[Top] [Contents] [Index] [ ? ]

shim6 manual (html version)

Authors: Jeff Ahrenholz and Tom Henderson

For a pdf version of this manual, see http://www.openhip.org/docs/shim6.pdf.

Copyright © 2006-07, The Boeing Company.

This software was developed under funding supplied by ONR contract N00014-06-C-0319 and The Boeing Company.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

1. Introduction

shim6 (Site Multihoming by IPv6 Intermediation) is a protocol being developed in the Internet Engineering Task Force (IETF) to provide a host-based solution to allow IPv6 sites to multi-home (connect to more than one Internet provider) for load sharing, redundancy, and fault tolerance. The shim6 protocol allows such hosts to hold multiple locators (addresses) and to migrate transport protocol sessions from one locator pair to another without disruption. The protocol includes components for securely (cryptographically) binding locator sets together to prevent address hijacking, and a separate reachability protocol (REAP) that can monitor the reachability of peer locators in active use.

shim6 is architecturally related to the Host Identity Protocol (HIP), in that they both implement an identifier/locator split at the boundary between the network and transport layer. Their control protocols also share many of the same packet formats.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

1.1 Goals

The goals of this shim6 effort have been to develop an open-source Linux implementation of shim6 that borrows from (and can later integrate with) our HIP implementation. We are interested in the long-term potential of the ID/locator split architecture and in eventual evolution towards some kind of a combined shim6/HIP implementation:


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

1.1.1 Non-goals

The following goals are deferred for a later phase of development:


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

1.2 Software architecture

Our shim6 implementation is a multithreaded C++ user-space processes that interfaces with a standard Linux kernel (extended via a loadable kernel module) through standard system interfaces and with a GUI-based status application via sockets IPC. Although we do not require kernel patches, we do require specific kernel versions since we are working with kernel modules that do not have stable APIs across kernel releases.

Although some components of our architecture are defined for multi-platform support, we currently focus on Linux. fig:overall-arch illustrates the overall software architecture. Cross-layer interaction with TCP (e.g., resetting congestion window upon locator change) is not shown and needs further consideration whether it can be done without a kernel modification.

figures/shim6-figure1

Figure 1.1: Overall shim6 implementation architecture.

The overall strategy is to use loadable Netfilter mangle modules in the IPv6 firewall tables to implement the shimming and deshimming of packets, to use Netfilter queue to receive shim6 control packets, and the Linux Netfilter conntrack (connection tracking) feature to track active flows. The shim6 daemon itself is a process that shares a HIP-abstraction library with our HIP daemon, and the failure detection daemon (reapd) is designed to be reused across HIP and shim6.

Below is an excerpt from Section 4 of the shim6 protocol draft. The above fig:overall-arch can probably best be understood by walking through what happens in the software to cause the following shim6 behavior to occur.


     The shim6 protocol operates in several phases over time.  The
     following sequence illustrates the concepts:
  
     o  An application on host A decides to contact B using some upper-
        layer protocol.  This results in the ULP on A sending packets to
        B. We call this the initial contact.  Assuming the IP addresses
        selected by Default Address Selection [12] and its extensions [13]
        work, then there is no action by the shim at this point in time.
        Any shim context establishment can be deferred until later.

No action.


     o  Some heuristic on A or B (or both) determine that it is
        appropriate to pay the shim6 overhead to make this host-to-host
        communication robust against locator failures.  For instance, this
        heuristic might be that more than 50 packets have been sent or
        received, or a timer expiration while active packet exchange is in
        place.  This makes the shim initiate the 4-way context
        establishment exchange.
  
        As a result of this exchange, both A and B will know a list of
        locators for each other.
  
        If the context establishment exchange fails, the initiator will
        then know that the other end does not support shim6, and will
        continue with standard unicast behavior for the session.

Netfilter connection tracking is used to implement the supported heuristic. A thread in the REAP user-space software can monitor this according to policy and invoke a shim6 context establishment and locator exchange (by telling the shim6 daemon) when necessary.

