draft-ietf-6man-rfc3484bis-05.txt   draft-ietf-6man-rfc3484bis-06.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: December 2, 2012 A. Matsumoto Expires: December 29, 2012 A. Matsumoto
NTT NTT
T. Chown T. Chown
University of Southampton University of Southampton
May 31, 2012 June 27, 2012
Default Address Selection for Internet Protocol version 6 (IPv6) Default Address Selection for Internet Protocol version 6 (IPv6)
draft-ietf-6man-rfc3484bis-05.txt draft-ietf-6man-rfc3484bis-06.txt
Abstract Abstract
This document describes two algorithms, one for source address This document describes two algorithms, one for source address
selection and one for destination address selection. The algorithms selection and one for destination address selection. The algorithms
specify default behavior for all Internet Protocol version 6 (IPv6) specify default behavior for all Internet Protocol version 6 (IPv6)
implementations. They do not override choices made by applications implementations. They do not override choices made by applications
or upper-layer protocols, nor do they preclude the development of or upper-layer protocols, nor do they preclude the development of
more advanced mechanisms for address selection. The two algorithms more advanced mechanisms for address selection. The two algorithms
share a common context, including an optional mechanism for allowing share a common context, including an optional mechanism for allowing
skipping to change at page 2, line 4 skipping to change at page 2, line 4
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 December 2, 2012. This Internet-Draft will expire on December 29, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 13 skipping to change at page 3, line 13
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
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 . . . . . . . . . . . . . . . . . . . . 9
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 . . . . 10
3.4. IPv6 Loopback Address and Other Format Prefixes . . . . . 10 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 . . . . . . . . . . . . . . . . . . 11
5. Source Address Selection . . . . . . . . . . . . . . . . . . . 11 5. Source Address Selection . . . . . . . . . . . . . . . . . . . 12
6. Destination Address Selection . . . . . . . . . . . . . . . . 14 6. Destination Address Selection . . . . . . . . . . . . . . . . 14
7. Interactions with Routing . . . . . . . . . . . . . . . . . . 16 7. Interactions with Routing . . . . . . . . . . . . . . . . . . 17
8. Implementation Considerations . . . . . . . . . . . . . . . . 17 8. Implementation Considerations . . . . . . . . . . . . . . . . 17
9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18
10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
10.1. Default Source Address Selection . . . . . . . . . . . . . 18 10.1. Default Source Address Selection . . . . . . . . . . . . . 19
10.2. Default Destination Address Selection . . . . . . . . . . 19 10.2. Default Destination Address Selection . . . . . . . . . . 20
10.3. Configuring Preference for IPv6 or IPv4 . . . . . . . . . 20 10.3. Configuring Preference for IPv6 or IPv4 . . . . . . . . . 21
10.3.1. Handling Broken IPv6 . . . . . . . . . . . . . . . . 21 10.3.1. Handling Broken IPv6 . . . . . . . . . . . . . . . . 22
10.4. Configuring Preference for Link-Local Addresses . . . . . 21 10.4. Configuring Preference for Link-Local Addresses . . . . . 22
10.5. Configuring a Multi-Homed Site . . . . . . . . . . . . . . 22 10.5. Configuring a Multi-Homed Site . . . . . . . . . . . . . . 23
10.6. Configuring ULA Preference . . . . . . . . . . . . . . . . 24 10.6. Configuring ULA Preference . . . . . . . . . . . . . . . . 24
10.7. Configuring 6to4 Preference . . . . . . . . . . . . . . . 25 10.7. Configuring 6to4 Preference . . . . . . . . . . . . . . . 25
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 11. 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 . . . . . . . . . . . . . . . . . . 27
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 28 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 29
Appendix B. Changes Since RFC 3484 . . . . . . . . . . . . . . . 28 Appendix B. Changes Since RFC 3484 . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction 1. Introduction
The IPv6 addressing architecture [RFC4291] allows multiple unicast The IPv6 addressing architecture [RFC4291] allows multiple unicast
addresses to be assigned to interfaces. These addresses might have addresses to be assigned to interfaces. These addresses might have
different reachability scopes (link-local, site-local, or global). different reachability scopes (link-local, site-local, or global).
These addresses might also be "preferred" or "deprecated" [RFC4862]. These addresses might also be "preferred" or "deprecated" [RFC4862].
Privacy considerations have introduced the concepts of "public Privacy considerations have introduced the concepts of "public
addresses" and "temporary addresses" [RFC4941]. The mobility addresses" and "temporary addresses" [RFC4941]. The mobility
architecture introduces "home addresses" and "care-of addresses" architecture introduces "home addresses" and "care-of addresses"
skipping to change at page 5, line 42 skipping to change at page 5, line 42
2. Context in Which the Algorithms Operate 2. Context in Which the Algorithms Operate
Our context for address selection derives from the most common Our context for address selection derives from the most common
implementation architecture, which separates the choice of implementation architecture, which separates the choice of
destination address from the choice of source address. Consequently, destination address from the choice of source address. Consequently,
we have two separate algorithms for these tasks. The algorithms are we have two separate algorithms for these tasks. The algorithms are
designed to work well together and they share a mechanism for designed to work well together and they share a mechanism for
administrative policy override. administrative policy override.
In this implementation architecture, applications use APIs [RFC3493] In this implementation architecture, applications use APIs such as
like getaddrinfo() that return a list of addresses to the getaddrinfo() [RFC3493] that return a list of addresses to the
application. This list might contain both IPv6 and IPv4 addresses application. This list might contain both IPv6 and IPv4 addresses
(sometimes represented as IPv4-mapped addresses). The application (sometimes represented as IPv4-mapped addresses). The application
then passes a destination address to the network stack with connect() then passes a destination address to the network stack with connect()
or sendto(). The application would then typically try the first or sendto(). The application would then typically try the first
address in the list, looping over the list of addresses until it address in the list, looping over the list of addresses until it
finds a working address. In any case, the network layer is never in finds a working address. In any case, the network layer is never in
a situation where it needs to choose a destination address from a situation where it needs to choose a destination address from
several alternatives. The application might also specify a source several alternatives. The application might also specify a source
address with bind(), but often the source address is left address with bind(), but often the source address is left
unspecified. Therefore the network layer does often choose a source unspecified. Therefore the network layer does often choose a source
address from several alternatives. address from several alternatives.
As a consequence, we intend that implementations of getaddrinfo() As a consequence, we intend that implementations of APIs such as
will use the destination address selection algorithm specified here getaddrinfo() will use the destination address selection algorithm
to sort the list of IPv6 and IPv4 addresses that they return. specified here to sort the list of IPv6 and IPv4 addresses that they
Separately, the IPv6 network layer will use the source address return. Separately, the IPv6 network layer will use the source
selection algorithm when an application or upper-layer has not address selection algorithm when an application or upper-layer has
specified a source address. Application of this specification to not specified a source address. Application of this specification to
source address selection in an IPv4 network layer might be possible source address selection in an IPv4 network layer might be possible
but this is not explored further here. but this is not explored further here.
Well-behaved applications SHOULD NOT simply use the first address Well-behaved applications SHOULD NOT simply use the first address
returned from getaddrinfo() and then give up if it fails. For many returned from an API such as getaddrinfo() and then give up if it
applications, it is appropriate to iterate through the list of fails. For many applications, it is appropriate to iterate through
addresses returned from getaddrinfo() until a working address is the list of addresses returned from getaddrinfo() until a working
found. For other applications, it might be appropriate to try address is found. For other applications, it might be appropriate to
multiple in parallel (e.g., with some small delay in between) and use try multiple in parallel (e.g., with some small delay in between) and
the first one to succeed. use the first one to succeed.
Although source and destination address selection is most typically
done when initiating communication, a responder also must deal with
address selection. In many cases this is trivially dealt with by an
application using the source address of a received packet as the
response destination, and the destination address of the received
packet as the response source. Other cases, however, are handled
like an initiator, such as when the request was multicast and hence
source address selection must still occur when generating a response,
or when the request includes a list of the initiator's addresses from
which to choose a destination. Finally, a third application scenario
is that of a listening application choosing on what local addresses
to listen. This third scenario is out of scope for this document.
The algorithms use several criteria in making their decisions. The The algorithms use several criteria in making their decisions. The
combined effect is to prefer destination/source address pairs for combined effect is to prefer destination/source address pairs for
which the two addresses are of equal scope or type, prefer smaller which the two addresses are of equal scope or type, prefer smaller
scopes over larger scopes for the destination address, prefer non- scopes over larger scopes for the destination address, prefer non-
deprecated source addresses, avoid the use of transitional addresses deprecated source addresses, avoid the use of transitional addresses
when native addresses are available, and all else being equal prefer when native addresses are available, and all else being equal prefer
address pairs having the longest possible common prefix. For source address pairs having the longest possible common prefix. For source
address selection, temporary addresses [RFC4941] are preferred over address selection, temporary addresses [RFC4941] are preferred over
public addresses. In mobile situations [RFC6275], home addresses are public addresses. In mobile situations [RFC6275], home addresses are
skipping to change at page 8, line 10 skipping to change at page 8, line 27
to the default table based on its configured addresses, such as for to the default table based on its configured addresses, such as for
Unique Local Addresses (ULAs) [RFC4193] and 6to4 [RFC3056] addresses Unique Local Addresses (ULAs) [RFC4193] and 6to4 [RFC3056] addresses
for instance (see Section 10.6 and Section 10.7 for examples). Any for instance (see Section 10.6 and Section 10.7 for examples). Any
such rows automatically added by the implementation as a result of such rows automatically added by the implementation as a result of
address acquisition MUST NOT override a row for the same prefix address acquisition MUST NOT override a row for the same prefix
configured via other means. That is, rows can be added but never configured via other means. That is, rows can be added but never
updated automatically. An implementation SHOULD provide a means (the updated automatically. An implementation SHOULD provide a means (the
Automatic Row Additions flag) for an administrator to disable Automatic Row Additions flag) for an administrator to disable
automatic row additions. automatic row additions.
One effect of the default policy table is to prefer using native As will become apparent later, one effect of the default policy table
source addresses with native destination addresses, 6to4 source is to prefer using native source addresses with native destination
addresses with 6to4 destination addresses, etc. Another effect of addresses, 6to4 source addresses with 6to4 destination addresses,
the default policy table is to prefer communication using IPv6 etc. Another effect of the default policy table is to prefer
addresses to communication using IPv4 addresses, if matching source communication using IPv6 addresses to communication using IPv4
addresses are available. addresses, if matching source addresses are available.
Policy table entries for scoped address prefixes MAY be qualified Policy table entries for address prefixes that are not of global
with an optional zone index. If so, a prefix table entry only scope MAY be qualified with an optional zone index. If so, a prefix
matches against an address during a lookup if the zone index also table entry only matches against an address during a lookup if the
matches the address's zone index. zone index also 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
prefix (looking at the most significant, or leftmost, bits) that the prefix (looking at the most significant, or leftmost, bits) that the
two addresses have in common, up to the length of S's prefix (i.e., two addresses have in common, up to the length of S's prefix (i.e.,
the portion of the address not including the interface ID). For the portion of the address not including the interface ID). For
example, CommonPrefixLen(fe80::1, fe80::2) is 64. example, CommonPrefixLen(fe80::1, fe80::2) is 64.
skipping to change at page 8, line 47 skipping to change at page 9, line 16
addresses can be "preferred" or "deprecated" [RFC4862], while IPv4 addresses can be "preferred" or "deprecated" [RFC4862], while IPv4
addresses have no such notion. To compare such addresses using the addresses have no such notion. To compare such addresses using the
ordering rules (e.g., to use "preferred" addresses in preference to ordering rules (e.g., to use "preferred" addresses in preference to
"deprecated" addresses), the following mappings are defined. "deprecated" addresses), the following mappings are defined.
3.1. Scope Comparisons 3.1. Scope Comparisons
Multicast destination addresses have a 4-bit scope field that Multicast destination addresses have a 4-bit scope field that
controls the propagation of the multicast packet. The IPv6 controls the propagation of the multicast packet. The IPv6
addressing architecture defines scope field values for interface- addressing architecture defines scope field values for interface-
local (0x1), link-local (0x2), subnet-local (0x3), admin-local (0x4), local (0x1), link-local (0x2), admin-local (0x4), site-local (0x5),
site-local (0x5), organization-local (0x8), and global (0xE) scopes organization-local (0x8), and global (0xE) scopes ([RFC4291] Section
[RFC4007]. 2.7).
Use of the source address selection algorithm in the presence of Use of the source address selection algorithm in the presence of
multicast destination addresses requires the comparison of a unicast multicast destination addresses requires the comparison of a unicast
address scope with a multicast address scope. We map unicast link- address scope with a multicast address scope. We map unicast link-
local to multicast link-local, unicast site-local to multicast site- local to multicast link-local, unicast site-local to multicast site-
local, and unicast global scope to multicast global scope. For local, and unicast global scope to multicast global scope. For
example, unicast site-local is equal to multicast site-local, which example, unicast site-local is equal to multicast site-local, which
is smaller than multicast organization-local, which is smaller than is smaller than multicast organization-local, which is smaller than
unicast global, which is equal to multicast global. (Note that ULAs unicast global, which is equal to multicast global. (Note that IPv6
are considered as global, not site-local, scope but are handled via site-local unicast addresses are deprecated [RFC4291]. However, some
the prefix policy table as discussed in Section 10.6.) existing implementations and deployments may still use these
addresses and, therefore, they are included in the procedures in this
specification. Also 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
skipping to change at page 10, line 27 skipping to change at page 10, line 47
Some nodes might support mobility using the concepts of home address Some nodes might support mobility using the concepts of home address
and care-of address (for example see [RFC6275]). Conceptually, a and care-of address (for example see [RFC6275]). Conceptually, a
home address is an IP address assigned to a mobile node and used as home address is an IP address assigned to a mobile node and used as
the permanent address of the mobile node. A care-of address is an IP the permanent address of the mobile node. A care-of address is an IP
address associated with a mobile node while visiting a foreign link. address associated with a mobile node while visiting a foreign link.
When a mobile node is on its home link, it might have an address that When a mobile node is on its home link, it might have an address that
is simultaneously a home address and a care-of address. is simultaneously a home address and a care-of address.
For the purposes of this document, it is sufficient to know whether For the purposes of this document, it is sufficient to know whether
or not one's own addresses are designated as home addresses or one's own addresses are designated as home addresses or care-of
care-of addresses. Whether or not an address is designated a home addresses. Whether an address ought to be designated a home address
address or care-of address is outside the scope of this document. or care-of address is outside the scope of this 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.
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 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.
Implementations that wish to support the use of global source
addresses assigned to a loopback interface MUST behave as if the
loopback interface originates and forwards the packet.
Discussion: The Neighbor Discovery Redirect mechanism [RFC4861] Discussion: The Neighbor Discovery Redirect mechanism [RFC4861]
requires that routers verify that the source address of a packet requires that routers verify that the source address of a packet
identifies a neighbor before generating a Redirect, so it is identifies a neighbor before generating a Redirect, so it is
advantageous for hosts to choose source addresses assigned to the advantageous for hosts to choose source addresses assigned to the
outgoing interface. Implementations that wish to support the use outgoing interface.
of global source addresses assigned to a loopback interface MUST
behave as if the loopback interface originates and forwards the
packet.
In some cases the destination address might be qualified with a zone In some cases the destination address might be qualified with a zone
index or other information that will constrain the candidate set. index or other information that will constrain the candidate set.
For multicast and link-local destination addresses, the set of For all multicast and link-local destination addresses, the set of
candidate source addresses MUST only include addresses assigned to candidate source addresses MUST only include addresses assigned to
interfaces belonging to the same link as the outgoing interface. interfaces belonging to the same link as the outgoing interface.
Discussion: The restriction for multicast destination addresses is Discussion: The restriction for multicast destination addresses is
necessary because currently-deployed multicast forwarding necessary because currently-deployed multicast forwarding
algorithms use Reverse Path Forwarding (RPF) checks. algorithms use Reverse Path Forwarding (RPF) checks.
For site-local destination addresses, the set of candidate source For site-local unicast destination addresses, the set of candidate
addresses MUST only include addresses assigned to interfaces source addresses MUST only include addresses assigned to interfaces
belonging to the same site as the outgoing interface. belonging to the same site as the outgoing interface.
In any case, multicast addresses, and the unspecified address MUST In any case, multicast addresses, and the unspecified address MUST
NOT be included in a candidate set. NOT be included in a candidate set.
If an application or upper layer specifies a source address that is On IPv6-only nodes that support Stateless IP/ICMP Translation (SIIT)
not in the candidate set for the destination, then the network layer [RFC6145], if the destination address is an IPv4-converted address
MUST treat this as an error. The specified source address may then the candidate set MUST contain only IPv4-translatable addresses.
influence the candidate set, by affecting the choice of outgoing
interface. If the application or upper layer specifies a source
address that is in the candidate set for the destination, then the
network layer MUST respect that choice. If the application or upper
layer does not specify a source address, then the network layer uses
the source address selection algorithm specified in the next section.
On IPv6-only nodes that support SIIT [RFC6145], if the destination If an application or upper layer specifies a source address, it may
address is an IPv4-converted address then the candidate set MUST affect the choice of outgoing interface. Regardless, if the
contain only IPv4-translatable addresses. application or upper layer specifies a source address that is not in
the candidate set for the destination, then the network layer MUST
treat this as an error. If the application or upper layer specifies
a source address that is in the candidate set for the destination,
then the network layer MUST respect that choice. If the application
or upper layer does not specify a source address, then the network
layer uses the source address selection algorithm specified in the
next section.
5. Source Address Selection 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
skipping to change at page 12, line 27 skipping to change at page 12, line 48
for the two addresses, the remaining rules MUST be applied (in order) for the two addresses, the remaining rules MUST be applied (in order)
to just those addresses that are tied to break the tie. Note that if to just those addresses that are tied to break the tie. Note that if
a rule produces a single clear "winner" (or set of "winners" in the a rule produces a single clear "winner" (or set of "winners" in the
case of ties), those addresses not in the winning set can be case of ties), those addresses not in the winning set can be
discarded from further consideration, with subsequent rules applied discarded from further consideration, with subsequent rules applied
only to the remaining addresses. If the eight rules fail to choose a only to the remaining addresses. If the eight rules fail to choose a
single address, the tie-breaker is implementation-specific. single address, the 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. If neither is
stated to be preferred, this means that SA is "equal to" SB and the
remaining rules apply as noted above.
Rule 1: Prefer same address. Rule 1: Prefer same address.
If SA = D, then prefer SA. Similarly, if SB = D, then prefer SB. If SA = D, then prefer SA. Similarly, if SB = D, then prefer SB.
Rule 2: Prefer appropriate scope. Rule 2: Prefer appropriate scope.
If Scope(SA) < Scope(SB): If Scope(SA) < Scope(D), then prefer SB and If Scope(SA) < Scope(SB): If Scope(SA) < Scope(D), then prefer SB and
otherwise prefer SA. Similarly, if Scope(SB) < Scope(SA): If otherwise prefer SA. Similarly, if Scope(SB) < Scope(SA): If
Scope(SB) < Scope(D), then prefer SA and otherwise prefer SB. Scope(SB) < Scope(D), then prefer SA and otherwise prefer SB.
Discussion: This rule must be given high priority because it can
affect interoperability.
Rule 3: Avoid deprecated addresses. Rule 3: Avoid deprecated addresses.
The addresses SA and SB have the same scope. If one of the two If one of the two source addresses is "preferred" and one of them is
source addresses is "preferred" and one of them is "deprecated" (in "deprecated" (in the RFC 4862 sense), then prefer the one that is
the RFC 4862 sense), then prefer the one that is "preferred." "preferred."
Rule 4: Prefer home addresses. Rule 4: Prefer home addresses.
If SA is simultaneously a home address and care-of address and SB is If SA is simultaneously a home address and care-of address and SB is
not, then prefer SA. Similarly, if SB is simultaneously a home not, then prefer SA. Similarly, if SB is simultaneously a home
address and care-of address and SA is not, then prefer SB. If SA is address and care-of address and SA is not, then prefer SB. If SA is
just a home address and SB is just a care-of address, then prefer SA. just a home address and SB is just a care-of address, then prefer SA.
Similarly, if SB is just a home address and SA is just a care-of Similarly, if SB is just a home address and SA is just a care-of
address, then prefer SB. address, then prefer SB.
Implementations supporting home addresses MUST provide a mechanism Implementations supporting home addresses MUST provide a mechanism
skipping to change at page 13, line 23 skipping to change at page 13, line 51
Rule 5.5: Prefer addresses in a prefix advertised by the next-hop Rule 5.5: Prefer addresses in a prefix advertised by the next-hop
If SA or SA's prefix is assigned by the selected next-hop that will If SA or SA's prefix is assigned by the selected next-hop that will
be used to send to D and SB or SB's prefix is assigned by a different be used to send to D and SB or SB's prefix is assigned by a different
next-hop, then prefer SA. Similarly, if SB or SB's prefix is next-hop, then prefer SA. Similarly, if SB or SB's prefix is
assigned by the next-hop that will be used to send to D and SA or assigned by the next-hop that will be used to send to D and SA or
SA's prefix is assigned by a different next-hop, then prefer SB. SA's prefix is assigned by a different next-hop, then prefer SB.
Discussion: An IPv6 implementation is not required to remember Discussion: An IPv6 implementation is not required to remember
which next-hops advertised which prefixes. The conceptual models which next-hops advertised which prefixes. The conceptual models
of IPv6 hosts in Section 5 of [RFC4861] and Section 3 of [RFC4191] of IPv6 hosts in Section 5 of [RFC4861] and Section 3 of [RFC4191]
have no such requirement. Implementations that do not track this have no such requirement. Hence rule 5.5 is only applicable to
information shall omit rule 5.5. implementations that track this information.
Rule 6: Prefer matching label. Rule 6: Prefer matching label.
If Label(SA) = Label(D) and Label(SB) <> Label(D), then prefer SA. If Label(SA) = Label(D) and Label(SB) <> Label(D), then prefer SA.
Similarly, if Label(SB) = Label(D) and Label(SA) <> Label(D), then Similarly, if Label(SB) = Label(D) and Label(SA) <> Label(D), then
prefer SB. prefer SB.
Rule 7: Prefer temporary addresses. Rule 7: Prefer temporary addresses.
If SA is a temporary address and SB is a public address, then prefer If SA is a temporary address and SB is a public address, then prefer
SA. Similarly, if SB is a temporary address and SA is a public SA. Similarly, if SB is a temporary address and SA is a public
address, then prefer SB. address, then prefer SB.
skipping to change at page 14, line 15 skipping to change at page 14, line 42
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
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 MUST be represented as an IPv4-mapped address. address MUST be represented as an IPv4-mapped address.
skipping to change at page 15, line 48 skipping to change at page 16, line 20
Rule 6: Prefer higher precedence. Rule 6: Prefer higher precedence.
If Precedence(DA) > Precedence(DB), then prefer DA. Similarly, if If Precedence(DA) > Precedence(DB), then prefer DA. Similarly, if
Precedence(DA) < Precedence(DB), then prefer DB. Precedence(DA) < Precedence(DB), then prefer DB.
Rule 7: Prefer native transport. Rule 7: Prefer native transport.
If DA is reached via an encapsulating transition mechanism (e.g., If DA is reached via an encapsulating transition mechanism (e.g.,
IPv6 in IPv4) and DB is not, then prefer DB. Similarly, if DB is IPv6 in IPv4) and DB is not, then prefer DB. Similarly, if DB is
reached via encapsulation and DA is not, then prefer DA. reached via encapsulation and DA is not, then prefer DA.
Discussion: 6RD [RFC5969], ISATAP [RFC5214], and configured Discussion: "IPv6 Rapid Deployment on IPv4 Infrastructures" (6rd)
tunnels [RFC4213] are examples of encapsulating transition [RFC5969], the Intra-Site Automatic Tunnel Addressing Protocol
mechanisms for which the destination address does not have a (ISATAP) [RFC5214], and configured tunnels [RFC4213] are examples
specific prefix and hence can not be assigned a lower precedence of encapsulating transition mechanisms for which the destination
in the policy table. An implementation MAY generalize this rule address does not have a specific prefix and hence can not be
by using a concept of interface preference, and giving virtual assigned a lower precedence in the policy table. An
interfaces (like the IPv6-in-IPv4 encapsulating interfaces) a implementation MAY generalize this rule by using a concept of
lower preference than native interfaces (like ethernet interface preference, and giving virtual interfaces (like the
interfaces). IPv6-in-IPv4 encapsulating interfaces) a lower 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.
Rule 9: Use longest matching prefix. Rule 9: Use longest matching prefix.
When DA and DB belong to the same address family (both are IPv6 or When DA and DB belong to the same address family (both are IPv6 or
both are IPv4): If CommonPrefixLen(Source(DA), DA) > both are IPv4): If CommonPrefixLen(Source(DA), DA) >
CommonPrefixLen(Source(DB), DB), then prefer DA. Similarly, if CommonPrefixLen(Source(DB), DB), then prefer DA. Similarly, if
CommonPrefixLen(Source(DA), DA) < CommonPrefixLen(Source(DB), DB), CommonPrefixLen(Source(DA), DA) < CommonPrefixLen(Source(DB), DB),
skipping to change at page 18, line 18 skipping to change at page 18, line 38
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.
Similarly, most source and destination address selection algorithms,
including the one specified in this document, influence the choice of
network path taken (as do routing algorithms that are orthogonal to,
but used together with such algorithms) and hence whether data might
be sent over a path or network that might be more or less trusted
than other paths or networks. Administrators should consider the
security impact of the rows they configure in the prefix policy
table, just as they should consider the security impact of the
interface metrics used in the routing algorithms.
In addition, some address selection rules might be administratively In addition, some address selection rules might be administratively
configurable. Care must be taken to make sure that all configurable. Care must be taken to make sure that all
administrative options are secured against illicit modification, or administrative options are secured against illicit modification, or
else an attacker could redirect and/or block traffic. else an attacker could redirect and/or block traffic.
10. Examples 10. Examples
This section contains a number of examples, first of default behavior This section contains a number of examples, first 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 are not These examples are provided for illustrative purposes; they are not
skipping to change at page 24, line 14 skipping to change at page 24, line 49
New Result: 2001:db8:6ccc::c (src 2001:db8:70aa::a) then 2001:db8: New Result: 2001:db8:6ccc::c (src 2001:db8:70aa::a) then 2001:db8:
1ccc::c (src 2001:db8:70aa::a) (longest matching prefix) 1ccc::c (src 2001:db8:70aa::a) (longest matching prefix)
In other words, when a host in site A initiates a connection to a In other words, when a host in site A initiates a connection to a
host in some other site C, the traffic uses the normal ISP as host in some other site C, the traffic uses the normal ISP as
desired. desired.
10.6. Configuring ULA Preference 10.6. Configuring ULA Preference
RFC 5220 [RFC5220] sections 2.1.4, 2.2.2, and 2.2.3 describe address RFC 5220 [RFC5220] sections 2.1.4, 2.2.2, and 2.2.3 describe address
selection problems related to ULAs [RFC4193]. By default, global selection problems related to Unique Local Addresses (ULAs)
IPv6 destinations are preferred over ULA destinations, since an [RFC4193]. By default, global IPv6 destinations are preferred over
arbitrary ULA is not necessarily reachable: ULA destinations, since an arbitrary ULA is not necessarily
reachable:
Candidate Source Addresses: 2001:db8:1::1 or fd11:1111:1111:1::1 Candidate Source Addresses: 2001:db8:1::1 or fd11:1111:1111:1::1
Destination Address List: 2001:db8:2::2 or fd22:2222:2222:2::2 Destination Address List: 2001:db8:2::2 or fd22:2222:2222:2::2
Result: 2001:db8:2::2 (src 2001:db8:1::1) then fd22:2222:2222:2::2 Result: 2001:db8:2::2 (src 2001:db8:1::1) then fd22:2222:2222:2::2
(src fd11:1111:1111:1::1) (prefer higher precedence) (src fd11:1111:1111:1::1) (prefer higher precedence)
However, a site-specific policy entry can be used to cause ULAs However, a site-specific policy entry can be used to cause ULAs
within a site to be preferred over global addresses as follows. within a site to be preferred over global addresses as follows.
Prefix Precedence Label Prefix Precedence Label
 End of changes. 33 change blocks. 
95 lines changed or deleted 127 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/