Vers la fin des années 90, on pensait qu'on allait bientôt avoir besoin de renuméroter les réseaux IPv6 de plus en plus souvent, notamment suite aux changements potentiellement fréquents des préfixes de sites IPv6 . Une telle renumérotation nécessiterait une mise à jour aussi fréquente du DNS pour assurer l'accessibilité des nouvelles adresses. On s'était vite rendu compte que l'enregistrement AAAA n'était pas adapté à ce besoin, notamment à cause du faible déploiement du mécanisme de mise à jour dynamique du DNS . Il a fallu alors spécifier une nouvelle extension et en même temps un nouveau type d'enregistrement, l'enregistrement A6 (RFC 2874), dont la structure reflète deux parties distinctes d'une adresse IPv6 :

• une partie variable : le préfixe du lien auquel l'interface est attachée. Ce préfixe (les 64 bits de poids fort) est dérivé du préfixe de site et supporte plusieurs niveaux d'agrégation, chaque niveau d'agrégation étant renseigné dans un enregistrement A6 faisant partie d'une chaîne ;
• une partie fixe (les 64 bits de poids faible) obtenue à partir de l'identificateur d'interface de l'équipement en question.

Malgré l'intérêt que présentait cette proposition, les groupes de travail de l'IETF dnsext et ngtrans ont décidé, après de longs débats, d'écarter l'extension A6 de la voie de standardisation (Standard Track) en faisant passer le RFC 2874 à l'état « experimental » pour les raisons suivantes :

• on ne voyait toujours pas de besoin concret de renumérotation fréquente de réseaux IPv6 ;
• l'implémentation de l'extension A6 et surtout son déploiement se sont avérés complexes. En effet, le fait qu'une requête de résolution DNS du type A6 puisse faire appel récursivement à d'autres requêtes A6 afin de reconstituer l'adresse IPv6 complète recherchée, peut provoquer des temps d'attente trop longs faisant ainsi échouer la requête de résolution initiale ;
• il serait dangereux de mettre en oeuvre la nouvelle extension A6 sans s'assurer par avance que cette extension n'aura aucun impact négatif sur les performances du DNS en production.

Soulignons que le groupe de travail dnsext a d'un côté recommandé de continuer à expérimenter l'extension A6 et de l'autre, il a décidé de faire avancer l'extension AAAA initialement publié dans le RFC 1886 et par la même occasion l'extension ip6.arpa, initialement publiée dans le RFC 3152, sur la voie de standardisation. En effet, suite à des tests d'interopérabilité réussis, les RFC originels (1886 et 3152) qui spécifiaient ces extensions et qui étaient en Proposed Standard (PS), ont été recyclés en un document IETF (Internet Draft) qui a donné naissance par la suite au RFC 3596 (avec le statut de Draft Standard, DS).

Par ailleurs, une autre extension a été proposée pour améliorer la gestion des zones DNS inverse IPv6 : les bitstring labels (RFC 2673). Cette extension, qui est censée s'appliquer uniquement sur l'arbre inverse ip6.arpa, consiste à utiliser des étiquettes binaires pour nommer les enregistrements PTR plutôt que les étiquettes en notation hexadécimale. Le but était de permettre de déléguer les blocs d'adresses selon une longueur quelconque de préfixe et de lever ainsi la contrainte de délégation des zones DNS inverse sur la frontière du demi-octet. Cette extension a été écartée de la voie de standardisation en même temps que l'extension A6 à cause de la complexité de sa mise en oeuvre et du manque de retour d'expérience sur son utilisation.