RIPE NCC's IPv4 pool dropped below two /8s this week.

RIPE NCC is the registry for Europe, the Middle East, Greenland, and Russia. According to their web site, they have just under two /8s left in their pool.

Chart of remaining IPv4 addresses in the RIPE NCC region

When RIPE's pool falls to one /8, the existing allocation rules will be thrown out, and new allocation rules will go into effect. You might think of these as austerity measures -- they place significant restrictions on IPv4 allocations in an effort to preserve the final /8 as long as possible. APNIC, the Asia-Pacific registry, implemented their final /8 policy over a year ago. This means that IPv4 networking in two of the largest regions is going to get a lot harder.
Map of Regional Internet Registries

If you care about internetworking with Europe, the Middle East, Asia, or Australia, you should deploy IPv6 now.

I saw this get buried in the background of one of Apple's slides from WWDC:

iOS will  support IPv6 over Wifi and LTE

Here's a zoomed and enhanced version:

iOS will  support IPv6 over Wifi and LTE

I'm glad to see this. Welcome to the party, Apple.

iOS has supported IPv6 over Wifi for some time, so it looks like only the LTE support is new.

Today is World Pv6 Launch Day. Penn State has been busy readying our infrastructure and public-facing services for IPv6. Over the last several years, our central networking group has improved IPv6 support in our core network and with our upstream providers. Over the past several months, various units have begun adding IPv6 to their services.

Several sites are reachable over IPv6, including the College of Earth & Mineral Sciences; our central wiki; Galaxy, a web-based bioinformatics cluster; our mobile site; and our mirror server.

Several months ago, the University's IT Leadership Council formed an IPv6 Working Group. We set a goal of IPv6-enabling our major public-facing services by this fall, so stay tuned for more announcements.

Back in 2009, Netflix launched an experimental IPv6 streaming service. When they moved operations to Amazon, they lost IPv6-streaming ability, to the chagrin of v6 enthusiasts everywhere.

Now it's back. Earlier this week, Netflix relaunched IPv6 support (and you don't even need a custom URL anymore). I ran into one glitch during testing (you have to stream something over IPv4 first, then you can stream v6-only), but I'm hoping this is a temporary issue.

Streaming Nat Geo's Amazing Planet over IPv6

Streaming Nat Geo's Amazing Planet over IPv6

This should make life much easier for network operators. Netflix generates a huge amount of network traffic. As many providers are running out of IPv4 addresses, they have to find increasinly painful ways of providing access to the v4 Internet, such as large-scale NATs (Comcast's approach) and IPv6-to-IPv4 translators (T-Mobile's approach). Running all of Netflix's traffic through these systems would be painful. Now, all that traffic can avoid these performance-killing NATs.

The same reasoning applies to Google's YouTube, which generates huge volumes of traffic itself, and is also IPv6-ready.

Last week, I chided Facebook for not fully supporting IPv6. Time for me to eat some humble pie -- their CDN now supports IPv6. Looks like most of the functionality is there (chat isn't working yet, but hopefully that's coming soon). Congrats to the FB team for all their hard work!

Facebook got some attention recently for turning on IPv6 on facebook.com. Unfortunately, they didn't enable it on their CDN, so Facebook is useless over an IPv6-only connection.

By contrast, Google+ works just fine. I did a side-by-side comparison earlier today on a v6-only VM (on a network that's in Google's IPv6 whitelist). G+, on the right, shows everything. FB shows an empty white box. I've been really impressed with Google's multi-year investment in IPv6. It's really paying off.

Facebook versus Google Plus on an IPv6-only connection
Nmap has had rudimentary IPv6 support for a while, but, frankly, it's been pretty limited. A new version was just released today with much improved support.

Some highlights:

  • Raw packet support
  • OS detection
  • Neighbor Discovery ping
  • New IPv6 detection techniques (including some neat tricks with MLD and SLAAC).
This is just in time for World IPv6 Launch Day. Go update now.

Congratulations

| | TrackBacks (0)
Congratulations to everyone on a successful World IPv6 Day test yesterday. From all reports, things went very well.

I've blogged before about the shoddy support for IPv6 in Perl. Last week, Perl 5.14 was released with improved IPv6 support in the core distribution:

Improved IPv6 support The Socket module provides new affordances for IPv6, including implementations of the Socket::getaddrinfo() and Socket::getnameinfo() functions, along with related constants and a handful of new functions. See Socket.

This change brings the standard getaddrinfo()/getnameinfo() socket calls into the core library. Prior to this, developers had to use a separate module, socket6, to get IPv6-capable socket calls. This change is long overdue. The getaddrinfo() and getnameinfo() calls were first defined in RFC 2113, which published in 1997!

In 2011, I can't imagine why anyone would want to write new code in Perl, but I'm glad that the core library finally has IPv6 support. There's still a lot of legacy Perl code out there, and much of it will have to get IPv6 support. This should make that process much easier.

Just saw this on Twitter and it was too cute not to share. A larger version is available if you click on the image.