Resumo

  • A RFC 3925 permitiu que o DHCPv4 transportasse dados de mais de um fornecedor na mesma mensagem, com limites explícitos entre eles.
  • Ela registrou os números das opções externas, mas deixou os códigos e significados internos para cada fornecedor; um PEN identifica um espaço, não autentica uma declaração.

Por cerca de uma década, o caminho habitual para trocar informações específicas de fornecedores no DHCPv4 tinha uma forma estreita. A opção 60 da RFC 2132 permitia ao cliente enviar uma cadeia de classe do fornecedor; a opção 43 levava um objeto opaco definido por ele. O servidor interpretava a opção 43 no contexto indicado pela 60. Isso funcionava quando bastava o vocabulário de um fornecedor. Ficava ambíguo quando um dispositivo ou perfil industrial precisava incluir informações definidas de forma independente por vários fornecedores. A RFC 3925 trata de enquadramento, não de uma falha na atribuição de endereços do DHCP.

A resposta foi criar outro par de opções. A opção 124, Vendor-Identifying Vendor Class, e a 125, Vendor-Identifying Vendor-Specific Information, colocam um Private Enterprise Number da IANA junto aos dados de cada fornecedor. A opção 125 pode conter várias entradas: número da empresa, comprimento e bytes daquele fornecedor. O comprimento delimita os dados, e o número indica qual interpretação se aplica. A RFC 3925 mantém intactas as opções 60 e 43; uma implementação pode encontrar as formas antigas e as identificadoras na mesma troca.

Essa estrutura marca uma distinção de projeto. A IANA atribui o código externo da opção DHCP; seu registro Enterprise Numbers atribui o número que identifica o espaço do fornecedor. Nenhum dos registros define o significado da carga útil. Por dentro, as subopções usam campos de código, comprimento e valor, mas a RFC 3925 diz que os códigos são definidos pelo fornecedor e não são administrados pela IANA. A norma criou uma forma de manter vários dialetos separados, não um dicionário comum para traduzi-los.

O tamanho do pacote também impõe limites. Como os dados agregados podem exceder o comprimento máximo de uma opção, a RFC 3925 declara que 124 e 125 exigem concatenação conforme a RFC 3396. O receptor reúne as instâncias repetidas em uma opção lógica antes de interpretar as entradas; não deve tratar cada fragmento como um novo registro de fornecedor. A norma recomenda que cada número de empresa apareça só uma vez entre todas as instâncias. Se ele se repetir, o comportamento não é definido. O enquadramento admite múltiplos fornecedores, mas não dá sentido a toda combinação repetida ou malformada.

A RFC 3925 reutilizou o padrão das opções de classe e informação de fornecedores do DHCPv6, que a RFC 3315 já havia definido. Essa linhagem está documentada, mas não prova que os dois protocolos compartilhem semântica de carga útil ou implantação. A extensão tampouco autentica o fornecedor: a RFC 3925 não adiciona segurança; a RFC 3118 define um mecanismo separado de autenticação DHCP que pode ser usado quando a autenticidade for necessária. Um número dentro da opção é um seletor de espaço, não uma assinatura.

É por isso que a RFC 3925 importa como história: tornou as fronteiras explícitas para permitir coexistência, sem centralizar o significado local. O registro externo ajuda a interpretar o contêiner e identificar seu espaço. Não diz ao cliente o que um byte específico fará, se o dispositivo realmente pertence ao fornecedor indicado ou se determinada implementação aceita a opção. Essas afirmações exigem outras evidências. Os RFCs e registros da IANA demonstram o projeto e as atribuições dos códigos; não medem adoção, interoperabilidade nem resultados operacionais.

Fontes