RFC 2661
Layer Two Tunneling Protocol "L2TP"
Layer Two Tunneling Protocol "L2TP" 🎀
Okay bestie, this is RFC 2661 💅 It's an August 1999 Standards Track doc from the Network Working Group, and it's written by W. Townsley (cisco Systems), A. Valencia (cisco Systems), A. Rubens (Ascend Communications), G. Pall and G. Zorn (Microsoft Corporation), and B. Palter (Redback Networks). Main character energy, the whole author squad 🦋
Status of this Memo ✨
ngl this part is a bit formal, but it matters 🫶 The doc specifies an Internet standards track protocol for the Internet community, and it's literally asking for discussion and suggestions for improvements. For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 💖
Copyright Notice 💜
Copyright (C) The Internet Society (1999). All Rights Reserved.
Abstract 🌸
So this doc describes the Layer Two Tunneling Protocol (L2TP) 🧚 STD 51, RFC 1661 specifies multi-protocol access via PPP [RFC1661]. L2TP facilitates the tunneling of PPP packets across an intervening network, and it's as transparent as possible to both end-users and applications. Iconic ✨
Table of Contents 🍓
1.0 Introduction.......................................... 3
1.1 Specification of Requirements......................... 4
1.2 Terminology........................................... 4
2.0 Topology.............................................. 8
3.0 Protocol Overview..................................... 9
3.1 L2TP Header Format.................................... 9
3.2 Control Message Types................................. 11
4.0 Control Message Attribute Value Pairs................. 12
4.1 AVP Format............................................ 13
4.2 Mandatory AVPs........................................ 14
4.3 Hiding of AVP Attribute Values........................ 14
4.4 AVP Summary........................................... 17
4.4.1 AVPs Applicable To All Control Messages.......... 17
4.4.2 Result and Error Codes........................... 18
4.4.3 Control Connection Management AVPs............... 20
4.4.4 Call Management AVPs............................. 27
4.4.5 Proxy LCP and Authentication AVPs................ 34
4.4.6 Call Status AVPs................................. 39
5.0 Protocol Operation.................................... 41
5.1 Control Connection Establishment...................... 41
5.1.1 Tunnel Authentication............................ 42
5.2 Session Establishment................................. 42
5.2.1 Incoming Call Establishment...................... 42
5.2.2 Outgoing Call Establishment...................... 43
5.3 Forwarding PPP Frames................................. 43
5.4 Using Sequence Numbers on the Data Channel............ 44
5.5 Keepalive (Hello)..................................... 44
5.6 Session Teardown...................................... 45
5.7 Control Connection Teardown........................... 45
5.8 Reliable Delivery of Control Messages................. 46
6.0 Control Connection Protocol Specification............. 48
6.1 Start-Control-Connection-Request (SCCRQ).............. 48
6.2 Start-Control-Connection-Reply (SCCRP)................ 48
6.3 Start-Control-Connection-Connected (SCCCN)............ 49
6.4 Stop-Control-Connection-Notification (StopCCN)........ 49
6.5 Hello (HELLO)......................................... 49
6.6 Incoming-Call-Request (ICRQ).......................... 50
6.7 Incoming-Call-Reply (ICRP)............................ 51
6.8 Incoming-Call-Connected (ICCN)........................ 51
6.9 Outgoing-Call-Request (OCRQ).......................... 52
6.10 Outgoing-Call-Reply (OCRP)........................... 53
6.11 Outgoing-Call-Connected (OCCN)....................... 53
6.12 Call-Disconnect-Notify (CDN)......................... 53
6.13 WAN-Error-Notify (WEN)............................... 54
6.14 Set-Link-Info (SLI).................................. 54
7.0 Control Connection State Machines..................... 54
7.1 Control Connection Protocol Operation................. 55
7.2 Control Connection States............................. 56
7.2.1 Control Connection Establishment................. 56
7.3 Timing considerations................................. 58
7.4 Incoming calls........................................ 58
7.4.1 LAC Incoming Call States......................... 60
7.4.2 LNS Incoming Call States......................... 62
7.5 Outgoing calls........................................ 63
7.5.1 LAC Outgoing Call States......................... 64
7.5.2 LNS Outgoing Call States......................... 66
7.6 Tunnel Disconnection.................................. 67
8.0 L2TP Over Specific Media.............................. 67
8.1 L2TP over UDP/IP...................................... 68
8.2 IP.................................................... 69
9.0 Security Considerations............................... 69
9.1 Tunnel Endpoint Security.............................. 70
9.2 Packet Level Security................................. 70
9.3 End to End Security................................... 70
9.4 L2TP and IPsec........................................ 71
9.5 Proxy PPP Authentication.............................. 71
10.0 IANA Considerations.................................. 71
10.1 AVP Attributes....................................... 71
10.2 Message Type AVP Values.............................. 72
10.3 Result Code AVP Values............................... 72
10.3.1 Result Code Field Values........................ 72
10.3.2 Error Code Field Values......................... 72
10.4 Framing Capabilities & Bearer Capabilities........... 72
10.5 Proxy Authen Type AVP Values......................... 72
10.6 AVP Header Bits...................................... 73
11.0 References........................................... 73
12.0 Acknowledgments...................................... 74
13.0 Authors' Addresses................................... 75
Appendix A: Control Channel Slow Start and Congestion
Avoidance..................................... 76
Appendix B: Control Message Examples...................... 77
Appendix C: Intellectual Property Notice.................. 79
Full Copyright Statement.................................. 801.0 Introduction 🦋
Okay so PPP [RFC1661] is the encapsulation mechanism for transporting multiprotocol packets across layer 2 (L2) point-to-point links. Usually a user gets an L2 connection to a Network Access Server (NAS) using one of a bunch of techniques (e.g., dialup POTS, ISDN, ADSL, etc.), and then runs PPP over that connection. In that setup, the L2 termination point and the PPP session endpoint live on the same physical device (i.e., the NAS) 💅
L2TP glows up the PPP model ✨ by letting the L2 and PPP endpoints live on different devices that are connected by a packet-switched network. With L2TP, the user has an L2 connection to an access concentrator (e.g., modem bank, ADSL DSLAM, etc.), and the concentrator then tunnels individual PPP frames to the NAS. This lets the actual processing of PPP packets get divorced from the termination of the L2 circuit. It's giving separation of concerns 🫶
One obvious benefit is that the L2 connection doesn't have to terminate at the NAS (which may come with a long-distance toll charge). Instead, it can terminate at a (local) circuit concentrator, which then extends the logical PPP session over shared infrastructure like a frame relay circuit or the Internet. From the user's perspective, there is no functional difference between having the L2 circuit terminate in a NAS directly or using L2TP. Iconic invisibility, no notes 🌈
L2TP may also solve the multilink hunt-group splitting problem 🔥 Multilink PPP [RFC1990] requires that all channels composing a multilink bundle be grouped at a single Network Access Server (NAS). Because L2TP can project a PPP session to a location other than the point where it was physically received, it can make all the channels terminate at a single NAS. That means multilink still works even when the calls are spread across distinct physical NASs 👑
This document defines the necessary control protocol for on-demand creation of tunnels between two nodes, plus the accompanying encapsulation for multiplexing multiple tunneled PPP sessions. Obsessed with this design, honestly 💜
1.1 Specification of Requirements 🎀
Here's the bit about the all-caps words 🙈 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]. Those are the official meanings, so no vibes-based interpretation allowed 💀
to be continued in part 2 🦋
1.2 Terminology 📖✨
okay bestie, here are the key terms you need to know before we go any further 💅
Analog Channel
a circuit-switched communication path meant to carry 3.1 kHz audio in each direction 🎧
Attribute Value Pair (AVP)
the variable length concatenation of a unique Attribute (represented by an integer) and a Value holding the actual value that the attribute identifies. multiple AVPs make up Control Messages, which are used to establish, maintain, and tear down tunnels 🔧
Call
a connection (or attempted connection) between a Remote System and LAC. for example, a telephone call through the PSTN 📞 a Call (Incoming or Outgoing) that is successfully established between a Remote System and LAC results in a matching L2TP Session inside a tunnel that was already set up between the LAC and LNS. (See also: Session, Incoming Call, Outgoing Call).
Called Number
an indication to the receiver of a call of which telephone number the caller used to reach it 📱
Calling Number
an indication to the receiver of a call of the telephone number of the caller 🫶
CHAP
Challenge Handshake Authentication Protocol [RFC1994], a PPP cryptographic challenge/response authentication protocol in which the cleartext password is not passed over the line 🔐
Control Connection
a control connection runs in-band over a tunnel to handle establishing, releasing, and maintaining sessions and the tunnel itself 🎀
Control Messages
control messages get swapped between LAC and LNS pairs, running in-band within the tunnel protocol. they govern aspects of the tunnel and of the sessions inside it 🧚
Digital Channel
a circuit-switched communication path meant to carry digital information in each direction 💻
DSLAM
Digital Subscriber Line (DSL) Access Module. a network device used in deploying DSL service. it's typically a concentrator of individual DSL lines located in a central office (CO) or local exchange 🏢
Incoming Call
a Call received at an LAC to be tunneled to an LNS (see Call, Outgoing Call) 📥
L2TP Access Concentrator (LAC)
a node that acts as one side of an L2TP tunnel endpoint and is a peer to the L2TP Network Server (LNS). the LAC sits between an LNS and a remote system and forwards packets to and from each. packets sent from the LAC to the LNS require tunneling with the L2TP protocol as defined in this document. the connection from the LAC to the remote system is either local (see: Client LAC) or a PPP link 🌸
L2TP Network Server (LNS)
a node that acts as one side of an L2TP tunnel endpoint and is a peer to the L2TP Access Concentrator (LAC). the LNS is the logical termination point of a PPP session that is being tunneled from the remote system by the LAC 👑
Management Domain (MD)
a network or networks under the control of a single administration, policy, or system. for example, an LNS's Management Domain might be the corporate network it serves, and an LAC's Management Domain might be the Internet Service Provider that owns and manages it 🦋
Network Access Server (NAS)
a device that gives users local network access across a remote access network such as the PSTN. an NAS may also serve as an LAC, an LNS, or both 🌈
Outgoing Call
a Call placed by an LAC on behalf of an LNS (see Call, Incoming Call) 📤
Peer
in the context of L2TP, peer refers to either the LAC or the LNS. an LAC's Peer is an LNS, and vice versa. in the context of PPP, a peer is either side of the PPP connection 🤝
POTS
Plain Old Telephone Service 📻
Remote System
an end-system or router attached to a remote access network (i.e. a PSTN), which is either the initiator or the recipient of a call. also referred to as a dial-up or virtual dial-up client 💜
Session
L2TP is connection-oriented. the LNS and LAC keep state for each Call that is initiated or answered by an LAC. an L2TP Session is created between the LAC and LNS when an end-to-end PPP connection is established between a Remote System and the LNS. datagrams related to the PPP connection are sent over the Tunnel between the LAC and LNS. there is a one to one relationship between established L2TP Sessions and their associated Calls. (See also: Call) ✨
Tunnel
a Tunnel exists between a LAC-LNS pair. the Tunnel consists of a Control Connection and zero or more L2TP Sessions. the Tunnel carries encapsulated PPP datagrams and Control Messages between the LAC and the LNS 🚇
Zero-Length Body (ZLB) Message
a control packet with only an L2TP header. ZLB messages are used to explicitly acknowledge packets on the reliable control channel 🙈
2.0 Topology 🗺️
here's the typical L2TP setup 👀 the goal is to tunnel PPP frames between the Remote System (or LAC Client) and an LNS sitting on a Home LAN.
[Home LAN]
[LAC Client]----------+ |
____|_____ +--[Host]
| | |
[LAC]---------| Internet |-----[LNS]-----+
| |__________| |
_____|_____ :
| |
| PSTN |
[Remote]--| Cloud |
[System] | | [Home LAN]
|___________| |
| ______________ +---[Host]
| | | |
[LAC]-------| Frame Relay |---[LNS]-----+
| or ATM Cloud | |
|______________| :the Remote System starts a PPP connection across the PSTN Cloud to an LAC. the LAC then tunnels that PPP connection across the Internet, Frame Relay, or ATM Cloud to an LNS, and that's how you get access to a Home LAN 🏠 the Remote System gets its addresses from the HOME LAN via PPP NCP negotiation. Authentication, Authorization and Accounting may be provided by the Home LAN's Management Domain, as if the user were connected to a Network Access Server directly 🔑
a LAC Client (a Host that runs L2TP natively) can also join the tunneling to the Home LAN without a separate LAC 💻 in this case, the Host holding the LAC Client software already has a connection to the public Internet. a "virtual" PPP connection is then created, and the local L2TP LAC Client software builds a tunnel to the LNS. just like the case above, Addressing, Authentication, Authorization and Accounting will be provided by the Home LAN's Management Domain 🫶
3.0 Protocol Overview 🧠
L2TP uses two types of messages: control messages and data messages 💖 control messages handle establishing, maintaining, and clearing tunnels and calls. data messages encapsulate the PPP frames being carried over the tunnel. control messages use a reliable Control Channel within L2TP to guarantee delivery (see section 5.1 for details). data messages are not retransmitted when packet loss occurs 😭
+-------------------+
| PPP Frames |
+-------------------+ +-----------------------+
| L2TP Data Messages| | L2TP Control Messages |
+-------------------+ +-----------------------+
| L2TP Data Channel | | L2TP Control Channel |
| (unreliable) | | (reliable) |
+------------------------------------------------+
| Packet Transport (UDP, FR, ATM, etc.) |
+------------------------------------------------+Figure 3.0 L2TP Protocol Structure
Figure 3.0 shows how PPP frames and Control Messages relate across the L2TP Control and Data Channels ✨ PPP Frames go over an unreliable Data Channel, encapsulated first by an L2TP header and then by a Packet Transport such as UDP, Frame Relay, ATM, etc. Control messages are sent over a reliable L2TP Control Channel, which transmits packets in-band over the same Packet Transport 🌈
sequence numbers are required to be present in all control messages, and they're what provides reliable delivery on the Control Channel 🔥 data messages may use sequence numbers to reorder packets and detect lost packets 🧚
all values are placed into their respective fields and sent in network order (high order octets first) 💅
3.1 L2TP Header Format ✨
okay so bestie, L2TP packets for the control channel and data channel share the SAME header format 🫶 super efficient. Anywhere a field is optional, its space just doesn't exist in the message if it's marked not present 🦋 But here's the twist: even though Length, Ns, and Nr are optional on data messages, they are required to be present on ALL control messages 💅
This is the header layout:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|L|x|x|S|x|O|P|x|x|x|x| Ver | Length (opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tunnel ID | Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ns (opt) | Nr (opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset Size (opt) | Offset pad... (opt)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 3.1 L2TP Message Header 🌸
Let's break down the bits, because this is where the drama is 😭
The Type (T) bit tells you what kind of message you're looking at. It's 0 for a data message and 1 for a control message. Main character energy ✨
The Length (L) bit = if it's 1, the Length field is there. This bit MUST be set to 1 for control messages. No exceptions, periodt 💀
The x bits are reserved for future extensions 🔮 All reserved bits MUST be set to 0 on outgoing messages and ignored on incoming messages. Be nice to your future self.
The Sequence (S) bit: if it's set to 1, the Ns and Nr fields are present. The S bit MUST be set to 1 for control messages. Obsessed with how consistent this is 🙈
The Offset (O) bit: if it's 1, the Offset Size field is present. The O bit MUST be set to 0 (zero) for control messages. Control messages are NOT doing offsets, bestie 🚫
The Priority (P) bit: if it's 1, this data message should receive preferential treatment in its local queuing and transmission. LCP echo requests used as a keepalive for the link, for instance, should generally be sent with this bit set to 1. Without it, a temporary interval of local congestion could interfere with keepalive messages and cause unnecessary loss of the link, which is so not it 😤 This feature is only for use with data messages. The P bit MUST be set to 0 for all control messages. 🧚
The Ver field MUST be 2, indicating the version of the L2TP data message header described in this document. The value 1 is reserved so you can detect L2F [RFC2341] packets if they show up mixed in with L2TP packets 🕵️♀️ Packets received with an unknown Ver field MUST be discarded. Bye bye 👋
The Length field indicates the total length of the message in octets. Simple, iconic 🍓
The Tunnel ID is the identifier for the control connection. L2TP tunnels are named by identifiers that have local significance only. That means the same tunnel gets a different Tunnel ID at each end of it, which is giving "same song, different playlist" 🎀 The Tunnel ID in each message is that of the intended recipient, NOT the sender (so always check who it's for!). Tunnel IDs get selected and exchanged as Assigned Tunnel ID AVPs when a tunnel is being created 🦋
The Session ID is the identifier for a session within a tunnel. Same deal as tunnels: L2TP sessions are named by identifiers with local significance only, so each end of the session gets its own Session ID 💜 The Session ID in each message is that of the intended recipient, not the sender. Session IDs are selected and exchanged as Assigned Session ID AVPs when a session is created 🌈
The Ns field is the sequence number for this data or control message. It begins at zero and goes up by one (modulo 2**16) for each message sent. See Section 5.8 and 5.4 for more information on using this field 📚
The Nr field is the sequence number expected in the next control message to be received. So Nr is set to the Ns of the last in-order message received plus one (modulo 2**16). In data messages, Nr is reserved and, if present (as indicated by the S-bit), MUST be ignored upon receipt. See Section 5.8 for more information on using this field in control messages 💅
Last but not least, the Offset Size field, if present, specifies the number of octets past the L2TP header where the payload data is expected to start. The actual data inside the offset padding is undefined, so don't read into it 🙈 If the offset field is present, the L2TP header ends after the last octet of the offset padding. Done and dusted 🫶
3.2 Control Message Types 🎀
The Message Type AVP (see section 4.4.1) defines the specific type of control message being sent. Recall from section 3.1 that this is only for control messages, meaning messages with the T-bit set to 1 🦋
This document defines the following control message types (see Section 6.1 through 6.14 for details on the construction and use of each message). Here's the whole squad 👑
Control Connection Management
0 (reserved)
1 (SCCRQ) Start-Control-Connection-Request
2 (SCCRP) Start-Control-Connection-Reply
3 (SCCCN) Start-Control-Connection-Connected
4 (StopCCN) Stop-Control-Connection-Notification
5 (reserved)
6 (HELLO) Hello
Call Management
7 (OCRQ) Outgoing-Call-Request
8 (OCRP) Outgoing-Call-Reply
9 (OCCN) Outgoing-Call-Connected
10 (ICRQ) Incoming-Call-Request
11 (ICRP) Incoming-Call-Reply
12 (ICCN) Incoming-Call-Connected
13 (reserved)
14 (CDN) Call-Disconnect-Notify
Error Reporting
15 (WEN) WAN-Error-Notify
PPP Session Control
16 (SLI) Set-Link-Info4.0 Control Message Attribute Value Pairs 💜
To maximize extensibility while still allowing interoperability, there's a uniform method for encoding message types and bodies used throughout L2TP. This encoding is termed AVP (Attribute-Value Pair) for the rest of this document. Think of it as the universal tote bag of L2TP 👜✨
4.1 AVP Format 🧚
Each AVP is encoded like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H| rsvd | Length | Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Type | Attribute Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
[until Length is reached]... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The first six bits are a bit mask describing the general attributes of the AVP. 🌸
Only two bits are defined in this document. The rest are reserved for future extensions. Reserved bits MUST be set to 0. An AVP received with a reserved bit set to 1 MUST be treated as an unrecognized AVP. Rude 🙅♀️
Here's where it gets spicy. The M bit controls what an implementation has to do when it gets an AVP it doesn't recognize. If the M bit is set on an unrecognized AVP inside a message tied to a particular session, that session MUST be terminated. If the M bit is set on an unrecognized AVP inside a message tied to the overall tunnel, the entire tunnel (and all sessions inside it) MUST be terminated. If the M bit is NOT set, the unrecognized AVP MUST be ignored, and the control message just keeps being processed as if that AVP was never there 💅
The H bit identifies hiding of data in the Attribute Value field of an AVP. This is handy for keeping sensitive stuff, like user passwords, from being sent as cleartext in an AVP 🔐 Section 4.3 describes the procedure for doing AVP hiding.
The Length field encodes the number of octets (including the Overall Length and bitmask fields) in this AVP. It can be calculated as 6 + the length of the Attribute Value field in octets. The field itself is 10 bits, so the max is 1023 octets of data in a single AVP. The minimum Length of an AVP is 6, and if the length is 6, the Attribute Value field is absent 🍓
The Vendor ID is the IANA assigned "SMI Network Management Private Enterprise Codes" [RFC1700] value. The value 0, which corresponds to IETF adopted attribute values, is used for all AVPs defined within this document. Any vendor who wants to build their own L2TP extensions can use their own Vendor ID along with private Attribute values, which guarantees they won't collide with any other vendor's extensions or with future IETF extensions 🌈 Note that 16 bits are allocated for the Vendor ID, so this feature is limited to the first 65,535 enterprises. Big club, still limited 🦋
The Attribute Type is a 2 octet value with a unique interpretation across all AVPs defined under a given Vendor ID 🎀
The Attribute Value is the actual value, as indicated by the Vendor ID and Attribute Type. It comes right after the Attribute Type field and runs for the remaining octets indicated in the Length (that's Length minus 6 octets of header). This field is absent if the Length is 6 🫶
4.2 Mandatory AVPs 😭
Receiving an unknown AVP that has the M-bit set is catastrophic to the session or tunnel it's associated with. So the M bit should only be defined for AVPs which are absolutely crucial to proper operation of the session or tunnel. Also, if the LAC or LNS receives an unknown AVP with the M-bit set and shuts down the session or tunnel because of it, it is the full responsibility of the peer that sent the Mandatory AVP to accept the blame for causing a non-interoperable situation. Before defining an AVP with the M-bit set, especially a vendor-specific one, make sure that's the intended consequence 🙈
When there's an adequate alternative to using the M-bit, it should be used. For example, rather than just sending an AVP with the M-bit set to find out whether a specific extension exists, you can find out whether it's available by sending an AVP in a request message and expecting a corresponding AVP in a reply message. Much more polite 💖
Use of the M-bit with new AVPs (those not defined in this document) MUST provide the ability to configure the associated feature off, so the AVP is either not sent, or sent with the M-bit not set. Give people an off switch, fr fr 🌸
4.3 Hiding of AVP Attribute Values 🔐
okay bestie, the H bit in every AVP header is basically a "this one's private 🙈" flag. It tells the receiving peer whether the AVP contents are hidden or sitting there in cleartext. This is how you keep sensitive stuff like user passwords or user IDs from being readable ✨
🚨 The H bit MUST only be set if a shared secret exists between the LAC and LNS. It's the same secret used for tunnel authentication (see Section 5.1.1). If the H bit is set in any AVP(s) in a given control message, a Random Vector AVP must also be present in the message and MUST precede the first AVP having an H bit of 1. no skipping that step 💅
Hiding an AVP value happens in a few steps. First, you take the length and value fields of the original (cleartext) AVP and encode them into a Hidden AVP Subformat, like this:
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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Here's what each piece does 🧁
- Length of Original Attribute Value: the length of the Original Attribute Value you're trying to obscure, in octets. This is needed so the original length can still be figured out, even though it gets lost once the extra Padding is added.
- Original Attribute Value: the Attribute Value that's getting obscured.
- Padding: random extra octets used to hide the length of the Attribute Value being hidden.
To mask the size of the hidden data, 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 it DOES change the length of the resulting AVP 📏 For example, say an Attribute Value to be hidden is 4 octets. The unhidden AVP length would be 10 octets (6 + Attribute Value length). After hiding, the AVP length becomes 6 + Attribute Value length + size of the Length of Original Attribute Value field + Padding. So if Padding is 12 octets, the AVP length is 6 + 4 + 2 + 12 = 24 octets.
Next up, an MD5 hash gets run on the concatenation of:
- the 2 octet Attribute number of the AVP
- the shared secret
- an arbitrary length random vector
The random vector used in this hash is passed in the value field of a Random Vector AVP. That Random Vector AVP MUST be placed in the message by the sender before any hidden AVPs. The same random vector can be reused for more than one hidden AVP in the same message 🔁 But if you switch to a different random vector for later AVPs, a new Random Vector AVP MUST go in the command message before the first AVP it applies to.
The MD5 hash value is then XORed with the first 16 octet (or less) segment of the Hidden AVP Subformat, and the result goes in the Attribute Value field of the Hidden AVP. If the Hidden AVP Subformat is less than 16 octets, it gets transformed as if the Attribute Value field had been padded to 16 octets before the XOR. Only the actual octets present in the Subformat get modified, though, and the AVP length is not altered 🤏
If the Subformat is longer than 16 octets, a second one-way MD5 hash is calculated over a stream of octets made of the shared secret followed by the result of the first XOR. That hash gets XORed with the second 16 octet (or less) segment of the Subformat and placed in the matching octets of the Value field of the Hidden AVP. If needed, this repeats, with the shared secret used along with each XOR result to generate the next hash for the next segment 🔄
The hiding method was adapted from RFC 2138 [RFC2138], which was taken from the "Mixing in the Plaintext" section in the book "Network Security" by Kaufman, Perlman and Speciner [KPS]. Here's a detailed explanation of how it works 🤓
Call the shared secret S, the Random Vector RV, and the Attribute Value AV. Break the value field into 16-octet chunks p1, p2, etc., with the last one padded at the end with random data to a 16-octet boundary. Call the ciphertext blocks c(1), c(2), etc. We'll also define intermediate values b1, b2, etc.
b1 = MD5(AV + S + RV) c(1) = p1 xor b1
b2 = MD5(S + c(1)) c(2) = p2 xor b2
. .
. .
. .
bi = MD5(S + c(i-1)) c(i) = pi xor biThe 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 before the AVP that needs unhiding. Then the process gets reversed to yield the original value 🎉
4.4 AVP Summary 📋
The following sections contain a list of all L2TP AVPs defined in this document 💖
Right after each AVP name, there's a list of the message types that use that AVP. After each title comes a short description of what the AVP is for, a detailed look at the format of the Attribute Value (with a graphic), and any extra info you need to use the AVP properly 💅
4.4.1 AVPs Applicable To All Control Messages 🌍
Message Type (All Messages)
The Message Type AVP, Attribute Type 0, identifies the control message and sets the context that decides what the following AVPs actually mean 🎯
The Attribute Value field for this AVP has the following format:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The Message Type is a 2 octet unsigned integer.
The Message Type AVP MUST be the first AVP in a message, immediately following the control message header (defined in section 3.1). See Section 3.2 for the list of defined control message types and their identifiers 📜
The Mandatory (M) bit in the Message Type AVP is extra special ✨ Instead of saying whether the AVP itself should be ignored when it's not recognized, it says whether the control message itself should be ignored. So if the M-bit is set in the Message Type AVP and the Message Type is unknown to the implementation, the tunnel MUST be cleared 🚫 If the M-bit is not set, the implementation may ignore an unknown message type. The M-bit MUST be set to 1 for all message types defined in this document. This AVP may not be hidden (the H-bit MUST be 0). The Length of this AVP is 8.
Random Vector (All Messages)
The Random Vector AVP, Attribute Type 36, is used to enable hiding the Attribute Value of arbitrary AVPs 🦋
The Attribute Value field for this AVP has the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Random Octet String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The Random Octet String may be of arbitrary length, although a random vector of at least 16 octets is recommended. The string holds the random vector used to compute the MD5 hash for retrieving or hiding the Attribute Value of a hidden AVP (see Section 4.2) 🎲
More than one Random Vector AVP may appear in a message. When that happens, a hidden AVP uses the Random Vector AVP that's most closely preceding it. This AVP MUST precede the first AVP with the H bit set.
The M-bit for this AVP MUST be set to 1. This AVP MUST NOT be hidden (the H-bit MUST be 0). The Length of this AVP is 6 plus the length of the Random Octet String 🫶
4.4.2 Result and Error Codes ✨
Result Code (CDN, StopCCN) 🎀
Okay bestie, the Result Code AVP (Attribute Type 1) is basically the "why did this end?" note 💀 It tells you the reason the control channel or session is being terminated.
Its Attribute Value looks like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result Code | Error Code (opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Message (opt) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The Result Code is a 2 octet unsigned integer, and the optional Error Code is too. An optional Error Message can come right after the Error Code. You can tell whether the Error Code and Message are there from the AVP Length field 🧠 The Error Message is an arbitrary string with extra human readable text about the situation. Human readable text in all error messages MUST be provided in the UTF-8 charset using the Default Language [RFC2277]. Periodt 💅
This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for this AVP MUST be set to 1. The Length is 8 if there's no Error Code or Message, 10 if there's an Error Code and no Error Message, or 10 + the length of the Error Message if there's an Error Code and Message 📏
Defined Result Code values for the StopCCN message are:
0 - Reserved
1 - General request to clear control connection
2 - General error--Error Code indicates the problem
3 - Control channel already exists
4 - Requester is not authorized to establish a control
channel
5 - The protocol version of the requester is not
supported
Error Code indicates highest version supported
6 - Requester is being shut down
7 - Finite State Machine errorDefined Result Code values for the CDN message are:
0 - Reserved
1 - Call disconnected due to loss of carrier
2 - Call disconnected for the reason indicated
in error code
3 - Call disconnected for administrative reasons
4 - Call failed due to lack of appropriate facilities
being available (temporary condition)
5 - Call failed due to lack of appropriate facilities being
available (permanent condition)
6 - Invalid destination
7 - Call failed due to no carrier detected
8 - Call failed due to detection of a busy signal
9 - Call failed due to lack of a dial tone
10 - Call was not established within time allotted by LAC
11 - Call was connected but no appropriate framing was
detectedThe Error Codes below are for errors that aren't tied to any one particular L2TP request. They're about protocol or message format errors instead 🔍 If an L2TP reply says in its Result Code that a general error happened, the General Error value should be examined to figure out what went wrong. The General Error codes that are currently defined, and what they mean, are:
0 - No general error
1 - No control connection exists yet for this LAC-LNS pair
2 - Length is wrong
3 - One of the field values was out of range or
reserved field was non-zero
4 - Insufficient resources to handle this operation now
5 - The Session ID is invalid in this context
6 - A generic vendor-specific error occurred in the LAC
7 - Try another. If LAC is aware of other possible LNS
destinations, it should try one of them. This can be
used to guide an LAC based on LNS policy, for instance,
the existence of multilink PPP bundles.
8 - Session or tunnel was shutdown due to receipt of an unknown
AVP with the M-bit set (see section 4.2). The Error Message
SHOULD contain the attribute of the offending AVP in (human
readable) text form.When General Error Code 6 is used, extra info about the error SHOULD be included in the Error Message field 🙈
4.4.3 Control Connection Management AVPs 🧚
Protocol Version (SCCRP, SCCRQ) 🌸
The Protocol Version AVP (Attribute Type 2) tells you which L2TP protocol version the sender is on.
Its Attribute Value looks like this:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | Rev |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The Ver field is a 1 octet unsigned integer holding the value 1. The Rev field is a 1 octet unsigned integer holding 0. Together that means L2TP protocol version 1, revision 0. Heads up: this is not the same version number that shows up in the header of each message 👀
This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for this AVP MUST be set to 1. The Length of this AVP is 8.
Framing Capabilities (SCCRP, SCCRQ) 🦋
The Framing Capabilities AVP (Attribute Type 3) lets the peer know which types of framing the sender will accept or request.
Its Attribute Value looks like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved for future framing type definitions |A|S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The Attribute Value field is a 32-bit mask with two bits defined. If bit A is set, asynchronous framing is supported. If bit S is set, synchronous framing is supported.
A peer MUST NOT request an incoming or outgoing call with a Framing Type AVP that specifies a value not advertised in the Framing Capabilities AVP it received during control connection establishment. If it tries anyway, the call will get rejected 🚫
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for this AVP MUST be set to 1. The Length (before hiding) is 10.
Bearer Capabilities (SCCRP, SCCRQ) 🌈
The Bearer Capabilities AVP (Attribute Type 4) lets the peer know which bearer device types the sender's hardware interfaces support for outgoing calls.
Its Attribute Value looks like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved for future bearer type definitions |A|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+This is a 32-bit mask with two bits defined. If bit A is set, analog access is supported. If bit D is set, digital access is supported.
An LNS should not request an outgoing call that specifies a value in the Bearer Type AVP for a device type not advertised in the Bearer Capabilities AVP it received from the LAC during control connection establishment. If it does, the call will get rejected.
This AVP MUST be present if the sender can place outgoing calls when requested.
Note that an LNS that can't act as an LAC as well won't support hardware devices for handling incoming and outgoing calls. It should therefore set the A and D bits of this AVP to 0, or it should not send the AVP at all. An LNS that can also act as an LAC and place outgoing calls should set A or D as appropriate. Having this AVP doesn't guarantee that the sender will place a given outgoing call when requested. It just means the physical capability exists 🔧
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for this AVP MUST be set to 1. The Length (before hiding) is 10.
Tie Breaker (SCCRQ) 💜
The Tie Breaker AVP (Attribute Type 5) says the sender wants just one tunnel to exist between the given LAC-LNS pair.
Its Attribute Value looks like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tie Break Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...(64 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The Tie Breaker Value is an 8 octet value used to pick a single tunnel when both the LAC and LNS request a tunnel at the same time. The recipient of an SCCRQ must check whether it has sent an SCCRQ to the peer. If it has, it must compare its Tie Breaker value with the received one. The lower value "wins", and the "loser" MUST silently discard its tunnel. If a tie breaker is present on both sides and the values are equal, both sides MUST discard their tunnels 😱
If a tie breaker is received and an outstanding SCCRQ had no tie breaker value, the initiator that included the Tie Breaker AVP "wins". If neither side issues a tie breaker, then two separate tunnels are opened 🎉
This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for this AVP MUST be set to 0. The Length of this AVP is 14.
Firmware Revision (SCCRP, SCCRQ) 🔥
The Firmware Revision AVP (Attribute Type 6) tells you the firmware revision of the device that issued it.
Its Attribute Value looks like this:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Firmware Revision |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The Firmware Revision is a 2 octet unsigned integer in a vendor specific format.
For devices that don't have a firmware revision (like general purpose computers running L2TP software modules, for instance), the revision of the L2TP software module may be reported instead 💻
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for this AVP MUST be set to 0. The Length (before hiding) is 8.
Host Name (SCCRP, SCCRQ) 🍓
The Host Name AVP (Attribute Type 7) tells you the name of the issuing LAC or LNS.
Its Attribute Value looks like this:
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 can be any length, but it MUST be at least 1 octet long.
The name should be as broadly unique as possible. For hosts taking part in DNS [RFC1034], a hostname with a fully qualified domain would be a good fit 🌐
This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for this AVP MUST be set to 1. The Length of this AVP is 6 plus the length of the Host Name.
Vendor Name (SCCRP, SCCRQ) 🦄
The Vendor Name AVP is Attribute Type 8 💖 It's a vendor-specific string (it can be human readable 🥹) that describes what kind of LAC or LNS is being used 🧚
The Attribute Value field is an arbitrary number of octets, laid out like this:
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 that many octets of vendor string 🎀 Human readable text here MUST be in the UTF-8 charset, using the Default Language [RFC2277] 🌸
This AVP can be hidden, so the H-bit can be 0 or 1 🦋 The M-bit MUST be set to 0 💅 The Length (before hiding) is 6 plus the length of the Vendor Name ✨
Assigned Tunnel ID (SCCRP, SCCRQ, StopCCN)
The Assigned Tunnel ID AVP is Attribute Type 9, and it carries the ID the sender is assigning to this tunnel 🫶
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Assigned Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The Assigned Tunnel ID is a 2 octet non-zero unsigned integer 🔥
This is the value that lets the LNS and LAC multiplex and demultiplex their tunnels 👑 The L2TP peer MUST put this value in the Tunnel ID header field of every control and data message it sends over that tunnel afterwards 💜 Until the Assigned Tunnel ID AVP has been received from a peer, messages to that peer MUST carry a Tunnel ID of 0 in the header of all control messages 🙈
In the StopCCN control message, the Assigned Tunnel ID AVP MUST match the Assigned Tunnel ID AVP first sent to the receiving peer 🍓 That way the peer can still find the right tunnel, even if a StopCCN shows up before it has received an Assigned Tunnel ID AVP 🧚
This AVP can be hidden (the H-bit can be 0 or 1) 🌈 The M-bit MUST be set to 1 💖 The Length (before hiding) is 8 ✨
Receive Window Size (SCCRQ, SCCRP)
The Receive Window Size AVP is Attribute Type 10, and it says what receive window size is being offered to the remote peer 🦋
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 this AVP is absent, the peer must assume a Window Size of 4 for its transmit window 🫶 The remote peer can send that many control messages before it must wait for an acknowledgment 💅
This AVP MUST NOT be hidden (the H-bit MUST be 0) 🔒 The M-bit MUST be set to 1 💜 The Length of this AVP is 8 ✨
Challenge (SCCRP, SCCRQ)
The Challenge AVP is Attribute Type 11. It tells the other side that the issuing peer wants to authenticate the tunnel endpoints using a CHAP-style authentication mechanism 🔐
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Challenge ... (arbitrary number of octets)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The Challenge is one or more octets of random data 🎲
This AVP can be hidden (the H-bit can be 0 or 1) 🦋 The M-bit MUST be set to 1 💖 The Length (before hiding) is 6 plus the length of the Challenge 🌈
Challenge Response (SCCCN, SCCRP)
The Response AVP is Attribute Type 13, and it's the answer to a challenge that was received 🙌
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Response ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The Response is a 16 octet value, the CHAP-style [RFC1994] response to the challenge 🔑
This AVP MUST be present in an SCCRP or SCCCN if a challenge was received in the preceding SCCRQ or SCCRP 💅 For the ID value in the CHAP response calculation, use the value of the Message Type AVP for this message (for example, 2 for an SCCRP, and 3 for an SCCCN) 🧮
This AVP can be hidden (the H-bit can be 0 or 1) 🦋 The M-bit MUST be set to 1 💜 The Length (before hiding) is 22 ✨
4.4.4 Call Management AVPs 📞
Q.931 Cause Code (CDN)
The Q.931 Cause Code AVP is Attribute Type 12. It gives extra info when a call gets disconnected unexpectedly 😭
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code | Cause Msg | Advisory Msg...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Cause Code is the returned Q.931 cause code, and Cause Msg is the returned Q.931 message code (for example, DISCONNECT) that goes with it 🙈 Both values come back in their native ITU encodings [DSS1] 🌸 An optional ASCII text Advisory Message can also be included (you can tell it's there from the AVP Length) to explain why the call was disconnected 🫶
This AVP MUST NOT be hidden (the H-bit MUST be 0) 🔒 The M-bit MUST be set to 1 💖 The Length of this AVP is 9, plus the size of the Advisory Message ✨
Assigned Session ID (CDN, ICRP, ICRQ, OCRP, OCRQ)
The Assigned Session ID AVP is Attribute Type 14, and it carries the ID the sender is assigning to this session 🧚
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Assigned Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The Assigned Session ID is a 2 octet non-zero unsigned integer 🔥
This AVP sets up the value used to multiplex and demultiplex data sent over a tunnel between the LNS and LAC 👑 The L2TP peer MUST put this value in the Session ID header field of every control and data message it sends over the tunnel that belongs to this session 💜 Until the Assigned Session ID AVP has been received from a peer, messages to that peer MUST be sent with a Session ID of 0 in the header of all control messages 🙈
In the CDN control message, the same Assigned Session ID AVP first sent to the receiving peer gets used again 🍓 That lets the peer find the right tunnel even if the CDN arrives before it has an Assigned Session ID 🧚
This AVP can be hidden (the H-bit can be 0 or 1) 🌈 The M-bit MUST be set to 1 💖 The Length (before hiding) is 8 ✨
Call Serial Number (ICRQ, OCRQ)
The Call Serial Number AVP is Attribute Type 15, and it's an identifier the LAC or LNS assigns to this call 🎀
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Call Serial Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The Call Serial Number is a 32 bit value 🔢
It's meant to be an easy reference for admins on both ends of a tunnel when they're digging into call failures 🕵️ Call Serial Numbers should be set to progressively increasing values, which are likely to stay unique for a significant period of time across all interconnected LNSs and LACs 🦋
This AVP can be hidden (the H-bit can be 0 or 1) 🌸 The M-bit MUST be set to 1 💜 The Length (before hiding) is 10 ✨
Minimum BPS (OCRQ)
The Minimum BPS AVP is Attribute Type 16, and it encodes the lowest acceptable line speed for this call 🐢
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum BPS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Minimum BPS is a 32 bit value that gives the speed in bits per second 🏎️
This AVP can be hidden (the H-bit can be 0 or 1) 🦋 The M-bit MUST be set to 1 💖 The Length (before hiding) is 10 ✨
Maximum BPS (OCRQ)
The Maximum BPS AVP is Attribute Type 17, and it encodes the highest acceptable line speed for this call 🚀
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum BPS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Maximum BPS is a 32 bit value that gives the speed in bits per second 🏎️
This AVP can be hidden (the H-bit can be 0 or 1) 🌈 The M-bit MUST be set to 1 💜 The Length (before hiding) is 10 ✨
Bearer Type (ICRQ, OCRQ)
The Bearer Type AVP is Attribute Type 18, and it encodes the bearer type for the incoming or outgoing call 📡
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved for future Bearer Types |A|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The Bearer Type is a 32-bit bit mask that shows the bearer capability of the call (ICRQ) or what the call requires (OCRQ) 🧠 If bit A is set, the call refers to an analog channel 📻 If bit D is set, the call refers to a digital channel 💻 Both can be set, which means the call was either indistinguishable, or it can be placed on either type of channel 🫧
okay so the LNS is the only one allowed to set these bits on an OCRQ 🫶 and it MUST only do that if the LAC already set them in the Bearer Capabilities AVP during control connection establishment. no sneaking extra bits in, bestie 💅 Setting neither the A nor the D bit in an ICRQ is totally valid. It may mean the call didn't come in over a physical link, like when the LAC and PPP live in the same subsystem 🦋 This AVP may be hidden (the H-bit may be 0 or 1), the M-bit MUST be set to 1, and the Length before hiding is 10 ✨
Framing Type (ICCN, OCCN, OCRQ) 🎀
The Framing Type AVP, Attribute Type 19, is how you encode the framing type for an incoming or outgoing call 💖
The Attribute Value field looks like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved for future Framing Types |A|S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+It's a 32-bit mask saying which PPP framing was requested for an OCRQ, or which one was negotiated for an OCCN or ICCN 🌸 The framing type MAY be used as a hint to PPP on the LNS for which link options to use during LCP negotiation [RFC1662]. Bit A means asynchronous framing and bit S means synchronous framing. For an OCRQ, both can be set, which means either one is fine 🧚
Same deal as before: the LNS MUST only set these bits for an OCRQ if the LAC sent them in the Framing Capabilities AVP during control connection establishment 👑 This AVP may be hidden (the H-bit may be 0 or 1), the M-bit MUST be set to 1, and the Length before hiding is 10 💅
Called Number (ICRQ, OCRQ) 📞
The Called Number AVP, Attribute Type 21, carries the phone number being called for an OCRQ, or the called number for an ICRQ ✨
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Called Number... (arbitrary number of octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The Called Number is an ASCII string 🍓 The LAC admin and the LNS admin might need to talk so they agree on how to read the value 🫶 This AVP may be hidden (the H-bit may be 0 or 1), the M-bit MUST be set to 1, and the Length before hiding is 6 plus the length of the Called Number 💖
Calling Number (ICRQ) 📱
The Calling Number AVP, Attribute Type 22, carries the originating number for the incoming call 🦋
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Calling Number... (arbitrary number of octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Calling Number is an ASCII string too. Same energy as Called Number: the LAC admin and LNS admin may need to coordinate on how to interpret the value in this AVP 🌈 This AVP may be hidden (the H-bit may be 0 or 1), the M-bit MUST be set to 1, and the Length before hiding is 6 plus the length of the Calling Number ✨
Sub-Address (ICRQ, OCRQ) 🌷
The Sub-Address AVP, Attribute Type 23, carries extra dialing info 🧚
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Address ... (arbitrary number of octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+It's an ASCII string, and yes, the admins may need to sync up on what it means 💅 This AVP may be hidden (the H-bit may be 0 or 1), the M-bit MUST be set to 1, and the Length before hiding is 6 plus the length of the Sub-Address 🫶
(Tx) Connect Speed (ICCN, OCCN) 🚀
The (Tx) Connect Speed BPS AVP, Attribute Type 24, carries the speed of the facility picked for the connection attempt ⭐
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BPS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+BPS is a 4 octet value giving the speed in bits per second 🔥 When the optional Rx Connect Speed AVP is present, this value is the transmit speed from the LAC's point of view, meaning data flowing from the LAC to the remote system 🌸 When the optional Rx Connect Speed AVP is not present, the speed between the remote system and the LAC is treated as symmetric and this one value covers both directions 🦋 This AVP may be hidden (the H-bit may be 0 or 1), the M-bit MUST be set to 1, and the Length before hiding is 10 💖
Rx Connect Speed (ICCN, OCCN) 📶
The Rx Connect Speed AVP, Attribute Type 38, shows the speed of the connection from the LAC's point of view, which is data flowing from the remote system to the LAC 🌈
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BPS (H) | BPS (L) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+BPS is a 4 octet value giving the speed in bits per second 🫶 Having this AVP means the connection can be asymmetric compared to the transmit speed in the (Tx) Connect Speed AVP 👑 This AVP may be hidden (the H-bit MAY be 1 or 0), the M-bit MUST be set to 0, and the Length before hiding is 10 ✨
Physical Channel ID (ICRQ, OCRP) 🔌
The Physical Channel ID AVP, Attribute Type 25, carries a vendor-specific physical channel number used for a call 🧚
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Physical Channel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Physical Channel ID is a 4 octet value meant for logging purposes only 📝 This AVP may be hidden (the H-bit may be 0 or 1), the M-bit MUST be set to 0, and the Length before hiding is 10 🌸
Private Group ID (ICCN) 🔐
The Private Group ID AVP, Attribute Type 37, is how the LAC says this call belongs to a particular customer group 💜
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Private Group ID ... (arbitrary number of octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The Private Group ID is a string of octets with arbitrary length 🦋 The LNS MAY treat the PPP session, plus the network traffic going through it, in a special way decided by the peer 🌈 Like, if the LNS is hooked up to a bunch of private networks using unregistered addresses, the LAC might include this AVP so the call goes to the right one 🧚
The Private Group ID is a string that matches a table in the LNS, and that table defines the characteristics of the chosen group 💅 A LAC MAY work out the Private Group ID from a RADIUS response, local configuration, or some other source ✨ This AVP may be hidden (the H-bit MAY be 1 or 0), the M-bit MUST be set to 0, and the Length before hiding is 6 plus the length of the Private Group ID 🫶
Sequencing Required (ICCN, OCCN) 🔢
The Sequencing Required AVP, Attribute Type 39, tells the LNS that Sequence Numbers MUST always be present on the data channel 🔥 This AVP has no Attribute Value field, so there's nothing to hide in the value itself 🙈
This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit MUST be set to 1, and the Length of this AVP is 6 💀
4.4.5 Proxy LCP and Authentication AVPs ✨
okay so the LAC might've already picked up the call and done LCP with the remote system 📞, maybe just to figure out what identity the system is showing. 🫶 In that case these AVPs can be included to share the link properties the remote system asked for at first, the ones the remote system and LAC actually agreed on in the end, and the PPP authentication info the LAC sent and got back. 💅 The LNS can use all of that to start up its own PPP LCP and authentication, so PPP keeps going without redoing LCP. 🧚 Heads up though: the LNS might be set up to do another round of LCP and/or auth anyway if it doesn't fully trust the LAC 🙈
Initial Received LCP CONFREQ (ICCN)
Okay this one is Attribute Type 26 💖 and it gives the LNS the very first CONFREQ the LAC got from the PPP Peer. 🌸
The Attribute Value field looks like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LCP CONFREQ... (arbitrary number of octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The LCP CONFREQ is just a copy of the initial CONFREQ's body, starting at the first option inside the LCP message. 🎀
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for this AVP MUST be set to 0. The Length (before hiding) of this AVP is 6 plus the length of the CONFREQ. 🔥
Last Sent LCP CONFREQ (ICCN)
Next up is Attribute Type 27 🦋 and this one hands the LNS the last CONFREQ the LAC sent to the PPP Peer. 💜
The Attribute Value field:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LCP CONFREQ... (arbitrary number of octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+This LCP CONFREQ is a copy of the body of the final CONFREQ sent to the client to wrap up LCP negotiation, again starting at the first option in the LCP message body. ✨
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for this AVP MUST be set to 0. The Length (before hiding) of this AVP is 6 plus the length of the CONFREQ. 💅
Last Received LCP CONFREQ (ICCN)
Attribute Type 28 is up now 🌈 and it gives the LNS the last CONFREQ the LAC got from the PPP Peer. 🍓
The Attribute Value field:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LCP CONFREQ... (arbitrary number of octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The LCP CONFREQ is a copy of the body of the final CONFREQ received from the client to complete LCP negotiation, starting at the first option within the LCP message body. 🦋
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for this AVP MUST be set to 0. The Length (before hiding) of this AVP is 6 plus the length of the CONFREQ. 🫶
Proxy Authen Type (ICCN)
Attribute Type 29 is the one that decides whether proxy authentication should be used. 👑
The Attribute Value field:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authen Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Authen Type is a 2 octet unsigned integer, holding:
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for this AVP MUST be set to 0. The Length (before hiding) of this AVP is 8. 🎀
The defined Authen Type values are:
0 - Reserved1 - Textual username/password exchange2 - PPP CHAP3 - PPP PAP4 - No Authentication5 - Microsoft CHAP Version 1 (MSCHAPv1)
This AVP MUST be present if proxy authentication is to be utilized. If it is not present, then it is assumed that this peer cannot perform proxy authentication, requiring a restart of the authentication phase at the LNS if the client has already entered this phase with the LAC (which may be determined by the Proxy LCP AVP if present). 🙈
Associated AVPs for each type of authentication follow. 🧚
Proxy Authen Name (ICCN)
Attribute Type 30 is the Proxy Authen Name AVP 💖 and it says who the authenticating client is when proxy authentication is being used. 🌸
The Attribute Value field:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authen Name... (arbitrary number of octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Authen Name is a string of octets with arbitrary length. It contains the name from the client's authentication response. 💜
This AVP MUST be present in messages containing a Proxy Authen Type AVP with an Authen Type of 1, 2, 3 or 5. It may be desirable to employ AVP hiding to keep the cleartext name obscured. 🔥
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for this AVP MUST be set to 0. The Length (before hiding) is 6 plus the length of the cleartext name. ✨
Proxy Authen Challenge (ICCN)
Attribute Type 31 is the Proxy Authen Challenge 🦋, which carries the challenge the LAC sent to the PPP Peer when proxy authentication is in use. 🍓
The Attribute Value field:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Challenge... (arbitrary number of octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The Challenge is a string of one or more octets. 🌈
This AVP MUST be present for Proxy Authen Types 2 and 5. The Challenge field holds the CHAP challenge the LAC presented to the client. 💅
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for this AVP MUST be set to 0. The Length (before hiding) of this AVP is 6, plus the length of the Challenge. 🫶
Proxy Authen ID (ICCN)
Attribute Type 32 is the Proxy Authen ID AVP 👑, and it gives the ID value of the PPP Authentication that got started between the LAC and the PPP Peer when proxy authentication is being used. 🧚
The Attribute Value field:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ID is a 2 octet unsigned integer, and its most significant octet MUST be 0. 🎀
The Proxy Authen ID AVP MUST be present for Proxy authen types 2, 3 and 5. For types 2 and 5, the ID field holds the byte ID value the LAC presented to the client in its Challenge. For type 3, it's the Identifier value of the Authenticate-Request. 💖
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for this AVP MUST be set to 0. 🌸
Proxy Authen Response (ICCN)
Last one for this section! Attribute Type 33 is the Proxy Authen Response AVP 💜. It carries the PPP Authentication response the LAC got back from the PPP Peer when proxy authentication is used. 🔥
The Attribute Value field:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Response... (arbitrary number of octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The Response is a string of octets. ✨
This AVP MUST be present for Proxy authen types 1, 2, 3 and 5. The Response field holds the client's response to the challenge. For Proxy authen types 2 and 5, this field has the response value the LAC received. For types 1 or 3, it has the clear text password the LAC got from the client. 🦋 With cleartext passwords, AVP hiding is recommended. 🙈
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for this AVP MUST be set to 0. The Length (before hiding) of this AVP is 6 plus the length of the Response. 💅
4.4.6 Call Status AVPs ✨
Call Errors (WEN) 💅
okay so the Call Errors AVP is Attribute Type 34 🎀 and it's how the LAC tells the LNS about error info. the layout is literally this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | CRC Errors (H) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CRC Errors (L) | Framing Errors (H) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Framing Errors (L) | Hardware Overruns (H) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hardware Overruns (L) | Buffer Overruns (H) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Buffer Overruns (L) | Time-out Errors (H) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time-out Errors (L) | Alignment Errors (H) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Alignment Errors (L) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+here's what each field means, bestie 🫶
Reserved- not used, and it MUST be 0 🔒CRC Errors- the number of PPP frames received with CRC errors since the call was established 💥Framing Errors- the number of improperly framed PPP packets received 🙈Hardware Overruns- the number of receive buffer over-runs since the call was established 🔧Buffer Overruns- the number of buffer over-runs detected since the call was established 🌊Time-out Errors- the number of time-outs since the call was established ⏰Alignment Errors- the number of alignment errors since the call was established 📐
this AVP may be hidden, so the H-bit can be 0 or 1 🦋 the M-bit for this AVP MUST be set to 1, and the Length (before hiding) of this AVP is 32 💜
ACCM (SLI) 🌈
the ACCM AVP is Attribute Type 35 and the LNS uses it to tell the LAC which ACCM got negotiated with the PPP Peer on the LNS side 🍓 the layout:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Send ACCM (H) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Send ACCM (L) | Receive ACCM (H) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receive ACCM (L) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+so Send ACCM and Receive ACCM are each 4 octet values, and each one has a 2 octet reserved bit in front of it 🎀 the Send ACCM value should be used by the LAC to process the packets it sends on the connection, and the Receive ACCM value should be used by the LAC to process incoming packets on the connection ✨ the default for both is 0xFFFFFFFF 💖 the LAC should honor these fields unless it has specific configuration info saying the requested mask has to be changed so things still work 🫶
this AVP may be hidden (the H-bit MAY be 1 or 0) 🦋 the M-bit for this AVP MUST be set to 1, and the Length of this AVP is 16 💅
5.0 Protocol Operation 🦋
okay so setting up L2TP to tunnel a PPP session is basically two steps 🌸 step one is establishing the Control Connection for a Tunnel, and step two is establishing a Session, which gets kicked off by an incoming or outgoing call request ✨ the Tunnel and its Control Connection MUST be established before any incoming or outgoing call is initiated 🔥 an L2TP Session MUST be established before L2TP can start tunneling PPP frames 💜 multiple Sessions can live across a single Tunnel, and multiple Tunnels can exist between the same LAC and LNS 👑
+-----+ +-----+
| |~~~~~~~~~~L2TP Tunnel~~~~~~~~~~| |
| LAC | | LNS |
| #######Control Connection######## |
[Remote] | | | |
[System]------Call----------*============L2TP Session=============* |
PPP +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ |
| | | |
[Remote] | | | |
[System]------Call----------*============L2TP Session=============* |
PPP +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ |
| | | |
| |~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| |
+-----+ +-----+Figure 5.1 Tunneling PPP 🧚
5.1 Control Connection Establishment 🌈
the Control Connection is the first connection that has to be achieved between an LAC and LNS before any sessions can come up 💖 setting it up means confirming who the peer is, and also figuring out the peer's L2TP version, framing, bearer capabilities, and so on 👀
it takes a three message exchange to set up the control connection, and a typical one looks like this:
LAC or LNS LAC or LNS
---------- ----------
SCCRQ ->
<- SCCRP
SCCCN ->
<- ZLB ACKthe ZLB ACK gets sent if there are no more messages waiting in the queue for that peer ✨
5.1.1 Tunnel Authentication 🔐
L2TP has a simple, optional, CHAP-like [RFC1994] tunnel authentication system built into control connection establishment 💅 if an LAC or LNS wants to check the identity of the peer it's contacting (or being contacted by), it includes a Challenge AVP in the SCCRQ or SCCRP message 🎀 if a Challenge AVP shows up in an SCCRQ or SCCRP, a Challenge Response AVP MUST be sent in the following SCCRP or SCCCN, respectively 🫶 and if the expected response doesn't match the response received from the peer, establishment of the tunnel MUST be disallowed 🚫
to take part in tunnel authentication, a single shared secret MUST exist between the LAC and LNS 🔑 it's the same shared secret that gets used for AVP hiding (see Section 4.3) 🙈 see Section 4.4.3 for the details on how the Challenge and Response AVPs are built 💜
5.2 Session Establishment 🌸
once the control connection is up, individual sessions can be created 💖 each session corresponds to a single PPP stream between the LAC and LNS 🦋 unlike control connection establishment, session establishment is directional, meaning it depends on which side is doing what 🧚 the LAC asks the LNS to accept a session for an incoming call, and the LNS asks the LAC to accept a session for placing an outgoing call 📞
5.2.1 Incoming Call Establishment 📥
a three message exchange sets up the session, and here's a typical sequence of events:
LAC LNS
--- ---
(Call
Detected)
ICRQ ->
<- ICRP
ICCN ->
<- ZLB ACKthe ZLB ACK gets sent if there are no more messages waiting in the queue for that peer ✨
5.2.2 Outgoing Call Establishment 📤
again, a three message exchange sets up the session, and a typical sequence goes like this:
LAC LNS
--- ---
<- OCRQ
OCRP ->
(Perform
Call
Operation)
OCCN ->
<- ZLB ACKthe ZLB ACK gets sent if there are no more messages waiting in the queue for that peer ✨
5.3 Forwarding PPP Frames 🚀
once tunnel establishment is done, PPP frames from the remote system show up at the LAC 🌊 the LAC strips off the CRC, the link framing, and the transparency bytes, then encapsulates the frame in L2TP and forwards it over the right tunnel 💫 the LNS gets the L2TP packet and handles the encapsulated PPP frame as if it had arrived on a local PPP interface 🫶
whoever sends a message tied to a particular session and tunnel puts the Session ID and Tunnel ID (as specified by its peer) into the Session ID and Tunnel ID header for every outgoing message 🎀 this is how PPP frames get multiplexed and demultiplexed over a single tunnel between a given LNS-LAC pair 🧩 multiple tunnels can exist between a given LNS-LAC pair, and multiple sessions can exist within a tunnel 👑
the value 0 for Session ID and Tunnel ID is special 🚫 it MUST NOT be used as an Assigned Session ID or Assigned Tunnel ID 🚫 when the peer hasn't assigned a Session ID yet (like while a new session or tunnel is being set up), the Session ID field MUST be sent as 0, and the Assigned Session ID AVP in the message MUST be used to identify the session 💜 same deal for the Tunnel ID: if it hasn't been assigned by the peer yet, the Tunnel ID MUST be sent as 0 and the Assigned Tunnel ID AVP gets used to identify the tunnel 🌈
5.4 Using Sequence Numbers on the Data Channel 🔢
sequence numbers are defined in the L2TP header for control messages, and they're optional for data messages (see Section 3.1) 🧠 they're used to give the control messages a reliable transport (see Section 5.8) and to give data messages optional sequencing 🌸 each peer keeps separate sequence numbers for the control connection and for each individual data session within a tunnel 💖
the L2TP data channel is different from the control channel because it doesn't use sequence numbers to retransmit lost data messages 🙅 instead, data messages can use sequence numbers to spot lost packets and/or put back the original order of packets that got reordered in transit 🦋 the LAC can ask for sequence numbers to be present in data messages with the Sequencing Required AVP (see Section 4.4.6) 🎀 if that AVP is there during session setup, sequence numbers MUST be present at all times 🔒 if it isn't there, then sequencing presence is up to the LNS 👑 the LNS turns sequence numbers on or off by sending a data message with or without them, and it can do that at any point during the life of a session 🔄 so if the LAC gets a data message without sequence numbers, it MUST stop sending sequence numbers in future data messages 🛑 and if the LAC gets a data message with sequence numbers, it MUST begin sending them in future outgoing data messages 🚀 if the LNS turns sequencing back on after turning it off earlier in the session, the sequence number state picks up right where it left off 🧚
the LNS can start disabling sequencing at any time during the session (even on the very first data message) 🌙 it is recommended that, for connections where reordering or packet loss might happen, sequence numbers always stay enabled during the initial PPP negotiation stages and only get disabled when and if the risk is considered acceptable 💅 for example, if the PPP session being tunneled isn't using any stateful compression or encryption protocols and is only carrying IP (as determined by the PPP NCPs that are established), then the LNS might decide to disable sequencing, because IP is tolerant to datagram loss and reordering 🌈
5.5 Keepalive (Hello) 💖
okay bestie, so L2TP needs a way to tell "the tunnel is dead" apart from "nobody has said anything in a while" 🥺 that's where keepalives come in. If there's been no data or control message on a tunnel for a set amount of time, the peer injects a Hello control message (see Section 6.5) to check in. Same as any other control message, if the Hello doesn't get delivered reliably, the tunnel is declared down and reset. 💅 The transport reset plus the Hello injections means a connectivity failure between the LNS and the LAC gets caught at both ends. no cap, that's iconic 🫶
5.6 Session Teardown 🦋
Either the LAC or the LNS can start a session teardown, and it's done by sending a CDN control message. 🌸 Once the last session is cleared, the control connection MAY be torn down too (and it typically is). Here's what a normal exchange looks like:
LAC or LNS LAC or LNS
CDN ->
(Clean up)
<- ZLB ACK
(Clean up)5.7 Control Connection Teardown ✨
Control connection teardown can also be started by either the LAC or the LNS, and it's done with one single StopCCN control message. 🎀 The receiver of a StopCCN MUST send a ZLB ACK to say "got it" and keep enough control connection state around to properly accept StopCCN retransmissions for at least a full retransmission cycle, just in case that ZLB ACK gets lost 😭 The recommended time for one full retransmission cycle is 31 seconds (see section 5.8). Here's the typical exchange:
LAC or LNS LAC or LNS
StopCCN ->
(Clean up)
<- ZLB ACK
(Wait)
(Clean up)An implementation may shut down an entire tunnel and all of its sessions by sending the StopCCN. 🧚 So you don't have to clear each session one by one when you're tearing down the whole tunnel. Efficient and slay 💅
5.8 Reliable Delivery of Control Messages 🌈
L2TP gives all control messages a lower level reliable transport. The Nr and Ns fields in the control message header (see section 3.1) belong to that transport, not to the upper layers, so the upper level functions don't care about retransmission or ordering. 🙈 This reliable control message layer is a sliding window transport that handles retransmission and congestion control, and each peer keeps its own separate sequence number state for the control connection in a tunnel.
The message sequence number, Ns, starts at 0, and every message after that gets the next number up. It's a free running counter represented modulo 65536. A received message's sequence number counts as "less than or equal to" the last received number if it falls in the range from the last received number back through the preceding 32767 values, inclusive. For example, if the last received sequence number was 15, then messages numbered 0 through 15, plus 32784 through 65535, would all count as less than or equal. 💀 Those are treated as duplicates and ignored. BUT, to make sure every message gets acknowledged properly (especially if a ZLB ACK got lost), receipt of duplicate messages MUST be acknowledged by the reliable transport too. That ack can ride piggybacked on a message already in the queue, or go out explicitly as a ZLB ACK.
Every control message uses up one slot in the control message sequence number space, except the ZLB acknowledgement. So Ns doesn't go up after a ZLB message is sent.
The last received message number, Nr, is how a peer acknowledges messages it received. It holds the sequence number of the message the peer expects next (so usually the last Ns of a non-ZLB message received, plus 1, modulo 65536). The Nr in a received ZLB is used to flush messages out of the local retransmit queue (more on that below), but the Nr of the next message sent is not be updated by the Ns of the ZLB. 🦋
The reliable transport at a receiving peer makes sure control messages get delivered to the upper level in order and without duplication. Out of order messages may be queued until the missing ones show up, or they may be discarded, which means the peer has to retransmit them. 🫶
Each tunnel keeps a queue of control messages to send to its peer. The message at the front of the queue goes out with a given Ns value and gets held until a control message comes in from the peer whose Nr shows it got that message. If a period of time passes with no acknowledgement (a recommended default is 1 second), the message gets retransmitted. The retransmitted message keeps the same Ns value, but the Nr value MUST be updated to the sequence number of the next expected message. ✨
Every retransmission after that MUST use an exponential backoff interval. So if the first retransmission happened after 1 second, the next one should happen after 2 seconds, then 4 seconds, and so on. An implementation MAY put a cap on the maximum interval between retransmissions, but that cap MUST be no less than 8 seconds per retransmission. 🍓 If there's no peer response after several retransmissions (a recommended default is 5, but SHOULD be configurable), the tunnel and all sessions in it MUST be cleared. Yikes 😭
When a tunnel is shutting down for reasons other than losing connectivity, the state and reliable delivery mechanisms MUST be maintained and operated for the full retransmission interval after the final message exchange. 👑
A sliding window mechanism handles control message transmission. Say we have two peers, A and B. If A sends a Receive Window Size AVP with a value of N in its SCCRQ or SCCRP messages, then B is allowed up to N outstanding control messages. Once N have been sent, it must wait for an acknowledgment that moves the window forward before it sends new control messages. An implementation may support a receive window of only 1 (by sending a Receive Window Size AVP with a value of 1), but it MUST accept a window of up to 4 from its peer, meaning it can handle 4 messages before backing off. A Receive Window Size AVP value of 0 is invalid. 🙅♀️
When retransmitting control messages, a slow start and congestion avoidance window adjustment procedure SHOULD be used. The recommended approach for that is in Appendix A. 🌸
A peer MUST NOT hold back acknowledgments as a way to flow control control messages. An L2TP implementation is expected to keep up with incoming control messages, and it can respond to some of them with errors if it can't carry out the requested action. 💅
Appendix B has examples of control message transmission, acknowledgement, and retransmission. 🧚
6.0 Control Connection Protocol Specification 💜
The control connection messages below are used to establish, clear, and maintain L2TP tunnels. All data is sent in network order (high order octets first). Any "reserved" or "empty" fields MUST be sent as 0 values so the protocol stays extensible. 🎀
6.1 Start-Control-Connection-Request (SCCRQ) 🌸
Start-Control-Connection-Request (SCCRQ) is the control message used to set up a tunnel between an LNS and an LAC. Either the LAC or the LNS can send it to kick off the tunnel establishment process. 🚀
The following AVPs MUST be present in the SCCRQ:
Message Type AVPProtocol VersionHost NameFraming CapabilitiesAssigned Tunnel ID
The following AVPs MAY be present in the SCCRQ:
Bearer CapabilitiesReceive Window SizeChallengeTie BreakerFirmware RevisionVendor Name
6.2 Start-Control-Connection-Reply (SCCRP) 🦋
Start-Control-Connection-Reply (SCCRP) is the control message sent back in reply to a received SCCRQ. It's how the peer says "your SCCRQ was accepted, keep establishing the tunnel" ✨
The following AVPs MUST be present in the SCCRP:
Message TypeProtocol VersionFraming CapabilitiesHost NameAssigned Tunnel ID
The following AVPs MAY be present in the SCCRP:
Bearer CapabilitiesFirmware RevisionVendor NameReceive Window SizeChallengeChallenge Response
6.3 Start-Control-Connection-Connected (SCCCN) 👑
Start-Control-Connection-Connected (SCCCN) is the control message sent in reply to an SCCRP. This is the one that finishes off tunnel establishment, so it's a whole vibe 🎉
The following AVP MUST be present in the SCCCN:
Message Type
The following AVP MAY be present in the SCCCN:
Challenge Response
6.4 Stop-Control-Connection-Notification (StopCCN) 😭
Stop-Control-Connection-Notification (StopCCN) is a control message that either the LAC or the LNS sends to tell its peer the tunnel is shutting down and the control connection should close. All active sessions get implicitly cleared too, with no explicit call control messages needed. 🫶 The reason for sending it goes in the Result Code AVP. There's no explicit reply, just the implicit ACK from the reliable control message transport layer.
The following AVPs MUST be present in the StopCCN:
Message TypeAssigned Tunnel IDResult Code
6.5 Hello (HELLO) 💖
The Hello (HELLO) message is an L2TP control message that either peer on a LAC-LNS control connection can send. It works as a "keepalive" for the tunnel. 🌈
Sending HELLO messages, and the policy for when to send them, is up to the implementation. A peer MUST NOT expect HELLO messages at any time or interval. Like every message on the control connection, the receiver answers with either a ZLB ACK or an unrelated message that carries the needed acknowledgement info. 🙈
Since a HELLO is a control message, and control messages are reliably sent by the lower level transport, the keepalive works by making the transport reliably deliver a message. If there's a media interruption, the reliable transport can't get the HELLO across and will clean up the tunnel. 💀
Keepalives for the tunnel MAY be implemented by sending a HELLO once a period of time (a recommended default is 60 seconds, but SHOULD be configurable) passes without any message (data or control) arriving from the peer. ⭐
HELLO messages are global to the tunnel, so the Session ID in a HELLO message MUST be 0. 🧚
The following AVP MUST be present in the HELLO message:
Message Type
6.6 Incoming-Call-Request (ICRQ) 📞✨
okay so the Incoming-Call-Request (ICRQ) is a control message the LAC sends to the LNS when it notices an incoming call 📞 it's the first message in a three-message exchange that sets up a session inside an L2TP tunnel 🎀
the ICRQ says "hey, this call needs a session" and gives the LNS the session parameter info it needs 💅 the LAC is allowed to wait before answering the call until an ICRP comes back from the LNS saying the session should be set up 🦋 that way the LNS can learn enough about the call to decide whether it even wants to pick up 👑 the other option is that the LAC answers the call right away, negotiates LCP and PPP authentication, and uses what it learns to pick the LNS 🌸 in that case the call is already answered by the time the ICRP shows up, so the LAC just fakes the "call indication" and "call answer" steps 🙈
the following AVPs MUST be present in the ICRQ:
Message TypeAssigned Session IDCall Serial Number
the following AVPs MAY be present in the ICRQ:
Bearer TypePhysical Channel IDCalling NumberCalled NumberSub-Address
6.7 Incoming-Call-Reply (ICRP) 💌
Incoming-Call-Reply (ICRP) is the LNS's reply to a received ICRQ 🫶 it's the second message in the three-message exchange for setting up sessions in an L2TP tunnel 💜
the ICRP says the ICRQ went through and tells the LAC to answer the call if it hasn't already 📲 it's also where the LNS can share any parameters it needs for the L2TP session 🧚
the following AVPs MUST be present in the ICRP:
Message TypeAssigned Session ID
6.8 Incoming-Call-Connected (ICCN) 🎉
Incoming-Call-Connected (ICCN) is the LAC's message to the LNS, sent after a received ICRP 💅 it's the third and final message in the three-message exchange for setting up sessions in an L2TP tunnel ✨
the ICCN tells the LNS the ICRP was accepted, the call has been answered, and the L2TP session should now move into the established state 🦋 it also gives the LNS extra info about the parameters used for the answered call 🌈 some of that info might not have been available yet when the ICRQ was sent, which is why it shows up here 🙈
the following AVPs MUST be present in the ICCN:
Message Type(Tx) Connect SpeedFraming Type
the following AVPs MAY be present in the ICCN:
Initial Received LCP CONFREQLast Sent LCP CONFREQLast Received LCP CONFREQProxy Authen TypeProxy Authen NameProxy Authen ChallengeProxy Authen IDProxy Authen ResponsePrivate Group IDRx Connect SpeedSequencing Required
6.9 Outgoing-Call-Request (OCRQ) 📤
Outgoing-Call-Request (OCRQ) is the LNS's message to the LAC asking for an outbound call from the LAC to be set up 🌸 it's the first message in a three-message exchange for setting up a session inside an L2TP tunnel 🎀
the OCRQ says a session should be set up between the LNS and LAC for this call 💖 it also gives the LAC the parameter info for both the L2TP session and the call that's about to be placed ✨
an LNS MUST have received a Bearer Capabilities AVP during tunnel establishment from an LAC before it can request an outgoing call to that LAC 🙅♀️ no skipping this step bestie 💅
the following AVPs MUST be present in the OCRQ:
Message TypeAssigned Session IDCall Serial NumberMinimum BPSMaximum BPSBearer TypeFraming TypeCalled Number
the following AVPs MAY be present in the OCRQ:
Sub-Address
6.10 Outgoing-Call-Reply (OCRP) 🫧
Outgoing-Call-Reply (OCRP) is the LAC's reply to a received OCRQ 💜 it's the second message in a three-message exchange for setting up a session inside an L2TP tunnel 🦋
the OCRP says the LAC can go ahead and try the outbound call, and it sends back some info about that attempt 🌟
the following AVPs MUST be present in the OCRP:
Message TypeAssigned Session ID
the following AVPs MAY be present in the OCRP:
Physical Channel ID
6.11 Outgoing-Call-Connected (OCCN) 🥳
Outgoing-Call-Connected (OCCN) is the LAC's message to the LNS, sent after the OCRP and once the outgoing call is finished 🎉 it's the final message in the three-message exchange for setting up a session inside an L2TP tunnel 💅
the OCCN says the outgoing call worked out 🙌 it also tells the LNS the specific parameters that were figured out once the call was established 🧚
the following AVPs MUST be present in the OCCN:
Message Type(Tx) Connect SpeedFraming Type
the following AVPs MAY be present in the OCCN:
Rx Connect SpeedSequencing Required
6.12 Call-Disconnect-Notify (CDN) 📴
The Call-Disconnect-Notify (CDN) message is an L2TP control message that either the LAC or the LNS can send to ask for a specific call inside the tunnel to be disconnected 💔 its job is to tell the peer that the call is going away and explain why 🥺 the peer MUST clean up any resources it was using 🧹 but it doesn't send back any kind of success or failure for that cleanup, so no reply, no drama 💅
the following AVPs MUST be present in the CDN:
Message TypeResult CodeAssigned Session ID
the following AVPs MAY be present in the CDN:
Q.931 Cause Code
6.13 WAN-Error-Notify (WEN) 🚨
The WAN-Error-Notify message is an L2TP control message the LAC sends to the LNS to report WAN error conditions, meaning the conditions that happen on the interface that supports PPP 📡 the counters in this message are cumulative, so they keep adding up 🔢 this message should only be sent when an error actually happens, and not more than once every 60 seconds ⏰ the counters get reset whenever a new call is set up 🌸
the following AVPs MUST be present in the WEN:
Message TypeCall Errors
6.14 Set-Link-Info (SLI) ⚙️
The Set-Link-Info message is an L2TP control message the LNS sends to the LAC to set PPP-negotiated options 🎛️ these options can change at any point during the life of the call, so the LAC MUST be able to update its internal call info and behavior on an active PPP session 🔄 no freezing up allowed 💖
the following AVPs MUST be present in the SLI:
Message TypeACCM
7.0 Control Connection State Machines 🗺️
the control messages from section 6 get exchanged through the state tables described in this section 💅 there are tables for placing an incoming call, placing an outgoing call, and starting up the tunnel itself 🎀 the state tables don't encode any timeout or retransmission behavior, because that's handled by the underlying semantics in Section 5.8 🔁
7.1 Control Connection Protocol Operation 🧭
this section walks through how the various L2TP control connection functions work and which Control Connection messages support them 🫶
if an invalid or unrecoverable malformed control message comes in, it should be logged properly and the control connection should be cleared so everything gets back to a known state 🧼 after that, the initiator can restart the control connection 🔄
an invalid control message is one with a Message Type that's marked mandatory (see Section 4.4.1) and that the implementation doesn't recognize, or one that shows up in the wrong order (for example, an SCCCN sent in reply to an SCCRQ) 🙃
malformed control messages include ones with an invalid value in the header, an AVP that's formatted wrong or has a value out of range, or a message that's missing a required AVP 😵 a control message with a malformed header should be discarded 🗑️ a control message with an invalid AVP should check the M-bit for that AVP to figure out whether the error is recoverable 🔍
a malformed but recoverable non-mandatory AVP (one where the M-bit is not set) should be handled a lot like an unrecognized non-mandatory AVP 🌷 so if a malformed AVP arrives with the M-bit set, the session or tunnel should be terminated, with a proper Result or Error Code sent 🛑 if the M-bit is not set, the AVP should be ignored (apart from logging a local error message) and the message gets accepted ✅
⚠️ bestie, read this part! This MUST NOT be treated as permission to send malformed AVPs 🙅♀️ it's just guidance for handling a badly formatted message if one shows up 💅 it's impossible to list every possible malformation and give advice for each one, so don't even try 😭
for example, a recoverable malformed AVP might be the Rx Connect Speed AVP, attribute 38, arriving with a length of 8 instead of 10, with the BPS given in 2 octets instead of 4 🤏 since Rx Connect Speed is non-mandatory, this shouldn't be treated as catastrophic 🌈 the control message should be accepted as if that AVP was never received (apart from logging a local error message) 📝
in several of the tables that follow, a protocol message gets sent and then a "clean up" happens 🧹 no matter who starts the tunnel destruction, the reliable delivery mechanism MUST be allowed to run (see Section 5.8) before the tunnel gets destroyed 🙏 this lets the tunnel management messages get reliably delivered to the peer 💌
Appendix B.1 has an example of lock-step tunnel establishment 🧩
7.2 Control Connection States 🌙
the L2TP control connection protocol doesn't tell the LNS and LAC apart 👯 but it does tell apart the originator and the receiver 💜 the originating peer is the one that first starts setting up the tunnel (in a tie breaker situation, the originator is whoever wins the tie) 🏆 since either the LAC or the LNS can be the originator, a collision can happen 💥 see the Tie Breaker AVP in Section 4.4.3 for how that's described and resolved 🫧
7.2.1 Control Connection Establishment ✨
okay, bestie, this table is the whole control connection handshake in one place 💅 everything is chill until someone sends something unexpected, and then the table tells you exactly how to handle the drama 🫶
State Event Action New State
----- ----- ------ ---------
idle Local Send SCCRQ wait-ctl-reply
Open request
idle Receive SCCRQ, Send SCCRP wait-ctl-conn
acceptable
idle Receive SCCRQ, Send StopCCN, idle
not acceptable Clean up
idle Receive SCCRP Send StopCCN idle
Clean up
idle Receive SCCCN Clean up idle
wait-ctl-reply Receive SCCRP, Send SCCCN, established
acceptable Send tunnel-open
event to waiting
sessions
wait-ctl-reply Receive SCCRP, Send StopCCN, idle
not acceptable Clean up
wait-ctl-reply Receive SCCRQ, Clean up, idle
lose tie-breaker Re-queue SCCRQ
for idle state
wait-ctl-reply Receive SCCCN Send StopCCN idle
Clean up
wait-ctl-conn Receive SCCCN, Send tunnel-open established
acceptable event to waiting
sessions
wait-ctl-conn Receive SCCCN, Send StopCCN, idle
not acceptable Clean up
wait-ctl-conn Receive SCCRP, Send StopCCN, idle
SCCRQ Clean up
established Local Send tunnel-open established
Open request event to waiting
(new call) sessions
established Admin Send StopCCN idle
Tunnel Close Clean up
established Receive SCCRQ, Send StopCCN idle
SCCRP, SCCCN Clean up
idle Receive StopCCN Clean up idle
wait-ctl-reply,
wait-ctl-conn,
establishedThe states that the LNS or LAC use for control connection establishment are:
idle Both the initiator and the recipient start here. An initiator transmits an SCCRQ, while a recipient stays in the idle state until it receives an SCCRQ.
wait-ctl-reply The originator checks whether another connection has been requested from the same peer. If so, it handles the collision situation described in Section 5.8.
When an SCCRP arrives, it gets checked for a compatible version. If the version in the reply is lower than the version sent in the request, the older (lower) version should be used, provided it is supported. If the version in the reply is earlier and supported, the originator moves to the established state. If the version is earlier and not supported, a StopCCN MUST be sent to the peer, and the originator cleans up and terminates the tunnel. 💀
wait-ctl-conn This is where the SCCCN gets awaited. Once it shows up, the challenge response is checked. The tunnel either gets established, or it gets torn down if an authorization failure is detected. 🔥
established An established connection can be terminated either by a local condition or by receipt of a Stop-Control-Connection-Notification. In the event of a local termination, the originator MUST send a Stop-Control-Connection-Notification and clean up the tunnel.
If the originator receives a Stop-Control-Connection-Notification, it MUST also clean up the tunnel. 🫶
7.3 Timing considerations 🦋
Because telephone signaling is real-time, both the LNS and the LAC should be implemented with multi-threaded architectures, so messages related to multiple calls aren't serialized and blocked. The call and connection state figures don't specify exceptions caused by timers. Those get handled in Section 5.8. ⏱️
7.4 Incoming calls 📞
An Incoming-Call-Request message is generated by the LAC when an incoming call is detected (for example, when an associated telephone line rings). The LAC picks a Session ID and serial number, and it indicates the call bearer type. Modems should always indicate the analog call type. ISDN calls should indicate digital when unrestricted digital service or rate adaption is used, and analog if digital modems are involved. Calling Number, Called Number, and Subaddress may be included in the message if they're available from the telephone network. 🌸
Once the LAC sends the Incoming-Call-Request, it waits for a response from the LNS, but it doesn't necessarily answer the call from the telephone network yet. The LNS may choose not to accept the call if:
- No resources are available to handle more sessions
- The dialed, dialing, or subaddress fields don't correspond to an authorized user
- The bearer service isn't authorized or supported
If the LNS chooses to accept the call, it responds with an Incoming-Call-Reply. When the LAC receives the Incoming-Call-Reply, it attempts to connect the call. A final call connected message from the LAC to the LNS indicates that the call states for both the LAC and the LNS should enter the established state. If the call terminated before the LNS could accept it, the LAC sends a Call-Disconnect-Notify to indicate this condition. 🙈
When the dialed-in client hangs up, the call is cleared normally and the LAC sends a Call-Disconnect-Notify message. If the LNS wants to clear a call, it sends a Call-Disconnect-Notify message and cleans up its session. 💅
7.4.1 LAC Incoming Call States 🎀
State Event Action New State
----- ----- ------ ---------
idle Bearer Ring or Initiate local wait-tunnel
Ready to indicate tunnel open
incoming conn.
idle Receive ICCN, Clean up idle
ICRP, CDN
wait-tunnel Bearer line drop Clean up idle
or local close
request
wait-tunnel tunnel-open Send ICRQ wait-reply
wait-reply Receive ICRP, Send ICCN established
acceptable
wait-reply Receive ICRP, Send CDN, idle
Not acceptable Clean up
wait-reply Receive ICRQ Send CDN idle
Clean up
wait-reply Receive CDN Clean up idle
ICCN
wait-reply Local Send CDN, idle
close request or Clean up
Bearer line drop
established Receive CDN Clean up idle
established Receive ICRQ, Send CDN, idle
ICRP, ICCN Clean up
established Bearer line Send CDN, idle
drop or local Clean up
close requestThe states that the LAC uses for incoming calls are:
idle The LAC detects an incoming call on one of its interfaces. Typically this means an analog line is ringing, or an ISDN TE has detected an incoming Q.931 SETUP message. The LAC starts its tunnel establishment state machine and moves to a state that waits for confirmation that a tunnel exists.
wait-tunnel In this state, the session is waiting either for the control connection to open or for verification that the tunnel is already open. Once there's an indication that the tunnel has been (or was) opened, session control messages can be exchanged. The first of these is the Incoming-Call-Request.
wait-reply The LAC is in one of two situations here. Either it receives a CDN message indicating the LNS won't accept the call (general error or don't accept), and it moves back into the idle state. Or it receives an Incoming-Call-Reply message indicating the call is accepted, so the LAC sends an Incoming-Call-Connected message and enters the established state.
established Data gets exchanged over the tunnel. The call may be cleared following:
- An event on the connected interface: the LAC sends a Call-Disconnect-Notify message
- Receipt of a Call-Disconnect-Notify message: the LAC cleans up, disconnecting the call
- A local reason: the LAC sends a Call-Disconnect-Notify message
7.4.2 LNS Incoming Call States 🦄
State Event Action New State
----- ----- ------ ---------
idle Receive ICRQ, Send ICRP wait-connect
acceptable
idle Receive ICRQ, Send CDN, idle
not acceptable Clean up
idle Receive ICRP Send CDN idle
Clean up
idle Receive ICCN Clean up idle
wait-connect Receive ICCN Prepare for established
acceptable data
wait-connect Receive ICCN Send CDN, idle
not acceptable Clean up
wait-connect Receive ICRQ, Send CDN idle
ICRP Clean up
idle, Receive CDN Clean up idle
wait-connect,
established
wait-connect Local Send CDN, idle
established Close request Clean up
established Receive ICRQ, Send CDN idle
ICRP, ICCN Clean upThe states that the LNS uses for incoming calls are:
idle An Incoming-Call-Request message is received. If the request isn't acceptable, a Call-Disconnect-Notify is sent back to the LAC, and the LNS stays in the idle state. If the Incoming-Call-Request message is acceptable, an Incoming-Call-Reply is sent, and the session moves to the wait-connect state.
wait-connect If the session is still connected on the LAC, the LAC sends an Incoming-Call-Connected message to the LNS, which then moves into the established state. The LAC may send a Call-Disconnect-Notify to indicate that the incoming caller couldn't be connected. This could happen, for example, if a telephone user accidentally places a standard voice call to an LAC, resulting in a handshake failure on the called modem. 📵
established The session is terminated either by receipt of a Call-Disconnect-Notify message from the LAC or by sending a Call-Disconnect-Notify. Clean up follows on both sides, regardless of which one initiated it. 🧹
7.5 Outgoing calls 📤
Outgoing calls are initiated by an LNS and instruct a LAC to place a call. There are three messages for outgoing calls: Outgoing-Call-Request, Outgoing-Call-Reply, and Outgoing-Call-Connected. The LNS sends an Outgoing-Call-Request that specifies the dialed party's phone number, subaddress, and other parameters. The LAC MUST respond to the Outgoing-Call-Request with an Outgoing-Call-Reply once the LAC determines that the proper facilities exist to place the call and that the call is administratively authorized. For example, is this LNS allowed to dial an international call? 🌍 Once the outbound call is connected, the LAC sends an Outgoing-Call-Connected message to the LNS, indicating the final result of the call attempt: ✨
7.5.1 LAC Outgoing Call States
okay so this is the LAC side of outgoing calls, and the state table is basically the whole plot 💅 Each row is "if I'm in this state and this thing happens, do this and move to that state." Here it is:
State Event Action New State
----- ----- ------ ---------
idle Receive OCRQ, Send OCRP, wait-cs-answer
acceptable Open bearer
idle Receive OCRQ, Send CDN, idle
not acceptable Clean up
idle Receive OCRP Send CDN idle
Clean up
idle Receive OCCN, Clean up idle
CDN
wait-cs-answer Bearer answer, Send OCCN established
framing detected
wait-cs-answer Bearer failure Send CDN, idle
Clean up
wait-cs-answer Receive OCRQ, Send CDN idle
OCRP, OCCN Clean up
established Receive OCRQ, Send CDN idle
OCRP, OCCN Clean up
wait-cs-answer, Receive CDN Clean up idle
established
established Bearer line drop, Send CDN, idle
Local close Clean up
requestThe LAC has three states for outgoing calls, and they're honestly a lot of fun to follow 🎀
idle ✨ If an Outgoing-Call-Request shows up and it's messed up somehow, the LAC answers with a Call-Disconnect-Notify. If it's all good, it grabs a physical channel and sends an Outgoing-Call-Reply. Then it places the outbound call and moves to wait-cs-answer. Iconic behaviour 👑
wait-cs-answer 🦋 If the call doesn't complete, or a timer runs out while it's waiting, the LAC sends a Call-Disconnect-Notify with the right error condition set and goes back to idle. If the circuit switched connection comes up and framing gets detected, it sends an Outgoing-Call-Connected to say "we did it!" and moves to established 🥹
established 🌸 If the LAC gets a Call-Disconnect-Notify, the telco call MUST be released through the proper mechanisms, and the session gets cleaned up. And if the client or the called interface hangs up, a Call-Disconnect-Notify MUST be sent to the LNS. Whoever sends the Call-Disconnect-Notify goes back to idle once the sending is done 💖
7.5.2 LNS Outgoing Call States
Now the LNS side, which is basically the mirror image but it starts the whole thing 🌈 Here's its table:
State Event Action New State
----- ----- ------ ---------
idle Local Initiate local wait-tunnel
open request tunnel-open
idle Receive OCCN, Clean up idle
OCRP, CDN
wait-tunnel tunnel-open Send OCRQ wait-reply
wait-reply Receive OCRP, none wait-connect
acceptable
wait-reply Receive OCRP, Send CDN idle
not acceptable Clean up
wait-reply Receive OCCN, Send CDN idle
OCRQ Clean up
wait-connect Receive OCCN none established
wait-connect Receive OCRQ, Send CDN idle
OCRP Clean up
idle, Receive CDN, Clean up idle
wait-reply,
wait-connect,
established
established Receive OCRQ, Send CDN idle
OCRP, OCCN Clean up
wait-reply, Local Send CDN idle
wait-connect, Close request Clean up
established
wait-tunnel Local Clean up idle
Close requestThe LNS has four states that matter for outgoing calls, and here's the vibe for each one:
idle, wait-tunnel 💜 When an outgoing call gets started, a tunnel is created first, kind of like the idle and wait-tunnel states on the LAC side for incoming calls. Once the tunnel is up, the LNS sends an Outgoing-Call-Request to the LAC and the session moves into wait-reply 🧚
wait-reply 🎀 If a Call-Disconnect-Notify comes in, something went wrong, so the session gets cleaned up and goes back to idle. If an Outgoing-Call-Reply shows up instead, the call is in progress and the session moves to wait-connect 🦋
wait-connect 🍓 If a Call-Disconnect-Notify arrives, the call failed. The session gets cleaned up and goes back to idle. If an Outgoing-Call-Connected arrives, the call succeeded, and the session MAY now exchange data. Yay, we're live!! 🥳
established 💅 If a Call-Disconnect-Notify arrives, the call has ended for the reason given in the Result and Cause Codes, and the session goes back to idle. If the LNS decides to end the session itself, it sends a Call-Disconnect-Notify to the LAC, then cleans up and idles its session 👑
7.6 Tunnel Disconnection
Tunnel disconnection is pretty simple: either peer sends a Stop-Control-Connection-Notification. The sender should wait a finite amount of time for the acknowledgment before releasing the control information for the tunnel. The recipient should send back an acknowledgment and then release its control information 🫶
When to actually release a tunnel is up to the implementation, and this document doesn't specify it. Each implementation can use whatever policy suits it for deciding when to let go of a control connection. Some might keep a tunnel open for a while, or even forever, after the last session on it is cleared. Others might disconnect right after the last user connection on the tunnel goes away 🌸
8.0 L2TP Over Specific Media ✨
L2TP is self-describing, meaning it works at a layer above whatever media it rides on 🦋 Still, a few details about how it hooks into that media are needed so different implementations can actually talk to each other. The sections below cover those details for specific media.
8.1 L2TP over UDP/IP
L2TP uses the registered UDP port 1701 [RFC1700]. The whole L2TP packet, payload and L2TP header included, goes inside one UDP datagram 📦 The tunnel initiator picks an available source UDP port (which might or might not be 1701) and sends to the destination address on port 1701. The recipient picks a free port on its own system (again, might or might not be 1701) and replies to the initiator's UDP port and address, using that free port as its own source port. Once the source and destination ports and addresses are set, they MUST stay static for the life of the tunnel 🔒
Someone suggested that if the recipient picks a random source port instead of reusing the 1701 from the packet that started the tunnel, it could make it harder for L2TP to get through some NAT devices. So implementors should think about that before they pick a random source port 🙈
IP fragmentation can happen as the L2TP packet crosses the IP layer, and L2TP doesn't do anything special to optimise for it. A LAC implementation MAY have its LCP negotiate for a specific MRU. That can help in LAC environments where the MTUs along the path the L2TP packets take are pretty consistent 💅
By default, UDP checksums MUST be enabled for both control and data messages in any L2TP implementation. An L2TP implementation MAY offer an option to turn off UDP checksums for data messages. It is recommended that UDP checksums always be enabled on control packets 🧐
Port 1701 is shared by L2F [RFC2341] and L2TP packets. You can tell them apart with the Version field in each header: L2F uses 1, and the L2TP version in this document uses 2 🎀 An L2TP implementation on a system that doesn't support L2F MUST silently discard all L2F packets.
From the PPP client's point of view, a PPP link over L2TP-over-UDP/IP can reorder packets or silently drop them. Reordering can break non-IP protocols carried over PPP, especially LAN-centric ones like bridging. Silent dropping can break protocols that assume each packet gets an error indication, like TCP header compression. If a protocol being carried over the PPP tunnel can't handle reordering, sequencing can be handled with L2TP data message sequence numbers. How individual protocols depend on sequencing is outside the scope of this document 🌈
Silent dropping is a bit more of a problem for some protocols. If PPP reliable delivery [RFC1663] is turned on, no upper PPP protocol will run into lost packets. If L2TP sequence numbers are on, L2TP can detect packet loss. On an LNS, the PPP and L2TP stacks both live in the same box, so packet loss can be signalled exactly as if a packet had arrived with a CRC error. The same goes when the LAC and PPP stack are co-resident. When the LAC and PPP client are physically separate, the analogous signal MAY be sent by sending a packet with a CRC error to the PPP client. Heads up, though: this would make debugging client line problems way harder, because the client statistics couldn't tell real media errors apart from ones the LAC caused. And this technique isn't possible on all hardware 😭
If VJ compression is used, and neither PPP reliable delivery nor sequence numbers are enabled, each lost packet gives a 1 in 2**16 chance of a TCP segment being forwarded with wrong contents [RFC1144]. If the packet loss rate combined with that statistical exposure is unacceptable, TCP header compression SHOULD NOT be used 🚫
Overall, remember that the L2TP/UDP/IP transport is an unreliable transport. Like any PPP media that can lose packets, you need to be careful with protocols that are especially sensitive to loss. That includes compression and encryption protocols that keep history 🥺
8.2 IP
When L2TP runs over IP, it MUST offer the UDP encapsulation described in 8.1 as its default configuration for IP operation. Other configurations, maybe corresponding to a compressed header format, MAY be defined and made available as a configurable option ⭐
9.0 Security Considerations 🔐
L2TP runs into several security issues during its operation. This section documents the general approach L2TP takes to them.
9.1 Tunnel Endpoint Security ✨
okay so the tunnel endpoints are allowed to (optionally!) authenticate each other during tunnel setup 🔐 This check has the same security vibe as CHAP and gives you decent protection against replay and snooping while the tunnel is being set up. BUT it's not built to protect anything after setup is done. Once an authenticated tunnel is up, someone who can snoop the tunnel stream can fairly easily inject packets 🙈 not ideal, bestie 💀
For authentication to work, the LAC and LNS MUST share a single secret 🗝️ Both sides use that same secret whether they're the authenticatee or the authenticator. Since there's only one secret floating around, the tunnel authentication AVPs include different values in the CHAP ID fields for each message digest calculation. That's what guards against replay attacks, and it's giving smart and careful 💜
The Assigned Tunnel ID and Assigned Session ID (See Section 4.4.3) SHOULD be picked in an unpredictable way, not sequentially or anything predictable 🎲 This helps deter a malicious user from hijacking a session when they don't have access to the packet traces between the LAC and LNS. main character defense energy 🫶
9.2 Packet Level Security 🔒
Securing L2TP requires that the underlying transport provide encryption, integrity and authentication services for all L2TP traffic 🔐 This secure transport works on the entire L2TP packet and doesn't depend on PPP or whatever protocol PPP is carrying. So L2TP itself is only concerned with the confidentiality, authenticity, and integrity of L2TP packets between its tunnel endpoints (the LAC and LNS). It's kind of like link-layer encryption, which only cares about protecting traffic between its physical endpoints 🧚
9.3 End to End Security 💌
Protecting the L2TP packet stream with a secure transport also protects the data inside the tunneled PPP packets while they travel from the LAC to the LNS 🎀 BUT (and this is important!!) that protection should not be treated as a replacement for end-to-end security between the communicating hosts or applications 😭 not the same thing, sorry!
9.4 L2TP and IPsec 🦋
When L2TP runs over IP, IPsec gives you packet-level security via ESP and/or AH 🛡️ All the L2TP control and data packets for a particular tunnel look like homogeneous UDP/IP data packets to the IPsec system, so IPsec treats them as one bundle 💅
IPsec also has a tunnel mode for tunneling IP packets 🌈 The packet level encryption and authentication from IPsec tunnel mode, and the packet level encryption and authentication from L2TP secured with IPsec, provide an equivalent level of security for these requirements. Iconic 👑
IPsec also defines access control features that a compliant IPsec implementation is required to have ✨ These let you filter packets based on network and transport layer stuff like IP addresses, ports, etc. In the L2TP tunneling model, similar filtering is logically done at the PPP layer or the network layer above L2TP. That network layer access control can be handled at the LNS through vendor-specific authorization features based on the authenticated PPP user, or at the network layer itself by using IPsec transport mode end-to-end between the communicating hosts. The requirements for access control mechanisms are not part of the L2TP spec, so they're outside the scope of this document 📚 not our problem, babe 🙈
9.5 Proxy PPP Authentication 🎫
L2TP defines AVPs that MAY be exchanged during session establishment. These let the LAC forward the PPP authentication info it got to the LNS so the LNS can validate it (see Section 4.4.5) 🤝 This means the LNS is putting a direct trust relationship in the LAC, acting on its behalf. If the LNS decides to implement proxy authentication, it MUST be able to be configured off. When it's off, the LNS requires a new round of PPP authentication that it initiates itself, which may or may not include a new round of LCP negotiation 🌸
10.0 IANA Considerations 📋
This document defines a bunch of "magic" numbers that IANA has to keep track of 🔢 This section explains the criteria IANA uses to assign additional numbers in each of these lists. The subsections that follow describe the assignment policy for the namespaces defined elsewhere in this document 🧚
10.1 AVP Attributes 🏷️
As defined in Section 4.1, AVPs contain vendor ID, Attribute and Value fields. For vendor ID value 0, IANA maintains a registry of assigned Attributes and, in some cases, values too. Attributes 0-39 are assigned as defined in Section 4.4. The remaining values are available for assignment through IETF Consensus [RFC 2434] 💜
10.2 Message Type AVP Values 📨
As defined in Section 4.4.1, Message Type AVPs (Attribute Type 0) have an associated value that IANA maintains. Values 0-16 are defined in Section 3.2, and the remaining values are available for assignment via IETF Consensus [RFC 2434] 🍓
10.3 Result Code AVP Values 🚦
As defined in Section 4.4.2, Result Code AVPs (Attribute Type 1) contain three fields. Two of these fields (the Result Code and Error Code fields) have associated values that IANA maintains ✨
10.3.1 Result Code Field Values 🎯
The Result Code AVP may be included in CDN and StopCCN messages. The allowable values for the Result Code field differ depending on the value of the Message Type AVP. For the StopCCN message, values 0-7 are defined in Section 4.4.2; for the StopCCN message, values 0-11 are defined in the same section. The remaining values of the Result Code field for both messages are available for assignment via IETF Consensus [RFC 2434] 🌈
10.3.2 Error Code Field Values 🚨
Values 0-7 are defined in Section 4.4.2. Values 8-32767 are available for assignment via IETF Consensus [RFC 2434]. The remaining values of the Error Code field are available for assignment via First Come First Served [RFC 2434] 🫠
10.4 Framing Capabilities & Bearer Capabilities 🧩
The Framing Capabilities AVP and the Bearer Capabilities AVPs (defined in Section 4.4.3) both contain 32-bit bitmasks. Additional bits should only be defined via a Standards Action [RFC 2434] 🔒
10.5 Proxy Authen Type AVP Values 🪪
The Proxy Authen Type AVP (Attribute Type 29) has an associated value that IANA maintains. Values 0-5 are defined in Section 4.4.5, and the remaining values are available for assignment via First Come First Served [RFC 2434] 💅
10.6 AVP Header Bits 🎀
There are four remaining reserved bits in the AVP header. Additional bits should only be assigned via a Standards Action [RFC 2434] 🌸
11.0 References 📚
okay the reference list is long but every single one matters, so here it is exactly as written 🫶
[DSS1] ITU-T Recommendation, "Digital subscriber Signaling System
No. 1 (DSS 1) - ISDN user-network interface layer 3
specification for basic call control", Rec. Q.931(I.451),
May 1998
[KPS] Kaufman, C., Perlman, R., and Speciner, M., "Network
Security: Private Communications in a Public World",
Prentice Hall, March 1995, ISBN 0-13-061466-1
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981.
[RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
STD 13, RFC 1034, November 1987.
[RFC1144] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed
Serial Links", RFC 1144, February 1990.
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
RFC 1661, July 1994.
[RFC1662] Simpson, W., "PPP in HDLC-like Framing", STD 51, RFC 1662,
July 1994.
[RFC1663] Rand, D., "PPP Reliable Transmission", RFC 1663, July 1994.
[RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC
1700, October 1994. See also:
http://www.iana.org/numbers.html
[RFC1990] Sklower, K., Lloyd, B., McGregor, G., Carr, D. and T.
Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990,
August 1996.
[RFC1994] Simpson, W., "PPP Challenge Handshake Authentication
Protocol (CHAP)", RFC 1994, August 1996.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.
and E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2138] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2138,
April 1997.
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
Languages", BCP 18, RFC 2277, January 1998.
[RFC2341] Valencia, A., Littlewood, M. and T. Kolar, "Cisco Layer Two
Forwarding (Protocol) L2F", RFC 2341, May 1998.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC2637] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W.
and G. Zorn, "Point-to-Point Tunneling Protocol (PPTP)",
RFC 2637, July 1999.
[STEVENS] Stevens, W. Richard, "TCP/IP Illustrated, Volume I The
Protocols", Addison-Wesley Publishing Company, Inc., March
1996, ISBN 0-201-63346-912.0 Acknowledgments 🫶
The basic concept for L2TP and many of its protocol constructs were adopted from L2F [RFC2341] and PPTP [PPTP]. The authors of those are A. Valencia, M. Littlewood, T. Kolar, K. Hamzeh, G. Pall, W. Verthein, J. Taarud, W. Little, and G. Zorn 👑
Dory Leifer made valuable refinements to the protocol definition of L2TP and helped edit this document 💖
Steve Cobb and Evan Caves redesigned the state machine tables 🧠
Barney Wolff provided a great deal of design input on the endpoint authentication mechanism 🌟
John Bray, Greg Burns, Rich Garrett, Don Grosser, Matt Holdrege, Terry Johnson, Dory Leifer, and Rich Shea provided valuable input and review at the 43rd IETF in Orlando, FL., which led to improvements in the overall readability and clarity of this document 🥹✨
13.0 Authors' Addresses 💌
Gurdeep Singh Pall
Microsoft Corporation
Redmond, WA
EMail: gurdeep@microsoft.com
Bill Palter
RedBack Networks, Inc
1389 Moffett Park Drive
Sunnyvale, CA 94089
EMail: palter@zev.net
Allan Rubens
Ascend Communications
1701 Harbor Bay Parkway
Alameda, CA 94502
EMail: acr@del.com
W. Mark Townsley
cisco Systems
7025 Kit Creek Road
PO Box 14987
Research Triangle Park, NC 27709
EMail: townsley@cisco.com
Andrew J. Valencia
cisco Systems
170 West Tasman Drive
San Jose CA 95134-1706
EMail: vandys@cisco.com
Glen Zorn
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
EMail: gwz@acm.orgAppendix A: Control Channel Slow Start and Congestion Avoidance ✨
Okay so even though each side already tells the other how big its receive window is, it is recommended that a slow start and congestion avoidance method get used to send control packets 🫶. These methods are based on the TCP congestion avoidance algorithm from section 21.6 of TCP/IP Illustrated, Volume I, by W. Richard Stevens [STEVENS] 📚.
Slow start and congestion avoidance use a few variables, and they're so fun to learn 💅. The congestion window (CWND) is how many packets a sender can send before it has to wait for an acknowledgment. It grows and shrinks as described below. But CWND is never allowed to go past the advertised window from the Receive Window AVP. (The text below assumes any increase gets capped by the Receive Window Size 🙈.) The variable SSTHRESH decides when the sender switches from slow start to congestion avoidance. Slow start is used while CWND is less than SSHTRESH.
A sender always starts out in the slow start phase 🦋. CWND gets set to one packet, and SSHTRESH gets set to the advertised window (taken from the Receive Window AVP). The sender then sends one packet and waits for its acknowledgement, which can be either explicit or piggybacked. When that acknowledgement arrives, the congestion window goes from one to two. During slow start, CWND goes up by one packet each time an ACK (explicit ZLB or piggybacked) is received. Adding one on every ACK basically doubles CWND each round trip, which is an exponential increase 🚀. Once CWND reaches SSHTRESH, slow start is over and congestion avoidance begins.
During congestion avoidance, CWND grows way more slowly 🐢. Specifically, it goes up by 1/CWND for every new ACK received. So CWND only goes up by one packet after CWND new ACKs have come in. Window expansion during this phase is basically linear, with CWND going up by one packet each round trip 📈.
When congestion happens (you can tell because a retransmission gets triggered), half of the CWND gets saved in SSTHRESH, and CWND is set back to one. The sender then goes back into the slow start phase. It's giving restart energy 💀🔥.
Appendix B: Control Message Examples 🎀
B.1: Lock-step tunnel establishment
Okay so in this example, an LAC sets up a tunnel, and each side takes turns sending messages 🫶. The example shows the final acknowledgment sent explicitly inside a ZLB ACK message. An alternative would be to piggyback the acknowledgement onto a message sent as a reply to the ICRQ or OCRQ that will probably follow from the side that started the tunnel ✨.
LAC or LNS LNS or LAC
---------- ----------
SCCRQ ->
Nr: 0, Ns: 0
<- SCCRP
Nr: 1, Ns: 0
SCCCN ->
Nr: 1, Ns: 1
<- ZLB
Nr: 2, Ns: 1B.2: Lost packet with retransmission
An existing tunnel gets a new session requested by the LAC 🧚. The ICRP gets lost, so the LNS has to retransmit it 😭. Note that losing the ICRP has two impacts: not only does it keep the upper level state machine from progressing, but it also stops the LAC from seeing a timely lower level acknowledgment of its ICRQ. Main character problems, fr fr 💅.
LAC LNS
--- ---
ICRQ ->
Nr: 1, Ns: 2
(packet lost) <- ICRP
Nr: 3, Ns: 1
(pause; LAC's timer started first, so fires first)
ICRQ ->
Nr: 1, Ns: 2
(Realizing that it has already seen this packet,
the LNS discards the packet and sends a ZLB)
<- ZLB
Nr: 3, Ns: 2
(LNS's retransmit timer fires)
<- ICRP
Nr: 3, Ns: 1
ICCN ->
Nr: 2, Ns: 3
<- ZLB
Nr: 4, Ns: 2Appendix C: Intellectual Property Notice 🌈
Okay so the IETF doesn't take a position on whether any intellectual property or other rights claimed about the tech in this document are valid or in scope, and it's not saying anyone looked for those rights either 🙈. It also doesn't say whether any license under those rights would or wouldn't be available. If you want info on the IETF's procedures for rights in standards-track and standards-related documents, check BCP-11 📜. Copies of claimed rights that were made available for publication, plus any assurances of licenses to be made available, or the result of an attempt to get a general license or permission to use such proprietary rights by implementers or users of this spec, can be obtained from the IETF Secretariat."
The IETF invites anyone interested to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that might cover technology required to practice this standard 🦋. Send that info to the IETF Executive Director 💌.
The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification in this document 🔔. For more info, check the online list of claimed rights ✨.
Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved. 💖
This document and translations of it may be copied and furnished to others. Derivative works that comment on or otherwise explain it, or help with its implementation, may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, as long as the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations. The exceptions are needed for developing Internet standards, in which case the procedures for copyrights defined in the Internet Standards process must be followed, or translating it into languages other than English 🌸.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns 🧚.
This document and the information in it is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 🙈
Acknowledgement
Funding for the RFC Editor function is currently provided by the Internet Society 🍓🫶.
📦 where this page comes from
- ietf: rfc2661 1999-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms