Zusammenfassung

  • RFC 5492 lässt BGP-Speaker optionale Fähigkeiten im OPEN auflisten. Eine Fähigkeit darf auf dem Peering nur verwendet werden, wenn beide Seiten sie angekündigt haben. Eine empfangene unbekannte Fähigkeit muss ignoriert werden; fehlt dagegen eine für den lokalen Zweck notwendige Fähigkeit, kann eine NOTIFICATION den Grund nennen und die Sitzung beenden.
  • John Scudders dokumentierte Autorschaft reicht bis RFC 8810, der einen verwirrenden privaten Coderaum neu ordnet, und RFC 9072 mit Enke Chen, der die 255-Oktett-Grenze der OPEN-Parameter erweitert. Protokollwachstum braucht beidseitige Evidenz, eindeutige Namen und einen ehrlichen Punkt, an dem ein alter Parser nicht mehr mithalten kann.

Die Verbindung stand, der gemeinsame Funktionsumfang noch nicht

BGP tauscht OPEN aus, bevor eine Route übertragen wird. Link, IP und TCP können fehlerfrei sein, während die Sitzung ihren vorgesehenen Auftrag nicht erfüllen kann. Die Differenz liegt dann nicht im Transport, sondern in den optionalen Regeln, zu denen sich beide Router gegenüber diesem Nachbarn erklärt haben.

Das von RFC 5492 beschriebene Grundverhalten beendete ein Peering bei einem unbekannten Optional Parameter. Das verhinderte improvisierte Interpretation, machte Erweiterungen aber teuer: Ein neues Parameterformat konnte auch den alten, weiterhin verständlichen Routenaustausch mitreißen.

Capability Advertisement begrenzt die Wirkung. OPEN trägt einen bekannten Capabilities Optional Parameter, in dem einzelne Erweiterungen stehen. Der Empfänger kann den Container verstehen und nur die unbekannte Fähigkeit ignorieren. Er behauptet nicht, sie zu beherrschen, muss aber den gemeinsamen Rest nicht aufgeben.

John Scudder und Ravi Chandra sind die Autoren von RFC 5492. Scudder verfasste RFC 8810 zur Registrierung von Capability Codes und schrieb mit Enke Chen RFC 9072 zur erweiterten Länge der OPEN-Parameter. Das IETF-Datatracker-Profil verbindet diese Dokumente mit seiner öffentlichen Routing-Arbeit und stellt das Referenzfoto bereit.

Die Zuschreibung bleibt begrenzt. Es sind gemeinsam geprüfte IETF-Dokumente mit Koautoren, Working Group, IANA, Implementierern und Betreibern. Eine Autorenzeile belegt Beteiligung, nicht Alleineigentum an BGP oder Verantwortung für ein Produkt und ein Betriebsergebnis.

Drei Felder tragen nur den gemeinsamen Mindestvertrag

Eine Capability besteht aus Capability Code, Capability Length und Capability Value. Code und Length sind jeweils ein Oktett groß; der variable Value wird nach der Spezifikation des Codes interpretiert.

Der Container ist absichtlich dünn. Er macht Identität und Grenze lesbar, ohne alle künftigen Erweiterungen zentral vorwegzunehmen. Erlaubt eine Fähigkeit mehrere Werte oder Instanzen, muss ihr eigenes Dokument die Verarbeitung definieren. Unabhängige Implementierungen teilen das Format und behalten Gestaltungsspielraum im Inhalt.

Korrekte Syntax ist kein Vertrauensbeweis. Ein registrierter Code verweist auf gemeinsame Semantik, authentisiert aber keinen Peer. Eine richtige Länge schützt den Parser, bestätigt aber nicht die Implementierung des Values. Selbst ein sauber dekodierter Wert beweist nicht, dass der Betreiber die Funktion für diesen Nachbarn zulässt.

RFC 5492 empfiehlt einen einzigen Capabilities Optional Parameter mit mehreren TLVs. Aus Kompatibilitätsgründen muss ein Empfänger mehrere solcher Parameter akzeptieren und die vereinigte Menge gleich behandeln. Identische Duplikate fügen keine Bedeutung hinzu, dürfen den Parser aber nicht brechen. Der öffentliche Vertrag ist die beobachtbare Semantik, nicht genau die Bytereihenfolge eines Herstellers.

