Summary

  • RFC 3437 let an L2TP access concentrator send desired and permitted LCP options to the remote network server, then required the server to return its last sent and received Configure-Requests after negotiation.
  • Those four AVPs transferred local knowledge and evidence, not control. Preference was not permission, a packet copy was not a service outcome, and mandatory support could trade compatibility for visibility.

The machine at the wire did not own the session

A dial or access line has facts that are difficult to see from the far end of a tunnel. It may require a particular maximum receive unit, escape certain control characters, compress PPP fields, or use an alternative frame check sequence. In L2TP, the L2TP Access Concentrator (LAC) stood beside that physical medium. The L2TP Network Server (LNS), often far away, terminated the logical PPP session and ran the Link Control Protocol.

That division was useful, but it divided knowledge from authority. Base L2TP offered coarse descriptions such as synchronous or asynchronous and digital or analog. They were not a complete account of the local framing interface. The LNS could own negotiation while lacking details the LAC could observe directly.

Published in December 2002, RFC 3437 built a narrow bridge across that gap. Its text, RFC Editor record, Datatracker page, history, references, later citations and errata search establish the documentary record. None proves that a named vendor implemented the extension or that any subscriber session succeeded.

Proxy LCP was useful and incomplete

PPP used LCP Configure-Requests, acknowledgements and rejections to establish link behavior. PPP in HDLC-like framing made options such as ACCM, PFC, ACFC and FCS behavior concrete at the line. LCP extensions and CHAP illustrate how link negotiation could reach beyond simple framing.

An LAC could perform Proxy LCP before handing a call to the LNS. That saved time and allowed the device nearest the medium to settle local parameters. Yet the proxy could not safely decide everything. Authentication policy belonged at the LNS. MRU could be constrained at both ends. More fundamentally, a PPP peer could reopen LCP after setup. A snapshot taken at admission could become stale while the session lived.

RFC 3437 therefore allowed the LAC to omit the older Proxy LCP AVPs and force the LNS to negotiate. It also allowed the new AVPs to coexist with proxy results. The design did not declare one workflow universally superior; it made the information boundary explicit.

Four records, four meanings

The LAC could put LCP Want Options, attribute 49, and LCP Allow Options, attribute 50, into an ICCN or OCCN message. Want was a preference: options the access side would like the LNS to negotiate. Allow was a boundary: options the physical interface could support. An option could be allowed without being wanted, or wanted without being accepted by the peer. Merging both into a single “capabilities” field would erase the very policy distinction the extension introduced.

After LCP finished, the LNS sent Set-Link-Info with LNS Last Sent LCP Confreq, attribute 51, and LNS Last Received LCP Confreq, attribute 52. Each carried a full LCP packet beginning with the Code field. They told the LAC what the last Configure-Requests actually looked like on each side of the exchange.

Direction mattered. Want and Allow moved physical-edge knowledge toward the session controller. The two Confreq records moved negotiation evidence back. If a LAC sent either forward AVP, it had to be able to receive and process the reverse ones. This was a reconciliation loop, not four interchangeable flags.

The returned packets still did not prove authentication, network-layer configuration, accounting, reachability or application success. They were stronger evidence than a desired-options list and weaker evidence than a completed user outcome.

Optional compatibility could hide the evidence

All four AVPs were non-mandatory by default. An older peer could ignore an unsupported optional AVP and continue. Setting the M bit could instead require the peer to terminate the session if it did not understand the extension. RFC 3437 discouraged that choice unless operating without the extension was completely unacceptable.

That warning exposes an operational bargain. Optionality protected availability but could leave the access edge without the evidence it wanted. Mandatory support improved enforcement only by making lack of support fatal. Operators needed to observe negotiated support rather than assuming that configured AVPs arrived.

The authors also allocated new attribute numbers instead of reusing Proxy LCP values. An old implementation might recognize an existing AVP but reject it when it appeared in a message type where the old specification did not permit it. New numbers were a compatibility device: unknown optional data was safer than familiar data in an allegedly impossible place. The IANA L2TP registry records those assignments; the PPP Numbers registry records the wider negotiation vocabulary. A registry entry is coordination evidence, not deployment evidence.

Information transfer exposed information

The security section was brief but honest. Desired, allowed and negotiated link parameters could reveal interface characteristics and help an observer infer topology. The authors noted that similar facts could already be visible in the LCP packets carried through the tunnel. RFC 3437 changed the format and the points at which the information appeared; it did not invent the underlying facts.

Related documents show where the boundary sat. RFC 3145 addressed L2TP disconnect-cause information, another effort to preserve meaning across separated endpoints. RFC 3193 specified L2TP over IPsec and exposed different state and MTU concerns. RFC 3438 treated PPP tunneling over MPLS, while RFC 3931 later generalized L2TP version 3 beyond PPP. None turns an RFC 3437 AVP into proof of confidentiality or service delivery.

A small protocol for separated control surfaces

Heng Lu's account of reality layers clarifies the receipt chain. Want is declared intent. Allow is a stated constraint. A Configure-Request is an observed protocol message. Completed LCP is link state. Authentication and useful traffic are later events. Each deserves its own record.

The case also supports running-code primacy: only implementation evidence can show whether endpoints survive unknown AVPs, reopened LCP and error paths. The minimum-initial-specification lens explains the economy of four AVPs. The protocol moved the minimum knowledge needed across the tunnel while leaving local policy and adoption voluntary. These are retrospective editorial readings, not claims about the authors' motives.

RFC 3437's durable lesson is not that remote control is wrong. It is that remote control becomes credible only when local constraints and returned evidence remain distinguishable. The physical link knew something the tunnel terminator could not see. The standard did not pretend otherwise; it gave each side a precise way to say what it knew.

Sources