RFC 8950 in der Praxis: IPv4-Präfixe mit IPv6-Next-Hop

Das Problem, das RFC 8950 löst

Multiprotocol BGP (RFC 4760) transportiert Routen für verschiedene Adressfamilien, identifiziert über das Paar AFI/SAFI. "AFI 1 = IPv4", "AFI 2 = IPv6", ..., "SAFI 1 = Unicast", "SAFI 2 = Multicast", u.v.m. Für IPv4-Unicast (AFI 1, SAFI 1) legten die ursprünglichen Definitionen fest, dass das Next-Hop-Feld im Attribut MP_REACH_NLRI eine IPv4-Adresse enthält. Wer also IPv4-Routen austauschen wollte, brauchte auf dem verbindenden Link zwingend IPv4-Adressen, selbst wenn die BGP-Session selbst längst über IPv6 lief.

Das ist in der Architektur an drei Stellen lästig. Erstens verbrauchen Punkt-zu-Punkt-Links und Peering-LANs IPv4-Adressen, die knapp und teuer sind. Zweitens muss jeder Link doppelt adressiert, doppelt dokumentiert und doppelt gefiltert werden. Drittens bleibt ARP als Broadcast-Mechanismus auf großen Layer-2-Domänen erhalten, was gerade in Peering-Umgebungen ein bekannter Störfaktor ist. Ausserdem wird zum Gateway eh via Layer-2-Adresse adressiert. Ohne diese kommen die Daten dort ja nicht an.

RFC 8950 hebt die Kopplung auf: Ein IPv4-Präfix darf mit einem IPv6-Next-Hop angekündigt werden. Die Steuerungsebene wird IPv6-only, die Datenebene bleibt unverändert. Ein IPv4-Paket wird wie bisher per Longest-Prefix-Match in der FIB nachgeschlagen, der Router löst dann statt einer IPv4-Adresse per ARP eine IPv6-Adresse per Neighbor Discovery in eine MAC-Adresse auf. Für den Ethernet-Frame ist es unerheblich, auf welchem Weg die Ziel-MAC ermittelt wurde.

Was der Standard technisch festlegt

Kodierung über die Feldlänge

Der Empfänger erkennt die Adressfamilie des Next-Hops ausschließlich an der Länge des Feldes. Für die AFI/SAFI-Paare 1/1 (Unicast), 1/2 (Multicast) und 1/4 (Labeled Unicast) bedeuten 4 Oktette einen IPv4-Next-Hop, 16 Oktette eine globale IPv6-Adresse und 32 Oktette eine globale Adresse gefolgt von einer Link-Local-Adresse. Bei VPN-IPv4 (1/128 und 1/129) wird der Next-Hop als VPN-IPv6-Adresse mit vorangestelltem Route Distinguisher von 8 Oktetten kodiert, also 24 oder 48 Oktette. Genau hier lag der Unterschied zu RFC 5549, der für VPN-IPv4 noch 16 oder 32 Oktette vorsah. RFC 8950 hat die Spezifikation an das angepasst, was die Implementierungen ohnehin schon taten..

Capability-Aushandlung

Damit kein Peer Routen erhält, die er nicht verarbeiten kann, definiert der Standard die BGP-Capability mit Code 5, die Extended Next Hop Encoding Capability. Sie wird in der OPEN-Nachricht ausgetauscht und enthält je Eintrag ein Tripel aus NLRI-AFI, NLRI-SAFI und Next-Hop-AFI. Nur wenn beide Seiten dasselbe Tripel signalisieren, darf für diese Adressfamilie ein IPv6-Next-Hop gesendet werden. Fehlt die Capability, läuft die Session im klassischen Modus weiter, sofern noch ein IPv4-Next-Hop zur Verfügung steht. Kurzum: die zu transportierenden Router auf der Strecke müssen allesamt auch RFC 8950 umsetzen können.

Die Aushandlung ist der Grund, warum sich RFC 8950 in bestehende Umgebungen schrittweise einführen lässt. Sie ist aber auch die Stelle, an der die meisten Interoperabilitätsprobleme sichtbar werden.

Status im Herbst 2026

Formal ist RFC 8950 seit November 2020 unverändert ein Proposed Standard (gilt als stabil, darf noch Schwächen haben) auf dem IETF Standards Track und macht RFC 5549 obsolet. Eine Nachfolgerevision ist nicht in Arbeit. Die Bewegung findet nicht im Standard statt, sondern in den Implementierungen und im Betrieb.

Rechenzentrums-Fabrics

