Summary

  • RFC 2516 fitted PPPoE inside Ethernet’s 1,500-octet payload by limiting the PPP MTU to 1,492: six octets of PPPoE header and two of PPP Protocol ID used the rest.
  • RFC 4638 made a larger MTU/MRU an optional capability exchange. The client, access concentrator, local interface setting and intermediate Ethernet path all had to agree before a session could carry more.

The ceiling came from arithmetic

A 1,500-octet Ethernet payload sounds like room for a 1,500-octet Internet packet. PPPoE took eight octets off that room before the packet reached the wire: six for its own header and two for the PPP Protocol ID. In February 1999, RFC 2516 set the PPP MTU ceiling at 1,492 octets on a standard Ethernet segment.

Nothing in that subtraction was mysterious. It was the price of putting one network’s session frame inside another network’s payload limit. The harder choice was why keep PPP at all when the subscriber’s new access device spoke Ethernet?

Broadband wanted the line and the session

RFC 2516 answered in business terms. Broadband access providers wanted Ethernet as a low-cost way to connect several hosts through a customer-premises bridge, while keeping PPP’s per-user access control, billing and service model. Ethernet gave the household a shared local medium; PPP gave the provider a separate session for each user.

That bargain carried a small protocol receipt in every packet. The provider kept the session boundary; the subscriber’s IP packet had eight fewer octets available inside the conventional 1,500-octet Ethernet payload. RFC 2516 made the limit explicit instead of asking equipment to guess whether the next link had spare room.

The arithmetic mattered when one side expected a 1,500-octet PPP unit and another side negotiated 1,492. RFC 4638’s 2006 introduction says that such mixed broadband paths could produce a large number of fragmented packets. The extension was written to reduce that fragmentation in next-generation broadband networks.

Eight bytes became a capability question

RFC 4638 did not make every PPPoE session run above 1,492. For the next-generation broadband designs it describes, it says a BRAS acting as PPPoE server MUST support negotiation above that value; the optional PPP-Max-Payload tag determines whether a particular client and server can use it. The two-octet tag value states the maximum PPP payload the client supports in both directions. A client requesting more than 1,492 includes it in PADI and PADR. A server able to support the request echoes it in PADO and PADS.

The server still has its own limit. RFC 4638 says it may negotiate a larger MRU subject to local configuration and the client’s declared maximum. Its selection rule keeps the smaller of the tag value and the server interface MTU minus eight. A tag can open a negotiation; it cannot enlarge a physical interface or rewrite the setting on an intervening segment.

That distinction turned a number into a chain of decisions. The client could request more. The concentrator could echo only what it supported. The local interface had to fit the encapsulation. Each Ethernet segment in the path had to carry the resulting packet. A 1,500-byte value on the subscriber’s screen was not a receipt from every switch between the home and the concentrator.

The path had a chance to object

RFC 4638 also describes a test after the session opens. The sending side can transmit an MRU-sized Echo-Request through the receiving endpoint and intermediate Ethernet equipment. If the large probe receives no Echo-Reply but the 1,492-octet probe does, the sender must stop sending larger packets on that session.

The fallback is important. If the tag is absent, or either side has no larger setting, RFC 2516’s 1,492-octet rule remains. If the path fails the larger probe, the connection can return to that lower ceiling. The extension preserved the old agreement as a working floor while letting compatible paths negotiate upward.

A published option was not a bigger Ethernet standard

RFC 4638 is an Informational RFC. Its IESG note says that, at publication, no current IEEE standard supported jumbo frames above a 1,500-octet MTU and warns that reliability and interoperability of non-standard extensions could not be assured. The RFC defined a way for PPPoE peers to ask for more; each Ethernet port still had to accept it.

That is why the extension is more revealing than a simple “1492 became 1500” timeline. It keeps the 1999 limit where the path needs it, names the capability exchange, and gives implementations a way to test the larger size. The protocol can describe the offer. The participants and their path decide whether the offer works.

The RFCs record the design and the fragmentation objective, not which retail networks enabled the tag; dated concentrator configuration or a captured discovery exchange would establish adoption for a named network.

The useful question is who can request an extension, who must answer, and which compatible systems choose to run it. A protocol can publish the option; only operating equipment can turn it into a working path.

Sources