Tech-invite3GPPspecsGlossariesIETFRFCsGroupsSIPABNFs   Ti+SearchTech-invite World Map Symbol

RFC 5533


Shim6: Level 3 Multihoming Shim Protocol for IPv6

Part 4 of 5, p. 86 to 110
Prev RFC Part       Next RFC Part


prevText      Top      Up      ToC       Page 86 
13.  Initial Contact

   The initial contact is some non-shim communication between two ULIDs,
   as described in Section 2.  At that point in time, there is no
   activity in the shim.

   Whether or not the shim ends up being used (e.g., the peer might not
   support Shim6), it is highly desirable that the initial contact can
   be established even if there is a failure for one or more IP

   The approach taken is to rely on the applications and the transport
   protocols to retry with different source and destination addresses,
   consistent with what is already specified in "Default Address
   Selection for IPv6" [7] as well as with some fixes to that
   specification [9], to make it try different source addresses and not
   only different destination addresses.

   The implementation of such an approach can potentially result in long
   timeouts.  For instance, consider a naive implementation at the
   socket API that uses getaddrinfo() to retrieve all destination
   addresses and then tries to bind() and connect() to try all source
   and destination address combinations and waits for TCP to time out
   for each combination before trying the next one.

   However, if implementations encapsulate this in some new connect-by-
   name() API and use non-blocking connect calls, it is possible to
   cycle through the available combinations in a more rapid manner until
   a working source and destination pair is found.  Thus, the issues in
   this domain are issues of implementations and the current socket API,
   and not issues of protocol specification.  In all honesty, while
   providing an easy to use connect-by-name() API for TCP and other
   connection-oriented transports is easy, providing a similar

Top      Up      ToC       Page 87 
   capability at the API for UDP is hard due to the protocol itself not
   providing any "success" feedback.  Yet, even the UDP issue is one of
   APIs and implementation.

14.  Protocol Constants

   The protocol uses the following constants:


   I1_TIMEOUT = 4 seconds

   NO_R1_HOLDDOWN_TIME = 1 min


   I2_TIMEOUT = 4 seconds


   I2bis_TIMEOUT = 4 seconds

   I2bis_RETRIES_MAX = 2


   UPDATE_TIMEOUT = 4 seconds

   MAX_UPDATE_TIMEOUT = 120 seconds

   The retransmit timers (I1_TIMEOUT, I2_TIMEOUT, UPDATE_TIMEOUT) are
   subject to binary exponential backoff as well as to randomization
   across a range of 0.5 and 1.5 times the nominal (backed off) value.
   This removes any risk of synchronization between lots of hosts
   performing independent shim operations at the same time.

   The randomization is applied after the binary exponential backoff.
   Thus, the first retransmission would happen based on a uniformly
   distributed random number in the range of [0.5*4, 1.5*4] seconds; the
   second retransmission, [0.5*8, 1.5*8] seconds after the first one,

Top      Up      ToC       Page 88 
15.  Implications Elsewhere

15.1.  Congestion Control Considerations

   When the locator pair currently used for exchanging packets in a
   Shim6 context becomes unreachable, the Shim6 layer will divert the
   communication through an alternative locator pair, which in most
   cases will result in redirecting the packet flow through an
   alternative network path.  In this case, it is recommended that the
   Shim6 follows the recommendation defined in [21] and informs the
   upper layers about the path change, in order to allow the congestion
   control mechanisms of the upper layers to react accordingly.

15.2.  Middle-Boxes Considerations

   Data packets belonging to a Shim6 context carrying the Shim6 Payload
   header contain alternative locators other than the ULIDs in the
   Source and Destination Address fields of the IPv6 header.  On the
   other hand, the upper layers of the peers involved in the
   communication operate on the ULID pair presented to them by the Shim6
   layer, rather than on the locator pair contained in the IPv6 header
   of the actual packets.  It should be noted that the Shim6 layer does
   not modify the data packets but, because a constant ULID pair is
   presented to upper layers irrespective of the locator pair changes,
   the relation between the upper-layer header (such as TCP, UDP, ICMP,
   ESP, etc) and the IPv6 header is modified.  In particular, when the
   Shim6 Extension header is present in the packet, if those data
   packets are TCP, UDP, or ICMP packets, the pseudo-header used for the
   checksum calculation will contain the ULID pair, rather than the
   locator pair contained in the data packet.

   It is possible that some firewalls or other middle-boxes will try to
   verify the validity of upper-layer sanity checks of the packet on the
   fly.  If they do that based on the actual source and destination
   addresses contained in the IPv6 header without considering the Shim6
   context information (in particular, without replacing the locator
   pair by the ULID pair used by the Shim6 context), such verifications
   may fail.  Those middle-boxes need to be updated in order to be able
   to parse the Shim6 Payload header and find the next header.  It is
   recommended that firewalls and other middle-boxes do not drop packets
   that carry the Shim6 Payload header with apparently incorrect upper-
   layer validity checks that involve the addresses in the IPv6 header
   for their computation, unless they are able to determine the ULID
   pair of the Shim6 context associated to the data packet and use the
   ULID pair for the verification of the validity check.

