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.