Lo que la transición de ARPANET enseña sobre IPv6

La ARPANET (Advanced Research Projects Agency Network) fue una de las primeras redes de computadoras en utilizar conmutación de paquetes y es considerada una de las principales precursoras de Internet. Creada por la ARPA, en Estados Unidos, la red inicialmente conectaba universidades y centros de investigación y, con el paso de los años, pasó a interconectar cientos de computadoras. Fue en este contexto que se consolidó la necesidad de sustituir el NCP (Network Control Program), utilizado para la comunicación entre los hosts de ARPANET, por el conjunto de protocolos TCP/IP (Transmission Control Protocol/Internet Protocol), desarrollado para permitir la interconexión entre redes diferentes. Esta transición se convertiría en uno de los hitos de la formación de la Internet moderna.

En 1981, ARPANET se encontraba ante un cambio que puede resultar familiar para quienes trabajan con redes: sería necesario sustituir el protocolo que sustentaba la comunicación entre sus hosts por una nueva arquitectura de interconexión. El NCP utilizado hasta ese momento daría paso a TCP/IP. La diferencia es que, en aquella época, alguien tuvo la idea, que quizás hoy podría parecer incluso audaz o polémica, de fijar una fecha para que esto ocurriera.

En octubre de 1981, Jon Postel publicó en el TCP/IP Digest un mensaje que presentaba el plazo de manera directa, como se muestra en la Figura 1.

Figura 1 –The deadline is: 1 January 1983.  Fuente: Jon Postel, NCP-to-TCP Transition, TCP/IP Digest, Vol. 1, Issue 2, 14 oct. 1981. Reproducción disponible en el archivo histórico LivingInternet. [1]

Publicada en noviembre de 1981, la RFC 801 [2] formalizó el plan de transición. No se trataba simplemente de recomendar que los administradores comenzaran a implementar TCP/IP. Cada organización debía preparar sus propios hosts; había etapas intermedias previstas para 1982, mecanismos para permitir la coexistencia entre NCP y TCP/IP y, al final del proceso, el NCP sería retirado.

Estos mecanismos incluían hosts con soporte para ambos protocolos y servicios de Telnet, FTP y correo electrónico entre sistemas NCP-only y TCP-only.

De acuerdo con la planificación, en enero de 1983 todos los hosts debían estar preparados para TCP/IP, el NCP sería retirado de servicio y los mecanismos temporales dejarían de ser necesarios.

Es interesante observar esto hoy porque estamos acostumbrados a hablar de IPv6 desde hace muchos años, casi siempre utilizando la palabra transición. En 1983 también hubo una transición, pero existía una diferencia fundamental: fue planificada como una migración con un inicio, etapas de preparación y un plazo para finalizar.

Una migración necesita una fecha

El primer aprendizaje quizás sea precisamente ese: una migración necesita una fecha que represente el momento en que lo nuevo pasa a ser el estándar y lo antiguo deja de ser la opción principal.

Esto no significa que todos los equipos deban modificarse al mismo tiempo. En el caso de ARPANET, hubo desarrollo, implementación, pruebas y períodos de operación en paralelo. A lo largo de 1982, la comunidad realizó pruebas en las que el NCP era interrumpido temporalmente, incluidos ensayos más prolongados en los que los paquetes NCP eran rechazados. Era una forma de detectar los problemas con anticipación y, al mismo tiempo, mostrar a los administradores que la desconexión prevista para enero no sería simplemente una recomendación.

Cuando llegó diciembre, la sensación de que la fecha estaba próxima aparece claramente en los registros históricos. El 30 de diciembre, Nancy Mimno envió un aviso, como se muestra en la Figura 2, a los contactos institucionales de CSNET, explicando que la transición se había estado planificando durante varios años y que el cambio a TCP/IP tendría lugar el 1.º de enero. Según el mensaje, el cambio afectaría a más de 250 hosts de ARPANET, y algunos de ellos podrían no estar preparados en la fecha establecida.

