La Fibre
Télécom => Réseau => 
IPv6 => Discussion démarrée par: 0xgrm le 27 avril 2023 à 19:30:20
-
Bonjour à tous,
Je me suis enfin lancé dans l'aventure IPv6 sur mon réseau local.
Je fais tourner un routeur VyOS virtuel sur Proxmox derrière une Freebox Delta en fibre, en mode routeur.
VyOS récupère l'IP de son interface WAN via la délégation du premier préfixe de la Freebox en DHCPv6-PD.
Ce que je n'arrive pas à faire, c'est de faire la délégation des préfixes suivants aux interfaces LAN en DHCPv6-PD. Cela ne fonctionne que lorsque je le délègue de manière statique.
De ce que j'ai compris de mes recherches, c'est que :
- Free alloue un /60 à chaque abonné (bien qu'on n'ait accès qu'à un /61 depuis la Freebox)
- le premier préfixe est dédié au WAN
J'ai configuré mon interface WAN et la délégation de préfixe comme suit :
ethernet eth2 {
address dhcp
address fe80::1/64
address dhcpv6
description WAN
hw-id <REDACTED>
dhcpv6-options {
pd 0 {
interface eth0.100 {
address 1
sla-id 1
}
length 60
}
rapid-commit
}
ipv6 {
address {
autoconf
}
}
offload {
gro
gso
sg
tso
}
}
Avant de vous dévoiler de manière plus détaillée ma configuration : est-il tout simplement possible d'obtenir la délégation des préfixes LAN en DHCPv6-PD depuis la Freebox vers VyOS ?
-
non la Freebox ne fait que du statique. Elle ne sait pas faire du DHCPv6-PD.
VyOS récupère l'IP de son interface WAN via la délégation du premier préfixe de la Freebox en DHCPv6-PD.
non y'a pas DHCPv6-PD la. c'est DHCPv6 simple (aucun interet a en faire d'ailleurs).
Le WAN de ton vyOS n'a pas besoin d'IPv6 publique, il suffit juste de lui indiqué l'ip-link local de la Freebox comme gateway.
le premier préfixe est dédié au WAN
non pas nécessairement. tu peux utiliser le premier prefixe si tu n'en a pas besoin d'IPv6 sur d'autres équipements derriere la freebox.
-
non y'a pas DHCPv6-PD la. c'est DHCPv6 simple (aucun interet a en faire d'ailleurs).
C’est pas du SLAAC plutôt ?
Mais oui sinon aucun intérêt de gaspiller un des 8 /64 sur l’interface WAN, les adresses Link-Local sont là pour ça.
-
C’est pas du SLAAC plutôt ?
Mais oui sinon aucun intérêt de gaspiller un des 8 /64 sur l’interface WAN, les adresses Link-Local sont là pour ça.
La Freebox prédécoupe les segments pour SLAAC. Elle fait bien sûr du RDNSS mais elle a une option non active par défaut pour tourner un dhcpv6. Je ne l'ai pas utilisée donc je ne commenterai pas plus avant.
Quant à la question du gaspillage et la non présence d'une adresse globale via interface externe, c'est votre opinion, c'est pourtant ce que vous auriez avec une délégation de préfixe et une option d'exclusion. Ca relève de la facilité de vos caractéristiques de déploiement.
Dans le cas de l'utilisation par le quidam du paramétrage Free, gaspiller un segment peut être dommage en effet mais a aussi la vertu de pouvoir configurer et maintenir une route.
-
c'est pourtant ce que vous auriez avec une délégation de préfixe et une option d'exclusion.
Bah je suis chez Orange, DHCP6-PD donc, et mon routeur (perso, en front, pas de LB donc) n'a pas de GUA sur son interface WAN. D'où mon terme "gaspillage" parce que ça fonctionne sans (et ça n'empêche pas le routeur d'être joignable de l'extérieur sur l'une de ses GUA coté LAN). Après, évidemment ça fonctionne aussi avec... Mais étant donné que chez Free on n'a que 8 /64 dispo ça peut être dommage d'en utiliser un pour seulement 1 adresse...
Et les routes peuvent parfaitement s'appuyer uniquement sur les adresses Link-Local. Perso le seul bénéfice que je vois à l'utilisation d'adresses GUA (voir ULA) sur un lien qui ne sert qu'au routage c'est avoir des traceroutes avec tous les sauts qui répondent.
-
Merci pour vos réponses.
Effectivement je suis conscient que mon routeur n'a pas nécessairement besoin d'une GUA sur son WAN pour pouvoir router les paquets. Toutefois j'ai un tunnel Wireguard dessus, j'ai donc besoin d'une GUA. Je m'interroge donc sur les bonnes pratiques : est-il plus approprié d'y accéder par la GUA qu'il acquiert sur son LAN ?
Quant au gaspillage de préfixe, la Freebox a une GUA sur le premier préfixe. C'est pour cela que je ne délègue pas ce préfixe à mes équipements sur le LAN. Ai-je tord de penser ainsi ?
non la Freebox ne fait que du statique. Elle ne sait pas faire du DHCPv6-PD.
OK, cela explique donc pourquoi elle sait allouer une IP sur le WAN de mon routeur en DHCPv6 mais pas déléguer l'un des 8 préfixes sur une interface LAN.
Je suis d'accord sur le fait que ça n'a pas un grand intérêt, c'était surtout dans un but éducatif sur le fonctionnement de l'IPv6.
-
Effectivement je suis conscient que mon routeur n'a pas nécessairement besoin d'une GUA sur son WAN pour pouvoir router les paquets. Toutefois j'ai un tunnel Wireguard dessus, j'ai donc besoin d'une GUA. Je m'interroge donc sur les bonnes pratiques : est-il plus approprié d'y accéder par la GUA qu'il acquiert sur son LAN ?
Tu peux parfaitement utiliser la GUA d'une patte LAN (ou la GUA d'une loopback, d'ailleurs) pour terminer ton tunnel wireguard.
J'utiliserai peut être une adresse de service pour le tunnel wireguard (une GUA dédiée à wireguard, potentiellement assignée à une interface loopback) afin de pouvoir le déplacer facilement et ne pas être tributaire de l'état opérationnel (up/down) d'une interface pour utiliser le VPN.
Quant à la bonne pratique, aucun souci pour ne pas avoir de GUA sur la patte WAN. Les messages ICMP (packet too big, destination unreachable, etc.) seront émis avec l'adresse source GUA de l'une des pattes LAN, ca ne pose pas de problème. Pour un réseau composé d'un unique routeur avec un ou plusieurs VLAN, je ne vois pas l'intérêt de cramer un /64.
-
J'utiliserai peut être une adresse de service pour le tunnel wireguard (une GUA dédiée à wireguard, potentiellement assignée à une interface loopback) afin de pouvoir le déplacer facilement et ne pas être tributaire de l'état opérationnel (up/down) d'une interface pour utiliser le VPN.
Cette idée est géniale ! Décidément, l'IPv6 m'en fait apprendre beaucoup et revoir totalement ma façon de penser le réseau.
Quant à la bonne pratique, aucun souci pour ne pas avoir de GUA sur la patte WAN. Les messages ICMP (packet too big, destination unreachable, etc.) seront émis avec l'adresse source GUA de l'une des pattes LAN, ca ne pose pas de problème. Pour un réseau composé d'un unique routeur avec un ou plusieurs VLAN, je ne vois pas l'intérêt de cramer un /64.
Je suis d'accord que ça n'a aucun sens de cramer un /64 pour le WAN avec un unique routeur.
Toutefois, comme je le disais, la Freebox a une GUA attribuée sur son premier préfixe : xxxx:xxxx:xxxx:xxx0::1/64. Donc même si je n'attribue pas de GUA à l'interface WAN de VyOS sur ce préfixe, puis-je l'utiliser pour un LAN ou un VLAN derrière ?
-
Toutefois, comme je le disais, la Freebox a une GUA attribuée sur son premier préfixe : xxxx:xxxx:xxxx:xxx0::1/64. Donc même si je n'attribue pas de GUA à l'interface WAN de VyOS sur ce préfixe, puis-je l'utiliser pour un LAN ou un VLAN derrière ?
si le next-hop du 1er prefixe /64 est renseigné, la freebox ne se configure pas ce GUA en question (c'est d'ailleurs indiqué dans l'interface il me semble ?).
donc oui tu peux sans souci l'utiliser derriere ton VyOS.
si le next-hop du 1er prefixe /64 est vide alors la freebox l'utilise:
- elle prend 1er-prefixe::1/64 pour elle meme sur son interface "lan" (= bridge de ses ports lan et du wifi)
- elle annonce 1er-prefixe::/64 sur son "lan" par RA (SLAAC) et DHCPv6 (ce dernier est désactivable je crois)
-
si le next-hop du 1er prefixe /64 est renseigné, la freebox ne se configure pas ce GUA en question (c'est d'ailleurs indiqué dans l'interface il me semble ?).
donc oui tu peux sans souci l'utiliser derriere ton VyOS.
C'est bon j'ai enfin pigé la subtilité. Merci beaucoup !
-
Quant à la bonne pratique, aucun souci pour ne pas avoir de GUA sur la patte WAN. Les messages ICMP (packet too big, destination unreachable, etc.) seront émis avec l'adresse source GUA de l'une des pattes LAN, ca ne pose pas de problème. Pour un réseau composé d'un unique routeur avec un ou plusieurs VLAN, je ne vois pas l'intérêt de cramer un /64.
Je suis très curieux de la production de vos "bonnes" pratiques puisque une autorité (l'IETF), elle, quand elle doit résoudre ce problème de délégation d'un seul et même préfixe à la fois au routeur et au reste de l'environnement du client ne préconise pas l'absence d'adresse de portée globale au routeur mais l'introduction d'une option DHCP pour détacher une sous-partie du préfixe pour pouvoir la fournir au routeur (rfc 6603).
Dans le cadre de Free, le travail est déjà pré-mâché puisque les segments sont déjà individualisés (et qu'on n'utilise pas DHCP pour la délégation).
De toute façon, il ne faut pas avoir une connaissance intime de la mécanique des OS pour réaliser que dissocier adresse (liée à une interface) et l'interface de transit n'est pas l'option de traitement idéale tant en sécurité qu'en performance. Là où ça prend encore de l'ampleur c'est quand on préconise des contortions pour ipv6 quand de toute manière IPv4 sera frontal et que le routeur en question sera déjà, par essence, filtrant (à état qui plus est).
Peut-être, une meilleure manière de reformuler votre développement serait de dire que si l'OP (dans son cadre) a besoin d'un huitième segment, il peut trouver une solution plus ou moins acceptable pour l'utiliser en interne. Mon avis est qu'autrement c'est une vraisemblablement une régression.
Ceci dit, @kgersen a factuellement fourni les clefs du fonctionnement de la box, à l'OP de voir en fonction de ses connaissances. Si je me permets d'intervenir c'est pour un regard critique sur les soi-disant meilleures manières de faire.
-
Peut-être, une meilleure manière de reformuler votre développement serait de dire que si l'OP (dans son cadre) a besoin d'un huitième segment, il peut trouver une solution plus ou moins acceptable pour l'utiliser en interne. Mon avis est qu'autrement c'est une vraisemblablement une régression.
Ceci dit, @kgersen a factuellement fourni les clefs du fonctionnement de la box, à l'OP de voir en fonction de ses connaissances. Si je me permets d'intervenir c'est pour un regard critique sur les soi-disant meilleures manières de faire.
Merci pour ton intervention. Je n'ai pas besoin pour le moment d'un huitième segment.
Toutefois, pourrais-tu expliquer pourquoi ne pas attribuer une adresse globale sur l'interface WAN peut constituer un risque en terme de sécurité ou de performance ?
Je n'arrive pas à saisir la différence fonctionnelle entre les deux cas de figure, d'autant plus que j'ai besoin que le routeur soit accessible de l'extérieur pour mon tunnel Wireguard.
-
Je suis très curieux de la production de vos "bonnes" pratiques puisque une autorité (l'IETF), elle, quand elle doit résoudre ce problème de délégation d'un seul et même préfixe à la fois au routeur et au reste de l'environnement du client ne préconise pas l'absence d'adresse de portée globale au routeur mais l'introduction d'une option DHCP pour détacher une sous-partie du préfixe pour pouvoir la fournir au routeur (rfc 6603).
Dans le cadre de Free, le travail est déjà pré-mâché puisque les segments sont déjà individualisés (et qu'on n'utilise pas DHCP pour la délégation).
pas vraiment d'accord la mais on part un peu en hors sujet.
la préco de l'IETF c'est de ne pas utiliser un prefix délegué sur l'interface qui sert au DHCP:
ce que dit la rfc 3633:
with the following exception: the requesting router MUST
NOT assign any delegated prefixes or subnets from the delegated
prefix(es) to the link through which it received the DHCP message
from the delegating router.
c'est sur le lien qui sert a la réception des messages DHCPv6-PD qu'il ne faut pas utiliser un des prefix.
D'ailleurs la livebox par exemple respecte cette norme: elle n'a pas de GUA coté WAN, elle y recoit un /56 via DHCPv6-PD mais ne configure pas de /64 (de ce /56) sur son WAN car elle respecte cette rfc.
autrement dit: si on veut une GUA sur son WAN il fallait utiliser autre chose que de s'approprier un prefix recu par dhcp-v6 sur son WAN SI aussi on redistribue les prefixes recues comme serveur dhcpv6-pd (le SI est important). Pourquoi ? parce que, entre autres, cela crée 2 routes pour le routeur en amont ce qui dans certaines config (notamment en partage de connexion via un mobile par exemple) pose probleme.
la rfc6603 permet de palier a cette contrainte en permettant d'exclure un /64 qui pourra faire l'objet d'une telle utilisation.
rfc 6603:
The OPTION_PD_EXCLUDE option
allows prefix delegation where a requesting router is delegated a
prefix (e.g., /56) and the delegating router uses one prefix (e.g.,
/64) on the link through which it exchanges DHCPv6 messages with the
requesting router with a prefix out of the same delegated prefix set.
mais c'est une option quand on veut vraiment faire cette double utilisation particulière d'une délégation. Ce n'est pas a généraliser pour toute les configs dhcpv6-pd.
De toute façon, il ne faut pas avoir une connaissance intime de la mécanique des OS pour réaliser que dissocier adresse (liée à une interface) et l'interface de transit n'est pas l'option de traitement idéale tant en sécurité qu'en performance. Là où ça prend encore de l'ampleur c'est quand on préconise des contortions pour ipv6 quand de toute manière IPv4 sera frontal et que le routeur en question sera déjà, par essence, filtrant (à état qui plus est).
pourquoi ? niveau sécurité c'est mieux de ne pas avoir de GUA coté WAN (le routeur peut avoir une GUA coté LAN ou en loopback interne pour termination VPN par exemple).
niveau performance / routage je ne vois pas trop ou est le probleme.
Il n'y pas de contorsions, c'est plutôt standard en IPv6.
Je serais curieux d'avoir plus de détails la.
-
Yep, je suis en accord avec kgersen, et je veux bien des infos sur l'impact sécu/performance moi aussi.
Pour être précis, je ne prétendais pas énoncer des bonnes pratiques, mais répondre au questionnement de l'OP sur les bonnes pratiques. Il n'y a pour moi ni impact sécu, ni impact sur les performances, à assigner un /128 à une interface de loopback et l'utiliser pour terminer le traffic localement destiné au routeur. Il n'y en a pas non plus à utiliser l'adresse GUA assignée à une autre interface que celle du WAN, et à avoir une interface WAN sans GUA.
Ca va sans dire, la solution que je présentais est en effet en prod, et elle marche bien :)
Enfin, pas sur de voir le lien avec du stateful filtering, on en a à priori pas parlé ici.
-
pas vraiment d'accord la mais on part un peu en hors sujet.
la préco de l'IETF c'est de ne pas utiliser un prefix délegué sur l'interface qui sert au DHCP:
ce que dit la rfc 3633:
c'est sur le lien qui sert a la réception des messages DHCPv6-PD qu'il ne faut pas utiliser un des prefix.
D'ailleurs la livebox par exemple respecte cette norme: elle n'a pas de GUA coté WAN, elle y recoit un /56 via DHCPv6-PD mais ne configure pas de /64 (de ce /56) sur son WAN car elle respecte cette rfc.
autrement dit: si on veut une GUA sur son WAN il fallait utiliser autre chose que de s'approprier un prefix recu par dhcp-v6 sur son WAN SI aussi on redistribue les prefixes recues comme serveur dhcpv6-pd (le SI est important). Pourquoi ? parce que, entre autres, cela crée 2 routes pour le routeur en amont ce qui dans certaines config (notamment en partage de connexion via un mobile par exemple) pose probleme.
la rfc6603 permet de palier a cette contrainte en permettant d'exclure un /64 qui pourra faire l'objet d'une telle utilisation.
rfc 6603:mais c'est une option quand on veut vraiment faire cette double utilisation particulière d'une délégation. Ce n'est pas a généraliser pour toute les configs dhcpv6-pd.
pourquoi ? niveau sécurité c'est mieux de ne pas avoir de GUA coté WAN (le routeur peut avoir une GUA coté LAN ou en loopback interne pour termination VPN par exemple).
J'entends bien ce que vous dites mais je n'en comprends pas la finalité par rapport aux points précédents:
- L'affirmation que l'absence de GUA sur patte WAN relève des "meilleures pratiques"
- Le fait qu'un utilisateur du fil (avec Orange) ne dispose pas d'une telle adresse en uplink ne justifie pas la pratique, que c'est la contrainte ou les caractéristiques de déploiement de son opérateur qui le place dans cette position et que, dans sa situation, si l'opérateur suivait la rfc 6603, il serait dans un cas proche de celui présentement chez Free avec une sous partie du préfixe délégué utilisable sur l'uplink.
Il n'y a pas de logique à faire valoir un point de rfc antérieure n'indiquant pas que la patte WAN ne doit pas recevoir d'adresse globale (d'un autre prefixe ou du même préfixe puisque justement mise à jour par une autre rfc depuis 10 ans quand même)
Nonobstant le fait que la délégation de préfixe au travers de la box Orange n'est pas vraiment un exemple en l'état actuel, les dispositions particulières d'un opérateur ne font pas loi pour les autres. C'est précisément un des cas d'espèce ici.
Pour éviter de rendre l'avis personnel, je vais simplement me retirer de l'équation en tant que noname random du forum. Le RIPE non seulement recommande l'affectation d'adresse globale sur l'uplink mais indique également que c'est le cas le plus fréquemment déployé. Précisément dans ses "bonnes pratiques". Alors ils ont peut-être tort, peut-être même que tout le monde ne pense pas pareil au sein du RIPE, ce n'est d'ailleurs pas un diktat, peut-être que tous ceux en Europe déployant ainsi (avec un autre préfixe dédié ou issu du même préfixe), majoritaires, n'ont pas la meilleure approche mais pour l'évaluer ou le savoir il faudrait avoir accès à un argumentaire étayant l'affirmation contraire stipulée plus avant dans ce fil. Or ce n'est pas le cas.
-
J'entends bien ce que vous dites mais je n'en comprends pas la finalité par rapport aux points précédents:
- L'affirmation que l'absence de GUA sur patte WAN relève des "meilleures pratiques"
Hm, justement, je crois qu'il y a erreur : personne n'a dit ca ici.
-
oui personne n'a dit ca.
si l'opérateur suivait la rfc 6603, il serait dans un cas proche de celui présentement chez Free avec une sous partie du préfixe délégué utilisable sur l'uplink
Free ne faisant pas de DHCPv6-PD la comparaison ne sert a pas a grand chose. D'autant qu'on compare une situation différente: dans le cas d'Orange qu'on mentionne on remplace la livebox , dans le cas présent on garde la freebox.
Si on cherche a remplacer la Freebox on ne sait toujours pas (a ma connaissance) comment faire pour le moment et si ou non y'a du DHCPv6-PD entre la freebox et le réseau de Free ?
Pour ce qui est de la rfc6603 je ne sais meme pas quel systeme la supporte dans un cadre "hors mobile". C'est une rfc pondue par des équipementiers mobiles (Nokia,Ericsson,Cisco) pour un usage avant tout mobile. Je ne sais pas si les implémentations classiques, non spécifiquement mobile, de DHCPv6-PD supportent cette rfc.
Le RIPE non seulement recommande l'affectation d'adresse globale sur l'uplink mais indique également que c'est le cas le plus fréquemment déployé.
source ?
Le RIPE a peut être une reco pour des cas 'entreprises' ou d'opérateurs Internet ?
je ne pense qu'il faille avoir avec un 'dogme' ou une "bonne pratique" trop générale. Dans plein de cas simples (particulier, soho, petite site remote, etc) il n'a y quasi pas d'utilité à avoir une GUA sur le WAN. Ca marche sans donc les gens font sans. Pourquoi ajouter de la complexité ou y'en a pas besoin ?
En général, la simplicité dicte les bonnes pratiques.
-
+1 sur le fait qu'une IP GUA sur le WAN ne sert a rien, chez nous on le fait pour une seule raison : éviter les clients dhcp qui demandent une IPv6 en boucle...
-
Probablement https://www.ripe.net/publications/docs/ripe-690
In order to facilitate troubleshooting and have a future proof network, you should consider numbering the WAN links using GUAs, using a /64 prefix out of a dedicated pool of IPv6 prefixes. If you decide to use /127 for each point-to-point link, it is advisable to allocate a /64 for each link and just use one /127 out of it.
4.1. Numbering the WAN link (interconnection between the network and the end-user CPE)
4.1.1. /64 prefix from a dedicated pool of IPv6 prefixes
Using a /64 prefix from a dedicated pool of IPv6 prefixes is the most common scenario and currently the best practice. A separate block of IPv6 space is allocated for the WAN links to the end customer CPEs, so that when CPE connects to the network and performs router discovery, a /64 prefix is used to number both ends of the connection.
-
Probablement https://www.ripe.net/publications/docs/ripe-690
a merci pour le lien.
oui et a lire tout 4.1.2, on voit bien qu'il n'y a pas de "recette unique" et que la publication s'adresse avant tout a des opérateurs.
Dans le cas d'Orange par exemple , leur design est fait pour que seule une livebox qu'ils contrôlent est directement sur le wan. Livebox qui s'attribuent une GUA sur son LAN. Il n'y a pas de scénario dans ce design ou c'est un équipement autre qu'une livebox qui est sur le lien.
ce qu'indique bien la publication du ripe:
4.1.2. Unnumbered
....
It is most useful in scenarios where it is known that only CPEs will be attached to the WAN link, and where a “pingable” address of the CPE is known (e.g. because the ISP-provided CPEs are always “pingable” on the first delegated address)
D'ailleurs c'est en cohérence avec la RFC 7084 https://datatracker.ietf.org/doc/html/rfc7084#section-4.2, requirements WAA-7:
WAA-7: If the IPv6 CE router does not acquire a global IPv6
address(es) from either SLAAC or DHCPv6, then it MUST create
a global IPv6 address(es) from its delegated prefix(es) and
configure those on one of its internal virtual network
interfaces, unless configured to require a global IPv6
address on the WAN interface.
et que le support de la RFC 6603 est SHOULD not MUST (WPD-8).