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