El día clave que cambió la autoridad: gobernanza tras la migración a TCP/IP

Resumen

• La transición de enero de 1983 fue sustancial pero desigual: las mediciones de febrero encontraron cientos de puntos finales de servicio TCP, aunque los resultados variaban según el servicio, la población de direcciones, la fecha de prueba y la ruta de red, y no describían una población universal que cambiara a medianoche.
• La influencia de los patrocinadores y operadores se ejerció mediante el rechazo a nivel IMP del tráfico NCP, las decisiones de excepción de DDN-PMO y la activación de hosts o puertos; la dependencia de los registros de SRI-NIC y la coordinación de números de USC/ISI aumentó operativamente sin pruebas de que la migración otorgara a ninguna de estas oficinas nueva autoridad discrecional.
• El proceso de excepción fue real pero parcial en lugar de independiente: los administradores podían presentar reclamas, una lista pública registraba la habilitación temporal de NCP y las fechas de vencimiento, y los retransmisores TAC y UDEL preservaban una accesibilidad limitada, pero no se publicaron las razones, los archivos de decisión completos ni hubo revisión fuera de DDN-PMO.

El 1 de febrero de 1983, un mes después del objetivo de ARPANET de conversión de NCP a TCP/IP, una prueba desde ISI-VAXA intentó conectarse a cada dirección en una tabla de hosts reciente del Network Information Center. El resultado no fue una red claramente dividida entre un pasado y un futuro. Fue un informe de ancho fijo lleno de conexiones aceptadas, rechazos, direcciones inaccesibles, sistemas muertos y campos de resultado vacíos.

La lista de hosts se había tomado de la tabla del NIC con fecha del 28 de enero. Las pruebas se ejecutaron desde ISI-VAXA los días 1 y 2 de febrero, y las entradas muertas, inaccesibles o con rechazo se reintentaron el 3 de febrero. El estudio intentó tres servicios TCP: Telnet, FTP y SMTP. No inspeccionó el software, no probó todas las funciones TCP o IP, no demostró que un host estuviera disponible continuamente ni enumeró cada ordenador conectado a las redes participantes. Registró lo que sucedió cuando un origen intentó puertos de servicio particulares durante períodos particulares.

El denominador enRFC 842, “Who Talks TCP?”fue de 328 filas de direcciones. De ellas, 200 comenzaban con el número de red 10, el espacio de direcciones de ARPANET, y 128 pertenecían a otras redes. Una fila no era necesariamente un ordenador físico único, una institución, un suscriptor de DDN o una organización. Un sistema con nombre podía aparecer en más de una dirección; los gateways y otras entradas operativas también podían aparecer en la tabla. Por el contrario, un sistema no registrado, desconectado, clasificado u omitido estaba fuera de la población medida.

Un recuento directo de las filas de resultados de RFC 842 produce la siguiente auditoría. El resultadoaccepted+de FTP se incluye en aceptadas. Una indicación de muerto o inaccesible que abarca las columnas de servicio se cuenta en ese estado para cada servicio.

Estas categorías describen observaciones, no explicaciones. Una entrada muerta podría haber tenido software TCP completamente funcional en una máquina que estaba apagada. Una dirección inaccesible podría indicar un problema de gateway, enrutamiento, direccionamiento o medición. Un rechazo podría significar que los paquetes llegaron a un punto final TCP pero la aplicación no aceptó la sesión solicitada. Un resultado vacío no revela si el fallo estuvo en el host, la ruta, el servicio o la tabla. La aceptación en un puerto demuestra menos que la conformidad total con TCP, IP, ICMP, enrutamiento, manejo de nombres y las aplicaciones principales.

La tabla de hosts tampoco era un censo de cumplimiento con el objetivo de enero del patrocinador. Sus 128 filas no pertenecientes a la red 10 incluían sistemas en redes operadas de forma independiente, de investigación, locales, extranjeras, de radio por paquetes, enlazadas por satélite y otras. Su aparición demostraba la participación en un entorno de internet en expansión. No demostraba que la Agencia de Comunicaciones de Defensa pudiera ordenar a todos sus operadores que hicieran la conversión.

El “día clave” del titular es, por lo tanto, una etiqueta retrospectiva, no el lenguaje ordinario del registro operativo. Los avisos contemporáneos hablaban de una migración, conversión o experimento solo TCP. En 1997, una historia de Internet Society escrita por varios participantes destacados describió el evento como unatransición al estilo “flag-day”. Ese relato posterior captó la fuerza coordinadora del plazo pero comprimió la implementación desigual que las tablas de febrero preservaron.

La conversión aun así tuvo consecuencias. Fue una decisión respaldada por el patrocinador para dejar de tratar la coexistencia NCP/TCP como el futuro normal de ARPANET. Su importancia no reside en una mítica transformación de medianoche sino en los mecanismos que hicieron creíble el objetivo: pruebas que deshabilitaron NCP en la red de conmutación, un proceso de excepción administrado por el operador, soporte temporal de retransmisión y terminal, aprobación de hosts y puertos, y una creciente dependencia de registros compartidos precisos.

1-18 de febrero de 1983: las observaciones cambiantes no formaban una curva de adopción

Un segundo estudio ilustra por qué los totales agregados no pueden convertirse casualmente en una historia de adopción constante.

RFC 843usó la tabla de hosts del NIC con fecha del 3 de febrero y probó desde ISI-VAXA los días 8 y 9 de febrero. Su población había crecido de 328 a 329 filas. Los recuentos totales de aceptadas fueron 187 para Telnet, 174 para FTP y 170 para SMTP, en comparación con 183, 170 y 169 en el informe anterior. Pero los grupos de la red 10 y fuera de la red 10 se movieron en direcciones opuestas.

Los recuentos de aceptadas de la red 10 aumentaron para los tres servicios. Los recuentos de otras redes disminuyeron para los tres. La tabla subyacente también cambió en una fila, y las máquinas individuales podían estar activas durante una prueba y no disponibles durante otra. Sin un análisis de entradas emparejadas que controle las adiciones, eliminaciones, fallos temporales y rutas cambiadas, los dos estudios muestran observaciones cambiantes en lugar de una tasa de adopción medida.

