Re: [DNSOP] [v6ops] New Version Notification for draft-v6ops-xie-network-happyeyeballs-00.txt

Hi Barbara,

In my experience, there are two ways IPv6 can be broken:
1) ICMPv6 being filtered, so PMTUD doesn't work.
2) IPv6 deployment issues (including having AAAA records with no or bad IPv6 connectivity).

HE only helps for 2).

But 2 can be caused in different points between the source and destination, and in most of the cases is bad transit/peering more often than the LANs or the ISP deploying IPv6 badly in its own network.

What is missing is that, unfortunately, many folks don't do the same level of monitoring on their IPv6 networks than IPv4 ones, or if the destination has AAAA, but they don't have IPv6 enabled, of course, they aren’t monitoring at all a non-existing IPv6 network.

Also, if the problem is caused by 1, is the ISP deploying IPv6, then one that need to get some kind of alert from the customers about failing end-sites, and contact them or their transits ...

At the end they need to be able to cooperate resolving the problem.

There is an example about this. I've detected several years ago that 1&1 deploys IPv6 to their customers, but even if I tried personally contacting them they did nothing. I kept insisting for 3 years, but I already give up.

This means that thousands of web site with IPv6 aren't reachable for many customers. Of course, because in this case is due to 1), you can't reach those web sites neither with IPv6 or IPv4 (unless you manually disable IPv6 in the browser or OS).

Regards,
Jordi

-----Mensaje original-----
De: v6ops <v6ops-bounces@ietf.org> en nombre de "STARK, BARBARA H" <bs7652@att.com>
Fecha: miércoles, 26 de septiembre de 2018, 10:45
Para: 'Tony Finch' <dot@dotat.at>, Gert Doering <gert@space.net>
CC: dnsop <dnsop@ietf.org>, "v6ops@ietf.org" <v6ops@ietf.org>
Asunto: Re: [v6ops] [DNSOP] New Version Notification for draft-v6ops-xie-network-happyeyeballs-00.txt

    > The point of happy eyeballs is to work around crappy or broken networks,

    That's my recollection, too. And I'm really struggling to figure out which are the broken IPv6 networks NHE is trying to work around. The possible networks are: LAN, ISP/access, core/transit, and destination. I'm not aware of issues with core/transit networks. I'm also not aware of major issues with IPv6 broken at the destination (authoritative DNS servers supplying AAAA records, but those IPv6 addresses aren't actually reachable over the Internet or have incredibly slow IPv6 connectivity to the Internet).

    My recollection is that the brokenness being worked around was primarily caused by non-functioning IPv6 connections that were being advertised to hosts, were provided AAAA addresses during DNS resolution (over IPv4), but didn't have actual IPv6 connectivity to The Internet. Teredo and 6to4 in CE routers and host OSs were primary causes of the problem, exacerbated by DNS resolvers (sitting on IPv4-only networks) providing AAAA records to DNS queries over IPv4. The destination network was *not* the source of the broken IPv6. The problem was very, very local. HE wasn't in response to minor performance differentials between IPv4 and IPv6 (to pick the one that worked better). It was about not waiting an entire 60 seconds (or more) for a 100% broken advertised IPv6 connection to fail before using IPv4. 

    Some questions I have are:
    Why would an ISP choose to deploy partial or broken IPv6 + NHE, rather than properly functioning IPv6? I would think we should be recommending deploying properly functioning IPv6 rather than broken IPv6 + NHE. I'm not aware of a compelling reason at this stage of the game for non-IPv6 or partial-IPv6 ISPs to be providing AAAA to DNS queries over IPv4. Not providing AAAA over IPv4 DNS in this case is much easier than the proposed NHE.

    As for CDN statements made in this thread: CDNs are in the business of optimizing connections to their content. HE isn't about optimizing connections -- it's about more quickly reacting to the likelihood of outright brokenness. But it sounds like NHE *is* about optimizing (where IPv6 isn't broken, but is just really slow)? I'm a bit confused about this.

    I've done various IPv4/IPv6 latency tests from inside my home, over time. 
    Back when I had an ISP that was experimenting with IPv6 by having a single 6rd BR in the center of the US and that ISP was having other "we don't know what we're doing" issues, the IPv6 and general IP-connectivity performance was pretty abysmal. Now that I have an ISP (for the past 6 years) that has deployed a rock solid IPv6 solution (and I successfully got all the Teredo, 6to4, and ISATAP disabled on every device in my home), I have no problem. Which suggests IPv6 issues related to poor IPv6 deployments in destination networks isn't an issue for me. If it's an issue elsewhere in the world, please provide statistics -- I haven't seen any statistics presented by proponents of NHE related to the severity of whichever problem they're trying to solve. My experience suggests that ISPs who deploy IPv6 properly have no need for NHE.

    It really sounds like the main thing NHE is trying to "solve" is "I'm an ISP who wants to deploy bad, partial, or broken IPv6 and need something that will keep my users from suffering too horribly from my ineptitude." I'm not sure that's a compelling reason for an RFC. I also question whether such inept ISPs would make use of NHE, even if it were available.
    Barbara

    _______________________________________________
    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 exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.