Zusammenfassung
- RFC 827 erlaubte einem autonomen System ein privates internes Routingverfahren. Außerhalb musste weder dessen Code noch seine vollständige Topologie bekannt sein.
- EGP verwaltete Nachbarschaft und Erreichbarkeit, aber keine vertrauenswürdige gemeinsame Metrik, keinen vollständigen Pfad und keine Richtliniensprache. Die frühe Kern-und-Stummel-Struktur fing einen Teil dieser Lücke auf.
- Im vermaschten NSFNET ergänzten bilaterale Vertretungsabkommen, eine Policy-Datenbank, Filter und Betriebsalarme die fehlende Bedeutung.
- BGP ließ eine Folge autonomer Systeme mit der Route reisen. Damit konnten Teilnehmer Schleifen erkennen und lokal entscheiden, ohne eine AS-Nummer zu Eigentum oder Souveränität umzudeuten.
Freiheit innerhalb einer schmalen Grenze
RFC 827 beschrieb 1982 ein autonomes System als Gruppe von Gateways unter einer Verwaltung. Innerhalb dieser Grenze durfte ein privates Routingverfahren laufen. Nachbarn mussten es weder implementieren noch im Detail kennen.
BBNs Rolle in dieser Geschichte ist eine begrenzte Herkunftsangabe, kein Eigentumsanspruch. Eric Rosen verfasste RFC 827 bei BBN und stellte die erste formale Grenze aus dem Forschungs- und Auftragnehmerumfeld des DARPA-Gateway-Systems vor. Daraus folgt weder Eigentum BBNs am AS-Konzept noch am Internet; am späteren NSFNET-Betrieb und an BGP arbeiteten andere Institutionen mit.
Das begrenzte den Koordinationsbedarf. Ein Campus konnte interne Kosten ändern, ein Auftragnehmer ein Verfahren ersetzen und ein Backbone auf einen Fehler reagieren, ohne das gesamte Internet gleichzeitig umzubauen. Gemeinsam verständlich bleiben musste nur das Verhalten an der Außengrenze.
Die damalige Anordnung war trotzdem asymmetrisch. DARPA-Gateways an ARPANET und SATNET bildeten den Kern; andere Systeme hingen als Stummel daran und sollten keinen Transit zwischen Dritten übernehmen. Der Kern besaß eine besondere Sicht auf die erreichbaren Netze.
Im selben Dokument stand bereits die Gegenidee: Künftige autonome Systeme könnten gleichrangig sein, sodass keines als Kern tauge. Die Verwaltungsgrenze erwies sich als dauerhafter als die Topologie, die ihre Einführung erleichterte.
Erreichbarkeit ohne universelles Urteil
EGP war kein Algorithmus, der für das gesamte Internet die beste Route berechnete. Es tauschte Informationen aus, die Routingverfahren vermutlich benötigten. RFC 904 präzisierte Nachbarschaftsaufbau, Zustandsüberwachung, Abfragen und Erreichbarkeitsmeldungen.
Die absichtliche Beschränkung schützte Vielfalt. Sie ließ aber wichtige Entscheidungsgrundlagen außerhalb des Pakets. EGP-Distanzen waren nur zwischen Angaben desselben autonomen Systems vergleichbar. Zwei Verwaltungen konnten verschiedene Sachverhalte zählen; eine gemeinsam vertrauenswürdige Skala gab es nicht.
Auch die vollständige Folge durchquerter Systeme fehlte. Eine Meldung bewies weder die Berechtigung, ein Netz zu vertreten, noch den institutionellen Grund für Transit. RFC 975 bezeichnete EGP deshalb als Zwischenlösung für eine annähernd baumförmige Welt, in der konkurrierende Pfade und beliebige Schleifen begrenzt blieben.
Autonomie war als Grenze vorhanden. Die Beweisführung zwischen autonomen Akteuren war noch nicht ausreichend.
NSFNET machte aus Auslassungen Betriebsarbeit
Im neuen NSFNET-Backbone passte die Baumannahme nicht mehr. RFC 1092 nannte das alte Kernkonzept in einer vermaschten Umgebung unzureichend. Ein Gateway konnte Netze vertreten, für die es keinen Auftrag hatte. Eine seitliche Verbindung konnte einen unerwünschten Transitweg erzeugen.
Die Betreiber ergänzten EGP durch eine Ausführungskette außerhalb des Protokolls:
- Bilaterale Abkommen bestimmten, was ein Regionalnetz vertreten durfte.
- Eine Policy-Datenbank hielt diese Beziehungen fest.
- Kernrouter setzten daraus abgeleitete Filter ein.
- Das Network Operations Center meldete widersprüchliche Ankündigungen.
- Eindeutige AS-Nummern banden Nachrichten an erkennbare Routingverwaltungen.
Der Vertrag ordnete Verantwortung zu, die Datenbank machte sie maschinenlesbar, der Filter ermöglichte lokale Zurückweisung und der Alarm machte Abweichungen sichtbar. Die nicht codierte Policy verschwand nicht, sondern wechselte ihr Medium.
RFC 1093 dokumentierte unterschiedliche Vertrauensmodelle an den Grenzen. Manche Nachbarn durften nur eingetragene Netze melden; andere Beziehungen erforderten freiere Regeln, feste Metriken oder Unterdrückung. Ein gemeinsames Nachrichtenformat war keine gemeinsame Annahmepflicht.
Ein Netz bestraft verborgenes Wissen
In einem Baum kann „dieses Ziel ist erreichbar“ genügen, weil es kaum Alternativen gibt. In einer Vermaschung melden zwei Nachbarn dasselbe Ziel. Ihre Distanzen sind nicht systemübergreifend vergleichbar. Wiederholt einer die vom anderen gelernte Information, fehlt dem Empfänger der vollständige AS-Pfad, um sich selbst in der Schleife zu erkennen.
Der Kern verringerte Mehrdeutigkeit, indem er Kontext sammelte. Damit sammelte er auch die Macht, Beziehungen und Ausnahmen zu deuten. Ein technisches Startmittel drohte zu einer dauerhaften Instanz zu werden, wenn sein Wissen nicht übertragbar wurde.
RFC 1105 führte für das erste BGP eine Folge autonomer Systeme mit. Der Empfänger konnte daraus einen Graphen bilden, Routen mit der eigenen Nummer verwerfen und Regeln auf die im Pfad genannten Systeme anwenden.
Das ergab keine objektiv beste Route. Ein Betreiber konnte weiterhin Kunden bevorzugen, einen Transit meiden oder Verkehr ablehnen. BGP beseitigte Policy nicht; es lieferte ihr ein lokal auswertbares Pfadobjekt.
Tragbarer Kontext ist kein Eigentumsnachweis
Der AS-Pfad bewies weiterhin weder Ursprungsberechtigung noch Eigentum oder Ehrlichkeit. Fehlerhafte Konfiguration und falsche Angaben blieben möglich. Verträge, Register, Filter und Beobachtung wurden nicht überflüssig.
Der Fortschritt war enger: Ein Teil des zuvor im Kern gehaltenen Wissens begleitete nun die Route. Teilnehmer erhielten genug Kontext, um bestimmte Schleifen selbst zu erkennen und ihre eigene Annahmepolitik auszuführen. Der Kern verlor sein Privileg, weil seine Beweisfunktion teilweise tragbar wurde.
RFC 1930 fasste die AS-Grenze später über eine eindeutig abweichende externe Routingpolitik. Ohne solche Abweichung sollte keine eigene Nummer bloß aus Verwaltungsbequemlichkeit entstehen. Ein Unternehmen kann mehrere AS betreiben, mehrere Organisationen können an einer Betriebsstruktur beteiligt sein, und ein AS kann stark vom Upstream abhängen.
Die Nummer ist keine Urkunde, kein Hoheitsgebiet und keine juristische Person. Sie zeigt, welche Routingverwaltung für die an dieser Grenze gezeigte Policy einsteht. Eine größere Bedeutung erzeugt institutionelle Übermacht; eine kleinere löscht die für Verteilung nötige Verantwortlichkeit.
Quellen und Beweisgrenzen
- https://www.rfc-editor.org/rfc/rfc827.html
- https://www.rfc-editor.org/rfc/rfc904.html
- https://www.rfc-editor.org/rfc/rfc975.html
- https://www.rfc-editor.org/rfc/rfc1092.html
- https://www.rfc-editor.org/rfc/rfc1093.html
- https://www.rfc-editor.org/rfc/rfc1105.html
- https://www.rfc-editor.org/rfc/rfc1126.html
- https://www.rfc-editor.org/rfc/rfc1771.html
- https://www.rfc-editor.org/rfc/rfc1930.html
- https://www.rfc-editor.org/rfc/rfc5773.html
Diese RFCs belegen Entwürfe, Anforderungen und konkrete Betriebspraktiken, aber keine vollständige Einsatzstatistik. Die gleichrangige Zukunft in RFC 827 datiert nicht das Ende jeder Kernfunktion. Spätere Fähigkeiten von BGP-4 dürfen nicht in das Jahr 1982 zurückprojiziert werden.
Mitgliederbriefing
Detaillierter Profilkontext
Melden Sie sich mit der richtigen Mitgliedschaftsstufe an, um das vollständige Briefing und die Quellennotizen freizuschalten.
Nur für Strategic Circle
Strategic Circle
Offen für alle Leser. Schalten Sie Profil-Briefings nach Beitritt und Anmeldung frei.
Strategic Circle beitretenNur für Leadership Alliance
Leadership Alliance
Für qualifizierte Inhaber von IP-Assets und Management; melden Sie sich an, um Leadership-Alliance-Briefings freizuschalten.
Leadership Alliance beitreten
