Subject: [v6ops] Happy Eyeballs operational issues

From: "Dale W. Carder" <[email-masked]>
Date: Mon, 24 Jan 2011 15:50:39 -0600

My experience in the past 8 or so years of production dual stack v6 service 
is that clients always try an AAAA record before an A record.  This has
proved to be easy to troubleshoot and support.

After reading draft-wing-v6ops-happy-eyeballs-ipv6-01, I would be concerned 
about trying to support hosts that do not deterministicly choose an address 
family to use.  Now on top of that, it would be unlikely that every
application will implement it or implement it exactly the same way.  To an
operator such undeterministic behavor is not easy to diagnose, fix, and
confirm when resolved.

In addition I would think it would be harder to sunset v4 service if
this is widely implemented.  I think (at some point) people will be watching 
the v4 traffic approach zero.  With happy eyeballs in place it may never get
even close.  Phased another way, if we had happy eyeballs implementations
in place years ago, we would probably still think we had to run IPX and 
appletalk now.

I think more effort should be spent making sure hosts are using RFC 5014,
and making v6 actually work.

Dale

---

From: Fred Baker <[email-masked]>
Date: Mon, 24 Jan 2011 14:23:44 -0800

On Jan 24, 2011, at 1:50 PM, Dale W. Carder wrote:

> In addition I would think it would be harder to sunset v4 service if this is widely implemented.  I think (at some point) people will be watching the v4 traffic approach zero. 

There I disagree. The question we are asked now is "why do I need to turn on IPv6 at all", and the reason has to do with the availability of address space and the ability to communicate with a set of peers - business partners, people one would like to sell to, people one would like to buy from, and so on. Even at this point, while it is increasingly obvious to ISPs why *they* need the additional address space (to deploy new services, meet new customers, etc), I am asked (as recently as last Friday) "so what business will I be able to transact that I cannot now transact with IPv4?" and "who are all these peers that are available on IPv6 and not IPv4?" At some point, I expect the absolute reverse: "I am operating a dual stack network, IPv4+IPv6. Yes, I see traffic using IPv4, and I do 50% of my business using it. However, which of those folks is not also accessible by IPv6, and is the number of them low enough for me to simply advise them that they need to get with the program as from some certain date I will no longer support IPv4?".

IPv4 traffic going to zero will come a lot later than the tipping point, but I expect CIOs to start acting at the tipping point. That's what makes it a tipping point.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 24 Jan 2011 17:27:52 -0500

> operator such undeterministic behavor is not easy to diagnose, fix, and

The behavior of devices on the network is never deterministic unless you have a very constrained network.   I think what you mean here is that which protocol will be chosen is not deterministic.   Perhaps so, but what is deterministic is that happy eyeballs will choose the protocol that works best at any given moment.

So when there is better IPv6 than IPv4 service, you will see IPv4 traffic drop off.  Deterministically.

:)

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 24 Jan 2011 19:53:20 -0800

> So when there is better IPv6 than IPv4 service, you will see IPv4 traffic drop off.  Deterministically.

I share similar heart burn on this issue to Dale.

On one hand, without pushing IPv6, traffic levels may not grow.  And
if they don't grow, they won't get funded for more development and
hacks like tunnels stay in place ... the service is poor, but there is
not traffic growth so why invest in more v6 capacity or native v6
capacity?  That is the reality of ISP builds.

On the other hand, i have a hard time accepting a crappy highly latent
poorly peered low MTU IPv6 service .... Yes, thats reality of IPv6 in
many places today.  Getting to Google via my home 6RD connection
involves more than 1 cross country trip ... and no, Youtube does not
play well at all in Seattle via this 6RD connection.   I wish i could
say otherwise. I hear native is on the way at some point for my ISP,
but many others will not be so lucky.  In fact, my native IPv6 on 3G
youtube plays better than my 6RD home connection.

