Resumo

  • Registros A e AAAA oferecem destinos candidatos; não provam que o caminho correspondente está acessível a partir daquele cliente naquele momento.
  • RFC 6555 deu a IPv6 uma vantagem inicial limitada. RFC 8305 refinou o processo com DNS assíncrono, ordenação RFC 6724, alternância entre famílias e tentativas sobrepostas, mas ritmadas.
  • A primeira conexão estabelecida vence apenas aquela escolha. A recuperação quase invisível melhora a experiência e pode esconder do operador uma família que falha todos os dias.

O nome sabia o endereço, não sabia o caminho

Em 1994, RFC 1671 já descrevia a armadilha da pilha dupla. Um nome podia devolver endereços das duas famílias, embora um roteador, túnel, peering ou serviço descartasse IPv6 em algum ponto. A informação publicada no DNS não precisava estar errada. Ela apenas não continha a observação de alcance feita pelo cliente.

Aplicações que percorriam a lista em série convertiam essa ausência em demora. Tentavam IPv6, aguardavam retransmissões e só depois chegavam ao IPv4 funcional. O equipamento com mais capacidades parecia pior do que o antigo. Desligar IPv6 removia o sintoma, produzindo um incentivo perverso: a transição ensinava o usuário a abandoná-la.

Um nome separado para IPv6 quebraria o identificador compartilhado. Listas estáticas não acompanhariam falhas intermitentes e caminhos diferentes. A decisão precisava acontecer onde a evidência surgia: na tentativa real de conexão.

Preferência passou a significar largar primeiro

RFC 6555 padronizou Happy Eyeballs em 2012. Não era uma corrida neutra em que IPv4 e IPv6 saíam juntos. A política de endereços do host continuava valendo e, em geral, colocava IPv6 primeiro. Se a tentativa preferida não terminasse logo, porém, outra tentativa começaria pela família alternativa.

Assim, política escolhia a primeira experiência; código em execução escolhia o transporte daquela sessão. A preferência deixou de ser um direito de bloquear.

Existe custo nessa liberdade. Tentativas adicionais criam estado no servidor, no firewall e no NAT, além de usar tráfego. A especificação manda espaçar as partidas e abandonar as conexões perdedoras. Tratar as famílias como perfeitamente iguais manteria carga desnecessária sobre IPv4 compartilhado; dar exclusividade prolongada a IPv6 cobraria do usuário pela falha de terceiros.

O histórico de falhas também recebe limites. Um cliente pode lembrar que uma família não funcionou, mas deve testar novamente a preferida de tempos em tempos; RFC 6555 sugere a ordem de dez minutos. Ao entrar em outra rede, o estado precisa ser reiniciado. A lembrança de um hotel não tem autoridade na rede doméstica.

A versão 2 incluiu o tempo do DNS

RFC 8305, de 2017, substituiu a primeira descrição. Ela separa quatro fases: consultas DNS assíncronas, ordenação de destinos, tentativas assíncronas e escolha de uma conexão com cancelamento das demais.

AAAA e A são consultados quase em sequência, AAAA primeiro. Se A chega antes, o cliente dá uma janela curta para AAAA; o valor recomendado é 50 milissegundos. IPv6 preserva uma pequena prioridade sem fazer uma resposta DNS atrasada congelar um IPv4 já conhecido.

Os candidatos disponíveis são classificados conforme RFC 6724. Endereço de origem viável, escopo, rótulo e política local formam uma ordem. Estar na frente não é certificado de alcance.

Depois, as famílias são intercaladas. Se IPv6 ocupa o primeiro lugar, o melhor IPv4 normalmente passa ao segundo. Isso impede que uma sequência de vários AAAA quebrados consuma vários intervalos antes da primeira chance de um A.

As conexões começam uma por vez e podem permanecer simultaneamente em andamento. RFC 8305 recomenda 250 milissegundos como intervalo padrão, proíbe menos de 10 milissegundos, recomenda 100 como mínimo e dois segundos como máximo. São parâmetros empíricos e ajustáveis. Histórico de tempo de ida e volta pode influenciar o ritmo, mas não deve atravessar interfaces e precisa desaparecer quando a rede muda.

Quando um estabelecimento termina, as outras tentativas são canceladas e os endereços ainda não usados são ignorados para aquela conexão. Respostas DNS tardias podem alimentar o cache por um breve período; não reabrem a decisão concluída.

Ganhar o início não prova o fim

Happy Eyeballs trata falhas iniciais da conexão. Um aperto de mão TCP concluído não garante TLS válido, HTTP consistente nem passagem de pacotes maiores. RFC 8305 avisa que um defeito de MTU pode aparecer apenas depois e ficar invisível durante a seleção.

O endereço vencedor tampouco autentica o serviço. DNS muda, e conexões sucessivas ao mesmo nome podem escolher IPs diferentes. Identidade pertence à camada que conhece a identidade esperada.

Há ainda o paradoxo de operação. Se IPv6 falha sempre e IPv4 assume após um quarto de segundo, o usuário vê sucesso. O operador pode não ver o incidente. Por isso o documento recomenda monitorar cada família por meios independentes. Recuperar a sessão não é reparar a infraestrutura.

Fontes e limites

O conjunto fechado é RFC 1671, RFC 6555, RFC 6724 e RFC 8305. Ele não fornece participação atual de implementações, desempenho mundial por família nem um atraso ideal para todas as redes.