Resumo

  • RFC 1931 descreveu vários servidores Dynamic RARP como redundância de disponibilidade, exigindo ao mesmo tempo que todos os servidores do segmento consultassem uma única autoridade lógica de endereços.
  • O cadastro podia estar consistente e ainda assim desatualizado: uma sondagem ARP ou ICMP antes da alocação verificava se um endereço registrado como livre já aparecia em uso.
  • Publicado em abril de 1996 como Informational e hoje classificado como Legacy, o texto registrou um mecanismo usado em certas plataformas Sun desde 1988; não criou um padrão nem prova que DRARP tenha originado DHCP.

Quando o silêncio acumulava cinco hipóteses

O RARP de RFC 903 partia de uma máquina que sabia seu endereço de hardware e precisava descobrir o endereço de protocolo. Ela fazia broadcast; um ou mais servidores com tabelas de correspondência podiam responder. Não existia resposta negativa, porque o desconhecimento de um servidor não autorizava falar pelos demais.

Para uma instalação sem operador, essa cautela deixava uma pergunta aberta demais. Nenhuma resposta podia significar perda, servidor indisponível, máquina sem cadastro, segmento errado ou ausência total do serviço. Repetir com recuo exponencial controlava o volume, mas não dizia quando desistir.

O cenário ainda dependia de preparação humana. A rede IP e o sistema de nomes já precisavam estar configurados. Conseguir um endereço não garantia o registro do nome, a reserva de arquivos de inicialização, a entrega de chaves ou a definição de uma senha inicial.

RFC 1931 registrou o Dynamic RARP como resposta a esse ponto específico. A extensão manteve o formato RARP e acrescentou uma solicitação, uma resposta temporária e um erro. Havendo vínculo permanente, vinha REVARP_REPLY. Sem ele, a autoridade podia criar um vínculo temporário e devolver DRARP_REPLY, ou usar DRARP_ERROR para separar restrição de política, falta de endereços, indisponibilidade da autoridade, mudança de segmento e falha não classificada.

Dar nome à falha não autenticava quem respondia nem comprovava a causa, mas criava consequências operacionais distintas. Uma restrição vigente não se resolve com nova tentativa imediata; uma autoridade temporariamente fora do ar talvez sim.

O contexto histórico consta na ficha do RFC Editor: Informational, no fluxo Legacy, sem estabelecer padrão da Internet. O mecanismo tinha sido usado em determinadas plataformas da Sun Microsystems a partir de 1988. Quando o documento saiu, em abril de 1996, essas plataformas já não eram vendidas e o DHCP já cobria parte da função. O valor do texto é documental, não normativo.

Alta disponibilidade não concedia novas versões da verdade

Quando vários servidores recebiam o mesmo pedido, as respostas não podiam divergir, exceto nos campos do próprio servidor remetente. Divergência era erro de protocolo. A regra transformava várias máquinas num único serviço coerente.

Colocar um servidor por segmento diminuía o custo de uma partição. Ter mais de um reduzia a exposição a falha de máquina ou cabo. Mas todos precisavam conversar com a mesma autoridade. A implementação descrita usava NIS e um serviço RPC centralizado chamado IPalloc, alterado apenas por agentes autorizados, como administradores e servidores DRARP. O RFC não padronizou esse protocolo nem as escolhas de segurança.

A autoridade mantinha vínculos permanentes, temporários e o conjunto disponível. Criava, procurava, removia e expurgava; enfrentava pedidos simultâneos e aplicava autorização. Havia uma autoridade por segmento em termos lógicos. Ela poderia ser fisicamente repartida, com custo administrativo e técnico considerável.

Por isso, contar servidores não mede descentralização. A camada de resposta tinha redundância. O ponto em que a alocação ganhava validade continuava singular. Uma frota pode tornar uma decisão errada mais disponível, sem torná-la correta.

O cadastro precisava perguntar ao mundo que pretendia ordenar

O próprio RFC alertava que uma base administrativa podia marcar como livre um endereço efetivamente usado. A alocação deveria então consultar a rede ativa; a implementação recorria a ARP e ICMP Echo.

RFC 826 define ARP como distribuição sob demanda de correspondências entre endereços de protocolo e de hardware. Uma resposta é evidência local, naquele momento, de uma alegação de uso. Não comprova proprietário, autorização nem exclusividade futura. Silêncio também não afasta perda, isolamento ou um equipamento que não respondeu.

O identificador de hardware, o vínculo reconhecido pela autoridade e a observação da sonda dizem coisas diferentes. Para reconhecer uma máquina deslocada entre segmentos, as autoridades precisavam ser iguais ou comunicar-se, e o identificador precisava ter alcance suficientemente amplo. Mesmo assim, o valor de enlace não autenticava dono ou usuário.

Servidores DRARP podiam ouvir anúncios de outros servidores e relatar um respondedor aparentemente não coordenado antes de entrar em modo restrito. Não havia, porém, protocolo de julgamento entre eles. Detectar uma possível anomalia era produzir evidência; decidir quem era espúrio continuava sendo questão da autoridade ou da administração.

A expiração administrava escassez, não sucesso

O vínculo temporário tinha de durar o bastante para a instalação e a propagação dos registros sobreviverem a falhas. O texto informa que uma hora de cache bastou na implementação inicial. Não a transforma em prazo universal. Expirar libera o pool; não confirma que a máquina concluiu as etapas seguintes.

O DHCP posterior organizou o compromisso de modo diferente. RFC 1541 explicitou ofertas múltiplas, seleção pelo cliente, identificador de servidor e lease finito. RFC 2131 refinou a sequência e permitiu que o cliente recusasse um endereço após detectar uso local. A comparação é de arquitetura; não há base para dizer que DRARP causou esses textos.

Outra família resolveu apenas o escopo do enlace. RFC 3927 permite que um host escolha, sonde, anuncie e, em certas condições, defenda um endereço IPv4 link-local. O endereço não é roteável e não sustenta identidade durável. RFC 5227 generaliza a detecção de conflito com ARP Probes e Announcements. O resultado continua local e temporário, limitado por partições, simultaneidade e respondentes maliciosos.

O contrato mínimo entre registro e execução

A lente de Running-Code Primacy, de Heng Lu, mostra por que a sonda importa. O cadastro tinha autoridade simbólica para coordenar; a atividade no cabo podia contradizê-lo. Consultar a execução não anulava a política, apenas impedia que uma política desatualizada se convertesse automaticamente em colisão.

Minimum Initial Specification aponta para um núcleo compartilhado pequeno e rigoroso: respostas coerentes, falhas distinguíveis e estado temporário preservado até que dependências possam convergir. NIS, RPC, duração exata e política local ficavam substituíveis.

Pelas camadas de realidade, o cadastro coordena, a resposta configura e a sonda contesta. Cada camada tem força própria. O mérito histórico de RFC 1931 está em não chamar várias caixas de várias autoridades — e em não chamar um cadastro coerente de realidade completa.

Fontes

  1. RFC 1931 — Dynamic RARP Extensions for Automatic Network Address Acquisition
  2. RFC Editor — registro atual de RFC 1931
  3. RFC 903 — A Reverse Address Resolution Protocol
  4. RFC 826 — An Ethernet Address Resolution Protocol
  5. RFC 1541 — Dynamic Host Configuration Protocol
  6. RFC 2131 — Dynamic Host Configuration Protocol
  7. RFC 3927 — Dynamic Configuration of IPv4 Link-Local Addresses
  8. RFC 5227 — IPv4 Address Conflict Detection
  9. Heng Lu — Running-Code Primacy
  10. Heng Lu — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  11. Heng Lu — On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile