Best Practice: IPv6

[wanne]

Abgetrennt aus: viewtopic.php?p=1377234

Nachdem bis jetzt niemand geantwortet hat, werde ich das mal in für dich vermutlich relativ unzufriedenstellender Art und weise machen.

Wie manage ich denn ein IPv6 Netzwerk richtig?

Was "richtig" und was "falsch" ist, liegt immer stark im Auge des Betrachters.
Deswegen werde ich relativ länglich erklären was die Beweggründe hinter IP(v6) waren und wie die Ersteller das gedacht hatten, was daraus wurde und überlasse dir was du für "richtig" hältst:
IPv6 kam 1995 raus. Da war IP(v4) der defakto weltweit frisch etablierte Standard aber eben erst frisch. Es hatte sich gegen diverse Alternativen durchgesetzt. Das war hier das Jahr als die Bundespost ihr Verbot gegen IP-Basierte Dienste zu ungusten von der von ihr gepushten Varianten BTX und Teletex aufhob und der DFN noch strickt Euronet/X.25 als Voraussetzung für Funding verlngte. Auf der anderen Seite des Atlantiks war SNA in der Finanzwelt noch immer unangefochten aber man erkannte die hohen Kosten, DECnet erst weniger Jahre zuvor vom Thron gestoßen wurde und für Privatanwender werkelte hinter den Kulissen noch überall XNS. Ntscape wurde im Selben Jahr veröffentlicht mit dem das Web von einem Ding für irgend welche Wissenschaftlern die mit dem Cern kooperieren zum dominanter Dienst wurde.

Das geschah weil es sich IP als massiv überlegen herausstellte. Aber was waren die Vorteile? SNA war um Größenordnungen Schneller und BTX unfraglich benutzerfreundlicher und mit weniger rechtlichen Problemen verbunden. – Defakto mussten hier in Deutschland erst TDG und TDDSG und später das TMG etabliert werden um Internetdiensten Rechtssicherheit zu geben.
Die Antwort die damals alle gegeben hätten war die höhere Flexibilität, die Neuerungen ermöglichte und die Universalität, die weltweit einheitliche Setups die problemlos überall einfach, billig und ohne Anpassungen deploied werden konnten ermöglichte statt Individuallösungen für jedes lokale Netz.
Ermöglicht wurde das durch folgende Sachen die alternativen nicht aufwiesen:

• IPv4 etablierte die Trennung von IP und TCP ermöglichte damit die Etablierung eines schnellen DNS-Dienstes neben den zuverlässigeren "download-Diensten" wie usenet und gopher.
• Ermöglicht durch das Ende-zu-Ende Prinzip, dass Netzwerk und Anwendung Trennte:
  a) Ermöglichte das auf der einen Seite den Netzbetreibern billigere/schnellere Hardware zu verwenden ohne ihre Anwendungen umzuschreiben und auf der anderen Seite deren Kunden einfach Hardware eines anderen Betreibers umzusteigen, wenn der billiger/schneller war.
  b) Anwendungsentwicklern beliebig angepasstere/bessere Anwendungen Schreiben die ohne aufwendige Genehmigung einfach überall liefen und deren Preis, weil sich Software einfach kopieren lässt und so die Entwicklungskosten auf beliebig viele Schultern aufgeteilt werden konnte gegen null viel.
• Das funktionierte weil man schlicht die den Namen eines Dienstes wissen musste und den so mit beliebiger Software an beliebiger stelle nutzen und so immer das beste und billigste Produkt nutzen. Outsourcing von Diensten an dezentrale Stellen war integrale Idee hinterm Internet

Die Aufgabe dieser Vorgänger geschah nicht weil plötzlich alle überzeugt von der technischen/ideologischen Überlegenheit waren. Netzbetreiber wären wunderbar glücklich gewesen weiter für jeden Klick im BTX rechtssicher abrechnen zu können und sich jede Neuerung versilbern zu lassen. Privatnutzer wallten eigentlich nur Bundesliga gucken und Geschäfte schlicht eine funktionale Abrechnung haben. Ganz abgesehen von diversen Politikern die großteils nicht begeistert waren ihre Gestaltungsmöglichkeit abzugeben und stattdessen zuzuschauen, wo die Masse hin rennt. Es war irgend wann schlicht nicht mehr vermittelbar dass man für einen 10 mal schlechteren Dienst 10 mal mehr zahlt weil sich Dinge im "freien" Internet 100 mal schneller und besser entwickelten als in den von langer Hand von Unternehmen und Regierungen geplanten Netzen. Und so wurde ein Dienst der für möglichst zuverlässige und Schelle Entwicklung im wissenschaftlichen und militärischen Kontext (Bis 1991 waren kommerzielle defakto vom Internet ausgeschlossen) der Standard für kommerzielle Applikationen.

Da IP nicht für den kommerziellen Anwendungszweck Designed sondern von den einstigen Konkurrenten aus der Forschung übernommen wurde übernahm man halt so viel man musste um möglichst einfach die wichtigsten Vorteile mitzunehmen ohne viel ändern zu müssen und passte nur an, wo es nötig war.
IPv4 sah vor das jeder Nutzer ~2Mio Netze zugeteilt bekommt daraus jedem seiner bis zu 16Mio. Geräte eine IP zuteilt deren Nutzer dann beliebige Software darauf nutzen konnten. Seine Netzwerkhardware ausrollt, Leitungen zu den Nachbarn baut und dann mit denen über Konnektivität verhandelt. Die Daten sollten dann von Nutze zu Nutzer zum Ziel springen ohne expliziten ausgehandelten Routen zu folgen. Das mochte zur Realität von US-Universitäten passen und einige Funkamateure mochten von ähnlichem Träumen. Aber europäische Realität mit staatlichen Kommunikationsmonopolen, die dann an private Unternehmen vergeben wurde sah völlig anders aus:

