Zusammenfassung

  • RFC 2260 behandelte Multihoming nicht als kostenlosen Zugewinn an Redundanz, sondern als Verteilungsproblem: Routenzustand, Renummerierung, Überwachung, Tunnel und Koordination können gegeneinander verschoben, aber nicht zugleich abgeschafft werden.
  • Im Normalzustand bleiben providerzugeteilte Präfixe aggregierbar. Erst beim Ausfall einer Verbindung kann ein zusätzliches, spezifischeres Präfix in die defaultfreie Zone gelangen; ein alternatives Verfahren hält diesen Zustand lokal, benötigt dafür jedoch nicht direktes EBGP und gekapselte Weiterleitung.
  • Eine BGP-Ankündigung belegt weder Annahme noch vollständige Verbreitung, Konvergenz, Weiterleitung oder Anwendungszustellung. RFC 2260 beschreibt Kontrollverfahren und erwartete Eigenschaften, keine gemessene Einführung oder garantierte Erreichbarkeit.

Die Rechnung hinter der Aggregation

Im Januar 1998 veröffentlichten Tony Bates und Yakov Rekhter RFC 2260 als informatorisches Dokument. Es war kein Internetstandard. Sein Gegenstand war dennoch ein Kernproblem der Internetarchitektur: Wie lässt sich ein Unternehmen mit mehreren Internetanbietern verbinden, ohne für jedes solche Unternehmen dauerhaft eine eigene Route in jedem Router der defaultfreien Zone zu hinterlegen? Das Dokument nennt höhere Zuverlässigkeit, Lastverteilung und möglicherweise bessere geografische Wege als Motive für mehrere Provider. Es misst aber keines dieser Ergebnisse.

Die Ausgangsannahme war knapp und folgenreich. Ein Verfahren, das jedem multihomed Unternehmen permanent eine unternehmensspezifische Route in der global sichtbaren Tabelle gibt, skaliert nicht hinreichend. Eine brauchbare Alternative sollte deshalb die Koordination klein halten – insbesondere zwischen Providern, die gar nicht direkt mit dem Unternehmen verbunden sind. Aggregation ist in dieser Perspektive kein Zaubertrick. Sie ist eine Entscheidung, den global sichtbaren Zustand zu verringern und dafür andere Komponenten stärker zu belasten.

RFC 2260 beginnt bei der Adressierung. Ein Unternehmen mit Verbindungen zu N Providern erhält N Präfixe, jeweils eines aus dem Adressraum des betreffenden Providers. Das folgt der im Dokument aufgegriffenen Adressverleihpolitik. Die interne Adressvergabe kann sich an der topologischen Nähe eines Knotens zu einem Providerübergang orientieren; ein Knoten kann eine Adresse aus einem Präfix oder mehrere Adressen aus mehreren Präfixen tragen. Damit wird Adressierung bereits zur Verkehrspolitik: Das gewählte Zielpräfix beeinflusst, über welchen Anschluss eingehender Verkehr natürlicherweise ankommt.

Diese Ordnung erhält Aggregation, bindet aber Teile der Unternehmensadressierung an den jeweiligen Provider. Wechselt das Unternehmen einen Anbieter, muss der Teil renummeriert werden, der dessen Adressblock verwendet. RFC 2260 stellt das als Folge des Adressverleihs dar, nicht als Sonderausnahme des Multihomings. Network Address Translation wird als möglicher Ansatz für Fragen der Zuteilung und Renummerierung erwähnt, doch NAT für multihomed Unternehmen liegt ausdrücklich außerhalb des Dokumentumfangs. Providerzugeteilter Raum wird dadurch nicht portabel.

Der ruhige Normalzustand und der laute Fehlerfall

Im Normalzustand kündigt ein Grenzrouter des Unternehmens einem direkt verbundenen ISP nur jenes Präfix an, das dieser ISP dem Unternehmen zugeteilt hat. Der Provider kann diese Route in seinem Aggregat aufgehen lassen. In der defaultfreien Zone muss kein separater Eintrag für das Unternehmen erscheinen. Die globale Tabelle bleibt ruhig, weil der spezifische Zustand dort nicht dauerhaft gebraucht wird.

Der Fehlerfall kehrt diese Ökonomie teilweise um. Erkennt ein Grenzrouter, dass die Erreichbarkeit über den anderen ISP ausgefallen ist, beginnt er, dessen providerzugeteiltes Präfix zusätzlich beim noch erreichbaren eigenen ISP anzukündigen. Für die Dauer des Ausfalls gelangt damit zusätzliche Routinginformation in die defaultfreie Zone. Nach der Wiederkehr der anderen Verbindung wird die zusätzliche Ankündigung zurückgezogen.

