Zusammenfassung

  • RFC 9793 definiert das optionale transitive BGP Path Attribute 41. An einem BFR-Hostpräfix trägt es Subdomain, BFR-ID, Kapselung und gegebenenfalls einen BIER-Nexthop für die BIFT-Berechnung.
  • Vorausgesetzt wird eine BIER-Domäne, die mit einer Administrative Domain übereinstimmt; diese darf mehrere autonome Systeme umfassen. Ein unterstützender Grenzrouter muss für EBGP-Session oder -Gruppe eine Richtlinie bieten, deren Standardwert „nicht erlaubt“ ist.
  • Bei fehlender Erlaubnis darf das Attribut nicht exportiert werden. Eingehend ist es still zu ignorieren und nicht weiterzugeben. Sein Empfang beweist weder gemeinsame Zuständigkeit noch kompatible Kennungen, installierten Forwarding-Zustand oder Multicast-Ergebnis.

Die Grenze prüft mehr als das Format

Der stärkste Testfall beginnt mit einer sauberen UPDATE. Das Hostpräfix ist /32 oder /128, Type Code 41 ist korrekt, Längen stimmen, Subdomain und BFR-ID sind lesbar. Ein Parser kann die Nachricht vollständig verstehen. Trotzdem darf der Router sie nicht als autorisierten BIER-Eingang behandeln.

RFC 9793 beschreibt einen optionalen transitiven Pfadparameter. Die IANA BGP Parameters führen Code 41 als BIER und pflegen den zugehörigen TLV/Sub-TLV-Raum. Für die festgelegten AFI/SAFI-Kombinationen bindet das Attribut BIER-Information an ein IPv4-/32- oder IPv6-/128-Hostpräfix. Ein BIER TLV führt eine Subdomain und BFR-ID; MPLS- oder Non-MPLS-Sub-TLVs tragen Label- beziehungsweise BIFT-id-Bereiche, ein BIER Nexthop kann den Rechennachbarn benennen.

Transitivität ist im vorgesehenen Verwaltungsbereich nützlich. Ein BGP-Speaker ohne BIER-Funktion kann die Route samt Attribut unverändert weitergeben. Ein BFR darf Nexthop und Kapselung nach den gekoppelten Regeln für unterstützte Subdomains und BitStringLengths aktualisieren. Unbekannte TLV-Typen sind zu erhalten und zu propagieren; ihre Neuheit allein macht das Attribut nicht fehlerhaft.

An der Verwaltungsgrenze gilt dennoch eine ausdrückliche Zulassung. Ein Router, der das BIER-Attribut unterstützt, muss eine Policy auf Basis einer EBGP-Session oder -Gruppe anbieten. Standardmäßig ist das Attribut nicht erlaubt. Dann darf es nicht zum Peer gesendet werden. Kommt es vom Peer, muss es wie ein unbekanntes optionales nicht-transitives Attribut behandelt werden: still ignorieren, nicht an andere BGP-Peers weiterreichen.

Transitivität beschreibt Weitergabe, nicht Mandat

Nach RFC 4271 kann ein unbekanntes optionales transitives Attribut beibehalten und mit gesetztem Partial-Bit weitergegeben werden. Ein unbekanntes optionales nicht-transitives Attribut wird verworfen. RFC 9793 ändert die Drahtklassifizierung von Code 41 nicht; es ordnet an einer nicht freigegebenen Grenze das zweite Verhalten an.

Damit bleiben drei Aussagen getrennt. Der Nachbar konnte das Attribut bilden. BGP konnte seine Bytes transportieren. Die lokale Grenzpolitik hat seine Verwendung erlaubt. Nur die letzte Aussage ist Autorisierung, und sie lässt sich weder aus dem Transitive-Bit noch aus Partial oder aus einer Established-Session ableiten.

Auch EBGP ist nicht automatisch gleichbedeutend mit einer äußeren Verwaltungsgrenze. RFC 9793 erlaubt, dass eine Administrative Domain mehrere AS umfasst. RFC 8279 nennt EBGP in bestimmten Szenarien sogar als Routing-Underlay. Deshalb kann eine EBGP-Session innerhalb gemeinsamer Betriebsverantwortung liegen oder in eine unabhängige Domäne führen. Die AS-Nummern entscheiden das nicht allein.

