Résumé

  • Dans le mécanisme défini par RFC 8539, une adresse source IPv6 peut changer pendant qu’un même bail IPv4 reste valide. Le service dépend donc d’une association entretenue, et pas seulement d’une ressource attribuée.
  • Le client dispose d’une latitude dans le choix de la source du tunnel. Cette latitude reste soumise à la topologie IPv6 disponible, aux règles de liaison et, éventuellement, à une fréquence minimale de mise à jour.
  • Déplacer le point d’entrée ne rend pas le client anonyme. Les identifiants et les informations déjà connues de l’opérateur constituent un problème distinct.

Une allocation IPv4 peut sembler être une affaire d’inventaire : une adresse, un bénéficiaire, une durée. Dès lors que le trafic IPv4 traverse un réseau IPv6 dans un tunnel, cette description devient incomplète. L’opérateur doit aussi savoir à quelle adresse IPv6 associer le service. Cette seconde adresse n’est pas nécessairement immuable pendant la durée du bail.

RFC 8539 organise précisément cette possibilité avec une configuration dynamique reposant sur DHCPv4 transporté par DHCPv6. Publié en mars 2019, le document figure toujours au rang de Proposed Standard dans sa fiche officielle. La consultation des errata, le 8 septembre 2026, n’a renvoyé aucune correspondance. Il s’agit d’un état documentaire, pas d’un constat sur une infrastructure commerciale.

Le sujet n’est donc pas de proclamer la victoire d’une famille d’adresses sur l’autre. Il est de comprendre ce que l’opérateur délègue lorsqu’il laisse le client choisir le point de départ de son tunnel, et ce qu’il continue de contrôler.

Une préférence n’est pas une interdiction

La première limite précède le bail IPv4. Un préfixe IPv6 approprié doit déjà être configuré, que ce soit au moyen de DHCPv6, d’annonces de routeur ou d’un autre mécanisme. L’attribution d’une ressource IPv4 ne fournit pas à elle seule cette connectivité préalable.

La configuration dynamique permet ensuite d’envisager un point de terminaison situé ailleurs que sur un équipement de bordure prédéterminé, au sein de la topologie IPv6 routable de l’utilisateur final. C’est une souplesse d’implantation potentielle. Elle ne garantit ni que tous les équipements la prennent en charge, ni que le service puisse suivre le client chez un autre opérateur.

Le document distingue soigneusement deux informations fournies par le serveur. Une adresse valide du relais de bordure est indispensable ; son absence ou son invalidité conduit le client à écarter le message. En revanche, le préfixe préféré est une indication. Si cette indication est invalide, elle est ignorée et le traitement se poursuit comme si elle n’avait pas été reçue. Si elle manque ou ne correspond à aucun préfixe disponible, le client peut, dans les conditions prévues, retenir un autre préfixe valide de portée appropriée.

Cette différence est importante pour décrire le partage des décisions. Le serveur fournit l’adresse du relais nécessaire au service, mais sa préférence concernant la source ne ferme pas forcément toutes les autres possibilités. Le client ne gagne pas pour autant le droit de choisir n’importe quelle adresse sur Internet : validité, portée et connectivité restent déterminantes.

Il peut réutiliser une adresse IPv6 existante ou en construire une nouvelle. La configuration requise, y compris la détection d’adresses dupliquées lorsqu’elle s’applique, doit être terminée avant la demande de liaison. Choisir un point de départ signifie donc choisir parmi des possibilités utilisables, pas demander au réseau de rendre utilisable une valeur arbitraire.

L’association fait partie du service

Le serveur conserve l’adresse source IPv6 avec le bail IPv4 et l’identifiant du client. La liaison reste valide avec le bail. Une renumérotation IPv6 peut cependant nécessiter une nouvelle source sans qu’il faille conclure que l’allocation IPv4 a disparu.

Le client demande alors la modification. Chaque DHCPACK indique l’adresse source effectivement liée par le serveur, et le client doit comparer cette valeur à sa source active. La présence d’un acquittement n’efface pas le besoin de vérifier ce qu’il acquitte.

Ce détail prend tout son sens avec l’architecture Lightweight 4over6. La traduction d’adresses et de ports y est effectuée du côté du client. Le routeur de transition léger de l’opérateur maintient, lui, une association entre une adresse IPv6, une adresse IPv4 publique et un ensemble restreint de ports. Cette association sert à acheminer les paquets entrants vers le bon point de terminaison et à vérifier le trafic encapsulé sortant.

