2.3.7 Layer Two Tunneling Protocol Extensions (l2tpext)

NOTE: This charter is a snapshot of the 46th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 22-Oct-99


W. Mark Townsley <townsley@cisco.com>

Internet Area Director(s):

Thomas Narten <narten@raleigh.ibm.com>
Erik Nordmark <nordmark@eng.sun.com>

Internet Area Advisor:

Thomas Narten <narten@raleigh.ibm.com>

Mailing Lists:

General Discussion:l2tp@ipsec.org
To Subscribe: l2tp-request@ipsec.org
Archive: http://www.ipsec.org/email/l2tp/

Description of Working Group:

The Layer 2 Tunneling Protocol (L2TP, RFC 2661) is a protocol for tunneling PPP (RFC 1661) sessions over various network types. The group will provide a forum for discussion and development of extensions to L2TP, and actively advance the L2TP base protocol to Internet Standard.

The group will:

Define and advance standard MIB for L2TP management.

Produce documents describing how L2TP operates over link types other than IP (e.g., ATM, Frame Relay, etc.)

Identify and define specific parameters and modes of IPsec in order to aid interoperability when IPsec is used to secure L2TP traffic.

Define and review the definition of any additional IETF AVPs which are of interest to the group.

Goals and Milestones:

Oct 99


Advance L2TP MIB to Proposed Standard

Feb 00


Advance L2TP Security to Proposed Standard

May 00


Advance L2TP over ATM and Frame Relay to Proposed Standard

Sep 00


Advance L2TP to Draft Standard


No Request For Comments

Current Meeting Report

L2TP Extensions WG Washintgon D.C. Thursday, November 11, 1999
64 people signed the blue sheet.

Chaired by Mark Townsley (townsley@cisco.com)
Reported by Matt Holdrege (holdrege@lucent.com)

Welcome to l2tpext and Agenda Bashing
The agenda was accepted.

Anita Freeman <anfreema@cisco.com>
PPP/L2TP/IPsec Workshop announcement
VPN Interoperability workshop announcement. Jan 9th 14th in San Diego.

Bill Palter <palter.ietf@zev.net>
L2TP Alternate Data Channel
The author asked if anyone cared if this draft was moved forward as an RFC.
No comments. It was asked if there are any implementations of this protocol. There were none.

Bill Palter <palter.ietf@zev.net>
L2TP Session Info
The author asked if anyone cared if this draft was moved forward as an RFC.
No comments.

This was compared with extending the bearer types and using bearer capability. We discussed the pros and cons without a clear resolution

It was asked if this would affect dial-out. Could this draft be expanded to have the LNS choose the dial-out bearer type. This will be discussed
further on the list.

Andy Valencia <vandys@cisco.com>
L2TP Header Compression

The objective is to reduce the overhead within the header. It's not VJ-style, it's stateless and it's based on raw IP (not UDP). So you effectively have a 1 byte header. But that would only support one PPP session per tunnel. This model is generally for voluntary tunneling where there generally be only one session per tunnel.

There aren't much savings in the general sense. There are some benefits for asymmetric data rate applications (TCP ack ratio). But RTP streams (as used in VoIP) over IPCP over L2TP may benefit significantly.

It was mentioned that this scheme would be very useful when using L2TP over ATM over ADSL.

Glen Zorn <gwz@acm.org>
Securing L2TP Using IP Security

Goals are interoperability. Specify parameters and modes for IPsec when used with L2TP. Advancement to proposed standard by February 2000. Proposed extensions to L2TP will not be considered. It is hoped this draft can be tested at the VPN bakeoff in January.

L2TP has little or no security on it's own and it relies on Ipsec. The requirements are that we MUST be able to provide integrity and replay protections for control packets. You SHOULD provide confidentiality for control packets. You MUST provide integrity and replay protection of data packets. You SHOULD provide confidentiality for data packets.

MUST implement ESP for control packets, and consequently you MUST implement ESP for securing L2TP data packets. All mandated cipher suites including NULL encryption MUST be supported.

IKE is a MUST.

Stateful PPP compression and encryption should be avoided over an IP network that might have packet loss. But they may work over a non-IP network such as ATM or Frame Relay.

MUST use transport mode rather than tunnel mode. We need to take this to the list to see if anyone has a reason for using tunnel mode.

L2TP needs to be able to now whether there is an IPsec SA protecting a given L2TP tunnel (thus, API's need to exist between L2TP and IPsec).

There are many details in this draft that need to be sorted out between the L2TP WG and the IPsec WG. This will be taken to the list.

Yves T'Joens <yves.tjoens@alcatel.be>
L2TP ATM access network extensions
Complications during tunnel establishment phase were discussed.

The author will propose a solution on the list.

This draft maintains the broadband bearer bits. Introduces calling/called sub address handling

Practically rewritten to match RFC 2661.

The author was concerned about ATM devices which do not support F4 and F5 cells and cannot report a PVC down. He has proposed an LNS echo mechanism. People in the room said that both ATM and PPP have standards such as F4 and F5 cells and PPP LQM and they should be used. This issue will be taken to the list.

Paolo Crivellari Paolo.Crivellari@alcatel.be Implementation feedback on L2TP over ATM Mark asked Paolo to work with Andy regarding L2TP header compression.

Further work will take place on the list to cover efficiency considerations, header considerations, and specific recommendations for usage of L2TP over ATM.

W. Mark Townlsey <townsley@cisco.com>
Status of l2tpext drafts
L2TP over Frame Relay and ATM are still being worked on.
The diff-serv and MPLS drafts need to see if they are still alive.
Mobile PPP may move to the L2TP group.
Secure Remote Access will be removed.
The L2TP link info draft will be resubmitted into the L2TP WG. Draft authors that need IANA numbers will apply for them as soon as possible.


None received.