Zusammenfassung

  • Ein PRL-Eintrag belegt, dass eine IPv4-Adresse als mögliches Ziel einer Router Solicitation veröffentlicht wurde. Er belegt nicht, dass dort noch ein berechtigter und erreichbarer Router arbeitet.
  • Eine gültige Router Advertisement ist ein neuer Beleg, aber noch kein Nachweis für Adresskonfiguration, Rückweg, einheitliche Anycast-Instanzen oder Anwendungserfolg.
  • Gemeinsame Koordination und lokaler Betriebsnachweis sollten getrennt bleiben: Die Liste sagt, wo gefragt wird; der laufende Verkehr zeigt, was tatsächlich geliefert wurde.

Die Konfiguration war grün, der Rückweg war tot

In einem ausdrücklich konstruierten Wartungsfenster liefert isatap.example.net um 09:00 Uhr zwei IPv4-Adressen. Soll- und Ist-Liste stimmen überein. Das Konfigurationssystem markiert beide Kandidaten als vorhanden.

Um 09:03 Uhr ist eine Adresse weiterhin im Cache, obwohl das alte Gerät am Vorabend entleert wurde. Der Ersatz steht in einer anderen Standortpartition, vor der eine Protocol-41-Regel noch geschlossen ist. Um 09:05 Uhr sendet ein Host zwei gerichtete Router Solicitations; nur eine Router Advertisement kehrt zurück. Um 09:08 Uhr besitzt der Host eine IPv6-Adresse und einen Standardrouter, doch ein Teil des Rückverkehrs folgt noch einer IPv6-Route zum stillgelegten Gerät.

Das Szenario ist aus den Mechanismen von RFC 5214, RFC 6964 und Neighbor Discovery zusammengesetzt. Es ist kein Bericht über einen konkreten Betreiber. Die vier Zustände — Veröffentlichung, Kontrollantwort, lokale Konfiguration und Dienst — müssen gerade deshalb getrennt werden, weil jeder für sich korrekt aussehen kann.

Warum ein NBMA-Link einen Wegweiser braucht

ISATAP kapselt IPv6 in IPv4 und behandelt das IPv4-Netz als Non-Broadcast-Multiple-Access-Link. Ein IPv4-Wert steckt im ISATAP-Interface-Identifier. So lässt sich der Underlay-Locator eines Peers statisch berechnen.

Allgemeines IPv4-Multicast steht nicht verlässlich zur Verfügung. Ein Host kann deshalb nicht einfach alle Router auf dem virtuellen Link gemeinsam ansprechen. Er braucht eine Potential Router List und sendet seine Anfrage einzeln an die dort genannten IPv4-Adressen.

Die PRL kann manuell, über eine anbieterspezifische DHCPv4-Option, über einen DNS-Namen oder über ein anderes Standortverfahren initialisiert werden. Diese Wege verteilen eine administrative Absicht. Sie prüfen weder Prozesszustand noch Routen, Firewallregeln oder Hardware.

RFC 5214 behandelt Frische als eigene Größe. PrlRefreshInterval hat einen Standard von 3.600 Sekunden. Bei DNS-TTLs soll die frühere Frist gelten. Damit wird ein Cache begrenzt. Der Timer garantiert nicht, dass das Gerät während seiner gesamten Laufzeit unverändert erreichbar bleibt.

Ein passendes Bitmuster bleibt ein enger Beweis

Beim Entkapseln prüft der Knoten, ob die äußere IPv4-Quelle zum eingebetteten IPv4-Wert der inneren ISATAP-Quelle passt. Handelt die Quelle als Router, kann auch ihre Mitgliedschaft in der PRL die Beziehung herstellen.

Diese Prüfung ist wichtig. Sie bindet äußeren Locator und innere Behauptung nach einer klaren Regel. Sie bestätigt jedoch nicht den Eigentümer des Geräts, die aktuelle Konfigurationsgeneration, die Zugehörigkeit zum beabsichtigten Standort oder das Ziel des nächsten weitergeleiteten Pakets.

Der Locator-Satz einer ISATAP-Schnittstelle darf nicht mehrere Standorte umfassen. Ein Standort ist aber kein selbstbeweisendes Adressmerkmal. Die Grenze entsteht erst durch IPv4-Routing, Namensdienst, Filter, Inventar und Änderungsprozesse.

An den Standortgrenzen sollen IPv4-Ingress und Protocol 41 gefiltert werden. Auch ein interner Knoten kann sich als Router ausgeben. Darum müssen Administratoren die PRL aktuell halten und ihren Auflösungsweg vor Manipulation schützen. Die veröffentlichte Adresse erbt ihre Vertrauenswürdigkeit von diesen Kontrollen.

Zwischen RS und Anwendung liegen mehrere Eigentümer

Der Host sendet RS an einen PRL-Kandidaten. Eine werbende ISATAP-Schnittstelle antwortet direkt mit RA. Die Link-Local-Quelle der RA muss eine ISATAP-Adresse sein, die den IPv4-Wert eines bekannten PRL-Eintrags enthält.

