RFC 5533
Shim6: Level 3 Multihoming Shim Protocol for IPv6
Pages: 124
Proposed Standard
Proposed Standard
Part 4 of 5 – Pages 86 to 110
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
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.
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.
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
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
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.
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.
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.
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
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 |
+------------+-----------------------------------------------------+
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 |
+---------+----------------------------------+
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.
[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.
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
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.
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 | | +---------------------+---------------------------------------------+
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 | | +---------------------+---------------------------------------------+
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 | | +---------------------+---------------------------------------------+
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 | | +---------------------+---------------------------------------------+
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 ) | | +---------------------+---------------------------------------------+
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 | +---------------------+---------------------------------------------+
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
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-
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)