Zusammenfassung

  • Eine laufende IPv4-Lease kann mit einer anderen IPv6-Quelladresse des Tunnels verknüpft werden. Die Zuteilung allein beschreibt daher nicht den vollständigen Betriebszustand.
  • RFC 8539 lässt dem Client unter bestimmten Voraussetzungen eine eigene Präfixwahl. Daraus folgt weder beliebige Erreichbarkeit noch anbieterübergreifende Portabilität.
  • Der Server kann die Häufigkeit von Quelländerungen begrenzen. Auch die Datenschutzwirkung ist gesondert zu prüfen: Eine neue Adresse beseitigt keine bereits bekannten Zusammenhänge.

Wer die Nutzbarkeit eines IPv4-Dienstes nur an der Laufzeit seiner Lease festmacht, übersieht möglicherweise eine zweite Koordinate. Wird IPv4-Verkehr durch ein IPv6-Netz getunnelt, muss der Anbieter wissen, welcher IPv6-Endpunkt zur zugeteilten Ressource gehört. Diese Zuordnung kann sich ändern, obwohl die IPv4-Lease weiterläuft.

Genau dafür beschreibt RFC 8539 eine dynamische Bereitstellung über DHCPv4 auf DHCPv6. Das Dokument erschien im März 2019; der offizielle Eintrag führt es weiterhin als Proposed Standard. Die Errata-Abfrage vom 8. September 2026 lieferte keine passenden Einträge. Das ist eine Auskunft über die Spezifikation, keine Prüfung eines konkreten Anbieternetzes.

Die interessante Frage lautet deshalb nicht, welches Adressprotokoll sich durchgesetzt hat. Sie lautet, was ein Kunde tatsächlich entscheiden darf, wenn er den Ausgangspunkt seines Tunnels wählen kann — und welche Abhängigkeiten diese Freiheit begleiten.

Erst die Reichweite, dann die Wahl

Die dynamische Konfiguration setzt ein geeignetes, bereits eingerichtetes IPv6-Präfix voraus. Es kann über DHCPv6, Router Advertisements oder auf anderem Weg bereitgestellt worden sein. Die IPv4-Lease erzeugt nicht zugleich den nötigen IPv6-Transportweg.

Innerhalb der routbaren IPv6-Topologie des Endnutzers kann der Tunnelendpunkt auf einem Gerät liegen, das nicht an einer vorher festgelegten Netzgrenze sitzt. Das eröffnet zusätzliche Möglichkeiten, den IPv4-Dienst zu platzieren. Es belegt weder die Unterstützung durch jedes Kundengerät noch die unveränderte Mitnahme des Dienstes zu einem anderen Anbieter.

Dabei sind die Angaben des Servers unterschiedlich verbindlich. Eine gültige Adresse des Border Relay ist notwendig; fehlt sie oder ist sie ungültig, verwirft der Client die Nachricht. Das bevorzugte Präfix dagegen ist ein Hinweis. Ein ungültiger Hinweis wird ignoriert, und die Verarbeitung läuft weiter, als wäre er nicht empfangen worden. Fehlt der Hinweis oder passt kein verfügbares Präfix dazu, darf der Client unter den genannten Bedingungen ein anderes gültiges Präfix mit geeignetem Geltungsbereich wählen.

Diese Unterscheidung beschreibt eine begrenzte Aufteilung von Entscheidungsrechten. Der Anbieter stellt den benötigten Relay-Endpunkt bereit, während der Client bei der Quelle einen gewissen Spielraum behält. Eine Empfehlung als absolutes Verbot anderer Präfixe darzustellen, würde die Serverkontrolle überzeichnen. Aus dem Spielraum die Freiheit zu beliebigen externen Adressen abzuleiten, würde umgekehrt die Clientautonomie überzeichnen.

Die Quelladresse kann bereits vorhanden sein oder neu gebildet werden. Erforderliche Konfiguration und gegebenenfalls Duplicate Address Detection müssen abgeschlossen sein, bevor der Client ihre Zuordnung anfordert. Er wählt somit einen verwendbaren Ausgangspunkt, nicht irgendeine Zeichenfolge, die das Netz anschließend erreichbar machen müsste.

Eine Ressource und die Zuordnung zu ihrem Nutzer

Der Server speichert die IPv6-Quelle zusammen mit der IPv4-Lease und der Clientkennung. Die Gültigkeit der Zuordnung folgt der Lease. Eine IPv6-Umnummerierung kann während dieser Zeit eine neue Quelle erfordern; der Client beantragt dann die entsprechende Änderung.

Jedes DHCPACK enthält die vom Server tatsächlich gebundene Quelladresse. Der Client muss diesen Wert mit seiner aktiven Quelle vergleichen. Der Nachrichtenname allein sagt nicht, ob der beantragte neue Wert übernommen wurde.

Die Architektur Lightweight 4over6 verdeutlicht den betrieblichen Stellenwert solcher Informationen. Sie verlagert die Adress- und Portübersetzung auf die Kundenseite. Der leichtgewichtige Übergangsrouter beim Anbieter hält eine Zuordnung aus IPv6-Adresse, öffentlicher IPv4-Adresse und beschränktem Portsatz. Damit findet er für eingehenden Verkehr den richtigen Tunnelendpunkt und prüft ausgehenden gekapselten Verkehr.

