Re: Happy eyeballs suggestions, was: Re: Apple and IPv6, a few clarifications
james woodyatt <jhw@...
2015-06-22 23:18:15 GMT
On Jun 22, 2015, at 15:57, Iljitsch van Beijnum <iljitsch <at> muada.com> wrote:
> On 23 Jun 2015, at 0:42, james woodyatt <jhw <at> nestlabs.com> 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; […]
> 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.
v6ops mailing list