Groupe de travail Réseau

S. Thomson, Cisco

Request for Comments : 3596

C. Huitema, Microsoft

RFC rendues obsolètes : 3152, 1886

V. Ksinant, 6WIND

Catégorie : En cours de normalisation

M. Souissi, AFNIC

Traduction Claude Brière de L'Isle

octobre 2003

 

 

Extensions au DNS pour la prise en charge de IP version 6

 

Statut du présent mémoire

Le présent document spécifie un protocole de normalisation Internet pour la communauté Internet, et appelle à discussion et suggestions en vue de son amélioration. Prière de se reporter à l’édition en cours des "Internet Official Protocol Standards" (normes officielles du protocole Internet) (STD 1) pour connaître l’état de la normalisation et le statut du présent protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

 

Déclaration de copyright

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

 

Résumé

Le présent document définit les changements qu'il est nécessaire de faire au système des noms de domaines (DNS, Domain Name System) pour la prise en charge des hôtes qui fonctionnent avec IP version 6 (IPv6). Les changements incluent un type d'enregistrement de ressource pour mémoriser une adresse IPv6, un domaine pour prendre en charge les recherches fondées sur une adresse IPv6, et des mises à jour des définitions des types d'interrogation existants qui retournent des adresses Internet au titre du traitement de la section additionnelle. Les extensions sont conçues comme compatibles avec les applications existantes, et en particulier, les mises en œuvre du DNS elles-mêmes.

 

Table des Matières

1.   Introduction

2.   Nouvelle définition et domaine d'enregistrement de ressource

2.1   Type d'enregistrement AAAA

2.2   Format de données AAAA

2.3   Interrogation AAAA

2.4   Format textuel des enregistrements AAAA

2.5   Domaine IP6.ARPA

3.   Modifications aux types d'interrogation existants

4.   Considérations pour la sécurité

5.   Considérations relatives à l'IANA

6.   Déclaration de droits de propriété intellectuelle

Remerciements

Appendice A   Changements par rapport à la RFC 1886

Références normatives

Références informatives

Adresse des auteurs

Déclaration complète de copyright

 

1.   Introduction

 

La prise en charge actuelle de la mémorisation des adresses Internet dans le système des noms de domaine (DNS, Domain Name System) [1,2] ne peut pas être étendue facilement à la prise en charge des adresses IPv6 [3] car les applications supposent que les interrogations d'adresse retournent seulement des adresses IPv4 de 32 bits.

 

Pour la prise en charge des adresses IPv6 dans le DNS, le présent document définit les extensions suivantes :

o   un type d'enregistrement de ressource est défini comme transposant un nom de domaine en adresse IPv6,

o   un domaine est défini comme prenant en charge des recherches fondées sur l'adresse,

o   les interrogations existantes qui effectuent un traitement de la section additionnelle pour localiser les adresses IPv4 sont redéfinies pour effectuer un traitement de la section additionnelle sur les deux adresses IPv4 et IPv6.

 

Les changements sont conçus pour être compatibles avec les logiciels existants. La prise en charge actuelle des adresses IPv4 est conservée. Les questions de transition qui se rapportent à la coexistence des adresses IPv4 et IPv6 dans le DNS sont exposées dans [4].

 

La version de protocole IP utilisée pour interroger les enregistrements de ressource est indépendante de la version de protocole des enregistrements de ressource ; par exemple, le transport IPv4 peut être utilisé pour interroger des enregistrements IPv6 et vice versa.

 

Le présent document combine la RFC 1886 [5] et les changements apportés à la RFC 1886 faits par la RFC 3152 [6], et les rend toutes deux obsolètes. Les changements consistent principalement à remplacer le domaine IP6.INT par le domaine IP6.ARPA tel que défini dans la RFC 3152.

 

2.   Nouvelle définition et domaine d'enregistrement de ressource

 

Un type d'enregistrement est défini pour mémoriser l'adresse IPv6 d'un hôte. Un hôte qui a plus d'une adresse IPv6 doit avoir plus d'un enregistrement de ce type.

 

2.1   Type d'enregistrement AAAA