Im Zwei-Provider-Beispiel des RFC kündigt die Seite von ISP A zunächst nur Präfix A an, solange die über A und B gesehenen Routensätze eine nicht leere Schnittmenge haben. Wird diese Schnittmenge leer, kündigt der Router Präfix B auch an ISP A an. Sobald die Schnittmenge zurückkehrt, verschwindet die Zusatzankündigung wieder. Der Mechanismus macht aus einem Konnektivitätsurteil eine Änderung global sichtbaren Zustands.

Das Dokument erwartet, dass nicht alle multihomed Unternehmen gleichzeitig eine Providerverbindung verlieren. Daher solle die durchschnittliche Zahl zusätzlicher Routen nur einen Bruchteil der Zahl multihomed Unternehmen betragen. Das ist eine aus einer Annahme abgeleitete Erwartung, keine Messung. RFC 2260 liefert weder eine Route-Collector-Auswertung noch einen beobachteten Tabellenrückgang, weder eine Einsatzstatistik noch eine Ausfallverteilung.

Auch die Erkennung ist nicht kostenlos. Der Grenzrouter muss sowohl den Zustand des anderen Pfades als auch das dort zugeteilte Präfix kennen. Als Möglichkeit nennt das Dokument eine IBGP-Beziehung und den Vergleich erreichbarer Routensätze. Weil die Berechnung von Schnittmengen großer Routensätze teuer sein kann, schlägt es als praktischere Annäherung vor, ein oder mehrere ausgewählte Backbone-Präfixe des Providers zu beobachten. Verschwindet ein solches Präfix über IBGP, kann dies die Injektion des entfernten Providerpräfixes auslösen.

Diese Abkürzung verschiebt die Frage von „Ist das Internet erreichbar?“ zu „Ist ein gewählter Stellvertreter noch sichtbar?“. Ein verschwundenes Überwachungspräfix kann ein brauchbares Signal sein, ist aber kein Beweis für jede Zieladresse. Umgekehrt muss die Anwesenheit eines Signals nicht bedeuten, dass jede Datenebenenverbindung funktioniert. Hinzu kommt ein ausdrücklich genannter Filtervorbehalt: Präfixlängenfilter können verhindern, dass die injizierte spezifischere Route Internetweit nutzbare Erreichbarkeit erzeugt.

Eine Routenankündigung ist daher keine Empfangsbestätigung. Sie zeigt eine beabsichtigte Änderung der Kontrollinformation. Sie beweist nicht, dass ein Upstream die Route akzeptiert, dass weitere Netze sie weitergeben, dass die Router stabil konvergieren, dass Pakete dem erwarteten Pfad folgen oder dass eine Anwendung Daten erhält. Genau an dieser Trennlinie zwischen Kontrollaussage und Zustellergebnis liegt die wichtigste Evidenzdisziplin bei der Lektüre von RFC 2260.

Globaler Zustand oder lokale Maschinerie

Eine weitere Variante versucht, die ausfallbedingte spezifische Route ganz aus der defaultfreien Zone herauszuhalten. Ein Grenzrouter des Unternehmens unterhält dafür EBGP nicht nur mit dem direkt angeschlossenen Providerrouter, sondern auch mit einem Router des Providers, der am anderen Unternehmensrand angeschlossen ist. Der Provider kündigt über die direkte und die nicht direkte Sitzung denselben Routensatz an. Das Unternehmen kündigt jedem Provider weiterhin nur dessen eigenes zugeteiltes Präfix an. Auf beiden Seiten werden direkt gelernte Routen gegenüber nicht direkt gelernten bevorzugt.

Fällt im Beispiel die direkte Verbindung zwischen ISP B und dem Unternehmensrand aus, erreicht Verkehr für Präfix B weiterhin ISP B. Dort kann er zum überlebenden Unternehmensrand gekapselt, am Ziel des Tunnels entkapselt und intern weitergeleitet werden. RFC 2260 verweist für die Kapselung auf GRE aus RFC 1773. Der globale Vorteil ist klar beschrieben: Der Unternehmensausfall erzeugt keine zusätzliche unternehmensspezifische Route in der defaultfreien Zone, und ein Filter für ein injiziertes längeres Präfix kann diesen Weg nicht verhindern.

Doch auch hier verschwindet die Rechnung nicht. Sie liegt nun in Multi-Hop-EBGP-Sitzungen, Präferenzregeln, Kapselung, Tunnelendpunkten, innerbetrieblicher Weiterleitung und der nötigen Providerkooperation. Die Sicherheitsbetrachtung verlangt geeignete BGP-Peer-Authentifizierung für Multi-Hop-EBGP. Sicherheitsfragen für IBGP und Ein-Hop-EBGP lässt das Dokument außerhalb seines Umfangs. Ob Provider einer solchen Sitzung zustimmten, sie korrekt authentifizierten, den Tunnel installierten, die passenden Routen akzeptierten und den Betrieb dauerhaft beherrschten, wird nicht belegt.

