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-
