RFC 6343

Advisory Guidelines for 6to4 Deployment

📅 published August 2011, from ietf

RFC 6343: Advisory Guidelines for 6to4 Deployment ✨

Okay bestie, this is RFC 6343 🎀 It's an Informational doc, which means it's advice and not a rulebook 💅 It was written by B. Carpenter at the Univ. of Auckland and published in August 2011 (ISSN 2070-1721). Its header has no Obsoletes or Updates line, so it isn't replacing or patching anything else 🦋

Abstract ✨

This document gives network operators advice on deploying the 6to4 technique for automatic tunneling of IPv6 over IPv4 🌸 It's mainly for Internet Service Providers (ISPs), including ones that don't support IPv6 yet, and for Content Providers. There's also some advice for implementers. The goal is to keep users happy and keep help-desk calls down 📞💖

Status of This Memo ✨

This document is not an Internet Standards Track specification. It's published for informational purposes 🧚

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community, got public review, and was approved for publication by the Internet Engineering Steering Group (IESG). Not every document the IESG approves is a candidate for any level of Internet Standard, so see Section 2 of RFC 5741 🫶

For the current status, any errata, and how to send feedback, check http://www.rfc-editor.org/info/rfc6343 🔍

Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved 💜

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication. Please read these carefully, because they cover your rights and restrictions for this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License 📜

Table of Contents 🌈

1. Introduction ....................................................2
2. Principles of Operation .........................................3
   2.1. Router 6to4 ................................................3
   2.2. Anycast 6to4 ...............................................4
3. Problems Observed ...............................................5
4. Advisory Guidelines ............................................10
   4.1. Vendor Issues .............................................10
   4.2. Consumer ISPs, and Enterprise Networks, That Do
        Not Support IPv6 in Any Way ...............................11
        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
        Support IPv6 ..............................................13
   4.4. Transit ISPs and Internet Exchange Points .................14
   4.5. Content Providers and Their ISPs ..........................15
5. Tunnels Managed by ISPs ........................................17
6. Security Considerations ........................................17
7. Acknowledgements ...............................................18
8. References .....................................................18
   8.1. Normative References ......................................18
   8.2. Informative References ....................................18

1. Introduction ✨

Once upon a time (a few years before this doc) someone defined a technique for automatic tunneling of IPv6 over IPv4 🌷 It was meant for when a user wants to reach IPv6-based services over a network that doesn't support IPv6. It's called 6to4 [RFC3056] [RFC3068], and it's super widely deployed in end systems, especially desktops and laptops 💻 6to4 is also built into a bunch of popular CPE router models, and some of them have it turned on by default. So lots of end users deploy it without even meaning to 🙈

Unfortunately, real-world experience shows the method has problems in current deployments that can cause connectivity failures 😭 These failures either cause long retry delays or total failures for users trying to connect to services. A lot of the time the user has no clue 6to4 is running, and when they call the help desk, the help desk is almost always unable to diagnose it properly 💀 Anecdotally, lots of help desks just tell users to disable IPv6, which totally defeats the purpose, since the whole point was to encourage early IPv6 adoption 🥲

The main goal of this document is to give network operators a more constructive way to handle this than just turning off 6to4 🦋 It briefly describes how it works, then covers the problems observed, and finally gives specific advice on the available ways to avoid those problems. Some of this advice applies to ISPs that don't support IPv6 yet, because their customers and help desks get hit by this stuff anyway 🫶

Other advice is for content providers and implementers, but this document doesn't go into aspects that are mainly outside the scope of network operators. Those are:

  1. Operating system preferences between IPv4 and IPv6 when both appear to be available [RFC3484-REVISE].
  2. Ensuring that application software deals gracefully with connectivity problems [EYEBALLS-IPV6].
  3. Some content providers have chosen to avoid the problem by hiding their IPv6 address except from customers of pre-qualified networks [DNSWHITE].

A companion document [HISTORIC] proposes to reclassify 6to4 as Historic. However, that won't remove the millions of existing hosts and CPEs that implement 6to4, so the advice in this document is still necessary 🌸

2. Principles of Operation ✨

There are two variants of 6to4, which are referred to here as "Router 6to4" and "Anycast 6to4" 🧚 To get Anycast 6to4, you first need to understand Router 6to4, so we'll start there 💅

2.1. Router 6to4 🎀

