Délégation de préfixes IPv6 avec la Livebox : expériences en profondeur
Mise à jour du 7 octobre 2024 : il ne suffit pas d’avoir des adresses MAC différentes pour chaque bail ; il faut envoyer un DUID différent aussi…
Mise à jour du 7 août 2022 : la version 4.53.14 du firmware souffre des mêmes problèmes.
Un soir, j’ai été surpris de découvrir que la Livebox propose désormais une fonction de délégation de préfixes IPv6 dans son interface d’administration.
C’est une fonction que j’attendais depuis très longtemps sur la Livebox, car sans elle, je ne pouvais pas avoir de connectivité IPv6 à cause de la configuration particulière de mon réseau. Au lieu de me fier directement à ma Livebox pour le routage, le pare-feu et le Wi-Fi, j’ai en effet choisi d’utiliser mes propres équipements au lieu de la box, et je n’utilise cette box que comme un pont entre le réseau délimité par mon propre routeur et le réseau d’Orange.
Après quelques heures passées à expérimenter, j’ai fini par être un peu déçu à cause de quelques limitations, selon moi injustifiées, imposées par la Livebox. Dans ce billet, je vous propose d’approfondir ce que j’ai déjà écrit sur Mastodon, avec quelques exemples, captures d’écran et captures réseau à l’appui. J’ai effectué mes tests sur une Livebox 4 ; les premiers ont été effectués avec la version 4.43.12 du firmware et des tests complémentaires pour préparer cet article avec la version 4.46.0, ma box ayant été subrepticement mise à jour (mais apparemment, les bugs seraient les mêmes).
La délégation de préfixes par DHCPv6
Le mécanisme de délégation de préfixes utilise une option DHCPv6, appelée IA_PD, spécifiée dans la RFC 3633. Un routeur souhaitant obtenir une délégation de préfixe (appelé requesting router dans la RFC, mais j’utiliserai ici le terme « routeur délégataire ») envoie un paquet DHCPv6 Solicit contenant, dans une ou plusieurs associations d’identité (IA), une option IA_PD. Le routeur délégant (delegating router) répond alors avec un DHCPv6 Advertise contenant elle aussi un ou plusieurs IA_PD par préfixe qu’il accepte de déléguer.
Orange utilise déjà la délégation de préfixes IPv6 dans son propre réseau pour attribuer les préfixes IPv6, des /56, aux abonnés. Donc si un routeur en aval de la Livebox peut demander des délégations de préfixes à la Livebox, on obtient une chaîne de délégation comme ceci :
- pour le préfixe 2001:db8:af3c:5a00::/56, un routeur quelque part dans le réseau opérateur d’Orange est le routeur délégant et la Livebox est le routeur délégataire ;
- pour le préfixe 2001:db8:af3c:5a82::/64, la Livebox est le routeur délégant et le routeur aval est le routeur délégataire.
Position du problème
La force des choses, c’est-à-dire, entre autres, ma passion pour l’informatique, ma méfiance vis-à-vis de certains appareils connectés que je présume être trop bavards, une certaine pandémie mais surtout une simple question d’hygiène informatique, m’a amené à découper mon réseau domestique en plusieurs VLAN : bureautique, multimédia (et autres bidules connectés), consoles de jeux, téléphonie sur IP, administration, labo d’expérimentation IPv6 et télétravail. Tous ces VLAN sont isolés entre eux et certains sont également isolés d’Internet.
En IPv4, parmi les plages d’adresses mises de côté par la RFC 1918 pour un usage privé, j’ai choisi un /16 que je découpe ensuite en /24 pour chacun de mes VLAN. En IPv6, il me faut idéalement un /64 par VLAN, donc le fait qu’Orange alloue un /56 par abonné est plutôt opportun. Bien que la Livebox réserve un des 256 /64 disponibles, cela me laisse tout de même la possibilité d’adresser 255 VLAN en IPv6, ce qui suffira amplement pour mes besoins.
Plus tôt, quand j’avais mis en place ma connectivité IPv6 en étant chez Free, j’avais un réseau beaucoup plus simple dans lequel je n’avais qu’un seul VLAN ; j’utilisais d’ailleurs un démon, ndppd, pour jouer le rôle de proxy NDP. Mais je souhaite écarter d’emblée cette solution, que je considère comme un honteux bidouillage qui oblige, par ailleurs, à utiliser des préfixes plus longs dans ses VLAN comme des /80, ce qui impose la mise en œuvre d’un serveur DHCPv6.
Les limitations de la Livebox en matière de délégation de préfixes
En passant une soirée à expérimenter avec la Livebox, j’ai pu trouver trois problèmes majeurs qui font obstacle, dans l’immédiat, à un déploiement généralisé d’IPv6 dans mon réseau : l’impossibilité de demander la délégation d’un préfixe plus court qu’un /64 ; l’impossibilité de choisir à l’avance le /64 à déléguer ; enfin, l’incapacité, pour la box, de déléguer correctement plus d’un /64 au même routeur délégataire lorsque ce dernier en demande plusieurs.
Déléguer un /56 ou un /60 ne fonctionne pas
Mon premier essai consistait à demander la délégation de mon /56 complet, c’est-à-dire 2001:db8:af3c:5a00::/56 dans le schéma d’exemple. Au lieu de cela, la Livebox me délègue un /64 que je n’ai pas choisi !
On le voit d’ailleurs bien dans l’interface d’administration de la Livebox : l’adresse MAC de mon routeur apparaît bien, mais pas le /56 que j’avais demandé. Sur le routeur délégataire, aucune des interfaces qui devait profiter des préfixes délégués par la Livebox n’a d’adresse IPv6, faute d’obtenir la délégation souhaitée. Donc demander un /56 ne marche pas.
À première vue, il est assez logique qu’une demande de délégation de 2001:db8:af3c:5a00::/56 n’aboutisse pas : ce /56 correspond à la plage complète déléguée à la Livebox, or elle réserve déjà 2001:db8:af3c:5a00::/64.
Mais même demander un /60 ne fonctionne pas non plus : dans ce cas, la Livebox délègue obstinément un /64, au lieu de renvoyer une erreur. Il y a pourtant 15 préfixes /60 qui n’entrent pas en conflit avec le /64 réservé par la Livebox.
Rien n’empêche a priori la Livebox d’accepter de déléguer
2001:db8:af3c:5a00::/56 excepté 2001:db8:af3c:5a00::/64 : il est même possible
d’exprimer cela grâce à une option DHCPv6 décrite dans la RFC 6603.
Le routeur délégataire doit pour cela signaler la prise en charge de cette RFC
dans son DHCPv6 Solicit. Or le client wide-dhcpv6, utilisé par mon routeur,
ne le fait pas ; seul dhcpcd sait le faire.
J’ai donc cherché à savoir si la Livebox prend en charge cette option. Pour ce
faire, j’ai pris une machine sous Linux, installé dhcpcd dessus, créé une
interface virtuelle avec la commande ip link create dummy0 type dummy, puis
préparé un fichier de configuration dhcpcd.conf avec le contenu suivant :
interface eth0
ia_pd 0/::/56 eth0/0 dummy0/1
J’ai alors lancé dhcpcd -6B -f /chemin/vers/dhcpcd.conf eth0, tout en étant
connecté en Ethernet à ma Livebox, pendant que je capturais les paquets
DHCPv6. Malgré la présence de l’indication de prise en charge de la RFC 6603
dans le DHCPv6 Solicit, la Livebox continue d’attribuer un /64 aléatoire.
C’est d’autant plus dommage que le souhait de disposer librement des sous-préfixes 2001:db8:a3fc:5a01::/64 à 2001:db8:a3fc:5aff::/64 est à mon avis le cas d’usage le plus répandu nécessitant la délégation de préfixes par la Livebox. Même disposer seulement d’un /60 m’aurait déjà permis de connecter en IPv6 seize VLAN, ce qui aurait été largement suffisant pour mon usage.
En l’état, cette mise en œuvre de la délégation de préfixes par la Livebox est déjà une opportunité manquée.
Pas de choix du préfixe délégué
Nous savons maintenant que la Livebox n’accepte de déléguer que des /64.
Sur l’interface d’administration de la box, il n’est pas possible de configurer à l’avance quels sous-préfixes la box peut déléguer : au lieu de cela, à chaque fois qu’un routeur délégataire demande un /64, il s’en voit attribuer un aléatoire par la box.
Ces préfixes ont l’air stables, c’est-à-dire que le même couple DUID/IAID donne le même préfixe ; mais attention, si on désactive puis réactive la fonction de délégation de préfixes sur la Livebox, tous les préfixes anciennement attribués sont oubliés et la box attribuera d’autres préfixes choisis au hasard pour le même couple DUID/IAID. Ou du moins, c’est ce qui est arrivé une fois : lorsque j’ai essayé de reproduire ce comportement, je n’y suis pas arrivé et la Livebox a attribué au même couple DUID/IAID le même /64. Quoi qu’il en soit, il manque cruellement d’options pour paramétrer plus finement les préfixes délégués.
Le caractère aléatoire des préfixes délégué n’est guère pratique quand on souhaite placer des serveurs dans une plage d’adresses ainsi déléguée : un préfixe imprévisible complique la publication de leurs adresses dans le DNS.
Pourtant, il est possible pour un routeur délégataire de demander la délégation d’un préfixe bien précis. Mais même quand l’option IA_PD du message DHCPv6 Solicit émis par le routeur délégataire désigne un préfixe qu’il souhaite obtenir, la Livebox n’en tient pas compte.
Au plus un /64 pour un équipement
Nous savons maintenant que la Livebox ne délègue que des /64 et qu’il est impossible de savoir à l’avance quels sont les préfixes qu’il distribue à chaque équipement. Au moins, elles devraient être relativement stables.
Dans un message DHCPv6, il est possible de demander la délégation de plusieurs préfixes, chacun identifiés par des IAID uniques (un IAID étant un entier non signé de 32 bits). Il serait donc normalement possible de contourner les précédentes limitations en demandant autant de délégations distinctes que de VLAN dans mon réseau.
J’ai donc essayé d’envoyer à la Livebox un DHCPv6 Solicit avec deux délégations, ayant les IAID respectifs 0 et 1. À première vue, ça a l’air de fonctionner, car je reçois bien deux préfixes /64 dans le DHCPv6 Advertise avec lequel la Livebox me répond.
Mais je suis alors tombé sur un autre bug de la Livebox : en passant d’un seul préfixe avec l’IAID 0 à deux préfixes avec les IAID 0 et 1, celui associé à l’IAID 0 perd toute connectivité à Internet (du moins, il ne m’est plus possible de pinger une autre machine en IPv6 avec) mais l’autre fonctionne.
En somme, quand un routeur délégataire demande plusieurs délégations de préfixes, toutes sont accordées, mais seule la dernière apparaissant dans le message DHCPv6 Solicit est routable. Impossible, donc, de faire router sept /64 en IPv6 par la Livebox vers mon routeur !
La fonction a-t-elle été testée ?
Je note aussi qu’il est impossible de désactiver la fonction. Après avoir décoché la case « Activer la délégation de préfixe IPv6 » puis cliqué sur « Enregistrer », j’avais fait un test en envoyant un DHCPv6 Solicit avec l’option IA_PD : la box répond quand même avec un IA_PD dans son DHCPv6 Advertise.
Ensuite, comme on peut le voir sur les captures d’écran plus haut dans ce billet, il semble que les informations affichées sur la page sont incomplètes : deux champs auraient dû afficher des informations d’adressage et de préfixes, mais ceux-ci n’apparaissent pas.
Conclusion
En l’état, la fonction de délégation de préfixes IPv6 telle que faite par la Livebox est un pas vers la bonne direction, mais sa mise en œuvre est encore loin d’être satisfaisante et ne me permet pas encore de relier mon réseau domestique à IPv6.
On dirait que la fonction a été développée à la va-vite, avec pour objectif de cocher une case sur une plaquette marketing avant tout, et sans tenir réellement compte des besoins et des cas d’utilisation de ce genre de fonctions. Le résultat est donc une bonne idée, mais insuffisamment testée, mal exécutée et à côté de la plaque. Dommage, parce que j’apprécie beaucoup qu’Orange ait la générosité de donner un /56 à chaque abonné !
Si je devais concevoir une fonction similaire sur une box d’opérateur, j’aurais prévu une interface de configuration permettant de lister précisément, pour un DUID donné, quels sont les préfixes à déléguer, IAID par IAID, avec une taille allant jusqu’au /56 (et si l’utilisateur sélectionne le /56, ce sera fait à l’exception du /64 réservé par la box, bien entendu). Cela permettrait de contrôler quels sont les routeurs ayant le droit de demander des délégations au sein de son réseau, mais aussi de savoir à l’avance qui obtient quoi. Ce serait par ailleurs plus simple à mettre en œuvre d’un point de vue technique, tout en étant moins susceptible d’avoir des bugs. Enfin, je pense que procéder ainsi couvrirait tous les cas d’usage possible d’une délégation de préfixes IPv6.
Bien sûr, d’aucuns me diront qu’il y a moult instructions sur des forums comme lafibre.info qui expliquent comment se passer de la Livebox. Mais c’est oublier que substituer un routeur tiers à la Livebox revient à mettre une croix sur la ligne téléphonique fixe, incluse dans l’abonnement et que j’utilise beaucoup ; et puisque j’ai déjà eu des problèmes quand j’ai été un peu trop curieux à propos de la téléphonie, ce n’est pas pour tout de suite. En attendant, il n’y a plus qu’à croiser les doigts pour qu’un jour, ces bugs soient corrigés.
Commentaires
Poster un commentaire
Bobii
Concernant la téléphonie, il est tout à fait possible de mettre la LB en aval de ton routeur qui remplace la LB et donc de conserver le tel.
Orsiris
Eh bien estimez vous heureux d'avoir une LB v5 qui permet de disposer du routage IPv6... Le prefix delegation sur une LB v6 ? Inexistant ! C'est honteux à mon sens, de faire en sorte que l'IPv6 soit aussi peu utilisable chez l'opérateur historique...
nscheffer
Merci bcp beaucoup cela m'a permis de mettre en place la délégation de prefixe sur un Fortigate avec deux Livebox (une 5 et une 6 Pro), c'était laborieux mais au final top !
Minikea
Bonjour,
J'essaye de mettre en place l'IPV6 sur mon installation domestique et il semble que la délégation de préfixe fonctionne (encore que je n'en voit pas forcément la preuve) mais si le routage semble fonctionner pour avoir internet en ipv6 depuis le LAN, l'inverse ne semble pas fonctionner: l'extérieur n'accède pas à mon serveur en ipv6. Il semble même que la LB ne transfère rien à mon routeur OpenWRT lorsque j'interroge une url en forçant ipv6 (curl -v -6 https://minikea.org/ ) le tcpdump sur le routeur openwrt ne voit rien passer avec l'ipv6 de mon serveur en destination. j'ai essayé avec une ipv6 fixe, une fournie par DHCP, et rien dans les deux cas. pas de problème en IPV4, mais c'est juste le NAT qui fonctionne.
installation : LiveBox5 <---> Routeur Linksys WRT1200AC (sous OpenWRT 19.07) <---> LAN pas de vlan
★ x0r
La Livebox filtre toutes les connexions IPv6 entrantes, qu’il y ait délégation de préfixes ou non. Avez-vous bien pensé à ajouter une règle dans le pare-feu IPv6 de la box ?
Il suffit normalement juste d’une règle pour autoriser tous les protocoles vers un équipement donné. Je mets ensuite toutes mes règles de filtrage sur le pare-feu en aval.
mixman68
hello,
Merci pour ces tests, je comprends mieux certains de mes bugs Force de constater qu'en décembre 2022 le bug de plusieurs PD pour un routeur est toujours présent.
Est il possible néanmoins de demander plusieurs PD depuis plusieurs devices différents. Si oui une chance que ça marche en LXC via un trunk sur un port réseau mais ça reste pas très propre..
★ x0r
Je n’ai pas testé, mais je pense qu’un contournement est en effet de ne jamais demander plus d’un /64 par adresse MAC.
Vin0x64
Hello Xur,
Merci pour cet article qui m'a permis de me mettre sur la voie et j'ai peut etre une solution à te proposer pour récupérer plus de préfix. Les tests que tu as fait semblent effectivement montrer que le dhcp de la box ne donne qu'un /64 à l'interface de ton routeur. En rajoutant une interface au routeur on arrive a récupérer un autre préfix. Du coup la solution que j'ai mise en place est la suivante (sous linux):
Création d'une interface de type macvlan attachée à la meme interface physique: /bin/ip link add macvlan1 link enp2s0 type macvlan mode bridge Puis lancement du dhclient sur cette interface.
-> Résultat cela permet de récuperer un 2e prefix, et il apparait bien dans l'interface de la livebox.
Voici a quoi ressemble le /etc/network/interfaces
iface macvlan1 inet dhcp pre-up /bin/ip link add macvlan1 link enp2s0 type macvlan mode bridge post-down /bin/ip link del macvlan1
iface macvlan1 inet6 dhcp accept_ra 1 request_prefix 1
★ x0r
Merci beaucoup pour la suggestion des MAC-VLAN, très intéressante ! Je n’ai pas exploré cette voie, mais ça a l’air de pouvoir marcher.
mixman68
A voir pour la macvlan pour la faire marcher avec vyatta (mon routeur)
En tout cas Orange a sorti une MAJ !! le préfixe est rempli désormais dans IPv6 Mais demander plusieurs c'est toujours KO
thomas
vous confondez mode bridge et délégation...
aucune livebox personnelle ne fait de bridge. il faut une offre entreprise. si vous voulez avoir un /56 direct sur le lan....
c'est normal et logique de déléguer un /64 au machine de lan, si la box reçoit un /56 sur le wan, c'est logique on ne peut pas avoir le même prefixe sur deux interfaces directement connectées.......
willy
Merci pour ces infos qui me confirment que ce n'est pas la peine que je perde mon temps dans cette voie. J'ai moi-même fait pas mal de tentatives pour essayer de faire passer de l'IPv6 à travers cet horrible équipement, et absolument tout est buggé dans cette machine. C'est dommage, le hardware semble plutôt bon, le réseau derrière aussi, et tout est gâché par l'incompétence manifeste des développeurs du produit qui ne sont visiblement que des développeurs web qui n'ont jamais eu l'occasion de brancher un câble ethernet, ce qui résulte en des options qui n'ont aucun sens et aucune application sur le terrain, et des manques cruels sur des configs de base. Chez moi j'essaie de faire passer du wireguard en IPv6 depuis une machine interne vers une externe, et pour une raison que j'ignore encore, après un reboot de la box, celle-ci décide de bloquer les paquets retour, comme si elle avait décidé qu'un paquet UDP entrant est forcément une attaque et doit engendrer un blocage définitif. Il me faut alors changer le port source du wireguard local et le relancer pour pouvoir à nouveau fonctionner. Et j'ai des règles FW custom qui autorisent explicitement le flux... De toute façon, entre ça, leur DHCP buggé, leur table de routage qui ignore les masques, leur identification des périphériques par des noms sans possibilité de les créer manuellement, le fait de ne pas pouvoir déléguer manuellement de l'IPv6 etc, je considère qu'Orange fait partie des opérateurs directement responsables du trop faible taux de déploiement IPv6, simplement par leur incompétence. C'est vraiment dommage et je leur en veux beaucoup pour tout ce gâchis. Qu'ils nous donnent juste de quoi entrer des routes IPv4 et IPv6 statiques manuelles vers de vraies destinations (pas des noms de hosts) et tout le monde sera heureux!
Nardol
Merci X0r pour cet article. J'ai également lu votre commentaire au sujet des règles de pare-feu, cependant en ce qui me concerne, même en autorisant tous les protocoles vers mon routeur (TP-link Deco m5) et en rajoutant la règle firewall qui va bien dans ses paramètres, impossible d'ouvrir un port sur l'extérieur. Comme si finalement la Livebox 5 n'avait autorisé que pour l'IPv6 du Deco mais pas pour les adresses de son préfixe Délégué. J'ai mal compris quelque chose ?
lost
@Nardol: C'est un peu tard, mais (dépendant du modèle de LB? Sur une Play en tout cas c'était le cas) il semble y avoir un gros bug: Si on ouvre le FW IPv6 vers un équipement pour un service (dans mon cas un serveur https auto hébergé pour ma domotique)... bin ça ne fonctionne pas! C'est d'ailleurs suite à ce dysfonctionnement que je m'étais rendu compte qu'une nuit Orange m'avait passé en IPv6 sans me prévenir. Ils avaient visiblement converti les règles NAT IPv4 existantes en règles FW IPv6, de manière a priori correcte pourtant. => Demande de retour IPv4, je refais une config NAT et tout remarche... Sauf qu'un jour, je me rends compte que retour à la case départ mais cette fois tout marchait??!! On pense au bug corrigé, sauf que je vois que j'ai encore des règles NAT devenues inutiles (le FW IPv6 avait gardé sa config et point de nouvelle migration de règles avec effacement des anciennes?). Je les vire donc et... plus d'accès externe! Je les remets et ça retombe en marche...
=> Probable qu'il y ait un gros bug: En IPv6 chez Orange, sans règles NAT (a priori inutiles) doublonnant la config FW IPv6 les accès à un serveur auto-hébergé ne fonctionnent pas.
LAB3W.ORJ
Bonjour, merci x0r pour ces informations, merci messieurs aussi.
J'ai ouvert un sujet sur LaFibre.Info par ici, si cela peut vous intéresser. https://lafibre.info/ipv6/comment-faire-plusieurs-reseaux-ipv664-dans-le-bloc-dorange-ipv656/
Bon courage à tous, en espérant qu'ils nous "proposent" une mise à jour fonctionnelles dans la décennie.
Romain.
Elfye95
Bonjour, merci pour cet article En contournement, il est possible d'utiliser des VRRP, associées à un bridge vers l'ethernet de la livebox, et pour chaque VRRP, de demander un prefix IPV6 La livebox affecte un /64 pour chaque mac@ ; testé jusqu'à 4 VRRP Exemple de configuration simplifiée (extrait)
# multiple IPV6 prefix IA_PD delegation from LiveboxV5 for Mikrotik RourerOS 7.X with VRRP on bridge # All personnal information has been removed/replaced # eth1 goes to livebox # br-lan may be used for wifi or eth to LAN # eoip is a tunnel to a VPS
# 2024-08-10 05:13:50 by RouterOS 7.15.3 # model = C53UiG+5HPaxD2HPaxD /interface bridge add name=br-lan port-cost-mode=short add name=br-uplink port-cost-mode=short
/interface ethernet set [ find default-name=ether1 ] name=eth1-uplink
/interface eoipv6 add local-address=2a01:xxx:xxx:xxx:xxx:xxx:xxx:MTMT loop-protect-disable-time=0s loop-protect-send-interval=0s mac-address=XX:XX:XX:XX:XX:XX name=eoipv6-tunnel1 remote-address=xxx::xxx tunnel-id=0
/interface vrrp add interface=br-uplink name=vrrp-uplink1 v3-protocol=ipv6 add interface=br-uplink name=vrrp-uplink2 v3-protocol=ipv6 vrid=2
/interface bridge port add bridge=br-uplink hw=no interface=eth1-uplink
/ipv6 route add disabled=no dst-address=::/0 gateway=2a01:xxx:xxx:xxx:xxx:xxx:xxx:LBOX routing-table=main suppress-hw-offload=no
/ipv6 address add address=2a01:xxx:xxx:xxx:xxx:xxx:xxx:MTMT advertise=no interface=br-uplink add address=::192:168:YYY:1 from-pool=pooldhcp1 interface=br-lan add address=::192:168:ZZZ:1 from-pool=pooldhcp2 interface=eoipv6-tunnel1
/ipv6 dhcp-client add interface=vrrp-uplink1 pool-name=pooldhcp1 request=prefix use-interface-duid=yes use-peer-dns=no add interface=vrrp-uplink2 pool-name=pooldhcp2 request=prefix use-interface-duid=yes use-peer-dns=no
#[hapax3] /ipv6/dhcp-client> print #Columns: INTERFACE, STATUS, REQUEST, PREFIX ## INTERFACE STATUS REQUEST PREFIX #0 vrrp-uplink1 bound prefix 2a01:2a01:2a01:2af0::/64, 23h55m21s #1 vrrp-uplink2 bound prefix 2a01:2a01:2a01:2af1::/64, 23h55m20s #[hapax3] /ipv6/dhcp-client>
#[mt-hapax3] /ipv6/address> print #Flags: I - INVALID, D - DYNAMIC; G - GLOBAL, L - LINK-LOCAL #Columns: ADDRESS, FROM-POOL, INTERFACE, ADVERTISE # # ADDRESS FROM-POOL INTERFACE ADVERTISE # 1 G 2a01:2a01:2a01:2af0:192:168:YYY:1/64 pooldhcp1 br-lan yes # 2 G 2a01:xxx:xxx:xxx:xxx:xxx:xxx:MTMT/64 br-uplink no # 3 G 2a01:2a01:2a01:2af1:192:168:ZZZ:1/64 pooldhcp2 eoipv6-tunnel1 yes # 4 D ::1/128 lo no # 5 DL fe80::fe80:fe80:fe80:fe80/64 br-lan no # 6 DL fe80::fe80:fe80:fe80:fe80/64 br-uplink no # 7 DL fe80::fe80:fe80:fe80:fe80/64 vrrp-uplink1 no #10 DL fe80::fe80:fe80:fe80:fe80/64 vrrp-uplink2 no #11 DL fe80::fe80:fe80:fe80:fe80/64 eoipv6-tunnel1 no #[mt-hapax3] /ipv6/address>
skarnet
Je viens avec un message d'espoir pour ceux qui se heurtent à ce problème : en me hissant sur les épaules de vous tous, géants qui m'avez précédé, j'ai réussi à hacker quelque chose de convenable en contournant la plupart des limitations de la Livebox.
Résumé : Les macvlans ça marche, et la Livebox arrive à déléguer jusqu'à 63 /64 en même temps dans un même /58, ce qui est en pratique assez pour prétendre en agitant les mains que tout le /58 est délégué et faire du routage statique. Il y a des subtilités avec le renouvellement des baux, et avec la configuration de votre routeur derrière la Livebox.
Ma box: Livebox 7, mais le logiciel est exactement le même sur au moins les Livebox 5 et 6 - donc la méthode devrait fonctionner quelle que soit votre Livebox.
En revanche, mon abonnement est Pro. Ça me permet d'avoir une IPv4 statique, dont j'ai besoin professionnellement, et des routes statiques sur la box pour éviter le double NAT. Ça marche très bien. Quant au niveau IPv6... l'offre Pro a exactement les mêmes problèmes que l'offre pour particuliers, je _suppose_ que mes contournements vont marcher aussi si vous avez une offre pour particuliers, mais Dieu seul sait quels horribles bridages IPv6 supplémentaires Orange a pu ajouter à la box quand vous n'êtes pas Pro.
Ma configuration : Internet--fibre--[Livebox]--eth2--[Routeur]--LANs Routeur est un mini-PC sous Linux avec plein d'interfaces réseau, servant aussi d'AP pour le wifi : comme LANs derrière, j'ai eth0 et eth1 en filaire, et wlan0 et wlan1 en wifi. (J'ai désactivé le wifi de la Livebox.)
Si votre routeur est différent, voici ce qu'il doit être capable de faire : - créer 63 MAC-VLANs sur l'interface branchée à la Livebox, ou toute autre méthode générant plusieurs MACs pour une même interface physique. - lancer 63 clients DHCPv6 en parallèle, un par MAC créé - ces clients DHCPv6 doivent être configurés pour envoyer leur requête de renouvellement de bail (renew) en multicast (et non unicast), ou pour sauter l'étape renew et passer directement à l'étape rebinding (qui est toujours multicast). La raison est que la Livebox refuse le renew en unicast.
Vous l'aurez deviné, la méthode est fine et subtile. Puisque la Livebox refuse de déléguer un /56 (ou même seulement un /57 si elle veut adresser elle-même les réseaux autour d'elle), que dirait-elle de déléguer à la place... 256 /64 ? Si le dialogue raisonnable ne fonctionne pas, il ne reste que la violence.
Spoiler : la Livebox n'aime pas. Le maximum qu'elle accepte de déléguer, j'ai abondamment testé, c'est 63 préfixes /64 à la fois. Au-delà, la requête IA_PD échoue avec "No prefix available". Créer une interface supplémentaire et lancer un client DHCPv6 supplémentaire ne servira à rien, ce client n'obtiendra jamais aucun bail.
La bonne nouvelle, c'est que tous les préfixes délégués appartiennent à un même sous-préfixe de votre /56. Mon préfixe est X:yy00::/56, et toutes les délégations que je peux obtenir sont dans X:yyc0::/58. Donc vous ne pourrez pas router tout votre /56, mais vous avez X:yy00::/64 sur le brin relié à la Livebox et vous pouvez avoir un plan d'adressage statique pour X:yyc0::/58 derrière votre routeur.
- Donc. Première étape, créer des MAC-VLANs. C'est indispensable puisque, comme mentionné par plusieurs contributeurs au-dessus, la Livebox refuse lamentablement de déléguer plusieurs préfixes à une même interface. Il est possible d'utiliser d'autres méthodes qui vous donnent des MAC virtuels, mais un macvlan c'est simple et n'occasionne aucune surcharge en runtime. # for i in `seq 63` ; do ip link add eth2_v$i link eth2 type macvlan ; echo 2 > /proc/sys/net/ipv6/conf/eth2_v$i/accept_ra ; ip link set eth2_v$i up ; done
- Ensuite, choisir un client DHCP que vous pouvez lancer en 63 exemplaires sans avoir besoin d'une centrale nucléaire. J'utilise udhcpc6, intégré dans busybox. Il prend peu de RAM, et au besoin (et besoin fut) je sais lire et patcher le code de busybox. Alors que dhcpcd, comme tout programme de l'ISC, est un gouffre à ressources et un labyrinthe de lignes de code incompréhensible, mais si vous avez des gigas de RAM à perdre sur votre routeur et que vous le faites marcher, tant mieux.
- Petite subtilité : la Livebox, dans sa grande sagesse (non), refuse les requêtes de renew en unicast. Il faut donc configurer votre client DHCPv6 pour qu'il envoie ses renew en multicast, ou pour qu'il saute directement à l'étape rebinding (qui est toujours multicast). J'ai dû patcher udhcpc6 pour faire ça ; si mon patch est accepté upstream, c'est l'option "-m" que vous pourrez utiliser. Sinon, le patch est temporairement accessible ici: https://skarnet.org/tmp/udhcpc6.diff.txt
- Autre subtilité : la Livebox, dans sa grande sagesse (vraiment non), s'emmêle les pinceaux quand vous faites une requête d'addresse IA_NA en même temps qu'une requête de délégation IA_PD. Ce que vous voulez, c'est la délégation de préfixe ; vous n'avez pas besoin de demander une adresse pour votre interface macvlan, qui en aura de toute façon normalement obtenue une via SLAAC même si elle ne s'en sert pas. Donc, désactivez l'option IA_NA dans vos requêtes.
- Au final, ma ligne de commande pour chacun des 63 clients DHCPv6 que je lance est la suivante : udhcpc6 -f -d -m -r no -A 600 -i eth2_$1 $1 étant le numéro du macvlan utilisé.
- Et derrière tout ça, je configure un radvd comme si X:yyc0::/58 m'était délégué statiquement, et les machines de mes LANs n'y voient que du feu, et tout marche en ipv6. J'ai mes propres serveurs DNS hébergés sur Routeur, parce que la Livebox va résoudre pour vous tout ce qui est à l'extérieur, mais elle ne connaîtra pas votre réseau local (et heureusement).
Maintenant un peu de détails techniques.
- Les baux durent 30 minutes, et sont normalement renouvelés toutes les 10 minutes. Ils sont stables : une fois que vous en avez un, si vous ne le laissez pas expirer (donc que vous le renouvelez régulièrement), vous pouvez le garder à volonté.
- Par contre, quand un bail expire, vous n'allez pas le récupérer immédiatement : la Livebox essaie de vous refourguer des préfixes aléatoires dans sa plage de 64. Quand vous perdez un préfixe, c'est galère pour le récupérer (voir plus bas). C'est pourquoi il est important de garder vos clients DHCP en vie, afin qu'ils maintiennent le grappin sur le préfixe que vous voulez.
- Si vous avez un client DHCP qui meurt, la Livebox ne supprime pas son bail. Le bail reste valide jusqu'à son expiration, dans 20 à 30 minutes en fonction du dernier renouvellement. Donc vous pouvez encore router le préfixe pendant 20 à 30 minutes ; si vous lancez un autre client DHCP pendant ce temps, si la table est pleine, vous allez vous faire jeter, et si elle ne l'est pas, vous allez récupérer un _autre_ préfixe. Et quand le bail expire, vous ne pouvez plus router son préfixe jusqu'à ce que la Livebox veuille bien vous l'attribuer dans un nouveau bail.
- C'est pourquoi, quand vous faites vos tests, ne vous étonnez pas de ne pas arriver à lancer 63 clients : vous allez en avoir qui échouent, c'est parce qu'il y a encore des baux persistants dans la Livebox, donc la table est encore pleine. Les baux vont expirer au fur et à mesure et vous pourrez lancer de nouveaux clients au fur et à mesure pour maintenir la table pleine. Ma ligne de commande contient "-A 600", c'est pour dire à udhcpc6 de rester en vie après un échec d'obtention de bail et de réessayer toutes les 10 minutes.
- Tout ça serait à peu près raisonnable si la Livebox pouvait vous attribuer 64 préfixes à la fois dans une plage qui en comporte 64. Il suffirait d'avoir 64 clients en permanence et tout serait délégué en permanence, si jamais un bail expire le préfixe libéré est le seul disponible donc un nouveau client se fait immédiatement réattribuer ce préfixe, et c'est parfaitement transparent. N'est-ce pas ? Sauf que oui, vous avez bien lu, la table de la Livebox est pleine à *63*, et pas 64. Donc quoi que vous fassiez, il y a toujours un préfixe qui reste en rade. Si vous êtes malchanceux et que ça tombe sur un réseau que vous avez alloué statiquement et que vous utilisez, la méthode est : 1. tuez un client DHCP qui maintient un préfixe dont vous ne vous servez pas, 2. attendez l'expiration du bail (20 à 30 minutes), 3. relancez le client DHCP. La Livebox lui attribuera l'autre préfixe qui est celui que vous voulez.
- Si vous n'avez pas 30 minutes ou que vous avez perdu le fil de vos baux et ne savez plus ou vous en êtes, vous pouvez rebooter la Livebox, ça va nettoyer sa table de délégation et vos clients DHCP vont pouvoir se jeter à nouveau dessus comme des mouches vertes sur ce bel étron logiciel ; et avec un peu de chance, le préfixe orphelin sera cette fois un que vous n'utilisez pas.
- Puisqu'on n'a que 63 préfixes et pas 64, ne peut-on pas router un /59 plutôt qu'un /58 et éviter le préfixe en rade ? Hélas non, parce que la Livebox choisit aléatoirement dans toute sa plage de délégation, pas seulement la moitié. Vous allez obtenir n'importe quel préfixe entre X:yyc0::/64 et X:yyff::/64, impossible de vous cantonner à X:yyc0::/59 ou X:yye0::/59. Vous devez prendre les 63 et espérer ne pas perdre à la loterie.
- Si ça ne marche pas pour vous (par exemple vous avez trop de LANs et le risque d'avoir un préfixe non routable est trop grand), alors il ne vous reste que l'allocation dynamique. Lancez autant de clients DHCP que vous utilisez de préfixes, et à *chaque* nouveau bail, modifiez votre radvd.conf avec les infos de délégation que vous récupérez. Je l'ai fait, ça fonctionne, mais c'est quand même plus compliqué d'ajouter de la reconfiguration dynamique partout, et si vous avez des DNS internes à maintenir, la couche de complexité est encore plus épaisse.
- Gérer 63 clients DHCP en s'assurant qu'aucun ne meurt sauf quand on veut explicitement en tuer un puis le relancer etc. c'est un peu pénible à faire à la main, surtout quand ils balancent des logs dans tous les sens, que vous voulez savoir qui correspond à quoi, et que vous voulez un peu automatiser tout ça. Un outil de supervision de processus peut vous être utile ! Le mien, c'est s6 : https://skarnet.org/software/s6/ et ça gère mon système les doigts dans le nez, c'est portable sur les BSD et sur n'importe quel Unix raisonnable. Cela dit, n'importe quel outil de supervision dont vous avez l'habitude pourra vous aider, du moment qu'il sait maintenir des services en vie et rassembler des logs. Si vous utilisez une grosse distribution Linux, systemd fera ça très bien pour vous - mais mettre systemd sur un routeur c'est attaquer une mouche au rouleau compresseur.
Pour finir, parlons un peu du routage sur votre LAN.
- Il faut un peu finasser la configuration de radvd sur le brin entre Routeur et Livebox pour que Routeur se comporte en _client_ vis-à-vis de la Livebox et que les messages de pub SLAAC ne se marchent pas sur les pieds. interface eth2 { AdvSendAdvert on ; AdvDefaultLifetime 0 ; AdvDefaultPreference low ; AdvManagedFlag on ; AdvOtherConfigFlag on ; MaxRtrAdvInterval 30 ; prefix X:yy00::/64 { AdvValidLifetime 1800 ; AdvPreferredLifetime 600 ; } ; route X:yyc0::/58 { AdvRoutePreference high ; AdvRouteLifetime 86400 ; # ce que vous voulez ici, c'est pseudo-statique } ; } ;
- Quand vous distribuez vos préfixes par SLAAC, radvd sait pour combien de temps ils vous ont été délégués. Pour éviter qu'il râle, il est bon d'aligner la durée de validité de vos préfixes sur celle du bail. interface eth0 { AdvSendAdvert on ; prefix X:yyc0::/64 { AdvValidLifetime 1800 ; AdvPreferredLifetime 600 ; } ; } ;
- Enfin, il est possible que radvd râle aussi si vous ne publiez pas les RDNSS qu'il reçoit de la Livebox. Vous pouvez les publier si vous voulez que vos clients utilisent le résolveur de la Livebox ; personnellement j'utilise mon propre résolveur à la place, et si vous avez un réseau interne un minimum sérieux, vous ferez de même parce que vous voudrez du nommage interne. Vous ferez également de même si vous ne souhaitez pas subir les bridages DNS imposés par Orange. Dans ce cas, configurez vos propres RDNSS, et laissez radvd râler.
Voilà, ça suffira pour ce roman. Bon courage si vous vous lancez dans cette aventure ; ça m'a pris une grosse semaine pour tout débroussailler, mais maintenant j'ai enfin un réseau professionnellement utilisable derrière une Livebox, donc ça valait le coup. J'espère que ces informations vous aideront à mettre ça en place en moins de temps ! :-)
skarnet
Un ajout: on me signale que le préfixe qui n'est pas délégué est toujours X:yyfe::/64, et quand je regarde ma configuration actuelle, c'est effectivement le cas. À vérifier sur la durée, mais si ça se confirme, c'est une excellente nouvelle : ça signifie que prendre les 63 baux sur X:yyc0::/58 couvre toute la plage sauf un préfixe fixe que la Livebox se réserve pour Dieu sait quelle raison, et donc que vous pouvez faire votre adressage statique tranquillement derrière en évitant simplement ce préfixe.
En revanche, on me dit aussi que le bloc IPv6 attribué par Orange n'est PAS fixe dans une configuration non-Pro, ce qui est complètement délirant et scandaleux. Dans ce cas, si votre offre n'est pas Pro, la méthode est toujours valide et vous pouvez toujours router un /58, mais vous devez quand même faire de la configuration dynamique de votre radvd parce que votre X:yy::/56 risque de changer à chaque fois que vous redémarrez la Livebox. :-/
jerem62
Un grand merci le changement de id client dhcp fonctionne a merveille (utiliser pour assigner un prefix a un réseau de conteneur docker)
Emile
C'est rigolo, je tombe sur cet article quelques semaines après avoir expérimenté la même chose sur une Bbox. On a un peu les mêmes limitations. J'ai documenté ça ici pour les intéressés : https://blog.emiletouron.fr/reseau/ipv6-pd/
Poster un commentaire