--- 1/draft-ietf-rtgwg-enterprise-pa-multihoming-07.txt 2019-05-17 15:13:12.447886563 -0700 +++ 2/draft-ietf-rtgwg-enterprise-pa-multihoming-08.txt 2019-05-17 15:13:12.547889079 -0700 @@ -1,66 +1,66 @@ Routing Working Group F. Baker Internet-Draft Intended status: Informational C. Bowers -Expires: December 13, 2018 Juniper Networks +Expires: November 18, 2019 Juniper Networks J. Linkova Google - June 11, 2018 + May 17, 2019 -Enterprise Multihoming using Provider-Assigned Addresses without Network - Prefix Translation: Requirements and Solution - draft-ietf-rtgwg-enterprise-pa-multihoming-07 + Enterprise Multihoming using Provider-Assigned IPv6 Addresses without + Network Prefix Translation: Requirements and Solution + draft-ietf-rtgwg-enterprise-pa-multihoming-08 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 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 attempts to define a complete solution to this problem. It covers the behavior of routers to forward traffic taking into account source address, and it covers the behavior of host to select appropriate 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 documents also makes explicit requirements + 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 Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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 December 13, 2018. + This Internet-Draft will expire on November 18, 2019. Copyright Notice - Copyright (c) 2018 IETF Trust and the persons identified as the + 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 @@ -84,58 +84,57 @@ 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.1. Controlling Source Address Selection With DHCPv6 . . 32 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. Selecting Source Address When All Uplinks Failed . . . . 37 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 + 5.7. Other Configuration Parameters . . . . . . . . . . . . . 40 + 5.7.1. DNS Configuration . . . . . . . . . . . . . . . . . . 40 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 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47 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 @@ -226,27 +224,34 @@ 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 [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. - 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. + This document is organized as follows. Section 3 looks in more + detail at the enterprise networking environments in which this + solution is expected to operate. The discussion of Section 3 uses + the concepts of source-prefix-scoped routing advertisements and + forwarding tables without stopping to provide a precise description + of how source-prefix-scoped routing advertisements are used to + generate source-prefix-scoped forwarding tables. Instead, this + detailed description is provided in Section 4. Section 5 discusses + existing and proposed mechanisms for hosts to select the source + address applied to packets. 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 select source + addresses dynamically based on network state. Section 6 discusses + deployment considerations, while Section 7 discussed 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. Enterprise Multihoming Requirements @@ -301,21 +306,21 @@ 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 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 + 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 multi- homing. We consider if this is possible and what are the tradeoffs 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, @@ -391,37 +396,37 @@ 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 to internal hosts, an enterprise network operator would expect there - to be no visible change in the path taken by this traffic, since this + 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:b010::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 so that these unscoped destination routes get used for forwarding this traffic, then we will have accomplished the goal of keeping forwarding of traffic destined for internal hosts, unaffected by the multihoming solution. For traffic destined for external hosts, it is reasonable to expect - that traffic with an source address from the prefix assigned by ISP-A + that traffic with a source address from the prefix assigned by ISP-A to follow the path to that the traffic would follow if there is 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 tradeoff that the enterprise network operator may decide to make. @@ -453,21 +458,25 @@ 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 multi-homing 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 re-established 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. + 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 example where the behavior of this multihoming solution differs significantly from that of multihoming with PI address or with PA addresses using NAT is in 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 @@ -504,21 +513,21 @@ 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 + 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 which 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 forward out the link from SERa to ISP-A. 2001:db8:0:1234::101 H101 | @@ -554,24 +563,24 @@ 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 which 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 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 it assigned to the site, + 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 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. @@ -668,24 +677,24 @@ source-prefix-scoped forwarding table. As the unscoped forwarding table is considered to be scoped to ::/0 this process starts with propagating routes from the unscoped forwarding table to source-prefix-scoped forwarding tables and then continues with propagating routes to more-specific-source-prefix-scoped forwarding tables should they exist. The forward tables produced by this process are used in the following way to forward packets. - 1. Select the most specific (longerst 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). + 1. Select the most specific (longest prefix match) source-prefix- + scoped forwarding table entries 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. @@ -760,39 +769,39 @@ D=::/0 NH=SERb1 Figure 5: Forwarding Entries Computed at R8 The final step is for R8 to augment the less specific source-prefix- scoped forwarding entries with more specific source-prefix-scoped forwarding entries. As unscoped forwarding table is considered being scoped to ::/0 and both 2001:db8:0:a000::/52 and 2001:db8:0:b000::/52 are more specific prefixes of ::/0, the unscoped (scoped to ::/0) forwarding table needs to be augmented with both more specific - source-prefix-scoped tables. If an less specific scoped forwarding - entry has the exact same destination prefix as an more specific + source-prefix-scoped tables. If a less specific scoped forwarding + entry has the exact same destination prefix as a more specific source-prefix-scoped forwarding entry (including destination prefix length), then the more specific source-prefix-scoped forwarding entry wins. As as an example of how the source 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 for ::/0 forwarding entries). The first four + 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 first four entries the - first table in Figure 6. + result of adding these entries is reflected in the first four entries + the first table in Figure 6. The next less specific 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.) @@ -845,25 +854,25 @@ 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 it 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. + 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 where not all routers in the site support SADR. Continuing with the topology shown in Figure 3, suppose that R3 and @@ -916,26 +925,23 @@ Any traffic that needs to exit the site will eventually hit a SADR- capable router. Once that traffic enters the SADR-capable domain, then it will not leave that domain until it exits the site. This property is required in order to guarantee that there will not be routing loops involving SADR-capable and non-SADR-capable routers. 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 - [I-D.ietf-rtgwg-dst-src-routing]. The method described in this - document is intended to be easy to understand for network enterprise - operators while at the same time being functionally correct. Another - difference is that the method in this document assumes that source - prefix will not overlap. Other differences between the two - approaches still need to be understood and reconciled. + [I-D.ietf-rtgwg-dst-src-routing]. The method described in the + current document is functionally equivalent, but it is intended to be + easier to understand for enterprise network operators. 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. @@ -973,21 +979,21 @@ 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. 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 sessions originated from an external host to an + 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 internal to the multi-homed site, the decision of what 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 @@ -1004,26 +1010,25 @@ 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 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 mulitihomed envinronment - when sending a packet to a remote host. Returning to the example in + choose among multiple source addresses in 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. Let's look - at what rules in [RFC6724] are actually used by H31 in this case. + 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 have 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 the candidate source addresses equals the destination address. Rule 2 (Prefer appropriate scope) is also not used in this scenario, @@ -1036,21 +1041,21 @@ 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. So a possible tool to control source address selection in this scenario would be for a host to make an address deprecated by having routers on that link, R1 and - R2 in Figure 3, send a Router Advertisement message contaning a + R2 in Figure 3, send a Router Advertisement message containing a Prefix Information Option for the source prefix to be discouraged (or prohibited) with the preferred lifetime 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. @@ -1104,21 +1109,21 @@ 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 8 source selection address rules from - [RFC6724], five actually apply to our basic site multihoming + [RFC6724], four actually apply to our basic site multihoming scenario. The rules that are relevant to this scenario are summarized below. o Rule 3: Avoid deprecated addresses. o Rule 5.5: Prefer addresses in a prefix advertised by the next-hop. o Rule 6: Prefer matching label. o Rule 8: Prefer longest matching prefix. @@ -1161,29 +1166,29 @@ 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 [RFC3736]). However this method has a number of + distribution (see [RFC8415]). However this method has a number of disadvantages: 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 + 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 multiomed sites. 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 @@ -1210,38 +1215,38 @@ prefixes. However, there is currently no standardized way to directly associate a particular destination prefix with a particular source prefix. [I-D.pfister-6man-sadr-ra] proposes a Source Address Dependent Route 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 + extension that allows 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 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) and starts sending two different RAs: one is sent from LLA_A and - includes PIO for 2001:db8:0:a020::/64, another us sent from LLA_B and + includes PIO for 2001:db8:0:a020::/64, another is sent from LLA_B and includes PIO for 2001:db8:0:b020::/64. Now it is possible to influence H41 source address selection for destinations which follow the default route by setting default router preference in RAs. If it is desired that H41 reaches H101 (or any destinations in the Internet) via ISP-A, then RAs sent from LLA_A should have default router preference set to 01 (high priority), while RAs sent from LLA_B should have preference set to 11 (low). Then LLA_A would be chosen as a next-hop for H101 and therefore (as 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 @@ -1337,27 +1342,28 @@ 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 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 - attack hosts SHOULD verify that the original packet header included - into ICMPv6 error message was actually sent by the host. + Using ICMPv6 Destination Unreachable Messages with Code 5 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 a communication with the + destination host). To protect from an attack of this kind, hosts + SHOULD verify that the original packet header included into ICMPv6 + error message was actually sent by the host. 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. @@ -1426,40 +1432,40 @@ 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 - Reconfigure Message to H31 as described in Section 19 of [RFC3315]. + 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 the 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 [RFC3315] + by sending a Reconfigure Message to H31. Note that [RFC8415] requires that Reconfigure Message 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 is not obtaining its IP addresses from the DHCP server, then it would need to use the Information Refresh Time option defined in - [RFC4242]. + [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 @@ -1680,21 +1686,21 @@ 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 + destinations). As a result, intra-site connectivity is broken. One of the possible way to solve it is to use ULAs. All hosts have ULA addresses assigned in addition to GUAs and 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 PIO from ULA address space, RIO for the ULA prefix and Router @@ -1706,22 +1712,22 @@ used to reach another ULA destinations. Note that ULA usage could be particularly useful if all ISPs assign prefixes via DHCP-PD. In the absence of ULAs uplinks failure hosts would lost all their GUAs upon prefix lifetime expiration which again makes intra-site communication 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 + network administrator needs to ensure that while the site has an + Internet connectivity, hosts do not select a router which advertises ULA prefixes as their default router. 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 5.3.3 @@ -1776,21 +1782,21 @@ To fully benefit from the RA-based solution, first-hop routers need to implement SADR and be able to send dedicated RAs per scoped forwarding table as discussed above, reacting to network changes with 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 - default address selection algorith as defined in [RFC6724]. While + default address selection algorithm as defined in [RFC6724]. While the basic (and most common) multihoming scenario (two or more Internet uplinks, no 'wall gardens') would work for any host supporting the minimal implementation of [RFC6724], more complex use cases (such as "wall 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. @@ -1799,54 +1805,54 @@ 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]. 5.7. Other Configuration Parameters 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). + DNS servers. For example, in the topology shown in 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 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 + 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 scare 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 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 server out of 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 + In such a scenario it is recommended that the enterprise runs 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: o the host supports RIO as defined in [RFC4191]; o the routers send RIO for routes to DNS server addresses. For example, if it is desirable that host H31 reaches the ISP-A DNS @@ -1867,44 +1873,43 @@ 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. 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 + to learn when the uplink to an ISP changes 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. The solution discussed in this document relies on the default address - selection algorithm ([RFC6724]) Rule 5.5. While [RFC6724] consideres + selection algorithm ([RFC6724]) Rule 5.5. While [RFC6724] considers this rule as optional, the recent [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]. Therefore while RFC8028-compliant hosts already have mechanism to learn about ISP uplinks state changes and selecting the source addresses accordingly, many hosts do not have such mechanism supported yet. It should be noted that multihomed enterprise network utilizing - multipe ISP prefixes can be considered as a typical mutiple - provisioning domain (mPVD) scenario, as desribed in [RFC7556]. This + multiple ISP prefixes can be considered as a typical mutiple + provisioning domain (mPVD) scenario, as described in [RFC7556]. This 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. 7. Other Solutions 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 @@ -1924,223 +1929,153 @@ 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 + to transport and application layer protocols hosts might 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. 7.3. Multipath Transport Using multipath transport might solve the problems discussed in - Section 5 it would allow hosts to use multiple source addresses for a - single connection and switch between source addresses when a + Section 5 since 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 5 migth not be needed (it + signalling solution described in Section 5 might 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 + 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 significant number of hosts + which do not use multipath transport currently and it seems unlikely + that the situation is going to change in any foreseeable future. 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 5, it could not be considered as a sole solution to the - problem of source address selection in multihomed envinronments. + problem of source address selection in multihomed environments. 8. IANA Considerations This memo asks the IANA for no new parameters. 9. Security Considerations - This document introduces no new security or privacy considerations. - Security considerations of using stateless address autoconfiguration - is discussed in [RFC4862]. + Section 5.2.3 discusses a mechanism for controlling source address + selection on hosts using ICMPv6 messages. It describes how an + attacker could exploit this mechansim by sending spoofed ICMPv6 + messages. It recommends that a given host verify the original packet + header included into ICMPv6 error message was actually sent by the + host itself. + + The security considerations of using stateless address + autoconfiguration are discussed in [RFC4862]. 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. + Carpenter, Lorenzo Colitti, David Lamparter, Nicolai Leymann, Acee + Lindem, Philip Matthewsu, Robert Raszuk, Dave Thaler, Martin + Vigoureux. 11. 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, - . - [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2827] 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, . - [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, - C., and M. Carney, "Dynamic Host Configuration Protocol - for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July - 2003, . - - [RFC3582] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site- - Multihoming Architectures", RFC 3582, - DOI 10.17487/RFC3582, August 2003, - . - - [RFC4116] Abley, J., Lindqvist, K., Davies, E., Black, B., and V. - Gill, "IPv4 Multihoming Practices and Limitations", - RFC 4116, DOI 10.17487/RFC4116, July 2005, - . - [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, November 2005, . [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, . - [RFC4218] Nordmark, E. and T. Li, "Threats Relating to IPv6 - Multihoming Solutions", RFC 4218, DOI 10.17487/RFC4218, - October 2005, . - - [RFC4219] Lear, E., "Things Multihoming in IPv6 (MULTI6) Developers - Should Think About", RFC 4219, DOI 10.17487/RFC4219, - October 2005, . - - [RFC4242] Venaas, S., Chown, T., and B. Volz, "Information Refresh - Time Option for Dynamic Host Configuration Protocol for - IPv6 (DHCPv6)", RFC 4242, DOI 10.17487/RFC4242, November - 2005, . - [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011, . - [RFC7157] Troan, O., Ed., Miles, D., Matsushima, S., Okimoto, T., - and D. Wing, "IPv6 Multihoming without Network Address - Translation", RFC 7157, DOI 10.17487/RFC7157, March 2014, - . - [RFC7556] Anipko, D., Ed., "Multiple Provisioning Domain Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015, . [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, - . + [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, + . 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), - April 2016. - - [I-D.boutier-babel-source-specific] - 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., Schinazi, D., and W. Shao, "Discovering Provisioning Domain Names and Data", - draft-ietf-intarea-provisioning-domains-02 (work in - progress), June 2018. + draft-ietf-intarea-provisioning-domains-04 (work in + progress), March 2019. [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. + Routing", draft-ietf-rtgwg-dst-src-routing-07 (work in + progress), March 2019. [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. - [I-D.xu-src-dst-bgp] - Xu, M., Yang, S., and J. Wu, "Source/Destination Routing - Using BGP-4", draft-xu-src-dst-bgp-00 (work in progress), - March 2016. - - [PATRICIA] - Morrison, D., "Practical Algorithm to Retrieve Information - Coded in Alphanumeric", Journal of the ACM 15(4) - pp514-534, October 1968. - [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 2004, . - [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol - (DHCP) Service for IPv6", RFC 3736, DOI 10.17487/RFC3736, - April 2004, . - [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, . [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, . @@ -2167,38 +2102,20 @@ [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, . [RFC7078] Matsumoto, A., Fujisaki, T., and T. Chown, "Distributing Address Selection Policy Using DHCPv6", RFC 7078, DOI 10.17487/RFC7078, January 2014, . - [RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking - Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April - 2016, . - - [RFC8041] Bonaventure, O., Paasch, C., and G. Detal, "Use Cases and - Operational Experience with Multipath TCP", RFC 8041, - DOI 10.17487/RFC8041, January 2017, - . - - [RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: - Better Connectivity Using Concurrency", RFC 8305, - DOI 10.17487/RFC8305, December 2017, - . - -Appendix A. Change Log - - Initial Version: July 2016 - Authors' Addresses Fred Baker Santa Barbara, California 93117 USA Email: FredBaker.IETF@gmail.com Chris Bowers Juniper Networks