One document matched: draft-ietf-l2tpext-link-07.txt-20787.txt
Differences from 07.txt-06.txt
INTERNET-DRAFT W. Palter
draft-ietf-l2tpext-link-07.txt zev.net
Category: Standards Track W. M. Townsley
Expires: February 2003 cisco Systems
August 2002
Layer-Two Tunneling Protocol (L2TP) Extensions for
PPP Link Control Protocol (LCP) Negotiation
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
This document defines extensions to the Layer Two Tunneling Protocol
(L2TP) for enhanced support of link-specific Point to Point Protocol
(PPP) options. PPP endpoints typically have direct access to the
common physical media connecting them and thus have detailed
knowledge about the media that is in use. When the L2TP is used, the
two PPP peers are no longer directly connected over the same physical
media. Instead, L2TP inserts a virtual connection over some or all
of the PPP connection by tunneling PPP frames over a packet switched
network such as IP. Under some conditions, an L2TP endpoint may need
to negotiate PPP Link Control Protocol (LCP) options at a location
Palter, Townsley Standards Track [Page 1]
INTERNET DRAFT L2TP PPP/LCP Extensions August 2002
which may not have access to all of the media information necessary
for proper participation in the LCP negotiation. This document
provides a mechanism for communicating desired LCP options between
L2TP endpoints in advance of PPP LCP negotiation at the far end of an
L2TP tunnel, as well as a mechanism for communicating the negotiated
LCP options back to where the native PPP link resides.
Palter, Townsley Standards Track [Page 2]
INTERNET DRAFT L2TP PPP/LCP Extensions August 2002
Contents
Status of this Memo.......................................... 1
1.0 Introduction.......................................... 3
1.1 Specification of Requirements......................... 4
2.0 LCP Options From LAC to LNS........................... 4
2.1 LCP Want Options (iccn, occn)......................... 4
2.2 LCP Allow Options (iccn, occn)........................ 6
2.3 LCP Options From LNS to LAC........................... 8
3.0 Security Considerations............................... 8
4.0 IANA Considerations................................... 9
5.0 Contacts.............................................. 9
6.0 References............................................ 9
1.0 Introduction
L2TP [RFC2661] provides a very limited amount of guidance to the LNS
as to what type of interface a tunneled PPP session arrived on at an
LAC. Such information is limited to whether the interface was
"synchronous" or "asynchronous", "digital" or "analog." These
indications provide some guidance when negotiating PPP LCP at the
LNS, but they are not as robust as they could be.
This document defines a more robust way to inform the LAC of LCP
negotiated options, and provides guidance to the LNS of the limits
and values that the LAC requires during LCP negotiation. Deep
knowledge of PPP [RFC1661] and L2TP [RFC2661] are expected for the
remainder of this document.
L2TP Proxy LCP allows options to be negotiated where the native PPP
link resides, thus circumventing issues with ACCM, Alternate FCS, and
other LCP Options that the LNS would not necessarily know how to
properly negotiate without access to the physical media for the
native PPP connection, interface type, or configuration. However, use
of Proxy LCP introduces other problems as well as there are options
within LCP PPP negotiation which should be set or adjusted by the
LNS, such as the PPP Authentication Type and MRU. Finally, the PPP
Client may reinitiate LCP negotiation at any time, and unless the LAC
is sniffing every PPP data packet it forwards, would not be aware
that this is even occurring.
LCP options may be classified into roughly three different categories
with respect to their affect on L2TP; (1) options which affect
framing in a way that the LAC may need to know about or handle
specifically (e.g., ALT-FCS, ACCM, MRU), (2) options that are mostly
transparent to the LAC (e.g., AUTH-TYPE), and (3) options that the
LAC may wish to influence because they are dependent on the media
type (ACFC, PFC). We are most concerned about options which fall into
Palter, Townsley Standards Track [Page 3]
INTERNET DRAFT L2TP PPP/LCP Extensions August 2002
category (1) and (3).
This document defines new AVPs to allow the LAC and the LNS to
communicate complete LCP information in order to react accordingly.
LCP option information is structured in the same way as the Proxy LCP
AVPs are in [RFC2661]. This essentially involves encapsulation of a
PPP LCP Configure- Request or Configure-Ack packet within an L2TP
AVP.
1.1 Specification of Requirements
In this document, several words are used to signify the requirements
of the specification. These words are often capitalized. The key
words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document
are to be interpreted as described in [RFC2119].
2.0 LCP Options From LAC to LNS
The LAC may utilize the following AVPs within an ICCN or OCCN message
in order to influence the LNS to negotiate LCP in a specific manner.
If these AVPs are supported by the LNS, they should override any
suggestions for LCP options implied by the Bearer Type or Framing
Type AVPs.
These AVPs may coexist with the Proxy LCP and Proxy Authentication
AVPs (Proxy AVPs) defined in the base L2TP specification. If Proxy
AVPs are received, the LNS may choose to accept these parameters, or
renegotiate LCP with the options suggested by the AVPs defined in
this document. If the LAC wishes to force negotiation of LCP by the
LNS, it should simply omit all Proxy AVPs during call initialization.
By default, the AVPs defined in this document are not mandatory (M-
bit is set to zero). However, if an implementation needs to strongly
enforce adherence to the options defined within the AVPs, it MAY set
the M-bit to 1, thus forcing the peer to discontinue the session if
it does not support this AVP. This is NOT recommended unless it is
known that the result of operating without these extensions is
completely unacceptable.
If the AVPs in sections 2.1 and 2.2 are sent to the LNS, the LAC MUST
be prepared to accept the AVPs as defined in section 2.3.
2.1 LCP Want Options (iccn, occn)
The LCP Allow Options AVP, Attribute Type TBA1, contains a list of
options that the LAC wants to be negotiated by the LNS.
Palter, Townsley Standards Track [Page 4]
INTERNET DRAFT L2TP PPP/LCP Extensions August 2002
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H| rsvd | Length | Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Type | LCP Configure-Req ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... LCP Configure-Req (continued) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Vendor ID is the IETF Vendor ID of 0.
This AVP MAY be hidden (the H bit MAY be 0 or 1).
The M bit for this AVP may be set to 0 or 1. If the sender of this
AVP does not wish to establish a connection to a peer which does not
understand this L2TP extension, it SHOULD set the M bit to 1,
otherwise it MUST be set to 0.
The Length (before hiding) of this AVP is 6 plus the length of the
LCP Configure Request.
The AVP SHOULD be present in the following messages: ICCN, OCCN
The LCP Configure-Req Value for this AVP is identical to the
information field of a PPP LCP Configure-Req Packet (much like a
Proxy LCP AVP in [RRFC2661]). It is sent from the LAC to the LNS, and
is intended to guide PPP LCP negotiations at an LNS. In some cases,
each individual PPP LCP option carried in this AVP maps to a desired
value (e.g., MRU) and in some cases it maps to a specific option that
is desired to be enabled (e.g., ACFC). The LNS should use these
suggestions when building its initial Configure-Request.
The following chart defines some of the more common LCP options that
may be included in this AVP with guidance of how to handle them at
the LAC and LNS. This table is provided for some of the more common
or problematic LCP options. It is not intended to be an exhaustive
representation of all LCP options available.
LCP Want Option LAC Action LNS Action
MRU LAC provides a LNS SHOULD begin LCP negotiation
maximum value with this value. However,
it MAY reduce MRU if
necessary.
ACCM LAC Provides a mask LNS SHOULD begin LCP negotiation
with this value. LNS may
Palter, Townsley Standards Track [Page 5]
INTERNET DRAFT L2TP PPP/LCP Extensions August 2002
add bit(s) while negotiating
PFC LAC provides PFC LNS SHOULD begin LCP negotiation
if it is desired on with this value.
the link type
(e.g. AHDLC)
ACFC LAC provides ACCOMP LNS SHOULD begin LCP negotiation
if it is desired on with this value.
the link type
(e.g. AHDLC)
FCS-ALT LAC indicates required LNS SHOULD begin negotiation
values for the link with this value. Note
type that this value is of
no consequence to the LNS
as FCS is stripped at the
LAC, however some PPP
media types require this
option.
2.2 LCP Allow Options (iccn, occn)
The LCP Allow Options AVP, Attribute Type TBA2, contains a list of
options that the LAC will allow to be negotiated by the LNS.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H| rsvd | Length | Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Type | LCP Configure-Ack ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... LCP Configure-Ack (continued) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Vendor ID is the IETF Vendor ID of 0.
This AVP MAY be hidden (the H bit MAY be 0 or 1).
The M bit for this AVP may be set to 0 or 1. If the sender of this
AVP does not wish to establish a connection to a peer which does not
understand this L2TP extension, it SHOULD set the M bit to 1,
otherwise it MUST be set to 0.
The Length (before hiding) of this AVP is 6 plus the length of the
LCP Configure Request.
Palter, Townsley Standards Track [Page 6]
INTERNET DRAFT L2TP PPP/LCP Extensions August 2002
The AVP MAY be present in the following messages: ICCN, OCCN
The LCP Configure-Ack Value for this AVP is identical to the
information field of a PPP LCP Configure-Req Packet (much like a
Proxy LCP AVP in [RRFC2661]). It is sent from the LAC to the LNS, and
is intended to guide PPP LCP negotiations at an LNS. In some cases,
each individual PPP LCP option carried in this AVP maps to a maximum
value (e.g., MRU) and in others it maps to an option that is
permitted by the LAC (e.g., ACFC). If the option is not included
here, it can be assumed by the LNS that the LAC does not understand
how to perform that particular option at the link layer (and would
thus Configure-Reject that option). Information in this AVP should be
utilized when building PPP Configure-Ack, Configure-Reject and
Configure-Nak messages.
The following chart defines some of the more common LCP options that
may be included in this AVP with guidance of how to handle them at
the LAC and LNS. This table is provided for illustration purposes for
some of the more common or problematic LCP options. It is not
intended to be an exhaustive representation of all LCP options
available.
LCP Allow Option LAC Action LNS Action
MRU LAC provides a LNS may accept reduction
maximum value MRU as requested
ACCM LAC Provides a mask LNS may accept bit(s)
defined here. Note that
if ACCM is missing it is
assumed that it is not
applicable to the link type
PFC LAC provides PFC LNS may accept PFC
if it is allowed on
the link type
(e.g. AHDLC)
ACFC LAC provides ACFC LNS may accept ACFC
if it is allowed on
the link type
(e.g. AHDLC)
FCS-ALT LAC indicates valid Negotiation this option
values for the link is of no consequence to the
type LNS as the FCS is stripped
at the LAC. However, the
Palter, Townsley Standards Track [Page 7]
INTERNET DRAFT L2TP PPP/LCP Extensions August 2002
LNS SHOULD only accept
FCS-ALT types listed here
(more than one value may be
present).
2.3 LCP Options From LNS to LAC
In order to communicate negotiated LCP parameters from the LNS to the
LAC, the format of two existing messages in [RFC2661] are used. These
are:
Last Sent LCP Confreq (IETF L2TP Attribute 27)
Last Received LCP Confreq (IETF L2TP Attribute 28)
These AVPs are sent from the LAC to the LNS to support Proxy LCP
negotiation. In order to report negotiated LCP parameters from the
LNS to the LAC, two messages of precisely the same format are
defined:
LNS Last Sent LCP Confreq (IETF L2TP Attribute TBA3)
LNS Last Received LCP Confreq (IETF L2TP Attribute TBA4)
When LCP negotiation is completed by the LNS, a Set-Link-Info control
message MUST be sent with the these AVPs contained within. These
AVPs MUST contain the last sent and last received (with respect to
the LNS) LCP packets.
Rather than simply using the old Attribute values in the SLI Message,
new AVP Attribute types are defined for these messages due to the
fact that some existing L2TP implementations might check for what
could seem like misplacement of known AVP types and generate a false
error condition.
3.0 Security Considerations
There are no known additional significant threats incurred by the
mechanisms described in this document.
This draft defines additional L2TP AVPs that identify link
characteristics and interface information of a tunneled PPP link. If
these values were snooped, a rogue individual may have access to more
information about a given network or topology. Given that these same
values may be negotiated over the tunneled link in PPP LCP packets
anyway, this is no more information than is potentially transmitted
today, it is just in a different form.
Palter, Townsley Standards Track [Page 8]
INTERNET DRAFT L2TP PPP/LCP Extensions August 2002
4.0 IANA Considerations
This document requires four new L2TP "AVP Attribute" numbers to be
assigned by IANA.
TBA1, Section 2.1, LCP Want Options
TBA2, Section 2.2, LCP Allow Options
TBA3, Section 2.3, LNS Last Sent LCP Confreq
TBA4, Section 2.3, LNS Last Received LCP Confreq
5.0 Contacts
W. Mark Townsley
Cisco Systems
7025 Kit Creek Road
PO Box 14987
Research Triangle Park, NC 27709
mark@townsley.net
Bill Palter
palter.ietf@zev.net
6.0 References
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
RFC 1661, July 1994.
[RFC2661] Townsley W., et al., "Layer Two Tunneling Layer Two Tunneling
Protocol (L2TP)", RFC 2661, August 1999.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
Palter, Townsley Standards Track [Page 9]
INTERNET DRAFT L2TP PPP/LCP Extensions August 2002
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
Palter, Townsley Standards Track [Page 10]
| PAFTECH AB 2003-2026 | 2026-04-23 12:44:51 |