See also RFC 6946 on this topic and the more controversial draft-ietf-6man-deprecate-atomfrag-generation
-éric On 29/04/16 08:43, "ipv6-ops-bounces+evyncke=cisco....@lists.cluenet.de on behalf of Seth Mos" <ipv6-ops-bounces+evyncke=cisco....@lists.cluenet.de on behalf of seth....@dds.nl> wrote: >Op 29-4-2016 om 8:30 schreef Mikael Abrahamsson: >> Hi, >> >> Site B which sends all data packets as fragments. This is most likely >> because they have some kind of AFTR where the IPv4 side has MTU1500 and >> the IPv6 side has MTU1320 or something like that. > >The site cbs.nl does this as well. It's the statistics agency for the >Netherlands. They use a Juniper with IPv4 to IPv6 translation, however, >it sets the frag attribute for all packets including the ACK. > >I've had extensive debugging to find out what was going wrong. >Eventually I found that our firewall was dropping IPv6 fragments, making >the website unreachable over IPv6. > >The RFC for this translation mode was followed literally, so it could be >argued that this is "to spec". > >Neither Juniper nor the website owner was willing to make any changes >(and make it reachable for anyone that dropped frags, it wasn't just >us). They could have just used a proxy or load balancer to terminate the >connections instead of relying on a passive NAT and not have any of >these problems. > >Cheers, > >Seth