Ist in einem Netzwerk die MAC-Adresse nicht überflüssig?

Moin,

im OSI-Modell bauen die verschiedenen Schichten auf einander auf - angefangen davon, wie elektrische oder optische Signale zu interpretieren sind, über die Hardware-Adressierung, wann die Netzwerkkarte anhand eine Signalabfolge erkennen kann, dass sie gemeint ist, weiter über die logische Adressierung im Betriebssystem, Ports, Dienste, Anwendung. Daher muss jegliche Kommunikation diese Schichten durchlaufen: beim Sender absteigend 7-6-5-4-3-2-1 und beim Empfänger aufsteigend 1-2-3-4-5-6-7. Die Antwort erfolgt dann in umgekehrter Reihenfolge. Es wirkt dabei so, also ob Schicht 1 des Senders mit Schicht 1 des Empfängers, 2 mit 2, 3 mit 3, etc. kommuniziert.

In Netzwerkkarten ist nun mal keine IP-Adresse (OSI Layer 3), sondern eine MAC-Adresse (OSI Layer 2) eingebrannt; und wie der Name Media Access Controll sagt, kümmert sich diese Teil nur um den geregelten Zugang zum Netzwerk.
Je mehr Geräte nun am selben Netzwerk angeschlossen sind, desto mehr Geschnatter ist auf der Leitung. Das führt ab einer gewissen Anzahl dazu, das eine vernünftige Kommunikation zwischen zwei Geräten schwierig bis gar nicht mehr möglich ist. Kennst du selbst, je mehr Leute in einem Raum (der Broadcast Domain) sind, desto schwieriger wird es ein Gespräch zu führen. Daher werden mehrere, kleinere Gruppen (Broadcast Domains) gebildet, die ihren eigenen IP-Adresskreis zugeordnet werden. Soll zwischen den Gruppen Informationen ausgetauscht werden, findet Routing statt.

Noch mal zurück zur MAC - wie möchtest du Techniken wie DHCP (Dynamic Host Configuration Protocol) oder WoL (Wake on LAN) realisieren, wenn die Netzwerkkarte keine IP kennt?

Und man sollte die historische Entwicklung nicht vergessen - am Anfang standen die Computer für sich allein herum, später wurde lokal vernetzt und noch später zwischen Firmen/Einrichtungen/Universitäten. Zuletzt zwischen Kontinenten, das Internet, wie wir es heute kennen.

Grüße
TA

Naja - sagen wir so: Ja, du müsstest halt den kompletten Netzwerkteil von grund auf neu programmieren -> denkbar ist da ja immer alles. ABER dann würdest du auch kein "IP" mehr haben...

Dein Switch zB. hat idR. eben eine MAC-Table die sagt welche MAC auf welchem Port zu finden ist -> weil du ja eben in deinem Netzwerk auch L2 Geräte haben kannst.. Da wäre es ja jetzt irgendwie sinnfrei wenn man in der gesamten Welt vorgeben würden das nur noch L3 vorhanden sein darf...

Kein Hallo (siehe Diskussionsrichtlinien - Netiquette)

laut Deinem Profil ist Dein Schwerpunkt Netzwerke!
Dann stellst Du so eine Frage?

Information aus dem Elektronikkompendium

auch KEIN Gruß

Moin,

Ganz einfach. MAC Adressen dienen dazu, wieder Name es schon sagt, Knoten im ubertragunsmedium zu adressieren. Bei Medien, die nur Punkt zu Punkt verbunden sind, benötigt man keine MAC-Adressen. Da fehlen sie sogar ganz. Bei Medien wie Ethernet oder Token Ting, wo mehrere Stationen "gleichzeitig" lauschen, muß man dazusagen, welcher Empfänger gemeint ist. Das ist völlig unabhängig davon, welche höheren Protokolle man verwendet.

lks

Moin,

historisch gesehen sind es eben die Mac-Adressen, die eineindeutig sind (auch wenn man da heute eingreifen kann).

Diese These dagegen ist falsch. Kennt jeder aus leidvoller Erfahrung, der mal das entsprechende Fehlerbild debuggen musste. Es ist nur so, dass jedes Endgerät in einem Netzwerk eine eindeutige IP-Adresse haben sollte, aber das hängt von einer sauberen Konfiguration ab.

Gruß

DivideByZero

zumal "jeder computer in einem netzwerk"... also ich hab grade 192.168.10.irgendwas (bitte jetzt nicht hacken ;) )... ich bin mir aber sicher ich bin teil eines netzwerkes - nämlich dem Internet... aber ich glaube irgendwie das es noch min. 1 anderen computer mit dieser IP gibt... ggf. auch 2 oder 3.... die irgendwo auf der welt rumstehen...

