Transition Mechanisms for IPv6 Hosts and Routers
obsoleted by
- rfc-2893 — Transition Mechanisms for IPv6 Hosts and Routers
Extracted elements (24)
A default configured tunnel can use an IPv4 anycast address as its endpoint, with multiple IPv6/IPv4 border routers advertising reachability to the same IPv4 address. This provides robustness because IPv4 routing automatically redirects traffic to another border router if one fails.
DNS resolver libraries on IPv6/IPv4 nodes have three options when both an AAAA record holding an IPv4-compatible address and an A record for the same host are found: return only the IPv6 address, only the IPv4 address, or both. The choice affects whether IPv6-encapsulated-in-IPv4 or native IPv4 traffic is generated, and implementations that do not support automatic tunneling should not return IPv4-compatible IPv6 addresses.
The encapsulating node should track IPv4 Path MTU across the tunnel using RFC 1191 Path MTU Discovery rather than treating the tunnel as a link with MTU 65515, because large-MTU treatment causes excess fragmentation and requires reassembly at tunnel endpoints (which is costly for router tunnels).
The single-hop tunnel model (decrementing hop limit by exactly 1 per tunnel traversal) intentionally hides the tunnel's internal structure from network diagnostic tools such as traceroute, making the tunnel opaque to users of the network.
IPv6/IPv4 nodes that support automatic tunneling generally should not return IPv4-compatible IPv6 addresses to applications when automatic tunneling is disabled or unsupported, because those destinations are only reachable via tunneling; implementations with tunneling enabled may elect to return only the IPv4-compatible IPv6 address rather than the IPv4 address.
Many older IPv4 routers return only 8 bytes beyond the IPv4 header in ICMP error messages, which is insufficient to include the IPv6 header address fields. More modern routers may return enough data to allow the encapsulating node to generate a corresponding IPv6 ICMP error back to the originating IPv6 node.
When an IPv4-compatible IPv6 address is assigned to a host supporting automatic tunneling, both an A record (low-order 32 bits) and an AAAA record (full IPv4-compatible IPv6 address) must be listed in DNS so that both IPv4-only and IPv6 resolvers can locate the host.
IPv6-over-IPv4 tunnels are modeled as single-hop: the IPv6 hop limit is decremented by 1 as if forwarding over any datalink, hiding the tunnel from diagnostic tools such as traceroute. The encapsulating IPv4 TTL is set in an implementation-dependent manner.
Packets sourced from or destined to the IPv4 loopback address must not be sent onto the network; implementations may treat ::127.0.0.1 as an IPv6 loopback address, and such packets should also remain entirely within the node.
The decapsulating node performs IPv4 reassembly before decapsulating the IPv6 packet so that all IPv6 options are preserved even if the encapsulating IPv4 packet was fragmented. The encapsulating IPv4 header is then discarded and the IPv6 packet processed normally.
When the IPv4 path MTU minus 20 bytes exceeds 576 bytes and the IPv6 packet exceeds that value, the encapsulating node MUST send an IPv6 ICMP 'packet too big' error with MTU = (IPv4 path MTU - 20) and drop the packet; otherwise it encapsulates and sets the Don't Fragment flag.
When the IPv4 path MTU minus 20 is less than or equal to 576 bytes and the IPv6 packet exceeds 576 bytes, an IPv6 ICMP 'packet too big' with MTU=576 is sent and the packet is dropped; for packets up to 576 bytes the DF flag must not be set, permitting IPv4 fragmentation along the path.
In automatic tunneling the tunnel endpoint is derived from the destination IPv6 packet's IPv4-compatible address: the low-order 32 bits are extracted and used as the IPv4 destination. A static routing table entry for prefix 0:0:0:0:0:0/96 directs all IPv4-compatible destinations to a pseudo-interface that performs automatic tunneling.
In configured tunneling the tunnel endpoint IPv4 address is stored in configuration information on the encapsulating node; routing table entries using prefix/mask matching direct IPv6 packets into specific tunnels identified by their configured endpoint address.
IPv4 ICMP 'packet too big' errors received by the encapsulating node are processed via IPv4 Path MTU Discovery (RFC 1191), and the resulting path MTU is used to determine whether to generate an IPv6 ICMP 'packet too big'. Other ICMP errors may be translated to IPv6 ICMP errors if the 'packet in error' field contains enough of the original IPv6 header.
IPv6/IPv4 nodes implement complete support for both IPv4 and IPv6, enabling direct interoperation with IPv4-only nodes via IPv4 packets and with IPv6 nodes via IPv6 packets. Three tunneling configurations are possible: no tunneling, configured tunneling only, or both configured and automatic tunneling.
IPv6/IPv4 nodes performing automatic tunneling may acquire IPv4-compatible IPv6 addresses by obtaining an IPv4 address via DHCP, BOOTP, RARP, or manual configuration, then prepending the 96-bit all-zeros prefix to construct the IPv4-compatible IPv6 address.
IPv6-over-IPv4 tunneling encapsulates IPv6 datagrams within IPv4 packets to carry them over IPv4 routing infrastructure. Four tunnel topologies are supported: router-to-router, host-to-router, host-to-host, and router-to-host.
On/off-link determination differs by address type: IPv4 addresses use the RFC 1122 netmask comparison algorithm; IPv4-compatible IPv6 addresses apply the same IPv4 netmask comparison to the low-order 32 bits; IPv6-only addresses use the IPv6 Neighbor Discovery mechanism.
IP protocol number 41 is assigned as the payload type for IPv6-in-IPv4 encapsulation. An IPv4 datagram with Protocol=41 addressed to a node's own IPv4 address is decapsulated by removing the IPv4 header and passing the inner IPv6 datagram to the IPv6 layer.
The document explicitly states that security issues are not discussed. No analysis of tunnel authentication, spoofing of encapsulated packets, or filtering of protocol-41 traffic is provided.
The default sending algorithm for IPv6/IPv4 nodes selects packet format based on (destination address type) × (on/off-link) × (IPv4 router present) × (IPv6 router present): IPv4 destinations use native IPv4; IPv4-compatible IPv6 destinations on-link use IPv6, off-link with IPv4 router use encapsulated IPv6/4, off-link with IPv6 router use native IPv6; IPv6-only destinations use native IPv6 or configured tunnel; otherwise destination is unreachable.
IPv4-compatible IPv6 addresses use a 96-bit all-zeros prefix (0:0:0:0:0:0) followed by a 32-bit IPv4 address in the low-order bits. The full 128-bit value serves as the node's IPv6 address while the embedded 32 bits serve as its IPv4 address.
The encapsulating IPv4 header for IPv6-in-IPv4 uses: Version=4, IHL=5 (no options), TOS=0, Total Length = IPv6 payload length + 60, Protocol=41, source = outgoing interface IPv4 address, destination = tunnel endpoint IPv4 address. DF and MF flags are set per the MTU algorithm.