Resumen

  • El plazo del 1 de enero de 1983 podía excluir tráfico NCP de ARPANET porque el patrocinador controlaba los IMP y respondía por esa red; no convertía el RFC en mandato para terceros.
  • RFC 801 dejó la implementación en manos de cada organización anfitriona y rodeó el corte de relés temporales, servicios sobre TCP, mediciones y ensayos que hicieron visible la falta de preparación.
  • La fecha no produjo perfección: los sondeos de servicios seguían lejos de una lectura ingenua del 100 %, el NIC tuvo problemas con la tabla de hosts y la carga real obligó a reajustar sistemas.

La compatibilidad dejó de ser una promesa

Para una máquina que sólo hablaba NCP, el cambio decisivo no ocurrió cuando se publicó la especificación de TCP. Ocurrió cuando ARPANET dejó de procesar el protocolo anterior. La máquina podía conservar su cable, su cuenta y su programa; sin el servicio del subnivel, ya no pertenecía al mismo conjunto operativo.

Vint Cerf recordó años después que los Interface Message Processors permitían rechazar el tráfico NCP. Según su relato, durante 1982 se apagó esa capacidad un día y, meses más tarde, unos dos días. El correo dejó de circular para quienes no habían migrado. La indignación confirmó algo que los avisos no habían logrado: el plazo no era una recomendación decorativa.

Su memoria no es un registro minuto a minuto. Cerf situó los ensayos de forma aproximada y dijo que en enero quedaron unas pocas excepciones para máquinas con dificultades especiales. Por eso conviene abandonar la imagen de un interruptor mundial perfecto. Hubo una secuencia gestionada dentro de ARPANET, no una conversión instantánea de todo lo que después llamaríamos Internet.

El límite que NCP llevaba dentro

NCP resolvía comunicación entre hosts en el entorno de ARPANET. Su diseño estaba ligado a los servicios y al modelo de direcciones de esa red. Pero el programa de investigación ya incluía radio por paquetes, satélite y redes locales, cada una con propiedades diferentes. Extender el mismo mecanismo de una sola subred no bastaba para unirlas sin borrar sus diferencias.

RFC 801 explica que IP y TCP surgieron para ofrecer un entorno común entre esas redes. RFC 791 definía la entrega de datagramas a través de redes; RFC 793 colocaba fiabilidad y orden en los extremos. El resultado era un «internet» de redes autónomas, no una ARPANET físicamente agrandada.

Ese objetivo cambia el sentido económico de la compatibilidad. Mantener NCP no era gratis ni puramente local. Los hosts de servicio, los relés, las tablas de nombres y los equipos de operación debían sostener dos mundos. Una organización que retrasaba su conversión trasladaba parte de su coste a quienes mantenían el puente.

El Department of Defense había adoptado IP/TCP para sus redes de paquetes. Como patrocinador de ARPANET, podía fijar una condición de acceso al servicio que financiaba y operaba. La autoridad no nacía de que Jon Postel escribiera un documento ni de que una comunidad alabara el protocolo; nacía de una responsabilidad concreta sobre una infraestructura concreta.

Un plan central que dependía de muchos talleres

RFC 801 no fingió que el centro podía hacer el trabajo de cada sitio. Encargó a cada organización anfitriona implementar IP/TCP en sus propias máquinas. Esto implicaba portar código a sistemas operativos distintos, resolver interfaces con el IMP, adaptar aplicaciones y formar personal local.

También exigía algo que los relatos centrados en las capas bajas suelen olvidar: Telnet, transferencia de archivos y correo debían funcionar sobre TCP. Una pila que respondía a una prueba pero no prestaba los servicios cotidianos no era una sustitución operativa.

El correo hizo visible la dependencia social. RFC 773 pedía que las direcciones conocidas siguieran funcionando, que los mecanismos antiguos sobrevivieran durante el intervalo y que el paso entre NCP y TCP se hiciera sin intervención del usuario cuando fuera posible. No era suficiente afirmar que el nuevo protocolo era mejor; había que conservar el trabajo que la red ya sostenía.

Para cubrir ritmos de conversión distintos, se desplegaron hosts de doble protocolo. Un usuario de Telnet podía entrar por TCP al relé y salir por NCP. Un archivo podía copiarse primero al intermediario y luego al destino. Un mensaje podía recibirse con un mecanismo y reenviarse con el otro.

La solución traía deuda. El relé añadía otra máquina a la cadena de fallos, requería cuentas y capacidad, y podía saturarse. RFC 801 trataba expresamente su fiabilidad y su carga. Era una herramienta para cruzar el intervalo, no una institución permanente obligada a mantener NCP mientras quedara un usuario.

Los cortes de prueba como evidencia

Un ensayo de apagado hace tres cosas que una declaración no puede hacer. Demuestra que el control existe, descubre dependencias que nadie registró y atribuye el fallo a un límite concreto. En 1982, el dolor del correo interrumpido indicó qué organizaciones seguían dependiendo de NCP y cuánto importaba el servicio.

