IPv6 Network Management: The Challenges

The challenge facing service providers (SPs), original equipment manufacturers, software vendors, and integrators is to develop robust applications that can perform various network-management operations in a changing, multivendor, multiplatform network.

Introducing IPv6 network services raises a key challenge to the network-management and systems operations support systems (NMS-OSS) architects: coping with the technical differences between IPv4 and IPv6 technologies. New challenges related to network addressing, usability, and network access have to be dealt with when IPv6 is deployed.

For instance, IPv6 addresses are awkwardly long and unsightly. Users will neither like to see long strings such as 2001:100:1234:5678:AB12:CD34:1121:2301 nor will they be able to easily recall them, let alone type them!

Furthermore, IPv6 addresses can change dynamically because of features such as renumbering, privacy mechanisms, and autoconfiguration. Dealing with dynamic addresses is not something new for network-management systems (NMSs) when it comes to managing hosts. It is, however, a bigger issue with IPv6 because dynamic address allocation can happen outside a centralized place (such as stateful Dynamic Host Configuration Protocol [DHCP] server), depriving the NMS of a convenient central repository of active hosts addresses.

From the user perspective, the IPv6 services bring up questions that revolve around ease of use. Handling the large IPv6 addresses is cumbersome, so the use of Domain Name Systems (DNS) becomes more important for IPv6 deployments. The guideline is for applications to use just host names, which are user friendly, and the DNS can take care of renumbering and fallback.

Another challenge for managing IPv6 relates to integration with IPv4 network management: How should operators manage parallel IPv4 and IPv6 services and resources, because IPv4 and IPv6 are expected to coexist for the foreseeable future?

IPv6 and IPv4 network-management concepts, requirements, and issues are much alike. This makes the challenges easier to tackle. The tools and applications necessary to meet the IPv6 network-management requirements are therefore mostly identical to the IPv4 ones. In most cases, managing IPv6 will entail providing proper IPv6 support within existing management tools, proper data availability from IPv6-enabled devices, and IPv6-enabled communications channels between the two.

Allocating IPv6 Addresses to Managed Nodes

Chapter 2, "An IPv6 Refresher," in the section "IPv6 Addressing," reviews the main IPv6 address types: unicast (link-local, unique-local, global), multicast, and anycast. It also emphasizes the fact that multiple addresses configured on an interface are common and expected with IPv6. For an NMS to communicate with an IPv6 node, it is likely that global unicast addresses (could be unique-local) will be used to manage all network elements from a central location. The network operator has multiple options in selecting the mechanism to assign global addresses to nodes: static configuration, autoconfiguration, stateful or stateless DHCPv6, or a combination of autoconfiguration with stateless DHCPv6.

From a network-management standpoint, however, not all the configuration methods are equally practical.

Static address configuration, for instance, is rather prohibitive in large-scale networks. The format, the size, and the complexity of IPv6 addresses tend to make it worse. It is not a scalable option, especially when considering the fact that renumbering is a fact of life in a network. Nevertheless, on networking devices and application servers, it is recommended to assign a static address that will be known from the NMS. In case of hardware changes, the configuration can be reloaded in the new box without change on the NMS to manage it.

Stateless autoconfiguration is an attractive alternative for hosts. However, its unpredictability might be a concern. Upon receiving multiple router advertisements (RAs) from on-link routers, a host builds multiple addresses, and the network-management station has a hard time figuring out which one to use (see the section "Topology Management" for further details) to reach the host. This may not be an issue for unmanaged hosts such as desktop and laptops.

Although stateful DHCP proves quite useful with IPv4 in helping the NMS to learn node addresses, stateful DHCPv6 is not widely available on commercial IPv6 stacks (at the time of this writing). It is, however, available on Cisco Network Registrar (CNR) 6.2 and reviewed in the section "Configuration and Provisioning Management."

Integrating IPv6 and IPv4 Network Management

Managing IPv6 nodes from the NMS requires the following elements:

• Instrumentation on IPv6-enabled devices to deliver IPv6 network-management data

• Transport of the data between the IPv6 device and NMS, using IPv4 or IPv6

• NMS application capability to handle/analyze/present the data

If network-management information transport is not supported over IPv6, IPv4 NMS applications could manage the IPv6 devices just like any other IPv4 device as long as they have IPv4 reachability from the network-management platform.

As a major evolutionary step, IPv6 introduces numerous mechanisms and features in the area of transitioning and coexistence with IPv4, including tunneling mechanisms (manual and automatic), IPv6 over MPLS (6PE and 6VPE), and translation mechanisms (NAT-PT). All these mechanisms are reviewed at length in Chapter 3, "Delivering IPv6 Unicast Services," and Chapter 7, "VPN IPv6 Architecture and Services." Although they help the coexistence of the two protocols, the transition mechanisms raise new challenges for the NMS.

When tunnels or translation mechanisms are deployed on the path from the NMS to the IPv6 devices, the NMS must be provided with the capability to traverse those tunnels. It might mean that the NMS supports some of the transitioning mechanisms, most specifically those used by hosts (ISATAP, Teredo, and so on).

Topology discovery is another area of concern with IPv6. The size of the IPv6 addresses as well as the randomization in some cases of address assignment makes it impossible for an NMS to scan the complete prefix range for active hosts. At the same time, link-locals are often the only addresses reported from neighbor caches, making the topology discovery a true challenge. In practice, topology discovery of IPv6 networks is likely to rely on IPv4, or be driven by manual configurations.

In the majority of the deployments, IPv6 is expected to coexist with IPv4, not to replace it. This comes at the cost of additional network operation complexity. To minimize this extra complexity, network operators might choose to stick with dual-stack devices, managed over an IPv4 transport, using generic (IPv4 and IPv6) management objects. It is an IPv6 transition guideline that whenever a node is not reachable through IPv6, there should be a fallback mechanism to contact it through IPv4.

Note

Minimizing network-management complexity is a bigger objective than it appears, and it can impact the network design itself. For instance, some SPs have expressed a preference for an IPv6 over IPv4 tunnel network design (see Chapter 3 for details) over deploying native IPv6 to reduce operating costs such as network management.

Dual-stack devices appear to offer a practical option for managing IPv6. The type of managed objects and the protocol used to transport the information are independent. For instance, Simple Network Management Protocol (SNMP) can run over IPv4 or IPv6 and report IPv4 or IPv6 Management Information Bases (MIBs). IPv6 configuration management or IPv6 topology management can be operated over IPv4 with minimum changes in the tools and in the operator habits.