Dans un article précédent, nous avons vu comment faire fonctionner son réseau avec l'IPv6 de Free en étant derrière son propre routeur OpenWRT. Je m'étais alors limité à l'autoconfiguration automatique (dit SLAAC, pour Stateless Address Autoconfiguration), pour des raisons de simplicité.

Cependant, la partie "stateless" fait que le routeur se contente de donner le préfixe /64 et éventuellement d'autres informations. Le client choisit alors lui-même les 64 derniers bits de l'adresse qu'il décide d'utiliser, moyennant quelques précautions pour éviter d'utiliser une adresse utilisée par quelqu'un d'autre (DAD, ou Duplicate Address Detection). Une adresse peut alors être générée à partir de l'adresse MAC, comme c'est souvent le cas sous Linux, mais elle peut aussi être choisie de manière complètement aléatoire, et renouvelée toutes les dix minutes, comme sous Windows et Mac OS. On parle d'utilisation d'adresses temporaires pour le second cas.

J'utilise Privoxy sur mon réseau. Il s'agit d'un proxy qui permet entre autres de filtrer les pubs et autres petits trucs indésirables (comme par exemple ces fameux boutons « J'aime » de Facebook, qui ont le malin plaisir d'utiliser un cookie pour tracer des utilisateurs, y compris ceux qui n'ont pas de compte chez eux – mais cela n'est pas l'objet principal de cet article). Il s'avère que de temps en temps, Chrome sous Windows ne parvient pas à se connecter au proxy (erreur net::ERR_PROXY_CONNECTION_FAILED pour ceux qui veulent des détails), alors que le reste du réseau fonctionne. Aucun paquet TCP, ni même un seul paquet SYN, ne parvient au serveur lorsque cela arrive.

J'ai donc conjecturé que c'était la faute de l'utilisation des adresses temporaires. J'ai donc eu l'idée d'expérimenter avec Dibbler, un petit serveur DHCPv6 portable, qui est entre autres packagé sous OpenWRT. Mon expérience est à la fois justifiée par ma conjecture et par le désir d'attribuer des reverse DNS pour les machines sur lesquelles je ne peux pas me permettre d'attribuer des IPv6 statiques à la main.

Dans ce post, je vais donc expliquer en détail ce que j'ai fait pour mettre en place un serveur DHCPv6 sur mon routeur, tout en explicitant les différences avec l'« ancien » DHCP d'IPv4. Je reviendrai d'abord sur le fonctionnement de radvd, avant de traiter de l'installation de Dibbler, de sa configuration et du test du service, pour ensuite conclure sur mes observations quant aux implémentations de dhcpcd et de Windows.

Retour sur radvd

Au moment où nous avions mis en place la connectivité IPv6 pour notre réseau, nous avions installés radvd, qui sert à répondre aux Router Solicitations (RS) d'ICMPv6 avec des Router Announcement (RA). Ces paquets contiennent deux types de flags.

Premièrement, les flags du paquet sont les suivants :

• M (Managed) : si ce flag est à 1, utiliser DHCPv6 pour récupérer son adresse IP. Sinon, se contenter de SLAAC ;
• O (Other) : si ce flag est à 1, utiliser DHCPv6 pour récupérer d'autres informations que l'adresse (par exemple les serveurs DNS).

Nous avions mis ces deux flags à 0 lorsque nous avions configuré radvd, signifiant que seuls des paquets RS et RA sont nécessaires pour l'autoconfiguration des clients. En passant à DHCPv6, nous mettrons le flag M à 1, et si nous souhaitons également fournir aux clients les adresses des serveurs DNS, nous ferons de même avec le flag O.

Ensuite, pour chaque préfixe signalé dans un RA, il y a également plusieurs flags, mais nous nous focaliserons surtout sur le suivant :

• A (Autonomous) : si ce flag est à 1, le client utilise SLAAC pour obtenir une adresse dans le préfixe correspondant.

