Résumé

  • La RFC 4008 organisait la gestion du NAT autour d’interfaces, de catégories de service et de paramètres configurables ; la RFC 7658 explique que ce modèle s’accordait mal avec de nombreuses implémentations.
  • NATV2-MIB a réduit la configuration commune tout en donnant davantage de contexte sur les instances logiques, les domaines d’adressage, les abonnés, les pools et l’état.

Une ligne d’interface avant le mappage

La procédure illustrative de la RFC 4008 commence par la création d’une entrée dans natInterfaceTable. Le gestionnaire doit déjà connaître l’index de l’interface et lui attribuer un rôle dans un domaine privé ou public. Ensuite viennent les entrées de mappage, elles aussi indexées par interface, puis les temporisations. Le premier objet n’est donc pas la règle de traduction : c’est le bord physique qui sert d’ancrage à la règle.

Ce choix paraît naturel lorsque l’on observe les paquets. Ils entrent et sortent d’un équipement par des interfaces, et l’administrateur peut associer ces bords à des domaines d’adressage. La MIB de 2005 construit ensuite une chaîne lisible : une interface, des règles de mappage, des liaisons d’adresse ou de port dérivées, puis des sessions reliant la représentation d’une session dans le domaine privé à celle du domaine public. Elle proposait aussi des statistiques et des temporisations, et devait permettre à la fois la configuration et la supervision. RFC 4008, sections 1 et 4

La cohérence du schéma avait toutefois un prix. Il supposait que le NAT puisse être décrit comme un service attaché à une interface déterminée. Il supposait aussi qu’un administrateur puisse exprimer par une taxonomie commune les services utilisés par des produits dont les algorithmes et les structures internes différaient. Ces suppositions n’étaient pas seulement des détails de nomenclature : elles déterminaient ce qu’un agent SNMP devait savoir et ce qu’un outil de gestion pouvait écrire.

Le retour d’expérience de 2015

La RFC 7658 ne présente pas la dépréciation comme une simple mise à jour. Elle rapporte que les algorithmes et les structures de données du NAT variaient fortement entre implémentations, produisant des paramètres de configuration incompatibles. Peu d’implémentations pouvaient revendiquer une conformité complète. Même en lecture seule, l’exposition de paramètres comme les temporisations rendait la conformité de base difficile. La leçon formulée par les auteurs est de limiter autant que possible l’écriture et de ne pas faire de la MIB un moyen d’exposer toute la configuration du NAT. RFC 7658, section 3

Le problème des interfaces était plus précis encore. Beaucoup d’implémentations ne suivaient pas l’interface d’une traduction ou associaient un mappage à plusieurs interfaces. Or ifIndex structurait la MIB de 2005, des lignes de mappage jusqu’aux tables d’état. Un appareil dont le modèle interne ne conservait pas ce lien ne pouvait pas représenter proprement les objets attendus. La RFC 7658 tire une conclusion importante : le NAT est une fonction logique qui peut être indépendante des interfaces.

Les catégories et les protocoles révélaient la même tension. La RFC 4008 proposait basicNat, napt, bidirectionalNat et twiceNat. La RFC 7658 les juge mal définies : les produits pouvaient utiliser d’autres catégories ou n’en utiliser aucune. Il s’agit des catégories de service de la MIB, pas de la classification des NAT en cône de la RFC 3489. Le successeur s’appuie plutôt sur la terminologie de comportement de la RFC 4787. De même, la liste fermée other, ICMP, UDP et TCP, avec des nombres qui n’étaient pas ceux du registre des protocoles, compliquait la représentation de protocoles tels que DCCP et SCTP. NATV2-MIB adopte les numéros normalisés de l’IANA.

Déprécier l’ancien schéma, en définir un autre

La transition de 2015 sépare clairement les deux actes. La RFC 7658 marque les objets de la RFC 4008 comme dépréciés et conserve leurs définitions avec ce changement de statut. La RFC 7659 définit NATV2-MIB. Les anciens identifiants ne sont donc pas silencieusement réinterprétés comme si le modèle n’avait pas changé. RFC 7658 RFC 7659

