RFC 4293
Management Information Base for the Internet Protocol (IP)
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 Notice Copyright (C) The Internet Society (2006).Abstract
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 ......................2 2. Revision History ................................................3 3. Overview ........................................................3 3.1. Multi-Stack Implementations ................................3 3.2. Discussion of Tables and Groups ............................3 3.2.1. General Objects .....................................4 3.2.2. Interface Tables ....................................4 3.2.3. IP Statistics Tables ................................4 3.2.4. Internet Address Prefix Table .......................8 3.2.5. Internet Address Table ..............................8 3.2.6. Internet Address Translation Table ..................9 3.2.7. IPv6 Scope Zone Index Table .........................9 3.2.8. Default Router Table ................................9 3.2.9. Router Advertisement Table ..........................9 3.2.10. ICMP Statistics Tables .............................9 3.2.11. Conformance and Compliance ........................10 3.2.12. Deprecated Objects ................................10 4. Updating Implementations .......................................10 4.1. Updating an Implementation of the IPv4-only IP-MIB ........11 4.2. Updating an Implementation of the IPv6-MIB ................12 5. Definitions ....................................................13 6. Previous Work .................................................116 7. References ....................................................116 7.1. Normative References .....................................116 7.2. Informative References ...................................117 8. Security Considerations .......................................118 9. Acknowledgements ..............................................120 10. 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 [9]. 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 [1], STD 58, RFC 2579 [2] and STD 58, RFC 2580 [3].
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 single protocol.3. Overview
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 entities. 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 count). 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 protocols.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 protocols.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 counted. 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 discontinuity event. 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 counter names.
from from
interface upper
layers
V V
| |
+ InReceives (1) + OutRequests
| |
| |
+--> InHdrErrors (5) +--> OutNoRoutes
| |
| |
+->-+ InMcastPkts (1) |
| V |
+-<-+ |
| |
+->-+ InBcastPkts (1) |
| V |
+-<-+ |
| |
| |
+--> InTruncatedPkts (5) |
| |
| |
+--> InAddrErrors |
| |
| |
+--> InDiscards (2) |
| |
| |
+--------+------->------+----->-----+----->-----+
| 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)
| |
V V
to to
upper interface
layers
(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
InHdrErrors.
(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 different entity. 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 incremented. 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 various circumstances. 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 this MIB.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 retained. 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 [16]. 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 IPv6 routers.
(page 13 continued on part 2)
