Resumo

  • A opção 52 declara quando file, sname ou ambos passam a carregar opções DHCP. O reaproveitamento é explícito e limitado à mensagem, não uma interpretação por adivinhação.
  • Os 192 bytes brutos desses campos também precisam acomodar códigos, comprimentos, terminadores e outras informações. Mais capacidade não elimina fronteiras nem cria uma mensagem ilimitada.
  • Dividir um valor e tomar campos emprestados são mecanismos distintos. RFC 3396 manda reunir os dados na ordem lógica options, file, sname, que não é a ordem física do pacote.

A conta que não cabe inteira na carga útil

Um campo de 128 bytes e outro de 64 parecem oferecer uma expansão simples: mais 192 bytes para configuração. Mas essa soma mede posições disponíveis, não dados úteis garantidos. Cada item precisa de identificação e comprimento; cada área precisa terminar corretamente; informações antigas talvez precisem ser representadas em outro lugar.

O ganho de espaço de DHCP Option Overload deve ser entendido assim. O protocolo não encontrou uma reserva sem custo nem tornou o pacote extensível sem limite. Ele autorizou uma mudança de uso em campos existentes, desde que o receptor pudesse saber que a mudança havia ocorrido.

A diferença importa porque a pressão por capacidade costuma aparecer antes da pressão por interpretação. Um transmissor consegue preencher um espaço vazio. O destinatário ainda precisa descobrir o que aqueles bytes representam, onde cada item acaba e como reunir partes que foram separadas apenas para caber.

Os campos antigos faziam um trabalho real

No BOOTP de RFC 951, publicado em setembro de 1985, uma máquina podia obter endereço, servidor e arquivo de inicialização antes de ter seu ambiente completo disponível. O formato fixo reservava lugares para essas informações.

sname ocupava 64 octetos para um nome opcional de servidor, e file ocupava 128 para o nome do arquivo de inicialização. Ambos eram cadeias terminadas em zero. Uma área vend de 64 octetos permitia informações específicas de fornecedor.

Essas posições facilitavam o trabalho de programas pequenos de inicialização. Não eram campos sem significado esperando uma aplicação futura. Reutilizá-los exigia preservar a possibilidade de transportar os dados para os quais haviam sido criados.

DHCP conservou a estrutura e ampliou a configuração. RFC 2131, de março de 1997, tornou options variável e exigiu que clientes recebessem uma área de opções de pelo menos 312 octetos. Negociar mensagens maiores era outra possibilidade. Nada disso deve ser confundido com o limite de 255 bytes de dados em uma instância convencional de opção.

A declaração precisava ficar fora do espaço emprestado

Option Overload já estava no RFC 1533, de outubro de 1993. Seu código é 52 e o dado tem um octeto: 1 seleciona file, 2 seleciona sname e 3 seleciona ambos. Portanto, o mecanismo não nasceu com o documento de opções longas de 2002.

A declaração vale para os campos indicados naquela mensagem. Não dá permissão geral para tratar qualquer sequência desconhecida como opções nem muda permanentemente o significado dos próximos pacotes. Uma área não selecionada fica fora do conjunto que será interpretado dessa forma.

RFC 2131 exige que a declaração apareça na área options normal. O receptor a interpreta primeiro, depois lê file se habilitado e, por fim, sname se habilitado. Ele não precisa procurar uma autorização dentro de um campo que ainda não sabe se está autorizado a interpretar como opções.

Essa regra separa a escolha local do formato comum. O transmissor escolhe usar capacidade adicional, mas não escolhe sozinho como o outro lado deve descobrir isso. A mudança precisa ser anunciada no ponto de entendimento que já existe.

A parede continua valendo depois do empréstimo

A área normal começa com um magic cookie de quatro octetos. Depois vêm os itens identificados por código. Uma opção variável típica tem código, comprimento e os dados correspondentes. O comprimento não inclui os dois octetos de cabeçalho. Pad e End são exceções de um só octeto.

Em file ou sname reaproveitado, as opções começam no primeiro byte do campo. Não se acrescenta outro cookie. Cada área usada termina com End e preenche o restante com Pad. Uma instância codificada precisa caber integralmente no campo onde foi colocada.

Não basta que haja espaço no campo seguinte para permitir um transbordamento físico. E um End encontrado em uma área não manda ignorar todas as outras áreas declaradas. O término de um recipiente e o término do conjunto lógico são limites diferentes.

É por isso que a soma de 192 bytes não pode ser anunciada como 192 bytes livres. Além de cabeçalhos e preenchimento, a declaração e os nomes deslocados também têm custo. O mecanismo reutiliza capacidade finita; não redefine o tamanho de toda a mensagem e não é fragmentação IP.

O arquivo deixa a caixa, não a configuração

RFC 2132, publicado em março de 1997, define a opção 66 para o nome do servidor TFTP quando sname é usado para opções, e a opção 67 para o arquivo de inicialização quando file tem esse novo uso.

O parâmetro pode, assim, sair da posição fixa e passar para uma representação com etiqueta. Um programa que só procura texto legível em file pode confundir mudança de lugar com ausência. A informação não precisa desaparecer para que seu antigo espaço seja ocupado.

O registro BOOTP/DHCP de IANA lista 52, 66, 67 e o posterior Domain Search, 119. São códigos de opções, não portas de transporte. A coincidência entre a opção 67 e a porta UDP usada pelo servidor DHCP não une seus significados.

