7. Deployment Scenarios and Examples (Deployment-Szenarien und Beispiele)

In diesem Abschnitt veranschaulichen wir, wie sich DNS64 in verschiedenen Szenarien verhält, die voraussichtlich häufig vorkommen werden. Insbesondere werden wir die folgenden in [RFC6144] definierten Szenarien betrachten: das Szenario "ein IPv6-Netzwerk zum IPv4-Internet" (sowohl mit DNS64 im DNS-Server-Modus als auch im Stub-Resolver-Modus) und das Setup "IPv6-Internet zu einem IPv4-Netzwerk" (nur mit DNS64 im DNS-Server-Modus).

In allen folgenden Beispielen gibt es einen IPv6/IPv4-Translator, der die IPv6-Domain mit der IPv4-Domain verbindet. Außerdem gibt es einen Nameserver, der ein Dual-Stack-Knoten ist, sodass er mit IPv6-Hosts über IPv6 und mit IPv4-Knoten über IPv4 kommunizieren kann. Darüber hinaus nehmen wir in den Beispielen an, dass die DNS64-Funktion erfährt, welches IPv6-Präfix sie verwenden muss, um den IPv4-Adressraum durch manuelle Konfiguration abzubilden.

7.1. Example of "an IPv6 Network to the IPv4 Internet" Setup with DNS64 in DNS Server Mode (Beispiel für ein "IPv6-Netzwerk zum IPv4-Internet"-Setup mit DNS64 im DNS-Server-Modus)

In diesem Beispiel betrachten wir einen IPv6-Knoten, der sich in einem reinen IPv6-Standort befindet und eine Kommunikation zu einem IPv4-Knoten im IPv4-Internet initiiert.

Das Szenario für diesen Fall ist in der folgenden Abbildung dargestellt:

+---------------------+         +---------------+
|IPv6 network         |         |    IPv4       |
|           |  +-------------+  |  Internet     |
|           |--| Name server |--|               |
|           |  | with DNS64  |  |  +----+       |
|  +----+   |  +-------------+  |  | H2 |       |
|  | H1 |---|         |         |  +----+       |
|  +----+   |   +------------+  |  192.0.2.1    |
|           |---| IPv6/IPv4  |--|               |
|           |   | Translator |  |               |
|           |   +------------+  |               |
|           |         |         |               |
+---------------------+         +---------------+

Die Abbildung zeigt einen IPv6-Knoten H1 und einen IPv4-Knoten H2 mit der IPv4-Adresse 192.0.2.1 und FQDN h2.example.com.

Der IPv6/IPv4-Translator hat die IPv4-Adresse 203.0.113.1, die seiner IPv4-Schnittstelle zugewiesen ist, und verwendet das Well-Known Prefix 64:ff9b::/96, um IPv6-Darstellungen von IPv4-Adressen zu erstellen. Dasselbe Präfix ist in der DNS64-Funktion im lokalen Nameserver konfiguriert.

Für dieses Beispiel nehmen wir die typische DNS-Situation an, in der IPv6-Hosts nur Stub-Resolver haben und mit der IP-Adresse eines Nameservers konfiguriert sind, den sie immer abfragen müssen und der rekursive Lookups durchführt (im Folgenden als "der rekursive Nameserver" bezeichnet).

Die Schritte, durch die H1 die Kommunikation mit H2 herstellt, sind:

H1 führt eine DNS-Suche nach h2.example.com durch. H1 tut dies, indem es eine DNS-Abfrage nach einem AAAA-Eintrag für H2 an den rekursiven Nameserver sendet. Der rekursive Nameserver implementiert DNS64-Funktionalität.
Der rekursive Nameserver löst die Abfrage auf und entdeckt, dass es keine AAAA-Einträge für H2 gibt.
Der rekursive Nameserver führt eine A-Eintrag-Abfrage für H2 durch und erhält ein RRSet zurück, das einen einzelnen A-Eintrag mit der IPv4-Adresse 192.0.2.1 enthält. Der Nameserver synthetisiert dann einen AAAA-Eintrag. Die IPv6-Adresse im AAAA-Eintrag enthält das dem IPv6/IPv4-Translator zugewiesene Präfix in den oberen 96 Bits und die empfangene IPv4-Adresse in den unteren 32 Bits; d.h., die resultierende IPv6-Adresse ist 64:ff9b::192.0.2.1.
H1 empfängt den synthetischen AAAA-Eintrag und sendet ein Paket an H2. Das Paket wird an die Zieladresse 64:ff9b::192.0.2.1 gesendet.
Das Paket wird an die IPv6-Schnittstelle des IPv6/IPv4-Translators geleitet, und die nachfolgende Kommunikation fließt durch die IPv6/IPv4-Translator-Mechanismen.

