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.
Karl Fox <karl@ascend.com>
Frank Kastenholz <kasten@ftp.com>
Jeffrey Burgan <jburgan@baynetworks.com>
General Discussion:ietf-ppp@merit.edu
To Subscribe: ietf-ppp-request@merit.edu
Archive: ftp://merit.edu/pub/ietf-ppp-archive
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
· 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"
· 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
· Layer Two Tunneling Protocol (L2TP) over AAL5 and FUNI
· PPP CallBack
Request For Comments:
Minutes of the Point-to-Point Protocol Extensions (PPPEXT) Working Group
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.
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.
· 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.
· 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.
· 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.