O que a transição da ARPANET ensina sobre IPv6

A ARPANET (Advanced Research Projects Agency Network) foi uma das primeiras redes de computadores a utilizar comutação de pacotes e é considerada uma das principais precursoras da Internet. Criada pela ARPA, nos Estados Unidos, a rede inicialmente conectava universidades e centros de pesquisa e, ao longo dos anos, passou a interligar centenas de computadores. Foi nesse ambiente que se consolidou a necessidade de substituir o NCP (Network Control Program), utilizado na comunicação entre hosts da ARPANET, pelo conjunto de protocolos TCP/IP (Transmission Control Protocol/Internet Protocol), desenvolvido para permitir a interconexão entre redes distintas. Essa transição se tornaria um dos marcos da formação da Internet moderna.

Em 1981, a ARPANET estava diante de uma mudança que pode parecer familiar para quem trabalha com redes: seria necessário substituir o protocolo que sustentava a comunicação entre seus hosts por uma nova arquitetura de interconexão. O NCP utilizado até então daria lugar ao TCP/IP. A diferença é que, naquela época, alguém teve a ideia, que talvez hoje pareça até ousada ou polêmica, de colocar uma data para que isso acontecesse.

Em outubro de 1981, Jon Postel publicou no TCP/IP Digest uma mensagem que apresentava o prazo de forma direta, como mostra a Figura 1.

Figura 1 – The deadline is: 1 January 1983. Fonte: Jon Postel, NCP-to-TCP Transition, TCP/IP Digest, Vol. 1, Issue 2, 14 Oct. 1981. Reprodução disponível no arquivo histórico LivingInternet. [1]

Publicada em novembro de 1981, a RFC 801 [2] formalizou o plano de transição. Não se tratava simplesmente de recomendar que os administradores começassem a implementar TCP/IP. Cada organização deveria preparar seus próprios hosts, havia etapas intermediárias previstas para 1982, mecanismos para permitir a convivência entre NCP e TCP/IP e, no final do processo, o NCP seria removido. Esses mecanismos incluíam hosts com suporte aos dois protocolos e serviços para Telnet, FTP e correio eletrônico entre sistemas NCP-only e TCP-only. De acordo com o planejamento, em janeiro de 1983 todos os hosts deveriam estar preparados para TCP/IP, o NCP seria retirado de serviço e os mecanismos temporários deixariam de ser necessários.

É interessante observar isso hoje porque estamos acostumados a falar de IPv6 há muitos anos, quase sempre utilizando a palavra transição. Em 1983 também houve uma transição, mas havia uma diferença fundamental, ela foi planejada como uma migração com início, etapas de preparação e prazo para terminar

Uma migração precisa de uma data

O primeiro aprendizado talvez seja justamente esse: uma migração precisa de uma data que represente o momento em que o novo passa a ser o padrão e o antigo deixa de ser a opção principal.

Isso não significa que todos os equipamentos precisam ser alterados ao mesmo tempo. No caso da ARPANET, houve desenvolvimento, implementação, testes e períodos de operação em paralelo. Ao longo de 1982, a comunidade realizou experiências em que o NCP era temporariamente interrompido, inclusive testes mais longos nos quais os pacotes NCP eram rejeitados. Era uma forma de descobrir antecipadamente os problemas e, ao mesmo tempo, mostrar aos administradores que o desligamento previsto para janeiro não seria apenas uma recomendação.

Quando dezembro chegou, a sensação de que a data estava próxima aparece claramente nos registros históricos. Em 30 de dezembro, Nancy Mimno enviou um aviso, conforme Figura 2, aos contatos institucionais da CSNET explicando que a transição vinha sendo planejada havia vários anos e que a mudança para TCP/IP aconteceria em 1º de janeiro. Segundo a mensagem, a mudança afetaria mais de 250 hosts da ARPANET, e alguns deles poderiam não estar preparados na data estabelecida.