Le type d'enregistrement de ressource AAAA est un enregistrement spécifique de la classe Internet qui mémorise une seule adresse IPv6.

 

La valeur allouée par l'IANA à ce type est 28 (décimal).

 

2.2   Format de données AAAA

Une adresse IPv6 de 128 bits est codée dans la portion de données d'un enregistrement de ressource AAAA dans l'ordre des octets du réseau (octet de plus fort poids en premier).

 

2.3   Interrogation AAAA

Une interrogation AAAA pour un nom de domaine spécifié dans la classe Internet retourne tous les enregistrements de ressource AAAA associés dans la section réponse d'une réponse.

 

Une interrogation AAAA de type ne déclanche pas de traitement de la section additionnelle.

 

2.4   Format textuel des enregistrements AAAA

La représentation textuelle de la portion de données de l'enregistrement de ressource AAAA utilisée dans un fichier maître de base de données est la représentation textuelle d'une adresse IPv6 telle que définie dans [3].

 

2.5   Domaine IP6.ARPA

Un domaine particulier est défini pour chercher un enregistrement étant donnée une adresse IPv6. L'objet de ce domaine est de fournir le moyen de transposer une adresse IPv6 en nom d'hôte, bien qu'il puisse aussi être utilisé à d'autres fins. La racine du domaine est IP6.ARPA.

 

Une adresse IPv6 est représentée comme un nom dans le domaine IP6.ARPA par une séquence de quartets séparés par des points avec le suffixe ".IP6.ARPA". La séquence de quartets est codée en ordre inverse, c'est-à-dire que le quartet de moindre poids est codé le premier, suivi par le quartet de moindre poids suivant, et ainsi de suite. Chaque quartet est représenté par un chiffre hexadécimal. Par exemple, la rechercher inverse de nom de domaine correspondant à l'adresse 4321:0:1:2:3:4:567:89ab serait b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.0.0.0.1.2.3.4.IP6.ARPA.

 

3.   Modifications aux types d'interrogation existants

 

Tous les types d'interrogation existants qui effectuent le traitement de section additionnelle de type A, c'est-à-dire les types d'interrogation de serveur de nom (NS), localisation de services (SRV) et échange de messagerie (MX), doivent être redéfinis pour effectuer à la fois le traitement de section additionnelle de type A et de type AAAA. Ces définitions signifient qu'un serveur de noms doit ajouter toutes les adresses IPv4 et toutes les adresses IPv6 pertinentes disponibles localement à la section additionnelle d'une réponse lors du traitement de l'une quelconque des interrogations ci-dessus.

 

4.   Considérations pour la sécurité

 

Toute information obtenue du DNS doit être considérée comme non sûre si les techniques spécifiées dans [7] ou [8] ne sont pas utilisées. Les définitions du type d'enregistrement AAAA et du domaine IP6.ARPA ne changent pas le modèle d'utilisation de ces techniques.

 

Donc, la présente spécification n'est pas considérée comme causant de nouveaux problèmes de sécurité, ni comme une solution à aucun problème existant.

 

5.   Considérations relatives à l'IANA

 

L'IANA n'a aucune allocation à effectuer.

 

6.   Déclaration de droits de propriété intellectuelle

 

L’IETF ne prend pas position sur la validité et la portée de tout droit de propriété intellectuelle ou autres droits qui pourrait être revendiqués au titre de la mise en œuvre ou l’utilisation de la technologie décrite dans le présent document ou sur la mesure dans laquelle toute licence sur de tels droits pourrait être ou n’être pas disponible ; pas plus qu’elle ne prétend avoir accompli aucun effort pour identifier de tels droits. Les informations sur les procédures de l’IETF au sujet des droits dans les documents en cours de normalisation et se rapportant aux normes figurent dans le BCP 11.

 

Des copies des dépôts d’IPR faites au secrétariat de l’IETF et toutes assurances de disponibilité de licences, ou le résultat de tentatives faites pour obtenir une licence ou permission générale d’utilisation de tels droits de propriété par ceux qui mettent en œuvre ou utilisent la présente spécification peuvent être obtenues sur répertoire en ligne des IPR de l’IETF à http://www.ietf.org/ipr.

 