Top      Up      ToC       Page 89 
   In the particular case of TCP, UDP, and ICMP checksums, it is
   recommended that firewalls and other middle-boxes do not drop TCP,
   UDP, and ICMP packets that carry the Shim6 Payload header with
   apparently incorrect checksums when using the addresses in the IPv6
   header for the pseudo-header computation, unless they are able to
   determine the ULID pair of the Shim6 context associated to the data
   packet and use the ULID pair to determine the checksum that must be
   present in a packet with addresses rewritten by Shim6.

   In addition, firewalls that today pass limited traffic, e.g.,
   outbound TCP connections, would presumably block the Shim6 protocol.
   This means that even when Shim6-capable hosts are communicating, the
   I1 messages would be dropped; hence, the hosts would not discover
   that their peer is Shim6-capable.  This is, in fact, a benefit since,
   if the hosts managed to establish a ULID-pair context, the firewall
   would probably drop the "different" packets that are sent after a
   failure (those using the Shim6 Payload Extension header with a TCP
   packet inside it).  Thus, stateful firewalls that are modified to
   pass Shim6 messages should also be modified to pass the Shim6 Payload
   Extension header so that the shim can use the alternate locators to
   recover from failures.  This presumably implies that the firewall
   needs to track the set of locators in use by looking at the Shim6
   control exchanges.  Such firewalls might even want to verify the
   locators using the HBA/CGA verification themselves, which they can do
   without modifying any of the Shim6 packets through which they pass.

15.3.  Operation and Management Considerations

   This section considers some aspects related to the operations and
   management of the Shim6 protocol.

   Deployment of the Shim6 protocol: The Shim6 protocol is a host-based
   solution.  So, in order to be deployed, the stacks of the hosts using
   the Shim6 protocol need to be updated to support it.  This enables an
   incremental deployment of the protocol since it does not require a
   flag day for the deployment -- just single host updates.  If the
   Shim6 solution will be deployed in a site, the host can be gradually
   updated to support the solution.  Moreover, for supporting the Shim6
   protocol, only end hosts need to be updated and no router changes are
   required.  However, it should be noted that, in order to benefit from
   the Shim6 protocol, both ends of a communication should support the
   protocol, meaning that both hosts must be updated to be able to use
   the Shim6 protocol.  Nevertheless, the Shim6 protocol uses a deferred
   context-setup capability that allows end hosts to establish normal
   IPv6 communications and, later on, if both endpoints are Shim6-
   capable, establish the Shim6 context using the Shim6 protocol.  This

Top      Up      ToC       Page 90 
   has an important deployment benefit, since Shim6-enabled nodes can
   talk perfectly to non-Shim6-capable nodes without introducing any
   problem into the communication.

   Configuration of Shim6-capable nodes: The Shim6 protocol itself does
   not require any specific configuration to provide its basic features.
   The Shim6 protocol is designed to provide a default service to upper
   layers that should satisfy general applications.  The Shim6 layer
   would automatically attempt to protect long-lived communications by
   triggering the establishment of the Shim6 context using some
   predefined heuristics.  Of course, if some special tunning is
   required by some applications, this may require additional
   configuration.  Similar considerations apply to a site attempting to
   perform some forms of traffic engineering by using different
   preferences for different locators.

   Address and prefix configuration: The Shim6 protocol assumes that, in
   a multihomed site, multiple prefixes will be available.  Such
   configuration can increase the operation work in a network.  However,
   it should be noted that the capability of having multiple prefixes in
   a site and multiple addresses assigned to an interface is an IPv6
   capability that goes beyond the Shim6 case, and it is expected to be
   widely used.  So, even though this is the case for Shim6, we consider
   that the implications of such a configuration is beyond the
   particular case of Shim6 and must be addressed for the generic IPv6
   case.  Nevertheless, Shim6 also assumes the usage of CGA/HBA
   addresses by Shim6 hosts.  This implies that Shim6-capable hosts
   should configure addresses using HBA/CGA generation mechanisms.
   Additional consideration about this issue can be found at [19].

15.4.  Other Considerations

   The general Shim6 approach as well as the specifics of this proposed
   solution have implications elsewhere, including:

   o  Applications that perform referrals or callbacks using IP
      addresses as the 'identifiers' can still function in limited ways,
      as described in [18].  But, in order for such applications to be
      able to take advantage of the multiple locators for redundancy,
      the applications need to be modified to either use Fully Qualified
      Domain Names as the 'identifiers' or they need to pass all the
      locators as the 'identifiers', i.e., the 'identifier' from the
      application's perspective becomes a set of IP addresses instead of
      a single IP address.

   o  Signaling protocols for QoS or for other things that involve
      having devices in the network path look at IP addresses and port
      numbers (or at IP addresses and Flow Labels) need to be invoked on

Top      Up      ToC       Page 91 
      the hosts when the locator pair changes due to a failure.  At that
      point in time, those protocols need to inform the devices that a
      new pair of IP addresses will be used for the flow.  Note that
      this is the case even though this protocol, unlike some earlier
      proposals, does not overload the Flow Label as a Context Tag; the
      in-path devices need to know about the use of the new locators
      even though the Flow Label stays the same.

   o  MTU implications.  By computing a minimum over the recently
      observed path MTUs, the path MTU mechanisms we use are robust
      against different packets taking different paths through the
      Internet.  When Shim6 fails over from using one locator pair to
      another, this means that packets might travel over a different
      path through the Internet; hence, the path MTU might be quite
      different.  In order to deal with this change in the MTU, the
      usage of Packetization Layer Path MTU Discovery as defined in [24]
      is recommended.

      The fact that the shim will add an 8-octet Shim6 Payload Extension
      header to the ULP packets after a locator switch can also affect
      the usable path MTU for the ULPs.  In this case, the MTU change is
      local to the sending host; thus, conveying the change to the ULPs
      is an implementation matter.  By conveying the information to the
      transport layer, it can adapt and reduce the Maximum Segment Size
      (MSS) accordingly.

