Summary

  • Moving the PPPoE endpoint from a PC to a residential gateway placed a familiar 1492-byte limit between an ordinary 1500-byte LAN packet and its access connection.
  • PPP-Max-Payload advertised support for larger PPP payloads during discovery. Local interface limits and ordinary LCP negotiation still determined what the session could use.
  • A large Echo request receiving no reply, followed by a successful 1492-byte request, could require a sender to stay at 1492 for that session. The comparison constrained operation without identifying every intervening limit.

A session was not a capacity certificate

The access concentrator had been found. The session had opened. The endpoints had even negotiated a receive size above the familiar PPPoE ceiling. None of those accomplishments necessarily meant that a packet of that size could cross the Ethernet segments between them.

That gap gives RFC 4638, published in September 2006, its particular interest. Its subject was not merely a larger number. It described how an extension could be understood by both ends, bounded by local capabilities and then restrained by an operational observation that the earlier agreement had not supplied.

An illustrative sequence makes the distinction concrete. A sender tries an LCP Echo request at the negotiated maximum size and receives no reply. It then tries 1492 bytes and receives a reply. Under the specified comparison, the sender must not send above 1492 for that session. This is a protocol scenario, not a claim about a documented outage.

The small success is useful precisely because it does not validate the large attempt. Nor does it name the bridge, interface or other condition responsible. It provides a narrower basis for action: do not continue using the larger size in this session merely because the endpoints previously agreed to it.

The cost was already in the envelope

The original arithmetic appeared in RFC 2516, the February 1999 PPP over Ethernet specification. An Ethernet payload of 1500 octets had to contain a six-octet PPPoE header and a two-octet PPP Protocol-ID. That left 1492 octets for the PPP payload.

The accounting boundary matters. This 1500 is Ethernet payload, not the complete on-wire frame including Ethernet headers, checks, preamble or additional tagging. A device displaying a whole-frame limit may be counting a different object. Comparing the numbers without their definitions creates an apparent disagreement before any packet is sent.

RFC 4638 did not remove either overhead. Carrying a 1500-octet PPP payload still required space for those eight octets: 1508 octets of Ethernet payload under the stated six-plus-two accounting. The proposal relied on Ethernet systems capable of larger payloads, described in the document through baby-giant or jumbo-frame support.

That is a capacity requirement, not a universal configuration recipe. It does not prescribe one full-frame setting for every interface or settle how every implementation counts extra tags. The lower layer had to provide the room; a new discovery tag could only make the endpoints’ intentions explicit.

The endpoint moved before the limit did

RFC 4638 traced the problem to changes in broadband architecture. In the older arrangement it described, a PC originated PPPoE through access equipment. A 1492-byte limit at the PC’s PPP endpoint was normally acceptable.

A residential gateway changed the handoff. It could terminate ordinary IP over Ethernet on the LAN and originate PPPoE toward the broadband access server. A 1500-byte IP packet from the LAN then met a PPP segment whose conventional payload limit was 1492. The machine producing the packet was no longer the machine negotiating that constrained segment.

The eight bytes had not grown. Their effect had moved into a boundary between two expectations. The gateway inherited the work that the end host’s direct participation had previously made more explicit.

The document also discussed PPPoA-to-PPPoE transitions and reported deployed PPPoA customer equipment that could not support a 1492-byte setting. Those are observations in a 2006 account, not a contemporary device census or a claim about every PPPoA implementation.

Nor was the preceding encapsulation limitless. RFC 2364, published in July 1998, bounded PPP over AAL5’s MRU by the maximum CPCS-SDU in the virtual connection’s traffic contract for the relevant direction. Migration changed the lower-layer contract; it did not introduce the first lower-layer constraint PPP had ever encountered.

What receiving more actually meant

The Maximum-Receive-Unit in RFC 1661, dated July 1994, covers the Information and Padding fields, not the PPP Protocol field or the surrounding framing. Ordinary PPP has a default MRU of 1500. That general default does not erase PPPoE’s specific 1492-byte restriction.

An MRU advertises reception capacity or requests smaller packets. It does not require the peer to fill every packet to that capacity. An offered ceiling, a negotiated limit and an observed packet size can therefore all differ without contradiction.

The extension introduced a preliminary declaration in PPPoE discovery. Discovery itself already had a distinct job: PADI solicited access concentrators, PADO offered a response, PADR requested the selected session and PADS confirmed it. Ethernet addresses and the session identifier associated the subsequent exchange with its participants.

Completing that sequence did not finish every later PPP phase, authenticate everything on the path or establish working IP service. The extension used it to answer one additional question before LCP: did both endpoints understand the possibility of a payload above 1492?

A returned tag left room for a smaller answer

The client seeking a larger payload must include PPP-Max-Payload in both PADI and PADR. A supporting server that receives it must echo the client’s tag in PADO and PADS. The tag’s type is 0x0120, or decimal 288; its two-octet binary value states the maximum PPP payload the client supports in both sending and receiving directions.

Those numbers have different roles. The type identifies an option; it is not a 288-byte payload allowance. The two-octet value is part of discovery, not an additional recurring header charged to every session packet.

The server echoes the client’s tag rather than necessarily rewriting it to the server’s own final limit. Local constraints enter the subsequent calculation. The procedure starts with 1492 as the maximum; when a tag is present and exceeds that value, the negotiable maximum becomes the smaller of the advertised value and the interface MTU minus eight.

Normal LCP negotiation then determines the actual MRU. A large discovery value is consequently not a command to use that size. RFC 4638 notes that even a tag above 1500 leaves ordinary PPP’s 1500 default in place if no larger MRU is negotiated, within an otherwise valid extended-capability exchange.

Without both sides indicating support during discovery, the 1492 ceiling remains. Unknown tags can be ignored by older equipment; being ignored must not count as consent. A tag at or below 1492 likewise does not activate a larger allowance. Backward compatibility depends on keeping absence of understanding distinct from acceptance of a new condition.

The devices in between had not voted

Discovery and LCP exchanged statements between endpoints. Intermediate Ethernet equipment could pass those small control messages without accommodating the larger frames the endpoints intended to use. No intermediate bridge had signed the negotiation.

RFC 4638 therefore says the sender should have the option of sending one or more MRU-sized LCP Echo requests after the session is open and a size above 1492 has been negotiated. If replies do not arrive, the sender may repeat at 1492. If those smaller requests receive replies, it must not send above 1492 for the current session.

The distinctions between those requirements are deliberate. The capability should be enabled by default and configurable; prior knowledge of the network can justify disabling it. The document does not prescribe an identical mandatory probe, retry count or timer for every session.

The inference is also limited. Failure at both sizes does not establish that the smaller one works. A reply to a small request does not vindicate a large request. A single successful exchange is not a permanent guarantee of maximum-size transport in both directions.

RFC 1661 confines LCP Echo exchanges to the Opened state and specifies the matching Identifier. It does not support the blanket assertion that every reply must have exactly the request’s size. Operators need the actual transmitted and received sizes, not merely a record labelled “Echo passed”.

An access test was not Internet path discovery

There was a separate history of learning packet-size constraints across routed paths. RFC 1191, from November 1990, described IPv4 Path MTU Discovery using the Don’t Fragment bit and ICMP feedback when a router could not forward a packet without fragmentation.

In that situation the router drops the packet and reports the need; the source reduces its path estimate. An oversized IPv4 packet is therefore not invariably fragmented and delivered. The conditions of the forwarding decision matter.

PPPoE’s size comparison addressed its session and intermediate Ethernet handling. It could not establish the MTU of every later Internet segment between the subscriber and a remote destination. Preserving this boundary makes the test useful: it answers an access question without pretending to settle a different end-to-end question.

A registry supplied vocabulary, not capacity

RFC 4638 was published as Informational, not as an Internet Standard. Its IESG note urged caution in the standards context of Ethernet payloads above 1500 at the time. That is a dated 2006 warning, not a statement about the standards landscape in 2026.

In June 2007, RFC 4937 established IANA arrangements for PPPoE’s 16-bit tag-type registry and recorded PPP-Max-Payload as decimal 288. The captured IANA PPPoE parameters registry retains that association.

Registration lets independent implementations recognise the same field. It neither certifies an access network’s frame capacity nor dates universal adoption. The original 1999 encapsulation, the 2006 extension and the 2007 registry work must not be collapsed into one deployment event.

The historical achievement was a division of evidence. Discovery established shared understanding, LCP negotiated within local bounds and an operational comparison could still restrict the current session. The endpoints could coordinate how to use capacity. They could not negotiate away the eight bytes that real equipment still had to carry.