Diez días después,RFC 844planteó una pregunta diferente. Seleccionó las 187 entradas que habían aceptado Telnet en RFC 843 e intentó contactarlas desde un concentrador de terminal en la red de Clase C 192.1.2 en BBN. El éxito requería más que un servicio Telnet que aceptara a lo largo de la ruta anterior: los paquetes y las respuestas tenían que funcionar a través del enrutamiento de gateway, el direccionamiento de Clase C y el comportamiento ICMP relevante.

Las conexiones se ingresaron manualmente por dirección punteada y solo se hicieron tres pasadas. Un host no disponible durante esas pasadas podría no ser detectado. Los resultados, sin embargo, expusieron cuán fuertemente dependía un aparente éxito TCP del origen de la prueba y la ruta de red.

El agregado de 127 de 187 no puede respaldar una afirmación simple de que las redes externas iban rezagadas respecto a ARPANET. El grupo no Clase A tuvo la tasa observada más alta, 30 de 32. Tampoco la prueba establece que cada entrada no exitosa careciera de soporte de Clase C o ICMP; la disponibilidad temporal y las condiciones de ruta siguieron sin resolverse.

En conjunto, los tres informes establecen un hecho más limitado pero valioso. Un mes después del objetivo, cientos de filas de la tabla aceptaban los principales servicios TCP, mientras que la capacidad registrada, la disponibilidad de aplicaciones y la accesibilidad desde diferentes orígenes seguían siendo desiguales. La conversión había producido una operación sustancial, no una uniformidad instantánea.

Ese es el primer límite de gobernanza. La medición hizo visible la implementación, pero la medición no decidió por qué falló un host o qué remedio debía seguir. Esas decisiones pertenecían a los administradores de hosts, implementadores, operadores de gateway y conmutación, el NIC, la Oficina de Gestión del Programa DDN, los patrocinadores de investigación y, fuera de la población controlada por el patrocinador, los operadores de red autónomos.

Noviembre de 1981: el plan fue diseñado para terminar con la mediación

El objetivo operativo comenzó como un plan por etapas, no como una afirmación de que cientos de máquinas podían cambiar a la vez.

RFC 801, publicado en noviembre de 1981, estableció el 1 de enero de 1983 como meta para un cambio completo de ARPANET de NCP a IP y TCP. Indicó a cada organización de hosts que comenzara a implementar IP/TCP antes del 1 de enero de 1982 y asignó la misma responsabilidad local para Telnet, transferencia de archivos y correo. Se esperaba que los nuevos hosts de ARPANET comenzaran con TCP/IP en lugar de entrar a través de NCP.

Los hitos del plan revelan su diseño real. Ya existían hosts con capacidad TCP y solo TCP. Se esperaba que los servicios de retransmisión sirvieran de puente entre hosts incompatibles. La última conversión de solo NCP debía comenzar en enero de 1982; se esperaba que la mayoría de los hosts tuvieran capacidad TCP para julio; la conversión final estaba programada para terminar en noviembre. Solo entonces, enero de 1983 traería un servicio completo basado en TCP, la eliminación de NCP y el fin del soporte normal de retransmisión.

La implementación permaneció distribuida. Las organizaciones de hosts de ARPANET controlaban máquinas con diferentes procesadores, sistemas operativos, personal, fuentes de software y requisitos de servicio local. El patrocinador podía anunciar un plazo y financiar implementaciones, pero no podía hacer que una rutina de suma de verificación defectuosa fuera correcta por decreto. Un host podía tener IP y TCP pero carecer de SMTP. Un sistema que funcionaba a través de un gateway podía manejar mal otra ruta, opciones, fragmentación o ICMP. El propio RFC 801 advirtió sobre implementaciones que omitían sumas de verificación, no reensamblaban fragmentos, dependían de datos de enrutamiento limitados, ignoraban opciones, reordenaban incorrectamente los datos TCP o mantenían tablas de nombres estáticas.

Lo que el objetivo sí podía hacer era cambiar el coste de la demora. Una organización de hosts podía conservar el software NCP en su propio ordenador, pero no podía obligar al operador de ARPANET a transportar tráfico NCP indefinidamente. Una vez que la red de conmutación rechazó el tráfico antiguo y terminaron las retransmisiones ordinarias, la implementación local inconclusa se convirtió en un problema de accesibilidad para el host y sus usuarios.

RFC 801 modeló por qué la coexistencia prolongada no era atractiva. Los puntos finales solo NCP y solo TCP no podían comunicarse directamente, por lo que los hosts de retransmisión de doble protocolo tenían que mediar Telnet, FTP y correo. Telnet implicaba una cuenta intermedia y un segundo inicio de sesión. FTP podía requerir mover un archivo al almacenamiento de retransmisión y luego transferirlo de nuevo. El correo requería lógica de reenvío y direccionamiento consciente del protocolo. Cada retransmisor añadía otra máquina que debía estar disponible y otro servicio que requería capacidad, control de acceso, documentación y soporte.

El modelo numérico de carga de retransmisión del documento era explícitamente especulativo, pero su argumento institucional era sólido. La coexistencia indefinida no era una preservación neutral de la elección. Alguien tenía que financiar y operar la unión entre los dos entornos. Un plazo transfería esa carga de los operadores de retransmisión a las organizaciones de hosts que no habían completado sus conversiones.

El plan por sí solo no prueba que esta transferencia ocurriera. El registro de ejecución aparece en una fuente diferente: los boletines operativos distribuidos por el NIC para la DCA y su Oficina de Gestión del Programa DDN.

Octubre-diciembre de 1982: la aplicación se trasladó a los IMP

El 1 de octubre de 1982, desde el mediodía hasta las 4 p. m., hora del Este, ARPANET realizó un experimento solo TCP. Durante esas cuatro horas, se instruyó a los Procesadores de Mensajes de Interfaz para que rechazaran los mensajes de host que usaran el enlace 0, el enlace asociado con el tráfico host a host NCP. El IMP devolvía un estado tipo 7, subtipo 3 que indicaba que la comunicación con el destino estaba "administrativamente prohibida".

