Keyed IPv6 Tunnel

Approval announcement
Draft of message to be sent after approval:

From: The IESG <>
To: "IETF-Announce" <>
Cc:,,,,,, "The IESG" <>,
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

A URL of this Internet Draft is:

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
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.


   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."