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

Iljitsch van Beijnum <iljitsch@muada.com> Mon, 22 June 2015 20:50 UTC

Return-Path: <iljitsch@muada.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D7DE1ACF54 for <v6ops@ietfa.amsl.com>; Mon, 22 Jun 2015 13:50:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.79
X-Spam-Level:
X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 79Pn5LMIkBjr for <v6ops@ietfa.amsl.com>; Mon, 22 Jun 2015 13:50:50 -0700 (PDT)
Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FDD91A6F2D for <v6ops@ietf.org>; Mon, 22 Jun 2015 13:50:49 -0700 (PDT)
Received: from global-hq.muada.nl (global-hq.muada.nl [IPv6:2001:470:1f15:8b5:7964:27be:c625:11ee] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id t5MKnhHU032932 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Jun 2015 22:49:43 +0200 (CEST) (envelope-from iljitsch@muada.com)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
From: Iljitsch van Beijnum <iljitsch@muada.com>
In-Reply-To: <1DD3B5D4-9F8B-4EE2-BC53-D840E9758FB9@delong.com>
Date: Mon, 22 Jun 2015 22:50:36 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <629902C3-6393-42DD-88E2-C72384EE8529@muada.com>
References: <E1C235B5-1421-4DAF-A2F3-F963982233DF@apple.com> <90744458-CA06-4347-A96B-D649800855D3@muada.com> <1DD3B5D4-9F8B-4EE2-BC53-D840E9758FB9@delong.com>
To: Owen DeLong <owen@delong.com>
X-Mailer: Apple Mail (2.2098)
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/MWQVDahGhxtI8Iuk9anx-l_MsKA>
Cc: v6ops@ietf.org, Vividh Siddha <vsiddha@apple.com>
Subject: Re: [v6ops] Happy eyeballs suggestions, was: Re: Apple and IPv6, a few clarifications
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Jun 2015 20:50:52 -0000

On 22 Jun 2015, at 18:49, Owen DeLong <owen@delong.com> wrote:

>> So if you guys currently look at the RTT for the three-way handshake, it would probably help if you could look at the RTT for data packets instead.

> Pretty hard to look at the data RTT when establishing a connection. How do you see that working?

I don't know the details of Apple's (or anyone else's) happy eyeballs implementation. If they set up connections, measure the RTT for the three three-way handshake and then abandon the higher RTT session, or initiate connections in parallel and only pursue the one that connects first, then you're right, this would be a problem. On the other hand, if they do an HTTP request over IPv4 and one over IPv6, then an RTT for data segments would be available.

>> Basically, what's needed for this is that if the interface in question is configured with "real" IPv6 addresses, those are kept and the prefix in question is advertised in RAs.

> Wouldn’t that require bridging to between the real interface and the test interface rather than routing? Perhaps that’s not a bad idea, (the kernel already has the necessary bridging code), but a consistent and deterministic way of selecting bridge vs. route would be necessary to create a full test environment, IMHO.

Hm, if native IPv6 is available on interface A but you want to run your test NAT64 network on interface B and thus need to bridge A and B, why wouldn't you just cut out the middleman and run your test NAT64 network on interface B?

Likely answer: because B is actually dual stack and you need to keep out the IPv4. So then not only would you have to bridge the IPv6, you would have to filter out the IPv4 while doing that. That seems a tall order.

A much simpler solution is to simply route a /64 to the interface that hosts the test NAT64 network. Obviously if you have consumer-level native IPv6 that won't always be possible because you only get a /64 and/or a way to route additional subnets through cascading DHCPv6 PD or an IPv6 routing protocol isn't supported.

But if all else fails you can terminate a tunnel broker (.net) tunnel on your Mac and route a /64 to the desired interface and turn on IPv6 forwarding in the kernel.

If Apple is interested in solving more of this than just allowing us to set up our own IPv6 addresses on the test NAT64 interface (which is the only part we need Apple to make possible, we can do the rest ourselves) then IPv6 bridging with IPv4 blocking would be a good choice because then you can easily take advantage of native IPv6 on an interface without automatically getting the IPv4 that virtually always comes with it.