Mon blog

Depuis que la pénurie d'adresses IPv4 a poussé au développement d'adressages privés, spécifiques à une organisation, plusieurs techniques ont été proposées pour donner à ces mondes privés la connexion à Internet malgré leurs adresses IP non-officielles. Ce RFC décrit une expérience, le système RSIP, qui n'a eu aucun succès.

Auujourd'hui, il est relativement courant que certains réseaux connectés à Internet n'utilisent pas des adresses IP officielles, publiques, attribuées via un RIR, mais des adresses privées. Ces adresses privées sont en général tirées du RFC 1918 et la principale motivation pour les utiliser est qu'il est très difficile (et donc coûteux, même si on ne paie pas directement) d'obtenir aujourd'hui des adresses IPv4. Par exemple, si on est client d'un FAI grand public, on n'obtient au mieux qu'une seule adresse IPv4 publique, même si on a deux machines chez soi.

Pour accèder quand même à Internet, plusieurs méthodes ont été développées comme l'utilisation de relais (ALG pour Application Level Gateway aussi appelés proxies) ou comme la traduction d'adresses (NAT pour Network Address Translation). Mais toutes ces techniques remettent en cause un principe cardinal d'Internet, la connectivité de bout en bout, qui permet de déployer de nouvelles applications sans se soucier des routeurs intermédiaires. Avec des adresses IP privées, fini le modèle de bout en bout et les applications comme les soft phones doivent consacrer beaucoup d'efforts à contourner les routeurs NAT. Quant aux protocoles de sécurité comme IPsec, ils protestent évidemment si les paquets sont modifiés en cours de route.

D'où la proposition de ce RFC d'essayer un nouveau système. D'abord, RSIP (Realm Specific IP) change le vocabulaire, il n'y a plus d'adresses privées ou publiques (le terme est conservé dans le RFC mais n'a pas d'importance en pratique, RSIP peut fonctionner entre deux domaines privés, par exemple), seulement des domaines (realms) d'adressage différents. À l'intérieur d'un domaine RSIP, les machines communiquent normalement. Entre deux domaines, les deux machines sont prévenues par un routeur que les adresses appartiennent à des domaines différents et qu'il faudra donc s'adapter (encapsuler les paquets dans un paquet à destination du routeur RSIP). Le protocole lui-même est décrit dans un autre RFC, le RFC 3103.

On voit que RSIP, contrairement au NAT pur, repose sur une connaissance explicite par chaque machine « terminale » de la présence des deux domaines. Mais, au lieu d'interroger un serveur public, comme avec STUN, ici, ce sont les routeurs qui préviennent les machines terminales de l'existence de deux domaines. Ainsi, le modèle de bout en bout est relativement respecté, chaque machine ayant connaissance de son adresse IP telle qu'elle est vue par l'autre machine.

Le routeur RSIP, à la frontière de deux domaines, peut attribuer aux machines d'un domaine des adresses IP de l'autre domaine ou bien, s'il manque d'adresses IP, des couples adresse IP / port, que la machine pourra utiliser.

RSIP n'a pas été un succès et n'a connu apparemment aucun déploiement, peut-être parce que, comme le prévient l'IESG dans un avertissement inséré au début du RFC, cette technique nécessiterait une modification de toutes les machines terminales et d'une bonne partie des routeurs.