16.  Security Considerations

   This document satisfies the concerns specified in [15] as follows:

   o  The HBA [3] and CGA [2] techniques for verifying the locators to
      prevent an attacker from redirecting the packet stream to
      somewhere else, prevent threats described in Sections 4.1.1,
      4.1.2, 4.1.3, and 4.2 of [15].  These two techniques provide a
      similar level of protection but also provide different
      functionality with different computational costs.

      The HBA mechanism relies on the capability of generating all the
      addresses of a multihomed host as an unalterable set of
      intrinsically bound IPv6 addresses, known as an HBA set.  In this
      approach, addresses incorporate a cryptographic one-way hash of
      the prefix set available into the interface identifier part.  The
      result is that the binding between all the available addresses is
      encoded within the addresses themselves, providing hijacking
      protection.  Any peer using the shim protocol node can efficiently
      verify that the alternative addresses proposed for continuing the
      communication are bound to the initial address through a simple
      hash calculation.

Top      Up      ToC       Page 92 
      In a CGA-based approach, the address used as the ULID is a CGA
      that contains a hash of a public key in its interface identifier.
      The result is a secure binding between the ULID and the associated
      key pair.  This allows each peer to use the corresponding private
      key to sign the shim messages that convey locator set information.
      The trust chain in this case is the following: the ULID used for
      the communication is securely bound to the key pair because it
      contains the hash of the public key, and the locator set is bound
      to the public key through the signature.

      Either of these two mechanisms, HBA and CGA, provides time-shifted
      attack protection (as described in Section 4.1.2 of [15]), since
      the ULID is securely bound to a locator set that can only be
      defined by the owner of the ULID.  The minimum acceptable key
      length for RSA keys used in the generation of CGAs MUST be at
      least 1024 bits.  Any implementation should follow prudent
      cryptographic practice in determining the appropriate key lengths.

   o  3rd party flooding attacks, described in Section 4.3 of [15], are
      prevented by requiring a Shim6 peer to perform a successful
      Reachability probe + reply exchange before accepting a new locator
      for use as a packet destination.

   o  The first message does not create any state on the responder.
      Essentially, a 3-way exchange is required before the responder
      creates any state.  This means that a state-based DoS attack
      (trying to use up all memory on the responder) at least requires
      the attacker to create state, consuming his own resources; it also
      provides an IPv6 address that the attacker was using.

   o  The context-establishment messages use nonces to prevent replay
      attacks, which are described in Section 4.1.4 of [15], and to
      prevent off-path attackers from interfering with the

   o  Every control message of the Shim6 protocol, past the context
      establishment, carry the Context Tag assigned to the particular
      context.  This implies that an attacker needs to discover that
      Context Tag before being able to spoof any Shim6 control message
      as described in Section 4.4 of [15].  Such discovery probably
      requires an attacker to be along the path in order to sniff the
      Context Tag value.  The result is that, through this technique,
      the Shim6 protocol is protected against off-path attackers.

Top      Up      ToC       Page 93 
16.1.  Interaction with IPSec

   Shim6 has two modes of processing data packets.  If the ULID pair is
   also the locator pair being used, then the data packet is not
   modified by Shim6.  In this case, the interaction with IPSec is
   exactly the same as if the Shim6 layer was not present in the host.

   If the ULID pair differs from the current locator pair for that Shim6
   context, then Shim6 will take the data packet, replace the ULIDs
   contained in the IP Source and Destination Address fields with the
   current locator pair, and add the Shim6 extension with the
   corresponding Context Tag.  In this case, as is mentioned in Section
   1.6, Shim6 conceptually works as a tunnel mechanism, where the inner
   header contains the ULID and the outer header contains the locators.
   The main difference is that the inner header is "compressed" and a
   compression tag, namely the Context Tag, is added to decompress the
   inner header at the receiving end.

   In this case, the interaction between IPSec and Shim6 is then similar
   to the interaction between IPSec and a tunnel mechanism.  When the
   packet is generated by the upper-layer protocol, it is passed to the
   IP layer containing the ULIDs in the IP Source and Destination field.
   IPSec is then applied to this packet.  Then the packet is passed to
   the Shim6 sublayer, which "encapsulates" the received packet and
   includes a new IP header containing the locator pair in the IP Source
   and Destination field.  This new IP packet is in turn passed to IPSec
   for processing, just as in the case of a tunnel.  This can be viewed
   as if IPSec is located both above and below the Shim6 sublayer and as
   if IPSec policies apply both to ULIDs and locators.

   When IPSec processed the packet after the Shim6 sublayer has
   processed it (i.e., the packet carrying the locators in the IP Source
   and Destination Address field), the Shim6 sublayer may have added the
   Shim6 Extension header.  In that case, IPSec needs to skip the Shim6
   Extension header to find the selectors for the next layer's protocols
   (e.g., TCP, UDP, Stream Control Transmission Protocol (SCTP)).

   When a packet is received at the other end, it is processed based on
   the order of the extension headers.  Thus, if an ESP or AH header
   precedes a Shim6 header, that determines the order.  Shim6 introduces
   the need to do policy checks, analogous to how they are done for
   tunnels, when Shim6 receives a packet and the ULID pair for that
   packet is not identical to the locator pair in the packet.

