Zusammenfassung

  • Eine IPv6-Umnummerierung ist Make-before-break und kein einzelner Routingbefehl. Altes und neues Präfix müssen parallel funktionieren, während Routen, Filter, Adressen, DNS und Anwendungen unterschiedlich schnell wechseln.
  • Operative Einordnung: Preferred und Valid Lifetime, delegierte Präfixe, Resolver-Konfiguration, positive und negative DNS-Caches, Quelladresswahl und langlebige Sitzungen bilden eine gemeinsame Entscheidungsgrenze.
  • Rollback ist keine atomare Protokolltransaktion. Er muss erprobt werden, solange Betreiber das alte Präfix, die Reverse-Zone und beide Verkehrspfade noch kontrollieren.

Eine bereits geteilte Umschaltung

In einer Niederlassung ist das neue Aggregat upstream sichtbar, die autoritative Zone veröffentlicht den neuen AAAA-Eintrag, und ein Monitoring-Test erreicht den Dienst. Dennoch hält der Standort-Router das alte delegierte Präfix, ein rekursiver Resolver liefert die alte Antwort aus seinem Cache, und eine Datenbanksitzung bleibt an die frühere Adresse gebunden. Neue Verbindungen vermeiden die Adresse, sobald sie deprecated ist; die laufende Sitzung wandert nicht automatisch.

Jedes Teilsystem kann eine wahre Aussage melden: Die Route steht, DNS wurde geändert, der Client besitzt eine neue Adresse, der Dienst antwortet. Die Gesamttransaktion bleibt riskant, weil sich diese Aussagen auf unterschiedliche Uhren beziehen.

RFC 4192 beschreibt die Umnummerierung ohne Flag Day: Das neue Präfix wird bei weiterlaufendem alten Präfix aufgebaut, ein stabiler Doppelzustand erreicht, die Nutzung verschoben und erst danach das alte Präfix entfernt. Das Dokument liefert ein anzupassendes Gerüst, keine universelle Automatisierung. Das Protokoll bietet Mechanismen; der Betreiber schuldet den Abschlussnachweis.

Ein Präfix steckt nicht nur in der Route

IPv6-Adressen stehen in Linkplänen, Router-Interfaces, Router Advertisements, DHCPv6, Präfixdelegationen, Ingress- und Egress-Filtern, ACLs, Dienstkonfigurationen, Forward- und Reverse-DNS, Allowlists, Monitoringzielen und Anwendungscaches. RFC 6879 ergänzt manuelle Konfiguration, langlebige Sitzungen und Systeme außerhalb der direkten Kontrolle des Netzteams.

Damit ist das Inventar Teil des Beweises. Eine erfolglose Suche nach Literalen reicht nicht: Eine Adresse kann aus einem Präfix abgeleitet, im Arbeitsspeicher gehalten, in den Filter eines Partners kopiert oder auf einem während der Überlappung ausgeschalteten Standort gespeichert sein. Der Beleg muss geprüfte Fläche, Änderungsversion, Verantwortliche und Ausnahmen nennen.

Preferred, valid und genutzt sind drei Zustände

RFC 4862 gibt einer automatisch konfigurierten Adresse zwei Uhren. Nach Ablauf der Preferred Lifetime ist sie deprecated, nach Ablauf der Valid Lifetime invalid. RFC 6724 lässt die Standard-Quelladresswahl deprecated Adressen vermeiden, wenn eine passende preferred Adresse vorhanden ist.

Deprecation beeinflusst neue Kommunikation. Sie beweist weder den Abbau alter Sitzungen noch das Aktualisieren gespeicherter Peers oder das Verschwinden eines alten AAAA aus externen Caches. Die alte Adresse valid zu halten bewahrt eine Wiederherstellungsfläche, kann aber Abhängigkeiten verdecken, wenn Flüsse nicht nach Präfix und Alter gemessen werden.

Die Zwei-Stunden-Regel aus RFC 4862 begrenzt zudem, wie stark ein nicht authentifiziertes Router Advertisement die verbleibende Valid Lifetime verkürzen kann. Das schützt vor sofortiger böswilliger Invalidierung, bedeutet aber auch: Ein zentraler Notfallbefehl ist kein sicherer universeller Ausschalter. Maßgeblich ist das Verhalten der Hosts, nicht nur die Controller-Anzeige.

Standort und Resolver haben eigene Uhren

RFC 8415 transportiert Preferred und Valid Lifetime für DHCPv6-Adressen und delegierte Präfixe sowie Renew- und Rebind-Verhalten. Ein Kundenrouter kann ein altes IA_PD behalten, obwohl Upstream-Route, SLAAC-Host und autoritative Zone bereits gewechselt haben. Ein während der Überlappung ausgeschalteter Standort kann mit nie geprüftem Zustand zurückkehren.

RFC 8978 zeigt, dass veraltete SLAAC-Präfixe nach einer schnellen Umnummerierung fortbestehen können. RFC 9096 empfiehlt, einschlägige Router-Advertisement-Laufzeiten mit der verbleibenden Gültigkeit des delegierten Präfixes abzustimmen. Das sind Betriebshinweise, keine Garantie für einheitliches Verhalten aller Kundenrouter. RFC 4472 weist außerdem darauf hin, dass langlebige Anwendungen DNS-Ergebnisse über die TTL eines Eintrags hinaus behalten können; deshalb ist das Anwendungsverhalten zu messen, nicht eine universelle Cache-Dauer anzunehmen.

DNS fügt weitere Uhren hinzu. TTLs steuern gecachte AAAA- und PTR-Antworten. Die Übertragung zwischen autoritativen Servern hat eigene Verzögerung. Per Router Advertisement gelernte Resolver und Suchlisten besitzen RDNSS- und DNSSL-Laufzeiten nach RFC 8106. Den Dienst umzustellen und den zu seiner Suche verwendeten Resolver umzustellen sind verschiedene Vorgänge.

Positive Antworten sind nicht der gesamte Cache. RFC 2308 regelt Negative Caching. Wurde ein neuer Name vor seiner Anlage abgefragt, kann ein Resolver auch nach Veröffentlichung bis zum Ablauf negativ antworten. Nur die AAAA-TTL zu erfassen begrenzt diesen Fehler nicht.

RFC 4861 vervollständigt die lokale Ebene: Hosts interpretieren Router- und Präfixinformationen aus Advertisements über Zeit. Zu beobachten ist, was der Host gelernt hat, nicht nur die Soll-Konfiguration des Routers.

Konvergenz ist das Maximum

Operative Einordnung: Das brauchbare Modell nimmt das Maximum der offenen Uhren für Route, Filter, PIO, IA_PD, RDNSS, positiven Cache, negativen Cache, Anwendung und Sitzung und ergänzt jede statische Ausnahme ohne Timer.

Ein Durchschnitt verbirgt den ausgeschalteten Standort, den Resolver mit längerer negativer Speicherung, die per Ticket geänderte Partner-ACL und das Gerät, das nur beim Start auflöst. Der richtige Nenner umfasst jede erklärte Abhängigkeit und jeden Messpunkt, nicht nur während des Fensters meldende Geräte.

Eine Routensonde beweist Erreichbarkeit über das neue Präfix. Eine DNS-Abfrage beweist die aktuelle Antwort eines Resolvers. Ein Flow-Export beweist beobachtete Nutzung. Keiner dieser Befunde genehmigt allein die Entfernung. Entscheidend werden sie erst an derselben Änderungsversion und demselben Ausnahmebuch.

Quellen