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

[Iljitsch van Beijnum <[e-mail]>]

On 22 Jun 2015, at 18:49, Owen DeLong <[e-mail]> 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.