Comment éviter les retards associés aux enregistrements IPv6 AAAA?

Nos serveurs Windows enregistrent des enregistrements IPv6 AAAAavec nos serveurs DNS Windows. Cependant, le routage IPv6 n'est pas activé sur notre réseau, ce qui entraîne fréquemment des comportements de blocage.

Microsoft RDP est le pire contrevenant. Lors de la connexion à un serveur qui a un AAAAenregistrement dans DNS, le client de bureau distant essaiera d'abord IPv6 et ne retombera pas sur IPv4 tant que la connexion n'aura pas expiré. Les utilisateurs expérimentés peuvent contourner ce problème en se connectant directement à l'adresse IP. La résolution de l'adresse IPv4 avec ping -4 hostname.foofonctionne toujours instantanément.

Que puis-je faire pour éviter ce retard?

• Désactiver IPv6 sur le client?
  • Non, Microsoft dit qu'IPv6 est une partie obligatoire du système d'exploitation Windows.
  • Trop de clients pour que cela soit défini partout de manière cohérente.
  • Cela causera plus de problèmes plus tard lorsque nous implémenterons enfin IPv6.
• Désactiver IPv6 sur le serveur?
  • Non, Microsoft dit qu'IPv6 est une partie obligatoire du système d'exploitation Windows.
  • Nécessite un hack de registre gênant pour désactiver la pile IPv6 entière.
  • Il n'est pas pratique de s'assurer que ce paramètre est correctement défini sur tous les serveurs.
  • Cela causera plus de problèmes plus tard lorsque nous implémenterons enfin IPv6.
• Masquer les enregistrements IPv6 sur le récurseur DNS utilisateur?
  • Non, nous utilisons NLNet Unbound et il ne prend pas en charge cela .
• Empêcher l'enregistrement des enregistrements IPv6 AAAA sur le serveur DNS Microsoft?
  • Je ne pense pas que ce soit même possible.

À ce stade, j'envisage d'écrire un script qui purge tous les enregistrements AAAA de nos zones DNS. S'il vous plaît, aidez-moi à trouver un meilleur moyen.

MISE À JOUR: La résolution DNS n'est pas le problème. Comme le souligne @joeqwerty dans sa réponse, les enregistrements DNS sont retournés instantanément. Les enregistrements Aet AAAAsont immédiatement disponibles. Le problème est que certains clients ( mstsc.exe) tenteront préférentiellement une connexion via IPv6 et mettront un certain temps à revenir à IPv4.

Cela semble être un problème de routage. La pingcommande génère un message d'erreur «Échec général» car l'adresse de destination n'est pas routable.

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),

Je ne peux pas obtenir une capture de paquets de ce comportement. L'exécution de cette commande ping (en échec) ne produit aucun paquet dans Microsoft Network Monitor. De même, la tentative de connexion avec mstsc.exeun hôte avec un AAAAenregistrement ne produit aucun trafic jusqu'à ce qu'il effectue un retour à IPv4.

MISE À JOUR: Nos hôtes utilisent tous des adresses IPv4 publiquement routables. Je pense que ce problème pourrait se résumer à une configuration 6to4 cassée. 6to4 se comporte différemment sur les hôtes avec des adresses IP publiques par rapport aux adresses RFC1918.

MISE À JOUR: Il y a certainement quelque chose de louche avec 6to4 sur mon réseau. Lorsque je désactive 6to4 sur le client Windows, les connexions se résolvent instantanément.

netsh int ipv6 6to4 set state disabled

Mais comme le dit @joeqwerty, cela ne fait que masquer le problème. J'essaie toujours de savoir pourquoi la communication IPv6 sur notre réseau ne fonctionne pas du tout.

Cette question est assez intéressante et je dois admettre que je n'ai jamais vu ce comportement. En jouant un peu pour essayer de mieux le comprendre, j'ai pris un extrait de nslookup interrogeant un de mes serveurs W2K8R2 RDS à partir d'un autre serveur W2K8R2 et j'ai également capturé un extrait d'une session RDP vers le même serveur RDS à partir du même serveur de test . Nslookup n'a montré aucun retard dans le retour de l'enregistrement IPv6 et le nslookup a montré mon serveur de test interrogeant l'enregistrement IPv4 avant d'interroger l'enregistrement IPv6. Le delta de temps dans la capture ne montre aucun retard appréciable (que je peux vérifier) ​​dans les deux requêtes.

ÉDITER

Maintenant, vous êtes sur quelque chose.

Assurez-vous de capturer le trafic pour l'adaptateur Microsoft 6To4, sinon vous ne verrez pas IPv6:

Voici le résultat nslookup pour mon serveur RDS. Notez les adresses IPv6:

Voici maintenant un extrait de ma capture:

