Résumé

  • A6 permettait de composer une adresse IPv6 à partir de fragments DNS administrés séparément, mais chaque maillon ajoutait requête, état de cache, risque de panne et dépendance administrative.
  • La RFC 3363 a déplacé A6 et les étiquettes binaires de Proposed Standard à Experimental et préféré AAAA pour la production ; ce changement de statut n’a pas réécrit les systèmes déployés.

L’idée d’A6 répondait à un vrai problème. Une adresse IPv6 contient des parties qui ne changent pas au même rythme. Le site pouvait conserver l’identifiant local tandis qu’un fournisseur modifiait le préfixe. Au lieu de réécrire toutes les feuilles, le résolveur assemblait l’adresse à la demande.

La généralité avait un prix. Le résolveur suivait un nom de préfixe vers un autre enregistrement, parfois puis vers un troisième. Chaque étape pouvait exiger une requête faisant autorité. Les réponses avaient des TTL, des caches et des propriétaires différents.

Publiée en août 2002, la RFC 3363 a rendu cette dépendance décisive. Document informatif, elle mettait à jour les RFC 2673 et 2874 et déplaçait leurs mécanismes de Proposed Standard à Experimental. Elle rapportait le consensus perçu dans DNSEXT et NGTRANS : AAAA convenait mieux à la production ; A6 gardait des propriétés intéressantes ; les bénéfices ne s’étaient pas encore montrés supérieurs aux coûts et risques.

Le texte ne niait pas l’avantage d’A6. La RFC 3364, analyse parallèle, expliquait que des préfixes pouvaient changer sans avertissement et qu’A6 exprimait cette composition au moment de la requête. Générer des AAAA par prétraitement pouvait reproduire une partie du résultat, mais déplaçait les dépendances vers le système de provisionnement.

La RFC 3363 raisonnait que le délai d’une chaîne de N maillons croîtrait approximativement avec N, sauf réponses déjà en cache. La probabilité d’échec suivrait une tendance comparable puisque chaque sous-requête pouvait échouer. Ce raisonnement architectural n’était ni une mesure mondiale ni un coefficient garanti.

Les frontières organisationnelles aggravaient le coût. Les usages les plus attrayants pointaient parfois hors de la zone et vers une organisation distincte. Chaque partie pouvait être localement correcte, tandis que l’assemblage global échouait parce qu’un propriétaire avait quitté, oublié ou retardé la maintenance.

AAAA acceptait un autre coût : l’adresse complète restait dans un seul enregistrement et le renumérotage exigeait davantage de modifications. En échange, la dépendance de résolution était plus visible et bornée. La RFC 3363 recommandait de maintenir la RFC 1886 sur la voie normative ; la RFC 3596 formalisa ensuite le modèle AAAA et IP6.ARPA devenu courant.

Les étiquettes binaires subirent la même révision. Définies par la RFC 2673, elles constituaient le premier nouveau type d’étiquette depuis la RFC 1035. Des serveurs qui ne les comprenaient pas pouvaient rejeter la requête comme mal formée. La notation hexadécimale suffisait aux schémas de délégation inverse attendus ; les étiquettes binaires passèrent donc en Experimental. La racine inverse, traitée par la RFC 3152, restait hors du périmètre.

Cette décision était une soustraction constructive. Le travail n’était pas effacé ; il restait disponible pour l’étude. Mais la couche de compatibilité de production cessait de dépendre d’une nouveauté dont la surface opérationnelle dépassait les preuves.

Il faut séparer les reçus. Le statut d’un document ne prouve pas le retrait du code. Le support logiciel ne prouve pas la publication d’une zone. Un enregistrement publié ne prouve pas une chaîne complète. Une adresse résolue ne prouve pas un service joignable.

AAAA ne résolvait pas tout. La RFC 4472 a ensuite inventorié des difficultés opérationnelles IPv6 dans DNS. La RFC 3597 montre aussi que transporter un type inconnu et comprendre une nouvelle syntaxe d’étiquette sont deux problèmes distincts. La simplification retirait une classe de dépendances, non l’exploitation elle-même.

Le registre IANA actuel conserve les identifiants et statuts. Il ne révèle pas quels résolveurs ont exécuté A6, quelles zones l’ont publié ou quand elles ont migré.

Deux textes de Lu Heng servent de lentilles déclarées. « Minimum Initial Specification » éclaire la différence entre une couche commune minimale et une composition dynamique plus épaisse. « On Reality Layers » empêche de confondre la baisse de statut documentaire avec un changement instantané du réseau. Documents, code, zones, caches et résultats avancent selon des horloges différentes.

La leçon n’est pas que l’élégance serait dangereuse. Elle est que la composition dépense de la fiabilité. Chaque partie remplaçable devient aussi une partie qui doit répondre au bon moment.

Sources