Zusammenfassung

  • RFC 2784 trennt Delivery Header, GRE Header und Payload. Der vier Oktette große Basiskopf benennt das innere Protokoll, entscheidet aber weder über den Grund des Tunnels noch über Berechtigung, Erreichbarkeit oder Schutz der Fracht.
  • Tony Li war Mitautor des GRE-Dokuments von 1994 und der Standards-Track-Spezifikation von 2000. Spätere RFCs zeigen die Betriebsschuld: Das Key-Feld ist ein Kontextkennzeichen, Sequenzierung erzeugt angreifbaren Zustand, und IPv6 verlangt fortlaufende MTU- und Integritätsentscheidungen an den Endpunkten.

Zwei Ziele, drei getrennte Nachweise

Am Ingress wird das ursprüngliche Paket zur Payload. Davor kommt ein GRE Header, um beides ein Delivery Header. Das Underlay liest das äußere Ziel und befördert die gesamte Konstruktion zum Egress. Dort werden die äußeren Schichten entfernt; das innere Ziel übernimmt wieder die Weiterleitung.

Damit entstehen drei eigenständige Datensätze. Der Delivery Header benennt die Tunnelendpunkte. GRE beschreibt den Typ der Fracht und aktive Optionen. Die Payload behält Quelle, Ziel, Lebensdauer und Bedeutung höherer Schichten. Eine funktionierende äußere Route beweist nur die Zustellung des Umschlags. Sie beweist keine innere Route, keine Freigabe nach der Decapsulation und keine Inspektion an der richtigen Stelle.

RFC 2784 erschien im März 2000 auf dem Standards Track und nennt Dino Farinacci, Tony Li, Stan Hanks, David Meyer und Paul Traina. Vorläufer war der Informational RFC 1701 von Hanks, Li, Farinacci und Traina. Das IETF-Datatracker-Profil von Tony Li liefert öffentliche Identität, RFC-Verzeichnis und Rollen im eingefrorenen Stand. Belegt ist kollektive Autorschaft, nicht Alleinerfindung, aktueller Arbeitgeber oder persönliche Kontrolle über laufende Tunnel.

Die personenbezogene Aussage ist enger und belastbarer: Li steht sowohl im frühen Entwurf eines allgemeinen Umschlags als auch in der späteren Verkleinerung seines gemeinsamen Kerns. Die dauerhafte Leistung liegt nicht in der Herrschaft über alle Anwendungen, sondern in der Disziplin, die gemeinsamen Bedeutungen klein zu halten.

Ein Umschlag statt einer Matrix aus Sonderfällen

Benötigt jedes Payload-Protokoll für jedes Delivery-Protokoll eine eigene Methode, wachsen die Paarungen als Matrix. RFC 2784 beschreibt dieses Problem als O(n²) und ordnet es neu: Payload, gemeinsames GRE, Delivery.

Die Allgemeinheit hat ausdrücklich Grenzen. Protokollspezifische Feinheiten werden ausgelassen; eine spezialisierte Lösung X über Y kann geeigneter sein. Vor allem bestimmt der RFC absichtlich nicht, wann ein Paket gekapselt werden soll. Er liefert Grammatik, keine Rechtfertigung.

Ein Unternehmen kann private Netze verbinden, ein Provider einen Dienst über ein Underlay tragen, ein Labor ein unbekanntes Protokoll testen. Kein Zweck wird durch ein konformes Format legitimiert. Eigentümer, Endpunkte, erlaubte Payloads, Kapazität, Sicherheitsgrenze und Ausstiegsbedingung bleiben lokale Entscheidungen.

Der gemeinsame Umschlag senkt Implementierungs- und Koordinationskosten. Er übernimmt aber keine Verluste aus Leaks, Blackholes, blinder Inspektion oder vergessener Abhängigkeit. Wer durch GRE spart, behält das betriebliche Risiko seines Einsatzes.

Vier Oktette enthalten keine verborgene Autorität

Ohne optionalen Checksum besteht der RFC-2784-Basiskopf aus zwei 16-Bit-Wörtern. Das erste enthält Checksum-Present, reservierte Bits und Version; das zweite den Protocol Type, einen EtherType für die Payload. Die Basisversion ist null.

Nicht enthalten sind globaler Tunnelbezeichner, Eigentümer, Policy, Route, Verschlüsselungszusage oder Serviceversprechen. Der Kopf sagt, wie die folgenden Bytes zu lesen sind. Ein unbekannter Protocol Type sollte verworfen werden. Reservierte Bits werden als null gesendet; bestimmte ältere Positionen führen bei einem Empfänger ohne entsprechende Implementierung zum Verwerfen.