Et enfin, voici un extrait de netstat montrant la connexion:

Donc, comme vous l'avez confirmé, la résolution DNS n'est pas le problème. Le problème est que la connexion RDP préfère IPv6 à IPv4 (qui est la valeur par défaut pour Windows - Windows préfère IPv6 à IPv4) et parce qu'IPv6 ne fonctionne pas correctement, il entraîne le retard (comme vous l'avez indiqué) lors du retour d'IPv6 vers IPv4. Vous pouvez résoudre ce problème en configurant les clients pour qu'ils préfèrent IPv4 à IPv6, mais je pense que cela masquerait simplement le problème. La meilleure solution serait de comprendre pourquoi IPv6 ne fonctionne pas et de résoudre ce problème. Je ne connais pas suffisamment IPv6 pour vous aider, mais je suppose que les enregistrements IPv6 renvoyés par DNS sont des adresses "locales" valides uniquement sur le sous-réseau où les hôtes RDS existent et puisque les clients sont dans un sous-réseau différent, ils peuvent ' t atteindre ces adresses IPv6.

La technologie de transition IPv6 appelée 6to4 est tristement célèbre pour causer des problèmes comme celui-ci. Il y a plusieurs facteurs à l'œuvre. Individuellement, ils sont inoffensifs, mais l'effet combiné est que les utilisateurs finaux peuvent subir des retards de connexion.

Une liste des facteurs favorables et des réflexions sur leur atténuation est présentée ci-dessous.

Windows active 6to4 par défaut

Si vos hôtes exécutent une version récente de Windows (Vista ou version ultérieure), Windows activera de manière opportuniste le tunneling 6to4 lorsqu'une adresse IPv4 publiquement routable est disponible. Surtout, cela s'applique aux serveurs et aux clients.

Pour savoir si un système utilise 6to4, exécutez ipconfiget recherchez une adresse IPv6 commençant par le préfixe 6to4 2002:. Cela ressemblerait à quelque chose comme ça.

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

• Si vos points de terminaison sont connectés à Active Directory, vous pouvez utiliser la stratégie de groupe pour désactiver les protocoles de transition tels que 6to4 et Teredo. Cela est bien documenté dans KB929852 . (Appliquer cela à vos clients ou serveurs serait suffisant, mais si vous prenez cette mesure, il est probablement judicieux de le désactiver partout, à la fois sur les clients et les serveurs.)
• Si vous ne gérez que quelques hôtes, vous pouvez désactiver 6to4 au cas par cas. C'est bien mieux que de désactiver complètement IPv6.netsh int ipv6 6to4 set state disabled
• Utilisez un système d'exploitation client différent. Par exemple, Mac OS X n'a ​​pas activé 6to4 par défaut.

Des adresses IPv4 publiquement routables sont utilisées

6to4 ne fonctionne que sur les hôtes qui ont des adresses IPv4 publiquement routables, ce problème n'affecte donc jamais les hôtes derrière un pare-feu NAT.

• Vous pouvez déplacer des clients et / ou des serveurs derrière un pare-feu NAT et commencer à utiliser l'adressage RFC1918. Mais dans certains cas, les adresses publiquement routables sont en fait préférées. Changer l'adressage d'un réseau entier peut également être un choix irréaliste.

6to4 ne fonctionne pas correctement sur le réseau

Il est tristement difficile de dépanner 6to4 en mode anycast. Il est tellement gênant qu'il y avait une demande officielle à l'IETF que 6to4 devrait être reclassé comme historique . De l'avis de cet auteur, 6to4 est obsolète.

En bref, 6to4 fonctionne en encapsulant des paquets IPv6 dans des paquets IPv4 en utilisant un protocole appelé 6in4 (protocole IP = 41). Les paquets IPv4 sont adressés à une adresse anycast 192.88.99.1dans l'espoir qu'il arrivera à un relais 6to4 fonctionnel quelque part sur Internet. Il pourrait même être géographiquement proche, si vous avez de la chance.

Dans la pratique, certains relais 6to4 sont mal configurés et de nombreux réseaux ne permettent même pas au trafic 6in4 de traverser le pare-feu. Cela se produit généralement lorsqu'un pare-feu autorise tout le trafic sortant, mais n'autorise pas explicitement les paquets du protocole IP 41 à revenir via le pare-feu. (À NOTER, la RFC appropriée pour le dépannage.) Cette panne («trou noir entrant») et bien d'autres sont décrites dans la RFC 6343 .

• Configurez votre pare-feu pour rejeter bruyamment le protocole IP 41 (avec réinitialisation TCP) lorsqu'il est envoyé à partir d'hôtes internes à votre réseau. Cela devrait se traduire par un comportement "échec rapide" qui a plus de sens que les retards de connexion non déterministes. Il a été démontré que cela fonctionne dans des environnements de test limités .
• Demandez à votre FAI ou à votre fournisseur de transport en commun de premier saut de configurer un relais 6to4 fonctionnel. Si cela est fait correctement, il en résultera la meilleure expérience pour les utilisateurs finaux. Tout utilisateur final possédant une adresse IPv4 publiquement routable pourrait participer à Internet IPv6.

Enregistrement DNS dynamique

Dans un environnement Active Directory typique, chaque ordinateur est autorisé à enregistrer ses propres adresses auprès du serveur DNS. Lorsqu'un hôte est multi-hôte, il enregistre toutes ses adresses, même à partir d'un tunnel 6to4.

La plupart des services Internet n'utilisent pas de DNS dynamique, donc ce problème est généralement limité aux sites d'entreprise où les clients et les serveurs sont tous "internes" au même réseau.

• Vous pouvez choisir de désactiver les mises à jour DNS dynamiques. Ensuite, si vous ne placez aucun enregistrement de ressource AAAA dans le fichier de zone, il ne sera jamais servi. Cependant, le DNS dynamique est souvent souhaitable pour les serveurs DNS internes. (Si vous faites cela, assurez-vous également de supprimer tous les enregistrements AAAA qui pourraient déjà être présents.)
• Configurez le serveur DNS pour ne pas fournir de réponses pour les enregistrements de ressources AAAA. Mais ne faites pas cela, car cela vous posera vraiment des problèmes lorsque vous souhaitez commencer à implémenter IPv6. (Quelqu'un connaît-il un pare-feu DNS gratuit / open source?)

L'application client n'échoue pas correctement

Le client RDP de Microsoft est un exemple d'une application client qui ne traite pas correctement les problèmes de routage IPv6. La plupart des navigateurs Web sont mieux à même de gérer les cas de périphérie IPv6 comme celui-ci, ils n'ont donc pas tendance à montrer ce comportement.

• Essayez d'utiliser un autre client. Vous aurez peut-être de la chance.

Je me rends compte que ce n'est pas très utile pour cette situation, mais pour les implémenteurs confrontés à un dilemme similaire, il existe une technique de mise en œuvre connue sous le nom de "Happy Eyeballs" (RFC 6555) qui spécifie une technique pour se connecter simultanément à ipv4 et ipv6 et choisir celle qui se connecte en premier.

Voici ma solution. Par défaut, Windows donne aux routes IPv6 une priorité plus élevée que les routes IPv4. Si vous modifiez la stratégie de préfixe IPv6, vous pouvez modifier ce comportement pour lui faire utiliser IPv4 de préférence à IPv6.

Pour m'assurer que tous les systèmes de mon réseau sont configurés de la même manière, j'ai placé les commandes suivantes dans un script .bat exécuté lors de l'installation du logiciel après la construction ou la remise à neuf d'une machine.

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

Pour expliquer ce que cela fait:

Les 3 premières lignes désactivent les interfaces de tunneling intégrées, car elles sont redondantes pour la plupart des réseaux. Vous voudrez peut-être ne pas utiliser ces 3 lignes si vous ne donnez pas vos propres adresses IPv6 à vos machines, dans mon cas, j'ai un serveur DHCPv6 et une infrastructure associée attribuant IPv6 pour la connectivité tunnel

Le deuxième bloc de commandes supprime toutes les stratégies de préfixe de routage IPv6 existantes.

Le troisième bloc recrée ensuite les stratégies de préfixe IPv6, mais utilise un ensemble de priorités différent. De même, le préfixe correspondant à IPv4 a la préférence sur IPv6, et la machine voudra alors utiliser IPv4 à moins que l'application ne spécifie l'utilisation d'IPv6.

Cette solution conserve la capacité de double pile fonctionnelle, mais la préférence d'utiliser IPv4 signifie que les sites avec IPv6 incomplet, peu fiable ou peu performant éviteront de l'utiliser à moins d'un programme du système.

À mon avis, faire en sorte que les systèmes d'exploitation utilisent IPv6 de préférence à IPv4 entrave en fait l'adoption. Pendant la période de transition, il y aura des moments où un hôte pense qu'il a une connectivité IPv6 mais n'a pas réellement de connexion entièrement fonctionnelle, ce qui entraîne des dysfonctionnements logiciels et des retards importants. Beaucoup de gens que je connais ont désactivé IPv6 entièrement sur leur routeur comme solution de contournement pour les FAI déployant IPv6 de manière cassée au départ avant d'établir une connectivité complète, et ces personnes oublieront simplement de le réactiver en les laissant sans IPv6 jusqu'à ce qu'elles reconfigurent à nouveau leur routeur.