O IPv4 fragmenta em trânsito; o IPv6 envia antes uma mensagem de pacote demasiado grande

As falhas de IPv6 são atribuídas ao protocolo muito mais vezes do que ao tamanho do pacote que as causou. As duas famílias tratam de facto de forma diferente um pacote demasiado grande, e é o túnel que torna essa diferença importante. Os routers IPv4 podem fragmentar um pacote quando as regras o permitem, enquanto os routers IPv6 não devem fragmentar em trânsito de todo. O IPv6 diz isso ao emissor, e espera-se que o emissor reaja. Tudo o que corre mal depois decorre de a mensagem chegar ou não.

O que cada família faz

A tabela é o mecanismo em quatro linhas, e uma linha explica a maior parte da confusão.

O IPv6 não tem fragmentação em trânsito nem um sinalizador DF para limpar, por isso não há nada a que recorrer quando um pacote é demasiado grande. É preciso dizê-lo ao emissor, e o emissor tem de acreditar.

O túnel estreita o caminho em silêncio

Uma VPN acrescenta cabeçalhos externos, e no caso cifrado também dados de integridade, antes de o pacote sair do anfitrião. O pacote interno pode caber na MTU da interface que vê, enquanto o pacote externo excede o limite da ligação seguinte, e é por isso que isto aparece primeiro num túnel. Baixe deliberadamente a MTU da interface do túnel, ou aperte o TCP MSS no caminho, e anote que valor escolheu e porquê.

A sobrecarga do ESP depende do modo e dos algoritmos, por isso a MTU correta do túnel é um cálculo e não uma convenção. Escolha o que escolher, tem de deixar espaço para um pacote IPv6 interno completo de 1280 bytes, porque cada ligação IPv6 tem de transportar isso. Um túnel que não consegue transportar 1280 bytes de IPv6 não é um problema de afinação; é um caminho quebrado para essa família. É essa restrição que desaparece quando um valor de MTU é copiado de uma implementação só com IPv4.

Porque é que o sintoma é um bloqueio

A falha não é um erro limpo, e é por isso que é mal diagnosticada. Um handshake TCP completa-se, chegam respostas pequenas, e a ligação bloqueia assim que começa uma resposta grande ou um carregamento massivo, porque esses são os primeiros pacotes suficientemente grandes para serem descartados. O SSH liga-se e depois bloqueia na primeira saída grande, e o cabeçalho de uma página carrega enquanto o corpo nunca termina.

Se as mensagens ICMPv6 de pacote demasiado grande forem filtradas, o emissor nunca fica a saber e continua a tentar o mesmo tamanho. Isso é um buraco negro e não um caminho lento, e a sua assinatura é um limite de tamanho repetível e não uma perda aleatória. Permitir o tráfego de controlo relevante faz parte de uma implementação IPv6 funcional, não é uma cortesia.

Não desative as mensagens das quais o seu próprio caminho depende e depois descreva o resultado como uma falha de IPv6. O mesmo argumento se aplica às mensagens Fragmentation Needed do IPv4, igualmente impopulares junto dos autores de firewalls e igualmente necessárias.

Meça o limite e depois corrija a camada

Verifique em vez de adivinhar: use o sinalizador don't-fragment no IPv4 e tamanhos fixos de carga no IPv6, e registe onde as respostas param. ping -M do -s 1472 e ping -6 -s 1400 bastam para estabelecer a forma do problema, e tracepath relata a MTU de caminho descoberta ao longo do percurso.

Depois corrija a camada que é dona do número: a MTU da interface do túnel, o clamp de MSS para TCP, ou o próprio caminho. O RFC 8200 é a referência para a regra IPv6, e lê-se mais depressa do que o incidente que evita.

Teste a família que a aplicação realmente usa, porque um nome de pilha dupla pode responder numa família e não na outra, e uma aplicação pode mudar após uma alteração de rede. Registe o endereço que testou, porque um resultado contra o registo A não diz nada sobre o registo AAAA.

Trate o limite de tamanho como prova

Um limite de tamanho repetível é uma das poucas falhas de rede que se reproduzem exatamente, com o mesmo número de bytes, a partir da mesma origem, todas as vezes. Isso torna-o numa prenda e não num mistério, e também significa que uma correção pode ser verificada em vez de esperada.

Escreva no ticket a MTU descoberta, a MTU do túnel que configurou e o teste que provou a diferença. A pessoa seguinte vai encontrar a mesma aritmética noutra ligação.