Figura 2 – Mensagem enviada por Nancy Mimno, em 30 de dezembro de 1982, comunicando a transição da ARPANET para TCP/IP em 1º de janeiro de 1983. Fonte: MIMNO (1982), mensagem eletrônica preservada na coleção histórica de Anne e Lynn Wheeler. [3]

No dia seguinte, 31 de dezembro, enquanto milhões de pessoas provavelmente estavam pensando em festejar a virada do ano, a preocupação de alguns administradores era outra. Às 23h11, Ken Wertz, da Carnegie Mellon, enviou uma mensagem intitulada “TCP reminder”, como mostra a Figura 3, lembrando que a ARPANET começaria a utilizar exclusivamente TCP/IP às 00h01 do dia seguinte e recomendando que os administradores verificassem as informações sobre as configurações dos sistemas da universidade.

Figura 3 – Mensagem enviada por Ken Wertz, às 23h11 de 31 de dezembro de 1982, lembrando que a ARPANET passaria a utilizar exclusivamente IP/TCP às 00h01 de 1º de janeiro de 1983. Fonte: CMU CS General Bboard archive. [4]

Portanto, a data existia porque era necessário transformar uma intenção em um compromisso coletivo. E talvez essa seja uma das coisas que perdemos quando uma transição se prolonga indefinidamente, a percepção de que, em algum momento, ela precisa terminar.

Responsabilidade

Uma data, sozinha, não faz uma migração acontecer. O segundo aspecto que chama atenção lendo os documentos daquela época é a clareza sobre quem deveria fazer o quê. A RFC 801 atribuía a cada organização a responsabilidade de implementar TCP/IP em seus próprios hosts.

Essa característica distingue a ARPANET da Internet atual. A ARPANET possuía uma estrutura administrativa delimitada e estava submetida à coordenação da ARPA e da DCA. Na Internet global, nenhuma organização possui autoridade para determinar uma data única de desligamento do IPv4.

Em relato reproduzido na Figura 4, Andrew G. Malis afirmou que participou da implementação do código que permitia bloquear pacotes NCP e que a aplicação desse mecanismo era feita host a host, considerando inclusive uma lista oficial de máquinas autorizadas a continuar utilizando NCP. Ele passou o primeiro dia de 1983 desativando o acesso por NCP dos hosts que não possuíam autorização e atendendo às ligações de administradores cujos sistemas haviam ficado sem comunicação.

Figura 4 – Relato de Andrew G. Malis sobre a operação da transição NCP/TCP em 1º de janeiro de 1983. Malis descreve a aplicação dos filtros e sua atuação durante o desligamento. Fonte: Internet-history mailing list, 5 Dec. 2020. [5]

Dan Lynch, em entrevista ao Computer History Museum [6], também recordou esse momento como o grande cut-over, com muitos profissionais trabalhando em torno da virada para garantir que a mudança acontecesse. Talvez seja justamente isso que transforme uma decisão técnica em uma migração de verdade. Havia profissionais que não apenas acreditavam na necessidade da mudança, mas também assumiam a responsabilidade por sua execução.

Quando olhamos para o IPv6, essa questão se mantém igual. É relativamente fácil dizer que uma organização está implantando IPv6. Mas o difícil é identificar quem é o responsável por fazer com que determinada rede, serviço ou aplicação deixe de depender de IPv4. Sem essa atribuição clara, a transição tende a permanecer como uma intenção coletiva, sem liderança definida para conduzi-la até sua conclusão.

Exceções sem abandonar o objetivo principal

Há outro detalhe da história que considero especialmente importante. Nem todo mundo estava pronto. Os documentos deixam claro que existiam hosts que ainda não haviam concluído a migração e que alguns problemas eram esperados. Por isso foram previstas exceções e mecanismos de transição. A própria documentação posterior registra que alguns hosts receberam autorização temporária para continuar utilizando NCP depois do desligamento. Portanto, 1º de janeiro de 1983 deve ser entendido como o início efetivo da operação TCP/IP-only como regra, e não como o instante em que toda utilização de NCP desapareceu sem exceções.