Ese mecanismo, descrito enARPANET News No. 14, es la evidencia más clara de imposición operativa en la conversión. NCP no fue simplemente desaprobado en un documento. La infraestructura de conmutación de paquetes rechazó el tráfico relevante. Los hosts solo NCP no pudieron usar ARPANET durante la prueba. Los sistemas de doble protocolo con estado de host remoto compartido también podían encontrar problemas a menos que los administradores deshabilitaran su implementación NCP durante el período.

El punto de aplicación importa. No fue SRI-NIC eliminando un nombre ni USC/ISI rechazando un número. Los IMP realizaron el rechazo bajo instrucciones de gestión de red, con el Centro de Operaciones de Red y la gestión vinculada a DCA responsables del entorno operativo. El estado devuelto fue diseñado para hacer visible la naturaleza administrativa del rechazo al host remitente.

News No. 16 recordó a los administradores la prueba del 1 de octubre y pidió a los participantes que informaran de las observaciones a Jon Postel, al NOC y al NIC. También presionó a los sitios para que implementaran SMTP y direccionamiento de internet de cuatro octetos para enero. Aquí, la coordinación combinó varias funciones: la red de conmutación creó la condición de prueba; los implementadores y administradores de hosts observaron fallos; ISI recibió informes técnicos; el NOC vigiló las operaciones; y el NIC distribuyó instrucciones y recopiló información de implementación.

Al experimento de cuatro horas le siguieron ensayos más largos.News No. 17anunció períodos solo TCP de 24 horas el 15 de noviembre y el 13-14 de diciembre. Se usaría el mismo método de rechazo a nivel IMP. El aviso advirtió explícitamente que también era el mecanismo previsto después del objetivo del 1 de enero.

Estas pruebas proporcionaron información que ninguna afirmación de tabla de hosts podía ofrecer. Un sitio podía informar que tenía TCP, pero descubrir durante un día sin NCP que un servicio de producción, un mailer, una ruta de terminal, un gateway o un procedimiento operativo local aún dependía de NCP. Un host podía pasar una prueba de laboratorio pero fallar bajo el tráfico y el comportamiento del usuario de un período operativo completo. Repetir el experimento aumentaba la probabilidad de que la dependencia se descubriera antes de que cambiara la política de red continua.

Las pruebas también crearon influencia. Un host controlado por el patrocinador que no se había convertido no podía simplemente seguir usando el protocolo antiguo durante toda la prueba. Sus usuarios experimentaban la consecuencia de la no conversión, y sus administradores recibían un estado específico de la red. Eso era materialmente diferente de la persuasión a través de un RFC.

Sin embargo, la influencia era limitada. Se aplicaba directamente al tráfico NCP enviado a través de los IMP de ARPANET. No alcanzaba a una red local independiente que operara NCP internamente, una red externa que no se hubiera unido a ARPA Internet, ni a cada dirección no perteneciente a la red 10 enumerada más tarde en RFC 842. Los socios de investigación financiados por DARPA podían enfrentar expectativas contractuales o fuertes incentivos de interoperabilidad, pero esas relaciones no eran idénticas al control de DCA sobre las operaciones de ARPANET.

La misma distinción limita las afirmaciones sobre el registro. Las pruebas demuestran que el operador podía deshabilitar un protocolo en la capa de conmutación. No demuestran que la migración diera al NIC nueva discreción sobre los nombres o a USC/ISI nueva discreción sobre las asignaciones de números. Esas funciones administrativas importaban para la interoperabilidad, pero el acto de imposición observado ocurrió en otro lugar.

Enero de 1983: las excepciones fueron públicas, pero solo en parte

La política operativa no consistía en un plazo sin vía para la demora.

Con fecha del 22 de diciembre de 1982,ARPANET News No. 19declaró que después de las 00:01, hora del Este, del 1 de enero, no se permitiría el uso de NCP sin una excepción específica de la Oficina de Gestión del Programa DDN. Dio a la solicitud de excepción un nombre—reclama—y especificó cómo presentar una.

Antes de enero, una solicitud podía enviarse por correo de red a las direcciones de DDN-PMO, con copias al NIC. Después del plazo, un administrador que no pudiera usar la red podía enviar la solicitud por correo postal de EE. UU. a la sede de DCA. Esa ruta fuera de línea era operativamente significativa: la política no asumía que alguien que buscara la restauración del acceso NCP aún tuviera acceso a la red en funcionamiento.

El solicitante debía proporcionar una justificación detallada, un cronograma de conversión, la fuente de la implementación TCP/IP prevista si se conocía, y una lista de hosts con los que se requería interoperabilidad. Se proporcionaron contactos designados de DDN-PMO para más información. Este era un proceso de solicitud documentado con una autoridad decisoria identificada y requisitos de información establecidos.

News No. 20, distribuido el 13 de enero, publicó luego una tabla de direcciones habilitadas para NCP y fechas de conversión programadas. Un recuento directo da 44 filas de direcciones o puertos. No eran 44 organizaciones independientes. Varias instituciones tenían múltiples direcciones de host físicas o lógicas; dos filas estaban etiquetadas como puertos de prueba; otra identificaba el gateway S1. Una fila tenía una fecha de migración desconocida. Las filas fechadas oscilaban entre el 16 de enero y el 1 de mayo, aunque a 25 se les asignó el 1 de febrero.

La antigua notación abreviada de la red 10 refuerza lo que representaba la tabla: entradas operativas de direcciones o puertos dentro del entorno ARPANET. No era una lista de entidades legales únicas, contratos, sitios o tomadores de decisiones humanos. Tampoco era un inventario completo de cada ordenador que usara NCP residual en algún lugar del DDN o DoD más amplio.

News No. 20 decía que se habían concedido exenciones a los sitios que enfrentaban una interrupción grave del servicio y enfatizaba que cada administrador de host debía solicitar la habilitación de NCP individualmente. También decía que los plazos eran firmes. La tabla, por tanto, conectaba una decisión administrativa con una condición de red concreta: habilitación continuada de NCP para una dirección especificada hasta una fecha especificada.

