Re: nd6_free assumes all routers are processed by kernel RA

[Roy Marples <roy%marples.name@localhost>]

On 23/08/2019 03:09, Robert Elz wrote:
> I haven't looked at the patch yet (haven't had time recently to
> even understand the issue properly) - but while there is a discussion
> of IPv6 default routers there's another issue I'd like to get fixed.
>
> My home net has a (commercial) IPv6 capable router, which sends RAs
> (etc) announcing itself as a router (whether it should or not is
> another issue - but one over which I have no control).   My home ISP
> however has no IPv6 service (available to me anyway) and for various
> reasons right now, no other ISP is an option (I could set up tunnels,
> but as the purpose here is not specific v6 research/work, all that would
> do is increase delays and overall network traffic, over simply using v4).
>
> Anyway, the point is that the RA the router sends has no v6 prefixes
> to advertise, the router (for v6 purposes) is a router in name only,
> it cannot actually forward anything anywhere, as all it sever sees is
> link local v6 addresses (which is why it perhaps should not be advertising
> itself as a router by sending RA's in the first place, but again, that
> is a topic outside the scope of this list.)
>
> The relevance to NetBSD is what a NetBSD client host does with a network
> in this state.    Clearly it can simply disable v6, and for "fixed" hosts
> that is what I do (if/when v6 becomes available, I'll just enable it again).
> But for a movable host (ie: laptop) that's not convenient, as it keeps
> moving between places where v6 is available (and should be used) and
> where it is not.
>
> As things are now (well, a few months ago's kernel, and perhaps just
> slightly older dhcpcd) a default v6 route gets installed (caused by the
> RA from the router, I assume), but no v6 addresses (except link local).
>
> In that state the kernel attempts to route packets via the router to
> any destination that the DNS returns a v6 address for (like *.netbsd.org).
> The effect of this is that the alternate v4 addresses (which work fine)
> are not attempted until the attempt at a v6 connection times out (several
> SYN retransmits with several seconds between each ... long enough to be
> highly irritating anyway!)   (And no, I do not want to priotorise v4 over
> v6 - when v6 is available, and working, I prefer to use it.)
>
> If I simply "route delete -inet6 default" manually, then everything works
> normally again for a while (often days) until something happens, and the
> route is reinstalled (after which I can delete it again, over and over,
> until I happen to be connected to a net where v6 is working.)

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.

> There are several ways that we could do better here.
>
> One (just to avoid someone suggesting this) that is not an option is
> to have the kernel refuse to attempt to send to a IPv6 global address
> (or even ULA) when all it has is a link local.  The kernel (by definition
> in this state) does not know where the host with the global v6 address
> is located (it has no prefix info at all) and hence does not know that
> the host is not on the local link - communications between a LL addr, and
> a global addr that is on the same link should always work (assuming the
> link and interfaces are working properly of course).
>
> What we could do is have the kernel refuse to use a router to forward
> packets for us, if we have nothing except a LL address - packets forwarded
> by a router are useless (and forbidden) when the source addr is LL, as
> that addr would be meaningless (in the wrong scope) for the recipient.
> If the dest addr is on the local link, no router is needed, if it is not
> communications don't work - either way the router is no benefit.   If we
> were to do that, the installed default v6 route (in my case) would never
> be used, and hence, things would be just the same as if it were not there.
>
> Or, we could refuse to automatically add routes when there is no non LL
> address available to use them (a faster and less weird alternate to my
> current situation where the route gets added, only to soon get deleted again).
>
> I believe it is dhcpcd that is adding the default v6 route, as by
> "disable v6" for "fixed" hosts above, what I do is simply config dhcpcd
> to only use v4, and in that state, everything is fine (except of course it
> never uses v6, even if v6 is available and would work).  When it is allowed
> to use both v4 and v6 (which is what I want for a laptop) is when the issue
> arises.

FWIW, kernel RA handling does the same as dhcpcd in regards to this.

> Of those, I think I prefer the second version - don't install useless
> routes in the first place, rather than having them installed, but ignored
> by the kernel (the first version) - as that then leaves things possible for
> someone to manually install a route, and have the kernel use it, if somehow
> they have a network configuration where that actually works somehow (I would
> perfer not to assume that can never happen).
>
> This behaviour (modification to dhcpcd I am presuming) could be controlled by
> yet another config option if desired (and I do not care which way the default
> would be set), and would result in dhcpcd never installing a route unless the
> system has at least one non-LL address installed (however installed - via
> dhcpcd or some other way).  Instead dhcpcd would remember the routes it would
> have installed (along with all the appropriate bookwork to forget any that
> have expired, etc - so a one time RA from some router a week ago is not
> remembered forever) and then should a non LL address be configured (by dhcpcd
> or otherwise) would at that time install all of the routes that it failed
> to install earlier (as in, immediately install, not waiting for the next
> RA from the router to cause that to happen.)
>
> I'd need to ponder all the variables more carefully, but it might even be
> that the correct behaviour would be not to install a route that is via an
> interface that has no non-LL addresses installed, regardless of whether some
> other interface might have a non-LL address.   (That would mean, for example,
> no local routes, to local routers, if none of my local interfaces have
> non-LL addresses, even if I have a v6 over v4 tunnel set up, and the gif
> interface (or whatever tunnel method I am using) does have a global v6
> address (any v6 routes in such a situation would beed to be via tunnels).
>
> For me, these two scenarios result in the same result - either I have
> v6 addresses on my useful interface, through which the RA was received
> (whether that is wireless or wired can vary day by day, or hour by hour)
> or I have no (non-LL) v6 addresses at all - but other hosts might not be
> quite so clear cut.
>
> I'm also deliberately omitting any discussion of v4 in all of this .. a true
> pure (original) v4 net would be just the same (except it had no RAs nor
> LL addresses to confuse things) but these days there are very few such nets
> in existance - and it is entirely possible that some router somewhere is
> willing to accept v4 LL sourced packets and NAT them into a "global" source
> addr - so nothing along the lines suggested above for v6 is likely to be
> workable for v4.

I disagree.
IPv4LL actually works quite well behind a NAT so the situation I believe 
is the same. What works for one can work for the other.

> Opinions?

We should do something with ICMP unreachable maybe? I assume the router 
did send something along those lines back?

Roy