Basic Transition Mechanisms for IPv6 Hosts and Routers
obsoletes
- rfc-2893 — Transition Mechanisms for IPv6 Hosts and Routers
Extracted elements (26)
Automatic tunneling and IPv4-compatible addresses from RFC 2893 were removed in this document because RFC 3056 provides a more general mechanism that gives each node with a global IPv4 address an entire /48 IPv6 prefix. The document was simplified to retain only widely-deployed mechanisms.
Configured tunnels are modeled as single-hop from the IPv6 perspective, making the tunnel opaque and invisible to traceroute. This is implemented by decrementing the IPv6 hop limit by 1 at both the encapsulator and decapsulator when forwarding, identical to forwarding on any other datalink.
Treating the tunnel as a 64KB MTU interface is prohibited for three reasons: (1) it causes unnecessary fragmentation, reducing performance because the loss unit becomes smaller than the retransmission unit; (2) IPv4 fragments inside the tunnel must be reassembled at router tunnel endpoints, consuming memory and resources; (3) the encapsulator cannot verify the decapsulator's ability to defragment or handle large MRUs.
Dynamic tunnel MTU determination is subject to IPv4 path MTU blackholes when ICMPv4 'packet too big' messages are dropped by firewalls or not generated by routers. When this occurs, at least two packet drops happen before MTU discovery converges: one for the encapsulator to learn the tunnel IPv4 MTU, and another for the IPv6 source to learn the reduced IPv6 MTU.
IPv6/IPv4 nodes must provide resolver libraries capable of handling both A and AAAA DNS records. The lookup of A vs. AAAA records is independent of whether DNS packets travel over IPv4 or IPv6, and DNS servers need not know the IP version capabilities of the requesting node.
After decapsulation, the node MUST silently discard packets with invalid IPv6 source addresses, including all multicast addresses (FF00::/8), the loopback address (::1), IPv4-compatible addresses (::/96 excluding ::/128 for DAD), and IPv4-mapped addresses (::ffff:0:0/96).
Configured tunnel implementations MUST accept and respond to NUD probe packets. Neighbor Discovery packets on tunnel links SHOULD NOT include Source or Target Link Layer Address options; receivers MUST silently ignore such options if present, consistent with point-to-point link behavior.
Configured tunnel interfaces MUST have link-local addresses because they are IPv6 interfaces over the IPv4 link layer. The interface identifier may be based on the 32-bit IPv4 address of an underlying interface, prepended by zeros, with the U/L bit set to zero.
DNS resolver libraries on IPv6/IPv4 nodes MUST be capable of handling both AAAA and A records. If an application has not specified a preference, or has requested both, the resolver library MUST NOT filter out any records.
It SHOULD be possible to administratively specify the source IPv4 address of a tunnel to ensure the encapsulator uses the correct address that the decapsulator expects, particularly when multiple addresses, interfaces, or frequently-changing routes are present.
The decapsulator MUST support an IPv6 MRU of at least the maximum of 1500 bytes and the largest IPv6 interface MTU on the decapsulator, and MUST be capable of reassembling an IPv4 packet up to the same size threshold.
The decapsulator MUST verify that the IPv4 source address of an incoming protocol-41 packet matches the configured tunnel endpoint address before further processing. Packets with non-matching source addresses MUST be discarded and an ICMP message SHOULD NOT be generated.
The encapsulator MUST NOT treat the tunnel as an interface with an MTU of 64 kilobytes. It must instead use either the fixed static MTU or optional dynamic MTU determination based on the IPv4 path MTU to the tunnel endpoint.
When reconstructing the IPv6 packet after decapsulation, the length MUST be determined from the IPv6 payload length field rather than from the IPv4 packet length, because the IPv4 packet may be padded to a length larger than the IPv6 packet plus the IPv4 header.
When using the static tunnel MTU, the Don't Fragment (DF) bit MUST NOT be set in the encapsulating IPv4 header, meaning the encapsulator will not receive ICMPv4 'packet too big' messages for its encapsulated packets.
With static tunnel MTU, the MTU MUST be between 1280 and 1480 bytes inclusive, and SHOULD default to 1280 bytes. If the default is not 1280 bytes, the implementation MUST provide a configurable knob to set the MTU value.
Configured tunneling encapsulates IPv6 packets within IPv4 headers to carry them over IPv4 routing infrastructure. Tunnel endpoints are determined by explicit configuration; all tunnels are assumed bidirectional and provide a virtual point-to-point link to the IPv6 layer.
Dual IP layer (dual stack) provides complete implementations of both IPv4 and IPv6 in a single host or router. IPv6/IPv4 nodes may operate with IPv4 only, IPv6 only, or both stacks enabled, and MAY provide a configuration switch to disable either stack.
Dynamic tunnel MTU determination is OPTIONAL; the encapsulator tracks IPv4 path MTU using RFC 1191 and sets the effective IPv6 MTU to (IPv4 path MTU - 20). If the path MTU would yield an IPv6 MTU below 1280 bytes, the encapsulator uses IPv4 fragmentation for packets up to 1280 bytes and sends ICMPv6 'packet too big' (MTU=1280) for larger ones.
ICMPv4 'packet too big' errors from routers inside the tunnel are handled per IPv4 Path MTU Discovery (RFC 1191) and the resulting path MTU is recorded. For other ICMPv4 errors, if sufficient payload bytes are available, the encapsulator MAY generate an ICMPv6 'unreachable / address unreachable' message to the originating IPv6 source. ICMPv4 error handling applies only to dynamic MTU determination.
If the residual source-spoofing threats of configured tunneling are considered significant, a scheme with authentication such as IPsec (RFC 2401, preferred) or GRE with a pre-configured key (RFC 2890) should be used instead. Shorter tunnels are preferable to longer ones to limit exposure.
Tunnels are more vulnerable than physical links to attacks exploiting Hop Count 255 and link-local address assumptions used by Neighbor Discovery, because any Internet attacker can inject an IPv6-in-IPv4 packet to the tunnel decapsulator. Mitigations include verifying IPv4 source address, discarding invalid IPv6 source addresses, and performing IPv4 and IPv6 ingress filtering.
When dropping packets due to IPv4 source address mismatch, implementations MUST discard silently and SHOULD NOT generate ICMP errors, to avoid revealing the tunnel's existence. If the implementation normally sends ICMP protocol-unreachable for unknown protocols, that same response MAY be sent for protocol-41 to ensure consistent behavior and resist probing.
Without ingress filtering at the decapsulator, an attacker can inject a packet with a spoofed inner IPv6 source address such that Bob receives a packet appearing to come from Alice. Even with full IPv4 and IPv6 ingress filtering deployed across all routers, the spoofed tunneled packet is not filtered. The mitigation is to accept encapsulated packets only from the explicitly configured tunnel source address.
IPv6-in-IPv4 encapsulation sets IPv4 Protocol to 41 (assigned payload type for IPv6), Version to 4, IHL to 5 (no options), Total Length to IPv6 payload length plus 60 bytes, and Source/Destination Address to the configured tunnel endpoint addresses. The DF bit is set or cleared per the applicable MTU scheme.
When forming a tunnel link-local address from an IPv4 address, the 128-bit address is FE80::/64 followed by 32 zero bits followed by the 32-bit IPv4 address. The U/L bit is zero, indicating the identifier is not globally unique.