Resumen

  • A6 podía construir una dirección IPv6 desde fragmentos DNS con propietarios distintos; cada eslabón añadía consulta, caché, demora, oportunidad de fallo y dependencia administrativa.
  • RFC 3363 movió A6 y las etiquetas binarias de Proposed Standard a Experimental y prefirió AAAA para producción, sin afirmar que el cambio documental modificara todos los sistemas desplegados.

La promesa era real: si cambiaba un prefijo, no era necesario editar cada hoja. RFC 2874 definió A6 para separar partes de una dirección y ensamblarlas durante la resolución. El identificador local podía permanecer junto al host mientras el proveedor mantenía el prefijo.

La misma independencia formó una cadena crítica. El resolvedor seguía el nombre del prefijo, consultaba otra autoridad y quizá repetía el proceso. Cada respuesta tenía TTL, caché y operador propios. Un fragmento ausente anulaba los anteriores.

RFC 3363, publicada en agosto de 2002, convirtió ese coste en una acción de estándares. Actualizó RFC 2673 y RFC 2874, trasladándolas de Proposed Standard a Experimental. Reflejó el consenso percibido en DNSEXT y NGTRANS: AAAA era preferible para producción; A6 merecía estudio; no se sabía si sus beneficios superaban costes y riesgos.

La RFC 3364 conservó el mejor argumento a favor de A6. Podía representar prefijos que cambiaran sin aviso de una forma que AAAA no componía en tiempo de consulta. Regenerar registros AAAA mediante automatización trasladaba esa inteligencia al aprovisionamiento, no la eliminaba.

El criterio decisivo fue operativo. RFC 3363 razonó que una cadena de N eslabones tardaría aproximadamente en proporción a N si las respuestas no estaban en caché. La probabilidad de fallo crecería de modo parecido. Era un razonamiento arquitectónico, no una medición universal.

Algunas configuraciones apuntaban fuera de zona y a otra organización. La referencia podía ser válida, pero nadie controlaba toda la reparación. Una caché antigua también podía hacer que dos observadores montaran direcciones distintas a partir de registros individualmente válidos.

AAAA almacenaba los 128 bits juntos. El renumerado exigía más cambios, pero la consulta tenía una dependencia más acotada. RFC 3363 recomendó conservar RFC 1886 en la vía normativa. RFC 3596 especificó después AAAA e IP6.ARPA como modelo ordinario.

Las etiquetas binarias mostraron otro límite. RFC 2673 había creado el primer nuevo tipo de etiqueta desde RFC 1035. Servidores sin soporte podían considerar malformada la consulta. Como las etiquetas hexadecimales cubrían los esquemas inversos previstos, también se movieron a Experimental. RFC 3152 trataba aparte la raíz inversa.

No fue destrucción del trabajo, sino una retirada disciplinada. Experimental preservaba la idea mientras dejaba de imponer su superficie de compatibilidad al camino de producción.

El estatus documental no elimina código, zonas ni cachés. El soporte de código no prueba publicación. La publicación no prueba resolución completa. Una dirección resuelta no prueba servicio. RFC 4472 documentó después problemas operativos de DNS IPv6 incluso bajo AAAA.

RFC 3597 ayuda a distinguir tipos desconocidos de sintaxis nuevas: un servidor puede transportar datos de un tipo que no interpreta y aun rechazar una forma de nombre que no sabe analizar. La compatibilidad tiene más de una dimensión.

El registro IANA actual conserva identificadores y estados, no una cronología de adopción. Dos ensayos de Lu Heng sirven como lentes declaradas: “Minimum Initial Specification” para comparar una capa común delgada con la composición dinámica; “On Reality Layers” para separar decisión, código, zona, caché y resultado.

La composición gastaba fiabilidad. Cada pieza reemplazable era también una pieza que debía estar disponible y coordinada. RFC 3363 mantuvo el experimento y retiró la obligación de tratar ese coste como gratuito.

Fuentes