Zusammenfassung

  • RFC 9072 nutzt den optionalen Parametertyp 255 und eine erweiterte Zwei-Oktett-Länge, damit ein BGP OPEN mehr als 255 Oktette optionale Parameter tragen kann.
  • Die größere Hülle ist keine pauschale Capability-Freigabe. Ein Peer ohne Verständnis der Erweiterung lehnt sie ab; der Grenzübertritt braucht daher belegte Interoperabilität.

Die ursprüngliche Grenze wird gemeinsam verbraucht

Das OPEN legt die Bedingungen fest, unter denen zwei BGP-Sprecher eine Sitzung aufbauen. Capabilities liegen in optionalen Parametern, doch RFC 4271 sieht für deren gesamte Länge nur ein Oktett vor. Die vollständige Codierung muss in 255 Oktette passen.

Die Einschränkung kann lange unsichtbar bleiben. Jede neue Fähigkeit ist klein und jede lokale Entscheidung wirkt eigenständig. Trotzdem kann eine Sammlung einzeln gültiger Funktionen im Grundformat unabbildbar werden, ohne dass eine davon fehlerhaft wäre.

RFC 9072 ändert die Hülle. Typ 255 signalisiert das erweiterte Format; danach folgt eine Zwei-Oktett-Gesamtlänge, und auch jeder Parameter erhält zwei Oktette für seine Länge. Die Codierungskapazität wächst, die Bedeutung der Fähigkeiten nicht.

Mehr Raum bedeutet nicht mehr Macht über den Nachbarn. Der Sender darf ein größeres Paket anbieten; der Empfänger entscheidet weiterhin, welche Syntax und Fähigkeiten er unterstützt. Der erfolgreiche Sitzungsaufbau ist der beobachtbare Beleg, dass beide Seiten die Verhandlung verarbeiten konnten.

Typ 255 öffnet die Hülle und legt die Grenze offen

Im erweiterten Format sollte das alte Längenfeld 255 sein und darf nie null sein. Das folgende Oktett an der Stelle eines normalen Typs muss ebenfalls 255 sein. So erkennt ein kompatibler Peer die erweiterte Länge und die anschließende Folge.

Bis 255 Oktette sollte das Grundformat verwendet werden. Eine Konfiguration darf das erweiterte Format zum Test erzwingen, und eine konforme Implementierung muss es auch für kurze Inhalte akzeptieren. Oberhalb der Grenze ist es zwingend.

Dieser Übergang ist der eigentliche Kontrollpunkt. Unterhalb bleibt ein Grundformat als Rückweg, während der neue Parser getestet wird. Oberhalb gibt es für dasselbe Paket keine alte Darstellung: Der Peer akzeptiert die Erweiterung, der Sender entfernt Fähigkeiten oder die Sitzung scheitert.

Rückwärtskompatibilität scheitert sichtbar. Ein Peer ohne RFC 9072 soll Typ 255 als unbekannten optionalen Parameter behandeln und die Verbindung mit Unsupported Optional Parameters schließen. Typ 255 an anderer Stelle ist ebenfalls unbekannt. Inkompatibilität wird nicht still umgedeutet.

Capability-Wachstum wird zum gemeinsamen Budget

Nutznießer sind Netze, deren legitimes Paket nicht mehr in die ursprüngliche Hülle passt. Sie müssen erforderliche Funktionen nicht nur wegen eines zu kurzen Längenfelds streichen. Die Kosten wandern jedoch in die Koordination.

Jede Fähigkeit verbraucht bis zur Umstellung einen Teil eines gemeinsamen OPEN-Budgets. Das Team, das eine Funktion einschaltet, betreibt womöglich nicht die externe Peer-Beziehung, die mit den letzten Oktetten die Grenze überschreitet. Ohne gemeinsames Inventar kann eine Routineänderung die Erweiterung erzwingen und alte Software am anderen Ende sichtbar machen.

Das erzwungene Testen unterhalb der Grenze trennt Parser-Reife vom Kapazitätsdruck. Belege sollten genaue OPEN-Länge, Format, Peer-Software, Fehler und Änderungen am Capability-Paket bei Wiederholungen enthalten.

Die Erweiterung authentifiziert keinen Nachbarn, schützt das OPEN nicht, prüft keine Richtlinie und garantiert keine spätere UPDATE-Verarbeitung. RFC 9072 verändert die Sicherheits- und Vertraulichkeitsprobleme von BGP nicht. Eine größere Hülle ist kein Nachweis umfassender Bereitschaft.

Evidenz und Grenzen

RFC 9072 belegt den Indikator 255, Zwei-Oktett-Längen, Auswahlregeln und das erwartete Verhalten alter Peers. RFC 4271 liefert das OPEN-Modell, RFC 5492 den Capability-Rahmen, IANA die Registrierung und RFC 4272 den Sicherheitskontext. Die Deutung als Governance-Budget ist Analyse.

Die Quellen belegen keine Einführung bei einem genannten Betreiber oder Hersteller, beziffern inkompatible Peers nicht und nennen keine allgemeine Capability-Anzahl bis zur Grenze. Ein erfolgreiches OPEN beweist Parser-Kompatibilität, nicht korrekte Richtlinien, Routenauswahl oder spätere UPDATEs.

Quellen