Représentation des adresses du protocole Internet version 6 (IPv6) dans le système des noms de domaine (DNS)

Statut de ce mémoire

Le présent mémoire apporte des informations pour la communauté de l’Internet. Il ne spécifie aucune forme de norme de l’Internet. La diffusion du présent mémoire n’est soumise à aucune restriction.

Notice de copyright

Copyright (C) The Internet Society (2002). Tous droits réservés.

Résumé

Le présent document précise et met à jour le statut de normalisation des RFC qui définissent la transposition directe et inverse des adresses IPv6 dans le DNS. Le présent document fait passer les spécifications d’étiquette A6 et Bit au statut de expérimental.

1. Introduction

L’IETF a commencé le processus de normalisation de deux différents formats d’adresse pour les adresses IPv6 : AAAA [RFC1886] et A6 [RFC2874] et tous deux sont des normes proposées. Cela a conduit à une certaine confusion et à des conflits sur celui à déployer. Il est important pour le déploiement que toute confusion dans ce domaine soit dissipée, car il y a dans la communauté le sentiment qu’il peut y avoir un choix à faire, ce qui conduit à des retards dans le déploiement de IPv6. L’objectif du présent document est de clarifier la situation.

Le présent document expose aussi les questions qui se rapportent à l’usage des étiquettes binaires [RFC 2673] pour prendre en charge la transposition inverse des adresses IPv6.

Le présent document se fonde sur une discussion technique extensive sur diverses listes de diffusion des groupes de travail pertinents et une réunion conjointe de DNSEXT et de NGTRANS à la 51^ème réunion de l’IETF en août 2001. Le présent document tente de saisir le sens des discussions et de les refléter pour représenter le consensus de la communauté.

Les principaux arguments et les questions sont traités dans un document distinct [RFC3364] qui reflète la compréhension actuelle de ces questions. Le présent document résumé le résultat de ces discussions.

La question de la racine de la transposition de l’adresse IPv6 inverse sort du domaine d’application du présent document et est traitée dans un document différent [RFC3152].

1.1 Action de normalisation entreprise

Le présent document change le statut des RFC 2673 et 2874 de Norme proposée en Expérimental.

2. Adresses IPv6 : RR AAAA ou RR A6

Le consensus des groupes de travail tel que perçu par les présidents des groupes de travail DNSEXT et NGTRANS est que :

a) les enregistrements AAAA sont préférables pour le moment pour la production du déploiement de IPv6, et

b) les enregistrements A6 ont des propriétés intéressantes qui doivent être mieux comprises avant leur déploiement :

c) on ne sait pas si les avantages de A6 valent leurs coûts et les risques.

2.1 Raison

Plusieurs problèmes potentiels des RR A6 découlent directement de caractéristiques qui les rendent différents des RR AAAA : la capacité à construire des adresses via le chaînage.

Résoudre une chaîne de RR A6 implique de résoudre une série d’interrogations qui sont presque indépendantes. Chacune de ces sous questions prend un délai non égal à zéro, sauf si la réponse se trouve déjà dans l’antémémoire locale du résolveur. Toutes choses égales par ailleurs, on s’attend à ce que le temps qu’il faut pour résoudre une chaîne de N liens de RR A6 soit en gros proportionnel à N. Ce fait nous suggère que les usagers étant déjà impatients avec le long délai nécessaire pour résoudre les RR A dans l’Internet IPv4, il est peu probable qu’ils soient plus patients avec des délais significativement plus longs dans l’Internet IPv6, mais terminer prématurément les interrogations est à la fois un gâchis des ressources et une autre source de frustration des utilisateurs. Donc, on est forcé de conclure qu’un usage sans discrimination de longues chaînes A6 va vraisemblablement conduire à une augmentation de la frustration des utilisateurs.

La probabilité d’un échec durant le processus de résolution d’une chaîne A6 de N liens apparaît aussi en gros proportionnel à N, car chacune des interrogations impliquées dans la résolution d’une chaîne A6 a en gros la même probabilité d’échec qu’une seule interrogation AAAA.

Enfin, plusieurs des applications potentielles les plus intéressantes pour les RR A6 impliquent des situations où le champ de nom de préfixe dans le RR A6 pointe sur une cible qui est non seulement en dehors de la zone DNS contenant le RR A6, mais est administrée par une organisation entièrement différente. Alors que les pointeurs hors zone ne sont pas un problème en soi, l’expérience aussi bien avec les RR glus qu’avec les RR PTR dans l’arborescence IN-ADDR.ARPA suggère que des pointeurs sur d’autres organisations ne sont souvent pas entretenus correctement, peut-être parce que ils sont moins susceptibles d’automatisation que le seraient les pointeurs au sein d’une seule organisation.

2.2 Action de normalisation recommandée

Sur la base du consensus perçu, le présent document recommande que la RFC1886 reste en cours de normalisation et soit avancée, et de passer la RFC2874 à l’état Expérimental.

3. Étiquettes binaires dans l’arborescence DNS inversée

La RFC2673 définit un nouveau type d’étiquette DNS. Cela a été le premier nouveau type défini depuis la [RFC1035]. Depuis le développement de la RFC2673, on a appris que le déploiement d’un nouveau type est difficile car les serveurs du DNS qui ne prennent pas en charge les étiquettes binaires rejettent les interrogations qui contiennent des étiquettes binaires comme étant mal formées. La communauté a aussi indiqué que ce nouveau type d’étiquette n’est pas nécessaire pour la transposition inverse d’adresses.

