Re: netbsd-9 ip6 kernel log messages

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

    Date:        Thu, 29 Aug 2019 11:15:47 +0200
    From:        Hauke Fath <hf%spg.tu-darmstadt.de@localhost>
    Message-ID:  <aaf18f23-70a6-cf92-605c-8c7e24b18cdd%spg.tu-darmstadt.de@localhost>

  | I understand. But in terms of network configuration, this is a very 
  | plain  setup, just a static ip4 address. Which is why I am left puzzled...

v6 is designed to autoconfigure, manually configuring something is
not supposed to be needed, so if you're in an environment where v6
is available, that should be happening, unless you take steps to
specifically prevent it.

Since you have v4 statically configured, I will guess that you're
not starting dhcpcd - if that's not running, the kernel is managing
v6 autoconfig for you.

Your initial message said "/var/log/messages gets spammed with..."
from which I have been assuming not just one message, but many.
Can you deduce from the timestamps the appoximate frequency, and
perhape correlate that with the frequency of RA messages from whatever
v6 enabled router is on the same (bridged, I am guessing from voif0)
network link?

That is, I would assume that what you're seeing is the kernel's attempt
to handle the RA messages it is seeing, and if that seems plausible,
it would seem like a good idea to dump one of those, something like

	tcpdump -vv -i voif0 -s1600 icmp6

which should result in something like:

 08:16:50.680157 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 24) fe80::c0ea:b0ff:fe55:6190 > ff02::1: [icmp6 sum ok] ICMP6, router advertisement, length 24
        hop limit 64, Flags [managed], pref low, router lifetime 30s, reachable time 0s, retrans time 0s
          source link-address option (1), length 8 (1): c4:6e:1f:46:e5:cc
            0x0000:  c46e 1f46 e5cc

(perhaps other icmpv6 messages as well, which will not be relevant for
this, so wait for a RA to fly past - the frequency of the log messages
should give you an idea how long that might be - but allow for these
messages not being synchronised, they are sent at an average interval
but with randomness included in the actual gaps between messages).

My current guess is that perhaps the RA is including loopback the loopback
prefix as an "on link" prefix, and the kernel is actually attempting to
use that, rather than rejecting it.

kre