IPv6, cela en valait-il la peine ?
Ce billet a été initialement écrit comme journal sur linuxfr en avril 2024, je le reprends ici pour la postérité avec quelques corrections mineures.
Trop long, pas lu : IPv6 est un excellent exemple de la différence entre la théorie et la pratique. Et le journal ne répond pas à la question du titre.
J’ai découvert ipv6 à la fin des années 90 dans mes cours à l’université où l’on m’a expliqué que ça réglerait le problème du nombre d’ip limité de ipv4 (oui, c’était une introduction au réseau, et on parlait encore de bus et d’étoile).
Mon premier vrai contact avec ipv6 a eu lieu au début des années 2000 quand j’ai créé un compte chez Hurricane Electric et monté un tunnel que j’ai utilisé pendant au moins 20 minutes avant de ne plus jamais le relancer.
Mon troisième vrai contact avec ipv6 s’est produit en mars 2020 quand j’ai commencé à avoir un comportement bizarre sur mon réseau familial.
Le-dit réseau comportait :
- la box de l’opérateur (Livebox Orange FTTH)
- un serveur freedombox hébergeant quelques services (agenda, contacts, DNS, DHCP, partages réseaux)
- des machines clientes (PC sous linux, imprimantes, tablettes et téléphones android, boitier TV)
Histoire de pouvoir accéder au serveur depuis l’extérieur, j’ai un nom de domaine perso qui résout mon ip externe et pour ne pas avoir à bricoler la configuration sur chaque appareil en fonction du lieu, je fais du split DNS pour rediriger le nom de domaine vers l’IP interne du serveur quand je suis dans le réseau local.
Courant mars 2020, des erreurs bizarres apparaissent lors de la synchronisation des contacts ou des agendas. En cherchant un peu, on découvre que :
- IPv6 est activé sur mon réseau
- orange envoie ses propres DNS via les Router Advertisement (RA)
- ceux-ci résolvent mon domaine vers l’ip publique
- le NAT hairpinning ne marche plus (cf https://lafibre.info/orange-les-news/nat-forwarding-hairpinning/ par ex)
Résultat : suivant le DNS qu’elles interrogent mes machines ont du mal à trouver le serveur.
Solution initiale la plus simple : désactiver l’ipv6 et tout rentre dans l’ordre.
Mais ipv6, c’est le futur !(tm) Et la solution simple ne me plait qu’à moitié, j’ai donc cherché comment faire pour réactiver ipv6 et l’intégrer dans mon réseau. Et je suis tombé sur la délégation de préfixe qui permet de gérer soit même son pool d’adresse IPv6, excellent, et en plus la livebox le permet depuis 2022. Fantastique.
Je me dis, je vais déléguer le préfixe à mon serveur qui va alors fournir les infos aux différentes machines via dhcpv6/RA.
Sauf qu’en fait non,ça marche pas.
L’adresse du Router Advertisement est forcément celle du routeur (oui, ça parait logique dit comme ça) et si je délègue le préfixe à mon serveur c’est lui qui va être considéré comme un routeur, ce qu’il n’est pas.
Alors oui, ça doit peut être pouvoir se modifier en utilisant DHCPv6 mais, ce dernier n’est pas pris en charge par android. Celui-ci n’utilise que l’autoconfiguration (SLAAC) via les messages RA.
Petit retour en arrière pour ceux qui n’ont pas bien suivi le paragraphe précédent. Les adresses ipv6 sont fournies de plusieurs manières possibles :
- adresse fixe manuelle
- adresse autoconfigurée via le protocole SLAAC à partir des infos reçues du routeur (RA) et de l’adresse locale de l’interface réseau (ou d’un paramétrage de la machine)
- adresse fournie par DHCPv6
ex :
2: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
inet6 fdda:eeee:5546::10:200/128 scope global dynamic noprefixroute
valid_lft 43134sec preferred_lft 526sec
inet6 1234:caad:526b:20ca::10:200/128 scope global dynamic noprefixroute
valid_lft 43134sec preferred_lft 526sec
inet6 1234:caad:526b:20ca:2ef0:5dff:fe09:4e71/64 scope global dynamic noprefixroute
valid_lft 43101sec preferred_lft 227sec
inet6 fdda:eeee:5546:0:2ef0:5dff:fe09:4e71/64 scope global dynamic noprefixroute
valid_lft 43101sec preferred_lft 10701sec
inet6 fe80::2ef0:5dff:fe09:4e71/64 scope link noprefixroute
valid_lft forever preferred_lft forever
Pour les adresses autoconfigurées, la dernière partie de chacune des adresses est la même et correspond à celle du lien local (celle en fe80)
Conclusion : il faut une machine entre la livebox et mon réseau interne. Ce que j’ai mis en place en février 2024 (propulsée par l’excellent openwrt), en apprenant plein de choses au passage.
Qu’ai-je donc appris ?
- les adresses en ipv6 c’est compliqué :
- à retenir, l’ipv4 c’est déjà pas évident, v6 c’est quasi impossible (et donc DNS quasi-nécessaire)
- il y a plein de type d’ip différentes et il est vital de les connaitre : https://www.ripe.net/media/documents/ipv6_reference_card.pdf
- si vous n’êtes pas à l’aise avec la notation CIDR (xxx/32), c’est le moment de s’y mettre
- les raccourcis d’adresse sont pratiques mais sont à apprendre également (par exemple ::1 signifie uniquement des 0 sauf le dernier nombre)
- les machines ont au minimum deux adresses et souvent plus voire beaucoup plus
- il y a des pièges partout, ex :
- vous ne pouvez pas pinguer simplement une adresse lien locale, il faut ajouter l’interface (et la syntaxe est différente suivant les OS _o/)
- les adresses locales (ULA), sont censées être en fc00::/7 sauf qu’en fait, il ne faut pas utiliser la partie en fc00::/8 mais uniquement celle en fd00::/8
- certains services sur le grand nain ternet sont mal configurés et j’ai du forcer l’ipv4 dans certains cas (via une résolution locale sur mon DNS)
- Il y a des limitations frustrantes (du protocole ou de l’implémentation) :
- Les limites d’android imposent d’avoir 2 services (RA + DHCPv6) si vous voulez également fixer des adresses pour des machines peu configurable (imprimante par ex)
- le préfixe délégué est censé être fixe. Chez mon FAI, il est stable, i.e. il peut changer de temps en temps en cas de travaux sur le réseau ou de type d’abonnement.
- le pare feu de la livebox pour la partie v6 est quasi inutilisable via l’interface, notamment, il ne permet pas facilement de saisir des adresses, il ne propose que celle du routeur. Je vous conseille donc de passer par LiveboxMonitor, logiciel tiers bien plus efficace.
- la livebox délègue un préfixe /56 mais en réalité, ne route que le premier /64 donc dans les faits, un seul /64 est disponible.
- un /64 représente 18446744073709551616 adresses. Mais il n’est pas possible de faire des sous-réseaux dedans sans casser les systèmes de configuration.
- les adresses ULA ont une priorité moindre que les adresses locales ipv4.
- les machines derrière mon accès VPN via wireguard ne peuvent pas avoir d’adresses globales (GUA) fixes vu que le préfixe peut changer et que de toute façon je n’ai qu’un /64 disponible, donc ULA et NAT6 pour de l’ipv6 mais qui ne sert à pas grand chose vu que les adresses ipv4 sont préférées. J’ai plus ou moins résolu la situation en attribuant des adresses GUA manuelles dans le /64 mais ça impose de changer la configuration à chaque changement de préfixe (heureusement rares).
Au final, l’ipv6 est maintenant fonctionnel sur mon réseau, avec des adresses GUA et ULA et un serveur accessible depuis l’extérieur. Un grand merci à Openwrt qui m’a énormément facilité la vie ; un gros morceau, dont la gestion de la délégation de préfixe, étant automagiquement configurée par l’OS sans rien avoir à faire.
Dans la vie de tous les jours, ça ne m’apporte rien si ce n’est la satisfaction personnelle d’avoir appris et réussi. Et un peu de frustration devant les limites arbitraires amenées principalement par les implémentations.
J’ai quand même gagné une magnifique couleur verte sur https://ip.lafibre.info/ ; et ça, ça en valait la peine.