MTU/MSS testing IPv6

[Shane Kerr]

Seth,

At 2016-04-29 08:43:09 +0200
Seth Mos <seth.mos at dds.nl> wrote:

> Op 29-4-2016 om 8:30 schreef Mikael Abrahamsson:
> > 
> > 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.

Presumably this is because the firewall wants the capability to do DPI
(deep-packet inspection) or something like that, and the cost of
managing fragmented streams is too high?

This is how we end up with every end host setting MTU to 1280.
Otherwise their fragments will get dropped by broken middleboxes. :(

> 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.

True, true. It's odd behavior, but one that will hopefully become more
rare as native IPv6 becomes more normal.

OTOH, blocking all IPv6 fragments seems a bit too aggressive for
firewalls. I guess if you are only expecting TCP traffic it is probably
okay though, since TCP does PMTU discovery and shouldn't result in
fragmented traffic.

Cheers,

--
Shane
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <https://lists.cluenet.de/pipermail/ipv6-ops/attachments/20160429/97cb67b2/attachment.sig>