Aller au contenu principal

RFC 3596 - Extensions DNS pour supporter la version 6 du protocole IP

  • Statut: Internet Standard
  • Publié: October 2003
  • Stream: IETF
  • Remplace: RFC1886, RFC3152
  • Errata: Pas d'errata

Résumé​

Ce document définit les modifications qui doivent être apportées au système de noms de domaine (Domain Name System, DNS) pour prendre en charge les hôtes exécutant IP version 6 (IPv6). Les modifications incluent un type d'enregistrement de ressource pour stocker une adresse IPv6, un domaine pour prendre en charge les recherches basées sur une adresse IPv6, et des définitions mises à jour des types de requêtes existants qui renvoient des adresses Internet dans le cadre du traitement de section additionnelle. Les extensions sont conçues pour être compatibles avec les applications existantes et, en particulier, avec les implémentations DNS elles-mêmes.

Table des matières​

1. Introduction​

La prise en charge actuelle du stockage des adresses Internet dans le système de noms de domaine (DNS) [1,2] ne peut pas être facilement étendue pour prendre en charge les adresses IPv6 [3] car les applications supposent que les requêtes d'adresse renvoient uniquement des adresses IPv4 de 32 bits.

Pour prendre en charge le stockage des adresses IPv6 dans le DNS, ce document définit les extensions suivantes:

  • Un type d'enregistrement de ressource est défini pour mapper un nom de domaine à une adresse IPv6.

  • Un domaine est défini pour prendre en charge les recherches basées sur l'adresse.

  • Les requêtes existantes qui effectuent un traitement de section additionnelle pour localiser les adresses IPv4 sont redéfinies pour effectuer un traitement de section additionnelle à la fois sur les adresses IPv4 et IPv6.

Les modifications sont conçues pour être compatibles avec les logiciels existants. La prise en charge existante des adresses IPv4 est conservée. Les problèmes de transition liés à la coexistence des adresses IPv4 et IPv6 dans le DNS sont discutés dans [4].

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

Ce document combine RFC 1886 [5] et les modifications apportées à RFC 1886 par RFC 3152 [6], rendant les deux obsolètes. Les modifications consistent principalement à remplacer le domaine IP6.INT par IP6.ARPA tel que défini dans RFC 3152.

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

Un type d'enregistrement est défini pour stocker l'adresse IPv6 d'un hôte. Un hôte qui possède plus d'une adresse IPv6 doit avoir plus d'un tel enregistrement.

2.1. Type d'enregistrement AAAA​

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

La valeur du type attribuée par l'IANA est 28 (décimal).

2.2. Format de données AAAA​

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

2.3. Requête AAAA​

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

Une requête de type AAAA ne déclenche pas de traitement de section additionnelle.

2.4. Format textuel des enregistrements AAAA​

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

2.5. Domaine IP6.ARPA​

Un domaine spécial est défini pour rechercher un enregistrement à partir d'une adresse IPv6. L'objectif de ce domaine est de fournir un moyen de mapper une adresse IPv6 à un nom d'hôte, bien qu'il puisse également être utilisé à d'autres fins. Le domaine est enraciné à IP6.ARPA.

Une adresse IPv6 est représentée comme un nom dans le domaine IP6.ARPA par une séquence de nibbles séparés par des points avec le suffixe ".IP6.ARPA". La séquence de nibbles est encodée dans l'ordre inverse, c'est-à-dire que le nibble de poids faible est encodé en premier, suivi du nibble de poids faible suivant et ainsi de suite. Chaque nibble est représenté par un chiffre hexadécimal. Par exemple, le nom de domaine de recherche inversée 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 des types de requêtes existants​

Tous les types de requêtes existants qui effectuent un traitement de section additionnelle de type A, c'est-à-dire les types de requêtes serveur de noms (NS), localisation des services (SRV) et échange de courrier (MX), doivent être redéfinis pour effectuer à la fois un 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 pertinentes et toutes les adresses IPv6 pertinentes disponibles localement à la section additionnelle d'une réponse lors du traitement de l'une des requêtes ci-dessus.

4. Considérations de sécurité​

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

Ainsi, cette spécification n'est pas considérée comme causant de nouveaux problèmes de sécurité, ni comme résolvant des problèmes existants.

5. Considérations IANA​

Il n'y a aucune attribution IANA à effectuer.

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

L'IETF ne prend aucune position concernant la validité ou la portée de toute propriété intellectuelle ou d'autres droits qui pourraient être revendiqués comme se rapportant à la mise en œuvre ou à l'utilisation de la technologie décrite dans ce document ou la mesure dans laquelle toute licence en vertu de tels droits pourrait ou non être disponible; elle ne représente pas non plus qu'elle a fait aucun effort pour identifier de tels droits. Les informations sur les procédures de l'IETF en ce qui concerne les droits dans les documents des normes et liés aux normes peuvent être trouvées dans BCP-11. Des copies des revendications de droits mises à disposition pour publication et toutes assurances de licences à mettre à disposition, ou le résultat d'une tentative faite pour obtenir une licence générale ou une permission pour l'utilisation de tels droits de propriété par les implémenteurs ou les utilisateurs de cette spécification peuvent être obtenues auprès du Secrétariat de l'IETF.

L'IETF invite toute partie intéressée à porter à son attention tout droit d'auteur, brevet ou demande de brevet, ou autres droits de propriété qui peuvent couvrir la technologie qui peut être nécessaire pour pratiquer cette norme. Veuillez 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 lors des sessions de tests d'interopérabilité RFC 1886.

Merci beaucoup à Alain Durand et Olafur Gudmundsson pour leur soutien.

Annexe A: Changements par rapport à RFC 1886​

Les modifications suivantes ont été apportées par rapport à RFC 1886 "DNS Extensions to support IP version 6":

  • Remplacement du domaine "IP6.INT" par "IP6.ARPA".
  • Mention des types de requêtes SRV dans la section 3 "MODIFICATIONS TO EXISTING QUERY TYPES"
  • Ajout des considérations de sécurité.
  • Mise à jour des références:
    • De RFC 1884 à RFC 3513 (IP Version 6 Addressing Architecture).
    • De "work in progress" à RFC 2893 (Transition Mechanisms for IPv6 Hosts and Routers).
    • Ajout de références à 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 de droits d'auteur
  • Ajout de la section considérations IANA
  • Ajout de la déclaration de propriété intellectuelle

Références normatives​

[1] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987.

[2] Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, RFC 1035, November 1987.

[3] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.

Références informatives​

[4] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC 2893, August 2000.

[5] Thomson, S. and C. Huitema, "DNS Extensions to support IP version 6", RFC 1886, December 1995.

[6] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152, August 2001.

[7] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999

[8] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May 2000.

Adresses des auteurs​

Susan Thomson
Cisco Systems
499 Thornall Street, 8th floor
Edison, NJ 08837
Téléphone: +1 732-635-3086
Email: [email protected]

Christian Huitema
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052-6399
Email: [email protected]

Vladimir Ksinant
6WIND S.A.
Immeuble Central Gare - Bat.C
1, place Charles de Gaulle
78180, Montigny-Le-Bretonneux - France
Téléphone: +33 1 39 30 92 36
Email: [email protected]

Mohsen Souissi
AFNIC
Immeuble International
2, rue Stephenson,
78181, Saint-Quentin en Yvelines Cedex - France
Téléphone: +33 1 39 30 83 40
Email: [email protected]

Dernière mise à jour le