In April 2011, the APNIC (the Regional Internet Registry for the Asia Pacific region) started allocating from its last /8. At the RIPE NCC we did not see a big jump in IPv4 address allocations in 2011, as anticipated by some observers.

The image below shows the total amount of IPv4 address space allocated each year (calculated as /16s on the y axis). You can see that in 2011 there was a drop in the amount of IPv4 address space from the previous year, bringing it down to the level of 2008 and 2009. There was no big run on the remaining IPv4 addresses.

Note that this does not correspond with the number of requests. Especially the number of requests for /21s increased in 2011 (you can find more on this in the background article on RIPE Labs).

IPv4 is certainly running out, but there is no great rush for the last addresses as feared by some. It was all pretty much "business as usual". As we've said in the past, predicting exactly when the RIPE NCC will run out of IPv4 address space is difficult. We cannot anticipate the size of requests we'll receive.

For more information and more statistics, please refer to IPv4 Allocation Statistics in 2011 on RIPE Labs.

Written by Daniel Karrenberg, Chief Scientist at the RIPE NCC

In this article, we want to present the efforts to keep the address space that is the responsibility of the RIPE NCC up to date and well maintained. When the RIPE NCC allocates addresses to a Local Internet Registry (LIR), the LIR is then the authorised holder and has responsibility for the registration and maintenance of all assignments it makes from this address range.

The RIPE NCC audit activity proactively checks the quality and validity of registry data, both in the internal records maintained by the LIRs and the public records in the RIPE Database. In 2011, approximately 400 audits were opened, which means that the LIR's records were reviewed and, if necessary, together with the LIR, corrected and updated. Taking into account that there are over 7,800 LIRs in the RIPE NCC service region, this might sound like a drop in the ocean. However, an LIR's registry data is also checked every time an LIR requests additional address space. This means that specific audits are carried out in addition to these regular checks and are often performed for LIRs that have not been in contact with the RIPE NCC for a longer period of time.

In the image below, you can see the type of issues that occurred during the audits in 2011. Note that multiple issues can be found in one audit.

During an audit, the following issues are typically found:

• Invalid records, such as:
  
  • more IP addresses registered than were approved
  • unapproved network names
  • missing network objects in the RIPE Database
• Overlapping assignments registered in the RIPE Database
• Resources returned
  
  • assigned PI or AS number resources are no longer valid or in use and are returned to the unused pool
• Internal records updated
  
  • Organisation contact data
• Assignment window (AW) abuse
  
  • if assignments are made that exceed the LIR's AW or are otherwise not compliant with the AW policy

The RIPE NCC works with the LIRs during an audit to assist in the resolution of any issues. An audit is closed only when all issues have been resolved or the audit is no longer relevant for other reasons, such as LIR closure, acquisition and so on.

Please refer to the 2011 Audit Results on RIPE Labs for a more detailed description of the audit activity and some other statistics.

Written by Mirjam Kuehne

We compile the data from all probes and build maps showing these results for each Atlas probe. In other words, the map shows the "gravitational radius" for root DNS server instances. This gives a unique insight into the client base for the root DNS operators. An example of such a map can be seen in Figure 1 below. The colour of the pin indicates the instance of K-root this particular probe is connecting to:

• Purple: AMS-IX (Amsterdam, The Netherlands)
• Green: DENIC (Frankfurt, Germany)
• Red: LINX (London, UK)
• Yellow: NAP (Miami, FL, US)
• White: JPNAP and DIX-IE (Tokyo, Japan)
• Blue: other (local) instances of K-root

On the map shown in Figure 2, you can see the results of the seven probes located in and around Berlin, Germany:

• Three connect to the K-root instance at AMS-IX in Amsterdam, the Netherlands (purple)
• Two connect to the K-root instance located at DENIC in Frankfurt, Germany (green)
• Two connect to the K-root instance located at LINX in London, UK (red)

This information can be useful for DNS root server operators as well as ISPs to determine whether there is room for improvement in terms of routing between end hosts (or rather, their DNS resolvers) and servers. This can result in reviewing of peering relations, or even deployment of new DNS root server instances.

We will make new visualisations available based on this data. We'll also make the data available to our users. More information on RIPE Atlas can be found at: http://labs/ripe/net/atlas.

Written by Daniel Karrenberg, Chief Scientist at the RIPE NCC

Amended Guidelines on GAC Advise

Before dissecting the IANA RFP language, one needs to begin with a side by side comparison of GAC's advice provisions contained in the Dakar Communiqué versus those provisions currently contained in the Applicant Guidebook. This comparison identifies the three classifications ("baskets") of advice the GAC is proposing to provide in connection with new gTLD applications, each of which is discussed in detail below.

For those readers with an institutional knowledge of ICANN's new gTLD program, particularly the 2000 proof-of-concept round, the use of the word "basket" is an intended pun on the ICANN Board's shopping basket reference during the 2000 selection process.

Basket One

The first basket is incredibly straightforward. When the GAC provides consensus advice that an application should not proceed, there is a strong presumption that the ICANN Board will not approve that application. If a new gTLD application falls into this basket, it is checkmate/game over for that applicant.

However, baskets two and three are where things get far more interesting as GAC advice on its face does not appear explicitly constrained to just consensus advice.

Basket Two

For this basket, the GAC has removed the text from the current Applicant Guidebook which states that this advice will not "create the presumption that the application should be denied" nor "require the Board to undertake the process for attempting to find a mutually acceptable solution with the GAC should the application be approved." Instead, the alternative language requires the ICANN Board "to enter into dialog with the GAC to understand the scope of concerns." This broader remit on its face is absent of any limitation of how such advice should be submitted by the GAC or received by the Board. The ability for this type of GAC advice to potentially block a new gTLD application becomes much clearer within the context of the IANA RFP language.

Basket Three

The third type of advice that the GAC can provide is in connection with applications that require remediation. The current guidebook appears to limit remediation to methods specified in the guidebook, and state the fact that material amendments to applications are generally prohibited, and that if no remediation method is available the application will not go forward and the applicant can re-apply in the second round. However, the proposed alternative text which the GAC has provided removes the apparent limitation on material amendments and the requirement that applicants re-apply in the second round. The proposed wording by GAC regarding this type of advice appears to leave open the option for future remediation methods to be added to Guidebook during the pendency of the application process. In fact this is exactly what happened in connection with the .ASIA and .CAT gTLD applications in the 2004 round to address GAC concerns.

Although most have feared GAC advice as serving as a higher bar to potential gTLD applications from being approved, this basket of advice on its face appears designed to allow remediation (and or material amendments) of applications that ICANN staff initially preferred to push toward the second round.

Those Who Fail to Learn From History Are Doomed to Repeat It

To properly interpret how GAC advice in connection with new gTLDs will be interpreted, it is constructive to revisit the GAC advice in connection with the ICM Registry application for the XXX domain name. Although there were some within the GAC that were seeking a consensus statement against the approval of the ICM Registry application (Basket 1), the GAC was only able to achieve consensus on the following advice:

• There is no active support of the GAC for the introduction of a .xxx TLD.
• While there are members, which neither endorse nor oppose the introduction of a .xxx TLD, others are emphatically opposed from a public policy perspective to the introduction of a .xxx TLD

Despite this clear advice expressing no support for the ICM Registry application, the ICANN Board decided to approve it absent any clear consensus advice from the GAC to reject it. This was a learning moment for the GAC and when coupling the Dakar communiqué with the current IANA RFP, one can see that the GAC now has the means to ensure that it its advice is never misinterpreted again.

Changes in the IANA Statement of Work (SOW)

When the USG issued the IANA Further Notice of Inquiry (FNOI) this past summer there was a proposed requirement in section C.2.2.1.3.2 pretaining to new gTLDs that would have required the contractor to document "how the proposed string has received consensus support from relevant stakeholders and is supported by the global public interest." However, the revised IANA RFP contained the following language;

the Contractor must provide documentation verifying that ICANN followed its own policy framework including specific documentation demonstrating how the process provided the opportunity for input from relevant stakeholders and was supportive of the global public interest.

While some people touted the removal of the language regarding documenting "consensus support from relevant stakeholders" as a win for ICANN, for the reasons set forth below this change in the language actually represents a coup for the USG and GAC.

Consensus is in the Eye of the Beholder

The problem with proving or disproving consensus is that it has different meanings to different communities. In the private sector consensus is broadly defined as general agreement (not unanimity) among a group of participants, which is different from consensus within an intergovernmental body. Per the GAC Dakar advice, "consensus is understood to mean the practice of adopting decisions by general agreement in the absence of any formal objection." Simply put, if a government is not happy and continues to make interventions on a issue, consensus cannot be achieved.

Public Sector Consensus versus Private Sector Consensus

Under the original IANA SOW the legal obligation was for the Contractor (ICANN) to "include documentation to demonstrate how the proposed string has received consensus support from relevant stakeholders and is supported by the global public interest." As noted above since consensus was never defined, there was a potential ambiguity in what definition of consensus should be applied. This ambiguity actually worked to ICANN's favor as it would have been able to document and provide a factual basis for its consensus finding. The burden of proof would have then fallen on the shoulders of the USG as the moving party to disprove consensus in order to reject the delegation of a new gTLD. In the ever increasing political internet governance debate, the USG did not want to have its finger prints on the smoking gun that killed a gTLD application.

In the published IANA RFP, the potential ambiguity of the consensus requirement has been removed. Instead, the legal requirement now imposed upon the Contractor (ICANN) in making "a delegation or redelegation recommendation" is to "provide documentation verifying that ICANN followed its own policy framework including specific documentation demonstrating how the process provided the opportunity for input from relevant stakeholders and was supportive of the global public interest." While some will argue that the removal of the specific text "the proposed string" from the draft SOW in the FNOI points to the Contractor only needing to document the "global public interest" with regard to the new gTLD program. However, that argument is difficult to reconcile with the actual words of the IANA RFP and current IANA practices.

The IANA RFP text requiring the Contractor to provide documentation appears in the sentence beginning with a reference to a delegation or redelegation recommendation. The current IANA practice is only to make new gTLD delegation request per each unique string; therefore it is reasonably to imply that that the documentation requirement is per each gTLD string request and not to the ICANN policy as a whole.

While this broader policy documentation requirement might have been consistent with the IANA standard operating procedures in 2000 when ICANN issued a single IANA report for both the .INFO and .BIZ gTLDs, the trend since then has been to provide increasing levels of factual detail in each new gTLD delegation request. By way of example, the .ASIA, .CAT and .XXX IANA delegation reports each document a detail list of actions taken to address GAC concerns that went above and beyond just a mere summary of the gTLD process.

Global Public Interest versus Public Policy

While the USG removed one potential ambiguity in defining consensus, the perhaps more difficult task of defining the "global public interest" remained. In fact US Senator John Rockefeller IV appears to be struggling with the same issue, as evidence by his recent correspondence to the Department of Commerce asking for clarification as to "what evaluation criteria a contractor should consider to determine whether a generic top level domain is supported by the global public interest." While there may be many potential opinions as to what is the authority body/standard to answer this question, it is respectfully submitted that within ICANN the GAC is the most authoritative body to speak on this issue. In addition to numerous citations in the ICANN bylaws regarding the role of the GAC in connection with public policy issues, the GAC provided a timely reminder to ICANN of the important role that it plays in its Dakar communiqué:

ICANN's Governmental Advisory Committee was formed to consider and provide advice on the activities of ICANN as they relate to concerns of governments, particularly matters where there may be an interaction between ICANN's policies and various laws and international agreements or where they may affect public policy issues. (emphasis added)

While there will be many within the ICANN community that will vehemently reject this potential interpretation of this IANA RFP provision, the only two entities that really matter are the USG and the GAC and how they define that phase.

GAC Veto

To better understand how this new standard might be applied; consider a scenario where the GAC was to provide advice similar to the one that it provided in connection with ICM Registry application, e.g. "there is no active support within the GAC that [dot-example] is in the global public interest." It would appear on its face that it would be checkmate/game over that gTLD applicant. As it is hard to conceive how the ICANN Board would be able to document "global public interest" to supersede this GAC advice.

In connection with the ICM Registry decision, the ICANN Board was briefed of its legal obligations under the bylaws, and how it could disregard GAC advice. However, in the scenario outlined above this bylaw provision permitting the ICANN Board to disregard GAC advice does not exist, as the legal burden to document "global public policy" rests solely as a contractual obligation to the USG in the IANA contract.

Also lost on most commentators is the fact the USG and the GAC have potentially increased their scope of review in providing "global public policy." No longer is the burden imposed upon the Contractor (ICANN) solely in connection with new gTLD delegation requests, but now it also involves redelegation requests as well.

Which Came First the Chicken or the Egg

Over the course of the past year the USG had become quite adept at releasing major publications or statements in advance of major ICANN events. However, it was initially somewhat of a surprise that the only announcement released prior to the Dakar meeting was a Presolicitation Notice that the IANA RFP would be issued on or about 4 November 2011. However, it was not until 10 November 2011 that the IANA RFP was issued suggesting that there may have been some material changes made to the IANA RFP based upon the feedback from the ICANN Dakar meeting. In fact given the recent release of an amended IANA RFP on 17 November 2011, it appears that the USG is not done tweaking the IANA RFP to achieve its desired goal.

Bylaw Rewrite

I have previously advocated amending the ICANN bylaws to put GAC advice on equal footing as a GNSO Supermajority vote. However, the GAC Dakar communiqué and the proposed IANA RFP appear on their face to have gone above and beyond a bylaw revision and superseded the ability of the ICANN Board to disregard GAC advice on global public policy in connection with gTLD delegation and redelegation issues. While many new gTLD applicants have expressed reservation about having to waive all types of legal rights against ICANN for the privilege of apply for a new gTLD, it appears that ICANN is getting a dose of its own medicine by the USG imposing a list of requirement that are rather take or leave it if ICANN wishes to remain the Contractor of the IANA functions. It seems that turn-around is fair play.

Mind the GAC

The GAC communicated to the ICANN Board in Dakar its concerns of providing early warning advice in connection with potential a substantially large number of new gTLD applications in such a short period of time, noting that ICANN had reserved itself the ability to batch applications in groups of five hundred. If the ICANN Board would like to prevent an initial GAC Early Warning communication noting genuine global public policy concerns involving a long laundry list of gTLD applications that have not been able to be fully resolved due to a short period of time, ICANN should be working on a way to address the valid concerns of the GAC expressed in Dakar.

Some critics will undoubtedly dismiss this article as placating to the GAC, or a last gasp attempt to interfere with the roll-out of the new gTLD process. Unfortunately these individuals are missing the much bigger picture of a fundamental paradigm shift within the power base of ICANN. During a recent presentation to a group of registration authorities in June I provided a presentation that included the following text: "[t]he GAC sleeping bear has been awoken; will it go back into hibernation or will it go on a feeding frenzy to bulk up." For anyone that may have missed Dakar just ask the registrars if they believe the GAC will be going back into hibernation anytime soon.

Written by Michael D. Palage, Intellectual Property Attorney and IT Consultant

When looking at IPv6 deployment at the LIR level, we can look at the following two metrics:

• The percentage of LIRs that have IPv6 address space (currently at 47%) and;
• What percentage of LIRs has IPv6 address space that is visible in the global routing table (currently at 29%).

What these numbers don't take into account is the sizes of the LIRs. For billing purposes, LIRs are divided into size categories based on the IP address space they hold and a number of other factors. We used these size categories when producing statistics such as these. Taking this one step further we can use the size of the LIRs as a weight to normalise deployment metrics. We took the total IPv4 address space held by an LIR as a good indication for the LIR's size, and took a fresh look at IPv6 deployment metrics taking LIR size into account.

We used "treemaps" to visualise this. In the images below, each country is represented by a rectangle. The size of these rectangles is based on the number of IPv4 addresses in the country. Each of these country rectangles is again divided into smaller rectangles, each of those representing one LIR. The size of the LIR's rectangles is based on the amount of the IPv4 address space held by this LIR.

The light green rectangles represent LIRs that have an IPv6 allocation or assignment, while the black rectangles represent LIRs without IPv6 address space. Note that there are some dark green rectangles. Those represent LIRs that we know will receive IPv6 addresses from another LIR belonging to the same organisation.

In the treemap in Figure 2, light green rectangles represent LIRs that have IPv6 address space visible in the global routing table, while the black rectangles represent LIRs that have IPv6 address space that isn't yet routed.

If we look at this numerically, we see that 47% of all LIRs hold IPv6 address space. If we weigh in the size of the LIR (as described above), this is even higher: 81%. In other words: 81% of IPv4 address space in the RIPE NCC service region is held by an LIR that also holds IPv6 address space (note: This doesn't take into account those organisations that maintain multiple LIRs with one of them holding IPv6 space — the dark green fields in Figure 1).

If we look at the underlying numbers of Figure 2, we can see that 29% of LIRs have one or more IPv6 prefixes visible in the global routing table. When we apply the weighting this becomes 63%. In other words: 63% of IPv4 address space in the RIPE NCC service region is with an LIR that holds IPv6 address space that is also routed.

Having 81% of IPv4 address space with LIRs that also took the first step in deploying IPv6 is an encouraging sign. But it is in stark contrast with statistics showing IPv6 deployment at End User sites (0.39% according to Google, roughly 2% at www.ripe.net), or statistics showing IPv6 traffic (0.3% at AMS-IX). This shows that a large majority of IPv4 address space holders in the RIPE NCC service region have taken the first steps but the work towards full dual-stack deployment, and later an IPv6-only network, is far from finished.

Please refer to the background article on RIPE Labs: Interesting Graph – IPv6 per LIR.

Written by Mirjam Kuehne

ANA's letter in full available here. ANA is holding a webinar on the proposed ICANN TLD program tomorrow, October 4, at 3 PM.

Also related blog by Kevin Murphy at DomainIncite: Would an ICANN ethics policy break the law?

First contact

Over four years ago the first contact between OPTA (the Dutch telecoms and post regulator) and the RIPE NCC was laid. It was an awkward meeting of two groups of people who were talking to each other, but didn't connect at any level. Around the same time RIPE NCC got into contact with LEAs that had an urgent need for accurate information in cybercrime investigations and was confronted with a growing number of requests for information. All this culminated in invitations participate in the Government Roundtable meetings for LEAs, including a special meeting aside.

From misconceptions to dialogue

At the first meeting in 2008 it was clear that there were several misconceptions on both sides as to content and purpose. There was a distinct tension between both parties and an expressed urgency on the side of the LEAs, which made dialogue hard to establish. What happened however, was that the friction built up during the first meeting was taken away by discussing possible future approaches. An agenda of topics was identified and an invitation formulated to continue the discussion. This led over the course of 2009 to the invitation to participate in respective relevant events. OPTA and representatives of cybercrime units presented at RIPE meetings, while RIPE NCC presented at the London Action Plan, the e-crime event in London and in the EU Cyber Crime Task Force. Relevant knowledge and information was shared between both sides.

Understanding each other's positions

This made a few things clear to participants. Law Enforcement officers learned to understand about policy processes within the RIPE community and that the only way to influence these processes is to participate and address the right people. Also they learned what sort of organisation RIPE NCC is and the sort of information she has on its members and the Internet in general. What of this information is public and what is private sensitive data. RIPE and RIPE NCC learned that (governments and) LEAs have legitimate concerns about the safety and security of the Internet and need accurate information on LIRs for investigating criminality or spam violations. But most probably also that they have no use for members that do not pay their bills and are untraceable as well as that it is not good for reputation when RIPE NCC is, no matter how unwillingly, associated with (organised) crime, which unfortunately, in very small numbers, was the case. This awareness caused RIPE NCC to look at her standards and procedures and alter them when deemed necessary, which is a great claim for self-governance.

Cooperation is successful

The reaching out led to the installation of the Cyber Crime Working Party in May 2010. In the CCWP LEAs, the Anti-Abuse Working Group of RIPE and LEAs share data and work together. The biggest challenge for law enforcement agencies is to dedicate resources to cooperation and participation, that do not immediately show a result in facts and figures presentable to the outside world. The figures presented by RIPE NCC on 12 September, as well as recent presentations by ARIN and AfriNIC, show that cooperation does pay off, but needs time to develop. On both sides! So use the figures within your respective organisations and make sure that this raises the awareness of the right people there.

As CCWP chair I complemented RIPE NCC with these results and noted that we have come a long way over the past few years. There is more to be done, but this moment of reflection is as good as any.

Written by Wout de Natris, Consultant international cooperation cyber crime + trainer spam enforcement

But not all of this history is a story of unqualified success. The telephone industry's visions of broadband data networking represented some pretty poor technology choices. I would not describe ISDN as an unqualified success, and the efforts to construct a useful broadband data infrastructure using ATM as the ubiquitous substrate was not exactly a high point for this industry. And many of the recent successes in this industry have come as a complete surprise. Nobody in the industry expected that SMS would be used at all, let alone become so popular. The SMS user interface on traditional numeric keypads was about as unfriendly as one can imagine and the limited message length was incredibly limiting. Why would anyone want to use it? Yet they did, in the millions!

SMS was not the only surprising success for this industry. The Internet itself came as a complete surprise to the traditional telco industry of the time. Indeed, the success of the Internet probably came as somewhat of a shock to the early developers of the Internet as well, given that the mantra of the early days of the Internet was that this was an "experiment" undertaken within the academic and research sector that would be useful to seed ideas for subsequent broadband data networking within the far larger telecommunications industry. It may have been a wistful thought, but it was never the firm intention that this particular exercise in network research was to inherit the load of the entire global telecommunications infrastructure. It just happened that way, and it was surprising to everyone.

So the telecommunications industry gets things wrong just as easily as it can get things right. In many ways the size of the industry is no indicator of its ability to make astute technology choices. Being large, and commanding vast resources in terms of workforce and capital does not necessarily help in making the right decisions. Some argue that it increases the probability of getting it wrong!

This then brings me onto the obvious question: How will this industry manage the transition from IPv4 to IPv6? Will it be successful? Or will our children assign this exercise to the top shelf of the industry's record of failures?

When I've posed this question to my colleagues, I've received a mixed set of reactions, but the most common reaction is one that simply asks why we need to worry about this question at all. Surely, they say, IPv6 is simply inevitable, and this is just a matter of sitting back and watching it happen. The exhaustion of the entire IPv4 address pool is inevitable, and the increased industry pressures from IPv4 address scarcity, including escalating pricing for IPv4 addresses in an address after-market all serve as drivers for IPv6 adoption. The higher the IPv4 price goes, the greater the incentive for IP service providers to seek relief by migrating their customers into IPv6. All of this process of transition is just inevitable, and there is simply no need to worry.

It's all very reassuring, but I'm not sure that it is convincing. I'd like to look at this proposition in a bit more detail and look at whether IPv6 is an inevitable outcome of IPv4 exhaustion, or whether we should worry, even just a little, about what is going on with this transition.

Technology Transition

When we look back at previous technology transitions in our industry, they all look just so logical. The early telephone networks used a dedicated pair of conductors to carry a single conversation. Scaling the telephone networks of the late nineteenth century was a matter more of the logistics of putting more and more copper wires up on poles in the cities, and the scarcity factors were centered around the limits to the number of discrete wires that could be hung from single poles that any other factors. The key technological innovation was the concept of replacing a physical electrical circuit with a virtual circuit. A number of these virtual circuits could be placed on a single conductor pair through frequency division multiplexing, in exactly the same way that multiple radio stations coexist in the spectrum space. The switching elements between trunks was augmented with electrical oscillators and now a single conductor could carry hundreds of telephone conversations simultaneously. The virtual circuit model was further refined in response to more sophisticated electronic capability, and the second generation of virtual circuitry was constructed using a conversion of the analogue conversation to a digital data stream, and replacing the frequency division multiplexing technique with time division multiplexing. Again, in retrospect it all looks so logical and so inevitable.

Even the transition from circuit to packet switching looks like an inevitable progression in retrospect. Instead of the network providing a constant time base for the transmitted data, the data unit itself carries sufficient information to allow each switching point to direct the data element towards its destination, and the sequence and timing information is pushed deeper into the data frame to become part of the end-to-end information stream, rather than trying to force the network into preserving timing and sequencing. These changes allow networks to be constructed in ways that are both faster and cheaper. And a combination of a technology shift that produces both financial and service opportunities is often irresistible.

What about the transition from IPv4 to IPv6? Is this also an inevitable transition? There is no doubt that the designers of IPv6 certainly envisaged this as an inevitable transition. But there are some challenges here.

The first is that the transition does not provide for backwards compatibility. A host cannot switch from using IPv4 to IPv6 and still communicate with all the hosts still using IPv4. So the transition has an essential "dual stack" phase where, during the transition, hosts operate with both protocol stacks concurrently, using the IPv6 protocol stack to speak to other IPv6 hosts and the IPv4 protocol stack to speak to other IPv4 hosts. This lack of backwards compatibility in IPv6 makes the transition slightly more complex, but not prohibitively so. What it means is that applications and host operating systems need to be aware of IPv6 and explicitly have capabilities to use IPv6. It's not a seamless augmentation at the application interface level.

There an additional challenge here that is formidable, and one that was largely unforeseen when IPv6 was being designed. At the time there was the general impression that the telecommunications industry behaved prudently, and given the warnings of the prospect of exhaustion of the IPv4 address space, industry actors, being prudent and risk averse, would embark on the transition to IPv6 well in advance of IPv4 address exhaustion. And one or two did. But everyone else did not. And now we have the challenge of trying to undertake this dual stack transition while one stack is critically short of further address space. This factor radically alters the dynamics of the transition. In order to make the IPv4 part of the transition work for the requisite number of additional years it will be necessary to deploy additional "middleware" in the network, and head in a different direction architecturally.

The most obvious shift is probably going to be one of deployment of Carrier Grade NATs (CGNs) in access networks. This will allow a single public IPv4 address to be shared across multiple end clients. The longer the transition takes the more likely that this alone will not be sufficient, and we may expect to see a push to re-architect content into Content Distribution Networks that have points of presence in major access networks. It is also possible that network providers may resort to Application Level Gateways (ALGs) and managed services in an effort to further contain the level of IPv4 address and port consumption by user services.

The risk here is that after making this additional capital investment in network infrastructure, the network service provider is then highly motivated to protect the value of this investment. What lengths will network service providers be prepared to go to in order to protect this investment in transitional services? And if these transitional services generate higher revenues for the network service provider than basic commodity packet transit services, to what extent is the network service provider then motivated to lock itself into this "transitional" service model for an extended period? Would this imply that rather than being a transitory state we see these changes to the network lasting for an indefinite period.

If one sector of the industry finds that this transitional model of providing services sufficiently attractive, is it possible that it could have sufficient market influence such the entire service provider industry collectively locks into this "transitional" model as an enduring service model? If this was to eventuate the internet would be driven in an entirely different direction than IPv6!

Challenges to Transition

Is it possible to manage this level of risk in the transition, and thereby ensure that this industry is not distracted by attempting to optimize what was intended to be a transitory phase of network transition. What can be done to ensure that this industry maintains collective focus on an IPv6 network as the objective of this exercise?

To try to assess the feasibility of such an approach it is useful to try and understand the collective pressures that are working against such an outcome.

There is no plan!

The first is that this is a deregulated and highly competitive environment. There is no single industry and no single "either/or" decision, but instead there are many different parts to this industry and each actor has their own perspective on the situation. Over the course of the transition it is likely that many different approaches will be explored by a diverse collection of industry actors. Any visible collective outcome of this process is not necessarily the outcome of a particular plan, but more likely to be the outcome of the interplay of various market pressures.

If the hope here is that there is some overall plan of a coordinated response to IPv4 exhaustion and the associated transition to IPv6, then it is useful to bear in mind that there really is no plan at all, and all we have instead is the interplay of market pressures and their outcome.

We are not experiencing the same pressures at the same time!

The second issue is related to the regional structure of the RIRs and the timelines of IPv4 address exhaustion.

In the Asia Pacific region APNIC ceased its IPv4 allocation function on the 19th April 2011, at which point the registry had 16,777,216 addresses left in its local pool. APNIC has now switched to its "last /8 allocation policy", which allows each requestor access to only one allocation of up to 1024 addresses and no more. In effect APNIC has "run out".

APNIC's IPv4 Address Allocations – 2008 to present

The state of the other RIRs is not quite the same. The following table shows the amount of available addresses in all the RIRs, using units of a "/8" (or 16,777,216 individual addresses).

RIR	Projected Exhaustion Date	Remaining Addresses in >RIR Pool (/8s)
APNIC	19-Apr-2011	1.2044
RIPENCC	29-Feb-2012	3.4683
LACNIC	19-Mar-2014	4.4370
AFRINIC	04-May-2014	4.3840
ARIN	26-May-2014	5.9743

These predictions are based on a weighted least squares best fit of an O(2) polynomial function over the past 3 years of allocations.

RIRs' IPv4 Address Allocations – 2008 to present

In the North American region, the local regional registry, ARIN, changed its general IPv4 address allocation policy in February 2011, coinciding with the exhaustion of the IANA-managed pool of addresses. Surprisingly, when this recent address consumption data is used to generate a prediction model for addresses, it appears that ARIN will not reach its final /8 until sometime in 2017. However I am somewhat wary of such a prediction, given the significant uncertainties that it encompasses.

Modified ARIN Exhaustion Model – 2011 to present

The situation we face today is that APNIC and the Asia Pacific region is already operating under circumstances where addresses are not abundant. However, other regions are still able to distribute IPv4 addresses. For other regions the concept of IPv4 exhaustion is a "future" problem rather than a "here and now" problem, and there is still a pervasive air of denial in many parts of the industry in those regions of the world where address exhaustion has not occurred yet. I'm reminded of the observation that: "It's not happening unless it's happening to me!"

We are not united with a common purpose!

From these two pressures comes the third consideration, namely the variation in the transition process.

The challenge we face is to sustain the IPv4 half of the dual stack environment in the face of continuing escalation of demand for addresses. For many years the conventional networking environment has included the use of a NAT device at the interface between the network and the user. Increased pressure on addresses is now forcing network service providers to place a second level of NAT inside their network as part of the network infrastructure.

This process of transition is expected to take many years, I have heard commentary to suggest that five years is unrealistically short, and we should expect a transition that may take a decade or longer. But will CGNs last for a further decade of network growth during this extended transition? The next step after CGNs is to break apart the end-to-end network model and start to erect connectivity "barriers" or "walled gardens". The tools to do this include re-homing a copy of certain content "inside" the network as a next step, then, as a further step in address 'compression', using application level gateways rather than address level IP header translators.

The current approach to IPv4 exhaustion will see different regions experiencing different IPv4 scarcity pressures at any point in time. In the Asia Pacific Region the momentum to deploy CGNs as the first response to IPv4 address scarcity is already visible. However, other regions are not experiencing the same pressure at this time. If one were to project this further forward by 18 months to 2013 the European region would also have exhausted its pool of IPv4 addresses, but the other three regions may well be operating in a mode that is still able to meet regional demands for IPv4 addresses. It is highly likely that at that time the different regions will be experiencing very different market pressures for the provision of Internet services, due to differing transitional pressures from IPv4 exhaustion.

The consequent question is: What's the level of risk that the differing environments of transition lead to significantly different outcomes in each region as the process of transition takes of a different momentum in different regions? And if this eventuates will we still have a single coherent Internet as a common asset, or will we find that market forces interact in unpredictable ways that create different outcomes in each region?

What of the plan to ultimately converge to an IPv6 network? It may be useful to remember the myth of the long term plan. Are we still as firmly committed to the long term plans we formulated 5 or 10 years ago? Or have we found that our plans are continually modified and refined over time, and there is actually little left of the original plan. So will we be as firmly committed to the transition to IPv6 in five years time? Or will we manage to lose the plot and head into different directions because of the different spread of pressures on service providers in each of the regions. We will forget about the intention to preserve the concept of a single global network in amidst the difficulties of this disparate transition?

On Maintaining the Momentum for IPv6

Can we help the Internet during this transition, and try to ensure that the Internet remains a single coherent network with some essential architectural attributes of end-to-end clarity? Or, if we want to aim a little lower, can we at least minimize the potential for disastrous long term damage to this phenomenally productive and valuable networking environment that the Internet has enabled?

I don't know the answer to those questions, but I would like to offer a small number of thoughts that I have had when thinking about this topic.

If we want a single working Internet at the end of all of this, then we need to keep an eye on the larger picture of network evolution during transition. We need to find ways for self interest and local interest to converge with what is in our common interest. Without that convergence we will see a form of market failure where the common interest of a single global network, and the value that such a service can generate, being lost to network divergence through the exercise of differing local market pressures. I'm not sure that I understand how to ensure that self interest aligns with common interest in every circumstance, but what would be good to avoid is building a network that imposes major barriers and inefficiencies all in the name of address conservation in IPv4, and then citing the investment in this additional infrastructure as grounds for not progressing with the transition to IPv6.

Secondly, IPv4 addresses should be used in working networks and not hoarded. Its probably a natural reaction to impending scarcity to hoard a resource, but its not necessarily a good reaction. Hoarding behaviour exacerbates the scarcity of the resource in both its intensity and duration. This generalization is also true in the specific context of IPv4 exhaustion and transition. The scarcity of IPv4 addresses creates market uncertainty and market pain in the form of a reduced revenue outlook across the transition period. Extending this scarcity through hoarding and other forms of witholding addresses from use in the network acts to prolong the market pain and increase the unpredictability of the entire transition process.

And finally, we need to keep the transition as quick as possible. A rapid transition represents the best chance of achieving an IPv6 network as an outcome of this process. The more time we spend investing time, money and effort in deploying IPv4 address extension mechanisms, the higher the risk that we will lose track of the temporary nature of transition and the higher the possibility that we'll get stuck with the wrong Internet at the end! If we are truly committed to achieving a single and coherent IPv6 Internet then perhaps its necessary to act now to compress the timelines for transition, not extend them!

Written by Geoff Huston, Author & Chief Scientist at APNIC

IP address space is a finite public resource. Traditionally, folk who need IP addresses fill in a simple form documenting how current addresses are used and explaining how the requested IPs will be used. It's a simple process that takes a few minutes to complete, and even less time to process. Having been a Hostmaster at one of the RIRs, I have some experience in this area. Back in the very early days of the IANA, requirements were even more simple and many organisations got lots more IPs than they could actually use due to the classfull nature of addressing at the time. These early Allocations are often called "legacy space", as they were made prior to the formation of the RIR system as we know it.

There seems to be a vocal minority clamoring for the removal of this needs requirement in some of the RIR regions, some of whom are undoubtedly hoping to profit from the sale of IP addresses, while others seem to be guided by free-market philosophies. Unfortunately, neither motivation seems to advance the public interest in IP address distribution, despite their rhetoric to the contrary.

If organisations were allowed to obtain IP blocks from the RIRs (or from other companies) without first demonstrating that they needed them, the Internet would have run out of IPv4 long ago. This would obviously not have been in the public interest, as Internet growth would have stagnated.

Recently, we have seen the Internetgovernanceproject blogging about this issue and they talk about the needs requirement as a "barrier to trade". While this may be the case, a much bigger and more damaging barrier to would be erected if folk were allowed to flog their IP resources (legacy or not) to the highest bidder without any regard for Internet resource stewardship. In the theoretical case that IGP raises, where Asian companies looking for more addresses than they think they can get from their RIR are eyeing legacy IP blocks. IGP seems to think that such organisation should be able to buy legacy blocks without demonstrating that they actually need these resources. In other words, the companies who have the most cash "wins", which is not a philosophy normally associated with public interest outcomes. Many in the RIR policy communities are concerned that this will lead to hoarding and speculation, driving up the cost of doing business for all while enriching the few.

The current RIR system works incredibly well. It is the most respected part of the ICANN system in terms of openness, transparency and true bottom uppity-ness. Normally, IGP decries the heavy influence in ICANN processes by monied interests, but in this case, they seem to be cheerleading for the monied interests due to some deep seated Ayn Rand-ian laissez faire-ness. Inexplicable really, but I digress.

Now that we are faced with the impending run out of IPv4, several RIR policy communities are placing greater restrictions on allocation and assignments as a natural reaction the coming shortage. For example, in the AfriNIC region, consensus was reached at the last AfriNIC meeting on a "Soft Landing" policy, which is now in Last Call. Amongst other things, this policy specifically states that resources allocated to the AfriNIC region are meant to be used in the region, thus precluding inter-region transfers.

Currently the APNIC community is in the process of restoring the justification of need for transfers, which was relaxed just last year.

Asking folk why they need a certain number of addresses has worked to prevent hoarding and speculation of Internet resources for many years. It is even more important now that we are running low on the supply side of IPv4. RIR policies are set by groups of people working together to reach consensus positions. Asking that we allow the "Invisible Hand" to determine policies going forward is not responsible stewardship, it's just crass commercialism.

Written by McTim, Co-Chair of the African Network Information Center Policy Development WG

Read full story: Reuters

Since March 2011, the RIPE NCC has been publishing the size of its pool of available IPv4 addresses. All five Regional Internet Registries (RIRs) regularly publish the status of their IPv4 address pools. In the image below, you can see how the number of IPv4 addresses in the RIPE NCC pool changes over time.

The graph is updated weekly and is adjusted up or down as IPv4 addresses are distributed and returned. Currently, around 4.5 /8s (76 million IPv4 addresses) are still available, with a stable decrease of less than 1 million addresses on average per week over the last three months. A run-out-fairly policy was implemented to ensure a gradual reduction of the allocation and assignment periods. This ensures a fair distribution of the remaining address space.

The graph also includes the 12.58 million IPv4 addresses temporarily set aside for the De-Bogonising New Address Blocks project. Under this project, pilot prefixes are announced to improve the routability of new address blocks. This is done only before real production prefixes are announced from the new block.

The last /8 that the RIPE NCC received from the IANA on 3 February 2011 is included in this graph and is shown by the yellow horizontal line. This last /8 will be allocated according to section 5.6 of the IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region. Each Local Internet Registry (LIR) can receive one /22 allocation from the last /8 to ensure that new LIRs can still get IPv4 address space in the future. To receive this allocation, the LIR must have an IPv6 allocation to prepare for the coming transition to IPv6.

The RIPE NCC available pool graph can also be found on the RIPE NCC website.

Written by Mirjam Kuehne

RIPE Labs graph looks at IPv6 RIPEness rate of all countries in the RIPE NCC service region as measured in May 2011. (Click to Enlarge)

• The LIR gets one star if it has an IPv6 allocation

Additional stars can be earned if,

• The address prefix is routed on the Internet
• A route6 object is registered in the RIPE Database
• Reverse DNS has been set up

In an earlier post on CircleID, "IPv6 RIPEness: the hard numbers on ISPs and Deployment Rates", published in April 2010, we saw that:

• 27% of all LIRs (6,748 at the time) had IPv6 address space (one star), and
• 8% of all LIRs (or a total of 540) had all four stars

Now, one year later, the numbers have gone up:

• 41% of all LIRs have IPv6 address space, and
• 13% have all four stars

In absolute numbers: more than 3,000 LIRs have IPv6 address space. This means that the RIPE NCC has made more than 1,100 IPv6 allocations within 12 months.

It is also interesting to look at the development in some countries:

• Slovenia is still the winner: More than 80% of all LIRs in that country have an IPv6 allocation, and almost half of them have all four stars
• Armenia is now second on the list: 72% of all LIRs have an IPv6 allocation (45% last year)

You might notice that some countries that had at least one or two stars previously now show no IPv6 RIPEness anymore. This is due to mergers or closures of LIRs in these countries and does not mean that IPv6 address space has been returned or revoked.

Even though we are happy to see progress, many LIRs have not yet requested IPv6 address space from the RIPE NCC. We hope that the IPv6 RIPEness system is helping to encourage LIRs to deploy IPv6. Note that all LIRs that reach all four stars receive free t-shirts and now also an IPv6-enabled fridge magnet from the RIPE NCC :)

For more background information, please refer to the article on RIPE Labs: IPv6 RIPEness — One Year Later.

Written by Daniel Karrenberg, Chief Scientist at the RIPE NCC

The court's order (found here) was signed without objection at a hearing attended by representatives from Nortel, Microsoft (GFS), ARIN, Addrex, various creditors and observers. It specifically authorizes the sale of various IPv4 address blocks, totaling 666,624 individual IPv4 Internet Numbers, for USD $7.5M (or $11.25 each). The sale agreement, filed with the court and approved by this order, identifies the seller's "exclusive rights to use and transfer" the Internet Numbers. The sale agreement also states that Microsoft, as the buyer, has agreed to enter into a Legacy Registry Services Agreement (LRSA) with ARIN. As a result we now have an example of Specified Transfer based, more or less, upon ARIN's Number Resource Policy Manual (NRPM) section 8.3. This is the beginning of a legal structure for recognizing IP addresses as a form of property and a template for future transactions in the ARIN region.

Of course, there are still open questions. For instance, the actual LRSA side-agreement entered into by Microsoft was not disclosed to the court. At this time we don't know what ARIN and Microsoft agreed or how it compares to the standard LRSA that others have signed. Also, there is no indication that a RSA is required for a legal transfer, only that ARIN requires a RSA as a condition of updating their Whois database. The court did not require the RSA, or any arbitrary terms of the sale agreement - it merely accepted the agreement negotiated between Nortel and Microsoft. Effectively, any question about whether a RSA is required has been postponed until a later date because Microsoft has agreed to sign a LRSA with ARIN. And there are questions about Microsoft's "justification of need", with regards to the ARIN transfer policy requirement. ARIN has stated that Microsoft did justify need and qualify for the transfer, but this raises a question about why Microsoft chose to buy these addresses rather than receive them as a direct allocation from ARIN.

Because of open questions such as these, we don't know what complexities might exist for future sales. One challenging area will be inter-regional sales of legacy blocks. These may be more politically sensitive, for instance, depending on who the buyer is. And there will almost certainly be open issues with inter-RIR cooperation. For example, these transfers may be economically complex, now that the APNIC region is under the "final /8" policies (announcement) and transfers no longer require justification of need.

As more IPv4 addresses enter the market (including Nortel's legacy /8 block) the community should pay close attention, and work to answer these questions proactively. A robust address market will benefit continued Internet growth and a smooth IPv6 transition, and we must be open-minded about these changes - exhaustion is here, whether or not we're prepared.

Written by Benson Schliesser, Principal Engineer, Cisco Systems

One aspect that has been overlooked amidst all the sound and fury, is the governmental perspective on IP address transfers. In the past decade, the continued discussion over the internalisation of "Critical Internet Resources" has brought many governments to positions of strong support for the current regionalised IP addess distribution system. This is largely due, I think, to the capacity building done over the years by the Internet Technnical Community or "I*s".

One example of this support is a letter written by Industry Canada (a department of the Canadian government). The letter supports the Internet Technical Communities long standing position that IP addresses are not property that can be bought and sold. What is interesting to me is that a government is both paying attention AND that they are willing to intervene in a civil matter in this way. This is very encouraging and shows that governments do have a strong interest in maintaining the current system of IP address distribution. I think that Canada holding the position of GAC Chair is no coincidence, it seems that the more active a government is in Internet Governance circles, the deeper the level of understanding.

The journey of capacity building around this Internet Governance issue is clearly not over yet, as there are still some folk (who have been active and influential in these circles) who insist, despite evidence to the contrary, that as a result of the recently announced Nortel/Microsoft transfer, IP addresses are now property that can be bought and sold at whim. The negative effects of monetising IPv4 (legacy) numbers is addressed in the Canadian letter, and is a subject that may need greater focus by capacity building programs (ISOC and Diplo spring to mind) in coming months.

As an aside, the most recent ISOC newsletter also weighs in on this issue, saying "The Internet Society is in full agreement with the RIR policy positions that any transfer, whether between going concerns or from the estate of a defunct company, should be performed in ways consistent with the relevant RIR policies."

"+1" to both ISOC and Canada!

Written by McTim, Co-Chair of the African Network Information Center Policy Development WG

This event is a key turning point in IPv4 exhaustion for the Asia Pacific, as the remaining IPv4 space will be 'rationed' to network operators to be used as essential connectivity with next-generation IPv6 addresses. All new and existing APNIC Members who meet the current allocation criteria will be entitled to a maximum delegation of a /22 (1,024 addresses) of IPv4 space.

"Considering the ongoing demand for IP addresses, this date effectively represents IPv4 exhaustion for many of the current operators in the Asia Pacific region," Wilson said. "From this day onwards, IPv6 is mandatory for building new Internet networks and services."