I had the pleasure to sit in Mark Townsley “Addressing Networking Challenges With Latest Innovations in IPv6” session at Cisco Live yesterday and – somewhat inevitably – there was a mention of Facebook having implemented an IPv6-only approach in their data centers (here’s a talk from Paul Saab/FB laying out details). So, with the “IPv6 Panel” looming, I started reflecting on “Why don’t we see this in our customer space?”. This post quickly summarizes some observations and thoughts.
From an abstract perspective, going with an IPv6-only approach in certain segments, combined with (NAT64 or SLB64) translators “in front of them”, could make quite some sense, namely when looking at mid-term OPEX (running single-stack instead of dual-stack). So how comes that we don’t see this in our customer environments?
I think there’s a quite simple answer: pursuing an “IPv6-only” strategy is based on two prerequisites:
- a (somewhat) homogeneous system/service landscape (which Facebook – somewhat – has, and which is one of the properties of parts of cable provider or telco infrastructures, too).
- a “concerted effort” approach where, at some given point of time, large parts of an infrastructure can be migrated to a different release/configuration at once (where “at once” can still be longer than “some hours”, but probably not “over a period of several weeks/months/even years”).
Realizing this it becomes clear why this is – from my expectation (I mean, I don’t have a crystal ball) – is not going to happen in large organizations from “traditional” industry sectors such as automotive, manufacturing, chemicals and the like:
- the “concerted effort” IPv6 migration simply does not happen there, due to the (political, organizational & technical) complexity and heterogeneity of those environments, combined with corporate silos and all the related typical ingredients of big corporations (and, tongue-in-cheek, who thinks about “mid-term OPEX savings” in shareholder-driven organizations anyway, right?). While at the same time IP(v4) is ubiquitous which in turn means: to replace (by a newer version) you’d either need a ubiquitous effort or you “slowly go through a period of co-existence”, which pretty accurately describes what we actually see happening (more on this in another post).
- as stated this either requires a mostly homogeneous system or service landscape, whereas these organizations have a [high] 5-digit number of “corporate applications” plus one outsourcing partner for “network services”, one for “the desktops”, another one operating the SIEM etc. When Mark stated in his session (iirc, I might have misunderstood sth here) “v6-only plus NAT64 in the data center is similar to NAT64 in mobile networks”, I was scratching my head: wait a second, doing v6-only plus NAT64 for unmanaged clients in a mobile network, with pretty much all of them doing “north-south traffic” (which in turn is 99% HTTP[S]), is very very different from migrating to v6-only in corporate data centers with lots of “east-west traffic” and all types of service dependencies (think monitoring, system management, logging, backup et.al. => all those must be v6-enabled [either v6-only or DS] once you connect to servers/segments running v6-only). Which then again would require a “concerted effort” which in turn… see above.
To summarize: I think there’s a reason why many organizations do not consider “v6-only” a feasible IPv6 migration strategy, but instead go with a slow transition approach, enabling IPv6 here and there, replacing components here+there etc.
If will happily discuss my perspective with you, so join the panel or just approach me directly (or leave a comment).
Have a great day everybody,
Enno