Keyed IPv6 Tunnel
Draft of message to be sent after approval:
From: The IESG <email@example.com> To: "IETF-Announce" <firstname.lastname@example.org> Cc: email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, "The IESG" <email@example.com>, firstname.lastname@example.org Subject: Protocol Action: 'Keyed IPv6 Tunnel' to Proposed Standard (draft-ietf-l2tpext-keyed-ipv6-tunnel-07.txt) The IESG has approved the following document: - 'Keyed IPv6 Tunnel' (draft-ietf-l2tpext-keyed-ipv6-tunnel-07.txt) as Proposed Standard This document is the product of the Layer Two Tunneling Protocol Extensions Working Group. The IESG contact persons are Alvaro Retana, Alia Atlas and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-l2tpext-keyed-ipv6-tunnel/
Technical Summary This document describes a simple L2 Ethernet over IPv6 tunnel encapsulation with mandatory 64-bit cookie for connecting L2 Ethernet attachment circuits identified by IPv6 addresses. The encapsulation is based on L2TPv3 over IP. Implementing L2TPv3 over IPv6 [RFC2460] provides the opportunity to utilize unique IPv6 addresses to identify Ethernet attachment circuits directly, leveraging the key property that IPv6 offers, a vast number of unique IP addresses. In this case, processing of the L2TPv3 Session ID may be bypassed upon receipt as each tunnel has one and only one associated session. This local optimization does not hinder the ability to continue supporting the multiplexing of circuits via the Session ID on the same router for other L2TPv3 tunnels. Working Group Summary The WG process as it relates to this document has been smooth and without major controversies. One of the key goals of the WG has been to ensure compliance, compatibility and continued support of demultiplexing based on Session ID. Document Quality There are multiple interoperable implementations of the solution described in this document, among four major router vendors. These implementations are deployed and running in production. Further, there is additional interop done with other vendors, and implementations in Linux. Personnel Who is the Document Shepherd for this document? Carlos Pignataro Who is the Responsible Area Director? Deborah Brungard RFC Editor's Note: The last sentence of Section 5 needs to be deleted: "IP fragmentation issues for L2TPv3 are discussed in section 4.1.4 of RFC3931."