Kann ich ein Ethernet-Netzwerk ohne Verwendung von IP erstellen?

Wie ich anhand des ISO-OSI-Modells verstehe, arbeiten MAC-Adressen auf einer anderen Ebene als IP-Adressen. Das ist mir klar.

Ich kann akzeptieren, dass Ethernet (LAN) keine IP-Adressen für die Kommunikation verwendet, sondern MAC-Adressen. Ich verstehe, dass diese MAC-Adressen nicht für das Routing außerhalb eines LAN verwendet werden können, da sie nicht hierarchisch definiert sind. Ich verstehe auch, dass IP der beste Weg ist, um über das große Internet zu routen. Was mich nicht ganz überzeugt hat, ist, dass MAC-Adressen die beste Möglichkeit sind, in einem LAN zu kommunizieren

Meine Fragen sind folgende:

1. Konnte Ethernet keine IP-Adressen zum Senden von Nachrichten verwenden? Ich sage es nicht sollte, ich frage nur, ob es sich dafür hätte entscheiden können.
2. Kann ich ein Ethernet-Netzwerk erstellen, in dem Geräte keine IP-Adresse, sondern nur eine MAC-Adresse haben, da Ethernet MAC-Adressen für die Kommunikation verwendet?

Könnte Ethernet IP-Adressen anstelle seiner eigenen Datenverbindungsschichtadressen verwendet haben? Mit Sicherheit nicht, wenn es nicht wissen wollte, welches Layer-3-Protokoll es verwendet.

Wir entwerfen Netzwerkprotokolle in Schichten, damit wir Schichten mischen und anpassen können.

Ethernet wurde ursprünglich von Bob Metcalfe et al. Bei Xerox PARC als netzwerkunabhängig entwickelt, da das Ziel nicht nur der TCP / IP-Zugriff, sondern auch der Xerox-eigene proprietäre XNS-Netzwerkprotokollstack / die XNS-Netzwerkprotokollsuite war.

DEC (Digital Equipment Corporation) wurde ein weiterer früher Anwender, der es hauptsächlich für seine DECnet-Protokollstapel / -suite verwendete.

In den späten 80ern und frühen 90ern gab es viele konkurrierende LAN-Protokollsuiten (alle völlig unabhängig von TCP / IP), die in Unternehmens-Ethernet-LANs ausgeführt wurden. Neben XNS und DECnet gab es Apple AppleTalk (EtherTalk), IPX von Novell, Banyan VINES, NetBEUI, DLC / LLC, IBM SNA, OSI / ISO und andere, die ich vergessen habe.

Ja, Sie können Ethernet ohne IP verwenden. Viele Firmennetzwerke haben es in den 80ern und 90ern getan.

Da es für Ethernet unerheblich war, welches Layer-3-Protokoll (Network Layer) darauf ausgeführt wurde, war es für diese Unternehmens-LANs relativ einfach, Mixe von Geräten verschiedener Anbieter zu unterstützen, und für diese LANs war es relativ einfach, IPv4 hinzuzufügen Unterstützung, als das Internet Mitte bis Ende der 90er Jahre in Gang kam, und es war für uns relativ einfach, jetzt IPv6-Unterstützung hinzuzufügen.

Kann ich ein Ethernet-Netzwerk erstellen, in dem Geräte keine IP-Adresse, sondern nur eine MAC-Adresse haben, da Ethernet MAC-Adressen für die Kommunikation verwendet?

Wenn Sie Ihre gesamte Software von Grund auf neu schreiben würden, könnten Sie dies auf jeden Fall tun. Lassen Sie die Software einfach überall dort eine MAC-Adresse akzeptieren, wo das normale Gegenstück zu diesem Programm eine IP-Adresse akzeptiert hätte. Verwenden Sie alle Systemaufrufe, um unformatierte Ethernet-Pakete anstelle der IP-Adresse zu senden, und es wird funktionieren - aber es wäre ein großer Aufwand.

Im Allgemeinen folgen MAC-Adressen in Ihrem Netzwerk keinem Muster. Sie werden vom Hersteller in die Hardware eingebrannt. Sie sind lang und sperrig. Meins ist jetzt C8-60-00-CA-4B-9A. Der Computer neben mir ist 00-40-F4-48-1B-88.