O registro também não comprova que um arquivo exista, que seja acessível ou que deva ser executado. Ele permite reconhecer o tipo de informação enviado. A obtenção efetiva do arquivo e a autoridade para usá-lo pertencem a outras etapas.

Dois motivos para dividir uma opção

Uma opção pode ter dados maiores que os 255 octetos representáveis por um byte de comprimento. Também pode ser curta e não caber no espaço restante da área atual, embora haja capacidade em outra área habilitada. O primeiro problema é de representação da extensão; o segundo é de distribuição do espaço.

RFC 3396, de Ted Lemon e Stuart Cheshire, tratou dos dois em novembro de 2002. Também retirou explicitamente a frase de RFC 2131 que restringia a repetição de uma opção por padrão, esclarecendo como várias ocorrências devem contribuir para um valor.

Cada parte leva o mesmo código e seu próprio comprimento. A soma dos dados forma o tamanho total. O receptor concatena esses dados sem incluir os códigos e comprimentos, não escolhe apenas a primeira ou a última ocorrência e não interpreta as partes como objetos separados.

O exemplo do documento é um caminho de apenas treze bytes, /diskless/foo, dividido em sete e seis. O corte acontece dentro de diskless. Não há significado nessa divisão: ela não cria dois arquivos nem segue necessariamente um componente de diretório. O emissor pode dividir em qualquer fronteira de octeto; cabe ao receptor recuperar o todo antes de interpretar.

Tomar campos emprestados e concatenar partes não são sinônimos. Uma área reaproveitada pode guardar opções inteiras. Um valor dividido pode caber em várias ocorrências dentro de options, sem usar os campos antigos. Uma técnica define lugares; a outra define reconstrução.

A ordem lógica contraria a aparência do pacote

Na disposição física herdada, sname aparece antes de file, e ambos antes de options. O agregado definido para reconstrução segue outra ordem: options, file, sname. Áreas não escolhidas para o reaproveitamento ficam excluídas.

Não se movem os campos na rede. O que se estabelece é uma sequência de interpretação. Um analisador que varra os bytes do início ao fim e concatene imediatamente todas as ocorrências pode produzir uma ordem incorreta quando as partes ocupam campos diferentes.

Primeiro é preciso descobrir a declaração, depois montar a sequência lógica das áreas permitidas e então reunir os dados de cada código. Isso impede que uma decisão incidental de implementação determine o conteúdo da configuração.

Cada parte ainda permanece dentro de seu campo. A abstração de um agregado não autoriza esquecer a geometria física que tornou necessário dividir o valor. O protocolo coordena dois mapas: onde os bytes ficam e em que ordem passam a significar uma coisa só.

O destinatário antigo não era atualizado pela especificação

RFC 3396 registrava que muitos agentes DHCP implantados na época não faziam concatenação. Por isso, recomendava não dividir sem necessidade ou sem saber que o destinatário conseguiria reunir as partes. Essa observação é de 2002 e não mede o parque atual.

A capacidade poderia ser presumida se o interlocutor fornecesse ou solicitasse uma opção cuja definição exigisse concatenação, ou se o administrador configurasse explicitamente essa hipótese. Não se tratava de um novo sinal universal de negociação.

Uma implementação podia evitar a divisão de opções comuns. Mas, ao suportar uma opção que exigisse concatenação, precisava conseguir reunir também outras opções recebidas em partes. Escolher uma saída mais simples não dispensava compreender uma entrada válida mais complexa.

A responsabilidade ficava distribuída. O emissor avaliava a necessidade e a compatibilidade do seu empacotamento. O receptor seguia a regra comum de reconstrução. A presença de um novo RFC não transformava automaticamente as rotinas instaladas em leitores desse novo acordo.

Um deslocamento que só faz sentido no conjunto

RFC 3397, do mesmo mês, oferece um exemplo concreto com a opção de pesquisa de domínios DNS, código 119. A lista pode ocupar várias ocorrências e usa compressão de nomes para economizar sufixos repetidos.

Os ponteiros se referem ao bloco completo de dados concatenados. Não incluem os códigos e comprimentos de cada parte, não se medem a partir do início do pacote DHCP e não reiniciam sua origem em cada fragmento.

Portanto, a montagem lógica precisa vir antes da interpretação dos nomes. Uma parte que termina no meio de um rótulo não é necessariamente um nome completo inválido; ainda não é o objeto completo. O limite relevante só aparece depois da reconstrução.

O caso mostra a dependência entre camadas de sintaxe, sem exigir repetir toda a história da compressão DNS. Um erro na ordem das partes muda o sistema de coordenadas usado para ler os dados, mesmo que os comprimentos individuais pareçam aceitáveis.

Reconstruir corretamente tampouco autentica a configuração. RFC 3397 observa que uma lista de pesquisa pode levar um nome curto a outro domínio completo mesmo quando os registros desse outro domínio têm assinaturas válidas. A forma correta de uma opção não decide quem pode escolher seu significado para o usuário.

Os bytes emprestados valeram porque vieram acompanhados de regras que tornavam seu uso reconhecível. A ampliação não apagou as fronteiras antigas: ensinou os participantes a combinar espaços limitados sem confundir posição, extensão e sentido.