Resumen

  • RFC 3152 eligió IP6.ARPA, solicitó su delegación bajo instrucciones del IAB y dispuso subdelegaciones acordes con el espacio IPv6 asignado; no creó por sí solo cada zona ni cada PTR.
  • Declarar IP6.INT inadecuado para implementaciones nuevas abrió una retirada ordenada, no un apagado mundial. La etapa formal de 2005 demuestra que decisión y corte operativo tuvieron relojes distintos.
  • La prueba completa separa norma, delegación superior, RIR, zona hija, datos PTR, sufijo consultado, caché, respuesta, validación y uso de la aplicación. Un nombre inverso no autentica a un host.

La delegación señalaba autoridad, no contenido

IPv6 necesitaba una forma de construir consultas de dirección a nombre. Los primeros textos usaban IP6.INT; el IAB, en cambio, estaba consolidando .ARPA como hogar de espacios de infraestructura. RFC 3152 resolvió ese conflicto de ubicación.

El BCP actualizó referencias en cinco RFC, pidió a IANA delegar IP6.ARPA conforme a instrucciones del IAB y ordenó que la jerarquía siguiera la asignación de direcciones. Las partes del árbol llegarían a los registros regionales según los bloques IPv6 bajo su responsabilidad.

Pero una delegación superior sólo indica dónde buscar la siguiente autoridad. No garantiza que el RIR haya delegado un prefijo concreto, que la zona hija responda, que exista un PTR ni que el programa consulte el sufijo nuevo. RFC 3152 cambió la arquitectura de autoridad; no afirmó que todo el contenido y todos los clientes ya hubieran migrado.

“Desaconsejado” describía un intervalo

El documento explicó qué significaba deprecar IP6.INT: no era apropiado para implementaciones nuevas y probablemente se retiraría de forma ordenada. Esa frase admite una fase en la que el destino nuevo es normativamente correcto y el anterior sigue recibiendo tráfico.

La coexistencia permitía actualizar bibliotecas, resolutores y registros sin una publicación simultánea global. También producía estados ambiguos. Un cliente podía intentar primero un árbol y luego el otro. Un operador podía mantener dos PTR distintos. Un caché negativo podía ocultar una delegación recién creada.

Por eso una respuesta visible no basta para saber qué ocurrió. Hay que registrar el QNAME, el sufijo, el resolutor, si hubo caché o fallback, la cadena de referencias, el servidor autoritativo, el RCODE, el TTL y el estado de validación.

La jerarquía copiaba la asignación sin copiar su evidencia

RFC 3172 presentó .ARPA como dominio de infraestructura de uso limitado. Confirmó que IP6.ARPA estaba delegado a IANA y que sus nombres continuarían hacia los RIR de acuerdo con las asignaciones IPv6.

Ese diseño distribuía la administración de manera coherente con los recursos numéricos. No convertía un recibo de asignación en recibo DNS. Un bloque puede estar asignado sin zona inversa. Una referencia puede apuntar a servidores incorrectos. Una zona puede responder autoritativamente sin el nombre buscado.

Los niveles tampoco pertenecen a un único actor. IETF define la convención; IAB e IANA cuidan la infraestructura superior; RIR y titulares gestionan delegaciones; operadores publican RRsets; resolutores deciden consulta y caché; aplicaciones interpretan el resultado. Un campo reverse_dns_ready borraría justamente la separación que hace gobernable al sistema.

El nombre correcto podía terminar en muchos resultados

RFC 3596 consolidó después la forma conocida: invertir los nibbles hexadecimales de la dirección IPv6, separarlos en etiquetas y añadir IP6.ARPA. La construcción exacta demuestra que se formó la clave prevista.

La consulta aún puede recibir referencia, NXDOMAIN, SERVFAIL, timeout, respuesta insegura, respuesta validada o dato almacenado. Cada resultado informa sobre una fase diferente. El PTR, cuando aparece, expresa datos de una zona; no prueba control del equipo, titularidad, alcance ni autorización.

Tampoco garantiza simetría. El nombre indicado por el PTR puede no tener AAAA, o su AAAA puede no contener la dirección original. Algunas aplicaciones comprueban ida y vuelta; otras sólo presentan el nombre. RFC 3152 no otorgó a ninguna de esas políticas fuerza de identidad.

Los documentos posteriores no borraron el proceso

En 2003, RFC 3596 reunió la especificación IPv6 de DNS con el cambio de IP6.INT a IP6.ARPA y declaró obsoletos RFC 1886 y RFC 3152. Eso absorbió el resultado, no retiró el árbol nuevo.

RFC 3363 había apartado A6 y Bitstring Labels hacia Experimental, favoreciendo AAAA. RFC 5855 estabilizó más tarde los nombres de servidores para las zonas inversas. RFC 9121 terminó registrando IP6.INT como dominio histórico eliminado de .INT.

La retirada operativa tuvo otro hito: RFC 4159 indicó que desde el 1 de septiembre de 2005 las implementaciones IPv6 conformes ya no debían usar IP6.INT, y pidió a los RIR acordar con sus comunidades el fin del servicio de registro. Si RFC 3152 hubiera cambiado cada sistema en 2001, esa coordinación posterior no habría sido necesaria.

No crear una amenaza nueva no resolvía la antigua

RFC 3152 reconoció que el spoofing de mapas dirección-nombre ya se había explotado en IPv4. Su frase “no crea nuevas amenazas” sólo limitaba el efecto de cambiar la raíz. No decía que un PTR fuera seguro.

RFC 3596 fue explícito: la información DNS debe considerarse insegura salvo uso de técnicas adecuadas, y las extensiones IPv6 no solucionaban los problemas existentes. DNSSEC puede autenticar el dato dentro de una cadena DNS, pero no la interpretación social del nombre ni la custodia actual del endpoint.

Una decisión de acceso necesita evidencia propia. Validación, coincidencia directa, inventario, credenciales y política no pueden inferirse de una cadena legible devuelta por la consulta inversa.

El código ejecutado podía desmentir una migración “terminada”

Imaginemos una zona correcta bajo IP6.ARPA. Un programa antiguo pregunta a IP6.INT; otro usa el nuevo árbol pero conserva NXDOMAIN en caché; un tercero llega al servidor y recibe PTR. La misma norma produce tres observaciones.

La primacía del código en ejecución no reduce la autoridad del BCP. La norma decide cuál es el árbol correcto. La ejecución revela si el cliente lo consultó, qué delegación siguió, qué dato recibió y qué hizo después.

La especificación inicial mínima hizo posible la coordinación: un destino común, una delegación superior, una jerarquía coherente y una retirada no atómica. Ese diseño dejó libertad local y evitó un día de corte universal. También obliga a no confundir dirección normativa con convergencia operativa.

La historia de RFC 3152 cabe así en una paradoja aparente: IP6.ARPA podía existir correctamente mientras IP6.INT aún funcionaba en algunos lugares. La transición fue real precisamente porque no fingió que todos los relojes marcaban la misma hora.

Fuentes