draft-ietf-rtgwg-enterprise-pa-multihoming-06.txt   draft-ietf-rtgwg-enterprise-pa-multihoming-07.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: November 16, 2018 Juniper Networks Expires: December 13, 2018 Juniper Networks
J. Linkova J. Linkova
Google Google
May 15, 2018 June 11, 2018
Enterprise Multihoming using Provider-Assigned Addresses without Network Enterprise Multihoming using Provider-Assigned Addresses without Network
Prefix Translation: Requirements and Solution Prefix Translation: Requirements and Solution
draft-ietf-rtgwg-enterprise-pa-multihoming-06 draft-ietf-rtgwg-enterprise-pa-multihoming-07
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
skipping to change at page 2, line 7 skipping to change at page 2, line 7
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 November 16, 2018. This Internet-Draft will expire on December 13, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Enterprise Multihoming Requirements . . . . . . . . . . . . . 6 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 6
2.1. Simple ISP Connectivity with Connected SERs . . . . . . . 6 3. Enterprise Multihoming Requirements . . . . . . . . . . . . . 6
2.2. Simple ISP Connectivity Where SERs Are Not Directly 3.1. Simple ISP Connectivity with Connected SERs . . . . . . . 6
Connected . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Simple ISP Connectivity Where SERs Are Not Directly
2.3. Enterprise Network Operator Expectations . . . . . . . . 8 Connected . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4. More complex ISP connectivity . . . . . . . . . . . . . . 11 3.3. Enterprise Network Operator Expectations . . . . . . . . 9
2.5. ISPs and Provider-Assigned Prefixes . . . . . . . . . . . 13 3.4. More complex ISP connectivity . . . . . . . . . . . . . . 12
2.6. Simplified Topologies . . . . . . . . . . . . . . . . . . 14 3.5. ISPs and Provider-Assigned Prefixes . . . . . . . . . . . 14
3. Generating Source-Prefix-Scoped Forwarding Tables . . . . . 14 3.6. Simplified Topologies . . . . . . . . . . . . . . . . . . 15
4. Mechanisms For Hosts To Choose Good Source Addresses In A 4. Generating Source-Prefix-Scoped Forwarding Tables . . . . . 15
Multihomed Site . . . . . . . . . . . . . . . . . . . . . . . 21 5. Mechanisms For Hosts To Choose Good Source Addresses In A
4.1. Source Address Selection Algorithm on Hosts . . . . . . . 23 Multihomed Site . . . . . . . . . . . . . . . . . . . . . . . 22
4.2. Selecting Source Address When Both Uplinks Are Working . 26 5.1. Source Address Selection Algorithm on Hosts . . . . . . . 24
4.2.1. Distributing Address Selection Policy Table with 5.2. Selecting Source Address When Both Uplinks Are Working . 27
DHCPv6 . . . . . . . . . . . . . . . . . . . . . . . 26 5.2.1. Distributing Address Selection Policy Table with
4.2.2. Controlling Source Address Selection With Router DHCPv6 . . . . . . . . . . . . . . . . . . . . . . . 27
Advertisements . . . . . . . . . . . . . . . . . . . 26 5.2.2. Controlling Source Address Selection With Router
4.2.3. Controlling Source Address Selection With ICMPv6 . . 28 Advertisements . . . . . . . . . . . . . . . . . . . 27
4.2.4. Summary of Methods For Controlling Source Address 5.2.3. Controlling Source Address Selection With ICMPv6 . . 29
Selection To Implement Routing Policy . . . . . . . . 30 5.2.4. Summary of Methods For Controlling Source Address
4.3. Selecting Source Address When One Uplink Has Failed . . . 31 Selection To Implement Routing Policy . . . . . . . . 31
4.3.1. Controlling Source Address Selection With DHCPv6 . . 32 5.3. Selecting Source Address When One Uplink Has Failed . . . 32
4.3.2. Controlling Source Address Selection With Router 5.3.1. Controlling Source Address Selection With DHCPv6 . . 33
Advertisements . . . . . . . . . . . . . . . . . . . 33 5.3.2. Controlling Source Address Selection With Router
4.3.3. Controlling Source Address Selection With ICMPv6 . . 34 Advertisements . . . . . . . . . . . . . . . . . . . 34
4.3.4. Summary Of Methods For Controlling Source Address
Selection On The Failure Of An Uplink . . . . . . . . 34 5.3.3. Controlling Source Address Selection With ICMPv6 . . 35
4.4. Selecting Source Address Upon Failed Uplink Recovery . . 35 5.3.4. Summary Of Methods For Controlling Source Address
4.4.1. Controlling Source Address Selection With DHCPv6 . . 35 Selection On The Failure Of An Uplink . . . . . . . . 35
4.4.2. Controlling Source Address Selection With Router 5.4. Selecting Source Address Upon Failed Uplink Recovery . . 36
Advertisements . . . . . . . . . . . . . . . . . . . 35 5.4.1. Controlling Source Address Selection With DHCPv6 . . 36
4.4.3. Controlling Source Address Selection With ICMP . . . 36 5.4.2. Controlling Source Address Selection With Router
4.4.4. Summary Of Methods For Controlling Source Address Advertisements . . . . . . . . . . . . . . . . . . . 36
Selection Upon Failed Uplink Recovery . . . . . . . . 36 5.4.3. Controlling Source Address Selection With ICMP . . . 37
4.5. Selecting Source Address When All Uplinks Failed . . . . 37 5.4.4. Summary Of Methods For Controlling Source Address
4.5.1. Controlling Source Address Selection With DHCPv6 . . 37 Selection Upon Failed Uplink Recovery . . . . . . . . 37
4.5.2. Controlling Source Address Selection With Router 5.5. Selecting Source Address When All Uplinks Failed . . . . 38
Advertisements . . . . . . . . . . . . . . . . . . . 37 5.5.1. Controlling Source Address Selection With DHCPv6 . . 38
4.5.3. Controlling Source Address Selection With ICMPv6 . . 38 5.5.2. Controlling Source Address Selection With Router
4.5.4. Summary Of Methods For Controlling Source Address Advertisements . . . . . . . . . . . . . . . . . . . 38
Selection When All Uplinks Failed . . . . . . . . . . 38 5.5.3. Controlling Source Address Selection With ICMPv6 . . 39
4.6. Summary Of Methods For Controlling Source Address 5.5.4. Summary Of Methods For Controlling Source Address
Selection . . . . . . . . . . . . . . . . . . . . . . . . 38 Selection When All Uplinks Failed . . . . . . . . . . 39
4.7. Other Configuration Parameters . . . . . . . . . . . . . 40 5.6. Summary Of Methods For Controlling Source Address
4.7.1. DNS Configuration . . . . . . . . . . . . . . . . . . 40 Selection . . . . . . . . . . . . . . . . . . . . . . . . 39
5. Deployment Considerations . . . . . . . . . . . . . . . . . . 41 5.7. Other Configuration Parameters . . . . . . . . . . . . . 41
6. Other Solutions . . . . . . . . . . . . . . . . . . . . . . . 42 5.7.1. DNS Configuration . . . . . . . . . . . . . . . . . . 41
6.1. Shim6 . . . . . . . . . . . . . . . . . . . . . . . . . . 42 6. Deployment Considerations . . . . . . . . . . . . . . . . . . 42
6.2. IPv6-to-IPv6 Network Prefix Translation . . . . . . . . . 42 7. Other Solutions . . . . . . . . . . . . . . . . . . . . . . . 43
6.3. Multipath Transport . . . . . . . . . . . . . . . . . . . 42 7.1. Shim6 . . . . . . . . . . . . . . . . . . . . . . . . . . 43
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 7.2. IPv6-to-IPv6 Network Prefix Translation . . . . . . . . . 43
8. Security Considerations . . . . . . . . . . . . . . . . . . . 43 7.3. Multipath Transport . . . . . . . . . . . . . . . . . . . 43
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 43 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 9. Security Considerations . . . . . . . . . . . . . . . . . . . 44
10.1. Normative References . . . . . . . . . . . . . . . . . . 43 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 44
10.2. Informative References . . . . . . . . . . . . . . . . . 45 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 44
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 48 11.1. Normative References . . . . . . . . . . . . . . . . . . 44
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48 11.2. Informative References . . . . . . . . . . . . . . . . . 46
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 49
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 14 skipping to change at page 5, line 14
[RFC6296] describes a translation solution specifically tailored to [RFC6296] describes a translation solution specifically tailored to
meet the requirements of multi-homing with provider-assigned IPv6 meet the requirements of multi-homing with provider-assigned IPv6
addresses. With the IPv6-to-IPv6 Network Prefix Translation (NPTv6) addresses. With the IPv6-to-IPv6 Network Prefix Translation (NPTv6)
solution, within the site an enterprise can use Unique Local solution, within the site an enterprise can use Unique Local
Addresses [RFC4193] or the prefix assigned by one of the ISPs. As Addresses [RFC4193] or the prefix assigned by one of the ISPs. As
traffic leaves the site on an uplink to an ISP, the source address traffic leaves the site on an uplink to an ISP, the source address
gets translated to an address within the prefix assigned by the ISP gets translated to an address within the prefix assigned by the ISP
on that uplink in a predictable and reversible manner. [RFC6296] is on that uplink in a predictable and reversible manner. [RFC6296] is
currently classified as Experimental, and it has been implemented by currently classified as Experimental, and it has been implemented by
several vendors. See Section 6.2, for more discussion of NPTv6. several vendors. See Section 7.2, for more discussion of NPTv6.
This document defines routing requirements for enterprise multihoming This document defines routing requirements for enterprise multihoming
using provider-assigned IPv6 addresses. We have made no attempt to using provider-assigned IPv6 addresses. We have made no attempt to
write these requirements in a manner that is agnostic to potential write these requirements in a manner that is agnostic to potential
solutions. Instead, this document focuses on the following general solutions. Instead, this document focuses on the following general
class of solutions. class of solutions.
Each host at the enterprise has multiple addresses, at least one from Each host at the enterprise has multiple addresses, at least one from
each ISP-assigned prefix. Each host, as discussed in Section 4.1 and each ISP-assigned prefix. Each host, as discussed in Section 5.1 and
[RFC6724], is responsible for choosing the source address applied to [RFC6724], is responsible for choosing the source address applied to
each packet it sends. A host SHOULD be able respond dynamically to each packet it sends. A host SHOULD be able respond dynamically to
the failure of an uplink to a given ISP by no longer sending packets the failure of an uplink to a given ISP by no longer sending packets
with the source address corresponding to that ISP. Potential with the source address corresponding to that ISP. Potential
mechanisms for the communication of changes in the network to the mechanisms for the communication of changes in the network to the
host are Neighbor Discovery Router Advertisements, DHCPv6, and host are Neighbor Discovery Router Advertisements, DHCPv6, and
ICMPv6. ICMPv6.
The routers in the enterprise network are responsible for ensuring The routers in the enterprise network are responsible for ensuring
that packets are delivered to the "correct" ISP uplink based on that packets are delivered to the "correct" ISP uplink based on
skipping to change at page 6, line 5 skipping to change at page 6, line 5
with external destinations. with external destinations.
The document first looks in more detail at the enterprise networking The document first looks in more detail at the enterprise networking
environments in which this solution is expected to operate. It then environments in which this solution is expected to operate. It then
discusses existing and proposed mechanisms for hosts to select the discusses existing and proposed mechanisms for hosts to select the
source address applied to packets. Finally, it looks at the source address applied to packets. Finally, it looks at the
requirements for routing that are needed to support these enterprise requirements for routing that are needed to support these enterprise
network scenarios and the mechanisms by which hosts are expected to network scenarios and the mechanisms by which hosts are expected to
select source addresses dynamically based on network state. select source addresses dynamically based on network state.
2. Enterprise Multihoming Requirements 2. Requirements Language
2.1. Simple ISP Connectivity with Connected SERs The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Enterprise Multihoming Requirements
3.1. Simple ISP Connectivity with Connected SERs
We start by looking at a scenario in which a site has connections to We start by looking at a scenario in which a site has connections to
two ISPs, as shown in Figure 1. The site is assigned the prefix two ISPs, as shown in Figure 1. The site is assigned the prefix
2001:db8:0:a000::/52 by ISP-A and prefix 2001:db8:0:b000::/52 by ISP- 2001:db8:0:a000::/52 by ISP-A and prefix 2001:db8:0:b000::/52 by ISP-
B. We consider three hosts in the site. H31 and H32 are on a LAN B. We consider three hosts in the site. H31 and H32 are on a LAN
that has been assigned subnets 2001:db8:0:a010::/64 and that has been assigned subnets 2001:db8:0:a010::/64 and
2001:db8:0:b010::/64. H31 has been assigned the addresses 2001:db8:0:b010::/64. H31 has been assigned the addresses
2001:db8:0:a010::31 and 2001:db8:0:b010::31. H32 has been assigned 2001:db8:0:a010::31 and 2001:db8:0:b010::31. H32 has been assigned
2001:db8:0:a010::32 and 2001:db8:0:b010::32. H41 is on a different 2001:db8:0:a010::32 and 2001:db8:0:b010::32. H41 is on a different
subnet that has been assigned 2001:db8:0:a020::/64 and subnet that has been assigned 2001:db8:0:a020::/64 and
skipping to change at page 7, line 5 skipping to change at page 7, line 37
2001:db8:0:a020::41 2001:db8:0:a020::41
2001:db8:0:b020::41 2001:db8:0:b020::41
Figure 1: Simple ISP Connectivity With Connected SERs Figure 1: Simple ISP Connectivity With Connected SERs
We refer to a router that connects the site to an ISP as a site edge We refer to a router that connects the site to an ISP as a site edge
router(SER). Several other routers provide connectivity among the router(SER). Several other routers provide connectivity among the
internal hosts (H31, H32, and H41), as well as connecting the internal hosts (H31, H32, and H41), as well as connecting the
internal hosts to the Internet through SERa and SERb. In this internal hosts to the Internet through SERa and SERb. In this
example SERa and SERb share a direct connection to each other. In example SERa and SERb share a direct connection to each other. In
Section 2.2, we consider a scenario where this is not the case. Section 3.2, we consider a scenario where this is not the case.
For the moment, we assume that the hosts are able to make good 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 4, we examine what role the routed network may packet. In Section 5, we examine what role the routed network may
play in helping hosts make good choices about source addresses for 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 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.
skipping to change at page 7, line 45 skipping to change at page 8, line 29
In Figure 1, when only SERa and SERb are capable of source address In Figure 1, when only SERa and SERb are capable of source address
dependent routing, PA multi-homing will work. However, the paths dependent routing, PA multi-homing will work. However, the paths
over which the packets are sent will generally not be the shortest over which the packets are sent will generally not be the shortest
paths. The forwarding paths will generally be more efficient as more paths. The forwarding paths will generally be more efficient as more
routers are capable of SADR. For example, if R4, R2, and R6 are routers are capable of SADR. For example, if R4, R2, and R6 are
upgraded to support SADR, then can exchange source-scoped routes with upgraded to support SADR, then can exchange source-scoped routes with
SERa and SERb. They will then know to send traffic with a source SERa and SERb. They will then know to send traffic with a source
address matching prefix 2001:db8:0:b000::/52 directly to SERb, address matching prefix 2001:db8:0:b000::/52 directly to SERb,
without sending it to SERa first. without sending it to SERa first.
2.2. Simple ISP Connectivity Where SERs Are Not Directly Connected 3.2. Simple ISP Connectivity Where SERs Are Not Directly Connected
In Figure 2, we modify the topology slightly by inserting R7, so that In Figure 2, we modify the topology slightly by inserting R7, so that
SERa and SERb are no longer directly connected. With this topology, SERa and SERb are no longer directly connected. With this topology,
it is not enough to just enable SADR routing on SERa and SERb to it is not enough to just enable SADR routing on SERa and SERb to
support PA multi-homing. There are two solutions to ways to enable support PA multi-homing. There are two solutions to ways to enable
PA multihoming in this topology. PA multihoming in this topology.
2001:db8:0:1234::101 H101 2001:db8:0:1234::101 H101
| |
| |
skipping to change at page 8, line 47 skipping to change at page 9, line 47
The other option is to enable SADR functionality on R7. In this way, The other option is to enable SADR functionality on R7. In this way,
R7 will exchange source-scoped routes with SERa and SERb, making the R7 will exchange source-scoped routes with SERa and SERb, making the
three routers act as a single SADR domain. This illustrates the three routers act as a single SADR domain. This illustrates the
basic principle that the minimum requirement for the routed site basic principle that the minimum requirement for the routed site
network to support PA multi-homing is having all of the site exit network to support PA multi-homing is having all of the site exit
routers be part of a connected SADR domain. Extending the connected routers be part of a connected SADR domain. Extending the connected
SADR domain beyond that point can produce more efficient forwarding SADR domain beyond that point can produce more efficient forwarding
paths. paths.
2.3. Enterprise Network Operator Expectations 3.3. Enterprise Network Operator Expectations
Before considering a more complex scenario, let's look in more detail 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
skipping to change at page 11, line 14 skipping to change at page 12, line 14
Implementing the same routing policy is more difficult with the PA Implementing the same routing policy is more difficult with the PA
multihoming solution described in this document since it doesn't use multihoming solution described in this document since it doesn't use
NAT. By design, the only way to control where a packet exits this NAT. By design, the only way to control where a packet exits this
network is by setting the source address of the packet. Since the network is by setting the source address of the packet. Since the
network cannot modify the source address without NAT, the host must network cannot modify the source address without NAT, the host must
set it. To implement this routing policy, each host needs to use the set it. To implement this routing policy, each host needs to use the
source address from the prefix assigned by ISP-A to send traffic source address from the prefix assigned by ISP-A to send traffic
destined for H101. Mechanisms have been proposed to allow hosts to destined for H101. Mechanisms have been proposed to allow hosts to
choose the source address for packets in a fine grained manner. We choose the source address for packets in a fine grained manner. We
will discuss these proposals in Section 4. However, interacting with will discuss these proposals in Section 5. However, interacting with
host operating systems in some manner to ensure a particular source host operating systems in some manner to ensure a particular source
address is chosen for a particular destination prefix is not what an address is chosen for a particular destination prefix is not what an
enterprise network administrator would expect to have to do to enterprise network administrator would expect to have to do to
implement this routing policy. implement this routing policy.
2.4. More complex ISP connectivity 3.4. More complex ISP connectivity
The previous sections considered two variations of a simple 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 variation of this are
skipping to change at page 13, line 43 skipping to change at page 14, line 43
administrator trying to configure, maintain, and trouble-shoot this administrator trying to configure, maintain, and trouble-shoot this
multihoming solution, it seems much clearer to have SERb2 originate multihoming solution, it seems much clearer to have SERb2 originate
the source-prefix-scoped destination route correspond to the service the source-prefix-scoped destination route correspond to the service
offered by ISP-B. In this way, all of the traffic leaving the site offered by ISP-B. In this way, all of the traffic leaving the site
is determined by the source-prefix-scoped routes, and all of the is determined by the source-prefix-scoped routes, and all of the
traffic within the site or arriving from external hosts is determined traffic within the site or arriving from external hosts is determined
by the unscoped destination routes. Therefore, for this multihoming by the unscoped destination routes. Therefore, for this multihoming
solution we choose to originate source-prefix-scoped routes for all solution we choose to originate source-prefix-scoped routes for all
traffic leaving the site. traffic leaving the site.
2.5. ISPs and Provider-Assigned Prefixes 3.5. ISPs and Provider-Assigned Prefixes
While we expect that most site multihoming involves connecting to 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.
2.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
exit router. However, it is the aim of this draft to provide a exit router. However, it is the aim of this draft to provide a
solution that applies to a broad a range of enterprise site network solution that applies to a broad a range of enterprise site network
topologies, so this draft focuses on providing a solution to the more topologies, so this draft focuses on providing a solution to the more
skipping to change at page 14, line 32 skipping to change at page 15, line 32
simplified cases. This solution however needs to support more simplified cases. This solution however needs to support more
complex topologies. complex topologies.
We are starting with the basic assumption that enterprise site We are starting with the basic assumption that enterprise site
networks can be quite complex from a routing perspective. However, networks can be quite complex from a routing perspective. However,
even a complex site network can be multihomed to different ISPs with even a complex site network can be multihomed to different ISPs with
PA addresses using IPv4 and NAT. It is not reasonable to expect an PA addresses using IPv4 and NAT. It is not reasonable to expect an
enterprise network operator to change the routing topology of the enterprise network operator to change the routing topology of the
site in order to deploy IPv6. site in order to deploy IPv6.
3. Generating Source-Prefix-Scoped Forwarding Tables 4. Generating Source-Prefix-Scoped Forwarding Tables
So far we have described in general terms how the routers in this So far we have described in general terms how the routers in this
solution that are capable of Source Address Dependent Routing will solution that are capable of Source Address Dependent Routing will
forward traffic using both normal unscoped destination routes and forward traffic using both normal unscoped destination routes and
source-prefix-scoped destination routes. Here we give a precise source-prefix-scoped destination routes. Here we give a precise
method for generating a source-prefix-scoped forwarding table on a method for generating a source-prefix-scoped forwarding table on a
router that supports SADR. router that supports SADR.
1. Compute the next-hops for the source-prefix-scoped destination 1. Compute the next-hops for the source-prefix-scoped destination
prefixes using only routers in the connected SADR domain. These prefixes using only routers in the connected SADR domain. These
skipping to change at page 21, line 43 skipping to change at page 22, line 43
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.
4. Mechanisms For Hosts To Choose Good Source Addresses In A Multihomed 5. Mechanisms For Hosts To Choose Good Source Addresses In A Multihomed
Site Site
Until this point, we have made the assumption that hosts are able to Until this point, we have made the assumption that hosts are able to
choose the correct source address using some unspecified mechanism. choose the correct source address using some unspecified mechanism.
This has allowed us to just focus on what the routers in a multihomed This has allowed us to just focus on what the routers in a multihomed
site network need to do in order to forward packets to the correct site network need to do in order to forward packets to the correct
ISP based on source address. Now we look at possible mechanisms for ISP based on source address. Now we look at possible mechanisms for
hosts to choose the correct source address. We also look at what hosts to choose the correct source address. We also look at what
role, if any, the routers may play in providing information that role, if any, the routers may play in providing information that
helps hosts to choose source addresses. helps hosts to choose source addresses.
skipping to change at page 23, line 8 skipping to change at page 24, line 8
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
ICMPv6. Note that we are explicitly excluding the possibility of ICMPv6. Note that we are explicitly excluding the possibility of
having hosts participate in or even listen directly to routing having hosts participate in or even listen directly to routing
protocol advertisements. protocol advertisements.
First we look at how a host is currently expected to select the First we look at how a host is currently expected to select the
source and destination address with which it sends a packet. source and destination address with which it sends a packet.
4.1. Source Address Selection Algorithm on Hosts 5.1. Source Address Selection Algorithm on Hosts
[RFC6724] defines the algorithms that hosts are expected to use to [RFC6724] defines the algorithms that hosts are expected to use to
select source and destination addresses for packets. It defines an select source and destination addresses for packets. It defines an
algorithm for selecting a source address and a separate algorithm for algorithm for selecting a source address and a separate algorithm for
selecting a destination address. Both of these algorithms depend on selecting a destination address. Both of these algorithms depend on
a policy table. [RFC6724] defines a default policy which produces a policy table. [RFC6724] defines a default policy which produces
certain behavior. certain behavior.
The rules in the two algorithms in [RFC6724] depend on many different The rules in the two algorithms in [RFC6724] depend on many different
properties of addresses. While these are needed for understanding properties of addresses. While these are needed for understanding
skipping to change at page 26, line 7 skipping to change at page 27, line 7
another strategy is to choose a source address, send the packet, get another strategy is to choose a source address, send the packet, get
feedback from the network about whether or not the source address is feedback from the network about whether or not the source address is
correct, and try another source address if it is not. correct, and try another source address if it is not.
We consider four scenarios where a host needs to select the correct We consider four scenarios where a host needs to select the correct
source address. The first is when both uplinks are working. The source address. The first is when both uplinks are working. The
second is when one uplink has failed. The third one is a situation second is when one uplink has failed. The third one is a situation
when one failed uplink has recovered. The last one is failure of when one failed uplink has recovered. The last one is failure of
both (all) uplinks. both (all) uplinks.
4.2. Selecting Source Address When Both Uplinks Are Working 5.2. Selecting Source Address When Both Uplinks Are Working
Again we return to the topology in Figure 3. Suppose that the site Again we return to the topology in Figure 3. Suppose that the site
administrator wants to implement a policy by which all hosts need to administrator wants to implement a policy by which all hosts need to
use ISP-A to reach H01 at D=2001:db8:0:1234::101. So for example, use ISP-A to reach H01 at D=2001:db8:0:1234::101. So for example,
H31 needs to select S=2001:db8:0:a010::31. H31 needs to select S=2001:db8:0:a010::31.
4.2.1. Distributing Address Selection Policy Table with DHCPv6 5.2.1. Distributing Address Selection Policy Table with DHCPv6
This policy can be implemented by using DHCPv6 to distribute an This policy can be implemented by using DHCPv6 to distribute an
address selection policy table that assigns the same label to address selection policy table that assigns the same label to
destination address that match 2001:db8:0:1234::/64 as it does to destination address that match 2001:db8:0:1234::/64 as it does to
source addresses that match 2001:db8:0:a000::/52. The following two source addresses that match 2001:db8:0:a000::/52. The following two
entries accomplish this. entries accomplish this.
Prefix Precedence Label Prefix Precedence Label
2001:db8:0:1234::/64 50 33 2001:db8:0:1234::/64 50 33
2001:db8:0:a000::/52 50 33 2001:db8:0:a000::/52 50 33
skipping to change at page 26, line 47 skipping to change at page 27, line 47
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 scenarion 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.
4.2.2. Controlling Source Address Selection With Router Advertisements 5.2.2. Controlling Source Address Selection With Router Advertisements
Neighbor Discovery currently has two mechanisms to communicate prefix Neighbor Discovery currently has two mechanisms to communicate prefix
information to hosts. The base specification for Neighbor Discovery information to hosts. The base specification for Neighbor Discovery
(see [RFC4861]) defines the Prefix Information Option (PIO) in the (see [RFC4861]) defines the Prefix Information Option (PIO) in the
Router Advertisement (RA) message. When a host receives a PIO with Router Advertisement (RA) message. When a host receives a PIO with
the A-flag set, it can use the prefix in the PIO as source prefix the A-flag set, it can use the prefix in the PIO as source prefix
from which it assigns itself an IP address using stateless address from which it assigns itself an IP address using stateless address
autoconfiguration (SLAAC) procedures described in [RFC4862]. In the autoconfiguration (SLAAC) procedures described in [RFC4862]. In the
example of Figure 3, if the site network is using SLAAC, we would example of Figure 3, if the site network is using SLAAC, we would
expect both R1 and R2 to send RA messages with PIOs for both source expect both R1 and R2 to send RA messages with PIOs for both source
skipping to change at page 27, line 40 skipping to change at page 28, line 40
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 a 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 4.1 above), together with default router (discussed in Section 5.1 above), together with default router
preference (specified in [RFC4191]) and RIO can be used to influence 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)
skipping to change at page 28, line 44 skipping to change at page 29, line 44
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.
4.2.3. Controlling Source Address Selection With ICMPv6 5.2.3. Controlling Source Address Selection With ICMPv6
We now discuss how one might use ICMPv6 to implement the routing We now discuss how one might use ICMPv6 to implement the routing
policy to send traffic destined for H101 out the uplink to ISP-A, policy to send traffic destined for H101 out the uplink to ISP-A,
even when uplinks to both ISPs are working. If H31 started sending even when uplinks to both ISPs are working. If H31 started sending
traffic to H101 with S=2001:db8:0:b010::31 and traffic to H101 with S=2001:db8:0:b010::31 and
D=2001:db8:0:1234::101, it would be routed through SER-b1 and out the D=2001:db8:0:1234::101, it would be routed through SER-b1 and out the
uplink to ISP-B. SERb1 could recognize that this is traffic is not uplink to ISP-B. SERb1 could recognize that this is traffic is not
following the desired routing policy and react by sending an ICMPv6 following the desired routing policy and react by sending an ICMPv6
message back to H31. message back to H31.
skipping to change at page 30, line 12 skipping to change at page 31, line 12
software or hardware limits on generating ICMP messages. An site software or hardware limits on generating ICMP messages. An site
administrator deploying a solution that relies on the SERs generating administrator deploying a solution that relies on the SERs generating
ICMP messages could try to improve the performance of SERs for ICMP messages could try to improve the performance of SERs for
generating ICMP messages. However, in a large network, it is still generating ICMP messages. However, in a large network, it is still
likely that ICMP message generation limits will be reached. As a likely that ICMP message generation limits will be reached. As a
result hosts would not receive ICMPv6 back which in turn leads to result hosts would not receive ICMPv6 back which in turn leads to
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 4.3). In addition, the same source prefix failure - see Section 5.3). In addition, the same source prefix
SHOULD be used for other destinations in the same /64 as the original 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 Code 5 message for influencing source address selection
allows an attacker to exhaust the list of candidate source addresses allows an attacker to exhaust the list of candidate source addresses
on the host by sending spoofed ICMPv6 Code 5 for all prefixes known on the host by sending spoofed ICMPv6 Code 5 for all prefixes known
on the network (therefore preventing a victim from establishing a on the network (therefore preventing a victim from establishing a
communication with the destination host). To protect from such communication with the destination host). To protect from such
skipping to change at page 30, line 35 skipping to change at page 31, line 35
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.
4.2.4. Summary of Methods For Controlling Source Address Selection To 5.2.4. Summary of Methods For Controlling Source Address Selection To
Implement Routing Policy Implement Routing Policy
So to summarize this section, we have looked at three methods for So to summarize this section, we have looked at three methods for
implementing a simple routing policy where all traffic for a given implementing a simple routing policy where all traffic for a given
destination on the Internet needs to use a particular ISP, even when destination on the Internet needs to use a particular ISP, even when
the uplinks to both ISPs are working. the uplinks to both ISPs are working.
The default source address selection policy cannot distinguish The default source address selection policy cannot distinguish
between the source addresses needed to enforce this policy, so a non- between the source addresses needed to enforce this policy, so a non-
default policy table using associating source and destination default policy table using associating source and destination
skipping to change at page 31, line 28 skipping to change at page 32, line 28
egress policy) for traffic that is being sent with the wrong source egress policy) for traffic that is being sent with the wrong source
address. The policy distribution can be automated by defining an address. The policy distribution can be automated by defining an
EXCLUSIVE flag for the source-prefix-scoped route which can be set on EXCLUSIVE flag for the source-prefix-scoped route which can be set on
the SER that originates the route. As ICMPv6 message generation can the SER that originates the route. As ICMPv6 message generation can
be rate-limited on routers, it SHOULD NOT be used as the only be rate-limited on routers, it SHOULD NOT be used as the only
mechanism to influence source address selection on hosts. While mechanism to influence source address selection on hosts. While
hosts SHOULD select the correct source address for a given hosts SHOULD select the correct source address for a given
destination the network SHOULD signal any source address issues back destination the network SHOULD signal any source address issues back
to hosts using ICMPv6 error messages. to hosts using ICMPv6 error messages.
4.3. Selecting Source Address When One Uplink Has Failed 5.3. Selecting Source Address When One Uplink Has Failed
Now we discuss if DHCPv6, Neighbor Discovery Router Advertisements, Now we discuss if DHCPv6, Neighbor Discovery Router Advertisements,
and ICMPv6 can help a host choose the right source address when an and ICMPv6 can help a host choose the right source address when an
uplink to one of the ISPs has failed. Again we look at the scenario uplink to one of the ISPs has failed. Again we look at the scenario
in Figure 3. This time we look at traffic from H31 destined for in Figure 3. This time we look at traffic from H31 destined for
external host H501 at D=2001:db8:0:5678::501. We initially assume external host H501 at D=2001:db8:0:5678::501. We initially assume
that the uplink from SERa to ISP-A is working and that the uplink that the uplink from SERa to ISP-A is working and that the uplink
from SERb1 to ISP-B is working. from SERb1 to ISP-B is working.
We assume there is no particular routing policy desired, so H31 is We assume there is no particular routing policy desired, so H31 is
free to send packets with S=2001:db8:0:a010::31 or free to send packets with S=2001:db8:0:a010::31 or
S=2001:db8:0:b010::31 and have them delivered to H501. For this S=2001:db8:0:b010::31 and have them delivered to H501. For this
example, we assume that H31 has chosen S=2001:db8:0:b010::31 so that example, we assume that H31 has chosen S=2001:db8:0:b010::31 so that
the packets exit via SERb to ISP-B. Now we see what happens when the the packets exit via SERb to ISP-B. Now we see what happens when the
link from SERb1 to ISP-B fails. How should H31 learn that it needs link from SERb1 to ISP-B fails. How should H31 learn that it needs
to start sending the packet to H501 with S=2001:db8:0:a010::31 in to start sending the packet to H501 with S=2001:db8:0:a010::31 in
order to start using the uplink to ISP-A? We need to do this in a order to start using the uplink to ISP-A? We need to do this in a
way that doesn't prevent H31 from still sending packets with way that doesn't prevent H31 from still sending packets with
S=2001:db8:0:b010::31 in order to reach H61 at D=2001:db8:0:6666::61. S=2001:db8:0:b010::31 in order to reach H61 at D=2001:db8:0:6666::61.
4.3.1. Controlling Source Address Selection With DHCPv6 5.3.1. Controlling Source Address Selection With DHCPv6
For this example we assume that the site network in Figure 3 has a For this example we assume that the site network in Figure 3 has a
centralized DHCP server and all routers act as DHCP relay agents. We centralized DHCP server and all routers act as DHCP relay agents. We
assume that both of the addresses assigned to H31 were assigned via assume that both of the addresses assigned to H31 were assigned via
DHCP. DHCP.
We could try to have the DHCP server monitor the state of the uplink We could try to have the DHCP server monitor the state of the uplink
from SERb1 to ISP-B in some manner and then tell H31 that it can no from SERb1 to ISP-B in some manner and then tell H31 that it can no
longer use S=2001:db8:0:b010::31 by settings its valid lifetime to longer use S=2001:db8:0:b010::31 by settings its valid lifetime to
zero. The DHCP server could initiate this process by sending a zero. The DHCP server could initiate this process by sending a
skipping to change at page 32, line 51 skipping to change at page 33, line 51
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
2001:db8:0:b000::/52 50 55 2001:db8:0:b000::/52 50 55
Figure 10: Policy Table Needed On Failure Of Uplink From SERb1 Figure 10: Policy Table Needed On Failure Of Uplink From SERb1
The described solution has a number of significant drawbacks, some of The described solution has a number of significant drawbacks, some of
them already discussed in Section 4.2.1. them already discussed in Section 5.2.1.
o DHCPv6 support is not required for an IPv6 host and there are o DHCPv6 support is not required for an IPv6 host and there are
operating systems which do not support DHCPv6. Besides that, it operating systems which do not support DHCPv6. Besides that, it
does not appear that [RFC7078] has been widely implemented on host does not appear that [RFC7078] has been widely implemented on host
operating systems. operating systems.
o [RFC7078] does not clearly specify this kind of a dynamic use case o [RFC7078] does not clearly specify this kind of a dynamic use case
where address selection policy needs to be updated quickly in where address selection policy needs to be updated quickly in
response to the failure of a link. In a large network it would response to the failure of a link. In a large network it would
present scalability issues as many hosts need to be reconfigured present scalability issues as many hosts need to be reconfigured
skipping to change at page 33, line 28 skipping to change at page 34, line 28
for mid/large distributed scale enterprise networks. In addition for mid/large distributed scale enterprise networks. In addition
to that, the policy table needs to be manually configured by to that, the policy table needs to be manually configured by
administrators which makes that solution prone to human error. administrators which makes that solution prone to human error.
o No mechanism exists for making DHCPv6 servers aware of network o No mechanism exists for making DHCPv6 servers aware of network
topology/routing changes in the network. In general DHCPv6 topology/routing changes in the network. In general DHCPv6
servers monitoring network-related events sounds like a bad idea servers monitoring network-related events sounds like a bad idea
as completely new functionality beyond the scope of DHCPv6 role is as completely new functionality beyond the scope of DHCPv6 role is
required. required.
4.3.2. Controlling Source Address Selection With Router Advertisements 5.3.2. Controlling Source Address Selection With Router Advertisements
The same mechanism as discussed in Section 4.2.2 can be used to The same mechanism as discussed in Section 5.2.2 can be used to
control the source address selection in the case of an uplink control the source address selection in the case of an uplink
failure. If a particular prefix should not be used as a source for failure. If a particular prefix should not be used as a source for
any destinations, then the router needs to send RA with Preferred any destinations, then the router needs to send RA with Preferred
Lifetime field for that prefix set to 0. Lifetime field for that prefix set to 0.
Let's consider a scenario when all uplinks are operational and H41 Let's consider a scenario when all uplinks are operational and H41
receives two different RAs from R3: one from LLA_A with PIO for receives two different RAs from R3: one from LLA_A with PIO for
2001:db8:0:a020::/64, default router preference set to 11 (low) and 2001:db8:0:a020::/64, default router preference set to 11 (low) and
another one from LLA_B with PIO for 2001:db8:0:a020::/64, default another one from LLA_B with PIO for 2001:db8:0:a020::/64, default
router preference set to 01 (high) and RIO for 2001:db8:0:6666::/64. router preference set to 01 (high) and RIO for 2001:db8:0:6666::/64.
skipping to change at page 34, line 13 skipping to change at page 35, line 13
hop and 2001:db8:0:b020::41 as a source address. For all traffic hop and 2001:db8:0:b020::41 as a source address. For all traffic
following the default route, LLA_A will be used as a next-hop and following the default route, LLA_A will be used as a next-hop and
2001:db8:0:a020::41 as a source address. 2001:db8:0:a020::41 as a source address.
If all uplinks to ISP-B have failed and therefore source addresses If all uplinks to ISP-B have failed and therefore source addresses
from ISP-B address space should not be used at all, the forwarding from ISP-B address space should not be used at all, the forwarding
table scoped S=2001:db8:0:b000::/52 contains no entries. Hosts can table scoped S=2001:db8:0:b000::/52 contains no entries. Hosts can
be instructed to stop using source addresses from that block by be instructed to stop using source addresses from that block by
sending RAs containing PIO with Preferred Lifetime set to 0. sending RAs containing PIO with Preferred Lifetime set to 0.
4.3.3. Controlling Source Address Selection With ICMPv6 5.3.3. Controlling Source Address Selection With ICMPv6
Now we look at how ICMPv6 messages can provide information back to Now we look at how ICMPv6 messages can provide information back to
H31. We assume again that at the time of the failure H31 is sending H31. We assume again that at the time of the failure H31 is sending
packets to H501 using (S=2001:db8:0:b010::31, packets to H501 using (S=2001:db8:0:b010::31,
D=2001:db8:0:5678::501). When the uplink from SERb1 to ISP-B fails, D=2001:db8:0:5678::501). When the uplink from SERb1 to ISP-B fails,
SERb1 would stop originating its source-prefix-scoped route for the SERb1 would stop originating its source-prefix-scoped route for the
default destination (S=2001:db8:0:b000::/52, D=::/0) as well as its default destination (S=2001:db8:0:b000::/52, D=::/0) as well as its
unscoped default destination route. With these routes no longer in unscoped default destination route. With these routes no longer in
the IGP, traffic with (S=2001:db8:0:b010::31, D=2001:db8:0:5678::501) the IGP, traffic with (S=2001:db8:0:b010::31, D=2001:db8:0:5678::501)
would end up at SERa based on the unscoped default destination route would end up at SERa based on the unscoped default destination route
skipping to change at page 34, line 35 skipping to change at page 35, line 35
address to be forwarded to ISP-A, SERa would drop it and send a address to be forwarded to ISP-A, SERa would drop it and send a
Destination Unreachable message with Code 5 (Source address failed Destination Unreachable message with Code 5 (Source address failed
ingress/egress policy) back to H31. H31 would then know to use ingress/egress policy) back to H31. H31 would then know to use
another source address for that destination and would try with another source address for that destination and would try with
(S=2001:db8:0:a010::31, D=2001:db8:0:5678::501). This would be (S=2001:db8:0:a010::31, D=2001:db8:0:5678::501). This would be
forwarded to SERa based on the source-prefix-scoped default forwarded to SERa based on the source-prefix-scoped default
destination route still being originated by SERa, and SERa would destination route still being originated by SERa, and SERa would
forward it to ISP-A. As discussed above, if we are willing to extend forward it to ISP-A. As discussed above, if we are willing to extend
ICMPv6, SERa can even tell H31 what source address it should use to ICMPv6, SERa can even tell H31 what source address it should use to
reach that destination. The expected host behaviour has been reach that destination. The expected host behaviour has been
discussed in Section 4.2.3. Potential issue with using ICMPv6 for discussed in Section 5.2.3. Potential issue with using ICMPv6 for
signalling source address issues back to hosts is that uplink to an signalling source address issues back to hosts is that uplink to an
ISP-B failure immediately invalidates source addresses from ISP-B failure immediately invalidates source addresses from
2001:db8:0:b000::/52 for all hosts which triggers a large number of 2001:db8:0:b000::/52 for all hosts which triggers a large number of
ICMPv6 being sent back to hosts - the same scalability/rate limiting ICMPv6 being sent back to hosts - the same scalability/rate limiting
issues discussed in Section 4.2.3 would apply. issues discussed in Section 5.2.3 would apply.
4.3.4. Summary Of Methods For Controlling Source Address Selection On 5.3.4. Summary Of Methods For Controlling Source Address Selection On
The Failure Of An Uplink The Failure Of An Uplink
It appears that DHCPv6 is not particularly well suited to quickly It appears that DHCPv6 is not particularly well suited to quickly
changing the source address used by a host in the event of the changing the source address used by a host in the event of the
failure of an uplink, which eliminates DHCPv6 from the list of failure of an uplink, which eliminates DHCPv6 from the list of
potential solutions. On the other hand Router Advertisements potential solutions. On the other hand Router Advertisements
provides a reliable mechanism to dynamically provide hosts with a provides a reliable mechanism to dynamically provide hosts with a
list of valid prefixes to use as source addresses as well as prevent list of valid prefixes to use as source addresses as well as prevent
particular prefixes to be used. While no additional new features are particular prefixes to be used. While no additional new features are
required to be implemented on hosts, routers need to be able to send required to be implemented on hosts, routers need to be able to send
skipping to change at page 35, line 24 skipping to change at page 36, line 24
Therefore it is highly desirable that hosts are able to select the Therefore it is highly desirable that hosts are able to select the
correct source address in case of uplinks failure with ICMPv6 being correct source address in case of uplinks failure with ICMPv6 being
an additional mechanism to signal unexpected failures back to hosts. an additional mechanism to signal unexpected failures back to hosts.
The current behavior of different host operating system when The current behavior of different host operating system when
receiving ICMPv6 Destination Unreachable message with code 5 (Source receiving ICMPv6 Destination Unreachable message with code 5 (Source
address failed ingress/egress policy) is not clear to the authors. address failed ingress/egress policy) is not clear to the authors.
Information from implementers, users, and testing would be quite Information from implementers, users, and testing would be quite
helpful in evaluating this approach. helpful in evaluating this approach.
4.4. Selecting Source Address Upon Failed Uplink Recovery 5.4. Selecting Source Address Upon Failed Uplink Recovery
The next logical step is to look at the scenario when a failed uplink The next logical step is to look at the scenario when a failed uplink
on SERb1 to ISP-B is coming back up, so hosts can start using source on SERb1 to ISP-B is coming back up, so hosts can start using source
addresses belonging to 2001:db8:0:b000::/52 again. addresses belonging to 2001:db8:0:b000::/52 again.
4.4.1. Controlling Source Address Selection With DHCPv6 5.4.1. Controlling Source Address Selection With DHCPv6
The mechanism to use DHCPv6 to instruct the hosts (H31 in our The mechanism to use DHCPv6 to instruct the hosts (H31 in our
example) to start using prefixes from ISP-B space (e.g. example) to start using prefixes from ISP-B space (e.g.
S=2001:db8:0:b010::31 for H31) to reach hosts on the Internet is S=2001:db8:0:b010::31 for H31) to reach hosts on the Internet is
quite similar to one discussed in Section 4.3.1 and shares the same quite similar to one discussed in Section 5.3.1 and shares the same
drawbacks. drawbacks.
4.4.2. Controlling Source Address Selection With Router Advertisements 5.4.2. Controlling Source Address Selection With Router Advertisements
Let's look at the scenario discussed in Section 4.3.2. If the Let's look at the scenario discussed in Section 5.3.2. If the
uplink(s) failure caused the complete withdrawal of prefixes from uplink(s) failure caused the complete withdrawal of prefixes from
2001:db8:0:b000::/52 address space by setting Preferred Lifetime 2001:db8:0:b000::/52 address space by setting Preferred Lifetime
value to 0, then the recovery of the link should just trigger new RA value to 0, then the recovery of the link should just trigger new RA
being sent with non-zero Preferred Lifetime. In another scenario being sent with non-zero Preferred Lifetime. In another scenario
discussed in Section 4.3.2, the SERb1 uplink to ISP-B failure leads discussed in Section 5.3.2, the SERb1 uplink to ISP-B failure leads
to disappearance of the (S=2001:db8:0:b000::/52, D=::/0) entry from to disappearance of the (S=2001:db8:0:b000::/52, D=::/0) entry from
the forwarding table scoped to S=2001:db8:0:b000::/52 and, in turn, the forwarding table scoped to S=2001:db8:0:b000::/52 and, in turn,
caused R3 to send RAs from LLA_B with Router Lifetime set to 0. The caused R3 to send RAs from LLA_B with Router Lifetime set to 0. The
recovery of the SERb1 uplink to ISP-B leads to recovery of the SERb1 uplink to ISP-B leads to
(S=2001:db8:0:b000::/52, D=::/0) scoped forwarding entry re- (S=2001:db8:0:b000::/52, D=::/0) scoped forwarding entry re-
appearance and instructs R3 that it should advertise itself as a appearance and instructs R3 that it should advertise itself as a
default router for ISP-B address space domain (send RAs from LLA_B default router for ISP-B address space domain (send RAs from LLA_B
with non-zero Router Lifetime). with non-zero Router Lifetime).
4.4.3. Controlling Source Address Selection With ICMP 5.4.3. Controlling Source Address Selection With ICMP
It looks like ICMPv6 provides a rather limited functionality to It looks like ICMPv6 provides a rather limited functionality to
signal back to hosts that particular source addresses have become signal back to hosts that particular source addresses have become
valid again. Unless the changes in the uplink state a particular valid again. Unless the changes in the uplink state a particular
(S,D) pair, hosts can keep using the same source address even after (S,D) pair, hosts can keep using the same source address even after
an ISP uplink has come back up. For example, after the uplink from an ISP uplink has come back up. For example, after the uplink from
SERb1 to ISP-B had failed, H31 received ICMPv6 Code 5 message (as SERb1 to ISP-B had failed, H31 received ICMPv6 Code 5 message (as
described in Section 4.3.3) and allegedly started using described in Section 5.3.3) and allegedly started using
(S=2001:db8:0:a010::31, D=2001:db8:0:5678::501) to reach H501. Now (S=2001:db8:0:a010::31, D=2001:db8:0:5678::501) to reach H501. Now
when the SERb1 uplink comes back up, the packets with that (S,D) pair when the SERb1 uplink comes back up, the packets with that (S,D) pair
are still routed to SERa1 and sent to the Internet. Therefore H31 is are still routed to SERa1 and sent to the Internet. Therefore H31 is
not informed that it should stop using 2001:db8:0:a010::31 and start not informed that it should stop using 2001:db8:0:a010::31 and start
using 2001:db8:0:b010::31 again. Unless SERa has a policy configured using 2001:db8:0:b010::31 again. Unless SERa has a policy configured
to drop packets (S=2001:db8:0:a010::31, D=2001:db8:0:5678::501) and to drop packets (S=2001:db8:0:a010::31, D=2001:db8:0:5678::501) and
send ICMPv6 back if SERb1 uplink to ISP-B is up, H31 will be unaware send ICMPv6 back if SERb1 uplink to ISP-B is up, H31 will be unaware
of the network topology change and keep using S=2001:db8:0:a010::31 of the network topology change and keep using S=2001:db8:0:a010::31
for Internet destinations, including H51. for Internet destinations, including H51.
One of the possible option may be using a scoped route with EXCLUSIVE One of the possible option may be using a scoped route with EXCLUSIVE
flag as described in Section 4.2.3. SERa1 uplink recovery would flag as described in Section 5.2.3. SERa1 uplink recovery would
cause (S=2001:db8:0:a000::/52, D=2001:db8:0:1234::/64) route to cause (S=2001:db8:0:a000::/52, D=2001:db8:0:1234::/64) route to
reappear in the routing table. In the absence of that route packets reappear in the routing table. In the absence of that route packets
to H101 which were sent to ISP-B (as ISP-A uplink was down) with to H101 which were sent to ISP-B (as ISP-A uplink was down) with
source addresses from 2001:db8:0:b000::/52. When the route re- source addresses from 2001:db8:0:b000::/52. When the route re-
appears SERb1 would reject those packets and sends ICMPv6 back as appears SERb1 would reject those packets and sends ICMPv6 back as
discussed in Section 4.2.3. Practically it might lead to scalability discussed in Section 5.2.3. Practically it might lead to scalability
issues which have been already discussed in Section 4.2.3 and issues which have been already discussed in Section 5.2.3 and
Section 4.4.3. Section 5.4.3.
4.4.4. Summary Of Methods For Controlling Source Address Selection Upon 5.4.4. Summary Of Methods For Controlling Source Address Selection Upon
Failed Uplink Recovery Failed Uplink Recovery
Once again DHCPv6 does not look like reasonable choice to manipulate Once again DHCPv6 does not look like reasonable choice to manipulate
source address selection process on a host in the case of network source address selection process on a host in the case of network
topology changes. Using Router Advertisement provides the flexible topology changes. Using Router Advertisement provides the flexible
mechanism to dynamically react to network topology changes (if mechanism to dynamically react to network topology changes (if
routers are able to use routing changes as a trigger for sending out routers are able to use routing changes as a trigger for sending out
RAs with specific parameters). ICMPv6 could be considered as a RAs with specific parameters). ICMPv6 could be considered as a
supporting mechanism to signal incorrect source address back to hosts supporting mechanism to signal incorrect source address back to hosts
but should not be considered as the only mechanism to control the but should not be considered as the only mechanism to control the
address selection in multihomed environments. address selection in multihomed environments.
4.5. Selecting Source Address When All Uplinks Failed 5.5. Selecting Source Address When All Uplinks Failed
One particular tricky case is a scenario when all uplinks have One particular tricky case is a scenario when all uplinks have
failed. In that case there is no valid source address to be used for failed. In that case there is no valid source address to be used for
any external destinations while it might be desirable to have intra- any external destinations while it might be desirable to have intra-
site connectivity. site connectivity.
4.5.1. Controlling Source Address Selection With DHCPv6 5.5.1. Controlling Source Address Selection With DHCPv6
From DHCPv6 perspective uplinks failure should be treated as two From DHCPv6 perspective uplinks failure should be treated as two
independent failures and processed as described in Section 4.3.1. At independent failures and processed as described in Section 5.3.1. At
this stage it is quite obvious that it would result in quite this stage it is quite obvious that it would result in quite
complicated policy table which needs to be explicitly configured by complicated policy table which needs to be explicitly configured by
administrators and therefore seems to be impractical. administrators and therefore seems to be impractical.
4.5.2. Controlling Source Address Selection With Router Advertisements 5.5.2. Controlling Source Address Selection With Router Advertisements
As discussed in Section 4.3.2 an uplink failure causes the scoped As discussed in Section 5.3.2 an uplink failure causes the scoped
default entry to disappear from the scoped forwarding table and 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 results intra-site connectivity is broken. One
skipping to change at page 38, line 13 skipping to change at page 39, line 13
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 adminstrator 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 roter which advertises
ULA prefixes as their default router. ULA prefixes as their default router.
4.5.3. Controlling Source Address Selection With ICMPv6 5.5.3. Controlling Source Address Selection With ICMPv6
In case of all uplinks failure all SERs will drop outgoing IPv6 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 4.3.3 discussed in Section 5.3.3
4.5.4. Summary Of Methods For Controlling Source Address Selection When 5.5.4. Summary Of Methods For Controlling Source Address Selection When
All Uplinks Failed All Uplinks Failed
Again, combining SADR with Router Advertisements seems to be the most Again, combining SADR with Router Advertisements seems to be the most
flexible and scalable way to control the source address selection on flexible and scalable way to control the source address selection on
hosts. hosts.
4.6. Summary Of Methods For Controlling Source Address Selection 5.6. Summary Of Methods For Controlling Source Address Selection
To summarize the scenarios and options discussed above: To summarize the scenarios and options discussed above:
While DHCPv6 allows administrators to manipulate source address While DHCPv6 allows administrators to manipulate source address
selection policy tables, this method has a number of significant selection policy tables, this method has a number of significant
disadvantages which eliminates DHCPv6 from a list of potential disadvantages which eliminates DHCPv6 from a list of potential
solutions: solutions:
1. It required hosts to support DHCPv6 and its extension (RFC7078); 1. It required hosts to support DHCPv6 and its extension (RFC7078);
skipping to change at page 40, line 5 skipping to change at page 41, line 5
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.
ICMPv6 Code 5 error message SHOULD be used to complement RA-based ICMPv6 Code 5 error message SHOULD be used to complement RA-based
solution to signal incorrect source address selection back to hosts, solution to signal incorrect source address selection back to hosts,
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].
4.7. Other Configuration Parameters 5.7. Other Configuration Parameters
4.7.1. DNS Configuration 5.7.1. DNS Configuration
In mutihomed envinronment each ISP might provide their own list of 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. E.g. in the topology show on Figure 3, ISP-A might
provide recursive DNS server H51 2001:db8:0:5555::51, while ISP-B provide recursive DNS server H51 2001:db8:0:5555::51, while ISP-B
might provide H61 2001:db8:0:6666::61 as a recursive DNS server. might provide H61 2001:db8:0:6666::61 as a recursive DNS server.
[RFC8106] defines IPv6 Router Advertisement options to allow IPv6 [RFC8106] defines IPv6 Router Advertisement options to allow IPv6
routers to advertise a list of DNS recursive server addresses and a routers to advertise a list of DNS recursive server addresses and a
DNS Search List to IPv6 hosts. Using RDNSS together with 'scoped' DNS Search List to IPv6 hosts. Using RDNSS together with 'scoped'
RAs as described above would allow a first-hop router (R3 in the RAs as described above would allow a first-hop router (R3 in the
Figure 3) to send DNS server addresses and search lists provided by Figure 3) to send DNS server addresses and search lists provided by
each ISP (or the corporate DNS servers addresses if the enterprise is each ISP (or the corporate DNS servers addresses if the enterprise is
running its own DNS servers). running its own DNS servers).
As discussed in Section 4.5.2, failure of all ISP uplinks would cause As discussed in Section 5.5.2, failure of all ISP uplinks would cause
deprecaction of all addresses assigned to a host from the address deprecaction of all addresses assigned to a host from the address
space if all ISPs. If any intra-site IPv6 connectivity is still space if 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 4.5.2. In network), then ULAs should be used as discussed in Section 5.5.2. In
such a scenario, the enterprise network should run its own recursive 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 4.5.2. send for ULA-scoped forwarding table as described in Section 5.5.2.
There are some scenarios when the final outcome of the name 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
skipping to change at page 41, line 24 skipping to change at page 42, line 24
It should be noted that [RFC8106] explicitly prohibits using DNS It should be noted that [RFC8106] explicitly prohibits using DNS
information if the RA router Lifetime expired: "An RDNSS address or a information if the RA router Lifetime expired: "An RDNSS address or a
DNSSL domain name MUST be used only as long as both the RA router DNSSL domain name MUST be used only as long as both the RA router
Lifetime (advertised by a Router Advertisement message) and the Lifetime (advertised by a Router Advertisement message) and the
corresponding option Lifetime have not expired.". Therefore hosts corresponding option Lifetime have not expired.". Therefore hosts
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.
5. 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 chages 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.
skipping to change at page 42, line 9 skipping to change at page 43, line 9
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.
6. Other Solutions 7. Other Solutions
6.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
host and exchange information about possible source and destination host and exchange information about possible source and destination
address pairs that they can use to communicate. It also specified address pairs that they can use to communicate. It also specified
the REAP protocol [RFC5534] to detect failures in the path between the REAP protocol [RFC5534] to detect failures in the path between
working address pairs and find new working address pairs. A working address pairs and find new working address pairs. A
fundamental requirement for Shim6 is that both internal and external fundamental requirement for Shim6 is that both internal and external
hosts need to support Shim6. That is, both the host internal to the hosts need to support Shim6. That is, both the host internal to the
multihomed site and the host external to the multihomed site need to multihomed site and the host external to the multihomed site need to
support Shim6 in order for there to be any benefit for the internal support Shim6 in order for there to be any benefit for the internal
host to run Shim6. The Shim6 protocol specification was published in host to run Shim6. The Shim6 protocol specification was published in
2009, but it has not been widely implemented. Therefore Shim6 is not 2009, but it has not been widely implemented. Therefore Shim6 is not
considered as a viable solution for enterprise multihoming. considered as a viable solution for enterprise multihoming.
6.2. IPv6-to-IPv6 Network Prefix Translation 7.2. IPv6-to-IPv6 Network Prefix Translation
IPv6-to-IPv6 Network Prefix Translation (NPTv6) [RFC6296] is not the 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 migth 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.
6.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 4 it would allow hosts to use multiple source addresses for a Section 5 it would allow hosts to use multiple source addresses for a
single connection and switch between source addresses when a 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 4 migth not be needed (it signalling solution described in Section 5 migth not be needed (it
should be noted that the Source Address Dependent Routing would still should be noted that the Source Address Dependent Routing would still
be required to delver packets to the correct uplinks). Unfortunatelt be required to delver packets to the correct uplinks). Unfortunatelt
when this document was written, mutlipath transport alone can not be when this document was written, mutlipath transport alone can not be
considered a solition for the problem of selecting the source address considered a solition for the problem of selecting the source address
in a multihomed envinronments. There are significant number of hosts in a multihomed envinronments. There are significant number of hosts
which do not use mulipath transport currently and it seems unlikely which do not use mulipath 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. As
the solution for enterprise multihoming needs to work for the least the 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 4, it could not be considered as a sole solution to the Section 5, it could not be considered as a sole solution to the
problem of source address selection in multihomed envinronments. problem of source address selection in multihomed envinronments.
7. IANA Considerations 8. IANA Considerations
This memo asks the IANA for no new parameters. This memo asks the IANA for no new parameters.
8. Security Considerations 9. Security Considerations
This document introduces no new security or privacy considerations. This document introduces no new security or privacy considerations.
Security considerations of using stateless address autoconfiguration Security considerations of using stateless address autoconfiguration
is discussed in [RFC4862]. is discussed in [RFC4862].
9. 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, Acee Lindem, Philip
Matthewsu, Robert Raszuk, Dave Thaler. Matthewsu, Robert Raszuk, Dave Thaler.
10. References 11. References
10.1. Normative References 11.1. Normative References
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, Communication Layers", STD 3, RFC 1122,
DOI 10.17487/RFC1122, October 1989, DOI 10.17487/RFC1122, October 1989,
<https://www.rfc-editor.org/info/rfc1122>. <https://www.rfc-editor.org/info/rfc1122>.
[RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts -
Application and Support", STD 3, RFC 1123, Application and Support", STD 3, RFC 1123,
DOI 10.17487/RFC1123, October 1989, DOI 10.17487/RFC1123, October 1989,
<https://www.rfc-editor.org/info/rfc1123>. <https://www.rfc-editor.org/info/rfc1123>.
skipping to change at page 45, line 33 skipping to change at page 46, line 33
[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
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200, (IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017, DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>. <https://www.rfc-editor.org/info/rfc8200>.
10.2. Informative References 11.2. Informative References
[I-D.baker-ipv6-isis-dst-src-routing] [I-D.baker-ipv6-isis-dst-src-routing]
Baker, F. and D. Lamparter, "IPv6 Source/Destination Baker, F. and D. Lamparter, "IPv6 Source/Destination
Routing using IS-IS", draft-baker-ipv6-isis-dst-src- Routing using IS-IS", draft-baker-ipv6-isis-dst-src-
routing-07 (work in progress), July 2017. routing-07 (work in progress), July 2017.
[I-D.baker-rtgwg-src-dst-routing-use-cases] [I-D.baker-rtgwg-src-dst-routing-use-cases]
Baker, F., Xu, M., Yang, S., and J. Wu, "Requirements and Baker, F., Xu, M., Yang, S., and J. Wu, "Requirements and
Use Cases for Source/Destination Routing", draft-baker- Use Cases for Source/Destination Routing", draft-baker-
rtgwg-src-dst-routing-use-cases-02 (work in progress), rtgwg-src-dst-routing-use-cases-02 (work in progress),
skipping to change at page 46, line 16 skipping to change at page 47, line 22
Boutier, M. and J. Chroboczek, "Source-Specific Routing in Boutier, M. and J. Chroboczek, "Source-Specific Routing in
Babel", draft-boutier-babel-source-specific-03 (work in Babel", draft-boutier-babel-source-specific-03 (work in
progress), July 2017. progress), July 2017.
[I-D.huitema-shim6-ingress-filtering] [I-D.huitema-shim6-ingress-filtering]
Huitema, C., "Ingress filtering compatibility for IPv6 Huitema, C., "Ingress filtering compatibility for IPv6
multihomed sites", draft-huitema-shim6-ingress- multihomed sites", draft-huitema-shim6-ingress-
filtering-00 (work in progress), September 2005. 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., and D. Schinazi, Pfister, P., Vyncke, E., Pauly, T., Schinazi, D., and W.
"Discovering Provisioning Domain Names and Data", draft- Shao, "Discovering Provisioning Domain Names and Data",
ietf-intarea-provisioning-domains-01 (work in progress), draft-ietf-intarea-provisioning-domains-02 (work in
February 2018. progress), June 2018.
[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-06 (work in
progress), October 2017. progress), October 2017.
[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.
 End of changes. 77 change blocks. 
138 lines changed or deleted 152 lines changed or added

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