Imagine yourself in a future world where networked technology is fully integrated into our daily lives and self-driving cars are commonplace. Most networks are wireless and almost all enterprise corporate applications are cloud-based. IPv6 is now widely deployed across the Internet and in private networks, yet there are still traces of legacy IPv4.
For years you’ve been saying that IPv6 will never happen and you steadfastly lobbied to keep IPv6 from being deployed in your enterprise organization. You have successfully derailed any attempt to deploy IPv6 and you are proud of your “vintage” IPv4-only network. You are the last hold-out of a bygone generation of network engineers who are comforted by the warm blanket familiarity of IPv4.
At one point, your colleagues at other companies were also like-minded and preferred IPv4, but now their organizations have migrated to dual-protocol. You are dismayed by a few of your former colleagues who have become “defectors” and now fully embrace IPv6, operating IPv6-only networks. If only they had listened to your warnings about how IPv6 isn’t a perfect, effortless replacement for IPv4. Now, when you meet with vendors they are surprised at your IPv4-only network and curious about how you have maintained it for so long. When you meet other networkers you often find yourself reminiscing with them about IPv4 subnetting, secondary addresses, IGRP and RIPv2.
When it comes to assessing where your organization falls on the IPv6 adoption curve, it is clear that you are in the IPv6 laggards category.
Love NATs and Tunnels?
Most of your IPv4 traffic goes through multiple layers of NAT. You feel comfortable that NATs protect knowledge of your private IPv4 addresses from being “leaked” to the shady characters on the Internet. However, due to the scarcity of public IPv4 addresses, your upstream ISPs have deployed Carrier Grade NAT (CGN) and Large-Scale NAT (LSN) and there are now multiple layers of NAT between you and the Internet. You feel even more secure from Internet threats now that you are tucked behind these barriers.
However, you have given up on using a few applications because they are problematic when used in an IPv4-only network. Those products and applications now have functionality that prefers native IPv6 addresses for peer-to-peer communications and connectivity to cloud applications. But in your IPv4-only environment, they don’t work quite as well or maybe not at all. End-users often complain and enter support tickets, but you brush this aside and maintain your IPv4-only preference. If only they could appreciate the purity and hipness of the retro IPv4-only network they have the privilege of connecting to.
When it comes to your branch offices, they are using IPv4 even though those SD-WAN service providers offer dual-protocol connectivity by default. But you elected to choose the IPv4-only provisioning option. Because these service providers prefer to operate a single-protocol core network, their entire backbone is IPv6-only. Therefore, when they need to connect legacy IPv4-only sites, they tunnel the IPv4 packets across their IPv6-only networks to a CGN/LSN gateway. Thus, your branch traffic is tunneled through the service provider network and your employees often complain about the slowness of their applications and more frequent application connection resets.
You are frustrated at the multiple layers of NAT and tunnels, but you remain steadfast in your decision to boycott IPv6. After all, it’s just too complicated.
Protecting Networks from IPv6 is Hard Work
At one point you were dismayed to discover that there were actual IPv6 packets on your supposedly pristine IPv4 networks. All of the operating systems on the nodes on your networks were IPv6-enabled and preferred to use IPv6 whenever possible. These IPv6-enabled nodes were sending out ICMPv6 multicast packets on the network. They were sending out ICMPv6 Neighbor Solicitation (NS) messages to perform Duplicate Address Detection (DAD) for their self-assigned link-local FE80::/10 addresses. They were sending Router Solicitation (RS) messages when they booted up to try to contact their local IPv6 router. You tried to deploy Microsoft Group Policy Object (GPO) to disable IPv6 on nodes, but you realized that only worked on Microsoft OSs. You discovered that Microsoft tech support would give you flak when you called for support because you disabled IPv6. There were also Microsoft operating systems that were not domain-joined that didn’t receive that policy and you had to configure those for IPv4-only manually. This GPO didn’t work on any of your Linux-based systems or any of the other devices on your networks like printers, badge readers, video surveillance systems, building control systems, and the myriad of BYOD nodes that have infiltrated the enterprise.
You worked diligently to try to disable IPv6 as a protocol stack on all the nodes in your network. At one point you were spending 15 hours a week looking for IPv6 packets and identifying IPv6-enabled nodes by their MAC address. Then you would manually track down the associated switch port and patch panel prior to marching over to scold the user at their desk for daring to pollute your network with IPv6 (after, of course, you had unceremoniously disabled it on the offending device).
These IPv6-enabled nodes also attempted to tunnel IPv6 packets over your IPv4-only core network. You were constantly using a protocol analyzer to determine if there were any IPv6 packets encapsulated in IPv4 packets and tracking down those hosts to disable IPv6.
You occasionally pondered the exact moment eliminating IPv6 from your network became a full-time job, but still felt a jolt of pride when you realized how you had persevered in keeping IPv6 packets off your immaculate networks.
Hooray, You got a /8!
Decades ago, the price for a public IPv4 address on the transfer market was anywhere from $15 to $20. Years ago, that price rose to a peak close to $100 per address. However, at some point, organizations, that transitioned to using IPv6 more extensively while continuing to use some private IPv4 addresses internally, realized they could relinquish their legacy public IPv4 addresses. The prices for large blocks of public IPv4 addresses are finally very affordable and your organization was eventually able to pick up that /8 that you always wanted.
But the /8 that you just bought is not as usable as you thought. Because most service providers have been completely focused on IPv6, they may have forgotten to remove this /8 from their blocked prefixes lists. As a result, there could be portions of the Internet that your hand-me-down /8 wouldn’t reach. Even if the service providers removed their filters and allowed you to advertise your /8, you would find that many of the subnets are on old IPv4 “bad-reputation” block lists. Tracking down the owner of the block list would be difficult as no one at these companies remembers any more how to maintain those legacy IPv4 security measures. So while you are enjoying all this extra IPv4 address space and using /24s everywhere, it isn’t as easy as you hoped. But you console yourself with the thought that it’s still a better situation than having to deal with those crazy large IPv6 prefixes with their inexhaustible host addresses and complicated nibble boundaries.
What’s Next for You?
You often wondered what life would be like if you are the last one on your block to deploy IPv6. Now that you have preserved your IPv4-only network and successfully staved off any IPv6 you know what that feels like.
Now, most products come with IPv6 as the default protocol and you are not able to find products that operate in an IPv4-only environment. You are constantly scanning the supported RFCs on the product spec sheet for RFC 1918. It occurs to you that you’ve been buying a lot of gear on eBay lately and that folks from the accounting department are starting to give you suspicious looks in the hallway.
Every day it is getting harder and harder to maintain an IPv4-only network. You try to steady yourself and renew your resolve, but every once-in-a-while you are curious what it would be like if you just enabled IPv6 and joined in with everyone else. No time for that now, though: several more IPv6-enabled devices connected to the network in just the last hour. Meanwhile your sales managers still hound you about why their new cloud-based SaaS portal isn’t working consistently from the office network. Looks like you’ll have to eat lunch at your desk. Again.
This post originally appeared on Infoblox Community: https://community.infoblox.com/t5/IPv6-CoE-Blog/Life-as-an-IPv6-Technology-Laggard/ba-p/11989
