Request routes and apply precedence
03Supporting clients request option 121 ahead of older alternatives. If 121 arrives, it controls route installation.
An unsupported client MUST ignore 121. This drawing makes no claim that such a client installs a particular older option.
Source for this drawing: RFC 3442 · Read RFC source: DHCP Client Behavior (unnumbered; page 5) ↗
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 request list order and a reply precedence rule are different decisions.
- A supporting client that sends a Parameter Request List MUST request 121 and Router option 3; it MAY request old Static Routes option 33 for compatibility. Code 121 MUST precede both, if present.
- A supporting client MUST install routes in 121, subject to the local-subnet exception. With 121 present it MUST ignore option 3 and MUST NOT install routes from option 33.
- A client without support MUST ignore 121. A default route from option 3 is not rescued merely because option 121 omits a default.
The example reply includes all three options to exercise client precedence; it is not a recommendation for this server response. When a requesting client asks for 121 plus older options, a server sending 121 SHOULD NOT include the older options.
Read the RFC section ↗