Resumen

  • LISP separa la identificación del extremo de la localización de red, pero convierte la entrega en una conjunción: registro autorizado del ETR, resolución del Mapping System, Map-Cache vigente, RLOC admisible, underlay alcanzable y reenvío interior correcto.
  • David Meyer es uno de varios autores que llevaron LISP desde su primera especificación hasta el RFC 9300; su papel importa porque muestra cómo una idea de arquitectura acaba necesitando relojes, derechos, señales de error y procedimientos de retirada.

Empezar por la respuesta negativa

Una forma útil de entender LISP es observar lo que ocurre cuando no existe una ubicación utilizable. El RFC 9301 permite que una respuesta sin localizadores indique que el EID no está registrado, que una política niega el acceso o que falló la autenticación. También puede ordenar que el paquete siga de manera nativa, que se repita la consulta, que no se haga nada o que se descarte. El protocolo se niega a llamar “ausencia” a cuatro situaciones institucionalmente distintas.

Esa precisión contradice la versión publicitaria de la separación identidad-localización. Si la ubicación hubiese desaparecido, no harían falta ni un registro autorizado ni una respuesta sobre por qué no se puede usar. LISP hace otra cosa: evita que el EID lleve información topológica interdominio y crea un sistema externo para mantenerla.

El punto de partida histórico fue la escala. El RFC 4984 recoge el taller de enrutamiento y direccionamiento de la IAB de 2006. Sus participantes consideraron que usar una sola dirección como identificador y localizador contribuía al crecimiento y la inestabilidad de las tablas, y que hacía falta alguna separación. No diseñaron allí la solución y sus opiniones no eran una posición oficial de la IAB.

El RFC 9299 explica la elección de LISP. EID y RLOC conservan la sintaxis de direcciones IPv4 o IPv6, pero viven en espacios semánticos diferentes. El EID identifica el extremo; el RLOC identifica un punto de conexión topológico. Los routers LISP consultan una relación entre ambos y encapsulan el paquete hacia el RLOC. Dos cadenas de bits pueden parecer iguales y obedecer a autoridades diferentes.

El identificador no lleva una escritura de propiedad

El RFC 9300 exige que un EID usado en Internet público sea único y proceda de un prefijo asociado al sitio. La palabra “identificador” no debe transformarse en identidad jurídica o humana. El EID no demuestra quién controla el recurso, no autentica a su usuario, no concede movilidad entre proveedores ni prueba que exista una entrada en el Mapping System.

La entrega comienza en otro sitio. Un ETR configura la relación entre uno o varios prefijos EID y los RLOC que permiten llegar a él. Mediante Map-Register, publica esa relación en un Map-Server. El servidor debe conocer los prefijos que ese ETR está autorizado a registrar y ambos necesitan un secreto previo para autenticar el mensaje. El RFC advierte que aceptar prefijos sin comprobar esa autorización abre un secuestro trivial.

Un ITR que necesita enviar tráfico realiza la coincidencia de prefijo más largo en su Map-Cache local. Si encuentra una entrada, recibe el Locator-Set. Si no, formula un Map-Request a través del Map-Resolver. Mientras espera, el despliegue decide si pierde o almacena temporalmente los paquetes. Una misma arquitectura puede ofrecer experiencias de fallo muy diferentes según esa decisión local.

La respuesta entra en caché con un TTL. El valor cero obliga a borrar de inmediato; otro valor excepcional permite que el receptor elija cuánto conservar. Esto crea una diferencia fundamental entre la verdad autoritativa y la copia que usa cada router. Un Map-Server puede haber aceptado una ubicación nueva mientras un ITR distante todavía usa la anterior.

El Locator-Set tampoco es una lista neutra. La Priority menor se prefiere; 255 prohíbe usar ese RLOC. Entre localizadores con la misma preferencia, Weight reparte la carga. Cambiar el peso es cambiar el comportamiento del servicio aunque el EID y todos los RLOC sigan escritos igual.

Después de la selección falta la red física y administrativa. El underlay debe llevar el paquete exterior hasta el RLOC. El ETR debe desencapsularlo y reenviar el paquete interior al destino. Un registro válido, una caché fresca y un RLOC seleccionado pueden coexistir con una avería de tránsito o con un fallo dentro del sitio.

