Top 5 Misperceptions about Enterprise IPv6 Deployment - #4
As we continue to work through my list of the Top 5 IPv6 Misconceptions, the No. 4 entry is what I call “taking the easy way out” when it comes to deploying IPv6 at your Internet edge.
We know what can happen to those who take the road that is perceived to be easier, cheaper and faster. In general, these words (in combination) are dangerous in IT as most of the time they actually mean that you did not build it with enough scale, availability, and security and with a thorough design, which then ends up making it harder, more expensive and slower. Not always, but often enough. We don’t want unneeded complexity and cost, but we can’t half-#%* it.
Here is what I often hear: “We are going to deploy a dedicated link or tunnel to our ISP for IPv6 and then just advertise AAAA records for our portal. If you come in on IPv6 you go this way, but it is best effort for us and we are not expecting much. Easy to do, cheap and we don’t have to get elaborate in the design”. This sounds like a genius move as it allows you to do the minimum, for free potentially, keeps your IPv6 traffic isolated from your real IPv4 traffic and if it dies, you did not really lose anything.
The problem is, that line of thinking is wrong on every point.
You have to understand the default mechanisms in place when a host – say an Internet-based client has both IPv4 and IPv6 enabled and functioning, like I do on my Comcast-provided IPv6 service. Now if you, the genius IT person, turns on IPv6 on your ISP link(s), either natively enabling IPv6 on your web servers or using stateful NAT64 to front-end them, and then you advertise a DNS record so I, your faithful customer, can reach your site, you had better not shortcut the IPv6 design. Why? Because by default, if I have a dual-stack connection, I have IPv4 and IPv6 addressing and name resolution and can get IPv6 resolution for your site. I will, by default, use IPv6 to reach you instead of IPv4.
Note: This experience can change depending on failures in any sequence of events in the IPv6 connectivity chain or you can adjust this behavior, but by default this is the way it works.
So, now, your awesome low-latency, high-speed, highly available, well-secured IPv4-based web service is now second fiddle to your crappy single-homed, barely functioning, latency/jitter/drop filled IPv6-enabled web service. By the way, to me your customer, IT’S THE SAME PORTAL only really horrendous now. I don’t call my ISP, I don’t call your ISP, I call you wondering why it takes me forever to get to a site that used to pop up in a blink of an eye.
Don’t confuse this with a host who has a dual stack connection, IPv6 dies (anywhere in the path) and the browser/app takes forever to recover before it drops you back to IPv4. These are different issues. That is an issue now being dealt with by the awesome work by Dan Wing and others with “Happy Eyeballs” which as-of now is available in Google Chrome and Firefox.
The real issue I am addressing in this blog is an IT shop doing the minimum while trying to get IPv6 enabled on their Internet-facing link either to make sure they have business continuity with those dual stack or IPv6-only hosts out there. You may not even have that noble of a cause and instead you are trying to get your leadership off your back because of this “IPv6 hype” thingy. You have to build out IPv6, whenever you are ready for it and for whatever reason, in a scalable, available and secure way just as you have with IPv4. Do it right or don’t do it at all.
