Point-to-Point Protocol Extensions (pppext)

NOTE: This charter is a snapshot of that in effect at the time of the 38th IETF Meeting in Memphis, Tennessee. It may now be out-of-date.

Chair(s): 

Karl Fox <karl@ascend.com>

Internet Area Director(s): 

Frank Kastenholz <kasten@ftp.com>
Jeffrey Burgan <jburgan@baynetworks.com>

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: 

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: 

· PPP Hewlett-Packard Packet-by-Packet Compression (HP PPC) Protocol 

· The PPP Internet Protocol Control Protocol (IPCP) 

· PPP Extensible Authentication Protocol (EAP) 

· PPP EAP RSA Public Key Authentication Protocol 

· Layer Two Forwarding (Protocol) "L2F" 

· PPP LCP Extensions 

· PPP Vendor Extensions 

· Layer Two Tunneling Protocol "L2TP" 

· Proposal for LCP Authentication Option 

· Mobile IPv4 Configuration Option for PPP IPCP 

· Semi Connected Mode for PPP links 

· Proposal for a PPP Network Layer Entity Selection Protocol 

· PPP over AAL5 and FUNI 

· Layer Two Tunneling Protocol (L2TP) over AAL5 and FUNI 

· PPP CallBack

Request For Comments:

RFC 

Status 

Title

RFC1220 

PS 

Point-to-Point Protocol Extensions for Bridging

RFC1331 

PS 

The Point-to-Point Protocol (PPP) for the Transmission of Multi-protocol Datagrams over Point-to-Point Links

RFC1332 

PS 

The PPP Internet Protocol Control Protocol (IPCP)

RFC1333 

PS 

PPP Link Quality Monitoring

RFC1334 

PS 

PPP Authentication Protocols

RFC1376 

PS 

The PPP DECnet Phase IV Control Protocol (DNCP)

RFC1377 

PS 

The PPP OSI Network Layer Control Protocol (OSINLCP)

RFC1378 

PS 

The PPP AppleTalk Control Protocol (ATCP)

RFC1472 

PS 

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

RFC1471 

PS 

The Definitions of Managed Objects for the Link Control Protocol 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

RFC1474 

PS 

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

RFC1547 

Requirements for an Internet Standard Point-to-Point Protocol

RFC1549 

DS 

PPP in HDLC Framing

RFC1548 

DS 

The Point-to-Point Protocol (PPP)

RFC1552 

PS 

The PPP Internetwork Packet Exchange Control Protocol (IPXCP)

RFC1553 

PS 

Compressing IPX Headers Over WAN Media (CIPX)

RFC1570 

PS 

PPP LCP Extensions

RFC1598 

PS 

PPP in X.25

RFC1618 

PS 

PPP over ISDN

RFC1619 

PS 

PPP over SONET/SDH

RFC1638 

PS 

PPP Bridging Control Protocol (BCP)

RFC1663 

PS 

PPP Reliable Transmission

RFC1662 

PPP in HDLC-like Framing

RFC1661 

The Point-to-Point Protocol (PPP)

RFC1717 

PS 

The PPP Multilink Protocol (MP)

RFC1763 

PS 

The PPP Banyan Vines Control Protocol (BVCP)

RFC1762 

DS 

The PPP DECnet Phase IV Control Protocol (DNCP)

RFC1764 

PS 

The PPP XNS IDP Control Protocol (XNSCP)

RFC1973 

PS 

PPP in Frame Relay

RFC1969 

The PPP DES Encryption Protocol (DESE)

RFC1962 

PS 

The PPP Compression Control Protocol (CCP)

RFC1968 

PS 

The PPP Encryption Control Protocol (ECP)

RFC1979 

PPP Deflate Protocol

RFC1977 

PPP BSD Compression Protocol

RFC1975 

PPP Magnalink Variable Resource Compression

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)

RFC1989 

DS 

PPP Link Quality Monitoring

RFC1990 

DS 

The PPP Multilink Protocol (MP)

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)

Current Meeting Report

Minutes of the Point-to-Point Protocol Extensions (PPPEXT) Working Group 

Reported by: Matt Holdrege 

Day One, April 7, 1997

I. PPP Vendor Extensions - Bill Simpson - draft-ietf-pppext-vendor-01.txt 

New draft. IESG suggested changes. They didn't want to mandate OUI's. Will now be forwarded back to the IESG.

II. PPP CallBack draft-ietf-pppext-callback-ds-01.txt 

Will go forward, probably as Draft Standard.

III. PPP LCP Extensions - draft-ietf-pppext-lcpext-ds.txt 

Will go forward on standards track. 

III. Mobile IPv4 Configuration - Jim Solomon - solomon@comm.mot.com 

draft-ietf-pppext-ipcp-mip-00.txtGoal: Reach consensus that this option is useful and on the procedure for its advancement on the standards track.Status: Consensus in Mobile IP working group that this option, as specified, is useful and in fact necessary; Consensus among Area Directors that this protocol belongs in the PPPEXT Working Group. 

Proposal: New IPCP option. Add bit options to handle Mobile IP better and specifically, foreign agent care-of address. 

Q: What to do when IP address req. is in the same packet as a mobile node request? Jim to check if the new option can be used in conjunction with IPCP IP-Address rather than instead of it. 

Q: Why does this use type=137? IANA assigned it, but Jim will check the sanity of this. 