Der lokale Mechanismus schützt die globale Tabelle außerdem nicht vor jeder anderen Art von Kosten. Nach einem Linkausfall kann der gekapselte Weg länger oder topologisch ungünstig sein. Der RFC bezeichnet dies als mögliche suboptimale Weiterleitung. Das ist der Preis dafür, Ausfallzustand lokal zu halten: Weniger globale Information kann bedeuten, dass das Netz nicht überall den direktesten Eingang wählen kann.

Optimierung mit begrenzter Sichtbarkeit

RFC 2260 kombiniert deshalb die Verfahren. Nicht direktes EBGP hält die Basiserreichbarkeit ohne zusätzliche globale Route aufrecht. Eine modifizierte automatische Injektion kann daneben spezifischere Routen verbreiten, deren Reichweite bewusst begrenzt wird. Eine BGP Community ist eine Möglichkeit, die Verteilung zu beschränken. Spätere offizielle Einordnung in RFC 2519 erläutert denselben größeren Zusammenhang: Aggregation reduziert Tabellengröße, Verarbeitungsaufwand und die Reichweite von Flaps, während spezifischere Information lokal bleiben oder mit no-export markiert werden kann.

Auch im ausfallfreien Zustand kann ausschließliches Ankündigen des direkt zugeteilten Präfixes zu ungünstigen Wegen führen. Kunden von ISP A können Verkehr zu Unternehmenssystemen, die aus dem Präfix von ISP B adressiert sind, zunächst in Richtung B senden, obwohl eine andere Eintrittsstelle näher läge. Das Unternehmen kann zusätzliche Providerpräfixe ankündigen, um die Eingangswege zu verbessern. Werden diese Ankündigungen aber schlecht begrenzt, erzeugen sie erheblichen Zusatzbestand in der defaultfreien Zone.

Hier liegt die eigentliche Kostenkurve des Dokuments. Breitere Sichtbarkeit kann bessere Eingangswahl oder raschere Ausweichpfade kaufen. Stärkere Aggregation kann den globalen Zustand kleiner halten. Beides zugleich verlangt mehr lokale Technik, Adressabhängigkeit, Providerabsprachen oder die Akzeptanz längerer Wege. Das Design entscheidet, wie weit ein Ausfall sichtbar wird und welche Akteure seine Folgen verarbeiten müssen.

Die im RFC verglichenen Alternativen bestätigen dieses Muster. Providerunabhängiger Adressraum gibt dem Unternehmen ein Präfix, das nicht von seinen ISPs abhängt. Seine unternehmensspezifische Route lässt sich jedoch nicht in einem Providerpräfix aggregieren; RFC 2260 beschreibt den Aufwand in der defaultfreien Zone als O(N) in der Zahl multihomed Unternehmen. Ein einzelnes Präfix eines Providers, das andere Provider selektiv tragen, verlangt Proxy-Aggregation, zusätzliche Koordination zwischen ISPs und komplexere Routerkonfiguration.

Automatische Routeninjektion verteilt Ausfalländerungen an jeden defaultfreien Router, der die spezifischere Route empfängt, und benötigt Schutz gegen instabile Flaps. Nicht direktes EBGP hält solche Flaps lokal, verlangt dafür aber andere Betriebsmaschinerie.

Spätere RFCs verändern diese historische Aussage nicht, sondern schärfen ihre Grenzen. RFC 4116 ordnet den RFC-2260-Ansatz als Multihoming mit provideraggregierbaren Adressen ein, das in seiner Grundform die globale Tabelle nicht zusätzlich belastet. Zugleich erfüllt es nicht jedes typische Multihomingziel, insbesondere nicht automatisch das Überleben von Transportsitzungen. RFC 8678 beschreibt 2019 für den behandelten IPv6-Kontext, dass providerzugeteiltes Multihoming PI-Routen in der globalen Tabelle vermeiden kann, Hosts und Router aber Quelladress- und Ausgangswahl koordinieren müssen.

Es bezeichnet das Problem in diesem Kontext weiterhin als ohne klar definierte, breit implementierte Lösung. Diese spätere Sicht ist Einordnung, kein Beleg dafür, dass die Mechanismen von RFC 2260 eingesetzt wurden oder dass spätere Verfahren bereits 1998 Teil seines Entwurfs waren.

RFC 2260 gilt laut eigener Aussage für IPv4 und IPv6. Das ist eine architektonische Reichweitenbehauptung, kein Nachweis gleicher Implementierung, Einführung oder Betriebserfahrung in beiden Protokollwelten. Ebenso wenig enthält das Dokument einen benannten Betreiber, ein konkretes Präfix, eine beobachtete Störung oder eine gemessene Veränderung der Routingtabelle. Es sagt, wie Zustand verteilt werden könnte. Es sagt nicht, dass die Welt diesen Zustand so verteilt hat.