Resumen

  • draft-ietf-lisp-site-external-connectivity-05 permite responder con un conjunto no vacío de localizadores pETR cuando la dirección es externa, desconocida o conocida pero no registrada.
  • La respuesta selecciona una puerta de salida dentro de un IID y una política. No convierte el hueco de mapeo en identidad del destino ni certifica la ruta nativa que comienza después del pETR.
  • Registro, selección, instalación en caché, desencapsulado y resultado de aplicación necesitan comprobantes distintos.

Un paquete llega al ITR y no encuentra un EID registrado. Hasta ahora, ese hecho podía producir una respuesta negativa con una acción acotada. La revisión 05 de LISP Site External Connectivity añade otra posibilidad: calcular el hueco no-LISP que cubre la dirección y devolver localizadores de uno o varios Proxy-ETR.

La idea resuelve una necesidad concreta. Una red empresarial, un VPN o un backend de cómputo puede disponer de varias salidas hacia dominios ajenos a LISP. Si cada ITR mantiene su propia lista, cambiar de pasarela es lento. Si los pETR se registran y el sistema de mapeo publica cambios, la selección se vuelve dinámica.

El peligro aparece cuando el resultado recibe un nombre demasiado amplio. El servidor no ha descubierto el destino. Ha decidido qué pasarela debe intentar transportar una clase de tráfico sin mapeo más específico.

Un hueco con siguiente salto sigue siendo un hueco

RFC 9301 define la respuesta negativa como un Map-Reply sin localizadores y con una acción. El nuevo borrador reutiliza el cálculo del prefijo hueco, pero exige un número de RLOC distinto de cero. Esa combinación no registra el EID ausente. Crea una política de salida para lo desconocido.

La diferencia debe permanecer en el modelo de datos. selected_external_exit es una conclusión defendible. destination_resolved no lo es. Conservar el estado desconocido permite investigar después si la pérdida ocurrió en el cache del ITR, en el túnel, en el pETR, en el enrutamiento externo, en un filtro o en el servicio final.

Un nuevo Map-Reply correcto puede coexistir con una aplicación caída. Repetir la consulta demuestra de nuevo el acto de selección; no aporta el recibo que falta fuera del dominio LISP.

El registro declara elegibilidad

El borrador permite que un pETR con conectividad externa se registre por Instance ID de VPN. El registro incluye un Distinguished Name configurable, el conjunto de RLOC y, si hace falta, contexto de VPN. También puede añadir datos LCAF específicos del proveedor sobre ubicación, disponibilidad de recursos o rendimiento.

Ese mensaje demuestra que un principal presentó una declaración y que la política de admisión la aceptó. No prueba que el enlace externo siga operativo cuando llegue el siguiente paquete. Conviene registrar por separado quién firmó, qué rol estaba autorizado para ese IID, qué localizadores controlaba, cuándo se comprobó la ruta y qué condición retira la inscripción.

La autenticación no sustituye a la autorización. Una pasarela auténtica puede anunciar el IID equivocado. Tampoco sustituye a la observación: una inscripción autorizada puede quedar obsoleta tras una avería aguas arriba.

RFC 9306 da cabida al formato LCAF de proveedor, pero no armoniza el significado de “rendimiento” o “disponibilidad”. Sin productor, unidad, ventana, método, confianza y caducidad, esos campos son indicios de política. No son una comparación objetiva entre caminos.

Prioridad y peso expresan intención

RFC 9300 selecciona primero la prioridad más baja y usa pesos relativos entre localizadores con la misma prioridad. Esto determina cómo un ITR reparte tráfico dentro del conjunto devuelto. No demuestra capacidad, independencia física, coste o latencia.

Dos RLOC diferentes pueden terminar en el mismo equipo o proveedor. Un peso 70/30 puede reflejar un contrato, no ancho de banda medido. Por eso el comprobante de decisión debe guardar candidatos, exclusiones, metadatos, versión de política, resultado de desempate y distribución prevista. Los contadores de encapsulado y desencapsulado muestran después la distribución real.

El matiz tiene consecuencias económicas. La pasarela que aporta su propia puntuación tiene incentivo para describirse favorablemente. Si el algoritmo no preserva procedencia y método, una preferencia comercial puede presentarse como hecho técnico.

Map-Notify no es entrega

RFC 9437 permite suscribirse a cambios y recibir Map-Notify autenticados. Map-Notify-Ack confirma el mensaje de control. La revisión 05 aprovecha ese mecanismo para propagar cambios de pETR; donde no existe, propone TTL más cortos.

Cada recibo se detiene en su capa. El ACK no demuestra que todas las estructuras de reenvío se hayan programado. La lectura correcta del cache no demuestra que un paquete haya llegado al pETR. El contador de desencapsulado no demuestra que el reenvío nativo alcanzó el destino. La respuesta de la aplicación no explica por qué se escogió esa salida.

Una automatización seria enlaza los pasos: notificación autenticada, validación de alcance, escritura, lectura posterior, canario hasta la pasarela, canario por la ruta externa y resultado de aplicación. El primer fallo identifica el límite operativo sin desacreditar hechos válidos anteriores.

La entrada por defecto multiplica el daño

El ITR puede instalar un prefijo hueco o una entrada por defecto. El borrador recomienda mantener bloques EID conocidos como entradas más específicas que siempre generen una nueva Map-Request. Esa protección impide que una regla externa amplia engulla el espacio que corresponde a resolución LISP normal.

Una entrada por defecto reduce trabajo, pero puede mover muchos flujos con un solo cambio. Además de disponibilidad, cambia el punto de observación, el coste, la jurisdicción y la aplicación de políticas. El despliegue debería comenzar por un IID limitado, con prefijos conocidos protegidos, ITR canarios y retirada selectiva. Vaciar caches ajenos para corregir un pETR amplía innecesariamente el incidente.

El registro de Datatracker describe un Internet-Draft experimental, no una RFC ni un informe de despliegue. La referencia a infraestructura de IA es una motivación, no prueba de uso por un producto o red concreta.

La lección encaja con las capas de realidad de Lu Heng. El nombre distinguido es un símbolo; el Map-Reply es una decisión; la entrada de cache es estado; el paquete es una acción física; la respuesta remota es un resultado. La precisión no consiste en elegir una sola etiqueta, sino en conservar las relaciones entre esas capas.

Fuentes