Zusammenfassung

  • Ein einzelnes Präfix aus einem historischen Class-A-Netz konnte in classful Logik das ganze Elternnetz repräsentieren und dessen übrigen Verkehr vom Default abziehen.
  • Die Freigabe des Adressvorrats verlangte deshalb eine gemeinsame Umstellung von Registry, Providern, Kundendomänen, Peers, Aggregation und Lochbehandlung.
  • RFC 2036 prognostizierte Bedingungen und Risiken; er lieferte weder Häufigkeiten aus dem Betrieb noch den Erfolgsnachweis eines Anbieters.

Ein verfügbarer Bestand war noch kein nutzbarer Bestand

RFC 2036 kommentierte eine mögliche Empfehlung, nach der IANA die damals unzugewiesenen Teile des Class-A-Raums über Registries als classless Präfixe vergeben sollte. Bisherige CIDR-Zuteilungen waren häufig konservativ als Superblöcke von Class-C-Netzen aufgebaut. Die neue Adressrechnung konnte so mit älterer Routinglogik koexistieren.

Ein Provider ohne Volltabelle durfte einen Default importieren und intern classful arbeiten. Die Aggregation zusammenhängender Klassenblöcke konnte ein Peer stellvertretend übernehmen. Diese Konstruktion war suboptimal, doch solange Zuteilungs- und Klassengrenzen zusammenfielen, blieb ihre gefährlichste Mehrdeutigkeit verborgen.

Ein kleiner Ausschnitt aus einem Class-A-Elternnetz änderte die Auswahl. Sah ein Router zugleich Default und Teilnetz, konnte er letzteres zur Route für die gesamte Klasse vergrößern. Ziele in anderen Ausschnitten folgten dann nicht zwingend dem Default. Der Default war nicht ausgefallen; er war durch eine falsche, angeblich genauere Kenntnis unzuständig geworden.

Daraus leitete RFC 2036 eine harte Forderung ab: Auch Default-only-Provider mussten classless routen. Proxy-Aggregation durch andere konnte die verlorene Präfixlänge nicht verlässlich ersetzen. Der Registry-Schnitt wurde zur Mindestanforderung an laufende Software.

Das Subnetz-Default zeigte plötzlich nach außen

Für eine nichttransitive Kundendomäne war die korrekte Richtung ungewohnt. Bei klassenkonformen Netzen durfte ein explizites Subnetz-Default nicht zum Provider zeigen, weil sonst an der Grenze eine Schleife entstehen konnte. Beim tolerierten classful Betrieb eines Class-A-Ausschnitts musste es laut RFC 2036 dagegen dem allgemeinen Default zum Provider folgen.

Diese Umkehr hielt den Rest des Elternnetzes erreichbar, erzeugte aber weitere Pflichten. Explizite interne Subnetzrouten konnten zum Provider durchsickern. Der Provider musste gegebenenfalls den Registry-Block aggregieren. Schickte er Verkehr für einen nicht belegten Teil unter dem Proxy-Aggregat zurück zum Kunden, kreiste der Verkehr an der Grenze. Routete er nur belegte Teile, wanderte ein Paket für das Loch über Defaults bis zu einem defaultfreien Punkt und wurde dort verworfen.

Darum empfiehlt das Dokument für alle unbelegten Komponenten Sink-Subnetzrouten. Aggregat und Sink bilden unterschiedliche Belege: Das Aggregat fasst die externe Ankündigung zusammen, der Sink begrenzt sie innerhalb des Blocks. Eine Soll-Konfiguration beweist noch keine FIB und keinen beobachteten Paketpfad.

Multi-Homing übertrug die Pflicht auf die ganze Nachbarschaft

Eine getrennte Domäne konnte classful bleiben. Ein einfach angebundener Kunde konnte die enge Default-Ausnahme nutzen. Mit einem zweiten Provider war das nicht mehr sicher, weil verschiedene Anbieter verschiedene Komponenten desselben Elternnetzes ankündigen konnten. Das interne Routing musste die Masken erhalten.

Noch deutlicher wird die Transitivität an Peers. RFC 2036 skizziert zwei classless Stubs X und Y, die über eine classful Domäne Z verbunden sind. X kündigt einen Ausschnitt an. Z macht daraus die ganze Class A und gibt sie an Y weiter. Diese Route verdrängt Ys Provider-Default; der Verkehr läuft über Z nach X und wird dort als nichtlokal verworfen.

Kein Protokoll muss dabei abstürzen. Jeder Prozess kann seine alte Regel korrekt ausführen. Fehlerhaft ist die Kombination aus neuer Zuteilungsgrenze und alter Interpretation. Eine spätere Peer- oder Backup-Verbindung kann deshalb eine gestern sichere Ausnahme ungültig machen.

Die Registry setzte einen Einsatzfilter

Die vorgeschlagene Anfangsphase sollte Präfixe an Netze geben, die bereits classless arbeiteten, oder an isolierte beziehungsweise einfach an einen classless Provider angeschlossene classful Domänen mit richtigem Subnetz-Default. Router sollten classless/classful Betrieb und die Wahl zwischen Default-Folge und Subnetz-Sink ausdrücklich konfigurierbar machen. Hosts sollten langfristig einen lokalen Präfix statt nur Klasse, Subnetz und Host verstehen.

RFC 2050 formulierte einen Monat später die administrative Ergänzung: Zuteilungen setzten VLSM und classless Technologien voraus; Anträge auf Basis classful Nutzung sollten nicht berücksichtigt werden. Das belegt eine Richtlinie, nicht deren Umsetzung bei jedem Empfänger.

Der ALE-Arbeitskreis lieferte den Druckkontext. Seine Charta umfasste IPv4-Lebensdauer, Auslastung, Zuteilungsregeln, Routenzahl sowie mögliche Rückgabe und Renummerierung. RFC 2036 verweist auf ALEs Sorge um den Class-C-Pool und den damals großen freien oberen Class-A-Bereich, veröffentlicht aber keine Rohdaten und keine Fehlerstatistik.

Historisch heißt abgeschlossen, nicht vollständig vermessen

RFC 2036 erschien Informational, ist heute Historic und hat laut RFC Editor keine erfassten Errata. RFC 4632 begründete die Herabstufung 2006 mit vollständigem CIDR-Einsatz und mehr als sechs Jahren Erfahrung mit classless Zuteilungen aus ehemals Class-A-Raum. Das ist ein später IETF-Befund, keine Betreiberliste und keine Messung der Vorhersagen aus RFC 2036.

RFC 4632 bewahrt zugleich das allgemeine Gegenmittel für Aggregatlöcher: Pakete, die nur das Aggregat, aber keine spezifischere Route treffen, müssen am Ursprung zum Nullziel gehen. Das heutige IANA-Register und die Dokumente zu den letzten /8 zeigen, dass der 1996 beschriebene Vorrat nicht mehr besteht. Sie sagen nichts über damalige Schleifen oder Erfolgsquoten.

Eine belastbare Rekonstruktion braucht sechs getrennte Quittungen: Registry-Präfix, Provider-Default und Importpolitik, Kunden-IGP und Subnetz-Default, Aggregat-Auslöser und Sinks, Maskenerhalt bei allen Peers sowie den tatsächlich beobachteten Next Hop oder Verwerfpunkt. Heng Lus Running-Code-Perspektive setzt jeder Behauptung dort eine Grenze, wo ihr Beleg endet. Der Eintrag ist Koordination; Erreichbarkeit entsteht erst, wenn alle Laufzeitschichten dieselbe Präfixgrenze bewahren.

Quellen