Mon blog

Le bon fonctionnement de l'Internet dépend de l'unicité de certains nombres, notamment les adresses IP. Comment ces nombres sont-ils alloués de manière à respecter cette unicité et d'autres propriétés souhaitables ? Ce RFC remplace l'ancien RFC 2050 qui décrivait le système d'allocation des adresses IP en 1996.

Comme son prédécesseur, ce RFC ne propose pas une nouvelle politique : il documente ce qui se fait actuellement. Cette documentation est d'autant plus difficile que la gouvernance des adresses IP est un sujet complexe, à l'intersection de la technique (les limites de taille de l'espace d'adressage, les limites de traitement des routeurs), de la politique et de l'économie. Contrairement à la gouvernance des noms de domaine, celle des adresses IP fait peu de bruit et est surtout traitée dans des cercles fermés. Malgré cela, il n'y a certainement pas de consensus quant à la gestion de ces adresses et ce RFC n'est pas exempt de parti pris. Dans cet article, j'essaie de coller à la description qu'ont choisi les auteurs du RFC mais rappelez-vous que tout le monde ne la trouve pas correcte, loin de là (j'avais un point de vue plus personnel dans mon article sur le RFC 2050).

On notera aussi que le titre du RFC fait référence au système d'allocation des nombres, pas seulement des adresses IP. Il traite en effet également des numéros d'AS, qui étaient absents du RFC 2050.

Donc, commençons par la section 2, les buts. Pourquoi faut-il une gestion des nombres ? On ne peut quand même pas être propriétaire du nombre 3676198671278441090, quand même ? Pourquoi ces organisations et ces règles ? Le premier but de cette gestion est la gestion de la pénurie : les adresses IPv4, notamment, sont en nombre fini et dramatiquement insuffisant. Le bon fonctionnement de l'Internet nécessitant qu'une adresse IP soit unique (ce blog est en 2605:4500:2:245b::42 ; si une autre machine avait cette adresse, à laquelle iraient les paquets ?), il faut un mécanisme pour s'assurer qu'une adresse ne soit allouée qu'une fois. Si l'espace d'adressage était immense, tirer un nombre au hasard dans cet espace assurerait une quasi-unicité (c'est ainsi qu'on fait pour les clés cryptographiques). Mais il ne l'est pas.

Et ce n'est pas le seul but de la gestion des adresses. Le routage dans l'Internet est hiérarchique. Il n'est pas possible qu'un routeur de la DFZ connaisse toutes les adresses du monde, sa mémoire n'y suffirait pas, sans parler du rythme de changement des tables de routage que cela imposerait. On regroupe donc les adresses en préfixes et le routage fonctionne sur ces préfixes, pas sur les adresses individuelles. Mais cela ne marche que si les adresses sont agrégeables, si elles sont suffisamment proches les unes des autres pour être regroupées en préfixes. Si 2001:db8:1:a::/64 est routé par un opérateur et 2001:db8:1:b::/64 par un autre, on ne pourra pas agréger ces annonces en un seul 2001:db8:1::/48. C'est donc le deuxième but de la politique de gestion des adresses IP, permettre l'agrégation. (Par contre, la politique de routage, à savoir ce que les routeurs acceptent en pratique ou pas, est indépendante du système d'enregistrement des nombres. Elle est décidée par chaque opérateur séparément.)

Troisième et dernier but, conserver et publier (typiquement, via whois), des informations fiables sur les titulaires des préfixes, de manière à pouvoir les contacter en cas de problème pratique (par exemple de sécurité, cf. section 7). L'un des rôles des registres est de s'assurer que ces informations soient correctes. En pratique, les données actuellement publiées sont souvent de qualité médiocre (erronées, pas à jour, etc.) D'autre part, rien n'étant parfait en ce monde, on a déjà vu des cas où deux registres avaient alloué le même nombre.

Comme le notait déjà le RFC 2050, ces buts peuvent être contradictoires entre eux. Ainsi, utiliser le mieux possible le nombre limité d'adresses IPv4 nécessiterait des micro-allocations (donner un /29 à celui qui n'a pas besoin de beaucoup d'adresses) alors que le routage demande de l'agrégation et donc d'allouer plutôt les préfixes en grands morceaux. D'autre part, ces trois buts peuvent être en contradiction avec d'autres intérêts. Par exemple, la publication des informations sur les titulaires et responsables techniques des préfixes peut être utilisée par les spammeurs pour collecter des adresses.

La section 3 du RFC décrit les organisations qui mettent en œuvre ce système de registre des nombres, et leurs relations. L'allocation hiérarchique des adresses IP et des numéros d'AS est enracinée à l'IANA qui distribue des ressources aux RIR qui les distribuent à des LIR qui les distribuent à des utilisateurs finaux (en simplifiant un peu). L'IANA est une fonction, pas une organisation (aujourd'hui, la fonction IANA est assurée par l'ICANN, suivant le MoU décrit dans le RFC 2860). Les documents IANA relatifs à ce rôle de registre des nombres sont notamment le ICANN Address Supporting Organization (ASO) MoU, le ICP-2: Criteria for Establishment of New Regional Internet Registries et le Internet Assigned Numbers Authority (IANA) Policy for Allocation of ASN Blocks to Regional Internet Registries. En pratique, les politiques d'allocation sont plutôt du ressort des RIR (décrits à l'origine dans le RFC 1366) et ces politiques doivent plutôt être cherchées sur les sites Web des RIR.

Mais d'autres organisations jouent aussi un rôle comme l'IETF qui édicte les normes techniques (mais, normalement, pas les politiques d'allocation précises, voir le RFC 6177 pour un exemple de débat) et qui réserve certains nombres (RFC 6890). La section 5 revient d'ailleurs sur les rôles respectifs de l'IETF et de l'ICANN.

La section 4 du RFC quitte ces considérations organisationnelles (ou bureaucratiques, si on veut être plus méchant) pour la technique, en notant qu'il est aussi de la responsabilité des registres de nombres de fournir un service de résolution DNS d'adresses IP en noms (via la gestion de domaines en in-addr.arpa et ip6.arpa) et d'assurer un service whois conforme à la norme technique (RFC 3912).

La section 6 décrit les changements depuis le RFC 2050, il y a dix-sept ans (lorsque l'ICANN n'existait même pas). Par exemple, le RFC 2050 décrivait un mécanisme d'appel à l'IANA lorsqu'on était mécontent d'une décision d'un autre acteur. Ce mécanisme a été supprimé (les RIR ont des procédures internes d'appel, par exemple le RIPE-NCC).