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

Ca By <> Mon, 22 June 2015 22:58 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E409F1B2A1A for <>; Mon, 22 Jun 2015 15:58:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3y0l3A5XD0M6 for <>; Mon, 22 Jun 2015 15:58:58 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c00::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 87EE81B2A15 for <>; Mon, 22 Jun 2015 15:58:57 -0700 (PDT)
Received: by wgqq4 with SMTP id q4so28552421wgq.1 for <>; Mon, 22 Jun 2015 15:58:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=viHe9jmkVj1W7pzncCvRnjXLK6RIZwsWE5vuZn98h+Q=; b=TJSrkNUJP8i5YofOsVlrYjHRwpidbdKYCGQLPaahhPS345zfDW0w6j9+vXMtB701fs Ohw/5CnH1JRhHxk43xtF+7cKIjMLZf+S9SdlP8/mkbpJj3ebeQOFpn5QlyvHkfarUb3W WNVdljylKKBjmppWeZHR/gjmGdUfd/Eed+zMwHak3aNlnTZS0Mo+sk0sn/Mn+KopKdwX CM7yG+0LKn3fc0e91/C+k8W/nqqHgMtT6k+aEWE5xqy4syMC2zkunU2QWnAkWHhNdfym xgT+gBqcar7nRZTmqqPVd5uGYXfcHR5iBUyDR1Tic6+3YuYsOX+N9MeTPmoyo/198pXT 0aog==
MIME-Version: 1.0
X-Received: by with SMTP id it10mr36619011wid.41.1435013936235; Mon, 22 Jun 2015 15:58:56 -0700 (PDT)
Received: by with HTTP; Mon, 22 Jun 2015 15:58:56 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <>
Date: Mon, 22 Jun 2015 15:58:56 -0700
Message-ID: <>
From: Ca By <>
To: james woodyatt <>
Content-Type: multipart/alternative; boundary=001a1136cbd8eac8cf0519233707
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:59:00 -0000

On Monday, June 22, 2015, james woodyatt <> wrote:

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

For some subset of networks, devs can test the real production deal if
apple could surface the apn setting in dev builds. It is hard to see the
harm in this. Other OSs allow apn setting fiddling. Also, this allows an
escape hatch for the inevitable user who cannot deal with ipv6-only in
production... And opens the door for end user opt in trials of ipv6.

It's really not a hard problem to solve for many situations (like tmus)
but the some backwards place .... They may not have this luxury of proper
ipv6 in mobile :/


> _______________________________________________
> v6ops mailing list
> <javascript:;>