MTU IPv6 e Path MTU Discovery: Evitando Problemas de Fragmentação

Fragmentação de pacotes é um daqueles problemas que você não nota até quebrar tudo.

TL;DR - Resumo rápido

Pontos-chave:

Roteadores IPv6 não podem fragmentar: Hosts de origem devem lidar com toda fragmentação via Path MTU Discovery
Nunca bloqueie ICMPv6 Type 2: Mensagens Packet Too Big são essenciais para PMTUD funcionar
MTU mínimo é 1280 bytes: Todos links IPv6 devem suportar isto, use como fallback
Túneis reduzem MTU: Considere overhead de encapsulamento (6in4: 20 bytes, VPN: 40-80 bytes)
Use MSS clamping: Force TCP a usar segmentos menores quando PMTUD falhar

Ir para: Black Holes PMTUD | Diagnosticando Problemas MTU | Configuração de Firewall

Por Que MTU Importa Mais no IPv6 #

O IPv6 removeu fragmentação baseada em roteador inteiramente. No IPv4, se um roteador recebe um pacote grande demais para o próximo hop, ele pode fragmentá-lo. Roteadores IPv6 não podem fazer isso — eles descartam o pacote e enviam uma mensagem ICMPv6 «Packet Too Big» de volta à origem.

O host de origem é responsável por toda fragmentação. Esta decisão de design melhora o desempenho do roteador e simplifica o protocolo, mas transfere o ônus para os endpoints e torna Path MTU Discovery (PMTUD) crítico.

Se PMTUD falhar, suas conexões travam misteriosamente. Handshakes TCP completam, mas transferência de dados para. Requisições HTTP expiram. Sessões SSH congelam após autenticação. Esses são sintomas clássicos de black hole de MTU.

MTU Mínimo IPv6 #

Todos links IPv6 devem suportar pelo menos 1280 bytes. Este é o MTU mínimo, e não é negociável. Se seu link não consegue manipular pacotes de 1280 bytes, ele não é conforme com IPv6.

A maioria das redes usa 1500 bytes (MTU Ethernet padrão), o que fornece espaço para o cabeçalho IPv6 de 40 bytes mais 1460 bytes de payload. Isso é equivalente ao MSS TCP típico de 1460 do IPv4.

Túneis e protocolos de encapsulamento reduzem MTU disponível. Se você está executando IPv6-in-IPv4 (6in4), 6to4 ou ISATAP, você perde bytes para o cabeçalho externo. VPNs, IPsec, GRE e VXLAN todos consomem espaço de MTU.

Valores MTU comuns que você encontrará:

1500: Ethernet padrão
1480: PPPoE (perde 8 bytes para overhead PPP)
1460: Túnel 6in4 (perde 20 bytes para cabeçalho IPv4)
1420: 6in4 sobre PPPoE
1280: MTU mínimo IPv6, valor de fallback
9000: Jumbo frames (redes de data center)

Como Funciona Path MTU Discovery #

PMTUD determina o maior tamanho de pacote que pode atravessar o caminho entre origem e destino sem fragmentação.

O processo é direto:

Host envia pacotes com o MTU atual
Se um roteador ao longo do caminho tem MTU menor, ele descarta o pacote
Roteador envia mensagem ICMPv6 Type 2 «Packet Too Big» de volta à origem
Mensagem inclui o MTU do próximo hop
Host reduz seu path MTU e reenvia
Processo repete até pacotes atravessarem todo o caminho

A mensagem «Packet Too Big» (ICMPv6 Type 2, Code 0) contém o valor MTU no payload da mensagem. Isso diz à origem exatamente quão grandes os pacotes podem ser, não apenas que são grandes demais.

Veja como a mensagem ICMPv6 se parece:

ICMPv6 Packet Too Big:
  Type: 2
  Code: 0
  MTU: 1280
  [Cabeçalhos de pacote original até MTU mínimo]

O host mantém um cache de path MTU com entradas que tipicamente expiram após 10 minutos (recomendação RFC 8201). Se caminhos de rede mudam, entradas de cache obsoletas podem causar problemas até expirarem.

Black Holes PMTUD #

O sistema quebra quando mensagens ICMPv6 Type 2 são bloqueadas. Isso cria «black holes PMTUD» onde pacotes desaparecem silenciosamente.

Causas comuns:

Firewalls zelosos demais: Administradores às vezes bloqueiam todo tráfego ICMP, tratando-o como risco de segurança. Isso é errado. ICMPv6 é integral à operação do IPv6, não um protocolo de diagnóstico opcional como ping.

Problemas de inspeção stateful: Alguns firewalls não associam adequadamente mensagens de erro ICMPv6 com conexões existentes, descartando-as como tráfego não solicitado.

Limitação de taxa: Dispositivos de segurança podem limitar ICMPv6, descartando mensagens PMTUD legítimas durante períodos ocupados.

Gateways NAT64: Tradução entre IPv6 e IPv4 pode perder informação PMTUD se o gateway não traduz adequadamente mensagens ICMP.

Sintomas de black holes PMTUD:

Conexão TCP estabelece (SYN, SYN-ACK, ACK completos)
Pacotes pequenos funcionam (consultas DNS, banner de login SSH)
Pacotes grandes falham (transferências de arquivo, HTTP POST com body, sessão SSH interativa após auth)
Sem mensagens de erro, apenas timeouts
Problema aparece intermitente (depende do tamanho do pacote)

Diagnosticando Problemas MTU #

Comece com ping. Envie pacotes de tamanhos específicos para testar path MTU:

# Teste com 1280 bytes (MTU mínimo)
ping6 -M do -s 1232 2001:db8::1
 
# Teste com 1500 bytes (Ethernet padrão)
ping6 -M do -s 1452 2001:db8::1
 
# Teste com payload de 1280 bytes
ping6 -c 5 -s 1280 2001:db8::1

A flag -M do proíbe fragmentação (don't fragment). O argumento -s especifica tamanho de payload — adicione 8 bytes para cabeçalho ICMPv6 e 40 para cabeçalho IPv6 para obter tamanho total do pacote.

Se 1452 bytes falha mas 1232 sucede, seu path MTU está entre 1280 e 1500. Busca binária para encontrar o valor exato:

# Tente 1400
ping6 -M do -s 1352 2001:db8::1
 
# Tente 1450
ping6 -M do -s 1402 2001:db8::1

Use traceroute para identificar onde MTU muda:

traceroute6 -n 2001:db8::1

Depois teste MTU para cada hop individualmente. O hop onde pacotes grandes começam a falhar é seu ponto problemático.

Para conexões TCP, observe comportamento real:

# Capture pacotes
tcpdump -i eth0 -n 'ip6 and (icmp6 or tcp)'

Procure por:

Retransmissões TCP após handshake inicial
Mensagens ICMPv6 Type 2 (devem aparecer se PMTUD está funcionando)
Ausência de ICMPv6 Type 2 (indica bloqueio ou black hole)

Ferramentas modernas podem automatizar isso. MTR combina traceroute com teste de tamanho de pacote:

# Teste com pacotes de 1400 bytes
mtr -6 -s 1400 2001:db8::1

TCP MSS Clamping #

MSS (Maximum Segment Size) é a opção TCP que diz ao outro lado quanto dado ele pode enviar em cada segmento. MSS = MTU - cabeçalho IP - cabeçalho TCP.

Para IPv6: MSS = MTU - 40 (IPv6) - 20 (TCP) = MTU - 60

Com MTU padrão de 1500 bytes: MSS = 1440

MSS clamping força conexões TCP a usar um valor MSS menor, contornando problemas MTU sem depender de PMTUD. Isso é comum em roteadores que terminam túneis ou conexões PPPoE.

Configure MSS clamping no Linux:

# Clamp MSS para 1280 para IPv6
ip6tables -t mangle -A FORWARD \
  -p tcp --tcp-flags SYN,RST SYN \
  -j TCPMSS --set-mss 1220

O valor 1220 considera 1280 MTU menos 60 bytes para cabeçalhos.

Para PPPoE com MTU 1492:

ip6tables -t mangle -A FORWARD \
  -p tcp --tcp-flags SYN,RST SYN \
  -j TCPMSS --set-mss 1432

MSS clamping afeta apenas TCP. UDP, SCTP e outros protocolos ainda dependem de PMTUD ou fragmentação em nível de aplicação.

Configuração de Firewall #

Seu firewall deve permitir mensagens ICMPv6 Type 2 para PMTUD funcionar. Isso é não negociável para redes IPv6 em produção.

Tipos ICMPv6 mínimos requeridos para operação IPv6:

Type 1: Destination Unreachable
Type 2: Packet Too Big (PMTUD)
Type 3: Time Exceeded
Type 4: Parameter Problem
Type 133-137: Neighbor Discovery Protocol

Regra iptables para PMTUD:

# Permita ICMPv6 Packet Too Big
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type 2 -j ACCEPT
ip6tables -A OUTPUT -p ipv6-icmp --icmpv6-type 2 -j ACCEPT
ip6tables -A FORWARD -p ipv6-icmp --icmpv6-type 2 -j ACCEPT

Abordagem melhor — permita todo ICMPv6 necessário:

# Permita ICMPv6 estabelecido
ip6tables -A INPUT -p ipv6-icmp -m state --state ESTABLISHED,RELATED -j ACCEPT
 
# Permita tipos ICMPv6 necessários
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type 1 -j ACCEPT    # Destination Unreachable
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type 2 -j ACCEPT    # Packet Too Big
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type 3 -j ACCEPT    # Time Exceeded
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type 4 -j ACCEPT    # Parameter Problem
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type 128 -j ACCEPT  # Echo Request
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type 129 -j ACCEPT  # Echo Reply
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type 133 -j ACCEPT  # Router Solicitation
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type 134 -j ACCEPT  # Router Advertisement
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type 135 -j ACCEPT  # Neighbor Solicitation
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type 136 -j ACCEPT  # Neighbor Advertisement

Limitação de taxa é aceitável mas defina limites generosos:

# Permita ICMPv6 com limitação de taxa
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type 2 \
  -m limit --limit 10/sec --limit-burst 20 -j ACCEPT

Nunca bloqueie ICMPv6 completamente. Não é um risco de segurança — é um requisito de protocolo.

Considerações MTU de Túnel #

Túneis reduzem MTU efetivo pelo overhead de cabeçalhos de encapsulamento.

Tipos comuns de túnel e overhead:

Tipo de Túnel	Overhead	MTU Efetivo (de 1500)
6in4	20 bytes	1480
6to4	20 bytes	1480
6rd	20 bytes	1480
ISATAP	20 bytes	1480
GRE	24 bytes	1476
IPsec	50-70 bytes	1430-1450
WireGuard	60 bytes	1420
OpenVPN	40-80 bytes	1420-1460

Configure MTU de túnel explicitamente para evitar problemas:

# Túnel 6in4
ip tunnel add tun6in4 mode sit remote 203.0.113.1 local 198.51.100.1
ip link set tun6in4 mtu 1480
ip link set tun6in4 up

Para WireGuard:

[Interface]
MTU = 1420

Alguns protocolos de túnel suportam descoberta MTU, mas configuração explícita é mais confiável.

Jumbo Frames e Data Centers #

Redes de data center frequentemente usam MTU de 9000 bytes (jumbo frames) para melhorar throughput para transferências bulk.

Habilite jumbo frames em interfaces:

ip link set eth0 mtu 9000

Garanta que todos switches e roteadores no caminho suportam jumbo frames. Um dispositivo com MTU de 1500 bytes se tornará um gargalo.

PMTUD ainda se aplica. Se um pacote sai de sua rede jumbo frame para a Internet, ele deve reduzir para 1500 ou menos.

Teste e Verificação #

Verifique configuração MTU do seu host:

ip -6 link show

Procure o valor MTU em cada interface.

Verifique cache de path MTU atual:

ip -6 route get 2001:db8::1

Saída mostra o MTU em cache para aquele destino.

Teste conectividade end-to-end com tamanhos de pacote variados:

for size in 1232 1352 1402 1452; do
  echo "Testando $size bytes:"
  ping6 -M do -s $size -c 3 2001:db8::1
done

Use netcat para testar negociação MSS TCP:

# Servidor
nc -6 -l 8080
 
# Cliente
nc -6 2001:db8::1 8080

Capture pacotes com tcpdump e verifique valores MSS em pacotes SYN.

Cenários Comuns e Correções #

Problema: Páginas web carregam lentamente, imagens falham Causa: Black hole PMTUD devido a firewall bloqueando ICMPv6 Type 2 Correção: Configure firewall para permitir ICMPv6 Type 2

Problema: SSH conecta mas congela após login Causa: MTU grande demais, PMTUD não funcionando Correção: Reduza MTU na interface cliente ou habilite MSS clamping no roteador

Problema: VPN funciona para transferências pequenas, falha para arquivos grandes Causa: MTU de túnel não configurado corretamente Correção: Reduza MTU de túnel para considerar overhead de encapsulamento

Problema: IPv6 funciona na rede local, falha através da Internet Causa: Roteador upstream tem MTU menor, não anunciando adequadamente Correção: Contate ISP ou reduza MTU local para 1280 (mínimo)

Problema: Alguns destinos funcionam, outros falham Causa: Problemas MTU específicos de caminho Correção: Teste com ping para identificar MTU funcional, configure interface adequadamente

Melhores Práticas #

Sempre permita ICMPv6 Type 2 em firewalls
Configure MTU de túnel explicitamente em vez de depender de detecção automática
Teste com MTU mínimo (1280) para garantir conectividade baseline
Use MSS clamping em endpoints de túnel e conexões PPPoE
Monitore falhas PMTUD com capturas de pacote durante troubleshooting
Documente o MTU da sua rede em cada camada (física, túnel, aplicação)
Defina valores MTU conservadores quando em dúvida (1280 sempre funciona)