Carry long route lists safely
05A route list can outgrow one DHCP option instance or a small message. Concatenation and advertised message size address different limits.
On a fictional 1500-octet-MTU interface with a capable stack, a 1500-octet Maximum DHCP Message Size illustrates the conditional SHOULD; it is not a universal fixed value.
Source for this drawing: RFC 3442 · Read RFC source: Requirements to Avoid Sizing Constraints (unnumbered; page 6) ↗
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.
Concatenate the option data before interpreting its routes.
- Clients requesting 121 and servers sending it MUST implement DHCP option concatenation (RFC 3396). A split need not coincide with a route boundary.
- If the client stack can receive larger IP datagrams, the client SHOULD send Maximum DHCP Message Size and SHOULD choose at least the interface MTU; it MAY choose higher, up to the largest UDP packet it will accept. The value includes IP and UDP headers.
- Administrators should configure both default-router representations for older clients. For a client requesting 121 plus 3 or 33, a server sending 121 SHOULD NOT include those older options.
The split below is a tiny chosen teaching split, not a maximum option size. RFC 3396 §2 defines ordered concatenation, including options/file/sname ordering when overload is used. This guide does not implement a complete DHCP packet parser.
Read the RFC section ↗