2.3.9 Point-to-Point Protocol Extensions (pppext)

NOTE: This charter is a snapshot of the 43rd IETF Meeting in Orlando, Florida. It may now be out-of-date. Last Modified: 25-Nov-98

Chair(s):

Karl Fox <karl@ascend.com>

Internet Area Director(s):

Jeffrey Burgan <burgan@home.net>
Thomas Narten <narten@raleigh.ibm.com>

Internet Area Advisor:

Jeffrey Burgan <burgan@home.net>

Mailing Lists:

General Discussion:ietf-ppp@merit.edu
To Subscribe: ietf-ppp-request@merit.edu
Archive: ftp://merit.edu/pub/ietf-ppp-archive

Description of Working Group:

Note: A seperate list has been set up for L2TP discussions

L2TP Discussions:l2tp@zendo.com To Subscribe: l2tp-request@zendo.com Archive: http://bodhi.zendo.com/vandys/l2tp-mail

The Point-to-Point Protocol (PPP) was designed to encapsulate multiple protocols. IP was the only network layer protocol defined in the original documents. The working group is defining the use of other network layer protocols and options for PPP. The group will define the use of protocols including: bridging, ISO, DECNET (Phase IV and V), XNS, and others. In addition, it will define new PPP options for the existing protocol definitions, such as stronger authentication and encryption methods.

No Goals and Milestones
Internet-Drafts:

Request For Comments:

RFC

Status

Title

 

RFC1332

PS

The PPP Internet Protocol Control Protocol (IPCP)

RFC1378

PS

The PPP AppleTalk Control Protocol (ATCP)

RFC1377

PS

The PPP OSI Network Layer Control Protocol (OSINLCP)

RFC1472

PS

The Definitions of Managed Objects for the Security Protocols of the Point-to-Point Protocol

RFC1473

PS

The Definitions of Managed Objects for the IP Network Control Protocol of the Point-to-Point Protocol

RFC1471

PS

The Definitions of Managed Objects for the Link Control Protocol of the Point-to-Point Protocol

RFC1474

PS

The Definitions of Managed Objects for the Bridge Network Control Protocol of the Point-to-Point Protocol

RFC1553

PS

Compressing IPX Headers Over WAN Media (CIPX)

RFC1552

PS

The PPP Internetwork Packet Exchange Control Protocol (IPXCP)

RFC1547

 

Requirements for an Internet Standard Point-to-Point Protocol

RFC1570

PS

PPP LCP Extensions

RFC1598

PS

PPP in X.25

RFC1619

PS

PPP over SONET/SDH

RFC1618

PS

PPP over ISDN

RFC1638

PS

PPP Bridging Control Protocol (BCP)

RFC1663

PS

PPP Reliable Transmission

RFC1662

S

PPP in HDLC-like Framing

RFC1762

DS

The PPP DECnet Phase IV Control Protocol (DNCP)

RFC1764

PS

The PPP XNS IDP Control Protocol (XNSCP)

RFC1763

PS

The PPP Banyan Vines Control Protocol (BVCP)

RFC1973

PS

PPP in Frame Relay

RFC1968

PS

The PPP Encryption Control Protocol (ECP)

RFC1979

 

PPP Deflate Protocol

RFC1975

 

PPP Magnalink Variable Resource Compression

RFC1977

 

PPP BSD Compression Protocol

RFC1974

 

PPP Stac LZS Compression Protocol

RFC1967

 

PPP LZS-DCP Compression Protocol (LZS-DCP)

RFC1976

 

PPP for Data Compression in Data Circuit-Terminating Equipment (DCE)

RFC1963

 

PPP Serial Data Transport Protocol (SDTP)

RFC1990

DS

The PPP Multilink Protocol (MP)

RFC1989

DS

PPP Link Quality Monitoring

RFC1978

 

PPP Predictor Compression Protocol

RFC1993

 

PPP Gandalf FZA Compression Protocol

RFC1994

DS

PPP Challenge Handshake Authentication Protocol (CHAP)

