Re: Modern RFC3442 (Classless DHCP Static Routes)
On Tue, May 10, 2022 at 4:23 AM wrote: > 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.
Re: Modern RFC3442 (Classless DHCP Static Routes)
On 2022-05-06, Stuart Henderson wrote: On 2022-05-04, nacelle ...: > 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. It's not just technically correct, handling this differently would be *in*correct, it is a MUST in the RFC. I agree to disagree. I think the RFC way (ignore option3 if option121) is interesting, but its not neccessarily more or less correct than having the client told to ignore option 3 in an optional fashion from a practical standpoint. Enforcing RFC behavior means fitting into less networks, making it the way by default and having options might work for the fit issues. > 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. right. > 2) dhcpleased enforces that it wont hand out a 0.0.0.0 destination route > in option 121 if this is the case, it's a problem, option 121 routes must be able to set 0.0.0.0/0. can you show your working for figuring this out as that might give a clue what's wrong? debug logs and packet captures might help. I did screw up here. I did the old "specify a cidr size and the network address" thing in my head, which came out "0,0", instead of using a single 0 for the default route. Now it works, smh. > What I've seen (and rely on with other OSes) is to honor dhcp routers and > option 121. which OS are explicitly breaking this RFC and how are they doing it? i.e. what happens if there are conflicting default routes between the two options? > if the client doesnt like the dhcp routers setting, there is > 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) the client shouldn't do this, the whole point of DHCP is that it's a protocol where the network admin sets things up. > 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 This isn't something that was just forgotten in the RFC, it was explicitly considered and the authors chose to do it this way and the reviewers agreed. > (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.) It seems quite clear-cut that the network is misconfigured in this case... *maybe* there's a case for a "the network admin doesn't know what they're doing" option to allow getting a default route in this case but I definitely think it is wrong to change this default behaviour. heh, your choice of words is harsh there, especially considering that 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. In any event, I see my error, and therefore my patch isn't needed. I can make my openbsd7.1 boxes do what my other inferior boxes do, its just a little bit different for the records that I have to define for openbsd. -shrug-
Re: Modern RFC3442 (Classless DHCP Static Routes)
Dealing with broken clients can be handled with separate groups or even "deny booting;" instead of breaking the dhcp server.
Re: Modern RFC3442 (Classless DHCP Static Routes)
On Mon, May 9, 2022 at 6:03 AM Stuart Henderson wrote: > On 2022-05-09, Stuart Henderson wrote: > > ...so the correct configuration is clear: list both a 0.0.0.0/0 > classless route and "option routers", and it should work for all > cases. Yes. The server sends both, the clients that handle option 121 use its data and ignore option 3, the clients that do not handle option 121 ignore it and use the data in option 3 (which may offer a different default route).
Re: Modern RFC3442 (Classless DHCP Static Routes)
On 2022-05-09, Stuart Henderson wrote: >>> >>> That doesn't seem like correct behavior (the ISC version certainly >>> offers both). Both options should be sent if configured, it's up to >>> the client to properly handle this. >>> Clients that are rfc3442 compliant will install the option 121 routes, >>> clients that are not rfc3442 compliant will ignore option 121 and >>> install the gateway supplied by option 3. If dhcpd doesn't hand out >>> option 3 when option 121 is configured then clients that are not >>> rfc3442 compliant will not receive a gateway address. >> >>> >> I fully agree, I was very surprised when I discovered this >> behaviour. But I haven't chased it down why this is. > > It was done to work-around broken clients: > > https://github.com/openbsd/src/commit/3f461432d6a77eea41f084ef892403cacc2ee370 ...so the correct configuration is clear: list both a 0.0.0.0/0 classless route and "option routers", and it should work for all cases.
Re: Modern RFC3442 (Classless DHCP Static Routes)
On 2022-05-06, Florian Obser wrote: > On 2022-05-06 10:28 -04, Sonic wrote: >> On Fri, May 6, 2022 at 7:18 AM Florian Obser wrote: >>> Also, dhcpd(8) does not even hand out option 3 when option 121 is >>> configured. >> >> That doesn't seem like correct behavior (the ISC version certainly >> offers both). Both options should be sent if configured, it's up to >> the client to properly handle this. >> Clients that are rfc3442 compliant will install the option 121 routes, >> clients that are not rfc3442 compliant will ignore option 121 and >> install the gateway supplied by option 3. If dhcpd doesn't hand out >> option 3 when option 121 is configured then clients that are not >> rfc3442 compliant will not receive a gateway address. > >> > I fully agree, I was very surprised when I discovered this > behaviour. But I haven't chased it down why this is. It was done to work-around broken clients: https://github.com/openbsd/src/commit/3f461432d6a77eea41f084ef892403cacc2ee370
Re: Modern RFC3442 (Classless DHCP Static Routes)
On 2022-05-06 10:28 -04, Sonic wrote: > On Fri, May 6, 2022 at 7:18 AM Florian Obser wrote: >> Also, dhcpd(8) does not even hand out option 3 when option 121 is >> configured. > > That doesn't seem like correct behavior (the ISC version certainly > offers both). Both options should be sent if configured, it's up to > the client to properly handle this. > Clients that are rfc3442 compliant will install the option 121 routes, > clients that are not rfc3442 compliant will ignore option 121 and > install the gateway supplied by option 3. If dhcpd doesn't hand out > option 3 when option 121 is configured then clients that are not > rfc3442 compliant will not receive a gateway address. > I fully agree, I was very surprised when I discovered this behaviour. But I haven't chased it down why this is. -- I'm not entirely sure you are real.
Re: Modern RFC3442 (Classless DHCP Static Routes)
On Fri, May 6, 2022 at 7:18 AM Florian Obser wrote: > Also, dhcpd(8) does not even hand out option 3 when option 121 is > configured. That doesn't seem like correct behavior (the ISC version certainly offers both). Both options should be sent if configured, it's up to the client to properly handle this. Clients that are rfc3442 compliant will install the option 121 routes, clients that are not rfc3442 compliant will ignore option 121 and install the gateway supplied by option 3. If dhcpd doesn't hand out option 3 when option 121 is configured then clients that are not rfc3442 compliant will not receive a gateway address.
Re: Modern RFC3442 (Classless DHCP Static Routes)
On 2022-05-06 08:26 UTC, Stuart Henderson wrote: > On 2022-05-04, nace...@narwhals.org wrote: >> 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. > > It's not just technically correct, handling this differently would be > *in*correct, it is a MUST in the RFC. > >> 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. > > right. > >> 2) dhcpleased enforces that it wont hand out a 0.0.0.0 destination route >> in option 121 > > if this is the case, it's a problem, option 121 routes must be able to set > 0.0.0.0/0. can you show your working for figuring this out as that might > give a clue what's wrong? debug logs and packet captures might help. It is not the case. This just works fine in dhcpleased(8). Also, dhcpd(8) does not even hand out option 3 when option 121 is configured. (Also dhcpleased does not "hand out" anything. I assume the OP means "configures a default route in the FIB.") -- I'm not entirely sure you are real.
Re: Modern RFC3442 (Classless DHCP Static Routes)
On 2022-05-04, nace...@narwhals.org wrote: > 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. It's not just technically correct, handling this differently would be *in*correct, it is a MUST in the RFC. > 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. right. > 2) dhcpleased enforces that it wont hand out a 0.0.0.0 destination route > in option 121 if this is the case, it's a problem, option 121 routes must be able to set 0.0.0.0/0. can you show your working for figuring this out as that might give a clue what's wrong? debug logs and packet captures might help. > What I've seen (and rely on with other OSes) is to honor dhcp routers and > option 121. which OS are explicitly breaking this RFC and how are they doing it? i.e. what happens if there are conflicting default routes between the two options? > if the client doesnt like the dhcp routers setting, there is > 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) the client shouldn't do this, the whole point of DHCP is that it's a protocol where the network admin sets things up. > 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 This isn't something that was just forgotten in the RFC, it was explicitly considered and the authors chose to do it this way and the reviewers agreed. > (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.) It seems quite clear-cut that the network is misconfigured in this case... *maybe* there's a case for a "the network admin doesn't know what they're doing" option to allow getting a default route in this case but I definitely think it is wrong to change this default behaviour.
Modern RFC3442 (Classless DHCP Static Routes)
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.c16 Feb 2022 10:35:57 -1.36
+++ engine.c3 May 2022 09:58:04 -
@@ -1106,14 +1106,6 @@ parse_dhcp(struct dhcpleased_iface *ifac
intprefixlen, 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.)
