Resumen

  • Un LSI permite que una aplicación heredada entregue a la misma pila un valor con forma de dirección; no autoriza a otra máquina a interpretarlo como localizador o identidad.
  • Las referencias, callbacks y cachés deben transportar alcance y época de mapeo, mientras que selección de ruta, asociación HIP y resultado de servicio conservan recibos propios.

Un éxito local preparó el fallo remoto

Una aplicación solicita un nombre, recibe un valor de treinta y dos bits, abre una conexión y guarda el valor para una devolución de llamada. Hasta ahí, la compatibilidad funciona. Más tarde envía el valor a un tercer sistema. El receptor ve algo que cabe en sockaddr_in y trata de conectarse.

RFC 5338 llama la atención sobre esta diferencia entre uso como handle breve y uso como referencia. En el primer caso, el valor viaja desde el resolvedor local hasta el socket de la misma máquina. En el segundo, cruza a un actor que no comparte la tabla LSI–Host Identity. Se conservaron los bits, pero no la autoridad necesaria para interpretarlos.

El patrón importa más que la tecnología concreta. Los formatos antiguos suelen condensar “dónde”, “quién” y “cómo volver” en una dirección. HIP separa identidad y localización, pero una aplicación sin modificar no conoce esa separación. La capa de compatibilidad puede sostener la ilusión durante una llamada local; no puede prometer que todos los usos secundarios sigan siendo válidos.

El LSI es una referencia local, no una ruta pequeña

RFC 5338 define el Local Scope Identifier como una cantidad que representa localmente una Host Identity en una API IPv4 o IPv6. RFC 9063 aclara el caso típico de treinta y dos bits: el LSI se traduce a HIT dentro de la capa HIP o del manejador de sockets y no se transmite por la red como dirección.

Por eso no basta con reservar un rango especial y enseñarlo a los operadores. El significado vive en estado: host asignador, HIT asociado, generación, caducidad y reglas de reciclaje. Si falta cualquiera de esas coordenadas, el valor puede ser un índice huérfano. En otra máquina, la misma secuencia puede apuntar a otra identidad o ser interpretada como IPv4 ordinario.

Una aplicación que usa el valor inmediatamente puede no notar la diferencia. Una base de datos que lo conserva durante meses sí la notará, quizá demasiado tarde. El atributo que parecía una clave estable era en realidad un puntero de proceso extendido a todo el sistema.

El resolvedor decide una representación, no el resultado

El documento describe un agente DNS local que obtiene información HIP y devuelve un LSI o HIT donde la aplicación espera una dirección. La pila mantiene la relación y la consume cuando llega connect() o sendto(). Hay utilidad real: software sin soporte HIP puede participar en una transición.

Pero cada paso tiene autoridad distinta. DNS aporta material de descubrimiento. La pila asigna un handle. La resolución posterior aporta localizadores. La política decide si intentar HIP. El intercambio criptográfico autentica dentro de su alcance. Los paquetes protegidos prueban uso del canal. La respuesta de la aplicación prueba el resultado pedido. Ningún paso hereda automáticamente todos los demás.

También puede haber una carrera. El resolvedor devuelve identificadores HIP y direcciones tradicionales; la aplicación inicia conexiones en paralelo. Aunque HIP aparezca primero, un camino ordinario puede ganar. Registrar sólo la lista devuelta convertiría preferencia en ejecución. El recibo correcto identifica el intento ganador y la política que lo permitió.

La distinción se vuelve crítica en auditorías de cumplimiento. “El host soportaba HIP” no equivale a “esta operación usó HIP”. Para afirmar lo segundo hacen falta datos de asociación y flujo, no el orden de getaddrinfo().

Una referencia necesita un nombre que el receptor pueda resolver

En el modelo de referral, B entrega a C la dirección de A. Si el dato es el LSI de A en B, C no recibe una referencia autosuficiente. Recibe una clave foránea sin la tabla principal. El fallo puede parecer falta de ruta, conflicto de ACL o indisponibilidad de A, cuando la pérdida ocurrió antes: se exportó una representación local.

