SNMP MIBs and IPv6

Contents

Introduction
Challenges with SNMP MIBs and IPv6
History of IP Protocol-Related MIBs
Current Status
Conclusion
Acknowledgments
References



Introduction

Simple Network Management Protocol (SNMP) is part of the Internet Protocol Suite from the Internet Engineering Task Force (IETF) that consists of four abstraction layers and defines a set of protocols that are used on the Internet. SNMP is mainly used for the management and monitoring of networked devices. It can inform users about the health of a network device or other reflections of its state (interfaces, IP addresses, traffic and more). SNMP is defined as part of RFC1157 from the IETF.

SNMP as a protocol belongs to the Application layer of the Open Systems Interconnection (OSI) or TCP/IP model. It uses UDP port 161 for polling and UDP port 162 for traps. It leverages information that is stored within Management Information Bases (MIBs) for its operation. MIBs define the structure of how the information about a device is stored in order to be reported via SNMP. They represent a hierarchical namespace containing object identifiers (OIDs). Each OID identifies an object that holds the information of interest and can be polled or set via SNMP. MIBs use the notation defined by ASN.1. Their implementation is vendor specific. In other words, standards define the MIB structures and it is up to the vendors to implement the MIB structure and be able to provide the information by accessing MIB OIDs. Otherwise, the vendors can implement the structures or OIDs that they chose for network monitoring and management. Given the industry need for interoperability with SNMP tools, almost all vendors chose to implement standardized MIBs.

Below is an example of an SNMP poll of a Cisco router from a Linux computer where we are polling the systemName OID of a Cisco device using IPv4 as the routed protocol.


# snmpget -v 2c -c public 10.10.10.10 iso.org.dod.internet.2.1.1.5.0
SNMPv2-MIB::sysName.0 = STRING: CiscoRouter

Since SNMP is a higher layer protocol, it is not affected by the Network layer protocol. IPv4 and IPv6 could be used without affecting the SNMP communication. For example, if we wanted to poll the same OID, using IPv6 we would use similar syntax and the information provided by the device would be the same.


# snmpwalk -v 2c -c public udp6:[fe80::10] iso.org.dod.internet.2.1.1.5.0
SNMPv2-MIB::sysName.0 = STRING: CiscoRouter

The next section will describe the challenges IPv6 brought to legacy SNMP MIBs and SNMP in general. This section will help us to follow the history of IP address-related MIBs and their current status as they have evolved to include IPv6 information.

Challenges with SNMP MIBs and IPv6

It is common knowledge that IPv6 has gained great attention, especially after the IPv4 address exhaustion reports in the first half of 2011. Indicative of the shift in interest at the time this paper was written was the World IPv6 Day that aimed to demonstrate and raise awareness about the transition to IPv6 taking place in years to come. It is easy for the reader to understand that for such a transition to occur, all IPv4 existing protocols and technologies like VPN, IPS, DNS, Routing, Network Management, and more would need to be migrated to function with IPv6. The transition would be smooth for many services, while other services could pose some challenges.

As far as SNMP is concerned, it should by default work with either IPv4 or IPv6 as its Network layer protocol. Though, there are a number of challenges that IPv6 poses to SNMP functionality and these challenges are not as much related to SNMP itself but rather to the MIB objects that are carrying network addresses. SNMP MIB OIDs contain information for multiple OSI or TCP/IP layers and thus the differences between IPv4 and IPv6 would in turn be reflected in the OIDs that are tied to them.

In more detail, problems existed in the lack of support for IPv6 in pre-existing MIB objects. These problems manifested in two ways:

  • Some MIBs only support IPv4, using the legacy ipAddress type, which cannot hold an IPv6 address.
  • IPv4 addresses are sometimes embedded information in OIDs that are not necessarily representing an IP address.

The issues mentioned above could be resolved in two ways:

  • New MIBs can be created. These MIBs could be IPv6 only or protocol-version independent (PVI).
  • Existing MIBs can be modified to add new or update existing OIDs in order to support IPv6 information.

