Resumo

  • A confirmação positiva prova que aquela sonda identificada, naquele tamanho, chegou à camada de empacotamento remota pelo caminho observado.
  • A RFC 8201 trata a MTU de caminho como estado variável; a RFC 8899 exige reconfirmação e estado separado por caminho quando há multipath ou multihoming.
  • Um registro verificável precisa unir endpoints, fluxo ou caminho, overhead, sonda, resposta, tempo e entrega representativa de dados.

Uma medição verdadeira com alcance exagerado

Considere um serviço que envia uma sonda preenchida até 1.450 bytes. O destino confirma exatamente essa sonda e o emissor eleva a PLPMTU. Pouco depois, um datagrama de aplicação do mesmo tamanho é colocado em outro membro ECMP. Nesse membro há mais overhead de túnel ou um enlace de MTU efetiva menor, e o pacote não chega.

O primeiro resultado continua verdadeiro. Ele descreve um pacote específico no caminho usado naquele instante. Não mediu todos os membros paralelos nem a rota futura. Quando o sistema guarda apenas “MTU OK”, perde o identificador da sonda, as chaves de fluxo, a geração da rota, o overhead e a idade da confirmação.

O que a PMTUD IPv6 mantém

A RFC 8201 define a PMTU como a menor MTU de enlace ao longo do caminho entre origem e destino. A origem pode começar pela MTU do primeiro salto e reduzir a estimativa após validar um ICMPv6 Packet Too Big. Podem ocorrer várias rodadas, pois um enlace ainda menor pode estar mais adiante.

Mudanças de topologia podem alterar a PMTU. Reduções aparecem por PTB; aumentos precisam ser procurados com tentativas periódicas de tamanho maior. Depois de uma redução, a RFC 8201 recomenda não tentar elevar o valor mais de uma vez a cada cinco minutos. O valor em cache tem envelhecimento e regra de renovação, não é propriedade permanente do destino.

Mesmo validado, um PTB comprova apenas uma restrição encontrada pelo tráfego correspondente. Não identifica sozinho qual rota mudou, qual túnel adicionou bytes ou se todos os caminhos paralelos possuem o mesmo teto.

O que a confirmação de DPLPMTUD comprova

A RFC 8899 leva a descoberta à camada que forma os datagramas. O emissor escolhe um tamanho e precisa de feedback que confirme a chegada daquela sonda ao endpoint remoto. Confirmada, a medida pode virar a PLPMTU atual.

É evidência mais forte que deduzir sucesso do silêncio, mas permanece específica. A perda de uma sonda não prova problema de MTU, pois congestão, erro e reordenação também existem. Uma confirmação também não transforma Search Complete em garantia vitalícia. Sem outra evidência de entrega, uma camada não confirmada usa o temporizador de confirmação para testar novamente o tamanho atual.

O método deve tolerar mudança de caminho, informação inconsistente, atraso, duplicação, reordenação e tráfego dividido entre vários caminhos. Havendo multipath ou multihoming, a RFC 8899 requer uma máquina de estados por caminho. Isso não combina com um único sinal verde por destino.

O orçamento de cabeçalhos faz parte do resultado

PLPMTU e carga útil disponível não são o mesmo número. Cabeçalhos IP, extensões, transporte, segurança e túneis consomem espaço. Uma nova encapsulação reduz o tamanho máximo da mensagem mesmo que a MTU física não mude.

Por isso o registro deve indicar a camada medida e o orçamento de cabeçalhos. Perdas repetidas correlacionadas ao tamanho justificam redução conservadora, mas não atribuem a causa sozinhas. Filtro, congestão, estado do receptor e perda comum continuam como hipóteses.

Fontes