Eine Anzeige ist keine einseitige Aktivierung

Eine Fähigkeit kann nur dann auf dem Peering verwendet werden, wenn beide Speaker sie angezeigt haben. Fehlt sie auf einer Seite, darf sie in dieser Sitzung nicht eingesetzt werden.

Das ist genauer als ein Versionsvergleich. Software kann eine Funktion enthalten und sie für einen bestimmten Nachbarn, eine Adressfamilie oder Rolle deaktivieren. OPEN dokumentiert, was das laufende System diesem konkreten Peer zu diesem Zeitpunkt erklärt hat.

Die Regel verhindert auch einseitige Macht. Ein Sender kann Schweigen nicht als Zustimmung behandeln. IANA vergibt eine eindeutige Nummer; der RFC definiert Verhalten; der Hersteller implementiert; der Betreiber konfiguriert. Keine dieser Handlungen aktiviert allein die Funktion zwischen zwei Endpunkten.

Werte und Richtung bleiben wichtig. Capabilities können asymmetrische oder rollenspezifische Bedeutung haben. Ein zusammengeführtes supported-Feld löscht, welcher Peer welche Aussage gemacht hat.

Unbekanntes wird ignoriert, Fehlendes kann zwingend sein

Empfängt ein Speaker eine Capability, die er nicht kennt oder unterstützt, muss er sie ignorieren. Er darf deshalb weder Unsupported Capability senden noch die Sitzung beenden.

Das ist der Kern schrittweiser Einführung. Alte Software täuscht kein Verständnis vor; die neue Anzeige erhält aber auch kein Vetorecht über die gemeinsame Basis. Das Unbekannte bleibt lokal ohne Wirkung.

Der Gegenfall betrifft eine lokale Anforderung. Eine Sitzung kann für eine Funktion vorgesehen sein, die ohne eine bestimmte Capability nicht existiert. Hat der Peer sie nicht angezeigt, darf der lokale Speaker Unsupported Capability senden und beenden. Die NOTIFICATION muss die Capability oder Capabilities nennen, deren Fehlen die Entscheidung ausgelöst hat.

Ob etwas zwingend ist, entscheidet die lokale Seite. RFC 5492 empfiehlt, ein so beendetes Peering nicht automatisch neu aufzubauen. Ein erneuter OPEN-Austausch mit unveränderter Software, Konfiguration und Anforderung wiederholt nur denselben Beweis.

Darum brauchen zwei ähnlich klingende Zustände gegensätzliche Reaktionen. „Der Peer nennt etwas, das ich nicht kenne“ schützt den gemeinsamen Dienst. „Der Peer nennt nicht, was mein Auftrag verlangt“ kann ihn verhindern. Eine generische Mismatch-Meldung verschleiert die richtige Maßnahme.

Legacy-Fallback stellt BGP her, nicht unbedingt den Auftrag

Ein noch älterer Speaker kann bereits den Capabilities Optional Parameter ablehnen und Unsupported Optional Parameter senden. RFC 5492 empfiehlt dann einen neuen Versuch ohne diesen Container.

Das schafft eine Brücke zum Basis-BGP. Reicht einfacher IPv4-Austausch, kann die Degradierung sinnvoll sein. War eine andere Adressfamilie oder Erweiterung beauftragt, ist Established keine Erfolgsmeldung für den Dienst.

Die Betriebsakte muss ersten OPEN, Ablehnung, zweiten reduzierten OPEN, verlorene Fähigkeiten, aktive Familien und tatsächlich empfangene Routen verbinden. Wer nur den letzten grünen Zustand speichert, erklärt eine Degradierung zur Reparatur.

Rückwärtskompatibilität bewahrt die gemeinsame Teilmenge, wenn sie genügt. Sie zwingt neue Anforderungen nicht dauerhaft auf den kleinsten Nenner eines alten Peers.

Private Codes werden beim Zusammentreffen öffentliches Konfliktmaterial