Esta es una evidencia más sólida que una ausencia inferida de gobernanza. Había un registro de excepciones público parcial. La comunidad podía ver qué direcciones listadas conservaban NCP y cuándo se esperaba que la mayoría hiciera la conversión. El aviso de solicitud revelaba al tomador de decisiones y el material que un solicitante debía presentar. La publicación de las filas también ayudaba a los usuarios de correo a determinar cuándo podría ser necesario un retransmisor.

El registro era incompleto en otros aspectos. No daba una razón junto a cada dirección. No reproducía las solicitudes, pruebas de respaldo, condiciones, denegaciones o el análisis detrás de los plazos individuales. Los avisos examinados no identifican un órgano de revisión independiente ni una apelación de una decisión de DDN-PMO. No revelan si casos similares fueron tratados de manera consistente o si todas las habilitaciones temporales aparecieron en la tabla.

La conclusión institucional precisa es, por lo tanto, limitada. La transición no carecía de un procedimiento de excepción ni de todos los informes de estado públicos. Tenía un tomador de decisiones operativo central, solicitudes individuales, habilitación temporal, filas de direcciones publicadas y fechas de vencimiento. Lo que le faltaba en el registro público era un archivo de decisión completo, un razonamiento por caso y una revisión independiente de la autoridad que administraba la política de red.

Esa combinación se adecuaba más a una red de defensa gestionada que a un sistema constitucional público. DDN-PMO estaba decidiendo cuánto tiempo un protocolo obsoleto podía permanecer activo en un entorno del cual tenía responsabilidad operativa. Los solicitantes eran administradores de hosts que buscaban un servicio continuo, no ciudadanos que afirmaran un derecho general a usar cualquier protocolo. La importancia posterior para la gobernanza surge porque el entorno técnico y sus registros compartidos se expandieron más allá de la población regida por esas relaciones originales.

Enero-febrero de 1983: los TAC y UDEL mantuvieron viva la unión

La migración no eliminó toda mediación el 1 de enero. La concentró en instalaciones específicas y temporales.

News No. 20 anunció que los Controladores de Acceso a Terminal de ARPANET continuarían dando soporte a NCP durante enero. Un usuario de terminal podía conectarse a través de un TAC e ingresar un comando adicional para llegar a un host NCP. El 1 de febrero, los TAC estaban programados para ser solo TCP/IP.

Esa continuación era importante porque el acceso por terminal era una ruta común hacia los hosts de servicio. El terminal del usuario no implementaba una pila de protocolos de host completa de la misma manera que un ordenador conectado. El TAC mediaba el acceso del terminal a los hosts. Mantener el soporte dual allí preservaba una ruta operativa para las personas cuyos destinos o sistemas de soporte no habían completado la conversión.

La Universidad de Delaware proporcionó otro puente real. UDEL acordó operar un retransmisor de reenvío de correo entre usuarios TCP y NCP. Un remitente TCP que se dirigía a un destino NCP usaba un formulario UDEL-RELAY que contenía la cuenta del destinatario y el nombre del host NCP. Un remitente NCP que se dirigía a un destinatario TCP usaba UDEL-TCP. El retransmisor también podía completar una transacción del mismo protocolo cuando el estado actual del destino era incierto.

Esto no era una traducción invisible. Los usuarios tenían que conocer el protocolo del remitente y construir la dirección en consecuencia. Un direccionamiento incorrecto podía causar que un mensaje fuera devuelto. El retransmisor requería software de correo funcional, un host accesible, contactos del personal, capacidad de cola y disco, y conocimiento actual del estado del protocolo de destino. Se suponía que la lista de exenciones publicada haría más fácil de gestionar esta última dependencia.

Estas acomodaciones revelan la textura real de la conversión. La aplicación y la asistencia no eran opuestas. El operador podía rechazar el tráfico NCP ordinario mientras preservaba direcciones NCP seleccionadas, extendía el soporte de TAC y organizaba un retransmisor de correo. La compatibilidad temporal reducía la interrupción sin renunciar al plazo.

El acuerdo también muestra por qué los registros precisos se volvieron más trascendentes operativamente. Una entrada de capacidad obsoleta podía dirigir el correo hacia el procedimiento equivocado. Un host mostrado incorrectamente como convertido podría ya no ser accesible a través de las rutas NCP ordinarias, mientras que un host convertido tratado como solo NCP podría atraer un uso innecesario de retransmisión. Las instrucciones de UDEL hacían decisivo el protocolo de origen; la tabla de excepciones ayudaba a identificar destinos residuales; el cronograma de TAC decía a los usuarios cuándo desaparecería una ruta de terminal.

Esa dependencia no convertía al NIC en la fuente de cada decisión. DDN-PMO concedía las excepciones NCP. Los operadores de red implementaban la habilitación en el entorno de conmutación. UDEL ejecutaba el retransmisor de correo. Los operadores de TAC proporcionaban compatibilidad de terminal. El NIC distribuía el boletín y la tabla. Cada institución controlaba un eslabón diferente.

Los retransmisores también imponen disciplina a las afirmaciones contrafactuales. Una conversión más lenta era tecnológicamente posible porque el servicio TAC de doble protocolo y el reenvío de UDEL existían en funcionamiento, no solo en papel. Pero mantenerlos requería personal, capacidad de host, instrucciones para los usuarios, controles de acceso, almacenamiento, conocimiento de direcciones, solución de problemas y pruebas continuas. Extender la coexistencia habría extendido esos costes.

No hay necesidad de inventar un incidente de seguridad para establecer la carga. Las cuentas intermedias, los archivos o mensajes almacenados y las máquinas de servicio adicionales requerían administración ocurriera o no una brecha. Las fuentes conservadas no establecen que un retransmisor de transición causara tal incidente. Sí establecen que la fiabilidad del retransmisor, la carga, el control de cuentas y el almacenamiento temporal eran preocupaciones operativas reconocidas.

Los registros entraron en la vía operativa sin convertirse en una sola autoridad

La conversión de protocolos, el registro de hosts, la aprobación de puertos, la asignación de números y la distribución de información estaban conectados, pero no eran un solo poder ejercido por una sola institución.

