draft-ietf-v6ops-6to4-advisory-01.txt   draft-ietf-v6ops-6to4-advisory-02.txt 
V6OPS B. Carpenter V6OPS B. Carpenter
Internet-Draft Univ. of Auckland Internet-Draft Univ. of Auckland
Intended status: Informational April 26, 2011 Intended status: Informational June 22, 2011
Expires: October 28, 2011 Expires: December 24, 2011
Advisory Guidelines for 6to4 Deployment Advisory Guidelines for 6to4 Deployment
draft-ietf-v6ops-6to4-advisory-01 draft-ietf-v6ops-6to4-advisory-02
Abstract Abstract
This document provides advice to network operators about deployment This document provides advice to network operators about deployment
of the 6to4 technique for automatic tunneling of IPv6 over IPv4. It of the 6to4 technique for automatic tunneling of IPv6 over IPv4. It
is principally addressed to Internet Service Providers, including is principally addressed to Internet Service Providers, including
those that do not yet support IPv6, and to Content Providers. Some those that do not yet support IPv6, and to Content Providers. Some
advice to implementers is also included. The intention of the advice advice to implementers is also included. The intention of the advice
is to minimise both user dissatisfaction and help desk calls. is to minimise both user dissatisfaction and help desk calls.
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 28, 2011. This Internet-Draft will expire on December 24, 2011.
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 27 skipping to change at page 2, line 27
4.2.1. Anycast address availability . . . . . . . . . . . . . 11 4.2.1. Anycast address availability . . . . . . . . . . . . . 11
4.2.2. Protocol 41 . . . . . . . . . . . . . . . . . . . . . 11 4.2.2. Protocol 41 . . . . . . . . . . . . . . . . . . . . . 11
4.2.3. IPv4 prefix issues . . . . . . . . . . . . . . . . . . 12 4.2.3. IPv4 prefix issues . . . . . . . . . . . . . . . . . . 12
4.2.4. DNS issues . . . . . . . . . . . . . . . . . . . . . . 12 4.2.4. DNS issues . . . . . . . . . . . . . . . . . . . . . . 12
4.2.5. Rogue Router Advertisements . . . . . . . . . . . . . 12 4.2.5. Rogue Router Advertisements . . . . . . . . . . . . . 12
4.2.6. Planning for IPv6 deployment . . . . . . . . . . . . . 13 4.2.6. Planning for IPv6 deployment . . . . . . . . . . . . . 13
4.3. Consumer ISPs, and enterprise networks, that do 4.3. Consumer ISPs, and enterprise networks, that do
support IPv6 . . . . . . . . . . . . . . . . . . . . . . . 13 support IPv6 . . . . . . . . . . . . . . . . . . . . . . . 13
4.4. Transit ISPs and Internet Exchange Points . . . . . . . . 13 4.4. Transit ISPs and Internet Exchange Points . . . . . . . . 13
4.5. Content providers and their ISPs . . . . . . . . . . . . . 15 4.5. Content providers and their ISPs . . . . . . . . . . . . . 15
5. Tunnels Managed by ISPs . . . . . . . . . . . . . . . . . . . 16 5. Tunnels Managed by ISPs . . . . . . . . . . . . . . . . . . . 17
6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
9. Change log [RFC Editor: please remove] . . . . . . . . . . . . 18 9. Change log [RFC Editor: please remove] . . . . . . . . . . . . 18
10. Informative References . . . . . . . . . . . . . . . . . . . . 18 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20 10.1. Normative References . . . . . . . . . . . . . . . . . . . 18
10.2. Informative References . . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
A technique for automatic tunneling of IPv6 over IPv4, intended for A technique for automatic tunneling of IPv6 over IPv4, intended for
situations where a user may wish to access IPv6-based services via a situations where a user may wish to access IPv6-based services via a
network that does not support IPv6, was defined a number of years network that does not support IPv6, was defined a number of years
ago. It is known as 6to4 [RFC3056] [RFC3068] and is quite widely ago. It is known as 6to4 [RFC3056] [RFC3068] and is quite widely
deployed in end systems, especially desktop and laptop computers. deployed in end systems, especially desktop and laptop computers.
Also, 6to4 is supported in a number of popular models of CPE routers, Also, 6to4 is supported in a number of popular models of CPE routers,
some of which have it enabled by default, leading to quite widespread some of which have it enabled by default, leading to quite widespread
skipping to change at page 3, line 46 skipping to change at page 3, line 46
document does not discuss aspects that are mainly outside the scope document does not discuss aspects that are mainly outside the scope
of network operators: of network operators:
1. Operating system preferences between IPv4 and IPv6 when both 1. Operating system preferences between IPv4 and IPv6 when both
appear to be available [I-D.ietf-6man-rfc3484-revise]. appear to be available [I-D.ietf-6man-rfc3484-revise].
2. Ensuring that application software deals gracefully with 2. Ensuring that application software deals gracefully with
connectivity problems [I-D.wing-v6ops-happy-eyeballs-ipv6]. connectivity problems [I-D.wing-v6ops-happy-eyeballs-ipv6].
3. Some content providers have chosen to avoid the problem by hiding 3. Some content providers have chosen to avoid the problem by hiding
their IPv6 address except from customers of pre-qualified their IPv6 address except from customers of pre-qualified
networks [I-D.ietf-v6ops-v6-aaaa-whitelisting-implications]. networks [I-D.ietf-v6ops-v6-aaaa-whitelisting-implications].
A companion document [I-D.ietf-v6ops-6to4-to-historic] reclassifies A companion document [I-D.ietf-v6ops-6to4-to-historic] proposes to
6to4 as Historic. However, this will not remove the millions of reclassify 6to4 as Historic. However, this will not remove the
existing hosts and customer premises equipments that implement 6to4. millions of existing hosts and customer premises equipments that
Hence, the advice in this document remains necessary. implement 6to4. Hence, the advice in this document remains
necessary.
2. Principles of Operation 2. Principles of Operation
There are two variants of 6to4 which are referred to here as "Router There are two variants of 6to4 which are referred to here as "Router
6to4" and "Anycast 6to4". To understand Anycast 6to4, it is 6to4" and "Anycast 6to4". To understand Anycast 6to4, it is
necessary first to understand Router 6to4. necessary first to understand Router 6to4.
2.1. Router 6to4 2.1. Router 6to4
Router 6to4 is the original version, documented in [RFC3056]. The Router 6to4 is the original version, documented in [RFC3056]. The
skipping to change at page 4, line 36 skipping to change at page 4, line 36
routers can exchange IPv6 packets by encapsulating them in IPv4 using routers can exchange IPv6 packets by encapsulating them in IPv4 using
protocol number 41, and sending them to each other at their protocol number 41, and sending them to each other at their
respective IPv4 addresses. In fact, any number of 6to4 routers respective IPv4 addresses. In fact, any number of 6to4 routers
connected to the IPv4 network can directly exchange IPv6 packets in connected to the IPv4 network can directly exchange IPv6 packets in
this way. this way.
Some 6to4 routers are also configured as "Relay routers." They Some 6to4 routers are also configured as "Relay routers." They
behave as just described, but in addition they obtain native IPv6 behave as just described, but in addition they obtain native IPv6
connectivity with a normal IPv6 prefix. They announce an IPv6 route connectivity with a normal IPv6 prefix. They announce an IPv6 route
to 2002::/16. For example, assume that the 6to4 router at to 2002::/16. For example, assume that the 6to4 router at
190.0.2.187 is a relay router, whose address on the 6to4 side is 192.0.2.187 is a relay router, whose address on the 6to4 side is
2002:c000:2bb::1. Suppose that a host with the 6to4 address 2002: 2002:c000:2bb::1. Suppose that a host with the 6to4 address 2002:
c000:2aa::123 sends an IPv6 packet to a native IPv6 destination such c000:2aa::123 sends an IPv6 packet to a native IPv6 destination such
as 2001:db8:123:456::321. Assume that the 6to4 router at 192.0.2.170 as 2001:db8:123:456::321. Assume that the 6to4 router at 192.0.2.170
has its IPv6 default route set to 2002:c000:2bb::1, i.e. the relay. has its IPv6 default route set to 2002:c000:2bb::1, i.e. the relay.
The packet will be delivered to the relay, encapsulated in IPv4. The packet will be delivered to the relay, encapsulated in IPv4. The
After decapsulation, the relay will forward the packet into native relay will decapsulate the packet and forward it into native IPv6 for
IPv6 for delivery. When the remote host replies, the packet (source delivery. When the remote host replies, the packet (source 2001:db8:
2001:db8:123:456::321, destination 2002:c000:2aa::123) will find a 123:456::321, destination 2002:c000:2aa::123) will find a route to
route to 2002::/16 and hence be delivered to a 6to4 relay. The 2002::/16 and hence be delivered to a 6to4 relay. The process will
process will be reversed and the packet will be encapsulated and be reversed and the packet will be encapsulated and forwarded to the
forwarded to the 6to4 router at 192.0.2.170 for final delivery. 6to4 router at 192.0.2.170 for final delivery.
Note that this process does not require the same relay to be used in Note that this process does not require the same relay to be used in
both directions. The outbound packet will go to whichever relay is both directions. The outbound packet will go to whichever relay is
configured as the default IPv6 router at the source router, and the configured as the default IPv6 router at the source router, and the
return packet will go to whichever relay is announcing a route to return packet will go to whichever relay is announcing a route to
2002::/16 in the vicinity of the remote IPv6 host. 2002::/16 in the vicinity of the remote IPv6 host.
There are of course many further details in RFC 3056, most of which There are of course many further details in RFC 3056, most of which
are irrelevant to current operational problems. are irrelevant to current operational problems.
skipping to change at page 8, line 44 skipping to change at page 8, line 44
variable RTT. variable RTT.
5. PMTUD Failure: A common link MTU size observed on the Internet 5. PMTUD Failure: A common link MTU size observed on the Internet
today is 1500 bytes. However, when using 6to4 the path MTU is today is 1500 bytes. However, when using 6to4 the path MTU is
less than this due to the encapsulation header. Thus a 6to4 less than this due to the encapsulation header. Thus a 6to4
client will normally see a link MTU that is less than 1500, but a client will normally see a link MTU that is less than 1500, but a
native IPv6 server will see 1500. It has been observed that Path native IPv6 server will see 1500. It has been observed that Path
MTU Discovery does not always work, and this can lead to MTU Discovery does not always work, and this can lead to
connectivity failures. Even if a TCP SYN/ACK exchange works, TCP connectivity failures. Even if a TCP SYN/ACK exchange works, TCP
packets with full size payloads may simply be lost. This problem packets with full size payloads may simply be lost. This problem
is apparently exacerbated in some cases by failure of the TCP MSS is apparently exacerbated in some cases by failure of the TCP MSS
negotiation mechanism. These failures are disconcerting even to negotiation mechanism [RFC2923]. These failures are
an informed user, since a standard 'ping' from the client to the disconcerting even to an informed user, since a standard 'ping'
server will succeed, because it generates small packets, and the from the client to the server will succeed, because it generates
successful SYN/ACK exchange can be traced. Also, the failure may small packets, and the successful SYN/ACK exchange can be traced.
occur on some paths but not others, so a user may be able to Also, the failure may occur on some paths but not others, so a
fetch web pages from one site, but only ping another. user may be able to fetch web pages from one site, but only ping
another.
Additionally, there is a problem if 6to4 is enabled on a router Additionally, there is a problem if 6to4 is enabled on a router
and it advertises the resulting prefix on a LAN, but does not and it advertises the resulting prefix on a LAN, but does not
also advertise a smaller MTU; in this case TCP MSS negotiation also advertise a smaller MTU; in this case TCP MSS negotiation
will definitely fail. will definitely fail.
6. Reverse DNS Failure: Typically a 6to4-addressed host will not 6. Reverse DNS Failure: Typically a 6to4-addressed host will not
have a reverse DNS delegation. If reverse DNS is used as a have a reverse DNS delegation. If reverse DNS is used as a
pseudo-security check, it will fail. pseudo-security check, it will fail.
7. Bogus Address Failure: By design, 6to4 does not work and will not 7. Bogus Address Failure: By design, 6to4 does not work and will not
activate itself if the available V4ADDR is a private address activate itself if the available V4ADDR is a private address
[RFC1918]. However it will also not work if the available V4ADDR [RFC1918]. However it will also not work if the available V4ADDR
is a "bogon", i.e. a global address that is being used by the is a "bogon", i.e. a global address that is being used by the
operator as a private address. A common case of this is a legacy operator as a private address. A common case of this is a legacy
wireless network using 1.1.1.0/24 as if it was a private address. wireless network using 1.1.1.0/24 as if it was a private address.
In this case, 6to4 will assume it is connected to the global In this case, 6to4 will assume it is connected to the global
Internet, but there is certainly no working return path. Internet, but there is certainly no working return path.
This failure mode will also occur if an ISP is operating a This failure mode will also occur if an ISP is operating a
Carrier Grade NAT between its customers and the Internet, and is Carrier Grade NAT [I-D.ietf-behave-lsn-requirements] between its
using global public address space as if it were private space to customers and the Internet, and is using global public address
do so. space as if it were private space to do so.
8. Faulty 6to4 Implementations: It has been reported that some 6to4 8. Faulty 6to4 Implementations: It has been reported that some 6to4
implementations attempt to activate themselves even when the implementations attempt to activate themselves even when the
available IPv4 address is an RFC 1918 address. This is in direct available IPv4 address is an RFC 1918 address. This is in direct
contradiction to RFC 3056, and will produce exactly the same contradiction to RFC 3056, and will produce exactly the same
failure mode as Bogus Address Failure. It is of course outside failure mode as Bogus Address Failure. It is of course outside
the ISP's control. the ISP's control.
9. Difficult Fault Diagnosis: The existence of all the above failure 9. Difficult Fault Diagnosis: The existence of all the above failure
modes creates a problem of its own: very difficult fault modes creates a problem of its own: very difficult fault
diagnosis, especially if the only symptom reported by a user is diagnosis, especially if the only symptom reported by a user is
slow access to web pages, caused by a long timeout before slow access to web pages, caused by a long timeout before
skipping to change at page 10, line 18 skipping to change at page 10, line 19
Internet connection. Issuing RA messages on the upstream link will Internet connection. Issuing RA messages on the upstream link will
perturb any other IPv6 hosts on that link. If 6to4 routing is perturb any other IPv6 hosts on that link. If 6to4 routing is
enabled by default on a device that exhibits this faulty behaviour, enabled by default on a device that exhibits this faulty behaviour,
the resulting rogue RA messages will indeed convey a 2002::/16 the resulting rogue RA messages will indeed convey a 2002::/16
prefix. prefix.
4. Advisory Guidelines 4. Advisory Guidelines
There are several types of operator involved, willingly or There are several types of operator involved, willingly or
unwillingly, in the Anycast 6to4 scenario and they will all suffer if unwillingly, in the Anycast 6to4 scenario and they will all suffer if
things work badly. There is a clear incentive for each of them to things work badly. To avoid operational problems and customer
take appropriate action, as described below. dissatisfaction, there is a clear incentive for each of them to take
appropriate action, as described below.
This document avoids formal normative language, because it is highly This document avoids formal normative language, because it is highly
unlikely that the guidelines apply universally. Each operator will unlikely that the guidelines apply universally. Each operator will
make its own decisions about which of the following guidelines are make its own decisions about which of the following guidelines are
useful in its specific scenario. useful in its specific scenario.
4.1. Vendor Issues 4.1. Vendor Issues
Although this document is aimed principally at operators, there are Although this document is aimed principally at operators, there are
some steps that implementers and vendors of 6to4 should take. some steps that implementers and vendors of 6to4 should take.
skipping to change at page 15, line 15 skipping to change at page 15, line 15
8. The relay must of course be connected directly to global IPv4 8. The relay must of course be connected directly to global IPv4
space, with no NAT. space, with no NAT.
Operators in this category should make sure that no routers are Operators in this category should make sure that no routers are
unintentionally or by default set up as active 6to4 relays. unintentionally or by default set up as active 6to4 relays.
Unmanaged 6to4 relays will be a source of problems. Unmanaged 6to4 relays will be a source of problems.
4.5. Content providers and their ISPs 4.5. Content providers and their ISPs
We assume that content providers and their ISPs have IPv6 We assume that content providers and their ISPs have IPv6
connectivity, and that content servers are dual stacked. There is a connectivity, and that the servers are dual stacked. The following
need to avoid the situation where a client host, configured with applies to content servers as such, but equally to web hosting
servers, servers that form part of a content distribution network,
load balancers in front of a server farm, and HTTP caches. There is
a need to avoid the situation where a client host, configured with
Anycast 6to4, succeeds in sending an IPv6 packet to the server, but Anycast 6to4, succeeds in sending an IPv6 packet to the server, but
the 6to4 return path fails as described above. To avoid this, there the 6to4 return path fails as described above. To avoid this, there
must be a locally positioned 6to4 relay. Large content providers are must be a locally positioned 6to4 relay. Large content providers are
advised to operate their own relays, and ISPs should do so in any advised to operate their own relays, and ISPs should do so in any
case. There must be a 2002::/16 route from the content server to the case. There must be a 2002::/16 route from the content server to the
relay. As noted in the previous section, the corresponding route relay. As noted in the previous section, the corresponding route
advertisement must be carefully scoped, since any traffic that advertisement must be carefully scoped, since any traffic that
arrives for 2002::/16 must be relayed. arrives for 2002::/16 must be relayed.
Such a relay may be dedicated entirely to return traffic, in which Such a relay may be dedicated entirely to return traffic, in which
skipping to change at page 16, line 12 skipping to change at page 16, line 16
The relay must have adequate performance, and since load prediction The relay must have adequate performance, and since load prediction
is extremely hard, it must be possible to scale it up or, perhaps is extremely hard, it must be possible to scale it up or, perhaps
better, to replicate it as needed. Since the relay process is better, to replicate it as needed. Since the relay process is
stateless, any reasonable method of load sharing between multiple stateless, any reasonable method of load sharing between multiple
relays will do. relays will do.
The relay must of course be connected directly to global IPv4 space, The relay must of course be connected directly to global IPv4 space,
with no NAT. with no NAT.
An option for content servers is to embed the relay function directly An option is to embed the relay function directly in the content
in the content server. This is in fact trivial, since it can be server or first hop router. This is straightforward, since it can be
achieved by enabling a local 6to4 interface on the server, and using achieved by enabling a local 6to4 interface, and using it to route
it to route 2002::/16 for outbound packets. (This might not allow 2002::/16 for outbound packets. (This might not allow use of
use of 192.88.99.1 as the source address.) Further details are to be 192.88.99.1 as the source address.) Further details are to be found
found at [Huston-b]. However, in this case Protocol 41 must be at [Huston-b]. However, in this case Protocol 41 must be allowed by
allowed by the firewalls. the firewalls.
Content providers who do embed the relay function in this way could, Content providers who do embed the relay function in this way could,
in theory, accept inbound 6to4 traffic as well. This is highly in theory, accept inbound 6to4 traffic as well. This is highly
unadvisable since, according the the rules of 6to4, they would then unadvisable since, according the the rules of 6to4, they would then
have to relay traffic for other IPv6 destinations too. So they have to relay traffic for other IPv6 destinations too. So they
should not be reachable via 192.88.99.1. Also, they should certainly should not be reachable via 192.88.99.1. Also, they should certainly
not create an AAAA record for their 6to4 address - their inbound IPv6 not create an AAAA record for their 6to4 address - their inbound IPv6
access should be native, and advertising a 6to4 address might well access should be native, and advertising a 6to4 address might well
lead to uRPF ingress filtering problems. lead to unicast reverse path forwarding (uRPF) [RFC3704] ingress
filtering problems.
To avoid the path MTU problem described above, content servers should To avoid the path MTU problem described above, content servers should
also set their IPv6 MTU to a safe value. From experience, 1280 bytes also set their IPv6 MTU to a safe value. From experience, 1280 bytes
(the minimum allowed for IPv6) is recommended; again see [Huston-b]. (the minimum allowed for IPv6) is recommended; again see [Huston-b].
Of course, ICMPv6 "Packet Too Big" must not be blocked or rate- Of course, ICMPv6 "Packet Too Big" must not be blocked or rate-
limited anywhere [RFC4890]. limited anywhere [RFC4890].
Reverse DNS delegations are highly unlikely to exist for 6to4 Reverse DNS delegations are highly unlikely to exist for 6to4
clients, and are by no means universal for other IPv6 clients. clients, and are by no means universal for other IPv6 clients.
Content providers (and in fact all service providers) should not rely Content providers (and in fact all service providers) should not rely
skipping to change at page 17, line 39 skipping to change at page 17, line 47
7. IANA Considerations 7. IANA Considerations
This document makes no request of the IANA. This document makes no request of the IANA.
8. Acknowledgements 8. Acknowledgements
Useful comments and contributions were made by Emile Aben, Mikael Useful comments and contributions were made by Emile Aben, Mikael
Abrahamsson, Tore Anderson, Hermin Anggawijaya, Jack Bates, Cameron Abrahamsson, Tore Anderson, Hermin Anggawijaya, Jack Bates, Cameron
Byrne, Tim Chown, Remi Despres, Jason Fesler, Wes George, Philip Byrne, Tim Chown, Remi Despres, Jason Fesler, Wes George, Philip
Homburg, Geoff Huston, Eric Kline, Victor Kuarsingh, Martin Levy, Homburg, Ray Hunter, Geoff Huston, Eric Kline, Victor Kuarsingh,
David Malone, Martin Millnert, Keith Moore, Gabi Nakibly, Michael Martin Levy, David Malone, Alexey Melnikov, Martin Millnert, Keith
Newbery, Pekka Savola, Mark Smith, Nathan Ward, James Woodyatt, and Moore, Gabi Nakibly, Michael Newbery, Phil Pennock, Pekka Savola,
others. Mark Smith, Nathan Ward, James Woodyatt, and others.
This document was produced using the xml2rfc tool [RFC2629]. This document was produced using the xml2rfc tool [RFC2629].
9. Change log [RFC Editor: please remove] 9. Change log [RFC Editor: please remove]
draft-ietf-v6ops-6to4-advisory-02: Updated with IETF Last Call and
IESG comments, 2011-06-22
draft-ietf-v6ops-6to4-advisory-01: Updated with WG Last Call draft-ietf-v6ops-6to4-advisory-01: Updated with WG Last Call
comments, 2011-04-26 comments, 2011-04-26
draft-ietf-v6ops-6to4-advisory-00: WG draft, updated with WG draft-ietf-v6ops-6to4-advisory-00: WG draft, updated with WG
comments, 2011-03-31 comments, 2011-03-31
draft-carpenter-v6ops-6to4-teredo-advisory-03: updated with draft-carpenter-v6ops-6to4-teredo-advisory-03: updated with
additional security reference and additional comments, 2011-03-12 additional security reference and additional comments, 2011-03-12
draft-carpenter-v6ops-6to4-teredo-advisory-02: updated after further draft-carpenter-v6ops-6to4-teredo-advisory-02: updated after further
comments, removed references to Teredo, 2011-02-24 comments, removed references to Teredo, 2011-02-24
draft-carpenter-v6ops-6to4-teredo-advisory-01: updated after WG draft-carpenter-v6ops-6to4-teredo-advisory-01: updated after WG
discussion, 2011-02-10 discussion, 2011-02-10
draft-carpenter-v6ops-6to4-teredo-advisory-00: original version, draft-carpenter-v6ops-6to4-teredo-advisory-00: original version,
2011-02-03 2011-02-03
10. Informative References 10. References
10.1. Normative References
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
via IPv4 Clouds", RFC 3056, February 2001.
[RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers",
RFC 3068, June 2001.
10.2. Informative References
[Aben] Aben, E., "6to4 - How Bad is it Really?", 2010, <https:// [Aben] Aben, E., "6to4 - How Bad is it Really?", 2010, <https://
labs.ripe.net/Members/emileaben/ labs.ripe.net/Members/emileaben/
6to4-how-bad-is-it-really>. 6to4-how-bad-is-it-really>.
[Anderson] [Anderson]
Anderson, T., "IPv6 dual-stack client loss in Norway", Anderson, T., "IPv6 dual-stack client loss in Norway",
2010, <http://www.fud.no/ipv6/>. 2010, <http://www.fud.no/ipv6/>.
[Huston-a] [Huston-a]
skipping to change at page 18, line 47 skipping to change at page 19, line 17
<http://www.potaroo.net/ispcol/2010-12/6to4fail.html>. <http://www.potaroo.net/ispcol/2010-12/6to4fail.html>.
[Huston-b] [Huston-b]
Huston, G., "Two Simple Hints for Dual Stack Servers", Huston, G., "Two Simple Hints for Dual Stack Servers",
2010, 2010,
<http://www.potaroo.net/ispcol/2010-05/v6hints.html>. <http://www.potaroo.net/ispcol/2010-05/v6hints.html>.
[I-D.ietf-6man-rfc3484-revise] [I-D.ietf-6man-rfc3484-revise]
Matsumoto, A., Kato, J., and T. Fujisaki, "Update to RFC Matsumoto, A., Kato, J., and T. Fujisaki, "Update to RFC
3484 Default Address Selection for IPv6", 3484 Default Address Selection for IPv6",
draft-ietf-6man-rfc3484-revise-02 (work in progress), draft-ietf-6man-rfc3484-revise-03 (work in progress),
March 2011. June 2011.
[I-D.ietf-behave-lsn-requirements]
Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A.,
and H. Ashida, "Common requirements for IP address sharing
schemes", draft-ietf-behave-lsn-requirements-01 (work in
progress), March 2011.
[I-D.ietf-intarea-shared-addressing-issues] [I-D.ietf-intarea-shared-addressing-issues]
Ford, M., Boucadair, M., Durand, A., Levis, P., and P. Ford, M., Boucadair, M., Durand, A., Levis, P., and P.
Roberts, "Issues with IP Address Sharing", Roberts, "Issues with IP Address Sharing",
draft-ietf-intarea-shared-addressing-issues-05 (work in draft-ietf-intarea-shared-addressing-issues-05 (work in
progress), March 2011. progress), March 2011.
[I-D.ietf-v6ops-6to4-to-historic] [I-D.ietf-v6ops-6to4-to-historic]
Troan, O., "Request to move Connection of IPv6 Domains via Troan, O., "Request to move Connection of IPv6 Domains via
IPv4 Clouds (6to4) to Historic status", IPv4 Clouds (6to4) to Historic status",
draft-ietf-v6ops-6to4-to-historic-00 (work in progress), draft-ietf-v6ops-6to4-to-historic-04 (work in progress),
April 2011. June 2011.
[I-D.ietf-v6ops-tunnel-loops] [I-D.ietf-v6ops-tunnel-loops]
Nakibly, G. and F. Templin, "Routing Loop Attack using Nakibly, G. and F. Templin, "Routing Loop Attack using
IPv6 Automatic Tunnels: Problem Statement and Proposed IPv6 Automatic Tunnels: Problem Statement and Proposed
Mitigations", draft-ietf-v6ops-tunnel-loops-06 (work in Mitigations", draft-ietf-v6ops-tunnel-loops-07 (work in
progress), March 2011. progress), May 2011.
[I-D.ietf-v6ops-v6-aaaa-whitelisting-implications] [I-D.ietf-v6ops-v6-aaaa-whitelisting-implications]
Livingood, J., "IPv6 AAAA DNS Whitelisting Implications", Livingood, J., "IPv6 AAAA DNS Whitelisting Implications",
draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 draft-ietf-v6ops-v6-aaaa-whitelisting-implications-06
(work in progress), February 2011. (work in progress), June 2011.
[I-D.wing-v6ops-happy-eyeballs-ipv6] [I-D.wing-v6ops-happy-eyeballs-ipv6]
Wing, D. and A. Yourtchenko, "Happy Eyeballs: Trending Wing, D. and A. Yourtchenko, "Happy Eyeballs: Trending
Towards Success with Dual-Stack Hosts", Towards Success with Dual-Stack Hosts",
draft-wing-v6ops-happy-eyeballs-ipv6-01 (work in draft-wing-v6ops-happy-eyeballs-ipv6-01 (work in
progress), October 2010. progress), October 2010.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets", E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996. BCP 5, RFC 1918, February 1996.
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999. June 1999.
[RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery",
RFC 2923, September 2000.
[RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 [RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6
Tunnel Broker", RFC 3053, January 2001. Tunnel Broker", RFC 3053, January 2001.
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
via IPv4 Clouds", RFC 3056, February 2001. Networks", BCP 84, RFC 3704, March 2004.
[RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers",
RFC 3068, June 2001.
[RFC3964] Savola, P. and C. Patel, "Security Considerations for [RFC3964] Savola, P. and C. Patel, "Security Considerations for
6to4", RFC 3964, December 2004. 6to4", RFC 3964, December 2004.
[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.
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
for IPv6 Hosts and Routers", RFC 4213, October 2005. for IPv6 Hosts and Routers", RFC 4213, October 2005.
 End of changes. 24 change blocks. 
59 lines changed or deleted 86 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/