Zusammenfassung

  • draft-ietf-v6ops-ipv6-app-testing-03 trennt IPv4-only, Dual Stack, IPv6-only mit NAT64 und IPv6-only-strict ohne relevante IPv4-Erreichbarkeit. Ein Dual-Stack-Erfolg kann nur einen gelungenen Fallback belegen.
  • Installation, Bedienoberfläche, Management und Update sind unabhängige Flächen. Eine belastbare Aussage nennt jeden wichtigen Fluss, das anwendbare Szenario, den Nachweis der Testbedingung sowie Transport- und Anwendungsergebnis.

Ein grünes Feld sprach für nicht geprüfte Wege

Eine Benutzerreise durchläuft selten das ganze Produkt. Frontend, Identität und Haupt-API können funktionieren, ohne Aktivierung, Paketquelle, Telemetrie, Fernwartung, Sicherung oder Wiederherstellung auszulösen. Wer daraus ein Produktabzeichen macht, lässt den beobachteten Pfad für abwesende Pfade sprechen.

Die vier Bedingungen der Revision 03 sind keine vier Aufkleber. Sie gelten für einen gerichteten Fluss einer Version, eine Lebenszyklusfunktion, Rollen von Client und Server und mögliche Vermittler. Der Beleg verbindet diese Faktoren mit erwartetem und beobachtetem Ergebnis.

In einer Cloud-Anwendung zerfällt der Ende-zu-Ende-Test in Kanten. Load Balancer, Gateway, Authentisierung, Autorisierung, Datenbank und Logging kommunizieren getrennt. Eine Komponente ist einmal Client, einmal Server. Der Enderfolg beweist weder IPv6 auf jeder Kante noch die Funktionsfähigkeit einer nicht ausgelösten Kante.

Ein blindes kartesisches Produkt ist nicht nötig. Eine kontrollierte Architektur darf Kombinationen ausschließen. Aber der Ausschluss braucht Version, Eigentümer und prüfbaren Grund. Eine fehlende Zeile ist unbekannt, nicht bestanden.

Dual Stack kann den Fehler verdecken, den es umgeht

Happy Eyeballs schützt Nutzer, verändert aber den Beweis. IPv6 kann nach TCP und vor TLS scheitern; IPv4 beendet den Vorgang. RFC 8305 reduziert Wartezeit zwischen Kandidaten und zertifiziert nicht den Verlierer.

DNS64 nach RFC 6147, Adressen nach RFC 6052 und 464XLAT nach RFC 6877 können eine IPv4-Abhängigkeit erreichbar machen. Das ist im Übergangsszenario gültig und im strict-Szenario eine Verunreinigung. CLAT, DNS64, NAT64-Präfix, VPN, Tunnel und Relay brauchen einen expliziten Nachweis.

Der Beleg hält DNS-Antworten, Kandidaten, gewählte Familie, Versuche, Fallback-Zeit, Proxy oder Übersetzer, Transport- und Anwendungsergebnis fest. Nur den letzten Erfolg zu speichern löscht den Fund.

Auch das Testbett kann versagen. Das Abschalten von IPv4 kann VM-Verwaltung oder Anmeldung zerstören. Testbettgesundheit und Produktgesundheit sind getrennte Belege.

Lebenszyklus bedeutet mehr als die Hauptoberfläche

Der Entwurf trennt Installation, UI, Management und Update. Installer benötigen Aktivierung oder Pakete; Management umfasst API, SNMP, Syslog und Monitoring; Updater nutzen andere Prozesse, Zertifikate, Spiegel und Rückwege.

Eine UI prüft keinen Installer. Eine Management-API beweist nicht korrekte IPv6-Quellen in Logs. Ein manuelles Update deckt den unbeaufsichtigten Agenten nicht zwingend ab. Der Bericht wird nach Flüssen und Eigentümern organisiert, nicht nach Screenshots.

Ein Proxy fügt ein drittes Bein hinzu. IPv6 vom Client zum Proxy sagt nichts über Proxy zum Ursprung. TURN erweitert Kandidaten; RFC 8656 beschreibt Relay-Verhalten, nicht die Vollständigkeit einer Kampagne.

Wiederverwendung macht die Prüfung rekursiv. Ein AAAA an einem gemeinsamen Dienst kann andere Produkte über IPv6 erreichen lassen, bevor deren Zugriffslisten und Logs bereit sind. Das Manifest gehört deshalb zu Versions- und Abhängigkeitsdaten.

Adressen sind auch Daten und Befugnis

Anwendungen validieren, zeigen, speichern, vergleichen und autorisieren Adressen. RFC 4291 definiert die Architektur, RFC 5952 empfiehlt Textdarstellung. Geschäftslogik kann dennoch nur Punktdezimal akzeptieren, Text abschneiden oder gleichwertige Formen trennen.

Zugriffslisten zeigen die Grenze. Nach Veröffentlichung eines AAAA kommen fähige Clients über IPv6. Kennt die Autorisierung nur IPv4, gelingt der Transport und die Anwendung verweigert. Happy Eyeballs repariert keine Richtlinie nach dem Verbindungsaufbau.

IPv6 empfangen zu können, ohne die Quelle in Audit oder Missbrauchsbearbeitung zu finden, ist ebenfalls unvollständiger Betrieb. Ein hoher IPv6-Anteil kann einen kritischen IPv4-gebundenen Managementweg verbergen.

Eine Aufzeichnung beweist nur ihre Beobachtung

Wenn strikte Isolation nicht möglich ist, stützen Logs und Mitschnitte eine engere Aussage. Kein IPv4 im Capture gilt für Schnittstelle, Filter, Zeitfenster und bekannte Flüsse. Späte Jobs, bedingte Zweige oder neue Abhängigkeiten bleiben offen.

Der Entwurf nennt Netzwerk-Tracing die fehleranfälligste Alternative, weil der Auswerter das Kommunikationsmuster bereits kennen muss. Vertretbar ist: „Alle Flüsse des Manifests X wurden in Lauf Y über IPv6 beobachtet.“ Nicht: „Es gibt keine verborgene IPv4-Abhängigkeit.“

Last Call ist kein Produktionsbeleg

Die Quelle ist Revision 03 vom 29. September 2026, Ablauf 2. April 2027. Datatracker führt sie als aktives V6OPS-WG-Dokument, I-D Exists, im WG Last Call. Der Kopf nennt Best Current Practice als Ziel, das intended-status-Feld ist leer. Sie ist weder RFC noch BCP.

Das Dokument vereinheitlicht Fragen und führt keine Tests aus. RFC 8504 stellt Knotenanforderungen, ersetzt aber keine Anwendungstests. RFC 8585 beschreibt Unternehmensszenarien und zertifiziert keine Abhängigkeit.

Running-Code Primacy hält die Reihenfolge: Leitfaden, Manifest, Testbedingung, Beobachtung, Anwendungsergebnis, Produktion. Keine Schicht erzeugt die nächste durch Erklärung.

Quellen