Zusammenfassung

  • RFC 8654 erhöht die maximale Größe von BGP-Nachrichten außer OPEN und KEEPALIVE von 4.096 auf 65.535 Oktette, erlaubt den Versand aber nur an einen Peer, der Fähigkeit 6 angekündigt hat.
  • Die Fähigkeit ist eine Empfangszusage pro Sitzung, keine netzweite Erlaubnis; gemischte Unterstützung kann Attributverwerfung, Zurückhalten oder Rückzug einer Route erzwingen.

Der größere Umschlag beginnt mit einer bilateralen Zusage

RFC 4271 setzt den Ausgangspunkt: Eine BGP-Nachricht wird erst nach vollständigem Empfang verarbeitet und darf höchstens 4.096 Oktette groß sein. RFC 8654 hebt die Grenze für neue Adressfamilien und Funktionen auf 65.535 Oktette an, ausgenommen OPEN und KEEPALIVE.

Die Steuerung liegt nicht in der Zahl, sondern in der Aushandlung. Ein Sprecher, der erweiterte Nachrichten empfangen kann, SHOULD diese Fähigkeit über RFC 5492 ankündigen. IANA führt sie als Fähigkeit 6. Ein Sender MAY eine erweiterte Nachricht nur dann schicken, wenn er die Fähigkeit vom Peer dieser Sitzung erhalten hat.

Die Ankündigung begründet eine echte Pflicht: Die Implementierung MUST Nachrichten bis einschließlich 65.535 Oktette empfangen können. Umgekehrt MUST ein technisch fähiger, aber so konfigurierter Sprecher, der die Fähigkeit nicht angekündigt hat, eine erweiterte Nachricht zurückweisen. Technische Fähigkeit ersetzt keine konfigurierte Sitzungsgrenze.

RFC 8654 setzt außerdem eine eigenständige Ausgangsgrenze: Eine NOTIFICATION an einen Peer, der die Fähigkeit nicht angekündigt hat, MUST NOT größer als 4.096 Oktette sein.

Die Kapazität einer Kante gilt nicht für die nächste

Ein UPDATE über 4.096 Oktette kann von einem fähigen Peer eintreffen und anschließend zu einem Nachbarn ohne Ankündigung weiterlaufen sollen. Die erste Sitzung hat den Empfang erlaubt; über die zweite hat sie nichts entschieden.

RFC 8654 sagt, der Vermittler SHOULD die Ausgabe verkleinern, indem er nur Attribute entfernt, die nach RFC 7606 für „attribute discard“ geeignet sind. Diese Attribute dürfen Auswahl oder Installation der Route nicht beeinflussen. Bleibt das UPDATE zu groß, darf es nicht gesendet werden. Wurde das NLRI vorher angekündigt, muss es gegenüber diesem Nachbarn aus dem Dienst zurückgezogen werden.

Nutznießer kann eine Anwendung sein, die mehr Attribute oder NLRI transportiert. Die Kosten können beim nächsten Peer und bei den Nutzern einer Route liegen, die sich nicht mehr über die 4.096-Oktett-Grenze zum folgenden Peer übertragen lässt. Darstellungsraum wird so zur Weiterleitungs- und Erreichbarkeitsentscheidung.

Interne Konsistenz wird zur Führungsaufgabe

RFC 8654 garantiert eine konsistente Sicht im autonomen System nur, wenn alle iBGP-Sprecher die Fähigkeit ankündigen. Andernfalls sollte der Betreiber erwägen, ob sie extern überhaupt angekündigt werden soll.

Eine verantwortliche Reihenfolge inventarisiert Fähigkeiten je Sitzung, testet Empfang und Parser mit Maximalgröße, misst Pufferreserven, identifiziert interne und externe Grenzen und beobachtet verworfene Routen und Attribute während der schrittweisen Einführung. Erst danach folgt die externe Freigabe.

Die Erweiterung behebt keine grundlegenden BGP-Sicherheitsprobleme. Größere Puffer können die absichtliche oder unbeabsichtigte Ressourcenerschöpfung begünstigen. Der Empfang der Fähigkeit beweist weder Routenlegitimität noch sichere Inhalte, sondern nur erklärte Empfangskapazität.

Belege und Grenzen

RFC 8654 definiert Größe, Ausnahmen, Aushandlung und Mischgrenzen. RFC 4271 liefert das ursprüngliche Maximum. RFC 5492 beschreibt Fähigkeitsankündigungen, RFC 7606 grenzt Attributverwerfung ein und IANA bestätigt Code 6.

Die Quellen nennen keine heutigen Netze mit Aktivierung, keinen universellen Speicheraufwand und keine Garantie, dass Verwerfung jedes UPDATE passend macht. Macht, Autorisierung, Nutznießer, Kosten und Gegenfaktum sind analytische Ableitungen.

Quellen