Zusammenfassung

  • RFC 9647 definiert das YANG-1.1-Modell ietf-babel für die Verwaltung von Babel, ist als Standards-Track-RFC im Oktober 2024 erschienen, NMDA-kompatibel und basiert auf der Babel-Spezifikation aus RFC 9046. Der Schwerpunkt liegt auf der administrativen und operativen Modellierung von Babel-Management über IPv6, nicht auf einer neuen Routinglogik.
  • Das Modell macht zentrale Zustände und Konfigurationen prüfbar: Aktivierung, Konstanten, Interfaces, MAC-Key-Sets, DTLS-Objekte und Routen. Ein Route-State kann unter anderem Präfix, Router-ID, Nachbarn, empfangene und berechnete Metrik, Sequenznummer, Next Hop, Feasibility und Auswahlzustand abbilden.
  • Die wichtigste Grenze bleibt bestehen: YANG beschreibt Datenstrukturen und Zustände, garantiert aber nicht automatisch, dass jede notwendige Information vorhanden oder aktuell befüllt ist. RFC 9647 weist ausdrücklich darauf hin, dass YANG selbst die Präsenz verpflichtender Read-only-Informationen aus dem Informationsmodell nicht erzwingen kann; Implementierungen müssen diese Werte bereitstellen.
  • Eine als „selected“ markierte Route ist deshalb eine Management-Projektion des Implementierungszustands. Sie ist kein unabhängiger Messbeweis für erfolgreiche Paketweiterleitung, stabile Nachbarschaft, korrekte Forwarding-Installation oder tatsächliche Ende-zu-Ende-Erreichbarkeit.

Artikel

Wenn eine Route sichtbar ist, aber der Nachweis fehlt

Netzbetreiber kennen das Muster: Ein Managementsystem zeigt einen klaren Zustand. Eine Route existiert. Ein Nachbar ist sichtbar. Ein Interface ist aktiviert. Eine Auswahlentscheidung wurde getroffen. Die Versuchung besteht darin, diese Daten als vollständige Erklärung des Betriebszustands zu behandeln.

Bei dynamischen Routingprotokollen ist diese Schlussfolgerung jedoch zu kurz. Zwischen einem modellierten Zustand und einem tatsächlich funktionierenden Datenpfad liegen mehrere Übergänge. Eine Babel-Route kann in einem YANG-gestützten Managementsystem als ausgewählt erscheinen, während eine andere Schicht noch unbewiesen ist: ob das richtige Interface verwendet wird, ob die Authentisierung tatsächlich erfolgreich war, ob der Kernel oder die Forwarding-Engine die Route installiert hat, ob ein Ausfall korrekt verarbeitet wird oder ob ein unabhängiger Datenverkehrstest dieselbe Realität bestätigt.

RFC 9647 adressiert genau diese Lücke der Beobachtbarkeit. Der RFC mit dem Titel „A YANG Data Model for Babel“ definiert kein neues Babel-Protokoll, sondern eine standardisierte Verwaltungsansicht. Die Spezifikation ist auf dem Standards Track im Oktober 2024 veröffentlicht worden und beschreibt das Modul ietf-babel in YANG 1.1. Die Grundlage bildet RFC 9046, während die Architektur der YANG-Datenmodelle mit den Regeln des Network Management Datastore Architecture (NMDA) aus RFC 8342 zusammenhängt.

Die normative Grundlage ist in den offiziellen Dokumenten nachvollziehbar: RFC 9647, RFC 9647 Information Page, IETF Datatracker RFC 9647 und die zugehörige Errata-Suche.

Was RFC 9647 tatsächlich sichtbar macht

Das Modell erweitert Babel-Management um strukturierte Objekte für mehrere betriebliche Ebenen. Dazu gehören:

  • die Aktivierung von Babel;
  • globale Konstanten;
  • Interface-bezogene Einstellungen;
  • MAC-Key-Sets;
  • DTLS-bezogene Objekte;
  • Routing-Zustände.

