--- 1/draft-ietf-rtgwg-enterprise-pa-multihoming-06.txt 2018-06-11 15:13:11.823127700 -0700 +++ 2/draft-ietf-rtgwg-enterprise-pa-multihoming-07.txt 2018-06-11 15:13:11.927130229 -0700 @@ -1,22 +1,22 @@ Routing Working Group F. Baker Internet-Draft Intended status: Informational C. Bowers -Expires: November 16, 2018 Juniper Networks +Expires: December 13, 2018 Juniper Networks J. Linkova Google - May 15, 2018 + June 11, 2018 Enterprise Multihoming using Provider-Assigned Addresses without Network Prefix Translation: Requirements and Solution - draft-ietf-rtgwg-enterprise-pa-multihoming-06 + draft-ietf-rtgwg-enterprise-pa-multihoming-07 Abstract Connecting an enterprise site to multiple ISPs 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 @@ -42,98 +42,100 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on November 16, 2018. + This Internet-Draft will expire on December 13, 2018. Copyright Notice Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Enterprise Multihoming Requirements . . . . . . . . . . . . . 6 - 2.1. Simple ISP Connectivity with Connected SERs . . . . . . . 6 - 2.2. Simple ISP Connectivity Where SERs Are Not Directly - Connected . . . . . . . . . . . . . . . . . . . . . . . . 7 - 2.3. Enterprise Network Operator Expectations . . . . . . . . 8 - 2.4. More complex ISP connectivity . . . . . . . . . . . . . . 11 - 2.5. ISPs and Provider-Assigned Prefixes . . . . . . . . . . . 13 - 2.6. Simplified Topologies . . . . . . . . . . . . . . . . . . 14 - 3. Generating Source-Prefix-Scoped Forwarding Tables . . . . . 14 - 4. Mechanisms For Hosts To Choose Good Source Addresses In A - Multihomed Site . . . . . . . . . . . . . . . . . . . . . . . 21 - 4.1. Source Address Selection Algorithm on Hosts . . . . . . . 23 - 4.2. Selecting Source Address When Both Uplinks Are Working . 26 - 4.2.1. Distributing Address Selection Policy Table with - DHCPv6 . . . . . . . . . . . . . . . . . . . . . . . 26 - 4.2.2. Controlling Source Address Selection With Router - Advertisements . . . . . . . . . . . . . . . . . . . 26 - 4.2.3. Controlling Source Address Selection With ICMPv6 . . 28 - 4.2.4. Summary of Methods For Controlling Source Address - Selection To Implement Routing Policy . . . . . . . . 30 - 4.3. Selecting Source Address When One Uplink Has Failed . . . 31 - 4.3.1. Controlling Source Address Selection With DHCPv6 . . 32 - 4.3.2. Controlling Source Address Selection With Router - Advertisements . . . . . . . . . . . . . . . . . . . 33 - 4.3.3. Controlling Source Address Selection With ICMPv6 . . 34 - 4.3.4. Summary Of Methods For Controlling Source Address - Selection On The Failure Of An Uplink . . . . . . . . 34 - 4.4. Selecting Source Address Upon Failed Uplink Recovery . . 35 - 4.4.1. Controlling Source Address Selection With DHCPv6 . . 35 - 4.4.2. Controlling Source Address Selection With Router - Advertisements . . . . . . . . . . . . . . . . . . . 35 - 4.4.3. Controlling Source Address Selection With ICMP . . . 36 - 4.4.4. Summary Of Methods For Controlling Source Address - Selection Upon Failed Uplink Recovery . . . . . . . . 36 - 4.5. Selecting Source Address When All Uplinks Failed . . . . 37 - 4.5.1. Controlling Source Address Selection With DHCPv6 . . 37 - 4.5.2. Controlling Source Address Selection With Router - Advertisements . . . . . . . . . . . . . . . . . . . 37 - 4.5.3. Controlling Source Address Selection With ICMPv6 . . 38 - 4.5.4. Summary Of Methods For Controlling Source Address - Selection When All Uplinks Failed . . . . . . . . . . 38 - 4.6. Summary Of Methods For Controlling Source Address - Selection . . . . . . . . . . . . . . . . . . . . . . . . 38 - 4.7. Other Configuration Parameters . . . . . . . . . . . . . 40 - 4.7.1. DNS Configuration . . . . . . . . . . . . . . . . . . 40 - 5. Deployment Considerations . . . . . . . . . . . . . . . . . . 41 - 6. Other Solutions . . . . . . . . . . . . . . . . . . . . . . . 42 - 6.1. Shim6 . . . . . . . . . . . . . . . . . . . . . . . . . . 42 - 6.2. IPv6-to-IPv6 Network Prefix Translation . . . . . . . . . 42 - 6.3. Multipath Transport . . . . . . . . . . . . . . . . . . . 42 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 43 - 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 43 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 - 10.1. Normative References . . . . . . . . . . . . . . . . . . 43 - 10.2. Informative References . . . . . . . . . . . . . . . . . 45 - Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 48 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48 + 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 6 + 3. Enterprise Multihoming Requirements . . . . . . . . . . . . . 6 + 3.1. Simple ISP Connectivity with Connected SERs . . . . . . . 6 + 3.2. Simple ISP Connectivity Where SERs Are Not Directly + Connected . . . . . . . . . . . . . . . . . . . . . . . . 8 + 3.3. Enterprise Network Operator Expectations . . . . . . . . 9 + 3.4. More complex ISP connectivity . . . . . . . . . . . . . . 12 + 3.5. ISPs and Provider-Assigned Prefixes . . . . . . . . . . . 14 + 3.6. Simplified Topologies . . . . . . . . . . . . . . . . . . 15 + 4. Generating Source-Prefix-Scoped Forwarding Tables . . . . . 15 + 5. Mechanisms For Hosts To Choose Good Source Addresses In A + Multihomed Site . . . . . . . . . . . . . . . . . . . . . . . 22 + 5.1. Source Address Selection Algorithm on Hosts . . . . . . . 24 + 5.2. Selecting Source Address When Both Uplinks Are Working . 27 + 5.2.1. Distributing Address Selection Policy Table with + DHCPv6 . . . . . . . . . . . . . . . . . . . . . . . 27 + 5.2.2. Controlling Source Address Selection With Router + Advertisements . . . . . . . . . . . . . . . . . . . 27 + 5.2.3. Controlling Source Address Selection With ICMPv6 . . 29 + 5.2.4. Summary of Methods For Controlling Source Address + Selection To Implement Routing Policy . . . . . . . . 31 + 5.3. Selecting Source Address When One Uplink Has Failed . . . 32 + 5.3.1. Controlling Source Address Selection With DHCPv6 . . 33 + 5.3.2. Controlling Source Address Selection With Router + Advertisements . . . . . . . . . . . . . . . . . . . 34 + + 5.3.3. Controlling Source Address Selection With ICMPv6 . . 35 + 5.3.4. Summary Of Methods For Controlling Source Address + Selection On The Failure Of An Uplink . . . . . . . . 35 + 5.4. Selecting Source Address Upon Failed Uplink Recovery . . 36 + 5.4.1. Controlling Source Address Selection With DHCPv6 . . 36 + 5.4.2. Controlling Source Address Selection With Router + Advertisements . . . . . . . . . . . . . . . . . . . 36 + 5.4.3. Controlling Source Address Selection With ICMP . . . 37 + 5.4.4. Summary Of Methods For Controlling Source Address + Selection Upon Failed Uplink Recovery . . . . . . . . 37 + 5.5. Selecting Source Address When All Uplinks Failed . . . . 38 + 5.5.1. Controlling Source Address Selection With DHCPv6 . . 38 + 5.5.2. Controlling Source Address Selection With Router + Advertisements . . . . . . . . . . . . . . . . . . . 38 + 5.5.3. Controlling Source Address Selection With ICMPv6 . . 39 + 5.5.4. Summary Of Methods For Controlling Source Address + Selection When All Uplinks Failed . . . . . . . . . . 39 + 5.6. Summary Of Methods For Controlling Source Address + Selection . . . . . . . . . . . . . . . . . . . . . . . . 39 + 5.7. Other Configuration Parameters . . . . . . . . . . . . . 41 + 5.7.1. DNS Configuration . . . . . . . . . . . . . . . . . . 41 + 6. Deployment Considerations . . . . . . . . . . . . . . . . . . 42 + 7. Other Solutions . . . . . . . . . . . . . . . . . . . . . . . 43 + 7.1. Shim6 . . . . . . . . . . . . . . . . . . . . . . . . . . 43 + 7.2. IPv6-to-IPv6 Network Prefix Translation . . . . . . . . . 43 + 7.3. Multipath Transport . . . . . . . . . . . . . . . . . . . 43 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 44 + 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 44 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 + 11.1. Normative References . . . . . . . . . . . . . . . . . . 44 + 11.2. Informative References . . . . . . . . . . . . . . . . . 46 + Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 49 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49 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 @@ -192,30 +195,30 @@ [RFC6296] describes a translation solution specifically tailored to meet the requirements of multi-homing with provider-assigned IPv6 addresses. With the IPv6-to-IPv6 Network Prefix Translation (NPTv6) solution, within the site an enterprise can use Unique Local Addresses [RFC4193] or the prefix assigned by one of the ISPs. As traffic leaves the site on an uplink to an ISP, the source address gets translated to an address within the prefix assigned by the ISP on that uplink in a predictable and reversible manner. [RFC6296] is currently classified as Experimental, and it has been implemented by - several vendors. See Section 6.2, for more discussion of NPTv6. + several vendors. See Section 7.2, for more discussion of NPTv6. This document defines routing requirements for enterprise multihoming using provider-assigned IPv6 addresses. We have made no attempt to write these requirements in a manner that is agnostic to potential solutions. Instead, 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. Each host, as discussed in Section 4.1 and + each ISP-assigned prefix. Each host, as discussed in Section 5.1 and [RFC6724], is responsible for choosing the source address applied to each packet it sends. A host SHOULD be able 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 the communication of changes in the network to the host are Neighbor Discovery Router Advertisements, DHCPv6, and ICMPv6. The routers in the enterprise network are responsible for ensuring that packets are delivered to the "correct" ISP uplink based on @@ -231,23 +234,31 @@ with external destinations. The document first looks in more detail at the enterprise networking environments in which this solution is expected to operate. It then discusses existing and proposed mechanisms for hosts to select the source address applied to packets. Finally, it looks at the requirements for routing that are needed to support these enterprise network scenarios and the mechanisms by which hosts are expected to select source addresses dynamically based on network state. -2. Enterprise Multihoming Requirements +2. Requirements Language -2.1. Simple ISP Connectivity with Connected SERs + 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. Enterprise Multihoming Requirements + +3.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 @@ -278,29 +289,29 @@ 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 connecting 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 2.2, we consider a scenario where this is not the case. + Section 3.2, we consider a scenario where this is not the case. For the moment, we assume that the hosts are able to make good choices about which source addresses through some mechanism that doesn't involve the routers in the site network. Here, we focus on 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 4, we examine what role the routed network may + packet. In Section 5, we examine what role the routed network may play in helping hosts make good choices about source addresses for packets. With this solution, routers will need 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 multi- homing. We consider if this is possible and what are the tradeoffs of not having all routers in the site support SADR functionality. @@ -318,21 +329,21 @@ In Figure 1, when only SERa and SERb are capable of source address dependent routing, PA multi-homing 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 as more routers are capable of SADR. For example, if R4, R2, and R6 are upgraded to support SADR, then 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. -2.2. Simple ISP Connectivity Where SERs Are Not Directly Connected +3.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 multi-homing. There are two solutions to ways to enable PA multihoming in this topology. 2001:db8:0:1234::101 H101 | | @@ -368,21 +379,21 @@ 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 multi-homing 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. -2.3. Enterprise Network Operator Expectations +3.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 as 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 traffic from outside the site @@ -477,27 +488,27 @@ 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 4. However, interacting with + will discuss these proposals in Section 5. However, interacting with host operating systems in some manner to ensure a particular source address is chosen for a particular destination prefix is not what an enterprise network administrator would expect to have to do to implement this routing policy. -2.4. More complex ISP connectivity +3.4. More complex ISP connectivity The previous sections considered two variations of a simple multihoming scenario where 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 variation of this are @@ -587,33 +598,33 @@ administrator trying to configure, maintain, and trouble-shoot this multihoming solution, it seems much clearer to have SERb2 originate the source-prefix-scoped destination route correspond 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. -2.5. ISPs and Provider-Assigned Prefixes +3.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 to be supported. 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. 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. -2.6. Simplified Topologies +3.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 having all hosts directly connected to the LAN connecting the two site exit routers, SERa and SERb. The topology could also be simplified by having the uplinks to ISP-A and ISP-B both connected to the same site exit router. However, it is the aim of this draft to provide a solution that applies to a broad a range of enterprise site network topologies, so this draft focuses on providing a solution to the more @@ -622,21 +633,21 @@ 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. -3. Generating Source-Prefix-Scoped Forwarding Tables +4. Generating Source-Prefix-Scoped Forwarding Tables So far we have described in general terms how the routers in this solution that are capable of Source Address Dependent Routing will forward traffic using both normal unscoped destination routes and source-prefix-scoped destination routes. Here we give a precise method for generating a source-prefix-scoped forwarding table on a router that supports SADR. 1. Compute the next-hops for the source-prefix-scoped destination prefixes using only routers in the connected SADR domain. These @@ -921,21 +932,21 @@ An interesting side-effect of deploying SADR is if all routers in a given network support SADR and have a scoped forwarding table, then the unscoped forwarding table can be eliminated which ensures that packets with legitimate source addresses only can leave the network (as there are no scoped forwarding tables for spoofed/bogon source addresses). It would prevent accidental leaks of ULA/reserved/link- local sources to the Internet as well as ensures that no spoofing is possible from the SADR-enabled network. -4. Mechanisms For Hosts To Choose Good Source Addresses In A Multihomed +5. Mechanisms For Hosts To Choose Good 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 just 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. @@ -980,21 +991,21 @@ 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 source and destination address with which it sends a packet. -4.1. Source Address Selection Algorithm on Hosts +5.1. 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 which produces certain behavior. The rules in the two algorithms in [RFC6724] depend on many different properties of addresses. While these are needed for understanding @@ -1123,28 +1134,28 @@ 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 where a host needs to select the correct source address. The first is when both uplinks are working. The second is when one uplink has failed. The third one is a situation when one failed uplink has recovered. The last one is failure of both (all) uplinks. -4.2. Selecting Source Address When Both Uplinks Are Working +5.2. Selecting 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 H01 at D=2001:db8:0:1234::101. So for example, H31 needs to select S=2001:db8:0:a010::31. -4.2.1. Distributing Address Selection Policy Table with DHCPv6 +5.2.1. Distributing 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 address 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 @@ -1163,21 +1174,21 @@ o DHCPv6 support is not a mandatory requirement for IPv6 hosts, so this method might not work for all devices. o Network administrators are required to explicitly configure the desired network access policies on DHCPv6 servers. While it might be feasible in the scenarion 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 multiomed sites. -4.2.2. Controlling Source Address Selection With Router Advertisements +5.2.2. Controlling 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 set, it can use the prefix in the PIO as 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 for both source @@ -1204,21 +1215,21 @@ Information option for Neighbor Discovery Router Advertisements which would associate a source prefix and with a destination prefix. The details of [I-D.pfister-6man-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 that allows a R1 and R2 to explicitly communicate to H31 an association between S=2001:db8:0:a000::/52 D=2001:db8:0:1234::/64 would be needed. However, Rule 5.5 of the source address selection algorithm - (discussed in Section 4.1 above), together with default router + (discussed in Section 5.1 above), 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) @@ -1256,21 +1267,21 @@ The mechanism described above relies on Rule 5.5 of the default source address selection algorithm defined in [RFC6724]. [RFC8028] recommends that a host SHOULD select default routers for each prefix in which it is assigned an address. 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. -4.2.3. Controlling Source Address Selection With ICMPv6 +5.2.3. Controlling 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 is traffic is not following the desired routing policy and react by sending an ICMPv6 message back to H31. @@ -1320,21 +1331,21 @@ software or hardware limits on generating ICMP messages. An 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 signalling hosts SHOULD cache the preferred source address (or prefix) for the given destination (which in turn might cause issues in case of the corresponding ISP uplinks - failure - see Section 4.3). In addition, the same source prefix + failure - see Section 5.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 SHOULD have a specific lifetime. Expiration of the lifetime SHOULD trigger the source address selection algorithm again. Using ICMPv6 Code 5 message for influencing 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 a communication with the destination host). To protect from such @@ -1343,21 +1354,21 @@ 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 communication information about which source prefix should be used for a retransmitted packet. The current document does not define such a mechanism. However, we note that this might be a useful extension to define in a different document. -4.2.4. Summary of Methods For Controlling Source Address Selection To +5.2.4. Summary of Methods For Controlling 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 @@ -1383,42 +1394,42 @@ egress policy) for traffic that is being sent with the wrong source address. The policy distribution can be automated by defining an EXCLUSIVE flag for the source-prefix-scoped route which can 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. -4.3. Selecting Source Address When One Uplink Has Failed +5.3. Selecting Source Address When One Uplink Has Failed Now we discuss if 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 the packet 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. -4.3.1. Controlling Source Address Selection With DHCPv6 +5.3.1. Controlling Source Address Selection With DHCPv6 For this example we assume that the site network in Figure 3 has a centralized DHCP server and 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 settings its valid lifetime to zero. The DHCP server could initiate this process by sending a @@ -1450,21 +1461,21 @@ 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 4.2.1. + them already discussed in Section 5.2.1. o DHCPv6 support is not required for an IPv6 host and there are operating systems which do not support DHCPv6. Besides that, it does not appear that [RFC7078] has been widely implemented on host operating systems. o [RFC7078] does not clearly specify this kind of a dynamic use case where 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 @@ -1475,23 +1486,23 @@ 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. o No mechanism exists for making DHCPv6 servers aware of network topology/routing changes in the network. In general DHCPv6 servers monitoring network-related events sounds like a bad idea as completely new functionality beyond the scope of DHCPv6 role is required. -4.3.2. Controlling Source Address Selection With Router Advertisements +5.3.2. Controlling Source Address Selection With Router Advertisements - The same mechanism as discussed in Section 4.2.2 can be used to + The same mechanism as discussed in Section 5.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 destinations, then the router needs to send RA with Preferred Lifetime field for that prefix set to 0. Let's consider a scenario when all uplinks are operational and H41 receives two different RAs from R3: one from LLA_A with PIO for 2001:db8:0:a020::/64, default router preference set to 11 (low) and another one from LLA_B with PIO for 2001:db8:0:a020::/64, default router preference set to 01 (high) and RIO for 2001:db8:0:6666::/64. @@ -1509,21 +1520,21 @@ 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 uplinks to ISP-B have failed and therefore source addresses from ISP-B address space should not be used at all, the forwarding table scoped S=2001:db8:0:b000::/52 contains no entries. Hosts can be instructed to stop using source addresses from that block by sending RAs containing PIO with Preferred Lifetime set to 0. -4.3.3. Controlling Source Address Selection With ICMPv6 +5.3.3. Controlling 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 @@ -1531,28 +1542,28 @@ 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 behaviour has been - discussed in Section 4.2.3. Potential issue with using ICMPv6 for + discussed in Section 5.2.3. Potential issue with using ICMPv6 for signalling source address issues back to hosts is that uplink to an ISP-B failure immediately invalidates source addresses from 2001:db8:0:b000::/52 for all hosts which triggers a large number of ICMPv6 being sent back to hosts - the same scalability/rate limiting - issues discussed in Section 4.2.3 would apply. + issues discussed in Section 5.2.3 would apply. -4.3.4. Summary Of Methods For Controlling Source Address Selection On +5.3.4. Summary Of Methods For Controlling 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 in the event of the failure of an uplink, which eliminates DHCPv6 from the list of potential solutions. On the other hand Router Advertisements provides a reliable mechanism to dynamically provide hosts with a list of valid prefixes to use as source addresses as well as prevent particular prefixes to be used. While no additional new features are required to be implemented on hosts, routers need to be able to send @@ -1568,112 +1579,112 @@ Therefore it is highly desirable that hosts are able to select the correct source address in case of uplinks failure with ICMPv6 being an additional mechanism to signal unexpected failures back to hosts. The current behavior of different host operating system when receiving 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. -4.4. Selecting Source Address Upon Failed Uplink Recovery +5.4. Selecting 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 is coming back up, so hosts can start using source addresses belonging to 2001:db8:0:b000::/52 again. -4.4.1. Controlling Source Address Selection With DHCPv6 +5.4.1. Controlling 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 4.3.1 and shares the same + quite similar to one discussed in Section 5.3.1 and shares the same drawbacks. -4.4.2. Controlling Source Address Selection With Router Advertisements +5.4.2. Controlling Source Address Selection With Router Advertisements - Let's look at the scenario discussed in Section 4.3.2. If the + Let's look at the scenario discussed in Section 5.3.2. If the uplink(s) failure caused the complete withdrawal of prefixes from 2001:db8:0:b000::/52 address space by setting Preferred Lifetime value to 0, then the recovery of the link should just trigger new RA being sent with non-zero Preferred Lifetime. In another scenario - discussed in Section 4.3.2, the SERb1 uplink to ISP-B failure leads + discussed in Section 5.3.2, the SERb1 uplink to ISP-B failure leads to 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, caused R3 to send RAs from LLA_B with Router Lifetime set to 0. The recovery of the SERb1 uplink to ISP-B leads to (S=2001:db8:0:b000::/52, D=::/0) scoped forwarding entry re- appearance and instructs R3 that it should advertise itself as a default router for ISP-B address space domain (send RAs from LLA_B with non-zero Router Lifetime). -4.4.3. Controlling Source Address Selection With ICMP +5.4.3. Controlling 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 state 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 4.3.3) and allegedly started using + described in Section 5.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 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 option may be using a scoped route with EXCLUSIVE - flag as described in Section 4.2.3. SERa1 uplink recovery would + flag as described in Section 5.2.3. SERa1 uplink recovery would cause (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 which were sent to ISP-B (as ISP-A uplink was down) with source addresses from 2001:db8:0:b000::/52. When the route re- appears SERb1 would reject those packets and sends ICMPv6 back as - discussed in Section 4.2.3. Practically it might lead to scalability - issues which have been already discussed in Section 4.2.3 and - Section 4.4.3. + discussed in Section 5.2.3. Practically it might lead to scalability + issues which have been already discussed in Section 5.2.3 and + Section 5.4.3. -4.4.4. Summary Of Methods For Controlling Source Address Selection Upon +5.4.4. Summary Of Methods For Controlling Source Address Selection Upon Failed Uplink Recovery Once again DHCPv6 does not look like reasonable choice to manipulate 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 should not be considered as the only mechanism to control the address selection in multihomed environments. -4.5. Selecting Source Address When All Uplinks Failed +5.5. Selecting Source Address When All Uplinks 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 while it might be desirable to have intra- site connectivity. -4.5.1. Controlling Source Address Selection With DHCPv6 +5.5.1. Controlling Source Address Selection With DHCPv6 From DHCPv6 perspective uplinks failure should be treated as two - independent failures and processed as described in Section 4.3.1. At + independent failures and processed as described in Section 5.3.1. At this stage it is quite obvious that it would result in quite complicated policy table which needs to be explicitly configured by administrators and therefore seems to be impractical. -4.5.2. Controlling Source Address Selection With Router Advertisements +5.5.2. Controlling Source Address Selection With Router Advertisements - As discussed in Section 4.3.2 an uplink failure causes the scoped + As discussed in Section 5.3.2 an uplink failure causes the scoped default entry to disappear from the scoped forwarding table and triggers RAs with zero Router Lifetime. Complete disappearance of all scoped entries for a given source prefix would cause the prefix being withdrawn from hosts by setting Preferred Lifetime value to zero in PIO. If all uplinks (SERa, SERb1 and SERb2) failed, hosts either lost 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 results intra-site connectivity is broken. One @@ -1699,37 +1710,37 @@ impossible. It should be noted that the 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 adminstrator needs to ensure that while the site has an Internet connectivity, hosts do not select a roter which advertises ULA prefixes as their default router. -4.5.3. Controlling Source Address Selection With ICMPv6 +5.5.3. Controlling Source Address Selection With ICMPv6 In case of all uplinks failure all SERs will drop outgoing IPv6 traffic and respond with ICMPv6 error message. In the large network when many hosts are trying to reach Internet destinations it means that SERs need to generate an ICMPv6 error to every packet they receive from hosts which presents the same scalability issues - discussed in Section 4.3.3 + discussed in Section 5.3.3 -4.5.4. Summary Of Methods For Controlling Source Address Selection When +5.5.4. Summary Of Methods For Controlling 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. -4.6. Summary Of Methods For Controlling Source Address Selection +5.6. Summary Of Methods For Controlling Source Address Selection To summarize 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 which eliminates DHCPv6 from a list of potential solutions: 1. It required hosts to support DHCPv6 and its extension (RFC7078); @@ -1783,44 +1794,44 @@ rule implemented currently. However it should be noted that [RFC8028] states that Rule 5.5 SHOULD be implemented. ICMPv6 Code 5 error message SHOULD be used to complement RA-based solution to signal incorrect source address selection back to hosts, but it SHOULD NOT be considered as the stand-alone solution. To prevent scenarios when hosts in multihomed envinronments incorrectly identify onlink/offlink destinations, hosts should treat ICMPv6 Redirects as discussed in [RFC8028]. -4.7. Other Configuration Parameters +5.7. Other Configuration Parameters -4.7.1. DNS Configuration +5.7.1. DNS Configuration In mutihomed envinronment each ISP might provide their own list of DNS servers. E.g. in the topology show on Figure 3, ISP-A might provide recursive DNS server H51 2001:db8:0:5555::51, while ISP-B might provide H61 2001:db8:0:6666::61 as a recursive DNS server. [RFC8106] defines IPv6 Router Advertisement options to allow IPv6 routers to advertise a list of DNS recursive server addresses and a DNS Search List to IPv6 hosts. Using RDNSS together with 'scoped' RAs as described above would allow a first-hop router (R3 in the Figure 3) to send DNS server addresses and search lists provided by each ISP (or the corporate DNS servers addresses if the enterprise is running its own DNS servers). - As discussed in Section 4.5.2, failure of all ISP uplinks would cause + As discussed in Section 5.5.2, failure of all ISP uplinks would cause deprecaction of all addresses assigned to a host from the address space if all ISPs. If any intra-site IPv6 connectivity is still desirable (most likely to be the case for any mid/large scare - network), then ULAs should be used as discussed in Section 4.5.2. In + network), then ULAs should be used as discussed in Section 5.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 - send for ULA-scoped forwarding table as described in Section 4.5.2. + send for ULA-scoped forwarding table as described in Section 5.5.2. There are some scenarios when the final outcome of the name resolution might be different depending on: o which DNS server is used; o 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 @@ -1850,21 +1861,21 @@ It should be noted that [RFC8106] explicitly prohibits using DNS information if the RA router Lifetime 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 set to 0. However the updated version of RFC6106 ([RFC8106]) has that requirement removed. -5. Deployment Considerations +6. 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 Source Address Dependent Routing (SADR). It also requires hosts to be able to learn when the uplink to an ISP chages its state so the corresponding source addresses should (or should not) be used. Ongoing work to create mechanisms to accomplish this are discussed in this document, but they are still a work in progress. @@ -1884,101 +1895,101 @@ document defines a way for network to provide the PVD information to hosts indirectly, using the existing mechanisms. At the same time [I-D.ietf-intarea-provisioning-domains]takes one step further and describes a comprehensive mechanism for hosts to discover the whole set of configuration information associated with different PVD/ISPs. [I-D.ietf-intarea-provisioning-domains] complements this document in terms of making hosts being able to learn about ISP uplink states and selecting the corresponding source addresses. -6. Other Solutions +7. Other Solutions -6.1. Shim6 +7.1. Shim6 The Shim6 working group specified the Shim6 protocol [RFC5533] which allows a host at a multihomed site to communicate with an external host and exchange information about possible source and destination address pairs that they can use to communicate. It also specified the REAP protocol [RFC5534] to detect failures in the path between working address pairs and 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. -6.2. IPv6-to-IPv6 Network Prefix Translation +7.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 address translation approaches: it breaks end-to- end connectivity. Therefore NPTv6 is not considered as desirable solution and this document intentionally focuses on solving enterprise multihoming problem without any form of address translations. With increasing interest and ongoing work in bringing path awareness to transport and application layer protocols hosts migth be able to determine the properties of the various network paths and choose among paths available to them. As selecting the correct source address is one of the possible mechanisms path-aware hosts may utilize, address translation negatively affects hosts path-awareness which makes NTPv6 even more undesirable solution. -6.3. Multipath Transport +7.3. Multipath Transport Using multipath transport might solve the problems discussed in - Section 4 it would allow hosts to use multiple source addresses for a + Section 5 it would allow hosts to use multiple source addresses for a single connection and switch between source addresses when a particular address becomes unavailable or a new address gets assigned to the host interface. Therefore if all hosts in the enterprise network are only using multipath transport for all connections, the - signalling solution described in Section 4 migth not be needed (it + signalling solution described in Section 5 migth not be needed (it should be noted that the Source Address Dependent Routing would still be required to delver packets to the correct uplinks). Unfortunatelt when this document was written, mutlipath transport alone can not be considered a solition for the problem of selecting the source address in a multihomed envinronments. There are significant number of hosts which do not use mulipath transport currently and it seems unlikely that the situation is going to change in any foreseeable future. As 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 4, it could not be considered as a sole solution to the + Section 5, it could not be considered as a sole solution to the problem of source address selection in multihomed envinronments. -7. IANA Considerations +8. IANA Considerations This memo asks the IANA for no new parameters. -8. Security Considerations +9. Security Considerations This document introduces no new security or privacy considerations. Security considerations of using stateless address autoconfiguration is discussed in [RFC4862]. -9. Acknowledgements +10. Acknowledgements The original outline was suggested by Ole Troan. The authors would like to thank the following people (in alphabetical order) for their review and feedback: Olivier Bonaventure, Brian E Carpenter, Lorenzo Colitti, David Lamparter, Acee Lindem, Philip Matthewsu, Robert Raszuk, Dave Thaler. -10. References +11. References -10.1. Normative References +11.1. Normative References [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, . [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, DOI 10.17487/RFC1123, October 1989, . @@ -2050,26 +2061,30 @@ [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, . [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, . + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, . + [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . -10.2. Informative References +11.2. Informative References [I-D.baker-ipv6-isis-dst-src-routing] Baker, F. and D. Lamparter, "IPv6 Source/Destination Routing using IS-IS", draft-baker-ipv6-isis-dst-src- routing-07 (work in progress), July 2017. [I-D.baker-rtgwg-src-dst-routing-use-cases] Baker, F., Xu, M., Yang, S., and J. Wu, "Requirements and Use Cases for Source/Destination Routing", draft-baker- rtgwg-src-dst-routing-use-cases-02 (work in progress), @@ -2079,24 +2094,24 @@ Boutier, M. and J. Chroboczek, "Source-Specific Routing in Babel", draft-boutier-babel-source-specific-03 (work in progress), July 2017. [I-D.huitema-shim6-ingress-filtering] Huitema, C., "Ingress filtering compatibility for IPv6 multihomed sites", draft-huitema-shim6-ingress- filtering-00 (work in progress), September 2005. [I-D.ietf-intarea-provisioning-domains] - Pfister, P., Vyncke, E., Pauly, T., and D. Schinazi, - "Discovering Provisioning Domain Names and Data", draft- - ietf-intarea-provisioning-domains-01 (work in progress), - February 2018. + Pfister, P., Vyncke, E., Pauly, T., Schinazi, D., and W. + Shao, "Discovering Provisioning Domain Names and Data", + draft-ietf-intarea-provisioning-domains-02 (work in + progress), June 2018. [I-D.ietf-rtgwg-dst-src-routing] Lamparter, D. and A. Smirnov, "Destination/Source Routing", draft-ietf-rtgwg-dst-src-routing-06 (work in progress), October 2017. [I-D.pfister-6man-sadr-ra] Pfister, P., "Source Address Dependent Route Information Option for Router Advertisements", draft-pfister-6man- sadr-ra-01 (work in progress), June 2015.