Summary

  • RFC 2452 kept most TCP management objects—including tcpActiveOpens—independent of whether IPv4 or IPv6 carried a connection.
  • Its separate IPv6 table added ipv6TcpConnIfIndex because four endpoint values could not always identify one connection row on a managed node.

One counter did not need a second name

The IPv6 transition could have produced a tidy but misleading split: one set of TCP counters for IPv4, another for IPv6, and two dashboards that appeared to describe different transports. RFC 2452 took a narrower position. Published in December 1998 as a Standards Track document, it said that most objects in the existing TCP Management Information Base (MIB) did not depend on the IP version beneath TCP. It specifically pointed to tcpActiveOpens: the counter measures a TCP connection's direct transition from CLOSED to SYN-SENT, whether IPv4 or IPv6 carries the packets.

That was a claim about the management contract, not a report on how every device implemented its internal counters. The RFC did not say that a shared number could tell an operator which address family, connection, interface, process or user caused an increment. It said the event retained one meaning, so duplicating its counter would add a family label that the object itself did not provide.

The connection table was different

RFC 2012's TCP table stored addresses using SMIv2's IpAddress, a four-octet value. That representation could not contain an IPv6 endpoint. RFC 2452 therefore defined a second table for connections whose endpoints were IPv6, while IPv4 connections remained in the old table. A single replacement table for every IP version was considered, but it would have required changes to RFC 2012 and to IPv4-only implementations. The separate table was a compatibility bridge, not a claim that parallel tables were the final model. The RFC placed its module identity in the experimental MIB subtree because an eventual update was expected to absorb those objects.

The IPv6 row had four familiar endpoint values: local address and port, remote address and port. But on one managed node, an IPv6 address—especially a link-local one—was not guaranteed to be unique across interfaces. The four values could therefore describe two different scoped situations. RFC 2452 added ipv6TcpConnIfIndex as the fifth table index. It was not a fifth field in a TCP packet or a change to the transport-layer connection tuple. It completed the key of this particular management row.

The index had a conditional meaning. When the remote address was link-local and the local address was not, it identified a local interface on the same link as that remote endpoint. Otherwise it identified the interface associated with the local IPv6 address. A non-zero value referred to the same interface as the corresponding IPv6 interface index and had to remain constant during the connection's lifetime.

Zero was a boundary, not a mystery interface

The RFC also allowed the interface value to be zero when the relevant interface could not be determined; a wildcard local address such as ::0 was one possible case. Zero did not turn uncertainty into a valid interface identity. It preserved what the management system did not know. That distinction matters when a table is used as evidence: a row with four known endpoint values and an indeterminate interface does not prove a unique path, a peer's identity, address ownership or application success.

The row itself was temporary. RFC 2452 described each entry as current connection information that ceased to exist when, or soon after, TCP entered CLOSED. The MIB key was thus a time-bounded observation. It could help a manager refer to a live row, but it was not a durable identity for a person, process or service.

The table inherited a writable connection-state object that included deleteTCB(12). That could terminate the corresponding host-side connection, but RFC 2012 and its published history own that intervention story. Here it is only a reminder that a precise observation surface can also be sensitive; the fifth index itself neither authorizes a write nor proves what a peer or application experienced.

A bridge with an endpoint

The next MIB generation changed the shape of the answer. RFC 4022, published in 2005, obsoleted both RFC 2012 and RFC 2452 and defined a TCP-MIB independent of IP version. It used generic address conventions rather than preserving the IPv6-only table and its fifth index unchanged. RFC 4001 supplied the InetAddressType and InetAddress pair, including zone-qualified forms; RFC 4007 described IPv6 scope and zones. In 2017, RFC 8096 separately reclassified RFC 2452 as Historic and retained its old module in an explicitly obsolete form for MIB-repository maintenance.

Those are two different lifecycle facts: a unified technical successor arrived first; a later document marked the IPv6-specific modules obsolete and the RFC Historic. Neither step proves how widely a given implementation was deployed. Together they show a careful transition: reuse the semantics that still fit, isolate the part that cannot represent the new addresses, then replace the temporary split when a family-neutral model is ready.

Sources