Zusammenfassung

  • RFC 8092 stellt drei 32-Bit-Felder bereit und löst damit das Platzproblem vier Oktett großer ASNs. Es signiert den Wert nicht, schützt ihn nicht Ende-zu-Ende und belegt nicht, dass das links genannte AS ihn geschrieben hat.
  • Operative Autorität entsteht erst, wenn die empfangende Policy Nachbar, Beziehung, Funktion und Parameter einer Änderung zuordnet. Belastbare Evidenz reicht vom rohen UPDATE über Autorisierung und RIBs bis zu FIB und Paketen.
  • Eine sichere Grenze entfernt unbefugte Befehle im eigenen Namespace, erhält sinnvollen fremden Kontext, trennt Information von Aktion und malformed von unauthorized, definiert Set- und Aggregationsregeln und rollt auch Routenzustand zurück.

Drei Empfänger, ein identischer Wert

Ein fiktiver multihomed Kunde, AS 4200004100, ist an zwei Transitprovider und einen IXP Route Server angeschlossen. Provider A veröffentlicht zwei Large-Community-Funktionen: LOCAL_PREF in einer Region absenken und Export zu einer Peer-Klasse unterbinden. Der Kunde markiert ein ungefährliches Präfix, um Verkehr von einer überlasteten Leitung wegzuführen.

Bei Provider A identifiziert der Import die Sitzung als vertraglich zugelassenen Kunden. Er prüft beide Funktionen und ihre Parameter. Das Adj-RIB-In hält die empfangenen Werte fest; ein Policy-Trace nennt Autorisierung, Regel und Wörterbuchversion. Loc-RIB und Adj-RIB-Out zeigen die begrenzte Entscheidung, FIB und Messpakete den Verkehrswechsel.

Provider B hat nur einen Teil seiner Migration beendet. Die Edge-Software kann Large Communities parsen, doch ein älterer Import-Regelsatz löscht das Attribut vor der gemeinsamen Policy. Die Session bleibt Established, die Präfixzahl wirkt normal und die Route erreichbar. Nur der Auftrag verschwindet. Ein Dashboard für Nachbarstatus meldet keinen Fehler.

Provider C akzeptiert den Wert zu bereitwillig. Seine Policy matcht den eigenen Global Administrator, ohne zuvor die erlaubte Session-Klasse zu prüfen. Ein Peer oder Downstream kann dasselbe syntaktisch korrekte Tripel setzen und eine interne Funktion erreichen. Das Format wurde nicht gefälscht; der Empfänger hat seinen Berechtigungsrand ausgelassen.

Alle drei Implementierungen können behaupten, RFC 8092 zu unterstützen. Nur die erste beweist Transport, Principal, Recht, Bedeutung, Ausführung und Wirkung getrennt. Unterstützung ist eine Fähigkeit, keine Governance-Aussage.

Das Platzproblem hinter den zwölf Oktetten

Die Communities aus RFC 1997 sind vier Oktett groß. Operative Konvention teilte sie oft in zwei 16-Bit-Werte und las sie als ASN:lokaler Wert. Ein vier Oktett großes ASN passt jedoch nicht in die linke Hälfte.

Extended Communities bringen Typisierung und acht Oktett. RFC 5668 definiert eine Form für vier Oktett große ASNs, doch ihr Global Administrator beansprucht vier Oktett und lässt dem Local Administrator zwei. Für die vorgesehenen typisierten Zwecke genügt das, nicht für ASN, Funktion und Parameter in voller Breite.

RFC 8092 verwendet Global Administrator, Local Data Part 1 und Local Data Part 2 mit jeweils vier Oktett. IANA weist dem Path Attribute type code 32 zu. RFC 8195 schlägt die lesbare Konvention ASN:Funktion:Parameter vor.

Die Standards definieren kein globales Funktionsregister. Jedes Netz kann Eintrittsort, Beziehung, Exportwunsch oder Präferenz anders codieren. Diese minimale Ausgangsspezifikation lässt freiwillige Adoption und lokale Weiterentwicklung zu. Gerade deshalb hat das Format keine eingebaute Befehlsgewalt. Bedeutung wird veröffentlicht; Wirkung wird durch laufende Policy erzeugt.

Namensinhaber und Urheber sind verschiedene Rollen

RFC 8092 empfiehlt ein ASN als Global Administrator. Dessen Inhaber definiert dann die Interpretation der beiden lokalen Felder. Damit besitzt er einen Definitionsraum, aber keine kryptografische Urheberschaft an jedem Vorkommen.