NATV2-MIB vise surtout la supervision. Les paramètres de configuration en lecture seule sont réduits à ce qui est nécessaire pour interpréter l’état et les statistiques. La configuration inscriptible est retirée, à l’exception des commandes qui contrôlent les notifications et des quotas de ressources NAT. Ce n’est donc pas une MIB sans contrôle : une limite de ressources peut toujours être définie. Mais elle cesse de prétendre offrir une interface de configuration universelle pour le moteur de traduction.

Son centre de gravité devient l’instance logique de NAT. Les mappages ne sont plus organisés autour d’une interface. Les tables peuvent décrire plusieurs instances sur un équipement, un nombre arbitraire de domaines d’adressage, des protocoles, des pools, des abonnés, de l’état, des statistiques et des notifications. La MIB ajoute ainsi des dimensions utiles au NAT de grande capacité, où les adresses et les ports publics sont partagés et où les ressources d’une instance doivent pouvoir être distinguées de celles d’une autre.

L’indexation des mappages de ports est également révisée pour faciliter le retour depuis des paramètres de paquet visibles à l’extérieur vers le point de terminaison interne correspondant. Cette capacité est une aide au diagnostic ou au rapprochement de données. Elle ne prouve ni l’identité juridique d’un abonné, ni la livraison d’un paquet, ni la réussite d’une application. RFC 7659, sections 2 et 3

La RFC 6888 fournit le contexte de partage de ressources : un CGN fait concourir plusieurs abonnés pour des ports et de l’état, et des limites par abonné peuvent prévenir l’épuisement par un seul participant. Les objets de NATV2-MIB permettent d’exprimer ce type de limite et d’observer certains compteurs. Les textes ne montrent cependant pas quels opérateurs ont appliqué ces objets, comment ils ont fixé les seuils ou quels résultats ils ont obtenus. RFC 6888, sections 4 et 5

Ce que le changement établit

L’histoire de cette MIB est une correction d’abstraction. La RFC 4008 essayait de rendre la traduction configurable au moyen d’une hiérarchie de tables portable. La RFC 7658 expose pourquoi l’interface ne constituait pas un ancrage commun pour beaucoup de produits, pourquoi certains paramètres ne se prêtaient pas à une configuration normalisée et pourquoi la liste de catégories et de protocoles était trop étroite. La RFC 7659 réduit alors la surface de configuration partagée tout en donnant un vocabulaire plus riche pour observer les instances et leurs ressources.

Cette séquence étaye une conclusion limitée : le modèle de gestion a dû changer pour décrire un éventail plus large d’implémentations. Elle ne prouve pas que tous les fabricants ont adopté NATV2-MIB, qu’elle est devenue universelle ou qu’elle a amélioré les performances de traduction. La RFC 7659 indique que la première MIB avait été peu implémentée, sans fournir de taux ni de mesure d’adoption pour son successeur.

La frontière avec les pare-feu est aussi explicite. Les RFC 4008 et 7658 précisent que ces MIB ne couvrent pas les fonctions de pare-feu et ne doivent pas servir à les configurer ou à les superviser. Une entrée de traduction n’est pas une règle de filtrage.

Enfin, un objet de gestion n’est pas un résultat de service. Un pool configuré n’est pas une traduction active ; un index d’abonné n’est pas une identité vérifiée ; un compteur a besoin de son contexte de discontinuité avant que l’on interprète son évolution ; aucun de ces éléments ne prouve qu’un paquet a atteint sa destination. NATV2-MIB rend la vue de gestion plus cohérente sans confondre configuration, état, traitement des paquets et résultat pour l’utilisateur.

La leçon historique est donc précise. Une norme de gestion peut devenir trop ambitieuse lorsqu’elle transforme des paramètres propres aux implémentations en interface commune. La RFC 7658 n’a pas répondu en ajoutant des attributs d’interface : elle a remis en question l’unité modélisée. NATV2-MIB a rendu moins de configuration universelle et davantage de contexte logique visible. La question n’était plus seulement « quelle interface possède ce mappage ? », mais « quelle instance, quel domaine, quel abonné, quel pool et quel état cette observation décrit-elle ? »

Sources