La capa de la tabla de hosts era anterior a la conversión de enero.RFC 810, emitido en marzo de 1982, reemplazó el antiguo formato de tabla orientado a ARPANET por uno diseñado para la interconexión de redes del DoD. El nuevo formato describía redes, gateways, hosts, direcciones de internet, sistemas operativos y capacidades de protocolo. Una fila podía distinguir TCP/Telnet de NCP/Telnet o registrar si SMTP estaba disponible.

La tabla se podía descargar comoHOSTS.TXTdesde SRI-NIC u obtenerse a través del Servidor de Nombres de Host. Las copias locales reducían la dependencia de una consulta en vivo para cada conexión, pero creaban un conocido problema de consistencia: una copia antigua podía conservar una dirección desaparecida o una afirmación de protocolo obsoleta. La conversión aumentó la frecuencia con la que tales diferencias importaban porque los usuarios y las aplicaciones necesitaban saber no solo un nombre y una dirección, sino qué entorno de comunicación soportaba un destino.

RFC 810 también impuso una regla formal dentro de su límite declarado. Los nombres y direcciones para redes, gateways y hosts del DoD debían negociarse y registrarse en el NIC antes de su uso y antes de que un host del DoD pasara su tráfico. Durante un período provisional, el NIC intentaría conservar información comparable para redes no DoD cuando los operadores la suministraran.

Ese texto establece un requisito de registro. No establece un caso documentado en el que el NIC rechazara un nombre en disputa, excluyera una red externa por lo demás funcional o adquiriera una nueva discreción política debido al plazo de TCP/IP. El requisito ya formaba parte de la especificación de la tabla de hosts de 1982. La conversión hizo que la precisión y el alcance del registro fueran más importantes; la evidencia no muestra que creara la regla.

RFC 811describió el Servidor de Nombres de Host del NIC como un servicio accesible por NCP y TCP operado en SRI en nombre de DCA. Los programas podían solicitar un registro por nombre, solicitarlo por dirección o recuperar toda la tabla. El protocolo definía las posibles respuestas para un nombre o dirección no encontrados, un comando ilegal o un fallo temporal del sistema.

Esos códigos de respuesta muestran para qué tenía que estar preparado el software consumidor. No muestran con qué frecuencia ocurrieron tales fallos ni identifican a un usuario que realmente perdiera el servicio debido a uno. Un registro faltante podía hacer que una búsqueda basada en nombre fallara mientras la comunicación numérica directa seguía siendo posible. Un fallo temporal del servidor podía mitigarse con una tabla local, aunque esa copia pudiera estar obsoleta. El RFC presentó la base de datos global única como un acuerdo provisional en el camino hacia un servicio distribuido de nombre a dirección.

Una barrera administrativa más directa apareció en los avisos operativos en torno a la planeada separación ARPANET/MILNET. News No. 18, con fecha del 17 de diciembre de 1982, decía que era necesario un registro preciso de hosts y puertos IMP para evitar denegar el servicio al usuario equivocado durante la división. Se instruyó a BBN para que deshabilitara los puertos no utilizados y los activara solo después de la aprobación de DDN-PMO. Los nuevos hosts y los cambios de puerto debían coordinarse con antelación.

News No. 21 revisó posteriormente el procedimiento. Las solicitudes de aprobación de nuevo host, activación de puerto o un cambio de host en un puerto activo se dirigían a un buzón en SRI-NIC. La información requerida incluía el nombre y la dirección del host, la ubicación, el hardware, el sistema operativo, el patrocinador, los protocolos y los detalles del enlace técnico.

Aquí, la precisión de los datos y la activación operativa estaban directamente unidas. Pero la razón declarada en News No. 18 era la división de la red y la gestión de puertos, no únicamente la conversión NCP/TCP. La autoridad decisoria era DDN-PMO; BBN controlaba el estado de los puertos bajo instrucción; el NIC recibía, mantenía y hacía circular la información. Tratar a los tres como "el registro" ocultaría dónde residía realmente el poder.

Los números asignados formaban otra capa separada.RFC 820, emitido en enero de 1983, registró los valores utilizados para números de red, números de protocolo, puertos, sockets y otros campos de implementación. Dirigía a los solicitantes a Jon Postel en USC/ISI y decía que las asignaciones se manejaban bajo un acuerdo entre la Oficina de Técnicas de Procesamiento de Información de DARPA y DDN-PMO.

Los números únicos eran necesarios para evitar implementaciones conflictivas y una interpretación ambigua de los paquetes. Esa necesidad creó dependencia de asignaciones coordinadas. El material conservado examinado aquí no muestra un rechazo relacionado con la migración, una apelación de una decisión de asignación o un cambio antes y después en la discreción formal de Postel. RFC 820 documenta una función de coordinación y su entorno institucional; no puede por sí mismo probar que el evento de enero ampliara la autoridad de esa función.

La distinción entre estos mecanismos es el centro causal de la historia:

• El rechazo por los IMP hizo que NCP fuera inutilizable en la red gestionada, excepto donde estaba habilitado.
• DDN-PMO decidió las excepciones temporales de NCP y aprobó la activación de hosts o puertos.
• Las organizaciones de hosts implementaron y operaron su propio software de protocolo.
• SRI-NIC registró y distribuyó nombres, direcciones, capacidades, contactos y avisos.
• USC/ISI coordinó los números de protocolo y red asignados.
• Los operadores de gateway y retransmisión determinaron si el tráfico podía cruzar límites técnicos particulares.
• Los operadores externos adoptaron TCP/IP bajo acuerdos de financiación, cooperación en investigación, reglas de adquisición o incentivos de interoperabilidad que no eran todos órdenes de DCA.

La migración aumentó la dependencia a lo largo de esta cadena. No fusionó la cadena en una sola oficina.

1972–1985: el límite institucional se movió bajo la red

Incluso la cronología básica advierte contra la descripción de una autoridad central continua.

Lacronología oficial de DARPAfecha el cambio de nombre de ARPA a Agencia de Proyectos de Investigación Avanzada de Defensa en 1972, no en 1973. DARPA siguió siendo el patrocinador de investigación detrás del trabajo clave de protocolo e implementación, con una influencia sustancial sobre sus contratistas y socios financiados.

