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.