Resumo

  • A RFC 3679 separou números de opções propostos que podiam ser recuperados dos códigos de PXE e Apple já usados, embora sem descrição em um RFC publicado.
  • A RFC 3942 definiu uma transição para códigos da faixa privada. Mais tarde, a RFC 8910 transferiu a sinalização de portal cativo do código 160 após um teste revelar o uso concorrente da Polycom. O registro mostra coordenação, não um censo de dispositivos instalados.

Uma bibliografia vazia não significava uma rede vazia

O DHCP transporta pequenos parâmetros durante a configuração de um endereço: máscara de sub-rede, endereço do roteador e outros dados de serviço. Os números de opção formam um espaço compartilhado. Se uma proposta abandonada mantiver seu código para sempre, sobra menos espaço para trabalhos futuros; se um código realmente implantado for reassinalado, dois dispositivos podem interpretar o mesmo campo de maneiras diferentes.

Em janeiro de 2004, a RFC 3679 tratou dos dois riscos. Ela listou atribuições anteriores cujas propostas expiraram, nunca chegaram a uma definição publicada ou já não eram usadas pelo protocolo de failover da época. Esses códigos poderiam voltar ao conjunto disponível da IANA. Mas outra seção dizia que as opções PXE 93, 94 e 97 eram amplamente usadas, apesar de não constarem de um RFC publicado. Também identificava usos da Apple para os códigos 95 e 112–114 sem documentação RFC. O documento pediu que essas atribuições fossem mantidas até que o grupo de trabalho DHC decidisse o que fazer. A evidência decisiva não era apenas a publicação: era o uso relatado. RFC 3679

Essa distinção não dizia que todo uso sem documentação merecia um número público permanente. A RFC 3679 expôs os motivos de recuperação caso a caso e tratou separadamente os usos conhecidos de PXE e Apple. Os códigos recuperáveis deveriam voltar à faixa disponível depois de esgotados os números nunca atribuídos ou já devolvidos. Era um memorando informativo, não uma prova de que cada implementação mencionada ainda existia nem de que toda atribuição estivesse resolvida no campo. Status da RFC 3679

De uma lista a uma transição

Ainda em 2004, a RFC 3942 ampliou o espaço de opções DHCPv4 definidas publicamente de 1–127 para 1–223, reclassificando a parte superior, antes reservada para uso privado. Isso não apagava configurações locais existentes. Por isso, o padrão criou uma transição: um código privado com uso conhecido poderia ficar indisponível enquanto fornecedores notificavam o grupo de trabalho e a IANA; uma atribuição pública provisória teria seis meses para notificação e dezoito meses para a apresentação de um Internet-Draft. Os sites foram orientados a migrar para a faixa privada restante. RFC 3942

A regra para colisões era mais dura. Se vários fornecedores demonstrassem uso razoavelmente amplo do mesmo número, nenhum poderia mantê-lo como código privado próprio; cada um teria de buscar uma atribuição pública normal. Isso não declarava ilegítimo o uso privado. Reconhecia que um número não coordena dois significados incompatíveis só porque cada fornecedor o usou localmente. A RFC 3942 também rejeitou uma extensão de 16 bits, que oneraria os primeiros adotantes, e um novo formato ou cookie mágico, que elevaria os custos de compatibilidade e descoberta.

O conflito posterior que tornou a diferença concreta

Mais tarde, a RFC 4578 descreveu as opções PXE 93, 94 e 97 como amplamente usadas, mas observou também que clientes PXE solicitavam os códigos 128–135, não oficialmente atribuídos para PXE e sujeitos a conflito com outros usos na mesma rede. A distinção é importante: um cliente solicitar um código não o transforma em atribuição oficial.

Um caso ainda mais claro surgiu com portais cativos. A RFC 7710 usou inicialmente a opção DHCPv4 160 para anunciar a URI do portal. Durante um teste na rede da IETF 106, alguns dispositivos Polycom usavam 160 para outros fins; ao carregar ali a URI do portal, eles não funcionaram como esperado. A RFC 8910 transferiu o sinal para a opção 114, atualizou a RFC 3679 e devolveu 160 ao estado “não atribuído”, registrando o uso conhecido da Polycom. Os autores descrevem um conflito observado naquele teste, não sua prevalência em todas as redes. RFC 7710 RFC 8910

A tabela atual da IANA mostra o destino posterior de alguns números: 83 passou a carregar iSNS; 88 e 89, opções BCMCS; 114 é Captive-Portal; e 96 continua sem atribuição. Os códigos 126 e 127 também aparecem como não atribuídos. Esses são estados do registro, não evidência de que nenhum equipamento em redes ativas emita esses valores. A atribuição posterior tampouco prova que todas as implementações anteriores desapareceram. Registro IANA BOOTP/DHCP RFC 4174 RFC 4280

A posterior Nota 72 de Lu Heng oferece um paralelo conceitual limitado: um registro de coordenação e a realidade operacional são tipos diferentes de evidência. O texto trata da coordenação da unicidade dos números da Internet, não da atribuição de opções DHCP, e não causou nem endossou essas decisões. A lição prática vem dos próprios RFCs: recuperar um número exige investigar seu uso, e reassinalá-lo é um processo de transição, não uma edição burocrática. Nota 72

Fontes

Contexto normativo adicional