The above step just builds state (ULID/locator context) in the shim6 daemon but does not affect any data plane packets.

However, the reachability protocol (REAP) starts to monitor the ULIDs for reachability, and should be provided with a list of alternate locators learned during the shim6 handshake.


     o  Communication continues without any change for the ULP packets.
        In particular, there are no shim extension headers added to the
        ULP packets, since the ULID pair is the same as the locator pair.
        In addition, there might be some messages exchanged between the
        shim sub-layers for (un)reachability detection.
  
     o  At some point in time something fails.  Depending on the approach
        to reachability detection, there might be some advice from the
        ULP, or the shim (un)reachability detection might discover that
        there is a problem.
  
        At this point in time one or both ends of the communication need
        to probe the different alternate locator pairs until a working
        pair is found, and switch to using that locator pair.

REAP process or thread separately does this probing, and notifies shim6 software via sockets IPC when a ULID should be replaced with alternate locator(s).

When notified, the host needs to assume that packets may start arriving on that shim context or may need to be sent on new shim context.

If the local host has new dest locators, a two step process is needed for each active locator that is != dst ULID:

  1. add a rule to divert packets to a SHIM6 module
    ip6tables -A INPUT <matching rule> -j SHIM6
  2. add context state to the SHIM6 module

If the local host has new src locators, a two step process will be needed for each active locator that is != src ULID:

  1. add a rule to divert packets to a SHIM6 module
    ip6tables -A OUTPUT <matching rule> -j SHIM6
  2. add context state to the SHIM6 module

     o  Once a working alternative locator pair has been found, the shim
        will rewrite the packets on transmit, and tag the packets with
        shim6 Payload extension header, which contains the receiver's
        context tag.  The receiver will use the context tag to find the
        context state which will indicate which addresses to place in the
        IPv6 header before passing the packet up to the ULP.  The result
        is that from the perspective of the ULP the packet passes
        unmodified end-to-end, even though the IP routing infrastructure
        sends the packet to a different locator.

Nothing needed, until connection being shimmed goes away or the locator pair changes again. There needs to be some garbage collection of shim state not being used for a long time. Again, Netfilter connection tracking could be used for this.


     o  The shim (un)reachability detection will monitor the new locator
        pair as it monitored the original locator pair, so that subsequent
        failures can be detected.

The above is a function of the REAP protocol.


     o  In addition to failures detected based on end-to-end observations,
        one endpoint might know for certain that one or more of its
        locators is not working.  For instance, the network interface
        might have failed or gone down (at layer 2), or an IPv6 address
        might have become deprecated or invalid.  In such cases the host
        can signal its peer that this address is no longer recommended to
        try.  Thus this triggers something similar to a failure handling
        in that a new, working locator pair must be found.

The above is a function of the REAP protocol.


        The protocol also has the ability to express other forms of
        locator preferences.  A change in any preferences can be signaled
        to the peer, which will made the peer record the new preferences.
        A change in the preferences might optionally make the peer want to
        use a different locator pair.  If it makes this decision, it
        follows the same locator switching procedure as after a failure
        (by verifying that its peer is indeed present at the alternate
        locator, etc).

This exchange will take part in the shim6 daemon, and updates are pushed to the REAP protocol. Change in local locator status may be monitored by the Netlink ROUTING socket.


     o  When the shim thinks that the context state is no longer used, it
        can garbage collect the state; there is no coordination necessary
        with the peer host before the state is removed.  There is a
        recovery message defined to be able to signal when there is no
        context state, which can be used to detect and recover from both
        premature garbage collection, as well as complete state loss
        (crash and reboot) of a peer.