I do personally feel happy eyeballs does not help us turn the page on
IPv4, even though it has the laudable ideals of choosing better
service.

Cameron
> :)
>
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Rémi Després <[email-masked]>
Date: Tue, 25 Jan 2011 17:41:59 +0100

Le 25 janv. 2011 à 04:53, Cameron Byrne a écrit :

> poorly peered low MTU IPv6 service ....

In IPv6, You must get at least an MTU of 1280.
Since the difference with the typical 1500 isn't that large, there must be another explanation to your problem.

> Yes, thats reality of IPv6 in
> involves more than 1 cross country trip ...

Why is it so?

> and no, Youtube does not
> but many others will not be so lucky.  

The 6rd of Free works fine, including for Youtube.

> In fact, my native IPv6 on 3G

The hotline for your DSL access should have an explanation, but it CANNOT BE an intrinsic characteristic of 6rd.

> IPv4, even though it has the laudable ideals of choosing better

I agree with you that IPv6 traffic will grow when offered with good quality.
(As a matter of fact, 6rd has proved to be one way of achieving it quickly, and on a large scale with regularly growing traffic.)

Regards,
RD

---

From: Cameron Byrne <[email-masked]>
Date: Tue, 25 Jan 2011 09:25:03 -0800

>> involves more than 1 cross country trip ...

Mostly my performance issues are a result of immature peering issues,
v6 is much less well provisioned and peered than v4.  I am just
sharing my IPv6 home access use case.

But, part of me was timing how long before you came to rescue 6RDs good name :)

Cameron

---

From: Simon Perreault <[email-masked]>
Date: Tue, 25 Jan 2011 14:15:43 -0500

On 2011-01-24 22:53, Cameron Byrne wrote:
> On one hand, without pushing IPv6, traffic levels may not grow. [...]
>
> poorly peered low MTU IPv6 service [...]

So what you're saying is you'd like to prefer IPv6, even if IPv6 is 
slightly worse than IPv4, but not past a given threshold. Right?

Happy eyeballs provides for that. Here's the text:

    The TCP client application is configured with one value, P. A
    positive value indicates a preference for IPv6 and a negative value
    indicates a preference for IPv4.  A value of 0 indicates equal
    weight, which means the A and AAAA queries and associated connection
    attempts will be sent as quickly as possible.  The absolute value of
    P is the measure of a delay before initiating a connection attempt on
    the other address family.  There are two P values maintained:  one is
    application-wide and the other is specific per each destination
    (hostname and port).

(See section 4.1 for the rest...)

Simon
-- 
NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
STUN/TURN server        --> http://numb.viagenie.ca
vCard 4.0               --> http://www.vcarddav.org

---

From: Mark Townsley <[email-masked]>
Date: Wed, 26 Jan 2011 22:39:43 +0100

> youtube plays better than my 6RD home connection.

 It really doesn't have to be that way. Someone isn't enabling 6rd on enough routers in enough locations. 

- Mark

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 27 Jan 2011 12:18:17 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Mark Townsley
> Sent: Wednesday, January 26, 2011 1:40 PM
> To: Cameron Byrne
> Cc: [email-masked]
> Subject: Re: [v6ops] Happy Eyeballs operational issues
> 
> 
> >> The behavior of devices on the network is never 
> deterministic unless you have a very constrained network.   I 
> think what you mean here is that which protocol will be 
> chosen is not deterministic.   Perhaps so, but what is 
> deterministic is that happy eyeballs will choose the protocol 
> that works best at any given moment.
> >> 
> >> So when there is better IPv6 than IPv4 service, you will 
> see IPv4 traffic drop off.  Deterministically.
> >> 
> > 
>  It really doesn't have to be that way. Someone isn't 
> enabling 6rd on enough routers in enough locations.

Or maybe they should be deploying a better service than 6RD:

http://www.rfc-editor.org/internet-drafts/draft-templin-iron-17.txt

Fred
[email-masked]