MTU/MSS testing IPv6

[Eric Vyncke (evyncke)]

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.com at lists.cluenet.de on
behalf of Seth Mos" <ipv6-ops-bounces+evyncke=cisco.com at lists.cluenet.de
on behalf of seth.mos at 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