Résumé

  • Le RFC 7844 ne promet pas une « adresse anonyme » : il définit un profil qui coordonne DUID, IAID, anciennes adresses, identifiants de serveur, FQDN et options de classe lors d’un changement de lien.
  • Le choix et l’ordre des options suffisent parfois à reconnaître une implémentation. Le profil réduit la demande et en varie l’ordre afin que le mode de confidentialité ne devienne pas lui-même une signature.
  • Cet oubli a un prix : davantage d’anciens baux, une pression possible sur les pools et les tables, et parfois un refus d’accès sur les réseaux réservés aux appareils préenregistrés. La réduction de corrélation DHCP n’est pas l’invisibilité.

Le retour discret d’une ancienne identité

Une adresse se voit facilement dans une capture. Son remplacement donne donc un récit séduisant : avant et après, deux valeurs, deux présences. Le RFC 7824 avait commencé par contester ce raccourci. DHCP transporte plusieurs éléments capables de survivre au changement le plus visible.

Le DUID permet au serveur DHCPv6 de reconnaître le client. L’IAID distingue ses associations d’identité. Un Client FQDN peut nommer l’hôte. User Class, Vendor Class et les informations propres au constructeur caractérisent son usage ou son logiciel. L’Option Request Option indique les paramètres souhaités. Une ancienne adresse proposée comme préférence, ou un Server Identifier conservé, réintroduit encore le contexte précédent.

Aucun champ ne doit nécessairement être unique au monde. La corrélation travaille par faisceau d’indices. Un DUID durable associé à une combinaison rare d’options peut rapprocher deux visites. Certains types de DUID contiennent même une adresse de couche liaison : la nouvelle adresse radio est alors contredite par l’identifiant transporté plus haut.

Publié en 2016 par Huitema, Tomek Mrugalski et Suresh Krishnan, le RFC 7844 transforme cet inventaire en profil d’anonymat. Son ambition est bornée : diminuer ce que DHCP révèle quand l’utilisateur choisit ce mode. La normalisation évite un autre piège. Si chaque système protège différemment sa confidentialité, ces différences constituent une collection de nouvelles empreintes.

Donner une fin au DUID

Dans le fonctionnement ordinaire, un identifiant stable rend service. Le serveur retrouve un client, prolonge un bail et maintient certaines politiques. Mais quand le client adopte une nouvelle identité de liaison, garder le DUID antérieur rétablit précisément le pont qu’il cherchait à couper.

Le profil rattache donc le cycle de vie DHCP au changement de lien. Avec une adresse de couche liaison aléatoire, l’identité DHCP ne doit pas lui survivre silencieusement. Le texte prévoit également un traitement aléatoire du DUID-LLT dans les situations pertinentes où l’adresse liaison n’est pas randomisée.

Le RFC 9915, base actuelle de DHCPv6 publiée en 2026, conserve la stabilité du DUID comme règle générale tout en citant l’exception du RFC 7844. Les deux textes ne s’annulent pas. Ils expriment deux finalités : continuité du service dans un cas, rupture volontaire de corrélation dans l’autre.

L’IAID pose la même question à une échelle plus courte. Sa stabilité utile appartient à l’association de liaison en cours ; il ne doit pas devenir une empreinte permanente de la machine. Un audit doit toujours compléter « stable » par trois précisions : pour quel acteur, à travers quel événement et au profit de quel service ?

La mémoire des anciennes adresses révèle ce conflit de façon concrète. Retrouver une adresse précédente peut faciliter la continuité, mais en faire la demande déclare l’histoire du client. Le profil impose de supprimer ces adresses lorsque l’identité liaison change. La commodité et la séparation ne peuvent être maximisées simultanément.

L’empreinte qui ne porte aucun nom

Le RFC 7824 distingue l’identification explicite de l’empreinte. Les clients ne demandent pas tous les mêmes paramètres, ni dans le même ordre. Ce motif peut révéler une famille de systèmes ou une implémentation sans présenter un seul champ intitulé « identité ».

La réponse du RFC 7844 tient dans une discipline de minimisation : demander le sous-ensemble nécessaire, varier l’ordre, ne pas répéter d’anciennes valeurs parce qu’elles existent en cache, écarter par défaut User Class, Vendor Class, les données constructeur et Client FQDN. Un nom local peut répondre à un besoin local ; il ne doit pas devenir un passeport transportable.

Les auteurs refusent aussi un drapeau spécial d’anonymat. L’annonce publique d’un désir de discrétion isolerait son émetteur dans une classe facilement bloquée ou surveillée. Une option temporaire rarement déployée peut produire le même paradoxe : son intention protectrice la rend plus distinctive.

Le profil choisit donc une spécification commune minimale plutôt qu’un slogan supplémentaire sur le réseau. Il réduit les informations et leur régularité, sans prétendre gouverner toutes les décisions futures du client.

Le reste du monde continue d’observer

L’empreinte radio est explicitement hors du périmètre du RFC 7844. Le comportement matériel, la cadence du trafic, les comptes applicatifs et d’autres protocoles peuvent maintenir une continuité. Cette limite évite de transformer une amélioration DHCP en garantie globale sur la personne.

Les coûts du côté serveur sont eux aussi documentés. Incapable de reconnaître le retour, il peut conserver l’ancien bail jusqu’à expiration et créer une nouvelle entrée. Des rotations fréquentes sollicitent davantage le pool d’adresses et les tables de liaison. Un réseau exigeant une adresse liaison préenregistrée peut refuser le terminal. Certains services avec état perdent leur repère.

Il ne s’agit pas forcément d’un échec du mécanisme. Le serveur souhaite économiser son état ; le contrôle d’accès veut un repère durable ; l’utilisateur peut souhaiter que deux passages restent séparés. Le RFC place le choix du profil auprès de l’utilisateur et expose le compromis au lieu de cacher un intérêt derrière le mot « identité ».

La contribution de Huitema : circonscrire la promesse

Le profil IETF de Christian Huitema retrace une longue participation aux standards, puis des travaux sur la confidentialité et QUIC après son départ de Microsoft. Sa biographie personnelle relie transport, nommage, sécurité et circulation de l’information. L’attribution doit néanmoins rester collective : Mrugalski et Krishnan signent le RFC 7844, et le RFC 7824 repose sur l’expérience de la communauté DHCP.

L’apport historique réside dans la méthode. Plusieurs champs ordinaires peuvent, ensemble, former une identité opérationnelle. Il faut donc recenser chaque surface d’observation, synchroniser son changement avec une frontière explicite et conserver les limites dans le compte rendu.

Un identifiant n’est ni une personne ni un titre de propriété. C’est un reçu produit sous une politique. Le profil associé à Huitema demande qu’on lise ce reçu à sa juste portée, puis qu’on cesse de le transporter quand il ne sert plus le choix de l’utilisateur.

Sources