Zusammenfassung

  • RFC 4012 ließ import, export und default im bisherigen IPv4-Unicast-Rahmen und ergänzte familienbezogene mp-*-Attribute.
  • Fehlt dort die optionale AFI-Angabe, gilt any für IPv4/IPv6-Unicast und Multicast. Das bedeutet nicht „keine Familie“.

Eine fehlende AFI war kein leerer Geltungsbereich

Wer ein mp-import ohne afi-Klausel liest, könnte annehmen, die Adressfamilie sei nicht festgelegt. RFC 4012 entscheidet anders: Die ausgelassene Klausel gilt als any und umfasst IPv4-Unicast, IPv4-Multicast, IPv6-Unicast und IPv6-Multicast. Das Feld fehlt im Text, nicht aber die Regel. Parser und Betreiber sollen die Reichweite nicht erraten müssen.

Diese Voreinstellung gilt nur für die neuen mp-*-Attribute. Die älteren Attribute import, export und default behalten ihre IPv4-Unicast-Bedeutung. So ändert sich die Semantik bestehender Einträge nicht stillschweigend, und eine neue Multiprotokollaussage bleibt auch ohne AFI eindeutig. Vor jeder weiteren Auslegung lohnt sich deshalb die Frage, welchen Umfang die Grammatik dem Auslassen bereits zuweist.

Vom IPv4-Unicast-Modell zur Familienkennung

RFC 2622 definierte RPSL 1999 für IPv4-Unicast-Richtlinien. Die Attribute import, export und default hatten ihre Bedeutung in diesem Rahmen. RFC 4012 erschien im März 2005 und erweiterte die Sprache auf IPv6 und Multicast, möglichst kompatibel mit vorhandenen Einträgen. RFC 2622 RFC 4012

Die alten Attribute blieben an IPv4-Unicast gebunden. Für multiprotokollfähige Ausdrücke kamen mp-import, mp-export und mp-default hinzu. Mit einer afi-Angabe lässt sich etwa ipv6.unicast oder ipv6.multicast benennen; weitere Werte umfassen breitere Geltungsbereiche. Fehlt die optionale AFI-Angabe bei einem mp-*-Attribut, gilt nach RFC 4012 der Bereich any, also alle vier beschriebenen Protokollfamilien. Das ist eine Auslegungsregel für den RPSL-Text, keine Zusage, dass ein Gerät jede Familie unterstützt oder die Richtlinie anwendet. RFC 4012, Abschnitte 2.1–2.5

Das ist mehr als Syntaxpflege. IPv4 und IPv6 können unterschiedliche Nachbarn, Filter, Next Hops und Ankündigungen haben. RPSLng macht es leichter, den gemeinten Bereich ausdrücklich zu benennen, ohne die Bedeutung des älteren Vokabulars umzudeuten.

Das Wörterbuch kann Bereiche außerdem zusammensetzen: ipv4 und ipv6 umfassen jeweils Unicast und Multicast ihrer Version; any.unicast und any.multicast bündeln je eine Verkehrsart über beide Versionen; any vereinigt alle vier Grundkombinationen. Die Grammatik ist knapp, weil sie diese Vereinigungen benennt, nicht weil ihr Umfang implizit wäre.

Dasselbe AFI-Kürzel, aber unterschiedliche Ebenen

RFC 4012 ergänzte auch die Klasse route6; ihr Objektschlüssel und die Änderungsberechtigung sind jedoch andere Fragen als die optionale AFI-Klausel. RFC 2725 behandelt jene Berechtigung. Hier markiert das nur eine Grenze und eröffnet kein zweites Thema. RFC 4012, Abschnitt 3 RFC 2725

Auch BGP verwendet AFI/SAFI, doch RFC 4760 ordnet damit Erreichbarkeit der Netzwerkschicht und Next-Hop-Angaben in UPDATE-Nachrichten ein. Die optionale AFI in RFC 4012 begrenzt dagegen einen RPSL-Richtlinienausdruck. Das gleiche Kürzel macht die Aussagen nicht austauschbar; Routenauswahl und Ankündigung an einzelne Peers gehören zum Laufzeitverhalten nach RFC 4271. RFC 4271 RFC 4760

Benannte Vereinigungen machten die Grammatik kombinierbar

Die Kurzform „RPSL bekam IPv6“ stimmt, greift aber zu kurz. RFC 4012 machte den Familienumfang einer Richtlinie ausdrücklich benennbar und gab Vereinigungen über Versionen und Verkehrsarten Namen. Das beschreibt die Sprache, nicht eine einheitliche Einführung beider Versionen.

Gerade in dualen Netzen ist diese Trennung wichtig. Eine Aussage für ipv6.unicast hat einen anderen Geltungsbereich als any. Trotzdem entscheidet die präzisere Dokumentation nicht, welche Richtlinie ein autonomes System lädt.

RFC 8212 aus dem Jahr 2017 setzt einen späteren zeitlichen Bezugspunkt: Für EBGP verlangt es explizite Richtlinien, regelt aber das BGP-Verhalten und ändert nicht, wie RFC 4012 eine fehlende AFI in RPSL auslegt. RFC 8212

Lu Hengs Notes 65 und 64 dienen hier als redaktionelle Linse: Gemeinsame Regeln sollten auf das für Interoperabilität Erforderliche begrenzt sein; Änderungen werden durch die Übernahme in laufenden Systemen wirksam. Damit wird keine Absicht der RFC-Autoren behauptet. Die Linse hilft, die Architekturgrenze zu benennen: RPSLng macht Richtlinien lesbarer, doch das laufende BGP-System entscheidet, was geladen und angekündigt wird. Note 65 Note 64

Die Quellen messen weder den heutigen Einsatz von RPSLng noch die Vollständigkeit von Registern oder die IPv6-Praxis eines bestimmten Betreibers. Der belegte Schluss ist enger: RFC 4012 machte den Geltungsbereich von RPSL-Richtlinienausdrücken präziser und eindeutiger.

Primärquellen