draft-ietf-6man-rfc3484bis-06.txt   rfc6724.txt 
Network Working Group D. Thaler, Ed. Internet Engineering Task Force (IETF) D. Thaler, Ed.
Internet-Draft Microsoft Request for Comments: 6724 Microsoft
Obsoletes: 3484 (if approved) R. Draves Obsoletes: 3484 R. Draves
Intended status: Standards Track Microsoft Research Category: Standards Track Microsoft Research
Expires: December 29, 2012 A. Matsumoto ISSN: 2070-1721 A. Matsumoto
NTT NTT
T. Chown T. Chown
University of Southampton University of Southampton
June 27, 2012 September 2012
Default Address Selection for Internet Protocol version 6 (IPv6) Default Address Selection for Internet Protocol Version 6 (IPv6)
draft-ietf-6man-rfc3484bis-06.txt
Abstract Abstract
This document describes two algorithms, one for source address This document describes two algorithms, one for source address
selection and one for destination address selection. The algorithms selection and one for destination address selection. The algorithms
specify default behavior for all Internet Protocol version 6 (IPv6) specify default behavior for all Internet Protocol version 6 (IPv6)
implementations. They do not override choices made by applications implementations. They do not override choices made by applications
or upper-layer protocols, nor do they preclude the development of or upper-layer protocols, nor do they preclude the development of
more advanced mechanisms for address selection. The two algorithms more advanced mechanisms for address selection. The two algorithms
share a common context, including an optional mechanism for allowing share a common context, including an optional mechanism for allowing
administrators to provide policy that can override the default administrators to provide policy that can override the default
behavior. In dual stack implementations, the destination address behavior. In dual-stack implementations, the destination address
selection algorithm can consider both IPv4 and IPv6 addresses - selection algorithm can consider both IPv4 and IPv6 addresses --
depending on the available source addresses, the algorithm might depending on the available source addresses, the algorithm might
prefer IPv6 addresses over IPv4 addresses, or vice-versa. prefer IPv6 addresses over IPv4 addresses, or vice versa.
Default address selection as defined in this specification applies to Default address selection as defined in this specification applies to
all IPv6 nodes, including both hosts and routers. This document all IPv6 nodes, including both hosts and routers. This document
obsoletes RFC 3484. obsoletes RFC 3484.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This document is a product of the Internet Engineering Task Force
Task Force (IETF). Note that other groups may also distribute (IETF). It represents the consensus of the IETF community. It has
working documents as Internet-Drafts. The list of current Internet- received public review and has been approved for publication by the
Drafts is at http://datatracker.ietf.org/drafts/current/. Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Internet-Drafts are draft documents valid for a maximum of six months Information about the current status of this document, any errata,
and may be updated, replaced, or obsoleted by other documents at any and how to provide feedback on it may be obtained at
time. It is inappropriate to use Internet-Drafts as reference http://www.rfc-editor.org/info/rfc6724.
material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 29, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction ....................................................3
1.1. Conventions Used in This Document . . . . . . . . . . . . 5 1.1. Conventions Used in This Document ..........................4
2. Context in Which the Algorithms Operate . . . . . . . . . . . 5 2. Context in Which the Algorithms Operate .........................4
2.1. Policy Table . . . . . . . . . . . . . . . . . . . . . . . 7 2.1. Policy Table ...............................................6
2.2. Common Prefix Length . . . . . . . . . . . . . . . . . . . 8 2.2. Common Prefix Length .......................................7
3. Address Properties . . . . . . . . . . . . . . . . . . . . . . 8 3. Address Properties ..............................................7
3.1. Scope Comparisons . . . . . . . . . . . . . . . . . . . . 9 3.1. Scope Comparisons ..........................................8
3.2. IPv4 Addresses and IPv4-Mapped Addresses . . . . . . . . . 9 3.2. IPv4 Addresses and IPv4-Mapped Addresses ...................8
3.3. Other IPv6 Addresses with Embedded IPv4 Addresses . . . . 10 3.3. Other IPv6 Addresses with Embedded IPv4 Addresses ..........9
3.4. IPv6 Loopback Address and Other Format Prefixes . . . . . 10 3.4. IPv6 Loopback Address and Other Format Prefixes ............9
3.5. Mobility Addresses . . . . . . . . . . . . . . . . . . . . 10 3.5. Mobility Addresses .........................................9
4. Candidate Source Addresses . . . . . . . . . . . . . . . . . . 11 4. Candidate Source Addresses .....................................10
5. Source Address Selection . . . . . . . . . . . . . . . . . . . 12 5. Source Address Selection .......................................11
6. Destination Address Selection . . . . . . . . . . . . . . . . 14 6. Destination Address Selection ..................................14
7. Interactions with Routing . . . . . . . . . . . . . . . . . . 17 7. Interactions with Routing ......................................16
8. Implementation Considerations . . . . . . . . . . . . . . . . 17 8. Implementation Considerations ..................................16
9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 9. Security Considerations ........................................17
10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 10. Examples ......................................................18
10.1. Default Source Address Selection . . . . . . . . . . . . . 19 10.1. Default Source Address Selection .........................18
10.2. Default Destination Address Selection . . . . . . . . . . 20 10.2. Default Destination Address Selection ....................19
10.3. Configuring Preference for IPv6 or IPv4 . . . . . . . . . 21 10.3. Configuring Preference for IPv6 or IPv4 ..................20
10.3.1. Handling Broken IPv6 . . . . . . . . . . . . . . . . 22 10.3.1. Handling Broken IPv6 ..............................21
10.4. Configuring Preference for Link-Local Addresses . . . . . 22 10.4. Configuring Preference for Link-Local Addresses ..........21
10.5. Configuring a Multi-Homed Site . . . . . . . . . . . . . . 23 10.5. Configuring a Multi-Homed Site ...........................22
10.6. Configuring ULA Preference . . . . . . . . . . . . . . . . 24 10.6. Configuring ULA Preference ...............................24
10.7. Configuring 6to4 Preference . . . . . . . . . . . . . . . 25 10.7. Configuring 6to4 Preference ..............................25
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 11. References ....................................................26
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 11.1. Normative References .....................................26
12.1. Normative References . . . . . . . . . . . . . . . . . . . 26 11.2. Informative References ...................................27
12.2. Informative References . . . . . . . . . . . . . . . . . . 27 Appendix A. Acknowledgements .....................................29
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 29 Appendix B. Changes since RFC 3484 ...............................29
Appendix B. Changes Since RFC 3484 . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction 1. Introduction
The IPv6 addressing architecture [RFC4291] allows multiple unicast The IPv6 addressing architecture [RFC4291] allows multiple unicast
addresses to be assigned to interfaces. These addresses might have addresses to be assigned to interfaces. These addresses might have
different reachability scopes (link-local, site-local, or global). different reachability scopes (link-local, site-local, or global).
These addresses might also be "preferred" or "deprecated" [RFC4862]. These addresses might also be "preferred" or "deprecated" [RFC4862].
Privacy considerations have introduced the concepts of "public Privacy considerations have introduced the concepts of "public
addresses" and "temporary addresses" [RFC4941]. The mobility addresses" and "temporary addresses" [RFC4941]. The mobility
architecture introduces "home addresses" and "care-of addresses" architecture introduces "home addresses" and "care-of addresses"
skipping to change at page 4, line 26 skipping to change at page 3, line 26
interfaces, some of them tunnels or virtual interfaces, or a site interfaces, some of them tunnels or virtual interfaces, or a site
might have multiple ISP attachments with a global prefix per ISP. might have multiple ISP attachments with a global prefix per ISP.
The end result is that IPv6 implementations will very often be faced The end result is that IPv6 implementations will very often be faced
with multiple possible source and destination addresses when with multiple possible source and destination addresses when
initiating communication. It is desirable to have default initiating communication. It is desirable to have default
algorithms, common across all implementations, for selecting source algorithms, common across all implementations, for selecting source
and destination addresses so that developers and administrators can and destination addresses so that developers and administrators can
reason about and predict the behavior of their systems. reason about and predict the behavior of their systems.
Furthermore, dual or hybrid stack implementations, which support both Furthermore, dual- or hybrid-stack implementations, which support
IPv6 and IPv4, will very often need to choose between IPv6 and IPv4 both IPv6 and IPv4, will very often need to choose between IPv6 and
when initiating communication. For example, when DNS name resolution IPv4 when initiating communication, for example, when DNS name
yields both IPv6 and IPv4 addresses and the network protocol stack resolution yields both IPv6 and IPv4 addresses and the network
has available both IPv6 and IPv4 source addresses. In such cases, a protocol stack has available both IPv6 and IPv4 source addresses. In
simple policy to always prefer IPv6 or always prefer IPv4 can produce such cases, a simple policy to always prefer IPv6 or always prefer
poor behavior. As one example, suppose a DNS name resolves to a IPv4 can produce poor behavior. As one example, suppose a DNS name
global IPv6 address and a global IPv4 address. If the node has resolves to a global IPv6 address and a global IPv4 address. If the
assigned a global IPv6 address and a 169.254/16 auto-configured IPv4 node has assigned a global IPv6 address and a 169.254/16 auto-
address [RFC3927], then IPv6 is the best choice for communication. configured IPv4 address [RFC3927], then IPv6 is the best choice for
But if the node has assigned only a link-local IPv6 address and a communication. But if the node has assigned only a link-local IPv6
global IPv4 address, then IPv4 is the best choice for communication. address and a global IPv4 address, then IPv4 is the best choice for
The destination address selection algorithm solves this with a communication. The destination address selection algorithm solves
unified procedure for choosing among both IPv6 and IPv4 addresses. this with a unified procedure for choosing among both IPv6 and IPv4
addresses.
The algorithms in this document are specified as a set of rules that The algorithms in this document are specified as a set of rules that
define a partial ordering on the set of addresses that are available define a partial ordering on the set of addresses that are available
for use. In the case of source address selection, a node typically for use. In the case of source address selection, a node typically
has multiple addresses assigned to its interfaces, and the source has multiple addresses assigned to its interfaces, and the source
address ordering rules in section 5 define which address is the address ordering rules in Section 5 define which address is the
"best" one to use. In the case of destination address selection, the "best" one to use. In the case of destination address selection, the
DNS might return a set of addresses for a given name, and an DNS might return a set of addresses for a given name, and an
application needs to decide which one to use first, and in what order application needs to decide which one to use first and in what order
to try others if the first one is not reachable. The destination to try others if the first one is not reachable. The destination
address ordering rules in section 6, when applied to the set of address ordering rules in Section 6, when applied to the set of
addresses returned by the DNS, provide such a recommended ordering. addresses returned by the DNS, provide such a recommended ordering.
This document specifies source address selection and destination This document specifies source address selection and destination
address selection separately, but using a common context so that address selection separately but uses a common context so that
together the two algorithms yield useful results. The algorithms together the two algorithms yield useful results. The algorithms
attempt to choose source and destination addresses of appropriate attempt to choose source and destination addresses of appropriate
scope and configuration status (preferred or deprecated in the RFC scope and configuration status ("preferred" or "deprecated" in the
4862 sense). Furthermore, this document suggests a preferred method, RFC 4862 sense). Furthermore, this document suggests a preferred
longest matching prefix, for choosing among otherwise equivalent method, longest matching prefix, for choosing among otherwise
addresses in the absence of better information. equivalent addresses in the absence of better information.
This document also specifies policy hooks to allow administrative This document also specifies policy hooks to allow administrative
override of the default behavior. For example, using these hooks an override of the default behavior. For example, using these hooks, an
administrator can specify a preferred source prefix for use with a administrator can specify a preferred source prefix for use with a
destination prefix, or prefer destination addresses with one prefix destination prefix or prefer destination addresses with one prefix
over addresses with another prefix. These hooks give an over addresses with another prefix. These hooks give an
administrator flexibility in dealing with some multi-homing and administrator flexibility in dealing with some multi-homing and
transition scenarios, but they are certainly not a panacea. transition scenarios, but they are certainly not a panacea.
The selection rules specified in this document MUST NOT be construed The selection rules specified in this document MUST NOT be construed
to override an application or upper-layer's explicit choice of a to override an application or upper layer's explicit choice of a
legal destination or source address. legal destination or source address.
1.1. Conventions Used in This Document 1.1. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119 document are to be interpreted as described in BCP 14, RFC 2119
[RFC2119]. [RFC2119].
2. Context in Which the Algorithms Operate 2. Context in Which the Algorithms Operate
Our context for address selection derives from the most common Our context for address selection derives from the most common
implementation architecture, which separates the choice of implementation architecture, which separates the choice of
destination address from the choice of source address. Consequently, destination address from the choice of source address. Consequently,
we have two separate algorithms for these tasks. The algorithms are we have two separate algorithms for these tasks. The algorithms are
designed to work well together and they share a mechanism for designed to work well together, and they share a mechanism for
administrative policy override. administrative policy override.
In this implementation architecture, applications use APIs such as In this implementation architecture, applications use APIs such as
getaddrinfo() [RFC3493] that return a list of addresses to the getaddrinfo() [RFC3493] that return a list of addresses to the
application. This list might contain both IPv6 and IPv4 addresses application. This list might contain both IPv6 and IPv4 addresses
(sometimes represented as IPv4-mapped addresses). The application (sometimes represented as IPv4-mapped addresses). The application
then passes a destination address to the network stack with connect() then passes a destination address to the network stack with connect()
or sendto(). The application would then typically try the first or sendto(). The application would then typically try the first
address in the list, looping over the list of addresses until it address in the list, looping over the list of addresses until it
finds a working address. In any case, the network layer is never in finds a working address. In any case, the network layer is never in
a situation where it needs to choose a destination address from a situation where it needs to choose a destination address from
several alternatives. The application might also specify a source several alternatives. The application might also specify a source
address with bind(), but often the source address is left address with bind(), but often the source address is left
unspecified. Therefore the network layer does often choose a source unspecified. Therefore, the network layer does often choose a source
address from several alternatives. address from several alternatives.
As a consequence, we intend that implementations of APIs such as As a consequence, we intend that implementations of APIs such as
getaddrinfo() will use the destination address selection algorithm getaddrinfo() will use the destination address selection algorithm
specified here to sort the list of IPv6 and IPv4 addresses that they specified here to sort the list of IPv6 and IPv4 addresses that they
return. Separately, the IPv6 network layer will use the source return. Separately, the IPv6 network layer will use the source
address selection algorithm when an application or upper-layer has address selection algorithm when an application or upper layer has
not specified a source address. Application of this specification to not specified a source address. Application of this specification to
source address selection in an IPv4 network layer might be possible source address selection in an IPv4 network layer might be possible,
but this is not explored further here. but this is not explored further here.
Well-behaved applications SHOULD NOT simply use the first address Well-behaved applications SHOULD NOT simply use the first address
returned from an API such as getaddrinfo() and then give up if it returned from an API such as getaddrinfo() and then give up if it
fails. For many applications, it is appropriate to iterate through fails. For many applications, it is appropriate to iterate through
the list of addresses returned from getaddrinfo() until a working the list of addresses returned from getaddrinfo() until a working
address is found. For other applications, it might be appropriate to address is found. For other applications, it might be appropriate to
try multiple in parallel (e.g., with some small delay in between) and try multiple addresses in parallel (e.g., with some small delay in
use the first one to succeed. between) and use the first one to succeed.
Although source and destination address selection is most typically Although source and destination address selection is most typically
done when initiating communication, a responder also must deal with done when initiating communication, a responder also must deal with
address selection. In many cases this is trivially dealt with by an address selection. In many cases, this is trivially dealt with by an
application using the source address of a received packet as the application using the source address of a received packet as the
response destination, and the destination address of the received response destination and the destination address of the received
packet as the response source. Other cases, however, are handled packet as the response source. Other cases, however, are handled
like an initiator, such as when the request was multicast and hence like an initiator, such as when the request is multicast and hence
source address selection must still occur when generating a response, source address selection must still occur when generating a response
or when the request includes a list of the initiator's addresses from or when the request includes a list of the initiator's addresses from
which to choose a destination. Finally, a third application scenario which to choose a destination. Finally, a third application scenario
is that of a listening application choosing on what local addresses is that of a listening application choosing on what local addresses
to listen. This third scenario is out of scope for this document. to listen. This third scenario is out of the scope of this document.
The algorithms use several criteria in making their decisions. The The algorithms use several criteria in making their decisions. The
combined effect is to prefer destination/source address pairs for combined effect is to prefer destination/source address pairs for
which the two addresses are of equal scope or type, prefer smaller which the two addresses are of equal scope or type, prefer smaller
scopes over larger scopes for the destination address, prefer non- scopes over larger scopes for the destination address, prefer non-
deprecated source addresses, avoid the use of transitional addresses deprecated source addresses, avoid the use of transitional addresses
when native addresses are available, and all else being equal prefer when native addresses are available, and all else being equal, prefer
address pairs having the longest possible common prefix. For source address pairs having the longest possible common prefix. For source
address selection, temporary addresses [RFC4941] are preferred over address selection, temporary addresses [RFC4941] are preferred over
public addresses. In mobile situations [RFC6275], home addresses are public addresses. In mobile situations [RFC6275], home addresses are
preferred over care-of addresses. If an address is simultaneously a preferred over care-of addresses. If an address is simultaneously a
home address and a care-of address (indicating the mobile node is "at home address and a care-of address (indicating the mobile node is "at
home" for that address), then the home/care-of address is preferred home" for that address), then the home/care-of address is preferred
over addresses that are solely a home address or solely a care-of over addresses that are solely a home address or solely a care-of
address. address.
This specification optionally allows for the possibility of This specification optionally allows for the possibility of
administrative configuration of policy (e.g., via manual administrative configuration of policy (e.g., via manual
configuration or a DHCP option such as that proposed in configuration or a DHCP option such as that proposed in
[I-D.ietf-6man-addr-select-opt]) that can override the default [ADDR-SEL-OPT]) that can override the default behavior of the
behavior of the algorithms. The policy override consists of the algorithms. The policy override consists of the following set of
following set of state, which SHOULD be configurable: state, which SHOULD be configurable:
o Policy Table (Section 2.1): a table that specifies precedence o Policy Table (Section 2.1): a table that specifies precedence
values and preferred source prefixes for destination prefixes. values and preferred source prefixes for destination prefixes.
o Automatic Row Additions flag (Section 2.1): a flag that specifies o Automatic Row Additions flag (Section 2.1): a flag that specifies
whether the implementation is permitted to automatically add site- whether the implementation is permitted to automatically add site-
specific rows for certain types of addresses. specific rows for certain types of addresses.
o Privacy Preference flag (Section 5): a flag that specifies whether o Privacy Preference flag (Section 5): a flag that specifies whether
temporary source addresses or stable source addresses are temporary source addresses or stable source addresses are
preferred by default, when both types exist. preferred by default when both types exist.
2.1. Policy Table 2.1. Policy Table
The policy table is a longest-matching-prefix lookup table, much like The policy table is a longest-matching-prefix lookup table, much like
a routing table. Given an address A, a lookup in the policy table a routing table. Given an address A, a lookup in the policy table
produces two values: a precedence value Precedence(A) and a produces two values: a precedence value denoted Precedence(A) and a
classification or label Label(A). classification or label denoted Label(A).
The precedence value Precedence(A) is used for sorting destination The precedence value Precedence(A) is used for sorting destination
addresses. If Precedence(A) > Precedence(B), we say that address A addresses. If Precedence(A) > Precedence(B), we say that address A
has higher precedence than address B, meaning that our algorithm will has higher precedence than address B, meaning that our algorithm will
prefer to sort destination address A before destination address B. prefer to sort destination address A before destination address B.
The label value Label(A) allows for policies that prefer a particular The label value Label(A) allows for policies that prefer a particular
source address prefix for use with a destination address prefix. The source address prefix for use with a destination address prefix. The
algorithms prefer to use a source address S with a destination algorithms prefer to use a source address S with a destination
address D if Label(S) = Label(D). address D if Label(S) = Label(D).
skipping to change at page 8, line 18 skipping to change at page 7, line 18
::ffff:0:0/96 35 4 ::ffff:0:0/96 35 4
2002::/16 30 2 2002::/16 30 2
2001::/32 5 5 2001::/32 5 5
fc00::/7 3 13 fc00::/7 3 13
::/96 1 3 ::/96 1 3
fec0::/10 1 11 fec0::/10 1 11
3ffe::/16 1 12 3ffe::/16 1 12
An implementation MAY automatically add additional site-specific rows An implementation MAY automatically add additional site-specific rows
to the default table based on its configured addresses, such as for to the default table based on its configured addresses, such as for
Unique Local Addresses (ULAs) [RFC4193] and 6to4 [RFC3056] addresses Unique Local Addresses (ULAs) [RFC4193] and 6to4 [RFC3056] addresses,
for instance (see Section 10.6 and Section 10.7 for examples). Any for instance (see Sections 10.6 and 10.7 for examples). Any such
such rows automatically added by the implementation as a result of rows automatically added by the implementation as a result of address
address acquisition MUST NOT override a row for the same prefix acquisition MUST NOT override a row for the same prefix configured
configured via other means. That is, rows can be added but never via other means. That is, rows can be added but never updated
updated automatically. An implementation SHOULD provide a means (the automatically. An implementation SHOULD provide a means (the
Automatic Row Additions flag) for an administrator to disable Automatic Row Additions flag) for an administrator to disable
automatic row additions. automatic row additions.
As will become apparent later, one effect of the default policy table As will become apparent later, one effect of the default policy table
is to prefer using native source addresses with native destination is to prefer using native source addresses with native destination
addresses, 6to4 source addresses with 6to4 destination addresses, addresses, 6to4 source addresses with 6to4 destination addresses,
etc. Another effect of the default policy table is to prefer etc. Another effect of the default policy table is to prefer
communication using IPv6 addresses to communication using IPv4 communication using IPv6 addresses to communication using IPv4
addresses, if matching source addresses are available. addresses, if matching source addresses are available.
skipping to change at page 8, line 51 skipping to change at page 7, line 51
We define the common prefix length CommonPrefixLen(S, D) of a source We define the common prefix length CommonPrefixLen(S, D) of a source
address S and a destination address D as the length of the longest address S and a destination address D as the length of the longest
prefix (looking at the most significant, or leftmost, bits) that the prefix (looking at the most significant, or leftmost, bits) that the
two addresses have in common, up to the length of S's prefix (i.e., two addresses have in common, up to the length of S's prefix (i.e.,
the portion of the address not including the interface ID). For the portion of the address not including the interface ID). For
example, CommonPrefixLen(fe80::1, fe80::2) is 64. example, CommonPrefixLen(fe80::1, fe80::2) is 64.
3. Address Properties 3. Address Properties
In the rules given in later sections, addresses of different types In the rules given in later sections, addresses of different types
(e.g., IPv4, IPv6, multicast and unicast) are compared against each (e.g., IPv4, IPv6, multicast, and unicast) are compared against each
other. Some of these address types have properties that aren't other. Some of these address types have properties that aren't
directly comparable to each other. For example, IPv6 unicast directly comparable to each other. For example, IPv6 unicast
addresses can be "preferred" or "deprecated" [RFC4862], while IPv4 addresses can be "preferred" or "deprecated" [RFC4862], while IPv4
addresses have no such notion. To compare such addresses using the addresses have no such notion. To compare such addresses using the
ordering rules (e.g., to use "preferred" addresses in preference to ordering rules (e.g., to use "preferred" addresses in preference to
"deprecated" addresses), the following mappings are defined. "deprecated" addresses), the following mappings are defined.
3.1. Scope Comparisons 3.1. Scope Comparisons
Multicast destination addresses have a 4-bit scope field that Multicast destination addresses have a 4-bit scope field that
controls the propagation of the multicast packet. The IPv6 controls the propagation of the multicast packet. The IPv6
addressing architecture defines scope field values for interface- addressing architecture defines scope field values for interface-
local (0x1), link-local (0x2), admin-local (0x4), site-local (0x5), local (0x1), link-local (0x2), admin-local (0x4), site-local (0x5),
organization-local (0x8), and global (0xE) scopes ([RFC4291] Section organization-local (0x8), and global (0xE) scopes (Section 2.7 of
2.7). [RFC4291]).
Use of the source address selection algorithm in the presence of Use of the source address selection algorithm in the presence of
multicast destination addresses requires the comparison of a unicast multicast destination addresses requires the comparison of a unicast
address scope with a multicast address scope. We map unicast link- address scope with a multicast address scope. We map unicast link-
local to multicast link-local, unicast site-local to multicast site- local to multicast link-local, unicast site-local to multicast site-
local, and unicast global scope to multicast global scope. For local, and unicast global scope to multicast global scope. For
example, unicast site-local is equal to multicast site-local, which example, unicast site-local is equal to multicast site-local, which
is smaller than multicast organization-local, which is smaller than is smaller than multicast organization-local, which is smaller than
unicast global, which is equal to multicast global. (Note that IPv6 unicast global, which is equal to multicast global. (Note that IPv6
site-local unicast addresses are deprecated [RFC4291]. However, some site-local unicast addresses are deprecated [RFC4291]. However, some
existing implementations and deployments may still use these existing implementations and deployments may still use these
addresses and, therefore, they are included in the procedures in this addresses; they are therefore included in the procedures in this
specification. Also note that ULAs are considered as global, not specification. Also, note that ULAs are considered as global, not
site-local, scope but are handled via the prefix policy table as site-local, scope but are handled via the prefix policy table as
discussed in Section 10.6.) discussed in Section 10.6.)
We write Scope(A) to mean the scope of address A. For example, if A We write Scope(A) to mean the scope of address A. For example, if A
is a link-local unicast address and B is a site-local multicast is a link-local unicast address and B is a site-local multicast
address, then Scope(A) < Scope(B). address, then Scope(A) < Scope(B).
This mapping implicitly conflates unicast site boundaries and This mapping implicitly conflates unicast site boundaries and
multicast site boundaries [RFC4007]. multicast site boundaries [RFC4007].
3.2. IPv4 Addresses and IPv4-Mapped Addresses 3.2. IPv4 Addresses and IPv4-Mapped Addresses
The destination address selection algorithm operates on both IPv6 and The destination address selection algorithm operates on both IPv6 and
IPv4 addresses. For this purpose, IPv4 addresses MUST be represented IPv4 addresses. For this purpose, IPv4 addresses MUST be represented
as IPv4-mapped addresses [RFC4291]. For example, to lookup the as IPv4-mapped addresses [RFC4291]. For example, to look up the
precedence or other attributes of an IPv4 address in the policy precedence or other attributes of an IPv4 address in the policy
table, lookup the corresponding IPv4-mapped IPv6 address. table, look up the corresponding IPv4-mapped IPv6 address.
IPv4 addresses are assigned scopes as follows. IPv4 auto- IPv4 addresses are assigned scopes as follows. IPv4 auto-
configuration addresses [RFC3927], which have the prefix 169.254/16, configuration addresses [RFC3927], which have the prefix 169.254/16,
are assigned link-local scope. IPv4 loopback addresses ([RFC1918], are assigned link-local scope. IPv4 loopback addresses (Section
section 4.2.2.11), which have the prefix 127/8, are assigned link- 4.2.2.11 of [RFC1812]), which have the prefix 127/8, are assigned
local scope (analogously to the treatment of the IPv6 loopback link-local scope (analogously to the treatment of the IPv6 loopback
address ([RFC4007], section 4)). Other IPv4 addresses (including address (Section 4 of [RFC4007])). Other IPv4 addresses (including
IPv4 private addresses [RFC1918] and Shared Address Space addresses IPv4 private addresses [RFC1918] and Shared Address Space addresses
[RFC6598]) are assigned global scope. [RFC6598]) are assigned global scope.
IPv4 addresses MUST be treated as having "preferred" (in the RFC 4862 IPv4 addresses MUST be treated as having "preferred" (in the RFC 4862
sense) configuration status. sense) configuration status.
3.3. Other IPv6 Addresses with Embedded IPv4 Addresses 3.3. Other IPv6 Addresses with Embedded IPv4 Addresses
IPv4-compatible addresses [RFC4291], IPv4-mapped [RFC4291], IPv4- IPv4-compatible addresses [RFC4291], IPv4-mapped [RFC4291], IPv4-
converted [RFC6145], IPv4-translatable [RFC6145], and 6to4 addresses converted [RFC6145], IPv4-translatable [RFC6145], and 6to4 addresses
[RFC3056] contain an embedded IPv4 address. For the purposes of this [RFC3056] contain an embedded IPv4 address. For the purposes of this
document, these addresses MUST be treated as having global scope. document, these addresses MUST be treated as having global scope.
IPv4-compatible, IPv4-mapped, and IPv4-converted addresses MUST be IPv4-compatible, IPv4-mapped, and IPv4-converted addresses MUST be
treated as having "preferred" (in the RFC 4862 sense) configuration treated as having "preferred" (in the RFC 4862 sense) configuration
status. status.
3.4. IPv6 Loopback Address and Other Format Prefixes 3.4. IPv6 Loopback Address and Other Format Prefixes
The loopback address MUST be treated as having link-local scope The loopback address MUST be treated as having link-local scope
([RFC4007], section 4) and "preferred" (in the RFC 4862 sense) (Section 4 of [RFC4007]) and "preferred" (in the RFC 4862 sense)
configuration status. configuration status.
NSAP addresses and other addresses with as-yet-undefined format NSAP addresses and other addresses with as-yet-undefined format
prefixes MUST be treated as having global scope and "preferred" (in prefixes MUST be treated as having global scope and "preferred" (in
the RFC 4862) configuration status. Later standards might supersede the RFC 4862) configuration status. Later standards might supersede
this treatment. this treatment.
3.5. Mobility Addresses 3.5. Mobility Addresses
Some nodes might support mobility using the concepts of home address Some nodes might support mobility using the concepts of home address
and care-of address (for example see [RFC6275]). Conceptually, a and care-of address (for example, see [RFC6275]). Conceptually, a
home address is an IP address assigned to a mobile node and used as home address is an IP address assigned to a mobile node and used as
the permanent address of the mobile node. A care-of address is an IP the permanent address of the mobile node. A care-of address is an IP
address associated with a mobile node while visiting a foreign link. address associated with a mobile node while visiting a foreign link.
When a mobile node is on its home link, it might have an address that When a mobile node is on its home link, it might have an address that
is simultaneously a home address and a care-of address. is simultaneously a home address and a care-of address.
For the purposes of this document, it is sufficient to know whether For the purposes of this document, it is sufficient to know whether
one's own addresses are designated as home addresses or care-of one's own addresses are designated as home addresses or care-of
addresses. Whether an address ought to be designated a home address addresses. Whether an address ought to be designated a home address
or care-of address is outside the scope of this document. or care-of address is outside the scope of this document.
skipping to change at page 11, line 29 skipping to change at page 10, line 29
Implementations that wish to support the use of global source Implementations that wish to support the use of global source
addresses assigned to a loopback interface MUST behave as if the addresses assigned to a loopback interface MUST behave as if the
loopback interface originates and forwards the packet. loopback interface originates and forwards the packet.
Discussion: The Neighbor Discovery Redirect mechanism [RFC4861] Discussion: The Neighbor Discovery Redirect mechanism [RFC4861]
requires that routers verify that the source address of a packet requires that routers verify that the source address of a packet
identifies a neighbor before generating a Redirect, so it is identifies a neighbor before generating a Redirect, so it is
advantageous for hosts to choose source addresses assigned to the advantageous for hosts to choose source addresses assigned to the
outgoing interface. outgoing interface.
In some cases the destination address might be qualified with a zone In some cases, the destination address might be qualified with a zone
index or other information that will constrain the candidate set. index or other information that will constrain the candidate set.
For all multicast and link-local destination addresses, the set of For all multicast and link-local destination addresses, the set of
candidate source addresses MUST only include addresses assigned to candidate source addresses MUST only include addresses assigned to
interfaces belonging to the same link as the outgoing interface. interfaces belonging to the same link as the outgoing interface.
Discussion: The restriction for multicast destination addresses is Discussion: The restriction for multicast destination addresses is
necessary because currently-deployed multicast forwarding necessary because currently deployed multicast forwarding
algorithms use Reverse Path Forwarding (RPF) checks. algorithms use Reverse Path Forwarding (RPF) checks.
For site-local unicast destination addresses, the set of candidate For site-local unicast destination addresses, the set of candidate
source addresses MUST only include addresses assigned to interfaces source addresses MUST only include addresses assigned to interfaces
belonging to the same site as the outgoing interface. belonging to the same site as the outgoing interface.
In any case, multicast addresses, and the unspecified address MUST In any case, multicast addresses and the unspecified address MUST NOT
NOT be included in a candidate set. be included in a candidate set.
On IPv6-only nodes that support Stateless IP/ICMP Translation (SIIT) On IPv6-only nodes that support Stateless IP/ICMP Translation (SIIT)
[RFC6145], if the destination address is an IPv4-converted address [RFC6145], if the destination address is an IPv4-converted address,
then the candidate set MUST contain only IPv4-translatable addresses. then the candidate set MUST contain only IPv4-translatable addresses.
If an application or upper layer specifies a source address, it may If an application or upper layer specifies a source address, it may
affect the choice of outgoing interface. Regardless, if the affect the choice of outgoing interface. Regardless, if the
application or upper layer specifies a source address that is not in application or upper layer specifies a source address that is not in
the candidate set for the destination, then the network layer MUST the candidate set for the destination, then the network layer MUST
treat this as an error. If the application or upper layer specifies treat this as an error. If the application or upper layer specifies
a source address that is in the candidate set for the destination, a source address that is in the candidate set for the destination,
then the network layer MUST respect that choice. If the application then the network layer MUST respect that choice. If the application
or upper layer does not specify a source address, then the network or upper layer does not specify a source address, then the network
skipping to change at page 12, line 35 skipping to change at page 11, line 38
Note that conceptually, a sort of the candidate set is being Note that conceptually, a sort of the candidate set is being
performed, where a set of rules define the ordering among addresses. performed, where a set of rules define the ordering among addresses.
But because the output of the algorithm is a single source address, But because the output of the algorithm is a single source address,
an implementation need not actually sort the set; it need only an implementation need not actually sort the set; it need only
identify the "maximum" value that ends up at the front of the sorted identify the "maximum" value that ends up at the front of the sorted
list. list.
The ordering of the addresses in the candidate set is defined by a The ordering of the addresses in the candidate set is defined by a
list of eight pair-wise comparison rules, with each rule placing a list of eight pair-wise comparison rules, with each rule placing a
"greater than," "less than" or "equal to" ordering on two source "greater than", "less than", or "equal to" ordering on two source
addresses with respect to each other (and that rule). In the case addresses with respect to each other (and that rule). In the case
that a given rule produces a tie, i.e., provides an "equal to" result that a given rule produces a tie, i.e., provides an "equal to" result
for the two addresses, the remaining rules MUST be applied (in order) for the two addresses, the remaining rules MUST be applied (in order)
to just those addresses that are tied to break the tie. Note that if to just those addresses that are tied to break the tie. Note that if
a rule produces a single clear "winner" (or set of "winners" in the a rule produces a single clear "winner" (or set of "winners" in the
case of ties), those addresses not in the winning set can be case of ties), those addresses not in the winning set can be
discarded from further consideration, with subsequent rules applied discarded from further consideration, with subsequent rules applied
only to the remaining addresses. If the eight rules fail to choose a only to the remaining addresses. If the eight rules fail to choose a
single address, the tie-breaker is implementation-specific. single address, the tiebreaker is implementation-specific.
When comparing two addresses SA and SB from the candidate set, we say When comparing two addresses SA and SB from the candidate set, we say
"prefer SA" to mean that SA is "greater than" SB, and similarly we "prefer SA" to mean that SA is "greater than" SB, and similarly, we
say "prefer SB" to mean that SA is "less than" SB. If neither is say "prefer SB" to mean that SA is "less than" SB. If neither is
stated to be preferred, this means that SA is "equal to" SB and the stated to be preferred, this means that SA is "equal to" SB, and the
remaining rules apply as noted above. remaining rules apply as noted above.
Rule 1: Prefer same address. Rule 1: Prefer same address.
If SA = D, then prefer SA. Similarly, if SB = D, then prefer SB. If SA = D, then prefer SA. Similarly, if SB = D, then prefer SB.
Rule 2: Prefer appropriate scope. Rule 2: Prefer appropriate scope.
If Scope(SA) < Scope(SB): If Scope(SA) < Scope(D), then prefer SB and If Scope(SA) < Scope(SB): If Scope(SA) < Scope(D), then prefer SB and
otherwise prefer SA. Similarly, if Scope(SB) < Scope(SA): If otherwise prefer SA. Similarly, if Scope(SB) < Scope(SA): If
Scope(SB) < Scope(D), then prefer SA and otherwise prefer SB. Scope(SB) < Scope(D), then prefer SA and otherwise prefer SB.
Discussion: This rule must be given high priority because it can Discussion: This rule must be given high priority because it can
affect interoperability. affect interoperability.
Rule 3: Avoid deprecated addresses. Rule 3: Avoid deprecated addresses.
If one of the two source addresses is "preferred" and one of them is If one of the two source addresses is "preferred" and one of them is
"deprecated" (in the RFC 4862 sense), then prefer the one that is "deprecated" (in the RFC 4862 sense), then prefer the one that is
"preferred." "preferred".
Rule 4: Prefer home addresses. Rule 4: Prefer home addresses.
If SA is simultaneously a home address and care-of address and SB is If SA is simultaneously a home address and care-of address and SB is
not, then prefer SA. Similarly, if SB is simultaneously a home not, then prefer SA. Similarly, if SB is simultaneously a home
address and care-of address and SA is not, then prefer SB. If SA is address and care-of address and SA is not, then prefer SB. If SA is
just a home address and SB is just a care-of address, then prefer SA. just a home address and SB is just a care-of address, then prefer SA.
Similarly, if SB is just a home address and SA is just a care-of Similarly, if SB is just a home address and SA is just a care-of
address, then prefer SB. address, then prefer SB.
Implementations supporting home addresses MUST provide a mechanism Implementations supporting home addresses MUST provide a mechanism
skipping to change at page 13, line 41 skipping to change at page 12, line 47
prefer care-of addresses over home addresses (e.g., via appropriate prefer care-of addresses over home addresses (e.g., via appropriate
API extensions such as [RFC5014]). Use of the mechanism MUST only API extensions such as [RFC5014]). Use of the mechanism MUST only
affect the selection rules for the invoking application. affect the selection rules for the invoking application.
Rule 5: Prefer outgoing interface. Rule 5: Prefer outgoing interface.
If SA is assigned to the interface that will be used to send to D and If SA is assigned to the interface that will be used to send to D and
SB is assigned to a different interface, then prefer SA. Similarly, SB is assigned to a different interface, then prefer SA. Similarly,
if SB is assigned to the interface that will be used to send to D and if SB is assigned to the interface that will be used to send to D and
SA is assigned to a different interface, then prefer SB. SA is assigned to a different interface, then prefer SB.
Rule 5.5: Prefer addresses in a prefix advertised by the next-hop Rule 5.5: Prefer addresses in a prefix advertised by the next-hop.
If SA or SA's prefix is assigned by the selected next-hop that will If SA or SA's prefix is assigned by the selected next-hop that will
be used to send to D and SB or SB's prefix is assigned by a different be used to send to D and SB or SB's prefix is assigned by a different
next-hop, then prefer SA. Similarly, if SB or SB's prefix is next-hop, then prefer SA. Similarly, if SB or SB's prefix is
assigned by the next-hop that will be used to send to D and SA or assigned by the next-hop that will be used to send to D and SA or
SA's prefix is assigned by a different next-hop, then prefer SB. SA's prefix is assigned by a different next-hop, then prefer SB.
Discussion: An IPv6 implementation is not required to remember Discussion: An IPv6 implementation is not required to remember
which next-hops advertised which prefixes. The conceptual models which next-hops advertised which prefixes. The conceptual models
of IPv6 hosts in Section 5 of [RFC4861] and Section 3 of [RFC4191] of IPv6 hosts in Section 5 of [RFC4861] and Section 3 of [RFC4191]
have no such requirement. Hence rule 5.5 is only applicable to have no such requirement. Hence, Rule 5.5 is only applicable to
implementations that track this information. implementations that track this information.
Rule 6: Prefer matching label. Rule 6: Prefer matching label.
If Label(SA) = Label(D) and Label(SB) <> Label(D), then prefer SA. If Label(SA) = Label(D) and Label(SB) <> Label(D), then prefer SA.
Similarly, if Label(SB) = Label(D) and Label(SA) <> Label(D), then Similarly, if Label(SB) = Label(D) and Label(SA) <> Label(D), then
prefer SB. prefer SB.
Rule 7: Prefer temporary addresses. Rule 7: Prefer temporary addresses.
If SA is a temporary address and SB is a public address, then prefer If SA is a temporary address and SB is a public address, then prefer
SA. Similarly, if SB is a temporary address and SA is a public SA. Similarly, if SB is a temporary address and SA is a public
address, then prefer SB. address, then prefer SB.
Implementations MUST provide a mechanism allowing an application to Implementations MUST provide a mechanism allowing an application to
reverse the sense of this preference and prefer public addresses over reverse the sense of this preference and prefer public addresses over
temporary addresses (e.g., via appropriate API extensions such as temporary addresses (e.g., via appropriate API extensions such as
[RFC5014]). Use of the mechanism MUST only affect the selection [RFC5014]). Use of the mechanism MUST only affect the selection
rules for the invoking application. This default is intended to rules for the invoking application. This default is intended to
address privacy concerns as discussed in [RFC4941], but introduces a address privacy concerns as discussed in [RFC4941] but introduces a
risk of applications potentially failing due to the relatively short risk of applications potentially failing due to the relatively short
lifetime of temporary addresses or due to the possibility of the lifetime of temporary addresses or due to the possibility of the
reverse lookup of a temporary address either failing or returning a reverse lookup of a temporary address either failing or returning a
randomized name. Implementations for which application compatibility randomized name. Implementations for which application compatibility
considerations outweigh these privacy concerns MAY reverse the sense considerations outweigh these privacy concerns MAY reverse the sense
of this rule and by default prefer public addresses over temporary of this rule and by default prefer public addresses over temporary
addresses. There SHOULD be an administrative option (the Privacy addresses. There SHOULD be an administrative option (the Privacy
Preference flag) to change this preference, if the implementation Preference flag) to change this preference, if the implementation
supports temporary addresses. If there is no such option, there MUST supports temporary addresses. If there is no such option, there MUST
be an administrative option to disable temporary addresses. be an administrative option to disable temporary addresses.
skipping to change at page 15, line 6 skipping to change at page 14, line 17
The destination address selection algorithm takes a list of The destination address selection algorithm takes a list of
destination addresses and sorts the addresses to produce a new list. destination addresses and sorts the addresses to produce a new list.
It is specified here in terms of the pair-wise comparison of It is specified here in terms of the pair-wise comparison of
addresses DA and DB, where DA appears before DB in the original list. addresses DA and DB, where DA appears before DB in the original list.
The algorithm sorts together both IPv6 and IPv4 addresses. To find The algorithm sorts together both IPv6 and IPv4 addresses. To find
the attributes of an IPv4 address in the policy table, the IPv4 the attributes of an IPv4 address in the policy table, the IPv4
address MUST be represented as an IPv4-mapped address. address MUST be represented as an IPv4-mapped address.
We write Source(D) to indicate the selected source address for a We write Source(D) to indicate the selected source address for a
destination D. For IPv6 addresses, the previous section specifies the destination D. For IPv6 addresses, the previous section specifies
source address selection algorithm. Source address selection for the source address selection algorithm. Source address selection for
IPv4 addresses is not specified in this document. IPv4 addresses is not specified in this document.
We say that Source(D) is undefined if there is no source address We say that Source(D) is undefined if there is no source address
available for destination D. For IPv6 addresses, this is only the available for destination D. For IPv6 addresses, this is only the
case if CandidateSource(D) is the empty set. case if CandidateSource(D) is the empty set.
The pair-wise comparison of destination addresses consists of ten The pair-wise comparison of destination addresses consists of ten
rules, which MUST be applied in order. If a rule determines a rules, which MUST be applied in order. If a rule determines a
result, then the remaining rules are not relevant and MUST be result, then the remaining rules are not relevant and MUST be
ignored. Subsequent rules act as tie-breakers for earlier rules. ignored. Subsequent rules act as tiebreakers for earlier rules. See
See the previous section for a lengthier description of how pair-wise the previous section for a lengthier description of how pair-wise
comparison tie-breaker rules can be used to sort a list. comparison tiebreaker rules can be used to sort a list.
Rule 1: Avoid unusable destinations. Rule 1: Avoid unusable destinations.
If DB is known to be unreachable or if Source(DB) is undefined, then If DB is known to be unreachable or if Source(DB) is undefined, then
prefer DA. Similarly, if DA is known to be unreachable or if prefer DA. Similarly, if DA is known to be unreachable or if
Source(DA) is undefined, then prefer DB. Source(DA) is undefined, then prefer DB.
Discussion: An implementation might know that a particular Discussion: An implementation might know that a particular
destination is unreachable in several ways. For example, the destination is unreachable in several ways. For example, the
destination might be reached through a network interface that is destination might be reached through a network interface that is
currently unplugged. For example, the implementation might retain currently unplugged. For example, the implementation might retain
for some period of time information from Neighbor Unreachability information from Neighbor Unreachability Detection [RFC4861] for
Detection [RFC4861]. In any case, the determination of some period of time. In any case, the determination of
unreachability for the purposes of this rule is implementation- unreachability for the purposes of this rule is implementation-
dependent. dependent.
Rule 2: Prefer matching scope. Rule 2: Prefer matching scope.
If Scope(DA) = Scope(Source(DA)) and Scope(DB) <> Scope(Source(DB)), If Scope(DA) = Scope(Source(DA)) and Scope(DB) <> Scope(Source(DB)),
then prefer DA. Similarly, if Scope(DA) <> Scope(Source(DA)) and then prefer DA. Similarly, if Scope(DA) <> Scope(Source(DA)) and
Scope(DB) = Scope(Source(DB)), then prefer DB. Scope(DB) = Scope(Source(DB)), then prefer DB.
Rule 3: Avoid deprecated addresses. Rule 3: Avoid deprecated addresses.
If Source(DA) is deprecated and Source(DB) is not, then prefer DB. If Source(DA) is deprecated and Source(DB) is not, then prefer DB.
skipping to change at page 16, line 20 skipping to change at page 15, line 34
Rule 6: Prefer higher precedence. Rule 6: Prefer higher precedence.
If Precedence(DA) > Precedence(DB), then prefer DA. Similarly, if If Precedence(DA) > Precedence(DB), then prefer DA. Similarly, if
Precedence(DA) < Precedence(DB), then prefer DB. Precedence(DA) < Precedence(DB), then prefer DB.
Rule 7: Prefer native transport. Rule 7: Prefer native transport.
If DA is reached via an encapsulating transition mechanism (e.g., If DA is reached via an encapsulating transition mechanism (e.g.,
IPv6 in IPv4) and DB is not, then prefer DB. Similarly, if DB is IPv6 in IPv4) and DB is not, then prefer DB. Similarly, if DB is
reached via encapsulation and DA is not, then prefer DA. reached via encapsulation and DA is not, then prefer DA.
Discussion: "IPv6 Rapid Deployment on IPv4 Infrastructures" (6rd) Discussion: The IPv6 Rapid Deployment on IPv4 Infrastructures
[RFC5969], the Intra-Site Automatic Tunnel Addressing Protocol (6rd) Protocol [RFC5969], the Intra-Site Automatic Tunnel
(ISATAP) [RFC5214], and configured tunnels [RFC4213] are examples Addressing Protocol (ISATAP) [RFC5214], and configured tunnels
of encapsulating transition mechanisms for which the destination [RFC4213] are examples of encapsulating transition mechanisms for
address does not have a specific prefix and hence can not be which the destination address does not have a specific prefix and
assigned a lower precedence in the policy table. An hence can not be assigned a lower precedence in the policy table.
implementation MAY generalize this rule by using a concept of An implementation MAY generalize this rule by using a concept of
interface preference, and giving virtual interfaces (like the interface preference and giving virtual interfaces (like the IPv6-
IPv6-in-IPv4 encapsulating interfaces) a lower preference than in-IPv4 encapsulating interfaces) a lower preference than native
native interfaces (like ethernet interfaces). interfaces (like ethernet interfaces).
Rule 8: Prefer smaller scope. Rule 8: Prefer smaller scope.
If Scope(DA) < Scope(DB), then prefer DA. Similarly, if Scope(DA) > If Scope(DA) < Scope(DB), then prefer DA. Similarly, if Scope(DA) >
Scope(DB), then prefer DB. Scope(DB), then prefer DB.
Rule 9: Use longest matching prefix. Rule 9: Use longest matching prefix.
When DA and DB belong to the same address family (both are IPv6 or When DA and DB belong to the same address family (both are IPv6 or
both are IPv4): If CommonPrefixLen(Source(DA), DA) > both are IPv4): If CommonPrefixLen(Source(DA), DA) >
CommonPrefixLen(Source(DB), DB), then prefer DA. Similarly, if CommonPrefixLen(Source(DB), DB), then prefer DA. Similarly, if
CommonPrefixLen(Source(DA), DA) < CommonPrefixLen(Source(DB), DB), CommonPrefixLen(Source(DA), DA) < CommonPrefixLen(Source(DB), DB),
then prefer DB. then prefer DB.
Rule 10: Otherwise, leave the order unchanged. Rule 10: Otherwise, leave the order unchanged.
If DA preceded DB in the original list, prefer DA. Otherwise prefer If DA preceded DB in the original list, prefer DA. Otherwise, prefer
DB. DB.
Rules 9 and 10 MAY be superseded if the implementation has other Rules 9 and 10 MAY be superseded if the implementation has other
means of sorting destination addresses. For example, if the means of sorting destination addresses. For example, if the
implementation somehow knows which destination addresses will result implementation somehow knows which destination addresses will result
in the "best" communications performance. in the "best" communications performance.
7. Interactions with Routing 7. Interactions with Routing
This specification of source address selection assumes that routing This specification of source address selection assumes that routing
skipping to change at page 17, line 22 skipping to change at page 16, line 38
For example, suppose a node has interfaces on two different links, For example, suppose a node has interfaces on two different links,
with both links having a working default router. Both of the with both links having a working default router. Both of the
interfaces have preferred (in the RFC 4862 sense) global addresses. interfaces have preferred (in the RFC 4862 sense) global addresses.
When sending to a global destination address, if there's no routing When sending to a global destination address, if there's no routing
reason to prefer one interface over the other, then an implementation reason to prefer one interface over the other, then an implementation
MAY preferentially choose the outgoing interface that will allow it MAY preferentially choose the outgoing interface that will allow it
to use the source address that shares a longer common prefix with the to use the source address that shares a longer common prefix with the
destination. destination.
Implementations that support source address selection (Section 5) Implementations that support Rule 5.5 of source address selection
Rule 5.5 also use the choice of router to influence the choice of (Section 5) also use the choice of router to influence the choice of
source address. For example, suppose a host is on a link with two source address. For example, suppose a host is on a link with two
routers. One router is advertising a global prefix A and the other routers. One router is advertising a global prefix A and the other
router is advertising global prefix B. Then when sending via the router is advertising global prefix B. Then, when sending via the
first router, the host might prefer source addresses with prefix A first router, the host might prefer source addresses with prefix A
and when sending via the second router, prefer source addresses with and when sending via the second router, prefer source addresses with
prefix B. prefix B.
8. Implementation Considerations 8. Implementation Considerations
The destination address selection algorithm needs information about The destination address selection algorithm needs information about
potential source addresses. One possible implementation strategy is potential source addresses. One possible implementation strategy is
for getaddrinfo() to call down to the network layer with a list of for getaddrinfo() to call down to the network layer with a list of
destination addresses, sort the list in the network layer with full destination addresses, sort the list in the network layer with full
current knowledge of available source addresses, and return the current knowledge of available source addresses, and return the
sorted list to getaddrinfo(). This is simple and gives the best sorted list to getaddrinfo(). This is simple and gives the best
results but it introduces the overhead of another system call. One results, but it introduces the overhead of another system call. One
way to reduce this overhead is to cache the sorted address list in way to reduce this overhead is to cache the sorted address list in
the resolver, so that subsequent calls for the same name do not need the resolver, so that subsequent calls for the same name do not need
to resort the list. to re-sort the list.
Another implementation strategy is to call down to the network layer Another implementation strategy is to call down to the network layer
to retrieve source address information and then sort the list of to retrieve source address information and then sort the list of
addresses directly in the context of getaddrinfo(). To reduce addresses directly in the context of getaddrinfo(). To reduce
overhead in this approach, the source address information can be overhead in this approach, the source address information can be
cached, amortizing the overhead of retrieving it across multiple cached, amortizing the overhead of retrieving it across multiple
calls to getaddrinfo(). In this approach, the implementation might calls to getaddrinfo(). In this approach, the implementation might
not have knowledge of the outgoing interface for each destination, so not have knowledge of the outgoing interface for each destination, so
it MAY use a looser definition of the candidate set during it MAY use a looser definition of the candidate set during
destination address ordering. destination address ordering.
In any case, if the implementation uses cached and possibly stale In any case, if the implementation uses cached and possibly stale
information in its implementation of destination address selection, information in its implementation of destination address selection or
or if the ordering of a cached list of destination addresses is if the ordering of a cached list of destination addresses is possibly
possibly stale, then it MUST ensure that the destination address stale, then it MUST ensure that the destination address ordering
ordering returned to the application is no more than one second out returned to the application is no more than one second out of date.
of date. For example, an implementation might make a system call to For example, an implementation might make a system call to check if
check if any routing table entries or source address assignments or any routing table entries, source address assignments, or prefix
prefix policy table entries that might affect these algorithms have policy table entries that might affect these algorithms have changed.
changed. Another strategy is to use an invalidation counter that is Another strategy is to use an invalidation counter that is
incremented whenever any underlying state is changed. By caching the incremented whenever any underlying state is changed. By caching the
current invalidation counter value with derived state and then later current invalidation counter value with derived state and then later
comparing against the current value, the implementation could detect comparing against the current value, the implementation could detect
if the derived state is potentially stale. if the derived state is potentially stale.
9. Security Considerations 9. Security Considerations
This document has no direct impact on Internet infrastructure This document has no direct impact on Internet infrastructure
security. security.
Note that most source address selection algorithms, including the one Note that most source address selection algorithms, including the one
specified in this document, expose a potential privacy concern. An specified in this document, expose a potential privacy concern. An
unfriendly node can infer correlations among a target node's unfriendly node can infer correlations among a target node's
addresses by probing the target node with request packets that force addresses by probing the target node with request packets that force
the target host to choose its source address for the reply packets. the target host to choose its source address for the reply packets
(Perhaps because the request packets are sent to an anycast or (perhaps because the request packets are sent to an anycast or
multicast address, or perhaps the upper-layer protocol chosen for the multicast address or perhaps because the upper-layer protocol chosen
attack does not specify a particular source address for its reply for the attack does not specify a particular source address for its
packets.) By using different addresses for itself, the unfriendly reply packets). By using different addresses for itself, the
node can cause the target node to expose the target's own addresses. unfriendly node can cause the target node to expose the target's own
The source address selection default preference for temporary addresses. The source address selection default preference for
addresses helps mitigate this concern. temporary addresses helps mitigate this concern.
Similarly, most source and destination address selection algorithms, Similarly, most source and destination address selection algorithms,
including the one specified in this document, influence the choice of including the one specified in this document, influence the choice of
network path taken (as do routing algorithms that are orthogonal to, network path taken (as do routing algorithms that are orthogonal to,
but used together with such algorithms) and hence whether data might but used together with, such algorithms) and hence whether data might
be sent over a path or network that might be more or less trusted be sent over a path or network that might be more or less trusted
than other paths or networks. Administrators should consider the than other paths or networks. Administrators should consider the
security impact of the rows they configure in the prefix policy security impact of the rows they configure in the prefix policy
table, just as they should consider the security impact of the table, just as they should consider the security impact of the
interface metrics used in the routing algorithms. interface metrics used in the routing algorithms.
In addition, some address selection rules might be administratively In addition, some address selection rules might be administratively
configurable. Care must be taken to make sure that all configurable. Care must be taken to make sure that all
administrative options are secured against illicit modification, or administrative options are secured against illicit modification, or
else an attacker could redirect and/or block traffic. else an attacker could redirect and/or block traffic.
10. Examples 10. Examples
This section contains a number of examples, first of default behavior This section contains a number of examples, first showing default
and then demonstrating the utility of policy table configuration. behavior and then demonstrating the utility of policy table
These examples are provided for illustrative purposes; they are not configuration. These examples are provided for illustrative
to be construed as normative. purposes; they are not to be construed as normative.
10.1. Default Source Address Selection 10.1. Default Source Address Selection
The source address selection rules, in conjunction with the default The source address selection rules, in conjunction with the default
policy table, produce the following behavior: policy table, produce the following behavior:
Destination: 2001:db8:1::1 Destination: 2001:db8:1::1
Candidate Source Addresses: 2001:db8:3::1 or fe80::1 Candidate Source Addresses: 2001:db8:3::1 or fe80::1
Result: 2001:db8::1 (prefer appropriate scope) Result: 2001:db8::1 (prefer appropriate scope)
skipping to change at page 19, line 37 skipping to change at page 18, line 51
Candidate Source Addresses: 2001:db8:1::1 (deprecated) or Candidate Source Addresses: 2001:db8:1::1 (deprecated) or
2001:db8:2::1 2001:db8:2::1
Result: 2001:db8:1::1 (prefer same address) Result: 2001:db8:1::1 (prefer same address)
Destination: fe80::1 Destination: fe80::1
Candidate Source Addresses: fe80::2 (deprecated) or 2001:db8:1::1 Candidate Source Addresses: fe80::2 (deprecated) or 2001:db8:1::1
Result: fe80::2 (prefer appropriate scope) Result: fe80::2 (prefer appropriate scope)
Destination: 2001:db8:1::1 Destination: 2001:db8:1::1
Candidate Source Addresses: 2001:db8:1::2 or 2001:db8:3::2 Candidate Source Addresses: 2001:db8:1::2 or 2001:db8:3::2
Result: 2001:db8:1:::2 (longest-matching-prefix) Result: 2001:db8:1:::2 (longest matching prefix)
Destination: 2001:db8:1::1 Destination: 2001:db8:1::1
Candidate Source Addresses: 2001:db8:1::2 (care-of address) or 2001: Candidate Source Addresses: 2001:db8:1::2 (care-of address) or 2001:
db8:3::2 (home address) db8:3::2 (home address)
Result: 2001:db8:3::2 (prefer home address) Result: 2001:db8:3::2 (prefer home address)
Destination: 2002:c633:6401::1 Destination: 2002:c633:6401::1
Candidate Source Addresses: 2002:c633:6401::d5e3:7953:13eb:22e8 Candidate Source Addresses: 2002:c633:6401::d5e3:7953:13eb:22e8
(temporary) or 2001:db8:1::2 (temporary) or 2001:db8:1::2
Result: 2002:c633:6401::d5e3:7953:13eb:22e8 (prefer matching label) Result: 2002:c633:6401::d5e3:7953:13eb:22e8 (prefer matching label)
Destination: 2001:db8:1::d5e3:0:0:1 Destination: 2001:db8:1::d5e3:0:0:1
Candidate Source Addresses: 2001:db8:1::2 or 2001:db8:1::d5e3:7953: Candidate Source Addresses: 2001:db8:1::2 (public) or
2001:db8:1::d5e3:7953:13eb:22e8 (temporary)
13eb:22e8 (temporary) Result: 2001:db8:1::d5e3:7953:13eb:22e8 (prefer temporary address)
Result: 2001:db8:1::2 (prefer public address)
10.2. Default Destination Address Selection 10.2. Default Destination Address Selection
The destination address selection rules, in conjunction with the The destination address selection rules, in conjunction with the
default policy table and the source address selection rules, produce default policy table and the source address selection rules, produce
the following behavior: the following behavior:
Candidate Source Addresses: 2001:db8:1::2 or fe80::1 or 169.254.13.78 Candidate Source Addresses: 2001:db8:1::2 or fe80::1 or 169.254.13.78
Destination Address List: 2001:db8:1::1 or 198.51.100.121 Destination Address List: 2001:db8:1::1 or 198.51.100.121
Result: 2001:db8:1::1 (src 2001:db8:1::2) then 198.51.100.121 (src Result: 2001:db8:1::1 (src 2001:db8:1::2) then 198.51.100.121 (src
skipping to change at page 22, line 8 skipping to change at page 21, line 17
2001:db8::1 (src fe80::1) (prefer matching scope) 2001:db8::1 (src fe80::1) (prefer matching scope)
Candidate Source Addresses: 2001:db8::2 or fe80::1 or 10.1.2.4 Candidate Source Addresses: 2001:db8::2 or fe80::1 or 10.1.2.4
Destination Address List: 2001:db8::1 or 10.1.2.3 Destination Address List: 2001:db8::1 or 10.1.2.3
New Result: 10.1.2.3 (src 10.1.2.4) then 2001:db8::1 (src New Result: 10.1.2.3 (src 10.1.2.4) then 2001:db8::1 (src
2001:db8::2) (prefer higher precedence) 2001:db8::2) (prefer higher precedence)
10.3.1. Handling Broken IPv6 10.3.1. Handling Broken IPv6
One problem in practice that has been recently observed occurs when a One problem in practice that has been recently observed occurs when a
host has IPv4 connectivity to the Internet, but has "broken" IPv6 host has IPv4 connectivity to the Internet but has "broken" IPv6
connectivity to the Internet in that it has a global IPv6 address, connectivity to the Internet in that it has a global IPv6 address but
but is discconnected from the IPv6 Internet. Since the default is disconnected from the IPv6 Internet. Since the default policy
policy table prefers IPv6, this can result in unwanted timeouts. table prefers IPv6, this can result in unwanted timeouts.
This can be solved by configuring the table to prefer IPv4 as shown This can be solved by configuring the table to prefer IPv4 as shown
above. An implementation that has some means to detect that it is above. An implementation that has some means to detect that it is
not connected to the IPv6 Internet MAY do this automatically. An not connected to the IPv6 Internet MAY do this automatically. An
implementation could instead treat it as part of its implementation implementation could instead treat it as part of its implementation
of Rule 1 (avoid unusable destinations). of Rule 1 (avoid unusable destinations).
10.4. Configuring Preference for Link-Local Addresses 10.4. Configuring Preference for Link-Local Addresses
The destination address selection rules give preference to The destination address selection rules give preference to
skipping to change at page 23, line 8 skipping to change at page 22, line 21
(prefer higher precedence) (prefer higher precedence)
Candidate Source Addresses: 2001:db8::2 (deprecated) or fe80::2 Candidate Source Addresses: 2001:db8::2 (deprecated) or fe80::2
Destination Address List: 2001:db8::1 or fe80::1 Destination Address List: 2001:db8::1 or fe80::1
Unchanged Result: fe80::1 (src fe80::2) then 2001:db8::1 (src 2001: Unchanged Result: fe80::1 (src fe80::2) then 2001:db8::1 (src 2001:
db8::2) (avoid deprecated addresses) db8::2) (avoid deprecated addresses)
10.5. Configuring a Multi-Homed Site 10.5. Configuring a Multi-Homed Site
Consider a site A that has a business-critical relationship with Consider a site A that has a business-critical relationship with
another site B. To support their business needs, the two sites have another site B. To support their business needs, the two sites have
contracted for service with a special high-performance ISP. This is contracted for service with a special high-performance ISP. This is
in addition to the normal Internet connection that both sites have in addition to the normal Internet connection that both sites have
with different ISPs. The high-performance ISP is expensive and the with different ISPs. The high-performance ISP is expensive, and the
two sites wish to use it only for their business-critical traffic two sites wish to use it only for their business-critical traffic
with each other. with each other.
Each site has two global prefixes, one from the high-performance ISP Each site has two global prefixes, one from the high-performance ISP
and one from their normal ISP. Site A has prefix 2001:db8:1aaa::/48 and one from their normal ISP. Site A has prefix 2001:db8:1aaa::/48
from the high-performance ISP and prefix 2001:db8:70aa::/48 from its from the high-performance ISP and prefix 2001:db8:70aa::/48 from its
normal ISP. Site B has prefix 2001:db8:1bbb::/48 from the high- normal ISP. Site B has prefix 2001:db8:1bbb::/48 from the high-
performance ISP and prefix 2001:db8:70bb::/48 from its normal ISP. performance ISP and prefix 2001:db8:70bb::/48 from its normal ISP.
All hosts in both sites register two addresses in the DNS. All hosts in both sites register two addresses in the DNS.
skipping to change at page 24, line 48 skipping to change at page 24, line 17
Destination Address List: 2001:db8:1ccc::c or 2001:db8:6ccc::c Destination Address List: 2001:db8:1ccc::c or 2001:db8:6ccc::c
New Result: 2001:db8:6ccc::c (src 2001:db8:70aa::a) then 2001:db8: New Result: 2001:db8:6ccc::c (src 2001:db8:70aa::a) then 2001:db8:
1ccc::c (src 2001:db8:70aa::a) (longest matching prefix) 1ccc::c (src 2001:db8:70aa::a) (longest matching prefix)
In other words, when a host in site A initiates a connection to a In other words, when a host in site A initiates a connection to a
host in some other site C, the traffic uses the normal ISP as host in some other site C, the traffic uses the normal ISP as
desired. desired.
10.6. Configuring ULA Preference 10.6. Configuring ULA Preference
RFC 5220 [RFC5220] sections 2.1.4, 2.2.2, and 2.2.3 describe address Sections 2.1.4, 2.2.2, and 2.2.3 of RFC 5220 [RFC5220] describe
selection problems related to Unique Local Addresses (ULAs) address selection problems related to Unique Local Addresses (ULAs)
[RFC4193]. By default, global IPv6 destinations are preferred over [RFC4193]. By default, global IPv6 destinations are preferred over
ULA destinations, since an arbitrary ULA is not necessarily ULA destinations, since an arbitrary ULA is not necessarily
reachable: reachable:
Candidate Source Addresses: 2001:db8:1::1 or fd11:1111:1111:1::1 Candidate Source Addresses: 2001:db8:1::1 or fd11:1111:1111:1::1
Destination Address List: 2001:db8:2::2 or fd22:2222:2222:2::2 Destination Address List: 2001:db8:2::2 or fd22:2222:2222:2::2
Result: 2001:db8:2::2 (src 2001:db8:1::1) then fd22:2222:2222:2::2 Result: 2001:db8:2::2 (src 2001:db8:1::1) then fd22:2222:2222:2::2
(src fd11:1111:1111:1::1) (prefer higher precedence) (src fd11:1111:1111:1::1) (prefer higher precedence)
However, a site-specific policy entry can be used to cause ULAs However, a site-specific policy entry can be used to cause ULAs
skipping to change at page 25, line 51 skipping to change at page 25, line 23
such, the existence of one or more rows in the prefix policy table is such, the existence of one or more rows in the prefix policy table is
important so that source address selection does not choose a ULA important so that source address selection does not choose a ULA
purely based on longest match: purely based on longest match:
Candidate Source Addresses: 2001:db8:1::1 or fd11:1111:1111:1::1 Candidate Source Addresses: 2001:db8:1::1 or fd11:1111:1111:1::1
Destination Address List: ff00:1 Destination Address List: ff00:1
Result: 2001:db8:1::1 (prefer matching label) Result: 2001:db8:1::1 (prefer matching label)
10.7. Configuring 6to4 Preference 10.7. Configuring 6to4 Preference
By default, NAT'ed IPv4 is preferred over 6to4-relayed connectivity: By default, NATed IPv4 is preferred over 6to4-relayed connectivity:
Candidate Source Addresses: 2002:c633:6401::2 or 10.1.2.3 Candidate Source Addresses: 2002:c633:6401::2 or 10.1.2.3
Destination Address List: 2001:db8:1::1 or 203.0.113.1 Destination Address List: 2001:db8:1::1 or 203.0.113.1
Result: 203.0.113.1 (src 10.1.2.3) then 2001:db8:1::1 (src 2002:c633: Result: 203.0.113.1 (src 10.1.2.3) then 2001:db8:1::1 (src 2002:c633:
6401::2) (prefer matching label) 6401::2) (prefer matching label)
However, NAT'ed IPv4 is now also preferred over 6to4-to-6to4 However, NATed IPv4 is now also preferred over 6to4-to-6to4
connectivity by default. Since a 6to4 prefix might be used natively connectivity by default. Since a 6to4 prefix might be used natively
within an organization, a site-specific policy entry can be used to within an organization, a site-specific policy entry can be used to
cause native IPv6 communication (using a 6to4 prefix) to be preferred cause native IPv6 communication (using a 6to4 prefix) to be preferred
over NAT'ed IPv4 as follows. over NATed IPv4 as follows.
Prefix Precedence Label Prefix Precedence Label
::1/128 50 0 ::1/128 50 0
2002:c633:6401::/48 45 14 2002:c633:6401::/48 45 14
::/0 40 1 ::/0 40 1
::ffff:0:0/96 35 4 ::ffff:0:0/96 35 4
2002::/16 30 2 2002::/16 30 2
2001::/32 5 5 2001::/32 5 5
fc00::/7 3 13 fc00::/7 3 13
::/96 1 3 ::/96 1 3
skipping to change at page 26, line 39 skipping to change at page 26, line 16
Candidate Source Addresses: 2002:c633:6401:1::1 or 10.1.2.3 Candidate Source Addresses: 2002:c633:6401:1::1 or 10.1.2.3
Destination Address List: 2002:c633:6401:2::2 or 203.0.113.1 Destination Address List: 2002:c633:6401:2::2 or 203.0.113.1
New Result: 2002:c633:6401:2::2 (src 2002:c633:6401:1::1) then New Result: 2002:c633:6401:2::2 (src 2002:c633:6401:1::1) then
203.0.113.1 (sec 10.1.2.3) (prefer higher precedence) 203.0.113.1 (sec 10.1.2.3) (prefer higher precedence)
Since 6to4 addresses are defined to have a /48 site prefix, an Since 6to4 addresses are defined to have a /48 site prefix, an
implementation might choose to add such a row automatically on a implementation might choose to add such a row automatically on a
machine with a native IPv6 address with a 6to4 prefix. machine with a native IPv6 address with a 6to4 prefix.
11. IANA Considerations 11. References
This document has no IANA actions. 11.1. Normative References
12. References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
12.1. Normative References [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6
Domains via IPv4 Clouds", RFC 3056, February 2001.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local
Requirement Levels", BCP 14, RFC 2119, March 1997. Addresses", RFC 3879, September 2004.
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6
via IPv4 Clouds", RFC 3056, February 2001. Unicast Addresses", RFC 4193, October 2005.
[RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Addresses", RFC 3879, September 2004. Architecture", RFC 4291, February 2006.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
Addresses", RFC 4193, October 2005. Network Address Translations (NATs)", RFC 4380,
February 2006.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6
Architecture", RFC 4291, February 2006. Stateless Address Autoconfiguration", RFC 4862,
September 2007.
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Network Address Translations (NATs)", RFC 4380, Extensions for Stateless Address Autoconfiguration in
February 2006. IPv6", RFC 4941, September 2007.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
Address Autoconfiguration", RFC 4862, September 2007. Algorithm", RFC 6145, April 2011.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 11.2. Informative References
Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, September 2007.
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation [ADDR-SEL-OPT] Matsumoto, A., Fujisaki, T., Kato, J., and T. Chown,
Algorithm", RFC 6145, April 2011. "Distributing Address Selection Policy using DHCPv6",
Work in Progress, August 2012.
12.2. Informative References [RFC1794] Brisco, T., "DNS Support for Load Balancing",
RFC 1794, April 1995.
[I-D.ietf-6man-addr-select-opt] [RFC1812] Baker, F., "Requirements for IP Version 4 Routers",
Matsumoto, A., Fujisaki, T., Kato, J., and T. Chown, RFC 1812, June 1995.
"Distributing Address Selection Policy using DHCPv6",
draft-ietf-6man-addr-select-opt-03 (work in progress),
February 2012.
[RFC1794] Brisco, T., "DNS Support for Load Balancing", RFC 1794, [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot,
April 1995. G., and E. Lear, "Address Allocation for Private
Internets", BCP 5, RFC 1918, February 1996.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and [RFC2827] Ferguson, P. and D. Senie, "Network Ingress
E. Lear, "Address Allocation for Private Internets", Filtering: Defeating Denial of Service Attacks which
BCP 5, RFC 1918, February 1996. employ IP Source Address Spoofing", BCP 38, RFC 2827,
May 2000.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: [RFC3484] Draves, R., "Default Address Selection for Internet
Defeating Denial of Service Attacks which employ IP Source Protocol version 6 (IPv6)", RFC 3484, February 2003.
Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and
Stevens, "Basic Socket Interface Extensions for IPv6", W. Stevens, "Basic Socket Interface Extensions for
RFC 3493, February 2003. IPv6", RFC 3493, February 2003.
[RFC3701] Fink, R. and R. Hinden, "6bone (IPv6 Testing Address [RFC3701] Fink, R. and R. Hinden, "6bone (IPv6 Testing Address
Allocation) Phaseout", RFC 3701, March 2004. Allocation) Phaseout", RFC 3701, March 2004.
[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
Configuration of IPv4 Link-Local Addresses", RFC 3927, Configuration of IPv4 Link-Local Addresses",
May 2005. RFC 3927, May 2005.
[RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and [RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E.,
B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, and B. Zill, "IPv6 Scoped Address Architecture",
March 2005. RFC 4007, March 2005.
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences
More-Specific Routes", RFC 4191, November 2005. and More-Specific Routes", RFC 4191, November 2005.
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition
for IPv6 Hosts and Routers", RFC 4213, October 2005. Mechanisms for IPv6 Hosts and Routers", RFC 4213,
October 2005.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H.
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, Soliman, "Neighbor Discovery for IP version 6
September 2007. (IPv6)", RFC 4861, September 2007.
[RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6 [RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6
Socket API for Source Address Selection", RFC 5014, Socket API for Source Address Selection", RFC 5014,
September 2007. September 2007.
[RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site
Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, Automatic Tunnel Addressing Protocol (ISATAP)",
March 2008. RFC 5214, March 2008.
[RFC5220] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, [RFC5220] Matsumoto, A., Fujisaki, T., Hiromi, R., and K.
"Problem Statement for Default Address Selection in Multi- Kanayama, "Problem Statement for Default Address
Prefix Environments: Operational Issues of RFC 3484 Selection in Multi-Prefix Environments: Operational
Default Rules", RFC 5220, July 2008. Issues of RFC 3484 Default Rules", RFC 5220,
July 2008.
[RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on
Infrastructures (6rd) -- Protocol Specification", IPv4 Infrastructures (6rd) -- Protocol
RFC 5969, August 2010. Specification", RFC 5969, August 2010.
[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility
in IPv6", RFC 6275, July 2011. Support in IPv6", RFC 6275, July 2011.
[RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and [RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe,
M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address C., and M. Azinger, "IANA-Reserved IPv4 Prefix for
Space", BCP 153, RFC 6598, April 2012. Shared Address Space", BCP 153, RFC 6598, April 2012.
Appendix A. Acknowledgements Appendix A. Acknowledgements
RFC 3484 acknowledged the contributions of the IPng Working Group, RFC 3484 [RFC3484] acknowledged the contributions of the IPng Working
particularly Marc Blanchet, Brian Carpenter, Matt Crawford, Alain Group, particularly Marc Blanchet, Brian Carpenter, Matt Crawford,
Durand, Steve Deering, Robert Elz, Jun-ichiro itojun Hagino, Tony Alain Durand, Steve Deering, Robert Elz, Jun-ichiro itojun Hagino,
Hain, M.T. Hollinger, JINMEI Tatuya, Thomas Narten, Erik Nordmark, Tony Hain, M.T. Hollinger, JINMEI Tatuya, Thomas Narten, Erik
Ken Powell, Markku Savela, Pekka Savola, Hesham Soliman, Dave Thaler, Nordmark, Ken Powell, Markku Savela, Pekka Savola, Hesham Soliman,
Mauro Tortonesi, Ole Troan, and Stig Venaas. In addition, the Dave Thaler, Mauro Tortonesi, Ole Troan, and Stig Venaas. In
anonymous IESG reviewers had many great comments and suggestions for addition, the anonymous IESG reviewers had many great comments and
clarification. suggestions for clarification.
This revision was heavily influenced by the work by Arifumi This revision was heavily influenced by the work by Arifumi
Matsumoto, Jun-ya Kato, and Tomohiro Fujisaki in a working draft that Matsumoto, Jun-ya Kato, and Tomohiro Fujisaki in a working document
made proposals for this revision to adopt, with input from Pekka that made proposals for this revision to adopt, with input from Pekka
Savola, Remi Denis-Courmont, Francois-Xavier Le Bail, and the 6man Savola, Remi Denis-Courmont, Francois-Xavier Le Bail, and the 6man
Working Group. Dmitry Anipko, Mark Andrews, Ray Hunter, and Wes Working Group. Dmitry Anipko, Mark Andrews, Ray Hunter, and Wes
George also provided valuable feedback on this revision. George also provided valuable feedback on this revision.
Appendix B. Changes Since RFC 3484 Appendix B. Changes since RFC 3484
Some changes were made to the default policy table that were deemed Some changes were made to the default policy table that were deemed
to be universally useful and cause no harm in every reasonable to be universally useful and cause no harm in every reasonable
network environment. In doing so, care was taken to use the same network environment. In doing so, care was taken to use the same
preference and label values as in RFC 3484 whenever possible, and for preference and label values as in RFC 3484 whenever possible and for
new rows to use label values less likely to collide with values that new rows to use label values less likely to collide with values that
might already be in use in additional rows on some hosts. These might already be in use in additional rows on some hosts. These
changes are: changes are:
1. Added the Teredo [RFC4380] prefix (2001::/32), with the 1. Added the Teredo [RFC4380] prefix (2001::/32), with the
preference and label values already widely used in popular preference and label values already widely used in popular
implementations. implementations.
2. Added a row for ULAs (fc00::/7) below native IPv6 since they are 2. Added a row for ULAs (fc00::/7) below native IPv6 since they are
not globally reachable, as discussed in Section 10.6. not globally reachable, as discussed in Section 10.6.
3. Added a row for site-local addresses (fec0::/10) in order to 3. Added a row for site-local addresses (fec0::/10) in order to
depreference them, for consistency with the example in depreference them, for consistency with the example in
Section 10.3, since they are deprecated [RFC3879]. Section 10.3, since they are deprecated [RFC3879].
4. Depreferenced 6to4 (2002::/32) below native IPv4 since 6to4 4. Depreferenced 6to4 (2002::/32) below native IPv4 since 6to4
connectivity is less reliable today (and is expected to be phased connectivity is less reliable today (and is expected to be phased
out over time, rather than becoming more reliable). It remains out over time, rather than becoming more reliable). It remains
above Teredo since 6to4 is more efficient in terms of connection above Teredo since 6to4 is more efficient in terms of connection
establishment time, bandwidth, and server load. establishment time, bandwidth, and server load.
5. Depreferenced IPv4-Compatible addresses (::/96) since they are 5. Depreferenced IPv4-Compatible addresses (::/96) since they are
now deprecated [RFC4291] and not in common use. now deprecated [RFC4291] and not in common use.
6. Added a row for 6bone testing addresses (3ffe::/16) in order to 6. Added a row for 6bone testing addresses (3ffe::/16) in order to
depreference them as they have also been phased out [RFC3701]. depreference them as they have also been phased out [RFC3701].
7. Added optional ability for an implementation to add automatic 7. Added optional ability for an implementation to add automatic
rows to the table for site-specific ULA prefixes and site- rows to the table for site-specific ULA prefixes and site-
specific native 6to4 prefixes. specific native 6to4 prefixes.
Similarly, some changes were made to the rules, as follows: Similarly, some changes were made to the rules, as follows:
1. Changed the definition of CommonPrefixLen() to only compare bits 1. Changed the definition of CommonPrefixLen() to only compare bits
skipping to change at page 30, line 20 skipping to change at page 30, line 23
1. Changed the definition of CommonPrefixLen() to only compare bits 1. Changed the definition of CommonPrefixLen() to only compare bits
up to the source address's prefix length. The previous up to the source address's prefix length. The previous
definition used the entire source address, rather than only its definition used the entire source address, rather than only its
prefix. As a result, when a source and destination addresses had prefix. As a result, when a source and destination addresses had
the same prefix, common bits in the interface ID would previously the same prefix, common bits in the interface ID would previously
result in overriding DNS load balancing [RFC1794] by forcing the result in overriding DNS load balancing [RFC1794] by forcing the
destination address with the most bits in common to be always destination address with the most bits in common to be always
chosen. The updated definition allows DNS load balancing to chosen. The updated definition allows DNS load balancing to
continue to be used as a tie breaker. continue to be used as a tie breaker.
2. Added Rule 5.5 to allow choosing a source address from a prefix 2. Added Rule 5.5 to allow choosing a source address from a prefix
advertised by the chosen next-hop for a given destination. This advertised by the chosen next-hop for a given destination. This
allows better connectivity in the presence of BCP 38 [RFC2827] allows better connectivity in the presence of BCP 38 [RFC2827]
ingress filtering and egress filtering. Previously, RFC 3484 had ingress filtering and egress filtering. Previously, RFC 3484 had
issues with multiple egress networks reached via the same issues with multiple egress networks reached via the same
interface, as discussed in [RFC5220]. interface, as discussed in [RFC5220].
3. Removed restriction against anycast addresses in the candidate 3. Removed restriction against anycast addresses in the candidate
set of source addresses, since the restriction against using IPv6 set of source addresses, since the restriction against using IPv6
anycast addresses as source addresses was removed in Section 2.6 anycast addresses as source addresses was removed in Section 2.6
of RFC 4291 [RFC4291]. of RFC 4291 [RFC4291].
4. Changed mapping of RFC 1918 [RFC1918] addresses to global scope 4. Changed mapping of RFC 1918 [RFC1918] addresses to global scope
in Section 3.2. Previously they were mapped to site-local scope. in Section 3.2. Previously, they were mapped to site-local
However, experience has resulted in current implementations scope. However, experience has resulted in current
already using global scope instead. When they were mapped to implementations already using global scope instead. When they
site-local, Destination Address Selection Rule 2 (Prefer matching were mapped to site-local, Destination Address Selection Rule 2
scope) would cause IPv6 to be preferred in scenarios such as that (Prefer matching scope) would cause IPv6 to be preferred in
described in Section 10.7. The change to global scope allows scenarios such as that described in Section 10.7. The change to
configurability via the prefix policy table. global scope allows configurability via the prefix policy table.
5. Changed the default recommendation for Source Address Selection 5. Changed the default recommendation for Source Address Selection
Rule 7 to prefer temporary addresses rather than public Rule 7 to prefer temporary addresses rather than public
addresses, while providing an administrative override (in addresses, while providing an administrative override (in
addition to the application-specific override that was already addition to the application-specific override that was already
specified). This change was made because of the increasing specified). This change was made because of the increasing
importance of privacy considerations, as well as the fact that importance of privacy considerations, as well as the fact that
widely deployed implementations have preferred temporary widely deployed implementations have preferred temporary
addresses for many years without major application issues. addresses for many years without major application issues.
Finally, some editorial changes were made, including: Finally, some editorial changes were made, including:
1. Changed global IP addresses in examples to use ranges reserved 1. Changed global IP addresses in examples to use ranges reserved
for documentation. for documentation.
2. Added additional examples in Section 10.6 and Section 10.7. 2. Added additional examples in Sections 10.6 and 10.7.
3. Added Section 10.3.1 on "broken" IPv6. 3. Added Section 10.3.1 on "broken" IPv6.
4. Updated references. 4. Updated references.
Authors' Addresses Authors' Addresses
Dave Thaler (editor) Dave Thaler (editor)
Microsoft Microsoft
One Microsoft Way One Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
USA
Phone: +1 425 703 8835 Phone: +1 425 703 8835
Email: dthaler@microsoft.com EMail: dthaler@microsoft.com
Richard Draves Richard Draves
Microsoft Research Microsoft Research
One Microsoft Way One Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
USA
Phone: +1 425 706 2268 Phone: +1 425 706 2268
Email: richdr@microsoft.com EMail: richdr@microsoft.com
Arifumi Matsumoto Arifumi Matsumoto
NTT SI Lab NTT SI Lab
Midori-Cho 3-9-11 Midori-Cho 3-9-11
Musashino-shi, Tokyo 180-8585 Musashino-shi, Tokyo 180-8585
Japan Japan
Phone: +81 422 59 3334 Phone: +81 422 59 3334
Email: arifumi@nttv6.net EMail: arifumi@nttv6.net
Tim Chown Tim Chown
University of Southampt on University of Southampt on
Southampton, Hampshire SO17 1BJ Southampton, Hampshire SO17 1BJ
United Kingdom United Kingdom
Email: tjc@ecs.soton.ac.uk EMail: tjc@ecs.soton.ac.uk
 End of changes. 131 change blocks. 
291 lines changed or deleted 304 lines changed or added

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