CURRENT_MEETING_REPORT_ Reported Brian Lloyd/Telebit PPPEXT Minutes Brian Lloyd welcomed the group, asked for sign-in and a short discussion on mailing list, ppp archive availability and history of PPP Working Group was held. Also Brian discussed current status and current implementations of PPP. Bill Simpson reported that SAAG has reviewed the PPP authentication draft document. The result is that the message digest algorithm used in the Challenge Handshake Authentication Protocol (CHAP) may be either MD4 or MD5. The document is being changed to support this. The default algorithm will be the same as that chosen by the SNMP Working Group for SNMP authentication. [MD5 was chosen]. Brian Lloyd reported on the IPLDN discussion on frame relay, X.25 and PPP over the same physical interface. They decided to use XID to distinguish which protocol will run on the link. Brad Parker of Cayman gave a synopsis of the work on PPP in the Appletalk Working Group. Apple has chosen to use PPP instead of a proprietary point-to-point protocol, thus paving the way for both IP and Appletalk on the same serial interface. The result is a document that is ready for review by the PPP Working Group. Two implementations are available. Brad has partially completed work on the drivers and [name] at the University of Michican is planning on continuing the effort. Phil Almquist presented the comments on the PPP requirements portion of the Router Requirements document. The members of the RR Working Group objected to listing line speeds above which VJ header compression should not be used. The result was that the recommendation from the PPPEXT Working Group was changed to read that VJ header compression should be used below 20Kbps and may be used at any speed above that. The upper bound above which VJ header compression should not be used, previously set at 64Kbps, was removed. Phil also reported that there were objections by the members of the RR Working Group to the requirement for Link Quality Monitoring (LQM). This led into a discussion of LQM. The issue was also raised that some of the vendors wish to do other forms of proprietary LQM. One of the problems with the existing LQM is that it is considered to be part of the LCP and hence must use an async control character map (ACCM) of all 1's. This just about doubles the size of an LQM packet on an async link. As a result the LCP document will be modified to support a slightly different LQM negotiation that can support multiple types of LQM. If an implementation supports LQM at all, it must support the existing type of LQM so that there will be a common denominator (analogy to MIB-1 and 1 MIB-2 of SNMP). As a result of the LQM problem the group decided that all Link Control Protocol (LCP) packet/option codes less than or equal to seven that are needed to bring the LCP to the open state must be escaped using the all-ones ACCM. After the link is open the other options, i.e. authentication, new LQM, etc., may be transmitted using the negotiated ACCM and compression options even though these packets are ostensibly LCP packets. There is a problem that occurs when the LCP goes to the open state and a frame that has the ACCM set to zero (control characters not escaped) arrives at the receiver before the receiver has updated its ACCM and changed to the open state (this often occurs when the first NCP packet immediately follows the last LCP ack). The NCP frame is discarded at the receiver. There was a suggestion to insert a delay to allow the receiver to get to the open state before sending the NCP packet. It was noted that this is not a serious problem because the standard error recovery sequence properly deals with this. It was decided not to make a change in the state machine and to add an implementation note describing the problem. There was concern about the length of time that it can take to determine that a link has failed (10 retries with 3 seconds between retries). The final decision was to make it clear that the 3 second delay may be adjusted to accommodate links with lower latency, i.e., that high speed link interfaces timeout values should be smaller. This information will be added to the LCP document and the default timeout value will become part of the PPP MIB. Glenn McGregor presented his IPCP document and discussed the changes to Van Jacobson header compression as used in PPP. Now, the slot number -- which is used to identify a particular session being compressed -- is not compressed. This greatly improves error recovery if a packet is lost or damaged in transit. PPP Minutes PM Session IP Address discussion continued. The Working Group decided to remove the feature for negotiating/reporting multiple IP addresses on an interface. In addition the Working Group decided that the IP address negotiation procedure was too complicated to ensure that it worked properly. The group decided on a much simpler scheme that retains all the features of the earlier version without the complexity. The IPCP document will contain a description of the old method along with a strong note indicating that implementations should use the new IP address negotiation procedure. And that the old IP address negotiation will be eliminated sometime in the not-too-distant future as the IPCP document proceeds down the standards track. Bill Simpson and Brian Lloyd presented the Authentication Document. The section on management of secrets (keys) has a hole due to the lack of 2 availability of a secure mechanism for the dissemination of the ``secret''. This will be gated by the work on Common Authentication Technology (CAT) and on SNMP secret dissemination technology. Also the CHAP will change the way it uses MD5 to generate the authentication ``signature'' so as to be 100should allow the core authentication procedures to be completely interchangable between PPP and SNMP. The discussion then proceeded to the call-back field of CHAP. The purpose of this field is for one end or the other to indicate to the peer that it wishes to terminate the link and call-back, primarily for purposes of reversing charges (some indicated that call-back may prove useful for enhancing security). Several people indicated that multiple call-back destinations may be desirable so a call-back address (phone number) field was defined and added. Marty Del Vecchio from Shiva Corp presented proposed Netware IPX Control Protocol which he has implemented. The group suggested a number of changes and improvements. Marty will do further research and present an improved document soon. Other documents were discussed. It was noted that 3Com has implemented stripped down versions of most of the NCPs. There was nothing to report on CLNP/OSI over PPP. Appletalk over PPP is very close to completion. Michele Wright of Timplex will take over DECnet over PPP doc. Several of the implementors present indicated that they are actively working on an implementation of PPP that supports DECnet. The topic of conversation then moved on to switched circuit (dial-up, ISDN, etc.) connection techniques. A discussion then ensued about techniques for automatically starting PPP during a login process. It was noted that the first PPP frame on an async link consists of the octet sequence ``7e ff 7d 03''. This makes it possible for a terminal server or host to recognize that the peer wishes to run PPP and may start PPP immediately. The discussion also went back to PPP over ISDN. The XID technique for determining which protocol would run, e.g., PPP, frame relay, or X.25, was discussed again. The discussion then proceeded to the topic of inverse multiplexing, e.g., using multiple PPP links to simulate a single link/interface with greater bandwidth. There is a need to add a mechanism to indicate to the remote peer that one end or the other needs to increase capacity and will be opening an additional link. It was suggested that the new link need only open the LCP and authenticate, and there is no need to renegotiate the NCPs. The magic number that is negotiated on a link could be used as a logical connection number and can be made unique across all of the logical PPP connections, e.g., all physical connections that are part of a single logical interface will use the same magic number. Results and Decisions 3 The group decided to move the status of the LCP document back to ``proposed'' because of the changes to LQM. The group decided to move the status of the IPCP document back to ``proposed'' status because of the desired changes to the IP address negotiation. The group decided to keep the status of the Authentication document at ``proposed'' status due to the changes in the CHAP. Attendees Steve Alexander stevea@i88.isc.com Fred Baker fbaker@emerald.acc.com Dean Cheng dean@sunz.retix.com Richard Cherry rcherry@wc.novell.com Curtis Cox ccox@wnyose.nctsw.navy.mil Kenneth Crepea crepea@cisco.com Marty Del Vecchio marty@shiva.com Craig Fox foxcj@network.com Chris Gunner gunner@osicwg.enet.dec.com Bob Jeckell robert_jeckell@nso.3com.com William Jolitz william@okeeffe.cs.berkeley.edu Frank Kastenholz kasten@europa.clearpoint.com Tom Kessler kessler@sun.com Holly Knight holly@apple.com Gordon Lee gordon@ftp.com Brian Lloyd brian@ray.lloyd.com Glenn McGregor ghm@merit.edu Robert Morgan morgan@jessica.stanford.edu Dean Morris morris@marvin.dec.com Michael Newell mnewell@nhqvax.hg.nasa.gov Chandy Nilakantan csn@3com.com J. Bradford Parker brad@cayman.com Miguel Sasson sasson@xylogics.com Mark Schaefer schaefer@davidsys.com William Simpson Bill_Simpson@um.cc.umich.edu Eric Smith Ravi Srinivasan ravi@eng.vitalink.com Bruce Taber taber@interlan.com Mark Therieau markt@python.eng.microcom.com William Townsend townsend@xylogics.com Maurice Turcotte dnmrt@interlan.com John Veizades veizades@apple.com Yuan Wang natadm!ycw@uunet.uu.net Scott Wasson Preston Wilson preston@i88.isc.com L. Michele Wright uncng!michele@uunet.uu.net 4