September 2008 Archives

More IPv6 progress

| | Comments (3) | TrackBacks (0)

More IPv6 progress around the world:

There has been a lot of IPv6 activity since my last blog post. I wanted to give folks an update.

  • Belize's top-level-domain servers are reachable over IPv6.
  • The University of California, Santa Barbara v6-enabled their DNS servers. UCSB does secondary DNS for Brown and Oregon State, and they got dragged along too.
  • ClamAV added IPv6 support in version 0.94.
  • IPv6 traffic at the Amsterdam Internet Exchange, the largest IXP in the world, continued to increase. The percentage of IPv6 traffic (compared to IPv4) hit a new peak, 0.4%.
  • Several Nokia firewalls received IPv6 Ready certification. Penn State uses Nokia firewalls for the ITS firewall service, so this is good news for us.
  • On a personal note, I had an IPv6 patch accepted into OpenSolaris. It added IPv6 support to the whois(1) utility.

The most interesting event was the APNIC 26 conference. Google's talk made the case for IPv6. We've long known that there are limits to NAT's scalability. Google is concerned that "AJAX applications break behind excessive NAT" due to ephemeral port exhaustion. Essentially, modern web apps create lots of connections, and that limits how many clients a NAT box can handle. This claim was echoed by NTT in a related talk. NTT tried to put some numbers on how many clients can be placed behind a single public IP address. They measued the number of concurrent TCP sessions created by popular "Web 2.0" services (YouTube, iGoogle, iTunes Music Store, etc), and used this to get some ballpark numbers for how many clients can be comfortably NATed. The numbers aren't encouraging.

Google had some good advice on how sites could do IPv6 deployment. They emphasized building testing and pilot services, and stressed that IPv6 doesn't have to be at parity with IPv4 on day one. I was glad to see this, since I frequently encounter defeatist thinking regarding IPv6: "Our {firewall, load-balancer, etc} doesn't support feature X for IPv6, therefore we can't do anything with IPv6!" This is simply false. IPv6 isn't an all-or-nothing proposal. While there are certainly problems, many of them aren't show-stoppers. For example, at Penn State, the ITS Wiki is IPv6-enabled, but it's not at feature-parity with IPv4. It's not load-balanced on IPv6, and the backend database isn't IPv6-enabled. The web double-sign-on system protecting it isn't IPv6-enabled either. We'll get to those issues later. For the moment, it was more important for us to do something rather than nothing. It doesn't have to be perfect on day one.