Resumo

  • No IPv4, Parameter Problem mantinha separado o descarte do diagnóstico: um Pointer de oito bits localizava o octeto do cabeçalho em que o erro tinha sido detectado.
  • No ICMPv6, o Pointer ganhou 32 bits e os códigos distinguiram campo incorreto, Next Header desconhecido e opção desconhecida ao longo de uma cadeia de extensões.
  • O deslocamento pode apontar para além dos bytes citados na resposta. Exatidão numérica não autentica o relato, não demonstra causa raiz e não autoriza acesso fora do buffer recebido.

O descarte que deixou uma coordenada

O RFC 792 tratou, em 1981, de um pacote IPv4 cujo cabeçalho não podia mais ser processado. O host ou gateway precisava descartar o datagrama. Somente quando esse defeito causava o descarte, podia devolver ICMP tipo 12, Parameter Problem.

Com código 0, o campo Pointer identificava o octeto do cabeçalho original em que o problema fora encontrado. O valor 1 podia indicar o antigo Type of Service; com opções, 20 podia indicar o tipo da primeira. O ponto poderia cair no meio de uma opção. O relator não dizia por que o emissor tomou determinada decisão: informava a posição em que seu próprio parser falhou.

A mensagem carregava ainda o cabeçalho Internet e os primeiros 64 bits de dados. Em TCP ou UDP, oito octetos frequentemente mostravam portas suficientes para associar o erro a um processo. A citação dava contexto de identidade; o Pointer dava endereço ao defeito.

Isso não tornou o IP confiável. O RFC 792 definiu ICMP como retorno sobre problemas, sem prometer resposta a toda perda. Filtros, regras contra recursão de erros, fragmentação e a própria perda da mensagem preservaram uma assimetria: uma resposta informa algo; silêncio não comprova aceitação.

A obrigação de encaminhar informação, não uma ordem de abortar

O RFC 1122 incorporou Parameter Problem aos requisitos de hosts. Quando o processo de origem podia ser identificado, o erro precisava chegar à camada pertinente. Para TCP, devia ser reportado, não interpretado automaticamente como ordem de encerrar qualquer conexão. Quem conhece o estado da operação conserva a decisão.

O mesmo documento recomendou registrar cabeçalhos de eventos estranhos, mas alertou contra logs que consumissem recursos proibitivos. Uma rede heterogênea precisa de evidência; um sistema exposto não pode gastar trabalho ilimitado explicando entradas defeituosas.

O RFC 1812 concretizou essa disciplina em roteadores IPv4. Datagramas inválidos são descartados. Em casos parcialmente legíveis, o roteador pode devolver Parameter Problem apontando para Internet Header Length ou Total Length. A falha, porém, pode resultar de truncamento na camada de enlace, corrupção, outra versão de IP ou geração ilegal na origem. O offset localiza a verificação que falhou, não decide sozinho a história causal.

O roteador passou a poder citar tanto do datagrama quanto coubesse sem fazer o ICMP ultrapassar o buffer mínimo de remontagem IPv4 de 576 bytes. A explicação ganhou contexto, mas continuou limitada contra amplificação.

A cadeia do IPv6 exigiu outro alcance

O cabeçalho IPv4, incluindo opções, tem no máximo 60 bytes; um Pointer de um octeto basta. No IPv6, um cabeçalho básico de 40 bytes pode ser seguido por extensões encadeadas. Cada Next Header determina o próximo passo de análise, e o defeito pode estar distante do início.

O RFC 2463 definiu em 1998 ICMPv6 Parameter Problem tipo 4, com Pointer de 32 bits. Código 0 representa campo de cabeçalho incorreto; código 1, Next Header desconhecido; código 2, opção IPv6 desconhecida. O RFC 4443 manteve o desenho em 2006.

Código 1 com Pointer 40 significa que o valor Next Header logo depois do cabeçalho básico não foi reconhecido. Quarenta não é quantidade de saltos nem severidade. É a posição, em octetos, dentro do pacote que provocou o erro.

O RFC 8200 exige processamento na ordem. Um destino não pode ignorar uma transição desconhecida para procurar adiante algo familiar. Se precisa prosseguir e não reconhece o Next Header atual, descarta e aponta para esse valor. Algumas classes de opção desconhecida usam código 2; os bits de ação dessas opções constituem outro mecanismo e não são o tema deste relato.

O Pointer registra a fronteira alcançada pelo parser. Não certifica os cabeçalhos posteriores e tampouco garante que o primeiro erro relatado seja o único.

A posição pode não caber na cópia

Erros ICMPv6 incluem o máximo possível do pacote invocador sem ultrapassar a MTU mínima IPv6. Uma cadeia longa pode colocar o campo defeituoso além do trecho que cabe na resposta.

O RFC 4443 preserva o deslocamento verdadeiro. O Pointer pode apontar além dos bytes do pacote invocador presentes na mensagem ICMPv6. A origem recebe a afirmação de que o relator parou na posição N, mas não recebe necessariamente o conteúdo dessa posição.

Esse limite evita dois falsos confortos. Ajustar o número para o último byte disponível acusaria outro campo. Expandir a resposta sem limite permitiria que o diagnóstico se tornasse amplificação. O protocolo mantém, lado a lado, localização conhecida e conteúdo ausente.

Por isso um programa precisa verificar o comprimento antes de usar Pointer como índice. O RFC 8883 torna a regra explícita: o valor deve ser menor que a quantidade de dados citados antes de qualquer leitura. Um offset válido no espaço do pacote não cria memória no buffer local.

Uma citação curta pode nem chegar ao protocolo de camada superior. Sem descobrir essa camada, o host talvez não identifique o processo a notificar. Saber onde a análise de rede parou não garante entrega útil da explicação.

Quando o limite pertence ao equipamento

Em 2020, o RFC 8883 acrescentou códigos 5 a 10 para Next Header desconhecido em nó intermediário e limites de tamanho da extensão, comprimento da cadeia, quantidade de cabeçalhos, quantidade de opções ou tamanho da opção. Dependendo do código, o Pointer marca o valor desconhecido ou o primeiro elemento que ultrapassou a cota local.

O pacote pode ser sintaticamente correto. Talvez exija apenas mais análise do que aquele nó decidiu suportar. O código diz qual orçamento local se esgotou; o deslocamento mostra onde.

Assim, capacidade local não se transforma em veredicto universal. Outro equipamento pode aceitar a mesma cadeia. Ao mesmo tempo, uma forma permitida pelo padrão não obriga cada roteador a reservar recursos infinitos. A resposta torna o limite observável e atribuível.

Evidência precisa sem autoridade automática

Uma mensagem ICMP comum não é autenticada por padrão. O RFC 4443 trata de origem forjada, alteração de campos, negação de serviço e ataques que exploram reações da camada superior. Antes de agir, o sistema precisa correlacionar endereços, protocolo, portas e tráfego realmente enviado.

Erros ICMPv6 também precisam ser limitados em taxa. Uma sequência de pacotes ruins não pode impor respostas sem fim. Multicast, filtros e perda normal acrescentam silêncio. Receber Parameter Problem prova que algum relator produziu aquela observação; não receber não prova que todos os parsers avançaram.

A contribuição histórica foi separar ação, classe de causa, localização e contexto citado. Cada parte diz apenas o necessário. O Pointer é útil justamente porque a precisão do número não apaga as fronteiras da evidência.

Fontes