Der optionale Checksum fügt vier Oktette hinzu und deckt GRE Header plus Payload mit der gewöhnlichen Internet-Prüfsumme. Er findet einen Teil zufälliger Verfälschungen, authentifiziert aber keinen Absender, verschlüsselt nichts und verleiht kein Recht. Eine gültige Prüfsumme ist kein vertrauenswürdiger Tunnel.

Eine minimale Spezifikation ist somit nicht unbestimmt. Sie macht wenige gemeinsame Tatsachen streng und lässt alles andere sichtbar außerhalb ihrer Zuständigkeit.

Nach dem Öffnen gehört die Route wieder der Payload

Ist die Fracht IPv4, muss der Egress laut RFC 2784 anhand des inneren Ziels weiterleiten und dessen TTL verringern. Das äußere Ziel hat seine Aufgabe beendet und ersetzt nicht die Routingsemantik des transportierten Pakets.

Der Text nennt auch eine Schleifenbedingung. Zeigt das innere Ziel auf den Encapsulator am anderen Ende, kann das Paket in dieselbe Beziehung zurücklaufen und muss verworfen werden. Ein Tunnel verbirgt Topologie, hebt aber die Folgen einer Schleife nicht auf.

Für die Diagnose ist diese Trennung entscheidend. Ein äußerer Traceroute erreicht den Egress, obwohl die innere Route fehlt. Das Tunnelinterface ist up, während eine Policy die Payload nach dem Öffnen stoppt. Umgekehrt kann ein GRE zugeschriebener Fehler im Underlay, Rückweg, Filter oder MTU liegen. Die drei Datensätze müssen getrennt beobachtet und am selben Paket verbunden werden.

Die Standardisierung verkleinerte den gemeinsamen Kern

RFC 1701 bot Routing, Key, Sequence, Strict Source Route und Recursion Control. RFC 2784 standardisierte die von mehreren Herstellern tatsächlich geteilte Schnittmenge und entfernte diese Felder aus dem Basisprofil. Ein Empfänger ohne ausdrücklich alte Funktion verwirft entsprechende gesetzte Bits.

Die Entwicklung bestand nicht aus immer mehr Optionen. Der gemeinsame Bedeutungsraum wurde kleiner, damit unabhängige Implementierungen über weniger Dinge sicherer übereinstimmen. Optionale Bedürfnisse konnten in einer gesonderten Extension zurückkehren, statt aus reservierten Bits erraten zu werden.

Kompatibilität ist daher eine erklärbare Ablehnungsgrenze. Ein unbekanntes Layout großzügig anzunehmen, löst die unterschiedlichen Fähigkeiten der Endpunkte nicht. Betreiber müssen das Paar nachweisen, nur das vereinbarte Profil aktivieren und einen Rollback zum vorherigen Parsingvertrag erhalten.

Ein Feld namens Key ist kein Sicherheitsschlüssel

RFC 2890, verfasst von Govindan Dommety und nicht von Li, definierte später optionale Key- und Sequence-Number-Erweiterungen. Der vier Oktette lange Key identifiziert einen Flow oder Kontext zwischen den Endpunkten; seine Vergabe liegt außerhalb des Dokuments.

Der Name legt einen gefährlichen Schluss nahe. Der RFC stellt klar, dass dieses Feld keine Sicherheitsfunktion hat. Nach lokaler Vereinbarung kann es Kunden oder Dienste unterscheiden. Ohne äußeren Schutz kann jedoch jeder, der GRE erzeugen kann, den Wert kopieren oder erfinden. Ein Kontextlabel ist kein Passwort.

Sequence Number unterstützt unzuverlässige, aber geordnete Lieferung. Der Empfänger speichert den letzten erfolgreich entkapselten Wert, verwirft ältere und darf begrenzt umsortieren. Für manche Payloads ist das hilfreich, erzeugt aber Zustand je Flow. Eine injizierte hohe Nummer kann legitimen Verkehr alt erscheinen lassen.

RFC 2890 verlangt für dieses Bedrohungsmodell IPsec AH oder ESP. Er warnt außerdem vor doppelter Reihenfolge, wenn eine höhere Schicht sie schon bereitstellt oder Unordnung toleriert. Ein optionales Bit aktiviert zugleich Speicher, Buffer, Counter, Logs und Angriffsfläche an beiden Enden.

Filtern, wo die innere Bedeutung sichtbar ist

RFC 2784 hält Route Filtering weitgehend mit nativem IPv4 vergleichbar. Packet Filtering muss dagegen in GRE hineinsehen oder an den Endpunkten stattfinden. Das Underlay kann Protocol 47 zwischen zwei Adressen korrekt beschränken und dennoch inneres Protokoll, Adresse und Port nicht kennen.

An dieser Stelle zerfällt Verantwortung leicht. Transport verweist auf die beschränkte Außenroute. Security erlaubt GRE nur zwischen zwei Endpunkten. Der Service nimmt an, seine innere Fracht habe beide Freigaben geerbt. Tatsächlich definiert keine Außenregel, was nach Decapsulation zugelassen ist.

Ein prüfbares Design verzeichnet erlaubte innere Präfixe und Protokolle, den Ort der Decapsulation, den Inspektionspunkt und den tatsächlichen Einsatz von IPsec. GRE up ist kein Sicherheitszustand. Beweis ist die wirksame Policy beider Schichten am beobachteten Paket.

IPv6 machte Auslassungen zu Aktivierungskriterien

RFC 7676 von Carlos Pignataro, Ron Bonica und Suresh Krishnan spezifizierte später IPv6 als Payload oder Delivery. Er gehört nicht zu Lis Autorschaft. Er zeigt, wie aus einem dünnen Grundvertrag konkrete Betreiberpflichten entstehen.

Ein Tunnel mit IPv6-Payload muss ein 1280-Oktett-Paket vom Ingress zum Egress tragen können, ohne die Payload zu fragmentieren. Der Ingress prüft das vor Aktivierung und regelmäßig danach und schaltet entsprechend ein oder aus. GMTU ist der Pfad-MTU zwischen den Endpunkten minus Delivery Header und GRE Overhead. Zu große Payloads werden unter den beschriebenen Bedingungen verworfen; eine ICMPv6-Packet-Too-Big-Meldung gibt den nutzbaren Wert zurück.

Der kleine Header beseitigt Paketgröße nicht. Er macht Overhead berechenbar und den Endpunkt für Test und Feedback verantwortlich. Verschwindet PTB, funktionieren kleine Probes, größere Flows stocken und der Control Plane bleibt grün.

Auch Integrität hat eine Grenze. Der Verzicht auf GRE Checksum kann redundante Rechenarbeit sparen. Der IPv6 Delivery Header besitzt aber keine eigene Prüfsumme, und GRE würde ihn nicht abdecken. RFC 7676 analysiert einen seltenen Fall: Ein beschädigtes äußeres Ziel führt zum falschen VPN-PE; überlappende private Adressen und passender Zustand können die Payload ins falsche VPN leiten. GRE über IPv6 darf dort nicht eingesetzt werden, wo der Betreiber dieses Risiko nicht akzeptiert; Ende-zu-Ende-Authentifizierung der Payload kann es mindern.

Der RFC beweist keinen konkreten Vorfall. Er etabliert eine Frage mit lokalem Entscheider vor der Produktion. Allgemeine Transportfähigkeit ist keine allgemeine Sicherheit.

Dünne Koordination verlangt dicke Beweise am Rand

Lu Hengs späterer Text Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption bietet Sofia Ren einen Rahmen für GRE. Gemeinsam bleiben Layout, Version, Typ, Extensions und Ablehnung. Jedes Netz behält Freiheit und Pflicht, Zweck, Endpunkte, Zulassung, Schutz und Stilllegung zu entscheiden.

Running-Code Primacy erhöht den Beweismaßstab. Ein Konfigurationsobjekt ist Absicht. Die reale Kette verbindet Außenroute, gesendete Flags, Protocol Type, tatsächlichen Overhead, Key-Kontext, Security Association, Innenroute, Filterentscheidung, MTU-Feedback, Counter und Anwendungsergebnis.

Diese Heng-Texte sind ein später redaktioneller Rahmen, kein Beleg für Lis private Absicht oder für IETF-Konsens außerhalb der zitierten RFCs. Sie klären die Verteilung: Der Standard besitzt den gemeinsamen Umschlag; die Implementierung Parsing und Zustand; der Betreiber jeden Grund, aus dem der Umschlag existieren darf.

GRE blieb, weil es seine Payload nicht regiert. Diese Zurückhaltung machte es portabel. Sie bedeutet zugleich, dass in vier Oktetten keine Institution steckt, die einen nachlässigen Betrieb rettet. Der Umschlag kann fast alles tragen; nur die Endpunkte können beweisen, was er tragen soll.

Quellen