La fecha en que DCA asumió la responsabilidad operativa de ARPANET es menos clara. Laguía de los registros de SRI ARC/NIC de 2011dice que la operación se entregó a DCA en 1973. Una publicación contemporánea de DCA da una fecha formal posterior: elfolleto informativo de ARPANET de 1978de la agencia dice que la responsabilidad de gestión se transfirió el 1 de julio de 1975.

Sin los registros de transferencia por fases subyacentes, esas declaraciones no deben forzarse a una falsa certeza. La guía de búsqueda posterior puede estar describiendo una entrega operativa anterior, mientras que el propio folleto de DCA identifica la transferencia formal de la responsabilidad de gestión. Para la fecha formal, el relato contemporáneo de DCA es más sólido. Para 1982, los propios avisos en vivo no dejan ambigüedad sobre la jerarquía operativa: eran distribuidos por el NIC para la Oficina de Gestión del Programa DDN de DCA, y las instrucciones de gestión de red provenían de esa estructura.

Para enero de 1983, debían mantenerse separadas al menos cinco poblaciones.

La población de la red 10 de ARPANET era el sujeto directo del plan NCP/TCP de RFC 801 y de las pruebas solo TCP a nivel IMP. El control operativo de DCA y las decisiones de excepción de DDN-PMO tenían allí su fuerza más clara.

MILNET y otros suscriptores de DDN pertenecían a un entorno de defensa más amplio que todavía se estaba ensamblando y diferenciando. Sus obligaciones de protocolo no eran reducibles a cada línea del plan de ARPANET. El informe del Consejo Nacional de Investigación de 1985 reproducido comoRFC 942decía que la red troncal MILNET no requería TCP en sí misma, aunque generalmente se requería que los suscriptores lo usaran.

Otras redes del DoD siguieron diferentes caminos técnicos y de adquisición. RFC 942 describía redes que ya usaban TCP, redes que planeaban conversiones posteriores y sistemas que usaban otros protocolos. Por lo tanto, "DoD Internet" no era una sola población que completó un evento universal en enero.

Los socios de investigación externos financiados por DARPA podían enfrentar expectativas del patrocinador y estar profundamente integrados en el trabajo de internet experimental. UCL, los participantes de la red satelital, los investigadores de radio por paquetes y los contratistas pertenecían a acuerdos de colaboración con un control operativo variable. Su presencia en documentos de protocolo o tablas de hosts no convertía a cada máquina en suscriptora de DCA.

Los adoptantes independientes y externos posteriores tenían una exposición aún más débil a las órdenes de DCA. Podían elegir TCP/IP porque las implementaciones estaban disponibles, porque corresponsales valiosos lo usaban o porque los protocolos incompatibles imponían costes de oportunidad crecientes. Esa presión de efecto de red podía ser poderosa sin crear jurisdicción de DCA sobre sus sistemas internos.

RFC 942 es particularmente útil porque preserva estas distinciones al tiempo que registra las consecuencias operativas de la conversión. El trabajo del Consejo Nacional de Investigación fue apoyado a través de un contrato de DCA y publicado en 1985, por lo que es una evaluación retrospectiva moldeada en parte por un debate sobre estándares de defensa en lugar de un censo neutral de enero.

El informe decía que aproximadamente 30 hosts solo TCP se habían unido a la población de doble protocolo existente durante los seis meses anteriores a la migración. Atribuyó a las pruebas exhaustivas la preservación de la capacidad operativa y dijo que los niveles normales de servicio se alcanzaron en unos pocos meses. También registró que el NIC no había estado listo para soportar los nuevos protocolos, lo que causó problemas de distribución de la tabla de hosts, y que los hosts de servicio requirieron un análisis de rendimiento y ajuste de parámetros sustancial porque no habían soportado previamente una carga completa de usuarios durante un período prolongado.

Esas son consecuencias documentadas de la dependencia concentrada. La distribución de la tabla era una dependencia operativa, no meramente un simbolismo administrativo. El software de servicio que funcionaba en pruebas limitadas aún podía fallar bajo una demanda sostenida. Un plazo capaz de alinear la implementación también concentraba la carga en servicios comunes.

El mismo informe complica un relato triunfal. Decía que ARPANET generalmente usaba TCP mientras que algunos usuarios seguían usando NCP. Esa declaración, dos años después del objetivo, no identifica los hosts o rutas implicados. Sí refuta cualquier afirmación literal de que todo uso residual desapareció universalmente a medianoche. La conversión de política, el servicio de red normal, el software de host, el uso local y la accesibilidad temporal o excepcional eran estados diferentes.

Adopción externa: donde terminó el mando y comenzó la compatibilidad

El éxito más amplio de TCP/IP dependió de extenderse más allá de la población que DCA podía gestionar.

RFC 801 describió una ARPA Internet que conectaba ARPANET con redes de radio por paquetes, satélite, locales y otras. RFC 842 y RFC 843 incluían direcciones fuera de la red 10. RFC 844 demostró que una ruta de prueba no Clase A podía alcanzar muchas entradas con éxito. Estas fuentes muestran un entorno de interconexión que cruzaba límites técnicos e institucionales a principios de 1983.

No establecen un régimen legal o administrativo único en ese entorno.

Para un host de la red 10, el rechazo de NCP por un IMP era un hecho operativo inmediato. Para una red gestionada por separado, los factores decisivos podían ser el acceso a una implementación de TCP, una relación de gateway, un contrato de investigación, el deseo de alcanzar los servicios de ARPANET o el creciente número de corresponsales compatibles. Una red podía usar TCP/IP interna y externamente sin aceptar la autoridad de DDN-PMO sobre cada host o puerto local.

Esta diferencia explica cómo los registros compartidos podían volverse más trascendentes que la jurisdicción del patrocinador original. Una red operada de forma independiente necesitaba direccionamiento único y valores de protocolo cuando se comunicaba con la internet más amplia. Sus usuarios se beneficiaban de una información de nombres precisa y gateways accesibles. La dependencia de una coordinación común podía extenderse más allá de la autoridad contractual que originalmente había apoyado el servicio de coordinación.

