Editor's note: These minutes have not been edited. IETF PPP Extensions Working Group San Jose, 12/10/96 Minutes taken by Matt Holdrege L2TP - Andy Valencia, Gurdeep Singh Pall (absent) Consensus on all pending issues Transport independence - Not dependent on TCP/IP Security Attribute numbering Control message delivery via small LAPD-like reliable protocol Organization of attribute-value pair number required several iterations Consensus on number globally document locally Where possible, share a common description For IP tunnel media, L2TP recommends IPsec Next: Edit and insert markups submitted Andy will publish draft hopefully in 4 weeks Implement! Initial interoperability testing at CIUG in May 1997 John Shriver (Shiva) wants authentication to occur earlier before the tunnel begins to accommodate users with older protocols. This issue will move to the list. L2TP Security - Baiju Patel Basically it was recommended to use IPSEC. PPP over Sonet/SDH - RFC 1619 - Bill Simpson pppsdh@greendragon.com is the new list for this protocol. [New information: listserv@watervalley.net is the address to subscribe to pppsdh. In the body of the message, say subscribe pppsdh YOUR NAME] PPP Vendors Extensions - Bill Simpson - draft-ietf-pppext-vendor-00.txt Recommended to move to an Informational RFC. All implementors should review before requesting numbers from IANA. Protocol Spoofing - Randy Sales of Novell - draft-ietf-pppext-spoof-00.txt Novell has a current implementation in their lab. Randy said that the draft author (Ian - Not Present) has not been able to further refine the draft. Novell would like the PPPEXT WG to help further refine this protocol. It was brought up that this draft has a scalability issue in reference to callback numbers. Novell said that they hope to use tunneling protocols to aid this scaling issue. Further work on timer negotiation needs to be done. John Shriver from Shiva requested that Novell publish a paper detailing just how to spoof NCP. Novell agreed. Bill Simpson noted that IPXCP already covers IPX spoofing. Bill also noted that we have too many protocols that use callback. Bill hopes that we can make whatever changes are necessary to IPXCP to satisfy needs. LCP extensions & callback. Bill sent two drafts out after the deadline. BACP - Craig Richards (absent), Kevin Smith (absent) - draft-ietf-pppext-bacp-05.txt Change the number for BAP so that it doesn't compress. Recommend to create a new version of this draft. Karl will request new numbers from IANA. Ascend is the only vendor in the room shipping BACP. ISSLOW - Carsten Bormann They want to provide fragmentation and suspend/resume mechanisms, header compression, and obtain compressability hints from the application. Big packets can be fragmented by MP, small packets would be sent outside of MP. As for suspending, they need something like H.324 or DSVD. The V.80 modem standard has much lower latency than V.34 and was recommended for RTP applications. They want to make use of the reserved bits in MP header to define classes of priority. They want to define a scheme where the fragmenters and suspenders can happily interoperate. Refer to isslow-fragment-ext-00.txt and draft-ietf-issll-isslow-mcml-00.txt Anita Freeman noted that the next Pac Bell PPP interoperability testing would take place from May 12-16th. ----------------------------------------------------------------------------- IETF PPP Extensions Working Group San Jose, 12/11/96 Minutes taken by Scott Wasson Steve Casner, IP/UDP/RTP Compression - Steve gives a presentation of RTP compression, which is similar to VJ TCP/IP Header Compression. - Need PPP packet types assigned, to differentiate between the IPv4 compression, and several new flavors to support compressed RTP and UDP. - Desire is to combine IPv4 and IPv6 compression into one document. - Discussion about whether both compressions should/would run concurrently. Both NCPs could be Open, allowing independence. Decision was to not allow concurrence so that the existing VJ Protocol ID's could be recycled. John Vollbrecht, Larry Blunk, EAP - No changes needed to the current draft; any new additions to go into a new add-on draft. IP Address option negotiation - None of the original protagonists were present, so the group discussed the issue in their absence. Anything "decided" obviously has to be taken to the mailing list to reach full consensus. - If unit sends: Req(0) -> and peer sends back: <- Nak(addr) ;That's OK. <- Nak(0) ;Prohibited! Never do! <- Rej() ;take default value, "Not Configured". <- Ack(0) ;Prohibited! Never do! Question is: What is the default value of this option? Unnumbered? Manually configured? Not configured? Decided "Not configured" should be the default. This is no change from before. - Discussion about adding a 2-byte "Numbered/Unnumbered" option. - We found that some vendors send cr-0, expecting the peer to supply an IP address. They hoped that the peer would send ca-0, meaning, "I don't have an address to give you, so if you really do have an address but were just trying to be polite and let me pick it, and since I don't have one to give you, now send me yours." - Consensus was that the originator shouldn't have attempted to be so polite. Just send its address. - Frank K. stepped up and pointed out that we were going in circles on the numbered/unnumbered issue, and that we should write up our discussion and bring it to the mailing list. - Brief mention of the next L2TP draft - hope to have it by the end of January. ----------------------------------------------------------------------------- -- Karl Fox, servant of God, employee of Ascend Communications 3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 614 326 6841