Die Route-Darstellung ist besonders relevant, weil sie den Unterschied zwischen Routingentscheidung und tatsächlichem Betrieb sichtbar macht. Ein Route-State kann Felder wie Präfix, Router-ID, Nachbarn, empfangene und berechnete Metrik, Sequenznummer, Next Hop, Feasibility und den Auswahlstatus enthalten.

Diese Informationen helfen bei der Beantwortung konkreter Fragen:

  • Welche Route wurde vom Babel-Implementierungszustand ausgewählt?
  • Welcher Nachbar liefert die Information?
  • Welche Sequenznummer und welche Metrik wurden verarbeitet?
  • Ist die Route aus Sicht des Protokolls zulässig und bevorzugt?

Die Antworten sind wertvoll, aber sie bleiben innerhalb der Managementebene. Ein YANG-Wert ist kein direktes Paket auf der Leitung und kein Ersatz für eine unabhängige Messung.

Administrative Absicht ist nicht gleich operativer Zustand

Ein zentrales Beispiel ist das enable-Leaf. Im laufenden beziehungsweise beabsichtigten Konfigurationskontext beschreibt es die administrative Absicht: Babel soll auf einer bestimmten Ebene aktiviert sein. Im operativen Zustand beschreibt es dagegen den tatsächlich laufenden Zustand.

Diese Trennung entspricht dem NMDA-Modell: Konfiguration und beobachteter Zustand müssen auseinandergehalten werden. Ein Betreiber kann also sehen, dass eine Aktivierung gewünscht ist, ohne daraus automatisch abzuleiten, dass die Funktion bereits vollständig wirksam ist.

Die operative Frage lautet daher nicht nur:

„Ist Babel aktiviert?“

Sondern:

„Ist die gewünschte Aktivierung in der realen Implementierung angekommen, und erzeugt sie den erwarteten Protokoll-, Routing- und Forwarding-Zustand?“

RFC 9647 macht diese Ebenen zugänglich. Es ersetzt jedoch nicht die Prüfung der Übergänge zwischen ihnen.

Standardwerte sind ein Anfang, kein Beweis

Babel arbeitet mit unterschiedlichen Netzumgebungen. RFC 9647 bildet deshalb auch Interface-Eigenschaften und Standardverhalten ab.

Für kabelgebundene Interfaces gelten bestimmte Default-Annahmen, darunter eine Zwei-aus-Drei-Konfiguration bei bestimmten Routingparametern sowie Split Horizon. Für drahtlose Interfaces werden andere Annahmen verwendet, darunter ETX-basierte Defaults ohne Split Horizon.

Diese Unterscheidung ist praktisch relevant. Ein Interface, das technisch wie ein Kabelanschluss aussieht, kann in einem speziellen Aufbau andere Eigenschaften benötigen. Radios hinter kabelgebundenen Ports, Tunnel, gemanagte Zwischenstrecken oder kostenbasierte Fallback-Links können explizite Überschreibungen und angepasste Timer erfordern.

Ein Modellwert für ein Interface zeigt also, was konfiguriert oder berechnet wurde. Er beweist nicht automatisch, dass die Klassifikation der realen Topologie entspricht.

Die betriebliche Prüfung muss deshalb folgende Frage beantworten:

Wurde der Default bewusst akzeptiert, oder hat eine implizite Annahme eine andere Netzrealität überdeckt?

Sicherheit: Schlüsselobjekte sind modelliert, Vertrauen bleibt eine Prozessfrage

RFC 9647 beschreibt auch Sicherheitsobjekte innerhalb des YANG-Modells. MAC-Key-Sets und DTLS-Objekte gehören zu den verwaltbaren Bestandteilen. Default-Apply-Einstellungen für MAC und DTLS können Referenzen auf neu erstellte Interfaces hinzufügen.

Gerade hier entsteht ein typischer Beweisbedarf. Eine globale oder automatische Referenzierung kann gewollt sein, aber sie muss gegen die tatsächliche Interface-Landschaft geprüft werden. Ein neu hinzugekommenes Interface kann theoretisch in einen Bereich fallen, der durch Default-Regeln erfasst wird, ohne dass dies der Sicherheitsabsicht entspricht.

