Resumo

  • draft-munizaga-quic-alternative-server-address-02 propõe um conjunto completo de candidatos, substituído por número de sequência e dividido por CURRENT_PATH entre preferidos e reservas; ainda é um Internet-Draft individual.
  • Anunciar não cria caminho. A prioridade é uma dica relativa, o cliente pode ignorá-la por política e dados comuns exigem validação do caminho na direção apropriada.
  • Anúncio, admissão local, validação, uso e efeito agregado precisam de recibos distintos, pois muitos clientes reagindo juntos podem transformar uma dica legítima em uma avalanche contra outro endpoint.

O problema começa depois que a conexão já existe. O endereço usado pelo servidor pode perder preferência, enquanto outra interface, proxy ou relay se torna mais conveniente. O mecanismo atual de endereço preferido nasce no handshake. A nova trama ALTERNATIVE_ADDRESS tenta manter essa informação mutável ao longo da sessão.

O servidor envia a lista inteira com um Sequence Number. Um número maior substitui o estado anterior e impede que reordenação da rede faça o cliente voltar no tempo. A ausência de um endereço no novo quadro retira o anúncio. Ainda assim, trocar o registro do servidor não comprova que o cliente cancelou sondagens antigas, drenou pacotes ou parou de usar imediatamente um caminho não atual.

Há exatamente um marcador CURRENT_PATH. Sem multipath, os itens antes dele ficam acima do caminho atual; os posteriores são reservas. O número de prioridade vale apenas dentro de cada lado. As dicas são consultivas: o cliente escolhe quais candidatos validar, se executa testes em paralelo e qual caminho validado usa.

Essa escolha local protege diferenças que o servidor não enxerga. Um IPv4 privado ou IPv6 local pode funcionar para um cliente e ser inútil para outro. NAT, interface, energia, política corporativa e quantidade de Connection IDs livres alteram o custo da sondagem. Sem identificador disponível, nem mesmo uma entrada “preferida” pode ser testada de imediato.

A validação responde a uma pergunta estreita. Um PATH_CHALLENGE vai para o candidato; o PATH_RESPONSE correspondente pode voltar por outro caminho e ainda validar aquele em que o desafio foi enviado. Receber uma sonda autenticada de uma origem não anunciada não valida a própria origem. O recibo deve nomear desafio, alvo, direção, tempo e resultado.

O servidor também valida sua direção antes de transmitir dados não exploratórios. Depois, o caminho pode substituir o atual, somar-se a ele em multipath, permanecer reserva ou nunca carregar aplicação. A especificação multipath não escolhe o algoritmo de escalonamento. RTT, perda, congestionamento e continuidade pertencem ao caminho usado de verdade.

O risco coletivo rompe a intuição de que autenticação basta. Um servidor malicioso pode indicar uma vítima como alternativa superior para milhares de clientes. Cada cliente recebe uma trama protegida e pode completar uma validação correta, mas o conjunto cria sobrecarga. O rascunho menciona atraso aleatório; não define orçamento global, consentimento do destino nem medição da convergência.

Na leitura de Heng Lu, a lista é um artefato de coordenação, não autoridade. A gramática comum deve ser mínima; o participante que executa mantém a futura decisão local. Publicação, registro, implementação e tráfego observado são camadas separadas. Em 25 de setembro de 2026, a revisão 02 continuava individual, I-D Exists, sem stream ou AD, e os valores pedidos não apareciam no retrato do registro IANA.

Fontes