Figura 2 – Mensaje enviado por Nancy Mimno, el 30 de diciembre de 1982, comunicando la transición de ARPANET a TCP/IP el 1.º de enero de 1983. Fuente: MIMNO (1982), mensaje electrónico preservado en la colección histórica de Anne y Lynn Wheeler. [3]

Al día siguiente, 31 de diciembre, mientras millones de personas probablemente estaban pensando en festejar la llegada del nuevo año, la preocupación de algunos administradores era otra. A las 23:11, Ken Wertz, de Carnegie Mellon, envió un mensaje titulado “TCP reminder”, como se muestra en la Figura 3, recordando que ARPANET comenzaría a utilizar exclusivamente TCP/IP a las 00:01 del día siguiente y recomendando que los administradores verificaran la información sobre las configuraciones de los sistemas de la universidad.

Figura 3 – Mensaje enviado por Ken Wertz, a las 23:11 del 31 de diciembre de 1982, recordando que ARPANET pasaría a utilizar exclusivamente IP/TCP a las 00:01 del 1.º de enero de 1983. Fuente: CMU CS General Bboard archive. [4]

Por lo tanto, la fecha existía porque era necesario transformar una intención en un compromiso colectivo. Y quizás esa sea una de las cosas que perdemos cuando una transición se prolonga indefinidamente: la percepción de que, en algún momento, necesita terminar.

Responsabilidad

Una fecha, por sí sola, no hace que una migración ocurra. El segundo aspecto que llama la atención al leer los documentos de aquella época es la claridad respecto de quién debía hacer qué. La RFC 801 asignaba a cada organización la responsabilidad de implementar TCP/IP en sus propios hosts.

Esta característica distingue a ARPANET de la Internet actual. ARPANET contaba con una estructura administrativa delimitada y estaba bajo la coordinación de ARPA y de la DCA. En la Internet global, ninguna organización tiene autoridad para determinar una fecha única para el apagado de IPv4.

En el relato reproducido en la Figura 4, Andrew G. Malis afirmó que participó en la implementación del código que permitía bloquear paquetes NCP y que la aplicación de este mecanismo se realizaba host por host, considerando incluso una lista oficial de máquinas autorizadas a continuar utilizando NCP. Pasó el primer día de 1983 deshabilitando el acceso mediante NCP de los hosts que no contaban con autorización y atendiendo las llamadas de administradores, cuyos sistemas habían quedado sin comunicación.

Figura 4 – Relato de Andrew G. Malis sobre la operación de la transición NCP/TCP el 1.º de enero de 1983. Malis describe la aplicación de los filtros y su actuación durante el apagado. Fuente: Internet-history mailing list, 5 dic. 2020. [5]

Dan Lynch, en una entrevista con el Computer History Museum [6], también recordó ese momento como el gran cut-over, con muchos profesionales trabajando en torno al cambio para garantizar que la transiciónocurriera. Quizás sea justamente eso lo que convierte una decisión técnica en una verdadera migración. Había profesionales que no solo creían en la necesidad del cambio, sino que también asumían la responsabilidad de llevarlo a cabo.

Cuando miramos el caso de IPv6, esta cuestión se mantiene igual. Es relativamente fácil decir que una organización está implementando IPv6. Pero lo difícil es identificar quién es responsable de lograr que una determinada red, servicio o aplicación deje de depender de IPv4. Sin una asignación clara de responsabilidades, la transición tiende a permanecer como una intención colectiva, sin un liderazgo definido que la conduzca hacia su finalización.

Excepciones sin abandonar el objetivo principal

Hay otro detalle de la historia que considero especialmente importante. No todos estaban preparados. Los documentos dejan claro que había hosts que aún no habían completado la migración y que se esperaba que surgieran algunos problemas. Por eso se previeron excepciones y mecanismos de transición. La propia documentación posterior registra que algunos hosts recibieron autorización temporal para continuar utilizando NCP después del apagado.

Por lo tanto, el 1.º de enero de 1983 debe entenderse como el inicio efectivo de la operación TCP/IP-only como regla, y no como el momento en que todo uso de NCP desapareció sin excepciones.

