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

Iljitsch van Beijnum <> Mon, 22 June 2015 21:48 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 4258D1A90E5 for <>; Mon, 22 Jun 2015 14:48:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OO78jl3Rvc9r for <>; Mon, 22 Jun 2015 14:48:02 -0700 (PDT)
Received: from ( [IPv6:2001:1af8:3100:a006:1::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B47EF1A01FC for <>; Mon, 22 Jun 2015 14:48:01 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.13.3/8.13.3) with ESMTP id t5MLl0pn033249 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Jun 2015 23:47:01 +0200 (CEST) (envelope-from
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
From: Iljitsch van Beijnum <>
In-Reply-To: <>
Date: Mon, 22 Jun 2015 23:47:49 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <>
To: james woodyatt <>
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 21:48:03 -0000

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.