Summary

  • RFC 2011 moved the remaining MIB-II IP and ICMP objects into an SMIv2 module and required the ipGroup and icmpGroup for compliance, but the IESG Note explicitly said its four-octet IpAddress type supported IPv4 only.
  • A readable address table or rising counter proved facts inside that declared object population. It did not prove that IPv6 addresses, prefixes, routes or neighbors were visible, nor that a configuration change had taken effect or a failure cause was known.
  • RFC 2465 first built a separate IPv6 management surface; RFC 4001 made address family an explicit companion to address value; RFC 4293 later unified the lineages and treated re-indexing and new instrumentation as implementation work.

A correct answer from a bounded world

Consider an agent that compiles the module, exposes every mandatory object and answers every authorised read. ipInReceives rises. ipAddrTable returns rows. The compliance checklist is green. Nothing in that sequence is false.

The mistake begins when “compliant with this MIB” is expanded into “the node's IP behavior is covered.” RFC 2011 did not leave that boundary implicit. Its IESG Note said that the IP, UDP and TCP MIB modules then supported only IPv4 because IpAddress represented a 32-bit address as an OCTET STRING of length four. They did not support 128-bit IPv6 addresses.

That was not a minor display limitation. In the IP group, ipAdEntAddr both named an address and indexed the row. Its netmask was another IpAddress. The network-to-media table also used an IpAddress in the row identity. A type decision therefore shaped what rows could exist, how a manager addressed them and what a walk could ever discover. An absent IPv6 row was not necessarily a reported fault. In this model it was unrepresentable.

What compliance actually covered

RFC 2011 had a precise historical job. MIB-II had defined IP and ICMP objects in the SNMPv1 framework. IP route management had already been updated separately by RFC 1354. RFC 2011 took the remaining objects and defined them under SNMPv2. Its module description expressly excluded management of IP routes.

The ipMIBCompliance statement required two groups for an SNMPv2 entity implementing IP. The IP group covered forwarding status, default TTL, input and output statistics, reassembly and fragmentation, address rows, network-to-media mappings and routing-entry discards. The ICMP group covered message and error counters. That is substantial instrumentation. It is also a declared set, not a synonym for the whole network.

Even within the set, the counters preserve different denominators. ipInReceives includes input datagrams received in error. ipInDiscards counts datagrams discarded despite no processing defect, but excludes discards while awaiting reassembly. ipOutNoRoutes counts datagrams discarded because no route could be found. ipReasmFails is not necessarily a count of discarded fragments. A rising integer says that a defined population changed. It does not identify the packet, address family, route decision, affected service or root cause.

The same caution applies to writable objects. ipForwarding and ipDefaultTTL were read-write, and network-to-media rows could be created or invalidated. A successful read proves visibility. A successful protocol response can prove acceptance. Neither alone proves who authorised the change, whether it persisted, which stack used it, whether forwarding behavior changed or whether a remote destination became reachable.

IPv6 first arrived beside the old model

RFC 2465 did not stretch the four-octet slot. In 1998 it defined a separate IPv6 General group. Its six tables covered IPv6 interfaces, per-interface statistics, prefixes, addresses, routes and network-to-media mappings. IPv6 addresses used a 16-octet string. The document stressed that this could be implemented without changing SMIv2 or compliant SNMP implementations.

That separation solved representation while creating a management join. A dual-stack operator needed to know which MIB families an agent implemented, which tables a collector queried, how interface identities aligned and whether dashboards combined or silently preferred one family. Passing RFC 2011 compliance did not fail because RFC 2465 existed. It simply remained evidence about the IPv4 side of a larger estate.

RFC 4001 later made the modeling lesson reusable. InetAddress carries a generic address value only in the context of InetAddressType. When used in an index, the type precedes the address and its length. The specification warned against binding object definitions to one address format. Yet it also allowed compliance statements to require only a subset of address types. The pair made coverage explicit; it did not make broad coverage automatic.

Unification became a migration control surface

RFC 4293, published in 2006, obsoleted RFC 2011, RFC 2465 and the separate ICMPv6 MIB. It created one IP-version-independent module. System and interface statistics gained an IP-version discriminator. Address objects acquired an address type. New prefix, default-router and physical-neighbor structures clarified information that the older split models could not express uniformly.

The revision history is unusually candid about the cost. The old ipAddrTable was only loosely converted to ipAddressTable; the new table was different enough that writing new code might be easier than updating old code. SNMP routines had to handle new indexing, and new counters required instrumentation. A standards document could define the destination schema. It could not migrate an agent, collector, archive, alert, runbook or operator decision on publication day.

This is where conformance becomes a control-plane fact rather than a decorative badge. During transition, an accountable inventory needs the implemented module revision, supported address types, SNMP context, queried tables, object instances, collection time and the downstream rule that consumed the result. Without those joins, a green check can hide a blind family, and a combined graph can hide two incompatible measurement surfaces.

Sources

Evidence limits

These sources establish specification status, object syntax, conformance groups and successor design. They do not establish vendor defects, deployment share, a present outage, a named network's monitoring coverage, SLA performance or the date on which any implementation migrated.