Zusammenfassung

  • RFC 5220 beschrieb ein „halb geschlossenes“ IPv6-Netz, in dem die Standardregel des Hosts eine Quelladresse aus einem Präfix wählen konnte, das aus dem öffentlichen Internet nicht erreichbar war.
  • Quelladresse und nächster Router sind zwei verschiedene Entscheidungen. Das RFC hält einen möglichen Konflikt fest, nicht einen konkreten Einsatz, eine Ausfallquote oder das Verhalten aller multihomed Hosts.

Zwei gültige Präfixe, eine unerreichbare Antwort

RFC 5220 erschien im Juli 2008 als Informational-Dokument zu IPv6-Adresswahl auf Verbindungen mit mehreren Präfixen. Es führte kein neues Paketformat ein. Stattdessen sammelte es Fälle, in denen die Standardregeln für Quell- und Zieladresswahl aus RFC 3484 schwer zu betreiben waren – besonders bei Hosts, die Nutzer nicht einzeln mit einer Netzwerkrichtlinie versehen können.

Das prägnanteste Beispiel nennt das Dokument ein „halb geschlossenes Netz“. Ein kleiner Standort hängt an zwei vorgelagerten Netzen: Das eine bietet gewöhnlichen Internetzugang, das andere ist ein geschlossenes Netz, etwa über ein VPN. Der Host besitzt von beiden eine gültige IPv6-Adresse. Kolleginnen und Kollegen im geschlossenen Netz erreichen ihn über die interne Adresse; ein öffentlicher Server kann eine Antwort an diese Adresse jedoch nicht über das offene Internet zustellen.

Der Konflikt entsteht, wenn der Host eine Verbindung zu einem öffentlichen Ziel beginnt. Im Beispiel von RFC 5220 kann die Regel des längsten passenden Präfixes die Adresse aus dem geschlossenen Netz als Quelle auswählen. Die Standardroute des Standorts kann das Paket dennoch an den Internetprovider schicken. Dieser kann ein Quellpräfix verwerfen, das er nicht vergeben hat. Selbst wenn das Paket hinauskommt, zeigt die Antwort des öffentlichen Servers auf das geschlossene Präfix und findet über den öffentlichen Weg nicht zurück. Eine gültige Adresse garantiert keine vollständige Kommunikation.

Der Text unterscheidet zwei mögliche Bruchstellen. Ein Eingangsfilter kann das ausgehende Paket verwerfen, weil seine Quelle nicht zum gewählten Provider gehört. Oder die Rückwegdomäne ist geschlossen, sodass die Antwort nicht ankommt, obwohl das Paket hinausging. Beides ist weder bloß ein DNS-Problem noch ein Beleg für eine ungültig formatierte Hostadresse.

Das Präfix verriet nichts über die Politik des Providers

RFC 3484 bot Standardvergleiche zwischen möglichen Adressen. Es teilte dem Host aber nicht automatisch mit, welcher Provider das Paket transportieren würde oder ob das ausgewählte Quellpräfix auf diesem Weg eine Antwort empfangen könnte. RFC 5220 behandelt solche Fälle deshalb als Abstimmungsproblem zwischen der Auswahl am Host und der Routingpolitik des Netzes. Im halb geschlossenen Beispiel konnte eine Richtlinientabelle auf dem Host die falsche Wahl vermeiden – vorausgesetzt, jemand kannte die Topologie und hielt die Konfiguration aktuell.

Das Dokument begrenzt seinen Anspruch ausdrücklich. Es trennt Probleme, die in den vorhandenen Auswahlrahmen passen, von solchen, die zusätzliche Information oder einen anderen Mechanismus erfordern könnten. Es behauptet nicht, jedes multihomed IPv6-Netz sei defekt gewesen, und misst auch nicht, wie oft die Beispiele im Betrieb vorkamen. Ein Diagramm beschreibt einen zu prüfenden Fehlerpfad, keinen Vorfallbericht.

Spätere Standards machten Teile dieser Grenze expliziter. RFC 6724 löste RFC 3484 ab. Der Standards-Track RFC 8028 beschrieb 2016 die Auswahl des ersten Routers in Netzen mit mehreren Präfixen und die Beziehung zwischen angekündigtem Präfix, Quelladresse und Ausgangsrouter. Das zeigt, wie sich die Standardarbeit entwickelte; es beweist weder die Verbreitung der Szenarien von 2008 noch ersetzt es die Prüfung eines realen Rückwegs.

Eine normative Warnung ist keine Verkehrsmessung

Der historische Beitrag von RFC 5220 liegt in der Trennung zusammenhängender, aber nicht austauschbarer Tatsachen: Quelladresse, nächster Hop, Providerfilter und Rückwärtserreichbarkeit. Das Dokument analysiert plausible Konfigurationen. Es liefert weder eine Betriebssystemerhebung noch Paketmitschnitte, einen benannten Ausfall oder einen Vorher-nachher-Vergleich. Wie viele Hosts tatsächlich falsch wählten oder wie stark spätere Arbeit die Live-Konnektivität verbesserte, ließe sich nur mit Implementierungs- und Betriebsbelegen außerhalb des RFC beantworten.

Quellen

  1. RFC 5220 — Problemstellung zur Standard-Adresswahl in Netzen mit mehreren Präfixen
  2. RFC 3484 — Standard-Adresswahl für IPv6
  3. RFC 6724 — Standard-Adresswahl für IPv6
  4. RFC 8028 — Auswahl des ersten Routers durch Hosts in Netzen mit mehreren Präfixen
  5. RFC 2827 — Ingress-Filterung in Netzen
  6. RFC 4193 — Eindeutige lokale IPv6-Unicast-Adressen
  7. RFC-Editor-Eintrag zu RFC 5220
  8. RFC-Editor-Eintrag zu RFC 8028