Zusammenfassung

  • Ein individueller Entwurf vom 21. Juli beschreibt eine Specific Local Address Table, kurz SLAT. Jeder Kunde des Route Servers kann denselben physischen Nachbarn unter einem anderen lokalen IPv4-Next-Hop sehen.
  • Der Server schreibt NEXT_HOP für einen älteren Empfänger anhand dessen SLAT-Spalte um. Der ARP/ND-Proxy des IXP muss diesen Alias zum richtigen Mitglied auflösen. Anzeige und Paketweg hängen am selben gepflegten Verzeichnis.
  • RFC 7947 verlangt bisher die unveränderte Weitergabe von NEXT_HOP. Der Entwurf würde eine Ausnahme schaffen. Bilaterale Peerings am Server vorbei brauchen die veröffentlichte Tabelle oder eine eigene Übersetzung.

Zwei Teilnehmer sehen dieselbe IPv4-Route. Einer versteht einen IPv6-Next-Hop, der andere nur IPv4. Das Zielpräfix bleibt gleich, ebenso der Teilnehmer, zu dem die Pakete gelangen sollen. Unterschiedlich ist die Adresse, die der jeweilige Empfänger im BGP-Update lesen kann, und die Antwort auf seine Nachbaranfrage im Peering-LAN. Öffentliche IPv4-Adressen für alle machen das einfach. Kundenspezifische lokale Namen sparen diese Adressen, verlangen aber ein präzises Verzeichnis.

RFC 8950 erlaubt IPv4-Erreichbarkeit mit IPv6-Next-Hop, wenn die entsprechende Fähigkeit ausgehandelt ist. Ein altes Gerät lernt sie durch die Aushandlung anderer Teilnehmer nicht. Der Übersetzungsentwurf nennt die Gruppen Legacy, Supporting und Unnumbered: nur IPv4-Next-Hop für die erste, beide Arten für die zweite, nur IPv6-Next-Hop für die dritte. Am Route Server treffen diese Sichtweisen aufeinander.

Zunächst erfasst der IXP für jedes Mitglied eine feste MAC-Adresse, eine linklokale und eine globale IPv6-Adresse. Die eindeutigen Dreiergruppen bilden die Local Address Table. Mit jedem Legacy- oder Supporting-Kunden vereinbart der Betreiber dann ein kundeneigenes lokales IPv4-Präfix. Eine neue Spalte gibt darin jedem physischen Teilnehmer einen IPv4-Alias; daraus entsteht die SLAT. In der Beispieltabelle heißt derselbe Nachbar für einen Empfänger 10.0.0.10, für einen anderen 192.0.2.10. Verschiedene Namen führen zur selben Maschine.

Der Route Server muss bei Ein- und Ausgang die passende Spalte wählen. Eine empfangene IPv4-Route mit IPv4-NEXT_HOP erhält intern die IPv6-Adresse ihres Absenders aus der Tabelle. Auf dem Weg zu einem Legacy-Empfänger wird daraus der IPv4-Alias des Absenders in der Spalte dieses Empfängers. Für Unnumbered bleibt der IPv6-Next-Hop unverändert; bei Supporting empfiehlt der Entwurf ebenfalls, ihn zu belassen. Fehlt für eine Next-Hop-Adresse jede SLAT-Zuordnung, darf die Route nicht verbreitet werden. Die Tabelle entscheidet also mit, welche Erreichbarkeitsbehauptung in welchem Format hinausgeht.

Der zweite Teil des Verfahrens liegt im LAN. Der IXP beobachtet ARP und Neighbor Discovery, beantwortet Anfragen aus der jeweiligen Kundenspalte und verhindert im vorgeschlagenen Modell deren direkte Weitergabe zwischen Kunden. Zeigt ein BGP-Update auf einen Alias, dessen ARP-Antwort zu einer anderen MAC führt, bleibt die Route im Kontrollsystem sichtbar, während Pakete den falschen Nachbarn erreichen. Für einen konkreten Einsatz fehlt die gemeinsame Aufzeichnung aus empfangener Route, SLAT-Zeile, ARP/ND-Antwort, FIB-Auflösung und Paketankunft, auch nach einer Adressänderung des Mitglieds.

Das verändert die Aufgabe des Route Servers. RFC 7947 Abschnitt 2.2.1 schreibt die unveränderte Weitergabe von NEXT_HOP vor, weil der Server selbst keinen Teilnehmerverkehr transportiert. Der neue Entwurf setzt die Regel für die Übersetzung ausdrücklich beiseite. Im SLAT-Hauptmodell bleibt der Server aus dem Datenpfad. Er verwaltet jedoch den Namen, mit dem ein Kunde den tatsächlichen Nachbarn findet. Der Proxy muss dieselbe Zuordnung kennen. Die Autoren empfehlen eine einzige Quelle für Adresszuweisungen und regelmäßige Prüfungen, ob die verschiedenen Next-Hop-Darstellungen zum selben Mitglied führen.

Die Umstellung lässt sich staffeln. Erst ARP/ND-Beobachtung, dann ein neuer Server für IPv6-Next-Hops bei IPv4-Routen neben dem traditionellen. Anfänglich können die Spalten bestehende öffentliche IPv4-Zuweisungen abbilden. Später werden Mitglieder in lokale Präfixe umnummeriert, auch in private Bereiche. Diese Mischphase hält einen Rückweg offen und zwingt gleichzeitig zur Prüfung beider Adressbilder.

Bilaterale BGP-Sitzungen umgehen die zentrale Umschreibung. Der Entwurf fordert dafür eine veröffentlichte, aktuelle SLAT, damit die Parteien selbst übersetzen können. Ein Looking Glass könnte den ursprünglichen IPv4-Wert, den tatsächlichen IPv6-Next-Hop und den Ausgangs-Alias für einen gewählten Empfänger nebeneinander anzeigen. Ein isolierter Alias sieht sonst wie eine allgemeingültige Identität aus. Eine weitere Variante setzt eine Proxy-Maschine ein, die Verkehr zwischen zwei Domänen tatsächlich weiterleitet; sie hat eine eigene Fehlerfläche.

Das IXP kann öffentliche IPv4-Adressen sparen, wenn es die dafür nötigen Zuordnungen als laufenden Dienst betreibt. Der BGP-Name und die Antwort auf dem LAN müssen denselben physischen Teilnehmer beschreiben. Pakete nehmen das Adressbuch beim Wort.

Entwurf Route Server Next Hop Translation, Revision 02 · RFC 7947 · RFC 8950 · RFC 9161