tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 4293

Proposed STD
Pages: 122
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: IPV6

Management Information Base for the Internet Protocol (IP)

Part 1 of 6, p. 1 to 13
None       Next RFC Part

Obsoletes:    2011    2465    2466

Top       ToC       Page 1 
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).


   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.

Top       Page 2 
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 ......................................................120

1.  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].

Top      ToC       Page 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

   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.

Top      ToC       Page 4 
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

Top      ToC       Page 5 
   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
   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.

Top      ToC       Page 6 
 from                                            from
 interface                                       upper

  V                                               V
  |                                               |
  + InReceives (1)                                + OutRequests
  |                                               |
  |                                               |
  +--> InHdrErrors (5)                            +--> OutNoRoutes
  |                                               |
  |                                               |
  +->-+ InMcastPkts (1)                           |
  |   V                                           |
  +-<-+                                           |
  |                                               |
  +->-+ InBcastPkts (1)                           |
  |   V                                           |
  +-<-+                                           |
  |                                               |
  |                                               |
  +--> InTruncatedPkts (5)                        |
  |                                               |
  |                                               |
  +--> InAddrErrors                               |
  |                                               |
  |                                               |
  +--> InDiscards (2)                             |
  |                                               |
  |                                               |

Top      ToC       Page 7 
  |  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

   (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.

Top      ToC       Page 8 
   (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.

Top      ToC       Page 9 
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.

Top      ToC       Page 10 
   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
   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.

Top      ToC       Page 11 
   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

   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.

Top      ToC       Page 12 
   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.

Top      ToC       Page 13 
   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)

Next RFC Part