So where should we look to find a business case for IPv6?

Over the last year or two, the shift towards cloud computing paradigm has started to make some pretty impressive waves. Although still at a relatively early stage, we are seeing both service providers and enterprises coming out with brand new strategies for public and private clouds. Based on the recent developments, we estimate that by 2015, the way in which applications and network services are consumed will be very different from what it is today. The discontinuity here will be just as big as the Internet was some 15 years ago.

As far as the IPv6 business case is concerned, not many people have realized how critical IP addresses and DNS is for the cloud orchestration process. To commission or decommission a virtual machine, one needs to reserve or to free an IP address, preferably within a window of 300 milliseconds. Further, in order for that newly commissioned virtual machine to be easily accessed, a DNS entry is also needed. With Infrastructure 1.0 utilizing IPv4 spaces managed with Excel spreadsheets, the cloud doesn't scale.

To address this issue, anyone serious about cloud computing will have to come to accept that Infrastructure 2.0 is required in order for the cloud computing paradigm to work as intended. If someone is to make a considerable investment in cloud environment, protecting the investment for at least the next 10 years becomes essential. And the way I see it, this is where IPv6 comes in.

In this light, IPv6 can be viewed as a similar enabler to the cloud as IPv4 was for the Internet. From the business perspective, IPv6 enables the cloud to scale into the foreseeable future. Furthermore, by making IPv6 a standard feature in clouds, organizations investing in them can make sure that their basic architecture will stand the test of time, thereby optimizing the cloud ROI.

Written by Juha Holkkola, Managing Director of Nixu Software

Thought leaders across the industry are focusing on transition topics that matter: from economic lifecycles, security, and business continuity to the promising future of the Internet of Things. This is what drives most of us, and those on the front lines in the IPv6 evolution have every right to rise up and celebrate. It's not only a great technological milestone, but a testament to their collective abilities to work together for the greater good of the connected planet.

Today's Internet is the foundation for everything we do and the IPv6 Internet will be too but unfortunately some things never change. While the majority have been busy working on IPv6 for the greater good, evidence makes clear we're likely to come face to face with a growing number of technologists (aka criminals) with malicious intentions. IPv6 hinders them in some ways, but helps them in others. If you have any doubts, a quick search will show a growing number of software tools intended to break or exploit IPv6. Everything we build offers potential for those who are malicious to use their skills for disruption. Security is a continuum and experience suggests it might be worth some cycles to make sure your IPv6 project does not end up on your CEO's shortlist of things that keep them up at night.

Preparing for the transition requires looking beyond just software support and interoperability testing to identifying strategic partners and understanding the long-term cost of ownership. If IPv6 is important to your future you owe it to your business, investors and customers to make sure you have the best technology but are also on the right path with the best, forward looking partners. It's refreshing to see that on the Internet, as has always been the case, a global initiative can transcend the boundaries of political, social, and economic agendas. Maybe we can all even learn a lesson or two from IPv6 on how to tackle some of the critical long-term social and economic challenges facing the world today.

Want to learn more about the transition to IPv6, join us at our webinar on May 30. Click here.

Written by Craig Sprosts, General Manager of Fixed Broadband Solutions at Nominum

Recent IPv6 statistics from the RIPE NCC show an accelerated uptake of IPv6 in Norway, both in terms of the number of allocated prefixes, and visible announcements in the routing system. This is based on a comparison over time of the amount of IPv6 addresses allocated to each economy, and the amount of visible prefixes per Autonomous System (AS) in the routing tables each day. The graph below shows 50% of ASes in Norway now announce one or more IPv6 prefix.

Some have interpreted this to mean that over 50% of the end users in Norway have now access to IPv6. However, a measurement of end user IPv6 capability by APNIC doesn't necessarily support that, rather, it suggests that end user access to IPv6 remains low in Norway, as in other economies. The graph below shows the percentage of IPv6 preference at the end user level.

Keep in mind that this only includes data until mid-May, hence the drop at the end. For the most up-to-date graph, please visit the APNIC Labs IPv6 Measurements pages.

Are these measurements in conflict?

No, not really. One is a measure of capacity and capability in routing and forwarding, and the other is a measure of end user access. There are many reasons why some routing-active entities don't show up in an end user measurement: the AS may be servicing content delivery and not offering access services, or may be providing transit and data management services for others and have no direct end user traffic.

