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.

Thursday, July 26, 2012

We Need a "Demand Side" World IPv6 Launch

I was chatting recently with Michael Vincent, an IPv6 savvy colleague, about worldwide IPv6 adoption, which despite the considerable press around World IPv6 Launch, is progressing at a snail's pace. We lamented that while World IPv6 Launch provided great publicity around IPv4 exhaustion and the need for IPv6, the focus of IPv6 launch was on IPv6 deployment for the Internet supply side, i.e., websites. It's absolutely wonderful that so many organizations have enabled IPv6 on their websites, but where are the IPv6 users, or the demand side?

As IPv4 addresses dwindle in supply, service providers will ultimately need to begin assigning IPv6 addresses to their mobile and broadband subscribers. Nevertheless despite a growing number of IPv6 Internet users, these users will expect and demand ubiquitous Internet access, which requires connectivity to IPv6 and IPv4 websites. Therefore, each service provider will need to accommodate this customer requirement by either assigning both an IPv6 and an IPv4 address in a dual stack configuration, at least until IPv4 addresses run out, or by deploying address translators within their networks to convert IPv6 packets into IPv4 packets to reach IPv4 destinations.

Various IPv6-IPv4 network address translation schemes have been devised to for service providers to enable IPv6-addresss subscribers to access IPv4 websites, including NAT64, CGN, 6rd, DS-Lite, among others. I'll refer to the class of IPv4-IPv6 translators within these schemes as address family translators (AFTs). 

Though AFTs are generally designed for scalability, they do have their limits. All IPv6-IPv4 traffic would need to funnel through these devices enroute from the service provider's subscriber devices to destination Internet sites. As the volume of IPv6 addressable subscribers grows, so will the volume of traffic at the expense of available shared IPv4 addresses and ports, and the capacity of daisy-chained  AFTs. At the point of reaching such scaling limitations, subscribers' perceived Internet performance will suffer and customer dissatisfaction will rise.

The dual stack approach is the most flexible but by definition requires availability of IPv4 addresses (NAT444 and similar IPv4-IPv4 NATs are likewise scale-limited). AFTs serve as a temporary IPv4 extension technology, but at some point, this dam will burst and barring any new IPv4 extension technologies, the service provider will be faced with a large number of unhappy customers.

While we are perhaps a couple of years from this situation occurring, it makes sense to plan ahead with a concerted Internet community effort for a demand side World IPv6 Launch. This launch would entail service providers decommissioning AFT devices and enabling native IPv6 addressed customers to access IPv6 enabled websites. As unpleasant as this sounds, this would effectively define the dreaded "Y2K date" for organizations to implement IPv6 websites to enable communications with this sudden spike of Internet IPv6 users. Of course organizations missing the date can still catch up later.

As such this launch date would need to be far enough into the future that organizations can plan for it, but not too far that IPv4-extending technologies surpass their capacities. I would defer to a true Internet guru such as Dr. Geoff Huston, who could perhaps extend his IPv4 exhaustion analysis to derive the upper bound of this date.

Compliance with this date would be completely voluntary, but it seems we need a plan to address this Internet transition issue. Without a concerted plan, individual service providers will "hit the wall" independently and subscribers will suddenly face limited Internet access. They may flock to other service providers who still have IPv4 capacity, only to accelerate their IPv4 run-out. With a launch date a year or so out, organizations can make concrete plans and service providers can offer a more consistent Internet experience to subscribers no matter which protocol they are using.

Wednesday, June 6, 2012

2012 IPv6 Survey Results Published

In celebration of World IPv6 Launch, we've published the results of our IPv6 survey. Evidently, people have been busy deploying IPv6 over the last twelve months! In last year's survey only 5% of respondents had deployed IPv6 on all or a portion of their networks. This year, that metric leaped to 13%. And with a 50% larger sample size, this represents quite a jump. Another 20% are engaged in the process of IPv6 deployment now and an additional 24% plan to deploy within two years.

Download the survey results to get all the details!

2012: It’s the end of the (Internet) world as we know it

