The Business Case for IPv6-Only Enterprise
Introduction
IPv6 has been my day job (and technology muse for well over a decade now. And while I’m pleased to have played any role at all in its global deployment, there’s much work that remains — particularly among enterprise networks where IPv6 deployment continues to lag behind service providers.
Previous entries in this blog series examined positive business cases for IPv6 through various contexts (e.g., service provider vs. enterprise, technological maturity, marketing). And within these contexts, IPv6 deployment offers various potential benefits (e.g., scale, business continuity, operational efficiencies, performance, and the messaging of competitive advantage).
But given the persistently slow rate of IPv6 deployment among enterprise networks, one or more compelling business cases for the technology are clearly still needed. And while earlier business cases for enterprise IPv6 have mostly focused on a dual-stack approach — i.e., IPv6 “adoption” (see below) — this article will instead identify some potential elements of a business case for enterprise IPv6 deployment based on an IPv6-only approach.
“IPv6 Adoption”
IPv6 adoption is a phrase I use reflexively and have for nearly the entire time I’ve been working with IPv6. At my first job as an IPv6 evangelist for a vendor whose customer base was primarily within the enterprise market, I wanted to dispel as much as I could any FUD [fear, uncertainty, and doubt] around incorporating IPv6 into existing IPv4 production networks. From a technical standpoint, this meant advocating for the use of the least complex IPv6 transition mechanism available. In other words, dual-stack. (More on that in a moment.)
The mantra among the IPv6 wizards of the time was “dual-stack where you can and tunnel where you must.” The earlier approach of tunneling was required where much of the network didn’t support IPv6 at all. But by the time I got into the IPv6 game there was enough router and switch and desktop and server support to make dual-stack not only viable but the easiest way to deliberately deploy and manage IPv6 (while also assuming the least risk to the existing IPv4 production network).
As a result, a bit of persnickety rhetoric seemed in order. For risk-averse enterprise network folk, any so-called IPv6 transition would likely be a non-starter. That phrase could suggest a mutually exclusive move from IPv4-only to IPv6-only, with all that might entail in terms of complexity, downtime, resume-generating events, etc. And so, enter the phrase “IPv6 adoption,” as in, “You’re not turning IPv4 off and won’t be for a long, long time. You’re only deliberately adding IPv6 to the network and learning to manage it effectively for that eventual transition.” Or, to put it in Dr. Frankenstein’s monster’s terms: Transition, bad! Adoption, good!
The Latent Costs of Dual-Stack
So, let’s imagine that you’re one of those lucky enterprises that was persuaded to “adopt” IPv6 (like you might adopt a cute puppy or kitten, aww!) and deploy it using a dual-stack approach. Now that you’ve been running it a while, you’ve likely learned a few things along the way:
- It was relatively easy and safe to deploy. In fact, you discovered it was already running by default on your desktops, mobile devices, and servers. And it was relatively easy to enable it on your routers, switches, and firewalls.
- As a result of deploying and managing IPv6, you’ve gained enough operational and protocol knowledge that the transition to IPv6-only seems, if not entirely less potentially disruptive and scary, then at least feasible on a timeline that doesn’t extend beyond your retirement.
- Running two network protocols is more work. Sure, “a packet delivered over IPv6 is one that didn’t need to be delivered over IPv4” might sound clever and be technically true, but you still had to make sure all the architecture and configuration bits were in place for both routed protocols to make that possible.
- You have realized there are still gaps in feature parity with IPv4 for some of the products you have in use. They could be specific security solutions, third-party applications, or cloud/SaaS [Software as a Service] solutions that have no (or only partial) IPv6 support.
These last two points suggest that some significant number of additional person-hours would have to be directed toward maintaining a dual-stack environment, raising operational expenditures. Additional costs are incurred discovering, identifying, and documenting where gaps exist.
Something else you might have noticed running dual-stack is that you must configure IPv4 everywhere you configure IPv6. That means you still need a supply of IPv4 to grow (or possibly reconfigure and renumber) the network. And while IPv6 addresses are virtually free, IPv4 addresses are not (even private IPv4, as we’ll discuss below). Prices for publicly routable IPv4 addresses remain high (in large part because cloud service providers have been gobbling them up as quickly as they can).
Enterprise networks generally don’t need an abundance of public IPv4, but even private IPv4 carries its own costs. The ubiquitous use and resulting exhaustion of RFC 1918 addresses in large organizations means that overlapping prefixes and duplicate addresses are a commonplace risk. (The use of 100.64.0.0/10 address range defined in RFC 6598 provided network operators additional private addressing and some added relief, however temporary.) Such address overlaps mean that the necessary use of NAT and/or renumbering are required to maintain and grow the network. The many liabilities and costs of NAT in general deserve their own article. But where NAT is used to handle overlapping private IPv4 prefixes, the result is architectural brittleness. Such brittleness makes the use of NAT for this purpose a devil’s bargain, one where getting the network running today comes at a future cost of network design flexibility.
But even this accrual of crippling technical debt is often preferable to the costly and risky nightmare of renumbering altogether. A looming enterprise-wide renumbering project is incentive enough for some network engineers who’ve experienced such a challenge in the past to change jobs instead. Even successful renumbering with IPv4 is still just changing deck chairs on the IPv4 Titanic. IPv4 renumbering simply to maintain the status quo is such a huge expenditure of time and resources with many technical risks that transitioning once to IPv6 makes more sense.
It’s fair to say that these problems with private IPv4 exist independently of IPv6. But deploying IPv6 using dual-stack doesn’t eliminate them or reduce the additional operational costs they create. As a result, a reasonable business case can be initiated based principally on avoidance of these dual-stack associated costs. And avoidance of dual-stack costs requires increased deployment of IPv6-only.
It may be illuminating to examine the situation where the business case for IPv6-only comes in the form of a mandate. That is the situation that all enterprise networks run by U.S. federal agencies are in. This situation is in fact nothing new to them: Federal IPv6 mandates date back to at least 2005. And, arguably, such mandates have driven much progress in improvement of IPv6 product support and operational practice. The vendor’s upgrade path of the router or switch or firewall that provides robust IPv6 support today began with not a little prodding from a mandate nearly two decades old.
Of course, at the time of their publication, such mandates are often considered burdensome (and characterized as unfunded) by IT management and staff. The latest federal mandate, M-21-07 “Completing the Transition to Internet Protocol Version 6 (IPv6),” issued in November 2020, is perhaps no exception. Among its other requirements, it establishes an aggressive timeline for agency networks to transition to IPv6-only: 20% of IPv6-enabled assets by the end of 2023; 50% by 2024; and 80% by 2025.
The mandate states: “OMB previously issued policy discussing the expectation for agencies to run dual stack (IPv4 and IPv6) into the foreseeable future; however, in recent years it has become clear that this approach is overly complex to maintain and unnecessary. As a result, standards bodies and leading technology companies began migrating toward IPv6-only deployments, thereby eliminating complexity, operational cost, and threat vectors associated with operating two network protocols.”
In other words, dual-stack networks add additional IT complexities and costs and, most critically, the transition to an IPv6-only network provides an opportunity to eliminate some or all of these. By identifying those costs along with the IPv6-only architectures and configurations that reduce or eliminate them, the business case for an IPv6-only network emerges. It is independent of any mandate and should prove widely applicable to many corporate enterprise networks.
As it happens, federal agencies have, in some cases, already made substantial progress in meeting the IPv6-only mandate. The strategies and associated architectures and configurations they are using to do so offer lessons for private enterprises on how to operationalize the business case for IPv6-only.
NAT64/DNS64 (or is it DNS64/NAT64?)
NAT has long been a dirty word (or is that a dirty acronym?) among the IPv6 cognoscenti due to its manifold deficiencies. Some of these deficiencies are arguably more ideological, such as the way NAT breaks the originally intended end-to-end model of the Internet. Other objections to NAT relate to its more hidden costs and technical debts mentioned above — e.g., the brittleness of network designs and configurations that rely on NAT (and session state) to permit use of duplicate and overlapping address space.
These deficiencies have been largely obscured for most enterprise network and IT folks, who instead often choose to focus on what they perceive as NAT’s virtues. First among these is the deceptively cheap extension of the value of limited IPv4 resources. From an enterprise perspective, this benefit has been undeniable, extending the useful life of IPv4 long past its rundown and exhaustion. Other perceived benefits are “security through obscurity,” or the ill-informed belief that internal private address ranges are less detectable to malefactors.
But whatever NAT’s historical deficiencies, enterprise network engineers are currently faced with the reality that a significant amount of content, many services, and many applications are (and will stubbornly remain) available over IPv4-only. It is this situation that compels the application of a specific variety of NAT in the form of NAT64. Combined with its fraternal technology, DNS64, NAT64 provides connectivity for hosts in an IPv6-only network of virtually any size (as has been proven by mobile providers’ successful large-scale use of it with IPv6-only mobile handsets) to any IPv4-only resource.
There are of course other proven technologies to make IPv4 resources available over IPv6, such as application layer gateways (ALGs) or server load balancers (SLBs). But these typically provide an isolated IPv6 front-end for some limited set of IPv4 resources and do not scale as well or as easily as NAT64/DNS64. Another IPv6-only architecture and configuration that is nearing maturity takes advantage of recent host OS implementations of CLAT — the customer-side translator component of the 464XLAT architecture preferred by large mobile service providers to enable IPv6-only handsets.
Where to Start Deploying IPv6-Only
Organizations that find the business case outlined above compelling have some options as to where to begin deployment and testing of IPv6-only. In general, areas of the network that are more isolated or self-contained may reduce the risk to existing network services and operations — especially where those areas are to be newly provisioned (i.e., “greenfield”) or more frequently reprovisioned. Such environments may include:
- End-user wireless (especially guest networks)
- Data centers
- Out-of-band (OOB) or management overlay networks
- Public or Hybrid Cloud and SaaS where IPv6-only support exists
Each of these environments, when provisioned and deployed as IPv6-only, introduce specific design and operational challenges that perhaps all deserve separate articles dedicated to them. But whatever technical challenges they may introduce will, by design, be unique to IPv6. And their deployment will ultimately retire the costs of providing and operating IPv4. And, if such deployment can be accomplished during the window when public IPv4 addresses still have market value, it might be possible for enterprises with these resources to sell them for profit (perhaps offsetting some or all of the costs associated with transitioning to IPv6-only).
Conclusion
In closing, it should be acknowledged that enterprise networks continue to make progress in deploying IPv6. The demonstrated maturity of the protocol itself and the expanding operational footprint within enterprises demonstrate a virtuous cycle that should inspire confidence to deploy IPv6 among those enterprises still not yet deliberately deploying and managing IPv6. Enterprises that are already running IPv6 are likely aware of some of the IPv4 and dual-stack costs identified in this article (especially those enterprises that have made significant strides toward IPv6-only, such as Facebook/Meta and LinkedIn). In either instance, the business case for enterprise IPv6-only should be regularly assessed and its considerations included in all IT network evaluation and planning. The IPv6-only enterprise network will ultimately prove more scalable, manageable, and cost-effective.
Any views, positions, statements, or opinions of a guest blog post are those of the author alone and do not represent those of ARIN. ARIN does not guarantee the accuracy, completeness, or validity of any claims or statements, nor shall ARIN be liable for any representations, omissions, or errors contained in a guest blog post.
Recent blogs categorized under: IPv6
GET THE LATEST!
Sign up to receive the latest news about ARIN and the most pressing issues facing the Internet community.
SIGN ME UP →Blog Categories
IPv6 • Business Case for IPv6 • Internet Governance • Public Policy • Elections • ARIN Bits • Fellowship Program • Grant Program • RPKI • Caribbean • Outreach • Training • Updates • IPv4 • Security • Data Accuracy • Tips • Customer Feedback • IRR
