Summary

  • RFC 2341 uses separate control state for an L2F tunnel and for each client connection; a tunnel OPEN is not a client acceptance receipt.
  • CLID, MID, challenge responses and Keys identify protocol contexts and protect a limited NAS–Home Gateway relationship. They do not establish a remote person's authority or an application identity.
  • L2F explicitly does not provide reliable delivery for data traffic. A healthy control plane therefore cannot prove that every frame arrived or that a usable service result followed.

The first receipt ends earlier than the dashboard suggests

RFC 2341 describes a virtual dial-up arrangement. A remote caller reaches an ISP's Network Access Server over PSTN or ISDN, but the PPP or SLIP connection is ultimately terminated at a Home Gateway elsewhere. L2F is the machinery that lets the physical access point and the link-layer termination point be different.

That architecture creates several boundaries that an operator can mistakenly collapse. The telephone call can be up while PPP is not ready. The NAS can discover an apparent identity and choose a Home Gateway while the gateway has not accepted the client. The L2F tunnel can be open while no client connection exists. A client connection can be accepted while later PPP authentication or network-layer configuration fails. Frames can be emitted while some never reach the other endpoint. An application can still fail after every lower layer succeeds.

The protocol itself models the first important separation. Tunnel establishment uses MID=0. The peers exchange L2F_CONF and L2F_OPEN, including names, challenges and assigned CLIDs. Once that exchange succeeds, the RFC says the tunnel is available for clients to be established. The wording is decisive: availability is a precondition for later work, not proof that the later work occurred.

Each client uses a nonzero MID and its own L2F_OPEN exchange. The NAS can include authentication type and information learned from CHAP, PAP or LCP. The Home Gateway's answering L2F_OPEN represents acceptance of that client connection. Only after this stage does the forwarding of PPP or SLIP frames begin. One green tunnel indicator can therefore coexist with zero accepted clients; one accepted client says nothing about another MID in the same tunnel.

Identifiers are routing handles, not biographies

CLID and MID make interleaved state manageable. CLID lets a recipient demultiplex tunnels when the lower transport does not reliably distinguish them. MID selects one client connection inside a tunnel. MID=0 is reserved for tunnel state, while nonzero values represent client state. A reused MID after closure must be initialized as a new connection.

Those properties are operationally useful, but their evidentiary meaning is narrow. A CLID points into a peer's tunnel context. A MID points into a client-state context. Neither is a claim about the legal identity of a human, the current authority attached to an account, or the subject recognized by an application. Treating them as identity proof converts a demultiplexing key into a credential it was never designed to be.

RFC 2341 is explicit about the distinction. At the ISP stage, the goal is only to discover the user's “apparent identity” and the destination Home Gateway. The Home Gateway then decides whether to accept or reject the connection. A further authentication stage may still take place after acceptance, outside L2F's own scope. CHAP, defined separately in RFC 1994, has its own challenge-response boundary. Collection, forwarding, validation, authorization and a successful application login are therefore different events, even when one username appears in several of them.

The data plane has no blanket delivery receipt

The strongest reason not to infer service success from control state appears in L2F's reliability model. Control messages must be retransmitted. Data traffic is different: L2F does not provide flow control or reliable delivery for it. The carried protocol is expected to manage its own recovery, and ordinary data traffic generally does not use the L2F sequence field.

This means an OPEN, an ECHO response, a valid Key, or a moving tunnel counter cannot certify the fate of every payload frame. Those observations may prove that a peer answered, a context existed or some traffic crossed a boundary. They do not form a per-frame chain of custody.

For PPP, L2F carries the link-layer frame after physical framing, transparency and FCS have been removed. It mostly transports that material without understanding the application result. PPP echo, NCP negotiation and termination requests are tunneled as HDLC-like frames. L2F does not itself detect a PPP termination request; the PPP endpoint's result must cause the relevant L2F close transition. The layers meet through state changes, but they do not inherit each other's knowledge.

PPP adds more checkpoints. LCP first establishes and configures the link. Authentication may follow. NCP then configures network-layer protocols. Only after those steps can an application attempt its own session and request. None of those upper outcomes can be reconstructed solely from a tunnel's OPEN state.

Security claims stop at the context they protect

The tunnel handshake uses a shared secret and a challenge-response calculation. Later packets can carry a 32-bit Key derived from the authentication response, and packets with an unknown CLID, wrong Key or invalid format are discarded. This raises the cost of spoofing within the configured NAS–Home Gateway relationship. It does not prove payload confidentiality, end-user authorization, application authentication or successful delivery.

Later L2TP security work makes the boundary easier to name. RFC 3193 distinguishes tunnel authentication from per-packet integrity, replay protection, confidentiality and end-to-end security. That later analysis is not a capability retroactively granted to L2F. It is evidence that “the tunnel peer answered” and “the service transaction is secure and complete” belong in separate columns.

What the record actually is

RFC 2341 is now Historic. Its own status text says it does not specify an Internet standard, and the IETF Datatracker describes it as a Legacy-stream document without IETF endorsement or formal standards-process standing. That classification does not erase its technical value. Nor does publication prove adoption, interoperability or current deployment.

The durable lesson is a method of reading operational evidence. Name the object behind each receipt: physical call, PPP link, selected gateway, tunnel, client MID, later authentication, frame, network-layer configuration, application session and user-visible result. Keep the counters of the NAS and Home Gateway distinct. Record closure independently at both ends. If a receipt cannot name the boundary it observed, it should not be promoted into proof of the entire service.

Sources