draft-ietf-6man-rfc3484bis-03.txt   draft-ietf-6man-rfc3484bis-04.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: November 6, 2012 A. Matsumoto Expires: November 16, 2012 A. Matsumoto
NTT NTT
T. Chown T. Chown
University of Southampton University of Southampton
May 5, 2012 May 15, 2012
Default Address Selection for Internet Protocol version 6 (IPv6) Default Address Selection for Internet Protocol version 6 (IPv6)
draft-ietf-6man-rfc3484bis-03.txt draft-ietf-6man-rfc3484bis-04.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
administrators to provide policy that can override the default administrators to provide policy that can override the default
behavior. In dual stack implementations, the destination address behavior. In dual stack implementations, the destination address
selection algorithm can consider both IPv4 and IPv6 addresses - selection algorithm can consider both IPv4 and IPv6 addresses -
depending on the available source addresses, the algorithm might depending on the available source addresses, the algorithm might
prefer IPv6 addresses over IPv4 addresses, or vice-versa. prefer IPv6 addresses over IPv4 addresses, or vice-versa.
All IPv6 nodes, including both hosts and routers, must implement All IPv6 nodes, including both hosts and routers, must implement
default address selection as defined in this specification. default address selection as defined in this specification. This
document obsoletes RFC 3484.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 November 16, 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
skipping to change at page 3, line 33 skipping to change at page 3, line 33
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 . . . . . . . . . . . . . . . . 24 10.6. Configuring ULA Preference . . . . . . . . . . . . . . . . 24
10.7. Configuring 6to4 Preference . . . . . . . . . . . . . . . 25 10.7. Configuring 6to4 Preference . . . . . . . . . . . . . . . 25
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
11.1. Normative References . . . . . . . . . . . . . . . . . . . 25 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
11.2. Informative References . . . . . . . . . . . . . . . . . . 26 12.1. Normative References . . . . . . . . . . . . . . . . . . . 26
12.2. Informative References . . . . . . . . . . . . . . . . . . 26
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 28 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 28
Appendix B. Changes Since RFC 3484 . . . . . . . . . . . . . . . 28 Appendix B. Changes Since RFC 3484 . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 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].
skipping to change at page 20, line 42 skipping to change at page 20, line 42
2002::/16 30 2 2002::/16 30 2
2001::/32 5 5 2001::/32 5 5
fc00::/7 3 13 fc00::/7 3 13
::/96 1 3 ::/96 1 3
fec0::/10 1 11 fec0::/10 1 11
3ffe::/16 1 12 3ffe::/16 1 12
This change to the default policy table produces the following This change to the default policy table produces the following
behavior: behavior:
Candidate Source Addresses: 2001::2 or fe80::1 or 169.254.13.78 Candidate Source Addresses: 2001:db8::2 or fe80::1 or 169.254.13.78
Destination Address List: 2001::1 or 198.51.100.121 Destination Address List: 2001:db8::1 or 198.51.100.121
Unchanged Result: 2001::1 (src 2001::2) then 198.51.100.121 (src Unchanged Result: 2001:db8::1 (src 2001:db8::2) then 198.51.100.121
169.254.13.78) (prefer matching scope) (src 169.254.13.78) (prefer matching scope)
Candidate Source Addresses: fe80::1 or 198.51.100.117 Candidate Source Addresses: fe80::1 or 198.51.100.117
Destination Address List: 2001::1 or 198.51.100.121 Destination Address List: 2001:db8::1 or 198.51.100.121
Unchanged Result: 198.51.100.121 (src 198.51.100.117) then 2001::1 Unchanged Result: 198.51.100.121 (src 198.51.100.117) then
(src fe80::1) (prefer matching scope) 2001:db8::1 (src fe80::1) (prefer matching scope)
Candidate Source Addresses: 2001::2 or fe80::1 or 10.1.2.4 Candidate Source Addresses: 2001:db8::2 or fe80::1 or 10.1.2.4
Destination Address List: 2001::1 or 10.1.2.3 Destination Address List: 2001:db8::1 or 10.1.2.3
New Result: 10.1.2.3 (src 10.1.2.4) then 2001::1 (src 2001::2) New Result: 10.1.2.3 (src 10.1.2.4) then 2001:db8::1 (src
(prefer higher precedence) 2001:db8::2) (prefer higher precedence)
10.3.1. Handling Broken IPv6 10.3.1. Handling Broken IPv6
One problem in practice that has been recently observed occurs when a One problem in practice that has been recently observed occurs when a
host has IPv4 connectivity to the Internet, but has "broken" IPv6 host has IPv4 connectivity to the Internet, but has "broken" IPv6
connectivity to the Internet in that it has a global IPv6 address, connectivity to the Internet in that it has a global IPv6 address,
but is discconnected from the IPv6 Internet. Since the default but is discconnected from the IPv6 Internet. Since the default
policy table prefers IPv6, this can result in unwanted timeouts. policy table prefers IPv6, this can result in unwanted timeouts.
This can be solved by configuring the table to prefer IPv4 as shown This can be solved by configuring the table to prefer IPv4 as shown
skipping to change at page 21, line 47 skipping to change at page 21, line 47
2002::/16 30 2 2002::/16 30 2
2001::/32 5 5 2001::/32 5 5
fc00::/7 3 13 fc00::/7 3 13
::/96 1 3 ::/96 1 3
fec0::/10 1 11 fec0::/10 1 11
3ffe::/16 1 12 3ffe::/16 1 12
This change to the default policy table produces the following This change to the default policy table produces the following
behavior: behavior:
Candidate Source Addresses: 2001::2 or fe80::2 Candidate Source Addresses: 2001:db8::2 or fe80::2
Destination Address List: 2001::1 or fe80::1 Destination Address List: 2001:db8::1 or fe80::1
New Result: 2001::1 (src 2001::2) then fe80::1 (src fe80::2) (prefer New Result: 2001:db8::1 (src 2001:db8::2) then fe80::1 (src fe80::2)
higher precedence) (prefer higher precedence)
Candidate Source Addresses: 2001::2 (deprecated) or fe80::2 Candidate Source Addresses: 2001:db8::2 (deprecated) or fe80::2
Destination Address List: 2001::1 or fe80::1 Destination Address List: 2001:db8::1 or fe80::1
Unchanged Result: fe80::1 (src fe80::2) then 2001::1 (src 2001::2) Unchanged Result: fe80::1 (src fe80::2) then 2001:db8::1 (src 2001:
(avoid deprecated addresses) db8::2) (avoid deprecated addresses)
10.5. Configuring a Multi-Homed Site 10.5. Configuring a Multi-Homed Site
Consider a site A that has a business-critical relationship with Consider a site A that has a business-critical relationship with
another site B. To support their business needs, the two sites have another site B. To support their business needs, the two sites have
contracted for service with a special high-performance ISP. This is contracted for service with a special high-performance ISP. This is
in addition to the normal Internet connection that both sites have in addition to the normal Internet connection that both sites have
with different ISPs. The high-performance ISP is expensive and the with different ISPs. The high-performance ISP is expensive and the
two sites wish to use it only for their business-critical traffic two sites wish to use it only for their business-critical traffic
with each other. with each other.
Each site has two global prefixes, one from the high-performance ISP Each site has two global prefixes, one from the high-performance ISP
and one from their normal ISP. Site A has prefix 2001:aaaa:aaaa::/48 and one from their normal ISP. Site A has prefix 2001:db8:1aaa::/48
from the high-performance ISP and prefix 2007:0:aaaa::/48 from its from the high-performance ISP and prefix 2001:db8:70aa::/48 from its
normal ISP. Site B has prefix 2001:bbbb:bbbb::/48 from the high- normal ISP. Site B has prefix 2001:db8:1bbb::/48 from the high-
performance ISP and prefix 2007:0:bbbb::/48 from its normal ISP. All performance ISP and prefix 2001:db8:70bb::/48 from its normal ISP.
hosts in both sites register two addresses in the DNS. All hosts in both sites register two addresses in the DNS.
The routing within both sites directs most traffic to the egress to The routing within both sites directs most traffic to the egress to
the normal ISP, but the routing directs traffic sent to the other the normal ISP, but the routing directs traffic sent to the other
site's 2001 prefix to the egress to the high-performance ISP. To site's 2001 prefix to the egress to the high-performance ISP. To
prevent unintended use of their high-performance ISP connection, the prevent unintended use of their high-performance ISP connection, the
two sites implement ingress filtering to discard traffic entering two sites implement ingress filtering to discard traffic entering
from the high-performance ISP that is not from the other site. from the high-performance ISP that is not from the other site.
The default policy table and address selection rules produce the The default policy table and address selection rules produce the
following behavior: following behavior:
Candidate Source Addresses: 2001:aaaa:aaaa::a or 2007:0:aaaa::a or Candidate Source Addresses: 2001:db8:1aaa::a or 2001:db8:70aa::a or
fe80::a fe80::a
Destination Address List: 2001:bbbb:bbbb::b or 2007:0:bbbb::b Destination Address List: 2001:db8:1bbb::b or 2001:db8:70bb::b
Result: 2007:0:bbbb::b (src 2007:0:aaaa::a) then 2001:bbbb:bbbb::b Result: 2001:db8:70bb::b (src 2001:db8:70aa::a) then 2001:db8:1bbb::b
(src 2001:aaaa:aaaa::a) (longest matching prefix) (src 2001:db8:1aaa::a) (longest matching prefix)
In other words, when a host in site A initiates a connection to a In other words, when a host in site A initiates a connection to a
host in site B, the traffic does not take advantage of their host in site B, the traffic does not take advantage of their
connections to the high-performance ISP. This is not their desired connections to the high-performance ISP. This is not their desired
behavior. behavior.
Candidate Source Addresses: 2001:aaaa:aaaa::a or 2007:0:aaaa::a or Candidate Source Addresses: 2001:db8:1aaa::a or 2001:db8:70aa::a or
fe80::a fe80::a
Destination Address List: 2001:cccc:cccc::c or 2006:cccc:cccc::c Destination Address List: 2001:db8:1ccc::c or 2001:db8:6ccc::c
Result: 2001:cccc:cccc::c (src 2001:aaaa:aaaa::a) then 2006:cccc: Result: 2001:db8:1ccc::c (src 2001:db8:1aaa::a) then 2001:db8:6ccc::c
cccc::c (src 2007:0:aaaa::a) (longest matching prefix) (src 2001:db8:70aa::a) (longest matching prefix)
In other words, when a host in site A initiates a connection to a In other words, when a host in site A initiates a connection to a
host in some other site C, the reverse traffic may come back through host in some other site C, the reverse traffic may come back through
the high-performance ISP. Again, this is not their desired behavior. the high-performance ISP. Again, this is not their desired behavior.
This predicament demonstrates the limitations of the longest- This predicament demonstrates the limitations of the longest-
matching-prefix heuristic in multi-homed situations. matching-prefix heuristic in multi-homed situations.
However, the administrators of sites A and B can achieve their However, the administrators of sites A and B can achieve their
desired behavior via policy table configuration. For example, they desired behavior via policy table configuration. For example, they
can use the following policy table: can use the following policy table:
Prefix Precedence Label Prefix Precedence Label
::1/128 50 0 ::1/128 50 0
2001:aaaa:aaaa::/48 43 6 2001:db8:1aaa::/48 43 6
2001:bbbb:bbbb::/48 43 6 2001:db8:1bbb::/48 43 6
::/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
2001::/32 5 5 2001::/32 5 5
fc00::/7 3 13 fc00::/7 3 13
::/96 1 3 ::/96 1 3
fec0::/10 1 11 fec0::/10 1 11
3ffe::/16 1 12 3ffe::/16 1 12
This policy table produces the following behavior: This policy table produces the following behavior:
Candidate Source Addresses: 2001:aaaa:aaaa::a or 2007:0:aaaa::a or Candidate Source Addresses: 2001:db8:1aaa::a or 2001:db8:70aa::a or
fe80::a fe80::a
Destination Address List: 2001:bbbb:bbbb::b or 2007:0:bbbb::b Destination Address List: 2001:db8:1bbb::b or 2001:db8:70bb::b
New Result: 2001:bbbb:bbbb::b (src 2001:aaaa:aaaa::a) then 2007:0: New Result: 2001:db8:1bbb::b (src 2001:db8:1aaa::a) then 2001:db8:
bbbb::b (src 2007:0:aaaa::a) (prefer higher precedence) 70bb::b (src 2001:db8:70aa::a) (prefer higher precedence)
In other words, when a host in site A initiates a connection to a In other words, when a host in site A initiates a connection to a
host in site B, the traffic uses the high-performance ISP as desired. host in site B, the traffic uses the high-performance ISP as desired.
Candidate Source Addresses: 2001:aaaa:aaaa::a or 2007:0:aaaa::a or Candidate Source Addresses: 2001:db8:1aaa::a or 2001:db8:70aa::a or
fe80::a fe80::a
Destination Address List: 2001:cccc:cccc::c or 2006:cccc:cccc::c Destination Address List: 2001:db8:1ccc::c or 2001:db8:6ccc::c
New Result: 2006:cccc:cccc::c (src 2007:0:aaaa::a) then 2001:cccc: New Result: 2001:db8:6ccc::c (src 2001:db8:70aa::a) then 2001:db8:
cccc::c (src 2007:0:aaaa::a) (longest matching prefix) 1ccc::c (src 2001:db8:70aa::a) (longest matching prefix)
In other words, when a host in site A initiates a connection to a In other words, when a host in site A initiates a connection to a
host in some other site C, the traffic uses the normal ISP as host in some other site C, the traffic uses the normal ISP as
desired. desired.
10.6. Configuring ULA Preference 10.6. Configuring ULA Preference
RFC 5220 [RFC5220] sections 2.1.4, 2.2.2, and 2.2.3 describe address RFC 5220 [RFC5220] sections 2.1.4, 2.2.2, and 2.2.3 describe address
selection problems related to ULAs [RFC4193]. By default, global selection problems related to ULAs [RFC4193]. By default, global
IPv6 destinations are preferred over ULA destinations, since an IPv6 destinations are preferred over ULA destinations, since an
skipping to change at page 25, line 11 skipping to change at page 25, line 11
purely based on longest match: purely based on longest match:
Candidate Source Addresses: 2001:db8:1::1 or fd11:1111:1111:1::1 Candidate Source Addresses: 2001:db8:1::1 or fd11:1111:1111:1::1
Destination Address List: ff00:1 Destination Address List: ff00:1
Result: 2001:db8:1::1 (prefer matching label) Result: 2001:db8:1::1 (prefer matching label)
10.7. Configuring 6to4 Preference 10.7. Configuring 6to4 Preference
By default, NAT'ed IPv4 is preferred over 6to4-relayed connectivity: By default, NAT'ed IPv4 is preferred over 6to4-relayed connectivity:
Candidate Source Addresses: 2002:836b:4179::2 or 10.1.2.3 Candidate Source Addresses: 2002:c633:6401::2 or 10.1.2.3
Destination Address List: 2001:db8:1::1 or 203.0.113.1 Destination Address List: 2001:db8:1::1 or 203.0.113.1
Result: 203.0.113.1 (src 10.1.2.3) then 2001:db8:1::1 (src 2002:836b: Result: 203.0.113.1 (src 10.1.2.3) then 2001:db8:1::1 (src 2002:c633:
4179::2) (prefer matching label) 6401::2) (prefer matching label)
However, NAT'ed IPv4 is now also preferred over 6to4-to-6to4 However, NAT'ed IPv4 is now also preferred over 6to4-to-6to4
connectivity by default. Since a 6to4 prefix might be used natively connectivity by default. Since a 6to4 prefix might be used natively
within an organization, a site-specific policy entry can be used to within an organization, a site-specific policy entry can be used to
cause native IPv6 communication (using a 6to4 prefix) to be preferred cause native IPv6 communication (using a 6to4 prefix) to be preferred
over NAT'ed IPv4 as follows. over NAT'ed IPv4 as follows.
Prefix Precedence Label Prefix Precedence Label
::1/128 50 0 ::1/128 50 0
2002:836b:4179::/48 45 14 2002:c633:6401::/48 45 14
::/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
2001::/32 5 5 2001::/32 5 5
fc00::/7 3 13 fc00::/7 3 13
::/96 1 3 ::/96 1 3
fec0::/10 1 11 fec0::/10 1 11
3ffe::/16 1 12 3ffe::/16 1 12
Such a configuration would have the following effect: Such a configuration would have the following effect:
Candidate Source Addresses: 2002:836b:4179:1::1 or 10.1.2.3 Candidate Source Addresses: 2002:c633:6401:1::1 or 10.1.2.3
Destination Address List: 2002:836b:4179:2::2 or 203.0.113.1 Destination Address List: 2002:c633:6401:2::2 or 203.0.113.1
New Result: 2002:836b:4179:2::2 (src 2002:836b:4179:1::1) then New Result: 2002:c633:6401:2::2 (src 2002:c633:6401:1::1) then
203.0.113.1 (sec 10.1.2.3) (prefer higher precedence) 203.0.113.1 (sec 10.1.2.3) (prefer higher precedence)
Since 6to4 addresses are defined to have a /48 site prefix, an Since 6to4 addresses are defined to have a /48 site prefix, an
implementation might choose to add such a row automatically on a implementation might choose to add such a row automatically on a
machine with a native IPv6 address with a 6to4 prefix. machine with a native IPv6 address with a 6to4 prefix.
11. References 11. IANA Considerations
11.1. Normative References This document has no IANA actions.
12. References
12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
via IPv4 Clouds", RFC 3056, February 2001. via IPv4 Clouds", RFC 3056, February 2001.
[RFC3701] Fink, R. and R. Hinden, "6bone (IPv6 Testing Address
Allocation) Phaseout", RFC 3701, March 2004.
[RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local [RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local
Addresses", RFC 3879, September 2004. Addresses", RFC 3879, September 2004.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005. Addresses", RFC 4193, October 2005.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006. Architecture", RFC 4291, February 2006.
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
skipping to change at page 26, line 34 skipping to change at page 26, line 35
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007. Address Autoconfiguration", RFC 4862, September 2007.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, September 2007. IPv6", RFC 4941, September 2007.
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
Algorithm", RFC 6145, April 2011. Algorithm", RFC 6145, April 2011.
11.2. Informative References 12.2. Informative References
[I-D.ietf-6man-addr-select-opt] [I-D.ietf-6man-addr-select-opt]
Matsumoto, A., Fujisaki, T., Kato, J., and T. Chown, Matsumoto, A., Fujisaki, T., Kato, J., and T. Chown,
"Distributing Address Selection Policy using DHCPv6", "Distributing Address Selection Policy using DHCPv6",
draft-ietf-6man-addr-select-opt-03 (work in progress), draft-ietf-6man-addr-select-opt-03 (work in progress),
February 2012. February 2012.
[RFC1794] Brisco, T., "DNS Support for Load Balancing", RFC 1794, [RFC1794] Brisco, T., "DNS Support for Load Balancing", RFC 1794,
April 1995. April 1995.
skipping to change at page 27, line 9 skipping to change at page 27, line 10
BCP 5, RFC 1918, February 1996. BCP 5, RFC 1918, February 1996.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
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.
[RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W.
Stevens, "Basic Socket Interface Extensions for IPv6", Stevens, "Basic Socket Interface Extensions for IPv6",
RFC 3493, February 2003. RFC 3493, February 2003.
[RFC3701] Fink, R. and R. Hinden, "6bone (IPv6 Testing Address
Allocation) Phaseout", RFC 3701, March 2004.
[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
Configuration of IPv4 Link-Local Addresses", RFC 3927, Configuration of IPv4 Link-Local Addresses", RFC 3927,
May 2005. May 2005.
[RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and [RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and
B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, B. Zill, "IPv6 Scoped Address Architecture", RFC 4007,
March 2005. March 2005.
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
More-Specific Routes", RFC 4191, November 2005. More-Specific Routes", RFC 4191, November 2005.
skipping to change at page 27, line 44 skipping to change at page 27, line 48
[RFC5220] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, [RFC5220] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama,
"Problem Statement for Default Address Selection in Multi- "Problem Statement for Default Address Selection in Multi-
Prefix Environments: Operational Issues of RFC 3484 Prefix Environments: Operational Issues of RFC 3484
Default Rules", RFC 5220, July 2008. Default Rules", RFC 5220, July 2008.
[RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4
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.
Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
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 [RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and
M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address
Space", BCP 153, RFC 6598, April 2012. 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,
 End of changes. 29 change blocks. 
68 lines changed or deleted 68 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/