Zusammenfassung

  • RFC 3194 formte die schwer vermittelbare H-Ratio aus RFC 1715 zur Host Density um: Logarithmus der zugeteilten Objekte geteilt durch den Logarithmus des maximalen Bestands, normalisiert auf null bis eins.
  • Drei historische Pläne änderten sich nahe 87 Prozent HD, obwohl ihre direkte Belegung nur 3,2, 10 und 22,8 Prozent betrug. Die Nähe war ein empirischer Schmerzindikator, kein Naturgesetz oder Erschöpfungsnachweis.

Eine freie Adresse half nicht, wenn sie im falschen Zweig lag

In einem flachen Behälter genügt Subtraktion: Gesamtzahl minus Belegung ergibt Restkapazität. Telefonnummern und Netzadressen wurden jedoch als Hierarchien vergeben.

Ziffern bezeichneten Regionen, Vermittlungen und Teilnehmer. Bits trennten Provider, Organisationen, Netze und Subnetze. Jede Ebene brauchte Reserve, weil Wachstum und Bewegung ungleich verteilt waren. Ein Zweig konnte überlaufen, obwohl ein anderer fast leer blieb.

Um diese Reserve zu verschieben, mussten Grenzen verändert und Teilnehmer neu nummeriert werden. RFC 3194 bezeichnete die Belastung für Betreiber und Nutzer als Schmerz. Praktische Kapazität endete nicht erst mit der letzten Zeichenfolge, sondern möglicherweise dann, wenn die Reorganisation der übrigen Zeichen zu teuer wurde.

Die Host Density lautete:

HD = log(zugeteilte Objekte) / log(maximal zuteilbare Objekte)

Die Basis war beliebig, solange sie oben und unten gleich war. Bei einem Objekt lag HD bei null, bei vollständiger Belegung bei eins. Dazwischen beschrieb 87 Prozent eine logarithmische Position. Es bedeutete nicht, dass 87 von hundert Adressen belegt waren.

Reserven auf mehreren Ebenen wirkten multiplikativ

War jede von drei Hierarchiestufen direkt zu 50 Prozent effizient, betrug die Gesamtbelegung 0,5 × 0,5 × 0,5, also 12,5 Prozent.

Der globale Raum konnte leer aussehen, während lokale Einheiten kaum noch wachsen konnten. Eine Summenzahl verriet weder die Lage der Lücken noch ihre Verwaltung oder die Kosten einer Verschiebung.

RFC 1715 hatte dafür die H-Ratio eingeführt: den Zehnerlogarithmus der Belegung geteilt durch die Adresslänge in Bits. Sie machte Pläne verschiedener Größe vergleichbarer, lag aber nur zwischen null und ungefähr 0,30103. Ein Wert von 0,25 benötigte eine Erklärung seiner eigenen Skala.

RFC 3194 teilte H meist durch log10(2) und erhielt HD zwischen null und eins. Ein Prozentwert war leichter auszusprechen.

Die neue Darstellung änderte keine Kapazität. Sie änderte die Sprache. Gerade dadurch entstand die Gefahr, dass Leser das Prozentzeichen als gewöhnlichen Anteil verstanden und den logarithmischen Nenner vergaßen.

Die drei Wendepunkte ähnelten sich erst nach der Umrechnung

Die Beispiele stammten aus RFC 1715. Frankreich fügte nach rund zehn Millionen Telefonen in einem achtstelligen Plan eine Ziffer hinzu. Das US-System erweiterte seine Vorwahlen bei etwa hundert Millionen Teilnehmern. Das global verbundene DECnet Phase IV zeigte bei ungefähr 15.000 Knoten in einem 16-Bit-Raum kein weiteres Wachstum; neue Knoten wurden verborgen.

Ihre direkten Belegungen betrugen 10, 3,2 und 22,8 Prozent. Eine gemeinsame Grenze war nicht sichtbar. Ihre HD-Werte lagen dagegen bei 87,5, 87,0 und 86,7 Prozent.

