On 7/12/23 10:20, Claudio Jeker wrote:
You are missing something. It is called the KAME hack or embedded scope.
The KAME IPv6 implementation hijacks the 2nd 16bit addr part to store the
scope_id. In some cases this embedded scope escapes in the addrs printed.
Especially the "ndp info overwritten for" is leaking the scope_id (4)
which is probably the interface index of your em0 interface.
Welcome to IPv6, the world would be better without all the garbage.
As predicted, em0 does in fact have index 4. Follow up question. Am I
to interpret this as purely a display problem and not a functional one?
If so, can you explain why when I have the following rule in pf.conf(5):
block out quick on $wan inet6 to fe80:4::c6ca:2bff:fe5a:8723%em0
I am still able to ping6(8) it:
router$ ping6 -c1 fe80:4::c6ca:2bff:fe5a:8723%em0
PING fe80:4::c6ca:2bff:fe5a:8723%em0 (fe80:4::c6ca:2bff:fe5a:8723%em0): 56 data
bytes
64 bytes from fe80::c6ca:2bff:fe5a:8723%em0: icmp_seq=0 hlim=64 time=7.294 ms
--- fe80:4::c6ca:2bff:fe5a:8723%em0 ping statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 7.294/7.294/7.294/0.000 ms
meanwhile if I remove the "4", I am unable to ping6(8) it?:
router$ ping6 -c1 fe80:4::c6ca:2bff:fe5a:8723%em0
PING fe80:4::c6ca:2bff:fe5a:8723%em0 (fe80:4::c6ca:2bff:fe5a:8723%em0): 56 data
bytes
ping6: sendmsg: Permission denied
ping: wrote fe80:4::c6ca:2bff:fe5a:8723%em0 64 chars, ret=-1
--- fe80:4::c6ca:2bff:fe5a:8723%em0 ping statistics ---
1 packets transmitted, 0 packets received, 100.0% packet loss
I should add that I can replace the second octet pair with any non-zero
value, and I am unable to block it. Asked differently, how would I be
able to block traffic to/from fe80:4::c6ca:2bff:fe5a:8723%em0 while
still allowing traffic to/from fe80::c6ca:2bff:fe5a:8723%em0 where "4"
is interpreted as not the scope_id but in fact part of the address since
seemingly "%em0" is sufficient without scope_id?
