Resumo

  • O prazo de janeiro de 1983 tinha consequência na ARPANET porque seu patrocinador controlava os IMPs que podiam deixar de atender o NCP; ele não invalidava redes independentes fora dali.
  • O RFC 801 combinou uma regra comum com execução distribuída: cada organização implementou sua própria pilha, enquanto relés temporários, serviços equivalentes, medições e cortes de ensaio reduziram o risco.
  • A data não produziu uma migração perfeita: os levantamentos de serviços não mostraram 100%, a distribuição da tabela de hosts falhou e a carga de produção revelou problemas que os testes não haviam reproduzido.

Um host conectado, mas fora do conjunto compatível

Uma máquina NCP podia continuar ligada fisicamente à ARPANET depois que seu protocolo deixasse de ser atendido. O software não desaparecia; o serviço, sim. Esse é o mecanismo que separa uma especificação de uma regra operacional. O texto diz como os pacotes deveriam se comportar. A rede em funcionamento decide quais pacotes ainda receberão tratamento.

Vint Cerf contou ao Computer History Museum que os Interface Message Processors tinham mecanismos para rejeitar o antigo tráfego NCP. Em sua lembrança, houve um corte de um dia em meados de 1982 e outro, de cerca de dois dias, por volta de outubro. Pessoas que ainda dependiam do protocolo perderam correio eletrônico e protestaram. A indisponibilidade mostrou, de modo que nenhum memorando conseguia mostrar, que o prazo seria executado.

O relato veio décadas depois e usa datas aproximadas. Cerf também mencionou poucas exceções em janeiro para máquinas com dificuldades especiais de software. Portanto, “flag day” é uma abreviação retrospectiva. A história real inclui aviso, pontes, ensaios, exceções e meses de ajuste após o corte.

Por que o NCP terminava onde a ARPANET terminava

O NCP não era apenas uma versão anterior do TCP. Ele estava associado ao serviço host a host e ao ambiente de endereços da ARPANET. A pesquisa da ARPA, porém, já envolvia rádio por pacotes, satélites e redes locais. Unir esses sistemas exigia um protocolo que não incorporasse as premissas de uma única sub-rede.

O RFC 801 apresenta IP e TCP como resultado desse problema. O RFC 791 descrevia o datagrama que atravessava redes distintas; o RFC 793 colocava a comunicação confiável nas pontas. A coleção interligada, chamada de ARPA Internet ou Catenet, podia manter diferentes tecnologias físicas sob um ambiente comum entre hosts.

Manter o NCP para sempre também teria imposto uma escolha. Hosts de serviço, tabelas de nomes, contas, relés e equipes teriam de sustentar dois universos. A organização atrasada não pagava sozinha por sua compatibilidade. Parte do custo ficava com todos os que mantinham a travessia.

O Department of Defense havia adotado IP/TCP como padrão para suas redes de pacotes. Na ARPANET, que financiava e operava por contratos definidos, havia um ponto legítimo de decisão: o patrocinador podia condicionar a continuidade do serviço a uma migração. Essa competência não transformava o autor de um RFC em autoridade sobre redes alheias.

A meta era comum; o trabalho, local

O RFC 801 atribuiu a cada organização host a responsabilidade de implementar IP/TCP em suas próprias máquinas. Nenhum centro conseguia portar remotamente sistemas operacionais diversos, corrigir interfaces, adaptar programas ou preparar suporte. O plano fixava comportamento e calendário; os sites produziam o código que realmente se comunicaria.

A pilha de transporte era apenas o começo. Telnet, transferência de arquivos e correio precisavam existir sobre TCP. Para o usuário, adoção não era uma resposta de laboratório a um datagrama, mas a capacidade de entrar num sistema remoto, mover um arquivo e entregar uma mensagem.

O correio exigiu a continuidade mais cuidadosa. O RFC 773 queria preservar nomes de caixas postais da ARPANET, manter mecanismos antigos durante o intervalo e fazer o encaminhamento entre NCP e TCP sem intervenção do usuário sempre que possível. O substituto precisava carregar o valor social do sistema antigo antes de justificar sua retirada.

Hosts com os dois protocolos funcionaram como relés. Uma sessão Telnet podia chegar em TCP e sair em NCP. Um arquivo podia ser copiado em duas etapas. Uma mensagem podia entrar por um procedimento, esperar numa fila e seguir pelo outro. Isso evitava exigir que centenas de máquinas mudassem no mesmo instante.

O relé também concentrava risco. Adicionava uma máquina à cadeia, exigia contas especiais e podia ficar sobrecarregado. O RFC 801 tratava explicitamente de confiabilidade e capacidade. A ponte comprava tempo para o trabalho local; não concedia ao protocolo antigo o direito de consumir recursos comuns indefinidamente.

Ensaiar a perda para descobrir a dependência

Um corte de teste responde a perguntas que uma lista de conformidade não alcança. O controle realmente funciona? Qual aplicação ainda depende do caminho antigo? Quem recebe o alerta? Em 1982, o correio interrompido revelou uma dependência que o prazo escrito não tornava urgente o bastante.

