Zusammenfassung

  • preferred_address authentisiert die vom Server für diese Verbindung gelieferten Werte, nicht die Erreichbarkeit vom Client aus.
  • Nach bestätigtem Handshake wählt der Client IPv4 oder IPv6, verwendet eine ungenutzte Verbindungs-ID und validiert den Pfad vor der Migration.
  • Validierung, MTU, Überlastung und RTT, Anwendungskontinuität und Geschäftsergebnis müssen getrennt erfasst werden.

Der typische Fehler entsteht, wenn ein Inventar eine angekündigte bevorzugte Adresse als aktiven Endpunkt markiert, bevor der Client den Pfad getestet hat. QUIC erlaubt dem Server, eine Verbindung an einer IP-Adresse anzunehmen und kurz nach dem Handshake eine andere Adresse anzubieten. Das kann sinnvoll sein, wenn die ursprüngliche Adresse von mehreren Servern geteilt wird und eine Unicast-Adresse größere Verbindungsstabilität ermöglichen könnte. Das Angebot ist dennoch keine Messung des Zielpfads.

Nur der Server sendet den Transportparameter preferred_address; er wird im TLS-Handshake übertragen. Der authentisierte Empfang beweist, welche Werte der Peer für diese Verbindung geliefert hat. Er beweist nicht, dass der Client das IPv4- oder IPv6-Tupel erreichen kann, dass die Pfadvalidierung gelingt oder dass der Pfad ein nutzbares MTU, verfügbare Kapazität, künftige Verfügbarkeit, Anwendungskontinuität oder ein erfolgreiches Geschäftsergebnis besitzt.

Der Parameter kann eine IPv4-Adresse mit Port und eine IPv6-Adresse mit Port enthalten. Eine Familie darf durch eine vollständig auf null gesetzte Adresse und Port ausgelassen werden. Das verschafft dem Client eine Wahl passend zu seinem Netzzugang; es sagt nicht, dass beide Pfade von diesem Client getestet wurden. Nach bestätigtem Handshake wählt der Client eine Adresse und startet die Validierung. Der Server startet diese Migration nicht. Der Client sollte eine zuvor ungenutzte aktive Verbindungs-ID aus preferred_address oder NEW_CONNECTION_ID verwenden. Die alternative ID hat die Sequenznummer 1 und ein 16-Byte-Stateless-Reset-Token. Die ID ist nicht an die bevorzugte Adresse gebunden und kann auf jedem Pfad verwendet werden.

Ein Server mit einer Verbindungs-ID der Länge null kann keine bevorzugte Adresse liefern; der Parameter darf ebenfalls keine solche ID enthalten. Verstöße sind TRANSPORT_PARAMETER_ERROR. Vor der Validierung darf der Client keine Nicht-Probing-Frames an die bevorzugte Adresse senden. Das begrenzt die Angriffsfläche für Request-Forgery. PATH_CHALLENGE und PATH_RESPONSE gehören zur Validierung; ein späterer Erfolg macht die ursprüngliche Ankündigung nicht rückwirkend zu einer Messung.

Bei erfolgreicher Validierung sollte der Client künftige Pakete mit der neuen ID an die neue Serveradresse senden und die alte Serveradresse nicht weiter verwenden. Bei einem Fehlschlag muss er an die ursprüngliche Server-IP senden. Der Server hat eigene Bedingungen: Er sondiert von der bevorzugten Adresse und sendet Nicht-Probing-Verkehr weiter von der ursprünglichen Adresse, bis er ein Nicht-Probing-Paket des Clients an der bevorzugten Adresse erhält und den neuen Pfad validiert. Erst dann sendet er ausschließlich von der bevorzugten Adresse, kann aber verspätete Pakete an der alten Adresse noch verarbeiten.

Die bevorzugte Adresse gilt nur für die Verbindung, in der sie geliefert wurde, nicht für andere oder wiederaufgenommene Verbindungen. disable_active_migration verhindert dieses ausdrücklich durch die Peer-Ankündigung ausgelöste Verfahren nicht. Bewegt sich der Client zuerst, sollte er die ursprüngliche und die bevorzugte Serveradresse von seiner neuen Clientadresse aus parallel validieren. Eine geänderte NAT-Bindung kann dazu führen, dass der Server an der bevorzugten Adresse eine andere Clientquelle sieht; dann wendet er Spoofing-Schutz an und validiert zu dieser Quelle.

Das Betriebsregister trennt authentisierten Empfang, IPv4/IPv6-Tupel einschließlich null gesetzter fehlender Familien, geschützten Digest der Sequenz-1-ID und Token-Referenz, Handshake-Bestätigung, Familien- und Auswahlentscheidung, tatsächlich verwendete ungenutzte ID, Validierungsbeginn, Ergebnis und Abbruchgrund, Client-Umschaltung und Rückfall, Server-Probe und -Umschaltung, NAT-Änderung, MTU, Überlastung/RTT, Anwendungskontinuität und Geschäftsergebnis. Datenschutzschonende Digests und Aufbewahrungskontrollen sind Betriebsempfehlungen, keine QUIC-Pflichten.

Das bleibt getrennt von TR-027 zur allgemeinen Migrationskonvergenz, TR-040 zum Verbindungs-ID-Inventar, TR-059 zur Abgrenzung von Empfangsgrenze und Pfad-MTU, TR-062 zur abgeschlossenen Rückkanal-Evidenz und TR-047 zu Leerlaufgrenzen. Eine erfolgreiche Validierung hat eine begrenzte Aussage. Eine Einladung wird nicht zur Garantie.