Eine solche teilnehmerbezogene Tabelle ist keine zentrale Sammlung sämtlicher Übersetzungssitzungen von Anwendungen. Weniger zentraler Sitzungszustand bedeutet aber nicht, dass der Anbieter überhaupt keinen Zustand mehr pflegen muss. Ebenso wenig bedeutet eine IPv4-Zuteilung bei beschränkten Ports eine unbegrenzte Kapazität für zusätzliche Verbindungen.

Für eine Effizienzbetrachtung reicht daher die Zahl der vergebenen Adressen nicht aus. Je nach Architektur gehören Portkapazität und Aufwand für die Zuordnungspflege dazu. Die Dokumente erklären technische Möglichkeiten für gemeinsame Nutzung und flexible Platzierung. Sie liefern keine gemessene Einsparung eines Betreibers und keinen Nachweis, dass jede Anwendungssitzung jede denkbare Umkonfiguration übersteht.

Beweglichkeit hat auch eine zeitliche Grenze

RFC 8539 erlaubt dem Server, einen Mindestabstand zwischen Quellaktualisierungen vorzusehen. Wird diese optionale Regel umgesetzt, beträgt der spezifizierte Standardwert 60 Sekunden. Eine zu früh eintreffende Änderungsanforderung darf unbeantwortet verworfen werden; alternativ kann ein ACK weiterhin die bisher gebundene Quelle enthalten.

Daraus folgt weder eine Wartepflicht für jeden Client noch ein allgemeines Wiederherstellungsversprechen von einer Minute. Ob die Regel aktiviert ist und welcher Wert tatsächlich gilt, muss im jeweiligen Betrieb geprüft werden. Wiederholungs- und Freigabeverhalten des Clients müssen zu dieser Umgebung passen.

Die möglichen Interessen sind verschieden. Häufige Quellenwechsel können Arbeit im Bereitstellungssystem verursachen; eine Begrenzung kann dieses System entlasten. Ein Kunde, dessen Quelle wegen einer Umnummerierung wechseln muss, erlebt dieselbe Begrenzung jedoch möglicherweise als Einschränkung der erneuten Nutzbarkeit. Die Spezifikation bewertet diese Kosten nicht gegeneinander. Sie belegt auch keine Absicht, Kunden zu behindern.

Eine weitere Grenze ist die Eindeutigkeit der Quelle unter aktiven Lease-Zuordnungen. Ein Konflikt bei einer neuen Zuteilung wird anders behandelt als ein Konflikt bei der Änderung einer vorhandenen Lease. Die gewünschte Beweglichkeit wird jedenfalls nicht dadurch hergestellt, dass die gültige Zuordnung eines anderen Kunden einfach überschrieben wird.

Die Laufzeit der Ressource ist also nur ein Teil des Angebots. Nutzbare Standorte und erlaubter Änderungsrhythmus sind weitere Teile. Wer nur „dynamisch“ verspricht, lässt offen, was im konkreten Fall tatsächlich möglich ist.

Eine neue Quelle ist noch keine anonyme Quelle

RFC 8539 warnt davor, dass ein unveränderlicher Interface Identifier die Wiedererkennung über Netze und Sitzungen hinweg ermöglichen kann. Das Dokument erörtert eine Bildung aus IPv4-Adresse und Portsatzkennung unter Verweis auf das MAP-E-Adressformat.

In diesem Zusammenhang erhält der Server dadurch keine zusätzlichen Clientinformationen über die bereits bekannten zugeteilten Ressourcen hinaus. Der gebildete Identifikator verändert sich mit der geleasten IPv4-Adresse. Diese Aussage ist bewusst begrenzt: Keine zusätzliche Information ist nicht dasselbe wie keine Information. Der Anbieter kennt weiterhin die aktive Zuteilung; gespeicherte frühere Zusammenhänge verschwinden nicht durch einen neuen Quellwert.

Die Anonymitätsprofile für DHCP-Clients erklären, weshalb eine wechselnde Adresse der Sicherungsschicht allein nicht genügt, wenn andere Kennungen stabil bleiben. Sie benennen zugleich betriebliche Folgen. Nach einem Identitätswechsel kann die bisherige Adresse weiterhin als geleast gelten, während eine neue vergeben wird. Wiederkehrenden Clients dieselbe Adresse zuzuteilen, Namen zu veröffentlichen oder den Zugang auf registrierte Kennungen zu beschränken, kann mit Anonymitätsentscheidungen in Spannung stehen.

Das ist keine Aufforderung, sämtliche Kennungen fester Breitbandanschlüsse ständig zufällig zu wechseln. Der passende Umgang hängt vom Nutzungskontext ab. Derselbe Nutzer kann in einem bekannten Netz eine stabile Zuteilung und in einem anderen Umfeld weniger Wiedererkennbarkeit wünschen. Ein Produkt, das Beweglichkeit, Stabilität und Anonymität gleichsetzt, verdeckt diese Entscheidung.

Auch Sicherheitsannahmen begrenzen die Anwendung. RFC 8539 sieht dedizierte Layer-2-Konnektivität je Client vor und empfiehlt den Einsatz auf einem gemeinsam genutzten Medium nicht. Eingangsfilterung und Prüfung am Border Relay gehören zum defensiven Kontext. Die Quellenwahl ist eine begrenzte Delegation innerhalb dieser Bedingungen, kein Recht, beliebige Herkunft zu behaupten.

Lu Heng fordert in Notiz 36, reale Strukturen zu beschreiben statt Lösungen zu bewerben. Für diese Konstruktion heißt das: Dynamische Bereitstellung erweitert die Platzierungsoptionen. Die Pflege der Zuordnung, die Macht über Aktualisierungen und die Wirkung von Identifikatoren bleiben bestehen.