Make room for PPPoE overhead
01Point-to-Point Protocol over Ethernet (PPPoE) adds link information around a PPP payload. MTU is a transmit limit; MRU is what a peer says it can receive.
A chosen link with a 1508-octet payload budget can fit the example. Both discovery support and subsequent LCP negotiation are still needed; a larger local interface does not prove the path.
Source for this drawing: RFC 4638 · Read RFC section 3 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
The default PPPoE MRU MUST NOT exceed 1492 octets: a 1500-octet Ethernet payload must also hold the 6-octet PPPoE header and 2-octet PPP Protocol field.
- The default PPPoE MRU MUST NOT exceed 1492 octets: a 1500-octet Ethernet payload must also hold the 6-octet PPPoE header and 2-octet PPP Protocol field.
- A 1500-octet PPP payload needs 1508 octets of Ethernet payload in this model. Ethernet framing outside that payload is not included in these numbers.
- RFC 4638 is Informational. Its proposed larger-payload mechanism relies on extended frame support along the path; its 2006 IESG caution is historical, not a claim about all current Ethernet standards. Endpoint agreement cannot guarantee intermediate-link support.
- For the larger-capacity broadband networks described in section1, RFC 4638 says a BRAS acting as the PPPoE server MUST support MRU negotiations above 1492. Allowing a particular larger size remains subject to local configuration (section3).
- The PPP Protocol field identifies the protocol carried by PPP. These arithmetic examples use the two-octet field described by RFC 4638; its overhead is separate from the PPP payload.
An educational PPPoE example, not a full PPP implementation or a guarantee of path support.
Read the RFC section ↗