Wednesday, September 19, 2012

IPv6 Deployment in U.S. Nearly Doubles Since World IPv6 Launch

With all the IPv6 fanfare and press leading up to World IPv6 Launch this past June 6th, after which things quieted down, I've been wondering, has anything happened since? According to ongoing research  conducted by the England Chapter of the Internet Society published on the RIPE NCC website, most countries worldwide have experienced higher IPv6 penetration as measured in August, 2012 vs. June, 2012. In fact, the U.S. experienced the largest percentage increase in IPv6 penetration over the period, leaping from 6.17% to 11.46%!

The research project is dubbed the IPv6 Matrix Project, and full details about the project can be found on its website. In a nutshell, the system attempts an "IPv6 crawl" by looking up DNS records for the top one million websites (and then some) according to Alexa. The system uses DNS results to initiate connection attempts to email, web and time servers.

The IPv6 Matrix website home page displays a world map, which I assume displays the very latest measured penetration percentage as you mouse over each country. Mousing over the U.S. today indicates 22.47%, but this particular metric includes only the .us ccTLD, not .com, .net or .org which are included in the report metrics published on the RIPE website.

Interestingly, results in Asia were surprisingly low given the general lack of IPv4 space coupled with tremendous wireless and broadband growth in the region. Perhaps most Internet hosts are behind NAT64 gateways. While the England chapter of the Internet Society plans expand the data analytics over time, additional "crawlers" distributed across the globe may provide more robust sampling. But certainly this is a great start in terms of publishing one measure of IPv6 deployment.

Friday, September 14, 2012

The Next Domino Falls - RIPE Down to Last /8

I used the metaphor of dominos in a prior post to illustrate the close inter-relationship among IPv4 address suppliers, namely IANA, each of the Regional Internet Registries (RIRs) and Internet Service Providers (ISPs). Up til now, the "initial domino" fell with IANA depleting its available IPv4 space in early February, 2011. This event was followed only two months later by the APNIC, the RIR serving the Asia Pacific region, to fall next when it reported that it had entered the final phase of its IPv4 allocation policy with only its final /8 of IPv4 space remaining. Today, the European RIR, the RIPE NCC, announced that it too has now begun making allocations from its final /8 of IPv4 address space.

The clock is ticking on IPv4 address space. Unfortunately, it's inevitable. IPv4 space will no longer be available for allocation anywhere at a time in the not too distant future. Even if you have plenty of IPv4 address space, the complexion of the Internet will continue to morph from today's predominantly IPv4-only network to a mixed IPv4-IPv6 network. To reach all Internet users of the future with the ubiquity of today's Internet, you'll need to deploy IPv6 at least for your Internet-facing infrastructure like web and email servers. Of course if your internal users desire to connect to IPv6-only websites that emerge over time, you'll need to consider techniques for enabling this, such as deploying a translation gateway or implementing dual stack on such devices.

There's a lot to think about when deploying IPv6, even on "only" Internet-facing infrastructure. Mike Dooley and I have teamed up to write a forthcoming book on the topic, to be available in early 2013, to help people understand the motivation behind deploying IPv6, the process of assessment, planning, testing and deployment, as well as the technical aspects including consideration of infrastructure, applications, computing devices, security, network management, and of course, IP address planning. More details will follow as we approach publication so stay tuned!

Tuesday, September 11, 2012

How many DNSSEC validators are you missing?

On the heels of my most recent post asking, "How many IPv6 eyeballs are you missing?," I now pose the analogous question for DNSSEC. Do your DNS servers receive queries requesting authenticated resource record data for your namespace? If so, and you have not signed your zones, then DNSSEC validators' requests for authentication will go unfulfilled. And their DNS caches they are attempting to protect from poisoning will go unprotected, not to mention the integrity of your DNS namespace. An attacker "impersonating" your namespace could redirect browsers to the attackers' website for example by providing DNS resolvers with falsified query answers using cache poisoning attacks such as those publicized by Dan Kaminsky.

On the other hand, if hardly any resolvers (i.e., caching servers) initiating queries on the Internet even perform DNSSEC validation, signing your zones will offer value only to a small number of deployed validators and no value to non-validating resolvers that ignore DNSSEC signatures. Is it worth the effort of implementing and maintaining signed zones?

In an attempt to quantify the number of DNNSEC validators issuing queries on the Internet over time, the Internet Society is asking for help on behalf of Verisign Labs. They are asking webmasters to add one line of code in their HTML files which causes each web browser visiting your site to initiate a DNS query to Verisign Labs' DNS servers authoritative for The Verisign Labs DNS servers then attempt to determine if the querying server is configured for DNSSEC validation. In this manner, Verisign Labs hopes to gather a measure of the relative quanitity of DNSSEC validating resolvers making Internet queries.

This data should help DNS administrators decide when DNSSEC zone signing makes sense for them. The preliminary results indicate that 3.66% of resolvers are DNSSEC-validating resolvers. Your participation in this analysis through the addition of one line of HTML can help Verisign Labs and the Internet Society to enlarge the sample size and provide robust measurements over time. These measurements will encourage DNS administrators to implement DNSSEC to secure their namespaces with the assurance that a given percentage of resolvers are utilizing and counting on their published DNSSEC signature data.

Wednesday, September 5, 2012

How many IPv6 eyeballs are you missing?

Here's my post for the Team ARIN blog:

Many organizations have expressed skepticism about deploying IPv6. But they need to understand that the issue is not how much IPv4 address space they have, but how much is available for global distribution. As IPv4 exhausts around the world over time, a new generation of web users possessing only IPv6 addresses will materialize and grow substantially.

But when will this new generation of Internet users appear in numbers? Many service providers are masking an indeterminate number of these users due to the necessity of providing them access to both IPv6 and IPv4 web content. This makes it difficult to gauge IPv6 client requests on a global scale, but you can actually measure this, albeit coarsely, on your own web presence. Let’s see how.

Presumably, service providers with IPv6-addressed subscribers will attempt to connect using native IPv6 end-to-end if possible, but drop back to using an IPv4-IPv6 co-existence technology such as tunneling or translation should the subscriber’s intended destination be reachable only via IPv4. The means to determine this reachability is initially done via the domain name system (DNS).

An IPv6-addressed device will attempt to resolve a user-selected URL to an IPv6 address by issuing a DNS query for the AAAA resource record type for the URL The service provider’s caching DNS server, to which the subscriber device directs this query, will attempt to locate the DNS server on the Internet that is authoritative for the corresponding domain, then query the server for the AAAA record. Should the query resolve successfully, the result is returned to the subscriber device and it will attempt a native IPv6 connection. If unsuccessful, the caching server may issue a similar DNS query for the A resource record type to determine if the destination is configured with an IPv4 address.

If the subscriber device has only an IPv6 address, configuring the caching DNS server as a DNS64 server provides a standardized method to translate the returned A record query result into an IPv6 address. When this synthesized IPv6 address is returned to the subscriber device in the form of a synthesized AAAA query response, the device will  attempt to establish connectivity via a service provider NAT64 gateway, which interconnects the service provider IPv6 network with the IPv4 Internet.

If the subscriber device is dual stacked, with both an IPv6 and an IPv4 address, it should issue both the AAAA and A queries itself, then apply its address selection policy table to determine which source and destination addresses to use. The default policy table implemented by most common operating systems today does favor IPv6 in the event of results returned from the AAAA query. If the AAAA query fails to return results, the device will attempt to initiate the connection via IPv4.

The bottom line is that IPv6 end users may be attempting to connect to your website using IPv6. The best way to determine this is by analyzing your DNS query logs. Review your query logs for AAAA query rates over time to identify increases in AAAA queries. As mentioned, this metric is rather coarse, as caching DNS or DNS64 servers will cache  responses received from other DNS servers, but it can serve as a useful indicator of IPv6 connection attempts to your website.