Zusammenfassung

  • RFC 8950 erlaubt IPv4- und VPN-IPv4-Erreichbarkeit mit einem IPv6 Next Hop. Capability Code 5 bestätigt nur ein genaues Tripel aus NLRI AFI, NLRI SAFI und Next-Hop AFI; er aktiviert weder die Familie noch beweist er Erreichbarkeit.
  • Der Empfänger bestimmt den Next-Hop-Typ aus der codierten Länge. Ein Route Reflector muss die übernommene Codierung bewahren und darf die NLRI nicht an einen Client verteilen, der dafür keine Unterstützung angekündigt hat.
  • Eine belastbare Migration belegt OPEN, MP_REACH_NLRI, Import-Policy, IPv6-Rekursion, Auswahl, FIB, Adjazenz oder Tunnel und echte IPv4-Pakete getrennt. Eine grüne Session ist nur der erste Schritt.

Um 01:40 Uhr stellt ein Aggregationsstandort sein Transport-Core auf ein einziges IPv6-Underlay um. Kunden und Präfixe bleiben IPv4. Das Ziel ist, doppelte Adressierung und IGP-Zustände im Core abzubauen, nicht das Kundenprodukt umzuwandeln.

Zwei Route Reflectors und die meisten Clients unterstützen das Verfahren. Ein neues Gerät kündigt IPv4 Unicast und Extended Next Hop Encoding im OPEN an. Ein älteres Gerät nennt nur die Familie. Beide Sessions werden Established.

Der neue Client empfängt und wählt die IPv4-Routen, doch sein Resolver sucht den IPv6 Next Hop in einer Management-VRF und landet an der falschen Schnittstelle. Der alte Client erhält die Route nicht: Der Reflector darf den IPv6 Next Hop nicht für ihn in IPv4 übersetzen.

Das Beispiel ist konstruiert, die Grenzen sind real. RFC 8950 verschmilzt IPv4 und IPv6 nicht. Eine Route trägt zwei typisierte Aussagen: Das Ziel ist IPv4; der zum Werbepunkt führende Next Hop ist IPv6.

Ziel und Next Hop beantworten verschiedene Fragen

Die NLRI benennt erreichbare Ziele. Der Next Hop nennt die Adresse, zu der der Empfänger auflösen und weiterleiten soll. Dass beide häufig dieselbe Adressfamilie verwenden, ist Konvention, keine Identität.

MP-BGP macht die Trennung sichtbar. MP_REACH_NLRI enthält AFI, SAFI, Next-Hop-Länge, Next-Hop-Bytes und NLRI. RFC 4760 definiert den Behälter. Frühere IPv4-Definitionen sahen nur IPv4-förmige Next Hops vor und konnten IPv4-Dienste über einem IPv6-Core nicht allgemein ausdrücken.

RFC 8950 erweitert die zulässige Kombination. AFI 1 bleibt IPv4-NLRI; für bestimmte SAFIs darf das Next-Hop AFI 2 sein. Die Kundenadresse wird nicht übersetzt, und die IPv4-Verantwortung verschwindet nicht. Nur der Transportanker benutzt eine andere Familie.

Die Einführung bleibt lokal. Ein Betreiber kann sie in einer Domain, bei ausgewählten Peers oder für einzelne Service-Familien aktivieren. Nichtadoption erzeugt einen anderen Kompatibilitätssatz, keinen ungültigen Teilnehmer. Der Standard liefert eine dünne gemeinsame Regel und keinen zentralen Migrationsplan.

Auch „IPv6-only Core“ braucht diese Begrenzung. Ein einheitliches Underlay kann Zustände reduzieren; IPv4-Kunden, Verträge, Ressourcenwerte, Support und Risiken bleiben. Der Name einer Transportschicht beschreibt nicht das gesamte Geschäft.

Capability 5 verspricht nur das exakte Tripel

Extended Next Hop Encoding ist Code 5. Der Wert enthält Sechs-Oktett-Tripel: je zwei Oktette für NLRI AFI, NLRI SAFI und Next-Hop AFI. RFC 8950 behandelt AFI 1, SAFI 1, 2, 4, 128 oder 129 und Next-Hop AFI 2.

Unterstützung für IPv4 Unicast beweist nichts über Labeled Unicast, Multicast oder VPN-IPv4. Releases, Plattformen und Line Cards können verschiedene Teilmengen tragen. Ein Feld extended-nexthop=true verwirft den eigentlichen Verhandlungsgegenstand.

