Resumo

  • O RFC 5192 exige que o conteúdo da opção PAA de DHCPv4 tenha comprimento múltiplo de quatro e que o de DHCPv6 tenha comprimento múltiplo de dezesseis. Quando a conta não fecha, a evidência correta é falha de validação, não uma lista “aproveitável” criada por truncamento silencioso.
  • Uma lista válida ainda é apenas uma sequência de candidatos. A ordem governa qual endereço o PaC deve tentar primeiro; não atesta saúde, identidade, disponibilidade nem sucesso posterior de PANA.

Formatos compactos parecem convidar tolerância. Se oito bytes já formam dois endereços IPv4, por que não ignorar os dois bytes que sobraram? Porque o resultado deixa de ser a mensagem recebida e passa a ser uma mensagem inventada pelo parser.

O RFC 5192 escolhe uma regra simples. A opção 136 de DHCPv4 carrega endereços de 32 bits e seu comprimento deve ser múltiplo de quatro. A opção 40 de DHCPv6 carrega endereços de 128 bits e o comprimento deve ser múltiplo de dezesseis. A divisibilidade é o que permite localizar todas as fronteiras sem adivinhação.

O documento não oferece uma rotina de reparo para resíduos. Não autoriza completar com zeros, cortar o final ou publicar as entradas anteriores como se toda a opção fosse válida. Se uma implementação adota recuperação local, precisa declará-la como política própria e conservar a falha original.

Validar antes de dar significado

O recibo começa pelo código da opção, comprimento declarado, número de bytes capturado, conteúdo bruto e versão do validador. Só depois de a estrutura passar é que a plataforma pode extrair endereços e posições.

Esse encadeamento impede três estados diferentes de colapsarem. Ausente significa que a mensagem não trouxe a opção. Inválida significa que dados chegaram, mas não obedeciam ao formato. Válida e vazia exigiria uma representação permitida que o operador pudesse demonstrar; não deve ser presumida a partir de erro.

Os sintomas podem coincidir: nenhum PAA utilizável. A causa, o risco e o dono da correção não coincidem. Ausência pode acionar outra forma de descoberta. Invalidez pode indicar corrupção, implementação defeituosa ou manipulação. Truncá-la remove justamente o sinal que separa essas hipóteses.

Também não basta registrar “parse warning”. Se a automação ainda executou os endereços fabricados, o sistema tomou uma decisão material. O log deve ligar input inválido, política de recuperação, candidatos derivados e tentativas resultantes.

Uma lista válida tem ordem, não saúde

Depois da validação, as entradas aparecem por ordem de preferência. O PaC deve tentar os registros na ordem recebida. A regra impede que um cliente trate a opção como um saco de endereços, mas não transforma a preferência em medição operacional.

Não há campo de latência, carga, capacidade, última sondagem, identidade criptográfica, causa de falha ou resultado PANA. O primeiro candidato pode estar indisponível; o segundo pode responder. O primeiro pode responder a IP e ainda falhar no protocolo.

Por isso, a lista válida recebe versão e hash imutáveis. Cada candidato mantém ordinal. Cada tentativa registra início, fim, observação de rede, mensagem PANA e motivo terminal. A seleção vencedora não apaga a ordem nem os fracassos anteriores.

Quando o parser ordena numericamente para facilitar exibição, ele altera a instrução. Quando deduplica sem preservar posições, também pode alterar semântica. A mesma representação usada pela execução precisa manter a sequência recebida.

O cliente pode não ter pedido a opção

O PaC deveria pedir a opção 136 na Parameter Request List de DHCPv4 e a opção 40 na Option Request Option de DHCPv6. Mas um servidor configurado com endereços PAA deveria fornecê-la mesmo sem solicitação explícita.

Logo, recebida não implica solicitada. A prova da intenção do cliente está no request; a prova da entrega está no response. Guardar apenas a resposta cria uma narrativa falsa sobre escolha.

Essa separação é particularmente importante numa investigação de parsing. Se o cliente não solicitou a opção e recebeu uma estrutura inválida, a pergunta não é apenas “por que o parser aceitou?”. Também é “qual servidor e qual configuração decidiram enviá-la?”.

O objeto de aquisição precisa de transaction ID, família, interface, servidor, relay, request set, response set e timestamps. Sem isso, os bytes ficam sem origem operacional.

Presença e ausência não decidem a política

O RFC 5192 proíbe usar a opção para negociar o emprego de PANA. A presença não significa que PANA foi mandatado; a ausência não autoriza abandonar o protocolo. Usar o silêncio como dispensa permitiria downgrade pela remoção da opção.

O mesmo vale para uma opção inválida. Falhar na validação não equivale a receber permissão para usar segurança inferior. A política de acesso continua vindo de outra superfície, com sua própria proveniência.

Uma implementação pode ter fallback configurado: descoberta alternativa, falha fechada, alerta ou intervenção. O que ela não pode fazer é atribuir essa decisão ao RFC 5192. O padrão delimitou a opção como descoberta, não como autoridade de negociação.

Essa honestidade reduz o raio de um bug. Um parser defeituoso afeta descoberta; só se torna downgrade silencioso quando o sistema lhe concede poder sobre política.

A opção pertence a um momento e a uma interface

DHCPv4 e DHCPv6 fornecem contexto de transação, servidor, relay, lease, Renew e Rebind. O RFC 5192 não promete que a lista mude ou permaneça igual em renovação. A operação deve observar o que cada resposta realmente trouxe.

Se uma troca posterior corrige o comprimento ou muda a ordem, cria-se nova versão. Tentativas iniciadas pela versão inválida ou anterior continuam ligadas a ela. Reatribuir uma tentativa velha à lista corrigida falsifica a causa.

Também é preciso separar famílias. Uma opção IPv4 válida não corrige automaticamente uma opção IPv6 inválida. O algoritmo dual-stack — serial, paralelo, preferência de família — é decisão local e precisa de versão própria.

Uma coluna global paa_address não preserva qualquer dessas linhas. Ela mostra o que sobrou, não como o sistema decidiu.

Proteção não pode ser inferida da existência de um padrão

O RFC 5192 observa que, na maioria das redes, o DHCP que entrega a opção antes da autenticação de acesso não tem proteção de integridade nem autenticação de origem. Uma resposta modificada ou inserida pode conduzir o PaC a um PAA malicioso, capaz de interceptar pedidos de autenticação ou negar acesso.

Há especificações de autenticação DHCP. Isso não prova que a mensagem observada foi protegida. O recibo precisa registrar o mecanismo aplicado, a identidade verificada e o resultado. Se nada foi verificado, o estado não pode subir para autenticado só porque o RFC 3118 existe.

Do mesmo modo, uma mensagem protegida ainda pode conter comprimento inválido por defeito do emissor. Autenticidade e conformidade estrutural são verificações diferentes. Uma não deve resgatar a outra.

Depois da estrutura válida, origem protegida também não vira health check. Ela prova quem forneceu a lista dentro do escopo do mecanismo; não prova que os endpoints estão prontos.

O registro operacional que preserva o erro

Para cada troca, conservar request e response, interface, família, servidor, relay, proteção e tempo. Para a opção, conservar código, comprimentos, bytes, validador e resultado. Somente uma opção válida produz lista normativa de endereços e ordem.

Se houver recuperação local, guardar uma transformação separada com versão de código, razão, entradas produzidas e autorização operacional. Candidatos derivados nunca devem ser indistinguíveis dos recebidos.

Cada tentativa referencia a lista ou transformação exata. O PANA subsequente é outro objeto. O artigo retido sobre RFC 5191 já trata autorização, Enforcement Point e plano de dados; esta análise para na integridade do caminho entre bytes DHCP e tentativa PAA.

Na disciplina de camadas de realidade de Heng Lu, o parser não recebe autoridade para criar realidade porque sua saída parece limpa. O pacote recebido, a interpretação e a execução são camadas diferentes. Preservá-las pode deixar um erro visível. Escondê-las deixa o sistema inexplicável.

Sources

  1. RFC 5192 HTML
  2. RFC 5192 texto
  3. Registro RFC 5192
  4. Datatracker RFC 5192
  5. Histórico RFC 5192
  6. Referências RFC 5192
  7. Errata RFC 5192
  8. RFC 2131
  9. Registro RFC 2131
  10. RFC 2132
  11. RFC 8415
  12. Registro RFC 8415
  13. RFC 3315
  14. RFC 5191
  15. RFC 3748
  16. RFC 3118
  17. Parâmetros BOOTP/DHCP da IANA
  18. Heng Lu — On Reality Layers
  19. Heng Lu — Minimum Initial Specification
  20. Heng Lu — Running-Code Primacy