64497:9:3 beweist nicht, dass AS 64497 den Wert hinzugefügt hat. Origin, Zwischen-AS oder unmittelbarer Nachbar kommen infrage. Ein intermediäres AS darf Werte hinzufügen, löschen oder verändern; Integrität wird vom Attribut nicht geschützt.

Auch reservierte Zahlen lösen die Autorisierungsfrage nicht. Von 0, 65535 und 4294967295 als Global Administrator wird abgeraten, doch ein reservierter oder nicht zugewiesener Wert ist nicht automatisch malformed. Parser, semantisches Wörterbuch und Senderberechtigung beantworten drei eigenständige Fragen.

Session-Schutz kann den Peer des aktuellen Hops identifizieren. Er attestiert keinen ersten Schreiber über mehrere AS hinweg. RPKI Origin Validation bindet Präfix und Origin-AS nach vorhandenem ROA; sie validiert weder Community-Autorenschaft noch das Recht, LOCAL_PREF in einem fremden Netz zu beeinflussen.

Derselbe Container trägt Beobachtung und Befehl

RFC 8195 unterscheidet informative und Action Communities. Information kann Eintrittspunkt, Beziehung oder gewünschtes Publikum beschreiben. Action verlangt eine Änderung an Verbreitung, LOCAL_PREF, Next-Hop oder AS_PATH-Prepending.

Das Bitmuster enthält diese Risikoklasse nicht. Wörterbuch und Policy legen sie fest. Ist das Wörterbuch veraltet oder auf Plattformen uneinheitlich, kann dasselbe Tripel auf einem Router Telemetrie und auf einem anderen ausführbarer Input sein.

Informations- und Aktionsbereiche sollten getrennt werden. Jede Aktion braucht Owner, erlaubte Senderklassen, Parameterdomäne, Konfliktvorrang, AFI/SAFI, Ablauf und Rollback. „Region 3“ muss eine bekannte Menge von Edges sein; Prepend-Zahlen brauchen Grenzen; eine Kundenberechtigung darf nicht durch ein gemeinsames Konfigurationsfragment an Peers vererbt werden.

RFC 8195 ermutigt Netze, unterstützte oder sichtbare Bedeutungen zu veröffentlichen. Das schafft eine Spezifikationsschicht. Welche Version wirklich geladen ist, welche Route eintraf, welche Clause matchte und welcher Pfad sich änderte, gehört zur Ausführungsschicht.

Eigene Befehle scrubben, fremden Kontext bewahren

RFC 7454 empfiehlt, inbound Communities mit der eigenen AS-Nummer zu scrubben und nur Signale zuzulassen, die dieser Kunde oder Peer verwenden darf. Andere Communities sollen nicht pauschal gelöscht werden, weil Kunden sie für weiter entfernte Netze benötigen können.

Für Large Communities entstehen mindestens vier Klassen: autorisierte Actions im lokalen Namespace; lokale Informationswerte, die vertraglich akzeptiert oder selbst gesetzt werden; opake fremde Werte, die transitiv bleiben sollen; sowie unbefugte, veraltete, für die Beziehung unsinnige oder in Kombination gefährliche Werte.

Alles zu erhalten lässt Outsider provider-eigene Befehle synthetisieren. Alles zu löschen zerstört legitime Koordination. Ein Set beim Hinzufügen einer lokalen Markierung vollständig zu ersetzen vernichtet frühere Provenienz. Additives Setzen bewahrt sie, verlangt aber explizite Bereinigung alter und widersprüchlicher Werte.

Route Server sind eine gewollte Sonderform. RFC 7948 beschreibt, wie Clients Exporte pro Empfänger steuern können. RFC 8195 nennt announce-to-all, announce-to-none und Ausnahmen. Dort ist der externe Einfluss auf Adj-RIB-Out Teil des Dienstes. Trotzdem muss der Betreiber die Client-Session binden, zulässige Funktionen begrenzen, Konflikte lösen und jeden Ausgang belegen. Diese Broker-Ausnahme gehört nicht ungeprüft in gewöhnliche Transit-Regelsätze.

Ein Set kennt keinen ersten Befehl

Large Communities bilden laut RFC 8092 eine ungeordnete Menge. Die Encoding-Reihenfolge ist bedeutungslos. „Der erste Wert gewinnt“ macht aus einem Implementierungsdetail eine Protokollpriorität.

