There seem to be some “issues” with enterprise’s relationship with IPv6. It isn’t clear if they just aren’t getting along or if enterprise is in a monogamous exclusive relationship with IPv4 and unwilling to explore the dual-protocol swingers’ lifestyle. Maybe conservative enterprises are “IPv6-curious” and fear reprisals from their peer-group if they exhibit an excessively-promiscuous network architecture. There are no taboos surrounding IPv6, but there could be a perception that “all the cool kids are doing it.”
We’ve Got Plenty of IPv4 Addresses #NotMyProblem
Enterprises often utter the words, “I have plenty of IPv4 addresses, so I don’t need IPv6”. How many times have you heard this argument? Those large enterprises, federal organizations, universities, etc., who were bequeathed large public IPv4 address resources often don’t consider the other-half of the relationship. From their perspective, it’s not them that’s the problem. IPv6 is an issue for others to tackle. Those types of organizations sometimes have enough public IPv4 addresses that they can use them internally and on their perimeter networks. While they have a plentiful supply of public IPv4 addresses, they don’t recognize the rest of the Internet population’s lack of public IPv4 addresses. Some companies consider themselves lucky if they have a /24 for their perimeter systems and make use of Network Address Translation (NAT) and proxies. But other people on the Internet don’t even have a single non-dynamic public IPv4 address.
The real issue here is that those enterprises who say “I don’t care for IPv6 because I love IPv4 and NAT” aren’t the problem. Instead, the problem is their customers, partners, and suppliers who lack public IPv4. Their customers do increasing amounts of online ecommerce via their mobile phones using private IPv4 addresses behind a NAT. When those customers go to a corporation’s IPv4-only systems, the corporation must backhaul their traffic through a CGN, NAT64/DNS64 or IPv4-as-a-Service system that may not be in their vicinity, adding latency and potentially reducing performance. Mobile subscribers have a high degree of IPv6 connectivity, but their mobile devices use a private IPv4 address and must pass through a CGN system within the mobile provider’s network. Furthermore, the NAT process causes TCP/UDP header checksums to be recomputed, and often customers are competing for TCP “port space” with numerous others passing through the same CGN. Therefore, over time, the end-user experience with IPv4 will worsen.
Those mobile devices have IPv6, but they are unable to connect to the IPv6-celibate corporations that are recalcitrant given their commitment to IPv4-only. When these mobile devices connect to places on the Internet, their experience over IPv6 can be better than over IPv4.
Turns out, in fact, it is the traditional enterprises that are the problem in the relationship.
You can almost hear the commercial enterprises repeating George’s famous breakup line as they ponder IPv6 adoption.
Playing the Field with Dual-Protocol
If you are an enterprise conducting business on the Internet then you will want to be able to “play the field.” You will want to be able to communicate and “hook up” with any customer, supplier, partner, vendor who may be using IPv4 or IPv6. The Internet “dating pool” is already using native IPv6, yes still using NAT through one (or two) NAT devices for IPv4 connectivity. If the corporate enterprise adopts a dual-protocol Internet environment, then they will be reachable to the throngs of mobile devices already using IPv6 today that their customers possess. When an enterprise elects to deploy IPv6, then their customers using IPv6 are far more likely to “swipe right.”
Falling in Love, Head Up in The Clouds
Corporate enterprises are falling in love with public cloud infrastructure. They are jumping into cloud-based relationships without first considering the consequences for their IP addressing plans. Enterprises may not think they need to enable IPv6 for their cloud environments so they start to deploy with 10.0.0.0/8. They use 10.10.0.0/16 for the first VPC, they use 10.20.0.0/16 for the second VPC, and so on for their other cloud vendor environments. Then they quickly realize the repercussions of this profligate behavior. That is, when they try to establish a hybrid-cloud architecture and join their cloud environments to their on-premises data center they are faced with the massive overlap of private IPv4 address space with their internal networks.
As the enterprise has stated “it’s not them” – they have plenty of bandwidth and IPv4 addresses. Typically, when they deploy their Internet-facing apps in the cloud, it is a single public IPv4 address on a load balancer front-ending the auto-scale-group of web servers. Also, those public addresses are usually owned by the cloud service provider and are not allocated from the enterprise’s current supply of public IPv4 addresses.
However, while the clients of that cloud-based web service or application lack direct IPv4, they do have direct native IPv6 connectivity. If the cloud-based applications want to be desirable and have the best opportunities for the best connectivity in all cases, then they will need to be accessible over both IPv4 and IPv6. This means choosing a cloud provider that has a substantial IPv6 service offerings to facilitate the greatest degree of Internet reachability.
Getting Married – Mergers and Acquisitions
Believe it or not, IP addresses are a topic for many prenuptial agreements. When two corporations want to merge, there is often a lengthy courtship that occurs as they evaluate their compatibility (and sort out all their overlapping IPv4 addresses). The choice is then made to readdress (typically the acquired company takes on that responsibility) or they decide to perpetually live their lives at arms-length and install bi-directional NAT between them.
IPv6 has the advantage when two companies fall in love and want to take that next step and move in together. Both organizations would be using globally-unique IPv6 addresses. They don’t require chaperones to avoid address overlap. IPv6 allows them to have a “spur of the moment Las Vegas wedding” and directly connect without concern for overlapping addresses or NATs. Both companies would be using globally-unique IPv6 addresses that facilitate direct communication without any NAT or readdressing process.
Be the Bigger Person
When it comes to communication in a relationship it is said that it’s best to be open-minded and receptive to others’ ways of communicating. If enterprises close off their borders to IPv6 and only speak IPv4, then they are not leveraging all that the Internet has to offer. You should “be the bigger person” and proceed to adopt IPv6 so that, regardless of other’s preferences for IPv4-only – whether it’s IPv4 through a CGN, NAT64/DNS64, IPv4-as-a-Service, or IPv6 – you will be able to communicate with everyone. After all, massive corporate enterprises have substantial IT budgets that eclipse the expense of their customer’s tiny mobile devices offering native global IPv6 but NAT’ed IPv4. They have the means to deploy IPv6 and, frankly, at this late stage, it shouldn’t be too difficult or time consuming to IPv6-enable their Internet-edge.
Achieving Self Actualization Through Holistic IPv6 Deployment
As for the enterprises, the “it’s not me, it’s you” mentality prevents them from deploying IPv6, but the reality is that “it is them” because they haven’t yet adopted IPv6. Enterprises should avoid becoming IPv6 technology laggards and should be more aggressively considering their adoption of new technology to create a competitive advantage. Their customers, partners, and suppliers may not have sufficient IPv4 resources and may be already using IPv6. And that should motivate them to have open lines of communication.
In the end, relationships are all about communication. If you are unable to communicate natively, transparently, and honestly, then your relationship is doomed. If enterprises, like people, are open with their feelings and with their choice of IP version, they have will have fulfilling enduring relationships with their IPv6-enabled customers.
Scott Hogg (@ScottHogg) is CTO of HexaBuild.io, an IPv6 consulting and training company. Scott is Chair Emeritus of the Rocky Mountain IPv6 Task Force (RMv6TF) and authored the Cisco Press book on IPv6 Security. Follow HexaBuild on Twitter and LinkedIn.