Zusätzlich sind sensible Informationen geschützt. MAC-Schlüssel und DTLS-Private-Keys unterliegen NACM-Schutzmechanismen. Die Zugriffskontrolle selbst ist jedoch nicht identisch mit einem vollständigen Sicherheitsnachweis.

RFC 9647 begrenzt seine eigene Sicherheitserörterung ausdrücklich auf das YANG-Modell. Die eigentlichen Protokoll- und Kryptographieaspekte liegen in den entsprechenden Babel-Spezifikationen, insbesondere RFC 8966, RFC 8967 und RFC 8968.

Die zehn Belege einer belastbaren Babel-Aussage

Eine belastbare Betriebsbehauptung „diese Babel-Route funktioniert“ benötigt mehr als einen einzelnen State-Eintrag. Praktisch lässt sich eine zehnteilige Beweiskette formulieren:

  1. Modulrevision und Features Die eingesetzte Version des ietf-babel-Modells und die aktivierten Features müssen bekannt sein.

  2. Datastore, Ursprung und Zeitpunkt Jeder relevante Wert braucht Kontext: aus welchem Datastore stammt er, welcher Ursprung gilt und wann wurde er beobachtet?

  3. Vorhandensein des erforderlichen Read-only-Zustands Fehlende operative Informationen dürfen nicht stillschweigend als Normalzustand interpretiert werden.

  4. Verifizierte Interface-Klassifikation Die reale Rolle eines Interfaces muss mit der modellierten Kabel-, Funk- oder Spezialkonfiguration übereinstimmen.

  5. Wirksame Defaults und Überschreibungen Betreiber müssen nachvollziehen, welche Regeln tatsächlich angewendet wurden.

  6. MAC- und DTLS-Identität sowie Zuordnung Schlüsselmaterial, Referenzen und Schutzmechanismen müssen zur gewünschten Sicherheitsarchitektur passen.

  7. Authentisierungs- und Handshake-Ergebnisse Eine konfigurierte Sicherheitsbeziehung ist nicht dasselbe wie ein erfolgreich abgeschlossener Austausch.

  8. Nachbarschafts- und Routenchronologie Zustände müssen über Zeit betrachtet werden: Entstehung, Änderung, Auswahl und Rücknahme einer Route.

  9. RIB- und FIB-Installation Eine ausgewählte Route muss in die tatsächlichen Routing- und Forwarding-Strukturen gelangen.

  10. Paketweiterleitung, Wiederherstellung und unabhängige Erreichbarkeit Erst Datenverkehr, Failover-Tests und externe Messungen schließen die Kette.

Diese zehn Belege sind keine zusätzliche Normanforderung von RFC 9647. Sie sind eine operative Konsequenz aus der Trennung zwischen Modell, Implementierung und Verhalten.

Die Rolle von YANG in einer Beweisinfrastruktur

YANG ist besonders stark darin, Verwaltungsschnittstellen zu vereinheitlichen. Es schafft gemeinsame Begriffe für Konfiguration und Zustand und ermöglicht automatisierte Prüfungen über verschiedene Systeme hinweg.

Die Grenze liegt dort, wo das Modell keine physische Realität erzwingen kann. RFC 9647 nennt ausdrücklich, dass YANG die Existenz bestimmter verpflichtender Read-only-Informationsfelder nicht selbst erzwingen kann. Wenn eine Implementierung solche Informationen nicht bereitstellt, entsteht eine Beobachtungslücke.

Das ist kein Fehler des Modells, sondern eine systemische Grenze jeder Datenmodellierung. Ein Schema kann definieren, wie Wissen dargestellt wird. Es kann nicht garantieren, dass die Welt außerhalb des Schemas diesem Wissen entspricht.

Für Betreiber bedeutet das: Automatisierung sollte nicht nur Werte sammeln, sondern Nachweise verbinden.

Quellen und Evidenzgrenzen

Die Analyse stützt sich auf die Standards und Referenzdokumente der IETF. Die Links dienen als Primärquellen für Spezifikation, Status und Sicherheitsmodell:

Sources