Network Working Group S. Routhier, Ed.
Request for Comments: 4293 April 2006
Obsoletes: 2011, 2465, 2466
Category: Standards Track
Management Information Base
for the Internet Protocol (IP)
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright (C) The Internet Society (2006).
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it describes managed objects used for implementations
of the Internet Protocol (IP) in an IP version independent manner.
This memo obsoletes RFCs 2011, 2465, and 2466.
Table of Contents
1. The Internet-Standard Management Framework ......................22. Revision History ................................................33. Overview ........................................................33.1. Multi-Stack Implementations ................................33.2. Discussion of Tables and Groups ............................33.2.1. General Objects .....................................43.2.2. Interface Tables ....................................43.2.3. IP Statistics Tables ................................43.2.4. Internet Address Prefix Table .......................83.2.5. Internet Address Table ..............................83.2.6. Internet Address Translation Table ..................93.2.7. IPv6 Scope Zone Index Table .........................93.2.8. Default Router Table ................................93.2.9. Router Advertisement Table ..........................93.2.10. ICMP Statistics Tables .............................93.2.11. Conformance and Compliance ........................103.2.12. Deprecated Objects ................................104. Updating Implementations .......................................104.1. Updating an Implementation of the IPv4-only IP-MIB ........114.2. Updating an Implementation of the IPv6-MIB ................125. Definitions ....................................................136. Previous Work .................................................1167. References ....................................................1167.1. Normative References .....................................1167.2. Informative References ...................................1178. Security Considerations .......................................1189. Acknowledgements ..............................................12010. Authors ......................................................1201. The Internet-Standard Management Framework
For a detailed overview of the documents that describe the current
Internet-Standard Management Framework, please refer to section 7 of
RFC 3410 .
Managed objects are accessed via a virtual information store, termed
the Management Information Base or MIB. MIB objects are generally
accessed through the Simple Network Management Protocol (SNMP).
Objects in the MIB are defined using the mechanisms defined in the
Structure of Management Information (SMI). This memo specifies a MIB
module that is compliant to the SMIv2, which is described in STD 58,
RFC 2578 , STD 58, RFC 2579  and STD 58, RFC 2580 .
2. Revision History
One of the primary purposes of this revision of the IP MIB is to
create a single set of objects to describe and manage IP modules in
an IP version independent manner. Where RFCs 2465 and 2466 created a
set of objects independent from RFC 2011, this document merges those
three documents into a single unified set of objects. The
ipSystemStatsTable and ipIfStatsTable tables are examples of updating
objects to be independent of IP version. Both of these tables
contain counters to reflect IP traffic statistics that originated in
much earlier MIBs and both include an IP address type in order to
separate the information based on IP version.
Another purpose of this document is to increase the manageability of
a node running IPv6 by adding new objects. Some of these tables,
such as ipDefaultRouterTable, may be useful on both IPv4 and IPv6
nodes while others, such as ipv6RouterAdvertTable, are specific to a
3.1. Multi-Stack Implementations
This MIB does not provide native support for implementations of
multiple stacks sharing the same address type. One option for
supporting such designs is to assign each stack within an address
type to a separate context. These contexts could then be selected
based upon the context name, with the Entity MIB and View-based
Access Control Model (VACM) Context Table providing methods for
listing the supported contexts.
3.2. Discussion of Tables and Groups
This MIB is composed of a small number of discrete objects and a
series of tables meant to form the base for managing IPv4 and IPv6
While some of the objects are meant to be included in all entities,
some of the objects are only conditionally mandatory. The
unconditionally mandatory objects are mostly counters for IP and ICMP
statistics. The conditionally mandatory objects fall into one of
several groups: objects for use in higher bandwidth situations,
objects for use with IPv4, objects for use with IPv6, and objects for
use on IPv6 routers. In short, it is not expected that every entity
will implement all of the objects within this MIB. The reader should
consult the conformance and compliance section to determine which
objects are appropriate for a given entity.
3.2.1. General Objects
In both IPv4 and IPv6, there are only a small number of "knobs" for
controlling the general IP stack. Most controls will be in a more
specific setting, such as for controlling a router or TCP engine.
This MIB defines a total of three general knobs, only two of which
are used for both IPv4 and IPv6.
Objects are included for both protocols to enable or disable
forwarding and to set limits on the lifetime of a packet (ttl or hop
The third knob, the timeout period for reassembling fragments, is
only defined for IPv4, as IPv6 specifies this value directly.
Each group of objects is required when implementing their respective
3.2.2. Interface Tables
This MIB includes a pair of tables to convey information about the
IPv4 and IPv6 protocols that is interface specific.
Special note should be taken of the administrative status objects.
These are defined to allow each protocol to selectively enable or
disable interfaces. These objects can be used in conjunction with
the ifAdminStatus object to manipulate the interfaces as necessary.
With these three objects, an interface may be enabled or disabled
completely, as well as connected to the IPv4 stack, the IPv6 stack or
both stacks. Setting ifAdminStatus to "down" should not affect the
protocol specific status objects.
Each interface table is required when implementing their respective
3.2.3. IP Statistics Tables
The IP statistics tables (ipSystemStatsTable and ipIfStatsTable)
contain objects to count the number of datagrams and octets that a
given entity has processed. Unlike the previous attempt, this
document uses a single table for multiple address types. Typically
the only two types of interest are IPv4 and IPv6; however, the table
can support other types if necessary.
The first table, ipSystemStatsTable, conveys system wide information.
(That is, the various counters are for all interfaces and not a
specific set of interfaces.) Its index is formed from a single
sub-id that represents the address type for which the statistics were
The second table, ipIfStatsTable, conveys interface specific
information. Its index is formed from two sub-ids. The first
represents the address type (IPv4 and IPv6), and the interface within
that address type is represented by the second sub-id.
The two tables have a similar set of objects that are intended to
count the same things, except for the difference in granularity. The
object ID "ipSystemStatsEntry.2" is reserved in order to align the
object IDs of the counters in the first table with their counterparts
in the second table.
Several objects to note are ipSystemStatsDiscontinuityTime,
ipIfStatsDiscontinuityTime, ipSystemsStatsRefreshRate, and
ipIfStatsRefreshRate. These objects provide information about the
row in the table more than about the system itself.
The discontinuity objects allow a management entity to determine if a
discontinuity event that would invalidate the management entity's
understanding of the counters has occurred. The system being re-
initialized or the interface being cycled are possible examples of a
The refresh objects allow a management entity to determine a proper
polling interval for the rest of the objects.
The following Case diagram represents the general ordering of the
packet counters. In order to avoid extra clutter, the prefixes
"ipSystemStats" and "ipIfStats" have been removed from each of the
| InForwDatagrams (6) | OutForwDatagrams (6)|
| V +->-+ OutFragReqds
| InNoRoutes | | (packets)
/ (local packet (3) | |
| IF is that of the address | +--> OutFragFails
| and may not be the receiving IF) | | (packets)
| | |
| | V OutFragOks
| | | (packets) (7)
| | |
+->-+ ReasmReqds (fragments) +-<-+ OutFragCreates
| | | (fragments)
| | |
| +--> ReasmFails (fragments (4)) +->-+ OutMcastPkts (1)
| | | V
| | +-<-+
+-<-+ ReasmOKs (reassembled packets) |
| +->-+ OutBcastPkts (1)
| | V
+--> InUnknownProtos +-<-+
+--> InDiscards (2) +--> OutDiscards (2)
+ InDelivers + OutTransmits (1)
(1) The HC counters and octet counters are also found at these points
but have been left out for clarity.
(2) The discard counters may increment at any time in the processing
path. Packets discarded to the left of InNoRoutes cause the
InDiscards counter to increment, while those discarded to the
right are counted in the OutDiscards counters.
(3) Local packets on the input side are counted on the interface
associated with their destination address, which may not be the
interface on which they were received. This requirement is
caused by the possibility of losing the original interface during
processing, especially re-assembly.
(4) Some re-assembly algorithms may lose track of the number of
fragments during processing and so some fragments may not be
counted in this object.
(5) InTruncatedPkts should only be incremented if the frame contained
a valid header but was otherwise shorter than required. Frames
that are too short to contain a valid header should be counted as
(6) The forwarding objects may be incremented, even for packets that
originated locally or are destined for the local host, if their
addresses are such that the local host would need to forward the
packet to pass it to the correct interface.
(7) When fragmenting a packet, an entity should increment the
OutFragFails counter, rather than the OutDiscards counter, in
order to preserve the equation FragOks + FragFails == FragRqds.
The objects in both tables are spread amongst several conformance
groups based on the bandwidth required to wrap the counters within an
hour. The base system group is mandatory for all entities. The
other system groups are optional depending on bandwidth. The
interface specific-groups are optional.
3.2.4. Internet Address Prefix Table
This table provides information about the prefixes this entity is
using, including their lifetimes. This table provides a convenient
place to which other tables that make use of prefixes, such as the
ipAddressTable, may point. By including this table, the MIB can
supply the prefix information for all addresses, yet minimize the
amount of duplication required in storing and accessing this data.
This arrangement also clarifies the relationship between addresses
that have the same prefix.
This table is required for IPv6 entities.
3.2.5. Internet Address Table
This table lists the IP addresses (both IPv4 and IPv6) used by this
entity. It also includes some basic information about how and when
the address was formed and last updated. This table allows a manager
to determine who a given entity thinks it is.
This table is required for all IP entities.
3.2.6. Internet Address Translation Table
This table provides a mapping between IP layer addresses and physical
addresses as would be formed by either Address Resolution Protocol
(ARP) for IPv4 or the neighbor discovery protocol for IPv6.
3.2.7. IPv6 Scope Zone Index Table
This table specifies the zone index to interface mapping. By
examining the table, a manager can determine which groups of
interfaces are within a particular zone for a given scope.
The zone index information is only valid within a given entity; the
indexes used on one entity may not be comparable to those used on a
This table is required for IPv6 entities.
3.2.8. Default Router Table
This table lists the default routers known to this entity. This
table is intended to be a simple list to display the information that
end nodes may have been configured with or acquired through a simple
system such as IPv6 router advertisements. Managers attempting to
view more complicated routing information should examine the routing
specific tables from other MIBs.
This table is required for all entities.
3.2.9. Router Advertisement Table
This table contains the non-routing information that an IPv6 router
would use in constructing a router advertisement message. It does
not contain information about the prefixes or other routing specific
information that the router might advertise. The router should
acquire such information from either the routing tables or from some
routing table specific MIB.
This table is only required for IPv6 router entities.
3.2.10. ICMP Statistics Tables
There are two sets of statistics for ICMP. The first contains a
simple set of counters to track the number of ICMP messages and
errors processed by this entity.
The second supplies more detail about the ICMP messages processed by
this entity. Its index is formed from two sub-ids. The first
represents the address type (IPv4 and IPv6), and the second
represents the particular message type being counted. A given row
need not be instantiated unless a message of that type has been
processed, i.e., the row for icmpMsgStatsType=X MAY be instantiated
before but MUST be instantated after the first message with Type=X is
received or transmitted. After receiving or transmitting any
succeeding messages with Type=X, the relevant counter must be
Both of these tables are required for all entities.
3.2.11. Conformance and Compliance
This MIB contains several sets of objects. Some of these sets are
useful on all types of entities, while others are only useful on a
limited subset of entities. The conformance section attempts to
group the objects into sets that may be discussed as units, and the
compliance section then details which of these units are required in
The circumstances used in the compliance section are implementing
IPv4, IPv6, or IPv6 router functions and having a bandwidth of less
than 20MB, between 20MB and 650MB, or greater than 650MB.
3.2.12. Deprecated Objects
This MIB also includes a set of deprecated objects from previous
iterations. They are included as part of the historical record.
4. Updating Implementations
There are several general classes of change that are required.
The first and most major change is that most of the previous objects
have different object IDs and additional indexes to support the
possibility of different address types. The general counters for IP
and ICMP are examples of this. They have been moved to the
ipSystemStatsTable and icmpMsgStatsTable, respectively.
The second change is the extension of all address objects to allow
for both IPv4 and IPv6 addresses and the addition of an address type
object to specify what address type is in use.
The third change is the addition of several new objects to the
replacement for a previously existing table such as ipNetToPhysical.
The fourth change is the addition of completely new tables such as
ipIfStatsTable and ipDefaultRouterTable. The first is based on the
previous statistics groups, while the second is completely new to
4.1. Updating an Implementation of the IPv4-only IP-MIB
The somewhat more specific changes that are required for IPv4 follow.
Note well: this is not meant to be an exhaustive list and the reader
should examine the MIB for full details.
Several of the general objects (ipForwarding, ipDefaultTTL,
ipReasmTimeout) remain unchanged.
Most of the rest of the general objects were counters and have been
moved into the ipSystemStatsTable. The basic instrumentation should
remain the same, though the object definitions should be checked for
clarifications. If they aren't already in a structure, putting the
counter variables in one would be useful. Several new objects have
been added to count additional items, and instrumentation code must
be added for these objects. Finally, the SNMP routines must be
updated to handle the new indexing.
In addition to the ipSystemStatsTable, the MIB includes the
ipIfStatsTable. This table counts the same items as the system table
but does so on a per interface basis. It is optional and may be
ignored. If you decide to implement it, you may wish to arrange to
collect the data on a per-interface basis and then sum those counters
in order to provide the aggregate system level statistics. However,
if you choose to provide the system level statistics by summing the
interface level counters, no interface level statistics can be lost -
if an interface is removed, the statistics associated with it must be
The ipAddrTable has, loosely, been converted to the ipAddressTable.
While the general idea remains the same, the ipAddressTable is
sufficiently different that writing new code may be easier than
updating old code. The primary difference is the addition of several
new objects. In addition, the ipAdEntReasmMaxSize has been moved to
another table, ipv4InterfaceTable. As above, the SNMP routines will
need to be updated to handle the new indexing.
The ipNetToMediaTable has been moved to the ipNetToPhysicalTable.
These tables are fairly similar and updating the old code may be
straightforward. As above, the SNMP routines will need to be updated
to handle the new indexing.
Two new tables, ipv4InterfaceTable and ipDefaultRouterTable, are
required as well as several new ICMP counters.
Finally, there are several tables that are required for IPv6 but are
optional for IPv4 that you may elect to implement.
4.2. Updating an Implementation of the IPv6-MIB
The somewhat more specific changes that are required for IPv6 follow.
Note well: this is not meant to be an exhaustive list and the reader
should examine the MIB for full details.
Two of the general objects, ipv6Forwarding and ipv6DefaultHopLimit,
have been renamed and given new object identifiers within the ip
branch but are otherwise unchanged. The new names are
ipv6IpForwarding and ipv6IpDefaultHopLimit.
While there is an ipv6InterfaceTable that contains some of the pieces
from the ipv6IfTable, the two are somewhat different in concept. The
ipv6IfTable was meant to replicate the ifTable while the
ipv6InterfaceTable is meant to be an addition to the ifTable. As
such, items that were duplicated between the ifTable and ipv6IfTable
have been removed and some new objects added.
The ipv6IfStatsTable most closely resembles the ipIfStatsTable with
an additional index for the address type and most of the
instrumentation should be re-usable. Some new objects have been
added to the ipIfStatsTable. As above, the SNMP routines will need
to be updated to handle the new indexing. Finally, the
ipIfStatsTable is optional and may be ignored.
The ipSystemStatsTable is effectively new, but it may be able to make
use of most of the instrumentation from the old ipv6IfStatsTable. As
with the IPv4 discussion, one implementation strategy would be to
count the statistics for the ipIfStatsTable and aggregate them when
queried for this table. Again, as with the IPv4 discussion, this
strategy only works if the interfaces cannot be removed or if the
statistics for removed interfaces are somehow retained.
The ipv6AddrPrefixTable is now the ipAddressPrefixTable. The new
table contains an extra object and the additional index required for
IPv4 compatibility. As above, the SNMP routines will need to be
updated to handle the new indexing.
The ipAddressTable is loosely based on the ipv6AddrTable but has
changed considerably with the addition of several new objects and the
removal of one of its indexes.
The IPv6 routing information (ipv6RouteNumber, ipv6DiscardedRoutes,
and ipv6RouteTable) has been removed from this MIB. The replacements
or updates for this information is in the update to the IP Forwarding
Table MIB . The ipv6NetToMediaTable has been converted to the
ipNetToPhysicalTable. The new table contains an extra object and the
additional index required for IPv4 compatibility. As above, the SNMP
routines will need to be updated to handle the new indexing.
The ICMP tables have been substantially changed. The previous tables
required counting on a per-message and per-interface basis. The new
tables only require counting on a per-message, per-protocol basis and
include an aggregate of all messages on a per-protocol basis.
In addition to the above, several new tables have been added. Both
the ipv6ScopeZoneIndexTable and ipDefaultRouterTable are required on
all IPv6 entities. The ipv6RouterAdvertTable is only required on