Some IPv4 /8s have been used to number IP networks in an unofficial and improper way. That is, they have been used without being properly allocated and registered in a public Whois database. In most cases these networks are mostly private, used internally in their organization, and so the addresses are not seen in the Internet’s routing system. The organizations using these addresses have relied on the overall availability of IPv4 addresses so that there was no pressing need to allocate all of the /8s that IANA manages. With the decreasing IANA free pool of unallocated IPv4 addresses, it is now clear that every last one of them will ultimately be allocated to the RIRs.

{ 2 comments }

In managing the root zone, recently we clarified some of the technical conformance criteria for the name servers top-level domain operators use. Before we put the adjusted criteria in place, we did some research to find out real world compliance against some of the metrics.
One of the more interesting insights involved looking at network diversity. [...]

{ 1 comment }

At ICANN’s meeting in Egypt last week, I had the opportunity to try and explain to various non-technical audiences why the Domain Name System (DNS) is vulnerable to attack, and why that is important, without needing a computer science degree to understand it. Here is the summary.

{ 24 comments }

IPv6 is in the news because the mainstream media have started to pick up the fact that IPv4 will be fully allocated in the next two or three years. And IPv6 deployment is important if we want to keep the Internet growing sustainably.

So where is IPv6 deployment most evident? It?s a very difficult thing to measure. It is difficult to measure the amount of IPv6 traffic as so much of it is tunneled inside of IPv4. And anyway, tunneled traffic is probably from end users rather than ISPs, but we need ISPs to deploy IPv6 to allow the Internet to grow. So how can we see where ISPs are deploying IPv6 in their networks?

{ 14 comments }

Every year there are new world events that see possible border changes and a restructure to the way the world’s countries and territories are configured. Think back to 50 years ago, and the world’s map was very different. There are literally a hundred countries that exist today that did not exist a hundred years ago. I wonder what country code the Ottoman Empire would have?

As these events occur, ICANN invariably receives requests to recognise new sovereign entities. In some cases we see very inaccurate press reports by “experts” on how country codes will be assigned. Thankfully, we have a very clear process for this that it is worth repeating.

{ 18 comments }

In February I commented about how we have been doing some research into the use of unallocated address space on the Internet.

{ 1 comment }

It is sometimes said that ISPs do not offer IPv6 transport and equipment vendors offer just partial IPv6 support because there is no customer demand. The counter argument is often made that consumers can only buy what is on offer so people prefer to buy production quality services and equipment.

Unfortunately, even when production quality IPv6 transport and network infrastructure are available it is not always possible to deploy a completely IPv6 accessible network. One problem is the difficulties domain name registrants have when they ask their domain name registrar to include their IPv6 glue in the DNS. Not many domain name registrars support glue registration for IPv6 addresses. This limits their ability to provide an IPv6 DNS service.

{ 3 comments }

Tonight on American television quiz show Jeopardy, a piece of IANA-esoterica was the “Final Jeopardy” question of the night:

{ 7 comments }

As noticed by some in the Internet network operations community, at the beginning of May an odd event occurred as ICANN ended DNS service on the IP address formerly associated with L.ROOT-SERVERS.NET (”L-root”). Specifically, as ICANN turned off the DNS service at the address formerly used by the L-root, 198.32.64.12 (and the routing announcement by ICANN for 198.32.64.0/24), DNS root queries sent to that address instead of the new L-root address (199.7.83.42) continued to be answered.

{ 19 comments }