Isso mostra que uma migração planejada não significa exigir perfeição antes de avançar. Significa reconhecer que haverá situações que não estarão prontas e criar mecanismos para tratá-las sem abandonar o objetivo principal. Essa distinção é importante. Uma exceção pode ser necessária. O problema é quando a exceção deixa de ter prazo e passa a ser considerada parte permanente da arquitetura.

É algo que conhecemos muito bem no mundo IPv6. Existe um equipamento legado que ainda precisa de IPv4. Existe uma aplicação antiga que não funciona em IPv6. Existe um sistema operacional que não pode ser atualizado. Existe um dispositivo de IoT que o fabricante ainda não implementou o IPv6. Cada caso pode ser legítimo, e em muitos ambientes, manter IPv4 temporariamente é simplesmente a decisão operacional correta. Mas precisamos tomar cuidado para que a existência desses casos não se transforme em justificativa para manter IPv4 em todos os lugares.

Talvez a pergunta não devesse ser quando todos estarão prontos para IPv6, porque provavelmente nunca teremos uma resposta para isso. Uma pergunta melhor seria: quais sistemas realmente ainda precisam de IPv4 e em quais pontos da infraestrutura ele precisa permanecer?

A partir daí, as exceções podem ser tratadas individualmente, em vez de servirem como justificativa para manter toda a infraestrutura presa ao passado. Foi exatamente essa capacidade que a comunidade da ARPANET demonstrou. Havia exceções, mas elas não impediram a migração.

A decisão de abandonar o NCP

Chegamos, talvez, à parte mais difícil: ter disposição para deixar para trás protocolos que passaram a fazer parte do legado da rede.

Nesse sentido, mecanismos como NAT64, DNS64, 464XLAT e SIIT-DC podem cumprir um papel semelhante ao dos serviços intermediários daquela transição: permitir o acesso a recursos legados sem obrigar que o protocolo anterior permaneça nativo em toda a infraestrutura.

A transição da ARPANET não terminou simplesmente porque a maioria dos hosts já utilizava TCP/IP. O plano previa que o NCP deixaria de ser utilizado e, no marco estabelecido para a migração, passariam a rejeitar o tráfego NCP proveniente dos hosts que não possuíssem uma exceção autorizada.

Isso exigia uma decisão que muitas vezes é difícil em ambientes de produção: aceitar que, a partir de determinado momento, o protocolo que havia sustentado a rede por anos deixaria de ser admitido como forma normal de acesso.

Vint Cerf relembrou posteriormente que a comunidade já havia feito interrupções temporárias do NCP durante os testes justamente para demonstrar que a migração seria levada a sério. Quando chegou janeiro de 1983, o acesso pelo protocolo antigo foi efetivamente encerrado, com poucas exceções.

Dan Lynch também ficou conhecido pelos botton com a frase “I survived the TCP transition”, Figura 5, dos quais produziu 500 unidades com recursos próprios para marcar a ocasião. Mas o que realmente havia acontecido era muito maior. A comunidade tinha demonstrado uma capacidade coletiva de decidir que uma transição precisava terminar.

Figura 5 – Botton “I Survived the TCP Transition 1/1/83”, produzido por Dan Lynch como lembrança da transição da ARPANET para TCP/IP. Fonte: Computer History Museum, entrevista com Dan Lynch.

E o que podemos aprender com isso?

Hoje falamos de transição para IPv6 há décadas. Há uma diferença importante entre a maneira como conduzimos hoje a adoção do IPv6 e a forma como a comunidade da ARPANET enfrentou a transição para TCP/IP.

Naquela época, o objetivo não era manter os dois protocolos indefinidamente. O NCP e o TCP/IP precisaram coexistir durante um período porque isso era necessário para realizar a migração. Isso não significa que toda convivência prolongada entre protocolos seja necessariamente inadequada. A diferença está em saber se ela responde a uma necessidade mensurável ou se apenas permanece por falta de planejamento para sua redução.

