draft-ietf-rtgwg-enterprise-pa-multihoming-11.txt   draft-ietf-rtgwg-enterprise-pa-multihoming-12.txt 
Routing Working Group F. Baker Routing Working Group F. Baker
Internet-Draft Internet-Draft
Intended status: Informational C. Bowers Intended status: Informational C. Bowers
Expires: January 4, 2020 Juniper Networks Expires: February 1, 2020 Juniper Networks
J. Linkova J. Linkova
Google Google
July 3, 2019 July 31, 2019
Enterprise Multihoming using Provider-Assigned IPv6 Addresses without Enterprise Multihoming using Provider-Assigned IPv6 Addresses without
Network Prefix Translation: Requirements and Solutions Network Prefix Translation: Requirements and Solutions
draft-ietf-rtgwg-enterprise-pa-multihoming-11 draft-ietf-rtgwg-enterprise-pa-multihoming-12
Abstract Abstract
Connecting an enterprise site to multiple ISPs over IPv6 using Connecting an enterprise site to multiple ISPs over IPv6 using
provider-assigned addresses is difficult without the use of some form provider-assigned addresses is difficult without the use of some form
of Network Address Translation (NAT). Much has been written on this 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 topic over the last 10 to 15 years, but it still remains a problem
without a clearly defined or widely implemented solution. Any without a clearly defined or widely implemented solution. Any
multihoming solution without NAT requires hosts at the site to have multihoming solution without NAT requires hosts at the site to have
addresses from each ISP and to select the egress ISP by selecting a addresses from each ISP and to select the egress ISP by selecting a
skipping to change at page 2, line 10 skipping to change at page 2, line 10
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 4, 2020. This Internet-Draft will expire on February 1, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 6 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 6
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Enterprise Multihoming Use Cases . . . . . . . . . . . . . . 8 4. Enterprise Multihoming Use Cases . . . . . . . . . . . . . . 8
4.1. Simple ISP Connectivity with Connected SERs . . . . . . . 8 4.1. Simple ISP Connectivity with Connected SERs . . . . . . . 8
4.2. Simple ISP Connectivity Where SERs Are Not Directly 4.2. Simple ISP Connectivity Where SERs Are Not Directly
Connected . . . . . . . . . . . . . . . . . . . . . . . . 9 Connected . . . . . . . . . . . . . . . . . . . . . . . . 10
4.3. Enterprise Network Operator Expectations . . . . . . . . 11 4.3. Enterprise Network Operator Expectations . . . . . . . . 12
4.4. More complex ISP connectivity . . . . . . . . . . . . . . 13 4.4. More complex ISP connectivity . . . . . . . . . . . . . . 14
4.5. ISPs and Provider-Assigned Prefixes . . . . . . . . . . . 15 4.5. ISPs and Provider-Assigned Prefixes . . . . . . . . . . . 16
4.6. Simplified Topologies . . . . . . . . . . . . . . . . . . 16 4.6. Simplified Topologies . . . . . . . . . . . . . . . . . . 17
5. Generating Source-Prefix-Scoped Forwarding Tables . . . . . 16 5. Generating Source-Prefix-Scoped Forwarding Tables . . . . . 17
6. Mechanisms For Hosts To Choose Good Source Addresses In A 6. Mechanisms For Hosts To Choose Good Default Source Addresses
Multihomed Site . . . . . . . . . . . . . . . . . . . . . . . 23 In A Multihomed Site . . . . . . . . . . . . . . . . . . . . 24
6.1. Source Address Selection Algorithm on Hosts . . . . . . . 25 6.1. Default Source Address Selection Algorithm on Hosts . . . 26
6.2. Selecting Source Address When Both Uplinks Are Working . 28 6.2. Selecting Default Source Address When Both Uplinks Are
6.2.1. Distributing Address Selection Policy Table with Working . . . . . . . . . . . . . . . . . . . . . . . . . 29
DHCPv6 . . . . . . . . . . . . . . . . . . . . . . . 28 6.2.1. Distributing Default Address Selection Policy Table
6.2.2. Controlling Source Address Selection With Router with DHCPv6 . . . . . . . . . . . . . . . . . . . . . 29
Advertisements . . . . . . . . . . . . . . . . . . . 29 6.2.2. Controlling Default Source Address Selection With
6.2.3. Controlling Source Address Selection With ICMPv6 . . 31 Router Advertisements . . . . . . . . . . . . . . . . 30
6.2.4. Summary of Methods For Controlling Source Address 6.2.3. Controlling Default Source Address Selection With
Selection To Implement Routing Policy . . . . . . . . 32 ICMPv6 . . . . . . . . . . . . . . . . . . . . . . . 32
6.3. Selecting Source Address When One Uplink Has Failed . . . 33 6.2.4. Summary of Methods For Controlling Default Source
6.3.1. Controlling Source Address Selection With DHCPv6 . . 34 Address Selection To Implement Routing Policy . . . . 33
6.3.2. Controlling Source Address Selection With Router 6.3. Selecting Default Source Address When One Uplink Has
Advertisements . . . . . . . . . . . . . . . . . . . 35 Failed . . . . . . . . . . . . . . . . . . . . . . . . . 34
6.3.3. Controlling Source Address Selection With ICMPv6 . . 36 6.3.1. Controlling Default Source Address Selection With
6.3.4. Summary Of Methods For Controlling Source Address DHCPv6 . . . . . . . . . . . . . . . . . . . . . . . 35
Selection On The Failure Of An Uplink . . . . . . . . 37 6.3.2. Controlling Default Source Address Selection With
6.4. Selecting Source Address Upon Failed Uplink Recovery . . 37 Router Advertisements . . . . . . . . . . . . . . . . 36
6.4.1. Controlling Source Address Selection With DHCPv6 . . 37 6.3.3. Controlling Default Source Address Selection With
6.4.2. Controlling Source Address Selection With Router ICMPv6 . . . . . . . . . . . . . . . . . . . . . . . 37
Advertisements . . . . . . . . . . . . . . . . . . . 38 6.3.4. Summary Of Methods For Controlling Default Source
6.4.3. Controlling Source Address Selection With ICMP . . . 38 Address Selection On The Failure Of An Uplink . . . . 38
6.4.4. Summary Of Methods For Controlling Source Address 6.4. Selecting Default Source Address Upon Failed Uplink
Selection Upon Failed Uplink Recovery . . . . . . . . 39 Recovery . . . . . . . . . . . . . . . . . . . . . . . . 38
6.5. Selecting Source Address When All Uplinks Failed . . . . 39 6.4.1. Controlling Default Source Address Selection With
6.5.1. Controlling Source Address Selection With DHCPv6 . . 39 DHCPv6 . . . . . . . . . . . . . . . . . . . . . . . 38
6.5.2. Controlling Source Address Selection With Router 6.4.2. Controlling Default Source Address Selection With
Advertisements . . . . . . . . . . . . . . . . . . . 39 Router Advertisements . . . . . . . . . . . . . . . . 39
6.5.3. Controlling Source Address Selection With ICMPv6 . . 40 6.4.3. Controlling Default Source Address Selection With
6.5.4. Summary Of Methods For Controlling Source Address ICMP . . . . . . . . . . . . . . . . . . . . . . . . 39
Selection When All Uplinks Failed . . . . . . . . . . 40 6.4.4. Summary Of Methods For Controlling Default Source
6.6. Summary Of Methods For Controlling Source Address Address Selection Upon Failed Uplink Recovery . . . . 40
Selection . . . . . . . . . . . . . . . . . . . . . . . . 40 6.5. Selecting Default Source Address When All Uplinks Failed 40
6.7. Solution Limitations . . . . . . . . . . . . . . . . . . 42 6.5.1. Controlling Default Source Address Selection With
6.7.1. Connections Preservation . . . . . . . . . . . . . . 42 DHCPv6 . . . . . . . . . . . . . . . . . . . . . . . 40
6.8. Other Configuration Parameters . . . . . . . . . . . . . 43 6.5.2. Controlling Default Source Address Selection With
6.8.1. DNS Configuration . . . . . . . . . . . . . . . . . . 43 Router Advertisements . . . . . . . . . . . . . . . . 40
7. Deployment Considerations . . . . . . . . . . . . . . . . . . 44 6.5.3. Controlling Default Source Address Selection With
7.1. Deploying SADR Domain . . . . . . . . . . . . . . . . . . 44 ICMPv6 . . . . . . . . . . . . . . . . . . . . . . . 41
7.2. Hosts-Related Considerations . . . . . . . . . . . . . . 45 6.5.4. Summary Of Methods For Controlling Default Source
8. Other Solutions . . . . . . . . . . . . . . . . . . . . . . . 45 Address Selection When All Uplinks Failed . . . . . . 41
8.1. Shim6 . . . . . . . . . . . . . . . . . . . . . . . . . . 45 6.6. Summary Of Methods For Controlling Default Source Address
8.2. IPv6-to-IPv6 Network Prefix Translation . . . . . . . . . 46 Selection . . . . . . . . . . . . . . . . . . . . . . . . 41
8.3. Multipath Transport . . . . . . . . . . . . . . . . . . . 46 6.7. Solution Limitations . . . . . . . . . . . . . . . . . . 43
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47 6.7.1. Connections Preservation . . . . . . . . . . . . . . 43
10. Security Considerations . . . . . . . . . . . . . . . . . . . 47 6.8. Other Configuration Parameters . . . . . . . . . . . . . 44
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 48 6.8.1. DNS Configuration . . . . . . . . . . . . . . . . . . 44
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 48 7. Deployment Considerations . . . . . . . . . . . . . . . . . . 45
12.1. Normative References . . . . . . . . . . . . . . . . . . 48 7.1. Deploying SADR Domain . . . . . . . . . . . . . . . . . . 46
12.2. Informative References . . . . . . . . . . . . . . . . . 50 7.2. Hosts-Related Considerations . . . . . . . . . . . . . . 46
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51 8. Other Solutions . . . . . . . . . . . . . . . . . . . . . . . 47
8.1. Shim6 . . . . . . . . . . . . . . . . . . . . . . . . . . 47
8.2. IPv6-to-IPv6 Network Prefix Translation . . . . . . . . . 47
8.3. Multipath Transport . . . . . . . . . . . . . . . . . . . 47
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48
10. Security Considerations . . . . . . . . . . . . . . . . . . . 48
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 49
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 49
12.1. Normative References . . . . . . . . . . . . . . . . . . 49
12.2. Informative References . . . . . . . . . . . . . . . . . 51
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52
1. Introduction 1. Introduction
Site multihoming, the connection of a subscriber network to multiple Site multihoming, the connection of a subscriber network to multiple
upstream networks using redundant uplinks, is a common enterprise upstream networks using redundant uplinks, is a common enterprise
architecture for improving the reliability of its Internet architecture for improving the reliability of its Internet
connectivity. If the site uses provider-independent (PI) addresses, connectivity. If the site uses provider-independent (PI) addresses,
all traffic originating from the enterprise can use source addresses all traffic originating from the enterprise can use source addresses
from the PI address space. Site multihoming with PI addresses is from the PI address space. Site multihoming with PI addresses is
commonly used with both IPv4 and IPv6, and does not present any new commonly used with both IPv4 and IPv6, and does not present any new
skipping to change at page 23, line 32 skipping to change at page 24, line 32
until it exits the site. Therefore all SADR-capable routers within until it exits the site. Therefore all SADR-capable routers within
the domain MUST be logically connected. the domain MUST be logically connected.
Note that the mechanism described here for converting source-prefix- Note that the mechanism described here for converting source-prefix-
scoped destination prefix routing advertisements into forwarding scoped destination prefix routing advertisements into forwarding
state is somewhat different from that proposed in state is somewhat different from that proposed in
[I-D.ietf-rtgwg-dst-src-routing]. The method described in the [I-D.ietf-rtgwg-dst-src-routing]. The method described in the
current document is functionally equivalent, but it is based on current document is functionally equivalent, but it is based on
application of existing mechanisms for the described scenarios. application of existing mechanisms for the described scenarios.
6. Mechanisms For Hosts To Choose Good Source Addresses In A Multihomed 6. Mechanisms For Hosts To Choose Good Default Source Addresses In A
Site Multihomed Site
Until this point, we have made the assumption that hosts are able to Until this point, we have made the assumption that hosts are able to
choose the correct source address using some unspecified mechanism. choose the correct source address using some unspecified mechanism.
This has allowed us to just focus on what the routers in a multihomed 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 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 ISP based on source address. Now we look at possible mechanisms for
hosts to choose the correct source address. We also look at what hosts to choose the correct source address. We also look at what
role, if any, the routers may play in providing information that role, if any, the routers may play in providing information that
helps hosts to choose source addresses. helps hosts to choose source addresses.
skipping to change at page 25, line 5 skipping to change at page 26, line 5
network. The two proactive methods are Neighbor Discovery Router network. The two proactive methods are Neighbor Discovery Router
Advertisements and DHCPv6. The one reactive method we consider is Advertisements and DHCPv6. The one reactive method we consider is
ICMPv6. Note that we are explicitly excluding the possibility of ICMPv6. Note that we are explicitly excluding the possibility of
having hosts participate in or even listen directly to routing having hosts participate in or even listen directly to routing
protocol advertisements. protocol advertisements.
First we look at how a host is currently expected to select the First we look at how a host is currently expected to select the
default source and destination addresses to be used for a new default source and destination addresses to be used for a new
connection. connection.
6.1. Source Address Selection Algorithm on Hosts 6.1. Default Source Address Selection Algorithm on Hosts
[RFC6724] defines the algorithms that hosts are expected to use to [RFC6724] defines the algorithms that hosts are expected to use to
select source and destination addresses for packets. It defines an select source and destination addresses for packets. It defines an
algorithm for selecting a source address and a separate algorithm for algorithm for selecting a source address and a separate algorithm for
selecting a destination address. Both of these algorithms depend on selecting a destination address. Both of these algorithms depend on
a policy table. [RFC6724] defines a default policy which produces a policy table. [RFC6724] defines a default policy which produces
certain behavior. certain behavior.
The rules in the two algorithms in [RFC6724] depend on many different The rules in the two algorithms in [RFC6724] depend on many different
properties of addresses. While these are needed for understanding properties of addresses. While these are needed for understanding
skipping to change at page 28, line 16 skipping to change at page 29, line 16
hosts to select default addresses that applications and upper-layer hosts to select default addresses that applications and upper-layer
protocols can use. Applications and upper-layer protocols can make protocols can use. Applications and upper-layer protocols can make
their own choices on selecting source addresses. The mechanism their own choices on selecting source addresses. The mechanism
proposed in this document attempts to ensure that the subset of proposed in this document attempts to ensure that the subset of
source addresses available for applications and upper-layer protocols source addresses available for applications and upper-layer protocols
is selected with the up-to-date network state in mind. The rest of is selected with the up-to-date network state in mind. The rest of
the document discusses various aspects of the default source address the document discusses various aspects of the default source address
selection defined in [RFC6724], calling it for the sake of brevity selection defined in [RFC6724], calling it for the sake of brevity
"the source address selection". "the source address selection".
6.2. Selecting Source Address When Both Uplinks Are Working 6.2. Selecting Default Source Address When Both Uplinks Are Working
Again we return to the topology in Figure 3. Suppose that the site 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 administrator wants to implement a policy by which all hosts need to
use ISP-A to reach H101 at D=2001:db8:0:1234::101. So for example, use ISP-A to reach H101 at D=2001:db8:0:1234::101. So for example,
H31 needs to select S=2001:db8:0:a010::31. H31 needs to select S=2001:db8:0:a010::31.
6.2.1. Distributing Address Selection Policy Table with DHCPv6 6.2.1. Distributing Default Address Selection Policy Table with DHCPv6
This policy can be implemented by using DHCPv6 to distribute an This policy can be implemented by using DHCPv6 to distribute an
address selection policy table that assigns the same label to address selection policy table that assigns the same label to
destination address that match 2001:db8:0:1234::/64 as it does 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 source addresses that match 2001:db8:0:a000::/52. The following two
entries accomplish this. entries accomplish this.
Prefix Precedence Label Prefix Precedence Label
2001:db8:0:1234::/64 50 33 2001:db8:0:1234::/64 50 33
2001:db8:0:a000::/52 50 33 2001:db8:0:a000::/52 50 33
skipping to change at page 29, line 7 skipping to change at page 30, line 7
o DHCPv6 support is not a mandatory requirement for IPv6 hosts o DHCPv6 support is not a mandatory requirement for IPv6 hosts
([RFC6434]), so this method might not work for all devices. ([RFC6434]), so this method might not work for all devices.
o Network administrators are required to explicitly configure the o Network administrators are required to explicitly configure the
desired network access policies on DHCPv6 servers. While it might desired network access policies on DHCPv6 servers. While it might
be feasible in the scenario 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 approach might have some scalability issues, especially if the
centralized DHCPv6 solution is deployed to serve a large number of centralized DHCPv6 solution is deployed to serve a large number of
multiomed sites. multiomed sites.
6.2.2. Controlling Source Address Selection With Router Advertisements 6.2.2. Controlling Default Source Address Selection With Router
Advertisements
Neighbor Discovery currently has two mechanisms to communicate prefix Neighbor Discovery currently has two mechanisms to communicate prefix
information to hosts. The base specification for Neighbor Discovery information to hosts. The base specification for Neighbor Discovery
(see [RFC4861]) defines the Prefix Information Option (PIO) in the (see [RFC4861]) defines the Prefix Information Option (PIO) in the
Router Advertisement (RA) message. When a host receives a PIO with 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 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 from which it assigns itself an IP address using stateless address
autoconfiguration (SLAAC) procedures described in [RFC4862]. In the autoconfiguration (SLAAC) procedures described in [RFC4862]. In the
example of Figure 3, if the site network is using SLAAC, we would 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 expect both R1 and R2 to send RA messages with PIOs for both source
skipping to change at page 31, line 5 skipping to change at page 32, line 5
The mechanism described above relies on Rule 5.5 of the default The mechanism described above relies on Rule 5.5 of the default
source address selection algorithm defined in [RFC6724]. [RFC8028] source address selection algorithm defined in [RFC6724]. [RFC8028]
states that "A host SHOULD select default routers for each prefix it states that "A host SHOULD select default routers for each prefix it
is assigned an address in". It also recommends that hosts should is assigned an address in". It also recommends that hosts should
implement Rule 5.5. of [RFC6724]. Hosts following the implement Rule 5.5. of [RFC6724]. Hosts following the
recommendations specified in [RFC8028] therefore should be able to recommendations specified in [RFC8028] therefore should be able to
benefit from the solution described in this document. No standards benefit from the solution described in this document. No standards
need to be updated in regards to host behavior. need to be updated in regards to host behavior.
6.2.3. Controlling Source Address Selection With ICMPv6 6.2.3. Controlling Default Source Address Selection With ICMPv6
We now discuss how one might use ICMPv6 to implement the routing 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, 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 even when uplinks to both ISPs are working. If H31 started sending
traffic to H101 with S=2001:db8:0:b010::31 and 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 D=2001:db8:0:1234::101, it would be routed through SER-b1 and out the
uplink to ISP-B. SERb1 could recognize that this traffic is not uplink to ISP-B. SERb1 could recognize that this traffic is not
following the desired routing policy and react by sending an ICMPv6 following the desired routing policy and react by sending an ICMPv6
message back to H31. message back to H31.
skipping to change at page 32, line 44 skipping to change at page 33, line 44
approach to retransmitting packets using different source addresses. approach to retransmitting packets using different source addresses.
As currently defined, the ICMPv6 message does not provide a mechanism As currently defined, the ICMPv6 message does not provide a mechanism
to communication information about which source prefix should be used to communication information about which source prefix should be used
for a retransmitted packet. The current document does not define for a retransmitted packet. The current document does not define
such a mechanism but it might be a useful extension to define in a such a mechanism but it might be a useful extension to define in a
different document. However this approach has some security different document. However this approach has some security
implications such as an ability for an attacker to send spoofed implications such as an ability for an attacker to send spoofed
ICMPv6 messages to signal invalid/unreachable source prefix causing ICMPv6 messages to signal invalid/unreachable source prefix causing
DoS-type attack. DoS-type attack.
6.2.4. Summary of Methods For Controlling Source Address Selection To 6.2.4. Summary of Methods For Controlling Default Source Address
Implement Routing Policy Selection To Implement Routing Policy
So to summarize this section, we have looked at three methods for So to summarize this section, we have looked at three methods for
implementing a simple routing policy where all traffic for a given implementing a simple routing policy where all traffic for a given
destination on the Internet needs to use a particular ISP, even when destination on the Internet needs to use a particular ISP, even when
the uplinks to both ISPs are working. the uplinks to both ISPs are working.
The default source address selection policy cannot distinguish The default source address selection policy cannot distinguish
between the source addresses needed to enforce this policy, so a non- between the source addresses needed to enforce this policy, so a non-
default policy table using associating source and destination default policy table using associating source and destination
prefixes using Label values would need to be installed on each host. prefixes using Label values would need to be installed on each host.
skipping to change at page 33, line 37 skipping to change at page 34, line 37
egress policy) for traffic that is being sent with the wrong source egress policy) for traffic that is being sent with the wrong source
address. The policy distribution could be automated by defining an address. The policy distribution could be automated by defining an
EXCLUSIVE flag for the source-prefix-scoped route which can be set on EXCLUSIVE flag for the source-prefix-scoped route which can be set on
the SER that originates the route. As ICMPv6 message generation can the SER that originates the route. As ICMPv6 message generation can
be rate-limited on routers, it SHOULD NOT be used as the only be rate-limited on routers, it SHOULD NOT be used as the only
mechanism to influence source address selection on hosts. While mechanism to influence source address selection on hosts. While
hosts SHOULD select the correct source address for a given hosts SHOULD select the correct source address for a given
destination the network SHOULD signal any source address issues back destination the network SHOULD signal any source address issues back
to hosts using ICMPv6 error messages. to hosts using ICMPv6 error messages.
6.3. Selecting Source Address When One Uplink Has Failed 6.3. Selecting Default Source Address When One Uplink Has Failed
Now we discuss if DHCPv6, Neighbor Discovery Router Advertisements, Now we discuss if DHCPv6, Neighbor Discovery Router Advertisements,
and ICMPv6 can help a host choose the right source address when an 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 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 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 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 that the uplink from SERa to ISP-A is working and that the uplink
from SERb1 to ISP-B is working. from SERb1 to ISP-B is working.
We assume there is no particular routing policy desired, so H31 is We assume there is no particular routing policy desired, so H31 is
free to send packets with S=2001:db8:0:a010::31 or 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 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 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 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 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 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 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 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. S=2001:db8:0:b010::31 in order to reach H61 at D=2001:db8:0:6666::61.
6.3.1. Controlling Source Address Selection With DHCPv6 6.3.1. Controlling Default Source Address Selection With DHCPv6
For this example we assume that the site network in Figure 3 has a 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 centralized DHCP server and all routers act as DHCP relay agents. We
assume that both of the addresses assigned to H31 were assigned via assume that both of the addresses assigned to H31 were assigned via
DHCP. DHCP.
We could try to have the DHCP server monitor the state of the uplink 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 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 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 zero. The DHCP server could initiate this process by sending a
skipping to change at page 35, line 39 skipping to change at page 36, line 39
for mid/large distributed scale enterprise networks. In addition for mid/large distributed scale enterprise networks. In addition
to that, the policy table needs to be manually configured by to that, the policy table needs to be manually configured by
administrators which makes that solution prone to human error. administrators which makes that solution prone to human error.
o No mechanism exists for making DHCPv6 servers aware of network o No mechanism exists for making DHCPv6 servers aware of network
topology/routing changes in the network. In general DHCPv6 topology/routing changes in the network. In general DHCPv6
servers monitoring network-related events sounds like a bad idea servers monitoring network-related events sounds like a bad idea
as completely new functionality beyond the scope of DHCPv6 role is as completely new functionality beyond the scope of DHCPv6 role is
required. required.
6.3.2. Controlling Source Address Selection With Router Advertisements 6.3.2. Controlling Default Source Address Selection With Router
Advertisements
The same mechanism as discussed in Section 6.2.2 can be used to The same mechanism as discussed in Section 6.2.2 can be used to
control the source address selection in the case of an uplink control the source address selection in the case of an uplink
failure. If a particular prefix should not be used as a source for failure. If a particular prefix should not be used as a source for
any destinations, then the router needs to send RA with Preferred any destinations, then the router needs to send RA with Preferred
Lifetime field for that prefix set to 0. Lifetime field for that prefix set to 0.
Let's consider a scenario when all uplinks are operational and H41 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 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 2001:db8:0:a020::/64, default router preference set to 11 (low) and
skipping to change at page 36, line 26 skipping to change at page 37, line 26
hop and 2001:db8:0:b020::41 as a source address. For all traffic 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 following the default route, LLA_A will be used as a next-hop and
2001:db8:0:a020::41 as a source address. 2001:db8:0:a020::41 as a source address.
If all uplinks to ISP-B have failed and therefore source addresses 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 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 table scoped S=2001:db8:0:b000::/52 contains no entries. Hosts can
be instructed to stop using source addresses from that block by be instructed to stop using source addresses from that block by
sending RAs containing PIO with Preferred Lifetime set to 0. sending RAs containing PIO with Preferred Lifetime set to 0.
6.3.3. Controlling Source Address Selection With ICMPv6 6.3.3. Controlling Default Source Address Selection With ICMPv6
Now we look at how ICMPv6 messages can provide information back to 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 H31. We assume again that at the time of the failure H31 is sending
packets to H501 using (S=2001:db8:0:b010::31, 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, 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 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 default destination (S=2001:db8:0:b000::/52, D=::/0) as well as its
unscoped default destination route. With these routes no longer in 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) 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 would end up at SERa based on the unscoped default destination route
skipping to change at page 37, line 7 skipping to change at page 38, line 7
forward it to ISP-A. As discussed above, if we are willing to extend 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 ICMPv6, SERa can even tell H31 what source address it should use to
reach that destination. The expected host behaviour has been reach that destination. The expected host behaviour has been
discussed in Section 6.2.3. Using ICMPv6 would have the same discussed in Section 6.2.3. Using ICMPv6 would have the same
scalability/rate limiting issues discussed in Section 6.2.3. ISP-B scalability/rate limiting issues discussed in Section 6.2.3. ISP-B
uplink failure immediately makes source addresses from uplink failure immediately makes source addresses from
2001:db8:0:b000::/52 unsuitable for external communication and might 2001:db8:0:b000::/52 unsuitable for external communication and might
trigger a large number of ICMPv6 packets being sent to hosts in that trigger a large number of ICMPv6 packets being sent to hosts in that
subnet. subnet.
6.3.4. Summary Of Methods For Controlling Source Address Selection On 6.3.4. Summary Of Methods For Controlling Default Source Address
The Failure Of An Uplink Selection On The Failure Of An Uplink
It appears that DHCPv6 is not particularly well suited to quickly It appears that DHCPv6 is not particularly well suited to quickly
changing the source address used by a host in the event of the changing the source address used by a host in the event of the
failure of an uplink, which eliminates DHCPv6 from the list of failure of an uplink, which eliminates DHCPv6 from the list of
potential solutions. On the other hand Router Advertisements potential solutions. On the other hand Router Advertisements
provides a reliable mechanism to dynamically provide hosts with a provides a reliable mechanism to dynamically provide hosts with a
list of valid prefixes to use as source addresses as well as prevent list of valid prefixes to use as source addresses as well as prevent
particular prefixes to be used. While no additional new features are particular prefixes to be used. While no additional new features are
required to be implemented on hosts, routers need to be able to send required to be implemented on hosts, routers need to be able to send
RAs based on the state of scoped forwarding tables entries and to RAs based on the state of scoped forwarding tables entries and to
skipping to change at page 37, line 37 skipping to change at page 38, line 37
Therefore it is highly desirable that hosts are able to select the Therefore it is highly desirable that hosts are able to select the
correct source address in case of uplinks failure with ICMPv6 being correct source address in case of uplinks failure with ICMPv6 being
an additional mechanism to signal unexpected failures back to hosts. an additional mechanism to signal unexpected failures back to hosts.
The current behavior of different host operating system when The current behavior of different host operating system when
receiving ICMPv6 Destination Unreachable message with code 5 (Source receiving ICMPv6 Destination Unreachable message with code 5 (Source
address failed ingress/egress policy) is not clear to the authors. address failed ingress/egress policy) is not clear to the authors.
Information from implementers, users, and testing would be quite Information from implementers, users, and testing would be quite
helpful in evaluating this approach. helpful in evaluating this approach.
6.4. Selecting Source Address Upon Failed Uplink Recovery 6.4. Selecting Default Source Address Upon Failed Uplink Recovery
The next logical step is to look at the scenario when a failed uplink 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 on SERb1 to ISP-B is coming back up, so hosts can start using source
addresses belonging to 2001:db8:0:b000::/52 again. addresses belonging to 2001:db8:0:b000::/52 again.
6.4.1. Controlling Source Address Selection With DHCPv6 6.4.1. Controlling Default Source Address Selection With DHCPv6
The mechanism to use DHCPv6 to instruct the hosts (H31 in our The mechanism to use DHCPv6 to instruct the hosts (H31 in our
example) to start using prefixes from ISP-B space (e.g. 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 S=2001:db8:0:b010::31 for H31) to reach hosts on the Internet is
quite similar to one discussed in Section 6.3.1 and shares the same quite similar to one discussed in Section 6.3.1 and shares the same
drawbacks. drawbacks.
6.4.2. Controlling Source Address Selection With Router Advertisements 6.4.2. Controlling Default Source Address Selection With Router
Advertisements
Let's look at the scenario discussed in Section 6.3.2. If the Let's look at the scenario discussed in Section 6.3.2. If the
uplink(s) failure caused the complete withdrawal of prefixes from uplink(s) failure caused the complete withdrawal of prefixes from
2001:db8:0:b000::/52 address space by setting Preferred Lifetime 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 value to 0, then the recovery of the link should just trigger new RA
being sent with non-zero Preferred Lifetime. In another scenario being sent with non-zero Preferred Lifetime. In another scenario
discussed in Section 6.3.2, the SERb1 uplink to ISP-B failure leads discussed in Section 6.3.2, the SERb1 uplink to ISP-B failure leads
to disappearance of the (S=2001:db8:0:b000::/52, D=::/0) entry from 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, 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 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 recovery of the SERb1 uplink to ISP-B leads to
(S=2001:db8:0:b000::/52, D=::/0) scoped forwarding entry re- (S=2001:db8:0:b000::/52, D=::/0) scoped forwarding entry re-
appearance and instructs R3 that it should advertise itself as a appearance and instructs R3 that it should advertise itself as a
default router for ISP-B address space domain (send RAs from LLA_B default router for ISP-B address space domain (send RAs from LLA_B
with non-zero Router Lifetime). with non-zero Router Lifetime).
6.4.3. Controlling Source Address Selection With ICMP 6.4.3. Controlling Default Source Address Selection With ICMP
It looks like ICMPv6 provides a rather limited functionality to It looks like ICMPv6 provides a rather limited functionality to
signal back to hosts that particular source addresses have become signal back to hosts that particular source addresses have become
valid again. Unless the changes in the uplink state a particular valid again. Unless the changes in the uplink state a particular
(S,D) pair, hosts can keep using the same source address even after (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 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 SERb1 to ISP-B had failed, H31 received ICMPv6 Code 5 message (as
described in Section 6.3.3) and allegedly started using described in Section 6.3.3) and allegedly started using
(S=2001:db8:0:a010::31, D=2001:db8:0:5678::501) to reach H501. Now (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 when the SERb1 uplink comes back up, the packets with that (S,D) pair
skipping to change at page 39, line 5 skipping to change at page 40, line 5
flag as described in Section 6.2.3. SERa1 uplink recovery would flag as described in Section 6.2.3. SERa1 uplink recovery would
cause (S=2001:db8:0:a000::/52, D=2001:db8:0:1234::/64) route to 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 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 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- source addresses from 2001:db8:0:b000::/52. When the route re-
appears SERb1 would reject those packets and sends ICMPv6 back as appears SERb1 would reject those packets and sends ICMPv6 back as
discussed in Section 6.2.3. Practically it might lead to scalability discussed in Section 6.2.3. Practically it might lead to scalability
issues which have been already discussed in Section 6.2.3 and issues which have been already discussed in Section 6.2.3 and
Section 6.4.3. Section 6.4.3.
6.4.4. Summary Of Methods For Controlling Source Address Selection Upon 6.4.4. Summary Of Methods For Controlling Default Source Address
Failed Uplink Recovery Selection Upon Failed Uplink Recovery
Once again DHCPv6 does not look like reasonable choice to manipulate Once again DHCPv6 does not look like reasonable choice to manipulate
source address selection process on a host in the case of network source address selection process on a host in the case of network
topology changes. Using Router Advertisement provides the flexible topology changes. Using Router Advertisement provides the flexible
mechanism to dynamically react to network topology changes (if mechanism to dynamically react to network topology changes (if
routers are able to use routing changes as a trigger for sending out routers are able to use routing changes as a trigger for sending out
RAs with specific parameters). ICMPv6 could be considered as a RAs with specific parameters). ICMPv6 could be considered as a
supporting mechanism to signal incorrect source address back to hosts supporting mechanism to signal incorrect source address back to hosts
but should not be considered as the only mechanism to control the but should not be considered as the only mechanism to control the
address selection in multihomed environments. address selection in multihomed environments.
6.5. Selecting Source Address When All Uplinks Failed 6.5. Selecting Default Source Address When All Uplinks Failed
One particular tricky case is a scenario when all uplinks have 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 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- any external destinations while it might be desirable to have intra-
site connectivity. site connectivity.
6.5.1. Controlling Source Address Selection With DHCPv6 6.5.1. Controlling Default Source Address Selection With DHCPv6
From DHCPv6 perspective uplinks failure should be treated as two From DHCPv6 perspective uplinks failure should be treated as two
independent failures and processed as described in Section 6.3.1. At independent failures and processed as described in Section 6.3.1. At
this stage it is quite obvious that it would result in quite this stage it is quite obvious that it would result in quite
complicated policy table which needs to be explicitly configured by complicated policy table which needs to be explicitly configured by
administrators and therefore seems to be impractical. administrators and therefore seems to be impractical.
6.5.2. Controlling Source Address Selection With Router Advertisements 6.5.2. Controlling Default Source Address Selection With Router
Advertisements
As discussed in Section 6.3.2 an uplink failure causes the scoped As discussed in Section 6.3.2 an uplink failure causes the scoped
default entry to disappear from the scoped forwarding table and default entry to disappear from the scoped forwarding table and
triggers RAs with zero Router Lifetime. Complete disappearance of triggers RAs with zero Router Lifetime. Complete disappearance of
all scoped entries for a given source prefix would cause the prefix all scoped entries for a given source prefix would cause the prefix
being withdrawn from hosts by setting Preferred Lifetime value to being withdrawn from hosts by setting Preferred Lifetime value to
zero in PIO. If all uplinks (SERa, SERb1 and SERb2) failed, hosts zero in PIO. If all uplinks (SERa, SERb1 and SERb2) failed, hosts
either lost their default routers and/or have no global IPv6 either lost their default routers and/or have no global IPv6
addresses to use as a source. (Note that 'uplink failure' might mean addresses to use as a source. (Note that 'uplink failure' might mean
'IPv6 connectivity failure with IPv4 still being reachable', in which 'IPv6 connectivity failure with IPv4 still being reachable', in which
skipping to change at page 40, line 26 skipping to change at page 41, line 27
site communication impossible. site communication impossible.
It should be noted that the Rule 5.5 (prefer a prefix advertised by 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 the selected next-hop) takes precedence over the Rule 6 (prefer
matching label, which ensures that GUA source addresses are preferred matching label, which ensures that GUA source addresses are preferred
over ULAs for GUA destinations). Therefore if ULAs are used, the over ULAs for GUA destinations). Therefore if ULAs are used, the
network administrator needs to ensure that while the site has an network administrator needs to ensure that while the site has an
Internet connectivity, hosts do not select a router which advertises Internet connectivity, hosts do not select a router which advertises
ULA prefixes as their default router. ULA prefixes as their default router.
6.5.3. Controlling Source Address Selection With ICMPv6 6.5.3. Controlling Default Source Address Selection With ICMPv6
In case of all uplinks failure all SERs will drop outgoing IPv6 In case of all uplinks failure all SERs will drop outgoing IPv6
traffic and respond with ICMPv6 error message. In the large network traffic and respond with ICMPv6 error message. In the large network
when many hosts are trying to reach Internet destinations it means when many hosts are trying to reach Internet destinations it means
that SERs need to generate an ICMPv6 error to every packet they that SERs need to generate an ICMPv6 error to every packet they
receive from hosts which presents the same scalability issues receive from hosts which presents the same scalability issues
discussed in Section 6.3.3 discussed in Section 6.3.3
6.5.4. Summary Of Methods For Controlling Source Address Selection When 6.5.4. Summary Of Methods For Controlling Default Source Address
All Uplinks Failed Selection When All Uplinks Failed
Again, combining SADR with Router Advertisements seems to be the most Again, combining SADR with Router Advertisements seems to be the most
flexible and scalable way to control the source address selection on flexible and scalable way to control the source address selection on
hosts. hosts.
6.6. Summary Of Methods For Controlling Source Address Selection 6.6. Summary Of Methods For Controlling Default Source Address
Selection
To summarize the scenarios and options discussed above: To summarize the scenarios and options discussed above:
While DHCPv6 allows administrators to manipulate source address While DHCPv6 allows administrators to manipulate source address
selection policy tables, this method has a number of significant selection policy tables, this method has a number of significant
disadvantages which eliminates DHCPv6 from a list of potential disadvantages which eliminates DHCPv6 from a list of potential
solutions: solutions:
1. It required hosts to support DHCPv6 and its extension (RFC7078); 1. It required hosts to support DHCPv6 and its extension (RFC7078);
2. DHCPv6 server needs to monitor network state and detect routing 2. DHCPv6 server needs to monitor network state and detect routing
changes. changes.
3. The use of policy tables requires manual configuration and might 3. The use of policy tables requires manual configuration and might
be extremely complicated, especially in the case of distributed be extremely complicated, especially in the case of distributed
network when large number of remote sites are being served by network when large number of remote sites are being served by
centralized DHCPv6 servers. centralized DHCPv6 servers.
4. Network topology/routing policy changes could trigger 4. Network topology/routing policy changes could trigger
simultaneous re-configuration of large number of hosts which simultaneous re-configuration of large number of hosts which
skipping to change at page 43, line 9 skipping to change at page 44, line 13
to be interrupted. to be interrupted.
While it's desirable for active connections to survive ISP failover While it's desirable for active connections to survive ISP failover
events, for sites using PA address space such events affect the events, for sites using PA address space such events affect the
reachability of IP addresses assigned to hosts. Unless the transport reachability of IP addresses assigned to hosts. Unless the transport
(or even higher level protocols) are capable of suviving the host (or even higher level protocols) are capable of suviving the host
renumbering, the active connections will be broken. The proposed renumbering, the active connections will be broken. The proposed
solution focuses on minimizing the impact of failover for new solution focuses on minimizing the impact of failover for new
connections and for multipath-aware protocols. connections and for multipath-aware protocols.
Another way to preserve connection state would be using multipath
transport as discussed in Section 8.3.
6.8. Other Configuration Parameters 6.8. Other Configuration Parameters
6.8.1. DNS Configuration 6.8.1. DNS Configuration
In mutihomed envinronment each ISP might provide their own list of In mutihomed envinronment each ISP might provide their own list of
DNS servers. For example, in the topology shown in Figure 3, ISP-A 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 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 ISP-B might provide H61 2001:db8:0:6666::61 as a recursive DNS
server. [RFC8106] defines IPv6 Router Advertisement options to allow server. [RFC8106] defines IPv6 Router Advertisement options to allow
IPv6 routers to advertise a list of DNS recursive server addresses IPv6 routers to advertise a list of DNS recursive server addresses
skipping to change at page 48, line 17 skipping to change at page 49, line 24
11. Acknowledgements 11. Acknowledgements
The original outline was suggested by Ole Troan. The original outline was suggested by Ole Troan.
The authors would like to thank the following people (in alphabetical The authors would like to thank the following people (in alphabetical
order) for their review and feedback: Olivier Bonaventure, Deborah order) for their review and feedback: Olivier Bonaventure, Deborah
Brungard, Brian E Carpenter, Lorenzo Colitti, Roman Danyliw, Benjamin Brungard, Brian E Carpenter, Lorenzo Colitti, Roman Danyliw, Benjamin
Kaduk, Suresh Krishnan, Mirja Kuhlewind, David Lamparter, Nicolai Kaduk, Suresh Krishnan, Mirja Kuhlewind, David Lamparter, Nicolai
Leymann, Acee Lindem, Philip Matthewsu, Robert Raszuk, Alvaro Retana, Leymann, Acee Lindem, Philip Matthewsu, Robert Raszuk, Alvaro Retana,
Dave Thaler, Michael Tuxen, Martin Vigoureux, Eric Vyncke, Magnus Pete Resnick, Dave Thaler, Michael Tuxen, Martin Vigoureux, Eric
Westerlund. Vyncke, Magnus Westerlund.
12. References 12. References
12.1. Normative References 12.1. Normative References
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
and E. Lear, "Address Allocation for Private Internets", and E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
<https://www.rfc-editor.org/info/rfc1918>. <https://www.rfc-editor.org/info/rfc1918>.
 End of changes. 32 change blocks. 
93 lines changed or deleted 112 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/