Lästige Problemchen mit dynamischen IPv6-Adressen
Oder: Ausgereift ist auch anders.
Ja, schreien sie alle, wer was auf sich hält, verwendet IPv6.
Natürlich verwende ich seit Jahren IPv6. Ich habe schon mit den ersten Varianten experimentiert, als das noch IPng hieß, und wenn ich mich recht erinnere, war das Ende der neunziger Jahre, als ich das das erste Mal verwendet habe. Damals noch Abenteuer erlebt, weil ich nach einiger Fehlersuche herausgefunden habe, dass mein Switch nicht IPv6-fähig war. Wenn man sowas erzählt, lachen einen die meisten erst mal aus, weil sie meinen, man hätte es nicht verstanden, denn IPv6 ist Schicht 3, Switche sind auf Schicht 2 und denen sollte das Schicht-3-Protokoll völlig egal sein.
Denkste. Die, die lach(t)en, kennen sich nicht aus. Denn die neighbor-discovery verwendet Ethernet Multicast, und die dabei verwendeten Adressen kannte der Chip in meinem Switch einfach noch nicht. Aus dem einfachen Grunde, dass der Chip gebaut worden war, bevor man die Adressen festgelegt hatte. Haben damals nur richtige Netzwerker verstanden, warum es Switche gibt, auf denen IPv6 nicht funktioniert. Ich habe damals vorgeschlagen, für sowas im Linux-Kernel die Möglichkeit vorzusehen, dafür auf broadcast umzuschalten. Nöh, wollten sie nicht. Sieht der Standard nicht vor. Zu arrogant und borniert. Also neuen Switch gekauft.
In das nächste Problem gelaufen. Der Linux-Kernel war damals so programmiert, dass auf einem Interface die Auto Configuration abgeschaltet wird, wenn man das Forwarding einschaltet. Warum? Weil irgendein Armleuchter einen Satz aus einem RFC überinterpretiert hat. Da stand, es gibt in einem Netzwerk IPv6-Clients und Router. Daraus hatten die geschlussfolget, dass man nur entweder das eine oder das andere sein könne. Das ist aber bullshit. Denn sie hatten dabei übersehen, dass die Deutschen das mit dem Datenschutz und den verschiedenen Provider-Tarifen ernster sehen und etwas tun, was die IPv6-Architekten nicht vorgesehen und nicht bedacht hatten: Wechselnde IPv6-Präfix wegen dynamischer Zuweisung. Die waren immer nur davon ausgegangen, dass man etwa einen Notebook-Rechner mal in ein fremdes Netz hängt und auto-konfiguriert, aber nicht, dass sich innerhalb eines Netzes der Präfix ändert. Genau das braucht man aber bei IPv6 in Deutschland/Europa/bei DSL-Providern. Denn während man bei IPv4 RFC1918-Adressen verwendet und der äußere Router NAT betreibt, es die Geräte im Netz also nicht so wirklich interessiert, ob sie die zugewiesene Adresse außen ändert, gibt es bei IPv6 (zumindest nach geplanter Architektur) kein NAT. Stattdessen bekommt jedes Gerät im Netz mehrere Adressen, auch die zum verwendeten offiziellen Präfix. Das heißt, dass einem gar nichts anderes übrig bleibt, als bei einem Präfix-Wechsel auch diese Adressen auf den Geräten zu ändern. DHCPv6 ginge zwar prinzipiell, würde aber immer nur mit Verzögerung funktionieren. Man muss bei Rechnern, die ins Internet wollen, die auto discovery einschalten. Hat man nun aber auf dem Rechner auch Routing-Aufgaben, etwa weil dort der VPN-Tunnel oder eine Virtualisierung läuft, dann funktioniert das eben nicht, weil man nicht beides zusammen haben kann/konnte. Dabei gibt es dafür überhaupt keinen Grund, nur einen, der meinte, die RFCs ganz eng befolgen zu müssen (gut), sie dabei aber willkürlich auslegte und Dinge reinlas, die nicht drin standen (nicht gut), etwa dass man nicht gleichzeitig forwarding und auto discovery haben dürfte. Ließen sich auch nicht überzeugen und lehnten meinen Bug Report ab. Sie wurden dann aber von anderen Leuten, die irgendwann das gleiche Problem hatten, längere Zeit beschimpft, beleidigt, und geshitstormt. Ich glaube, sie haben irgendwann aufgegeben und es so geändert, dass man doch beides haben konnte.
Das waren so frühe IPv6-Abenteuer, aber alle so, weiß nicht mehr genau, 10 bis 15 Jahre her.
Komischerweise lies das Interesse an IPv6 stark nach, wenn man’s mal begriffen und alle Problem verstanden und gelöst hatte. Ist halt auch nur Internet, man kann nicht mehr als mit IPv4.
Irgendwann hatten wir es auch beim Provider für die Web-Maschine, und auch bei den ersten Leuten zu hause, und wieder gab’s Probleme. Weil Rechner nämlich in der Regel so programmiert sind, dass sie beim Zugriff auf Server IPv6 bevorzugen, wenn DNS auch AAAA-Records antwortet. Da kommt man schnell ins fluchen, weil IPv6 im Internet noch nicht sauber, schnell, störungs- und unterbrechungsfrei lief, die Browser und andere Clients aber partout nicht zum freiwilligen Verzicht auf IPv6 zu bewegen waren. Das führte teilweise zu massiven Problemen, weshalb wir das erst mal für einige Zeit wieder abgeschaltet haben. Prompt lief wieder alles stabil und störungsfrei. Erst so seit 1-2 Jahren führt ein zusätzlicher IPv6-Betrieb nicht mehr zu merklichen Funktionsstörungen.
Weniger Probleme hatte ich dabei mit IPv6 zuhause. Oder genauer gesagt, hatte ich damit nie Probleme bis vor ein paar Tagen, als ich dann vom Provider mit IPv6 beglückt hatte. Es lief immer gut, solange sich der Provider da raushielt.
Als ich noch in (bei) München wohnte, war ich bei Kabel Deutschland. Und hatte damals die Fritz Box von denen. Die hatte den Nachteil, dass sie kein Kabel-Modem hatte, und deshalb zusammen mit einem externen Kabel-Modem verwendet werden musste. Dafür hatte sie den Vorteil, dass sie eine normale Fritz Box war, nur mit dem kleinen Unterschied, dass die VoIP-Konfiguration vom Provider auf das Gerät gepusht wurde (notwendig, weil die sich gelegentlich änderte). Ansonsten konnte man die Fritz Box normal konfigurieren und vor allem updaten (auch mit den Experimental-Versionen), und ich habe mir da einfach einen 6to4-Tunnel konfiguriert. Lief prima. Ist zwar getunnelt, aber hat damals alle meine Zwecke erfüllt. Und da man seine externe IPv4-Adresse per DynDNS exportieren kann, kann man sich auch von unterwegs stets die IPv6-Adresse ausrechnen.
Irgendwann ging’s nicht mehr. Denn 6to4 funktioniert darüber, dass der Tunnel zur IPv4-Adresse 192.88.99.1 aufgebaut wird, und das ist keine einzelne Adresse, sondern eine Anycast-Adresse. Heißt, dass nicht ein bestimmter Rechner angesprochen wird, sondern es weltweit viele mit dieser IP-Adresse geben kann, und einfach – nach Wahl des Providers – der nächstbeste angesprochen wird, in der Regel der, des Providers. Und das hat Kabel Deutschland vor ein paar Jahren mal abgesägt. Die hatten einen Rechner, der auf diese IP-Adresse hört, aber nicht tunnelt, und damit ging das nicht mehr. Machte aber auch nichts, denn da bin ich eh umgezogen.
Dann bin ich nach Berlin umgezogen und in einer Gegend gelandet, bei der es kaum Auswahl unter Providern gab, weil kaum versorgt. Da bin ich bei Tele Columbus gelandet, und habe mich über die massiv geärgert. Die haben nämlich zu wenig IPv4-Adressen und deshalb keine offizielle IP-Adressen mehr vergeben, sondern den Kunden hinter Provider-NAT geklemmt. Das Modell gibt es zwar, aber es gehört zu Dual-Stack-Lite, kann also eigentlich nur in Verbindung mit IPv6 als Zugriffsmethode auf alte Server ohne IPv6 angeboten werden. Die haben aber IPv6 nicht hinbekommen und das dann einfach ohne angeboten. Man konnte sich wegen Provider-NAT dann gar nicht mehr von außen zuhause einloggen.
Die Lösung: IPv6. Ich hatte damals einen eigenen, ganz billigen WLAN-Router mit OpenWRT drauf, und auf dem Ding einfach einen SIXXS-Tunnel konfiguriert.
Lief prima. Völlig problemlos, stabil, fehlerfrei. Und problemlos zu konfigurieren, weil statisch. Kein wechselndes Präfix. Brauchte also auch keinen Advertiser, sondern habe einfach die Rechner, auf denen ich das brauchte, entsprechend konfiguriert. Fertig. Läuft. 🙂
Dann nochmal umgezogen.
Wieder bei Kabel Deutschland. Wieder Fritz Box.
Aber, ach. Inzwischen nämlich bekommen die von AVM eigene Fritz-Boxen mit eingebautem Kabel-Modem und grotesk kastrierter Firmware. Viele wichtige Funktionen und Konfigurationen fehlen einfach. Ein massives Ärgernis, aber man kommt (bisher) kaum dran vorbei, denn bei DOCSIS-Kabel-Anbindung kann man nicht einfach ein eigenes Gerät anschließen, sondern nur das, das der Provider liefert (wegen eines Schlüssels und der nötigen Provisionierung). Und man hat die Wahl zwischen einem Doof-Modem mit Analog-Telefonanschlüssen und eben der Fritzbox. Will man also mehr als nur analoge Telefonanschlüsse haben, muss man leider die Schrott-Box nehmen.
Und wieder nur IPv4, aber wenigstens eine offizielle Adresse.
Also wieder SIXXS-Tunnel. Den kann man auf normalen Fritz-Boxen direkt benutzen, nicht aber auf den Kabel-Kastraten von Kabel Deutschland. Also auf einem Odroid (sowas ähnliches wie ein Raspberry Pi) aufgesetzt. Läuft wieder prima. Völlig einwandfrei, stabil, sauber.
Vor ein paar Tagen hatte ich dann ein Netzwerkproblem. Ich konnte einige meiner eigenen Rechner hier im LAN nicht mehr erreichen.
Ursache: Kabel Deutschland hatte einfach mal so heimlich und im Hintergrund IPv6 freigeschaltet. Das führte dazu, dass die Fritz Box nun urplötzlich IPv6 sprach, ihr Präfix per Advertiser verkündete, und sich die Rechner natürlich alle gleich eine Adresse daraus nahmen. So weit, so gut. Bis hierhin ist es schön.
Aber: Die Fritz Box nimmt diese IPv6-Adressen automatisch in ihr DNS mit auf, und gibt sie als AAAA-Record mit auf.
Hat man also einen Rechner namens KISTE, dann hat man vorher dafür nur die IPv4-Adresse bekommen, jetzt aber auch IPv6-Adressen mit dem offiziellen Präfix. Und clients wie ssh, Web-Browser und so weiter verwenden bevorzugt die IPv6-Adresse, wenn sie eine kriegen.
Das hätte so auch funktioniert, und ist ja im Prinzip auch schön. Wer sich mit sowas nicht auskennt, und – wie sicherlich 95% der Nutzer – ohne nachzudenken einfach seine Rechner irgendwie reinstöpselt, hätte überhaupt nicht gemerkt, das sich was geändert hat, und dass sie jetzt IPv6 im LAN verwenden. Die meisten wüssten nicht mal, was der Unterschied ist. Läuft einfach, man bekommt die Webseiten, die man will. So weit, so gut.
Aber, ach.
Ich traue nämlich dieser Fritz-Box nicht sehr weit. Weil ich einem Router, den ich nicht konfigurieren kann, den aber der Provider nach Gutdünken umprogrammiert und auch für dieses Kabel-Deutschland-WLAN für andere Kunden mitbenutzen kann, und der zudem einige Firmware-Versionen hinterherhinkt, einfach nicht traue.
Also habe ich auf den meisten Rechnern eigene Firewalls. Linux iptables.
Und die sind/waren nun mal nicht so ausgelegt, dass sich da jede x-beliebige offizielle IP-Adresse einloggen oder sonst zugreifen kann (logisch, denn wäre alles offen, bräuchte man sie ja nicht).
Was passiert nun aber?
Clients, die die Fritz Box als DNS-Server verwenden, bekommen unter dem Namen eines Servers nun auch IPv6-Adressen und nehmen dann nur noch die, und laufen gegen die Firewall (drop). Bleiben also hängen.
Was also tun?
Ports für offizielle IP-Adressen mit ständig wechselnden Präfixen aufmachen? Es würde nichts passieren, solange die Fritz Box dicht hält. (Zumal ich auf den meisten Diensten auch noch Authentifikation drauf habe.) Aber der traue ich ja nicht so wirklich (um das verkürzt darzustellen).
Oder so, wie ich das bisher gemacht habe, die Link-Local-Adressen (fe80::) verwenden? Wäre die Lösung, die bisher schon so gut funktioniert hat. Geht aber leider nicht glatt, die Fritz Box nimmt die nicht ins DNS auf. Gut, das könnte man über /etc/hosts machen, sowas hatte ich ja auch früher schon, aber richtig schön ist es nicht, weil die Rechner nunmehr ja das Fritz-DNS verwenden soll(t)en, wenn’s schon angeboten wird.
Lösung: Sogar in der kastrierten Fritzbox kann man einstellen, dass sie Unique Local Adresses (RFC 4193) verwenden soll. Das macht sie zwar schon ab Werk, aber nur ersatzweise, wenn IPv6 ausfällt, eben als Ersatz. Man kann im Menü aber auswählen, dass man es immer habenwill (und, wichtig: auch den zufälligen Adressteil eintragen, denn diese Adressen setzen zur Kollisionsvermeidung voraus, dass man nicht FD00::/64 verwendet, sondern einen Zufallsbereich auswählt).
Damit bekommen alle Rechner zwei Präfixe (und doppelte Adressen), einen offiziellen für das freie Internet draußen, und einen aus dem RFC4193-Netz (FD00::/8), die nicht geroutet und nur lokal verwendet wird, ähnlich den RFC1918-Adressen bei IPv4.
Löst im Prinzip genau das Problem.
Öffnet dummerweise aber mehrere neue.
Das erste neue Problem ist, dass clients per DNS immer alle Adressen bekommen und zuerst die offiziellen probieren. Da ich meine Firewalls bei offiziellen Adressen aber auf drop stehen habe, dauert jeder Verbindungsaufbau immer erst mal mehrere Verbindungstimeouts, also mehrere Minuten. Und da sich mit der Zeit durch die Temp-Adressen ziemlich viele ansammeln, kann das dann auch ziemlich lange dauern. Also muss man die Firewall auf REJECT stellen, damit die Versuche sofort abgewiesen werden und man schnell zu den lokalen kommt. Funktioniert zwar, ist aber nicht schön, weil ich es eigentlich nicht mag, auf offizielle Adressen mit REJECT zu antworten, weil der Angreifer dann sieht, dass da was ist.
Das zweite Problem ist, dass man ja im Internet (was ja jetzt automatisch mit IPv6 verwendet wird) nicht immer mit demselben unteren Adressteil gesehen und wiedererkannt werden will, und deshalb unter Linux aktiviert, temporär wechselnde Adressen zu verwenden.
Dummerweise haben sie da wieder gepennt. Man kann es nämlich nicht pro Adressbereich sondern nur pro Interface einstellen. Also fängt die Kiste an, auch die lokalen Adressen zu verändern.
Das an sich wäre auch noch kein Problem, weil man der Kiste ja manuell noch eine feste IP-Adresse dazubraten kann. Unter den meisten Linux-Rechnern mit Desktop macht das aber der NetworkManager. Und der kann das nicht. Der kann nur automatisch oder fest, aber nicht gemischt.
Und das nächste Problem wäre die dynamische Anpassung von Firewall-Regeln, weil iptables nicht für wechselnde Präfixe ausgelegt ist. Mir fehlt da eine Regel die matcht, wenn das Präfix dem auf dem Interface konfigurierten Präfix entspricht. Es gibt auch kein Callback bei Präfix-Wechseln, man müsste also per daemon überwachen, ob sich was ändert. Schön ist anders.
Und die Moral von der Geschicht:
IPv6 kommt zwar. Aber so richtig glatt ausgereift ist das auch nach 15 Jahren noch nicht. Bei Präfix-Wechseln, Firewall-Regeln und dem Willen, nicht so direkt im Internet zu hängen, gibt’s da noch einen Art Kultur-Reibereien zwischen deutschen und amerikanischen (IETF-)Sichtweisen. Mehr oder weniger Datenschutz und Sicherheit.
Mir gruselt’s, wenn ich dran denke, dass auf den IETF-Konferenzen damals sogar besprochen wurde, dass man nicht nur NAT, sondern auch Firewalls abschaffen wollte und die Rechner alle direkt am Internet hängen sollten.
Konfigurationen wie diese Fritz Box sorgen zwar dafür, dass IPv6 unmerklich reinkommen und „Otto Normalverbraucher” IPv6 verwendet, ohne es zu wissen, zu merken oder sich Gedanken darüber machen zu müssen. Sobland man es aber etwas enger zudreht, gibt’s Stolperer.
Zwei positive Nebenwirkungen von IPv4 fallen aber weg: (Nur) RFC1918-Adressen im LAN, und die Entkopplung von der Adresswechselei durch NAT.
43 Kommentare (RSS-Feed)
@Thomas Schäfer:
> Sich einerseits über Provider-NAT beschweren und ganz am Ende IPv4 wegen NAT loben.
Lass Dir halt mal von jemandem den Unterschied erklären.
NAT selbst zu machen hat deutlich andere Auswirkungen als NAT durch den Provider. Bei eigenem NAT kann ich das nämlich jederzeit auch bleiben lassen, sowie statisches NAT eintragen, und mich somit von außen nach innen verbinden. Oder auch VPN-Tunnel aufbauen. Oder mir auf einer anderen Maschine Ports für meine IP-Adresse aufmachen. Das geht bei Provider-NAT alles nicht. Bei eigenem NAT habe ich nämlich immer mindestens ein Gerät (i.d.R. der Router selbst), das nicht durch NAT läuft.
Außerdem hat es auch enorme Auswirkungen auf beispielsweise die Vorratsdatenspeicherung. Bei Provider-NAT müssen die nämlich Verkehr mitschneiden, um es auflösen zu können.
NAT und Provider-NAT ist ein Riesen-Unterschied. Und den sollte man begriffen haben. Nur weil’s beides NAT heißt, ist es noch lange nicht dasselbe. Es kommt darauf an, wer es macht, wo es passiert und wer die Kontrolle darüber hat.
Davon ganz abgesehen habe ich IPv4 nicht wegen NAT „gelobt”, sondern gesagt, dass es eine positive Nebenwirkung hatte. Nämlich eben weil Verbindungen von außen nach innen nur über statisches NAT (o.ä.) laufen. Es ist deutlich schwieriger, sich das so fehlzukonfigurieren, dass man von außen reinkommt. Es ist eine Eigenschaft, die bei IPv6 (konstruktionsbedingt und gewollt) wegfällt.
Willst du uns in den Schlaf wiegeln? Ich bin ja selber IT-Mensch, aber soviel Technik macht mich müde. Gute Nacht!
Kabel BW unterstützt zwar IPv6, aber in der Kombination von Fritz Box, einer alten Time Capsule und mehreren Apple-Geräten führt das regelmäßig zum Totalausfall des WLANs. Habe jetzt die Time Capsule soweit konfiguriert, daß sie nach außen nur IPv4 unterstützt. Wenn ich die Wahl habe zwischen modern und geht nicht auf der einen Seite und geht, ist aber veraltet, dann… Mit dem ersten chinesischen Billigmodem von Kabel BW lief es übrigens. Wahrscheinlich testet AVM nicht mit Mac Hard- und Software.
Bezeichnet die Einschätzung “Positive Nebenwirkung” – kein Lob?
Ich kenne den Unterschied zwischen CGNAT und NAT am eigenen Router.
Trotzdem noch mal Danke für die Erklärung für die, die es noch nicht wussten.
Es wurde nur vergessen, eine “öffentliche” IP-Adresse kann da auch ganz schnell knapp und werden zum zum Spielverderber mutieren.
Zu den IPv6-Punkten: Zum einen wärmst Du uralte Probleme(multicast am switch) auf zum anderen wechselst Du ständig die Anforderungen/die Perspektive.(mal OttoNormalverbraucher – mal “Experte”mit besonderen Wünschen)
Zum Teil schaffst Du selbst Probleme, bei denen Du dann anderen die Schuld gibst.
@Thomas Schäfer:
> Bezeichnet die Einschätzung “Positive Nebenwirkung” – kein Lob?
Nein. Natürlich nicht. Man kann jemanden nicht für etwas loben, was er nicht beabsichtigt und nicht bewusst herbeigeführt hat. Dazu bräuchte es schon eine positive Hauptwirkung.
> Ich kenne den Unterschied zwischen CGNAT und NAT am eigenen Router.
Hörte sich aber gar nicht so an.
> Es wurde nur vergessen, eine “öffentliche” IP-Adresse kann da auch ganz schnell knapp und werden zum zum Spielverderber mutieren.
Wieso „vergessen”? Was ist das für eine unsinnige Aussage? Eine Adresse wird weder knapp, noch mutiert sie.
Das Problem ist ja auch nicht die Adressknappheit, sondern dass TC CGNAT ohne IPv6 angeboten hat, was eigentlich gar kein richtiger Internet-Anschluss ist. Deine Aussage hat damit nichts zu tun. Was soll das überhaupt heißen „zum Spielverderber mutieren”?
> Zum einen wärmst Du uralte Probleme(multicast am switch) auf
Habe ich doch dazu geschrieben, dass das alt ist. Warum soll ich darüber nicht schreiben können, wenn ich eine Historie von Erfahrungen berichte?
> wechselst Du ständig die Anforderungen/die Perspektive.(mal OttoNormalverbraucher – mal “Experte”mit besonderen Wünschen)
Erstens tue ich das nicht, zweitens dürfte ich das, weil man sowas durchaus aus Verbraucher- und Expertensicht sehen kann.
> Zum Teil schaffst Du selbst Probleme, bei denen Du dann anderen die Schuld gibst.
Wo hätte ich hier Probleme geschaffen?
Ich kann Deine Vorhaltungen nicht ansatzweise nachvollziehen, und Deine „pseudotechnischen” Ausführungen auch nicht.
Weiche von mir, Troll!
NAT widerspricht der Idee der durchgehenden End-to-End-Konnektivität des Internet, dass jeder mit jedem sprechen kann. NAT wurde anfangs als Krücke empfunden, ist aber ein bisschen wie die Prothesen von Oscar Pistorius, der damit scheller rennen kann als der Rest der Menschheit ohne Prothesen. In der Praxis hat sich halt herausgestellt, dass das Konzept Gateway + Firewall + NAT in den allermeisten Fällen eines Privat- oder kleinern Firmennetzes viel eher dem Bedarf entspricht. Der Abteilungsdrucker im zweiten Stock muss mit niemandem außerhalb dieses zweiten Stocks sprechen. Natürlich lässt sich das auch ohne NAT implementieren, aber mit NAT lässt sich ein einfaches mentales Modell des Netzwerkes sehr schön 1:1 umsetzen, anders ist das komplizierter und fehleranfälliger.
Die Erfinder von IPv6 haben das nicht erkannt oder ignoriert und proklamiert, dass es mit IPv6 wieder wie in den guten alten Zeiten sein wird, End-to-End für alle. Damit haben sie ein bisschen am Bedarf vorbei designt und erst nachträglich NAT, Privacy Extensions und sonst noch allerhand dazugehackt – das Ergebnis ist alles andere als elegant.
@Lercherl: Ja.
> Damit haben sie ein bisschen am Bedarf vorbei designt
Ja. Da waren, wie so oft, ein paar Fundamentalisten ohne Realitätsbezug und oft auch mit wenig Realitätserfahrung unterwegs, die ihren persönlichen Traum vom grenzenlosen Internet umsetzen wollten. Ist aber halt nicht so, und hat deshalb einige Probleme.
Ich freu mich auf IPv6 mit allen. Dann geht cjdns erst recht transparent und man kann Bittorrent einfach anwerfen und zu allen Verbindung haben, ohne grosses Port freischalten und ohne Abmahnungen. Für die Deutschen. Alle anderen machen sowieso, was sie wollen.
Übrigens ist die Furcht vorm statisch vergebenen Präfix und der MAC seit https://panopticlick.eff.org/ nur noch herzig.
> Übrigens ist die Furcht vorm statisch vergebenen Präfix und der MAC seit https://panopticlick.eff.org/ nur noch herzig.
Nein. Unsinn.
Solche Browseridentifzierungen funktionieren nur, wenn man mit einem Webserver spricht (und der genug Informationen hat). Spricht man etwas anderes als HTTP, funktioniert das nicht. Nutzt man etwas anderes als einen Browser, funktioniert das nicht. Und nutzt man HTTPS, funktioniert das auch bei einem mithörenden Dritten nicht. Sehr wohl aber die MAC.
> und ohne Abmahnungen.
Wie kommst Du auf das schmale Brett?
“Ausgereift ist auch anders.”
Haha! Ob von Dir gewollt oder nicht, das wird mein Referenzartikel dazu, warum ipv6 stinkt. Das ist so ein Müll, designed by Workgroup. Aber man muß ja nicht mal ipv6 fahren, um den Gestank zu riechen. .1x und ipsec kommen ja aus derselben Jauchegrube. Das hat weniger mit ausgereift zu tun, sondern damit, erbärmlichen Bockmist zu nehmen um etwas funktionierendes zu ersetzen. So schlimm ist nicht mal Microsoft.
Hätten sie doch einfach nur den Adressraum vergrössert.
@Hadmut: Du weißt aber schon, dass Drop-Regeln auch keine Rechner verstecken können, oder? Wenn ich ein Paket wegsende und kein ICMP-Host-Unreachable zurückkommt, sondern einfach Stille, dann weiß ich doch, dass da irgendein Rechner sich versteckt. Sei es der Router direkt vor der Adresse, die ich angepingt habe, oder der Rechner an der Adresse selber.
Das einzige, was du mit Drop-Regeln erreichst, sind minutenlange Verbindungsaufbaue. Großartig! Ernsthaft, ich habe nie verstanden, warum Leute immer wieder Drop-Regeln verwenden. Und warum bei Linux iptables die Standardeinstellung für Reject irgendeine seltsame ICMP-Nachricht war, anstatt ICMP-Admin-Prohib (was man immer extra angeben muss).
@nullplan:
> @Hadmut: Du weißt aber schon, dass Drop-Regeln auch keine Rechner verstecken können, oder?
Freilich. Eine Firewall davor würde das ja auch machen.
> Wenn ich ein Paket wegsende und kein ICMP-Host-Unreachable zurückkommt, sondern einfach Stille, dann weiß ich doch, dass da irgendein Rechner sich versteckt.
Nein. Dann weißt Du höchstens, dass eine Firewall dazwischen steckt und das Netz belegt ist, aber nicht diese IP-Adresse. Die meisten IP-Adressen antworten auch gar nichts.
Ich kenne übrigens jede Menge IP-Adressen persönlich, die nichts antworten, und hinter denen auch kein Rechner ist.
Antwortet aber der Rechner sogar selbst mit ICMP-Host-Unreachable, dann weißt Du, dass da was faul ist. Denn wie sollte der Rechner selbst mit Host Unreachable antworten? Bestenfalls Port Unreachable. Damit weißt Du aber, dass der Rechner da ist, denn er antwortet ja. Stell Dir vor, Du klingelst irgendwo und von drinnen ruft einer „Hier ist keiner!”
> Das einzige, was du mit Drop-Regeln erreichst, sind minutenlange Verbindungsaufbaue.
Falsch.
Mit Drop-Regeln erreicht man gar keine Verbindungsaufbauten.
Die Verzögerung ist aber im Internet durchaus gewollt, damit erschwert man nämlich Scans und dergleichen (etwas, zumindest ein bisschen).
Man verhindert/erschwert aber Dinge wie DoS-Attacken, bei denen nämlich ein Angreifer jede Menge Pakete mit gefälschter Absenderadresse seines Opfers losdonnert, und alle Welt dem dann die Leitung mit ICMP usw. dicht macht. Es ist einfach nicht gesund, auf jeden Müll gleich ein ICMP zu verschicken.
> Ernsthaft, ich habe nie verstanden, warum Leute immer wieder Drop-Regeln verwenden.
Befasse Dich mal mit Firewalltechnik und solchen Angriffen und Scans. Dann verstehst Du es.
Meine Firewall-Praxis war immer, Reject zum LAN hin, damit es keine Verzögerungen gibt, Drop zum Internet hin, aus besagten Gründen. Das wird allerdings schwer, wenn man wechselnde IPv6-Präfixe hat und vorher nie so genau weiß, welche Adressebereiche denn jetzt innen und welche außen sind.
Damit ist nämlich die topologische Absicherung nicht mehr möglich (bzw. muss geändert und angepasst werden).
Typo: “bullshit”
Darauf komme ich, weil das wichtigste Medium heute http mit viel Putzmittel/Ajax ist. Mailclients verraten auch eine Menge, vpn, bittorrent und anderes lassen auch ein paar Rückschlüsse zu.
Und die Abmahnungen? Sind heute immer noch territorial gebunden.
Momentan betreibe ich ja auch v6 über SIXX mit einer Fritzbox (an DSL). Nach anfänglichen Schwierigkeiten läuft das inzwischen auch recht stabil. Aber ich befürchte schlimmes, wenn die Telekom flächendeckend v6 ausrollt, wenn ich das so lese.
Gaaanz vorsichtige, kleine Anmerkung, weil’s bei vielen Themen hier immer wieder mal vorkommt:
Nicht jeder Kommentator, der etwas am Text des Hausherrn kritisiert, muss gleich ein Troll sein. Für mich als Außenstehender sieht das dann so aus, als wenn unangenehme Kritik weggedrückt werden soll. Vor allem, wenn der Kommentator weder beleidigend noch ‘off topic’ schrieb, sondern einfach nur anderer Meinung war.
@Klaus:
> Gaaanz vorsichtige, kleine Anmerkung, weil’s bei vielen Themen hier immer wieder mal vorkommt:
Gaaanz vorsichtige, kleine Antwort:
> Nicht jeder Kommentator, der etwas am Text des Hausherrn kritisiert, muss gleich ein Troll sein.
Nicht jeder. Aber manche sind es.
Es geht dabei nämlich gar nicht darum, ob jemand mich kritisiert, sondern wie mich jemand kritisiert.
Und wenn man merkt, dass jemand eigentlich gar nichts sagen kann, die Sache auch nicht verstanden hat, seine Kritik auch nicht begründet, aber mal schnell die Gelegenheit nutzen wollte, mir an die Hütte zu pinkeln, dann ist derjenige ein Troll.
Ich habe Hadmuts Artikel jetzt mal zum Anlass genommen mir die Wiki-Seite über IPv6 nochmal genau durchzulesen und komme zu dem Schluss, dass manuelle Netzwerk-Konfiguration bzw. Problem-Lösung damit zur Geheim-Wissenschaft wird.
Leute wie ich, die in kleineren bis mittelgrossen Firmen-Netzwerken bisher ganz gut Durchblick hatten und z.B. dafür sorgen konnten dass der Netzwerk-Drucker im Keller auch von einem bestimmten anderen Segment in der 3.Etage aus angesprochen werden konnte, die können einpacken bei IPv6-Problemen.
Der “gewöhnliche” Techniker wird sich in Zukunft darauf verlassen müssen dass die Auto-Konfiguration funktioniert. Wenn das nicht klappt kann man entweder einen teuren Spezialisten ordern oder, was dann wohl meist billiger sein wird, das Gerät wegschmeissen und ein anderes besorgen bei dem die Auto-Konfiguration klappt.
Und hier zu fordern dass die Armada von mies bezahlten Technikern der externen Dienstleister sich halt reinknien müsste und sich allesamt zu Spezialisten fortbilden müssten ist nicht realistisch. Ich sehe da ein großes Drama auf die IT-Welt zukommen wenn IPv4 irgendwann abgeschaltet wird. Riesige Halden von funktionierenden, weggeschmissenen Geräten die nicht in’s Netzwerk integriert werden konnten, weil keiner mehr Durchblick hat.
Als Generalist schalte ich das ganze Zeug (Discovery, QoS, IPv6, Letzteres auch in der Fritz!Box) immer gleich nch der Installation aus, weil sie mir bisher eher Nachteile brachten (insbesondere höhere Komplexität bei der Fehlersuche).
Du als Spezialist mit Erfahrung: Wo ist mein wirklicher Vorteil, wenn ich im LAN mit IPv6 arbeite? Gibt es wirklich schon Services, die *ausschliesslich* über IPv6 erreichbar sind?
@.Ralph K.:
> Du als Spezialist mit Erfahrung: Wo ist mein wirklicher Vorteil, wenn ich im LAN mit IPv6 arbeite? Gibt es wirklich schon Services, die *ausschliesslich* über IPv6 erreichbar sind?
Es gibt ein paar exotische Experimentaldienste, die nur mit IPv6 laufen, aber beim allem, was man tatsächlich verwendet, ist das bisher nicht der Fall.
Allerdings gibt es zwar nicht „Services”, sondern Systeme, die nur noch über IPv6 erreichbar sind, wenn Du etwa ein Heimnetz hinter Dual-Stack-Lite hast und IPv4 nur noch über cgNAT läuft.
Auch sind in vielen Ländern – vor allem in Asien und Afrika – die IPv4-Adressen noch viel knapper, da werden also neue Server per IPv4 manchmal nicht mehr erreichbar sein.
Ein anderer Vorteil ist, dass man Adresskollisionen vermeidet. Ich habe vor Jahren, als ich noch Firewalls im Industriebereich installiert habe, schon katastrophale Adresskollisionen erlebt, weil beispielsweise zwei Netze verbunden werden müssen (direkt oder VPN), die beide 10er-Adressen verwenden. Da muss man dann mit doppeltem NAT und Zwischen-Netzen arbeiten, einfach katastrophal.
Und man „lernt” natürlich IPv6.
Im normalen Hausgebrauch ist der Vorteil aber derzeit gering bis Null, es sei denn freilich, man braucht Verbindungen von außen nach innen und leidet unter Provider-NAT. Den ersten allgemeinen Vorteil sehe ich erst dann, wenn es Webserver usw. gibt, die nur noch per IPv6 erreichbar sind.
Bei Kabel-D und Standardbox statt Fritz soll es möglich sein, per Supportseite oder -person diese Box von Router auf Modem zu kastrieren. Dann muss man zwar mit Analogtelefonie leben – oder diese Anschlüsse zur internen Telefonanlage durchreichen – aber kann sich den Router aussuchen.
Zwei positive Nebenwirkungen von IPv4 fallen aber weg: (Nur) RFC1918-Adressen im LAN
wieso sollte mich ipv6 irgendwo im internet hindern nicht-eindeutige ipv4 adressen in meinem netz zu benutzen. das mit den wechselnden ipv6 adressen funktioniert nämlich oft nicht.
@verwirrt:
> wieso sollte mich ipv6 irgendwo im internet hindern nicht-eindeutige ipv4 adressen in meinem netz zu benutzen. das mit den wechselnden ipv6 adressen funktioniert nämlich oft nicht.
Vielleicht habe ich mich missverständlich ausgedrückt.
Ich meinte damit, dass IPv6 das im Vergleich anders macht. Guckst Du aber auf meine Aussage, dann steht da ein (Nur). Und wenn Du IPv6 dazupackst, dann ist es eben nicht mehr „Nur”.
IPv6 kann Dich dann am Gebrauch hindern, wenn Du ein Gerät hat, das nicht Dual-Stack-fähig ist. Es ist nämlich ursprünglich gar nicht vorgesehen, dass ein Geräut IPv4 und IPv6 spricht. Wer IPv6 spricht, darf eigentlich nicht mehr IPv4 sprechen.
Aber selbst wenn: Fast alle Geräte präferieren IPv6 über IPv4. Auch wenn Du IPv4-Adressen vergibst, werden die meisten Geräte sie nicht mehr verwenden, sie nutzen Dir also nichts. So sieht das „hindern” dann aus.
Man kann seine Zeit auch sinnvoller nutzen als sie mit IPv6 zu verplempern. Solche “ich nutze IPv6”-Poser gab es damals auch schon im Studium, für Privatleute hat das exakt 0 nutzen. Na dann weiterhin fröhliches Frickeln und ein gutes Gefühl auf der ‘Höhe der Zeit’ zu sein, arme Schweine ihr seid.
@Yoda
> Man kann seine Zeit auch sinnvoller nutzen als sie mit IPv6 zu verplempern.
Klar.
Aber in meinem Beruf muss man es können, da ist das keine verplemperte Zeit.
Und ich hab’s ja auch nicht aus Spaß gemacht, sondern weil der Provider IPv6 auf dem Router und in meinem LAN freigeschaltet hat, ohne mich zu fragen. Was mir ziemlich auf den Sack geht, wenn der Router nicht mehr die Trennschicht ist und der Provider in meinem LAN herumfuhrwerkt.
Ein wesentlicher Punkt ist aber eben, dass man sich damit auskennen muss, wenn man Informatiker und im Bereich Netzwerk/IT-Sicherheit tätig ist. Dürfte Leuten wie Dir nur schwer einleuchten.
> Na dann weiterhin fröhliches Frickeln und ein gutes Gefühl auf der ‘Höhe der Zeit’ zu sein, arme Schweine ihr seid.
Du bist ein Dummkopf.
Ich habe seit 2000 mit IPv6 experimentiert, nachdem erste “produktive” v6-Stack in FreeBSD aufgenommen wurde. Also Extrem-Early-Adopter. Linux hinkte da übrigens jahrelang hinterher. Dann organisierte man sich einen Tunnel, anfangs hatte ich sogar noch Adressen aus [3ffe::/16]. Und dann wartete man, bis der eigene ISP und die eine oder andere Webseite mal so langsam auf Dual-Stack umrüstet, damit man Probleme frühzeitig erkennen und beheben konnte. Soweit der Plan.
Dann passierte erstmal ein Jahrzehnt lang NICHTS. Man loggte sich per IPv6 ins IRC ein und das war es dann auch schon. Lächerlich.
Gegen 2012 fingen dann die großen Content-Anbieter IPv6 auszurollen. Nun ging plötzlich tunnelbedingt der QoS des eigenen Internetzugangs kräftig nach unten, denn jetzt nahm alles einen Umweg über einen mit 100MBit angebundenen Tunnelhost (für 2002 völlig ausreichend), statt direkt per IPv4 geroutet zu werden.
Eigentlich sollte der eigene ISP schon lange IPv6-Dualstack ausgerollt haben und die Tunnelei längst Geschichte sein. Das passierte aber bis heute (2015) nicht. Technologieführer Deutschland!
Die Konsequenz: IPv6 komplett wieder abgeschaltet, Internetzugang seitdem wieder IPv4-only. Experiment abgeschlossen. Willkommen in der dritten Welt, Rumänien hat eine höhere IPv6-Penetration.
>Aber in meinem Beruf muss man es können, da ist das keine verplemperte Zeit.
Ja klar, dich meinte ich auch nicht.
Ich habe es ja auch ausprobiert damals als die ersten Implementierungen aufkamen. Mir kommen da immer Privatleute in den Sinn die meinen sie bräuchten das, haben nur Ärger damit, reine Zeitverschwendung wenn man es nicht wirklich braucht. Ich habe später mehr darüber gelesen, genutzt habe ich es nie weil es für mich sinnlos ist und eben mehr Probleme macht und Zeit frisst.
Kennt jemand gut Literatur zu dem Thema IPv6?
Bei IPv6 bietet es sich an, Subnetze nach Sicherheitsklassen anzulegen und z.B. Clients, Drucker und Server in jeweils eigene Subnetze zu stellen. Also tendenziell eher kleinere Subnetzte zu verwenden. (/64 sind sie alle, aber mit weniger Nodes, als bei lagacy IP) Die Filter werden dann auf dem Router/Firewall konfiguriert.
Ein Provider-Router, dem man nicht trauen kann und man nicht unter seiner Kontrolle hat ist dafür freilich untauglich. Da hilft nur ein Downgrade auf ein Moden und ein eigener Router.
@Yoga
Nur weil e sfür Dich sinnlos ist, heißt das nciht, daß es für die anderen Zeitverschwendung wäre. Hier sind genügend Informatiker, die mit Netzwerken Ihr Geld verdienen und da ist es unabdingbare Voraussetzung, die Tücken zu kennen.
@Uwe:
Eine brauchbare Einführung ist:
IPv6-Workshop [Zweite Auflage]: Eine praktische Einführung in das Internet-Protokoll der Zukunft
von Dan Lüdke
Sicher noch verbesserungswürdig, aber für den Einstieg i.O.
Den Router so konfigurieren dass er im WAN IPv6 verwendet und im LAN nur IPv4. Geht das und welche Probleme hätte ich dann?
@Fritz:
> Den Router so konfigurieren dass er im WAN IPv6 verwendet und im LAN nur IPv4. Geht das und welche Probleme hätte ich dann?
Ja, das geht. Das Problem, das Du dann hättest, wäre aber, dass Du gar keinen Internet-Verkehr mehr hättest.
Man kann nämlich nicht zwischen IPv4 und IPv6 routen. Es gab zwar mal so einen Gedanken, weil es auch einen IPv6-Bereich gibt, der IPv4 abbildet. Wegen unterschiedlicher Paket-Formate ist es nur schwierig und problematisch möglich, zwischen v6 und v4 hin- und herzurouten und zu natten. Man würde das, wenn überhaupt, nur dann machen, wenn man im LAN nur IPv6 hat und nach außen hin ipv4 sprechen muss. Umgekehrt geht es aber nicht, wenn man kann ja nicht in 32 Bit ipv4-Adresse die 128 Bit der ipv6-Adresse einpacken.
Man kann aber etwas machen, was dem, was Du willst, sehr nahe kommt:
Wenn man nämlich vom LAN nicht direkt ins Internet geht, sondern über Web-Proxies, Mail-Relays, IMAP-Server usw., dann reicht es, wenn nur diese Geräte (die dann z. B. auch in einer DMZ stehen können) IPv6 haben, und das LAN auf IPv4 bleibt.
Da aber alle neueren Betriebssysteme sowieso schon automatisch IPv6 sprechen, wird der Fall so kaum auftreten.
Das Problem ist aber ein ganz anders: Kann der Router im WAN nur IPv6, dann erreicht man so ja erst mal nicht die vielen Server im Internet, die nur IPv4 sprechen. Da müsste man dann NAT64 oder ähnliches anwenden. Mir ist so ein Fall aber bisher nicht untergekommen(obwohl das natürlich auftreten kann), bisher packt jeder mir bekannte Provider zu IPv6 noch IPv4 (mindestens als Dual-Stack-Lite, also cgNAT) hinzu. Kann aber in Zukunft durchaus auftreten.
Also so schlimm finde ich das bei IPv6 aber nicht. Wechselnde Präfixe sind zwar nervig aber nichts, was man nicht lösen könnte.
Für den Otto-Normal-Benutzer ist die Regelung wie in der Fritzbox eigentlich völlig ausreichend: Man trägt nur den Host-Teil in die Portfreischaltung ein und überlässt dem Router, die Firewall bei einem Wechsel des Präfixes zu aktualisieren. Das funktioniert sogar bei OpenWRT, indem man folgendes schreibt: ::bade:affe/-64. Es gibt sogar dynamische DNS, die das können.
Problematisch ist es dann höchstens nur bei dem Subnetzteil, also praktisch bei /64-/56. Der kann sich ja ändern, aber ich sehe nicht wieso es da keine Lösungen für gehen sollte.
Letztlich ist doch das Hauptproblem, dass IPv6 jahrelang einfach nicht notwendig war und deswegen manche Probleme noch nicht aufgetaucht sind. Das kommt doch jetzt erst dank DS Lite. Die Telekom bietet jetzt sogar IPv6 im Mobilfunknetz an!
Von daher einfach noch ein paar Jahre warten, dann sollte das alles ganz gut laufen. Bei Unicode war das doch auch so ein Hickhack, und jetzt wird es fast von jedem Programm unterstützt.
Am schönsten fände ich es übrigens wenn die Provider eine statische und einen dynamischen Präfix gleichzeitig herausbringen würden. Statisch für das LAN und für die Erreichbarkeit von außen, dynamisch als Erweiterung der Privacy Extensions.
> Wechselnde Präfixe sind zwar nervig aber nichts, was man nicht lösen könnte.
Man braucht sie ja gar nicht zu „lösen”. Es funktioniert ja einfach so.
Der Haken ist, dass man firewall- und rechtetechnisch die Adressen nicht mehr eindeutig der Topologie zuordnen kann.
Die Telekom bietet jetzt sogar IPv6 im Mobilfunknetz an!
Und wegen des bescheuerten Mobilfunk-Protokolldesigns braucht man nun ein neues GSM/3G-Endgerät, welches IPv6 explizit unterstützen muß. Und Dualstack ist gleich mal überhaupt nicht vorgesehen.
Naja, ich bin auf das Problem auch schon manchmal gestoßen. Ich probiere aktuell z.B. mal damit rum, bei meinem OpenVPN-Server auch ein IPv6-Netz auf den Tunnel legen zu können.
Klappt auch eigentlich ganz gut:
Ich hol mir mit einem DHCPv6-Client ein Präfix (meine UM-Fritzbox kann ja leider keine statischen IPv6-Routen, deswegen muss ich auf jeden Fall PD machen, damit das in der Fritzbox eingetragen wird), das trage ich dann in der server.conf als “server-ipv6 2001:db8:0:123::/64” ein, und es funktioniert. Naja, solange sich das Präfix nicht ändert (das tut es zum Glück bei UM so selten, dass man das auch noch manuell nachtragen kann). Aber bei Telekom fände ich das schon sehr knifflig. Wobei bei UM auch nervig ist, dass es ein /59er-Netz ist und es den vorletzten Buchstaben vom Hostnetz in Hex-Schreibweise durchtrennt und man so nicht einfach nur die vorderen 3,5 Blöcke ändern kann sondern auch noch bei dem Buchstaben aufpassen muss . Sehr nervig.
Ich fände es daher interessant, so etwas mit einem Alias-Namen zu lösen. Sagen wir mal, ich kriege immer den Block 2001:db8:0:0::/56, den ich dann als “meinblock” bezeichnen würde. Dann würde ich im DHCP-Client sagen, dass er sich daraus ein Subnetz holen soll und dieses dann als “meinblock.openvpn-netz” bezeichnen soll. In der OpenVPN-Config kann ich dann z.B. “server-ipv6 meinblock.openvpn-netz/64” schreiben.
Aber ist das nicht letztlich alles ein Problem für Heimanwender, denen aber die Fritzbox-FW reicht? Und bei Firmen gäbe es dann statische IPs.
Hi Hadmut,
wie hattest Du das gemacht mit den Link-Local-Adressen in der /etc/hosts? Bei mir geklappt das nicht. Das Problem ist die Interfaceangabe.
Beispiel:
ping6 fe80::1234:56ff:fe78:9abc%eth0
funktioniert
/etc/hosts: fe80::1234:56ff:fe78:9abc foobar
ping6 foobar%eth0
funktioniert nicht
/etc/hosts: fe80::1234:56ff:fe78:9abc%eth0 foobar
ping6 foobar
funktioniert nicht
@Hägar: Kann ich gerade nicht sagen, das habe ich nicht probiert und bin gerade unterwegs.
Soweit ich mich erinnere, ist die Syntax aber anders, man gibt das Interface mit -I oder sowas an. Denn bei den fe80-Adressen kann ping6 ja nicht selbst herausfinden, welches Interface das richtige ist.
Außerdem wären ein paar Angaben zu “funktioniert nicht” schon hilfreich.
/etc/hosts: fe80::1234:56ff:fe78:9abc foobar
$ ping6 foobar%eth0
unknown host
ping6 -I eth0 foobar
geht, aber nicht jedes Programm erlaubt die separate Angabe des Interfaces. Dafür hat man ja die %-Schriebweise.
/etc/hosts: fe80::1234:56ff:fe78:9abc%eth0 foobar
$ ping6 foobar
unknown host
Zitat Hadmut: “Man kann nämlich nicht zwischen IPv4 und IPv6 routen.”
Das habe ich befürchtet.
Zitat Hadmut: “Mir gruselt’s, wenn ich dran denke, dass auf den IETF-Konferenzen damals sogar besprochen wurde, dass man nicht nur NAT, sondern auch Firewalls abschaffen wollte und die Rechner alle direkt am Internet hängen sollten.”
Mir ist vieles noch schleierhaft, aber genau das ist jetzt meine Befürchtung, dass mit Einführung von IPv6 die Trennung zwischen WAN und LAN erst aufgeweicht und dann ganz aufgehoben wird.
Ich verliere die Kontrolle über mein LAN, das plötzlich Teil des Internets wird. Schöne neue Welt.
@Fritz
IPv6 hebt die Tennung zwischen LAN und WAN nicht auf, nur weil Du öffentliche IP-Adressen verwendest. Die Hauptursache für derzeitige Probleme liegt in der Umsetzung in den Heim-Routern. Auf den meisten dieser Plastik-Boxen läuft Linux. Mit Linux iptables ist eine Firewall, die eingehenden Traffic analog zu NAT blockiert, einfacher eingerichtet, als NAT. Das ist natürlich nichts für den Standardanwender, das muss der Hersteller machen, aber das macht er bei NAT ja auch.
Wie ich oben schon schrieb, bietet es sich bei IPv6 an, die Subnetzte sicherheitskontextbezogen einzurichten. Auch bei Privatanschlüssen bekomment man ein kleineres Präfix, als /64, so dass man noch Subnetze bilden kann. Viele Heim-Router haben 4 oder 5 LAN-Ports. Da könnte man einfache Filtervorgaben in der Konfig-GUI hinterlegen, z.B.
#1: “LAN mit Internet” (bis bisher bei NAT. Zugriffe nur von innen nach außen erlaubt, z.B. für PCs)
#2: “LAN nur intern” (kein Internetzugriff, z.B. für Drucker)
#3: “WAN” (voller Internetzugriff, auch von außen, z.B. für Server)
Das könnte auf der Hardware ohne großen Aufwand realisiert werden und kann auch ohne große Netzwerkkenntnisse bedient werden. (Im Auslieferungszustand alle Ports auf Regel 1, damit der Kunde keine Überraschung erlebt, mit ein wenigen Klicks hat man es bei Bedarf angepaßt.) Damit ist die Einrichtung schon einfacher als bei NAT, bei dem man Weiterleitungen für individuelle IPs einstellen muß.
Sich einerseits über Provider-NAT beschweren und ganz am Ende IPv4 wegen NAT loben.
Irgendwas passt da nicht zusammen. Und nicht nur da.