Résumé

  • RFC 1924 transforme l’adresse IPv6 entière en un entier écrit en base 85, sur exactement vingt caractères. La transformation est réversible, mais la réversibilité ne suffit ni à la reconnaissance humaine ni à la recherche littérale.
  • Neuf signes ASCII imprimables sont volontairement exclus de l’alphabet afin de rester disponibles pour les guillemets, listes, chemins, préfixes CIDR, crochets et échappements. La syntaxe environnante fait donc partie du problème.
  • Les textes ultérieurs ont conservé l’hexadécimal à deux-points, encadré les littéraux dans les URI et normalisé la sortie. Leur objectif pratique était de rendre l’égalité visible, sans confondre notation, attribution et activité du réseau.

La preuve se perdait entre deux écritures exactes

Imaginons un incident dont le ticket contient une adresse hexadécimale. Le pare-feu a bien observé le même nombre de 128 bits, mais son journal l’a enregistré avec l’alphabet de RFC 1924. Une recherche textuelle échoue. Aucun paquet n’a changé, aucune conversion n’est ambiguë, et pourtant le rapprochement opérationnel n’a pas lieu.

RFC 1924, publié le 1er avril 1996 dans la catégorie Informational, ne définissait pas une norme Internet. Il proposait de lire l’adresse comme un grand entier non signé, puis de l’écrire avec 85 caractères ASCII imprimables. L’exemple 1080:0:0:0:8:800:200C:417A devenait 4)+k&C#VzJ4br>0wv%Yp. Les zéros initiaux étaient conservés et la longueur restait fixe.

Cette mécanique prouve qu’un décodeur conforme retrouve le nombre. Elle ne prouve pas qu’un humain reconnaît la famille IPv6, qu’un analyseur d’URI isole correctement la chaîne, qu’un tableur rassemble les occurrences, ni qu’un outil ancien possède le décodeur. Une bijection mathématique n’est pas encore un accord social entre logiciels et opérateurs.

Le nombre 85 libérait neuf signes

Le choix reposait sur une frontière précise. Il existe (2^{128}) adresses possibles. Vingt chiffres en base 84 ne couvrent pas cet espace, alors que vingt chiffres en base 85 le couvrent : (84^{20} < 2^{128} \leq 85^{20}). Passer à 94 ou 95 symboles n’aurait pas gagné une position supplémentaire. On pouvait donc retirer neuf caractères utiles ailleurs sans allonger l’adresse.

Les omissions racontent la vie réelle d’une chaîne : guillemets simple et double, virgule, point, barre oblique, deux-points, crochets et barre oblique inverse. Ces signes servent à citer, séparer, ponctuer, écrire un suffixe CIDR, former une URL, délimiter un littéral ou échapper un caractère. Une représentation dense doit encore traverser une grammaire qui n’est pas la sienne.

La longueur fixe simplifiait les champs et supprimait les variantes d’abréviation. Mais elle rendait aussi l’adresse dépendante d’un nouvel alphabet partout où celle-ci passait. Le gain local du format pouvait devenir le coût distribué des adaptateurs.

L’hexadécimal était imparfait mais reconnaissable

La première architecture d’adressage IPv6 décrivait huit blocs hexadécimaux de 16 bits, autorisait la suppression des zéros initiaux, un seul :: pour une suite de blocs nuls et une fin décimale IPv4. Une même valeur pouvait donc recevoir plusieurs graphies légales. C’était une source d’incohérence, mais les deux-points et les blocs gardaient une silhouette connue.

Le conflit avec les URL montra qu’il n’était pas nécessaire de remplacer toute la notation. RFC 2732 choisit les crochets autour d’un littéral IPv6, avec l’objectif explicite de permettre le copier-coller avec un minimum de retouches. RFC 3986 conserva ensuite cette place réservée aux littéraux IP dans les URI. Le délimiteur résolvait l’ambiguïté extérieure ; il ne redessinait pas l’adresse intérieure.

Cette solution avait aussi un avantage institutionnel. Les outils capables de lire l’hexadécimal continuaient à le faire. Les composants d’URI n’avaient qu’une règle de bord supplémentaire à partager. La spécification initiale commune restait plus petite que la transformation de tous les affichages.

Normaliser sans fermer la porte

RFC 4291 maintint les formes hexadécimales flexibles. Cette tolérance facilita l’entrée, mais elle laissa les producteurs libres d’imprimer différemment. RFC 5952 décrivit plus tard les conséquences : recherches manquées, comparaisons erronées dans les tableurs et fichiers, divergence entre Whois, schémas, journaux, audits et opérations de vérification.

Sa réponse sépara lecture et écriture. Un analyseur devait toujours accepter toutes les formes légales. Un producteur devait préférer une seule sortie : minuscules, aucun zéro initial, compression maximale de la plus longue suite nulle, première suite choisie en cas d’égalité, jamais :: pour un seul bloc nul. La compatibilité restait large à l’entrée ; la preuve devenait convergente à la sortie.

Cette discipline ne garantissait pas la brièveté absolue. Elle garantissait quelque chose de plus utile à l’enquête : deux systèmes suivant la même règle avaient davantage de chances de laisser la même trace visible pour le même nombre.

Six niveaux qu’il ne faut pas confondre

Les bits constituent le premier niveau. Vient ensuite la valeur produite par l’analyseur, puis l’affichage normalisé, la chaîne réellement conservée dans le journal, le résultat d’une recherche et enfin l’observation d’un effet réseau. Sauter un niveau transforme une indication en certitude.

Deux chaînes décodées vers la même valeur démontrent une équivalence de représentation. Deux chaînes canoniques identiques démontrent une convention d’affichage commune. Une ligne de journal démontre qu’un composant a consigné quelque chose. Rien de cela ne démontre l’attribution de l’adresse, l’autorisation d’une origine de route, la présence d’une route active, l’accessibilité d’une interface, l’identité d’un service ou la livraison d’un paquet.

La chronologie primaire se lit dans RFC 1884, RFC 1924, RFC 2732, RFC 3986, RFC 4291 et RFC 5952. Ces textes ne constituent ni un recensement des implémentations de la base 85 ni la preuve d’un rejet formel ultérieur.

Running-Code Primacy invite, avec le recul, à vérifier ce que les analyseurs, journaux et gestes d’exploitation préservent vraiment. Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption aide à comprendre la force d’un petit accord commun entouré de décisions locales. Ces notes postérieures ne décrivent pas l’intention des auteurs des RFC.

RFC 1924 a raccourci l’adresse sans raccourcir la chaîne de confiance nécessaire pour l’utiliser. C’est précisément pourquoi ses vingt caractères restent une excellente leçon de conception.