Making IPv6 Work for You

By Alan Skinner and David Ririe

IPv6 has been a long time coming, but it’s here and offers some enticing benefits. Cox has deployed IPv6 to over 3 million residential and business customers, and another 3 million managed STB devices. Our insights can help you get the most out of your IPv6 migration.

Review: IPv6 History and Timetable

Anyone who works in data networking will tell you that Internet Protocol version 6 (IPv6) has been long promised and little deployed, at least up until very recently. Despite being ratified in 1998 as RFC2460, IPv6 made very few inroads into service provider networks and even less into customer devices for many years. The tipping point for the cable industry came with widespread DOCSIS 3.0 adoption and the IPv6 support that it brought into headends, hubs, and subscriber homes. Broadband service providers have finally made substantial progress moving toward IPv6, with Comcast leading the charge.

The reasons for slow adoption of IPv6 are many, and have been covered at length elsewhere. In summary:

IPv6 is not backwards compatible with IPv4, and thus requires complicated and/or expensive transition technologies
New hardware (often) and new software (always) is required – without associated revenue generation to fund it
Until Internet Protocol version 4 (IPv4) is completely sunsetted, supporting IPv6 often means building and supporting a second, parallel network (typically with minimal if any incremental staff). This can be avoided in some cases, but more on that later.
The list goes on….

Despite these hurdles, the Internet’s IPv6 landscape is much less bleak today. Most of the large content providers (Netflix, Amazon, Google, YouTube, Yahoo, etc.) fully support native IPv6 today, and more are adding support all the time. 25.6% of the top 1000 web sites are IPv6-enabled as of October 2017. IPv6 traffic is a much larger percentage of the total, due to the aforementioned major content providers defaulting to IPv6. IPv4-only content is becoming the long tail – albeit a very long tail. Retail networking devices such as home routers and access points support IPv6 almost universally, even though customers don’t know it or care about it.

At Cox Communications, we began the planning and design for IPv6 in 2010 with an initial focus on infrastructure and backbone. The rollout of IPv6 support to residential and commercial data and video customers was completed in 2016. Enterprise IPv6 support across our HQ campus was completed in 2017. There were substantial gaps in progress during that span while we waited for vendor support to catch up with our plans, but providers who tackle this now should require much less time.

In April, Cox was among a select group of service providers to be recognized as “IPv6 Pioneers” by the North American IPv6 Task Force for subscriber adoption exceeding 20%. The accompanying summit included talks from IPv6 movers and shakers across North America. Of particular interest were experiments underway by Microsoft and Cisco to test “pure IPv6” facilities. While that is not yet on our roadmap for customer services, we do use IPv6 exclusively for some managed devices.

IPv6 as an Enabler

Why bother with IPv6 at all? The stock answers are a) it’s a better protocol with lots more address space, b) the Internet is going here sooner or later, and c) IPv4 address space is gone. We believe that those are all valid, but there are other important drivers that make IPv6 worth the effort.

Beyond the rationale of “bigger, better, newer,” here are five additional reasons to deploy IPv6.

Auto-configuration of IP addresses in IPv4 was crude and useful only in limited, LAN-specific applications. IPv6 auto-configuration is powerful and can ease IP management for high-volume devices where building DHCP pools might be tedious. One example would be simplifying the process of commissioning new remote PHY devices (RPDs) at scale.
If you do need to use DHCP, IPv6 subnets are sufficiently large that you only have to build them once and they last forever. Gone are the days of monitoring IP usage and supplementing exhausted subnets on a regular basis.
Goodbye, silos. Unless you like them, that is. IPv4 “private” space, defined by RFC1918, is limited in size and reachability. Use IPv6 instead, and a poller in one location (for example) could reach devices in any silo of traditionally re-used IPv4 private space that has migrated to IPv6.
NAT/PAT. Love it or hate it, a great deal of time and effort has gone into working around the problems introduced by network address translation (NAT). Living without NAT frees us from the hacks and workarounds required to handle services which span internal and external routing domains. With IPv6, it’s all just routing.
IPv6 is a clean slate. Instead of numerous, scattered IPv4 CIDR blocks, IPv6 prefixes and routes are much easier to aggregate. This simplifies the route tables, enables faster convergence, and can even help enable portability of reserved addresses for commercial customers that require them.

Still Contemplating, or Just Beginning, a Migration to IPv6? Read on…

IPv6 technology can seem overwhelming and we admit it is. A good analogy of the difficulty in pursuing this migration is similar in theory of pushing a rock uphill. But we know you can do it and we can pass along several key lessons learned that will help ensure a timely, highly available, low impact migration.

LESSON 1

This is the most important lesson and is listed first! The key to your success is to find a great project manager. Why? Because the list of tasks to knock out is long and spans most of the network and infrastructure. You must have in individual that you can rely on and trust to perform the tasks that at times can be difficult.

LESSON 2

Plan your IPv6 space in such a way that it is logical, repeatable, standardized, and convenient – even if that means it is – gasp! – inefficient. Break out of the IPv4 mindset of trying to scale every market, serving area, or network device “properly.” ARIN is more than happy to give you as much space as you need – just ask for it. Instead of right-sizing each deployment, choose one or two standard addressing designs and re-use them over and over for consistency.

LESSON 3

Audit, Audit, Audit! IPv6 issues can hide behind the cover of dual-stack, manifesting themselves only occasionally or seemingly at random. Finding patterns that lead to root cause is hard; auditing with probes and scripts is easier. Audit every endpoint, every configuration backup, every DHCPv6 subnet, even public message boards, looking for failures or inconsistencies.

LESSON 4

To the extent possible, avoid using dual-stack to mask deficient areas of the network or non-compliant devices. This results in a second parallel network which requires care and feeding. Better, switch to pure IPv6. For example, while customer premises equipment might require dual-stack, managed devices such as STBs may not. Run them in native v6 mode.

LESSON 5

Be specific with your vendors about what IPv6 functionality you plan to deploy. A generic “do you support IPv6?” will almost always result in a generic answer of “yes,” so be as clear as possible. Avoid relying on roadmaps or promises of future support “coming soon.” Fully baked IPv6 functionality should be table stakes in 2017.

Deploying IPv6 can seem like pushing a boulder up a hill. But by following these guidelines, you can get it done and your network will be better for it.

Alan Skinner
Systems Engineer at Cox Communications
alan.skinner@cox.com

Alan Skinner is 10-year veteran of Cable Access Engineering at Cox Communications. His current efforts center around remote PHY and CCAP video integration, but for the three years prior to that he served as technical lead for IPv6 implementation throughout the company. His responsibilities have also included the design and implementation of DSG and related STB technologies. Prior to joining Cox, Alan spent eight years in DOCSIS engineering at ARRIS and Cisco.

David Ririe

Sr. Director, Access Engineering
Cox Communications, Inc.
david.ririe@cox.com

David Ririe serves as a Senior Director in the Access Engineering group for Cox Communications in Atlanta, GA. He has worked in various engineering roles for Cox Communications starting as a Network Engineer in the Omaha, NE market 14 years ago. He has lead the team through a number of transitions and upgrades on both the DOCSIS and PON technology platforms in that time. He began his telecom career in the U.S. Air Force working on various communications and data networking platforms in the air and on the ground.

Credit: Shutterstock