diff options
Diffstat (limited to 'rfc/rfc3931.txt')
| -rw-r--r-- | rfc/rfc3931.txt | 5267 |
1 files changed, 5267 insertions, 0 deletions
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] + |