Zusammenfassung

  • Revision 15 des MASQUE-Entwurfs transportiert Ethernet-Frames über einen geschützten HTTP-Tunnel; sie bindet den authentisierten HTTP-Prinzipal nicht automatisch an die Quell-MAC jedes Frames.
  • 101 oder 2xx belegt den Tunnelaufbau. Größenannahme, MAC- und VLAN-Entscheidungen, Schleifenfreiheit, Ausgang und Zielwirkung sind eigenständige Tatsachen.

draft-ietf-masque-connect-ethernet-15 wurde am 30. September 2026 veröffentlicht. Der aktive MASQUE-Arbeitsgruppenentwurf strebt Proposed Standard an. Datatracker führt ihn in IESG Evaluation mit dem Unterstatus AD Followup; nach Revision 15 steht die IANA-Prüfung wieder auf „Version Changed - Review Needed“. Er ist kein RFC und die eingefrorenen Quellen belegen weder Einführung noch Verbreitung, Implementierungskonformität, Leistung oder einen Vorfall.

HTTP/1.1 handelt den Mechanismus per GET, Upgrade: connect-ethernet und 101 Switching Protocols aus. HTTP/2 und HTTP/3 nutzen Extended CONNECT mit :protocol = connect-ethernet; eine passende 2xx-Antwort startet das Capsule Protocol. Erfolg bedeutet, dass der Proxy den Tunnel eingerichtet hat und Frames weiterleiten will.

Ein Tunnelbeleg ist noch kein Datenbeleg

Die Verbindung muss über TLS, QUIC-Verschlüsselung oder gleichwertigen Schutz laufen. Das sichert die HTTP-Beziehung. Es bescheinigt jedoch nicht, dass eine im Ethernet-Header behauptete Quelladresse dem HTTP-Nutzer gehört. Der Entwurf erlaubt beliebige Frames und warnt vor beliebigen Quell-MACs, Host-Imitation sowie ARP-, NDP- und CAM-Vergiftung.

Context ID 0 bezeichnet das Ethernet-Format. Die Nutzlast reicht von der Zieladresse bis vor die FCS. Die ursprüngliche FCS entfällt, weil Schnittstellen sie beim Eingang entfernen und beim Ausgang neu erzeugen. Transportintegrität und eine neue FCS sind wichtig, aber keine Herkunftsbescheinigung für die Quell-MAC.

Lokale Richtlinien müssen deshalb HTTP-Prinzipal, URI, erlaubte Quell- und Zieladressen, EtherTypes, VLANs, Laufzeit und Widerruf verbinden. Der Entwurf nennt Ein-MAC-Beschränkung, konfigurierte Filter, IEEE 802.1X, Nutzerauthentisierung und Rate Limits. Eine dynamische Aushandlung der MAC-Filter bleibt künftigen Erweiterungen vorbehalten.

Die Größenentscheidung verändert den Ausgang

Bei HTTP/3 können Ethernet-Frames in QUIC-DATAGRAM übertragen werden. Diese Datagramme werden nicht fragmentiert. Passt ein Frame nicht in die verfügbare Nutzlast, muss er verworfen werden; der Endpunkt darf ihn nicht stillschweigend in eine DATAGRAM-Capsule verschieben.

Capsules auf einem Stream können größere Frames über mehrere Pakete tragen. Sie bieten andere Zuverlässigkeitseigenschaften, doch die Frame-Reihenfolge ist nicht in jeder Architektur garantiert. Ein Vermittler kann Capsules in QUIC-DATAGRAM umcodieren. Derselbe lebende HTTP-Tunnel kann daher je nach Modus, Pfad-MTU und Vermittler andere Zustell- und Ordnungsmerkmale besitzen.

Nach der Entkapselung folgt eine zweite Größenprüfung. Übersteigt der Frame die Grenze der Ausgangsschnittstelle, des Zielnetzes oder des Empfängers, muss er ebenfalls verworfen werden. Der Entwurf empfiehlt einen Zähler für übergroße Frames. Kann der Endpunkt den Frame nicht in das zugrunde liegende Segment liefern, wird er verworfen.

Eine Betriebsanzeige braucht deshalb mindestens: eingegangene Größe, aktuellen Modus, verfügbare Datagramm-Nutzlast, erkundete Pfad-MTU, Ausgangsgrenze, Drop-Grund, Warteschlange und Schnittstellenergebnis. Ein grüner Tunnel ohne diese Werte beantwortet die falsche Frage.

VLAN und Bridge besitzen eigene Zustände

802.1Q-Tags werden standardmäßig transparent weitergereicht. Wenn Ein- oder Ausgang sie auswertet, benötigen beide Seiten eine signalisierte oder manuell konfigurierte Übereinkunft; der Entwurf definiert sie nicht. Eine VLAN-spezifische URI oder das Entfernen und spätere Ergänzen eines Tags kann sinnvoll sein, macht aber die URI–VLAN-Zuordnung zur Autorisierungsregel.

Wird der emulierte Link an ein externes Netz angeschlossen, entstehen Bridge-Aufgaben: Broadcast, Multicast, PAUSE, Lernen und Schleifenvermeidung. Zwei korrekte Tunnel können gemeinsam einen falschen Kreis bilden. STP/RSTP, Delegation an den Kernel, eine nachweislich schleifenfreie Topologie sowie Broadcast-Limits sind getrennte Kontrollen.

Der Nachweis muss entlang des Frames laufen

Die belastbare Kette hält auseinander: Transportendpunkt; HTTP-Identität und Richtlinie; URI/VLAN; 101/2xx; Context und Übertragungsmodus; MAC-Entscheidung; Tag-Behandlung; Bridge-Zustand; Größen- und Queue-Entscheidung; Ausgang; Beobachtung am Ziel. Die Tunnelantwort darf keine spätere Stufe vertreten.

Heng Lus Texte zu Running-Code Primacy, minimaler Anfangsspezifikation und Agency dienen als offengelegte redaktionelle Linse. Der gemeinsame Mechanismus kann schmal bleiben, wenn laufende Systeme ihre zusätzlichen Macht- und Wirkungsaussagen belegen. Das ist eine Analyse, keine Behauptung über IETF-Absichten.

Quellen