Code 5 erlaubt auch nicht die AFI/SAFI selbst. Die Multiprotocol Capability entscheidet getrennt, ob die Familie zwischen Peers verwendet wird. Extended Next Hop Encoding sagt nur, welche Next-Hop-Darstellung für eine bereits erlaubte Familie verstanden wird.

OPEN-Beweise brauchen deshalb zwei Spalten: Wurde die MP-BGP-Familie ausgehandelt? Hat der Empfänger das genaue Tripel angekündigt? Eine Session kann Established sein, obwohl eine Antwort nein lautet. Erst nach dem zweiten Nachweis darf der Sender IPv4-NLRI mit IPv6 Next Hop senden.

Das ist Minimum Initial Specification in kleiner Form: stabiler Code, deterministische Regel, lokale Entscheidung. Fehlt das Tripel, wird diese Codierung an diesem Rand nicht benutzt; keine zentrale Instanz erklärt das Netz für migriert.

Das Inventar muss BGP-Instanz, Peer, Versionen, Session-Epoch, AFI/SAFI und jedes gesendete oder empfangene Tripel führen. Eine Produktmatrix ist Beschaffungsinformation, kein Laufzeitbeweis.

Die Länge ist Typinformation

Bei AFI 1 und SAFI 1, 2 oder 4 umfasst der IPv6 Next Hop 16 oder 32 Oktette. Sechzehn tragen eine Adresse; zweiunddreißig können eine globale und anschließend eine Link-Local-Adresse nach RFC 2545 tragen.

Bei VPN-IPv4 mit SAFI 128 oder 129 sind es 24 oder 48 Oktette. Die Darstellung enthält einen auf null gesetzten, acht Oktette langen Route Distinguisher. RFC 8950 passte die VPN-Codierung aus RFC 5549 an bereits interoperable Implementierungen an und behandelte ein Erratum.

Der Receiver muss aus der für AFI/SAFI erlaubten Länge das Protokoll des Next Hops bestimmen. Sie ist kein Anzeigeattribut. Telemetrie, die alles in einen untypisierten String umwandelt, verliert den späteren Validierungsbeweis.

Globale und Link-Local-Adressen haben unterschiedliche Geltung. Eine globale Adresse wird in einer Tabelle aufgelöst; Link-Local wird erst mit Interface und Link eindeutig. fe80::1 ohne Peer, Schnittstelle und VRF ist kein vollständiger Next-Hop-Schlüssel.

Bei unnumbered eBGP können Session und Capability stimmen, während dem FIB die schnittstellengebundene Adjazenz fehlt. Neustart oder Porttausch können denselben Adresstext erhalten und den wirksamen Kontext ändern.

Im VPN-Fall entfernt der Null-RD im Next-Hop-Feld weder den Service-RD noch Route Targets der Route. VPN-Identität und Next-Hop-Codierung bleiben getrennte Objekte.

Der Reflector ist kein Übersetzer

Gibt ein Route Reflector den Next Hop unverändert weiter, muss er dessen Codierung bewahren. Kann ein Client sie nicht verarbeiten, darf die NLRI nicht ankommen. IPv6 durch IPv4 zu ersetzen wäre eine neue Routingentscheidung mit anderem Rekursionspunkt und möglichem Failure Domain.

Damit wird Kompatibilität topologisch. Erzeugt ein Client eine Codierung, die andere über denselben Reflector empfangen müssen, benötigen die relevanten Empfänger Unterstützung. Ein Upgrade kann eine Lücke anderswo sichtbar machen, ohne dass der Reflector defekt ist.

Das Fehlen wirkt unauffällig: Der alte Client bleibt Established, empfängt andere IPv4-Routen, und der Reflector behält die betroffene Route. Ein Zähler zeigt nur die Differenz, nicht den Capability-Grund.

Der Beweis verbindet im selben Epoch Ursprungs-UPDATE, angenommene Reflector-Route, OPEN des Ziel-Clients und dessen Adj-RIB-Out. Der Grund lautet „Codierung nicht unterstützt“, nicht allgemein „Präfix fehlt“.

next-hop-self, Route Server und Konföderationen ändern die Grenze. Ein Rewrite kann beabsichtigt sein, ist dann aber eine lokale Aktion mit Eigentümer und Nachweis, keine unsichtbare Reflexion.

