Management Information Base for the Internet Protocol (IP)
obsoletes
Extracted elements (30)
Conformance groups for the statistics tables are stratified by interface bandwidth: a mandatory base group covers all entities, with optional groups for bandwidths between 20 MB and 650 MB and above 650 MB. This avoids requiring 64-bit HC counters on low-bandwidth devices where 32-bit counters will not wrap within a polling hour.
{ ipv6InterfaceEntry 4 } (formerly ipv6InterfacePhysicalAddress) is reserved rather than reused. Although OIDs should not be assigned before an RFC is published, some vendors shipped code based on earlier drafts, so the OID is held to avoid collisions with deployed implementations.
Object ID { ipSystemStatsEntry 2 } is permanently reserved so that the OID suffixes of the traffic counters in ipSystemStatsTable align with their counterparts in ipIfStatsTable. This makes cross-table navigation predictable for managers.
RFC 4293 was created to merge RFC 2011, RFC 2465, and RFC 2466 into a single IP-version-independent MIB. The previous documents defined separate, incompatible object sets for IPv4 and IPv6; tables such as ipSystemStatsTable now use an InetVersion index to unify them.
The MIB does not natively support multiple stacks sharing the same address type. The recommended approach is to assign each stack to a separate SNMP context, enumerated via the Entity MIB and the VACM Context Table.
When updating an IPv4-only RFC 2011 implementation: ipForwarding, ipDefaultTTL, and ipReasmTimeout are unchanged; most counter objects move to ipSystemStatsTable with new indexes; ipAddrTable converts to the substantially different ipAddressTable; ipNetToMediaTable moves to ipNetToPhysicalTable; two new required tables are ipv4InterfaceTable and ipDefaultRouterTable.
When updating an RFC 2465/2466 IPv6 MIB implementation: ipv6Forwarding and ipv6DefaultHopLimit are renamed to ipv6IpForwarding and ipv6IpDefaultHopLimit with new OIDs; IPv6 routing objects (ipv6RouteNumber, ipv6DiscardedRoutes, ipv6RouteTable) are removed from this MIB and replaced by the updated IP Forwarding Table MIB.
A row in icmpMsgStatsTable for a given ICMP type X MAY be instantiated before the first message of that type, but MUST be instantiated after it is received or transmitted. Subsequent messages of the same type must increment the relevant counter.
For objects represented by both 32-bit and 64-bit counters, the 32-bit value MUST be the low-order 32 bits of the 64-bit value. Additionally, the 32-bit counters must be included whenever the 64-bit counters are included.
ipv6InterfaceForwarding is constrained by ipv6IpForwarding and is ignored if ipv6IpForwarding is set to notForwarding. Systems without per-interface forwarding control should set this object to forwarding on all interfaces and use ipv6IpForwarding as the sole control.
IpAddressOriginTC defines five values for how an address was created: other(1), manual(2), dhcp(4), linklayer(5) (IPv6 SLAAC), and random(6) (e.g., RFC 3041 privacy addresses or IPv4 169.254/16).
IpAddressPrefixOriginTC defines five values for prefix origin: other(1), manual(2), wellknown(3), dhcp(4), and routeradv(5). It is distinct from IpAddressOriginTC: the former describes how a prefix was learned, the latter how an address was created.
ipAddressPrefixTable provides prefix information (including lifetimes) for all addresses, allowing other tables such as ipAddressTable to reference prefixes by pointer and avoid duplication. This table is required for IPv6 entities.
IpAddressStatusTC is a textual convention defining eight address states: preferred(1), deprecated(2), invalid(3), inaccessible(4), unknown(5), tentative(6), duplicate(7), and optimistic(8). Most states correspond to IPv6 stateless address autoconfiguration; IPv4 addresses default to preferred(1).
ipAddressTable lists all IPv4 and IPv6 addresses in use by this entity, including information about how and when each address was formed. It is required for all IP entities and replaces both ipAddrTable (IPv4) and ipv6AddrTable (IPv6).
ipDefaultRouterTable lists default routers known to this entity, intended for end nodes that learn router information via DHCP or IPv6 router advertisements. It is required for all IP entities; more detailed routing information is in routing-specific MIBs.
ipDefaultTTL is a read-write Integer32 (1..255) specifying the default TTL inserted into IPv4 datagram headers when no TTL is supplied by the transport layer. Changes should be persisted to non-volatile storage.
ipForwarding is a read-write INTEGER object (forwarding(1)/notForwarding(2)) controlling whether this entity acts as an IPv4 router. Changes should be saved to non-volatile storage; a SHOULD (rather than MUST) is used because the object was previously defined with weaker language.
ipIfStatsTable provides the same counters as ipSystemStatsTable but on a per-interface basis, indexed by InetVersion and InterfaceIndex. The two tables share identical object semantics; object ID 2 in ipSystemStatsEntry is reserved to keep the two tables' OID suffixes aligned.
ipNetToPhysicalTable provides a mapping between IP layer addresses and physical (link-layer) addresses, unifying ARP for IPv4 and Neighbor Discovery for IPv6. It replaces both ipNetToMediaTable and ipv6NetToMediaTable.
ipReasmTimeout is a read-only Integer32 (in seconds) representing the maximum time received IPv4 fragments are held awaiting reassembly. IPv6 specifies this value directly in the protocol, so no equivalent object exists for IPv6.
ipSystemStatsDiscontinuityTime records the sysUpTime of the most recent counter discontinuity event (e.g., system re-initialization or interface cycling). ipSystemStatsRefreshRate provides the minimum recommended polling interval in milliseconds for the counters in that row.
ipSystemStatsTable provides system-wide IP traffic statistics indexed by InetVersion (IPv4 or IPv6). It contains Counter32/Counter64 pairs for received, forwarded, reassembled, fragmented, discarded, multicast, and broadcast datagrams and octets, plus discontinuity and refresh-rate metadata.
ipv4InterfaceTable contains per-interface IPv4-specific information: ipv4InterfaceReasmMaxSize (largest re-assemblable datagram, Integer32 0..65535), ipv4InterfaceEnableStatus (up/down, read-write), and ipv4InterfaceRetransmitTime (ARP retransmit interval in milliseconds, default 1000).
ipv6InterfaceTable contains per-interface IPv6-specific information including ReasmMaxSize (Unsigned32 1500..65535 octets), the interface identifier (up to 8 octets), EnableStatus (read-write, SHOULD be persisted), ReachableTime, RetransmitTime, and per-interface Forwarding control.
ipv6IpDefaultHopLimit is a read-write Integer32 (0..255) specifying the default Hop Limit for IPv6 datagrams when the transport layer does not supply one, per RFC 2461 Section 6.3.2. Entities SHOULD persist changes to non-volatile storage.
ipv6IpForwarding is a read-write INTEGER (forwarding(1)/notForwarding(2)) controlling whether this entity acts as an IPv6 router on any interface. Entities SHOULD save this to non-volatile storage and restore it on re-initialization.
ipv6RouterAdvertTable contains non-routing information an IPv6 router uses when constructing router advertisement messages (e.g., flags and intervals), but not prefix or routing-specific data. This table is required only for IPv6 router entities.
ipv6ScopeZoneIndexTable maps IPv6 scope zones to interface groups. Zone indexes are only meaningful within a single entity and are not comparable across entities. This table is required for IPv6 entities.
Several objects in this MIB have read-write access, including ipForwarding, ipv6IpForwarding, ipv6InterfaceForwarding, ipv4InterfaceEnableStatus, and ipv6InterfaceEnableStatus. Unauthorized write access could disable IP connectivity on specific interfaces or re-configure routing behavior; SNMPv3 with authentication and privacy is strongly recommended to protect these objects.