Zum Hauptinhalt springen

RFC 3596 - DNS-Erweiterungen zur Unterstützung von IP Version 6

  • Status: Internet Standard
  • Veröffentlicht: October 2003
  • Stream: IETF
  • Ersetzt: RFC1886, RFC3152
  • Errata: Keine Errata

Zusammenfassung​

Dieses Dokument definiert die Änderungen, die am Domain Name System (DNS) [1,2] vorgenommen werden müssen, um Hosts zu unterstützen, die IP Version 6 (IPv6) ausführen. Die Änderungen umfassen einen Ressourceneintragstyp zum Speichern einer IPv6-Adresse, eine Domain zur Unterstützung von Lookups basierend auf einer IPv6-Adresse und aktualisierte Definitionen bestehender Abfragetypen, die Internet-Adressen als Teil der zusätzlichen Abschnittsverarbeitung zurückgeben. Die Erweiterungen sind so konzipiert, dass sie mit bestehenden Anwendungen und insbesondere mit DNS-Implementierungen selbst kompatibel sind.

Inhaltsverzeichnis​

1. Einführung​

Die aktuelle Unterstützung für die Speicherung von Internet-Adressen im Domain Name System (DNS) [1,2] kann nicht einfach erweitert werden, um IPv6-Adressen [3] zu unterstützen, da Anwendungen davon ausgehen, dass Adressabfragen nur 32-Bit-IPv4-Adressen zurückgeben.

Um die Speicherung von IPv6-Adressen im DNS zu unterstützen, definiert dieses Dokument die folgenden Erweiterungen:

  • Ein Ressourceneintragstyp ist definiert, um einen Domain-Namen auf eine IPv6-Adresse abzubilden.

  • Eine Domain ist definiert, um Lookups basierend auf der Adresse zu unterstützen.

  • Bestehende Abfragen, die eine zusätzliche Abschnittsverarbeitung durchführen, um IPv4-Adressen zu lokalisieren, werden neu definiert, um eine zusätzliche Abschnittsverarbeitung sowohl für IPv4- als auch für IPv6-Adressen durchzuführen.

Die Änderungen sind so konzipiert, dass sie mit bestehender Software kompatibel sind. Die bestehende Unterstützung für IPv4-Adressen bleibt erhalten. Übergangsprobleme im Zusammenhang mit der Koexistenz von IPv4- und IPv6-Adressen im DNS werden in [4] diskutiert.

Die IP-Protokollversion, die zum Abfragen von Ressourceneinträgen verwendet wird, ist unabhängig von der Protokollversion der Ressourceneinträge; z. B. kann IPv4-Transport zum Abfragen von IPv6-Einträgen verwendet werden und umgekehrt.

Dieses Dokument kombiniert RFC 1886 [5] und Änderungen an RFC 1886, die durch RFC 3152 [6] vorgenommen wurden, und macht beide obsolet. Die Änderungen bestehen hauptsächlich darin, die IP6.INT-Domain durch IP6.ARPA zu ersetzen, wie in RFC 3152 definiert.

2. Neue Ressourceneintragsdefinition und Domain​

Ein Eintragstyp ist definiert, um die IPv6-Adresse eines Hosts zu speichern. Ein Host, der mehr als eine IPv6-Adresse hat, muss mehr als einen solchen Eintrag haben.

2.1. AAAA-Eintragstyp​

Der AAAA-Ressourceneintragstyp ist ein eintragsspezifischer Eintrag für die Internet-Klasse, der eine einzelne IPv6-Adresse speichert.

Der von der IANA zugewiesene Wert des Typs ist 28 (dezimal).

2.2. AAAA-Datenformat​

Eine 128-Bit-IPv6-Adresse wird im Datenbereich eines AAAA-Ressourceneintrags in Netzwerk-Byte-Reihenfolge (Byte höherer Ordnung zuerst) kodiert.

2.3. AAAA-Abfrage​

Eine AAAA-Abfrage für einen angegebenen Domain-Namen in der Internet-Klasse gibt alle zugehörigen AAAA-Ressourceneinträge im Antwortbereich einer Antwort zurück.

Eine Abfrage vom Typ AAAA löst keine zusätzliche Abschnittsverarbeitung aus.

2.4. Textformat von AAAA-Einträgen​

Die Textdarstellung des Datenbereichs des AAAA-Ressourceneintrags, der in einer Master-Datenbankdatei verwendet wird, ist die Textdarstellung einer IPv6-Adresse, wie in [3] definiert.

2.5. IP6.ARPA-Domain​

Eine spezielle Domain ist definiert, um einen Eintrag anhand einer IPv6-Adresse nachzuschlagen. Die Absicht dieser Domain ist es, eine Möglichkeit zur Zuordnung einer IPv6-Adresse zu einem Host-Namen bereitzustellen, obwohl sie auch für andere Zwecke verwendet werden kann. Die Domain ist bei IP6.ARPA verwurzelt.

Eine IPv6-Adresse wird als Name in der IP6.ARPA-Domain durch eine Folge von Nibbles dargestellt, die durch Punkte getrennt sind, mit dem Suffix ".IP6.ARPA". Die Folge von Nibbles wird in umgekehrter Reihenfolge kodiert, d. h., das Nibble niedrigerer Ordnung wird zuerst kodiert, gefolgt vom nächsten Nibble niedrigerer Ordnung usw. Jedes Nibble wird durch eine hexadezimale Ziffer dargestellt. Zum Beispiel wäre der Reverse-Lookup-Domain-Name, der der Adresse entspricht

