Résumé

  • Le 30 avril 2026, un utilisateur a signalé des lettres majuscules dans les adresses IPv6 du CSV téléchargeable depuis « Manage Networks » et a demandé une sortie en minuscules conforme à la RFC 5952. Nous n’avons pas consulté aujourd’hui ce fichier réservé aux comptes.
  • Le 11 mai, ARIN a jugé le changement favorable à la lisibilité et à la normalisation, l’a renvoyé à la planification interne et a clos la suggestion. Aucune date de livraison ni capture d’un export corrigé ne figure dans cette réponse.
  • La RFC 5952 donne une forme textuelle canonique aux adresses et aux préfixes IPv6, tout en laissant les systèmes accepter les représentations valides antérieures. La casse ne transforme pas un préfixe en une autre ressource.
  • Le risque à examiner est celui d’un rapprochement de fichiers fondé sur les caractères, non sur la valeur numérique. Les sources décrivent ce mécanisme général, pas une erreur avérée chez un client d’ARIN.

Le registre et son reflet dans un fichier

La différence entre 2001:DB8::/32 et 2001:db8::/32 tient à trois lettres. Pour un logiciel qui analyse les adresses IPv6, elle n’existe pas : la famille, la valeur et la longueur du préfixe sont identiques. Dans un tableau où la recherche distingue majuscules et minuscules, les deux cellules peuvent pourtant cesser de se rejoindre. Le registre n’a pas créé deux blocs. Le fichier a permis deux graphies d’un seul objet.

La suggestion 2026.8 publiée par ARIN porte précisément sur ce fichier, non sur l’ensemble de ses services. Son auteur, Will MacKay, écrit le 30 avril que le bouton de téléchargement de la page « Manage Networks » produit des réseaux IPv6 en majuscules. Il demande des minuscules en invoquant la RFC 5952. Il ne rapporte ni doublon d’attribution, ni panne de routage, ni échec documenté d’un rapprochement client.

La réponse d’ARIN, le 11 mai, reconnaît l’intérêt d’un rapport plus standard et plus lisible. Elle inscrit la suggestion dans le processus interne de priorisation et de préparation de la mise en œuvre, puis la marque close. Dans le vocabulaire d’une procédure de suggestions, « close » décrit ici le sort de la demande reçue. Il ne décrit pas l’état du programme qui produit le CSV. La page ne donne ni numéro de version, ni calendrier, ni exemple avant/après. Sans accès au téléchargement authentifié, il serait tout aussi abusif d’affirmer que les majuscules persistent aujourd’hui que de proclamer la correction déployée.

La norme n’invalide pas les anciennes chaînes

La RFC 5952 part d’un fait simple : une adresse IPv6 peut être écrite de plusieurs manières légitimes. Les zéros initiaux, la compression par :: et la casse ouvrent des variantes. Sa section 4.3 exige les lettres hexadécimales minuscules dans la représentation canonique ; sa section 7 applique le même principe aux préfixes. La norme vise une sortie stable, utile aux humains comme aux logiciels.

Mais elle n’ordonne pas de rejeter toute entrée qui diffère de cette forme. Elle précise que les implémentations doivent accepter les formes valides de la RFC 4291 et ne fixe pas leur représentation en mémoire. Il faut donc distinguer l’émission et la lecture. Un export modernisé peut écrire en minuscules ; un lecteur correct peut encore comprendre un ancien export en majuscules. Une normalisation de la sortie ne devrait pas se muer en amnésie de l’entrée.

L’autre piège serait de déclarer « conforme » un CSV parce que seules les lettres ont changé. La RFC fixe aussi des règles sur les zéros initiaux et sur l’endroit où comprimer une série de champs nuls. Le dossier d’ARIN ne demande expressément que la casse. Même si ce point était corrigé, il faudrait encore examiner la représentation complète avant d’affirmer une conformité exhaustive. À l’inverse, un texte parfaitement canonique n’empêche pas un tableur mal conçu de comparer les colonnes comme de simples chaînes.

La norme décrit les difficultés qui naissent dans la recherche de fichiers, les feuilles de calcul, les journaux et les audits lorsque plusieurs écritures désignent une même valeur. Ce constat apporte une explication au bénéfice attendu ; ce n’est pas une statistique sur ARIN. Aucun document examiné n’établit qu’un de ses clients a perdu un enregistrement, contourné un contrôle ou pris une décision de réseau erronée à cause de ces majuscules.

Le contre-argument tient

La défense la plus solide d’une modification minimale est technique. Un consommateur qui utilise une bibliothèque d’adresses compare des valeurs, pas des graphies. Chez lui, la casse n’a aucune incidence sur l’identité du préfixe. ARIN peut donc estimer qu’un passage aux minuscules relève d’abord de la lisibilité et traiter la demande sans solennité excessive. La réponse officielle n’avance pas d’autre motif.

Cette objection n’efface pas la vie ordinaire d’un CSV. Les fichiers circulent hors du système qui les a créés. Ils entrent dans des tableaux de rapprochement, des historiques locaux, des dossiers d’assistance ou des scripts anciens. Une modification de casse peut alors produire un diff bruyant : des lignes paraissent nouvelles parce que leur texte a changé, tandis que les ressources n’ont pas bougé. Le scénario est plausible au regard de la RFC. Il demeure hypothétique pour ce téléchargement précis.

La bonne réponse n’est pas de réécrire les anciens fichiers pour les rendre identiques au nouveau. Leur forme d’origine atteste ce qui a été fourni à une date donnée. Mieux vaut conserver ces octets et, à côté, enregistrer la valeur IPv6 analysée et la longueur du préfixe. Une comparaison de ressources devient reproductible ; une comparaison de versions d’export reste possible. Chacune répond à une question différente.

Un test simple rendrait la frontière visible : une ligne historique en majuscules et une ligne nouvelle en minuscules doivent conduire à la même valeur de préfixe ; deux longueurs de préfixe différentes doivent rester distinctes. Il faudrait également accepter une entrée IPv6 légitime sans prétendre que toutes ses graphies sont la forme conseillée en sortie. Cette vérification ne réclame ni fichier client public ni nouvelle base de données personnelle. Elle fixe seulement ce que « même ressource » veut dire à l’interface.

Une clôture administrative, une décision technique encore à observer

La proposition est donc plus étroite qu’une réforme de la gouvernance des registres. ARIN pourrait, si le changement est livré, publier une note datée indiquant le champ CSV touché, la règle de sortie, le périmètre, la compatibilité attendue et la manière de signaler une erreur. Si le projet n’est pas retenu, une décision explicite serait aussi intelligible. Ce bref reçu de changement est une recommandation éditoriale, pas un engagement déjà pris par ARIN.

Le dossier public s’arrête aujourd’hui à une suggestion acceptée pour examen interne puis close. Il ne permet pas de raconter une mise en production. Il permet une conclusion plus durable : l’autorité d’un registre sur les ressources et son choix de la façon de les imprimer sont deux choses. Une majuscule ne modifie pas la première. La seconde mérite néanmoins une trace quand le fichier sert de preuve ailleurs.

Sources