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

james woodyatt <> Mon, 22 June 2015 22:42 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1D7251A90EC for <>; Mon, 22 Jun 2015 15:42:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Z00ukxqsh-a9 for <>; Mon, 22 Jun 2015 15:42:09 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 84BCE1A8937 for <>; Mon, 22 Jun 2015 15:42:09 -0700 (PDT)
Received: by igboe5 with SMTP id oe5so75102485igb.1 for <>; Mon, 22 Jun 2015 15:42:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=K1Y1NFfa0v152HwWvTsVg3iu1g8g9dDXKF0lp/WvH6o=; b=fPH/VCCbJqQxWRLux8rk1yu6rRbIGiPo2GiM4p3V9nLOgSbmkB/JK16sSBKnzWhzLO NGm/pTKMwkggHTye0wGIPRxd165HGzZqNITlmbz+Q0l4vjB3A3N04pbSobbljZBGJ82K GudHU1fcy4GlBOTrdFtmmGCTLb2heFlGvhZaw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=K1Y1NFfa0v152HwWvTsVg3iu1g8g9dDXKF0lp/WvH6o=; b=UN6+aGkMcP/XOo1LIKQoPHGh7QBR11T28960baaqSTiF4grECgjDK9aTJ0G+i5mUj0 Iz3pdwdzeK+vL+tH1c26EPRI4mbYCYVPvNIAcWH4D5y6Vx//BiezjWFez2cVtwhY7UTo LCpdqTJLslk8bjUtSQh6xzIqMB5JXkdSun4xbspmBeFrC6lPPLV/lKTQiIbAo96DM57A b3VqqjkYBWDybaMR0TuGE0St4cPW+KlN5RBzgnM3zZvD5qnjuQujCUDULKKWzH6WIYRP mQRMpGCN0tm5k5n8eieNX30nTXLY2VHGEPhyhiV7HuyrW9EojHe/J84bm4iy6Dognf2o DxSA==
X-Gm-Message-State: ALoCoQk97zIJZ+22eCvdlfTo6i5npo6rpIpIE7FVmXmiHueNgvT/NBL1OJ0c421pGewEs6CBQrl+
X-Received: by with SMTP id jd8mr23969745igb.47.1435012928996; Mon, 22 Jun 2015 15:42:08 -0700 (PDT)
Received: from ([]) by with ESMTPSA id h128sm13734670ioh.38.2015. (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 22 Jun 2015 15:42:08 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
From: james woodyatt <>
In-Reply-To: <>
Date: Mon, 22 Jun 2015 15:42:06 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <>
To: Iljitsch van Beijnum <>
X-Mailer: Apple Mail (2.2098)
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: Mon, 22 Jun 2015 22:42:11 -0000

On Jun 22, 2015, at 14:47, Iljitsch van Beijnum <> wrote:
> On 22 Jun 2015, at 23:26, james woodyatt <> 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.