--- 1/draft-ietf-6man-rfc3484-revise-04.txt 2011-11-01 01:14:24.314670983 +0100 +++ 2/draft-ietf-6man-rfc3484-revise-05.txt 2011-11-01 01:14:24.338671508 +0100 @@ -1,21 +1,21 @@ Network Working Group A. Matsumoto Internet-Draft J. Kato Intended status: Standards Track T. Fujisaki -Expires: January 2, 2012 NTT +Expires: April 3, 2012 NTT T. Chown University of Southampton - July 1, 2011 + October 2011 Update to RFC 3484 Default Address Selection for IPv6 - draft-ietf-6man-rfc3484-revise-04.txt + draft-ietf-6man-rfc3484-revise-05.txt Abstract RFC 3484 describes algorithms for source address selection and for destination address selection. The algorithms specify default behavior for all Internet Protocol version 6 (IPv6) implementations. This document specifies a set of updates that modify the algorithms and fix the known defects. Status of this Memo @@ -26,21 +26,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 January 2, 2012. + This Internet-Draft will expire on April 3, 2012. Copyright Notice Copyright (c) 2011 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 @@ -69,31 +69,32 @@ 2.1. Changes related to the default policy table . . . . . . . 3 2.1.1. ULA in the policy table . . . . . . . . . . . . . . . 4 2.1.2. Teredo in the policy table . . . . . . . . . . . . . . 4 2.1.3. 6to4, Teredo, and IPv4 prioritization . . . . . . . . 4 2.1.4. Deprecated addresses in the policy table . . . . . . . 5 2.1.5. Renewed default policy table . . . . . . . . . . . . . 5 2.2. The longest matching rule . . . . . . . . . . . . . . . . 5 2.3. Utilize next-hop for source address selection . . . . . . 6 2.4. Private IPv4 address scope . . . . . . . . . . . . . . . . 6 2.5. Deprecation of site-local unicast address . . . . . . . . 7 + 2.6. Anycast addresses for candidate source addresses . . . . . 7 3. Security Considerations . . . . . . . . . . . . . . . . . . . 7 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Normative References . . . . . . . . . . . . . . . . . . . 8 5.2. Informative References . . . . . . . . . . . . . . . . . . 8 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 9 Appendix B. Past Discussion . . . . . . . . . . . . . . . . . . . 9 B.1. The longest match rule . . . . . . . . . . . . . . . . . . 9 B.2. NAT64 prefix issue . . . . . . . . . . . . . . . . . . . . 10 B.3. ISATAP issue . . . . . . . . . . . . . . . . . . . . . . . 10 - Appendix C. Revision History . . . . . . . . . . . . . . . . . . 10 + Appendix C. Revision History . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction The IPv6 addressing architecture [RFC4291] allows multiple unicast addresses to be assigned to interfaces. Because of this IPv6 implementations need to handle multiple possible source and destination addresses when initiating communication. RFC 3484 [RFC3484] specifies the default algorithms, common across all implementations, for selecting source and destination addresses so @@ -184,45 +185,43 @@ IPv4. These mechanisms are said to be the last resort access method to IPv6 resources. 6to4 should have higher precedence than Teredo, given that 6to4 host to 6to4 host communication can be over IPv4 (which can result in a more optimal path) and that 6to4 should not used behind a NAT device. 2.1.4. Deprecated addresses in the policy table IPv4-compatible IPv6 addresses (::/96) are deprecated [RFC4291]. IPv6 site-local unicast addresses (fec0::/10) are deprecated - [RFC3879]. 6bone testing addresses [RFC3701] were returned. - - These addresses were removed from the current specification. So they - should not be treated differently, especially if we plan future re- - use of these address blocks. The 6bone testing address block should - not be treated specially. + [RFC3879]. 6bone testing addresses [RFC3701] has also been phased + out. + These addresses were removed from the current specification. Considering the inappropriate use of these address blocks, especially in outdated implementations and bad effects brought by them, they should be labeled differently from the legitimate address blocks as long as the address block is reserved by IANA. 2.1.5. Renewed default policy table After applying these updates, the default policy table will be: Prefix Precedence Label ::1/128 60 0 fc00::/7 50 1 ::/0 40 2 ::ffff:0:0/96 30 3 2002::/16 20 4 2001::/32 10 5 ::/96 1 10 fec0::/10 1 11 + 3ffe::/16 1 12 2.2. The longest matching rule This issue is related to the longest matching rule, which was found by Dave Thaler. It causes a malfunction of the DNS round robin technique, as described below. It is common for both IPv4 and IPv6. When a destination address DA, DB, and the source address of DA Source(DA) are on the same subnet and Source(DA) == Source(DB), DNS round robin load-balancing cannot function. By considering prefix @@ -305,20 +304,29 @@ RFC 3484 contains a few "site-local unicast" and "fec0::" descriptions. It's better to remove examples related to site-local unicast addresses, or change the examples to use ULAs. Possible points to be re-written are listed below. - 2nd paragraph in RFC 3484 Section 3.1 describes the scope comparison mechanism. - RFC 3484 Section 10 contains examples for site-local addresses. +2.6. Anycast addresses for candidate source addresses + + RFC 3484 Section 4 states that anycast addresses, as well as + multicast addresses and the unspecified address, MUST NOT be included + in a candidate set of source address. Now that RFC 4291 Section 2.6 + [RFC4291] removed the restrictions on using IPv6 anycast addresses as + the source address of an IPv6 packet, this restriction of RFC 3484 + should also be removed. + 3. Security Considerations No security risk is found that degrades RFC 3484. 4. IANA Considerations Address type number for the policy table may have to be assigned by IANA. 5. References @@ -386,22 +395,23 @@ Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000. [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, October 2010. Appendix A. Acknowledgements Authors would like to thank to Dave Thaler, Pekka Savola, Remi Denis- - Courmont and the members of 6man's address selection design team for - their invaluable contributions to this document. + Courmont, Francois-Xavier Le Bail, and the members of 6man's address + selection design team for their invaluable contributions to this + document. Appendix B. Past Discussion This section summarizes discussions we had before related to address selection mechanisms. B.1. The longest match rule RFC 3484 defines that destination address selection rule 9 should be applied to both IPv4 and IPv6, which spoils the DNS-based load @@ -451,25 +461,28 @@ Where a site is using ISATAP [RFC5214], there is generally no way to differentiate an ISATAP address from a native address without interface information. However, a site will assign a prefix for its ISATAP overlay, and can choose to add an entry for that prefix to the policy table if it wishes to change the default preference for that prefix. Appendix C. Revision History + 05: + 6bone testing addresses were back in the default policy table. + Section 2.6 for allowing anycast source address were added. + 04: Added comment about ISATAP. 03: - ULA address selection issue was expanded. 6to4, Teredo and IPv4 prioritization issue was elaborated. Deprecated address blocks in policy table section was elaborated. In appendix, NAT64 prefix issue was added. 02: Suresh Krishnan's suggestions for better english sentences were incorporated. A new source address selection rule that utilizes the next-hop information is included in Section 2.3.