Summary

  • draft-ietf-idr-rt-derived-community-13 vom 28. Oktober beschreibt eine vom Route Target abgeleitete Extended Community. Ihre Werte für Global Administrator und Local Administrator bleiben erhalten; der Subtyp wechselt. Nach diesem Entwurf identifiziert die abgeleitete Markierung nur das ursprüngliche RT. Sie begrenzt weder die Routenverteilung noch löst sie den Import in eine VRF aus. Das Dokument befindet sich in der IESG Evaluation und ist als Informational vorgesehen.
  • IANA führt bereits sechs entsprechende Zuweisungen mit Verweis auf einen Vorläuferentwurf von 2021. Der neue Text beantragt aktualisierte Verweise und weitere Werte. Eine Nummer im Register legt noch kein Verhalten für den empfangenden Router fest.

Ein gemeinsames VPN, verschiedene Empfänger

Der Entwurf beschreibt ein VPN mit zehn Provider-Edge-Routern. Ein gemeinsames Route Target sorgt dafür, dass alle zehn passende VPN-Routen in ihre VRFs importieren. Eine weitere BGP-Route soll zwar mit demselben VPN verbunden sein, jedoch nur einen Teil der Router erreichen. Mit dem gemeinsamen RT bekäme die Verteilungslogik einen Grund, alle zu beliefern. Für jede Teilgruppe ein neues RT einzuführen, würde umgekehrt dieselbe VPN-Beziehung unter viele Kennungen zerlegen. Der Entwurf sucht eine Bezeichnung der Beziehung ohne die zugehörige Verteilerliste.

Die abgeleitete Extended Community behält die Administratorwerte des RT und tauscht den Subtyp. Daraus lässt sich das ursprüngliche RT wiederfinden. Abschnitt 2 sagt jedoch ausdrücklich, dass diese Markierung kraft des Entwurfs weder die Weitergabe der Route steuert noch sie in eine VRF importiert. Sie kann nicht als RT-Mitgliedschafts-NLRI nach RFC 4684 transportiert werden. Eine Richtlinie, die Route Targets abgleicht, trifft die abgeleitete Community nicht. Sie verweist auf einen Schlüssel, ohne selbst das Schloss zu öffnen.

Der geltende RFC 4360 erklärt, warum die Trennung zählt: Ein Route Target bezeichnet Router, die Routen mit diesem Target empfangen können. Die neue Kennzeichnung nutzt dieselben administrativen Werte, damit unterschiedliche Teilgruppen ein gemeinsames VPN erkennen. Der andere Subtyp hält die Import- und Verteilungswirkung beim eigentlichen RT. Ähnlichkeit im Zahlenfeld ist kein Zuständigkeitsnachweis.

IANA vergibt Zeichen, keine lokale Freigabe

Die IANA-Register für BGP Extended Communities enthalten bereits Einträge RT-derived-EC mit Subtyp 0x15 sowie einen IPv6-spezifischen Typ 0x0015. Der Entwurf zählt sechs bestehende Zuweisungen, deren Quellen noch auf den Vorläufer von 2021 zeigen. Er beantragt neue Quellenangaben, die Umbenennung des EVPN-Eintrags und weitere Werte für einen UUID-basierten IPv6-RT und zwei Transport Classes. Die beantragten Werte stehen im IANA-Abschnitt des Entwurfs; sie sind damit noch keine erledigten Registereinträge.

Auch die verbreitete Zuordnung 0x02 zu 0x15 ist laut Text eine Konvention, keine allgemeine Rechenregel. Tabelle 1 legt die jeweiligen Paare fest. Für einen IPv6-RT mit Wert 0x0011 wird ein abgeleiteter Wert erst beantragt. Wer Implementierungen allein auf das häufigste Muster trainiert, kann gerade bei den Ausnahmen einen fremden Subtyp als bekannte Berechtigung auslegen.

Was ein Empfänger mit der abgeleiteten Kennzeichnung macht, muss ein gesondertes Nutzungsdokument bestimmen. Es soll AFI/SAFI und Routentypen benennen und die konkrete Reaktion festlegen. Die gemeinsame Spezifikation liefert eine erkennbare Beziehung; über Handlung und Reichweite entscheiden spätere Texte und lokale Richtlinien. Ein IANA-Codepunkt ist deshalb kein Nachweis für Installation, Weitergabe oder erfolgreiche Zustellung.

Am 28. Oktober verzeichnete der Datatracker Revision 13 als Entwurf in IESG Evaluation und die IANA-Prüfung als nach Versionsänderung erneut nötig. Die Quellen dokumentieren Vorschlag und vorhandene Nummern, keinen realen Routenleck-Vorfall.