Resumen

  • RFC 1504 combinó un identificador de dominio con el rango original para transportar una identidad única a través del túnel, mientras cada red local podía asignarle un alias no conflictivo.
  • Un camino redundante podía devolver ese alias sin su procedencia. El router que lo había creado lo veía entonces como una red nueva, lo traducía de nuevo y producía copias fantasma de la misma red física.
  • Ni el número, ni una actualización reconocida, ni una tabla sin alarmas demostraban identidad o entrega: hacían falta época de asignación, puerto, conexión, secuencia, fotografía completa y resultado de tráfico.

La colisión era real y las dos administraciones también

RFC 1504 apareció en agosto de 1993 como documento informativo de Alan Oppenheimer, de Apple Computer. Su propósito declarado era documentar por completo un protocolo Apple que podía circular sobre Internet. No era un estándar de Internet y tampoco una medición de adopción.

AURP conectaba internets AppleTalk mediante redes ajenas —por ejemplo, una internet TCP/IP— o enlaces punto a punto. La escala creaba un problema sencillo: organizaciones que nunca coordinaron sus planes podían usar el mismo número de red. Al interconectarlas, el número dejaba de ser único.

Obligar a renumerar de inmediato habría trasladado todo el costo al dominio antiguo. Aceptar dos significados para el mismo número habría hecho ambiguo el reenvío. AURP introdujo una capa intermedia.

Cada red exportada tenía un UI, un identificador único para el túnel. Un router con remapeo lo construía a partir del DI del dominio y del número o rango original. En la red receptora, el router exterior elegía una cifra libre de un rango reservado. Las máquinas locales seguían viendo números AppleTalk normales, y la frontera recordaba qué alias correspondía a qué UI.

La solución preservaba autonomía porque la identidad compartida era pequeña y la presentación seguía siendo local. También creaba una obligación: conservar la relación. El alias no podía explicar por sí solo de dónde venía.

Un número igual y un número distinto podían engañar

Si dos routers receptores asignaban alias distintos al mismo UI, los números diferentes no implicaban dos redes. Si un router reutilizaba una cifra en otro momento, el mismo número no implicaba la misma red. La identidad dependía de la combinación de origen, lugar y tiempo.

El remapeo estático daba a un UI una posición previsible. Ayudaba al operador, pero gastaba una reserva finita. El dinámico asignaba cifras al descubrir redes y aprovechaba mejor el rango; a cambio, cada reutilización abría una nueva época.

RFC 1504 recomendó reutilizar sólo cuando se agotaran las demás cifras y no entregar inmediatamente a una red nueva el UI que acababa de pertenecer a una red caída. El matiz es importante: quitar una fila de la tabla no demuestra que hayan desaparecido los paquetes demorados, los cachés y las referencias de gestión que todavía conservan el significado anterior.

Una tabla segura debía recordar <router, puerto, época, DI, rango original, alias local, alta, retirada>. Reducir todo a <alias, destino> ahorraba columnas y perdía la capacidad de explicar el siguiente incidente.

La traducción conocía algunos campos, no todos los lenguajes

El router podía cambiar números en cabeceras DDP, direcciones de entidad NBP y datos de encaminamiento AURP. La operación podía modificar la cabecera y parte del contenido. Si existía checksum DDP, primero se comprobaba y luego se ponía a cero, porque ya no correspondía al paquete reescrito.

Pero el router no sabía dónde había escondido un protocolo de tercero otra dirección AppleTalk. Un paquete podía cruzar la frontera con la cabecera correcta y el dato interno equivocado. La ruta parecía operativa; la aplicación no encontraba su objeto.

La gestión mostraba otra vista. Una consulta a través del túnel podía recibir números originales no remapeados dentro de la respuesta. Para relacionarlos con la vista local, la estación necesitaba la base de remapeo AURP. RFC 1742 añadió después objetos normalizados para puertos, RTMP, tablas y contadores AppleTalk. Esos objetos ofrecían observaciones parciales, no una identidad global.

Por eso un NOC podía ver tres verdades compatibles: el UI exportado, el alias local usado para reenviar y el número original devuelto por una consulta. El error empezaba cuando la interfaz los presentaba sin decir qué capa y qué época representaba cada uno.

El alias salió por una frontera y regresó por otra

La red fantasma requería un bucle. Dos internets AppleTalk estaban unidas por el túnel y, además, por un camino redundante. El alias creado al importar una red podía avanzar por el entorno local, tomar ese segundo camino y volver al router exterior de origen.

Al regresar, ya no llevaba el DI y el rango original como UI de túnel. Parecía una red local auténtica. El router no podía reconocer que era su propia salida, así que la convertía en otra identidad de túnel, le asignaba otro número y la exportaba.

La red física seguía siendo una. La tabla veía dos, luego tres representaciones. RFC 1504 las llamó shadow networks. Cada vuelta podía añadir una copia hasta que la distancia aparente superara el límite de saltos.

