Résumé

  • RFC 2452 n’a pas dupliqué la plupart des objets de gestion TCP : tcpActiveOpens gardait le même sens avec IPv4 ou IPv6.
  • Pour sa table de connexions IPv6, il a ajouté ipv6TcpConnIfIndex, car quatre valeurs d’adresse et de port ne suffisaient pas toujours à distinguer une ligne sur un nœud multiconnecté.

Deux lignes pouvaient partager les mêmes quatre valeurs

Imaginez une station de gestion qui interroge un routeur connecté à plusieurs liens. Une adresse locale, un port, une adresse distante et son port semblent former une clé complète. Mais IPv6 ne garantit pas que toutes les adresses aient une portée globale sur le nœud : une adresse locale au lien peut apparaître sur des interfaces distinctes. La même série de quatre valeurs peut donc ne pas désigner une seule observation.

RFC 2452, publié en décembre 1998, a répondu à cette ambiguïté au niveau de la table. L’entrée ipv6TcpConnEntry était indexée par les deux adresses et les deux ports, puis par ipv6TcpConnIfIndex. Ce cinquième élément n’a pas modifié le tuple TCP transmis sur le réseau. Il complétait la clé du modèle de gestion afin que l’interface ou le lien fasse partie de l’interprétation.

Ne pas découper les compteurs sans raison

La solution n’était pas de séparer tous les objets en deux familles. RFC 2452 disait qu’une connexion TCP utilisant IPv6 restait largement invisible au fonctionnement du transport : la pile devait prendre en charge les adresses IPv6, mais il n’était pas nécessaire de créer un « TCPng ». La plupart des objets de RFC 2012 demeuraient pertinents quel que soit le protocole IP sous-jacent.

tcpActiveOpens en donne l’exemple. Il compte les transitions directes de CLOSED à SYN-SENT, indépendamment d’IPv4 ou d’IPv6. Ce choix ne promet pas une attribution par famille : le compteur seul ne révèle ni la connexion ni l’interface. Il évite plutôt de donner deux noms à un même événement TCP. Le document décrit un contrat de mesure, pas l’architecture interne de chaque implémentation.

La table était l’exception pratique. RFC 2012 utilisait le type SMIv2 IpAddress, une représentation sur quatre octets incapable de contenir une adresse IPv6. Une table entièrement nouvelle pour les deux versions aurait exigé de modifier l’ancien TCP-MIB et les mises en œuvre IPv4 seulement. RFC 2452 a donc laissé ces dernières intactes et défini une table réservée aux connexions entre deux points IPv6. Comme une mise à jour ultérieure était attendue, son module a été placé dans la branche expérimentale de la MIB.

Un index, pas une identité éternelle

La signification de l’interface dépendait des adresses. Si l’adresse distante était locale au lien et l’adresse locale ne l’était pas, l’index désignait une interface sur le même lien que le pair. Dans les autres cas, il désignait l’interface associée à l’adresse locale. Une valeur non nulle renvoyait à la même interface que ipv6IfIndex et devait rester stable pendant la connexion.

Quand cette interface ne pouvait pas être déterminée, RFC 2452 prévoyait la valeur zéro — par exemple avec l’adresse locale générique ::0. Zéro conservait l’incertitude ; il ne nommait pas une interface réelle. La distinction interdit d’inventer un rattachement lors d’une analyse ultérieure.

L’entrée était également éphémère : elle disparaissait lorsque TCP passait à CLOSED ou peu après. La ligne était une observation actuelle, non un identifiant durable de serveur, de processus, de personne ou de service. Elle ne prouvait ni la joignabilité, ni l’identité du pair, ni le succès de l’application.

Du pont de compatibilité au modèle générique

RFC 4022 a ensuite remplacé RFC 2012 et RFC 2452 par une TCP-MIB indépendante de la version IP, en utilisant des conventions d’adresse génériques au lieu de conserver la table IPv6 séparée. RFC 4001 a défini la paire InetAddressType/InetAddress et les variantes avec zone ; RFC 4007 a explicité portée et zones IPv6. En 2017, RFC 8096 a, dans une étape distincte, classé RFC 2452 comme historique et marqué ses anciens modules comme obsolètes dans le cadre de la maintenance des dépôts MIB.

Ce parcours n’établit aucune fréquence de déploiement. Il montre plutôt une transition en deux temps : préserver le modèle IPv4 pendant que l’on rend visibles les connexions IPv6, puis adopter une représentation commune quand elle existe. Le compteur et la ligne ne portaient pas la même question ; les traiter de la même façon aurait soit fragmenté l’observation TCP, soit effacé le contexte d’interface.

Sources