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

Owen DeLong <> Tue, 23 June 2015 00:03 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 21C9D1ACD4C for <>; Mon, 22 Jun 2015 17:03:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.289
X-Spam-Status: No, score=0.289 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_ADSP_ALL=0.8, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zuhly0esPy0k for <>; Mon, 22 Jun 2015 17:03:21 -0700 (PDT)
Received: from ( [IPv6:2620:0:930::200:2]) by (Postfix) with ESMTP id 38B6F1ACD38 for <>; Mon, 22 Jun 2015 17:03:20 -0700 (PDT)
Received: from [IPv6:2620::930:0:ae87:a3ff:fe29:7192] ([IPv6:2620:0:930:0:ae87:a3ff:fe29:7192]) (authenticated bits=0) by (8.14.4/8.14.2) with ESMTP id t5N03JZv031679 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 22 Jun 2015 17:03:19 -0700
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
From: Owen DeLong <>
In-Reply-To: <>
Date: Mon, 22 Jun 2015 17:03:18 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <>
To: Iljitsch van Beijnum <>
X-Mailer: Apple Mail (2.2098)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 ( [IPv6:2620:0:930::200:2]); Mon, 22 Jun 2015 17:03:19 -0700 (PDT)
Archived-At: <>
Cc: "" <>
Subject: Re: [v6ops] Happy eyeballs suggestions, was: Re: Apple and IPv6, a few clarifications
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 23 Jun 2015 00:03:22 -0000

> On Jun 22, 2015, at 16:31 , Iljitsch van Beijnum <> wrote:
> On 23 Jun 2015, at 1:18, james woodyatt <> 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.