Summary

  • Em 1985, o BOOTP permitia que um cliente sem disco pedisse um endereço e as instruções do arquivo de inicialização antes de poder enviar uma solicitação IP comum a um servidor. Um relé podia levar essa troca para além da rede local.
  • giaddr descrevia o caminho de retransmissão do próprio BOOTP. A RFC 1542 esclareceu depois que ele não era o roteador IP geral nem a rota padrão do cliente.

O computador precisava de ajuda antes de poder pedi-la

Uma estação sem disco enfrentava um impasse ao ligar: precisava de um endereço de Internet para usar IP, mas dependia da rede para descobrir qual endereço deveria usar. Também precisava localizar o servidor e o arquivo que dariam continuidade à inicialização. Se o servidor estivesse em outra rede, uma transmissão local não atravessaria sozinha os roteadores comuns.

A RFC 951, publicada em setembro de 1985, descreveu o BOOTP como a primeira etapa: determinar o endereço e selecionar o arquivo de inicialização. O cliente enviava um BOOTREQUEST com seu endereço de hardware e, caso já o conhecesse, seu endereço IP. Se ciaddr fosse zero, o servidor poderia consultar seu banco de dados pelo endereço de hardware e devolver o endereço do cliente em yiaddr. Outros campos indicavam o servidor e o arquivo. A troca usava UDP nas portas 67 e 68.

A resposta não carregava o sistema operacional. A RFC 951 separou a escolha do endereço e do arquivo da transferência posterior, normalmente feita com TFTP. A RFC 906 já havia descrito a carga de arquivos de inicialização pela rede em 1984. Uma resposta BOOTP podia indicar servidor e arquivo sem provar que o cliente alcançou o servidor, recebeu todos os dados ou concluiu a inicialização.

Da transmissão local ao serviço em outra rede

O cliente ainda não configurado não precisava descobrir um servidor remoto pelo DNS nem possuir uma rota previamente definida. Ele podia transmitir o pedido na rede local. Se o servidor estivesse em outro lugar, um gateway ou agente de encaminhamento poderia levar o pedido BOOTP até ele e trazer a resposta de volta. A RFC 951 tornou opcional essa operação entre redes: ela exigia código adicional em gateways e servidores, mas nenhuma ação especial do cliente.

O pacote continha giaddr, descrito em 1985 como um endereço IP de gateway. No encaminhamento, o primeiro gateway podia preencher o campo se estivesse zerado e incrementar hops. Com giaddr diferente de zero, o servidor podia enviar a resposta BOOTP para aquele endereço, pela porta do servidor, para que o relé a entregasse na rede do cliente. O campo, portanto, conectava o computador em inicialização a um serviço instalado em outro local.

Esse caminho não era a rota que o computador usaria depois. A redação inicial da RFC 951 deixava margem para confusão: uma passagem sugeria encaminhar pacotes via giaddr “para chegar ao servidor”. Mas a transferência do arquivo de inicialização e o roteamento IP normal do cliente eram tarefas diferentes. O nome “gateway” não bastava para torná-las a mesma coisa.

A clarificação de 1993

A RFC 1542 tratou diretamente da ambiguidade. A especificação anterior não definia com clareza o comportamento do agente de encaminhamento, então adotou “agente de retransmissão” para diferenciá-lo do encaminhamento IP comum. O relé recebe a mensagem BOOTP como destino e gera outra mensagem BOOTP; não apenas deixa um datagrama passar intacto. A função podia ficar em um roteador que conectava as redes ou em um host ligado diretamente à rede do cliente.

A RFC 1542 explica que giaddr serve para levar BOOTREQUESTs, por agentes de retransmissão, a servidores em outras redes e trazer os BOOTREPLYs de volta pelo mesmo tipo de agente. O campo não representa um roteador IP de uso geral para o cliente, que não deve interpretá-lo dessa forma. Para alcançar um servidor TFTP fora da rede local, o host ainda precisa obter separadamente o endereço do primeiro roteador, por outra opção de configuração ou mecanismo de descoberta.

A clarificação não descartou o desenho de 1985. Ela tornou seu limite visível: o relé resolvia um problema próprio do serviço de inicialização enquanto a configuração IP do cliente ainda estava incompleta. Não configurava todo o tráfego que viria depois.

O que a inicialização centralizada permitia — e o que não resolvia

Com um relé, o servidor de inicialização, os registros que relacionavam endereços físicos e IP e os arquivos podiam ficar fora do cabo local. Isso poderia evitar um servidor em cada segmento e dar ao operador um ponto central para manter os mapeamentos e arquivos. É uma implicação arquitetural das RFCs, não uma medida da adoção ou dos custos reais.

Ainda havia dependências em cadeia: enlace local, relé, destino configurado, registro do cliente no servidor, arquivo, rota do cliente e a transferência TFTP. Uma resposta BOOTP não prova que qualquer etapa posterior foi concluída. O endereço do relé tampouco identifica uma pessoa, comprova autorização ou determina a rota padrão do cliente.

Mais tarde, o DHCP reutilizou o comportamento do agente de retransmissão e acrescentou formas de alocação de endereços, inclusive concessões por tempo limitado. Essa evolução não deve confundir a troca de inicialização BOOTP, o ciclo da concessão DHCP, a transferência TFTP e o roteamento IP comum. Os quatro podem participar do mesmo processo de partida, mas cada um tem estado e registros próprios.

A questão histórica cabe em quatro letras. giaddr permitia que uma mensagem cruzasse uma fronteira quando o host ainda aprendia a participar do IP. O nome não o transformava no gateway do host. Na infraestrutura da Internet, o caminho de retorno de uma mensagem de controle, o próximo salto do cliente, o endereço do servidor de arquivos e o êxito do serviço são fatos relacionados, mas não intercambiáveis.

Fontes