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

james woodyatt <> Mon, 22 June 2015 23:18 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id EDF7C1B2A6B for <>; Mon, 22 Jun 2015 16:18:18 -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 fG2uuQVqLjTi for <>; Mon, 22 Jun 2015 16:18:17 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 97C581B2A68 for <>; Mon, 22 Jun 2015 16:18:17 -0700 (PDT)
Received: by igbqq3 with SMTP id qq3so75532480igb.0 for <>; Mon, 22 Jun 2015 16:18:17 -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=Y37KdEqH4SLT3GMUVU2sn45fYPH70CRNzRrfp08e8nQ=; b=cnB/sqq2DkhHtRM6NpjX84BC+lsV8tX8ojsPwIgufpEcdW9E4BXFpmGjXoFNVLe6T1 Ma3hJTl2pDn4D5q6gAgNQPvjcRlywwXtmEvftbwBjOAEiNv3ijYI29yZWHfJtAqx4E9A EEELE2cidkKzWwUiwNnQqCx8q3o8CLTLfmb88=
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=Y37KdEqH4SLT3GMUVU2sn45fYPH70CRNzRrfp08e8nQ=; b=C60xxfXWWSxGYXnUiTVOq9eUJuKV+d9ze268YYbgKltEcaeJDWzAAT/e6SHakVJeKe xw4QXR+WV9aeyFree3C1kgwq/J6JdInx0B6EOxr7lOgtxGmT7CYUq82zbhzxHe7Q67SN ooDQiJJMfZik7QUIwcMLYdCOPHQxw/RW2YKhCIcVD7pfn0XaqFaTSzbVDxLa5fvee1yp gGbh5ivnLOn1palTwt5JSoi86FBp2Vq8RaPXMNH2mfbu8/k5Ce3iZ72kM8wqO3zjYHMZ AGwLmYrxIz+K0mEgXtnM8zDro3/q6mST0uqTbZkPJrgp5k00hfr1sxEl/TYZeWf1pNGC uP9Q==
X-Gm-Message-State: ALoCoQmmFf/lqtyuwemLRwc7QJKCBTuTkKcuimOxdLNNGjJxUYUc8l4pKQZnYTfOI3jLZmAi3BXK
X-Received: by with SMTP id y4mr24236785igl.14.1435015096940; Mon, 22 Jun 2015 16:18:16 -0700 (PDT)
Received: from ([]) by with ESMTPSA id k74sm13797388iok.30.2015. (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 22 Jun 2015 16:18:16 -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 16:18:15 -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 23:18:19 -0000

On Jun 22, 2015, at 15:57, Iljitsch van Beijnum <> wrote:
> On 23 Jun 2015, at 0:42, james woodyatt <> wrote:
>> 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.
> No, I didn't overlook that part. But let me return the favor: I think you're confusing IPv6 with IPv4 here. In IPv6, fragmentation is an IP-level function on the host.

I’m not confused about that.

> As such: […] I'm 99.9% sure this works the same way for UDP as for ICMPv6; […]

It does.

> You're right about the retransmission part, though, the first packet (the one that triggers the too big) is lost. If the return packet (for the retransmission) is also large, that one will very likely also be lost and cause the too big in the other direction, so it takes two retransmissions to get a reply.

The problem is that you can send those 1500 octet packets out your Wi-fi, and the NAT64 will shorten them to 1480 when it replaces the IPv6 header with an IPv4 header. Those 1480-octet IPv4 packets will then 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. Hence, you have something that works on NAT64 that will fail when they encounter native IPv6 and PMTU=1492, which is as we all know, not as uncommon as we’d like it to be.