Top      Up      ToC       Page 94 
16.2.  Residual Threats

   Some of the residual threats in this proposal are:

   o  An attacker that arrives late on the path (after the context has
      been established) can use the R1bis message to cause one peer to
      re-create the context and, at that point in time, can observe all
      of the exchange.  But this doesn't seem to open any new doors for
      the attacker since such an attacker can observe the Context Tags
      that are being used and, once known, can use those to send bogus

   o  An attacker present on the path in order to find out the Context
      Tags can generate an R1bis message after it has moved off the
      path.  For this packet to be effective, it needs to have a source
      locator that belongs to the context; thus, there cannot be "too
      much" ingress filtering between the attacker's new location and
      the communicating peers.  But this doesn't seem to be that severe
      because, once the R1bis causes the context to be re-established, a
      new pair of Context Tags will be used, which will not be known to
      the attacker.  If this is still a concern, we could require a
      2-way handshake, "did you really lose the state?", in response to
      the error message.

   o  It might be possible for an attacker to try random 47-bit Context
      Tags and see if they can cause disruption for communication
      between two hosts.  In particular, in the case of payload packets,
      the effects of such an attack would be similar to those of an
      attacker sending packets with a spoofed source address.  In the
      case of control packets, it is not enough to find the correct
      Context Tag -- additional information is required (e.g., nonces,
      proper source addresses; see previous bullet for the case of
      R1bis).  If a 47-bit tag, which is the largest that fits in an
      8-octet Extension header, isn't sufficient, one could use an even
      larger tag in the Shim6 control messages and use the low-order 47
      bits in the Shim6 Payload Extension header.

   o  When the Shim6 Payload Extension header is used, an attacker that
      can guess the 47-bit random Context Tag can inject packets into
      the context with any source locator.  Thus, if there is ingress
      filtering between the attacker and its target, this could
      potentially allow the attacker to bypass the ingress filtering.
      However, in addition to guessing the 47-bit Context Tag, the
      attacker also needs to find a context where, after the receiver's
      replacement of the locators with the ULIDs, the ULP checksum is
      correct.  But even this wouldn't be sufficient with ULPs like TCP,
      since the TCP port numbers and sequence numbers must match an
      existing connection.  Thus, even though the issues for off-path

Top      Up      ToC       Page 95 
      attackers injecting packets are different than today with ingress
      filtering, it is still very hard for an off-path attacker to
      guess.  If IPsec is applied, then the issue goes away completely.

   o  The validator included in the R1 and R1bis packets is generated as
      a hash of several input parameters.  While most of the inputs are
      actually determined by the sender, and only the secret value S is
      unknown to the sender, the resulting protection is deemed to be
      enough since it would be easier for the attacker to just obtain a
      new validator by sending an I1 packet than to perform all the
      computations required to determine the secret S.  Nevertheless, it
      is recommended that the host change the secret S periodically.

17.  IANA Considerations

   IANA allocated a new IP Protocol Number value (140) for the Shim6

   IANA recorded a CGA message type for the Shim6 protocol in the CGA
   Extension Type Tags registry with the value 0x4A30 5662 4858 574B
   3655 416F 506A 6D48.

   IANA established a Shim6 Parameter Registry with four components:
   Shim6 Type registrations, Shim6 Options registrations, Shim6 Error
   Code registrations, and Shim6 Verification Method registrations.

   The initial contents of the Shim6 Type registry are as follows:

   | Type Value |                       Message                       |
   |      0     |                       RESERVED                      |
   |      1     | I1 (first establishment message from the initiator) |
   |      2     | R1 (first establishment message from the responder) |
   |      3     |  I2 (2nd establishment message from the initiator)  |
   |      4     |  R2 (2nd establishment message from the responder)  |
   |      5     |  R1bis (Reply to reference to non-existent context) |
   |      6     |           I2bis (Reply to a R1bis message)          |
   |    7-59    |           Allocated using Standards action          |
   |    60-63   |                 For Experimental use                |
   |     64     |                    Update Request                   |
   |     65     |                Update Acknowledgement               |
   |     66     |                      Keepalive                      |
   |     67     |                    Probe Message                    |
   |     68     |                    Error Message                    |
   |   69-123   |           Allocated using Standards action          |
   |   124-127  |                 For Experimental use                |

Top      Up      ToC       Page 96 
   The initial contents of the Shim6 Options registry are as follows:

            |     Type    |            Option Name           |
            |      0      |             RESERVED             |
            |      1      |        Responder Validator       |
            |      2      |           Locator List           |
            |      3      |        Locator Preferences       |
            |      4      |   CGA Parameter Data Structure   |
            |      5      |           CGA Signature          |
            |      6      |             ULID Pair            |
            |      7      |    Forked Instance Identifier    |
            |     8-9     | Allocated using Standards action |
            |      10     |     Keepalive Timeout Option     |
            |   11-16383  | Allocated using Standards action |
            | 16384-32767 |       For Experimental use       |

   The initial contents of the Shim6 Error Code registry are as follows:

        | Code Value |                 Description                |
        |      0     |         Unknown Shim6 message type         |
        |      1     |       Critical Option not recognized       |
        |      2     |     Locator verification method failed     |
        |      3     | Locator List Generation number out of sync |
        |      4     |       Error in the number of locators      |
        |    5-19    |      Allocated using Standards action      |
        |   120-127  |       Reserved for debugging purposes      |

   The initial contents of the Shim6 Verification Method registry are as

              |  Value  |        Verification Method       |
              |    0    |             RESERVED             |
              |    1    |                CGA               |
              |    2    |                HBA               |
              |  3-200  | Allocated using Standards action |
              | 201-254 |       For Experimental use       |
              |   255   |             RESERVED             |

Top      Up      ToC       Page 97 
18.  Acknowledgements

   Over the years, many people active in the multi6 and shim6 WGs have
   contributed ideas and suggestions that are reflected in this
   specification.  Special thanks to the careful comments from Sam
   Hartman, Cullen Jennings, Magnus Nystrom, Stephen Kent, Geoff Huston,
   Shinta Sugimoto, Pekka Savola, Dave Meyer, Deguang Le, Jari Arkko,
   Iljitsch van Beijnum, Jim Bound, Brian Carpenter, Sebastien Barre,
   Matthijs Mekking, Dave Thaler, Bob Braden, Wesley Eddy, Pasi Eronen,
   and Tom Henderson on earlier versions of this document.