Die Autoren sahen darin einen Hinweis auf den Punkt, an dem Verwalter drastische Änderungen akzeptierten. Umnummerierung oder Protokollwechsel wurden aufgeschoben, bis das Festhalten am alten Plan noch schmerzhafter war.

Drei Fälle ergaben keine universelle Konstante. Technik, Institution und gezähltes Objekt unterschieden sich. Der Text sprach von Vorschlägen und Hypothesen. Er zeigte eine nützliche Verdichtung, nicht einen garantierten Zusammenbruch bei 87 Prozent.

Ein größerer Nenner senkte HD, ohne Teilnehmer zu löschen

Nach der französischen Erweiterung von acht auf neun Ziffern fiel HD von 87,5 auf 77,8 Prozent. In den USA sank er ungefähr von 87 auf 80 Prozent.

Die Population blieb. Das Maximum wurde größer. Derselbe Zähler nahm auf der logarithmischen Skala eine niedrigere Position ein.

RFC 3194 deutete 80 Prozent oder weniger als bequemeren Kompromiss. Der Wert erfasste aber nicht die Kosten der Umstellung: Geräte, Verzeichnisse, Kommunikation und Übergangsfehler konnten erheblich sein.

Eine niedrige HD beseitigte auch keine großen Routingtabellen, unglücklichen Delegationen oder lokalen Fragmentierungen. Mehr nominaler Raum war nicht automatisch Raum am richtigen Ort.

Die IPv4-Zeile machte den Unterschied messbar

Zur Rückrechnung verwendete der RFC:

zuteilbare Objekte = (maximale Objekte)^HD

Für 32 Bits nannte die Tabelle ungefähr 51 Millionen Objekte bei HD 80 Prozent, 154 Millionen bei 85, 192 Millionen bei 86 und 240 Millionen bei 87. Die Spalten hießen vernünftig, schmerzhaft, sehr schmerzhaft und praktisches Maximum.

240 Millionen sind nur rund 5,6 Prozent von 2^32. Über 94 Prozent der wörtlichen Werte konnten unzugeteilt bleiben, während die HD-Skala 87 Prozent zeigte.

Das war kein Widerspruch. Die Potenzrechnung übersetzte die logarithmische Position zurück. Der Abstand stand für Reserve und Verlust an mehreren Hierarchiestufen, nicht für verschwundene Adressen.

Auch das praktische Maximum war keine harte Grenze. Es hing laut Text davon ab, wie viel Schmerz Nutzer und Provider hinnehmen wollten. Wer mehr Belastung akzeptierte, konnte mehr Objekte zuteilen. Die Kennzahl stoppte keinen Vorgang.

Die Metrik war weder Register noch Routingbeweis

Die 128 Bit von IPv6 waren 2001 bereits beschlossen. RFC 3194 öffnete diese Entscheidung nicht neu, sondern bot eine Vergleichssprache für praktische Kapazität.

CIDR, Registry-Regeln und IPv6-Zuteilungsempfehlungen bestimmten Aggregation, Blockgröße, Reserve und Delegation. HD konnte ein Eingangswert sein, besaß aber keine Autorität über diese Regeln.

Ein zugeteiltes Objekt war außerdem nicht zwingend ein aktiver Host. Telefonteilnehmer, sichtbarer Knoten und delegierte Adresse waren verschiedene Einheiten. Wer den Zähler austauschte, ohne es zu sagen, ließ dieselbe Prozentzahl über eine andere Wirklichkeit sprechen.

Der historische Gewinn bestand in der Einsicht, dass freie Symbole nicht stets nutzbare Kapazität sind. Die Gegenseite dieser Einsicht lautet: Eine normalisierte Prozentzahl ist keine physische Belegung. Sie bleibt nur dann überprüfbar, wenn Formel, Einheit, Hierarchie, Maximum und Schwellenentscheidung erhalten bleiben.