7.2. Example of "an IPv6 Network to the IPv4 Internet" Setup with DNS64 in Stub-Resolver Mode (Beispiel für ein "IPv6-Netzwerk zum IPv4-Internet"-Setup mit DNS64 im Stub-Resolver-Modus)

Dieser Fall ist in der folgenden Abbildung dargestellt:

+---------------------+         +---------------+
|IPv6 network         |         |    IPv4       |
|           |     +--------+    |  Internet     |
|           |-----| Name   |----|               |
| +-----+   |     | server |    |  +----+       |
| | H1  |   |     +--------+    |  | H2 |       |
| |with |---|         |         |  +----+       |
| |DNS64|   |   +------------+  |  192.0.2.1    |
| +----+    |---| IPv6/IPv4  |--|               |
|           |   | Translator |  |               |
|           |   +------------+  |               |
|           |         |         |               |
+---------------------+         +---------------+

Die Abbildung zeigt einen IPv6-Knoten H1, der die DNS64-Funktion implementiert, und einen IPv4-Knoten H2 mit der IPv4-Adresse 192.0.2.1 und FQDN h2.example.com.

Die Schritte, durch die H1 die Kommunikation mit H2 herstellt, sind:

H1 führt eine DNS-Suche nach h2.example.com durch. H1 tut dies, indem es eine DNS-Abfrage nach einem AAAA-Eintrag für H2 an den rekursiven Nameserver sendet.
Der rekursive DNS-Server löst die Abfrage auf und gibt die Antwort an H1 zurück. Da es keine AAAA-Einträge im globalen DNS für H2 gibt, ist die Antwort leer.
Der Stub-Resolver bei H1 fragt dann nach einem A-Eintrag für H2 und erhält einen A-Eintrag zurück, der die IPv4-Adresse 192.0.2.1 enthält. Die DNS64-Funktion innerhalb von H1 synthetisiert dann einen AAAA-Eintrag. Die IPv6-Adresse im AAAA-Eintrag enthält das dem IPv6/IPv4-Translator zugewiesene Präfix in den oberen 96 Bits, dann die empfangene IPv4-Adresse in den unteren 32 Bits; die resultierende IPv6-Adresse ist 64:ff9b::192.0.2.1.
H1 sendet ein Paket an H2. Das Paket wird an die Zieladresse 64:ff9b::192.0.2.1 gesendet.
Das Paket wird an die IPv6-Schnittstelle des IPv6/IPv4-Translators geleitet, und die nachfolgende Kommunikation fließt unter Verwendung der IPv6/IPv4-Translator-Mechanismen.

7.3. Example of "the IPv6 Internet to an IPv4 Network" Setup with DNS64 in DNS Server Mode (Beispiel für ein "IPv6-Internet zu einem IPv4-Netzwerk"-Setup mit DNS64 im DNS-Server-Modus)

In diesem Beispiel betrachten wir einen IPv6-Knoten im IPv6-Internet, der eine Kommunikation zu einem IPv4-Knoten im IPv4-Standort initiiert.

In einigen Fällen kann dieses Szenario ohne Verwendung einer Form von DNS64-Funktion behandelt werden. Dies liegt daran, dass es möglich ist, jedem der IPv4-Knoten eine feste IPv6-Adresse zuzuweisen. Eine solche IPv6-Adresse würde unter Verwendung des in [RFC6052] definierten Adresstransformationsalgorithmus konstruiert, der als Eingabe das Pref64::/96 und die IPv4-Adresse des IPv4-Knotens nimmt. Beachten Sie, dass die IPv4-Adresse eine öffentliche oder eine private Adresse sein kann; Letztere stellt keine zusätzliche Schwierigkeit dar, da ein NSP als Pref64::/96 verwendet werden muss (in diesem Szenario wird die Verwendung des Well-Known Prefix nicht unterstützt, wie in [RFC6052] diskutiert). Sobald diese IPv6-Adressen zugewiesen wurden, um die IPv4-Knoten im IPv6-Internet darzustellen, können echte AAAA RRs, die diese Adressen enthalten, im DNS unter der Domain des Standorts veröffentlicht werden. Dies ist der empfohlene Ansatz zur Behandlung dieses Szenarios, da er nicht die Synthese von AAAA-Einträgen zum Zeitpunkt der Abfrage beinhaltet.

