IPv6 fragment handling

  • Will pfSense 2.2 deal with IPv6 fragments properly?
    IIRC it is a big problem for those with IPv6 tunnel connectivity to receive responses to IPv6 DNSSEC traffic. I also ran into problems playing with IPv6 IPsec tunnels if memory serves right.
    At least DNS would be a problem noticed frequently now that Unbound is in base. As a workaround I always had to switch do-ip6 to no for Unbound.

  • I have little experience with IPv6, and I'm kind of curious as to what kind of problems. According to the IPv6 spec, the minimum MTU is 1280 and the end points are responsible for making sure that all packets fit in the path's MTU.

    One thing I found was this for a work around. Disable normalization for IPv6 fragments: pass in on <int>inet6 proto ipv6-frag all

    Pretty much means your firewall is disabled on IPv6 fragments.

    IPv6 requires that every link in the internet have an MTU of 1280
      octets or greater.  On any link that cannot convey a 1280-octet
      packet in one piece, link-specific fragmentation and reassembly must
      be provided at a layer below IPv6.

    According to the RFC, if your tunnel is only 1280, and you attempt another tunnel, then it is the responsibility of that second tunnel to handle fragmentation, not IPv6.

    Sounds like the issue with fragments is the packets are not self-contained. You need to accumulate data across the many packets. OpenBSD tried implementing fragmentation support, but eventually pulled it because of issues with complexity. Linux supports it, but I guess it has some security issues related to an attack being able to side step the firewall.

    According to the RFC, fragments are highly recommended against, but if you absolutely need them, they have a standard. Seems few OSes have implemented the standard and the one that did, have some glaring holes. FreeBSD opted for a "drop the packets". Much safer.

    The reasons given by FreeBSD seem to give little solace to those who "need" fragmentation to work.</int>

  • That may or may not make 2.2. That'd been the plan, but we're running short on time so some non-regressions may get pushed to post-2.2.

  • Good news, many thanks for the info!