Resumen

  • Para RFC 2452, tcpActiveOpens conservó su significado tanto si la conexión usaba IPv4 como IPv6; la mayoría de los objetos TCP no necesitaba una copia por familia.
  • La tabla específica de IPv6 sí necesitó ipv6TcpConnIfIndex: las cuatro direcciones y puertos no siempre identificaban una sola fila en un equipo con varias interfaces.

Cuándo cuatro valores dejan de ser una clave

Una estación de gestión puede leer la dirección local, el puerto local, la dirección remota y el puerto remoto de una conexión. En una tabla simple, esos cuatro campos parecen suficientes. Pero un nodo IPv6 puede tener varias interfaces y una dirección local al enlace no tiene por qué ser única en todo el nodo. Dos observaciones pueden compartir los mismos valores visibles y pertenecer a enlaces diferentes.

RFC 2452, publicado en diciembre de 1998, añadió un quinto índice a ipv6TcpConnEntry: ipv6TcpConnIfIndex. Ese valor completa la clave de la fila de gestión. No forma parte de la cabecera TCP ni altera la tupla de transporte que circula por la red. Su función es distinguir el contexto de interfaz cuando la dirección, por sí sola, no basta.

El documento no dividió todos los contadores entre IPv4 e IPv6. Explicó que el uso de IPv6 era, en gran medida, invisible para TCP: se necesitaba soporte para direcciones nuevas, no un “TCPng”. La mayoría de objetos de RFC 2012 seguía teniendo el mismo sentido con cualquier versión IP subyacente.

tcpActiveOpens ilustra esa continuidad: cuenta las transiciones directas de CLOSED a SYN-SENT, sea cual sea la versión IP usada entre los extremos. El contador común no atribuye un incremento a IPv4, IPv6, una conexión, una interfaz o una aplicación. Tampoco demuestra que todas las implementaciones compartieran su almacenamiento interno. Es una regla para interpretar el objeto de gestión, no un censo de implementaciones.

La excepción de la tabla

La tabla de RFC 2012 usaba IpAddress, un tipo SMIv2 de cuatro octetos que solo podía representar direcciones IPv4. RFC 2452 creó por eso ipv6TcpConnTable para conexiones entre dos extremos IPv6 y dejó las conexiones IPv4 en la tabla previa. Una tabla única para ambas familias habría exigido modificar RFC 2012 y podía afectar a implementaciones que solo entendían IPv4. Mantener la tabla antigua intacta reducía ese coste; el precio fue una estructura paralela. El RFC ubicó el módulo bajo el árbol experimental porque esperaba que una futura actualización incorporara esos objetos.

El quinto índice tenía una regla concreta. Si la dirección remota era link-local y la local no, identificaba una interfaz del mismo enlace que el extremo remoto. En los demás casos señalaba la interfaz asociada a la dirección local. Un valor distinto de cero correspondía a la interfaz de ipv6IfIndex con el mismo número y debía permanecer constante durante la conexión.

Cuando no era posible averiguar la interfaz, el índice podía valer cero; el documento menciona como posible ejemplo una dirección local comodín ::0. Cero no es una interfaz misteriosa: conserva la falta de información. Convertirlo después en una asociación inferida eliminaría precisamente la incertidumbre que el modelo dejó visible.

Una fila viva, no una identidad permanente

RFC 2452 describió cada fila como información sobre una conexión actual. Desaparecía cuando TCP pasaba a CLOSED o poco después. La tabla ofrecía una observación transitoria y dirigida a la gestión; no un identificador duradero de un usuario, proceso, servicio o interlocutor. Ni el índice de interfaz ni los cuatro extremos prueban identidad del par, propiedad de la dirección, alcanzabilidad o éxito de la aplicación.

La tabla heredó el estado escribible deleteTCB(12), que podía terminar la conexión en el nodo gestionado. La historia de esa capacidad pertenece al artículo ya publicado sobre RFC 2012; aquí solo importa como recordatorio acotado de que un objeto de observación puede ser sensible. Un índice preciso no constituye autorización para actuar ni evidencia del efecto en el otro extremo.

RFC 4022 sustituyó en 2005 RFC 2012 y RFC 2452 por una TCP-MIB independiente de la versión IP, con convenciones de dirección genéricas en lugar de mantener intacta la tabla IPv6 separada. RFC 4001 definió InetAddressType junto con InetAddress, incluidas variantes con zona; RFC 4007 describió las zonas y el alcance IPv6. En 2017, RFC 8096 reclasificó por separado RFC 2452 como Histórico y marcó obsoletos sus módulos IPv6 para mantener los repositorios MIB. El sucesor técnico y la reclasificación posterior fueron pasos distintos.

Fuentes