Résumé

  • La RFC 1930 définit un système autonome par sa politique de routage unique et clairement établie, pas par le nom d’une entreprise ni par son nombre de routeurs.
  • Dès 1994, le formulaire RIPE demandait des éléments administratifs et techniques ; la BCP de 1996 a précisé quand un ASN distinct apporte une information de routage.

Analyse

Quand un réseau annonce des routes à deux fournisseurs, chacun doit pouvoir distinguer la politique qu’il propose aux autres réseaux. Le nombre de routeurs ou le nom de l’entreprise ne répond pas à cette question. C’est le problème pratique que la RFC 1930 éclaire : publiée en mars 1996 comme bonne pratique de l’IETF, elle définit le système autonome comme un ensemble de préfixes IP exploités selon une politique de routage unique et clairement établie. Un ASN est utile lorsque les voisins doivent distinguer cette politique.

Pour un client relié à un seul fournisseur, la distinction est concrète. Si ses routes suivent la politique de ce fournisseur, la RFC 1930 juge généralement inutile de créer un AS séparé : ses préfixes peuvent rester dans celui du fournisseur. Un site multihébergé est différent lorsqu’il doit exprimer ses propres préférences entre plusieurs fournisseurs. La question ne se réduit donc ni au nombre de câbles, ni à celui des routeurs ou des contrats. Elle porte sur le caractère distinct de la politique annoncée aux autres réseaux.

Les démarches administratives rendaient déjà cette différence visible. Daté du 1er mars 1994, RIPE-109 séparait une demande d’AS en deux parties, administrative et technique. La première était obligatoire ; les détails techniques pouvaient manquer au dépôt initial, mais RIPE demandait qu’ils soient transmis ensuite. Le formulaire comportait un objet AS et des expressions as-in et as-out pour décrire les routes acceptées des pairs et celles qui leur étaient annoncées. La RFC 1930 précise que ses recommandations plus générales reposent sur ce document du RIPE.

La RFC corrigeait ainsi une confusion de catégorie. La définition antérieure associait l’AS à une seule administration technique et à un protocole interne commun. Or un opérateur pouvait employer plusieurs protocoles internes et métriques tout en présentant un plan cohérent à l’extérieur. À l’inverse, une même entreprise pouvait réunir des politiques distinctes. La frontière pertinente était celle de la politique visible par les autres réseaux, pas celle de l’organigramme ou du parc informatique.

Cette précision comptait aussi parce que l’espace de numéros était fini. La RFC 1930 le décrivait alors comme un champ de 16 bits : environ 5 100 numéros attribués, dont moins de 600 actifs dans le routage mondial selon les auteurs en 1996. Ce sont des chiffres historiques, pas un état actuel. Le texte déconseille de créer un AS par simple habitude administrative et réserve 64512 à 65535 à l’usage privé. En 2007, la RFC 4893 a prévu une transition progressive de BGP vers les numéros sur quatre octets, avec des mécanismes de compatibilité ; la RFC 6793 l’a ensuite remplacée.

Cette histoire ne se résume pas à une pénurie de numéros. Elle porte sur ce que le numéro devait représenter. Un ASN peut identifier une frontière de politique dans un registre ou un chemin BGP ; il ne prouve pas à lui seul qui exploite chaque routeur, si une route est acceptée ni où un service est fourni. Le formulaire, le protocole et l’observation du réseau sont des sources différentes. Les confondre transforme un identifiant utile en preuve qu’il ne peut pas fournir.

Sources