We’ve read about it on the web, seen it on TV, watched it in movie theaters: the Mayans predicted 2012 as the end of the world! Despite rumors about the predicted end of time resulting from lack of additional space on the rock on which the calendar was carved, I personally believe this was merely the “IPv4 Internet rock”, which has reached its end as a homogeneous entity this year. The Mayans were very sophisticated in their foresight and technology, so we should not underestimate their ability to predict the end of the Internet as we know it!
All kidding aside, with World IPv6 Launch, the Internet has changed forever. Over 2,500 organizations including BT have enabled IPv6 websites permanently in celebration of the launch. This “supply” of web content will be welcomed by a burgeoning population of IPv6 users, arising from insatiable global demand for IP addresses, driven by explosive rates of mobile and wireless subscriber growth, particularly in the eastern hemisphere where IPv4 address space is already depleted. Evolving “smart” initiatives like smart cars, smart homes, etc., featuring vast distribution of IP-addressable probes and devices for remote monitoring and control, promise to be massive consumers of IP addresses as well.
At BT, we’ve been conducting periodic surveys over the last seven years to gauge IPv6 interest and deployment. We just concluded our most recent IPv6 survey in early May and it’s clear that more people are looking into IPv6 this year than in prior years. Key among our findings from the survey was that 13 per cent of respondents indicated that they had already deployed IPv6 across all or a portion of their networks. This is up from only five per cent last year, a substantial jump. Another 44 per cent are in the process of deploying IPv6 or will begin deployment within two years.
The need for organizations to deploy IPv6 is primarily driven by the fact that IPv4 and IPv6 do not natively interoperate. As the proportion of IPv6 users increases with continuing IP address demand, the best approach to enable communications with these users is to deploy IPv6 while maintaining your IPv4 implementation. Survey respondents agreed that such a “dual stack” approach was favored over tunneling and translation approaches. This entails assigning both an IPv4 address and an IPv6 address to each device on the network, say your web servers for example.
When assigning two addresses to your web server, you’ll need to make sure your domain name server, DNS, is configured properly to direct your website “www address” to both the assigned IPv4 address and the IPv6 address.  The dual stack approach enables end users of either protocol, IPv4 or IPv6, to reach your Internet servers, and to allow your users to communicate with other Internet servers (in accordance with your security policies of course!).
Should you decide not to deploy IPv6, your Internet presence will continue serving IPv4 users, but as the density of IPv6 users on the Internet grows, these users will be unable to reach your Internet sites. And your users will be unable to reach theirs. We recommend you begin planning now or in the near future even if you don’t have immediate deployment plans. The process of deployment may be relatively simple or very complex and time-consuming, depending on your deployment scope and current networking and computing environment. Planning for IPv6 deployment in advance can help identify steps to deployment and streamline the process in preparation for the time when deployment is deemed necessary.
If you need assistance with IPv6 deployment planning, BT can help with assessment, planning, implementation and IPv4-IPv6 network operations. Key among tools used throughout this process is our IP address management solutions from BT Diamond IP. These solutions enable assessment and planning of your IPv4 and IPv6 address plans, and are indispensable in the ongoing management of address space within an organization’s IPv4-IPv6 network.

Tuesday, May 8, 2012

Six Simple Steps to IPv6

