Transition Mechanisms for IPv6 Hosts and Routers
obsoleted by
- rfc-4213 — Basic Transition Mechanisms for IPv6 Hosts and Routers
obsoletes
- rfc-1933 — Transition Mechanisms for IPv6 Hosts and Routers
Extracted elements (27)
Automatic tunneling was designed to eliminate explicit tunnel configuration by embedding the IPv4 tunnel endpoint address in the IPv6 destination address itself (IPv4-compatible format). This is only applicable for host-to-host and router-to-host tunnels where destination and tunnel endpoint are identical; configured tunneling is required when tunneling to an intermediate router.
The 'default raw send' mode from RFC 1933, which allowed nodes to send packets directly to IPv4-compatible destinations on the same datalink without encapsulation, was removed because implementation experience showed the added complexity was not justified by the minimal header overhead savings.
The single-hop tunnel model was chosen to make tunnels invisible to the network; the tunnel appears as a single link-layer hop regardless of how many IPv4 hops lie inside. This simplifies the IPv6 topology visible to routing protocols and diagnostic tools.
A6/AAAA records for a node should not be added to the DNS until the address is assigned, configured on the interface, and the interface is connected to the IPv6 infrastructure. Adding AAAA records for a node not reachable via IPv6 causes external nodes to attempt IPv6 connections and suffer TCP timeout delays of several minutes before falling back to IPv4.
A decapsulated packet MUST NOT be forwarded unless the node has been explicitly configured to accept encapsulated packets from the given IPv4 source address. This restriction prevents tunneling from being used as a mechanism to circumvent ingress filtering.
After decapsulation, the node SHOULD silently discard packets with invalid IPv4 source addresses (multicast, broadcast, 0.0.0.0, 127.0.0.1) applying martian and ingress filtering rules. Packets with invalid IPv6 source addresses (multicast, unspecified, loopback, or IPv4-compatible addresses embedding an invalid IPv4 address) SHOULD also be silently discarded.
Both configured and automatic tunnel interfaces MUST have IPv6 link-local addresses. The Interface Identifier SHOULD be the 32-bit IPv4 address zero-padded on the left to 64 bits, forming a link-local address with the FE80::/64 prefix.
DNS resolver libraries on IPv6/IPv4 nodes MUST be capable of handling both A6/AAAA and A records. An implementation MUST allow the application to control whether DNS result filtering (returning only IPv4, only IPv6, or both addresses) takes place.
For automatic tunneling, the decapsulating node MUST verify that encapsulated packets are acceptable before forwarding. Since automatic tunnels always tunnel directly to the destination, any packet received over an automatic tunnel SHOULD NOT be forwarded.
For bidirectional configured tunnels, the node MUST accept and respond to NUD probe packets and SHOULD send NUD probes to detect tunnel failure. Neighbor Discovery packets on tunnel links SHOULD NOT include SLLA or TLLA options, and any received SLLA/TLLA options MUST be silently ignored.
For source address selection, it is RECOMMENDED that when the destination is IPv4-compatible, the node use the IPv4-compatible source address corresponding to the outgoing IPv4 interface; when the destination is IPv6-native, the node use the IPv6-native address of the outgoing interface. This ensures symmetric traffic paths.
IPv4 layer fragmentation SHOULD be avoided due to the performance penalty of a loss unit smaller than the retransmission unit. When not applying IPv4 Path MTU Discovery across the tunnel, the Don't Fragment bit MUST NOT be set in the encapsulating IPv4 header.
The automatic tunneling module MUST NOT send to IPv4 broadcast or multicast destinations. It MUST drop all IPv6 packets destined to IPv4-compatible addresses where the embedded IPv4 part is broadcast, multicast, 0.0.0.0, or the loopback address 127.0.0.1.
The decapsulating node MUST be capable of reassembling an IPv4 packet that is 1300 bytes (1280 bytes of IPv6 plus the 20-byte IPv4 header), ensuring minimum-size IPv6 packets encapsulated in IPv4 can always be reassembled.
The decapsulating node MUST verify that the tunnel source address is acceptable before forwarding decapsulated packets. For unidirectional configured tunnels, a list of acceptable source IPv4 address prefixes MUST be configured and MUST default to empty, requiring explicit configuration before any forwarding occurs.
A default configured tunnel to an IPv4 anycast address allows multiple border routers to advertise reachability to the same IPv4 address, providing redundancy. IPv4 routing delivers traffic to the closest router; care is needed to prevent different IPv4 fragments from arriving at different routers for reassembly.
An IPv6/IPv4 node implements both IPv4 and IPv6 stacks and may operate in three modes: IPv4-only (IPv6 stack disabled), IPv6-only (IPv4 stack disabled), or dual-stack (both enabled). Nodes MAY provide a configuration switch to disable either stack.
In automatic tunneling, the IPv4 encapsulating destination is the low-order 32 bits of the IPv4-compatible IPv6 destination address. A static routing entry for 0:0:0:0:0:0/96 directs all IPv4-compatible destinations to a pseudo-interface driver that performs automatic encapsulation, requiring no per-tunnel configuration.
In configured tunneling, the tunnel endpoint IPv4 address is stored as explicit configuration on the encapsulating node. Tunnels may be unidirectional or bidirectional; bidirectional configured tunnels behave as virtual point-to-point links. Packet selection is typically done via routing table prefix matching.
IPv4 ICMP 'packet too big' errors received by the encapsulating node are processed per IPv4 Path MTU Discovery; the resulting path MTU is recorded and used by the IPv6 layer. Other ICMP error types MAY be used to generate IPv6 ICMP errors back to the originating IPv6 node if sufficient encapsulated header data is present.
IPv6-over-IPv4 tunnels are modeled as single-hop: the IPv6 hop limit is decremented by exactly 1 when an IPv6 packet traverses the entire tunnel. This hides the tunnel from traceroute and other network diagnostic tools, making it opaque to users.
Tunnel MTU is the IPv4 path MTU minus 20 bytes. If this yields an IPv6 MTU below 1280 bytes, the tunnel presents a 1280-byte MTU and IPv4 fragmentation is used as necessary. The encapsulating node uses an algorithm to decide between sending an IPv6 ICMP 'packet too big' error and fragmenting at the IPv4 layer.
Tunneling can circumvent ingress filtering because the encapsulating node's IPv4 address appears as the source. This is mitigated by requiring decapsulating routers to only forward packets from explicitly configured acceptable IPv4 source addresses, and by prohibiting forwarding of automatically tunneled packets entirely.
An IPv4-compatible IPv6 address consists of a 96-bit all-zeros prefix (0:0:0:0:0:0) followed by a 32-bit IPv4 address in the low-order bits. This format is used exclusively by nodes supporting automatic tunneling to encode the tunnel endpoint address within the IPv6 destination address.
IPv6-over-IPv4 encapsulation prepends a 20-byte IPv4 header to the IPv6 datagram. The IPv4 Protocol field is set to 41 (assigned payload type for IPv6). The encapsulating IPv4 header has no options (IHL=5), ToS=0, and Total Length equal to the IPv6 payload length plus 60 bytes.
The encapsulating IPv4 header fields: Version=4, IHL=5, ToS=0, Total Length=IPv6 payload + 60 bytes, Protocol=41, Source Address=IPv4 address of outgoing interface, Destination Address=IPv4 tunnel endpoint. The Don't Fragment flag is set per the Path MTU algorithm in section 3.2.
The IPv6 link-local address for an IPv4 tunnel interface is formed as FE80::0000:0000:IPv4addr, where the 128-bit address is FE80 followed by 48 zero bits followed by the 32-bit IPv4 address. The U/L bit is zero, indicating the identifier is not globally unique.