TCP over fragmented IPv6 dropped in Comcast's network

[Clint Armstrong <clint () clintarmstrong net>]

In troubleshooting why a DNS zone transfer fails over IPv6 from a DNS
master hosted on a Comcast connection, I've discovered that a router in
Comcast's network is IPv6 Fragments with TCP headers.

More specifically it appears that this router silently drops any packet
with a non-zero fragment offset, followed by a tcp header. Packets with a
fragment offset followed by a udp header, or anything else, are passed just
fine. Also, fragments sent in the opposite direction, from outside Comcast
coming in, are passed just fine.

I believe I was able to determine the problematic router by using the
sendip tool to generate these dropped packets and increasing the TTL on the
packet until I no longer got an ICMPv6 unreachable response from the next
hop.

If anyone else with a Comcast IPv6 connection would like to test and see if
your connections are affected by this issue, here is how you can test.

First you need sendip version 2.5-mec-3a2 with the frag.so module.

Start tcpdump or wireshark looking for ICMPv6 Time Exceeded messages.

Then send test packets to any destination IP you'd like to test a route to
using the command `sendip <dest_addr> -p ipv6 -6s <source_addr> -6h 2  -p
frag -Fo 1 -p tcp`

Increment the 6h value until you no longer get an ICMPv6 Time Exceeded
response. At that point try removing the `-p tcp` parameter and see if that
works. In my case, it does, demonstrating that this problematic router
successfully passes IPv6 fragments without a TCP header.

If anyone at Comcast would like to contact me off-list, I'll share more
details of my findings, including the source address where I'm testing
from, and what I believe is the problematic router.