Date: Tue, 20 Apr 2021 12:54:57 -0400
From: Jan Schaumann <jscha...@netmeister.org>
Message-ID: <20210420165457.ge5...@netmeister.org>
| You can grab a pcap file from here:
| https://www.netmeister.org/tmp/ipv6.pcap
It looks to me as if the problem might be that NetBSD has removed too much
of RA processing from the kernel.
It seems as if what is happening, is that the router is sending RA's with
the source-link addr option, which isn't being added to the neighbour
cache.
Then NetBSD is doing a NS to discover the address it ignored from the RA,
but instead of replying with a ND as would perhaps be expected, the router
is simply sending another RA (containing the relevant addr info, which would
answer the NS if processed).
I'd suggest putting RA processing back into the kernel to avoid this kind
of issue.
I have another reason for wanting that ... I run a reasonably current HEAD
kernel (9.99.80 from mid Feb at the minute, though I can upgrade that as
soon as there's a reason) but a fairly old userland (8.99.12 from late Jan,
2018)
Upgrading the kernel without upgrading userland is supposed to be supported.
My dhcpcd comes from that vintage (more recent than NetBSD 8 which is
still supported), which is before the RA processing was moved from kernel
to dhcpcd.
Things mostly work, except that if the router fails to deprecate an old
IPv6 addr (which can happen if the router reboots - it doesn't keep state
of that kind of thing) and gets handed a new IPv6 addr from the ISP - it
advertises the new one, and says nothing about the old. In my system
currently nothing is aging out that old v6 addr, I need to "ifconfig -alias"
it manually. Much the same happens if for some other reason (like the
cable being removed) my laptop goes off net at the time the ISP decides I
have been using my old addr long enough, and issues a new one. When I'm
connected to the net when that happens, everything works, the old addr is
deprecated, and then removed (so the router is clearly sending the lifetime 0
RA for the old prefix) but if I am not on the net, and so miss that packet
(or packet sequence) the old addr remains live, seemingly forever (I've never
managed to be quite patient enough to wait for forever to arrive to test
this theory...)
kre
