On Tue, May 10, 2022 at 4:23 AM <[email protected]> wrote: <snip> > most > other OSes ship with "broken" RFC3442 support in this fashion. Cisco > doesn't, but Mac, Ubuntu, Windows, and Android do. Color me suprised to > find out this wrinkle of RFC3442.
Note that the test is using the Openbsd isc-dhcp-server-4.4.3 package. A test with a Windows 10 system: if option 3 is different from the default route in option 121 than Windows 10 installs both as default routes. A test with a Debian system works differently in that it ignores option 3 if option 121 sends a default route, but installs the option 3 route if a default route is not provided by option 121. According to this paragraph of RFC3442: "If the DHCP server returns both a Classless Static Routes option and a Router option, the DHCP client MUST ignore the Router option." I'm not even sure Debian strictly follows how that reads to me, which is that option 3 should be totally ignored even if option 121 does not include a default route. However the RFC then goes on to place the onus on the DHCP Server administrator: "DHCP Server Administrator Responsibilities Many clients may not implement the Classless Static Routes option. DHCP server administrators should therefore configure their DHCP servers to send both a Router option and a Classless Static Routes option, and should specify the default router(s) both in the Router option and in the Classless Static Routes option. When a DHCP client requests the Classless Static Routes option and also requests either or both of the Router option and the Static Routes option, and the DHCP server is sending Classless Static Routes options to that client, the server SHOULD NOT include the Router or Static Routes options." Basically the first paragraph of the two directly above seems to work fine for cases where the default route is the same for both option 3 and option 121, but if one desires a different default route in both options then some client configs may break if paragraph two is not heeded. Which seems to indicate that it's the admins responsibility to configure the server so that it does send option 3 to a client that requests option 121, which seems at odds with the first paragraph and seems like something the dhcp server itself should handle instead of the dhcp server admin. Using class matching it would be fairly straightforward to set up proper pools for the various systems. However, that feature is one that's sorely missing (to my knowledge anyway) in the Openbsd base dhcp server.
