zumindest was den Versand von E-Mails über GMX angeht, hat SpaceRat eine brauchbare (Übergangs-)Lösung parat: http://www.unitymediakabelbwforum.de/viewtopic.php?f=53&t=30186&start=60#p316469
Die funktioniert - wenn man sie abwandelt - auch mit allem anderen.
Es ist eigentlich nur eine Variante
dieses Vorschlages, den ich Betroffenen schon vor einem halben Jahr gemacht habe.
Die Benutzung eines solchen externen DNS64/NAT64-Providers hat - wie jeder Übergangsmechanismus - auch gewisse Nebeneffekte:
Server, die die Absender-IPv4 des Clients für irgendwas nutzen, werden in die Irre geleitet, da sie nun die IPv4(s) des NAT64-Providers sehen.
Das kann positiv sein:
- Wenn GMX oder andere Server-Betreiber tausendfache Zugriffe von diesen IPv4-Adressen sehen, dann könnten sie ggf. merken, daß es Zeit wird, die Finger aus dem 4rsch zu kriegen und mail.gmx.net, pop.gmx.net, ... so langsam auch mal per IPv6 erreichbar zu machen.
- Server, die es mit der Privatsphäre nicht so genau nehmen, sehen immerhin nicht direkt Eure IPv4 (Über die Header allerdings schon).
... aber auch negativ:
- Dienste, die über die Absender-IP freigeschaltet werden, funktionieren nicht mehr. Beispiel: Horizon go.
Den letzten Effekt könnte man übrigens beseitigen:
1. Horizon auch per IPv6 erreichbar machen
Das ist immer noch die größte Schande im Hause Unitymedia, daß sie selbst nicht fr3ssen, was sie den Kunden auftischen.
Kein einziger Unitymedia-Server/-Dienst ist per IPv6 verfügbar!
Bei Problemen mit dem AFTR-Gateway kommt der UM-Kunde nicht einmal auf die Unitymedia-Seiten, um nach der Telefonnummer oder ins Kundencenter zu gucken ... 2. Selber einen (non-public) NAT64/DNS64-Dienst anbieten
Das sind die Punkte, wegen derer man eigentlich sauer auf Unitymedia sein sollte.
Sie tun
rein gar nichts um die Probleme zu lösen oder zu lindern!
"Dual-Stack/IPv4 für alle" geht wirklich nicht, das ist so und das bleibt so.
Aber DS-lite, CGN usw. heißen eben auch nicht, daß es so laufen muß, wie es aktuell läuft.
Wenn die AFTR-Gateways aber seit mehr als einem halben Jahr unter der Last ächzen und stöhnen und weder neue/größere wie Pilze aus dem Boden schießen oder zusätzliche Maßnahmen wie eigene NAT64/DNS64-Server ergriffen werden, dann popelt man sich in Kerpen definitiv nur in der Nase rum. Nochmal zurück zur /etc/hosts-Methode:
Es ist insofern nur eine Variante der DNS64-Lösung, als einfach nur die dringlichsten Hosts gezielt über einen solchen aufgelöst wurden:
Code:
C:\>nslookup mail.gmx.net 2001:8b0:6464::1
Server: totd.aa.net.uk
Address: 2001:8b0:6464::1
Nicht autorisierende Antwort:
Name: mail.gmx.net
Addresses: 2001:8b0:6464:0:666:616:d4e3:11a8 2001:8b0:6464:0:666:616:d4e3:11be 212.227.17.190 212.227.17.168
Durch diese Auflösung erfährt man die NAT64-Adresse des aufzulösenden Hosts.
Wenn man diese dann in /etc/hosts bzw. C:\Windows\system32\drivers\etc\hosts einträgt, dann wird sie fortan auch verwendet ohne den DNS-Server im LAN komplett auf 2001:8b0:6464::1 umzustellen (/etc/hosts hat Vorrang vor der Auflösung durch einen DNS-Server).
In der Konsequenz heißt das, das man das auch mit jedem anderen IPv4-only-Server machen kann, mit dem man über AFTR Probleme hat:
1. Auflösen
Code:
C:\>nslookup www.ebay.de 2001:8b0:6464::1
...
Name: a1985.b.akamai.net
Addresses: 2001:8b0:6464:0:666:616:1743:ffca 2001:8b0:6464:0:666:616:173f:6208 23.67.255.202 23.63.98.8
Aliases: www.ebay.de www-de.g.ebay.com www.ebay.de.edgesuite.net
2. /etc/hosts entsprechend ergänzen:
Code:
2001:8b0:6464:0:666:616:1743:ffca a1985.b.akamai.net
2001:8b0:6464:0:666:616:173f:6208 a1985.b.akamai.net
2001:8b0:6464:0:666:616:1743:ffca www.ebay.de
2001:8b0:6464:0:666:616:173f:6208 www.ebay.de
2001:8b0:6464:0:666:616:1743:ffca www-de.g.ebay.com
2001:8b0:6464:0:666:616:173f:6208 www-de.g.ebay.com
2001:8b0:6464:0:666:616:1743:ffca www.ebay.de.edgesuite.net
2001:8b0:6464:0:666:616:173f:6208 www.ebay.de.edgesuite.net
(Also jede der zurückgemeldeten IPv6-Adressen für jeden der zurückgemeldeten Hostnamen/Aliase eintragen)
Das geht natürlich auch umgekehrt, indem man
2001:8b0:6464::1 und 2001:8b0:6464::2
oder
2001:67c:27e4::46
oder
2001:67c:27e4::64
oder
2001:67c:27e4:1002::64
als DNS-Server nutzt und dann für Server, die auf die UM-Absende-IPv4 angewiesen sind, die IPv4 vorgibt:
1. Auflösen:
Code:
C:\>nslookup www.upclive.com
...
Name: www.upclive.com
Addresses: 2001:8b0:6464:0:666:616:d52e:f249 213.46.242.73
(Jeder DNS64-Server meldet auch weiterhin die ursprüngliche IPv4 zurück, da es ja auch Clients und Client-Programme gibt, die nur IPv4 können. Ein IPv6-fähiger Client wird diese aber nicht nutzen.)
2. /etc/hosts ergänzen:
Code:
213.46.242.73 www.upclive.com
(Also
nur die originale IPv4 und nicht die NAT64-IPv6 eintragen.)
Muß jeder für sich entscheiden, was bei ihm weniger Arbeit macht:
- DNS64 durch Verwendung der o.g. DNS64-Server als default, damit IPv6 für alles (ggf. via NAT64) bei fallweiser Umgehung für Hosts, die das nicht vertragen.
oder - Normaler DNS und damit IPv6 nur bei Servern die es nativ können und fallweiser Umgehung des AFTR-Gateways durch NAT64 bei Hosts die via DS-lite nicht gut laufen.
Mit Routern, die fortgeschrittene Konfigurationen erlauben, z.B. Fritz!Boxen mit Freetz oder OpenWrt und jeweils DNSMasq, kann man das auch eleganter für das ganze Netz lösen:
Code:
# NAT64-Server
server=2001:8b0:6464::1
server=2001:8b0:6464::2
# Folgende Dienste nutzen LBS und dürfen NICHT vom NAT64-Server aufgelöst werden
server=/horizon.tv/2001:4860:4860::8888
server=/omtrdc.net/2001:4860:4860::8888
server=/link.theplatform.com/2001:4860:4860::8888
server=/unitymedia.de/8.8.8.8
# Zeitserver, nicht mit zusätzlicher Latenz durch NAT64-Server belasten:
server=/ntp.org/8.8.8.8
Hier wird dann einfach als Standard-DNS-Server der NAT64-Server eingetragen, aber für bestimmte Domains ein normaler, hier Google-DNS.
Daß das alles eigentlich nicht Aufgabe des Kunden sein kann steht dabei wohl außer Frage.
