Where IPv6 adoption is concerned, it’s natural to focus on the larger themes — themes the Infoblox IPv6 Center of Excellence routinely covers: the phased approach to IPv6 adoption, the importance of proper auditing of hardware and software, obtaining IPv6 addresses and connectivity, creating (and revising) an IPv6 address plan, and getting content online over IPv6.
One aspect of IPv6 adoption that may touch on these but is often overlooked or neglected: network management and/or monitoring and the systems that provide it.
In the past, this has been at least partly due to the fact that many vendors treated basic IPv6 support for management protocols like SNMP as an afterthought. Network hardware with generally mature dual-stack support often had no, or inconsistent, IPv6 support for management-related functions such as management interfaces, SSH, or SNMP.
In addition, management and monitoring regimes are usually built and deployed in the same ad hoc fashion as the network itself, with several applications and platforms providing a kind of patchwork of visibility and control. Operational processes relying on such a patchwork are excessively vulnerable to any one platform failing to properly support a critical protocol like IPv6.
Part of the solution to this problem is as simple as making sure that hardware and software dedicated to network management and monitoring has been subjected to the same auditing process validating IPv6 support as other critical network elements.
So what constitutes good network management support for IPv6? Version 2.0 of the Office of Management and Budget’s planning guide for IPv6 published in July of 2012 offers the following criteria:
- No dependencies on IPv4 transport or services but can utilize either transport protocol
- Ability to utilize IPv6 neighbor discovery, ND cache or SNMP MIBS, or other methods to perform network mapping if allowed within security policies
- Upgraded for the latest IPv6 and dual-stacked Management Information Bases (MIBs)
- Database and/or storage structures upgraded for IPv6 and dual stack mode
- GUI and documentation upgraded for IPv6 and dual stack.
They go on to say: “Replacing a non-conforming NMS is much more difficult than replacing other hardware or software as it tightly integrates with device software and hardware ports. Testing of all types and configuration of devices should be completed prior to system cutover and turn-up.”
The underlying message here should certainly not be to delay IPv6 adoption if one’s NMS isn’t fully IPv6-capable. Administrators may de-prioritize some network management functionality under the assumption that management and monitoring via IPv4 will be sufficient in the short-term, even as IPv6 adoption proceeds.
The general problem with this approach (even though it is often regarded as a perfectly valid and/or necessary tactical decision to prioritize other IPv6 adoption tasks) is that it often lets the vendor off the hook for properly supporting critical network management features in IPv6. And though hounding a stable full of vendors for critical feature support is nobody’s idea of a good time, it’s unfortunately a critical part of paving the way for IPv6 adoption, both within and outside the enterprise network.
With luck, your existing NMS may offer sufficient support for IPv6. Just make sure that you’ve tested what works and exposed what doesn’t. Then be sure to let your vendors hear about it. (And if they’re not already sick of your requests for IPv6 support and feature parity, you’re doing it wrong!).
And to get you started with assessing your existing NMS, here’s a list compiled by the Department of Defense High Performance Computing program displaying the status of IPv6 support for various NMS tools and systems (see section 1.5).