Eine akzeptierte RA ist ein konkreter Erfolg: Ein Kontrollpaket erreichte ein Ziel, und eine regelkonforme Antwort kam zurück. Trotzdem bleiben Router-, Präfix- und Routenlaufzeiten, Adresskonfiguration, Nachbarerreichbarkeit, Tunnel in beide Richtungen, Rückrouting und Anwendung offen.

RFC 5214 empfiehlt Neighbor Unreachability Detection auf Hosts. Nach der Adressauflösung soll eine erste Bestätigung über NS und NA erfolgen. Router dürfen das ebenfalls tun, wobei der Zustand nicht in jeder Umgebung skaliert. ARP-Fehler und dauerhafte ICMPv4-Fehler sind Hinweise auf einen möglicherweise ausgefallenen Nachbarpfad.

Ein sauberer Nachweis baut deshalb stufenweise auf: Quelle und Alter der PRL; IPv4-Route und ARP; Protocol-41-Politik; gesendete RS; validierte RA; akzeptierte Laufzeiten; konfigurierte Adresse; NS/NA; NUD; bidirektionale Pakete; externe IPv6-Ziele; Anwendungstransaktion. Kein früher Beleg darf die fehlende spätere Stufe ersetzen.

Anycast stabilisiert die Adresse und verbirgt die Instanz

RFC 6964 beschreibt mehrere werbende Router für Lastverteilung und Standortpartitionen. Eine IPv4-Anycast-Adresse kann in der PRL stehen und mehreren Geräten zugewiesen werden. Das IPv4-Routing entscheidet, welche Instanz antwortet.

Damit wird der Dienst widerstandsfähiger, während die einzelne Adresse weniger über den tatsächlichen Empfänger aussagt. Gestern antwortete Instanz A, heute B. Eine erfolgreiche RA von A beweist nicht, dass B dieselben IPv6-Routen, Filter, MTU-Werte und Softwarestände besitzt.

Werden unterschiedliche Präfixe von unterschiedlichen Routern getragen, braucht die Topologie ein IPv6-Routingprotokoll oder Companion Gateways, die den Rückweg zur richtigen Instanz kennen. Eine ausgehende RA verteilt diese Zuordnung nicht automatisch im übrigen Netz.

RFC 6324 zeigt beim Thema automatische Tunnelschleifen dieselbe Beweisgrenze. Eine umfassende Liste aller Tunnelrouter kann als Filter dienen, wenn sie tatsächlich vollständig ist und keine andere Tunnelart die Annahme verletzt. Vollständigkeit ist ein betriebliches Messergebnis, kein Versprechen des Feldnamens.

RFC 9099 bezeichnet ISATAP als nicht mehr häufig genutzt und hält seine Sicherheitsfragen dennoch für relevant. Daraus folgt keine weltweite Bestandszahl für 2026. Relevant bleibt die Struktur: Automatische Adressableitung und Discovery ersparen Arbeit, aber nicht die Verifikation des laufenden Pfads.

Ein Betriebsbeleg für Weiterbetrieb und Abschaltung

Ein ISATAP-Beleg sollte Standort und Locator-Grenze, PRL-Quelle, Werte, TTL und Zeit, Verantwortlichen jeder Adresse, IPv4-Route und ARP je Partition, Randfilter, RS/RA-Paare, Laufzeiten, NS/NA und NUD, Anycast-Mitgliedschaft, IPv6-Routen, bidirektionale Beobachtung, externes Ziel, repräsentative Anwendung sowie die Entfernung alter Einträge verbinden.

Dieser Beleg ist eine redaktionelle BTW-Analyse, keine neue Anforderung von RFC 5214. Beim Abschalten verhindert er, dass die Löschung des DNS-Namens als Ende gilt, obwohl manuell konfigurierte Hosts, Caches oder Protocol-41-Ausnahmen weiterleben.

Heng Lus Running-Code Primacy liefert die passende Trennung. Die gemeinsame Schicht enthält nur die deterministischen Mindestregeln für Interoperabilität und Sicherheit. Spätere Zustände werden lokal von den Teilnehmern geprüft, die das System betreiben. Die PRL darf den Ort der Frage koordinieren. Sie darf nicht zur Autorität über die Antwort erklärt werden.

Quellen

  1. RFC 5214
  2. RFC 5214 im IETF Datatracker
  3. RFC-5214-Informationsseite
  4. RFC-5214-Historie
  5. RFC 4213
  6. RFC 4861
  7. RFC 4862
  8. RFC 6964
  9. RFC 6324
  10. RFC 9099
  11. RFC 6169
  12. RFC 7059
  13. RFC 7123
  14. RFC 3756
  15. RFC 4191
  16. RFC 1035
  17. RFC 2131
  18. RFC 4301
  19. RFC-5214-Errata
  20. Heng Lu, Running-Code Primacy