Esto demuestra que una migración planificada no significa exigir perfección antes de avanzar. Significa reconocer que habrá situaciones que no estarán preparadas y crear mecanismos para abordarlas sin abandonar el objetivo principal. Esta distinción es importante. Una excepción puede ser necesaria. El problema surge cuando la excepción deja de tener un plazo y pasa a considerarse parte permanente de la arquitectura.

Es algo que conocemos muy bien en el mundo de IPv6. Existe un equipo heredado que todavía necesita IPv4. Existe una aplicación antigua que no funciona con IPv6. Existe un sistema operativo que no puede actualizarse. Existe un dispositivo de IoT cuyo fabricante aún no ha implementado IPv6. Cada caso puede ser legítimo y, en muchos entornos, mantener IPv4 temporalmente es simplemente la decisión operativa correcta. Sin embargo, debemos tener cuidado que la existencia de estos casos no se convierta en una justificación para mantener IPv4 en todas partes.

Quizás la pregunta no debería ser cuándo estarán todos preparados para IPv6, porque probablemente nunca tendremos una respuesta para eso. Una pregunta mejor sería: ¿qué sistemas realmente todavía necesitan IPv4 y en qué puntos de la infraestructura es necesario que permanezca?

A partir de ahí, las excepciones pueden ser tratadas individualmente, en lugar de servir como justificación para mantener toda la infraestructura atada al pasado. Fue precisamente esa capacidad la que demostró la comunidad de ARPANET. Había excepciones, pero no impidieron la migración.

La decisión de abandonar el NCP

Llegamos, quizás, a la parte más difícil: tener la disposición para dejar atrás protocolos que pasaron a formar parte del legado de la red.

En ese sentido, mecanismos como NAT64, DNS64, 464XLAT y SIIT-DC pueden cumplir un papel similar al de los servicios intermediarios de aquella transición: permitir el acceso a recursos heredados sin obligar a que el protocolo anterior permanezca de forma nativa en toda la infraestructura.

La transición de ARPANET no terminó simplemente porque la mayoría de los hosts ya utilizaba TCP/IP. El plan establecía que el NCP dejaría de utilizarse y que, en el momento establecido para la migración, se comenzaría a rechazar el tráfico NCP proveniente de los hosts que no contaran con una excepción autorizada.

Esto exigía tomar una decisión que muchas veces resulta difícil en entornos de producción: aceptar que, a partir de determinado momento, el protocolo que había sustentado la red durante años dejaría de admitirse como forma normal de acceso.

Vint Cerf recordó posteriormente que la comunidad ya había realizado interrupciones temporales del NCP durante las pruebas, precisamente para demostrar que la migración se tomaría en serio. Cuando llegó enero de 1983, el acceso mediante el protocolo anterior se cerró efectivamente, con pocas excepciones.

Dan Lynch también se hizo conocido por los buttons con la frase “I survived the TCP transition”, Figura 5, de los cuales produjo 500 unidades con recursos propios para conmemorar la ocasión. Pero lo que realmente había sucedido era mucho más importante. La comunidad había demostrado una capacidad colectiva para decidir que una transición debía terminar.

Figura 5 – Button “I Survived the TCP Transition 1/1/83”, producido por Dan Lynch como recuerdo de la transición de ARPANET a TCP/IP. Fuente: Computer History Museum, entrevista con Dan Lynch.

¿Y qué podemos aprender de esto?

Hoy hablamos de la transición a IPv6 desde hace décadas. Existe una diferencia importante entre la manera en que conducimos actualmente la adopción de IPv6 y la forma en que la comunidad de ARPANET afrontó la transición a TCP/IP.

En aquella época, el objetivo no era mantener ambos protocolos de forma indefinida. NCP y TCP/IP tuvieron que coexistir durante un período porque esa coexistencia era necesaria para llevar adelante la migración. Esto no significa que toda coexistencia prolongada entre protocolos sea necesariamente inadecuada. La diferencia está en determinar si responde a una necesidad técnica medible o si simplemente se mantiene por falta de planificación para reducir su uso.

