Re: [v6ops] Apple and IPv6 - Happy Eyeballs

Sander Steffann <> Fri, 10 July 2015 12:40 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 949681A9300 for <>; Fri, 10 Jul 2015 05:40:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.494
X-Spam-Level: *
X-Spam-Status: No, score=1.494 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oe9geKF2SMWi for <>; Fri, 10 Jul 2015 05:40:00 -0700 (PDT)
Received: from ( [IPv6:2001:9e0:803::6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E484F1A92FC for <>; Fri, 10 Jul 2015 05:39:59 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6F66545; Fri, 10 Jul 2015 14:39:56 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; h= x-mailer:references:message-id:content-transfer-encoding:date :date:in-reply-to:from:from:subject:subject:mime-version :content-type:content-type:received:received; s=mail; t= 1436531994; bh=sfGvDvQ37k3ffrPyrwQ/b2zECmYalUepCP8gh/iIyiE=; b=q Dge7laI4pNjLmjvIqRNxHkk9mAP3+xumfoFdYr8kBxy/dhoNzRSyZ/sqa0SGxoO5 boDoWVmY7JH04wU+FQCDl+dpS6QR59itWxblqQxnxmjAGfhh+0xKyX45Cu0kyzxV OYlW7/yaFnQp0+WLTrMxk8us35RZwqTDRayv89pmQ4=
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10026) with ESMTP id M016RSsN8yBL; Fri, 10 Jul 2015 14:39:54 +0200 (CEST)
Received: from [IPv6:2a00:8640:1::1491:7bec:f773:fb31] (unknown [IPv6:2a00:8640:1:0:1491:7bec:f773:fb31]) by (Postfix) with ESMTPSA id 14F4543; Fri, 10 Jul 2015 14:39:53 +0200 (CEST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\))
X-Clacks-Overhead: GNU Terry Pratchett
From: Sander Steffann <>
In-Reply-To: <>
Date: Fri, 10 Jul 2015 14:39:53 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: David Schinazi <>
X-Mailer: Apple Mail (2.2102)
Archived-At: <>
Cc: Paul Saab <>,
Subject: Re: [v6ops] Apple and IPv6 - Happy Eyeballs
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: Fri, 10 Jul 2015 12:40:01 -0000

Hi David,

> Today Apple released the first public seeds of iOS 9 and OS X El Capitan.
> These seeds (and the third developer seeds released yesterday) include an improved version of Happy Eyeballs.
> Based on our testing, this makes our Happy Eyeballs implementation go from roughly 50/50 IPv4/IPv6 in iOS 8 and Yosemite to ~99% IPv6 in iOS 9 and El Capitan betas.

Very glad to hear that!

> While our previous implementation from four years ago was designed to select the connection with lowest latency no matter what, we agree that the Internet has changed since then and reports indicate that biasing towards IPv6 is now beneficial for our customers: IPv6 is now mainstream instead of being an exception, there are less broken IPv6 tunnels, IPv4 carrier-grade NATs are increasing in numbers, and throughput may even be better on average over IPv6.
> The updated implementation performs the following:
> - Query the DNS resolver for A and AAAA.
>   If the DNS records are not in the cache, the requests are sent back to back on the wire, AAAA first.
> - If the first reply we get is AAAA, we send out the v6 SYN immediately
> - If the first reply we get is A and we're expecting a AAAA, we start a 25ms timer
>   - If the timer fires, we send out the v4 SYN
>   - If we get the AAAA during that 25ms window, we move on to address selection
> - When we have a list of IP addresses (either from the DNS cache or by receiving them close together with v4 before v6), we perform our own address selection algorithm to sort them. This algorithm uses historical RTT data to prefer addresses that have lower latency - but has a 25ms leeway: if the historical RTT of two compared address are within 25ms of each other, we use RFC3484 to pick the best one.

RFC 3484 or 6724?

> - Once the list is sorted, we send out the SYN for the first address and start timers based on average and variance of the historical TCP RTT. Roughly speaking, we start the second address around the same time we send out a SYN retransmission for the first address.
> - The first address to reply with a SYN-ACK wins the race, we then cancel the other TCP connection attempts.

That sounds like a reasonable algorithm.