NetBSD 6 had sporadic inet6 problems and someone recommended to
open traffic at fe80::/10 and ff00::/10, so I added this to npf.conf:
$link6 = { fe80::/10, ff00::/10 }
pass stateful out family inet6 proto ipv6-icmp from $link6
pass stateful in family inet6 proto ipv6-icmp to $link6
which fixed the inet6 lapses.
Every machine on this network is manually configured for inet6 and
I am familiar with fe80::/10 but what is ff00::/10?
A subset of the IPv6 multicast address space, ff00::/8, and a superset
of ff02::/16.
The most important are:
+ ff02::1 all nodes on this link
+ ff02::2 all routers on this link
+ ff02::1:ffxx:xxxx solicited-node multicast address
not having these, and linklocal, basically broke your IPv6.
the following conventions apply:
+ ff0x:: is a permanent multicast address
+ ff1x:: is a temporary one
+ ff01:: is valid on a certain node (for conversations with itself)
+ ff02:: has link scope
+ ff05:: has site scope
+ ff08:: is valid within an organisation (if not using 5, site)
+ ff0e:: is a global multicast address.
You probably also can get away with just allowing ff02::/16.
Also, does someone know what is happening with NetBSD that is not
going on with FreeBSD regarding inet6 traffic? On FreeBSD, ipfw
shows inet6 traffic like this:
0 0 allow log ipv6-icmp from :: to ff02::/16
0 0 allow log ipv6-icmp from fe80::/10 to fe80::/10
0 0 allow log ipv6-icmp from fe80::/10 to ff02::/10
13935 952840 allow log ipv6-icmp from any to any \
ip6 icmp6types 1,2,128,129,135,136
so it seems like there is no link-local traffic while about 14
thousand packets have passed otherwise, even considering that ipfw
passes the first match and npf passes the last match.
Maybe the FreeBSD kernel is not passing administrative packets like
Duplicate Address Detection and Neighbor Discovery to ipfw?
At least these need to happen even on a statically configured host
(or a router).