During the IPv6 summit in Slovenia I’ve participated in a roundtable organized by our Ministry of Higher Education, Science and Technology. One of my points was that the government should require true IPv6 support in all its IT procurement processes to promote IPv6 adoption (I have to admit I’ve borrowed a few ideas from Geoff Huston’s “Is the Transition to IPv6 a Market Failure?” article) … and one of the participants (coming from the Service Provider industry) answered that “that’s common hygiene”. I’m not so sure.
To start with, vendors will tell you that their products are “IPv6-capable” or “IPv6-ready”. The first term is (in my opinion) pure vaporware. Anything that was produced in the last 10 years can be made to run IPv6 (unless it’s a consumer product using severely limited hardware), so the “IPv6-capable” label is meaningless. For example, Cisco’s ACE Web Application Firewall seems to be IPv6-capable (translated from marketese: I haven’t been able to find a single occurrence of IPv6 in its administration or user’s guide, but I’m positive a software running on a Linux platform can be adapted to support IPv6).
IPv6-ready is more meaningful; it implies that the product actually runs IPv6. However, you should ask (at least) these two questions:
- Does IPv6 support the same functionality as IPv4? For example, split DNS support in Cisco IOS works only with IPv4 DNS servers.
- Does the product perform IPv6 operations with the same (or similar) speed as IPv4 operations?
The second question is particularly relevant for hardware-based routers and switches (one cannot imagine an application having significantly different performance when running over IPv6). These devices usually rely on ASICs and TCAM to perform high-speed packet forwarding. The TCAM width (number of bits available in a single TCAM entry) can significantly limit the wire-speed IPv6 capabilities. For example, PFC on a Catalyst 6500 cannot filter on full 128-bit IPv6 addresses and TCP/UDP port numbers.