Router 6to4 is the original version, documented in [RFC3056]. The model assumes a user site runs native IPv6, but its ISP provides no IPv6 service. The site border router acts as a 6to4 router. If its external global 32-bit IPv4 address is V4ADDR, the site automatically inherits the IPv6 prefix 2002:V4ADDR::/48. (The explanation in RFC 3056 is kinda confusing, because it uses the obsolete "Top Level Aggregator" terminology 🙃) The prefix 2002:V4ADDR::/48 will be used and delegated for IPv6 service within the user site ✨

Let's say there are two site border routers with global IPv4 addresses 192.0.2.170 and 192.0.2.187. They therefore inherit the IPv6 prefixes 2002:c000:2aa::/48 and 2002:c000:2bb::/48, respectively 🦋 The routers can swap IPv6 packets by encapsulating them in IPv4 using protocol number 41, then sending them to each other at their respective IPv4 addresses. In fact, any number of 6to4 routers connected to the IPv4 network can directly exchange IPv6 packets this way 🌈

Some 6to4 routers are also configured as "relay routers" 👑 They behave just like we described, but on top of that they get native IPv6 connectivity with a normal IPv6 prefix. They announce an IPv6 route to 2002::/16. For example, say the 6to4 router at 192.0.2.187 is a relay router, and its address on the 6to4 side is 2002:c000:2bb::1. Now suppose a host with the 6to4 address 2002:c000:2aa::123 sends an IPv6 packet to a native IPv6 destination like 2001:db8:123:456::321. Assume the 6to4 router at 192.0.2.170 has its IPv6 default route set to 2002:c000:2bb::1, meaning the relay. The packet gets delivered to the relay, encapsulated in IPv4. The relay decapsulates it and forwards it into native IPv6 for delivery 🚀 When the remote host replies, the packet (source 2001:db8:123:456::321, destination 2002:c000:2aa::123) finds a route to 2002::/16, so it gets delivered to a 6to4 relay. The process gets reversed, and the packet is encapsulated and forwarded to the 6to4 router at 192.0.2.170 for final delivery 💖

Note that this process does not require the same relay in both directions. The outbound packet goes to whichever relay is configured as the default IPv6 router at the source router, and the return packet goes to whichever relay is announcing a route to 2002::/16 near the remote IPv6 host. Main character energy, the routing is doing its own thing 💅

Of course, RFC 3056 has lots more details, but most of them aren't relevant to current operational problems 🙈

2.2. Anycast 6to4 🌸

Router 6to4 assumes 6to4 routers and relays get managed and configured cooperatively 🫶 In particular, 6to4 sites need to configure a relay router that's willing to carry their outbound traffic, and that relay becomes their default IPv6 router (except for 2002::/16). The goal of the anycast variant, defined in [RFC3068], is to skip all of that configuration. The intention was to make the solution available for small or domestic users, even ones with a single host or a simple home gateway instead of a border router 🏠 It's achieved pretty simply by defining 192.88.99.1 as the default IPv4 address for a 6to4 relay, and therefore 2002:c058:6301:: as the default IPv6 router address for a 6to4 site ✨

Since Anycast 6to4 implies a default configuration for the user site, it doesn't need any special user action 🥹 It does need an IPv4 anycast route to be in place to a relay at 192.88.99.1. As with Router 6to4, there's no requirement that the return path goes through the same relay 🦋

3. Problems Observed 🔥

It should be noted that Router 6to4 was not designed to be an unmanaged solution. Quite the contrary! RFC 3056 contains a number of operational recommendations intended to avoid routing issues 📋 In practice, there are few if any deployments of Router 6to4 that follow those recommendations. Mostly, Anycast 6to4 has been deployed. In this case, the user site (either a single host or a small broadband gateway) discovers that it doesn't have native IPv6 connectivity, but that it does have a global IPv4 address and can resolve AAAA queries. So it assumes it can send 6to4 packets to 192.88.99.1 😳

Okay so, 6to4 is literally giving connection failure 😭 See [Aben] and [Huston-a]. Some researchers ran tests on dual-stack web servers and tracked the TCP connection failure rate 📊 A connection attempt counted as failed when the server got a TCP SYN packet and sent back a SYN/ACK, but never got the ACK it needed to finish the initial TCP three-way handshake 💔

Aben's experiment recorded a failure rate of between 9% and 20% of all 6to4 connection attempts 🫠 Huston's experiment recorded between 9% and 19% of all 6to4 clients. In Huston's, it was also noticed that between 65% to 80% of the 6to4 clients who failed to connect over 6to4 could still connect over IPv4. The rest didn't make any IPv4 connection attempt at all, successful or not, using the mapped IPv4 address as a source address. The server recorded zero connection attempts using embedded RFC 1918 IPv4 addresses 🙈