As we will see below, the creation of PVI MIBs has prevailed with new IETF Standards that describe the newly created MIBs.

On a less important note, IPv6 brought some application implementation issues that only depend on the SNMP application that is collecting the SNMP data. These issues include IPv6 address parsing. In other words, an IPv6 address could have many representations that could "confuse" a poorly implemented application. For example, the two IPv6 addresses fe80::10:0:0:10 and fe80:0:0:0:10::10 represent the same address. Thus an SNMP server collecting information should be able to distinguish that these addresses are the same using their binary format when aggregating SNMP traps and polls and when generating reports about IP addresses.

Finally, the size of an address has now quadrupled (IPv6 address is 128-bytes where IPv4 was 32), which increases the size of the data to be carried in the payload of the SNMP UDP packets containing IPv6 address information. We do not expect that a bigger payload size will cause any issues in existing infrastructures.

The next section presents the evolution of SNMP MIBs and the developments as IPv6 integration in MIB objects is finalized.

History of IP Protocol-Related MIBs

The IPv6 protocol has existed as an IETF standard since 1998. SNMP MIBs were developed at a time when IP networks were becoming popular, almost a decade before IPv6. Thus, IPv6 was not in the mind of the IETF as the initial MIBs were being proposed and implemented. As years passed and IPv6 gradually gained traction, changes needed to be made in the MIB status quo.

It is important to present a summary of the evolution of these changes in the standards that help clarify the current situation with network devices, supported SNMP MIBs, and on what the future holds. All SNMP RFCs will not be addressed in this paper; this paper will only focus on RFCs that describe objects with IP specific information and that are affected by the implementation of IPv6.

The first definition of a MIB came in RFC1066, from the IETF, which was obsoleted by RFC1156 in 1990. As the standard says, RFC1156 "provides the initial version of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets in the short-term". RFC1156 was later extended by RFC1158 that defined "the second version of the Management Information Base (MIB-II) for use with network management protocols in TCP/IP-based internets." It practically proposed a general MIB with multiple groups for different layer protocols. RFC1158 was obsoleted by RFC1213 in 1991. Up to that point only IPv4 was taken into consideration for MIB objects.

Later, in 1996, RFC1213 was updated by RFC2011, 2012, and 2013 splitting the global MIB definition to separate IP, UDP and TCP MIB modules. RFC2011 defined the IP-MIB and made the distinction that IPv6 is not supported. Below, the reader can see the RFC2011 definitition of an IPAddress object that was assumed to be IPv4 only.


ipAdEntAddr OBJECT-TYPE
    SYNTAX      IpAddress
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
            "The IP address to which this entry's addressing information
            pertains."
    ::= { ipAddrEntry 1 }

The network management community gradually started to realize that IPv6 should be taken into consideration. Thus, RFC2465 and RFC2466 spun off in 1998. They define MIB definitions for IPv6 and ICMPv6. It is obvious that the initial direction was to follow a protocol-specific approach where different MIBs would exist for each IP version.

That approach started to change and in 2001 draft-ietf-ipngwg-rfc2011-update-00 attempted to update RFC2011 by defining managed objects used for implementations of the Internet Protocol (IP) in an IP version independent manner. Cisco also created the PVI CISCO-IETF-IP-MIB from the draft in 2003. Finally, the protocol-dependent RFC2011, RFC2465 and RFC2466 were obsoleted by RFC4293 in 2006. RFC4293 is IP version independent and defines "a single set of objects to describe and manage IP modules in an IP version independent manner." The RFC2012 and 2013 were also updated, but their changes were irrelevant to IPv6 and thus not discussed here. The RFC4293 snippet below shows the transition that now defines InetAddress could now be IPv4, IPv6, or any other type of address.