1. Keiner wollte die über Jahrzehnte entwickelten Sachen einfach über den Haufen werfen und bei 0 anfangen. Für die Migration entstand ein Haufen Tunngeling IP over X.25 für den DFN, SAN over TCP für die Banken...
2. Die 2 Mio. Nutzer waren lächerlich zu klein gewählt. Verhandlungen zwischen Nachbarn zu beidseitigem Vorteil ohne Aufsicht abseits der Realität guter Bürger Gerichte brauchen um sich auf die Astlänge ihrer Bäume im Garten zu einigen. Die Lösung waren ISPs die als Netzwerke aufbauten und einzelne IPs an ihre Kunden (per DHCP) vergaben und dafür (pro vergabezeit) kassierten.
3. Das schaffte das Problem, dass es Netze mit mehr Geräten als vorgesehen gab. Abhilfe schaffte CDIR/Netzmasken und temporär vergebene und wiederverwendete Adressen.
4. Damit wurden Adressen plötzlich ein in Anzahl und Zeit begrenztes Gut. Es etablierte sich NAT um hinter eine IP viele Geräte zu bekommen und damit die Fesselung an ausgehende tcp-Verbindungen und die eine spezielle Variante von UDP, die DNS verwendete für den überwältigenden Teil der Nutzer.
5. Auch in Unternehmen saßen nicht vertrauenswürdige Wissenschaftler die selbständig mit ihren UNIX-Accounts und passenden Berechtigungen auf administrierten Rechnern arbeiteten sonden "Tippsen" die auf ihre DOS-Geräte ohne Rechtemanagement alles installierten, was bei 3 nicht aufm Baum war neben alten Steuerungsmaschienen die blind alles ausführten, was durch die Leitung rein kam, die dafür gedacht war direkt mit dem Bediener verbunden zu sein. Das feuerte den Bedarf nach Firewalls an, die irgend wie die Unterscheidung zwischen "internem" und "externen" Netz, die das Internet abschaffen wollte am leben erhielten.
6. Viele Infrastrukturbetreiber verdienten noch einen Haufen Geld mit Telefonie, SMS und ähnlichen Diensten verdienten die plötzlich Hinz und Kunz überall auf der Welt für einen Apfel und ein Ein anbieten konnten. NAT, Dynamische IPs und Firewalls die das unterbinden konnten und so den Bedarf für teurere Premiumanschlüsse produzierten kamen denen Gerade recht und wurden von denen mit Zwangsroutern und Marketing massiv gepushed. Was zu noch mehr Tunneling und Overlaynetzwerken führte: Du kannst keine eingehende Verbindungen für eingehende Nachrichten/Telefonate annehmen? Pack den Proprietäres Quatschprotokoll einfach in ne ausgehende https-Verbindung und es geht plötzlich durch jede Firewall. Zoom und WhatsApp waren geboren.

Aus der Sicht der treibenden Kräfte hinter IP killte das genau die Apspekte von IP, die es erfolgreich gemacht hatte. Mit SCTP, Multipath TCP, SDDP waren weitere alternativen zu TCP gerade der heiße scheiß. Alle scheiterten an NAT und Firewalls. Nach WWW und Unsnet wartete man mitten im Höhepunkt der DotCom-Blase darauf das der nächst Nerd aus Hintertupfingen das Internet mit der nächsten Killerapp mit eigenem Protokoll revolutionierte. Das geht aber nicht wenn man erst mal Teil von einem proprietären Overlay-Netzwerk sein muss und der ISP die Funktionalität des Netzwerks möglichst stark beschneidet um dann Premiumdienste verkaufen zu können.
Das Ergebnis war ein anderer Ansatz für die Lösung der genannten Probleme

• 2⁶⁴ Netze mit 2⁶⁴ Hosts sollten alle Limitierungen in Anzahl und damit NAT ein für alle mal überflüssig machen. CIDR wurde zwar beibehalten. Aber nur als optionale Optimierung fürs Routing. In den meisten Fällen kann man problemlos mit festen und damit performanteren /64-Masken arbeiten.
• Mit Traffic-Klassen versuchte man noch mehr Differenzierung von Anforderungen von Anwendungen ohne spezielle Anwendungen fest zuschreiben und so Neuentwicklung gleiche Chancen einzuräumen.
• Mit Mobile IPv6 erlaubte man den Nutzern das eigene Netz zu behalten und trotzdem den ISP ihre Netze zu verwalten.
• IPSec wurde als universelles Protokoll zur Abkapselung unsicherer Anwendungen etabliert das von jeder Implementierung unterstützt werden muss.
• Wir erinnern uns die zentrale Idee die Internet von anderen Diensten unterschied, war dass jeder Subnetzbetreiber sein Netzwerk nach belieben umbauen konnte ohne auf eine zentrale Konfiguration warten zu müssen. Mit slaac ging man einen Schritt weiter und setzte die Verantwortung sogar auf Rechner-Level sodass diese individuell upgraden und an ihre Bedürfnisse anpassen konnten. Privacy-Extentions fürs browsen ohne Tracking EUI-64 für Serverdienste und für Linux Nerds ne mischung aus beidem damit Browser neben ssh-Server die für sie optimale Variante aussuchen können.
• Ähnlich konsequent trennte man sich endgültig von den letzten paar Link-Layer Abhängigkeiten und schaffte das Hardwareabhängie ARP und den statisch-geroutete/dynamische-IP-Vergabe UDP ohne IP DHCP krüppel ab und ersetzte alles durch einheitliches Hardware unabhängiges und klar IP-basiertes statisches ICMPv6. Und das vollständig dynamische auch IP-basierte DHCPv6 für geroutete Netzwerke.
• Jede Anwendung ihr eigenes Protokolle mit den eigenen Servern nutzen ohne auf komplexe Overlaynetzwerke angewiesen zu sein. So wie das vor 1989 in IPv4 der Fall war als man im IP-Netz duzende unterschiedliche Cliententypen mit speziellen Aufgaben und Anforderungen durch universelle gleich zu behandelnde Hosts ersetzte (Was Netzwerke ungleich einfacher machte).

Die Antwort auf deine Fragen aus Sicht der IP-Entwickler ist also:

• Du hast in deinem lokalen netzwerk viele 0815 Clients, die einfach nur "online gehen" wollen.
  Dann hast du aber auch diverse Server oder Services: Webserver, Switches, Telefonie-Services, ... eben diverse Dinge die du direkt ansprechen können willst. Und mit direkt würde ich meinen "statisch adressiert".
  Es gibt jetzt in jedem Netzwerk mehr als genug IP-Adressen jeder Rechner kann jetzt mit einem Vollwertigen Internetanschluss versorgt werden. Eine derartige Unterscheidung ist nun wieder vollständig überflüssig. Das ermöglicht es jederzeit Problemlos die Funktionalität von Hosts zu erweitern.
