Enterprise Multihoming using
Provider-Assigned Addresses without Network Prefix Translation:
Requirements and SolutionCisco SystemsSanta Barbara93117CaliforniaUSAfred@cisco.comJuniper NetworksSunnyvale94089CaliforniaUSAcbowers@juniper.netGoogleMountain View94043CaliforniaUSAfurry@google.com
Routing Area
Routing Working GroupConnecting an enterprise site to multiple ISPs using
provider-assigned addresses is difficult without the use of some form of
Network Address Translation (NAT). Much has been written on this topic
over the last 10 to 15 years, but it still remains a problem without a
clearly defined or widely implemented solution. Any multihoming solution
without NAT requires hosts at the site to have addresses from each ISP
and to select the egress ISP by selecting a source address for outgoing
packets. It also requires routers at the site to take into account those
source addresses when forwarding packets out towards the ISPs.This document attempts to define a complete solution to this problem.
It covers the behavior of routers to forward traffic taking into account
source address, and it covers the behavior of host to select appropriate
source addresses. It also covers any possible role that routers might
play in providing information to hosts to help them select appropriate
source addresses. In the process of exploring potential solutions, this
documents also makes explicit requirements for how the solution would be
expected to behave from the perspective of an enterprise site network
administrator .Site multihoming, the connection of a subscriber network to multiple
upstream networks using redundant uplinks, is a common enterprise
architecture for improving the reliability of its Internet connectivity.
If the site uses provider-independent (PI) addresses, all traffic
originating from the enterprise can use source addresses from the PI
address space. Site multihoming with PI addresses is commonly used with
both IPv4 and IPv6, and does not present any new technical
challenges.It may be desirable for an enterprise site to connect to multiple
ISPs using provider-assigned (PA) addresses, instead of PI addresses.
Multihoming with provider-assigned addresses is typically less expensive
for the enterprise relative to using provider-independent addresses. PA
multihoming is also a practice that should be facilitated and encouraged
because it does not add to the size of the Internet routing table,
whereas PI multihoming does. Note that PA is also used to mean
"provider-aggregatable". In this document we assume that
provider-assigned addresses are always provider-aggregatable.With PA multihoming, for each ISP connection, the site is assigned a
prefix from within an address block allocated to that ISP by its
National or Regional Internet Registry. In the simple case of two ISPs
(ISP-A and ISP-B), the site will have two different prefixes assigned to
it (prefix-A and prefix-B). This arrangement is problematic. First,
packets with the "wrong" source address may be dropped by one of the
ISPs. In order to limit denial of service attacks using spoofed source
addresses, BCP38 recommends that ISPs
filter traffic from customer sites to only allow traffic with a source
address that has been assigned by that ISP. So a packet sent from a
multihomed site on the uplink to ISP-B with a source address in prefix-A
may be dropped by ISP-B.However, even if ISP-B does not implement BCP38 or ISP-B adds
prefix-A to its list of allowed source addresses on the uplink from the
multihomed site, two-way communication may still fail. If the packet
with source address in prefix-A was sent to ISP-B because the uplink to
ISP-A failed, then if ISP-B does not drop the packet and the packet
reaches its destination somewhere on the Internet, the return packet
will be sent back with a destination address in prefix-A. The return
packet will be routed over the Internet to ISP-A, but it will not be
delivered to the multihomed site because its link with ISP-A has failed.
Two-way communication would require some arrangement for ISP-B to
advertise prefix-A when the uplink to ISP-A fails.Note that the same may be true with a provider that does not
implement BCP 38, if his upstream provider does, or has no corresponding
route. The issue is not that the immediate provider implements ingress
filtering; it is that someone upstream does, or lacks a route.With IPv4, this problem is commonly solved by using private address space within the multi-homed site and
Network Address Translation (NAT) or Network Address/Port Translation
(NAPT) on the uplinks to the ISPs. However, one of the goals of IPv6 is
to eliminate the need for and the use of NAT or NAPT. Therefore,
requiring the use of NAT or NAPT for an enterprise site to multihome
with provider-assigned addresses is not an attractive solution. describes a translation solution
specifically tailored to meet the requirements of multi-homing with
provider-assigned IPv6 addresses. With the IPv6-to-IPv6 Network Prefix
Translation (NPTv6) solution, within the site an enterprise can use
Unique Local Addresses or the prefix assigned
by one of the ISPs. As 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 on that uplink in a predictable and reversible
manner. is currently classified as
Experimental, and it has been implemented by several vendors. See , for more discussion of NPTv6.This document defines routing requirements for enterprise multihoming
using provider-assigned IPv6 addresses. We have made no attempt to write
these requirements in a manner that is agnostic to potential solutions.
Instead, this document focuses on the following general class of
solutions.Each host at the enterprise has multiple addresses, at least one from
each ISP-assigned prefix. Each host, as discussed in and ,
is responsible for choosing the source address applied 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 with the source
address corresponding to that ISP. Potential mechanisms for the
communication of changes in the network to the host are Neighbor
Discovery Router Advertisements, DHCPv6, and ICMPv6.The routers in the enterprise network are responsible for ensuring
that packets are delivered to the "correct" ISP uplink based on source
address. This requires that at least some routers in the site network
are able to take into account the source address of a packet when
deciding how to route it. That is, some routers must be capable of some
form of Source Address Dependent Routing (SADR), if only as described in
. At a minimum, the routers connected to the ISP
uplinks (the site exit routers or SERs) must be capable of Source
Address Dependent Routing. Expanding the connected domain of routers
capable of SADR from the site exit routers deeper into the site network
will generally result in more efficient routing of traffic with external
destinations.The document first looks in more detail at the enterprise networking
environments in which this solution is expected to operate. It then
discusses existing and proposed mechanisms for hosts to select the
source address applied to packets. Finally, it looks at the requirements
for routing that are needed to support these enterprise network
scenarios and the mechanisms by which hosts are expected to select
source addresses dynamically based on network state.We start by looking at a scenario in which a site has connections
to two ISPs, as shown in . The
site is assigned the prefix 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 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: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 subnet that has been assigned 2001:db8:0:a020::/64 and
2001:db8:0:b020::/64.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
internal hosts (H31, H32, and H41), as well as connecting the internal
hosts to the Internet through SERa and SERb. In this example SERa and
SERb share a direct connection to each other. In , we consider a scenario where this
is not the case.For the moment, we assume that the hosts are able to make good
choices about which source addresses through some mechanism that
doesn't involve the routers in the site network. Here, we focus on
primary task of the routed site network, which is to get packets
efficiently to their destinations, while sending a packet to the ISP
that assigned the prefix that matches the source address of the
packet. In , we examine what role
the routed network may play in helping hosts make good choices about
source addresses for packets.With this solution, routers will need form of Source Address
Dependent Routing, which will be new functionality. It would be useful
if an enterprise site does not need to upgrade all routers to support
the new SADR functionality in order to support PA multi-homing. We
consider if this is possible and what are the tradeoffs of not having
all routers in the site support SADR functionality.In the topology in , it is
possible to support PA multihoming with only SERa and SERb being
capable of SADR. The other routers can continue to forward based only
on destination address, and exchange routes that only consider
destination address. In this scenario, SERa and SERb communicate
source-scoped routing information across their shared connection. When
SERa receives a packet with a source address matching prefix
2001:db8:0:b000::/52 , it forwards the packet to SERb, which forwards
it on the uplink to ISP-B. The analogous behaviour holds for traffic
that SERb receives with a source address matching prefix
2001:db8:0:a000::/52.In , when only SERa and SERb
are capable of source address dependent routing, PA multi-homing will
work. However, the paths over which the packets are sent will
generally not be the shortest paths. The forwarding paths will
generally be more efficient as more routers are capable of SADR. For
example, if R4, R2, and R6 are upgraded to support SADR, then can
exchange source-scoped routes with SERa and SERb. They will then know
to send traffic with a source address matching prefix
2001:db8:0:b000::/52 directly to SERb, without sending it to SERa
first.In , we modify the topology
slightly by inserting R7, so that 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 support PA multi-homing. There are two
solutions to ways to enable PA multihoming in this topology.One option is to effectively modify the topology by creating a
logical tunnel between SERa and SERb, using GRE for example. Although
SERa and SERb are not directly connected physically in this topology,
they can be directly connected logically by a tunnel.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 three routers act as a single SADR domain. This illustrates the
basic principle that the minimum requirement for the routed site
network to support PA multi-homing is having all of the site exit
routers be part of a connected SADR domain. Extending the connected
SADR domain beyond that point can produce more efficient forwarding
paths.Before considering a more complex scenario, let's look in more
detail at the reasonably simple multihoming scenario in to understand what can reasonably
be expected from this solution. As a general guiding principle, we
assume an enterprise network operator will expect a multihomed network
to behave as close as to a single-homed network as possible. So a
solution that meets those expectations where possible is a good
thing.For traffic between internal hosts and traffic from outside the
site to internal hosts, an enterprise network operator would expect
there to be no visible change in the path taken by this traffic, since
this traffic does not need to be routed in a way that depends on
source address. It is also reasonable to expect that internal hosts
should be able to communicate with each other using either of their
source addresses without restriction. For example, H31 should be able
to communicate with H41 using a packet with S=2001:db8:0:a010::31,
D=2001:db8:0:b010::41, regardless of the state of uplink to ISP-B.These goals can be accomplished by having all of the routers in the
network continue to originate normal unscoped destination routes for
their connected networks. If we can arrange so that these unscoped
destination routes get used for forwarding this traffic, then we will
have accomplished the goal of keeping forwarding of traffic destined
for internal hosts, unaffected by the multihoming solution.For traffic destined for external hosts, it is reasonable to expect
that traffic with an source address from the prefix assigned by ISP-A
to follow the path to that the traffic would follow if there is no
connection to ISP-B. This can be accomplished by having SERa originate
a source-scoped route of the form (S=2001:db8:0:a000::/52, D=::/0) .
If all of the routers in the site support SADR, then the path of
traffic exiting via ISP-A can match that expectation. If some routers
don't support SADR, then it is reasonable to expect that the path for
traffic exiting via ISP-A may be different within the site. This is a
tradeoff that the enterprise network operator may decide to make.It is important to understand how this multihoming solution behaves
when an uplink to one of the ISPs fails. To simplify this discussion,
we assume that all routers in the site support SADR. We first start by
looking at how the network operates when the uplinks to both ISP-A and
ISP-B are functioning properly. SERa originates a source-scoped route
of the form (S=2001:db8:0:a000::/52, D=::/0), and SERb is originates a
source-scoped route of the form (S=2001:db8:0:b000::/52, D=::/0).
These routes are distributed through the routers in the site, and they
establish within the routers two set of forwarding paths for traffic
leaving the site. One set of forwarding paths is for packets with
source address in 2001:db8:0:a000::/52. The other set of forwarding
paths is for packets with source address in 2001:db8:0:b000::/52. The
normal destination routes which are not scoped to these two source
prefixes play no role in the forwarding. Whether a packet exits the
site via SERa or via SERb is completely determined by the source
address applied to the packet by the host. So for example, when host
H31 sends a packet to host H101 with (S=2001:db8:0:a010::31,
D=2001:db8:0:1234::101), the packet will only be sent out the link
from SERa to ISP-A.Now consider what happens when the uplink from SERa to ISP-A fails.
The only way for the packets from H31 to reach H101 is for H31 to
start using the source address for ISP-B. H31 needs to send the
following packet: (S=2001:db8:0:b010::31, D=2001:db8:0:1234::101).This behavior is very different from the behavior that occurs with
site multihoming using PI addresses or with PA addresses using NAT. In
these other multi-homing solutions, hosts do not need to react to
network failures several hops away in order to regain Internet access.
Instead, a host can be largely unaware of the failure of an uplink to
an ISP. When multihoming with PA addresses and NAT, existing sessions
generally need to be re-established after a failure since the external
host will receive packets from the internal host with a new source
address. However, new sessions can be established without any action
on the part of the hosts.Another example where the behavior of this multihoming solution
differs significantly from that of multihoming with PI address or with
PA addresses using NAT is in the ability of the enterprise network
operator to route traffic over different ISPs based on destination
address. We still consider the fairly simple network of and assume that uplinks to both
ISPs are functioning. Assume that the site is multihomed using PA
addresses and NAT, and that SERa and SERb each originate a normal
destination route for D=::/0, with the route origination dependent on
the state of the uplink to the respective ISP.Now suppose it is observed that an important application running
between internal hosts and external host H101 experience much better
performance when the traffic passes through ISP-A (perhaps because
ISP-A provides lower latency to H101.) When multihoming this site with
PI addresses or with PA addresses and NAT, the enterprise network
operator can configure SERa to originate into the site network a
normal destination route for D=2001:db8:0:1234::/64 (the destination
prefix to reach H101) that depends on the state of the uplink to
ISP-A. When the link to ISP-A is functioning, the destination route
D=2001:db8:0:1234::/64 will be originated by SERa, so traffic from all
hosts will use ISP-A to reach H101 based on the longest destination
prefix match in the route lookup.Implementing the same routing policy is more difficult with the PA
multihoming solution described in this document since it doesn't use
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 cannot modify the source address without NAT, the host must
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
destined for H101. Mechanisms have been proposed to allow hosts to
choose the source address for packets in a fine grained manner. We
will discuss these proposals in .
However, interacting with host operating systems in some manner to
ensure a particular source address is chosen for a particular
destination prefix is not what an enterprise network administrator
would expect to have to do to implement this routing policy.The previous sections considered two variations of a simple
multihoming scenario where the site is connected to two ISPs offering
only Internet connectivity. It is likely that many actual enterprise
multihoming scenarios will be similar to this simple example. However,
there are more complex multihoming scenarios that we would like this
solution to address as well.It is fairly common for an ISP to offer a service in addition to
Internet access over the same uplink. Two variation of this are
reflected in . In addition to Internet
access, ISP-A offers a service which requires the site to access host
H51 at 2001:db8:0:5555::51. The site has a single physical and logical
connection with ISP-A, and ISP-A only allows access to H51 over that
connection. So when H32 needs to access the service at H51 it needs to
send packets with (S=2001:db8:0:a010::32, D=2001:db8:0:5555::51) and
those packets need to be forward out the link from SERa to ISP-A.ISP-B illustrates a variation on this scenario. In addition to
Internet access, ISP-B also offers a service which requires the site
to access host H61. The site has two connections to two different
parts of ISP-B (shown as SERb1 and SERb2 in ). ISP-B expects Internet traffic to use the
uplink from SERb1, while it expects it expects traffic destined for
the service at H61 to use the uplink from SERb2. For either uplink,
ISP-B expects the ingress traffic to have a source address matching
the prefix it assigned to the site, 2001:db8:0:b000::/52.As discussed before, we rely completely on the internal host to set
the source address of the packet properly. In the case of a packet
sent by H31 to access the service in ISP-B at H61, we expect the
packet to have the following addresses: (S=2001:db8:0:b010::31,
D=2001:db8:0:6666::61). The routed network has two potential ways of
distributing routes so that this packet exits the site on the uplink
at SERb2.We could just rely on normal destination routes, without using
source-prefix scoped routes. If we have SERb2 originate a normal
unscoped destination route for D=2001:db8:0:6666::/64, the packets
from H31 to H61 will exit the site at SERb2 as desired. We should not
have to worry about SERa needing to originate the same route, because
ISP-B should choose a globally unique prefix for the service at
H61.The alternative is to have SERb2 originate a source-prefix-scoped
destination route of the form (S=2001:db8:0:b000::/52,
D=2001:db8:0:6666::/64). From a forwarding point of view, the use of
the source-prefix-scoped destination route would result in traffic
with source addresses corresponding only to ISP-B being sent to SERb2.
Instead, the use of the unscoped destination route would result in
traffic with source addresses corresponding to ISP-A and ISP-B being
sent to SERb2, as long as the destination address matches the
destination prefix. It seems like either forwarding behavior would be
acceptable.However, from the point of view of the enterprise network
administrator trying to configure, maintain, and trouble-shoot this
multihoming solution, it seems much clearer to have SERb2 originate
the source-prefix-scoped destination route correspond to the service
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 traffic
within the site or arriving from external hosts is determined by the
unscoped destination routes. Therefore, for this multihoming solution
we choose to originate source-prefix-scoped routes for all traffic
leaving the site.While we expect that most site multihoming involves connecting to
only two ISPs, this solution allows for connections to an arbitrary
number of ISPs to be supported. However, when evaluating scalable
implementations of the solution, it would be reasonable to assume 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
different ISPs will not overlap. This must be the case , since the
provider-assigned addresses have to be globally unique.The topologies of many enterprise sites using this multihoming
solution may in practice be simpler than the examples that we have
used. The topology in could be
further simplified by having all hosts directly connected to the LAN
connecting the two site exit 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 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 topologies, so this draft focuses on providing
a solution to the more general case. The simplified cases will also be
supported by this solution, and there may even be optimizations that
can be made for simplified cases. This solution however needs to
support more complex topologies.We are starting with the basic assumption that enterprise site
networks can be quite complex from a routing perspective. However,
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
enterprise network operator to change the routing topology of the site
in order to deploy IPv6.So far we have described in general terms how the routers in this
solution that are capable of Source Address Dependent Routing will
forward traffic using both normal unscoped destination routes and
source-prefix-scoped destination routes. Here we give a precise method
for generating a source-prefix-scoped forwarding table on a router that
supports SADR.Compute the next-hops for the source-prefix-scoped destination
prefixes using only routers in the connected SADR domain. These are
the initial source-prefix-scoped forwarding table entries.Compute the next-hops for the unscoped destination prefixes using
all routers in the IGP. This is the unscoped forwarding table.Augment each source-prefix-scoped forwarding table with unscoped
forwarding table entries based on the following rule. If the
destination prefix of the unscoped forwarding entry exactly matches
the destination prefix of an existing source-prefix-scoped
forwarding entry (including destination prefix length), then do not
add the unscoped forwarding entry. If the destination prefix does
NOT match an existing entry, then add the entry to the
source-prefix-scoped forwarding table.The forward tables produced by this process are used in the following
way to forward packets. If the source address of the packet matches one of the source
prefixes, then look up the destination address of the packet in the
corresponding source-prefix-scoped forwarding table to determine the
next-hop for the packet.If the source address of the packet does NOT match one of the
source prefixes, then look up the destination address of the packet
in unscoped forwarding table to determine the next-hop for the
packet.The following example illustrates how this process is used to create
a forwarding table for each provider-assigned source prefix. We consider
the multihomed site network in .
Initially we assume that all of the routers in the site network support
SADR. shows the routes that are
originated by the routers in the site network.Each SER originates destination routes which are scoped to the source
prefix assigned by the ISP that the SER connects to. Note that the SERs
also originate the corresponding unscoped destination route. This is not
needed when all of the routers in the site support SADR. However, it is
required when some routers do not support SADR. This will be discussed
in more detail later.We focus on how R8 constructs its source-prefix-scoped forwarding
tables from these route advertisements. R8 computes the next hops for
destination routes which are scoped to the source prefix
2001:db8:0:a000::/52. The results are shown in the first table in . (In this example, the next hops are
computed assuming that all links have the same metric.) Then, R8
computes the next hops for destination routes which are scoped to the
source prefix 2001:db8:0:b000::/52. The results are shown in the second
table in . Finally, R8 computes
the next hops for the unscoped destination prefixes. The results are
shown in the third table in .The final step is for R8 to augment the source-prefix-scoped
forwarding entries with unscoped forwarding entries. If an unscoped
forwarding entry has the exact same destination prefix as an
source-prefix-scoped forwarding entry (including destination prefix
length), then the source-prefix-scoped forwarding entry wins.As as an example of how the source scoped forwarding entries are
augmented with unscoped forwarding entries, we consider how the two
entries in the first table in
(the table for source prefix = 2001:db8:0:a000::/52) are augmented with
entries from the third table in
(the table of unscoped forwarding entries). The first four unscoped
forwarding entries (D=2001:db8:0:a010::/64, D=2001:db8:0:b010::/64,
D=2001:db8:0:a020::/64, and D=2001:db8:0:b020::/64) are not an exact
match for any of the existing entries in the forwarding table for source
prefix 2001:db8:0:a000::/52. Therefore, these four entries are added to
the final forwarding table for source prefix 2001:db8:0:a000::/52. The
result of adding these entries is reflected in first four entries the
first table in .The next unscoped forwarding table entry is for
D=2001:db8:0:5555::/64. This entry is an exact match for the existing
entry in the forwarding table for source prefix 2001:db8:0:a000::/52.
Therefore, we do not replace the existing entry with the entry from the
unscoped forwarding table. This is reflected in the fifth entry in the
first table in . (Note that since
both scoped and unscoped entries have R7 as the next hop, the result of
applying this rule is not visible.)The next unscoped forwarding table entry is for
D=2001:db8:0:6666::/64. This entry is not an exact match for any
existing entries in the forwarding table for source prefix
2001:db8:0:a000::/52. Therefore, we add this entry. This is reflected in
the sixth entry in the first table in .The next unscoped forwarding table entry is for D=::/0. This entry is
an exact match for the existing entry in the forwarding table for source
prefix 2001:db8:0:a000::/52. Therefore, we do not overwrite the existing
source-prefix-scoped entry, as can be seen in the last entry in the
first table in .The forwarding tables produced by this process at R8 have the desired
properties. A packet with a source address in 2001:db8:0:a000::/52 will
be forwarded based on the first table in . If the packet is destined for the
Internet at large or the service at D=2001:db8:0:5555/64, it will be
sent to R7 in the direction of SERa. If the packet is destined for an
internal host, then the first four entries will send it to R2 or R5 as
expected. Note that if this packet has a destination address
corresponding to the service offered by ISP-B (D=2001:db8:0:5555::/64),
then it will get forwarded to SERb2. It will be dropped by SERb2 or by
ISP-B, since it the packet has a source address that was not assigned by
ISP-B. However, this is expected behavior. In order to use the service
offered by ISP-B, the host needs to originate the packet with a source
address assigned by ISP-B.In this example, a packet with a source address that doesn't match
2001:db8:0:a000::/52 or 2001:db8:0:b000::/52 must have originated from
an external host. Such a packet will use the unscoped forwarding table
(the last table in ). These
packets will flow exactly as they would in absence of multihoming.We can also modify this example to illustrate how it supports
deployments where not all routers in the site support SADR. Continuing
with the topology shown in , suppose
that R3 and R5 do not support SADR. Instead they are only capable of
understanding unscoped route advertisements. The SADR routers in the
network will still originate the routes shown in . However, R3 and R5 will only
understand the unscoped routes as shown in .With these unscoped route advertisements, R5 will produce the
forwarding table shown in .Any traffic that needs to exit the site will eventually hit a
SADR-capable router. Once that traffic enters the SADR-capable domain,
then it will not leave that domain until it exits the site. This
property is required in order to guarantee that there will not be
routing loops involving SADR-capable and non-SADR-capable routers.Note that the mechanism described here for converting
source-prefix-scoped destination prefix routing advertisements into
forwarding state is somewhat different from that proposed in . The method described in this
document is intended to be easy to understand for network enterprise
operators while at the same time being functionally correct. Another
difference is that the method in this document assumes that source
prefix will not overlap. Other differences between the two approaches
still need to be understood and reconciled.An interesting side-effect of deploying SADR is if all routers in a
given network support SADR and have a scoped forwarding table, then the
unscoped forwarding table can be eliminated which ensures that packets
with legitimate source addresses only can leave the network (as there
are no scoped forwarding tables for spoofed/bogon source addresses). It
would prevent accidental leaks of ULA/reserved/link-local sources to the
Internet as well as ensures that no spoofing is possible from the
SADR-enabled network.Until this point, we have made the assumption that hosts are able to
choose the correct source address using some unspecified mechanism. 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 ISP based
on source address. Now we look at possible mechanisms for hosts to
choose the correct source address. We also look at what role, if any,
the routers may play in providing information that helps hosts to choose
source addresses.Any host that needs to be able to send traffic using the uplinks to a
given ISP is expected to be configured with an address from the prefix
assigned by that ISP. The host will control which ISP is used for its
traffic by selecting one of the addresses configured on the host as the
source address for outgoing traffic. It is the responsibility of the
site network to ensure that a packet with the source address from an ISP
is not sent on an uplink to that ISP.If all of the ISP uplinks are working, the choice of source address
by the host may be driven by the desire to load share across ISP
uplinks, or it may be driven by the desire to take advantage of certain
properties of a particular uplink or ISP. If any of the ISP uplinks is
not working, then the choice of source address by the host can determine
if packets get dropped.How a host should make good decisions about source address selection
in a multihomed site is not a solved problem. We do not attempt to solve
this problem in this document. Instead we discuss the current state of
affairs with respect to standardized solutions and implementation of
those solutions. We also look at proposed solutions for this
problem.An external host initiating communication with a host internal to a
PA multihomed site will need to know multiple addresses for that host in
order to communicate with it using different ISPs to the multihomed
site. These addresses are typically learned through DNS. (For
simplicity, we assume that the external host is single-homed.) The
external host chooses the ISP that will be used at the remote multihomed
site by setting the destination address on the packets it transmits. For
a sessions originated from an external host to an internal host, the
choice of source address used by the internal host is simple. The
internal host has no choice but to use the destination address in the
received packet as the source address of the transmitted packet.For a session originated by a host internal to the multi-homed site,
the decision of what source address to select is more complicated. We
consider three main methods for hosts to get information about the
network. The two proactive methods are Neighbor Discovery Router
Advertisements and DHCPv6. The one reactive method we consider is
ICMPv6. Note that we are explicitly excluding the possibility of having
hosts participate in or even listen directly to routing protocol
advertisements.First we look at how a host is currently expected to select the
source and destination address with which it sends a packet. defines the algorithms that hosts are
expected to use to select source and destination addresses for
packets. It defines an algorithm for selecting a source address and a
separate algorithm for selecting a destination address. Both of these
algorithms depend on a policy table. defines
a default policy which produces certain behavior.The rules in the two algorithms in depend
on many different properties of addresses. While these are needed for
understanding how a host should choose addresses in an arbitrary
environment, most of the rules are not relevant for understanding how
a host should choose among multiple source addresses in mulitihomed
envinronment when sending a
packet to a remote host. Returning to the example in , we look at what the default algorithms in
say about the source address that internal
host H31 should use to send traffic to external host H101, somewhere
on the Internet. Let's look at what rules in
are actually used by H31 in this case.There is no choice to be made with respect to destination address.
H31 needs to send a packet with D=2001:db8:0:1234::101 in order to
reach H101. So H31 have to choose between using S=2001:db8:0:a010::31
or S=2001:db8:0:b010::31 as the source address for this packet. We go
through the rules for source address selection in Section 5 of . Rule 1 (Prefer same address) is not useful to
break the tie between source addresses, because neither the candidate
source addresses equals the destination address. Rule 2 (Prefer
appropriate scope) is also not used in this scenario, because both
source addresses and the destination address have global scope.Rule 3 (Avoid deprecated addresses) applies to an address that has
been autoconfigured by a host using stateless address
autoconfiguration as defined in . An address
autoconfigured by a host has a preferred lifetime and a valid
lifetime. The address is preferred until the preferred lifetime
expires, after which it becomes deprecated. A deprecated address is not
used if there is a preferred address of the appropriate scope available.
When the valid lifetime expires, the address cannot be used at all. The
preferred and valid lifetimes for an autoconfigured address are set
based on the corresponding lifetimes in the Prefix Information Option
in Neighbor Discovery Router Advertisements. So a possible tool to
control source address selection in this scenario would be for a host
to make an address deprecated by having routers on that link, R1 and
R2 in , send a Router Advertisement message
contaning a Prefix Information Option for the source prefix to be
discouraged (or prohibited) with the preferred lifetime set to zero.
This is a rather blunt tool, because it discourages or prohibits the use
of that source prefix for all destinations. However, it may be useful in some scenarios.
For example, if all uplinks to a particular ISP fail, it is desirable to prevent hosts from
using source addresses from that ISP address space.
Rule 4 (Avoid home addresses) does not apply here because we are
not considering Mobile IP.Rule 5 (Prefer outgoing interface) is not useful in this scenario,
because both source addresses are assigned to the same interface.Rule 5.5 (Prefer addresses in a prefix advertised by the next-hop) is not
useful in the scenario when both R1 and R2 will advertise both source
prefixes. However potentially this rule may allow a host to select the
correct source prefix by selecting a next-hop. The most obvious way
would be to make R1 to advertise itself as a default router and send
PIO for 2001:db8:0:a010::/64, while R2 is advertising itself as a
default router and sending PIO for 2001:db8:0:b010::/64. We'll discuss
later how Rule 5.5 can be used to influence a source address selection
in single-router topologies (e.g. when H41 is sending traffic using R3
as a default gateway).Rule 6 (Prefer matching label) refers to the Label value determined
for each source and destination prefix as a result of applying the
policy table to the prefix. With the default policy table defined in
Section 2.1 of , Label(2001:db8:0:a010::31) =
5, Label(2001:db8:0:b010::31) = 5, and Label(2001:db8:0:1234::101) =
5. So with the default policy, Rule 6 does not break the tie. However,
the algorithms in are defined in such as way
that non-default address selection policy tables can be used. defines a way to distribute a non-default address
selection policy table to hosts using DHCPv6. So even though the
application of rule 6 to this scenario using the default policy table
is not useful, rule 6 may still be a useful tool.Rule 7 (Prefer temporary addresses) has to do with the technique
described in to periodically randomize the
interface portion of an IPv6 address that has been generated using
stateless address autoconfiguration. In general, if H31 were using
this technique, it would use it for both source addresses, for example
creating temporary addresses 2001:db8:0:a010:2839:9938:ab58:830f and
2001:db8:0:b010:4838:f483:8384:3208, in addition to
2001:db8:0:a010::31 and 2001:db8:0:b010::31. So this rule would prefer
the two temporary addresses, but it would not break the tie between
the two source prefixes from ISP-A and ISP-B.Rule 8 (Use longest matching prefix) dictates that between two
candidate source addresses the one which has longest common prefix
length with the destination address. For example, if H31 were
selecting the source address for sending packets to H101, this rule
would not be a tie breaker as for both candidate source addresses
2001:db8:0:a101::31 and 2001:db8:0:b101::31 the common prefix length
with the destination is 48. However if H31 were selecting the source
address for sending packets H41 address 2001:db8:0:a020::41, then this
rule would result in using 2001:db8:0:a101::31 as a source
(2001:db8:0:a101::31 and 2001:db8:0:a020::41 share the common prefix
2001:db8:0:a000::/58, while for `2001:db8:0:b101::31 and
2001:db8:0:a020::41 the common prefix is 2001:db8:0:a000::/51).
Therefore rule 8 might be useful for selecting the correct source
address in some but not all scenarios (for example if ISP-B services
belong to 2001:db8:0:b000::/59 then H31 would always use
2001:db8:0:b010::31 to access those destinations).So we can see that of the 8 source selection address rules from
, five actually apply to our basic site
multihoming scenario. The rules that are relevant to this scenario are
summarized below.Rule 3: Avoid deprecated addresses.Rule 5.5: Prefer addresses in a prefix advertised by the
next-hop.Rule 6: Prefer matching label.Rule 8: Prefer longest matching prefix.The two methods that we discuss for controlling the source address
selection through the four relevant rules above are SLAAC Router
Advertisement messages and DHCPv6.We also consider a possible role for ICMPv6 for getting
traffic-driven feedback from the network. With the source address
selection algorithm discussed above, the goal is to choose the correct
source address on the first try, before any traffic is sent. However,
another strategy is to choose a source address, send the packet, get
feedback from the network about whether or not the source address is
correct, and try another source address if it is not.We consider four scenarios where a host needs to select the correct
source address. The first is when both uplinks are working. The 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 both (all)
uplinks.Again we return to the topology in . Suppose that the site 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, H31 needs to select
S=2001:db8:0:a010::31.This policy can be implemented by using DHCPv6 to distribute an
address selection policy table that assigns the same label 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
entries accomplish this.This requires that the hosts implement ,
the basic source and destination address framework, along with , the DHCPv6 extension for distributing a
non-default policy table. Note that it does NOT require that the
hosts use DHCPv6 for address assignment. The hosts could still use
stateless address autoconfiguration for address configuration, while
using DHCPv6 only for policy table distribution (see ). However this method has a number of
disadvantages: DHCPv6 support is not a mandatory requirement for IPv6 hosts,
so this method might not work for all devices.Network administrators are required to explicitly configure
the desired network access policies on DHCPv6 servers.Neighbor Discovery currently has two mechanisms to communicate
prefix information to hosts. The base specification for Neighbor
Discovery (see ) defines the Prefix
Information Option (PIO) in the 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 from which it assigns itself an
IP address using stateless address autoconfiguration (SLAAC)
procedures described in . In the example of
, if the site network is using
SLAAC, we would expect both R1 and R2 to send RA messages with PIOs
for both source prefixes 2001:db8:0:a010::/64 and
2001:db8:0:b010::/64 with the A-flag set. H31 would then use the
SLAAC procedure to configure itself with the 2001:db8:0:a010::31 and
2001:db8:0:b010::31.Whereas a host learns about source prefixes from PIO messages,
hosts can learn about a destination prefix from a Router
Advertisement containing Route Information Option (RIO), as
specified in . The destination prefixes in
RIOs are intended to allow a host to choose the router that it uses
as its first hop to reach a particular destination prefix.As currently standardized, neither PIO nor RIO options contained
in Neighbor Discovery Router Advertisements can communicate the
information needed to implement the desired routing policy. PIO's
communicate source prefixes, and RIO communicate destination
prefixes. However, there is currently no standardized way to
directly associate a particular destination prefix with a particular
source prefix. proposes a Source
Address Dependent Route Information option for Neighbor Discovery
Router Advertisements which would associate a source prefix and with
a destination prefix. The details of might need tweaking to address
this use case. However, in order to be able to use Neighbor
Discovery Router Advertisements to implement this routing policy, an
extension that allows a R1 and R2 to explicitly communicate to H31
an association between S=2001:db8:0:a000::/52 D=2001:db8:0:1234::/64
would be needed.However, Rule 5.5 of the source address selection algorithm (discussed
in above),
together with default router preference (specified in ) and RIO can be used to influence a source
address selection on a host as described below. Let's look at source
address selection on the host H41. It receives RAs from R3 with PIOs
for 2001:db8:0:a020::/64 and 2001:db8:0:b020::/64. At that point all
traffic would use the same next-hop (R3 link-local address) so Rule
5.5 does not apply. Now let's assume that R3 supports SADR and has
two scoped forwarding tables, one scoped to S=2001:db8:0:a000::/52
and another scoped to S=2001:db8:0:b000::/52. If R3 generates two
different link-local addresses for its interface facing H41 (one for
each scoped forwarding table, LLA_A and LLA_B) and starts sending
two different RAs: one is sent from LLA_A and includes PIO for
2001:db8:0:a020::/64, another us sent from LLA_B and includes PIO
for 2001:db8:0:b020::/64. Now it is possible to influence H41 source
address selection for destinations which follow the default route by
setting default router preference in RAs. If it is desired that H41
reaches H101 (or any destinations in the Internet) via ISP-A, then
RAs sent from LLA_A should have default router preference set to 01
(high priority), while RAs sent from LLA_B should have preference
set to 11 (low). Then LLA_A would be chosen as a next-hop for H101
and therefore (as per rule 5.5) 2001:db8:0:a020::41 would be
selected as the source address. If, at the same time, it is desired
that H61 is accessible via ISP-B then R3 should include a RIO for
2001:db8:0:6666::/64 to its RA sent from LLA_B. H41 would chose
LLA_B as a next-hop for all traffic to H61 and then as per Rule 5.5,
2001:db8:0:b020::41 would be selected as a source address.If in the above mentioned scenario it is desirable that all
Internet traffic leaves the network via ISP-A and the link to ISP-B
is used for accessing ISP-B services only (not as ISP-A link
backup), then RAs sent by R3 from LLA_B should have Router Lifetime
set to 0 and should include RIOs for ISP-B address space. It would
instruct H41 to use LLA_A for all Internet traffic but use LLA_B as
a next-hop while sending traffic to ISP-B addresses.The description of the mechanism above assumes SADR support by the
first-hop routers as well as SERs. However, a first-hop router can still
provide a less flexible version of this mechanism even without
implementing SADR. This could be done by providing configuration knobs on the
first-hop router that allow it to generate different link-local addresses
and to send individual RAs for each prefix.
The mechanism described above relies on Rule 5.5 of the
default source address selection algorithm defined in .
recommends that a host SHOULD select default routers for
each prefix in which it is assigned an address. It also recommends that
hosts SHOULD implement Rule 5.5. of . Hosts following the
recommendations specified in therefore should be able to benefit from
the solution described in this document. No standards need to be
updated in regards to host behavior. 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,
even when uplinks to both ISPs are working. If H31 started sending
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 uplink to ISP-B. SERb1 could recognize that this is traffic is
not following the desired routing policy and react by sending an
ICMPv6 message back to H31.In this example, we could arrange things so that SERb1 drops the
packet with S=2001:db8:0:b010::31 and D=2001:db8:0:1234::101, and
then sends to H31 an ICMPv6 Destination Unreachable message with
Code 5 (Source address failed ingress/egress policy). When H31
receives this packet, it would then be expected to try another
source address to reach the destination. In this example, H31 would
then send a packet with S=2001:db8:0:a010::31 and
D=2001:db8:0:1234::101, which will reach SERa and be forwarded out
the uplink to ISP-A.However, we would also want it to be the case that SERb1 does not
enforce this routing policy when the uplink from SERa to ISP-A has
failed. This could be accomplished by having SERa originate a
source-prefix-scoped route for (S=2001:db8:0:a000::/52,
D=2001:db8:0:1234::/64) and have SERb1 monitor the presence of that
route. If that route is not present (because SERa has stopped
originating it), then SERb1 will not enforce the routing policy, and
it will forward packets with S=2001:db8:0:b010::31 and
D=2001:db8:0:1234::101 out its uplink to ISP-B.We can also use this source-prefix-scoped route originated by
SERa to communicate the desired routing policy to SERb1. We can
define an EXCLUSIVE flag to be advertised together with the IGP
route for (S=2001:db8:0:a000::/52, D=2001:db8:0:1234::/64). This
would allow SERa to communicate to SERb that SERb should reject
traffic for D=2001:db8:0:1234::/64 and respond with an ICMPv6
Destination Unreachable Code 5 message, as long as the route for
(S=2001:db8:0:a000::/52, D=2001:db8:0:1234::/64) is present.Finally, if we are willing to extend ICMPv6 to support this
solution, then we could create a mechanism for SERb1 to tell the
host what source address it should be using to successfully forward
packets that meet the policy. In its current form, when SERb1 sends
an ICMPv6 Destination Unreachable Code 5 message, it is basically
saying, "This source address is wrong. Try another source address."
In the absence of a clear indication which address to try next, the host
will iterate over all addresses assigned to the interface (e.g. various
privacy addresses) which would lead to significant delays and degraded user experience.
It would be better is if the ICMPv6 message could say, "This source
address is wrong. Instead use a source address in
S=2001:db8:0:a000::/52.". However using ICMPv6 for signalling source address information
back to hosts introduces new challenges. Most routers currently have
software or hardware limits on generating ICMP messages. An site
administrator deploying a solution that relies on the SERs
generating ICMP messages could try to improve the performance of
SERs for generating ICMP messages. However, in a large network, it
is still likely that ICMP message generation limits will be reached.
As a result hosts would not receive ICMPv6 back which in turn leads
to traffic blackholing and poor user experience. To improve the
scalability of ICMPv6-based signalling hosts SHOULD cache the
preferred source address (or prefix) for the given destination
(which in turn might cause issues in case of the corresponding
ISP uplinks failure - see ). In
addition, the same source prefix SHOULD be used for other
destinations in the same /64 as the original destination address.
The source prefix SHOULD have a specific lifetime. Expiration of the
lifetime SHOULD trigger the source address selection algorithm
again.Using ICMPv6 Code 5 message for influencing source address
selection allows an attacker to exhaust the list of candidate source
addresses on the host by sending spoofed ICMPv6 Code 5 for all
prefixes known on the network (therefore preventing a victim from
establishing a communication with the destination host). To protect
from such attack hosts SHOULD verify that the original packet header
included into ICMPv6 error message was actually sent by the
host. As currently standardized in , the ICMPv6
Destination Unreachable Message with Code 5 would allow for the
iterative approach to retransmitting packets using different source addresses.
As currently defined, the ICMPv6 message does not provide
a mechanism to communication information about which source prefix
should be used for a retransmitted packet. The current document does not
define such a mechanism. However, we note that this might be a useful extension
to define in a different document. So to summarize this section, we have looked at three methods for
implementing a simple routing policy where all traffic for a given
destination on the Internet needs to use a particular ISP, even when
the uplinks to both ISPs are working.The default source address selection policy cannot distinguish
between the source addresses needed to enforce this policy, so a
non-default policy table using associating source and destination
prefixes using Label values would need to be installed on each host.
A mechanism exists for DHCPv6 to distribute a non-default policy
table but such solution would heavily rely on DHCPv6 support by host
operating system. Moreover there is no mechanism to translate
desired routing/traffic engineering policies into policy tables on
DHCPv6 servers. Therefore using DHCPv6 for controlling address
selection policy table is not recommended and SHOULD NOT be
used.At the same time Router Advertisements provide a reliable
mechanism to influence source address selection process via PIO, RIO
and default router preferences. As all those options have been
standardized by IETF and are supported by various operating systems,
no changes are required on hosts. First-hop routers in the
enterprise network need to be able of sending different RAs for
different SLAAC prefixes (either based on scoped forwarding tables
or based on pre-configured policies).SERs can enforce the routing policy by sending ICMPv6 Destination
Unreachable messages with Code 5 (Source address failed
ingress/egress policy) for traffic that is being sent with the wrong
source address. The policy distribution can be automated by defining
an EXCLUSIVE flag for the source-prefix-scoped route which can be
set on the SER that originates the route. As ICMPv6 message
generation can be rate-limited on routers, it SHOULD NOT be used as
the only mechanism to influence source address selection on hosts.
While hosts SHOULD select the correct source address for a given
destination the network SHOULD signal any source address issues back
to hosts using ICMPv6 error messages.Now we discuss if DHCPv6, Neighbor Discovery Router Advertisements,
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 in
. This time we look at traffic from
H31 destined for 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 from SERb1 to ISP-B is working.We assume there is no particular routing policy desired, so H31 is
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
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
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 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
S=2001:db8:0:b010::31 in order to reach H61 at
D=2001:db8:0:6666::61.For this example we assume that the site network in has a centralized DHCP server and all
routers act as DHCP relay agents. We assume that both of the
addresses assigned to H31 were assigned via DHCP.We could try to have the DHCP server monitor the state of the
uplink from SERb1 to ISP-B in some manner and then tell H31 that it
can no longer use S=2001:db8:0:b010::31 by settings its valid
lifetime to zero. The DHCP server could initiate this process by
sending a Reconfigure Message to H31 as described in Section 19 of
. Or the DHCP server can assign addresses
with short lifetimes in order to force clients to renew them
often.This approach would prevent H31 from using S=2001:db8:0:b010::31
to reach the a host on the Internet. However, it would also prevent
H31 from using S=2001:db8:0:b010::31 to reach H61 at
D=2001:db8:0:6666::61, which is not desirable.Another potential approach is to have the DHCP server monitor the
uplink from SERb1 to ISP-B and control the choice of source address
on H31 by updating its address selection policy table via the
mechanism in . The DHCP server could
initiate this process by sending a Reconfigure Message to H31. Note
that requires that Reconfigure Message use
DHCP authentication. DHCP authentication could be avoided by using
short address lifetimes to force clients to send Renew messages to
the server often. If the host is not obtaining its IP addresses from
the DHCP server, then it would need to use the Information Refresh
Time option defined in .If the following policy table can be installed on H31 after the
failure of the uplink from SERb1, then the desired routing behavior
should be achieved based on source and destination prefix being
matched with label values.The described solution has a number of significant drawbacks,
some of them already discussed in .DHCPv6 support is not required for an IPv6 host and there are
operating systems which do not support DHCPv6. Besides that, it
does not appear that has been widely
implemented on host operating systems. does not clearly specify this kind
of a dynamic use case where address selection policy needs to be
updated quickly in response to the failure of a link. In a large
network it would present scalability issues as many hosts need
to be reconfigured in very short period of time.Updating DHCPv6 server configuration each time an ISP
uplink changes its state introduces some scalability issues, especially
for mid/large distributed scale enterprise networks. In addition to that,
the policy table needs to be manually configured by administrators which makes
that solution prone to human error.No mechanism exists for making DHCPv6 servers aware of
network topology/routing changes in the network. In general
DHCPv6 servers monitoring network-related events sounds like a
bad idea as completely new functionality beyond the scope of
DHCPv6 role is required.The same mechanism as discussed in can be used to control the source
address selection in the case of an uplink failure. If a particular
prefix should not be used as a source for any destinations, then the
router needs to send RA with Preferred Lifetime field for that
prefix set to 0.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
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
router preference set to 01 (high) and RIO for 2001:db8:0:6666::/64.
As a result H41 is using 2001:db8:0:b020::41 as a source address for
all Internet traffic and those packets are sent by SERs to ISP-B. If
SERb1 uplink to ISP-B failed, the desired behavior is that H41 stops
using 2001:db8:0:b020::41 as a source address for all destinations
but H61. To achieve that R3 should react to SERb1 uplink failure
(which could be detected as the scoped route
(S=2001:db8:0:b000::/52, D=::/0) disappearance) by withdrawing
itself as a default router. R3 sends a new RA from LLA_B with Router
Lifetime value set to 0 (which means that it should not be used as
default router). That RA still contains PIO for 2001:db8:0:b020::/64
(for SLAAC purposes) and RIO for 2001:db8:0:6666::/64 so H41 can
reach H61 using LLA_B as a next-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 2001:db8:0:a020::41 as a source
address.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 table scoped S=2001:db8:0:b000::/52 contains no entries.
Hosts can be instructed to stop using source addresses from that
block by sending RAs containing PIO with Preferred Lifetime set to
0.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 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,
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
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) would end up at SERa based on the unscoped
default destination route being originated by SERa. Since that
traffic has the wrong source address to be forwarded to ISP-A, SERa
would drop it and send a Destination Unreachable message with Code 5
(Source address failed ingress/egress policy) back to H31. H31 would
then know to use 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 forwarded to SERa based on the source-prefix-scoped default
destination route still being originated by SERa, and SERa would
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
reach that destination. The expected host behaviour has been
discussed in . Potential
issue with using ICMPv6 for signalling source address issues back to
hosts is that uplink to an ISP-B failure immediately invalidates
source addresses from 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 issues discussed in would apply.It appears that DHCPv6 is not particularly well suited to quickly
changing the source address used by a host in the event of the
failure of an uplink, which eliminates DHCPv6 from the list of
potential solutions. On the other hand Router Advertisements
provides a reliable mechanism to dynamically provide hosts with a
list of valid prefixes to use as source addresses as well as prevent
particular prefixes to be used. While no additional new features are
required to be implemented on hosts, routers need to be able to send
RAs based on the state of scoped forwarding tables entries and to
react to network topology changes by sending RAs with particular
parameters set.The use of ICMPv6 Destination Unreachable messages generated by
the SER (or any SADR-capable) routers seem like they have the
potential to provide a support mechanism together with RAs to signal
source address selection errors back to hosts, however scalability
issues may arise in large networks in case of sudden topology
change. Therefore it is highly desirable that hosts are able to
select the correct source address in case of uplinks failure with
ICMPv6 being an additional mechanism to signal unexpected failures
back to hosts.The current behavior of different host operating system when
receiving ICMPv6 Destination Unreachable message with code 5 (Source
address failed ingress/egress policy) is not clear to the authors.
Information from implementers, users, and testing would be quite
helpful in evaluating this approach.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 addresses belonging to 2001:db8:0:b000::/52 again.The mechanism to use DHCPv6 to instruct the hosts (H31 in our
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
quite similar to one discussed in and shares the same
drawbacks.Let's look at the scenario discussed in . If the uplink(s) failure caused
the complete withdrawal of prefixes from 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 being sent with
non-zero Preferred Lifetime. In another scenario discussed in , the SERb1 uplink to ISP-B
failure leads 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, 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 (S=2001:db8:0:b000::/52, D=::/0) scoped
forwarding entry re-appearance and instructs R3 that it should
advertise itself as a default router for ISP-B address space domain
(send RAs from LLA_B with non-zero Router Lifetime).It looks like ICMPv6 provides a rather limited functionality to
signal back to hosts that particular source addresses have become
valid again. Unless the changes in the uplink state a particular
(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
SERb1 to ISP-B had failed, H31 received ICMPv6 Code 5 message (as
described in ) and
allegedly started using (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 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 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
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
for Internet destinations, including H51.One of the possible option may be using a scoped route with
EXCLUSIVE flag as described in . SERa1 uplink recovery would
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
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-appears SERb1 would reject those packets and sends ICMPv6 back as
discussed in . Practically
it might lead to scalability issues which have been already
discussed in and .Once again DHCPv6 does not look like reasonable choice to
manipulate source address selection process on a host in the case of
network topology changes. Using Router Advertisement provides the
flexible mechanism to dynamically react to network topology changes
(if routers are able to use routing changes as a trigger for sending
out RAs with specific parameters). ICMPv6 could be considered as a
supporting mechanism to signal incorrect source address back to
hosts but should not be considered as the only mechanism to control
the address selection in multihomed environments.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
any external destinations while it might be desirable to have
intra-site connectivity.From DHCPv6 perspective uplinks failure should be treated as two
independent failures and processed as described in . At this stage it is quite
obvious that it would result in quite complicated policy table which
needs to be explicitly configured by administrators and therefore
seems to be impractical.As discussed in an
uplink failure causes the scoped default entry to disappear from the
scoped forwarding table and triggers RAs with zero Router Lifetime.
Complete disappearance of all scoped entries for a given source
prefix would cause the prefix being withdrawn from hosts by setting
Preferred Lifetime value to zero in PIO. If all uplinks (SERa, SERb1
and SERb2) failed, hosts either lost their default routers and/or
have no global IPv6 addresses to use as a source. (Note that 'uplink
failure' might mean 'IPv6 connectivity failure with IPv4 still being
reachable', in which case hosts might fall back to IPv4 if there is
IPv4 connectivity to destinations). As a results intra-site
connectivity is broken. One of the possible way to solve it is to
use ULAs.All hosts have ULA addresses assigned in addition to GUAs and
used for intra-site communication even if there is no GUA assigned
to a host. To avoid accidental leaking of packets with ULA sources
SADR-capable routers SHOULD have a scoped forwarding table for ULA
source for internal routes but MUST NOT have an entry for D=::/0 in
that table. In the absence of (S=ULA_Prefix; D=::/0) first-hop
routers will send dedicated RAs from a unique link-local source
LLA_ULA with PIO from ULA address space, RIO for the ULA prefix and
Router Lifetime set to zero. The behaviour is consistent with the
situation when SERb1 lost the uplink to ISP-B (so there is no
Internet connectivity from 2001:db8:0:b000::/52 sources) but those
sources can be used to reach some specific destinations. In the case
of ULA there is no Internet connectivity from ULA sources but they
can be used to reach another ULA destinations. Note that ULA usage
could be particularly useful if all ISPs assign prefixes via
DHCP-PD. In the absence of ULAs uplinks failure hosts would lost all
their GUAs upon prefix lifetime expiration which again makes
intra-site communication impossible.In case of all uplinks failure all SERs will drop outgoing IPv6
traffic and respond with ICMPv6 error message. In the large network
when many hosts are trying to reach Internet destinations it means
that SERs need to generate an ICMPv6 error to every packet they
receive from hosts which presents the same scalability issues
discussed in Again, combining SADR with Router Advertisements seems to be the
most flexible and scalable way to control the source address
selection on hosts.To summarize the scenarios and options discussed above:While DHCPv6 allows administrators to manipulate source address
selection policy tables, this method has a number of significant
disadvantages which eliminates DHCPv6 from a list of potential
solutions:It required hosts to support DHCPv6 and its extension
(RFC7078);DHCPv6 server needs to monitor network state and detect routing
changes.The use of policy tables requires manual configuration and might be extremely
complicated, especially in the case of distributed network when large
number of remote sites are being served by centralized DHCPv6 servers.Network topology/routing policy changes could trigger
simultaneous re-configuration of large number of hosts which
present serious scalability issues.The use of Router Advertisements to influence the source address
selection on hosts seem to be the most reliable, flexible and scalable
solution. It has the following benefits:no new (non-standard) functionality needs to be implemented on
hosts (except for support);no changes in RA format;routers can react to routing table changes by sending RAs which
would minimize the failover time in the case of network topology
changes;information required for source address selection is broadcast
to all affected hosts in case of topology change event which
improves the scalability of the solution (comparing to DHCPv6
reconfiguration or ICMPv6 error messages).To fully benefit from the RA-based solution, first-hop routers need
to implement SADR and be able to send dedicated RAs per scoped
forwarding table as discussed above, reacting to network changes with
sending new RAs. It should be noted that the proposed solution would
work even if first-hop routers are not SADR-capable but still able
to send individual RAs for each ISP prefix and react to topology changes
as discussed above (e.g. via configuration knobs). The RA-based solution relies heavily on hosts correctly implementing
default address selection algorith as defined in .
While the basic (and most common) multihoming scenario (two or more Internet
uplinks, no 'wall gardens') would work for any host supporting the minimal
implementation of , more complex use cases (such as
"wall garden" and other scenarios when some ISP resources can only be reached from
that ISP address space) require that hosts support Rule 5.5 of the default address
selection algorithm. There is some evidence that not all host OSes
have that rule implemented currently. However it should be noted that
states that Rule 5.5 SHOULD be implemented.
ICMPv6 Code 5 error message SHOULD be used to complement RA-based
solution to signal incorrect source address selection back to hosts,
but it SHOULD NOT be considered as the stand-alone solution.
To prevent scenarios when hosts in multihomed envinronments incorrectly
identify onlink/offlink destinations, hosts should treat ICMPv6 Redirects
as discussed in . In mutihomed envinronment each ISP might provide their own list of
DNS servers. E.g. in the topology show on Figure 3, ISP-A might provide
recursive DNS server H51 2001:db8:0:5555::51, while ISP-B might provide
H61 2001:db8:0:6666::61 as a recursive DNS server.
defines IPv6 Router Advertisement options to allow
IPv6 routers to advertise a list of DNS recursive server addresses
and a DNS Search List to IPv6 hosts. Using RDNSS together with 'scoped' RAs
as described above would allow a first-hop router (R3 in the Figure 3) to send
DNS server addresses and search lists provided by each ISP (or the corporate DNS servers
addresses if the enterprise is running its own DNS servers).As discussed in , failure of all ISP uplinks
would cause deprecaction of all addresses assigned to a host from the address space
if all ISPs.
If any intra-site IPv6 connectivity is still desirable (most likely to be the case for
any mid/large scare network), then ULAs should be used as discussed in .
In such a scenario, the enterprise network should run its own recursive DNS server(s) and provide
its ULA addresses to hosts via RDNSS in RAs send for ULA-scoped forwarding table as described in .There are some scenarios when the final outcome of the name resolution might be different
depending on:which DNS server is used;which source address the client uses to send a DNS query to the server (DNS split horizon).There is no way currently to instruct a host to use a particular DNS server out of the configured servers list
for resolving a particular name. Therefore it does not seem feasible to solve the problem of DNS server selection
on the host (it should be noted that this particular issue is protocol-agnostic and happens for IPv4 as well). In such
a scenario it is recommended that the enterprise run its own local recursive DNS server.To influence host source address selection for packets sent to a particular DNS server
the following requirements must be met:
the host supports RIO as defined in ; the routers send RIO for routes to DNS server addresses.
For example, if it is desirable that host H31 reaches the ISP-A DNS server H51 2001:db8:0:5555::51
using its source address 2001:db8:0:a010::31, then both R1 and R2 should send the RIO containing the route to 2001:db8:0:5555::51
(or covering route) in their 'scoped' RAs, containing LLA_A as the default router address and the PO for SLAAC prefix 2001:db8:0:a010::/64.
In that case the host H31 (if it supports the Rule 5.5) would select LLA_A as a next-hop and then chose 2001:db8:0:a010::31 as the source address
for packets to the DNS server.
It should be noted that explicitly prohibits using DNS 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 Lifetime (advertised by a Router
Advertisement message) and the corresponding option
Lifetime have not expired.". Therefore hosts might ignore RDNSS information provided
in ULA-scoped RAs as those RAs would have router lifetime set to 0. However the updated version of
RFC6106 () has that requirement removed.
The Shim6 working group specified the Shim6 protocol which allows a host at a multihomed site to
communicate with an external host and exchange information about
possible source and destination address pairs that they can use to
communicate. It also specified the REAP protocol to detect failures in the path between working
address pairs and find new working address pairs. A fundamental
requirement for Shim6 is that both internal and external 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 support Shim6 in
order for there to be any benefit for the internal host to run Shim6.
The Shim6 protocol specification was published in 2009, but it has not
been implemented on widely used operating systems.We do not consider Shim6 to be a viable solution. It suffers from
the fact that it requires widespread deployment of Shim6 on hosts all
over the Internet before the host at a PA multihomed site sees
significant benefit. However, there appears to be no motivation for
the vast majority of hosts on the Internet (which are not at PA
multihomed sites) to deploy Shim6. This may help explain why Shim6 has
not been widely implemented.IPv6-to-IPv6 Network Prefix Translation (NPTv6) is not the focus of this document. This document
describes a solution where a host in a multihomed site determines
which ISP a packet will be sent to based on the source address it
applies to the packet. This solution has many moving parts. It
requires some routers in the enterprise site to support some form of
Source Address Dependent Routing (SADR). It requires a host to be able
to learn when the uplink to an ISP fails so that it can stop using the
source address corresponding to that ISP. Ongoing work to create
mechanisms to accomplish this are discussed in this document, but they
are still a work in progress.This document attempts to create a PA multihoming solution that is
as easy as possible for an enterprise to deploy. However, the success
of this solution will depend greatly on whether or not the mechanisms
for hosts to select source addresses based on the state of ISP uplinks
gets implemented across a wide range of operating systems as the
default mode of operation. Until that occurs, NPTv6 should still be
considered a viable option to enable PA multihoming for
enterprises.This memo asks the IANA for no new parameters.The original outline was suggested by Ole Troan.Practical Algorithm to Retrieve Information Coded in
AlphanumericAssociation for Computing MachineryJuly 2016