RFC 3145

L2TP Disconnect Cause Information

📅 published July 2001, from ietf

RFC 3145: L2TP Disconnect Cause Information 💖

okay bestie, this one is a Standards Track spec (so it's a real protocol doc, not just a vibe) 🧚 It was written by R. Verma (Deloitte Consulting), M. Verma (3Com Corporation), and J. Carlson (Sun Microsystems), and it's dated July 2001. The title block doesn't list anything it obsoletes or updates. 🎀

Status of This Memo ✨

This document specifies an Internet standards track protocol for the Internet community, and it asks 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 (C) The Internet Society (2001). All Rights Reserved.

Abstract 🦋

Okay so this doc adds an extension to the Layer 2 Tunneling Protocol ("L2TP"), which is the mechanism for tunneling Point-to-Point Protocol (PPP) sessions. The lowkey problem is that L2TP has no way for one host to tell another host the PPP-related disconnect cause. This extension fixes that, and the info is super useful for accounting and debugging 🔥

1. Introduction 🌸

L2TP [1] is the general-purpose way to tunnel PPP over various media. It's designed to stay out of the details of the PPP session it's carrying, which is iconic of it honestly 💅 But there are times when PPP-specific disconnect info is needed by an L2TP host (an L2TP Access Concentrator [LAC] or an L2TP Network Server [LNS]), and it needs to be in a descriptive format. Not having that info is a big problem especially when the LAC and LNS aren't owned or managed by the same entities 😭

The Result and Error Codes that L2TP defines only cover L2TP-specific disconnect info. So this doc adds a new Attribute Value Pair (AVP) called PPP Disconnect Cause Code. An L2TP host MAY use it to send PPP-specific disconnect info to its peer. It should be used alongside the L2TP Result and Error Code AVPs, not instead of them 🫶

The PPP Disconnect Cause Code AVP can also carry a human-readable disconnect reason for the user. It should not affect the tunnel or the PPP session at all. It's just for info and logging 📝

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 BCP 14 [2]. ✨

2. PPP Disconnect Cause Code AVP 🎀

The AVP is only valid in the L2TP Call-Disconnect-Notify (CDN) message, and it MUST NOT be marked Mandatory. Don't be that person 🙈

The PPP Disconnect Cause Code AVP uses Vendor ID 0 and an Attribute Type of PPP Disconnect Cause Code (46). The Value field length MUST be at least 11 octets. If the length is more than 11 octets, the extra octets MUST hold descriptive text in UTF-8 [3] format that can be shown to the user or written to a log file. Here's 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |M|H| rsvd  |      Length       |          Vendor ID          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Attribute Type        |       Disconnect Code       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Control Protocol Number    |   Direction   | Message...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

Figure 1: PPP Disconnect Cause Code AVP

Here's what each field does:

  • Mandatory (M) bit: MUST be 0.
  • Hidden (H) bit: MAY be 1 if the attribute is hidden.
  • Length: The length of the entire attribute in octets, in a single octet. The length MUST be at least 11.
  • Vendor ID: A two octet value in network byte order. Set it to 0 to show this is an IETF-assigned attribute.
  • Attribute Type: A two octet value in network byte order. Set it to 46 (PPP Disconnect Cause Code).
  • Disconnect Code: A two octet value in network byte order. (More on this in section 3 of this doc 💜)
  • Control Protocol Number: The PPP Control Protocol number of the primary protocol known to have caused the error, if any. This field may be 0 unless the description of the Disconnect Codes in section 3 says otherwise.
  • Direction: A single octet value that says which direction the Disconnect Code applies to. The valid values are:
0: global error
1: at peer
2: at local
3-255: Reserved

This field SHOULD be 0 unless the description of the specific Disconnect Code documents otherwise. 🍓

3. Disconnect Codes 🦋

This section has the list of well-known values for the Disconnect Code field in the PPP Disconnect Cause Code AVP. The IANA will keep a registry of the up-to-date values (see section 5 of this doc, which is actually section 6 in the numbering, so check the IANA bit 👀). These values should be used together with the Direction value and the Control Protocol Number field to figure out the specific error condition.

Unless a specific Disconnect Code documents otherwise, the Direction value SHOULD be 0. ✨

3.1. Global Errors 🌍

The global error codes below are Disconnect Codes that don't relate to one particular PPP Control Protocol. So the Control Protocol Number for these errors MUST be set to 0.

0    No information available.

1    Administrative disconnect.

2    Link Control Protocol (LCP) renegotiation at LNS disabled; LNS
     expects proxy LCP information, LAC did not send it.

3    Normal Disconnection, LCP Terminate-Request sent.

     Valid Direction values are:

        1: LCP Terminate-Request sent by peer
        2: LCP Terminate-Request sent by local

4    Compulsory encryption required by a PPP peer was refused by the
     other.

     Valid Direction values are:

        1: Required by local; refused by peer
        2: Required by peer; refused by local

3.2. LCP Errors 🔐

The LCP error codes below are disconnect reasons that are directly tied to PPP peers failing to negotiate link parameters they can both agree on. The Control Protocol Number for these errors MUST be set to C021 hexadecimal (LCP). 💫

5    FSM (Finite State Machine) Timeout error.  (PPP event "TO-".)

6    No recognizable LCP packets were received.

7    LCP failure: Magic Number error; link possibly looped back.

8    LCP link failure: Echo Request timeout.

9    Peer has unexpected Endpoint-Discriminator for existing
     Multilink PPP (MP) bundle.

10   Peer has unexpected MRRU for existing MP bundle.

11   Peer has unexpected Short-Sequence-Number option for existing
     MP bundle.

12   Compulsory call-back required by a PPP peer was refused by the
     other.

     Valid Direction values are:

        1: Required by local; refused by peer
        2: Required by peer; refused by local

3.3. Authentication Errors 🔑

The authentication error codes below are disconnect reasons that are directly tied to authentication failures between PPP peers. The Control Protocol Number for these errors MUST correspond to the PPP Control Protocol number for the authentication protocol in use. 🙌

13   FSM Timeout error.

14   Peer has unexpected authenticated name for existing MP bundle.

15   PPP authentication failure: Authentication protocol
     unacceptable.

     Valid Direction values are:

        1: All local authentication protocols were rejected by the
           peer.

        2: All authentication protocols requested by peer were
           unacceptable or unimplemented locally.

16   PPP authentication failure: Authentication failed (bad name,
     password, or secret).

     Valid Direction values are:

        1: Authentication of peer identity by local system.
        2: Authentication of local identity by peer system.

3.4. Network Control Protocol (NCP) Errors 🌐

NCP Errors are disconnect reasons that are directly tied to PPP peers failing to agree on a set of parameters for the network protocols. The Control Protocol Number for these errors SHOULD correspond to the PPP Network Control Protocol number in use. If more than one network protocol is in use, multiple copies of this AVP MAY be given to show the failure reasons for each NCP. Otherwise, if only one copy of the AVP is given, the Control Protocol Number SHOULD correspond to the last (most recent) failing NCP. 💅

17   FSM Timeout error.

18   No NCPs available (all disabled or rejected); no NCPs went to
     Opened state.  (Control Protocol Number may be zero only if
     neither peer has enabled NCPs.)

19   NCP failure: failed to converge on acceptable addresses.

     Valid Direction values are:

        1: Too many Configure-Naks received from peer.
        2: Too many Configure-Naks sent to peer.

20   NCP failure: user not permitted to use any addresses.

     Valid Direction values are:

        1: Local link address not acceptable to peer.
        2: Remote link address not acceptable to local system.

4. Notes 📝

This AVP MAY may be sent by either the LNS or LAC. It's generally expected to be most useful for sending notifications from the LNS to the LAC in the compulsory tunneling case, though it's not ruled out in any other case 💜

A draft version of this AVP used Vendor ID 43 (3Com Corporation) and vendor-specific Attribute Type 46. Implementations MAY accept AVPs with these values as equivalent to the message described in this document, but SHOULD NOT transmit an AVP using these values. 🙈

5. Security Considerations 🔒

Okay, serious moment, but make it cute 🎀 The integrity and confidentiality of this AVP rely on the underlying L2TP security mechanisms. It's meant for logging and diagnostics when a PPP link fails, and it should not pose a threat to system security. The AVP MAY be hidden as described in section 4.3 of RFC 2661.

The defined extension does not provide information that would be useful to an attacker. Future extensions should not be defined to lessen security. For instance, it's inappropriate to provide distinguishing information that would tell the peer that a given authentication name is correct but the password/secret is incorrect. That's a major no-no, bestie 🚫

6. IANA Considerations 🧚

IANA has assigned an L2TP Attribute Type value of 46 for the PPP Disconnect Cause Code defined in Section 2. ✨

This AVP includes an enumerated cause code value called the "Disconnect Code." Values 0 through 20 are described in this document. Values 21 through 32767 (inclusive) are assigned by the IANA subject to IESG Approval. Values 32768 through 65279 (inclusive) are assigned by the IANA on a First Come First Served basis, and they're intended for vendor-specific features. Values 65280 through 65535 (inclusive) are allocated for Private or Experimental Use, and no assignment through the IANA is expected 🌈

7. References 📚

okay so the references are where the receipts live, bestie 🧾✨ there are three of them:

  • [1] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. and B. Palter, "Layer 2 Tunnel Protocol (L2TP)", RFC 2661, August 1999. 🦋
  • [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 💅
  • [3] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998. 🌈

8. Acknowledgments 🫶

the authors thank W. Mark Townsley and Thomas Narten for their comments and help. they're literally the best 🥹

9. Contacts 💌

9.1. L2TP Working Group Chair 🧚

W. Mark Townsley
Cisco Systems
7025 Kit Creek Road
PO Box 14987
Research Triangle Park, NC 27709

EMail:  townsley@cisco.com

9.2. Authors' Addresses 🌸

the three authors, with their addresses, phone numbers, fax numbers and emails, are listed below so you can reach them if you're obsessed with this stuff too 💖

Rohit Verma
180 N. Stetson Avenue
Chicago IL 60601

Phone:  +1 312 374 2475
Fax:    +1 312 870 2475
EMail:  rverma@dc.com


Madhvi Verma
3800 Golf Road
Rolling Meadows IL 60008

Phone:  +1 847 262 2987
Fax:    +1 847 262 2255
EMail:  Madhvi_Verma@3com.com


James Carlson
Sun Microsystems
1 Network Drive MS UBUR02-212
Burlington MA  01803-2757

Phone:  +1 781 442 2084
Fax:    +1 781 442 1677
EMail:  james.d.carlson@sun.com

10. Standard Notices 📢

10.1. IETF Intellectual Property Statement ⚖️

okay this part is a bit legal-coded, but it's important, so listen up 👑

the IETF takes no position on whether any intellectual property or other rights that someone might claim about the technology in this document are valid or in scope, or whether any license under those rights might or might not be available. it also doesn't say it has tried to find any such rights. info about how the IETF handles rights for standards-track and standards-related docs is in BCP 11. copies of claimed rights submitted for publication, and any assurances of licenses that will be made available, or the outcome of an attempt to get a general license or permission for implementers or users to use those proprietary rights, can be obtained from the IETF Secretariat 📬

the IETF also invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to practice this standard. please send that info to the IETF Executive Director 🫡

Copyright (C) The Internet Society (2001). All Rights Reserved. 💜

this document and translations of it may be copied and given to others. derivative works that comment on or otherwise explain it, or help with implementing it, may be prepared, copied, published and distributed, in whole or in part, with no 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 when it's needed for developing Internet standards, in which case the copyright procedures in the Internet Standards process must be followed, or when it's required to translate it into languages other than English 🌍

the limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. no take-backsies 🔒

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. thank you, Internet Society, you're iconic ✨

📦 where this page comes from