diff options
Diffstat (limited to 'rfc')
| -rw-r--r-- | rfc/rfc2661.txt | 4483 | ||||
| -rw-r--r-- | rfc/rfc3931.txt | 5267 |
2 files changed, 9750 insertions, 0 deletions
diff --git a/rfc/rfc2661.txt b/rfc/rfc2661.txt new file mode 100644 index 00000000..78f01d7e --- /dev/null +++ b/rfc/rfc2661.txt @@ -0,0 +1,4483 @@ + + + + + + +Network Working Group W. Townsley +Request for Comments: 2661 A. Valencia +Category: Standards Track cisco Systems + A. Rubens + Ascend Communications + G. Pall + G. Zorn + Microsoft Corporation + B. Palter + Redback Networks + August 1999 + + + Layer Two Tunneling Protocol "L2TP" + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (1999). All Rights Reserved. + +Abstract + + This document describes the Layer Two Tunneling Protocol (L2TP). STD + 51, RFC 1661 specifies multi-protocol access via PPP [RFC1661]. L2TP + facilitates the tunneling of PPP packets across an intervening + network in a way that is as transparent as possible to both end-users + and applications. + +Table of Contents + + 1.0 Introduction.......................................... 3 + 1.1 Specification of Requirements......................... 4 + 1.2 Terminology........................................... 4 + 2.0 Topology.............................................. 8 + 3.0 Protocol Overview..................................... 9 + 3.1 L2TP Header Format.................................... 9 + 3.2 Control Message Types................................. 11 + 4.0 Control Message Attribute Value Pairs................. 12 + 4.1 AVP Format............................................ 13 + 4.2 Mandatory AVPs........................................ 14 + 4.3 Hiding of AVP Attribute Values........................ 14 + + + +Townsley, et al. Standards Track [Page 1] + +RFC 2661 L2TP August 1999 + + + 4.4 AVP Summary........................................... 17 + 4.4.1 AVPs Applicable To All Control Messages.......... 17 + 4.4.2 Result and Error Codes........................... 18 + 4.4.3 Control Connection Management AVPs............... 20 + 4.4.4 Call Management AVPs............................. 27 + 4.4.5 Proxy LCP and Authentication AVPs................ 34 + 4.4.6 Call Status AVPs................................. 39 + 5.0 Protocol Operation.................................... 41 + 5.1 Control Connection Establishment...................... 41 + 5.1.1 Tunnel Authentication............................ 42 + 5.2 Session Establishment................................. 42 + 5.2.1 Incoming Call Establishment...................... 42 + 5.2.2 Outgoing Call Establishment...................... 43 + 5.3 Forwarding PPP Frames................................. 43 + 5.4 Using Sequence Numbers on the Data Channel............ 44 + 5.5 Keepalive (Hello)..................................... 44 + 5.6 Session Teardown...................................... 45 + 5.7 Control Connection Teardown........................... 45 + 5.8 Reliable Delivery of Control Messages................. 46 + 6.0 Control Connection Protocol Specification............. 48 + 6.1 Start-Control-Connection-Request (SCCRQ).............. 48 + 6.2 Start-Control-Connection-Reply (SCCRP)................ 48 + 6.3 Start-Control-Connection-Connected (SCCCN)............ 49 + 6.4 Stop-Control-Connection-Notification (StopCCN)........ 49 + 6.5 Hello (HELLO)......................................... 49 + 6.6 Incoming-Call-Request (ICRQ).......................... 50 + 6.7 Incoming-Call-Reply (ICRP)............................ 51 + 6.8 Incoming-Call-Connected (ICCN)........................ 51 + 6.9 Outgoing-Call-Request (OCRQ).......................... 52 + 6.10 Outgoing-Call-Reply (OCRP)........................... 53 + 6.11 Outgoing-Call-Connected (OCCN)....................... 53 + 6.12 Call-Disconnect-Notify (CDN)......................... 53 + 6.13 WAN-Error-Notify (WEN)............................... 54 + 6.14 Set-Link-Info (SLI).................................. 54 + 7.0 Control Connection State Machines..................... 54 + 7.1 Control Connection Protocol Operation................. 55 + 7.2 Control Connection States............................. 56 + 7.2.1 Control Connection Establishment................. 56 + 7.3 Timing considerations................................. 58 + 7.4 Incoming calls........................................ 58 + 7.4.1 LAC Incoming Call States......................... 60 + 7.4.2 LNS Incoming Call States......................... 62 + 7.5 Outgoing calls........................................ 63 + 7.5.1 LAC Outgoing Call States......................... 64 + 7.5.2 LNS Outgoing Call States......................... 66 + 7.6 Tunnel Disconnection.................................. 67 + 8.0 L2TP Over Specific Media.............................. 67 + 8.1 L2TP over UDP/IP...................................... 68 + + + +Townsley, et al. Standards Track [Page 2] + +RFC 2661 L2TP August 1999 + + + 8.2 IP.................................................... 69 + 9.0 Security Considerations............................... 69 + 9.1 Tunnel Endpoint Security.............................. 70 + 9.2 Packet Level Security................................. 70 + 9.3 End to End Security................................... 70 + 9.4 L2TP and IPsec........................................ 71 + 9.5 Proxy PPP Authentication.............................. 71 + 10.0 IANA Considerations.................................. 71 + 10.1 AVP Attributes....................................... 71 + 10.2 Message Type AVP Values.............................. 72 + 10.3 Result Code AVP Values............................... 72 + 10.3.1 Result Code Field Values........................ 72 + 10.3.2 Error Code Field Values......................... 72 + 10.4 Framing Capabilities & Bearer Capabilities........... 72 + 10.5 Proxy Authen Type AVP Values......................... 72 + 10.6 AVP Header Bits...................................... 73 + 11.0 References........................................... 73 + 12.0 Acknowledgments...................................... 74 + 13.0 Authors' Addresses................................... 75 + Appendix A: Control Channel Slow Start and Congestion + Avoidance..................................... 76 + Appendix B: Control Message Examples...................... 77 + Appendix C: Intellectual Property Notice.................. 79 + Full Copyright Statement.................................. 80 + +1.0 Introduction + + PPP [RFC1661] defines an encapsulation mechanism for transporting + multiprotocol packets across layer 2 (L2) point-to-point links. + Typically, a user obtains a L2 connection to a Network Access Server + (NAS) using one of a number of techniques (e.g., dialup POTS, ISDN, + ADSL, etc.) and 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). + + L2TP extends the PPP model by allowing the L2 and PPP endpoints to + reside on different devices interconnected by a packet-switched + network. With L2TP, a user has an L2 connection to an access + concentrator (e.g., modem bank, ADSL DSLAM, etc.), and the + concentrator then tunnels individual PPP frames to the NAS. This + allows the actual processing of PPP packets to be divorced from the + termination of the L2 circuit. + + One obvious benefit of such a separation is that instead of requiring + the L2 connection terminate at the NAS (which may require a + long-distance toll charge), the connection may terminate at a (local) + circuit concentrator, which then extends the logical PPP session over + + + + +Townsley, et al. Standards Track [Page 3] + +RFC 2661 L2TP August 1999 + + + a shared infrastructure such as frame relay circuit or the Internet. + From the user's perspective, there is no functional difference between + having the L2 circuit terminate in a NAS directly or using L2TP. + + L2TP may also solve the multilink hunt-group splitting problem. + Multilink PPP [RFC1990] requires that all channels composing a + multilink bundle be grouped at a single Network Access Server (NAS). + Due to its ability to project a PPP session to a location other than + the point at which it was physically received, L2TP can be used to + make all channels terminate at a single NAS. This allows multilink + operation even when the calls are spread across distinct physical + NASs. + + This document defines the necessary control protocol for on-demand + creation of tunnels between two nodes and the accompanying + encapsulation for multiplexing multiple, tunneled PPP sessions. + +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 + + Analog Channel + + A circuit-switched communication path which is intended to carry + 3.1 kHz audio in each direction. + + Attribute Value Pair (AVP) + + The variable length concatenation of a unique Attribute + (represented by an integer) and a Value containing the actual + value identified by the attribute. Multiple AVPs make up Control + Messages which are used in the establishment, maintenance, and + teardown of tunnels. + + Call + + A connection (or attempted connection) between a Remote System and + LAC. For example, a telephone call through the PSTN. A Call + (Incoming or Outgoing) which is successfully established between a + Remote System and LAC results in a corresponding L2TP Session + within a previously established Tunnel between the LAC and LNS. + (See also: Session, Incoming Call, Outgoing Call). + + + + + +Townsley, et al. Standards Track [Page 4] + +RFC 2661 L2TP August 1999 + + + Called Number + + An indication to the receiver of a call as to what telephone + number the caller used to reach it. + + Calling Number + + An indication to the receiver of a call as to the telephone number + of the caller. + + CHAP + + Challenge Handshake Authentication Protocol [RFC1994], a PPP + cryptographic challenge/response authentication protocol in which + the cleartext password is not passed over the line. + + Control Connection + + A control connection operates in-band over a tunnel to control the + establishment, release, and maintenance of sessions and of the + tunnel itself. + + Control Messages + + Control messages are exchanged between LAC and LNS pairs, + operating in-band within the tunnel protocol. Control messages + govern aspects of the tunnel and sessions within the tunnel. + + Digital Channel + + A circuit-switched communication path which is intended to carry + digital information in each direction. + + 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. + + Incoming Call + + A Call received at an LAC to be tunneled to an LNS (see Call, + Outgoing Call). + + + + + + + +Townsley, et al. Standards Track [Page 5] + +RFC 2661 L2TP August 1999 + + + L2TP Access Concentrator (LAC) + + A node that acts as one side of an L2TP tunnel endpoint and is a + peer to the L2TP Network Server (LNS). The LAC sits between an + LNS and a remote system and forwards packets to and from each. + Packets sent from the LAC to the LNS requires tunneling with the + L2TP protocol as defined in this document. The connection from + the LAC to the remote system is either local (see: Client LAC) or + a PPP link. + + L2TP Network Server (LNS) + + A node that acts as one side of an L2TP tunnel endpoint and is a + peer to the L2TP Access Concentrator (LAC). The LNS is the + logical termination point of a PPP session that is being tunneled + from the remote system by the LAC. + + Management Domain (MD) + + A network or networks under the control of a single + administration, policy or system. For example, an LNS's Management + Domain might be the corporate network it serves. An LAC's + Management Domain might be the Internet Service Provider that owns + and manages it. + + Network Access Server (NAS) + + A device providing local network access to users across a remote + access network such as the PSTN. An NAS may also serve as an LAC, + LNS or both. + + Outgoing Call + + A Call placed by an LAC on behalf of an LNS (see Call, Incoming + Call). + + Peer + + When used in context with L2TP, peer refers to either the LAC or + LNS. An LAC's Peer is an LNS and vice versa. When used in context + with PPP, a peer is either side of the PPP connection. + + POTS + + Plain Old Telephone Service. + + + + + + +Townsley, et al. Standards Track [Page 6] + +RFC 2661 L2TP August 1999 + + + Remote System + + An end-system or router attached to a remote access network (i.e. + a PSTN), which is either the initiator or recipient of a call. + Also referred to as a dial-up or virtual dial-up client. + + Session + + L2TP is connection-oriented. The LNS and LAC maintain state for + each Call that is initiated or answered by an LAC. An L2TP Session + is created between the LAC and LNS when an end-to-end PPP + connection is established between a Remote System and the LNS. + Datagrams related to the PPP connection are sent over the Tunnel + between the LAC and LNS. There is a one to one relationship + between established L2TP Sessions and their associated Calls. (See + also: Call). + + Tunnel + + A Tunnel exists between a LAC-LNS pair. The Tunnel consists of a + Control Connection and zero or more L2TP Sessions. The Tunnel + carries encapsulated PPP datagrams and Control Messages between + the LAC and the LNS. + + Zero-Length Body (ZLB) Message + + A control packet with only an L2TP header. ZLB messages are used + for explicitly acknowledging packets on the reliable control + channel. + + + + + + + + + + + + + + + + + + + + + + +Townsley, et al. Standards Track [Page 7] + +RFC 2661 L2TP August 1999 + + +2.0 Topology + + The following diagram depicts a typical L2TP scenario. The goal is to + tunnel PPP frames between the Remote System or LAC Client and an LNS + located at a Home LAN. + + [Home LAN] + [LAC Client]----------+ | + ____|_____ +--[Host] + | | | + [LAC]---------| Internet |-----[LNS]-----+ + | |__________| | + _____|_____ : + | | + | PSTN | + [Remote]--| Cloud | + [System] | | [Home LAN] + |___________| | + | ______________ +---[Host] + | | | | + [LAC]-------| Frame Relay |---[LNS]-----+ + | or ATM Cloud | | + |______________| : + + The Remote System initiates a PPP connection across the PSTN Cloud to + an LAC. The LAC then tunnels the PPP connection across the Internet, + Frame Relay, or ATM Cloud to an LNS whereby access to a Home LAN is + obtained. The Remote System is provided addresses from the HOME LAN + + via PPP NCP negotiation. Authentication, Authorization and Accounting + may be provided by the Home LAN's Management Domain as if the user + were connected to a Network Access Server directly. + + A LAC Client (a Host which runs L2TP natively) may also participate + in tunneling to the Home LAN without use of a separate LAC. In this + case, the Host containing the LAC Client software already has a + connection to the public Internet. A "virtual" PPP connection is then + created and the local L2TP LAC Client software creates a tunnel to + the LNS. As in the above case, Addressing, Authentication, + Authorization and Accounting will be provided by the Home LAN's + Management Domain. + + + + + + + + + + +Townsley, et al. Standards Track [Page 8] + +RFC 2661 L2TP August 1999 + + +3.0 Protocol Overview + + L2TP utilizes two types of messages, control messages and data + messages. Control messages are used in the establishment, maintenance + and clearing of tunnels and calls. Data messages are used to + encapsulate PPP frames being carried over the tunnel. Control + messages utilize a reliable Control Channel within L2TP to guarantee + delivery (see section 5.1 for details). Data messages are not + retransmitted when packet loss occurs. + + +-------------------+ + | PPP Frames | + +-------------------+ +-----------------------+ + | L2TP Data Messages| | L2TP Control Messages | + +-------------------+ +-----------------------+ + | L2TP Data Channel | | L2TP Control Channel | + | (unreliable) | | (reliable) | + +------------------------------------------------+ + | Packet Transport (UDP, FR, ATM, etc.) | + +------------------------------------------------+ + + Figure 3.0 L2TP Protocol Structure + + Figure 3.0 depicts the relationship of PPP frames and Control + Messages over the L2TP Control and Data Channels. PPP Frames are + passed over an unreliable Data Channel encapsulated first by an L2TP + header and then a Packet Transport such as UDP, Frame Relay, ATM, + etc. Control messages are sent over a reliable L2TP Control Channel + which transmits packets in-band over the same Packet Transport. + + Sequence numbers are required to be present in all control messages + and are used to provide reliable delivery on the Control Channel. + Data Messages may use sequence numbers to reorder packets and detect + lost packets. + + All values are placed into their respective fields and sent in + network order (high order octets first). + +3.1 L2TP Header Format + + L2TP packets for the control channel and data channel share a common + header format. In each case where a field is optional, its space does + not exist in the message if the field is marked not present. Note + that while optional on data messages, the Length, Ns, and Nr fields + marked as optional below, are required to be present on all control + messages. + + + + + +Townsley, et al. Standards Track [Page 9] + +RFC 2661 L2TP August 1999 + + + This header is formatted: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |T|L|x|x|S|x|O|P|x|x|x|x| Ver | Length (opt) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Tunnel ID | Session ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Ns (opt) | Nr (opt) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Offset Size (opt) | Offset pad... (opt) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 3.1 L2TP Message Header + + The Type (T) bit indicates the type of message. It is set to 0 for a + data message and 1 for a control message. + + If the Length (L) bit is 1, the Length field is present. This bit + MUST be set to 1 for control messages. + + The x bits are reserved for future extensions. All reserved bits MUST + be set to 0 on outgoing messages and ignored on incoming messages. + + If the Sequence (S) bit is set to 1 the Ns and Nr fields are present. + The S bit MUST be set to 1 for control messages. + + If the Offset (O) bit is 1, the Offset Size field is present. The O + bit MUST be set to 0 (zero) for control messages. + + If the Priority (P) bit is 1, this data message should receive + preferential treatment in its local queuing and transmission. LCP + echo requests used as a keepalive for the link, for instance, should + generally be sent with this bit set to 1. Without it, a temporary + interval of local congestion could result in interference with + keepalive messages and unnecessary loss of the link. This feature is + only for use with data messages. The P bit MUST be set to 0 for all + control messages. + + Ver MUST be 2, indicating the version of the L2TP data message header + described in this document. The value 1 is reserved to permit + detection of L2F [RFC2341] packets should they arrive intermixed with + L2TP packets. Packets received with an unknown Ver field MUST be + discarded. + + The Length field indicates the total length of the message in octets. + + + + +Townsley, et al. Standards Track [Page 10] + +RFC 2661 L2TP August 1999 + + + Tunnel ID indicates the identifier for the control connection. L2TP + tunnels are named by identifiers that have local significance only. + That is, the same tunnel will be given different Tunnel IDs by each + end of the tunnel. Tunnel ID in each message is that of the intended + recipient, not the sender. Tunnel IDs are selected and exchanged as + Assigned Tunnel ID AVPs during the creation of a tunnel. + + Session ID indicates the identifier for a session within a tunnel. + L2TP sessions are named by identifiers that have local significance + only. That is, the same session will be given different Session IDs + by each end of the session. Session ID in each message is that of the + intended recipient, not the sender. Session IDs are selected and + exchanged as Assigned Session ID AVPs during the creation of a + session. + + Ns indicates the sequence number for this data or control message, + beginning at zero and incrementing by one (modulo 2**16) for each + message sent. See Section 5.8 and 5.4 for more information on using + this field. + + Nr indicates the sequence number expected in the next control message + to be received. Thus, Nr is set to the Ns of the last in-order + message received plus one (modulo 2**16). In data messages, Nr is + reserved and, if present (as indicated by the S-bit), MUST be ignored + upon receipt. See section 5.8 for more information on using this + field in control messages. + + The Offset Size field, if present, specifies the number of octets + past the L2TP header at which the payload data is expected to start. + Actual data within the offset padding is undefined. If the offset + field is present, the L2TP header ends after the last octet of the + offset padding. + +3.2 Control Message Types + + The Message Type AVP (see section 4.4.1) defines the specific type of + control message being sent. Recall from section 3.1 that this is only + for control messages, that is, messages with the T-bit set to 1. + + + + + + + + + + + + + +Townsley, et al. Standards Track [Page 11] + +RFC 2661 L2TP August 1999 + + + This document defines the following control message types (see + Section 6.1 through 6.14 for details on the construction and use of + each message): + + Control Connection Management + + 0 (reserved) + + 1 (SCCRQ) Start-Control-Connection-Request + 2 (SCCRP) Start-Control-Connection-Reply + 3 (SCCCN) Start-Control-Connection-Connected + 4 (StopCCN) Stop-Control-Connection-Notification + 5 (reserved) + 6 (HELLO) Hello + + Call Management + + 7 (OCRQ) Outgoing-Call-Request + 8 (OCRP) Outgoing-Call-Reply + 9 (OCCN) Outgoing-Call-Connected + 10 (ICRQ) Incoming-Call-Request + 11 (ICRP) Incoming-Call-Reply + 12 (ICCN) Incoming-Call-Connected + 13 (reserved) + 14 (CDN) Call-Disconnect-Notify + + Error Reporting + + 15 (WEN) WAN-Error-Notify + + PPP Session Control + + 16 (SLI) Set-Link-Info + +4.0 Control Message Attribute Value Pairs + + To maximize extensibility while still permitting interoperability, a + uniform method for encoding message types and bodies is used + throughout L2TP. This encoding will be termed AVP (Attribute-Value + Pair) in the remainder of this document. + + + + + + + + + + + +Townsley, et al. Standards Track [Page 12] + +RFC 2661 L2TP August 1999 + + +4.1 AVP Format + + Each AVP is encoded as: + + 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 | Attribute Value... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + [until Length is reached]... | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The first six bits are a bit mask, describing the general attributes + of the AVP. + + Two bits are defined in this document, the remaining are reserved for + future extensions. Reserved bits MUST be set to 0. An AVP received + with a reserved bit set to 1 MUST be treated as an unrecognized AVP. + + Mandatory (M) bit: Controls the behavior required of an + implementation which receives an AVP which it does not recognize. If + the M bit is set on an unrecognized AVP within a message associated + with a particular session, the session associated with this message + MUST be terminated. If the M bit is set on an unrecognized AVP within + a message associated with the overall tunnel, the entire tunnel (and + all sessions within) MUST be terminated. If the M bit is not set, an + unrecognized AVP MUST be ignored. The control message must then + continue to be processed as if the AVP had not been present. + + Hidden (H) bit: Identifies the hiding of data in the Attribute Value + field of an AVP. This capability can be used to avoid the passing of + sensitive data, such as user passwords, as cleartext in an AVP. + Section 4.3 describes the procedure for performing AVP hiding. + + Length: Encodes the number of octets (including the Overall Length + and bitmask fields) contained in this AVP. The Length may be + calculated as 6 + the length of the Attribute Value field in octets. + The field itself is 10 bits, permitting a maximum of 1023 octets of + data in a single AVP. The minimum Length of an AVP is 6. If the + length is 6, then the Attribute Value field is absent. + + Vendor ID: The IANA assigned "SMI Network Management Private + Enterprise Codes" [RFC1700] value. The value 0, corresponding to + IETF adopted attribute values, is used for all AVPs defined within + this document. Any vendor wishing to implement their own L2TP + extensions can use their own Vendor ID along with private Attribute + + + +Townsley, et al. Standards Track [Page 13] + +RFC 2661 L2TP August 1999 + + + values, guaranteeing that they will not collide with any other + vendor's extensions, nor with future IETF extensions. Note that there + are 16 bits allocated for the Vendor ID, thus limiting this feature + to the first 65,535 enterprises. + + Attribute Type: A 2 octet value with a unique interpretation across + all AVPs defined under a given Vendor ID. + + Attribute Value: This is the actual value as indicated by the Vendor + ID and Attribute Type. It follows immediately after the Attribute + Type field, and runs for the remaining octets indicated in the Length + (i.e., Length minus 6 octets of header). This field is absent if the + Length is 6. + +4.2 Mandatory AVPs + + Receipt of an unknown AVP that has the M-bit set is catastrophic to + the session or tunnel it is associated with. Thus, the M bit should + only be defined for AVPs which are absolutely crucial to proper + operation of the session or tunnel. Further, in the case where the + LAC or LNS receives an unknown AVP with the M-bit set and shuts down + the session or tunnel accordingly, it is the full responsibility of + the peer sending the Mandatory AVP to accept fault for causing an + non-interoperable situation. Before defining an AVP with the M-bit + set, particularly a vendor-specific AVP, be sure that this is the + intended consequence. + + When an adequate alternative exists to use of the M-bit, it should be + utilized. For example, rather than simply sending an AVP with the M- + bit set to determine if a specific extension exists, availability may + be identified by sending an AVP in a request message and expecting a + corresponding AVP in a reply message. + + Use of the M-bit with new AVPs (those not defined in this document) + MUST provide the ability to configure the associated feature off, + such that the AVP is either not sent, or sent with the M-bit not set. + +4.3 Hiding of AVP Attribute Values + + The H bit in the header of each AVP provides a mechanism to indicate + to the receiving peer whether the contents of the AVP are hidden or + present in cleartext. This feature can be used to hide sensitive + control message data such as user passwords or user IDs. + + The H bit MUST only be set if a shared secret exists between the LAC + and LNS. The shared secret is the same secret that is used for tunnel + authentication (see Section 5.1.1). If the H bit is set in any + + + + +Townsley, et al. Standards Track [Page 14] + +RFC 2661 L2TP August 1999 + + + AVP(s) in a given control message, a Random Vector AVP must also be + present in the message and MUST precede the first AVP having an H bit + of 1. + + Hiding an AVP value is done in several steps. The first step is to + take the length and value fields of the original (cleartext) AVP and + encode them into a Hidden AVP Subformat 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Length of Original Value | Original Attribute Value ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ... | Padding ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Length of Original Attribute Value: This is length of the Original + Attribute Value to be obscured in octets. This is necessary to + determine the original length of the Attribute Value which is lost + when the additional Padding is added. + + Original Attribute Value: Attribute Value that is to be obscured. + + Padding: Random additional octets used to obscure length of the + Attribute Value that is being hidden. + + To mask the size of the data being hidden, the resulting subformat + MAY be padded as shown above. Padding does NOT alter the value placed + in the Length of Original Attribute Value field, but does alter the + length of the resultant AVP that is being created. For example, If an + Attribute Value to be hidden is 4 octets in length, the unhidden AVP + length would be 10 octets (6 + Attribute Value length). After hiding, + the length of the AVP will become 6 + Attribute Value length + size + of the Length of Original Attribute Value field + Padding. Thus, if + Padding is 12 octets, the AVP length will be 6 + 4 + 2 + 12 = 24 + octets. + + Next, An MD5 hash is performed on the concatenation of: + + + the 2 octet Attribute number of the AVP + + the shared secret + + an arbitrary length random vector + + The value of the random vector used in this hash is passed in the + value field of a Random Vector AVP. This Random Vector AVP must be + placed in the message by the sender before any hidden AVPs. The same + random vector may be used for more than one hidden AVP in the same + + + + +Townsley, et al. Standards Track [Page 15] + +RFC 2661 L2TP August 1999 + + + message. If a different random vector is used for the hiding of + subsequent AVPs then a new Random Vector AVP must be placed in the + command message before the first AVP to which it applies. + + The MD5 hash value is then XORed with the first 16 octet (or less) + segment of the Hidden AVP Subformat and placed in the Attribute Value + field of the Hidden AVP. If the Hidden AVP Subformat is less than 16 + octets, the Subformat is transformed as if the Attribute Value field + had been padded to 16 octets before the XOR, but only the actual + octets present in the Subformat are modified, and the length of the + AVP is not altered. + + If the Subformat is longer than 16 octets, a second one-way MD5 hash + is calculated over a stream of octets consisting of the shared secret + followed by the result of the first XOR. That hash is XORed with the + second 16 octet (or less) segment of the Subformat and placed in the + corresponding octets of the Value field of the Hidden AVP. + + If necessary, this operation is repeated, with the shared secret used + along with each XOR result to generate the next hash to XOR the next + segment of the value with. + + The hiding method was adapted from RFC 2138 [RFC2138] which was taken + from the "Mixing in the Plaintext" section in the book "Network + Security" by Kaufman, Perlman and Speciner [KPS]. A detailed + explanation of the method follows: + + Call the shared secret S, the Random Vector RV, and the Attribute + Value AV. Break the value field into 16-octet chunks p1, p2, etc. + with the last one padded at the end with random data to a 16-octet + boundary. Call the ciphertext blocks c(1), c(2), etc. We will also + define intermediate values b1, b2, etc. + + b1 = MD5(AV + S + RV) c(1) = p1 xor b1 + b2 = MD5(S + c(1)) c(2) = p2 xor b2 + . . + . . + . . + bi = MD5(S + c(i-1)) c(i) = pi xor bi + + The String will contain c(1)+c(2)+...+c(i) where + denotes + concatenation. + + On receipt, the random vector is taken from the last Random Vector + AVP encountered in the message prior to the AVP to be unhidden. The + above process is then reversed to yield the original value. + + + + + +Townsley, et al. Standards Track [Page 16] + +RFC 2661 L2TP August 1999 + + +4.4 AVP Summary + + The following sections contain a list of all L2TP AVPs defined in + this document. + + Following the name of the AVP is a list indicating the message types + that utilize each AVP. 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. + +4.4.1 AVPs Applicable To All Control Messages + + Message Type (All Messages) + + The Message Type AVP, Attribute Type 0, identifies the control + message herein and defines the context in which the exact meaning + of the following AVPs will be determined. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Message Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The Message Type is a 2 octet unsigned integer. + + The Message Type AVP MUST be the first AVP in a message, + immediately following the control message header (defined in + section 3.1). See Section 3.2 for the list of defined control + message types and their identifiers. + + The Mandatory (M) bit within the Message Type AVP has special + meaning. Rather than an indication as to whether the AVP itself + should be ignored if not recognized, it is an indication as to + whether the control message itself should be ignored. Thus, if the + M-bit is set within the Message Type AVP and the Message Type is + unknown to the implementation, the tunnel MUST be cleared. If the + M-bit is not set, then the implementation may ignore an unknown + message type. The M-bit MUST be set to 1 for all message types + defined in this document. This AVP may not be hidden (the H-bit + MUST be 0). The Length of this AVP is 8. + + + + + + + +Townsley, et al. Standards Track [Page 17] + +RFC 2661 L2TP August 1999 + + + Random Vector (All Messages) + + The Random Vector AVP, Attribute Type 36, is used to enable the + hiding of the Attribute Value of arbitrary AVPs. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Random Octet String ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The Random Octet String may be of arbitrary length, although a + random vector of at least 16 octets is recommended. The string + contains the random vector for use in computing the MD5 hash to + retrieve or hide the Attribute Value of a hidden AVP (see Section + 4.2). + + More than one Random Vector AVP may appear in a message, in which + case a hidden AVP uses the Random Vector AVP most closely + preceding it. This AVP MUST precede the first AVP with the H bit + set. + + The M-bit for this AVP MUST be set to 1. This AVP MUST NOT be + hidden (the H-bit MUST be 0). The Length of this AVP is 6 plus the + length of the Random Octet String. + +4.4.2 Result and Error Codes + + Result Code (CDN, StopCCN) + + The Result Code AVP, Attribute Type 1, indicates the reason for + terminating the control channel or session. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Result Code | Error Code (opt) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Error Message (opt) ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The Result Code is a 2 octet unsigned integer. The optional Error + Code is a 2 octet unsigned integer. An optional Error Message can + follow the Error Code field. Presence of the Error Code and + + + +Townsley, et al. Standards Track [Page 18] + +RFC 2661 L2TP August 1999 + + + Message are indicated by the AVP Length field. The Error Message + contains an arbitrary string providing further (human readable) + text associated with the condition. Human readable text in all + error messages MUST be provided in the UTF-8 charset using the + Default Language [RFC2277]. + + 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 is 8 if there is no Error + Code or Message, 10 if there is an Error Code and no Error Message + or 10 + the length of the Error Message if there is an Error Code + and Message. + + Defined Result Code values for the StopCCN message are: + + 0 - Reserved + 1 - General request to clear control connection + 2 - General error--Error Code indicates the problem + 3 - Control channel already exists + 4 - Requester is not authorized to establish a control + channel + 5 - The protocol version of the requester is not + supported + Error Code indicates highest version supported + 6 - Requester is being shut down + 7 - Finite State Machine error + + Defined Result Code values for the CDN message are: + + 0 - Reserved + 1 - Call disconnected due to loss of carrier + 2 - Call disconnected for the reason indicated + in error code + 3 - Call disconnected for administrative reasons + 4 - Call failed due to lack of appropriate facilities + being available (temporary condition) + 5 - Call failed due to lack of appropriate facilities being + available (permanent condition) + 6 - Invalid destination + 7 - Call failed due to no carrier detected + 8 - Call failed due to detection of a busy signal + 9 - Call failed due to lack of a dial tone + 10 - Call was not established within time allotted by LAC + 11 - Call was connected but no appropriate framing was + detected + + The Error Codes defined below pertain to types of errors that are + not specific to any particular L2TP request, but rather to + protocol or message format errors. If an L2TP reply indicates in + + + +Townsley, et al. Standards Track [Page 19] + +RFC 2661 L2TP August 1999 + + + its Result Code that a general error occurred, the General Error + value should be examined to determine what the error was. The + currently defined General Error codes and their meanings are: + + 0 - No general error + 1 - No control connection exists yet for this LAC-LNS pair + 2 - Length is wrong + 3 - One of the field values was out of range or + reserved field was non-zero + 4 - Insufficient resources to handle this operation now + 5 - The Session ID is invalid in this context + 6 - A generic vendor-specific error occurred in the LAC + 7 - Try another. If LAC is aware of other possible LNS + destinations, it should try one of them. This can be + used to guide an LAC based on LNS policy, for instance, + the existence of multilink PPP bundles. + 8 - Session or tunnel was shutdown due to receipt of an unknown + AVP with the M-bit set (see section 4.2). The Error Message + SHOULD contain the attribute of the offending AVP in (human + readable) text form. + + When a General Error Code of 6 is used, additional information + about the error SHOULD be included in the Error Message field. + +4.4.3 Control Connection Management AVPs + + Protocol Version (SCCRP, SCCRQ) + + The Protocol Version AVP, Attribute Type 2, indicates the L2TP + protocol version of the sender. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Ver | Rev | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The Ver field is a 1 octet unsigned integer containing the value + 1. Rev field is a 1 octet unsigned integer containing 0. This + pertains to L2TP protocol version 1, revision 0. Note this is not + the same version number that is included in the header of each + message. + + 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 8. + + + + +Townsley, et al. Standards Track [Page 20] + +RFC 2661 L2TP August 1999 + + + Framing Capabilities (SCCRP, SCCRQ) + + The Framing Capabilities AVP, Attribute Type 3, provides the peer + with an indication of the types of framing that will be accepted + or requested by the sender. + + 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. + + A peer MUST NOT request an incoming or outgoing call with a + Framing Type AVP specifying a value not advertised in the Framing + Capabilities AVP it received during control connection + establishment. Attempts to do so will result in the call being + rejected. + + 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 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 |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. + + + + + + + +Townsley, et al. Standards Track [Page 21] + +RFC 2661 L2TP August 1999 + + + An LNS should not request an outgoing call specifying a value in + the Bearer Type AVP for a device type not advertised in the Bearer + Capabilities AVP it received from the LAC during control + connection establishment. Attempts to do so will result in the + call being rejected. + + This AVP MUST be present if the sender can place outgoing calls + when requested. + + Note that an LNS that cannot act as an LAC as well will not + support hardware devices for handling incoming and outgoing calls + and should therefore set the A and D bits of this AVP to 0, or + should not send the AVP at all. An LNS that can also act as an LAC + and place outgoing calls should set A or D as appropriate. + 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. + + Tie Breaker (SCCRQ) + + The Tie Breaker AVP, Attribute Type 5, indicates that the sender + wishes a single tunnel to exist between the given LAC-LNS pair. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Tie Break Value... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ...(64 bits) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The Tie Breaker Value is an 8 octet value that is used to choose a + single tunnel where both LAC and LNS request a tunnel + concurrently. The recipient of a SCCRQ must check to see if a + SCCRQ has been sent to the peer, and if so, must compare its Tie + Breaker value with the received one. The lower value "wins", and + the "loser" MUST silently discard its tunnel. In the case where a + tie breaker is present on both sides, and the value is equal, both + sides MUST discard their tunnels. + + + + + + + +Townsley, et al. Standards Track [Page 22] + +RFC 2661 L2TP August 1999 + + + If a tie breaker is received, and an outstanding SCCRQ had no tie + breaker value, the initiator which included the Tie Breaker AVP + "wins". If neither side issues a tie breaker, then two separate + tunnels are opened. + + This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for + this AVP MUST be set to 0. The Length of this AVP is 14. + + Firmware Revision (SCCRP, SCCRQ) + + The Firmware Revision AVP, Attribute Type 6, indicates the + firmware revision of the issuing device. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Firmware Revision | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The Firmware Revision is a 2 octet unsigned integer encoded in a + vendor specific format. + + For devices which do not have a firmware revision (general purpose + computers running L2TP software modules, for instance), the + revision of the L2TP software module may be reported instead. + + 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 8. + + Host Name (SCCRP, SCCRQ) + + The Host Name AVP, Attribute Type 7, indicates the name of the + issuing LAC or LNS. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Host Name ... (arbitrary number of octets) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The Host Name is of arbitrary length, but MUST be at least 1 + octet. + + + + + +Townsley, et al. Standards Track [Page 23] + +RFC 2661 L2TP August 1999 + + + This name should be as broadly unique as possible; for hosts + participating in DNS [RFC1034], a hostname with fully qualified + domain would be appropriate. + + 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 plus the + length of the Host Name. + + Vendor Name (SCCRP, SCCRQ) + + The Vendor Name AVP, Attribute Type 8, contains a vendor specific + (possibly human readable) string describing the type of LAC or LNS + being 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Vendor Name ...(arbitrary number of octets) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The Vendor Name is the indicated number of octets representing the + vendor string. Human readable text for this AVP MUST be provided + in the UTF-8 charset using the Default Language [RFC2277]. + + 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 Vendor Name. + + Assigned Tunnel ID (SCCRP, SCCRQ, StopCCN) + + The Assigned Tunnel ID AVP, Attribute Type 9, encodes the ID being + assigned to this tunnel by the sender. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Assigned Tunnel ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The Assigned Tunnel ID is a 2 octet non-zero unsigned integer. + + The Assigned Tunnel ID AVP establishes a value used to multiplex + and demultiplex multiple tunnels between the LNS and LAC. The L2TP + peer MUST place this value in the Tunnel ID header field of all + + + +Townsley, et al. Standards Track [Page 24] + +RFC 2661 L2TP August 1999 + + + control and data messages that it subsequently transmits over the + associated tunnel. Before the Assigned Tunnel ID AVP is received + from a peer, messages MUST be sent to that peer with a Tunnel ID + value of 0 in the header of all control messages. + + In the StopCCN control message, the Assigned Tunnel ID AVP MUST be + the same as the Assigned Tunnel ID AVP first sent to the receiving + peer, permitting the peer to identify the appropriate tunnel even + if a StopCCN is sent before an Assigned Tunnel ID AVP is received. + + 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 8. + + Receive Window Size (SCCRQ, SCCRP) + + The Receive Window Size AVP, Attribute Type 10, specifies the + receive window size being offered to the remote peer. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Window Size | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The Window Size is a 2 octet unsigned integer. + + If absent, the peer must assume a Window Size of 4 for its + transmit window. The remote peer may send the specified number of + control messages before it must wait for an acknowledgment. + + 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 8. + + Challenge (SCCRP, SCCRQ) + + The Challenge AVP, Attribute Type 11, indicates that the issuing + peer wishes to authenticate the tunnel endpoints using a CHAP- + style authentication mechanism. + + + + + + + + + + +Townsley, et al. Standards Track [Page 25] + +RFC 2661 L2TP August 1999 + + + 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 one or more octets of random data. + + 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 Challenge. + + Challenge Response (SCCCN, SCCRP) + + The Response AVP, Attribute Type 13, provides a response to a + challenge received. + + 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 ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ... (16 octets) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The Response is a 16 octet value reflecting the CHAP-style + [RFC1994] response to the challenge. + + This AVP MUST be present in an SCCRP or SCCCN if a challenge was + received in the preceding SCCRQ or SCCRP. For purposes of the ID + value in the CHAP response calculation, the value of the Message + Type AVP for this message is used (e.g. 2 for an SCCRP, and 3 for + an SCCCN). + + 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 22. + + + + + + +Townsley, et al. Standards Track [Page 26] + +RFC 2661 L2TP August 1999 + + +4.4.4 Call Management AVPs + + 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... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Cause Code is the returned Q.931 Cause code, and Cause Msg 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 + size of the Advisory Message. + + Assigned Session ID (CDN, ICRP, ICRQ, OCRP, OCRQ) + + The Assigned Session ID AVP, Attribute Type 14, encodes the ID + being assigned to this session by the sender. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Assigned Session ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The Assigned Session ID is a 2 octet non-zero unsigned integer. + + The Assigned Session ID AVP is establishes a value used to + multiplex and demultiplex data sent over a tunnel between the LNS + and LAC. The L2TP peer MUST place this value in the Session ID + header field of all control and data messages that it subsequently + transmits over the tunnel that belong to this session. Before the + + + + + +Townsley, et al. Standards Track [Page 27] + +RFC 2661 L2TP August 1999 + + + Assigned Session ID AVP is received from a peer, messages MUST be + sent to that peer with a Session ID of 0 in the header of all + control messages. + + In the CDN control message, the same Assigned Session ID AVP first + sent to the receiving peer is used, permitting the peer to + identify the appropriate tunnel even if CDN is sent before an + Assigned Session ID is received. + + 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 8. + + Call Serial Number (ICRQ, OCRQ) + + The Call Serial Number AVP, Attribute Type 15, encodes an + identifier assigned by the LAC or LNS to this 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Call Serial Number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The Call Serial Number is a 32 bit value. + + The Call Serial Number is intended to be an easy reference for + administrators on both ends of a tunnel to use when investigating + call failure problems. Call Serial Numbers should be set to + progressively increasing values, which are likely to be unique for + a significant period of time across all interconnected LNSs and + LACs. + + 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. + + Minimum BPS (OCRQ) + + The Minimum BPS AVP, Attribute Type 16, encodes the lowest + acceptable line speed for this call. + + + + + + + + +Townsley, et al. Standards Track [Page 28] + +RFC 2661 L2TP August 1999 + + + 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 indicates the speed in bits per + second. + + 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. + + 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 indicates the speed in bits per + second. + + 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. + + 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 |A|D| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + +Townsley, et al. Standards Track [Page 29] + +RFC 2661 L2TP August 1999 + + + The Bearer Type is a 32-bit bit mask, which indicates the bearer + capability of the call (ICRQ) or required for the call (OCRQ). If + set, bit A indicates that the call refers to an analog channel. If + set, bit D indicates that the call refers to a digital channel. + Both may be set, indicating that the call was either + indistinguishable, or can be placed on either type of channel. + + Bits in the Value field of this AVP MUST only be set by the LNS + for an OCRQ if it was set in the Bearer Capabilities AVP received + from the LAC during control connection establishment. + + It is valid to set neither the A nor D bits in an ICRQ. Such a + setting may indicate that the call was not received over a + physical link (e.g if the LAC and PPP are located in the same + subsystem). + + 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. The framing type MAY be used as an + indication to PPP on the LNS as to what link options to use for + LCP negotiation [RFC1662]. + + Bit A indicates asynchronous framing. Bit S indicates synchronous + framing. For an OCRQ, both may be set, indicating that either type + of framing may be used. + + 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. + + + + + +Townsley, et al. Standards Track [Page 30] + +RFC 2661 L2TP August 1999 + + + 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) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + 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. + + 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. + + + + + +Townsley, et al. Standards Track [Page 31] + +RFC 2661 L2TP August 1999 + + + Sub-Address (ICRQ, OCRQ) + + The Sub-Address AVP, Attribute Type 23, encodes additional dialing + information. + + 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. + + (Tx) Connect Speed (ICCN, OCCN) + + The (Tx) Connect Speed BPS AVP, Attribute Type 24, encodes the + speed of the facility chosen for the connection attempt. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | BPS | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The (Tx) Connect Speed BPS is a 4 octet value indicating the speed + in bits per second. + + When the optional Rx Connect Speed AVP is present, the value in + this AVP represents the transmit connect speed, from the + perspective of the LAC (e.g. data flowing from the LAC to the + remote system). When the optional Rx Connect Speed AVP is NOT + present, the connection speed between the remote system and LAC is + assumed to be symmetric and is represented by the single 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 10. + + + +Townsley, et al. Standards Track [Page 32] + +RFC 2661 L2TP August 1999 + + + Rx Connect Speed (ICCN, OCCN) + + The Rx Connect Speed AVP, Attribute Type 38, represents the speed + of the connection from the perspective of the LAC (e.g. data + flowing from the remote system to the LAC). + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | BPS (H) | BPS (L) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + BPS is a 4 octet value indicating the speed in bits per second. + + Presence of this AVP implies that the connection speed may be + asymmetric with respect to the transmit connect speed given in the + (Tx) Connect Speed AVP. + + This AVP may be hidden (the H-bit MAY be 1 or 0). The M-bit for + this AVP MUST be set to 0. The Length (before hiding) of this AVP + is 10. + + Physical Channel ID (ICRQ, OCRP) + + The Physical Channel ID AVP, Attribute Type 25, encodes the vendor + specific physical channel number used for a 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Physical Channel ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Physical Channel ID is a 4 octet value intended to be used for + logging purposes only. + + 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 10. + + + + + + + + +Townsley, et al. Standards Track [Page 33] + +RFC 2661 L2TP August 1999 + + + Private Group ID (ICCN) + + The Private Group ID AVP, Attribute Type 37, is used by the LAC to + indicate that this call is to be associated with a particular + customer group. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Private Group ID ... (arbitrary number of octets) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The Private Group ID is a string of octets of arbitrary length. + + The LNS MAY treat the PPP session as well as network traffic + through this session in a special manner determined by the peer. + For example, if the LNS is individually connected to several + private networks using unregistered addresses, this AVP may be + included by the LAC to indicate that a given call should be + associated with one of the private networks. + + The Private Group ID is a string corresponding to a table in the + LNS that defines the particular characteristics of the selected + group. A LAC MAY determine the Private Group ID from a RADIUS + response, local configuration, or some other source. + + This AVP may be hidden (the H-bit MAY be 1 or 0). 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 Private Group ID. + + Sequencing Required (ICCN, OCCN) + + The Sequencing Required AVP, Attribute Type 39, indicates to the + LNS 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. + +4.4.5 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 the + + + +Townsley, et al. Standards Track [Page 34] + +RFC 2661 L2TP August 1999 + + + link properties the remote system initially requested, properties + the remote system and LAC ultimately negotiated, as well as PPP + authentication information sent and received by the LAC. This + information may be used to initiate the PPP LCP and authentication + systems 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, + 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) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + 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. + + 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. + + + + + +Townsley, et al. Standards Track [Page 35] + +RFC 2661 L2TP August 1999 + + + 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, determines if proxy + authentication should be 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Authen Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Authen Type is a 2 octet unsigned integer, holding: + + 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. + + + + + + + + +Townsley, et al. Standards Track [Page 36] + +RFC 2661 L2TP August 1999 + + + 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) + + 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, requiring + a restart of the authentication phase at the LNS if the client + has already entered this phase with the + LAC (which may be determined by the Proxy LCP AVP if present). + + 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 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. + + + + +Townsley, et al. Standards Track [Page 37] + +RFC 2661 L2TP August 1999 + + + 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. + + 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. + + + +Townsley, et al. Standards Track [Page 38] + +RFC 2661 L2TP August 1999 + + + 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 types 1 or 3, it contains the clear + text 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. + +4.4.6 Call Status AVPs + + Call Errors (WEN) + + The Call Errors AVP, Attribute Type 34, is used by the LAC to send + error information to the LNS. + + 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 | CRC Errors (H) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | CRC Errors (L) | Framing Errors (H) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Framing Errors (L) | Hardware Overruns (H) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Hardware Overruns (L) | Buffer Overruns (H) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Buffer Overruns (L) | Time-out Errors (H) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Time-out Errors (L) | Alignment Errors (H) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Alignment Errors (L) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + +Townsley, et al. Standards Track [Page 39] + +RFC 2661 L2TP August 1999 + + + The following fields are defined: + + Reserved - Not used, MUST be 0 + CRC Errors - Number of PPP frames received with CRC errors + since call was established + Framing Errors - Number of improperly framed PPP packets + received + Hardware Overruns - Number of receive buffer over-runs since + call was established + Buffer Overruns - Number of buffer over-runs detected since + call was established + Time-out Errors - Number of time-outs since call was + established + Alignment Errors - Number of alignment errors since call was + established + + 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 32. + + 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: + + 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) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Send ACCM and Receive ACCM are each 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. + + + +Townsley, et al. Standards Track [Page 40] + +RFC 2661 L2TP August 1999 + + +5.0 Protocol Operation + + The necessary setup for tunneling a PPP session with L2TP consists of + two steps, (1) establishing the Control Connection for a Tunnel, and + (2) establishing a Session as triggered by an incoming or outgoing + call request. The Tunnel and corresponding Control Connection MUST be + established before an incoming or outgoing call is initiated. An L2TP + Session MUST be established before L2TP can begin to tunnel PPP + frames. Multiple Sessions may exist across a single Tunnel and + multiple Tunnels may exist between the same LAC and LNS. + + +-----+ +-----+ + | |~~~~~~~~~~L2TP Tunnel~~~~~~~~~~| | + | LAC | | LNS | + | #######Control Connection######## | + [Remote] | | | | + [System]------Call----------*============L2TP Session=============* | + PPP +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ | + | | | | + [Remote] | | | | + [System]------Call----------*============L2TP Session=============* | + PPP +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ | + | | | | + | |~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| | + +-----+ +-----+ + + Figure 5.1 Tunneling PPP + +5.1 Control Connection Establishment + + The Control Connection is the initial connection that must be + achieved between an LAC and LNS before sessions may be brought up. + Establishment of the control connection includes securing the + identity of the peer, as well as identifying the peer's L2TP version, + framing, and bearer capabilities, etc. + + A three message exchange is utilized to setup the control connection. + Following is a typical message exchange: + + LAC or LNS LAC or LNS + ---------- ---------- + SCCRQ -> + <- SCCRP + SCCCN -> + <- ZLB ACK + + The ZLB ACK is sent if there are no further messages waiting in queue + for that peer. + + + +Townsley, et al. Standards Track [Page 41] + +RFC 2661 L2TP August 1999 + + +5.1.1 Tunnel Authentication + + L2TP incorporates a simple, optional, CHAP-like [RFC1994] tunnel + authentication system during control connection establishment. If an + LAC or LNS wishes to authenticate the identity of the peer it is + contacting or being contacted by, a Challenge AVP is included in the + SCCRQ or SCCRP message. If a Challenge AVP is received in an SCCRQ or + SCCRP, a Challenge Response AVP MUST be sent in the following SCCRP + or SCCCN, respectively. If the expected response and response + received from a peer does not match, establishment of the tunnel MUST + be disallowed. + + To participate in tunnel authentication, a single shared secret MUST + exist between the LAC and LNS. This is the same shared secret used + for AVP hiding (see Section 4.3). See Section 4.4.3 for details on + construction of the Challenge and Response AVPs. + +5.2 Session Establishment + + After successful control connection establishment, individual + sessions may be created. Each session corresponds to single PPP + stream between the LAC and LNS. Unlike control connection + establishment, session establishment is directional with respect to + the LAC and LNS. The LAC requests the LNS to accept a session for an + incoming call, and the LNS requests the LAC to accept a session for + placing an outgoing call. + +5.2.1 Incoming Call Establishment + + A three message exchange is employed to setup the session. Following + is a typical sequence of events: + + LAC LNS + --- --- + (Call + Detected) + + ICRQ -> + <- ICRP + ICCN -> + <- ZLB ACK + + The ZLB ACK is sent if there are no further messages waiting in queue + for that peer. + + + + + + + +Townsley, et al. Standards Track [Page 42] + +RFC 2661 L2TP August 1999 + + +5.2.2 Outgoing Call Establishment + + A three message exchange is employed to setup the session. Following + is a typical sequence of events: + + LAC LNS + --- --- + <- OCRQ + OCRP -> + + (Perform + Call + Operation) + + OCCN -> + <- ZLB ACK + + The ZLB ACK is sent if there are no further messages waiting in queue + for that peer. + +5.3 Forwarding PPP Frames + + Once tunnel establishment is complete, PPP frames from the remote + system are received at the LAC, stripped of CRC, link framing, and + transparency bytes, encapsulated in L2TP, and forwarded over the + appropriate tunnel. The LNS receives the L2TP packet, and processes + the encapsulated PPP frame as if it were received on a local PPP + interface. + + The sender of a message associated with a particular session and + tunnel places the Session ID and Tunnel ID (specified by its peer) in + the Session ID and Tunnel ID header for all outgoing messages. In + this manner, PPP frames are multiplexed and demultiplexed over a + single tunnel between a given LNS-LAC pair. Multiple tunnels may + exist between a given LNS-LAC pair, and multiple sessions may exist + within a tunnel. + + The value of 0 for Session ID and Tunnel ID is special and MUST NOT + be used as an Assigned Session ID or Assigned Tunnel ID. For the + cases where a Session ID has not yet been assigned by the peer (i.e., + during establishment of a new session or tunnel), the Session ID + field MUST be sent as 0, and the Assigned Session ID AVP within the + message MUST be used to identify the session. Similarly, for cases + where the Tunnel ID has not yet been assigned from the peer, the + Tunnel ID MUST be sent as 0 and Assigned Tunnel ID AVP used to + identify the tunnel. + + + + + +Townsley, et al. Standards Track [Page 43] + +RFC 2661 L2TP August 1999 + + +5.4 Using Sequence Numbers on the Data Channel + + Sequence numbers are defined in the L2TP header for control messages + and optionally for data messages (see Section 3.1). These are used to + provide a reliable control message transport (see Section 5.8) and + optional data message sequencing. Each peer maintains separate + sequence numbers for the control connection and each individual data + session within a tunnel. + + Unlike the L2TP control channel, the L2TP data channel does not use + sequence numbers to retransmit lost data messages. Rather, data + messages may use sequence numbers to detect lost packets and/or + restore the original sequence of packets that may have been reordered + during transport. The LAC may request that sequence numbers be + present in data messages via the Sequencing Required AVP (see Section + 4.4.6). If this AVP is present during session setup, sequence numbers + MUST be present at all times. If this AVP is not present, sequencing + presence is under control of the LNS. The LNS controls enabling and + disabling of sequence numbers by sending a data message with or + without sequence numbers present at any time during the life of a + session. Thus, if the LAC receives a data message without sequence + numbers present, it MUST stop sending sequence numbers in future data + messages. If the LAC receives a data message with sequence numbers + present, it MUST begin sending sequence numbers in future outgoing + data messages. If the LNS enables sequencing after disabling it + earlier in the session, the sequence number state picks up where it + left off before. + + The LNS may initiate disabling of sequencing at any time during the + session (including the first data message sent). It is recommended + that for connections where reordering or packet loss may occur, + sequence numbers always be enabled during the initial negotiation + stages of PPP and disabled only when and if the risk is considered + acceptable. For example, if the PPP session being tunneled is not + utilizing any stateful compression or encryption protocols and is + only carrying IP (as determined by the PPP NCPs that are + established), then the LNS might decide to disable sequencing as IP + is tolerant to datagram loss and reordering. + +5.5 Keepalive (Hello) + + A keepalive mechanism is employed by L2TP in order to differentiate + tunnel outages from extended periods of no control or data activity + on a tunnel. This is accomplished by injecting Hello control messages + (see Section 6.5) after a specified period of time has elapsed since + the last data or control message was received on a tunnel. As for any + other control message, if the Hello message is not reliably delivered + then the tunnel is declared down and is reset. The transport reset + + + +Townsley, et al. Standards Track [Page 44] + +RFC 2661 L2TP August 1999 + + + mechanism along with the injection of Hello messages ensures that a + connectivity failure between the LNS and the LAC will be detected at + both ends of a tunnel. + +5.6 Session Teardown + + Session teardown may be initiated by either the LAC or LNS and is + accomplished by sending a CDN control message. After the last session + is cleared, the control connection MAY be torn down as well (and + typically is). Following is an example of a typical control message + exchange: + + LAC or LNS LAC or LNS + + CDN -> + (Clean up) + + <- ZLB ACK + (Clean up) + +5.7 Control Connection Teardown + + Control connection teardown may be initiated by either the LAC or LNS + and is accomplished by sending a single StopCCN control message. The + receiver of a StopCCN MUST send a ZLB ACK to acknowledge receipt of + the message and maintain enough control connection state to properly + accept StopCCN retransmissions over at least a full retransmission + cycle (in case the ZLB ACK is lost). The recommended time for a full + retransmission cycle is 31 seconds (see section 5.8). Following is an + example of a typical control message exchange: + + LAC or LNS LAC or LNS + + StopCCN -> + (Clean up) + + <- ZLB ACK + (Wait) + (Clean up) + + An implementation may shut down an entire tunnel and all sessions on + the tunnel by sending the StopCCN. Thus, it is not necessary to clear + each session individually when tearing down the whole tunnel. + + + + + + + + +Townsley, et al. Standards Track [Page 45] + +RFC 2661 L2TP August 1999 + + +5.8 Reliable Delivery of Control Messages + + L2TP provides a lower level reliable transport service for all + control messages. The Nr and Ns fields of the control message header + (see section 3.1) belong to this transport. The upper level + functions of L2TP are not concerned with retransmission or ordering + of control messages. The reliable control message is a sliding window + transport that provides control message retransmission and congestion + control. Each peer maintains separate sequence number state for the + control connection within a tunnel. + + The message sequence number, Ns, 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 65536. 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 32767 values, + inclusive. For example, if the last received sequence number was 15, + then messages with sequence numbers 0 through 15, as well as 32784 + through 65535, would be considered less than or equal. Such a message + would be considered a duplicate of a message already received and + ignored from processing. However, in order to ensure that all + messages are acknowledged properly (particularly in the case of a + lost ZLB ACK message), receipt of duplicate messages MUST be + acknowledged by the reliable transport. This acknowledgement may + either piggybacked on a message in queue, or explicitly via a ZLB + ACK. + + All control messages take up one slot in the control message sequence + number space, except the ZLB acknowledgement. Thus, Ns is not + incremented after a ZLB message is sent. + + The last received message number, Nr, is used to acknowledge messages + received by an L2TP peer. It contains the sequence number of the + message the peer expects to receive next (e.g. the last Ns of a non- + ZLB message received plus 1, modulo 65536). While the Nr in a + received ZLB is used to flush messages from the local retransmit + queue (see below), Nr of the next message sent is not be updated by + the Ns of the ZLB. + + The reliable transport at a receiving peer is responsible for making + sure that control messages are delivered in order and without + duplication to the upper level. Messages arriving out of order may be + queued for in-order delivery when the missing messages are received, + or they may be discarded requiring a retransmission by the peer. + + + + + + +Townsley, et al. Standards Track [Page 46] + +RFC 2661 L2TP August 1999 + + + Each tunnel maintains a queue of control messages to be transmitted + to its peer. The message at the front of the queue is sent with a + given Ns value, and is held until a control message arrives from the + peer in which the Nr field indicates receipt of this message. After a + period of time (a recommended default is 1 second) passes without + acknowledgement, the message is retransmitted. The retransmitted + message contains the same Ns value, but the Nr value MUST be updated + with the sequence number of the next expected message. + + Each subsequent retransmission of a message MUST employ an + exponential backoff interval. Thus, if the first retransmission + occurred after 1 second, the next retransmission should occur after 2 + seconds has elapsed, then 4 seconds, etc. An implementation MAY place + a cap upon the maximum interval between retransmissions. This cap + MUST be no less than 8 seconds per retransmission. If no peer + response is detected after several retransmissions, (a recommended + default is 5, but SHOULD be configurable), the tunnel and all + sessions within MUST be cleared. + + When a tunnel is being shut down for reasons other than loss of + connectivity, the state and reliable delivery mechanisms MUST be + maintained and operated for the full retransmission interval after + the final message exchange has occurred. + + A sliding window mechanism is used for control message transmission. + Consider two peers A & B. Suppose A specifies a Receive Window Size + AVP with a value of N in the SCCRQ or SCCRP messages. B is now + allowed to have up to N outstanding control messages. Once N have + been sent, it must wait for an acknowledgment that advances the + window before sending new control messages. An implementation may + support a receive window of only 1 (i.e., by sending out a Receive + Window Size AVP with a value of 1), but MUST accept a window of up to + 4 from its peer (e.g. have the ability to send 4 messages before + backing off). A value of 0 for the Receive Window Size AVP is + invalid. + + When retransmitting control messages, a slow start and congestion + avoidance window adjustment procedure SHOULD be utilized. The + recommended procedure for this is described in Appendix A. + + A peer MUST NOT withhold acknowledgment of messages as a technique + for flow controlling control messages. An L2TP implementation is + expected to be able to keep up with incoming control messages, + possibly responding to some with errors reflecting an inability to + honor the requested action. + + Appendix B contains examples of control message transmission, + acknowledgement, and retransmission. + + + +Townsley, et al. Standards Track [Page 47] + +RFC 2661 L2TP August 1999 + + +6.0 Control Connection Protocol Specification + + The following control connection messages are used to establish, + clear and maintain L2TP tunnels. All data is sent in network order + (high order octets first). Any "reserved" or "empty" fields MUST be + sent as 0 values to allow for protocol extensibility. + +6.1 Start-Control-Connection-Request (SCCRQ) + + Start-Control-Connection-Request (SCCRQ) is a control message used to + initialize a tunnel between an LNS and an LAC. It is sent by either + the LAC or the LNS to being the tunnel establishment process. + + The following AVPs MUST be present in the SCCRQ: + + Message Type AVP + Protocol Version + Host Name + Framing Capabilities + Assigned Tunnel ID + + The Following AVPs MAY be present in the SCCRQ: + + Bearer Capabilities + Receive Window Size + Challenge + Tie Breaker + Firmware Revision + Vendor Name + +6.2 Start-Control-Connection-Reply (SCCRP) + + Start-Control-Connection-Reply (SCCRP) is a control message sent in + reply to a received SCCRQ message. SCCRP is used to indicate that the + SCCRQ was accepted and establishment of the tunnel should continue. + + The following AVPs MUST be present in the SCCRP: + + Message Type + Protocol Version + Framing Capabilities + Host Name + Assigned Tunnel ID + + + + + + + + +Townsley, et al. Standards Track [Page 48] + +RFC 2661 L2TP August 1999 + + + The following AVPs MAY be present in the SCCRP: + + Bearer Capabilities + Firmware Revision + Vendor Name + Receive Window Size + Challenge + Challenge Response + +6.3 Start-Control-Connection-Connected (SCCCN) + + Start-Control-Connection-Connected (SCCCN) is a control message sent + in reply to an SCCRP. SCCCN completes the tunnel establishment + process. + + The following AVP MUST be present in the SCCCN: + + Message Type + + The following AVP MAY be present in the SCCCN: + + Challenge Response + +6.4 Stop-Control-Connection-Notification (StopCCN) + + Stop-Control-Connection-Notification (StopCCN) is a control message + sent by either the LAC or LNS to inform its peer that the tunnel is + being shutdown and the control connection should be closed. In + addition, all active sessions are implicitly cleared (without sending + any explicit call control messages). The reason for issuing this + request is indicated in the Result Code AVP. There is no explicit + reply to the message, only the implicit ACK that is received by the + reliable control message transport layer. + + The following AVPs MUST be present in the StopCCN: + + Message Type + Assigned Tunnel ID + Result Code + +6.5 Hello (HELLO) + + The Hello (HELLO) message is an L2TP control message sent by either + peer of a LAC-LNS control connection. This control message is used as + a "keepalive" for the tunnel. + + + + + + +Townsley, et al. Standards Track [Page 49] + +RFC 2661 L2TP August 1999 + + + The sending of HELLO messages and the policy for sending them are + left up to the implementation. A peer MUST NOT expect HELLO messages + at any time or interval. As with all messages sent on the control + connection, the receiver will return either a ZLB ACK or an + (unrelated) message piggybacking the necessary acknowledgement + information. + + Since a HELLO is a control message, and control messages are reliably + sent by the lower level transport, this keepalive function operates + by causing the transport level to reliably deliver a message. If a + media interruption has occurred, the reliable transport will be + unable to deliver the HELLO across, and will clean up the tunnel. + + Keepalives for the tunnel MAY be implemented by sending a HELLO if a + period of time (a recommended default is 60 seconds, but SHOULD be + configurable) has passed without receiving any message (data or + control) from the peer. + + HELLO messages are global to the tunnel. The Session ID in a HELLO + message MUST be 0. + + The Following AVP MUST be present in the HELLO message: + + Message Type + +6.6 Incoming-Call-Request (ICRQ) + + Incoming-Call-Request (ICRQ) is a control message sent by the LAC to + the LNS when an incoming call is detected. It is the first in a three + message exchange used for establishing a session within an L2TP + tunnel. + + ICRQ is used to indicate that a session is to be established between + the LAC and LNS for this call and provides the LNS with parameter + information for the session. The LAC may defer answering the call + until it has received an ICRP from the LNS indicating that the + session should be established. This mechanism allows the LNS to + obtain sufficient information about the call before determining + whether it should be answered or not. Alternatively, the LAC may + answer the call, negotiate LCP and PPP authentication, and use the + information gained to choose the LNS. In this case, the call has + already been answered by the time the ICRP message is received; the + LAC simply spoofs the "call indication" and "call answer" steps in + this case. + + + + + + + +Townsley, et al. Standards Track [Page 50] + +RFC 2661 L2TP August 1999 + + + The following AVPs MUST be present in the ICRQ: + + Message Type + Assigned Session ID + Call Serial Number + + The following AVPs MAY be present in the ICRQ: + + Bearer Type + Physical Channel ID + Calling Number + Called Number + Sub-Address + +6.7 Incoming-Call-Reply (ICRP) + + Incoming-Call-Reply (ICRP) is a control message sent by the LNS to + the LAC in response to a received ICRQ message. It is the second in + the three message exchange used for establishing sessions within an + L2TP tunnel. + + ICRP is used to indicate that the ICRQ was successful and for the LAC + to answer the call if it has not already done so. It also allows the + LNS to indicate necessary parameters for the L2TP session. + + The following AVPs MUST be present in the ICRP: + + Message Type + Assigned Session ID + +6.8 Incoming-Call-Connected (ICCN) + + Incoming-Call-Connected (ICCN) is a control message sent by the LAC + to the LNS in response to a received ICRP message. It is the third + message in the three message exchange used for establishing sessions + within an L2TP tunnel. + + ICCN is used to indicate that the ICRP was accepted, the call has + been answered, and that the L2TP session should move to the + established state. It also provides additional information to the + LNS about parameters used for the answered call (parameters that may + not always available at the time the ICRQ is issued). + + The following AVPs MUST be present in the ICCN: + + Message Type + (Tx) Connect Speed + Framing Type + + + +Townsley, et al. Standards Track [Page 51] + +RFC 2661 L2TP August 1999 + + + The following AVPs MAY be present in the ICCN: + + Initial Received LCP CONFREQ + Last Sent LCP CONFREQ + Last Received LCP CONFREQ + Proxy Authen Type + Proxy Authen Name + Proxy Authen Challenge + Proxy Authen ID + Proxy Authen Response + Private Group ID + Rx Connect Speed + Sequencing Required + +6.9 Outgoing-Call-Request (OCRQ) + + Outgoing-Call-Request (OCRQ) is a control message sent by the LNS to + the LAC to indicate that an outbound call from the LAC is to be + established. It is the first in a three message exchange used for + establishing a session within an L2TP tunnel. + + OCRQ is used to indicate that a session is to be established between + the LNS and LAC for this call and provides the LAC with parameter + information for both the L2TP session, and the call that is to be + placed + + An LNS MUST have received a Bearer Capabilities AVP during tunnel + establishment from an LAC in order to request an outgoing call to + that LAC. + + The following AVPs MUST be present in the OCRQ: + + Message Type + Assigned Session ID + Call Serial Number + Minimum BPS + Maximum BPS + Bearer Type + Framing Type + Called Number + + The following AVPs MAY be present in the OCRQ: + + Sub-Address + + + + + + + +Townsley, et al. Standards Track [Page 52] + +RFC 2661 L2TP August 1999 + + +6.10 Outgoing-Call-Reply (OCRP) + + Outgoing-Call-Reply (OCRP) is a control message sent by the LAC to + the LNS in response to a received OCRQ message. It is the second in a + three message exchange used for establishing a session within an L2TP + tunnel. + + OCRP is used to indicate that the LAC is able to attempt the outbound + call and returns certain parameters regarding the call attempt. + + The following AVPs MUST be present in the OCRP: + + Message Type + Assigned Session ID + + The following AVPs MAY be present in the OCRP: + + Physical Channel ID + +6.11 Outgoing-Call-Connected (OCCN) + + Outgoing-Call-Connected (OCCN) is a control message sent by the LAC + to the LNS following the OCRP and after the outgoing call has been + completed. It is the final message in a three message exchange used + for establishing a session within an L2TP tunnel. + + OCCN is used to indicate that the result of a requested outgoing call + was successful. It also provides information to the LNS about the + particular parameters obtained after the call was established. + + The following AVPs MUST be present in the OCCN: + + Message Type + (Tx) Connect Speed + Framing Type + + The following AVPs MAY be present in the OCCN: + + Rx Connect Speed + Sequencing Required + +6.12 Call-Disconnect-Notify (CDN) + + The Call-Disconnect-Notify (CDN) message is an L2TP control message + sent by either the LAC or LNS to request disconnection of a specific + call within the tunnel. Its purpose is to inform the peer of the + + + + + +Townsley, et al. Standards Track [Page 53] + +RFC 2661 L2TP August 1999 + + + disconnection and the reason why the disconnection occurred. The peer + MUST clean up any resources, and does not send back any indication of + success or failure for such cleanup. + + The following AVPs MUST be present in the CDN: + + Message Type + Result Code + Assigned Session ID + + The following AVPs MAY be present in the CDN: + + Q.931 Cause Code + +6.13 WAN-Error-Notify (WEN) + + The WAN-Error-Notify message is an L2TP control message sent by the + LAC to the LNS to indicate WAN error conditions (conditions that + occur on the interface supporting PPP). The counters in this message + are cumulative. This message should only be sent when an error + occurs, and not more than once every 60 seconds. The counters are + reset when a new call is established. + + The following AVPs MUST be present in the WEN: + + Message Type + Call Errors + +6.14 Set-Link-Info (SLI) + + The Set-Link-Info message is an L2TP control message sent by the LNS + to the LAC to set PPP-negotiated options. These options can change + at any time during the life of the call, thus the LAC MUST be able to + update its internal call information and behavior on an active PPP + session. + + The following AVPs MUST be present in the SLI: + + Message Type + ACCM + +7.0 Control Connection State Machines + + The control messages defined in section 6 are exchanged by way of + state tables defined in this section. Tables are defined for incoming + call placement, outgoing call placement, as well as for initiation of + + + + + +Townsley, et al. Standards Track [Page 54] + +RFC 2661 L2TP August 1999 + + + the tunnel itself. The state tables do not encode timeout and + retransmission behavior, as this is handled in the underlying + semantics defined in Section 5.8. + +7.1 Control Connection Protocol Operation + + This section describes the operation of various L2TP control + connection functions and the Control Connection messages which are + used to support them. + + Receipt of an invalid or unrecoverable malformed control message + should be logged appropriately and the control connection cleared to + ensure recovery to a known state. The control connection may then be + restarted by the initiator. + + An invalid control message is defined as a message which contains a + Message Type that is marked mandatory (see Section 4.4.1) and is + unknown to the implementation, or a control message that is received + in an improper sequence (e.g. an SCCCN sent in reply to an SCCRQ). + + Examples of a malformed control message include one that has an + invalid value in its header, contains an AVP that is formatted + incorrectly or whose value is out of range, or a message that is + missing a required AVP. A control message with a malformed header + should be discarded. A control message with an invalid AVP should + look to the M-bit for that AVP to determine whether the error is + recoverable or not. + + A malformed yet recoverable non-mandatory (M-bit is not set) AVP + within a control message should be treated in a similar manner as an + unrecognized non-mandatory AVP. Thus, if a malformed AVP is received + with the M-bit set, the session or tunnel should be terminated with a + proper Result or Error Code sent. If the M-bit is not set, the AVP + should be ignored (with the exception of logging a local error + message) and the message accepted. + + This MUST NOT be considered a license to send malformed AVPs, but + simply a guide towards how to handle an improperly formatted message + if one is received. It is impossible to list all potential + malformations of a given message and give advice for each. That said, + one example of a recoverable, malformed AVP might be if the Rx + Connect Speed AVP, attribute 38, is received with a length of 8 + rather than 10 and the BPS given in 2 octets rather than 4. Since the + Rx Connect Speed is non-mandatory, this condition should not be + considered catastrophic. As such, the control message should be + accepted as if the AVP had not been received (with the exception of a + local error message being logged). + + + + +Townsley, et al. Standards Track [Page 55] + +RFC 2661 L2TP August 1999 + + + In several cases in the following tables, a protocol message is sent, + and then a "clean up" occurs. Note that regardless of the initiator + of the tunnel destruction, the reliable delivery mechanism must be + allowed to run (see Section 5.8) before destroying the tunnel. This + permits the tunnel management messages to be reliably delivered to + the peer. + + Appendix B.1 contains an example of lock-step tunnel establishment. + +7.2 Control Connection States + + The L2TP control connection protocol is not distinguishable between + the LNS and LAC, but is distinguishable between the originator and + receiver. The originating peer is the one which first initiates + establishment of the tunnel (in a tie breaker situation, this is the + winner of the tie). Since either LAC or LNS can be the originator, a + collision can occur. See the Tie Breaker AVP in Section 4.4.3 for a + description of this and its resolution. + +7.2.1 Control Connection Establishment + + State Event Action New State + ----- ----- ------ --------- + idle Local Send SCCRQ wait-ctl-reply + Open request + + idle Receive SCCRQ, Send SCCRP wait-ctl-conn + acceptable + + idle Receive SCCRQ, Send StopCCN, idle + not acceptable Clean up + + idle Receive SCCRP Send StopCCN idle + Clean up + + idle Receive SCCCN Clean up idle + + wait-ctl-reply Receive SCCRP, Send SCCCN, established + acceptable Send tunnel-open + event to waiting + sessions + + wait-ctl-reply Receive SCCRP, Send StopCCN, idle + not acceptable Clean up + + wait-ctl-reply Receive SCCRQ, Clean up, idle + lose tie-breaker Re-queue SCCRQ + for idle state + + + +Townsley, et al. Standards Track [Page 56] + +RFC 2661 L2TP August 1999 + + + wait-ctl-reply Receive SCCCN Send StopCCN idle + Clean up + + wait-ctl-conn Receive SCCCN, Send tunnel-open established + acceptable event to waiting + sessions + + wait-ctl-conn Receive SCCCN, Send StopCCN, idle + not acceptable Clean up + + wait-ctl-conn Receive SCCRP, Send StopCCN, idle + SCCRQ Clean up + + established Local Send tunnel-open established + Open request event to waiting + (new call) sessions + + established Admin Send StopCCN idle + Tunnel Close Clean up + + established Receive SCCRQ, Send StopCCN idle + SCCRP, SCCCN Clean up + + idle Receive StopCCN Clean up idle + wait-ctl-reply, + wait-ctl-conn, + established + + The states associated with the LNS or LAC for control connection + establishment are: + + idle + Both initiator and recipient start from this state. An initiator + transmits an SCCRQ, while a recipient remains in the idle state + until receiving an SCCRQ. + + wait-ctl-reply + The originator checks to see if another connection has been + requested from the same peer, and if so, handles the collision + situation described in Section 5.8. + + When an SCCRP is received, it is examined for a compatible + version. If the version of the reply is lower than the version + sent in the request, the older (lower) version should be used + provided it is supported. If the version in the reply is earlier + and supported, the originator moves to the established state. If + + + + + +Townsley, et al. Standards Track [Page 57] + +RFC 2661 L2TP August 1999 + + + the version is earlier and not supported, a StopCCN MUST be sent + to the peer and the originator cleans up and terminates the + tunnel. + + wait-ctl-conn + This is where an SCCCN is awaited; upon receipt, the challenge + response is checked. The tunnel either is established, or is torn + down if an authorization failure is detected. + + established + An established connection may be terminated by either a local + condition or the receipt of a Stop-Control-Connection- + Notification. In the event of a local termination, the originator + MUST send a Stop-Control-Connection-Notification and clean up the + tunnel. + + If the originator receives a Stop-Control-Connection-Notification + it MUST also clean up the tunnel. + +7.3 Timing considerations + + Due to the real-time nature of telephone signaling, both the LNS and + LAC should be implemented with multi-threaded architectures such that + messages related to multiple calls are not serialized and blocked. + The call and connection state figures do not specify exceptions + caused by timers. These are addressed in Section 5.8. + +7.4 Incoming calls + + An Incoming-Call-Request message is generated by the LAC when an + incoming call is detected (for example, an associated telephone line + rings). The LAC selects a Session ID and serial number and indicates + the call bearer type. Modems should always indicate analog call type. + ISDN calls should indicate digital when unrestricted digital service + or rate adaption is used and analog if digital modems are involved. + Calling Number, Called Number, and Subaddress may be included in the + message if they are available from the telephone network. + + Once the LAC sends the Incoming-Call-Request, it waits for a response + from the LNS but it does not necessarily answer the call from the + telephone network yet. The LNS may choose not to accept the call if: + + - No resources are available to handle more sessions + - The dialed, dialing, or subaddress fields do not correspond to + an authorized user + - The bearer service is not authorized or supported + + + + + +Townsley, et al. Standards Track [Page 58] + +RFC 2661 L2TP August 1999 + + + If the LNS chooses to accept the call, it responds with an Incoming- + Call-Reply. When the LAC receives the Incoming-Call-Reply, it + attempts to connect the call. A final call connected message from + the LAC to the LNS indicates that the call states for both the LAC + and the LNS should enter the established state. If the call + terminated before the LNS could accept it, a Call-Disconnect-Notify + is sent by the LAC to indicate this condition. + + When the dialed-in client hangs up, the call is cleared normally and + the LAC sends a Call-Disconnect-Notify message. If the LNS wishes to + clear a call, it sends a Call-Disconnect-Notify message and cleans up + its session. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Townsley, et al. Standards Track [Page 59] + +RFC 2661 L2TP August 1999 + + +7.4.1 LAC Incoming Call States + + State Event Action New State + ----- ----- ------ --------- + idle Bearer Ring or Initiate local wait-tunnel + Ready to indicate tunnel open + incoming conn. + + idle Receive ICCN, Clean up idle + ICRP, CDN + + wait-tunnel Bearer line drop Clean up idle + or local close + request + + wait-tunnel tunnel-open Send ICRQ wait-reply + + wait-reply Receive ICRP, Send ICCN established + acceptable + + wait-reply Receive ICRP, Send CDN, idle + Not acceptable Clean up + + wait-reply Receive ICRQ Send CDN idle + Clean up + + wait-reply Receive CDN Clean up idle + ICCN + + wait-reply Local Send CDN, idle + close request or Clean up + Bearer line drop + + established Receive CDN Clean up idle + + established Receive ICRQ, Send CDN, idle + ICRP, ICCN Clean up + + established Bearer line Send CDN, idle + drop or local Clean up + close request + + + + + + + + + + +Townsley, et al. Standards Track [Page 60] + +RFC 2661 L2TP August 1999 + + + The states associated with the LAC for incoming calls are: + + idle + The LAC detects an incoming call on one of its interfaces. + Typically this means an analog line is ringing or an ISDN TE has + detected an incoming Q.931 SETUP message. The LAC initiates its + tunnel establishment state machine, and moves to a state waiting + for confirmation of the existence of a tunnel. + + wait-tunnel + In this state the session is waiting for either the control + connection to be opened or for verification that the tunnel is + already open. Once an indication that the tunnel has/was opened, + session control messages may be exchanged. The first of these is + the Incoming-Call-Request. + + wait-reply + The LAC receives either a CDN message indicating the LNS is not + willing to accept the call (general error or don't accept) and + moves back into the idle state, or an Incoming-Call-Reply message + indicating the call is accepted, the LAC sends an Incoming-Call- + Connected message and enters the established state. + + established + Data is exchanged over the tunnel. The call may be cleared + following: + + An event on the connected interface: The LAC sends a Call- + Disconnect-Notify message + + Receipt of a Call-Disconnect-Notify message: The LAC cleans + up, disconnecting the call. + + A local reason: The LAC sends a Call-Disconnect-Notify + message. + + + + + + + + + + + + + + + + + + + +Townsley, et al. Standards Track [Page 61] + +RFC 2661 L2TP August 1999 + + +7.4.2 LNS Incoming Call States + + State Event Action New State + ----- ----- ------ --------- + idle Receive ICRQ, Send ICRP wait-connect + acceptable + + idle Receive ICRQ, Send CDN, idle + not acceptable Clean up + + idle Receive ICRP Send CDN idle + Clean up + + idle Receive ICCN Clean up idle + + wait-connect Receive ICCN Prepare for established + acceptable data + + wait-connect Receive ICCN Send CDN, idle + not acceptable Clean up + + wait-connect Receive ICRQ, Send CDN idle + ICRP Clean up + + idle, Receive CDN Clean up idle + wait-connect, + established + + wait-connect Local Send CDN, idle + established Close request Clean up + + established Receive ICRQ, Send CDN idle + ICRP, ICCN Clean up + + The states associated with the LNS for incoming calls are: + + idle + An Incoming-Call-Request message is received. If the request is + not acceptable, a Call-Disconnect-Notify is sent back to the LAC + and the LNS remains in the idle state. If the Incoming-Call- + Request message is acceptable, an Incoming-Call-Reply is sent. The + session moves to the wait-connect state. + + wait-connect + If the session is still connected on the LAC, the LAC sends an + Incoming-Call-Connected message to the LNS which then moves into + established state. The LAC may send a Call-Disconnect-Notify to + indicate that the incoming caller could not be connected. This + + + +Townsley, et al. Standards Track [Page 62] + +RFC 2661 L2TP August 1999 + + + could happen, for example, if a telephone user accidentally places + a standard voice call to an LAC resulting in a handshake failure + on the called modem. + + established + The session is terminated either by receipt of a Call-Disconnect- + Notify message from the LAC or by sending a Call-Disconnect- + Notify. Clean up follows on both sides regardless of the + initiator. + +7.5 Outgoing calls + + Outgoing calls are initiated by an LNS and instruct an LAC to place a + call. There are three messages for outgoing calls: Outgoing-Call- + Request, Outgoing-Call-Reply, and Outgoing-Call-Connected. The LNS + sends an Outgoing-Call-Request specifying the dialed party phone + number, subaddress and other parameters. The LAC MUST respond to the + Outgoing-Call-Request message with an Outgoing-Call-Reply message + once the LAC determines that the proper facilities exist to place the + call and the call is administratively authorized. For example, is + this LNS allowed to dial an international call? Once the outbound + call is connected, the LAC sends an Outgoing-Call-Connected message + to the LNS indicating the final result of the call attempt: + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Townsley, et al. Standards Track [Page 63] + +RFC 2661 L2TP August 1999 + + +7.5.1 LAC Outgoing Call States + + State Event Action New State + ----- ----- ------ --------- + idle Receive OCRQ, Send OCRP, wait-cs-answer + acceptable Open bearer + + idle Receive OCRQ, Send CDN, idle + not acceptable Clean up + + idle Receive OCRP Send CDN idle + Clean up + + idle Receive OCCN, Clean up idle + CDN + + wait-cs-answer Bearer answer, Send OCCN established + framing detected + + wait-cs-answer Bearer failure Send CDN, idle + Clean up + + wait-cs-answer Receive OCRQ, Send CDN idle + OCRP, OCCN Clean up + + established Receive OCRQ, Send CDN idle + OCRP, OCCN Clean up + + wait-cs-answer, Receive CDN Clean up idle + established + + established Bearer line drop, Send CDN, idle + Local close Clean up + request + + The states associated with the LAC for outgoing calls are: + + idle + If Outgoing-Call-Request is received in error, respond with a + Call-Disconnect-Notify. Otherwise, allocate a physical channel and + send an Outgoing-Call-Reply. Place the outbound call and move to + the wait-cs-answer state. + + wait-cs-answer + If the call is not completed or a timer expires waiting for the + call to complete, send a Call-Disconnect-Notify with the + appropriate error condition set and go to idle state. If a circuit + + + + +Townsley, et al. Standards Track [Page 64] + +RFC 2661 L2TP August 1999 + + + switched connection is established and framing is detected, send + an Outgoing-Call-Connected indicating success and go to + established state. + + established + If a Call-Disconnect-Notify is received by the LAC, the telco call + MUST be released via appropriate mechanisms and the session + cleaned up. If the call is disconnected by the client or the + called interface, a Call-Disconnect-Notify message MUST be sent to + the LNS. The sender of the Call-Disconnect-Notify message returns + to the idle state after sending of the message is complete. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Townsley, et al. Standards Track [Page 65] + +RFC 2661 L2TP August 1999 + + +7.5.2 LNS Outgoing Call States + + State Event Action New State + ----- ----- ------ --------- + idle Local Initiate local wait-tunnel + open request tunnel-open + + idle Receive OCCN, Clean up idle + OCRP, CDN + + wait-tunnel tunnel-open Send OCRQ wait-reply + + wait-reply Receive OCRP, none wait-connect + acceptable + + wait-reply Receive OCRP, Send CDN idle + not acceptable Clean up + + wait-reply Receive OCCN, Send CDN idle + OCRQ Clean up + + wait-connect Receive OCCN none established + + wait-connect Receive OCRQ, Send CDN idle + OCRP Clean up + + idle, Receive CDN, Clean up idle + wait-reply, + wait-connect, + established + + established Receive OCRQ, Send CDN idle + OCRP, OCCN Clean up + + wait-reply, Local Send CDN idle + wait-connect, Close request Clean up + established + + wait-tunnel Local Clean up idle + Close request + + The states associated with the LNS for outgoing calls are: + + idle, wait-tunnel + When an outgoing call is initiated, a tunnel is first created, + much as the idle and wait-tunnel states for an LAC incoming call. + Once a tunnel is established, an Outgoing-Call-Request message is + sent to the LAC and the session moves into the wait-reply state. + + + +Townsley, et al. Standards Track [Page 66] + +RFC 2661 L2TP August 1999 + + + wait-reply + If a Call-Disconnect-Notify is received, an error occurred, and + the session is cleaned up and returns to idle. If an Outgoing- + Call-Reply is received, the call is in progress and the session + moves to the wait-connect state. + + wait-connect + If a Call-Disconnect-Notify is received, the call failed; the + session is cleaned up and returns to idle. If an Outgoing-Call- + Connected is received, the call has succeeded and the session may + now exchange data. + + established + If a Call-Disconnect-Notify is received, the call has been + terminated for the reason indicated in the Result and Cause Codes; + the session moves back to the idle state. If the LNS chooses to + terminate the session, it sends a Call-Disconnect-Notify to the + LAC and then cleans up and idles its session. + +7.6 Tunnel Disconnection + + The disconnection of a tunnel consists of either peer issuing a + Stop-Control-Connection-Notification. The sender of this Notification + should wait a finite period of time for the acknowledgment of this + message before releasing the control information associated with the + tunnel. The recipient of this Notification should send an + acknowledgment of the Notification and then release the associated + control information. + + When to release a tunnel is an implementation issue and is not + specified in this document. A particular implementation may use + whatever policy is appropriate for determining when to release a + control connection. Some implementations may leave a tunnel open for + a period of time or perhaps indefinitely after the last session for + that tunnel is cleared. Others may choose to disconnect the tunnel + immediately after the last user connection on the tunnel disconnects. + +8.0 L2TP Over Specific Media + + L2TP is self-describing, operating at a level above the media over + which it is carried. However, some details of its connection to media + are required to permit interoperable implementations. The following + sections describe details needed to permit interoperability over + specific media. + + + + + + + +Townsley, et al. Standards Track [Page 67] + +RFC 2661 L2TP August 1999 + + +8.1 L2TP over UDP/IP + + L2TP uses the registered UDP port 1701 [RFC1700]. The entire L2TP + packet, including payload and L2TP header, is sent within a UDP + datagram. The initiator of an L2TP tunnel picks an available source + UDP port (which may or may not be 1701), and sends to the desired + destination address at port 1701. The recipient picks a free port on + its own system (which may or may not be 1701), and sends its reply to + the initiator's UDP port and address, setting its own source port to + the free port it found. Once the source and destination ports and + addresses are established, they MUST remain static for the life of + the tunnel. + + It has been suggested that having the recipient choose an arbitrary + source port (as opposed to using the destination port in the packet + initiating the tunnel, i.e., 1701) may make it more difficult for + L2TP to traverse some NAT devices. Implementors should consider the + potential implication of this before before choosing an arbitrary + source port. + + IP fragmentation may occur as the L2TP packet travels over the IP + substrate. L2TP makes no special efforts to optimize this. A LAC + implementation MAY cause its LCP to negotiate for a specific MRU, + which could optimize for LAC environments in which the MTU's of the + path over which the L2TP packets are likely to travel have a + consistent value. + + The default for any L2TP implementation is that UDP checksums MUST be + enabled for both control and data messages. An L2TP implementation + MAY provide an option to disable UDP checksums for data messages. It + is recommended that UDP checksums always be enabled on control + packets. + + Port 1701 is used for both L2F [RFC2341] and L2TP packets. The + Version field in each header may be used to discriminate between the + two packet types (L2F uses a value of 1, and the L2TP version + described in this document uses a value of 2). An L2TP implementation + running on a system which does not support L2F MUST silently discard + all L2F packets. + + To the PPP clients using an L2TP-over-UDP/IP tunnel, the PPP link has + the characteristic of being able to reorder or silently drop packets. + The former may break non-IP protocols being carried by PPP, + especially LAN-centric ones such as bridging. The latter may break + protocols which assume per-packet indication of error, such as TCP + header compression. Sequencing may be handled by using L2TP data + message sequence numbers if any protocol being transported by the PPP + + + + +Townsley, et al. Standards Track [Page 68] + +RFC 2661 L2TP August 1999 + + + tunnel cannot tolerate reordering. 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 L2TP 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 + 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/UDP/IP transport is + an unreliable transport. As with any PPP media 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. + +8.2 IP + + When operating in IP environments, L2TP MUST offer the UDP + encapsulation described in 8.1 as its default configuration for IP + operation. Other configurations (perhaps corresponding to a + compressed header format) MAY be defined and made available as a + configurable option. + +9.0 Security Considerations + + L2TP encounters several security issues in its operation. The + general approach of L2TP to these issues is documented here. + + + + + + + +Townsley, et al. Standards Track [Page 69] + +RFC 2661 L2TP August 1999 + + +9.1 Tunnel Endpoint Security + + The tunnel endpoints may optionally perform an authentication + procedure of one another during tunnel establishment. This + authentication has the same security attributes as CHAP, and has + reasonable protection against replay and snooping during the tunnel + establishment process. This mechanism is not designed to provide any + authentication beyond tunnel establishment; it is fairly simple for a + malicious user who can snoop the tunnel stream to inject packets once + an authenticated tunnel establishment has been completed + successfully. + + For authentication to occur, the LAC and LNS MUST share a single + secret. Each side uses this same secret when acting as authenticatee + as well as authenticator. Since a single secret is used, the tunnel + authentication AVPs include differentiating values in the CHAP ID + fields for each message digest calculation to guard against replay + attacks. + + The Assigned Tunnel ID and Assigned Session ID (See Section 4.4.3) + SHOULD be selected in an unpredictable manner rather than + sequentially or otherwise. Doing so will help deter hijacking of a + session by a malicious user who does not have access to packet traces + between the LAC and LNS. + +9.2 Packet Level Security + + Securing L2TP requires that the underlying transport make available + encryption, integrity and authentication services for all L2TP + traffic. This secure transport operates on the entire L2TP packet + and is functionally independent of PPP and the protocol being carried + by PPP. As such, L2TP is only concerned with confidentiality, + authenticity, and integrity of the L2TP packets between its tunnel + + endpoints (the LAC and LNS), not unlike link-layer encryption being + concerned only about protecting the confidentiality of traffic + between its physical endpoints. + +9.3 End to End Security + + Protecting the L2TP packet stream via a secure transport does, in + turn, also protect the data within the tunneled PPP packets while + transported from the LAC to the LNS. Such protection should not be + considered a substitution for end-to-end security between + communicating hosts or applications. + + + + + + +Townsley, et al. Standards Track [Page 70] + +RFC 2661 L2TP August 1999 + + +9.4 L2TP and IPsec + + When running over IP, IPsec provides packet-level security via ESP + and/or AH. All L2TP control and data packets for a particular tunnel + appear as homogeneous UDP/IP data packets to the IPsec system. + + In addition to IP transport security, IPsec defines a mode of + operation that allows tunneling of IP packets. The packet level + encryption and authentication provided by IPsec tunnel mode and that + provided by L2TP secured with IPsec provide an equivalent level of + security for these requirements. + + IPsec also defines access control features that are required of a + compliant IPsec implementation. These features allow filtering of + packets based upon network and transport layer characteristics such + as IP address, ports, etc. In the L2TP tunneling model, analogous + filtering is logically performed at the PPP layer or network layer + above L2TP. These network layer access control features may be + handled at the LNS via vendor-specific authorization features based + upon the authenticated PPP user, or at the network layer itself by + using IPsec transport mode end-to-end between the communicating + hosts. The requirements for access control mechanisms are not a part + of the L2TP specification and as such are outside the scope of this + document. + +9.5 Proxy PPP Authentication + + L2TP defines AVPs that MAY be exchanged during session establishment + to provide forwarding of PPP authentication information obtained at + the LAC to the LNS for validation (see Section 4.4.5). This implies a + direct trust relationship of the LAC on behalf of the LNS. If the + LNS chooses to implement proxy authentication, it MUST be able to be + configured off, requiring a new round a PPP authentication initiated + by the LNS (which may or may not include a new round of LCP + negotiation). + +10.0 IANA Considerations + + This document defines a number of "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. + +10.1 AVP Attributes + + As defined in Section 4.1, AVPs contain vendor ID, Attribute and + Value fields. For vendor ID value of 0, IANA will maintain a registry + + + +Townsley, et al. Standards Track [Page 71] + +RFC 2661 L2TP August 1999 + + + of assigned Attributes and in some case also values. Attributes 0-39 + are assigned as defined in Section 4.4. The remaining values are + available for assignment through IETF Consensus [RFC 2434]. + +10.2 Message Type AVP Values + + As defined in Section 4.4.1, Message Type AVPs (Attribute Type 0) + have an associated value maintained by IANA. Values 0-16 are defined + in Section 3.2, the remaining values are available for assignment via + IETF Consensus [RFC 2434] + +10.3 Result Code AVP Values + + As defined in Section 4.4.2, Result Code AVPs (Attribute Type 1) + contain three fields. Two of these fields (the Result Code and Error + Code fields) have associated values maintained by IANA. + +10.3.1 Result Code Field Values + + The Result Code AVP may be included in CDN and StopCCN messages. The + allowable values for the Result Code field of the AVP differ + depending upon the value of the Message Type AVP. For the StopCCN + message, values 0-7 are defined in Section 4.4.2; for the StopCCN + message, values 0-11 are defined in the same section. The remaining + values of the Result Code field for both messages are available for + assignment via IETF Consensus [RFC 2434]. + +10.3.2 Error Code Field Values + + Values 0-7 are defined in Section 4.4.2. Values 8-32767 are + available for assignment via IETF Consensus [RFC 2434]. The remaining + values of the Error Code field are available for assignment via First + Come First Served [RFC 2434]. + +10.4 Framing Capabilities & Bearer Capabilities + + The Framing Capabilities AVP and Bearer Capabilities AVPs (defined in + Section 4.4.3) both contain 32-bit bitmasks. Additional bits should + only be defined via a Standards Action [RFC 2434]. + +10.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 4.4.5, the + remaining values are available for assignment via First Come First + Served [RFC 2434]. + + + + + +Townsley, et al. Standards Track [Page 72] + +RFC 2661 L2TP August 1999 + + +10.6 AVP Header Bits + + There are four remaining reserved bits in the AVP header. Additional + bits should only be assigned via a Standards Action [RFC 2434]. + +11.0 References + + [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. + + [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. + + + + + +Townsley, et al. Standards Track [Page 73] + +RFC 2661 L2TP August 1999 + + + [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 + +12.0 Acknowledgments + + The basic concept for L2TP and many of its protocol constructs were + adopted from L2F [RFC2341] and PPTP [PPTP]. Authors of these are A. + Valencia, M. Littlewood, T. Kolar, K. Hamzeh, G. Pall, W. Verthein, + J. Taarud, W. Little, and G. Zorn. + + Dory Leifer made valuable refinements to the protocol definition of + L2TP and contributed to the editing of this document. + + Steve Cobb and Evan Caves redesigned the state machine tables. + + Barney Wolff provided a great deal of design input on the endpoint + authentication mechanism. + + 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 this document. + + + + +Townsley, et al. Standards Track [Page 74] + +RFC 2661 L2TP August 1999 + + +13.0 Authors' Addresses + + Gurdeep Singh Pall + Microsoft Corporation + Redmond, WA + + EMail: gurdeep@microsoft.com + + + Bill Palter + RedBack Networks, Inc + 1389 Moffett Park Drive + Sunnyvale, CA 94089 + + EMail: palter@zev.net + + + Allan Rubens + Ascend Communications + 1701 Harbor Bay Parkway + Alameda, CA 94502 + + EMail: acr@del.com + + + W. Mark Townsley + cisco Systems + 7025 Kit Creek Road + PO Box 14987 + Research Triangle Park, NC 27709 + + EMail: townsley@cisco.com + + + Andrew J. Valencia + cisco Systems + 170 West Tasman Drive + San Jose CA 95134-1706 + + EMail: vandys@cisco.com + + + Glen Zorn + Microsoft Corporation + One Microsoft Way + Redmond, WA 98052 + + EMail: gwz@acm.org + + + +Townsley, et al. Standards Track [Page 75] + +RFC 2661 L2TP August 1999 + + +Appendix A: Control Channel Slow Start and Congestion Avoidance + + Although each side has indicated the maximum size of its receive + window, it is recommended that a slow start and congestion avoidance + method be used to transmit control packets. The methods described + here are based upon the TCP congestion avoidance algorithm as + described in section 21.6 of TCP/IP Illustrated, Volume I, by W. + Richard Stevens [STEVENS]. + + Slow start and congestion avoidance make use of several variables. + The congestion window (CWND) defines the number of packets a sender + may send before waiting for an acknowledgment. The size of CWND + expands and contracts as described below. Note however, that CWND is + never allowed to exceed the size of the advertised window obtained + from the Receive Window AVP (in the text below, it is assumed any + increase will be limited by the Receive Window Size). The variable + SSTHRESH determines when the sender switches from slow start to + congestion avoidance. Slow start is used while CWND is less than + SSHTRESH. + + A sender starts out in the slow start phase. CWND is initialized to + one packet, and SSHTRESH is initialized to the advertised window + (obtained from the Receive Window AVP). The sender then transmits + one packet and waits for its acknowledgement (either explicit or + piggybacked). When the acknowledgement is received, the congestion + window is incremented from one to two. During slow start, CWND is + increased by one packet each time an ACK (explicit ZLB or + piggybacked) is received. Increasing CWND by one on each ACK has the + effect of doubling CWND with each round trip, resulting in an + exponential increase. When the value of CWND reaches SSHTRESH, the + slow start phase ends and the congestion avoidance phase begins. + + During congestion avoidance, CWND expands more slowly. Specifically, + it increases by 1/CWND for every new ACK received. That is, CWND is + increased by one packet after CWND new ACKs have been received. + Window expansion during the congestion avoidance phase is effectively + linear, with CWND increasing by one packet each round trip. + + When congestion occurs (indicated by the triggering of a + retransmission) one half of the CWND is saved in SSTHRESH, and CWND + is set to one. The sender then reenters the slow start phase. + + + + + + + + + + +Townsley, et al. Standards Track [Page 76] + +RFC 2661 L2TP August 1999 + + +Appendix B: Control Message Examples + +B.1: Lock-step tunnel establishment + + In this example, an LAC establishes a tunnel, with the exchange + involving each side alternating in sending messages. This example + shows the final acknowledgment explicitly sent within a ZLB ACK + message. An alternative would be to piggyback the acknowledgement + within a message sent as a reply to the ICRQ or OCRQ that will likely + follow from the side that initiated the tunnel. + + LAC or LNS LNS or LAC + ---------- ---------- + + SCCRQ -> + Nr: 0, Ns: 0 + <- SCCRP + Nr: 1, Ns: 0 + SCCCN -> + Nr: 1, Ns: 1 + <- ZLB + Nr: 2, Ns: 1 + +B.2: Lost packet with retransmission + + An existing tunnel has a new session requested by the LAC. The ICRP + is lost and must be retransmitted by the LNS. Note that loss of the + ICRP has two impacts: not only does it keep the upper level state + machine from progressing, but it also keeps the LAC from seeing a + timely lower level acknowledgment of its ICRQ. + + LAC LNS + --- --- + + ICRQ -> + Nr: 1, Ns: 2 + + (packet lost) <- ICRP + Nr: 3, Ns: 1 + + (pause; LAC's timer started first, so fires first) + + ICRQ -> + Nr: 1, Ns: 2 + + (Realizing that it has already seen this packet, + the LNS discards the packet and sends a ZLB) + + + + +Townsley, et al. Standards Track [Page 77] + +RFC 2661 L2TP August 1999 + + + <- ZLB + Nr: 3, Ns: 2 + + (LNS's retransmit timer fires) + + <- ICRP + Nr: 3, Ns: 1 + ICCN -> + Nr: 2, Ns: 3 + + <- ZLB + Nr: 4, Ns: 2 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Townsley, et al. Standards Track [Page 78] + +RFC 2661 L2TP August 1999 + + +Appendix C: Intellectual Property Notice + + The IETF takes no position regarding the validity or scope of any + intellectual property or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; neither does it represent that it + has made any effort to identify any such rights. Information on the + IETF's procedures with respect to rights in standards-track and + standards-related documentation can be found in BCP-11. Copies of + claims of rights made available for publication and any assurances of + licenses to be made available, or the result of an attempt made to + obtain a general license or permission for the use of such + proprietary rights by implementers or users of this specification can + be obtained from the IETF Secretariat." + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights which may cover technology that may be required to practice + this standard. Please address the information to the IETF Executive + Director. + + The IETF has been notified of intellectual property rights claimed in + regard to some or all of the specification contained in this + document. For more information consult the online list of claimed + rights. + + + + + + + + + + + + + + + + + + + + + + + + + +Townsley, et al. Standards Track [Page 79] + +RFC 2661 L2TP August 1999 + + +Full Copyright Statement + + Copyright (C) The Internet Society (1999). 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 + 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. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Townsley, et al. Standards Track [Page 80] + diff --git a/rfc/rfc3931.txt b/rfc/rfc3931.txt new file mode 100644 index 00000000..e4287229 --- /dev/null +++ b/rfc/rfc3931.txt @@ -0,0 +1,5267 @@ + + + + + + +Network Working Group J. Lau, Ed. +Request for Comments: 3931 M. Townsley, Ed. +Category: Standards Track Cisco Systems + I. Goyret, Ed. + Lucent Technologies + March 2005 + + + Layer Two Tunneling Protocol - Version 3 (L2TPv3) + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + This document describes "version 3" of the Layer Two Tunneling + Protocol (L2TPv3). L2TPv3 defines the base control protocol and + encapsulation for tunneling multiple Layer 2 connections between two + IP nodes. Additional documents detail the specifics for each data + link type being emulated. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Changes from RFC 2661. . . . . . . . . . . . . . . . . . 4 + 1.2. Specification of Requirements. . . . . . . . . . . . . . 4 + 1.3. Terminology. . . . . . . . . . . . . . . . . . . . . . . 5 + 2. Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 3. Protocol Overview. . . . . . . . . . . . . . . . . . . . . . . 9 + 3.1. Control Message Types. . . . . . . . . . . . . . . . . . 10 + 3.2. L2TP Header Formats. . . . . . . . . . . . . . . . . . . 11 + 3.2.1. L2TP Control Message Header. . . . . . . . . . . 11 + 3.2.2. L2TP Data Message. . . . . . . . . . . . . . . . 12 + 3.3. Control Connection Management. . . . . . . . . . . . . . 13 + 3.3.1. Control Connection Establishment . . . . . . . . 14 + 3.3.2. Control Connection Teardown. . . . . . . . . . . 14 + 3.4. Session Management . . . . . . . . . . . . . . . . . . . 15 + 3.4.1. Session Establishment for an Incoming Call . . . 15 + 3.4.2. Session Establishment for an Outgoing Call . . . 15 + + + +Lau, et al. Standards Track [Page 1] + +RFC 3931 L2TPv3 March 2005 + + + 3.4.3. Session Teardown . . . . . . . . . . . . . . . . 16 + 4. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 16 + 4.1. L2TP Over Specific Packet-Switched Networks (PSNs) . . . 16 + 4.1.1. L2TPv3 over IP . . . . . . . . . . . . . . . . . 17 + 4.1.2. L2TP over UDP. . . . . . . . . . . . . . . . . . 18 + 4.1.3. L2TP and IPsec . . . . . . . . . . . . . . . . . 20 + 4.1.4. IP Fragmentation Issues. . . . . . . . . . . . . 21 + 4.2. Reliable Delivery of Control Messages. . . . . . . . . . 23 + 4.3. Control Message Authentication . . . . . . . . . . . . . 25 + 4.4. Keepalive (Hello). . . . . . . . . . . . . . . . . . . . 26 + 4.5. Forwarding Session Data Frames . . . . . . . . . . . . . 26 + 4.6. Default L2-Specific Sublayer . . . . . . . . . . . . . . 27 + 4.6.1. Sequencing Data Packets. . . . . . . . . . . . . 28 + 4.7. L2TPv2/v3 Interoperability and Migration . . . . . . . . 28 + 4.7.1. L2TPv3 over IP . . . . . . . . . . . . . . . . . 29 + 4.7.2. L2TPv3 over UDP. . . . . . . . . . . . . . . . . 29 + 4.7.3. Automatic L2TPv2 Fallback. . . . . . . . . . . . 29 + 5. Control Message Attribute Value Pairs. . . . . . . . . . . . . 30 + 5.1. AVP Format . . . . . . . . . . . . . . . . . . . . . . . 30 + 5.2. Mandatory AVPs and Setting the M Bit . . . . . . . . . . 32 + 5.3. Hiding of AVP Attribute Values . . . . . . . . . . . . . 33 + 5.4. AVP Summary. . . . . . . . . . . . . . . . . . . . . . . 36 + 5.4.1. General Control Message AVPs . . . . . . . . . . 36 + 5.4.2. Result and Error Codes . . . . . . . . . . . . . 40 + 5.4.3. Control Connection Management AVPs . . . . . . . 43 + 5.4.4. Session Management AVPs. . . . . . . . . . . . . 48 + 5.4.5. Circuit Status AVPs. . . . . . . . . . . . . . . 57 + 6. Control Connection Protocol Specification. . . . . . . . . . . 59 + 6.1. Start-Control-Connection-Request (SCCRQ) . . . . . . . . 60 + 6.2. Start-Control-Connection-Reply (SCCRP) . . . . . . . . . 60 + 6.3. Start-Control-Connection-Connected (SCCCN) . . . . . . . 61 + 6.4. Stop-Control-Connection-Notification (StopCCN) . . . . . 61 + 6.5. Hello (HELLO). . . . . . . . . . . . . . . . . . . . . . 61 + 6.6. Incoming-Call-Request (ICRQ) . . . . . . . . . . . . . . 62 + 6.7. Incoming-Call-Reply (ICRP) . . . . . . . . . . . . . . . 63 + 6.8. Incoming-Call-Connected (ICCN) . . . . . . . . . . . . . 63 + 6.9. Outgoing-Call-Request (OCRQ) . . . . . . . . . . . . . . 64 + 6.10. Outgoing-Call-Reply (OCRP) . . . . . . . . . . . . . . . 65 + 6.11. Outgoing-Call-Connected (OCCN) . . . . . . . . . . . . . 65 + 6.12. Call-Disconnect-Notify (CDN) . . . . . . . . . . . . . . 66 + 6.13. WAN-Error-Notify (WEN) . . . . . . . . . . . . . . . . . 66 + 6.14. Set-Link-Info (SLI). . . . . . . . . . . . . . . . . . . 67 + 6.15. Explicit-Acknowledgement (ACK) . . . . . . . . . . . . . 67 + 7. Control Connection State Machines. . . . . . . . . . . . . . . 68 + 7.1. Malformed AVPs and Control Messages. . . . . . . . . . . 68 + 7.2. Control Connection States. . . . . . . . . . . . . . . . 69 + 7.3. Incoming Calls . . . . . . . . . . . . . . . . . . . . . 71 + 7.3.1. ICRQ Sender States . . . . . . . . . . . . . . . 72 + + + +Lau, et al. Standards Track [Page 2] + +RFC 3931 L2TPv3 March 2005 + + + 7.3.2. ICRQ Recipient States. . . . . . . . . . . . . . 73 + 7.4. Outgoing Calls . . . . . . . . . . . . . . . . . . . . . 74 + 7.4.1. OCRQ Sender States . . . . . . . . . . . . . . . 75 + 7.4.2. OCRQ Recipient (LAC) States. . . . . . . . . . . 76 + 7.5. Termination of a Control Connection. . . . . . . . . . . 77 + 8. Security Considerations. . . . . . . . . . . . . . . . . . . . 78 + 8.1. Control Connection Endpoint and Message Security . . . . 78 + 8.2. Data Packet Spoofing . . . . . . . . . . . . . . . . . . 78 + 9. Internationalization Considerations. . . . . . . . . . . . . . 79 + 10. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 80 + 10.1. Control Message Attribute Value Pairs (AVPs) . . . . . . 80 + 10.2. Message Type AVP Values. . . . . . . . . . . . . . . . . 81 + 10.3. Result Code AVP Values . . . . . . . . . . . . . . . . . 81 + 10.4. AVP Header Bits. . . . . . . . . . . . . . . . . . . . . 82 + 10.5. L2TP Control Message Header Bits . . . . . . . . . . . . 82 + 10.6. Pseudowire Types . . . . . . . . . . . . . . . . . . . . 83 + 10.7. Circuit Status Bits. . . . . . . . . . . . . . . . . . . 83 + 10.8. Default L2-Specific Sublayer bits. . . . . . . . . . . . 84 + 10.9. L2-Specific Sublayer Type. . . . . . . . . . . . . . . . 84 + 10.10 Data Sequencing Level. . . . . . . . . . . . . . . . . . 84 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 85 + 11.1. Normative References . . . . . . . . . . . . . . . . . . 85 + 11.2. Informative References . . . . . . . . . . . . . . . . . 85 + 12. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 87 + Appendix A: Control Slow Start and Congestion Avoidance. . . . . . 89 + Appendix B: Control Message Examples . . . . . . . . . . . . . . . 90 + Appendix C: Processing Sequence Numbers. . . . . . . . . . . . . . 91 + Editors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 93 + Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 94 + +1. Introduction + + The Layer Two Tunneling Protocol (L2TP) provides a dynamic mechanism + for tunneling Layer 2 (L2) "circuits" across a packet-oriented data + network (e.g., over IP). L2TP, as originally defined in RFC 2661, is + a standard method for tunneling Point-to-Point Protocol (PPP) + [RFC1661] sessions. L2TP has since been adopted for tunneling a + number of other L2 protocols. In order to provide greater + modularity, this document describes the base L2TP protocol, + independent of the L2 payload that is being tunneled. + + The base L2TP protocol defined in this document consists of (1) the + control protocol for dynamic creation, maintenance, and teardown of + L2TP sessions, and (2) the L2TP data encapsulation to multiplex and + demultiplex L2 data streams between two L2TP nodes across an IP + network. Additional documents are expected to be published for each + L2 data link emulation type (a.k.a. pseudowire-type) supported by + L2TP (i.e., PPP, Ethernet, Frame Relay, etc.). These documents will + + + +Lau, et al. Standards Track [Page 3] + +RFC 3931 L2TPv3 March 2005 + + + contain any pseudowire-type specific details that are outside the + scope of this base specification. + + When the designation between L2TPv2 and L2TPv3 is necessary, L2TP as + defined in RFC 2661 will be referred to as "L2TPv2", corresponding to + the value in the Version field of an L2TP header. (Layer 2 + Forwarding, L2F, [RFC2341] was defined as "version 1".) At times, + L2TP as defined in this document will be referred to as "L2TPv3". + Otherwise, the acronym "L2TP" will refer to L2TPv3 or L2TP in + general. + +1.1. Changes from RFC 2661 + + Many of the protocol constructs described in this document are + carried over from RFC 2661. Changes include clarifications based on + years of interoperability and deployment experience as well as + modifications to either improve protocol operation or provide a + clearer separation from PPP. The intent of these modifications is to + achieve a healthy balance between code reuse, interoperability + experience, and a directed evolution of L2TP as it is applied to new + tasks. + + Notable differences between L2TPv2 and L2TPv3 include the following: + + Separation of all PPP-related AVPs, references, etc., including a + portion of the L2TP data header that was specific to the needs of + PPP. The PPP-specific constructs are described in a companion + document. + + Transition from a 16-bit Session ID and Tunnel ID to a 32-bit + Session ID and Control Connection ID, respectively. + + Extension of the Tunnel Authentication mechanism to cover the + entire control message rather than just a portion of certain + messages. + + Details of these changes and a recommendation for transitioning to + L2TPv3 are discussed in Section 4.7. + +1.2. 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]. + + + + + + + +Lau, et al. Standards Track [Page 4] + +RFC 3931 L2TPv3 March 2005 + + +1.3. Terminology + + Attribute Value Pair (AVP) + + The variable-length concatenation of a unique Attribute + (represented by an integer), a length field, and a Value + containing the actual value identified by the attribute. Zero or + more AVPs make up the body of control messages, which are used in + the establishment, maintenance, and teardown of control + connections. This basic construct is sometimes referred to as a + Type-Length-Value (TLV) in some specifications. (See also: + Control Connection, Control Message.) + + Call (Circuit Up) + + The action of transitioning a circuit on an L2TP Access + Concentrator (LAC) to an "up" or "active" state. A call may be + dynamically established through signaling properties (e.g., an + incoming or outgoing call through the Public Switched Telephone + Network (PSTN)) or statically configured (e.g., provisioning a + Virtual Circuit on an interface). A call is defined by its + properties (e.g., type of call, called number, etc.) and its data + traffic. (See also: Circuit, Session, Incoming Call, Outgoing + Call, Outgoing Call Request.) + + Circuit + + A general term identifying any one of a wide range of L2 + connections. A circuit may be virtual in nature (e.g., an ATM + PVC, an IEEE 802 VLAN, or an L2TP session), or it may have direct + correlation to a physical layer (e.g., an RS-232 serial line). + Circuits may be statically configured with a relatively long-lived + uptime, or dynamically established with signaling to govern the + establishment, maintenance, and teardown of the circuit. For the + purposes of this document, a statically configured circuit is + considered to be essentially the same as a very simple, long- + lived, dynamic circuit. (See also: Call, Remote System.) + + Client + + (See Remote System.) + + Control Connection + + An L2TP control connection is a reliable control channel that is + used to establish, maintain, and release individual L2TP sessions + as well as the control connection itself. (See also: Control + Message, Data Channel.) + + + +Lau, et al. Standards Track [Page 5] + +RFC 3931 L2TPv3 March 2005 + + + Control Message + + An L2TP message used by the control connection. (See also: + Control Connection.) + + Data Message + + Message used by the data channel. (a.k.a. Data Packet, See also: + Data Channel.) + + Data Channel + + The channel for L2TP-encapsulated data traffic that passes between + two LCCEs over a Packet-Switched Network (i.e., IP). (See also: + Control Connection, Data Message.) + + Incoming Call + + The action of receiving a call (circuit up event) on an LAC. The + call may have been placed by a remote system (e.g., a phone call + over a PSTN), or it may have been triggered by a local event + (e.g., interesting traffic routed to a virtual interface). An + incoming call that needs to be tunneled (as determined by the LAC) + results in the generation of an L2TP ICRQ message. (See also: + Call, Outgoing Call, Outgoing Call Request.) + + L2TP Access Concentrator (LAC) + + If an L2TP Control Connection Endpoint (LCCE) is being used to + cross-connect an L2TP session directly to a data link, we refer to + it as an L2TP Access Concentrator (LAC). An LCCE may act as both + an L2TP Network Server (LNS) for some sessions and an LAC for + others, so these terms must only be used within the context of a + given set of sessions unless the LCCE is in fact single purpose + for a given topology. (See also: LCCE, LNS.) + + L2TP Control Connection Endpoint (LCCE) + + An L2TP node that exists at either end of an L2TP control + connection. May also be referred to as an LAC or LNS, depending + on whether tunneled frames are processed at the data link (LAC) or + network layer (LNS). (See also: LAC, LNS.) + + L2TP Network Server (LNS) + + If a given L2TP session is terminated at the L2TP node and the + encapsulated network layer (L3) packet processed on a virtual + interface, we refer to this L2TP node as an L2TP Network Server + + + +Lau, et al. Standards Track [Page 6] + +RFC 3931 L2TPv3 March 2005 + + + (LNS). A given LCCE may act as both an LNS for some sessions and + an LAC for others, so these terms must only be used within the + context of a given set of sessions unless the LCCE is in fact + single purpose for a given topology. (See also: LCCE, LAC.) + + Outgoing Call + + The action of placing a call by an LAC, typically in response to + policy directed by the peer in an Outgoing Call Request. (See + also: Call, Incoming Call, Outgoing Call Request.) + + Outgoing Call Request + + A request sent to an LAC to place an outgoing call. The request + contains specific information not known a priori by the LAC (e.g., + a number to dial). (See also: Call, Incoming Call, Outgoing + Call.) + + Packet-Switched Network (PSN) + + A network that uses packet switching technology for data delivery. + For L2TPv3, this layer is principally IP. Other examples include + MPLS, Frame Relay, and ATM. + + Peer + + When used in context with L2TP, Peer refers to the far end of an + L2TP control connection (i.e., the remote LCCE). An LAC's peer + may be either an LNS or another LAC. Similarly, an LNS's peer may + be either an LAC or another LNS. (See also: LAC, LCCE, LNS.) + + Pseudowire (PW) + + An emulated circuit as it traverses a PSN. There is one + Pseudowire per L2TP Session. (See also: Packet-Switched Network, + Session.) + + Pseudowire Type + + The payload type being carried within an L2TP session. Examples + include PPP, Ethernet, and Frame Relay. (See also: Session.) + + Remote System + + An end system or router connected by a circuit to an LAC. + + + + + + +Lau, et al. Standards Track [Page 7] + +RFC 3931 L2TPv3 March 2005 + + + Session + + An L2TP session is the entity that is created between two LCCEs in + order to exchange parameters for and maintain an emulated L2 + connection. Multiple sessions may be associated with a single + Control Connection. + + Zero-Length Body (ZLB) Message + + A control message with only an L2TP header. ZLB messages are used + only to acknowledge messages on the L2TP reliable control + connection. (See also: Control Message.) + +2. Topology + + L2TP operates between two L2TP Control Connection Endpoints (LCCEs), + tunneling traffic across a packet network. There are three + predominant tunneling models in which L2TP operates: LAC-LNS (or vice + versa), LAC-LAC, and LNS-LNS. These models are diagrammed below. + (Dotted lines designate network connections. Solid lines designate + circuit connections.) + + Figure 2.0: L2TP Reference Models + + (a) LAC-LNS Reference Model: On one side, the LAC receives traffic + from an L2 circuit, which it forwards via L2TP across an IP or other + packet-based network. On the other side, an LNS logically terminates + the L2 circuit locally and routes network traffic to the home + network. The action of session establishment is driven by the LAC + (as an incoming call) or the LNS (as an outgoing call). + + +-----+ L2 +-----+ +-----+ + | |------| LAC |.........[ IP ].........| LNS |...[home network] + +-----+ +-----+ +-----+ + remote + system + |<-- emulated service -->| + |<----------- L2 service ------------>| + + (b) LAC-LAC Reference Model: In this model, both LCCEs are LACs. + Each LAC forwards circuit traffic from the remote system to the peer + LAC using L2TP, and vice versa. In its simplest form, an LAC acts as + a simple cross-connect between a circuit to a remote system and an + L2TP session. This model typically involves symmetric establishment; + that is, either side of the connection may initiate a session at any + time (or simultaneously, in which a tie breaking mechanism is + utilized). + + + + +Lau, et al. Standards Track [Page 8] + +RFC 3931 L2TPv3 March 2005 + + + +-----+ L2 +-----+ +-----+ L2 +-----+ + | |------| LAC |........[ IP ]........| LAC |------| | + +-----+ +-----+ +-----+ +-----+ + remote remote + system system + |<- emulated service ->| + |<----------------- L2 service ----------------->| + + (c) LNS-LNS Reference Model: This model has two LNSs as the LCCEs. A + user-level, traffic-generated, or signaled event typically drives + session establishment from one side of the tunnel. For example, a + tunnel generated from a PC by a user, or automatically by customer + premises equipment. + + +-----+ +-----+ + [home network]...| LNS |........[ IP ]........| LNS |...[home network] + +-----+ +-----+ + |<- emulated service ->| + |<---- L2 service ---->| + + Note: In L2TPv2, user-driven tunneling of this type is often referred + to as "voluntary tunneling" [RFC2809]. Further, an LNS acting as + part of a software package on a host is sometimes referred to as an + "LAC Client" [RFC2661]. + +3. Protocol Overview + + L2TP is comprised of two types of messages, control messages and data + messages (sometimes referred to as "control packets" and "data + packets", respectively). Control messages are used in the + establishment, maintenance, and clearing of control connections and + sessions. These messages utilize a reliable control channel within + L2TP to guarantee delivery (see Section 4.2 for details). Data + messages are used to encapsulate the L2 traffic being carried over + the L2TP session. Unlike control messages, data messages are not + retransmitted when packet loss occurs. + + The L2TPv3 control message format defined in this document borrows + largely from L2TPv2. These control messages are used in conjunction + with the associated protocol state machines that govern the dynamic + setup, maintenance, and teardown for L2TP sessions. The data message + format for tunneling data packets may be utilized with or without the + L2TP control channel, either via manual configuration or via other + signaling methods to pre-configure or distribute L2TP session + information. Utilization of the L2TP data message format with other + signaling methods is outside the scope of this document. + + + + + +Lau, et al. Standards Track [Page 9] + +RFC 3931 L2TPv3 March 2005 + + + Figure 3.0: L2TPv3 Structure + + +-------------------+ +-----------------------+ + | Tunneled Frame | | L2TP Control Message | + +-------------------+ +-----------------------+ + | L2TP Data Header | | L2TP Control Header | + +-------------------+ +-----------------------+ + | L2TP Data Channel | | L2TP Control Channel | + | (unreliable) | | (reliable) | + +-------------------+----+-----------------------+ + | Packet-Switched Network (IP, FR, MPLS, etc.) | + +------------------------------------------------+ + + Figure 3.0 depicts the relationship of control messages and data + messages over the L2TP control and data channels, respectively. Data + messages are passed over an unreliable data channel, encapsulated by + an L2TP header, and sent over a Packet-Switched Network (PSN) such as + IP, UDP, Frame Relay, ATM, MPLS, etc. Control messages are sent over + a reliable L2TP control channel, which operates over the same PSN. + + The necessary setup for tunneling a session with L2TP consists of two + steps: (1) Establishing the control connection, and (2) establishing + a session as triggered by an incoming call or outgoing call. An L2TP + session MUST be established before L2TP can begin to forward session + frames. Multiple sessions may be bound to a single control + connection, and multiple control connections may exist between the + same two LCCEs. + +3.1. Control Message Types + + The Message Type AVP (see Section 5.4.1) defines the specific type of + control message being sent. + + This document defines the following control message types (see + Sections 6.1 through 6.15 for details on the construction and use of + each message): + + Control Connection Management + + 0 (reserved) + 1 (SCCRQ) Start-Control-Connection-Request + 2 (SCCRP) Start-Control-Connection-Reply + 3 (SCCCN) Start-Control-Connection-Connected + 4 (StopCCN) Stop-Control-Connection-Notification + 5 (reserved) + 6 (HELLO) Hello + 20 (ACK) Explicit Acknowledgement + + + + +Lau, et al. Standards Track [Page 10] + +RFC 3931 L2TPv3 March 2005 + + + Call Management + + 7 (OCRQ) Outgoing-Call-Request + 8 (OCRP) Outgoing-Call-Reply + 9 (OCCN) Outgoing-Call-Connected + 10 (ICRQ) Incoming-Call-Request + 11 (ICRP) Incoming-Call-Reply + 12 (ICCN) Incoming-Call-Connected + 13 (reserved) + 14 (CDN) Call-Disconnect-Notify + + Error Reporting + + 15 (WEN) WAN-Error-Notify + + Link Status Change Reporting + + 16 (SLI) Set-Link-Info + +3.2. L2TP Header Formats + + This section defines header formats for L2TP control messages and + L2TP data messages. All values are placed into their respective + fields and sent in network order (high-order octets first). + +3.2.1. L2TP Control Message Header + + The L2TP control message header provides information for the reliable + transport of messages that govern the establishment, maintenance, and + teardown of L2TP sessions. By default, control messages are sent + over the underlying media in-band with L2TP data messages. + + The L2TP control message header is formatted as follows: + + Figure 3.2.1: L2TP Control Message Header + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |T|L|x|x|S|x|x|x|x|x|x|x| Ver | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Control Connection ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Ns | Nr | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The T bit MUST be set to 1, indicating that this is a control + message. + + + +Lau, et al. Standards Track [Page 11] + +RFC 3931 L2TPv3 March 2005 + + + The L and S bits MUST be set to 1, indicating that the Length field + and sequence numbers are present. + + 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 Ver field indicates the version of the L2TP control message + header described in this document. On sending, this field MUST be + set to 3 for all messages (unless operating in an environment that + includes L2TPv2 [RFC2661] and/or L2F [RFC2341] as well, see Section + 4.1 for details). + + The Length field indicates the total length of the message in octets, + always calculated from the start of the control message header itself + (beginning with the T bit). + + The Control Connection ID field contains the identifier for the + control connection. L2TP control connections are named by + identifiers that have local significance only. That is, the same + control connection will be given unique Control Connection IDs by + each LCCE from within each endpoint's own Control Connection ID + number space. As such, the Control Connection ID in each message is + that of the intended recipient, not the sender. Non-zero Control + Connection IDs are selected and exchanged as Assigned Control + Connection ID AVPs during the creation of a control connection. + + Ns indicates the sequence number for this control message, beginning + at zero and incrementing by one (modulo 2**16) for each message sent. + See Section 4.2 for more information on using this field. + + Nr indicates the sequence number expected in the next control message + to be received. Thus, Nr is set to the Ns of the last in-order + message received plus one (modulo 2**16). See Section 4.2 for more + information on using this field. + +3.2.2. L2TP Data Message + + In general, an L2TP data message consists of a (1) Session Header, + (2) an optional L2-Specific Sublayer, and (3) the Tunnel Payload, as + depicted below. + + + + + + + + + + +Lau, et al. Standards Track [Page 12] + +RFC 3931 L2TPv3 March 2005 + + + Figure 3.2.2: L2TP Data Message Header + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | L2TP Session Header | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | L2-Specific Sublayer | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Tunnel Payload ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The L2TP Session Header is specific to the encapsulating PSN over + which the L2TP traffic is delivered. The Session Header MUST provide + (1) a method of distinguishing traffic among multiple L2TP data + sessions and (2) a method of distinguishing data messages from + control messages. + + Each type of encapsulating PSN MUST define its own session header, + clearly identifying the format of the header and parameters necessary + to setup the session. Section 4.1 defines two session headers, one + for transport over UDP and one for transport over IP. + + The L2-Specific Sublayer is an intermediary layer between the L2TP + session header and the start of the tunneled frame. It contains + control fields that are used to facilitate the tunneling of each + frame (e.g., sequence numbers or flags). The Default L2-Specific + Sublayer for L2TPv3 is defined in Section 4.6. + + The Data Message Header is followed by the Tunnel Payload, including + any necessary L2 framing as defined in the payload-specific companion + documents. + +3.3. Control Connection Management + + The L2TP control connection handles dynamic establishment, teardown, + and maintenance of the L2TP sessions and of the control connection + itself. The reliable delivery of control messages is described in + Section 4.2. + + This section describes typical control connection establishment and + teardown exchanges. It is important to note that, in the diagrams + that follow, the reliable control message delivery mechanism exists + independently of the L2TP state machine. For instance, Explicit + Acknowledgement (ACK) messages may be sent after any of the control + messages indicated in the exchanges below if an acknowledgment is not + piggybacked on a later control message. + + + + + + +Lau, et al. Standards Track [Page 13] + +RFC 3931 L2TPv3 March 2005 + + + LCCEs are identified during control connection establishment either + by the Host Name AVP, the Router ID AVP, or a combination of the two + (see Section 5.4.3). The identity of a peer LCCE is central to + selecting proper configuration parameters (i.e., Hello interval, + window size, etc.) for a control connection, as well as for + determining how to set up associated sessions within the control + connection, password lookup for control connection authentication, + control connection level tie breaking, etc. + +3.3.1. Control Connection Establishment + + Establishment of the control connection involves an exchange of AVPs + that identifies the peer and its capabilities. + + A three-message exchange is used to establish the control connection. + The following is a typical message exchange: + + LCCE A LCCE B + ------ ------ + SCCRQ -> + <- SCCRP + SCCCN -> + +3.3.2. Control Connection Teardown + + Control connection teardown may be initiated by either LCCE and is + accomplished by sending a single StopCCN control message. As part of + the reliable control message delivery mechanism, the recipient of a + StopCCN MUST send an ACK message to acknowledge receipt of the + message and maintain enough control connection state to properly + accept StopCCN retransmissions over at least a full retransmission + cycle (in case the ACK message is lost). The recommended time for a + full retransmission cycle is at least 31 seconds (see Section 4.2). + The following is an example of a typical control message exchange: + + LCCE A LCCE B + ------ ------ + StopCCN -> + (Clean up) + + (Wait) + (Clean up) + + An implementation may shut down an entire control connection and all + sessions associated with the control connection by sending the + StopCCN. Thus, it is not necessary to clear each session + individually when tearing down the whole control connection. + + + + +Lau, et al. Standards Track [Page 14] + +RFC 3931 L2TPv3 March 2005 + + +3.4. Session Management + + After successful control connection establishment, individual + sessions may be created. Each session corresponds to a single data + stream between the two LCCEs. This section describes the typical + call establishment and teardown exchanges. + +3.4.1. Session Establishment for an Incoming Call + + A three-message exchange is used to establish the session. The + following is a typical sequence of events: + + LCCE A LCCE B + ------ ------ + (Call + Detected) + + ICRQ -> + <- ICRP + (Call + Accepted) + + ICCN -> + +3.4.2. Session Establishment for an Outgoing Call + + A three-message exchange is used to set up the session. The + following is a typical sequence of events: + + LCCE A LCCE B + ------ ------ + <- OCRQ + OCRP -> + + (Perform + Call + Operation) + + OCCN -> + + (Call Operation + Completed + Successfully) + + + + + + + + +Lau, et al. Standards Track [Page 15] + +RFC 3931 L2TPv3 March 2005 + + +3.4.3. Session Teardown + + Session teardown may be initiated by either the LAC or LNS and is + accomplished by sending a CDN control message. After the last + session is cleared, the control connection MAY be torn down as well + (and typically is). The following is an example of a typical control + message exchange: + + LCCE A LCCE B + ------ ------ + CDN -> + (Clean up) + + (Clean up) + +4. Protocol Operation + +4.1. L2TP Over Specific Packet-Switched Networks (PSNs) + + L2TP may operate over a variety of PSNs. There are two modes + described for operation over IP, L2TP directly over IP (see Section + 4.1.1) and L2TP over UDP (see Section 4.1.2). L2TPv3 implementations + MUST support L2TP over IP and SHOULD support L2TP over UDP for better + NAT and firewall traversal, and for easier migration from L2TPv2. + + L2TP over other PSNs may be defined, but the specifics are outside + the scope of this document. Examples of L2TPv2 over other PSNs + include [RFC3070] and [RFC3355]. + + The following field definitions are defined for use in all L2TP + Session Header encapsulations. + + Session ID + + A 32-bit field containing a non-zero identifier for a session. + L2TP sessions are named by identifiers that have local + significance only. That is, the same logical session will be + given different Session IDs by each end of the control connection + for the life of the session. When the L2TP control connection is + used for session establishment, Session IDs are selected and + exchanged as Local Session ID AVPs during the creation of a + session. The Session ID alone provides the necessary context for + all further packet processing, including the presence, size, and + value of the Cookie, the type of L2-Specific Sublayer, and the + type of payload being tunneled. + + + + + + +Lau, et al. Standards Track [Page 16] + +RFC 3931 L2TPv3 March 2005 + + + Cookie + + The optional Cookie field contains a variable-length value + (maximum 64 bits) used to check the association of a received data + message with the session identified by the Session ID. The Cookie + MUST be set to the configured or signaled random value for this + session. The Cookie provides an additional level of guarantee + that a data message has been directed to the proper session by the + Session ID. A well-chosen Cookie may prevent inadvertent + misdirection of stray packets with recently reused Session IDs, + Session IDs subject to packet corruption, etc. The Cookie may + also provide protection against some specific malicious packet + insertion attacks, as described in Section 8.2. + + When the L2TP control connection is used for session + establishment, random Cookie values are selected and exchanged as + Assigned Cookie AVPs during session creation. + +4.1.1. L2TPv3 over IP + + L2TPv3 over IP (both versions) utilizes the IANA-assigned IP protocol + ID 115. + +4.1.1.1. L2TPv3 Session Header Over IP + + Unlike L2TP over UDP, the L2TPv3 session header over IP is free of + any restrictions imposed by coexistence with L2TPv2 and L2F. As + such, the header format has been designed to optimize packet + processing. The following session header format is utilized when + operating L2TPv3 over IP: + + Figure 4.1.1.1: L2TPv3 Session Header Over IP + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Session ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Cookie (optional, maximum 64 bits)... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The Session ID and Cookie fields are as defined in Section 4.1. The + Session ID of zero is reserved for use by L2TP control messages (see + Section 4.1.1.2). + + + + + +Lau, et al. Standards Track [Page 17] + +RFC 3931 L2TPv3 March 2005 + + +4.1.1.2. L2TP Control and Data Traffic over IP + + Unlike L2TP over UDP, which uses the T bit to distinguish between + L2TP control and data packets, L2TP over IP uses the reserved Session + ID of zero (0) when sending control messages. It is presumed that + checking for the zero Session ID is more efficient -- both in header + size for data packets and in processing speed for distinguishing + between control and data messages -- than checking a single bit. + + The entire control message header over IP, including the zero session + ID, appears as follows: + + Figure 4.1.1.2: L2TPv3 Control Message Header Over IP + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | (32 bits of zeros) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |T|L|x|x|S|x|x|x|x|x|x|x| Ver | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Control Connection ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Ns | Nr | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Named fields are as defined in Section 3.2.1. Note that the Length + field is still calculated from the beginning of the control message + header, beginning with the T bit. It does NOT include the "(32 bits + of zeros)" depicted above. + + When operating directly over IP, L2TP packets lose the ability to + take advantage of the UDP checksum as a simple packet integrity + check, which is of particular concern for L2TP control messages. + Control Message Authentication (see Section 4.3), even with an empty + password field, provides for a sufficient packet integrity check and + SHOULD always be enabled. + +4.1.2. L2TP over UDP + + L2TPv3 over UDP must consider other L2 tunneling protocols that may + be operating in the same environment, including L2TPv2 [RFC2661] and + L2F [RFC2341]. + + While there are efficiencies gained by running L2TP directly over IP, + there are possible side effects as well. For instance, L2TP over IP + is not as NAT-friendly as L2TP over UDP. + + + + +Lau, et al. Standards Track [Page 18] + +RFC 3931 L2TPv3 March 2005 + + +4.1.2.1. L2TP Session Header Over UDP + + The following session header format is utilized when operating L2TPv3 + over UDP: + + Figure 4.1.2.1: L2TPv3 Session Header over UDP + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |T|x|x|x|x|x|x|x|x|x|x|x| Ver | Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Session ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Cookie (optional, maximum 64 bits)... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The T bit MUST be set to 0, indicating that this is a data message. + + The x bits and Reserved field are reserved for future extensions. + All reserved values MUST be set to 0 on outgoing messages and ignored + on incoming messages. + + The Ver field MUST be set to 3, indicating an L2TPv3 message. + + Note that the initial bits 1, 4, 6, and 7 have meaning in L2TPv2 + [RFC2661], and are deprecated and marked as reserved in L2TPv3. + Thus, for UDP mode on a system that supports both versions of L2TP, + it is important that the Ver field be inspected first to determine + the Version of the header before acting upon any of these bits. + + The Session ID and Cookie fields are as defined in Section 4.1. + +4.1.2.2. UDP Port Selection + + The method for UDP Port Selection defined in this section is + identical to that defined for L2TPv2 [RFC2661]. + + When negotiating a control connection over UDP, control messages MUST + be sent as UDP datagrams using the registered UDP port 1701 + [RFC1700]. The initiator of an L2TP control connection picks an + available source UDP port (which may or may not be 1701) and sends to + the desired destination address at port 1701. The recipient picks a + free port on its own system (which may or may not be 1701) and sends + its reply to the initiator's UDP port and address, setting its own + source port to the free port it found. + + + +Lau, et al. Standards Track [Page 19] + +RFC 3931 L2TPv3 March 2005 + + + Any subsequent traffic associated with this control connection + (either control traffic or data traffic from a session established + through this control connection) must use these same UDP ports. + + It has been suggested that having the recipient choose an arbitrary + source port (as opposed to using the destination port in the packet + initiating the control connection, i.e., 1701) may make it more + difficult for L2TP to traverse some NAT devices. Implementations + should consider the potential implication of this capability before + choosing an arbitrary source port. A NAT device that can pass TFTP + traffic with variant UDP ports should be able to pass L2TP UDP + traffic since both protocols employ similar policies with regard to + UDP port selection. + +4.1.2.3. UDP Checksum + + The tunneled frames that L2TP carry often have their own checksums or + integrity checks, rendering the UDP checksum redundant for much of + the L2TP data message contents. Thus, UDP checksums MAY be disabled + in order to reduce the associated packet processing burden at the + L2TP endpoints. + + The L2TP header itself does not have its own checksum or integrity + check. However, use of the L2TP Session ID and Cookie pair guards + against accepting an L2TP data message if corruption of the Session + ID or associated Cookie has occurred. When the L2-Specific Sublayer + is present in the L2TP header, there is no built-in integrity check + for the information contained therein if UDP checksums or some other + integrity check is not employed. IPsec (see Section 4.1.3) may be + used for strong integrity protection of the entire contents of L2TP + data messages. + + UDP checksums MUST be enabled for L2TP control messages. + +4.1.3. L2TP and IPsec + + The L2TP data channel does not provide cryptographic security of any + kind. If the L2TP data channel operates over a public or untrusted + IP network where privacy of the L2TP data is of concern or + sophisticated attacks against L2TP are expected to occur, IPsec + [RFC2401] MUST be made available to secure the L2TP traffic. + + Either L2TP over UDP or L2TP over IP may be secured with IPsec. + [RFC3193] defines the recommended method for securing L2TPv2. L2TPv3 + possesses identical characteristics to IPsec as L2TPv2 when running + over UDP and implementations MUST follow the same recommendation. + When operating over IP directly, [RFC3193] still applies, though + references to UDP source and destination ports (in particular, those + + + +Lau, et al. Standards Track [Page 20] + +RFC 3931 L2TPv3 March 2005 + + + in Section 4, "IPsec Filtering details when protecting L2TP") may be + ignored. Instead, the selectors used to identify L2TPv3 traffic are + simply the source and destination IP addresses for the tunnel + endpoints together with the L2TPv3 IP protocol type, 115. + + In addition to IP transport security, IPsec defines a mode of + operation that allows tunneling of IP packets. The packet-level + encryption and authentication provided by IPsec tunnel mode and that + provided by L2TP secured with IPsec provide an equivalent level of + security for these requirements. + + IPsec also defines access control features that are required of a + compliant IPsec implementation. These features allow filtering of + packets based upon network and transport layer characteristics such + as IP address, ports, etc. In the L2TP tunneling model, analogous + filtering may be performed at the network layer above L2TP. These + network layer access control features may be handled at an LCCE via + vendor-specific authorization features, or at the network layer + itself by using IPsec transport mode end-to-end between the + communicating hosts. The requirements for access control mechanisms + are not a part of the L2TP specification, and as such, are outside + the scope of this document. + + Protecting the L2TP packet stream with IPsec does, in turn, also + protect the data within the tunneled session packets while + transported from one LCCE to the other. Such protection must not be + considered a substitution for end-to-end security between + communicating hosts or applications. + +4.1.4. IP Fragmentation Issues + + Fragmentation and reassembly in network equipment generally require + significantly greater resources than sending or receiving a packet as + a single unit. As such, fragmentation and reassembly should be + avoided whenever possible. Ideal solutions for avoiding + fragmentation include proper configuration and management of MTU + sizes among the Remote System, the LCCE, and the IP network, as well + as adaptive measures that operate with the originating host (e.g., + [RFC1191], [RFC1981]) to reduce the packet sizes at the source. + + An LCCE MAY fragment a packet before encapsulating it in L2TP. For + example, if an IPv4 packet arrives at an LCCE from a Remote System + that, after encapsulation with its associated framing, L2TP, and IP, + does not fit in the available path MTU towards its LCCE peer, the + local LCCE may perform IPv4 fragmentation on the packet before tunnel + encapsulation. This creates two (or more) L2TP packets, each + + + + + +Lau, et al. Standards Track [Page 21] + +RFC 3931 L2TPv3 March 2005 + + + carrying an IPv4 fragment with its associated framing. This + ultimately has the effect of placing the burden of fragmentation on + the LCCE, while reassembly occurs on the IPv4 destination host. + + If an IPv6 packet arrives at an LCCE from a Remote System that, after + encapsulation with associated framing, L2TP and IP, does not fit in + the available path MTU towards its L2TP peer, the Generic Packet + Tunneling specification [RFC2473], Section 7.1 SHOULD be followed. + In this case, the LCCE should either send an ICMP Packet Too Big + message to the data source, or fragment the resultant L2TP/IP packet + (for reassembly by the L2TP peer). + + If the amount of traffic requiring fragmentation and reassembly is + rather light, or there are sufficiently optimized mechanisms at the + tunnel endpoints, fragmentation of the L2TP/IP packet may be + sufficient for accommodating mismatched MTUs that cannot be managed + by more efficient means. This method effectively emulates a larger + MTU between tunnel endpoints and should work for any type of L2- + encapsulated packet. Note that IPv6 does not support "in-flight" + fragmentation of data packets. Thus, unlike IPv4, the MTU of the + path towards an L2TP peer must be known in advance (or the last + resort IPv6 minimum MTU of 1280 bytes utilized) so that IPv6 + fragmentation may occur at the LCCE. + + In summary, attempting to control the source MTU by communicating + with the originating host, forcing that an MTU be sufficiently large + on the path between LCCE peers to tunnel a frame from any other + interface without fragmentation, fragmenting IP packets before + encapsulation with L2TP/IP, or fragmenting the resultant L2TP/IP + packet between the tunnel endpoints, are all valid methods for + managing MTU mismatches. Some are clearly better than others + depending on the given deployment. For example, a passive monitoring + application using L2TP would certainly not wish to have ICMP messages + sent to a traffic source. Further, if the links connecting a set of + LCCEs have a very large MTU (e.g., SDH/SONET) and it is known that + the MTU of all links being tunneled by L2TP have smaller MTUs (e.g., + 1500 bytes), then any IP fragmentation and reassembly enabled on the + participating LCCEs would never be utilized. An implementation MUST + implement at least one of the methods described in this section for + managing mismatched MTUs, based on careful consideration of how the + final product will be deployed. + + L2TP-specific fragmentation and reassembly methods, which may or may + not depend on the characteristics of the type of link being tunneled + (e.g., judicious packing of ATM cells), may be defined as well, but + these methods are outside the scope of this document. + + + + + +Lau, et al. Standards Track [Page 22] + +RFC 3931 L2TPv3 March 2005 + + +4.2. Reliable Delivery of Control Messages + + L2TP provides a lower level reliable delivery service for all control + messages. The Nr and Ns fields of the control message header (see + Section 3.2.1) belong to this delivery mechanism. The upper level + functions of L2TP are not concerned with retransmission or ordering + of control messages. The reliable control messaging mechanism is a + sliding window mechanism that provides control message retransmission + and congestion control. Each peer maintains separate sequence number + state for each control connection. + + The message sequence number, Ns, 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 + 65536. 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 + 32767 values, inclusive. For example, if the last received sequence + number was 15, then messages with sequence numbers 0 through 15, as + well as 32784 through 65535, would be considered less than or equal. + Such a message would be considered a duplicate of a message already + received and ignored from processing. However, in order to ensure + that all messages are acknowledged properly (particularly in the case + of a lost ACK message), receipt of duplicate messages MUST be + acknowledged by the reliable delivery mechanism. This acknowledgment + may either piggybacked on a message in queue or sent explicitly via + an ACK message. + + All control messages take up one slot in the control message sequence + number space, except the ACK message. Thus, Ns is not incremented + after an ACK message is sent. + + The last received message number, Nr, is used to acknowledge messages + received by an L2TP peer. It contains the sequence number of the + message the peer expects to receive next (e.g., the last Ns of a + non-ACK message received plus 1, modulo 65536). While the Nr in a + received ACK message is used to flush messages from the local + retransmit queue (see below), the Nr of the next message sent is not + updated by the Ns of the ACK message. Nr SHOULD be sanity-checked + before flushing the retransmit queue. For instance, if the Nr + received in a control message is greater than the last Ns sent plus 1 + modulo 65536, the control message is clearly invalid. + + The reliable delivery mechanism at a receiving peer is responsible + for making sure that control messages are delivered in order and + without duplication to the upper level. Messages arriving out-of- + order may be queued for in-order delivery when the missing messages + + + + +Lau, et al. Standards Track [Page 23] + +RFC 3931 L2TPv3 March 2005 + + + are received. Alternatively, they may be discarded, thus requiring a + retransmission by the peer. When dropping out-of-order control + packets, Nr MAY be updated before the packet is discarded. + + Each control connection maintains a queue of control messages to be + transmitted to its peer. The message at the front of the queue is + sent with a given Ns value and is held until a control message + arrives from the peer in which the Nr field indicates receipt of this + message. After a period of time (a recommended default is 1 second + but SHOULD be configurable) passes without acknowledgment, the + message is retransmitted. The retransmitted message contains the + same Ns value, but the Nr value MUST be updated with the sequence + number of the next expected message. + + Each subsequent retransmission of a message MUST employ an + exponential backoff interval. Thus, if the first retransmission + occurred after 1 second, the next retransmission should occur after 2 + seconds has elapsed, then 4 seconds, etc. An implementation MAY + place a cap upon the maximum interval between retransmissions. This + cap SHOULD be no less than 8 seconds per retransmission. If no peer + response is detected after several retransmissions (a recommended + default is 10, but MUST be configurable), the control connection and + all associated sessions MUST be cleared. As it is the first message + to establish a control connection, the SCCRQ MAY employ a different + retransmission maximum than other control messages in order to help + facilitate failover to alternate LCCEs in a timely fashion. + + When a control connection is being shut down for reasons other than + loss of connectivity, the state and reliable delivery mechanisms MUST + be maintained and operated for the full retransmission interval after + the final message StopCCN message has been sent (e.g., 1 + 2 + 4 + 8 + + 8... seconds), or until the StopCCN message itself has been + acknowledged. + + A sliding window mechanism is used for control message transmission + and retransmission. Consider two peers, A and B. Suppose A + specifies a Receive Window Size AVP with a value of N in the SCCRQ or + SCCRP message. B is now allowed to have a maximum of N outstanding + (i.e., unacknowledged) control messages. Once N messages have been + sent, B must wait for an acknowledgment from A that advances the + window before sending new control messages. An implementation may + advertise a non-zero receive window as small or as large as it + wishes, depending on its own ability to process incoming messages + before sending an acknowledgement. Each peer MUST limit the number + of unacknowledged messages it will send before receiving an + acknowledgement by this Receive Window Size. The actual internal + + + + + +Lau, et al. Standards Track [Page 24] + +RFC 3931 L2TPv3 March 2005 + + + unacknowledged message send-queue depth may be further limited by + local resource allocation or by dynamic slow-start and congestion- + avoidance mechanisms. + + When retransmitting control messages, a slow start and congestion + avoidance window adjustment procedure SHOULD be utilized. A + recommended procedure is described in Appendix A. A peer MAY drop + messages, but MUST NOT actively delay acknowledgment of messages as a + technique for flow control of control messages. Appendix B contains + examples of control message transmission, acknowledgment, and + retransmission. + +4.3. Control Message Authentication + + L2TP incorporates an optional authentication and integrity check for + all control messages. This mechanism consists of a computed one-way + hash over the header and body of the L2TP control message, a pre- + configured shared secret, and a local and remote nonce (random value) + exchanged via the Control Message Authentication Nonce AVP. This + per-message authentication and integrity check is designed to perform + a mutual authentication between L2TP nodes, perform integrity + checking of all control messages, and guard against control message + spoofing and replay attacks that would otherwise be trivial to mount. + + At least one shared secret (password) MUST exist between + communicating L2TP nodes to enable Control Message Authentication. + See Section 5.4.3 for details on calculation of the Message Digest + and construction of the Control Message Authentication Nonce and + Message Digest AVPs. + + L2TPv3 Control Message Authentication is similar to L2TPv2 [RFC2661] + Tunnel Authentication in its use of a shared secret and one-way hash + calculation. The principal difference is that, instead of computing + the hash over selected contents of a received control message (e.g., + the Challenge AVP and Message Type) as in L2TPv2, the entire message + is used in the hash in L2TPv3. In addition, instead of including the + hash digest in just the SCCRP and SCCCN messages, it is now included + in all L2TP messages. + + The Control Message Authentication mechanism is optional, and may be + disabled if both peers agree. For example, if IPsec is already being + used for security and integrity checking between the LCCEs, the + function of the L2TP mechanism becomes redundant and may be disabled. + + Presence of the Control Message Authentication Nonce AVP in an SCCRQ + or SCCRP message serves as indication to a peer that Control Message + Authentication is enabled. If an SCCRQ or SCCRP contains a Control + Message Authentication Nonce AVP, the receiver of the message MUST + + + +Lau, et al. Standards Track [Page 25] + +RFC 3931 L2TPv3 March 2005 + + + respond with a Message Digest AVP in all subsequent messages sent. + Control Message Authentication is always bidirectional; either both + sides participate in authentication, or neither does. + + If Control Message Authentication is disabled, the Message Digest AVP + still MAY be sent as an integrity check of the message. The + integrity check is calculated as in Section 5.4.3, with an empty + zero-length shared secret, local nonce, and remote nonce. If an + invalid Message Digest is received, it should be assumed that the + message has been corrupted in transit and the message dropped + accordingly. + + Implementations MAY rate-limit control messages, particularly SCCRQ + messages, upon receipt for performance reasons or for protection + against denial of service attacks. + +4.4. Keepalive (Hello) + + L2TP employs a keepalive mechanism to detect loss of connectivity + between a pair of LCCEs. This is accomplished by injecting Hello + control messages (see Section 6.5) after a period of time has elapsed + since the last data message or control message was received on an + L2TP session or control connection, respectively. As with any other + control message, if the Hello message is not reliably delivered, the + sending LCCE declares that the control connection is down and resets + its state for the control connection. This behavior ensures that a + connectivity failure between the LCCEs is detected independently by + each end of a control connection. + + Since the control channel is operated in-band with data traffic over + the PSN, this single mechanism can be used to infer basic data + connectivity between a pair of LCCEs for all sessions associated with + the control connection. + + Periodic keepalive for the control connection MUST be implemented by + sending a Hello if a period of time (a recommended default is 60 + seconds, but MUST be configurable) has passed without receiving any + message (data or control) from the peer. An LCCE sending Hello + messages across multiple control connections between the same LCCE + endpoints MUST employ a jittered timer mechanism to prevent grouping + of Hello messages. + +4.5. Forwarding Session Data Frames + + Once session establishment is complete, circuit frames are received + at an LCCE, encapsulated in L2TP (with appropriate attention to + framing, as described in documents for the particular pseudowire + type), and forwarded over the appropriate session. For every + + + +Lau, et al. Standards Track [Page 26] + +RFC 3931 L2TPv3 March 2005 + + + outgoing data message, the sender places the identifier specified in + the Local Session ID AVP (received from peer during session + establishment) in the Session ID field of the L2TP data header. In + this manner, session frames are multiplexed and demultiplexed between + a given pair of LCCEs. Multiple control connections may exist + between a given pair of LCCEs, and multiple sessions may be + associated with a given control connection. + + The peer LCCE receiving the L2TP data packet identifies the session + with which the packet is associated by the Session ID in the data + packet's header. The LCCE then checks the Cookie field in the data + packet against the Cookie value received in the Assigned Cookie AVP + during session establishment. It is important for implementers to + note that the Cookie field check occurs after looking up the session + context by the Session ID, and as such, consists merely of a value + match of the Cookie field and that stored in the retrieved context. + There is no need to perform a lookup across the Session ID and Cookie + as a single value. Any received data packets that contain invalid + Session IDs or associated Cookie values MUST be dropped. Finally, + the LCCE either forwards the network packet within the tunneled frame + (e.g., as an LNS) or switches the frame to a circuit (e.g., as an + LAC). + +4.6. Default L2-Specific Sublayer + + This document defines a Default L2-Specific Sublayer format (see + Section 3.2.2) that a pseudowire may use for features such as + sequencing support, L2 interworking, OAM, or other per-data-packet + operations. The Default L2-Specific Sublayer SHOULD be used by a + given PW type to support these features if it is adequate, and its + presence is requested by a peer during session negotiation. + Alternative sublayers MAY be defined (e.g., an encapsulation with a + larger Sequence Number field or timing information) and identified + for use via the L2-Specific Sublayer Type AVP. + + Figure 4.6: Default L2-Specific Sublayer 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |x|S|x|x|x|x|x|x| Sequence Number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The S (Sequence) bit is set to 1 when the Sequence Number contains a + valid number for this sequenced frame. If the S bit is set to zero, + the Sequence Number contents are undefined and MUST be ignored by the + receiver. + + + + +Lau, et al. Standards Track [Page 27] + +RFC 3931 L2TPv3 March 2005 + + + The Sequence Number field contains a free-running counter of 2^24 + sequence numbers. If the number in this field is valid, the S bit + MUST be set to 1. The Sequence Number begins at zero, which is a + valid sequence number. (In this way, implementations inserting + sequence numbers do not have to "skip" zero when incrementing.) 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^23-1) + values, inclusive. + +4.6.1. Sequencing Data Packets + + The Sequence Number field may be used to detect lost, duplicate, or + out-of-order packets within a given session. + + When L2 frames are carried over an L2TP-over-IP or L2TP-over-UDP/IP + data channel, this part of the link has the characteristic of being + able to reorder, duplicate, or silently drop packets. Reordering may + break some non-IP protocols or L2 control traffic being carried by + the link. Silent dropping or duplication of packets may break + protocols that assume per-packet indications of error, such as TCP + header compression. While a common mechanism for packet sequence + detection is provided, the sequence dependency characteristics of + individual protocols are outside the scope of this document. + + If any protocol being transported by over L2TP data channels cannot + tolerate misordering of data packets, packet duplication, or silent + packet loss, sequencing may be enabled on some or all packets by + using the S bit and Sequence Number field defined in the Default L2- + Specific Sublayer (see Section 4.6). For a given L2TP session, each + LCCE is responsible for communicating to its peer the level of + sequencing support that it requires of data packets that it receives. + Mechanisms to advertise this information during session negotiation + are provided (see Data Sequencing AVP in Section 5.4.4). + + When determining whether a packet is in or out of sequence, an + implementation SHOULD utilize a method that is resilient to temporary + dropouts in connectivity coupled with high per-session packet rates. + The recommended method is outlined in Appendix C. + +4.7. L2TPv2/v3 Interoperability and Migration + + L2TPv2 and L2TPv3 environments should be able to coexist while a + migration to L2TPv3 is made. Migration issues are discussed for each + media type in this section. Most issues apply only to + implementations that require both L2TPv2 and L2TPv3 operation. + + + + + +Lau, et al. Standards Track [Page 28] + +RFC 3931 L2TPv3 March 2005 + + + However, even L2TPv3-only implementations must at least be mindful of + these issues in order to interoperate with implementations that + support both versions. + +4.7.1. L2TPv3 over IP + + L2TPv3 implementations running strictly over IP with no desire to + interoperate with L2TPv2 implementations may safely disregard most + migration issues from L2TPv2. All control messages and data messages + are sent as described in this document, without normative reference + to RFC 2661. + + If one wishes to tunnel PPP over L2TPv3, and fallback to L2TPv2 only + if it is not available, then L2TPv3 over UDP with automatic fallback + (see Section 4.7.3) MUST be used. There is no deterministic method + for automatic fallback from L2TPv3 over IP to either L2TPv2 or L2TPv3 + over UDP. One could infer whether L2TPv3 over IP is supported by + sending an SCCRQ and waiting for a response, but this could be + problematic during periods of packet loss between L2TP nodes. + +4.7.2. L2TPv3 over UDP + + The format of the L2TPv3 over UDP header is defined in Section + 4.1.2.1. + + When operating over UDP, L2TPv3 uses the same port (1701) as L2TPv2 + and shares the first two octets of header format with L2TPv2. The + Ver field is used to distinguish L2TPv2 packets from L2TPv3 packets. + If an implementation is capable of operating in L2TPv2 or L2TPv3 + modes, it is possible to automatically detect whether a peer can + support L2TPv2 or L2TPv3 and operate accordingly. The details of + this fallback capability is defined in the following section. + +4.7.3. Automatic L2TPv2 Fallback + + When running over UDP, an implementation may detect whether a peer is + L2TPv3-capable by sending a special SCCRQ that is properly formatted + for both L2TPv2 and L2TPv3. This is accomplished by sending an SCCRQ + with its Ver field set to 2 (for L2TPv2), and ensuring that any + L2TPv3-specific AVPs (i.e., AVPs present within this document and not + defined within RFC 2661) in the message are sent with each M bit set + to 0, and that all L2TPv2 AVPs are present as they would be for + L2TPv2. This is done so that L2TPv3 AVPs will be ignored by an + L2TPv2-only implementation. Note that, in both L2TPv2 and L2TPv3, + the value contained in the space of the control message header + utilized by the 32-bit Control Connection ID in L2TPv3, and the 16- + bit Tunnel ID and + + + + +Lau, et al. Standards Track [Page 29] + +RFC 3931 L2TPv3 March 2005 + + + 16-bit Session ID in L2TPv2, are always 0 for an SCCRQ. This + effectively hides the fact that there are a pair of 16-bit fields in + L2TPv2, and a single 32-bit field in L2TPv3. + + If the peer implementation is L2TPv3-capable, a control message with + the Ver field set to 3 and an L2TPv3 header and message format will + be sent in response to the SCCRQ. Operation may then continue as + L2TPv3. If a message is received with the Ver field set to 2, it + must be assumed that the peer implementation is L2TPv2-only, thus + enabling fallback to L2TPv2 mode to safely occur. + + Note Well: The L2TPv2/v3 auto-detection mode requires that all L2TPv3 + implementations over UDP be liberal in accepting an SCCRQ control + message with the Ver field set to 2 or 3 and the presence of L2TPv2- + specific AVPs. An L2TPv3-only implementation MUST ignore all L2TPv2 + AVPs (e.g., those defined in RFC 2661 and not in this document) + within an SCCRQ with the Ver field set to 2 (even if the M bit is set + on the L2TPv2-specific AVPs). + +5. Control Message Attribute Value Pairs + + To maximize extensibility while permitting interoperability, a + uniform method for encoding message types is used throughout L2TP. + This encoding will be termed AVP (Attribute Value Pair) for the + remainder of this document. + +5.1. AVP Format + + Each AVP is encoded as follows: + + Figure 5.1: AVP 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |M|H| rsvd | Length | Vendor ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Attribute Type | Attribute Value ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + (until Length is reached) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The first six bits comprise a bit mask that describes the general + attributes of the AVP. Two bits are defined in this document; the + remaining bits are reserved for future extensions. Reserved bits + MUST be set to 0 when sent and ignored upon receipt. + + + + + +Lau, et al. Standards Track [Page 30] + +RFC 3931 L2TPv3 March 2005 + + + Mandatory (M) bit: Controls the behavior required of an + implementation that receives an unrecognized AVP. The M bit of a + given AVP MUST only be inspected and acted upon if the AVP is + unrecognized (see Section 5.2). + + Hidden (H) bit: Identifies the hiding of data in the Attribute Value + field of an AVP. This capability can be used to avoid the passing of + sensitive data, such as user passwords, as cleartext in an AVP. + Section 5.3 describes the procedure for performing AVP hiding. + + Length: Contains the number of octets (including the Overall Length + and bit mask fields) contained in this AVP. The Length may be + calculated as 6 + the length of the Attribute Value field in octets. + + The field itself is 10 bits, permitting a maximum of 1023 octets of + data in a single AVP. The minimum Length of an AVP is 6. If the + Length is 6, then the Attribute Value field is absent. + + Vendor ID: The IANA-assigned "SMI Network Management Private + Enterprise Codes" [RFC1700] value. The value 0, corresponding to + IETF-adopted attribute values, is used for all AVPs defined within + this document. Any vendor wishing to implement its own L2TP + extensions can use its own Vendor ID along with private Attribute + values, guaranteeing that they will not collide with any other + vendor's extensions or future IETF extensions. Note that there are + 16 bits allocated for the Vendor ID, thus limiting this feature to + the first 65,535 enterprises. + + Attribute Type: A 2-octet value with a unique interpretation across + all AVPs defined under a given Vendor ID. + + Attribute Value: This is the actual value as indicated by the Vendor + ID and Attribute Type. It follows immediately after the Attribute + Type field and runs for the remaining octets indicated in the Length + (i.e., Length minus 6 octets of header). This field is absent if the + Length is 6. + + In the event that the 16-bit Vendor ID space is exhausted, vendor- + specific AVPs with a 32-bit Vendor ID MUST be encapsulated in the + following manner: + + + + + + + + + + + +Lau, et al. Standards Track [Page 31] + +RFC 3931 L2TPv3 March 2005 + + + Figure 5.2: Extended Vendor ID AVP 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |M|H| rsvd | Length | 0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 58 | 32-bit Vendor ID ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Attribute Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Attribute Value ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + (until Length is reached) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + This AVP encodes a vendor-specific AVP with a 32-bit Vendor ID space + within the Attribute Value field. Multiple AVPs of this type may + exist in any message. The 16-bit Vendor ID MUST be 0, indicating + that this is an IETF-defined AVP, and the Attribute Type MUST be 58, + indicating that what follows is a vendor-specific AVP with a 32-bit + Vendor ID code. 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 of the AVP is 12 + plus the length of the Attribute Value. + +5.2. Mandatory AVPs and Setting the M Bit + + If the M bit is set on an AVP that is unrecognized by its recipient, + the session or control connection associated with the control message + containing the AVP MUST be shut down. If the control message + containing the unrecognized AVP is associated with a session (e.g., + an ICRQ, ICRP, ICCN, SLI, etc.), then the session MUST be issued a + CDN with a Result Code of 2 and Error Code of 8 (as defined in + Section 5.4.2) and shut down. If the control message containing the + unrecognized AVP is associated with establishment or maintenance of a + Control Connection (e.g., SCCRQ, SCCRP, SCCCN, Hello), then the + associated Control Connection MUST be issued a StopCCN with Result + Code of 2 and Error Code of 8 (as defined in Section 5.4.2) and shut + down. If the M bit is not set on an unrecognized AVP, the AVP MUST + be ignored when received, processing the control message as if the + AVP were not present. + + Receipt of an unrecognized AVP that has the M bit set is catastrophic + to the session or control connection with which it is associated. + Thus, the M bit should only be set for AVPs that are deemed crucial + to proper operation of the session or control connection by the + sender. AVPs that are considered crucial by the sender may vary by + application and configured options. In no case shall a receiver of + + + +Lau, et al. Standards Track [Page 32] + +RFC 3931 L2TPv3 March 2005 + + + an AVP "validate" if the M bit is set on a recognized AVP. If the + AVP is recognized (as all AVPs defined in this document MUST be for a + compliant L2TPv3 specification), then by definition, the M bit is of + no consequence. + + The sender of an AVP is free to set its M bit to 1 or 0 based on + whether the configured application strictly requires the value + contained in the AVP to be recognized or not. For example, + "Automatic L2TPv2 Fallback" in Section 4.7.3 requires the setting of + the M bit on all new L2TPv3 AVPs to zero if fallback to L2TPv2 is + supported and desired, and 1 if not. + + The M bit is useful as extra assurance for support of critical AVP + extensions. However, more explicit methods may be available to + determine support for a given feature rather than using the M bit + alone. For example, if a new AVP is defined in a message for which + there is always a message reply (i.e., an ICRQ, ICRP, SCCRQ, or SCCRP + message), rather than simply sending an AVP in the message with the M + bit set, availability of the extension may be identified by sending + an AVP in the request message and expecting a corresponding AVP in a + reply message. This more explicit method, when possible, is + preferred. + + The M bit also plays a role in determining whether or not a malformed + or out-of-range value within an AVP should be ignored or should + result in termination of a session or control connection (see Section + 7.1 for more details). + +5.3. Hiding of AVP Attribute Values + + The H bit in the header of each AVP provides a mechanism to indicate + to the receiving peer whether the contents of the AVP are hidden or + present in cleartext. This feature can be used to hide sensitive + control message data such as user passwords, IDs, or other vital + information. + + The H bit MUST only be set if (1) a shared secret exists between the + LCCEs and (2) Control Message Authentication is enabled (see Section + 4.3). If the H bit is set in any AVP(s) in a given control message, + at least one Random Vector AVP must also be present in the message + and MUST precede the first AVP having an H bit of 1. + + + + + + + + + + +Lau, et al. Standards Track [Page 33] + +RFC 3931 L2TPv3 March 2005 + + + The shared secret between LCCEs is used to derive a unique shared key + for hiding and unhiding calculations. The derived shared key is + obtained via an HMAC-MD5 keyed hash [RFC2104], with the key + consisting of the shared secret, and with the data being hashed + consisting of a single octet containing the value 1. + + shared_key = HMAC_MD5 (shared_secret, 1) + + Hiding an AVP value is done in several steps. The first step is to + take the length and value fields of the original (cleartext) AVP and + encode them into the Hidden AVP Subformat, which appears as follows: + + Figure 5.3: Hidden AVP Subformat + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Length of Original Value | Original Attribute Value ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ... | Padding ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Length of Original Attribute Value: This is length of the Original + Attribute Value to be obscured in octets. This is necessary to + determine the original length of the Attribute Value that is lost + when the additional Padding is added. + + Original Attribute Value: Attribute Value that is to be obscured. + + Padding: Random additional octets used to obscure length of the + Attribute Value that is being hidden. + + To mask the size of the data being hidden, the resulting subformat + MAY be padded as shown above. Padding does NOT alter the value + placed in the Length of Original Attribute Value field, but does + alter the length of the resultant AVP that is being created. For + example, if an Attribute Value to be hidden is 4 octets in length, + the unhidden AVP length would be 10 octets (6 + Attribute Value + length). After hiding, the length of the AVP would become 6 + + Attribute Value length + size of the Length of Original Attribute + Value field + Padding. Thus, if Padding is 12 octets, the AVP length + would be 6 + 4 + 2 + 12 = 24 octets. + + + + + + + + + +Lau, et al. Standards Track [Page 34] + +RFC 3931 L2TPv3 March 2005 + + + Next, an MD5 [RFC1321] hash is performed (in network byte order) on + the concatenation of the following: + + + the 2-octet Attribute number of the AVP + + the shared key + + an arbitrary length random vector + + The value of the random vector used in this hash is passed in the + value field of a Random Vector AVP. This Random Vector AVP must be + placed in the message by the sender before any hidden AVPs. The same + random vector may be used for more than one hidden AVP in the same + message, but not for hiding two or more instances of an AVP with the + same Attribute Type unless the Attribute Values in the two AVPs are + also identical. When a different random vector is used for the + hiding of subsequent AVPs, a new Random Vector AVP MUST be placed in + the control message before the first AVP to which it applies. + + The MD5 hash value is then XORed with the first 16-octet (or less) + segment of the Hidden AVP Subformat and placed in the Attribute Value + field of the Hidden AVP. If the Hidden AVP Subformat is less than 16 + octets, the Subformat is transformed as if the Attribute Value field + had been padded to 16 octets before the XOR. Only the actual octets + present in the Subformat are modified, and the length of the AVP is + not altered. + + If the Subformat is longer than 16 octets, a second one-way MD5 hash + is calculated over a stream of octets consisting of the shared key + followed by the result of the first XOR. That hash is XORed with the + second 16-octet (or less) segment of the Subformat and placed in the + corresponding octets of the Value field of the Hidden AVP. + + If necessary, this operation is repeated, with the shared key used + along with each XOR result to generate the next hash to XOR the next + segment of the value with. + + The hiding method was adapted from [RFC2865], which was taken from + the "Mixing in the Plaintext" section in the book "Network Security" + by Kaufman, Perlman and Speciner [KPS]. A detailed explanation of + the method follows: + + Call the shared key S, the Random Vector RV, and the Attribute Type + A. Break the value field into 16-octet chunks p_1, p_2, etc., with + the last one padded at the end with random data to a 16-octet + boundary. Call the ciphertext blocks c_1, c_2, etc. We will also + define intermediate values b_1, b_2, etc. + + + + + + +Lau, et al. Standards Track [Page 35] + +RFC 3931 L2TPv3 March 2005 + + + b_1 = MD5 (A + S + RV) c_1 = p_1 xor b_1 + b_2 = MD5 (S + c_1) c_2 = p_2 xor b_2 + . . + . . + . . + b_i = MD5 (S + c_i-1) c_i = p_i xor b_i + + The String will contain c_1 + c_2 +...+ c_i, where "+" denotes + concatenation. + + On receipt, the random vector is taken from the last Random Vector + AVP encountered in the message prior to the AVP to be unhidden. The + above process is then reversed to yield the original value. + +5.4. AVP Summary + + The following sections contain a list of all L2TP AVPs defined in + this document. + + Following the name of the AVP is a list indicating the message types + that utilize each AVP. 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.4.1. General Control Message AVPs + + Message Type (All Messages) + + The Message Type AVP, Attribute Type 0, identifies the control + message herein and defines the context in which the exact meaning + of the following AVPs will be determined. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Message Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The Message Type is a 2-octet unsigned integer. + + The Message Type AVP MUST be the first AVP in a message, + immediately following the control message header (defined in + Section 3.2.1). See Section 3.1 for the list of defined control + message types and their identifiers. + + + + +Lau, et al. Standards Track [Page 36] + +RFC 3931 L2TPv3 March 2005 + + + The Mandatory (M) bit within the Message Type AVP has special + meaning. Rather than an indication as to whether the AVP itself + should be ignored if not recognized, it is an indication as to + whether the control message itself should be ignored. If the M + bit is set within the Message Type AVP and the Message Type is + unknown to the implementation, the control connection MUST be + cleared. If the M bit is not set, then the implementation may + ignore an unknown message type. The M bit MUST be set to 1 for + all message types defined in this document. This AVP MUST NOT be + hidden (the H bit MUST be 0). The Length of this AVP is 8. + + A vendor-specific control message may be defined by setting the + Vendor ID of the Message Type AVP to a value other than the IETF + Vendor ID of 0 (see Section 5.1). The Message Type AVP MUST still + be the first AVP in the control message. + + Message Digest (All Messages) + + The Message Digest AVP, Attribute Type 59 is used as an integrity + and authentication check of the L2TP Control Message header and + body. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Digest Type | Message Digest ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ... (16 or 20 octets) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Digest Type is a one-octet integer indicating the Digest + calculation algorithm: + + 0 HMAC-MD5 [RFC2104] + 1 HMAC-SHA-1 [RFC2104] + + Digest Type 0 (HMAC-MD5) MUST be supported, while Digest Type 1 + (HMAC-SHA-1) SHOULD be supported. + + The Message Digest is of variable length and contains the result + of the control message authentication and integrity calculation. + For Digest Type 0 (HMAC-MD5), the length of the digest MUST be 16 + + + +Lau, et al. Standards Track [Page 37] + +RFC 3931 L2TPv3 March 2005 + + + bytes. For Digest Type 1 (HMAC-SHA-1) the length of the digest + MUST be 20 bytes. + + If Control Message Authentication is enabled, at least one Message + Digest AVP MUST be present in all messages and MUST be placed + immediately after the Message Type AVP. This forces the Message + Digest AVP to begin at a well-known and fixed offset. A second + Message Digest AVP MAY be present in a message and MUST be placed + directly after the first Message Digest AVP. + + The shared secret between LCCEs is used to derive a unique shared + key for Control Message Authentication calculations. The derived + shared key is obtained via an HMAC-MD5 keyed hash [RFC2104], with + the key consisting of the shared secret, and with the data being + hashed consisting of a single octet containing the value 2. + + shared_key = HMAC_MD5 (shared_secret, 2) + + Calculation of the Message Digest is as follows for all messages + other than the SCCRQ (where "+" refers to concatenation): + + Message Digest = HMAC_Hash (shared_key, local_nonce + + remote_nonce + control_message) + + HMAC_Hash: HMAC Hashing algorithm identified by the Digest Type + (MD5 or SHA1) + + local_nonce: Nonce chosen locally and advertised to the remote + LCCE. + + remote_nonce: Nonce received from the remote LCCE + + (The local_nonce and remote_nonce are advertised via the + Control Message Authentication Nonce AVP, also defined in this + section.) + + shared_key: Derived shared key for this control connection + + control_message: The entire contents of the L2TP control + message, including the control message header and all AVPs. + Note that the control message header in this case begins after + the all-zero Session ID when running over IP (see Section + 4.1.1.2), and after the UDP header when running over UDP (see + Section 4.1.2.1). + + When calculating the Message Digest, the Message Digest AVP MUST + be present within the control message with the Digest Type set to + its proper value, but the Message Digest itself set to zeros. + + + +Lau, et al. Standards Track [Page 38] + +RFC 3931 L2TPv3 March 2005 + + + When receiving a control message, the contents of the Message + Digest AVP MUST be compared against the expected digest value + based on local calculation. This is done by performing the same + digest calculation above, with the local_nonce and remote_nonce + reversed. This message authenticity and integrity checking MUST + be performed before utilizing any information contained within the + control message. If the calculation fails, the message MUST be + dropped. + + The SCCRQ has special treatment as it is the initial message + commencing a new control connection. As such, there is only one + nonce available. Since the nonce is present within the message + itself as part of the Control Message Authentication Nonce AVP, + there is no need to use it in the calculation explicitly. + Calculation of the SCCRQ Message Digest is performed as follows: + + Message Digest = HMAC_Hash (shared_key, control_message) + + To allow for graceful switchover to a new shared secret or hash + algorithm, two Message Digest AVPs MAY be present in a control + message, and two shared secrets MAY be configured for a given + LCCE. If two Message Digest AVPs are received in a control + message, the message MUST be accepted if either Message Digest is + valid. If two shared secrets are configured, each (separately) + MUST be used for calculating a digest to be compared to the + Message Digest(s) received. When calculating a digest for a + control message, the Value field for both of the Message Digest + AVPs MUST be set to zero. + + This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for + this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The + Length is 23 for Digest Type 1 (HMAC-MD5), and 27 for Digest Type + 2 (HMAC-SHA-1). + + Control Message Authentication Nonce (SCCRQ, SCCRP) + + The Control Message Authentication Nonce AVP, Attribute Type 73, + MUST contain a cryptographically random value [RFC1750]. This + value is used for Control Message 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Nonce ... (arbitrary number of octets) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + +Lau, et al. Standards Track [Page 39] + +RFC 3931 L2TPv3 March 2005 + + + The Nonce is of arbitrary length, though at least 16 octets is + recommended. The Nonce contains the random value for use in the + Control Message Authentication hash calculation (see Message + Digest AVP definition in this section). + + If Control Message Authentication is enabled, this AVP MUST be + present in the SCCRQ and SCCRP messages. + + This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for + this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The + Length of this AVP is 6 plus the length of the Nonce. + + Random Vector (All Messages) + + The Random Vector AVP, Attribute Type 36, MUST contain a + cryptographically random value [RFC1750]. This value is used for + AVP Hiding. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Random Octet String ... (arbitrary number of octets) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The Random Octet String is of arbitrary length, though at least 16 + octets is recommended. The string contains the random vector for + use in computing the MD5 hash to retrieve or hide the Attribute + Value of a hidden AVP (see Section 5.3). + + More than one Random Vector AVP may appear in a message, in which + case a hidden AVP uses the Random Vector AVP most closely + preceding it. As such, at least one Random Vector AVP MUST + precede the first AVP with the H bit set. + + This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for + this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The + Length of this AVP is 6 plus the length of the Random Octet + String. + +5.4.2. Result and Error Codes + + Result Code (StopCCN, CDN) + + The Result Code AVP, Attribute Type 1, indicates the reason for + terminating the control connection or session. + + + + +Lau, et al. Standards Track [Page 40] + +RFC 3931 L2TPv3 March 2005 + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Result Code | Error Code (optional) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Error Message ... (optional, arbitrary number of octets) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The Result Code is a 2-octet unsigned integer. The optional Error + Code is a 2-octet unsigned integer. An optional Error Message can + follow the Error Code field. Presence of the Error Code and + Message is indicated by the AVP Length field. The Error Message + contains an arbitrary string providing further (human-readable) + text associated with the condition. Human-readable text in all + error messages MUST be provided in the UTF-8 charset [RFC3629] + using the Default Language [RFC2277]. + + This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for + this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The + Length is 8 if there is no Error Code or Message, 10 if there is + an Error Code and no Error Message, or 10 plus the length of the + Error Message if there is an Error Code and Message. + + Defined Result Code values for the StopCCN message are as follows: + + 0 - Reserved. + 1 - General request to clear control connection. + 2 - General error, Error Code indicates the problem. + 3 - Control connection already exists. + 4 - Requester is not authorized to establish a control + connection. + 5 - The protocol version of the requester is not supported, + Error Code indicates highest version supported. + 6 - Requester is being shut down. + 7 - Finite state machine error or timeout + + General Result Code values for the CDN message are as follows: + + 0 - Reserved. + 1 - Session disconnected due to loss of carrier or + circuit disconnect. + 2 - Session disconnected for the reason indicated in Error + Code. + 3 - Session disconnected for administrative reasons. + 4 - Session establishment failed due to lack of appropriate + facilities being available (temporary condition). + + + +Lau, et al. Standards Track [Page 41] + +RFC 3931 L2TPv3 March 2005 + + + 5 - Session establishment failed due to lack of appropriate + facilities being available (permanent condition). + 13 - Session not established due to losing tie breaker. + 14 - Session not established due to unsupported PW type. + 15 - Session not established, sequencing required without + valid L2-Specific Sublayer. + 16 - Finite state machine error or timeout. + + Additional service-specific Result Codes are defined outside this + document. + + The Error Codes defined below pertain to types of errors that are + not specific to any particular L2TP request, but rather to + protocol or message format errors. If an L2TP reply indicates in + its Result Code that a General Error occurred, the General Error + value should be examined to determine what the error was. The + currently defined General Error codes and their meanings are as + follows: + + 0 - No General Error. + 1 - No control connection exists yet for this pair of LCCEs. + 2 - Length is wrong. + 3 - One of the field values was out of range. + 4 - Insufficient resources to handle this operation now. + 5 - Invalid Session ID. + 6 - A generic vendor-specific error occurred. + 7 - Try another. If initiator is aware of other possible + responder destinations, it should try one of them. This can + be used to guide an LAC or LNS based on policy. + 8 - The session or control connection was shut down due to receipt + of an unknown AVP with the M bit set (see Section 5.2). The + Error Message SHOULD contain the attribute of the offending + AVP in (human-readable) text form. + 9 - Try another directed. If an LAC or LNS is aware of other + possible destinations, it should inform the initiator of the + control connection or session. The Error Message MUST contain + a comma-separated list of addresses from which the initiator + may choose. If the L2TP data channel runs over IPv4, then + this would be a comma-separated list of IP addresses in the + canonical dotted-decimal format (e.g., "192.0.2.1, 192.0.2.2, + 192.0.2.3") in the UTF-8 charset [RFC3629] using the Default + Language [RFC2277]. If there are no servers for the LAC or + LNS to suggest, then Error Code 7 should be used. For IPv4, + the delimiter between addresses MUST be precisely a single + comma and a single space. For IPv6, each literal address MUST + be enclosed in "[" and "]" characters, following the encoding + described in [RFC2732]. + + + + +Lau, et al. Standards Track [Page 42] + +RFC 3931 L2TPv3 March 2005 + + + When a General Error Code of 6 is used, additional information + about the error SHOULD be included in the Error Message field. A + vendor-specific AVP MAY be sent to more precisely detail a + vendor-specific problem. + +5.4.3. Control Connection Management AVPs + + Control Connection Tie Breaker (SCCRQ) + + The Control Connection Tie Breaker AVP, Attribute Type 5, + indicates that the sender desires a single control connection to + exist between a given pair of LCCEs. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Control Connection Tie Breaker Value ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ... (64 bits) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The Control Connection Tie Breaker Value is an 8-octet random + value that is used to choose a single control connection when two + LCCEs request a control connection concurrently. The recipient of + a SCCRQ must check to see if a SCCRQ has been sent to the peer; if + so, a tie has been detected. In this case, the LCCE must compare + its Control Connection Tie Breaker value with the one received in + the SCCRQ. The lower value "wins", and the "loser" MUST discard + its control connection. A StopCCN SHOULD be sent by the winner as + an explicit rejection for the losing SCCRQ. In the case in which + a tie breaker is present on both sides and the value is equal, + both sides MUST discard their control connections and restart + control connection negotiation with a new, random tie breaker + value. + + If a tie breaker is received and an outstanding SCCRQ has no tie + breaker value, the initiator that included the Control Connection + Tie Breaker AVP "wins". If neither side issues a tie breaker, + then two separate control connections are opened. + + Applications that employ a distinct and well-known initiator have + no need for tie breaking, and MAY omit this AVP or disable tie + breaking functionality. Applications that require tie breaking + also require that an LCCE be uniquely identifiable upon receipt of + an SCCRQ. For L2TP over IP, this MUST be accomplished via the + Router ID AVP. + + + +Lau, et al. Standards Track [Page 43] + +RFC 3931 L2TPv3 March 2005 + + + Note that in [RFC2661], this AVP is referred to as the "Tie + Breaker AVP" and is applicable only to a control connection. In + L2TPv3, the AVP serves the same purpose of tie breaking, but is + applicable to a control connection or a session. The Control + Connection Tie Breaker AVP (present only in Control Connection + messages) and Session Tie Breaker AVP (present only in Session + messages), are described separately in this document, but share + the same Attribute type of 5. + + This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for + this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The + length of this AVP is 14. + + Host Name (SCCRQ, SCCRP) + + The Host Name AVP, Attribute Type 7, indicates the name of the + issuing LAC or LNS, encoded in the US-ASCII charset. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Host Name ... (arbitrary number of octets) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The Host Name is of arbitrary length, but MUST be at least 1 + octet. + + This name should be as broadly unique as possible; for hosts + participating in DNS [RFC1034], a host name with fully qualified + domain would be appropriate. The Host Name AVP and/or Router ID + AVP MUST be used to identify an LCCE as described in Section 3.3. + + This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for + this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The + Length of this AVP is 6 plus the length of the Host Name. + + Router ID (SCCRQ, SCCRP) + + The Router ID AVP, Attribute Type 60, is an identifier used to + identify an LCCE for control connection setup, tie breaking, + and/or tunnel authentication. + + + + + + + + +Lau, et al. Standards Track [Page 44] + +RFC 3931 L2TPv3 March 2005 + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Router Identifier | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The Router Identifier is a 4-octet unsigned integer. Its value is + unique for a given LCCE, per Section 8.1 of [RFC2072]. The Host + Name AVP and/or Router ID AVP MUST be used to identify an LCCE as + described in Section 3.3. + + Implementations MUST NOT assume that Router Identifier is a valid + IP address. The Router Identifier for L2TP over IPv6 can be + obtained from an IPv4 address (if available) or via unspecified + implementation-specific means. + + This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for + this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The + Length of this AVP is 10. + + Vendor Name (SCCRQ, SCCRP) + + The Vendor Name AVP, Attribute Type 8, contains a vendor-specific + (possibly human-readable) string describing the type of LAC or LNS + being 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Vendor Name ... (arbitrary number of octets) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The Vendor Name is the indicated number of octets representing the + vendor string. Human-readable text for this AVP MUST be provided + in the US-ASCII charset [RFC1958, RFC2277]. + + This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for + this AVP SHOULD be set to 0, but MAY vary (see Section 5.2). The + Length (before hiding) of this AVP is 6 plus the length of the + Vendor Name. + + + + + + + +Lau, et al. Standards Track [Page 45] + +RFC 3931 L2TPv3 March 2005 + + + Assigned Control Connection ID (SCCRQ, SCCRP, StopCCN) + + The Assigned Control Connection ID AVP, Attribute Type 61, + contains the ID being assigned to this control connection by the + sender. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Assigned Control Connection ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The Assigned Control Connection ID is a 4-octet non-zero unsigned + integer. + + The Assigned Control Connection ID AVP establishes the identifier + used to multiplex and demultiplex multiple control connections + between a pair of LCCEs. Once the Assigned Control Connection ID + AVP has been received by an LCCE, the Control Connection ID + specified in the AVP MUST be included in the Control Connection ID + field of all control packets sent to the peer for the lifetime of + the control connection. Before the Assigned Control Connection ID + AVP is received from a peer, all control messages MUST be sent to + that peer with a Control Connection ID value of 0 in the header. + Because a Control Connection ID value of 0 is used in this special + manner, the zero value MUST NOT be sent as an Assigned Control + Connection ID value. + + Under certain circumstances, an LCCE may need to send a StopCCN to + a peer without having yet received an Assigned Control Connection + ID AVP from the peer (i.e., SCCRQ sent, no SCCRP received yet). + In this case, the Assigned Control Connection ID AVP that had been + sent to the peer earlier (i.e., in the SCCRQ) MUST be sent as the + Assigned Control Connection ID AVP in the StopCCN. This policy + allows the peer to try to identify the appropriate control + connection via a reverse lookup. + + This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for + this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The + Length (before hiding) of this AVP is 10. + + Receive Window Size (SCCRQ, SCCRP) + + The Receive Window Size AVP, Attribute Type 10, specifies the + receive window size being offered to the remote peer. + + + + +Lau, et al. Standards Track [Page 46] + +RFC 3931 L2TPv3 March 2005 + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Window Size | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The Window Size is a 2-octet unsigned integer. + + If absent, the peer must assume a Window Size of 4 for its + transmit window. + + The remote peer may send the specified number of control messages + before it must wait for an acknowledgment. See Section 4.2 for + more information on reliable control message delivery. + + This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for + this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The + Length of this AVP is 8. + + Pseudowire Capabilities List (SCCRQ, SCCRP) + + The Pseudowire Capabilities List (PW Capabilities List) AVP, + Attribute Type 62, indicates the L2 payload types the sender can + support. The specific payload type of a given session is + identified by the Pseudowire Type AVP. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | PW Type 0 | ... | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | ... | PW Type N | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Defined PW types that may appear in this list are managed by IANA + and will appear in associated pseudowire-specific documents for + each PW type. + + If a sender includes a given PW type in the PW Capabilities List + AVP, the sender assumes full responsibility for supporting that + particular payload, such as any payload-specific AVPs, L2-Specific + Sublayer, or control messages that may be defined in the + appropriate companion document. + + + + +Lau, et al. Standards Track [Page 47] + +RFC 3931 L2TPv3 March 2005 + + + This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for + this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The + Length (before hiding) of this AVP is 8 octets with one PW type + specified, plus 2 octets for each additional PW type. + + Preferred Language (SCCRQ, SCCRP) + + The Preferred Language AVP, Attribute Type 72, provides a method + for an LCCE to indicate to the peer the language in which human- + readable messages it sends SHOULD be composed. This AVP contains + a single language tag or language range [RFC3066]. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Preferred Language... (arbitrary number of octets) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The Preferred Language is the indicated number of octets + representing the language tag or language range, encoded in the + US-ASCII charset. + + It is not required to send a Preferred Language AVP. If (1) an + LCCE does not signify a language preference by the inclusion of + this AVP in the SCCRQ or SCCRP, (2) the Preferred Language AVP is + unrecognized, or (3) the requested language is not supported by + the peer LCCE, the default language [RFC2277] MUST be used for all + internationalized strings sent by the peer. + + This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for + this AVP SHOULD be set to 0, but MAY vary (see Section 5.2). The + Length (before hiding) of this AVP is 6 plus the length of the + Preferred Language. + +5.4.4. Session Management AVPs + + Local Session ID (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN, CDN, WEN, SLI) + + The Local Session ID AVP (analogous to the Assigned Session ID in + L2TPv2), Attribute Type 63, contains the identifier being assigned + to this session by the sender. + + + + + + + + +Lau, et al. Standards Track [Page 48] + +RFC 3931 L2TPv3 March 2005 + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Local Session ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The Local Session ID is a 4-octet non-zero unsigned integer. + + The Local Session ID AVP establishes the two identifiers used to + multiplex and demultiplex sessions between two LCCEs. Each LCCE + chooses any free value it desires, and sends it to the remote LCCE + using this AVP. The remote LCCE MUST then send all data packets + associated with this session using this value. Additionally, for + all session-oriented control messages sent after this AVP is + received (e.g., ICRP, ICCN, CDN, SLI, etc.), the remote LCCE MUST + echo this value in the Remote Session ID AVP. + + Note that a Session ID value is unidirectional. Because each LCCE + chooses its Session ID independent of its peer LCCE, the value + does not have to match in each direction for a given session. + + See Section 4.1 for additional information about the Session ID. + + This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for + this AVP SHOULD be 1 set to 1, but MAY vary (see Section 5.2). + The Length (before hiding) of this AVP is 10. + + Remote Session ID (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN, CDN, WEN, SLI) + + The Remote Session ID AVP, Attribute Type 64, contains the + identifier that was assigned to this session by the 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Remote Session ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The Remote Session ID is a 4-octet non-zero unsigned integer. + + The Remote Session ID AVP MUST be present in all session-level + control messages. The AVP's value echoes the session identifier + advertised by the peer via the Local Session ID AVP. It is the + same value that will be used in all transmitted data messages by + + + +Lau, et al. Standards Track [Page 49] + +RFC 3931 L2TPv3 March 2005 + + + this side of the session. In most cases, this identifier is + sufficient for the peer to look up session-level context for this + control message. + + When a session-level control message must be sent to the peer + before the Local Session ID AVP has been received, the value of + the Remote Session ID AVP MUST be set to zero. Additionally, the + Local Session ID AVP (sent in a previous control message for this + session) MUST be included in the control message. The peer must + then use the Local Session ID AVP to perform a reverse lookup to + find its session context. Session-level control messages defined + in this document that might be subject to a reverse lookup by a + receiving peer include the CDN, WEN, and SLI. + + This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for + this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The + Length (before hiding) of this AVP is 10. + + Assigned Cookie (ICRQ, ICRP, OCRQ, OCRP) + + The Assigned Cookie AVP, Attribute Type 65, contains the Cookie + value being assigned to this session by the sender. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Assigned Cookie (32 or 64 bits) ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The Assigned Cookie is a 4-octet or 8-octet random value. + + The Assigned Cookie AVP contains the value used to check the + association of a received data message with the session identified + by the Session ID. All data messages sent to a peer MUST use the + Assigned Cookie sent by the peer in this AVP. The value's length + (0, 32, or 64 bits) is obtained by the length of the AVP. + + A missing Assigned Cookie AVP or Assigned Cookie Value of zero + length indicates that the Cookie field should not be present in + any data packets sent to the LCCE sending this AVP. + + See Section 4.1 for additional information about the Assigned + Cookie. + + + + + + +Lau, et al. Standards Track [Page 50] + +RFC 3931 L2TPv3 March 2005 + + + This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for + this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The + Length (before hiding) of this AVP may be 6, 10, or 14 octets. + + Serial Number (ICRQ, OCRQ) + + The Serial Number AVP, Attribute Type 15, contains an identifier + assigned by the LAC or LNS to this session. + + The Attribute Value field for this AVP has the following format: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Serial Number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The Serial Number is a 32-bit value. + + The Serial Number is intended to be an easy reference for + administrators on both ends of a control connection to use when + investigating session failure problems. Serial Numbers should be + set to progressively increasing values, which are likely to be + unique for a significant period of time across all interconnected + LNSs and LACs. + + Note that in RFC 2661, this value was referred to as the "Call + Serial Number AVP". It serves the same purpose and has the same + attribute value and composition. + + This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for + this AVP SHOULD be set to 0, but MAY vary (see Section 5.2). The + Length (before hiding) of this AVP is 10. + + Remote End ID (ICRQ, OCRQ) + + The Remote End ID AVP, Attribute Type 66, contains an identifier + used to bind L2TP sessions to a given circuit, interface, or + bridging instance. It also may be used to detect session-level + ties. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Remote End Identifier ... (arbitrary number of octets) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + +Lau, et al. Standards Track [Page 51] + +RFC 3931 L2TPv3 March 2005 + + + The Remote End Identifier field is a variable-length field whose + value is unique for a given LCCE peer, as described in Section + 3.3. + + A session-level tie is detected if an LCCE receives an ICRQ or + OCRQ with an End ID AVP whose value matches that which was just + sent in an outgoing ICRQ or OCRQ to the same peer. If the two + values match, an LCCE recognizes that a tie exists (i.e., both + LCCEs are attempting to establish sessions for the same circuit). + The tie is broken by the Session Tie Breaker AVP. + + By default, the LAC-LAC cross-connect application (see Section + 2(b)) of L2TP over an IP network MUST utilize the Router ID AVP + and Remote End ID AVP to associate a circuit to an L2TP session. + Other AVPs MAY be used for LCCE or circuit identification as + specified in companion documents. + + This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for + this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The + Length (before hiding) of this AVP is 6 plus the length of the + Remote End Identifier value. + + Session Tie Breaker (ICRQ, OCRQ) + + The Session Tie Breaker AVP, Attribute Type 5, is used to break + ties when two peers concurrently attempt to establish a session + for the same circuit. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Session Tie Breaker Value ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ... (64 bits) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The Session Tie Breaker Value is an 8-octet random value that is + used to choose a session when two LCCEs concurrently request a + session for the same circuit. A tie is detected by examining the + peer's identity (described in Section 3.3) plus the per-session + shared value communicated via the End ID AVP. In the case of a + tie, the recipient of an ICRQ or OCRQ must compare the received + tie breaker value with the one that it sent earlier. The LCCE + with the lower value "wins" and MUST send a CDN with result code + set to 13 (as defined in Section 5.4.2) in response to the losing + ICRQ or OCRQ. In the case in which a tie is detected, tie + + + +Lau, et al. Standards Track [Page 52] + +RFC 3931 L2TPv3 March 2005 + + + breakers are sent by both sides, and the tie breaker values are + equal, both sides MUST discard their sessions and restart session + negotiation with new random tie breaker values. + + If a tie is detected but only one side sends a Session Tie Breaker + AVP, the session initiator that included the Session Tie Breaker + AVP "wins". If neither side issues a tie breaker, then both sides + MUST tear down the session. + + This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for + this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The + Length of this AVP is 14. + + Pseudowire Type (ICRQ, OCRQ) + + The Pseudowire Type (PW Type) AVP, Attribute Type 68, indicates + the L2 payload type of the packets that will be tunneled using + this L2TP session. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | PW Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + A peer MUST NOT request an incoming or outgoing call with a PW + Type AVP specifying a value not advertised in the PW Capabilities + List AVP it received during control connection establishment. + Attempts to do so MUST result in the call being rejected via a CDN + with the Result Code set to 14 (see Section 5.4.2). + + This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for + this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The + Length (before hiding) of this AVP is 8. + + L2-Specific Sublayer (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN) + + The L2-Specific Sublayer AVP, Attribute Type 69, indicates the + presence and format of the L2-Specific Sublayer the sender of this + AVP requires on all incoming data packets for this L2TP session. + + 0 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | L2-Specific Sublayer Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + +Lau, et al. Standards Track [Page 53] + +RFC 3931 L2TPv3 March 2005 + + + The L2-Specific Sublayer Type is a 2-octet unsigned integer with + the following values defined in this document: + + 0 - There is no L2-Specific Sublayer present. + 1 - The Default L2-Specific Sublayer (defined in Section 4.6) + is used. + + If this AVP is received and has a value other than zero, the + receiving LCCE MUST include the identified L2-Specific Sublayer in + its outgoing data messages. If the AVP is not received, it is + assumed that there is no sublayer present. + + This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for + this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The + Length (before hiding) of this AVP is 8. + + Data Sequencing (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN) + + The Data Sequencing AVP, Attribute Type 70, indicates that the + sender requires some or all of the data packets that it receives + to be sequenced. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Data Sequencing Level | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The Data Sequencing Level is a 2-octet unsigned integer indicating + the degree of incoming data traffic that the sender of this AVP + wishes to be marked with sequence numbers. + + Defined Data Sequencing Levels are as follows: + + 0 - No incoming data packets require sequencing. + 1 - Only non-IP data packets require sequencing. + 2 - All incoming data packets require sequencing. + + If a Data Sequencing Level of 0 is specified, there is no need to + send packets with sequence numbers. If sequence numbers are sent, + they will be ignored upon receipt. If no Data Sequencing AVP is + received, a Data Sequencing Level of 0 is assumed. + + If a Data Sequencing Level of 1 is specified, only non-IP traffic + carried within the tunneled L2 frame should have sequence numbers + applied. Non-IP traffic here refers to any packets that cannot be + + + +Lau, et al. Standards Track [Page 54] + +RFC 3931 L2TPv3 March 2005 + + + classified as an IP packet within their respective L2 framing + (e.g., a PPP control packet or NETBIOS frame encapsulated by Frame + Relay before being tunneled). All traffic that can be classified + as IP MUST be sent with no sequencing (i.e., the S bit in the L2- + Specific Sublayer is set to zero). If a packet is unable to be + classified at all (e.g., because it has been compressed or + encrypted at layer 2) or if an implementation is unable to perform + such classification within L2 frames, all packets MUST be provided + with sequence numbers (essentially falling back to a Data + Sequencing Level of 2). + + If a Data Sequencing Level of 2 is specified, all traffic MUST be + sequenced. + + Data sequencing may only be requested when there is an L2-Specific + Sublayer present that can provide sequence numbers. If sequencing + is requested without requesting a L2-Specific Sublayer AVP, the + session MUST be disconnected with a Result Code of 15 (see Section + 5.4.2). + + This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for + this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The + Length (before hiding) of this AVP is 8. + + Tx Connect Speed (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN) + + The Tx Connect Speed BPS AVP, Attribute Type 74, contains the + speed of the facility chosen for the connection attempt. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Connect Speed in bps... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ...Connect Speed in bps (64 bits) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The Tx Connect Speed BPS is an 8-octet value indicating the speed + in bits per second. A value of zero indicates that the speed is + indeterminable or that there is no physical point-to-point link. + + When the optional Rx Connect Speed AVP is present, the value in + this AVP represents the transmit connect speed from the + perspective of the LAC (i.e., data flowing from the LAC to the + remote system). When the optional Rx Connect Speed AVP is NOT + present, the connection speed between the remote system and LAC is + + + +Lau, et al. Standards Track [Page 55] + +RFC 3931 L2TPv3 March 2005 + + + assumed to be symmetric and is represented by the single value in + this AVP. + + This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for + this AVP SHOULD be set to 0, but MAY vary (see Section 5.2). The + Length (before hiding) of this AVP is 14. + + Rx Connect Speed (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN) + + The Rx Connect Speed AVP, Attribute Type 75, represents the speed + of the connection from the perspective of the LAC (i.e., data + flowing from the remote system to the LAC). + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Connect Speed in bps... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ...Connect Speed in bps (64 bits) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Connect Speed BPS is an 8-octet value indicating the speed in bits + per second. A value of zero indicates that the speed is + indeterminable or that there is no physical point-to-point link. + + Presence of this AVP implies that the connection speed may be + asymmetric with respect to the transmit connect speed given in the + Tx Connect Speed AVP. + + This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for + this AVP SHOULD be set to 0, but MAY vary (see Section 5.2). The + Length (before hiding) of this AVP is 14. + + Physical Channel ID (ICRQ, ICRP, OCRP) + + The Physical Channel ID AVP, Attribute Type 25, contains the + vendor-specific physical channel number used for a 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Physical Channel ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + +Lau, et al. Standards Track [Page 56] + +RFC 3931 L2TPv3 March 2005 + + + Physical Channel ID is a 4-octet value intended to be used for + logging purposes only. + + This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for + this AVP SHOULD be set to 0, but MAY vary (see Section 5.2). The + Length (before hiding) of this AVP is 10. + +5.4.5. Circuit Status AVPs + + Circuit Status (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN, SLI) + + The Circuit Status AVP, Attribute Type 71, indicates the initial + status of or a status change in the circuit to which the session + is bound. + + 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 |N|A| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The A (Active) bit indicates whether the circuit is + up/active/ready (1) or down/inactive/not-ready (0). + + The N (New) bit indicates whether the circuit status indication is + for a new circuit (1) or an existing circuit (0). Links that have + a similar mechanism available (e.g., Frame Relay) MUST map the + setting of this bit to the associated signaling for that link. + Otherwise, the New bit SHOULD still be set the first time the L2TP + session is established after provisioning. + + The remaining bits are reserved for future use. Reserved bits + MUST be set to 0 when sending and ignored upon receipt. + + The Circuit Status AVP is used to advertise whether a circuit or + interface bound to an L2TP session is up and ready to send and/or + receive traffic. Different circuit types have different names for + status types. For example, HDLC primary and secondary stations + refer to a circuit as being "Receive Ready" or "Receive Not + Ready", while Frame Relay refers to a circuit as "Active" or + "Inactive". This AVP adopts the latter terminology, though the + concept remains the same regardless of the PW type for the L2TP + session. + + + + + + +Lau, et al. Standards Track [Page 57] + +RFC 3931 L2TPv3 March 2005 + + + In the simplest case, the circuit to which this AVP refers is a + single physical interface, port, or circuit, depending on the + application and the session setup. The status indication in this + AVP may then be used to provide simple ILMI interworking for a + variety of circuit types. For virtual or multipoint interfaces, + the Circuit Status AVP is still utilized, but in this case, it + refers to the state of an internal structure or a logical set of + circuits. Each PW-specific companion document MUST specify + precisely how this AVP is translated for each circuit type. + + If this AVP is received with a Not Active notification for a given + L2TP session, all data traffic for that session MUST cease (or not + begin) in the direction of the sender of the Circuit Status AVP + until the circuit is advertised as Active. + + The Circuit Status MUST be advertised by this AVP in ICRQ, ICRP, + OCRQ, and OCRP messages. Often, the circuit type will be marked + Active when initiated, but subsequently MAY be advertised as + Inactive. This indicates that an L2TP session is to be created, + but that the interface or circuit is still not ready to pass + traffic. The ICCN, OCCN, and SLI control messages all MAY contain + this AVP to update the status of the circuit after establishment + of the L2TP session is requested. + + If additional circuit status information is needed for a given PW + type, any new PW-specific AVPs MUST be defined in a separate + document. This AVP is only for general circuit status information + generally applicable to all circuit/interface types. + + This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for + this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The + Length (before hiding) of this AVP is 8. + + Circuit Errors (WEN) + + The Circuit Errors AVP, Attribute Type 34, conveys circuit error + information to the peer. + + + + + + + + + + + + + + +Lau, et al. Standards Track [Page 58] + +RFC 3931 L2TPv3 March 2005 + + + 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 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Hardware Overruns | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Buffer Overruns | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Timeout Errors | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Alignment Errors | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The following fields are defined: + + Reserved: 2 octets of Reserved data is present (providing longword + alignment within the AVP of the following values). Reserved + data MUST be zero on sending and ignored upon receipt. + Hardware Overruns: Number of receive buffer overruns since call + was established. + Buffer Overruns: Number of buffer overruns detected since call was + established. + Timeout Errors: Number of timeouts since call was established. + Alignment Errors: Number of alignment errors since call was + established. + + This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for + this AVP SHOULD be set to 0, but MAY vary (see Section 5.2). The + Length (before hiding) of this AVP is 32. + +6. Control Connection Protocol Specification + + The following control messages are used to establish, maintain, and + tear down L2TP control connections. All data packets are sent in + network order (high-order octets first). Any "reserved" or "empty" + fields MUST be sent as 0 values to allow for protocol extensibility. + + The exchanges in which these messages are involved are outlined in + Section 3.3. + + + + + + + + + +Lau, et al. Standards Track [Page 59] + +RFC 3931 L2TPv3 March 2005 + + +6.1. Start-Control-Connection-Request (SCCRQ) + + Start-Control-Connection-Request (SCCRQ) is a control message used to + initiate a control connection between two LCCEs. It is sent by + either the LAC or the LNS to begin the control connection + establishment process. + + The following AVPs MUST be present in the SCCRQ: + + Message Type + Host Name + Router ID + Assigned Control Connection ID + Pseudowire Capabilities List + + The following AVPs MAY be present in the SCCRQ: + + Random Vector + Control Message Authentication Nonce + Message Digest + Control Connection Tie Breaker + Vendor Name + Receive Window Size + Preferred Language + +6.2. Start-Control-Connection-Reply (SCCRP) + + Start-Control-Connection-Reply (SCCRP) is the control message sent in + reply to a received SCCRQ message. The SCCRP is used to indicate + that the SCCRQ was accepted and that establishment of the control + connection should continue. + + The following AVPs MUST be present in the SCCRP: + + Message Type + Host Name + Router ID + Assigned Control Connection ID + Pseudowire Capabilities List + + The following AVPs MAY be present in the SCCRP: + + Random Vector + Control Message Authentication Nonce + Message Digest + Vendor Name + Receive Window Size + Preferred Language + + + +Lau, et al. Standards Track [Page 60] + +RFC 3931 L2TPv3 March 2005 + + +6.3. Start-Control-Connection-Connected (SCCCN) + + Start-Control-Connection-Connected (SCCCN) is the control message + sent in reply to an SCCRP. The SCCCN completes the control + connection establishment process. + + The following AVP MUST be present in the SCCCN: + + Message Type + + The following AVP MAY be present in the SCCCN: + + Random Vector + Message Digest + +6.4. Stop-Control-Connection-Notification (StopCCN) + + Stop-Control-Connection-Notification (StopCCN) is the control message + sent by either LCCE to inform its peer that the control connection is + being shut down and that the control connection should be closed. In + addition, all active sessions are implicitly cleared (without sending + any explicit session control messages). The reason for issuing this + request is indicated in the Result Code AVP. There is no explicit + reply to the message, only the implicit ACK that is received by the + reliable control message delivery layer. + + The following AVPs MUST be present in the StopCCN: + + Message Type + Result Code + + The following AVPs MAY be present in the StopCCN: + + Random Vector + Message Digest + Assigned Control Connection ID + + Note that the Assigned Control Connection ID MUST be present if the + StopCCN is sent after an SCCRQ or SCCRP message has been sent. + +6.5. Hello (HELLO) + + The Hello (HELLO) message is an L2TP control message sent by either + peer of a control connection. This control message is used as a + "keepalive" for the control connection. See Section 4.2 for a + description of the keepalive mechanism. + + + + + +Lau, et al. Standards Track [Page 61] + +RFC 3931 L2TPv3 March 2005 + + + HELLO messages are global to the control connection. The Session ID + in a HELLO message MUST be 0. + + The following AVP MUST be present in the HELLO: + + Message Type + + The following AVP MAY be present in the HELLO: + + Random Vector + Message Digest + +6.6. Incoming-Call-Request (ICRQ) + + Incoming-Call-Request (ICRQ) is the control message sent by an LCCE + to a peer when an incoming call is detected (although the ICRQ may + also be sent as a result of a local event). It is the first in a + three-message exchange used for establishing a session via an L2TP + control connection. + + The ICRQ is used to indicate that a session is to be established + between an LCCE and a peer. The sender of an ICRQ provides the peer + with parameter information for the session. However, the sender + makes no demands about how the session is terminated at the peer + (i.e., whether the L2 traffic is processed locally, forwarded, etc.). + + The following AVPs MUST be present in the ICRQ: + + Message Type + Local Session ID + Remote Session ID + Serial Number + Pseudowire Type + Remote End ID + Circuit Status + + The following AVPs MAY be present in the ICRQ: + + Random Vector + Message Digest + Assigned Cookie + Session Tie Breaker + L2-Specific Sublayer + Data Sequencing + Tx Connect Speed + Rx Connect Speed + Physical Channel ID + + + + +Lau, et al. Standards Track [Page 62] + +RFC 3931 L2TPv3 March 2005 + + +6.7. Incoming-Call-Reply (ICRP) + + Incoming-Call-Reply (ICRP) is the control message sent by an LCCE in + response to a received ICRQ. It is the second in the three-message + exchange used for establishing sessions within an L2TP control + connection. + + The ICRP is used to indicate that the ICRQ was successful and that + the peer should establish (i.e., answer) the incoming call if it has + not already done so. It also allows the sender to indicate specific + parameters about the L2TP session. + + The following AVPs MUST be present in the ICRP: + + Message Type + Local Session ID + Remote Session ID + Circuit Status + + The following AVPs MAY be present in the ICRP: + + Random Vector + Message Digest + Assigned Cookie + L2-Specific Sublayer + Data Sequencing + Tx Connect Speed + Rx Connect Speed + Physical Channel ID + +6.8. Incoming-Call-Connected (ICCN) + + Incoming-Call-Connected (ICCN) is the control message sent by the + LCCE that originally sent an ICRQ upon receiving an ICRP from its + peer. It is the final message in the three-message exchange used for + establishing L2TP sessions. + + The ICCN is used to indicate that the ICRP was accepted, that the + call has been established, and that the L2TP session should move to + the established state. It also allows the sender to indicate + specific parameters about the established call (parameters that may + not have been available at the time the ICRQ was issued). + + The following AVPs MUST be present in the ICCN: + + Message Type + Local Session ID + Remote Session ID + + + +Lau, et al. Standards Track [Page 63] + +RFC 3931 L2TPv3 March 2005 + + + The following AVPs MAY be present in the ICCN: + + Random Vector + Message Digest + L2-Specific Sublayer + Data Sequencing + Tx Connect Speed + Rx Connect Speed + Circuit Status + +6.9. Outgoing-Call-Request (OCRQ) + + Outgoing-Call-Request (OCRQ) is the control message sent by an LCCE + to an LAC to indicate that an outbound call at the LAC is to be + established based on specific destination information sent in this + message. It is the first in a three-message exchange used for + establishing a session and placing a call on behalf of the initiating + LCCE. + + Note that a call may be any L2 connection requiring well-known + destination information to be sent from an LCCE to an LAC. This call + could be a dialup connection to the PSTN, an SVC connection, the IP + address of another LCCE, or any other destination dictated by the + sender of this message. + + The following AVPs MUST be present in the OCRQ: + + Message Type + Local Session ID + Remote Session ID + Serial Number + Pseudowire Type + Remote End ID + Circuit Status + + The following AVPs MAY be present in the OCRQ: + + Random Vector + Message Digest + Assigned Cookie + Tx Connect Speed + Rx Connect Speed + Session Tie Breaker + L2-Specific Sublayer + Data Sequencing + + + + + + +Lau, et al. Standards Track [Page 64] + +RFC 3931 L2TPv3 March 2005 + + +6.10. Outgoing-Call-Reply (OCRP) + + Outgoing-Call-Reply (OCRP) is the control message sent by an LAC to + an LCCE in response to a received OCRQ. It is the second in a + three-message exchange used for establishing a session within an L2TP + control connection. + + OCRP is used to indicate that the LAC has been able to attempt the + outbound call. The message returns any relevant parameters regarding + the call attempt. Data MUST NOT be forwarded until the OCCN is + received, which indicates that the call has been placed. + + The following AVPs MUST be present in the OCRP: + + Message Type + Local Session ID + Remote Session ID + Circuit Status + + The following AVPs MAY be present in the OCRP: + + Random Vector + Message Digest + Assigned Cookie + L2-Specific Sublayer + Tx Connect Speed + Rx Connect Speed + Data Sequencing + Physical Channel ID + +6.11. Outgoing-Call-Connected (OCCN) + + Outgoing-Call-Connected (OCCN) is the control message sent by an LAC + to another LCCE after the OCRP and after the outgoing call has been + completed. It is the final message in a three-message exchange used + for establishing a session. + + OCCN is used to indicate that the result of a requested outgoing call + was successful. It also provides information to the LCCE who + requested the call about the particular parameters obtained after the + call was established. + + The following AVPs MUST be present in the OCCN: + + Message Type + Local Session ID + Remote Session ID + + + + +Lau, et al. Standards Track [Page 65] + +RFC 3931 L2TPv3 March 2005 + + + The following AVPs MAY be present in the OCCN: + + Random Vector + Message Digest + L2-Specific Sublayer + Tx Connect Speed + Rx Connect Speed + Data Sequencing + Circuit Status + +6.12. Call-Disconnect-Notify (CDN) + + The Call-Disconnect-Notify (CDN) is a control message sent by an LCCE + to request disconnection of a specific session. Its purpose is to + inform the peer of the disconnection and the reason for the + disconnection. The peer MUST clean up any resources, and does not + send back any indication of success or failure for such cleanup. + + The following AVPs MUST be present in the CDN: + + Message Type + Result Code + Local Session ID + Remote Session ID + + The following AVP MAY be present in the CDN: + + Random Vector + Message Digest + +6.13. WAN-Error-Notify (WEN) + + The WAN-Error-Notify (WEN) is a control message sent from an LAC to + an LNS to indicate WAN error conditions. The counters in this + message are cumulative. This message should only be sent when an + error occurs, and not more than once every 60 seconds. The counters + are reset when a new call is established. + + The following AVPs MUST be present in the WEN: + + Message Type + Local Session ID + Remote Session ID + Circuit Errors + + + + + + + +Lau, et al. Standards Track [Page 66] + +RFC 3931 L2TPv3 March 2005 + + + The following AVP MAY be present in the WEN: + + Random Vector + Message Digest + +6.14. Set-Link-Info (SLI) + + The Set-Link-Info control message is sent by an LCCE to convey link + or circuit status change information regarding the circuit associated + with this L2TP session. For example, if PPP renegotiates LCP at an + LNS or between an LAC and a Remote System, or if a forwarded Frame + Relay VC transitions to Active or Inactive at an LAC, an SLI message + SHOULD be sent to indicate this event. Precise details of when the + SLI is sent, what PW type-specific AVPs must be present, and how + those AVPs should be interpreted by the receiving peer are outside + the scope of this document. These details should be described in the + associated pseudowire-specific documents that require use of this + message. + + The following AVPs MUST be present in the SLI: + + Message Type + Local Session ID + Remote Session ID + + The following AVPs MAY be present in the SLI: + + Random Vector + Message Digest + Circuit Status + +6.15. Explicit-Acknowledgement (ACK) + + The Explicit Acknowledgement (ACK) message is used only to + acknowledge receipt of a message or messages on the control + connection (e.g., for purposes of updating Ns and Nr values). + Receipt of this message does not trigger an event for the L2TP + protocol state machine. + + A message received without any AVPs (including the Message Type AVP), + is referred to as a Zero Length Body (ZLB) message, and serves the + same function as the Explicit Acknowledgement. ZLB messages are only + permitted when Control Message Authentication defined in Section 4.3 + is not enabled. + + + + + + + +Lau, et al. Standards Track [Page 67] + +RFC 3931 L2TPv3 March 2005 + + + The following AVPs MAY be present in the ACK message: + + Message Type + Message Digest + +7. Control Connection State Machines + + The state tables defined in this section govern the exchange of + control messages defined in Section 6. Tables are defined for + incoming call placement and outgoing call placement, as well as for + initiation of the control connection itself. The state tables do not + encode timeout and retransmission behavior, as this is handled in the + underlying reliable control message delivery mechanism (see Section + 4.2). + +7.1. Malformed AVPs and Control Messages + + Receipt of an invalid or unrecoverable malformed control message + SHOULD be logged appropriately and the control connection cleared to + ensure recovery to a known state. The control connection may then be + restarted by the initiator. + + An invalid control message is defined as (1) a message that contains + a Message Type marked as mandatory (see Section 5.4.1) but that is + unknown to the implementation, or (2) a control message that is + received in the wrong state. + + Examples of malformed control messages include (1) a message that has + an invalid value in its header, (2) a message that contains an AVP + that is formatted incorrectly or whose value is out of range, and (3) + a message that is missing a required AVP. A control message with a + malformed header MUST be discarded. + + When possible, a malformed AVP should be treated as an unrecognized + AVP (see Section 5.2). Thus, an attempt to inspect the M bit SHOULD + be made to determine the importance of the malformed AVP, and thus, + the severity of the malformation to the entire control message. If + the M bit can be reasonably inspected within the malformed AVP and is + determined to be set, then as with an unrecognized AVP, the + associated session or control connection MUST be shut down. If the M + bit is inspected and is found to be 0, the AVP MUST be ignored + (assuming recovery from the AVP malformation is indeed possible). + + This policy must not be considered as a license to send malformed + AVPs, but rather, as a guide towards how to handle an improperly + formatted message if one is received. It is impossible to list all + potential malformations of a given message and give advice for each. + One example of a malformed AVP situation that should be recoverable + + + +Lau, et al. Standards Track [Page 68] + +RFC 3931 L2TPv3 March 2005 + + + is if the Rx Connect Speed AVP is received with a length of 10 rather + than 14, implying that the connect speed bits-per-second is being + formatted in 4 octets rather than 8. If the AVP does not have its M + bit set (as would typically be the case), this condition is not + considered catastrophic. As such, the control message should be + accepted as though the AVP were not present (though a local error + message may be logged). + + + In several cases in the following tables, a protocol message is sent, + and then a "clean up" occurs. Note that, regardless of the initiator + of the control connection destruction, the reliable delivery + mechanism must be allowed to run (see Section 4.2) before destroying + the control connection. This permits the control connection + management messages to be reliably delivered to the peer. + + Appendix B.1 contains an example of lock-step control connection + establishment. + +7.2. Control Connection States + + The L2TP control connection protocol is not distinguishable between + the two LCCEs but is distinguishable between the originator and + receiver. The originating peer is the one that first initiates + establishment of the control connection. (In a tie breaker + situation, this is the winner of the tie.) Since either the LAC or + the LNS can be the originator, a collision can occur. See the + Control Connection Tie Breaker AVP in Section 5.4.3 for a description + of this and its resolution. + + State Event Action New State + ----- ----- ------ --------- + idle Local open Send SCCRQ wait-ctl-reply + request + + idle Receive SCCRQ, Send SCCRP wait-ctl-conn + acceptable + + idle Receive SCCRQ, Send StopCCN, idle + not acceptable clean up + + idle Receive SCCRP Send StopCCN, idle + clean up + + idle Receive SCCCN Send StopCCN, idle + clean up + + + + + +Lau, et al. Standards Track [Page 69] + +RFC 3931 L2TPv3 March 2005 + + + wait-ctl-reply Receive SCCRP, Send SCCCN, established + acceptable send control-conn + open event to + waiting sessions + + wait-ctl-reply Receive SCCRP, Send StopCCN, idle + not acceptable clean up + + wait-ctl-reply Receive SCCRQ, Send SCCRP, wait-ctl-conn + lose tie breaker, Clean up losing + SCCRQ acceptable connection + + wait-ctl-reply Receive SCCRQ, Send StopCCN, idle + lose tie breaker, Clean up losing + SCCRQ unacceptable connection + + wait-ctl-reply Receive SCCRQ, Send StopCCN for wait-ctl-reply + win tie breaker losing connection + + wait-ctl-reply Receive SCCCN Send StopCCN, idle + clean up + + wait-ctl-conn Receive SCCCN, Send control-conn established + acceptable open event to + waiting sessions + + wait-ctl-conn Receive SCCCN, Send StopCCN, idle + not acceptable clean up + + wait-ctl-conn Receive SCCRQ, Send StopCCN, idle + SCCRP clean up + + established Local open Send control-conn established + request open event to + (new call) waiting sessions + + established Administrative Send StopCCN, idle + control-conn clean up + close event + + established Receive SCCRQ, Send StopCCN, idle + SCCRP, SCCCN clean up + + idle, Receive StopCCN Clean up idle + wait-ctl-reply, + wait-ctl-conn, + established + + + + +Lau, et al. Standards Track [Page 70] + +RFC 3931 L2TPv3 March 2005 + + + The states associated with an LCCE for control connection + establishment are as follows: + + idle + Both initiator and recipient start from this state. An initiator + transmits an SCCRQ, while a recipient remains in the idle state + until receiving an SCCRQ. + + wait-ctl-reply + The originator checks to see if another connection has been + requested from the same peer, and if so, handles the collision + situation described in Section 5.4.3. + + wait-ctl-conn + Awaiting an SCCCN. If the SCCCN is valid, the control connection + is established; otherwise, it is torn down (sending a StopCCN with + the proper result and/or error code). + + established + An established connection may be terminated by either a local + condition or the receipt of a StopCCN. In the event of a local + termination, the originator MUST send a StopCCN and clean up the + control connection. If the originator receives a StopCCN, it MUST + also clean up the control connection. + +7.3. Incoming Calls + + An ICRQ is generated by an LCCE, typically in response to an incoming + call or a local event. Once the LCCE sends the ICRQ, it waits for a + response from the peer. However, it may choose to postpone + establishment of the call (e.g., answering the call, bringing up the + circuit) until the peer has indicated with an ICRP that it will + accept the call. The peer may choose not to accept the call if, for + instance, there are insufficient resources to handle an additional + session. + + If the peer chooses to accept the call, it responds with an ICRP. + When the local LCCE receives the ICRP, it attempts to establish the + call. A final call connected message, the ICCN, is sent from the + local LCCE to the peer to indicate that the call states for both + LCCEs should enter the established state. If the call is terminated + before the peer can accept it, a CDN is sent by the local LCCE to + indicate this condition. + + When a call transitions to a "disconnected" or "down" state, the call + is cleared normally, and the local LCCE sends a CDN. Similarly, if + the peer wishes to clear a call, it sends a CDN and cleans up its + session. + + + +Lau, et al. Standards Track [Page 71] + +RFC 3931 L2TPv3 March 2005 + + +7.3.1. ICRQ Sender States + + State Event Action New State + ----- ----- ------ --------- + + idle Call signal or Initiate local wait-control-conn + ready to receive control-conn + incoming conn open + + idle Receive ICCN, Clean up idle + ICRP, CDN + + wait-control- Bearer line drop Clean up idle + conn or local close + request + + wait-control- control-conn-open Send ICRQ wait-reply + conn + + wait-reply Receive ICRP, Send ICCN established + acceptable + + wait-reply Receive ICRP, Send CDN, idle + Not acceptable clean up + + wait-reply Receive ICRQ, Process as idle + lose tie breaker ICRQ Recipient + (Section 7.3.2) + + wait-reply Receive ICRQ, Send CDN wait-reply + win tie breaker for losing + session + + wait-reply Receive CDN, Clean up idle + ICCN + + wait-reply Local close Send CDN, idle + request clean up + + established Receive CDN Clean up idle + + established Receive ICRQ, Send CDN, idle + ICRP, ICCN clean up + + established Local close Send CDN, idle + request clean up + + + + + +Lau, et al. Standards Track [Page 72] + +RFC 3931 L2TPv3 March 2005 + + + The states associated with the ICRQ sender are as follows: + + idle + The LCCE detects an incoming call on one of its interfaces (e.g., + an analog PSTN line rings, or an ATM PVC is provisioned), or a + local event occurs. The LCCE initiates its control connection + establishment state machine and moves to a state waiting for + confirmation of the existence of a control connection. + + wait-control-conn + In this state, the session is waiting for either the control + connection to be opened or for verification that the control + connection is already open. Once an indication that the control + connection has been opened is received, session control messages + may be exchanged. The first of these messages is the ICRQ. + + wait-reply + The ICRQ sender receives either (1) a CDN indicating the peer is + not willing to accept the call (general error or do not accept) + and moves back into the idle state, or (2) an ICRP indicating the + call is accepted. In the latter case, the LCCE sends an ICCN and + enters the established state. + + established + Data is exchanged over the session. The call may be cleared by + any of the following: + + An event on the connected interface: The LCCE sends a CDN. + + Receipt of a CDN: The LCCE cleans up, disconnecting the call. + + A local reason: The LCCE sends a CDN. + +7.3.2. ICRQ Recipient States + + State Event Action New State + ----- ----- ------ --------- + idle Receive ICRQ, Send ICRP wait-connect + acceptable + + idle Receive ICRQ, Send CDN, idle + not acceptable clean up + + idle Receive ICRP Send CDN idle + clean up + + idle Receive ICCN Clean up idle + + wait-connect Receive ICCN, Prepare for established + acceptable data + + + + +Lau, et al. Standards Track [Page 73] + +RFC 3931 L2TPv3 March 2005 + + + wait-connect Receive ICCN, Send CDN, idle + not acceptable clean up + + wait-connect Receive ICRQ, Send CDN, idle + ICRP clean up + + idle, Receive CDN Clean up idle + wait-connect, + established + + wait-connect Local close Send CDN, idle + established request clean up + + established Receive ICRQ, Send CDN, idle + ICRP, ICCN clean up + + The states associated with the ICRQ recipient are as follows: + + idle + An ICRQ is received. If the request is not acceptable, a CDN is + sent back to the peer LCCE, and the local LCCE remains in the idle + state. If the ICRQ is acceptable, an ICRP is sent. The session + moves to the wait-connect state. + + wait-connect + The local LCCE is waiting for an ICCN from the peer. Upon receipt + of the ICCN, the local LCCE moves to established state. + + established + The session is terminated either by sending a CDN or by receiving + a CDN from the peer. Clean up follows on both sides regardless of + the initiator. + +7.4. Outgoing Calls + + Outgoing calls instruct an LAC to place a call. There are three + messages for outgoing calls: OCRQ, OCRP, and OCCN. An LCCE first + sends an OCRQ to an LAC to request an outgoing call. The LAC MUST + respond to the OCRQ with an OCRP once it determines that the proper + facilities exist to place the call and that the call is + administratively authorized. Once the outbound call is connected, + the LAC sends an OCCN to the peer indicating the final result of the + call attempt. + + + + + + + + +Lau, et al. Standards Track [Page 74] + +RFC 3931 L2TPv3 March 2005 + + +7.4.1. OCRQ Sender States + + State Event Action New State + ----- ----- ------ --------- + idle Local open Initiate local wait-control-conn + request control-conn-open + + idle Receive OCCN, Clean up idle + OCRP + + wait-control- control-conn-open Send OCRQ wait-reply + conn + + wait-reply Receive OCRP, none wait-connect + acceptable + + wait-reply Receive OCRP, Send CDN, idle + not acceptable clean up + + wait-reply Receive OCCN Send CDN, idle + clean up + + wait-reply Receive OCRQ, Process as idle + lose tie breaker OCRQ Recipient + (Section 7.4.2) + + wait-reply Receive OCRQ, Send CDN wait-reply + win tie breaker for losing + session + + wait-connect Receive OCCN none established + + wait-connect Receive OCRQ, Send CDN, idle + OCRP clean up + + idle, Receive CDN Clean up idle + wait-reply, + wait-connect, + established + + established Receive OCRQ, Send CDN, idle + OCRP, OCCN clean up + + wait-reply, Local close Send CDN, idle + wait-connect, request clean up + established + + + + + +Lau, et al. Standards Track [Page 75] + +RFC 3931 L2TPv3 March 2005 + + + wait-control- Local close Clean up idle + conn request + + The states associated with the OCRQ sender are as follows: + + idle, wait-control-conn + When an outgoing call request is initiated, a control connection + is created as described above, if not already present. Once the + control connection is established, an OCRQ is sent to the LAC, and + the session moves into the wait-reply state. + + wait-reply + If a CDN is received, the session is cleaned up and returns to + idle state. If an OCRP is received, the call is in progress, and + the session moves to the wait-connect state. + + wait-connect + If a CDN is received, the session is cleaned up and returns to + idle state. If an OCCN is received, the call has succeeded, and + the session may now exchange data. + + established + If a CDN is received, the session is cleaned up and returns to + idle state. Alternatively, if the LCCE chooses to terminate the + session, it sends a CDN to the LAC, cleans up the session, and + moves the session to idle state. + +7.4.2. OCRQ Recipient (LAC) States + + State Event Action New State + ----- ----- ------ --------- + idle Receive OCRQ, Send OCRP, wait-cs-answer + acceptable Place call + + idle Receive OCRQ, Send CDN, idle + not acceptable clean up + + idle Receive OCRP Send CDN, idle + clean up + + idle Receive OCCN, Clean up idle + CDN + + wait-cs-answer Call placement Send OCCN established + successful + + wait-cs-answer Call placement Send CDN, idle + failed clean up + + + +Lau, et al. Standards Track [Page 76] + +RFC 3931 L2TPv3 March 2005 + + + wait-cs-answer Receive OCRQ, Send CDN, idle + OCRP, OCCN clean up + + established Receive OCRQ, Send CDN, idle + OCRP, OCCN clean up + + wait-cs-answer, Receive CDN Clean up idle + established + + wait-cs-answer, Local close Send CDN, idle + established request clean up + + The states associated with the LAC for outgoing calls are as follows: + + idle + If the OCRQ is received in error, respond with a CDN. Otherwise, + place the call, send an OCRP, and move to the wait-cs-answer + state. + + wait-cs-answer + If the call is not completed or a timer expires while waiting for + the call to complete, send a CDN with the appropriate error + condition set, and go to idle state. If a circuit-switched + connection is established, send an OCCN indicating success, and go + to established state. + + established + If the LAC receives a CDN from the peer, the call MUST be released + via appropriate mechanisms, and the session cleaned up. If the + call is disconnected because the circuit transitions to a + "disconnected" or "down" state, the LAC MUST send a CDN to the + peer and return to idle state. + +7.5. Termination of a Control Connection + + The termination of a control connection consists of either peer + issuing a StopCCN. The sender of this message SHOULD wait a full + control message retransmission cycle (e.g., 1 + 2 + 4 + 8 ... + seconds) for the acknowledgment of this message before releasing the + control information associated with the control connection. The + recipient of this message should send an acknowledgment of the + message to the peer, then release the associated control information. + + When to release a control connection is an implementation issue and + is not specified in this document. A particular implementation may + use whatever policy is appropriate for determining when to release a + control connection. Some implementations may leave a control + connection open for a period of time or perhaps indefinitely after + + + +Lau, et al. Standards Track [Page 77] + +RFC 3931 L2TPv3 March 2005 + + + the last session for that control connection is cleared. Others may + choose to disconnect the control connection immediately after the + last call on the control connection disconnects. + +8. Security Considerations + + This section addresses some of the security issues that L2TP + encounters in its operation. + +8.1. Control Connection Endpoint and Message Security + + If a shared secret (password) exists between two LCCEs, it may be + used to perform a mutual authentication between the two LCCEs, and + construct an authentication and integrity check of arriving L2TP + control messages. The mechanism provided by L2TPv3 is described in + Section 4.3 and in the definition of the Message Digest and Control + Message Authentication Nonce AVPs in Section 5.4.1. + + This control message security mechanism provides for (1) mutual + endpoint authentication, and (2) individual control message integrity + and authenticity checking. Mutual endpoint authentication ensures + that an L2TPv3 control connection is only established between two + endpoints that are configured with the proper password. The + individual control message and integrity check guards against + accidental or intentional packet corruption (i.e., those caused by a + control message spoofing or man-in-the-middle attack). + + The shared secret that is used for all control connection, control + message, and AVP security features defined in this document never + needs to be sent in the clear between L2TP tunnel endpoints. + +8.2. Data Packet Spoofing + + Packet spoofing for any type of Virtual Private Network (VPN) + protocol is of particular concern as insertion of carefully + constructed rogue packets into the VPN transit network could result + in a violation of VPN traffic separation, leaking data into a + customer VPN. This is complicated by the fact that it may be + particularly difficult for the operator of the VPN to even be aware + that it has become a point of transit into or between customer VPNs. + + L2TPv3 provides traffic separation for its VPNs via a 32-bit Session + ID in the L2TPv3 data header. When present, the L2TPv3 Cookie + (described in Section 4.1), provides an additional check to ensure + that an arriving packet is intended for the identified session. + Thus, use of a Cookie with the Session ID provides an extra guarantee + that the Session ID lookup was performed properly and that the + Session ID itself was not corrupted in transit. + + + +Lau, et al. Standards Track [Page 78] + +RFC 3931 L2TPv3 March 2005 + + + In the presence of a blind packet spoofing attack, the Cookie may + also provide security against inadvertent leaking of frames into a + customer VPN. To illustrate the type of security that it is provided + in this case, consider comparing the validation of a 64-bit Cookie in + the L2TPv3 header to the admission of packets that match a given + source and destination IP address pair. Both the source and + destination IP address pair validation and Cookie validation consist + of a fast check on cleartext header information on all arriving + packets. However, since L2TPv3 uses its own value, it removes the + requirement for one to maintain a list of (potentially several) + permitted or denied IP addresses, and moreover, to guard knowledge of + the permitted IP addresses from hackers who may obtain and spoof + them. Further, it is far easier to change a compromised L2TPv3 + Cookie than a compromised IP address," and a cryptographically random + [RFC1750] value is far less likely to be discovered by brute-force + attacks compared to an IP address. + + For protection against brute-force, blind, insertion attacks, a 64- + bit Cookie MUST be used with all sessions. A 32-bit Cookie is + vulnerable to brute-force guessing at high packet rates, and as such, + should not be considered an effective barrier to blind insertion + attacks (though it is still useful as an additional verification of a + successful Session ID lookup). The Cookie provides no protection + against a sophisticated man-in-the-middle attacker who can sniff and + correlate captured data between nodes for use in a coordinated + attack. + + The Assigned Cookie AVP is used to signal the value and size of the + Cookie that must be present in all data packets for a given session. + Each Assigned Cookie MUST be selected in a cryptographically random + manner [RFC1750] such that a series of Assigned Cookies does not + provide any indication of what a future Cookie will be. + + The L2TPv3 Cookie must not be regarded as a substitute for security + such as that provided by IPsec when operating over an open or + untrusted network where packets may be sniffed, decoded, and + correlated for use in a coordinated attack. See Section 4.1.3 for + more information on running L2TP over IPsec. + +9. Internationalization Considerations + + The Host Name and Vendor Name AVPs are not internationalized. The + Vendor Name AVP, although intended to be human-readable, would seem + to fit in the category of "globally visible names" [RFC2277] and so + is represented in US-ASCII. + + If (1) an LCCE does not signify a language preference by the + inclusion of a Preferred Language AVP (see Section 5.4.3) in the + + + +Lau, et al. Standards Track [Page 79] + +RFC 3931 L2TPv3 March 2005 + + + SCCRQ or SCCRP, (2) the Preferred Language AVP is unrecognized, or + (3) the requested language is not supported by the peer LCCE, the + default language [RFC2277] MUST be used for all internationalized + strings sent by the peer. + +10. IANA Considerations + + This document defines a number of "magic" numbers to be maintained by + the IANA. This section explains the criteria 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. + + Sections 10.1 through 10.3 are requests for new values already + managed by IANA according to [RFC3438]. + + The remaining sections are for new registries that have been added to + the existing L2TP registry and are maintained by IANA accordingly. + +10.1. Control Message Attribute Value Pairs (AVPs) + + This number space is managed by IANA as per [RFC3438]. + + A summary of the new AVPs follows: + + Control Message Attribute Value Pairs + + Attribute + Type Description + --------- ------------------ + + 58 Extended Vendor ID AVP + 59 Message Digest + 60 Router ID + 61 Assigned Control Connection ID + 62 Pseudowire Capabilities List + 63 Local Session ID + 64 Remote Session ID + 65 Assigned Cookie + 66 Remote End ID + 68 Pseudowire Type + 69 L2-Specific Sublayer + 70 Data Sequencing + 71 Circuit Status + 72 Preferred Language + 73 Control Message Authentication Nonce + 74 Tx Connect Speed + 75 Rx Connect Speed + + + +Lau, et al. Standards Track [Page 80] + +RFC 3931 L2TPv3 March 2005 + + +10.2. Message Type AVP Values + + This number space is managed by IANA as per [RFC3438]. There is one + new message type, defined in Section 3.1, that was allocated for this + specification: + + Message Type AVP (Attribute Type 0) Values + ------------------------------------------ + + Control Connection Management + + 20 (ACK) Explicit Acknowledgement + +10.3. Result Code AVP Values + + This number space is managed by IANA as per [RFC3438]. + + New Result Code values for the CDN message are defined in Section + 5.4. The following is a summary: + + Result Code AVP (Attribute Type 1) Values + ----------------------------------------- + + General Error Codes + + 13 - Session not established due to losing + tie breaker (L2TPv3). + 14 - Session not established due to unsupported + PW type (L2TPv3). + 15 - Session not established, sequencing required + without valid L2-Specific Sublayer (L2TPv3). + 16 - Finite state machine error or timeout. + + + + + + + + + + + + + + + + + + + +Lau, et al. Standards Track [Page 81] + +RFC 3931 L2TPv3 March 2005 + + +10.4. AVP Header Bits + + This is a new registry for IANA to maintain. + + Leading Bits of the L2TP AVP Header + ----------------------------------- + + There six bits at the beginning of the L2TP AVP header. New bits are + assigned via Standards Action [RFC2434]. + + Bit 0 - Mandatory (M bit) + Bit 1 - Hidden (H bit) + Bit 2 - Reserved + Bit 3 - Reserved + Bit 4 - Reserved + Bit 5 - Reserved + +10.5. L2TP Control Message Header Bits + + This is a new registry for IANA to maintain. + + Leading Bits of the L2TP Control Message Header + ----------------------------------------------- + + There are 12 bits at the beginning of the L2TP Control Message + Header. Reserved bits should only be defined by Standard + Action [RFC2434]. + + Bit 0 - Message Type (T bit) + Bit 1 - Length Field is Present (L bit) + Bit 2 - Reserved + Bit 3 - Reserved + Bit 4 - Sequence Numbers Present (S bit) + Bit 5 - Reserved + Bit 6 - Offset Field is Present [RFC2661] + Bit 7 - Priority Bit (P bit) [RFC2661] + Bit 8 - Reserved + Bit 9 - Reserved + Bit 10 - Reserved + Bit 11 - Reserved + + + + + + + + + + + +Lau, et al. Standards Track [Page 82] + +RFC 3931 L2TPv3 March 2005 + + +10.6. Pseudowire Types + + This is a new registry for IANA to maintain, there are no values + assigned within this document to maintain. + + L2TPv3 Pseudowire Types + ----------------------- + + The Pseudowire Type (PW Type, see Section 5.4) is a 2-octet value + used in the Pseudowire Type AVP and Pseudowire Capabilities List AVP + defined in Section 5.4.3. 0 to 32767 are assignable by Expert Review + [RFC2434], while 32768 to 65535 are assigned by a First Come First + Served policy [RFC2434]. There are no specific pseudowire types + assigned within this document. Each pseudowire-specific document + must allocate its own PW types from IANA as necessary. + +10.7. Circuit Status Bits + + This is a new registry for IANA to maintain. + + Circuit Status Bits + ------------------- + + The Circuit Status field is a 16-bit mask, with the two low order + bits assigned. Additional bits may be assigned by IETF Consensus + [RFC2434]. + + Bit 14 - New (N bit) + Bit 15 - Active (A bit) + + + + + + + + + + + + + + + + + + + + + + +Lau, et al. Standards Track [Page 83] + +RFC 3931 L2TPv3 March 2005 + + +10.8. Default L2-Specific Sublayer bits + + This is a new registry for IANA to maintain. + + Default L2-Specific Sublayer Bits + --------------------------------- + + The Default L2-Specific Sublayer contains 8 bits in the low-order + portion of the header. Reserved bits may be assigned by IETF + Consensus [RFC2434]. + + Bit 0 - Reserved + Bit 1 - Sequence (S bit) + Bit 2 - Reserved + Bit 3 - Reserved + Bit 4 - Reserved + Bit 5 - Reserved + Bit 6 - Reserved + Bit 7 - Reserved + +10.9. L2-Specific Sublayer Type + + This is a new registry for IANA to maintain. + + L2-Specific Sublayer Type + ------------------------- + + The L2-Specific Sublayer Type is a 2-octet unsigned integer. + Additional values may be assigned by Expert Review [RFC2434]. + + 0 - No L2-Specific Sublayer + 1 - Default L2-Specific Sublayer present + +10.10. Data Sequencing Level + + This is a new registry for IANA to maintain. + + Data Sequencing Level + --------------------- + + The Data Sequencing Level is a 2-octet unsigned integer + Additional values may be assigned by Expert Review [RFC2434]. + + 0 - No incoming data packets require sequencing. + 1 - Only non-IP data packets require sequencing. + 2 - All incoming data packets require sequencing. + + + + + +Lau, et al. Standards Track [Page 84] + +RFC 3931 L2TPv3 March 2005 + + +11. References + +11.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and + Languages", BCP 18, RFC 2277, January 1998. + + [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations section in RFCs", BCP 26, RFC 2434, + October 1998. + + [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 + Specification", RFC 2473, December 1998. + + [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., + and Palter, B., "Layer Two Tunneling Layer Two Tunneling + Protocol (L2TP)", RFC 2661, August 1999. + + [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, + "Remote Authentication Dial In User Service (RADIUS)", RFC + 2865, June 2000. + + [RFC3066] Alvestrand, H., "Tags for the Identification of Languages", + BCP 47, RFC 3066, January 2001. + + [RFC3193] Patel, B., Aboba, B., Dixon, W., Zorn, G., and Booth, S., + "Securing L2TP using IPsec", RFC 3193, November 2001. + + [RFC3438] Townsley, W., "Layer Two Tunneling Protocol (L2TP) Internet + Assigned Numbers Authority (IANA) Considerations Update", + BCP 68, RFC 3438, December 2002. + + [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", + STD 63, RFC 3629, November 2003. + +11.2. Informative References + + [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", + STD 13, RFC 1034, November 1987. + + [RFC1191] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191, + November 1990. + + [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, + April 1992. + + + +Lau, et al. Standards Track [Page 85] + +RFC 3931 L2TPv3 March 2005 + + + [RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD + 51, RFC 1661, July 1994. + + [RFC1700] Reynolds, J. and Postel, J., "Assigned Numbers", STD 2, RFC + 1700, October 1994. + + [RFC1750] Eastlake, D., Crocker, S., and Schiller, J., "Randomness + Recommendations for Security", RFC 1750, December 1994. + + [RFC1958] Carpenter, B., Ed., "Architectural Principles of the + Internet", RFC 1958, June 1996. + + [RFC1981] McCann, J., Deering, S., and Mogul, J., "Path MTU Discovery + for IP version 6", RFC 1981, August 1996. + + [RFC2072] Berkowitz, H., "Router Renumbering Guide", RFC 2072, + January 1997. + + [RFC2104] Krawczyk, H., Bellare, M., and Canetti, R., "HMAC: Keyed- + Hashing for Message Authentication", RFC 2104, February + 1997. + + [RFC2341] Valencia, A., Littlewood, M., and Kolar, T., "Cisco Layer + Two Forwarding (Protocol) L2F", RFC 2341, May 1998. + + [RFC2401] Kent, S. and Atkinson, R., "Security Architecture for the + Internet Protocol", RFC 2401, November 1998. + + [RFC2581] Allman, M., Paxson, V., and Stevens, W., "TCP Congestion + Control", RFC 2581, April 1999. + + [RFC2637] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W., + and Zorn, G., "Point-to-Point Tunneling Protocol (PPTP)", + RFC 2637, July 1999. + + [RFC2732] Hinden, R., Carpenter, B., and Masinter, L., "Format for + Literal IPv6 Addresses in URL's", RFC 2732, December 1999. + + [RFC2809] Aboba, B. and Zorn, G., "Implementation of L2TP Compulsory + Tunneling via RADIUS", RFC 2809, April 2000. + + [RFC3070] Rawat, V., Tio, R., Nanji, S., and Verma, R., "Layer Two + Tunneling Protocol (L2TP) over Frame Relay", RFC 3070, + February 2001. + + + + + + + +Lau, et al. Standards Track [Page 86] + +RFC 3931 L2TPv3 March 2005 + + + [RFC3355] Singh, A., Turner, R., Tio, R., and Nanji, S., "Layer Two + Tunnelling Protocol (L2TP) Over ATM Adaptation Layer 5 + (AAL5)", RFC 3355, August 2002. + + [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. + + [STEVENS] Stevens, W. Richard, "TCP/IP Illustrated, Volume I: The + Protocols", Addison-Wesley Publishing Company, Inc., March + 1996, ISBN 0-201-63346-9. + +12. Acknowledgments + + Many of the protocol constructs were originally defined in, and the + text of this document began with, RFC 2661, "L2TPv2". RFC 2661 + authors are W. Townsley, A. Valencia, A. Rubens, G. Pall, G. Zorn and + B. Palter. + + The basic concept for L2TP and many of its protocol constructs were + adopted from L2F [RFC2341] and PPTP [RFC2637]. Authors of these + versions are A. Valencia, M. Littlewood, T. Kolar, K. Hamzeh, G. + Pall, W. Verthein, J. Taarud, W. Little, and G. Zorn. + + Danny Mcpherson and Suhail Nanji published the first "L2TP Service + Type" version, which defined the use of L2TP for tunneling of various + L2 payload types (initially, Ethernet and Frame Relay). + + The team for splitting RFC 2661 into this base document and the + companion PPP document consisted of Ignacio Goyret, Jed Lau, Bill + Palter, Mark Townsley, and Madhvi Verma. Skip Booth also provided + very helpful review and comment. + + Some constructs of L2TPv3 were based in part on UTI (Universal + Transport Interface), which was originally conceived by Peter + Lothberg and Tony Bates. + + Stewart Bryant and Simon Barber provided valuable input for the + L2TPv3 over IP header. + + Juha Heinanen provided helpful review in the early stages of this + effort. + + Jan Vilhuber, Scott Fluhrer, David McGrew, Scott Wainner, Skip Booth + and Maria Dos Santos contributed to the Control Message + Authentication Mechanism as well as general discussions of security. + + + + + +Lau, et al. Standards Track [Page 87] + +RFC 3931 L2TPv3 March 2005 + + + James Carlson, Thomas Narten, Maria Dos Santos, Steven Bellovin, Ted + Hardie, and Pekka Savola provided very helpful review of the final + versions of text. + + Russ Housley provided valuable review and comment on security, + particularly with respect to the Control Message Authentication + mechanism. + + Pekka Savola contributed to proper alignment with IPv6 and inspired + much of Section 4.1.4 on fragmentation. + + Aside of his original influence and co-authorship of RFC 2661, Glen + Zorn helped get all of the language and character references straight + in this document. + + A number of people provided valuable input and effort for RFC 2661, + on which this document was based: + + 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 RFC 2661. + + Thomas Narten provided a great deal of critical review and + formatting. He wrote the first version of the IANA Considerations + section. + + Dory Leifer made valuable refinements to the protocol definition of + L2TP and contributed to the editing of early versions leading to RFC + 2661. + + Steve Cobb and Evan Caves redesigned the state machine tables. + Barney Wolff provided a great deal of design input on the original + endpoint authentication mechanism. + + + + + + + + + + + + + + + + + +Lau, et al. Standards Track [Page 88] + +RFC 3931 L2TPv3 March 2005 + + +Appendix A: Control Slow Start and Congestion Avoidance + + Although each side has indicated the maximum size of its receive + window, it is recommended that a slow start and congestion avoidance + method be used to transmit control packets. The methods described + here are based upon the TCP congestion avoidance algorithm as + described in Section 21.6 of TCP/IP Illustrated, Volume I, by W. + Richard Stevens [STEVENS] (this algorithm is also described in + [RFC2581]). + + Slow start and congestion avoidance make use of several variables. + The congestion window (CWND) defines the number of packets a sender + may send before waiting for an acknowledgment. The size of CWND + expands and contracts as described below. Note, however, that CWND + is never allowed to exceed the size of the advertised window obtained + from the Receive Window AVP. (In the text below, it is assumed any + increase will be limited by the Receive Window Size.) The variable + SSTHRESH determines when the sender switches from slow start to + congestion avoidance. Slow start is used while CWND is less than + SSHTRESH. + + A sender starts out in the slow start phase. CWND is initialized to + one packet, and SSHTRESH is initialized to the advertised window + (obtained from the Receive Window AVP). The sender then transmits + one packet and waits for its acknowledgment (either explicit or + piggybacked). When the acknowledgment is received, the congestion + window is incremented from one to two. During slow start, CWND is + increased by one packet each time an ACK (explicit ACK message or + piggybacked) is received. Increasing CWND by one on each ACK has the + effect of doubling CWND with each round trip, resulting in an + exponential increase. When the value of CWND reaches SSHTRESH, the + slow start phase ends and the congestion avoidance phase begins. + + During congestion avoidance, CWND expands more slowly. Specifically, + it increases by 1/CWND for every new ACK received. That is, CWND is + increased by one packet after CWND new ACKs have been received. + Window expansion during the congestion avoidance phase is effectively + linear, with CWND increasing by one packet each round trip. + + When congestion occurs (indicated by the triggering of a + retransmission) one-half of the CWND is saved in SSTHRESH, and CWND + is set to one. The sender then reenters the slow start phase. + + + + + + + + + +Lau, et al. Standards Track [Page 89] + +RFC 3931 L2TPv3 March 2005 + + +Appendix B: Control Message Examples + +B.1: Lock-Step Control Connection Establishment + + In this example, an LCCE establishes a control connection, with the + exchange involving each side alternating in sending messages. This + example shows the final acknowledgment explicitly sent within an ACK + message. An alternative would be to piggyback the acknowledgment + within a message sent as a reply to the ICRQ or OCRQ that will likely + follow from the side that initiated the control connection. + + LCCE A LCCE B + ------ ------ + SCCRQ -> + Nr: 0, Ns: 0 + <- SCCRP + Nr: 1, Ns: 0 + SCCCN -> + Nr: 1, Ns: 1 + <- ACK + Nr: 2, Ns: 1 + +B.2: Lost Packet with Retransmission + + An existing control connection has a new session requested by LCCE A. + The ICRP is lost and must be retransmitted by LCCE B. Note that loss + of the ICRP has two effects: It not only keeps the upper level state + machine from progressing, but also keeps LCCE A from seeing a timely + lower level acknowledgment of its ICRQ. + + LCCE A LCCE B + ------ ------ + ICRQ -> + Nr: 1, Ns: 2 + (packet lost) <- ICRP + Nr: 3, Ns: 1 + + (pause; LCCE A's timer started first, so fires first) + + ICRQ -> + Nr: 1, Ns: 2 + + (Realizing that it has already seen this packet, + LCCE B discards the packet and sends an ACK message) + + <- ACK + Nr: 3, Ns: 2 + + + + +Lau, et al. Standards Track [Page 90] + +RFC 3931 L2TPv3 March 2005 + + + (LCCE B's retransmit timer fires) + + <- ICRP + Nr: 3, Ns: 1 + ICCN -> + Nr: 2, Ns: 3 + + <- ACK + Nr: 4, Ns: 2 + +Appendix C: Processing Sequence Numbers + + The Default L2-Specific Sublayer, defined in Section 4.6, provides a + 24-bit field for sequencing of data packets within an L2TP session. + L2TP data packets are never retransmitted, so this sequence is used + only to detect packet order, duplicate packets, or lost packets. + + The 24-bit Sequence Number field of the Default L2-Specific Sublayer + contains a packet sequence number for the associated session. Each + sequenced data packet that is sent must contain the sequence number, + incremented by one, of the previous sequenced packet sent on a given + L2TP session. Upon receipt, any packet with a sequence number equal + to or greater than the current expected packet (the last received + in-order packet plus one) should be considered "new" and accepted. + All other packets are considered "old" or "duplicate" and discarded. + Note that the 24-bit sequence number space includes zero as a valid + sequence number (as such, it may be implemented with a masked 32-bit + counter if desired). All new sessions MUST begin sending sequence + numbers at zero. + + Larger or smaller sequence number fields are possible with L2TP if an + alternative format to the Default L2-Specific Sublayer defined in + this document is used. While 24 bits may be adequate in a number of + circumstances, a larger sequence number space will be less + susceptible to sequence number wrapping problems for very high + session data rates across long dropout periods. The sequence number + processing recommendations below should hold for any size sequence + number field. + + When detecting whether a packet sequence number is "greater" or + "less" than a given sequence number value, wrapping of the sequence + number must be considered. This is typically accomplished by keeping + a window of sequence numbers beyond the current expected sequence + number for determination of whether a packet is "new" or not. The + window may be sized based on the link speed and sequence number space + and SHOULD be configurable with a default equal to one half the size + of the available number space (e.g., 2^(n-1), where n is the number + of bits available in the sequence number). + + + +Lau, et al. Standards Track [Page 91] + +RFC 3931 L2TPv3 March 2005 + + + Upon receipt, packets that exactly match the expected sequence number + are processed immediately and the next expected sequence number + incremented. Packets that fall within the window for new packets may + either be processed immediately and the next expected sequence number + updated to one plus that received in the new packet, or held for a + very short period of time in hopes of receiving the missing + packet(s). This "very short period" should be configurable, with a + default corresponding to a time lapse that is at least an order of + magnitude less than the retransmission timeout periods of higher + layer protocols such as TCP. + + For typical transient packet mis-orderings, dropping out-of-order + packets alone should suffice and generally requires far less + resources than actively reordering packets within L2TP. An exception + is a case in which a pair of packet fragments are persistently + retransmitted and sent out-of-order. For example, if an IP packet + has been fragmented into a very small packet followed by a very large + packet before being tunneled by L2TP, it is possible (though + admittedly wrong) that the two resulting L2TP packets may be + consistently mis-ordered by the PSN in transit between L2TP nodes. + If sequence numbers were being enforced at the receiving node without + any buffering of out-of-order packets, then the fragmented IP packet + may never reach its destination. It may be worth noting here that + this condition is true for any tunneling mechanism of IP packets that + includes sequence number checking on receipt (i.e., GRE [RFC2890]). + + Utilization of a Data Sequencing Level (see Section 5.4.3) of 1 (only + non-IP data packets require sequencing) allows IP data packets being + tunneled by L2TP to not utilize sequence numbers, while utilizing + sequence numbers and enforcing packet order for any remaining non-IP + data packets. Depending on the requirements of the link layer being + tunneled and the network data traversing the data link, this is + sufficient in many cases to enforce packet order on frames that + require it (such as end-to-end data link control messages), while not + on IP packets that are known to be resilient to packet reordering. + + If a large number of packets (i.e., more than one new packet window) + are dropped due to an extended outage or loss of sequence number + state on one side of the connection (perhaps as part of a forwarding + plane reset or failover to a standby node), it is possible that a + large number of packets will be sent in-order, but be wrongly + detected by the peer as out-of-order. This can be generally + characterized for a window size, w, sequence number space, s, and + number of packets lost in transit between L2TP endpoints, p, as + follows: + + + + + + +Lau, et al. Standards Track [Page 92] + +RFC 3931 L2TPv3 March 2005 + + + If s > p > w, then an additional (s - p) packets that were otherwise + received in-order, will be incorrectly classified as out-of-order and + dropped. Thus, for a sequence number space, s = 128, window size, w + = 64, and number of lost packets, p = 70; 128 - 70 = 58 additional + packets would be dropped after the outage until the sequence number + wrapped back to the current expected next sequence number. + + To mitigate this additional packet loss, one MUST inspect the + sequence numbers of packets dropped due to being classified as "old" + and reset the expected sequence number accordingly. This may be + accomplished by counting the number of "old" packets dropped that + were in sequence among themselves and, upon reaching a threshold, + resetting the next expected sequence number to that seen in the + arriving data packets. Packet timestamps may also be used as an + indicator to reset the expected sequence number by detecting a period + of time over which "old" packets have been received in-sequence. The + ideal thresholds will vary depending on link speed, sequence number + space, and link tolerance to out-of-order packets, and MUST be + configurable. + +Editors' Addresses + + Jed Lau + cisco Systems + 170 W. Tasman Drive + San Jose, CA 95134 + + EMail: jedlau@cisco.com + + + W. Mark Townsley + cisco Systems + + EMail: mark@townsley.net + + + Ignacio Goyret + Lucent Technologies + + EMail: igoyret@lucent.com + + + + + + + + + + + +Lau, et al. Standards Track [Page 93] + +RFC 3931 L2TPv3 March 2005 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2005). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM 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. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Lau, et al. Standards Track [Page 94] + |