Zusammenfassung

  • RFC 1887 behandelte Multihoming als Kostenverteilung: eine stabile unabhängige Adresse belastete die globale Routingtabelle, providergebundene Aggregation dagegen den Standort beim Wechsel.
  • RFC 2073 kodierte Registry ID, Provider ID und Subscriber ID; RFC 2374 ersetzte dieses Modell durch TLA/NLA/SLA, bevor RFC 3587 auch diese feste Struktur historisch machte.
  • Hierarchische Präfixe blieben. Dauerhafte institutionelle Rollen wurden jedoch aus dem Bitlayout in eine veränderbare Allokationspolitik zurückgenommen.

Der Vorteil entstand außerhalb des Standorts

RFC 1887 begann 1995 mit Reichweiteninformation. Wenn viele Standorte zusammenhängende Blöcke eines Providers nutzten, konnte dieser sie als ein Präfix ankündigen. Entfernte Router sparten Speicher, Austauschbandbreite und Rechenarbeit.

Die CIDR-Dokumente RFC 1518 und RFC 1519 hatten dieses Prinzip für IPv4 vorbereitet. Beliebige Präfixlängen ließen Adressierung der Topologie folgen. Auch 128 Bit machten den gemeinsamen Routingzustand nicht unbegrenzt.

RFC 1887 benannte den Konflikt als Effizienz gegen dezentrale Kontrolle. Allokation konnte verteilt werden; Aggregation setzte dennoch eine Beziehung zur tatsächlichen Verbindung voraus. Unternehmensgrenzen, Verwaltungsräume und physische Wege deckten sich nicht automatisch. Eine Ausnahme verschwand daher nie, sie erhielt nur einen Kostenträger.

Multihoming zeigte den Kostenträger

Ein providerunabhängiges Präfix gab der Organisation einen stabilen internen Plan. Außerhalb musste es jedoch als eigener Eintrag verbreitet werden, möglicherweise weltweit.

Ein Präfix je Provider ließ jeden Zugang sauber aggregieren. Fiel ein Anschluss aus, waren seine Adressen aber nicht automatisch über den anderen erreichbar. Änderte sich die externe Verbindung, mussten interne Adressen folgen. Zusätzliche Backup-Routen verringerten dieses Risiko und zugleich den Aggregationsgewinn.

Eine dritte Lösung wählte ein Hauptpräfix und verbreitete direkte Wege nur selektiv. Eine vierte gruppierte Kunden, die exakt dieselbe Providerkombination teilten. Alle vier verschoben Tabellenzustand, Koordination und Abhängigkeit.

RFC 1887 erklärte ausdrücklich, jede Variante lege andere reale, also finanzielle Kosten auf multihomed Organisationen und Transitdomänen — auch auf solche ohne direkte Beziehung. Die Entscheidung eines Providers, fremde Präfixe anzunehmen und weiterzugeben, war folglich Betriebspolitik mit Verteilungswirkung.

Die Verwaltungskette bekam Felder

RFC 2073 definierte 1997 nach einem dreibittigen Format Prefix eine fünf Bit lange Registry ID, anschließend Provider ID, Subscriber ID und einen 64-Bit-Innenbereich. IANA war Hauptregistry; Werte waren auch für RIPE NCC, INTERNIC und APNIC vorgesehen.

Registries strukturierten Provider- und Teilnehmerraum, Provider ihre Subscriber IDs und Teilnehmer den lokalen Bereich. Router interpretierten diese Amtsbezeichnungen jedoch nicht. Sie leiteten nach längster Präfixübereinstimmung weiter. Andere Unicast-Formate blieben möglich, ebenso direkt von einer Registry bezogener, providerunabhängiger Raum.

Ein Feld namens Provider belegte deshalb weder den heutigen Vertrag noch BGP-Ursprung, Eigentum oder Erreichbarkeit. Es belegte eine Position in einem damaligen Allokationsmodell.

Zuerst gingen die Registry-Bits

RFC 2374 löste RFC 2073 im Juli 1998 ab. Die Registry-Bits entfielen, weil sie für Aggregation nicht nötig waren. TLA, NLA und SLA trennten öffentliche Topologie, Standorttopologie und Interface Identifier.

Neben Provideraggregation sah der Entwurf Exchange-basierte Aggregation vor. Ein Standort könnte dadurch den Fernprovider wechseln und mehrere nutzen, ohne von jedem ein Präfix zu beziehen. Die Mechanismen für Auswahl und Portabilität blieben aber ausdrücklich außerhalb des Dokuments. Ein Platz im Diagramm war noch kein vollziehbarer Wechselprozess.

RFC 3587 machte 2003 RFC 2374 und TLA/NLA historisch. Eine koordinierte RIR-Allokationspolitik hatte die feste Struktur ersetzt. Das Dokument hielt sie in dieser Einsatzphase nicht zwingend für den technisch besten Ansatz und erwartete weitere politische Entwicklung.

Übrig blieb die allgemeine Form aus global routing prefix, subnet ID und interface ID. RIRs und ISPs konnten den globalen Teil weiter hierarchisch strukturieren, Standorte ihren Subnetzteil. Aggregation blieb Funktion; die feste Benennung äußerer Institutionen verschwand aus der dauerhaften Semantik.

Ein Verfahren macht den Wechsel nicht kostenlos

RFC 4192 beschrieb Renumbering als Make-before-break. Altes und neues Präfix koexistieren, während DNS, Routing und Konfiguration wechseln. Das vermeidet einen gemeinsamen Umschalttag, findet aber nicht jede Adresse in ACL, Monitoring, Zertifikat oder Anwendung.

RFC 4984 hielt fest, dass solche Abhängigkeiten Renumbering für manche Standorte praktisch unmöglich machten. PI-Raum vermied Providerbindung, erzeugte jedoch nicht aggregierbare globale Einträge. PA-Raum aggregierte beim Ursprungsprovider; die Ankündigung über einen anderen konnte Deaggregation erzwingen.

Der Bericht bezeichnete die Doppelrolle der IP-Adresse als Locator und Identifier als Grundproblem. Der Locator soll der Topologie folgen, der Identifier stabil bleiben. Ein Zahlenraum kann beide Wünsche nicht in jeder Lage gleichzeitig optimieren.

Auch die allgemeine /48-Empfehlung von RFC 3177 blieb nicht fest. RFC 6177 verwarf 2011 die Einheitsgröße und warnte davor, wenige Grenzen wie neue Adressklassen fest zu kodieren. Genügend Raum blieb Prinzip; die genaue Größe wurde wieder operative Entscheidung.

Welche Aussage welches Dokument trägt

Ein Allokationseintrag belegt eine Delegation unter einer datierten Politik. Eine BGP-Beobachtung belegt einen sichtbaren Ursprung an einem Messpunkt. Ein Vertrag belegt Pflichten. Paket- und Dienstprotokolle belegen Weg und Ergebnis. Dasselbe Präfix verbindet diese Aussagen, macht sie aber nicht austauschbar.

Die Folge der RFCs zeigt eine seltene Form institutioneller Disziplin: Das technische Ziel blieb messbar, während die organisatorische Umsetzung revidierbar blieb. Präfix, Allokationsquelle, Ursprung, Akzeptanzpolitik, Providervertrag, Renumbering-Abhängigkeit und Dienstresultat gehören in getrennte, verknüpfte Nachweise.

Routen dürfen komprimiert werden. Zuständigkeit nicht.

Quellen