Editor's note: These minutes have not been edited. The PPP Extensions Working Group met at the Montreal IETF meeting on Wednesday, June 26th from 1300-1500 and on Thursday, June 27th from 1300-1500. Minutes of the two meetings follow: Reported by: Ed Allen Wednesday meeting 1. LCP Extensions (draft-ietf-pppext-lcpext-ds-00.txt) Bill Simpson led a discussion of the various LCP extensions described in the document. Bill said this draft has been on hold waiting for someone who wanted to change callback. An informal poll showed that there are 2 implementations of the Identification option, and 2 implementations of callback. Discussion revealed there is concern that the callback option is not ready yet. Resolution is that Callback option will be stripped from current draft and made into a separate draft, so that the remaining LCP extensions can continue on the standards track. draft-ietf-pppext-lcpext-ds will then be resubmitted and sent out for working group last call. 2. Vendor Extensions (draft-ietf-pppext-vendor-00.txt) Bill Simpson explained the rationale of this draft. He explained that this cannot be standards track document due to no possibility of interoperable versions, but noted that CCP already has the same vendor-specific option, which is standards-track. Bill asked what do people think about going standards track? Area Director Jeff Burgan said he thought it would be Informational. Resolution is that this draft will be sent as Informational RFC by Bill Simpson to the IESG. 3. SONET (RFC 1619) Bill Simpson explained that there are already commercial implementations of this RFC. Bill explained that PPP has been designed to run from very low speeds to very high speeds, and briefly explained SONET, which runs at 155 Mbits/sec, with 622 Mbs and 2 Gbps in development. He explained that although ATM runs over SONET, it has a larger overhead than PPP. He noted that one major chip vendor has admitted not conforming to SONET spec in loss of state. The chip only detects 72 bit sequences of zeros. Bill proposed to add two sentences and an appendix to PPP over SONET which will describe a settable third byte and how to escape long sequences of zeros. This text will provide a workaround for the chip problem. 4. Multilink Protocol(MP) (draft-ietf-pppext-multilink-12.txt) Karl Fox led a discussion of Multilink, RFC 1717. Karl said MP has been sent to Draft Standard. Karl recalled a discussion which took place on the list to the effect that the caller being responsible for initiating bringup of links (with respect to dialed lines and bandwidth-on-demand). Resolution of this issue was that there would be no change to MP. It is on desk of RFC editor and will have a new RFC number assigned to it. There was discussion as to whether there should be an informational RFC describing current practices in this area. It was decided that there is sufficient interest, and Dan Brennan volunteered to head up the effort to write the informational RFC. 5. Extensible Authentication Protocol(EAP) (draft-ietf-pppext-eap-auth-02.txt and draft-ietf-pppext-eaprsa- 02.txt) Karl Fox noted the main document fell off the six month timer. Since there are two interoperable implementations the main document will be resubmitted. There was interest by three to four vendors in working on this extension. 6. Protocol Spoofing Control Protocol(PSCP) (draft-ietf-pppext-spoof- 00.txt) The author was not present. A discussion of the merits of this approach occurred. A representative from one vendor mentioned they had done some work on retaining context while spoofing, when zero links (retaining context across disconnects). One benefit is that a client can retain its dynamically assigned IP address. There was a proposal that doing a spoofing protocol was not worthwhile in and of itself. Long discussion occurred about persistent state, suspend/resume notion, spoofing. Group rejected idea of putting spoofing capabilities into BACP. At least one vendor has implemented PSCP. Resolution was that Dana Blair would work with Ian Puleston (draft author) to describe current practices. 7. STAC compression (draft-ietf-pppext-stacker-09.txt) It was agreed that draft 10 will consist of draft .09 plus fixed typos. Draft 10 will then be sent to the IESG for upgrade to proposed standard. One questioner asked whether anyone has gone ahead w/ Motorola license agreement? Only one company said they had executed the license agreement. Hands showed there were about 10 implementers of Stacker. A representative from Stac said that there is a deal where you can get access to Motorola license proposal from Stac. It contains terms of license agreement. 8. Status of other work by PPP WG. CHAP and LQM are now approved Draft Standards, and will get RFC numbers soon. Netbios CP is at Proposed Std status. Other drafts: Status of WCP (draft-ietf-pppext-wcp-00.txt) was discussed. Ed Allen explained that WCP can be negotiated using CCP, and is thus not a standard which competes with WCP. draft-ietf-pppext-dataencap-03.txt has expired, and as there is no interest from the WG, will be allowed to die. draft-ietf-pppext-encryption-04.txt is at Proposed Standards draft- ietf-pppext-des-encrypt-01.txt is an informational. draft-ietf-pppext- frame-relay-03.txt is stds track, and is at PS and will receive an RFC number from the RFC editor at some point in the future. draft-ietf-pppext-snacp-01.txt has been implemented by one vendor, and will become and informational RFC. 11. PacBell bakeoff Anita Freeman of PacBell stated there will be another interoperability bakeoff either Oct 20-25 or Nov 17-22. (The October choice was chosen by the WG.) Anita stated that there will be a max. of 68 tables. There will be up to 8 PRI interfaces and 136 BRIs 1st couple days are remedial testing for MP, followed by testing for CCP and BACP. Location is San Ramon, San Ramon Marriott was suggested for advance reservations. bob@Larribeau.com is organizer of the bakeoff. 12. Assorted other PPP extensions. Bill Simpson asked the working group about assorted other PPP extensions. IPXCP Bill Simpson asked the WG if there were any changes need to IPXCP. Twelve vendors said they had implemented IPXCP. The WG agreed to send IPXCP to IESG as draft standard. PPP over ISDN (RFC 1618) Bill said there have questions and comments about this draft. Dana Blair will solicit list for comments. PPP over X.25 A (non) show of hands revealed , nobody in room had implemented this one Bill knows of 3 vendors shipping this. There will be an effort to get a number of protocols either to draft std status or to kill them. --------------------- Thursday meeting 13. BACP - Craig Richards Current draft is draft-ietf-pppext-bacp-03.txt, is based on comments from LA IETF meeting and experiences at May Pacbell bakeoff. The draft is now in last call status. Craig said the most recent changes were the removal of Link Drop request, Bundle Drop request and 2 other msgs. He said he improved & clarified phone number format, he noted other changes as well. Craig noted there was successful interoperability at PacBell bakeoff. All were alpha or beta code. There were questions and suggestions for rewording regarding: o section 6.2 Phone-Delta Unique Digits suboption o substituting transmitter/receiver for peer. o Link-Drop-query request wording. o sect 2.1 Link Discriminator, description of wrapping. o discussion re: Callback-request value and concern of is value. o link-type option only being 8 bits. Craig indicated he would clarify the wording where necessary. Karl Fox polled the WG to find out the WG opinion of BACP. A show of hands revealed there are 4 BACP implementations and 8 more planned. 25 hands indicated they thought BACP was valuable, while zero hands thought BACP was not valuable. 14. Point-to-Point Tunneling Protocol(PPTP) - draft-ietf-pppext-pptp- 00.txt Gurdeep Singh Pall presented concepts, terminology, design goals and protocol details of PPTP. He presented Incoming Call states for each end of a tunnel. He also presented a comparison between PPTP and L2F. Gurdeep stated future goals for PPTP, which included the following: o Converge with L2F o Include new features which have been identified, but which are not in PPTP today. o Leverage other IETF efforts, including IPSEC. Gurdeep provided the following URL for PPTP source code: http://ftp.microsft.com/developer/drg/pptp/src Here are some of many questions/discussions following Gurdeep's presentation: o How does PPTP go thru firewall o How handle shared credentials, and other security issues. 15. Level Two Forwarding(L2F) - draft-ietf-pppext-l2f-02.txt Andy Valencia discussed a number of detailed L2f issues that are outstanding. Some are included here: o out of seq recovery o uniform len-type-value encoding o mandatory/optional flag o vendor specific fields o outbound calling There was a lot of discussion on question of whether to use IP instead of UDP. Resolution was to use GRE, which has its own IP protocol number. Coulduse and IP prot # instead, and sve 20 bytes pkt hdr. AV has concern that if eeveryone did this, all IP #s would be used up Concern that firewalls would not be able to filter on IP prot #. Pat asks why not use GRE, which has prot number Disc of Ipv6 There was discussion of various other issues, such as: o how IPv6 fits in o MTU issues o clear text passwords across tunnel when PAP or SLIP is used o pre- encrypted passwords o other possible security attacks o the second negotiation of LCP, and how client LCP implementations handle LCP going down. o minimal or no L2f header A discussion of the LCP options recommended for use with L2F suggested the following options: o Multilink o 1500 byte MTU o others to be solicited from the PPP WG list. Andy presented L2F status as this: 1. holding up well in IETF 2. interoperable implementations 3. L2F and PPTP folks have been talking Andy categorized commonalities between L2F and PPTP and also aspects unique to each. 16. Combine PPTP and L2F After discussion a goal was stated to combine PPTP and L2F before the next IETF meeting. Proponents of each will work together to come up with a new draft, tentatively called L2TP. Andy Valencia made some suggestions as to what L2TP would inherit from PPTP and L2F. L2TP would: Keep layer 2 tunnel keep GRE format Adopt uiformat content format L2TP would inherit from PPTP: media semantics (BACP) calling (but modularize) optional flow control L2TP would inherit from L2F: optional ID optional LCP others were mentioned Andy also highlighted some L2TP futures as being: encryption integration with BACP multicasting fancy queuing issues There was a discussion of using a reliable channel for data. Ian Duncan agreed to set up a mailing list for discussions related to L2TP and to send the email address to the PPP list. 17. Secure Dynamic Tunneling Protocol(SDTP) Pat Calhoun and Ellis Wong Pat Calhoun and Ellis Wong presented concepts of SDTP. The following are some SDTP concepts: o can be used as a router to router tunneling protocol o can be used as a NAS to gateway tunneling protocol o PPP is terminated at the NAS for dial-up access. o security for the tunnel uses IPSEC o high scalability due to multiple tunnel capability o multiple protocol support (any level 2 and level 3) o some SDTP concepts are borrowed from Mobile IP Questions/discussion followed regarding how SDTP is different from ATMP. Ellis Wong agreed to send a path to slides to the mailing list. Some participants expressed the opinion that SDTP concepts should be combined into L2TP.