• Naja, Firewalls tun sich mit IP Adressen einfacher als mit Hostnamen, deren dahinter stehende IP sich ggf. immer mal wieder ändert.
  Dein Betriebssystem bietet dir mit IPSec diverse universelle Möglichkeiten auch in unsicheren Netzwerken zu kommunizieren sollten gewisse Anwendungen in ihrer Kommunikation eingeschränkt werden solltest du ihm die Rechte dazu entziehen. Das nachträgliche Filtern von zuvor erstellten Paketen ist nicht nur ineffizient sondern erschwert auch Fehlersuche und das weiterentwickeln von Netzwerkprotokollen massiv. Daneben lassen sich Firewalls einfachst durch Overlaynetzwerke umgehen bieten also keinerlei echte garantieen. Tor und Teredo zeigen das am eindrücklichsten. Und während man nun anfangen kann zu versuchen diese bekanntesten Protokolle explizit zu filtern ist es unmöglich als Organisation jeder weltweiten Entwicklung hinter her zu laufen. Das Spiel zwischen der relativ kleinen Tor- und I2P-Entwickler Communitys und den riesigen Geheimdienstcommunities in Iran und Saudi-Arabien zeigt diese Asymmetrie am eindrücklichsten.
• Was ist der Best-Practice weg um Geräten/Servern/Services im Netzwerk eine Adresse zu verpassen, die ich möglichst zentral pflege
  Die gesamte Idee hinter dem Internet war, dass eben NICHT zentral auf Netzwerkebene sondern an den individuellen Clients konfiguriert wird. So wie Best Practice für sicheres Autofahren ohne Gurt ist das nicht zu tun ist Best Practice das Adressen eben nicht zentral zu vergeben.
• selbst eine Tabelle/Doku pflegen in der ich das alles notiere.
  Es gibt einen sehr gut etablierten Service zum Verwalten von IP-Adressen. Er nennt sich DNS! Sollten sich deine Adressen regelmäßig ändern (was sie nicht sollten) gibt es diverse Methoden diesen dezentralen Dienst automatisiert upzudaten. (Z.B. DynDNS.)

Kann mich da jemand mit einem Praxisbeispiel aufschlauen "wie man das aktuell so macht"?
Wie schon angemerkt wurde IP im heutigen Umfeld defakto von den einstigen Gegnern implementiert. Die waren gar nicht an dem Netzwerk das jedem eine möglichst rapide, bürokratiefreie und flexible Weiterentwicklung ermöglichte. ISPs wollten nicht das jeder Telefondienst unabhängig vom Protokoll gleich gut funktionierte. Die waren Gott froh wenn sie ihren eigenen Schrottdienst durch bevorzugte Behandlung am Leben erhalten konnten. Auch deren Kunden waren keine keine Forscher die Neuland betreten wollten sondern Konsumenten, die möglichst bequem über das abendliche Fußballspiel informiert werden wollten. Der Umstieg auf IP war dem Geschuldet das nach 20 Jahren rapider Entwicklung im Internet die kommerziellen Alternativen unheimlich beschissen aussahen. Sie wollten Lees Web nicht die Grundlagen, die ihm erlaubt haben zu entstehen. Und da nun beide Welten verschmolzen zogen die gleichen Firewalls, Gesetze, Admins und Workarounds im Internet ein wie in Unternehmen. Es gab in den nächsten 20 Jahren keine rapide Weiterentwicklung mehr. Die überwältigende Mehrheit waren "08/15-User" die mit den auf die Regeln der 70erJahre zurückgetrimmten Protokolle der 80er (Namentlich tcp/SSL/http/IPv4) mehr als zufrieden und blockierten jede Weiterentwicklung. Diese Leute hatten aber wenig Einfluss auf die Entwicklung von IPv6. – Wer will das alles bleibt wie es ist, hilft nicht bei der Entwicklung eines neuen Protokolls sondern blockiert dessen Einführung. Daher auch der Tot aller Nachfolger und die Wiredness, das es für viele IPv4-Entwicklungen die exzessiv genutzt werden keine IPv6 äquivalente gibt.

Wer also schlicht ein 70er-Jahre Konsument sein willst der kein Interesse an neu modischem Kram hat und noch weniger Kooperation vom Provider dafür hat, fährt vermutlich anders deutlich einfacher:

• SLAAC ist absolut überall etabliert. Das Rad drehst du nicht mehr zurück. Wie gesagt DHCPv6 ist eigentlich ein vollständiges routing-Protokoll für komplexe Umgebungen mit in Baum-Struktur gerouteten subnetzen und damit eher ein Nachfolger für RIP und Co. Selbst wo DHCP genutzt wird, passiert die IP-Vergabe per SLAAC. Wenn du statische IPs haben willst, lassen sich privacy-extentions abschalten. Da braucht es kein DHCP für. Dann hast du deine EUI-64 Host-Parts auf die du filtern kannst.
• Auch wenn ich dir persönlich DynDNS ans Herz legen würde. Wie gesagt: Dynamische IPs waren nie vorgesehen und entsprechend dünn gesät sind die Implementierungen unter den IPv6 Entusiasten: Auch wenn ULAs wie einst Private IP-Adrressen nie für die Verbindung mit dem Internet vorgesehen waren: Keiner hindert dich daran weiter dein 70er-Jahre privates Netz, dass damit zu betreiben. Damit hast du dann vollständig eigen vergebene IPs unter deiner Kontrolle die du in deine /etc/hosts schreiben und per rsync kopieren kannst. Es ist aber Integralerer Bestandteil von IPv6 verschiedene Adressen auf einem Interface haben zu können. Du brauchst also kein NAT mehr du kannst schlicht beides haben. Die gai.conf ist per default so, dass die öffentliche IP fürs Internet genutzt wird und die Private kannst du dann für internen Traffic verwenden.
• Wenn du wirklich ein bisschen Vorteile ausprobieren willst: Die meisten deutschen Provider geben dir wirklich mehrere Subnetze. Du kannst verschiedene Rechner mit verschiedenen Aufgaben in verschiedene VLANs mit eigenen Subnetzen legen. Dann kannst du unterschiedlichen Traffic aufgrund des subnets unterschiedliche behandeln. Braucht aber halt zumindest nen vlan-fähigen Router. (Also keine Fritz!Box, die VLANs nur auf dem WAN-Port erlaubt.)

[alex0801]

@wanne

Danke für den ausführlichen Beitrag. Da hast du wir wirklich sehr viel Zeit genommen. Tatsächlich kenne ich einen sehr großen Teil der Geschichte. Aber ein paar Details waren mir tatsächlich neu --> wieder etwas dazu gelernt. Deshalb hier explizit nochmal: Danke für den Geschichtsunterricht.

Du hast in deinem lokalen netzwerk viele 0815 Clients, die einfach nur "online gehen" wollen.
Dann hast du aber auch diverse Server oder Services: Webserver, Switches, Telefonie-Services, ... eben diverse Dinge die du direkt ansprechen können willst. Und mit direkt würde ich meinen "statisch adressiert".

Es gibt jetzt in jedem Netzwerk mehr als genug IP-Adressen jeder Rechner kann jetzt mit einem Vollwertigen Internetanschluss versorgt werden. Eine derartige Unterscheidung ist nun wieder vollständig überflüssig. Das ermöglicht es jederzeit Problemlos die Funktionalität von Hosts zu erweitern.

