Was sind die Nachteile der Aktivierung von IPv6 in öffentlich zugänglichen Diensten?

Unser internes Netzwerk und unsere internen Dienste sind IPv6-fähig. Wir erwägen, IPv6 auf öffentlich zugänglichen SMTP-, DNS- und Webservern zu aktivieren. Alle Anleitungen / Whitepaper, die ich zu diesem Thema gelesen habe, sprechen nur über die Vorteile, aber ich bin sicher, dass es auch einige Nachteile gibt. Zum Beispiel:

1. Clients mit IPv6 über Tunnel haben langsameren Zugriff auf unsere Dienste, wenn wir IPv6 aktivieren.
2. Clients mit defektem IPv6 können überhaupt nicht darauf zugreifen.

Angesichts der Tatsache, dass nur ein sehr kleiner Prozentsatz der Benutzer über IPv6 verfügt und diese normalerweise Dual-Stack-fähig sind, bin ich der Meinung, dass die Aktivierung von IPv6, wenn Sie nicht beide Seiten des Kommunikationskanals steuern, 2011 eine schlechte Idee ist .

Gibt es Forschungsergebnisse / Artikel / Artikel zu diesem Thema?

Dieser Artikel gibt einen Überblick über ein reales Experiment. Sie behaupten, nur geringfügige Probleme zu haben.

Möglicherweise hilft es ein wenig , Ihre DNS-Server so zu konfigurieren, dass IPv6-Antworten nur über IPv6-Schnittstellen gesendet werden. Dadurch werden ISPs ausgeschlossen, die überhaupt kein IPv6 haben. Nicht alle Clients verwenden DNS-Resolver, die von ihrem Internetdienstanbieter bereitgestellt werden, die meisten jedoch. Auch ISP mit IPv6 bedeutet nicht, dass Kunden IPv6 haben. Es ist jedoch eine Verbesserung.

Übrigens, wenn jemand klug genug ist, einen Tunnel einzurichten, weiß er wahrscheinlich, was er tut und sollte nur sich selbst die Schuld geben. :) :)

Bearbeiten:

BIND9 Handbuch:

filter-aaaa-on-v4 Diese Option ist nur verfügbar, wenn BIND 9 mit der Option --enable-filter- aaaa in der Befehlszeile "configure" kompiliert wurde. Es soll den Übergang von IPv4 zu IPv6 erleichtern, indem DNS-Clients keine IPv6-Adressen zugewiesen werden, es sei denn, sie haben Verbindungen zum IPv6-Internet. Dies wird nur empfohlen, wenn dies unbedingt erforderlich ist.

... Dieser Mechanismus wird sowohl auf autorisierende als auch auf nicht autorisierende Datensätze angewendet. ...

Der Welt-IPv6-Tag Anfang dieses Jahres war ein Test dafür. Die Ergebnisse waren gemischt , endeten jedoch besser als befürchtet . Die Angst war Massenbruch, da IPv6-fähige Clients auf v6-Inseln keinen Zugriff auf v6-Sites erhalten konnten, aber dies geschah nicht annähernd so oft, wie theoretisiert.

Ein großer Vorteil ist, dass moderne Browser mit der v4 / v6-Jiggery-Pokery so umgehen, dass Benutzer nicht annähernd so verärgert sind wie noch vor zwei Jahren.

In der Praxis ist einer der größten Erfolge bei der Einführung von v6, dass bei einigen v6-Clients mit v6-Tunneln anstelle von nativen v6-Verbindungen zum Internet der Datenverkehr möglicherweise länger / langsamer zu Ihrer Site führt als bei nativen v4-Clients. Es wird immer noch funktionieren, es wird nur langsamer geladen.

Die Ergebnisse des Welt-IPv6-Tages haben gezeigt, dass dies kein großes Problem ist. Jemand mit einem IPv6-Tunnel hat sich bewusst für diesen Tunnel entschieden. Wenn der Tunnel also viel langsamer als IPv4 ist, ist dies nach Wahl des Benutzers / Systemadministrators. Die aktuellen Browser (Firefox, Chrome, Safari und in naher Zukunft sogar IE) verwenden ein System namens Happy Eyeballs oder ähnliches. Sehr grobe Beschreibung: Beim Öffnen einer IPv6-Verbindung ist ein kurzer Timer eingestellt (ich denke, Chrome verwendet 300 ms). Wenn dieser Timer abläuft, bevor die IPv6-Verbindung hergestellt wurde, wird versucht, eine IPv4-Verbindung einzurichten. Der Benutzer wird keine potenziellen Probleme mit IPv6 bemerken.