Rekursion macht Syntax zu Betrieb

Nach Annahme des UPDATE löst der Empfänger den IPv6 Next Hop auf: Tabelle oder VRF wählen, Underlay-Route finden, Rekursion verfolgen, Adjazenz oder Tunnel binden, FIB programmieren.

Jeder Übergang kann einzeln scheitern: Adresse fehlt im IGP, Route liegt nur global, Rekursionskette ist offen, Neighbor Discovery versagt, Label oder SID fehlt, MTU reicht nach Kapselung nicht, Line Card hinkt hinterher.

Die Beweiskette lautet:

  1. MP-BGP-Familie angekündigt;
  2. genaues Extended-Next-Hop-Tripel;
  3. erwartetes MP_REACH_NLRI auf dem Wire;
  4. Typ korrekt interpretiert;
  5. Import-Policy akzeptiert;
  6. Route ausgewählt;
  7. Next Hop im richtigen Kontext aufgelöst;
  8. IPv4-Ziel ins FIB programmiert;
  9. IPv4-Pakete hin und zurück.

Keine Stufe zertifiziert die nächste. „BGP hat die Route“ ist zu grob. Dashboards dürfen korrelieren, müssen aber die Quelle jedes Übergangs erhalten.

Rollback braucht dieselbe Präzision. Die Rückkehr zu IPv4 Next Hop kann altes Underlay, next-hop-self, Capabilities und Anzeigenreihenfolge erfordern. Code 5 auszuschalten, ohne den alten Resolverpfad wiederherzustellen, ist kein Rollback.

Security erhält eine IPv6-Fläche

RFC 8950 authentifiziert keine Route. Eine geschützte Session kann unzulässige Anzeigen tragen. RPKI Origin Validation prüft den Origin AS eines IPv4-Präfixes, nicht Sicherheit oder Erreichbarkeit des IPv6 Next Hops.

Werkzeuge mit der Annahme „IPv4-Route gleich IPv4 Next Hop“ übersehen das neue Objekt. RFC 8950 warnt vor Traffic Diversion durch dazwischenliegende IPv6-Infrastruktur mit Hijacking- oder Denial-of-Service-Folgen. Auch der seltene IPv4-mapped IPv6 Next Hop muss korrekt behandelt werden.

Die Lösung ist eine erweiterte Autorisierung: Welche Peers dürfen für welche Service-Familie welche IPv6-Scopes, Tabellen und Tunnel als Next Hop verwenden, und welche IPv4-Dienste dürfen davon abhängen?

Transportauthentisierung, GTSM, Präfix-Policy, RPKI, Next-Hop-Autorisierung, Underlay-Security und Pakettest bleiben getrennte Kontrollen. Korrelation ist sinnvoll; Bedeutungsverschmelzung nicht.

Der Canary muss beide Familien durchqueren

Vor Aktivierung ein begrenztes IPv4-Präfix und den erwarteten IPv6 Next Hop wählen. Route, FIB, Paketpfad, Peer, Resolverkontext und erwartete Tripel je Speaker sichern.

Im neuen Session-Epoch beide OPEN erfassen und Multiprotocol sowie Code 5 getrennt prüfen. Danach UPDATE auf AFI 1, SAFI, Länge 16/32 oder 24/48, IPv6-Bytes und NLRI untersuchen.

Mit Reflector die Bewahrung und Client-Unterstützung nachweisen. Je Empfänger Pre-/Post-Policy, Auswahl, Rekursion, Tabelle, Adjazenz/Tunnel und FIB speichern.

Repräsentative IPv4-Pakete mit Quelle, Ziel, Richtung, Rückweg, Größe und Epoch senden. Ping allein deckt Kapselung und MTU nicht ab. Canary anschließend withdrawen und Cleanup in Adj-RIB-Out, RIB, Rekursion und FIB prüfen.

Eine alte Config in Git ist kein Rückweg. Der frühere Pfad muss unter heutigem Zustand wieder Pakete tragen.

Der RFC liefert gemeinsame Sprache, Hersteller implementieren, Betreiber wählen, das laufende Netz entscheidet. Das Ziel wird nicht IPv6, weil es einen IPv6-Core durchquert. Die Capability wird nicht zur Forwarding-Autorität, weil dieselbe Nummer im OPEN steht. Erst Typ, Policy, Rekursion, Hardware und Paketbeweis machen die Route betrieblich glaubwürdig.