Nun, jeder Computer hat ja auch einen eindeutigen Namen (zumindest sollte er eindeutig sein) - da könnte man glatt auf die Idee kommen, dass auch keine IP benötigt wird.

Aber wie so oft in der Informatik baut ein Protokoll auf das andere auf.
DNS: Name -> IP
ARP: IP -> MAC

Wenn der TO mit Wireshark mal guckt, wie seine Clients IP-Pakete an das Gateway adressieren, wird ihm wohl auffallen, dass das Gateway nur deshalb weiß, dass es sich für den Traffic zuständig fühlen soll, weil dessen MAC-Adresse als Ziel drinsteht. Nirgendwo in den Paketen steht die Gateway-IP.
Nur anhand der Ziel-MAC-Adresse weiß sein Router, dass *er* die Pakete routen soll, nicht ein eventuell anderer Router der im Netzwerk vorhanden sein könnte.

Das allerdings ist nicht realistisch.

Eher theoretisch? Dann lautet die Antwort klar nein, da die Protokolle das nicht hergeben. Rein theoretisch am Reissbrett? Wäre denkbar.

Wenn Du das ganze also ausschließlich theoretisch hinterfragst: sicher, das könnte auch anders gelöst werden. Aber Umsetzungswahrscheinlichkeit in die Praxis: m.E. 0%. Umstellung IPv4 auf IPv6 oder fehlende Fortentwicklung der E-Mail-Protokolle (Verschlüsselung, Signierung, Prioritätszustellung ...) zeigen, dass es bei einmal eingeschlagenen, funktionsfähigen Pfaden weltweit angewandter Technik quasi unmöglich ist, das durch ein alternatives System zu ersetzen. Fortentwicklungen (OAuth bei Mail bpsw.) setzen sich ggf. langsam durch, wenn große Player das machen, aber hier würden wir über ein 100% geändertes System reden. Daher: das kann nur eine rein theoretische Betrachtung bleiben.

Nein, da es ja zB. im WLAN sein kann das du von einem AP auf nen anderen wechselst. Dann hast du trotzdem ja noch dieselbe IP. Oder du steckst einfach mal dein Kabel um... Wäre dann also blöd wenn das nur nach dem ersten aushandeln über die IP läuft.

Edit: ausserdem kannst du natürlich im netz auch duplicated IPs haben -> wenn die zB. in 2 VLANs sind stört das niemanden... der Switch würde aber ja dann nen problem haben...

Wie gesagt: Schaue die Pakete mit Wireshark an und versuche nur anhand der IP-Adressen herauszufinden, an welches Gateway sie adressiert wurden. Stelle dir einfach dabei mal vor, du hättest mehrere Gateways in deinem Netzwerk und bestimmte IP-Adressen müssten an ein anderes Gateway geroutet werden.
Und dann suche die Gateway-IP in den Paketen – die steht da nämlich nicht drin
Dein Gateway weiß nur dass es ein Paket routen soll, weil es per MAC-Adresse als Empfänger adressiert ist, die im IP-Layer genannte Ziel-IP aber nicht auf dem Gateway selbst irgendwo gebunden ist – dann routet es.

Es gibt Netzwerke, die ohne MAC-Adressen auskommen. Im einfachsten Fall ist es SLIP über ein serielles Kabel. Oder PPP-Verbindungen auf höheren Schichten, bei denen du auch keine MAC-Adressen benutzt.
Das sind aber alles nur Punkt-zu-Punkt-Verbindungen, bei denen es sowieso nur genau zwei Teilnehmer gibt (PtP), da ist prinzipbedingt klar, dass man bei einem empfangenen Paket als Empfänger gemeint ist.
Bei Punkt-zu-Multipunkt-Verbindungen (PtmP) weißt du das eben nicht.
Bei MPLS hast du ebenfalls keine MAC, aber Flow-Labels, die im weitesten Sinne diese Funktion übernehmen.
Bluetooth widerum hat MAC-Adressen um die Geräte zu adressieren, da du damit ja mehrere vollkommen verschiedene Geräte zu einem Netzwerk verbinden kannst. Bonus: Du kannst auch IPv4 und IPv6 darüber transportieren. Oder reine Audio-Frames zu einem Lautsprecher. Bei letzterem muss der Lautsprecher dann keine IP-Adresse haben, die nicht zufällig mit dem Netzwerk, in dem sich dein Telefon von dem gestreamed wird, befindet. Wäre ja blöd, wenn dein Telefon in 10.0.0.0/8 ist und dein Lautsprecher auch

