Re: [v6ops] Happy eyeballs suggestions, was: Re: Apple and IPv6, a few clarifications

[james woodyatt <[e-mail]>]

On Jun 22, 2015, at 15:57, Iljitsch van Beijnum <[e-mail]> wrote:
> On 23 Jun 2015, at 0:42, james woodyatt <[e-mail]> wrote:
> 
>> I think you might have overlooked where I wrote “UDP” above instead of “TCP” which on iOS and OS X doesn’t have any PMTUD support. The kernel will not do any fragmentation or retransmission of UDP packets.
> 
> No, I didn't overlook that part. But let me return the favor: I think you're confusing IPv6 with IPv4 here. In IPv6, fragmentation is an IP-level function on the host.

I’m not confused about that.

> As such: […] I'm 99.9% sure this works the same way for UDP as for ICMPv6; […]

It does.

> You're right about the retransmission part, though, the first packet (the one that triggers the too big) is lost. If the return packet (for the retransmission) is also large, that one will very likely also be lost and cause the too big in the other direction, so it takes two retransmissions to get a reply.


The problem is that you can send those 1500 octet packets out your Wi-fi, and the NAT64 will shorten them to 1480 when it replaces the IPv6 header with an IPv4 header. Those 1480-octet IPv4 packets will then pass straight through parts of the network with PMTU=1492 without generating errors and therefore never exercising any application layer logic needed to deal with UDP-PMTUD, which is typically not there at all because developers are… well, they often don’t do it. Hence, you have something that works on NAT64 that will fail when they encounter native IPv6 and PMTU=1492, which is as we all know, not as uncommon as we’d like it to be.


—james