We've been hearing about the next generation of the Internet Protocol (IP), IPv6, for years. It now appears that the enterprise will have to deal with this new version very soon. This became apparent when I listened to an IPv6 presentation by Jeff Doyle.
Jeff Doyle and Associates, Inc. is a consultancy specializing in large-scale enterprise and service provider networks. Jeff provides planning, design, and best-practice expertise around IPv6, MPLS, BGP, and OSPF/IS-IS.
I posed a number of questions to Jeff to obtain a better appreciation of the implications of the IPv6 move for enterprises.
What is the value of moving to IPv6 for the enterprise?
The value of moving to IPv6 for the enterprise is on the public-facing edge. Over the coming years Internet service providers--primarily broadband service providers--will be bringing large numbers of new IPv6 users on-line, because the only addresses available for them to give new customers are IPv6 addresses. These providers will be implementing a number of "transitional" technologies to enable their IPv6 users to reach IPv4 content on the Internet, and these technologies are known to cause performance problems or completely break many applications. This is problematic for enterprise operators because if one of these transitional technologies creates a bad user experience, the user is not going to perceive it as a problem with their Internet provider--they are going to blame the enterprise or content provider. So, for example, if a customer's online banking application stops working, he will blame the bank; if a customer's online health insurer's account management behaves poorly, she will blame the insurance provider. By ensuring that their online services are IPv6 enabled, enterprises and content providers bypass the potential problems of IPv4/IPv6 transitional technologies, allowing IPv6 users to access their services natively and on par with IPv4.
What about all the other RFCs that are part of IPv6 beyond the addressing scheme?
There are indeed many Requests For Comments (RFC). This was the same with IPv4. Some are essential to IPv6, like Neighbor Discovery Protocol (NDP) and ICMPv6. Others are specialized and only used in certain situations or by certain devices, such as the IPv6 routing protocols (OSPVv3, etc.). Then there are others that are only used in limited environments, such as the many RFCs around mobility. There are also a number of RFCs that will probably never be implemented at any scale, due to lack of interest from the user community or lack of support from vendors. This is no different than dealing with IPv4.
As for why the more obscure ones are being proposed, it is also typical within the IETF. A few engineers think of a good idea, or a vendor is looking to propose a standard around one of their developments. That's just the nature of the IETF, and why the documents are called Requests for Comments; they get published specifically to get the community to look at the proposed standards.
There will doubtless be hundreds of new RFCs over the coming years, some of which will affect enterprises and some of which will be irrelevant to them.
Is there an ROI for the enterprise to move to IPv6?
Usually not. It is, as the answer to #2 explains, more of a business protection move, ensuring that they can continue to service online customers as more and more of those customers begin using IPv6.
What existing systems will have to be changed for the move to IPv6?
This depends greatly on the individual network architecture, but typically:
* Routers
* Servers
* Load balancers
* Security (firewalls, IDPs, web filters, etc)
* Support systems (DNS, DHCP)
* Management systems
What is the effect on existing applications, worst to best case?
Worst case is an application that makes direct references to the network layer (usually addresses). These are poorly written applications and will break if they expect to find an IPv4 address and instead find an IPv6 address, or more likely, cannot parse the IPv6 header at all.
Best case is an application that is written with a proper network-layer API, and is entirely "network layer agnostic". These applications should have no problems at all.
Why has it taken so long for the move?
Denial and economics. Despite the large body of data that since 2005 has been showing that the IPv4 address pool would be depleted sometime between 2010 and 2012, most network operators continued to question whether IPv6 was really necessary. It was very difficult to make a business case for IPv6 and gain funding for an implementation project, when there was little evidence of new IPv6 users. Unfortunately, avoiding its implementation before IPv4 address depletion became critical, and means that the cost and risk of implementing now goes up. These will continue to go up the longer the implementation project is put off.
Will there be an IPv7?
There are no plans for an IPv7, and no reason for creating one. If an IPv7 arises, it will likely be a specialized, experimental protocol like IPv5 was, rather than a replacement for IPv6.