Duplikate sollen nicht gesendet und beim Empfang still entfernt werden. Zwei gleiche Werte sind weder zwei Stimmen noch zwei Urheber. Contains, match-any, match-every und Gleichheit der vollständigen Menge unterscheiden sich ebenfalls. Cisco IOS XR dokumentiert Matching, additives Setzen, Löschen und Filtern; FRRouting ermöglicht Value-, Exact-Set- und JSON-Readback. Sichtbarkeit ersetzt keine sichere Auswahl.

Aggregation fügt eine weitere Grenze hinzu. Das Aggregat soll die Union der Large Communities seiner Contributors tragen. Das erhält Informationen, bedeutet aber keine Einstimmigkeit. Zwei More-Specifics mit unterschiedlichen Aktionen können beide Werte an das Aggregat vererben. Es braucht eine Regel, welche Aktionsklassen Aggregation überleben und wie die Beitragsevidenz erhalten bleibt.

Malformed ist nicht unauthorized

Die Attributlänge muss ein von null verschiedenes Vielfaches von zwölf Oktett sein. Andernfalls verlangt RFC 8092 die treat-as-withdraw-Behandlung nach RFC 7606.

Die BGP-Session wird dadurch nicht zwingend zurückgesetzt. Das begrenzt den Fehler, kann ihn aber hinter grüner Telemetrie verbergen. KEEPALIVEs laufen, der Peer bleibt Established und unbeteiligte Routen überleben, während betroffene NLRI verschwinden. Raw Attribute Error, Adj-RIB-In-Delta und Dienstwirkung müssen korreliert werden.

Ein korrekt codiertes Tripel eines unbefugten Principals ist ein anderer Fall. Es sollte eine nachvollziehbare Autorisierungsentscheidung erreichen: lokale Action entfernen und Route behalten, Route nach Vertrag ablehnen oder zur Prüfung isolieren. Wer jeden Rechtefehler als „malformed“ bezeichnet, verliert die Unterscheidung zwischen Parser, Wörterbuch und Principal-Grenze.

Migration ist ein verteiltes Programm-Update

Der Wechsel von klassischer Community zu Large Community betrifft Producer, Edge-Import, Route Reflectors, Route Server, Collector, Kundendokumentation und Incident-Werkzeuge. Sie brauchen dieselbe Policy-Epoche.

Dual Signalling hilft alten Nachbarn, kann aber eine Action doppelt ausführen. Sind alte und neue Wörterbücher auseinandergelaufen, entstehen verschiedene Resultate. Dass ein Collector das neue Tripel speichert, beweist Transport, nicht die Übernahme in die Decision Policy.

Ein Canary braucht ein sicheres, unabhängig messbares Präfix. Aufzuzeichnen sind empfangene Legacy- und Large-Sets, normalisierte Menge nach Scrub, exakte Regel und Version, Attributänderung, relevante Adj-RIB-Outs, Selected Route, FIB-Next-Hop und Paketverhalten. Ein erlaubter und ein verbotener Sender gehören in den Test. Falsche Länge bleibt im Labor. Wer aggregiert, testet die Union.

Rollback muss Zustand nennen. Nach Entfernen der neuen Regel kann eine Route unter dem früheren LOCAL_PREF ausgewählt bleiben, bis Policy Re-Evaluation stattfindet. Route Refresh besitzt Umfang und Timing; Hard Reset eine größere Konvergenzwirkung. Bei einem BGP Wedgie nach RFC 4264 kann ein stabiler Fehlzustand koordinierte Änderungen erfordern, obwohl die lokale Konfiguration bereits zurückgesetzt aussieht.

Das Evidenzbuch

Für jede empfangene Route gehören Peer, Beziehungsklasse, Präfix, AFI/SAFI, Session-Epoche, Rohmenge, Parsing-Ergebnis, normalisierte Menge, gelöschte und lokal hinzugefügte Werte, Wörterbuchversion, Autorisierung, gematchte Clause und resultierende Attribute in den Nachweis. Dazu kommen Loc-RIB-Auswahlgrund, Adj-RIB-Out je Nachbarklasse, FIB-Next-Hop und Paketprobes.

So bleiben die Fragen getrennt: Wurde der Wert getragen? War er wohlgeformt? War der Sender befugt? Was bedeutete er in dieser Version? Wurde er ausgeführt? Änderte sich Forwarding? Überlebte die Bedeutung weiter?

Ein öffentlicher Collector liefert nur einen Exportblick auf die letzte Frage. Er rekonstruiert nicht jede Transformation, authentisiert keinen ersten Schreiber und sieht keine Action, die in einem anderen AS intern blieb. Abwesenheit kann Scrub, Best-Path, Aggregation oder eine andere Export View bedeuten.

Sources