Summary
- RFC 3070 showed that L2TP could carry PPP sessions over Frame Relay only after operators agreed how to identify the protocol, map tunnels to PVCs or SVCs, name circuit endpoints and accommodate the resulting packet size.
- The specification separated a portable tunnel/session abstraction from the circuit that made it work; it standardized the seam but left provisioning, quality of service, security and user outcome under other authorities.
A small document about a large illusion
Published in February 2001, RFC 3070 specified how Layer Two Tunneling Protocol packets should be carried over Frame Relay. It is easy to read it as a narrow encapsulation note from an era of dial access and carrier clouds. Its more durable lesson is about the word independent.
L2TP had been designed to operate over many packet-oriented networks. A PPP session could begin near a caller at an L2TP Access Concentrator, or LAC, and terminate logically at an L2TP Network Server, or LNS. The tunnel between them made the access session less dependent on the details of the intervening medium. Yet a real packet could not cross Frame Relay merely because the higher layer declared itself media-independent. Someone still had to construct a virtual circuit, identify its endpoints, choose an encapsulation, size frames, and decide what happened when the bearer failed.
RFC 3070 therefore did not prove that L2TP had escaped its medium. It documented the contract by which one medium could support the abstraction.
A session and a circuit were different objects
RFC 2661 had already separated the L2TP control connection from the individual sessions multiplexed through a tunnel. Session identifiers belonged to the L2TP relationship between LAC and LNS. Frame Relay, however, offered virtual circuits. A permanent virtual circuit was ordinarily recognized locally by a Data Link Connection Identifier. A switched virtual circuit was established through signalling and addressed with X.121 or E.164 information.
Those identities could be associated, but they were not interchangeable. An L2TP tunnel identifier did not provision a carrier circuit. A DLCI did not describe which user's PPP session it carried. An endpoint number suitable for setting up an SVC did not establish that the remote LNS was authorized to receive a subscriber's traffic. Each identifier was evidence about a different layer.
This distinction becomes especially clear in the two mappings defined by RFC 3070. For an SVC, creation of an L2TP tunnel triggered establishment of the Frame Relay circuit. The precise trigger was implementation-dependent, and the document did not alter the signalling procedures used by Frame Relay. For a PVC, the circuit had to be administratively configured between L2TP endpoints. The DLCI could also be supplied through configuration or authorization systems, including the tunnel attributes defined for RADIUS in RFC 2868.
The convenient story was that the tunnel came up. The operational story was that a control event, an authorization decision and a bearer circuit had been made to correspond.
Media independence required a media-specific number
RFC 3070 required L2TP to share a Frame Relay virtual circuit with other protocols. A receiver therefore needed an unambiguous way to know what arrived. The prescribed frame used Q.922 addressing, followed by a SNAP header: NLPID 0x80, IANA's organisationally unique identifier 0x00-00-5E, and protocol identifier 0x0007 for L2TP.
These values look like small registry facts. They were the public seam between two systems. Without them, the bearer could carry bytes but could not reliably tell an L2TP packet from another protocol on the same circuit. The abstraction became portable because the underlying medium received a precise, media-specific label.
RFC 1490 and its successor RFC 2427 supplied the broader multiprotocol encapsulation rules. RFC 3070 did not replace that machinery; it occupied a defined place inside it. This is a recurring pattern in Internet architecture. A higher layer gains apparent independence by depending on a thinner, more stable interface below. The dependency becomes narrower and more inspectable, not nonexistent.
The missing frame left consequences behind
When a PPP frame entered L2TP, its physical-layer framing, transparency mechanisms and frame check sequence were removed before the PPP payload was encapsulated. That was necessary: the remote endpoint did not need every electrical or link-specific mark created on the access side. But stripping the old shell also meant the later packet did not carry a complete record of its physical history.
An operator observing the L2TP payload could verify the tunnel and session context available there. The operator could not infer, from that payload alone, the exact access framing, the quality of the original line, or whether an earlier link-layer check had nearly failed. Abstraction changed what evidence crossed the boundary.
Packet size exposed another consequence. RFC 3070 calculated that a Frame Relay network without fragmentation needed to support at least 1,526 octets to carry a minimum-compliant L2TP datagram, and recommended 1,564 octets to accommodate a PPP peer using the conventional 1,500-octet maximum receive unit. How an implementation enforced or negotiated those limits remained implementation-specific.
The tunnel could be media-independent in protocol design while the service still failed on a concrete MTU. A clean control-plane success was not proof that the intended user packet would traverse the path intact.
The standard stopped before service quality and trust
RFC 3070 explicitly declined to standardize quality of service for this mapping. It noted that vendors offered proprietary mechanisms and that broader standards work might later apply. It also observed that Frame Relay had no standard security mechanisms for this use and referred readers back to L2TP's security considerations.
Those omissions were honest boundary markers. They did not mean latency, loss, congestion, traffic isolation or confidentiality were unimportant. They meant the mapping document did not own those outcomes. A carrier could provision a circuit. A vendor could expose a priority feature. An L2TP deployment could use authentication or IP-layer protection. An operator could monitor packet loss. None of these authorities was created by the encapsulation number.
The allocation of control was distributed. IANA controlled registered identifiers. The IETF specified interoperable formats and behavior. A Frame Relay provider or network operator controlled circuit availability and characteristics. The LAC and LNS administrators controlled tunnel configuration. An authorization service could supply attributes. Implementations decided triggers and limit enforcement. The subscriber experienced the resulting service but controlled little of the path.
Later tunnelling did not rewrite the old circuit
RFC 3931 later generalized L2TP version 3 for pseudowires carrying a wider range of layer-two services. That successor history shows the continuing value of separating an emulated service from the packet network beneath it. It does not prove that RFC 3070 deployments automatically migrated, or that every operational dependency was absorbed into the newer design.
Protocol succession is not infrastructure succession. A standards document can be obsoleted, a feature can be added to software, and a circuit can remain provisioned for years. Conversely, a carrier can retire a bearer while configuration records, RADIUS attributes and troubleshooting assumptions survive. The archival question is therefore not simply which RFC was current. It is which executable and administrative dependencies still governed a particular service.
Lu Heng's running-code principle is useful here. Working software is strong evidence that a defined interface can be implemented. It is not evidence that the circuit was correctly provisioned, that the endpoints were legitimately authorized, that the MTU covered every traffic pattern, or that the service met its users' needs. His reality-layer framework adds the missing discipline: a tunnel identifier, a configured DLCI, a signalling exchange, a forwarded packet and a satisfactory connection are related facts, not one fact repeated five times.
RFC 3070 is historically valuable precisely because it did not conceal that difference. It made L2TP media-independent by naming what Frame Relay still had to do. The tunnel borrowed a circuit, and the quality of the abstraction depended on keeping the loan visible.
Sources
- https://www.rfc-editor.org/rfc/rfc3070.html
- https://www.rfc-editor.org/info/rfc3070/
- https://datatracker.ietf.org/doc/rfc3070/
- https://www.rfc-editor.org/rfc/rfc2661.html
- https://www.rfc-editor.org/rfc/rfc2868.html
- https://www.rfc-editor.org/rfc/rfc1490.html
- https://www.rfc-editor.org/rfc/rfc2427.html
- https://www.rfc-editor.org/rfc/rfc2119.html
- https://www.rfc-editor.org/rfc/rfc3931.html
- https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
- https://heng.lu/on-reality-layers-symbolic-power-and-why-clarity-feels-so-hostile/
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance
