IPv6 and DNSSEC are respectively 20 and 19 years old. Their backgrounds, obstacles and outlooks make them close in many ways… This post is dedicated to them.

A few weeks ago I came across an old interview of me by ITespresso.fr from 10 years back entitled “IPv6 frees human imagination”. At the time, I was talking about the contributions IPv6 was expected to make and the challenges it had to face. After reading the article again, I realized that it has become a little dusty (plus a blurred photo of the interviewee :-)).

But what caught my attention the most in the interview was my assertion: “If IPv6 does not prevail in 2006, it’s a safe bet that it will happen in 2007”. Wow! Is that precise or is that precise? Since then, although things have changed, we are still far from that goal.

In the interview and in its totally inaccurate prediction I nonetheless found the initial motivation for sharing my current thoughts and analyses ten years on, with the promise not to try to make that kind of prediction again :-). That motivation, however, was insufficient to put pen to paper until chance opened a “window of opportunity” for a few weeks when IPv6 celebrated its 20^th anniversary in December 2015. Another coincidental event was the 19^th anniversary of DNSSEC in January 2016. Prompted by these various motivators I decided to broaden the scope of this post beyond the subject of IPv6 alone, and incorporate thoughts on the past and future of DNSSEC, a technology that has known a similar fate to date, in addition to having a similar age.

Here I am at last, keyboard

in hand, ready to face the blank page. To work!

The purpose of this post is to share feedback, in the form of an analogical exercise, on the respective careers of IPv6 and DNSSEC and the challenges facing both technologies. I have decided to focus on the similitudes between IPv6 and DNSSEC rather than dwell on what separates them, especially as both technologies are derived from functional / protocol layers that are fundamentally different.

An analogical exercise of this type can be seriously tackled only after sufficient hindsight and distance from the subject, while capitalizing on so many years of observation. I hope this post will live up to that requirement.

* * *

Several years of gestation, 20 years of maturation

In the context of the development of Internet standards, par excellence in the Internet Engineering Task Force (IETF), the birth of a concept / protocol / technology is materialized by publishing a “Request For Comments” (RFC). In this case, the first specification for IPv6 [RFC 1883] was published in December 1995, while the first specification for DNSSEC [RFC 2065] was published^[1] in January 1971 (those who wish to know more about the genesis of IPv6 or DNSSEC can visit this page for IPv6 or this page for DNSSEC, where one can note that the first initiatives took place much earlier).

With hindsight, and regardless of the status of the deployment of IPv6 and DNSSEC today, I am fortunate to have seen both technologies grow, to have been involved in both their careers, and above all to have witnessed, for the past 18 years, the first tests, the first go-live deployments (in particular by Afnic in 2003), outreach efforts, even the multiple barriers and challenges in their deployment faced by their respective communities. I wrote “respective communities”, when in fact they substantially overlap, since many of the pioneers in these technologies have worked on both fronts at the same time.

Use of the term “new” technologies

The first thing that needs to be put into perspective is the terminology used. I find it rather amusing that we (including me, don’t worry!) continue to use “new protocol”, “new technology”, “new extension” or “new version” when talking about IPv6 and / or DNSSEC, when their age is significantly long compared with the timescale of the digital age in which we live. No doubt our use of the term “new” is abusive, given the (still) low level of deployment of both technologies on the global scale. But its use still seems perfectly acceptable, and I personally intend to continue to refer to them as new, as long as the balance of power has not been reversed.

IPv6 and DNSSEC: close careers

Developments and extensions of standardized technologies within the IETF community are rarely disruptive, often for reasons of interoperability / backward compatibility. Indeed, in the “IETF standardization culture”, in case of tension, arbitration is often to the advantage of the objective/principle of stability and continuity of service (that of the Internet globally) to the detriment of introducing any significant leap in features and/or performance. This IETF culture is often translated into architectural principles, as can be seen in section 3 of [RFC 6709] for example.

Comparing these principles with the criteria that make a protocol a “wild success” [RFC 5218], given the difficulty of IPv6 and DNSSEC in becoming firmly established in their respective environments, the conclusion is severe for both technologies. While IPv4 and DNS (without security extensions) are considered a success, and may even be considered to some extent a “wild success”, IPv6 and the DNS Security Extensions (DNSSEC) are still far from being entitled to the (simple) rank of a “success”.

It is worth recalling that the initial goal for IPv6 and DNSSEC was simply to be successful, and not necessarily to be a “wild success”. But we should also recall that even “simply” being successful has often been the result of perseverance, rarely that of chance or a long and passive (mutual) wait. It is difficult to predict and achieve success for any new technology whose benefits are a priori collective, as is the case for IPv6 and DNSSEC. This collective benefit is above all the result of the network effect, often explained by “Metcalfe’s Law”.

What makes them so close?

First of all, they were invented at a time when the technology to be (ultimately) “replaced” or “spread” was already widely deployed, and this clearly represented a first brake. As a result, any deployment strategy of either of the two “new” technologies had to be gradual (no D-day) and preserve the interoperability and continuity of the overall operation of the Internet. Regarding IPv6, one thing to be avoided at all costs was a certain partitioning (“balkanization”) of the Internet into one set of networks that can only communicate via IPv4 and others that can only communicate via IPv6. For DNSSEC, the objective was mainly to ensure that the content of DNSSEC signed zones continued to be provided as “regular” (non-DNSSEC) content for resolvers that do not announce DNSSEC compatibility (“DNSSEC OK”).

Secondly, IPv6 and DNSSEC each experienced a long period of testing at the local, national and global level, with more or less close cooperation between stakeholders and more or less rigorous assessment of the results. Thus for IPv6, the 6bone network, launched in 1996 by three players [Uni-C (Denmark), G6 (France) and WIDE (Japan)] based on tunnels (encapsulation of IPv6 in IPv4), quickly evolved to provide a global experimentation platform for the basic features of the new protocol (with 2 IPv6 addressing plans tested at its peak, the 6bone had more than 1,000 sites in more than 50 participating countries). Thanks to the conclusive results obtained, the IPv6 pioneers deployed pilot networks and then real live networks late in the 90’s and the first decade of the 21^st century. Several players followed the model to the point where the 6bone network, interconnected with the live networks, had become the “weak link” in terms of stability and performance and caused increasing degradation at the global level. It therefore became necessary to dismantle the network, and the phase-out was announced on 6/6/6 (note the symbol!).

For DNSSEC, the pioneers first of all fought to obtain or develop each the tools necessary to sign their zones, before collectively putting pressure on ICANN to sign the root zone, like the RIPE community in 2007 or the workshop organized by the .se in 2008, which was the first ccTLD to deploy DNSSEC. Meanwhile, a bypass technique was adopted by the IETF, with the DNSSEC Lookaside Validation (DLV) [RFC 5074], and widely deployed based on the registry made available by the ISC. The root zone having been DNSSEC signed in 2010, the managers of signed top-level domains (TLD) gradually withdrew their keys from the DLV registry after creating the link connecting them to the root in the DNSSEC chain of trust. As a result, the ISC’s DLV registry began to lose its interest and the ISC therefore announced the gradual turndown of the registry by 2017.

Each of these experimental devices (6bone and DLV) therefore lasted nearly 10 years and it is fairly symptomatic of the very low level of initiative and involvement among the stakeholders conducting the experiments, and this “growth retardation” partly explains that of the maturity of two technologies.

Furthermore, during these long test periods, the IPv6 and DNSSEC communities were both obsessed about finding one or more (cumulative) factors that might significantly accelerate the adoption and deployment of these technologies. The most recurrent possibilities included the following:

1. a “killer app” is found, i.e. a use that is indispensable but requires deployment of the technology;
2. one or more major players decide to massively deploy and pull the others;
3. one or more governments start to impose deployment by decree and/or establish financial/fiscal incentives/deterrents (bonus/malus) to incite the stakeholders to adopt these technologies;
4. a significant threat occurs, causes a major risk of discontinuity/disruption of the existing services thus forcing the players into a corner, leaving them with no choice other than to deploy the technology in question, given the emergency.

Without reviewing one by one the items in the list above, today we can safely say that for both IPv6 and DNSSEC, the idea of a “killer app” ended up by being killed! There was little hope of finding one, and the collective energy could be better invested elsewhere… In particular, everything was tried to (over)sell the potential of IPv6, without ever succeeding in demonstrating the reality of its superiority over IPv4 to the more “resistant” users. For DNSSEC, the search by some of a “killer application” ended up by being caricatured by the others in a single sentence: “DNSSEC is a solution looking for a problem” :-)

Moreover, the “major” players had made announcements for nearly 10 years on their intention to implement/deploy IPv6 and/or DNSSEC, announcements that were publicized widely enough but with mixed results. This was the case for example of the release of Microsoft’s Windows Vista with its “native support” for IPv6, or the US government’s decision to integrate, in turn, IPv6 and DNSSEC, in the networks of all the federal agencies, with updates, regular reviews of the degree to which the objectives had been met, or Comcast’s announcement to deploy DNSSEC for their millions of customers. Finally, in Europe, let us remember the press release of the European Commission in 2008 announcing a target set by the EC: “[...] in 2010, 25% of companies, governments and European individuals use IPv6”. But the EC had failed to define the indicators and measurement parameters used to assess / monitor the level of deployment / use of IPv6 to maturity, and monitoring beyond. It was in April 2010 that the OECD has filled this gap. Its report “INTERNET ADDRESSING: MEASURING DEPLOYMENT OF IPv6” remains to date a known reference for the diversity of IPv6 indicators and metrics dealt with, as well as for the rigor of their definition.

In addition to these announcements, a sense of urgency was created on several occasions, involving many players worldwide. As can be read in an issue paper published by Afnic in 2011 (“IPv6, A Passport For The Future Internet”), some of the most significant occasions for IPv6 including the alarming (alarmist?) predictions by Geoff Huston announced in 2007 for an end of the IPv4 world in 2011, and then the effective exhaustion of the IANA IPv4 stock in 2011, in its wake causing a large number of players to get involved in the “World IPv6 Day” (2011/06/08), before seeing even more of them a year later (from 2012/6/6) with a permanent deployment target, the “World IPv6 Launch”. For DNSSEC, it was mainly the discovery of the “Kaminsky DNS flaw” which forced the world DNS community to rally around DNSSEC as the only long-term solution to mitigate cache-poisoning attacks.

Of course, many were betting on the fact that the adoption of IPv6 and/or DNSSEC by the “Internet giants” and the sense of urgency created globally would result in a massive push to deploy these technologies, and thereby make up for lost time. If these events did help the deployment of IPv6 / DNSSEC to take off, it is clear that we are far from the hoped-for tidal wave, even many years later.

Obstacles and Outlooks

IPv6 and DNSSEC face challenges of a similar nature to their widespread adoption. Sometimes presented as “new standards” with which “we must comply anyway sooner or later”, they leave the choice up to the players directly concerned and especially those who are not directly concerned to postpone the decision to deploy as long as possible.

The network’s players seem to have been in midstream for a long time. On the one hand, those who have deployed are struggling/slow to reap the expected return on investment and are experiencing growing frustration in not always being able to fully benefit from these “new technologies” and on the other hand, those who have still not deployed them, can still buy time and only “jump on the bandwagon” when it becomes imperative and urgent for everyone to do so.

Meanwhile, in no case must the former’s frustration be seen as a loss of motivation or despair. In other situations, when the objectives are not met, it is legitimate to consider “pausing a while”, “cutting losses” and/or “activating a (hypothetical) plan B”. But in the case of IPv6 and DNSSEC, the Internet community is unanimous: “we’ve got to do it!” Even if global deployment is taking much more time than expected, given the continued growth of the penetration rate of these technologies worldwide, it is clear that perseverance pays. To be convinced one need only visit some of the many websites that offer global or country-specific statistics that show the development over time of the level of deployment. For IPv6, the portal of the ISOC “Deploy360” program lists the Google site that shows the development of IPv6 penetration in users’ browsers querying the search engine, or the 6lab (Cisco) site, which integrates infrastructure indicators [prefixes, transit, autonomous systems (AS)]² and content, or the site of the Internet Resilience Observatory in France, where the development of IPv6 indicators (routing and DNS) has been monitored since 2011. In addition, the same Deploy 360 program (ISOC) compiles several benchmarks for global or country-specific DNSSEC statistics.

The outlooks for IPv6 are increasingly promising despite the delay, even though the technology is no longer listed among the trends of the moment (as shown in the recent editions of the “Gartner Hype Cycle for Emerging Technologies”, when IPv6 was at the top in 2006). Indeed, now that everyone has understood that IPv6 is neither a product nor a use in itself, attention is being focused on its power to enable new uses, once deployed.

When speaking for example about the Internet of Things, which now has its own “Gartner Hype Cycle”, IPv6 is often mentioned as a logical ally of IoT or even a prerequisite. But beware of confusion and quite common shortcuts! First, if the huge IPv6 address space can indeed assign an address to each object in the world, including the tens of billions of connected objects (from 20 to 50 billion according to forecasts) that may “invade us” over the next 5 years, only those who have the ability to “speak IP” to “deserve” one! I can already see coming the question: “Yes, okay, but still billions of objects will need to be connected with IP, right? And in this case, IPv4

residue will not make it, unlike IPv6, isn’t it?” In fact, the answer is not so simple. Just observe the current deployments that are almost only in IPv4. At the risk of disappointing the reader, the private address of IPv4 can (continue to) meet the addressing operators’ needs for the next 20 years if those continue to make choices for closed network architectures with centralized control and management (à la “Minitel”). However, IPv4 is clearly not a sustainable solution when we think of the need for making possible end-to-end communications between connected objects, typically through open and interoperable architectures. As a matter of fact, from this perspective of IPv6 that fosters innovation, notably “permissionless innovation”, the qualifier of enabler, takes on its full meaning.

Similarly, if 3G deployments are almost exclusively made in IPv4 (the botched “IPv6-UMTS” meet-up has never been caught up), for the more recent 4G deployments, certain mobile operators will increasingly “inject v6” (subject to a few transition mechanisms in terms of access), such as T-Mobile (USA) and Orange Poland. Geoff Huston said as much in fairly striking fashion at a recent presentation at the RIPE meeting 71, “An Update on Mobility in Today’s Internet” (cf. transparent #15 and video at [15:00 - 15:20]): ”[...] If the mobile industry doesn’t do v6, it’s not going to happen… That’s simple. Because, the mobile industry IS the Internet [...]”.

For DNSEC, several factors will determine whether its deployment accelerates in the coming years, or its overall slow pace is maintained worldwide, especially on the part of operators of recursive servers (resolvers). These cumulative factors include a possible increase in the level of the risk of attacks against which only this technology can help fight (such as by cache poisoning) or the maturity of application software services such as DANE (DNS-based Authentication of Named Entities), which uses DNSSEC as a PKI and is therefore vital for their operation.

No doubt when preparing to launch a new technology fully based on network effects, provision is necessarily made for interdependencies between the stakeholders concerned, often causing deadlocks, vicious circles and other chicken-and-egg types of problems. However, the most difficult task remains that of collectively developing a global strategy (by the “pioneers”) or individually (by the “followers”) and to implement it. As prerequisites (but which are unfortunately insufficient on their own), that strategy must:

• identify in advance the most significant obstacles that need to be overcome, preferably with a prior idea of their intensity and duration over time;
• propose multiple action levers (outreach, incentives, capacity building, etc.) depending on the stakeholders and obstacles to be overcome (or bypassed);
• convert the strategic levers into practical actions and schedule them according to a multi-year action plan;
• provide for regular assessment of the results and the feedback loop to revise the strategy if necessary (and that is often the case!).

In conclusion, until IPv6 and DNSSEC establish themselves (as I still hope they will, but as promised, I am making no more predictions about dates :-)), we not only need to continue our efforts in terms of outreach and instruction, but must also remember that all of the players must first of all “put their own house in order,” before asking others (legitimately or not) to fulfill their role. Better still, according to the well-known expression “Eat your own dog food”, even when you think you’ve done your job well, it is important to check its quality, in order to set the example.

¹ After many iterations, these specifications have undergone significant improvements, leading to stable standards for several years ([RFC 2460] for IPv6, in force since 1998 although some updates have been made to it over time, and [RFC 4033] [RFC 4034] [RFC 4035] for DNSSEC in force for over 10 years now, after a temporary switch to [RFC 2535] and related RFCs).
^ Back to the reference of the footnote

² It is noteworthy that Belgium, which was far behind other European countries barely 5 years ago, now occupies first place worldwide, with a combined penetration rate of 56% (as at January 3, 2016, with 44% on the user side, according to 6lab - Cisco). Conversely, France, which led the pack at the time (and became “famous for IPv6 in addition to its fine wine and cheese”), is now far behind (32% of deployment as at January 3, 2016, with only 6.5% on the user side).
^ Back to the reference of the footnote