Moin allerseits,
> setzt jemand NAT64 ein oder hat Erfahrung damit? Wenn ja, welche
> Lösung wird eingesetzt bzw. kann empfohlen werden? Vielen Dank im
> Voraus für Tipps und Hinweise.
habe vor Jahren in Workshops immer wieder ungern TRT (ein
Vorläuferverfahren) vorgeführt. War jedesmal der Teil, der mich am
meisten Nerven gekostet hat...
Ganz allgemein und unabhängig vom exakten Mechanismus oder dessen
Implementierung nur so viel: Wenn's funktioniert ist man heilfroh.
Wenn man Fehler suchen muss, wird's sehr schnell richtig eklig -- NAT
im Weg macht ja die Fehlersuche schon nicht einfach, aber diese
Mechanismen sind nochmal deutlich schlimmer.
Und es gibt tatsächlich Protokolle, die nicht dadurch funktionieren --
im speziellen Fall von faith(4) als TRT-Implementierung so
unwesentliche Sachen wie Ping. Inhärent braucht man für alle Dienste,
die IP-Adressen in der Payload übertragen, mindestens wieder
Basteleien, die das umschreiben -- das betrifft beispielsweise nicht
nur Active Mode VTP, sondern auch SIP, H.323 und generell eben so
ziemlich alle Protokolle, die getrennte Control und Data Streams
verwenden.
Ich gebe Bernhard recht, dass das ganze für den Admin-Zugriff in
manchen Fällen hilfreich sein kann. Aber für End User ohne einen
Admin in der Nähe, den produktiven Betrieb und vor allem als
Universallösung halte ich den Ansatz als solchen für wenig geeignet --
auch wenn jetzt Cisco- und Microsoft-Vertriebler gemeinsam in lautes
Geschrei ausbrechen...
Für den produktiven Betrieb würde ich immer versuchen, so weit wie
irgend möglich auf anwendungsspezifische Proxies auszuweichen. Als
zweite Option kommt grundsätzlich SOCKS (4a oder 5) in Frage, wobei
ich noch keinen Grund hatte, das produktiv zu betreiben. Danach
bleibt ein manueller Proxy mit socat(8) oder ähnlichem und dazu
passendem DNS-Eintrag. Erst wenn das alles nicht hilft, würde ich
über Protocol Translation egal in welcher Form nachdenken -- und dann
als erstes mit der Frage, ob ich mir das wirklich antun will.
Viele Grüße,
Benedikt
--
Business Grade IPv6
Consulting, Training, Projects
Benedikt Stockebrand, Dipl.-Inform. http://www.benedikt-stockebrand.de/
--
ipv6 mailing list
ipv6@listserv.uni-muenster.de
http://listserv.uni-muenster.de/mailman/listinfo/ipv6