Und, das darf man nicht vergessen: Es gibt auch andere Protokolle neben IPv4 und IPv6.
ARP ist so eines, das hat keine IP-Header. Das existiert nur in Ethernet-Netzwerken und nutzt ausschließlich die MAC-Adressen zur Lenkung.
Aber dann gibt oder gab es Protokolle wie IPX/SPX oder AppleTalk, die in Ethernet- und TokenRing-Netzwerken eingesetzt wurden und keine IP-Adressen hatten sondern ein eigenes Adressierungsschema.
Diese Protokolle wurden irgendwann durch IP(v4) obsolet, die gute Nachricht ist aber, dass man keine neue Netzwerkhardware kaufen musste. Denn IP hockt ja in Layer3, das ist aus Sicht des Switches nur uninteressanter Payload.
Und dann kam irgendwann IPv6, das hat auch einfach in bestehenden Umgebungen funktioniert, weil es ja ebenfalls nur auf Layer3 arbeitet. Selbst ein 30 Jahre alter Switch oder Hub oder Token-Ring MAU kann IPv6 transportieren.
Im Falle von Token-Ring hast du dann allerdings keine MAC-Adressen, das ist ja schließlich so designed, dass das Paket einmal durch alle Rechner durchfließt, eine Adressierung auf den unteren Schichten ist daher sinnlos.

Worauf will ich hinaus? Stell dir vor, du hättest ein Rechenzentrum mit vielen "L3-Switches" und ein paar dicken Core-Routern und es wäre tatsächlich so, dass man nicht über die MAC-Adresse sondern nur über IP-Adressen adressiert.
Jetzt kommt plötzlich IPv6 und du musst alle diese Switches und deine Core-Router austauschen, weil die das nicht unterstützen. Jede Netzwerkhardware, die das Protokoll nicht kennt, kann es natürlich auch nicht transportieren und du hättest ohne den Austausch keine Erreichbarkeiten von IPv6.
Du kannst mal nachgucken gehen, was Rechenzentrums-Technik so kostet. Ein einfacher "L3-Switch" mit 48x 1G Ports von Juniper oder Cisco liegt preislich nicht unter 8.000 €.
Router kosten leicht 20k € oder mehr.
Das würde also bommelig 100k € oder mehr kosten, bevor wir eine einzige IPv6-Adresse mal anpingen konnten.

Jetzt nehmen wir das reale Leben, wo wir die MAC-Adressen haben:
IPv6 kommt, wir wollen das auf ein paar Systemen testweise aktivieren.
Wir kaufen einen neuen Router, der IPv6 kann. Der Rest kann erstmal so bleiben, weil dem Switch ja vollkommen egal ist, was er transportiert, solange vernünftige MAC-Adressen drin stehen.
Wir haben also eine Start-Investition von den 20k € und können IPv6 ausrollen.


Und deshalb, genau deshalb, ist es sinnvoll, die Adressierung immer auch zur Aufgabe der jeweiligen Transport-Layer zu machen, ohne dass sie ineinander übergreifen.

Danke für die super Erklärung!

Prinzipiell ist das schon möglich, aber dann kann de switch nicht mehr entscheiden an welchen Anschluß das Paket weitergeleitet werden muß und alle Stationen bekommen die Pakete und jede muß dann schauen, ob das Paket fur sie ist, d.,h man arbeitet dann nur noch mit Broadcasts, was die Netzwerkperformance deutlich senkt.

lks

Und was machst du, wenn das Ziel nicht im lokalen Netz sondern im Internet liegt? Die IP ist an keinem Port des Switch angeschlossen, also kann er nach deiner Logik auch nicht wissen, wohin mit dem Paket.

Außerdem wissen L3 Switche auch nicht zwangsweise, welche IP an welchem Port hängt, da braucht es auch wieder Protokolle für.

Und, wie @LordGurke schon sagte: Was machst du, wenn deine Clients kein IP sprechen?

Gruß,
Avoton

Woher weiß der sendende Computer, dass er an einem L3-Switch angeschlossen ist? Und nicht etwa einem „normalen“ Switch oder gar einem Hub, der überhaupt keine MAC-, geschweige denn eine IP-Tabelle hat? Zwei Computer könnten auch mit einem Crossover-Kabel miteinander verbunden sein… Der Computer kann nicht wissen, was ihn im Netz erwartet. MAC ist nun mal der kleinste gemeinsame Nenner um Daten ins lokale Netzwerk zu schicken. Dabei ist das IP-Packet der Payload des MAC-Frames. Klar kannst du sagen, du willst das anders machen, aber wenn du die Abwärtskompatibilität nicht beachtest, muss du komplett neu machen. Der Transrapid ist der Eisenbahn auch in vielen Dingen überlegen, aber er passt nun mal nicht auf das gewachsene Schienennetz.


