Resumo

  • A RFC 2322 descreveu um método físico para distribuir endereços em uma rede temporária: cada prendedor de madeira representava um número IP, e os prendedores ainda não entregues formavam um conjunto visível.
  • O objeto tornava o estado da alocação observável, mas uma pessoa ainda o distribuía e copiava o endereço e as configurações comuns para o computador. O relato de campo da própria RFC diz que alguém confundiu o endereço do roteador padrão com o seu e interrompeu a rede por algum tempo.

A RFC 2322 não é um padrão DHCP. Publicada em 1º de abril de 1998 como um documento informativo, ela descreve o “peg-DHCP” para redes de campo e pequenos eventos sem uma organização administrativa definida. O relato começa no Hacking In Progress, encontro de três dias realizado nos Países Baixos em 1997. Os organizadores esperavam computadores variados e precisavam de uma LAN TCP/IP com acesso à Internet. Preocupavam-se com números duplicados ou pulados e com um servidor de software que talvez não funcionasse em diferentes pilhas IP. A RFC registra essa motivação; não comprova que o DHCP convencional falhou.

A proposta tornava uma parte da administração concreta. Um prendedor representava um endereço. Os prendedores disponíveis, pendurados em um varal, formavam o conjunto livre; um prendedor preso perto do cabo de rede de um computador indicava onde o endereço estava em uso. Cores diferentes podiam separar sub-redes. Em um evento curto, o ponto de distribuição podia ser uma barraca ou mesa com alguém responsável, ou os participantes podiam retirar os prendedores por conta própria, se houvesse menos controle. Uma ficha ou aviso mostrava parâmetros comuns, como rede, máscara, gateway e proxy.

A pessoa então digitava esses valores no computador e nos aplicativos necessários.

Essa última etapa é fundamental. O peg-DHCP não configurava a interface, não negociava uma concessão e não verificava a identidade de quem recebia o endereço. Ele deslocava parte do registro de alocação do estado invisível de um servidor para um objeto que podia ser visto e movido. A pessoa continuava sendo o adaptador entre o prendedor, o papel e o sistema operacional. A RFC reconhece que a transcrição podia perder ou corromper dados e apresenta um caso concreto: durante o encontro, alguém configurou o endereço do roteador padrão como seu próprio endereço, deixando a rede inutilizável por um período.

O ciclo de vida também era local. Quando não precisava mais do endereço, o cliente podia devolver o prendedor ao conjunto. Se não houvesse atendente, teria de colocá-lo de volta por conta própria. O fim do evento podia servir como um TTL aproximado, já que os endereços deixariam de valer depois do encontro. Isso não equivale às trocas de concessão do DHCP, em que cliente e servidor comunicam alocação, renovação, rebinding e expiração. A diferença não é “manual é ruim, automático é bom”; é entre custódia visível e decisão humana, de um lado, e estado de protocolo e troca de mensagens, de outro.

A seção de segurança da RFC delimita o mecanismo: um prendedor podia se perder e ser usado por quem o encontrasse; tanto o objeto quanto o papel com os dados comuns eram legíveis. O documento recomenda não compartilhar informações privadas por esse meio. O prendedor representava uma alocação, não provava a identidade de alguém nem autenticava seu direito de usar o endereço. A sugestão de transportar o prendedor em um portador aviário é explicitamente experimental, não uma afirmação de implantação.

O valor histórico da RFC 2322 é mais restrito e interessante que sua premissa humorística: em um ambiente delimitado, transformou um conjunto invisível em estado visível e inspecionável, enquanto expunha o papel da entrega humana. A visibilidade podia ajudar a perceber se um número estava em uso, mas não impedia que alguém digitasse o endereço errado em uma máquina.

Fontes