It’s easy to understand how one would be perplexed by the multitude of IPv6 deployment options and approaches. And depending on the extent of your network on which you plan to deploy IPv6 as well as the state of your current IPv4 network and computing environment, the task of IPv6 deployment may range from being quite straightforward to being very complicated.
But to help you get started in determining where your environment lies on this complexity continuum, I’d propose the following steps to keep it SIMPLE! These steps may be iterative if you split your deployment into phases, but the same basic process should apply on each iteration:
  • Scope - The first step is to define the scope of your IPv6 deployment. For example, are you planning to implement IPv6 on Internet-facing infrastructure only or throughout your network? You may plan to implement IPv6 throughout your network eventually but decide to deploy in phases, starting with a small, controlled portion of your network to gain experience and test for any unanticipated side effects. It will likely also be more appealing from the perspective of resource requirements to start small then expand deployment as well.
  • Itemize – If you don’t already have complete computing and network inventory, perform network discovery of end user devices, servers, infrastructure, IP subnets and address assignments as well as address pools within your chosen scope. This should also include applications, databases, security and network management products, and those employee “bring your own devices” (BYODs).
  • Mitigate – From your itemized list of computing components, identify which are IPv6-ready and which require upgrading or replacement. The latter forms the start of your “to-do” list. Recent vintage routers, switches and device/server operating systems support IPv6 today but it is instructive to take inventory and verify this is the case. Most applications that do not embed IP addresses within screens, configuration files or packet payloads should work with IPv4 as well as IPv6 though this should be verified as well. You may also need to invest in new infrastructure; e.g., DHCPv6 servers, so identify required new items for your “to-do” list, and also consider your security and network management products.
  • Plan – Based on your defined mitigation tasks, i.e., your “to-do” list, which identifies what components need to be procured or updated, determine the respective costs and align with the budget process, phasing in any required purchases as the budget permits. Define your IPv6 address plan and identify any IPv4-IPv6 transition technologies you plan to use, such as dual-stack, tunneling and translation techniques. Update your security policy to incorporate IPv6 protection policies, as well as management and change control policies to account for IPv6. Plan for training for personnel involved in IPv6 implementation and support. Integrate all of these planning tasks into an integrated project plan and identify resources required, dependencies, and planning time frames.
  • Lab test – The plan should incorporate a testing phase prior to production deployment to verify IPv4-IPv6 operations. To the extent possible, include as many components as possible in the testing, including security and management systems. Identify any issues and update plans or work with respective vendors to resolve.
  • Execute and manage – With a solid plan in hand and successful lab testing, the probability of successful plan execution can be maximized. However, even the best plans cannot predict every possible error condition. Carefully manage the deployment in accordance with the plan, invoking contingencies as needed. Communicate feedback to all involved including management to provide status updates and issues. Monitor security logs and management systems to baseline network operation and to identify anomalous conditions.
These “simple” steps provide a broad guideline for the process of IPv6 deployment. In attempting to keep things simple, try to focus the project only on deploying IPv6, and not to “throw in” additional network initiatives at the same time. This can lead to unexpected outcomes and complexity in troubleshooting and resolving error conditions. Stay focused and keep it simple!

Monday, May 7, 2012

IPv6 Survey Deadline Extended!

If you haven't yet had time to complete our annual IPv6 survey, there's still time! We have as many responses already as last year but we wanted to extend the deadline to account for some late notifications that went out last week. So you now have until May 15th at noon Eastern Daylight Time in the U.S. to complete the survey. You can enter your contact information to be eligile for a drawing for a free Apple iPad too! Make your voice heard! Survey results will be published by World IPv6 Launch on June 6th.

Monday, April 23, 2012

Take our 2012 IPv6 Survey

The 2012 edition of our IPv6 survey is now on-line! Breaking our former tri-ennial pattern, we're now going annual, since IPv6 deployment has certainly heated up! We conducting the survey over the next two weeks until May 4. The survey should only take 5-10 minutes to complete and for your trouble, you can enter your name and contact information to be entered into a drawing for a free Apple iPad.

The survey is similar to last year's, which helps us look for trends, but also features a couple of new questions. One of particular interest asks about the "IPv6 density threshold" people may be waiting for to pull the trigger on deploying IPv6. This density threshold relates to the percentage of Internet users that are IPv6 within the entire Internet. It'd be interesting to see if this "IPv6 audience size" has an influence on people's planning initiatives. Thank you in advance for taking the time to complete this survey! Results will be published in mid-May.

Monday, April 16, 2012

IETF decrees that "IPv6 is no longer considered optional"

The Internet Engineering Task Force (IETF), which for all intents and purposes is the standards body of the Internet Protocol, has declared that "IPv6 is no longer considered optional." In RFC 6540 officially published late last week as an Internet Best Current Practice, the IETF cites the impending depletion of IPv4 address space with the continued growth of the Internet as drivers for widespread IPv6 deployment. While the RFC defines requirements for all developers of IP nodes, the main target seems to be consumer device vendors, many of whom have delayed implementation of IPv6. With consumers just implementing these IPv4-only devices today, they are likely to remain installed for many years, extending the IPv4 support lifecycle. Of course IPv4 will be around for quite some time, but the more of these devices that are IPv4+IPv6 instead of IPv4-only, the easier co-existence will be to manage.

Among the best practices recommended, the RFC stipulates that all new "IP implementations" must support IPv6, and IPv6 support must be equivalent to or better than corresponding IPv4 feature support and quality, that dual-stack support is required though IPv4 must not be required for operation, and existing hardware and software implementations should be considered for upgrade to IPv6 support.

Another interesting statement from the RFC is that "the term "IP" can now be interpreted to mean IPv4 + IPv6, IPv6-only, or IPv4-only." While separate standards exist for IPv4 and IPv6, the term "IP" now officially encompasses both protocols. Requirements for features specific to a given version should be so indicated, while general "IP" features will be assumed to apply to both.

This IETF statement complements what the Regional Internet Registries have been promoting for some time, and the World IPv6 Launch seven weeks away testifies to Internet heavyweights' participation in supporting IPv6 deployment. The IPAM Worldwide homepage features a graph embedded from the RIPE NCC which illustrates the relative density of IPv6 networks being advertised on the Internet. While the graph certainly shows a growing influence of IPv6, the raw numbers are also of interest. Considering the worldwide average, 5320 IPv6 networks are being advertised as of the end of March, 2012, while only 3594 were in March, 2011. This represents a 48% jump in advertised IPv6 networks. The industry momentum continues to build for IPv6!

Wednesday, April 4, 2012

DDIB? DDI and block management

I recently had the opportunity to preview a market analyst's brief on BT Diamond IP's DHCP/DNS/IPAM (DDI) features and benefits. Among my comments, I indicated that there was no mention of IPv4/IPv6 block management, a core IPAM function for which we are frankly unmatched. To my surprise, I was asked to elaborate about our block management features and benefits.

From my perspective, for any modest sized or larger IP network, DDI starts with block management. If you have to manually type in every subnet address in your network, why not use a spreadsheet? Block management enables entry of a "root" block, such as, fc00::/7, 2001:db8:a87e::/48, etc. as the root block from which subnets or other "pool" blocks can be allocated. This allocation process should not require re-entry (or cut-and-paste) of a chosen subnet address; if yours does, you're little better off than using spreadsheets which likewise require manual entry. With the Diamond IP solution you simply navigate logically to where the subnet is needed, and a few mouse clicks to select the type of address space (VoIP, wireless, management, etc.) you need, the version (IPv4 or IPv6), and CIDR size then submit!

This simple process ties IPAM directly to business processes. For example:

  • "I need a new wireless subnet in the Philly office finance division"...point and click and done
  • "I'm planning to open a new branch office next month and need to allocate eight subnets for planning purposes"...our site template feature allows one to meet this business requirement in one click!

And each subnet in turn can have an associated address assignment template, so one can also assign addresses for routers, switches, servers, DHCP pools, etc. as well as automatically generate A/AAAA/PTR resource records for each assigned address, further automating DDI functions! These two simple examples illustrate how block management ties directly to business initiatives, and how BT Diamond IP intuitively and easily maps these business initiatives.

There's a lot of noise out there about IPAM and DDI, and the messaging is understandably blurred. When trying to cut through the hype, don't discount what I consider a core IPAM feature: block management. After all, if you don't get your block management right, your underlying IP assignments and DHCP/DNS configurations won't be right either.

Friday, March 30, 2012

Ingredients coming together for global DNSSEC deployment - are you ready?

It's been a year since .com was signed, which was a major step forward towards Internet community support for DNSSEC implementation given that nearly 45% of all Internet domains fall within the .com branch. I was curious how other top level domains (TLDs) were doing in this regard so I checked out the ICANN Research site for TLD signing statistics. As shown in the following summary table, 22.5% of TLDs were signed a year ago, while 29.1% are signed as of today. This 31% jump in signed TLDs represents good progress, but there's still a way to go to get to DNSSEC ubiquity in chains of trust to the root zone.
March 2011March 2012
TLDs in the root zone306313
TLDs signed6991
% TLDs signed22.5%29.1%

Another boost to DNSSEC deployment was announced last week in the form of a pending FCC recommendation that promotes the deployment of DNSSEC planned by several major ISPs. These ISPs will be implementing DNSSEC validation on their recursive servers, which their customers query for DNS resolution. That is, as their customers issue DNS queries to these ISP recursive servers, the servers will resolve the query and attempt to validate the query signatures up the chain of trust to the root (or other configured trusted key).

This ISP deployment of DNSSEC should protect broadband users from website hijacking and other DNS cache poisoning style attacks. That is if the websites these users are attempting to access are signed. With growing TLD adoption of DNSSEC and an expected jump in recursive servers validating queries via DNSSEC thanks to this ISP initiative, the way forward is clear if your TLD is signed. All you have to do is sign your Internet zones and provide your parent zone registrar with your corresponding Delegation Signer (DS) records to link you into the DNSSEC chain of trust.

I believe the hesitancy with DNSSEC implementation is more deeply rooted in the complexity of DNSSEC configuration and the burden of ongoing management requirements for key rollovers and refreshing signatures than in the lack of widescale DNSSEC deployment. In many cases, this lack of deployment has served as a legitimate barrier to implementation, but this will soon cease to be the case.

As for DNSSEC complexity, BT Diamond IP offers a simple solution to signing your DNS information and ongoing maintenance: the Sapphire Sx20 appliance can be configured with your signing and rollover policies so you can set it and forget it. It will automatically roll keys, update signatures, even auto-update DS records accordingly for your subzones. The barriers to deploying DNSSEC are dwindling. Will you protect the integrity of your web resources?

Thursday, March 29, 2012

What would you ask about IPv6?

I am in the process of compiling questions for the 2012 rendition of BT Diamond IP's IPv6 survey. This survey is open to anyone wishing to express their opinion about the state of IPv6 and deployment plans. While I'd like to retain some of the questions from last year's survey to identify shifts or trends in opinion, there's always room for one or two additional questions. So if there's a question that's on your mind, feel free to post a comment to this blog post and I'll consider it!

I'm interested in what people are thinking about what conditions would hasten their plans to deploy IPv6, so I'm planning to add a question about this from the perspective of the IPv6 user density on the Internet. What would it take for you to consider this critical mass? 1 % of Internet users being IPv6, or 10%, or even 50%? Let me know if you agree this is a good question or if you have a different metric or any additional question ideas!

Friday, February 24, 2012

Whatever happened to IPv5?

In response to a recent question asking what happened to IPv5, I offer the following response.

The Internet Assigned Numbers Authority (IANA) maintains a centralized repository of Internet Protocol parameters. This function is critical to assure uniqueness of parameter settings to keep the Internet Protocol operating smoothly and without ambiguity.

Among the parameters maintained by IANA are the assigned values of the version field of the IP header. As you might guess, for IPv4, the version value is 4, and for IPv6, the value is 6. But as new protocols are developed within the Internet community, parameter value assignments are requested of and assigned by IANA. In the case of the IP version parameter, the value of 5 has been assigned to the Internet Stream Protocol an experimental real-time streaming protocol.

In fact, the IP version parameter has not only been assigned values 4, 5 and 6, it has also been assigned values of 7, 8 and 9 as shown in the following table from IANA:

4IPInternet ProtocolRFC791
5STST Datagram ModeRFC1190
6IPv6Internet Protocol version 6RFC1752
7TP/IXTP/IX: The Next InternetRFC1475
8PIPThe P Internet ProtocolRFC1621

If the next version of IP beyond IPv6 was defined as of today, it would be known as IPv10! But hopefully with plentiful IPv6 address space, we won’t need to go there at least in the next 40 years!

Sunday, January 29, 2012

Dictionary Needed: IPv4-IPv6, French-English

I was fiddling with a London Underground ticket machine to purchase a "tube" (subway) ticket upon my arrival here today, and a couple on the next machine over starting asking me French. Through gestures and pointing to the ticket machine screen display, I figured out that while the screen stated the Oyster card they wished to purchase covered the tram and bus, it did not mention use on the tube. I was experiencing some screen information shortcomings myself in desiring to purchase a zones 1-3 ticket, but only 1-1, 1-2 and 1-4 were offered. So given my prior research on the Oyster card and the incompleteness of our respective ticket machine user interfaces, I assured them that they Oyster card would work for the tube as well.

But this experience struck me later in the day in that we were only able to successfully communicate when we supplemented our verbal attempts at communication with gestures and visual clues. Had they rang me on my phone and asked me the same question, we would gone around in circles with little likelihood of success. This naturally brought me back to one of my favorite topics, IPv6. Speaking French to an English (non-French) speaker is a lot like an IPv6 device trying to communicate with an IPv4 (non-IPv6) device: it will not work!

Of course if I was bi-lingual (analogous to dual-stack) we would have easily and natively communicated. Otherwise, if we had no visual ability, a translator would have been required, analogous to a protocol translation gateway for IPv4-IPv6. But as we know in speech translation, something usually gets "lost in the translation", which is possible in IP communications, especially for sophisticated IP applications like SIP traversing a translation gateway. By the way, the third technology of IPv4-IPv6 co-existence, tunneling, doesn't really apply to our analogy, which would have been more like I had written a note in English, sealed it in an envelope on which delivery instructions were written in French and asked my French friends to deliver it!

The bottom line is that if you want to communicate globally, speak the language! Keep learning and gearing up for IPv6! It's the Internet "language" of the future.

Thursday, January 26, 2012

Combat DNS Hijacking

Dark Reading reported this morning that the, and domains were hijacked using DNS attacks earlier this week. The attack was performed by hacking the DNS servers authoritative for these zones and re-pointing web addresses to the attacker's site. Anyone attempting to access UFC's or Coach's websites was unwittingly directed to the imposter's site. Apparently these domains were targeted due to their organizations' support of SOPA/PIPA anti-piracy bills. The attack was detected by a sudden large influx of web traffic at the attacker's hosting provider. Administrators monitoring the attacked domains' web resources would have noticed a corresponding drop in traffic, which is one way to detect such an attack.

Had these zones been signed via DNSSEC, perhaps this attack impact would have been minimized. This would have been the case if a) the attacker was unable to "re-sign" each zone after modifying it, which would have depended on the depth of the hack to initiate zone signing or not and b) the resolvers performed DNSSEC validation. While it's debatable that an attacker having file access to a zone file also would have had access to run "dnssec-signzone" (or that auto-signing was configured), it's probably more likely that the resolver would not have been configured to validate DNSSEC signatures in the first place and thereby detect that the signature did not match the returned resolution data.

If you aren't already aware, you should know that configuring DNSSEC validation is relatively simple with BIND 9.8 and above. Simply configure your recursive servers with the DNS root public key within a "managed-keys" statement, and set dnssec-enable and dnssec-vailidation to "yes" within the BIND configuration file. BIND supports additional DNSSEC options to configure recursive servers but the beauty of this is that once setup, it runs on "auto-pilot." The managed-keys statement instructs BIND to detect updates to the root zone key (as defined in RFC 5011) and to automatically update its "trust anchor" accordingly.

Of course DNSSEC validation is only useful if queried zones (and parent zones up to the root) are signed. But BIND releases are also progressing towards making the authoritative side of equation easier as well (recursive servers ask, authoritative servers answer). BIND 9.9 promises some improvements in this area with in-line signing but does not yet automate key re-generation for automated rollovers. If you need an automated authoritative solution, check out BT Diamond IP's Sapphire Sx20 appliance, which enables creation of key, signature and rollover policies once, then it runs on "auto-pilot." DNSSEC cryptography technology is a bit foreign to DNS administrators; an automated solution can help provide the security required but minimize associated administrative support.

Tuesday, January 24, 2012

Happy Chinese New Year! Half a Billion Internet Users!

Global Times, a leading English news periodical in China, reported last week that the number of Internet uses in China surpassed half a billion by the end of last (calendar) year, according to the China Network Information Center. According to the report, China now counts 513 million Internet users, up from about 457 million at the end of 2010, about 12% growth.

The question I've been trying to answer is how many of these 513 million users have IPv6 addresses vs. IPv4 addresses? As yet I have been unsuccessful in answering my own question. But I've found that Mike Leber from Hurricane Electric publishes a daily Global IPv6 Deployment Progress Report. This report lists the TLDs with IPv6 (surprisingly only 85.9% have IPv6 addressable name servers today), a summary of A and AAAA records for "next level domains" for each TLD, a summary of advertised autonomous systems (ASes) for IPv6 networks, top websites available over IPv6 and more.

The top websites statistic is an interesting one, which today indicates that about 1.1% of the top 1 million websites as reported by Alexa, publishes at least one AAAA record to advertise IPv6 reachability. I view this statistic as the "supply side" of the IPv6 supply and demand relationship. The "demand side" would be represented by the number of IPv6 user devices, or my as yet unanswered question, not only for China but worldwide. At some point in time, I expect this demand side will reach a level where organizations will want to participate in supplying IPv6 content. But having visibility to this demand curve is necessary to make this decision. So I'll keep fishing around but if anyone has any suggestions, please share them!

Thursday, January 19, 2012

Gearing up for World IPv6 Launch

What better time to unveil the IPv6 Resource Center at BT Diamond IP than immediately following the announcement about the World IPv6 Launch! We've amassed a variety of material on IPv6 that hopefully enables people to learn about IPv6, in whatever media they prefer - video, audio, webcast, or reading with white papers and books.

World IPv6 Launch is not a deadline to implement IPv6. It's another means of publicizing the need to consider IPv6 deployment - is it right for you and when? IPv4 space is pretty much gone in Asia so as new IP address consumers in that part of the world comprising over 60% of the world's population begin using broadband and wireless devices, IPv6 address use on the Internet will grow. The homogeneous IPv4 Internet of today will evolve to a mixed IPv4-IPv6 Internet.

How rapidly and to what proportion IPv6 will permeate this mix is unclear. But it makes sense to track this over time and to be ready should the IPv6 density reach a level where substantial potential customers and sellers are unreachable with IPv4-only Internet presence. This is the real decision point for deploying IPv6 for those with plenty of IPv4 address space: at what point will I be missing substantial inbound and outbound sales, collaboration, and partnering opportunities with organizations constrained to only an IPv6 Internet presence? For every organization, this critical "IPv6 density" point will differ - for example, for organizations serving primarily Internet users from Asia, this time will be sooner than those that do not.

I'd recommend estimating that date for you (if you ever believe it will happen) and working backwards to devise a plan to support an IPv6 Internet presence. With a plan at the ready, you can estimate the plan execution time (make sure you add some fudge time due to inevitable unforeseen issues) and be ready to invoke it with enough lead time to complete it by your IPv6 Density or "D-Day."

Where to start? We've put together the IPv6 Resource Center for your perusal of material about IPv6 technology, IPv4-IPv6 co-existence techniques, and even a recorded webinar outlining an IPv6 deployment plan template. Please don't hesitate to contact me with any feedback on the material or suggestions for coverage of additional topics.

Tuesday, January 17, 2012

From World IPv6 Day to World IPv6 Launch!

The Internet Society announced today that several major Internet companies have agreed to transform last year's World IPv6 Day success to a deeper commitment with World IPv6 launch! The World IPv6 Launch is scheduled for June 6, 2012. Last year's event was a one-day "test flight" for IPv6. This year's launch promises a permanent enabling of IPv6 for not only major ISPs and websites, but also home networking equipment providers, which extends IPv6 to the "last mile" to residences.

The goal is to enable IPv6 for enough end users so that at least 1% of wireline residential subscribers' connections to participating websites to use IPv6 by June 6. This may not sound like much but 1% of an estimated 500 million is 5 million users which is substantial. This is an exciting time for Internet companies. The industry is moving deeper into IPv6. Are you ready?

Thursday, January 12, 2012

New gTLD program officially launched!

As of today, ICANN has opened the application process for new gTLDs! Applications for new generic top level domains are now being accepted through April 12, 2012. This is the first time that internationalized domain name (IDN) based gTLD applications are being accepted. Today sub-gTLD domain names may be defined in internationalized format and several country code TLDs (ccTLDs) have been in production for some time, but this is the first time that gTLDs may be defined.

So what's the big deal? Depending on what gTLDs are accepted, organizations may desire to register subdomains beneath new gTLDs in ASCII or IDN format. Considering that every marketing message from an organization includes a website address, advertisting a fully native lanugage URL (and of course content!) may facilitate marketing communications with audiences in certain parts of the world. For example, if your organization is attempting to reach or attract residents in India and a new gTLD is created using the native language Devanagari alphabet, creating a subdomain using the Devanagari alphabet may facilitate this reachability. Putting your information in your target customers' terms, down to the URL, can help improve communications and provide a competitive advantage.

Configuring DNS with IDNs requires no upgrades of DNS, but it does require conversion of native language characters, represented in Unicode, into ASCII which is required in DNS configuration files and the DNS protocol. This conversion process is a bit complex but the IPControl IPAM system automates this conversion to save time. If you'd like more details on IDN conversion for DNS configuration, please see our IDNA white paper, webinar replay or visit the ICANN gTLD website.