PPPEXT WG
Dec. 7th, 1998
Meeting Chair
Matt Holdrege -
[email protected]
Reported by
Don Grosser -
[email protected]
L2TP draft status - Mark Townsley
=================================
-Poll: about 50% of attendees monitor the L2TP mailing list
-Poll: most of those who monitor the L2TP mailing list saw the
email from the IESG (Thomas Narten)
-Mark pointed out that the authors have been working hard to
advance L2TP.
Mark read the following statement:
The Layer 2 Tunneling Protocol, which began 2 years ago as the merging of
the L2F and PPTP specifications, is currently in its 12th state of
Internet Draft revision. In March of this year, the Working Group
requested that the 10th revision of L2TP be promoted to RFC Proposed
Standard. To date, the Working Group is aware of over 20 independently
developed, interoperable L2TP implementations. In reaction to substantial
customer demand, several vendors have announced general availability of
L2TP in their products and have begun the initial stages of widespread
deployment. One could say with clear conscience that L2TP has been in a
�de facto� Proposed Standard phase for many months.
The high level of endorsement for L2TP by the industry places additional
weight on every decision to alter the specification as well as increased
demands for an expeditious advancement through the IETF process. In fact,
as time has marched forth, the L2TP specification has become less of a
static proposal to base new implementations off of, and more of a report
on the details of implementations have already been developed. The Editors
consider the L2TP draft as the �source code� for which developers have
created many L2TP implementations. As with any product which has been in
widespread use in the field, every change made is applied with great
scrutiny as each invariably run the risk of causing unintentional side
affects. In our case, the side affects are the possible introduction of
contradictions or ambiguities that may hinder interoperability of future
L2TP implementations using the L2TP specification.
This state of affairs has created a setting that to the IESG has seemed
rigid and closed minded. In fact, this behavior has been a simple effort
to balance protection of both the installed base of implementations and
hard-earned consensus that the Working Group had already achieved,
together with the necessary changes required in order to move the official
status of the document forward in a swift manner. It seems, however, that
this hard-lined conservative approach has hindered the IETF process more
than it helped.
Over the past 9 months, the Area Directors and IESG have made a total of
57 specific suggestions for alteration of the L2TP specification. With so
many other items on its plate, the IESG must truly be commended for such a
thorough review. These items have ranged from simple typos, to operational
changes in protocol itself. 23 of the 57 items presented were incorporated
into draft 11 and 12. The rest were resisted by the Editors on grounds
that they were general misunderstandings, were not backward compatible
with the multitude of existing implementations and did not provide enough
benefit to outweigh the costs, or would require additional implementation
experience in the field to properly address. The latter is something we
argue could be taken care of during the Proposed Standard phase.
At the IESG�s request, we recently re-evaluated the suggestions that were
originally rejected or missed. Of these, 8 were still considered
unnecessary and 8 were accepted with the necessary changes to the text
applied. The final 18 items were each affiliated in one way or another
with the optional flow control feature of L2TP. The Editors have been
unable to reconcile each of these issues in a manner that we believe would
not require additional review by the Working Group and another round of
consensus attained. Therefore, it is the recommendation of the Editors
that the portion of the L2TP specification that handles the optional Flow
Control mechanism be isolated and moved to its own Internet Draft, leaving
the base specification for approval by the IESG without this hindrance.
The purpose of this action is NOT to alter the L2TP protocol itself. The
express intent is to enhance the clarity and readability of the L2TP
specification, properly address all of the concerns of the IESG, and still
allow for a swift promotion of the base specification to Proposed
Standard. To this end, no new functionality to the new L2TP specification
will be permitted during this phase, beyond any necessary items for the
clean separation of the Flow Control capability. Of primary concern is
that the new draft be backwards compatible to the previous specification,
and thus to the many existing L2TP implementations that have already been
deployed. Any proposed changes solely for increased clarity and
readability will be graciously accepted and evaluated for inclusion into
the new specification. However, please remember that when trying to
improve the overall clarity of a document, removing words is often more
effective than adding them. This �Less is More� principal will certainly
apply here.
-It is the recommendation of the authors to remove L2TP flow
control from the base specification in order to advance the
L2TP draft. They propose a new draft to describe L2TP flow
control.
-It was noted that the new flow control draft should be
backwards compatible with existing implementations.
-Focus will be on advancing the L2TP base spec *then*
the flow control draft.
-Mark is targeting Dec. 17 to present base L2TP to the IESG.
-Mark requested a document review group to be held later in
the week at the IETF to review the changes.
-It was noted that the base L2TP spec should always set the R-bit
for the benefit of existing implementations which "stick" after
dropping a packet.
L2TP Link Extensions (Bill Palter/Mark Townsley)
================================================
-Need a way to communicate negotiated LCP options from LNS to LAC.
-Need a way for the LAC to provide the LNS with LCP options
suggestions/limitations.
-LAC to LNS:
-LCP want options AVP (format is similar to existing proxy
LCP AVPs). A table is provided in the draft giving LCP
option meaning in the context of this new AVP.
-LCP allow options AVP (format is similar to existing proxy
LCP AVPs). A table is provided in the draft giving per LCP
option meaning in the context of this new AVP.
-It was noted that some LCP options (like auth. protocol)
should not be included in the new AVP because the LAC
shouldn't have any input as to which auth. protocol the LNS
uses.
-LNS to LAC:
-Bill described a method to communicate LNS negotiated LCP
options to the LAC.
-The L2TP SLI message can include the LCP-Conf-Req and last-
received-LCP-Config-Req AVPs.
L2TP MIB - Evan Caves
=====================
-Changes from draft -02:
-Sessions are no longer logical sub-interfaces represented in
the ifTable.
-The session table is indexed by tunnel ifIndex and Local CallID.
-Mapping tables have been added by request.
-A tunnel shared secret object has been added to the Domain and
tunnel config tables.
-The address and port change counters have been removed in
response to the L2TP draft removing these features.
-The addressing change notification has been removed.
-It was noted that the L2TP MIB draft may need to be separated
into an L2TP base MIB and an L2TP flow control MIB draft in
light of the proposed L2TP draft split.
Framework for L2TP Message Extensions - Richard Shea
====================================================
-This draft describes a generic approach to signal support for an L2TP
protocol extension. For example:
-new message types
-new AVPs
-existing AVPs in new messages
-A bitmask would be used to indicate support for various extensions -
one bit per extension.
-It was noted that there should be a way to "reserve" bits.
-This approach also serves to minimize new AVPs which signal support
for an L2TP protocol extension.
L2TP Dynamic Data Window Adjustment - Richard Shea
==================================================
-After session establishment the LNS can modify its receive window
based on which network control protocols were negotiated.
-The LAC can also change its window after receiving window adjustment
from LNS
Mobile PPP - Mooi Choo Chuah/Don Grosser
========================================
-Goal is to provide uninterrupted VPN service to vanilla mobile nodes
without having to renegotiate the PPP link during handovers.
-no client software changes
-minimize handover messaging/delay on expensive wireless WAN
-Clients can have allocated IP addresses from a pool rather than
using fixed IP addresses since IPCP will not be renegotiated.
-This draft leverages L2TP.
-3 models:
-Simple AVP Approach - The new "serving LAC" starts a L2TP call
(and possibly a tunnel) to the existing LNS. During call setup
a new AVP (User AVP) identifies a PPP session on the LNS which
is being replaced. The original LAC-LNS call is subsequently
dropped.
-Independent Tunnel Approach - The end-to-end PPP session is
carried over a 2 separate L2TP tunnels.
-Concatenated Tunnel Approach - This method expands the L2TP
session into a 2-hop L2TP session with end-to-end flow control.
-There were comments and concerns regarding its applicability and
relationship to other work.
L2TP over ATM - Yves
====================
-Removed from the draft:
-"raw" PPP framing over L2TP
-MRU indication from LAC to LNS
-Modified:
-extension for assymmetric bw
-indication of bearer capabilities/type
-indication of framing capabilities/type
-ATM cause code
-Rx minimum bps (OCRQ)
-Rx Maximum bps (OCRQ)
-NSAP based dialed number if b bit
-A request will be made to the PPPEXT chair to make this draft part
of the PPPEXT.
PPTP - Glenn Zorn
=================
-Someone asked what the delta was for the latest draft.
-Glenn noted that the main differences were:
-The security considerations section is much larger.
-References to Karn's algorithm were removed.
-Various format changes were made.
-Appendices were moved to the the draft body.
MPPE - Glenn Zorn
=================
-It was noted that the naming of the associated "key" documents is
confusing.
Day Two:
Session chair: Matt Holdrege
Reported by: Andy Malis
Mark Townsley announced that there is going to be an L2TP editing session
immediately following this meeting.
Shahrukh Merchant (Cimaron) presented his PPP over SONET from STS-1 to
STS-192 draft (draft-merchant-pppext-sonet-sdh-00.txt).
Purpose:
� Document existing practice on previous technology (STS-3c, STS-12c)
� Document what appears to be consensus and/or current practice on current
technology (STS-48c)
� Proposed extension for future technology (STS-192c and above).
For STS1, STS-3c, and STS-12c, use HDLC per RFC 1662 and revised ANSI
T1.105.02 or Revised G.707 for SONET mapping: C2 = 0x16, x^43 + 1 payload
scrambling, FCS-16 is the default and FCS-32 is optional.
For STS-48c, the same as above, except that FCS-32 is the default (FCS-16
is not a defined option).
For STS-192C, he proposed moving from a byte-oriented HDLC to HDLC-32, a
32-bit oriented HDLC that uses 32-bit alignment in the SONET payload for
easier implementation at 10 Gbps speeds. The HDLC-32 payload scrambling
(X^29 + 1) prevents potential malicious bandwidth expansion. It supports
FCS-32 only.
His motivation for HDLC-32 is that byte-wise HDLC is extremely complex and
hard to implement at STS-192c and faster speeds. The flag sequences are:
Flag0=E7 81 CA 34
Flag1=E7 81 CA 35
Flag2=E7 81 CA 36
Flag3=E7 81 CA 37
The escape sequence is
Esc32=EB 8D C6 38
HDLC-32 uses four-octet flags as frame delimiters and as fill when idle.
There are four defined 32-bit flag sequences and one escape sequence. The
abort sequence is Esc32 + Flag0.
Additions he will made to the next version of the draft:
� No FCS is not an option for STS/1/3C/12c
� FCS-16 is not an option for STS-48c.
� ACCM is not used (although an HDLC decode would always decode it properly
anyway).
Next steps:
� Incorporate comments, discussion, and suggestions
� Fill in Appendix A, B, and C (clarifying bit ordering of scrambling and
CRC calculations)
� Fill in Appendix D (PPP over DS3) and expand to include DS1-DS3 and E1-E3
Chuck Benz from Nexabit suggested an intra-packet idle for under run
situations for HDLC-32.
Shahrukh does not believe that Cimaron intends to patent HDLC-32. He will
confirm that.
Andy Hebb said that it looks like you could send (worst case) up to an
additional 6 bytes of overhead per frame (3 extra bytes of flag and at worst
padding to a four-octet boundary) compared to byte-wide HDLC. Shahrukh
added that the average was actually 4.5 bytes extra; however, this
would be reduced relative to byte-wide HDLC by the fact that the
presence of Escape sequences would be a negligible factor (vs. about 1%
for byte-wide HDLC with random data) since the probability of
needing escapes in the data goes down exponentially with word size,
and packets are scrambled before HDLC-32 insertion, so scrambling will
also prevent malicious insertion.
Matt Holdrege wrote a draft on Always On/Dynamic ISDN
(draft-ietf-ppext-aodi-00.txt), and he asked for comments for the intent of
moving it on the standards track. There are multiple interoperable
implementations.
Anita Freeman announced two upcoming interoperability workshops on
L2TP/IPsec, MS-Chapv2, MPPE and perhaps other protocols. Details will be
sent to the pppext and ipsec email lists.