Der älteste produktive Einsatzfall ist BGP Unnumbered in Leaf-Spine-Fabrics. FRRouting und darauf aufbauende Systeme wie Cumulus Linux bzw. NVIDIA Cumulus nutzen seit Jahren Link-Local-Adressen als Session-Endpunkte und Next-Hops für IPv4-Präfixe. Kein Fabric-Link trägt dort noch eine IPv4-Adresse. Ein bekanntes Detail: Ältere FRR-Versionen trugen im Linux-Kernel einen synthetischen Next-Hop 169.254.0.1 mit statischem Neighbor-Eintrag ein, weil der Kernel früher keinen IPv6-Next-Hop für IPv4-Routen akzeptierte. Mit Nexthop-Groups ist das nicht mehr nötig, die Artefakte sind aber in vielen Installationen noch sichtbar. Sie haben eine solche Gateway-IP schon für Ihren VPS beim Cloudanbieter gesehen? :-)

Internet-Exchanges und Peering

Der eigentliche Schub kam aus der Peering-Welt. Die RIPE NCC hat 2023 die Standardzuweisung für IXP-Peering-LANs von /24 auf /26 reduziert, weil der reservierte /15-Pool absehbar zur Neige geht. Eine informelle Arbeitsgruppe bei Euro-IX hat von 2023 bis 2026 die Einführung an Exchanges vorbereitet: Containerlab-Umgebungen, herstellerspezifische Konfigurationsbeispiele, eine Interoperabilitätsmatrix und Anpassungen an ARouteServer, BIRD, Alice-LG und IXP Manager. Die Gruppe hat ihre regulären Treffen im März 2026 beendet, weil die wesentlichen Ziele erreicht waren.

Im Ergebnis betreiben BCIX in Berlin sowie NIX.CZ und NIX.SK Route Server mit RFC 8950 im Produktivbetrieb. TREX Turku in Finnland ist seit 2025 der erste Exchange, dessen Peering-LAN von Anfang an ohne IPv4 betrieben wird. Auf Netzbetreiberseite hat Meta bereits 2024 vorgestellt, wie IPv4-Infrastrukturadressen aus dem Edge-Netz entfernt wurden. Einzelne Content-Netze wie DeepL geben in PeeringDB an, neue BGP-Sessions nur noch über "IPv6 mit Extended Next Hop" (RFC 8950) für beide Adressfamilien aufzubauen. Für PeeringDB wurde ein Flag „IPv4 with IPv6 next hop" beantragt, damit sich die Unterstützung vor dem Sessionaufbau abfragen lässt.

MPLS- und VPN-Umgebungen

Der dritte Einsatzfall ist ein IPv6-only-Core, über den VPN-IPv4-Routen (SAFI 128) transportiert werden, häufig als 4PE oder 4VPE bezeichnet. Hier greift die geänderte VPN-Kodierung mit Route Distinguisher, und genau hier sind die Unterschiede zwischen Implementierungen am größten.

Herstellerstand, soweit belastbar

Die Unterstützung ist inzwischen breit, aber nicht einheitlich. Wer plant, sollte drei Fragen je Plattform beantworten: Welche AFI/SAFI-Kombinationen werden unterstützt? Ab welcher Softwareversion ist die Kodierung standardkonform? Wird der IPv6-Next-Hop nur in der RIB gehalten oder auch in der Hardware-FIB programmiert? Die folgenden Angaben stützen sich auf Herstellerdokumentation und dokumentierte Betriebserfahrung; Versionsstände sollten vor einer Entscheidung im Feature-Navigator des jeweiligen Herstellers gegengeprüft werden.

