Resumen

  • El 27 de octubre de 1980, los IMP de ARPANET aceptaban y volvían a propagar actualizaciones con los números 8, 40 y 44: la comparación de seis bits hacía que cada uno pudiera parecer posterior a otro.
  • Según la reconstrucción probable de Eric Rosen en el RFC 789, una retransmisión alterada por un fallo físico inició el ciclo; los mensajes agotaron búferes, interrumpieron las comprobaciones de línea y convirtieron la propia red en una vía lenta para distribuir el parche.

El acceso respondía, pero los nodos ya no se comunicaban

El fallo no se presentó primero como un mapa de rutas equivocado. Algunos usuarios todavía podían entrar por una línea telefónica a un Terminal Interface Processor, o TIP. Sin embargo, al intentar llegar a un equipo conectado a otro Interface Message Processor (IMP), recibían «net trouble». Las conexiones abiertas se cortaban. El TIP seguía hablando con el usuario, pero el IMP ya no encontraba un camino utilizable hacia otro IMP. Esa diferencia dirigió la investigación hacia la red que conectaba los nodos.

Eric C. Rosen reconstruyó lo ocurrido en el RFC 789, usando, entre otras pruebas, volcados de memoria de varios IMP. En casi todos encontró búferes llenos de actualizaciones de enrutamiento pendientes. Parecían proceder del IMP 50, que había fallado poco antes y estaba fuera de la red durante el incidente. Su vecino inmediato, el IMP 29, también tenía problemas de hardware y perdía bits. Reiniciar los IMP cercanos no bastó: al volver a conectarlos recibían de sus vecinos las mismas actualizaciones.

Una regla de secuencia que se cerraba sobre sí misma

Cada IMP enviaba información periódica sobre las demoras y el estado de sus líneas. Las actualizaciones se propagaban por la red para que los nodos mantuvieran una visión compartida. Cada paquete llevaba un número de secuencia de seis bits que avanzaba en módulo 64. El receptor aplicaba una comparación de medio rango para decidir si el valor recibido era LATER, es decir, posterior al último que había aceptado del mismo origen.

No era una fecha ni un reloj. La regla consideraba posterior un número que avanzara hasta 32 posiciones, o uno que hubiera dado la vuelta por cero y quedara a más de 32 posiciones del otro. Con los valores encontrados, resultaba que 44 era posterior a 40, 40 a 8 y 8 a 44. La comparación formaba un ciclo.

Los volcados mostraban las colas repitiendo 8, 40, 44, y luego la misma secuencia otra vez. Las actualizaciones eran iguales salvo por el número de secuencia. Así, cada copia podía desplazar a otra como información «más reciente» y volver a difundirse. Cada IMP seguía aplicando la regla local prevista; el problema surgió porque coexistían valores que el proceso normal de generación debía mantener separados.

Rosen no afirmó conocer con certeza el origen de los tres valores. Su explicación más probable era que una actualización 44 se había reconstruido para retransmisión a partir de datos almacenados y que bits perdidos habían cambiado el número primero a 40 y después a 8. Los paquetes transmitidos llevaban suma de comprobación, pero al retransmitir un IMP volvía a crear el paquete desde sus tablas internas, que no se verificaban constantemente. Hacerlo habría consumido tiempo de CPU o memoria, recursos escasos. Rosen también consideró la posibilidad inversa: que el 8 fuese el original y se hubieran añadido bits.

La circulación de los tres números consta en los volcados; la causa física precisa es una inferencia.

El bucle de rutas se convirtió en agotamiento de recursos

El procesamiento de las actualizaciones tenía alta prioridad. Al circular sin fin, consumía CPU y búferes. Los IMP dejaban de disponer de búferes para procesar los mensajes HELLO e I-HEARD-YOU que los nodos vecinos utilizaban para confirmar que una línea estaba operativa. Sin esos intercambios, el protocolo de estado de línea no podía funcionar y el software declaraba las líneas caídas. El tráfico de control alteró así la topología que los demás IMP intentaban observar.

Por eso «el enrutamiento calculó una ruta errónea» no describe bien el diagnóstico de Rosen. Las rutas seguían siendo coherentes con las reglas y el programa ejecutaba su procedimiento. El fallo de hardware produjo un estado fuera de los supuestos normales; después, el tratamiento válido de ese estado consumió demasiados recursos sin una contención suficiente. El caso no prueba un ataque ni describe el enrutamiento de Internet actual. Muestra cómo una retransmisión puede amplificar datos corruptos y convertir un fallo localizado en una interrupción más amplia.

La reparación dependía de la red averiada

Los operadores aplicaron un parche que ordenaba a los IMP ignorar las actualizaciones del IMP 50, aunque ya estaba desconectado. En condiciones normales, el Centro de Control de la Red podía difundirlo en minutos. Durante la caída, controlar a distancia unos IMP que normalmente no tenían personal presente podía llevar tres o cuatro horas, porque el canal era la propia red. La vía de recuperación dependía de la infraestructura que trataba de recuperar. El parche funcionó; Rosen no encontró daños duraderos aparte de la interrupción.

Propuso ajustar el límite de la comparación LATER, mejorar la detección y corrección de errores en la siguiente generación de hardware C30 y detectar cuándo un proceso de alta prioridad consumía demasiados recursos, para poner el IMP en un estado controlable a distancia. Eran medidas en capas: impedir el ciclo conocido, detectar el error físico y poder recuperar el nodo. Ninguna demostraba que ya no pudiera producirse otro fallo poco común.

Fuentes y alcance

Rosen publicó el estudio en el número de enero de 1981 de SIGSOFT Software Engineering Notes y lo difundió como RFC 789. Es el registro principal del incidente y distingue observaciones de hipótesis. El artículo de McQuillan, Richer y Rosen de mayo de 1980 describe pruebas anteriores sobre la red en funcionamiento; no demuestra que se hubiera ensayado esta combinación excepcional de corrupción de datos almacenados y ciclo de secuencia. Una nota conmemorativa del Computer History Museum llama «marcas de tiempo» a los valores; el RFC especifica números de secuencia de seis bits.

Fuentes: RFC 789; McQuillan, Richer y Rosen, “The New Routing Algorithm for the ARPANET”; entrada del 27 de octubre del Computer History Museum; copia alojada del artículo de 1980 en IPCOMPRO; la primacía del código en ejecución de Heng Lu, citada solo como enfoque editorial.