Die MAC ist für die lokale Zuordnung notwendig, während die IP auch andere Netze adressiert. Bei deiner E-Mail steht am Anfang nur eine E-Mail-Adresse, z. B. Guy@far-away.com

• Computer: bin ich selbst Far-away.com? Nee, mal DNS fragen… („nslookup far-away.com“)
• DNS: far-away.com hat die IP 123.123.123.123
• Computer: ist das bei mir im Netz oder woanders? Meine IP ist 234.234.234.234, Netzwerkmaske 255.255.255.0. Das passt nicht, also Route nachschlagen („route print“). Ok, wie so oft alles ans Standard-Gateway.

Würdest du jetzt wie von dir angedacht direkt an die IP adressieren, stehst du vor dem Problem, welche der beiden IPs - die Ziel-IP für die E-Mail oder die des Gateways - verwendet werden soll. Im ersten Fall fühlt sich das Gateway nicht angesprochen, im zweiten weiß das Gateway nicht wohin damit.

• Wo ist nochmal die verdammte MAC des Gateways? Ich nehm ARP und rufe es einfach mal laut ins Netz, derjenige wird schon antworten: „Who has 234.234.234.1? Tell 234.234.234.234.“ Als Antwort kommt dann die MAC zur IP zurück (auflisten mit „arp -a“)
• So, Daten an die MAC-Adresse des Gateways schicken und als Payload/Nutzlast nehme ich die IP des Ziels 123.123.123.123 und die Daten. Soll sich das Gateway damit rumschlagen.

Wäre die Mail im gleichen Netz zu verschicken, passiert das gleiche: „who has 234.234.234.100? Tell 234.234.234.234.“ Danach kann er an die MAC des Zielsystems weiterleiten. Der Rechner merkt sich nicht alle IPs, die er jemals gesehen hat, sondern verwirft die MAC-IP-Zuordnung (ARP-Table) nach zwei Sekunden standardmäßig. Das spart Ressourcen - und je länger die eigene zu pflegende Liste werden würde, desto ineffizienter würde sie.

Für deine theoretischen Überlegungen müsstest du erstmal alle davon überzeugen das IP-Protokoll nicht nur für die Fallunterscheidung intern/extern zu erweitern (dann müsste ein IP-Packet in ein IP-Packet, damit Gateway und Ziel adressiert werden können?), sondern diese Erweiterung von den Herstellern für alle Geräte - vor allem für alle Netzwerkkarten, denn die haben keine IP!) umsetzen lassen. Und das für eine Funktion, die auf Layer 2 mit MAC schon gegeben ist (schicke Frame an Gateway-MAC oder netzwerkinterner Computer-MAC, Ziel-IP ist im Payload).

Umgekehrt wäre es doch geschickter für die Kommunikation in internen Netzwerken auf die IP zu verzichten. Es müssten „nur“ die Anwendungen umgeschrieben werden die MAC statt der IP zu verwenden, ein DNS-artiger Dienst müsste Name zu MAC auflösen. Ob das einfacher wäre?

Die bestehende Lösung kann sowohl externe und interne Ziele behandeln, ist also universeller als die von dir angedachte, künstliche Unterscheidung bzgl. interner Kommunikation.

Schönes Wochenende
TA

Moin,

Man könnte es auch ganz einfach so ausdrücken:

Ethernet arbeitet mit MAC-Adressen und weiß nichts über drüberliegende Schichten. Alle Protokolle, die Ethernet nutzen wollen, müssen sich an die Ethernet-Standards halten. Wenn das drüberluegende Protokoll das nicht will, muß man halt ein anderes LAN-Protokoll verwenden.

lks

Und hier ist schon ein wesentlicher Denkfehler: Du gehst davon aus, dass es nur "das Gateway" im Singular pro Netzwerk geben kann.
Ich empfehle dir dringend, dir mal anzusehen wie so ein Internet Exchange wie der DE-CIX funktioniert — der ist nämlich erstmal nur ein großer Switch. Da hängen alle angeschlossenen Teilnehmer in einem Peering-LAN (selbes Präfix). Das ist ein LAN mit hunderten Routern.
Über die BGP-Sessions mit den Route-Servern bekommst du die Routinginformationen welche Präfixe über welchen Router erreicht werden können.
Und du hast zu einigen Routen mehrere infrage kommende Router, an die du das schicken kannst — wegen redundanter Anbindungen oder wegen Anycast.
Aber der wesentlichste Punkt ist: Der DE-CIX routet nicht. Es sind die daran angeschlossenen Router, die Pakete an andere angeschlossene Router schicken, aber dazwischen ist nur ein Switch, der auf L2 arbeitet. Denn sonst könnte es dort auch kein selektives Peering geben, wo Provider A seine Routen nur bestimmten anderen Providern schicken will.
Es ist also wesentliches Konzept, dass dort der Switch eben nichts mit IP anfangen kann.

