Today's ARIN estimated depletion date:

Archive for October, 2010

Interop returns most of 45/8


Posted by ipv4depletion  |  No Comments »

ARIN announced a few days ago that Interop will return most of their Class-A Legacy IPv4 network. This is of course great news but will not extend the IPv4 lifetime that much. We are currently burning about 1.5 /8 per month so don’t expect more than a few weeks of extended lifetime.

36/8 and 42/8 to APNIC


Posted by ipv4depletion  |  No Comments »

The IANA IPv4 address space registry now shows 36/8 and 42/8 being allocated to APNIC

Ipv4depletion now IPv6 enabled


Posted by ipv4depletion  |  5 Comments »

I have to admit that my webmaster skills suck. Some stuff doesn’t work after I moved this site to an IPv6 enabled host. I will try to resolve it as soon as possible. In the mean time, enjoy the rest.

CGN and Port starvation


Posted by admin  |  6 Comments »

There have been a lot of discussions lately on the Internet about Carrier Grade NAT. I hope the Internet community implements IPv6 instead of doing NAT444 or any other crazy Carrier Grade NAT scheme that is proposed. There are many reasons why we should avoid those schemes; however port starvation is not one of them. I’m not a fan of CGN but I want to set the record straight as the technology has been bullied for quite a while now.
One of the criticism against Carrier Grade NAT is that it there are only about 65,000 outgoing source ports that can be used. Web applications, in particular those that are using the framework AJAX are allegedly very port hungry. According to the critics of CGN the limited number of ports available could potentially put a limit on how many devices you can have behind each NAT gateway. Numbers around 8000 users per NAT device has been mentioned.
However this is not true. Most modern NAT devices are not using ONLY the source port in the state table.  Instead a combination of Source Port, destination IP and destination Port is used. This way, it is actually possible have more than one device using the same outgoing port. The only minor problem occurs when two packets to the same destination IP and destination port happens to arrive from clients using the same source port. (For example two users happened to go to at the same time and both of their browsers happens to use port 1234 as the source port) The NAT device must in this (hopefully pretty rare) case translate the Source Port as well as the IP address. Most application protocols (HTTP for example) do not really care about the source port so they survive this translation. Other applications such as DNS do not really care about the source port either, as long as the outgoing port is randomized.
When you think about it you will realize that this works just fine and that reuse of source port is widespread already. A good example is a web-server. For example, a webserver is not locked up and unable to respond to any additional requests just because somebody is downloading a 2 Gig file from it. The webserver is still able to handle multiple clients and all packets are leaving from port 80.
But again, there are many other good reasons why we shouldn’t use Carrier Grade NAT. Timeouts, end-to-end connectivity, abuse handling are just a few examples.

Guest blogging


Posted by admin  |  No Comments »

I recently wrote a guest blog about IPv6 and DNS at Steve Goodbarn’s site. Steve is the CEO of Secure64, the company I work for.

DNS and IPv6: Is your service provider ready?