Contexte historique et objectifs initiaux

Le NAT (Network Address Translation) a été formalisé dans le RFC 1631 en 1994. Son texte indique que les deux problèmes majeurs de l’Internet étaient l’épuisement des adresses IPv4 et la complexité du routage. La solution à court terme proposée était le CIDR, tandis que le NAT était présenté comme une mesure transitoire permettant à plusieurs hôtes de partager une même adresse publique en réécrivant les en‑têtes IP. Cette approche a conduit à la réservation de plages privées (10/8, 172.16/12, 192.168/16) qui sont aujourd’hui omniprésentes.

Fonctionnement technique d’un routeur domestique

Un ordinateur interne, par exemple 10.11.70.21:50413, envoie un paquet vers 67.215.249.229:70. Le routeur NAT le transforme en 146.7.15.85:60612 avant de le transmettre. Le serveur répond à 146.7.15.85:60612, le routeur inverse la traduction et le paquet revient à 10.11.70.21:50413. Cette table d’état ne conserve qu’une correspondance IP+port public → IP+port privé. Ainsi, un serveur externe qui initie la connexion ne trouve aucun point d’ancrage dans la table, ce qui bloque les services entrants.

Source IP 10.11.70.21
Source Port 50413
Destination IP 67.215.249.229
Destination Port 70
--- NAT ---
Source IP 146.7.15.85
Source Port 60612
Destination IP 67.215.249.229
Destination Port 70
--- réponse ---
Destination IP 146.7.15.85
Destination Port 60612
--- NAT inverse ---
Destination IP 10.11.70.21
Destination Port 50413

Contournements et leurs limites

Le contournement le plus simple est le port forwarding : le routeur associe de façon statique le port public 60612 à l’hôte interne 10.11.70.21. Cette méthode ne permet qu’une correspondance unique par port, ce qui devient problématique dans les réseaux d’entreprise où plusieurs machines doivent exposer le même service. Le UPnP, le NAT‑PMP et le PCP automatisent la création de ces règles, mais ils sont souvent désactivés pour des raisons de sécurité ou inutilisables derrière un CGNAT, où le fournisseur contrôle la traduction et ne donne aucun accès à la configuration.

Les protocoles STUN, TURN et ICE adoptent une approche différente. STUN interroge un serveur public pour connaître l’adresse et le port assignés par le NAT (« hole punching »). Cette technique fonctionne avec les NAT de type « cone », mais échoue avec les NAT « symmetric », fréquents dans les CGNAT, où chaque destination reçoit un port différent. TURN contourne le problème en relayant tout le trafic via un serveur tiers, au prix d’une latence supplémentaire et d’une dépendance à l’infrastructure du relais. ICE orchestre l’ensemble : il teste les connexions directes, les mappages STUN et, en dernier recours, le relais TURN. WebRTC s’appuie sur ICE pour offrir la meilleure connectivité possible, mais il ne supprime pas la couche de traduction sous‑jacente.

Conséquences sur la décentralisation d’Internet

En imposant une barrière d’accès aux hôtes privés, le NAT a conduit à une concentration des services vers les datacenters qui possèdent des adresses publiques dédiées. Les tentatives de décentralisation (serveurs P2P, hébergement domestique) nécessitent des solutions de contournement qui introduisent de la complexité, de la latence ou une dépendance à des services tiers. Le modèle original d’un réseau où chaque nœud pouvait être contacté directement a été remplacé par un schéma où la plupart des nœuds sont invisibles derrière plusieurs niveaux de traduction. Tant que l’IPv6 ne sera pas déployé à grande échelle, cette architecture restera un obstacle majeur à la mise en place d’applications véritablement distribuées.