Preferable to breaking this into an original IPCP request and a Mobile node request.

V. PPP Stac LZS Compression (RFC 1974) 

Fix the conflict between Extended Mode and PFC. 

Propose to remove mention of PFC if Microsoft won't accept PFC while accepting STAC option four? Need to find out Microsoft behavior. 

Philip Rakity pmr@flowpoint.com - Resynchronizing when using extended mode. Philip proposed changing text that he will send to the list. 

Proposal for a PPP network Layer entity selection protocol - Avri Doria adoria@gdc.com - draft-ietf-pppext-nles-00.txt. 

Mechanism for selecting target system when using a direct access network like xDSL. Suggested using LCP. Much discussion made it seem clear that this may not be necessary. 

If using HDLC switching, a special HDLC packet may handle this better. If using PPP authentication, something like RADIUS realms seems more appropriate. Working Group to drop this item.

VI. PPP DES Encryption - RFC 1969 - Plaintext Padding. 

SDP is assumed to be pre-negotiated with M=8 and pad all protocols. PPP-style SDP technique is mandated, not PKCS style. If the packet length doesn't require padding, add pad bytes only if the last byte of data is 8 or less. In security section, say that checking all pad bytes is recommended but not mandatory.

VII. Semi Connected modem for PPP links - Mikael Latvala 

mikael.latvala@lmf.ericsson.se - draft-ietf-pppext-scm-00.txt. 

Motivation: Minimize reconnection latency. Allow end-users to pay for a bearer service on a need basis. It was also stated that this protocol will aid greatly in resource reservation. The Chair pointed out that the resource issue is handled by other protocols. 

Bill Simpson gave a discourse on the many reasons why latency issues should not be considered. It would be handy but not necessary to have an implementor's document describing how to do this with existing protocols.

VIII. L2TP draft-ietf-pppext-l2tp-01.txt - Andy Valencia - vandys@cisco.com 

Much progress had been made since the last IETF meeting. Looking forward to the interoperability testing at the CIUG in May. Will be tunneled on top of UDP. Will work with some NAT techniques. UDP checksums will be supported. No PPP checksums because the LNS cannot be expected to handle that. 

Issues of callback in complex configurations has yet to be hashed out. 

Andy is looking for feedback from implementors. 

As before, please comment if anything below seems to misrepresent what actually occurred at the meeting. 

Day Two - April 9, 1997 

I. PPP over AAL5/FUNI - Manu Kaycee - mjk@nj.paradyne.com 

Manu gave an overview of the draft and proposed encapsulation Map PPP packet over AAL5 and FUNI Datalink Leverage. The rich PPP framework in these level-2 environments Provide a standard for ADSL forum and other bodies Uses RFC 1483 VC multiplexing for payload mappings Applies equally to AAL5 & FUNI FUNI 2.0 is being straw balloted in ATM forum. ACFC, No. PFC, yes. Clarifying text to follow. Propose separate ID's. Other signaling frameworks may follow. 

Discussion: 

· LLC encapsulation? Yes or no? 

· What about the Frame discard issue in Section 4? 

· Andy Malis said performance is better with VC encaps than LLC. 

· Others said the LLC was needed for internetworking. 

· The CF issue was discussed for internetworking's sake. 

· Bill recommends we choose either AAL5 or FUNI to move forward to fit with IETF philosophy. 

· Andy says that both interfaces will be popular and will need to interoperate. 

So, it was proposed that text would be included in the two documents that will make sure that interoperability will work between the two.

It was stated that LLC adds overhead, but it may be needed to handle situations where switches lose information. It was stated that major vendors are now implementing PPP over AAL5 and working on PPP over FUNI. 

No consensus was reached. The issues surrounding this draft will move to the list. An updated draft will soon be sent to the list. Next step: Update ID's.

II. L2TP over AAL5 and FUNI 

· Much the same justification and motivation as PPP over AAL5 & FUNI 

· Multiple tunnels MAY exist over the same VC 

· Same tunnel MAY be administered across multiple VC's 

· L2TP codepoint: Tim Kwock to follow through 

· Section 2.2 is incorrect and will be updated 

· QoS AVP will be sent to the list

Next step: Clean up and update ID 

Bill Simpson asked why we need this protocol? 

Manu said it is intended to support large number of VC's in core networks. This draft will cover how to multiplex several L2TP/PPP sessions over a single VC. 

BT and others will send some scenarios to the list, which would support the usefulness of this protocol. 

It was stated that it would be useful in building access networks, which want to use L2TP mapped to ATM VC's. Some are afraid that ATM or ATM CPE doesn't currently scale well enough to support enough VC's to handle individual VC's per L2TP/PPP sessions. Others said that this is a temporary issue and we shouldn't design a protocol to solve a temporary issue. 

It was pointed out that this draft doesn't adequately address security. 

It was mentioned that the QoS AVP's will be added to RADIUS as tunnel attributes. 

Other items: 

· The chair repeated that SCM is now dropped as a work item. 

· IPCP is out in draft; comments are requested 

· When the chair requested on the L2TP mailing list that discussion be dropped concerning UDP checksums, several people refused, both publicly and privately. The chair pointed out that the Area Directors agree with his decision, and would ask that such rude behavior be kept off the PPP lists in the future. 

Slides

1. L2TP over AAL5 and Funi  Attendees List

Attendees List

TOC