draft-ietf-6man-rfc3484bis-02.txt   draft-ietf-6man-rfc3484bis-03.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: October 13, 2012 A. Matsumoto Expires: November 6, 2012 A. Matsumoto
NTT NTT
T. Chown T. Chown
University of Southampton University of Southampton
April 11, 2012 May 5, 2012
Default Address Selection for Internet Protocol version 6 (IPv6) Default Address Selection for Internet Protocol version 6 (IPv6)
draft-ietf-6man-rfc3484bis-02.txt draft-ietf-6man-rfc3484bis-03.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 October 13, 2012. This Internet-Draft will expire on November 6, 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
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 . . . . . . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . . . 8
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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
10.1. Default Source Address Selection . . . . . . . . . . . . . 18 10.1. Default Source Address Selection . . . . . . . . . . . . . 18
10.2. Default Destination Address Selection . . . . . . . . . . 19 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 . . . . . . . . . . . . . . . . 21 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 . . . . . . . . . . . . . . 22 10.5. Configuring a Multi-Homed Site . . . . . . . . . . . . . . 22
10.6. Configuring ULA Preference . . . . . . . . . . . . . . . . 23 10.6. Configuring ULA Preference . . . . . . . . . . . . . . . . 24
10.7. Configuring 6to4 Preference . . . . . . . . . . . . . . . 25 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 . . . . . . . . . . . . . . . . . . 28
Appendix B. Changes Since RFC 3484 . . . . . . . . . . . . . . . 28 Appendix B. Changes Since RFC 3484 . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
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 may have addresses to be assigned to interfaces. These addresses may have
different reachability scopes (link-local, site-local, or global). different reachability scopes (link-local, site-local, or global).
These addresses may also be "preferred" or "deprecated" [RFC4862]. These addresses may 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 6, line 40 skipping to change at page 6, line 40
preferred over care-of addresses. If an address is simultaneously a 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 address and a care-of address (indicating the mobile node is "at
home" for that address), then the home/care-of address is preferred 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 over addresses that are solely a home address or 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 consists of the
configurable table that specifies precedence values and preferred following set of state, which SHOULD be configurable:
source prefixes for destination prefixes. If an implementation is
not configurable, or if an implementation has not been configured, o Policy Table (Section 2.1): a table that specifies precedence
then the default policy table specified in this document SHOULD be values and preferred source prefixes for destination prefixes.
used. o Automatic Row Additions flag (Section 2.1): a flag that specifies
whether the implementation may automatically add site-specific
rows for certain types of addresses.
o Privacy Preference flag (Section 5): a flag that specifies whether
temporary source addresses or stable source addresses are
preferred by default, when both types exist.
2.1. Policy Table 2.1. Policy Table
The policy table is a longest-matching-prefix lookup table, much like The policy table is a longest-matching-prefix lookup table, much like
a routing table. Given an address A, a lookup in the policy table a routing table. Given an address A, a lookup in the policy table
produces two values: a precedence value Precedence(A) and a produces two values: a precedence value Precedence(A) and a
classification or label Label(A). classification or label Label(A).
The precedence value Precedence(A) is used for sorting destination The precedence value Precedence(A) is used for sorting destination
addresses. If Precedence(A) > Precedence(B), we say that address A addresses. If Precedence(A) > Precedence(B), we say that address A
skipping to change at page 7, line 19 skipping to change at page 7, line 25
prefer to sort destination address A before destination address B. prefer to sort destination address A before destination address B.
The label value Label(A) allows for policies that prefer a particular The label value Label(A) allows for policies that prefer a particular
source address prefix for use with a destination address prefix. The source address prefix for use with a destination address prefix. The
algorithms prefer to use a source address S with a destination algorithms prefer to use a source address S with a destination
address D if Label(S) = Label(D). address D if Label(S) = Label(D).
IPv6 implementations SHOULD support configurable address selection IPv6 implementations SHOULD support configurable address selection
via a mechanism at least as powerful as the policy tables defined via a mechanism at least as powerful as the policy tables defined
here. It is important that implementations provide a way to change here. It is important that implementations provide a way to change
the default policies as more experience is gained. Sections 10.3 and the default policies as more experience is gained. Sections 10.3
10.4 provide examples of the kind of changes that might be needed. through 10.7 provide examples of the kind of changes that might be
needed.
If an implementation is not configurable or has not been configured, If an implementation is not configurable or has not been configured,
then it SHOULD operate according to the algorithms specified here in then it SHOULD operate according to the algorithms specified here in
conjunction with the following default policy table: conjunction with the following default policy table:
Prefix Precedence Label Prefix Precedence Label
::1/128 50 0 ::1/128 50 0
::/0 40 1 ::/0 40 1
::ffff:0:0/96 35 4 ::ffff:0:0/96 35 4
2002::/16 30 2 2002::/16 30 2
skipping to change at page 7, line 44 skipping to change at page 7, line 51
fec0::/10 1 11 fec0::/10 1 11
3ffe::/16 1 12 3ffe::/16 1 12
An implementation MAY automatically add additional site-specific rows An implementation MAY automatically add additional site-specific rows
to the default table based on its configured addresses, such as for to the default table based on its configured addresses, such as for
ULAs and 6to4 addresses for instance (see Section 10.6 and ULAs and 6to4 addresses for instance (see Section 10.6 and
Section 10.7 for examples). Any such rows automatically added by the Section 10.7 for examples). Any such rows automatically added by the
implementation as a result of address acquisition MUST NOT override a implementation as a result of address acquisition MUST NOT override a
row for the same prefix configured via other means. That is, rows row for the same prefix configured via other means. That is, rows
can be added but never updated automatically. An implementation can be added but never updated automatically. An implementation
SHOULD provide a means for an administrator to disable automatic row SHOULD provide a means (the Automatic Row Additions flag) for an
additions. administrator to disable automatic row additions.
One effect of the default policy table is to prefer using native One effect of the default policy table is to prefer using native
source addresses with native destination addresses, 6to4 [RFC3056] source addresses with native destination addresses, 6to4 [RFC3056]
source addresses with 6to4 destination addresses, etc. Another source addresses with 6to4 destination addresses, etc. Another
effect of the default policy table is to prefer communication using effect of the default policy table is to prefer communication using
IPv6 addresses to communication using IPv4 addresses, if matching IPv6 addresses to communication using IPv4 addresses, if matching
source addresses are available. source addresses are available.
Policy table entries for scoped address prefixes MAY be qualified Policy table entries for scoped address prefixes MAY be qualified
with an optional zone index. If so, a prefix table entry only with an optional zone index. If so, a prefix table entry only
skipping to change at page 9, line 19 skipping to change at page 9, line 24
3.2. IPv4 Addresses and IPv4-Mapped Addresses 3.2. IPv4 Addresses and IPv4-Mapped Addresses
The destination address selection algorithm operates on both IPv6 and The destination address selection algorithm operates on both IPv6 and
IPv4 addresses. For this purpose, IPv4 addresses should be IPv4 addresses. For this purpose, IPv4 addresses should be
represented as IPv4-mapped addresses [RFC4291]. For example, to represented as IPv4-mapped addresses [RFC4291]. For example, to
lookup the precedence or other attributes of an IPv4 address in the lookup the precedence or other attributes of an IPv4 address in the
policy table, lookup the corresponding IPv4-mapped IPv6 address. policy table, lookup the corresponding IPv4-mapped IPv6 address.
IPv4 addresses are assigned scopes as follows. IPv4 auto- IPv4 addresses are assigned scopes as follows. IPv4 auto-
configuration addresses [RFC3927], which have the prefix 169.254/16, configuration addresses [RFC3927], which have the prefix 169.254/16,
are assigned link-local scope. IPv4 private addresses [RFC1918], are assigned link-local scope. IPv4 loopback addresses ([RFC1918],
which have the prefixes 10/8, 172.16/12, and 192.168/16, are assigned section 4.2.2.11), which have the prefix 127/8, are assigned link-
global scope. IPv4 loopback addresses ([RFC1918], section 4.2.2.11), local scope (analogously to the treatment of the IPv6 loopback
which have the prefix 127/8, are assigned link-local scope address ([RFC4007], section 4)). Other IPv4 addresses (including
(analogously to the treatment of the IPv6 loopback address IPv4 private addresses [RFC1918] and Shared Address Space addresses
([RFC4007], section 4)). Other IPv4 addresses are assigned global [RFC6598]) are assigned global scope.
scope.
IPv4 addresses should be treated as having "preferred" (in the RFC IPv4 addresses should be treated as having "preferred" (in the RFC
4862 sense) configuration status. 4862 sense) configuration status.
3.3. Other IPv6 Addresses with Embedded IPv4 Addresses 3.3. Other IPv6 Addresses with Embedded IPv4 Addresses
IPv4-compatible addresses [RFC4291], IPv4-mapped [RFC4291], IPv4- IPv4-compatible addresses [RFC4291], IPv4-mapped [RFC4291], IPv4-
converted [RFC6145], IPv4-translatable [RFC6145], and 6to4 addresses converted [RFC6145], IPv4-translatable [RFC6145], and 6to4 addresses
[RFC3056] contain an embedded IPv4 address. For the purposes of this [RFC3056] contain an embedded IPv4 address. For the purposes of this
document, these addresses should be treated as having global scope. document, these addresses should be treated as having global scope.
skipping to change at page 13, line 40 skipping to change at page 13, line 43
temporary 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 default is intended to rules for the invoking application. This default is intended to
address privacy concerns as discussed in [RFC4941], but introduces a address privacy concerns as discussed in [RFC4941], but introduces a
risk of applications potentially failing due to the relatively short risk of applications potentially failing due to the relatively short
lifetime of temporary addresses or due to the possibility of the lifetime of temporary addresses or due to the possibility of the
reverse lookup of a temporary address either failing or returning a reverse lookup of a temporary address either failing or returning a
randomized name. Implementations for which application compatibility randomized name. Implementations for which application compatibility
considerations outweigh these privacy concerns MAY reverse the sense considerations outweigh these privacy concerns MAY reverse the sense
of this rule and by default prefer public addresses over temporary of this rule and by default prefer public addresses over temporary
addresses. There SHOULD be an administrative option to change this addresses. There SHOULD be an administrative option (the Privacy
preference, if the implementation supports temporary addresses. If Preference flag) to change this preference, if the implementation
there is no such option, there MUST be an administrative option to supports temporary addresses. If there is no such option, there MUST
disable temporary addresses. 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 27, line 47 skipping to change at page 27, line 51
Infrastructures (6rd) -- Protocol Specification", Infrastructures (6rd) -- Protocol Specification",
RFC 5969, August 2010. RFC 5969, August 2010.
[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.
[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
in IPv6", RFC 6275, July 2011. in IPv6", RFC 6275, July 2011.
[RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and
M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address
Space", BCP 153, RFC 6598, April 2012.
Appendix A. Acknowledgements Appendix A. Acknowledgements
RFC 3484 acknowledged the contributions of the IPng Working Group, RFC 3484 acknowledged the contributions of the IPng Working Group,
particularly Marc Blanchet, Brian Carpenter, Matt Crawford, Alain particularly Marc Blanchet, Brian Carpenter, Matt Crawford, Alain
Durand, Steve Deering, Robert Elz, Jun-ichiro itojun Hagino, Tony Durand, Steve Deering, Robert Elz, Jun-ichiro itojun Hagino, Tony
Hain, M.T. Hollinger, JINMEI Tatuya, Thomas Narten, Erik Nordmark, Hain, M.T. Hollinger, JINMEI Tatuya, Thomas Narten, Erik Nordmark,
Ken Powell, Markku Savela, Pekka Savola, Hesham Soliman, Dave Thaler, Ken Powell, Markku Savela, Pekka Savola, Hesham Soliman, Dave Thaler,
Mauro Tortonesi, Ole Troan, and Stig Venaas. In addition, the Mauro Tortonesi, Ole Troan, and Stig Venaas. In addition, the
anonymous IESG reviewers had many great comments and suggestions for anonymous IESG reviewers had many great comments and suggestions for
clarification. clarification.
This revision was heavily influenced by the work by Arifumi This revision was heavily influenced by the work by Arifumi
Matsumoto, Jun-ya Kato, and Tomohiro Fujisaki in a working draft that Matsumoto, Jun-ya Kato, and Tomohiro Fujisaki in a working draft that
made proposals for this revision to adopt, with input from Pekka made proposals for this revision to adopt, with input from Pekka
Savola, Remi Denis-Courmont, Francois-Xavier Le Bail, and the 6man Savola, Remi Denis-Courmont, Francois-Xavier Le Bail, and the 6man
Working Group. Dmitry Anipko, Mark Andrews, and Ray Hunter also Working Group. Dmitry Anipko, Mark Andrews, Ray Hunter, and Wes
provided valuable feedback on this revision. George also provided valuable feedback on this revision.
Appendix B. Changes Since RFC 3484 Appendix B. Changes Since RFC 3484
Some changes were made to the default policy table that were deemed Some changes were made to the default policy table that were deemed
to be universally useful and cause no harm in every reasonable to be universally useful and cause no harm in every reasonable
network environment. In doing so, care was taken to use the same network environment. In doing so, care was taken to use the same
preference and label values as in RFC 3484 whenever possible, and for preference and label values as in RFC 3484 whenever possible, and for
new rows to use label values less likely to collide with values that new rows to use label values less likely to collide with values that
might already be in use in additional rows on some hosts. These might already be in use in additional rows on some hosts. These
changes are: changes are:
skipping to change at page 28, line 42 skipping to change at page 29, line 4
3. Added a row for site-local addresses (fec0::/10) in order to 3. Added a row for site-local addresses (fec0::/10) in order to
depreference them, for consistency with the example in depreference them, for consistency with the example in
Section 10.3, since they are deprecated [RFC3879]. Section 10.3, since they are deprecated [RFC3879].
4. Depreferenced 6to4 (2002::/32) below native IPv4 since 6to4 4. Depreferenced 6to4 (2002::/32) below native IPv4 since 6to4
connectivity is less reliable today (and is expected to be phased connectivity is less reliable today (and is expected to be phased
out over time, rather than becoming more reliable). It remains out over time, rather than becoming more reliable). It remains
above Teredo since 6to4 is more efficient in terms of connection above Teredo since 6to4 is more efficient in terms of connection
establishment time, bandwidth, and server load. establishment time, bandwidth, and server load.
5. Depreferenced IPv4-Compatible addresses (::/96) since they are 5. Depreferenced IPv4-Compatible addresses (::/96) since they are
now deprecated [RFC4291] and not in common use. now deprecated [RFC4291] and not in common use.
6. Added a row for 6bone testing addresses (3ffe::/16) in order to 6. Added a row for 6bone testing addresses (3ffe::/16) in order to
depreference them as they have also been phased out [RFC3701]. depreference them as they have also been phased out [RFC3701].
7. Added optional ability for an implementation to add automatic
rows to the table for site-specific ULA prefixes and site-
specific native 6to4 prefixes.
Similarly, some changes were made to the rules, as follows: Similarly, some changes were made to the rules, as follows:
1. Changed the definition of CommonPrefixLen() to only compare bits 1. Changed the definition of CommonPrefixLen() to only compare bits
up to the source address's prefix length. The previous up to the source address's prefix length. The previous
definition used the entire source address, rather than only its definition used the entire source address, rather than only its
prefix. As a result, when a source and destination addresses had prefix. As a result, when a source and destination addresses had
the same prefix, common bits in the interface ID would previously the same prefix, common bits in the interface ID would previously
result in overriding DNS load balancing [RFC1794] by forcing the result in overriding DNS load balancing [RFC1794] by forcing the
destination address with the most bits in common to be always destination address with the most bits in common to be always
skipping to change at page 29, line 20 skipping to change at page 29, line 33
advertised by the chosen next-hop for a given destination. This advertised by the chosen next-hop for a given destination. This
allows better connectivity in the presence of BCP 38 [RFC2827] allows better connectivity in the presence of BCP 38 [RFC2827]
ingress filtering and egress filtering. Previously, RFC 3484 had ingress filtering and egress filtering. Previously, RFC 3484 had
issues with multiple egress networks reached via the same issues with multiple egress networks reached via the same
interface, as discussed in [RFC5220]. interface, as discussed in [RFC5220].
3. Removed restriction against anycast addresses in the candidate 3. Removed restriction against anycast addresses in the candidate
set of source addresses, since the restriction against using IPv6 set of source addresses, since the restriction against using IPv6
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 3.2. Previously they were mapped to site-local scope.
local scope. However, experience has resulted in current However, experience has resulted in current implementations
implementations already using global scope instead. When they already using global scope instead. When they were mapped to
were mapped to site-local, Destination Address Selection Rule 2 site-local, Destination Address Selection Rule 2 (Prefer matching
(Prefer matching scope) would cause IPv6 to be preferred in scope) would cause IPv6 to be preferred in scenarios such as that
scenarios such as that described in Section 10.7. The change to described in Section 10.7. The change to global scope allows
global scope allows configurability via the prefix policy table. configurability via the prefix policy table.
5. Changed the default recommendation for Source Address Selection 5. Changed the default recommendation for Source Address Selection
Rule 7 to prefer temporary addresses rather than public Rule 7 to prefer temporary addresses rather than public
addresses, while providing an administrative override (in addresses, while providing an administrative override (in
addition to the application-specific override that was already addition to the application-specific override that was already
specified). This change was made because of the increasing specified). This change was made because of the increasing
importance of privacy considerations, as well as the fact that importance of privacy considerations, as well as the fact that
widely deployed implementations have preferred temporary widely deployed implementations have preferred temporary
addresses for many years without major application issues. addresses for many years without major application issues.
Finally, some editorial changes were made, including: Finally, some editorial changes were made, including:
 End of changes. 19 change blocks. 
50 lines changed or deleted 51 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/