Zusammenfassung

  • RFC 2050 behandelte Conservation, Routability und Registration als getrennte, mitunter widersprüchliche Ziele und verlangte eine Abwägung im Einzelfall.
  • Zuteilung und Registereintrag belegten Eindeutigkeit, Ansprechpartner und Prüfgrundlagen; sie belegten weder Ankündigung noch globale Verbreitung, tatsächliche Erreichbarkeit, Legitimität oder dauerhaften Anspruch.

Der wichtigste Satz in RFC 2050 steht im Abschnitt über Routability: Die Vergabe oder Zuweisung einer IPv4-Adresse garantiere die Routbarkeit in keiner Weise. Damit zog das Dokument eine Grenze, die seine Prozentwerte und Verfahren erst verständlich macht.

Conservation sollte den endlichen Vorrat bedarfsgerecht verteilen und Hortung verhindern. Routability sollte durch hierarchische Vergabe Aggregation ermöglichen. Registration sollte Mehrfachvergabe ausschließen und bei Betriebs- oder Sicherheitsproblemen zuständige Kontakte liefern. Das RFC erklärte ausdrücklich, dass die ersten beiden Ziele oft kollidierten und alle drei gegen Einzelinteressen stehen konnten.

Ein kleiner, sparsam bemessener Block konnte als langes Präfix schwer transportierbar sein. Ein providergebundener Aggregatblock schonte die globale Routingtabelle, verlangte beim Anbieterwechsel aber Rückgabe und Renummerierung. Vollständige Reassignment-Daten erhöhten Rechenschaft, erzeugten jedoch Verwaltungsaufwand. Es gab keinen kostenlosen gemeinsamen Höchstwert.

Auch allocation und assignment waren nicht dasselbe. Ein Regional Registry teilte einem ISP Raum zu; der ISP wies einem Endunternehmen einen Teil zur internen Nutzung zu. Der Registereintrag dokumentierte eine solche Handlung. Er erzeugte keine BGP-Session und änderte keine Import-Policy eines Nachbarn.

Reassignment-Daten sollten unmittelbar gemeldet werden. Sie nannten Nutzer sowie Betriebs- und Sicherheitskontakt, belegten die weitgehende Nutzung des bisherigen CIDR-Blocks und dienten Studien. Etwa 80 Prozent der Angaben sollten vor einer weiteren Zuteilung vorliegen. Das Register war Prüfakte und Kontaktfläche, nicht Messnetz.

Die Akte konnte Subnetze, Masken, Hostzahlen, Topologie, Protokolle, Einschränkungen, frühere Zuteilungen, Ausbau und Wachstum enthalten. 25 Prozent Sofortnutzung, 50 Prozent nach einem Jahr und Slow Start waren historische Richtwerte. Sie beweisen keine heutige Policy und keine tatsächliche damalige Umsetzung.

Aus der CIDR-Architektur von RFC 1518 folgte der Rat, Adressen meist beim Upstream zu beziehen, Blöcke zusammenzuhalten und sie nach Ende des Zugangsvertrags zurückzugeben. Skalierbarkeit wurde durch eine sichtbare Bindung und Renummerierung erkauft.

Direkter Registry-Raum blieb für bestimmte Multihoming- oder Exchange-Fälle vorgesehen. Gerade providerunabhängige Adressen bezeichnete RFC 2050 jedoch als am wenigsten wahrscheinlich global routbar. Die Zusage eines anerkannten ISP, ein langes Präfix einzuspeisen, verpflichtete keinen Transit anderswo.

Große Transitanbieter durften Präfixlängen begrenzen und nicht aggregierte Routen filtern. Deshalb können Registerzeile und Routingstille gleichzeitig wahr sein. Umgekehrt beweist eine Route bei einem Collector nur Sichtbarkeit über dessen Peers zu diesem Zeitpunkt, nicht weltweite Annahme, autorisierten Ursprung, Nutzung oder Dienstzustand.

Das Dokument sprach außerdem von Leihadressen während der Konnektivität, bedingter Gültigkeit, Audits, möglicher Ungültigerklärung, Transfergenehmigung und Berufung bis zur IANA. Diese Aussagen gehören in das Jahr 1996. Sie entscheiden keine heutige Eigentums-, Vertrags- oder RIR-Frage.

Der RFC-Editor-Eintrag, der Datatracker und die Errata-Suche dokumentieren den heutigen Status Historic. RFC 7020 ersetzte RFC 2050 2013 und ließ überholte ICANN- und RIR-Verfahren bewusst aus.

Der Nachfolger behielt die funktionale Trennung: Pool-Management, hierarchische Zuteilung und Registrierungsgenauigkeit. Ob Adressen tatsächlich angekündigt werden und wie, erklärte er ausdrücklich zur operativen Frage außerhalb des Registry-Systems.

Die IESG Note begrenzte schon 1996 das BCP-Siegel. Die Genehmigung bedeutete nur, dass der Text nach Überzeugung des IESG die damalige Registry-Praxis zutreffend beschrieb. Sie war weder Empfehlung noch Billigung. Für die angekündigte Neubewertung im Dezember 1997 liefert das eingefrorene Quellenpaket kein separates Ergebnis.

RFC 1466 war der abgelöste Vorgänger. RFC 2008 behandelte Verleih, Portabilität und Filterung beim Providerwechsel. RFC 7249 bietet spätere Architektur. Das heutige IANA-IPv4-Register belegt seine aktuellen Zeilen, nicht die Route eines historischen Blocks.

Heng Lus Adressbuch trennt Eintrag und Straße. Seine Texte über Realitätsebenen, laufenden Code und minimale Anfangsspezifikation sind offengelegte heutige Deutungsrahmen, keine Aussagen der RFC-Autoren.

RFC 2050 schuf also kein schwaches Register. Es gab ihm konkrete Aufgaben: Eindeutigkeit, Kontakte, Nutzungsprüfung und aggregationsfreundliche Anreize. Stark war es gerade dort, wo es nicht behauptete, die Router anderer zu bedienen.

Quellen