"In relation to the problem of matching Internet Protocol addresses, my government will bring forward proposals to enable the protection of the public and the investigation of crime in Cyberspace." [on Youtube, 5:45]

As the Guardian pointed out:

The text of the Queen's speech gives the go-ahead to legislation, if needed, to deal with the limited technical problem of there being many more devices including phones and tablets in use than the number of internet protocol (IP) addresses that allow the police to identify who sent an email or made a Skype call at a given time.

What's the problem here?

The perspective of various law enforcement agencies is that the Internet is seen as a space that has been systematically abused, and too many folk are felling prey to various forms of deceit and fraud. If you add to that the undercurrent of concern that the Internet contains a wide range of vulnerabilities from the perspective of what we could generally term "cybersecurity," then it's not surprising to see law enforcement agencies now turning to legislation to assist them in undertaking their role. And part of their desired toolset in undertaking investigations and gathering intelligence is access to records from the public communications networks of exactly who is talking to whom. Such measures are used in many countries, falling under the generic title of "data retention."

In the world of telephony the term "data retention" was used to refer to the capture and storage of call detail records. Such records typically contain the telephone numbers used, time and duration of the call, and may also include ancillary information including location and subscriber details. Obviously such detailed use data is highly susceptible to data mining, and such call records can be used to identify an individual's associates and can be readily used to identify members of a group. Obviously, such data has been of enormous interest to various forms of law enforcement and security agencies over the years, even without the call conversation logs from direct wire tapping of targeted individuals. The regulatory measures designed to protect access to these records vary from country to country, but access is typically made available to agencies on the grounds of national security, law enforcement or even enforcement of taxation conformance.

So if that's what happens in telephony, what happens on the Internet?

Here the story is a continually evolving one, and these days the issues of IPv4 address exhaustion and IPv6 are starting to be very important topics in this area. To see why it is probably worth a looking at how this used to happen and what technical changes have prompted changes to the requirements related to data retention for Internet Service Providers (ISPs).

The original model of the analogous data records for the Internet was the registry of allocated addresses maintained by Internet Network Information Centre, or Internic. This registry did not record any form of packet activity, but was the reference data that shows which entity had been assigned which IP address. So if you wanted to know what entity was using a particular IP address, then you could use a very simple "whois" query tool to interrogate this database:

$ whois -h whois.apnic.net 202.12.29.211

inetnum: 202.12.28.0 - 202.12.29.255
netname: APNIC-AP
descr: Asia Pacific Network Information Centre
descr: Regional Internet Registry for the Asia-Pacific Region
descr: 6 Cordelia Street
descr: PO Box 3646
descr: South Brisbane, QLD 4101
descr: Australia

However, this model of the registry making direct allocations to end user entities stopped in the early 1990's with the advent of the ISP. The early models of ISP service were commonly based on the dial-up model, where a customer would be assigned an IP address for the duration of their call, and the IP address would return to the free pool for subsequent reassignment at the end of the call. The new registry model was that the identity of the service provider was described in the public address registry, and the assignment of individual addresses to each of their dial-up customers was information that was private to the service provider. Now if you wanted to know what entity was using a particular IP address you also had to know the time of day as well, and while a "whois" query could point you in the direction of whom to ask, you now had to ask the ISP for access to their Access, Authentication and Accounting (AAA) records, typically the radius log entries, in order to establish who was using a particular IP address at a given time. Invariably, this provider data is private data, and agencies wanting access to this data had to obtain appropriate authorization or warrants under the prevailing regulatory regime.

This model of traceback has been blurred by the deployment of edge NATs, where a single external IP address is shared across multiple local systems serviced by the NAT. This exercise can therefore trace back to the NAT device, but no further. So with access to this data you can get to understand the interactions on the network at a level of granularity of customer end points, but not at a level of individual devices or users.

We've used this model of Internet address tracking across the wave of cable and DSL deployments. The end customer presents their credentials to the service provider, and is provided with an IPv4 address as part of the session initiation sequence. The time of this transaction, the identity of the customer and the IP address is logged, and when the session is terminated the address is pulled back into the address pool and the release of the address is logged. The implication is that as long as the traceback can start with a query that includes an IP address and a time of day, its highly likely that the end user can be identified from this information.

But, as the Guardian's commentary points out, this is all changing again. IPv4 address exhaustion is prompting some of the large retail service providers to enter the Carrier Grade NAT space, and join what has already become a well established practice in the mobile data service world. The same week of the Queen's speech, BT announced a trial of Carrier Grade NAT use in its basic IP service.

At the heart of the Carrier Grade NAT approach is the concept of sharing a public IP address across multiple customers at the same time. An inevitable casualty of this approach is the concept of traceback in the internet and the associated matter of record keeping rules. It is no longer adequate to front up with an IP address and a time of day. That is just not enough information to uniquely distinguish one customer's use of the network from another's. But what is required is now going to be dependant on the particular NAT technology that is being used by the ISP. If the CGN is a simple port-multiplexing NAT then you need the external IP address and the port number. When combined with the CGN-generated records of NAT's bindings of internal to external address, this can map you back to the internal customer's IP address, and using the ISP's address allocations records, this will lead to identification of the customer.

So traceback is still possible in this context. In a story titled "Individuals can be identified despite IP address sharing, BT says" the newsletter out-law.com (produced by the law firm Pinsent Masons) reports:

BT told Out-Law.com that its CGNAT technology would not prevent the correct perpetrators of illegal online activity from being identified.

"The technology does still allow individual customers to be identified if they are sharing the same IP address, as long as the port the customer is using is also known," a BT spokesperson said in a statement. "Although the IP address is shared, the combination of IP address and port will always be unique and as such these two pieces of information, along with the time of the activity can uniquely identify traffic back to a broadband line. [...] If we subsequently receive a request to identify someone who is using IP address x, and port number y, and time z we can then determine who this is from the logs," the spokesperson said. [...] "If only the IP address and timestamp are provided for a CGNAT customer then we are unable to identify the activity back to a broadband line," they added.

But port-multiplexing NATs are still relatively inefficient in terms of address utilization. A more efficient form of NAT multiplexing uses the complete 5-tuple of the connection signature, so that the NAT's binding table uses a lookup key of the protocol field and the source and destination addresses and port values. This allows the NAT to achieve far higher address sharing ratios, allowing a single external IP address to be shared across a pool of up to thousands of customers.

So what data needs to be collected by the ISP to allow for traceback in this sort of CGN environment? In this case the ISP needs to collect the complete 5-tuple of the external view of the connection, plus the start and stop times at a level of granularity to the millisecond or finer, together with the end-user identification codes. Such a session state log entry takes typically around 512 bytes as a stored data unit.

How many individual CGN bindings, or session states, does each user generate? One report I've seen points to an average of some 33,000 connections per end customer each day. If that's the case then the implication is that each customer will generate some 17Mbytes of log information every day. For a very large service provider, with, say, some 25 million customers, that equates to a daily log file of 425Tbytes. If these CGN records were produced at an unrealistically uniform rate per day, that's a constant log data flow of some 40Gbps. At a more realistic estimate of the busy period peaking at 10 times the average, the peak log data flow rate is some 400Gbps.

That's the daily load, but what about longer term data retention storage demands? The critical questions here is the prevailing data retention period. In some regimes it's 2 years, while in other regimes it's up to 7 years. Continuing with our example, holding this volume of data for 7 years of data will consume 1,085,875 Terrabytes, or 1.0 Exabytes to use the language of excessively large numbers. And that's even before you contemplate backup copies of the data! And yes, that's before you contemplate an Internet that becomes even more pervasive and therefore of course even larger and used more intensively in the coming years.

The questions such a data set can answer also requires a very precisely defined question. It's no longer an option to ask "who used this IP address on this date?" Or even "who used this IP address and this port address in this hour?" A traceback that can penetrate the CGN-generated address overuse fog requires the question to include both the source and destination IP addresses and port numbers, the transport protocol, and the precise time of day, measured in milliseconds. This last requirement, of precise coordinated time records, is a new addition to the problem, as traceback now requires that the incident being tracked be identified in time according to a highly accurate time source running in a known timezone, so that a precise match can be found in the ISP's data logs. It's unclear what it will cost to collect and maintain such massive data sets, but its by no means a low cost incidental activity for any ISP.

No wonder the UK is now contemplating legislation to enforce such record keeping requirements in the light of the forthcoming CGN deployments in large scale service provider networks in that part of the world. Without such a regulatory impost its unlikely that any service provider would, of their own volition, embark on such a massive data collection and long term storage exercise. One comment I've heard is that in some regimes it may well be cheaper not to collect this information and opt to pay the statutory fine instead — it could well be cheaper!

