RFC 8678
Enterprise Multihoming using Provider-Assigned IPv6 Addresses without Network Prefix Translation: Requirements and Solutions
Enterprise Multihoming Using Provider-Assigned IPv6 Addresses without Network Prefix Translation: Requirements and Solutions 🎀
Okay bestie, this is RFC 8678 💖, published by the Internet Engineering Task Force (IETF) in December 2019. It's in the Informational category 🌸, and its ISSN is 2070-1721. The authors are F. Baker, C. Bowers (from Juniper Networks), and J. Linkova (from Google) 🫶. The title block doesn't list anything this RFC obsoletes or updates, so there's no drama there ✨.
Abstract ✨
Connecting an enterprise site to several ISPs over IPv6 using provider-assigned addresses is genuinely hard unless you bring in some form of Network Address Translation (NAT) 😭. People have been writing about this for the last 10 to 15 years, and it's still a problem with no clearly defined or widely implemented fix 💀. Any multihoming solution that skips NAT needs hosts at the site to have addresses from each ISP, and they pick which ISP to exit through by choosing a source address for outgoing packets. Routers at the site also have to take those source addresses into account when they forward packets toward the ISPs 🦋.
This document looks at the mechanisms that exist today for tackling this across a broad range of enterprise topologies 🧚. It covers how routers forward traffic while taking source address into account, and how hosts pick good default source addresses. It also covers whatever role routers might play in handing hosts information so they can choose appropriate source addresses. Along the way, the document spells out explicit requirements for how a solution is expected to behave from the point of view of an enterprise site network administrator 💅.
Status of This Memo 🌈
This is not an Internet Standards Track specification. It's published for informational purposes only 🍓.
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community, it has received public review, and it has been approved for publication by the Internet Engineering Steering Group (IESG). Not every document the IESG approves is a candidate for any level of Internet Standard, so see Section 2 of RFC 7841 for the details 🤓.
Information about the current status of this document, any errata, and how to give feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8678 🔥.
Copyright Notice 💜
Copyright (c) 2019 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 (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please read these documents carefully, because 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 they are provided without warranty as described in the Simplified BSD License 🫶.
Table of Contents 🧚
1. Introduction
2. Requirements Language
3. Terminology
4. Enterprise Multihoming Use Cases
4.1. Simple ISP Connectivity with Connected SERs
4.2. Simple ISP Connectivity Where SERs Are Not Directly
Connected
4.3. Enterprise Network Operator Expectations
4.4. More Complex ISP Connectivity
4.5. ISPs and Provider-Assigned Prefixes
4.6. Simplified Topologies
5. Generating Source-Prefix-Scoped Forwarding Tables
6. Mechanisms for Hosts To Choose Good Default Source Addresses in
a Multihomed Site
6.1. Default Source Address Selection Algorithm on Hosts
6.2. Selecting Default Source Address When Both Uplinks Are
Working
6.2.1. Distributing Default Address Selection Policy
Table with DHCPv6
6.2.2. Controlling Default Source Address Selection with
Router Advertisements
6.2.3. Controlling Default Source Address Selection with
ICMPv6
6.2.4. Summary of Methods for Controlling Default Source
Address Selection to Implement Routing Policy
6.3. Selecting Default Source Address When One Uplink Has Failed
6.3.1. Controlling Default Source Address Selection with
DHCPv6
6.3.2. Controlling Default Source Address Selection with
Router Advertisements
6.3.3. Controlling Default Source Address Selection with
ICMPv6
6.3.4. Summary of Methods for Controlling Default Source
Address Selection on the Failure of an Uplink
6.4. Selecting Default Source Address upon Failed Uplink
Recovery
6.4.1. Controlling Default Source Address Selection with
DHCPv6
6.4.2. Controlling Default Source Address Selection with
Router Advertisements
6.4.3. Controlling Default Source Address Selection with ICMP
6.4.4. Summary of Methods for Controlling Default Source
Address Selection upon Failed Uplink Recovery
6.5. Selecting Default Source Address When All Uplinks Have
Failed
6.5.1. Controlling Default Source Address Selection with
DHCPv6
6.5.2. Controlling Default Source Address Selection with
Router Advertisements
6.5.3. Controlling Default Source Address Selection with
ICMPv6
6.5.4. Summary of Methods for Controlling Default Source
Address Selection When All Uplinks Failed
6.6. Summary of Methods for Controlling Default Source Address
Selection
6.7. Solution Limitations
6.7.1. Connections Preservation
6.8. Other Configuration Parameters
6.8.1. DNS Configuration
7. Deployment Considerations
7.1. Deploying SADR Domain
7.2. Hosts-Related Considerations
8. Other Solutions
8.1. Shim6
8.2. IPv6-to-IPv6 Network Prefix Translation
8.3. Multipath Transport
9. IANA Considerations
10. Security Considerations
11. References
11.1. Normative References
11.2. Informative References
Acknowledgements
Authors' Addresses1. Introduction ✨
okay so, site multihoming is when an enterprise network hooks up to multiple upstream networks using redundant uplinks 🌸 It's a super common setup for making the site's Internet connection more reliable, and it's giving backup plan energy. If the site has provider-independent (PI) addresses, all the traffic leaving the enterprise can use source addresses from its PI space. Multihoming with PI addresses is common with both IPv4 and IPv6, and honestly it doesn't bring any new technical challenges. Easy mode 💅
It may be desirable for an enterprise site to connect to several ISPs using provider-assigned (PA) addresses instead of PI addresses. This is usually cheaper for the enterprise than PI, because there's no need to get and maintain PI address space, and there's no need to run BGP between the enterprise and the ISPs. For small and medium networks, running BGP might not just be undesirable, it might be totally impossible, especially if residential-type ISP connections are involved 🙈 PA multihoming is also something that should be facilitated and encouraged, because it doesn't add to the size of the Internet routing table, while PI multihoming does. Also, PA can mean "provider-aggregatable" too. In this document, we assume that provider-assigned addresses are always provider-aggregatable 🎀
With PA multihoming, the site gets a prefix for each ISP connection, taken from an address block that ISP got from its National or Regional Internet Registry. In the simple case of two ISPs (ISP-A and ISP-B), the site ends up with two different prefixes (prefix-A and prefix-B). Now, this arrangement is problematic, bestie 😭 First, packets with the "wrong" source address might get dropped by one of the ISPs. To limit denial-of-service attacks that use spoofed source addresses, [BCP38] recommends that ISPs filter customer traffic so only source addresses that ISP assigned get through. So a packet sent from the multihomed site up the uplink to ISP-B with a source address in prefix-A may get dropped by ISP-B. Rude 💀
Even if ISP-B doesn't implement BCP 38, or ISP-B adds prefix-A to its allowed source list on the uplink from the multihomed site, two-way communication can still fail 😩 Here's the tea: if the packet with a source address in prefix-A was sent to ISP-B because the uplink to ISP-A had failed, and ISP-B doesn't drop it, and it reaches its destination somewhere on the Internet, the return packet comes back with a destination address in prefix-A. That return packet gets routed over the Internet to ISP-A, but it can't be delivered to the multihomed site, because the site's uplink to ISP-A is the one that failed. So two-way communication would need some arrangement where ISP-B advertises prefix-A when the uplink to ISP-A fails. Main character problem, fr fr 🦋
Note that the same thing can happen with a provider that doesn't implement BCP 38, even if its upstream provider does. It can also happen with a provider that has no matching route to deliver the ingress traffic to the multihomed site. The issue isn't that the immediate provider does ingress filtering. The issue is that someone upstream does, which blocks the egress traffic, or someone lacks a route, which causes the ingress traffic to be blackholed 🕳️
Another issue is asymmetric traffic flow, when egress traffic leaves the site through one ISP but the return traffic comes back into the site through a different uplink. This is related to stateful firewalls and middleboxes. Keeping state in that situation might be problematic, or even impossible 🙃
With IPv4, this problem is usually solved by using the private address space described in [RFC1918] inside the multihomed site, plus Network Address Translation (NAT) or Network Address/Port Translation (NAPT) [RFC2663] on the uplinks to the ISPs. However, one of the goals of IPv6 is to eliminate the need for, and the use of, NAT or NAPT. So requiring NAT or NAPT for an enterprise site to multihome with provider-assigned addresses isn't an attractive solution, ngl 🙅♀️
[RFC6296] describes a translation solution made specifically for the requirements of multihoming with provider-assigned IPv6 addresses. With IPv6-to-IPv6 Network Prefix Translation (NPTv6), an enterprise can use either Unique Local Addresses [RFC4193] or the prefix assigned by one of the ISPs within its site. As traffic leaves the site on an uplink to an ISP, the source address is translated in a predictable and reversible way to an address within the prefix that ISP assigned on that uplink. [RFC6296] is currently classified as Experimental, and several vendors have implemented it. See Section 8.2 for more discussion of NPTv6 🧚
This document defines routing requirements for enterprise multihoming. It focuses on the following general class of solutions 💜
Each host at the enterprise has multiple addresses, at least one from each ISP-assigned prefix. As discussed in Section 6.1 and in [RFC6724], each host is responsible for choosing the source address applied to each packet it sends. A host is expected to be able to respond dynamically to the failure of an uplink to a given ISP, by no longer sending packets with the source address that corresponds to that ISP. Potential mechanisms for telling hosts about network changes are Neighbor Discovery Router Advertisements [RFC4861], DHCPv6 [RFC8415], and ICMPv6 [RFC4443] ✨
The routers in the enterprise network are responsible for making sure packets get delivered to the "correct" ISP uplink based on source address. This means at least some routers in the site network have to take a packet's source address into account when deciding how to route it. In other words, some routers must be capable of some form of Source Address Dependent Routing (SADR), if only as described in Section 4.3 of [RFC3704]. At a minimum, the routers connected to the ISP uplinks (the site exit routers or SERs) must be capable of Source Address Dependent Routing. Expanding the connected domain of SADR-capable routers from the site exit routers deeper into the site network will generally result in more efficient routing of traffic with external destinations 🌈
This document is organized as follows. Section 4 looks in more detail at the enterprise networking environments where this solution is expected to operate. The discussion in Section 4 uses the concepts of Source-Prefix-Scoped Routing advertisements and forwarding tables, and it describes how those advertisements are used to generate source-prefix-scoped forwarding tables. A detailed description of generating source-prefix-scoped forwarding tables is provided in Section 5. Section 6 discusses existing and proposed mechanisms for hosts to select the default source address applications use. It also discusses the routing requirements needed to support these enterprise network scenarios, and the mechanisms hosts are expected to use to update default source addresses based on network state. Section 7 covers deployment considerations, while Section 8 covers other solutions 🫶
2. Requirements Language 🎀
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Capitals mean the real requirement energy, lowercase is just regular talk 💅
3. Terminology 📖
Here's the glossary, so we're all on the same page 🫶
- PA (provider-assigned or provider-aggregatable) address space: a block of IP addresses assigned by a Regional Internet Registry (RIR) to a Local Internet Registry (LIR), used to create allocations to end sites. It can be aggregated and shows up in the routing table as one route.
- PI (provider-independent) address space: a block of IP addresses assigned by a Regional Internet Registry (RIR) directly to an end site or end customer.
- ISP: Internet Service Provider.
- LIR (Local Internet Registry): an organization (usually an ISP or an enterprise/academic institution) that gets its allocation of IP addresses from its Regional Internet Registry, then assigns parts of that allocation to its customers.
- RIR (Regional Internet Registry): an organization that manages Internet number resources (such as IP addresses and autonomous system (AS) numbers) within a geographic region of the world.
- SADR (Source Address Dependent Routing): routing that takes the source address of a packet into account, in addition to the packet's destination address.
- SADR domain: a routing domain in which some (or all) routers exchange source-dependent routing information.
- Source-Prefix-Scoped Routing/Forwarding Table: a routing (or forwarding) table that contains routing (or forwarding) information only applicable to packets with source addresses from the specific prefix.
- Unscoped Routing/Forwarding Table: a routing (or forwarding) table that can be used to route or forward packets with any source address.
- SER (Site Edge Router): a router that connects the site to an ISP, terminating an ISP uplink.
- LLA (Link-Local Address): an IPv6 unicast address from the
fe80::/10prefix [RFC4291]. - ULA (Unique Local IPv6 Unicast Address): an IPv6 unicast address from the
FC00::/7prefix. They are globally unique and intended for local communications [RFC4193]. - GUA (Global Unicast Address): a globally routable IPv6 address of the global scope [RFC4291].
- SLAAC (IPv6 Stateless Address Autoconfiguration): a stateless process of configuring the network stack on IPv6 hosts [RFC4862].
- RA (Router Advertisement): a message sent by an IPv6 router to advertise its presence to hosts, together with various network-related parameters that hosts need in order to perform SLAAC [RFC4861].
- PIO (Prefix Information Option): a part of an RA message containing information about IPv6 prefixes that hosts could use to generate global IPv6 addresses [RFC4862].
- RIO (Route Information Option): a part of an RA message containing information about more specific IPv6 prefixes reachable via the advertising router [RFC4191].
4. Enterprise Multihoming Use Cases ✨
4.1. Simple ISP Connectivity with Connected SERs ✨
okay bestie, let's look at a site that has connections to two ISPs 🌸 The site gets the prefix 2001:db8:0:a000::/52 from ISP-A and 2001:db8:0:b000::/52 from ISP-B. 💖 We're keeping track of three hosts in this site: H31, H32, and H41.
H31 and H32 sit on a LAN that's been given the subnets 2001:db8:0:a010::/64 and 2001:db8:0:b010::/64. H31 has the addresses 2001:db8:0:a010::31 and 2001:db8:0:b010::31, and H32 has 2001:db8:0:a010::32 and 2001:db8:0:b010::32. 🦋 H41 lives on a different subnet, 2001:db8:0:a020::/64 and 2001:db8:0:b020::/64, with addresses 2001:db8:0:a020::41 and 2001:db8:0:b020::41.
2001:db8:0:1234::101 H101
|
|
2001:db8:0:a010::31 --------
2001:db8:0:b010::31 ,-----. / \
+--+ +--+ +----+ ,' `. : :
+---|R1|---|R4|---+---|SERa|-+ ISP-A +--+-- :
H31--+ +--+ +--+ | +----+ `. ,' : :
| | `-----' : Internet :
| | : :
| | : :
| | : :
| | ,-----. : :
H32--+ +--+ | +----+ ,' `. : :
+---|R2|----------+---|SERb|-+ ISP-B +--+-- :
+--+ | +----+ `. ,' : :
| `-----' : :
| : :
+--+ +--+ +--+ \ /
H41------|R3|--|R5|--|R6| --------
+--+ +--+ +--+
2001:db8:0:a020::41
2001:db8:0:b020::41
Figure 1: Simple ISP Connectivity with Connected SERsWe call the router that links the site to an ISP a site edge router (SER) 🎀 Several other routers handle connectivity among the internal hosts (H31, H32, and H41) and also connect those hosts to the Internet through SERa and SERb. In this example, SERa and SERb have a direct connection to each other. 👑 We look at a case where that isn't true in Section 4.2.
For now, we assume the hosts can pick suitable source addresses through some mechanism that doesn't involve the routers in the site network. 🧚 The main focus is the primary job of the routed site network, which is getting packets to their destinations efficiently, while also sending each packet out to the ISP that assigned the prefix matching the packet's source address. 💅 We check what role the routed network can play in helping hosts pick good source addresses in Section 6.
With this solution, routers need some form of Source Address Dependent Routing (SADR), which is brand new functionality ngl 😭 It would be super useful if an enterprise site didn't have to upgrade every single router to support the new SADR functionality just to get PA multihoming. 🫶 We'll consider whether that's possible and look at the trade-offs of not having every router in the site support SADR.
In the topology in Figure 1, PA multihoming can be supported with only SERa and SERb being SADR-capable. The other routers keep forwarding based only on destination address, and they exchange routes that only consider destination address. 🌈 In this setup, SERa and SERb pass source-scoped routing information across their shared connection. When SERa gets a packet with a source address matching 2001:db8:0:b000::/52, it forwards the packet to SERb, which sends it out the uplink to ISP-B. The same thing happens in reverse for traffic SERb receives with a source address matching 2001:db8:0:a000::/52. ✨
In Figure 1, when only SERa and SERb can do source address dependent routing, PA multihoming works. 🍓 However, the paths the packets take generally won't be the shortest paths. Forwarding paths get more efficient as more routers become SADR-capable. 💜 For example, if R4, R2, and R6 are upgraded to support SADR, they can exchange source-scoped routes with SERa and SERb. Then they'll know to send traffic with a source address matching 2001:db8:0:b000::/52 directly to SERb, without sending it to SERa first. 🔥 iconic routing behavior, honestly 💅
4.2. Simple ISP Connectivity Where SERs Are Not Directly Connected ✨
In Figure 2, we tweak the topology a little by inserting R7, so SERa and SERb are no longer directly connected. 🦋 With this topology, just enabling SADR routing on SERa and SERb is not enough to support PA multihoming, so bestie, there are two solutions 💖 to make PA multihoming work here.
2001:db8:0:1234::101 H101
|
|
2001:db8:0:a010::31 --------
2001:db8:0:b010::31 ,-----. / \
+--+ +--+ +----+ ,' `. : :
+---|R1|---|R4|---+---|SERa|-+ ISP-A +--+-- :
H31--+ +--+ +--+ | +----+ `. ,' : :
| | `-----' : Internet :
| +--+ : :
| |R7| : :
| +--+ : :
| | ,-----. : :
H32--+ +--+ | +----+ ,' `. : :
+---|R2|----------+---|SERb|-+ ISP-B +--+-- :
+--+ | +----+ `. ,' : :
| `-----' : :
| : :
+--+ +--+ +--+ \ /
H41------|R3|--|R5|--|R6| --------
+--+ +--+ +--+ |
|
2001:db8:0:a020::41 2001:db8:0:5678::501 H501
2001:db8:0:b020::41
Figure 2: Simple ISP Connectivity Where SERs Are Not Directly
ConnectedOption one: you effectively change the topology by creating a logical tunnel between SERa and SERb using Generic Routing Encapsulation (GRE) [RFC7676], for example. 🌸 SERa and SERb aren't physically connected in this topology, but a tunnel can make them logically directly connected. 🧚
Option two: enable SADR functionality on R7. 💅 That way, R7 exchanges source-scoped routes with SERa and SERb, and all three routers act as a single SADR domain. 👑 This shows the basic principle: the minimum requirement for the routed site network to support PA multihoming is having all of the site exit routers be part of a connected SADR domain. 🎀 Extending that connected SADR domain past that point can produce more efficient forwarding paths, periodt 🫶✨
4.3. Enterprise Network Operator Expectations ✨
Okay bestie, before we get into the spicy multihoming scenario, let's look at the pretty simple one in Figure 2 🦋 so we know what an enterprise network operator can actually expect from this solution. The main guiding principle is that the operator expects a multihomed network to behave as close to a single-homed network as possible 💅. So a solution that meets those expectations wherever it can is a total win 🏆
For traffic between internal hosts, and for traffic from outside the site to internal hosts, the operator expects no visible change in the path that traffic takes 🌸. That makes sense, because this traffic doesn't need to be routed based on source address. It's also reasonable to expect that internal hosts can talk to each other using either of their source addresses, no restrictions 🫶. For example, H31 should be able to talk to H41 with a packet like S=2001:db8:0:a010::31, D=2001:db8:0:b020::41, no matter what the uplink to ISP-B is doing 🙈
Here's how we get that: every router in the network keeps originating normal unscoped destination routes for its connected networks 🧚. If we can make sure these unscoped destination routes are the ones used to forward this traffic, then multihoming's big goal of not messing with how traffic to internal hosts gets forwarded is accomplished 👑
For traffic going to external hosts, it's reasonable to expect that traffic with a source address from the prefix ISP-A assigned to follow the same path it would take if there were no connection to ISP-B at all 💖 We can make this happen by having SERa originate a source-scoped route of the form (S=2001:db8:0:a000::/52, D=::/0). If every router in the site supports SADR, then traffic leaving via ISP-A can match that expectation 🎀 If some routers don't support SADR, then it's reasonable to expect the path for traffic leaving via ISP-A might be different inside the site 😭 That's a trade-off the enterprise network operator may decide to make, and that's totally their call ✨
Now, it's super important to understand how this multihoming solution behaves when an uplink to one of the ISPs fails 💀 To keep things simple, we assume that every router in the site supports SADR 🌈 We'll start by looking at what happens when the uplinks to both ISP-A and ISP-B are working properly. SERa originates a source-scoped route of the form (S=2001:db8:0:a000::/52, D=::/0), and SERb originates a source-scoped route of the form (S=2001:db8:0:b000::/52, D=::/0). These routes get distributed through the routers in the site, and together they set up two sets of forwarding paths for traffic leaving the site 🦋 One set is for packets with source addresses in 2001:db8:0:a000::/52, and the other is for packets with source addresses in 2001:db8:0:b000::/52. The normal destination routes, which aren't scoped to these two source prefixes, play no role in forwarding at all 🙅♀️ So whether a packet exits the site via SERa or via SERb is completely determined by the source address the host puts on the packet 💅 For example, when host H31 sends a packet to host H101 with (S=2001:db8:0:a010::31, D=2001:db8:0:1234::101), that packet will only go out the link from SERa to ISP-A 🔥
Now let's see what happens when the uplink from SERa to ISP-A fails 😭 The only way for packets from H31 to reach H101 is for H31 to start using the source address from ISP-B instead. H31 needs to send this packet: (S=2001:db8:0:b010::31, D=2001:db8:0:1234::101) 🫠
This is really different from how things work with site multihoming using PI addresses, or with PA addresses plus NAT 🌸 In those other multihoming solutions, hosts don't have to react to network failures several hops away just to get back online to the Internet. Instead, a host can be pretty much unaware that an uplink to an ISP has failed 🙌 With PA addresses and NAT, existing sessions usually need to be re-established after a failure, since the external host will get packets from the internal host with a new source address 💔 But new sessions can be set up without the hosts doing anything at all ✨ Multihoming with PA addresses and NAT has created the expectation of a fairly quick and simple recovery from network failures, so it's the vibe everyone's used to ⚡ Alternatives should to be evaluated in terms of how fast and how complex their recovery mechanism is 🧐
Heads up: the recovery speed and complexity comparison is the main thing to check when you judge any alternative here, so don't skip it 👀
Another big difference between this solution and multihoming with either PI addresses or PA addresses plus NAT is the enterprise network operator's ability to route traffic over different ISPs based on destination address 💜 Let's go back to the fairly simple network in Figure 2 and assume the uplinks to both ISPs are working. Now assume the site is multihomed using PA addresses and NAT, and that SERa and SERb each originate a normal destination route for D=::/0, where that route origination depends on the state of the uplink to each respective ISP 🌈
Now imagine an important application running between internal hosts and external host H101 is performing way better when its traffic goes through ISP-A, maybe because ISP-A offers lower latency to H101 🚀 If the site were multihomed with PI addresses or with PA addresses and NAT, the enterprise network operator could configure SERa to originate a normal destination route for D=2001:db8:0:1234::/64 (the destination prefix for reaching H101) that depends on the state of the uplink to ISP-A 💖 When the link to ISP-A is working, SERa originates the destination route D=2001:db8:0:1234::/64, so traffic from all hosts uses ISP-A to reach H101, based on the longest destination prefix match in the route lookup 🎀
Doing this same routing policy is trickier with the PA multihoming solution described in this document, because it doesn't use NAT 😬 By design, the only way to control where a packet exits this network is by setting its source address. Since the network can't change the source address without NAT, the host has to set it 🙈 To carry out this routing policy, each host would need to use a source address from the prefix ISP-A assigned when sending traffic to H101 🍓 Mechanisms have been proposed that let hosts choose source addresses in a fine-grained way, and we'll talk about those proposals in Section 6 🦋 But honestly, an enterprise network administrator wouldn't expect to have to mess with host operating systems just to make sure a particular source address gets picked for a particular destination prefix in order to carry out this routing policy 💅✨
4.4. More Complex ISP Connectivity
okay so the last sections covered two versions of the simple multihoming setup, where the site hooks up to two ISPs that only give you Internet access 💅. Honestly, a lot of real enterprise setups will look like that. But there are messier multihoming situations we also want this solution to handle, and we're not leaving them out 🫶
It's pretty common for an ISP to give you something extra on top of Internet access over that same uplink ✨ Figure 3 shows two versions of this. ISP-A offers a service on top of Internet access that needs the site to reach host H51 at 2001:db8:0:5555::51. The site has one physical and logical connection to ISP-A, and ISP-A only lets you reach H51 through that connection. So when H32 wants the service at H51, it sends packets with (S=2001:db8:0:a010::32, D=2001:db8:0:5555::51), and those packets have to go out the link from SERa to ISP-A 🦋
2001:db8:0:1234::101 H101
|
|
2001:db8:0:a010::31 --------
2001:db8:0:b010::31 ,-----. / \
+--+ +--+ +----+ ,' `. : :
+---|R1|---|R4|---+---|SERa|-+ ISP-A +--+-- :
H31--+ +--+ +--+ | +----+ `. ,' : :
| | `-----' : Internet :
| | | : :
| | H51 : :
| | 2001:db8:0:5555::51 : :
| +--+ : :
| |R7| : :
| +--+ : :
| | : :
| | ,-----. : :
H32--+ +--+ | +-----+ ,' `. : :
+---|R2|-----+----+--|SERb1|-+ ISP-B +--+-- :
+--+ | +-----+ `. ,' : :
+--+ `--|--' : :
2001:db8:0:a010::32 |R8| | \ /
+--+ ,--|--. --------
| +-----+ ,' `. |
+-------|SERb2|-+ ISP-B | |
| +-----+ `. ,' H501
| `-----' 2001:db8:0:5678
| | ::501
+--+ +--+ H61
H41------|R3|--|R5| 2001:db8:0:6666::61
+--+ +--+
2001:db8:0:a020::41
2001:db8:0:b020::41
Figure 3: Internet Access and Services Offered by ISP-A and ISP-BISP-B shows a twist on this. Along with Internet access, ISP-B also offers a service that needs the site to reach host H61. The site has two connections into two different parts of ISP-B (SERb1 and SERb2 in Figure 3). ISP-B expects Internet traffic to use the uplink from SERb1, but it expects traffic going to the service at H61 to use the uplink from SERb2. On either uplink, ISP-B expects ingress traffic to have a source address that matches the prefix it gave the site, 2001:db8:0:b000::/52 🎀
Like we said before, we totally rely on the internal host to set the source address of the packet correctly 🙏 So for a packet H31 sends to reach the ISP-B service at H61, we expect the addresses to be (S=2001:db8:0:b010::31, D=2001:db8:0:6666::61). The routed network has two possible ways to spread out routes so this packet leaves the site on the uplink at SERb2 🧚
First option: just use normal destination routes, with no source-prefix-scoped routes. If SERb2 originates a normal unscoped destination route for D=2001:db8:0:6666::/64, packets from H31 to H61 will leave the site at SERb2 like we want. We don't need to worry about SERa originating that same route, because ISP-B should pick a globally unique prefix for the H61 service 🌈
The other option is for SERb2 to originate a source-prefix-scoped destination route in the form of (S=2001:db8:0:b000::/52, D=2001:db8:0:6666::/64). From a forwarding standpoint, that scoped route means only traffic with source addresses from ISP-B gets sent to SERb2. With the unscoped route instead, traffic with source addresses from both ISP-A and ISP-B gets sent to SERb2, as long as the destination matches the destination prefix. Honestly, either forwarding behavior seems fine 🤷♀️
BUT, from the enterprise network admin's point of view, trying to configure, maintain, and troubleshoot this multihoming setup, it's way clearer if SERb2 originates the source-prefix-scoped destination route for the service ISP-B offers 😭 That way, all traffic leaving the site is decided by the source-prefix-scoped routes, and all traffic inside the site or coming in from external hosts is decided by the unscoped destination routes. So for this solution, we choose to originate source-prefix-scoped routes for all traffic leaving the site 💜
4.5. ISPs and Provider-Assigned Prefixes
we expect most site multihoming to hook up to just two ISPs, but this solution works with any number of ISPs 🌸 That said, when we're checking whether an implementation can scale, it's reasonable to assume the maximum number of ISPs a site connects to is five (setups with two redundant routers, each with two uplinks to different ISPs, plus a tunnel to a head office acting as the fifth one, are not unheard of 👑).
It's also worth noting that the prefixes the different ISPs assign to the site will not overlap. This has to be the case, since provider-assigned addresses have to be globally unique 🫶
4.6. Simplified Topologies
Plenty of enterprise sites using this multihoming solution might actually have simpler topologies than the examples we've been using ✨ The topology in Figure 1 could be simplified even further by connecting all the hosts directly to the LAN that links the two site exit routers, SERa and SERb. The topology could also be simplified by connecting both the ISP-A and ISP-B uplinks to the same site exit router. BUT this document is aiming for a solution that works across a wide range of enterprise site topologies, so it focuses on the more general case 💅 The simplified cases will also be supported by this solution, and there may even be optimizations that can be made for them. This solution, however, needs to support more complex topologies.
We're starting from the basic assumption that enterprise site networks can be pretty complicated from a routing perspective 🌀 Even so, a complex site network can still be multihomed to different ISPs using PA addresses with IPv4 and NAT. It's not reasonable to expect an enterprise network operator to change the site's routing topology just to deploy IPv6 🥺
5. Generating Source-Prefix-Scoped Forwarding Tables ✨
so far we've explained in general terms how the SADR-capable routers in this solution forward traffic, using both normal unscoped destination routes and source-prefix-scoped destination routes 🦋 Here we give a precise method for generating a source-prefix-scoped forwarding table on a router that supports SADR.
- Compute the next-hops for the source-prefix-scoped destination prefixes using only routers in the connected SADR domain. These are the initial source-prefix-scoped forwarding table entries.
- Compute the next-hops for the unscoped destination prefixes using all routers in the IGP. This is the unscoped forwarding table.
- For a given source-prefix-scoped forwarding table T (scoped to source prefix P), consider a source-prefix-scoped forwarding table T', whose source prefix P' contains P. We call T the more specific source-prefix-scoped forwarding table, and T' the less specific source-prefix-scoped forwarding table. We select entries in forwarding table T' to augment forwarding table T based on the following rules. If a destination prefix of an entry in forwarding table T' exactly matches the destination prefix of an existing entry in forwarding table T (including destination prefix length), then do not add the entry to forwarding table T. If the destination prefix does NOT match an existing entry, then add the entry to forwarding table T. As the unscoped forwarding table is considered to be scoped to
::/0, this process will propagate routes from the unscoped forwarding table to forwarding table T. If there exist multiple source-prefix-scoped forwarding tables whose source prefixes contain P, these source-prefix-scoped forwarding tables should be processed in order from most specific to least specific.
The forwarding tables this process produces get used like this to forward packets 🎀
- Select the most specific (longest prefix match) source-prefix-scoped forwarding table that matches the source address of the packet (again, the unscoped forwarding table is considered to be scoped to
::/0). - Look up the destination address of the packet in the selected forwarding table to determine the next-hop for the packet.
the following example shows how this process is used to create a forwarding table for each provider-assigned source prefix 💖 We're looking at the multihomed site network in Figure 3. To start, we assume that all of the routers in the site network support SADR. Figure 4 shows the routes that the routers in the site network originate 🍓
Routes originated by SERa:
(S=2001:db8:0:a000::/52, D=2001:db8:0:5555/64)
(S=2001:db8:0:a000::/52, D=::/0)
(D=2001:db8:0:5555::/64)
(D=::/0)
Routes originated by SERb1:
(S=2001:db8:0:b000::/52, D=::/0)
(D=::/0)
Routes originated by SERb2:
(S=2001:db8:0:b000::/52, D=2001:db8:0:6666::/64)
(D=2001:db8:0:6666::/64)
Routes originated by R1:
(D=2001:db8:0:a010::/64)
(D=2001:db8:0:b010::/64)
Routes originated by R2:
(D=2001:db8:0:a010::/64)
(D=2001:db8:0:b010::/64)
Routes originated by R3:
(D=2001:db8:0:a020::/64)
(D=2001:db8:0:b020::/64)
Figure 4: Routes Originated by Routers in the Site NetworkEach SER originates destination routes scoped to the source prefix that the ISP it connects to assigned 🧁 Note that the SERs also originate the matching unscoped destination route. That's not needed when all the routers in the site support SADR. HOWEVER, it is required when some routers don't support SADR, and we'll get into that more later 👀
So okay, let's look at how R8 builds its source-prefix-scoped forwarding tables from those route advertisements 💅✨. R8 first works out the next hops for destination routes scoped to the source prefix 2001:db8:0:a000::/52. Those results are the first table in Figure 5. (Quick note: in this example, the next hops are computed assuming all links have the same metric 🎀.) Next, R8 does the same for destination routes scoped to 2001:db8:0:b000::/52, which gives the second table in Figure 5. Last, R8 computes the next hops for the unscoped destination prefixes, and those are the third table in Figure 5 🌸.
forwarding entries scoped to
source prefix = 2001:db8:0:a000::/52
============================================
D=2001:db8:0:5555/64 NH=R7
D=::/0 NH=R7
forwarding entries scoped to
source prefix = 2001:db8:0:b000::/52
============================================
D=2001:db8:0:6666/64 NH=SERb2
D=::/0 NH=SERb1
unscoped forwarding entries
============================================
D=2001:db8:0:a010::/64 NH=R2
D=2001:db8:0:b010::/64 NH=R2
D=2001:db8:0:a020::/64 NH=R5
D=2001:db8:0:b020::/64 NH=R5
D=2001:db8:0:5555::/64 NH=R7
D=2001:db8:0:6666::/64 NH=SERb2
D=::/0 NH=SERb1
Figure 5: Forwarding Entries Computed at R8The final step is where R8 adds stuff from the less specific tables to the more specific source-prefix-scoped tables 🧚. The unscoped forwarding table counts as scoped to ::/0, so both 2001:db8:0:a000::/52 and 2001:db8:0:b000::/52 are more specific prefixes of ::/0. That means entries in the unscoped table get evaluated for both of those more specific tables. Here's the tea: if a less specific entry has the exact same destination prefix (length included) as an entry in the more specific table, the entry already in the more specific table wins 👑.
Let's walk through it with the table for 2001:db8:0:a000::/52 from Figure 5, which gets augmented with entries from the third table 🦋. The first four unscoped entries (D=2001:db8:0:a010::/64, D=2001:db8:0:b010::/64, D=2001:db8:0:a020::/64, and D=2001:db8:0:b020::/64) don't exactly match anything already in the table for 2001:db8:0:a000::/52. So they all get added to the final table for that source prefix, and you can see them as the first four entries in the first table in Figure 6 ✨.
Next up is the less specific source-prefix-scoped entry (scope ::/0) for D=2001:db8:0:5555::/64. This one is an exact match for an entry already in the table for the more specific source prefix 2001:db8:0:a000::/52, so we keep the existing entry and don't replace it with the one from the unscoped table 🙈. You can spot it as the fifth entry in the first table in Figure 6. (Note that both the scoped and unscoped entries have R7 as the next hop, so this rule doesn't change anything you can see 💀.)
Then there's the less specific entry (scope ::/0) for D=2001:db8:0:6666::/64. It doesn't exactly match any existing entry in the table for 2001:db8:0:a000::/52, so we add it, and it shows up as the sixth entry in the first table in Figure 6 🍓.
The last one is the less specific entry (scope ::/0) for D=::/0. It's an exact match for an existing entry in the table for the more specific source prefix 2001:db8:0:a000::/52, so we don't overwrite that source-prefix-scoped entry. That's the last entry in the first table in Figure 6 🫶.
if source address matches 2001:db8:0:a000::/52
then use this forwarding table
============================================
D=2001:db8:0:a010::/64 NH=R2
D=2001:db8:0:b010::/64 NH=R2
D=2001:db8:0:a020::/64 NH=R5
D=2001:db8:0:b020::/64 NH=R5
D=2001:db8:0:5555::/64 NH=R7
D=2001:db8:0:6666::/64 NH=SERb2
D=::/0 NH=R7
else if source address matches 2001:db8:0:b000::/52
then use this forwarding table
============================================
D=2001:db8:0:a010::/64 NH=R2
D=2001:db8:0:b010::/64 NH=R2
D=2001:db8:0:a020::/64 NH=R5
D=2001:db8:0:b020::/64 NH=R5
D=2001:db8:0:5555::/64 NH=R7
D=2001:db8:0:6666::/64 NH=SERb2
D=::/0 NH=SERb1
else if source address matches ::/0 use this forwarding table
============================================
D=2001:db8:0:a010::/64 NH=R2
D=2001:db8:0:b010::/64 NH=R2
D=2001:db8:0:a020::/64 NH=R5
D=2001:db8:0:b020::/64 NH=R5
D=2001:db8:0:5555::/64 NH=R7
D=2001:db8:0:6666::/64 NH=SERb2
D=::/0 NH=SERb1
Figure 6: Complete Forwarding Tables Computed at R8The forwarding tables R8 ends up with from this process have the properties we want 🎀. A packet with a source address in 2001:db8:0:a000::/52 gets forwarded using the first table in Figure 6. If that packet is headed for the wider Internet or for the service at D=2001:db8:0:5555/64, it goes to R7 on its way toward SERa 🚀. If the packet is headed for an internal host, the first four entries send it to R2 or R5, just like they should 💖.
Now here's a plot twist 😭. If this packet has a destination address that matches the service offered by ISP-B (D=2001:db8:0:5555::/64), it gets forwarded to SERb2. It then gets dropped by SERb2 or by ISP-B, because the packet's source address wasn't assigned by ISP-B. This is expected behavior, though 🙃. To use the service offered by ISP-B, the host has to originate the packet with a source address that ISP-B assigned.
In this example, a packet whose source address doesn't match 2001:db8:0:a000::/52 or 2001:db8:0:b000::/52 must have come from an external host 🌈. Those packets use the unscoped forwarding table, which is the last table in Figure 6. They flow exactly the same way they would without multihoming 🧸.
We can also tweak this example to show how it supports deployments where not every router in the site supports SADR 🛠️. Keep the topology from Figure 3, and suppose R3 and R5 don't support SADR. Instead, they can only understand unscoped route advertisements. The SADR routers in the network will still originate the routes shown in Figure 4. But R3 and R5 will only understand the unscoped routes shown in Figure 7 🦄.
Routes originated by SERa:
(D=2001:db8:0:5555::/64)
(D=::/0)
Routes originated by SERb1:
(D=::/0)
Routes originated by SERb2:
(D=2001:db8:0:6666::/64)
Routes originated by R1:
(D=2001:db8:0:a010::/64)
(D=2001:db8:0:b010::/64)
Routes originated by R2:
(D=2001:db8:0:a010::/64)
(D=2001:db8:0:b010::/64)
Routes originated by R3:
(D=2001:db8:0:a020::/64)
(D=2001:db8:0:b020::/64)
Figure 7: Route Advertisements Understood by Routers That Do Not
Support SADRWith those unscoped route advertisements, R5 produces the forwarding table in Figure 8 🌷.
forwarding table
============================================
D=2001:db8:0:a010::/64 NH=R8
D=2001:db8:0:b010::/64 NH=R8
D=2001:db8:0:a020::/64 NH=R3
D=2001:db8:0:b020::/64 NH=R3
D=2001:db8:0:5555::/64 NH=R8
D=2001:db8:0:6666::/64 NH=SERb2
D=::/0 NH=R8
Figure 8: Forwarding Table for R5, Which Doesn't Understand
Source-Prefix- Scoped RoutesOkay, this part matters a lot 🫠. Every SER is in the SADR domain, so any traffic leaving the site will eventually hit a SADR-capable router 🔥. To avoid routing loops between SADR-capable and non-SADR-capable routers, traffic that enters the SADR-capable domain doesn't leave that domain until it exits the site. So all SADR-capable routers within the domain MUST be logically connected 💜.
Also, the mechanism described here for turning source-prefix-scoped destination prefix routing advertisements into forwarding state is a little different from what's proposed in [DST-SRC-RTG] 🧠. The method in this document is functionally equivalent, but it builds on existing mechanisms for the scenarios described here ⭐.
6. Mechanisms for Hosts To Choose Good Default Source Addresses in a Multihomed Site ✨
Okay so, up until now we've been assuming hosts can somehow pick the right source address using some mechanism nobody bothered to name 🙈. That let us focus on what the routers in a multihomed site need to do to forward packets to the correct ISP based on source address. Now it's time to look at ways hosts could pick the right source address 💅. We also check out what role, if any, the routers might play in giving hosts info that helps them choose 🫶.
It's worth noting that this section is about how hosts could select the default source address for new connections 🦋. Any connection that already exists on a host is bound to a specific source address, and that address cannot be changed 😭. Section 6.7 gets into this connections preservation issue in more detail 💜.
Any host that needs to send traffic over the uplinks to a given ISP is expected to be configured with an address from the prefix that ISP assigned 🎀. The host controls which ISP its traffic goes out through by picking one of its configured addresses as the source address for outgoing traffic 👑. It's the site network's job to make sure a packet with a source address from an ISP is now sent on an uplink to that ISP 🌸.
If all of the ISP uplinks are working, the host's choice of source address might be driven by wanting to load share across the uplinks 🍓. Or it might be driven by wanting to take advantage of certain properties of a particular uplink or ISP, if some information about various path properties has been made available to the host somehow (see [PROV-DOMAINS] as an example) 🧚. But if any of the ISP uplinks isn't working, the host's choice of source address can cause packets to get dropped 💀.
How a host selects a suitable source address in a multihomed site is not a solved problem 😤. We don't attempt to solve it in this document. Instead we talk about the current state of affairs with respect to standardized solutions and how those solutions are implemented 📚. We also look at proposed solutions for this problem 🔥.
An external host that starts communication with a host inside a PA-multihomed site needs to know multiple addresses for that host, so it can talk to it using different ISPs to the multihomed site. Knowing just one address would undermine all the benefits of redundant connectivity that multihoming provides 🙅♀️. These addresses are typically learned through DNS. (For simplicity, we assume the external host is single-homed.) The external host picks which ISP gets used at the remote multihomed site by setting the destination address on the packets it sends 🌈. For a session originated from an external host to an internal host, the internal host's source address choice is simple. It has no choice but to use the destination address in the received packet as the source address of the transmitted packet 🫠.
For a session originated by a host inside the multihomed site, choosing the source address is more complicated 🌀. We consider three main methods for hosts to get information about the network. The two proactive methods are Neighbor Discovery Router Advertisements and DHCPv6. The one reactive method we consider is ICMPv6 ⭐. Note that we are explicitly excluding the possibility of having hosts participate in, or even listen directly to, routing protocol advertisements 🚫.
First, let's look at how a host is currently expected to select the default source and destination addresses to be used for a new connection 🦋.
6.1. Default Source Address Selection Algorithm on Hosts ✨
okay bestie, let's talk about how hosts pick their source address 💖 [RFC6724] is the rulebook for this. It defines one algorithm for picking a source address and a separate one for picking a destination address, and both of them lean on a policy table. [RFC6724] also ships a default policy that produces certain behavior 🎀
The rules in those two algorithms depend on a lot of address properties. Those details matter if you want to know how a host should choose addresses in any random environment. But most of the rules don't help when a host has several source addresses in a multihomed setup and is sending to a remote host. So let's go back to the Figure 3 example and check what the default algorithms in [RFC6724] say about the source address that internal host H31 should use to reach external host H101 somewhere on the Internet 🦋
There's no decision to make about the destination address. H31 needs to send a packet with D=2001:db8:0:1234::101 to reach H101. So H31 has to pick between S=2001:db8:0:a010::31 and S=2001:db8:0:b010::31 as the source. We'll go through the source address selection rules in Section 5 of [RFC6724] 👑
Rule 1 (Prefer same address) can't break the tie 🙈 Neither candidate source address equals the destination address, so it's a no-go.
Rule 2 (Prefer appropriate scope) isn't helpful here either. Both source addresses and the destination address have global scope, so it's all even 💅
Rule 3 (Avoid deprecated addresses) is the one that applies to an address autoconfigured by a host through stateless address autoconfiguration as defined in [RFC4862] 🌸 An autoconfigured address has a preferred lifetime and a valid lifetime. It's preferred until the preferred lifetime runs out, and then it turns deprecated. A deprecated address is not used if a preferred address of the appropriate scope is available. Once the valid lifetime expires, the address can't be used at all 😭 The preferred and valid lifetimes for an autoconfigured address are set from the matching lifetimes in the Prefix Information Option in Neighbor Discovery Router Advertisements.
In this scenario, one tool a host could use to control source address selection is deprecating an address. Routers on that link, R1 and R2 in Figure 3, would send Router Advertisement messages containing PIOs with the Preferred Lifetime for the deprecated source prefix set to zero. Honestly this is a pretty blunt tool 💀 It discourages or prohibits using that source prefix for all destinations. It can still be useful in some situations, though. For example, if all uplinks to a particular ISP fail, it's desirable to stop hosts from using source addresses from that ISP's address space 🍓
Rule 4 (Avoid home addresses) doesn't apply here because we aren't considering Mobile IP 🙅♀️
Rule 5 (Prefer outgoing interface) isn't useful in this scenario because both source addresses are assigned to the same interface 🧚
Rule 5.5 (Prefer addresses in a prefix advertised by the next-hop) isn't useful when both R1 and R2 advertise both source prefixes. However, this rule might let a host pick the correct source prefix by picking a next-hop. The most obvious way is for R1 to advertise itself as a default router and send a PIO for 2001:db8:0:a010::/64, while R2 advertises itself as a default router and sends a PIO for 2001:db8:0:b010::/64. We'll talk later about how Rule 5.5 can influence source address selection in single-router topologies, like when H41 is sending traffic using R3 as its default gateway 🌈
Rule 6 (Prefer matching label) is about the label value that gets determined for each source and destination prefix after the policy table is applied to the prefix. With the default policy table defined in Section 2.1 of [RFC6724], Label(2001:db8:0:a010::31) = 5, Label(2001:db8:0:b010::31) = 5, and Label(2001:db8:0:1234::101) = 5. So with the default policy, Rule 6 doesn't break the tie 🥺 But the algorithms in [RFC6724] are defined so that non-default address selection policy tables can be used. [RFC7078] defines a way to distribute a non-default address selection policy table to hosts using DHCPv6. So even though Rule 6 isn't useful with the default policy table here, it can still be a useful tool ✨
Rule 7 (Prefer temporary addresses) is about the technique in [RFC4941] that periodically randomizes the interface portion of an IPv6 address generated through stateless address autoconfiguration. If H31 used this technique, it would apply to both source addresses. For example, it would create the temporary addresses 2001:db8:0:a010:2839:9938:ab58:830f and 2001:db8:0:b010:4838:f483:8384:3208, in addition to 2001:db8:0:a010::31 and 2001:db8:0:b010::31. So this rule would prefer the two temporary addresses, but it wouldn't break the tie between the two source prefixes from ISP-A and ISP-B 🦋
Rule 8 (Use longest matching prefix) says that between two candidate source addresses, the host picks the one whose common prefix length with the destination address is longest 🔥 For example, if H31 were choosing a source address for sending packets to H101, this rule wouldn't break the tie between the candidate source addresses 2001:db8:0:a101::31 and 2001:db8:0:b101::31, because the common prefix length with the destination is 48. But if H31 were choosing a source address for sending packets to H41 at 2001:db8:0:a020::41, then this rule would result in using 2001:db8:0:a101::31 as the source. (2001:db8:0:a101::31 and 2001:db8:0:a020::41 share the common prefix 2001:db8:0:a000::/58, while 2001:db8:0:b101::31 and 2001:db8:0:a020::41 only share 2001:db8:0:a000::/51.) So Rule 8 might help pick the correct source address in some scenarios, but not all of them. For example, if ISP-B services belong to 2001:db8:0:b000::/59, then H31 would always use 2001:db8:0:b010::31 to access those destinations 💅
So out of the eight source address selection rules in [RFC6724], four actually apply to our basic site multihoming scenario 🎀 The relevant rules are summarized below.
- Rule 3: Avoid deprecated addresses.
- Rule 5.5: Prefer addresses in a prefix advertised by the next-hop.
- Rule 6: Prefer matching label.
- Rule 8: Prefer longest matching prefix.
The two methods we discuss for controlling source address selection through those four rules are SLAAC Router Advertisement messages and DHCPv6 🌸
We also consider a possible role for ICMPv6 in getting traffic-driven feedback from the network 👀 With the source address selection algorithm above, the goal is to choose the correct source address on the first try, before any traffic gets sent. Another strategy is to choose a source address, send the packet, get feedback from the network about whether that source address is correct, and try a different one if it isn't 🧚
We look at four scenarios where a host needs to select the correct source address. In the first, both uplinks are working. In the second, one uplink has failed. The third is when one failed uplink has recovered. The last is when both (all) uplinks fail 😭
It should be noted that [RFC6724] only defines how IPv6 hosts select default addresses that applications and upper-layer protocols can use. Applications and upper-layer protocols can make their own choices about source addresses 💜 The mechanism proposed in this document tries to make sure that the subset of source addresses available to applications and upper-layer protocols gets selected with up-to-date network state in mind. The rest of the document discusses various aspects of the default source address selection defined in [RFC6724], which we'll call "the source address selection" for brevity ✨
6.2. Selecting Default Source Address When Both Uplinks Are Working 🌈
Back to the Figure 3 topology we go 🦋 Say the site administrator wants a policy where all hosts have to use ISP-A to reach H101 at D=2001:db8:0:1234::101. So for example, H31 needs to select S=2001:db8:0:a010::31 💖
6.2.1. Distributing Default Address Selection Policy Table with DHCPv6 🎀
This policy can be implemented by using DHCPv6 to distribute an address selection policy table. That table assigns the same label to destination addresses matching 2001:db8:0:1234::/64 as it does to source addresses matching 2001:db8:0:a000::/52. The following two entries get this done 🧚
Prefix Precedence Label
2001:db8:0:1234::/64 50 33
2001:db8:0:a000::/52 50 33
Figure 9: Policy Table Entries to Implement a Routing PolicyThis requires that hosts implement [RFC6724], the basic source and destination address framework, along with [RFC7078], the DHCPv6 extension for distributing a non-default policy table. Note that it does NOT require hosts to use DHCPv6 for address assignment 🙈 Hosts can still use stateless address autoconfiguration for addressing, while using DHCPv6 only for policy table distribution (see [RFC8415]). However, this method has a few disadvantages 😬
- DHCPv6 support is not a mandatory requirement for IPv6 hosts [RFC8504], so this method might not work for all devices.
- Network administrators are required to explicitly configure the desired network access policies on DHCPv6 servers. While that might be feasible for a single multihomed network, this approach might run into scalability issues, especially if a centralized DHCPv6 solution is deployed to serve a large number of multihomed sites 💀
6.2.2. Controlling Default Source Address Selection with Router Advertisements ✨
Okay so Neighbor Discovery has two ways to tell hosts about prefixes 🌸. The base spec ([RFC4861]) gives us the Prefix Information Option (PIO) inside the Router Advertisement (RA) message. When a host gets a PIO with the A-flag [RFC8425] set, it can use that prefix as a source prefix and build its own IP address with the stateless address autoconfiguration (SLAAC) procedures described in [RFC4862]. In the Figure 3 example, if the site network is using SLAAC, we'd expect both R1 and R2 to send RA messages with PIOs that have the A-flag set, one for 2001:db8:0:a010::/64 and one for 2001:db8:0:b010::/64. Then H31 runs SLAAC and configures itself with 2001:db8:0:a010::31 and 2001:db8:0:b010::31 💅.
Now, while a host learns about source prefixes from PIOs, it can learn about a destination prefix from a Router Advertisement containing a Route Information Option (RIO), as specified in [RFC4191]. The destination prefixes in RIOs are meant to help a host pick which router it uses as its first hop to reach a certain destination prefix 🧚.
Here's the catch 🙈. As currently standardized, neither the PIO nor the RIO in a Neighbor Discovery RA can carry the info needed to make the routing policy actually work. PIOs give us source prefixes, RIOs give us destination prefixes, and there's no standard way to directly link one destination prefix to one source prefix. Lowkey a big gap.
[SADR-RA] proposes a Source Address Dependent Route Information option for Neighbor Discovery RAs that would tie a source prefix to a destination prefix. The details of [SADR-RA] might need some tweaking for this use case 🔧. Still, to use RAs to implement this routing policy, we need an extension that lets R1 and R2 explicitly tell H31 about the association between S=2001:db8:0:a000::/52 and D=2001:db8:0:1234::/64 🫶.
That said, Rule 5.5 of the default source address selection algorithm (discussed in Section 6.1), along with default router preference (specified in [RFC4191]) and RIO, can already be used to influence source address selection on a host. Let's look at host H41. It receives RAs from R3 with PIOs for 2001:db8:0:a020::/64 and 2001:db8:0:b020::/64. At that point, all traffic would use the same next-hop (R3's link-local address), so Rule 5.5 doesn't apply yet 🤷♀️.
Now let's say R3 supports SADR and has two scoped forwarding tables: one scoped to S=2001:db8:0:a000::/52 and another scoped to S=2001:db8:0:b000::/52. If R3 generates two different link-local addresses for its interface facing H41 (one per scoped forwarding table, LLA_A and LLA_B), then R3 sends two different RAs. One comes from LLA_A and includes a PIO for 2001:db8:0:a020::/64, and the other comes from LLA_B and includes a PIO for 2001:db8:0:b020::/64. Now we can influence H41's source address selection for destinations that follow the default route by setting the default router preference in the RAs 🎀. If we want H41 to reach H101 (or any destination on the Internet) via ISP-A, then the RAs sent from LLA_A should have the default router preference set to 01 (high priority), while the RAs sent from LLA_B should have it set to 11 (low). LLA_A then gets picked as the next-hop for H101, and therefore (per Rule 5.5) 2001:db8:0:a020::41 gets selected as the source address 💖. If, at the same time, we want H61 to be accessible via ISP-B, then R3 should include a RIO for 2001:db8:0:6666::/64 in its RA sent from LLA_B. H41 will choose LLA_B as the next-hop for all traffic to H61, and then per Rule 5.5, 2001:db8:0:b020::41 gets selected as the source address 🌈.
Now, if in that scenario we want all Internet traffic to leave the network via ISP-A, and the link to ISP-B is only used for accessing ISP-B services (not as a backup for the ISP-A link), then the RAs R3 sends from LLA_B should have their Router Lifetime values set to zero and should include RIOs for ISP-B address space. This tells H41 to use LLA_A for all Internet traffic, but to use LLA_B as the next-hop when it sends traffic to ISP-B addresses 👑.
The mechanism above assumes that both the first-hop routers and the SERs support SADR. A first-hop router can still offer a less flexible version of this even without implementing SADR, though 🍓. It can do this with configuration knobs that let it generate different link-local addresses and send individual RAs for each prefix.
The mechanism described above relies on Rule 5.5 of the default source address selection algorithm defined in [RFC6724]. [RFC8028] states that "A host SHOULD select default routers for each prefix it is assigned an address in." It also recommends that hosts implement Rule 5.5 of [RFC6724]. So hosts that follow the recommendations in [RFC8028] should be able to benefit from the solution in this document, and no standards need to be updated for host behavior. Bestie, that's a W 🎉.
6.2.3. Controlling Default Source Address Selection with ICMPv6 ✨
Next up: how we might use ICMPv6 to enforce the routing policy and send traffic destined for H101 out the uplink to ISP-A, even when the uplinks to both ISPs are working 🦋. If H31 starts sending traffic to H101 with S=2001:db8:0:b010::31 and D=2001:db8:0:1234::101, the traffic gets routed through SER-b1 and out the uplink to ISP-B. SERb1 could notice that this traffic isn't following the desired routing policy and respond by sending an ICMPv6 message back to H31 😤.
In this example, SERb1 drops the packet with S=2001:db8:0:b010::31 and D=2001:db8:0:1234::101, then sends H31 an ICMPv6 Destination Unreachable message with Code 5 (Source address failed ingress/egress policy). When H31 gets this, it is expected to try another source address to reach the destination. So H31 sends a packet with S=2001:db8:0:a010::31 and D=2001:db8:0:1234::101, which reaches SERa and gets forwarded out the uplink to ISP-A ✨.
We also want SERb1 to NOT enforce this policy when the uplink from SERa to ISP-A has failed 💀. We can do that by having SERa originate a source-prefix-scoped route for (S=2001:db8:0:a000::/52, D=2001:db8:0:1234::/64), and having SERb1 monitor whether that route is present. If the route isn't there (because SERa stopped originating it), SERb1 won't enforce the routing policy, and it will forward packets with S=2001:db8:0:b010::31 and D=2001:db8:0:1234::101 out its uplink to ISP-B.
We can also use this source-prefix-scoped route from SERa to pass the desired routing policy along to SERb1 🧠. We can define an EXCLUSIVE flag to be advertised together with the IGP route for (S=2001:db8:0:a000::/52, D=2001:db8:0:1234::/64). This lets SERa tell SERb that SERb should reject traffic for D=2001:db8:0:1234::/64 and respond with an ICMPv6 Destination Unreachable Code 5 message, as long as the route for (S=2001:db8:0:a000::/52, D=2001:db8:0:1234::/64) is present. Defining an EXCLUSIVE flag for SADR advertisements in IGPs would need future standardization work 📚.
Finally, if we're willing to extend ICMPv6 to support this, we could create a way for SERb1 to tell the host which source address to use so that packets get forwarded successfully and meet the policy 🎯. Right now, when SERb1 sends an ICMPv6 Destination Unreachable Code 5 message, it's basically saying, "This source address is wrong. Try another source address." Without a clear hint about which address to try next, the host will go through every address assigned to the interface (for example, various privacy addresses). That leads to big delays and a sad user experience 😭. It would be way better if the ICMPv6 message could say, "This source address is wrong. Instead use a source address in S=2001:db8:0:a000::/52".
Using ICMPv6 to send source address info back to hosts comes with its own challenges, though 🙃. Most routers have software or hardware limits on how many ICMP messages they generate. A site administrator deploying a solution that relies on the SERs generating ICMP messages could try to boost SER performance for generating them. But in a large network, ICMP message generation limits will probably still get hit. When that happens, hosts don't get the ICMPv6 back, which leads to traffic blackholing and poor user experience. To make ICMPv6-based signaling more scalable, hosts SHOULD cache the preferred source address (or prefix) for a given destination. This might cause issues if the corresponding ISP uplink fails (see Section 6.3). In addition, the same source prefix SHOULD be used for other destinations in the same /64 as the original destination address. The source prefix-to-destination mapping SHOULD have a specific lifetime, and when that lifetime expires, it SHOULD trigger the source address selection algorithm again ⏳.
Using ICMPv6 Destination Unreachable messages with Code 5 to influence source address selection brings some security challenges, which are discussed in Section 10 🔐.
As currently standardized in [RFC4443], the ICMPv6 Destination Unreachable message with Code 5 allows for the iterative approach of retransmitting packets with different source addresses 🔁. But as currently defined, the ICMPv6 message doesn't say which source prefix should be used for a retransmitted packet. This document doesn't define such a mechanism, though it might be a useful extension for a different document 🌟. This approach also has security implications. For example, an attacker could send spoofed ICMPv6 messages to signal an invalid or unreachable source prefix, causing a DoS-type attack 🚨.
6.2.4. Summary of Methods for Controlling Default Source Address Selection to Implement Routing Policy ✨
Okay so, to recap this section 💅: we looked at three methods for a simple routing policy where all traffic for a given destination on the Internet needs to use a particular ISP, even when the uplinks to both ISPs are working 🦋.
The default source address selection policy can't tell apart the source addresses needed to enforce this policy 😭, so a non-default policy table that associates source and destination prefixes using label values would need to be installed on each host. There is a mechanism for DHCPv6 to distribute a non-default policy table, but that solution would heavily rely on DHCPv6 support in the host operating system 💀. Plus, there's no mechanism to translate desired routing/traffic engineering policies into policy tables on DHCPv6 servers. So using DHCPv6 to control the address selection policy table is not recommended and SHOULD NOT be used 🙈.
Router Advertisements, on the other hand, are giving reliable 👑. They can influence the source address selection process through PIO, RIO, and default router preferences. All of those options are already standardized by the IETF and supported by various operating systems, so no changes are required on hosts 🌸. First-hop routers in the enterprise network do need to be capable of sending different RAs for different SLAAC prefixes (either based on scoped forwarding tables or based on preconfigured policies) ✨.
SERs can enforce the routing policy by sending ICMPv6 Destination Unreachable messages with Code 5 (Source address failed ingress/egress policy) for traffic sent with the wrong source address 🔥. The policy distribution could be automated by defining an EXCLUSIVE flag for the source-prefix-scoped route, which could then be set on the SER that originates the route 🧚. But ICMPv6 message generation can be rate limited on routers, so it SHOULD NOT be used as the only mechanism to influence source address selection on hosts 😭. Hosts SHOULD select the correct source address for a given destination, and the network SHOULD signal any source address issues back to hosts using ICMPv6 error messages 🫶.
6.3. Selecting Default Source Address When One Uplink Has Failed 🌈
Now we check whether DHCPv6, Neighbor Discovery Router Advertisements, and ICMPv6 can help a host choose the right source address when an uplink to one of the ISPs has failed 👀. Again we look at the scenario in Figure 3. This time we look at traffic from H31 destined for external host H501 at D=2001:db8:0:5678::501. We initially assume that the uplink from SERa to ISP-A is working and that the uplink from SERb1 to ISP-B is working.
We assume there is no particular routing policy desired, so H31 is free to send packets with S=2001:db8:0:a010::31 or S=2001:db8:0:b010::31 and have them delivered to H501. For this example, we assume that H31 has chosen S=2001:db8:0:b010::31 so that the packets exit via SERb to ISP-B. Now we see what happens when the link from SERb1 to ISP-B fails. How should H31 learn that it needs to start sending packets to H501 with S=2001:db8:0:a010::31 in order to start using the uplink to ISP-A? We need to do this in a way that doesn't stop H31 from still sending packets with S=2001:db8:0:b010::31 in order to reach H61 at D=2001:db8:0:6666::61 🎀.
6.3.1. Controlling Default Source Address Selection with DHCPv6 📋
For this example, we assume that the site network in Figure 3 has a centralized DHCP server and that all routers act as DHCP relay agents. We assume that both of the addresses assigned to H31 were assigned via DHCP.
We could try to have the DHCP server monitor the state of the uplink from SERb1 to ISP-B in some manner, and then tell H31 that it can no longer use S=2001:db8:0:b010::31 by setting its valid lifetime to zero 😬. The DHCP server could start this process by sending a Reconfigure message to H31 as described in Section 18.3 of [RFC8415]. Or the DHCP server can assign addresses with short lifetimes to force clients to renew them often 🔄.
This approach would stop H31 from using S=2001:db8:0:b010::31 to reach a host on the Internet. However, it would also stop H31 from using S=2001:db8:0:b010::31 to reach H61 at D=2001:db8:0:6666::61, which is not desirable 🙅♀️.
Another possible approach is to have the DHCP server monitor the uplink from SERb1 to ISP-B and control the choice of source address on H31 by updating its address selection policy table via the mechanism in [RFC7078]. The DHCP server could start this process by sending a Reconfigure message to H31. Note that [RFC8415] requires that Reconfigure messages use DHCP authentication. DHCP authentication could be skipped by using short address lifetimes to force clients to send Renew messages to the server often. If the host does not get its IP addresses from the DHCP server, then it would need to use the Information Refresh Time option defined in [RFC8415] 🧠.
If the following policy table can be installed on H31 after the failure of the uplink from SERb1, then the desired routing behavior should be achieved based on source and destination prefix being matched with label values 💖.
Prefix Precedence Label
::/0 50 44
2001:db8:0:a000::/52 50 44
2001:db8:0:6666::/64 50 55
2001:db8:0:b000::/52 50 55
Figure 10: Policy Table Needed on Failure of Uplink from SERb1The described solution has a number of big drawbacks, some of them already covered in Section 6.2.1 😩.
- DHCPv6 support is not required for an IPv6 host, and there are operating systems that don't support DHCPv6 🙃. Besides that, it doesn't look like [RFC7078] has been widely implemented on host operating systems 💀.
- [RFC7078] doesn't clearly specify this kind of dynamic use case, where the address selection policy needs to be updated quickly in response to the failure of a link 🚨. In a large network, it would have scalability issues because many hosts would need to be reconfigured in a very short period of time 😵.
- Updating DHCPv6 server configuration every time an ISP's uplink changes state causes some scalability issues, especially for mid-sized and large distributed enterprise networks 📉. On top of that, the policy table needs to be configured manually by administrators, which makes this solution prone to human error 🙈.
- No mechanism exists for making DHCPv6 servers aware of network topology or routing changes in the network. In general, having DHCPv6 servers monitor network-related events sounds like a bad idea, since it needs completely new functionality beyond the scope of the DHCPv6 role 🚫.
6.3.2. Controlling Default Source Address Selection with Router Advertisements 📡
The same mechanism discussed in Section 6.2.2 can be used to control source address selection when there's an uplink failure. If a particular prefix should not be used as a source for any destination, then the router needs to send an RA with the Preferred Lifetime field for that prefix set to zero 🍓.
Let's look at a scenario where all uplinks are operational. H41 receives two different RAs from R3: one from LLA_A with a PIO for 2001:db8:0:a020::/64 and the default router preference set to 11 (low), and another one from LLA_B with a PIO for 2001:db8:0:a020::/64, the default router preference set to 01 (high), and a RIO for 2001:db8:0:6666::/64. As a result, H41 uses 2001:db8:0:b020::41 as a source address for all Internet traffic, and those packets are sent by SERs to ISP-B 🌟. If SERb1's uplink to ISP-B fails, the desired behavior is that H41 stops using 2001:db8:0:b020::41 as a source address for all destinations except H61 🥺.
To make that happen, R3 should react to SERb1's uplink failure (which could be detected as the disappearance of the scoped route (S=2001:db8:0:b000::/52, D=::/0)) by withdrawing itself as a default router. R3 sends a new RA from LLA_B with the Router Lifetime value set to zero (which means it should not be used as the default router). That RA still contains a PIO for 2001:db8:0:b020::/64 (for SLAAC purposes) and a RIO for 2001:db8:0:6666::/64, so H41 can reach H61 using LLA_B as a next-hop and 2001:db8:0:b020::41 as a source address 🦋. For all traffic following the default route, LLA_A will be used as a next-hop and 2001:db8:0:a020::41 as a source address ✨.
If all of the uplinks to ISP-B have failed, source addresses from ISP-B address space should not be used. In that failure scenario, the forwarding table scoped to S=2001:db8:0:b000::/52 has no entries, which tells R3 to instruct hosts to stop using source addresses from 2001:db8:0:b000::/52 by sending RAs containing PIOs with Preferred Lifetime values set to zero 🛑.
6.3.3. Controlling Default Source Address Selection with ICMPv6 🚨
Now let's look at how ICMPv6 messages can send information back to H31. We assume again that, at the time of the failure, H31 is sending packets to H501 using (S=2001:db8:0:b010::31, D=2001:db8:0:5678::501). When the uplink from SERb1 to ISP-B fails, SERb1 would stop originating its source-prefix-scoped route for the default destination (S=2001:db8:0:b000::/52, D=::/0), as well as its unscoped default destination route 🕳️. With those routes no longer in the IGP, traffic with (S=2001:db8:0:b010::31, D=2001:db8:0:5678::501) would end up at SERa, based on the unscoped default destination route that SERa originates 🌀.
Since that traffic has the wrong source address to be forwarded to ISP-A, SERa would drop it and send a Destination Unreachable message with Code 5 (Source address failed ingress/egress policy) back to H31 🙅♀️. H31 would then know to use another source address for that destination, and would try with (S=2001:db8:0:a010::31, D=2001:db8:0:5678::501) 💜. That traffic would be forwarded to SERa, based on the source-prefix-scoped default destination route that SERa still originates, and SERa would forward it to ISP-A 🚀.
As discussed above, if we're willing to extend ICMPv6, SERa can even tell H31 which source address it should use to reach that destination 🧚♀️. The expected host behavior was covered in Section 6.2.3. Using ICMPv6 would have the same scalability and rate limiting issues discussed in Section 6.2.3 😬. An ISP-B uplink failure immediately makes source addresses from 2001:db8:0:b000::/52 unsuitable for external communication, and it might trigger a large number of ICMPv6 packets being sent to hosts in that subnet 📨💀.
6.3.4. Summary of Methods for Controlling Default Source Address Selection on the Failure of an Uplink ✨
okay so DHCPv6 is lowkey NOT it for this 💀. It doesn't seem especially good at quickly changing which source address a host uses when an uplink fails, so it's out of the running 🙈. Router Advertisements, though? They're giving reliable 💅. They can dynamically hand hosts a list of valid prefixes to use as source addresses, and they can also stop particular prefixes from being used. No new features are required on hosts 🫶, but routers do need to be able to send RAs based on the state of scoped forwarding table entries, and they need to react to network topology changes by sending RAs with particular parameters set 🔥.
It seems like ICMPv6 Destination Unreachable messages from the SER (or any SADR-capable) routers, paired with RAs to signal source address selection errors back to hosts, could be a support mechanism 🧚. BUT scalability issues may show up in big networks when the topology suddenly changes 😭. So it's really desirable that hosts can pick the correct source address when an uplink fails, with ICMPv6 as an extra way to flag unexpected failures back to hosts 💖.
Honestly, the authors aren't clear on how different host operating systems behave when they get an ICMPv6 Destination Unreachable message with Code 5 (Source address failed ingress/egress policy) 🤷♀️. Info from implementers, users, and testing would be super helpful for evaluating this approach 🎀.
6.4. Selecting Default Source Address upon Failed Uplink Recovery 🌸
next up: what happens when a failed uplink on SERb1 to ISP-B comes back online, so hosts can start using source addresses from 2001:db8:0:b000::/52 again 🦋.
6.4.1. Controlling Default Source Address Selection with DHCPv6 🍓
using DHCPv6 to tell the hosts (H31 in our example) to start using prefixes from ISP-B space (e.g., S=2001:db8:0:b010::31 for H31) to reach hosts on the Internet is pretty much the same as what we covered in Section 6.3.1, and it has the same drawbacks 🙃.
6.4.2. Controlling Default Source Address Selection with Router Advertisements 📡
let's look at the scenario from Section 6.3.2 💫. If the uplink failure caused the complete withdrawal of prefixes from 2001:db8:0:b000::/52 by setting the Preferred Lifetime value to zero, then when the link recovers, all it takes is sending a new RA with a non-zero Preferred Lifetime ✨.
there's another scenario from Section 6.3.2 too: when the SERb1 uplink to ISP-B fails, the (S=2001:db8:0:b000::/52, D=::/0) entry disappears from the forwarding table scoped to S=2001:db8:0:b000::/52. That makes R3 send RAs with the Router Lifetime set to zero from LLA_B 😵. When the SERb1 uplink to ISP-B recovers, the scoped forwarding entry (S=2001:db8:0:b000::/52, D=::/0) shows up again. That reappearance acts as a signal for R3 to advertise itself as a default router for the ISP-B address space domain (sending RAs from LLA_B with a non-zero Router Lifetime) 🎉.
6.4.3. Controlling Default Source Address Selection with ICMP 🙈
ICMPv6 looks pretty limited when it comes to telling hosts that certain source addresses are valid again 🥲. Unless the uplink changes specify a particular (S,D) pair, hosts can keep using the same source address even after an ISP uplink is back up 😬.
for example: after the uplink from SERb1 to ISP-B failed, H31 got an ICMPv6 Code 5 message (as described in Section 6.3.3) and allegedly started using (S=2001:db8:0:a010::31, D=2001:db8:0:5678::501) to reach H501. Now the SERb1 uplink is back up, but packets with that (S,D) pair are still routed to SERa1 and sent out to the Internet 🙃. So H31 never finds out that it should stop using 2001:db8:0:a010::31 and go back to 2001:db8:0:b010::31. Unless SERa has a policy configured to drop packets (S=2001:db8:0:a010::31, D=2001:db8:0:5678::501) and send ICMPv6 back when the SERb1 uplink to ISP-B is up, H31 will be totally unaware of the topology change and will keep using S=2001:db8:0:a010::31 for Internet destinations, including H51 💀.
one of the possible options is a scoped route with an EXCLUSIVE flag, as described in Section 6.2.3 🧠. When the SERa1 uplink recovers, the (S=2001:db8:0:a000::/52, D=2001:db8:0:1234::/64) route would reappear in the routing table. Without it, packets to H101 are sent to ISP-B (since the ISP-A uplink is down) using source addresses from 2001:db8:0:b000::/52. When the route reappears, SERb1 rejects those packets and sends ICMPv6 back, as discussed in Section 6.2.3 🔄. In practice, this could lead to scalability issues, which were already discussed in 6.2.3 and 6.4.3 📉.
6.4.4. Summary of Methods for Controlling Default Source Address Selection upon Failed Uplink Recovery 👑
once again, DHCPv6 doesn't look like a reasonable pick for steering source address selection on a host when the topology changes 🙅♀️. Router Advertisements give you a flexible way to react dynamically to topology changes (as long as routers can use routing changes as a trigger for sending out RAs with specific parameters) 💅. ICMPv6 could be considered as a supporting mechanism to signal an incorrect source address back to hosts, but it should not be considered as the only mechanism for controlling address selection in multihomed environments 🫶.
6.5. Selecting Default Source Address When All Uplinks Have Failed 🥀
this one is a tricky case 😩: all uplinks have failed. In that situation there's no valid source address to use for any external destinations, even though intra-site connectivity might still be desirable 🏠.
6.5.1. Controlling Default Source Address Selection with DHCPv6 🙃
from the DHCPv6 point of view, uplink failures should be treated as two independent failures and processed as described in Section 6.3.1. Right now it's pretty obvious that this would result in a super complicated policy table that administrators would have to configure explicitly, so it seems impractical 📋💀.
6.5.2. Controlling Default Source Address Selection with Router Advertisements 🌈
as discussed in Section 6.3.2, an uplink failure makes the scoped default entry vanish from the scoped forwarding table and triggers RAs with zero Router Lifetimes 🫠. When all scoped entries for a given source prefix are completely gone, that prefix gets withdrawn from hosts by setting the Preferred Lifetime value to zero in the PIO. If all uplinks (SERa, SERb1 and SERb2) fail, hosts either lose their default routers and/or have no global IPv6 addresses to use as a source 😱. (Note that 'uplink failure' might mean 'IPv6 connectivity failure with IPv4 still being reachable', in which case hosts might fall back to IPv4 if there's IPv4 connectivity to destinations 🙏.) As a result, intra-site connectivity breaks 💔. One of the possible ways to fix that is to use ULAs ✨.
on top of GUAs, all hosts have ULA addresses assigned, and those are used for intra-site communication even when a host has no GUA 🏡. To avoid accidentally leaking packets with ULA sources, SADR-capable routers SHOULD have a scoped forwarding table for ULA source for internal routes, but they MUST NOT have an entry for D=::/0 in that table 🚫. Without (S=ULA_Prefix; D=::/0), first-hop routers send dedicated RAs from a unique link-local source LLA_ULA, with a PIO from ULA address space, a RIO for the ULA prefix, and Router Lifetime set to zero 📡. This matches what happens when SERb1 loses its uplink to ISP-B (so there's no Internet connectivity from 2001:db8:0:b000::/52 sources), but those sources can still reach some specific destinations 🧚. With ULA, there's no Internet connectivity from ULA sources, but they can reach other ULA destinations 🫶. ULA usage could be especially useful if all ISPs assign prefixes via DHCP prefix delegation 🎀. Without ULAs, when all uplinks fail, hosts would lose all their GUAs once the prefix lifetime expires, and intra-site communication would be impossible again 😭.
it should be noted that Rule 5.5 (prefer a prefix advertised by the selected next-hop) takes precedence over Rule 6 (prefer matching label, which makes GUA source addresses preferred over ULAs for GUA destinations) 🧐. So if ULAs are used, the network administrator needs to make sure that, while the site has Internet connectivity, hosts don't select a router that advertises ULA prefixes as their default router 👀.
6.5.3. Controlling Default Source Address Selection with ICMPv6 🙈
when all uplinks fail, every SER drops outgoing IPv6 traffic and responds with ICMPv6 error messages 🛑. In a large network where lots of hosts try to reach Internet destinations, the SERs would need to generate an ICMPv6 error for every packet they get from hosts. That runs into the same scalability issues discussed in Section 6.3.3 📉💀.
6.5.4. Summary of Methods for Controlling Default Source Address Selection When All Uplinks Failed 💅
again, combining SADR with Router Advertisements seems to be the most flexible and scalable way to control source address selection on hosts 👑✨.
6.6. Summary of Methods for Controlling Default Source Address Selection 💅
okay bestie, this section is the big recap 🎀 of every scenario and option we just went through 🫶
DHCPv6 can let admins mess with the source address selection policy tables, but it comes with a bunch of major downsides that kick it off the list of possible solutions 😭:
- It requires hosts to support DHCPv6 and its extension [RFC7078].
- A DHCPv6 server needs to monitor network state and detect routing changes.
- The use of policy tables requires manual configuration and might be extremely complicated, especially in the case of a distributed network in which a large number of remote sites are being served by centralized DHCPv6 servers.
- Network topology/routing policy changes could trigger simultaneous reconfiguration of large number of hosts, which presents serious scalability issues.
Now the Router Advertisement era ✨. Using Router Advertisements to influence source address selection on hosts seems to be the most reliable, flexible, and scalable solution 👑. It comes with these perks:
- No new (non-standard) functionality needs to be implemented on hosts (except for RIO support [RFC4191], which is not widely implemented at the time of this writing).
- No changes in RA format.
- Routers can react to routing table changes by sending RAs, which would minimize the failover time in the case of network topology changes.
- Information required for source address selection is broadcast to all affected hosts in the case of a topology change event, which improves the scalability of the solution (compared to DHCPv6 reconfiguration or ICMPv6 error messages).
To fully get the RA-based magic ✨, first-hop routers need to implement SADR, belong to the SADR domain, and be able to send dedicated RAs per scoped forwarding table as discussed above, reacting to network changes by sending new RAs. It should be noted that the proposed solution would work even if first-hop routers are not SADR-capable but still able to send individual RAs for each ISP prefix and react to topology changes as discussed above (e.g., via configuration knobs) 🌸.
The RA-based solution leans super hard on hosts correctly implementing the default address selection algorithm as defined in [RFC6724] 🧚. The basic, and most common, multihoming scenario (two or more Internet uplinks, no 'walled gardens') would work for any host supporting the minimal implementation of [RFC6724], but more complex use cases (such as 'walled garden' and other scenarios when some ISP resources can only be reached from that ISP address space) require that hosts support Rule 5.5 of the default address selection algorithm. There is some evidence that not all host OSes have that rule implemented currently. However, it should be noted that [RFC8028] states that Rule 5.5 should be implemented 🙈.
The ICMPv6 Code 5 error message SHOULD be used to complement an RA-based solution to signal incorrect source address selection back to hosts, but it SHOULD NOT be considered as the standalone solution. To prevent scenarios when hosts in multihomed environments incorrectly identify on-link/off-link destinations, hosts SHOULD treat ICMPv6 Redirects as discussed in [RFC8028] 💜.
6.7. Solution Limitations 🥀
6.7.1. Connections Preservation
Okay, real talk: the proposed solution is not designed to preserve connection state when an uplink fails 😭. When all uplinks to an ISP go down, all transport connections established to/from that ISP address space will be interrupted (unless the transport protocol has specific multihoming support). That's similar to IPv4 multihoming with NAT, where an uplink failure causes all connections to be NATed to completely different public IPv4 addresses. Is it suboptimal? Kinda, yes. But it's determined by the nature of PA address space: if all uplinks to the particular ISP have failed, there's no path for ingress traffic to reach the site, and the egress traffic is supposed to be dropped by the ingress filters [BCP38]. The only potential way around this would be to run BGP with all ISPs and advertise all site prefixes to all uplinks, which shares all the drawbacks of using PI address space without sharing its benefits. Networks willing and capable of running BGP and using PI are out of scope of this document 🧐.
It should be noted that with IPv4 NAT-based multihoming, uplink recovery could cause connection interruptions too (unless packet forwarding is integrated with the tracking of existing NAT sessions so that the egress interface for the existing sessions is not changed). BUT the proposed solution has the benefit of preserving existing sessions during and after the restoration of the failed uplink 🦋. Unlike the uplink failure event, which causes all addresses from the affected prefix to be deprecated, recovery would just add new, preferred addresses to a host without making any addresses unavailable. So connections established to and from those addresses don't have to be interrupted ✨.
While it's desirable for active connections to survive ISP failover events, these events affect the reachability of IP addresses assigned to hosts in sites using PA address space. Unless the transport (or higher-level protocols) is capable of surviving the host renumbering, the active connections will be broken. The proposed solution focuses on minimizing the impact of failover on new connections and on multipath-aware protocols 🍓.
Another way to preserve connection state is to use multipath transport as discussed in Section 8.3 💜.
6.8. Other Configuration Parameters ⭐
6.8.1. DNS Configuration
In a multihomed environment, each ISP might provide their own list of DNS servers. For example, in the topology shown in Figure 3, ISP-A might provide H51 2001:db8:0:5555::51 as a recursive DNS server, while ISP-B might provide H61 2001:db8:0:6666::61 as a recursive DNS server (RDNSS). [RFC8106] defines IPv6 Router Advertisement options to allow IPv6 routers to advertise a list of RDNSS addresses and a DNS Search List (DNSSL) to IPv6 hosts. Using RDNSS together with 'scoped' RAs as described above would allow a first-hop router (R3 in Figure 3) to send DNS server addresses and search lists provided by each ISP (or the corporate DNS server addresses if the enterprise is running its own DNS servers. As discussed below, the DNS split-horizon problem is too hard to solve without running a local DNS server) 🧠.
As discussed in Section 6.5.2, failure of all ISP uplinks would cause deprecation of all addresses assigned to a host from the address space of all ISPs. If any intra-site IPv6 connectivity is still desirable (most likely the case for any mid/large-scale network), then ULAs should be used as discussed in Section 6.5.2. In such a scenario, the enterprise network should run its own recursive DNS server(s) and provide its ULA addresses to hosts via RDNSS in RAs sent for ULA-scoped forwarding table as described in Section 6.5.2 🏠.
There are some scenarios where the final outcome of name resolution might be different depending on:
- which DNS server is used;
- which source address the client uses to send a DNS query to the server (DNS split horizon).
There is no way currently to instruct a host to use a particular DNS server from the configured servers list for resolving a particular name. Therefore, it does not seem feasible to solve the problem of DNS server selection on the host (it should be noted that this particular issue is protocol-agnostic and happens for IPv4 as well). In such a scenario, it is recommended that the enterprise run its own local recursive DNS server 💅.
To influence host source address selection for packets sent to a particular DNS server, the following requirements must be met:
- The host supports RIO as defined in [RFC4191].
- The routers send RIOs for routes to DNS server addresses.
For example, if it's desirable that host H31 reaches the ISP-A DNS server H51 2001:db8:0:5555::51 using its source address 2001:db8:0:a010::31, then both R1 and R2 should send RIOs containing the route to 2001:db8:0:5555::51 (or covering route) in their 'scoped' RAs, containing LLA_A as the default router address and the PIO for SLAAC prefix 2001:db8:0:a010::/64. In that case, host H31 (if it supports Rule 5.5) would select LLA_A as a next-hop and then choose 2001:db8:0:a010::31 as the source address for packets to the DNS server 🎯.
It should be noted that [RFC6106] explicitly prohibits using DNS information if the RA Router Lifetime has expired:
An RDNSS address or a DNSSL domain name MUST be used only as long
as both the RA router Lifetime (advertised by a Router
Advertisement message) and the corresponding option Lifetime have
not expired.So hosts might ignore RDNSS information provided in ULA-scoped RAs, since those RAs would have Router Lifetime values set to zero. However, [RFC8106], which obsoletes RFC 6106, has removed that requirement 🌈.
As discussed above, the DNS split-horizon problem and the selection of the correct DNS server in a multihomed environment are not easy problems to solve. The proper solution would require hosts to support the concept of multiple provisioning domains (PvD, a set of configuration information associated with a network, [RFC7556]) 🦋.
7. Deployment Considerations 🛠️
The solution described in this document requires certain mechanisms to be supported by the network infrastructure and hosts. It requires some routers in the enterprise site to support some form of SADR. It also requires hosts to be able to learn when the uplink to an ISP changes its state so that the hosts can use appropriate source addresses. Ongoing work to create mechanisms to accomplish this is discussed in this document, but those are still works in progress 🚧.
7.1. Deploying SADR Domain
The proposed solution does not prescribe particular details regarding deploying an SADR domain within a multihomed enterprise network. However, the following guidelines could be applied:
- The SADR domain is usually limited by the multihomed site border.
- The minimal deployable scenario requires enabling SADR on all SERs and including them into a single SADR domain.
- As discussed in Section 4.2, extending the connected SADR domain beyond the SERs to the first-hop routers can produce more efficient forwarding paths and allow the network to fully benefit from SADR. It would also simplify the operation of the SADR domain.
- During the incremental SADR domain expansion from the SERs down towards first-hop routers, it's important to ensure that, at any given moment, all SADR-capable routers within the domain are logically connected (see Section 5) 🌟.
7.2. Hosts-Related Considerations 💖
Okay so this whole solution leans on the default address selection algorithm, Rule 5.5 from [RFC6724] 🫶. [RFC6724] treats Rule 5.5 as optional, but the newer [RFC8028] says "A host SHOULD select default routers for each prefix it is assigned an address in." It also recommends that hosts should implement Rule 5.5 of [RFC6724]. So hosts that follow RFC 8028 already have a way to notice when ISP uplinks change state and to pick source addresses to match 🌸. The catch? Plenty of hosts don't support that mechanism yet 😭.
Also, a multihomed enterprise network with several ISP prefixes is a classic multiple provisioning domain (mPvD) scenario, as described in [RFC7556] ✨. This document gives the network a way to pass PvD information to hosts indirectly, using mechanisms that already exist 🎀. Meanwhile, [PROV-DOMAINS] goes a step further and describes a full mechanism for hosts to discover the whole set of configuration information tied to each PvD/ISP 👑. It complements this document by helping hosts learn about ISP uplink states and choose the matching source addresses 💅.
8. Other Solutions 🦋
8.1. Shim6 🧚
Okay, the Shim6 protocol [RFC5533] was specified by the Shim6 working group, and it lets a host at a multihomed site talk to an external host and swap info about the possible source and destination address pairs they can use 💜. The Shim6 working group also specified the REAchability Protocol (REAP) [RFC5534], which detects failures on the path between working address pairs and finds new working ones 🔍. The big catch is that both internal and external hosts need to support Shim6. Like, both the host inside the multihomed site and the host outside it have to run Shim6 before the internal host gets any benefit 😩. The Shim6 spec came out in 2009, but it never got widely implemented 💀. So Shim6 isn't considered a viable solution for enterprise multihoming 🙈.
8.2. IPv6-to-IPv6 Network Prefix Translation 🌈
IPv6-to-IPv6 Network Prefix Translation (NPTv6) [RFC6296] isn't the focus of this document 🍓. NPTv6 has the same fundamental issue as every other address translation approach: it breaks end-to-end connectivity 💔. So NPTv6 isn't considered a desirable solution, and this document deliberately focuses on solving the enterprise multihoming problem without any form of address translation ✨.
There's growing interest and ongoing work in bringing path awareness to transport- and application-layer protocols, so hosts might be able to figure out the properties of their various network paths and pick among the ones they have 🔥. Selecting the correct source address is one of the mechanisms path-aware hosts can use, and address translation hurts that path-awareness, which makes NTPv6 an even more undesirable solution 😤.
8.3. Multipath Transport 🫧
Using multipath transport, like Multipath TCP (MPTCP) [RFC6824] or multipath capabilities in QUIC, might solve the problems discussed in Section 6 🤩. A multipath transport would let hosts use multiple source addresses for a single connection and switch between them when one becomes unavailable or a new address gets assigned to the host interface. So if every host in the enterprise network uses only multipath transport for all connections, the signaling solution in Section 6 might not be needed. (Heads up, though: Source Address Dependent Routing would still be required to deliver packets to the correct uplinks 🚦.)
When this document was written, multipath transport alone couldn't count as a solution for source address selection in a multihomed environment 🙅♀️. A lot of hosts don't use multipath transport right now, and it seems unlikely that will change anytime soon. Even if new operating system releases support multipath protocols, there will be a long tail of legacy hosts 🐢. The enterprise solution has to work for the least common denominator, which means hosts without multipath transport support 💅. Plus, not all protocols use multipath transport. Multipath would complement the solution in Section 6, but it can't be the sole solution to source address selection in multihomed environments 🫶.
PA-based multihoming can also give extra benefits to multipath protocols, if those get deployed in the network 🦋. Multipath protocols could use source address selection to get maximum path diversity, and potentially better performance too ✨.
So deploying multipath protocols shouldn't be treated as an alternative to the approach in this document 🙅♀️. Instead, both solutions complement each other, and deploying multipath protocols in a PA-based multihomed network turns out to be mutually beneficial 👑.
9. IANA Considerations ✨
This document has no IANA actions 🌸.
10. Security Considerations 💀
Okay, this section is serious, bestie 😭. Section 6.2.3 discusses a mechanism for controlling source address selection on hosts using ICMPv6 messages. Using ICMPv6 to influence source address selection lets an attacker exhaust the list of candidate source addresses on the host by sending spoofed ICMPv6 Code 5 for all prefixes known on the network. That would stop a victim from setting up communication with the destination host 🚫. Another possible attack vector is using ICMPv6 Destination Unreachable Messages with Code 5 to steer egress traffic toward a particular ISP. The attacker could then benefit from their ability to do traffic sniffing/interception in that ISP network 👀.
To prevent those attacks, hosts SHOULD verify that the original packet header included in the ICMPv6 error message was actually sent by the host. That way, they can be sure the ICMPv6 message was triggered by a packet the host really sent 🛡️.
As ICMPv6 Destination Unreachable Messages with Code 5 could be originated by any SADR-capable router within the domain (or even come from the Internet), the Generalized TTL Security Mechanism (GTSM) [RFC5082] cannot be applied 🥲. Filtering such ICMPv6 messages at the site border cannot be recommended either, because it would break the legitimate end-to-end error signaling mechanism that ICMPv6 was designed for 🙈.
The security considerations of using stateless address autoconfiguration are discussed in [RFC4862] 🧚.
11. References 📚
11.1. Normative References 🎀
[BCP38] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
May 2000, <https://www.rfc-editor.org/info/rfc2827>.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.
J., and E. Lear, "Address Allocation for Private
Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918,
February 1996, <https://www.rfc-editor.org/info/rfc1918>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191,
November 2005, <https://www.rfc-editor.org/info/rfc4191>.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
<https://www.rfc-editor.org/info/rfc4193>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/info/rfc4291>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", STD 89,
RFC 4443, DOI 10.17487/RFC4443, March 2006,
<https://www.rfc-editor.org/info/rfc4443>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007,
<https://www.rfc-editor.org/info/rfc4861>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862,
DOI 10.17487/RFC4862, September 2007,
<https://www.rfc-editor.org/info/rfc4862>.
[RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,
"IPv6 Router Advertisement Options for DNS Configuration",
RFC 6106, DOI 10.17487/RFC6106, November 2010,
<https://www.rfc-editor.org/info/rfc6106>.
[RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix
Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011,
<https://www.rfc-editor.org/info/rfc6296>.
[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,
<https://www.rfc-editor.org/info/rfc6724>.
[RFC7078] Matsumoto, A., Fujisaki, T., and T. Chown, "Distributing
Address Selection Policy Using DHCPv6", RFC 7078,
DOI 10.17487/RFC7078, January 2014,
<https://www.rfc-editor.org/info/rfc7078>.
[RFC7556] Anipko, D., Ed., "Multiple Provisioning Domain
Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015,
<https://www.rfc-editor.org/info/rfc7556>.
[RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by
Hosts in a Multi-Prefix Network", RFC 8028,
DOI 10.17487/RFC8028, November 2016,
<https://www.rfc-editor.org/info/rfc8028>.
[RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,
"IPv6 Router Advertisement Options for DNS Configuration",
RFC 8106, DOI 10.17487/RFC8106, March 2017,
<https://www.rfc-editor.org/info/rfc8106>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
Richardson, M., Jiang, S., Lemon, T., and T. Winters,
"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
RFC 8415, DOI 10.17487/RFC8415, November 2018,
<https://www.rfc-editor.org/info/rfc8415>.11.2. Informative References ✨
Okay bestie, these are the background reads 📚 The spec points to them for context. Some are Internet-Drafts that were still works in progress when this was written 🧚
[DST-SRC-RTG]
Lamparter, D. and A. Smirnov, "Destination/Source
Routing", Work in Progress, Internet-Draft, draft-ietf-
rtgwg-dst-src-routing-07, 10 March 2019,
<https://tools.ietf.org/html/draft-ietf-rtgwg-dst-src-
routing-07>.
[PROV-DOMAINS]
Pfister, P., Vyncke, E., Pauly, T., Schinazi, D., and W.
Shao, "Discovering Provisioning Domain Names and Data",
Work in Progress, Internet-Draft, draft-ietf-intarea-
provisioning-domains-09, 6 December 2019,
<https://tools.ietf.org/html/draft-ietf-intarea-
provisioning-domains-09>.
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations",
RFC 2663, DOI 10.17487/RFC2663, August 1999,
<https://www.rfc-editor.org/info/rfc2663>.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March
2004, <https://www.rfc-editor.org/info/rfc3704>.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007,
<https://www.rfc-editor.org/info/rfc4941>.
[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C.
Pignataro, "The Generalized TTL Security Mechanism
(GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007,
<https://www.rfc-editor.org/info/rfc5082>.
[RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming
Shim Protocol for IPv6", RFC 5533, DOI 10.17487/RFC5533,
June 2009, <https://www.rfc-editor.org/info/rfc5533>.
[RFC5534] Arkko, J. and I. van Beijnum, "Failure Detection and
Locator Pair Exploration Protocol for IPv6 Multihoming",
RFC 5534, DOI 10.17487/RFC5534, June 2009,
<https://www.rfc-editor.org/info/rfc5534>.
[RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure,
"TCP Extensions for Multipath Operation with Multiple
Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013,
<https://www.rfc-editor.org/info/rfc6824>.
[RFC7676] Pignataro, C., Bonica, R., and S. Krishnan, "IPv6 Support
for Generic Routing Encapsulation (GRE)", RFC 7676,
DOI 10.17487/RFC7676, October 2015,
<https://www.rfc-editor.org/info/rfc7676>.
[RFC8425] Troan, O., "IANA Considerations for IPv6 Neighbor
Discovery Prefix Information Option Flags", RFC 8425,
DOI 10.17487/RFC8425, July 2018,
<https://www.rfc-editor.org/info/rfc8425>.
[RFC8504] Chown, T., Loughney, J., and T. Winters, "IPv6 Node
Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504,
January 2019, <https://www.rfc-editor.org/info/rfc8504>.
[SADR-RA] Pfister, P., "Source Address Dependent Route Information
Option for Router Advertisements", Work in Progress,
Internet-Draft, draft-pfister-6man-sadr-ra-01, 22 June
2015, <https://tools.ietf.org/html/draft-pfister-6man-
sadr-ra-01>.Acknowledgements 🫶
The original outline was suggested by Ole Trøan. Huge shoutout to him 🌸
The authors also gave a big thank-you to these people, listed in alphabetical order, for reviewing and giving feedback: Olivier Bonaventure, Deborah Brungard, Brian E. Carpenter, Lorenzo Colitti, Roman Danyliw, Benjamin Kaduk, Suresh Krishnan, Mirja Kühlewind, David Lamparter, Nicolai Leymann, Acee Lindem, Philip Matthews, Robert Raszuk, Pete Resnick, Alvaro Retana, Dave Thaler, Michael Tüxen, Martin Vigoureux, Éric Vyncke, Magnus Westerlund 💖 Reviewers are the unsung heroes fr 👑
Authors' Addresses 🦋
Fred Baker
Santa Barbara, California 93117
United States of America
Email: FredBaker.IETF@gmail.com
Chris Bowers
Juniper Networks
Sunnyvale, California 94089
United States of America
Email: cbowers@juniper.net
Jen Linkova
Google
1 Darling Island Rd
Pyrmont NSW 2009
Australia
Email: furry@google.com📦 where this page comes from
- ietf: rfc8678 2019-12
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms