Probe the opened session and bound a failure
05Large discovery values describe endpoint capability. An intermediate Ethernet segment can still drop a large packet, so the sender can offer a session-open size test.
In this example a 1492-size Echo-Reply returns. The sender MUST NOT send above 1492 for this session. Testing does not authenticate the peer or guarantee all later deliveries.
Source for this drawing: RFC 4638 · Read RFC section 5.2 ↗
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.
For MRU above 1492 the sending side SHOULD offer one or more MRU-sized Echo-Requests once the session is open. This capability SHOULD be enabled by default and configurable; it MAY be disabled with prior knowledge that testing is unnecessary.
- For MRU above 1492 the sending side SHOULD offer one or more MRU-sized Echo-Requests once the session is open. This capability SHOULD be enabled by default and configurable; it MAY be disabled with prior knowledge that testing is unnecessary.
- If no Echo-Replies arrive, the sender MAY retry with 1492-octet Echo-Requests. If those receive replies, it MUST NOT send packets bigger than 1492 for this session. Missing large replies alone do not prove which device or cause failed.
- RFC 1661 section5.8 allows Echo-Request/Reply only in LCP Opened state and requires an Echo-Reply on receiving an Echo-Request there. The example picks one test in each size; RFC 4638 supplies no universal count, timeout, or later recovery algorithm.
- Size agreement and echo testing add no authentication or confidentiality. RFC 4638 section6 retains the original PPPoE security considerations; this drawing is not a path-MTU discovery or secure-channel implementation.
An educational PPPoE example, not a full PPP implementation or a guarantee of path support.
Read the RFC section ↗