Resumo

  • A RFC 9868 usa a diferença entre o fim declarado pelo UDP Length e o fim do payload IP para criar uma área de opções; ela não transforma esses bytes em mensagem da aplicação.
  • Uma falha de verificação descarta normalmente a área de opções e preserva os dados UDP validados. Exigir recusa é escolha explícita da aplicação ou da biblioteca.

UDP continua útil porque promete pouco. Sua cabeça informa portas, checksum e comprimento, mas não abre sessão, não identifica um par e não confirma resultado de negócio. A RFC 9868, publicada em outubro de 2025, trabalha justamente com essa contenção. O campo UDP Length pode terminar antes do fim do datagrama IP. O espaço posterior, chamado de área excedente, recebe opções de transporte.

A posição impõe uma fronteira. Os bytes adicionais não são inseridos no conteúdo entregue pela aplicação, nem sua presença demonstra que ela aceitou uma semântica nova. O UDP Length ainda encerra os dados do usuário; a área excedente tem parsing e integridade próprios. A RFC chama o mecanismo de plano de controle suave, mas também afirma que UDP permanece sem estado e unidirecional e que opções são um framework, não um protocolo completo.

As opções SAFE podem ser ignoradas por um receptor que não as compreende sem mudar os dados UDP ou seu significado. Um receptor que conhece opções ignora silenciosamente uma SAFE desconhecida ou malformada. Opções UNSAFE podem alterar significado e por isso têm restrições: se existirem, os dados UDP normais devem estar vazios e o payload de transporte segue pelo mecanismo FRAG.

O checksum de opções protege a área excedente separadamente do checksum UDP, que protege os dados declarados. Se a validação do checksum de opções falhar, o receptor deve ignorar as opções e descartar a área. Dados de usuário com checksum UDP correto ainda devem ser entregues como seriam sem opções. A observação é precisa: a extensão falhou; ela não é uma sentença automática sobre a mensagem da aplicação.

Essa compatibilidade é intencional. Exceto no caso de fragmentos, falhas de checksum, autenticação ou descriptografia de opções não bloqueiam automaticamente o pacote recebido. A aplicação precisa substituir explicitamente a regra se quiser que a falha altere a entrega. O transporte pode informar uma falha; não pode decidir sozinho se um resolvedor, um coletor de telemetria ou um controle industrial deve descartar dados válidos em outros aspectos.

Registros operacionais devem manter comprimento IP e UDP, tipos e ordem das opções, resultado de parsing, OCS/APC/AUTH/UENC quando usados, política do receptor e resultado da aplicação. Um pacote não prova identidade, autorização ou sucesso. A contribuição de Touch também é delimitada: o perfil IETF sustenta atividade técnica e a RFC sustenta coautoria, não domínio sobre implementações, middleboxes ou políticas de terceiros.

Fontes