Tech-invite3GPPspecsSIPRFCs
898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100

in Index   Prev   Next

RFC 4293

Management Information Base for the Internet Protocol (IP)

Pages: 122
Proposed Standard
Errata
Obsoletes:  201124652466
Part 1 of 6 – Pages 1 to 13
None   None   Next

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

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.
Top   ToC   RFC4293 - 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   RFC4293 - 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 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.
Top   ToC   RFC4293 - 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 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
Top   ToC   RFC4293 - Page 5
   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.
Top   ToC   RFC4293 - Page 6
 from                                            from
 interface                                       upper
                                                 layers

  V                                               V
  |                                               |
  + InReceives (1)                                + OutRequests
  |                                               |
  |                                               |
  +--> InHdrErrors (5)                            +--> OutNoRoutes
  |                                               |
  |                                               |
  +->-+ InMcastPkts (1)                           |
  |   V                                           |
  +-<-+                                           |
  |                                               |
  +->-+ InBcastPkts (1)                           |
  |   V                                           |
  +-<-+                                           |
  |                                               |
  |                                               |
  +--> InTruncatedPkts (5)                        |
  |                                               |
  |                                               |
  +--> InAddrErrors                               |
  |                                               |
  |                                               |
  +--> InDiscards (2)                             |
  |                                               |
  |                                               |
Top   ToC   RFC4293 - 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
 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.
Top   ToC   RFC4293 - 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
       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.
Top   ToC   RFC4293 - 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   RFC4293 - 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
   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.
Top   ToC   RFC4293 - 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 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.
Top   ToC   RFC4293 - 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   RFC4293 - 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 Section