Resumo

  • preferred_address autentica o que o servidor ofereceu para aquela conexão, não a alcançabilidade do endereço pelo cliente.
  • Depois da confirmação do handshake, o cliente escolhe IPv4 ou IPv6, usa um ID de conexão ainda não usado e valida o caminho antes de migrar.
  • Validação, MTU, congestionamento e RTT, continuidade da aplicação e resultado de negócio são evidências separadas.

O erro operacional começa quando um inventário transforma o preferred address anunciado em endpoint ativo antes de qualquer teste do cliente. O QUIC permite que o servidor aceite a conexão em um endereço IP e ofereça outro pouco depois do handshake. Isso pode ser útil quando o endereço inicial é compartilhado por vários servidores e um endereço unicast pode oferecer maior estabilidade. A oferta, porém, não é uma medição do destino.

Somente o servidor envia o parâmetro de transporte preferred_address, dentro do handshake TLS. Recebê-lo de forma autenticada prova quais valores o par forneceu para aquela conexão. Não prova que o cliente alcança o tuple IPv4 ou IPv6, que a validação terá sucesso, nem que o caminho possui MTU utilizável, capacidade disponível, disponibilidade futura, continuidade da aplicação ou sucesso comercial.

O parâmetro pode trazer endereço e porta IPv4 e endereço e porta IPv6. Uma família pode ser omitida com endereço e porta totalmente zerados. Isso dá ao cliente uma opção compatível com seu acesso de rede; não significa que ambos os caminhos foram testados por ele. Com o handshake confirmado, o cliente escolhe um endereço e inicia a validação. O servidor não inicia essa migração. O cliente deveria usar um ID de conexão ativo e anteriormente não usado de preferred_address ou NEW_CONNECTION_ID. O ID alternativo tem número de sequência 1 e vem com um Stateless Reset Token de 16 bytes. Ele não é vinculado ao endereço preferido e pode ser usado em qualquer caminho.

Um servidor que usa ID de comprimento zero não pode fornecer preferred address, e o parâmetro não pode conter um ID desse tipo. A violação é condição TRANSPORT_PARAMETER_ERROR. Antes da validação, o cliente não deve enviar quadros não-probing ao endereço preferido; isso reduz a exposição a falsificação de requisições. PATH_CHALLENGE e PATH_RESPONSE participam da validação, mas um resultado posterior não transforma a oferta inicial em medição retroativa.

Se a validação for bem-sucedida, o cliente deve enviar os pacotes seguintes ao novo endereço com o novo ID e parar de usar o endereço antigo do servidor. Se falhar, deve continuar enviando para o IP original. O servidor tem condições próprias: faz probing a partir do endereço preferido e continua enviando tráfego não-probing pelo endereço original até receber ali um pacote não-probing do cliente e validar o novo caminho. Somente depois das duas condições passa a enviar exclusivamente pelo endereço preferido, embora ainda possa processar pacotes atrasados no endereço antigo.

O preferred address vale apenas para a conexão que o forneceu; não pode ser reutilizado em outra conexão, inclusive uma conexão retomada. disable_active_migration não bloqueia esse procedimento explícito. Se o cliente se mover antes da migração, deve validar em paralelo os endereços original e preferido do servidor a partir do novo endereço do cliente. Uma mudança de binding NAT pode fazer o servidor observar outra fonte no endereço preferido. Nesse caso, ele aplica defesas contra falsificação e inicia validação para essa fonte.

O registro operacional deve separar recebimento autenticado; tuplas IPv4/IPv6 e famílias ausentes; resumo protegido do ID de sequência 1 e referência ao reset token; confirmação do handshake; família e decisão de seleção; ID realmente usado e seu estado de não uso; início, evidência, resultado e abandono da validação; troca do cliente e retorno ao endereço original; sondagem do servidor, validação do servidor, primeiro pacote do cliente que não seja de sondagem recebido no endereço preferido e troca do servidor; mudança de NAT; MTU; congestionamento/RTT; continuidade da aplicação; resultado de negócio.

Resumos que preservem privacidade e controles de retenção são recomendações de operação, não exigências do QUIC.

A distinção também separa este caso de TR-027, sobre convergência geral de migração; TR-040, sobre inventário de IDs; TR-059, sobre teto de recebimento versus MTU; TR-062, sobre evidência de retorno após validação concluída; e TR-047, sobre limites de inatividade. Validação concluída tem significado limitado. Um convite não vira garantia.