Résumé

  • RFC 2011 définit sous SMIv2 les objets IP et ICMP restant de MIB-II et rend obligatoires ipGroup et icmpGroup, tout en signalant que IpAddress, limité à quatre octets, ne représente qu’IPv4.
  • Une table lisible ou un compteur qui progresse établit un fait dans la population déclarée. Cela ne prouve ni la présence d’IPv6, ni l’identité complète d’une adresse, ni une route joignable, ni l’effet d’une écriture.
  • RFC 2465 a d’abord construit une surface IPv6 séparée ; RFC 4001 a associé type et valeur d’adresse ; RFC 4293 a réuni les deux lignées en faisant de l’indexation et de l’instrumentation un chantier de migration.

Le vert peut être juste

Un agent charge le module, expose les groupes obligatoires et répond aux lectures autorisées. ipInReceives augmente ; ipAddrTable contient des lignes. Le verdict de conformité est vert. RFC 2011 n’offre aucune raison de contester ces observations.

Mais la note de l’IESG précise la portée du verdict. Les MIB IP, UDP et TCP de l’époque n’acceptent que l’IPv4 : le type IpAddress défini par SMIv2 est une chaîne de quatre octets pour une adresse de 32 bits. L’IPv6 à 128 bits n’entre pas dans ce format.

Cette limite structure les tables. Dans ipAddrTable, ipAdEntAddr sert à la fois de valeur d’adresse et d’index de ligne ; le masque utilise le même type. ipNetToMediaTable place aussi l’adresse dans l’identité de l’entrée. Une ligne IPv6 absente ne déclenche pas nécessairement une erreur. Le modèle ne possède tout simplement aucun nom pour elle.

Un groupe obligatoire n’est pas le réseau entier

RFC 2011 avait un mandat historique circonscrit. Les objets IP et ICMP provenaient de MIB-II sous SNMPv1 ; la gestion des routes avait déjà été révisée dans RFC 1354. Le nouveau module reprend le reste sous SNMPv2 et dit expressément qu’il exclut la gestion des routes IP.

La conformité impose ipGroup et icmpGroup. On y trouve l’état de forwarding, le TTL par défaut, les compteurs d’entrée et de sortie, la fragmentation et le réassemblage, les adresses, les correspondances avec le support physique et de nombreux types ICMP. C’est une instrumentation cohérente, pas un inventaire universel.

Les descriptions empêchent aussi d’aplatir les compteurs. ipInReceives inclut des datagrammes reçus en erreur. ipInDiscards exclut les abandons pendant l’attente de réassemblage. ipOutNoRoutes ne compte que l’absence de route. ipReasmFails ne correspond pas forcément au nombre de fragments perdus. Le nombre indique l’évolution d’un ensemble défini ; il ne livre ni le paquet, ni la famille d’adresse, ni le chemin, ni la cause.

Les objets modifiables ne ferment pas davantage la chaîne. Une réponse positive à l’écriture de ipForwarding, de ipDefaultTTL ou d’une ligne de voisinage prouve une acceptation par l’agent. Il faut encore établir l’autorisation, la persistance, la pile concernée et l’effet observé.

D’abord deux cartes, ensuite une carte typée

RFC 2465 choisit en 1998 une MIB IPv6 distincte. Son groupe général réunit six tables : interfaces, statistiques par interface, préfixes, adresses, routes et associations réseau-support. L’adresse IPv6 occupe seize octets, sans qu’il soit nécessaire de modifier SMIv2.

La représentation est réglée, mais l’exploitation doit désormais joindre deux surfaces. Un collecteur double pile doit savoir quelles MIB l’agent met en œuvre, quelles tables il parcourt et comment il rapproche les interfaces. La conformité à RFC 2011 reste vraie pour IPv4 ; elle ne devient pas un témoignage sur la moitié IPv6.

RFC 4001 rend ensuite la famille explicite avec le couple InetAddressType/InetAddress. Dans un index, le type précède la longueur et les octets de l’adresse. Le texte déconseille de figer un objet dans un seul format, tout en autorisant une déclaration de conformité à n’exiger qu’un sous-ensemble des types. L’étiquette générique ouvre la porte ; elle ne prouve pas que chaque pièce a été aménagée.

RFC 4293 finit par remplacer RFC 2011 et les MIB IPv6 séparées. Les statistiques système et interface sont distinguées par version IP ; les adresses reçoivent un type ; les préfixes, routeurs par défaut et voisins sont réorganisés. Le texte reconnaît que le passage de ipAddrTable à ipAddressTable est assez profond pour rendre un nouveau code plus simple qu’une retouche. Les routines SNMP doivent apprendre la nouvelle indexation et l’instrumentation doit produire de nouveaux compteurs.

Le document normalise donc la destination, pas l’arrivée. Pour prouver une migration, il faut conserver la révision du module, les familles déclarées et réellement présentes, le contexte SNMP, les tables interrogées, l’identité des instances, l’heure de collecte et l’effet opérationnel qui suit une modification.

Sources

Limites de preuve

Ces sources établissent les textes, les types, les groupes de conformité et leur succession. Elles ne mesurent ni les défauts de fournisseurs, ni le déploiement, ni une panne actuelle, ni la couverture d’un réseau nommé, ni un SLA, ni la date réelle d’une migration.