Resumen

  • El método Reg-RWS vigente acepta una dirección IPv4 o IPv6 para solicitar un informe WhoWas, y el ReadMe define rangos de ambas familias; son pruebas de entrada y formato, no de la historia efectivamente recuperada.
  • Las sugerencias ACSP 2025.4 y 2026.5 pidieron historia IPv6. ARIN las remitió a priorización interna y las cerró, sin prometer fecha ni publicar un identificador que las conecte con la documentación actual.
  • Un recibo de capacidad podría usar una dirección IPv6 controlada para acreditar versión, aceptación, cierre del ticket, horizonte histórico, clases de objetos, vacíos conocidos y correcciones, sin exponer datos de clientes.

La escena parece terminar demasiado pronto. Un operador autorizado envía una dirección IPv6 al método NET de WhoWas. El sistema reconoce la sintaxis, crea un ticket y devuelve el sobre administrativo que permitirá recoger el informe más tarde. En una prueba de API, eso suele contarse como éxito.

En una investigación histórica, apenas es el principio.

El ticket no dice si el archivo conserva un cambio de organización ocurrido años atrás. La columna IPv6 no dice si los registros antiguos fueron migrados. Un informe vacío no explica si jamás hubo un evento público o si el evento está fuera del horizonte disponible. La interfaz, el esquema y el contenido son piezas consecutivas, pero no intercambiables.

ARIN publica hoy documentación que acerca mucho esas piezas. La página de métodos Reg-RWS indica que IPADDRESS debe ser una dirección IPv4 o IPv6 y muestra ejemplos de las dos. El ReadMe de WhoWas define Net Range como un intervalo de direcciones IPv4 o IPv6. La página del servicio afirma que usuarios autorizados pueden obtener información histórica de una dirección IP o un ASN, incluso de recursos ajenos a su organización, y describe el resultado como toda la historia pública.

Sin embargo, dos registros ACSP recientes cuentan que la comunidad seguía pidiendo la historia de IPv6. En mayo de 2025 ARIN calificó la incorporación como útil y la dejó pendiente de priorización. En abril de 2026 respondió a una petición repetida con el mismo envío al proceso interno. Ambos expedientes quedaron cerrados, pero ninguno enlaza a una entrega, una versión o una prueba.

Es posible que la capacidad se haya desplegado después y que los manuales ya reflejen la realidad. También es posible que la entrada y el formato estén listos mientras la cobertura histórica tenga límites. Puede haber diferencias por fecha, tipo de objeto o migración. Como esta investigación no obtuvo autorización de WhoWas ni ejecutó consultas, no adjudica un resultado al sistema vivo. El hallazgo es documental y operativo a la vez: falta una identidad común que ate la solicitud aceptada al archivo que la responde.

La primera solicitud trataba de una pérdida real de contexto

El 9 de mayo de 2025, la sugerencia 2025.4 describió una entidad aguas abajo cuyo recurso IPv6 ya no estaba correctamente asignado. El autor quería recuperar los datos de registro anteriores y afirmó que el servicio solo permitía consultas de prefijos IPv4. Su propuesta de paridad no era una celebración técnica de IPv6; era una petición de continuidad probatoria.

Cuando la asignación actual ya no representa el pasado, Whois o RDAP muestran el punto equivocado de la película. Identifican lo que ARIN publica ahora, pero no necesariamente quién figuraba cuando ocurrió una incidencia, cuándo se retiró el registro o cómo cambió la asociación entre red, organización y POC. Para eso existe un archivo histórico.

ARIN respondió el 21 de mayo que añadir información IPv6 sería útil. Incorporó la idea a la lista de mejoras sugeridas pendientes de prioridad y la remitió a planificación de implementación. Después cerró el expediente. El verbo puede confundir si se lee sin el párrafo que lo acompaña: terminó el trámite público de la sugerencia, no se certificó un despliegue. No se había especificado plazo y ARIN tampoco lo ofreció.

La segunda petición llegó el 31 de marzo de 2026. Su autor quería consultar la historia de rangos IPv6, en particular cuando una entidad sufría una revocación, con detalles comparables a IPv4 y ASN. El 2 de abril, ARIN reconoció expresamente que era una repetición y dijo que esa reiteración pesaría al evaluar la prioridad del desarrollo. La remitió al proceso interno y la cerró.

La repetición demuestra que el uso seguía siendo relevante. No demuestra por sí sola el estado técnico. Un usuario puede no conocer una función nueva, puede carecer del permiso correcto o puede llamar “soporte IPv6” a una parte del producto distinta de la que ya existe. La respuesta de ARIN aporta más contexto, pero tampoco especifica si el trabajo pendiente afectaba al analizador de direcciones, al generador del informe, a la migración de datos o a la paridad de relaciones históricas.

Una dirección válida no certifica un archivo

El contrato de entrada es concreto. El método WhoWas NET no acepta un handle como sustituto de la dirección ni un prefijo CIDR como forma de la solicitud. Exige una dirección individual, IPv4 o IPv6. Si la llamada prospera, devuelve un Ticket Payload. El usuario consulta luego el estado y obtiene el informe adjunto cuando esté listo.

Esa asincronía separa dos comprobaciones. La primera verifica que la solicitud fue reconocida y registrada. La segunda tendría que verificar que el resultado contiene los eventos esperados. Un ticket puede cerrar correctamente aunque la dirección carezca de cambios históricos. También puede producir un documento válido cuya cobertura empiece después del hecho investigado. El código de éxito no conoce la diferencia.

El contrato de salida añade otra pista. Según el ReadMe, Net Range admite direcciones IPv4 o IPv6, y el informe maneja acciones como creación, modificación y eliminación del registro. Es la gramática adecuada para contar la evolución de un recurso. Pero los esquemas suelen describir el universo posible, no el inventario poblado. Una exportación puede añadir campos antes de completar una migración; una misma estructura puede servir a cohortes con distinta profundidad.

La descripción del servicio es la afirmación más amplia: el informe contiene toda la historia pública de la dirección o el ASN. ARIN explica que una dirección pudo pertenecer a varias redes a lo largo del tiempo, que esas redes pudieron asignarse a distintas organizaciones y que cada organización pudo tener varios POC. El texto muestra por qué el informe es complejo. No publica, sin embargo, una matriz por familia de direcciones ni un caso IPv6 de historia conocida.

Decir que la función está completa porque el manual incluye 2001:DB8:: sería convertir una prueba de sintaxis en una auditoría de datos. Decir que no existe porque una sugerencia de 2026 lo pidió sería convertir una ficha administrativa en telemetría. La salida responsable es mantener las proposiciones separadas hasta que un ensayo común las una.

El vacío es un resultado ambiguo

La calidad de un archivo se vuelve visible cuando no encuentra nada. Una dirección puede no haber cambiado nunca en el registro público. Puede haber formado parte de un bloque padre cuyos límites se modificaron. El evento buscado puede ser anterior al horizonte conservado. Las relaciones con organizaciones o contactos pueden haberse migrado de forma diferente. El permiso del solicitante puede impedir la operación. O la historia IPv6 puede no estar habilitada para ese caso.

Todas esas causas producen decisiones distintas. Un equipo de abuso intenta atribuir control en el momento de un incidente. Un asesor de transferencias necesita establecer continuidad entre titulares. Un operador busca explicar a un cliente por qué desapareció una asignación. Un abogado quiere fechar una representación pública del registro. La respuesta “sin historia” solo es útil si informa qué clase de ausencia representa.

La frase “toda la historia pública” tiene límites razonables. Pública excluye datos protegidos. Historia empieza donde comienza la conservación o la migración. Toda puede significar todos los eventos públicos retenidos, no todos los hechos reales sobre la explotación de la red. Hacer visibles esos límites no rebaja la promesa; la convierte en algo que un profesional puede interpretar.

Sin esa clasificación, cada empresa crea una memoria paralela. Los analistas anotan que antes de cierta fecha los resultados son inseguros, que determinadas relaciones faltan o que una consulta IPv6 vacía requiere soporte. Ese saber no tiene versión, no distingue una corrección reciente y no puede compararse entre organizaciones. Es un coste de coordinación producido por la falta de un recibo pequeño.

Las listas de proyectos no responden a una consulta

La página de funcionalidad planificada de ARIN avisa de que ofrece una visión general. Para 2026 enumera alta disponibilidad, reducción de deuda técnica, cambios por políticas y tarifas, mejoras de sitios, SOC 2 Type 2 y seguridad de enrutamiento. No menciona de forma explícita historia IPv6 en WhoWas.

