6to4

6to4 is an Internet transition mechanism for migrating from Internet Protocol version 4 (IPv4) to version 6 (IPv6) and a system that allows IPv6 packets to be transmitted over an IPv4 network (generally the IPv4 Internet) without the need to configure explicit tunnels. Special relay servers are also in place that allow 6to4 networks to communicate with native IPv6 networks.

6to4 is especially relevant during the initial phases of deployment to full, native IPv6 connectivity, since IPv6 is not required on nodes between the host and the destination. However, it is intended only as a transition mechanism and is not meant to be used permanently.

6to4 may be used by an individual host, or by a local IPv6 network. When used by a host, it must have a global IPv4 address connected, and the host is responsible for encapsulation of outgoing IPv6 packets and decapsulation of incoming 6to4 packets. If the host is configured to forward packets for other clients, often a local network, it is then a router.

Most IPv6 networks use autoconfiguration, which requires the last 64 bits of the address for the host. The first 64 bits are the IPv6 prefix. The first 16 bits of the prefix are always 2002:, the next 32 bits are the IPv4 address, and the last 16 bits of the prefix are available for addressing multiple IPv6 subnets behind the same 6to4 router. Since the IPv6 hosts using autoconfiguration already have determined the unique 64 bit host portion of their address, they must simply wait for a Router Advertisement indicating the first 64 bits of prefix to have a complete IPv6 address. A 6to4 router will know to send an encapsulated packet directly over IPv4 if the first 16 bits are 2002, using the next 32 as the destination, or otherwise send the packet to a well-known relay server, which has access to native IPv6.

6to4 does not facilitate interoperation between IPv4-only hosts and IPv6-only hosts (for that, see NAT64). 6to4 is simply a transparent mechanism used as a transport layer between IPv6 nodes.

Due to the high levels of misconfigured hosts and poor performance observed, an advisory about how 6to4 should be deployed was published in August 2011. Due to unsolvable operational problems using the 6to4 anycast prefix, that part of the standard was deprecated in 2015.

How 6to4 works

6to4

6to4 performs three functions:

• Assigns a block of IPv6 address space to any host or network that has a global IPv4 address.
• Encapsulates IPv6 packets inside IPv4 packets for transmission over an IPv4 network using 6in4.
• Routes traffic between 6to4 and "native" IPv6 networks.

Address block allocation

6to4 address

For any 32-bit global IPv4 address that is assigned to a host, a 48-bit 6to4 IPv6 prefix can be constructed for use by that host (and if applicable the network behind it) by appending the IPv4 address to 2002::/16.

For example, the global IPv4 address 192.0.2.4 has the corresponding 6to4 prefix 2002:c000:0204::/48. This gives a prefix length of 48 bits, which leaves room for a 16-bit subnet field and 64 bit host addresses within the subnets.

Any IPv6 address that begins with the 2002::/16 prefix (in other words, any address with the first two octets of 2002 hexadecimal) is known as a 6to4 address, as opposed to a native IPv6 address which does not systematically use transition technologies.

Note that using a reserved IPv4 address, such as those provided by RFC 1918, is undefined, since these networks are disallowed from being routed on the public Internet. For example, using 192.168.1.1 as the router's WAN address would be invalid since a return packet would not be able to determine the destination IPv4 address of the actual sender.

Encapsulation and transmission

6to4 embeds an IPv6 packet in the payload portion of an IPv4 packet with protocol type 41. To send an IPv6 packet over an IPv4 network to a 6to4 destination address, an IPv4 header with protocol type 41 is prepended to the IPv6 packet. The IPv4 destination address for the prepended packet header is derived from the IPv6 destination address of the inner packet (which is in the format of a 6to4 address), by extracting the 32 bits immediately following the IPv6 destination address's 2002::/16 prefix. The IPv4 source address in the prepended packet header is the IPv4 address of the host or router which is sending the packet over IPv4. The resulting IPv4 packet is then routed to its IPv4 destination address just like any other IPv4 packet.

Routing between 6to4 and native IPv6

