Read the real PPP-Max-Payload tag
03Discovery carries a type-length-value tag. Its binary value is a maximum PPP payload in octets, directly comparable to the MRU value, rather than an Ethernet frame size.
A separate 1600 example uses06 40, leaving type and length unchanged. A larger advertised maximum still feeds the interface limit and normal MRU negotiation.
Source for this drawing: RFC 4638 · Read RFC section 4 ↗
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.
TAG_TYPE0x 0120 occupies two octets; TAG_LENGTH0x 0002 occupies two octets and counts just the two value octets. These multi-octet tag fields use network byte order (RFC 2516 section5).
- TAG_TYPE0x 0120 occupies two octets; TAG_LENGTH0x 0002 occupies two octets and counts just the two value octets. These multi-octet tag fields use network byte order (RFC 2516 section5).
- The example value 1500 encodes as05dc, so this complete tag is01 20 00 02 05 dc: six octets altogether. The value describes supported PPP payload in both send and receive directions.
- This discovery tag is different from the LCP MRU option. A valid tag is not an agreed final MRU, full-packet validation, authentication or proof that intermediate equipment carries the chosen size.
An educational PPPoE example, not a full PPP implementation or a guarantee of path support.
Read the RFC section ↗