There are a few theories for why this 6to4 connection failure happens 🧐 The first is that private IPv4 addresses get embedded in the 6to4 address, which makes the return path for the 6to4 tunnel infeasible. The second is that local filters and firewalls drop incoming IP packets that use IP protocol 41. If the first one were the main culprit, you'd expect a big chunk of the failed 6to4 connections to use embedded IPv4 addresses from the private use (RFC 1918) ranges, which goes against RFC 3056, or from addresses that aren't announced in the Internet's IPv4 inter-domain routing table. Huston's experiments didn't see either of those showing up in any real volume 🤷‍♀️

The conditions were also switched up. The return 6to4 tunnel used either the dual-stack server's native IPv4 source address or an IPv4 source address of 192.88.99.1. The 6to4 connection failure rate didn't change between those two setups 🤔 Other operators did report big problems when replying from the native address, though, and those were caused by stateful firewalls at the user site. Since the server used its own 6to4 relay for the return path, the only difference in the IP packet itself between the successful IPv4 connections and the failed 6to4 connections was the IP protocol number. It was 6 (TCP) for the successful IPv4 connections and 41 (IPv6 payload) for the failed 6to4 connections 👀 So the inference is that one likely reason for the high 6to4 connection failure rate is local filters close to the end user that block incoming packets with protocol 41. In some cases, stateful firewalls make it worse if the source address isn't 192.88.99.1 💅

In a dual-stack setup, this failure rate was basically hidden because the client could recover and connect over IPv4 instead 🦋 The only effect on the client was a delay of between 7 and 20 seconds while the client's system timed out on the 6to4 connection attempts (see [EYEBALLS-IPV6]). Ngl that's a long wait 😩

Now, this experience and further analysis show that Anycast 6to4 has these specific operational problems:

  1. Outbound Black Hole: 192.88.99.1 doesn't generate 'destination unreachable' even though packets sent to that address are actually dropped 🕳️ This can happen because of routing or firewall configuration, or even because the relay those packets reach has an ACL that discards them.

This class of problem happens because the user's ISP accepts a route to 192.88.99.0/24 even though that route doesn't go anywhere useful. Either the user site or its ISP is dropping outbound protocol 41 traffic, or the upstream operator won't accept incoming 6to4 packets from the user's ISP. The latter is superficially compatible with the design of Router 6to4, which the RFC 3056 calls "unwilling to relay." But simply announcing a route to 192.88.99.0/24 in IPv4, combined with the behavior described in RFC 3068, amounts to announcing a default route for IPv6 to every 6to4 site that receives the IPv4 route. That goes against the assumptions of RFC 3056 🚫

For users, this means their IPv6 stack thinks it has 6to4 connectivity, but all outgoing IPv6 packets are actually black-holed. How common this is is hard to measure, since those IPv6 packets can never be observed from the outside 👻

  1. Inbound Black Hole: Here, 6to4 packets sent to 192.88.99.1 are correctly delivered to a 6to4 relay and reply packets come back, but they get dropped by an inbound protocol 41 filter 😤 From the user's point of view, it's the same as the previous case: IPv6 is a black hole. Lots of enterprise networks are believed to be set up this way. Server operators on IPv6 can spot these connection attempts as SYN packets from addresses in 2002::/16 followed by no response to the resulting SYN/ACK. Based on the experiments above, this looks like a significant problem in practice 📉

This problem gets 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; and packets from the relay may be subject to IPv4 ingress filtering. If the protocol 41 filter is stateless, 6to4 will never succeed. If it's stateful, the firewall drops inbound packets from addresses that haven't been seen in outbound traffic on the same port. In that case, 6to4 only succeeds if the packets are sourced from 192.88.99.1. If the relay is subject to ingress filtering, only packets from its native IPv4 address can get through. So there are 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.
  1. No Return Relay: If the Outbound Black Hole problem doesn't happen, meaning the outgoing packet does reach the intended native IPv6 destination, the target system sends a reply packet to 2002:c000:2aa::123 in our example above. Then 2002::/16 may or may not be routed successfully. If it isn't routed, the packet gets dropped (hopefully with 'destination unreachable') 🤞 According to RFC 3056, an unwilling relay "MUST NOT advertise any 2002:: routing prefix into the native IPv6 domain," so if this prefix is advertised, the relay must relay packets regardless of source and destination. The catch is that in practice, some relays reject packets they should relay, based on their IPv6 source address 😵

