Separate routing syntax from trust
06A route can be well formed and still send traffic to the wrong place. Option 121 does not authenticate the server or protect the next hop.
A syntax check alone cannot approve the sender. The guide points to DHCP security and authentication sources instead of inventing protection in option 121.
Source for this drawing: RFC 3442 · Read RFC source: Security Considerations (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.
Correct encoding is not proof of a trustworthy route.
- A false router address can cause denial of service by choosing an invalid next hop, or direct traffic through a snooper.
- The same class of risk already exists in Router and old Static Routes options; option 121 does not create an authenticated routing system.
- RFC 3442 points to RFC 2131 §7 and DHCP authentication RFC 3118. This example does not imply that all DHCP deployments authenticate messages.
Packet paths are alternative examples, not events that all happen in one session. No new MUST/SHOULD defense is invented. Deployment trust and network controls require their own assessment.
Read the RFC section ↗