3.1 Raison

La représentation en texte hexadécimal des adresses IPv6 apparaît capable d’exprimer tous les schémas de délégation qu’on s’attend à voir utiliser dans l’arborescence inverse du DNS.

3.2 Action de normalisation recommandée

Le statut de la normalisation de la RFC2673 est à changer de norme proposée en expérimentale. La normalisation future de ces documents sera faite par le groupe de travail DNSEXT ou ses successeurs.

4. DNAME dans l’arborescence IPv6 inversée

Les problèmes de DNAME dans l’arborescence de transposition inverse apparaissent étroitement liés au besoin d’utiliser le RR A6 fragmenté dans l’arbre principal : si il en est un nécessaire, il en est de même pour l’autre, et si l’un n’est pas nécessaire, l’autre ne l’est pas non plus. Donc, en passant la RFC2874 au statut de expérimentale, l’intention du présent document est que l’utilisation des RR DNAME soit déconseillée dans l’arborescence inverse.

5. Remerciements

Le présent document se fonde sur des apports de nombreux membres des divers groupes de travail de l’IETF impliqués dans ces questions. Des remerciements particuliers sont adressés aux personnes qui ont préparé les matériaux écrits pour la réunion du groupe de travail conjoint DNSEXT/NGTRANS à la 51^ème réunion de l’IETF à Londres, Rob Austein, Dan Bernstein, Matt Crawford, Jun-ichiro itojun Hagino, Christian Huitema. De nombreuses autres personnes ont fait des commentaires sur les listes de diffusion sur ces questions, incluant Andrew W. Barclay, Robert Elz, Johan Ihren, Edward Lewis, Bill Manning, Pekka Savola, Paul Vixie.

6. Considérations pour la sécurité

Comme le présent document spécifie une action, il n’y a pas de considérations directes pour la sécurité. Il y a un impact indirect sur la sécurité dans le choix, en ce que les relations entre A6 et la DNSSEC ne sont pas bien comprises au sein de la communauté, alors que le choix de AAAA conduit à un modèle pour l’utilisation de DNSSEC dans les réseaux IPv6 qui est parallèle à la pratique courante d’IPv4.

7. Considérations pour l’IANA

Aucune.

Références normatives

[RFC1035] P. Mockapetris, "Noms de domaines – Mise en œuvre et spécification", STD 13, novembre 1987. (MàJ par la RFC6604)

[RFC1886] S. Thomson, C. Huitema, "Extensions au DNS pour la prise en charge de IP version 6", décembre 1995. (Obsolète, voir RFC3596) (MàJ par RFC2874, RFC3152) (P.S.)

[RFC2673] M. Crawford, "Étiquettes binaires dans le système des noms de domaine", août 1999. (Remplacée par RFC6891)

[RFC2874] M. Crawford, C. Huitema, "Extensions de DNS pour la prise en charge de l'agrégation et du rénumérotage d'adresse IPv6", juillet 2000. (MàJ par RFC3152, RFC3226, RFC3363, RFC3364) (Expérimentale)

[RFC3152] R. Bush, "Délégation de IP6.ARPA", août 200. (Obsolète, voir RFC3596), (BCP0049)

Référence pour information

[RFC3364] R. Austein, "Compromis pour la prise en charge de IPv6 par le système des noms de domaine (DNS)", août 2002. (Information)

Adresse des éditeurs

Randy Bush

mél : randy@psg.com

Alain Durand

mél : alain.durand@sun.com

Bob Fink

mél : fink@es.net

Olafur Gudmundsson

mél : ogud@ogud.com

Tony Hain

mél : hain@tndh.net

Déclaration complète de droits de reproduction

Copyright (C) The Internet Society (2002). Tous droits réservés.

Le présent document et ses traductions peuvent être copiés et fournis aux tiers, et les travaux dérivés qui les commentent ou les expliquent ou aident à leur mise en œuvre peuvent être préparés, copiés, publiés et distribués, en tout ou partie, sans restriction d’aucune sorte, pourvu que la déclaration de droits de reproduction ci-dessus et le présent paragraphe soient inclus dans toutes telles copies et travaux dérivés. Cependant, le présent document lui-même ne peut être modifié d’aucune façon, en particulier en retirant la notice de droits de reproduction ou les références à la Internet Society ou aux autres organisations Internet, excepté autant qu’il est nécessaire pour le besoin du développement des normes Internet, auquel cas les procédures de droits de reproduction définies dans les procédures des normes Internet doivent être suivies, ou pour les besoins de la traduction dans d’autres langues que l’anglais.

Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Internet Society ou ses successeurs ou ayant droits.

Le présent document et les informations y contenues sont fournies sur une base "EN L’ÉTAT" et le contributeur, l’organisation qu’il ou elle représente ou qui le/la finance (s’il en est), la INTERNET SOCIETY et la INTERNET ENGINEERING TASK FORCE déclinent toutes garanties, exprimées ou implicites, y compris mais non limitées à toute garantie que l’utilisation des informations ci encloses ne violent aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.

Remerciement

Le financement de la fonction d’édition des RFC est actuellement fourni par l’Internet Society.