On ne doit pas confondre cette table avec un suivi central de chaque session traduite. Déplacer la traduction vers le client peut réduire un type d’état au centre sans supprimer l’état nécessaire à l’allocation. De même, lorsque le service utilise un ensemble de ports, disposer d’une adresse IPv4 et disposer de ports supplémentaires ne sont pas la même chose.

La conséquence analytique est simple : compter les adresses attribuées ne suffit pas à décrire les ressources nécessaires au service. Il faut aussi considérer les associations à maintenir et, selon l’architecture, les capacités de ports. Les documents étudiés exposent des mécanismes ; ils ne mesurent ni les économies réalisées par un fournisseur, ni la survie de toutes les sessions applicatives à chaque changement possible.

Le droit de choisir a un rythme

Une liberté d’emplacement peut coexister avec une contrainte de fréquence. RFC 8539 autorise le serveur à imposer un intervalle minimal entre les mises à jour de l’adresse source. Si cette politique optionnelle est mise en œuvre, la valeur par défaut spécifiée est de 60 secondes.

Une demande trop précoce peut être ignorée, ou recevoir un acquittement qui contient encore l’ancienne source liée. Ce n’est ni une obligation d’attente applicable à tous les clients, ni un engagement universel de rétablissement en une minute. La valeur effective et l’activation de la politique relèvent du déploiement. Les comportements de nouvelle tentative et de libération du client doivent s’accorder avec ces règles.

L’intérêt possible du serveur est compréhensible : des changements incessants peuvent multiplier les opérations de configuration. Mais un client dont le préfixe vient de changer ne considère pas forcément cette activité comme évitable. Une protection de la fréquence des mises à jour peut, pour lui, devenir une limite à la remise en usage du service.

Le standard ne tranche pas le bilan économique entre ces deux points de vue. Il ne démontre pas non plus une intention de bloquer le client. Il rend visible un arbitrage qui aurait tort de rester caché derrière le seul mot « dynamique ».

La source choisie doit en outre être unique parmi les liaisons de baux actifs. Le traitement d’un conflit n’est pas identique pour un nouveau bail et pour une modification d’un bail existant. L’autre association valide n’est pas simplement écrasée pour satisfaire la demande. La souplesse demeure une délégation encadrée par un état partagé.

Changer d’adresse ne supprime pas la mémoire

Il serait tentant de présenter une source mobile comme un progrès automatique de confidentialité. RFC 8539 invite à une lecture plus prudente. Un identifiant d’interface immuable peut permettre un suivi entre réseaux et sessions. Le document examine une construction utilisant l’adresse IPv4 et l’identifiant de l’ensemble de ports, en référence au format MAP-E.

Dans ce contexte, cette construction ne donne pas au serveur d’information supplémentaire sur le client par rapport aux ressources qu’il connaît déjà. Elle évolue avec l’adresse IPv4 louée. Mais l’absence d’information supplémentaire n’est pas l’absence d’information : l’opérateur conserve nécessairement la connaissance de l’association active, et les données déjà retenues ne disparaissent pas lorsque la source change.

Les profils d’anonymat DHCP mettent en évidence une difficulté comparable. Modifier l’adresse de liaison ne suffit pas si d’autres identifiants restent stables. Ils décrivent aussi des conséquences opérationnelles : après un changement d’identité, une ancienne adresse peut rester marquée comme louée tandis qu’une nouvelle est attribuée. Certains services s’appuient sur la reconnaissance d’un client pour lui redonner la même adresse ou l’autoriser à se connecter.

Il ne s’ensuit pas que tous les clients d’un accès fixe doivent renouveler aléatoirement leurs identifiants. Le choix dépend du contexte. La stabilité utile sur un réseau connu peut devenir indésirable dans une situation où l’utilisateur souhaite limiter les corrélations. Le produit doit rendre cette différence intelligible au lieu de décider tacitement que mobilité, stabilité et anonymat sont interchangeables.

Les hypothèses de sécurité comptent également. RFC 8539 vise une connectivité de couche deux dédiée par client et déconseille l’usage sur un support partagé. Le filtrage à l’entrée et la validation au relais de bordure font partie du contexte défensif. Le choix de la source ne saurait être décrit comme une faculté illimitée d’affirmer n’importe quelle origine.

Dans sa note 36, Lu Heng insiste sur la description des structures réelles plutôt que la promotion de solutions. C’est ici le bon critère éditorial. La configuration dynamique assouplit une contrainte d’emplacement ; elle ne fait disparaître ni le coût de l’association, ni le contrôle de son évolution, ni la question des traces.