7. Unterstützung von reinen IPv6-Netzwerken mit NAT64 und DNS64 (Supporting IPv6-Only Networks with NAT64 and DNS64)

Während viele IPv6-Übergangsprotok

olle standardisiert und eingesetzt wurden, sind die meisten für Client-Geräte transparent. Die kombinierte Verwendung von NAT64 [RFC6146] und DNS64 [RFC6147] ist eine beliebte Lösung, die eingesetzt wird und Änderungen an Client-Geräten erfordert. Eine mögliche Methode zum Umgang mit diesen Netzwerken besteht darin, dass der Netzwerkstack des Client-Geräts 464XLAT [RFC6877] implementiert. 464XLAT hat den Vorteil, dass keine Änderungen an Benutzerraumsoftware erforderlich sind; es erfordert jedoch eine paketweise Übersetzung, wenn die Anwendung IPv4-Literale verwendet, und ermutigt die Client-Anwendungssoftware nicht, natives IPv6 zu unterstützen. Auf Plattformen, die 464XLAT nicht unterstützen, SHOULD die Happy Eyeballs-Engine den Empfehlungen in diesem Abschnitt folgen, um reine IPv6-Netzwerke mit NAT64 und DNS64 ordnungsgemäß zu unterstützen.

Die in diesem Abschnitt beschriebenen Funktionen SHOULD nur aktiviert werden, wenn der Host eines dieser Netzwerke erkennt. Eine einfache Heuristik, um dies zu erreichen, besteht darin, zu überprüfen, ob das Netzwerk routingfähige IPv6-Adressierung bietet, keine routingfähige IPv4-Adressierung bietet und eine DNS-Resolver-Adresse anbietet.

7.1. IPv4-Adressliterale (IPv4 Address Literals)

Wenn Client-Anwendungen oder Benutzer eine Verbindung zu IPv4-Adressliteralen herstellen möchten, muss die Happy Eyeballs-Engine NAT64-Adresssynthese für sie durchführen. Die Lösung ist ähnlich wie "Bump-in-the-Host" [RFC6535], wird jedoch innerhalb der Happy Eyeballs-Bibliothek implementiert.

Wenn eine IPv4-Adresse anstelle eines Hostnamens an die Bibliothek übergeben wird, fragt das Gerät das Netzwerk nach dem NAT64-Präfix unter Verwendung von "Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis" (Entdeckung des für IPv6-Adresssynthese verwendeten IPv6-Präfixes) [RFC7050] ab und synthetisiert dann eine geeignete IPv6-Adresse (oder mehrere) unter Verwendung der in "IPv6 Addressing of IPv4/IPv6 Translators" (IPv6-Adressierung von IPv4/IPv6-Übersetzern) [RFC6052] beschriebenen Kodierung. Die synthetisierten Adressen werden dann in die Adressliste eingefügt, als wären sie Ergebnisse von DNS-Abfragen; Verbindungsversuche folgen dem oben beschriebenen Algorithmus (siehe Abschnitt 5).

7.2. Hostnamen mit defekten AAAA-Einträgen (Hostnames with Broken AAAA Records)

Zum Zeitpunkt des Schreibens gibt es eine kleine, aber nicht vernachlässigbare Anzahl von Hostnamen, die sich in gültige A-Einträge und defekte AAAA-Einträge auflösen, die wir als AAAA-Einträge definieren, die scheinbar gültige IPv6-Adressen enthalten, aber diese Adressen antworten nie, wenn sie auf den üblichen Ports kontaktiert werden. Diese können beispielsweise verursacht werden durch:

• Tippfehler der IPv6-Adresse in der DNS-Zonenkonfiguration

• Routing-Schwarze-Löcher

• Dienstausfälle

Während ein Algorithmus, der den anderen Abschnitten dieses Dokuments entspricht, solche Hostnamen in einem Dual-Stack-Netzwerk korrekt behandeln würde, funktionieren sie nicht unbedingt korrekt in reinen IPv6-Netzwerken mit NAT64 und DNS64. Da DNS64-rekursive Resolver darauf angewiesen sind, dass die autoritativen Nameserver negative Antworten ("kein Fehler keine Antwort") für AAAA-Einträge senden, um zu synthetisieren, synthetisieren sie keine Einträge für diese bestimmten Hostnamen und leiten stattdessen den defekten AAAA-Eintrag weiter.

Um diese Szenarien zu unterstützen, muss das Client-Gerät den DNS nach dem A-Eintrag abfragen und dann eine lokale Synthese durchführen. Da diese Arten von Hostnamen selten sind und um die Last auf DNS-Servern zu minimieren, sollte diese A-Abfrage nur durchgeführt werden, wenn der Client die anfänglich empfangenen AAAA-Einträge aufgegeben hat. Dies kann durch Verwendung eines längeren Timeouts erreicht werden, das als "Last Resort Local Synthesis Delay" (Verzögerung der lokalen Synthese als letztes Mittel) bezeichnet wird; die Verzögerung wird mit 2 Sekunden empfohlen. Der Timer wird gestartet, wenn der letzte Verbindungsversuch ausgelöst wird. Wenn kein Verbindungsversuch erfolgreich war, wenn dieser Timer ausgelöst wird, fragt das Gerät den DNS nach der IPv4-Adresse ab und behandelt sie beim Empfang eines gültigen A-Eintrags, als wäre sie von der Anwendung bereitgestellt worden (siehe Abschnitt 7.1).

7.3. Virtuelle private Netzwerke (Virtual Private Networks)

Einige virtuelle private Netzwerke (Virtual Private Network, VPN) können so konfiguriert sein, dass sie DNS-Abfragen vom Gerät verarbeiten. Die Konfiguration könnte alle Abfragen oder eine Teilmenge wie "*.internal.example.com" umfassen. Diese VPNs können auch so konfiguriert sein, dass sie nur einen Teil des IPv4-Adressraums routen, wie 192.0.2.0/24. Wenn sich jedoch ein interner Hostname in eine externe IPv4-Adresse auflöst, können diese Probleme verursachen, wenn das zugrunde liegende Netzwerk nur IPv6 ist. Nehmen wir als Beispiel an, dass "www.internal.example.com" genau einen A-Eintrag, 198.51.100.42, und keine AAAA-Einträge hat. Der Client sendet die DNS-Abfrage an den rekursiven Resolver des Unternehmens, und dieser Resolver antwortet mit diesen Einträgen. Das Gerät hat jetzt nur eine IPv4-Adresse, zu der eine Verbindung hergestellt werden soll, und keine Route zu dieser Adresse. Da der Resolver des Unternehmens das NAT64-Präfix des zugrunde liegenden Netzwerks nicht kennt, kann er die Adresse nicht synthetisieren. Ebenso kennt der DNS64-rekursive Resolver des zugrunde liegenden Netzwerks die internen Adressen des Unternehmens nicht, sodass er den Hostnamen nicht auflösen kann. Aus diesem Grund muss das Client-Gerät den A-Eintrag unter Verwendung des Resolvers des Unternehmens auflösen und dann lokal eine IPv6-Adresse synthetisieren, als ob die aufgelöste IPv4-Adresse von der Anwendung bereitgestellt worden wäre (Abschnitt 7.1).