- In frühen Netzwerken, die vor allem auf Punkt-zu-Punkt-Verbindungen beruhten, war ein Adressschema kaum nötig; mit der Verbreitung von Busnetzwerken zur Kostensenkung häuften sich jedoch Komplexitäten wie MAC-Adressen, Bridging und ARP
- Als Ethernet und IP zusammenkamen, wurden für die Weiterleitung zum nächsten Hop MAC-Adressierung und ARP-Broadcasts nötig, und diese Last vergrößerte sich in großen zusammengeschalteten Netzwerken und bei WLAN erheblich
- In der IPv6-Vision spiegelte sich die Erwartung einer einfacheren Welt wider, in der physische Busse und Layer-2-Internetworks verschwinden und sogar Broadcast, ARP, DHCP und MAC-Adressen entfallen
- In realen Deployment-Umgebungen blieben jedoch IPv4 und bestehendes Framing erhalten, sodass auch Altlasten wie Neighbor Discovery, DHCP, NAT und Layer-2-Bridging weitergeführt wurden
- Um Verbindungen während der Bewegung aufrechtzuerhalten, werden statt Internet-Routing weiterhin Layer-2-Bridging und zentrales Tunneling eingesetzt; Alternativen wie QUIC werden als Umgehung für Roaming genannt
Der Moment, in dem Busnetzwerke alles ruinierten
- In den frühen Umgebungen von leitungsvermittelten Telefonnetzen und Standleitungen gab es nur Punkt-zu-Punkt-Verbindungen, daher brauchte man kein Adressschema; Bits, die an der einen Seite eingespeist wurden, kamen nach einer festen Zeit an der anderen Seite wieder heraus
- Auch nach der Einführung von TDM und virtueller Leitungsvermittlung sah es für Nutzer weiterhin so aus, als führe ein Eingang auf der einen Seite zu einem Ausgang auf der anderen; auch in dieser Phase waren Adressen nicht nötig
- Als Computer mit mehreren Interfaces Bits zwischen Leitungen weiterleiteten, entstanden IP-Adressen, Subnetze und Routing, doch auf Punkt-zu-Punkt-Links waren MAC-Adressen weiterhin unnötig
- Um die Kosten für lokale Standortverbindungen zu senken, entstanden Busnetzwerke, bei denen mehrere Geräte an eine gemeinsame Leitung angeschlossen wurden; getrennt von der Internet-Familie entstanden jeweils eigene Layer-2-Systeme
- Das frühe LAN arcnet verlangte die manuelle Konfiguration von 8-Bit-Layer-2-Adressen per Jumper oder DIP-Schalter; Duplikate führten zu schweren Störungen, aber in kleinen Netzwerken war dieser Nachteil begrenzt
- Ethernet führte 48-Bit-MAC-Adressen ein und löste das Duplikatproblem dadurch, dass schon bei der Herstellung nahezu eindeutige Adressen vergeben wurden
- LAN-Techniken wie IPX und Netware funktionierten innerhalb eines einzelnen Busnetzwerks gut ganz ohne Adresskonfiguration und werden als eine schöne und zuverlässige Ära beschrieben
- Große Unternehmens- und Universitätsnetze mussten wegen des Flaschenhalses eines einzelnen 10-Mbps-Busses mehrere Busse zusammenschalten, entschieden sich dafür aber nicht für das damals noch unreife IP, sondern für Bridging und Switching auf Basis von Ethernet-Adressen
- Ethernet-Adressen wurden sequenziell in der Fabrik vergeben und hatten daher keine Hierarchie; Bridging-Tabellen ließen sich deshalb nicht so effizient zusammenfassen wie moderne IP-Routingtabellen, die Pfade pro Subnetz behandeln
- Für effizientes Bridging musste man sich merken, auf welchem Bus sich jede MAC-Adresse befand
- Um das nicht manuell zu konfigurieren, wurden automatisches Lernen und komplexe Wechselwirkungen nötig
- Komplexe Bridge-Netzwerke wurden mit Verfahren wie spanning tree verbunden, was Broadcast-Flooding, nicht optimale Pfade und geringe Debugbarkeit mit sich brachte
- Für Zwischen-Bridges gab es in gewöhnlichem Ethernet gar kein Adresskonzept, daher konnten Werkzeuge wie traceroute nicht entstehen; Bridging war faktisch eine Struktur, die sich fast nicht debuggen ließ
- Dennoch war Bridging dank Hardware-Optimierung sehr schnell und arbeitete nahe an der Ethernet-Leitungsgeschwindigkeit, was damals ein großer Vorteil war
Das Internet auf dem Bus
- Aus einer Struktur, die einzelne Computer über Fern-Punkt-zu-Punkt-Links verband, entstand allmählich der Bedarf nach Verbindung ganzer LANs über große Entfernungen hinweg
- Einfaches Fern-Bridging funktionierte wegen Problemen der Congestion Control nicht; Ethernet-Bridging arbeitete nur unter der Annahme, dass alle Links ähnlich schnell waren oder kaum Überlast auftrat
- 10-Mbps-Ethernet direkt per Bridging an einen 0,128-Mbps-Punkt-zu-Punkt-Link zu hängen, war aussichtslos, und flooding-basierte Pfadsuche war auf langsamen Links viel zu verschwenderisch
- Nicht optimales Routing, das lokal noch erträglich war, wurde auf langsamen und teuren Fernverbindungen fatal und war nicht skalierbar
- Diese Problemklasse war genau das, womit sich das Internet ohnehin schon befasste; LAN-Busse mit Internettechnik zu verbinden, konnte eine viel bessere Struktur liefern
- Deshalb wurden Frame-Formate entworfen, die Internet-Pakete auf LANs wie Ethernet und arcnet transportieren konnten, und an diesem Punkt begannen die Probleme
- Wenn sich mehrere IP-Router in einem Ethernet-Segment befanden, musste unterschieden werden, welcher Router ein Paket empfangen und weiterleiten sollte; die endgültige Ziel-IP allein konnte diese Wahl nicht ausdrücken
- Daher blieb das Endziel im IP-Header, während der tatsächliche nächste Hop über die MAC-Adresse im Ethernet-Frame angegeben wurde
- Die eigentlich gemeinte Information ist
sende an Ziel-IP 10.1.1.1 über Router-MAC 11:22:33:44:55:66, doch das Betriebssystem behandelt dies in einer Form wieüber Router-IP 192.168.1.1 - Für diese Abstraktion musste das Betriebssystem zunächst die Ethernet-Adresse des Router-IP-Ziels finden; als Zwischenschritt kam ARP hinzu
- ARP sucht den Besitzer einer bestimmten IP, indem es einen Broadcast an das gesamte lokale Ethernet sendet; gibt es Bridges, muss dieser Ethernet-Broadcast an alle Interfaces weitergeleitet werden
- In großen zusammengeschalteten Ethernet-Netzen wurden übermäßige Broadcasts zu einem der schlimmsten Albträume, besonders bei WLAN
- Später bauten Bridges und Switches spezielle Hacks ein, um die Verbreitung von ARP zu begrenzen, und manche Geräte, besonders WLAN-Access-Points, erzeugten sogar gefälschte ARP-Antworten; all das blieb jedoch technisch gesehen ein Hack
Vom Erbe erdrückt
- Mit der Zeit verschwanden Nicht-IP-Protokolle über Ethernet fast vollständig, und Netzwerke verfestigten sich als Struktur aus busartigem Layer 2 auf physischen Leitungen, Bridges zwischen diesen Bussen und darüberliegenden Layer-3-Routern
- Als die manuelle IP-Konfiguration immer lästiger wurde, entstand Bedarf an automatischer Konfiguration; Geräte wurden aber bereits mit Ethernet-Adressen ausgeliefert, und IPv4-32-Bit-Adressen reichten nicht aus, um sie schon in der Fertigung dauerhaft eindeutig zu vergeben
- Eine simple sequenzielle Vergabe von IP-Adressen würde wieder in eine nicht hierarchische Struktur wie bei Ethernet zurückführen und war daher keine gute Lösung
- Deshalb entstanden bootp und DHCP, die wie ARP zu Protokollen wurden, die besonders behandelt werden mussten
- DHCP muss von einem Knoten ohne IP-Adresse zuerst gesendet werden und muss deshalb einen nach RFC festgelegten, praktisch bedeutungslosen IP-Header ausfüllen; DHCP-Server müssen diesen oft direkt per Raw Socket statt über den IP-Stack des Kernels erzeugen
- bootp und DHCP müssen letztlich die Ethernet-Adresse kennen, um eine IP-Adresse zuweisen zu können, und übernehmen damit fast die umgekehrte Rolle von ARP
- Es wird erwähnt, dass RARP dasselbe einfacher erledigte, hier aber kaum behandelt wird
- Am Ende wurden Ethernet und IP immer stärker miteinander verflochten und sind heute nahezu untrennbar
- IP-Routingtabellen tun so, als würden sie Router per IP-Adresse angeben, benennen tatsächlich aber indirekt MAC-Adressen; ARP läuft über Bridges, und DHCP sieht wie ein IP-Paket aus, ist strukturell aber eher ein Ethernet-Protokoll
- Zugleich wurden sowohl Bridging als auch Routing immer komplexer; Bridging blieb weitgehend Domäne von IEEE und Hardware, Routing eher Domäne von IETF und Software, und beide taten so, als gäbe es die jeweils andere Seite nicht
- Netzwerkbetreiber wählten zwischen Bridging und Routing je nach Geschwindigkeitsanforderungen und danach, wie sehr sie die Konfiguration von DHCP-Servern vermeiden wollten; man setzte möglichst viel Bridging ein und nur dann Routing, wenn es nötig war
- Die Komplexität des Bridging führte schließlich zu SDN, das Layer-2-Entscheidungen in höhere Schichten zog und zentral über Protokolle auf IP-Basis steuerte
- SDN war besser, als wenn Switches und Bridges jeweils nach eigenem Gutdünken arbeiteten, wirkte aber grundlegend ironisch, weil IP selbst von Anfang an schon ein softwaredefiniertes Netzwerk gewesen sei, um ein eigentlich zu großes Netz per Software zu beherrschen
- IPv4 war anfangs schwer in Hardware zu beschleunigen und wurde tatsächlich lange nicht ausreichend hardwarebeschleunigt; dazu war DHCP-Konfiguration lästig, sodass Betreiber lernten, immer größere Bereiche zu bridgen
- Heutige große Rechenzentren werden als gewaltige virtuelle Busnetzwerke auf SDN-Basis beschrieben, die Pakete oft faktisch gar nicht routen
Vergessen wir die vorangegangene Geschichte kurz
- Als die IETF Anfang der 1990er Jahre IPv6 entwarf, war bereits viel Verwirrung im Gange, aber die Entwicklung geschah unter der Annahme, man könne die kommende Katastrophe noch vermeiden
- Eine zentrale Veränderung dabei war, dass physische Busnetzwerke praktisch bereits aufgegeben worden waren
- Ethernet war kein echter Bus mehr, sondern tat nur noch so; als höhere Geschwindigkeiten CSMA/CD unmöglich machten, kehrte man wieder zu einer Stern-Topologie zurück
- Es wurde üblich, von jeder Station ein eigenes Kabel zu einem zentralen Switch zu ziehen, sodass Wände, Decken und Böden mit großen und teuren Bündeln aus Ethernet-Kabeln gefüllt wurden
- Selbst WLAN, das wie das ultimative gemeinsam genutzte Funkmedium und damit wie ein Bus erscheint, wird in der Praxis fast immer im infrastructure mode betrieben und ahmt damit eine große Stern-Topologie nach
- Selbst zwei WLAN-Stationen am selben Access Point kommunizieren nicht direkt; sie senden Pakete mit der MAC-Adresse des Gegenübers an den Access Point, und dieser strahlt sie erneut aus
- Wenn Knoten X über IP-Router Y und WLAN-Access-Point A an Internet-Knoten Z sendet, ist Z das IP-Ziel, Y das Ethernet-Ziel und A der tatsächliche Funkpartner, sodass sich die Adressschichten kompliziert überlagern
- Dafür bietet 802.11 einen 3-address mode, der sowohl das eigentliche Ethernet-Ziel als auch das zwischengeschaltete Ethernet-Ziel enthalten kann
- Dazu kommen
to-AP- undfrom-AP-Bits, die die Richtung Station→AP bzw. AP→Station anzeigen; sind beide gleichzeitig gesetzt, lässt sich damit auch Relay-Betrieb zwischen APs ausdrücken - Wenn A ein Repeater ist und an Basisstation B weiterleiten muss, unterscheiden sich tatsächliche Sender und Empfänger in der Luft erneut von Ethernet-Quelle und -Ziel, wofür ein 4-address mode nötig wird
- 802.11s mesh hat sogar einen 6-address mode, und an diesem Punkt, so heißt es, habe man aufgegeben, das noch verstehen zu wollen
Die Welt, in der IPv6 ein gutes Design war
- Die IETF, die über IPv6 nachdachte, sah das bereits eingetretene Chaos und das noch größere kommende und stellte sich eine neue Welt ohne bestehende Altlasten vor
- Voraussetzungen dieser Welt waren die Abschaffung physischer Busnetzwerke, die Abschaffung von Layer-2-Internetworks, die Abschaffung von Broadcasts, die Abschaffung von MAC-Adressen, die Abschaffung von ARP und DHCP, ein einfacher IP-Header mit Hardware-Beschleunigung, die Beseitigung der Adressknappheit und die Abschaffung manueller IP-Konfiguration außerhalb des Kerns
- Wenn Layer 2 immer Punkt-zu-Punkt wäre, gäbe es gar kein Ziel für Broadcasts mehr, also könnte man sie durch Multicast ersetzen; und weil Sender und Empfänger ohnehin eindeutig wären, wären auch MAC-Adressen überflüssig
- Ohne MAC-Adressen wäre auch keine Zuordnung zwischen IP und MAC mehr nötig, sodass ARP und DHCP entfallen könnten; gleichzeitig wäre genug Adressraum vorhanden, um wieder große Subnetze routen zu können
- In dieser Welt, so die Vorstellung, hätten WLAN-Repeater, WLAN-Access-Points, Ethernet-Switches und sogar SDN alle als IPv6-Router gearbeitet
- Dann hätten ARP-Stürme, IGMP-snooping-Bridges und Bridging-Loops verschwinden können, und alle Routingprobleme wären mit traceroute nachvollziehbar gewesen
- Weil man pro Ethernet-Paket 12 Byte Quell- und Ziel-MAC-Adresse und pro WLAN-Paket 18 Byte Adressinformation entfernen könnte, würde IPv6 trotz seiner 24 Byte größeren Adressen gegenüber IPv4 unter dem Strich nur 12 Byte zusätzlichen Overhead verursachen, wenn man den Wegfall des Ethernet-Headers einrechnet
- Diese Erwartung, eines Tages sogar Ethernet-Adressen selbst abschaffen zu können, half laut Darstellung dabei, die Entscheidung für die übermäßig große IPv6-Adresslänge zu rechtfertigen
- Doch dieses schöne Design wurde in der realen Welt nicht verwirklicht
Requiem für den Traum
- Die Formulierung eines Kollegen, „Schichten werden nur hinzugefügt, nie entfernt“, dient als Gesamtfazit
- Die Vorteile von IPv6 hätten nur funktioniert, wenn man bestehende Altlasten hätte abwerfen und neu anfangen können, doch in der Praxis war das fast unmöglich
- Selbst wenn die IPv6-Verbreitung 99 % erreichen würde, verschwänden Ethernet-Adressen und WLAN-Adressen nicht, solange IPv4 nicht vollständig verschwindet; und solange IEEE-802.3- und 802.11-Framing-Standards beibehalten werden, lassen sich auch die eingesparten Bytes nicht realisieren
- Daher brauchte IPv6 am Ende neighbor discovery, das noch komplexer als ARP ist, und selbst wenn Busnetzwerke verschwanden, brauchte man weiterhin broadcastähnliche Simulationen für ARP-artiges Verhalten
- Zu Hause muss man weiter einen lokalen DHCP-Server betreiben, damit alte IPv4-Glühbirnen funktionieren, und damit sie das Internet erreichen, bleibt auch NAT nötig
- Noch schlimmer sei, dass das IPv6-Team das Problem von mobile IP ungelöst zurückließ, wodurch das schreckliche Layer-2-Bridging weiterhin nötig blieb
- Es wird vermutet, dass man damals zuerst IPv6 innerhalb weniger Jahre ausrollen und mobile IP später leichter lösen wollte, nachdem IPv4 und MAC-Adressen verschwunden wären
- Damals hielt man mobile Computer wohl noch kaum für einen relevanten Anwendungsfall; vorstellen konnte man sich eher nur die etwas seltsame Idee, zwischen Ethernet-Ports umzuziehen und dabei eine ftp-Verbindung fortzusetzen
Mobile IP als Killer-App
- In der späteren Geschichte wurde der Anwendungsfall alltäglich, tragbare Computer, also Telefone, zwischen mehreren drahtlosen Access Points zu bewegen
- In LTE funktioniert diese Bewegung meist, in WLAN manchmal, und das Geheimnis dahinter ist nicht Internet-Routing, sondern Layer-2-Bridging
- Internet-Routing kann Mobilität überhaupt nicht handhaben; wenn sich ein Gerät in einem IP-Netz bewegt und seine IP-Adresse wechselt, brechen alle offenen Verbindungen ab
- Unternehmens-WLAN bridgt deshalb das gesamte LAN auf Layer 2, sodass ein zentraler DHCP-Server unabhängig vom verwendeten Access Point dieselbe IP-Adresse vergeben kann; man nimmt nur einige Sekunden Verwirrung während der Neukonfiguration der Bridges in Kauf und behält die Verbindung
- Heim-WLAN mit mehreren Extendern oder Repeatern arbeitet auf dieselbe Weise
- Bewegt man sich dagegen durch verschiedene WLAN-Netze, etwa von Geschäft zu Geschäft auf der Straße, bekommt man jedes Mal eine neue IP-Adresse, und alle Verbindungen reißen ab
- LTE geht noch weiter und hält dieselbe IP-Adresse aufrecht, selbst wenn man sich viele Meilen zwischen mehreren Basisstationen bewegt; in Mobilfunknetzen werden dabei meist IPv6-Adressen verwendet
- Der Trick besteht darin, den Verkehr zu einem zentralen Punkt zu tunneln und dort zusammen mit vielen Firewalls in ein einziges riesiges virtuelles Layer-2-LAN zu bridgen; der Preis dafür ist enorme Komplexität und beschämend hohe zusätzliche Latenz
- Mobilfunkanbieter würden das gern beheben, doch es sei fast unmöglich
Wie man Mobile IP tatsächlich zum Laufen bringt 1
- Die Antwort darauf, warum mobile IP nicht richtig funktioniert, lautet schließlich, dass die berühmte Definition des 4-Tupels zur Sitzungsidentifikation falsch ist
- TCP- und UDP-Sitzungen werden durch
(source ip, source port, destination ip, destination port)identifiziert; diese Struktur greift über Layer 3 und Layer 4 hinweg und ist gegenüber Änderungen der IP-Adresse anfällig - Wäre die Sitzungsidentifikation nur durch Layer-4-Daten bestimmt, hätte mobile IP perfekt funktionieren können
- Beispiel: Wenn X:1111 mit Y:80 kommuniziert und X seine Adresse zu Q ändert, wird aus dem Paket
(Q,1111,Y,80); Y erkennt es nicht mehr als bestehende Sitzung und verwirft es, und auch Pakete von Y als(Y,80,X,1111)erreichen X nicht mehr - Als Alternative wird skizziert, Portnummern statt auf 16 Bit auf 128 oder 256 Bit als eindeutige Hash-Werte zu vergrößern und Sockets über tags zu identifizieren, die von IP-Adressen unabhängig sind
- In diesem Fall enthalten Pakete auf Layer 3 weiterhin die Adressinformation
(X,Y)für das Routing, doch der Kernel benutzt beim Empfang die Layer-3-Information nicht mehr zur Socket-Identifikation, sondern nur noch die uuid - Zielport 80 wäre dann nur noch beim Start einer neuen Sitzung nötig, um den gewünschten Dienst zu unterscheiden, und könnte danach ignoriert oder weggelassen werden
- Der Kernel von Y würde cachen, dass
(uuid)-Sitzungspakete zuletzt von X kamen; wenn X zu Q wechselt und dann mit demselben(uuid,80)-Tag wieder erscheint, könnte diese Sitzung zugeordnet und das Antwortziel von X auf Q aktualisiert werden - So bliebe die Verbindung erhalten, allerdings mit der zusätzlichen Einschränkung, dass man Übernahme durch Angreifer verhindern muss
- UDP und TCP funktionieren jedoch nicht so, und das heute zu ändern, wird als dieselbe Art von Projekt beschrieben wie der Wechsel von IPv4 zu IPv6: Es sah leicht aus, und selbst Jahrzehnte später ist nicht einmal die Hälfte geschafft
QUIC und eine mögliche Umgehung
- Positiv betrachtet wird durch einen weiteren Schichtenverstoß eine indirekte Lösung in Aussicht gestellt
- Wenn man das alte TCP verwirft und QUIC über UDP nutzt, kann man ein Modell verwenden, in dem das UDP-4-Tupel selbst nicht als Verbindungsidentifikator dient
- Wenn der UDP-Port ein spezieller Port der Mobility-Schicht ist, kann man dessen Inhalt erneut entpacken, als internes Paket mit passendem uuid-Tag interpretieren und korrekt der richtigen Sitzung und dem passenden Socket zuordnen
- Das experimentelle QUIC-Protokoll habe zumindest theoretisch bereits ein Paketformat, das zu einer solchen Struktur passe
- Da QUIC ohnehin für seine zustandslose Paketverschlüsselung und Authentifizierung einen eindeutigen Sitzungsidentifikator oder Schlüssel benötigt, könnte mit relativ wenig zusätzlicher Arbeit transparente Unterstützung für Roaming möglich sein
- Dann müsste nur noch das verbleibende UDP und TCP vollständig aus dem Internet entfernt werden, und diesmal könnte Layer-2-Bridging wirklich überflüssig werden; dann ließen sich auch Broadcasts, MAC-Adressen, SDN und DHCP abschaffen
- Der Schluss endet mit dem Satz von der Wiederherstellung der Eleganz des Internet
Nachträge und Korrekturen
-
Korrektur 2017-08-16
- Die vorangehende Idee zu mobile IP ist nicht auf IPv6 beschränkt
- Es wird klargestellt, dass sie auch in IPv4- und NAT-Umgebungen funktionieren könnte, sogar beim Roaming durch mehrere NATs hindurch
-
Korrektur 2017-08-15
- Als einfachstes Beispiel zur Verhinderung von Sitzungsübernahme wird ein SYN-ACK-SYNACK-ähnlicher Austausch beim Start von TCP genannt
- Würde Y dem ersten Paket des neuen Hosts Q sofort vertrauen, könnte ein Angreifer irgendwo im Internet leicht die Verbindung X→Y kapern
- Wenn Y ein Cookie sendet und Q es empfangen, verarbeiten und an Y zurücksenden muss, wäre für einen Angriff zumindest ein Man-in-the-Middle und nicht bloß ein einfacher externer Angreifer nötig
- Bei verschlüsselten Protokollen wie QUIC könnte auch dieser Handshake durch den Sitzungsschlüssel geschützt werden
-
Korrektur 2017-10-24
- Neben QUIC gebe es weitere Kandidaten für TCP-Ersatzprotokolle mit solcher Roaming-Unterstützung; als Beispiel wird MinimaLT genannt
- MinimaLT wird als das erste Protokoll erwähnt, von dem man gehört habe, das das Roaming-Problem elegant löst, und es wird angedeutet, dass künftige Lösungen diese Struktur nachahmen könnten
-
Korrektur 2020-07-09
- Es wird lediglich erwähnt, dass zusätzliche Gedanken zu IPv4/IPv6-Migration und Interoperabilität in einem anderen Beitrag veröffentlicht wurden; weitere Erläuterungen im Text gibt es nicht
1 Kommentare
Hacker-News-Kommentare
Aus meiner Sicht ist IPv6 vielleicht nicht der Gipfel perfekten Protokolldesigns, aber die Alternativen, die Leute als besser vorschlagen, konvergieren am Ende doch auf etwas, das IPv6 sehr ähnlich ist. Wenn es dauerhaft niemand schafft, etwas Besseres zu bauen, heißt das für mich letztlich, dass IPv6 ein ziemlich gutes Design ist
Wenn man frühere Hacker-News-Diskussionen sammelt, sieht man, dass dieses Thema im Abstand von ein paar Jahren immer wieder auftaucht, etwa im Thread von 2017, Thread von 2019, Thread von 2020 und Thread von 2023
Mir gefällt nicht, dass dieser Artikel ARP so negativ darstellt. Dank ARP ist IP-Networking innerhalb eines LAN auch ohne Router möglich, und das Standard-Gateway lässt sich als Spezialfall derselben allgemeinen LAN-IP-Kommunikation behandeln. Die Darstellung der Netzwerkgeschichte selbst ist allerdings wirklich hervorragend, und ich bin beim IPv6-Teil noch mitten im Lesen
Ich bin etwas unsicher, was dieser Artikel genau sagen will. Geht es darum, dass meine Netzwerkgeräte sich auf Basis ihrer MAC-Adresse selbst eine IPv6-Adresse geben, und dass das der Kern von stateless IPv6 ist? Soweit ich weiß, wurde IPv6 auch eingeführt, um die Erschöpfung von IPv4 und die Probleme von NAT zu lösen. Aber meine Xbox sagt, das Netzwerk sei nicht besonders gut, wenn es kein IPv6 gibt, und auch das wirkt auf mich ziemlich nordamerika-zentriert
Ich habe zunehmend das Gefühl, dass es ein großer Fehler war, bei IPv6 sowohl SLAAC als auch DHCPv6 beizubehalten. SLAAC selbst ist großartig, aber zwei Konfigurationsmechanismen sind einfach zu verwirrend. Dass Android DHCPv6 nicht unterstützt, macht es noch chaotischer. Ich vermute, SLAAC ist ein Produkt aus einer Zeit, in der Computer teuer waren und DHCP-Server auf separater Hardware liefen. Heute sind Computer billig, und die meisten Router können DHCP selbst betreiben, also ist die Lage anders. Wenn DHCPv6 standardmäßig in Richtung MAC-basierter Adressvergabe gegangen wäre, wäre die Konfiguration vermutlich einfacher geworden, und die automatische Konfiguration auf Link-Local-Ebene wäre wohl trotzdem erhalten geblieben
Ich fand diesen Artikel sehr interessant, aber einen Punkt verstehe ich nicht gut. Der Autor sagt, dass selbst WiFi inzwischen kein CSMA/CD mehr verwendet. Wie funktioniert es dann tatsächlich? Der Autor erklärt, dass selbst zwei WiFi-Stationen am selben Access Point nicht direkt miteinander kommunizieren. Dann muss doch irgendwann jede Station unterscheiden können, ob ein Signal für sie selbst bestimmt ist, von einer anderen Station an den AP geht oder vom AP an eine andere Station gesendet wird. Müsste man dafür nicht weiterhin einen ähnlichen Mechanismus brauchen, auch wenn er nur anders heißt?
Früher wirkte IPv6 wie der unausweichliche nächste Schritt, aber wenn es heute so kraftlos wirkt, frage ich mich, ob das Problem, das es lösen sollte, von Anfang an vielleicht gar nicht so wichtig war. Aus Sicht realer Nutzer schien man am Ende irgendwie doch genug IPv4-Adressen zu beschaffen, sodass das Internet einfach weiterlief, und deshalb frage ich mich selbst, ob IPv6 wirklich notwendig war. Ich würde gern wissen, ob diese Schlussfolgerung falsch ist