Resumo
- A RFC 7112 exige que o fragmento IPv6 com
Fragment Offsetigual a zero contenha a cadeia completa de cabeçalhos até o primeiro cabeçalho da camada superior. Um filtro sem estado pode então enxergar o protocolo e, quando disponível, a porta antes de decidir. - A conformidade da primeira peça não autentica a origem nem valida as demais. Construção no emissor, MTU do caminho, regra aplicada, ICMPv6 Type 4 Code 3, offsets posteriores, sobreposição, remontagem e resultado da aplicação precisam de registros separados.
A regra existia, o campo ainda não
Os cabeçalhos de extensão do IPv6 formam uma sequência entre o cabeçalho básico e TCP, UDP ou outro protocolo superior. Cada campo Next Header aponta para o próximo. Quando a sequência é longa, o ponto de corte da fragmentação pode cair antes do cabeçalho de transporte.
Para um filtro que olha apenas endereços, talvez isso não mude nada. Para uma ACL que autoriza uma porta e bloqueia outra, muda tudo. Encaminhar a primeira peça incompleta pode admitir o que a política rejeitaria. Descartá-la preventivamente pode bloquear o que a política aceitaria. O equipamento é obrigado a agir antes de receber a pergunta completa.
Uma solução seria remontar em cada ponto intermediário. Ela acrescentaria memória, estado, temporizadores e superfície de ataque a equipamentos cujo trabalho deveria continuar limitado. A RFC 7112 escolheu outro lugar para o custo: a origem que fragmenta deve colocar a cadeia inteira na primeira peça.
O pacote passa a se apresentar antes de pedir julgamento. A rede comum não ganha uma política global; ganha uma condição objetiva para executar políticas locais.
O significado limitado de “inteira”
A cadeia começa no cabeçalho IPv6 inicial, percorre zero ou mais cabeçalhos de extensão e termina no primeiro cabeçalho da camada superior. TCP, UDP e ICMPv6 são exemplos usuais. Em um túnel IPv6 sobre IPv6, o segundo cabeçalho IPv6 é tratado como o limite superior dessa definição. ESP também encerra a cadeia. No Next Header serve de término quando nada vem depois.
A carga superior não entra na definição. A primeira peça precisa incluir o cabeçalho TCP, não todo o conteúdo carregado por TCP. Assim, a RFC não proíbe cargas grandes e não elimina a fragmentação. Ela obriga apenas a introdução protocolar a caber no MTU do caminho.
Esse limite evita um exagero comum. Ver uma porta permite avaliar uma regra de porta. Não permite concluir que o conteúdo posterior passou por inspeção profunda. Uma sequência sintaticamente correta não comprova identidade, autorização ou intenção benigna.
O fragmento fornece evidência sobre sua estrutura. A política e a confiança continuam em outras camadas.
Offset zero não é credencial
A primeira peça é definida por Fragment Offset = 0. A leitura é determinística e local: nenhum diretório ou comitê precisa confirmar a posição. Ainda assim, qualquer software pode preencher esse campo, inclusive um atacante.
O endereço de origem visível pode ser forjado. O identificador de fragmentação não é uma assinatura. A cadeia completa informa qual protocolo aparece; não informa quem tem direito de usá-lo.
Essa separação é útil para uma arquitetura fina. O padrão fixa a forma mínima que todos podem verificar. Cada operadora escolhe suas portas permitidas, seu modo de compatibilidade e o tratamento local. O destino faz sua própria recepção e remontagem. A autoria da RFC não transfere controle sobre nenhuma dessas escolhas.
Quando a telemetria diz “primeiro fragmento válido”, deve significar apenas que a condição de cabeçalho foi observada. Qualquer outra conclusão precisa apontar outra evidência.
Obrigações diferentes em cada ponto
Para a origem que fragmenta, incluir a cadeia é uma obrigação MUST. Para o host que recebe uma primeira peça incompleta, a RFC 7112 recomenda o descarte e o envio de erro ICMPv6, respeitando as regras gerais. Uma implementação pode manter uma opção de aceitação por compatibilidade.
No meio do caminho, a linguagem é mais permissiva. Um roteador ou firewall pode descartar e pode enviar o erro. Quando suporta o descarte, deveria permitir que essa decisão seja configurada. A escolha não desaparece; ela se torna identificável e atribuível.
Por isso, “a Internet rejeita esse pacote” é uma descrição errada. Uma origem pode ter construído algo não conforme. Um firewall específico pode aplicar ou não seu modo de bloqueio. O destino pode tomar outra decisão. O diagnóstico precisa dizer qual função agiu.
Nome do equipamento, interface, versão, revisão da regra, valor do modo de compatibilidade e ponto de captura são parte do fato. O nome da RFC sozinho não é causa suficiente.
Code 3: uma resposta que também pode se perder
Quando o descarte por cadeia incompleta é acompanhado de sinalização, a resposta definida é ICMPv6 Parameter Problem, Type 4, Code 3, com Pointer zero. O código registrado descreve precisamente a primeira peça IPv6 com cadeia incompleta.
Ele pode funcionar como recibo. Um desenvolvedor associa a mensagem ao pacote citado. Uma equipe de rede compara picos com uma atualização de host, mudança de túnel ou nova combinação de extensões. Um teste controlado confirma se um equipamento descarta, encaminha, registra e responde.
Mas o recibo não é obrigatório em todos os pontos. Um sistema intermediário pode não gerá-lo. As regras de ICMPv6 podem limitar a mensagem; rate limit e filtragem de retorno podem apagá-la. Com origem falsificada, o destinatário do erro talvez nem seja quem enviou o tráfego.
A ausência do Code 3 não prova aceitação. A presença não identifica automaticamente o gerador. Hora, trecho citado, interface, captura, contador e versão da configuração completam a atribuição.
O MTU também faz parte da história
Se todos os cabeçalhos até a camada superior precisam caber na primeira peça, o tamanho da cadeia não pode superar o MTU do caminho. A RFC 7112 diz que um host sem descoberta de MTU deve limitar a cadeia a 1.280 bytes, o mínimo IPv6 considerado pelo documento.
Isso amplia as hipóteses de investigação. Uma primeira peça incompleta pode ser tentativa de evasão, mas também pode surgir quando uma encapsulação reduz o MTU efetivo, quando o cache de caminho está obsoleto ou quando a pilha constrói uma sequência de extensões que já não cabe.
O registro deve ligar o pacote ao MTU conhecido naquele momento. Um valor atual consultado horas depois não substitui a crença usada pela origem. Em redes com túneis, convém registrar a camada em que a fragmentação ocorreu e a camada em que o filtro observou o pacote.
O mecanismo de segurança e a engenharia de tamanho se encontram na mesma borda. Sem esse contexto, um contador de descarte pode ser classificado como ataque quando o defeito está na construção.
Admissão, remontagem e aplicação
A RFC 8200 incorporou o requisito à especificação básica de IPv6. Ela distingue cabeçalhos que acompanham cada fragmento, o cabeçalho Fragment, as extensões e o cabeçalho superior que aparecem na primeira peça, e os dados distribuídos.
Depois da admissão vem a remontagem no destino. Fragmentos são associados por origem, destino e Fragment Identification; offsets e comprimentos definem posições. Faltas por 60 segundos levam ao abandono. Comprimentos inválidos geram erro. Sobreposição exige descartar o datagrama inteiro. Duplicatas exatas podem ser reconhecidas e removidas sem eliminar as demais.
Uma primeira peça completa não garante a chegada da última. Tampouco elimina sobreposição ou timeout. Um datagrama remontado ainda pode falhar em TCP ou na aplicação. São três resultados, não um.
O inverso também engana. Um firewall pode descartar offset zero e encaminhar peças posteriores. Sem a primeira, o destino não conclui a remontagem. Contar fragmentos posteriores como “tráfego admitido” atribui a eles um resultado que não produziram.
O vocabulário operacional precisa preservar a sequência: validação da cadeia, estado da remontagem, resultado do serviço.
O caso atômico fica fora da fila
A RFC 6946, de autoria de Fernando Gont, trata de um pacote com cabeçalho Fragment, mas offset = 0 e bit M igual a zero. É o fragmento atômico: um datagrama completo que não espera outras peças.
Algumas implementações ainda o misturavam a uma fila de remontagem com fragmentos de mesma origem, destino e identificador. Um atacante podia explorar essa mistura para provocar descarte. A correção foi processar o atômico de forma independente. A RFC 8200 incorporou esse comportamento.
Ele não é uma versão menor do problema da RFC 7112. Primeira peça incompleta, atômico e sobreposição representam estados diferentes. Cada um pede outro teste e outro remédio.
Guardar apenas “há cabeçalho Fragment” destrói a distinção. Offset, M, identificação, término da cadeia, quantidade observada e estado da fila precisam sobreviver à normalização dos logs.
Da atualização ao texto-base
Em 2014, a RFC 7112 atualizou a RFC 2460. Em 2017, a RFC 8200 substituiu a antiga especificação e passou a exigir no próprio procedimento de fragmentação que as extensões posteriores ao cabeçalho Fragment e o cabeçalho superior estejam na primeira peça. Se faltarem, o texto recomenda descarte e Code 3.
A RFC 9099 leva a regra à prática de segurança: firewalls, dispositivos de proteção e destinos deveriam descartar primeiras peças sem toda a cadeia, inclusive o cabeçalho de transporte, porque um atacante pode contornar filtragem sem estado.
Esse percurso prova a evolução documental. Não prova o comportamento de um parque. Um ASIC pode não percorrer cadeias longas. Um software pode manter compatibilidade antiga. A geração de ICMPv6 pode variar.
Testes construídos, capturas nos dois lados, contadores, configuração versionada e resultado de serviço são a evidência de adoção. A RFC ensina a formular a pergunta; o código em execução responde.
A participação documentada de Fernando Gont
Fernando Gont divide a autoria da RFC 7112 com Vishwas Manral e Ron Bonica. O status Standards Track representa revisão e consenso no IETF. Não representa invenção exclusiva nem poder de um autor sobre as redes que implementam a regra.
O perfil atual no IETF lista 40 RFCs e uma trajetória em segurança de protocolos. A RFC 6946 ajuda a entender a linha de trabalho: separar estados que implementações misturavam e transformá-los em condições observáveis.
Na RFC 7112, a primeira peça precisa revelar o limite superior necessário. Na RFC 6946, o atômico precisa ficar fora da remontagem alheia. Em ambos, a função vem antes da instituição: o formato traz dados, o equipamento decide localmente, o destino remonta e a aplicação demonstra o resultado.
O primeiro fragmento não precisa narrar a conversa. Precisa apenas apresentar o protocolo sem esconder o campo que a próxima máquina foi configurada para ler.
Fontes
- https://www.rfc-editor.org/rfc/rfc7112.html
- https://www.rfc-editor.org/rfc/rfc8200.html
- https://www.rfc-editor.org/rfc/rfc6946.html
- https://www.rfc-editor.org/rfc/rfc9099.html
- https://www.ietf.org/lib/dt/media/photo/fgont-square_LD9VupS.jpg
- https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
- https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
Briefing para membros
Contexto aprofundado do perfil
Faça login com o nível de assinatura correto para desbloquear o briefing completo e as notas das fontes.
Apenas para Strategic Circle
Strategic Circle
Aberto a todos os leitores. Desbloqueie Briefings de perfil após se inscrever e fazer login.
Junte-se ao Strategic CircleSomente para Leadership Alliance
Leadership Alliance
Para proprietários e gestores qualificados de ativos de PI; faça login para desbloquear os briefings da Leadership Alliance.
Junte-se ao Leadership Alliance
