World IPv6 day, where Web properties around the world test drive their sites using the IPv6 protocol, is today. It’s not a holiday by anyone’s real stretch of the imagination, nor is it a full-on switch-out. But it will be a milestone in the ultimate, slow transition from current IPv4 addressing to IPv6 addressing.
According to the Internet Society’s FAQ page on the event, “is a global-scale test flight of IPv6 sponsored by the Internet Society. On World IPv6 Day, major Web companies and other industry players will come together to enable IPv6 on their main Web sites for 24 hours. The goal is to motivate organizations across the industry — Internet service providers, hardware makers, operating system vendors and Web companies — to prepare their services for IPv6 to ensure a successful transition as IPv4 address space runs out.”
Basically this is one big 24-hour awareness event to prepare us all for what life will be like after all the current 32-bit IP addresses run out.
Oh, wait, that already happened.
There is no sign of any kind of catastrophic collapse now that there’s no more unallocated IPv4 addresses, but there is a little bit more urgency in the efforts to get people to pay more attention to IPv6. But the fact that there’s no Year 2000-type disaster looming in the headlines seems to have put a damper on IPv6 network deployments.
The trick to implementing IPv6 may be not treating it as a upgrade migration project — at least in traditional terms. When you upgrade software, for instance, the older version of the software is typically removed, and your organization must deal with the consequences — good and bad — of the new software version.
But when implementing IPv6, there’s no reason to eliminate IPv4. In fact, you would not want to, because a vast majority of networked servers will still roll with IPv4 in a dual-stack or tunneling scenario for a long time. Instead, when you swap out existing infrastructure for any reason, all you need to do is just make sure the new equipment or software is IPv6-compliant. Then it’s just a matter of taking a little extra time to make sure IPv6 is running alongside IPv4 for that new component.
That’s a piecemeal way of solving the problem, of course. Even as you roll out IPv6-compatible components, you will also need to identify all of the components in your infrastructure that actually need IPv6. It could be a big list, depending on the size of your organization, because there’s a lot of IT assets that are network enabled. Client computers, Web servers, file servers, printers, routers, WiFi, firewalls, switches… even any mobile device your organization for which has responsibility.
Without a complete inventory, there could come a day when your organization will switch over to IPv6 and discover gaping deadzones in your network topology because of one forgotten switch somewhere.
The new protocol is about more than just packets. You also need to make sure IPv6 can do the tasks you need it to do. IPv6 is a protocol that is still relatively immature as an application platform. There are still a lot of things that IPv4 can do that IPv6 users can’t, because there may not be networking applications that are IPv6 ready.
In May, for instance, Cisco took a big step forward in solving this problem when it released a new version of its IOS platform with a reported 200 new IPv6 features.
“Our biggest goal in IOS now is to have parity between IPv4 and IPv6,” Faraz Aladin, director, Marketing Cloud Switching and Services at Cisco told InternetNews.com. “Whatever you can do in IPv4, you should be able to do with IPv6.”
Some of this is really basic stuff, too. The Cisco announcement in May highlighted the availability of the Network Time Protocol in IPv6. But in truth, any application that uses IP addresses will need to be updated.
Finally, you will need to make a plan on how to handle network security. There are some experts who are suggesting that you won’t need network allocation tables (NATs) at the edges of your network anymore. With 2
Right now, security is probably the biggest question mark for IPv6 deployment, because network security relies in well-defined network edges, ideally guarded by the firewall. If NATs went away, the firewall would have to maintain security across a fuzzier boundary. It’s been suggested that with the huge network segments available in IPv6, malicious hackers would have to scan your network segment for years to find a potentially vulnerable target. Great, but what if you have to run the same kind of scan for internal vulnerabilities?
Another potential angle of attack: IP options in IPv6 like destination or authentication information aren’t found in the main header, but in extension headers. This means an IPv6 packet is roughly put together like this: Main header and extension headers and packet content. Malicious packets could contain specific extension information or just a ton of junk extension data that might potentially choke the target device.
Security, then, will be the space to watch as you start moving towards IPv6. You must make sure you have efficient security tools in place that follow the best practices–which are even now being put together. Until these issues are solved, start making that inventory, and analyze which applications use IP addressing. Then you will be ready to swim into IPv6 when the lifeguards say the water is safe.