Résumé

  • IPV6_ADDR_PREFERENCES formule un souhait par socket ; sa réussite ne certifie ni la disponibilité de l’attribut, ni l’adresse finalement retenue.
  • Une exigence ferme impose une autre chaîne : préférences cohérentes, sélection sans émission prématurée, relecture, validation de l’attribut, puis observation distincte du réseau et de l’application.

Un comité de risque lit « adresse temporaire préférée » dans un rapport et reformule la ligne en « adresse temporaire utilisée ». Le premier énoncé est une consigne. Le second est un constat. Entre les deux, le système a travaillé sans laisser de reçu.

Le RFC 5014 a été publié en 2007 pour résoudre un problème d’interface bien délimité. Une application pouvait déjà fixer une source avec bind() ou IPV6_PKTINFO, mais elle devait alors reprendre à sa charge la pertinence de cette adresse pour la destination, l’interface et la portée. Le nouveau mécanisme permet d’infléchir quelques règles tout en laissant la pile exécuter le reste de la sélection.

Trois couples structurent la demande : adresse de domicile ou adresse temporaire de rattachement, adresse temporaire ou publique, CGA ou non-CGA. Chaque drapeau a son contraire. On peut croiser plusieurs dimensions, mais associer les deux termes d’un même couple est contradictoire. L’option de socket échoue alors avec EINVAL, et l’extension de getaddrinfo() avec EAI_BADEXTFLAGS.

Cette discipline empêche une demande incohérente ; elle ne transforme pas la demande en obligation. Le texte le dit sans détour : le mécanisme exprime des préférences et non des exigences fermes. Si l’application préfère une adresse temporaire alors que l’hôte n’en possède aucune, une adresse publique peut être choisie. Si une préférence combinée comporte un attribut indisponible, l’autre attribut peut survivre et la politique par défaut décide du reste. Les drapeaux non pris en charge doivent même être ignorés silencieusement.

Le succès de setsockopt() prouve donc une opération de configuration. Il ne prouve pas que l’hôte disposait du candidat voulu. Il ne décrit pas les autres règles de tri et n’identifie pas la source qui apparaîtra dans une trame.

La résolution ajoute une seconde scène. Puisque l’ordre des destinations peut dépendre de la source envisageable, RFC 5014 étend getaddrinfo(). L’application doit transmettre des préférences sémantiquement équivalentes au résolveur et au socket. Si les deux appels divergent, le comportement est déclaré indéfini. Un contrôle qui journalise l’option de socket mais oublie l’ordre renvoyé par le résolveur ne garde qu’une moitié de la décision.

Une instruction explicite peut encore prendre le dessus. Lorsqu’un bind() ou IPV6_PKTINFO fixe une source en même temps que l’option exprime une préférence, l’adresse explicite l’emporte. Le drapeau reste présent, mais il n’est plus l’autorité effective.

Le chapitre de validation du RFC est la frontière essentielle. Pour une application qui ne peut accepter la « mauvaise » propriété, les préférences ne garantissent pas le respect de l’exigence. Le programme doit présenter les mêmes drapeaux à getaddrinfo() et au socket, provoquer la sélection, relire l’adresse choisie avec getsockname(), la tester avec inet6_is_srcaddr(), puis renoncer à communiquer si le résultat ne convient pas.

Même « provoquer la sélection » doit être qualifié. Sur un transport orienté connexion, connect() peut envoyer un SYN avant que l’application ne vérifie la source. RFC 5014 propose bind2addrsel() pour lier la source que la pile choisirait sans envoyer ce premier paquet. Pour UDP, connect() réalise localement la sélection sans transmettre de datagramme. Une adresse retenue n’est pas encore une adresse observée sur le réseau.

La fonction de validation rend trois résultats : vrai si l’adresse appartient au nœud et satisfait tous les attributs demandés, faux si les attributs ne correspondent pas, erreur si l’adresse n’est pas locale ou si l’entrée est invalide. Le vrai reste étroit. Le test « domicile » peut réussir sur un hôte sans Mobile IPv6 ou sur un mobile revenu chez lui. Ce n’est ni une localisation physique ni une identité d’utilisateur.

Il faut appliquer la même prudence aux mots séduisants. Le RFC 8981 explique que le renouvellement des adresses temporaires réduit la fenêtre de corrélation triviale fondée sur l’adresse. Il ne promet pas l’anonymat aux couches supérieures. Le RFC 3972 relie une CGA à une clé publique par sa construction, tout en précisant que la CGA n’est pas certifiée. Préférer une CGA n’équivaut pas à vérifier une signature ou une autorisation.

Les valeurs par défaut sont historiques. RFC 5014 s’appuyait sur le RFC 3484, qui préférait alors l’adresse publique. Le RFC 6724 l’a remplacé et privilégie l’adresse temporaire dans cette règle. Aucun audit sérieux ne peut déduire le comportement actuel d’une machine de la seule date d’un texte.

Un reçu de sélection devrait conserver l’identité de l’application et du socket, les drapeaux demandés et la valeur antérieure, les drapeaux équivalents du résolveur, l’ordre des destinations, les attributs ignorés, l’ensemble des candidats, la version de politique, tout bind() explicite, l’appel de sélection, la possibilité d’une émission préalable, l’adresse relue, le résultat ternaire de validation, la décision de poursuivre ou d’abandonner, puis les paquets et le résultat applicatif observés séparément.

Cette liste est une recommandation d’exploitation, non une obligation dissimulée du RFC. Elle transpose les couches de réalité de Heng Lu : le souhait appartient à l’application ; le choix, à la pile à un instant donné ; l’attribut, au test local ; la joignabilité, au chemin ; le succès, au service. Les fusionner fabrique une assurance que le protocole n’a jamais fournie.

Sources