La solución adecuada depende del protocolo. Puede ser un HIT con mecanismo de resolución, un nombre DNS y reglas de seguridad, o un objeto que incluya identidad, alcance y datos de descubrimiento. Lo que no funciona es etiquetar el LSI como “IP” y confiar en que su forma obligue a todas las máquinas a compartir significado.

RFC 5338 observa que estos programas también suelen romperse con ciertas formas de NAT. La lección no es que todo callback sea imposible. Es que un protocolo que transporta direcciones internas debe declarar quién las interpreta. HIP hace explícita una deuda que ya existía.

Cuando no se puede cambiar el protocolo, el sistema puede necesitar un mediador, una resolución remota o una prohibición de exportación. Cada alternativa debe producir evidencia. Un proxy exitoso no convierte retrospectivamente el LSI en global; demuestra que un actor con contexto realizó la traducción.

El tiempo altera el sujeto de los mismos bits

Las aplicaciones heredadas pueden guardar respuestas DNS más tiempo que la pila. RFC 5338 señala la dificultad de saber cuándo recolectar mappings LSI. Si se reutiliza pronto, un proceso rezagado puede dirigirse a otra Host Identity. Si nunca se reutiliza, el espacio y el estado operacional crecen.

La gestión necesita una época explícita. Una referencia completa combina LSI, host local y generación de asignación. Los logs deben añadir HIT, localizadores, FQDN y proceso. De ese modo un investigador reconstruye lo que la pila sabía en aquel momento, en vez de consultar la tabla actual y proyectarla sobre el pasado.

La recomendación de RFC 5338 de registrar HIT, LSI, direcciones correspondientes y contexto FQDN no es decoración diagnóstica. Es una defensa contra la pérdida semántica. Aun así, esos datos sólo prueban correlación de nombres y localizadores; no prueban que el servicio completara la operación.

Nombrar un HIT fortalece la intención, no entrega el servicio

Una llamada construida alrededor de una dirección IP puede significar apenas “llega al sistema que responde aquí”. La pila puede intentar HIP, pero el vínculo inicial entre dirección e identidad no siempre es fuerte o visible para el usuario. RFC 5338 contrasta esto con una solicitud explícita a un HIT, que expresa una identidad criptográfica concreta.

El nombre explícito reduce una ambigüedad, no toda la cadena. Todavía hay que obtener localizadores, completar la asociación, comprobar qué canal llevó los datos y observar la respuesta. La autenticación del host tampoco decide por sí sola autorización de la cuenta, disponibilidad del servicio o aceptación de la transacción.

Esta tesis no repite los límites ya cubiertos sobre registros DNS HIP, rendezvous, movilidad o ESP. Su objeto es el punto donde una aplicación antigua recibe un símbolo y le atribuye más alcance del que el emisor local podía conferir.

Un bind comodín deja una decisión de identidad debajo

El lado servidor conserva otra ambigüedad. Un servicio enlazado a una dirección comodín puede ejecutarse en un host con varias Host Identities. Si la aplicación no elige una, la política local decide. En UDP, una respuesta enviada después de recvfrom() puede salir con un HIT diferente del que el cliente asocia al socket y ser descartada.

El estado “escuchando” no demuestra continuidad de identidad. Para demostrarla hay que registrar la identidad local a la que llegó el datagrama, la identidad seleccionada para la salida y la política aplicada. Si el servicio no puede manejar esa multiplicidad, la publicación debe limitarse a la identidad que coincide con la salida predeterminada.

La compatibilidad funciona mejor cuando sus decisiones ocultas son observables. Lo contrario produce fallos en los que red, criptografía y aplicación parecen sanas por separado, mientras el enlace entre identidades cambió sin recibo.

Fuentes y límite probatorio

Las fuentes fijan especificaciones, arquitectura y resultados históricos de experimentación. No demuestran un despliegue actual, un producto, una organización afectada, un incidente ni una tasa de fallo.