2.3.10 Point-to-Point Protocol Extensions (pppext)

NOTE: This charter is a snapshot of the 41st IETF Meeting in Los Angeles, California. It may now be out-of-date. Last Modified: 12-Feb-98


Karl Fox <karl@ascend.com>

Internet Area Director(s):

Jeffrey Burgan <burgan@home.net>
Thomas Narten <narten@raleigh.ibm.com>

Internet Area Advisor:

Jeffrey Burgan <burgan@home.net>

Mailing Lists:

General Discussion:ietf-ppp@merit.edu
To Subscribe: ietf-ppp-request@merit.edu
Archive: ftp://merit.edu/pub/ietf-ppp-archive

Description of Working Group:

Note: A separate list has been set up for L2TP discussions

L2TP Discussions:l2tp@zendo.com To Subscribe: l2tp-request@zendo.com Archive: http://bodhi.zendo.com/vandys/l2tp-mail

The Point-to-Point Protocol (PPP) was designed to encapsulate multiple protocols. IP was the only network layer protocol defined in the original documents. The working group is defining the use of other network layer protocols and options for PPP. The group will define the use of protocols including: bridging, ISO, DECNET (Phase IV and V), XNS, and others. In addition, it will define new PPP options for the existing protocol definitions, such as stronger authentication and encryption methods.

No Goals and Milestones

Request For Comments:







The PPP Internet Protocol Control Protocol (IPCP)



The PPP AppleTalk Control Protocol (ATCP)



The PPP OSI Network Layer Control Protocol (OSINLCP)



The Definitions of Managed Objects for the IP Network Control Protocol of the Point-to-Point Protocol



The Definitions of Managed Objects for the Security Protocols of the Point-to-Point Protocol



The Definitions of Managed Objects for the Link Control Protocol of the Point-to-Point Protocol



The Definitions of Managed Objects for the Bridge Network Control Protocol of the Point-to-Point Protocol



Compressing IPX Headers Over WAN Media (CIPX)



The PPP Internetwork Packet Exchange Control Protocol (IPXCP)



Requirements for an Internet Standard Point-to-Point Protocol



PPP LCP Extensions



PPP in X.25









PPP Bridging Control Protocol (BCP)



PPP Reliable Transmission



PPP in HDLC-like Framing



The PPP DECnet Phase IV Control Protocol (DNCP)



The PPP XNS IDP Control Protocol (XNSCP)



The PPP Banyan Vines Control Protocol (BVCP)



The PPP Encryption Control Protocol (ECP)



PPP in Frame Relay



The PPP DES Encryption Protocol (DESE)



PPP BSD Compression Protocol



PPP Magnalink Variable Resource Compression



PPP Deflate Protocol



PPP LZS-DCP Compression Protocol (LZS-DCP)



PPP Stac LZS Compression Protocol



PPP for Data Compression in Data Circuit-Terminating Equipment (DCE)



PPP Serial Data Transport Protocol (SDTP)



The PPP Multilink Protocol (MP)



PPP Link Quality Monitoring



PPP Predictor Compression Protocol



PPP Gandalf FZA Compression Protocol



PPP Challenge Handshake Authentication Protocol (CHAP)



The PPP SNA Control Protocol (SNACP)



The PPP NetBIOS Frames Control Protocol (NBFCP)



Microsoft Point-To-Point Compression (MPPC) Protocol



The PPP Bandwidth Allocation Protocol (BAP) The PPP Bandwidth Allocation Control Protocol (BACP)



PPP Vendor Extensions



Mobile-IPv4 Configuration Option for PPP IPCP



PPP Extensible Authentication Protocol (EAP)

Current Meeting Report

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

Reported by: Andy Malis

The PPPext working group met in two sessions, Monday 30 March 1998 at 15:30 - 17:30, and Tuesday 31 March 1998 from 09:00 to 10:00. Matt Holdrege was chairing in place of Karl Fox, who was unable to attend.

Session 1

Ken Peirce presented L2TP integration with MPLS

Ken gave an overview of MPLS and how it and L2TP could relate to each other. The purpose of his draft is to see if the MPLS label could be used to provide a gross-level QoS and performance specifier on the path. Two possible uses are:

1. Allow the LNS to take advantage of knowledge of existing label switched paths - explicit routes for load balancing.
2. Allow the LNS to "seed" the MPLS mlabel stack to permit fast flow recognition when it reaches the LNS from the LAC.