Das ist mir klar. Ich wollte an der Stelle nur sagen: Es gibt Netzteilnehmer die komsumieren nur als Client. Und es gibt Netzteilnehmer die bieten auch Services an. Die Trennung hier sehe ich primär erstmal "gedanklich".

Naja, Firewalls tun sich mit IP Adressen einfacher als mit Hostnamen, deren dahinter stehende IP sich ggf. immer mal wieder ändert.

Dein Betriebssystem bietet dir mit IPSec diverse universelle Möglichkeiten auch in unsicheren Netzwerken zu kommunizieren sollten gewisse Anwendungen in ihrer Kommunikation eingeschränkt werden solltest du ihm die Rechte dazu entziehen. Das nachträgliche Filtern von zuvor erstellten Paketen ist nicht nur ineffizient sondern erschwert auch Fehlersuche und das weiterentwickeln von Netzwerkprotokollen massiv. Daneben lassen sich Firewalls einfachst durch Overlaynetzwerke umgehen bieten also keinerlei echte garantieen. Tor und Teredo zeigen das am eindrücklichsten. Und während man nun anfangen kann zu versuchen diese bekanntesten Protokolle explizit zu filtern ist es unmöglich als Organisation jeder weltweiten Entwicklung hinter her zu laufen. Das Spiel zwischen der relativ kleinen Tor- und I2P-Entwickler Communitys und den riesigen Geheimdienstcommunities in Iran und Saudi-Arabien zeigt diese Asymmetrie am eindrücklichsten.

Ich kann dir nur begrenzt folgen. Klar, ich kann das IPv6 Prefix das ich von meinem ISP bekomme in meinem Netzwerk daheim propagieren, alle bedienen sich daran.
Dennoch brauche ich aus Sicherheitsgründen am Eingang zu "meinem" Netz eine Firewall, weil ich will nicht jeden Dienst (und sei es nur auch ICMP Nachrichten antworten) den ein Netzteilnehmer bei mir daheim anbietet, auch "im großen Internet" anbieten. Klar, z.B. ein rein lokaler Webserver kann ich rein über die lokale IPv6 Adresse am Netzteilnehmer binden. An der "public IPv6" binde ich den Port nicht, und ergo ist der Dienst nicht öffentlich erreichbar.
Aber da nicht jede Software sich ideal verhält, bleibt mir aus Sicherheitsgründen wohl nach wie vor keine Wahl außer am Eingangspunkt (Router) eine Firewall zuhaben die kontrolliert was drin drinnen darf und was nicht. Und an genau dieser Stelle hat man in Firewall Regeln. Und die Regeln sind doch - korrigiert mich bitte jemand wenn ich auch da falsch liege - basieren auf Quell-IP/Ziel-IP, Quell-Port/Ziel-Port, Protokoll (TCP/UDP/...), .. aufgebaut. Ind für solche Regeln muss ich explizit angeben was wer nach wo hin nicht darf. Ergo kann ich hier eine siche alle Nase lang ändernde IP nicht gebrauchen.
Auf genau das wollte ich eigentlich hinaus.
Muss mich noch näher mit SLAAC beschäftigen. Ggf. sehe ich das zu dynamisch und sehe noch den Wald vor lauter Bäumen nicht. Wenn so ein Server sich aus dem public IPv6 Subnetz bedient und dann hinten raus seine MAC in die IP die er sich gibt einfließen lässt, dann ist das ja statisch genug. Praktisch fehlt es mir hier noch an KnowHow. Muss ich ausprobieren und testen. Vielleicht macht's dann "klick".

Was ist der Best-Practice weg um Geräten/Servern/Services im Netzwerk eine Adresse zu verpassen, die ich möglichst zentral pflege

Die gesamte Idee hinter dem Internet war, dass eben NICHT zentral auf Netzwerkebene sondern an den individuellen Clients konfiguriert wird. So wie Best Practice für sicheres Autofahren ohne Gurt ist das nicht zu tun ist Best Practice das Adressen eben nicht zentral zu vergeben.

"Zentral pflegen" war vielleicht die falsche Wortwahl. Aber wie gesagt: Für sowas wie eine Firewall muss ich irgendwo eine Liste haben anhand der ich die Dienst-Anbietenden Netzwerkteilnehmer identifizieren kann.

selbst eine Tabelle/Doku pflegen in der ich das alles notiere.

Es gibt einen sehr gut etablierten Service zum Verwalten von IP-Adressen. Er nennt sich DNS! Sollten sich deine Adressen regelmäßig ändern (was sie nicht sollten) gibt es diverse Methoden diesen dezentralen Dienst automatisiert upzudaten. (Z.B. DynDNS.)

Ich wehre mich absolut nicht gegen DNS. Klar, ich nutze das auch bisher. Aber auch hier wieder das Thema Firewall:
Ich kann zwar auch lokale Netzteilnehmer in meinem Router im DNS eintragen (lassen), aber dann hab ich wieder die Herausforderung "Firewall". Nicht jede Firewall spielt da mit wenn ich statt IPs nun Hostnamen verwende. Für Netzteilnehmer die nur "konsumieren" ist das alles entspannt. Die haben keine Probleme damit wenn ihre Adresse nicht statisch ist. Für die Server-Seite:
Man stelle sich nur mal einen Taxifahrer vor, der einen ans richtige Ziel bringen soll und das Ziel von heute auf morgen und übermorgen erneut, "verschiebt" und unter einer anderen Adresse erreichbar ist. Was gestern noch Hausnummer 10 war, ist morgen vielleicht Hausnummer 110, oder 1456.
Ein Nameserverintrag mit "Serverdienst-XYZ" hilft da, löst aber nicht alles Probleme den Weg an's Ziel vorbei an den Sicherheitskontrollen zu finden.

SLAAC ist absolut überall etabliert. Das Rad drehst du nicht mehr zurück.

FullAck... SLAAC ist ne feine Sache.

Wenn du statische IPs haben willst, lassen sich privacy-extentions abschalten. Da braucht es kein DHCP für. Dann hast du deine EUI-64 Host-Parts auf die du filtern kannst.

Heißt so viel wie: Auf meinen Servern schalte ich die Privacy Extensions ab und schwups haben die Rechner aus dem verteilten Subnetz eine IP die "auf die MAC" endet... Klingt super. Das sollte die Sache sauber lösen. Muss ich nochmal testen.

Auch wenn ich dir persönlich DynDNS ans Herz legen würde. Wie gesagt: Dynamische IPs waren nie vorgesehen und entsprechend dünn gesät sind die Implementierungen unter den IPv6 Entusiasten: Auch wenn ULAs wie einst Private IP-Adrressen nie für die Verbindung mit dem Internet vorgesehen waren: Keiner hindert dich daran weiter dein 70er-Jahre privates Netz, dass damit zu betreiben. Damit hast du dann vollständig eigen vergebene IPs unter deiner Kontrolle die du in deine /etc/hosts schreiben und per rsync kopieren kannst. Es ist aber Integralerer Bestandteil von IPv6 verschiedene Adressen auf einem Interface haben zu können. Du brauchst also kein NAT mehr du kannst schlicht beides haben. Die gai.conf ist per default so, dass die öffentliche IP fürs Internet genutzt wird und die Private kannst du dann für internen Traffic verwenden.

DynDNS nutze ich schon. Hab sogar meinen eigenen DynDNS Nameserver aufgebaut. Wenn's nach mir ginge würde ich auch eher ein statisches IPv6 Präfix nutzen. Aber die ISPs sind da immer noch "von gestern".

Wenn du wirklich ein bisschen Vorteile ausprobieren willst: Die meisten deutschen Provider geben dir wirklich mehrere Subnetze. Du kannst verschiedene Rechner mit verschiedenen Aufgaben in verschiedene VLANs mit eigenen Subnetzen legen. Dann kannst du unterschiedlichen Traffic aufgrund des subnets unterschiedliche behandeln. Braucht aber halt zumindest nen vlan-fähigen Router. (Also keine Fritz!Box, die VLANs nur auf dem WAN-Port erlaubt.)

Bin im IPv6 Vokabular immer noch recht neu: Du meinst die ISPs geben mit dem recht großen /56 Präfix genug Spielraum für weitere Subnetze. Japp, soweit bin ich schon.
Und und wie ich das mit VLAN (ja, kann mein Router, ist keine Fritzbox) weiter verteile/einschränke... Muss ich mal schauen. Ist aber ein interessanter Aspekt den ich so in der Art auch schon im Kopf hatte.

@bluestar
Die Idee mit dem ULA im fdxx:... Bereich hatte ich auch schon. Die gefällt mir eigentlich sogar recht gut. Die "normalen" Clients verwenden IPs aus dem Subnetz des ISPs. Per Firewall erlaube ich da eingehend quasi nix. Ausgehend quasi alles.
Die Server bekommen noch eine ULA Adresse, entweder mit dem Token am Ende, oder mit der MAC am Ende (muss ich testen). In der Firewall kann ich das entsprechend gut berücksichtigen, weil: ändert sich nicht. Bräuchte dann aber wieder NAT...
Wenn ich die IPs aus dem public /56 nehme, sind die (wegen wechselndem Präfix) wieder dynamisch. Für DynDNS kein Problem, aber in der Firewall muss ich dann auch ein Update fahren?!
Muss aber auch mal testen ob und wie gut kein Router mit Hostnamen statt IPs in der Firewall zurecht kommt.

Zusammenfassend lässt sich jedoch sagen, dass du weder DHCPv6 brauchst noch eine händische Liste von vergebenen IPv6 Adressen pflegen musst, da du ja einen DNS-Server hast. (kann auch ein DNS-Server bei deinem Provider sein).

Moment... wenn ich ULA im stil von fdxx:.... verwende, ist die nur lokal. DynDNS macht ja nur sinn für das Public /56 Subnetz das ich vom ISP bekomme. Wenn ich untern für die Serverdienste ULA verwende, bin ich wieder bei NAT ... dann reicht "die eine" IPv6 aus dem /56 Subnetz des IPs direkt am Router, welche ich in DynDNS eintragen muss. Die Liste mit ULA Adressen und Diensten im lokalen Netz brauch ich dann ja dennoch (zur not als Tabelle) damit ich die FW pflegen kann?!




Alles in allem wäre (ich muss aber noch viel lesen und probieren) mein aktueller Plan:

* Das /56er IPv6 Präfix vom ISP für SLAAC im LAN propagieren. Damit können die Clients dann sauber ins IPv6 Internet
* Ein fdxx:... ULA Bereich definieren und den ebenfalls im lokalen Netz propagieren, entweder über die Token-Variante oder über die MAC Variante als Endung in der IP. Damit sind die Server dann ohne wechselndes Präfix immer gleich Adressierbar. Auch für die Firewall.
* Die Router-IPv6 Adresse aus dem /56er ISP Bereich per DynDNS mit einem vernünftigen Hostnamen bekannt geben
* Im Router in der Firewall genau diese IP auf die ULA Adressen NAT'en


Wäre das /56 Präfix vom ISP statisch, könnte ich mir das NAT'en sparen und nur mit Firewall-Regeln die LAN Sicherheit festlegen.

[schorsch_76]

Moment... wenn ich ULA im stil von fdxx:.... verwende, ist die nur lokal. DynDNS macht ja nur sinn für das Public /56 Subnetz das ich vom ISP bekomme.

Ich muss hier noch mal klarstellen: Du lässt zwei Präfixe vom Router verteilen, einmal den statischen mit fdxx:.... und einmal den von deinem Provider zugewiesenen.

Wenn sich das öffentliche Präfix ändert, dann musst du natürlich den DNS aktualisieren und die Firewall neu starten. NAT würde ich im IPv6 Bereich nicht machen.

Naja, würde ich nicht so eng sehen mit dem NAT. Zuhause macht das keine Probleme.

[mino23]

Es wurde hier im thread bereits erwähnt. 1995 kam ipv6 raus. Danach war lange Zeit Ruhe um ipv6. Dann gab es plötzlich einen ipv6 Hype. Viele wollten nach Möglichkeit sofort ipv6 fähig werden. Das kann jeder hier im Forum verfolgen. Ich meine, das war ein deutscher Trend. Bei debian.net ging es zeitgleich wesentlich ruhiger und unaufgeregter zu.

Ja, dann passierte es! Im df fragte ein Nutzer der jetzt Moderator ist, "ob es Webseiten gibt, die er mit ipv6 aufrufen kann und ob es den Aufwand lohne?". Wenn ich mich richtig entsinne kam als Antwort Spiegel online, Heise und fefe. Danach wurde es wieder ruhig um ipv6 - zumindest hier im df.

Wie sieht es denn heute damit aus?

Bei meinem Nachbarn im Heimnetz läuft ipv6. Der hat ipv6 an Rolläden, Dachluken, Außenbeleuchtung, Rasenmäher, Fußbodenheizung u.a.m. vergeben. Auf meine Frage, ob er auch die deutschen Leitmedien mit ipv6 aufruft, sagte er "nein, ich weiß nicht ob die das können".

