There would appear to be little evidence of substantial active use of
the original form of 6to4 described in [RFC3056
This statement is unsupported, and I believe, superfluous. Such a
statement might be supportable via traffic measurements, depending
on how the measurements were done. But traffic measurements are
often misinterpreted, and without a reference describing actual
methods and results there's no way for the reader to assess the
validity of the statement. Whether it's a defensible statement
also depends on what "substantial" means. Anyway, the document
would be stronger without it, as the document shouldn't really be
about RFC 3056.
Recommendation: delete this sentence.
] analyses the known operational issues in detail and
describes a set of suggestions to improve 6to4 reliability, given the
widespread presence of hosts and customer premises equipment that
support it. However, experience shows that operational failures have
continued despite this advice being available. Fortunately the
advice to disable 6to4 by default has been widely adopted in recent
operating systems, and the failure modes have been largely hidden
from users by many browsers adopting the "Happy Eyeballs" approach
]. Nevertheless, a substantial amount of 6to4 traffic is
still observed and the operational problems caused by 6to4 still
Although facts are hard to obtain, the remaining successful users of
anycast 6to4 are likely to be on hosts using the obsolete policy
] (which prefers 6to4 above IPv4), without Happy
Eyeballs, with a route to an operational anycast relay, and accessing
sites that have a route to an operational return relay.
Taken together these statements seem confusing at best. Here's my
attempt to sort things out:
- Measures that have been taken in the past (recommending
disabling 6to4 by default, use of happy eyeballs) have had some
- However some hosts are still observed (again, without any
reference to the observations) to use 6to4 and have operational
problems doing so.
- Presumably the hosts that are still having operational
problems are those that have, for whatever reason, failed to
implement those measures (perhaps because they are running
obsolete code, perhaps because they are behind routers that
implement 6to4). (Perhaps it is believed that publishing
additional RFCs discouraging 6to4 use will help reduce those
problems, as if somehow users will upgrade their systems and/or
routers because we publish more RFCs.)
Much of the latter paragraph seems completely unsupportable. The
RFC3484 prefix selection table doesn't affect address selection for
applications requiring or deliberately preferring IPv6 (say to
circumvent NAT) and having only a single IPv6 address. (Perhaps the
authors are under the impression that the only hosts anyone wishes
to communicate with using anycast 6to4 are those which also have
IPv4 addresses, or the only apps using IPv6 are those which could
work equally well through IPv4 NAT?) Happy Eyeballs isn't
generally applicable to all applications using IPv6, and even when
it's useful only helps if there are multiple source/destination
address pairs from which to choose. Again, it's not correct to
assume that either end of traffic using 6to4 has an IPv4 address
that would work better for that application. Just to pick one
example, I've seen bittorrent use IPv6 addresses, including 6to4
addresses, when doing so would circumvent NAT brain-damage.
Of course successful use of 6to4 does require routes to working
relays in both directions.
Recommendation: reword the former paragraph and (especially) delete
the latter one.
IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) [RFC5969
explicitly builds on the 6to4 mechanism, and could be viewed as a
superset of 6to4, using a service provider prefix instead of
2002::/16. However, the deployment model is based on service povider
support, such that 6rd can avoid the problems described here. In
this sense, 6rd can be viewed as superseding 6to4 as described in
section 4.2.4 of [RFC2026]
While 6rd is indeed useful, and it seems like a good solution for
access providers wishing to provide their customers with an interim
IPv6 solution until they deploy native IPv6, it is misleading to
call it a "superset" of 6to4 or to claim that it supersedes it. 6rd
would be better described as a subset, since it's potentially
applicable in fewer situations than 6to4 is. Or perhaps it would
be better to say that 6rd and 6to4 have different use cases. In
particular, 6rd doesn't provide any help to a user needing to reach
IPv6 hosts if the ISP to which he's currently connected doesn't
Recommendation: delete the paragraph. 6rd is irrelevant to this
Given that native IPv6 support and various reliable transition
mechanisms are now becoming common, the IETF sees no evolutionary
future for the 6to4 mechanism.
Whether native IPv4 support or reliable transition mechanisms are
"becoming common" depends on your definition of "common", but we're
still a long way from a point where such mechanisms are generally
available and applicable to ordinary users. The main reason that
there's no evolutionary future for the 6to4 mechanism is exhaustion
of IPv4 address space and widespread deployment of NAT including
carrier-side NAT. (The problems with use of anycast could be
fixed if there were much to be gained by fixing them, but the
inevitably-increasing use of carrier-side NAT means there's really
no point in doing so.) Also, the paragraph could be taken to mean
that these "reliable transition mechanisms" are good substitutes for
6to4, when reality is that there is currently no good replacement
Recommendation: reword to say "Given that due to exhaustion of IPv4
address space carrier-side NAT is now becoming common, the IETF sees
no evolutionary future for the 6to4 mechanism"
With the increased deployment of IPv6, the
mechanism has been shown to have a number of fundamental
Some of these shortcomings are not specifically shortcomings with
6to4, but rather shortcomings of original address selection rules
(which incorrectly assumed that any v6 path would work at least as
well as any v4 path), the Internet architecture itself (poor support
for multihomed hosts which manifests in several ways and persists to
o Use of relays. 6to4 depends on an unknown third party to operate
the relays between the 6to4 cloud and the native IPv6 Internet.
I think this is redundant with the 3rd bullet, and the 3rd bullet
states it better.
o The placement of the relay can lead to increased latency, and in
the case the relay is overloaded, packet loss.
While this statement is true on its face, it's sort of meaningless
or misleading. It begs the question "increased latency as
compared to what?" 6to4 actually did a fairly good job of finding
nearby relays in both directions if they were available - often
providing lower latency better than configured tunnels except those
provided by one's own ISP.
The real problem was with the original address prefix selection
algorithm and its implicit assumption that any IPv6 path would be
better than any IPv4 path. If ISPs around the world had deployed
native IPv6 15 years ago but initially with suboptimal routing, the
same problem of decreased latency would have appeared due to hosts'
blind preference of v6 over v4.
For that matter, the intended purpose of 6to4 (or for that matter
IPv6) never was to facilitate communications between hosts or
application peers that could just as well use IPv4.
o There is generally no customer relationship between the end-user
and the relay operator, or even a way for the end-user to know who
the relay operator is, so no support is possible.
o A 6to4 relay for the reverse path and an anycast 6to4 relay used
for the forward path, are openly accessible, limited only by the
scope of routing. 6to4 relays can be used to anonymize traffic and
inject attacks into IPv6 that are very difficult to trace.
Two things: The first statement is true but as far as I can tell
only half of it is relevant - the "reverse" (6->4) path relay
doesn't permit anonymizing traffic as far as I can tell. The
"forward" (4->6) path relay permits anonymizing traffic if the
relay doesn't check that the IPv4 source address on the inbound
packet is consistent with the IPv6 source address on the inbound
packet. Otherwise, the degree of anonymizing possible is about the
same as with NAT44 - the rest of the network can't tell which host
the traffic came from but it can tell which network it came from.
o 6to4 may silently discard traffic in the case where protocol (41)
is blocked in intermediate firewalls. Even if a firewall sent an
ICMP message unreachable back, an IPv4 ICMP message rarely
contains enough of the original IPv6 packet so that it can be
relayed back to the IPv6 sender. That makes this problem hard to
detect and react upon by the sender of the packet.
Well, of course it's not 6to4 discarding the traffic, it's the
firewalls. Place the blame where it belongs. And these problems
exist with protocol 41 tunnels in general, including 6rd tunnels,
not just 6to4 tunnels. (It seems especially odd for this document
to be recommending 6rd as a replacement of sorts for 6to4 while at
the same time
citing 6to4 for shortcomings that are also present with 6rd.)
There are really two issues here:
- "accidental" blocking of 6to4 by firewalls (i.e. because of
naivete or misconfiguration rather than because of explicit policy)
- hosts/apps not coping well with blocking of 6to4 by firewalls
Recommendation: separate into two bullets:
- 6to4 traffic was sometimes silently discarded by firewalls, either
because they blocked
protocol 41 indiscriminately, or because they blocked incoming
traffic flows that weren't initiated by outgoing traffic flows, and
were not configured to recognize outgoing flows over protocol 41.
Sometimes this blocking was deliberate, sometimes accidental due to
- Whether or not by accident, when encapsulated traffic was blocked
by a IPv4-only firewall, an ICMPv4 response from the firewall was
unlikely to be useful to the sender's IPv6 stack, and an IPv4-only
firewall generally wouldn't know how to send ICMPv6 responses
encapsulated in IPv4, to the sending host.
o As 6to4 tunnels across the Internet, the IPv4 addresses used must
be globally reachable. RFC 3056
states that a private address
] MUST NOT be used. 6to4 will not work in networks that
employ other addresses with limited topological span. In
particular it will predictably fail in the case of double network
address translation (NAT444).
This bullet seems very muddy.
"As 6to4 tunnels across the Internet" should say "the IPv4
Internet". The Internet isn't just IPv4.
The second sentence seems out of place. It's not immediately clear
what RFC 3056's statement about RFC 1918 addresses has to do with
the argument that's being made.
- The general issue is that 6to4 doesn't work to provide IPv6 access
to hosts or routers lacking a globally-scoped and globally-reachable
IPv4 address. This in combination with widespread use of NAT made
6to4 much less useful than it would otherwise have been, and is
perhaps the biggest single problem with 6to4.
- A related problem was that it wasn't clear from the 6to4
specifications that hosts and routers supporting 6to4 needed a
reliable way to detect that they had globally-scoped and
globally-reachable IPv4 addresses. RFC 1918 addresses were excluded
by RFC 3056, but other unsuitable IPv4 addresses were not as easily
- Some 6to4 implementations were once known to enable 6to4 by
default for any non-RFC1918 address, having the effect of enabling a
IPv6 address and interface that would never work, and (in the
absence of modern address selection rules or happy eyeballs) causing
traffic to be blackholed. However this problem has largely been
As far as I can tell, the problem with double NAT is just one
example of the general problem. Even a single layer of NAT breaks
Recommendation: reword the above bullet into two separate bullets,
along the lines above.