< draft-ietf-ipv6-default-addr-select-07.txt   draft-ietf-ipv6-default-addr-select-08.txt >
IPng Working Group Richard Draves IPng Working Group Richard Draves
Internet Draft Microsoft Research Internet Draft Microsoft Research
Document: draft-ietf-ipv6-default-addr-select-07.txt March 1, 2002 Document: draft-ietf-ipv6-default-addr-select-08.txt June 17, 2002
Category: Standards Track Category: Standards Track
Default Address Selection for IPv6 Default Address Selection for IPv6
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026 [1]. all provisions of Section 10 of RFC 2026 [1].
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
skipping to change at line 37 skipping to change at line 37
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
This document describes two algorithms, for source address selection This document describes two algorithms, for source address selection
and for destination address selection. The algorithms specify and for destination address selection. The algorithms specify
default behavior for all IPv6 implementations. They do not override default behavior for all IPv6 implementations. They do not override
choices made by applications or upper-layer protocols, nor do they choices made by applications or upper-layer protocols, nor do they
preclude the development of more advanced mechanisms for address preclude the development of more advanced mechanisms for address
selection. The two algorithms share a common framework, including an selection. The two algorithms share a common context, including an
optional mechanism for allowing administrators to provide policy optional mechanism for allowing administrators to provide policy
that can override the default behavior. In dual stack that can override the default behavior. In dual stack
implementations, the framework allows the destination address implementations, the destination address selection algorithm can
selection algorithm to consider both IPv4 and IPv6 addresses - consider both IPv4 and IPv6 addresses - depending on the available
depending on the available source addresses, the algorithm might source addresses, the algorithm might prefer IPv6 addresses over
prefer IPv6 addresses over IPv4 addresses, or vice-versa. IPv4 addresses, or vice-versa.
All IPv6 nodes, including both hosts and routers, must implement All IPv6 nodes, including both hosts and routers, must implement
default address selection as defined in this specification. default address selection as defined in this specification.
Table of Contents Table of Contents
1. Introduction................................................2 1. Introduction................................................2
1.1. Conventions used in this document...........................3 1.1. Conventions Used in This Document...........................3
2. Framework...................................................3 2. Context in Which the Algorithms Operate.....................4
2.1. Scope Comparisons...........................................4 2.1. Policy Table................................................5
2.2. IPv4 Addresses and IPv4-Mapped Addresses....................5 2.2. Common Prefix Length........................................6
2.3. Other IPv6 Addresses with Embedded IPv4 Addresses...........5 3. Address Properties..........................................6
2.4. IPv6 Loopback Address and Other Format Prefixes.............5 3.1. Scope Comparisons...........................................6
2.5. Policy Table................................................6 3.2. IPv4 Addresses and IPv4-Mapped Addresses....................7
2.6. Common Prefix Length........................................6 3.3. Other IPv6 Addresses with Embedded IPv4 Addresses...........7
3. Candidate Source Addresses..................................7 3.4. IPv6 Loopback Address and Other Format Prefixes.............7
4. Source Address Selection....................................8 4. Candidate Source Addresses..................................7
5. Destination Address Selection..............................10 5. Source Address Selection....................................8
6. Interactions with Routing..................................12 6. Destination Address Selection..............................11
7. Implementation Considerations..............................12 7. Interactions with Routing..................................13
8. Security Considerations....................................13 8. Implementation Considerations..............................13
9. Examples...................................................13 9. Security Considerations....................................14
9.1. Default Source Address Selection...........................13 10. Examples...................................................14
9.2. Default Destination Address Selection......................14 10.1. Default Source Address Selection...........................14
9.3. Configuring Preference for IPv6 or IPv4....................15 10.2. Default Destination Address Selection......................15
9.4. Configuring Preference for Scoped Addresses................16 10.3. Configuring Preference for IPv6 or IPv4....................16
9.5. Configuring a Multi-Homed Site.............................16 10.4. Configuring Preference for Scoped Addresses................17
Acknowledgments...................................................19 10.5. Configuring a Multi-Homed Site.............................17
Author's Address..................................................19 Acknowledgments...................................................20
Revision History..................................................19 Author's Address..................................................20
Revision History..................................................20
1. Introduction 1. Introduction
The IPv6 addressing architecture [2] allows multiple unicast The IPv6 addressing architecture [2] allows multiple unicast
addresses to be assigned to interfaces. These addresses may have addresses to be assigned to interfaces. These addresses may 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" [3]. Privacy These addresses may also be "preferred" or "deprecated" [3]. Privacy
considerations have introduced the concepts of "public addresses" considerations have introduced the concepts of "public addresses"
and "temporary addresses" [4]. The mobility architecture introduces and "temporary addresses" [4]. The mobility architecture introduces
"home addresses" and "care-of addresses" [5]. In addition, multi- "home addresses" and "care-of addresses" [5]. In addition, multi-
skipping to change at line 112 skipping to change at line 113
IPv4 can produce poor behavior. As one example, suppose a DNS name IPv4 can produce poor behavior. As one example, suppose a DNS name
resolves to a global IPv6 address and a global IPv4 address. If the resolves to a global IPv6 address and a global IPv4 address. If the
node has assigned a global IPv6 address and a 169.254/16 auto- node has assigned a global IPv6 address and a 169.254/16 auto-
configured IPv4 address [6], then IPv6 is the best choice for configured IPv4 address [6], then IPv6 is the best choice for
communication. But if the node has assigned only a link-local IPv6 communication. But if the node has assigned only a link-local IPv6
address and a global IPv4 address, then IPv4 is the best choice for address and a global IPv4 address, then IPv4 is the best choice for
communication. The destination address selection algorithm solves communication. The destination address selection algorithm solves
this with a unified procedure for choosing among both IPv6 and IPv4 this with a unified procedure for choosing among both IPv6 and IPv4
addresses. addresses.
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
for use. In the case of source address selection, a node typically
has multiple addresses assigned to its interfaces, and the source
address ordering rules in section 5 define which address is 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
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 address ordering rules in section 6, when applied to the
set of 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 framework 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). scope and configuration status (preferred or deprecated in the RFC
Furthermore, this document suggests a preferred method, longest 2462 sense). Furthermore, this document suggests a preferred method,
matching prefix, for choosing among otherwise equivalent addresses longest matching prefix, for choosing among otherwise equivalent
in the absence of better information. addresses in the absence of better information.
The framework also has policy hooks to allow administrative override This document also specifies policy hooks to allow administrative
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 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC 2119 [7]. this document are to be interpreted as described in RFC 2119 [7].
2. Framework 2. Context in Which the Algorithms Operate
Our framework 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,
the framework specifies two separate algorithms for these tasks. The we have two separate algorithms for these tasks. The algorithms are
algorithms are designed to work well together and they share a designed to work well together and they share a mechanism for
mechanism for administrative policy override. administrative policy override.
In this implementation architecture, applications use APIs [8] like In this implementation architecture, applications use APIs [8] like
getaddrinfo() that return a list of addresses to the application. getaddrinfo() that return a list of addresses to the application.
This list might contain both IPv6 and IPv4 addresses (sometimes This list might contain both IPv6 and IPv4 addresses (sometimes
represented as IPv4-mapped addresses). The application then passes a represented as IPv4-mapped addresses). The application then passes a
destination address to the network stack with connect() or sendto(). destination address to the network stack with connect() or sendto().
The application would then typically try the first address in the The application would then typically try the first address in the
list, looping over the list of addresses until it finds a working list, looping over the list of addresses until it finds a working
address. In any case, the network layer is never in a situation address. In any case, the network layer is never in a situation
where it needs to choose a destination address from several where it needs to choose a destination address from several
alternatives. The application might also specify a source address alternatives. The application might also specify a source address
with bind(), but often the source address is left unspecified. with bind(), but often the source address is left unspecified.
Therefore the network layer does often choose a source address from Therefore the network layer does often choose a source address from
several alternatives. 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 framework to source specified a source address. Application of this specification to
address selection in an IPv4 network layer may be possible but this source address selection in an IPv4 network layer may be possible
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 iterate through the list of
addresses returned from getaddrinfo() until they find a working addresses returned from getaddrinfo() until they find a working
address. address.
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, public addresses [4] are preferred over temporary address selection, public addresses [4] are preferred over temporary
addresses. In mobile situations [5], home addresses are preferred addresses. In mobile situations [5], home addresses are preferred
over care-of addresses. If an address is simultaneously a home over care-of addresses. If an address is simultaneously a home
address and a care-of address (indicating the mobile node is "at 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.
The framework optionally allows for the possibility of This specification optionally allows for the possibility of
administrative configuration of policy that can override the default administrative configuration of policy that can override the default
behavior of the algorithms. The policy override takes the form of a behavior of the algorithms. The policy override takes the form of a
configurable table that specifies precedence values and preferred configurable table that specifies precedence values and preferred
source prefixes for destination prefixes. If an implementation is source prefixes for destination prefixes. If an implementation is
not configurable, or if an implementation has not been configured, not configurable, or if an implementation has not been configured,
then the default policy table specified in this document SHOULD be then the default policy table specified in this document SHOULD be
used. used.
2.1. Scope Comparisons 2.1. Policy Table
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 produces two values: a precedence value Precedence(A) and a
classification or label Label(A).
The precedence value Precedence(A) is used for sorting destination
addresses. If Precedence(A) > Precedence(B), we say that address A
has higher precedence than address B, meaning that our algorithm
will prefer to sort destination address A before destination address
B.
The label value Label(A) allows for policies that prefer a
particular source address prefix for use with a destination address
prefix. The algorithms prefer to use a source address S with a
destination address D if Label(S) = Label(D).
IPv6 implementations SHOULD support configurable address selection
via a mechanism at least as powerful as the policy tables defined
here. Note that at the time of this writing there is only limited
experience with the use of policies that select from a set of
possible IPv6 addresses. As more experience is gained, the
recommended default policies may change. Consequently it is
important that implementations provide a way to change the default
policies as more experience is gained. Sections 10.3 and 10.4
provide examples of the kind of changes that might be needed.
If an implementation is not configurable or has not been configured,
then it SHOULD operate according to the algorithms specified here in
conjunction with the following default policy table:
Prefix Precedence Label
::1/128 50 0
::/0 40 1
2002::/16 30 2
::/96 20 3
::ffff:0:0/96 10 4
One effect of the default policy table is to prefer using native
source addresses with native destination addresses, 6to4 [9] source
addresses with 6to4 destination addresses, and v4-compatible [2]
source addresses with v4-compatible destination addresses. Another
effect of the default policy table is to prefer communication using
IPv6 addresses to communication using IPv4 addresses, if matching
source addresses are available.
Policy table entries for scoped address prefixes MAY be qualified
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 the address's zone index.
2.2. Common Prefix Length
We define the common prefix length CommonPrefixLen(A, B) of two
addresses A and B as the length of the longest prefix (looking at
the most significant, or leftmost, bits) that the two addresses have
in common. It ranges from 0 to 128.
3. Address Properties
In the rules given in later sections, addresses of different types
(e.g., IPv4, IPv6, multicast and unicast) are compared against each
other. Some of these address types have properties that aren't
directly comparable to each other. For example, IPv6 unicast
addresses can be "preferred" or "deprecated" [3], while IPv4
addresses have no such notion. To compare such addresses using the
ordering rules (e.g., to use "preferred" addresses in preference to
"deprecated" addresses), the following mappings are defined.
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), subnet-local (0x3), admin-local local (0x1), link-local (0x2), subnet-local (0x3), admin-local
(0x4), site-local (0x5), organization-local (0x8), and global (0xE) (0x4), site-local (0x5), organization-local (0x8), and global (0xE)
scopes [9]. scopes [10].
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.
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 [9]. multicast site boundaries [10].
2.2. IPv4 Addresses and IPv4-Mapped Addresses 3.2. IPv4 Addresses and IPv4-Mapped Addresses
The destination address selection algorithm operates on both IPv6 The destination address selection algorithm operates on both IPv6
and IPv4 addresses. For this purpose, IPv4 addresses should be and IPv4 addresses. For this purpose, IPv4 addresses should be
represented as IPv4-mapped addresses [2]. For example, to lookup the represented as IPv4-mapped addresses [2]. For example, to lookup 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, 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 [6], which have the prefix 169.254/16, are configuration addresses [6], which have the prefix 169.254/16, are
assigned link-local scope. IPv4 private addresses [10], which have assigned link-local scope. IPv4 private addresses [11], which have
the prefixes 10/8, 172.16/12, and 192.168/16, are assigned site- the prefixes 10/8, 172.16/12, and 192.168/16, are assigned site-
local scope. IPv4 loopback addresses [11, section 4.2.2.11], which local scope. IPv4 loopback addresses [12, section 4.2.2.11], which
have the prefix 127/8, are assigned link-local scope (analogously to have the prefix 127/8, are assigned link-local scope (analogously to
the treatment of the IPv6 loopback address [9, section 4]). Other the treatment of the IPv6 loopback address [10, section 4]). Other
IPv4 addresses are assigned global scope. IPv4 addresses are assigned global scope.
IPv4 addresses should be treated as having "preferred" configuration IPv4 addresses should be treated as having "preferred" (in the RFC
status. 2462 sense) configuration status.
2.3. Other IPv6 Addresses with Embedded IPv4 Addresses 3.3. Other IPv6 Addresses with Embedded IPv4 Addresses
IPv4-compatible addresses [2] and 6to4 addresses [12] contain an IPv4-compatible addresses [2], IPv4-mapped [2], IPv4-translatable
embedded IPv4 address. For the purposes of this document, these [13] and 6to4 addresses [9] contain an embedded IPv4 address. For
addresses should be treated as having global scope. the purposes of this document, these addresses should be treated as
having global scope.
IPv4-compatible addresses should be treated as having "preferred" IPv4-compatible, IPv4-mapped, and IPv4-translatable addresses should
be treated as having "preferred" (in the RFC 2462 sense)
configuration status. configuration status.
2.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 The loopback address should be treated as having link-local
scope [9, section 4] and "preferred" configuration status. scope [10, section 4] and "preferred" (in the RFC 2462 sense)
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" prefixes should be treated as having global scope and "preferred"
configuration status. Later standards may supersede this treatment. (in the RFC 2462) configuration status. Later standards may
supersede this treatment.
2.5. Policy Table
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 produces two values: a precedence value Precedence(A) and a
classification or label Label(A).
The precedence value Precedence(A) is used for sorting destination
addresses. If Precedence(A) > Precedence(B), we say that address A
has higher precedence than address B, meaning that our algorithm
will prefer to sort destination address A before destination address
B.
The label value Label(A) allows for policies that prefer a
particular source address prefix for use with a destination address
prefix. The algorithms prefer to use a source address S with a
destination address D if Label(S) = Label(D).
IPv6 implementations SHOULD support configurable address selection
via a mechanism at least as powerful as the policy tables defined
here. If an implementation is not configurable or has not been
configured, then it SHOULD operate according to the algorithms
specified here in conjunction with the following default policy
table:
Prefix Precedence Label
::1/128 50 0
::/0 40 1
2002::/16 30 2
::/96 20 3
::ffff:0:0/96 10 4
One effect of the default policy table is to prefer using native
source addresses with native destination addresses, 6to4 [12] source
addresses with 6to4 destination addresses, and v4-compatible [2]
source addresses with v4-compatible destination addresses. Another
effect of the default policy table is to prefer communication using
IPv6 addresses to communication using IPv4 addresses, if matching
source addresses are available.
Policy table entries for scoped address prefixes MAY be qualified
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 the address's zone index.
2.6. Common Prefix Length
We define the common prefix length CommonPrefixLen(A, B) of two
addresses A and B as the length of the longest prefix (looking at
the most significant, or leftmost, bits) that the two addresses have
in common. It ranges from 0 to 128.
3. 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 "candidate set" of potential source addresses for a given
destination address. The candidate set is the set of all addresses destination address. The candidate set is the set of all addresses
that could be used as a source address; the source address selection that could be used as a source address; the source address selection
algorithm will pick an address out of that set. We write algorithm will pick an address out of that set. We write
CandidateSource(A) to denote the candidate set for the address A. CandidateSource(A) to denote the candidate set for the address A.
It is RECOMMENDED that the candidate source addresses be the set of It is RECOMMENDED that the candidate source addresses be the set of
unicast addresses assigned to the interface that will be used to unicast addresses assigned to the interface that will be used to
send to the destination. (The "outgoing" interface.) On routers, the send to the destination. (The "outgoing" interface.) On routers, the
candidate set MAY include unicast addresses assigned to any candidate set MAY include unicast addresses assigned to any
interface that forwards packets, subject to the restrictions interface that forwards packets, subject to the restrictions
described below. described below.
Discussion: The Neighbor Discovery Redirect mechanism [13] Discussion: The Neighbor Discovery Redirect mechanism [14]
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 should
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 may 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.
skipping to change at line 368 skipping to change at line 404
not in the candidate set for the destination, then the network layer not in the candidate set for the destination, then the network layer
MUST treat this as an error. The specified source address may MUST treat this as an error. The specified source address may
influence the candidate set, by affecting the choice of outgoing influence the candidate set, by affecting the choice of outgoing
interface. If the application or upper-layer specifies a source interface. If the application or upper-layer specifies a source
address that is in the candidate set for the destination, then the address that is in the candidate set for the destination, then the
network layer MUST respect that choice. If the application or upper- network layer MUST respect that choice. If the application or upper-
layer does not specify a source address, then the network layer uses layer does not specify a source address, then the network layer uses
the source address selection algorithm specified in the next the source address selection algorithm specified in the next
section. section.
4. Source Address Selection On IPv6-only nodes that support SIIT [13, especially section 5], if
the destination address is an IPv4-mapped address then the candidate
set MUST contain only IPv4-translatable addresses. If the
destination address is not an IPv4-mapped address, then the
candidate set MUST NOT contain IPv4-translatable addresses.
5. Source Address Selection
The source address selection algorithm produces as output a single The source address selection algorithm produces as output a single
source address for use with a given destination address. This source address for use with a given destination address. This
algorithm only applies to IPv6 destination addresses, not IPv4 algorithm only applies to IPv6 destination addresses, not IPv4
addresses. addresses.
The algorithm is specified here in terms of a list of pair-wise The algorithm is specified here in terms of a list of pair-wise
comparison rules that (for a given destination address D) imposes a comparison rules that (for a given destination address D) imposes a
"greater than" ordering on the addresses in the candidate set "greater than" ordering on the addresses in the candidate set
CandidateSource(D). The address at the front of the list after the CandidateSource(D). The address at the front of the list after the
skipping to change at line 416 skipping to change at line 458
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 If Scope(SA) < Scope(SB): If Scope(SA) < Scope(D), then prefer SB
and otherwise prefer SA. and otherwise prefer SA.
Similarly, if Scope(SB) < Scope(SA): If Scope(SB) < Scope(D), then Similarly, if Scope(SB) < Scope(SA): If Scope(SB) < Scope(D), then
prefer SA and otherwise prefer SB. prefer SA and otherwise prefer SB.
Rule 3: Avoid deprecated addresses. Rule 3: Avoid deprecated addresses.
The addresses SA and SB have the same scope. If one of the two The addresses SA and SB have the same scope. If one of the two
source addresses is "preferred" and one of them is "deprecated", source addresses is "preferred" and one of them is "deprecated" (in
then prefer the one that is "preferred." the RFC 2462 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. 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 If SA is 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 prefer SA. Similarly, if SB is just a home address and SA is just a
care-of address, then prefer SB. care-of address, then prefer SB.
An implementation may support a per-connection configuration An implementation may support a per-connection configuration
mechanism (for example, a socket option) to reverse the sense of mechanism (for example, a socket option) to reverse the sense of
this preference and prefer care-of addresses over home addresses. this preference and prefer care-of addresses over home addresses.
skipping to change at line 445 skipping to change at line 487
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 public addresses. Rule 7: Prefer public addresses.
If SA is a public address and SB is a temporary address, then prefer If SA is a public address and SB is a temporary address, then prefer
SA. Similarly, if SB is a public address and SA is a temporary SA. Similarly, if SB is a public address and SA is a temporary
address, then prefer SB. address, then prefer SB.
An implementation may support a per-connection configuration An implementation MUST support a per-connection configuration
mechanism (for example, a socket option) to reverse the sense of mechanism (for example, a socket option) to reverse the sense of
this preference and prefer temporary addresses over public this preference and prefer temporary addresses over public
addresses. addresses.
This rule avoids applications potentially failing due to the This rule avoids applications potentially failing due to the
relatively short lifetime of temporary addresses or due to the relatively short lifetime of temporary addresses or due to the
possibility of the reverse lookup of a temporary address either possibility of the reverse lookup of a temporary address either
failing or returning a randomized name. Implementations for which failing or returning a randomized name. Implementations for which
privacy considerations outweigh these application compatibility privacy considerations outweigh these application compatibility
concerns MAY reverse the sense of this rule and by default prefer concerns MAY reverse the sense of this rule and by default prefer
skipping to change at line 471 skipping to change at line 513
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.
5. 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 addresses DA and DB, where DA appears before DB in the original
list. 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 should be represented as an IPv4-mapped address.
skipping to change at line 509 skipping to change at line 551
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 may 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 may be reached through a network interface that is
currently unplugged. For example, the implementation may retain currently unplugged. For example, the implementation may retain
for some period of time information from Neighbor Unreachability for some period of time information from Neighbor Unreachability
Detection [13]. In any case, the determination of unreachability Detection [14]. In any case, the determination of unreachability
for the purposes of this rule is implementation-dependent. for the purposes of this rule is implementation-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.
Similarly, if Source(DA) is not deprecated and Source(DB) is Similarly, if Source(DA) is not deprecated and Source(DB) is
skipping to change at line 545 skipping to change at line 587
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 (eg, IPv6 If DA is reached via an encapsulating transition mechanism (eg, IPv6
in IPv4) and DB is not, then prefer DB. Similarly, if DB is reached in IPv4) and DB is not, then prefer DB. Similarly, if DB is reached
via encapsulation and DA is not, then prefer DA. via encapsulation and DA is not, then prefer DA.
Discussion: 6-over-4 [14], ISATAP [15], and configured Discussion: 6-over-4 [15], ISATAP [16], and configured
tunnels [16] are examples of encapsulating transition mechanisms tunnels [17] are examples of encapsulating transition mechanisms
for which the destination address does not have a specific prefix for which the destination address does not have a specific prefix
and hence can not be assigned a lower precedence in the policy and hence can not be assigned a lower precedence in the policy
table. An implementation MAY generalize this rule by using a table. An implementation MAY generalize this rule by using a
concept of interface preference, and giving virtual interfaces concept of interface preference, and giving virtual interfaces
(like the IPv6-in-IPv4 encapsulating interfaces) a lower (like the IPv6-in-IPv4 encapsulating interfaces) a lower
preference than native interfaces (like ethernet interfaces). preference than native 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.
skipping to change at line 574 skipping to change at line 616
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.
6. 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 global addresses. When sending to a global interfaces have preferred (in the RFC 2462 sense) global addresses.
destination address, if there's no routing reason to prefer one When sending to a global destination address, if there's no routing
interface over the other, then an implementation may preferentially reason to prefer one interface over the other, then an
choose the outgoing interface that will allow it to use the source implementation may preferentially choose the outgoing interface that
address that shares a longer common prefix with the destination. will allow it to use the source address that shares a longer common
prefix with the destination.
Implementations may also use the choice of router to influence the Implementations may also use the choice of router to influence the
choice of source address. For example, suppose a host is on a link choice of source address. For example, suppose a host is on a link
with two routers. One router is advertising a global prefix A and with two routers. One router is advertising a global prefix A and
the other router is advertising global prefix B. Then when sending the other router is advertising global prefix B. Then when sending
via the first router, the host may prefer source addresses with via the first router, the host may prefer source addresses with
prefix A and when sending via the second router, prefer source prefix A and when sending via the second router, prefer source
addresses with prefix B. addresses with prefix B.
7. 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
skipping to change at line 635 skipping to change at line 678
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 check if any routing table entries or source address assignments
that might affect these algorithms have changed. Another strategy is that might affect these algorithms have changed. Another strategy is
to use an invalidation counter that is incremented whenever any to use an invalidation counter that is incremented whenever any
underlying state is changed. By caching the current invalidation underlying state is changed. By caching the current invalidation
counter value with derived state and then later comparing against counter value with derived state and then later comparing against
the current value, the implementation could detect if the derived the current value, the implementation could detect if the derived
state is potentially stale. state is potentially stale.
8. 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 Note that most source address selection algorithms, including the
one specified in this document, expose a potential privacy concern. one specified in this document, expose a potential privacy concern.
An unfriendly node can infer correlations among a target node's An 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 multicast address, or perhaps the upper-layer protocol chosen for
the attack does not specify a particular source address for its the attack does not specify a particular source address for its
reply packets.) By using different addresses for itself, the reply packets.) By using different addresses for itself, the
unfriendly node can cause the target node to expose the target's own unfriendly node can cause the target node to expose the target's own
addresses. addresses.
9. Examples 10. Examples
This section contains a number of examples, first of default This section contains a number of examples, first of default
behavior and then demonstrating the utility of policy table behavior and then demonstrating the utility of policy table
configuration. These examples are provided for illustrative configuration. These examples are provided for illustrative
purposes; they should not be construed as normative. purposes; they should not be construed as normative.
9.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::1 Destination: 2001::1
Candidate Set: 3ffe::1 or fe80::1 Candidate Source Addresses: 3ffe::1 or fe80::1
Result: 3ffe::1 (prefer appropriate scope) Result: 3ffe::1 (prefer appropriate scope)
Destination: 2001::1 Destination: 2001::1
Candidate Set: fe80::1 or fec0::1 Candidate Source Addresses: fe80::1 or fec0::1
Result: fec0::1 (prefer appropriate scope) Result: fec0::1 (prefer appropriate scope)
Destination: fec0::1 Destination: fec0::1
Candidate Set: fe80::1 or 2001::1 Candidate Source Addresses: fe80::1 or 2001::1
Result: 2001::1 (prefer appropriate scope) Result: 2001::1 (prefer appropriate scope)
Destination: ff05::1 Destination: ff05::1
Candidate Set: fe80::1 or fec0::1 or 2001::1 Candidate Source Addresses: fe80::1 or fec0::1 or 2001::1
Result: fec0::1 (prefer appropriate scope) Result: fec0::1 (prefer appropriate scope)
Destination: 2001::1 Destination: 2001::1
Candidate Set: 2001::1 (deprecated) or 2002::1 Candidate Source Addresses: 2001::1 (deprecated) or 2002::1
Result: 2001::1 (prefer same address) Result: 2001::1 (prefer same address)
Destination: fec0::1 Destination: fec0::1
Candidate Set: fec0::2 (deprecated) or 2001::1 Candidate Source Addresses: fec0::2 (deprecated) or 2001::1
Result: fec0::2 (prefer appropriate scope) Result: fec0::2 (prefer appropriate scope)
Destination: 2001::1 Destination: 2001::1
Candidate Set: 2001::2 or 3ffe::2 Candidate Source Addresses: 2001::2 or 3ffe::2
Result: 2001::2 (longest-matching-prefix) Result: 2001::2 (longest-matching-prefix)
Destination: 2001::1 Destination: 2001::1
Candidate Set: 2001::2 (care-of address) or 3ffe::2 (home address) Candidate Source Addresses: 2001::2 (care-of address) or 3ffe::2
(home address)
Result: 3ffe::2 (prefer home address) Result: 3ffe::2 (prefer home address)
Destination: 2002:836b:2179::1 Destination: 2002:836b:2179::1
Candidate Set: 2002:836b:2179::d5e3:7953:13eb:22e8 (temporary) or Candidate Source Addresses: 2002:836b:2179::d5e3:7953:13eb:22e8
2001::2 (temporary) or 2001::2
Result: 2002:836b:2179::d5e3:7953:13eb:22e8 (prefer matching label) Result: 2002:836b:2179::d5e3:7953:13eb:22e8 (prefer matching label)
Destination: 2001::d5e3:0:0:1 Destination: 2001::d5e3:0:0:1
Candidate Set: 2001::2 or 2001::d5e3:7953:13eb:22e8 (temporary) Candidate Source Addresses: 2001::2 or 2001::d5e3:7953:13eb:22e8
(temporary)
Result: 2001::2 (prefer public address) Result: 2001::2 (prefer public address)
9.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 Set: 2001::2 or fe80::1 or 169.254.13.78 Candidate Source Addresses: 2001::2 or fe80::1 or 169.254.13.78
Destinations: 2001::1 or 131.107.65.121 Destination Address List: 2001::1 or 131.107.65.121
Result: 2001::1 (src 2001::2) then 131.107.65.121 (src Result: 2001::1 (src 2001::2) then 131.107.65.121 (src
169.254.13.78) (prefer matching scope) 169.254.13.78) (prefer matching scope)
Candidate Set: fe80::1 or 131.107.65.117 Candidate Source Addresses: fe80::1 or 131.107.65.117
Destinations: 2001::1 or 131.107.65.121 Destination Address List: 2001::1 or 131.107.65.121
Result: 131.107.65.121 (src 131.107.65.117) then 2001::1 (src Result: 131.107.65.121 (src 131.107.65.117) then 2001::1 (src
fe80::1) (prefer matching scope) fe80::1) (prefer matching scope)
Candidate Set: 2001::2 or fe80::1 or 10.1.2.4 Candidate Source Addresses: 2001::2 or fe80::1 or 10.1.2.4
Destinations: 2001::1 or 10.1.2.3 Destination Address List: 2001::1 or 10.1.2.3
Result: 2001::1 (src 2001::2) then 10.1.2.3 (src 10.1.2.4) (prefer Result: 2001::1 (src 2001::2) then 10.1.2.3 (src 10.1.2.4) (prefer
higher precedence) higher precedence)
Candidate Set: 2001::2 or fec0::2 or fe80::2 Candidate Source Addresses: 2001::2 or fec0::2 or fe80::2
Destinations: 2001::1 or fec0::1 or fe80::1 Destination Address List: 2001::1 or fec0::1 or fe80::1
Result: fe80::1 (src fe80::2) then fec0::1 (src fec0::2) then Result: fe80::1 (src fe80::2) then fec0::1 (src fec0::2) then
2001::1 (src 2001::2) (prefer smaller scope) 2001::1 (src 2001::2) (prefer smaller scope)
Candidate Source Addresses: 2001::2 (care-of address) or 3ffe::1
Candidate Set: 2001::2 (care-of address) or 3ffe::1 (home address) (home address) or fec0::2 (care-of address) or fe80::2 (care-of
or fec0::2 (care-of address) or fe80::2 (care-of address) address)
Destinations: 2001::1 or fec0::1 Destination Address List: 2001::1 or fec0::1
Result: 2001:1 (src 3ffe::1) then fec0::1 (src fec0::2) (prefer home Result: 2001:1 (src 3ffe::1) then fec0::1 (src fec0::2) (prefer home
address) address)
Candidate Set: 2001::2 or fec0::2 (deprecated) or fe80::2 Candidate Source Addresses: 2001::2 or fec0::2 (deprecated) or
Destinations: 2001::1 or fec0::1 fe80::2
Destination Address List: 2001::1 or fec0::1
Result: 2001::1 (src 2001::2) then fec0::1 (src fec0::2) (avoid Result: 2001::1 (src 2001::2) then fec0::1 (src fec0::2) (avoid
deprecated addresses) deprecated addresses)
Candidate Set: 2001::2 or 3f44::2 or fe80::2 Candidate Source Addresses: 2001::2 or 3f44::2 or fe80::2
Destinations: 2001::1 or 3ffe::1 Destination Address List: 2001::1 or 3ffe::1
Result: 2001::1 (src 2001::2) then 3ffe::1 (src 3f44::2) (longest Result: 2001::1 (src 2001::2) then 3ffe::1 (src 3f44::2) (longest
matching prefix) matching prefix)
Candidate Set: 2002:836b:4179::2 or fe80::2 Candidate Source Addresses: 2002:836b:4179::2 or fe80::2
Destinations: 2002:836b:4179::1 or 2001::1 Destination Address List: 2002:836b:4179::1 or 2001::1
Result: 2002:836b:4179::1 (src 2002:836b:4179::2) then 2001::1 (src Result: 2002:836b:4179::1 (src 2002:836b:4179::2) then 2001::1 (src
2002:836b:4179::2) (prefer matching label) 2002:836b:4179::2) (prefer matching label)
Candidate Set: 2002:836b:4179::2 or 2001::2 or fe80::2 Candidate Source Addresses: 2002:836b:4179::2 or 2001::2 or fe80::2
Destinations: 2002:836b:4179::1 or 2001::1 Destination Address List: 2002:836b:4179::1 or 2001::1
Result: 2001::1 (src 2001::2) then 2002:836b:4179::1 (src Result: 2001::1 (src 2001::2) then 2002:836b:4179::1 (src
2002:836b:4179::2) (prefer higher precedence) 2002:836b:4179::2) (prefer higher precedence)
9.3. Configuring Preference for IPv6 or IPv4 10.3. Configuring Preference for IPv6 or IPv4
The default policy table gives IPv6 addresses higher precedence than The default policy table gives IPv6 addresses higher precedence than
IPv4 addresses. This means that applications will use IPv6 in IPv4 addresses. This means that applications will use IPv6 in
preference to IPv4 when the two are equally suitable. An preference to IPv4 when the two are equally suitable. An
administrator can change the policy table to prefer IPv4 addresses administrator can change the policy table to prefer IPv4 addresses
by giving the ::ffff:0.0.0.0/96 prefix a higher precedence: by giving the ::ffff:0.0.0.0/96 prefix a higher precedence:
Prefix Precedence Label Prefix Precedence Label
::1/128 50 0 ::1/128 50 0
::/0 40 1 ::/0 40 1
2002::/16 30 2 2002::/16 30 2
::/96 20 3 ::/96 20 3
::ffff:0:0/96 100 4 ::ffff:0:0/96 100 4
This change to the default policy table produces the following This change to the default policy table produces the following
behavior: behavior:
Candidate Set: 2001::2 or fe80::1 or 169.254.13.78 Candidate Source Addresses: 2001::2 or fe80::1 or 169.254.13.78
Destinations: 2001::1 or 131.107.65.121 Destination Address List: 2001::1 or 131.107.65.121
Unchanged Result: 2001::1 (src 2001::2) then 131.107.65.121 (src Unchanged Result: 2001::1 (src 2001::2) then 131.107.65.121 (src
169.254.13.78) (prefer matching scope) 169.254.13.78) (prefer matching scope)
Candidate Source Addresses: fe80::1 or 131.107.65.117
Candidate Set: fe80::1 or 131.107.65.117 Destination Address List: 2001::1 or 131.107.65.121
Destinations: 2001::1 or 131.107.65.121
Unchanged Result: 131.107.65.121 (src 131.107.65.117) then 2001::1 Unchanged Result: 131.107.65.121 (src 131.107.65.117) then 2001::1
(src fe80::1) (prefer matching scope) (src fe80::1) (prefer matching scope)
Candidate Set: 2001::2 or fe80::1 or 10.1.2.4
Destinations: 2001::1 or 10.1.2.3 Candidate Source Addresses: 2001::2 or fe80::1 or 10.1.2.4
Destination Address List: 2001::1 or 10.1.2.3
New Result: 10.1.2.3 (src 10.1.2.4) then 2001::1 (src 2001::2) New Result: 10.1.2.3 (src 10.1.2.4) then 2001::1 (src 2001::2)
(prefer higher precedence) (prefer higher precedence)
9.4. Configuring Preference for Scoped Addresses 10.4. Configuring Preference for Scoped Addresses
The destination address selection rules give preference to The destination address selection rules give preference to
destinations of smaller scope. For example, a site-local destination destinations of smaller scope. For example, a site-local destination
will be sorted before a global scope destination when the two are will be sorted before a global scope destination when the two are
otherwise equally suitable. An administrator can change the policy otherwise equally suitable. An administrator can change the policy
table to reverse this preference and sort global destinations before table to reverse this preference and sort global destinations before
site-local destinations, and site-local destinations before link- site-local destinations, and site-local destinations before link-
local destinations: local destinations:
Prefix Precedence Label Prefix Precedence Label
skipping to change at line 810 skipping to change at line 856
::/0 40 1 ::/0 40 1
fec0::/10 37 1 fec0::/10 37 1
fe80::/10 33 1 fe80::/10 33 1
2002::/16 30 2 2002::/16 30 2
::/96 20 3 ::/96 20 3
::ffff:0:0/96 10 4 ::ffff:0:0/96 10 4
This change to the default policy table produces the following This change to the default policy table produces the following
behavior: behavior:
Candidate Set: 2001::2 or fec0::2 or fe80::2 Candidate Source Addresses: 2001::2 or fec0::2 or fe80::2
Destinations: 2001::1 or fec0::1 or fe80::1 Destination Address List: 2001::1 or fec0::1 or fe80::1
New Result: 2001::1 (src 2001::2) then fec0::1 (src fec0::2) then New Result: 2001::1 (src 2001::2) then fec0::1 (src fec0::2) then
fe80::1 (src fe80::2) (prefer higher precedence) fe80::1 (src fe80::2) (prefer higher precedence)
Candidate Set: 2001::2 (deprecated) or fec0::2 or fe80::2 Candidate Source Addresses: 2001::2 (deprecated) or fec0::2 or
Destinations: 2001::1 or fec0::1 fe80::2
Destination Address List: 2001::1 or fec0::1
Unchanged Result: fec0::1 (src fec0::2) then 2001::1 (src 2001::2) Unchanged Result: fec0::1 (src fec0::2) then 2001::1 (src 2001::2)
(avoid deprecated addresses) (avoid deprecated addresses)
9.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
skipping to change at line 847 skipping to change at line 894
The routing within both sites directs most traffic to the egress to The routing within both sites directs most traffic to the egress to
the normal ISP, but the routing directs traffic sent to the other the normal ISP, but the routing directs traffic sent to the other
site's 2001 prefix to the egress to the high-performance ISP. To site's 2001 prefix to the egress to the high-performance ISP. To
prevent unintended use of their high-performance ISP connection, the prevent unintended use of their high-performance ISP connection, the
two sites implement ingress filtering to discard traffic entering two sites implement ingress filtering to discard traffic entering
from the high-performance ISP that is not from the other site. from the high-performance ISP that is not from the other site.
The default policy table and address selection rules produce the The default policy table and address selection rules produce the
following behavior: following behavior:
Candidate Set: 2001:aaaa:aaaa::a or 2007:0:aaaa::a or fe80::a Candidate Source Addresses: 2001:aaaa:aaaa::a or 2007:0:aaaa::a or
Destinations: 2001:bbbb:bbbb::b or 2007:0:bbbb::b fe80::a
Destination Address List: 2001:bbbb:bbbb::b or 2007:0:bbbb::b
Result: 2007:0:bbbb::b (src 2007:0:aaaa::a) then 2001:bbbb:bbbb::b Result: 2007:0:bbbb::b (src 2007:0:aaaa::a) then 2001:bbbb:bbbb::b
(src 2001:aaaa:aaaa::a) (longest matching prefix) (src 2001:aaaa:aaaa::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 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 Set: 2001:aaaa:aaaa::a or 2007:0:aaaa::a or fe80::a Candidate Source Addresses: 2001:aaaa:aaaa::a or 2007:0:aaaa::a or
Destinations: 2001:cccc:cccc::c or 2006:cccc:cccc::c fe80::a
Destination Address List: 2001:cccc:cccc::c or 2006:cccc:cccc::c
Result: 2001:cccc:cccc::c (src 2001:aaaa:aaaa::a) then Result: 2001:cccc:cccc::c (src 2001:aaaa:aaaa::a) then
2006:cccc:cccc::c (src 2007:0:aaaa::a) (longest matching prefix) 2006:cccc:cccc::c (src 2007:0:aaaa::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 may come back through
the high-performance ISP. Again, this is not their desired behavior. the high-performance ISP. Again, this is not their desired behavior.
This situation demonstrates the limitations of the longest-matching- This predicament demonstrates the limitations of the longest-
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 50 0 ::1 50 0
2001:aaaa:aaaa::/48 45 5 2001:aaaa:aaaa::/48 45 5
2001:bbbb:bbbb::/48 45 5 2001:bbbb:bbbb::/48 45 5
::/0 40 1 ::/0 40 1
skipping to change at line 881 skipping to change at line 930
can use the following policy table: can use the following policy table:
Prefix Precedence Label Prefix Precedence Label
::1 50 0 ::1 50 0
2001:aaaa:aaaa::/48 45 5 2001:aaaa:aaaa::/48 45 5
2001:bbbb:bbbb::/48 45 5 2001:bbbb:bbbb::/48 45 5
::/0 40 1 ::/0 40 1
2002::/16 30 2 2002::/16 30 2
::/96 20 3 ::/96 20 3
::ffff:0:0/96 10 4 ::ffff:0:0/96 10 4
This policy table produces the following behavior: This policy table produces the following behavior:
Candidate Set: 2001:aaaa:aaaa::a or 2007:0:aaaa::a or fe80::a Candidate Source Addresses: 2001:aaaa:aaaa::a or 2007:0:aaaa::a or
Destinations: 2001:bbbb:bbbb::b or 2007:0:bbbb::b fe80::a
Destination Address List: 2001:bbbb:bbbb::b or 2007:0:bbbb::b
New Result: 2001:bbbb:bbbb::b (src 2001:aaaa:aaaa::a) then New Result: 2001:bbbb:bbbb::b (src 2001:aaaa:aaaa::a) then
2007:0:bbbb::b (src 2007:0:aaaa::a) (prefer higher precedence) 2007:0:bbbb::b (src 2007:0:aaaa::a) (prefer higher precedence)
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 uses the high-performance ISP as host in site B, the traffic uses the high-performance ISP as
desired. desired.
Candidate Set: 2001:aaaa:aaaa::a or 2007:0:aaaa::a or fe80::a Candidate Source Addresses: 2001:aaaa:aaaa::a or 2007:0:aaaa::a or
Destinations: 2001:cccc:cccc::c or 2006:cccc:cccc::c fe80::a
Destination Address List: 2001:cccc:cccc::c or 2006:cccc:cccc::c
New Result: 2006:cccc:cccc::c (src 2007:0:aaaa::a) then New Result: 2006:cccc:cccc::c (src 2007:0:aaaa::a) then
2001:cccc:cccc::c (src 2007:0:aaaa::a) (longest matching prefix) 2001:cccc:cccc::c (src 2007:0:aaaa::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.
References References
1 S. Bradner, "The Internet Standards Process -- Revision 3", BCP 1 S. Bradner, "The Internet Standards Process -- Revision 3", BCP
skipping to change at line 928 skipping to change at line 978
6 S. Cheshire, B. Aboba, "Dynamic Configuration of IPv4 Link-local 6 S. Cheshire, B. Aboba, "Dynamic Configuration of IPv4 Link-local
Addresses", draft-ietf-zeroconf-ipv4-linklocal-04.txt, July 2001. Addresses", draft-ietf-zeroconf-ipv4-linklocal-04.txt, July 2001.
7 S. Bradner, "Key words for use in RFCs to Indicate Requirement 7 S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
8 R. Gilligan, S. Thomson, J. Bound, W. Stevens, "Basic Socket 8 R. Gilligan, S. Thomson, J. Bound, W. Stevens, "Basic Socket
Interface Extensions for IPv6", RFC 2553, March 1999. Interface Extensions for IPv6", RFC 2553, March 1999.
9 S. Deering et. al, "IP Version 6 Scoped Address Architecture", 9 B. Carpenter, K. Moore, "Connection of IPv6 Domains via IPv4
Clouds", RFC 3056, February 2001.
10 S. Deering et. al, "IP Version 6 Scoped Address Architecture",
draft-ietf-ipngwg-scoping-arch-03.txt, November 2001. draft-ietf-ipngwg-scoping-arch-03.txt, November 2001.
10 Y. Rekhter et. al, "Address Allocation for Private Internets", 11 Y. Rekhter et. al, "Address Allocation for Private Internets",
RFC 1918, February 1996. RFC 1918, February 1996.
11 F. Baker, Editor, "Requirements for IP Version 4 Routers", RFC 12 F. Baker, Editor, "Requirements for IP Version 4 Routers", RFC
1812, June 1995. 1812, June 1995.
12 B. Carpenter, K. Moore, "Connection of IPv6 Domains via IPv4 13 E. Nordmark, "Stateless IP/ICMP Translation Algorithm (SIIT)",
Clouds", RFC 3056, February 2001. RFC 2765, February 2000.
13 T. Narten, E. Nordmark, and W. Simpson, "Neighbor Discovery for 14 T. Narten, E. Nordmark, and W. Simpson, "Neighbor Discovery for
IP Version 6", RFC 2461, December 1998. IP Version 6", RFC 2461, December 1998.
14 B. Carpenter and C. Jung, "Transmission of IPv6 over IPv4 Domains 15 B. Carpenter and C. Jung, "Transmission of IPv6 over IPv4 Domains
without Explicit Tunnels", RFC 2529, March 1999. without Explicit Tunnels", RFC 2529, March 1999.
15 F. Templin et. al, "Intra-Site Automatic Tunnel Addressing 16 F. Templin et. al, "Intra-Site Automatic Tunnel Addressing
Protocol (ISATAP)", draft-ietf-ngtrans-isatap-03.txt, January Protocol (ISATAP)", draft-ietf-ngtrans-isatap-03.txt, January
2002. 2002.
16 R. Gilligan and E. Nordmark, "Transition Mechanisms for IPv6 17 R. Gilligan and E. Nordmark, "Transition Mechanisms for IPv6
Hosts and Routers", RFC 1933, April 1996. Hosts and Routers", RFC 1933, April 1996.
Acknowledgments Acknowledgments
The author would like to acknowledge the contributions of the IPng The author would like to acknowledge the contributions of the IPng
Working Group, particularly Marc Blanchet, Brian Carpenter, Matt Working Group, particularly Marc Blanchet, Brian Carpenter, Matt
Crawford, Alain Durand, Steve Deering, Robert Elz, Jun-ichiro itojun Crawford, Alain Durand, Steve Deering, Robert Elz, Jun-ichiro itojun
Hagino, Tony Hain, M.T. Hollinger, JINMEI Tatuya, Thomas Narten, Hagino, Tony Hain, M.T. Hollinger, JINMEI Tatuya, Thomas Narten,
Erik Nordmark, Ken Powell, Markku Savela, Pekka Savola, Dave Thaler, Erik Nordmark, Ken Powell, Markku Savela, Pekka Savola, Hesham
Mauro Tortonesi, Ole Troan, and Stig Venaas. Soliman, Dave Thaler, Mauro Tortonesi, Ole Troan, and Stig Venaas.
In addition, the anonymous IESG reviewers had many great comments
and suggestions for clarification.
Author's Address Author's Address
Richard Draves Richard Draves
Microsoft Research Microsoft Research
One Microsoft Way One Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
Phone: +1 425 706 2268 Phone: +1 425 706 2268
Email: richdr@microsoft.com Email: richdr@microsoft.com
Revision History Revision History
This section to be removed by the RFC editor upon publication.
Changes from draft-ietf-ipv6-default-addr-select-07
Added definitions and requirements for IPv4-mapped and IPv4-
translatable addresses, in support of SIIT.
Changed the requirement for an API to control temporary vs public
address preference in source address selection, from may to MUST.
Clarifications and editorial changes from the IESG.
Changes from draft-ietf-ipngwg-default-addr-select-06 Changes from draft-ietf-ipngwg-default-addr-select-06
Added a table of contents. Added a table of contents.
Modified the longest-matching-prefix destination-address selection Modified the longest-matching-prefix destination-address selection
rule, so that it only applies if the two destination addresses rule, so that it only applies if the two destination addresses
belong to the same address family. belong to the same address family.
Various great clarifications from Thomas Narten. Various great clarifications from Thomas Narten.
 End of changes. 86 change blocks. 
203 lines changed or deleted 270 lines changed or added

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