Ok, sorry, ich habe keine Ahnung wer im www heute via ipv6 erreichbar ist und warum nicht. Wenn sich heute jemand via ipv6 erreichbar machen will, dann ist das zunächst löblich. Aber was soll das?

Mein letzter Stand über ipv6 kommt aus der Zeit, damals, als nftables das iptables ablöste und die Info lautete: ABSCHALTEN! Alles was IPv6 betrifft abschalten. IPv6 ist ein Sicherheitsrisiko. Ja, nftables ist ebenfalls so ein Ding das plötzlich jeder haben mußte. Dieser run kann ebenfalls im df verfolgt werden.

Grundsätzlich rufe ich die Webseiten aller deutschen Leitmedien etwa 1x am Tag auf. Ich habe bisher bei keiner den Hinweis auf ipv6 Fähigkeit gesehen. Oder sollte ich mich selber darum kümmern oder merke ich nichts, weil ich in meinem Haushalt ipv6 getötet habe? Sollte vielleicht alles um mich herum bereits ipv6 sein und ich habe es nicht bemerkt?

Wie finde ich heraus, ob das df ipv6 kann und wie die Adresse lautet? Ich müßte jetzt irgend etwas tun, um das heraus zu finden. Muß ich das? Mir würde ein Hinweis im footer des df genügen. Als ich jung war nannte sich das Service. Aber vielleicht kann das df gar kein ipv6 und meine Aufregung ist für die Gallerie ...

[MSfree]

Wie finde ich heraus, ob das df ipv6 kann und wie die Adresse lautet?

Code: Alles auswählen

nslookup debianforum.de
Server:         192.168.31.1
Address:        192.168.31.1#53

Non-authoritative answer:
Name:   debianforum.de
Address: 142.132.203.155
Name:   debianforum.de
Address: 2a01:4f8:261:4fe1::2

Die letze Zeile sieht eindeutig nach IPv6 aus.

[bluestar]

... Oder sollte ich mich selber darum kümmern oder merke ich nichts, weil ich in meinem Haushalt ipv6 getötet habe? Sollte vielleicht alles um mich herum bereits ipv6 sein und ich habe es nicht bemerkt?

Ich würde an dieser Stelle mal ganz stark behaupten, wenn du das Fehlen von IPv6 nicht bemerkst, dann hast du damit auch erstmal kein Problem. Es gibt jedoch viele - insbesondere jüngere Internetprovider - die setzen IPv6 nativ ein und IPv4 über CGNAT. Bei diesen Anbietern hast du eine schlechtere IPv4 Performance im Vergleich zu den etablierten Anbietern, die dir IPv4 ohne CGNAT bieten.

Gründe sich mit IPv6 im LAN zu beschäftigen sind daher die Einschränkungen die CGNAT mit sich bringt:
* kein VPN von unterwegs aus ins eigene LAN
* überlastetes CGNAT und dadurch langsameres Internet.

[schorsch_76]

Es gibt schon große Änderungen auch im internationalen Netz [1][2]. Ein paar große (westliche) Internetdienste scheinen hier eher die Bremse zu sein [3].

[1] https://www.theregister.com/2024/07/10/ ... v6_update/
[2] https://en.ncsti.gov.cn/Latest/news/202 ... 71038.html
[3] https://whynoipv6.com/

[wanne]

So hier nochmal etwas länger warum die Lösung die echten IPv6ler nicht gut finden. Und warum es trotzdem üblich ist.

Die Trennung hier sehe ich primär erstmal "gedanklich".

Und auf diesen Gedanken wärst du nie gekommen, wenn du nie ein NAT konfiguriert hättest. Und er resultiert halt wieder in NAT-artigen überkomplexen fortschrittsfeindlichen Netzen.

brauche ich […]eine Firewall […] Und an genau dieser Stelle hat man in Firewall Regeln. Und die Regeln sind doch - korrigiert mich bitte jemand wenn ich auch da falsch liege - basieren auf Quell-IP/Ziel-IP, Quell-Port/Ziel-Port, Protokoll (TCP/UDP/...), .. aufgebaut.

Und so lange du mit Gewalt an dieser NAT-Denke Festhältst wird sich IPv6 immer als Fremdkörper anfühlen. Die Idee an IP war nun mal dass die Möglichkeit beliebige Hosts direkt und möglichst schnell adressieren zu können Software deutlich einfacher und damit schneller und sicherer macht. Genau diesen Vorteil versuchst du mit Gewalt wieder kaputt zu schießen. Quasi jedes deiner Argumente fängt an mit: Ich will aber Middleboxes haben und dannn ist das ungeschickt. Selbstverständlich ist aber auch in die andere Richtung Korrekt dass quasi alle Client-Software NAT-Umgehung bereits eingebaut hat. IPv6 zusätzlich anzubieten schafft damit eben nur zusätzliche Komplexität. Dadurch wird Software selten schneller oft unzuverlässiger und immer Unsicherer. Und das ist halt die Krux hinter IPv6 ohne Middleboxes. Wäre IPv4 mit Middleboxes vollständig überlegen. Aber IPv6 ohne Middleboxes+IPv4 mit Middleboxes ist der schlechteste Fall. Da er die Probleme Beider Welten vereint. Ursprünglich hat man ja gedacht, dass es das für ne kurze Übergangszeit ist. Aber da konservative üblicherweise härter ihren Willen durchsetzen während progressive meist nur lauter schreien bleiben die Middleboxes halt.

erlaube ich da eingehend quasi nix. Ausgehend quasi alles.

