Am Sonntag, 10. März 2013, 09:27:29 schrieb Michael Schnupp: > Am 9. März 2013 11:00 schrieb Thomas Schäfer <[email protected]>: > > Da ich heute einen public NAT64/DNS64-Service gefunden habe, können wir > > auch > > während des Workshops das ausprobieren, was bei den Kunden einiger US- > > amerikanischer Mobilfunkkunden schon lange gang und gäbe ist - IPv6 only, > > und > > trotzdem alles(?) erreichbar. > > Ich hatte früher(tm) eine ganze Weile mal ein IPv6-only-Netz für zu Hause > im Einsatz. > Man nehme einen guten alten Wlan-Router mit OpenWRT, installiere darauf > einen Tunnel-Client für die IPv6-Anbindung, einen totd um ipv4-Adressen im > DNS umzuschreiben und ein NAT-PT(?)-Packet (ich komme spontan nicht mehr > auf den Namen) das die umgeschriebenen Adressen wieder nach IPv4 > weiterreicht.
Die Zeiten haben sich zum Glück etwas geändert. Es werden immer mehr native IPv6-Anschlüsse ausgerollt. http://www.vyncke.org/ipv6status/compare.php?metric=p&countries=de Im DSL/Kabel-Bereich mit unterschiedlichen Konzepten. Während die DTAG auf echtes Dualstack setzt, setzen einige Kabelbetreiber auf DS-lite - einem IPv4- Tunnel, dessen Adressen meist auf Carrier-Seite schon geNATet werden. (CGNAT). In Frankreich sind nach meinen Informationen viele Anbindung trotz IPv6- Verfügbarkeit auf IPv4 angewiesen - RD-Tunnel hängen von funktionierenden IPv4 ab. Das ließ sich schnell implementieren, hatte aber den Nachteil, dass man die eigentliche Arbeit noch vor sich hat. Frankreich hat deswegen seit Jahren schon einen Verbreitungsgrad von ca 5%. http://www.vyncke.org/ipv6status/compare.php?metric=p&countries=fr Bei Mobilfunkanbietern zeichnet sich ab, dass IPv6-only ohne Dualstack die Lösung ist bzw. in Europa sein wird. Für die Übergangsphase ist NAT64 auf Providerseite vorhanden, d.h. IPv6-Verbindungen gehen glatt durch, IPv4 wird übersetzt. Als freie Lösungen habe ich zwei gefunden: TAYGA http://www.litech.org/tayga/ "nat64" https://github.com/fln/nat64 Beide habe ich aber nicht selbst aufgesetzt. Ich will mich am Samstag nicht an Bastler im engeren Sinne wenden, sondern eher über den zukünftigen (2014) Normalbetrieb unter Linux berichten bzw. vorführen. Als kleine Bastlerlösung habe ich einen SQUID-Proxy im Betrieb, sozusagen die minimale Lösung für IPv6only. Für meine Vorführung vom Netzwerkteilen/Tethering hoffe auch auf Anwesenheit von Apple-Jüngern. Android hat nämlich noch einen hässlichen Bug: http://code.google.com/p/android/issues/detail?id=32630 Notebooks von Vista bis 8 und Linux(PC/Notebook) sollten keine Problem haben, die geteilte (ipv4-freie) automatisch konfigurierte Verbindung nutzen zu können. Zurück zu "Man nehme..." Dazu braucht man kein Openwrt mehr, zumal im Normalbetrieb Dualstack auch schon von aktuellen handelsüblichen Routern beherrscht wird. NAT64 ist ein Fall für ISPs. Ich werde mich wie angekündigt aber in erste Linie den Surfsticks(UMTS/LTE) widmen. Dazu braucht man nur einen aktuellen Modemmanager und das Wissen über einige geänderte Konzepte und Schnittstellen. (und eine SIM - die IPv6-APNs anbietet/freigibt, welche im Moment noch Mangelware ist) Da ich auch "Tethering" vorführen möchte, geht natürlich auch kein Weg an Autokonfiguration und DHCPv6 vorbei. Alles mit Bordmitteln gängiger Distributionen. (und somit auch in openwrt realisierbar, vielleicht ist es auch schon - ich habe openwrt lange nicht angeschaut) > Problem waren lediglich Programmen, die hart auf IPv4 gecodet waren und > Webseiten mit literalen IPv4-Adressen. (google :( ) Für google stimmt das nicht mehr. Die einzige populäre Anwendung, die derzeit nicht mit NAT64 klar kommt, ist skype. Auf einem etwas älteren Ipad (ios4.X) eines Bekannten habe ich gestern eine Handvoll Apps und Webseiten ausprobiert. (auch TV und Radio-streams) > Ich hatte noch versucht IPv4-Unterstützung komplett aus dem Kernel zu > werfen, aber der IPv6-Code war damals einfach nur als Erweiterung von IPv4 > implementiert. Wozu der Aufwand? Ohne vergebene IPv4-Adresse kann der Kernel keine IPv4- Verbindung aufbauen. Und IPv4 ganz heraus schmeißen, kann noch unangenehme Folgen haben. Einige Dualstack-Anwendungen geben dann plötzlich merkwürdige Fehlermeldungen von sich, andere wollen Localhost doch irgendwie noch im Netz 127/8 statt in 1::/128 wissen. > > Ich kann mal noch schauen, was ich davon hier noch finde, aber ich vermute > mal dass sich mittlerweile viel getan hat und man das heutzutage irgendwie > anders machen würde. Es hat sich viel getan. Kurz zusammengefasst: Wie sind beim Abbau der (provisorischen) Tunnel zugunsten von echten Internet. Dafür kämpfen wir mit anderen temporären Zwischenlösungen. Die Flüche einiger Kabelkunden über IPv4-CGNAT sind in einigen Foren sehr laut -sind aber nicht die Schuld von Kabel Deutschland oder unitymedia, sondern das liegt an der allgemeinen Verschleppung der Umstellung. Ein paar Leute müssen jetzt auch in Deutschland den IPv4-Adressmangel ausbaden, solange die IPv6- Verbreitung noch zu wünschen übrig lässt. Auch NAT64 - obwohl es mich überzeugt hat (Es läuft mindestens genauso gut oder schlecht wie das bisherige CGNAT bei Mobilfunkprovidern - nur eben mit der Perspektive dass es zunehmend überflüssig wird.) ist nicht frei von Problemen. > > Wikipedia sagt dazu: http://en.wikipedia.org/wiki/IPv6_transition_mechanisms Über die Funktionsweise von NAT64 muss man zum Glück nicht viel wissen. Man muss nur seine Anwendung (Eintrag der DNS-Resolver) und seine Grenzen (IPv4- Literale) kennen. Ich hoffe am Samstag auf einen großen Erfahrungsaustausch! Mit freundlichen Grüßen Thomas Schäfer PS: So ist aus einer Email wieder ein Roman geworden.... -- Abmelden und Archiv: https://lists.frodev.org/mailman/listinfo/opensourcetreffen-discuss Tipps zu Listenmails: http://wiki.documentfoundation.org/Netiquette/de Alle E-Mails an diese Liste werden unlöschbar öffentlich archiviert