ipAddressAddr OBJECT-TYPE
    SYNTAX     InetAddress
    MAX-ACCESS not-accessible
    STATUS     current
    DESCRIPTION
           "The IP address to which this entry's addressing information
            pertains.  The address type of this object is specified in
            ipAddressAddrType.
            Implementors need to be aware that if the size of
            ipAddressAddr exceeds 116 octets, then OIDS of instances of
            columns in this row will have more than 128 sub-identifiers
            and cannot be accessed using SNMPv1, SNMPv2c, or SNMPv3."
    ::= { ipAddressEntry 2 }

Another MIB that was affected by the IPv6 transition was the IP-FORWARD-MIB that defined "objects for managing routes in the IP Internet." It was part of RFC1354 in 1992 to replace "ipRouteTable defined by MIB-II (RFC 1213)." RFC1354 was in turn made obsolete in 1997 by RFC2096. The basic change was with CIDR routes. Up until that point only IPv4 was taken into consideration for IP routing tables.

Again, the PVI train of thought arose and in 2001 there was an attempt to update of RFC2096 to be able to support both IPv4 and IPv6. That was draft-ietf-ipngwg-rfc2096-update-00 which Cisco used to create the CISCO-IETF-IP-FORWARDING-MIB in 2003. Finally, IETF came up with a PVI definition of IP Forwarding Table MIB in RFC4292 that made RFC2096 obsolete in 2006.

The most important PVI tables in RFCs 4292/93 are:

  • ipAddressTable — includes IP Address Information
  • ipSystemStatsTable — includes System wide statistics
  • ipIfStatsTable — includes Interface specific statistics
  • inetCidrRouteTable — includes Routing Table information

The following figure shows the progress of IP protocol related RFCs that were described above. The arrow text shows the RFC transitions as they were updated, extended, or made obsolete by newer ones. The color coding of the RFC depicts if it was defined as PVI. The latest (at the time this white-paper was written) IP protocol RFCs are RFC4293 (IP-MIB) and RFC4292 (IP-FORWARD-MIB).

Figure 1. IPv6 MIB-Related RFC Transitions

 

In summary, SNMP MIB objects were initially envisioned strictly for IPv4. As time passed, IPv6 had to be integrated in the existing OIDs. After an initial IPv4 or IPv6 only approach, IETF adopted a PVI avenue. The latest IETF Standards, RFC4293 and RFC4292, which are followed by the industry, describe IP protocol-independent objects in the IP-MIB and IP-FORWARD-MIB. While waiting for these standards, Cisco had come up with its own CISCO-IETF-IP-MIB and CISCO-IETF-IP-FORWARDING-MIB that were defined as being PVI, but were implemented only for IPv6 objects and tables. RFC4293 and RFC4292 are currently supported in Cisco products.

Current Status

Almost all vendors support IPv4 MIBs (RFC2011, 2096). Cisco has long supported them in almost all of its products. We already discussed the current PVI MIB definitions. Vendors are naturally expected to already have adapted or be in the process of adapting their products to support the PVI MIBs.

During the transition to PVI MIBs phase, Cisco had introduced CISCO-IETF-IP-MIB and CISCO-IETF-IP-FORWARDING-MIB that were defined as being PVI, but were implemented in Cisco products that were designed only for IPv6 objects and tables. Starting in Cisco IOS Release 12.2(33)SRC, IP-MIB and IP-FORWARD-MIB were updated to RFC4293 and RFC4292 standards. CISCO-IETF-IP-MIB and CISCO-IETF-IP-FORWARDING-MIB have been removed from the Cisco IOS releases in which the new standards have been applied. Information is now included in the new IP-MIB and IP-FORWARD-MIB. For more information, see the Cisco IOS IPv6 Configuration Guide. Of course there can sometimes be discrepancies on the implementation process and MIB changes in some products. More product-specific information for supported MIBs can be found in the MIB Locator.