To allow hosts and networks using 6to4 addresses to exchange traffic with hosts using "native" IPv6 addresses, "relay routers" have been established. A relay router connects to an IPv4 network and an IPv6 network. 6to4 packets arriving on an IPv4 interface will have their IPv6 payloads routed to the IPv6 network, while packets arriving on the IPv6 interface with a destination address prefix of 2002::/16 will be encapsulated and forwarded over the IPv4 network.

There is a difference between a "relay router" and a "border router" (also known as a "6to4 border router"). A 6to4 border router is an IPv6 router supporting a 6to4 pseudo-interface. It is normally the border router between an IPv6 site and a wide-area IPv4 network, where the IPv6 site uses 2002::/16 co-related to the IPv4 address used later on. On the other hand, a "relay router" is a 6to4 router configured to support transit routing between 6to4 addresses and pure native IPv6 addresses.

To allow a 6to4 host to communicate with the native IPv6 Internet, it must have its IPv6 default gateway set to a 6to4 address which contains the IPv4 address of a 6to4 relay router. To avoid the need for users to set this up manually, the anycast address 192.88.99.1 used to be allocated. It could be assigned to any number of 6to4 relay routers, so that IPv4 routing would take care of routing the encapsulated IPv6 packets to the one closest-by for forwarding onto IPv6 Internet. Due to unsolvable operational problems, this use has been deprecated.

Packets from the IPv6 Internet to 6to4 systems must be sent to a 6to4 relay router by normal IPv6 routing methods. The specification states that such relay routers must only advertise 2002::/16 and not subdivisions of it to prevent IPv4 routes polluting the routing tables of IPv6 routers. From here they can then be sent over the IPv4 Internet to the destination.

For a 6to4 host to have fast and reliable connectivity with a host natively using the IPv6 Internet, both the 6to4 host and the native IPv6 host must have a route to a fast, reliable and correctly configured relay server. The 6to4 host's ISP can ensure that outgoing packets go to such a relay, but they have no control over the relay used for the responses from the native IPv6 host. A variant called IPv6 rapid deployment ("6rd") uses the same basic principles as 6to4 but uses a relay operated by the 6rd user's ISP for traffic in both directions. To achieve this an address block allocated by the user's ISP is used instead of 2002::/16.

Reverse DNS delegation

When a site using 6to4 has a fixed global IPv4 address, its 6to4 IPv6 prefix is also fixed. It is then possible to request reverse DNS delegation for an individual 6to4 48-bits prefix inside the 2.0.0.2.ip6.arpa DNS zone from the Number Resource Organization at 6to4.nro.net. The process is entirely automatic.

Security considerations

According to RFC 3964, 6to4 routers and relays should ensure that:

• either or both the source and destination addresses of any encapsulated packet is within the 6to4 IPv6 prefix 2002::/16,
• if the source IPv6 address is a 6to4 IPv6 address, its corresponding 6to4 router IPv4 address matches the IPv4 source address in the IPv4 encapsulation header,
• similarly, if the destination IPv6 address is a 6to4 IPv6 address, its corresponding 6to4 router IPv4 address matches the IPv4 destination address in the IPv4 encapsulation header,
• any embedded 6to4 router IPv4 address is global unicast.

Software support

Microsoft Windows

6to4 has been default disabled since the Anniversary Update. It is no longer being actively supported and might be removed in a future release.

See also

• IPv6 rapid deployment
• Teredo tunneling

Further reading

• B. Carpenter & K. Moore. Connection of IPv6 Domains via IPv4 Clouds. RFC 3056, February 2001.
• R. Gilligan & E. Nordmark. Transition Mechanisms for IPv6 Hosts and Routers. RFC 2893, August 2000.
• P. Savola & C. Patel. Security Considerations for 6to4. RFC 3964, December 2004.
• B. Carpenter. Advisory Guidelines for 6to4 Deployment. RFC 6343, August 2011.
• O. Troan, B. Carpenter, Ed. Deprecating the Anycast Prefix for 6to4 Relay Routers. RFC 7526, May 2015.

External links

• "Routing IPv6 over IPv4" article by Cisco Archived 2015-12-03 at the Wayback Machine
• IPv6 6to4 tunnel configuration example