Resumo

  • A RFC 1048 colocou 99.130.83.99 no início do campo de fornecedor do BOOTP para selecionar uma gramática comum. Tags e comprimentos permitiam ao cliente interpretar opções conhecidas e saltar as desconhecidas sem perder a fronteira seguinte.
  • Um cookie válido não autenticava o servidor nem tornava correto um roteador ou servidor DNS anunciado. O campo de 64 octetos organizava representação, alocação e compatibilidade; a autoridade continuava fora dele.

O cliente descrito na RFC 951 começa com poucos fatos. Ele pode saber o endereço de hardware e executar um programa de bootstrap, mas ainda não conhece seu endereço IP, um servidor disponível ou o arquivo que precisa carregar. O BOOTP trata da primeira etapa; outro protocolo transfere o arquivo depois.

O pacote reservava 64 octetos no campo vend. Era uma oportunidade para devolver máscara, gateway e outros parâmetros, porém a qualificação “específico de fornecedor” deixava o significado dependente do fabricante. A RFC 951 aconselhava abrir os dados usados com um número mágico de quatro bytes para identificar o tipo de informação. Faltava um modo compartilhado de percorrer o que vinha em seguida.

Em fevereiro de 1988, a RFC 1048 preservou o envelope e normalizou seu interior. A decisão não buscou resolver toda a configuração no primeiro pacote. Ela criou uma fronteira pequena o bastante para implementações diferentes concordarem sobre leitura, extensão e término.

Os quatro octetos selecionam um leitor

O magic cookie é 99.130.83.99 em decimal, ou 63.82.53.63 em hexadecimal, transmitido na ordem de bytes da rede. A RFC 1048 diz que ele identifica o modo em que os dados posteriores devem ser interpretados.

Ao encontrá-lo, um cliente escolhe a gramática da RFC em vez de um arranjo privado. Isso não revela a identidade do emissor. O valor é público, não contém segredo e pode ser copiado por qualquer servidor. Tampouco prova que um relay preservou o conteúdo ou que o operador tem direito sobre o gateway anunciado.

O Transaction ID, o endereço de hardware e os endereços do BOOTP ajudam a relacionar a resposta à solicitação e a entregá-la. Correlação é útil, mas seu escopo é outro. Uma resposta pode parecer pertencer à tentativa pendente e ainda vir de uma fonte não autorizada.

A RFC 1542 tornou esse risco explícito. O BOOTP não dispõe de autenticação razoável, e um servidor ilegítimo pode fornecer endereço IP, roteador e DNS falsos. O pacote malicioso não precisa violar uma única regra de tag ou comprimento.

O comprimento limita o que o receptor não sabe

Depois do cookie, a opção ordinária contém um octeto de tag, um de comprimento e o número indicado de octetos de valor. O comprimento não inclui os dois primeiros. Números maiores usam a ordem de rede.

Essa estrutura permite que versões diferentes convivam. Se o receptor conhece a tag, interpreta o valor. Se não conhece, avança pelo comprimento declarado e procura a próxima. Uma novidade deixa de ser um buraco sem borda no pacote.

O resultado é uma compatibilidade baseada em ignorância controlada. Um cliente antigo não precisa fingir que entende a extensão nova, e um servidor não precisa mudar a versão do envelope para toda opção registrada. Ambos mantêm a capacidade de encontrar o que compartilham.

O comprimento não atesta conteúdo. Uma opção local pode ter sentidos diferentes em redes distintas. Um endereço com o tamanho certo pode estar obsoleto. Um parser que localiza a fronteira ainda pode ter erros de memória. A RFC 1084 e a RFC 1497 alteraram o catálogo e mantiveram o formato; isso mostra estabilidade da moldura, não uniformidade das implementações.

Pad e End controlam a ausência de leitura

A tag 0, Pad, ocupa apenas um octeto e não traz comprimento. Serve para alinhamento ou espaço não usado. A tag 255, End, também ocupa um octeto e encerra a sequência; os bytes restantes são preenchidos com zeros.

Essas duas exceções são instruções ao parser. Procurar um comprimento depois de Pad deslocaria a leitura. Continuar depois de End transformaria preenchimento em opções imaginárias. A extensibilidade depende de uma forma inequívoca de parar.

Também há ordem obrigatória em um caso importante. Quando máscara e gateway aparecem, a máscara deve vir antes. O cliente precisa saber a extensão da rede local para interpretar a rota. As tags separam os campos fisicamente, mas não eliminam uma dependência semântica.

Portanto, a gramática não se reduz a “tag, length, value”. Ela inclui a escolha inicial, as exceções sem comprimento, o término, o preenchimento e relações de ordem. É essa combinação que permite leitura comum.

O teto transforma adição em escolha

O cookie consome quatro dos 64 octetos. Cada opção ordinária gasta dois antes de começar seu valor. Um endereço IPv4 ocupa mais quatro, e uma lista multiplica o custo. A RFC 1048 exige que nada ultrapasse vend e recomenda que informações não essenciais sejam obtidas por outro serviço.

Assim, cada inclusão compete com outra. Máscara, roteadores, servidores de nome, hora e registro podem ser úteis, mas o primeiro pacote não comporta um inventário ilimitado. O padrão atribui representações; a operação decide as prioridades.

Os códigos genéricos também são recursos compartilhados. A RFC pede registro para campos de uso geral, evitando colisão entre definições públicas. As tags 128 a 254 permanecem específicas do local. Elas abrem espaço para adaptação privada, mas seu sentido vale apenas onde existe o acordo correspondente.

O desenho reduz o custo de acrescentar itens e aumenta o custo de abandonar o contêiner. Quando firmware, clientes e servidores dependem da mesma moldura, uma nova tag é mais barata do que uma nova gramática. A própria compatibilidade produz uma forma de lock-in na borda de 64 octetos.

Uma base eficiente ainda pode estar errada

A RFC 1048 contrasta o banco central do BOOTP com formas distribuídas de descoberta. Se uma resposta contém tudo o que o cliente precisa, a operação é eficiente: há menos consultas e o programa pode seguir usando uma tabela local. Entretanto, o documento reconhece que a informação centralizada pode estar incompleta ou desatualizada.

O administrador do banco controla os valores que o BOOTP local publica. Esse controle não comprova a identidade do servidor de arquivos nem a integridade da imagem carregada. A RFC afirma que o banco BOOTP não basta para autenticação forte do file server; a verificação pertence ao serviço em questão.

Uma inicialização mistura, então, fatos diferentes: o pacote tem gramática reconhecida; corresponde a uma tentativa; veio por determinado caminho; aponta para certo serviço; o serviço realizou ou não sua própria autenticação. Chamar tudo de “cookie válido” apaga a etapa em que a decisão falhou.

A RFC 1542 recomenda que mesmo um cliente sem opções envie cookie, End e zeros. O objetivo é informar ao servidor qual formato usar na resposta. Trata-se de uma declaração de sintaxe quase vazia, não de uma credencial.

O DHCP recebeu a moldura, não a confiança

A RFC 1533 usa nas opções DHCP o formato de extensões do BOOTP: tag, comprimento e valor, com Pad e End como exceções. Mantém cookie, ordem de rede e faixa específica de local. A RFC 2132 registra depois um catálogo DHCP maior dentro dessa linhagem.

A continuidade está documentada no formato. Não permite supor que toda prática posterior do DHCP já existia nas redes de 1988, nem que cada opção conservou sua semântica. A própria RFC 1533 declara que não discute segurança. O recipiente passou adiante sem adquirir prova de origem.

O avanço da RFC 1048 foi estabelecer um acordo cujo alcance podia ser cumprido. Quatro octetos indicavam a leitura; comprimentos preservavam fronteiras; Pad e End disciplinavam o percurso; o limite forçava prioridade. Identidade, atualidade, autorização e resultado continuavam sob outras decisões.

Fontes e limites de evidência

A RFC 951 descreve o BOOTP original, o campo de 64 octetos e o número mágico. A RFC 1048 define cookie, gramática, ordem, alocação e tamanho. A RFC 1084 e a RFC 1497 registram revisões do BOOTP. A RFC 1533, a RFC 1542 e a RFC 2132 mostram a continuidade no DHCP e a fronteira de segurança.

Essas fontes provam especificações e mudanças documentais. Não medem adoção histórica, não descrevem uma rede particular e não garantem que toda implementação tenha tratado opções desconhecidas com segurança.