Operationalizing IPv6: From Theoretical to Practical
In the period leading up to the year 2000, the definition of IPv6 was barely complete, with non-production, experimental academic applications abounding. This is not unlike how many new technologies begin their life cycle. What would happen over the next decade — the explosive adoption and growth of broadband, web-scalers, and the cloud — would unfortunately distract most would-be adopters of IPv6 from continuing their journeys. That is, of course, apart from a handful of commercial adopters who truly had no good alternatives to support growth.
Circa 2005, the cable industry assessed the situation and committed to ensuring IPv6 was deployable for production use, at scale and reliably. This went far beyond simply IPv6-enabling the token web server or desktop networks so a handful of end users could “surf” the web to view a dancing turtle (or not). 2005 marked the beginning of a period in which it was decided that:
- IPv6 support would be first class and production grade, and
- The use of IPv6 only would become a reality for select use cases.
In the early days, IPv6 support was not even second class. Heterogenous router implementations could not be configured to support common addressing to facilitate point-to-point connections. Access control lists (ACLs) had severe limitations that if left unaddressed introduced substantial risk to the stability of the device, the network, and, in turn, the customer experience. Sacrificing the customer experience was simply never an option, neither commercially nor technologically. Deploying unstable, new technologies would certainly apply a great deal of pressure to industries already facing extreme criticisms for “lacking customer service.” If IPv6 was at the root of customer impact, then it surely would have altered the protocol’s fate and the appetite for its future adoption.
Such was the dilemma for companies now depending on IPv6. This is when the real work began. Here we will explore the journey from theoretical to practical for IPv6 and attempt to facilitate understanding of what that truly involved at the time when there were really no concrete, large-scale deployments. Then, we’ll discuss how IPv6 was leveraged operationally to yield meaningful value commercially (to business owners) and experientially (to customers).
Scope, Magnitude, and Criticality
It is true, in the early days of IPv6 before and circa the year 2000, there was no true business case or motivator to initiate or fuel its adoption. Until the Internet and its ecosystem experienced unprecedented growth, the most fundamental motivations to consider IPv6 from a business point of view were:
- To buy or not to buy IPv4 addresses (at the time they were not expensive)
- To engineer around the limitations of IPv4
Those with the vision, will, and resources opted for the road less traveled — IPv6. It can be said that others, perhaps, took the easier path by deploying overlapping instances of IPv4 (public and private). The side effects of the latter would eventually come to function as a tax for those short-sighted decisions.
During this same time period:
- Bona fide deployments of IPv6 began to appear,
- IPv6 implementations were improving, and
- New areas requiring IPv6 support began to emerge and take shape.
Post 2005, but preceding highly visible deployments from the likes of the web-scale and cloud companies, large cable companies embarked on one of the most substantive firsts from an IPv6 deployment perspective — “IPv6 only” for cable modem management.
Let’s be crystal clear: For years leading up to this point, IPv4 addressing (public and private) had been used for internal management of cable modems, aka the life blood of every service that enters a cable subscriber’s home:
- Internet
- Voice
- Video
- Home Security
- Public Wi-Fi
The management interface for cable modems is reachable only over the operator’s internal network — or intranet — to manage the services to which a customer has subscribed. So, what’s the big deal? It is only for internal use, making it a perfect candidate for migration to IPv6 only, right? Theoretically this is accurate, but practically it becomes a challenge when factoring in all of these elements that would need to support IPv6 (only):
- Hundreds of makes and models of cable modems
- Several makes and models of cable modem termination systems (CMTS)
- A variety of makes and models of core routing equipment
- Hundreds of back office systems
The magnitude of the migration effort grew exponentially. Let us not forget that a cable modem’s management interface must be operational for all services to operate; if it disabled or impaired, it is safe to assume every service used by the customer could be as well. This cable modem use case would eventually be revisited with a new goal of making cable’s core video services IPv6-only. Similar challenges apply to IPv6-only video, except now the conditions were compounded by requiring:
- An IPv6-only managed cable modem
- Embedded within an IPv6-only video device
- Internet-originated content and content distribution networks (CDNs) to support IPv6
- Cloud infrastructure (public and private) that offers production caliber IPv6 support
For video services, some “new” additional complexities arise that require addressing originally introduced as a byproduct of IPv4 (or the lack of IPv6): differentiated services code point (DSCP) markings. IPv4’s lack of flexibility had borne several unintended “applications” or overloading of existing technologies like DSCP marking. One could argue Network Address Translations (NAT) is yet another popular byproduct.
This summary does not remotely do justice to the entirety of the complexities faced along the lengthy, productive, and successful IPv6 journey that resulted. The full accounting of these details is truly a subject for a book (perhaps multiple) outlining the memoirs of real IPv6 deployments. Hopefully, however, the context here sufficiently conveys the scope and magnitude of the work required to make IPv6 deployable, and the criticality of IPv6 working well for the delivery of services to consumers.
The above is a backdrop for the true focus of this post: the why.
Business Continuity and Growth
The best analogies I offer to lay people, friends, and family to describe my “job” and the IPv4-to-IPv6 transition involve the traditional phone system we all grew up with and the migration from seven- to 10-digit dialing and/or petroleum extraction with the expectation that one day electric vehicles will dominate and petroleum-based fuels will no longer be required.
Beyond technological altruism, the original interest in IPv6, for some adopters, was simply motivated by two factors:
- Scale, and
- Cost avoidance
Times have since changed, and that list of motivations now includes monetization. While the details of that topic are for another day, some light reference follows.
As introduced above, the interest in IPv6 in the earliest days of assessing how and why to deploy it centered around cost avoidance and scale. Once the free pool of IPv4 was depleted, there was no appetite from a business perspective to develop the habit of buying IPv4 addresses to support the growth of the business. IPv6, if applied properly, would allow the adopter to grow their business without the restrictions imposed by a finite resource (IPv4 addresses).
Today, these motivations have only intensified as the value of IPv4 addresses has increased dramatically. Approaching 2010, when no real market existed yet, the cost was roughly $10 per IPv4 address. In 2022, the cost was publicly cited at nearly $60 per IPv4 address — a staggering nearly 600% increase. Recent data suggests that the price per IPv4 continues to increase while supply is stagnant or decreasing. This growing value and scarcity of IPv4, driven by growing consumption, punctuates the importance of IPv6 and its adoption and leads up to the industry’s focus on leveraging IPv6 to increase the availability of IPv4 address supply.
Operational Efficiencies
Complementary to the excitement around the value of IPv4, and beyond the business and commercial impacts highlighted above, a multitude of substantive, day-to-day operational benefits are associated with the adoption of IPv6.
Operations and Change Management
In most networks, especially those spanning geographies where multiple types of services are offered, IPv4 imposes non-trivial limitations. For one, the default mode of operation is to attempt to deliver every “service” over a singular collapsed IPv4 infrastructure — trying to disambiguate service offerings without the span of address space to properly categorize them. Unlike IPv6, IPv4 does not afford users the proper means (or space) to differentiate types of services by IP prefixes or aggregates. This is not to say that IPv6 can’t be poorly deployed and yield the same result, but dedicated IPv6 prefixes per service per geography cleanly fuels deployment models that enable adopters to differentiate service types across geographies by IPv6 aggregates.
The concept of IPv6 service aggregates by geography also introduces substantial simplicity for capacity management. Many high-volume, high-growth organizations inevitably have segments or portions of their networks that require frequent capacity augmentation. Specific examples include:
- CMTSs that require additional IP addresses to ensure that new cable modems can register and come online
- Physical or virtual server networks that experience explosive growth where publicly-routable IPv4 connectivity is required
- Video environments where video devices consume large quantities of IP addresses
And yet, the simplest and most significant attribute of IPv6 — its vastness — is materially taken for granted and grossly overlooked as its most impactful feature. Anyone who has ever run a reasonably large network or infrastructure understands that:
- Change introduces variability, and
- Variability can introduce outages and, in turn, impact customers
Rhetorically speaking, is the remedy simply to not make changes? To not deploy upgrades? But, absent these critical activities, how can customers be expected to take advantage of new features or functionality, which are required to generate new revenue? IPv6 is not a universal silver bullet. However, in the case of frequent maintenance it can often minimize, if not alleviate, the need for some types of changes.
For example, imagine installing a /64 in a DHCPv6 pool for cable modem management and never having to add capacity. This in turn alleviates the need to introduce IGP changes, until, of course, the access layer element is decommissioned. Furthermore, with the use of a /64 of IPv6 address space, the aggregate announcement will never require any form of additional announcements that represent a super-net.
Deployment and Performance Impacts
On the topic of routing, imagine a scenario where most of the layer 3 management for infrastructure is over IPv6 only; perhaps IPv6 only is used to deliver a high-volume video service. This will leave IPv4 routes in the table only for services that strictly require IPv4 connectivity. Today this is most often oriented around heterogeneous connectivity of the Internet. There are at least two material byproducts in such environments:
- A decrease in the routing table utilization (typically internal), which must not be underestimated, and
- The genesis of network infrastructure that can truly be deployed for IPv6-only traffic
Those experienced with capital and operational expenditure responsibility will recognize that the cost of specialized hardware for and the performance trade-offs of routing table size reduction are material to the economics of operating large-scale networks. Again, using IPv6 only where possible minimizes change, reduces resource utilization, increases efficiency, and, in the end, increases performance. Plus, for Internet-facing content and services, IPv6 only interconnects with third-party networks (peers) and enables the use of commodity hardware that is less expensive (per port) and is optimized for performance around a single IP version (IPv6) while maintaining the simplicity associated with many fewer features. Of course, certain prerequisites must be met before being able to take advantage of IPv6 only in this manner. First and foremost, it requires a first-class IPv6 implementation that supports the ability to operate and manage mission critical infrastructure, end-to-end, using IPv6 only.
Fewer features, while seemingly irrelevant, in fact reduces complexity and thus simplifies operations, deployment, and development (attractive to vendors). The end result is not only a positive impact on performance but also a substantive increase in reliability and stability — which positively impacts the customer experience.
Mergers and Acquisitions
The tactical side effects of larger corporate mergers and acquisitions (M&A) activity seldom, if ever, make the front page or reach the top of mind. However, when organizations of any size merge or are acquired, the pursuit of technical and financial synergies quickly follows. This is particularly true when the organizations merging or attempting to merge have a large-scale network at the heart of their business (think web scale, social media, streaming, and broadband networks).
In the not-too-distant past, IPv6 would have been a key element in enabling a sizable merger affecting three of North America’s largest broadband networks. Let’s take a look at the highlights of how IPv6 was used to lay the groundwork for what would have been one of the largest network mergers in history, with an estimated value of more than US$45 billion.
Two of the three networks chose to use multiple instances of overlapping RFC1918 IPv4 address space within their own networks. Much of this overlap would have exacerbated complexity since the same RFC1918 IPv4 address space was in use across all three networks. The use of IPv6 as a single (flat) topology would have enabled clean migration paths when network integration began, without the need for costly, time-consuming IPv4 renumbering efforts. Any renumbering to occur would have been from IPv4 (public or private) to IPv6. Lastly, publicly routable IPv4 resources to the tune of three /8 IPv4 blocks would have been used to subsidize the IPv4 resource requirements spanning three massive broadband networks.
Admittedly, M&A activity of this magnitude does not occur all that frequently. While some of those highlights may seem exclusive to large network infrastructures, the same fundamental principles apply to networks of practically any size.
Continuing Progress Through Collaboration
The operationalization of IPv6 has come a long way since the turn of the millennium. The once-homogenous use of IPv6 for simple, novel desktop use has been catapulted forward to diverse, business-impacting production deployments. So much progress has been made, but there is still a great deal of work to be done to ensure that IPv6 represents the majority of Internet traffic around the globe and beyond.
Most estimates from the likes of APNIC and RIPE suggest this milestone may be 10 or more years away. The reality of the current situation is even that time frame is not guaranteed without concerted, industry-wide collaboration — collaboration oriented around deployment scenarios that produce true business value. IPv6 has reached many substantive milestones of varying magnitudes over the past 20 years, and there is clearly room for a few more. While a global tipping point for IPv6 may remain somewhat distant, the cost of IPv4 for some (or its value for others) continues to increase. In uncertain times on so many other fronts, the deployment of IPv6 can help networks of all shapes and sizes introduce a reliable foundation for growth with regards to IP addressing.
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
Grant Program • Tips • RPKI • Updates • IPv6 • Business Case for IPv6 • Internet Governance • Public Policy • Elections • ARIN Bits • Fellowship Program • Caribbean • Outreach • Training • IPv4 • Security • Data Accuracy • Customer Feedback • IRR
