draft-ietf-rtgwg-enterprise-pa-multihoming-07.txt   draft-ietf-rtgwg-enterprise-pa-multihoming-08.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: December 13, 2018 Juniper Networks Expires: November 18, 2019 Juniper Networks
J. Linkova J. Linkova
Google Google
June 11, 2018 May 17, 2019
Enterprise Multihoming using Provider-Assigned Addresses without Network Enterprise Multihoming using Provider-Assigned IPv6 Addresses without
Prefix Translation: Requirements and Solution Network Prefix Translation: Requirements and Solution
draft-ietf-rtgwg-enterprise-pa-multihoming-07 draft-ietf-rtgwg-enterprise-pa-multihoming-08
Abstract Abstract
Connecting an enterprise site to multiple ISPs using provider- Connecting an enterprise site to multiple ISPs using provider-
assigned addresses is difficult without the use of some form of assigned addresses is difficult without the use of some form of
Network Address Translation (NAT). Much has been written on this 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 attempts to define a complete solution to this problem. This document attempts to define a complete solution to this problem.
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 host to select account source address, and it covers the behavior of host to select
appropriate source addresses. It also covers any possible role that appropriate source addresses. It also covers any possible role that
routers might play in providing information to hosts to help them routers might play in providing information to hosts to help them
select appropriate source addresses. In the process of exploring select appropriate source addresses. In the process of exploring
potential solutions, this documents also makes explicit requirements potential solutions, this document also makes explicit requirements
for how the solution would be expected to behave from the perspective for how the solution would be expected to behave from the perspective
of an enterprise site network administrator . 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 December 13, 2018. This Internet-Draft will expire on November 18, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. 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
skipping to change at page 2, line 49 skipping to change at page 2, line 49
5.1. Source Address Selection Algorithm on Hosts . . . . . . . 24 5.1. Source Address Selection Algorithm on Hosts . . . . . . . 24
5.2. Selecting Source Address When Both Uplinks Are Working . 27 5.2. Selecting Source Address When Both Uplinks Are Working . 27
5.2.1. Distributing Address Selection Policy Table with 5.2.1. Distributing Address Selection Policy Table with
DHCPv6 . . . . . . . . . . . . . . . . . . . . . . . 27 DHCPv6 . . . . . . . . . . . . . . . . . . . . . . . 27
5.2.2. Controlling Source Address Selection With Router 5.2.2. Controlling Source Address Selection With Router
Advertisements . . . . . . . . . . . . . . . . . . . 27 Advertisements . . . . . . . . . . . . . . . . . . . 27
5.2.3. Controlling Source Address Selection With ICMPv6 . . 29 5.2.3. Controlling Source Address Selection With ICMPv6 . . 29
5.2.4. Summary of Methods For Controlling Source Address 5.2.4. Summary of Methods For Controlling Source Address
Selection To Implement Routing Policy . . . . . . . . 31 Selection To Implement Routing Policy . . . . . . . . 31
5.3. Selecting Source Address When One Uplink Has Failed . . . 32 5.3. Selecting Source Address When One Uplink Has Failed . . . 32
5.3.1. Controlling Source Address Selection With DHCPv6 . . 33 5.3.1. Controlling Source Address Selection With DHCPv6 . . 32
5.3.2. Controlling Source Address Selection With Router 5.3.2. Controlling Source Address Selection With Router
Advertisements . . . . . . . . . . . . . . . . . . . 34 Advertisements . . . . . . . . . . . . . . . . . . . 34
5.3.3. Controlling Source Address Selection With ICMPv6 . . 35 5.3.3. Controlling Source Address Selection With ICMPv6 . . 35
5.3.4. Summary Of Methods For Controlling Source Address 5.3.4. Summary Of Methods For Controlling Source Address
Selection On The Failure Of An Uplink . . . . . . . . 35 Selection On The Failure Of An Uplink . . . . . . . . 35
5.4. Selecting Source Address Upon Failed Uplink Recovery . . 36 5.4. Selecting Source Address Upon Failed Uplink Recovery . . 36
5.4.1. Controlling Source Address Selection With DHCPv6 . . 36 5.4.1. Controlling Source Address Selection With DHCPv6 . . 36
5.4.2. Controlling Source Address Selection With Router 5.4.2. Controlling Source Address Selection With Router
Advertisements . . . . . . . . . . . . . . . . . . . 36 Advertisements . . . . . . . . . . . . . . . . . . . 36
5.4.3. Controlling Source Address Selection With ICMP . . . 37 5.4.3. Controlling Source Address Selection With ICMP . . . 37
5.4.4. Summary Of Methods For Controlling Source Address 5.4.4. Summary Of Methods For Controlling Source Address
Selection Upon Failed Uplink Recovery . . . . . . . . 37 Selection Upon Failed Uplink Recovery . . . . . . . . 37
5.5. Selecting Source Address When All Uplinks Failed . . . . 38 5.5. Selecting Source Address When All Uplinks Failed . . . . 37
5.5.1. Controlling Source Address Selection With DHCPv6 . . 38 5.5.1. Controlling Source Address Selection With DHCPv6 . . 38
5.5.2. Controlling Source Address Selection With Router 5.5.2. Controlling Source Address Selection With Router
Advertisements . . . . . . . . . . . . . . . . . . . 38 Advertisements . . . . . . . . . . . . . . . . . . . 38
5.5.3. Controlling Source Address Selection With ICMPv6 . . 39 5.5.3. Controlling Source Address Selection With ICMPv6 . . 39
5.5.4. Summary Of Methods For Controlling Source Address 5.5.4. Summary Of Methods For Controlling Source Address
Selection When All Uplinks Failed . . . . . . . . . . 39 Selection When All Uplinks Failed . . . . . . . . . . 39
5.6. Summary Of Methods For Controlling Source Address 5.6. Summary Of Methods For Controlling Source Address
Selection . . . . . . . . . . . . . . . . . . . . . . . . 39 Selection . . . . . . . . . . . . . . . . . . . . . . . . 39
5.7. Other Configuration Parameters . . . . . . . . . . . . . 41 5.7. Other Configuration Parameters . . . . . . . . . . . . . 40
5.7.1. DNS Configuration . . . . . . . . . . . . . . . . . . 41 5.7.1. DNS Configuration . . . . . . . . . . . . . . . . . . 40
6. Deployment Considerations . . . . . . . . . . . . . . . . . . 42 6. Deployment Considerations . . . . . . . . . . . . . . . . . . 42
7. Other Solutions . . . . . . . . . . . . . . . . . . . . . . . 43 7. Other Solutions . . . . . . . . . . . . . . . . . . . . . . . 43
7.1. Shim6 . . . . . . . . . . . . . . . . . . . . . . . . . . 43 7.1. Shim6 . . . . . . . . . . . . . . . . . . . . . . . . . . 43
7.2. IPv6-to-IPv6 Network Prefix Translation . . . . . . . . . 43 7.2. IPv6-to-IPv6 Network Prefix Translation . . . . . . . . . 43
7.3. Multipath Transport . . . . . . . . . . . . . . . . . . . 43 7.3. Multipath Transport . . . . . . . . . . . . . . . . . . . 43
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44
9. Security Considerations . . . . . . . . . . . . . . . . . . . 44 9. Security Considerations . . . . . . . . . . . . . . . . . . . 44
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 44 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 44
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 44
11.1. Normative References . . . . . . . . . . . . . . . . . . 44 11.1. Normative References . . . . . . . . . . . . . . . . . . 44
11.2. Informative References . . . . . . . . . . . . . . . . . 46 11.2. Informative References . . . . . . . . . . . . . . . . . 46
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 49 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49
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 5, line 45 skipping to change at page 5, line 45
network are able to take into account the source address of a packet network are able to take into account the source address of a packet
when deciding how to route it. That is, some routers must be capable when deciding how to route it. That is, some routers must be capable
of some form of Source Address Dependent Routing (SADR), if only as of some form of Source Address Dependent Routing (SADR), if only as
described in [RFC3704]. At a minimum, the routers connected to the described in [RFC3704]. At a minimum, the routers connected to the
ISP uplinks (the site exit routers or SERs) must be capable of Source ISP uplinks (the site exit routers or SERs) must be capable of Source
Address Dependent Routing. Expanding the connected domain of routers Address Dependent Routing. Expanding the connected domain of routers
capable of SADR from the site exit routers deeper into the site capable of SADR from the site exit routers deeper into the site
network will generally result in more efficient routing of traffic network will generally result in more efficient routing of traffic
with external destinations. with external destinations.
The document first looks in more detail at the enterprise networking This document is organized as follows. Section 3 looks in more
environments in which this solution is expected to operate. It then detail at the enterprise networking environments in which this
discusses existing and proposed mechanisms for hosts to select the solution is expected to operate. The discussion of Section 3 uses
source address applied to packets. Finally, it looks at the the concepts of source-prefix-scoped routing advertisements and
requirements for routing that are needed to support these enterprise forwarding tables without stopping to provide a precise description
network scenarios and the mechanisms by which hosts are expected to of how source-prefix-scoped routing advertisements are used to
select source addresses dynamically based on network state. generate source-prefix-scoped forwarding tables. Instead, this
detailed description is provided in Section 4. Section 5 discusses
existing and proposed mechanisms for hosts to select the source
address applied to packets. It also discusses the requirements for
routing that are needed to support these enterprise network scenarios
and the mechanisms by which hosts are expected to select source
addresses dynamically based on network state. Section 6 discusses
deployment considerations, while Section 7 discussed other solutions.
2. Requirements Language 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. Enterprise Multihoming Requirements 3. Enterprise Multihoming Requirements
skipping to change at page 7, line 49 skipping to change at page 7, line 49
For the moment, we assume that the hosts are able to make good For the moment, we assume that the hosts are able to make good
choices about which source addresses through some mechanism that choices about which source addresses through some mechanism that
doesn't involve the routers in the site network. Here, we focus on doesn't involve the routers in the site network. Here, we focus on
primary task of the routed site network, which is to get packets primary task of the routed site network, which is to get packets
efficiently to their destinations, while sending a packet to the ISP efficiently to their destinations, while sending a packet to the ISP
that assigned the prefix that matches the source address of the that assigned the prefix that matches the source address of the
packet. In Section 5, we examine what role the routed network may packet. In Section 5, we examine what role the routed network may
play in helping hosts make good choices about source addresses for play in helping hosts make good choices about source addresses for
packets. packets.
With this solution, routers will need form of Source Address With this solution, routers will need some form of Source Address
Dependent Routing, which will be new functionality. It would be Dependent Routing, which will be new functionality. It would be
useful if an enterprise site does not need to upgrade all routers to useful if an enterprise site does not need to upgrade all routers to
support the new SADR functionality in order to support PA multi- support the new SADR functionality in order to support PA multi-
homing. We consider if this is possible and what are the tradeoffs homing. We consider if this is possible and what are the tradeoffs
of not having all routers in the site support SADR functionality. of not having all routers in the site support SADR functionality.
In the topology in Figure 1, it is possible to support PA multihoming In the topology in Figure 1, it is possible to support PA multihoming
with only SERa and SERb being capable of SADR. The other routers can with only SERa and SERb being capable of SADR. The other routers can
continue to forward based only on destination address, and exchange continue to forward based only on destination address, and exchange
routes that only consider destination address. In this scenario, routes that only consider destination address. In this scenario,
skipping to change at page 10, line 11 skipping to change at page 10, line 11
Before considering a more complex scenario, let's look in more detail Before considering a more complex scenario, let's look in more detail
at the reasonably simple multihoming scenario in Figure 2 to at the reasonably simple multihoming scenario in Figure 2 to
understand what can reasonably be expected from this solution. As a understand what can reasonably be expected from this solution. As a
general guiding principle, we assume an enterprise network operator general guiding principle, we assume an enterprise network operator
will expect a multihomed network to behave as close as to a single- will expect a multihomed network to behave as close as to a single-
homed network as possible. So a solution that meets those homed network as possible. So a solution that meets those
expectations where possible is a good thing. expectations where possible is a good thing.
For traffic between internal hosts and traffic from outside the site For traffic between internal hosts and traffic from outside the site
to internal hosts, an enterprise network operator would expect there to internal hosts, an enterprise network operator would expect there
to be no visible change in the path taken by this traffic, since this be no visible change in the path taken by this traffic, since this
traffic does not need to be routed in a way that depends on source traffic does not need to be routed in a way that depends on source
address. It is also reasonable to expect that internal hosts should address. It is also reasonable to expect that internal hosts should
be able to communicate with each other using either of their source be able to communicate with each other using either of their source
addresses without restriction. For example, H31 should be able to addresses without restriction. For example, H31 should be able to
communicate with H41 using a packet with S=2001:db8:0:a010::31, communicate with H41 using a packet with S=2001:db8:0:a010::31,
D=2001:db8:0:b010::41, regardless of the state of uplink to ISP-B. D=2001:db8:0:b010::41, regardless of the state of uplink to ISP-B.
These goals can be accomplished by having all of the routers in the These goals can be accomplished by having all of the routers in the
network continue to originate normal unscoped destination routes for network continue to originate normal unscoped destination routes for
their connected networks. If we can arrange so that these unscoped their connected networks. If we can arrange so that these unscoped
destination routes get used for forwarding this traffic, then we will destination routes get used for forwarding this traffic, then we will
have accomplished the goal of keeping forwarding of traffic destined have accomplished the goal of keeping forwarding of traffic destined
for internal hosts, unaffected by the multihoming solution. for internal hosts, unaffected by the multihoming solution.
For traffic destined for external hosts, it is reasonable to expect For traffic destined for external hosts, it is reasonable to expect
that traffic with an source address from the prefix assigned by ISP-A that traffic with a source address from the prefix assigned by ISP-A
to follow the path to that the traffic would follow if there is no to follow the path to that the traffic would follow if there is no
connection to ISP-B. This can be accomplished by having SERa connection to ISP-B. This can be accomplished by having SERa
originate a source-scoped route of the form (S=2001:db8:0:a000::/52, originate a source-scoped route of the form (S=2001:db8:0:a000::/52,
D=::/0) . If all of the routers in the site support SADR, then the D=::/0) . If all of the routers in the site support SADR, then the
path of traffic exiting via ISP-A can match that expectation. If path of traffic exiting via ISP-A can match that expectation. If
some routers don't support SADR, then it is reasonable to expect that some routers don't support SADR, then it is reasonable to expect that
the path for traffic exiting via ISP-A may be different within the the path for traffic exiting via ISP-A may be different within the
site. This is a tradeoff that the enterprise network operator may site. This is a tradeoff that the enterprise network operator may
decide to make. decide to make.
skipping to change at page 11, line 25 skipping to change at page 11, line 25
This behavior is very different from the behavior that occurs with This behavior is very different from the behavior that occurs with
site multihoming using PI addresses or with PA addresses using NAT. site multihoming using PI addresses or with PA addresses using NAT.
In these other multi-homing solutions, hosts do not need to react to In these other multi-homing solutions, hosts do not need to react to
network failures several hops away in order to regain Internet network failures several hops away in order to regain Internet
access. Instead, a host can be largely unaware of the failure of an access. Instead, a host can be largely unaware of the failure of an
uplink to an ISP. When multihoming with PA addresses and NAT, uplink to an ISP. When multihoming with PA addresses and NAT,
existing sessions generally need to be re-established after a failure existing sessions generally need to be re-established after a failure
since the external host will receive packets from the internal host since the external host will receive packets from the internal host
with a new source address. However, new sessions can be established with a new source address. However, new sessions can be established
without any action on the part of the hosts. without any action on the part of the hosts. Multihoming with PA
addresses and NAT has created the expectation of a fairly quick and
simple recovery from network failures. Alternatives should to be
evaluated in terms of the speed and complexity of the recovery
mechanism.
Another example where the behavior of this multihoming solution Another example where the behavior of this multihoming solution
differs significantly from that of multihoming with PI address or differs significantly from that of multihoming with PI address or
with PA addresses using NAT is in the ability of the enterprise with PA addresses using NAT is in the ability of the enterprise
network operator to route traffic over different ISPs based on network operator to route traffic over different ISPs based on
destination address. We still consider the fairly simple network of destination address. We still consider the fairly simple network of
Figure 2 and assume that uplinks to both ISPs are functioning. Figure 2 and assume that uplinks to both ISPs are functioning.
Assume that the site is multihomed using PA addresses and NAT, and Assume that the site is multihomed using PA addresses and NAT, and
that SERa and SERb each originate a normal destination route for that SERa and SERb each originate a normal destination route for
D=::/0, with the route origination dependent on the state of the D=::/0, with the route origination dependent on the state of the
skipping to change at page 12, line 30 skipping to change at page 12, line 32
3.4. More complex ISP connectivity 3.4. More complex ISP connectivity
The previous sections considered two variations of a simple The previous sections considered two variations of a simple
multihoming scenario where the site is connected to two ISPs offering multihoming scenario where the site is connected to two ISPs offering
only Internet connectivity. It is likely that many actual enterprise only Internet connectivity. It is likely that many actual enterprise
multihoming scenarios will be similar to this simple example. multihoming scenarios will be similar to this simple example.
However, there are more complex multihoming scenarios that we would However, there are more complex multihoming scenarios that we would
like this solution to address as well. like this solution to address as well.
It is fairly common for an ISP to offer a service in addition to It is fairly common for an ISP to offer a service in addition to
Internet access over the same uplink. Two variation of this are Internet access over the same uplink. Two variations of this are
reflected in Figure 3. In addition to Internet access, ISP-A offers reflected in Figure 3. In addition to Internet access, ISP-A offers
a service which requires the site to access host H51 at a service which requires the site to access host H51 at
2001:db8:0:5555::51. The site has a single physical and logical 2001:db8:0:5555::51. The site has a single physical and logical
connection with ISP-A, and ISP-A only allows access to H51 over that connection with ISP-A, and ISP-A only allows access to H51 over that
connection. So when H32 needs to access the service at H51 it needs connection. So when H32 needs to access the service at H51 it needs
to send packets with (S=2001:db8:0:a010::32, D=2001:db8:0:5555::51) to send packets with (S=2001:db8:0:a010::32, D=2001:db8:0:5555::51)
and those packets need to be forward out the link from SERa to ISP-A. and those packets need to be forward out the link from SERa to ISP-A.
2001:db8:0:1234::101 H101 2001:db8:0:1234::101 H101
| |
skipping to change at page 13, line 46 skipping to change at page 13, line 46
2001:db8:0:a020::41 2001:db8:0:a020::41
2001:db8:0:b020::41 2001:db8:0:b020::41
Figure 3: Internet access and services offered by ISP-A and ISP-B Figure 3: Internet access and services offered by ISP-A and ISP-B
ISP-B illustrates a variation on this scenario. In addition to ISP-B illustrates a variation on this scenario. In addition to
Internet access, ISP-B also offers a service which requires the site Internet access, ISP-B also offers a service which requires the site
to access host H61. The site has two connections to two different to access host H61. The site has two connections to two different
parts of ISP-B (shown as SERb1 and SERb2 in Figure 3). ISP-B expects parts of ISP-B (shown as SERb1 and SERb2 in Figure 3). ISP-B expects
Internet traffic to use the uplink from SERb1, while it expects it Internet traffic to use the uplink from SERb1, while it expects
expects traffic destined for the service at H61 to use the uplink traffic destined for the service at H61 to use the uplink from SERb2.
from SERb2. For either uplink, ISP-B expects the ingress traffic to For either uplink, ISP-B expects the ingress traffic to have a source
have a source address matching the prefix it assigned to the site, address matching the prefix it assigned to the site,
2001:db8:0:b000::/52. 2001:db8:0:b000::/52.
As discussed before, we rely completely on the internal host to set As discussed before, we rely completely on the internal host to set
the source address of the packet properly. In the case of a packet the source address of the packet properly. In the case of a packet
sent by H31 to access the service in ISP-B at H61, we expect the sent by H31 to access the service in ISP-B at H61, we expect the
packet to have the following addresses: (S=2001:db8:0:b010::31, packet to have the following addresses: (S=2001:db8:0:b010::31,
D=2001:db8:0:6666::61). The routed network has two potential ways of D=2001:db8:0:6666::61). The routed network has two potential ways of
distributing routes so that this packet exits the site on the uplink distributing routes so that this packet exits the site on the uplink
at SERb2. at SERb2.
skipping to change at page 15, line 6 skipping to change at page 15, line 6
3.5. ISPs and Provider-Assigned Prefixes 3.5. ISPs and Provider-Assigned Prefixes
While we expect that most site multihoming involves connecting to While we expect that most site multihoming involves connecting to
only two ISPs, this solution allows for connections to an arbitrary only two ISPs, this solution allows for connections to an arbitrary
number of ISPs to be supported. However, when evaluating scalable number of ISPs to be supported. However, when evaluating scalable
implementations of the solution, it would be reasonable to assume implementations of the solution, it would be reasonable to assume
that the maximum number of ISPs that a site would connect to is five. that the maximum number of ISPs that a site would connect to is five.
It is also useful to note that the prefixes assigned to the site by It is also useful to note that the prefixes assigned to the site by
different ISPs will not overlap. This must be the case , since the different ISPs will not overlap. This must be the case, since the
provider-assigned addresses have to be globally unique. provider-assigned addresses have to be globally unique.
3.6. Simplified Topologies 3.6. Simplified Topologies
The topologies of many enterprise sites using this multihoming The topologies of many enterprise sites using this multihoming
solution may in practice be simpler than the examples that we have solution may in practice be simpler than the examples that we have
used. The topology in Figure 1 could be further simplified by having used. The topology in Figure 1 could be further simplified by having
all hosts directly connected to the LAN connecting the two site exit all hosts directly connected to the LAN connecting the two site exit
routers, SERa and SERb. The topology could also be simplified by routers, SERa and SERb. The topology could also be simplified by
having the uplinks to ISP-A and ISP-B both connected to the same site having the uplinks to ISP-A and ISP-B both connected to the same site
skipping to change at page 16, line 18 skipping to change at page 16, line 18
source-prefix-scoped forwarding table. As the unscoped source-prefix-scoped forwarding table. As the unscoped
forwarding table is considered to be scoped to ::/0 this process forwarding table is considered to be scoped to ::/0 this process
starts with propagating routes from the unscoped forwarding table starts with propagating routes from the unscoped forwarding table
to source-prefix-scoped forwarding tables and then continues with to source-prefix-scoped forwarding tables and then continues with
propagating routes to more-specific-source-prefix-scoped propagating routes to more-specific-source-prefix-scoped
forwarding tables should they exist. forwarding tables should they exist.
The forward tables produced by this process are used in the following The forward tables produced by this process are used in the following
way to forward packets. way to forward packets.
1. Select the most specific (longerst 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 entries that matches the source address
packet (again, the unscoped forwarding table is considered to be of the packet (again, the unscoped forwarding table is considered
scoped to ::/0). to be 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
forwarding table to determine the next-hop for the packet. forwarding table to determine the next-hop for the packet.
The following example illustrates how this process is used to create The following example illustrates how this process is used to create
a forwarding table for each provider-assigned source prefix. We a forwarding table for each provider-assigned source prefix. We
consider the multihomed site network in Figure 3. Initially we consider the multihomed site network in Figure 3. Initially we
assume that all of the routers in the site network support SADR. assume that all of the routers in the site network support SADR.
Figure 4 shows the routes that are originated by the routers in the Figure 4 shows the routes that are originated by the routers in the
site network. site network.
skipping to change at page 18, line 35 skipping to change at page 18, line 35
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 less specific source-prefix-
scoped forwarding entries with more specific source-prefix-scoped scoped forwarding entries with more specific source-prefix-scoped
forwarding entries. As unscoped forwarding table is considered being forwarding entries. As unscoped forwarding table is considered being
scoped to ::/0 and both 2001:db8:0:a000::/52 and 2001:db8:0:b000::/52 scoped to ::/0 and both 2001:db8:0:a000::/52 and 2001:db8:0:b000::/52
are more specific prefixes of ::/0, the unscoped (scoped to ::/0) are more specific prefixes of ::/0, the unscoped (scoped to ::/0)
forwarding table needs to be augmented with both more specific forwarding table needs to be augmented with both more specific
source-prefix-scoped tables. If an less specific scoped forwarding source-prefix-scoped tables. If a less specific scoped forwarding
entry has the exact same destination prefix as an more specific entry has the exact same destination prefix as a more specific
source-prefix-scoped forwarding entry (including destination prefix source-prefix-scoped forwarding entry (including destination prefix
length), then the more specific source-prefix-scoped forwarding entry length), then the more specific source-prefix-scoped forwarding entry
wins. wins.
As as an example of how the source scoped forwarding entries are As 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 for ::/0 forwarding entries). The first four unscoped or scoped to ::/0 forwarding entries). The first four
unscoped forwarding entries (D=2001:db8:0:a010::/64, 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
2001:db8:0:a000::/52. Therefore, these four entries are added to the 2001:db8:0:a000::/52. Therefore, these four entries are added to the
final forwarding table for source prefix 2001:db8:0:a000::/52. The final forwarding table for source prefix 2001:db8:0:a000::/52. The
result of adding these entries is reflected in first four entries the result of adding these entries is reflected in the first four entries
first table in Figure 6. the first table in Figure 6.
The next less specific scoped (scope is ::/0) forwarding table entry The next less specific scoped (scope is ::/0) forwarding table entry
is for D=2001:db8:0:5555::/64. This entry is an exact match for the is for D=2001:db8:0:5555::/64. This entry is an exact match for the
existing entry in the forwarding table for the more specific source existing entry in the forwarding table for the more specific source
prefix 2001:db8:0:a000::/52. Therefore, we do not replace the prefix 2001:db8:0:a000::/52. Therefore, we do not replace the
existing entry with the entry from the unscoped forwarding table. existing entry with the entry from the unscoped forwarding table.
This is reflected in the fifth entry in the first table in Figure 6. This is reflected in the fifth entry in the first table in Figure 6.
(Note that since both scoped and unscoped entries have R7 as the next (Note that since both scoped and unscoped entries have R7 as the next
hop, the result of applying this rule is not visible.) hop, the result of applying this rule is not visible.)
skipping to change at page 20, line 48 skipping to change at page 20, line 48
The forwarding tables produced by this process at R8 have the desired The forwarding tables produced by this process at R8 have the desired
properties. A packet with a source address in 2001:db8:0:a000::/52 properties. A packet with a source address in 2001:db8:0:a000::/52
will be forwarded based on the first table in Figure 6. If the will be forwarded based on the first table in Figure 6. If the
packet is destined for the Internet at large or the service at packet is destined for the Internet at large or the service at
D=2001:db8:0:5555/64, it will be sent to R7 in the direction of SERa. D=2001:db8:0:5555/64, it will be sent to R7 in the direction of SERa.
If the packet is destined for an internal host, then the first four If the packet is destined for an internal host, then the first four
entries will send it to R2 or R5 as expected. Note that if this entries will send it to R2 or R5 as expected. Note that if this
packet has a destination address corresponding to the service offered packet has a destination address corresponding to the service offered
by ISP-B (D=2001:db8:0:5555::/64), then it will get forwarded to by ISP-B (D=2001:db8:0:5555::/64), then it will get forwarded to
SERb2. It will be dropped by SERb2 or by ISP-B, since it the packet SERb2. It will be dropped by SERb2 or by ISP-B, since the packet has
has a source address that was not assigned by ISP-B. However, this a source address that was not assigned by ISP-B. However, this is
is expected behavior. In order to use the service offered by ISP-B, expected behavior. In order to use the service offered by ISP-B, the
the host needs to originate the packet with a source address assigned host needs to originate the packet with a source address assigned by
by ISP-B. ISP-B.
In this example, a packet with a source address that doesn't match In this example, a packet with a source address that doesn't match
2001:db8:0:a000::/52 or 2001:db8:0:b000::/52 must have originated 2001:db8:0:a000::/52 or 2001:db8:0:b000::/52 must have originated
from an external host. Such a packet will use the unscoped from an external host. Such a packet will use the unscoped
forwarding table (the last table in Figure 6). These packets will forwarding table (the last table in Figure 6). These packets will
flow exactly as they would in absence of multihoming. flow exactly as they would in absence of multihoming.
We can also modify this example to illustrate how it supports We can also modify this example to illustrate how it supports
deployments where not all routers in the site support SADR. deployments where not all routers in the site support SADR.
Continuing with the topology shown in Figure 3, suppose that R3 and Continuing with the topology shown in Figure 3, suppose that R3 and
skipping to change at page 22, line 27 skipping to change at page 22, line 27
Any traffic that needs to exit the site will eventually hit a SADR- Any traffic that needs to exit the site will eventually hit a SADR-
capable router. Once that traffic enters the SADR-capable domain, capable router. Once that traffic enters the SADR-capable domain,
then it will not leave that domain until it exits the site. This then it will not leave that domain until it exits the site. This
property is required in order to guarantee that there will not be property is required in order to guarantee that there will not be
routing loops involving SADR-capable and non-SADR-capable routers. routing loops involving SADR-capable and non-SADR-capable routers.
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 this [I-D.ietf-rtgwg-dst-src-routing]. The method described in the
document is intended to be easy to understand for network enterprise current document is functionally equivalent, but it is intended to be
operators while at the same time being functionally correct. Another easier to understand for enterprise network operators.
difference is that the method in this document assumes that source
prefix will not overlap. Other differences between the two
approaches still need to be understood and reconciled.
An interesting side-effect of deploying SADR is if all routers in a An interesting side-effect of deploying SADR is if all routers in a
given network support SADR and have a scoped forwarding table, then given network support SADR and have a scoped forwarding table, then
the unscoped forwarding table can be eliminated which ensures that the unscoped forwarding table can be eliminated which ensures that
packets with legitimate source addresses only can leave the network packets with legitimate source addresses only can leave the network
(as there are no scoped forwarding tables for spoofed/bogon source (as there are no scoped forwarding tables for spoofed/bogon source
addresses). It would prevent accidental leaks of ULA/reserved/link- addresses). It would prevent accidental leaks of ULA/reserved/link-
local sources to the Internet as well as ensures that no spoofing is local sources to the Internet as well as ensures that no spoofing is
possible from the SADR-enabled network. possible from the SADR-enabled network.
skipping to change at page 23, line 36 skipping to change at page 23, line 34
implementation of those solutions. We also look at proposed implementation of those solutions. We also look at proposed
solutions for this problem. solutions for this problem.
An external host initiating communication with a host internal to a An external host initiating communication with a host internal to a
PA multihomed site will need to know multiple addresses for that host PA multihomed site will need to know multiple addresses for that host
in order to communicate with it using different ISPs to the in order to communicate with it using different ISPs to the
multihomed site. These addresses are typically learned through DNS. multihomed site. These addresses are typically learned through DNS.
(For simplicity, we assume that the external host is single-homed.) (For simplicity, we assume that the external host is single-homed.)
The external host chooses the ISP that will be used at the remote The external host chooses the ISP that will be used at the remote
multihomed site by setting the destination address on the packets it multihomed site by setting the destination address on the packets it
transmits. For a sessions originated from an external host to an transmits. For a session originated from an external host to an
internal host, the choice of source address used by the internal host internal host, the choice of source address used by the internal host
is simple. The internal host has no choice but to use the is simple. The internal host has no choice but to use the
destination address in the received packet as the source address of destination address in the received packet as the source address of
the transmitted packet. the transmitted packet.
For a session originated by a host internal to the multi-homed site, For a session originated by a host internal to the multi-homed site,
the decision of what source address to select is more complicated. the decision of what source address to select is more complicated.
We consider three main methods for hosts to get information about the We 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
skipping to change at page 24, line 21 skipping to change at page 24, line 18
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
how a host should choose addresses in an arbitrary environment, most how a host should choose addresses in an arbitrary environment, most
of the rules are not relevant for understanding how a host should of the rules are not relevant for understanding how a host should
choose among multiple source addresses in mulitihomed envinronment choose among multiple source addresses in multihomed environment when
when sending a packet to a remote host. Returning to the example in sending a packet to a remote host. Returning to the example in
Figure 3, we look at what the default algorithms in [RFC6724] say Figure 3, we look at what the default algorithms in [RFC6724] say
about the source address that internal host H31 should use to send about the source address that internal host H31 should use to send
traffic to external host H101, somewhere on the Internet. Let's look traffic to external host H101, somewhere on the Internet.
at what rules in [RFC6724] are actually used by H31 in this case.
There is no choice to be made with respect to destination address. There is no choice to be made with respect to destination address.
H31 needs to send a packet with D=2001:db8:0:1234::101 in order to H31 needs to send a packet with D=2001:db8:0:1234::101 in order to
reach H101. So H31 have to choose between using reach H101. So H31 have to choose between using
S=2001:db8:0:a010::31 or S=2001:db8:0:b010::31 as the source address S=2001:db8:0:a010::31 or S=2001:db8:0:b010::31 as the source address
for this packet. We go through the rules for source address for this packet. We go through the rules for source address
selection in Section 5 of [RFC6724]. Rule 1 (Prefer same address) is selection in Section 5 of [RFC6724]. Rule 1 (Prefer same address) is
not useful to break the tie between source addresses, because neither not useful to break the tie between source addresses, because neither
the candidate source addresses equals the destination address. Rule the candidate source addresses equals the destination address. Rule
2 (Prefer appropriate scope) is also not used in this scenario, 2 (Prefer appropriate scope) is also not used in this scenario,
skipping to change at page 25, line 4 skipping to change at page 24, line 49
by a host has a preferred lifetime and a valid lifetime. The address by a host has a preferred lifetime and a valid lifetime. The address
is preferred until the preferred lifetime expires, after which it is preferred until the preferred lifetime expires, after which it
becomes deprecated. A deprecated address is not used if there is a becomes deprecated. A deprecated address is not used if there is a
preferred address of the appropriate scope available. When the valid preferred address of the appropriate scope available. When the valid
lifetime expires, the address cannot be used at all. The preferred lifetime expires, the address cannot be used at all. The preferred
and valid lifetimes for an autoconfigured address are set based on and valid lifetimes for an autoconfigured address are set based on
the corresponding lifetimes in the Prefix Information Option in the corresponding lifetimes in the Prefix Information Option in
Neighbor Discovery Router Advertisements. So a possible tool to Neighbor Discovery Router Advertisements. So a possible tool to
control source address selection in this scenario would be for a host control source address selection in this scenario would be for a host
to make an address deprecated by having routers on that link, R1 and to make an address deprecated by having routers on that link, R1 and
R2 in Figure 3, send a Router Advertisement message contaning a R2 in Figure 3, send a Router Advertisement message containing a
Prefix Information Option for the source prefix to be discouraged (or Prefix Information Option for the source prefix to be discouraged (or
prohibited) with the preferred lifetime set to zero. This is a prohibited) with the preferred lifetime set to zero. This is a
rather blunt tool, because it discourages or prohibits the use of rather blunt tool, because it discourages or prohibits the use of
that source prefix for all destinations. However, it may be useful that source prefix for all destinations. However, it may be useful
in some scenarios. For example, if all uplinks to a particular ISP in some scenarios. For example, if all uplinks to a particular ISP
fail, it is desirable to prevent hosts from using source addresses fail, it is desirable to prevent hosts from using source addresses
from that ISP address space. from that ISP address space.
Rule 4 (Avoid home addresses) does not apply here because we are not Rule 4 (Avoid home addresses) does not apply here because we are not
considering Mobile IP. considering Mobile IP.
skipping to change at page 26, line 25 skipping to change at page 26, line 20
this rule would result in using 2001:db8:0:a101::31 as a source this rule would result in using 2001:db8:0:a101::31 as a source
(2001:db8:0:a101::31 and 2001:db8:0:a020::41 share the common prefix (2001:db8:0:a101::31 and 2001:db8:0:a020::41 share the common prefix
2001:db8:0:a000::/58, while for `2001:db8:0:b101::31 and 2001:db8:0:a000::/58, while for `2001:db8:0:b101::31 and
2001:db8:0:a020::41 the common prefix is 2001:db8:0:a000::/51). 2001:db8:0:a020::41 the common prefix is 2001:db8:0:a000::/51).
Therefore rule 8 might be useful for selecting the correct source Therefore rule 8 might be useful for selecting the correct source
address in some but not all scenarios (for example if ISP-B services address in some but not all scenarios (for example if ISP-B services
belong to 2001:db8:0:b000::/59 then H31 would always use belong to 2001:db8:0:b000::/59 then H31 would always use
2001:db8:0:b010::31 to access those destinations). 2001:db8:0:b010::31 to access those destinations).
So we can see that of the 8 source selection address rules from So we can see that of the 8 source selection address rules from
[RFC6724], five actually apply to our basic site multihoming [RFC6724], four actually apply to our basic site multihoming
scenario. The rules that are relevant to this scenario are scenario. The rules that are relevant to this scenario are
summarized below. summarized below.
o Rule 3: Avoid deprecated addresses. o Rule 3: Avoid deprecated addresses.
o Rule 5.5: Prefer addresses in a prefix advertised by the next-hop. o Rule 5.5: Prefer addresses in a prefix advertised by the next-hop.
o Rule 6: Prefer matching label. o Rule 6: Prefer matching label.
o Rule 8: Prefer longest matching prefix. o Rule 8: Prefer longest matching prefix.
skipping to change at page 27, line 34 skipping to change at page 27, line 32
2001:db8:0:a000::/52 50 33 2001:db8:0:a000::/52 50 33
Figure 9: Policy table entries to implement a routing policy Figure 9: Policy table entries to implement a routing policy
This requires that the hosts implement [RFC6724], the basic source This requires that the hosts implement [RFC6724], the basic source
and destination address framework, along with [RFC7078], the DHCPv6 and destination address framework, along with [RFC7078], the DHCPv6
extension for distributing a non-default policy table. Note that it extension for distributing a non-default policy table. Note that it
does NOT require that the hosts use DHCPv6 for address assignment. does NOT require that the hosts use DHCPv6 for address assignment.
The hosts could still use stateless address autoconfiguration for The hosts could still use stateless address autoconfiguration for
address configuration, while using DHCPv6 only for policy table address configuration, while using DHCPv6 only for policy table
distribution (see [RFC3736]). However this method has a number of distribution (see [RFC8415]). However this method has a number of
disadvantages: disadvantages:
o DHCPv6 support is not a mandatory requirement for IPv6 hosts, so o DHCPv6 support is not a mandatory requirement for IPv6 hosts, so
this method might not work for all devices. 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 scenarion of a single multihomed network, such be feasible in the scenario of a single multihomed network, such
approach might have some scalability issues, especially if the 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.
5.2.2. Controlling Source Address Selection With Router Advertisements 5.2.2. Controlling Source Address Selection With Router Advertisements
Neighbor Discovery currently has two mechanisms to communicate prefix 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
skipping to change at page 28, line 35 skipping to change at page 28, line 32
prefixes. However, there is currently no standardized way to prefixes. However, there is currently no standardized way to
directly associate a particular destination prefix with a particular directly associate a particular destination prefix with a particular
source prefix. source prefix.
[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 a R1 and R2 to explicitly communicate to H31 an extension that allows R1 and R2 to explicitly communicate to H31 an
association between S=2001:db8:0:a000::/52 D=2001:db8:0:1234::/64 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 source address selection algorithm
(discussed in Section 5.1 above), together with default router (discussed in Section 5.1 above), together with default router
preference (specified in [RFC4191]) and RIO can be used to influence 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
facing H41 (one for each scoped forwarding table, LLA_A and LLA_B) facing H41 (one for each scoped forwarding table, LLA_A and LLA_B)
and starts sending two different RAs: one is sent from LLA_A and and starts sending two different RAs: one is sent from LLA_A and
includes PIO for 2001:db8:0:a020::/64, another us sent from LLA_B and includes PIO for 2001:db8:0:a020::/64, another is sent from LLA_B and
includes PIO for 2001:db8:0:b020::/64. Now it is possible to includes PIO for 2001:db8:0:b020::/64. Now it is possible to
influence H41 source address selection for destinations which follow influence H41 source address selection for destinations which follow
the default route by setting default router preference in RAs. If it the default route by setting default router preference in RAs. If it
is desired that H41 reaches H101 (or any destinations in the is desired that H41 reaches H101 (or any destinations in the
Internet) via ISP-A, then RAs sent from LLA_A should have default Internet) via ISP-A, then RAs sent from LLA_A should have default
router preference set to 01 (high priority), while RAs sent from router preference set to 01 (high priority), while RAs sent from
LLA_B should have preference set to 11 (low). Then LLA_A would be LLA_B should have preference set to 11 (low). Then LLA_A would be
chosen as a next-hop for H101 and therefore (as per rule 5.5) chosen as a next-hop for H101 and therefore (as per rule 5.5)
2001:db8:0:a020::41 would be selected as the source address. If, at 2001:db8:0:a020::41 would be selected as the source address. If, at
the same time, it is desired that H61 is accessible via ISP-B then R3 the same time, it is desired that H61 is accessible via ISP-B then R3
skipping to change at page 29, line 40 skipping to change at page 29, line 37
still provide a less flexible version of this mechanism even without still provide a less flexible version of this mechanism even without
implementing SADR. This could be done by providing configuration implementing SADR. This could be done by providing configuration
knobs on the first-hop router that allow it to generate different knobs on the first-hop router that allow it to generate different
link-local addresses and to send individual RAs for each prefix. link-local addresses and to send individual RAs for each prefix.
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]
recommends that a host SHOULD select default routers for each prefix recommends that a host SHOULD select default routers for each prefix
in which it is assigned an address. It also recommends that hosts in which it is assigned an address. It also recommends that hosts
SHOULD implement Rule 5.5. of [RFC6724]. Hosts following the SHOULD 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.
5.2.3. Controlling Source Address Selection With ICMPv6 5.2.3. Controlling Source Address Selection With ICMPv6
We now discuss how one might use ICMPv6 to implement the routing 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
skipping to change at page 31, line 18 skipping to change at page 31, line 15
traffic blackholing and poor user experience. To improve the traffic blackholing and poor user experience. To improve the
scalability of ICMPv6-based signalling hosts SHOULD cache the scalability of ICMPv6-based signalling 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 5.3). In addition, the same source prefix failure - see Section 5.3). In addition, the same source prefix
SHOULD be used for other destinations in the same /64 as the original SHOULD be used for other destinations in the same /64 as the original
destination address. The source prefix SHOULD have a specific destination address. The source prefix SHOULD have a specific
lifetime. Expiration of the lifetime SHOULD trigger the source lifetime. Expiration of the lifetime SHOULD trigger the source
address selection algorithm again. address selection algorithm again.
Using ICMPv6 Code 5 message for influencing source address selection Using ICMPv6 Destination Unreachable Messages with Code 5 to
allows an attacker to exhaust the list of candidate source addresses influence source address selection allows an attacker to exhaust the
on the host by sending spoofed ICMPv6 Code 5 for all prefixes known list of candidate source addresses on the host by sending spoofed
on the network (therefore preventing a victim from establishing a ICMPv6 Code 5 for all prefixes known on the network (therefore
communication with the destination host). To protect from such preventing a victim from establishing a communication with the
attack hosts SHOULD verify that the original packet header included destination host). To protect from an attack of this kind, hosts
into ICMPv6 error message was actually sent by the host. 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. However, we note that this might be a useful such a mechanism. However, we note that this might be a useful
extension to define in a different document. extension to define in a different document.
skipping to change at page 33, line 16 skipping to change at page 33, line 9
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
Reconfigure Message to H31 as described in Section 19 of [RFC3315]. Reconfigure Message to H31 as described in Section 18.3 of [RFC8415].
Or the DHCP server can assign addresses with short lifetimes in order Or the DHCP server can assign addresses with short lifetimes in order
to force clients to renew them often. to force clients to renew them often.
This approach would prevent H31 from using S=2001:db8:0:b010::31 to This approach would prevent H31 from using S=2001:db8:0:b010::31 to
reach the a host on the Internet. However, it would also prevent H31 reach the a host on the Internet. However, it would also prevent H31
from using S=2001:db8:0:b010::31 to reach H61 at from using S=2001:db8:0:b010::31 to reach H61 at
D=2001:db8:0:6666::61, which is not desirable. D=2001:db8:0:6666::61, which is not desirable.
Another potential approach is to have the DHCP server monitor the Another potential approach is to have the DHCP server monitor the
uplink from SERb1 to ISP-B and control the choice of source address uplink from SERb1 to ISP-B and control the choice of source address
on H31 by updating its address selection policy table via the on H31 by updating its address selection policy table via the
mechanism in [RFC7078]. The DHCP server could initiate this process mechanism in [RFC7078]. The DHCP server could initiate this process
by sending a Reconfigure Message to H31. Note that [RFC3315] by sending a Reconfigure Message to H31. Note that [RFC8415]
requires that Reconfigure Message use DHCP authentication. DHCP requires that Reconfigure Message use DHCP authentication. DHCP
authentication could be avoided by using short address lifetimes to authentication could be avoided by using short address lifetimes to
force clients to send Renew messages to the server often. If the force clients to send Renew messages to the server often. If the
host is not obtaining its IP addresses from the DHCP server, then it host is not obtaining its IP addresses from the DHCP server, then it
would need to use the Information Refresh Time option defined in would need to use the Information Refresh Time option defined in
[RFC4242]. [RFC8415].
If the following policy table can be installed on H31 after the If the following policy table can be installed on H31 after the
failure of the uplink from SERb1, then the desired routing behavior failure of the uplink from SERb1, then the desired routing behavior
should be achieved based on source and destination prefix being should be achieved based on source and destination prefix being
matched with label values. matched with label values.
Prefix Precedence Label Prefix Precedence Label
::/0 50 44 ::/0 50 44
2001:db8:0:a000::/52 50 44 2001:db8:0:a000::/52 50 44
2001:db8:0:6666::/64 50 55 2001:db8:0:6666::/64 50 55
skipping to change at page 38, line 32 skipping to change at page 38, line 27
As discussed in Section 5.3.2 an uplink failure causes the scoped As discussed in Section 5.3.2 an uplink failure causes the scoped
default entry to disappear from the scoped forwarding table and 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
case hosts might fall back to IPv4 if there is IPv4 connectivity to case hosts might fall back to IPv4 if there is IPv4 connectivity to
destinations). As a results intra-site connectivity is broken. One destinations). As a result, intra-site connectivity is broken. One
of the possible way to solve it is to use ULAs. of the possible way to solve it is to use ULAs.
All hosts have ULA addresses assigned in addition to GUAs and used All hosts have ULA addresses assigned in addition to GUAs and used
for intra-site communication even if there is no GUA assigned to a for intra-site communication even if there is no GUA assigned to a
host. To avoid accidental leaking of packets with ULA sources SADR- host. To avoid accidental leaking of packets with ULA sources SADR-
capable routers SHOULD have a scoped forwarding table for ULA source capable routers SHOULD have a scoped forwarding table for ULA source
for internal routes but MUST NOT have an entry for D=::/0 in that for internal routes but MUST NOT have an entry for D=::/0 in that
table. In the absence of (S=ULA_Prefix; D=::/0) first-hop routers 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
skipping to change at page 39, line 9 skipping to change at page 39, line 5
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 uplinks failure hosts would lost all their GUAs upon absence of ULAs uplinks failure hosts would lost all their GUAs upon
prefix lifetime expiration which again makes intra-site communication prefix lifetime expiration which again makes intra-site communication
impossible. 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 adminstrator 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 roter which advertises Internet connectivity, hosts do not select a router which advertises
ULA prefixes as their default router. ULA prefixes as their default router.
5.5.3. Controlling Source Address Selection With ICMPv6 5.5.3. Controlling Source Address Selection With ICMPv6
In case of all uplinks failure all SERs will drop outgoing IPv6 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 5.3.3 discussed in Section 5.3.3
skipping to change at page 40, line 32 skipping to change at page 40, line 28
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 and be able to send dedicated RAs per scoped
forwarding table as discussed above, reacting to network changes with forwarding table as discussed above, reacting to network changes with
sending new RAs. It should be noted that the proposed solution would sending new RAs. It should be noted that the proposed solution would
work even if first-hop routers are not SADR-capable but still able to work even if first-hop routers are not SADR-capable but still able to
send individual RAs for each ISP prefix and react to topology changes send individual RAs for each ISP prefix and react to topology changes
as discussed above (e.g. via configuration knobs). 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 algorith as defined in [RFC6724]. While default address selection algorithm as defined in [RFC6724]. While
the basic (and most common) multihoming scenario (two or more the basic (and most common) multihoming scenario (two or more
Internet uplinks, no 'wall gardens') would work for any host Internet uplinks, no 'wall 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 "wall garden" and other scenarios when some ISP cases (such as "wall 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
rule implemented currently. However it should be noted that rule implemented currently. However it should be noted that
[RFC8028] states that Rule 5.5 SHOULD be implemented. [RFC8028] states that Rule 5.5 SHOULD be implemented.
skipping to change at page 41, line 10 skipping to change at page 40, line 51
but it SHOULD NOT be considered as the stand-alone solution. To but it SHOULD NOT be considered as the stand-alone solution. To
prevent scenarios when hosts in multihomed envinronments incorrectly prevent scenarios when hosts in multihomed envinronments incorrectly
identify onlink/offlink destinations, hosts should treat ICMPv6 identify onlink/offlink destinations, hosts should treat ICMPv6
Redirects as discussed in [RFC8028]. Redirects as discussed in [RFC8028].
5.7. Other Configuration Parameters 5.7. Other Configuration Parameters
5.7.1. DNS Configuration 5.7.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. E.g. in the topology show on Figure 3, ISP-A might DNS servers. For example, in the topology shown in Figure 3, ISP-A
provide recursive DNS server H51 2001:db8:0:5555::51, while ISP-B might provide recursive DNS server H51 2001:db8:0:5555::51, while
might provide H61 2001:db8:0:6666::61 as a recursive DNS server. ISP-B might provide H61 2001:db8:0:6666::61 as a recursive DNS
[RFC8106] defines IPv6 Router Advertisement options to allow IPv6 server. [RFC8106] defines IPv6 Router Advertisement options to allow
routers to advertise a list of DNS recursive server addresses and a IPv6 routers to advertise a list of DNS recursive server addresses
DNS Search List to IPv6 hosts. Using RDNSS together with 'scoped' and a DNS Search List to IPv6 hosts. Using RDNSS together with
RAs as described above would allow a first-hop router (R3 in the 'scoped' RAs as described above would allow a first-hop router (R3 in
Figure 3) to send DNS server addresses and search lists provided by the Figure 3) to send DNS server addresses and search lists provided
each ISP (or the corporate DNS servers addresses if the enterprise is by each ISP (or the corporate DNS servers addresses if the enterprise
running its own DNS servers). is running its own DNS servers).
As discussed in Section 5.5.2, failure of all ISP uplinks would cause As discussed in Section 5.5.2, failure of all ISP uplinks would cause
deprecaction of all addresses assigned to a host from the address deprecation of all addresses assigned to a host from the address
space if all ISPs. If any intra-site IPv6 connectivity is still space of all ISPs. If any intra-site IPv6 connectivity is still
desirable (most likely to be the case for any mid/large scare desirable (most likely to be the case for any mid/large scare
network), then ULAs should be used as discussed in Section 5.5.2. In network), then ULAs should be used as discussed in Section 5.5.2. In
such a scenario, the enterprise network should run its own recursive such a scenario, the enterprise network should run its own recursive
DNS server(s) and provide its ULA addresses to hosts via RDNSS in RAs DNS server(s) and provide its ULA addresses to hosts via RDNSS in RAs
send for ULA-scoped forwarding table as described in Section 5.5.2. send for ULA-scoped forwarding table as described in Section 5.5.2.
There are some scenarios when the final outcome of the name There are some scenarios when the final outcome of the name
resolution might be different depending on: resolution might be different depending on:
o which DNS server is used; o which DNS server is used;
o which source address the client uses to send a DNS query to the o which source address the client uses to send a DNS query to the
server (DNS split horizon). server (DNS split horizon).
There is no way currently to instruct a host to use a particular DNS There is no way currently to instruct a host to use a particular DNS
server out of the configured servers list for resolving a particular server out of the configured servers list for resolving a particular
name. Therefore it does not seem feasible to solve the problem of name. Therefore it does not seem feasible to solve the problem of
DNS server selection on the host (it should be noted that this DNS server selection on the host (it should be noted that this
particular issue is protocol-agnostic and happens for IPv4 as well). particular issue is protocol-agnostic and happens for IPv4 as well).
In such a scenario it is recommended that the enterprise run its own In such a scenario it is recommended that the enterprise runs its own
local recursive DNS server. local recursive DNS server.
To influence host source address selection for packets sent to a To influence host source address selection for packets sent to a
particular DNS server the following requirements must be met: particular DNS server the following requirements must be met:
o the host supports RIO as defined in [RFC4191]; o the host supports RIO as defined in [RFC4191];
o the routers send RIO for routes to DNS server addresses. o the routers send RIO for routes to DNS server addresses.
For example, if it is desirable that host H31 reaches the ISP-A DNS For example, if it is desirable that host H31 reaches the ISP-A DNS
skipping to change at page 42, line 30 skipping to change at page 42, line 22
might ignore RDNSS information provided in ULA-scoped RAs as those might ignore RDNSS information provided in ULA-scoped RAs as those
RAs would have router lifetime set to 0. However the updated version RAs would have router lifetime set to 0. However the updated version
of RFC6106 ([RFC8106]) has that requirement removed. of RFC6106 ([RFC8106]) has that requirement removed.
6. Deployment Considerations 6. Deployment Considerations
The solution described in this document requires certain mechanisms The solution described in this document requires certain mechanisms
to be supported by the network infrastructure and hosts. It requires to be supported by the network infrastructure and hosts. It requires
some routers in the enterprise site to support some form of Source some routers in the enterprise site to support some form of Source
Address Dependent Routing (SADR). It also requires hosts to be able Address Dependent Routing (SADR). It also requires hosts to be able
to learn when the uplink to an ISP chages its state so the to learn when the uplink to an ISP changes its state so the
corresponding source addresses should (or should not) be used. corresponding source addresses should (or should not) be used.
Ongoing work to create mechanisms to accomplish this are discussed in Ongoing work to create mechanisms to accomplish this are discussed in
this document, but they are still a work in progress. this document, but they are still a work in progress.
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] consideres selection algorithm ([RFC6724]) Rule 5.5. While [RFC6724] considers
this rule as optional, the recent [RFC8028] recommends that a host this rule as optional, the recent [RFC8028] recommends that a host
SHOULD select default routers for each prefix in which it is assigned SHOULD select default routers for each prefix in which it is assigned
an address. It also recommends that hosts SHOULD implement Rule 5.5. an address. It also recommends that hosts SHOULD implement Rule 5.5.
of [RFC6724]. Therefore while RFC8028-compliant hosts already have of [RFC6724]. Therefore while RFC8028-compliant hosts already have
mechanism to learn about ISP uplinks state changes and selecting the mechanism to learn about ISP uplinks state changes and selecting the
source addresses accordingly, many hosts do not have such mechanism source addresses accordingly, many hosts do not have such mechanism
supported yet. supported yet.
It should be noted that multihomed enterprise network utilizing It should be noted that multihomed enterprise network utilizing
multipe ISP prefixes can be considered as a typical mutiple multiple ISP prefixes can be considered as a typical mutiple
provisioning domain (mPVD) scenario, as desribed in [RFC7556]. This provisioning domain (mPVD) scenario, as described in [RFC7556]. This
document defines a way for network to provide the PVD information to document defines a way for network to provide the PVD information to
hosts indirectly, using the existing mechanisms. At the same time hosts indirectly, using the existing mechanisms. At the same time
[I-D.ietf-intarea-provisioning-domains]takes one step further and [I-D.ietf-intarea-provisioning-domains]takes one step further and
describes a comprehensive mechanism for hosts to discover the whole describes a comprehensive mechanism for hosts to discover the whole
set of configuration information associated with different PVD/ISPs. set of configuration information associated with different PVD/ISPs.
[I-D.ietf-intarea-provisioning-domains] complements this document in [I-D.ietf-intarea-provisioning-domains] complements this document in
terms of making hosts being able to learn about ISP uplink states and terms of making hosts being able to learn about ISP uplink states and
selecting the corresponding source addresses. selecting the corresponding source addresses.
7. Other Solutions 7. Other Solutions
7.1. Shim6 7.1. Shim6
The Shim6 working group specified the Shim6 protocol [RFC5533] which The Shim6 working group specified the Shim6 protocol [RFC5533] which
allows a host at a multihomed site to communicate with an external allows a host at a multihomed site to communicate with an external
skipping to change at page 43, line 38 skipping to change at page 43, line 34
IPv6-to-IPv6 Network Prefix Translation (NPTv6) [RFC6296] is not the IPv6-to-IPv6 Network Prefix Translation (NPTv6) [RFC6296] is not the
focus of this document. NPTv6 suffers from the same fundamental focus of this document. NPTv6 suffers from the same fundamental
issue as any other address translation approaches: it breaks end-to- issue as any other address translation approaches: it breaks end-to-
end connectivity. Therefore NPTv6 is not considered as desirable end connectivity. Therefore NPTv6 is not considered as desirable
solution and this document intentionally focuses on solving solution and this document intentionally focuses on solving
enterprise multihoming problem without any form of address enterprise multihoming problem without any form of address
translations. translations.
With increasing interest and ongoing work in bringing path awareness With increasing interest and ongoing work in bringing path awareness
to transport and application layer protocols hosts migth be able to to transport and application layer protocols hosts might be able to
determine the properties of the various network paths and choose determine the properties of the various network paths and choose
among paths available to them. As selecting the correct source among paths available to them. As selecting the correct source
address is one of the possible mechanisms path-aware hosts may address is one of the possible mechanisms path-aware hosts may
utilize, address translation negatively affects hosts path-awareness utilize, address translation negatively affects hosts path-awareness
which makes NTPv6 even more undesirable solution. which makes NTPv6 even more undesirable solution.
7.3. Multipath Transport 7.3. Multipath Transport
Using multipath transport might solve the problems discussed in Using multipath transport might solve the problems discussed in
Section 5 it would allow hosts to use multiple source addresses for a Section 5 since it would allow hosts to use multiple source addresses
single connection and switch between source addresses when a for a single connection and switch between source addresses when a
particular address becomes unavailable or a new address gets assigned particular address becomes unavailable or a new address gets assigned
to the host interface. Therefore if all hosts in the enterprise to the host interface. Therefore if all hosts in the enterprise
network are only using multipath transport for all connections, the network are only using multipath transport for all connections, the
signalling solution described in Section 5 migth not be needed (it signalling solution described in Section 5 might not be needed (it
should be noted that the Source Address Dependent Routing would still should be noted that the Source Address Dependent Routing would still
be required to delver packets to the correct uplinks). Unfortunatelt be required to deliver packets to the correct uplinks). At the time
when this document was written, mutlipath transport alone can not be this document was written, multipath transport alone could not be
considered a solition for the problem of selecting the source address considered a solution for the problem of selecting the source address
in a multihomed envinronments. There are significant number of hosts in a multihomed environment. There are significant number of hosts
which do not use mulipath transport currently and it seems unlikely which do not use multipath transport currently and it seems unlikely
that the situation is going to change in any foreseeable future. As that the situation is going to change in any foreseeable future. The
the solution for enterprise multihoming needs to work for the least solution for enterprise multihoming needs to work for the least
common denominator: hosts without multipath transport support. In common denominator: hosts without multipath transport support. In
addition, not all protocols are using multipath transport. While addition, not all protocols are using multipath transport. While
multipath transport would complement the solution described in multipath transport would complement the solution described in
Section 5, it could not be considered as a sole solution to the Section 5, it could not be considered as a sole solution to the
problem of source address selection in multihomed envinronments. problem of source address selection in multihomed environments.
8. IANA Considerations 8. IANA Considerations
This memo asks the IANA for no new parameters. This memo asks the IANA for no new parameters.
9. Security Considerations 9. Security Considerations
This document introduces no new security or privacy considerations. Section 5.2.3 discusses a mechanism for controlling source address
Security considerations of using stateless address autoconfiguration selection on hosts using ICMPv6 messages. It describes how an
is discussed in [RFC4862]. attacker could exploit this mechansim by sending spoofed ICMPv6
messages. It recommends that a given host verify the original packet
header included into ICMPv6 error message was actually sent by the
host itself.
The security considerations of using stateless address
autoconfiguration are discussed in [RFC4862].
10. Acknowledgements 10. 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, Brian E order) for their review and feedback: Olivier Bonaventure, Brian E
Carpenter, Lorenzo Colitti, David Lamparter, Acee Lindem, Philip Carpenter, Lorenzo Colitti, David Lamparter, Nicolai Leymann, Acee
Matthewsu, Robert Raszuk, Dave Thaler. Lindem, Philip Matthewsu, Robert Raszuk, Dave Thaler, Martin
Vigoureux.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122,
DOI 10.17487/RFC1122, October 1989,
<https://www.rfc-editor.org/info/rfc1122>.
[RFC1123] Braden, R., Ed., "Requirements for Internet Hosts -
Application and Support", STD 3, RFC 1123,
DOI 10.17487/RFC1123, October 1989,
<https://www.rfc-editor.org/info/rfc1123>.
[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>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
May 2000, <https://www.rfc-editor.org/info/rfc2827>. May 2000, <https://www.rfc-editor.org/info/rfc2827>.
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
C., and M. Carney, "Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
2003, <https://www.rfc-editor.org/info/rfc3315>.
[RFC3582] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site-
Multihoming Architectures", RFC 3582,
DOI 10.17487/RFC3582, August 2003,
<https://www.rfc-editor.org/info/rfc3582>.
[RFC4116] Abley, J., Lindqvist, K., Davies, E., Black, B., and V.
Gill, "IPv4 Multihoming Practices and Limitations",
RFC 4116, DOI 10.17487/RFC4116, July 2005,
<https://www.rfc-editor.org/info/rfc4116>.
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191,
November 2005, <https://www.rfc-editor.org/info/rfc4191>. November 2005, <https://www.rfc-editor.org/info/rfc4191>.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
<https://www.rfc-editor.org/info/rfc4193>. <https://www.rfc-editor.org/info/rfc4193>.
[RFC4218] Nordmark, E. and T. Li, "Threats Relating to IPv6
Multihoming Solutions", RFC 4218, DOI 10.17487/RFC4218,
October 2005, <https://www.rfc-editor.org/info/rfc4218>.
[RFC4219] Lear, E., "Things Multihoming in IPv6 (MULTI6) Developers
Should Think About", RFC 4219, DOI 10.17487/RFC4219,
October 2005, <https://www.rfc-editor.org/info/rfc4219>.
[RFC4242] Venaas, S., Chown, T., and B. Volz, "Information Refresh
Time Option for Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 4242, DOI 10.17487/RFC4242, November
2005, <https://www.rfc-editor.org/info/rfc4242>.
[RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix
Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011, Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011,
<https://www.rfc-editor.org/info/rfc6296>. <https://www.rfc-editor.org/info/rfc6296>.
[RFC7157] Troan, O., Ed., Miles, D., Matsushima, S., Okimoto, T.,
and D. Wing, "IPv6 Multihoming without Network Address
Translation", RFC 7157, DOI 10.17487/RFC7157, March 2014,
<https://www.rfc-editor.org/info/rfc7157>.
[RFC7556] Anipko, D., Ed., "Multiple Provisioning Domain [RFC7556] Anipko, D., Ed., "Multiple Provisioning Domain
Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015, Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015,
<https://www.rfc-editor.org/info/rfc7556>. <https://www.rfc-editor.org/info/rfc7556>.
[RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by [RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by
Hosts in a Multi-Prefix Network", RFC 8028, Hosts in a Multi-Prefix Network", RFC 8028,
DOI 10.17487/RFC8028, November 2016, DOI 10.17487/RFC8028, November 2016,
<https://www.rfc-editor.org/info/rfc8028>. <https://www.rfc-editor.org/info/rfc8028>.
[RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, [RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,
"IPv6 Router Advertisement Options for DNS Configuration", "IPv6 Router Advertisement Options for DNS Configuration",
RFC 8106, DOI 10.17487/RFC8106, March 2017, RFC 8106, DOI 10.17487/RFC8106, March 2017,
<https://www.rfc-editor.org/info/rfc8106>. <https://www.rfc-editor.org/info/rfc8106>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
(IPv6) Specification", STD 86, RFC 8200, Richardson, M., Jiang, S., Lemon, T., and T. Winters,
DOI 10.17487/RFC8200, July 2017, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
<https://www.rfc-editor.org/info/rfc8200>. RFC 8415, DOI 10.17487/RFC8415, November 2018,
<https://www.rfc-editor.org/info/rfc8415>.
11.2. Informative References 11.2. Informative References
[I-D.baker-ipv6-isis-dst-src-routing]
Baker, F. and D. Lamparter, "IPv6 Source/Destination
Routing using IS-IS", draft-baker-ipv6-isis-dst-src-
routing-07 (work in progress), July 2017.
[I-D.baker-rtgwg-src-dst-routing-use-cases]
Baker, F., Xu, M., Yang, S., and J. Wu, "Requirements and
Use Cases for Source/Destination Routing", draft-baker-
rtgwg-src-dst-routing-use-cases-02 (work in progress),
April 2016.
[I-D.boutier-babel-source-specific]
Boutier, M. and J. Chroboczek, "Source-Specific Routing in
Babel", draft-boutier-babel-source-specific-03 (work in
progress), July 2017.
[I-D.huitema-shim6-ingress-filtering]
Huitema, C., "Ingress filtering compatibility for IPv6
multihomed sites", draft-huitema-shim6-ingress-
filtering-00 (work in progress), September 2005.
[I-D.ietf-intarea-provisioning-domains] [I-D.ietf-intarea-provisioning-domains]
Pfister, P., Vyncke, E., Pauly, T., Schinazi, D., and W. Pfister, P., Vyncke, E., Pauly, T., Schinazi, D., and W.
Shao, "Discovering Provisioning Domain Names and Data", Shao, "Discovering Provisioning Domain Names and Data",
draft-ietf-intarea-provisioning-domains-02 (work in draft-ietf-intarea-provisioning-domains-04 (work in
progress), June 2018. progress), March 2019.
[I-D.ietf-rtgwg-dst-src-routing] [I-D.ietf-rtgwg-dst-src-routing]
Lamparter, D. and A. Smirnov, "Destination/Source Lamparter, D. and A. Smirnov, "Destination/Source
Routing", draft-ietf-rtgwg-dst-src-routing-06 (work in Routing", draft-ietf-rtgwg-dst-src-routing-07 (work in
progress), October 2017. progress), March 2019.
[I-D.pfister-6man-sadr-ra] [I-D.pfister-6man-sadr-ra]
Pfister, P., "Source Address Dependent Route Information Pfister, P., "Source Address Dependent Route Information
Option for Router Advertisements", draft-pfister-6man- Option for Router Advertisements", draft-pfister-6man-
sadr-ra-01 (work in progress), June 2015. sadr-ra-01 (work in progress), June 2015.
[I-D.xu-src-dst-bgp]
Xu, M., Yang, S., and J. Wu, "Source/Destination Routing
Using BGP-4", draft-xu-src-dst-bgp-00 (work in progress),
March 2016.
[PATRICIA]
Morrison, D., "Practical Algorithm to Retrieve Information
Coded in Alphanumeric", Journal of the ACM 15(4)
pp514-534, October 1968.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed [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>.
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol
(DHCP) Service for IPv6", RFC 3736, DOI 10.17487/RFC3736,
April 2004, <https://www.rfc-editor.org/info/rfc3736>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
Control Message Protocol (ICMPv6) for the Internet Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", STD 89, Protocol Version 6 (IPv6) Specification", STD 89,
RFC 4443, DOI 10.17487/RFC4443, March 2006, RFC 4443, DOI 10.17487/RFC4443, March 2006,
<https://www.rfc-editor.org/info/rfc4443>. <https://www.rfc-editor.org/info/rfc4443>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007, DOI 10.17487/RFC4861, September 2007,
<https://www.rfc-editor.org/info/rfc4861>. <https://www.rfc-editor.org/info/rfc4861>.
skipping to change at page 48, line 49 skipping to change at page 47, line 20
[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6 "Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,
<https://www.rfc-editor.org/info/rfc6724>. <https://www.rfc-editor.org/info/rfc6724>.
[RFC7078] Matsumoto, A., Fujisaki, T., and T. Chown, "Distributing [RFC7078] Matsumoto, A., Fujisaki, T., and T. Chown, "Distributing
Address Selection Policy Using DHCPv6", RFC 7078, Address Selection Policy Using DHCPv6", RFC 7078,
DOI 10.17487/RFC7078, January 2014, DOI 10.17487/RFC7078, January 2014,
<https://www.rfc-editor.org/info/rfc7078>. <https://www.rfc-editor.org/info/rfc7078>.
[RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking
Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April
2016, <https://www.rfc-editor.org/info/rfc7788>.
[RFC8041] Bonaventure, O., Paasch, C., and G. Detal, "Use Cases and
Operational Experience with Multipath TCP", RFC 8041,
DOI 10.17487/RFC8041, January 2017,
<https://www.rfc-editor.org/info/rfc8041>.
[RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2:
Better Connectivity Using Concurrency", RFC 8305,
DOI 10.17487/RFC8305, December 2017,
<https://www.rfc-editor.org/info/rfc8305>.
Appendix A. Change Log
Initial Version: July 2016
Authors' Addresses Authors' Addresses
Fred Baker Fred Baker
Santa Barbara, California 93117 Santa Barbara, California 93117
USA USA
Email: FredBaker.IETF@gmail.com Email: FredBaker.IETF@gmail.com
Chris Bowers Chris Bowers
Juniper Networks Juniper Networks
 End of changes. 67 change blocks. 
217 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/