IPFW has two flaws in its handling of IPv6 packets that arrive in
fragments. First, it will deny an IPv6 packet that arrives with
a fragmentation header which has an offset of zero, but no
further fragments. This type of packet is explicitly allowed in
RFC 2460:

In response to an IPv6 packet that is sent to an IPv4 destination
(i.e., a packet that undergoes translation from IPv6 to IPv4),
the originating IPv6 node may receive an ICMP Packet Too Big
message reporting a Next-Hop MTU less than 1280. In that
case, the IPv6 node is not required to reduce the size of
subsequent packets to less than 1280, but must include a
Fragment header in those packets so that the IPv6-to-IPv4
translating router can obtain a suitable Identification value
to use in resulting IPv4 fragments. Note that this means the
payload may have to be reduced to 1232 octets (1280 minus 40
for the IPv6 header and 8 for the Fragment header), and
smaller still if additional extension headers are used.

The second flaw is that the code allows IPv6 packets that arrive in
fragments to avoid transport-layer rules. For example, consider this
ruleset:

00001 deny tcp from 2607:f0b0:0:6:209:87:239:67 80 to 2404:138:4002:4000:205:1cff:fe11:beff dst-port 37822
65534 allow ip from any to any
65535 deny ip from any to any

Rule 1 will not be applied to the fragment with offset zero
because the MF bit is intentionally included in the offset
variable used in ipfw_chk, so the check to see if the transport
header is found in fragment zero will fail. Instead, the rule
will be skipped over, and the next rule which in this example is
an allow will accept the fragment. Where an administrator might
have expected the traffic to be blocked it will instead be
allowed through the firewall.

Attached is a revised patch fixing a third flaw. ipfw will reject
very small IPv6 fragments when it tries to pullup the transport
header. This relaxes the code to be consistent with the IPv4 path
where it only tries to pull up the transport header on fragments with
offset zero.

Reported to FreeBSD by Matthew Luckie , pr 145733.