Whether the native IPv6 destination has no route to 2002::/16 or ends up with a route to an unwilling relay, the result is the same: all return IPv6 packets get black-holed. There's no direct evidence of how common this is, but it definitely happens in practice 🥲

  1. Large RTT: If none of the above three problems apply, and a two-way path does exist between a 6to4 host and a native host, the round-trip time can be quite large and variable 🐢 That's because the paths to the two relays are unmanaged and may be complex. Overloaded relays might also cause highly variable RTT.
  2. PMTUD Failure: A common link MTU size on the Internet today is 1500 bytes. But when using 6to4, the path MTU is smaller than that because of the encapsulation header. So a 6to4 client will normally see a link MTU under 1500, while a native IPv6 server sees 1500 📦 It's been observed that Path MTU Discovery (PMTUD) doesn't always work, and that can lead to connectivity failures. Even if a TCP SYN/ACK exchange works, TCP packets with full-size payloads may just get lost. This problem is apparently made worse in some cases when the TCP Maximum Segment Size (MSS) negotiation mechanism fails [RFC2923]. These failures are confusing even for an informed user 😭 A standard 'ping' from the client to the server will succeed, since it generates small packets, and the successful SYN/ACK exchange can be traced. Also, the failure may happen on some paths but not others, so a user might be able to fetch web pages from one site but only ping another.

There's also a problem if 6to4 is enabled on a router and it advertises the resulting prefix on a LAN, but doesn't also advertise a smaller MTU. In that case, TCP MSS negotiation will definitely fail 💀

  1. Reverse DNS Failure: A 6to4-addressed host typically won't have a reverse DNS delegation. If reverse DNS is used as a pseudo-security check, it will fail 🙅‍♀️
  2. Bogus Address Failure: By design, 6to4 doesn't work and won't activate itself if the available V4ADDR is a private address [RFC1918]. But it also won't work if the available V4ADDR is a "bogon," meaning a global address that the operator is using as a private address. A common case is a legacy wireless network using 1.1.1.0/24 as if it were a private address. In that case, 6to4 assumes it's connected to the global Internet, but there's definitely no working return path 🫣

This failure mode also happens if an ISP runs a Carrier Grade NAT [CGN] between its customers and the Internet, and uses global public address space as if it were private space to do it.

  1. Faulty 6to4 Implementations: It's been reported that some 6to4 implementations try to activate themselves even when the available IPv4 address is an RFC 1918 address. That's in direct contradiction to RFC 3056, and it produces exactly the same failure mode as Bogus Address Failure. It's of course outside the ISP's control 🙄
  2. Difficult Fault Diagnosis: All of the failure modes above create a problem of their own: really difficult fault diagnosis 🕵️‍♀️ This is especially true if the only symptom a user reports is slow access to web pages, caused by a long timeout before falling back to IPv4. Tracking down Anycast routing problems and PMTUD failures is particularly hard 😮‍💨

The practical damage from those problems is real, even though they aren't universal. Anycast 6to4 works fine for plenty of people. Still, measurements show a fraction of 1% of attempted connections to dual-stack content servers fail [Anderson]. That sounds tiny, but only a small share of client hosts try 6to4 at all, and up to 20% of those hit one of the failure modes above. It may look like a small number, but it adds up to a big financial hit for content providers 💸. Users who get stuck with slow fallback to IPv4 [EYEBALLS-IPV6] also end up calling help desks, and those calls cost money too 📞😩.

There's another weird side effect 🙈. Observations at the University of Southampton, from Tim Chown and James Morse, along with reports from other sites, show that rogue Router Advertisements [RFC6104] often carry a 2002::/16 prefix. The culprit seems to be devices acting as local IPv6 routers or connection-sharing boxes that send Router Advertisement (RA) messages out the wrong interface. A device like that, if it gets IPv6 connectivity through an upstream link to the Internet, should only send its RA messages on the downstream link, to the nodes it's meant to share the connection with. Sending them upstream messes with every other IPv6 host on that link 😤. If 6to4 routing is on by default on a device that acts this way, those rogue RA messages will carry a 2002::/16 prefix, no doubt about it 💅.

4. Advisory Guidelines ✨

There are several kinds of operators who end up in the Anycast 6to4 picture, whether they signed up for it or not 🫠. If things go sideways, they all suffer. So there's a clear incentive for each of them to take the right action, as described below 🎀.

This document avoids formal normative language, because it is highly unlikely that the guidelines apply universally. Each operator will make its own decisions about which of the following guidelines are useful in its specific scenario 💜.

