draft-ietf-v6ops-6to4-advisory-00.txt   draft-ietf-v6ops-6to4-advisory-01.txt 
V6OPS B. Carpenter V6OPS B. Carpenter
Internet-Draft Univ. of Auckland Internet-Draft Univ. of Auckland
Intended status: Informational March 31, 2011 Intended status: Informational April 26, 2011
Expires: October 2, 2011 Expires: October 28, 2011
Advisory Guidelines for 6to4 Deployment Advisory Guidelines for 6to4 Deployment
draft-ietf-v6ops-6to4-advisory-00 draft-ietf-v6ops-6to4-advisory-01
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. The those that do not yet support IPv6, and to Content Providers. Some
intention of the advice is to minimise both user dissatisfaction and advice to implementers is also included. The intention of the advice
help desk calls. is to minimise both user dissatisfaction and help desk calls.
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 October 2, 2011. This Internet-Draft will expire on October 28, 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 13 skipping to change at page 2, line 13
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.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Principles of Operation . . . . . . . . . . . . . . . . . . . 4 2. Principles of Operation . . . . . . . . . . . . . . . . . . . 4
2.1. Router 6to4 . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Router 6to4 . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Anycast 6to4 . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Anycast 6to4 . . . . . . . . . . . . . . . . . . . . . . . 5
3. Problems Observed . . . . . . . . . . . . . . . . . . . . . . 5 3. Problems Observed . . . . . . . . . . . . . . . . . . . . . . 5
4. Advisory Guidelines . . . . . . . . . . . . . . . . . . . . . 9 4. Advisory Guidelines . . . . . . . . . . . . . . . . . . . . . 10
4.1. Vendor Issues . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Vendor Issues . . . . . . . . . . . . . . . . . . . . . . 10
4.2. Consumer ISPs, and enterprise networks, that do not 4.2. Consumer ISPs, and enterprise networks, that do not
support IPv6 in any way . . . . . . . . . . . . . . . . . 10 support IPv6 in any way . . . . . . . . . . . . . . . . . 11
4.2.1. 6to4 as the first step to IPv6 operation . . . . . . . 12 4.2.1. Anycast address availability . . . . . . . . . . . . . 11
4.2.2. Protocol 41 . . . . . . . . . . . . . . . . . . . . . 11
4.2.3. IPv4 prefix issues . . . . . . . . . . . . . . . . . . 12
4.2.4. DNS issues . . . . . . . . . . . . . . . . . . . . . . 12
4.2.5. Rogue Router Advertisements . . . . . . . . . . . . . 12
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 . . . . . . . . . . . . . . . . . . . . . . . 12 support IPv6 . . . . . . . . . . . . . . . . . . . . . . . 13
4.4. Transit ISPs and Internet Exchange Points . . . . . . . . 12 4.4. Transit ISPs and Internet Exchange Points . . . . . . . . 13
4.5. Content providers and their ISPs . . . . . . . . . . . . . 13 4.5. Content providers and their ISPs . . . . . . . . . . . . . 15
5. Tunnels Managed by ISPs . . . . . . . . . . . . . . . . . . . 15 5. Tunnels Managed by ISPs . . . . . . . . . . . . . . . . . . . 16
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
9. Change log . . . . . . . . . . . . . . . . . . . . . . . . . . 16 9. Change log [RFC Editor: please remove] . . . . . . . . . . . . 18
10. Informative References . . . . . . . . . . . . . . . . . . . . 17 10. Informative References . . . . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20
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
unintentional deployment by end users. unintentional deployment by end users.
Unfortunately, experience shows that the method has some problems in Unfortunately, experience shows that the method has some problems in
current deployments that can lead to connectivity failures. These current deployments that can lead to connectivity failures. These
failures either cause long retry delays or complete failures for failures either cause long retry delays or complete failures for
users trying to connect to services. In many cases, the user may be users trying to connect to services. In many cases, the user may be
quite unaware that 6to4 is in use, and when the user contacts a help quite unaware that 6to4 is in use, and when the user contacts a help
desk, in all probability the help desk is unable to correctly desk, in all probability the help desk is unable to correctly
diagnose the problem. Anecdotally, many help desks simply advise diagnose the problem. Anecdotally, many help desks simply advise
users to disable IPv6, thus defeating the whole purpose of the users to disable IPv6, thus defeating the whole purpose of the
mechanism, which was to encourage early adoption of IPv6. mechanism, which was to encourage early adoption of IPv6.
There is additional discussion of operational issues in The main goal of the present document is to offer advice to network
[I-D.vandevelde-v6ops-harmful-tunnels]. The main goal of the present operators on how to deal with this situation more constructively than
document is to offer advice to network operators on how to deal with by disabling 6to4. It briefly describes the principle of operation,
this situation more constructively than by disabling 6to4. It then describes the problems observed, and finally offers specific
briefly describes the principle of operation, then describes the advice on the available methods of avoiding the problems. Note that
problems observed, and finally offers specific advice on the some of this advice applies to ISPs that do not yet support IPv6,
available methods of avoiding the problems. Note that some of this since their customers and help desks are significantly affected in
advice applies to ISPs that do not yet support IPv6, since their any case.
customers and help desks are significantly affected in any case.
Other advice applies to content providers.
We do not discuss here details of this situation that are mainly Other advice applies to content providers and implementers, but this
outside the scope of network operators: document does not discuss aspects that are mainly outside the scope
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 [insert reference to successor of A companion document [I-D.ietf-v6ops-6to4-to-historic] reclassifies
draft-troan-v6ops-6to4-to-historic] reclassifies 6to4 as Historic. 6to4 as Historic. However, this will not remove the millions of
However, this will not remove the millions of existing hosts and existing hosts and customer premises equipments that implement 6to4.
customer premises equipments that implement 6to4. Hence, the advice Hence, the advice in this document remains necessary.
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
model assumes that a user site operates native IPv6, but that its ISP model assumes that a user site operates native IPv6, but that its ISP
provides no IPv6 service. The site border router acts as a 6to4 provides no IPv6 service. The site border router acts as a 6to4
router. If its external global 32-bit IPv4 address is V4ADDR, the router. If its external global 32-bit IPv4 address is V4ADDR, the
site automatically inherits the IPv6 prefix 2002:V4ADDR::/48. (The site automatically inherits the IPv6 prefix 2002:V4ADDR::/48. (The
explanation in RFC 3056 is somewhat confusing, as it refers to the explanation in RFC 3056 is somewhat confusing, as it refers to the
obsolete "Top Level Aggregator" terminology.) The prefix 2002: obsolete "Top Level Aggregator" terminology.) The prefix 2002:
V4ADDR::/48 will be used and delegated for IPv6 service within the V4ADDR::/48 will be used and delegated for IPv6 service within the
user site. user site.
Consider two such site border routers, with global IPv4 addresses Consider two such site border routers, with global IPv4 addresses
192.0.2.170 and 190.0.2.187, and therefore inheriting the IPv6 192.0.2.170 and 192.0.2.187, and therefore inheriting the IPv6
prefixes 2002:c000:2aa::/48 and 2002:c000:2bb::/48 respectively. The prefixes 2002:c000:2aa::/48 and 2002:c000:2bb::/48 respectively. The
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
skipping to change at page 5, line 12 skipping to change at page 5, line 12
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.
2.2. Anycast 6to4 2.2. Anycast 6to4
Router 6to4 assumes that 6to4 routers and relays will be managed and Router 6to4 assumes that 6to4 routers and relays will be managed and
configured cooperatively. In particular, 6to4 sites need to find a configured cooperatively. In particular, 6to4 sites need to
relay router willing to carry their outbound traffic, which becomes configure a relay router willing to carry their outbound traffic,
their default IPv6 router (except for 2002::/16). The objective of which becomes their default IPv6 router (except for 2002::/16). The
the anycast variant, defined in [RFC3068], is to avoid any need for objective of the anycast variant, defined in [RFC3068], is to avoid
such configuration. The intention was to make the solution available any need for such configuration. The intention was to make the
for small or domestic users, even those with a single host or simple solution available for small or domestic users, even those with a
home gateway rather than a border router. This is achieved quite single host or simple home gateway rather than a border router. This
simply, by defining 192.88.99.1 as the default IPv4 address for a is achieved quite simply, by defining 192.88.99.1 as the default IPv4
6to4 relay, and therefore 2002:c058:6301:: as the default IPv6 router address for a 6to4 relay, and therefore 2002:c058:6301:: as the
address for a 6to4 site. default IPv6 router address for a 6to4 site.
Since Anycast 6to4 implies a default configuration for the user site, Since Anycast 6to4 implies a default configuration for the user site,
it does not require any particular user action. It does require an it does not require any particular user action. It does require an
IPv4 anycast route to be in place to a relay at 192.88.99.1. As with IPv4 anycast route to be in place to a relay at 192.88.99.1. As with
Router 6to4, there is no requirement that the return path goes Router 6to4, there is no requirement that the return path goes
through the same relay. through the same relay.
3. Problems Observed 3. Problems Observed
It should be noted that Router 6to4 was not designed to be an It should be noted that Router 6to4 was not designed to be an
unmanaged solution. Quite the contrary: RFC 3056 contains a number unmanaged solution. Quite the contrary: RFC 3056 contains a number
of operational recommendations intended to avoid routing issues. In of operational recommendations intended to avoid routing issues. In
practice, there are few if any deployments of Router 6to4 following practice, there are few if any deployments of Router 6to4 following
these recommendations. Mostly, Anycast 6to4 has been deployed. In these recommendations. Mostly, Anycast 6to4 has been deployed. In
this case, the user site (either a single host or a small broaband this case, the user site (either a single host or a small broadband
gateway) discovers that it doesn't have native IPv6 connectivity, but gateway) discovers that it doesn't have native IPv6 connectivity, but
that it does have a global IPv4 address and can resolve AAAA queries, that it does have a global IPv4 address and can resolve AAAA queries,
and therefore assumes that it can send 6to4 packets to 192.88.99.1. and therefore assumes that it can send 6to4 packets to 192.88.99.1.
Empirically, 6to4 appears to suffer from a significant level of Empirically, 6to4 appears to suffer from a significant level of
connection failure; see connection failure; see [Aben] and [Huston-a]. In experiments
<https://labs.ripe.net/Members/emileaben/6to4-how-bad-is-it-really> conducted on a number of dual stack web servers, the TCP connection
and <http://www.potaroo.net/ispcol/2010-12/6to4fail.html>. In failure rate has been measured. In these experiments, the client's
experiments conducted on a number of dual stack web servers, the TCP connection attempt to a server was considered to have failed when the
connection failure rate has been measured. In these experiments, the server received a TCP SYN packet and sent a SYN/ACK packet in
client's connection attempt to a server was considered to have failed response, but received no ACK packet to complete the initial TCP
when the server received a TCP SYN packet and sent a SYN/ACK packet
in response, but received no ACK packet to complete the initial TCP
3-way handshake. The experiment conducted by Aben recorded a failure 3-way handshake. The experiment conducted by Aben recorded a failure
rate of between 9% and 20% of all 6to4 connection attempts. The rate of between 9% and 20% of all 6to4 connection attempts. The
experiment conducted by Huston has recorded a failure rate of between experiment conducted by Huston has recorded a failure rate of between
9% and 19% of all 6to4 clients. In this latter experiment it was 9% and 19% of all 6to4 clients. In this latter experiment it was
further noted that between 65% to 80% of all 6to4 clients who failed further noted that between 65% to 80% of all 6to4 clients who failed
to connect using 6to4 were able to make a successful connection using to connect using 6to4 were able to make a successful connection using
IPv4, while the remainder did not make any form of IPv4 connection IPv4, while the remainder did not make any form of IPv4 connection
attempt, successful or otherwise, using the mapped IPv4 address as a attempt, successful or otherwise, using the mapped IPv4 address as a
source address. No connection attempts were recorded by the server source address. No connection attempts using embedded RFC 1918 IPv4
using embedded RFC1918 IPv4 addresses. addresses were recorded by the server.
There have been several possible reasons offered for this form of There have been several possible reasons offered for this form of
6to4 connection failure. One is the use of private IPv4 addresses 6to4 connection failure. One is the use of private IPv4 addresses
embedded in the 6to4 address, making the return path for the 6to4 embedded in the 6to4 address, making the return path for the 6to4
tunnel infeasible, and the second is the use of local filters and tunnel infeasible, and the second is the use of local filters and
firewalls that drop incoming IP packets that use IP protocol 41. If firewalls that drop incoming IP packets that use IP protocol 41. If
the former case were prevalent it would be reasonable to expect that the former case were prevalent it would be reasonable to expect that
a significant proportion of failed 6to4 connections would use a significant proportion of failed 6to4 connections would use
embedded IPv4 addresses that are either drawn from the private use embedded IPv4 addresses that are either drawn from the private use
(RFC 1918) address ranges, contrary to RFC 3056, or from addresses (RFC 1918) address ranges, contrary to RFC 3056, or from addresses
skipping to change at page 6, line 39 skipping to change at page 6, line 37
rate was observed between these two configurations; however, other rate was observed between these two configurations; however, other
operators have reported significant problems when replying from the operators have reported significant problems when replying from the
native address, caused by stateful firewalls at the user site. Given native address, caused by stateful firewalls at the user site. Given
that the server used its own 6to4 relay for the return path, the only that the server used its own 6to4 relay for the return path, the only
difference in the IP packet itself between the successful IPv4 difference in the IP packet itself between the successful IPv4
connections and the failed 6to4 connections was the IP protocol connections and the failed 6to4 connections was the IP protocol
number, which was 6 (TCP) for the successful IPv4 connections and 41 number, which was 6 (TCP) for the successful IPv4 connections and 41
(IPv6 payload) for the failed 6to4 connections. The inference from (IPv6 payload) for the failed 6to4 connections. The inference from
these experiments is that one likely reason for the high connection these experiments is that one likely reason for the high connection
failure rate for 6to4 connections is the use of local filters close failure rate for 6to4 connections is the use of local filters close
to the end-user that block incoming packets with protocol 41. to the end-user that block incoming packets with protocol 41, in some
cases made worse by stateful firewalls if the source address is not
192.88.99.1.
In a dual stack context this connection failure rate was effectively In a dual stack context this connection failure rate was effectively
masked by the ability of the client system to recover from the masked by the ability of the client system to recover from the
failure and make a successful connection using IPv4. In this case failure and make a successful connection using IPv4. In this case
the only effect on the client system was a delay in making the the only effect on the client system was a delay in making the
connection of between 7 and 20 seconds as the client's system timed connection of between 7 and 20 seconds as the client's system timed
out on the 6to4 connection attempts (see out on the 6to4 connection attempts (see
[I-D.wing-v6ops-happy-eyeballs-ipv6]). [I-D.wing-v6ops-happy-eyeballs-ipv6]).
This experience and further analysis shows that specific operational This experience and further analysis shows that specific operational
skipping to change at page 7, line 34 skipping to change at page 7, line 34
The effect of this problem on users is that their IPv6 stack The effect of this problem on users is that their IPv6 stack
believes that it has 6to4 connectivity, but in fact all outgoing believes that it has 6to4 connectivity, but in fact all outgoing
IPv6 packets are black-holed. The prevalence of this problem is IPv6 packets are black-holed. The prevalence of this problem is
hard to measure, since the resulting IPv6 packets can never be hard to measure, since the resulting IPv6 packets can never be
observed from the outside. observed from the outside.
2. Inbound Black Hole: In this case, 6to4 packets sent to 2. Inbound Black Hole: In this case, 6to4 packets sent to
192.88.99.1 are correctly delivered to a 6to4 relay, and reply 192.88.99.1 are correctly delivered to a 6to4 relay, and reply
packets are returned, but they are dropped by an inbound Protocol packets are returned, but they are dropped by an inbound Protocol
41 filter. As far as the user is concerned, the effect is the 41 filter. As far as the user is concerned, the effect is the
same as the previous case: IPv6 is a black hole. Many enterprise same as the previous case: IPv6 is a black hole. Many enterprise
neworks are believed to be set up in this way. Connection networks are believed to be set up in this way. Connection
attempts due to this case can be observed by IPv6 server attempts due to this case can be observed by IPv6 server
operators, in the form of SYN packets from addresses in 2002::/16 operators, in the form of SYN packets from addresses in 2002::/16
followed by no response to the resulting SYN/ACK. From the followed by no response to the resulting SYN/ACK. From the
experiments cited above, this appears to be a significant problem experiments cited above, this appears to be a significant problem
in practice. in practice.
This problem is complicated by three variables: the firewall
applying the Protocol 41 filter may be stateless or stateful; the
relay may source its packets from its native IPv4 address or from
192.88.99.1; packets from the relay may be subject to IPv4
ingress filtering. If the Protocol 41 filter is stateless, 6to4
will never succeed. If it is stateful, the firewall will drop
inbound packets from addresses that have not been seen in
outbound traffic on the same port. In this case, 6to4 will only
succeed if the packets are sourced from 192.88.99.1. But if the
relay is subject to ingress filtering, only packets from its
native IPv4 address can be transmitted. There are therefore only
three combinations that can succeed:
1. No Protocol 41 filter, with the relay using its native IPv4
source address.
2. No Protocol 41 filter, with the relay using the anycast IPv4
source address and with no ingress filter.
3. A stateful Protocol 41 firewall, with the relay using the
anycast IPv4 source address and with no ingress filter.
3. No Return Relay: If the Outbound Black Hole problem does not 3. No Return Relay: If the Outbound Black Hole problem does not
occur, i.e. the outgoing packet does reach the intended native occur, i.e. the outgoing packet does reach the intended native
IPv6 destination, the target system will send a reply packet, to IPv6 destination, the target system will send a reply packet, to
2002:c000:2aa::123 in our example above. Then 2002::/16 may or 2002:c000:2aa::123 in our example above. Then 2002::/16 may or
may not be successfully routed. If it is not routed, the packet may not be successfully routed. If it is not routed, the packet
will be dropped (hopefully with 'destination unreachable'). will be dropped (hopefully with 'destination unreachable').
According to RFC 3056, an unwilling relay "MUST NOT advertise any According to RFC 3056, an unwilling relay "MUST NOT advertise any
2002:: routing prefix into the native IPv6 domain"; therefore, 2002:: routing prefix into the native IPv6 domain"; therefore,
conversely, if this prefix is advertised the relay must relay conversely, if this prefix is advertised the relay must relay
packets regardless of source and destination. However, in packets regardless of source and destination. However, in
skipping to change at page 8, line 20 skipping to change at page 8, line 39
4. Large RTT: In the event that none of the above three problems 4. Large RTT: In the event that none of the above three problems
applies, and a two-way path does in fact exist between a 6to4 applies, and a two-way path does in fact exist between a 6to4
host and a native host, the round trip time may be quite large host and a native host, the round trip time may be quite large
and variable since the paths to the two relays are unmanaged and and variable since the paths to the two relays are unmanaged and
may be complex. Overloaded relays might also cause highly may be complex. Overloaded relays might also cause highly
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. Path MTU Discovery does not native IPv6 server will see 1500. It has been observed that Path
always work, and this can lead to connectivity failures. Even if MTU Discovery does not always work, and this can lead to
a TCP SYN/ACK exchange works, TCP packets with full size payloads connectivity failures. Even if a TCP SYN/ACK exchange works, TCP
may simply be lost. These failures are disconcerting even to an packets with full size payloads may simply be lost. This problem
informed user, since a standard 'ping' from the client to the is apparently exacerbated in some cases by failure of the TCP MSS
negotiation mechanism. These failures are disconcerting even to
an informed user, since a standard 'ping' from the client to the
server will succeed, because it generates small packets, and the server will succeed, because it generates small packets, and the
successful SYN/ACK exchange can be traced. Also, the failure may successful SYN/ACK exchange can be traced. Also, the failure may
occur on some paths but not others, so a user may be able to occur on some paths but not others, so a user may be able to
fetch web pages from one site, but only ping another. fetch web pages from one site, but only ping another.
Additionally, there is a problem if 6to4 is enabled on a router
and it advertises the resulting prefix on a LAN, but does not
also advertise a smaller MTU; in this case TCP MSS negotiation
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
skipping to change at page 9, line 15 skipping to change at page 9, line 38
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
fallback to IPv4. Tracking down anycast routing problems and fallback to IPv4. Tracking down anycast routing problems and
PMTUD failures is particularly hard. PMTUD failures is particularly hard.
The practical impact of the above problems, which are by no means The practical impact of the above problems, which are by no means
universal as there is considerable successful use of Anycast 6to4, universal as there is considerable successful use of Anycast 6to4,
has been measured at a fraction of 1% loss of attempted connections has been measured at a fraction of 1% loss of attempted connections
to content servers (see <http://www.fud.no/ipv6/>). While this seems to dual-stack content servers [Anderson]. This is because a small
fraction of client hosts attempt to connect using 6to4, and up to 20%
of these experience one of the above failure modes. While this seems
low, it amounts to a significant financial impact for content low, it amounts to a significant financial impact for content
providers. Also, end users frustrated by the poor response times providers. Also, end users frustrated by the poor response times
caused by fall-back to IPv4 connectivity caused by fall-back to IPv4 connectivity
[I-D.wing-v6ops-happy-eyeballs-ipv6] are considered likely to [I-D.wing-v6ops-happy-eyeballs-ipv6] are considered likely to
generate help desk calls with their attendant costs. generate help desk calls with their attendant costs.
A rather different operational problem caused incidentally by 6to4 is A rather different operational problem caused incidentally by 6to4 is
that, according to observations made by Tim Chown and James Morse at that, according to observations made at the University of Southampton
the University of Southampton, rogue Router Advertisements [RFC6104] by Tim Chown and James Morse, and at other sites, rogue Router
predominantly convey a 2002::/16 prefix. This appears to be due to Advertisements [RFC6104] often convey a 2002::/16 prefix. This
misbehaviour by devices acting as local IPv6 routers or connection- appears to be due to misbehaviour by devices acting as local IPv6
sharing devices but issuing RA messages on the wrong interface. routers or connection-sharing devices but issuing RA messages on the
wrong interface. Such a device, if it obtains IPv6 connectivity via
an upstream link to the Internet, should only issue the corresponding
RA messages on its downstream link to the nodes intended to share its
Internet connection. Issuing RA messages on the upstream link will
perturb any other IPv6 hosts on that link. If 6to4 routing is
enabled by default on a device that exhibits this faulty behaviour,
the resulting rogue RA messages will indeed convey a 2002::/16
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. There is a clear incentive for each of them to
take appropriate action, as described below. 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
skipping to change at page 10, line 4 skipping to change at page 10, line 36
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.
1. Some vendors of routers, including customer premises equipment, 1. Some vendors of routers, including customer premises equipment,
have not only included support for 6to4 in their products, but have not only included support for 6to4 in their products, but
have enabled it by default. This is bad practice - it should have enabled it by default. This is bad practice - it should
always be a conscious decision by a user to enable 6to4. Many of always be a conscious decision by a user to enable 6to4. Many of
the above problems only occur due to unintentional deployment of the above problems only occur due to unintentional deployment of
6to4. 6to4.
2. Similarly, host operating systems should not enable Anycast 6to4 2. Similarly, host operating systems should not enable Anycast 6to4
by default; it should always be left to the user to switch it on. by default; it should always be left to the user to switch it on.
3. Any 6to4 implementation that attempts to activate itself when the 3. Any 6to4 implementation that attempts to activate itself when the
available IPv4 address is an RFC 1918 address is faulty and needs available IPv4 address is an RFC 1918 address is faulty and needs
to be updated. to be updated.
4. 6to4 implementations should adopt updated IETF recommendations on 4. 6to4 implementations should adopt updated IETF recommendations on
address selection [I-D.ietf-6man-rfc3484-revise]. address selection [I-D.ietf-6man-rfc3484-revise].
5. 6to4 router or connection-sharing implementations must avoid 5. 6to4 relay implementations must carefully follow section 3.2 of
issuing rogue RAs [RFC6104]. Specifically, where 6to4 is being [RFC4213] to ensure correct handling of MTU issues.
enabled by a host for Internet connection sharing purposes, and 6. 6to4 router or connection-sharing implementations must avoid
the host supports [RFC4191], then it should set the Router issuing rogue RAs [RFC6104]. Additionally, where 6to4 is being
enabled by a node for Internet connection sharing purposes, and
the node supports [RFC4191], then it should set the Router
Advertisement router preference bits to 11 (low preference). Advertisement router preference bits to 11 (low preference).
4.2. Consumer ISPs, and enterprise networks, that do not support IPv6 4.2. Consumer ISPs, and enterprise networks, that do not support IPv6
in any way in any way
4.2.1. Anycast address availability
To reduce the negative impact of Anycast 6to4 deployed (probably To reduce the negative impact of Anycast 6to4 deployed (probably
unknowingly) by users, and consequent user dissatisfaction and help unknowingly) by users, and consequent user dissatisfaction and help
desk calls, such ISPs should check in sequence: desk calls, such ISPs should check in sequence:
1. Does the ISP have a route to 192.88.99.1? (This means an 1. Does the ISP have a route to 192.88.99.1? (This means an
explicit route, or knowledge that the default upstream provider explicit route, or knowledge that the default upstream provider
has an explicit route. A default route doesn't count!) has an explicit route. A default route doesn't count!)
2. If so, is it functional and stable? 2. If so, is it functional and stable?
3. If so, is the ping time reasonably short? 3. If so, is the ping time reasonably short?
4. If so, does the relay willingly accept 6to4 traffic from the 4. If so, does the relay willingly accept 6to4 traffic from the
ISP's IPv4 prefixes? (Note that this is an administrative as ISP's IPv4 prefixes? (Note that this is an administrative as
well as a technical question - is the relay's operator willing to well as a technical question - is the relay's operator willing to
accept the traffic?) accept the traffic?)
Unless the answer to all these questions is 'yes', subscribers will Unless the answer to all these questions is 'yes', the operator
be no worse off, and possibly better off, if the route to 192.88.99.1 should consider blocking the route to 192.88.99.1 and generating an
is blocked and generates an IPv4 'destination unreachable'. There is IPv4 'destination unreachable' message. This may cause some 6to4
little operational experience with this, however. implementations to fall back to IPv4 more quickly. There is little
operational experience with this, however.
Some implementations also perform some form of 6to4 relay Some implementations also perform some form of 6to4 relay
qualification. For example, one host implementation (Windows) tests qualification. For example, one host implementation (Windows) tests
the Protocol 41 reachability by sending an ICMPv6 echo request with the Protocol 41 reachability by sending an ICMPv6 echo request with
Hop Limit=1 to the relay, expecting a response or Hop Limit exceeded Hop Limit=1 to the relay, expecting a response or Hop Limit exceeded
error back. Lack of any response indicates that the 6to4 relay does error back. Lack of any response indicates that the 6to4 relay does
not work so 6to4 is turned off [Savola]. not work so 6to4 is turned off [Savola].
A more constructive approach for such an ISP is to seek out a transit A more constructive approach for such an ISP is to seek out a transit
provider who is indeed willing to offer outbound 6to4 relay service, provider who is indeed willing to offer outbound 6to4 relay service,
so that the answer to each of the questions above is positive. so that the answer to each of the questions above is positive.
In any case, such ISPs should always allow protocol 41 through their 4.2.2. Protocol 41
ISPs in this class should always allow protocol 41 through their
network and firewalls. Not only is this a necessary condition for network and firewalls. Not only is this a necessary condition for
6to4 to work, but it also allows users who want to use a configured 6to4 to work, but it also allows users who want to use a configured
IPv6 tunnel service to do so. IPv6 tunnel service to do so.
Some operators, particularly enterprise networks, silently block Some operators, particularly enterprise networks, silently block
Protocol 41 on security grounds. Doing this on its own is bad Protocol 41 on security grounds. Doing this on its own is bad
practice, since it contributes to the problem and harms any users who practice, since it contributes to the problem and harms any users who
are knowingly or unknowingly attempting to run 6to4. The strategic are knowingly or unknowingly attempting to run 6to4. The strategic
solution is to deploy native IPv6, making Protocol 41 redundant. In solution is to deploy native IPv6, making Protocol 41 redundant. In
the short term, experimentation could be encouraged by allowing the short term, experimentation could be encouraged by allowing
Protocol 41 for certain users, while returning appropriate ICMP Protocol 41 for certain users, while returning appropriate ICMP
responses as mentioned above. Unfortunately, if this is not done, responses as mentioned above. Unfortunately, if this is not done,
the 6to4 problem cannot be solved. the 6to4 problem cannot be solved.
4.2.3. IPv4 prefix issues
Operators should never use "bogon" address space such as the example Operators should never use "bogon" address space such as the example
of 1.1.1.0/24 for customers, since IPv4 exhaustion means that all of 1.1.1.0/24 for customers, since IPv4 exhaustion means that all
such addresses are likely to be in real use in the near future. such addresses are likely to be in real use in the near future.
(Also see [I-D.ietf-intarea-shared-addressing-issues].) An operator (Also see [I-D.ietf-intarea-shared-addressing-issues].) An operator
that is unable to immediately drop this practice should ensure that that is unable to immediately drop this practice should ensure that
192.88.99.1 generates IPv4 'destination unreachable'. It has been 192.88.99.1 generates IPv4 'destination unreachable'. It has been
suggested that they could also run a dummy 6to4 relay at that address suggested that they could also run a dummy 6to4 relay at that address
which always returns ICMPv6 'destination unreachable' as a 6to4 which always returns ICMPv6 'destination unreachable' as a 6to4
packet. However, these techniques are not very effective, since most packet. However, these techniques are not very effective, since most
current end-user 6to4 implementations will ignore them. current end-user 6to4 implementations will ignore them.
If an operator is providing legitimate global addresses to customers If an operator is providing legitimate global addresses to customers
(neither RFC 1918 nor bogon addresses), and also running Carrier (neither RFC 1918 nor bogon addresses), and also running Carrier
Grade NAT (Large Scale NAT) between this address space and the global Grade NAT (Large Scale NAT) between this address space and the global
address space of the Internet, then 6to4 cannot work properly. Such address space of the Internet, then 6to4 cannot work properly. Such
an operator should also take care to return 'destination unreachable' an operator should also take care to return 'destination unreachable'
for 6to4 traffic. Alternatively, they could offer untranslated for 6to4 traffic. Alternatively, they could offer untranslated
address space to the customers concerned. address space to the customers concerned.
4.2.4. DNS issues
A customer who is intentionally using 6to4 may also need to create A customer who is intentionally using 6to4 may also need to create
AAAA records, and the operator should be able to support this, even AAAA records, and the operator should be able to support this, even
if the DNS service itself runs exclusively over IPv4. However, if the DNS service itself runs exclusively over IPv4. However,
customers should be advised to consider carefully whether their 6to4 customers should be advised to consider carefully whether their 6to4
service is sufficiently reliable for this. service is sufficiently reliable for this.
Operators could, in principle, offer reverse DNS support for 6to4 Operators could, in principle, offer reverse DNS support for 6to4
users [RFC5158], although this is not straightforward for domestic users [RFC5158], although this is not straightforward for domestic
customers. customers.
4.2.5. Rogue Router Advertisements
Paradoxically, operators in this category should consider whether Paradoxically, operators in this category should consider whether
they need to defend themselves against rogue IPv6 RA messages they need to defend themselves against rogue IPv6 RA messages
[RFC6105], since such messages may appear from devices seeking to [RFC6105], since such messages may appear from devices seeking to
operate as 6to4 routers. operate as 6to4 routers, and confuse any user devices with IPv6
enabled by default. Eventually, the measures being designed by the
IETF Source Address Validation Improvements (SAVI) working group will
assist with this problem. In the short term, IPv4-only operators may
choose to filter out packets with the IPv6 Ethertype (0x86DD) in
their access equipment; this will definitively remove rogue RA
packets.
Finally, enterprise operators who have complete administrative 4.2.6. Planning for IPv6 deployment
control of all end-systems may choose to disable 6to4 in those
systems as an integral part of their plan to deploy IPv6.
4.2.1. 6to4 as the first step to IPv6 operation Enterprise operators who have complete administrative control of all
end-systems may choose to disable 6to4 in those systems as an
integral part of their plan to deploy IPv6.
Some IPv4 operators have chosen to install a 6to4 relay, connected Some IPv4 operators have chosen to install a 6to4 relay, connected
via an IPv6-in-IPv4 tunnel to an IPv6 operator, as a first step via an IPv6-in-IPv4 tunnel to an IPv6 operator, as a first step
before native IPv6 deployment. The routing guidelines in Section 4.4 before native IPv6 deployment. The routing guidelines in Section 4.4
would apply. However, offering genuine IPv6 service to interested would apply. However, offering genuine IPv6 service to interested
customers, even if tunneled, would generally be a better first step. customers, even if tunneled, would generally be a better first step.
4.3. Consumer ISPs, and enterprise networks, that do support IPv6 4.3. Consumer ISPs, and enterprise networks, that do support IPv6
Once an operator does support IPv6 service, whether experimentally or Once an operator does support IPv6 service, whether experimentally or
skipping to change at page 12, line 32 skipping to change at page 13, line 36
Such an operator may automatically fall into one of the following two Such an operator may automatically fall into one of the following two
categories (transit provider or content provider), so the guidelines categories (transit provider or content provider), so the guidelines
in Section 4.4 or in Section 4.5 will apply instead. in Section 4.4 or in Section 4.5 will apply instead.
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.
Operators in this category should consider whether they need to Operators in this category should consider whether they need to
defend themselves against rogue RA messages [RFC6105]. defend themselves against rogue RA messages with an RA Guard solution
[RFC6105]. If RA Guard is not available, it may help in some cases
if at least one legitimate IPv6 router per LAN supports [RFC4191] and
sets the Router Advertisement router preference bits to 01 (high
preference). Eventually, the measures being designed by the IETF
Source Address Validation Improvements (SAVI) working group will
assist with this problem.
4.4. Transit ISPs and Internet Exchange Points 4.4. Transit ISPs and Internet Exchange Points
We assume that transit ISPs and IXPs have IPv6 connectivity. To We assume that transit ISPs have IPv6 connectivity. To reduce the
reduce the negative impact of Anycast 6to4 on all their client negative impact of Anycast 6to4 on all their client networks, it is
networks, it is strongly recommended that they each run an Anycast strongly recommended that they each run an Anycast 6to4 relay
6to4 relay service. This will have the additional advantage that service. This will have the additional advantage that they will
they will terminate the 6to4 IPv4 packets, and can then forward the terminate the 6to4 IPv4 packets, and can then forward the
decapsulated IPv6 traffic according to their own policy. Otherwise, decapsulated IPv6 traffic according to their own policy. Otherwise,
they will blindly forward all the encapsulated IPv6 traffic to a they will blindly forward all the encapsulated IPv6 traffic to a
competitor who does run a relay. competitor who does run a relay.
Although most modern Internet Exchange Points do not offer IP layer
services, an IXP could choose to operate an Anycast 6to4 relay
service for the benefit of its customers. If so, it should follow
the recommendations in this section.
It is of critical importance that routing to this service is It is of critical importance that routing to this service is
carefully managed: carefully managed:
1. The IPv4 prefix 192.88.99.0/24 must be announced only towards 1. The IPv4 prefix 192.88.99.0/24 must be announced only towards
client IPv4 networks whose outbound 6to4 packets will be client IPv4 networks whose outbound 6to4 packets will be
accepted. accepted.
2. The IPv6 prefix 2002::/16 must be announced towards native IPv6. 2. The IPv6 prefix 2002::/16 must be announced towards native IPv6.
The relay must accept all traffic towards 2002::/16 that reaches The relay must accept all traffic towards 2002::/16 that reaches
it, so the scope reached by this announcement should be carefully it, so the scope reached by this announcement should be carefully
planned. It must reach all client IPv6 networks of the transit planned. It must reach all client IPv6 networks of the transit
ISP or IXP. If it reaches a wider scope, the relay will be ISP. If it reaches a wider scope, the relay will be offering a
offering a free ride to non-clients. free ride to non-clients.
3. The evidence is mixed, but it seems best to ensure that when the 3. As discussed in item 2 of Section 3, the choice of IPv4 source
relay sends 6to4 packets back towards a 6to4 user, they should address used when the relay sends 6to4 packets back towards a
have 192.88.99.1 as their IPv4 source address (not the relay's 6to4 user is important. The best choice is likely to be
unicast IPv4 address). This is to avoid problems if the user is 192.88.99.1, not the relay's unicast IPv4 address, unless ingress
behind a stateful firewall that drops inbound packets from filtering is an issue. This is to avoid failure if the user is
addresses that have not been seen in outbound traffic. behind a stateful firewall.
4. The relay should be capable of responding correctly to ICMPv6 4. The relay should be capable of responding correctly to ICMPv6
echo requests encapsulated in IPv4 protocol 41, typically with echo requests encapsulated in IPv4 protocol 41, typically with
outer destination address 192.88.99.1 and inner destination outer destination address 192.88.99.1 and inner destination
address 2002:c058:6301::. (As noted previously, some 6to4 hosts address 2002:c058:6301::. (As noted previously, some 6to4 hosts
are known to send echo requests with Hop Limit = 1, which allows are known to send echo requests with Hop Limit = 1, which allows
them to rapidly detect the presence or absence of a relay in any them to rapidly detect the presence or absence of a relay in any
case, but operators cannot rely on this behaviour.) case, but operators cannot rely on this behaviour.)
5. Protocol 41 must not be filtered in any IPv4 network or 5. Protocol 41 must not be filtered in any IPv4 network or
firewalls. firewalls.
6. As a matter of general practice, which is essential for 6to4 to 6. As a matter of general practice, which is essential for 6to4 to
work well, IPv6 PMTUD must be possible, which means that ICMPv6 work well, IPv6 PMTUD must be possible, which means that ICMPv6
must not be blocked anywhere [RFC4890]. This also requires that must not be blocked anywhere [RFC4890]. This also requires that
the relay has a sufficiently high ICMP error generation the relay has a sufficiently high ICMP error generation
threshold. For a busy relay, a typical default rate limit of 100 threshold. For a busy relay, a typical default rate limit of 100
packets per second is too slow. On a busy relay, 1000pps or more packets per second is too slow. On a busy relay, 1000pps or more
might be needed. If ICMPv6 "Packet too Big" error messages are might be needed. If ICMPv6 "Packet Too Big" error messages are
rate-limited, users will experience PMTUD failure. rate-limited, users will experience PMTUD failure.
7. The relay must have adequate performance, and since load 7. The relay must have adequate performance, and since load
prediction is extremely hard, it must be possible to scale it up prediction is extremely hard, it must be possible to scale it up
or, perhaps better, to replicate it as needed. Since the relay or, perhaps better, to replicate it as needed. Since the relay
process is stateless, any reasonable method of load sharing process is stateless, any reasonable method of load sharing
between multiple relays will do. between multiple relays will do.
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
skipping to change at page 13, line 51 skipping to change at page 15, line 17
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 content servers are dual stacked. There is a
need to avoid the situation where a client host, configured with need to avoid the situation where a client host, configured with
Anycast 6to4, suceeds 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
case it need not respond to the 6to4 anycast address. case it need not respond to the 6to4 anycast address.
skipping to change at page 14, line 34 skipping to change at page 15, line 49
as short as possible. It is highly desirable to arrange the scope of as short as possible. It is highly desirable to arrange the scope of
advertisements for 2002::/16 such that content providers have a short advertisements for 2002::/16 such that content providers have a short
path to the relay, and the relay should have a short path to the ISP path to the relay, and the relay should have a short path to the ISP
border. Care should be taken about shooting off advertisements for border. Care should be taken about shooting off advertisements for
2002::/16 into BGP4; they will become traffic magnets. If every ISP 2002::/16 into BGP4; they will become traffic magnets. If every ISP
with content provider customers operates a relay, there will be no with content provider customers operates a relay, there will be no
need for any of them to be advertised beyond each ISP's own need for any of them to be advertised beyond each ISP's own
customers. customers.
Protocol 41 must not be filtered in the ISP's IPv4 network or Protocol 41 must not be filtered in the ISP's IPv4 network or
firewallls. If the relays are placed outside the content provider's firewalls. If the relays are placed outside the content provider's
firewall, the latter may filter protocol 41 if desired. firewall, the latter may filter protocol 41 if desired.
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 for content servers is to embed the relay function directly
in the content server. This is in fact trivial, since it can be in the content server. This is in fact trivial, since it can be
achieved by enabling a local 6to4 interface on the server, and using achieved by enabling a local 6to4 interface on the server, and using
it to route 2002::/16 for outbound packets. (This might not allow it to route 2002::/16 for outbound packets. (This might not allow
use of 192.88.99.1 as the source address.) Further details are to be use of 192.88.99.1 as the source address.) Further details are to be
found at <http://www.potaroo.net/ispcol/2010-05/v6hints.html>. found at [Huston-b]. However, in this case Protocol 41 must be
allowed by the firewalls.
However, in this case Protocol 41 must be allowed by 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 uRPF 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 (the minimum allowed for IPv6) is recommended; again see [Huston-b].
<http://www.potaroo.net/ispcol/2010-05/v6hints.html>. Of course, Of course, ICMPv6 "Packet Too Big" must not be blocked or rate-
ICMPv6 "Message too Big" must not be blocked or rate-limited anywhere limited anywhere [RFC4890].
[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
on them as a pseudo-security check for IPv6 clients. on them as a pseudo-security check for IPv6 clients.
Operators and content providers should make sure that no routers are Operators and content providers 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.
skipping to change at page 15, line 44 skipping to change at page 17, line 9
There are various ways, such as tunnel brokers [RFC3053], 6rd There are various ways, such as tunnel brokers [RFC3053], 6rd
[RFC5969], and L2TPv2 hub-and-spoke [RFC5571], by which Internet [RFC5969], and L2TPv2 hub-and-spoke [RFC5571], by which Internet
Service Providers can provide tunneled IPv6 service to subscribers in Service Providers can provide tunneled IPv6 service to subscribers in
a managed way, in which the subscriber will acquire an IPv6 prefix a managed way, in which the subscriber will acquire an IPv6 prefix
under a normal provider-based global IPv6 prefix. Most of the issues under a normal provider-based global IPv6 prefix. Most of the issues
described for 6to4 do not arise in these scenarios. However, for described for 6to4 do not arise in these scenarios. However, for
IPv6-in-IPv4 tunnels used by clients behind a firewall, it is IPv6-in-IPv4 tunnels used by clients behind a firewall, it is
essential that IPv4 Protocol 41 is not blocked. essential that IPv4 Protocol 41 is not blocked.
As a matter of general practice, IPv6 PMTUD must be possible, which As a matter of general practice, IPv6 PMTUD must be possible, which
means that ICMPv6 "Message too Big" must not be blocked or rate- means that ICMPv6 "Packet Too Big" must not be blocked or rate-
limited anywhere [RFC4890]. limited anywhere [RFC4890].
6. Security Considerations 6. Security Considerations
There is a general discussion of security issues for IPv6-in-IPv4 There is a general discussion of security issues for IPv6-in-IPv4
tunnels in [I-D.ietf-v6ops-tunnel-security-concerns], and tunnels in [RFC6169] and [I-D.ietf-v6ops-tunnel-loops] discusses
possible malicious loops. [RFC3964] specifically discusses 6to4
[I-D.ietf-v6ops-tunnel-loops] discusses possible malicious loops. security. In summary, tunnels create a challenge for many common
[RFC3964] specifically discusses 6to4 security. In summary, tunnels security mechanisms, simply because a potentially suspect packet is
create a challenge for many common security mechanisms, simply encapsulated inside a harmless outer packet. All these
because a potentially suspect packet is encapsulated inside a considerations apply to the automatic mechanisms discussed in this
harmless outer packet. All these considerations apply to the document. However, it should be noted that if an operator provides
automatic mechanisms discussed in this document. However, it should well managed servers and relays for 6to4, non-encapsulated IPv6
be noted that if an operator provides well managed servers and relays packets will pass through well defined points (the native IPv6
for 6to4, non-encapsulated IPv6 packets will pass through well interfaces of those servers and relays) at which security mechanisms
defined points (the native IPv6 interfaces of those servers and may be applied.
relays) at which security mechanisms may be applied.
A blanket recommendation to block Protocol 41 is not compatible with A blanket recommendation to block Protocol 41 is not compatible with
mitigating the 6to4 problems described in this document. mitigating the 6to4 problems described in this document.
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, Tore Useful comments and contributions were made by Emile Aben, Mikael
Anderson, Jack Bates, Cameron Byrne, Tim Chown, Remi Despres, Jason Abrahamsson, Tore Anderson, Hermin Anggawijaya, Jack Bates, Cameron
Fesler, Wes George, Geoff Huston, Eric Kline, Victor Kuarsingh, Byrne, Tim Chown, Remi Despres, Jason Fesler, Wes George, Philip
Martin Levy, David Malone, Martin Millnert, Keith Moore, Gabi Homburg, Geoff Huston, Eric Kline, Victor Kuarsingh, Martin Levy,
Nakibly, Michael Newbery, Pekka Savola, Mark Smith, Nathan Ward, David Malone, Martin Millnert, Keith Moore, Gabi Nakibly, Michael
James Woodyatt, and others. Newbery, Pekka Savola, 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 9. Change log [RFC Editor: please remove]
draft-ietf-v6ops-6to4-advisory-01: Updated with WG Last Call
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 addditional 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. Informative References
[Aben] Aben, E., "6to4 - How Bad is it Really?", 2010, <https://
labs.ripe.net/Members/emileaben/
6to4-how-bad-is-it-really>.
[Anderson]
Anderson, T., "IPv6 dual-stack client loss in Norway",
2010, <http://www.fud.no/ipv6/>.
[Huston-a]
Huston, G., "Flailing IPv6", 2010,
<http://www.potaroo.net/ispcol/2010-12/6to4fail.html>.
[Huston-b]
Huston, G., "Two Simple Hints for Dual Stack Servers",
2010,
<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-02 (work in progress),
March 2011. 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]
Troan, O., "Request to move Connection of IPv6 Domains via
IPv4 Clouds (6to4) to Historic status",
draft-ietf-v6ops-6to4-to-historic-00 (work in progress),
April 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-06 (work in
progress), March 2011. progress), March 2011.
[I-D.ietf-v6ops-tunnel-security-concerns]
Krishnan, S., Thaler, D., and J. Hoagland, "Security
Concerns With IP Tunneling",
draft-ietf-v6ops-tunnel-security-concerns-04 (work in
progress), October 2010.
[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-03
(work in progress), February 2011. (work in progress), February 2011.
[I-D.vandevelde-v6ops-harmful-tunnels]
Velde, G., Troan, O., and T. Chown, "Non-Managed IPv6
Tunnels considered Harmful",
draft-vandevelde-v6ops-harmful-tunnels-01 (work in
progress), August 2010.
[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.
skipping to change at page 18, line 21 skipping to change at page 20, line 5
[RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers",
RFC 3068, June 2001. 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
for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering [RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering
ICMPv6 Messages in Firewalls", RFC 4890, May 2007. ICMPv6 Messages in Firewalls", RFC 4890, May 2007.
[RFC5158] Huston, G., "6to4 Reverse DNS Delegation Specification", [RFC5158] Huston, G., "6to4 Reverse DNS Delegation Specification",
RFC 5158, March 2008. RFC 5158, March 2008.
[RFC5571] Storer, B., Pignataro, C., Dos Santos, M., Stevant, B., [RFC5571] Storer, B., Pignataro, C., Dos Santos, M., Stevant, B.,
Toutain, L., and J. Tremblay, "Softwire Hub and Spoke Toutain, L., and J. Tremblay, "Softwire Hub and Spoke
Deployment Framework with Layer Two Tunneling Protocol Deployment Framework with Layer Two Tunneling Protocol
Version 2 (L2TPv2)", RFC 5571, June 2009. Version 2 (L2TPv2)", RFC 5571, June 2009.
skipping to change at page 18, line 43 skipping to change at page 20, line 30
Infrastructures (6rd) -- Protocol Specification", Infrastructures (6rd) -- Protocol Specification",
RFC 5969, August 2010. RFC 5969, August 2010.
[RFC6104] Chown, T. and S. Venaas, "Rogue IPv6 Router Advertisement [RFC6104] Chown, T. and S. Venaas, "Rogue IPv6 Router Advertisement
Problem Statement", RFC 6104, February 2011. Problem Statement", RFC 6104, February 2011.
[RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J.
Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105,
February 2011. February 2011.
[RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security
Concerns with IP Tunneling", RFC 6169, April 2011.
[Savola] Savola, P., "Observations of IPv6 Traffic on a 6to4 [Savola] Savola, P., "Observations of IPv6 Traffic on a 6to4
Relay", ACM SIGCOMM CCR 35 (1) 23-28, 2006. Relay", ACM SIGCOMM CCR 35 (1) 23-28, 2006.
Author's Address Author's Address
Brian Carpenter Brian Carpenter
Department of Computer Science Department of Computer Science
University of Auckland University of Auckland
PB 92019 PB 92019
Auckland, 1142 Auckland, 1142
 End of changes. 57 change blocks. 
147 lines changed or deleted 235 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/