Resumo

  • O BOOTP permitia que um cliente sem disco consultasse seu endereço IP, um servidor e o nome de um arquivo de inicialização antes de ter conectividade IP normal; depois, uma transferência separada, geralmente via TFTP, buscava o arquivo.
  • A resposta criava outro impasse: sem endereço, o cliente não podia responder ao ARP. A RFC 951 propôs uma entrada ARP temporária no servidor ou uma resposta em broadcast; regras posteriores permitiram retransmitir pedidos entre sub-redes.

Ao ser ligada, uma estação sem disco ainda não tinha um sistema operacional para configurar a rede. O programa na PROM podia enviar um pedido, mas primeiro precisava saber qual endereço usar e qual arquivo carregar. Só então poderia solicitá-lo. A sequência parecia circular: como um equipamento recebe uma resposta de rede antes de ter uma identidade de rede utilizável?

Bill Croft e John Gilmore descreveram esse problema na RFC 951, publicada em setembro de 1985. O BOOTP não transferia arquivos. Ele cuidava da primeira etapa: determinar o endereço e escolher o arquivo de inicialização. A PROM do cliente podia pedir um endereço, um servidor e um nome de arquivo; após a resposta, uma segunda etapa — normalmente com TFTP — buscaria o arquivo para a memória. O documento previa uma partida sem intervenção humana, ao ligar uma máquina sem operador presente. Era uma proposta de projeto, não um levantamento de quantas máquinas a utilizavam. (RFC 951, §§ 2 e 7.5.)

O pedido não exigia um endereço IP que o cliente ainda desconhecia. Se o servidor também não estivesse definido, o cliente podia enviar um pacote IP/UDP com endereço de origem zero a 255.255.255.255, um broadcast no cabo local. O pedido levava também o tipo e o endereço de hardware do cliente, além de um identificador de transação. O servidor podia consultar sua própria base de dados para associar aquele endereço de hardware a um endereço IP, colocar o resultado no campo yiaddr da resposta e escolher o caminho completo do arquivo de inicialização. Um pedido genérico, como unix, podia resultar em um arquivo personalizado para aquele cliente. O registro local do servidor passava a fazer parte do processo de partida. (RFC 951, §§ 2–3, 7.1, 7.3 e 9.)

A primeira resposta tinha seu próprio dilema do ovo e da galinha. Em geral, o servidor precisa do ARP para descobrir o endereço de enlace de um destino IP. Mas o cliente ainda não conhecia seu endereço e não podia responder à consulta ARP do servidor. A RFC 951 apresentou duas saídas. Com o suporte adequado no kernel ou no driver, o transmissor podia criar uma entrada ARP temporária a partir dos endereços de hardware e IP proposto, com prazo para expirar. A RFC registra que o UNIX 4.2 BSD tinha esse recurso. Sem esse suporte, o servidor podia transmitir a resposta por broadcast na interface do cliente. A solução dependia dos recursos locais de quem enviava a resposta. (RFC 951, § 4.)

As duas portas UDP também ajudavam a entregar a resposta. Os pedidos iam para a porta 67 do servidor BOOTP; as respostas, para a porta 68 do cliente. A RFC 951 explica que essa separação permitia ao kernel filtrar broadcasts destinados à porta do cliente nos equipamentos que não a escutavam, sem acordar e escalonar os processos servidores BOOTP de outras máquinas. Uma porta aleatória escolhida pelo cliente também poderia fazer o broadcast parecer destinado a um processo em escuta em outro equipamento. Não era um detalhe cosmético: evitava que a resposta de inicialização de uma máquina virasse um evento de aplicação para todo o segmento. (RFC 951, § 3.)

O servidor de inicialização nem sempre ficava no mesmo cabo. A RFC 951 tornava opcional a partida através de gateways e exigia cooperação. Um gateway ou outro agente podia receber o broadcast, preencher giaddr com a rede do cliente e encaminhar o pedido ao servidor. Os autores alertavam contra retransmitir pedidos indiscriminadamente, pois isso poderia gerar loops. Em outubro de 1993, a RFC 1542 delimitou melhor essa função: um agente de retransmissão BOOTP não era simplesmente um roteador IP encaminhando um datagrama de forma transparente. Podia receber a mensagem BOOTP como destino final e gerar outra mensagem BOOTP. A função podia rodar no roteador ou em outro host conectado à sub-rede do cliente. Era um serviço configurado, com regras próprias de processamento. (RFC 951, § 8; RFC 1542, §§ 4–4.1.)

Por isso, não convém reduzir o BOOTP a um “DHCP antigo”. A RFC 2131 descreveu depois o DHCP como uma extensão do mecanismo BOOTP e preservou o formato de mensagens e o comportamento do agente de retransmissão para permitir interoperabilidade com clientes existentes. Também destacou uma mudança central: o DHCP podia conceder um endereço por prazo determinado e reutilizá-lo quando o cliente deixasse de precisar dele. O modelo do BOOTP de 1985 consultava registros no servidor para encontrar o endereço e o arquivo de inicialização. O DHCP também permite alocação manual; a diferença não foi transformar todos os endereços em temporários, mas acrescentar ao protocolo a alocação dinâmica. (RFC 2131, §§ 1–2.)

A contribuição histórica do BOOTP foi pequena, mas necessária. Ele não tornava uma máquina sem disco autônoma, não autenticava um usuário e não transferia sozinho a imagem do sistema operacional. Definia como uma máquina com endereço de hardware, mas sem identidade IP utilizável, poderia pedir as próximas peças do processo de partida; como um servidor poderia escolhê-las; e como uma resposta retornaria antes de o ARP funcionar normalmente. Nesse caso, a conectividade começava com um broadcast local, um registro explícito no servidor e uma resposta que exigia tratamento especial.

Fontes e limites

A RFC 951 era uma proposta e descreve o comportamento previsto, não o alcance da adoção. A menção a um recurso de cache ARP no 4.2 BSD não prova que todas as implementações o tinham. A RFC 1542 registra regras de retransmissão posteriores, sem demonstrar conformidade universal. O BOOTP escolhia parâmetros de rede e o nome de um arquivo; outra etapa transferia o arquivo. O DHCP acrescentou concessões dinâmicas e também manteve a alocação manual.