Sin embargo, la dependencia por sí sola no prueba un derecho a gobernar. Un guardián de registros puede volverse importante porque los participantes necesitan información compatible, pero carece de autoridad sobre su financiación, sistemas internos o procedimientos de decisión. Un patrocinador puede poseer autoridad directa sobre su propia red, pero solo influir en los adoptantes externos a través de incentivos de interoperabilidad. La expansión de TCP/IP, por tanto, amplió el dominio de la coordinación sin hacer que ese dominio fuera constitucionalmente uniforme.

Es por esto también que no se puede atribuir a la migración la creación de todo el poder de registro posterior. Las tablas de hosts centrales, la coordinación de números asignados y las reglas de registro del DoD ya existían. Lo que cambió fue la exposición operativa de un entorno de compatibilidad más amplio a errores, datos de capacidad obsoletos, conflictos de números, fallos de gateway y debilidades de distribución. Una mayor trascendencia no es idéntica a una discreción recién creada.

Una conversión más lenta era posible, pero no era gratuita

Los acuerdos reales de TAC y UDEL permiten modelar una alternativa históricamente plausible sin importar tecnologías posteriores a 1983.

Supongamos que DCA hubiera retenido NCP como un servicio ordinario de ARPANET más allá de enero y hubiera permitido a las organizaciones de hosts convertirse voluntariamente. Los TAC de doble protocolo podrían haber permanecido disponibles. UDEL u otros hosts adicionales podrían haber continuado el reenvío de correo. Las cuentas de retransmisión de Telnet y FTP podrían haber servido de puente entre los usuarios y los hosts de servicio incompatibles. Los sitios podrían haber descargado copias fechadas deHOSTS.TXTy utilizado los campos de capacidad de protocolo para seleccionar rutas directas o retransmitidas.

Esto habría reducido la presión inmediata sobre los sistemas difíciles. Un host que dependía de un puerto de proveedor inacabado podría haber esperado. Los administradores podrían haber programado la conversión en función del personal local y el mantenimiento. Los hosts de servicio podrían haber sido sometidos a pruebas de carga más largas antes de que llegaran todos los usuarios. El NIC podría haber mejorado la distribución basada en TCP mientras los sitios conservaban la ruta anterior.

El precio habría sido un servicio de transición permanente.

Los TAC de doble protocolo necesitaban soporte de software y pruebas continuas. Los retransmisores necesitaban cuentas, almacenamiento, operadores, documentación y capacidad. Una transferencia de archivos en dos etapas consumía espacio en disco y requería mantenimiento. El reenvío de correo necesitaba colas, manejo de direcciones consciente del protocolo, información actual del destino y personal capaz de rastrear fallos en dos entornos. Los usuarios de terminal tenían que entender comandos adicionales y distinguir el acceso directo del mediado.

La resolución de problemas se volvería menos local. Una sesión fallida podía implicar a cualquiera de los puntos finales, cualquiera de las pilas de protocolo, una cuenta de retransmisión, un gateway, una copia obsoleta de la tabla de hosts o un campo de capacidad incorrecto. El personal de soporte necesitaría conservar experiencia en ambos entornos de protocolo. Las pruebas tendrían que continuar porque una ruta NCP podía seguir siendo funcional mientras el servicio TCP correspondiente se deterioraba silenciosamente, o viceversa.

El patrocinador también continuaría pagando por la no convergencia. Las organizaciones de hosts capaces de usar un retransmisor podían posponer el difícil trabajo de conversión porque parte del coste se había trasladado al operador del retransmisor. Cuanto más útil se volviera el servicio de compatibilidad, más fácil sería para las islas heredadas sobrevivir. Los efectos de red podrían eventualmente hacer que NCP fuera poco atractivo, pero el calendario sería incierto y la unión operativa podría persistir durante años.

Una transición voluntaria no habría sido necesariamente más descentralizada. Habría reducido el dramatismo de una fecha impuesta por el operador, al tiempo que aumentaba la dependencia de los administradores de retransmisores, TAC, registros de capacidad y hosts de servicio de doble protocolo. La autoridad se volvería menos visible en lugar de desaparecer.

Tampoco se puede rechazar la alternativa afirmando que habría producido un fallo de seguridad. Las fuentes no documentan tal incidente. Apoyan una observación más modesta: cada cuenta adicional, host intermedio, mensaje almacenado, copia de archivo e implementación heredada requería control de acceso y cuidado operativo. La magnitud del riesgo resultante no se mide.

La conversión real eligió una asignación diferente de costes. La mediación temporal permaneció disponible, pero sus fechas de vencimiento forzaron a las organizaciones de hosts a absorber el trabajo de implementación. DCA y DDN-PMO utilizaron el control del servicio de red para hacer creíble esa asignación. Las redes externas, fuera de ese control, continuaron adoptando TCP/IP según sus propios calendarios.

Cómo podría haber sido una coordinación más responsable en 1983

Una conversión más legible no requería sistemas de autenticación modernos, replicación global automatizada ni suposiciones sobre abundantes recursos informáticos.

El período ya tenía los bloques de construcción necesarios para una mejora modesta: avisos por correo, contactos operativos designados, encuestas de estado de hosts, copias locales deHOSTS.TXT, un proceso de solicitud, una tabla de excepciones publicada, días de prueba programados, soporte telefónico, retransmisores y comparación manual de registros.

News No. 19 podría haberse ampliado a un formato de decisión público completo para casos no sensibles. Cada fila de excepción podría haber llevado una breve categoría de razón, la fecha de solicitud, la fecha de decisión, la oficina aprobatoria, las condiciones adjuntas a la habilitación de NCP y si se había cumplido la fecha de conversión indicada. Los detalles sensibles podrían permanecer retenidos sin eliminar la existencia y el estado de la decisión.

Una solicitud de reconsideración podría haberse dirigido a un patrocinador u oficial de operaciones que no hubiera tomado la determinación inicial. Tal procedimiento no habría eliminado el control de DDN-PMO sobre la red. Habría separado la administración de primera línea de la revisión y habría creado un registro de si problemas operativos similares recibían un tratamiento similar.