19.  References

19.1.  Normative References

   [1]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

   [2]   Aura, T., "Cryptographically Generated Addresses (CGA)",
         RFC 3972, March 2005.

   [3]   Bagnulo, M., "Hash-Based Addresses (HBA)", RFC 5535, June 2009.

   [4]   Arkko, J. and I. van Beijnum, "Failure Detection and Locator
         Pair Exploration Protocol for IPv6 Multihoming", RFC 5534,
         June 2009.

19.2.  Informative References

   [5]   Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
         specifying the location of services (DNS SRV)", RFC 2782,
         February 2000.

   [6]   Ferguson, P. and D. Senie, "Network Ingress Filtering:
         Defeating Denial of Service Attacks which employ IP Source
         Address Spoofing", BCP 38, RFC 2827, May 2000.

   [7]   Draves, R., "Default Address Selection for Internet Protocol
         version 6 (IPv6)", RFC 3484, February 2003.

   [8]   Nordmark, E., "Multihoming without IP Identifiers", Work
         in Progress, July 2004.

   [9]   Bagnulo, M., "Updating RFC 3484 for multihoming support", Work
         in Progress, November 2007.

Top      Up      ToC       Page 98 
   [10]  Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
         "RTP: A Transport Protocol for Real-Time Applications", STD 64,
         RFC 3550, July 2003.

   [11]  Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site-
         Multihoming Architectures", RFC 3582, August 2003.

   [12]  Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, "IPv6
         Flow Label Specification", RFC 3697, March 2004.

   [13]  Eastlake, D., Schiller, J., and S. Crocker, "Randomness
         Requirements for Security", BCP 106, RFC 4086, June 2005.

   [14]  Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
         Addresses", RFC 4193, October 2005.

   [15]  Nordmark, E. and T. Li, "Threats Relating to IPv6 Multihoming
         Solutions", RFC 4218, October 2005.

   [16]  Huitema, C., "Ingress filtering compatibility for IPv6
         multihomed sites", Work in Progress, September 2005.

   [17]  Bagnulo, M. and E. Nordmark, "SHIM - MIPv6 Interaction", Work
         in Progress, July 2005.

   [18]  Nordmark, E., "Shim6-Application Referral Issues", Work
         in Progress, July 2005.

   [19]  Bagnulo, M. and J. Abley, "Applicability Statement for the
         Level 3 Multihoming Shim Protocol (Shim6)", Work in Progress,
         July 2007.

   [20]  Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson,
         "Host Identity Protocol", RFC 5201, April 2008.

   [21]  Schuetz, S., Koutsianas, N., Eggert, L., Eddy, W., Swami, Y.,
         and K. Le, "TCP Response to Lower-Layer Connectivity-Change
         Indications", Work in Progress, February 2008.

   [22]  Williams, N. and M. Richardson, "Better-Than-Nothing Security:
         An Unauthenticated Mode of IPsec", RFC 5386, November 2008.

   [23]  Komu, M., Bagnulo, M., Slavov, K., and S. Sugimoto, "Socket
         Application Program Interface (API) for Multihoming Shim", Work
         in Progress, November 2008.

   [24]  Mathis, M. and J. Heffner, "Packetization Layer Path MTU
         Discovery", RFC 4821, March 2007.

Top      Up      ToC       Page 99 
   [25]  Bonica, R., Gan, D., Tappan, D., and C. Pignataro, "Extended
         ICMP to Support Multi-Part Messages", RFC 4884, April 2007.

Top      Up      ToC       Page 100 
Appendix A.  Possible Protocol Extensions

   During the development of this protocol, several issues have been
   brought up that are important to address but that do not need to be
   in the base protocol itself; instead, these can be done as extensions
   to the protocol.  The key ones are:

   o  As stated in the assumptions in Section 3, in order for the Shim6
      protocol to be able to recover from a wide range of failures (for
      instance, when one of the communicating hosts is single-homed) and
      to cope with a site's ISPs that do ingress filtering based on the
      source IPv6 address, there is a need for the host to be able to
      influence the egress selection from its site.  Further discussion
      of this issue is captured in [16].

   o  Is there need for keeping the list of locators private between the
      two communicating endpoints?  We can potentially accomplish that
      when using CGA (not when using HBA), but only at the cost of doing
      some public key encryption and decryption operations as part of
      the context establishment.  The suggestion is to leave this for a
      future extension to the protocol.

   o  Defining some form of end-to-end "compression" mechanism that
      removes the need to include the Shim6 Payload Extension header
      when the locator pair is not the ULID pair.

   o  Supporting the dynamic setting of locator preferences on a site-
      wide basis and using the Locator Preference option in the Shim6
      protocol to convey these preferences to remote communicating
      hosts.  This could mirror the DNS SRV record's notion of priority
      and weight.

   o  Specifying APIs in order for the ULPs to be aware of the locators
      that the shim is using and to be able to influence the choice of
      locators (controlling preferences as well as triggering a locator-
      pair switch).  This includes providing APIs that the ULPs can use
      to fork a shim context.

   o  Determining whether it is feasible to relax the suggestions for
      when context state is removed so that one can end up with an
      asymmetric distribution of the context state and still get (most
      of) the shim benefits.  For example, the busy server would go
      through the context setup but would quickly remove the context
      state after this (in order to save memory); however, the not-so-
      busy client would retain the context state.  The context-recovery
      mechanism presented in Section 7.5 would then re-create the state
      should the client send either a shim control message (e.g., Probe
      message because it sees a problem) or a ULP packet in a Shim6

