Advertise and echo support during discovery
02A client discovers an access server before the PPP session. A larger-payload client carries PPP-Max-Payload in its initiation and request; a supporting server echoes it in offer and confirmation.
Server unicasts PPPoE Active Discovery Session-confirmation (PADS), echoing 1500 in this successful case. Ordinary session setup is assumed; next comes PPP LCP, not automatic 1500-octet traffic.
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.
A client wanting MTU/MRU above 1492 MUST include PPP-Max-Payload in PADI and PADR. A server able to support above 1492 MUST echo the received client tag in PADO and PADS.
- A client wanting MTU/MRU above 1492 MUST include PPP-Max-Payload in PADI and PADR. A server able to support above 1492 MUST echo the received client tag in PADO and PADS.
- PADI is broadcast; PADO, the selected-server PADR, and a successful PADS are unicast. Only one responding server is shown; ordinary discovery tags and success/session fields are omitted here. RFC 2516 sections5.1–5.4 define those details.
- The server MAY allow larger negotiation within local configuration and client limits (section3). Both endpoints must indicate larger support before negotiating above 1492. Echoing a tag is not a measured path-size result.
An educational PPPoE example, not a full PPP implementation or a guarantee of path support.
Read the RFC section ↗