Yesterday, the National Telecommunications and Information Administration of the U.S. government hosted a workshop discussing the state of IPv6 in the United States and its impact on industry, government, and the Internet economy. I was asked to be a panelist, along with industry executives from ARIN, ISOC, ICANN, Comcast, Akamai, Verizon, Google, VeriSign, DOE, NIST, and DREN. Moderated by Aneesh Chopra, Chief Technology Officer of the United States and Vivek Kundra, Chief Information Officer of the United States, this was the first event in the past few years to truly shine a spotlight on IPv6 adoption (or lack thereof) and introduce key directives to move this issue forward.
Expecting an IPv6 service that matches IPv4 is asking a lot — the industry overall is still some distance away. John Curran from ARIN and Danny McPherson from VeriSign provided excellent detail on the adoption and usage rates of IPv6 and IPv4, predicting an IPv4 Exhaustion day of May 29, 2011.
Afilias' registry and DNS services support over 17 million domains. All our registries support IPv4 and native IPv6, and have done so for years. We have spent significant time and money in migrating our core services to be fully IPv6 compatible. Despite this attention and effort, and similar to other companies on the front lines of IPv6 deployment, neither the systems nor user adoption are quite there yet.
Usage drives demand – current IPv6 usage is limited
While our systems support IPv6, very few customers are actually using it. Here are a few key statistics:
The .ORG registry has over 8.6 million domain names registered in its system. Of these, about 17,000 names have both an IPv4 and IPv6 address in their glue records; and 99 names have an IPv6 only address. The .INFO registry has nearly 7 million domain names registered in its system. Of these, only 58 names have both IPv4 and IPv6 addresses in their glue records and 25 names have IPv6 only. The .MOBI registry has over 910,000 domain names registered in its system. Of these, no names have both IPv4 and IPv6 addresses in their glue records, and only 2 names have IPv6 only addresses. We also manage the technical systems of 10 national sovereign country code registries, with close to 1 million domain names registered. Of these names, only 14 domains have both IPv4 and IPv6 addresses in their glue records, and 6 domains have IPv6 only addresses.
In contrast, .ORG has over 2.3 million domain names that have an IPv4 only address; .INFO has close to 300,000 IPv4 only addresses, MOBI has 3,660 IPv4 only addresses and the 10 countries whose domains we provide technical services for have over 60,000 IPv4 only addresses.
Just to be clear, these numbers measure the number of "glue records" that have an IPv6 address. A more technical way of saying that would be the number of subdomain DNS servers within the Top-Level Domain (TLD) that can be queried over IPv6. That is not necessarily the same as the number of servers/hosts within those TLDs that are IPv6 enabled.
Aneesh Chopra called this adoption rate "lame." It seems an apt description.
When "IPv6 Compatible" Isn't Good Enough
Hardware vendors for critical pieces of load balancing equipment claim to have "Support for IPv6". Recently, we evaluated equipment from various competing vendors. Quickly, it became evident that there is a remarkable difference in the way IPv6 flows are processed by the different security appliances currently in the market. IPv4 packets are processed by dedicated hardware built into the appliance — this allows the device to handle filter lists of several thousand entries with no or very little impact to performance. In contrast, IPv6 flows are processed in software and therefore impact the CPU directly, consequently affecting the forwarding rate of the appliance as the filter list grows in size. This presents a significant risk of performance degradation and there is no guarantee that software performance will match the service level standards we have been able to meet with our current IPv4 configuration. To solve for some of these limitations, Afilias has provisioned a separate set of front end firewalls dedicated to handle IPv6 only traffic in order to minimize risk on the IPv4 infrastructure. We have also beefed up our evaluation criteria because "support for IPv6" does not equate to "equivalent performance with IPv6". My experiences were supported by other panelists, and Doug Montgomery from NIST spoke eloquently about having to reject many pieces of so-called IPv6 compatible equipment because of performance issues.
About the same time as we were looking at load balancers, we also evaluated vendors who could offer equipment for rate limiting traffic inflows into our global networks that would match our current IPv4 policies. As of today, there are are no vendors in the market that offer an IPv6 solution with sufficient performance to match that required by our current IPv4 supported policy. Therefore the likelihood of having a single appliance with a unique and enforceable policy for rate limiting in both IPv4 and IPv6 is very unlikely. This is an increased cost, management and usability burden. Vint Cerf from Google explained that his organization circumvents some of these issues because Google builds much of their own systems, but to the extent that they buy from external vendors, they too face similar issues.
Key Directives for IPv6 Adoption
At yesterday's second panel that focused on Federal efforts on IPv6, US CIO Vivek Kundra unveiled the U.S. Office of Management and Budget's memorandum to all CIOs of Executive Departments and Agencies of the US government that contained key actionable directives for IPv6 deployment and adoption.
These Federal government directives can be summarized as:
George Conrades from Akamai suggested that for IPv6 adoption to be taken seriously, it needed to become a reported-upon item at Board Risk Management Committees. This suggestion resonated strongly with both the panelists and the audience, and Aneesh Chopra asked George to lead a "coalition of the willing" to deliver a Board Risk template that could be widely adopted in industry in the next 90 days.
My perspective that, prior to training technical departments, organizational procurement departments also require training on IPv6 found broad acceptance in the room. Teaching the procurement department that best fit calculations based on IPv4 defaults do not translate to a v6 environment, and that incompatibility of IPv4 and IPv6 operations will lead to poor and degraded performance for customers will mean that a different kind of procurement and technology checklist for IPv6 purchases is now needed. Chopra took that on, as a second deliverable to find a way to create a technology IPv6 requirements template to mirror the Board Risk template.
IPv6 performance and requirements must conform to a uniform template across the industry — something that does not exist today. Both Jason Livingood from Comcast and Nabil Bitar from Verizon said that Internet consumers first demand high performance, and IPv6 based networks have to deliver such performance above all else. Given the volume of data that flows between the companies whom the panelists represented — there was a gentle nudge to the Federal government to try to gather publicly available data on IPv6 usage, and publish them in an accessible manner — a national IPv6 Usage Dashboard, of sorts.
As Leslie Daigle from ISOC said, staying with the current Internet addressing protocol is not an option. We are rapidly moving to a world where new devices will be IPv6 accessible only. So far, IPv4 depletion has resulted in scarcity economics rather than prompting a massive IPv6 migration. The eventual adoption of IPv6 is likely to be driven not just by scarcity, but by the direct and tangible benefits organizations believe they can obtain — economic self interest will be the critical motivating factor. The US government directives could spur those economic forces further forward towards broader IPv6 adoption.
|Cybersquatting||Policy & Regulation|
|DNS Security||Registry Services|
|IP Addressing||White Space|
Afilias - Mobile & Web Services
Minds + Machines