RFC2043

PS

The PPP SNA Control Protocol (SNACP)

RFC2097

PS

The PPP NetBIOS Frames Control Protocol (NBFCP)

RFC2118

 

Microsoft Point-To-Point Compression (MPPC) Protocol

RFC2125

PS

The PPP Bandwidth Allocation Protocol (BAP) The PPP Bandwidth Allocation Control Protocol (BACP)

RFC2153

 

PPP Vendor Extensions

RFC2290

PS

Mobile-IPv4 Configuration Option for PPP IPCP

RFC2284

PS

PPP Extensible Authentication Protocol (EAP)

RFC2363

PS

PPP Over FUNI

RFC2364

PS

PPP over AAL5

RFC2419

PS

The PPP DES Encryption Protocol, Version 2 (DESE-bis)

RFC2420

PS

The PPP Triple-DES Encryption Protocol (3DESE)

RFC2433

 

Microsoft PPP CHAP Extensions

Current Meeting Report

PPPEXT WG
Dec. 7th, 1998

Meeting Chair Matt Holdrege - matt@ascend.com

Reported by Don Grosser - grosser@us.ibm.com

L2TP draft status - Mark Townsley

Mark read the following statement:

The Layer 2 Tunneling Protocol, which began 2 years ago as the merging of the L2F and PPTP specifications, is currently in its 12th state of Internet Draft revision. In March of this year, the Working Group requested that the 10th revision of L2TP be promoted to RFC Proposed Standard. To date, the Working Group is aware of over 20 independently developed, interoperable L2TP implementations. In reaction to substantial customer demand, several vendors have announced general availability of L2TP in their products and have begun the initial stages of widespread deployment. One could say with clear conscience that L2TP has been in a "de facto" Proposed Standard phase for many months.

The high level of endorsement for L2TP by the industry places additional weight on every decision to alter the specification as well as increased demands for an expeditious advancement through the IETF process. In fact, as time has marched forth, the L2TP specification has become less of a static proposal to base new implementations off of, and more of a report on the details of implementations have already been developed. The Editors consider the L2TP draft as the "source code" for which developers have created many L2TP implementations. As with any product which has been in widespread use in the field, every change made is applied with great scrutiny as each invariably run the risk of causing unintentional side affects. In our case, the side affects are the possible introduction of contradictions or ambiguities that may hinder interoperability of future L2TP implementations using the L2TP specification.

This state of affairs has created a setting that to the IESG has seemed rigid and closed minded. In fact, this behavior has been a simple effort to balance protection of both the installed base of implementations and hard-earned consensus that the Working Group had already achieved, together with the necessary changes required in order to move the official status of the document forward in a swift manner. It seems, however, that this hard-lined conservative approach has hindered the IETF process more than it helped.

Over the past 9 months, the Area Directors and IESG have made a total of 57 specific suggestions for alteration of the L2TP specification. With so many other items on its plate, the IESG must truly be commended for such a thorough review. These items have ranged from simple typos, to operational changes in protocol itself. 23 of the 57 items presented were incorporated into draft 11 and 12. The rest were resisted by the Editors on grounds that they were general misunderstandings, were not backward compatible with the multitude of existing implementations and did not provide enough benefit to outweigh the costs, or would require additional implementation experience in the field to properly address. The latter is something we argue could be taken care of during the Proposed Standard phase.

At the IESG's request, we recently re-evaluated the suggestions that were originally rejected or missed. Of these, 8 were still considered unnecessary and 8 were accepted with the necessary changes to the text applied. The final 18 items were each affiliated in one way or another with the optional flow control feature of L2TP. The Editors have been unable to reconcile each of these issues in a manner that we believe would not require additional review by the Working Group and another round of consensus attained. Therefore, it is the recommendation of the Editors that the portion of the L2TP specification that handles the optional Flow Control mechanism be isolated and moved to its own Internet Draft, leaving the base specification for approval by the IESG without this hindrance.

