Editor's note: These minutes have not been edited. Baiju Patel: IPCP Mobility Extensions Messages are sent originally to the mobile user's home machine, which forwards the message to a 'care of' address. The care-of address can change from time to time as the mobile user moves. The mobile user might reply directly or via the home system, depending on the needs of the transport protocol implementation. Data is forwarded in an IP-in-IP tunnel when going between the mobile user and his home system. The problem is that Mobile IP needs to be able to identify a foreign agent on a dial connection. The proposal is to define an IPCP option, which negotiates whether the peer is willing to be a foreign agent. Draft needs to be updated to, instead of shutting down when the option is refused, to be able to use a co-located agent in the requesting system. Consensus is to continue this work; seems like a reasonable proposal. Ed Allen - IP6 CP The authors propose a new control protocol for IP6 than IP4. This reflects the features of the IP4 CP in IP6 concepts and formats. two options: interface option - negotiate IP6 link addresses compression protocol - negotiate the use of VJ compression The question arose why the authors didn't just "embed the PPP Magic Number as part of the IP6 link-layer address instead of negotiating a separate option for it". Charles Perkins will determine whether a mobility option is required. The working group feels that this is a reasonable (though not the only possible) approach for IP6. Rob Friend - Stac Compression OPtion 17: Objectives with respect to draft 4: - add anti-expansion bit to check mode? - no - add bit to check mode field to put check value after data? - no - add combination bit? no - add bit to utilize Option 23 (DCP) format/protocol? - no - clarify multiple histories? yes Draft 5 sought to do these, improve clarity, and mandate support of default values. It also adds a Windows '95 option. Issues not addressed in draft 5: - sending uncompressed packets - anti-expansion bit - moving the LCB field - 0x4021 is still there to send Stac datagrams with certain defaults, rather than CCP. It conflicts with history count = 1 and no history synchronization requirement. If it is unused, it should be pulled. Rob is going to drop a note to the PPP list asking who is using 0x4021. If it is not, the value will be pulled. Draft 6 addresses a backwards compatibility issue in draft 5, restores the 0x00 deletion and insertion, and defines the extended (Windows '95) mode. Windows '95 uses option 4 in a different way than the draft describes, and uses a different data format. The question arises whether it is appropriate to include in the draft. Draft 6 has five options for check mode, all of which (except extended mode) seem to be widely implemented. The question was raised if we could select one or two and make all others historical. The resolution, after some discussion, was to require implementation ("MUST IMPLEMENT") of option 3 - sequence number check mode - with at least one history. The other four check modes are to be documented and made optional to implement. The LCB and CRC configuration options were viewed as redundant with FCS. This implies that the implementation "MUST IMPLEMENT" the use of the CCP RESET/RESPONSE mechanism, or reliable mode, or both. Other issues include clearly specifying the above paragraph in the current text, defining transmitter & receiver processes in extended mode, deleting the reference to mandating the same number history number bytes in both directions, and other minor editorial updates. Option 18: Called "LZM" technology Used in Windows NT and Windows 95 Windows NT only supports Option 18; Windows 95 supports both OPtion 17 and 18 Called "MPPC" inside Microsoft S/W libraries available from Stac Option 23: Removing 0x00 deletion/insertion and padding discussed, because h/w does not support this. Orthogonality with Frame Relay and TIA superceded this decision. The draft remained unchanged. Stac will support these options in hardware. Andy Valencia - Level Two Forwarding (Protocol) "L2F" The Level 2 Forwarding Protocol is proposed as a way to enable a private network to be extended through a firewall to service providers which handle Async or ISDN dial-in. The expectation is that these endpoints would tunnel the connection through an internet (perhaps using IPSEC protocols) and yet enable them to appear to be within the home network from an addressing perspective. This enables companies to be able to use ISPs rather than deploy world-wide telephone networks. PPP, in this case, is terminated in the "home gateway" or firewall. The ISP essentially virtual-circuit switches the connection to the home gateway, where NCPs and authentication are negotiated. These virtual circuits might be X.25, Frame Relay, UDP, or others. Craig Richards/Kevin Smith [who was not present] BACP Purpose of BAP/BACP: - multiple servers on a huntgroup - interoperable bandwidth on demand - reduce end user configuration burden Bandwidth on Demand: - Resource BOD allows an implementation to unilaterally make decisions - Throughput BOD depends on traffic transmitted. New draft coming out. Bake-off at Pac Bell May 20th 2 days of multilink testing 2 days of CCP testing 1 day BACP testing up to 56 vendors can be accomodated. There will be 40 analog links 98 BRI links 4 PRI links (92 B channels) The sense in the room was that the protocol is too complex; that a sufficient subset of its features can be implemented with a much simpler protocol. Specifically, rather than enumerating link types, it was suggested that one might request certain amount of bandwidth as an integer, potentially with a link type of V.110, V.120, ISDN Sync, or standard Async. It was also suggested that the bundle drop and available link messages are unnecessary. Craig is to develop a feature set proposal and discuss the matter further on the list. Andrew M. Fuqua - PPP SNA Control Protocol This draft documents existing SNA/PPP and APPN/PPP implementations, with the intent of enabling the development of interoperable implementations. The decision was to take this to Proposed Standard after a working group last call. Bill Simpson - CHAP, LQM, and LCP Extensions We need a list of CHAP implementations that have been tested and known to interoperate, and a list of known defects in the protocol. This is to be requested from the list. We need a list of LQM implementations that have been tested and known to interoperate, and a list of known defects in the protocol. This is to be requested from the list. LCP Extensions: it was felt that keeping both the LCP Callback and the BAP "Call me" message s reasonable, as they have different demantics and different purposes. LCP Callback is used for security callback, where BAP Callback is used for negotiating additional bandwidth. The current draft describes only those options that had a constituency the last time we asked. Bill will post an updated draft, and we will then issue a working group last call. Bill Whelan - EAP RSA Authentication The new draft defines an ISO-509 certificate and BER encoding, and tightens some language. The recommendation was made to make sure that this draft conforms to the DER encoding in use in the IPSEC community. Bill will talk with Bob Baldwin at RSA to assure this. Given an updated draft or a statement from Bill that no update is required to align with IPSEC, we will entertain a working group last call on this and EAP. Bill will also inquire about fair and reasonable licnesing arrangements, asking RSADSI to amke the statements requested by the current POISED-95 draft available to the IESG Executive Secretary Ian Puleston - Protocol Spoofing Ian was not present to lead a discussion; we will discuss this on the list. Glenn McGregor - IPCP Glenn will post an updated draft, and we will post a working group last call. The issues: unnumbered links and an ACK of 0.0.0.0. The consensus on unnumbered links was that a system using numbered links SHOULD use option 3 to state or negotiate its address. A system that does not state its address is one which either has a configured address or is willing to run an unnumbered link. The consensus on ACK 0.0.0.0 was that this is not a protocol error, but an implementation note to the effect that keying on this to send IP datagrams with a source address of 0.0.0.0 violates RFC 1122 and is frowned upon mightily. A working group last call was held regarding PPP Multilink; this draft is recommended to advance to Draft Standard. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= It has recently been discovered that research causes cancer in rats.