Ce flag était à 1 dans notre configuration initiale. Comme nous utilisons DHCPv6, nous pouvons la passer à 0 pour s'assurer, entre autres, que les clients n'utilisent pas d'adresses temporaires.

Installation de Dibbler

L'installation de Dibbler est très simple. En tant que root sur le routeur :

# opkg install dibbler-server

Configuration de Dibbler

La configuration de Dibbler se fait dans /etc/dibbler/server.conf. Voici un petit exemple de configuration attribuant des IP aléatoires dans son /64, tout en attribuant certaines IP fixes pour certaines machines.

# Logging level range: 1(Emergency)-8(Debug)
log-level 7

# Don't log full date
log-mode short

# set preference of this server to 0 (higher = more prefered)
preference 0

iface "br-lan" {
 // also ranges can be defines, instead of exact values
 t1 1800-2000
 t2 2700-3000
 prefered-lifetime 3600
 valid-lifetime 7200

# assign addresses from this pool

 class {
   pool 2001:db8:0:42/64
 }

 option domain example.com
 option dns-server 2001:db8:0:42::b
 option ntp-server 2001:db8:0:42::17
 option time-zone  CET

 client duid 00:01:00:01:18:92:e4:e9:aa:bb:cc:dd:ee:ff
 {
   address 2001:db8:0:42::cafe
 }

 client duid 00:01:00:01:18:5a:14:81:01:23:45:67:89:ab
 {
   address 2001:db8:0:42::c0ca
 }
}

La plupart des directives sont plutôt évidentes. Il y a cependant deux choses auxquelles il faut faire attention :

• Dibbler 0.8.2 semble avoir un bug qui oblige les adresses statiques à être obligatoirement dans un préfixe déclaré avec la directive class. Cela signifie qu'il est pour le moment impossible de donner des IP dans deux plages disjointes selon qu'il s'agisse d'une machine connue ou inconnue.

• On n'attribue plus d'adresses en fonction d'adresses MAC, mais en fonction d'identifiants uniques appelés DUID (plus de détails dans la RFC 3315, section 9 – lecture très recommandée). Ces DUID sont généralement générés une fois à l'installation du système (ou à la première utilisation de DHCPv6...).
  L'inconvénient majeur est le fait que ces DUID sont imprévisibles ; il faut donc regarder dans /var/lib/dibbler/server-cache.xml pour retrouver celui qui correspond à la bonne adresse.

Mis à part l'utilisation de DUID, il n'y a pas grand-chose de sensiblement différent comparé au DHCP traditionnel.

Tester le service

Sous Linux, on peut tester le bon fonctionnement avec le client fourni avec Dibbler. Il suffit de lancer dibbler-client run en tant que root, puis de faire un petit ifconfig pour voir si on obtient une adresse IP par DHCPv6.

Windows 7 implémente déjà un client DHCPv6, donc il suffit de rebooter la carte ou la machine. En faisant un petit ipconfig dans une invite de commandes, on voit que ça marche tout seul.

Conclusion

Bien que l'utilisation de DHCPv6 n'ait pas résolu le problème avec le proxy sous Chrome mentionné en introduction (ou alors ce sont des gremlins qui s'amusent avec la carte réseau), cela m'a ensuite permis de mettre en place assez facilement les enregistrements reverse DNS pour ma plage d'adresses IPv6. Pas forcément nécessaire, mais toujours appréciable.

Pour le moment, dhcpcd, le client DHCP utilisé par wicd entre autres, ne prend pas encore en charge DHCPv6, donc pour ceux qui utilisent ce démon, vous n'avez pas de chance ; vous n'aurez que du SLAAC. Ou sinon, il faudra compiler et installer la version 5.99.

Du côté des serveurs, dnsmasq implémenterait également un serveur DHCPv6, mais cela contraint de supprimer radvd, ce que je ne souhaitais pas. In fine, la solution que j'ai retenue est celle qui fournit le plus de flexibilité, et permet théoriquement de s'affranchir de cette problématique récurrente d'administration réseau qu'est l'adressage.