4.1. Vendor Issues

Even though this document is mainly aimed at operators, there are some steps that implementers and vendors of 6to4 should take 🛠️.

  1. Some vendors of routers, including customer premises equipment, have not only added support for 6to4 to their products, but have turned it on by default. This is bad practice. Enabling 6to4 should always be a conscious decision made by the user 🙅‍♀️. Lots of the problems above only happen because 6to4 got deployed by accident.
  2. Host operating systems should likewise not enable Anycast 6to4 by default. It should always be up to the user to switch it on 🔘.
  3. Any 6to4 implementation that tries to activate itself when the available IPv4 address is an RFC 1918 address is faulty and needs to be updated 🚩.
  4. 6to4 implementations should adopt updated IETF recommendations on address selection [RFC3484-REVISE] 🧭.
  5. 6to4 relay implementations must carefully follow Section 3.2 of [RFC4213] to make sure MTU issues are handled correctly 📏.
  6. 6to4 router or connection-sharing implementations must avoid issuing rogue RAs [RFC6104]. Also, 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) 🌙.

4.2. Consumer ISPs, and Enterprise Networks, That Do Not Support IPv6 in Any Way 🙃

4.2.1. Anycast Address Availability

To cut down on the damage from Anycast 6to4 that users are probably turning on without knowing it, and the resulting unhappy users and help-desk calls 😭, these ISPs should check the following in sequence:

  1. Does the ISP have a route to 192.88.99.1? (This means an explicit route, or knowledge that the default upstream provider has an explicit route. A default route doesn't count! 🙅)
  2. If so, is it functional and stable?
  3. If so, is the ping time reasonably short?
  4. If so, does the relay willingly accept 6to4 traffic from the ISP's IPv4 prefixes? (Note that this is an administrative as well as a technical question. Is the relay's operator willing to accept the traffic? 🤔)

Unless the answer to all these questions is 'yes', the operator should consider blocking the route to 192.88.99.1 and generating an IPv4 'destination unreachable' message. This may cause some 6to4 implementations to fall back to IPv4 more quickly. There is little operational experience with this, however 🤷‍♀️.

Some implementations also do some form of 6to4 relay qualification 🔍. For example, one host implementation (Windows) tests the protocol 41 reachability by sending an ICMPv6 echo request with Hop Limit = 1 to the relay, expecting a response or Hop Limit exceeded error back. If there's no response at all, the 6to4 relay doesn't work, so 6to4 gets turned off [Savola] 🔌.

A more constructive move for an ISP like this is to find a transit provider that's actually willing to offer outbound 6to4 relay service. That way, the answer to each of the questions above is positive 🌟.

4.2.2. Protocol 41

ISPs in this class should always allow protocol 41 through their networks and firewalls. This isn't just a nice-to-have, it's a necessary condition for 6to4 to work at all. It also lets users who want a configured IPv6 tunnel service use one 🚇.

Some operators, especially enterprise networks, quietly block protocol 41 for security reasons 🔒. Doing this on its own is bad practice, since it adds to the problem and hurts any users who are knowingly or unknowingly trying to run 6to4 😬. The strategic fix is to deploy native IPv6, which makes protocol 41 redundant ✨. In the short term, experimentation could be encouraged by allowing protocol 41 for certain users while returning the appropriate ICMP responses mentioned above. Unfortunately, if none of this gets done, the 6to4 problem can't be solved 💀.

Blocking protocol 41 silently on its own doesn't fix anything. It just makes things worse for the people actually trying to use 6to4 🚫.

4.2.3. IPv4 Prefix Issues

Operators should never use "bogon" address space, like the example 1.1.1.0/24, for customers 🙅‍♀️. IPv4 exhaustion means all of those addresses are likely to be in real use soon. (Also, see [RFC6269].) An operator that can't drop this practice right away should make sure 192.88.99.1 generates an IPv4 'destination unreachable'. Someone has suggested running a dummy 6to4 relay at that address that always returns an ICMPv6 'destination unreachable' as a 6to4 packet. However, these techniques aren't very effective, since most current end-user 6to4 implementations will ignore them 🫥.

If an operator is giving customers legitimate global addresses (neither RFC 1918 nor bogon addresses), and is also running Carrier Grade NAT (Large Scale NAT) between that address space and the global address space of the Internet, then 6to4 can't work properly 🧱. An operator like that should also take care to return 'destination unreachable' for 6to4 traffic. Alternatively, they could offer untranslated address space to the customers concerned 🎁.

