Summary

  • RFC 2516 placed a stateless discovery stage before the point-to-point PPP session; both endpoints allocated virtual-interface resources only once the session was established.
  • An optional AC-Cookie could let a concentrator check that a source address could return a value it had sent, while Host-Uniq and Relay-Session-Id served separate host- and relay-owned correlation roles.
  • These tokens carried bounded packet context. None authenticated a person or proved that later PPP configuration, traffic or a commercial service existed.

A broadcast without a session table

In February 1999, RFC 2516 described how PPP could cross an Ethernet that was built for many-to-many access. A host sent PADI as a broadcast; concentrators that could serve it could answer with PADO. The host chose an offer and sent one unicast PADR to that concentrator. PADS then confirmed an accepted service and supplied a session identifier. The RFC called the stages Discovery and PPP Session, and made their boundary unusually explicit: discovery remained stateless until the PPP session was established. At that point, both host and access concentrator had to allocate resources for a PPP virtual interface.

The sequence was not simply a prettier handshake. A shared Ethernet could deliver a solicitation to multiple boxes, while a point-to-point PPP endpoint needed state that belonged to one selected peer. Deferring the virtual interface meant that a broadcast request or an offer did not itself require the concentrator to commit session resources. The protocol did not claim that discovery consumed no processing at all; it drew a line around the more durable PPP-session state.

The value had to make the trip back

RFC 2516 offered the access concentrator an optional AC-Cookie tag. If the concentrator sent one in PADO, the host had to return it unchanged in PADR. The host treated the bytes as opaque. The RFC recommended that the concentrator be able to regenerate the value using the PADR source address. That could show the address was reachable in the return direction and help the concentrator limit concurrent sessions for it.

The standard gave HMAC over the host MAC, with a key known only to the concentrator, as an example. It mandated neither that algorithm nor a universal protection. It explicitly warned that a cookie could not prevent every denial-of-service attack. The mechanism was a way to postpone per-session resource commitment until a party that received an offer could send it back—not a cryptographic assertion about who controlled a household or account.

Other tags made the ownership boundaries clearer. Host-Uniq was chosen by the host and let it associate an arriving PADO or PADS with its own request; the concentrator reflected the bytes without interpreting them. Relay-Session-Id could be added by an intermediate relay and was opaque to both endpoints; they returned it unmodified. Each token helped its creator correlate a path. Their successful return did not make them interchangeable identities.

Confirmation changed the resource state

The accepted PADS supplied a nonzero session ID and the service name the concentrator accepted. A rejected service name used PADS with ID zero and an error tag. Once a session existed, its identifier was fixed, but the RFC defined the session by a tuple: source MAC, destination MAC and SESSION_ID. A dashboard that retained only the 16-bit number would discard part of the protocol's scope.

PADS moved discovery into PPP Session. It did not perform PPP's later Link Control Protocol negotiation, optional authentication or Network Control Protocol configuration; RFC 1661 describes those phases separately. This article does not reprise the older PPPoE coverage of payload size or the 1492-byte boundary in RFC 4638. Its subject is the resource transition and the distinct scopes of three returned tags—not a claim about downstream service delivery.

The cookie was evidence of a route back

RFC 2516's design made a small but consequential distinction: an offer could be cheap and broadly visible; a session was a specific bilateral resource commitment. A concentrator-owned cookie helped test return reachability before that commitment, while host and relay tokens preserved their own correlation contexts. The same bytes might be useful to correlate a packet exchange, yet still say nothing about a human identity or authority.

This is the historical account the standard supports. It documents a resource-protection design and its stated limits. It does not quantify saved memory, name an implementation that used the HMAC example, prove current deployment, or show that any given session completed authentication or carried traffic.

Sources: RFC 2516; RFC 1661; RFC 2104; RFC 4638 (adjacent payload-size topic excluded here).