Das ist so generell erst mal falsch.
Mach Whatsapp/Signal auf und du wirst Eingehende Nachrichten bekommen. Starte Ekiga und du kannst eingehende Telefonate bekommen. Starte dein Tor+Hidden-Service und jeder andere Tor-Nutzer kann unbemerkt deine Webseite aufrufen. Starte dein IRC-SSH-Plugin und du kannst auf deinen lokalen Rechner per ssh zugreifen.
Und ich weiß, du wirst jetzt sagen:
Aus der Sicht von einem NAT ist der Tor hidden Service eine ausgehende Verbindung, weil sich beide Seiten zuvor zum Tor-Netzwerk verbinden. Aus der Sicht von einem NAT ist das eingehende Telefonat eine ausgehende Verbindung, weil beide Seiten die Verbindung gezielt gleichzeitig aufbauen und es so für jeden so aussieht als hätte er angefangen. Aus der Sicht von einem NAT kommt die Nachricht nicht vom eigentlichen Absender sondern wird vom Server in regelmäßigen Abständen abgefragt statt dass sie direkt gesendet wird.
Der Hintergrund warum all diese "Consumer-Anwendungen" keine eingehende Verbindungen "benötigen" ist nicht, dass sie inhärent anders sind. Er ist weil sie mit viel Aufwand dafür gebaut wurden hinter NAT zu funktionieren. Kein ansatzweise normal denkende Mensch würde initial auf die Idee kommen eine Nachricht von mir zum dir zuerst zu Signal zu schicken dann Signal das an Google geben lassen damit du da regelmäßig nachfragst ob du neue Nachrichten bekommen hast. Sondern einfach an dein Handy senden. Ich fahr ja auch nicht wöchentlich nach Rom um da nachzufragen ob ich einen Brief von meinem Freund aus dem Nachbardorf bekommen habe. Der einzige Grund das so umständlich und ineffizient zu machen wäre wenn ihm verboten wäre mich direkt zu kontaktieren.
Aber es funktioniert natürlich. Die Methoden wie man NAT umgeht sind seit langem bekannt. Deswegen kannst du so leben.
Fast jedes verbreitete Betriebssystem (Android, Windows, iOS, XBox) bietet Anwendungen sogar direkt einen Service an mit dem man beliebige eingehende Pakete empfangen kann indem sie eine ausgehende Verbindung zum Hersteller aufbauen über die dann beliebige eingehende Pakete empfangen kann. Da das unter Windows vom Admin abgeschaltet und relativ einfach gefiltert werden kann, bringen die meisten Anwendungen ihre eigene Alternative mit wofür es auch massenhaft libs gibt. Die Funktionalität bleibt es ist nur komplizierter und damit meist langsamer und fehleranfälliger.

Dennoch brauche ich aus Sicherheitsgründen am Eingang zu "meinem" Netz eine Firewall, weil ich will nicht jeden Dienst (und sei es nur auch ICMP Nachrichten antworten) den ein Netzteilnehmer bei mir daheim anbietet, auch "im großen Internet" anbieten.

Dann tu das nicht.

Aber da nicht jede Software sich ideal verhält, bleibt mir aus Sicherheitsgründen wohl nach wie vor keine Wahl außer am Eingangspunkt (Router) eine Firewall zuhaben die kontrolliert was drin drinnen darf und was nicht.

Es gibt 3 Möglichkeiten, warum sich deine Software so verhält
a) Die Software will explizit entgegen deinem Willen eine eingehende Pakete annehmen. Dann nimmt sie eine der oben genannten Varianten. Da die verschlüsselt sind, gibt es absolut keine Möglichkeit, das zu unterbinden. Da tausende Leute NAT haben, passiert das auch. Klar kann sie das verkacken. Aber da bösartige Software vermutlich mehr Arbeit in solche Verstecktackticken steckt, wird sie dabei vermutlich sogar weniger und nicht mehr Fehler machen wird, filtert deine Firewall "gutartigen" Verkehr sogar wahrscheinlicher als bösartigen. Das ist also eine deutlich schlechtere Lösung als allen Verkehr durchzulassen oder schlicht das Kabel zu durchtrennen.
b) Die Software hat einen Fehler, den du nicht beheben kannst.– Du kannst also den einen Fehler nicht beheben, der Entwickler kann/will es auch nicht aber traust dir zu zu beurteilen, dass da keine anderen drin sind? Und das wird zufällig dadurch behoben dass du das verhalten von NAT emulierst? Sorry das ist schon sehr absurd an den Haaren herbei gezogen.
c) Die Software war für eine andere Umgebung (vor ~1995 oder für Server) geschrieben. Dann schießt du die explizit kaputt. In einem Großteil der Fälle um sie dann durch einen Umweg funktional zu machen. Im anderen weil die Funktion nicht gebraucht wird. Das ist der eine Punkt, den die meisten anführen, dass es ja dann die Sicherheit fördert. Sinnvoll ist das auch nicht. Ich mache mal ein anderes Beispiel: Eingaben per Tastatur verursachen selbstverständlich ein Haufen Sicherheitslücken. Man könnte jetzt allen Anwendungen den Zugriff auf die Tastatur weg nimmt und das ja keine Anwendung Zugriff auf die Tastatur braucht, weil man ja auch einfach ne Bildschirmtastatur benutzen kann. Und man sich ja einfach per SSH einloggen kann wenn das zu kompliziert ist. Klar: Jetzt funktionieren einige die Apps erst mal nicht mehr und deswegen verhindert man die Sicherheitslücken von denen aber es ist offensichtlich, dass man die durchschnittliche Sicherheit nicht dadurch erhöht, da man jetzt überall durch SSH-Tunnelt sondern schafft im Gegenteil zusätzliche Sicherheitslücken da jeder Otto-Normalrechner nen SSH-Server braucht und die meisten ihren eigenen veralteten Schrott mitbundeln werden, damit es einfach tut. Das selbe ist wahr für NAT-Umgehung.
Es ist absolut absurd ausgehende tcp-Verbindungen blind zuzulassen egal wie viele Sicherheitslücken sie in der Vergangenheit hatten während man inhärent sicherere Protokolle wie sctp blockiert. Und die Argumentation, dass man das macht weil man das "eine braucht und das andere nicht" ist noch viel absurder. Man kann doch auch für ne Straßensperrung argumentieren dass da ja eh gerade keiner lang fährt. Schieße ein Jahr lang alle ausgehenden Verbindungen kaputt und du wirst sehen, dass das ganze jahr keine ausgehenden Verbindungen genutzt werden. Und ich gehe jede wette ein, dass dir genug möglichkeiten einfallen, wie du den Rechner trotzdem weiter nutzen kannst. (SSH-Reverse-Tunnel...)

Aber was soll das?

Schöne Beispiele:

