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

[james woodyatt <[e-mail]>]

On Jun 22, 2015, at 14:47, Iljitsch van Beijnum <[e-mail]> wrote:
> On 22 Jun 2015, at 23:26, james woodyatt <[e-mail]> wrote:
> 
>>> Hm, what kind of stuff would work through NAT64 that wouldn't work with real IPv6 connectivity?
> 
>> An obvious example would be a UDP application that depends on a 1500 octet path MTU to all the IPv6 destinations it cares about. The NAT64 will shave a 1500 octet packet down to 1480, which might make it everywhere you want to go over IPv4 without needing to handle ICMPv6 Packet Too Big Errors, leaving you to discover later that native IPv6 destinations require you to deal with paths that are 1492 octets and not 1500 octets.
> 
> Sure. Except that the kernel will handle all your fragmentation needs invisibly to the application (well, save for a retransmission or two). And testing with native IPv6 won't catch this most of the time anyway, as 65% of all paths (in my very limited measurements, but still) are 1500-byte clean.
> 
> Also, I certainly hope application writers aren't going to test their applications for compatibility with networks that filter ICMPv6 too bigs, that would be insanity.

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. A lot of applications are coded never to process the error code at a socket if a Too Big error is received. They either ignore the error and fail because packet size are never reduced, or they fail inappropriately rather than reduce packet sizes. Developers who only use the NAT64 environment without testing on a native IPv6 network may never see the Too Big errors that would expose this problem, and they won’t see it until their application is deployed for reals.


—james