Résumé

  • La NAT pouvait économiser des adresses IPv4 globalement uniques à la frontière d’un réseau ; les applications qui utilisaient ces adresses avaient besoin d’autre chose qu’une simple réécriture de l’en-tête IP.
  • La RFC 2993 s’intéresse à l’endroit où ce travail a été reporté : passerelles applicatives, mises à jour coordonnées des terminaux, gestion locale des noms et assistance — pas seulement une boîte sur le chemin des routeurs.

Un traducteur peut appliquer correctement sa règle et laisser une application dans l’impossibilité de se connecter. La table de traduction n’est pas forcément en faute. Le problème peut surgir quand une adresse désigne une machine dans un réseau privé, une autre valeur à l’extérieur, et qu’une troisième copie de cette adresse figure dans les messages de l’application.

Cette tension apparaissait déjà dans la proposition de 1994. La RFC 1631 présentait la traduction d’adresses réseau comme une réponse progressive à la pression sur IPv4 : les réseaux terminaux pouvaient réutiliser leurs adresses internes, tandis qu’un équipement de bord traduisait le trafic qui sortait vers l’espace d’adresses globales. Le texte reconnaissait aussi le prix de l’opération : la signification de bout en bout d’une adresse IP diminuait au profit d’un état conservé dans le réseau. Lorsqu’un site avait plusieurs sorties, les traducteurs devaient partager une vue cohérente de leurs correspondances. C’était un pont praticable, pas une architecture sans coût.

En novembre 2000, Tony Hain a réexaminé la NAT après six années d’intérêt et de déploiement croissants dans la RFC 2993. La question n’était plus seulement de savoir si un routeur pouvait remplacer une adresse par une autre. Il fallait comprendre si le service pouvait fonctionner lorsque l’adresse apparaissait à un endroit que le traducteur ne regardait pas.

La réponse dépendait de l’application. Un échange simple entre deux terminaux à travers une seule NAT pouvait se gérer. Mais certains protocoles transportaient des adresses IP dans leur charge utile ; d’autres supposaient que l’en-tête reste cohérent pour les sommes de contrôle, l’authentification ou la sécurité. Un traducteur limité aux en-têtes ne pouvait pas corriger toutes ces hypothèses. Les passerelles de couche application (ALG) et les mandataires pouvaient aider, mais chacun devait connaître le protocole qu’il réparait. La RFC 2775 avait formulé un constat voisin plus tôt cette année-là : une ALG ou un mandataire devait être mis à jour à l’arrivée d’une nouvelle application dépendante des adresses.

La transparence devenait ainsi une promesse conditionnelle. Si l’application n’exposait pas l’adresse traduite et n’en dépendait pas, l’équipement de bord pouvait rester invisible. Sinon, il fallait coordonner la solution de contournement partout où cette application tournait. La RFC 2993 oppose le cas relativement simple de deux terminaux à celui de chemins NAT redondants et d’applications multipoints comme le partage de documents. Elle dit que la complexité de coordination croît géométriquement avec le nombre de terminaux.

Le texte ne donne ni équation ni courbe de coût mesurée : il décrit un problème d’échelle architectural, pas un résultat expérimental.

La redondance ajoutait une autre dépendance d’état. Deux traducteurs empruntés par des chemins différents devaient s’accorder sur les correspondances d’un même appareil. Si l’état d’une connexion restait sur le premier chemin et que le trafic basculait vers l’autre, celui-ci pouvait créer une nouvelle correspondance. Le retour à l’ancienne route ne rétablissait pas forcément la conversation. L’adresse du paquet n’était donc pas tout l’état : la correspondance du traducteur et sa place dans le chemin comptaient aussi.

Le coût pouvait passer d’une organisation à une autre. La RFC 2993 note qu’une NAT gérée par le fournisseur d’accès peut simplifier une partie de son assistance tout en augmentant la gestion locale des adresses et des noms. C’est le déplacement de charge décrit par le mémo, non la mesure d’une hausse universelle du coût total. Après une fusion, un administrateur local pouvait devoir résoudre des conflits d’adresses privées, organiser des réponses DNS internes et externes, ou coordonner une correction d’application auparavant invisible au fournisseur.

La sécurité rendait la distinction entre traduction et politique plus nette. La RFC avertit que la NAT — en particulier la traduction de ports — peut donner l’impression d’une barrière de sécurité sans l’intention explicite de contrôle d’accès d’un pare-feu. Elle décrit aussi des difficultés de compatibilité pour IPsec, le DNS et l’authentification SNMPv3. Ces mécanismes dépendent des protocoles et de la configuration ; ils ne prouvent pas que toute NAT neutralise tout protocole de sécurité. Le traducteur modifie des éléments d’adressage utilisés comme preuves ; à lui seul, il ne décide pas quel trafic est autorisé.

La suite documentaire rendit le travail plus visible, sans montrer qu’il avait disparu. La RFC 3022 remplaça la RFC 1631 par une description de la NAT traditionnelle en 2001. La RFC 3235 publia en 2002 des recommandations pour concevoir des applications compatibles avec la NAT. Ces textes ne prouvent ni que la RFC 2993 a causé un déploiement particulier ni que tous les logiciels ont suivi ces recommandations. Ils montrent que la technique de bordure a suscité une littérature de conception applicative.

La contribution historique de la RFC 2993 n’est donc pas un verdict selon lequel la NAT échoue toujours. Elle sépare l’économie d’adresses à la frontière du travail de compatibilité nécessaire au-dessus. Le traducteur pouvait être posé sur une seule passerelle ; la réparation exigeait parfois de modifier une application sur de nombreux terminaux, de synchroniser l’état entre plusieurs chemins et de confier les noms à l’administration locale. Le réseau n’a pas fait disparaître ce travail : il a changé qui devait le remarquer et le coordonner.

Sources