Re: IPv6: in6_setscope: can't set scope for not loopback interface

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

    Date:        Wed, 21 Apr 2021 22:50:40 +0200
    From:        =?UTF-8?Q?J=C3=B6rn_Clausen?= <joernc%googlemail.com@localhost>
    Message-ID:  <CABFsXQeRXOjLwtm63REgTNS5OFiAxv44E-vA+R5zYzsoEo+dNA%mail.gmail.com@localhost>

  | I am mostly ignorant to everything IPv6, so I have no clue what that
  | message means, and I was not able to find any enlightenment online.

IPv6 link local (and multicast, and sometimes some other) addresses
have a "scope" in addition to the address itself.  That's because there
is nothing in the address which indicates which interface it belongs
to (no sub-net identifier or anything like that).

The reference to ::1 in the messages is interesting, that's the v6
equivalent of 127.0.0.1 in V4 - the loopback address, and should only
be assigned to lo0 (but needs to be there).

  | Is this something I can fix from inside the OS?

Almost certainly.  There's probably something mis-configured.

What is the status of the loopback interface (lo0) ?

Mine looks like:

	lo0: flags=0x8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33624
                inet 127.0.0.1/8 flags 0x0
                inet6 ::1/128 flags 0x20<NODAD>
                inet6 fe80::1%lo0/64 flags 0x0 scopeid 0x3


  | $ ifconfig vioif0
  | vioif0: flags=0x8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
  |         ec_capabilities=1<VLAN_MTU>
  |         ec_enabled=0
  |         address: 00:16:3e:b3:00:8a
  |         inet 5.2.76.44/24 broadcast 5.2.76.255 flags 0x0
  |         inet6 fe80::216:3eff:feb3:8a%vioif0/64 flags 0x0 scopeid 0x1

Nothing looks wrong there

	fe80::216:3eff:feb3:8a

is your link local address on that interface, the "%vioif0" is the
scope (and the /64 is essentially the netmask of course).

While the changes at your ISP may have triggered something, and of
course it is possible they're doing something incorrect or unusual, it
is probably more likely that it is just different.

You might want to capture a short sequence of packets on that interface
to see what is happening, since the timestamps you included show the
messages appearing several times a minute, capturing packets for just
a minute or two should be enough to see if there's anything strange.

	tcpdump -i vioif0 -s 1600 -w /tmp/packets.pcap ip6

should do it, simply interrupt it after a couple of minutes.   Then you
can use tcpdump -r or wireshark to look at the packets, or put the file
somewhere it can be fetched.

kre