Hoy, muchas veces, convertimos la propia coexistencia en un estado permanente. No creo que la lección sea simplemente fijar una fecha para apagar IPv4 en toda Internet, aunque en ocasiones se han propuesto, incluso de forma provocadora, interrupciones controladas para medir el grado actual de dependencia de IPv4, como ocurrió durante las pruebas realizadas antes de 1983.

ARPANET contaba con unos pocos cientos de hosts y una coordinación administrativa capaz de establecer y hacer cumplir el plazo. La Internet actual reúne innumerables sistemas autónomos, operadores, fabricantes, aplicaciones y usuarios, sin una autoridad central que pueda determinar el apagado global de IPv4. Puede que la pregunta «¿cuándo vamos a apagar IPv4?» genere resistencia incluso antes de comenzar.

Quizás la pregunta más útil sea otra: ¿Cuál es el próximo entorno en el que podemos establecer una fecha para dejar de depender de Ipv4?

Puede ser una nueva red Wi-Fi, una nueva VLAN, un nuevo centro de datos, una infraestructura de IoT o una aplicación que ya pueda implementarse como IPv6-only o IPv6-mostly, recurriendo a mecanismos de traducción únicamente para acceder a los recursos que todavía dependen de IPv4.

Para cada entorno, la meta podría ser monitoreada mediante indicadores simples: cantidad de aplicaciones que todavía requieren IPv4, volumen de tráfico IPv4 remanente, existencia de responsables de las excepciones, plazo de revisión y porcentaje de servicios capaces de operar exclusivamente sobre IPv6.

Por último, esta es la historia que creo que vale la pena contar, incluso en el aula. No solo por nostalgia o por interés en la historia de Internet, ni como un intento de afirmar que la Internet actual podría administrarse como ARPANET en 1983, sino porque esta experiencia plantea una pregunta incómoda que sigue siendo vigente.

Queda, sin embargo, una pregunta: si una comunidad entera logró establecer una fecha para dejar atrás el NCP, ¿qué nos impide todavía definir metas y plazos para reducir, de forma planificada, la dependencia de IPv4 en los entornos que administramos?

Referencias

[1] LIVINGINTERNET. TCP/IP Internet Protocol. [S. l.], [s. d.]. Disponible en: https://www.livinginternet.com/i/ii_tcpip.htm. Acceso: 8 set. 2026.

[2] POSTEL, Jon. RFC 801: NCP/TCP Transition Plan. [S. l.]: Internet Engineering Task Force, nov. 1981. Disponible en: https://www.rfc-editor.org/info/rfc801. Acceso: 8 set. 2026.

[3] MIMNO, Nancy. Notice of TCP/IP Transition on ARPANET. Mensaje electrónico enviado a la lista CSNET-LIAISONS el 30 dic. 1982. Reproducción preservada en la colección histórica de Anne y Lynn Wheeler. Disponible en: https://web.archive.org/web/20230928072135/https://www.garlic.com/~lynn/2000e.html#18. Acceso: 8 set. 2026.

[4] WERTZ, Ken. TCP reminder. Mensaje publicado en el CMU CS General Bboard el 31 dic. 1982. En: BAIRD, Jeff. CMU CS General Bboard Contents from 25-Nov-82 to 31-Dec-82. [S. l.], 15 jul. 2002. Disponible en: https://self-issued.info/Smiley/Nov-Dec-82_BBoard_Contents.html. Acceso: 8 set. 2026.

[5] MALIS, Andrew G. Relato sobre la transición NCP/TCP en ARPANET. Mensaje electrónico del 5 dic. 2020, reproducido en una discusión de la lista Internet-history. En: AUERBACH, Karl. Fwd: Question – reference source for formal decommissioning of ARPANET in 1990? Internet History Society, 6 dic. 2020. Disponible en: https://elists.isoc.org/pipermail/internet-history/2020-December/006780.html. Acceso: 8 set. 2026.

[6] LYNCH, Dan. Interview of Dan Lynch. Entrevista concedida a James Pelkey em 16 feb. 1988, Cupertino, California. Mountain View: Computer History Museum, 2016. Disponible en: https://archive.computerhistory.org/resources/access/text/2016/02/102717120-05-01-acc.pdf. Acceso: 8 set. 2026.