Perhaps the AS is servicing segments of the user base who only gain access to the global Internet occasionally, or to restricted URLs, or not even the web but only VOIP (which we can't measure in the APNIC technique.)

The difference is not a conflict. It exposes differences in what we see on the Internet and the different conclusions drawn from each.

APNIC's measurement focuses on end user access, and in large part, suggests that there is a continuing problem with end user access to IPv6, even when the AS in question may have associated IPv6 allocations visible in global routing.

In the background article on RIPE Labs you can find much more information, including the methodology and an analysis of the specific situation in Norway and in Japan.

Written by Mirjam Kuehne

The first, more widely known, development is the IETF's ongoing DANE effort. The DANE standard proposes to improve the Transport Level Security (TLS) protocol, which is used worldwide to secure communication between applications (e.g., a browser) and host machines (e.g., a website server). DANE enables administrators of domain names to specify TLS cryptographic key material in a resource record stored in a zone file. Using DNSSEC, an application could validate the resource record with the practical result that communication between an application and host machine is probably more secure — a good thing.

Perhaps the most interesting aspect of DANE is that it takes TLS key distribution out of the hands of the browser/certificate authorities and places it with DNS operators. The browser/certificate authority regime has been shown to be susceptible to attack and lacking in clear lines of accountability. In theory, if an administrator puts signed key material in the DNS, an application can validate it starting from the single trust anchor maintained by ICANN. Like DNSSEC, DANE depends on registrars, registries and Internet service providers not tampering with signed data provided by administrators. Pressure to tamper with data could come from numerous sources, e.g., interests in intellectual property protection, advertising, surveillance, etc. At the end of the day, it will be the DNS contractual regime, the laws that govern the involved parties, and the extent to which those institutions are transnationally interoperable that determines how DANE contributes to various global public policy goals like free expression and free trade in information services. Expect the differences between governments, and their response to domestic pressures, to challenge that interoperability.

The second, and in our opinion, more interesting development is the more recently proposed ROVER (Route Origin Verification) effort which seeks to address the problem of misconfigured routing announcements, whether accidental or intentional. Similar to DANE, ROVER proposes to improve the inter-domain routing by creating new resource records published in the secure reverse DNS (i.e., the in-addr.arpa zone). Similar ideas have been proposed previously, but never took hold. The records would allow network operators to indicate whether an IPv4 or IPv6 prefix ought to appear in global routing tables and identify authorized origin Autonomous System Number(s) for that prefix. This is the same data (i.e., Route Origin Announcements) which appears in the Resource Public Key Infrastructure (RPKI) being managed by some RIRs. ROVER would facilitate the comparison of validated records stored in the secure reverse DNS against route announcements being made on the Internet. Discrepancies could be flagged and lead to further action taken by the operator.

Again, the most interesting aspect is the interplay between technology and institutional power. The technical community has been debating the merits of Secure DNS vs. RPKI. The debate occurs in the shadow of the major, ongoing concern for network operators concerning RPKI, i.e., how it could allow certificate authorities (e.g., the RIRs) to impact routing. This concern is further complicated with Border Gateway Protocol Security (BGPSEC), which proposes incorporating cryptographic signing and validation of route announcements directly into the BGP. As an alternative, ROVER suggests leveraging the certified resource allocation data stored in the RPKI (or elsewhere) to create and validate route announcements in the secure reverse DNS. But it allows operators to independently apply that data to routing decisions. If a certificate authority revoked a certificate it would not impact routing unless the operator allowed it to. Less appreciated, however, is that ROVER potentially shifts route announcement data, typically stored in the decentralized Internet Routing Registries (IRRs) now, into the hierarchical secure DNS. Given this, the operation and governance of a few zones, namely .arpa and in-addr.arpa, becomes critical. Those zones are currently managed by ICANN. Its use for routing purposes may raise contention that too much power is centralized with this organization. In theory, as manager of the in-addr zone, ICANN could regulate network operators via contract, similar to the way it does some TLD operators. This will need to be examined more closely.

Written by Brenden Kuerbis, Postdoctoral Researcher at Syracuse University, School of Information Studies