Cisco Cisco Prime Network Registrar 8.0 White Paper

 

 

© 2011 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. 

Page 5 of 8 

DNS, DHCP, and FTP are not the only set members of IPv6 applications requiring attention. Any network 

management application will require modification or rewrite to fully support and manage IPv6 with parity against the 

IPv4 solutions that might be available today. The problem is not addressed by simply modifying existing IPv4 

applications with different data structures. The following should help guide your efforts when addressing possible 

changes to network management applications: 

● 

Add IPv6 stack support to the network management system (NMS): This support is paramount to 

implementing the DSTM mentioned earlier. This effort is neither trivial nor automated. Each implementation 

of an IPv6 stack along side of an IPv4 stack will require substantial effort and will have proprietary 

components. 

● 

Add IPv6 stacks to managed devices: The addition of IPv6 instrumentation and IPv6 support in network 

elements must coincide with that in the NMS itself. Many vendors do not have long-term solutions for IPv6 

instrumentation in the managed elements, using rather short-term, or point, solutions such as discrete MIBs 

rather than unified MIBs. The application migration must account for this reality. 

● 

Add full Simple Network Management Protocol Version 3 (SNMPv3) support to the network over IPv4 but 

supporting IPv6 MIBs. 

● 

Move NMS applications over the IPv6 stack: We assume, of course, that IPv6 is now native in the 

infrastructure or that tunnel mechanisms are in place to transport IPv6 through the IPv4 networks. 

● 

Add SNMP support over IPv6 transport: SNMPv3 supports IPv6 but needs to be transported itself “over” 
IPv6 instead of just “managing” IPv6. 

Applications That “Use” IPv6 

Applications that use IPv6 are as varied in design as the mechanisms they deploy internally to accommodate the 

IP transport. Most, if not all, IPv4 applications that use IP for service delivery fall into three categories: 

● 

Unicast applications: These applications are best categorized as a one-to-one service delivery model. 

● 

Broadcast applications: These applications fall into the one-to-all service delivery model. 

● 

Multicast applications: These applications use IP for a one-to-many service delivery model. 

IPv6 radically changes the IPv4 service delivery models by eliminating the broadcast paradigm and introducing the 
anycast paradigm. Anycast allows delivery to the “closest” (relative use) node of a group. Address mechanisms for 

the transition period for any IPv6 network follow: 

Many IPv4 applications use broadcast either in replacement of, or in conjunction with, Unicast addressing for 

service delivery. IPv6 architecture has both eliminated broadcast capabilities and introduced a new paradigm, 

anycast. 

Consider a pragmatic example from Mi

crosoft architecture addressing “how” to port an IPv4 application that uses 

broadcast to its IPv6 equivalent. We will use Windows Sockets as our example, but the references here, and the 

concepts, hold well for any UNIX variant as well. Because, from the perspective of an application, IPv6 Multicast 

can emulate the older IPv4 broadcast capabilities, our example will reflect how to change an IPv4 broadcast 

application to an equally useful IPv6 Multicast scenario. 

The IPv4 operationally equivalent approach is to set the IPv6_ADD_MEMBERSHIP socket option with an IPv6 

address set to link-local scope all nodes address (FF02::1). Using this address is functionally the same as using