Top      Up      ToC       Page 101 
      Payload Extension header (because it had earlier failed over to an
      alternative locator pair but had been silent for a while).  This
      seems to provide the benefits of the shim as long as the client
      can detect the failure.  If the client doesn't send anything and
      it is the server that tries to send, then it will not be able to
      recover because the shim on the server has no context state and
      hence doesn't know any alternate locator pairs.

   o  Study what it would take to make the Shim6 control protocol not
      rely at all on a stable source locator in the packets.  This can
      probably be accomplished by having all the shim control messages
      include the ULID-pair option.

   o  If each host might have lots of locators, then the current
      requirement to include essentially all of them in the I2 and R2
      messages might be constraining.  If this is the case, we can look
      into using the CGA Parameter Data Structure for the comparison,
      instead of the prefix sets, to be able to detect context
      confusion.  This would place some constraint on a (logical) only
      using, for example, one CGA public key; it would also require some
      carefully crafted rules on how two PDSs are compared for "being
      the same host".  But if we don't expect more than a handful of
      locators per host, then we don't need this added complexity.

   o  ULP-specified timers for the reachability detection mechanism
      (which can be particularly useful when there are forked contexts).

   o  Pre-verify some "backup" locator pair, so that the failover time
      can be shorter.

   o  Study how Shim6 and Mobile IPv6 might interact [17].

Appendix B.  Simplified STATE Machine

   The STATEs are defined in Section 6.2.  The intent is for the
   stylized description below to be consistent with the textual
   description in the specification; however, should they conflict, the
   textual description is normative.

Top      Up      ToC       Page 102 
   The following table describes the possible actions in STATE IDLE and
   their respective triggers:

   | Trigger             | Action                                      |
   | Receive I1          | Send R1 and stay in IDLE                    |
   |                     |                                             |
   | Heuristics trigger  | Send I1 and move to I1-SENT                 |
   | a new context       |                                             |
   | establishment       |                                             |
   |                     |                                             |
   | Receive I2, verify  | If successful, send R2 and move to          |
   | validator and       | ESTABLISHED                                 |
   | RESP Nonce          |                                             |
   |                     | If fail, stay in IDLE                       |
   |                     |                                             |
   | Receive I2bis,      | If successful, send R2 and move to          |
   | verify validator    | ESTABLISHED                                 |
   | and RESP Nonce      |                                             |
   |                     | If fail, stay in IDLE                       |
   |                     |                                             |
   | R1, R1bis, R2       | N/A (This context lacks the required info   |
   |                     | for the dispatcher to deliver them)         |
   |                     |                                             |
   | Receive Payload     | Send R1bis and stay in IDLE                 |
   | Extension header    |                                             |
   | or other control    |                                             |
   | packet              |                                             |

Top      Up      ToC       Page 103 
   The following table describes the possible actions in STATE I1-SENT
   and their respective triggers:

   | Trigger             | Action                                      |
   | Receive R1, verify  | If successful, send I2 and move to I2-SENT  |
   | INIT Nonce          |                                             |
   |                     | If fail, discard and stay in I1-SENT        |
   |                     |                                             |
   | Receive I1          | Send R2 and stay in I1-SENT                 |
   |                     |                                             |
   | Receive R2, verify  | If successful, move to ESTABLISHED          |
   | INIT Nonce          |                                             |
   |                     | If fail, discard and stay in I1-SENT        |
   |                     |                                             |
   | Receive I2, verify  | If successful, send R2 and move to          |
   | validator and RESP  | ESTABLISHED                                 |
   | Nonce               |                                             |
   |                     | If fail, discard and stay in I1-SENT        |
   |                     |                                             |
   | Receive I2bis,      | If successful, send R2 and move to          |
   | verify validator    | ESTABLISHED                                 |
   | and RESP Nonce      |                                             |
   |                     | If fail, discard and stay in I1-SENT        |
   |                     |                                             |
   | Timeout, increment  | If counter =< I1_RETRIES_MAX, send I1 and   |
   | timeout counter     | stay in I1-SENT                             |
   |                     |                                             |
   |                     | If counter > I1_RETRIES_MAX, go to E-FAILED |
   |                     |                                             |
   | Receive ICMP payload| Move to E-FAILED                            |
   | unknown error       |                                             |
   |                     |                                             |
   | R1bis               | N/A (Dispatcher doesn't deliver since       |
   |                     | CT(peer) is not set)                        |
   |                     |                                             |
   | Receive Payload     | Discard and stay in I1-SENT                 |
   | Extension header    |                                             |
   | or other control    |                                             |
   | packet              |                                             |

Top      Up      ToC       Page 104 
   The following table describes the possible actions in STATE I2-SENT
   and their respective triggers:

   | Trigger             | Action                                      |
   | Receive R2, verify  | If successful, move to ESTABLISHED          |
   | INIT Nonce          |                                             |
   |                     | If fail, stay in I2-SENT                    |
   |                     |                                             |
   | Receive I1          | Send R2 and stay in I2-SENT                 |
   |                     |                                             |
   | Receive I2,         | Send R2 and stay in I2-SENT                 |
   | verify validator    |                                             |
   | and RESP Nonce      |                                             |
   |                     |                                             |
   | Receive I2bis,      | Send R2 and stay in I2-SENT                 |
   | verify validator    |                                             |
   | and RESP Nonce      |                                             |
   |                     |                                             |
   | Receive R1          | Discard and stay in I2-SENT                 |
   |                     |                                             |
   | Timeout, increment  | If counter =< I2_RETRIES_MAX, send I2 and   |
   | timeout counter     | stay in I2-SENT                             |
   |                     |                                             |
   |                     | If counter > I2_RETRIES_MAX, send I1 and go |
   |                     | to I1-SENT                                  |
   |                     |                                             |
   | R1bis               | N/A (Dispatcher doesn't deliver since       |
   |                     | CT(peer) is not set)                        |
   |                     |                                             |
   | Receive Payload     | Accept and send I2 (probably R2 was sent    |
   | Extension header    | by peer and lost)                           |
   | or other control    |                                             |
   | packet              |                                             |

