diff options
Diffstat (limited to 'doc/rfc/rfc8678.txt')
| -rw-r--r-- | doc/rfc/rfc8678.txt | 2423 |
1 files changed, 2423 insertions, 0 deletions
diff --git a/doc/rfc/rfc8678.txt b/doc/rfc/rfc8678.txt new file mode 100644 index 0000000..713e761 --- /dev/null +++ b/doc/rfc/rfc8678.txt @@ -0,0 +1,2423 @@ + + + + +Internet Engineering Task Force (IETF) F. Baker +Request for Comments: 8678 +Category: Informational C. Bowers +ISSN: 2070-1721 Juniper Networks + J. Linkova + Google + December 2019 + + + Enterprise Multihoming Using Provider-Assigned IPv6 Addresses without + Network Prefix Translation: Requirements and Solutions + +Abstract + + Connecting an enterprise site to multiple ISPs over IPv6 using + provider-assigned addresses is difficult without the use of some form + of Network Address Translation (NAT). Much has been written on this + topic over the last 10 to 15 years, but it still remains a problem + without a clearly defined or widely implemented solution. Any + multihoming solution without NAT requires hosts at the site to have + addresses from each ISP and to select the egress ISP by selecting a + source address for outgoing packets. It also requires routers at the + site to take into account those source addresses when forwarding + packets out towards the ISPs. + + This document examines currently available mechanisms for providing a + solution to this problem for a broad range of enterprise topologies. + It covers the behavior of routers to forward traffic by taking into + account source address, and it covers the behavior of hosts to select + appropriate default source addresses. It also covers any possible + role that routers might play in providing information to hosts to + help them select appropriate source addresses. In the process of + exploring potential solutions, this document also makes explicit + requirements for how the solution would be expected to behave from + the perspective of an enterprise site network administrator. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + 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 has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are candidates for any level of Internet + Standard; see Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide 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 review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction + 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' Addresses + +1. Introduction + + Site multihoming, the connection of a subscriber network to multiple + upstream networks using redundant uplinks, is a common enterprise + architecture for improving the reliability of its Internet + connectivity. If the site uses provider-independent (PI) addresses, + all traffic originating from the enterprise can use source addresses + from the PI address space. Site multihoming with PI addresses is + commonly used with both IPv4 and IPv6, and does not present any new + technical challenges. + + It may be desirable for an enterprise site to connect to multiple + ISPs using provider-assigned (PA) addresses instead of PI addresses. + Multihoming with provider-assigned addresses is typically less + expensive for the enterprise relative to using provider-independent + addresses as it does not require obtaining and maintaining PI address + space nor does it require running BGP between the enterprise and the + ISPs (for small/medium networks, running BGP might be not only + undesirable but also impossible, especially if residential-type ISP + connections are used). PA multihoming is also a practice that should + be facilitated and encouraged because it does not add to the size of + the Internet routing table, whereas PI multihoming does. Note that + PA is also used to mean "provider-aggregatable". In this document, + we assume that provider-assigned addresses are always provider- + aggregatable. + + With PA multihoming, for each ISP connection, the site is assigned a + prefix from within an address block allocated to that ISP by its + National or Regional Internet Registry. In the simple case of two + ISPs (ISP-A and ISP-B), the site will have two different prefixes + assigned to it (prefix-A and prefix-B). This arrangement is + problematic. First, packets with the "wrong" source address may be + dropped by one of the ISPs. In order to limit denial-of-service + attacks using spoofed source addresses, [BCP38] recommends that ISPs + filter traffic from customer sites to allow only traffic with a + source address that has been assigned by that ISP. So a packet sent + from a multihomed site on the uplink to ISP-B with a source address + in prefix-A may be dropped by ISP-B. + + However, even if ISP-B does not implement BCP 38, or ISP-B adds + prefix-A to its list of allowed source addresses on the uplink from + the multihomed site, two-way communication may still fail. If the + packet with a source address in prefix-A was sent to ISP-B because + the uplink to ISP-A failed, then if ISP-B does not drop the packet, + and the packet reaches its destination somewhere on the Internet, the + return packet will be sent back with a destination address in prefix- + A. The return packet will be routed over the Internet to ISP-A, but + it will not be delivered to the multihomed site because the site + uplink with ISP-A has failed. Two-way communication would require + some arrangement for ISP-B to advertise prefix-A when the uplink to + ISP-A fails. + + Note that the same may be true of a provider that does not implement + BCP 38, even if his upstream provider does, or of a provider that has + no corresponding route to deliver the ingress traffic to the + multihomed site. The issue is not that the immediate provider + implements ingress filtering; it is that someone upstream does (so + egress traffic is blocked) or lacks a route (causing blackholing of + the ingress traffic). + + Another issue with asymmetric traffic flow (when the egress traffic + leaves the site via one ISP, but the return traffic enters the site + via another uplink) is related to stateful firewalls/middleboxes. + Keeping state in that case might be problematic, even impossible. + + With IPv4, this problem is commonly solved by using private address + space described in [RFC1918] within the multihomed site and 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. + Therefore, requiring the use of NAT or NAPT for an enterprise site to + multihome with provider-assigned addresses is not an attractive + solution. + + [RFC6296] describes a translation solution specifically tailored to + meet the requirements of multihoming with provider-assigned IPv6 + addresses. With the IPv6-to-IPv6 Network Prefix Translation (NPTv6) + solution, 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 manner to an address + within the prefix assigned by the ISP on that uplink. [RFC6296] is + currently classified as Experimental, and it has been implemented by + several vendors. See Section 8.2 for more discussion of NPTv6. + + This document defines routing requirements for enterprise + multihoming. This document 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 + that is 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 + corresponding to that ISP. Potential mechanisms for communicating + network changes to the host are Neighbor Discovery Router + Advertisements [RFC4861], DHCPv6 [RFC8415], and ICMPv6 [RFC4443]. + + The routers in the enterprise network are responsible for ensuring + that packets are delivered to the "correct" ISP uplink based on + source address. This requires that at least some routers in the site + network are able to take into account the source address of a packet + when deciding how to route it. That is, 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 routers capable of SADR 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 in which this + solution is expected to operate. The discussion of Section 4 uses + the concepts of Source-Prefix-Scoped Routing advertisements and + forwarding tables and describes how Source-Prefix-Scoped Routing + 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 to be used by applications. It also discusses the + requirements for routing that are needed to support these enterprise + network scenarios and the mechanisms by which hosts are expected to + update default source addresses based on network state. Section 7 + discusses deployment considerations, while Section 8 discusses 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. + +3. Terminology + + 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. Can be aggregated and present 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 end + site / end customer. + + ISP: Internet Service Provider + + LIR (Local Internet Registry): an organization (usually an ISP or an + enterprise/academic) that receives 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 the + Internet number resources (such as IP addresses and autonomous + system (AS) numbers) within a geographical region of the world. + + SADR (Source Address Dependent Routing): routing that takes into + account the source address of a packet in addition to the packet + 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/forward packets with any source address. + + SER (Site Edge Router): a router that connects the site to an ISP + (terminates an ISP uplink). + + LLA (Link-Local Address): an IPv6 unicast address from the fe80::/10 + prefix [RFC4291]. + + ULA (Unique Local IPv6 Unicast Address): an IPv6 unicast address + from the FC00::/7 prefix. 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 required for hosts to perform SLAAC [RFC4861]. + + PIO (Prefix Information Option): a part of an RA message containing + information about IPv6 prefixes that could be used by hosts 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 + + We start by looking at a scenario in which a site has connections to + two ISPs, as shown in Figure 1. The site is assigned the prefix + 2001:db8:0:a000::/52 by ISP-A and prefix 2001:db8:0:b000::/52 by ISP- + B. We consider three hosts in the site. H31 and H32 are on a LAN + that has been assigned subnets 2001:db8:0:a010::/64 and + 2001:db8:0:b010::/64. H31 has been assigned the addresses + 2001:db8:0:a010::31 and 2001:db8:0:b010::31. H32 has been assigned + 2001:db8:0:a010::32 and 2001:db8:0:b010::32. H41 is on a different + subnet that has been assigned 2001:db8:0:a020::/64 and + 2001:db8:0:b020::/64. + + 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 SERs + + We refer to a router that connects the site to an ISP as a site edge + router (SER). Several other routers provide connectivity among the + internal hosts (H31, H32, and H41), as well as connect the internal + hosts to the Internet through SERa and SERb. In this example, SERa + and SERb share a direct connection to each other. In Section 4.2, we + consider a scenario in which this is not the case. + + For the moment, we assume that the hosts are able to select suitable + source addresses through some mechanism that doesn't involve the + routers in the site network. Here, we focus on the primary task of + the routed site network, which is to get packets efficiently to their + destinations, while sending a packet to the ISP that assigned the + prefix that matches the source address of the packet. In Section 6, + we examine what role the routed network may play in helping hosts + select suitable source addresses for packets. + + With this solution, routers will need some form of Source Address + Dependent Routing, which will be new functionality. It would be + useful if an enterprise site does not need to upgrade all routers to + support the new SADR functionality in order to support PA + multihoming. We consider whether this is possible and examine the + trade-offs of not having all routers in the site support SADR + functionality. + + In the topology in Figure 1, it is possible to support PA multihoming + with only SERa and SERb being capable of SADR. The other routers can + continue to forward based only on destination address, and exchange + routes that only consider destination address. In this scenario, + SERa and SERb communicate source-scoped routing information across + their shared connection. When SERa receives a packet with a source + address matching prefix 2001:db8:0:b000::/52, it forwards the packet + to SERb, which forwards it on the uplink to ISP-B. The analogous + behavior holds for traffic that SERb receives with a source address + matching prefix 2001:db8:0:a000::/52. + + In Figure 1, when only SERa and SERb are capable of source address + dependent routing, PA multihoming will work. However, the paths over + which the packets are sent will generally not be the shortest paths. + The forwarding paths will generally be more efficient when more + routers are capable of SADR. For example, if R4, R2, and R6 are + upgraded to support SADR, then they can exchange source-scoped routes + with SERa and SERb. They will then know to send traffic with a + source address matching prefix 2001:db8:0:b000::/52 directly to SERb, + without sending it to SERa first. + +4.2. Simple ISP Connectivity Where SERs Are Not Directly Connected + + In Figure 2, we modify the topology slightly by inserting R7, so that + SERa and SERb are no longer directly connected. With this topology, + it is not enough to just enable SADR routing on SERa and SERb to + support PA multihoming. There are two solutions to enable PA + multihoming in this topology. + + 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 + Connected + + One option is to effectively modify the topology by creating a + logical tunnel between SERa and SERb by using Generic Routing + Encapsulation (GRE) [RFC7676], for example. Although SERa and SERb + are not directly connected physically in this topology, they can be + directly connected logically by a tunnel. + + The other option is to enable SADR functionality on R7. In this way, + R7 will exchange source-scoped routes with SERa and SERb, making the + three routers act as a single SADR domain. This illustrates the + basic principle that 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 the connected + SADR domain beyond that point can produce more efficient forwarding + paths. + +4.3. Enterprise Network Operator Expectations + + Before considering a more complex scenario, let's look in more detail + at the reasonably simple multihoming scenario in Figure 2 to + understand what can reasonably be expected from this solution. As a + general guiding principle, we assume an enterprise network operator + will expect a multihomed network to behave as close to a single-homed + network as possible. So a solution that meets those expectations + where possible is a good thing. + + For traffic between internal hosts and for traffic from outside the + site to internal hosts, an enterprise network operator would expect + there to be no visible change in the path taken by this traffic, + since this traffic does not need to be routed in a way that depends + on source address. It is also reasonable to expect that internal + hosts should be able to communicate with each other using either of + their source addresses without restriction. For example, H31 should + be able to communicate with H41 using a packet with + S=2001:db8:0:a010::31, D=2001:db8:0:b020::41, regardless of the state + of uplink to ISP-B. + + These goals can be accomplished by having all of the routers in the + network continue to originate normal unscoped destination routes for + their connected networks. If we can arrange it so that these + unscoped destination routes are used for forwarding this traffic, + then we will have accomplished multihoming's goal of not affecting + the forwarding of traffic destined for internal hosts. + + For traffic destined for external hosts, it is reasonable to expect + that traffic with a source address from the prefix assigned by ISP-A + to follow the path that the traffic would follow if there were no + connection to ISP-B. This can be accomplished by having SERa + originate a source-scoped route of the form (S=2001:db8:0:a000::/52, + D=::/0). If all of the routers in the site support SADR, then the + path of traffic exiting via ISP-A can match that expectation. If + some routers don't support SADR, then it is reasonable to expect that + the path for traffic exiting via ISP-A may be different within the + site. This is a trade-off that the enterprise network operator may + decide to make. + + It is important to understand the behavior of this multihoming + solution when an uplink to one of the ISPs fails. To simplify this + discussion, we assume that all routers in the site support SADR. We + start by looking at the operation of the network when the uplinks to + both ISP-A and ISP-B are functioning 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 are distributed + through the routers in the site, and they establish within the + routers two sets of forwarding paths for traffic leaving the site. + One set of forwarding paths is for packets with source addresses in + 2001:db8:0:a000::/52. The other set of forwarding paths is for + packets with source addresses in 2001:db8:0:b000::/52. The normal + destination routes, which are not scoped to these two source + prefixes, play no role in the forwarding. Whether a packet exits the + site via SERa or via SERb is completely determined by the source + address applied to the packet by the host. So for example, when host + H31 sends a packet to host H101 with (S=2001:db8:0:a010::31, + D=2001:db8:0:1234::101), the packet will only be sent out the link + from SERa to ISP-A. + + Now consider what happens when the uplink from SERa to ISP-A fails. + The only way for the packets from H31 to reach H101 is for H31 to + start using the source address for ISP-B. H31 needs to send the + following packet: (S=2001:db8:0:b010::31, D=2001:db8:0:1234::101). + + This behavior is very different from the behavior that occurs with + site multihoming using PI addresses or with PA addresses using NAT. + In these other multihoming solutions, hosts do not need to react to + network failures several hops away in order to regain Internet + access. Instead, a host can be largely unaware of the failure of an + uplink to an ISP. When multihoming with PA addresses and NAT, + existing sessions generally need to be reestablished after a failure + since the external host will receive packets from the internal host + with a new source address. However, new sessions can be established + without any action on the part of the hosts. Multihoming with PA + addresses and NAT has created the expectation of a fairly quick and + simple recovery from network failures. Alternatives should to be + evaluated in terms of the speed and complexity of the recovery + mechanism. + + Another significant difference between this multihoming solution and + multihoming with either PI addresses or with PA addresses using NAT + is the ability of the enterprise network operator to route traffic + over different ISPs based on destination address. We still consider + the fairly simple network of Figure 2 and assume that uplinks to both + ISPs are functioning. Assume that the site is multihomed using PA + addresses and NAT, and that SERa and SERb each originate a normal + destination route for D=::/0, with the route origination dependent on + the state of the uplink to the respective ISP. + + Now suppose it is observed that an important application running + between internal hosts and external host H101 experiences much better + performance when the traffic passes through ISP-A (perhaps because + ISP-A provides lower latency to H101). When multihoming this site + with PI addresses or with PA addresses and NAT, the enterprise + network operator can configure SERa to originate into the site + network a normal destination route for D=2001:db8:0:1234::/64 (the + destination prefix to reach H101) that depends on the state of the + uplink to ISP-A. When the link to ISP-A is functioning, the + destination route D=2001:db8:0:1234::/64 will be originated by SERa, + so traffic from all hosts will use ISP-A to reach H101 based on the + longest destination prefix match in the route lookup. + + Implementing the same routing policy is more difficult with the PA + multihoming solution described in this document since it doesn't use + NAT. By design, the only way to control where a packet exits this + network is by setting the source address of the packet. Since the + network cannot modify the source address without NAT, the host must + set it. To implement this routing policy, each host needs to use the + source address from the prefix assigned by ISP-A to send traffic + destined for H101. Mechanisms have been proposed to allow hosts to + choose the source address for packets in a fine-grained manner. We + will discuss these proposals in Section 6. However, an enterprise + network administrator would not expect to interact with host + operating systems to ensure that a particular source address is + chosen for a particular destination prefix in order to implement this + routing policy. + +4.4. More Complex ISP Connectivity + + The previous sections considered two variations of a simple + multihoming scenario in which the site is connected to two ISPs + offering only Internet connectivity. It is likely that many actual + enterprise multihoming scenarios will be similar to this simple + example. However, there are more complex multihoming scenarios that + we would like this solution to address as well. + + It is fairly common for an ISP to offer a service in addition to + Internet access over the same uplink. Two variations of this are + reflected in Figure 3. In addition to Internet access, ISP-A offers + a service that requires the site to access host H51 at + 2001:db8:0:5555::51. The site has a single physical and logical + connection with ISP-A, and ISP-A only allows access to H51 over that + connection. So when H32 needs to access the service at H51, it needs + to send packets with (S=2001:db8:0:a010::32, D=2001:db8:0:5555::51), + and those packets need to be forwarded 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-B + + ISP-B illustrates a variation on this scenario. In addition to + Internet access, ISP-B also offers a service that requires the site + to access host H61. The site has two connections to two different + parts of ISP-B (shown as SERb1 and SERb2 in Figure 3). ISP-B expects + Internet traffic to use the uplink from SERb1, while it expects + traffic destined for the service at H61 to use the uplink from SERb2. + For either uplink, ISP-B expects the ingress traffic to have a source + address matching the prefix that it assigned to the site, + 2001:db8:0:b000::/52. + + As discussed before, we rely completely on the internal host to set + the source address of the packet properly. In the case of a packet + sent by H31 to access the service in ISP-B at H61, we expect the + packet to have the following addresses: (S=2001:db8:0:b010::31, + D=2001:db8:0:6666::61). The routed network has two potential ways of + distributing routes so that this packet exits the site on the uplink + at SERb2. + + We could just rely on normal destination routes, without using + source-prefix-scoped routes. If we have SERb2 originate a normal + unscoped destination route for D=2001:db8:0:6666::/64, the packets + from H31 to H61 will exit the site at SERb2 as desired. We should + not have to worry about SERa needing to originate the same route, + because ISP-B should choose a globally unique prefix for the service + at H61. + + The alternative is to have SERb2 originate a source-prefix-scoped + destination route of the form (S=2001:db8:0:b000::/52, + D=2001:db8:0:6666::/64). From a forwarding point of view, the use of + the source-prefix-scoped destination route would result in traffic + with source addresses corresponding only to ISP-B being sent to + SERb2. Instead, the use of the unscoped destination route would + result in traffic with source addresses corresponding to ISP-A and + ISP-B being sent to SERb2, as long as the destination address matches + the destination prefix. It seems like either forwarding behavior + would be acceptable. + + However, from the point of view of the enterprise network + administrator trying to configure, maintain, and troubleshoot this + multihoming solution, it seems much clearer to have SERb2 originate + the source-prefix-scoped destination route corresponding to the + service offered by ISP-B. In this way, all of the traffic leaving + the site is determined by the source-prefix-scoped routes, and all of + the traffic within the site or arriving from external hosts is + determined by the unscoped destination routes. Therefore, for this + multihoming solution we choose to originate source-prefix-scoped + routes for all traffic leaving the site. + +4.5. ISPs and Provider-Assigned Prefixes + + While we expect that most site multihoming involves connecting to + only two ISPs, this solution allows for connections to an arbitrary + number of ISPs. However, when evaluating scalable implementations of + the solution, it would be reasonable to assume that the maximum + number of ISPs that a site would connect to is five (topologies with + two redundant routers, each having two uplinks to different ISPs, + plus a tunnel to a head office acting as fifth one are not unheard + of). + + It is also useful to note that the prefixes assigned to the site by + different ISPs will not overlap. This must be the case, since the + provider-assigned addresses have to be globally unique. + +4.6. Simplified Topologies + + The topologies of many enterprise sites using this multihoming + solution may in practice be simpler than the examples that we have + used. The topology in Figure 1 could be further simplified by + directly connecting all hosts to the LAN that connects the two site + exit routers, SERa and SERb. The topology could also be simplified + by connecting both uplinks to ISP-A and ISP-B to the same site exit + router. However, it is the aim of this document to provide a + solution that applies to a broad range of enterprise site network + topologies, so this document focuses on providing a solution to 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 simplified cases. This solution, however, needs to support more + complex topologies. + + We are starting with the basic assumption that enterprise site + networks can be quite complex from a routing perspective. However, + even a complex site network can be multihomed to different ISPs with + PA addresses using IPv4 and NAT. It is not reasonable to expect an + enterprise network operator to change the routing topology of the + site in order to deploy IPv6. + +5. Generating Source-Prefix-Scoped Forwarding Tables + + So far, we have described in general terms how the SADR-capable + routers in this solution forward traffic by 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. + + 1. 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. + + 2. Compute the next-hops for the unscoped destination prefixes using + all routers in the IGP. This is the unscoped forwarding table. + + 3. 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 produced by this process are used in the + following way to forward packets. + + 1. 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). + + 2. Look up the destination address of the packet in the selected + forwarding table to determine the next-hop for the packet. + + The following example illustrates how this process is used to create + a forwarding table for each provider-assigned source prefix. We + consider the multihomed site network in Figure 3. Initially we + assume that all of the routers in the site network support SADR. + Figure 4 shows the routes that are originated by the routers in the + site network. + + 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 Network + + Each SER originates destination routes that are scoped to the source + prefix assigned by the ISP to which the SER connects. Note that the + SERs also originate the corresponding unscoped destination route. + This is not needed when all of the routers in the site support SADR. + However, it is required when some routers do not support SADR. This + will be discussed in more detail later. + + We focus on how R8 constructs its source-prefix-scoped forwarding + tables from these route advertisements. R8 computes the next hops + for destination routes that are scoped to the source prefix + 2001:db8:0:a000::/52. The results are shown in the first table in + Figure 5. (In this example, the next hops are computed assuming that + all links have the same metric.) Then, R8 computes the next hops for + destination routes that are scoped to the source prefix + 2001:db8:0:b000::/52. The results are shown in the second table in + Figure 5. Finally, R8 computes the next hops for the unscoped + destination prefixes. The results are shown in 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 R8 + + The final step is for R8 to augment the more specific source-prefix- + scoped forwarding tables with entries from less specific source- + prefix-scoped forwarding tables. The unscoped forwarding table is + considered as being scoped to ::/0, so both 2001:db8:0:a000::/52 and + 2001:db8:0:b000::/52 are more specific prefixes of ::/0. Therefore, + entries in the unscoped forwarding table will be evaluated to be + added to these two more specific source-prefix-scoped forwarding + tables. If a forwarding entry from the less specific source-prefix- + scoped forwarding table has the exact same destination prefix + (including destination prefix length) as the forwarding entry from + the more specific source-prefix-scoped forwarding table, then the + existing forwarding entry in the more specific source-prefix-scoped + forwarding table wins. + + As an example of how the source-prefix-scoped forwarding entries are + augmented, we consider how the two entries in the first table in + Figure 5 (the table for source prefix = 2001:db8:0:a000::/52) are + augmented with entries from the third table in Figure 5 (the table of + unscoped or scoped to ::/0 forwarding entries). The first four + unscoped forwarding 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) are not an exact match for any of the + existing entries in the forwarding table for source prefix + 2001:db8:0:a000::/52. Therefore, these four entries are added to the + final forwarding table for source prefix 2001:db8:0:a000::/52. The + result of adding these entries is reflected in the first four entries + the first table in Figure 6. + + The next less specific source-prefix-scoped (scope is ::/0) + forwarding table entry is for D=2001:db8:0:5555::/64. This entry is + an exact match for the existing entry in the forwarding table for the + more specific source prefix 2001:db8:0:a000::/52. Therefore, we do + not replace the existing entry with the entry from the unscoped + forwarding table. This is reflected in the fifth entry in the first + table in Figure 6. (Note that since both scoped and unscoped entries + have R7 as the next hop, the result of applying this rule is not + visible.) + + The next less specific source-prefix-scoped (scope is ::/0) + forwarding table entry is for D=2001:db8:0:6666::/64. This entry is + not an exact match for any existing entries in the forwarding table + for source prefix 2001:db8:0:a000::/52. Therefore, we add this + entry. This is reflected in the sixth entry in the first table in + Figure 6. + + The next less specific source-prefix-scoped (scope is ::/0) + forwarding table entry is for D=::/0. This entry is an exact match + for the existing entry in the forwarding table for the more specific + source prefix 2001:db8:0:a000::/52. Therefore, we do not overwrite + the existing source-prefix-scoped entry, as can be seen in 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 R8 + + The forwarding tables produced by this process at R8 have the desired + properties. A packet with a source address in 2001:db8:0:a000::/52 + will be forwarded based on the first table in Figure 6. If the + packet is destined for the Internet at large or the service at + D=2001:db8:0:5555/64, it will be sent to R7 in the direction of SERa. + If the packet is destined for an internal host, then the first four + entries will send it to R2 or R5 as expected. Note that if this + packet has a destination address corresponding to the service offered + by ISP-B (D=2001:db8:0:5555::/64), then it will get forwarded to + SERb2. It will be dropped by SERb2 or by ISP-B, since the packet has + a source address that was not assigned by ISP-B. However, this is + expected behavior. In order to use the service offered by ISP-B, the + host needs to originate the packet with a source address assigned by + ISP-B. + + In this example, a packet with a source address that doesn't match + 2001:db8:0:a000::/52 or 2001:db8:0:b000::/52 must have originated + from an external host. Such a packet will use the unscoped + forwarding table (the last table in Figure 6). These packets will + flow exactly as they would in absence of multihoming. + + We can also modify this example to illustrate how it supports + deployments in which not all routers in the site support SADR. + Continuing with the topology shown in Figure 3, suppose that R3 and + R5 do not support SADR. Instead they are only capable of + understanding unscoped route advertisements. The SADR routers in the + network will still originate the routes shown in Figure 4. However, + R3 and R5 will only understand the unscoped routes as 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 SADR + + With these unscoped route advertisements, R5 will produce the + forwarding table shown 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 Routes + + As all SERs belong to the SADR domain, any traffic that needs to exit + the site will eventually hit a SADR-capable router. To prevent + routing loops involving SADR-capable and non-SADR-capable routers, + traffic that enters the SADR-capable domain does not leave the domain + until it exits the site. Therefore all SADR-capable routers within + the domain MUST be logically connected. + + Note that the mechanism described here for converting source-prefix- + scoped destination prefix routing advertisements into forwarding + state is somewhat different from that proposed in [DST-SRC-RTG]. The + method described in this document is functionally equivalent, but it + is based on application of existing mechanisms for the described + scenarios. + +6. Mechanisms for Hosts To Choose Good Default Source Addresses in a + Multihomed Site + + Until this point, we have made the assumption that hosts are able to + choose the correct source address using some unspecified mechanism. + This has allowed us to focus on what the routers in a multihomed site + network need to do in order to forward packets to the correct ISP + based on source address. Now we look at possible mechanisms for + hosts to choose the correct source address. We also look at what + role, if any, the routers may play in providing information that + helps hosts to choose source addresses. + + It should be noted that this section discusses 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 that + cannot be changed. Section 6.7 discusses the connections + preservation issue in more detail. + + Any host that needs to be able to send traffic using the uplinks to a + given ISP is expected to be configured with an address from the + prefix assigned by that ISP. The host will control which ISP is used + for its traffic by selecting one of the addresses configured on the + host as the source address for outgoing traffic. It is the + responsibility of the site network to ensure that a packet with the + source address from an ISP is now sent on an uplink to that ISP. + + If all of the ISP uplinks are working, then the host's choice of + source address may be driven by the desire to load share across ISP + uplinks, or it may be driven by the desire 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). If any of the ISP + uplinks is not working, then the choice of source address by the host + can cause packets to get dropped. + + How a host selects a suitable source address in a multihomed site is + not a solved problem. We do not attempt to solve this problem in + this document. Instead we discuss the current state of affairs with + respect to standardized solutions and the implementation of those + solutions. We also look at proposed solutions for this problem. + + An external host initiating communication with a host internal to a + PA-multihomed site will need to know multiple addresses for that host + in order to communicate with it using different ISPs to the + multihomed site (knowing just one address would undermine all + benefits of redundant connectivity provided by multihoming). These + addresses are typically learned through DNS. (For simplicity, we + assume that the external host is single-homed.) The external host + chooses the ISP that will be used at the remote multihomed site by + setting the destination address on the packets it transmits. For a + session originated from an external host to an internal host, the + choice of source address used by the internal host is simple. The + internal host 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, the + decision of which source address to select 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 we 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 + + [RFC6724] defines the algorithms that hosts are expected to use to + select source and destination addresses for packets. It defines an + algorithm for selecting a source address and a separate algorithm for + selecting a destination address. Both of these algorithms depend on + a policy table. [RFC6724] defines a default policy that produces + certain behavior. + + The rules in the two algorithms in [RFC6724] depend on many different + properties of addresses. While these are needed for understanding + how a host should choose addresses in an arbitrary environment, most + of the rules are not relevant for understanding how a host should + choose among multiple source addresses in a multihomed environment + when sending a packet to a remote host. Returning to the example in + Figure 3, we look at what the default algorithms in [RFC6724] say + about the source address that internal host H31 should use to send + traffic to external host H101, somewhere on the Internet. + + There is no choice to be made with respect to destination address. + H31 needs to send a packet with D=2001:db8:0:1234::101 in order to + reach H101. So H31 has to choose between using S=2001:db8:0:a010::31 + or S=2001:db8:0:b010::31 as the source address for this packet. We + go through the rules for source address selection in Section 5 of + [RFC6724]. + + Rule 1 (Prefer same address) is not useful to break the tie between + source addresses because neither one of the candidate source + addresses equals the destination address. + + Rule 2 (Prefer appropriate scope) is also not useful in this scenario + because both source addresses and the destination address have global + scope. + + Rule 3 (Avoid deprecated addresses) applies to an address that has + been autoconfigured by a host using stateless address + autoconfiguration as defined in [RFC4862]. An address autoconfigured + by a host has a preferred lifetime and a valid lifetime. The address + is preferred until the preferred lifetime expires, after which it + becomes deprecated. A deprecated address is not used if there is a + preferred address of the appropriate scope available. When the valid + lifetime expires, the address cannot be used at all. The preferred + and valid lifetimes for an autoconfigured address are set based on + the corresponding lifetimes in the Prefix Information Option in + Neighbor Discovery Router Advertisements. In this scenario, a + possible tool to control source address selection in this scenario + would be for a host to deprecate an address by having routers on that + link, R1 and R2 in Figure 3, send Router Advertisement messages + containing PIOs with the Preferred Lifetime value for the deprecated + source prefix set to zero. This is a rather blunt tool, because it + discourages or prohibits the use of that source prefix for all + destinations. However, it may be useful in some scenarios. For + example, if all uplinks to a particular ISP fail, it is desirable to + prevent hosts from using source addresses from that ISP address + space. + + Rule 4 (Avoid home addresses) does not apply here because we are not + considering Mobile IP. + + Rule 5 (Prefer outgoing interface) is not 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) is + not useful in the scenario when both R1 and R2 will advertise both + source prefixes. However, this rule may potentially allow a host to + select the correct source prefix by selecting a next-hop. The most + obvious way would be to make R1 advertise itself as a default router + and send PIO for 2001:db8:0:a010::/64, while R2 advertises itself as + a default router and sends PIO for 2001:db8:0:b010::/64. We'll + discuss later how Rule 5.5 can be used to influence a source address + selection in single-router topologies (e.g., when H41 is sending + traffic using R3 as a default gateway). + + Rule 6 (Prefer matching label) refers to the label value determined + for each source and destination prefix as a result of applying the + policy table 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 does not break the tie. However, + the algorithms in [RFC6724] are defined in such a way 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 the application of Rule + 6 to this scenario using the default policy table is not useful, Rule + 6 may still be a useful tool. + + Rule 7 (Prefer temporary addresses) has to do with the technique + described in [RFC4941] to periodically randomize the interface + portion of an IPv6 address that has been generated using stateless + address autoconfiguration. In general, if H31 were using this + technique, it would use it for both source addresses, for example, + creating 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 would not break the tie + between the two source prefixes from ISP-A and ISP-B. + + Rule 8 (Use longest matching prefix) dictates that, between two + candidate source addresses, the host selects the one that has longest + common prefix length with the destination address. For example, if + H31 were selecting the source address for sending packets to H101, + this rule would not break the tie between candidate source addresses + 2001:db8:0:a101::31 and 2001:db8:0:b101::31 since the common prefix + length with the destination is 48. However, if H31 were selecting + the source address for sending packets to H41 address + 2001:db8:0:a020::41, then this rule would result in using + 2001:db8:0:a101::31 as a source (2001:db8:0:a101::31 and + 2001:db8:0:a020::41 share the common prefix 2001:db8:0:a000::/58, + while for 2001:db8:0:b101::31 and 2001:db8:0:a020::41, the common + prefix is 2001:db8:0:a000::/51). Therefore Rule 8 might be useful + for selecting the correct source address in some, but not all, + scenarios (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 we can see that of the eight source address selection rules from + [RFC6724], four actually apply to our basic site multihoming + scenario. The rules that are relevant to this scenario 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 that we discuss for controlling the source address + selection through the four relevant rules above are SLAAC Router + Advertisement messages and DHCPv6. + + We also consider a possible role for ICMPv6 for getting traffic- + driven feedback from the network. With the source address selection + algorithm discussed above, the goal is to choose the correct source + address on the first try, before any traffic is sent. However, + another strategy is to choose a source address, send the packet, get + feedback from the network about whether or not the source address is + correct, and try another source address if it is not. + + We consider four scenarios in which a host needs to select the + correct source address. In the first scenario, both uplinks are + working. In the second scenario, one uplink has failed. The third + scenario is a situation in which one failed uplink has recovered. + The last scenario is failure of both (all) uplinks. + + It should be noted that [RFC6724] only defines the behavior of IPv6 + hosts to select default addresses that applications and upper-layer + protocols can use. Applications and upper-layer protocols can make + their own choices on selecting source addresses. The mechanism + proposed in this document attempts to ensure that the subset of + source addresses available for applications and upper-layer protocols + is selected with the up-to-date network state in mind. The rest of + the document discusses various aspects of the default source address + selection defined in [RFC6724], calling it for the sake of brevity + "the source address selection". + +6.2. Selecting Default Source Address When Both Uplinks Are Working + + Again we return to the topology in Figure 3. Suppose that the site + administrator wants to implement a policy by which all hosts need 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 assigns the same label to + destination addresses that match 2001:db8:0:1234::/64 as it does to + source addresses that match 2001:db8:0:a000::/52. The following two + entries accomplish this. + + 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 Policy + + This requires that the 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 that the hosts use DHCPv6 for address assignment. + The hosts could still use stateless address autoconfiguration for + address configuration, while using DHCPv6 only for policy table + distribution (see [RFC8415]). However this method has a number of + 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 it might + be feasible in the scenario of a single multihomed network, such + approach might have some scalability issues, especially if the + centralized DHCPv6 solution is deployed to serve a large number of + multihomed sites. + +6.2.2. Controlling Default Source Address Selection with Router + Advertisements + + Neighbor Discovery currently has two mechanisms to communicate prefix + information to hosts. The base specification for Neighbor Discovery + (see [RFC4861]) defines the Prefix Information Option (PIO) in the + Router Advertisement (RA) message. When a host receives a PIO with + the A-flag [RFC8425] set, it can use the prefix in the PIO as the + source prefix from which it assigns itself an IP address using + stateless address autoconfiguration (SLAAC) procedures described in + [RFC4862]. In the example of Figure 3, if the site network is using + SLAAC, we would expect both R1 and R2 to send RA messages with PIOs + with the A-flag set for both source prefixes 2001:db8:0:a010::/64 and + 2001:db8:0:b010::/64. H31 would then use the SLAAC procedure to + configure itself with 2001:db8:0:a010::31 and 2001:db8:0:b010::31. + + Whereas a host learns about source prefixes from PIO messages, hosts + 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 intended to allow a + host to choose the router that it uses as its first hop to reach a + particular destination prefix. + + As currently standardized, neither PIO nor RIO options contained in + Neighbor Discovery Router Advertisements can communicate the + information needed to implement the desired routing policy. PIOs + communicate source prefixes, and RIOs communicate destination + prefixes. However, there is currently no standardized way to + directly associate a particular destination prefix with a particular + source prefix. + + [SADR-RA] proposes a Source Address Dependent Route Information + option for Neighbor Discovery Router Advertisements that would + associate a source prefix with a destination prefix. The details of + [SADR-RA] might need tweaking to address this use case. However, in + order to be able to use Neighbor Discovery Router Advertisements to + implement this routing policy, an extension is needed that would + allow R1 and R2 to explicitly communicate to H31 an association + between S=2001:db8:0:a000::/52 and D=2001:db8:0:1234::/64. + + However, Rule 5.5 of the default source address selection algorithm + (discussed in Section 6.1), together with default router preference + (specified in [RFC4191]) and RIO, can be used to influence a source + address selection on a host as described below. Let's look at source + address selection on the 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 link-local address) so + Rule 5.5 does not apply. Now let's assume that 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 for each scoped forwarding table, LLA_A and LLA_B), + R3 will send two different RAs: one from LLA_A that includes a PIO + for 2001:db8:0:a020::/64, and another from LLA_B that includes a PIO + for 2001:db8:0:b020::/64. Now it is possible to influence H41 source + address selection for destinations that follow the default route by + setting the default router preference in RAs. If it is desired that + H41 reaches H101 (or any destination in the Internet) via ISP-A, then + RAs sent from LLA_A should have the default router preference set to + 01 (high priority), while RAs sent from LLA_B should have the + preference set to 11 (low). LLA_A would then be chosen as a next-hop + for H101, and therefore (per Rule 5.5) 2001:db8:0:a020::41 would be + selected as the source address. If, at the same time, it is desired + that H61 is accessible via ISP-B, then R3 should include a RIO for + 2001:db8:0:6666::/64 in its RA sent from LLA_B. H41 would choose + LLA_B as a next-hop for all traffic to H61, and then per Rule 5.5, + 2001:db8:0:b020::41 would be selected as a source address. + + If in the above-mentioned scenario it is desirable that all Internet + traffic leaves the network via ISP-A, and the link to ISP-B is used + for accessing ISP-B services only (not as an ISP-A link backup), then + RAs sent by R3 from LLA_B should have their Router Lifetime values + set to zero and should include RIOs for ISP-B address space. It + would instruct H41 to use LLA_A for all Internet traffic but to use + LLA_B as a next-hop while sending traffic to ISP-B addresses. + + The description of the mechanism above assumes SADR support by the + first-hop routers as well as SERs. However, a first-hop router can + still provide a less flexible version of this mechanism even without + implementing SADR. This could be done by providing configuration + knobs on the first-hop router that allow it to generate different + link-local addresses and to 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 should + implement Rule 5.5. of [RFC6724]. Hosts following the + recommendations specified in [RFC8028] therefore should be able to + benefit from the solution described in this document. No standards + need to be updated in regards to host behavior. + +6.2.3. Controlling Default Source Address Selection with ICMPv6 + + We now discuss how one might use ICMPv6 to implement the routing + policy to send traffic destined for H101 out the uplink to ISP-A, + even when uplinks to both ISPs are working. If H31 started sending + traffic to H101 with S=2001:db8:0:b010::31 and + D=2001:db8:0:1234::101, it would be routed through SER-b1 and out the + uplink to ISP-B. SERb1 could recognize that this traffic is not + following the desired routing policy and react by sending an ICMPv6 + message back to H31. + + In this example, we could arrange things so that SERb1 drops the + packet with S=2001:db8:0:b010::31 and D=2001:db8:0:1234::101, and + then sends to H31 an ICMPv6 Destination Unreachable message with Code + 5 (Source address failed ingress/egress policy). When H31 receives + this packet, it would then be expected to try another source address + to reach the destination. In this example, H31 would then send a + packet with S=2001:db8:0:a010::31 and D=2001:db8:0:1234::101, which + will reach SERa and be forwarded out the uplink to ISP-A. + + However, we would also want it to be the case that SERb1 does not + enforce this routing policy when the uplink from SERa to ISP-A has + failed. This could be accomplished by having SERa originate a + source-prefix-scoped route for (S=2001:db8:0:a000::/52, + D=2001:db8:0:1234::/64), and have SERb1 monitor the presence of that + route. If that route is not present (because SERa has stopped + originating it), then SERb1 will not 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 originated by SERa to + communicate the desired routing policy 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 would allow + SERa to communicate to 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. The + definition of an EXCLUSIVE flag for SADR advertisements in IGPs would + require future standardization work. + + Finally, if we are willing to extend ICMPv6 to support this solution, + then we could create a mechanism for SERb1 to tell the host which + source address it should be using to successfully forward packets + that meet the policy. In its current form, when SERb1 sends an + ICMPv6 Destination Unreachable Code 5 message, it is basically + saying, "This source address is wrong. Try another source address." + In the absence of a clear indication which address to try next, the + host will iterate over all addresses assigned to the interface (e.g., + various privacy addresses), which would lead to significant delays + and degraded user experience. It would be better if the ICMPv6 + message could say, "This source address is wrong. Instead use a + source address in S=2001:db8:0:a000::/52". + + However, using ICMPv6 for signaling source address information back + to hosts introduces new challenges. Most routers currently have + software or hardware limits on generating ICMP messages. A site + administrator deploying a solution that relies on the SERs generating + ICMP messages could try to improve the performance of SERs for + generating ICMP messages. However, in a large network, it is still + likely that ICMP message generation limits will be reached. As a + result, hosts would not receive ICMPv6 back, which in turn leads to + traffic blackholing and poor user experience. To improve the + scalability of ICMPv6-based signaling, hosts SHOULD cache the + preferred source address (or prefix) for the given destination (which + in turn might cause issues in the case of the corresponding ISP + uplink failure - 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 the destination + mapping SHOULD have a specific lifetime. Expiration of the lifetime + SHOULD trigger the source address selection algorithm again. + + Using ICMPv6 Destination Unreachable Messages with Code 5 to + influence source address selection introduces some security + challenges, which are discussed in Section 10. + + As currently standardized in [RFC4443], the ICMPv6 Destination + Unreachable Message with Code 5 would allow for the iterative + approach to retransmitting packets using different source addresses. + As currently defined, the ICMPv6 message does not provide a mechanism + to communicate information about which source prefix should be used + for a retransmitted packet. The current document does not define + such a mechanism, but it might be a useful extension to define in a + different document. However, this approach has some security + implications, such as an ability for an attacker to send spoofed + ICMPv6 messages to signal an invalid/unreachable source prefix, + causing a DoS-type attack. + +6.2.4. Summary of Methods for Controlling Default Source Address + Selection to Implement Routing Policy + + So to summarize this section, we have looked at three methods for + implementing 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 cannot distinguish + between the source addresses needed to enforce this policy, so a non- + default policy table using associating source and destination + prefixes using label values would need to be installed on each host. + A mechanism exists for DHCPv6 to distribute a non-default policy + table, but such solution would heavily rely on DHCPv6 support by the + host operating system. Moreover, there is no mechanism to translate + desired routing/traffic engineering policies into policy tables on + DHCPv6 servers. Therefore using DHCPv6 for controlling the address + selection policy table is not recommended and SHOULD NOT be used. + + At the same time, Router Advertisements provide a reliable mechanism + to influence the source address selection process via PIO, RIO, and + default router preferences. As all those options have been + standardized by the IETF and are supported by various operating + systems, no changes are required on hosts. First-hop routers in the + enterprise network 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. As ICMPv6 message generation can be + rate limited on routers, it SHOULD NOT be used as the only mechanism + to influence source address selection on hosts. While hosts SHOULD + select the correct source address for a given destination, 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 discuss 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 prevent 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 initiate 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 in order + to force clients to renew them often. + + This approach would prevent H31 from using S=2001:db8:0:b010::31 to + reach a host on the Internet. However, it would also prevent H31 + from using S=2001:db8:0:b010::31 to reach H61 at + D=2001:db8:0:6666::61, which is not desirable. + + Another potential 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 initiate this process + by sending a Reconfigure message to H31. Note that [RFC8415] + requires that Reconfigure messages use DHCP authentication. DHCP + authentication could be avoided by using short address lifetimes to + force clients to send Renew messages to the server often. If the + host does not obtain 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 SERb1 + + The described solution has a number of significant drawbacks, some of + them already discussed in Section 6.2.1. + + * DHCPv6 support is not required for an IPv6 host, and there are + operating systems that do not support DHCPv6. Besides that, it + does not appear that [RFC7078] has been widely implemented on host + operating systems. + + * [RFC7078] does not clearly specify this kind of a dynamic use case + in which the address selection policy needs to be updated quickly + in response to the failure of a link. In a large network, it + would present scalability issues as many hosts need to be + reconfigured in a very short period of time. + + * Updating DHCPv6 server configuration each time an ISP's uplink + changes its state introduces some scalability issues, especially + for mid/large distributed-scale enterprise networks. In addition + to that, the policy table needs to be manually configured by + administrators, which makes that solution prone to human error. + + * No mechanism exists for making DHCPv6 servers aware of network + topology/routing changes in the network. In general, having + DHCPv6 servers monitor network-related events sounds like a bad + idea as it requires completely new functionality beyond the scope + of the DHCPv6 role. + +6.3.2. Controlling Default Source Address Selection with Router + Advertisements + + The same mechanism as discussed in Section 6.2.2 can be used to + control the source address selection in the case of 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 consider a scenario in which all uplinks are operational, and + 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 but H61. + To achieve that, R3 should react to SERb1's uplink failure (which + could be detected as the disappearance of 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 that 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 that 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 such a failure scenario, + the forwarding table scoped S=2001:db8:0:b000::/52 contains no + entries, indicating that R3 can 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 we look at how ICMPv6 messages can provide 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 these 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 + being originated by SERa. 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). This would be + forwarded to SERa based on the source-prefix-scoped default + destination route still being originated by SERa, and SERa would + forward it to ISP-A. As discussed above, if we are willing to extend + ICMPv6, SERa can even tell H31 what source address it should use to + reach that destination. The expected host behavior has been + discussed in Section 6.2.3. Using ICMPv6 would have the same + scalability/rate limiting issues that are 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 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 + + It appears that DHCPv6 is not particularly well suited to quickly + changing the source address used by a host when an uplink fails, + which eliminates DHCPv6 from the list of potential solutions. On the + other hand, Router Advertisements provide a reliable mechanism to + dynamically provide hosts with a list of valid prefixes to use as + source addresses as well as to prevent the use of particular + prefixes. While no additional new features are required to be + implemented on hosts, routers need to be able to send RAs based on + the state of scoped forwarding table entries and to react to network + topology changes by sending RAs with particular parameters set. + + It seems that the use of ICMPv6 Destination Unreachable messages + generated by the SER (or any SADR-capable) routers, together with the + use of RAs to signal source address selection errors back to hosts, + has the potential to provide a support mechanism. However, + scalability issues may arise in large networks when topology suddenly + changes. Therefore, it is highly desirable that hosts are able to + select the correct source address in the case of uplink failure, with + ICMPv6 being an additional mechanism to signal unexpected failures + back to hosts. + + The current behaviors of different host operating systems upon + receipt of an ICMPv6 Destination Unreachable message with Code 5 + (Source address failed ingress/egress policy) is not clear to the + authors. Information from implementers, users, and testing would be + quite helpful in evaluating this approach. + +6.4. Selecting Default Source Address upon Failed Uplink Recovery + + The next logical step is to look at the scenario when a failed uplink + on SERb1 to ISP-B comes back up, so the hosts can start using source + addresses belonging to 2001:db8:0:b000::/52 again. + +6.4.1. Controlling Default Source Address Selection with DHCPv6 + + The mechanism to use DHCPv6 to instruct 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 + quite similar to one discussed in Section 6.3.1 and shares the same + drawbacks. + +6.4.2. Controlling Default Source Address Selection with Router + Advertisements + + Let's look at the scenario discussed in Section 6.3.2. If the + uplink(s) failure caused the complete withdrawal of prefixes from the + 2001:db8:0:b000::/52 address space by setting the Preferred Lifetime + value to zero, then the recovery of the link should just trigger the + sending of a new RA with a non-zero Preferred Lifetime. In another + scenario discussed in Section 6.3.2, the failure of the SERb1 uplink + to ISP-B leads to the disappearance of the (S=2001:db8:0:b000::/52, + D=::/0) entry from the forwarding table scoped to + S=2001:db8:0:b000::/52 and, in turn, causes R3 to send RAs with the + Router Lifetime set to zero from LLA_B. The recovery of the SERb1 + uplink to ISP-B leads to the reappearance of the scoped forwarding + entry (S=2001:db8:0:b000::/52, D=::/0). That reappearance acts as a + signal for R3 to advertise itself as a default router for ISP-B + address space domain (to send RAs from LLA_B with non-zero Router + Lifetime). + +6.4.3. Controlling Default Source Address Selection with ICMP + + It looks like ICMPv6 provides a rather limited functionality to + signal back to hosts that particular source addresses have become + valid again. Unless the changes in the uplink specify a particular + (S,D) pair, hosts can keep using the same source address even after + an ISP uplink has come back up. For example, after the uplink from + SERb1 to ISP-B had failed, H31 received 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 + when the SERb1 uplink comes back up, the packets with that (S,D) pair + are still routed to SERa1 and sent to the Internet. Therefore, H31 + is not informed that it should stop using 2001:db8:0:a010::31 and + start using 2001:db8:0:b010::31 again. 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 if the SERb1 uplink to + ISP-B is up, H31 will be unaware of the network topology change and + keep using S=2001:db8:0:a010::31 for Internet destinations, including + H51. + + One of the possible options may be using a scoped route with an + EXCLUSIVE flag as described in Section 6.2.3. SERa1 uplink recovery + would cause the (S=2001:db8:0:a000::/52, D=2001:db8:0:1234::/64) + route to reappear in the routing table. In the absence of that, + route packets to H101 are sent to ISP-B (as ISP-A uplink was down) + with 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. Practically, it might lead to + scalability issues, which have been 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 does not look like a reasonable choice to + manipulate the source address selection process on a host in the case + of network topology changes. Using Router Advertisement provides the + flexible mechanism to dynamically react to network topology changes + (if routers are able to use routing changes as a trigger for sending + out RAs with specific parameters). ICMPv6 could be considered as a + supporting mechanism to signal incorrect source address back to + hosts, but it should not be considered as the only mechanism to + control the address selection in multihomed environments. + +6.5. Selecting Default Source Address When All Uplinks Have Failed + + One particular tricky case is a scenario when all uplinks have + failed. In that case, there is no valid source address to be used + for any external destinations when it might be desirable to have + intra-site connectivity. + +6.5.1. Controlling Default Source Address Selection with DHCPv6 + + From the DHCPv6 perspective, uplinks failure should be treated as two + independent failures and processed as described in Section 6.3.1. At + this stage, it is quite obvious that it would result in a quite + complicated policy table that would need to be explicitly configured + by administrators and therefore seems to be impractical. + +6.5.2. Controlling Default Source Address Selection with Router + Advertisements + + As discussed in Section 6.3.2, an uplink failure causes the scoped + default entry to disappear from the scoped forwarding table and + triggers RAs with zero Router Lifetimes. Complete disappearance of + all scoped entries for a given source prefix would cause the prefix + to be 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 is IPv4 connectivity to + destinations). As a result, intra-site connectivity is broken. One + of the possible ways to solve it is to use ULAs. + + In addition to GUAs, all hosts have ULA addresses assigned, and these + addresses are used for intra-site communication even if there is no + GUA assigned to a host. To avoid accidental leaking of packets with + ULA sources, SADR-capable routers SHOULD have a scoped forwarding + table for ULA source for internal routes but MUST NOT have an entry + for D=::/0 in that table. In the absence of (S=ULA_Prefix; D=::/0), + first-hop routers will 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. The behavior is consistent + with the situation when SERb1 lost the uplink to ISP-B (so there is + no Internet connectivity from 2001:db8:0:b000::/52 sources), but + those sources can be used to reach some specific destinations. In + the case of ULA, there is no Internet connectivity from ULA sources, + but they can be used to reach other ULA destinations. Note that ULA + usage could be particularly useful if all ISPs assign prefixes via + DHCP prefix delegation. In the absence of ULAs, upon the failure of + all uplinks, hosts would lose all their GUAs upon prefix-lifetime + expiration, which again makes intra-site communication impossible. + + It should be noted that Rule 5.5 (prefer a prefix advertised by the + selected next-hop) takes precedence over the Rule 6 (prefer matching + label, which ensures that GUA source addresses are preferred over + ULAs for GUA destinations). Therefore if ULAs are used, the network + administrator needs to ensure that, while the site has Internet + connectivity, hosts do not select a router that advertises ULA + prefixes as their default router. + +6.5.3. Controlling Default Source Address Selection with ICMPv6 + + In the case of the failure of all uplinks, all SERs will drop + outgoing IPv6 traffic and respond with ICMPv6 error messages. In a + large network in which many hosts attempt to reach Internet + destinations, the SERs need to generate an ICMPv6 error for every + packet they receive from hosts, which presents 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 the source address selection on + hosts. + +6.6. Summary of Methods for Controlling Default Source Address + Selection + + This section summarizes the scenarios and options discussed above. + + While DHCPv6 allows administrators to manipulate source address + selection policy tables, this method has a number of significant + disadvantages that eliminate DHCPv6 from a list of potential + solutions: + + 1. It requires hosts to support DHCPv6 and its extension [RFC7078]. + + 2. A DHCPv6 server needs to monitor network state and detect routing + changes. + + 3. 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. + + 4. Network topology/routing policy changes could trigger + simultaneous reconfiguration of large number of hosts, which + presents serious scalability issues. + + The use of Router Advertisements to influence the source address + selection on hosts seem to be the most reliable, flexible, and + scalable solution. It has the following benefits: + + 1. 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). + + 2. No changes in RA format. + + 3. Routers can react to routing table changes by sending RAs, which + would minimize the failover time in the case of network topology + changes. + + 4. 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 benefit from the RA-based solution, 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 relies heavily on hosts correctly implementing + the default address selection algorithm as defined in [RFC6724]. + While the basic, and the most common, multihoming scenario (two or + more Internet uplinks, no 'walled gardens') would work for any host + supporting the minimal implementation of [RFC6724], 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 + + The proposed solution is not designed to preserve connection state in + the case of an uplink failure. 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 behavior is similar to the scenario of + IPv4 multihoming with NAT when an uplink failure causes all + connections to be NATed to completely different public IPv4 + addresses. While it does sound suboptimal, it is determined by the + nature of PA address space: if all uplinks to the particular ISP have + failed, there is no path for the ingress traffic to reach the site, + and the egress traffic is supposed to be dropped by the ingress + filters [BCP38]. The only potential way to overcome this limitation + would be to run BGP with all ISPs and to advertise all site prefixes + to all uplinks - a solution that shares all the drawbacks of using + the 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 in the case of IPv4 NAT-based multihoming, + uplink recovery could cause connection interruptions as well (unless + packet forwarding is integrated with the tracking of existing NAT + sessions so that the egress interface for the existing sessions is + not changed). However, the proposed solution has the benefit of + preserving the 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, the recovery + would just add new, preferred addresses to a host without making any + addresses unavailable. Therefore, connections established to and + from those addresses do not have to be interrupted. + + While it's desirable for active connections to survive ISP failover + events, such 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 to be 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 in which the final outcome of the 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 is 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. + + Therefore, hosts might ignore RDNSS information provided in ULA- + scoped RAs, as 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 are + discussed in this document, but they 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 + + The solution discussed in this document relies on the default address + selection algorithm, Rule 5.5 [RFC6724]. While [RFC6724] considers + this rule as optional, the more recent [RFC8028] states that "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]. Therefore, while hosts compliant with RFC 8028 + already have a mechanism to learn about state changes to ISP uplinks + and to select the source addresses accordingly, many hosts do not + support such a mechanism yet. + + It should be noted that a multihomed enterprise network utilizing + multiple ISP prefixes can be considered as a typical multiple + provisioning domain (mPvD) scenario, as described in [RFC7556]. This + document defines a way for the network to provide the PvD information + to hosts indirectly, using the existing mechanisms. At the same + time, [PROV-DOMAINS] takes one step further and describes a + comprehensive mechanism for hosts to discover the whole set of + configuration information associated with different PvDs/ISPs. + [PROV-DOMAINS] complements this document in terms of enabling hosts + to learn about ISP uplink states and to select the corresponding + source addresses. + +8. Other Solutions + +8.1. Shim6 + + The Shim6 protocol [RFC5533], specified by the Shim6 working group, + allows a host at a multihomed site to communicate with an external + host and to exchange information about possible source and + destination address pairs that they can use to communicate. The + Shim6 working group also specified the REAchability Protocol (REAP) + [RFC5534] to detect failures in the path between working address + pairs and to find new working address pairs. A fundamental + requirement for Shim6 is that both internal and external hosts need + to support Shim6. That is, both the host internal to the multihomed + site and the host external to the multihomed site need to support + Shim6 in order for there to be any benefit for the internal host to + run Shim6. The Shim6 protocol specification was published in 2009, + but it has not been widely implemented. Therefore Shim6 is not + considered as a viable solution for enterprise multihoming. + +8.2. IPv6-to-IPv6 Network Prefix Translation + + IPv6-to-IPv6 Network Prefix Translation (NPTv6) [RFC6296] is not the + focus of this document. NPTv6 suffers from the same fundamental + issue as any other approaches to address translation: it breaks end- + to-end connectivity. Therefore NPTv6 is not considered as a + desirable solution, and this document intentionally focuses on + solving the enterprise multihoming problem without any form of + address translation. + + With increasing interest and ongoing work in bringing path awareness + to transport- and application-layer protocols, hosts might be able to + determine the properties of the various network paths and choose + among the paths that are available to them. As selecting the correct + source address is one of the possible mechanisms that path-aware + hosts may utilize, address translation negatively affects hosts' + path-awareness, which makes NTPv6 an even more undesirable solution. + +8.3. Multipath Transport + + Using multipath transport (such as Multipath TCP (MPTCP) [RFC6824] or + multipath capabilities in QUIC) might solve the problems discussed in + Section 6 since a multipath transport would allow hosts to use + multiple source addresses for a single connection and to switch + between those source addresses when a particular address becomes + unavailable or a new address is assigned to the host interface. + Therefore, if all hosts in the enterprise network use only multipath + transport for all connections, the signaling solution described in + Section 6 might not be needed (it should be noted that Source Address + Dependent Routing would still be required to deliver packets to the + correct uplinks). At the time this document was written, multipath + transport alone could not be considered a solution for the problem of + selecting the source address in a multihomed environment. There are + a significant number of hosts that do not use multipath transport + currently, and it seems unlikely that the situation will change in + the foreseeable future (even if new releases of operating systems + support multipath protocols, there will be a long tail of legacy + hosts). The solution for enterprise multihoming needs to work for + the least common denominator: hosts without multipath transport + support. In addition, not all protocols are using multipath + transport. While multipath transport would complement the solution + described in Section 6, it could not be considered as a sole solution + to the problem of source address selection in multihomed + environments. + + On the other hand, PA-based multihoming could provide additional + benefits to multipath protocols, should those protocols be deployed + in the network. Multipath protocols could leverage source address + selection to achieve maximum path diversity (and potentially improved + performance). + + Therefore, the deployment of multipath protocols should not be + considered as an alternative to the approach proposed in this + document. Instead, both solutions complement each other, so + deploying multipath protocols in a PA-based multihomed network proves + mutually beneficial. + +9. IANA Considerations + + This document has no IANA actions. + +10. Security Considerations + + Section 6.2.3 discusses a mechanism for controlling source address + selection on hosts using ICMPv6 messages. Using ICMPv6 to influence + source address selection allows an attacker to exhaust the list of + candidate source addresses on the host by sending spoofed ICMPv6 Code + 5 for all prefixes known on the network (therefore preventing a + victim from establishing communication with the destination host). + Another possible attack vector is using ICMPv6 Destination + Unreachable Messages with Code 5 to steer the egress traffic towards + the particular ISP, so the attacker can benefit from their ability + doing 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 (to ensure that the ICMPv6 message was triggered by a + packet sent by the host). + + 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 as it would break the legitimate + end-to-end error signaling mechanism for which ICMPv6 was designed. + + 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 + + [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. + + The authors would like to thank the following people (in alphabetical + order) for their review and 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. + +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 |