Use a cap before ordinary MRU negotiation
04The Link Control Protocol (LCP) negotiates PPP options. Discovery permits considering a larger MRU; a selected server interface can still impose a smaller maximum.
Normal LCP can choose a smaller receive limit. The illustrative local policy selects 1492 within cap 1500; an unnegotiated extended default would be 1500, not 1600.
Source for this drawing: RFC 4638 · Read RFC section 5.1 ↗
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.
Without larger support indicated by both endpoints, the MRU MUST NOT exceed 1492. An absent tag or one not greater than 1492 keeps the compatible constraint; a smaller tag is not an instruction to raise the cap.
- Without larger support indicated by both endpoints, the MRU MUST NOT exceed 1492. An absent tag or one not greater than 1492 keeps the compatible constraint; a smaller tag is not an instruction to raise the cap.
- With the extension and a tag above 1492, the server MUST consider both the tag and interface MTU: PPP_MRU_Max = min(tag, Interface MTU − 8), followed by normal RFC 1661 MRU negotiation. Local policy can further restrict allowance.
- The worked example uses tag 1600 and interface MTU 1508, giving cap 1500. A cap is not the actual MRU: peers advertise receive limits and need not transmit the largest permitted packets.
- Within this extended context, no MRU negotiation uses RFC 1661’s 1500 default, not a larger tag value such as 1600. This does not override RFC 2516’s 1492 constraint when the extension is absent. A tag/interface combination unable to carry a default must not be treated as permission to send oversized traffic.
An educational PPPoE example, not a full PPP implementation or a guarantee of path support.
Read the RFC section ↗