but are you missing anything else? Use these five steps to avoid common IPv6 planning pitfalls and ease your IPv6 transition.
Now that you have followed the IPv6 migration strategy from my previous article, you are ready to implement IPv6. Simple, right? Not exactly. While it's true that most of your current infrastructure is IPv6 ready, a migration to IPv6 requires a bit more thought then simply reconfiguring devices to talk IPv6 instead of IPv4. Rather, a successful IPv6 plan requires careful attention to device capabilities, system architecture, scalability, management and provider services.
IPv6 planning pitfall #1: Hardware or software?
Most routers and switches have IPv6 support, but how these network devices forward IPv6 packets varies. High-capacity core routers typically process packets in dedicated hardware (i.e., ASICs or network processors) to speed IPv4 forwarding. But hardware architectures often don’t support IPv6; this means routers process IPv6 packets in general purpose processors, with the result being slower forwarding rates and lower capacity.
IPv6 planning pitfall #2: Applications
Most applications don’t care about the Internet Protocol (IP) of the underlying network. But some do, such as real-time services using the Session Initiation Protocol (SIP). SIP’s creators made a crucial error by including IP address information within SIP message headers. Vendors and developers of SIP-based applications must reconfigure their apps to support IPv6 information in the SIP header.
IPv6 planning pitfall #3: Carriers
Support for IPv6 is still very limited, especially for services such as MPLS and residential Internet. For example, Verizon’s FiOS lacks IPv6 support, so home/teleworkers on FiOS can’t access v6 services without some form of tunneling. Many residential routers don’t yet include IPv6 support. Meanwhile, other providers including Comcast, NTT and Hurricane Electric are already well into their IPv6 deployments. Most carriers are adopting a dual-stack architecture; they are carrying both IPv4 and IPv6 while using carrier grade NAT as a v4 to v6 gateway. But carrier grade NAT can introduce additional transit delay in the carrier’s network. And many Internet architects worry that carrier grade NAT breaks the end-to-end Internet model; this means that carriers can restrict unwanted services by not allowing them to transverse their NATs. Regardless, carrier grade NAT is perhaps the only currently viable solution to overcome not only the need for IPv4 to IPv6 interworking, but also the need to minimize IPv4 and IPv6 route propagation to reduce carrier border router resource loads.
IPv6 planning pitfall #4: Multihoming and private addressing
Multihoming is standard practice for most enterprises, but the IPv6 addressing scheme was designed as a hierarchy to summarize routes into aggregates to simplify route lookup tables. IPv6 designers didn’t anticipate the need for private IP addressing or multihoming, but enterprises demand both for security and resiliency. Creating a multihoming or v6 NAT strategy requires close coordination with your service providers and possibly obtaining your own IPv6 address space.
IPv6 planning pitfall #5: Everything else
Once you’ve solved the first four planning pitfalls, the last one may be the biggest. IP networks today consist of a lot more than routers, switches and PCs. Wide area network (WAN) optimization and management platforms, provisioning and change management applications, sensors and M2M devices, and management tools all require analysis from IT shops. IT engineers must analyze them for their ability to support IPv6, and plot either an upgrade or gateway strategy to ensure that legacy applications and devices can coexist in a mixed IPv4-IPv6 network.
Taken as a whole, these five IPv6 planning pitfalls shouldn’t scare anyone away from IPv6, but they should serve as a reminder that implementing IPv6 requires a great deal of advanced planning. Many of our clients have found benefit from engaging professional services firms with IPv6 expertise. While actual implementations are still rare, we expect that the use of third-party services will grow along with real-world deployments. Pay attention to these IPv6 planning pitfalls, and your road to IPv6 will become a tiny bit clearer.
⇒ Read our IPv6 migration guide to learn more.
This was first published in February 2011