On 2022-05-04, nace...@narwhals.org <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.
