Fragmentação de Pacotes e MTU

1. Definição de MTU

MTU (Maximum Transmission Unit) é o tamanho máximo, em bytes, do PDU que um enlace pode transportar em um único quadro. Para Ethernet padrão (IEEE 802.3), o MTU é 1500 bytes de payload — somando cabeçalhos Ethernet (14 bytes) e FCS (4 bytes), o quadro total chega a 1518 bytes. Esse valor foi escolhido em 1983 como compromisso entre eficiência (mais payload por overhead) e taxa de erro (quadros menores reduzem retransmissão em caso de corrupção).

Quando a camada IP precisa transmitir um datagrama maior que o MTU do próximo enlace, ela tem duas opções: fragmentar o pacote em partes menores ou descartá-lo e notificar a origem via ICMP (se o bit DF estiver ligado). A fragmentação é uma das operações mais caras em roteadores e fonte clássica de problemas de rede.

2. Campos do Cabeçalho IPv4 Envolvidos

A fragmentação usa três campos específicos do cabeçalho IPv4 (RFC 791):

O offset é em blocos de 8 bytes porque 13 bits só endereçam 8192 unidades, e 8192 × 8 = 65536, que é o tamanho máximo de datagrama IPv4 (2¹⁶ − 1).

• DF = 1: o pacote não pode ser fragmentado. Se um roteador não conseguir encaminhá-lo, descarta e envia ICMP "Fragmentation Needed" (Type 3, Code 4) para a origem.
• MF = 1: indica que há mais fragmentos a seguir. O último fragmento tem MF = 0, sinalizando o fim do conjunto.

3. O Processo de Fragmentação

Quando um roteador recebe um pacote maior que o MTU do enlace de saída, ele:

1. Verifica o bit DF. Se DF = 1, descarta e envia ICMP Type 3 Code 4.
2. Calcula o tamanho de cada fragmento: deve ser múltiplo de 8 bytes (por causa do offset de 13 bits).
3. Copia o cabeçalho IP para cada fragmento, ajustando:
   - Total Length: tamanho do fragmento (incluindo cabeçalho).
   - MF: 1 para todos exceto o último.
   - Fragment Offset: posição em blocos de 8 bytes.
   - Identification: idêntico em todos (preserva o original).
   - Checksum: recalculado em cada fragmento.
4. Encaminha os fragmentos independentemente — eles podem seguir rotas diferentes.

4. Reassembly

A reassembly só acontece no destino final, nunca em roteadores intermediários. Isso foi uma decisão de design da RFC 791: fragmentos podem chegar fora de ordem e por rotas distintas, então só quem conhece o estado completo é o host de destino. Se um fragmento se perder, o destino espera um tempo (timeout) e descarta os parciais — ICMP "Time Exceeded, Fragment Reassembly Time Exceeded" (Type 11 Code 1) pode ser enviado.

5. Exemplo Numérico

Pacote IPv4 de 4000 bytes (20 de cabeçalho + 3980 de payload) precisa atravessar enlace MTU 1500.

• MTU efetivo de payload por fragmento: 1500 − 20 = 1480. Múltiplo de 8 mais próximo: 1480 (1480 / 8 = 185, exato).
• Fragmento 1: offset 0, payload 1480, MF = 1 → quadro 1500 bytes.
• Fragmento 2: offset 185, payload 1480, MF = 1 → quadro 1500 bytes.
• Fragmento 3: offset 370, payload 1020 (3980 − 2960), MF = 0 → quadro 1040 bytes.

Total transmitido: 1500 + 1500 + 1040 = 4040 bytes (overhead de 3 cabeçalhos extras = 40 bytes). Cada fragmento carrega a mesma Identification, permitindo ao destino remontar o pacote original na ordem correta.

6. Path MTU Discovery (PMTUD)

A PMTUD (RFC 1191) descobre o menor MTU ao longo do caminho entre origem e destino. Funciona assim:

1. Origem envia pacote com DF = 1 e tamanho igual ao MTU local.
2. Se algum roteador intermediário não puder encaminhar (MTU menor), descarta o pacote e responde com ICMP Type 3 Code 4, incluindo o MTU do próximo salto no campo "Next-Hop MTU".
3. A origem reduz o tamanho do pacote e tenta novamente, progressivamente.

A PMTUD é essencial para TCP em conexões longas (HTTP/HTTPS, transferências grandes), pois evita fragmentação. TCP também negocia o MSS (Maximum Segment Size) no handshake SYN/SYN-ACK, normalmente 1460 bytes (MTU 1500 − 20 IP − 20 TCP).

7. Black Hole PMTUD

Se um firewall bloqueia ICMP Type 3 Code 4 — prática comum em políticas de segurança mal concebidas — a origem nunca recebe a notificação. Os pacotes grandes são descartados silenciosamente. Sintomas clássicos:

• Ping pequeno funciona, ping grande trava.
• HTTPS "pendura" no TLS handshake (certificados grandes não passam).
• SSH conecta mas ls em diretório grande trava (initial window estoura MTU).
• Email com anexo não envia, mas texto curto sim.

Soluções:
- MSS Clamping: roteador reescreve MSS nas opções TCP para 1380 ou similar, independentemente do que o cliente pediu. Implementado em Linux com iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu.
- Liberação de ICMP Type 3 Code 4 no firewall.
- Reduzir MTU na interface do cliente (ex.: 1400 em links PPPoE).

8. VPNs e Túneis

VPNs (IPsec, GRE, WireGuard, OpenVPN) adicionam encapsulamento, reduzindo o MTU efetivo:

• IPsec ESP tunnel (AES-CBC + HMAC-SHA1): ~50 bytes de overhead → MTU 1450.
• GRE: 24 bytes → MTU 1476.
• WireGuard (UDP): ~80 bytes → MTU 1420.
• OpenVPN UDP: ~70-90 bytes → MTU 1400-1450.
• VXLAN: 50 bytes → MTU 1450 (exige jumbo frames no underlay).

Sem PMTUD funcional ou MSS clamping, VPNs sofrem com "black hole" — sintoma clássico de consultas que funcionam no site local mas travam via túnel.

9. IPv6: Sem Fragmentação em Roteadores

A RFC 8200 (IPv6) proíbe que roteadores intermediários fragmentem. Apenas a origem fragmenta, e ela deve descobrir o MTU do caminho previamente via PMTUD (RFC 8201). Se um pacote IPv6 excede o MTU de um enlace, o roteador descarta e envia ICMPv6 Type 2 "Packet Too Big", contendo o MTU aceitável.

A origem então divide o pacote usando o cabeçalho de extensão Fragment Header (Next Header 44). Como cada fragmento é um pacote IPv6 independente, o impacto em roteadores intermediários é zero — eles não precisam manter estado.

10. Jumbo Frames

Em datacenters, o MTU é frequentemente configurado para 9000 bytes (Jumbo Frame), reduzindo o overhead de cabeçalho em transferências grandes (storage iSCSI, replicação, vMotion). Cálculo simples:

• 1 GB de dados em MTU 1500: ~715.000 quadros, ~28 MB de overhead de cabeçalho.
• Em MTU 9000: ~119.000 quadros, ~1,9 MB de overhead.

Redução de 93% no overhead e no número de interrupções no NIC. Porém, jumbo frames não atravessam a internet — precisam ser locais ao datacenter ou habilitados ponta-a-ponta no underlay.

11. Comandos Práticos

# Descobrir PMTU para um destino
tracepath example.com
ip route get 203.0.113.10

# Ping com DF e tamanho fixo (1472 = 1500 - 28 ICMP+IP)
ping -M do -s 1472 example.com       # Linux
ping -D -s 1472 example.com          # macOS
ping -f -l 1472 example.com          # Windows

# Alterar MTU da interface
ip link set dev eth0 mtu 9000
ethtool -G eth0 rx 4096 tx 4096

# Verificar MTU
ip link show eth0
cat /sys/class/net/eth0/mtu

! Cisco IOS
Router(config)# interface GigabitEthernet0/0
Router(config-if)# ip tcp adjust-mss 1380     ! MSS clamping
Router(config-if)# mtu 9000                   ! jumbo frames

12. Boas Práticas

1. Habilitar PMTUD em todos os hosts (default na maioria dos SOs modernos).
2. Nunca bloquear ICMP Type 3 Code 4 sem considerar o impacto.
3. Aplicar MSS clamping em bordas de VPN e PPPoE.
4. Padronizar MTU em todo o datacenter para jumbo (9000) ou standard (1500), sem misturas no mesmo domínio L2.
5. Monitorar fragmentação via SNMP (ipForwDatagrams, ipFragCreates) e NetFlow.
6. Documentar MTU de cada enlace no IPAM/CMDB.
7. Testar PMTU após mudanças de topologia com tracepath.

13. Resumo

A fragmentação é uma "válvula de escape" do IPv4 — necessária quando o MTU do enlace é menor que o pacote, mas custosa e fonte de problemas. A PMTUD evita a fragmentação em tempo de execução, mas depende de ICMP fluindo livremente. O IPv6 removeu a fragmentação de roteadores e a delegou à origem. Em ambientes modernos (VPNs, cloud, datacenter), o ajuste fino de MTU e MSS é parte essencial do design de rede — ignorar esse detalhe causa sintomas bizarros difíceis de diagnosticar.