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 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 ).
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 .
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 , 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 ). 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 ) 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 pour un exemple de débat)
et qui réserve certains nombres (). 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 ().
La section 6 décrit les changements depuis le , il y a dix-sept ans (lorsque l'ICANN n'existait même
pas). Par exemple, le 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).