Damit die Computer miteinander kommunizieren können, können Sie jedem Computer eine fest codierte Liste aller MAC-Adressen aller anderen Computer im Netzwerk geben, damit er weiß, wohin Pakete gesendet werden sollen. Dies ist eine Menge fehleranfälliger Eingaben, und jedes Mal, wenn Sie Ihre Netzwerkhardware geändert haben, müssen Sie alle Listen ändern, um die neuen MAC-Adressen wiederzugeben.

Dies ist ein riesiger Aufwand, sodass Sie wahrscheinlich eine Möglichkeit finden werden, mit der die Computer im Netzwerk die MAC-Adressen der anderen Computer mithilfe von Broadcast-Paketen automatisch ermitteln können. Dann geben Sie ihnen die Möglichkeit, sich mit einer aussagekräftigen Adresse zu identifizieren, sodass Sie Befehle wie "telnet C8-60-00-CA-4B-9A" eingeben müssen.

Es stellt sich heraus, dass dies genau das ist, was IP tut - es ist eine Möglichkeit, sinnvolle Zahlen zu verwenden, um Hosts in einem Netzwerk zu adressieren, anstatt MAC-Adressen fest zu codieren. Fügen Sie DNS zusätzlich zu IP hinzu und geben Sie einen Befehl wie "telnet webserver" ein.

Konnte Ethernet keine IP-Adressen zum Senden von Nachrichten verwenden? Ich sage es nicht sollte, ich frage nur, ob es sich dafür hätte entscheiden können.

MAC-Adressen bestehen aus 6 Bytes an Informationen und IP-Adressen bestehen nur aus 4 Bytes. Sie können also keine 1-zu-1-Zuordnung vornehmen. Sie benötigen eine Möglichkeit, die MAC-Adresse (um das Paket einzugeben) anhand einer IP-Adresse zu ermitteln (die von der Software bereitgestellt wird, die mit einem anderen Host im Netzwerk kommunizieren möchte).

Ein (fester) Weg, dies zu tun, wäre, in jeden Rechner im Netzwerk zu gehen und dessen Hardware-MAC-Adresse so zu ändern, dass sie wie eine IP-Adresse aussieht, indem die oberen beiden Bytes Nullen sind (oder eine andere feste Zahl, die gleich ist für jeden Rechner im Netzwerk) und setzen Sie die unteren vier Bytes auf die "IP-Adresse", die sie im Netzwerk haben sollen. (Bei den meisten Netzwerkkarten können Sie die vom Hersteller zugewiesene MAC-Adresse ändern.)

Damit dies tatsächlich funktioniert, müssten Sie als Nächstes auch den Code in Ihrem Netzwerkstapel hacken, um dieses System tatsächlich zu verwenden. Sie würden im Grunde alles herausreißen, was mit ARP zu tun hat (die Methode, mit der IP-Adressen in MAC-Adressen übersetzt werden). Sie würden die Teile herausreißen, die IP-Header erstellen / lesen. Stattdessen ersetzen Sie alles durch den sehr einfachen Code, der bei einem an den Host zu sendenden IP-Paket unter der Adresse wxyz einen Ethernet-Frame mit der auf 00-00-wxyz festgelegten DEST-Adresse erstellt.

Sie müssen dem Empfänger eines Pakets auch anzeigen, für welches Protokoll (UDP, TCP) es bestimmt ist. Sie könnten dies wahrscheinlich irgendwo im Ethernet-Header vermerken, indem Sie ein vorhandenes Feld überschreiben. Verwenden Sie möglicherweise eines der beiden obersten Bytes der Quelladresse? Dies würde die Empfangsfähigkeit des Zielcomputers nicht beeinträchtigen, könnte jedoch einige Switches durcheinander bringen. Sie können das Protokoll auch an den Anfang oder das Ende des Ethernet-Frames setzen und die Nutzlast um eins erhöhen - aber das fängt an, nach einem IP-Header zu riechen.

Also, was würde dir diese ganze Arbeit kaufen?

Erstens würde es Ihnen den Overhead einer Suche in der ARP-Tabelle für jedes ausgehende Paket ersparen. Dies liegt wahrscheinlich in der Größenordnung von nur Mikrosekunden.

Sie sparen die Arbeit bei der Berechnung der IP-Header-Prüfsummen und den Speicher, der für deren Speicherung erforderlich ist. Dies ist bei moderner Hardware wahrscheinlich nicht von Bedeutung.

Sie sparen 16 Bytes in jedem Paket im Netzwerk, da es keine IP-Header geben würde. Dies kann sich je nach Anwendung summieren.

Der größte Vorteil wäre, dass Sie keine ARP-Anforderungen ausführen müssten. Das Senden eines Standard-IP-Pakets an einen neuen Host löst einen ARP-Austausch aus, der Millisekunden dauern kann und unvorhersehbar ist. Dies kann für einige Anwendungen, die sehr empfindlich auf Latenz und Jitter reagieren, ein enormer Gewinn sein.

Für einige sehr spezielle Anwendungen ist dies tatsächlich sinnvoll. Ich habe einmal mit einem Echtzeitsystem gearbeitet, bei dem nur UDP-Pakete für die gesamte Kommunikation zwischen Hosts gesendet wurden, und zwar aus dem einzigen Grund, dass diese ARP-Sequenzen nicht aktiviert wurden und unvorhersehbar Verzögerungen und Jitter verursachen. Ich habe auch einmal an einem ressourcenbeschränkten Embedded-System gearbeitet, bei dem UDP-Payloads direkt in IP-Paketen gesendet wurden (kein IP-Header), da die gesamte Komplexität und der Arbeitsspeicher eingespart wurden, die für die Implementierung des gesamten ARP- und Netzmasken- sowie zusätzlicher Prüfsummen erforderlich sind.

Konnte Ethernet keine IP-Adressen zum Senden von Nachrichten verwenden? Ich sage es nicht sollte, ich frage nur, ob es sich dafür hätte entscheiden können

Ich denke, Ethernet hätte Vier-Byte-Adressen wie IPv4 anstelle von Sechs-Byte-Adressen verwenden können. Es ist wahrscheinlich gut, dass sie es nicht getan haben, da ihnen inzwischen die Zahlen ausgehen, wette ich.

Kann ich ein Ethernet-Netzwerk erstellen, in dem Geräte keine IP-Adresse, sondern nur eine MAC-Adresse haben, da Ethernet MAC-Adressen für die Kommunikation verwendet?

Sie können, wenn Sie Programme haben, die mit MAC-Adressen anstelle von IP-Adressen arbeiten. Natürlich bleiben Sie in diesem Netzwerk stecken und können andere nicht erreichen, ohne etwas Hackery.

Sie benötigen die IP-Schicht wirklich nur, wenn Sie planen, Routing durchzuführen, insbesondere wenn ein anderes Netzwerk möglicherweise eine andere Schicht-2-Technologie als Ethernet verwendet, wie z. B. Token Ring, was eine echte Möglichkeit war, als das meiste davon entwickelt wurde. Wer weiß, ob eine andere Layer-2-Technologie in Zukunft allgegenwärtig wird, wenn ja, ist IP davon unabhängig.

> Couldn't Ethernet make use of IP addresses to send messages? I'm not
> saying it should, I'm just asking if it could have chosen to do so.

Wenn Sie Ethernet als Netzwerkebene bezeichnen, kann dies nicht der Fall sein. Die Netzwerkschicht erfordert die physikalische Adresse des Netzwerkgeräts. Eine IP-Adresse ist eine beliebige Nummer, die der Einfachheit halber einer MAC-Adresse zugewiesen wird. IP-Adressen sind eine Softwarelösung und nicht Teil der Netzwerkkarte - der Hardwarelösung. Das ist der Grund, warum IP-Adressen leicht geändert werden können, während MAC-Adressen fest auf der Karte gespeichert und nicht geändert werden können (ungeachtet der MAC-Adress-Spoofing-Software, die die Adresse immer noch nicht so sehr ändert, wie es sich um die Adresse handelt) )

> As Ethernet uses MAC addresses for communication, could I create an
> Ethernet network where devices would not have an IP address, just a
> MAC address?

Ja, Sie könnten es, aber Sie würden es nicht genießen, da die Funktionalität sehr eingeschränkt und überhaupt nicht benutzerfreundlich wäre. Es gibt einen Grund, warum die Transportschicht implementiert wurde.

Aus WikiPedia heraus kontrolliert die Transportschicht die Zuverlässigkeit einer bestimmten Verbindung durch Flusskontrolle, Segmentierung / Desegmentierung und Fehlerkontrolle. Einige Protokolle sind zustands- und verbindungsorientiert. Dies bedeutet, dass die Transportschicht die Segmente verfolgen und die fehlgeschlagenen erneut übertragen kann. Die Transportschicht liefert auch die Bestätigung der erfolgreichen Datenübertragung und sendet die nächsten Daten, wenn keine Fehler aufgetreten sind.

Ohne die Transportschicht, die heutzutage das TCP / IP-Protokoll bedeutet, wäre es nicht möglich, sicherzustellen, dass Ihre Daten das Ziel erreichen, oder dass fehlende Teile automatisch zurückgesetzt werden.

Es ist durchaus möglich, dass Maschinen in einem lokalen Netzwerk ohne eine Routing-Schicht kommunizieren. Sie binden die Nachricht einfach in einen Ethernet-Frame ein und hoffen auf das Beste. Es ist ein bisschen so, als würde man eine Notiz auf eine Postkarte schreiben und hoffen, dass die Post ihren Job macht.

Sie müssen hoffen, dass der Empfänger abhört, und sorgfältig auf eine Antwortnachricht warten (möglicherweise unter vielen anderen Nachrichten von anderen Knoten). Sie sind dafür verantwortlich, alle diese Nachrichten selbst zu sortieren.

Wenn Sie beispielsweise 1: 1-Nachrichten erhalten möchten, benötigen Sie zusätzlich zu den Ethernet-Frames ein anderes Protokoll, um das Abhören für Sie zu erledigen. Hierfür wird häufig das Point-to-Point-Protokoll (PPP) verwendet, über Ethernet wird dies als PPPoE bezeichnet. PPPoE bietet Ihnen Authentifizierung und Verschlüsselung, beides sehr gute Ideen in einem Broadcast-Netzwerk.

Ohne irgendeine Form von Routing-Informationen können Sie jedoch nur mit Knoten im lokalen Netzwerk kommunizieren. Sobald Sie anfangen, Routing-Informationen für die Weiterleitung von Nachrichten (z. B. ins Internet) zu verwenden, möchten Sie eine Form von Routing-Protokoll, z. B. IP oder IPX. Und wahrscheinlich möchten Sie auch eine Übertragungssteuerung (TCP) ...

IP-Netzwerke sind eine Abstraktion, eine Indirektionsebene, das heißt, sie sind ein virtuelles Netzwerk, das nicht permanent an eine bestimmte physikalische Kommunikationsmethode oder ein bestimmtes Gerät gebunden ist.

Ein Ethernet-Host verfügt über eine MAC-Adresse (pro NIC), die ihn global eindeutig identifiziert. Dieser Host kann jedoch gleichzeitig zu vielen IP-Netzwerken gehören, wobei für jedes eine andere IP-Adresse verwendet wird und immer die eine MAC-Adresse verwendet wird.

Diese Trennung von physischer und logischer Adressierung oder Virtualisierung der Adressierung ermöglicht eine gewisse Flexibilität, z. B. das Verschieben eines IP-Hosts (z. B. eines Servers) von einem physischen Computer auf einen anderen mit einer anderen MAC-Adresse, ohne dass andere Hosts neu konfiguriert werden müssen (zB Client-Software).

IP oder das Internet-Protokoll und Ethernet lösen unterschiedliche Probleme: Ethernet ermöglicht die Kommunikation auf LAN-Ebene und nur in einem einzelnen LAN. Dabei spielt es keine Rolle, mit welchen anderen Netzwerken das LAN über einen Router verbunden sein kann. IP befasst sich mit Internetworking und ist daher LAN-unabhängig. Könnte Ethernet IP-Adressen anstelle von MAC-Adressen verwenden? Sicher, aber es bringt Ihnen nichts, da diese Nachrichten immer noch auf das LAN beschränkt wären.

In einem Ethernet-LAN, das DHCP (Dynamic Host Configuration Protocol) für die Zuweisung von IP-Adressen verwendet, tritt eine solche Situation zu unterschiedlichen Zeiten auf . Wenn ein neuer Host eine Verbindung zum LAN herstellt, hat er keine IP-Adresse, sendet also einen gesendeten Ethernet-Frame an alle Geräte und wartet auf die Antwort eines DHCP-Servers. Zu diesem Zeitpunkt kennt der Client weder die MAC-Adresse noch die IP-Adresse des DHCP-Servers, daher die Rundsendung. Beim Empfang der Anfrage kennt der Server nun die MAC-Adresse des Clients und kann so die Antwort korrekt adressieren.