Question during discussion: L2TP has a protocol to allow you to negotiate the mlabel through the AVP. Is there precedent for this, and can other protocols do this? Answer: Not yet, but a similar approach has been discussed in the MPLS group regarding RSVP. You can use this method to set up an explicit route for the tunnel.

Ken Peirce also presented L2TP and Differential Services.

Ken gave an introduction to the work in the diff-serv working group. The current strawman proposal uses a five-bit "Per-hop behavior", one bit of "In/Out", and two currently unused bits (N.B.: the diff-serv group dropped the "In/Out" bit later in the week).

A host will make an explicit bandwidth request to a bandwidth broker. The LNS will use the diff-serv byte to tell the LAC the appropriate value of the byte in the IPv4 header for a call. The LAC may suggest a value, but should consider a value suggested by the LNS to take precedence.

The diff-serv octet allows differentiated services to be applied on a per-call basis. You can do differentiated services within a tunnel, and then put a diff-serv octet on the packets for the tunnel itself.
Ken intends to ask the PPPext WG to standardize these two drafts.

Dave Allan presented his MARS Proxy draft.

This was originally presented at the ADSL BOF at the Washington IETF meeting. Starting with the PPP over ATM model for ADSL, this draft allows the provider to add IP multicast for bandwidth-intensive applications. It will use an ATM point-to-multipoint tree instead of PPP over ATM point-to-point connections for the data path.

Direct end-host access to MARS has several issues, including provisioning, authentication, and VC frugality, so he is proposing that a proxy be used on behalf of the end users. His proposal is to use a PAP/CHAP authenticated PPP/ATM VC and IGMP. The RAS interworks the IGMP and MARS interaction.

The draft allows you to use ATM multicasting or a multicast server (MCS). The MARS proxy will be run by the server provider on behalf of the clients, which have a PPP connection to the proxy. The client uses IGMP to interact with the proxy, just as if it were on a LAN. The MARS proxy then interworks that into the MARS protocol on behalf of the end client.

There are several issues:

1. Redirected packet detection. This needs to use type 2 encapsulation, which has MTU implications.
2. The subnet model is broken by this approach. PPP uses host routes, there is no subnet.
3. Use of the source host address and source protocol address changes to permit a proxy to issue a join on behalf of a client.
4. MARS implementations must track group membership by cluster member ID, not ATM address.
5. The MARS client must be able to accept incoming calls - there is not current mechanism to authenticate those calls.

There was one question from the audience: You've requested some changes to MARS multicast infrastructure. You are augmenting the PPP session with the multicast service, but this would have been better presented in the ION group? Andy Malis answered this question, stating that this isn't possible due to the current IESG policy to not take on new work in the ion working group, to give the group a chance to get implementation and interoperability experience with its current set of protocols.

Bill Palter and Mark Townsley presented an L2TP update.

The current L2TP schedule is:

2/23: PPP CIUG interoperability workshop, third workshop with L2TP implementations present, numerous interoperable implementations

3/14: draft 10 was posted to the L2TP mailing list. No bits on the wire changed, just clarifications in the text.

3/15: Karl Fox issued a 2nd WG last call.

3/19: Draft 10 rev II (a.k.a. draft 11) was posted to the L2TP mailing list with apologies.

3/20: Karl sent email to the area directors to recommend that L2TP be published as a Proposed Standard RFC. This will occur once the internet draft blackout period ends, and the final version of the draft is available in the internet-drafts directory.

There is already lots of interoperability experience; however, there will be another interoperability bakeoff after the next IETF.

Question from George Gross: Since this moving to Proposed status, can the framing issue (how to carry non-HLDC framing over L2TP) be revisited? Answer: No, not at this time, but later. But it would need a lot of consensus to change at this time, and would need to be done in a separate document. This would really be an extension that can be in a separate draft.

Glen Zorn spoke on MS-MPPE, MS-CHAP, and character set/language negotiation in LCP.

The Microsoft specifications are informational documents describing proprietary documents, and the only comments allowed are regarding their completeness or understandability. The important part is that people be able to implement the protocols as documented.

He asked for comments on the MS-CHAP document. There were none.

He asked for comments on the MS-MPPE document. He's already received a number of comments, and has revised it twice already. Most of the changes are clarifications and examples.

The third draft is non-proprietary and standards track, and technical comments are invited. Question from Craig Fox: There was concern regarding string matching in the options in the specification, and whether we can at least list the valid strings, and have numbers associated with them. However, there is a problem with this: there is already a list of character sets and languages with IANA, and we would have to ask IANA to number them and publish them with their numbers.