Top      Up      ToC       Page 105 
   The following table describes the possible actions in STATE I2BIS-
   SENT and their respective triggers:

   | Trigger             | Action                                      |
   | Receive R2, verify  | If successful, move to ESTABLISHED          |
   | INIT Nonce          |                                             |
   |                     | If fail, stay in I2BIS-SENT                 |
   |                     |                                             |
   | Receive I1          | Send R2 and stay in I2BIS-SENT              |
   |                     |                                             |
   | Receive I2,         | Send R2 and stay in I2BIS-SENT              |
   | verify validator    |                                             |
   | and RESP Nonce      |                                             |
   |                     |                                             |
   | Receive I2bis,      | Send R2 and stay in I2BIS-SENT              |
   | verify validator    |                                             |
   | and RESP Nonce      |                                             |
   |                     |                                             |
   | Receive R1          | Discard and stay in I2BIS-SENT              |
   |                     |                                             |
   | Timeout, increment  | If counter =< I2_RETRIES_MAX, send I2bis    |
   | timeout counter     | and stay in I2BIS-SENT                      |
   |                     |                                             |
   |                     | If counter > I2_RETRIES_MAX, send I1 and    |
   |                     | go to I1-SENT                               |
   |                     |                                             |
   | R1bis               | N/A (Dispatcher doesn't deliver since       |
   |                     | CT(peer) is not set)                        |
   |                     |                                             |
   | Receive Payload     | Accept and send I2bis (probably R2 was      |
   | Extension header    | sent by peer and lost)                      |
   | or other control    |                                             |
   | packet              |                                             |

Top      Up      ToC       Page 106 
   The following table describes the possible actions in STATE
   ESTABLISHED and their respective triggers:

   | Trigger             | Action                                      |
   | Receive I1, compare | If no match, send R1 and stay in ESTABLISHED|
   | CT(peer) with       |                                             |
   | received CT         | If match, send R2 and stay in ESTABLISHED   |
   |                     |                                             |
   |                     |                                             |
   | Receive I2, verify  | If successful, send R2 and stay in          |
   | validator and RESP  | ESTABLISHED                                 |
   | Nonce               |                                             |
   |                     | Otherwise, discard and stay in ESTABLISHED  |
   |                     |                                             |
   | Receive I2bis,      | If successful, send R2 and stay in          |
   | verify validator    | ESTABLISHED                                 |
   | and RESP Nonce      |                                             |
   |                     | Otherwise, discard and stay in ESTABLISHED  |
   |                     |                                             |
   | Receive R2          | Discard and stay in ESTABLISHED             |
   |                     |                                             |
   | Receive R1          | Discard and stay in ESTABLISHED             |
   |                     |                                             |
   | Receive R1bis       | Send I2bis and move to I2BIS-SENT           |
   |                     |                                             |
   |                     |                                             |
   | Receive Payload     | Process and stay in ESTABLISHED             |
   | Extension header    |                                             |
   | or other control    |                                             |
   | packet              |                                             |
   |                     |                                             |
   | Implementation-     | Discard state and go to IDLE                |
   | specific heuristic  |                                             |
   | (e.g., No open ULP  |                                             |
   | sockets and idle    |                                             |
   | for some time )     |                                             |

Top      Up      ToC       Page 107 
   The following table describes the possible actions in STATE E-FAILED
   and their respective triggers:

   | Trigger             | Action                                      |
   | Wait for            | Go to IDLE                                  |
   | NO_R1_HOLDDOWN_TIME |                                             |
   |                     |                                             |
   | Any packet          | Process as in IDLE                          |

   The following table describes the possible actions in STATE NO-
   SUPPORT and their respective triggers:

   | Trigger             | Action                                      |
   | Wait for            | Go to IDLE                                  |
   | ICMP_HOLDDOWN_TIME  |                                             |
   |                     |                                             |
   | Any packet          | Process as in IDLE                          |