El límite evitaba una circulación infinita de tráfico, pero no era un mecanismo de verdad. Una entrada que muere por exceso de saltos no recupera automáticamente el origen de sus alias hermanos. El diagnóstico exigía seguir el camino inverso.

El remapeo parcial partía la capacidad de detectar

AURP trataba un túnel multipunto como un único enlace virtual. Cada router exterior aplicaba horizonte dividido: no reenviaba por ese mismo túnel las rutas aprendidas de otro router exterior. Esto suponía conectividad directa entre todos los participantes.

Una topología multipunto podía estar parcialmente conectada por política o por error. El router, por lo general, no sabía cuál de las dos cosas ocurría. El diseño lógico decía “un enlace”; la realidad podía parecerse a dos enlaces unidos por un intermediario.

El remapeo se configuraba individualmente. Los routers que remapeaban ejecutaban detección de bucles relacionada con esas funciones; los que no remapeaban, no. Con una mezcla, un bucle entre routers no remapeadores podía permanecer invisible y presentar copias a un router que sí remapeaba.

Dos routers redundantes con remapeo necesitaban el mismo DI para el dominio local y la misma tabla UI-alias. RFC 1504 sugirió configuración común o intercambio futuro, pero dijo que AURP no proporcionaba entonces esa sincronización. Se podía duplicar el camino sin duplicar de forma transaccional el contexto que daba sentido al camino.

La semejanza abría una investigación

El documento propuso identificar como sospechosa una información de ruta cuyo tamaño de rango y lista de zonas coincidieran con una red local. No ordenó tratar la coincidencia como condena. El router debía enviar un paquete por el túnel y observar si retornaba por un puerto local.

La prueba añadía procedencia activa. Un atributo similar sólo decía “podría ser mi red”. Ver volver la instancia emitida decía “este camino la devuelve ahora”. Aun así, no demostraba intención, permanencia ni efecto sobre todos los servicios.

El control de seguridad era igualmente limitado. RFC 1504 llamó débiles al ocultamiento de redes y dispositivos y dejó fuera la seguridad general. Quitar una red de la presentación reducía visibilidad; no autenticaba rutas ni demostraba que el objeto hubiera desaparecido.

Fotografía y eventos podían cruzarse

AURP reducía la charla periódica de RTMP y ZIP con un intercambio inicial y actualizaciones posteriores. Las conexiones eran unidireccionales, tenían un identificador y numeraban los paquetes. El emisor esperaba un RI-Ack antes de mandar el siguiente.

Un receptor nuevo podía iniciar el intercambio mientras el emisor aún acumulaba cambios. La fotografía inicial y el evento posterior podían parecer incongruentes. RFC 1504 transformaba algunos casos: un cambio de distancia de una red desconocida se procesaba como alta; un alta de una red ya conocida, como cambio; determinadas bajas desconocidas se ignoraban.

Estas reglas permitían reconstruir una tabla útil, no demostrar un instante común. RI-Ack confirmaba la recepción de un paquete con una secuencia. No confirmaba la propagación local, la igualdad de los mapeos, el estado de otro peer o la entrega del datagrama.

Si el receptor sufría desbordamiento y perdía información, las actualizaciones no se retransmitían indefinidamente. Debía solicitar una tabla completa con RI-Req. Cuando falta un tramo de historia, una actualización reciente no puede certificar lo ocurrido en el hueco.

Un expediente para desmontar el fantasma

La investigación necesita enlazar seis registros: UI original; decisión de mapeo con época; mensaje y secuencia; puerto y camino de entrada; tabla y next hop seleccionados; sonda o carga útil en el servicio correcto.

Con ellos se puede distinguir:

  • dos dominios reales que chocan en una cifra local;
  • un dominio mostrado bajo dos alias;
  • un alias reutilizado entre dos épocas;
  • una traducción propia que volvió por un bucle;
  • una dirección interna que nunca fue reescrita;
  • una ruta válida sin entrega válida.

El número aislado no resuelve ninguna de esas bifurcaciones. Es útil para ejecutar una decisión local y demasiado pobre para explicar su autoridad.

Lo que no dicen los documentos

Las fuentes no establecen cuántos routers AURP existieron, qué fabricante implementó todas las opciones, si ocurrió un incidente concreto ni si hay una red moderna que conserve el diseño. RFC 1504 guarda una especificación informativa, no un registro de ejecución.

RFC 1378 permite negociar AppleTalk sobre PPP y transportar información AURP en el enlace. No certifica convergencia. RFC 1742 define un vocabulario de gestión; no demuestra que un agente exponga todos los mapeos. Los textos de Lu Heng aportan la regla analítica: publicación, implementación, autoridad local y resultado observado no son intercambiables.

La lección histórica no depende de fingir actualidad. AURP dejó un ejemplo extremadamente concreto de cómo una capa de compatibilidad puede mantener el servicio y, al perder procedencia, inventar objetos que nunca existieron.

Fuentes