Answer: This will be investigated. Craig volunteered to enumerate the character sets in order to present the enumerated list to IANA. This would modify the draft to make the length of the string three or four, and just use the numbers. There was also discussion on possibly improving the negotiation procedure. The spec will allow multiple languages and character sets in a single request, and if you ACK more than one, then the first one in the ACK will be the one used. There was a comment that this may conflict with standard PPP option mechanisms. If the option is rejected, it goes to the default.

There was a suggestion to support more than one option in the configure request, because you don't know how the server is going to be configured. This will be taken to the list - there was no final decision made in the group.

There were several questions concerning details in the MPPE draft, which Glen answered. What does the MPPE receiver do when the flush bit is set because of compression expansion? Does the key get updated, or does it go back to the original key? A: The key only gets updated whenever there is data loss, or when the flush bit is set (it is being treated as packet loss). Q: You're initializing with the current key, rather than rekeying? A: The receiver must reinitialize its tables but does not rekey. But you do rekey in stateless mode on every packet. This will be further discussed offline and then they will let the list know the result.

George Gross spoke on PPP over AAL5. George announced a compromise agreement for PPP over AAL5 to allow the draft to be approved by the IESG. The IESG was concerned about interoperability, especially when interworking with an RFC 1973 (PPP over FR) endpoint. The essence is that the internet draft will require both VC-multiplexed and multi-protocol-encapsulated PPP in order to be conformant. There will also be modifications on the signaling section, and an exception to the VC-multiplexed requirement for interworking with RFC 1973.

There was an interoperability testing event at UNH last week, and George will be making some updates to the draft based upon that experience.

Matt Holdrege asked the group whether L2TP over non-IP media, such as AAL5, is important, and whether the WG should be working on L2TP over AAL5 in particular. This was felt to be important several years ago, but it seems to have cooled off somewhat. A comment was made that L2TP over FR might make more sense than AAL5. There was another comment made that there needs to be a multiplexing mechanism to allow multiple L2TP sessions. There are also people looking at L2TP bridges. Rohit Verma said that he would be willing to work on L2TP over non-IP networks.
Mark said that the L2TP draft is already pretty self-sufficient (just section 8 is IP-specific). Rohit said that there were some open issues that could be discussed in the draft.

Carsten Bormann spoke about ISSLOW issues: Integrated Services on low-bitrate links.
Up to now, Integrated Services has been on high-speed links only. ISSLOW was meant to extend this to modem lines up to 56 Kbps, ISDN, low speed leased lines up to 128K, fractional T1, etc.

The three problems are:

1. Low-speed links blocked by large frames, which kill latency for real-time packets, fixed by fragmentation and suspend/resume;
2. The header overhead, fixed with header compression;
3. It's difficult to reserve bandwidth when header compression produces variable results. This is still an open issue.

One thing that may come up in this group to help support ISSLOW is link characteristic determination, such as round-trip delay.

Another open issue is real-time encapsulation, which is need to minimize worst case end-to-end delay for real-time streams, maximize available bandwidth, minimize overhead, and be predicable enough for admission control. It cooperate nicely with PPP, work with existing chips and router systems, and be future proof (for example, modem protocol developments).

The possible design avenues are abort/suspend, cell-oriented + final bit vs. suspend/resume, where to place the suspend information, how many priorities, and where to put error control.

Two solutions need to be provided:

1. Transmitter fragments large packets down to the latency goal (for example, about 128 bytes). You must pay fragment overhead (similar to cell tax for ATM). PPP multi-link is almost it.
2. For the best latency, send an interrupt packet immediately. You need a way to suspend the frame being sent.

Challenge: Define a scheme where fragmenters and suspenders can happily interoperate. Fortunately, this is just a differentiation on the sending side.

PPP multi-link has one problem: the serial sequence numbering does not allow suspension, but you can still send intervening non-multi-link packets. So you can send two multi-link fragments separated by a non-multi-link packet. However, this only provides a single level of priority.

If you need more than two levels, you need to add two "class" bits to the standard PPP multi-link header. This allows 4 instances of the PPP multi-link protocol to run in parallel with four sequence spaces. This is in draft-issll-isslow-mcml-0x.txt.