L’IETF invite toute partie intéressée à porter son attention sur tous copyrights, brevet ou applications de brevets, ou autres droits de propriété qui pourraient recouvrir la technologie qui pourrait être nécessaire pour mettre en œuvre la présente norme. Prière d’adresser les informations au directeur exécutif de l’IETF.

 

Remerciements

 

Vladimir Ksinant et Mohsen Souissi tiennent à remercier Sebastien Barbin (IRISA), Luc Beloeil (France Telecom R&D), Jean-Mickael Guerin (6WIND), Vincent Levigneron (AFNIC), Alain Ritoux (6WIND), Frederic Roudaut (IRISA) et le groupe G6 pour leur aide durant les sessions d'essai Interop de la RFC 1886.

 

Un grand merci à Alain Durand et Olafur Gudmundsson pour leur soutien.

 

Appendice A   Changements par rapport à la RFC 1886

 

Les changements suivants ont été faits par rapport à la RFC 1886 "Extensions au DNS pour la prise en charge de IPv6":

 

-   Remplacement du domaine "IP6.INT" par "IP6.ARPA".

-   Mention des types d'interrogation SRV dans la section 3 "Modifications aux types d'interrogation existants"

-   Ajout des considérations pour la sécurité.

-   Mise à jour de références :

   * de la RFC 1884 à la RFC 3513 (Architecture d'adressage de IP version 6).

   * de "Travail en cours" à la RFC 2893 (Mécanismes de transition pour les hôtes et routeurs IPv6).

   * ajout de la référence aux RFC 1886, RFC 3152, RFC 2535 et RFC 2845.

-   Mise à jour du résumé du document.

-   Ajout de la table des matières.

-   Ajout de la déclaration complète des droits de propriété intellectuelle.

-   Ajour de la section Considérations relatives à l'IANA.

-   Ajout de la déclaration sur la propriété intellectuelle.

 

Références normatives

 

[1]   P. Mockapetris, "Noms de domaines - Concepts et facilités", RFC 1034, STD 13, novembre 1987.

[2]   P. Mockapetris, "Noms de domaines – Mise en œuvre et spécification", RFC 1035, STD 13, novembre 1987.

[3]   R. Hinden et S. Deering, "Architecture d'adressage du protocole Internet version 6 (IPv6)", RFC 3513, avril 2003.

 

Références informatives

 

[4]   R. Gilligan, E. Nordmark, "Mécanismes de transition pour les hôtes et routeurs IPv6", RFC2893, août 2000. (Obsolète, voirRFC4213)

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

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

[7]   D. Eastlake, 3 rd, "Extensions de sécurité du système des noms de domaines", RFC2535, mars 1999. (Obsolète, voirRFC4033, RFC4034, RFC4035) (P.S.)

[8]   P. Vixie et autres, "Authentification de transaction de clé secrète pour DNS (TSIG)", RFC2845, mai 20000 (MàJ parRFC3645) (P.S.)

 

Adresse des auteurs

 

Susan Thomson

Christian Huitema

Cisco Systems

Microsoft Corporation

499 Thornall Street, 8th floor

One Microsoft Way

Edison, NJ 08837

Redmond, WA 98052-6399

téléphone : +1 732-635-3086

USA

mél : sethomso@cisco.com

mél : huitema@microsoft.com

 

Vladimir Ksinant

Mohsen Souissi

6WIND S.A.

AFNIC

Immeuble Central Gare - Bat.C

Immeuble International

1, place Charles de Gaulle

2, rue Stephenson,

78180, Montigny-Le-Bretonneux - France

78181, Saint-Quentin en Yvelines Cedex - France

téléphone : +33 1 39 30 92 36

téléphone: +33 1 39 30 83 40

mél : vladimir.ksinant@6wind.com

mél : Mohsen.Souissi@nic.fr

 

Déclaration complète de copyright

 

Copyright (C) The Internet Society (2003). 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 copyright 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 copyright 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 copyright 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 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.