Resumo

  • No IPv4 original, um gateway podia fragmentar o datagrama que não coubesse no próximo enlace, deixando a remontagem para o destino. A heterogeneidade sumia da vista, mas a perda de um fragmento comprometia o conjunto.
  • O PMTUD clássico fez a origem marcar DF e diminuir o tamanho após receber ICMP de fragmentação necessária. Quando a mensagem era filtrada, pacotes pequenos passavam e a transferência grande caía num buraco negro.
  • O PLPMTUD passou a testar a entrega na camada que monta pacotes. O caminho ainda oferece evidência, mas a origem mantém a estimativa, valida sinais e revê a decisão quando a rota muda.

Grande demais para a próxima rede

As redes interligadas não compartilhavam um tamanho máximo. O RFC 791, de setembro de 1981, colocou endereçamento e fragmentação entre as duas funções básicas do IP. Se um datagrama encontrasse adiante uma rede que só aceitava pacotes menores, um gateway podia dividi-lo.

Identification, Fragment Offset e More Fragments permitiam ao destino reconstruir as partes. O transporte não precisava conhecer cada tecnologia intermediária. Mas o custo aparecia no ponto estreito: mais pacotes, processamento no roteador, estado de remontagem e o fracasso do datagrama inteiro quando faltava uma parte.

O bit Don't Fragment já abria outra possibilidade. Um pacote DF grande demais não podia ser recortado; deveria ser descartado. Isso devolvia à origem a chance de adaptar o envio, desde que ela recebesse uma explicação. Sem retorno, a perda parecia congestionamento ou defeito qualquer.

Path MTU é o menor MTU entre os enlaces da rota atual. Não é atributo eterno do destino. Mudanças de rota, cabeçalhos de túnel e ramos de multipath alteram o limite utilizável.

A opção que todos os gateways precisavam editar

Em julho de 1988, o RFC 1063 propôs que o caminho escrevesse seu mínimo. Probe MTU sairia com o valor do primeiro enlace. Cada gateway compararia interfaces de entrada e saída e reduziria o campo. Reply MTU levaria a resposta à origem.

A proposta reconhecia o dilema: pacotes conservadores desperdiçam capacidade e multiplicam cabeçalhos; palpites grandes causam fragmentação; sondas extras consomem rede e envelhecem com a rota. Também separava TCP MSS de PMTU. MSS trata da carga TCP que o par aceita; PMTU, do pacote IP que o percurso carrega.

O problema era a coordenação. Todos os gateways relevantes tinham de compreender e alterar a opção. O próprio documento dizia que alguns equipamentos não conheciam as interfaces necessárias naquele estágio do processamento e que o suporte poderia exigir mudanças importantes.

Só o enlace que recusa precisa falar

O RFC 1191, de novembro de 1990, pediu menos ao núcleo. A origem começa pelo MTU do primeiro salto e envia com DF. O roteador que não consegue encaminhar intacto descarta e devolve ICMP Destination Unreachable, com o código “fragmentação necessária e DF definido”. A origem reduz a estimativa.

Um campo ICMP antes sem uso passou a informar o MTU do próximo salto que causou a rejeição. O roteador não reescrevia todo pacote; produzia evidência apenas no fracasso. Continuar com DF permitia detectar uma rota futura mais estreita.

Roteadores antigos devolviam zero nesse campo. Para eles, o host descia por “patamares” de MTU associados a tecnologias comuns. Subestimar alguns pontos percentuais era melhor do que ultrapassar por um byte. A lista era orientação contemporânea, não registro perpétuo.

Uma rota também pode ficar mais larga. O cache precisa envelhecer e testar valores maiores em intervalos comedidos. Uma mensagem de erro pode reduzir a estimativa, nunca aumentá-la sozinha. Para subir, é preciso observar entrega.

Conectado para o aperto de mãos, travado para os dados

O método clássico depende da volta do ICMP. O RFC 2923, de 2000, registrou o buraco negro criado quando roteadores não geravam o aviso ou firewalls bloqueavam todo ICMP. A origem repetia o pacote DF grande demais sem aprender a diminuir.

O sintoma enganava. O handshake TCP usa pacotes pequenos e terminava. Ping e uma sessão interativa podiam funcionar. O primeiro segmento grande sumia e era retransmitido no mesmo tamanho até o timeout. O destino era alcançável para uma unidade e inalcançável para outra.

Recuar para um valor pequeno restaura o serviço, mas pode esconder uma política quebrada e manter perda de desempenho. Filtragem não é causa única: túneis adicionam cabeçalhos, rotas assimétricas separam dados e retorno, ICMP sofre limitação e a camada 2 pode descartar sem gerar mensagem útil.

O RFC 8201, especificação atual de PMTUD para IPv6, descreve o mesmo handshake bem-sucedido seguido de dados parados quando Packet Too Big é bloqueado. Roteadores IPv6 não fragmentam em trânsito; a origem escolhe o tamanho e produz fragmentos quando necessário.

Demonstrar sucesso na ponta

Em 2007, o RFC 4821 trocou a espera por uma explicação de falha por uma prova de entrega. O Packetization Layer PMTUD parte de um tamanho funcional e envia sondas progressivamente maiores. Confirmação eleva o limite inferior; falha conclusiva de uma sonda isolada reduz o superior.

A camada de empacotamento decide como dados viram pacotes — TCP no exemplo habitual — e sabe qual sonda foi reconhecida. Pode manter dados comuns num valor seguro enquanto testa. Contudo, um timeout ou perdas adicionais tornam o resultado inconclusivo e exigem controle de congestionamento normal. Nem toda perda é MTU.

O sucesso também tem escopo. Uma sonda comprova que aquele pacote atravessou o caminho observado naquele momento; não garante a rota futura nem todos os ramos de custo igual. Por isso a busca usa faixas, repetição, temporizadores e estado perecível.

PLPMTUD pode aproveitar ICMP ou avançar sem ele. Não declara irrelevante o conhecimento do roteador; apenas impede que um único canal ausente detenha a conexão para sempre. A robustez custa lógica de confirmação, busca, contagem de cabeçalhos e coordenação com congestionamento.

Datagramas precisam fornecer confirmação

IPv6 mantém a necessidade da descoberta. Ficar no mínimo IPv6 evita certa fragilidade, mas desperdiça caminhos mais largos. Procurar acima dele requer um método que suporte a ausência de PTB.

O RFC 8899, de 2020, definiu DPLPMTUD para transportes e aplicações de datagramas, incluindo protocolos sobre UDP, SCTP e QUIC. Quando o transporte não oferece confirmação, a aplicação precisa criar um meio de reconhecer a chegada da sonda.

Dados normais ficam até o tamanho efetivo; uma sonda identificada pode excedê-lo. Detectar buraco negro reduz o valor; confirmações permitem buscar acima. PTB validado acelera, mas é entrada opcional e deve corresponder a tráfego realmente enviado.

Não houve uma única transferência de poder do núcleo para as pontas. Fragmentação ocultava diversidade e ampliava custos. A opção de 1988 coletava bom conhecimento local e exigia todos. ICMP falava somente no fracasso, mas dependia do retorno. A sondagem na ponta acrescentou a entrega real e limitou essa dependência.

Tamanho é uma decisão com prazo

MTU costuma virar um número decorado. A história mostra uma superfície de controle. O operador define o limite local; o roteador o aplica e pode reportar; o firewall pode apagar o relato; o host guarda estado do caminho; transporte ou aplicação monta o próximo pacote. Nenhum ator controla a rota inteira.

A regra compartilhada deve ser estreita: expor a restrição quando possível, permitir que a origem compare o relato com entrega e congestionamento, e fazer a conclusão expirar. O pacote não ganhou inteligência; a arquitetura colocou a decisão onde evidência e consequência podiam ser vistas juntas.

Fontes e limites

RFC 791 documenta fragmentação e DF; RFC 1063, opções atualizadas pelos gateways; RFC 1191, PMTUD clássico, next-hop MTU, patamares e envelhecimento. RFC 2923 descreve o buraco negro TCP. RFC 4821 define sondagem na camada de empacotamento, RFC 8201 o modelo IPv6 e RFC 8899 a extensão a datagramas.

São fontes de especificação e falhas reconhecidas, não um censo mundial de adoção, uma data universal de implantação ou uma medição atual de prevalência.