Real-time framing allows suspending of packets at any time. This is compatible with type-2 receivers (which have basic HDLC hardware). Multi-ink support is optional. The approach is that there is a second-level scan. HDLC framing is unchanged, but in the payload of the HDLC frames, there is a fragment suspend escape (FSE), 0xDE.

There is a new compressed multi-link header, from three bytes to one byte: 3-bit sequence number, 3-bit class number, one R bit (which is the inverted B bit), and a "1" in the low bit. The bit combination 0xFF cannot be used, so class 7 cannot be suspended and does not need a sequence number. 0xFF is an escape back to normal PPP headers.

When a 0xDE occurs in the data, it has to be escaped using a form of byte stuffing so that a suspension does not occur. There is a maximum expansion of 25%.

There are MRU issues, and a single-automaton implementation requires a two-byte delay for CRC.

There are two new LCP options: Multi-link header format option (27), and Prefix elision (26). They could not use option 18 for the former because of backwards compatibility issues. The latter is somewhat odd, in that it negotiates the behavior of the sender rather than the receiver.

How does this relate to Consistent Overhead Bytes Stuffing (COBS)? It produces better efficiency, but is not compatible with current HDLC chips.

It could be used instead of HDLC as the outer encapsulation of the frames. This is good for high-sped links such as SONET (very efficient to implement).

In the ISSLL group, there has been a last call for the work described here. The purpose of this talk was to introduce the work to the group and invite their comments to the last call.

There were several comments regarding the prefix elision option. There was some concern expressed because it is negotiating the sender behavior.

There was a question why the short header negotiation was part of option 27, rather than 18.

At this point, Carsten's presentation was interrupted by the end of the session.

Second session:

Dave Thaler quickly presented the tunnel MIB.

The tunnel MIB extends the interfaces MIB for certain rows, and the L2TP MIB further extends the tunnel MIB. They share the same ifIndex value for the applicable rows.

Evan Caves presented the L2TP MIB.

There are four L2TP MIB groups, the scalar group, the tunnel group, the session group, and the transport group.

Proposed changes and issues:

* Relationship to Dave Thaler's Tunnel MIB - this will be updated
* How is the session table instantiated?
* Tunnel Domain Group
* Configuration Table
* Statistics Table - more appropriate to have statistics based on groups of hosts
* Reduce number of objects

They intend to add a tunnel session table in the tunnel MIB to correspond with the L2TP session table.

Comment: That approach is preferred to having to walk the entire MIB table to find session table entries.

Comment: There need to be more statistics for the LNC, and the MIB is IP-centric. L2TP will be run over other media besides IP.

Matt asked that detailed comments be addressed to the list.

John Shriver presented some MIB issues that he had sent to the list.

Tunnel configuration lookup rules are a key issue - tunnel configuration is really very different at the LAC and LNS.

It may be better to have different tables for calling and called parties.

The row-create model of the configuration tables is completely ignored. There needs to be a good deal more thinking about how the various parts of configuration fit together.

There was discussion of how the tables should be indexed for best lookup capabilities. This will be further discussed on the list.

The discussion as a whole will be taken back to the list. The tunnel table will be instantiated in the ifTable. There was no consensus on how to instantiate the L2TP session entries, whether in the ifTable or in the L2TP tunnel table.

Carsten Bormann continued his ISSLOW talk from the first session.

He is going to make the following updates to the spec, both regarding option 27 (multilink header format):
* Explain multiple occurrences
* Add parameter for number of suspendable classes, so that it can be negotiated

The replacement text will be sent to the PPPext email list. However, since it has already been through last-call in ISSLL, he would propose to end the discussion by April 20.

The prefix elision option (27) is going to be moved to a separate draft, with more discussion, based upon yesterday's discussion.

The group discussed whether to have multiple options in LCP, or to have one option with multiple bits to select various behaviors. There were concerns that these options could cause multiple rounds of option negotiation. There were suggestions to make certain choices mandatory, to help options negotiation converge.

The option numbers 27 and 26 have been assigned by IANA. Bernard Aboba spoke on L2TP security. A new draft has been sent out. Key management has been taken out, and replaced by a pointer to ipsec. Please send comments to the list. There was discussion about when the L2TP security draft should be advanced. Matt suggested that it have a security review for comments, and then go to WG last call. The suggestion was made that the security folks are overloaded, and it might be better to get their attention by going directly to last call.


MARS Proxy
MPLS Mlabel Distribution via L2TP
L2TP MIB Groups
L2TP and Differential Services

Attendees List

go to list