No IPv6 by design to increase reliability...
I was having a debate with someone on this. Take a critical web site, say one where you want 100% global uptime, no potential issues with end users having connectivity or routing issues getting to your IP. Would it be advantageous to purposely not support a AAAA record in DNS and disable IPv6, only exist on IPv4? My argument against this was "Broken IPv6 Connectivity" doesn't really occur anymore, also, almost all browsers and OS IP stacks implement Happy Eyeballs algorithm where both v4 and v6 are attempted, so if v6 dies it will try v4. I would also argue that lack of IPv6 technically makes the site unreachable from native IPv6 clients, and in the event of an IPv4 outage, connectivity might still remain on IPv6 if the site had an IPv6 address (I've experienced scenarios with a bad IPv4 BGP session, but the IPv6 session remained up and transiting traffic...) Thoughts? -John
Broken IPv6 connectivity happens all the time, sometimes for weeks, before some folks seem to notice. I could understand why one could take the stance that IPv4 only is less problematic (and therefore more available) than dual stack. Overall, it might depend on your application and the happy eyeballs tech built (or not built) into it. John Von Essen wrote on 1/17/2019 1:45 PM:
I was having a debate with someone on this. Take a critical web site, say one where you want 100% global uptime, no potential issues with end users having connectivity or routing issues getting to your IP. Would it be advantageous to purposely not support a AAAA record in DNS and disable IPv6, only exist on IPv4?
My argument against this was "Broken IPv6 Connectivity" doesn't really occur anymore, also, almost all browsers and OS IP stacks implement Happy Eyeballs algorithm where both v4 and v6 are attempted, so if v6 dies it will try v4. I would also argue that lack of IPv6 technically makes the site unreachable from native IPv6 clients, and in the event of an IPv4 outage, connectivity might still remain on IPv6 if the site had an IPv6 address (I've experienced scenarios with a bad IPv4 BGP session, but the IPv6 session remained up and transiting traffic...)
Thoughts?
-John
I think you’ve got it basically right. Over time, the number of v6 only clients will continue to grow. (It’s infinitessimally small right now) It should, however, also be noted that there are a larger and growing number of v6 capable clients with increasingly degraded v4 capabilities (v6 only handsets with nat64 or 464xlat, cgn, etc.) which are also negatively impacted by the decision not to support v6 in the scenario described. If v6 were such a problem as described, I think it wouldn’t be so readily embraced by facebook, google, Comcast, Netflix, etc. Owen
On Jan 17, 2019, at 11:45, John Von Essen <john@essenz.com> wrote:
I was having a debate with someone on this. Take a critical web site, say one where you want 100% global uptime, no potential issues with end users having connectivity or routing issues getting to your IP. Would it be advantageous to purposely not support a AAAA record in DNS and disable IPv6, only exist on IPv4?
My argument against this was "Broken IPv6 Connectivity" doesn't really occur anymore, also, almost all browsers and OS IP stacks implement Happy Eyeballs algorithm where both v4 and v6 are attempted, so if v6 dies it will try v4. I would also argue that lack of IPv6 technically makes the site unreachable from native IPv6 clients, and in the event of an IPv4 outage, connectivity might still remain on IPv6 if the site had an IPv6 address (I've experienced scenarios with a bad IPv4 BGP session, but the IPv6 session remained up and transiting traffic...)
Thoughts?
-John
In article <39BFCD05-62CB-46C7-83E6-0CC25D393137@delong.com> you write:
If v6 were such a problem as described, I think it wouldn’t be so readily embraced by facebook, google, Comcast, Netflix, etc.
Their priorities are probably not your priorities. For example, I expect they want to be able to distinguish among the devices behind a v4 NAT so they can segment and market more precisely. -- Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly
On Jan 17, 2019, at 12:40 PM, John Levine <johnl@iecc.com> wrote:
In article <39BFCD05-62CB-46C7-83E6-0CC25D393137@delong.com> you write:
If v6 were such a problem as described, I think it wouldn’t be so readily embraced by facebook, google, Comcast, Netflix, etc.
Their priorities are probably not your priorities. For example, I expect they want to be able to distinguish among the devices behind a v4 NAT so they can segment and market more precisely.
That’s already relatively easy to do through other mechanisms (cookies anyone). Having had in depth conversations with the people running those networks, I can assure you that a number of their priorities are in line with mine: a stable, functional internet that can accommodate existing users and scale for a workable future. That simply isn’t possible in IPv4. It hasn’t been for years. IPv4 continues to degrade. Eventually it will reach a point where the problems are so obvious that they can no longer be ignored by the laggards that still haven’t implemented IPv6. One of several things will eventually resolve that issue: 1. The remaining content providers failing to support IPv6 become sufficiently insignificant that ISPs turning off IPv4 will consider the revenue lost by losing customers that care to be significantly less than the cost to continue supporting IPv4 for those customers. 2. Enough eyeball ISPs will begin charging a premium for IPv4 services to cover the growing cost of maintaining this backwards compatibility that it drives a user revolt against the sites described in the previous paragraph, thus accelerating situation 1 above. 3. A sufficient critical mass of eyeballs are connected to IPv6 only networks that don’t offer IPv4 backwards compatibility that the content providers that fail to support them recognize significant revenue drop. I suspect that the most likely scenario will be 2 accelerating 1, but it could play out in any of the above ways. Bottom line is that anyone still supporting IPv4 only is basically running on a toxic-polluter business model depending on everyone else to cover the growing costs of the mess they are making of the current internet. Owen
On Thu, Jan 17, 2019 at 11:46 AM John Von Essen <john@essenz.com> wrote:
I was having a debate with someone on this. Take a critical web site, say one where you want 100% global uptime, no potential issues with end users having connectivity or routing issues getting to your IP. Would it be advantageous to purposely not support a AAAA record in DNS and disable IPv6, only exist on IPv4?
No
My argument against this was "Broken IPv6 Connectivity" doesn't really occur anymore, also, almost all browsers and OS IP stacks implement Happy Eyeballs algorithm where both v4 and v6 are attempted, so if v6 dies it will try v4. I would also argue that lack of IPv6 technically makes the site unreachable from native IPv6 clients, and in the event of an IPv4 outage, connectivity might still remain on IPv6 if the site had an IPv6 address (I've experienced scenarios with a bad IPv4 BGP session, but the IPv6 session remained up and transiting traffic...)
Thoughts?
Correct, the broken ipv6 thing is super rare and those rare event are solved with Happy eyeballs. There are well over 100 million ipv6-only Android and iOS devices in north america alone. Failing to deploy ipv6 on the website means they get to share capacity on a CGN, ip repution issues, and indirection to reach the CGN. FB, Google, Netflix, Akamai and other push ipv6 because it is good for business, the business of running money making content.
-John
It is an interesting question to ponder. It is true that IPv6 tends to be somewhat more problematic than IPv4, but these days the incidents where IPv6 becomes unavailable or has issues are rare. BTW I have had recently an issue where I had IPv4 reachability problems while IPv6 worked perfectly. regards, -Carlos On 17 Jan 2019, at 16:45, John Von Essen wrote:
I was having a debate with someone on this. Take a critical web site, say one where you want 100% global uptime, no potential issues with end users having connectivity or routing issues getting to your IP. Would it be advantageous to purposely not support a AAAA record in DNS and disable IPv6, only exist on IPv4?
My argument against this was "Broken IPv6 Connectivity" doesn't really occur anymore, also, almost all browsers and OS IP stacks implement Happy Eyeballs algorithm where both v4 and v6 are attempted, so if v6 dies it will try v4. I would also argue that lack of IPv6 technically makes the site unreachable from native IPv6 clients, and in the event of an IPv4 outage, connectivity might still remain on IPv6 if the site had an IPv6 address (I've experienced scenarios with a bad IPv4 BGP session, but the IPv6 session remained up and transiting traffic...)
Thoughts?
-John
participants (6)
-
Blake Hudson -
Ca By -
Carlos M. Martinez -
John Levine -
John Von Essen -
Owen DeLong