Como evitar atrasos associados aos registros IPv6 AAAA?

Nossos servidores Windows estão registrando AAAAregistros IPv6 nos servidores DNS do Windows. No entanto, não temos o roteamento IPv6 ativado em nossa rede, portanto, isso frequentemente causa comportamentos de estol.

O Microsoft RDP é o pior infrator. Ao conectar-se a um servidor que possui umAAAA registro no DNS, o cliente da área de trabalho remota tentará o IPv6 primeiro e não voltará ao IPv4 até que a conexão expire. Usuários avançados podem solucionar esse problema conectando-se diretamente ao endereço IP. A resolução do endereço IPv4 ping -4 hostname.foosempre funciona instantaneamente.

O que posso fazer para evitar esse atraso?

• Desativar IPv6 no cliente?
  • Não, a Microsoft diz IPv6 é uma parte obrigatória do sistema operacional Windows.
  • Muitos clientes para garantir que isso seja definido em todos os lugares de maneira consistente.
  • Causará mais problemas mais tarde, quando finalmente implementarmos o IPv6.
• Desativar IPv6 no servidor?
  • Não, a Microsoft diz que o IPv6 é uma parte obrigatória do sistema operacional Windows.
  • Requer um corte de registro inconveniente para desativar toda a pilha IPv6.
  • Garantir que isso esteja definido corretamente em todos os servidores é inconveniente.
  • Causará mais problemas mais tarde, quando finalmente implementarmos o IPv6.
• Mascarar registros IPv6 no recursor DNS do usuário?
  • Não, estamos usando o NLNet Unbound e ele não suporta isso .
• Impedir o registro de registros IPv6 AAAA no servidor DNS da Microsoft?
  • Eu não acho que isso seja possível.

Neste ponto, estou pensando em escrever um script que limpe todos os registros AAAA de nossas zonas DNS. Por favor, me ajude a encontrar uma maneira melhor.

ATUALIZAÇÃO: a resolução do DNS não é o problema. Como @joeqwerty aponta em sua resposta, os registros DNS são retornados instantaneamente. Os registros Ae AAAAestão imediatamente disponíveis. O problema é que alguns clientes (mstsc.exe ) tentam preferencialmente uma conexão pelo IPv6 e demoram um pouco para voltar ao IPv4.

Isso parece um problema de roteamento. O pingcomando produz uma mensagem de erro "Falha geral" porque o endereço de destino não pode ser roteado.

C:\Windows\system32>ping myhost.mydomain
Pinging myhost.mydomain [2002:1234:1234::1234:1234] with 32 bytes of data:
General failure.
General failure.
General failure.
General failure.
Ping statistics for 2002:1234:1234::1234:1234:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

Não consigo obter uma captura de pacotes desse comportamento. A execução desse comando ping (com falha) não produz nenhum pacote no Microsoft Network Monitor. Da mesma forma, tentar uma conexão com mstsc.exeum host com umAAAA registro não produz tráfego até fazer um fallback para o IPv4.

ATUALIZAR: Todos os nossos hosts estão usando endereços IPv4 roteados publicamente. Eu acho que esse problema pode se dever a uma configuração 6to4 quebrada. 6to4 se comporta de maneira diferente em hosts com endereços IP públicos versus endereços RFC1918.

ATUALIZAÇÃO: Definitivamente, há algo suspeito com o 6to4 na minha rede. Quando desabilito o 6to4 no cliente Windows, as conexões são resolvidas instantaneamente.

netsh int ipv6 6to4 set state disabled

Mas como @joeqwerty diz, isso apenas mascara o problema. Ainda estou tentando descobrir por que a comunicação IPv6 em nossa rede não funciona completamente.

Essa pergunta é bem interessante e devo admitir que nunca vi esse comportamento. Para tentar entender melhor, peguei um trecho de consulta nslookup para um dos meus servidores W2K8R2 RDS de outro servidor W2K8R2 e também capturei um trecho de uma sessão RDP para o mesmo servidor RDS do mesmo servidor de teste . O nslookup não mostrou atraso no retorno do registro IPv6 e o ​​nslookup mostrou meu servidor de teste consultando o registro IPv4 antes de consultar o registro IPv6. O delta de tempo na captura não mostra nenhum atraso apreciável (que eu possa verificar) em qualquer consulta.

EDITAR

Agora você está no caminho certo.

Verifique se está capturando tráfego para o adaptador Microsoft 6To4, caso contrário você não verá o IPv6:

Aqui está o resultado do nslookup para o meu servidor RDS. Anote os endereços IPv6:

Agora, aqui está um trecho da minha captura:

E finalmente, aqui está um trecho do netstat mostrando a conexão:

Claramente, como você confirmou, a resolução do DNS não é o problema. O problema é que a conexão RDP prefere IPv6 sobre IPv4 (que é o padrão para Windows - Windows prefere IPv6 sobre IPv4) e porque o IPv6 não está funcionando corretamente, está causando o atraso (como você declarou) ao retornar do IPv6 para IPv4. Você pode corrigir isso configurando os clientes para preferir o IPv4 sobre o IPv6, mas acho que isso seria apenas mascarar o problema. A melhor solução seria descobrir por que o IPv6 não está funcionando e corrigir isso. Não sei o suficiente sobre o IPv6 para ajudar, mas acho que os registros IPv6 retornados pelo DNS são endereços "locais" válidos somente na sub-rede em que os hosts RDS existem e, como os clientes estão em uma sub-rede diferente, eles podem " t alcance esses endereços IPv6.

A tecnologia de transição IPv6 chamada 6to4 é famosa por causar problemas como este. Existem vários fatores no trabalho. Individualmente, eles são inofensivos, mas o efeito combinado é que os usuários finais podem sofrer atrasos na conexão.

Uma lista de fatores e pensamentos facilitadores sobre sua mitigação é apresentada abaixo.

O Windows ativa o 6to4 por padrão

Se seus hosts estiverem executando uma versão recente do Windows (Vista ou posterior), o Windows ativará oportunamente o encapsulamento 6to4 quando um endereço IPv4 publicamente roteável estiver disponível. Criticamente, isso se aplica a servidores e clientes.

Para descobrir se um sistema está usando 6to4, execute ipconfige procure um endereço IPv6 que comece com o prefixo 6to4 2002:. Seria algo assim.

C:\> ipconfig
Tunnel adapter 6TO4 Adapter:
IPv6 Address. . . . . . . . . . . : 2002:1111:2222::1111:2222

• Se seus pontos de extremidade estiverem conectados ao Active Directory, você poderá usar a Diretiva de Grupo para desativar protocolos de transição como 6to4 e Teredo. Isso está bem documentado no KB929852 . (Aplicar isso a seus clientes ou servidores seria suficiente, mas se você estiver executando esta etapa, provavelmente fará sentido desabilitá-la em qualquer lugar, tanto em clientes quanto em servidores.)
• Se você gerenciar apenas alguns hosts, poderá desativar o 6to4 caso a caso. Isso é muito melhor do que desativar totalmente o IPv6.netsh int ipv6 6to4 set state disabled
• Use um sistema operacional cliente diferente. Por exemplo, o Mac OS X não possui o 6to4 ativado por padrão.

Endereços IPv4 publicamente roteáveis ​​estão sendo usados

6to4 funciona apenas em hosts que possuem endereços IPv4 publicamente roteáveis, portanto esse problema nunca afeta os hosts atrás de um firewall NAT.

• Você pode mover clientes e / ou servidores para um firewall NAT e começar a usar o endereçamento RFC1918. Mas, em alguns casos, endereços publicamente roteáveis ​​são realmente preferidos. Alterar o endereçamento de uma rede inteira também pode ser uma escolha irrealista.

6to4 não está funcionando corretamente na rede

É extremamente difícil solucionar problemas de 6to4 no modo anycast. É tão problemático que houve um pedido formal à IETF que o 6to4 deve ser reclassificado como histórico . Na opinião deste autor, 6to4 foi preterido.

Em resumo, 6to4 funciona encapsulando pacotes IPv6 em pacotes IPv4 usando um protocolo chamado 6in4 (protocolo IP = 41). Os pacotes IPv4 são endereçados a qualquer endereço de broadcast, 192.88.99.1na esperança de que ele chegue a um retransmissor 6to4 em algum lugar da Internet. Pode até estar geograficamente próximo, se você tiver sorte.

Na prática, alguns relés 6to4 são configurados incorretamente e muitas redes nem permitem que o tráfego 6in4 atravesse o firewall. Normalmente, isso acontece quando um firewall permite todo o tráfego de saída, mas não permite explicitamente que os pacotes do protocolo IP 41 retornem pelo firewall. (TODO observe a RFC relevante para solução de problemas.) Essa falha ("buraco negro de entrada") e muitas outras estão descritas na RFC 6343 .

• Configure seu firewall para rejeitar em voz alta o protocolo IP 41 (com redefinições de TCP) quando enviado de hosts internos à sua rede. Isso deve resultar em um comportamento de "falha rápida" que faz mais sentido do que atrasos de conexão não determinísticos. Isso demonstrou funcionar em ambientes de teste limitados .
• Peça ao seu ISP ou provedor de transporte de primeiro salto que configure um relé 6to4 em funcionamento. Se isso for feito corretamente, resultará na melhor experiência para os usuários finais. Qualquer usuário final com um endereço IPv4 publicamente roteável poderá participar da Internet IPv6.

Registro DNS dinâmico

Em um ambiente típico do Active Directory, todos os computadores têm permissão para registrar seus próprios endereços no servidor DNS. Quando um host possui hospedagem múltipla, ele registra todos os seus endereços, mesmo em um túnel 6to4.

Como a maioria dos serviços de Internet não usa DNS dinâmico, esse problema geralmente é restrito a sites corporativos em que os clientes e servidores são todos "internos" à mesma rede.

• Você pode optar por desativar as atualizações dinâmicas de DNS. Então, se você não colocar nenhum registro de recurso AAAA no arquivo de zona, eles nunca serão atendidos. No entanto, o DNS dinâmico geralmente é desejável para servidores DNS internos. (Se você fizer isso, exclua também quaisquer registros AAAA que já possam estar presentes.)
• Configure o servidor DNS para não fornecer respostas para registros de recursos AAAA. Mas não faça isso, porque isso realmente causará problemas quando você deseja começar a implementar o IPv6. (Alguém sabe de um firewall DNS gratuito / de código aberto?)

O aplicativo cliente não falha normalmente

O cliente RDP da Microsoft é um exemplo de aplicativo cliente que não lida normalmente com problemas de roteamento IPv6. A maioria dos navegadores da Web é melhor para lidar com casos de borda do IPv6 como este, portanto, eles não tendem a mostrar esse comportamento.

• Tente usar um cliente diferente. Talvez você tenha sorte.

Sei que não é muito útil para essa situação, mas para implementadores que enfrentam um dilema semelhante, existe uma técnica de implementação conhecida como "Happy Eyeballs" (RFC 6555) que especifica uma técnica para conectar-se ao ipv4 e ipv6 simultaneamente e escolher o que se conectar primeiro.

Aqui estava a minha solução. Por padrão, o Windows concede às rotas IPv6 uma prioridade mais alta que as rotas IPv4. Se você editar a política de prefixo IPv6, poderá alterar esse comportamento para fazer com que ele use o IPv4 em preferência ao IPv6.

Para garantir que todos os sistemas da minha rede estejam configurados da mesma maneira, coloquei os seguintes comandos em um script .bat executado durante a instalação do software após a construção ou reforma de uma máquina.

netsh int ipv6 isatap set state disabled
netsh int ipv6 6to4 set state disabled
netsh interface teredo set state disable

netsh interface ipv6 delete prefixpolicy ::1/128
netsh interface ipv6 delete prefixpolicy ::/0
netsh interface ipv6 delete prefixpolicy 2002::/16
netsh interface ipv6 delete prefixpolicy ::/96
netsh interface ipv6 delete prefixpolicy ::ffff:0:0/96
netsh interface ipv6 delete prefixpolicy 2001::/32

netsh interface ipv6 add prefixpolicy ::1/128 50 0
netsh interface ipv6 add prefixpolicy ::ffff:0:0/96 40 1
netsh interface ipv6 add prefixpolicy ::/0 30 2
netsh interface ipv6 add prefixpolicy 2002::/16 20 3
netsh interface ipv6 add prefixpolicy ::/96 10 4
netsh interface ipv6 add prefixpolicy 2001::/32 5 5

Para explicar o que isso faz:

As três primeiras linhas desabilitam as interfaces de encapsulamento internas, pois são redundantes para a maioria das redes. Você pode querer não usar essas três linhas se não estiver fornecendo endereços IPv6 para suas máquinas. No meu caso, eu tenho um servidor DHCPv6 e uma infraestrutura associada que atribui o IPv6 à conectividade em túnel

O segundo bloco de comandos exclui todas as políticas de prefixo de roteamento IPv6 existentes.

O terceiro bloco recria as políticas de prefixo IPv6, mas usa um conjunto diferente de prioridades. Assim, o prefixo correspondente ao IPv4 recebe preferência sobre o IPv6, e a máquina deseja usar o IPv4, a menos que o aplicativo especifique o uso do IPv6.

Essa solução mantém a capacidade funcional de pilha dupla, mas a preferência pelo uso do IPv4 significa que sites com IPv6 incompleto, não confiável ou com desempenho ruim evitarão usá-lo, a menos que solicitado por um programa no sistema.

É minha opinião que fazer com que os sistemas operacionais usem o IPv6 em vez do IPv4 está realmente impedindo a adoção. Durante o período de transição, haverá momentos em que um host pensa que possui conectividade IPv6, mas na verdade não possui uma conexão totalmente funcional, levando ao mau funcionamento do software e a grandes atrasos. Muitas pessoas que conheço desabilitaram o IPv6 inteiramente em seu roteador como uma solução alternativa para os ISPs que implantam o IPv6 de uma maneira quebrada inicialmente antes de estabelecer a conectividade total, e essas pessoas simplesmente esquecerão de habilitá-lo novamente, deixando-os sem o IPv6 até reconfigurar o roteador novamente.