Las publicaciones de estado también podrían haber separado las poblaciones. Una tabla de cumplimiento de la red 10, una tabla de suscriptores de DDN y una lista informativa de entradas de internet externas habrían evitado que una tabla de hosts mixta se confundiera con una comunidad gobernada. Los resultados podrían distinguir la capacidad registrada, una conexión de aplicación aceptada, una prueba enrutada exitosa desde otra clase de dirección, una excepción NCP aprobada, la indisponibilidad temporal y un resultado inexplicado.

La resiliencia de la distribución era posible de forma limitada. Más de un host de solo lectura podría haber servido copias fechadas de la tabla de hosts. Los operadores podrían comparar las fechas de versión y realizar comprobaciones manuales de consistencia con la copia del NIC. Esto reduciría la dependencia de una sola máquina de distribución durante una interrupción. No descentralizaría la autoridad de actualización: si cada espejo reproducía el mismo registro maestro erróneo, el error seguiría siendo autorizado.

Tales medidas habrían costado tiempo del personal, almacenamiento, coordinación telefónica y trabajo de conciliación adicional. Los registros podrían discrepar. La publicación podría retrasarse con respecto a los cambios operativos urgentes. Parte de la información de defensa no podría ser divulgada. Una segunda revisión podría retrasar una decisión necesaria rápidamente para restaurar o proteger el servicio.

Esos costes son precisamente la razón por la que la rendición de cuentas no puede tratarse como una adición gratuita a la coordinación técnica. La comparación relevante es entre el coste de mantener registros más claros y el coste impuesto cuando los operadores no pueden determinar si un fallo es técnico, administrativo, temporal o intencionado.

El registro de la conversión sugiere que esta distinción habría sido útil. RFC 842 podía mostrar que una dirección no aceptaba un servicio pero no por qué. News No. 20 podía mostrar que una dirección conservaba NCP pero no la razón completa. El NIC podía publicar una afirmación de protocolo pero no garantizar la operación observada. DDN-PMO podía aprobar un puerto, pero la aprobación no podía reparar una implementación defectuosa. Un mejor registro no colapsaría esos estados; los mantendría separados.

La autoridad que cambió estaba limitada por la red

La conversión de enero tuvo éxito en su principal propósito operativo. TCP/IP se convirtió en el entorno de comunicaciones normal de ARPANET, los principales servicios se trasladaron a él y las redes heterogéneas pudieron participar a través de una capa de interconexión común. Los estudios de febrero muestran cientos de puntos finales de servicio que aceptaban, aunque también muestran un funcionamiento incompleto y dependiente de la ruta.

La fuerza de la conversión provino de una estructura institucional específica. DARPA financió la investigación e influyó en los contratistas. DCA gestionó ARPANET formalmente a mediados de los años 70. DDN-PMO estableció la política operativa, decidió las excepciones NCP y aprobó hosts o puertos. Los IMP y los operadores de red impusieron la deshabilitación del protocolo. Las organizaciones de hosts controlaron la implementación en sus ordenadores. SRI-NIC registró y distribuyó información operativa. USC/ISI coordinó los números asignados. Los operadores de TAC y retransmisión preservaron la accesibilidad temporal.

Esta división impide la versión más fuerte de la afirmación de centralización. La evidencia no muestra que la propia migración diera a SRI-NIC un nuevo poder para decidir quién merecía un nombre, o a USC/ISI un nuevo poder para excluir redes externas mediante la asignación de números. Muestra que los nombres, direcciones, capacidades de protocolo, valores numéricos y servicios de distribución precisos se volvieron más importantes operativamente a medida que más comunicaciones convergían en TCP/IP.

La influencia ejercida residía en otro lugar. El rechazo de NCP a nivel IMP hizo concreta la autoridad del patrocinador y del operador. La habilitación individual y las fechas de vencimiento hicieron que la discreción de DDN-PMO fuera trascendente para las direcciones de la red 10 afectadas. La aprobación de hosts y puertos vinculó los datos administrativos con la activación de la red durante la separación ARPANET/MILNET. Los problemas posteriores de distribución de la tabla de hosts del NIC demostraron la dependencia de un servicio de información compartido, no una negativa política. La coordinación de números asignados preservó la unicidad, pero el registro examinado no proporciona ninguna denegación o apelación relacionada con la migración.

Más allá de la población gestionada, los incentivos de compatibilidad reemplazaron el mando directo. Los operadores externos adoptaron TCP/IP porque interoperar con una comunidad creciente era útil, porque los patrocinadores o los programas de adquisición lo apoyaban, o porque las implementaciones estaban disponibles. Su dependencia técnica de identificadores compartidos no convirtió sus redes en propiedad de DCA, DARPA, SRI o ISI.

El logro institucional y el problema de legitimidad son, por lo tanto, diferentes. El logro fue la interoperabilidad coordinada entre sistemas heterogéneos. El problema de legitimidad fue que la creciente dependencia operativa podía superar los registros de decisión, los procedimientos de revisión y los acuerdos de continuidad de las instituciones creadas para un entorno más pequeño controlado por el patrocinador.

El 1 de enero importó porque puso fin a la coexistencia indefinida como política predeterminada de ARPANET. Los experimentos de octubre, noviembre y diciembre demostraron cómo se aplicaría esa política. El registro de excepciones de enero mostró que la aplicación era selectiva y temporal en lugar de absoluta. Los TAC y UDEL preservaron uniones esenciales. Los estudios de febrero mostraron que la conversión formal, la capacidad registrada, la respuesta de la aplicación y la accesibilidad enrutada seguían siendo hechos diferentes.

La migración cambió la autoridad al hacer que algunos poderes existentes fueran operativamente decisivos: el poder de deshabilitar un protocolo, aprobar la continuación temporal, activar un puerto, distribuir un registro compartido o mantener un retransmisor. También aumentó la dependencia de la coordinación más allá del alcance de esos poderes. Eso es más preciso que decir que una sola autoridad cambió Internet, y más trascendente que la leyenda de una medianoche perfecta.