A month ago, I noted some improvements in IPv6 management networks. I have some more positive news for ET's management network.
Our group is moving to a new office location this fall. We'll be out of the Computer Building, across campus from the machine room. So we wanted a small server to keep in the new office, so we ordered a Dell PowerEdge T610, a small tower. It turns out Dell's iDRAC6 remote management card supports IPv6:
If I'd been more up-to-date on DISA's IPv6 compliance list, I wouldn't have been surprised by this.
Sadly, the IPv6 stack is disabled by default. But at least it's there.
Two weeks ago, I noted that Netflix was accessible over IPv6. At the time, it was only their website, not their streaming service. Today, at NANOG 46, Netflix announced that their streaming service now supports IPv6.
Here's a screenshot of my Vista box running IPv6-only and streaming Serenity. Notice that there's no IPv4 address on the box.
(click for larger image.)
There were several interesting bits in Netflix's slidedeck. Their Content Delivery Network, Limelight, announced IPv6 support today. This is huge, as they're the first CDN to announce production IPv6 support. Lack of IPv6 support in CDNs has been cited again and again as a primary factor in not deploying IPv6 on large content sites.
To my mind, there were two big points in Netflix's presentation:
- IPv6 is easy. On Netflix's end, the entire deployment, from idea to production service, took two months. Limelight only tasked two engineers to work on IPv6 support.
- "Load Balancers are easy." Alleged lack of IPv6 support in loadbalancers is a common canard that's totted out again and again when folks talk about production IPv6 deployments. I was so glad to see a large Internet content provider dispel this myth. Netflix even posted sample config for IPv6 on a Citrix Netscalar in their slidedeck.
Hats off to Netflix and Limelight for this.
Cell phone carriers have seen a huge growth in wireless data usage. The iPhone is selling like hotcakes, and its users generate large amounts of traffic. Not surprisingly, as cellular providers deploy faster network technologies, users generate even more data. Here's data from Verizon:
Customers' demand for more, faster connectivity is pressuring cell carriers to accelerate their timelines for deploying next generation cellular technologies (the so-called "4G" technologies). One of the most promising of these technologies is LTE, Long Term Evolution. LTE will provide much more bandwidth than current 3G cellular system.
Aside from speed, LTE makes a significant change to cellular networks: Voice is now an IP service. With LTE, your handset is a voice over IP (VoIP) device. This eliminates the distinction between the "phone part" of your smartphone (voice calls, SMS, voicemail), and the "Internet part" (email, web, games, etc). In other words, your phone will need an IP address all the time, even just to receive voice calls.
Independently, the number of cellular subscribers is increasing rapdily. According to the United Nations, more than 40% of the world population has a cell phone:
One research company predicts there will be 5.2 billion cellular subscribers, worldwide, by 2011. Another firm estimates 2 billion new cellular subscribers by 2013. If even a small fraction of these are using 4G, e.g. IP-based, communication, it will place substantial strain on IPv4 address reserves.
The problem, of course, is that we're running out of IPv4 addresses. The IANA pool will most likely be depleted by the end of 2010. This has led many people to wonder if LTE deployments will require IPv6. Now we have an answer: Yes.
Verizon has posted specs for any LTE device that will be permitted on its LTE network. IPv6 support is mandated. IPv4 is optional. That's quite a statement, since IPv4 traffic currently dominates the Internet.
A few relevant quotes from Verizon's spec:
"The device shall support IPv6. The device may support IPv4. IPv6 and IPv4 support shall be per the 3GPP Release 8 Specifications (March 2009)". (section 3.2.4.1)
and
"The device shall be assigned an IPv6 address whenever it attaches to the LTE network." (section 3.2.4.2)
IPv4 support appears optional: "If the device supports IPv4, then the device shall be able to support simultaneous IPv6 and IPv4 sessions." (section 3.2.4.4)
Verizon appears to be trying to conserve IPv4 addresses by disallowing long-term address leases: "If the device supports IPv4, the device shall request an IPv4 address if an application using the LTE bearer requests a data connection using an IPv4 address. Once the application is closed, the IPv4 address shall be released by the device". (section 3.2.4.3)
I'm curious how this will affect handset manufacturers. Windows Mobile and Symbian (used in Nokia phones) already support IPv6. Google is working on IPv6 support in Android. The iPhone and Blackberry don't currently support IPv6. I'm curious if version 3.0 of the iPhone OS will add IPv6 support.
Back in Febrary, Netflix got an IPv6 allocation from ARIN. Now, they're running an IPv6 test: http://ipv6.netflix.com/.
Like ipv6.google.com, it's an IPv6-only site.
You can't stream video over IPv6, but you can go to their web site and manage your queue.
That's pretty cool. I hope this spurs more large content providers to start deploying IPv6.
Today, Microsoft released Service Pack 2 for Vista and Windows 2008. There's a noteworthy IPv6 bugfix in SP2 regarding DHCPv6. Vista probably has the best DHCPv6 support of any OS I've used (in that its DHCPv6 client actually works and doesn't require extensive, manual configuration).
It does have one bug: It mangles DNS search domain lists (e.g., "foo.psu.edu, bar.psu.edu, psu.edu"). Windows 2008 SP 1's DHCPv6 server malforms the list, and Vista SP1 expects the list to be malformed. Things work fine if you have Microsoft DHCPv6 software everywhere, but in mixed environments, the DNS search domains will get broken.
This is fixed in SP2 for Windows 2008 and Vista. Happy patching.
Today, VMware released vSphere 4.0. vSphere 4.0 has several new IPv6 features:
- IPv6 TSO and checksum offloading
- Service Console is reachable over IPv6
- vmkernel has IPv6 support
In ET, we've made IPv6 support an issue. Fortunately, we can manage our IP-based serial consoles and our IP-based KVM over IPv6. Even our networked printer can be managed over IPv6 (following an upgrade to a newer JetDirect card). If you're careful about what you buy, you can get a fair bit of your management network IPv6-ified.
Now if IBM would just add IPv6 support to the BladeCenter Management Module....
A few months ago, I made a post about IPv6 security. I've caught some flak for saying that IPv6 isn't a security issue. I still stand by this position.
This is not to say that you should ignore security considersations when deploying IPv6. All I claim is that deploying IPv6 in and of itself does not make an organization any more or less secure. This point was made by Dr. Joe St. Sauver, of the University of Oregon, in an excellent talk on IPv6 security at the Winter 2009 Internet2 Joint Techs meeting (video is also available). Joe's talk is the most level-headed analysis of IPv6 security I've seen. I highly recommend watching it.
Earlier this month, Derrick Webber posted an article entitled, "The coming IPv6 security disaster". For the most part, I agree with his conclusion: If organizations wait to deploy IPv6 until IPv4 is depleted, they will most likely rush to deploy IPv6, and the ensuing sloppiness will have security implications. But this doesn't seem to me to be an IPv6-specific issue; the same could be said for practically any technology (in his defense, Weber admits this).
Having said that, there are aspects of IPv6 which need to be addressed. These include securing Router Advertisements, handling fragment reassembly and analysis, and the lack of NDP and DHCPv6 inspection in edge switches.
Another common concern are the "transition" mechanisms, such as dual-stack and tunneling. Securing dual-stack networks isn't that difficult: For the most part, you mirror your security policies from IPv4 to IPv6 (accomodating protocol-specific differences, such as ICMPv6 filtering). As for tunneling, I don't have much good to say about it. I certainly recommend avoiding 6to4 and Teredo whenever possible. Both systems tend to be very slow. Many firewalls can't filter them (but most firewalls can't filter many other tunneled protocols either). I understand that it's easy for me to dismiss tunneling, since I work at an institution with native IPv6 access. If you're going to tunnel, at least use a static one from a reputable tunnel broker.
Of course, with any code, there are bound to be implementation bugs. Most recently, Stephan Lagerholm alterted the IPv6 community to a particularly nasty ICMPv6 bug that was patched in Mac OS X 10.5.7 (so go patch if you haven't already). Of course, the 10.5.7 update fixed several other remotely exploitable bugs that have nothing to do with IPv6, some of which are pretty serious. To repeat a line from my earlier blog post: Implementation bugs in any piece of software are inevitable. When we find them, we patch the affected systems. This is true of IPv4, IPv6, Apache, sendmail, IOS, OpenSSL the VMware hypervisor, etc. Keep your wits about you, and sign up for the appropriate mailing lists.
At Penn State, as part of ITS' IPv6 planning process, I've been working with our security office to develop list of security requirements for IPv6-only networks. In other words, if a unit wants to deploy an IPv6-only network, what does ITS have to do first, to enable them to be incompliance with various University policies (such as AD-20 and iPAS Phase II). It's more of a hypothetical exercise today, as we could use private IPv4 addresses to contact internal resources (such as update servers, syslog servers, etc), but it was still a very useful exercice. The good news is that we're well on the way to IPv6-enabling several of these services (watch this space, big announcement should be coming soon).
By the way, I can't say enough positive things about the book, IPv6 Security by Scott Hogg and Eric Vyncke. It's an excellent book that covers the common attacks on IPv6 networks, and presents a realistic, vendor neutral view of the current state of IPv6 security. For readers at Penn State, the book is available online via the University Library's Safari subscription. I also encourage PSU readers to consult the IPv6 Security page in the University Wiki.
Deploying IPv6 won't make you any more or less secure. But like any "new" technology, it takes time to deploy it right. So start now!
It's been a few months since my last stats update, and there's been some progress:
New IPv6-reachable DNS:
- Northern Lights GigaPOP
- University of Minnessota
- University of Washington
At Penn State, we IPv6-enabled one more of our root servers, bringing our total to 50%.
For the top-level domains, we picked up a few more IPv6-reachable domains: Madagascar, Macau, and Somalia. But we lost Niue.
Internet2 Email:
There's been good progress IPv6-enabling DNS in Internet2, but much less progress with email servers. Recently, there's been some progress: University of Maine and Virginia Tech have IPv6-enabled their incoming mail servers. However, the University of South Florida took down their IPv6 mail server in late March. Only five members of Internet2 have IPv6-reachable email servers:
- 3ROX
- KanREN
- UCLA
- U. Maine
- Virginia Tech
This doesn't compare favorably to the 45 I2 members with IPv6-reachable DNS.
Yesterday, the IANA allocated two /8s to the Asia-Pacific region. The global IPv4 pool is down to 11.7% free:
Except that it's actually a little less than 11.7%. Last month, the "n=1" proposal was adopted by ICANN. This policy sets aside one /8 for each Regional Internet Registries (RIRs):
There are five RIRs. If you exclude the five reserved /8s, the IPv4 pool has only 25 /8s free, or 9.7%. That's a pretty sobering reality.
Several of the RIRs have released their 2008 annual reports. 2008 was another record year for IPv6 allocations:
The above image (taken from the RIPE NCC 2008 Annual Report) shows IPv6 initial allocations by the regional registries. The blue line is Europe, Middle East and parts of Asia. The green line is the US and Canada. The purple line is the Asia/Pacific region (including Australia). All three regions showed enormous growth in IPv6 allocations from 2007-2008.
This is good news, since we'll need every year from now on to be a record year if we're going to get IPv6 deployed in any reasonable timeframe.
It's interesting that Africa (the red line) and Latin America (the yellow line) didn't show any real growth. Those regions could be acutely affected by IPv4 depletion, as they have very few IPv4 addresses to begin with.
