L’un des problèmes les plus fréquemment rencontrés lors du déploiement d’un système VoIP est celui de la traversée de NAT. Bien que le principe du NAT en lui-même soit relativement simple, les conséquences sur les protocoles de VoIP sont assez complexes et il n’existe malheureusement pas de solutions simples et universelles pour y remédier. Dans cette série d’articles, nous décrirons les difficultés rencontrées lors d’un déploiement VoIP en présence de NAT ainsi que les différentes solutions, que ce soit dans les équipements disponibles du commerce ou dans les spécifications récentes et non encore mises en pratique. Dans ce premier article, nous allons examiner ce qu’est le NAT, les raisons de l’introduction de ce mécanisme et son principe général de fonctionnement.

Les origines du mécanisme de NAT (Network Address Translation) sont intimement liées avec la démocratisation des accès à Internet au cours des années 1990. Ce réseau global se repose en effet sur l’utilisation de IPv4 (Internet Protocol version 4) qui, lorsqu’il a été défini au début des années 80, n’avait jamais envisagé une telle expansion. Il faut en effet comprendre que tout équipement souhaitant communiquer au sein d’un réseau (et par conséquent, Internet aussi), doit impérativement disposer d’une adresse IP unique, tout comme une habitation afin de pouvoir recevoir du courrier par exemple. Alors que cette dernière se repose sur le nom de rue, ville, code postal …, IPv4 code ses adresses sur 32 bits, ce qui permet de disposer d’un peu plus de 4 milliards d’adresses différentes. Au début d’Internet, ce nombre paraissant plus que suffisant et l’on ne pensait pas manquer d’adresses disponibles.

Cependant avec l’explosion des demandes d’accès, que ce soit par des particuliers ou des entreprises (pouvant utiliser parfois quelques dizaines, centaines, voire plus, d’adresses) ainsi qu’une méthode d’attribution ayant conduit à des gaspillages importants, il est apparu, dès le début des années 90, qu’un épuisement était inévitable à moyen terme.

Afin de retarder autant que possible cet épuisement total, les acteurs de d’Internet ont dû rechercher des solutions. La solution logique, en préparation depuis de nombreuses années, est de transposer l’ensemble du réseau sur une révision du protocole : IPv6. Toutefois, la mise en place d’une telle évolution allait prendre un temps considérable (à tel point que cette transition est à peine initiée à l’heure actuelle !). Une solution temporaire, plus immédiate, a été trouvée au travers de l’établissement de plages d’adresses réservées, dites privées :

• Classe A : 10.0.0.0 /8, soit 24 bits adressables (16’777’215 adresses disponibles).
• Classe B : 172.16.0.0 /12, soit 20 bits adressables (1’048’575 adresses disponibles).
• Classe C : 192.168.0.0 /16, soit 16 bits adressables (65’535 adresses disponibles).

Elles sont nommées privées car elles ne sont pas utilisables en dehors des réseaux de terminaison, que ce soit chez les particuliers ou les entreprises. Cette définition implique que ces adresses ne sont en aucun cas routables globalement, c’est-à-dire qu’aucune communication n’est possible entre un équipement doté d’une adresse privée et un autre situé sur le réseau Internet public. L’usage de ces adresses permet de s’adapter à tous les cas de figures, allant de la multinationale (utilisant par exemple la classe A) aux SOHO (Small Offices, Home Offices, utilisant par exemple la classe C, mieux adaptée à leurs besoins).

Cette méthode permettait certes de réduire la consommation d’adresses IPv4 (une unique adresse étant utilisée pour un groupe de machine), mais il demeurait un problème majeur en l’état : il n’était pas possible pour un réseau privé de communiquer sur le réseau public, et inversement.

Il a donc fallu à nouveau trouver une solution à ce problème : le concept est excellent, mais cette limitation n’était pas acceptable en pratique. Les acteurs de l’Internet ont par conséquent imaginé un équipement frontalier qui serait en mesure d’appliquer une translation entre l’adresse privée et l’adresse public afin de permettre aux équipements internes de communiquer globalement. Ce concept est aujourd’hui caractérisé par les NAT (Network Address Translators, nom donné au équipements, à distinguer selon le contexte du nom de la technologie).

Par conséquent, ces entités vont permettre à un groupe d’équipements internes ou privés de partager la ou les adresses publiques associées avec le NAT. Ces mécanismes vont transformer les informations contenues dans les entêtes réseaux (couche Internet et Transport du modèle TCP/IP) afin de les faire correspondre aux informations du côté public du NAT, comme le montre l’exemple ci-dessous.

Grâce à ce nouvel équipement réseau, généralement implémenté comme une fonction d’un MoDem/routeur ADSL (Box, etc.), il est désormais, et depuis de nombreuses années maintenant, possible de communiquer à partir de pratiquement tout équipement disposant des capacités suffisantes.

Idéals sur le papier, du moins temporairement, ces NAT ne sont toutefois pas exempts de défauts. En effet, si leur principe reste globalement toujours le même (transformer un couple adresse/port privée en un équivalent public, et inversement), les différentes implémentations du mécanisme ont engendré un nombre de contraintes non négligeables, en particulier pour les protocoles et applications tentant de relier directement deux terminaux entre eux, ce qui est souvent le cas pour les protocoles de voix sur IP. Les NAT ne se préoccupent en effet que des informations réseaux de routage et transport (TCP/UDP/IP …), et ignorent totalement les données applicatives utilisées par ces protocoles afin d’établir leurs communications. Le problème est que ces données contiennent parfois des adresses IP privées qui ne sont alors pas exploitables par les correspondants situés en dehors du réseau privé. Cela conduit alors inévitablement à des problèmes dans l’établissement des appels (échec global, appel établi mais sans canal audio …, perte de messages de signalisation …).

Dans cette série d’articles relatifs à la traversée de NAT, nous aborderons cette problématique et présenterons les différents mécanismes permettant d’y apporter des solutions. Dans ce but, il est nécessaire de déterminer au préalable et de manière précise à quel type de NAT un utilisateur est confronté. Ces deux points (détermination et résolution) seront traités dans nos prochains articles.