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

[Owen DeLong <[e-mail]>]

> On Jun 22, 2015, at 16:31 , Iljitsch van Beijnum <[e-mail]> wrote:
> 
> On 23 Jun 2015, at 1:18, james woodyatt <[e-mail]> wrote:
> 
>>> As such: […] I'm 99.9% sure this works the same way for UDP as for ICMPv6; […]
> 
>> It does.
> 
> So then why would this be a problem:
> 
>> 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.
> 
> What exactly are you objecting to? That the translated packets are too small to trigger too bigs? That also happens with native IPv6 if the path supports 1500 bytes. So if you want to test for paths with < 1500 PMTUs, you will have to, you know, do the work to test with paths with < 1500 PTMUs.
> 
> If your problem is that applications don't handle incoming too bigs, then be glad you're behind a NAT64 because this is indeed a problem with IPv4 (but easily solved by simply setting the DF bit to 0!) but it isn't for IPv6, as we just agreed that with IPv6, the IP layer catches too bigs and fragments subsequent packets without involvement from the application.
> 

Let me try and get you guys to stop talking across each other…

The issue James has (rightly, IMHO) raised is that at the application developer level, you may or may not think to test for <1500 MTU.

However, if you test your 1500-octet packet using application in a NAT64 environment and it works (because you’re connecting to an IPv4 server via a NAT that shortens your packets) and you think everything is wonderful and ship your application, it could come as a rude shock to your end-users who happen to have native IPv6 that wasn’t available in your development environment because all of a sudden, the 1500-octet packets you are sending are leaving the device as 1500-octet packets and dying in the wild rather than getting artificially shortened.

Thus, you’ve got a scenario where NAT64 testing is inadequate vs. NAT64 + Native V6 testing which was, in fact, the original question.

Owen