4.2.4. DNS Issues

A customer who is intentionally using 6to4 may also need to create AAAA records, and the operator should be able to support this, even if the DNS service itself runs exclusively over IPv4 📇. Still, customers should be advised to think carefully about whether their 6to4 service is reliable enough for this 🤔.

In principle, operators could offer reverse DNS support for 6to4 users [RFC5158], although this isn't straightforward for domestic customers 🏠.

4.2.5. Rogue Router Advertisements

Plot twist 🌀: operators in this category should consider whether they need to defend themselves against rogue IPv6 RA messages [RFC6105]. These messages can come from devices trying to act as 6to4 routers, and they can confuse any user devices that have IPv6 enabled by default 😵‍💫. The IETF Source Address Validation Improvement (SAVI) working group is designing measures that will eventually help 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. That will definitively remove rogue RA packets 🧹.

4.2.6. Planning for IPv6 Deployment

Enterprise operators with complete administrative control of all end systems may choose to disable 6to4 on those systems as an integral part of their IPv6 deployment plan 🗺️.

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 before native IPv6 deployment 🪜. The routing guidelines in Section 4.4 would apply. However, offering genuine IPv6 service to interested customers, even if it's tunneled, would generally be a better first step 💖.

4.3. Consumer ISPs, and Enterprise Networks, That Do Support IPv6 🌸

Once an operator supports IPv6 service, whether it's experimental or in production, it's almost certain that users will get better results with that service than with 6to4 🚀. So these operators are encouraged to tell their users to disable 6to4, and they should not create DNS records for any 6to4 addresses 📵.

An operator like this may automatically fall into one of the following two categories (transit provider or content provider), so the guidelines in Sections 4.4 or 4.5 will apply instead 🔀.

Operators in this category should make sure that no routers are unintentionally or by default set up as active 6to4 relays. Unmanaged 6to4 relays will cause problems 🚨.

Operators in this category should consider whether they need to defend themselves against rogue RA messages with an RA Guard solution [RFC6105]. If RA Guard isn't 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 IETF Source Address Validation Improvement (SAVI) working group's measures will help with this problem too ✨.

4.4. Transit ISPs and Internet Exchange Points 🦋

okay so we're assuming transit ISPs already have IPv6 connectivity 🌐 and to keep Anycast 6to4 from wrecking all their client networks, it is strongly recommended that each of them runs an Anycast 6to4 relay service 💅 bonus: they get to terminate the 6to4 IPv4 packets and then forward the decapsulated IPv6 traffic however they like, aka their own policy 👑 without this, they'd just blindly forward all that encapsulated IPv6 traffic over to a competitor who does run a relay 💀

most modern Internet Exchange Points don't offer IP layer services anymore, but an Internet exchange point (IXP) could decide to run an Anycast 6to4 relay service for its customers 🧚 if it does, it should follow the recommendations in this section ✨

routing to this service is giving critical importance 🚨 so it has to be managed super carefully:

  1. The IPv4 prefix 192.88.99.0/24 must be announced only towards client IPv4 networks whose outbound 6to4 packets will be accepted. 🎀
  2. The IPv6 prefix 2002::/16 must be announced towards native IPv6. The relay must accept all traffic towards 2002::/16 that reaches it, so the scope reached by this announcement should be carefully planned 🗺️ it must reach all client IPv6 networks of the transit ISP. If it reaches a wider scope, the relay will be offering a free ride to non-clients 😭
  3. As discussed in item 2 of Section 3, the choice of IPv4 source address used when the relay sends 6to4 packets back towards a 6to4 user is important 🫶 the best choice is likely to be 192.88.99.1, not the relay's unicast IPv4 address, unless ingress filtering is an issue. This is to avoid failure if the user is behind a stateful firewall 🛡️
  4. The relay should be capable of responding correctly to ICMPv6 echo requests encapsulated in IPv4 protocol 41, typically with outer destination address 192.88.99.1 and inner destination address 2002:c058:6301::. (As noted previously, some 6to4 hosts 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 case, but operators cannot rely on this behavior. 🙈)
  5. Protocol 41 must not be filtered in any IPv4 network or firewalls. 🚫
  6. As a matter of general practice, which is essential for 6to4 to work well, IPv6 PMTUD must be possible, which means that ICMPv6 must not be blocked anywhere [RFC4890] 🌸 this also requires that the relay has a sufficiently high ICMP error generation threshold. For a busy relay, a typical default rate limit of 100 packets per second is too slow. On a busy relay, 1000 pps or more might be needed. If ICMPv6 "Packet Too Big" error messages are rate limited, users will experience PMTUD failure 💔
  7. The relay must have adequate performance, and since load prediction is extremely hard 🥲 it must be possible to scale it up or, perhaps better, to replicate it as needed. Since the relay process is stateless, any reasonable method of load sharing between multiple relays will do. ⭐
  8. Of course, the relay must be connected directly to global IPv4 space, with no NAT. 🌈

