Subject: Re: [v6ops] draft-pauly-v6ops-happy-eyeballs-update-01

From: David Schinazi <[email-masked]>
Date: Mon, 03 Apr 2017 14:45:17 -0700

Hi Cameron,

Jordi was asking us to phase out Happy Eyeballs because it masks breakage in the network,
and what plan we could build to gradually phase it out. My response was that if you, as a
network operator, prefer to avoid Happy Eyeballs, you can deploy IPv6-only, as that will
in effect disable HE.

The scenario you describe is the opposite: you have a broken server and want HE to
hide that breakage from users. The tradeoff here is slightly different since that breakage
is much less widespread. It is something that a NAT64-aware HE stack could provide though.

David

> On Mar 29, 2017, at 13:22, Ca By <[email-masked]> wrote:
> 
> Just a comment following up on Jordi's Mic comment
> 
> Jordi said there was an issue with HE hiding IPv6 issues.
> 
> David's response was something along the lines of "deploy ipv6-only".  I did not really understand this.
> 
> When folks deploy ipv6-only, they find they are all alone with a broken ipv6 scenarios that work on all their competitors IPv4-only networks and HE dual-stack networks.
> 
> Also, friendly reminder that Dan Wing catalogs a subset of the websites that fail on ipv6-only http://www.employees.org/~dwing/aaaa-stats/ <http://www.employees.org/~dwing/aaaa-stats/>
> 
> And, my customers still complain about www.fra.dot.gov <http://www.fra.dot.gov/> ... this works for everyone but me... because of HE...and I am already on IPv6-only ... and nobody will fix it.  This issues has been known by the USG DOT for over 3 months, noted to NANOG, nobody cares to fix it.
> 
> So, perhaps there is room in the I-D for including NAT64 synthesized address candidate set.  Meaning the HE algo on an IPv6-only host would include the set of available native IPv6 answers as well as a 500ms timer for attempting an A query with using whatever mechanism is available to the host for relaying IPv4 packets across an IPv6 only network (RFC6877, Bump in API, ...) 
> 
> Without this, IPv6-only networks are at a painful disadvantage since IPv6 must be perfect while every other scenario has HE to mask brokenness. 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 04 Apr 2017 00:22:54 +0200

Hi David,

I understand that a gradual phase out may be not feasible, or even difficult to standardize as I’m not even sure the IETF process provides that path. So, maybe the only option is to come back in 1-2 years and declare HE historic, maybe as part of the sunset4 WG work.

On Friday, speaking about this with a colleague, we had an idea, which could be part of the HE update.

What if we can, not just improve HE, but also ensure that the operators get reported those failures? May be by means of a well known IPv4+IPv6 anycast address in operator networks with a collector to get the data about those failures, or alternatively to the anycast, some DNS PTR, etc.

Maybe I’m targeting too high, but we could take also the opportunity to signal to the same collector those failures that HE doesn’t sort out, such as PMTUD.

Operators will decide if they implement it or not, but we can provide the tool at least, and seems to me that if we update HE, it may be the perfect place to do so.

Regards,
Jordi

-----Mensaje original-----
De: v6ops <[email-masked]> en nombre de David Schinazi <[email-masked]>
Responder a: <[email-masked]>
Fecha: lunes, 3 de abril de 2017, 23:45
Para: Ca By <[email-masked]>
CC: IPv6 Ops WG <[email-masked]>
Asunto: Re: [v6ops] draft-pauly-v6ops-happy-eyeballs-update-01

    Hi Cameron,

    David

    

    
    Also, friendly reminder that Dan Wing catalogs a subset of the websites that fail on ipv6-only http://www.employees.org/~dwing/aaaa-stats/

    

    

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

---

From: Sander Steffann <[email-masked]>
Date: Tue, 4 Apr 2017 00:34:26 +0200

Hi,

> I understand that a gradual phase out may be not feasible, or even difficult to standardize as I’m not even sure the IETF process provides that path. So, maybe the only option is to come back in 1-…

I once suggested to increase the HE timers to make broken IPv6 a bit more noticeable without breaking stuff completely. In the cases where the server is broken (I have seen insane AAAA records) it might be slightly less pleasant for the user, but suddenly there is a tangible incentive for the server to get fixed. "Unfortunately" the implementation of HE is on the user's side and the software developer's main goal is to provide a good user experience.

But yeah, HE is hiding brokenness. On one hand this is a good thing because it makes people less afraid of deploying IPv6 because the "risk" is lower. On the other hand that lower risk also means that problems don't get solved. My guess is that when more and more NAT64 networks get deployed, and HE doesn't help anymore, the brokenness will get fixed.

Cheers,
Sander

---

From: Ca By <[email-masked]>
Date: Mon, 03 Apr 2017 22:46:32 +0000

On Mon, Apr 3, 2017 at 3:34 PM Sander Steffann <[email-masked]> wrote:

> Hi,
>
> > I understand that a gradual phase out may be not feasible, or even
> difficult to standardize as I’m not even sure the IETF process provides
> that path. So, maybe the only option is to come back in 1-2 years and
> declare HE historic, maybe as part of the sunset4 WG work.
>
> I once suggested to increase the HE timers to make broken IPv6 a bit more
> noticeable without breaking stuff completely. In the cases where the server
> is broken (I have seen insane AAAA records) it might be slightly less
> pleasant for the user, but suddenly there is a tangible incentive for the
> server to get fixed. "Unfortunately" the implementation of HE is on the
> user's side and the software developer's main goal is to provide a good
> user experience.
>
> But yeah, HE is hiding brokenness. On one hand this is a good thing
> because it makes people less afraid of deploying IPv6 because the "risk" is
> lower. On the other hand that lower risk also means that problems don't get
> solved. My guess is that when more and more NAT64 networks get deployed,
> and HE doesn't help anymore, the brokenness will get fixed.
>

My experience is that when clients see failure due to broken severs, nat64
based solutions get rolled back or shelved completely

After all, that website with the bad aaaa works on my DS competition's
network and my ipv4 only  competition's network.

HE has created a situation where ipv6-only must be perfect (impossible)
while ipv4 and ipv6 have a nonzero acceptable error budget.

Note, 464xlat is effectively DS in this example and can tolerate
misconfigured ipv6

---

From: David Schinazi <[email-masked]>
Date: Wed, 05 Apr 2017 21:28:40 -0700

Hi Jordi,

I think error reporting is an interesting idea.

We're proposing PvD as a way for the network to give the device information, so that could be a good tool here:
https://tools.ietf.org/html/draft-bruneau-intarea-provisioning-domains <https://tools.ietf.org/html/draft-bruneau-intarea-provisioning-domains>

We'd have to flesh out what the device sends and ensure that it doesn't negatively impact users' privacy.

I think it might be worth writing a draft and discussing it with the community in Prague.

Thanks,
David

> On Apr 3, 2017, at 15:22, JORDI PALET MARTINEZ <[email-masked]> wrote:
> 
> Hi David,
>