Actuellement, seules les adresses IPv4 sont présentes dans la zone racine et ce à cause d'une limitation historique de la taille des requêtes DNS (en UDP). Il est probable que pour l'utilisateur moyen ça ne change encore pas grand chose, mais c'est encore une bonne nouvelle pour le déploiement de l'IPv6.
Aller plus loin
- Annonce sur arstechnica (4 clics)
- News sur Slashdot (4 clics)
- Rapport sur les problèmes potentiels pouvant apparaître (258 clics)
- Livre en ligne sur IPv6 (9 clics)
# déploiement représentatif
Posté par BAud (site web personnel) . Évalué à 2.
Cela permet de tester de bout en bout (accès IPv6, requêtes DNS pour trouver l'IPv6 des serveurs, accès aux serveurs en IPv6) que tout fonctionne en IPv6.
Reste à trouver de plus en plus de serveurs en IPv6 et aussi s'assurer que ça fonctionne déjà bien chez soi, comme commencé dans ce journal : https://linuxfr.org//~carlo/25836.html
Certaines distributions ont commencé à recenser les applications impactées http://wiki.mandriva.com/en/Docs/SysAdmin/Networking/IPV6 [en] n'hésitez pas à participer à ce travail d'intégration dans votre distribution pour que cela fonctionne hors de la boîte pour le plus grand monde ;-)
Déjà pour l'accès Free IPv6, j'avais commencé la prise de notes sur http://wiki.eagle-usb.org/wakka.php?wiki=FreeIPv6to4rd vous pouvez completer, cela étant un wiki.
# l'annonce de l'icann
Posté par toof . Évalué à 1.
voir : Discussion of Supporting IPv6 in the Root Server System
# Faire un serveur compatible ipv6 ?
Posté par ploum (site web personnel, Mastodon) . Évalué à 2.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Faire un serveur compatible ipv6 ?
Posté par demik . Évalué à 1.
Par exemple pour lighttpd, il suffit d'ajouter:
server.use-ipv6 = "enable"
Pour postfix, c'est plutôt :
inet_protocols = ipv4, ipv6
Pour cyrus, me semble pas avoir fait quelque chose de spécial, je crois que c'est une option à la compilation.
Grosso modo, un petit tour dans le manuel de chaque service, et c'est réglé !
# .
Posté par M . Évalué à 2.
Et ils ont resolu le pb comment ?
[^] # Re: .
Posté par BAud (site web personnel) . Évalué à 3.
z'ont implémenté des logiciels nouveaux gérant au-delà de la spécification d'origine du protocole, seuls de vieux DNS avec de vieux logiciels risquent de ne pas passer à IPv6 (une bonne manière de les réformer lors de la migration), ils seront identifiés dans cette phase préliminaire, même si une alternative a été proposée pour que ça marchotte quand même.
[^] # Re: .
Posté par briaeros007 . Évalué à 2.
Enfin le 512 octets c'est parce que la norme udp dis qu'il faut pouvoir envoyer un datagramme d'au moins 512 octets.
Et le coup du truncated+tcp, c'est le fonctionnement normal du dns quand on doit envoyer des requêtes plus grosses (transfert de zone par exemple).
L'alternative elle existait déjà dans le standard dns depuis fort longtemps ;)
[^] # EDNS0, pas TCP
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 2.
L'alternative avec TCP, oui, depuis le début, mais elle est coûteuse pour le serveur.
Ce qui est plus nouveau, c'est EDNS0 (http://www.bortzmeyer.org/2671.html), qui permet de faire sauter la limite des 512 octets, et qui n'a été massivement déployé que depuis quelques années.
[^] # arstechnica ne s'est pas bien exprimé
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 1.
Ce n'est pas vraiment exact (sauf à utiliser le mot troncation dans un sens très général, alors qu'il a une signification bien précise pour le DNS).
Comme la taille de la section Réponse ou Autorité ne va pas changer (il n'y a toujours que treize serveurs), il n'y aura pas de troncation. Il y aura simplement sélection des enregistrements dans la section Addition, et cette section n'est pas obligatoire.
Donc, le risque n'était pas la troncation, mais le fait que la sélection des colles (les adresses IP des serveurs) pourrait ne laisser que des adresses IPv4 ou bien que des adresses IPv4, ce qui serait ennuyeux pour le client mono-protocole.
Avec EDNS0, le problème disparait.
Le rapport complet du SSAC pour ceux qui ont le courage : http://www.icann.org/committees/security/sac018.pdf
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.