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-boun...@ietf.org> en nombre de "STARK, BARBARA H"
<bs7...@att.com>
Fecha: miércoles, 26 de septiembre de 2018, 10:45
Para: 'Tony Finch' <d...@dotat.at>, Gert Doering <g...@space.net>
CC: dnsop <dnsop@ietf.org>, "v6...@ietf.org" <v6...@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
v6...@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.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
