Resumo

  • Uma REQ leva um token de quatro octetos, EOL completa o tamanho de teste e uma RES correspondente confirma que a sonda chegou ao receptor UDP Options.
  • A conclusão pertence ao 5-tuple, ao caminho e ao instante medidos. ECMP e multihoming exigem estado separado e a PLPMTU precisa de validação periódica.
  • A falta de resposta pode refletir perda na ida, espera por tráfego de retorno, limite de taxa ou perda na volta; não diagnostica sozinha uma MTU menor.

O recibo responde a uma pergunta pequena

A RFC 9869 aplica DPLPMTUD a UDP Options. O emissor inclui um token em REQ e usa EOL com preenchimento para formar o datagrama do tamanho escolhido. A sonda pode ficar acima da estimativa atual de PLPMTU, nunca acima do MTU da interface, e não deve sofrer fragmentação IP. O receptor devolve em RES o último token recebido.

Se o token coincide, há um fato positivo: aquela sonda alcançou o processamento UDP Options remoto. Isso não comprova que dados chegaram à aplicação, foram aceitos ou produziram resultado. Também não mede o limite do caminho reverso nem garante que o próximo pacote seguirá a mesma rota.

Sondas usadas para aumentar a PLPMTU, portanto, não deveriam carregar dados de aplicação. Perder candidatos grandes faz parte da descoberta. A sonda sem payload não sobe à camada superior. Pacotes com dados podem confirmar ou validar um tamanho em uso, mas não devem explorar o aumento.

A vida do token protege a atribuição

O token precisa ser único no 5-tuple durante o Maximum Segment Lifetime e não pode ser reutilizado nesse intervalo. Valor inicial aleatório e sequência imprevisível dificultam respostas forjadas fora do caminho. Ainda assim, salvar apenas a PLPMTU final elimina sua justificativa: token, tamanho, endereços, portas, rota, horários, tentativa e versão do software.

Os dois aplicativos precisam habilitar o serviço explicitamente; o receptor não pode responder antes disso. Se o transporte e um protocolo superior executarem DPLPMTUD em paralelo, devem coordenar ou separar os tokens. Uma resposta legítima atribuída à máquina de estados errada continua sendo evidência mal ligada.

O método é voltado principalmente a unicast e não atende multicast. O receptor pode gerar resposta vazia para acelerar o avanço, mas o tráfego composto apenas de respostas deve ter limite de taxa.

Cada rota tem sua própria memória

Em multipath, ECMP ou multihoming, a RFC exige estado independente para cada caminho. O gargalo pertence à rota percorrida, não ao nome remoto. Copiar o valor bem-sucedido para uma alternativa troca uma medição por uma suposição.

O tempo também muda o limite. Rotas, túneis e políticas podem mudar; uma restrição temporária pode desaparecer. Validar periodicamente a PLPMTU atual impede que um sucesso histórico se torne autoridade eterna e permite revisar um teto aprendido durante uma falha transitória.

O silêncio pode nascer no retorno

O receptor pode esperar um datagrama de retorno já previsto para anexar a RES. Se várias sondas chegarem antes dele, apenas o token mais recente pode ser confirmado, fazendo sondas anteriores parecerem perdidas. Com pouco tráfego reverso, o emissor pode ficar abaixo da capacidade real ou até na PLPMTU mínima.

Uma resposta vazia dedicada reduz a espera, mas sofre limite de taxa. Logo, timeout pode significar perda da sonda, política do receptor, fila, limitação ou perda reversa. A reação conservadora da máquina de estados não autoriza atribuir uma causa única.

O uso de ICMP Packet Too Big é opcional. Se processado, o protocolo citado deve ser validado e o token REQ deveria ser conferido quando possível. Mensagem que não puder ser validada deve ser ignorada. Tokens imprevisíveis reduzem falsificação fora do caminho, não a interferência de quem está nele.

Fontes