Zusammenfassung

  • Ein erfolgreich gesetztes IPV6_ADDR_PREFERENCES belegt den konsistenten Wunsch der Anwendung, nicht die Verfügbarkeit oder Auswahl der gewünschten Adresseigenschaft.
  • Bei einer harten Anforderung muss die Anwendung die Auswahl herbeiführen, die Adresse zurücklesen, ihre Eigenschaft prüfen und gegebenenfalls abbrechen; Paket und Ergebnis sind danach weiterhin separat zu beobachten.

In einem Prüfbericht wird aus einem gesetzten Bit ein Nachweis: „temporäre Quelle verwendet“. Der Bericht kennt aber weder die Kandidaten noch die Adresse, die der Host tatsächlich gewählt hat.

RFC 5014 schließt eine eng begrenzte API-Lücke. Anwendungen konnten eine Quelle bereits mit bind() oder IPV6_PKTINFO festlegen, mussten dann aber Eignung für Ziel, Schnittstelle und Gültigkeitsbereich selbst beurteilen. Die neue Option lässt sie einzelne Präferenzen ändern, während das System die übrigen Auswahlregeln behält.

Die sechs Flags bilden drei Gegensatzpaare: home/care-of, temporary/public und CGA/non-CGA. Eigenschaften aus verschiedenen Paaren dürfen kombiniert werden. Beide Seiten desselben Paars sind widersprüchlich und führen zu EINVAL am Socket beziehungsweise EAI_BADEXTFLAGS bei getaddrinfo(). Eine widerspruchsfreie Eingabe ist noch keine erfüllte Vorgabe.

Der Standard spricht absichtlich von Präferenzen. Fehlt trotz IPV6_PREFER_SRC_TMP jede temporäre Adresse, darf eine öffentliche Adresse gewählt werden. Ist bei einer Kombination nur ein Attribut verfügbar, beeinflusst dieses die Wahl und für den Rest gilt die Systemvorgabe. Nicht unterstützte Flags sollen still ignoriert werden. Der Erfolg der API verrät nicht, welcher Fall eingetreten ist.

Auch der Resolver besitzt eine Kontrollkante. Die erwartete Quelle kann die Reihenfolge der Ziele beeinflussen. Deshalb müssen getaddrinfo() und Socket semantisch gleiche Flags erhalten; bei Abweichung ist das Verhalten undefiniert. Wer nur die Socket-Option protokolliert, kann die vorherige Zielsortierung nicht erklären.

Explizite Festlegung schlägt Präferenz. Eine mit bind() oder IPV6_PKTINFO gesetzte Quelle hat Vorrang. Das Präferenzbit kann weiterhin im Zustand stehen, obwohl es die wirksame Entscheidung nicht getroffen hat.

Für harte Anforderungen sagt RFC 5014 ausdrücklich, dass Präferenzen ihre Erfüllung nicht garantieren. Die Anwendung setzt gleiche Flags für Resolver und Socket, lässt eine Quelle auswählen, liest sie mit getsockname() zurück, prüft sie mit inet6_is_srcaddr() und bricht ab, wenn die Eigenschaften fehlen.

Die Auswahl kann schon eine Wirkung haben. Bei TCP kann connect() vor der Prüfung ein SYN senden. bind2addrsel() bindet deshalb die voraussichtlich gewählte Quelle für ein Ziel, ohne die Verbindung zu starten. Bei UDP kann connect() lokal auswählen, ohne selbst ein Datagramm zu senden. „Ausgewählt“ ist nicht „übertragen“.

Die Prüffunktion liefert 1, 0 oder -1: lokale Adresse mit allen verlangten Eigenschaften, Nichtübereinstimmung oder ungültige/nicht lokale Eingabe. Auch 1 belegt keinen entfernten Pfad. Das Merkmal home kann bei einem Host ohne Mobile IPv6 oder bei einem mobilen Knoten zu Hause wahr sein. Es ist kein Ortsnachweis.

Ebenso eng sind temporary und CGA zu lesen. RFC 8981 verkürzt durch wechselnde temporäre Adressen das Fenster einfacher adressbasierter Verknüpfung; andere Identifikatoren bleiben möglich. RFC 3972 bindet eine CGA an Schlüsselmaterial, doch CGAs sind nicht zertifiziert. Eine CGA-Präferenz ist weder Signaturprüfung noch Identitäts- oder Autorisierungsbeleg.

Schließlich änderten sich die Standardwerte. RFC 5014 bezog sich auf RFC 3484, der öffentliche Quellen bevorzugte. RFC 6724 löste ihn ab und bevorzugt in dieser Regel temporäre Quellen. Entscheidend sind Kandidaten und Richtlinienstand des konkreten Hosts.

Ein belastbarer Beleg hält Anwendung und Socket, gewünschte und vorherige Flags, Resolver-Flags und Zielreihenfolge, ignorierte Fähigkeiten, Kandidatenmenge, Richtlinienstand, explizite Quelle, Auswahlmethode, mögliches frühes Senden, getsockname()-Wert, dreistelliges Prüfergebnis, Fortfahren oder Abbruch sowie beobachteten Ausgangsverkehr, Rückverkehr und Anwendungsergebnis getrennt fest.

Das ist eine betriebliche Empfehlung, keine versteckte Pflicht des RFC. Sie folgt Heng Lus Trennung der Realitätsebenen: Absicht, Hostauswahl, lokale Eigenschaft, Pfad und Geschäftsergebnis dürfen erst zusammengeführt werden, wenn eine beweisbare Kante existiert.

Quellen