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

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 <jordi.palet@consulintel.es> wrote:
> 
> 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 <v6ops-bounces@ietf.org> en nombre de David Schinazi <dschinazi@apple.com>
> Responder a: <dschinazi@apple.com>
> Fecha: lunes, 3 de abril de 2017, 23:45
> Para: Ca By <cb.list6@gmail.com>
> CC: IPv6 Ops WG <v6ops@ietf.org>
> Asunto: Re: [v6ops] draft-pauly-v6ops-happy-eyeballs-update-01
> 
>    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 <cb.list6@gmail.com> 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/
> 
>    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
>    v6ops@ietf.org
>    https://www.ietf.org/mailman/listinfo/v6ops
> 
> 
> 
> 
> 
> 
>    _______________________________________________
>    v6ops mailing list
>    v6ops@ietf.org
>    https://www.ietf.org/mailman/listinfo/v6ops
> 
> 
> 
> 
> **********************************************
> 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.
> 
> 
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops