--- 1/draft-ietf-6man-rfc3484bis-01.txt 2012-04-11 01:13:56.982671027 +0200 +++ 2/draft-ietf-6man-rfc3484bis-02.txt 2012-04-11 01:13:57.038672172 +0200 @@ -1,23 +1,23 @@ Network Working Group D. Thaler, Ed. Internet-Draft Microsoft Obsoletes: 3484 (if approved) R. Draves Intended status: Standards Track Microsoft Research -Expires: September 6, 2012 A. Matsumoto +Expires: October 13, 2012 A. Matsumoto NTT T. Chown University of Southampton - March 5, 2012 + April 11, 2012 Default Address Selection for Internet Protocol version 6 (IPv6) - draft-ietf-6man-rfc3484bis-01.txt + draft-ietf-6man-rfc3484bis-02.txt Abstract This document describes two algorithms, for source address selection and for destination address selection. The algorithms specify default behavior for all Internet Protocol version 6 (IPv6) implementations. They do not override choices made by applications or upper-layer protocols, nor do they preclude the development of more advanced mechanisms for address selection. The two algorithms share a common context, including an optional mechanism for allowing @@ -38,21 +38,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -86,29 +86,29 @@ 3.2. IPv4 Addresses and IPv4-Mapped Addresses . . . . . . . . . 9 3.3. Other IPv6 Addresses with Embedded IPv4 Addresses . . . . 9 3.4. IPv6 Loopback Address and Other Format Prefixes . . . . . 9 3.5. Mobility Addresses . . . . . . . . . . . . . . . . . . . . 10 4. Candidate Source Addresses . . . . . . . . . . . . . . . . . . 10 5. Source Address Selection . . . . . . . . . . . . . . . . . . . 11 6. Destination Address Selection . . . . . . . . . . . . . . . . 14 7. Interactions with Routing . . . . . . . . . . . . . . . . . . 16 8. Implementation Considerations . . . . . . . . . . . . . . . . 16 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 - 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 + 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 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.1. Handling Broken IPv6 . . . . . . . . . . . . . . . . 20 + 10.3.1. Handling Broken IPv6 . . . . . . . . . . . . . . . . 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.7. Configuring 6to4 Preference . . . . . . . . . . . . . . . 24 + 10.7. Configuring 6to4 Preference . . . . . . . . . . . . . . . 25 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 11.1. Normative References . . . . . . . . . . . . . . . . . . . 25 11.2. Informative References . . . . . . . . . . . . . . . . . . 26 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 27 Appendix B. Changes Since RFC 3484 . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 1. Introduction The IPv6 addressing architecture [RFC4291] allows multiple unicast @@ -221,27 +221,27 @@ addresses returned from getaddrinfo() until they find a working address. The algorithms use several criteria in making their decisions. The combined effect is to prefer destination/source address pairs for which the two addresses are of equal scope or type, prefer smaller scopes over larger scopes for the destination address, prefer non- deprecated source addresses, avoid the use of transitional addresses when native addresses are available, and all else being equal prefer address pairs having the longest possible common prefix. For source - address selection, public addresses [RFC4941] are preferred over - temporary addresses. In mobile situations [RFC6275], home addresses - are preferred over care-of addresses. If an address is - simultaneously a home address and a care-of address (indicating the - mobile node is "at home" for that address), then the home/care-of - address is preferred over addresses that are solely a home address or - solely a care-of address. + address selection, temporary addresses [RFC4941] are preferred over + public addresses. In mobile situations [RFC6275], home addresses are + preferred over care-of addresses. If an address is simultaneously a + home address and a care-of address (indicating the mobile node is "at + home" for that address), then the home/care-of address is preferred + over addresses that are solely a home address or solely a care-of + address. This specification optionally allows for the possibility of administrative configuration of policy (e.g., via manual configuration or a DHCP option such as that proposed in [I-D.ietf-6man-addr-select-opt]) that can override the default behavior of the algorithms. The policy override takes the form of a configurable table that specifies precedence values and preferred source prefixes for destination prefixes. If an implementation is not configurable, or if an implementation has not been configured, then the default policy table specified in this document SHOULD be @@ -548,36 +548,41 @@ which next-hops advertised which prefixes. The conceptual models of IPv6 hosts in Section 5 of [RFC4861] and Section 3 of [RFC4191] have no such requirement. Implementations that do not track this information shall omit rule 5.5. Rule 6: Prefer matching label. 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 prefer SB. - Rule 7: Prefer public addresses. - 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 + Rule 7: Prefer temporary addresses. + 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 address, then prefer SB. Implementations MUST provide a mechanism allowing an application to - reverse the sense of this preference and prefer temporary addresses - over public addresses (e.g., via appropriate API extensions such as + reverse the sense of this preference and prefer public addresses over + temporary addresses (e.g., via appropriate API extensions such as [RFC5014]). Use of the mechanism should only affect the selection - rules for the invoking application. This rule avoids applications - potentially failing due to the relatively short lifetime of temporary - addresses or due to the possibility of the reverse lookup of a - temporary address either failing or returning a randomized name. - Implementations for which privacy considerations outweigh these - application compatibility concerns MAY reverse the sense of this rule - and by default prefer temporary addresses over public addresses. + rules for the invoking application. This default is intended to + address privacy concerns as discussed in [RFC4941], but introduces a + risk of applications potentially failing due to the relatively short + lifetime of temporary addresses or due to the possibility of the + reverse lookup of a temporary address either failing or returning a + randomized name. Implementations for which application compatibility + 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. If CommonPrefixLen(SA, D) > CommonPrefixLen(SB, D), then prefer SA. Similarly, if CommonPrefixLen(SB, D) > CommonPrefixLen(SA, D), then prefer SB. Rule 8 may be superseded if the implementation has other means of choosing among source addresses. For example, if the implementation somehow knows which source address will result in the "best" communications performance. @@ -761,20 +767,27 @@ Note that most source address selection algorithms, including the one specified in this document, expose a potential privacy concern. An unfriendly node can infer correlations among a target node's addresses by probing the target node with request packets that force the target host to choose its source address for the reply packets. (Perhaps because the request packets are sent to an anycast or multicast address, or perhaps the upper-layer protocol chosen for the attack does not specify a particular source address for its reply packets.) By using different addresses for itself, the unfriendly 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 This section contains a number of examples, first of default behavior and then demonstrating the utility of policy table configuration. These examples are provided for illustrative purposes; they should not be construed as normative. 10.1. Default Source Address Selection @@ -1304,20 +1316,28 @@ anycast addresses as source addresses was removed in Section 2.6 of RFC 4291 [RFC4291]. 4. Changed mapping of RFC 1918 [RFC1918] addresses to global scope in Section Section 3.2. Previously they were mapped to site- local scope. However, experience has resulted in current implementations already using global scope instead. When they were mapped to site-local, Destination Address Selection Rule 2 (Prefer matching scope) would cause IPv6 to be preferred in scenarios such as that described in Section 10.7. The change to 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: 1. Changed global IP addresses in examples to use ranges reserved for documentation. 2. Added additional examples in Section 10.6 and Section 10.7. 3. Added Section 10.3.1 on "broken" IPv6. 4. Updated references. Authors' Addresses