Bilde das mal mit deinem Konzept ab, das explodiert dir noch in der Hand

Oh, eine Sache noch: Eine vollständige Tabelle aller IPv4- und IPv6-Routen ohne Redundanzen belegt ungefähr 2,4 GB RAM und besteht aus ca. 1,4M Routen.
Während die MAC-Table am DE-CIX nur rund 800 Einträge hat.

For your convenience
Im Ernst, es ist tatsächlich eigentlich nicht notwendig. Aber weil es unhandlicher und unflexibler ist, die MAC-Adresse anzugeben, behilft man sich mit der IP. Denn eine IP kann ich notfalls irgendwann auf einen anderen Router transferieren, wenn ich ihn austausche, ohne dabei dann bei allen Geräten die Gateway-MAC zu ändern.

Letztlich braucht man die IP nur, um darüber die MAC-Adresse des Gateways zu finden.
Wenn du dir IPv6-RA-Pakete in Wireshark anschaust, wirst du sehen, dass dort die MAC-Adresse des aussendenden Routers als "LLADDR" direkt mitübermittelt wird, damit die Clients diese nicht noch per Neighbor-Discovery auflösen müssen.

Man könnte auch einfach sagen: Du brauchst ne MAC Adresse, die IP brauchst du nicht. Denn IP ist auf dem höherem Level - da hast du aber ja schon ne gewisse Wahlfreiheit. IP (genauer IPv4) hat sich halt aktuell durchgesetzt durch das Internet, es gab aber zB. in der Novell-Welt auch mal IPX/SPX, das hatte mit deinen IP-Adressen von heute eben nicht viel zu tun... Es gibt nebenbei auch noch IPv6 - auch da hast du natürlich eine völlig andere Adressierungsform als bei IPv4. Und da gibts halt schon noch nen paar Optionen, aber das ist alles im "Layer 3" vom OSI. Die MAC ist auf dem Layer2. Grundregel ist halt das die "unteren" Schichten sich nicht dafür interessieren was darüber passiert, die oberen davon ausgehen das die unteren einfach funktionieren. Würdest du jetzt also nen kompletten Netzwerk-Stack neu schreiben und die MAC rauslassen müsstest du alles was darüber liegt ebenfalls neu aufbauen und - sofern du es nicht schaffst das weltweit in ne Norm zu bekommen und als Industrie-Standard durchzusetzen - damit leben das du eben nur in deinem Netzwerk was damit tun könntest. Jedes andere Gerät wie zB. nen Router würde das als "Datenmüll" sehen und verwerfen.

Du kannst deine Frage aber auch auf eine höhere Ebene im OSI bringen - und da würdest du dann sehen das eben "eigene" Implementierungen durchaus nix ungewöhnliches werden. So gehst du ja dann bei nem VPN (oder div. Verschlüsselten Verbindungen) auch bei und baust dir prinzipiell ne art eigenes Protokoll. Da WILLST du ja sogar das es für andere nur Datenmüll ist. Diesen "Müll" verpackst du dann halt nur für die unteren Schichten in standard-pakete (z.B. nen TCP paket, das packst du dann in IP, dann klebst du ne MAC dran und deine Netzwerkkarte wandelt das in nen bisserl Strom / Licht / whatever um). Nur durch dieses "umwandeln" kannst du dann nämlich aus deinem Netzwerk via VPN nen ganz normalen PING oder irgendwelche Daten via (TCP/UDP)-IP verschlüsselt in nen anderes Office zB. schicken. Hätte sich der Programmierer der $VPN-Software gedacht "hey, ich bin lustig, ich ändere das Protokoll und mache IPs mit Hex-Buchstaben wie ABC.DEF.123.123" könnte er/sie das tun, nur würden dann deine Standard-Programme eben nicht mehr unbedingt funktionieren. Solang er/sie aber nach "aussen" das ganze wieder in standard-IP verpacken würde wäre erstmal alles gut.. Es wäre zwar ggf. nutzlos aber funktional ;)

Moin,

Ich habe langsam das Gefühl, das Du versuchst uns Deine Hausaufgaben machen zu lassen.

lks