draft-ietf-6man-rfc3484bis-01.txt   draft-ietf-6man-rfc3484bis-02.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: September 6, 2012 A. Matsumoto Expires: October 13, 2012 A. Matsumoto
NTT NTT
T. Chown T. Chown
University of Southampton University of Southampton
March 5, 2012 April 11, 2012
Default Address Selection for Internet Protocol version 6 (IPv6) Default Address Selection for Internet Protocol version 6 (IPv6)
draft-ietf-6man-rfc3484bis-01.txt draft-ietf-6man-rfc3484bis-02.txt
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 Internet Protocol version 6 (IPv6) 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 1, line 49 skipping to change at page 1, line 49
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 September 6, 2012. This Internet-Draft will expire on October 13, 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 24 skipping to change at page 3, line 24
3.2. IPv4 Addresses and IPv4-Mapped Addresses . . . . . . . . . 9 3.2. IPv4 Addresses and IPv4-Mapped Addresses . . . . . . . . . 9
3.3. Other IPv6 Addresses with Embedded IPv4 Addresses . . . . 9 3.3. Other IPv6 Addresses with Embedded IPv4 Addresses . . . . 9
3.4. IPv6 Loopback Address and Other Format Prefixes . . . . . 9 3.4. IPv6 Loopback Address and Other Format Prefixes . . . . . 9
3.5. Mobility Addresses . . . . . . . . . . . . . . . . . . . . 10 3.5. Mobility Addresses . . . . . . . . . . . . . . . . . . . . 10
4. Candidate Source Addresses . . . . . . . . . . . . . . . . . . 10 4. Candidate Source Addresses . . . . . . . . . . . . . . . . . . 10
5. Source Address Selection . . . . . . . . . . . . . . . . . . . 11 5. Source Address Selection . . . . . . . . . . . . . . . . . . . 11
6. Destination Address Selection . . . . . . . . . . . . . . . . 14 6. Destination Address Selection . . . . . . . . . . . . . . . . 14
7. Interactions with Routing . . . . . . . . . . . . . . . . . . 16 7. Interactions with Routing . . . . . . . . . . . . . . . . . . 16
8. Implementation Considerations . . . . . . . . . . . . . . . . 16 8. Implementation Considerations . . . . . . . . . . . . . . . . 16
9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17
10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
10.1. Default Source Address Selection . . . . . . . . . . . . . 18 10.1. Default Source Address Selection . . . . . . . . . . . . . 18
10.2. Default Destination Address Selection . . . . . . . . . . 18 10.2. Default Destination Address Selection . . . . . . . . . . 19
10.3. Configuring Preference for IPv6 or IPv4 . . . . . . . . . 20 10.3. Configuring Preference for IPv6 or IPv4 . . . . . . . . . 20
10.3.1. Handling Broken IPv6 . . . . . . . . . . . . . . . . 20 10.3.1. Handling Broken IPv6 . . . . . . . . . . . . . . . . 21
10.4. Configuring Preference for Link-Local Addresses . . . . . 21 10.4. Configuring Preference for Link-Local Addresses . . . . . 21
10.5. Configuring a Multi-Homed Site . . . . . . . . . . . . . . 21 10.5. Configuring a Multi-Homed Site . . . . . . . . . . . . . . 22
10.6. Configuring ULA Preference . . . . . . . . . . . . . . . . 23 10.6. Configuring ULA Preference . . . . . . . . . . . . . . . . 23
10.7. Configuring 6to4 Preference . . . . . . . . . . . . . . . 24 10.7. Configuring 6to4 Preference . . . . . . . . . . . . . . . 25
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
11.1. Normative References . . . . . . . . . . . . . . . . . . . 25 11.1. Normative References . . . . . . . . . . . . . . . . . . . 25
11.2. Informative References . . . . . . . . . . . . . . . . . . 26 11.2. Informative References . . . . . . . . . . . . . . . . . . 26
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 27 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 27
Appendix B. Changes Since RFC 3484 . . . . . . . . . . . . . . . 28 Appendix B. Changes Since RFC 3484 . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction 1. Introduction
The IPv6 addressing architecture [RFC4291] allows multiple unicast The IPv6 addressing architecture [RFC4291] allows multiple unicast
skipping to change at page 6, line 28 skipping to change at page 6, line 28
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 [RFC4941] are preferred over address selection, temporary addresses [RFC4941] are preferred over
temporary addresses. In mobile situations [RFC6275], home addresses public addresses. In mobile situations [RFC6275], home addresses are
are preferred over care-of addresses. If an address is preferred over care-of addresses. If an address is simultaneously a
simultaneously a home address and a care-of address (indicating the home address and a care-of address (indicating the mobile node is "at
mobile node is "at home" for that address), then the home/care-of home" for that address), then the home/care-of address is preferred
address is preferred over addresses that are solely a home address or over addresses that are solely a home address or solely a care-of
solely a care-of address. address.
This specification optionally allows for the possibility of This specification optionally allows for the possibility of
administrative configuration of policy (e.g., via manual administrative configuration of policy (e.g., via manual
configuration or a DHCP option such as that proposed in configuration or a DHCP option such as that proposed in
[I-D.ietf-6man-addr-select-opt]) that can override the default [I-D.ietf-6man-addr-select-opt]) 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
skipping to change at page 13, line 23 skipping to change at page 13, line 23
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. Implementations that do not track this
information shall omit rule 5.5. information shall omit rule 5.5.
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 temporary addresses.
If SA is a public address and SB is a temporary address, then prefer If SA is a temporary address and SB is a public address, then prefer
SA. Similarly, if SB is a public address and SA is a temporary SA. Similarly, if SB is a temporary address and SA is a public
address, then prefer SB. address, then prefer SB.
Implementations MUST provide a mechanism allowing an application to Implementations MUST provide a mechanism allowing an application to
reverse the sense of this preference and prefer temporary addresses reverse the sense of this preference and prefer public addresses over
over public addresses (e.g., via appropriate API extensions such as temporary addresses (e.g., via appropriate API extensions such as
[RFC5014]). Use of the mechanism should only affect the selection [RFC5014]). Use of the mechanism should only affect the selection
rules for the invoking application. This rule avoids applications rules for the invoking application. This default is intended to
potentially failing due to the relatively short lifetime of temporary address privacy concerns as discussed in [RFC4941], but introduces a
addresses or due to the possibility of the reverse lookup of a risk of applications potentially failing due to the relatively short
temporary address either failing or returning a randomized name. lifetime of temporary addresses or due to the possibility of the
Implementations for which privacy considerations outweigh these reverse lookup of a temporary address either failing or returning a
application compatibility concerns MAY reverse the sense of this rule randomized name. Implementations for which application compatibility
and by default prefer temporary addresses over public addresses. considerations outweigh these privacy concerns MAY reverse the sense
of this rule and by default prefer public addresses over temporary
addresses. There SHOULD be an administrative option to change this
preference, if the implementation supports temporary addresses. If
there is no such option, there MUST be an administrative option to
disable temporary addresses.
Rule 8: Use longest matching prefix. Rule 8: Use longest matching prefix.
If CommonPrefixLen(SA, D) > CommonPrefixLen(SB, D), then prefer SA. If CommonPrefixLen(SA, D) > CommonPrefixLen(SB, D), then prefer SA.
Similarly, if CommonPrefixLen(SB, D) > CommonPrefixLen(SA, D), then Similarly, if CommonPrefixLen(SB, D) > CommonPrefixLen(SA, D), then
prefer SB. prefer SB.
Rule 8 may be superseded if the implementation has other means of Rule 8 may be superseded if the implementation has other means of
choosing among source addresses. For example, if the implementation choosing among source addresses. For example, if the implementation
somehow knows which source address will result in the "best" somehow knows which source address will result in the "best"
communications performance. communications performance.
skipping to change at page 17, line 44 skipping to change at page 17, line 50
Note that most source address selection algorithms, including the one Note that most source address selection algorithms, including the one
specified in this document, expose a potential privacy concern. An specified in this document, expose a potential privacy concern. An
unfriendly node can infer correlations among a target node's unfriendly node can infer correlations among a target node's
addresses by probing the target node with request packets that force addresses by probing the target node with request packets that force
the target host to choose its source address for the reply packets. the target host to choose its source address for the reply packets.
(Perhaps because the request packets are sent to an anycast or (Perhaps because the request packets are sent to an anycast or
multicast address, or perhaps the upper-layer protocol chosen for the multicast address, or perhaps 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
addresses helps mitigate this concern.
In addition, some address selection rules may be administratively
configurable. Care must be taken to make sure that all
administrative options are secured against illicit modification, or
else an attacker could redirect and/or block traffic.
10. Examples 10. Examples
This section contains a number of examples, first of default behavior This section contains a number of examples, first of default behavior
and then demonstrating the utility of policy table configuration. and then demonstrating the utility of policy table configuration.
These examples are provided for illustrative purposes; they should These examples are provided for illustrative purposes; they should
not be construed as normative. not be construed as normative.
10.1. Default Source Address Selection 10.1. Default Source Address Selection
skipping to change at page 29, line 17 skipping to change at page 29, line 27
anycast addresses as source addresses was removed in Section 2.6 anycast addresses as source addresses was removed in Section 2.6
of RFC 4291 [RFC4291]. of RFC 4291 [RFC4291].
4. Changed mapping of RFC 1918 [RFC1918] addresses to global scope 4. Changed mapping of RFC 1918 [RFC1918] addresses to global scope
in Section Section 3.2. Previously they were mapped to site- in Section Section 3.2. Previously they were mapped to site-
local scope. However, experience has resulted in current local scope. However, experience has resulted in current
implementations already using global scope instead. When they implementations already using global scope instead. When they
were mapped to site-local, Destination Address Selection Rule 2 were mapped to site-local, Destination Address Selection Rule 2
(Prefer matching scope) would cause IPv6 to be preferred in (Prefer matching scope) would cause IPv6 to be preferred in
scenarios such as that described in Section 10.7. The change to scenarios such as that described in Section 10.7. The change to
global scope allows configurability via the prefix policy table. global scope allows configurability via the prefix policy table.
5. Changed the default recommendation for Source Address Selection
Rule 7 to prefer temporary addresses rather than public
addresses, while providing an administrative override (in
addition to the application-specific override that was already
specified). This change was made because of the increasing
importance of privacy considerations, as well as the fact that
widely deployed implementations have preferred temporary
addresses for many years without major application issues.
Finally, some editorial changes were made, including: Finally, some editorial changes were made, including:
1. Changed global IP addresses in examples to use ranges reserved 1. Changed global IP addresses in examples to use ranges reserved
for documentation. for documentation.
2. Added additional examples in Section 10.6 and Section 10.7. 2. Added additional examples in Section 10.6 and Section 10.7.
3. Added Section 10.3.1 on "broken" IPv6. 3. Added Section 10.3.1 on "broken" IPv6.
4. Updated references. 4. Updated references.
Authors' Addresses Authors' Addresses
 End of changes. 15 change blocks. 
28 lines changed or deleted 48 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/