Network Working Group J. Lau Internet-Draft M. Townsley Category: Standards Track A. Valencia G. Zorn cisco Systems M. Verma CommWorks, a 3Com company I. Goyret Lucent Technologies G. Pall Microsoft Corporation A. Rubens Nexthop B. Palter Redback Networks November 2001 PPP Tunneling Using Layer Two Tunneling Protocol 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''. To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.ietf.org (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). The distribution of this memo is unlimited. It is filed as and expires May 2002. Please send comments to the L2TP mailing list (l2tp@l2tp.net). Copyright Notice Townsley, et al. Standards Track [Page 1] INTERNET DRAFT L2TP November 2001 Copyright (C) The Internet Society (1999). All Rights Reserved. Abstract This document describes the use of Layer Two Tunneling Protocol (L2TP) to tunnel PPP packets. Townsley, et al. Standards Track [Page 2] INTERNET DRAFT L2TP November 2001 Contents Status of this Memo.......................................... 1 1. Introduction.............................................. 3 1.1 Specification of Requirements......................... 4 1.2 Terminology........................................... 4 2. Topology.................................................. 5 3. Control Channel Specifics for PPP......................... 5 4. Data Channel Specifics for PPP............................ 6 4.1 PPP-Specific Sublayer................................. 6 4.2 Forwarding PPP Frames................................. 7 5. AVP Description........................................... 7 5.1 PPP-Specific AVPs..................................... 8 5.1.1 Control Connection Management AVPs............... 8 5.1.2 Call Management AVPs............................. 9 5.1.3 Proxy LCP and Authentication AVPs................ 13 5.1.4 Call Status AVPs................................. 17 5.2 Service Type Independent AVPs......................... 18 6. Data Channel Sequencing................................... 19 6.1 Sequence Numbers...................................... 19 6.2 Data Channel Sequencing over Specific Media........... 20 7. IANA Considerations....................................... 21 7.1 AVP Attributes........................................ 21 7.2 SLI Message Type...................................... 21 7.3 Framing Capabilities and Bearer Capabilities.......... 21 7.4 Framing Type and Bearer Type.......................... 21 7.5 Proxy Authen Type AVP Values.......................... 22 7.6 PPP Sublayer Header Bits.............................. 22 8. References................................................ 22 9. Acknowledgments........................................... 23 10. Authors' Addresses....................................... 24 1. Introduction The Point-to-Point Protocol (PPP) is a data link layer protocol that provides a standard method for carrying multiprotocol packets across point-to-point links. It is the most commonly used protocol to provide remote access over various access media such as dial-up POTS, Townsley, et al. Standards Track [Page 3] INTERNET DRAFT L2TP November 2001 ISDN, ADSL, etc. Typically, a user obtains a Layer 2 (L2) connection to a Network Access Server (NAS) using one of a number of techniques (e.g. dial-up POTS, ISDN, ADSL, etc.), then runs PPP over that connection. In such a configuration, the L2 termination point and PPP session endpoint reside on the same physical device (i.e. the NAS). Tunneling protocols, such as the Layer Two Tunneling Protocol defined in [L2TP], extend PPP by allowing the L2 and PPP endpoints to reside on different devices that are interconnected by a network. This separation allows the actual processing of PPP packets to be divorced from the termination of the L2 circuit. This document defines the specific mechanisms for tunneling of PPP using L2TP. This is a companion document to be read in conjunction with [L2TP]. A large part of this document is derived from [RFC2661], which describes the L2TP protocol signaling as well as the encapsulation method to tunnel PPP sessions. This document is a result of the rewriting of [RFC2661] to separate the base L2TP protocol from the PPP tunneling details. 1.1 Specification of Requirements 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]. 1.2 Terminology This document uses terminology defined in [L2TP]. Additional terminology is defined here. Called Number The telephone number dialed by a caller to reach the receiver of the call. Calling Number The telephone number of the caller. CHAP Challenge Handshake Authentication Protocol [RFC1994], a point-to- point cryptographic challenge/response authentication protocol in Townsley, et al. Standards Track [Page 4] INTERNET DRAFT L2TP November 2001 which the cleartext password is not passed over the line. DSLAM Digital Subscriber Line (DSL) Access Module. A network device used in the deployment of DSL service. This is typically a concentrator of individual DSL lines located in a central office (CO) or local exchange. Network Access Server (NAS) A device providing local network access to users across a remote access network, such as the PSTN. POTS Plain Old Telephone Service. 2. Topology Although PPP tunneling can be deployed in all of the different tunneling models specified in [L2TP], it is most commonly deployed in the LAC-LNS reference model. The LAC physically terminates the L2 connection and tunnels the PPP packets to the LNS. The LNS then terminates the logical PPP connection. 3. Control Channel Specifics for PPP When PPP is tunneled through L2TP, a session control message, Set- Link-Info (SLI), is used to send PPP-specific link level information from the LNS to the LAC. The SLI is sent by the LNS to the LAC to set any PPP-negotiated options. It is sent after the last LCP CONFACK is received during PPP LCP negotiation. This AVP contains any relevant link level parameters of which the LAC may need to be aware (e.g. ACCM info). If there is no relevant information to be sent in the SLI, then the sending of this message MAY be omitted. Since LCP may be renegotiated at any time, an SLI may be sent at any time during the life of the call. For this reason, the LAC MUST be able to update its internal call information and behavior on an active session. Furthermore, if there are packets in queue at the LAC when an SLI is received, these must be flushed before applying the SLI information to the link. If the PPP session at the LNS renegotiates LCP during the call, an SLI MUST be sent to the LAC to return link level information to the initial default values while the negotiation occurs. However, if the Townsley, et al. Standards Track [Page 5] INTERNET DRAFT L2TP November 2001 last SLI sent was already set to default values or no SLI was sent at all, this step MAY be omitted. The following AVPs MUST be present in the SLI: Message Type This AVP is described in [L2TP]. In the SLI, the value of this attribute is 16. ACCM This AVP is described in Section 5.1.4. 4. Data Channel Specifics for PPP This section describes the encapsulation mechanism for forwarding PPP frames over the L2TP data channel. 4.1 PPP-Specific Sublayer According to the base L2TP specification [L2TP], the header format for the data messages consists of a fixed header followed by a L2-specific sublayer. The PPP sublayer is formatted as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |P|S|x|x| OffSz | Reserved | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Offset padding... (optional, up to 15 octets) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4.1: PPP Sublayer in L2TP Data Message Header If the Priority (P) bit is 1, this data message should receive preferential treatment in its local queuing and transmission. If the Sequence (S) bit is 1, it indicates that the Sequence Number field has meaningful data and that the receiver of this data packet should interpret it accordingly. The x bits are reserved for future extensions. All reserved bits MUST be set to 0 on outgoing messages and ignored on incoming messages. The Offset Size (OffSz) field specifies the number of octets past the PPP sublayer header at which the payload data is expected to start. Townsley, et al. Standards Track [Page 6] INTERNET DRAFT L2TP November 2001 An Offset Size of 0 indicates no offset. Otherwise, the PPP sublayer header ends after the last octet of the Offset Padding. The maximum offset value that may be specified is 15 octets. The Sequence Number field indicates the sequence number for this data message, beginning at zero and incrementing by one (modulo 2**16) for each message sent. See Section 6.1 for more information on using this field. The minimum length for the PPP sublayer is 4 octets (corresponding to an Offset Size of 0). 4.2 Forwarding PPP Frames PPP tunneling via L2TP utilizes both the control connection for session management and the base L2TP encapsulation to tunnel the PPP frames. Both of these mechanisms are defined in [L2TP]. After L2TP control channel establishment (see [L2TP] for details on control channel establishment), PPP frames are tunneled. The PPP frames from the remote system are received at the LAC, stripped of CRC, link framing, and transparency bytes, encapsulated with the PPP sublayer header followed by the fixed L2TP data header [L2TP], and forwarded over the session. The LNS receives the L2TP packet and processes the encapsulated PPP frame as if it were received on a local PPP interface. The LNS assumes the operation of PPP over HDLC and performs the HDLC Address and Control field processing for PPP frames. Besides this HDLC processing, all other framing operations (e.g. CRC, character escaping, etc.) are handled by the LAC. When encapsulating the PPP frame in L2TP, both the LAC and the LNS MUST always include the HDLC header (Address and Control fields) as well as the PPP Protocol ID fields along with the PPP frame. This implies that the LNS MUST always reject the Address and Control Field Compression (ACFC) as well as the Protocol Field Compression (PFC) LCP options. For non-HDLC connections between the LAC and the remote systems, the LAC MUST translate the addressing method to HDLC addressing. 5. AVP Description The base L2TP specification [L2TP] describes the use of service type specific Attribute Value Pairs (AVPs). These AVPs are specific to the L2 payload carried by the L2TP sessions. This section provides a description of all PPP-specific AVPs. It also provides additional PPP-specific information about certain other service-independent AVPs Townsley, et al. Standards Track [Page 7] INTERNET DRAFT L2TP November 2001 when PPP is tunneled by L2TP. Following the name of each AVP is a list indicating the message types that utilize each AVP. These message types are described in the base L2TP specification [L2TP]. After each AVP title follows a short description of the purpose of the AVP, a detail (including a graphic) of the format for the Attribute Value, and any additional information needed for proper use of the AVP. 5.1 PPP-Specific AVPs 5.1.1 Control Connection Management AVPs The AVPs described in this section are included in the control connection messages. Framing Capabilities (SCCRP, SCCRQ) The Framing Capabilities AVP, Attribute Type 3, provides the peer with an indication of the types of PPP framing that will be supported for outgoing call requests. The Attribute Value field for this AVP has the following format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved for future framing type definitions |A|S| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Attribute Value field is a 32-bit mask, with two bits defined. If bit A is set, asynchronous framing is supported. If bit S is set, synchronous framing is supported. The framing capabilities defined in this AVP refer only to the physical interfaces available for dialout usage on an LAC. An LNS MUST not send an OCRQ with a Framing Type AVP specifying a value not advertised in this AVP. Presence of this message is not a guarantee that a given outgoing call will be placed by the sender if requested, just that the physical capability exists. This AVP may be hidden (the H bit may be 0 or 1). The M bit for this AVP MUST be set to 1. The Length (before hiding) is 10. Bearer Capabilities (SCCRP, SCCRQ) The Bearer Capabilities AVP, Attribute Type 4, provides the peer with an indication of the bearer device types supported by the hardware Townsley, et al. Standards Track [Page 8] INTERNET DRAFT L2TP November 2001 interfaces of the sender for outgoing calls. The Attribute Value field for this AVP has the following format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved for future bearer type definitions |V|A|D| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This is a 32-bit mask, with two bits defined. If bit A is set, analog access is supported. If bit D is set, digital access is supported. If bit V is set, virtual access is supported. (Virtual access refers to access in which there is no physical point-to-point link.) The bearer capabilities defined in this AVP refer only to the physical interfaces available for dialout usage on an LAC. An LNS MUST not send an OCRQ with a Bearer Type AVP specifying a value not advertised in this AVP. This AVP MUST be present if the sender can place outgoing calls when requested. Presence of this message is not a guarantee that a given outgoing call will be placed by the sender if requested, just that the physical capability exists. This AVP may be hidden (the H bit may be 0 or 1). The M bit for this AVP MUST be set to 1. The Length (before hiding) is 10. 5.1.2 Call Management AVPs Bearer Type (ICRQ, OCRQ) The Bearer Type AVP, Attribute Type 18, encodes the bearer type for the incoming or outgoing call. The Attribute Value field for this AVP has the following format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved for future Bearer Types |V|A|D| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Bearer Type is a 32-bit bit mask indicating the bearer capability of the call (ICRQ) or required for the call (OCRQ). Bit A refers to an analog channel. Bit D refers to a digital channel. Bit V (virtual) refers to a channel for which there is no physical point- Townsley, et al. Standards Track [Page 9] INTERNET DRAFT L2TP November 2001 to-point link. Bits set in the Bearer Type AVP in an OCRQ message indicate the bearer type(s) on which an outgoing call may be placed. If more than one bit is set, the LAC may choose the bearer type with which to place the call. If no bits are set, any type of available channel may be used. Bits in the Value field of this AVP MUST only be set by the LNS for an OCRQ if the same bit was set in the Bearer Capabilities AVP received from the LAC during control connection establishment. Bits set in the Bearer Type AVP in an ICRQ message indicate the bearer type on which an incoming call was received at the LAC. If no bits are set in an ICRQ, then it is assumed that the bearer type was indeterminable. This AVP may be hidden (the H bit may be 0 or 1). The M bit for this AVP MUST be set to 1. The Length (before hiding) of this AVP is 10. Framing Type (ICCN, OCCN, OCRQ) The Framing Type AVP, Attribute Type 19, encodes the framing type for the incoming or outgoing call. The Attribute Value field for this AVP has the following format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved for future Framing Types |A|S| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Framing Type is a 32-bit mask, which indicates the type of PPP framing requested for an OCRQ, or the type of PPP framing negotiated for an OCCN or ICCN. Bit A indicates asynchronous framing. Bit S indicates synchronous framing. For an OCRQ, both may be set, indicating that the LAC may decide the type of framing to be used. For an ICRQ, only one framing type bit may be set. The framing type SHOULD be used as an indication to PPP on the LNS as to what link options to use for LCP negotiation [RFC1662]. For example, if the A bit is not set in the Framing Type AVP in an ICRQ message and an ACCM LCP option is requested by the PPP client, then the LNS should try to respond with no bits set in the ACCM mask, since the LAC will not likely perform async mapping on a non-async interface. Similarly, if Townsley, et al. Standards Track [Page 10] INTERNET DRAFT L2TP November 2001 the S bit is set, PPP may wish to reject address field compression and protocol field compression options. Bits in the Value field of this AVP MUST only be set by the LNS for an OCRQ if it was set in the Framing Capabilities AVP received from the LAC during control connection establishment. This AVP may be hidden (the H bit may be 0 or 1). The M bit for this AVP MUST be set to 1. The Length (before hiding) of this AVP is 10. Called Number (ICRQ, OCRQ) The Called Number AVP, Attribute Type 21, encodes the telephone number to be called for an OCRQ, and the called number for an ICRQ. The Attribute Value field for this AVP has the following format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Called Number... (arbitrary number of octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Called Number is an ASCII string. Contact between the administrator of the LAC and the LNS may be necessary to coordinate interpretation of the value needed in this AVP. This AVP may be hidden (the H bit may be 0 or 1). The M bit for this AVP MUST be set to 1. The Length (before hiding) of this AVP is 6 plus the length of the Called Number. Calling Number (ICRQ) The Calling Number AVP, Attribute Type 22, encodes the originating number for the incoming call. The Attribute Value field for this AVP has the following format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Calling Number... (arbitrary number of octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Calling Number is an ASCII string. Contact between the administrator of the LAC and the LNS may be necessary to coordinate interpretation of the value in this AVP. Townsley, et al. Standards Track [Page 11] INTERNET DRAFT L2TP November 2001 This AVP may be hidden (the H bit may be 0 or 1). The M bit for this AVP MUST be set to 1. The Length (before hiding) of this AVP is 6 plus the length of the Calling Number. Sub-Address (ICRQ, OCRQ) The Sub-Address AVP, Attribute Type 23, encodes additional dialing information. For instance, it can be used by the LNS to encode the ISDN sub-address information for an outgoing call request. The Attribute Value field for this AVP has the following format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Address ... (arbitrary number of octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Sub-Address is an ASCII string. Contact between the administrator of the LAC and the LNS may be necessary to coordinate interpretation of the value in this AVP. This AVP may be hidden (the H bit may be 0 or 1). The M bit for this AVP MUST be set to 1. The Length (before hiding) of this AVP is 6 plus the length of the Sub-Address. Q.931 Cause Code (CDN) The Q.931 Cause Code AVP, Attribute Type 12, is used to give additional information in case of unsolicited call disconnection. The Attribute Value field for this AVP has the following format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code | Cause Msg | Advisory Msg... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Cause Code field is the returned Q.931 cause code, and the Cause Msg field is the returned Q.931 message code (e.g., DISCONNECT) associated with the cause code. Both values are returned in their native ITU encodings [DSS1]. An additional ASCII text Advisory Message may also be included (presence indicated by the AVP Length) to further explain the reason for disconnecting. This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for this AVP MUST be set to 1. The Length of this AVP is 9, plus the Townsley, et al. Standards Track [Page 12] INTERNET DRAFT L2TP November 2001 size of the Advisory Message. Sequencing Required (ICCN, OCCN, ICRP, OCRQ) The Sequencing Required AVP, Attribute Type 39, indicates to the peer that Sequence Numbers MUST always be present on the data channel. This AVP has no Attribute Value field. This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for this AVP MUST be set to 1. The Length of this AVP is 6. 5.1.3 Proxy LCP and Authentication AVPs The LAC may have answered the call and negotiated LCP with the remote system, perhaps in order to establish the system's apparent identity. In this case, these AVPs may be included to indicate, first, the link properties the remote system initially requested, and second, the properties the remote system and LAC ultimately negotiated. In addition, the authentication information can be sent by the LAC by including the proxy authentication AVPs. This information may be used to initiate the PPP LCP and authentication states on the LNS, allowing PPP to continue without renegotiation of LCP. Note that the LNS policy may be to enter an additional round of LCP negotiation and/or authentication if the LAC is not trusted. Initial Received LCP CONFREQ (ICCN) In the Initial Received LCP CONFREQ AVP, Attribute Type 26, the LAC provides the LNS with the Initial CONFREQ received by the LAC from the PPP Peer. The Attribute Value field for this AVP has the following format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LCP CONFREQ... (arbitrary number of octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The LCP CONFREQ is a copy of the body of the initial CONFREQ received, starting at the first option within the body of the LCP message. This AVP may be hidden (the H bit may be 0 or 1). The M bit for this AVP MUST be set to 0. The Length (before hiding) of this AVP is 6 plus the length of the CONFREQ. Townsley, et al. Standards Track [Page 13] INTERNET DRAFT L2TP November 2001 Last Sent LCP CONFREQ (ICCN) In the Last Sent LCP CONFREQ AVP, Attribute Type 27, provides the LNS with the Last CONFREQ sent by the LAC to the PPP Peer. The Attribute Value field for this AVP has the following format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LCP CONFREQ... (arbitrary number of octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The LCP CONFREQ is a copy of the body of the final CONFREQ sent to the client to complete LCP negotiation, starting at the first option within the body of the LCP message. This AVP may be hidden (the H bit may be 0 or 1). The M bit for this AVP MUST be set to 0. The Length (before hiding) of this AVP is 6 plus the length of the CONFREQ. Last Received LCP CONFREQ (ICCN) The Last Received LCP CONFREQ AVP, Attribute Type 28, provides the LNS with the Last CONFREQ received by the LAC from the PPP Peer. The Attribute Value field for this AVP has the following format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LCP CONFREQ... (arbitrary number of octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The LCP CONFREQ is a copy of the body of the final CONFREQ received from the client to complete LCP negotiation, starting at the first option within the body of the LCP message. This AVP may be hidden (the H bit may be 0 or 1). The M bit for this AVP MUST be set to 0. The Length (before hiding) of this AVP is 6 plus the length of the CONFREQ. Proxy Authen Type (ICCN) The Proxy Authen Type AVP, Attribute Type 29, indicates the type of authentication that was performed for this call by the LAC, if any. The Attribute Value field for this AVP has the following format: Townsley, et al. Standards Track [Page 14] INTERNET DRAFT L2TP November 2001 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authen Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Authen Type is a 2-octet unsigned integer. Defined Authen Type values are: 0 - Reserved 1 - Textual username/password exchange 2 - PPP CHAP 3 - PPP PAP 4 - No authentication 5 - Microsoft CHAP Version 1 (MSCHAPv1) TBA - Microsoft CHAP Version 2 (MSCHAPv2) TBA - PPP EAP TBA - Others This AVP MUST be present if proxy authentication is to be utilized. If it is not present, then it is assumed that this peer cannot perform proxy authentication. In this case, a restart of the authentication phase at the LNS is required if the client has already entered this phase with the LAC (which may be determined by the presence of the Proxy LCP AVP). This AVP may be hidden (the H bit may be 0 or 1). The M bit for this AVP MUST be set to 0. The Length (before hiding) of this AVP is 8. Associated AVPs for each type of authentication follow. Proxy Authen Name (ICCN) The Proxy Authen Name AVP, Attribute Type 30, specifies the name of the authenticating client when using proxy authentication. The Attribute Value field for this AVP has the following format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authen Name... (arbitrary number of octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Authen Name is a string of octets of arbitrary length. It contains the name specified in the client's authentication response. This AVP MUST be present in messages containing a Proxy Authen Type Townsley, et al. Standards Track [Page 15] INTERNET DRAFT L2TP November 2001 AVP with an Authen Type of 1, 2, 3 or 5. It may be desirable to employ AVP hiding for obscuring the cleartext name. This AVP may be hidden (the H bit may be 0 or 1). The M bit for this AVP MUST be set to 0. The Length (before hiding) is 6 plus the length of the cleartext name. Proxy Authen Challenge (ICCN) The Proxy Authen Challenge AVP, Attribute Type 31, specifies the challenge sent by the LAC to the PPP Peer when using proxy authentication. The Attribute Value field for this AVP has the following format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Challenge... (arbitrary number of octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Challenge is a string of one or more octets. This AVP MUST be present for Proxy Authen Types 2 and 5. The Challenge field contains the CHAP challenge presented to the client by the LAC. This AVP may be hidden (the H bit may be 0 or 1). The M bit for this AVP MUST be set to 0. The Length (before hiding) of this AVP is 6, plus the length of the Challenge. Proxy Authen ID (ICCN) The Proxy Authen ID AVP, Attribute Type 32, specifies the ID value of the PPP Authentication that was started between the LAC and the PPP Peer when proxy authentication is being used. The Attribute Value field for this AVP has the following format: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ID is a 2-octet unsigned integer. The most significant octet MUST be 0. Townsley, et al. Standards Track [Page 16] INTERNET DRAFT L2TP November 2001 The Proxy Authen ID AVP MUST be present for Proxy Authen Types 2, 3 and 5. For 2 and 5, the ID field contains the byte ID value presented to the client by the LAC in its Challenge. For 3, it is the Identifier value of the Authenticate-Request. This AVP may be hidden (the H bit may be 0 or 1). The M bit for this AVP MUST be set to 0. Proxy Authen Response (ICCN) The Proxy Authen Response AVP, Attribute Type 33, specifies the PPP Authentication response received by the LAC from the PPP Peer, when proxy authentication is used. The Attribute Value field for this AVP has the following format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Response... (arbitrary number of octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Response is a string of octets. This AVP MUST be present for Proxy Authen Types 1, 2, 3 and 5. The Response field contains the client's response to the challenge. For Proxy Authen Types 2 and 5, this field contains the response value received by the LAC. For 1 and 3, it contains the cleartext password received from the client by the LAC. In the case of cleartext passwords, AVP hiding is recommended. This AVP may be hidden (the H bit may be 0 or 1). The M bit for this AVP MUST be set to 0. The Length (before hiding) of this AVP is 6 plus the length of the Response. 5.1.4 Call Status AVPs ACCM (SLI) The ACCM AVP, Attribute Type 35, is used by the LNS to inform LAC of the ACCM negotiated with the PPP Peer by the LNS. The Attribute Value field for this AVP has the following format: Townsley, et al. Standards Track [Page 17] INTERNET DRAFT L2TP November 2001 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Send ACCM (H) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Send ACCM (L) | Receive ACCM (H) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receive ACCM (L) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Send ACCM and Receive ACCM fields are 4-octet values preceded by a 2-octet reserved quantity. The Send ACCM value should be used by the LAC to process packets it sends on the connection. The Receive ACCM value should be used by the LAC to process incoming packets on the connection. The default values used by the LAC for both these fields are 0xFFFFFFFF. The LAC should honor these fields unless it has specific configuration information to indicate that the requested mask must be modified to permit operation. This AVP may be hidden (the H bit MAY be 1 or 0). The M bit for this AVP MUST be set to 1. The Length of this AVP is 16. 5.2 Service Type Independent AVPs The base L2TP specification [L2TP] gives a detailed description of these AVPs. However, the AVP values described in [L2TP] should be interpreted differently for different service type payloads carried by L2TP. This section describes the AVP values in the context of PPP payload. This section should be read in conjunction with the relevant sections from [L2TP]. Minimum BPS (OCRQ) The Minimum BPS AVP, Attribute Type 16, encodes the lowest acceptable line speed for this call over a dial-up network. This is the lowest acceptable line speed in the transmit direction (i.e. the direction from the LAC to the user). The Attribute Value field for this AVP has the following format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Minimum BPS | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Minimum BPS is a 32-bit value indicating the speed in bits per second. Townsley, et al. Standards Track [Page 18] INTERNET DRAFT L2TP November 2001 This AVP may be hidden (the H bit may be 0 or 1). The M bit for this AVP MUST be set to 1. The Length (before hiding) of this AVP is 10. Maximum BPS (OCRQ) The Maximum BPS AVP, Attribute Type 17, encodes the highest acceptable line speed for this call in the transmit direction (i.e. from LAC to the user). The Attribute Value field for this AVP has the following format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Maximum BPS | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Maximum BPS is a 32-bit value indicating the speed in bits per second. This speed is the line speed (for example, modem connect speed) in the transmit direction. This AVP may be hidden (the H bit may be 0 or 1). The M bit for this AVP MUST be set to 1. The Length (before hiding) of this AVP is 10. 6. Data Channel Sequencing This section describes the method for using sequence numbers on the L2TP data plane carrying PPP frames. It also provides guidelines on when to use these sequence numbers. 6.1 Sequence Numbers The Sequence Number field defined in the PPP sublayer header allows an LCCE to convey sequence information to a peer. Unlike the L2TP control plane, the L2TP data plane carrying PPP frames does not use sequencing to retransmit lost data messages. Rather, sequencing may be used to detect lost packets and/or restore the original sequence of packets that may have been reordered during traversal of the packet network. The sequence number begins at 0. Each subsequent message is sent with the next increment of the sequence number. The sequence number is thus a free-running counter represented modulo 2**16. The sequence number in the header of a received message is considered less than or equal to the last received number if its value lies in the range of the last received number and the preceding (2**16 - 1) values, inclusive. For example, if the last received sequence number was 15, then messages with sequence numbers 0 through 15, as well as Townsley, et al. Standards Track [Page 19] INTERNET DRAFT L2TP November 2001 32784 through 65535, would be considered less than or equal. Usage of this field is a matter of local policy for each LCCE. An LCCE SHOULD update the Sequence Number field in the manner described above for outgoing packets. If an LCCE chooses to update the Sequence Number field for outgoing packets, it MUST set the Sequence bit in the PPP sublayer header to 1 (see Section 4.1). In the other direction, an LCCE may choose to honor the sequence numbers received in incoming messages. The precise mechanism for dealing with reordered or lost packets is also a matter of local policy. Alternatively, an LCCE may choose to ignore sequence numbers altogether. One LCCE may convey to its peer that the Sequence Number field will be honored for incoming data messages by sending the Sequencing Required AVP. If this AVP is sent during session establishment, it is recommended that the peer update the Sequence Number field in the manner described above. 6.2 Data Channel Sequencing over Specific Media When PPP frames are carried over an L2TP-over-IP or L2TP-over-UDP/IP data channel to the PPP client, this link has the characteristic of being able to reorder or silently drop packets. Reordering may break non-IP protocols being carried by PPP, especially LAN-centric ones such as bridging. Silent dropping of packets may break protocols that assume per-packet indication of error, such as TCP header compression. If any protocol being transported by PPP over these L2TP data channels cannot tolerate reordering, sequencing may be turned on by using the sequence number field in the PPP sublayer header. The sequence dependency characteristics of individual protocols are outside the scope of this document. Allowing packets to be dropped silently is perhaps more problematic with some protocols. If PPP reliable delivery [RFC1663] is enabled, no upper PPP protocol will encounter lost packets. If sequence numbers are enabled, L2TP can detect the packet loss. In the case of an LNS, the PPP and L2TP stacks are both present within the LNS, and packet loss signaling may occur precisely as if a packet was received with a CRC error. Where the LAC and PPP stack are co-resident, this technique also applies. Where the LAC and PPP client are physically distinct, the analogous signaling MAY be accomplished by sending a packet with a CRC error to the PPP client. Note that this would greatly increase the complexity of debugging client line problems, since the client statistics could not distinguish between true media errors and LAC-initiated ones. Further, this technique is not Townsley, et al. Standards Track [Page 20] INTERNET DRAFT L2TP November 2001 possible on all hardware. If VJ compression is used, and neither PPP reliable delivery nor sequence numbers are enabled, each lost packet results in a 1 in 2**16 chance of a TCP segment being forwarded with incorrect contents [RFC1144]. Where the combination of the packet loss rate with this statistical exposure is unacceptable, TCP header compression SHOULD NOT be used. In general, it is wise to remember that the L2TP-over-IP as well as the L2TP-over-UDP/IP transports are unreliable transport media. As with any PPP medium that is subject to loss, care should be taken when using protocols that are particularly loss-sensitive. Such protocols include compression and encryption protocols that employ history. 7. IANA Considerations This document defines "magic" numbers to be maintained by the IANA. This section explains the criteria to be used by the IANA to assign additional numbers in each of these lists. The following subsections describe the assignment policy for the namespaces defined elsewhere in this document. 7.1 AVP Attributes As defined in [L2TP], AVPs contain Vendor ID, Attribute, and Value fields. For a Vendor ID value of 0, IANA will maintain a registry of assigned Attributes for PPP-specific AVPs described in Section 3.1, and in some cases, values for those attributes. 7.2 SLI Message Type Section 3 of this document defines the value 16 for the SLI message type. This value will be maintained by the IANA. 7.3 Framing Capabilities and Bearer Capabilities The Framing Capabilities AVP and Bearer Capabilities AVP (defined in Section 5.1) both contain 32-bit bitmasks. Additional bits should only be defined via a Standards Action [RFC 2434]. 7.4 Framing Type and Bearer Type The Framing Type AVP and Bearer Type AVP (defined in Section 5.1) both contain 32-bit bitmasks. Additional bits should only be defined via a Standards Action [RFC 2434]. Townsley, et al. Standards Track [Page 21] INTERNET DRAFT L2TP November 2001 7.5 Proxy Authen Type AVP Values The Proxy Authen Type AVP (Attribute Type 29) has an associated value maintained by IANA. Values 0-5 are defined in Section 5.1, the remaining values are available for assignment upon Expert Review [RFC 2434]. 7.6 PPP Sublayer Header Bits There are three remaining reserved bits in the PPP Sublayer header. Additional bits should only be assigned via a Standards Action [RFC 2434]. 8. References [L2TP] J. Lau, M. Townsley, A. Valencia, G. Zorn, I. Goyret, G. Singh Pall, A. Rubens, B. Palter, "Layer Two Tunneling Protocol (L2TP)", , July 2001 [RFC2661] W.M. Townsley, A. Valencia, A. Rubens, G. Singh Pall, G. Zorn, B. Palter, "Layer Two Tunneling Protocol (L2TP)", RFC 2661, August 1999 [DSS1] ITU-T Recommendation, "Digital subscriber Signaling System No. 1 (DSS 1) - ISDN user-network interface layer 3 specification for basic call control", Rec. Q.931(I.451), May 1998 [KPS] Kaufman, C., Perlman, R., and Speciner, M., "Network Security: Private Communications in a Public World", Prentice Hall, March 1995, ISBN 0-13-061466-1 [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987. [RFC1144] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed Serial Links", RFC 1144, February 1990. [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994. [RFC1662] Simpson, W., "PPP in HDLC-like Framing", STD 51, RFC 1662, July 1994. [RFC1663] Rand, D., "PPP Reliable Transmission", RFC 1663, July 1994. Townsley, et al. Standards Track [Page 22] INTERNET DRAFT L2TP November 2001 [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994. See also: http://www.iana.org/numbers.html [RFC1990] Sklower, K., Lloyd, B., McGregor, G., Carr, D. and T. Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990, August 1996. [RFC1994] Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996. [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2138] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC 2138, April 1997. [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998. [RFC2341] Valencia, A., Littlewood, M. and T. Kolar, "Cisco Layer Two Forwarding (Protocol) L2F", RFC 2341, May 1998. [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations section in RFCs", BCP 26, RFC 2434, October 1998. [RFC2637] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W. and G. Zorn, "Point-to-Point Tunneling Protocol (PPTP)", RFC 2637, July 1999. [STEVENS] Stevens, W. Richard, "TCP/IP Illustrated, Volume I The Protocols", Addison-Wesley Publishing Company, Inc., March 1996, ISBN 0-201-63346-9 9. Acknowledgments The basic concept for L2TP and many of its protocol constructs were adopted from L2F [RFC2341] and PPTP [RFC2637]. Authors of these are A. Valencia, M. Littlewood, T. Kolar, K. Hamzeh, G. Pall, W. Townsley, et al. Standards Track [Page 23] INTERNET DRAFT L2TP November 2001 Verthein, J. Taarud, W. Little, and G. Zorn. The L2TP rewrite team for splitting RFC2661 into the base and companion PPP specifications consisted of Ignacio Goyret, Jed Lau, Bill Palter, Mark Townsley, and Madhvi Verma. This document was based upon RFC2661, for which a number of people provided valuable input and effort. John Bray, Greg Burns, Rich Garrett, Don Grosser, Matt Holdrege, Terry Johnson, Dory Leifer, and Rich Shea provided valuable input and review at the 43rd IETF in Orlando, FL., which led to improvement of the overall readability and clarity of RFC2661. Thomas Narten provided a great deal of critical review, formatting, and wrote the IANA Considerations section. Dory Leifer made valuable refinements to the protocol definition of L2TP and contributed to the editing of early drafts leading to RFC2661. Steve Cobb and Evan Caves redesigned the state machine tables. Barney Wolff provided a great deal of design input on the endpoint authentication mechanism. 10. Authors' Addresses Ignacio Goyret Lucent Technologies 1701 Harbor Bay Parkway Alameda, CA 94502 Email: igoyret@lucent.com Jed Lau cisco Systems 170 W. Tasman Drive San Jose, CA 95134 Email: jedlau@cisco.com Gurdeep Singh Pall Microsoft Corporation Redmond, WA Email: gurdeep@microsoft.com Townsley, et al. Standards Track [Page 24] INTERNET DRAFT L2TP November 2001 Bill Palter RedBack Networks, Inc 1389 Moffett Park Drive Sunnyvale, CA 94089 Email: palter@zev.net Allan Rubens Email: acr@del.com W. Mark Townsley cisco Systems 7025 Kit Creek Road PO Box 14987 Research Triangle Park, NC 27709 Email: mark@townsley.net Andrew J. Valencia P.O. Box 2928 Vashon, WA 98070 Email: vandys@zendo.com Madhvi Verma CommWorks, a 3Com company 3800 Golf Road Rolling Meadows, IL 60008 Email: madhvi_verma@3com.com Glen Zorn cisco Systems 500 108th Avenue N.E., Suite 500 Bellevue, WA 98004 Email: gwz@cisco.com Townsley, et al. Standards Track [Page 25]