No fue consenso por votación. Tampoco era una reivindicación de gobierno universal. La relación relevante era contractual y operativa: el patrocinador definía el servicio de su red; cada sitio decidía cómo completar su implementación; los usuarios podían exigir que el cambio estuviera preparado, pero no que NCP se mantuviera sin final a costa del resto.

Esta frontera impide usar 1983 como excusa para una policía global de protocolos. Una entidad que no controla el equipo, no paga la transición y no responde por la pérdida no obtiene poder sólo por publicar una fecha. En ARPANET, la consecuencia era que un paquete NCP ya no recibía servicio. Fuera de ARPANET, ningún tercero perdía por decreto la capacidad de operar su propia red.

Un 100 % que nunca fue una sola cifra

El calendario de RFC 801 preveía que en enero todos los hosts serían capaces de TCP, todos los servicios usarían TCP, los relés terminarían y NCP saldría de servicio. Los sondeos de David Smallberg ofrecen una vista menos ordenada.

RFC 847 resume pruebas semanales de servidores Telnet, FTP y SMTP. El 28 de diciembre de 1982 aceptaban conexión 95, 80 y 72 hosts respectivamente, sobre un total de 314. El 4 de enero de 1983 las cifras saltaron a 151, 132 y 124 de 315. El 22 de febrero llegaron a 190, 181 y 178 de 325.

No se puede convertir esos datos en una tasa simple de «migración». Un host apagado no contestaba; un sistema especial podía ejecutar TCP sin ofrecer ninguno de los tres servicios; las listas cambiaban entre semanas. Los autores calcularon que 37 hosts, un 11 %, pertenecían a categorías que hacían imposible esperar respuesta, y situaron el máximo razonable en torno al 89 %.

La lección es metodológica. Estándar publicado, pila instalada, puerto abierto, tráfico real y usuario satisfecho son estados diferentes. Los sondeos confirman una aceleración visible junto al corte, pero también impiden presentar la mañana del 1 de enero como un estado homogéneo y completo.

La carga de producción corrigió el guion

RFC 942, el informe posterior del National Research Council, observó que unos treinta hosts exclusivamente TCP habían participado durante los seis meses previos. Las pruebas permitieron mantener capacidad operativa durante el cambio, pero el nivel normal de servicio tardó meses en recuperarse.

El Network Information Center no estaba preparado para distribuir la tabla de hosts en el nuevo entorno. Los servidores comunes sufrieron problemas de rendimiento porque ninguno había soportado durante mucho tiempo la carga completa de usuarios. Hubo que analizar y ajustar parámetros después del corte. Los relés de correo fueron muy usados; otros tipos de relé, menos.

Esto no convierte la migración en fracaso. Define qué significa éxito en una infraestructura viva: se puede retirar la compatibilidad vieja y conservar la continuidad básica, mientras todavía se reparan capacidad, distribución de estado y operación. La fecha elimina una opción; no crea madurez instantánea.

También muestra la división real del poder. El centro podía ordenar el final de NCP en el subnet. No podía sustituir a los administradores de sistemas, operadores de TAC, personal del NIC, mantenedores de servicios y usuarios. La frontera de ejecución estaba concentrada; el conocimiento para hacerla soportable, distribuido.

Donde acababa la orden

Dentro de ARPANET, un host no tenía derecho ilimitado a exigir que la red siguiera sirviendo NCP. El patrocinador podía retirar un protocolo que bloqueaba su arquitectura de múltiples redes, siempre que preparara sustitutos, hiciera visible el riesgo y respondiera por la ejecución.

Fuera de esa relación, el mismo patrocinador no podía crear adopción. Universidades, fabricantes y redes distintas tenían que implementar TCP/IP y decidir con quién interoperar. La suite adquirió fuerza más amplia porque el código funcionaba entre tecnologías heterogéneas y porque los servicios útiles viajaban sobre él.

Así se separan coordinación y soberanía. Un operador puede rechazar en sus equipos un tráfico incompatible. Debe explicar la regla, medir sus efectos y asumir sus errores. No puede convertir el control de su borde en propiedad sobre las máquinas ajenas ni en capacidad para declarar inexistente otra compatibilidad.

El hito de 1983 fue, por tanto, más preciso que un nacimiento mítico. NCP dejó de ser una prestación ordinaria en ARPANET. La obligación local empujó a sus hosts; la utilidad y la interoperabilidad empujaron al resto. La autoridad técnica fue eficaz porque tenía un límite.

Fuentes y límites de la evidencia

El plan y sus hitos están en RFC 801. La continuidad del correo procede de RFC 773. RFC 791 y RFC 793 contienen las reglas comunes; RFC 820 documenta el entorno contemporáneo de transición.

Los recuentos de servicios son de RFC 847, con sus propias reservas. Los problemas operativos posteriores aparecen en RFC 942. Los apagados de ensayo, el rechazo en los IMP y las pocas excepciones se atribuyen a la entrevista de Vint Cerf del Computer History Museum.

No existe aquí una lista final de excepciones, un tiempo universal de caída ni un censo total de implementaciones. La evidencia respalda un corte planificado y ejecutado en ARPANET, seguido de meses de ajuste. No respalda una hora exacta en la que todas las redes del mundo adoptaran TCP/IP o «naciera» Internet.