RFC 3437
Layer-Two Tunneling Protocol Extensions for PPP Link Control Protocol Negotiation
RFC 3437 ✨ Layer-Two Tunneling Protocol Extensions for PPP Link Control Protocol Negotiation
okay bestie, let's get into this one 🧚 It's an RFC from December 2002, and it's a Standards Track spec, so it's the real deal, not just a suggestion 💅
- Network Working Group
- Request for Comments: 3437 🎀
- Category: Standards Track 👑
- Authors: W. Palter (zev.net) and W. Townsley (Cisco Systems) 🫶
- Date: December 2002 🍓
- Obsoletes / Updates: the title block doesn't list anything it obsoletes or updates 🌸
Status of This Memo
ok so this part is the paperwork 🙈 It says this document specifies an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements. If you want to know where this protocol stands, check the current edition of the "Internet Official Protocol Standards" (STD 1). And distribution of this memo is unlimited, so share it with everyone 🦋
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved. 💜
Abstract
okay so this doc adds extensions to the Layer Two Tunneling Protocol (L2TP) to give better support for link-specific Point to Point Protocol (PPP) options 🔥 Normally, PPP endpoints are directly connected over the same physical media, so they know all the juicy details about the media in use 👀
Once L2TP is involved, though, the two PPP peers aren't directly connected over the same physical media anymore. L2TP adds a virtual connection over some or all of the PPP connection and tunnels PPP frames across a packet switched network, like IP 🌈 Sometimes an L2TP endpoint has to negotiate PPP Link Control Protocol (LCP) options from a spot that doesn't have all the media information it needs to participate properly in the LCP negotiation 😭
So this document gives a way for L2TP endpoints to share the LCP options they want before LCP negotiation happens at the far end of the L2TP tunnel. It also gives a way to send the negotiated LCP options back to where the native PPP link lives ✨
Table of Contents
1. Introduction............................................... 2
1.1 Specification of Requirements........................... 3
2. LCP Options From LAC to LNS................................ 3
2.1 LCP Want Options (iccn, occn)........................... 4
2.2 LCP Allow Options (iccn, occn).......................... 6
2.3 LCP Options From LNS to LAC............................. 7
3. Security Considerations.................................... 8
4. IANA Considerations........................................ 8
5. Normative References....................................... 8
6. Author's Addresses......................................... 9
7. Full Copyright Statement................................... 101. Introduction ✨
okay so L2TP [RFC2661] gives the LNS a very limited amount of guidance about what type of interface a tunneled PPP session arrived on at an LAC 🧐 All it tells the LNS is whether the interface was "synchronous" or "asynchronous", and whether it was "digital" or "analog." Those hints help a bit when the LNS negotiates PPP LCP, but they're not as robust as they could be 🙃
This document makes a more robust way to tell the LAC about the LCP options that were negotiated. It also gives the LNS guidance on the limits and values the LAC needs during LCP negotiation 💖 You'll need deep knowledge of PPP [RFC1661] and L2TP [RFC2661] for the rest of this doc, so grab your snacks 🍿
Proxy LCP lets options get negotiated where the native PPP link lives, which dodges problems with ACCM, Alternate FCS, and other LCP Options. The LNS wouldn't necessarily know how to negotiate those properly without access to the physical media, the interface type, or the configuration of the native PPP connection 😵💫 But using Proxy LCP brings its own problems, because there are options in LCP negotiation that the LNS should be setting or adjusting, like the PPP Authentication Type and MRU 💀 And here's the wild part: the PPP Client can restart LCP negotiation at any time, and unless the LAC is sniffing every PPP data packet it forwards, it has no idea that's happening 🙈
LCP options fall into roughly three categories when it comes to how they affect L2TP:
- options that affect framing in a way the LAC may need to know about or handle specifically (for example ALT-FCS, ACCM, and MRU),
- options that are mostly transparent to the LAC (for example AUTH-TYPE), and
- options the LAC may want to influence because they depend on the media type (ACFC and PFC).
We're mostly focused on categories (1) and (3) 🎀
This document defines new AVPs so the LAC and the LNS can share complete LCP information and react to it accordingly 🫶 The LCP option information is structured the same way the Proxy LCP AVPs are in [RFC2661]. Basically, it means wrapping a PPP LCP Configure-Request or Configure-Ack packet inside an L2TP AVP 🦋
1.1 Specification of Requirements
okay so this is the bit where the spec tells you how to read the big words 🤓 Several words are used to signal the requirements of the specification, and they're often capitalized. 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] 🔥
2. LCP Options From LAC to LNS 🌸
so the LAC can use the AVPs below inside an ICCN or OCCN message to nudge the LNS into negotiating LCP a certain way 🧚 If the LNS supports these AVPs, they should override any LCP option suggestions that come from the Bearer Type or Framing Type AVPs 💅
These AVPs can coexist with the Proxy LCP and Proxy Authentication AVPs (Proxy AVPs) from the base L2TP spec 💜 If Proxy AVPs show up, the LNS may decide to accept those parameters, or it may renegotiate LCP using the options suggested by the AVPs defined in this document. If the LAC wants to force the LNS to do the LCP negotiation, it should just leave out all the Proxy AVPs during call initialization 🫠
By default, the AVPs in this document aren't mandatory (the M-bit is set to zero) ✨ But if an implementation really needs to enforce the options in these AVPs, it MAY set the M-bit to 1. That forces the peer to end the session if it doesn't support this AVP 😤 This is NOT recommended unless you know that running without these extensions would be completely unacceptable 🚫
If the AVPs in sections 2.1 and 2.2 are sent to the LNS, the LAC MUST be prepared to accept the AVPs as defined in section 2.3 🌈
2.1 LCP Want Options (iccn, occn)
okay so the LCP Allow Options AVP (Attribute Type 49) holds a list of options the LAC wants the LNS to negotiate 👑
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 | LCP Configure-Req ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... LCP Configure-Req (continued) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The Vendor ID is the IETF Vendor ID of 0 🧸
This AVP MAY be hidden (the H bit MAY be 0 or 1) 🙈
The M bit for this AVP may be set to 0 or 1. If the sender of this AVP doesn't want to connect to a peer that doesn't understand this L2TP extension, it SHOULD set the M bit to 1. Otherwise, it MUST be set to 0 🎀
The Length (before hiding) of this AVP is 6 plus the length of the LCP Configure Request 🔢
The AVP SHOULD be present in the following messages: ICCN, OCCN 💖
The LCP Configure-Req Value for this AVP is identical to the information field of a PPP LCP Configure-Req Packet (much like a Proxy LCP AVP in [RFC2661]) 🫶 It's sent from the LAC to the LNS and is meant to guide the PPP LCP negotiations at the LNS. Sometimes each individual PPP LCP option in this AVP maps to a desired value (like MRU), and sometimes it maps to a specific option that should be enabled (like ACFC). The LNS should use these suggestions when it builds its initial Configure-Request 🧚
The chart below defines some of the more common LCP options that can go in this AVP, with guidance on how to handle them at the LAC and the LNS. It's only for some of the more common or problematic LCP options, and it's not meant to be an exhaustive list of all LCP options out there 🌈
LCP Want Option LAC Action LNS Action
MRU LAC provides a LNS SHOULD begin LCP
negotiation maximum
value with this value.
However, it MAY reduce
MRU if necessary.
ACCM LAC Provides a mask LNS SHOULD begin LCP
negotiation with this
value. LNS may add
bit(s) while
negotiating.
PFC LAC provides PFC LNS SHOULD begin LCP
on the link type negotiation if it is
desired with
the link type this value.
(e.g. AHDLC)
ACFC LAC provides ACCOMP LNS SHOULD begin LCP
if it is desired on negotiation with this
the link type value.
(e.g. AHDLC)
FCS-ALT LAC indicates required LNS SHOULD begin
values for the link negotiation with this
type value. Note that this
value is of no
consequence to the LNS
as FCS is stripped at
the LAC, however some
PPP media types require
this option.Part 1 wraps up right here, and there's a lot more coming in Part 2 with the rest of the LCP options and the security and IANA stuff 🦋💜
2.2 LCP Allow Options (iccn, occn) 💖
okay bestie, this one is the LCP Allow Options AVP, Attribute Type 50 🦋 it holds a list of options that the LAC will allow the LNS to negotiate. 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 | LCP Configure-Ack ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... LCP Configure-Ack (continued) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+the Vendor ID is the IETF Vendor ID of 0 🌸
this AVP MAY be hidden ✨ (the H bit MAY be 0 or 1). the M bit may be set to 0 or 1 too. but here's the tea 🫖: if the sender doesn't want to connect to a peer that doesn't understand this L2TP extension, it SHOULD set the M bit to 1. otherwise it MUST be set to 0. no wiggle room, periodt 💅
the Length (before hiding) of this AVP is 6 plus the length of the LCP Configure Request 🧚
the AVP MAY be present in the following messages: ICCN, OCCN 🎀
so the LCP Configure-Ack Value for this AVP is literally identical to the information field of a PPP LCP Configure-Req Packet 😭 it's kinda like a Proxy LCP AVP in [RFC2661]. it gets sent from the LAC to the LNS to guide PPP LCP negotiations at the LNS. sometimes each option in here maps to a maximum value (like MRU), and other times it maps to something the LAC is allowing (like ACFC). if an option isn't in here, the LNS can assume the LAC doesn't know how to do that option at the link layer, so it'd Configure-Reject it. use this info when building PPP Configure-Ack, Configure-Reject and Configure-Nak messages 🍓
this chart shows some of the more common LCP options that might be in this AVP, and how to handle them at the LAC and LNS 🌈 it's just for illustration, lowkey not a full list of every LCP option out there 🙈
LCP Allow Option LAC Action LNS Action
MRU LAC provides a LNS may accept reduction
maximum value MRU as requested.
ACCM LAC Provides a mask LNS may accept bit(s)
defined here. Note that
if ACCM is missing it is
assumed that it is not
applicable to the link
type.
PFC LAC provides PFC LNS may accept PFC.
if it is allowed on
the link type
(e.g. AHDLC)
ACFC LAC provides ACFC LNS may accept ACFC.
if it is allowed on
the link type
(e.g. AHDLC)
FCS-ALT LAC indicates valid Negotiation this option
values for the link is of no consequence to
type the LNS as the FCS is
stripped at the LAC.
However, the LNS SHOULD
only accept FCS-ALT types
listed here (more than
one
value may be present).2.3 LCP Options From LNS to LAC 🦋
okay so now we go the other way, from the LNS back to the LAC 🔥 to pass negotiated LCP parameters from the LNS to the LAC, the format of two existing messages in [RFC2661] gets reused. they are:
Last Sent LCP Confreq (IETF L2TP Attribute 27)
Last Received LCP Confreq (IETF L2TP Attribute 28)those AVPs go from the LAC to the LNS to support Proxy LCP negotiation 💜 and to report negotiated LCP parameters from the LNS to the LAC, two new messages with precisely the same format are defined:
LNS Last Sent LCP Confreq (IETF L2TP Attribute 51)
LNS Last Received LCP Confreq (IETF L2TP Attribute 52)when the LNS finishes LCP negotiation, a Set-Link-Info control message MUST be sent with these AVPs inside it ✨ and these AVPs MUST contain the last sent and last received LCP packets (from the LNS's point of view) 💅
the reason they got brand-new attribute types instead of just reusing the old ones in the SLI Message is kinda iconic 👑 some existing L2TP implementations might see what looks like known AVP types in the wrong place and throw a false error. so nobody gets confused 🙈
3. Security Considerations 🔐
ngl this section is short but serious 🫶 there are no known additional significant threats incurred by the mechanisms described in this document.
this document defines more L2TP AVPs that identify link characteristics and interface information of a tunneled PPP link. if somebody snoops these values, a rogue individual could learn more about a given network or topology 😳 but these same values may be negotiated over the tunneled link in PPP LCP packets anyway. so this isn't more info than what's already potentially sent today, it's just in a different form 🦋
4. IANA Considerations 🌸
this document requires four new L2TP "AVP Attribute" numbers to be assigned by IANA 🎀
49, Section 2.1, LCP Want Options
50, Section 2.2, LCP Allow Options
51, Section 2.3, LNS Last Sent LCP Confreq
52, Section 2.3, LNS Last Received LCP Confreq5. Normative References 📚
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
RFC 1661, July 1994.
[RFC 2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G.
and B. Palter, "Layer Two Tunneling Layer Two Tunneling
Protocol (L2TP)", RFC 2661, August 1999.6. Author's Addresses 💌
W. Mark Townsley
Cisco Systems
7025 Kit Creek Road
PO Box 14987
Research Triangle Park, NC 27709
EMail: mark@townsley.net
Bill Palter
EMail: palter.ietf@zev.net7. Full Copyright Statement ⭐
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.Acknowledgement 🫶
Funding for the RFC Editor function is currently provided by the
Internet Society.📦 where this page comes from
- ietf: rfc3437 2003-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms