MediaWiki API result

{
    "warnings": {
        "query": {
            "*": "Formatting of continuation data will be changing soon. To continue using the current formatting, use the 'rawcontinue' parameter. To begin using the new format, pass an empty string for 'continue' in the initial query."
        }
    },
    "query-continue": {
        "allpages": {
            "gapcontinue": "Routage"
        }
    },
    "query": {
        "pages": {
            "1370": {
                "pageid": 1370,
                "ns": 0,
                "title": "Recommandations op\u00e9rationnelles pour l'int\u00e9gration d'IPv6",
                "revisions": [
                    {
                        "contentformat": "text/x-wiki",
                        "contentmodel": "wikitext",
                        "*": "{{suivi|Les solutions exp\u00e9rimentales A6 et bitstring labels|Les solutions exp\u00e9rimentales A6 et bitstring labels|D\u00e9couverte de la liste de serveurs DNS r\u00e9cursifs|D\u00e9couverte de la liste de serveurs DNS r\u00e9cursifs}}\n\nComme cela a \u00e9t\u00e9 d\u00e9crit dans l'introduction de ce chapitre, le DNS a la particularit\u00e9 d'\u00eatre \u00e0 la fois une application TCP/IP et une infrastructure critique (en tant que base de donn\u00e9es) pour le fonctionnement des autres applications TCP/IP classiques (web, mail, ftp, ...). Avec l'int\u00e9gration progressive d'IPv6, de nouveaux probl\u00e8mes op\u00e9rationnels li\u00e9s au DNS se posent ou risquent de se poser et il convient donc de les \u00e9viter ou de trouver tout au moins les solutions ad\u00e9quates afin d'y rem\u00e9dier. \u00c0 cet effet, RFC 3901 et RFC 4472 identifient les principaux probl\u00e8mes et formulent une s\u00e9rie de recommandations pratiques pour y faire face. Les sections qui suivent tentent de r\u00e9sumer ces recommandations.\n\n==Les deux aspects du DNS==\n\nEn tant que base de donn\u00e9es, le DNS supporte les enregistrements <tt>A</tt> et <tt>AAAA</tt> et ce, ind\u00e9pendamment de la version d'IP qui est utilis\u00e9e pour transporter les requ\u00eates et r\u00e9ponses DNS relatives \u00e0 ces enregistrements. Par ailleurs, en tant qu'application TCP/IP, un serveur DNS supporte le transport IPv4 ou le transport IPv6 ou les deux \u00e0 la fois. Dans tous les cas, il doit retourner ce qu'il a dans sa base de donn\u00e9es pour r\u00e9pondre \u00e0 une requ\u00eate donn\u00e9e, ind\u00e9pendamment de la version d'IP sur laquelle il a re\u00e7u cette requ\u00eate. En effet, un serveur DNS ne peut a priori pas savoir si le client initiateur de la requ\u00eate a transmis celle-ci en IPv4 ou en IPv6 \u00e0 son serveur r\u00e9cursif (cache) : des serveurs interm\u00e9diaires appel\u00e9s cache forwarders et n'utilisant pas la m\u00eame version d'IP que le client, peuvent intervenir dans la cha\u00eene des serveurs interrog\u00e9s durant le processus de r\u00e9solution DNS. En outre, en admettant m\u00eame que le serveur DNS puisse conna\u00eetre la version d'IP utilis\u00e9e par le client qui a initi\u00e9 la requ\u00eate, il faut souligner que le serveur n'a pas \u00e0 faire d'hypoth\u00e8se sur l'usage que fera le client de la r\u00e9ponse DNS retourn\u00e9e.\n\n==Continuit\u00e9 du service DNS==\n\nAvant l'arriv\u00e9e d'IPv6, le processus de r\u00e9solution DNS ne faisait intervenir que la version 4 d'IP et le service \u00e9tait donc garanti pour tous les clients DNS. Avec IPv6, on risque de se trouver dans des configurations o\u00f9 l'espace de nommage devient fragment\u00e9 en des partitions accessibles uniquement au-dessus d'IPv4 et d'autres accessibles uniquement au-dessus d'IPv6. Voici par exemple deux sc\u00e9narios illustrant ce probl\u00e8me de fragmentation ainsi que la solution recommand\u00e9e dans chaque sc\u00e9nario :\n\n* premier sc\u00e9nario : un client ne supportant qu'IPv4 souhaite r\u00e9soudre une requ\u00eate relative \u00e0 une zone DNS h\u00e9berg\u00e9e sur des serveurs ne supportant qu'IPv6. Dans ces cas-l\u00e0, le processus de r\u00e9solution se termine par un \u00e9chec d\u00fb \u00e0 l'impossibilit\u00e9 d'acc\u00e9der aux serveurs qui font autorit\u00e9 sur cette zone. Pour y rem\u00e9dier, il faudra faire en sorte que toute zone DNS soit servie par au moins un serveur supportant IPv4.\n* second sc\u00e9nario : un client DNS dans un r\u00e9seau ne supportant qu'IPv6 souhaite r\u00e9soudre une requ\u00eate donn\u00e9e. Si le serveur r\u00e9cursif interrog\u00e9 ne supporte pas non plus IPv4, le processus de r\u00e9solution risque d'\u00e9chouer plus tard avant de joindre les serveurs faisant autorit\u00e9 sur l'information recherch\u00e9e. En effet, lors de son parcours de la cha\u00eene de d\u00e9l\u00e9gations dans l'arborescence DNS, le serveur r\u00e9cursif risque de tomber sur un serveur ne supportant pas IPv6. Afin d'y rem\u00e9dier, il est recommand\u00e9 dans ce cas, de configurer le serveur r\u00e9cursif en le faisant pointer vers un serveur <tt>forwarder</tt> en double pile IPv4/IPv6.\n\nPar exemple, pour une distribution BIND, il suffit d'ajouter l'option :\n\n forwarders {<liste des adresses de serveurs forwarders> ;}\n\nsous la rubrique \u00ab <tt>options</tt> \u00bb dans le fichier <tt>named.conf</tt>.\n\n==Taille limit\u00e9e des messages DNS en UDP==\n\nLes impl\u00e9mentations DNS s'appuient essentiellement sur deux standards de l'IETF (RFC 1034 et  RFC 1035). De nombreux autres RFC compl\u00e9mentaires ont \u00e9t\u00e9 publi\u00e9s plus tard pour clarifier certains aspects pratiques ou pour apporter de nouvelles extensions r\u00e9pondant \u00e0 de nouveaux besoins (enregistrements <tt>AAAA</tt>, <tt>SRV</tt>, extensions DNSSEC, ...). En tant qu'application TCP/IP, le DNS doit supporter les deux modes de transport UDP et TCP (RFC 1035), le port associ\u00e9 \u00e9tant le m\u00eame : 53.\n\nLe mode UDP est g\u00e9n\u00e9ralement utilis\u00e9 pour les requ\u00eates/r\u00e9ponses DNS et le mode TCP est g\u00e9n\u00e9ralement utilis\u00e9 pour les transferts de zones. Cependant, compte tenu de la taille limit\u00e9e \u00e0 512 octets des messages DNS en mode UDP, certaines requ\u00eates peuvent provoquer le passage en mode TCP si la taille de la r\u00e9ponse d\u00e9passe cette limite.\n\nDans ce cas, le client re\u00e7oit dans un premier temps un message dont la section r\u00e9ponse (''answer section'') est vide et dont le bit <tt>TC</tt> (''Truncated'') est positionn\u00e9, ce qui signifie implicitement que le client est invit\u00e9 \u00e0 r\u00e9interroger le serveur en mode TCP. Au passage, ce sc\u00e9nario constitue un argument justifiant le fait que le port 53 en TCP ne doit pas \u00eatre ouvert exclusivement pour les transferts de zones.\n\nNotons qu'un basculement trop fr\u00e9quent en mode TCP risque de consommer davantage de ressources et d\u00e9grader par cons\u00e9quent les performances du serveur DNS. Certains nouveaux types d'enregistrements (tels que le type <tt>AAAA</tt>) risquent d'augmenter la taille des r\u00e9ponses DNS de mani\u00e8re significative, ce qui risque de faire basculer plus souvent les requ\u00eates/r\u00e9ponses DNS en mode TCP. Aujourd'hui, ce d\u00e9passement n'arrive que rarement car la plupart des r\u00e9ponses DNS ne d\u00e9passe gu\u00e8re les 400 octets. En effet, les sections <tt>answer</tt>, <tt>authority</tt> et <tt>additional</tt>, qui constituent la majeure partie de la r\u00e9ponse DNS, ne contiennent qu'un nombre limit\u00e9 d'enregistrements si cette r\u00e9ponse ne concerne pas directement une zone de haut niveau telle que <tt>.com</tt>, <tt>.net</tt>, <tt>.fr</tt>, <tt>.de</tt>...\n\nFace \u00e0 ce risque, l'extension EDNS.0 (RFC 2671) a \u00e9t\u00e9 propos\u00e9e et est d\u00e9j\u00e0 d\u00e9ploy\u00e9e dans les versions r\u00e9centes des logiciels DNS. Cette extension, permet \u00e0 un client DNS d'informer le serveur interrog\u00e9 qu'il est capable de supporter des r\u00e9ponses de taille sup\u00e9rieure \u00e0 la limite des 512 octets (4096 octets par exemple). Ainsi, en pr\u00e9sence d'IPv6, le support d'EDNS.0 devient fortement recommand\u00e9. \u00c0 noter que le support d'EDNS.0 devient \u00e9galement indispensable en pr\u00e9sence des extensions DNSSEC.\n\nLe faible taux de p\u00e9n\u00e9tration d'EDNS.0 dans les logiciels DNS (surtout les clients) est rest\u00e9 pendant plusieurs ann\u00e9es l'un des principaux motifs du refus de l'IANA/ICANN de publier de nouvelles adresses (IPv4 ou IPv6) pour des serveurs de la racine. \u00c0 partir du 4  f\u00e9vrier 2008, l'[http://www.iana.org IANA] publie dans la zone racine l'adresse IPv6 (enregistrement AAAA) des serveurs racine supportant le transport IPv6 et la nouvelle version du fichier de de d\u00e9marrage (typiquement <tt>named.root</tt> pour BIND 9) contient \u00e9galement ces adresses.\n\nNotons enfin que des informations sur les adresses IPv4 et IPv6 des serveurs de la racine ainsi que sur la r\u00e9partition g\u00e9ographique de ces serveurs sont publi\u00e9es sur le site web : http://www.root-servers.org/ .\n\n== Glue IPv6 ==\n\nLa zone racine publie \u00e9galement les adresses des diff\u00e9rents serveurs DNS pour chacun des domaines de haut niveau (TLD : ''Top Level Domain''). Ces adresses, appel\u00e9es \u00ab glues \u00bb sont n\u00e9cessaires pour que le processus de r\u00e9solution DNS puisse d\u00e9marrer. En effet, rappelons que les serveurs DNS de la racine ne sont pas cens\u00e9s r\u00e9soudre eux-m\u00eames les requ\u00eates. Leur r\u00f4le est de faire le premier aiguillage (''referal'') vers des serveurs de haut niveau (TLD). L'information d'aiguillage comprend la liste des serveurs du TLD sous l'arborescence duquel se trouve la ressource ainsi que les adresses (glues) associ\u00e9es \u00e0 ces serveurs. Sans ces glues, le processus de r\u00e9solution risque de tourner en rond.\n\n\nEn attendant que les serveurs de la racine puissent recevoir des requ\u00eates DNS et y r\u00e9pondre en IPv6, les TLD avaient \u0153uvr\u00e9 pendant des ann\u00e9es \u00e0 l'introduction dans la zone racine des \u00ab glues \u00bb IPv6 qui lui sont associ\u00e9es. L'IANA/ICANN ont enfin \u00e9t\u00e9  convaincus que la publication des glues IPv6 des serveurs DNS de TLD supportant IPv6 peut se faire sans risque pour la stabilit\u00e9 du DNS. L'ICANN/IANA a d\u00e9marr\u00e9 en juillet 2004 la publication des glues IPv6 des TLD dans la zone racine. Les trois TLD <tt>.fr</tt>, <tt>.jp</tt> et <tt>.kr</tt> ont vu les premiers leur glue IPv6 publi\u00e9e.\n\n== Publication des enregistrements AAAA dans le DNS ==\n\nOn choisit g\u00e9n\u00e9ralement de publier dans le DNS le (ou les) enregistrement(s) <tt>AAAA</tt> associ\u00e9(s) \u00e0 un \u00e9quipement donn\u00e9 lorsque l'on souhaite que les applications initiant des communications \u00e0 destination de cet \u00e9quipement d\u00e9couvrent le support du transport IPv6. Par exemple, un navigateur supportant IPv6, d\u00e9couvre via le DNS qu'il est possible de se connecter en IPv6 au site <tt><nowiki>http://www.afnic.fr/</nowiki></tt>. Il peut alors choisir de privil\u00e9gier la connexion http au serveur en IPv4 ou en IPv6. Or avec l'int\u00e9gration progressive d'IPv6, certaines applications s'ex\u00e9cutant sur l'\u00e9quipement dont l'adresse IPv6 est publi\u00e9e dans le DNS peuvent ne pas supporter IPv6. Ainsi, l'on risque de se trouver par exemple dans la situation suivante :\n\n* l'\u00e9quipement <tt>foo.example.com</tt> h\u00e9berge plusieurs services : web, ftp, mail, dns ;\n* les serveurs web et dns s'ex\u00e9cutant sur <tt>foo.example.com</tt> supportent IPv6 mais pas les serveurs ftp et mail ;\n* une adresse IPv6 est publi\u00e9e dans le DNS pour <tt>foo.example.com</tt> ;\n* un client ftp supportant IPv6 tente de se connecter au serveur s'ex\u00e9cutant sur <tt>foo.example.com</tt>. Le client s\u00e9lectionne alors l'adresse IPv6 de <tt>foo.example.com</tt> comme adresse destination ;\n* la tentative de communication en IPv6 \u00e9choue. Selon les impl\u00e9mentations, certains clients r\u00e9essaient (ou non) d'autres adresses IPv6 s'il y en a ou passent (ou non) en IPv4 en dernier recours.\n\nAfin de pallier ce probl\u00e8me, il est recommand\u00e9 d'associer des noms DNS aux services et non aux \u00e9quipements. Ainsi, pour notre exemple pr\u00e9c\u00e9dent, il serait judicieux de publier dans le DNS d'une part, les noms <tt>www.example.com</tt> et <tt>ns.example.com</tt> avec adresses IPv6 (et IPv4 \u00e9ventuellement) et d'autre part, les noms <tt>ftp.example.com</tt> et <tt>mail.example.com</tt> avec des adresses IPv4 uniquement. L'enregistrement <tt>AAAA</tt> pour <tt>foo.example.com</tt> n'est alors publi\u00e9 que lorsque l'on a la certitude que toutes les applications s'ex\u00e9cutant sur cet \u00e9quipement supportent IPv6.\n\nPar ailleurs, le DNS \u00e9tant une ressource publique, il est fortement d\u00e9conseill\u00e9 (sauf si l'administrateur DNS sait tr\u00e8s bien ce qu'il/elle fait !) d'y publier des adresses IPv6 non joignables de l'ext\u00e9rieur, soit \u00e0 cause d'une port\u00e9e faible (adresses [[Lien-local|lien-local]] par exemple), soit parce que toutes les communications provenant de l'ext\u00e9rieur du r\u00e9seau et allant vers ces adresses sont filtr\u00e9es. Notons que cette r\u00e8gle est d\u00e9j\u00e0 appliqu\u00e9e pour les adresses IPv4 priv\u00e9es (RFC 1918) et que certains logiciels DNS r\u00e9cents supportent aujourd'hui les vues DNS (on parle de ''two-face DNS'', de ''split-view DNS'' ou encore de ''split DNS''). Avec ce syst\u00e8me de vues, la r\u00e9ponse \u00e0 une requ\u00eate DNS d\u00e9pend de l'origine du client. Par exemple un client appartenant au r\u00e9seau interne pourra voir les adresses priv\u00e9es des \u00e9quipements. Les clients externes, quant \u00e0 eux, ne verront que les adresses globales et joignables de l'ext\u00e9rieur.\n{{suivi|Les solutions exp\u00e9rimentales A6 et bitstring labels|Les solutions exp\u00e9rimentales A6 et bitstring labels|D\u00e9couverte de la liste de serveurs DNS r\u00e9cursifs|D\u00e9couverte de la liste de serveurs DNS r\u00e9cursifs}}"
                    }
                ]
            },
            "1361": {
                "pageid": 1361,
                "ns": 0,
                "title": "Renum\u00e9rotation des routeurs",
                "revisions": [
                    {
                        "contentformat": "text/x-wiki",
                        "contentmodel": "wikitext",
                        "*": "{{suivi|Configuration avec \u00e9tat :DHCPv6|Configuration avec \u00e9tat :DHCPv6|M\u00e9canisme de d\u00e9couverte du PMTU|M\u00e9canisme de d\u00e9couverte du PMTU}} \nLe m\u00e9canisme d'allocation d'adresses sans \u00e9tat permet aux \u00e9quipements terminaux de s'auto-configurer automatiquement. Un noeud cr\u00e9e son (ou ses) adresse(s) en concatenant un identifiant d'interface, g\u00e9n\u00e9ralement construit \u00e0 partir de l'adresse MAC, et des pr\u00e9fixes annonc\u00e9s par les routeurs. Il n'existe pas de protocole automatique de configuration de routeur, les adresses des diff\u00e9rents interfaces doivent \u00eatre configur\u00e9s statiquement, par exemple en donnant la liste des pr\u00e9fixes correspondant \u00e0 un interface puis en cr\u00e9ant des adresses en concat\u00e9nant un identifiant \u00e0 chacun des pr\u00e9fixes.\n\nLe protocole de renum\u00e9rotation automatique constitue une \u00e9tape suppl\u00e9mentaire pour automatiser la gestion d'un r\u00e9seau : il permet de mani\u00e8re globale et automatis\u00e9e de modifier la configuration des routeurs et les annonces de pr\u00e9fixes. Un administrateur r\u00e9seau peut ajouter, retirer ou modifier des pr\u00e9fixes dans les routeurs, ce qui aura pour effet de renum\u00e9roter toutes les machines d'un r\u00e9seau (aussi bien un simple lien que tout un site)8.\n\nLe protocole, d\u00e9fini dans le RFC 2894, concerne uniquement les routeurs. Il utilise des messages ICMPv6 de type 138 (cf. [[Mod\u00e8le:Tableau ICMPv6#138|tableau Valeurs des champs type et code d'ICMPv6]], See Valeurs des champs type et code d'ICMPv6) pour v\u00e9hiculer les instructions de renum\u00e9rotation.\n\nLes messages sont diffus\u00e9s en unicast ou en multicast (en utilisant l'adresse \u00abtous les routeurs du lien\u00bb ou \u00abtous les routeurs du site\u00bb). Ils contiennent un pr\u00e9fixe qui permet de s\u00e9lectionner le ou les interfaces des routeurs sur lesquelles s'applique la r\u00e9mun\u00e9ration. Trois commandes sont possibles sur ces interfaces :\n\n* ajouter un nouveau pr\u00e9fixe,\n* remplacer le pr\u00e9fixe \u00abs\u00e9lectionn\u00e9\u00bb par un autre pr\u00e9fixe,\n* remplacer tous les pr\u00e9fixes existant par un nouveau ensemble de pr\u00e9fixes.\n\nChaque fois qu'un pr\u00e9fixe est modifi\u00e9 sur une interface, l'adresse globale correspondante est elle aussi modifi\u00e9e.\n\nVu les probl\u00e8mes de s\u00e9curit\u00e9 li\u00e9 \u00e0 au protocole de renum\u00e9ration automatique, l'utilisation de l'extension d'authentification est n\u00e9cessaire, et un num\u00e9ro de s\u00e9quence toujours croissant permet d'interdire les rejeux.\n\nCe protocole est encore exp\u00e9rimental et n'est pas largement d\u00e9ploy\u00e9 dans les routeurs.\n\n{{suivi|Configuration avec \u00e9tat :DHCPv6|Configuration avec \u00e9tat :DHCPv6|M\u00e9canisme de d\u00e9couverte du PMTU|M\u00e9canisme de d\u00e9couverte du PMTU}}"
                    }
                ]
            }
        }
    }
}