Zusammenfassung

  • RFC 3069 ließ getrennte Kunden-VLANs ein IPv4-Subnetz und Gateway gemeinsam nutzen, ohne ihre Broadcast-Domänen auf Layer 2 zusammenzuführen.
  • Ein Host im selben Präfix versucht zuerst ARP. Deshalb muss ein Super-VLAN-Router vermitteln; die Maske beweist weder Nachbarschaft noch Berechtigung.

Weniger Adressen, mehr Vermittlung

Die Rechnung war attraktiv. Im RFC-Beispiel erwarteten drei Kunden je sechzehn Hosts. Separate Subnetze verbrauchten 28 Adressen, wenn Netzwerk-, Directed-Broadcast- und Gateway-Adresse sowie die Aufrundung auf Zweierpotenzen berücksichtigt wurden. RFC 3069 kam mit neunzehn aus: Drei Kunden-Sub-VLANs teilten 1.1.1.0/24 und das Gateway 1.1.1.1, behielten aber disjunkte Hostbereiche. Ein ungenutzter Bereich konnte weiterverwendet werden, ohne den ursprünglichen Kunden umzunummerieren.

Die Einsparung machte Kunden nicht zu Nachbarn auf Layer 2. Jedes Sub-VLAN blieb eine eigene Broadcast-Domäne. Dennoch verwendeten alle Hosts die Präfixlänge des Super-VLANs. Gewöhnliche IP-Logik behandelte ein Ziel innerhalb 1.1.1.0/24 deshalb als on-link und versuchte ARP, statt das Paket an das Standard-Gateway zu schicken. ARP löst eine Link-Layer-Adresse im lokalen Netz auf; es vereinigt keine getrennten Broadcast-Domänen.

Der Super-VLAN-Router füllte die Lücke. Laut RFC 3069 darf er eine Proxy-ARP-ähnliche Funktion übernehmen: auf eine Anfrage für eine Adresse in einem anderen Sub-VLAN antworten, den Frame entgegennehmen und das Paket weiterleiten. Für den Host sah das Ziel wie ein Nachbar aus. Im Weiterleitungssystem vermittelte der Router. Der Präfix beschrieb eine Adressbeziehung, keine physische oder Layer-2-Tatsache.

Hinter der scheinbaren Einfachheit steckt Betriebszustand. Der Router muss wissen, zu welchem Sub-VLAN jede Adresse gehört, entscheiden, ob der Absender die angegebene Quelladresse verwenden darf, konsistent auf ARP antworten und über den vorgesehenen Pfad weiterleiten. Eine plausible Maske oder erfolgreiche ARP-Antwort belegt nicht, dass die Adress-VLAN-Bindung aktuell oder autorisiert ist. RFC 3069 empfiehlt Sticky Address Ranges: IP- oder ARP-Pakete verwerfen, die aus einem Sub-VLAN mit einer dort nicht zugeteilten Quelladresse eintreffen, und den Vorgang optional protokollieren.

Die Schutzwirkung hängt von lokalen Zuteilungs- und Bindungsdaten ab.

Manche vertrauten Subnetzfunktionen passen nicht mehr zu einer einzigen Broadcast-Domäne. RFC 3069 unterstützt keinen Directed Broadcast, weil die All-ones-Adresse nicht gleichzeitig mehrere getrennte Layer-2-Domänen bezeichnen kann. Auch Multicast braucht Sonderbehandlung: Für RPF-Prüfungen zwischen getrennten Domänen kann ein Multicast-Router hostroutenähnlichen Zustand benötigen. RFC 4562 beschrieb später, wie kundenweise VLAN-Trennung Multicast-Replikation erschwert und die Obergrenze von 4096 VLANs in Breitband-Zugangsnetzen zum Betriebsproblem macht.

Die Adressersparnis beseitigte Kosten nicht, sondern verlagerte sie in Routerzustand und Netzbetrieb.

Die Beweisgrenze ist wichtig. RFC 3069 ist Informational und kein Internet Standard; Implementierungsdetails lässt er absichtlich offen. Er berichtet, Extreme Networks habe seit mehr als einem Jahr eine funktionierende Implementierung in Service-Provider-Rechenzentren betrieben. Das ist ein Bericht der RFC-Autoren, keine unabhängige Verbreitungsstudie. Für andere Hersteller erwähnt der Text nur Gerüchte über ähnliche Entwicklungen. Breite Messungen zu Interoperabilität, Fehlerraten oder Kundenergebnissen fehlen.

Das Paket prüfen, nicht nur die Maske

Wenn ein Datenfluss innerhalb desselben Präfixes scheitert, ist die Maske nur ein Hinweis. Zu prüfen sind ARP-Anfrage und -Antwort am eingehenden Sub-VLAN, Quelladresse, Adress-VLAN-Zuteilung im Router, Proxy-/ARP-Entscheidung und Weiterleitungsergebnis. Bei Multicast zählen auch RPF-Zustand und senderbezogene Routen. Diese Belege zeigen das Verhalten des Routers an einem Beobachtungspunkt; sie beweisen nicht automatisch den Anwendungserfolg oder die Isolation jedes Zugangspfads.

Quellen