The purpose of this action is NOT to alter the L2TP protocol itself. The express intent is to enhance the clarity and readability of the L2TP specification, properly address all of the concerns of the IESG, and still allow for a swift promotion of the base specification to Proposed Standard. To this end, no new functionality to the new L2TP specification will be permitted during this phase, beyond any necessary items for the clean separation of the Flow Control capability. Of primary concern is that the new draft be backwards compatible to the previous specification, and thus to the many existing L2TP implementations that have already been deployed. Any proposed changes solely for increased clarity and readability will be graciously accepted and evaluated for inclusion into the new specification. However, please remember that when trying to improve the overall clarity of a document, removing words is often more effective than adding them. This "Less is More" principal will certainly apply here.

L2TP Link Extensions (Bill Palter/Mark Townsley)

L2TP MIB - Evan Caves

Framework for L2TP Message Extensions - Richard Shea

L2TP Dynamic Data Window Adjustment - Richard Shea

Mobile PPP - Mooi Choo Chuah/Don Grosser

L2TP over ATM - Yves

PPTP - Glenn Zorn

MPPE - Glenn Zorn

Day Two:
Session chair: Matt Holdrege
Reported by: Andy Malis

Mark Townsley announced that there is going to be an L2TP editing session immediately following this meeting.

Shahrukh Merchant (Cimaron) presented his PPP over SONET from STS-1 to STS-192 draft (draft-merchant-pppext-sonet-sdh-00.txt).

Purpose:

For STS1, STS-3c, and STS-12c, use HDLC per RFC 1662 and revised ANSI T1.105.02 or Revised G.707 for SONET mapping: C2 = 0x16, x^43 + 1 payload scrambling, FCS-16 is the default and FCS-32 is optional.

For STS-48c, the same as above, except that FCS-32 is the default (FCS-16 is not a defined option).

For STS-192C, he proposed moving from a byte-oriented HDLC to HDLC-32, a 32-bit oriented HDLC that uses 32-bit alignment in the SONET payload for easier implementation at 10 Gbps speeds. The HDLC-32 payload scrambling (X^29 + 1) prevents potential malicious bandwidth expansion. It supports FCS-32 only. His motivation for HDLC-32 is that byte-wise HDLC is extremely complex and hard to implement at STS-192c and faster speeds. The flag sequences are:

Flag0=E7 81 CA 34
Flag1=E7 81 CA 35
Flag2=E7 81 CA 36
Flag3=E7 81 CA 37

The escape sequence is Esc32=EB 8D C6 38

HDLC-32 uses four-octet flags as frame delimiters and as fill when idle. There are four defined 32-bit flag sequences and one escape sequence. The abort sequence is Esc32 + Flag0.

Additions he will made to the next version of the draft:

Next steps:

Chuck Benz from Nexabit suggested an intra-packet idle for under run situations for HDLC-32.

Shahrukh does not believe that Cimaron intends to patent HDLC-32. He will confirm that.

Andy Hebb said that it looks like you could send (worst case) up to an additional 6 bytes of overhead per frame (3 extra bytes of flag and at worst padding to a four-octet boundary) compared to byte-wide HDLC. Shahrukh added that the average was actually 4.5 bytes extra; however, this would be reduced relative to byte-wide HDLC by the fact that the presence of Escape sequences would be a negligible factor (vs. about 1% for byte-wide HDLC with random data) since the probability of needing escapes in the data goes down exponentially with word size, and packets are scrambled before HDLC-32 insertion, so scrambling will also prevent malicious insertion.

Matt Holdrege wrote a draft on Always On/Dynamic ISDN (draft-ietf-ppext-aodi-00.txt), and he asked for comments for the intent of moving it on the standards track. There are multiple interoperable implementations.

Anita Freeman announced two upcoming interoperability workshops on L2TP/IPsec, MS-Chapv2, MPPE and perhaps other protocols. Details will be sent to the pppext and ipsec email lists.

Slides

Mobile PPP
PPP over SONET from STS- 1 (STM- 0/ AU- 3) toSTS- 192c (STM- 64/ AU- 4- 64c)