La página de versiones conserva la genealogía del producto: WhoWas aparece en marzo de 2012 y sus informes mediante Reg-RWS en mayo del mismo año. En las entradas visibles de 2025 y 2026 no hay una línea que anuncie historia IPv6. Varias versiones, no obstante, agrupan mejoras menores y correcciones sin enumerarlas.

La omisión no demuestra que el trabajo no se haya desplegado. Una visión general no es un backlog completo y un resumen no es un historial de commits. Un cambio puede viajar dentro de una entrega mayor o entre dos fechas publicadas. Las páginas sirven para constatar que falta la referencia, no para inventar un veredicto técnico.

Si la capacidad ya existe, ARIN podría cerrar el círculo con un enlace desde las sugerencias a la versión y a la revisión del manual. Si es parcial, una tabla por periodos y clases de objetos sería más exacta que un indicador binario. Si el manual describe una intención futura, debería separar la sintaxis aceptada de la cobertura disponible. Cualquiera de esas opciones reduce la ambigüedad sin prometer lo que el registro no pueda sostener.

Un caso de prueba que no pertenezca a nadie

La prueba pública no debe usar la historia de un cliente. WhoWas requiere acceso aprobado y condiciones de uso porque el informe puede incluir relaciones históricas y contactos. El test idóneo sería una dirección IPv6 reservada para documentación o para el entorno de evaluación, con una secuencia conocida y publicable: creación del registro, cambio de organización, modificación de POC y retirada o sustitución.

El recibo identificaría la versión del sistema y la fecha. Registraría si la dirección fue aceptada, si el ticket terminó, si apareció un adjunto y si el documento contenía el evento más antiguo y las clases previstas. Añadiría las cohortes no migradas, los vínculos que no se garantizan y cualquier límite temporal. Cuando algo cambiara, una corrección fechada mantendría la procedencia del resultado anterior.

Un hash del escenario y de la expectativa ayudaría a demostrar que el ejemplo no fue reescrito después de conocer la salida. No sería un adorno: la ruta de la API puede permanecer idéntica mientras cambian el analizador, la base histórica o el generador. La prueba necesita identificar la generación que examinó.

El recibo no certificaría cada fila ni prometería que toda dirección tiene una historia extensa. Tampoco transformaría WhoWas en un servicio de investigación masiva, uso que ARIN excluye. Probaría una afirmación mucho menor: en una versión conocida, la entrada IPv6, el ticket, el formato y una secuencia histórica esperada funcionaron juntos.

El control de acceso concentra la capacidad de probar

ARIN controla el permiso, el archivo, la generación del informe, la documentación y el seguimiento ACSP. El operador controla qué dirección investiga y qué otras pruebas compara. Una organización antigua puede aparecer en el registro sin controlar la conservación ni el acceso. El público puede leer la promesa pero no reproducir la respuesta.

Esa asimetría tiene una consecuencia favorable: ARIN es también quien mejor puede publicar una prueba sin divulgar datos. Pedir a usuarios que demuestren la función con informes reales elevaría el riesgo de privacidad y produciría casos no comparables. Un escenario sintético, mantenido por el registro, sería más limpio.

La separación de responsabilidades explica por qué falta el enlace. El equipo de API actualiza parámetros. El equipo de datos mantiene la historia. ACSP cierra solicitudes cuando pasan a planificación. Las notas de versión seleccionan noticias. Cada página puede ser correcta desde su oficina y aun así dejar sin respuesta la experiencia completa del usuario.

Lo que se puede afirmar sin exagerar

No hay fundamento para decir que WhoWas rechaza IPv6: la documentación vigente acepta esa entrada. Tampoco hay fundamento para declarar completa la historia IPv6: no se observó un informe controlado. Las respuestas ACSP no prometieron fechas, así que no se puede afirmar un incumplimiento de plazo. “Closed” no equivale a “released”.

Sí puede afirmarse que dos usuarios buscaron historia IPv6, que ARIN la trató como mejora a priorizar, que la interfaz y el formato actuales hablan ya el idioma de IPv6 y que el registro público no muestra la versión que reconcilia esos hechos.

El recibo propuesto cabe exactamente en ese hueco. Si la función ya fue entregada, hará visible la finalización. Si sigue pendiente, definirá una condición verificable sin imponer calendario. Si está disponible por cohortes, convertirá límites ocultos en información profesional. El archivo dejará entonces de depender de una deducción imposible: que abrir la puerta demuestra por sí solo lo que hay en cada cajón.

Fuentes