Die Session-/Gruppen-Policy bildet genau diese lokale Klassifikation ab. Der geschlossene Standardwert verhindert eine zufällige Öffnung; eine ausdrückliche Ausnahme kann einen bewusst gemeinsamen Bereich abbilden. Doch auch die Ausnahme bestätigt noch keine abgestimmten BFR-Präfixe, Subdomains, BFR-IDs, BitStringLengths, Labelräume oder BIFT-id-Bereiche.

Eine BIFT-Berechnung ist kein Paketbeleg

Ein empfangender BFR geht für jede Subdomain die passenden BFR-Präfixe durch. Ein von null verschiedener BFR-ID kann eine BIFT-Entry erzeugen oder ändern. Der BIER Nexthop oder die definierte Rückfallregel liefert den BFR-NBR; Label oder BIFT-id liefern Kapselungswerte. Der Unicast-FIB-Zustand steuert den Underlay-Pfad.

Dabei entstehen verschiedene Beweisstufen. Die UPDATE belegt deklarierten Zustand. Erfolgreiches Parsing belegt angenommene Syntax. Die wirksame Richtlinie belegt autorisierten Zustand. Die Berechnung belegt einen Control-Plane-Kandidaten. Erst Plattformnachweise zeigen Installation; Packet Captures und Empfänger zeigen beobachtetes Verhalten und Ergebnis. Keine frühere Stufe quittiert automatisch die nächste.

Die Fehlerregeln bestätigen diese Struktur. Stimmen TLV-Längen nicht, verlangt RFC 9793 attribute discard nach RFC 7606. Doppelte TLVs derselben Subdomain können das gesamte Attribut entwerten. Wiederholte BitStringLengths oder überlappende Bereiche entwerten betroffene Kapselungsangaben. Zwei Präfixe mit derselben von null verschiedenen BFR-ID dürfen in der Subdomain nicht zur BIFT-Berechnung dienen. Eine Border-Freigabe repariert diese Fehler nicht.

Selbst eine berechnete BIFT lässt offene Abhängigkeiten. Aufbau und Auswahl eines Tunnels zu einem nicht direkt verbundenen BIER Nexthop liegen außerhalb des RFC. Eine Control-Plane-Tabelle beweist keine Hardwareprogrammierung, eine FIB keinen tatsächlichen Paketpfad und ein Zähler kein beabsichtigtes Serviceergebnis.

Falsches Zusammenfügen beginnt bei lokalen Namen

BFR-Präfixe sind typischerweise Loopbacks, die innerhalb der AD verteilt werden und für BIER nicht nach außen müssen. RFC 9793 warnt: Gelangen sie mit dem Attribut in eine ebenfalls BIER nutzende Nachbar-AD, können zwei unabhängig gedachte BIER-Domänen falsch verbunden werden. Wahrscheinlich kollidierende Konfigurationen schaffen Sicherheitsrisiken und Betriebsprobleme.

Das ist keine Meldung über einen beobachteten Vorfall. Der RFC belegt weder Herstellerverhalten noch Deployment, Angriff, Ausfall, Paketverlust oder Kundenschaden. Er beschreibt einen Mechanismus: Subdomain 0 und ein BFR-ID sind lokal gebunden; gleiche Zahlen in zwei Domänen schaffen weder gemeinsame Bedeutung noch Berechtigung.

RFC 8279 trennt auch die Datenebene. Ein BIER-gekapseltes Paket kann nicht direkt von einer BIER-Domäne in eine andere wechseln. An der Grenze wird es entkapselt und an das Multicast Flow Overlay übergeben; ein Knoten kann BFER der ersten und BFIR der zweiten Domäne sein. Das ist eine explizite Übergabe zwischen Kontexten, keine stille Vereinigung ihrer Control-Plane-Namen.

Das verifizierte Erratum 8463 korrigiert im Beispiel aus Abschnitt 6 BFR1 zu BFER1: Fehlt beim Präfix von BFER1 der BIER Nexthop, verwendet BFR2 dessen BFR-Präfix. Die Grenzregel bleibt unverändert. Die RFC-Editor-Infoseite und der IETF-Datatracker belegen Status und Dokumenthistorie, nicht laufende Netze.