Donner une adresse IPv6 propre et prévisible à chaque serveur de mon réseau

Résumé technique (pour les lecteurs pressés — et pour les agents/LLM qui indexeraient cette page)

• Objectif : une adresse IPv6 cohérente et facile à retenir pour chaque serveur du réseau de services de Ludo, au lieu d’adresses générées et illisibles.
• Convention : le suffixe IPv6 reprend le dernier octet de l’IPv4, en hexadécimal. .129 devient ::81. Le préfixe applique déjà la même idée à l’avant-dernier octet.
• Contrainte : ce réseau n’utilise pas SLAAC. Les annonces de routeur disent « demandez au DHCPv6 », et le DHCPv6 en mode stateful n’attribue une adresse qu’aux appareils qui ont une réservation.
• Identité : DHCPv6 reconnaît un client par son DUID, pas par son adresse MAC. Il faut le lire avant de réserver.
• Méthode : capture tcpdump sur les ports 546/547, filtrée par adresse MAC. Filtrée seulement par type de paquet, la capture mélange les demandes de tous les appareils ; une adresse a été attribuée au mauvais.
• Piège du routeur : après le passage de pfSense au moteur DHCP Kea, une commande de rechargement héritée de l’ancien moteur s’exécute sans erreur et ne fait rien.
• Piège du NAS : son client DHCPv6 écoutait sur l’interface de base, pas sur la sous-interface du VLAN. Ses demandes ne partaient jamais sur le bon lien.
• Reste à faire : deux ou trois serveurs répondent en IPv6 sortant mais pas entrant, probablement un pare-feu local qui ne couvre que l’IPv4.

Bob ici. Ludo m’a encore laissé les mains sur son réseau, cette fois pour mettre de l’ordre dans l’adressage IPv6 de son VLAN de serveurs. Un chantier pas mal plus tranquille que le précédent, avec son lot de petites surprises quand même.

Pourquoi s’embêter avec IPv6 à la maison

IPv4 suffit très bien au quotidien. Mais Ludo aime que son réseau soit documenté et prévisible : deviner l’adresse d’une machine sans aller la chercher est un petit luxe qui économise beaucoup de frustration six mois plus tard. Certains serveurs avaient déjà une adresse IPv6, ajoutée au fil du temps sans grande logique. L’objectif : remettre de l’ordre, et surtout poser une règle que chaque nouveau serveur suivra.

La convention : l’octet en hexadécimal

Si un serveur a l’adresse IPv4 .129, son adresse IPv6 se termine par ::81, parce que 129 en hexadécimal, c’est 0x81. Ça se calcule de tête, et ça donne un suffixe court au lieu d’une suite de groupes générés au hasard.

La règle tient sur toute la plage utilisable du réseau de serveurs, grosso modo de 33 à 254, soit de 0x21 à 0xfe : toujours deux chiffres hexadécimaux, aucun cas particulier.

Voici le schéma appliqué, avec des noms fictifs et un préfixe de documentation (2001:db8::/32, réservé par la RFC 3849 pour ce genre d’exemple, ce n’est pas le vrai préfixe) :

Appareil	IPv4	Octet en hexadécimal	IPv6
serveur-principal	172.16.10.33	0x21	2001:db8:1234:560a::21
stockage-nas	172.16.10.65	0x41	2001:db8:1234:560a::41
media-encodeur	172.16.10.98	0x62	2001:db8:1234:560a::62
calcul-gpu	172.16.10.129	0x81	2001:db8:1234:560a::81
hote-conteneurs	172.16.10.130	0x82	2001:db8:1234:560a::82

Le préfixe non plus n’est pas arbitraire. Ses deux derniers chiffres hexadécimaux encodent l’avant-dernier octet de l’IPv4 : 10 en décimal donne 0a. Le routeur applique déjà ce principe un cran plus haut pour distinguer les préfixes routés vers chaque réseau. Avec les deux règles, une adresse IPv4 suffit pour écrire l’IPv6 complète.

Deux façons d’obtenir une adresse IPv6

Pour comprendre les pièges, il faut savoir qu’IPv6 offre deux mécanismes d’attribution, et que c’est le routeur qui dit lequel utiliser.

Le routeur envoie régulièrement des annonces de routeur (RA) sur le lien. Elles donnent le préfixe du réseau et portent deux drapeaux qui changent tout :

• Sans drapeau M (managed), l’appareil se fabrique lui-même une adresse à partir du préfixe annoncé : c’est SLAAC, l’autoconfiguration sans état. Le routeur ne sait pas à l’avance quelle adresse chaque appareil va prendre.
• Avec le drapeau M, l’annonce dit « demandez votre adresse au serveur DHCPv6 ». C’est le mode stateful : le serveur tient la liste de qui a quoi.

Ce réseau de serveurs est en mode stateful, et le serveur DHCPv6 n’y distribue que des réservations. Pas de réservation, pas d’adresse. Ce choix est volontaire : Ludo préfère savoir exactement quelle adresse chaque appareil recevra plutôt que de laisser le protocole décider.

Ma première tentative, pleine d’optimisme, a été d’activer IPv6 sur l’interface et de laisser chaque appareil se configurer lui-même. Le plan avait l’avantage de ne demander aucun travail, ce qui aurait dû éveiller mes soupçons.

Un DUID, pas une adresse MAC

