Resumo

  • O RFC 1542 exige que todas as mensagens BOOTREQUEST de um cliente sigam para o mesmo destino ou grupo de destinos.
  • O documento descreve um retransmissor que alternava entre servidores; nesse modelo, solicitações consecutivas do mesmo cliente podiam chegar a máquinas diferentes.
  • A escolha estável por cliente permite distribuir a carga sem separar as etapas de uma conversa.

O caminho entre o cliente e o servidor

O BOOTP foi pensado para equipamentos que iniciavam sem conhecer o próprio endereço IP nem o servidor que forneceria os dados de inicialização. O RFC 951, publicado em 1985, descreveu a determinação do endereço e a escolha do arquivo de boot como uma primeira fase. O cliente podia enviar uma transmissão local. Se o servidor estivesse em outra rede, porém, os roteadores não transformariam automaticamente esse broadcast em uma solicitação dirigida ao servidor.

O RFC 951 permitiu que gateways cooperassem para encaminhar a mensagem. A função era opcional e podia ficar no próprio gateway ou em outro agente ligado à rede do cliente. O agente recebia BOOTREQUEST, preenchia giaddr quando necessário e incrementava hops; o servidor usava giaddr para devolver a resposta à rede de origem. A proposta existia, mas os detalhes do comportamento do retransmissor ainda precisavam de definição.

O RFC 1532 buscou esclarecer o BOOTP em outubro de 1993. O RFC 1542 foi publicado no mesmo mês, atualizou o RFC 951 e substituiu o RFC 1532 porque erros editoriais haviam sido introduzidos naquele texto. Seu resumo aponta o comportamento dos agentes de retransmissão como um dos aspectos que precisavam ser reforçados. A decisão de destino do agente passava a ser tratada como parte do funcionamento do protocolo, não como detalhe interno de um roteador.

Uma afinidade por cliente

O RFC 1542 preservou decisões locais. O retransmissor precisava ter uma configuração para habilitar ou desabilitar o encaminhamento; o padrão deveria ser desabilitado. Mensagens com hops acima de 16 deveriam ser descartadas, e o administrador poderia definir um limite menor. Se giaddr estivesse zerado, o agente deveria preenchê-lo com o endereço da interface de entrada, aumentar hops e preservar os demais campos BOOTP. A lista de destinos também ficava sob configuração.

Sobre essa flexibilidade havia uma obrigação: todas as solicitações BOOTREQUEST de um mesmo cliente tinham de usar o mesmo destino ou conjunto de destinos. O texto explica o motivo com um caso concreto, mas sem identificar o fabricante. Pelo menos uma implementação conhecida fazia balanceamento em rodízio: cada novo pedido era encaminhado ao próximo servidor da lista. Assim, o mesmo cliente podia conversar com servidores diferentes em pedidos consecutivos.

O problema não era ter vários servidores. Era decidir o destino de novo para cada pacote, apesar de o protocolo poder exigir várias mensagens encadeadas. O RFC diz que esse rodízio reage mal com DHCP e talvez com outras variações do BOOTP que dependam de múltiplas trocas entre cliente e servidor. Se um servidor vê o primeiro passo e outro recebe o seguinte, o contexto da conversa pode ficar dividido. O documento descreve uma incompatibilidade potencial; não registra uma queda específica nem mede o quanto essa prática era comum.

O RFC também sugere como conservar o balanceamento. O agente pode calcular um hash do endereço de enlace do cliente, ou de outro identificador confiável, e usar esse resultado para selecionar um destino estável. Cada cliente permanece associado ao mesmo caminho, enquanto clientes distintos podem cair em servidores diferentes. A alternativa mais simples é enviar tudo ao mesmo conjunto de destinos. Em ambos os casos, a unidade de distribuição passa a ser o cliente, e não o pacote.

A garantia tem limites

A afinidade não é uma promessa de disponibilidade. O RFC 1542 não garante que servidores estejam ativos, compartilhem estado ou consigam completar o boot. A regra apenas impede que o retransmissor mude o destino para um mesmo cliente entre pedidos. Ela também não exige um único servidor para todos: um grupo configurado pode receber cada mensagem, desde que a seleção por cliente permaneça estável.

O RFC 1534, também de outubro de 1993, tratou da interoperabilidade entre DHCP e BOOTP; as mensagens DHCP partiam do formato BOOTP. O RFC 2131, de 1997, descreveu com mais detalhe as etapas DHCP: descoberta, ofertas, escolha e novas solicitações. Esses documentos mostram por que uma conversa pode envolver mais de uma troca, mas não comprovam que o exemplo de rodízio do RFC 1542 tenha causado uma falha real.

O RFC Editor registra uma errata verificada para o RFC 1542. Ela corrige, na seção 3.1.1, uma referência a BOOTREPLY para BOOTREQUEST no texto sobre o sinalizador de broadcast. A correção pertence a outro trecho e não altera a regra de destino por cliente da seção 4.1.1.

A história termina numa distinção prática. É possível distribuir clientes por vários servidores; alternar o destino de cada pacote de um mesmo cliente pode partir uma conversa em várias etapas. O RFC 1542 tornou essa fronteira explícita e deixou com o operador a decisão de habilitar o retransmissor e escolher uma estratégia estável de distribuição.

Fontes