operators in this category should make sure that no routers are unintentionally or by default set up as active 6to4 relays 🙅‍♀️ unmanaged 6to4 relays will be a source of problems, bestie 😤

4.5. Content Providers and Their ISPs 💜

we're assuming content providers and their ISPs have IPv6 connectivity, and that the servers are dual stacked 🧠 this 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's a need to avoid the situation where a client host, configured with Anycast 6to4, succeeds in sending an IPv6 packet to the server, but the 6to4 return path fails as described above 😩 to avoid this, there must be a locally positioned 6to4 relay. Large content providers are 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 relay. As noted in the previous section, the corresponding route advertisement must be carefully scoped, since any traffic that arrives for 2002::/16 must be relayed 🚦

such a relay may be dedicated entirely to return traffic, in which case, it need not respond to the 6to4 anycast address 🦋

nevertheless, it seems wisest to ensure that when the relay sends 6to4 packets back towards a 6to4 user, they should have 192.88.99.1 as their IPv4 source address (not the relay's unicast IPv4 address). As noted above, this is to avoid problems if the user is behind a stateful firewall that drops UDP packets from addresses that have not been seen in outbound traffic 🛡️ however, it is also necessary that 192.88.99.1 is not blocked by upstream ingress filtering -- this needs to be tested 🧪

without careful engineering, there is nothing to make the return path as short as possible 🏃‍♀️ it is highly desirable to arrange the scope of 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 border. Care should be taken about shooting off advertisements for 2002::/16 into BGP4; they will become traffic magnets 🧲 if every ISP with content provider customers operates a relay, there will be no need for any of them to be advertised beyond each ISP's own customers ✨

protocol 41 must not be filtered in the ISP's IPv4 network or firewalls. If the relays are placed outside the content provider's firewall, the latter may filter protocol 41 if desired 🔥

the relay must have adequate performance, and since load prediction is extremely hard 😵‍💫 it must be possible to scale it up or, perhaps better, to replicate it as needed. Since the relay process is stateless, any reasonable method of load sharing between multiple relays will do 💅

the relay must of course be connected directly to global IPv4 space, with no NAT 🌍

an option is to embed the relay function directly in the content server or first hop router. This is straightforward, since it can be achieved by enabling a local 6to4 interface, and using 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 found at [Huston-b]. However, in this case protocol 41 must be allowed by the firewalls 🧚

content providers who do embed the relay function in this way could, in theory, accept inbound 6to4 traffic as well. This is highly unadvisable since, according to the rules of 6to4, they would then have to relay traffic for other IPv6 destinations, too. So they 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 access should be native, and advertising a 6to4 address might well lead to unicast reverse path forwarding (uRPF) [RFC3704] ingress filtering problems 🙅‍♀️💖

to avoid the path MTU problem described above, content servers should also set their IPv6 MTU to a safe value. From experience, 1280 bytes (the minimum allowed for IPv6) is recommended; again, see [Huston-b] 🎀

of course, ICMPv6 "Packet Too Big" must not be blocked or rate-limited anywhere [RFC4890] 🫧

reverse DNS delegations are highly unlikely to exist for 6to4 clients, and are by no means universal for other IPv6 clients. Content providers (and, in fact, all service providers) should not rely on them as a pseudo-security check for IPv6 clients 🙈

operators and content providers should make sure that no routers are unintentionally or by default set up as active 6to4 relays. Unmanaged 6to4 relays will be a source of problems 😤

5. Tunnels Managed by ISPs 🌷

there are various ways, such as tunnel brokers [RFC3053], 6rd [RFC5969], and Layer 2 Tunneling Protocol version 2 (L2TPv2) hub-and-spoke [RFC5571], by which Internet Service Providers can provide tunneled IPv6 service to subscribers in a managed way 🎁 in these, the subscriber will acquire an IPv6 prefix under a normal provider-based global IPv6 prefix. Most of the issues described for 6to4 do not arise in these scenarios. However, for IPv6-in-IPv4 tunnels used by clients behind a firewall, it is essential that IPv4 protocol 41 is not blocked 🔐

as a matter of general practice, IPv6 PMTUD must be possible, which means that ICMPv6 "Packet Too Big" must not be blocked or rate-limited anywhere [RFC4890] 💫

6. Security Considerations 🛡️💀

there is a general discussion of security issues for IPv6-in-IPv4 tunnels in [RFC6169], and [TUNNEL-LOOPS] discusses possible malicious loops 😈 [RFC3964] specifically discusses 6to4 security. In summary, tunnels create a challenge for many common security mechanisms, simply because a potentially suspect packet is encapsulated inside a harmless outer packet 🎭 all these considerations apply to the automatic mechanisms discussed in this document. However, it should be noted that if an operator provides well-managed servers and relays for 6to4, non-encapsulated IPv6 packets will pass through well-defined points (the native IPv6 interfaces of those servers and relays) at which security mechanisms may be applied 🔒 this is a genuinely big deal, so keep it in mind 👑

a blanket recommendation to block protocol 41 is not compatible with mitigating the 6to4 problems described in this document. 🚨 blocking it wholesale isn't the fix, bestie 🙅‍♀️

7. Acknowledgements 🫶

useful comments and contributions were made by Emile Aben, Mikael Abrahamsson, Tore Anderson, Hermin Anggawijaya, Jack Bates, Cameron Byrne, Tim Chown, Remi Despres, Jason Fesler, Wes George, Philip Homburg, Ray Hunter, Geoff Huston, Eric Kline, Victor Kuarsingh, Martin Levy, David Malone, Alexey Melnikov, Martin Millnert, Keith Moore, Gabi Nakibly, Michael Newbery, Phil Pennock, Pekka Savola, Mark Smith, Nathan Ward, James Woodyatt, and others 💖 the whole squad showed up for this one 🌈

8. References 📚

8.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.

8.2. Informative References 📚✨

okay bestie, this is the reading list! 🦋 These are the extra sources the spec points to, so you can go deeper whenever you want. Here they all are, every detail intact 💅

[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/>.

[CGN] Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., and H. Ashida, "Common requirements for Carrier Grade NAT (CGN)", Work in Progress, July 2011.

[DNSWHITE] Livingood, J., "IPv6 AAAA DNS Whitelisting Implications", Work in Progress, June 2011.

[EYEBALLS-IPV6] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Trending Towards Success with Dual-Stack Hosts", Work in Progress, October 2010.

[HISTORIC] Troan, O., "Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status", Work in Progress, June 2011.

[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>.

[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.

[RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 2923, September 2000.

[RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 Tunnel Broker", RFC 3053, January 2001.

[RFC3484-REVISE] Matsumoto, A., Kato, J., Fujisaki, T., and T. Chown, "Update to RFC 3484 Default Address Selection for IPv6", Work in Progress, July 2011.

[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.

[RFC3964] Savola, P. and C. Patel, "Security Considerations for 6to4", RFC 3964, December 2004.

[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 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 ICMPv6 Messages in Firewalls", RFC 4890, May 2007.

[RFC5158] Huston, G., "6to4 Reverse DNS Delegation Specification", RFC 5158, March 2008.

[RFC5571] Storer, B., Pignataro, C., Dos Santos, M., Stevant, B., Toutain, L., and J. Tremblay, "Softwire Hub and Spoke Deployment Framework with Layer Two Tunneling Protocol Version 2 (L2TPv2)", RFC 5571, June 2009.

[RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification", RFC 5969, August 2010.

[RFC6104] Chown, T. and S. Venaas, "Rogue IPv6 Router Advertisement Problem Statement", RFC 6104, February 2011.

[RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, February 2011.

[RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security Concerns with IP Tunneling", RFC 6169, April 2011.

[RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. Roberts, "Issues with IP Address Sharing", RFC 6269, June 2011.

[Savola] Savola, P., "Observations of IPv6 Traffic on a 6to4 Relay", ACM SIGCOMM CCR 35 (1) 23-28, 2006.

[TUNNEL-LOOPS] Nakibly, G. and F. Templin, "Routing Loop Attack using IPv6 Automatic Tunnels: Problem Statement and Proposed Mitigations", Work in Progress, May 2011.

Author's Address 🎀

The author of this one, Brian Carpenter, can be reached at the details below 💖

Brian Carpenter
Department of Computer Science
University of Auckland
PB 92019
Auckland, 1142
New Zealand

EMail: brian.e.carpenter@gmail.com
📦 where this page comes from