RFC 5492 wies 128–255 zunächst Private Use zu. RFC 8810 hält fest, dass diese Einteilung in der Praxis nutzlos und für Implementierer aktiv verwirrend war.

Zwei Hersteller können im geschlossenen Labor dieselbe Nummer für verschiedene Funktionen verwenden. Treffen ihre Produkte aufeinander, reist der private Kontext nicht mit. Beide lesen denselben Code und verbinden ihn mit anderer Bedeutung. Der Kompatibilitätsdatensatz erzeugt eine falsche Übereinstimmung.

RFC 8810 belässt 1–63 bei IETF Review, ordnet 64–238 First Come First Served zu, reserviert 239–254 für Experimental Use und 255 als Reserved. Experimentelle Codes sollen nicht dauerhaft und nicht in ausgelieferten Produkten verwendet werden.

Das Register übernimmt eine enge Aufgabe: Eindeutigkeit und Referenz. Es befiehlt keine Aktivierung, zertifiziert keine Implementierung und bewertet nicht den Geschäftsnutzen.

Auch die Bereinigung anerkennt Grenzen. Eine Erhebung suchte bekannte private Verwendungen und trug mehrere vorstandardisierte Werte ein. Das Dokument garantiert nicht, alles gefunden zu haben. Verbleibende Kollisionen müssen als reale Abweichungen entdeckt und behandelt werden.

Auch der Umschlag für Erweiterungen wurde zu klein

Optional Parameters Length in OPEN war ein Oktett breit und begrenzte das gesamte Feld auf 255 Oktette. Mit wachsender Capability-Zahl erreichte der Mechanismus zur Beschreibung der Zukunft seine eigene Grenze.

RFC 9072 verwendet bei höchstens 255 normalerweise weiter das Basisformat. Darüber markiert Typ 255 die erweiterte Form, gefolgt von einer zwei Oktett breiten Gesamtlänge; auch die Länge jedes Optional Parameter wird zwei Oktett breit. Neue Implementierungen müssen die erweiterte Form selbst bei kleinen Inhalten akzeptieren.

Kompatibilität mit einem alten Peer hängt von der tatsächlichen Größe ab. Solange der neue OPEN in das alte Format passt, besteht an dieser Stelle kein Problem. Benötigt er mehr als 255, muss die neue Form gesendet werden. Der alte Peer sieht Typ 255 als unbekannt und sollte mit Unsupported Optional Parameters schließen.

Dieser Abbruch ist ehrlicher als stilles Abschneiden. Sonst könnten beide Seiten verschiedene Capability-Mengen annehmen und die Sitzung dennoch für gültig halten. Rückwärtskompatibilität erhält das Verständliche, sie erfindet keine Parserkapazität.

RFC 9072 ändert außerdem weder Sicherheits- noch Vertraulichkeitsprobleme von BGP. Mehr Platz macht die Erklärung nicht authentisch.

Der gemeinsame Mindeststandard bleibt dem laufenden Netz rechenschaftspflichtig

Lu Hengs späterer Text Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption bietet Sofia Ren eine analytische Linse. Gemeinsam nötig sind interpretierbarer Container, eindeutige Codes, beidseitige Bedingung, begrenzte Fehler und erweiterbare Länge. Die genaue Fähigkeit und die lokale Pflichtentscheidung bleiben bei denen, die Folgen tragen.

Das ist eine redaktionelle Anwendung von 2026, kein Beweis privater Absichten von Scudder, Chandra, Chen oder dem IETF. Normativ bleiben die RFC-Texte.

Running-Code Primacy liefert die Gegenprobe. OPEN ist stärker als ein Datenblatt, weil zwei laufende Router ihre tatsächliche Erklärung austauschen. Es beweist noch nicht den Effekt. Aushandlungszustand, Nachrichten, Routen, Fehler, Wiederherstellung und Weiterleitung müssen folgen.

Capability Advertisement braucht keine Zentrale, die jede BGP-Erweiterung anordnet. Es braucht eindeutige Namen, zwei getrennte Aussagen und die Disziplin, Unbekanntes nicht mit Falschem gleichzusetzen. So kann Neues freiwillig eintreten, während das Ende der Verständigung sichtbar bleibt.

Quellen