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 |
+------------+-----------------------------------------------------+
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
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 |
+---------------------+---------------------------------------------+
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.
