Resumen

  • RFC 2373 asignó las direcciones anycast desde el espacio unicast: sus bits no revelaban que varios interfaces compartían el destino ni cuál recibiría el paquete.
  • «Más cercano» significaba el resultado de la métrica vigente de los protocolos de enrutamiento, no cercanía geográfica, menor latencia, mejor salud, menos carga o identidad estable.

Un destino escrito, ningún ganador incorporado

La arquitectura de RFC 2373 empezaba por los interfaces. Unicast identificaba uno; multicast identificaba un conjunto y entregaba a todos; anycast identificaba también un conjunto, pero entregaba solamente a un miembro, el considerado «más cercano».

La innovación estaba en lo que el formato no añadía. Las direcciones anycast procedían del espacio unicast y conservaban sus formatos. Eran sintácticamente indistinguibles. Cuando la misma dirección se asignaba a varios interfaces, los nodos participantes debían configurarse de forma explícita para reconocerla como anycast.

Por tanto, una dirección observada en un registro no era un inventario. No decía si el destino pertenecía a uno o muchos interfaces, no nombraba al que respondería y tampoco conservaba las razones de la selección.

«Más cercano» era una conclusión de las rutas

Las comillas importaban. La distancia era la que los protocolos de enrutamiento calculaban después de incorporar topología, políticas y anuncios disponibles. No equivalía a kilómetros, latencia de aplicación, estado del proceso, carga de la máquina ni propiedad administrativa.

Así, el reenvío ordinario podía alcanzar a un miembro sin un campo nuevo en el paquete. Pero también podía elegir otro cuando cambiaban las rutas. Dos puntos de observación podían llegar a máquinas distintas usando la misma dirección; un mismo punto podía llegar a otra más tarde. La cadena estable era un lugar de encuentro para el servicio, no el nombre permanente de una máquina.

La pertenencia se encontraba en el plano de enrutamiento

RFC 2373 definió para cada conjunto anycast el prefijo más largo P que contenía la región topológica de todos sus miembros. Dentro de P, cada miembro tenía que aparecer como una entrada separada, una ruta de host. Fuera de P, la dirección podía agregarse a la ruta del propio prefijo.

La escala imponía un precio visible. Si no existía una región topológica común, P podía ser el prefijo nulo y la ruta específica tendría que circular por todo Internet. El RFC calificó la consecuencia como una limitación grave y previó que los conjuntos globales serían imposibles o estarían muy restringidos.

La dirección no llevaba esa lista de miembros. Los operadores la construían mediante configuración de interfaces y anuncios; la agregación podía ocultar deliberadamente los miembros individuales a observadores remotos.

Ceros que podían significar «uno de los routers»

La dirección anycast obligatoria Subnet-Router materializaba la ambigüedad. Se formaba con el prefijo de subred y un identificador de interfaz compuesto por ceros. En sintaxis era idéntica a una dirección unicast para el interfaz cero. En operación, todos los routers de la subred debían reconocerla y solo uno recibía el paquete.

Para las demás direcciones, las implementaciones debían suponer unicast salvo configuración expresa de anycast. Parte de la clasificación vivía fuera de los 128 bits: en la configuración del nodo y en el estado de reenvío.

Las restricciones iniciales eran una medida de prudencia

RFC 2373 reconocía que había poca experiencia con el uso arbitrario de anycast a escala de Internet. Prohibió temporalmente usarlo como dirección de origen y limitó su asignación a routers. Esas restricciones desaparecieron en especificaciones posteriores, pero sobrevivió el modelo central de formato unicast, pertenencia configurada y selección por rutas.

La historia no debe leerse hacia atrás. En 1998, una especificación inicial mínima reutilizaba mecanismos conocidos, exigía un caso concreto entre routers y acotaba una superficie poco entendida. La autorización posterior no demuestra que los riesgos ya estuvieran resueltos ni convierte a RFC 2373 en una descripción de las operaciones anycast modernas.

El alcance probatorio de una respuesta

Una respuesta demostraba que, en ese instante y desde ese lugar, algún camino alcanzó a un miembro capaz de contestar. No enumeraba los miembros, no probaba que la ruta fuera óptima o elegida por una comprobación de salud, no garantizaba la próxima selección y no acreditaba el resultado final de la aplicación.

Una cadena de evidencia sólida separa la dirección de destino, la membresía configurada, cada anuncio, la ruta seleccionada desde cada punto, el interfaz receptor, el proceso que contestó, la continuidad de sesión y el resultado de negocio.

El principio de Lu Heng sobre la primacía del código en ejecución sitúa la autoridad en la configuración y el reenvío que realmente operan, no en la etiqueta. La especificación inicial mínima explica la reutilización del formato. Las capas de realidad recuerdan que dirección, ruta, respuesta y operación concluida son hechos contiguos, pero no intercambiables.

RFC 2373 permitió que una dirección encontrara a un miembro del conjunto. Lo consiguió precisamente porque no fingió saber de antemano cuál sería.