Warum nutzt eine Punkt-zu-Punkt-Übergabe IPv4 /31 oder IPv6 /127?

Ein IPv4-/31 oder IPv6-/127 an einer IP-Transit-Übergabe ist nicht zu klein: Auf einem echten Punkt-zu-Punkt-Link werden genau zwei Router adressiert. Die langen Präfixe bilden diese Topologie ausdrücklich ab. Entscheidend ist, dass beide Seiten dieselben lokalen und entfernten Adressen, Präfixlängen und Übergabeparameter konfigurieren. Die Netze, die Sie anschließend per BGP ankündigen, sind davon getrennt.

Warum ein IPv4-/31 zwei nutzbare Adressen hat

In einem klassischen IPv4-/30 gibt es vier Adressen: Netzadresse, zwei Hostadressen und Broadcast-Adresse. RFC 3021 definiert für Punkt-zu-Punkt-Links eine engere Auslegung. Bei einem /31 stehen die beiden Bitkombinationen für die zwei Endpunkte; die sonst als Netz- und Broadcast-Adresse behandelten Werte dürfen dort als Quell- und Zieladresse der Router dienen. Dadurch benötigt die Verbindung zwei statt vier IPv4-Adressen.

Diese Ausnahme gilt für einen Link mit genau zwei Endpunkten. Ein gemeinsames Ethernet-Segment mit weiteren Routern, Servern oder automatischer Hostadressierung ist ein anderes Netzmodell. Außerdem müssen beide Geräte /31 auf dem betreffenden Interface unterstützen. RFC 3021 warnt ausdrücklich davor, nur eine Seite entsprechend zu konfigurieren.

Warum IPv6-/127 nicht einfach ein winziges LAN ist

RFC 6164 legt /127 für Punkt-zu-Punkt-Verbindungen zwischen Routern fest, wenn konkrete, nicht nur link-lokale Adressen verwendet werden. Auch hier bleiben genau zwei Endpunktadressen. Der Anwendungsbereich ist bewusst eng: zwei Router, keine angeschlossenen Hosts. Die Empfehlung ist daher kein Muster für ein Server-VLAN oder ein Endkundennetz.

Die lange Präfixlänge hat bei IPv6 nicht primär den Zweck, Adressen zu sparen. RFC 6164 beschreibt unter anderem zwei betriebliche Vorteile: Unbenutzte Adressen eines großen Link-Präfixes können keine Ping-Pong-Weiterleitung zwischen den Enden auslösen, und auf Ethernet entsteht kein großer Vorrat scheinbar erreichbarer Ziele, für die der Router erfolglos Neighbor-Discovery-Einträge anlegt. RFC 9099 greift diese Gründe in seinen IPv6-Sicherheitshinweisen auf.

Beispiel: Übergabenetz und angekündigte Präfixe trennen

Das folgende Beispiel ist ausschließlich illustrativ. Es verwendet die für Dokumentation vorgesehenen Bereiche aus RFC 5737 und RFC 3849; die Adressen beschreiben keine reale AS51202-Übergabe.

• IPv4: Router A nutzt 192.0.2.0, Router B nutzt 192.0.2.1; das gemeinsame Präfix lautet 192.0.2.0/31.
• IPv6: Router A nutzt 2001:db8:1200:1::2, Router B nutzt 2001:db8:1200:1::3; das gemeinsame Präfix lautet 2001:db8:1200:1::2/127.

Welche Seite die erste oder zweite Adresse erhält, ist keine allgemeine Regel; maßgeblich ist das Übergabeblatt. Die BGP-Nachbaradresse ist jeweils die Adresse des anderen Routers. Eigene Kundenpräfixe werden separat als BGP-Routen angekündigt. Aus dem /31 oder /127 folgt weder, welche Routen empfangen werden, noch welche Präfixe exportiert werden dürfen.

Ist bei IPv6 auch nur Link-Local möglich?

Ja, Router können Infrastrukturverbindungen unter bestimmten Voraussetzungen nur mit IPv6-Link-Local-Adressen betreiben. RFC 7404 beschreibt Vorteile und Nachteile dieses Modells. Die Adressen gelten nur auf dem jeweiligen Link; bei mehreren Interfaces muss deshalb zusätzlich die richtige Zone beziehungsweise Schnittstelle eindeutig sein. Ein BGP-Nachbar wie fe80::1 ist ohne diesen Kontext nicht eindeutig.

Link-Local-only ist kein stiller Ersatz für ein vereinbartes /127. Entfernte Interface-Pings, Traceroute-Darstellung, Monitoring und die Quelladresswahl für ICMPv6 können sich anders verhalten. Verwenden Sie das Modell, das beide Seiten ausdrücklich dokumentiert haben, und legen Sie vorab fest, welche Adressen für Diagnose und Management vorgesehen sind.

Typische Fehler bei der Inbetriebnahme

• Eine Seite konfiguriert /31, die andere /30 – dadurch bewerten die Router dieselbe Adresse unterschiedlich.
• Lokale und entfernte Adresse werden aus einer vermeintlichen Provider-/Kundenkonvention abgeleitet statt aus dem Übergabeblatt.
• VLAN, ungetaggte Übergabe oder MTU stimmen nicht; das Adressproblem ist dann nur der sichtbare Folgeschaden.
• Das Übergabenetz wird mit den per BGP anzukündigenden Kundenpräfixen verwechselt oder ungefragt in Exportfilter aufgenommen.
• IPv6 Neighbor Discovery oder notwendige ICMPv6-Nachrichten werden durch eine zu breite ACL blockiert.
• Dasselbe Punkt-zu-Punkt-Präfix wird für zwei getrennte Links wiederverwendet; Diagnose und Ausfallverhalten werden dadurch uneindeutig.

Prüfreihenfolge vor der BGP-Session

1. 1Übergabepunkt, Port, Optik, VLAN und MTU mit der schriftlichen Übergabe abgleichen.
2. 2Lokale Adresse, entfernte Adresse und Präfixlänge für IPv4 und IPv6 getrennt übernehmen.
3. 3Direkte Erreichbarkeit des gegenüberliegenden Routers und bei IPv6 den Neighbor-Status prüfen.
4. 4Erst danach BGP-Nachbar, lokale und entfernte ASN sowie die vereinbarten Import- und Exportfilter aktivieren.
5. 5Empfangene und angekündigte Routen gegen den vereinbarten Umfang prüfen; eine funktionierende BGP-Session allein bestätigt noch keine korrekte Policy.
6. 6Diagnoseweg, technische Kontakte und Rückfall für Änderungen dokumentieren.

Für eine Transit-Anfrage helfen Übergabestandort, gewünschter Commit und Port, ASN, Präfixe und der gewünschte Routenempfang. Falls Ihr Router oder Ihr Adresskonzept Einschränkungen bei /31, /127 oder Link-Local-Peering hat, nennen Sie diese vor der Konfiguration. Zugangsdaten oder private Schlüssel gehören nicht in die Anfrage.