Re: nd6_free assumes all routers are processed by kernel RA

[Robert Elz <kre%munnari.OZ.AU@localhost>]

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.)

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.

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.

Opinions?

kre