Resumo

  • A RFC 903 tratava de um problema específico de partida a frio: uma estação sem disco conhecia seu endereço físico, mas precisava obter um endereço de protocolo antes de usar IP.
  • O RARP fazia a consulta na camada de enlace. Um servidor respondia com base em uma tabela de associações entre endereços físicos e de protocolo; a resposta não autenticava a máquina nem provava que a inicialização havia terminado.
  • O protocolo não definia uma resposta explícita de “não encontrado”. Sem resposta, o cliente precisava esperar o timeout sem saber se faltava a associação, se um pacote se perdera ou se nenhum servidor respondera.
  • A RFC 950 e o BOOTP mostram por que um endereço não bastava para configurar um host: também poderiam ser necessários gateway, servidor de nomes, máscara de sub-rede e arquivo de inicialização.

A primeira pergunta vinha antes do IP

Pense em uma estação de trabalho sem disco local. Seu código de inicialização consegue ler o endereço físico da interface Ethernet, mas não tem um endereço de Internet guardado. Uma solicitação IP não resolve o impasse: a máquina ainda não sabe que endereço de origem usar.

Na RFC 903, publicada em junho de 1984, Ross Finlayson, Timothy Mann, Jeffrey Mogul e Marvin Theimer propuseram o RARP. O memorando descreve um host que pergunta a uma fonte externa seu endereço de protocolo por um meio de difusão, como a Ethernet. O ARP resolvia o sentido oposto: encontrava o endereço físico quando o endereço de protocolo já era conhecido. O RARP partia do endereço físico e pedia o endereço de protocolo correspondente.

Não era um serviço geral de identidade. O RARP não perguntava quem era o dono da estação nem se uma pessoa tinha direito a usar determinado endereço. Ele dava a um host ainda não configurado um modo de solicitar uma associação específica antes da comunicação IP normal.

Um servidor local guardava a resposta

A RFC 903 definiu deliberadamente o RARP como um protocolo separado da camada de enlace. Ele reutilizava o formato de pacote do ARP, mas atribuía códigos de operação distintos às solicitações e respostas reversas. Ao pedir o próprio endereço, o host colocava o mesmo endereço físico nos campos de origem e de destino. Um servidor que reconhecesse aquele endereço poderia responder com o endereço de protocolo correspondente.

A resposta dependia do estado do servidor. A RFC diz que um ou mais servidores RARP mantêm um banco de associações entre endereços físicos e de protocolo. Isso difere do ARP comum: os hosts acumulam em cache as correspondências dos pares, sem separação entre cliente e servidor. O RARP introduzia, portanto, uma dependência operacional: o cliente podia perguntar, mas alguém na rede local precisava manter a tabela do servidor em condições de uso.

A resposta era um recibo de correspondência, não uma credencial. A RFC não define autenticação que ligue o endereço físico a uma pessoa, a um proprietário ou a um equipamento autorizado. Também não prova que o host instalou corretamente o endereço, alcançou um gateway ou carregou um sistema operacional. Essas etapas vêm depois.

Silêncio não queria dizer “não encontrado”

A RFC 903 define solicitações e respostas reversas, mas nenhum pacote de “não encontrado” ou de erro. Os autores explicam que vários servidores podem estar livres para responder. Em vez de criar uma recusa separada, o RFC manda o solicitante esperar até o timeout se nenhuma resposta chegar dentro de um intervalo razoável.

Essa escolha manteve a troca pequena, mas deixou o cliente com uma observação ambígua. O timeout podia indicar que nenhum servidor tinha aquela associação; a solicitação ou resposta também podia ter se perdido, o enlace podia estar fora do ar ou nenhum servidor podia estar disponível. O silêncio não distinguia essas condições. Um log de inicialização que apenas registrasse “timeout RARP” não determinava a causa.

A diferença importa ao reconstruir uma falha. A ausência de resposta mostra o que o cliente recebeu — nada —, mas não prova que o endereço não foi atribuído. O memorando original deixa essa fronteira clara, embora não prescreva um sistema de diagnóstico capaz de separar todas as causas.

Um endereço não configurava o host inteiro

O problema mais amplo de inicialização apareceu rapidamente. A RFC 950 cita o RARP como uma forma de um host recém-iniciado descobrir seu endereço de Internet e, em seguida, enumera outros dados que ele talvez precisasse: o endereço físico de um gateway, o IP de um servidor de nomes e a máscara de sub-rede. O texto considera preferível obter vários parâmetros em uma única solicitação a emitir várias difusões.

O BOOTP, especificado no ano seguinte, manteve a consulta de endereço físico para IP e também transportou mais informações de inicialização, inclusive um nome de arquivo opcional. Seu desenho permitia iniciar um host através de gateways. A RFC 951 compara explicitamente essa abordagem IP/UDP aos pacotes RARP de camada de enlace e às mudanças específicas de kernel ou driver necessárias para acessá-los. A RFC 1542 esclareceu depois o comportamento dos retransmissores BOOTP; a RFC 2131 descreve o DHCP como uma extensão do BOOTP que acrescentou alocação automática de endereços reutilizáveis e opções de configuração.

Essa sequência não prova que todas as redes abandonaram o RARP em uma data específica. Mostra que a pergunta mudou: descobrir um endereço previamente associado era útil, mas inicializar um host através de redes roteadas exigia uma troca mais ampla e um caminho de retransmissão.

Um registro não é a máquina

A Nota 72 de Heng Lu oferece uma lente analítica posterior, não uma fonte sobre 1984: um registro descreve a realidade, mas não a cria. O RARP não era um registro global, mas a distinção continua útil. A tabela do servidor coordenava uma associação local; não transformava o endereço devolvido em prova de propriedade do equipamento, identidade do usuário ou operação bem-sucedida.

A contribuição histórica do protocolo era mais estreita e prática. Ele permitiu que um host perguntasse ao enlace que já conseguia alcançar pelo único endereço necessário para começar a se comunicar com IP. Seu limite também era seu custo: as associações locais precisavam de manutenção, o silêncio não se explicava e a resposta não equivalia à configuração completa.

Fontes

RFC 903 — A Reverse Address Resolution Protocol; RFC 826 — An Ethernet Address Resolution Protocol; RFC 950 — Internet Standard Subnetting Procedure; RFC 951 — Bootstrap Protocol; RFC 1542 — Clarifications and Extensions for the Bootstrap Protocol; RFC 2131 — Dynamic Host Configuration Protocol. A Nota 72 é uma lente editorial posterior, não uma fonte histórica.