[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: nd6_free assumes all routers are processed by kernel RA
Date: Fri, 23 Aug 2019 20:43:53 +0100
From: Roy Marples <roy%marples.name@localhost>
| I've not tested it, but is the same true for v4?
| private v4 address, default route to a existing router that
| doesn't forward.
I think I answered that later in the message, but yes, mostly, though it
is far less likely that (anything operating today, rather than in, say, 1980)
would not forward v4 in this scenario. Further, a "private" v4 address
is not a LL (that would be more a ULA), LL's in v4 are the 169.whatever.it.is
set (the thing dhcpcd assigns when there is no DHCP server reachable), not 10,
192,168., or whatever the class B version is. (I know you know this.)
| FWIW, kernel RA handling does the same as dhcpcd in regards to this.
I can certainly believe that, at first sight, simply processing an RA
and assigning it as a default router is the sane thing to do - one would
not expect a router to send an RA if it had no actual ability to act as
a router (the perils of cheap implementations....). Whatever gets fixed
should get fixed both ways.
Having the kernel simply not use a router to forward packets which have
a LL source addr would handle all of this in one change, but it just seems
like perhaps a little too servere to me.
| I disagree.
| IPv4LL actually works quite well behind a NAT so the situation I believe
| is the same.
Only if you presume the existence of v6 NAT, which is something I would
hope would never actually catch on, despite some people's apparent desire
for it. There is no need for v6 NAT there are plenty of global addresses
so every host can have one - NAT for no purpose is pointless. Further, if
one really wanted NAT, one would be better to use ULA's as the "stable"
addresses (just as net 10, 192.168, ... are used in v4, as they can be
locally routed around multiple local nets) rather than LL addresses, which
generally are designed to work *only* on one link - that is, some of their
uses are designed with that property in the forefront.
| What works for one can work for the other.
But as I said, I would be happy for some change to not install default
routes, or to have the kernel not use them with LL sources, to be
conditional, so if we have someone who really believes that NAT is
worth using, and LL is suitable as a source for it (neither of which is
a sane opinion, IMO, but never mind) then the system can be configured
to allow it.
| We should do something with ICMP unreachable maybe? I assume the router
| did send something along those lines back?
I never bothered to look, but I shall. Sending the packets in the first
place seems wrong to me, what should happen after we do the wrong thing is
or less consequence than not doing it in the first pace.
I'll wait until I see the default v6 route come back (might be a few
days - I don't know what triggers that, it certainly isn't simply every
RA), and then monitor the network while I try a ssh to netbsd.org or a
cvs update, or similar.
Main Index |
Thread Index |