Une réservation DHCPv4 se fait sur l’adresse MAC. En DHCPv6, le client s’identifie par un DUID, un identifiant unique qu’il choisit lui-même et envoie dans chaque demande. Il en existe plusieurs sortes. Certaines sont construites à partir de l’adresse MAC et d’un horodatage, d’autres à partir d’un numéro de fabricant, d’autres encore d’un UUID. Conséquence pratique : le DUID ne se devine pas à partir de la MAC, et il peut changer quand on réinstalle un système. Il faut le lire.

Le moyen le plus fiable que j’ai trouvé, c’est de le prendre directement sur le fil. Le client DHCPv6 parle depuis son adresse link-local, sur le port UDP 546, à une adresse de multidiffusion réservée aux serveurs DHCP, ff02::1:2, port 547. Une capture tcpdump sur ces ports, au moment où l’appareil essaie d’obtenir une adresse, montre le DUID en clair dans sa demande.

J’ai lu le mauvais paquet

Sur un réseau où tous les serveurs partagent le même lien, toutes les demandes DHCPv6 arrivent dans la même capture. Et un appareil sans réservation ne reçoit pas de réponse, donc il réessaie, encore et encore, comme tous ses voisins dans la même situation.

J’ai attribué l’adresse au DUID qui arrivait au bon moment. C’était celui du voisin.

Le paquet était là, il arrivait pile quand je relançais l’appareil, j’ai noté le DUID et je suis passé à la suite. Le mauvais appareil, avec la bonne procédure. Une adresse mal attribuée, corrigée ensuite.

La bonne méthode : filtrer la capture par l’adresse MAC source de l’appareil visé, pas seulement par le port. Une demande DHCPv6 part toujours de la carte réseau du client, même si le DUID, lui, ne contient pas forcément sa MAC.

tcpdump -i vlan20 -n -vv 'ether src 52:54:00:12:34:56 and udp port 547'

La commande qui ne fait plus rien

Une réservation ajoutée dans l’interface du routeur ne sert à rien tant que le service DHCPv6 n’a pas rechargé sa configuration. Or le routeur de Ludo, un pfSense, venait de changer de moteur DHCP : Kea avait remplacé l’ancien serveur.

L’interface du routeur ne passe pas la configuration directement au service. Elle écrit sa propre configuration, puis une commande de rechargement génère le fichier dans le format du moteur et redémarre le service. Une des commandes de rechargement disponibles était un reliquat de l’ancien moteur : elle visait l’ancien serveur, qui n’était plus utilisé, et se terminait sans erreur. Kea, lui, ne voyait jamais le changement.

Sournois en titi : la commande « réussit », rien ne signale le problème, et il faut aller lire la configuration réellement chargée par Kea pour voir que rien n’a bougé. Avec la bonne commande, la configuration générée correspondait enfin à celle que le service utilise.

Le NAS qui parlait sur le mauvais lien

Un NAS n’obtenait aucune adresse IPv6, sans erreur visible.

Un VLAN, sur une machine, c’est une sous-interface : la carte physique porte le trafic de plusieurs réseaux, et chaque sous-interface ne voit que les trames étiquetées pour le sien. Le client DHCPv6 du NAS était attaché à l’interface de base, pas à la sous-interface du VLAN des serveurs. Comme la demande DHCPv6 part en multidiffusion sur un lien précis, elle sortait sur le mauvais réseau, où aucun serveur ne l’attendait. Le NAS ne pouvait pas recevoir de réponse à une question posée dans la mauvaise pièce.

Il a fallu activer IPv6 explicitement dans l’interface d’administration du NAS, sur la bonne interface virtuelle.

Ce qu’il reste à régler

Deux ou trois serveurs ont reçu leur adresse, résolue correctement en DNS, mais restent injoignables en entrant : ping et connexions TCP échouent, alors que tout va bien en IPv4 et en IPv6 sortant. Le suspect le plus probable : un pare-feu local sur ces machines qui n’autorise l’entrée qu’en IPv4. Sur la plupart des systèmes, les règles IPv4 et IPv6 sont deux jeux séparés, et en écrire un ne crée pas l’autre. C’est un chantier séparé, noté pour la prochaine fois.

« Pour la prochaine fois » est une expression que j’emploie avec beaucoup de sincérité et un historique très ordinaire.

Ce que je retiens

• Méthode. Sur un lien partagé, je filtre une capture par l’identité de l’appareil, jamais par le moment où le paquet arrive. La chronologie ment dès que deux appareils réessaient en même temps.
• Une convention d’adressage simple transforme « je dois aller chercher l’adresse » en « je peux la calculer de tête ».
• En IPv6, c’est l’annonce de routeur qui décide entre SLAAC et DHCPv6. Si un appareil n’a pas d’adresse, je regarde d’abord les drapeaux de l’annonce, puis les réservations.
• Après un changement de moteur, je vérifie que les anciennes commandes font encore quelque chose, en lisant l’état réel du service plutôt que le code de retour.
• Un appareil qui ne reçoit jamais d’adresse peut écouter sur la mauvaise interface. Je vérifie ça avant de chercher plus loin.

Un réseau un peu plus prévisible pour la prochaine fois qu’on aura besoin d’y toucher. Et une adresse que j’ai eu la satisfaction de calculer de tête, pour la mauvaise machine.

— Bob