MIBs can be redefined, updated, extended, or made obsolete by new ones. In fact, many MIBs get updated regularly with new objects added and old objects deprecated. The details on the objects added/deprecated are provided in the MIB definition itself. It is obvious that in the future, in order to support IPv6 functionality, new objects may be added to existing MIBs. For every set of changes in a MIB, a new MIB Revision Number is defined. The MIB revisions supported by a device are important as they ensure the accuracy of the information that is provided by SNMP. The Cisco Technical Assistance Center (TAC) can provide MIB revision information per Cisco software release version. Below is an example of the IP-MIB revisions as shown in RFC4393.


ipMIB MODULE-IDENTITY
    LAST-UPDATED "200602020000Z"
    ORGANIZATION "IETF IPv6 MIB Revision Team"
    CONTACT-INFO
           "Editor:
            Shawn A. Routhier
            Interworking Labs
            108 Whispering Pines Dr. Suite 235
            Scotts Valley, CA 95066
            USA
            EMail: <sar@iwl.com>"
    DESCRIPTION
           "The MIB module for managing IP and ICMP implementations, but
            excluding their management of IP routes.
            Copyright (C) The Internet Society (2006).  This version of
            this MIB module is part of RFC 4293; see the RFC itself for
            full legal notices."
    REVISION      "200602020000Z"
    DESCRIPTION
           "The IP version neutral revision with added IPv6 objects for
            ND, default routers, and router advertisements.  As well as
            being the successor to RFC 2011, this MIB is also the
            successor to RFCs 2465 and 2466.  Published as RFC 4293."
    REVISION      "199411010000Z"
    DESCRIPTION
           "A separate MIB module (IP-MIB) for IP and ICMP management
            objects.  Published as RFC 2011."
    REVISION      "199103310000Z"
    DESCRIPTION
           "The initial revision of this MIB module was part of MIB-II,
            which was published as RFC 1213."
    ::= { mib-2 48}

Finally, it is good to keep in mind that it is critical that regardless of the IP version protocol, SNMP must be properly secured to protect the confidentiality, integrity, and availability of both the network data and the network devices through which this data transits. SNMP provides with a wealth of information on the health of network devices. This information should be protected from malicious users that want to leverage this data to perform attacks against the network. Protection mechanisms include using:

  • SNMP Community Strings
  • SNMP Community Strings with ACLs
  • Infrastructure ACLs
  • SNMP Views
  • SNMP Version 3

For more information on securing SNMP, see the Fortify the Simple Network Management Protocol section of the Cisco Guide to Harden Cisco IOS Devices.

Conclusion

It is important to note that the time period in which this document was created. In the middle of year 2011, the MIBs have gone through the transition phase from only IPv4, to IP version specific, and then to PVI. For the past five years, the RFCs seem to have matured and the industry is already adapting as IPv6 is getting widely deployed. Cisco entered into the scene early by implementing Cisco MIBs while waiting for the IETF transition. Now, the latest RFCs from the IETF are in the process of being integrated on all Cisco platforms. We expect that MIBs will be updated regularly to accommodate for IPv6 information, but the major SNMP MIB changes to address the adoption of IPv6 have already taken place.

Acknowledgements

Author: Panos Kampanakis (pkampana[at]cisco[dot]com) is a member of the Applied Intelligence team in the Cisco Security Research & Operations organization.

References

IETF RFC search 
http://tools.ietf.org/html/

SNMP Object Navigator
http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml

MIBS supported, by Cisco product
http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml

Implementing IPv6 for Network Management in IOS
//www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipv6/configuration/12-2sx/ipv6-12-2sx-book/ip6-mng-apps.html

IPv6 MIBs supported in IOS 
//www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipv6_nman/configuration/xe-3se/3850/ip6-mibs.html

 

This document is part of the Cisco Security portal. Cisco provides the official information contained on the Cisco Security portal in English only.

This document is provided on an “as is” basis and does not imply any kind of guarantee or warranty, including the warranties of merchantability or fitness for a particular use. Your use of the information in the document or materials linked from the document is at your own risk. Cisco reserves the right to change or update this document without notice at any time.

Back to Top