Keyed IPv6 Tunnel
Extracted elements (22)
By using unique IPv6 addresses to identify each Ethernet attachment circuit, processing of the L2TPv3 Session ID can be bypassed upon receipt since each tunnel has one and only one associated session. This enables better ECMP load balancing (unique source/destination IPv6 address pairs per tunnel) and finer-grained routing protocol control compared to the traditional approach of using a loopback address with multiple sessions.
The 64-bit cookie size is the largest permitted in RFC 3931 and is mandated (not optional) in this specification. This is a deliberate change from RFC 3931's optional variable-length cookie, made to ensure sufficient protection against spoofing and brute-force blind insertion attacks at the cost of constraining interoperability to RFC 3931 implementations that support 64-bit cookies.
Routers implementing L2TPv3 per RFC 3931 can interoperate with keyed IPv6 tunnel routers by being configured with multiple L2TPv3 tunnels with one session per tunnel. Interoperability is constrained to RFC 3931 implementations that support a 64-bit cookie. For two-stage resolution platforms (IPv6 Address + Session ID), explicit configuration of Session ID to any non-zero value is supported.
All packets MUST carry the 64-bit L2TPv3 cookie field. The cookie MUST be 64 bits long to provide sufficient protection against spoofing and brute-force blind insertion attacks. Cookie values SHOULD be randomly selected.
Any service-delimiting IEEE 802.1Q or IEEE 802.1ad VLAN IDs (S-tag, C-tag, or S-tag+C-tag tuple) are treated with local significance and MUST NOT be forwarded over the IPv6 L2TPv3 tunnel.
Cookies are asymmetric: local and remote endpoints may send different cookie values and SHOULD do so.
It is RECOMMENDED that Ethernet OAM as defined in IEEE 802.1ag and/or ITU-T Y.1731 be enabled for keyed IP tunnels, since OAM at the tunnel layer cannot detect failures in Ethernet service processing at the ingress/egress router or on the attachment circuit.
It is RECOMMENDED that routers implement IPv6 Path MTU Discovery (RFC 1981) to confirm that the path has sufficient MTU for a maximum-length Ethernet frame plus encapsulation overhead. It is NOT RECOMMENDED to enable IPv6 fragmentation (RFC 2460 Section 4.5) for keyed IP tunnels.
Local IPv6 addresses identifying L2TPv3 tunnels SHOULD NOT be assigned from connected IPv6 subnets facing towards remote tunnel endpoints, as this would create an IPv6 Neighbor Discovery cache entry per tunnel on the next-hop router. It is RECOMMENDED that such addresses be assigned from dedicated subnets used only for tunnel endpoints.
Routers MAY implement L2TPv3 fragmentation (RFC 4623 Section 5). In the absence of a control plane, fragmentation (if implemented) SHOULD be configured locally on a per-tunnel basis, and fragmentation configuration MUST be consistent between the two tunnel endpoints.
Support for retaining the FCS and for receiving packets with a retained FCS is OPTIONAL and, if present, MUST be configurable. In the absence of a control plane, FCS retention configuration MUST be consistent between the two tunnel endpoints. Any router configured to retain FCS MUST do so for all frames on that tunnel.
The cookie value MUST be able to be changed at any time without dropping legitimate tunneled packets: the receiver MUST be configurable to accept two discrete cookies for a single tunnel simultaneously, holding both 'old' and 'new' values during transition. Cookie values SHOULD be changed periodically by the management plane.
The ingress router encapsulates the entire Ethernet frame without the preamble and FCS per RFC 4719. The L2-specific sublayer MAY be carried if VCCV and/or frame sequencing is required, but SHOULD NOT be carried otherwise.
The management plane MUST NOT configure a keyed IP tunnel unless both endpoints support the 64-bit cookie, since mandating a 64-bit cookie is a change from the optional variable-length cookie of RFC 3931.
OAM for keyed IPv6 tunnels uses three CFM/ETH-CC configurations: an Up MEP at the tunnel endpoint for connectivity verification across the tunnel, a Down MEP for connectivity verification across the local attachment circuit, and a MIP at the tunnel endpoint for intermediate connectivity verification.
The IPv6 Traffic Class may be set by the ingress router to ensure correct PHB treatment and QoS disposition. The IPv6 Flow Label may be set to indicate a packet flow that must not be reordered, enabling finer-grained ECMP load balancing beyond per-circuit granularity.
The keyed IPv6 tunnel uses a static 1:1 mapping without a control plane: the management plane creates a one-to-one mapping between the access-side L2 attachment circuit (identified by port ID or port ID + VLAN ID) and the network-side IPv6 address (which also identifies the tunnel endpoint). There is a single session per tunnel.
The optional L2-Specific Sublayer (32 bits) is present when VCCV and/or frame sequencing is required. Bit 0 (V-bit) set indicates VCCV messages; bit 1 (S-bit) set indicates a valid frame sequence number in bits 8-31.
The Session ID field (32 bits) is included for RFC 3931 compatibility. For static 1:1 mapping, it SHOULD be ignored upon receipt at endpoints supporting one-stage resolution, and it is RECOMMENDED to be set to all ones (0xFFFFFFFF). The Session ID of zero MUST NOT be used as it is reserved for L2TP control messages. The Session ID is unidirectional.
Keyed IPv6 encapsulation provides traffic separation via separate 128-bit IPv6 addresses identifying tunnel endpoints. The mandatory 64-bit cookie provides an additional check ensuring arriving packets are intended for the identified tunnel, protecting against inadvertent frame leakage into customer VPNs as documented in RFC 3931 Section 8.2.
The 64-bit L2TPv3 cookie provides protection against blind packet-spoofing attacks that could violate VPN traffic separation. However, it provides no protection against a sophisticated man-in-the-middle attacker who can sniff and correlate captured data. The cookie MUST NOT be regarded as a substitute for IPsec when operating over open or untrusted networks.
The full encapsulation consists of: IPv6 Header (320 bits), Session ID (32 bits), Cookie bits 0:31 (32 bits), Cookie bits 32:63 (32 bits), optional L2-Specific Sublayer (32 bits), and variable-length Ethernet payload. The IPv6 Next Header field is set to 0x73 to indicate L2TPv3. No UDP header is carried.