Hello,
A few bizarre pf & tcpdump behavior I've noticed:
1.
An ipv6 multicast listener report packet gets logged to pflog regardless
of the pf ruleset, every time an interface is brought up. Furthermore,
this packet, although an icmp6 packet, does not match tcpdump icmp6.
Steps to reproduce:
In one terminal:
# tcpdump -n -ttt -l -s 1500 -i pflog0 ip6
In another terminal:
# echo '' | pfctl -f -
# ifconfig re0 inet6 up
The following packet will appear on the tcpdump terminal:
[TIMESTAMP] :: > ff02::1:ffXX:XXXX: HBH icmp6 multicast listener report
max resp delay: 0 addr: ff02::1:ffXX:XXXX [hlim 1]
If, we were to invoke tcpdump with:
# tcpdump -n -ttt -l -s 1500 -i pflog0 icmp6
Then the above mentioned packet does not show up.
2.
A table with ::/128 as its only entry is treated differently from
specifying ::/128 directly as src/dst address. The former is treated
as an empty table.
Steps to reproduce:
pf.conf.1:
table <v6_sol_node_multicast> const persist { ff02::1:ff00:0/104 }
table <v6_unspecified> const persist { ::/128 }
block all
pass in on re0 inet6 proto icmp6 from <v6_unspecified> to
{<v6_sol_node_multicast>, (re0)} icmp6-type neighbrsol
pf.conf.2
table <v6_sol_node_multicast> const persist { ff02::1:ff00:0/104 }
block all
pass in on re0 inet6 proto icmp6 from ::/128 to
{<v6_sol_node_multicast>, (re0)} icmp6-type neighbrsol
pf.conf.2 has the desired effect of letting the specified packet in,
whereas pf.conf.1 does not let anything in.
3.
pf does not match ipv6 link-local addresses to an interface's :network,
although link-local addresses are technically "the network(s) attached
to the interface" (quoting pf.conf(5) man page).
4.
pf state tracking does not work for packets involving ipv6 all router
multicast ff02::2/128.