• FRRouting: Seit Jahren Grundlage für BGP Unnumbered in Leaf-Spine-Fabrics. Bei interface-basierten Peerings ohne IPv4-Adresse wird die Extended-Next-Hop-Capability automatisch gesendet. In den Containerlab-Referenzumgebungen der Euro-IX-Arbeitsgruppe als Testpartner enthalten.
• Juniper Junos: RFC 5549 auf MX seit 17.3R1, weitere Plattformen später. Junos verwendet standardmäßig eine Vorab-Kodierung aus der Draft-Phase. Ohne das Schlüsselwort rfc8950-compliant funktioniert der Austausch zwischen Juniper-Routern, gegen Fremdhersteller aber mit hoher Wahrscheinlichkeit nicht. Konformitätsprobleme wurden in PR1649332 und PR1716946 behoben, die Korrekturen liegen ab 22.4R2 bzw. 23.2R1 vor.
• Arista EOS: Extended Next Hop Encoding für IPv4-Unicast bereits länger; die Erweiterung auf Labeled Unicast (1/4) und VPN-IPv4 (1/128) über IPv6-Sessions kam mit EOS 4.34.2F.
• Nokia SR OS: Offiziell dokumentiert für IPv4-Unicast über IPv6-only-Transportsessions. Die Funktion wird je Session mit advertise-ipv6-next-hops ipv4 aktiviert. Als Next-Hop dient dann die lokale IPv6-Peering-Adresse, sofern der Peer die Capability für das Tripel ⟨1, 1, 2⟩ angekündigt hat. In der Euro-IX-Laborumgebung seit 2024 im Einsatz.
• Cisco NX-OS: Der Nexus-9000-Konfigurationsguide nennt RFC 5549 für IPv4-Präfixe mit IPv6-Next-Hop, ohne die 8950-Änderungen bei VPN-IPv4 gesondert auszuweisen.
• Cisco IOS XE: Ab Release 17.8 dokumentiert für VPNv4-Präfixe mit IPv6-Next-Hop nach RFC 8950: die Capability wird für die VPNv4-Adressfamilie gesendet. Für IPv4-Unicast (1/1) und für IOS XR liegen keine belastbaren Angaben vor. Hier wäre eine Rückfrage beim Hersteller für die konkrete Version nötig.
• MikroTik RouterOS: Nach Angaben der Euro-IX-Arbeitsgruppe konnte der Kernel IPv6-Next-Hops für IPv4-Routen schon lange, die BGP-Implementierung zog erst mit RouterOS 7.20 nach.
• Route-Server-Software: BIRD mit Multi-Channel-Konfiguration und ARouteServer unterstützen den Standard; Alice-LG kann Routen mit IPv6-Next-Hop im Looking Glass darstellen, IXP Manager liefert Konfigurationsvorlagen. Für ExaBGP war die Funktion zeitweise nur unzureichend dokumentiert.

Versionsangaben veralten schnell. Als laufend gepflegte Referenz dient die Interoperabilitätsmatrix im Repository euro-ix/rfc8950-ixp auf GitHub, in der Testergebnisse über mehrere Hersteller dokumentiert sind.

Stolpersteine in der Umsetzung

Traceroute, ICMP und Loopbacks

Ein Router ohne IPv4-Adresse auf dem Transit-Interface muss ICMP-Fehlermeldungen wie Time Exceeded oder Fragmentation Needed trotzdem mit einer IPv4-Quelladresse erzeugen. Dafür braucht jeder Router mindestens eine IPv4-Adresse auf einem Loopback, und die Plattform muss ICMP-Antworten konsequent von dort sourcen. Ist das nicht sauber konfiguriert, bricht Path-MTU-Discovery, und IPv4-Traceroutes zeigen entweder nur Loopbacks oder gar nichts. Für den Betrieb heißt das: Die Fehlersuche verliert ein gewohntes Werkzeug, und Monitoring-Systeme, die Interface-Adressen abfragen, müssen angepasst werden.

iBGP und next-hop-self

Wird eine an einem Exchange gelernte IPv4-Route mit IPv6-Next-Hop per iBGP ins eigene Netz weitergereicht, muss der Border-Router den Next-Hop auf sich selbst setzen, und zwar in einer Form, die die internen Router auflösen können. Einige Implementierungen setzen dabei automatisch wieder einen IPv4-Next-Hop, andere reichen die IPv6-Adresse durch, die im IGP dann unbekannt ist. Das Verhalten ist plattformabhängig und gehört auf die Testliste.

Brownfield: Peers ohne Unterstützung

An einem Exchange mit Hunderten Teilnehmern wird es über Jahre Router ohne RFC-8950-Unterstützung geben. Ein Route Server kann diesen Peers keine Routen mit IPv6-Next-Hop liefern. Der aktuelle Internet-Draft draft-marenamat-grow-route-server-nh-translation von CZ.NIC und DE-CIX (Version -01, Februar 2026) schlägt vor, dass der Route Server je Legacy-Peer synthetische IPv4-Next-Hops aus einer Übersetzungstabelle einsetzt und der Exchange ARP-Anfragen dafür per Proxy beantwortet. Das ist noch kein Standard, zeigt aber, dass die Koexistenz aktiv bearbeitet wird. Bilaterale Sessions am selben LAN bleiben davon unberührt und müssen von den Teilnehmern selbst gelöst werden.

Sicherheit und Filterung

