Tech-invite3GPPspaceIETF RFCsSIP
929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 5533

Shim6: Level 3 Multihoming Shim Protocol for IPv6

Pages: 124
Proposed Standard
Part 4 of 5 – Pages 86 to 110
First   Prev   Next

Top   ToC   RFC5533 - Page 86   prevText

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 addresses. 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   ToC   RFC5533 - 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_RETRIES_MAX = 4 I1_TIMEOUT = 4 seconds NO_R1_HOLDDOWN_TIME = 1 min ICMP_HOLDDOWN_TIME = 10 min I2_TIMEOUT = 4 seconds I2_RETRIES_MAX = 2 I2bis_TIMEOUT = 4 seconds I2bis_RETRIES_MAX = 2 VALIDATOR_MIN_LIFETIME = 30 seconds 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, etc.
Top   ToC   RFC5533 - 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   ToC   RFC5533 - 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   ToC   RFC5533 - 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   ToC   RFC5533 - 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   ToC   RFC5533 - 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
      establishment.

   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   ToC   RFC5533 - 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   ToC   RFC5533 - 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 messages. 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   ToC   RFC5533 - 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 Protocol. 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   ToC   RFC5533 - 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
   follows:

              +---------+----------------------------------+
              |  Value  |        Verification Method       |
              +---------+----------------------------------+
              |    0    |             RESERVED             |
              |    1    |                CGA               |
              |    2    |                HBA               |
              |  3-200  | Allocated using Standards action |
              | 201-254 |       For Experimental use       |
              |   255   |             RESERVED             |
              +---------+----------------------------------+
Top   ToC   RFC5533 - 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   ToC   RFC5533 - 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   ToC   RFC5533 - Page 99
   [25]  Bonica, R., Gan, D., Tappan, D., and C. Pignataro, "Extended
         ICMP to Support Multi-Part Messages", RFC 4884, April 2007.
Top   ToC   RFC5533 - 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   ToC   RFC5533 - 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   ToC   RFC5533 - 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   ToC   RFC5533 - 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   ToC   RFC5533 - 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   ToC   RFC5533 - 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   ToC   RFC5533 - 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   ToC   RFC5533 - 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   ToC   RFC5533 - 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   ToC   RFC5533 - 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 works. 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   ToC   RFC5533 - 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 page on part 5)

Next Section