draft-ietf-6man-rfc3484bis-04.txt   draft-ietf-6man-rfc3484bis-05.txt 
Network Working Group D. Thaler, Ed. Network Working Group D. Thaler, Ed.
Internet-Draft Microsoft Internet-Draft Microsoft
Obsoletes: 3484 (if approved) R. Draves Obsoletes: 3484 (if approved) R. Draves
Intended status: Standards Track Microsoft Research Intended status: Standards Track Microsoft Research
Expires: November 16, 2012 A. Matsumoto Expires: December 2, 2012 A. Matsumoto
NTT NTT
T. Chown T. Chown
University of Southampton University of Southampton
May 15, 2012 May 31, 2012
Default Address Selection for Internet Protocol version 6 (IPv6) Default Address Selection for Internet Protocol version 6 (IPv6)
draft-ietf-6man-rfc3484bis-04.txt draft-ietf-6man-rfc3484bis-05.txt
Abstract Abstract
This document describes two algorithms, for source address selection This document describes two algorithms, one for source address
and for destination address selection. The algorithms specify selection and one for destination address selection. The algorithms
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.
All IPv6 nodes, including both hosts and routers, must implement Default address selection as defined in this specification applies to
default address selection as defined in this specification. This all IPv6 nodes, including both hosts and routers. This document
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 Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 16, 2012. This Internet-Draft will expire on December 2, 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
skipping to change at page 3, line 16 skipping to change at page 3, line 16
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Conventions Used in This Document . . . . . . . . . . . . 5 1.1. Conventions Used in This Document . . . . . . . . . . . . 5
2. Context in Which the Algorithms Operate . . . . . . . . . . . 5 2. Context in Which the Algorithms Operate . . . . . . . . . . . 5
2.1. Policy Table . . . . . . . . . . . . . . . . . . . . . . . 7 2.1. Policy Table . . . . . . . . . . . . . . . . . . . . . . . 7
2.2. Common Prefix Length . . . . . . . . . . . . . . . . . . . 8 2.2. Common Prefix Length . . . . . . . . . . . . . . . . . . . 8
3. Address Properties . . . . . . . . . . . . . . . . . . . . . . 8 3. Address Properties . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Scope Comparisons . . . . . . . . . . . . . . . . . . . . 8 3.1. Scope Comparisons . . . . . . . . . . . . . . . . . . . . 8
3.2. IPv4 Addresses and IPv4-Mapped Addresses . . . . . . . . . 9 3.2. IPv4 Addresses and IPv4-Mapped Addresses . . . . . . . . . 9
3.3. Other IPv6 Addresses with Embedded IPv4 Addresses . . . . 9 3.3. Other IPv6 Addresses with Embedded IPv4 Addresses . . . . 9
3.4. IPv6 Loopback Address and Other Format Prefixes . . . . . 9 3.4. IPv6 Loopback Address and Other Format Prefixes . . . . . 10
3.5. Mobility Addresses . . . . . . . . . . . . . . . . . . . . 10 3.5. Mobility Addresses . . . . . . . . . . . . . . . . . . . . 10
4. Candidate Source Addresses . . . . . . . . . . . . . . . . . . 10 4. Candidate Source Addresses . . . . . . . . . . . . . . . . . . 10
5. Source Address Selection . . . . . . . . . . . . . . . . . . . 11 5. Source Address Selection . . . . . . . . . . . . . . . . . . . 11
6. Destination Address Selection . . . . . . . . . . . . . . . . 14 6. Destination Address Selection . . . . . . . . . . . . . . . . 14
7. Interactions with Routing . . . . . . . . . . . . . . . . . . 16 7. Interactions with Routing . . . . . . . . . . . . . . . . . . 16
8. Implementation Considerations . . . . . . . . . . . . . . . . 16 8. Implementation Considerations . . . . . . . . . . . . . . . . 17
9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17
10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
10.1. Default Source Address Selection . . . . . . . . . . . . . 18 10.1. Default Source Address Selection . . . . . . . . . . . . . 18
10.2. Default Destination Address Selection . . . . . . . . . . 19 10.2. Default Destination Address Selection . . . . . . . . . . 19
10.3. Configuring Preference for IPv6 or IPv4 . . . . . . . . . 20 10.3. Configuring Preference for IPv6 or IPv4 . . . . . . . . . 20
10.3.1. Handling Broken IPv6 . . . . . . . . . . . . . . . . 21 10.3.1. Handling Broken IPv6 . . . . . . . . . . . . . . . . 21
10.4. Configuring Preference for Link-Local Addresses . . . . . 21 10.4. Configuring Preference for Link-Local Addresses . . . . . 21
10.5. Configuring a Multi-Homed Site . . . . . . . . . . . . . . 22 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 . . . . . . . . . . . . . . . . . . . . . 25 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
12.1. Normative References . . . . . . . . . . . . . . . . . . . 26 12.1. Normative References . . . . . . . . . . . . . . . . . . . 26
12.2. Informative References . . . . . . . . . . . . . . . . . . 26 12.2. Informative References . . . . . . . . . . . . . . . . . . 26
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 28 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 28
Appendix B. Changes Since RFC 3484 . . . . . . . . . . . . . . . 28 Appendix B. Changes Since RFC 3484 . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
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 may 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 may 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"
[RFC6275]. In addition, multi-homing situations will result in more [RFC6275]. In addition, multi-homing situations will result in more
addresses per node. For example, a node may have multiple addresses per node. For example, a node might have multiple
interfaces, some of them tunnels or virtual interfaces, or a site may interfaces, some of them tunnels or virtual interfaces, or a site
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 both
IPv6 and IPv4, will very often need to choose between IPv6 and IPv4 IPv6 and IPv4, will very often need to choose between IPv6 and IPv4
skipping to change at page 4, line 47 skipping to change at page 4, line 47
global IPv4 address, then IPv4 is the best choice for communication. global IPv4 address, then IPv4 is the best choice for communication.
The destination address selection algorithm solves this with a The destination address selection algorithm solves this with a
unified procedure for choosing among both IPv6 and IPv4 addresses. 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 may 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 should the first one not be 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 using 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 RFC
4862 sense). Furthermore, this document suggests a preferred method, 4862 sense). Furthermore, this document suggests a preferred method,
longest matching prefix, for choosing among otherwise equivalent longest matching prefix, for choosing among otherwise equivalent
skipping to change at page 6, line 14 skipping to change at page 6, line 14
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 getaddrinfo() As a consequence, we intend that implementations of getaddrinfo()
will use the destination address selection algorithm specified here will use the destination address selection algorithm specified here
to sort the list of IPv6 and IPv4 addresses that they return. to sort the list of IPv6 and IPv4 addresses that they return.
Separately, the IPv6 network layer will use the source address Separately, the IPv6 network layer will use the source address
selection algorithm when an application or upper-layer has not selection algorithm when an application or upper-layer has not
specified a source address. Application of this specification to specified a source address. Application of this specification to
source address selection in an IPv4 network layer may be possible but source address selection in an IPv4 network layer might be possible
this is not explored further here. but this is not explored further here.
Well-behaved applications SHOULD iterate through the list of Well-behaved applications SHOULD NOT simply use the first address
addresses returned from getaddrinfo() until they find a working returned from getaddrinfo() and then give up if it fails. For many
address. applications, it is appropriate to iterate through the list of
addresses returned from getaddrinfo() until a working address is
found. For other applications, it might be appropriate to try
multiple in parallel (e.g., with some small delay in between) and use
the first one to succeed.
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
skipping to change at page 6, line 46 skipping to change at page 6, line 50
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 [I-D.ietf-6man-addr-select-opt]) that can override the default
behavior of the algorithms. The policy override consists of the behavior of the algorithms. The policy override consists of the
following set of state, which SHOULD be configurable: following set of 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 may automatically add site-specific whether the implementation is permitted to automatically add site-
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 Precedence(A) and a
classification or label Label(A). classification or label Label(A).
skipping to change at page 7, line 46 skipping to change at page 7, line 50
::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
ULAs and 6to4 addresses for instance (see Section 10.6 and Unique Local Addresses (ULAs) [RFC4193] and 6to4 [RFC3056] addresses
Section 10.7 for examples). Any such rows automatically added by the for instance (see Section 10.6 and Section 10.7 for examples). Any
implementation as a result of address acquisition MUST NOT override a such rows automatically added by the implementation as a result of
row for the same prefix configured via other means. That is, rows address acquisition MUST NOT override a row for the same prefix
can be added but never updated automatically. An implementation configured via other means. That is, rows can be added but never
SHOULD provide a means (the Automatic Row Additions flag) for an updated automatically. An implementation SHOULD provide a means (the
administrator to disable automatic row additions. Automatic Row Additions flag) for an administrator to disable
automatic row additions.
One effect of the default policy table is to prefer using native One effect of the default policy table is to prefer using native
source addresses with native destination addresses, 6to4 [RFC3056] source addresses with native destination addresses, 6to4 source
source addresses with 6to4 destination addresses, etc. Another addresses with 6to4 destination addresses, etc. Another effect of
effect of the default policy table is to prefer communication using the default policy table is to prefer communication using IPv6
IPv6 addresses to communication using IPv4 addresses, if matching addresses to communication using IPv4 addresses, if matching source
source addresses are available. addresses are available.
Policy table entries for scoped address prefixes MAY be qualified Policy table entries for scoped address prefixes MAY be qualified
with an optional zone index. If so, a prefix table entry only with an optional zone index. If so, a prefix table entry only
matches against an address during a lookup if the zone index also matches against an address during a lookup if the zone index also
matches the address's zone index. matches the address's zone index.
2.2. Common Prefix Length 2.2. Common Prefix Length
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
skipping to change at page 9, line 5 skipping to change at page 9, line 12
site-local (0x5), organization-local (0x8), and global (0xE) scopes site-local (0x5), organization-local (0x8), and global (0xE) scopes
[RFC4007]. [RFC4007].
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. unicast global, which is equal to multicast global. (Note that ULAs
are considered as global, not site-local, scope but are handled via
the prefix policy table as 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 should be IPv4 addresses. For this purpose, IPv4 addresses MUST be represented
represented as IPv4-mapped addresses [RFC4291]. For example, to as IPv4-mapped addresses [RFC4291]. For example, to lookup the
lookup the precedence or other attributes of an IPv4 address in the precedence or other attributes of an IPv4 address in the policy
policy table, lookup the corresponding IPv4-mapped IPv6 address. table, lookup 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 ([RFC1918],
section 4.2.2.11), which have the prefix 127/8, are assigned link- section 4.2.2.11), which have the prefix 127/8, are assigned link-
local scope (analogously to the treatment of the IPv6 loopback local scope (analogously to the treatment of the IPv6 loopback
address ([RFC4007], section 4)). Other IPv4 addresses (including address ([RFC4007], section 4)). 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 should be treated as having "preferred" (in the RFC IPv4 addresses MUST be treated as having "preferred" (in the RFC 4862
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 should be treated as having global scope. document, these addresses MUST be treated as having global scope.
IPv4-compatible, IPv4-mapped, and IPv4-converted addresses should 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 should 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) ([RFC4007], section 4) 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 should 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 may supersede the RFC 4862) configuration status. Later standards might supersede
this treatment. this treatment.
3.5. Mobility Addresses 3.5. Mobility Addresses
Some nodes may 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 may 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
or not one's own addresses are designated as home addresses or or not one's own addresses are designated as home addresses or
care-of addresses. Whether or not an address should be designated a care-of addresses. Whether or not an address is designated a home
home address or care-of address is outside the scope of this address or care-of address is outside the scope of this document.
document.
4. Candidate Source Addresses 4. Candidate Source Addresses
The source address selection algorithm uses the concept of a The source address selection algorithm uses the concept of a
"candidate set" of potential source addresses for a given destination "candidate set" of potential source addresses for a given destination
address. The candidate set is the set of all addresses that could be address. The candidate set is the set of all addresses that could be
used as a source address; the source address selection algorithm will used as a source address; the source address selection algorithm will
pick an address out of that set. We write CandidateSource(A) to pick an address out of that set. We write CandidateSource(A) to
denote the candidate set for the address A. denote the candidate set for the address A.
skipping to change at page 10, line 44 skipping to change at page 10, line 51
unicast addresses assigned to the interface that will be used to send unicast addresses assigned to the interface that will be used to send
to the destination. (The "outgoing" interface.) On routers, the to the destination. (The "outgoing" interface.) On routers, the
candidate set MAY include unicast addresses assigned to any interface candidate set MAY include unicast addresses assigned to any interface
that forwards packets, subject to the restrictions described below. that forwards packets, subject to the restrictions described below.
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. Implementations that wish to support the use outgoing interface. Implementations that wish to support the use
of global source addresses assigned to a loopback interface should of global source addresses assigned to a loopback interface MUST
behave as if the loopback interface originates and forwards the behave as if the loopback interface originates and forwards the
packet. packet.
In some cases the destination address may 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 multicast and link-local destination addresses, the set of For 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.
skipping to change at page 12, line 11 skipping to change at page 12, line 17
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 are applied (in order) to for the two addresses, the remaining rules MUST be applied (in order)
just those addresses that are tied to break the tie. Note that if a to just those addresses that are tied to break the tie. Note that if
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, some unspecified tie-breaker should be used. single address, the tie-breaker 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. say "prefer SB" to mean that SA is "less than" SB.
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
skipping to change at page 12, line 44 skipping to change at page 12, line 50
the RFC 4862 sense), then prefer the one that is "preferred." the RFC 4862 sense), then prefer the one that is "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 should provide a mechanism allowing an application to Implementations supporting home addresses MUST provide a mechanism
reverse the sense of this preference and prefer care-of addresses allowing an application to reverse the sense of this preference and
over home addresses (e.g., via appropriate API extensions such as prefer care-of addresses over home addresses (e.g., via appropriate
[RFC5014]). Use of the mechanism should only affect the selection API extensions such as [RFC5014]). Use of the mechanism MUST only
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
skipping to change at page 13, line 34 skipping to change at page 13, line 39
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 should 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.
Rule 8: Use longest matching prefix. Rule 8: Use longest matching prefix.
If CommonPrefixLen(SA, D) > CommonPrefixLen(SB, D), then prefer SA. If CommonPrefixLen(SA, D) > CommonPrefixLen(SB, D), then prefer SA.
Similarly, if CommonPrefixLen(SB, D) > CommonPrefixLen(SA, D), then Similarly, if CommonPrefixLen(SB, D) > CommonPrefixLen(SA, D), then
prefer SB. prefer SB.
Rule 8 may be superseded if the implementation has other means of Rule 8 MAY be superseded if the implementation has other means of
choosing among source addresses. For example, if the implementation choosing among source addresses. For example, if the implementation
somehow knows which source address will result in the "best" somehow knows which source address will result in the "best"
communications performance. communications performance.
Rule 2 (prefer appropriate scope) MUST be implemented and given high Rule 2 (prefer appropriate scope) MUST be implemented and given high
priority because it can affect interoperability. priority because it can affect interoperability.
6. Destination Address Selection 6. Destination Address Selection
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 should 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 the
source address selection algorithm. Source address selection for 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 should 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 should 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 tie-breakers for earlier rules.
See the previous section for a lengthier description of how pair-wise See the previous section for a lengthier description of how pair-wise
comparison tie-breaker rules can be used to sort a list. comparison tie-breaker 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 may 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 may be reached through a network interface that is destination might be reached through a network interface that is
currently unplugged. For example, the implementation may retain currently unplugged. For example, the implementation might retain
for some period of time information from Neighbor Unreachability for some period of time information from Neighbor Unreachability
Detection [RFC4861]. In any case, the determination of Detection [RFC4861]. 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.
skipping to change at page 16, line 17 skipping to change at page 16, line 24
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
(more precisely, selecting an outgoing interface on a node with (more precisely, selecting an outgoing interface on a node with
multiple interfaces) is done before source address selection. multiple interfaces) is done before source address selection.
However, implementations may use source address considerations as a However, implementations MAY use source address considerations as a
tiebreaker when choosing among otherwise equivalent routes. tiebreaker when choosing among otherwise equivalent routes.
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 Rule 5.5 also use the choice of router Implementations that support source address selection (Section 5)
to influence the choice of source address. For example, suppose a Rule 5.5 also use the choice of router to influence the choice of
host is on a link with two routers. One router is advertising a source address. For example, suppose a host is on a link with two
global prefix A and the other router is advertising global prefix B. routers. One router is advertising a global prefix A and the other
Then when sending via the first router, the host may prefer source router is advertising global prefix B. Then when sending via the
addresses with prefix A and when sending via the second router, first router, the host might prefer source addresses with prefix A
prefer source addresses with prefix B. and when sending via the second router, prefer source addresses with
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 resort 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 may not calls to getaddrinfo(). In this approach, the implementation might
have knowledge of the outgoing interface for each destination, so it not have knowledge of the outgoing interface for each destination, so
MAY use a looser definition of the candidate set during destination it MAY use a looser definition of the candidate set during
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 if the ordering of a cached list of destination addresses is or if the ordering of a cached list of destination addresses is
possibly stale, then it should ensure that the destination address possibly stale, then it MUST ensure that the destination address
ordering returned to the application is no more than one second out ordering returned to the application is no more than one second out
of date. For example, an implementation might make a system call to of date. For example, an implementation might make a system call to
check if any routing table entries or source address assignments or check if any routing table entries or source address assignments or
prefix policy table entries that might affect these algorithms have prefix policy table entries that might affect these algorithms have
changed. Another strategy is to use an invalidation counter that is changed. 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.
skipping to change at page 18, line 9 skipping to change at page 18, line 18
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 the upper-layer protocol chosen for the
attack does not specify a particular source address for its reply attack does not specify a particular source address for its reply
packets.) By using different addresses for itself, the unfriendly packets.) By using different addresses for itself, the unfriendly
node can cause the target node to expose the target's own addresses. node can cause the target node to expose the target's own addresses.
The source address selection default preference for temporary The source address selection default preference for temporary
addresses helps mitigate this concern. addresses helps mitigate this concern.
In addition, some address selection rules may 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 of default behavior
and then demonstrating the utility of policy table configuration. and then demonstrating the utility of policy table configuration.
These examples are provided for illustrative purposes; they should These examples are provided for illustrative purposes; they are not
not be construed as normative. 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 23, line 4 skipping to change at page 23, line 12
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 site B, the traffic does not take advantage of their host in site B, the traffic does not take advantage of their
connections to the high-performance ISP. This is not their desired connections to the high-performance ISP. This is not their desired
behavior. behavior.
Candidate Source Addresses: 2001:db8:1aaa::a or 2001:db8:70aa::a or Candidate Source Addresses: 2001:db8:1aaa::a or 2001:db8:70aa::a or
fe80::a fe80::a
Destination Address List: 2001:db8:1ccc::c or 2001:db8:6ccc::c Destination Address List: 2001:db8:1ccc::c or 2001:db8:6ccc::c
Result: 2001:db8:1ccc::c (src 2001:db8:1aaa::a) then 2001:db8:6ccc::c Result: 2001:db8:1ccc::c (src 2001:db8:1aaa::a) then 2001:db8:6ccc::c
(src 2001:db8:70aa::a) (longest matching prefix) (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 reverse traffic may come back through host in some other site C, the reverse traffic might come back
the high-performance ISP. Again, this is not their desired behavior. through the high-performance ISP. Again, this is not their desired
behavior.
This predicament demonstrates the limitations of the longest- This predicament demonstrates the limitations of the longest-
matching-prefix heuristic in multi-homed situations. matching-prefix heuristic in multi-homed situations.
However, the administrators of sites A and B can achieve their However, the administrators of sites A and B can achieve their
desired behavior via policy table configuration. For example, they desired behavior via policy table configuration. For example, they
can use the following policy table: can use the following policy table:
Prefix Precedence Label Prefix Precedence Label
::1/128 50 0 ::1/128 50 0
 End of changes. 50 change blocks. 
95 lines changed or deleted 105 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/