SHIM6 kernel module needs to be able to send this NO_CONTEXT message to shim6 daemon.


        The exact mechanism to determine when the context state is no
        longer used is implementation dependent.  An implementation might
        use the existence of ULP state (where known to the implementation)
        as an indication that the state is still used, combined with a
        timer (to handle ULP state that might not be known to the shim
        sub-layer) to determine when the state is likely to no longer be
        used.
  
     NOTE: The ULP packets in shim6 can be carried completely unmodified
     as long as the ULID pair is used as the locator pair.  After a switch
     to a different locator pair the packets are "tagged" with a shim6
     extension header, so that the receiver can always determine the
     context to which they belong.  This is accomplished by including an
     8-octet shim6 Payload Extension header before the (extension) headers
     that are processed by the IP endpoint sublayer and ULPs.  If
     subsequently the original ULIDs are selected as the active locator
     pair then the tagging of packets with the shim6 extension header can
     also be stopped.

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

1.3 Implementation status

Currently, this implementation supports the following:


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

1.4 Future work

These items are left for future revisions:


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

2. Installation


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

2.1 Prerequisites

Background information on shim6 is available at these links:


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

2.1.1 Operating Systems

This software has only been tested on Linux i386 systems. There are several Linux kernel dependencies that are known to be unstable across recent kernel versions. We have tested using 2.6.20 kernels on Ubuntu and Fedora Linux.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

2.2 Installing supporting libraries


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

2.2.1 Overview

The following open source packages and programs are needed for shim6:

These dependencies are part of this software distribution:


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

2.2.2 Supporting libraries

The following libraries are necessary. We recommend that you install these from a source package because some of the RPM and DEB packages for Linux distributions are incomplete (even development packages).


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

2.2.3 ip6tables extensions

The kernel-level firewall tool for IPv6, ip6tables, has been extended in two ways to support SHIM6. There is a shim6 match module for receiving SHIM6 control and data packets, and a shim6_data target for inserting and removing the shim layer from data packets.

  1. build and install both shim6 ip6tables kernel modules
  2. build and install the iptables libraries - for extending the ip6tables command

The following is performed automatically by the shim6 daemon, but included here for reference.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

2.3 Installing shim6


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

2.3.1 REAP daemon

This implements the REAchability Process that monitors local address information, remote peer status, and takes care of verifying reachability.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

2.3.2 SHIM6 daemon

The SHIM6 daemon implements the SHIM6 protocol, exchanging SHIM6 control messages and inserting context state into the kernel, using both the REAP daemon and the HAL library. The REAP daemon should be running first.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3. Running shim6


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.1 Overview

shim6 requires two processes and a number of modules to be running:

If you performed a make install in the previous installation step, these executables are likely in your /usr/local/sbin path:

Here is a sample list of commands that could be executed:

 
cd /usr/local/sbin
sudo ip6tables -F
sudo modprobe nf_conntrack_ipv6
sudo insmod -f ./ip6t_shim6.ko
sudo insmod -f ./ip6t_shim6_data.ko
sudo reapd
sudo shim6d

Of course, all of the above could be somewhat automated in an init script.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.2 Testing shim6

So now what? shim6 and reap are running, but are they doing anything?

Below are some initial steps that can be taken to exercise your implementation.


[Top] [Contents] [Index] [ ? ]

Table of Contents


[Top] [Contents] [Index] [ ? ]

About This Document

This document was generated by Tom Henderson on December, 31 2007 using texi2html 1.76.

The buttons in the navigation panels have the following meaning:

Button Name Go to From 1.2.3 go to
[ < ] Back previous section in reading order 1.2.2
[ > ] Forward next section in reading order 1.2.4
[ << ] FastBack beginning of this chapter or previous chapter 1
[ Up ] Up up section 1.2
[ >> ] FastForward next chapter 2
[Top] Top cover (top) of document  
[Contents] Contents table of contents  
[Index] Index index  
[ ? ] About about (help)  

where the Example assumes that the current position is at Subsubsection One-Two-Three of a document of the following structure:


This document was generated by Tom Henderson on December, 31 2007 using texi2html 1.76.