La caducidad es parte del diseño

La caché a demanda reduce la necesidad de mantener todas las asociaciones en todos los ITR, pero convierte el tiempo en un dato de encaminamiento. El RFC 9301 prescribe renovaciones periódicas del registro y permite retirar una inscripción que deja de validarse. Cuando el ETR modifica el mapa, el Solicit-Map-Request invita a los ITR que realmente guardan esa entrada a consultar de nuevo. La señal y la respuesta tienen límites de frecuencia; quien no posee la caché no necesita refrescarla.

En redes cerradas y confiables, el RFC 9302 ofrece Map-Versioning opcional. Sus doce bits cambian cuando se añade o retira un RLOC, cambia Priority o Weight, o cambia la alcanzabilidad local. Al ser un contador circular, una versión muy antigua puede confundirse con una nueva si el operador no espera por lo menos el TTL anterior o la convergencia del tráfico activo. Sin embargo, el RFC 9300 prohíbe utilizar Map-Versioning, gleaning, Locator-Status-Bits y Echo-Nonce como atajos de actualización o alcanzabilidad en Internet público. Allí la información debe venir del plano de control.

La restricción es reveladora. Una señal presente en un paquete no se convierte en prueba sólo por ser rápida. Su ámbito de confianza determina dónde puede usarse.

La confianza precede a la consulta

El análisis de seguridad del RFC 9301 presupone que el Mapping System es seguro y confiable, que el ETR mantiene una relación preconfigurada con él y que el sistema conoce los EID autorizados. La manera de crear las claves y las asignaciones queda fuera del documento. Es una frontera honesta: el protocolo procesa una autoridad que otro proceso institucional tuvo que establecer.

El RFC 9303 define LISP-SEC para autenticar el origen, proteger la integridad, evitar repeticiones y verificar la autorización de una reclamación de prefijo. Sin esa protección, un atacante puede manipular la relación, desviar tráfico o reclamar un bloque mayor. LISP-SEC también conserva supuestos: el Mapping System ha de conducir la pregunta al ETR correcto y el Map-Server debe comprobar el derecho de registro. La seguridad protege el mapa; no convierte al EID en credencial.

La persistencia tiene además un coste de privacidad. Vincular un EID duradero con RLOC sucesivos puede revelar movimientos topológicos. La continuidad de una sesión o de una numeración no equivale a anonimato.

Meyer dentro de una autoría colectiva

El RFC 9300 lleva los nombres de Dino Farinacci, Vince Fuller, Dave Meyer, Darrel Lewis y Albert Cabellos como editor. Meyer también firmó el RFC 6830 original. No es razón para atribuirle LISP en solitario. Sí permite observar una continuidad poco común: el mismo arquitecto ve cómo una separación conceptual acumula restricciones públicas, mecanismos de caché y controles de seguridad.

La página histórica de ONUG sitúa a Meyer en Cisco y Brocade, en la IAB, en la comunidad NANOG y en la Universidad de Oregón con RouteViews. Son referencias de una época, no una afirmación sobre su trabajo actual. La experiencia sirve para situar la pregunta que atraviesa su obra: qué parte del plano de control puede documentarse y qué parte sólo se conoce al observar una red funcionando.

Ya existe un artículo sobre Meyer centrado en RouteViews, RPSL y OpenDaylight. Esta pieza evita repetirlo. No trata de abrir el plano de control al público, sino de conservar la diferencia entre el identificador, el registro autoritativo, la copia temporal y el camino efectivo.

El RFC 7215 ofrece la mejor vacuna contra una lectura heroica. Su guía Experimental de migración enumera comprobaciones de versión del equipo, configuración, MTU, prefijo, RLOC, claves, registro, caches de proxy, políticas BGP, visibilidad externa y tráfico. Aunque algunas técnicas reflejan la transición de 2014, la lógica probatoria sigue intacta: no se puede saltar desde “la norma existe” a “el servicio llega”.

Por eso, la evidencia mínima de una ubicación LISP tiene varias marcas de tiempo: quién registró qué, bajo qué derecho, qué resolvió cada ITR, cuándo caduca, qué RLOC eligió, si el underlay lo alcanzó y si el extremo recibió el paquete. La estabilidad del EID organiza el expediente; no lo sustituye.

Fuentes