I'm running an OpenBSD desktop machine from within
a protected internal network. I'm using 4.0-release
at present , though I have noticed similar problems
with previous release-versions.

My OpenBSD system seems to be generating and sending out
IPV6-related packets that PF does not seem to be capable of
controlling or logging.



[Immediately after a cold-boot , netstat -ss displays]:

ip:
icmp:
igmp:
ipencap:
tcp:
udp:
esp:
ah:
etherip:
ipcomp:
carp:
pfsync:
ip6:
7 packets sent from this host
Mbuf statistics:
icmp6:
Output packet histogram:
multicast listener report: 6
neighbor solicitation: 1
Histogram of error messages to be generated:
pim6:
rip6:



[pfctl -si displays]:

Status: Enabled for 0 days 00:30:58 Debug: Urgent

Interface Stats for em0 IPv4 IPv6
Bytes In 0 0
Bytes Out 0 352
Packets In
Passed 0 0
Blocked 0 0
Packets Out
Passed 0 3
Blocked 0 2

State Table Total Rate
current entries 0
searches 5 0.0/s
inserts 0 0.0/s
removals 0 0.0/s
Counters
match 5 0.0/s
bad-offset 0 0.0/s
fragment 0 0.0/s
short 0 0.0/s
normalize 0 0.0/s
memory 0 0.0/s
bad-timestamp 0 0.0/s
congestion 0 0.0/s
ip-option 0 0.0/s
proto-cksum 0 0.0/s
state-mismatch 0 0.0/s
state-insert 0 0.0/s
state-limit 0 0.0/s
src-limit 0 0.0/s
synproxy 0 0.0/s



[pfctl -v -s rules displays (excerpt)]:

block drop in log quick proto ipv6 all
[ Evaluations: 0 Packets: 0 Bytes: 0 States: 0 ]
[ Inserted: uid 0 pid 19624 ]
block drop in log quick proto ipv6-icmp all
[ Evaluations: 0 Packets: 0 Bytes: 0 States: 0 ]
[ Inserted: uid 0 pid 19624 ]
block drop in log quick proto ipv6-nonxt all
[ Evaluations: 0 Packets: 0 Bytes: 0 States: 0 ]
[ Inserted: uid 0 pid 19624 ]
block drop in log quick proto ipv6-opts all
[ Evaluations: 0 Packets: 0 Bytes: 0 States: 0 ]
[ Inserted: uid 0 pid 19624 ]




block drop out log quick proto ipv6 all
[ Evaluations: 2 Packets: 0 Bytes: 0 States: 0 ]
[ Inserted: uid 0 pid 19624 ]
block drop out log quick proto ipv6-icmp all
[ Evaluations: 2 Packets: 2 Bytes: 144 States: 0 ]
[ Inserted: uid 0 pid 19624 ]
block drop out log quick proto ipv6-nonxt all
[ Evaluations: 0 Packets: 0 Bytes: 0 States: 0 ]
[ Inserted: uid 0 pid 19624 ]
block drop out log quick proto ipv6-opts all
[ Evaluations: 0 Packets: 0 Bytes: 0 States: 0 ]
[ Inserted: uid 0 pid 19624 ]



pfctl -v -s rules does not list the three IPV6-related packets
that were sent successfully through PF. I cannot log them.

I have Default Block Drop policies in effect IN and OUT , have
no rules allowing IPV6-related traffic , and have explicit Block
Drop Quick rules for all IPV6-related traffic as an additional
safeguard (and for easier logging).



[pfctl -sr (excerpt)]:

block drop in log all
block drop out log all


block drop in log quick proto ipv6 all
block drop in log quick proto ipv6-icmp all
block drop in log quick proto ipv6-nonxt all
block drop in log quick proto ipv6-opts all


block drop out log quick proto ipv6 all
block drop out log quick proto ipv6-icmp all
block drop out log quick proto ipv6-nonxt all
block drop out log quick proto ipv6-opts all



Might anyone know:

1) Why OpenBSD might be sending out (according to netstat -ss)
two IPV6-related packets before PF is allowed to come up?

2) Why Default Block Drop policies and explicit Block Drop Quick
rules cannot stop three IPV6-related packets from passing out
through PF?

3) Why the three IPV6-related packets passing through and
leaving PF can be detected by netstat -ss and pfctl -si but
not by pfctl -v -s rules and cannot be logged (only the two
Blocked/Dropped packets appear in pflog)?



Can anyone replicate any of the above? I know recompiling my
kernel to remove IPV6 support is an option. It would be much
nicer if there were an easier way to entirely disable IPV6 ,
perhaps a sysctl setting. It would be easiest if PF could be
configured to stop these packets. Could these be due to PF
IPV6 bugs?

Unfortunately the firewall that protects the internal network
isn't particularly conducive to logging. I'm not even sure if
it is capable of handling IPV6. I have never received any incoming IPV6
packets. Replacing the firewall protecting the internal network
is on my list of things to do.