• Das die Akkus der alten Dummphones trotz viel schlechterer Hardware so lange gehalten haben lag halt vor allem auch daran, dass sie geschlafen haben bis ein Anruf oder eine SMS eintraf. Das Baseband war (und ist) auf nem kleinen sehr stromsparenden Chip und der weckt den Rest vom Handy auf, wenn etwas ankommt. WhatsApp muss dagegen in regelmäßigen Abständen beim Server nachfragen ob neue Nachrichten da sind. Das Handy muss deswegen um Größenordnungen öfter aufwachen, was Strom verbraucht. Deswegen wurde für LTE IPv6 vorgeschrieben. Dummer weise gibt es nicht nur einige, die sich daran nicht halten sondern sogar viel mehr die IPv6 (oder eingehende Verbindungen dort) schlicht weg firewallen man kann also nicht mal für die, die IPv6 haben das polling abschalten. Android schaltet deswegen btw. sogar IPv6 bei allen 4 deutschen Providern ab obwohl die perfekt funktionierendes IPv6 haben. Alle nicht groß genug, damit sie es in Googles-Whitelist für funktionierendes IPv6 geschafft haben. Deswegen 0-Akku-Ersparnis, wenn man IPv6 nutzen würde.
• TCP bricht Downloads ab, wenn man sich IP ändert. Das ist vor allem für Handys doof, die zwischen Mobilfunkmasten oder Wifis hin und her wandern. Bei Multipath TCP passiert das nicht. Da aber Multipath TCP nicht durch NAT (und durch alex0801 artige Firewalls) kommt bricht die Verbindung halt immer noch ab sobald man in ein IPv4 only Network kommt. Mobilfunkprovider und größere Unternehmen leiten deswegen allen Traffic über zentrale Knoten um um da NAT zu machen, damit sich die externe IP nicht ändert. Die Umleitung ist zwar teuer und killt Multipath TCP. Aber da die schlechtere Lösung die bessere killt nutzt die Bessere keiner. Mittlerweile sogar aus dem Kernel geflogen.
• CDIR war inhärent ressourcen hungriger als classfull routing. Vor allem auch, weil es zur massiven Fragmentierung beigetragen hat. Das war schon als es eingeführt wurde klar. Aber als einzige Lösung für den Zuwachs im IPv4-Netz hat man es trotzdem eingeführt. IPv6 nimmt eigentlich den Nachteil wieder weg. Da man großzügiger Subnetze vergeben kann fragmentiert es weniger und man kann die letzten 64Bit schlicht im Router ignorieren. Deswegen ist die RIB für IPv6 nur 15% der Größe von IPv4 obwohl mittlerweile ~75% der Hosts über IPv6 erreichbar sind. Dummer weise hilft dir das als IPv6 user nicht oder nur marginal, wenn der Router mit IPv4 überlastet ist, ist auch den Paket langsam. Selbst da wo dediziert Hardware für beide Seiten genutzt wird, wird halt schlicht weniger für IPv6 gekauft.
• Eine IPv4 Adresse kostet ein vielfaches einer IPv6-Adresse. Da Online-Shops die IPv4-Adresse für die IPv6 Verweigerer aber anyway brauchen, wird kein Produkt billiger, nur weil du es über IPv6 gekauft wurde.
• Ich glaube nicht, dass die Home-Automation Leute je auf die Idee gekommen wären, alles (für sie teuer) über ihre Server umzuleiten, wenn man jeden Staubsauger auch direkt über seine IPv6-Adresse hätte ansprechen können. Aber die wollten halt, dass es überall tut. Scheiß egal welch Firewall zwischen Handy und Staubsauger steht. Und so wird jetzt alles per ausgehende TCP-Verbindung über die Cloud geleitet. Die dann irgend wann abgestellt wird und einen Haufen Elektroschrott verursacht. Und jetzt kommen die Leute das wäre doch eine Katastrophe, wenn jeder aus dem Internet auf meinen Staubsauger zugreifen könnte! Sorry geh nach Timbuktu fake deinen Standort auf Deutschland und guck ob deine Fernsteuerungssoftware tut. Und selbstverständlich tut darüber auch jeder Exploit der über das direkte ansprechen getan hätte. Es ist absolut absurd zu denken, dass das umleiten über den RoboRock-Server das ganze auch nur ein µ sicherer macht.

Wie schon gesagt: Hätten wir getrennte IPv4 mit NAT und IPv6-Netze ohne Middleboxes mit getrennt entwickelter Software würden wir vermutlich heute einen massiven Zulauf zu IPv6 sehen weil da alles schneller, billiger und komfortabler wäre. Aber da wir im IPv6-Netz weitestgehend mit den IPv4-Diensten leben ist da halt wenig Vorteil zu holen solange es diese 25% Verweigerer gibt bzw. die, die alle Vorteile per Firewall kaputt schießen. Oder mindestens so lange es nicht genau so viele gibt, die sich IPv4 und NAT-Umgehungstechniken verweigern. Genau deswegen haben sich die IPv6-Leute so gegen NAT bei IPv6 gesträubt.
Die Idee für den Migrationspfad war, dass zuerst fast alle IPv6 und IPv4 untersützen, weil das relativ billig zu haben ist dann Software entwickelt werden, die die Vorteile von IPv6 nutzt und dann kann IPv4 abgeschaltet werden, weil die Hälfte da eh nicht mehr tun. Wenn man aber IPv6 von Anfang an per Firewall seiner Vorteile beraubt, gibt es keinen Sinn für Softwareentwickler IPv6 zu unterstützen.
Und genau das sehen wir: Auch wenn nicht ganz alle Provider so weit waren: 2010 unterstützte quasi jede verbreitete Software IPv6 meist mit mehr Features als unter IPv4. (Siehe Multiplayer in der xbox 360...) Dann kam eine neue Generation von Entwicklern die keine Vorteile mehr in IPv6 sah weil die Admins eh konsequent alles kaputt geschossen haben. Es kamen Docker, AWS, Microsoft Identity, die IPv4 only waren, weil singlestack IPv4 ist halt billiger als Dualstack...

Aber ich bin hier doch ein wenig "eingeschränkt". Mikrotik's RouterOS tickt da ein wenig anders.

Ja genau aus dem Grund habe die IPv6 Leute immer gepredigt, dass Funktionalität auf dem Router nichts zu suchen hat. Weil man plötzlich Designentscheidungen aufgrund dessen macht, was der Router kann statt aufgrund dessen, was der sinnvollste weg wäre.

[bluestar]

Ich teile deinen Gedanken, dass bei einem reinen IPv6 Netz mit öffentlichem Präfix keine Middlebox-Firewall von Nöten sein sollte auf jeden Fall.

Leider sieht aber heute die IPv6 Realität so aus: Mein Drucker bietet IPv6 aber keine vernünftige Zugriffskontrolle selbst an. Jetzt habe ich die Wahl, entweder er bekommt keine öffentliche IPv6-IP oder ich muss eine Middlebox mit IPv6 Firewall davor schalten.

Daher ist auch mein LAN so gestaltet, das sich ausgehende IPv6 Verbindungen von allen Geräten erlaube, eingehende Verbindungen jedoch durch die Firewall auf dem Router eingeschränkt sein müssen. Wobei ich hier tatsächlich sehr liberal vorgehe, d.h. nur Geräte die auf Grund ihrer Konfiguration nicht selbst abgesichert werden können, werden gefiltert.

Also mein Laptop ist öffentlich per IPv6 erreichbar und gerade im Zusammenhang mit SSH und SCP ist es echt eine feine Sache, wenn man aus dem Internet direkt auf seinen Laptop zugreifen kann.