4321:0:1:2:3:4:567:89ab
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. Änderungen an bestehenden Abfragetypen​

Alle bestehenden Abfragetypen, die eine zusätzliche Abschnittsverarbeitung vom Typ A durchführen, d. h. Name-Server (NS), Standort von Diensten (SRV) und Mail-Exchange (MX)-Abfragetypen, müssen neu definiert werden, um sowohl eine zusätzliche Abschnittsverarbeitung vom Typ A als auch vom Typ AAAA durchzuführen. Diese Definitionen bedeuten, dass ein Name-Server alle relevanten IPv4-Adressen und alle relevanten IPv6-Adressen, die lokal verfügbar sind, zum zusätzlichen Abschnitt einer Antwort hinzufügen muss, wenn eine der oben genannten Abfragen verarbeitet wird.

4. Sicherheitsüberlegungen​

Alle Informationen, die vom DNS erhalten werden, müssen als unsicher betrachtet werden, es sei denn, es werden Techniken verwendet, die in [7] oder [8] spezifiziert sind. Die Definitionen des AAAA-Eintragstyps und der IP6.ARPA-Domain ändern das Modell für die Verwendung dieser Techniken nicht.

Daher wird nicht angenommen, dass diese Spezifikation neue Sicherheitsprobleme verursacht oder bestehende löst.

5. IANA-Überlegungen​

Es sind keine IANA-Zuweisungen durchzuführen.

6. Geistiges Eigentum​

Die IETF nimmt keine Position zur Gültigkeit oder zum Umfang geistigen Eigentums oder anderer Rechte ein, die möglicherweise als relevant für die Implementierung oder Verwendung der in diesem Dokument beschriebenen Technologie beansprucht werden, oder zum Ausmaß, in dem eine Lizenz unter solchen Rechten verfügbar sein könnte oder nicht; sie stellt auch nicht dar, dass sie sich bemüht hat, solche Rechte zu identifizieren. Informationen zu den Verfahren der IETF in Bezug auf Rechte in Standards-Track- und standardsbezogenen Dokumentationen finden sich in BCP-11. Kopien von Rechteansprüchen, die zur Veröffentlichung bereitgestellt wurden, und alle Zusicherungen von Lizenzen, die bereitgestellt werden sollen, oder das Ergebnis eines Versuchs, eine allgemeine Lizenz oder Erlaubnis für die Verwendung solcher proprietären Rechte durch Implementierer oder Benutzer dieser Spezifikation zu erhalten, können vom IETF-Sekretariat erhalten werden.

Die IETF lädt alle interessierten Parteien ein, ihre Aufmerksamkeit auf Urheberrechte, Patente oder Patentanmeldungen oder andere proprietäre Rechte zu lenken, die Technologien abdecken könnten, die zur Ausübung dieses Standards erforderlich sein könnten. Bitte richten Sie die Informationen an den IETF Executive Director.

Danksagungen​

Vladimir Ksinant und Mohsen Souissi möchten Sebastien Barbin (IRISA), Luc Beloeil (France Telecom R&D), Jean-Mickael Guerin (6WIND), Vincent Levigneron (AFNIC), Alain Ritoux (6WIND), Frederic Roudaut (IRISA) und der G6-Gruppe für ihre Hilfe während der RFC 1886 Interop-Testsitzungen danken.

Vielen Dank an Alain Durand und Olafur Gudmundsson für ihre Unterstützung.

Anhang A: Änderungen gegenüber RFC 1886​

Die folgenden Änderungen wurden gegenüber RFC 1886 "DNS Extensions to support IP version 6" vorgenommen:

  • Ersetzung der "IP6.INT"-Domain durch "IP6.ARPA".
  • Erwähnung von SRV-Abfragetypen in Abschnitt 3 "MODIFICATIONS TO EXISTING QUERY TYPES"
  • Hinzufügung von Sicherheitsüberlegungen.
  • Aktualisierte Referenzen:
    • Von RFC 1884 zu RFC 3513 (IP Version 6 Addressing Architecture).
    • Von "work in progress" zu RFC 2893 (Transition Mechanisms for IPv6 Hosts and Routers).
    • Hinzufügung von Referenzen zu RFC 1886, RFC 3152, RFC 2535 und RFC 2845.
  • Aktualisierte Dokumentzusammenfassung
  • Hinzufügung des Inhaltsverzeichnisses
  • Hinzufügung der vollständigen Urheberrechtserklärung
  • Hinzufügung des Abschnitts IANA-Überlegungen
  • Hinzufügung der Erklärung zum geistigen Eigentum

Normative Referenzen​

[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.

Informative Referenzen​

[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.

Adressen der Autoren​

Susan Thomson
Cisco Systems
499 Thornall Street, 8th floor
Edison, NJ 08837
Telefon: +1 732-635-3086
E-Mail: [email protected]

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

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

Mohsen Souissi
AFNIC
Immeuble International
2, rue Stephenson,
78181, Saint-Quentin en Yvelines Cedex - France
Telefon: +33 1 39 30 83 40
E-Mail: [email protected]

Letztes Update am