Mon blog

Un des problèmes de croissance auquel l'Internet fait face est la croissance de la table de routage des routeurs du cœur. Pour arrêter cette croissance, il sera sans doute nécessaire de séparer les fonctions actuelles des adresses IP en deux : les fonctions d'identificateur et de localisateur.

La croissance phénoménale de l'Internet est à la fois un hommage aux capacités des protocoles de la famille TCP/IP et une menace pour eux, car on s'approche désormais souvent des limites. Par exemple, la pénurie d'adresses IPv4 rend difficile et compliquée l'obtention d'adresses. Si le protocole IPv6 permet de faire sauter cette limite, il dévoile la limite suivante : la taille de la table de routage. Actuellement, les routeurs du cœur de l'Internet, la DFZ (Default-free zone, ensemble des routeurs BGP sans route par défaut), reçoivent une quantité de routes et surtout de changements qui est à la fois en croissance rapide et souvent inutile puisqu'un routeur de la DFZ à Tokyo ne devrait pas avoir besoin d'être prévenu d'un changement de connexion à un point d'échange à São Paulo.

Les gros routeurs du cœur, engins chers et compliqués dont beaucoup de fonctions sont mises en œuvre directement par le matériel, des ASIC, auront peut-être du mal à suivre cette croissance, d'ici quelques années.

Ces points et bien d'autres ont fait l'objet en octobre 2006 d'un séminaire de l'IAB sur le routage et l'adressage (Routing and Addressing Workshop). Le compte-rendu de ce séminaire a été publié dans le RFC 4984.

Pour arrêter cette course, il faudrait renouveler le mécanisme d'adressage de l'Internet. Actuellement, les adresses IP servent à deux choses : identifier une machine sur le réseau (« netstat montre que nous avons une connexion SSH en provenance de 192.0.2.125 ») et localiser une machine, indiquer par quelle(s) route(s) passer pour la joindre. Les identificateurs devraient être stables et attribués sans tenir compte de la topologie, toujours changeante, de l'Internet. Les localisateurs devraient au contraire être très proches de la topologie pour être efficaces pour le routage.

Dit autrement, nous avons une lutte des classes traditionnelle : les utilisateurs préféreraient des adresses qui soient indépendantes de la topologie et donc notamment indépendantes de leur opérateur actuel. Ce sont les adresses PI (Provider Independant) que les RIR n'accordent qu'au compte-goutte. Et les opérateurs préféraient des adresses étroitement liées à la topologie, agrégeables en un petit nombre de préfixes, des adresses PA (Provider Aggregatable). Il n'y a pas de moyen de réconcilier ces deux approches, à part séparer l'identificateur du localisateur.

Une fois ce principe posé, plusieurs propositions existent pour réaliser cette séparation, connue à l'IETF sous le nom de « Séparation Identificateur / Localisateur » (Identifier / Locator Separation). Aucune n'est en voie d'être déployée, toutes changent profondément l'architecture de l'Internet.

Les plus connues sont :

• HIP, Host Identity Protocol, décrit dans le RFC 9063 et normalisé dans le RFC 7401, qui transforme l'adresse IP en localisateur et crée un identificateur, le HI, lié au localisateur par un calcul cryptographique. Les applications, ainsi que TCP et UDP n'utilisent que le HI.
• SHIM6 (Site Multihoming by IPv6 Intermediation, RFC 5533) qui fonctionne de manière analogue, mais en exploitant les spécificités de IPv6.
• Six/One, qui fonctionne par réécriture des adresses et pas par encapsulation (Internet-Draft draft-vogt-rrg-six-one),
• LISP (Locator/ID Separation Protocol, développé par le groupe de travail du même nom, actuellement à l'état de projet dans l'Internet-Draft draft-farinacci-lisp) qui reporte cette séparation plus loin dans le réseau. Les paquets IP utilisant les identificateurs sont encapsulés dans des tunnels utilisant les locateurs.

Le RFC 6227 fait le point sur les problèmes d'architecture de l'Internet et prône entre autres la séparation entre localisateur et identificateur. Le RFC 6115 décrit toutes les solutions proposées. À noter que le protocole SCTP, présenté dans le RFC 4960 partage beaucoup de points communs avec les solutions ci-dessus.

Les transparents d'un exposé que j'ai fait sur la séparation identificateur / localisateur sont disponibles : version pour afficher et version pour imprimer.