Resumen

  • La RFC 4620 ofreció a las herramientas de diagnóstico IPv6 una forma directa de preguntar a un nodo por ciertos nombres o direcciones, sobre todo en enlaces sin DNS ni enrutamiento global.
  • El nodo podía negarse. Su respuesta seguía siendo una declaración local, no una identidad autenticada ni un registro con autoridad.

Análisis

Una dirección IPv6 autoconfigurada puede funcionar y aun así resultar difícil de asociar con una máquina concreta. Al activar un enlace o investigar un fallo, quizá no haya DNS disponible en ese segmento; una dirección de ámbito local tampoco tiene por qué aparecer en una zona pública. Aun así, puede ser útil preguntar al extremo que responde qué nombre o qué direcciones relaciona consigo mismo.

En agosto de 2006, Michael Crawford y Brian Haberman describieron esa opción en la RFC 4620, publicada como protocolo Experimental. El documento limitó su uso al diagnóstico, la depuración y la gestión de redes. También mantuvo una frontera explícita: en Internet global, el DNS seguía siendo la fuente con autoridad para nombres y direcciones. La consulta al nodo no pretendía crear otro directorio mundial; servía para investigar enlaces donde el DNS o el enrutamiento global no estaban disponibles.

El intercambio viajaba en ICMPv6: tipo 139 para la consulta y tipo 140 para la respuesta. La consulta señalaba al nodo que debía recibirla y el asunto sobre el que preguntaba; esas direcciones podían ser distintas. Los tipos de información cubrían una operación sin datos, el nombre del nodo, sus direcciones IPv6 y sus direcciones IPv4. En las consultas de direcciones, varios indicadores permitían delimitar el ámbito solicitado. Así, una herramienta podía preguntar qué declaraba el extremo presente en el enlace, sin suponer que esa respuesta enumeraba de manera exhaustiva todas sus interfaces.

La negativa era un resultado previsto. El código de respuesta distinguía éxito, rechazo y tipo de consulta desconocido. Incluso una respuesta exitosa podía venir vacía. Por eso, el silencio, el rechazo, un tipo no reconocido y un resultado vacío no significan lo mismo; ninguno demuestra por sí solo que el equipo no exista. Antes de responder, el nodo debía comprobar que el paquete iba dirigido a una dirección unicast o anycast propia, o a un grupo multicast local al que se hubiera unido. La política local podía descartar consultas.

Un nonce de 64 bits se copiaba de la consulta a la respuesta para emparejar ambos mensajes y dificultar la falsificación a ciegas. Los autores advirtieron, sin embargo, que alguien capaz de observar el intercambio podía superar esa protección. Recomendaron IPsec cuando hiciera falta seguridad de comunicación y dijeron que los datos obtenidos no debían sustentar decisiones de seguridad sin autenticación adicional.

La divulgación también tenía límites. La configuración predeterminada debía rechazar consultas procedentes de direcciones de alcance global; el documento recomendaba limitar la tasa de respuesta y controlar la publicación de direcciones temporales de privacidad. IANA aún registra los tipos ICMPv6 139 y 140. Ese registro demuestra que existen números asignados, no que cualquier host vaya a responder. La RFC citó ping6 de KAME, USAGI y otras implementaciones IPv6 como ejemplo diagnóstico. Nmap documenta hoy un script de descubrimiento compatible; estos ejemplos confirman capacidad en herramientas, no cuántas redes permiten usarla.

La aportación histórica de la RFC 4620 fue acotada: hizo consultable la declaración local de un nodo para facilitar el diagnóstico, pero dejó explícitos tanto el derecho a no responder como la debilidad probatoria de la respuesta. El intercambio no identificaba a una organización, no demostraba quién controlaba el equipo ni convertía una observación en inventario autoritativo.

Fuentes