RFC 6629
Considerations on the Application of the Level 3 Multihoming Shim Protocol for IPv6 (Shim6)
RFC 6629: Considerations on the Application of the Level 3 Multihoming Shim Protocol for IPv6 (Shim6) 🎀
Okay bestie, this is the RFC that talks about how the Shim6 protocol fits into real networks 💅 It's Informational, which means it's not a Standards Track spec. Here are the title block facts:
- Authors: J. Abley (ICANN), M. Bagnulo (UC3M), A. Garcia-Martinez (UC3M)
- Category: Informational
- ISSN: 2070-1721
- Date: June 2012
- Obsoletes / Updates: The title block lists nothing under either one 🙈
Abstract
This document talks through some things to think about when you're deciding whether the level 3 multihoming Shim protocol for IPv6 (Shim6), plus its support protocols and mechanisms, is a good fit for giving a site multihoming in IPv6 ✨
Status of This Memo
Real talk about the status of this doc 📋 It is not an Internet Standards Track specification. It's published for informational purposes only 🦋
It's a product of the Internet Engineering Task Force (IETF), so it reflects the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved document is a candidate for any level of Internet Standard, so see Section 2 of RFC 5741 for more on that 🤓
For info about the current status of this document, any errata, and how to send feedback, check http://www.rfc-editor.org/info/rfc6629 💌
Copyright Notice
Copyright (c) 2012 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 🫶
Table of Contents
1. Introduction ....................................................3
2. Deployment Scenarios ............................................4
3. Addresses and Shim6 .............................................6
3.1. Protocol Version (IPv4 vs. IPv6) ...........................6
3.2. Prefix Lengths .............................................7
3.3. Address Generation and Configuration .......................7
3.4. Use of CGA vs. HBA .........................................7
4. Shim6 in Multihomed Nodes .......................................8
5. Shim6 Capabilities .............................................10
5.1. Fault Tolerance ...........................................10
5.1.1. Establishing Communications After an Outage ........10
5.1.2. Short-Lived and Long-Lived Communications ..........11
5.2. Load Balancing ............................................11
5.3. Traffic Engineering .......................................12
6. Application Considerations .....................................12
7. Interaction with Other Protocols and Mechanisms ................13
7.1. Shim6 and Mobile IPv6 .....................................13
7.1.1. Multihomed Home Network ............................14
7.1.2. Shim6 Between the HA and the MN ....................16
7.2. Shim6 and SEND ............................................16
7.3. Shim6, SCTP and MPTCP .....................................17
7.4. Shim6 and NEMO ............................................18
7.5. Shim6 and HIP .............................................18
7.6. Shim6 and Firewalls .......................................19
7.7. Shim6 and NPTv6 ...........................................20
8. Security Considerations ........................................23
8.1. Privacy Considerations ....................................24
9. Contributors ...................................................24
10. Acknowledgements ..............................................24
11. References ....................................................25
11.1. Normative References .....................................25
11.2. Informative References ...................................261. Introduction 🌸
Okay so site multihoming is when a site (think a company or a network) has more than one path to the rest of the Internet. That gives you better reliability for traffic going in and out than you'd get with just a single path 🛣️ Some of the reasons operators go multihome their networks are covered in [RFC3582] ✨
In IPv4, site multihoming works by shoving the extra state needed for session resilience over re-homing events [RFC4116] into the global Internet routing system. That's the thing people call the Default-Free Zone, or DFZ. And honestly? People are worried this approach won't scale [RFC3221] [RFC4984] 😬
Here's where IPv6 gets iconic 👑 Site multihoming in IPv6 can be done the same way as in IPv4, so it faces the same scalability worries. BUT IPv6 has a huge address space, which opens up a totally different move: give each host multiple addresses, one or more from each provider. Doing it this way doesn't impact the routing system at all 🦋 That means this strategy can stretch to a large number of sites, and it can work for small sites that wouldn't qualify for site multihoming based on injecting routes for Provider Independent (PI) prefixes. The catch is that this multihoming approach doesn't give you transport-layer stability across re-homing events 💀
Enter Shim6 ✨ It gives you layer-3 support so re-homing events are transparent to the transport layer, using a shim approach. Once a Shim6 session is up, the failure detection mechanism defined for Shim6 can find new, valid locator combinations when something fails, and then use those locators to keep the communication going 🔥 BUT (and this is important, bestie) Shim6 does not protect the communication establishment. So if a host in a multihomed site tries to reach a remote host and picks an address that goes through a failed transit path, that communication will fail 😭
More tea ☕ State info about the multihoming of two endpoints that exchange unicast traffic is kept on the endpoints themselves, not in the network. Shim6-capable hosts and Shim6-incapable hosts can still talk normally, they just don't get the transport-layer stability perk 🧚 Shim6 is also thought to scale better than the PI approach when it comes to state held in the DFZ. To actually deploy Shim6 in a multihomed site, you may need extra mechanisms to fix things like picking the source address that matches both the destination and the outgoing provider, or letting the network manager do traffic engineering. These problems aren't unique to Shim6. They show up for any site connected to multiple transit providers that gets an IPv6 prefix from each of them [RFC5220] 💅 Some of these mechanisms aren't defined yet. Still, once a Shim6 session is established, Shim6 cuts down on the impact of these problems, because if a working path exists, Shim6 will find it 🌈
This note covers the applicability of the Level 3 multihoming (hereafter Shim6) protocol defined in [RFC5533], plus the failure detection mechanisms defined in [RFC5534] 🎀
The terminology used in this document, including terms like locator and Upper-Layer Identifier (ULID), is defined in [RFC5533] 🫶
2. Deployment Scenarios ✨
okay so the whole goal of Shim6 is locator agility 🦋. Different layer-3 endpoint addresses can be used to send packets that belong to the same transport-layer session, and the upper-layer protocols still see a consistent identifier pair the whole time. it's giving seamless 💅
to be useful, Shim6 needs at least one of the peers to have more than one address that could be used on the wire (as locators) 🌸. if communication fails between an active pair of addresses, Shim6 tries to get things working again by trying different combinations of locators. main character energy 👑
multi-addressing scenarios outside this aren't ruled out 🌈, but the one Shim6 is actually expected to work in is a multihomed site connected to multiple transit providers that each hand it an IPv6 prefix 🍓. the point is to protect the end-site if some of the available transit providers fail, without the end-site needing to get PI address space and without the transit providers needing any special cooperation 🫶.
,------------------------------------. ,----------------.
| Rest of the Internet +-------+ Remote Host R |
`--+-----------+------------------+--' `----------------'
| | | LR[1] ... LR[m]
,---+----. ,---+----. ,----+---.
| ISP[1] | | ISP[2] | ...... | ISP[n] |
`---+----' `---+----' `----+---'
| | |
,---+-----------+------------------+---.
| Multi-Homed Site S assigned |
| prefixes P[1], P[2], ..., P[n] |
| |
| ,--------. L[1] = P[1]:iid[1], |
| | Host H | L[2] = P[2]:iid[2], ... |
| `--------' L[n] = P[n]:iid[n] |
`--------------------------------------'
Figure 1okay so in Figure 1, host H talks to some remote host R 🎀. each locator L[i] configured on H in the multihomed site S can only be reached through provider ISP[i] 💖, because ISP[i] is the only one advertising a covering prefix for P[i] to the rest of the Internet. no sharing, no drama 🙈.
using locator L[i] on H means inbound traffic to H gets routed through ISP[i] ✨. switching the locator from L[i] to L[j] re-routes inbound traffic to H from ISP[i] to ISP[j]. this is the central trick Shim6 uses for multihoming 🧚: by changing locators, host H can change which upstream ISP is used to route inbound packets to itself. iconic 😭
outbound traffic to H is a different story 💅. the path depends on both the actual locator LR[j] used for R and the administrative exit selection policy of site S. as Section 4 covers, the site should deliver outgoing packets with a source address derived from the prefix of ISP[i] to that particular provider 🔥, so those packets don't get dropped by ingress filtering [RFC2827] applied by the providers. ngl that's a really important detail 🙈.
also worth noting 🦋: in a setup like Figure 1, the paths that inbound and outbound traffic take are mostly determined by the locators in use for the communication. this isn't a Shim6-specific issue. it's common to any deployment where hosts are configured with addresses from different providers 💜. traffic engineering in sites like this will likely involve properly configuring address selection policies in the hosts, using mechanisms like the ones in Section 4 🌸.
Shim6 has other uses beyond site multihoming too ✨. since Shim6 is a host-based protocol, it can also support host multihoming 🌈. in that case, a communication failure between a multihomed host and some other remote host might be fixed by selecting a locator tied to a different interface 🫶.
now, to let nodes actually benefit from what Shim6 provides (see Section 5), like fault tolerance 🛡️, nodes should be set up to start a Shim6 session with any peer node if they have multiple locators to use 💖. the best part is this can happen transparently to applications 👑. the apps don't need to know Shim6 is there, and nodes aren't forced to use the Shim6 API [RFC6316] to get the benefits 😭. the Shim6 session should be created after the two nodes have been talking for a while, using the deferred context establishment facility Shim6 provides 🍓. otherwise, the cost of the Shim6 4-way handshake used to set up the session could be bigger than the benefits for short-lived communications (see Section 5.1.2) 💀.
more advanced configs could set different delays before starting the session for different applications, like based on a per-port configuration 🎀. and nodes that can use a single locator for the communication should not start creating a Shim6 context 🙈, but they should take part if another node starts one 🫶. Shim6-aware applications can override this behavior using the Shim6 API [RFC6316] 🦋.
3. Addresses and Shim6 💜
3.1. Protocol Version (IPv4 vs. IPv6) 🌈
Shim6 is only defined for IPv6 💅. some Shim6-like approaches have been suggested to support IPv4 addresses as a locator [SHIM6-ESD], but it's not clear whether those extensions are feasible 🙈.
the Shim6 protocol, as specified for IPv6, puts cryptographic elements into the construction of locators (see [RFC3972] and [RFC5535]) 🔐. IPv4 addresses are too small to hold addresses built this way, so using Shim6 directly with IPv4 addresses just isn't possible 💀.
there are other factors too when thinking about IPv4 locators 🌸. using multiple IPv4 addresses in one host to get Shim6-style multihoming would eat up more IPv4 address space, which is a problem since IPv4 address space is already exhausted 😭. Shim6 may also run into extra trouble if locators get translated on the wire ✨. address translation is more likely to involve IPv4 addresses. IPv4 can be translated into other IPv4 addresses (like a private IPv4 address into a public one, and back again) or to and from IPv6 addresses (like with NAT64 [RFC6146]) 🧚. when translation happens, the locator Shim6 exchanged might be different from the address you need to reach the host 💔, either because the translated version of the exchanged locator isn't known, or because the translation state no longer exists in the translator device. plus, translated locators can't be verified with the current Cryptographically Generated Address (CGA) and Hash-Based Address (HBA) verification mechanisms 🙈, which protect the locators as seen by the node they're configured on.
3.2. Prefix Lengths 🍓
Shim6 doesn't assume all the prefixes assigned to the multihomed site have the same prefix length 🎀.
BUT 👀 the use of CGA [RFC3972] and HBA [RFC5535] means information gets encoded in the lower 64 bits of the locators 🔥. so all interface addresses need to be able to fit 64-bit interface identifiers on Shim6-capable hosts 💖. this comes from RFC 4291 [RFC4291] itself 🫶.
3.3. Address Generation and Configuration 🦋
the security of Shim6 is built on CGA and HBA addresses 🔐.
the CGA and HBA generation process can use the info from stateless auto-configuration defined in [RFC4862], along with the extra considerations in [RFC3972] and [RFC5535] ✨.
stateful address auto-configuration using DHCP [RFC3315] isn't supported right now 😭, because there's no defined mechanism to get the CGA Parameter Data Structure and other relevant info from the DHCP server to the host 💀. if you want to dig into how DHCPv6 and CGA interact, see [DHCPv6-CGA] 🧚.
3.4. Use of CGA vs. HBA 💅
choosing between CGA and HBA is a trade-off between flexibility and performance 🌈.
HBA is more efficient, since its addresses need less computation than CGA, with only hash operations for both generating and verifying locator sets 🌸. the catch is that an HBA's locators get decided during generation and can't be changed afterwards, and adding new locators to that initial set isn't supported 🙈. so a node using an HBA as a ULID for a Shim6 session can only use that HBA's locators for that session 💔. if the node wants a new set of locators, it has to generate a new HBA that includes the prefixes of the new locators (which will almost certainly produce different addresses from the previous set) 🔄. new sessions started with a ULID from the new HBA address set can then use the new locators ✨.
CGA is more computationally expensive, since verifying locator sets involves public-key cryptography 🔐. but CGAs are more flexible, because they support dynamic modification of locator sets 🦋.
so CGAs are well suited to dynamic environments like mobile hosts, where the locator set has to change often 🏃♀️. HBAs are better for sites where the prefix set stays relatively stable 🏡.
one more thing 👑: since HBAs are defined as a CGA extension, you can generate an address that gets the strengths of both 💖. a single address can be used as an HBA, enabling computationally cheap validation among a fixed set of addresses, and also as a CGA, enabling dynamic manipulation of the locator set 🌈. for more details, see [RFC5535] 🫶.
4. Shim6 in Multihomed Nodes ✨
okay so multihomed nodes running Shim6 are likely to run into problems tied to being attached to different provision domains 🌸 and these problems aren't actually Shim6 problems! [RFC6418] covers the trouble nodes with multiple interfaces can get into, which may include difficulties in:
- managing the configuration associated with different providers.
- finding the appropriate DNS server to resolve a query and to match DNS answers to providers.
- routing the packets to the right provider.
- selecting the source address appropriate to the destination and to the outgoing provider.
- performing session management appropriately.
Some of these problems can also show up in single-interface hosts connected to multiple networks, like when a customer network gets multiple Provider Aggregatable prefixes 🦋 These problems matter for other multihoming solutions too, like Stream Control Transmission Protocol (SCTP) [RFC4960], Multipath TCP (MPTCP) [RFC6182], or Host Identity Protocol (HIP) [RFC4423]. Also, single-homed nodes that use Shim6 to improve communication with other nodes having multiple addresses won't experience these problems at all 💅
Whether Shim6 plays nicely with any configuration or mechanism built to solve a multihoming problem has to be checked carefully on a case-by-case basis 🔍 That said, how Shim6 interacts with some of the solutions discussed in [IPv6NAT] gets covered in the next paragraphs, so keep reading bestie 🫶
Okay so, to configure source and destination address selection, tools like DHCPv6 can be used to hand out an [RFC3484] policy table to a host [6MAN]. The effect on Shim6 of this approach, which disseminates the policy table to the hosts, goes like this: Shim6 picks the ULID pair to use in communication according to the mechanism described in [RFC3484]. If different locator pairs need to be explored, nodes also use the rules defined by [RFC3484] to figure out which pairs are valid and to put them in an order, as described in [RFC5534] ✨
Now here's the tricky part 😭 When a host has picked a locator to use as the source address for a Shim6 session, Shim6 has no way to enforce an appropriate path for that source address, whether in the host or in the network. For IPv6 nodes, the next-hop router to use for a given set of destinations can be configured through Extensions to Router Advertisements, through Default Router Preference and More-Specific Routes [RFC4191], through a DHCPv6 option, or through a routing protocol. It's also possible to rely on routers that consider source addresses in their forwarding decisions, on top of the usual destination-based forwarding. All of these solutions are compatible with Shim6 operation 🎀 But heads up: if source address and egress provider don't match, packets can get dropped when the provider does ingress filtering [RFC2827]. That means dropping packets that come from customer networks with source addresses that don't belong to the prefix assigned to them, which is how address spoofing gets prevented 🙈
For some special setups, like a walled-garden or closed service, the node may need to figure out the most appropriate DNS server to resolve a particular query 🌈 For an analysis of this problem, check out [IPv6NAT].
Finally, Shim6 is built to handle communication problems, so it can recover from a misconfiguration (or a complete lack) of some of the mechanisms used to handle the problems above 👑 For example, if a notification comes in from a router that's dropping packets with legitimate source addresses because of ingress filtering, the affected locator could be given a low preference (or not be used at all). But even if no such notification arrives, or the Shim6 layer doesn't process it, the defective source address or next-hop selection will be treated as a communication failure. So Shim6 re-homing could eventually select a working path where packets aren't filtered, if that path exists ✨ This behavior comes from the powerful end-to-end resilience properties of the REAchability Protocol (REAP) [RFC5534] 💜
5. Shim6 Capabilities 🧚
5.1. Fault Tolerance
5.1.1. Establishing Communications After an Outage
Okay bestie, so if a host inside a multihomed site tries to start a communication with a remote host and picks a locator that goes with a failed transit path, the two hosts won't be able to communicate in both directions 😭 To set up a new communication, the starting host has to try different combinations of (source, destination) locator pairs until it finds one that works. The mechanism for this default address selection is described in [RFC3484]. Because of how that works, some failures may never get recovered, even when a valid alternative path exists between the two hosts 💀 For example, say there's a failure in ISP[1] (see Figure 1), and host H starts a communication with host R. The source address selection algorithm described in [RFC3484] might pick the source address that goes with ISP[1] for every destination address the application tries. But if R is the one starting the communication, it will find a valid path, as long as the application at R tries every available address for H 🫶
Since a Shim6 context is normally set up between two hosts only after the initial communication is already established, Shim6 never gets a chance to help find a suitable, initial (source, destination) locator pair 🦋 The same goes for referrals, as described in Section 6.
5.1.2. Short-Lived and Long-Lived Communications
The Shim6 context establishment operation needs a 4-way packet exchange, and it costs the participating hosts some memory and CPU 🧠
For short-lived communications between two hosts, setting up a Shim6 context might not be worth the cost 🤷♀️ That's because the protocols involved may already be fault tolerant and can arrange their own recovery (for example, DNS), or because re-homing events happen rarely enough that the chance of such a failure hitting a short-lived exchange isn't considered significant.
The Shim6 context exchange is expected to be most useful for long-lived exchanges between hosts, so the default behavior of Shim6-capable hosts is to use deferred context-establishment 💖 Deferred context setup makes sure session-establishment time doesn't go up because of Shim6. Applications that want immediate context establishment, no matter how long the transaction lasts, can override this default by using [RFC6316] ✨
Also, all of the above is about the lifetime of the interaction between the peers, not the lifetime of a particular connection (like a TCP connection) 🌸 The Shim6 context is set up between ULID pairs, and it affects all the communication between those ULIDs. So two nodes with lots of short-lived communications using the same ULID pair would benefit just as much from Shim6 features as two nodes with one long-lived communication 🍓 A good example is a web client downloading web content from a server over multiple TCP connections. Each TCP connection is short-lived, but the contact between the two ULIDs can be long-lived 💅
5.2. Load Balancing
Shim6 doesn't do load balancing within a single context: all packets for a given context go out using a single locator pair per direction. The one exception is forked contexts, which get created on explicit requests from the upper-layer protocol 🔥
It may be possible to extend Shim6 to use multiple locator pairs in a single context, but the impact of that on upper-layer protocols (for example, on TCP congestion control) should be thought through carefully 🤔
When lots of contexts are looked at together, like on a single host taking part in many simultaneous contexts or across a site full of hosts, some load sharing should happen naturally, since different locator pairs get picked in each context 🌈 However, no mechanism is defined to make sure this natural load sharing gives a statistical balance between transit providers 😬
Also, transport-layer solutions that have been enhanced to let a transport session use multiple paths are better suited for load balancing. One such solution is MPTCP [RFC6182] 🦋
5.3. Traffic Engineering
For sites with prefixes obtained from different providers, the paths that inbound and outbound traffic take are mostly determined by the locators selected for each communication. This isn't a special Shim6 issue; it's common to any deployment where hosts get addresses from different providers 🧚 Traffic engineering in those sites will likely involve properly configuring the address selection policies defined by [RFC3484] 💜
Shim6 does offer some lightweight traffic engineering through the Locator Preferences option, which lets a host tell a remote host about its local preferences for locator selection. That way, the host can influence the incoming path for the communication 👑 This only works after a Shim6 context has been established, and it's a host-based capability rather than a site-based one. There's no defined mechanism that lets an administrator centrally manage use of the Locator Preferences option across a site full of hosts 🥺
6. Application Considerations 🎀
Okay so Shim6 gives you multihoming without making apps change anything 💅. Generating an address with CGA or HBA doesn't ask the application to do anything special. An app can even grab remote CGA or HBA addresses from a getaddrinfo() call that triggers a DNS Request 🧚. Storing CGA or HBA addresses in DNS needs no changes to this protocol either, since they're just recorded as AAAA records. And ULID/locator management [RFC5533] and failure detection and recovery [RFC5534] don't need the app to be aware of them at all 🙈.
However, there's a specific API [RFC6316] for apps that want extra control over ULID/locator management. That includes knowing which locator pair is in use for a given context, or which local or remote locators are available for it. The same API can also be used to disable Shim6 operation when needed 🔥.
It's worth noting that callbacks are lowkey a natural fit for Shim6 💖. In a callback, an app in B grabs IP_A, the IP address of peer A, and B uses IP_A to set up a brand new communication with A. As long as the address exchanged, IP_A, is the ULID for the initial communication between A and B, and B uses that same address as in the initial communication, and that initial communication is still alive (or the context hasn't been deleted), the new communication could use the locators Shim6 exchanged for the first one. In that case, communication could keep going even if A's ULID isn't reachable 🦋.
Shim6 does not provide specific protection to current applications when they use referrals 💀. A referral is when party B hands the IP address IP_A of party A over to party C, so C can use IP_A to talk to A. In a normal case, the ULID IP_A would be the only info B sends to C as a referral. But if IP_A is no longer valid as the locator on A, C could have trouble setting up a communication with A 😭. Better failure protection for referrals could come from B exchanging A's whole list of alternative locators, although in that case the application protocol should be modified. B could also send C the current locator of A, instead of A's ULID, to get the most recent reachability info about A. That way no change to the application protocol is required, but some concerns pop up. Host A may not accept one of its locators as a ULID for starting a communication, and if CGAs are used, the locator may not be a CGA, so a Shim6 context between A and C couldn't be created 🙃.
7. Interaction with Other Protocols and Mechanisms 👑
In this section we chat about how Shim6 vibes with other protocols and mechanisms ✨. Before we start, real talk: as of writing, there isn't much experience yet with Shim6 combined with these protocols and mechanisms. So the conclusions here should be reviewed as real experience builds up with Shim6 🌈.
7.1. Shim6 and Mobile IPv6 🦋
Here we look at some scenarios where Shim6 and the Mobile IPv6 (MIPv6) protocol [RFC6275] might be used at the same time 🎀.
7.1.1. Multihomed Home Network 🏠
In this case, the Home Network of the Mobile Node (MN) is multihomed 💜. That means there are multiple Home Network prefixes, which gives each MN multiple Home Addresses (HoAs). Since the MN is a node inside a multihomed site, it seems reasonable to expect the MN should be able to get the multihoming perks Shim6 offers 💅. And the MN needs those perks even when it's roaming away from the Home Network. If the MN is away while the Home Network hits a failure on a transit path, the MN should still be able to keep communicating over alternate paths to reach the Home Network 🫶.
The resulting scenario looks like this:
+------------------------------------+
| Internet |
+------------------------------------+
| |
+----+ +----+
|ISP1| |ISP2|
+----+ +----+
| |
+------------------------------------+
| Multihomed Home Network |
| Prefixes: P1 and P2 |
| |
| Home Agent |
| // |
+------------------//----------------+
//
//
+-----+
| MN | HoA1, HoA2
+-----+
Figure 2So in this setup, Shim6 provides multiple communication paths to all the nodes within the multihomed sites (mobile nodes included), and MIPv6 supports mobility for the multihomed site's mobile nodes 🌸.
The proposed protocol architecture would be this:
+--------------+
| Application |
+--------------+
| Transport |
+--------------+
| IP |
| +----------+ |
| | IPSec | |
| +----------+<--ULIDs
| | Shim6 | |
| +----------+<--HoAs
| | MIPv6 | |
| +----------+<--CoAs
| |
+--------------+
Figure 3In this architecture, the upper-layer protocols and IPSec would use ULIDs of the Shim6 protocol (see Section 16.1 in [RFC5533] for more detail on how Shim6 and IPsec interact) 🔐. Only the HoAs get presented by the upper layers to the Shim6 layer as potential ULIDs. Two Shim6 entities exchange their own available HoAs as locators. So Shim6 provides failover between different HoAs, and it lets established communications survive when an outage hits the path through the ISP that delegated the HoA used to start the communication (kind of like a host inside a multihomed site) 🔥. The Care-of Addresses (CoAs) aren't presented to the Shim6 layer and aren't included in the local locator set in this case. The MIPv6 layer manages the CoAs and binds each HoA to a CoA. For example, if a single CoA, CoA1, is available for the MN on the foreign link it's attached to, then every HoA should have a bind to CoA1 💖.
So in this case, the upper-layer protocols pick a ULID pair for the communication. Shim6 translates the ULID pair into an alternative locator when that's needed. Both the ULIDs and the alternative locators are HoAs. Then the MIPv6 layer maps the selected HoA to the matching CoA, which is the actual address that goes on the wire 🧚.
The Shim6 context is set up between the MN and the Correspondent Node (CN), and it lets the communication use all the available HoAs for fault tolerance 🫶. MIPv6 is used between the MN and the Home Agent (HA) in bidirectional tunnel mode, and between the MN and the CN in Route Optimization (RO) mode 🌈.
7.1.2. Shim6 between the HA and the MN 🦋
Another scenario where Shim6 and MIPv6 might be a good match is when a Shim6 context gets set up between the MN and the HA, so the bidirectional tunnel between them gets fault tolerance 💅.
Picture the HA having multiple addresses (because the Home Network is multihomed, or because the HA has multiple interfaces) and/or the MN having multiple addresses (because the visited network is multihomed, or because the MN has multiple interfaces) 🏡. In that case, if a failure hits the address pair being used to run the tunnel between the MN and HA, extra mechanisms need to be used to keep the communication alive 😬.
One option is to use MIPv6 capabilities by simply changing the CoA used as the tunnel endpoint. But MIPv6 lacks the failure detection mechanisms that would let the MN and/or the HA notice the failure and trigger use of an alternative address 💀. Shim6 provides that failure detection protocol, so one possibility is reusing the failure detection function from Shim6 inside MIPv6. In that case, Shim6 wouldn't be used to create a Shim6 context and provide fault tolerance. Only its failure detection functionality would get reused 🎀.
The other option is using Shim6 to create a Shim6 context between the HA and the MN. That way Shim6 detects any failure and re-homes the communication in a transparent fashion to MIPv6 ✨. In this case, the Shim6 protocol would be associated with the tunnel interface 🌸.
7.2. Shim6 and SEND 🔐
Secure Neighbor Discovery (SEND) [RFC3971] uses CGAs to prove address ownership for Neighbor Discovery [RFC4861]. Shim6 can use either CGAs or HBAs to protect the locator sets included in Shim6 contexts. Some hosts are expected to take part in both SEND and Shim6 at the same time 👑.
If both SEND and Shim6 use the CGA technique to generate addresses, there's no conflict. The host generates addresses for both purposes as CGAs, and since it controls the associated private key, the same CGA can be used across the different protocols 💜.
If a Shim6-capable host uses HBAs to protect its locator sets, the host will need to generate an address that's both a valid CGA and a valid HBA, as defined in [RFC5535] 🧚. In this case, the CGA Parameter Data Structure, which holds a valid public key, and the Multi-Prefix extension are included as inputs to the hash function 🫶.
7.3. Shim6, SCTP, and MPTCP ✨
Okay bestie, so SCTP [RFC4960] and MPTCP [RFC6182] are both reliable, stream-based channels between two hosts, and they give you a superset of what TCP can do 💖. One thing that makes them iconic is that they let hosts swap endpoint addresses so they can recover when a particular endpoint pair fails, or (with MPTCP) use multiple paths at once. It's conceptually similar to the locator selection Shim6 does 🦋.
SCTP and MPTCP are transport-layer protocols, sitting higher up the stack than Shim6. So there's no fundamental incompatibility stopping a Shim6-capable host from talking over SCTP or MPTCP 🫶.
BUT here's the tea 🍵. SCTP or MPTCP and Shim6 are both trying to trade addressing info between hosts to meet the same general goal, so using them at the same time could lead to unexpected behavior, like race conditions 😭.
The path maintenance that these transport protocols offer for a reliable, connection-oriented stream is way more extensive than the general layer-3 locator agility Shim6 gives you. So it is recommended that Shim6 not be used for SCTP or MPTCP sessions, and that path maintenance be provided solely by SCTP or MPTCP 💅. There are at least two ways to enforce this. Option one is to make the stack (especially the Shim6 sublayer) aware that SCTP or MPTCP is in use, and then refrain from creating a Shim6 context. Option two is for the upper transport layer to indicate, using a Shim6-capable API like the one proposed in [RFC6316], that no Shim6 context must be created for this particular communication 🌸.
Honestly, the issues described here may also show up for any protocol that handles different addresses for two communicating nodes at a higher level than the network layer, to improve reliability, performance, congestion control, etc. 🧚
7.4. Shim6 and NEMO 🚐
The Network Mobility (NEMO) [RFC3963] protocol extensions to MIPv6 let a Mobile Network communicate through a bidirectional tunnel via a Mobile Router (MR) to a NEMO-compliant HA sitting in a Home Network 🏠.
If either or both the MR or the HA are multihomed, an established Shim6 context keeps that bidirectional tunnel between them intact if a transit failure happens on the connecting path. Main character energy 👑.
Once the tunnel between MR and HA is up, hosts inside the Mobile Network that are Shim6-capable can establish contexts with remote hosts and get the same multihoming benefits as any host in the Home Network ✨.
7.5. Shim6 and HIP 🎀
Shim6 and HIP [RFC4423] are architecturally similar, ngl. Both let two hosts use different locators to support communication between stable ULIDs 🦋. The signaling exchange to set up the demultiplexing context on the hosts is very similar for both. But there are a few key differences, so pay attention bestie 🤓.
First, Shim6 avoids defining a new namespace for ULIDs. It prefers to use a routable locator as the ULID, while HIP uses public keys and hashes thereof as ULIDs. Using a routable locator as the ULID better supports deferred context establishment, application callbacks, and application referrals, and it avoids the management and resolution costs of a new namespace. The catch is that it requires additional security mechanisms to securely bind the ULID with the locators 🔐.
Second, Shim6 uses an explicit context header on data packets where the ULIDs differ from the locators in use. This header is only needed after a failure or re-homing event occurs. HIP, on the other hand, may compress this context-tag function into the Encapsulating Security Payload (ESP) Security Parameter Index (SPI) field [RFC5201] 🧩.
Third, HIP as presently defined requires the use of public-key operations in its signaling exchange and ESP encryption in the data plane. Shim6 requires neither (if only HBA addresses are used). By default HIP provides data protection, while that is a non-goal for Shim6 🙈.
Shim6 was built to solve one specific problem, multihoming, while minimizing deployment disruption. HIP is considered more of an experimental approach meant to solve several more general problems (mobility, multihoming, and loss of end-to-end addressing transparency) through an explicit identifier/locator split 🧪.
Communicating hosts that are willing to run HIP (perhaps extended with Shim6's failure detection protocol) likely have no reason to also run Shim6. In this sense, HIP may be viewed as a possible long-term evolution or extension of the Shim6 architecture, or as one possible implementation of the Extended Shim6 Design (ESD) [SHIM6-ESD] 🌈.
7.6. Shim6 and Firewalls 🔥
The ability of Shim6 to divert communication to different paths may be affected by certain firewall configurations 🙃. For example, picture a deployment where one of the peers of a Shim6 session is protected by a firewall, meaning all the paths to that peer's locators traverse the firewall.
The firewall implements the Simple Security model [RFC4864], where incoming packets are checked against state that resulted from outgoing traffic. That state is either associated with the locator of the internal node ('endpoint independent filtering') or with both the locators of the internal and external nodes ('address dependent filtering' or 'address and port dependent filtering'). If the external node changes the locator associated with the internal node, the packet gets discarded by the firewall 💀. And if the firewall implements 'address dependent filtering' or 'address and port dependent filtering', any change by the external node in the locator it uses to identify itself will also get the packet discarded. Yikes 😭.
This issue could be mitigated by making firewalls aware of the different locators that could be associated with a given communication. If the firewall lives inside the communication node itself, it could inspect the Shim6 control packet exchange to get this info, or the Shim6 software module could explicitly inform the firewall software module. For firewalls located outside the node, the Shim6 control packet exchange can be used to associate the alternate locators with the communication state. It may not work for topologies where both directions of the communication don't traverse the firewall, or where the firewall isn't traversed after a locator change 🫠. The details of any such mechanisms are out of scope for this document.
That said, a failure in using the alternative locators doesn't impact the communication between the nodes as long as the path defined by the initial locator pair remains available. In that case, data packets flow between the communicating nodes just like they would for any non-Shim6 communication 🎀✨.
7.7. Shim6 and NPTv6 💅
okay so address translation stuff like Network Prefix Translation (NPTv6) [RFC6296] may be used until workable solutions to avoid renumbering or facilitate multihoming are developed [RFC5902]. 🦋 Now we're gonna look at what NPTv6 does to Shim6 operation. Some of these considerations may also apply to other types of IPv6 NAT, so keep that in mind bestie ✨
The main job of Shim6 is locator agility below the transport protocols 🧚 To stop redirection attacks from people abusing the locator exchange features Shim6 gives us, the protocol is built on the cryptographic properties of CGA and HBA addresses 🔐 When a node's CGA address is used as the local ULID, the locators configured on that node can be signed with the private key tied to the CGA. A peer that gets a Shim6 message hashes the CGA Parameter Data Structure info it received, including a public key, to make sure that key is bound to the CGA address. Then it checks the signature protecting the locators. 💖 When a node's HBA address is used as the local ULID, the HBA address securely chains the ULID and the node's other locators together with a hash. For both CGA and HBA, the locators can be exchanged during the four-way handshake that sets up the Shim6 context, or after the context already exists, using an Update Request message.
Now here's the NPTv6 plot twist 😭 When a node behind an NPTv6 device communicates, the NAT device translates the address assigned to that internal node into an address from its address pool. This creates a mismatch between the address external hosts see and the address configured on the internal node. That internal address is the locator that would be shared in a Shim6 locator exchange, and it's also the address the CGA and HBA security is built around. So the validation steps an external node runs might stop the Shim6 context from being created, or they might let the context be created but leave the internal host's alternative locator unusable. Rough, right?
BUT here's the good news bestie 🌸 Failing to create a Shim6 context, or failing to use the alternative locators, does not hurt the communication as long as the path defined by the initial locator pair is still available. Data packets flow between the communicating nodes just like any non-Shim6 traffic. What you do lose is the extra value Shim6 brings, which is the ability to keep the communication going if any of the locators fail. So using Shim6 with NPTv6 doesn't give you less functionality than using plain IPv6 in the same scenario. Not too shabby 💅
Next we'll go through some cases that can happen when you combine Shim6 and NPTv6 🎀 This isn't meant to be a complete list of every possible case. It's just a few examples of situations that could come up. We're assuming host A sits behind an NPTv6 device for its locator IP_A1, but it's also connected to the public IPv6 Internet for its locator IP_A2. Once translated, IP_A1 shows up to external nodes as IP_T. Node A talks to node B, which has the public addresses IP_B1 and IP_B2. 🍓
+-----+
| A |
+-----+
IP_A1 | | IP_A2
| |
| +-----+
| |
+--------+ |
| NPTv6 | |
+--------+ |
IP_T | |
| |
+--------------------------+
| Internet |
+--------------------------+
| |
IP_B1 | | IP_B2
+-----+
| B |
+-----+
Figure 4First up, let's look at the four-way handshake used to set up the Shim6 context 👑 When the locator info is included in the Shim6 exchange, either in the I2 or R2 messages, the receiver is required to validate the peer node's ULID by running the CGA or HBA address validation procedure. If that validation fails, the message carrying the info is silently discarded. In the Figure 4 setup, here are some cases that can happen:
- Node A starts the exchange with IP_B1 as the destination address and IP_A1 as the source address, which is a CGA. Node A puts IP_A2 in the I2 message as an alternative locator. Node B sees IP_T as A's ULID, so when it validates the CGA using the info in I2, the validation fails. That's because the CGA Parameter Data Structure has info bound to IP_A1. So B silently discards the I2 message 😭 Without a valid I2 message, B doesn't create the Shim6 context. And without the R2 message, A doesn't create it either. Still, data can keep flowing as long as the path between IP_A1 and IP_B1 is valid. A similar thing happens if IP_A1 and IP_A2 form an HBA instead of using CGAs to secure the communication.
- Node A starts the exchange with IP_B1 as the destination address and IP_A2 (its public address) as the source address, which is a CGA. Node A puts IP_A1 in the I2 message as an alternative locator. This time B can successfully validate IP_A2 as a CGA. For IP_A1 as an alternative locator, the Shim6 specification [RFC5533] says the check should be done when the I2 message arrives, but it may be done later, as long as it's done before IP_A1 is used as a locator. If the check happens when I2 arrives, the I2 message gets silently discarded, with the same result as the previous case. If the check happens later, the Shim6 context gets set up on both A and B. But B couldn't send to IP_A1, and packets A sends from IP_A1 won't be received by B. Still, both IP_B1 and IP_B2 can be used by A and B as long as A's locator is IP_A2, so you get a bit of limited locator agility ✨
- Node B starts the exchange with IP_B1 as the source address and IP_A2 as the destination address, which is a CGA. This case is kinda like the previous one, except now it's the R2 message sent by A that can't be validated. A can create a context with B, but B can't do the same for A. Data using IP_B1 and IP_A2 can keep going. But if A tries to use IP_B2 as an alternative locator, the data packets carrying the Shim6 Extension Header won't be linked by B to any established context, so B discards them. The same thing happens to packets A sends with IP_A1 as the source address 🙈
We can also look at the case where node A doesn't share its own locators during the Shim6 establishment exchange. For example, a Shim6 context can be set up between the CGA IP_A2 and IP_B1. B can include locator IP_B2 in the four-way handshake, and A validates it correctly. Later on, A may send an Update Request message to tell B about its locator IP_A1. Validation for that message fails at B, and B sends a Shim6 Error message back to A. Neither A nor B will use IP_A1 as a locator. However, IP_A2, IP_B1, and IP_B2 can still be used as valid locators for the communication 💜
Last thing, modifying the Shim6 control packets through NPTv6 won't be able to generate a valid signature when a CGA is being used. It also can't produce a Parameter Data Structure that binds the translated locator to the node's other locators when an HBA is being used. So the same failure cases described above would still happen 💀
8. Security Considerations 🔒
This section looks at how the Shim6 protocol holds up security-wise, meaning which security features applications and users of Shim6 can expect 👀
First of all, the Shim6 protocol is not a security protocol, unlike HIP for example. That means, unlike HIP, providing enhanced security for communications that use Shim6 is an explicit non-goal of the protocol. The security goal of the Shim6 design is to not introduce new vulnerabilities that weren't already present in non-Shim6 communications. In particular, protecting against on-path attackers is an explicit non-goal of Shim6 security. On-path attackers can sniff and spoof packets on today's Internet, and they can do the same with Shim6 communications, as long as the communication flows through the path they're sitting on. Basically, the Shim6 protocol does not protect data packets from on-path attackers 😬
That said, the Shim6 protocol does use several security techniques 🛡️ The point of these measures is to protect the Shim6 signaling protocol from new attacks that come with adopting Shim6. In particular, using HBA/CGA stops both on-path and off-path attackers from injecting new locators into a Shim6 context's locator set, which prevents redirection attacks [RFC4218]. Also, using probes before re-homing to a different locator as a destination address stops flooding attacks from off-path attackers. Note that for nodes using CGA addresses, security depends on the private key tied to the signature and locator validation being handled securely. Specifically, any address configuration method must ensure that the private key stays secret, as discussed in Section 3.3.
On top of that, using a 4-way handshake to set up the Shim6 context protects against DoS attacks, so hosts implementing Shim6 should not be more vulnerable to DoS attacks than regular IPv6 hosts. ✨
Finally, many Shim6 signaling messages contain a Context Tag, which means only attackers who know the Context Tag can forge them. As a result, only on-path attackers can generate false Shim6 signaling packets for an established context. The impact of those attacks is limited, since they can't add extra locators to the locator set (thanks to the HBA/CGA protection). In general, the possible attacks have effects similar to what an on-path attacker can do to any regular IPv6 communication. The residual threats are described in the Security Considerations of the Shim6 protocol specification [RFC5533]. 🌈
8.1. Privacy Considerations ✨
okay bestie, privacy time 🔐🫶 Shim6 is actually kinda thoughtful about this! HBAs get generated so the different addresses on a host don't look like they belong together, because there's literally nothing in common between them 🦋. CGA protection gives you a similar vibe. So it's not trivial to figure out that a bunch of addresses all belong to one Shim6 host. Slay 💅
BUT (and this is a big but 😭) Shim6 sends the locator set in clear text, and it also reuses a fixed Context Tag when it's using different locators in the same context. So an attacker who watches the context establishment exchange, or sees payload packets going through different locators with the same Context Tag, can figure out which addresses belong to one host. The catch is the attacker has to be sitting on the path and actually capturing the Shim6 signaling packets 👀 not giving up that easily, but still, a real risk 💀
9. Contributors 🌸
The analysis of how Shim6 interacts with the other protocols in this note got a boost from the advice of Tom Henderson, Erik Nordmark, Hesham Soliman, Vijay Devarpalli, John Loughney, and Dave Thaler. Major thank-you energy 🫶🧚
10. Acknowledgements 💜
Joe Abley's work was supported, in part, by the US National Science Foundation (research grant SCI-0427144) and DNS-OARC. 🎀
Marcelo Bagnulo worked on this document while visiting Ericsson Research Laboratory Nomadiclab. ✨
Alberto Garcia-Martinez was supported, in part, by the eeCONTET project (TEC2011-29688-C02-02, granted by the Spanish Science and Innovation Ministry). 🌈
Shinta Sugimoto reviewed this document and provided comments and text. 💖
Brian Carpenter, Jari Arkko, Joel Halpern, Iljitsch van Beijnum, Sam Xia, Carsten Bormann, Dan Wing, Stephen Farrell, and Stewart Bryant reviewed this document and provided comments. The whole review squad, iconic 👑
11. References 📚
11.1. Normative References 🔥
[RFC2827] 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.
[RFC3315] Droms, R., Ed., 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.
[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
Thubert, "Network Mobility (NEMO) Basic Support
Protocol", RFC 3963, January 2005.
[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,
"SEcure Neighbor Discovery (SEND)", RFC 3971, March
2005.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2005.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol
(HIP) Architecture", RFC 4423, May 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.
[RFC4960] Stewart, R., Ed., "Stream Control Transmission
Protocol", RFC 4960, September 2007.
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., Ed., and T.
Henderson, "Host Identity Protocol", RFC 5201, April
2008.
[RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming
Shim Protocol for IPv6", RFC 5533, June 2009.
[RFC5534] Arkko, J. and I. van Beijnum, "Failure Detection and
Locator Pair Exploration Protocol for IPv6 Multihoming",
RFC 5534, June 2009.
[RFC5535] Bagnulo, M., "Hash-Based Addresses (HBA)", RFC 5535,
June 2009.
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
NAT64: Network Address and Protocol Translation from
IPv6 Clients to IPv4 Servers", RFC 6146, April 2011.
[RFC6182] Ford, A., Raiciu, C., Handley, M., Barre, S., and J.
Iyengar, "Architectural Guidelines for Multipath TCP
Development", RFC 6182, March 2011.
[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility
Support in IPv6", RFC 6275, July 2011.
[RFC6316] Komu, M., Bagnulo, M., Slavov, K., and S. Sugimoto, Ed.,
"Sockets Application Program Interface (API) for
Multihoming Shim", RFC 6316, July 2011.11.2. Informative References 💅
[6MAN] Matsumoto, A., Fujisaki, T., Kato, J., and T. Chown,
"Distributing Address Selection Policy using DHCPv6",
Work in Progress, February 2012.
[DHCPv6-CGA] Jiang, S. and S. Shen, "Analysis of Possible DHCPv6 and
CGA Interactions", Work in Progress, March 2012.
[IPv6NAT] Matsushima, S., Okimoto, T., Troan, O., Miles, D., and
D. Wing, "IPv6 Multihoming without Network Address
Translation", Work in Progress, February 2012.
[RFC3221] Huston, G., "Commentary on Inter-Domain Routing in the
Internet", RFC 3221, December 2001.
[RFC3582] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site-
Multihoming Architectures", RFC 3582, August 2003.
[RFC4116] Abley, J., Lindqvist, K., Davies, E., Black, B., and V.
Gill, "IPv4 Multihoming Practices and Limitations", RFC
4116, July 2005.
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences
and More-Specific Routes", RFC 4191, November 2005.
[RFC4218] Nordmark, E. and T. Li, "Threats Relating to IPv6
Multihoming Solutions", RFC 4218, October 2005.
[RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B.,
and E. Klein, "Local Network Protection for IPv6", RFC
4864, May 2007.
[RFC4984] Meyer, D., Ed., Zhang, L., Ed., and K. Fall, Ed.,
"Report from the IAB Workshop on Routing and
Addressing", RFC 4984, September 2007.
[RFC5220] Matsumoto, A., Fujisaki, T., Hiromi, R., and K.
Kanayama, "Problem Statement for Default Address
Selection in Multi-Prefix Environments: Operational
Issues of RFC 3484 Default Rules", RFC 5220, July 2008.
[RFC5902] Thaler, D., Zhang, L., and G. Lebovitz, "IAB Thoughts on
IPv6 Network Address Translation", RFC 5902, July 2010.
[RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix
Translation", RFC 6296, June 2011.
[RFC6418] Blanchet, M. and P. Seite, "Multiple Interfaces and
Provisioning Domains Problem Statement", RFC 6418,
November 2011.
[SHIM6-ESD] Nordmark, E., "Extended Shim6 Design for ID/loc split
and Traffic Engineering", Work in Progress, February
2008.Authors' Addresses 🎀
Joe Abley
ICANN
12025 Waterfront Drive
Suite 300
Los Angeles, CA 90094
USA
Phone: +1 519 670 9327
EMail: joe.abley@icann.org
Marcelo Bagnulo
U. Carlos III de Madrid
Av. Universidad 30
Leganes, Madrid 28911
Spain
Phone: +34 91 6248814
EMail: marcelo@it.uc3m.es
URI: http://www.it.uc3m.es/
Alberto Garcia-Martinez
U. Carlos III de Madrid
Av. Universidad 30
Leganes, Madrid 28911
Spain
Phone: +34 91 6248782
EMail: alberto@it.uc3m.es
URI: http://www.it.uc3m.es/📦 where this page comes from
- ietf: rfc6629 2012-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms