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.

Here's a zoomed and enhanced version:

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.

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.

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

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.

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.

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.

(credit to Paul's Random Crap for noticing this).

Back in 2009, I reported that Verizon mandated IPv6 support in LTE devices. It's good to see that they've taken the next step and enabled IPv6 on their network, and that they're doing so with globally routable addresses. On a personal note, I'm quite happy about this, as Verizon is slated to bring LTE to State College by mid-year. This will probably be enough to get me to jump ship to Verizon and pick up a Droid Bionic.

The IANA has been sitting on five /8s (one per regional registry), and these will be handed out (along with the fragments from the legacy class B space), one to each registry. The IANA IPv4 registry doesn't yet reflect this.

This is the first milestone in IPv4 depletion. The regional registries will start to run out later this year. Most likely, Asia-Pacific will run out first, followed by Europe, then North America. The South American and African registries will last longer, as there's much less demand for IPv4 addresses in those regions.

The Asia-Pacific registry estimates it will run out of IPv4 by the end of this summer.

It was fun while it lasted.

Nevertheless, forward-looking organizations realized that they needed to start deploying IPv6. They did this by putting IPv6 at a different URL (such as ipv6.google.com or www.v6.facebook.com), or by whitelisting approved domains for IPv6 access. These approaches let them get operational experience with IPv6 without impacting the vast majority of IPv4-only users (currently estimated at over 99% of the Internet). Nevertheless, URL tricks and whitelisting aren't scalable, long-term solutions, and there's a desire to see what would happen if we lit up IPv6 for real. Some sites have bitten the bullet and turned on IPv6 on their main site, with few problems. Others are more timid and want a limited-scope trial. Hence, IPv6 Day.

I'm certainly in favor of this, but the timing concerns me. The IANA IPv4 pool (the central pool of IPv4 addresses) is due to run out any day now, but IPv6 Day isn't for another six months. So, we'll end up doing out first large-scale production test of IPv6 after the first milestone of IPv4 depletion. This concerns me. The IT industry as a whole has dragged its feet with IPv6 for over a decade. Further delay seems ill-advised. I'm also worried that sites will turn off IPv6 at the end of the day. At the point, we should be leaving IPv6 enabled everywhere we can, unless there's a major problem. I hope that the hard work of many organizations leading up to IPv6 Day will mitigate most of the problems, and that we can use the results as reason to turn IPv6 on and leave it on.

Nevertheless, I give kudos to sites like Yahoo for stepping up and participating, even if it means some short-term breakage. The need to deploy IPv6 is too urgent to let fears of short-term problems paralyze us. I hope other sites with IPv6 pilots participate, like CNN and Wikipedia.

Penn State readers, consider this my public call to you to enable IPv6 on your services. Our internal audits reveal high levels of IPv6 support in several major services. Several highly visible services could be IPv6-enabled very easily (by slapping v6 addresses on a few load-balancers). Network admins should also deploy IPv6 to client machines, to increase the audience for IPv6-accessible content (it will also help reduce breakage from user-created IPv6 tunnels). There's no reason, other than willpower, why PSU can't participate in IPv6 Day.

IPv6 is on our networks whether we put it there or not. Let's step up, treat it as a production service, and deploy native IPv6 rather than let unsuspecting students and staff do it for us with tunnels.

And, no, I didn't buy the shiny laptop. Even if it is really svelte.