Generic Packet Tunneling in IPv6 Specification
Extracted elements (24)
IPv6 tunnels are modeled as 'single-hop virtual links': the entry-point sets the tunnel IPv6 hop limit independently of the original packet hop limit, so intermediate hops inside the tunnel are invisible to the original packet. This hides the true tunnel hop count from original packet sources.
Recursive encapsulation risk is highest when inner tunnels share identical exit-points and when the route to the exit-point is a default route, because default routing cannot discriminate based on destination and will re-encapsulate indefinitely in a routing loop. Route-to-node provides minimum risk; default route provides maximum risk.
The Tunnel Encapsulation Limit option is carried in a Destination Options extension header (examined only by the tunnel entry-point, an intentional exception to IPv6 rules) rather than a Hop-by-Hop header, to avoid imposing processing overhead and latency at every IPv6 node along the tunnel path.
When a fragmented tunnel packet is addressed to an exit-point identified by an anycast address, successful reassembly requires all fragments to arrive at the same anycast node, which is not guaranteed by anycast routing; this is a known limitation analogous to the problem with fragmented IPv6 packets to anycast destinations.
A tunnel entry-point node, as the originator of tunnel IPv6 packets, must support fragmentation of those tunnel packets. A tunnel intermediate node must not fragment a packet undergoing forwarding.
A tunnel entry-point node is required to examine entering packets for a Tunnel Encapsulation Limit option. If the option is found with a limit value of zero, the packet must be discarded and an ICMPv6 Parameter Problem (Code 0, Pointer to the third octet of the TEL option) must be sent to the packet's source.
A tunnel exit-point node receiving fragmented tunnel packets must reassemble all fragments into a complete tunnel packet before processing the encapsulated original packet.
During encapsulation, the original packet header's hop field must be decremented by one: IPv6 original packet hop limit is decremented by 1, and IPv4 original packet TTL is decremented by 1, before prepending the tunnel IPv6 header.
If a Tunnel Encapsulation Limit option with a non-zero value is found in a packet entering a tunnel, the entry-point must include a new TEL option in the encapsulating headers with a limit value one less than the found value.
If no Tunnel Encapsulation Limit option is present in the entering packet and an encapsulation limit is configured for the tunnel, the entry-point must include a TEL option with the configured limit value. If no limit is configured, no TEL option is included.
Loopback encapsulation — where an entry-point encapsulates tunnel packets originated from and destined to itself — must be avoided. Implementations should reject configurations where entry-point and exit-point addresses belong to the same node.
The tunnel entry-point node must relay ICMP error messages received from inside the tunnel to the source of the original packet, translating tunnel ICMP codes (hop limit exceeded, unreachable, parameter problem) into appropriate ICMP messages for the original packet's protocol.
The tunnel hop limit should be set by the entry-point node independently of the original packet hop limit, using a pre-configured value; the recommended default for hosts is the Neighbor Discovery advertised hop limit, and for routers the IPv6 default (64).
To avoid routing-loop recursive encapsulation, two mechanisms must be used together: decrementing the original packet hop limit at each forwarding/encapsulation operation, and decrementing the tunnel encapsulation limit at each nested encapsulation.
When an IPv4 original packet exceeds the tunnel MTU and the DF bit is SET, the entry-point node must discard the packet and return an ICMP Destination Unreachable / Packet Too Big message. If the DF bit is CLEAR, the entry-point encapsulates and then fragments the resulting tunnel packet.
When an IPv6 original packet exceeds the tunnel MTU and its size is larger than the IPv6 minimum link MTU, the entry-point node must discard it and send an ICMPv6 Packet Too Big message to the original source with MTU = max(tunnel MTU, IPv6 minimum link MTU). If the original is at or below the minimum link MTU, the entry-point encapsulates and then fragments the resulting tunnel packet.
For IPv4 original packets, tunnel ICMP errors (hop limit exceeded, unreachable, parameter problem) are mapped to ICMP Type 3 Code 1 (host unreachable); Packet Too Big is mapped to ICMP Type 3 Code 4 with the MTU field adjusted by subtracting tunnel header length.
For IPv6 original packets, tunnel ICMP errors (hop limit exceeded, unreachable node, parameter problem) are reported to the original source as ICMPv6 Type 1 (Unreachable) Code 3 (address unreachable); Packet Too Big is reported as Type 2 Code 0 with the MTU field adjusted by subtracting the tunnel header length.
IPv6 tunnel state variables configured at the entry-point node include: entry-point address (source), exit-point address (destination), hop limit (default 64 for routers), traffic class (default 0 or copy from original), flow label (default 0), encapsulation limit (recommended default 4), and tunnel MTU (Path MTU minus tunnel header size).
The Tunnel Encapsulation Limit (TEL) option (Option Type decimal 4, Opt Data Len 1) carries an 8-bit unsigned integer specifying how many additional levels of encapsulation are permitted beyond the current one. The two high-order bits (00) indicate 'skip if unrecognized'; the third bit (0) indicates data does not change en route.
The tunnel IPv6 header is a standard IPv6 header with Version=6; Traffic Class set to original packet value or pre-configured value; Flow Label defaulting to zero; Payload Length = original packet length plus extension header lengths; Hop Limit set to configured tunnel value; Source = entry-point node address; Destination = exit-point node address.
An IPv6 tunnel can be secured by applying IPsec (AH per RFC 2402, or ESP per RFC 2406) between the entry-point and exit-point nodes per the security architecture of RFC 2401. Security headers are prepended as part of the tunnel headers and processed at the exit-point; there is no dependency between tunnel-level and payload-level security.
The IPv6 Tunnel Protocol Engine defines two roles: upper-layer (decapsulation input from link-layer or nested tunnel, output to upper-layer or nested tunnel) and link-layer (encapsulation input from upper-layer, link, or nested tunnel; output of original packets post-decapsulation to upper-layer, link, or nested tunnel). Paths #1-8 govern packet flow through encapsulation and decapsulation stages.
The Destination Options extension header carrying only the TEL option occupies exactly 8 octets: Next Header (1), Hdr Ext Len=0 (1), Opt Type=4 (1), Opt Data Len=1 (1), Tun Encap Lim (1), PadN Opt Type=1 (1), PadN Opt Data Len=1 (1), padding byte 0x00 (1).