draft-ietf-rtgwg-enterprise-pa-multihoming-09.txt   draft-ietf-rtgwg-enterprise-pa-multihoming-10.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 2, 2020 Juniper Networks Expires: January 4, 2020 Juniper Networks
J. Linkova J. Linkova
Google Google
July 1, 2019 July 3, 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-09 draft-ietf-rtgwg-enterprise-pa-multihoming-10
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
source address for outgoing packets. It also requires routers at the source address for outgoing packets. It also requires routers at the
site to take into account those source addresses when forwarding site to take into account those source addresses when forwarding
packets out towards the ISPs. packets out towards the ISPs.
This document examines currently available mechanisms for providing a This document examines currently available mechanisms for providing a
solution to this problem for a broad range of enterprise topologies. solution to this problem for a broad range of enterprise topologies.
It covers the behavior of routers to forward traffic taking into It covers the behavior of routers to forward traffic taking into
account source address, and it covers the behavior of hosts to select account source address, and it covers the behavior of hosts to select
appropriate source addresses. It also covers any possible role that appropriate default source addresses. It also covers any possible
routers might play in providing information to hosts to help them role that routers might play in providing information to hosts to
select appropriate source addresses. In the process of exploring help them select appropriate source addresses. In the process of
potential solutions, this document also makes explicit requirements exploring potential solutions, this document also makes explicit
for how the solution would be expected to behave from the perspective requirements for how the solution would be expected to behave from
of an enterprise site network administrator. the perspective of an enterprise site network administrator.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 2, 2020. This Internet-Draft will expire on January 4, 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
skipping to change at page 2, line 51 skipping to change at page 2, line 51
6. Mechanisms For Hosts To Choose Good Source Addresses In A 6. Mechanisms For Hosts To Choose Good Source Addresses In A
Multihomed Site . . . . . . . . . . . . . . . . . . . . . . . 23 Multihomed Site . . . . . . . . . . . . . . . . . . . . . . . 23
6.1. Source Address Selection Algorithm on Hosts . . . . . . . 25 6.1. Source Address Selection Algorithm on Hosts . . . . . . . 25
6.2. Selecting Source Address When Both Uplinks Are Working . 28 6.2. Selecting Source Address When Both Uplinks Are Working . 28
6.2.1. Distributing Address Selection Policy Table with 6.2.1. Distributing Address Selection Policy Table with
DHCPv6 . . . . . . . . . . . . . . . . . . . . . . . 28 DHCPv6 . . . . . . . . . . . . . . . . . . . . . . . 28
6.2.2. Controlling Source Address Selection With Router 6.2.2. Controlling Source Address Selection With Router
Advertisements . . . . . . . . . . . . . . . . . . . 29 Advertisements . . . . . . . . . . . . . . . . . . . 29
6.2.3. Controlling Source Address Selection With ICMPv6 . . 31 6.2.3. Controlling Source Address Selection With ICMPv6 . . 31
6.2.4. Summary of Methods For Controlling Source Address 6.2.4. Summary of Methods For Controlling Source Address
Selection To Implement Routing Policy . . . . . . . . 33 Selection To Implement Routing Policy . . . . . . . . 32
6.3. Selecting Source Address When One Uplink Has Failed . . . 33 6.3. Selecting Source Address When One Uplink Has Failed . . . 33
6.3.1. Controlling Source Address Selection With DHCPv6 . . 34 6.3.1. Controlling Source Address Selection With DHCPv6 . . 34
6.3.2. Controlling Source Address Selection With Router 6.3.2. Controlling Source Address Selection With Router
Advertisements . . . . . . . . . . . . . . . . . . . 35 Advertisements . . . . . . . . . . . . . . . . . . . 35
6.3.3. Controlling Source Address Selection With ICMPv6 . . 36 6.3.3. Controlling Source Address Selection With ICMPv6 . . 36
6.3.4. Summary Of Methods For Controlling Source Address 6.3.4. Summary Of Methods For Controlling Source Address
Selection On The Failure Of An Uplink . . . . . . . . 37 Selection On The Failure Of An Uplink . . . . . . . . 37
6.4. Selecting Source Address Upon Failed Uplink Recovery . . 37 6.4. Selecting Source Address Upon Failed Uplink Recovery . . 37
6.4.1. Controlling Source Address Selection With DHCPv6 . . 37 6.4.1. Controlling Source Address Selection With DHCPv6 . . 37
6.4.2. Controlling Source Address Selection With Router 6.4.2. Controlling Source Address Selection With Router
skipping to change at page 3, line 39 skipping to change at page 3, line 39
6.8.1. DNS Configuration . . . . . . . . . . . . . . . . . . 43 6.8.1. DNS Configuration . . . . . . . . . . . . . . . . . . 43
7. Deployment Considerations . . . . . . . . . . . . . . . . . . 44 7. Deployment Considerations . . . . . . . . . . . . . . . . . . 44
7.1. Deploying SADR Domain . . . . . . . . . . . . . . . . . . 44 7.1. Deploying SADR Domain . . . . . . . . . . . . . . . . . . 44
7.2. Hosts-Related Considerations . . . . . . . . . . . . . . 45 7.2. Hosts-Related Considerations . . . . . . . . . . . . . . 45
8. Other Solutions . . . . . . . . . . . . . . . . . . . . . . . 45 8. Other Solutions . . . . . . . . . . . . . . . . . . . . . . . 45
8.1. Shim6 . . . . . . . . . . . . . . . . . . . . . . . . . . 45 8.1. Shim6 . . . . . . . . . . . . . . . . . . . . . . . . . . 45
8.2. IPv6-to-IPv6 Network Prefix Translation . . . . . . . . . 46 8.2. IPv6-to-IPv6 Network Prefix Translation . . . . . . . . . 46
8.3. Multipath Transport . . . . . . . . . . . . . . . . . . . 46 8.3. Multipath Transport . . . . . . . . . . . . . . . . . . . 46
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47
10. Security Considerations . . . . . . . . . . . . . . . . . . . 47 10. Security Considerations . . . . . . . . . . . . . . . . . . . 47
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 47 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 48
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 47 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 48
12.1. Normative References . . . . . . . . . . . . . . . . . . 47 12.1. Normative References . . . . . . . . . . . . . . . . . . 48
12.2. Informative References . . . . . . . . . . . . . . . . . 49 12.2. Informative References . . . . . . . . . . . . . . . . . 50
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 50 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51
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 6, line 18 skipping to change at page 6, line 18
of traffic with external destinations. of traffic with external destinations.
This document is organized as follows. Section 4 looks in more This document is organized as follows. Section 4 looks in more
detail at the enterprise networking environments in which this detail at the enterprise networking environments in which this
solution is expected to operate. The discussion of Section 4 uses solution is expected to operate. The discussion of Section 4 uses
the concepts of source-prefix-scoped routing advertisements and the concepts of source-prefix-scoped routing advertisements and
forwarding tables and provides a description of how source-prefix- forwarding tables and provides a description of how source-prefix-
scoped routing advertisements are used to generate source-prefix- scoped routing advertisements are used to generate source-prefix-
scoped forwarding tables. Instead, this detailed description is scoped forwarding tables. Instead, this detailed description is
provided in Section 5. Section 6 discusses existing and proposed provided in Section 5. Section 6 discusses existing and proposed
mechanisms for hosts to select the source address applied to packets. mechanisms for hosts to select the default source address applied to
It also discusses the requirements for routing that are needed to packets. It also discusses the requirements for routing that are
support these enterprise network scenarios and the mechanisms by needed to support these enterprise network scenarios and the
which hosts are expected to select source addresses dynamically based mechanisms by which hosts are expected to select source addresses for
on network state. Section 7 discusses deployment considerations, new connetions dynamically based on network state. Section 7
while Section 8 discusses other solutions. discusses deployment considerations, while Section 8 discusses other
solutions.
2. Requirements Language 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Terminology 3. Terminology
skipping to change at page 16, line 48 skipping to change at page 16, line 48
method for generating a source-prefix-scoped forwarding table on a method for generating a source-prefix-scoped forwarding table on a
router that supports SADR. router that supports SADR.
1. Compute the next-hops for the source-prefix-scoped destination 1. Compute the next-hops for the source-prefix-scoped destination
prefixes using only routers in the connected SADR domain. These prefixes using only routers in the connected SADR domain. These
are the initial source-prefix-scoped forwarding table entries. are the initial source-prefix-scoped forwarding table entries.
2. Compute the next-hops for the unscoped destination prefixes using 2. Compute the next-hops for the unscoped destination prefixes using
all routers in the IGP. This is the unscoped forwarding table. all routers in the IGP. This is the unscoped forwarding table.
3. Augment each less specific source-prefix-scoped forwarding table 3. For a given source-prefix-scoped forwarding table T (scoped to
with all more specific source-prefix-scoped forwarding tables source prefix P), consider a source-prefix-scoped forwarding
entries based on the following rule. If the destination prefix table T', whose source prefix P' contains P. We call T the more
of the less specific source-prefix-scoped forwarding entry specific source-prefix-scoped forwarding table, and T' the less
exactly matches the destination prefix of an existing more specific source-prefix-scoped forwarding table. We select
specific source-prefix-scoped forwarding entry (including entries in the less specific source-prefix-scoped forwarding
destination prefix length), then do not add the less specific table to augment the more specific source-prefix-scoped
source-prefix-scoped forwarding entry. If the destination prefix forwarding table based on the following rules. If a destination
does NOT match an existing entry, then add the entry to the more prefix of an entry in the less specific source-prefix-scoped
specific source-prefix-scoped forwarding table. As the unscoped forwarding table exactly matches the destination prefix of an
forwarding table is considered to be scoped to ::/0 this process existing entry in the more specific source-prefix-scoped
starts with propagating routes from the unscoped forwarding table forwarding table (including destination prefix length), then do
to source-prefix-scoped forwarding tables and then continues with not add the entry to the more specific source-prefix-scoped
propagating routes to more-specific-source-prefix-scoped forwarding table. If the destination prefix does NOT match an
forwarding tables should they exist. existing entry, then add the entry to the more specific source-
prefix-scoped forwarding table. As the unscoped forwarding table
is considered to be scoped to ::/0, this process will propagate
routes from the unscoped forwarding table to the more specific
source-prefix-scoped forwarding table. If there exist multiple
source-prefix-scoped forwarding tables whose source prefixes
contain P, these source-prefix-scoped forwarding tables should be
processed in order from most specific to least specific.
The forwarding tables produced by this process are used in the The forwarding tables produced by this process are used in the
following way to forward packets. following way to forward packets.
1. Select the most specific (longest prefix match) source-prefix- 1. Select the most specific (longest prefix match) source-prefix-
scoped forwarding table that matches the source address of the scoped forwarding table that matches the source address of the
packet (again, the unscoped forwarding table is considered to be packet (again, the unscoped forwarding table is considered to be
scoped to ::/0). scoped to ::/0).
2. Look up the destination address of the packet in the selected 2. Look up the destination address of the packet in the selected
skipping to change at page 19, line 29 skipping to change at page 19, line 29
D=2001:db8:0:a010::/64 NH=R2 D=2001:db8:0:a010::/64 NH=R2
D=2001:db8:0:b010::/64 NH=R2 D=2001:db8:0:b010::/64 NH=R2
D=2001:db8:0:a020::/64 NH=R5 D=2001:db8:0:a020::/64 NH=R5
D=2001:db8:0:b020::/64 NH=R5 D=2001:db8:0:b020::/64 NH=R5
D=2001:db8:0:5555::/64 NH=R7 D=2001:db8:0:5555::/64 NH=R7
D=2001:db8:0:6666::/64 NH=SERb2 D=2001:db8:0:6666::/64 NH=SERb2
D=::/0 NH=SERb1 D=::/0 NH=SERb1
Figure 5: Forwarding Entries Computed at R8 Figure 5: Forwarding Entries Computed at R8
The final step is for R8 to augment the less specific source-prefix- The final step is for R8 to augment the more specific source-prefix-
scoped forwarding entries with more specific source-prefix-scoped scoped forwarding tables with entries from less specific source-
forwarding entries. As unscoped forwarding table is considered being prefix-scoped forwarding tables. The unscoped forwarding table is
scoped to ::/0 and both 2001:db8:0:a000::/52 and 2001:db8:0:b000::/52 considered as being scoped to ::/0, so both 2001:db8:0:a000::/52 and
are more specific prefixes of ::/0, the unscoped (scoped to ::/0) 2001:db8:0:b000::/52 are more specific prefixes of ::/0. Therefore,
forwarding table needs to be augmented with both more specific entries in the unscoped forwarding table will be evaluated to be
source-prefix-scoped tables. If a less specific scoped forwarding added to these two more specific source-prefix-scoped forwarding
entry has the exact same destination prefix as a more specific tables. If a forwarding entry from the less specific source-prefix-
source-prefix-scoped forwarding entry (including destination prefix scoped forwarding table has the exact same destination prefix
length), then the more specific source-prefix-scoped forwarding entry (including destination prefix length) as the forwarding entry from
wins. the more specific source-prefix-scoped forwarding table, then the
existing forwarding entry in the more specific source-prefix-scoped
forwarding table wins.
As an example of how the source scoped forwarding entries are As an example of how the source scoped forwarding entries are
augmented, we consider how the two entries in the first table in 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 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 augmented with entries from the third table in Figure 5 (the table of
unscoped or scoped to ::/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, 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:b010::/64, D=2001:db8:0:a020::/64, and
D=2001:db8:0:b020::/64) are not an exact match for any of the D=2001:db8:0:b020::/64) are not an exact match for any of the
existing entries in the forwarding table for source prefix existing entries in the forwarding table for source prefix
skipping to change at page 23, line 22 skipping to change at page 23, line 22
D=2001:db8:0:6666::/64 NH=SERb2 D=2001:db8:0:6666::/64 NH=SERb2
D=::/0 NH=R8 D=::/0 NH=R8
Figure 8: Forwarding Table For R5, Which Doesn't Understand Source- Figure 8: Forwarding Table For R5, Which Doesn't Understand Source-
Prefix-Scoped Routes Prefix-Scoped Routes
As all SERs belong to the SADR domain any traffic that needs to exit As all SERs belong to the SADR domain any traffic that needs to exit
the site will eventually hit a SADR-capable router. To prevent the site will eventually hit a SADR-capable router. To prevent
routing loops involving SADR-capable and non-SADR-capable routers, routing loops involving SADR-capable and non-SADR-capable routers,
traffic that enters the SADR-capable domain does not leave the domain traffic that enters the SADR-capable domain does not leave the domain
until it exits the site. Therefore all SADR-capable routers with the until it exits the site. Therefore all SADR-capable routers within
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 Source Addresses In A Multihomed
Site Site
skipping to change at page 23, line 45 skipping to change at page 23, line 45
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.
It should be noted that this section discussed how hosts could select It should be noted that this section discussed how hosts could select
the source address for new connections. Any connection which already the default source address for new connections. Any connection which
exists on a host is bound to the specific source address which can already exists on a host is bound to the specific source address
not be changed. Section 6.7 discusses the connections preservation which can not be changed. Section 6.7 discusses the connections
issue in more details. preservation issue in more details.
Any host that needs to be able to send traffic using the uplinks to a Any host that needs to be able to send traffic using the uplinks to a
given ISP is expected to be configured with an address from the given ISP is expected to be configured with an address from the
prefix assigned by that ISP. The host will control which ISP is used prefix assigned by that ISP. The host will control which ISP is used
for its traffic by selecting one of the addresses configured on the for its traffic by selecting one of the addresses configured on the
host as the source address for outgoing traffic. It is the host as the source address for outgoing traffic. It is the
responsibility of the site network to ensure that a packet with the responsibility of the site network to ensure that a packet with the
source address from an ISP is now sent on an uplink to that ISP. source address from an ISP is now sent on an uplink to that ISP.
If all of the ISP uplinks are working, the choice of source address If all of the ISP uplinks are working, the choice of source address
skipping to change at page 24, line 49 skipping to change at page 24, line 49
For a session originated by a host inside the multi-homed site, the For a session originated by a host inside the multi-homed site, the
decision of what source address to select is more complicated. We decision of what source address to select is more complicated. We
consider three main methods for hosts to get information about the consider three main methods for hosts to get information about the
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
source and destination address with which it sends a packet 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. 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.
skipping to change at page 28, line 5 skipping to change at page 28, line 5
another strategy is to choose a source address, send the packet, get another strategy is to choose a source address, send the packet, get
feedback from the network about whether or not the source address is feedback from the network about whether or not the source address is
correct, and try another source address if it is not. correct, and try another source address if it is not.
We consider four scenarios where a host needs to select the correct We consider four scenarios where a host needs to select the correct
source address. The first is when both uplinks are working. The source address. The first is when both uplinks are working. The
second is when one uplink has failed. The third one is a situation second is when one uplink has failed. The third one is a situation
when one failed uplink has recovered. The last one is failure of when one failed uplink has recovered. The last one is failure of
both (all) uplinks. both (all) uplinks.
It should be noted that [RFC6724] defines the default behaviour for It should be noted that [RFC6724] only defines the behavior of IPv6
IPv6 hosts. The applications and uppler-layer protocols can make hosts to select default addresses that applications and upper-layer
their own choices on selecting source addresses. However the protocols can use. Applications and upper-layer protocols can make
mechanism proposed in this document attempts to ensure that the their own choices on selecting source addresses. The mechanism
subset of source addresses available for applications and upper-layer proposed in this document attempts to ensure that the subset of
protocols is selected with the up-to-date network state in mind. source addresses available for applications and upper-layer protocols
is selected with the up-to-date network state in mind. The rest of
the document discusses various aspects of the default source address
selection defined in [RFC6724], calling it for the sake of brevity
"the source address selection".
6.2. Selecting Source Address When Both Uplinks Are Working 6.2. Selecting 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 Address Selection Policy Table with DHCPv6
skipping to change at page 29, line 45 skipping to change at page 29, line 47
[I-D.pfister-6man-sadr-ra] proposes a Source Address Dependent Route [I-D.pfister-6man-sadr-ra] proposes a Source Address Dependent Route
Information option for Neighbor Discovery Router Advertisements which Information option for Neighbor Discovery Router Advertisements which
would associate a source prefix and with a destination prefix. The would associate a source prefix and with a destination prefix. The
details of [I-D.pfister-6man-sadr-ra] might need tweaking to address 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 this use case. However, in order to be able to use Neighbor
Discovery Router Advertisements to implement this routing policy, an Discovery Router Advertisements to implement this routing policy, an
extension that allows 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 association between S=2001:db8:0:a000::/52 D=2001:db8:0:1234::/64
would be needed. would be needed.
However, Rule 5.5 of the source address selection algorithm However, Rule 5.5 of the default source address selection algorithm
(discussed in Section 6.1 above), together with default router (discussed in Section 6.1 above), together with default router
preference (specified in [RFC4191]) and RIO can be used to influence preference (specified in [RFC4191]) and RIO can be used to influence
a source address selection on a host as described below. Let's look 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 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 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) 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 so Rule 5.5 does not apply. Now let's assume that R3 supports SADR
and has two scoped forwarding tables, one scoped to 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. 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 If R3 generates two different link-local addresses for its interface
skipping to change at page 31, line 42 skipping to change at page 31, line 42
it will forward packets with S=2001:db8:0:b010::31 and it will forward packets with S=2001:db8:0:b010::31 and
D=2001:db8:0:1234::101 out its uplink to ISP-B. D=2001:db8:0:1234::101 out its uplink to ISP-B.
We can also use this source-prefix-scoped route originated by SERa to We can also use this source-prefix-scoped route originated by SERa to
communicate the desired routing policy to SERb1. We can define an communicate the desired routing policy to SERb1. We can define an
EXCLUSIVE flag to be advertised together with the IGP route for EXCLUSIVE flag to be advertised together with the IGP route for
(S=2001:db8:0:a000::/52, D=2001:db8:0:1234::/64). This would allow (S=2001:db8:0:a000::/52, D=2001:db8:0:1234::/64). This would allow
SERa to communicate to SERb that SERb should reject traffic for SERa to communicate to SERb that SERb should reject traffic for
D=2001:db8:0:1234::/64 and respond with an ICMPv6 Destination D=2001:db8:0:1234::/64 and respond with an ICMPv6 Destination
Unreachable Code 5 message, as long as the route for Unreachable Code 5 message, as long as the route for
(S=2001:db8:0:a000::/52, D=2001:db8:0:1234::/64) is present. (S=2001:db8:0:a000::/52, D=2001:db8:0:1234::/64) is present. The
definition of an EXCLUSIVE flag for SADR advertisements in IGPs would
require future standardization work.
Finally, if we are willing to extend ICMPv6 to support this solution, Finally, if we are willing to extend ICMPv6 to support this solution,
then we could create a mechanism for SERb1 to tell the host what then we could create a mechanism for SERb1 to tell the host what
source address it should be using to successfully forward packets source address it should be using to successfully forward packets
that meet the policy. In its current form, when SERb1 sends an that meet the policy. In its current form, when SERb1 sends an
ICMPv6 Destination Unreachable Code 5 message, it is basically ICMPv6 Destination Unreachable Code 5 message, it is basically
saying, "This source address is wrong. Try another source address." saying, "This source address is wrong. Try another source address."
In the absence of a clear indication which address to try next, the In the absence of a clear indication which address to try next, the
host will iterate over all addresses assigned to the interface (e.g. host will iterate over all addresses assigned to the interface (e.g.
various privacy addresses) which would lead to significant delays and various privacy addresses) which would lead to significant delays and
skipping to change at page 32, line 27 skipping to change at page 32, line 29
scalability of ICMPv6-based signaling hosts SHOULD cache the scalability of ICMPv6-based signaling hosts SHOULD cache the
preferred source address (or prefix) for the given destination (which preferred source address (or prefix) for the given destination (which
in turn might cause issues in case of the corresponding ISP uplinks in turn might cause issues in case of the corresponding ISP uplinks
failure - see Section 6.3). In addition, the same source prefix failure - see Section 6.3). In addition, the same source prefix
SHOULD be used for other destinations in the same /64 as the original SHOULD be used for other destinations in the same /64 as the original
destination address. The source prefix to the destination mapping destination address. The source prefix to the destination mapping
SHOULD have a specific lifetime. Expiration of the lifetime SHOULD SHOULD have a specific lifetime. Expiration of the lifetime SHOULD
trigger the source address selection algorithm again. trigger the source address selection algorithm again.
Using ICMPv6 Destination Unreachable Messages with Code 5 to Using ICMPv6 Destination Unreachable Messages with Code 5 to
influence source address selection allows an attacker to exhaust the influence source address selection introduces some security
list of candidate source addresses on the host by sending spoofed challenges which are discussed in Section 10.
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 As currently standardized in [RFC4443], the ICMPv6 Destination
Unreachable Message with Code 5 would allow for the iterative Unreachable Message with Code 5 would allow for the iterative
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
skipping to change at page 33, line 36 skipping to change at page 33, line 28
default router preferences. As all those options have been default router preferences. As all those options have been
standardized by IETF and are supported by various operating systems standardized by IETF and are supported by various operating systems
no changes are required on hosts. First-hop routers in the no changes are required on hosts. First-hop routers in the
enterprise network need to be able of sending different RAs for enterprise network need to be able of sending different RAs for
different SLAAC prefixes (either based on scoped forwarding tables or different SLAAC prefixes (either based on scoped forwarding tables or
based on pre-configured policies). based on pre-configured policies).
SERs can enforce the routing policy by sending ICMPv6 Destination SERs can enforce the routing policy by sending ICMPv6 Destination
Unreachable messages with Code 5 (Source address failed ingress/ Unreachable messages with Code 5 (Source address failed ingress/
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 can 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 Source Address When One Uplink Has Failed
skipping to change at page 37, line 4 skipping to change at page 36, line 50
ingress/egress policy) back to H31. H31 would then know to use ingress/egress policy) back to H31. H31 would then know to use
another source address for that destination and would try with another source address for that destination and would try with
(S=2001:db8:0:a010::31, D=2001:db8:0:5678::501). This would be (S=2001:db8:0:a010::31, D=2001:db8:0:5678::501). This would be
forwarded to SERa based on the source-prefix-scoped default forwarded to SERa based on the source-prefix-scoped default
destination route still being originated by SERa, and SERa would destination route still being originated by SERa, and SERa would
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 immidiately 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 Source Address Selection On
The Failure Of An Uplink 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
skipping to change at page 40, line 14 skipping to change at page 40, line 14
table. In the absence of (S=ULA_Prefix; D=::/0) first-hop routers 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 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 PIO from ULA address space, RIO for the ULA prefix and Router
Lifetime set to zero. The behaviour is consistent with the situation Lifetime set to zero. The behaviour is consistent with the situation
when SERb1 lost the uplink to ISP-B (so there is no Internet when SERb1 lost the uplink to ISP-B (so there is no Internet
connectivity from 2001:db8:0:b000::/52 sources) but those sources can connectivity from 2001:db8:0:b000::/52 sources) but those sources can
be used to reach some specific destinations. In the case of ULA be used to reach some specific destinations. In the case of ULA
there is no Internet connectivity from ULA sources but they can be there is no Internet connectivity from ULA sources but they can be
used to reach another ULA destinations. Note that ULA usage could be used to reach another ULA destinations. Note that ULA usage could be
particularly useful if all ISPs assign prefixes via DHCP-PD. In the particularly useful if all ISPs assign prefixes via DHCP-PD. In the
absence of ULAs upon the all uplinks failure hosts would lost all absence of ULAs, upon the all uplinks failure hosts would lost all
their GUAs upon prefix lifetime expiration which again makes intra- their GUAs upon prefix lifetime expiration which again makes intra-
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.
skipping to change at page 41, line 21 skipping to change at page 41, line 21
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
present serious scalability issues. present serious scalability issues.
The use of Router Advertisements to influence the source address The use of Router Advertisements to influence the source address
selection on hosts seem to be the most reliable, flexible and selection on hosts seem to be the most reliable, flexible and
scalable solution. It has the following benefits: scalable solution. It has the following benefits:
1. no new (non-standard) functionality needs to be implemented on 1. no new (non-standard) functionality needs to be implemented on
hosts (except for [RFC4191] support); hosts (except for [RFC4191] RIO support, which remains at the
time of this writing not widely implemented);
2. no changes in RA format; 2. no changes in RA format;
3. routers can react to routing table changes by sending RAs which 3. routers can react to routing table changes by sending RAs which
would minimize the failover time in the case of network topology would minimize the failover time in the case of network topology
changes; changes;
4. information required for source address selection is broadcast to 4. information required for source address selection is broadcast to
all affected hosts in case of topology change event which all affected hosts in case of topology change event which
improves the scalability of the solution (comparing to DHCPv6 improves the scalability of the solution (comparing to DHCPv6
reconfiguration or ICMPv6 error messages). reconfiguration or ICMPv6 error messages).
To fully benefit from the RA-based solution, first-hop routers need To fully benefit from the RA-based solution, first-hop routers need
to implement SADR and be able to send dedicated RAs per scoped to implement SADR, belong to the SADR domain and be able to send
forwarding table as discussed above, reacting to network changes with dedicated RAs per scoped forwarding table as discussed above,
sending new RAs. It should be noted that the proposed solution would reacting to network changes with sending new RAs. It should be noted
work even if first-hop routers are not SADR-capable but still able to that the proposed solution would work even if first-hop routers are
send individual RAs for each ISP prefix and react to topology changes not SADR-capable but still able to send individual RAs for each ISP
as discussed above (e.g. via configuration knobs). prefix and react to topology changes as discussed above (e.g. via
configuration knobs).
The RA-based solution relies heavily on hosts correctly implementing The RA-based solution relies heavily on hosts correctly implementing
default address selection algorithm as defined in [RFC6724]. While default address selection algorithm as defined in [RFC6724]. While
the basic (and most common) multihoming scenario (two or more the basic (and most common) multihoming scenario (two or more
Internet uplinks, no 'walled gardens') would work for any host Internet uplinks, no 'walled gardens') would work for any host
supporting the minimal implementation of [RFC6724], more complex use supporting the minimal implementation of [RFC6724], more complex use
cases (such as "walled garden" and other scenarios when some ISP cases (such as "walled garden" and other scenarios when some ISP
resources can only be reached from that ISP address space) require resources can only be reached from that ISP address space) require
that hosts support Rule 5.5 of the default address selection that hosts support Rule 5.5 of the default address selection
algorithm. There is some evidence that not all host OSes have that algorithm. There is some evidence that not all host OSes have that
skipping to change at page 45, line 14 skipping to change at page 45, line 16
o The minimal deployable scenario requires enabling SADR on all SERs o The minimal deployable scenario requires enabling SADR on all SERs
and including them into a single SADR domain. and including them into a single SADR domain.
o As discussed in Section 4.2, extending the connected SADR domain o As discussed in Section 4.2, extending the connected SADR domain
beyond that point down to the first-hop routers can produce more beyond that point down to the first-hop routers can produce more
efficient forwarding paths and allow the network to fully benefit efficient forwarding paths and allow the network to fully benefit
from SADR. it would also simplify the operation of the SADR from SADR. it would also simplify the operation of the SADR
domain. domain.
o During the incremental SADR domain expansion from the SERs down
towards first-hop routers it's important to ensure that at any
moment of time all SADR-capable routers within the domain are
logically connected (see Section 5).
7.2. Hosts-Related Considerations 7.2. Hosts-Related Considerations
The solution discussed in this document relies on the default address The solution discussed in this document relies on the default address
selection algorithm ([RFC6724]) Rule 5.5. While [RFC6724] considers selection algorithm ([RFC6724]) Rule 5.5. While [RFC6724] considers
this rule as optional, the recent [RFC8028] states that "A host this rule as optional, the recent [RFC8028] states that "A host
SHOULD select default routers for each prefix it is assigned an SHOULD select default routers for each prefix it is assigned an
address in". It also recommends that hosts should implement Rule address in". It also recommends that hosts should implement Rule
5.5. of [RFC6724]. Therefore while RFC8028-compliant hosts already 5.5. of [RFC6724]. Therefore while RFC8028-compliant hosts already
have mechanism to learn about ISP uplinks state changes and selecting have mechanism to learn about ISP uplinks state changes and selecting
the source addresses accordingly, many hosts do not have such the source addresses accordingly, many hosts do not have such
skipping to change at page 47, line 5 skipping to change at page 47, line 10
that the situation is going to change in any foreseeable future (even that the situation is going to change in any foreseeable future (even
if new releases of operatin systems get multipath protocols support if new releases of operatin systems get multipath protocols support
there will be a long tail of legacy hosts). The solution for there will be a long tail of legacy hosts). The solution for
enterprise multihoming needs to work for the least common enterprise multihoming needs to work for the least common
denominator: hosts without multipath transport support. In addition, denominator: hosts without multipath transport support. In addition,
not all protocols are using multipath transport. While multipath not all protocols are using multipath transport. While multipath
transport would complement the solution described in Section 6, it transport would complement the solution described in Section 6, it
could not be considered as a sole solution to the problem of source could not be considered as a sole solution to the problem of source
address selection in multihomed environments. address selection in multihomed environments.
On the other hand PA-based multihoming could provide additional
benefits for multipath protocol, should those protocols be deployed
in the network. Multipath protocols could leverage source address
selection to achieve maximum path diversity (and potentially improved
performance).
Therefore deploying multipath protocols could not be considered as an
alternative to the approach proposed in this document. Instead both
solutions complement each other so deploying multipath protocols in
PA-based multihomed network proves mutually beneficial.
9. IANA Considerations 9. IANA Considerations
This memo asks the IANA for no new parameters. This memo asks the IANA for no new parameters.
10. Security Considerations 10. Security Considerations
Section 6.2.3 discusses a mechanism for controlling source address Section 6.2.3 discusses a mechanism for controlling source address
selection on hosts using ICMPv6 messages. It describes how an selection on hosts using ICMPv6 messages. Using ICMPv6 to influence
attacker could exploit this mechansim by sending spoofed ICMPv6 source address selection allows an attacker to exhaust the list of
messages. It recommends that a given host verify the original packet 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).
Another possible attack vector is using ICMPv6 Destination
Unreachable Messages with Code 5 to steer the egress tra ffic towards
the particular ISP (for example if the attacker has the ability of
doing traffic sniffing or man-in-the-middle attack in that ISP
network).
To prevent those attacks hosts SHOULD verify that the original packet
header included into ICMPv6 error message was actually sent by the header included into ICMPv6 error message was actually sent by the
host itself. host (to ensure that the ICMPv6 message was triggered by a packet
sent by the host).
As ICMPv6 Destination Unreachable Messages with Code 5 could be
originated by any SADR-capable router within the domain (or even come
from the Internet), GTSM ([RFC5082]) can not be applied. Filtering
such ICMOv6 messages at the site border can not be recommended as it
would break the legitimate end2end error signalling mechanism ICMPv6
is designed for.
The security considerations of using stateless address The security considerations of using stateless address
autoconfiguration are discussed in [RFC4862]. autoconfiguration are discussed in [RFC4862].
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
skipping to change at page 50, line 10 skipping to change at page 50, line 42
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March
2004, <https://www.rfc-editor.org/info/rfc3704>. 2004, <https://www.rfc-editor.org/info/rfc3704>.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007,
<https://www.rfc-editor.org/info/rfc4941>. <https://www.rfc-editor.org/info/rfc4941>.
[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C.
Pignataro, "The Generalized TTL Security Mechanism
(GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007,
<https://www.rfc-editor.org/info/rfc5082>.
[RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming
Shim Protocol for IPv6", RFC 5533, DOI 10.17487/RFC5533, Shim Protocol for IPv6", RFC 5533, DOI 10.17487/RFC5533,
June 2009, <https://www.rfc-editor.org/info/rfc5533>. June 2009, <https://www.rfc-editor.org/info/rfc5533>.
[RFC5534] Arkko, J. and I. van Beijnum, "Failure Detection and [RFC5534] Arkko, J. and I. van Beijnum, "Failure Detection and
Locator Pair Exploration Protocol for IPv6 Multihoming", Locator Pair Exploration Protocol for IPv6 Multihoming",
RFC 5534, DOI 10.17487/RFC5534, June 2009, RFC 5534, DOI 10.17487/RFC5534, June 2009,
<https://www.rfc-editor.org/info/rfc5534>. <https://www.rfc-editor.org/info/rfc5534>.
[RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node
 End of changes. 27 change blocks. 
84 lines changed or deleted 135 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/