Psst – Interested in Some Lightly-Used IP Addresses?

The Internet Service Provider (ISP) community is carefully watching the impending depletion of the unassigned IPv4 address pool. Most estimates place the depletion of the central pool of unassigned IPv4 addresses by mid-2011. After that, each Regional Internet Registry (RIR) will continue to satisfy requests for additional IPv4 space for a limited time (depending on the rate of incoming requests and the amount of address space on hand in the RIR at the time of central pool depletion).

To continue growing, ISPs require access to a steady stream of IP addresses to connect new customers. In ARIN’s service region (Canada, the United States, and parts of the Caribbean), allocation policies have resulted in growing ISPs requesting additional IP addresses every 6 to 12 months. These policies emphasize that addresses are available based on documented need per community-developed criteria; similar policies exist in the four RIRs serving the other regions of the globe.

As the available supply of IPv4 address space dwindles, ISPs are encouraged to deploy IP version 6 (IPv6), which is the successor protocol to IPv4 developed by the Internet Engineering Task Force (IETF). All of the application protocols that make the Internet a great success (e.g. HTTP for the world wide web, SMTP for email, etc.) work over IPv6, so it is predominantly a network change resulting in a new Internet that still looks to the end-user just like the IPv4 Internet today.

However, organizations looking to deploy IPv6 may be undertaking their most significant network change to date. While IPv6 has similar routing and performance properties when it comes to connecting new customers, the need to interoperate with the existing IPv4 Internet requires that ISPs must also provide IPv6/IPv4 address translation of customers’ traffic. This interoperability requirement creates a number of engineering and capital challenges that are of great concern to ISPs across the globe.

Because of these challenges, ISPs are also interested in alternatives to deploying IPv6, or ways to defer their IPv6 initiatives until a time they deem most appropriate. This is reasonable, as ISPs are businesses that must manage their resources as efficiently as possible to stay competitive, and each faces unique issues regarding the optimal time for additional infrastructure investment and deployment.

ISPs wishing to use IPv4 to continue connecting new customers for a short time post-depletion do have an option: to get usable IPv4 address space via a third-party. This approach may temporarily allow deferring the technical and capital challenges associated with introducing IPv6 infrastructure, but substitutes other potential costs and risks that may be manageable from the ISP’s perspective.

In the ARIN region, a transfer of IPv4 address space to a specified recipient is possible due to a relatively new policy that was formulated and endorsed by the community. The “Transfers to Specified Recipients” policy (contained in section 8.3 of the ARIN Number Resource Policy Manual – NRPM) recognizes that some organizations may wish to release IPv4 address space to ARIN for reassignment to a specified party that has documented need.

Since Internet number resource assignments ‘are valid as long as the criteria continues to be met’ (per IETF RFC 2050), address holders who no longer need their IPv4 addresses have always been encouraged to return them to the RIR system so that they can be assigned to those with need. In fact, many organizations (including the US Dept of Defense, BBN, and Stanford University) have returned significant amounts of IPv4 address space for the benefit of the Internet community.

It is relatively straightforward for organizations to return entire address blocks, but years of mergers, reorganizations, and equipment upgrades often result in organizations using addresses that are sparsely allocated out of many address blocks. Those that want to do the right thing and renumber to free up address space for return may face a formidable task, depending on the complexity and scale of their operation. One of the most significant benefits of the transfer policy is that it provides an incentive for the return of address space which otherwise would remain underutilized.

There are several things for organizations to consider before using this policy. First, the Specified Transfer policy provides a way of getting IPv4 address space once your need has been documented and approved by ARIN, per the normal IPv4 address space request process. (From a practical perspective, there’s very little reason for ISPs to use the Specified Transfer policy as long as ARIN has available resources for approved IPv4 requests). Second, any address space to be transferred must be under a registration services agreement with ARIN, as the process of bringing it under agreement allows for address holder verification. Later this year, ARIN will provide a listing service for organizations that have approved requests for address space and for those that may be able to make resources available for transfer.

ISPs considering extending their existing model with this approach have one additional item to consider: while continuing to use IPv4 for customer connections may be expedient in the immediate future, the cost-effectiveness of this approach will quickly diminish with the growth of IPv6-based Internet capabilities. ISPs deferring their transition to IPv6-based services will eventually have to compete with those who faced the challenge and built their IPv6 capabilities from the beginning.

Written by John Curran, President and CEO at American Registry for Internet Numbers (ARIN)

ATT holds an online IPv6 Chat Session

ATT had an IPv6 Chat Session today. See the transcript for all the details.

A Look at IPv6 Allocations Since 1999

This graph illustrates the three phases that have defined the RIPE community’s journey to IPv6 deployment since 1999. (Click to Enlarge)

In the previous graph and article published here two weeks ago, we showed that many ISPs in the RIPE NCC service region (Europe, the Middle East and parts of Central Asia) have not yet obtained IPv6 addresses from the RIPE NCC. Our latest graph demonstrates just how quickly this is changing.

In this graph you can see the number of IPv6 allocations made by the RIPE NCC to its members since 1999. Three phases are clearly visible:

Experimental Phase (1999 – 2002)

During the experimental phase allocations were made sporadically.

Early Adopters (2002 – 2007)

During this phase there was a steady flow of requests from early adopters.

Deployment (2007 – Now)

Since 2007 we have witnessed a growing number of IPv6 allocation requests.

More and more ISPs are obtaining IPv6 addresses at present, which is very encouraging. It is essential that all organisations worldwide will deploy IPv6 quickly enough to ensure the sustainable growth of the Internet.

Read more about this graph on the RIPE Labs site.

Written by Daniel Karrenberg, Chief Scientist at the RIPE NCC

New delegations from APNIC

APNIC continues to delegate large IPv4 networks to China and the rest of the region.

The network 223.240.0.0/13 or about half a million addresses was delegated to China Telecom Anhui Province. China Telecom is the largest ISP in the world serving about 55 million customers.

The networks 14.32.0.0/11 and 14.64.0.0/11 totalling around 4 million IPv4 addresses was delegated to Korea Telecom.
A quarter million addresses in the network 223.208.0.0/14 as delegated to Greatwall Broadband Network in China.

T-Mobile IPv6 Open Trial

T-Mobile USA is running an open beta (or “friendly user trial”) of their IPv6-over-cellular service. If you’re a T-Mobile USA customer, and have the right phone, you should check this out.

What’s note-worthy about this trial is that it’s self-service. Unlike the Comcast or Verizon FIOS trials, you don’t have to apply and wait for approval and new gear.

To participate in the T-Mobile USA IPv6 beta service, you must:

  • Be a T-Mobile USA subscriber with an unlimited data plan
  • Have T-Mobile coverage, not roaming or WiFi
  • Have a Nokia 5230 Nuron or the Nokia E73 Mode phone. The N900 also works, but it’s IPv6 support is much less mature.
  • Be willing to help T-Mobile improve the service, forgive us as we grow and refine the service, and accept that this beta service is not supported within any T-Mobile support channel, including Customer Care or any T-Mobile store or reseller. This Google groups forum is the only channel for IPv6 support during the beta friendly user trial.
  • Accept that the service is still evolving and that many services like Visual Voice Mail, MyAccount, MMS (picture messages), and several other services do not yet work. Web and Email both work well, but many other data services are still coming online with IPv6.

Android devices aren’t supported because of a bug with the Qualcomm chip used by many devices.

As mentioned in an earlier post, T-Mobile USA is using DNS64/NAT64, so you should expect a few kinks (but my experience with Ecdysis‘s NAT64 has been very positive).

Background radiation in IPv6

To what extent is the IPv6 Internet polluted by “background radiation”?

In earlier work we set up a number of “black hole” experiments in the Internet, where traffic can enter the experimental setup, but the setup generates no packets in response. All received packets are recorded. So far we’ve used this setup to test a number of empty address blocks that have been allocated to APNIC in recent months, including 1.0.0.0/8, 14.0.0.0 and 223.0.0.0/8.

It’s clear that these days the IPv4 Internet is now heavily polluted with various scanners and probes that attempt to detect the presence of vulnerable systems. This traffic is “dark” traffic in that it exists irrespective of whether it solicits a response from a remote system or not. The average level of dark traffic in the IPv4 Internet is an average of around 20kbps per /16, or the equivalent of a single incoming packet per address every 50 minutes.

More from http://www.potaroo.net