Zusammenfassung

  • Mehrere gültige Adressen, Router und Resolver können gemeinsam einen ungültigen Pfad bilden, wenn sie aus verschiedenen Bereitstellungskontexten stammen.
  • Ein belastbarer Verbindungsbeleg bindet DNS-, Quell- und First-Hop-Auswahl an denselben Versuch, ohne Konfiguration, Anwendung, Upstream-Akzeptanz und Dienstergebnis gleichzusetzen.

Der Fehler zeigt sich oft zwischen drei grünen Anzeigen. Der Resolver hat geantwortet. Das Betriebssystem besitzt eine globale IPv6-Adresse. Ein Standardrouter ist erreichbar. Trotzdem läuft die Anwendung in einen Timeout. Keine Anzeige muss falsch sein. Die DNS-Antwort kann aus dem Firmennetz stammen, die Quelle aus dem Festnetzpräfix und der gewählte Ausgang aus dem Mobilfunknetz.

RFC 7157, IPv6 Multihoming without Network Address Translation, analysiert genau diese Art von Fehlkopplung. Das Dokument erschien im März 2014 als Informational RFC mit IETF-Konsens. O. Troan ist als Editor aufgeführt, gefolgt von David Miles, Satoru Matsushima, Takashi Okimoto und Dan Wing. Auch Ole Trøans offizielles Datatracker-Profil verzeichnet die RFC. Das belegt seine redaktionelle Mitwirkung an kollektiver Arbeit, nicht alleinige Erfindung, Kontrolle über Implementierungen oder Urheberschaft späterer RFCs.

Der entscheidende Gedanke betrifft die Funktionen einer IPv4-NAPT-Box. Sie übersetzt nicht nur Adressen. Häufig wählt sie zugleich die nach außen sichtbare Quelladresse, bestimmt den nächsten Hop und vermittelt optional DNS. Der interne Host sieht eine private Adresse und einen scheinbar eindeutigen Ausgang. Welche Provideradresse, welcher Pfad und welcher Namensraum zusammengehören, bleibt im Randgerät verborgen.

Bei IPv6 kann ein kleiner Standort von jedem Provider ein globales Präfix erhalten. Ein Notebook hält WLAN und Mobilfunk gleichzeitig aktiv und ergänzt sie um ein Unternehmens-VPN. Das erlaubt transparente Ende-zu-Ende-Kommunikation ohne unsichtbare Übersetzung jedes Flows. Der größere Adressraum beantwortet aber nicht, welche gelernten Parameter zu derselben Bereitstellungsdomäne gehören.

RFC 7157 trennt deshalb drei Entscheidungen vor dem ersten Paket. Der Host braucht eine zum Ziel und Upstream passende Quelladresse, einen dazu passenden ersten Hop und einen rekursiven DNS-Server, der den richtigen Namensraum kennt. Provider setzen oft Ingress-Filter gegen gefälschte Quellen ein. Ein Paket mit einem rechtmäßig von Provider A vergebenen Präfix kann am Ausgang von Provider B verworfen werden. Einzelne Gültigkeit ist kein Beleg für eine gültige Kombination.

Die erste Entscheidung betrifft die Quelle. RFC 6724 definiert Standardalgorithmen für Quell- und Zieladressauswahl sowie eine administrierbare Policy-Tabelle. RFC 7157 weist darauf hin, dass diese Vorgaben in einer Multi-Präfix-Umgebung nicht immer deterministisch die providergeeignete Quelle wählen. RFC 7078 bietet eine DHCPv6-Option zur Verteilung der Auswahltabelle. Der Empfang dieser Option ist jedoch nur ein Konfigurationsbeleg. Er beweist weder Installation und Aktualität noch ihre Anwendung auf das untersuchte Paket.

Die zweite Entscheidung ist die Tür. Router Advertisements können mehrere Standardrouter gleichzeitig gültig halten. Eine beliebige Auswahl kann die richtige Quelle an den falschen Upstream schicken. RFC 8028 präzisierte später auf dem Standards Track die Reihenfolge: Der Host wählt zuerst die Quelle und danach einen First-Hop-Router, der dieses Quellpräfix angekündigt hat. Autoren sind Fred Baker und Brian Carpenter. Ole Troan wird für wichtigen Text gedankt; eine Danksagung ist kein Autorenwechsel.

