Zusammenfassung
- RFC 3378 dokumentierte EtherIP: Ein 16-Bit-Kopf stand vor dem Ethernet-Frame, der mit IP-Protokollnummer 97 durch IPv4 transportiert wurde.
- Der Kopf bot keine Peer-Authentisierung, innere Integrität, Reihenfolge, Tunnelsteuerung oder Schleifenvermeidung. Erfolgreiches Entkapseln belegte Ankunft, nicht ein sicheres gemeinsames LAN.
Ein LAN besteht nicht nur aus Frames. Verkabelung, Switches, Verwaltung und Nachbarschaftsannahmen geben lokalen Protokollen ihren Sicherheitsrahmen. EtherIP erhielt das Format und entfernte die Örtlichkeit.
RFC 3378 erschien im September 2002 als Informational. Es hielt ein 1991–1992 entwickeltes Protokoll und den Hintergrund der Nummer 97 fest. Für neue Entwürfe verwies es auf spätere Standards zu Layer-2-Tunneln und Pseudowires.
Nach IPv4 folgten vier Versionsbits mit Wert drei und zwölf reservierte Nullbits. Dann kam der Ethernet- oder IEEE-802.3-Frame ohne FCS. Der Empfänger verwarf falsche Werte, entnahm den Frame, berechnete ein neues FCS und sendete ihn im entfernten LAN.
Das war Syntaxprüfung, keine Vertrauensprüfung. Weder Sender noch MAC-Berechtigung, Sitzung, Reihenfolge oder innere Unversehrtheit wurden belegt.
Das ursprüngliche FCS endete am Eingang. Die IPv4-Kopfsumme schützte den inneren Frame laut RFC nicht; ein höheres Protokoll sollte Integrität liefern. Ein korrektes neues FCS am Ausgang bestätigte nur den letzten lokalen Link.
Endstationen konnten eigene Frames auswählen. Brückenähnliche Stationen hörten promiscuous und entschieden nach MAC, EtherType oder VLAN. Zusätzlich musste eine Ziel-MAC einer entfernten IP zugeordnet werden. Auswahl und Zuordnung lagen außerhalb der 16 Bits.
Mehrere Brücken konnten denselben Broadcast oder Multicast endlos erfassen und wieder einspeisen. Die RFC verlangte eine Baumtopologie, überließ deren Bau aber dem Menschen. Weder Spanning Tree noch Hop Count begrenzten eine Fehlkonfiguration.
So konnten alle lokalen Regeln korrekt und ihr Zusammenspiel dennoch zirkulär sein. Steigende Zähler belegten Verarbeitung, keinen Nutzen.
Auch die Sicherheitsgrenze dehnte sich aus. EtherIP durch eine Firewall konnte beliebige Kommunikation ermöglichen. Schwache Mechanismen für lokale Nachbarn wurden auf Distanz gefährlicher. VRRP diente als Beispiel; IPsec als mögliche äußere Sicherung.
RFC 2401 und RFC 4301 geben den IPsec-Kontext. Äußerer Schutz entscheidet jedoch nicht über Capture-Regel, Baum, Wiedereinspeisung oder Anwendungsergebnis.
RFC 2003 und RFC 2784 bieten Vergleiche mit IP-in-IP und GRE. RFC 3931, RFC 3985 und RFC 4448 zeigen spätere L2TPv3- und Pseudowire-Strukturen. Sie ergänzen EtherIP nicht rückwirkend und beweisen keine Verbreitung.
Die MUST-Wörter aus RFC 2119 betreffen Felder und Verwerfungen. IANAs Eintrag macht 97 verständlich, nicht freigegeben oder sicher. Lu Hengs minimale Anfangsspezifikation erklärt den Wert weniger gemeinsamer Bits; seine Realitätsebenen trennen Auswahl, Kapselung, Peer, Route, Integrität, Ausgang und Empfang.
EtherIP bewegte den Umschlag. Topologie, Autorität, Vertrauen und physische Folgen des LAN blieben zurück und mussten neu abgesichert werden.
Quellen
Mitgliederbriefing
Detaillierter Profilkontext
Melden Sie sich mit der richtigen Mitgliedschaftsstufe an, um das vollständige Briefing und die Quellennotizen freizuschalten.
Nur für Strategic Circle
Strategic Circle
Offen für alle Leser. Schalten Sie Profil-Briefings nach Beitritt und Anmeldung frei.
Strategic Circle beitretenNur für Leadership Alliance
Leadership Alliance
Für qualifizierte Inhaber von IP-Assets und Management; melden Sie sich an, um Leadership-Alliance-Briefings freizuschalten.
Leadership Alliance beitreten
