Resumo

  • No RFC 1191, a origem IPv4 marca Don't Fragment; o router que encontra um enlace menor devolve por ICMP o next-hop MTU; o endpoint reduz sua estimativa. Observar e corrigir ficaram em camadas diferentes.
  • O RFC 2923 registrou o PMTUD black hole: sem o ICMP, uma conexão TCP podia abrir e começar a funcionar, mas parar nos segmentos grandes. MSS não era uma medição completa do caminho.
  • No caso da Cloudflare de 2015, TCP e ICMP passavam por hashes ECMP diferentes. A mensagem chegava à rede certa, porém ao backend sem o estado da conexão.
  • PLPMTUD e DPLPMTUD deram ao endpoint uma saída baseada em probes e confirmação de entrega. A menor dependência de ICMP veio com tráfego, estado e ambiguidade entre limite de MTU e outras perdas.

A explicação entrou no data center e perdeu o destinatário

A Cloudflare tinha ampliado o uso interno de Equal-Cost Multi-Path routing. Para TCP, o equipamento calculava um hash com IP e porta de origem e destino. Os pacotes de uma conexão eram, assim, mantidos no mesmo backend.

Para ICMP, o relato da empresa descreve um hash apenas com os endereços de origem e destino. Um Packet Too Big podia ser enviado a outro servidor, enquanto o fluxo TCP continuava no primeiro. A Cloudflare declarou que foi exatamente isso que ocorreu.

O postmortem fala em apenas alguns usuários de túneis IPv6. Não é uma medição de prevalência mundial, nem permite atribuir dano ou culpa a terceiros. Ele comprova uma falha mais específica: uma organização pode receber evidência de controle sem entregá-la ao estado que lhe dá significado.

Como remendo, a empresa baixou o MTU de IPv6 para 1280 e ativou o probing do RFC 4821 em IPv4. Depois criou um daemon que capturava fragmentation needed de IPv4 e Packet Too Big de IPv6 e fazia broadcast para todos os servidores.

O repositório público trazia limites padrão de um pacote por segundo por origem e dez por segundo por interface. Transformar evidência de uma conexão em informação compartilhada resolvia o problema de propriedade do estado, mas exigia controle de capacidade, validação e abuso. Era uma resposta arquitetural local, não uma receita universal.

Antes do PMTUD, o conservadorismo também cobrava seu preço

O RFC 1191, de 1990, define Path MTU como o menor MTU dos hops entre origem e destino. Não é propriedade permanente de um endereço ou prefixo. Uma mudança de rota ou a inclusão de um túnel pode mudar o mínimo sem alterar os endpoints.

Uma prática anterior usava o menor valor entre 576 octetos e o MTU do primeiro hop. Ela evitava presumir que um caminho desconhecido aceitaria um datagrama grande. Também desperdiçava capacidade em caminhos mais largos e ainda podia levar a fragmentação caso um router posterior tivesse um enlace menor.

Na fragmentação IPv4, o ajuste passava para a rede. Um router dividia o datagrama e o destino remontava as partes; perder uma delas comprometia o original. A experiência consolidada no RFC 8900 adicionou middleboxes com estado, filtros, túneis e caminhos desiguais à lista de fragilidades.

As opções eram todas imperfeitas: enviar sempre pequeno, deixar routers fragmentarem, pedir evidência explícita ao caminho ou combinar os mecanismos. O RFC 1191 escolheu o feedback para aproveitar melhor a capacidade real sem tornar a fragmentação intermediária o padrão.

O router tinha a medida; a origem tinha a decisão

No PMTUD clássico de IPv4, a origem ativa Don't Fragment. Se um router não consegue encaminhar o datagrama pelo próximo enlace, descarta-o e envia ICMP Destination Unreachable com o código fragmentation needed.

O RFC 1191 exige o next-hop MTU na mensagem. O host reduz sua estimativa e pode mandar pacotes menores ou deixar de usar DF. O router informa sua restrição local, mas não escolhe a política do transporte.

Essa divisão cria a dependência. O router observa diretamente uma interface. O endpoint controla a packetização. Nenhum possui a superfície de controle do outro; a mensagem ICMP conecta evidência e ação.

Um aumento é tratado com mais desconfiança. O endpoint não pode elevar a estimativa porque um ICMP anuncia valor maior. Precisa testar depois. O RFC recomendou esperar ao menos cinco minutos após uma redução, de preferência dez, antes de tentar crescer.

Esses tempos são orientação histórica, não retrato de toda stack atual. Eles mostram a fronteira da evidência: rotas mudam e uma mensagem pode ser antiga ou falsa; um número observado não vira autorização eterna.

IPv6 tirou a fragmentação dos routers

A especificação-base atual de IPv6 exige que cada enlace transporte 1280 octetos ou ofereça fragmentação e remontagem abaixo de IP. Routers IPv6 não fragmentam pacotes em trânsito. Apenas a origem pode adicionar Fragment header.

O RFC 8200 recomenda fortemente PMTUD para aproveitar tamanhos acima de 1280. Uma implementação mínima pode permanecer em 1280. Isso reduz a dependência de descoberta e abre mão da eficiência possível em caminhos maiores; não prova que o MTU real seja 1280.

Pelo RFC 8201, um router que não consegue encaminhar envia ICMPv6 Packet Too Big. O endpoint deve validar que o pacote citado corresponde a tráfego que enviou. Uma mensagem válida reduz a estimativa, mas não abaixo do mínimo IPv6.

Packet Too Big nunca serve para aumentar o valor. Depois de uma redução, a origem pode testar para cima em intervalos de pelo menos cinco minutos, com dez recomendados. O router declara um limite; o endpoint verifica o contexto e mantém a decisão.

O RFC 4890 coloca Packet Too Big entre as mensagens ICMPv6 que um firewall não deve descartar, pois a comunicação pode ser impedida ou seriamente afetada. É uma recomendação operacional clara, não prova de cumprimento universal nem licença para aceitar todo ICMP sem validação.

O black hole escondia a explicação, não a restrição

O RFC 2923 descreveu em 2000 um problema antigo. Router, falha de kernel, configuração ou firewall impedia o retorno do ICMP. A origem continuava enviando um tamanho que o caminho descartava.

TCP tornava o problema parcial. O handshake, pequeno, podia passar. Os primeiros dados também. Quando surgia um segmento maior, ele sumia e as retransmissões repetiam o tamanho. O exemplo de FTP separava um canal de controle funcional de uma transferência em massa travada.

Esse padrão é um gatilho de investigação, não um veredicto. Congestionamento, corrupção ou políticas assimétricas podem imitar a perda. O diagnóstico exige tamanho, família IP, DF ou Fragment, retransmissões e o conteúdo citado em qualquer ICMP.

MSS não substitui o path MTU. Ele anuncia o maior payload TCP que o receptor aceita. Não mede cada túnel no sentido de ida e não garante simetria no retorno.

O RFC 2923 preferia corrigir o black hole de ICMP. Uma detecção local também podia reduzir o pacote após timeouts. Isso restaurava algumas sessões, mas acrescentava segundos e escondia uma falha de caminho que continuava para outros fluxos.

Filtrar localmente não certifica o que o caminho suporta

Um operador pode ter autoridade legítima para definir a política de seu firewall. As fontes não autorizam alegações de malícia, ilegalidade ou motivação privada de qualquer operador específico.

O limite verificável é outro. Descartar Packet Too Big não torna o pacote grande encaminhável. Remove a evidência e mantém a restrição. O filtro ganha veto prático sobre a adaptação sem ganhar o conhecimento do enlace ou a responsabilidade do endpoint.

Túneis adicionam cabeçalhos depois que o endpoint escolhe o tamanho. ECMP e anycast podem separar a instância dos dados daquela que recebe o erro. Um valor de MTU sem tempo, direção, fluxo e encapsulamento não é atributo duradouro de um bloco de endereços.

Para titulares de recursos numéricos, isso evita uma conclusão errada. Um RIR aloca endereços; não certifica o MTU fim a fim de toda rota. ASN, prefixo e IP de serviço podem ficar iguais enquanto uma mudança operacional quebra apenas os pacotes grandes.

PLPMTUD transformou silêncio em teste

O RFC 4821 definiu em 2007 o Packetization Layer PMTUD. A camada que forma pacotes envia probes progressivamente maiores e aprende com entrega ou perda, sem depender de a mensagem ICMP chegar.

O endpoint recupera uma saída, não certeza. Perder uma sonda grande isolada pode indicar o limite. Se outros pacotes próximos também se perdem, congestionamento ou outra causa torna o resultado inconclusivo. São necessários estado de busca, timers e retestes cuidadosos.

A carta do IETF PMTUD Working Group registrou as fraquezas do mecanismo anterior como impedimento crônico para novos enlaces e túneis. A direção era começar pequeno e testar para cima sem depender de ICMP. A carta comprova um escopo institucional, não consenso ou adoção universal.

O RFC 8899 levou o princípio a camadas de packetização de datagramas. DPLPMTUD testa tamanhos, aumenta o confirmado após prova de entrega e reduz ao detectar black hole. Pode usar um PTB validado, mas não só ele, e nunca para aumentar.

UDP não fornece acknowledgement sozinho. A aplicação ou camada de packetização precisa confirmar a sonda. Ao mover poder para o endpoint, o projeto move junto tráfego, estado e a obrigação de interpretar perda.

O acordo atual mantém mecanismos concorrentes

A especificação TCP vigente recomenda fortemente PMTUD e recomenda PLPMTUD. Tamanhos pequenos de fallback permanecem, enquanto o RFC 9293 alerta para o custo de desempenho. O probing não aboliu o sinal do router; criou uma saída para a ausência dele.

A documentação Linux atual mostra o menu. tcp_mtu_probing=0 desativa probing; modo 1 ativa depois de detectar um ICMP black hole; modo 2 o mantém ativo a partir de um base MSS. O intervalo documentado tem default de dez minutos.

Isso prova controles do produto, não configuração mundial. A base instalada conserva hosts, firewalls, túneis, transports e aplicações de gerações diferentes. Esse descompasso é o mecanismo de lock-in.

Por isso o RFC 8900 não declarou a fragmentação obsoleta. Catalogou a fragilidade e pediu que as camadas superiores reduzissem dependência. O resultado combina sinal explícito, validação, probing no endpoint e fallback conservador.