Es gibt jedoch einige dynamischere Szenarien, in denen die Synthese von AAAA RRs in diesem Setup erforderlich sein kann. Insbesondere wenn DNS Update [RFC2136] im IPv4-Standort verwendet wird, um die A RRs für die IPv4-Knoten zu aktualisieren, gibt es zwei Optionen. Eine Option besteht darin, den DNS-Server zu modifizieren, der die dynamischen DNS-Updates empfängt. Das wäre normalerweise der autoritative Server für die Zone. Der autoritative Zone würde also normale AAAA RRs haben, die synthetisiert werden, wenn dynamische Updates auftreten. Die andere Option besteht darin, alle autoritativen Server zu modifizieren, um synthetische AAAA-Einträge für eine Zone zu generieren, möglicherweise basierend auf zusätzlichen Einschränkungen, beim Empfang einer DNS-Abfrage für den AAAA RR. Die erste Option -- bei der der AAAA synthetisiert wird, wenn die DNS-Update-Nachricht empfangen wird, und die Daten in der relevanten Zone veröffentlicht werden -- wird gegenüber der zweiten Option (d.h. der Synthese beim Empfang der AAAA-DNS-Abfrage) empfohlen. Dies liegt daran, dass es normalerweise einfacher ist, Probleme mit Fehlkonfigurationen zu lösen, wenn die DNS-Antworten nicht dynamisch generiert werden. Es kann jedoch der Fall sein, dass der primäre Server (der alle Updates empfängt) aus welchem Grund auch immer nicht aktualisiert werden kann, aber ein sekundärer aktualisiert werden kann, um die (vergleichsweise geringe Menge an) AAAA-Abfragen zu behandeln. In einem solchen Fall ist es möglich, DNS64 wie im Folgenden beschrieben zu verwenden. Das DNS64-Verhalten, das wir in diesem Abschnitt beschreiben, deckt den Fall der Synthese des AAAA RR ab, wenn die DNS-Abfrage eintrifft.

Das Szenario für diesen Fall ist in der folgenden Abbildung dargestellt:

+-----------+          +----------------------+
|           |          |   IPv4 site          |
|   IPv6    |    +------------+  |   +----+   |
| Internet  |----| IPv6/IPv4  |--|---| H2 |   |
|           |    | Translator |  |   +----+   |
|           |    +------------+  |            |
|           |          |         | 192.0.2.1  |
|           |    +------------+  |            |
|           |----| Name server|--|            |
|           |    | with DNS64 |  |            |
+-----------+    +------------+  |            |
  |                    |         |            |
+----+                 |                      |
| H1 |                 +----------------------+
+----+

Die Abbildung zeigt einen IPv6-Knoten H1 und einen IPv4-Knoten H2 mit der IPv4-Adresse 192.0.2.1 und FQDN h2.example.com.

Der IPv6/IPv4-Translator verwendet ein NSP 2001:db8::/96, um IPv6-Darstellungen von IPv4-Adressen zu erstellen. Dasselbe Präfix ist in der DNS64-Funktion im lokalen Nameserver konfiguriert. Der Nameserver, der die DNS64-Funktion implementiert, ist der autoritative Nameserver für die lokale Domain.

Die Schritte, durch die H1 die Kommunikation mit H2 herstellt, sind:

H1 führt eine DNS-Suche nach h2.example.com durch. H1 tut dies, indem es eine DNS-Abfrage nach einem AAAA-Eintrag für H2 sendet. Die Abfrage wird schließlich an den Server im IPv4-Standort weitergeleitet.
Der lokale DNS-Server löst die Abfrage (lokal) auf und entdeckt, dass es keine AAAA-Einträge für H2 gibt.
Der Nameserver überprüft, ob h2.example.com und sein A RR zu denen gehören, die die lokale Policy als erlaubt definiert, um einen AAAA RR zu generieren. Wenn das der Fall ist, synthetisiert der Nameserver einen AAAA-Eintrag aus dem A RR und dem Präfix 2001:db8::/96. Die IPv6-Adresse im AAAA-Eintrag ist 2001:db8::192.0.2.1.
H1 empfängt den synthetischen AAAA-Eintrag und sendet ein Paket an H2. Das Paket wird an die Zieladresse 2001:db8::192.0.2.1 gesendet.
Das Paket wird durch das IPv6-Internet an die IPv6-Schnittstelle des IPv6/IPv4-Translators geleitet, und die Kommunikation fließt unter Verwendung der IPv6/IPv4-Translator-Mechanismen.