Resumo

  • O RFC 3396 tratou ocorrências repetidas de um código DHCPv4 como fragmentos sequenciais de um valor lógico, por causa do limite de 255 octetos ou da falta de espaço em um campo sobrecarregado.
  • A remontagem obedecia à ordem lógica options, file, sname, diferente da ordem física. O corte não tinha semântica e um envio correto não provava que o receptor instalado soubesse reconstruí-lo.

O pacote trazia duas ordens. Uma era herdada do formato BOOTP: onde os campos estavam fisicamente. A outra dizia como juntar o conteúdo quando DHCP reutilizava esses campos para opções. RFC 3396 tornou obrigatório conhecer a segunda antes de atribuir significado aos bytes.

Publicado em novembro de 2002 na trilha de padrões, o texto partia de uma limitação de um byte. A opção variável tinha um octeto de código, um de comprimento e até 255 octetos de valor. Um objeto maior não cabia em uma única ocorrência.

RFC 2131 já mencionava concatenar opções repetidas, mas não completava sua ordenação e ainda dizia que uma opção só apareceria uma vez salvo regra específica. RFC 3396 eliminou essa frase. Repetir o mesmo código passou a indicar partes de uma opção a serem unidas antes do processamento.

Nem toda divisão vinha de um valor longo. Uma opção menor podia não caber no espaço restante da área atual, embora outro campo tivesse capacidade. O codificador então aplicava o algoritmo ou não enviava a opção. Uma ocorrência não podia atravessar diretamente a fronteira entre campos.

DHCP usava a área normal de parâmetros e, com option overload, podia transformar file e sname em áreas de opções. O RFC definiu um buffer agregado conceitual: primeiro options, depois file, por fim sname. Advertiu que essa sequência não era a ordem física dos campos no pacote.

Cada fragmento mantinha o mesmo código, era codificado como opção comum e levava no máximo 255 octetos de valor. A soma dos comprimentos produzia o total. Um analisador que simplesmente percorresse a estrutura em memória podia trocar a posição de fragmentos perfeitamente válidos.

O corte podia ocorrer em qualquer fronteira de octeto. Logo, não podia representar fim de nome, rota, registro ou subopção. Era apenas uma costura de contêiner. Dar significado à posição do corte inventava informação que o emissor estava proibido de comunicar dessa forma.

Ao receber repetições, o decodificador reunia os valores na ordem agregada e tratava o resultado como um objeto. Não devia analisar cada fragmento separadamente. Também precisava resolver seu próprio alinhamento de memória: o emissor não escolheria cortes convenientes para a arquitetura do receptor.

O exemplo de Bootfile Name partia /diskless/foo em duas ocorrências da opção 67. Nenhum pedaço era um nome de boot independente. A simplicidade mostrava que o mecanismo não dependia de tamanho extremo; dependia de preservar unidade lógica.

A advertência operacional era mais importante que o exemplo. Muitos agentes DHCP já instalados não implementavam concatenação. Um emissor em plena conformidade podia encontrar quem lesse apenas a primeira parte, tratasse as ocorrências como objetos ou descartasse o valor. Conformidade de envio não era recibo de recepção.

O documento criou categorias: opções que exigiam concatenação e opções que não exigiam. A primeira só existia quando sua própria especificação citava RFC 3396 e tornava o mecanismo obrigatório. O emissor deveria evitar dividir, salvo necessidade, evidência da capacidade do par ou configuração administrativa explícita.

Ter solicitado ou fornecido uma opção da categoria obrigatória permitia presumir capacidade. Era um sinal limitado, não garantia de todos os tamanhos e caminhos. Uma implementação podia nunca dividir opções comuns; porém, ao suportar uma opção obrigatória, tinha de concatenar na recepção repetições das duas categorias.

A opção de autenticação do RFC 3118 também podia ser fragmentada. Ao zerar o campo de autenticação para gerar ou verificar o MAC, o software precisava encontrá-lo mesmo atravessando ocorrências. Calcular sobre recipientes separados em vez do objeto lógico podia autenticar uma representação errada.

RFC 3397, RFC 3361, RFC 3442 e RFC 3925 levaram busca de domínios, proxies SIP, rotas sem classe e estruturas de fornecedor sobre essa base. Cada um definiu sua gramática. RFC 3396 definiu como entregar à gramática um único fluxo de valor.

Uma captura com todos os fragmentos ainda não prova que o cliente reconheceu overload, respeitou a ordem agregada, guardou repetições, lidou com alinhamento, autenticou e aplicou a configuração. Cada passagem precisa de evidência própria.

A busca atual de erratas não apresenta item para RFC 3396. Isso descreve o registro editorial, não o código. O documento existiu justamente porque texto anterior e implantação real não convergiam sozinhos.

O princípio da especificação inicial mínima de Lu Heng explica por que foram fixados código, ordem, continuidade e ausência de semântica na divisão, sem impor buffers internos. A primazia do código em execução exige testar cortes ruins, os três campos e o efeito final.

RFC 3396 separou endereço físico de identidade lógica. Os fragmentos não pediam uma interpretação mais esperta. Pediam contenção: recuperar o objeto inteiro antes de acreditar que qualquer pedaço dissesse alguma coisa.

Fontes