Resumen

  • RFC 9962 permite que xTR participantes mantengan el mapa EID-a-RLOC de LISP; el diseño push replica registros con multidifusión y el pull localiza Map-Servers mediante una transformación coherente y DNS.
  • Un mapa, un registro autenticado y un acuse de procesamiento son pruebas acotadas del plano de control. RFC 9301 advierte que el estado de un RLOC no expresa la alcanzabilidad de la ruta vista por quien solicita.

LISP separa el Endpoint Identifier, que nombra un extremo dentro de una red superpuesta, del Routing Locator que transporta el tráfico encapsulado. Entre ambos hace falta un sistema de mapeo. En el modelo habitual, un Mapping System Provider opera Map-Resolver y Map-Server, y los xTR del plano de datos registran o consultan asociaciones allí. RFC 9962 no convierte el mapa en un hecho sin dueño. Cambia quién mantiene y sirve esa pieza limitada de información: los xTR que la usan pueden participar también como pares que la conservan.

Ese cambio de dependencia no es una demostración total del mundo. En RFC 9301, un ETR envía a un Map-Server un Map-Register que contiene un prefijo EID y un conjunto de RLOC. Si pide Map-Notify, recibe confirmación de que el servidor recibió y procesó el registro. Recibido, procesado y confirmado describen actos concretos de control. No dicen que todos los solicitantes puedan llegar por la ruta a ese RLOC, que el retorno funcionará o que el servicio detrás de la dirección sigue siendo apropiado para una obligación operativa.

RFC 9301 establece una frontera esencial: el estado de RLOC puede transmitir alcanzabilidad, pero no la alcanzabilidad de la ruta desde la perspectiva del solicitante; hace falta una prueba de ruta separada. El lugar de origen, la encapsulación, los filtros, el camino de vuelta, la congestión, la conmutación y la política del servicio pueden cambiar el resultado de una misma entrada. Un mapa correcto puede llevar por tanto a una ruta inútil. Y que un paquete alcance una dirección no resuelve identidad, autorización comercial ni aceptación operacional.

Los dos diseños de RFC 9962 hacen visible esa frontera. En push, los xTR se incorporan al mismo grupo multicast y un Map-Register puede distribuirse a todos los Map-Servers del grupo, que conservan estado registrado replicado. Gana redundancia, pero exige una base multicast real. En pull, una transformación determinista convierte el EID en un nombre DNS y localiza así el conjunto de Map-Servers pertinente. Replica menos estado, pero requiere acuerdo sostenido sobre función, nombres, módulo y expansión.

No son dos mejoras que se mezclen a voluntad: RFC 9962 exige escoger una; aun coexistiendo, siguen siendo sistemas discretos sin promesa de compatibilidad entre sí.

La autenticación también tiene frontera. RFC 9962 remite a RFC 9301 y ECDSA-AUTH para establecer confianza entre xTR. RFC 9301 protege origen e integridad de un Map-Register, usa un nonce frente a repeticiones y permite que el Map-Server rechace registros que no satisfacen sus claves o política. Eso vuelve atribuible la pregunta «quién presentó qué registro y qué hizo el sistema». No demuestra identidad del extremo, derecho a atender a un cliente, calidad de trayecto ni entrega futura. La prueba de una clave cubre un acto de protocolo, no todas sus consecuencias.

Leído junto a la defensa de Lu Heng de mecanismos iniciales mínimos y decisiones futuras localizadas, RFC 9962 importa porque acerca una función de coordinación a quienes participan sin otorgarle capacidad de decidir por ellos. Un mapa compartido puede rebajar el coste de descubrir y registrar. No debería adquirir, por el mero hecho de existir, poder para escoger tráfico, exposición de clientes, tolerancia a fallos o salida. La pregunta directiva no es si «descentralizado» suena bien; es qué dependencia cambió, qué registro puede auditarse y quién conserva el juicio final.

Fuentes