Die dritte Entscheidung ist der DNS-Kontext. Ein interner Name kann nur im VPN existieren. Ein Zugangsprovider kann je nach Anfragequelle andere Antworten liefern. Wer alle Resolver fragt und die schnellste Antwort übernimmt, kann eine echte Adresse erhalten, die über den gewählten Ausgang nicht nutzbar ist. RFC 7157 diskutiert Auswahlregeln nach Namensraum und verweist auf RFC 6731 zur Verteilung von DNS-Auswahlregeln per DHCPv6. Die Antwort muss mit Anfrageinterface, Quelle, Resolver und Bereitstellungskontext verbunden bleiben.

Die drei Entscheidungen folgen aufeinander, gehören aber nicht derselben Instanz. Eine Anwendung nennt Ziel und Zweck. DNS-Policy wählt den Namenskontext und liefert Kandidaten. Der Host bestimmt die Quelle. Routing bestimmt den ersten Hop. Gateway und Upstream-Filter entscheiden weiter über Annahme oder Verwerfen. Am Ende antwortet der entfernte Dienst oder schweigt. Ein Eintrag „IPv6 erfolgreich“ löscht die Beziehungen, die den nächsten Fehler erklären könnten.

Auch die Alternativen haben eine präzise Grenze. RFC 7157 möchte NAT und NPTv6 nach Möglichkeit vermeiden, um Ende-zu-Ende-Transparenz zu erhalten. Zugleich hält das Fazit DHCPv6-basierte Lösungen für die untersuchten Probleme für geeignet und NPTv6 möglicherweise für eine Zwischenlösung. Architekturziel und unvollständiger Migrationspfad können nebeneinander bestehen. RFC 6296 beschreibt zustandslose IPv6-Präfixübersetzung, schreibt sie aber nicht jedem Standort vor.

Spätere Dokumente gaben der Zugehörigkeit von Konfiguration einen Namen. RFC 7556 definiert eine Provisioning Domain, PvD, als konsistenten Satz von Quellpräfixen, DNS-Servern und -Suffixen, Standardgateway und weiteren Informationen. Das Modell soll versehentliches Mischen verschiedener Domänen verhindern. RFC 8801 ermöglicht FQDN-basierte PvD-Kennungen in Router Advertisements und optionale JSON-Zusatzdaten. Eine Kennung stützt die Zuordnung, garantiert aber weder Vertrauen noch aktuelle Erreichbarkeit oder Anwendungserfolg.

Der prüfbare Gegenstand ist deshalb ein einzelner Verbindungsversuch. Eine gemeinsame ID verbindet Zielnamen und Anwendungsabsicht, DNS-PvD und Resolver, Quelle und Interface der Anfrage, Antwortmenge und TTL, gewähltes Ziel, Quellkandidaten, ausgewählte Quelle, Policy-Version, Routerkandidaten, ersten Hop, angekündigte Präfixe und Lebensdauern, Nachbar- und Routenzustand, Filterentscheidung, Änderungen bei Wiederholungen und verfügbare Beobachtungen am Upstream oder Ziel. Monotone Zeitangaben bewahren die Reihenfolge trotz Uhrkorrekturen.

Jeder Datensatz bleibt begrenzt. Eine konfigurierte Adresse ist keine ausgewählte Adresse. Eine ausgewählte Quelle ist keine akzeptierte Quelle. Ein Router Advertisement ist kein Weiterleitungsbeleg. Eine DNS-Antwort ist keine Zustellung. Selbst eine erfolgreiche Anwendung bestätigt nur diese Kombination zu diesem Zeitpunkt, nicht alle Ziele, Namensräume oder Ausweichwege.

Darin liegt der bleibende Wert von Trøans dokumentierter Rolle. RFC 7157 zerlegt, was die alte Box bündelte. Transparenz ist nicht die Abwesenheit von Kontrolle. Sie besteht darin, Eingaben, Entscheider, Gültigkeit und Widerruf jeder Kontrolle lesen zu können.

Quellen