RFC 5534
Failure Detection and Locator Pair Exploration Protocol for IPv6 Multihoming
RFC 5534: Failure Detection and Locator Pair Exploration Protocol for IPv6 Multihoming 🦋
Okay bestie, this one is by J. Arkko (Ericsson) and I. van Beijnum (IMDEA Networks). It's a Standards Track document from June 2009, and the title block doesn't list anything it obsoletes or updates, so it's standing on its own. ✨ It's all about how Shim6 nodes notice when their connection path breaks and find a new working one. Main character energy 💅
Status of This Memo 📜
This document is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 💖 For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌈
Copyright Notice ©️
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. 🎀
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please read these carefully, because they spell out your rights and restrictions for this document 🫶
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without an adequate license from the person(s) controlling the copyright in those materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process. The one exception is formatting it for publication as an RFC or translating it into languages other than English 🌸
Abstract ✨
This document is about how the level 3 multihoming Shim6 protocol (Shim6) detects failures between two communicating nodes 🔥 It also covers an exploration protocol. If a failure happens and a working pair can be found, the nodes can switch to another pair of interfaces and/or addresses between the same two nodes 🦋
Table of Contents 🧚
1. Introduction ....................................................3
2. Requirements Language ...........................................4
3. Definitions .....................................................4
3.1. Available Addresses ........................................4
3.2. Locally Operational Addresses ..............................5
3.3. Operational Address Pairs ..................................5
3.4. Primary Address Pair .......................................7
3.5. Current Address Pair .......................................7
4. Protocol Overview ...............................................8
4.1. Failure Detection ..........................................8
4.2. Full Reachability Exploration .............................10
4.3. Exploration Order .........................................11
5. Protocol Definition ............................................13
5.1. Keepalive Message .........................................13
5.2. Probe Message .............................................14
5.3. Keepalive Timeout Option Format ...........................18
6. Behavior .......................................................19
6.1. Incoming Payload Packet ...................................20
6.2. Outgoing Payload Packet ...................................21
6.3. Keepalive Timeout .........................................21
6.4. Send Timeout ..............................................22
6.5. Retransmission ............................................22
6.6. Reception of the Keepalive Message ........................22
6.7. Reception of the Probe Message State=Exploring ............23
6.8. Reception of the Probe Message State=InboundOk ............23
6.9. Reception of the Probe Message State=Operational ..........23
6.10. Graphical Representation of the State Machine ............24
7. Protocol Constants and Variables ...............................24
8. Security Considerations ........................................25
9. Operational Considerations .....................................27
10. References ....................................................28
10.1. Normative References .....................................28
10.2. Informative References ...................................29
Appendix A. Example Protocol Runs..................................30
Appendix B. Contributors...........................................35
Appendix C. Acknowledgements.......................................351. Introduction 🌸
The Shim6 protocol [RFC5533] extends IPv6 to support multihoming 🌈 It's an IP-layer mechanism that hides multihoming from applications, so apps never have to know about it 🫶 Part of the Shim6 solution is noticing when the pair of addresses (or interfaces) currently in use between two communicating nodes has failed, and then picking another pair when that happens. We call the first part "failure detection" and the second part "locator pair exploration" 💖
This document specifies the mechanisms and protocol messages for both failure detection and locator pair exploration. This part of the Shim6 protocol is called the REAchability Protocol (REAP) 🦋
Failure detection is made as lightweight as possible ✨ Payload data traffic in both directions is observed. If the communication is idle and there is no traffic, failure detection is also idle and doesn't generate any packets 😴 When payload traffic is flowing in both directions, there's no need to send failure detection packets either 💅 Only when there is traffic in one direction does the failure detection mechanism generate keepalives in the other direction. So whenever there is outgoing traffic and no incoming return traffic or keepalives, there must be failure 😭 At that point, locator pair exploration is performed to find a working address pair for each direction 🔥
This document is structured as follows: Section 3 defines a set of useful terms, Section 4 gives an overview of REAP, and Section 5 provides a detailed definition. Section 6 specifies behavior, and Section 7 discusses protocol constants. Section 8 discusses the security considerations of REAP 🧚
In this specification, we consider an address to be synonymous with a locator 🎀 Other parts of the Shim6 protocol make sure the different locators used by a node actually belong together. That means REAP is not responsible for ensuring that said node ends up with a legitimate locator 🙈
REAP has been designed to be used with Shim6, so it's tailored to an environment where it typically runs on hosts, uses widely varying types of paths, and is unaware of application context. As a result, REAP tries to be as self-configuring and unobtrusive as possible 👑 In particular, it avoids sending any packets except where absolutely required, and it uses exponential back-off to avoid congestion 🍓 The downside is that it can't offer the same granularity of detecting problems as mechanisms that have more application context and the ability to negotiate or configure parameters. It's a tradeoff, but it's giving reliable and low-key 💜
Future versions of this specification may consider extensions with those capabilities, for instance by inheriting some mechanisms from the Bidirectional Forwarding Detection (BFD) protocol [BFD] 🦋
2. Requirements Language 📝
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] ✨
3. Definitions 📚
This section defines terms that are useful for talking about failure detection and locator pair exploration 🧠
3.1. Available Addresses 🏡
Shim6 nodes need to be aware of what addresses they themselves have 👀 If a node loses the address it's currently using for communications, another address must replace it. And if a node loses an address that the node's peer knows about, the peer must be informed 😭 Similarly, when a node acquires a new address, it may generally want the peer to know about it 💖
Definition. Available address: an address is said to be available if all the following conditions are fulfilled:
- The address has been assigned to an interface of the node.
- The valid lifetime of the prefix (Section 4.6.2 of RFC 4861 [RFC4861]) associated with the address has not expired.
- The address is not tentative in the sense of RFC 4862 [RFC4862]. In other words, the address assignment is complete so that communications can be started.
Note that this explicitly allows an address to be optimistic in the sense of Optimistic Duplicate Address Detection (DAD) [RFC4429], even though implementations may prefer using other addresses as long as there is an alternative 🙃
- The address is a global unicast or unique local address [RFC4193]. That is, it is not an IPv6 site-local or link-local address.
With link-local addresses, the nodes would be unable to determine on which link the given address is usable 🤔
- The address and interface are acceptable for use according to a local policy.
Available addresses are discovered and monitored through mechanisms outside the scope of Shim6 🔍 Shim6 implementations MUST be able to employ information provided by IPv6 Neighbor Discovery [RFC4861], Address Autoconfiguration [RFC4862], and DHCP [RFC3315] (when DHCP is implemented) 🫶 This information includes the availability of a new address and status changes of existing addresses, such as when an address becomes invalid 🥀
3.2. Locally Operational Addresses 🚦
Two different granularity levels are needed for failure detection ✨ The coarser granularity is for individual addresses 💅
Definition. Locally operational address: an available address is said to be locally operational when its use is known to be possible locally. In other words, the interface is up, a default router (if needed) suitable for this address is known to be reachable, and no other local information points to the address being unusable 🌈
Locally operational addresses are discovered and monitored through mechanisms outside the Shim6 protocol 🧚 Shim6 implementations MUST be able to employ information provided from Neighbor Unreachability Detection [RFC4861]. Implementations MAY also employ additional, link-layer-specific mechanisms 🎀
Note 1: A part of the problem in ensuring that an address is operational is making sure that after a change in link-layer connectivity, we are still connected to the same IP subnet. Mechanisms such as [DNA-SIM] can be used to ensure this. 🙈
Note 2: In theory, it would also be possible for nodes to learn about routing failures for a particular selected source prefix, if only suitable protocols for this purpose existed. Some proposals in this space have been made (see, for instance, [ADD-SEL] and [MULTI6]), but none have been standardized to date. 🍓
3.3. Operational Address Pairs ✨
okay so, having a locally operational address doesn't mean you can actually talk to your peer 😭 a routing hiccup can stop packets from ever reaching their destination 💀 which is why we need a second, finer level of granularity: address pairs 🎀
Definition. Bidirectionally operational address pair - a pair of locally operational addresses is an operational address pair when bidirectional connectivity can be shown between the addresses. That means a packet sent with one address in the Source field and the other in the Destination field reaches the destination, and vice versa. 💖
Unfortunately, bidirectionally operational address pairs don't always exist 🙈 ingress filtering or network failures can leave one address pair working in one direction while another pair works only the other way. The following definition covers this situation 🦋
Definition. Unidirectionally operational address pair - a pair of locally operational addresses is an unidirectionally operational address pair when packets sent with the first address as the source and the second address as the destination reach the destination. 🌸
Shim6 implementations MUST support the discovery of operational address pairs through the use of explicit reachability tests and Forced Bidirectional Communication (FBD), described later in this specification. ✨ Future extensions of Shim6 may specify additional mechanisms, and a few ideas for those are listed below, though they aren't fully specified in this document:
- Positive feedback from upper-layer protocols. For instance, TCP can tell the IP layer that it's making progress. This is kind of like how IPv6 Neighbor Unreachability Detection can, in some cases, be skipped when upper layers provide information about bidirectional connectivity [RFC4861]. 🧚
In the case of unidirectional connectivity, the upper-layer protocol responses come back using another address pair, but they show that the messages sent using the first address pair were received. 💜
- Negative feedback from upper-layer protocols. It's conceivable that upper-layer protocols signal a problem to the multihoming layer. For instance, TCP could indicate congestion or a lack of connectivity in the path because it isn't getting ACKs. 😬
- ICMP error messages. ICMP messages are super easy to spoof, so be careful not to trust them blindly 🙅♀️ One approach would be to use ICMP error messages only as a hint to perform an explicit reachability test, or to move an address pair to a lower place in the list of address pairs to be probed. Don't use these messages as a reason to disrupt ongoing communications without other indications of problems. The situation may be different when certain verifications of the ICMP messages are being performed, as explained by Gont in [GONT]. Those verifications can ensure that (practically) only on-path attackers can spoof the messages. 🔥
3.4. Primary Address Pair 🎀
The primary address pair is made up of the addresses that upper-layer protocols use when they interact with the Shim6 layer. Using the primary address pair means the communication is compatible with regular non-Shim6 communication, and no context tag needs to be present. 💅
3.5. Current Address Pair 🦋
Shim6 needs to avoid sending packets that belong to the same transport connection concurrently over multiple paths 🙅♀️ This is because congestion control in commonly used transport protocols is based on the idea of a single path. Routing can change paths too, and transport protocols have ways to cope with that, but frequent changes will cause problems. Effective congestion control over multiple paths was still considered a research topic when this document was published. So Shim6 doesn't try to use multiple paths at the same time. 🧠
Note: The Stream Control Transmission Protocol (SCTP) and future multipath transport protocols are likely to require interaction with Shim6, at least to make sure they don't employ Shim6 unexpectedly. 🫶
For these reasons, it's necessary to choose one particular pair of addresses as the current address pair, and to keep using it until problems occur, at least for the same session. 💖
It is theoretically possible to support multiple current address pairs for different transport sessions or Shim6 contexts. However, this is not supported in this version of the Shim6 protocol. 🙈
A current address pair doesn't need to be operational at all times. If there's no traffic to send, we might not know whether the current address pair is operational. Even so, it makes sense to assume that the address pair that worked previously keeps working for new communications too. ✨
4. Protocol Overview 👑
This section talks about the design of the reachability detection and full reachability exploration mechanisms, and gives an overview of the REAP protocol. 🌈
Exploring the full set of communication options between two nodes that both have two or more addresses is an expensive operation, because the number of combinations to explore grows really fast as the number of addresses goes up 😭 For instance, with two addresses on each side there are four possible address pairs. We can't assume that reachability in one direction automatically means reachability for the complementary pair in the other direction, so the total number of two-way combinations is eight: Combinations = nA * nB * 2. 🍓
An important observation in multihoming is that failures are relatively infrequent, so an operational pair that worked a few seconds ago is very likely to still be operational 🦋 So it makes sense to have a lightweight protocol that confirms existing reachability, and to only invoke the heavier exploration mechanism when there's a suspected failure. 💜
4.1. Failure Detection 🔍
okay so failure detection has three parts, bestie 💅: tracking local info, tracking what's going on with your peer, and then verifying reachability. Tracking local info means using stuff like reachability info about your own router as an input ✨. Nodes SHOULD employ the techniques in Sections 3.1 and 3.2 to keep tabs on the local situation. You also need to track the peer's address info, because if the peer's address in the current address pair is no longer locally operational, there has to be a way to tell them 🫶. The Update Request message in the Shim6 protocol handles that job [RFC5533]. Last but not least, when the local and remote info says communication should be possible and there are upper-layer packets waiting to go out, reachability verification is necessary to make sure the peers actually have an operational address pair 🔥.
A technique called Forced Bidirectional Detection (FBD) handles that reachability check 🦋. Reachability for the currently used address pair in a Shim6 context is determined by making sure that whenever there is payload traffic in one direction, there is also traffic in the other direction. That return traffic can be data traffic, or it may be transport-layer acknowledgments, or a REAP reachability keepalive if nothing else is flowing. So one-way traffic just stops being a thing 🙅♀️. If payload is going out and no packets are coming back, something is broken, and the full exploration mechanism kicks off 💀.
Here's the more detailed version of the pair-reachability evaluation mechanism 📝:
- To stop the other side from deciding there's a reachability failure, a node running the failure-detection mechanism needs to generate periodic keepalives when there is no other traffic 🌸.
FBD works by generating REAP keepalives if the node is receiving packets from its peer but not sending any of its own. The keepalives are sent at certain intervals so the other side knows there's a reachability problem when it doesn't receive any incoming packets for the duration of a Send Timeout period. The node tells its peer its Send Timeout value as a Keepalive Timeout Option (Section 5.3) in the I2, I2bis, R2, or UPDATE messages. The peer then maps that value to its own Keepalive Timeout value 🧚.
The interval after which keepalives are sent is named the Keepalive Interval. The RECOMMENDED approach is to send keepalives at one-half to one-third of the Keepalive Timeout interval, so that multiple keepalives get generated and have time to reach the peer before it times out 🍓.
- Whenever outgoing payload packets are generated, a timer starts to reflect the requirement that the peer should generate return traffic from payload packets. The timeout value is set to the value of Send Timeout ⏱️.
For the purposes of this specification, "payload packet" refers to any packet that is part of a Shim6 context, including both upper-layer protocol packets and Shim6 protocol messages, except those defined in this specification. For the latter messages, Section 6 explains what happens to the timers when a message is transmitted or received 📖.
- Whenever incoming payload packets are received, the timer associated with the return traffic from the peer is stopped, and another timer starts to reflect the requirement for this node to generate return traffic. This timeout value is set to the value of Keepalive Timeout 💜.
These two timers are mutually exclusive. In other words, either the node is expecting to see traffic from the peer based on the traffic it sent earlier, or the node is expecting to respond to the peer based on the traffic the peer sent earlier. (Otherwise, the node is in an idle state 😴.)
- The reception of a REAP Keepalive message leads to stopping the timer associated with the return traffic from the peer ✅.
- Keepalive Interval seconds after the last payload packet has been received for a context, if no other packet has been sent within this context since that payload packet was received, a REAP Keepalive message is generated for the context in question and transmitted to the peer. A node may send the keepalive sooner than Keepalive Interval seconds if implementation considerations warrant it, but should take care to avoid sending keepalives at an excessive rate 🙈. REAP Keepalive messages SHOULD continue to be sent at the Keepalive Interval until either a payload packet in the Shim6 context has been received from the peer or the Keepalive Timeout expires. Keepalives are not sent at all if one or more payload packets were sent within the Keepalive Interval 🎀.
- Send Timeout seconds after the transmission of a payload packet with no return traffic on this context, a full reachability exploration is started 🚨.
Section 7 provides some suggested defaults for these timeout values. The actual value SHOULD be randomized in order to prevent synchronization 🌈. Experience from deploying the Shim6 protocol is needed to figure out which values are most suitable 🔮.
4.2. Full Reachability Exploration 🗺️
As we've covered, the currently used address pair can become invalid. Either one of the addresses becomes unavailable or nonoperational, or the pair itself gets declared nonoperational 😭. An exploration process then tries to find another operational pair so communications can resume 💖.
What makes this process hard is the requirement to support unidirectionally operational address pairs 🙃. It's not enough to probe address pairs with a simple request-response protocol. Instead, the party that first detects the problem starts a process where it tries each of the different address pairs in turn by sending a message to its peer. These messages carry info about the state of connectivity between the peers, like whether the sender has seen any traffic from the peer recently. When the peer gets a message that signals a problem, it helps out by starting its own parallel exploration in the other direction, again sending info about recently received payload traffic or signaling messages 👑.
Specifically, when A decides it needs to explore for an alternative address pair to B, it initiates a set of Probe messages, in sequence, until it gets a Probe message from B indicating that (a) B has received one of A's messages and, obviously, (b) B's Probe message gets back to A. B uses the same algorithm, but starts the process from the reception of the first Probe message from A 🧚♀️.
Upon changing to a new address pair, the network path traversed most likely has changed, so the upper-layer protocol (ULP) SHOULD be informed 🛣️. This can be a signal for the ULP to adapt to the change in path. For example, if the ULP is TCP, it could initiate a slow start procedure. However, the circumstances that led to picking a new path have probably already caused enough packet loss to trigger slow start anyway 🥹.
REAP is designed to support failure recovery even when you only have unidirectionally operational address pairs ✨. However, because of the security concerns discussed in Section 8, the exploration process can typically only run for a session that has already been established 🔐. Specifically, while REAP would in theory be capable of exploration even during connection establishment, its use within the Shim6 protocol does not allow this 🙅♀️💅.
4.3. Exploration Order ✨
okay so exploration needs a way to pick which address pairs to test first, and REAP has a whole process for it 🧚 here's how it goes:
- 🌸 To start, the node knows its own addresses, and Shim6 protocol messages have told it what the peer's addresses are. Put those two lists together and you get a list of possible address pairs.
- 💅 Standard IPv6 address selection rules then prune that list by tossing out combos that don't make sense. For example, trying a link-local address when the peer uses a global unicast address is a no-go.
- 🦋 The same IPv6 address selection rules also give a basic priority order for the pairs that are left.
- 🎀 Local preferences can tune that order a bit more. How those preferences get set isn't specified, but it could be something like config saying you prefer one interface over another.
- 👑 So in the end the node has a prioritized list of pairs to try. The list can still be super long, though, because if there are lots of addresses on both sides you get a combinatorial explosion 💀 REAP tries the pairs one at a time and uses a back-off procedure so it doesn't cause a "signaling storm". This keeps exploration relatively conservative, or "safe". The tradeoff is that finding a working path can take a while when there are many addresses on both sides.
In more detail, nodes first check the RFC 3484 default address selection rules [RFC3484] to see which combinations of addresses are allowed from their own point of view. This shrinks the search space, which is very healthy. RFC 3484 also gives a priority ordering among the different address pairs, which might make the search faster. (More mechanisms may be defined later for getting an initial ordering of address pairs before testing starts [PAIR].) Nodes can also use local info, like known quality of service parameters or interface types, to decide which addresses they like better, and then try the pairs with those addresses first. The Shim6 protocol carries preference information in its messages too, so that's another source of input 🌈
Out of the candidate address pairs, nodes SHOULD try testing through all of them until they find an operational pair, and retry the process as necessary. But all nodes MUST do this sequentially and with exponential back-off 😭 Going one at a time is what prevents a "signaling storm" when an outage hits, especially for a complete site. The catch is that it also limits how many addresses can really be used for multihoming, since transport- and application-layer protocols will fail if switching to a new address pair takes too long.
Section 7 suggests default values for the timers used in exploration. The Initial Probe Timeout (0.5 seconds) is the interval between the initial attempts to send probes. The Number of Initial Probes (4) is how many initial probes can go out before the exponential back-off has to kick in. After that, the time between probes keeps growing if there's no response. Usually each increase doubles the time, but this specification doesn't require any particular increase, so that part is flexible 🧁
Note: The reason for sending four packets at a fixed rate before the exponential back-off kicks in is to avoid sending them excessively fast. Without this, having 0.5 seconds between the third and fourth probe would mean the time between the first and second probe had to be 0.125 seconds, which leaves very little time for a reply to the first packet to arrive. Also, the first four packets would go out within 0.875 seconds instead of 2 seconds, which raises the chance of congestion if a large number of Shim6 contexts need to send probes at the same time after a failure 😤
Finally, the Max Probe Timeout (60 seconds) is a limit that the probe interval isn't allowed to grow past. If exploration reaches this interval, it keeps sending at this rate until a suitable response gets triggered, or until the Shim6 context is garbage collected because the upper-layer protocols using that context aren't trying to send packets anymore. Hitting the Max Probe Timeout may also be a hint to the garbage collection process that the context is no longer usable 🫶
5. Protocol Definition 💌
5.1. Keepalive Message
Okay bestie, here's what a Keepalive message looks like on the wire 👀
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len |0| Type = 66 | Reserved1 |0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum |R| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Receiver Context Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Options +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Here's the field breakdown, it's giving very organized 💖
Next Header,Hdr Ext Len,0,0,Checksum: these are as specified in Section 5.3 of the Shim6 protocol description [RFC5533].Type: this field identifies the Keepalive message and MUST be set to66(Keepalive).Reserved1: this is a 7-bit field reserved for future use. It is set to zero on transmit and MUST be ignored on receipt.R: this is a 1-bit field reserved for future use. It is set to zero on transmit and MUST be ignored on receipt.Receiver Context Tag: this is a 47-bit field for the context tag that the receiver has allocated for the context.Reserved2: this is a 32-bit field reserved for future use. It is set to zero on transmit and MUST be ignored on receipt.Options: this field MAY contain one or more Shim6 options. However, there are currently no defined options that are useful in a Keepalive message. TheOptionsfield is provided only for future extensibility reasons.
A valid message conforms to the format above, has a Receiver Context Tag that matches the context known by the receiver, is a valid Shim6 control message as defined in Section 12.3 of the Shim6 protocol description [RFC5533], and has a Shim6 context that is in state ESTABLISHED. The receiver processes a valid message by inspecting its options and executing any actions specified for such options 🧚
The processing rules for this message are given in more detail in Section 6 💜
5.2. Probe Message ✨
okay bestie, this message is how REAP explores the network 🔍🦋 It's the one doing the detective work, so it's kind of the main character of this section 💅
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len |0| Type = 67 | Reserved |0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum |R| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Receiver Context Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Precvd| Psent |Sta| Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ First probe sent +
| |
+ Source address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ First probe sent +
| |
+ Destination address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| First Probe Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| First Probe Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ /
/ Nth probe sent /
| |
+ Source address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Nth probe sent +
| |
+ Destination address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nth Probe Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nth Probe Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ First probe received +
| |
+ Source address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ First probe received +
| |
+ Destination address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| First Probe Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| First Probe Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Nth probe received +
| |
+ Source address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Nth probe received +
| |
+ Destination address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nth Probe Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nth Probe Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Options //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Next Header, Hdr Ext Len, 0, 0, Checksum These are as specified in Section 5.3 of the Shim6 protocol description [RFC5533]. 🫶
Type This field identifies the Probe message and MUST be set to 67 (Probe). 🎀
Reserved This is a 7-bit field reserved for future use. It is set to zero on transmit and MUST be ignored on receipt. 🌸
R This is a 1-bit field reserved for future use. It is set to zero on transmit and MUST be ignored on receipt. 🌸
Receiver Context Tag This is a 47-bit field for the context tag that the receiver has allocated for the context. 🧚
Psent This is a 4-bit field that indicates the number of sent probes included in this Probe message. The first set of Probe fields pertains to the current message and MUST be present, so the minimum value for this field is 1. Additional sent Probe fields are copies of the same fields sent in (recent) earlier probes and may be included or omitted as per any logic employed by the implementation. 💜
Precvd This is a 4-bit field that indicates the number of received probes included in this Probe message. Received Probe fields are copies of the same fields in earlier received probes that arrived since the last transition to state Exploring. When a sender is in state InboundOk it MUST include copies of the fields of at least one of the inbound probes. A sender MAY include additional sets of these received Probe fields in any state as per any logic employed by the implementation.
The fields Probe Source, Probe Destination, Probe Nonce, and Probe Data may be repeated, depending on the value of Psent and Preceived. 🔥
Sta (State) This 2-bit State field is used to inform the peer about the state of the sender. It has three legal values:
0 (Operational) implies that the sender both (a) believes it has no problem communicating and (b) believes that the recipient also has no problem communicating. ✨
1 (Exploring) implies that the sender has a problem communicating with the recipient, e.g., it has not seen any traffic from the recipient even when it expected some. 😭
2 (InboundOk) implies that the sender believes it has no problem communicating, i.e., it at least sees packets from the recipient but that the recipient either has a problem or has not yet confirmed to the sender that the problem has been resolved. 🌈
Reserved2 MUST be set to zero upon transmission and MUST be ignored upon reception. 🍓
Probe Source This 128-bit field contains the source IPv6 address used to send the probe. 🦋
Probe Destination This 128-bit field contains the destination IPv6 address used to send the probe. 🦋
Probe Nonce This is a 32-bit field that is initialized by the sender with a value that allows it to determine with which sent probes a received probe correlates. It is highly RECOMMENDED that the Nonce field be at least moderately hard to guess so that even on-path attackers can't deduce the next nonce value that will be used. This value SHOULD be generated using a random number generator that is known to have good randomness properties as outlined in RFC 4086 [RFC4086]. 🔐💀
Probe Data This is a 32-bit field with no fixed meaning. The Probe Data field is copied back with no changes. Future flags may define a use for this field. ⭐
Options For future extensions. 🌈
5.3. Keepalive Timeout Option Format 💖
okay so either side of a Shim6 context can tell its peer what Keepalive Timeout value it would like the peer to use 🫶 If the node is using a non-default Send Timeout value, it MUST communicate this value as a Keepalive Timeout value to the peer in the below option. This option MAY be sent in the I2, I2bis, R2, or UPDATE messages. The option SHOULD only need to be sent once in a given Shim6 association. If a node receives this option, it SHOULD update its Keepalive Timeout value for the peer. 🎀
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 10 |0| Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Reserved | Keepalive Timeout |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Fields:
Type This field identifies the option and MUST be set to 10 (Keepalive Timeout). 🌸
Length This field MUST be set as specified in Section 5.1 of the Shim6 protocol description [RFC5533] -- that is, set to 4. 🍓
Reserved A 16-bit field reserved for future use. It is set to zero upon transmit and MUST be ignored upon receipt. 🧚
Keepalive Timeout The value in seconds corresponding to the suggested Keepalive Timeout value for the peer. 👑
6. Behavior ✨
okay bestie, this is the part where the REAP nodes get their whole personality 💅. The required behavior is written as a state machine, and the thing you can see from the outside has to MUST conform to it 🔥. The implementation doesn't have to actually use a state machine internally, though. We also get a tabular version of the state machine mixed in, but that table is just informational, so it's more of a cheat sheet 🌸.
Each node can be in one of three states with a given peer: Operational, Exploring, or InboundOK 🦋. In Operational, the address pairs are assumed to be working, so we're all good ✨. In Exploring, the node hasn't heard anything from the peer for longer than a Send Timer period, so it's lowkey worried 😭. In InboundOK, the node is getting traffic from the peer, but the peer might not be seeing any traffic from this node yet, so the exploration has to keep going 🧚.
The node also keeps two timers: the Send Timer (Send Timeout seconds) and the Keepalive Timer (Keepalive Timeout seconds) ⏰. The Send Timer is about the vibe check on outgoing traffic. When this node sends a payload packet, it should get some return traffic (payload packets or Keepalive messages) within Send Timeout seconds 💜. The Keepalive Timer is the mirror of that. When this node receives a payload packet, there should be a similar response going back to the peer 🫶. The Keepalive Timer only runs in Operational, and the Send Timer runs in Operational and InboundOK 🎀. Nothing runs in Exploring 🙈. Also, the two timers are mutually exclusive (see Section 4.1), so either one is running or neither is, but never both 💖.
Appendix A has examples of typical protocol runs if you want to see this in action 🍓.
6.1. Incoming Payload Packet
So when a payload packet shows up while the node is Operational, the node starts the Keepalive Timer if it isn't already going, and stops the Send Timer if it's running 🌈.
If the node is Exploring, it switches to InboundOK, sends a Probe message, and starts the Send Timer 🚀. The Probe message gets filled up with the Psent fields (plus the matching Probe Source Address, Probe Destination Address, Probe Nonce, and Probe Data) describing recent Probe messages that the peer hasn't reported seeing yet 👀. It also fills the Precvd fields (with the same matching Probe Source Address, Probe Destination Address, Probe Nonce, and Probe Data) describing the recent Probe messages the node has received from the peer 💅. The State field MUST be set to a value that matches the sender's conceptual state after sending the Probe, so here the node puts 2 (InboundOk) in there 🧚. The IP source and destination addresses for the Probe get picked the way Section 4.3 describes ✨.
In InboundOK, the node stops the Send Timer if it's running, and that's literally it, nothing else happens 😌.
Shim6 control messages other than Keepalive and Probe messages get treated the same way as payload packets when they're received 🎀.
While the Keepalive Timer is running, the node SHOULD send Keepalive messages to the peer every Keepalive Interval seconds 🫧. There's conceptually a separate timer for that interval, separate from the overall Keepalive Timeout, but it doesn't show up in the tables or the diagrams 🙈. The Keepalive message gets built the way Section 5.1 says, and it goes out using the current address pair 💖.
Quick decoder ring for the tables 🔑: "START", "RESTART", and "STOP" are about the Keepalive Timer or the Send Timer, "GOTO" is changing state, "SEND" is sending a message, and "-" means do absolutely nothing 💀.
Operational Exploring InboundOk
--------------------------------------------------------------------
STOP Send SEND Probe InboundOk STOP Send
START Keepalive START Send
GOTO InboundOk6.2. Outgoing Payload Packet
When the node sends a payload packet while Operational, it stops the Keepalive Timer if it's going and starts the Send Timer if it isn't already 🚀. Exploring doesn't change anything here 🙃. In InboundOK, the node just starts the Send Timer if it's not running yet 💜. (Sending Shim6 control messages is treated the exact same way 🎀.)
Operational Exploring InboundOk
------------------------------------------------------------------
START Send - START Send
STOP Keepalive6.3. Keepalive Timeout
When the Keepalive Timer times out, the node sends one last Keepalive message 👋. This can only happen in Operational 🥹.
That Keepalive message is built as described in Section 5.1 and goes out over the current address pair 🌸.
Operational Exploring InboundOk
------------------------------------------------------------------
SEND Keepalive - -6.4. Send Timeout
When the Send Timer times out, the node moves into Exploring and sends a Probe message 😱. That Probe is built the way Section 6.1 explains, except the State field gets set to 1 (Exploring) 🔍.
Operational Exploring InboundOk
------------------------------------------------------------------
SEND Probe Exploring - SEND Probe Exploring
GOTO Exploring GOTO Exploring6.5. Retransmission
While the node is Exploring, it keeps retransmitting its Probe messages to different addresses, or even the same ones, following Section 4.3 🔁. InboundOK does something similar, with one twist: when it retransmits, the Send Timer gets started if it wasn't running already ⏰.
Probes are built as explained in Section 6.1, except the State field is 1 (Exploring) or 2 (InboundOk), depending on which state the sender is in 💅.
Operational Exploring InboundOk
-----------------------------------------------------------------
- SEND Probe Exploring SEND Probe InboundOk
START Send6.6. Reception of the Keepalive Message
When a Keepalive message arrives while Operational, the node stops the Send Timer if it's running 💖. If the node is Exploring, it switches to InboundOK, sends a Probe message, and starts the Send Timer 🦋. That Probe is built as explained in Section 6.1 ✨.
In InboundOK, the Send Timer gets stopped if it was running 🫶.
Operational Exploring InboundOk
------------------------------------------------------------------
STOP Send SEND Probe InboundOk STOP Send
START Send
GOTO InboundOk6.7. Reception of the Probe Message State=Exploring
When a Probe comes in with State set to Exploring, the node moves into InboundOK, sends a Probe as described in Section 6.1, stops the Keepalive Timer if it's running, and restarts the Send Timer 🎀.
Operational Exploring InboundOk
------------------------------------------------------------------
SEND Probe InboundOk SEND Probe InboundOk SEND Probe InboundOk
STOP Keepalive START Send RESTART Send
RESTART Send GOTO InboundOk
GOTO InboundOk6.8. Reception of the Probe Message State=InboundOk
When a Probe with State set to InboundOk arrives, the node sends a Probe, restarts the Send Timer, stops the Keepalive Timer if it's running, and moves into Operational 👑. A new current address pair gets picked for the connection based on the probe reports in the message we just got 🔥. If the message doesn't report any received probes, the current address pair just stays the same 🙈.
That Probe is built as explained in Section 6.1, except the State field is set to zero (Operational) 🌈.
Operational Exploring InboundOk
--------------------------------------------------------------------
SEND Probe Operational SEND Probe Operational SEND Probe Operational
RESTART Send RESTART Send RESTART Send
STOP Keepalive GOTO Operational GOTO Operational6.9. Reception of the Probe Message State=Operational
When a Probe with State set to Operational shows up, the node stops the Send Timer if it's running, starts the Keepalive Timer if it isn't already, and moves into Operational 🥳. That Probe is built as explained in Section 6.1, except the State field is set to zero (Operational) ✨.
Note: This ends the exploration process once both parties are happy and both know the other one is happy too 💖.
Operational Exploring InboundOk
------------------------------------------------------------------
STOP Send STOP Send STOP Send
START Keepalive START Keepalive START Keepalive
GOTO Operational GOTO OperationalAlso, the reachability detection and exploration process doesn't affect payload communications until a new operational address pair has actually been confirmed 🔒. Until then, payload packets keep going to the addresses that were already in use 🫶.
6.10. Graphical Representation of the State Machine
The PDF version of this specification has an informational drawing of the state machine 🎨. If the text and the drawing ever disagree, the text wins 👑.
Okay that's the whole behavior section, we're in the big leagues now!! 🌈✨
7. Protocol Constants and Variables ✨
okay so this section is where all the magic numbers live 🧚 first up, the protocol constants, which are fixed:
Initial Probe Timeout 0.5 seconds
Number of Initial Probes 4 probesand then these variables come with default values, and they're giving main character energy 💅
Send Timeout 15 seconds
Keepalive Timeout X seconds, where X is the peer's
Send Timeout as communicated in
the Keepalive Timeout Option
15 seconds if the peer didn't send
a Keepalive Timeout option
Keepalive Interval Y seconds, where Y is one-third to
one-half of the Keepalive Timeout
value (see Section 4.1)Now, a node is allowed to pick its own alternate values of the Send Timeout and tell its peer about them in the Keepalive Timeout Option 🎀 but bestie, be careful with tiny values. A very small Send Timeout can make it hard to swap keepalives over a path with a long roundtrip delay 😭 It can also make Shim6 react to temporary failures more often than it needs to, which is not the vibe. So it is RECOMMENDED that an alternate Send Timeout value not be under 10 seconds 🫶 Going higher than that is also possible, but Send Timeout and REAP's ability to find and fix errors in the communication path are connected, so keep that in mind 🦋 Either way, Shim6 only really helps if it spots and fixes communication problems long before the upper layers give up ✨ That's why it is RECOMMENDED that Send Timeout be at most 100 seconds (default TCP R2 timeout [RFC1122]).
Note: It is not expected that the Send Timeout or other values will be estimated based on experienced roundtrip times. Signaling exchanges are performed based on exponential back-off. The keepalive processes send packets only in the relatively rare condition that all traffic is unidirectional.
8. Security Considerations 🔥
okay bestie, this part is serious, so let's get into it 🙈 Attackers can spoof all kinds of indications from the lower layers and from the network, trying to confuse the peers about which addresses are or aren't working. For example, an attacker can spoof ICMP error messages to get the parties to move their traffic somewhere else, or even to disconnect 💀 Attackers can also spoof info about network attachments, Router Discovery, and address assignments, so the parties think they have Internet connectivity when they actually don't.
That can lead to use of non-preferred addresses, or even denial of service 😭
This protocol doesn't protect its own indications from other parts of the protocol stack. Unprotected indications SHOULD NOT be taken as proof of connectivity problems. That said, REAP is somewhat resistant to incorrect info even from unprotected indications, because it runs its own tests before it picks a new address pair 🛡️ Denial-of-service vulnerabilities still exist, though, and so do vulnerabilities against on-path attackers.
Some of these problems can be eased with techniques specific to the other parts of the stack, like properly dealing with ICMP errors [GONT], link-layer security, or using SEND [RFC3971] to protect IPv6 Router and Neighbor Discovery 🔐
Other parts of the Shim6 protocol make sure the set of addresses we switch between actually belong together. REAP itself gives no such guarantee 👀 REAP does give some protection against third-party flooding attacks [AURA02], though. When REAP runs, its Probe Nonces can be used as a return routability check that the claimed address really is willing to receive traffic. But that has to be paired with another mechanism to confirm the claimed address is also the correct node. Shim6 handles that by binding all operations to context tags 🎀
The keepalive mechanism in this specification is vulnerable to spoofing. On-path attackers who can see a Shim6 context tag can send spoofed Keepalive messages once per Send Timeout interval, which stops the two Shim6 nodes from sending Keepalives themselves 😤 This is only relevant to nodes involved in one-way communication. The result is that the nodes enter the exploration phase for no reason, though they should still be able to confirm connectivity unless the attacker can stop the exploration phase from finishing. Off-path attackers probably can't generate spoofed results, since the context tags are 47-bit random numbers 🌈
To protect against spoofed Keepalive messages, a node implementing both Shim6 and IPsec MAY ignore incoming REAP keepalives if it has good reason to assume the other side will be sending IPsec-protected return traffic. In other words, if a node is sending TCP payload data, it can reasonably expect TCP ACKs back. If no IPsec-protected ACKs come back but unprotected keepalives do, that could mean an attacker is trying to hide broken connectivity 👀🚨
The exploration phase is vulnerable to attackers on the path. Off-path attackers would find it hard to guess either the context tag or the correct probe identifiers. Since IPsec operates above the Shim6 layer, IPsec can't protect the exploration phase against on-path attackers. This is similar to the issues with protecting other Shim6 control exchanges. There are mechanisms in place to stop communications from being redirected to the wrong addresses, but on-path attackers can still cause denial-of-service, move communications to less-preferred address pairs, and so on 😩
Last but definitely not least, the exploration itself can cause a bunch of packets to be sent. So it could be used as a tool for packet amplification in flooding attacks 💥 It is required that the protocol employing REAP has built-in mechanisms to prevent this. For instance, Shim6 contexts are only created after a relatively large number of packets have been exchanged, and that cost makes using Shim6 and REAP for amplification attacks less appealing. However, those protections typically aren't present at connection-establishment time. When exploration would be needed for connection establishment to succeed, using it would create an amplification vulnerability. Because of that, Shim6 does not support using REAP in the connection-establishment stage 🙅♀️
9. Operational Considerations 🌸
okay, the good news is that when nothing is failing, the failure-detection mechanism (and Shim6 in general) is super lightweight 🍓 Keepalives aren't sent when a Shim6 context is idle or when there's traffic in both directions. So in normal TCP or TCP-like operations, you'd only see one or two keepalives when a session goes from active to idle ✨
Things only get busy when there are failures, especially when a link that's shared by lots of active sessions and multiple nodes goes down 😱 When that happens, one keepalive gets sent, followed by a series of probes. This happens per active (traffic-generating) context, and they all time out within 15 seconds after the failure. That makes the peak traffic Shim6 generates after a failure about one packet per second per context. The sessions running over those contexts were probably sending at least that much traffic, and most likely more. So if the backup path has a lot lower bandwidth than the failed path, this could lead to temporary congestion 🚦
However, note that in the case of multihoming using BGP, if the failover is fast enough that TCP doesn't go into slow start, the full payload data traffic that flows over the failed path is switched over to the backup path. If this backup path has lower capacity, there will be even more congestion 😬
Even though the failure detection probing doesn't do congestion control as such, the exponential back-off makes sure the number of packets sent quickly goes down. Eventually it reaches one per context per minute, which should be conservative enough even on the lowest bandwidth links 🐢
Section 7 specifies a number of protocol parameters. Tuning these parameters, and others that aren't mandated in this specification, may affect these properties. It's expected that further revisions of this specification will add more info once enough deployment experience has come in from different environments 📚
Implementations may provide ways to monitor their performance and send alarms about problems. Standardizing those is, however, the subject of future specifications 🔔 In general, Shim6 is most applicable for small sites and nodes, and monitoring requirements on those deployments are expected to be pretty modest. Either way, where the node is associated with a management system, it is RECOMMENDED that detected failures and failover events are reported via asynchronous notifications to the management system 📨 Similarly, where logging mechanisms are available on the node, these events should be recorded in event logs 📝
Shim6 uses the same header for both signaling and encapsulating payload packets after a rehoming event. This way, fate is shared between the two types of packets. So the situation where reachability probes or keepalives get through but payload packets don't is mostly avoided 🫶 Either all Shim6 packets make it through, so Shim6 works as intended, or none do, and no Shim6 state gets negotiated. Even when some packets make it through and others don't, Shim6 will generally either work as intended or provide a service that's no worse than without Shim6, apart from maybe generating a small amount of signaling traffic 💖
Sometimes payload packets (and possibly payload packets encapsulated in the Shim6 header) don't make it through, but signaling and keepalives do. This can happen when there's a path MTU discovery black hole on one of the paths 🕳️ If only large packets are sent at some point, reachability exploration will be turned on and REAP will likely select another path. That path may or may not be affected by the PMTUD black hole 🦋
10. References 📚
10.1. Normative References 📚✨
okay so these are the docs this spec literally can't function without, bestie 🫶 you need to read them to fully get what's going on
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
- [RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
- [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
- [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005.
- [RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) for IPv6", RFC 4429, April 2006.
- [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
- [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
- [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming Shim Protocol for IPv6", RFC 5533, June 2009.
10.2. Informative References 🌸
these ones are the extra reading, the "ooh tell me more" section 🤓 they're not required to get the spec, but they're so good for going deeper
- [ADD-SEL] Bagnulo, M., "Address selection in multihomed environments", Work in Progress, October 2005.
- [AURA02] Aura, T., Roe, M., and J. Arkko, "Security of Internet Location Management", Proceedings of the 18th Annual Computer Security Applications Conference, Las Vegas, Nevada, USA, December 2002.
- [BFD] Katz, D. and D. Ward, "Bidirectional Forwarding Detection", Work in Progress, February 2009.
- [DNA-SIM] Krishnan, S. and G. Daley, "Simple procedures for Detecting Network Attachment in IPv6", Work in Progress, February 2009.
- [GONT] Gont, F., "ICMP attacks against TCP", Work in Progress, October 2008.
- [MULTI6] Huitema, C., "Address selection in multihomed environments", Work in Progress, October 2004.
- [PAIR] Bagnulo, M., "Default Locator-pair selection algorithm for the Shim6 protocol", Work in Progress, October 2008.
- [RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
- [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
- [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
- [RFC5206] Nikander, P., Henderson, T., Vogt, C., and J. Arkko, "End-Host Mobility and Multihoming with the Host Identity Protocol", RFC 5206, April 2008.
Appendix A. Example Protocol Runs 🦋✨
okay bestie, this appendix is the fun part 💖 It's a bunch of example REAP protocol runs showing what actually happens in typical scenarios. We start super simple, then work up to the messy failure stuff where things break and the nodes have to figure it out 🫶
Example 1 is two nodes, A and B, that have a Shim6 connection with each other but aren't sending any payload data right now. Since neither side is sending anything, they also don't expect anything back. So there are literally no messages 🙈 😌
EXAMPLE 1: No Communications
Peer A Peer B
| |
| |
| |
| |
| |
| |
| |
| |Example 2 is an active connection with payload packets flowing both ways. Here, getting payload data from the peer already counts as proof that it's reachable, so again there are no extra packets needed. Iconic, no notes 💅
EXAMPLE 2: Bidirectional Communications
Peer A Peer B
| |
| payload packet |
|-------------------------------------------->|
| |
| payload packet |
|<--------------------------------------------|
| |
| payload packet |
|-------------------------------------------->|
| |
| |Example 3 is the first one with an actual REAP message in it 👀 The nodes only talk in one direction here, so REAP messages are needed to let the peer that's sending payload packets know that its packets are getting through. It's giving "I need confirmation, pls" energy 🥹
EXAMPLE 3: Unidirectional Communications
Peer A Peer B
| |
| payload packet |
|-------------------------------------------->|
| |
| payload packet |
|-------------------------------------------->|
| |
| payload packet |
|-------------------------------------------->|
| |
| Keepalive Nonce=p |
|<--------------------------------------------|
| |
| payload packet |
|-------------------------------------------->|
| |
| |Example 4 is the failure scenario, and it's giving drama 😭🔥 Here, A has address A and B has addresses B1 and B2. The address pairs in use are (A, B1) and (B1, A). Then all connections via B1 break, which kicks off an exploration process. Watch B freak out and then find a new path 💀
EXAMPLE 4: Failure Scenario
Peer A Peer B
| |
State: | State:
Operational | Operational
| (A,B1) payload packet |
|-------------------------------------------->|
| |
| (B1,A) payload packet |
|<--------------------------------------------| At time T1
| | path A<->B1
| (A,B1) payload packet | becomes
|----------------------------------------/ | broken.
| |
| ( B1,A) payload packet |
| /-----------------------------------------|
| |
| (A,B1) payload packet |
|----------------------------------------/ |
| |
| (B1,A) payload packet |
| /-----------------------------------------|
| |
| (A,B1) payload packet |
|----------------------------------------/ |
| |
| | Send Timeout
| | seconds after
| | T1, B happens to
| | see the problem
| (B1,A) Probe Nonce=p, | first and sends a
| state=exploring | complaint that
| /-----------------------------------------| it is not
| | receiving
| | anything.
| | State:
| | Exploring
| |
| (B2,A) Probe Nonce=q, |
| state=exploring | But it's lost,
|<--------------------------------------------| retransmission
| | uses another pair
A realizes |
that it needs |
to start the |
exploration. |
It picks B2 as the |
most likely candidate, |
as it appeared in the |
Probe. |
State: InboundOk |
| |
| (A, B2) Probe Nonce=r, |
| state=inboundok, |
| received probe q | This one gets
|-------------------------------------------->| through.
| | State:
| | Operational
| (B2,A) Probe Nonce=s, |
| state=operational, | B now knows
| received probe r | that A has no
|<--------------------------------------------| problem receiving
| | its packets.
State: Operational |
| |
| (A,B2) payload packet |
|-------------------------------------------->| Payload packets
| | flow again.
| (B2,A) payload packet |
|<--------------------------------------------|Example 5 is the one-way failure case 🫠 This time the failure only goes in one direction. A has addresses A1 and A2, B has addresses B1 and B2, and the current chat is between A1 and B1. But A's packets stop reaching B on that pair. Not fair, but we fix it 💪
EXAMPLE 5: One-Way Failure
Peer A Peer B
| |
State: | State:
Operational | Operational
| |
| (A1,B1) payload packet |
|-------------------------------------------->|
| |
| (B1,A1) payload packet |
|<--------------------------------------------|
| |
| (A1,B1) payload packet | At time T1
|----------------------------------------/ | path A1->B1
| | becomes
| | broken.
| (B1,A1) payload packet |
|<--------------------------------------------|
| |
| (A1,B1) payload packet |
|----------------------------------------/ |
| |
| (B1,A1) payload packet |
|<--------------------------------------------|
| |
| (A1,B1) payload packet |
|----------------------------------------/ |
| |
| | Send Timeout
| | seconds after
| | T1, B notices
| | the problem and
| (B1,A1) Probe Nonce=p, | sends a
| state=exploring | complaint that
|<--------------------------------------------| it is not
| | receiving
| | anything.
A responds. | State: Exploring
State: InboundOk |
| |
| (A1, B1) Probe Nonce=q, |
| state=inboundok, |
| received probe p |
|----------------------------------------/ | A's response
| | is lost.
| (B2,A2) Probe Nonce=r, |
| state=exploring | Next, try a different
|<--------------------------------------------| locator pair.
| |
| (A2, B2) Probe Nonce=s, |
| state=inboundok, |
| received probes p, r | This one gets
|-------------------------------------------->| through.
| | State: Operational
| |
| | B now knows
| | that A has no
| (B2,A2) Probe Nonce=t, | problem receiving
| state=operational, | its packets and
| received probe s | that A's probe
|<--------------------------------------------| gets to B. It
| | sends a
State: Operational | confirmation to A.
| |
| (A2,B2) payload packet |
|-------------------------------------------->| Payload packets
| | flow again.
| (B1,A1) payload packet |
|<--------------------------------------------|Appendix B. Contributors ✨
okay so this one is basically the group chat credits 🎀 the people who threw ideas around for the whole thing, plus the vibes from related work that the spec is super grateful for. MULTI6 WG design team members Marcelo Bagnulo Braun, Erik Nordmark, Geoff Huston, Kurtis Lindqvist, Margaret Wasserman, and Jukka Ylitalo 🫶 MOBIKE WG contributors Pasi Eronen, Tero Kivinen, Francis Dupont, Spencer Dawkins, and James Kempf 💅 and HIP WG contributors like Pekka Nikander 🌸 all of these folks shaped the thinking, even the unpublished bits 😭
the doc also says it owes a lot to SCTP [RFC4960] 🦋 and the Host Identity Protocol (HIP) multihoming and mobility extension [RFC5206] 💜 so iconic of them to credit the work that came before 👑
Appendix C. Acknowledgements 🌈
the authors wanna give a big shoutout to Christian Huitema, Pekka Savola, John Loughney, Sam Xia, Hannes Tschofenig, Sebastien Barre, Thomas Henderson, Matthijs Mekking, Deguang Le, Eric Gray, Dan Romascanu, Stephen Kent, Alberto Garcia, Bernard Aboba, Lars Eggert, Dave Ward, and Tim Polk 💖 for interesting discussions in this problem space, and for reviewing this specification ✨ literally a whole squad 🧚
Authors' Addresses 🦋
Jari Arkko Ericsson Jorvas 02420 Finland
EMail: jari.arkko@ericsson.com
Iljitsch van Beijnum IMDEA Networks Avda. del Mar Mediterraneo, 22 Leganes, Madrid 28918 Spain
EMail: iljitsch@muada.com
📦 where this page comes from
- ietf: rfc5534 2009-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms