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

["STARK, BARBARA H" <[e-mail]>]

> 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