Não se tratava de uma votação sobre a verdade técnica. A comunidade de hosts da ARPANET não era um parlamento mundial. A relação relevante era operacional: o patrocinador podia alterar o serviço da rede sob sua responsabilidade; cada organização controlava os sistemas que conectava; a dor do ensaio voltava ao mesmo ambiente de pesquisa que dependia da comunicação.

Essa limitação impede outra leitura errada. Uma instituição que não opera a rede, não financia a migração e não responde pela falha não pode usar 1983 para reivindicar poder global. Na ARPANET, a consequência era concreta: pacotes NCP deixavam de ser atendidos. Em outra rede, ninguém perdia existência ou legitimidade por declaração.

O plano dizia “todos”; a medição dizia “depende”

O marco de janeiro no RFC 801 previa todos os hosts capazes de TCP, todos os serviços em TCP, NCP removido e relés encerrados. Os levantamentos de David Smallberg mostram que disponibilidade observável não cabe numa linha tão limpa.

O RFC 847 resume testes semanais de servidores Telnet, FTP e SMTP. Em 28 de dezembro de 1982, 95, 80 e 72 hosts, respectivamente, aceitaram conexão entre 314 listados. Em 4 de janeiro de 1983, os números subiram para 151, 132 e 124 entre 315. Em 22 de fevereiro, eram 190, 181 e 178 entre 325.

Esses valores não medem toda implementação TCP. Uma máquina podia estar desligada, ter função especial ou escolher não oferecer os serviços testados. Os autores estimaram que 37 hosts, 11% do conjunto, estavam nessa situação, tornando 89% um teto mais razoável. O denominador também mudou ao longo das semanas.

A conclusão responsável é que os serviços TCP visíveis cresceram rapidamente em torno do corte, sem formar um estado instantâneo de 100%. Especificação publicada, pilha instalada, porta acessível, tráfego real e experiência do usuário são evidências diferentes. O levantamento media uma delas.

Depois do prazo, a carga virou o teste

O National Research Council avaliou depois a transição no relatório publicado como RFC 942. Cerca de trinta hosts exclusivamente TCP participaram dos seis meses anteriores. A preparação ajudou a preservar a capacidade operacional, mas o serviço normal levou alguns meses para voltar.

O Network Information Center não estava pronto para o novo ambiente, e houve problemas na distribuição da tabela de hosts. Máquinas de serviço sofreram com desempenho porque nenhuma havia sido submetida por muito tempo à carga completa de usuários. Parâmetros precisaram de ajuste depois. Os relés de correio foram muito usados; os demais, pouco.

Nada disso anula o corte. Mostra quanto ele custou. Uma infraestrutura pode retirar uma promessa antiga e manter continuidade essencial sem atingir maturidade no primeiro dia. O calendário elimina uma opção; capacidade, dados de configuração e suporte ainda precisam sobreviver à produção.

Também aparece o limite do comando. O patrocinador podia desligar NCP no subnet, mas não substituía desenvolvedores de sistemas, administradores de serviço, o NIC, operadores de TAC ou mantenedores de relé. A fronteira era central; a competência continuava espalhada.

Onde a ordem acabava

Dentro da ARPANET, um site não tinha direito ilimitado de exigir que todos mantivessem NCP. O operador podia retirar um serviço que impedia a arquitetura de múltiplas redes, desde que preparasse funções equivalentes, tornasse a consequência visível, controlasse exceções e assumisse o dano causado por erro.

Fora dessa fronteira de ativos e contratos, o mesmo patrocinador não fabricava adoção. Universidades, fabricantes, LANs e outras redes precisavam implementar TCP/IP e escolher seus pares. A autoridade mais ampla da suíte veio de código que interoperava entre tecnologias diferentes, não de uma instituição que marcava o não adotante como inválido.

Essa é a diferença entre coordenação e soberania. Um operador pode recusar tráfego em seu equipamento. Deve explicar a regra, medir seus efeitos e responder por decisões ruins. Não pode transformar o controle do próprio limite em propriedade sobre máquinas ou redes futuras de terceiros.

Assim, 1º de janeiro de 1983 não precisa ser chamado de aniversário da Internet. A interligação de redes já havia sido concebida, demonstrada e usada. A data marcou o fim do NCP como serviço normal da ARPANET. Dentro dela, o prazo empurrou a execução; fora dela, a interoperabilidade atraiu a adoção. A força histórica da regra veio justamente de sua fronteira limitada.

Fontes e limites de evidência

O plano, as responsabilidades e os marcos estão no RFC 801. A continuidade do correio está no RFC 773. As regras comuns são RFC 791 e RFC 793; o RFC 820 registra o ambiente de protocolos da época.

Os números de aceitação de serviço vêm do RFC 847, com suas ressalvas. As lições de operação vêm do RFC 942. Os cortes de ensaio, o mecanismo no IMP e as poucas exceções são atribuídos à entrevista de Vint Cerf no Computer History Museum.

O conjunto não contém lista completa de exceções, duração única de indisponibilidade ou denominador global. Sustenta uma transição planejada e executada na ARPANET, seguida por meses de reparos. Não sustenta um instante em que todas as redes do mundo adotaram TCP/IP ou em que a Internet nasceu.