This is starting to look messy. The impact of CGNs on an already massive system is serious, in that it alters the granularity of rudimentary data logging from the level of a connection to the Internet to the need to log each and every individual component conversation that every consumer has. Not only is it every service you use and every site you visit, but its even at the level of every image, every ad you download, everything. Because when we start sharing addresses we now can only distinguish one customer from another at the level of these individual basic transactions. Its starting to look complicated and certainly very messy.

But, in theory in any case, we don't necessarily have to be in such a difficult place for the next decade and beyond.

The hopeful message is that if we ever complete the transitional leap over to an all-IPv6 Internet the data retention capability reverts back to a far simpler model that bears a strong similarity to the very first model of IP address registration. The lack of scarcity pressure in IPv6 addresses allows the ISP to statically assign a unique site prefix to each and every customer, so that the service providers data records can revert to a simple listing of customer identities and the assigned IPv6 prefix. In such an environment the cyber-intelligence community would find that their role could be undertaken with a lot less complexity, and the ISPs may well find that regulatory compliance, in this aspect at least, would be a lot easier and a whole lot cheaper!

Written by Geoff Huston, Author & Chief Scientist at APNIC

If you're shopping for a solution to help you reach these goals, here are four reasons IP geolocation should be at the top of your list. Gleaning high-value business intelligence from IP addresses, geolocation technology delivers BIG where the alternatives fall short.

Personalize web content with or without cookies

With IP geolocation, you can tailor your storefront based on the visitor's country, region or city, and other factors like time of day, current weather or venue (airports, hotels, etc.). While cookies do allow you to customize content, they can present problems. First-party cookies, for example, require you to collect information on the first visit — and asking for information right off the bat can turn off potential buyers. Third-party cookies, meanwhile, collect geolocation and other valuable data, but they are getting a bad reputation due to privacy concerns. Because of concerns related to cookies and privacy, many people use browser tools to block cookies aimed and preventing outside organizations from gaining personal and behavioral data. IP geolocation allows you to customize content for privacy-sensitive users.

Content Localization based on browser settings

Examining the user preferences in the browser can give you basic localization information such as language and time zone. Knowing the time of day visitors are reaching you online, and presenting your content in their preferred language, will ensure a basic level of engagement. Using browser settings is easy, but it does not provide the full impact of localized content that considers regional aspects of language and geography. Improve your message even further by considering variations in dialect and slang. Adjust your focus by knowing whether they are within a coastal, mountain or metropolitan community. IP geolocation provides the capability for more granular, targeted localization.

Locate visitors without the opt-in hassles of GPS apps

In the mobile space, GPS-enabled applications can find the precise location of smartphone users in relation to nearby businesses. Sounds good, especially if you're marketing a local restaurant or store. But here's the rub: these location services are usually opt-in. Users must first decide to let you find them. Again, privacy-minded consumers often say, "no thanks," greatly shrinking your target audience and deflating your campaign. IP geolocation offers a privacy friendly alternative to GPS.

One IP Geo solution that works across all media and environments

Every device that connects to the Internet gets an IP address. Given an IP address, Neustar IP Intelligence can locate the user, many times all the way down to the postal code, without additional software or user intervention, and while respecting user privacy preferences. For more than 10 years we have maintained a database of all routable IP addresses throughout the world. Using IP geolocation, you can manage your customer experience using one technique that works across all user media and environments.

Remember: you only get one first impression. It's important to make the most of it instead of risking the loss of a business opportunity.

IP geolocation, it's the smart way to customize content and show you know your audience. Want more details? Learn more here.

The issue of leasing — or rather sub-leasing, because ARIN is already leasing the addresses to its members — is yet another symptom of the growing scarcity of IPv4 addresses. Subleasing is interesting, however, as another example of the way RIR's bureaucratic control of transactions between willing sellers and buyers can lead to workarounds that make the Whois directory less accurate.

It's unclear exactly how ARIN is aware of this nominally private activity. Perhaps someone involved is tipping ARIN off, or maybe its staff is observing instances where the ASN information associated with a routed block is changing while the contact information in the ARIN Whois directory remains the same. In either case, a greater degree of transparency about refused transfers and the basis for ARIN's determination would be welcome. On a related note, we sought to shed some light on the emerging transfer market in a paper last year.

What is troubling, for ARIN at least, is that the subleasing of addresses is taking place outside of the RIR address governance regime. It is understandable that ARIN would react to something that might undermine its control over address space. Part of ARIN's power stems from its ability to identify who is allocated or assigned what address block(s) via its Whois Directory Service. Practically, the Whois has also been used to identify the party actually routing an address block, although technically this is a distinct activity over which ARIN claims no control.

From an operational perspective, if the organization actually routing an address block is unable to be contacted this could be detrimental to administrators attempting to resolve networking issues, and to parties seeking to use the Whois for law enforcement or related policy matters. However, at this point it is unclear if lessees are actually unreachable. In fact, one could argue that lessors are in a better position to keep accurate lessee contact records than the address registry — they are invoicing their lessees, we assume! Whether, and under what conditions, they would release contact information is basically unknown at this point.

For now, ARIN does not seem to be too alarmed. It suggests three potential policy solutions:

1. Decide this is not an issue for ARIN to deal with
2. Create new policy requiring that the actual party using the addresses be listed as an operational contact in Whois
3. Create new policy that would prevent leasing of address space without needs based justification.

Again, absent any data on leasing, it is hard to say which way ARIN or its membership might go, although the third option seems increasingly unlikely as ARIN moves closer to IPv4 exhaustion and the RIPE region is contemplating elimination of needs based justification entirely.

It may just turn out that private subleasing transforms the address transfer market. As Addrex's Charles Lee pointed out at INET in Denver, all kinds of parties lease assets (including ARIN leasing addresses to its own customers). It serves a useful business purpose and is not a bad thing per se. The entry of large subleasing companies without any Internet operations, Lee noted, might transform the address market. It could create entirely new ways of allocating addresses and provisioning post allocation services. It might lead to innovative product offerings such as providing means to mitigate the technological obsolescence of IPv4. We just don't know. What we know for sure is that it will create governance dilemmas.

Written by Brenden Kuerbis, Fellow in Internet Security Governance, Citizen Lab, Univ of Toronto

At first blush that may sound like a contradiction in terms, or perhaps a wild conjecture intended only to grab your attention to get you to read on. After all, the Internet is a modern day technical marvel. In just a couple of decades the Internet has not only transformed the global communications sector, but its reach has extended far further into our society, and it has fundamentally changed the way we do business, the nature of entertainment, the way we buy and sell, and even the structures of government and their engagement with citizens. In many ways the Internet has had a transformative effect on our society that is similar in scale and scope to that of the industrial revolution in the 19th century. How could it possibly be that this prodigious technology of the Internet is "badly broken?" Everything that worked yesterday is still working today isn't it? In this article I'd like to explain this situation in a little more detail and expose some cracks in the foundations of today's Internet.

You see it's all about addresses. In a communications network that supports individual communications it's essential that every reachable destination has its own unique address. For the postal network it's commonly your street address. For the traditional telephone network it's your phone number. This address is not just how other users of the network can select you, and only you, as the intended recipient of their communication. It's how the network itself can ensure that the communication is correctly delivered to the intended recipient. The Internet also uses addresses. In fact the Internet uses two sets of addresses. One set of addresses is for you and I to use. Domain names are the addresses we enter into web browsers, or what we use on the right hand side of the @ in an email address. These addresses look a lot like words in natural languages, which is what makes them so easy for we humans to use. The other set of addresses are used by the network. Every packet that is passing through the Internet has a digital field in its header that describes the network address of the packet's intended delivery address: it's "destination address." This address is a 32 bit value. A 2 bit field has four possible values, a 3 bit field has eight possible values, and by the same arithmetic a 32 bit field has 2 to the power 32, or some 4,294,967,296 unique values.

If every reachable device on the Internet needs a unique address in order to receive packets, then does that mean that we can only connect at most some 4 billion devices to the Internet? Well, in general terms, yes! And once we reach that hard limit of the address size, should we expect to encounter problems? Well, in general terms, yes!

Running out of addresses in any communications network can pose a massive problem. We have encountered this a number of times in the telephone network, and each time we've managed to add more area codes, and within each area we've added more in-area digits to telephone numbers to accommodate an ever-growing population of connected telephone handsets. Every time we've made this change to the address plan of the telephone network we needed to reprogram the network. Luckily, we didn't needed to reprogram the telephone handsets as well. We just had to re-educate telephone users to dial more digits. With care, with patience, and with enough money this on-the-fly expansion of the telephone system's address plan can be undertaken relatively smoothly. But this approach does not apply to the Internet. The address structure of the Internet is not only embedded into the devices that operate the network itself, the very same address structure is embedded in every device that is attached to the network. So if, or more correctly, when, we run out of these 32 bit addresses on the Internet we are going to be faced with the massive endeavour of not only reprogramming every part of the network, but also reprogramming every single device that is attached to the network. Given that the Internet today spans more than 2.3 billion users and a comparable number of connected devices then this sounds like a formidable and extremely expensive undertaking.

Frank Solensky's Report on Address Depletion, Proceedings of IETF 18, p. 61, Vancouver, August 1990 (PDf)If running out of IP addresses is such a problem for the Internet then you'd like to hope that we could predict when the ominous event would occur, and then give ourselves plenty of lead time to dream up something clever as a response. And indeed we did predict this address depletion. Some 23 years ago, in August 1990, when the Internet was still largely a research experiment and not the foundation bedrock of the global communications enterprise we saw the first prediction of address runout. At the time Frank Solensky a participant in the Internet Engineering Task Force (IETF) extrapolated the growth of the Internet from the emerging experience of the US National Science Foundation's NSFNET, and similar experiences in related academic and research projects, and predicted that the pool of addresses would run out in some 6-10 years time.

The technical community took this message to heart, and started working on the problem in the early 1990's.

From this effort emerged a stop gap measure that while it was not a long term solution, would buy us some urgently needed extra time. At the time the Internet's use of address use was extremely inefficient. In a similar manner to a telephone address that uses an area code followed by a local number part, the Internet's IP address plan divides an IP address into a network identifier and a local host identifier. At the time we were using an address plan that used fixed boundaries between the network identification part and the host identification part. This address plan was a variant of a "one size fits all" approach, where we had three sizes of host addresses within the network: one size was just too big for most networks, one size was too small, and the only one that left was capable of spanning an Internet of just 16,382 networks. It was this set of so-called "Class B" address blocks that Frank Solensky predicated to run out in four year's time.

So what was the stop gap measure? Easy. Remove the fixed boundaries in the address plan and provide networks with only as many addresses as they needed at the time. It was hoped that this measure would give us a few more years of leeway to allow us to develop a robust long term answer to this address problem. The new address plan was deployed on the Internet in early 1993, and for a couple of years it looked like we were precisely on track, and, as shown in Figure 2, this small change in the address plan, known as Classless Inter-Domain Routing (CIDR), would buy us around 2 or 3 years of additional time to work on a longer term approach to IP address exhaustion.

Figure 2 – CIDR and Address Consumption

As things turned out, we were wrong in that 2 — 3 year estimate.

The reason why we were wrong was that a second stop gap measure was also developed in the early 1990's. This new technology cut right to the heart of the architecture of the Internet and removed the strict requirement that every attached device needed its own unique address on the Internet.

The approach of Network Address Translators (NATs), allowed a collection of devices to share a single public IP address. The devices that were located "behind" a NAT could not be the a target of a new communication, so that, for example, you could not host a web service if you were behind a NAT, but as long as the devices behind the NAT initiated all communications, then the NAT function became invisible, and the fact that an IP address was being shared across multiple devices was effectively irrelevant. In a model of clients and servers, then as long as you only placed the clients behind a NAT then it was possible to share a single IP address across multiple clients simultaneously.

The emerging retail ISP industry took up this NAT technology with enthusiasm. The provisioning model for retail Internet services was for a single IP address provided for each connected service, which was then shared by all the computers in the home using a NAT that was embedded into the DSL or cable modem that interfaced the home network to the service provider network. The IP address consumption levels dropped dramatically, as it was no longer a case of requiring a new IP address for each connected device, but instead requiring a single IP address for each connected service. And as the home collected more connected devices, none of these devices drew additional addresses from the IP address pool.

Instead of buying a couple of years of additional breathing space to design a long term solution to address depletion, the result of the combination of classless addressing and NATs was that it looked like we had managed to push the issue of address depletion out by some decades! The most optimistic prediction of address longevity in around 2001 predicted that IPv4 address depletion might not occur for some decades, as the address consumption rate had flattened out, as shown in Figure 3.

Figure 3 – CIDR, NATs and Address Consumption

Perhaps it may have been an unwarranted over-reaction, but given this reprieve the industry appeared to put this entire issue of IP address depletion in the Internet onto the top shelf of the dusty cupboard down in the basement.

As events turned out, that level of complacency about the deferral of address depletion was misguided. The next major shift in the environment was the mobile Internet revolution of the last half of the 2000's. Before then mobile devices were generally just wireless telephones. But one major provider in Japan had chosen a different path, and NTT DOCOMO launched Internet-capable handsets onto an enthusiastic domestic market in the late 1990's. Their year-on-year rapid expansion of their mobile Internet service piqued the interest of many mobile service operators in other countries. And when Apple came out with a mobile device that included a relatively large well-designed screen and good battery life, an impressive collection of applications and of course a fully functional IP protocol engine, the situation changed dramatically. The iPhone was quickly followed by a number of other vendors, and mobile operators quickly embraced the possibilities of this new market for mobile Internet services. The dramatic uptake of these services implied an equally dramatic level of new demand for IP addresses to service these mobile IP deployments, and the picture for IP address depletion one more changed. What was thought to be comfortably far into the future problem of IP address depletion once more turned into a here and now problem.

Figure 4 – Address Consumption

Even so, we had exceeded our most optimistic expectations and instead of getting a couple of years of additional breathing space from these stop gap measures, we had managed to pull some 15 additional years of life out of the IPv4 address pool. But with the added pressures from the deployment of IP into the world's mobile networks we were once more facing the prospect of imminent address exhaustion in IPv4. So it was time to look at that long term solution. What was it again?

During the 1990's the technical community did not stop with these short term mitigations. They took the address depletion scenario seriously, and considered what could be done to define a packet-based network architecture that could span not just billions of connected devices but hundreds of billions of devices or more. Out of this effort came version 6 of the Internet Protocol, or IPv6. The changes to IPv4 were relatively conservative, apart from one major shift. The address fields in the IP packet header were expanded from 32 bits to 128 bits. Now every time you add a single bit you double the number of available addresses. This approach added 96 bits to the IP address plan. Yes, that's 340,282,366,920,938,463,463,374,607,431,768,211,456 possible addresses!

This approach to IPv6 appeared to adequately answer the need for a long term replacement protocol with enough addresses to fuel a rapacious silicon industry that can manufacture billions of processors each and every year. However, there was one residual annoying problem. The problem arises from one of the underlying features of the Internet's architecture: IP is an "end-to-end' protocol. There is no defined role for intermediaries in packet delivery. In the architecture of the Internet, what gets sent in a packet is what gets received at the other end. So if a device sends an IPv4 packet into the network, what comes out is an IPv4 packet, not an IPv6 packet. Similarly, if a device sends an IPv6 packet into the network then what comes out at the other end is still an IPv6 packet. The upshot of this is that IPv6 is not "backward compatible" with IPv4. In other words setting up a device to talk the "new" protocol means that it can only talk to other devices that also talk the same protocol. This device is completely isolated from the existing population of Internet users. What were these technology folk thinking in offering a new protocol that could not interoperate with the existing protocol?

What they were thinking was that this was an industry that was supposedly highly risk averse, and that once a long term replacement technology was available then the industry would commence broad adoption well before the crisis point of address exhaustion eventuated. The idea was that many years in advance of the predicted address exhaustion time, all new Internet devices would be configured to be capable of using both protocols, both IPv4 and IPv6. And the idea was that these bilingual devices would try to communicate using IPv6 first and fall back to IPv4 if they could not establish a connection in IPv6. The second part of the transition plan was to gradually convert the installed base of devices that only talked IPv4 and reprogram them to be bilingual in IPv6 and IPv4. Either that, or send these older IPv4-only devices to the silicon graveyard!

The transition plan was simple. The more devices on the Internet that were bilingual the more that the conversations across the network would use IPv6 in preference to IPv4. Over time IPv4 would essentially die out and support for this legacy protocol would be no longer required.

However one part of this plan was critical. We were meant to embark on this plan well before the time of address exhaustion, and, more critically, we were meant to complete this transition well before we used that last IPv4 address.

Figure 5 – The IPv6 Transition Plan

And to some extent this is what happened. Microsoft added IPv6 to its operating systems from the mid 2000's with the Windows Vista and Windows Server 2008 products. Apple similarly added IPv6 into their Mac OSX system from around 2006. More recently, IPv6 support has been added into many mobile devices. These days it appears that around one half of all devices connected to the Internet are bi-lingual with IPv6 and IPv4. This is indeed a monumental achievement, and much of the effort in re-programming the devices that are attached to the Internet to speak the new protocol has been achieved. So we are all ready to switch over the Internet to use IPv6, yes? Well, no, not at all.

So what's gone wrong?

Many things have not gone according to this plan, but perhaps there are two aspects of the situation that deserve highlighting here.

Firstly, despite the addition of IPv6 into the popular computer platforms, the uptake of IPv6 in the network is just not happening. While there was a general view that the initial phase of IPv6 adoption would be slow, the expectation was that the use of IPv6 would accelerate along exponentially increasing lines. But so far this has not been all that evident. There are many metrics of the adoption of IPv6 in the Internet, but one of the more relevant and useful measurements is that relating to client behaviour. When presented with a service that is available in both IPv4 and IPv6, what proportion of clients will prefer to use IPv6? Google provide one measurement point, that measures a sample of the clients who connect to Google's service. Their results are shown in Figure 6.

Figure 6 – IPv6 Adoption (Source)

Over the past four years Google has seen this number rise from less than 1% of users in early 2009 to a current value of 1.2%. It's one of those glass half-full or half-empty stories. Although in this case the glass is either 1% full or 99% empty! If broad scale use of IPv6 is the plan, then right now we seem to be well short of that target. On a country-by-country basis the picture is even more challenging. Only 9 countries have seen the proportion of IPv6 users rise above 1%, and the list has some surprising entries.

Figure 7 – IPv6 Adoption (Source)

It's hard to portray this as evidence of broad based adoption of IPv6. Its perhaps more accurate to observe that a small number of network providers have been very active in deploying IPv6 to their customer base, but these providers are the minority, and most of the Internet remains locked deeply in IPv4. If a significant proportion of the end devices support IPv6 then why are these use metrics so unbelievably small? It appears that the other part of the larger network re-programming effort, that of enabling the devices sitting within the network to be IPv6-capable, has not taken place to any significant extent. It's still the case that a very large number of ISPs do not include IPv6 as part of their service offering, which means that even if an attached computer or mobile device is perfectly capable of speaking IPv6, if the access service does not support IPv6 service then there is effectively no usable way for the device to use IPv6. And even when the service provider supplies IPv6 as part of its service bundle, it may still be the case that the user's own network devices, such as the in-home NAT/modems and other consumer equipment that supports in in-home networks, such as a WiFi base station or a home router may only support IPv4. Until this equipment is replaced or upgraded, then IPv6 cannot happen. The result is as we seen in the IPv6 usage metrics today: when offered a choice between IPv4 and IPv6, some 99% of the Internet's connected devices will only use IPv4.

Secondly, we've now crossed into a space that was previously regarded as the unthinkable: we've started to run out of IPv4 addresses in the operating network. This address exhaustion started with the central address pool, managed by the Internet Assigned Numbers Authority (IANA). The IANA handed out its last address block in February 2011. IANA hands out large blocks of addresses (16,777,216 addresses per "block") to the Regional Internet Address Registries (RIRs), and in February 2011 it handed out the last round of address blocks to the RIRs. Each of the five RIRs operates independently, and each will themselves exhaust their remaining pool of IPv4 addresses in response to regional demand. APNIC, the RIR serving the Asia Pacific region, was the first to run out of addresses, and in mid April 2011 APNIC handed out its last block of "general use" IPv4 addresses. (as a side remark here, APNIC still had 17 million addresses held aside at that point, but the conditions associated with allocations from this so-called "final /8" are than each recipient can receive at most an allocation of a total of just 1,024 addresses from this block.) This represented an abrupt change in the region. In the last full year of general use address allocations, 2010, APNIC consumed some 120 million addresses. In 2012, the first full year of operation under this last /8 policy the total number of addresses handed out in the region dropped to 1 million addresses. The unmet address demand from this region appears to be growing at a rate of around 120 — 150 millions addresses per year.

The region of Europe and the Middle East has been the next to run out, and in September 2012 the RIPE NCC, the RIR serving this region, also reached its "last /8" threshold, and ceased to hand out any further general use IPv4 addresses. The process of exhaustion continues, and the registry that serves Northern America and parts of the Caribbean, ARIN, has some 40 million addresses left in its address pool. At the current consumption rate ARIN will be down to its last /8 block 12 months from now, in April 2014. LACNIC, the regional registry serving Latin America and the Caribbean, currently has some 43 million addresses in its pool, and is projected to reach their last /8 slightly later in August 2014. The African regional registry, AFRINIC, has 62 million addresses, and at its current address consumption rate, the registry will be able to service address requests for the coming seven years.

Figure 8 – IPv4 Address Depletion (Source)

So if the concept was that we would not only commence, but complete the process of transition to use IPv6 across the entire Internet before we got to that last IPv4 address, then for Europe, the Middle East, Asia and the Pacific this is not going to happen. It's just too late. And for North and South America it's also highly unlikely to happen in time.

And the slow pace of uptake of IPv6 points to the expectation that this "running on empty" condition for the Internet address plan may well continue for some years to come.

We are now entering into a period of potential damage for the Internet. If the objective of this transition from IPv4 to IPv6 was to avoid some of the worse pitfalls of exhaustion of the IPv4 address space in the internet, then we've failed.

The consequence of this failure is that we are now adding a new challenge for the Internet. It's already a given that we are meant to sustain continued, and indeed accelerating, growth in terms of the overall size of the network and the population of connected devices. The pace of this growth is expressed as a demand for some 300 million additional IP addresses per year, and the figures from the device manufacturers point to a larger figure of some 500 — 700 million new devices being connected to the Internet each year. And the number grows each year. We are expanding the Internet at ever faster rates. As if riding this phenomenal rate of growth on the existing infrastructure and existing technology base wasn't challenging enough, we also have the objective not just to maintain, but to accelerate the pace of transition to IPv6. These two tasks were already proving to be extremely challenging, and we've been slipping on the second. But we now have the additional challenge of trying to achieve these two objectives without the supply of any further IPv4 addresses. At this point the degree of difficulty starts to get uncomfortably close to ten!

This situation poses some architectural consequences for the Internet. Until now we've managed to push NATs out to the edge of the network, and make address compression something that end users did in their home networks. The consequences of failure of such devices and functions are limited to the edge network served by the NAT. We are now deploying mechanisms that allow this NAT function to be performed in the core of the carriage networks. This introduces a new set of unquantified factors. We've little experience in working with large scale NAT devices. We have no idea of the failure modes, or even the set of vulnerabilities in such an approach. We are still debating the appropriate technical approach in the standards bodies, so there are a variety of these service provider NAT approaches being deployed. Each NAT approach has different operational properties, and different security aspects. But now we don't have the luxury of being able to buy more time to explore the various approaches and understand the relative strengths and weaknesses of each. The exigencies of address exhaustion mean that the need for carrier level NAT solutions is now pressing, and given that this is a situation that we never intended to experience, we find ourselves ill-prepared to deal with the side effects from this subtle change in the network's architecture. The greater the level of complexity we add into the network, and the wider the variation in potential network behaviours as a result, the greater the burden we then place on applications. If the network becomes complex to negotiate then applications are forced to explore the local properties of the network environment in order to provide the user with a robust service.

If the hallmark of the Internet was one of efficiency and flexibility based on a simple network architecture, then as we add complexity into the network what we lose is this same efficiency and flexibility that made the Internet so seductively attractive in the first place. The result is a network that is baroquely ornamented, and one that behaves in ways that are increasingly capricious.

We are hopelessly addicted to using a network protocol that has now run out of addresses. At this point the future of the Internet, with its projections of trillions of dollars of value, with its projections of billions of connected silicon devices, with its projections of petabytes of traffic, with its projections of ubiquitous fibre optics conduits spanning the entire world is now entering a period of extreme uncertainty and confusion. A well planned path of evolution to a new protocol that could comfortably address these potential futures is no longer being followed. The underlying address infrastructure of the network is now driven by scarcity rather than abundance, and this is having profound implications on the direction of evolution of the Internet.

There really is something badly broken in today's Internet.

Written by Geoff Huston, Author & Chief Scientist at APNIC

We recently analyzed the reputation of a country's Internet (IPv4) addresses by examining the number of blacklisted IPv4 addresses that geolocate to a given country. We compared this indicator with two qualitative measures of each country's governance. We hypothesized that countries with more transparent, democratic governmental institutions would harbor a smaller fraction of misbehaving (blacklisted) hosts. The available data confirms this hypothesis. A similar correlation exists between perceived corruption and fraction of blacklisted IP addresses.

CAIDA's Country IP Reputation Graphs (Click to Enlarge)
See the interactive graph and analysis on the CAIDA website

For more details of data sources and analysis, see:
http://www.caida.org/research/policy/country-level-ip-reputation/

Written by kc claffy, Director, CAIDA and Adjunct Professor, UC, San Diego

http://www.internetsociety.org/events/inet-denver/inet-denver-livestream

Sessions include:

• IPv4 Exhaustion Update
• IPv4 Exhaustion at ARIN
• Address Policy Workshop
• Evaluation of Current Transfer Market
• TCO of IPv6
• Internet Society Initiatives and How To Get Involved

The list of speakers includes people from ARIN, CableLabs, Internet Society, Time Warner Cable, Google and more.

It sounds like a great event and I'm looking forward to watching it remotely.  It will be recorded so that you will be able to watch it later if you cannot view it live.

Written by Dan York, Author and Speaker on Internet technologies

IPv4 is likely to co-exist with IPv6 for some time, so a native dual-stack migration strategy will be the best transition option for most providers. Dual-stack mode allows both IPv4 and IPv6 to run simultaneously over the network, which lets end-user devices communicate via whichever protocol they are equipped for. With dual-stack mode, there is no disruption to the service if a client requests an IPv4 address. Clients that receive both an IPv4 and IPv6 address will prefer to access the IPv6 network, if it's available. The DNS can determine whether the service is reachable over IPv6 or whether to fall back to IPv4.

Of course, dual-stack provisioning isn't perfect. Service disruptions can occur if you don't have enough IPv4 addresses to hand out to new subscribers. This is because dual-stack systems require devices to have both an IPv4 and IPv6 address. If this is a problem for you, it may be possible to use a tunneling technique or network address translation (NAT).

NAT, however, comes with its own set of problems, including:

• Impaired quality of service for internal and external systems
• Increased network complexity and fragmentation
• Security concerns when multiple subscribers share a single, public IPv4 address
• Difficulty with law enforcement compliance

Despite these issues, you may find it difficult to implement native dual-stack mode without NAT if you continue to delay your IPv6 preparations. The sooner that you can begin handing out IPv6 addresses to new customers, the sooner you will be able to store IPv4 resources to provide addresses to older subscriber devices. This means you need to start your IPv6 preparations now — even if you still have plenty of IPv4 resources.

If you're interested in learning more about dual-stack migration or want to explore other transition options, download our free ebook: IPv6 eBook Series: Migration.

Written by Stephane Bourque, Founder, CEO and President at Incognito Software

The RIPE NCC's IPv6-ASN graph shows the percentage of networks that announce one or more IPv6 prefixes in the global routing system. Having an IPv6 prefix visible in the global routing system is a required step for a network to actually start exchanging IPv6 traffic with other networks. The interactive graph allows you to specify the countries or service regions you are interested in, which can make for some interesting comparisons.

The graph below shows the percentage of networks announcing IPv6 prefixes in each Regional Internet Registry's (RIR) service region over the last few years.

It is interesting to see that the percentage of networks announcing IPv6 address space in the APNIC and the RIPE NCC service regions continues to increase steadily. Both of these RIRs have reached IPv4 exhaustion (in 2011 and 2012 respectively) and are currently allocating from their last /8 block of addresses.

It is also encouraging to see that the percentage of IPv6-enabled networks in the ARIN service region, which is projected to be the third RIR to reach its last /8 of IPv4 addresses, is also increasing. On the other hand, the percentage of IPv6-enabled networks in the Lacnic and the AFRINIC service regions appears to have stopped growing. For the Lacnic service region this number even fell a little over the last few months. Despite the absolute number of IPv6 announcing networks growing from 388 to 399 since the beginning of 2013, this growth was outpaced by the total growth of networks in the service region that are visible in the global routing system, which resulted in a total percentage decrease from 15.5% to 15.0% for this period. Even though this might not be a surprise, it's reassuring to see that in regions where IPv4 exhaustion has occurred, there is a steady growth in the percentage of networks announcing IPv6 address space.

If you find other interesting comparisons between countries or regions, please comment below! You can find more information and statistics on RIPE Labs.

Note that this article is based on work done by Emile Aben, System Architect at the RIPE NCC.

Written by Mirjam Kuehne

You won't want to miss this unique opportunity to join IPv6 networking professionals from across North America, who will attend to learn the latest on IPv4 exhaustion and how to transition to IPv6. The INET Denver agenda will bring together top experts in the networking field to discuss the latest on IPv4 exhaustion in our market, and the TCO of IPv6.

The line up of speakers includes industry experts like:

John Curran, President & CEO, ARIN
Owen DeLong, IPv6 Evangelist, Hurricane Electric
Lee Howard, Director of Network Technology, Time Warner Cable
Dr. Patrick Ryan, Public Policy & Government Relations Counsel, Google

When:

April 17, 2013
Registration: 12:00 - 1:00 PM
INET Denver: 1:00 - 6:00 PM
Refreshments: 6:00 - 7:30 PM

Where:

Grand Hyatt Denver
1750 Welton Street
Denver, CO 80202

Additional Details:

http://www.internetsociety.org/events/inet-denver

Registration:

http://www.internetsociety.org/form/inet

The INET Denver will co-locate with the 2013 North American IPv6 Summit. Take part in this unique opportunity to learn from top experts in the networking field discussing the latest on IPv4 exhaustion in our market and the TCO of IPv6.

Don't delay and register today!

Regardless of the size of your organization, your firm's core network infrastructure including your DNS, DHCP and IPAM servers are the backbone of your IT system, supporting the growth and scalability of your business. Unfortunately though, many IT departments fail to realize that home-grown solutions, stand alone systems and Excel spreadsheets used to manually manage their IP-dependent infrastructure, simply can not support the dynamic nature and scalability demands of today's networks. With the imminent move to the cloud and the introduction of the hybrid cloud model to organizations' network infrastructure, how you manage your IP address space becomes even more important.

IPAM consumed as a software service on the cloud is one viable solution, especially for Small and Medium Enterprises (SMEs) with limited IT budget for capital infrastructure investments. Simply put, IPAM SaaS is a shared IPAM on the cloud through which the organization's DNS and DHCP servers are managed. These servers could either be in the organization's own private network or then dedicated server instances on the cloud. Here, the enterprise's own IT department would be utilizing the IPAM service on the cloud, through a secure remote access, to manage the DNS and DHCP servers. With a pay-as-you-go business model, this approach allows the SME to have access to state-of-the-art, scalable IP address management system with zero requirements for capital expenses, maintenance, license and renewal fees.

Another approach is to dispense with the major part of the operating costs by dedicating the task to Managed Service Providers (MSPs) who would then be managing the IPAM for you. Here, the MSP would be running a dedicated IPAM instance on the cloud to manage the organization's core IP network. All communications between the IaaS cloud and the organization's network are conducted through a secure tunnel without any need for public IP address routing, making the IaaS cloud a transparent extension of the organization's resources (see this post for more on security). In practice, this approach has all the advantages discussed in the previous paragraph plus the added benefit that it considerably reduces the operating expenses.

This has huge implications for an organization's resource planning strategy, and changes the competitive landscape in the industry. Thanks to services such as IPAM SaaS and IaaS, SMEs and start-ups now have access to the same computing resources and capabilities as their bigger rivals, allowing them to focus on getting the services they need without being constrained by the technology on which those services are based. Cloud-based service delivery with a pay-as-you-go business model has changed the rules of the game, paving the way for a fairer competitive environment based on innovative business models and sustainable capabilities.

Written by Hanieh Taipalus, Marketing Manager at Nixu Software

CENTR Paper – Fifth World Telecommunication/ICT Policy Forum (Download PDF)

Introduction

Many nations, particularly from the developing world, look to the International Telecommunications Union (ITU) for advice on telecommunications issues and, increasingly, Internet governance issues. The ITU's Fifth World Telecommunication/ICT Policy Forum (WTPF-13), 14-16 May 2013, Geneva, Switzerland, will be the first WTPF to focus exclusively on Internet issues. Positions agreed to by ITU Member States on the management of Internet resources — including ccTLDs — and the roles and responsibilities of stakeholders in Internet governance are of particular importance to ccTLD operators due to the close association of ccTLDs to the territorial boundaries of sovereign nations.

WTPF-13

WTPF-13 has been convened to discuss the issues raised in ITU's three key Internet-related resolutions:¹

• Resolution 101:"Internet Protocol (IP)-based Networks" (Rev. Guadalajara, 2010)²
• Resolution 102: "ITU's role with regard to international public policy issues pertaining to the Internet and the management of Internet resources, including domain names and addresses" (Rev. Guadalajara, 2010)³
• Resolution 133: "Roles of administrations of Member States in the management of Internationalized (multilingual) domain names" (Rev. Guadalajara, 2010)⁴

The main policy outcomes of WTPF-13 will be the "Opinion" documents, which are non-binding on ITU's membership. However, the Opinions and final meeting report will be a good indicator of the Internet issues that may become the focus of ITU discussions, and in turn, more formal resolutions and recommendations, in the near future. In particular, WTPF-13 outcomes will inform the discussions at the Council Working Group on International Internet-Related Public Policy Issues (CWG-Internet), the ITU Plenipotentiary 2014 and the WSIS+10 review process.

In preparation for WTPF-13, two meetings of the Informal Experts Group (IEG)⁵ have already been held to fine-tune the Secretary- General's report.⁶ The report's summary of issues, which includes ccTLD processes, will form the basis of WTPF-13 discussions in May. Draft Opinions have been made available in the fourth, and latest, version of the Secretary-General's report. It is possible that more Draft Opinions will appear in the next and final version of the Secretary General's report, which will be published 1 March 2013.

WTPF-13 Draft Opinions

There are six Draft Opinions in the January 2013 version of the Secretary-General's report. The final WTPF-13 Opinions will be based on these drafts and onsite discussion of the contents of the Secretariat-General's report.

Overall model of Internet governance and development

There are three Draft Opinions on this topic. Two of the three drafts, submitted by Saudi Arabia, focus on the need for "immediate operationalization of the enhanced cooperation process" via an existing or new intergovernmental organization, in consultation with other stakeholders. The third draft, submitted by the United Kingdom, focuses on open, transparent and accountable Internet development, freedom of expression, universal access, and invites all stakeholders — not only Member States and Sector Members — to collaborate towards the ongoing expansion of the Internet.

Why these Opinions matter: These three Draft Opinions reflect fundamentally different views on how the Internet should be governed. On one side are States who believe it is important to have a government-only platform to discuss international Internet governance matters (this does not exclude other venues for Internet governance discussions). In many cases, these governments focus on the security risks the Internet can pose and seek an intergovernmental venue that can address these risks. On the other side are States who prefer to maintain the current multi-stakeholder environment, believing that governments already have enough opportunities to participate in Internet governance processes. These States often prefer to focus on the opportunities the Internet offers, such as freedom of expression and the development of an information society for all.

IPv6 deployment Both Draft Opinions on IPv6 encourage Member States to develop policies and incentives for IPv6 deployment within their territories. The Saudi Arabian draft also proposes ITU to develop policies to manage IPv4 address transfers in the wake of the exhaustion of the unallocated IPv4 pool. The United Kingdom's draft emphasizes the need to build human capacity in developing countries to enable IPv6 deployment.

Why these Opinions matter: If ITU Member States recommend the ITU should actively develop policy for IP address space management — an area already served by Regional Internet Registries (RIRs) — it may open the door for ITU to consider policy development in other areas of Internet resource management. In many cases, such policy development already has a home within existing organizations, such as the ICANN.

IXPs as the long-term solution to better and more robust Internet connectivity

The final draft opinion, from the United Kingdom, invites Member States and Sector Members to work collaboratively with developing countries in promoting IXPs.

Why this Opinion matters: In contrast to the other Draft Opinions, where views on the same topic are the result of ideological differences, this Draft Opinion is an example of practical ways to develop Internet capacity in developing countries. In addition, an improved Internet quality for regions served by new IXPs, will create new useful locations to host anycasted Root DNS Servers and secondary ccTLDs nameservers.

Internet issues contained in the Secretary-General's WTPF-13 report

Any of the topics included in the Secretary-General's report may be included in the final Opinions and meeting report. In particular, the broad scope of the three Draft Opinions on the overall model of Internet governance and development leaves room to add text on a variety of Internet issues summarized in the Secretary-General's report. The issues of most relevance to the ccTLD community in the report are:

1. Roles and responsibilities of stakeholders in Internet management

While the WSIS Tunis Agenda⁷ recognized the multi-stakeholder model as the appropriate global model for Internet governance, the Secretary-General's report summarizes debates on whether the model has been fully implemented. One view maintains that the current Internet governance framework is sufficiently multi-stakeholder and that intergovernmental forums that discuss the Internet, such as the ITU, also need to adopt a multi-stakeholder approach. The ITU has itself been keen to change the world's perceptions of its working methods, publicizing that the WTPF IEG process is open to all stakeholders.⁸

The other view is that the role of governments in Internet governance has not been allowed to evolve according to the "enhanced cooperation" text in the Tunis Agenda, which states:

"We further recognize the need for enhanced cooperation in the future, to enable governments, on an equal footing, to carry out their roles and responsibilities, in international public policy issues pertaining to the Internet, but not in the day-to-day technical and operational matters, that do not impact on international public policy issues."

According to this second view, the failure to operationalize an intergovernmental mechanism for enhanced cooperation has contributed to the world's failure to adequately address ongoing Internet challenges, including spam and cybercrime. States holding this view often also question the adequacy of the ICANN Government Advisory Committee (GAC).

2. Management of Internet resources

The Secretary-General's report notes concerns with the current Internet infrastructure's ability to support the Internet's continued growth — in particular, the ability to support security, identity management and multilingualism. Under the topic of Internet resource management are the following topics of interest:

• Internet connectivity – The high cost of international Internet connectivity for Least Developed Countries (LDCs) is seen to be particularly problematic, with IXPs reported as a long-term solution to the problem. Included in the report are descriptions of some of the main challenges LCDs face in closing the digital divide.
• IP addresses – The ITU has a long history discussing IP address management, which is reflected in the Secretary-General's report. The slow rate of IPv6 deployment, in particular, is a concern, with continued debate about whether today's "first come, first served" IPv6 allocation policies could penalize late adopters. The ITU has issued a number of IP address-related resolutions⁹, so it is a certainty that WTPF 2013 will result in an IP address-related Opinion.
• Resource Public Key Infrastructure (RPKI) – RPKI is still in its infancy but it is hoped it will make the Internet's IP routing system more secure. Given the security implications, RPKI is a topic of interest to ITU Member States and therefore is included in the Secretary-General's report. In particular, the report notes that questions have been raised about whether the operation of the RPKI certifi cate chain by ICANN and RIRs fundamentally changes their role in Internet governance.

3. gTLDs

The new gTLD process is detailed in the report, with the Secretary-General noting discussions about new gTLDs' impact on gTLD market competition and trademark or rights holders, particularly those in developing countries. The report also notes that concerns have been raised about the potential misuse of acronyms reserved for use by intergovernmental organizations (IGOs), geographic names, and cultural and language descriptors.

4. ccTLDs

The report notes that there is not a one-to-one relationship between a ccTLD string for a "territory" as defined in the ISO-3166 list and the name of a sovereign nation, with some nations having more than one ccTLD string reserved for their use (for example, Finland has both .fi and .ax). The ccTLD re-delegation process is also described in depth, including the need for the US government to evaluate IANA's report on the ccTLD request. The report includes a reference to ITU's role in requesting the re-delegation of .so in 2009 and notes that the Tunis Agenda states that countries should not be involved in decisions regarding another country's ccTLD. It is not clear whether this reference is meant to be compared directly with the earlier reference to the US government's role in overseeing re-delegation. The effect, however, is to highlight the US government's role in the re-delegation process of other nations' ccTLDs.

5. DNS security

The report describes how DNSSEC works and notes concerns about the processes that create the DNSSEC "chain of trust". However, given the sources of such concerns have not attended IEG meetings, the majority of the text reflects the views of those who support the current DNSSEC trust chain.

6. Multilingualism and IDNs

The report states that internationalized domain names (IDNs) are seen as an important step in overcoming linguistic barriers to Internet access, while also highlighting views that there are a number of challenges regarding intellectual property and the IDN deployment. The report notes some countries believe the current Unicode-based IDN implementation is "effectively a patch on an ASCII-based system and that the DNS will properly refl ect multilingualism when support is native to the system".

7. Regional distribution of Root DNS Servers

The report notes that there is a disparity between the geographical distribution of Root DNS Servers and the global distribution of Internet users but does bust the myth that there are only 13 Root Servers by explaining the concept of anycasting. However, the report also points out that only three of the Root Server operators have administrative headquarters outside the USA.

WTPF-13 and other Internet-related discussions at the ITU

The ITU has held many Internet-related discussions in its meetings and Study Groups. Discussion at WTPF-13 will both be informed by these previous discussions as well as inform future discussions on the Internet at the ITU. The key interactions are described below.

World Conference on International Telecommunications

Many of the proposals submitted during the two-year preparatory process of WCIT¹⁰ contained explicit Internet-related content, including:

• Adding principles for Internet governance
• Asserting that "Member States have equal rights to manage the Internet, including in regard to the allotment, assignment and reclamation of Internet numbering, naming, addressing and identification resources"

Ultimately, the final set of International Telecommunication Regulations (ITRs)¹¹ produced in Dubai in 2012 did not include the word "Internet" anywhere. However, there are still many traces of Internet-related issues visible in the ITRs. For example, the ITRs' recognition of States' rights to access to international telecommunication services was added in response to trade blockades that prevent Internet-based services, such as electronic payments, being available in some countries. In addition, a new ITR article on accessibility to international telecommunication services is most applicable to Internet-based services (such as web services). There were strong disagreements on Internet-related issues at WCIT, and, following the intergovernmental practice of discarding proposals that cannot reach consensus amongst States, all direct references to the Internet were removed. A number of States, however, chose not to sign the ITRs — amongst them, the US government. Given the US government provides IANA with the authority to global coordinate the DNS Root and IP addressing systems, the refusal of the USA to sign the ITRs may be seen by a number of States as a sign that the USA "continues" to "control" the Internet. Many of the ideas expressed in Internet-related WCIT proposals have previously appeared in submissions to other ITU meetings, reflecting the fact that some Member States continue to feel strongly that current Internet governance arrangements — particularly the relationship between the US government and IANA — are unsatisfactory. Given the "unsatisfactory" Internet governance arrangements were not addressed in the WCIT outcomes, it is highly probable that many of the same issues will be create equally strong discussion at WTPF-13.

Council Working Group on International Internet-Related Public Policy Issues

Since 2010, the Member States-only CWG-Internet¹² — previously known as the Dedicated Group (DG) on International Internet- Related Public Policy Issues — has discussed ccTLDs, gTLDs, IDNs, IP addresses, DNSSEC, and RPKI under the banner of "critical Internet infrastructure". It has also discussed how ICANN and the ICANN GAC work. Although the group discusses many Internet issues that are currently managed under the open multi-stakeholder model of Internet governance, the CWG's documents are available only to Member States. One of the key documents produced by the group, "Internet Governance: Background Information on Mechanisms, Arrangements, Organizations and some Current Topics" is the source of much of the Secretary-General's report for WTPF-13, including information on ccTLD operations and re-delegation procedures. The Opinions produced by WTPF-13 are likely to affect future discussions within the CWG.

WSIS, the Tunis Agenda and WSIS+10

The World Summit on the Information Society (WSIS)¹³ produced the Tunis Agenda, which has become one of the key documents informing intergovernmental discussions on Internet governance. While it clearly stated that the multi-stakeholder model was the appropriate model for global Internet governance, its text on the need for "enhanced cooperation" between governments in relation to Internet governance remains the subject of debate to this day. WTPF-13 discussions on the appropriate way to further implement, if necessary, governments' roles in Internet governance result directly from differing interpretations of this Tunis Agenda text. To mark the tenth anniversary of the WSIS process ("WSIS+10"), there will be a high level event in 2014 or 2015 that will assess the implementation of WSIS goals. As the tenth anniversary of WSIS is only two years ago, governments that have been pushing for an intergovernmental organization to enhance their role in Internet governance are beginning to express their frustration at the lack of progress to date. With the WCIT outcomes not meeting their goals, the WTPF is the next major ITU event at which governments can continue this debate.

Plenipotentiary 2014

WTPF-13 is based on the Internet-related resolutions that were updated at Plenipotentiary 2010 and will, in turn, influence the Internet-related resolutions developed at the next Plenipotentiary¹⁴. Resolutions passed at Plenipotentiaries are particularly important as these meetings set the agenda for the following four years of ITU's work.

How to participate in WTPF-13

The final version of the Secretary-General will be published 1 March 2013. The WTPF-13 will be held 14-16 May 2013, in parallel with ITU's WSIS Forum, in Geneva, Switzerland. Anyone can attend the WTPF and ask for the floor to make statements.

Nominet, responsible for .uk, has already made a submission to the IEG process.¹⁵ Stakeholders can also contact their government representatives at ITU to help their government develop positions on the issues under discussion at WTPF-13. Many governments who support the multi-stakeholder model of Internet governance are also happy to place non-government stakeholders on their official delegation at meetings such as WTPF-13.

If you are unsure whom to contact within your government, a good place to start is the Participants List from WCIT:
http://files.wcitleaks.org/public/S12-WCIT12-ADM-0004!!PDF-E.pdf

All information relating to WTPF-13 is posted at:
http://www.itu.int/wtpf

¹ Given the recent WCIT held in Dubai also adopted an Internet-related resolution, it is possible that the issues it raises will also be incorporated in the next version of the Secretary- General's report.

² http://www.itu.int/osg/csd/intgov/resoultions_2010/PP-10/RESOLUTION_101.pdf

³ http://www.itu.int/osg/csd/intgov/resoultions_2010/PP-10/RESOLUTION_102.pdf

⁴ http://www.itu.int/osg/csd/intgov/resoultions_2010/PP-10/RESOLUTION_133.pdf

⁵ http://www.itu.int/en/wtpf-13/Pages/ieg.aspx

⁶ http://www.itu.int/en/wtpf-13/Pages/report-sg.aspx

⁷ http://www.itu.int/wsis/docs2/tunis/off/6rev1.html

⁸ The recent WCIT Resolution 3 (see http://www.itu.int/en/wcit-12/Documents/final-acts-wcit-12.pdf) also called on Member States to "to engage with all their stakeholders" on "international Internet-related technical, development and public-policy issues within the mandate of ITU" but stopped short of opening ITU meetings to the full participation of all stakeholders.

⁹ For example: WTSA 2008 Resolution 64, http://www.itu.int/dms_pub/itu-t/opb/res/T-RES-T.64-2008-PDF-E.pdf; WTDC 2010 Resolution 63, http://www.itu.int/osg/csd/intgov/ resoultions_2010/resolution63.pdf; Plenipotentiary 2010 Resolution 180 http://www.itu.int/osg/csd/intgov/resoultions_2010/PP-10/RESOLUTION_180.pdf

¹⁰ http://www.itu.int/en/wcit-12/Pages/default.aspx

¹¹ http://www.itu.int/en/wcit-12/Pages/itrs.aspx

¹² http://www.itu.int/council/groups/CWG-internet

¹³ http://www.itu.int/wsis

¹⁴ http://www.itu.int/en/plenipotentiary/Pages/default.aspx

¹⁵ http://www.itu.int/md/S12-WTPF13PREP-C-0024/en

Written by CircleID Reporter

Last week, we made our 1000th allocation from the final /8 and five months after reaching this point, we can report back on what we've seen so far.

Prior to reaching this milestone, the RIPE community had already developed policies to govern how the RIPE NCC would allocate the remaining space. The last /8 policy ensures that each member of the RIPE NCC can receive one final /22 of IPv4 address space (1,024 IPs) from the last /8. With approximately 16,000 /22s in a /8, and around 8,800 RIPE NCC members, the RIPE community decided that this approach would give Local Internet Registries (LIRs) some breathing room to make the transition to IPv6, and would also ensure new entrants to the industry could access IPv4 address space.

As pointed out in the most recent article RIPE NCC Membership - 2012 Statistics, the number of IPv4 allocations issued since September has remained stable. In Figure 1 below, you can see the number of IPv4 /22 allocations per week since September 2012. The numbers were a little lower in the second half of December but they increased again in January 2013.

Figure 1: Number of IPv4 allocations since September 2012 on a weekly basis

Note that the last bar doesn't show a full week but ends on 31 January — the day we handed out the 1,000th IPv4 /22.

As you can see in Figure 2, most allocations in the first two months were existing LIRs claiming their final /22 (additional allocations). This might be due to those requests that were already ongoing when we started allocating from the last /8.

Figure 2: Number of /22s as first (blue) vs. additional allocations (red) since reaching the last /8 of IPv4 address space

Since November 2012, the majority of /22 allocations were made as first allocations to new LIRs. This indicates that the last /8 policy is ensuring that new entrants in the industry can still receive a small block of IPv4 address space for the foreseeable future. This had been one of the motivations behind the RIPE community putting this policy into place.

In summary, we can say that even though the number of IPv4 allocations has been fairly consistent since September, we haven't see a big run on the last block of IPv4 addresses. Considering the fact that we have over 8,800 members, 1,000 /22s allocated over five months is a moderate number. Also, when looking at the distribution of first verses additional allocations, the last /8 policy is working to allow new organisations to enter the market.

For more information and additional graphs, please refer to the background article on RIPE Labs: 1,000 /22s Allocated from Last /8.

Written by Mirjam Kuehne

Over the last 10 years, the principle of security by design has been gaining popularity within software engineering. This concept should also be incorporated into the SDDC and cloud architectures, to ensure that organizations leveraging the promise of cloud computing will not be compromised for their forward looking thinking.

I guess it would be fair to say that perimeter security is currently the most widely used protection for IT infrastructure. By implementing firewalls, VPNs, intrusion prevention, attack detection and the like, it has been possible to deploy reasonably secure private computing environments. To complement the perimeter security, most organizations are taking further measures inside their enterprise networks, to make sure that threats are promptly detected and dealt with.

With all this in mind, it is no wonder that information security professionals are skeptic about public and hybrid clouding models. After all, both introduce a number of new attack vectors into the secured environments. But what if the hybrid cloud did not require communication with applications and servers running in the public Internet, but rather involved an architecture that was secure by design?

The problem with most IaaS cloud offerings out there today is that their hybrid offering usually relies on public IP addresses. The customers are expected to network to the extra capacity over the Internet. While this may be an easy solution for an IaaS cloud provider leveraging standard cloud stacks and DHCP, the publicly routed IP addresses assigned to the workloads introduce a new attack vector to the end-user's private network environment.

The simplest way to overcome this security issue is to create a secure tunnel between the IaaS cloud and its end-users' enterprise networks, and to assign every single workload an IP address that matched with the IP addressing scheme used in end-users' private networks. While Cisco says that VXLAN is intended for intra data center connectivity only, for example VPN could be used for tunneling just as well.

This straightforward solution brings about two major benefits. First, since the IP addresses in the IaaS cloud are part of every end-user's own IP addressing scheme, the hosts will have no trouble networking between the cloud and the enterprise network back home. Second, if the VLANs in which the workloads are deployed are not routed to the public Internet at all, they will be less prone to various security threats lurking there.

When an IP addressing model described above is merged with a dynamic DNS provisioning engine, the outcome becomes extremely powerful. After all, what organization would not want to tap into is the economics of an IaaS cloud, knowing that it was as secure as their enterprise network. This proposition becomes even more compelling when the workloads have names and IP addresses that match with end-users' own enterprise networks, making the IaaS cloud a transparent extension of one's own computing resources.

In the context of orchestrated cloud application deployment, the technologies I've outlined in this trilogy are generally related to release parameters. So rather than talking about DHCP, IP addressing or DNS as isolated technologies, I argue that they should be merged into automated and holistic Release Parameter Provisioning (RPP). More importantly, rather than trying to make cloud orchestration solutions perform tasks they are not good at, I claim that RPP merits its own layer in the SDDC and cloud stacks, functioning as a neat bridge between the SDN and the cloud orchestration layers.

Written by Juha Holkkola, Managing Director of Nixu Software

"I suppose it is tempting, if the only tool you have is a hammer, to treat everything as if it was a nail.”
—Abraham Maslow, The Psychology of Science

Until the late 90s, the networking industry largely depended on static IP address allocations. Around that time, the number of connected devices started growing rapidly, making it impossible for the network administrators to keep up much longer with the manual configuration of the equipment. To solve this problem, along came the Dynamic Host Configuration Protocol (DHCP) and the fireworks of dynamic IP assignment.

The trouble is, the networking community has not got anywhere since the late 90s. Granted, there have been new RFCs relating to DHCP along the way — DHCPv6 being the most notable example — but deep down the IP addressing paradigm has remained exactly the same. Either the addresses are static or they are issued dynamically by a DHCP server. In this regard, insofar the cloud has been no different.

When one takes a look at various cloud stacks, they mostly rely on DHCP as far as IP addressing is concerned. Admittedly, that works fine in public clouds where no one really cares what IP address is assigned to a given tenant. Ditto for private clouds, as all tenants are firmly sitting in the same enterprise network. But as soon as one gets around to multi-tenant Infrastructure-as-a-Service (IaaS) clouds, that's when DHCP goes sour.

Looking at an enterprise out there, the chances are it takes good use of a private network. Looking at two, the chances are their private networks overlap. And once you have an IaaS Cloud provider trying to service both simultaneously in a multi-tenant cloud environment, the DHCP service no longer works, unless you set up and manage a dedicated DHCP service for each enterprise end-user. Even if the IaaS Cloud provider didn't have more than a few dozen customers, DHCP would likely become a no-go. Just imagine the Operating Expense and you will know why.

Interestingly enough, VMware and Cisco both acknowledged the VLAN and IP Address Management challenges in data centers already in 2011. Their solution was Virtual eXtensible Local Networks, or VXLANs, extending the VLAN address space to gazillion available IDs.

Although I am confident that having network equipment that supports VXLAN Tunnel End Points (VTEP) allows the software defined data center to scale better, it actually does nothing to address the IP allocation issue. In fact, in isolation, it has the potential to make things worse, since in addition to allowing the managed address spaces to grow larger, it also allows the address spaces to span across a number of VLANs.

To address the root cause, the networking community has to take a hard look at the IP addressing methods used in connection with SDDC. While DHCP continues to be a good technology as far as IP allocation to physical devices is concerned, it is not well-suited for multi-tenant cloud environments. Rather, what is needed is an automated IP commissioning system that supports overlapping private networks with tagging for appropriate VLANs and/or VXLANs, with open APIs used to integrate the whole enchilada with cloud orchestration and DNS architectures.

To wrap up this SDDC trilogy, my next blog will discuss how IP commissioning should work in practice.

Written by Juha Holkkola, Managing Director of Nixu Software

Top Ten Featured Blogs from the community in 2012:

#1		DNS Changerby Paul Vixie | Mar 27, 2012 | Viewed 66,094 times
#2		Trademarking .generics - the .bank Fiasco!by Konstantinos Komaitis | Jan 18, 2012 | Viewed 17,124 times
#3		Refusing REFUSEDby Paul Vixie | Jan 11, 2012 | Viewed 11,860 times
#4		MegaBust's MegaQuestions Cloud the Net's Futureby Philip S Corwin | Feb 13, 2012 | Viewed 10,430 times
#5		Anonymous Plans to Go After DNS Root Servers. What Will Be the US's Response?by Terry Zink | Feb 15, 2012 | Viewed 9,813 times
#6		Why the Dot Com Kingdom Will Continue to Rule Post New gTLDsby Naseem Javed | Jul 24, 2012 | Viewed 9,771 times
#7		Fake Bank Site, Fake Registrarby Garth Bruen | Mar 27, 2012 | Viewed 8,977 times
#8		Why Vint Cerf is Wrongby Wout de Natris | Nov 21, 2012 | Viewed 8,891 times
#9		Internet Governance and the Public Interestby Paul Diaz | Mar 19, 2012 | Viewed 8,384 times
#10		IPv6 Subnetting - The Paradigm Shiftby Chris Grundemann | Jul 19, 2012 | Viewed 8,380 times

Top 10 News in 2012:

#1		ISPs Are Not Broadcasters, Says Supreme Court of CanadaFeb 10, 2012 | Viewed 35,128 times
#2		Iran Blocks HTTPS, 30 Million Reported Losing Email AccessFeb 11, 2012 | Viewed 11,016 times
#3		Vint Cerf: The Launch of a New Larger InternetJun 05, 2012 | Viewed 8,257 times
#4		The Digital Marketing & gTLD Strategy Congress Announces Keynote, Speakers, Initial PartnershipsJan 08, 2013 | Viewed 7,841 times
#5		Akamai Reports 460 Times Increase in IPv6 Requests Over Its Platform Since Last YearOct 22, 2012 | Viewed 6,976 times
#6		Saudi Arabia Objects to Certain Proposed New gTLD Strings Such as .Gay and .WineAug 15, 2012 | Viewed 6,764 times
#7		Department of Commerce Cancels IANA Contract RFPMar 09, 2012 | Viewed 6,343 times
#8		SPECIAL: Updates from the ICANN Meetings in TorontoOct 17, 2012 | Viewed 5,802 times
#9		Most U.S. Agencies Expected to Miss IPv6 DeadlineSep 28, 2012 | Viewed 5,411 times
#10		Websites Go Dark Protesting SOPA and PIPA, Senators Change CourseJan 18, 2012 | Viewed 5,299 times

Top 10 Industry News in 2012 (sponsored posts):

#1		MarkMonitor Offers New gTLD Application Databaseby MarkMonitor | Jun 15, 2012 | Viewed 6,992 times
#2		DotConnectAfrica Participates in ICANN-45 Toronto, Unveils New IBCA Initiative at ICANN Public Forumby DotConnectAfrica | Oct 23, 2012 | Viewed 6,822 times
#3		ICANN 45: New gTLDs Not Far Away Nowby Afilias | Oct 25, 2012 | Viewed 5,676 times
#4		MarkMonitor to Exhibit at Internet Tech Policy Exhibition and Reception to be Held on Capitol Hillby MarkMonitor | Jan 24, 2012 | Viewed 5,355 times
#5		CentralNic and REG.RU Confirm Strategic Partnershipby CentralNic | Jul 30, 2012 | Viewed 5,244 times
#6		MarkMonitor Fraud Intelligence Report, Q4 2011by MarkMonitor | Feb 17, 2012 | Viewed 5,037 times
#7		Afilias Participates in Global Test of Multilingual IDN Emailby Afilias | Jun 28, 2012 | Viewed 4,857 times
#8		Implementing a Cyber-Security Code of Conduct: Real-Life Lessons From Australia (Webinar)by Nominum | Apr 30, 2012 | Viewed 4,665 times
#9		Top-Level Domain Survey Findings Not Surprising, But Still Concerningby MarkMonitor | Sep 05, 2012 | Viewed 4,509 times
#10		Public Interest Registry Releases Results of Bi-Annual Domain Name Reportby PIR | Aug 14, 2012 | Viewed 4,462 times

Additionally, you can also check the leaderboards for CircleID's overall top 100 community and industry participants.

Written by CircleID Reporter