CURRENT MEETING REPORT

Reported by Fred Baker, Cisco Systems

Minutes of the Point-to-Point Protocol Extensions Working Group (pppext)

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:
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:
Draft 5 sought to do these, improve clarity, and mandate support ofdefault values. It also adds a Windows '95 option.
Issues not addressed in draft 5:
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:
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:
Bandwidth on Demand:
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 asufficient subset of its features can be implemented with a much simplerprotocol. 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 furtheron 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.
In relation to 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.