Hoje, muitas vezes, transformamos a própria coexistência em estado permanente. Não acredito que a lição seja simplesmente marcar uma data para desligar o IPv4 em toda a Internet, embora às vezes se proponham, até de forma provocativa, interrupções controladas para medir o grau atual de dependência do IPv4, como ocorreu durante os testes anteriores a 1983.

A ARPANET possuía algumas centenas de hosts e uma coordenação administrativa capaz de estabelecer e aplicar o prazo. A Internet atual reúne inúmeros sistemas autônomos, operadores, fabricantes, aplicações e usuários, sem uma autoridade central que possa determinar o desligamento global do IPv4. Pode ser que a pergunta quando vamos desligar o IPv4 provoque resistência antes mesmo de começarmos.

Talvez a pergunta mais útil seja outra: Qual é o próximo ambiente em que podemos estabelecer uma data para deixar de depender do IPv4?

Pode ser uma nova rede Wi-Fi, uma nova VLAN, um novo datacenter, uma infraestrutura de IoT ou uma aplicação que já possa nascer IPv6-only ou IPv6-mostly, recorrendo à tradução apenas para alcançar os recursos que ainda dependem de IPv4.

Para cada ambiente, a meta poderia ser acompanhada por indicadores simples: quantidade de aplicações que ainda exigem IPv4, volume de tráfego IPv4 remanescente, existência de responsáveis pelas exceções, prazo de revisão e percentual de serviços capazes de operar exclusivamente sobre IPv6.

Por fim, essa é a história que eu acho que vale contar, inclusive em sala de aula. Não apenas por nostalgia ou interesse pela história da Internet, nem como tentativa de afirmar que a Internet atual poderia ser administrada como a ARPANET de 1983, mas porque essa experiência apresenta uma pergunta incômoda que continua atual.

Fica, porém, uma pergunta: se uma comunidade inteira conseguiu estabelecer uma data para deixar o NCP para trás, o que ainda nos impede de definir metas e prazos para reduzir, de forma planejada, a dependência do IPv4 nos ambientes que administramos?

Referências

[1] LIVINGINTERNET. TCP/IP Internet Protocol. [S. l.], [s. d.]. Disponível em: https://www.livinginternet.com/i/ii_tcpip.htm. Acesso em: 8 set. 2026.

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

[3] MIMNO, Nancy. Notice of TCP/IP Transition on ARPANET. Mensagem eletrônica enviada à lista CSNET-LIAISONS em 30 dez. 1982. Reprodução preservada na coleção histórica de Anne e Lynn Wheeler. Disponível em: https://web.archive.org/web/20230928072135/https://www.garlic.com/~lynn/2000e.html#18. Acesso em: 8 set. 2026.

[4] WERTZ, Ken. TCP reminder. Mensagem publicada no CMU CS General Bboard em 31 dez. 1982. In: BAIRD, Jeff. CMU CS General Bboard Contents from 25-Nov-82 to 31-Dec-82. [S. l.], 15 jul. 2002. Disponível em: https://self-issued.info/Smiley/Nov-Dec-82_BBoard_Contents.html. Acesso em: 8 set. 2026.

[5] MALIS, Andrew G. Relato sobre a transição NCP/TCP na ARPANET. Mensagem eletrônica de 5 dez. 2020, reproduzida em discussão da lista Internet-history. In: AUERBACH, Karl. Fwd: Question – reference source for formal decommissioning of ARPANET in 1990? Internet History Society, 6 dez. 2020. Disponível em: https://elists.isoc.org/pipermail/internet-history/2020-December/006780.html. Acesso em: 8 set. 2026. [6] LYNCH, Dan. Interview of Dan Lynch. Entrevista concedida a James Pelkey em 16 fev. 1988, Cupertino, Califórnia. Mountain View: Computer History Museum, 2016. Disponível em: https://archive.computerhistory.org/resources/access/text/2016/02/102717120-05-01-acc.pdf. Acesso em: 8 set. 2026.