https://marc.info/?l=openbsd-tech&m=162652200109398&w=2 I disagree.
while its technically correct with the rfc, in practice, not many OSes rigidly enforces not using the router option when 121 is present that I've used.

This is how dhcpleased works in -current:
1) if a client using dhcpleased gets an option 121 set of routes, it ignores the dhcp router option. 2) dhcpleased enforces that it wont hand out a 0.0.0.0 destination route in option 121

So, effectively, you cant use option 121 to hand out a default route to a dhcpleased machine with either option 121 or the dhcp's regular routers options. This is not a practical default.

What I've seen (and rely on with other OSes) is to honor dhcp routers and option 121. if the client doesnt like the dhcp routers setting, there is usually a flag to ignore that (or the dhcp server can be configured to hand out a lease without a routers option for that client)

Basically, I use option 121 routes supplementally, and this works quite well. Certain clients get special routes on my network, others don't. All get the same default gateway as they're all on the same subnet otherwise.

fwiw, the actual technical fix to the problem I'm seeing is simple, its deleting a few lines in dhcpleased/engine.c:

RCS file: /cvs/src/sbin/dhcpleased/engine.c,v
retrieving revision 1.36
diff -u -p -u -p -r1.36 engine.c
--- engine.c    16 Feb 2022 10:35:57 -0000    1.36
+++ engine.c    3 May 2022 09:58:04 -0000
@@ -1106,14 +1106,6 @@ parse_dhcp(struct dhcpleased_iface *ifac
             int    prefixlen, compressed_prefixlen;

             csr = 1;
-            if (routers) {
-                /*
-                 * Ignore routers option if classless static
-                 * routes are present (RFC3442).
-                 */
-                routers = 0;
-                routes_len = 0;
-            }
             while (routes_len < MAX_DHCP_ROUTES && dho_len > 0) {
                 prefixlen = *p;
                 p += 1;



If there is no method to have the client ignore the routers option of the lease, folks who for whatever reason rely on rfc3442 explicit behavior might not like this change - but again, I suspect this is not the right default here and that the rfc3442 has a bit of a glitch


(either support handing out the 0.0.0.0 route in option 121 or honor routers and option 121 (and 249, fine, microsoft)... but dont do what it currently spells out and get no default routes when option 121 is in use - thats painful.)


Reply via email to