Connection of IPv6 Domains via IPv4 Clouds
Extracted elements (28)
6to4 treats the global IPv4 network as a unicast point-to-point link layer, eliminating the need for explicit per-tunnel configuration. This was chosen to allow isolated IPv6 sites to communicate with minimal manual setup during the IPv4-to-IPv6 co-existence period, explicitly not as a permanent solution.
The 6to4 prefix format embeds V4ADDR directly in the NLA field of the IPv6 address, allowing the IPv4 destination to be derived mechanically from the IPv6 next-hop address with no routing table lookup or tunnel configuration in the IPv4 network.
The mechanism introduces no new entries in the IPv4 routing table and only one new entry (2002::/16) in the native IPv6 routing table, keeping the impact on global routing infrastructure minimal during transition.
A fragmented IPv4 topology (disjoint IPv4 network segments each served by separate relay routers with no cross-visibility) breaks 6to4 connectivity: sites on one segment cannot reach sites on the other because the 2002::/16 advertisements are mutually invisible. This scenario must be avoided.
Address selection rule for mixed environments: if one host has only a 6to4 address and the other has both 6to4 and native IPv6, the 6to4 address should be used for both. If both have both types, the default should be native IPv6, but the choice should be configurable.
IPv4 ICMP 'unreachable' messages returned to the 6to4 router for encapsulated packets cannot generally be translated into ICMPv6 messages for the originating IPv6 node, making the IPv4 cloud appear as an undiagnosable link layer for IPv6 operational purposes.
When co-existing with an IPv4 NAT, the 6to4 router and NAT must be combined; V4ADDR is the globally unique address of the NAT. Hosts more than one NAT hop from global address space must all use 2002:: addresses derived from the outermost NAT's global address.
6to4 prefixes more specific than 2002::/16 must not be propagated in native IPv6 routing. A 6to4 site with a native IPv6 connection MUST NOT advertise its 2002::/48 prefix on that connection, and all native IPv6 operators MUST filter out any 2002:: prefix advertisement longer than /16.
A relay router MUST advertise a route to 2002::/16 into the native IPv6 exterior routing domain, and MUST NOT advertise any longer 2002:: routing prefix on its native IPv6 interface.
A site with both 6to4 and native IPv6 interfaces that is unwilling to act as a relay MUST NOT advertise any 2002:: prefix into the native IPv6 domain and MUST NOT advertise any native IPv6 prefixes or a default IPv6 route into the 6to4 domain.
Any 6to4 traffic whose source or destination address embeds a V4ADDR that is not a global unicast address (e.g., RFC 1918, broadcast, multicast, loopback) MUST be silently discarded by both encapsulators and decapsulators.
Each site is RECOMMENDED to use only one IPv4 address per 6to4 router (the address on the external interface). Single-homed sites SHOULD use only one IPv4 address for 6to4 routing.
Every 6to4 router MUST implement the additional decapsulation rule for incoming IPv4 packets with Protocol 41: apply security checks, remove the IPv4 header, and submit the packet to local IPv6 routing.
Every 6to4 router MUST implement the additional sending rule: if the next-hop IPv6 address matches 2002::/16 and does not match a local site prefix, apply security checks, encapsulate in IPv4 with destination equal to the V4ADDR extracted from the next-hop address, and queue for IPv4 forwarding.
The 2002::/16 prefix MUST NOT be advertised into a 6to4 exterior routing domain, as doing so would attract all 6to4 traffic to the announcing site and cause a routing loop.
The 6to4 router SHOULD generate appropriate IPv6 prefix announcements (per stateless address autoconfiguration and neighbor discovery) for the site's 2002::/48 prefix.
The IPv4 address V4ADDR used to construct the 6to4 prefix MUST be duly allocated by an address registry and MUST NOT be a private address as defined in RFC 1918.
The IPv4 'do not fragment' bit SHOULD NOT be set in the encapsulating IPv4 header, so that intermediate IPv4 fragmentation can occur when the IPv6 MTU is too large for an intermediate subnet.
V4ADDR MUST be configured on the IPv4 interface carrying 6to4 traffic; this interface is logically treated as the 6to4 pseudo-interface.
A relay router is a 6to4 router that also has native IPv6 interfaces and is configured to transit traffic between 6to4 addresses and native IPv6 addresses. It participates in both IPv6 exterior routing (advertising 2002::/16) and the 6to4 exterior routing domain independently.
The 6to4 prefix is a /48 IPv6 prefix constructed as: Format Prefix 001 (3 bits), TLA 0x0002 (13 bits), V4ADDR (32 bits), yielding the abbreviated form 2002:V4ADDR::/48. Within the site it is used exactly like any other /48 prefix.
The 6to4 pseudo-interface is the logical IPv6 interface at the encapsulation/decapsulation point, where the link layer is the IPv4 unicast network. It may be implemented as a true interface or as a tunnel end-point.
The IANA permanently assigned one 13-bit IPv6 TLA identifier with numeric value 0x0002 under IPv6 Format Prefix 001 for the 6to4 scheme, yielding the well-known prefix 2002::/16. No further IANA assignments are required by this document.
A plausibility check SHOULD be applied: the encapsulating IPv4 source address should be consistent with the V4ADDR embedded in the encapsulated 2002:: source address. Exceptions must be configured for traffic from relay routers.
By default, 6to4 traffic is accepted from any IPv4 source that is otherwise permitted. If IPv6 spoofing is considered a greater risk than IPv4 spoofing, additional source-address filtering may be applied at the 6to4 router.
Implementing IPv6-level security is required even when IPv4 security is available, because IPv4 security does not protect IPv6 traffic once it leaves the 6to4 domain; conversely, redundant dual-layer encryption should be avoided for efficiency.
Packet processing at a 6to4 router has two states: (1) outbound — if next-hop matches 2002::/16 and is non-local, encapsulate in IPv4 and forward; (2) inbound — if IPv4 Protocol is 41, decapsulate and submit to IPv6 routing. Both transitions require a security check before processing.
IPv6 packets are encapsulated in IPv4 packets with Protocol field set to 41. The IPv4 header carries Source and Destination IPv4 addresses; the body contains the full IPv6 header and payload. Standard IPv4 TTL and IPv6 hop-limit fields are set independently.