Wer Link-Local-Adressen als Next-Hop nutzt, verlagert die Nachbarschaftsauflösung vollständig auf Neighbor Discovery. ND ist Multicast statt Broadcast, damit leiser als ARP, aber nicht per se sicherer. RA-Guard, ND-Inspection und Rate-Limits gehören in dieselbe Sorgfaltsstufe wie bisher Dynamic ARP Inspection. Firewalls und ACLs zwischen Routern müssen ICMPv6 für ND und das BGP-Peering über IPv6 zulassen, während sie gleichzeitig weiterhin IPv4-Nutzverkehr filtern. Regelwerke, die IPv4 und IPv6 als getrennte Welten behandeln, passen hier nicht mehr.

Bedeutung für Unternehmens- und Produktionsnetze

Außerhalb von Rechenzentren und Exchanges ist RFC 8950 noch selten anzutreffen, obwohl die Vorteile dort ähnlich sind. Konzern-WANs mit Dutzenden Transfernetzen zu Standorten, Partnern und Cloud-Anschlüssen verbrauchen IPv4-Adressraum, der oft aus privaten Bereichen mit Kollisionen bei Fusionen stammt. Eine IPv6-only-Steuerungsebene entkoppelt die Transfernetze von diesem Problem und verringert die Zahl der zu pflegenden Adressobjekte deutlich.

In OT-Umgebungen liegt der Nutzen an einer anderen Stelle. Die Produktionszellen selbst bleiben auf absehbare Zeit IPv4, weil Steuerungen, HMIs und Protokolle wie Profinet oder EtherNet/IP daran hängen. Die Übergänge zwischen den Zonen nach IEC 62443, also Zonengrenzen, Conduits und die Anbindung der Industrial DMZ, sind jedoch reine Infrastruktur-Links, die niemand adressieren muss außer den Routern selbst. Genau dort lässt sich mit unnumbered BGP über IPv6-Link-Local ein Segmentierungskonzept aufbauen, das ohne IPv4-Transfernetze auskommt, sauber per BFD überwacht wird und keine ARP-Broadcasts zwischen Zonen erzeugt. Voraussetzung wäre dann, dass die eingesetzten Industrie-Router und Firewalls die Capability beherrschen. Bei vielen OT-Herstellern ist das derzeit nicht der Fall und sollte vor einer Ausschreibung abgefragt werden.

Empfehlung für die Planung

1. Inventar erstellen: Welche Router, Firewalls und Route Server sind beteiligt, mit welcher Softwareversion, für welche AFI/SAFI-Kombinationen?
2. Im Labor testen, Capability-Aushandlung mitschneiden, Next-Hop in RIB und FIB prüfen, Traceroute und PMTUD mit IPv4-Loopback verifizieren, iBGP-Weitergabe testen.
3. Junos-Peers ausdrücklich mit rfc8950-compliant konfigurieren und die Mindestversionen einhalten.
4. Monitoring, Looking Glass und Dokumentation auf IPv6-Next-Hops vorbereiten, viele Werkzeuge erwarten noch IPv4 auf jedem Interface.
5. Schrittweise einführen: Neue Links und neue Peerings IPv6-only, Bestand dual-stack belassen, bis die Gegenseite nachgezogen hat.

RFC 8950 ist kein Experiment mehr. Der Standard ist stabil, die großen Routing-Plattformen unterstützen ihn, und an mehreren europäischen Exchanges läuft er produktiv. Offen sind nicht die Grundlagen, sondern die Betriebsdetails: ICMP-Sourcing, iBGP-Verhalten, Werkzeugunterstützung und die Koexistenz mit Altgeräten. Wer diese Punkte im Labor abgearbeitet hat, kann IPv4-Adressen von Infrastruktur-Links streichen, ohne dass sich für den IPv4-Nutzverkehr etwas ändert. Es sollte nicht nur wohl überlegt sein, wo IPv6 eingesetzt werden kann und wo RFC 8950 sinnvoll ist. Viele Hersteller von Routern, L3-Switchen, Firewalls, Loadbalancern und anderen Appliances versprechen Kompatibilität, halten diese aber nicht bis ins Detail ein. Die Dataplane reicht schon nach den gefragten Anforderungen weiter, aber in HA-Szenarien, bei einem OoB-Managment sowie Anforderungen, die etwas anspruchsvoller sind, gibt es Hersteller-seitig noch immer Probleme. Hier muss in einem POC festgestellt werden, ob alles wie gewünscht funktioniert. Zudem sit wichtig, ob der Servicevertrag nach Auftauchen eines alten Bugs oder Features diese auch schnell ausmerzen kann.