Re: weird IPv6 packet dropping with 6to4

[Taylor R Campbell <campbell%mumble.net@localhost>]

   Date: Sat, 5 Sep 2009 13:25:30 +0100
   From: Matthias Scheler <tron%zhadum.org.uk@localhost>

   I'm not very convinced about the usefulness of PF's scrubbing in general.
   But there is no reason to limit the MSS of TCP connections here.
   IPv6 requires to handle fragmentation via ICMP.

Why might NetBSD not be sending ICMP6 packet-too-big messages, then?
There aren't any in the packet traces.  These packet traces are not
complete, since I filtered only a subset of the packets, but running
tcpdump with no filter showed no more relevant packets.

Something I do notice, though, is that when I omit MSS clamping from
stf0, I sometimes get IPv4 fragmented packets (containing encapsulated
IPv6 packets).  While I'm sure that the system should be able to cope
with this and reassemble whole IPv6 packets, that doesn't seem right!

   > block drop all

   I don't think the 

Did you mean to finish this sentence with something about dropping
packets versus returning ICMP packets?  `drop' is the default in pf
for block rules; I didn't write that explicitly.  Changing it to
`return' doesn't affect whether I can load web pages at www.ietf.org
-- I still get similar packet traces, and no new ICMP packets.

   This looks wrong. As a 6to4 host you can receive IPv6 packets from
   different remote endpoints. I don't think that state keeping can
   work here.

Like `drop', `keep state' is the default in pf; I didn't write that in
the configuration file.  I doubt whether it hurts.