Resumo

  • O RFC 906 propôs TFTP sobre IP como caminho comum para buscar o primeiro código de uma máquina sem disco, numa época em que instalações com equipamentos de vários fabricantes podiam precisar de múltiplas implementações de servidor de boot.
  • No exemplo para uma estação Motorola 68000 com Ethernet, um ERROR não encerrava a espera: o primeiro pacote DATA válido determinava o parceiro da transferência. O código em ROM tinha menos de 4 KB, sem o driver Ethernet; isso comprova uma implementação, não adoção ampla.

Uma estação podia falar os mesmos protocolos de Internet que as vizinhas depois de iniciar e, ainda assim, depender de outro mecanismo para chegar até esse ponto. O sistema operacional ainda não estava disponível para pedir um arquivo. Um programa pequeno, gravado em memória somente de leitura, precisava ativar rede suficiente para buscar o próximo trecho de código.

Publicado por Ross Finlayson em junho de 1984, o RFC 906 descreveu o custo prático dessa fronteira. Os fabricantes usavam métodos diferentes para carregar os arquivos iniciais. Uma instalação que atendesse vários tipos de máquina talvez tivesse de manter várias implementações de servidores de boot, embora os computadores pudessem se comunicar livremente depois de ligados. O RFC propôs um protocolo comum para essa primeira transferência: TFTP transportado por IP. O próprio documento diz que é uma proposta para a comunidade ARPA Internet e pede comentários e melhorias. Não afirma que o método já tivesse se tornado universal.

A escolha do TFTP foi deliberadamente contida. O programa enviava uma solicitação de leitura com o nome do arquivo, recebia pacotes DATA e devolvia confirmações ou erros. O RFC considerava aceitável que o primeiro carregamento fosse lento, pois uma etapa posterior poderia usar um protocolo mais rápido. O cliente precisava receber datagramas IP de até 524 octetos, sem contar o cabeçalho IP: um pacote TFTP DATA de até 516 octetos mais os 8 octetos do cabeçalho UDP. A máquina que estava iniciando não precisava responder a solicitações TFTP de leitura ou escrita recebidas.

Era um cliente enxuto para buscar código, não um servidor de arquivos completo.

O texto também não padronizava toda a experiência de boot. Ele especificava apenas os protocolos de rede. Não dizia como a pessoa deveria iniciar a máquina nem qual comando digitar no console, e não exigia Ethernet ou qualquer outro enlace específico. Assim, uma troca de pacotes comum podia conviver com procedimentos locais diferentes para iniciar a máquina e escolher o arquivo.

O exemplo torna essa divisão mais concreta. Finlayson relatou uma implementação em ROM para uma estação Motorola 68000 conectada por Ethernet. A pessoa informava o nome do arquivo e podia fornecer os endereços Internet da própria estação e do servidor. Sem o endereço do servidor, mais de um servidor TFTP poderia receber a solicitação. A questão importante deixava de ser simplesmente se alguém responderia e passava a ser qual resposta mudaria o estado do cliente.

A regra era direta. Um pacote TFTP ERROR de um servidor não fazia o cliente desistir, porque outro servidor ainda poderia enviar o arquivo. O primeiro pacote DATA válido definia os endereços Internet e Ethernet para os quais iriam os ACKs seguintes. Se outro servidor enviasse DATA depois, o cliente lhe devolveria um ERROR. A solicitação podia chegar a vários servidores; uma única primeira resposta válida passava a ser a contraparte daquela transferência.

Essa regra pode parecer uma autenticação, mas não é. A revisão 2 do TFTP diz que o protocolo não prevê autenticação de usuário. O critério do primeiro DATA válido escolhe quem respondeu; não prova que aquele seja o servidor esperado pelo operador nem que a origem da imagem de boot tenha sido verificada de forma independente. As fontes não registram um ataque ou incidente de implantação. Elas mostram onde a proposta colocava a decisão: no tratamento das respostas pelo cliente e no ambiente local que determinava quem podia responder.

O número sobre o tamanho do código também tem limites claros. A implementação descrita ocupava menos de 4 KB, sem contar o driver do dispositivo Ethernet. Isso demonstra que um autor conseguiu colocar o cliente em uma ROM limitada; não mede outros processadores, não conta instalações e não comprova que os métodos específicos dos fabricantes tenham desaparecido.

Documentos posteriores ajudam a entender a arquitetura, mas não provam uma cadeia direta de adoção. O RFC 951, de 1985, descreve o BOOTP como uma primeira fase para determinar o endereço e escolher o arquivo de boot, seguida normalmente pela transferência TFTP. Em 1989, o RFC 1123 também apresenta duas etapas para o boot de uma máquina sem disco, conduzidas por um programa em ROM: configurar IP e carregar o código do sistema. Esses textos deixam mais clara a separação entre preparação e transferência; não transformam a única implementação mencionada no RFC 906 em uma estatística de implantação.

O valor histórico do RFC 906 está nessa fronteira, não numa vitória consumada. Um programa pequeno em ROM podia pedir o próximo arquivo usando o transporte IP, enquanto o modo de iniciar a máquina e parte da escolha do servidor permaneciam locais. O primeiro DATA válido marcava o ponto em que uma resposta se tornava a contraparte da transferência. O protocolo ficava enxuto, mas cabia ao operador saber de onde viria o código que respondesse primeiro.

A Note 65 posterior de Heng Lu funciona aqui como disciplina editorial, não como prova da intenção de Finlayson: proposta publicada, implementação relatada, implantação e uso são evidências diferentes. O material disponível confirma uma proposta e um exemplo. Não informa quantas instalações adotaram o método nem se ele eliminou o custo de suporte descrito.

Fontes