Top      Up      ToC       Page 108 
B.1.  Simplified STATE Machine Diagram

                                          Timeout/Null    +------------+
                            I1/R1      +------------------| NO SUPPORT |
            Payload or Control/R1bis   |                  +------------+
                        +---------+    |                              ^
                        |         |    |               ICMP Error/Null|
                        |         V    V                              |
                      +-----------------+  Timeout/Null  +----------+ |
                      |                 |<---------------| E-FAILED | |
                    +-|      IDLE       |                +----------+ |
     I2 or I2bis/R2 | |                 |                          ^  |
                    | +-----------------+       (Tiemout#>MAX)/Null|  |
                    |    ^            |                            |  |
                    |    |            +------+                     |  |
   I2 or I2bis/R2   |    |       Heuristic/I1|            I1/R2    |  |
     Payload/Null   |    |                   |       Control/Null  |  |
      I1/R1 or R2   | +--+                   |       Payload/Null  |  |
    R1 or R2/Null   | |Heuristic/Null        |  (Tiemout#<MAX)/I1  |  |
      +----------+  | |                      |         +--------+  |  |
      |          V  V |                      |         |        V  |  |
    +-------------------+   R2/Null          |        +----------------+
    |                   |   I2 or I2bis/R2   +------->|                |
    |   ESTABLISHED     |<----------------------------|    I1-SENT     |
    |                   |                             |                |
    +-------------------+                             +----------------+
       |     ^        ^                                   |   ^       ^
       |     |        |R2/Null              +-------------+   |       |
       |     |        +----------+          |R1/I2            |       |
       |     |                   |          V                 |       |
       |     |               +------------------+             |       |
       |     |               |                  |-------------+       |
       |     |               |     I2-SENT      | (Timeout#>Max)/I1   |
       |     |               |                  |                     |
       |     |               +------------------+                     |
       |     |                 |              ^                       |
       |     |                 +--------------+                       |
       |     |                I1 or I2bis or I2/R2                    |
       |     |           (Timeout#<Max) or Payload/I2                 |
       |     |                 R1 or R1bis/Null                       |
       |     +-------+                              (Timeout#>Max)/I1 |
       |      R2/Null|     +------------------------------------------+
       |             V     |
       |         +-------------------+
       |         |                   |<-+ (Timeout#<Max)/I2bis
       +-------->|   I2bis-SENT      |  | I1 or I2 or I2bis/R2
     R1bis/I2bis |                   |--+ R1 or R1bis/Null
                 +-------------------+    Payload/I2bis

Top      Up      ToC       Page 109 
Appendix C.  Context Tag Reuse

   The Shim6 protocol doesn't have a mechanism for coordinated state
   removal between the peers because such state removal doesn't seem to
   help, given that a host can crash and reboot at any time.  A result
   of this is that the protocol needs to be robust against a Context Tag
   being reused for some other context.  This section summarizes the
   different cases in which a Tag can be reused, and how the recovery

   The different cases are exemplified by the following case.  Assume
   hosts A and B were communicating using a context with the ULID pair
   <A1, B2>, and that B had assigned Context Tag X to this context.  We
   assume that B uses only the Context Tag to demultiplex the received
   Shim6 Payload Extension headers, since this is the more general case.
   Further, we assume that B removes this context state, while A retains
   it.  B might then at a later time assign CT(local)=X to some other
   context, at which time, we have several possible cases:

   o  The Context Tag is reassigned to a context for the same ULID pair
      <A1, B2>.  We've called this "context recovery" in this document.

   o  The Context Tag is reassigned to a context for a different ULID
      pair between the same two hosts, e.g., <A3, B3>.  We've called
      this "context confusion" in this document.

   o  The Context Tag is reassigned to a context between B and another
      host C, for instance, for the ULID pair <C3, B2>.  That is a form
      of three-party context confusion.

C.1.  Context Recovery

   This case is relatively simple and is discussed in Section 7.5.  The
   observation is that since the ULID pair is the same, when either A or
   B tries to establish the new context, A can keep the old context
   while B re-creates the context with the same Context Tag CT(B) = X.

C.2.  Context Confusion

   This case is a bit more complex and is discussed in Section 7.6.
   When the new context is created, whether A or B initiates it, host A
   can detect when it receives B's locator set (in the I2 or R2 message)
   in that it ends up with two contexts to the same peer host
   (overlapping Ls(peer) locator sets) that have the same Context Tag:
   CT(peer) = X.  At this point in time, host A can clear up any
   possibility of causing confusion by not using the old context to send
   any more packets.  It either just discards the old context (it might
   not be used by any ULP traffic, since B had discarded it) or it re-

Top      Up      ToC       Page 110 
   creates a different context for the old ULID pair (<A1, B2>), for
   which B will assign a unique CT(B) as part of the normal context-
   establishment mechanism.

C.3.  Three-Party Context Confusion

   The third case does not have a place where the old state on A can be
   verified since the new context is established between B and C.  Thus,
   when B receives Shim6 Payload Extension headers with X as the Context
   Tag, it will find the context for <C3, B2> and, hence, will rewrite
   the packets to have C3 in the Source Address field and B2 in the
   Destination Address field before passing them up to the ULP.  This
   rewriting is correct when the packets are in fact sent by host C, but
   if host A ever happens to send a packet using the old context, then
   the ULP on A sends a packet with ULIDs <A1, B2> and the packet
   arrives at the ULP on B with ULIDs <C3, B2>.

   This is clearly an error, and the packet will most likely be rejected
   by the ULP on B due to a bad pseudo-header checksum.  Even if the
   checksum is okay (probability 2^-16), the ULP isn't likely to have a
   connection for those ULIDs and port numbers.  And if the ULP is
   connection-less, processing the packet is most likely harmless; such
   a ULP must be able to copy with random packets being sent by random
   peers in any case.

   This broken state, where packets are sent from A to B using the old
   context on host A, might persist for some time but will not remain
   for very long.  The unreachability detection on host A will kick in
   because it does not see any return traffic (payload or Keepalive
   messages) for the context.  This will result in host A sending Probe
   messages to host B to find a working locator pair.  The effect of
   this is that host B will notice that it does not have a context for
   the ULID pair <A1, B2> and CT(B) = X, which will make host B send an
   R1bis packet to re-establish that context.  The re-established
   context, just like in the previous section, will get a unique CT(B)
   assigned by host B; thus, there will no longer be any confusion.

C.4.  Summary

   In summary, there are cases where a Context Tag might be reused while
   some peer retains the state, but the protocol can recover from it.
   The probability of these events is low, given the 47-bit Context Tag
   size.  However, it is important that these recovery mechanisms be
   tested.  Thus, during development and testing, it is recommended that
   implementations not use the full 47-bit space but instead keep, for
   example, the top 40 bits as zero, only leaving the host with 128
   unique Context Tags.  This will help test the recovery mechanisms.

Next RFC Part