Bon, je vois que tu viens du monde de l'industrie, et moi je connais IPv6 par le prisme libriste et académique, mais je vais essayer de comprendre ce que tu racontes (je suis intéressé parce qu'en particulier, les déploiements multicast longue distance réels je n'en ai malheureusement jamais vu en concret) :
Le problème principal est que IPv6 a besoin de nombreux mécanismes en plus du transport unicast pour fonctionner. Entre autre (mais pas seulement) du well known multicast et de tout un tas de protocoles qui utilisent ce well known multicast.
Je ne comprends pas ce qui pose problème : le principe des adresses « bien connues » c'est d'avoir une base commune d'identifiant spécifique à chaque application. Pour NDP il en utilise quelque peu pour fonctionner, et tes IGP aussi ; IPv6 « à la base » n'est même pas définit en fonction de ça.
Pour tous ces mécanismes il existe le plus souvent plusieurs choix, qui sont incompatibles les uns avec les autres et qui en plus passent souvent mal les méthodes de virtualisation de réseau.
Pour les choix, je t'ai vu citer OSPFv3 et IS-IS pour les IGP, mais c'est à peu près tout. Les méthodes de « virtualisation » de réseau, je ne sais pas exactement de quoi tu parles, ça peut recouper des pratiques qui je pense n'ont pas leur place en IPv6.
Typiquement si tu fais du eVPN pour relier deux réseaux
En fait, le problèmes commence déjà ici selon l'approche que j'ai évoquée : si tu te dis que tu as forcément besoin d'un eVPN pour commencer, c'est déjà que tu as un problème applicatif sur la manière dont le réseau est imbriqué avec les applications. Du routage simple devrait théoriquement suffire. Je sais bien que c'est la réalité du terrain, il faut faire avec, mais j'essaye de montrer en quoi IPv6 est handicapé par ces pratiques, pour lesquelles il n'est pas mieux fait qu'IPv4 (à part peut-être grâce à sa taille d'adressage, qui permet de faire des bidouilles d'encapsulation/traduction plus facilement ; mais ça reste des bidouilles).
tu vas avoir vraiment beaucoup de mal à faire que les infos multicasts passent correctement d'une branche de réseau à l'autre via l'overlay.
Pourquoi ? Parce qu'elles sont mal scopées à la base ? Problème de configuration alors, comme je l'évoquais au début, qui est le compagnon des problèmes applicatifs.
Par exemple tu veux fusionner les cœurs de réseau de deux sites, mais tu veux que les bordures de réseau et les vlans internes restent chacun sur leur site. De ton coté tu utilises SLAAC + DHCPv6 static pour configurer tes machines internes - de l'autre l'admin utilise aussi SLAAC mais utilise le WKM pour mettre le DNS sur la gateway en ::3.
Je ne sais pas ce qu'est WKM, mais si tu parles de ne pas partager les VLAN je suppose que tu parles de routage pur, et à ce moment-là les méthodes de configuration des deux sites sont complètement indépendantes ! Je ne vois pas où est le problème encore une fois d'avoir ces deux méthodes des deux côté (à part en complexité opérationnelle, mais ça n'est pas la faute d'IPv6).
Si WKM est un mécanisme de Microsoft pour provisionner les machines, je supputes que c'est pour contourner le fait que MS a toujours refusé de faire du provisionning des resolvers DNS par RA avec RDNSS et oblige à passer par DHCPv6, et que l'admin devait avoir la flemme. Toujours pas la faute d'IPv6 !
Après de ton coté les routes convergent en utilisant IS-IS, mais de l'autre coté tout est réglé pour utiliser OSPFv3. OSPFv3 est aussi utilisé pour les segments sur la même branche entre switchs/routeurs alors que toi pour ces segments là tu utilises NDP.
Là je te suis un peu moins : oui, si tu veux échanger tes tables de routage entre tes deux IGP, ça va être un peu plus galère. Mais bon, à défaut de machine qui pourrait mélanger les deux (je suppose que bird le fait en libre, mais tu as l'air d'être bloqué sur du Cisco/Juniper & co), tu peux toujours n'annoncer qu'un préfixe qui englobe tout de chaque côté, vu que de toutes façons on parle d'un seul lien entre deux sites, non ? Ou faire parler les deux en BGP (déjà fait ici ; ça rajoute un troisième larron, mais ça marche). Je n'ai par contre pas compris la deuxième partie.
Et tout ça c'est de la complication applicative — certes liée au routage — mais qui encore une fois n'est pas plus complexe qu'en IPv4. Tu peux regretter qu'IPv6 n'ai pas unifié tous les IGP, mais il n'a pas de pouvoir magique pour mettre tout le monde d'accord sur l'applicatif ; déjà que standardiser sur un format de paquet commun c'était galère...
Et bien bonne chance pour réussir ta mission sans reconfigurer tous les équipements d'un coté ou de l'autre, voire en racheter au cas ou certains mécanismes ne sont pas disponibles.
Je ne vois pas la nécessité de reconfigurer « tous les équipments » : ceux en bordure, oui, le reste je ne comprends pas. Pour les mécanismes dispos, ça dépend de la politique de ton constructeur, et c'était pareil en v4 (avec moins de maturité pour v6, je l'accorde), mais tu peux toujours passer par des workaround moins optimisés également. Je ne vois pas de complexité « en plus », à défaut d'être mieux qu'IPv4 sur ce point précis.
Et là on essaye de faire un lien pur L2. Bien sur à chaque fois que l'on remonte un layer on se prend une couche de complexité supplémentaire.
Pourquoi vouloir étendre un L2 ? C'est évident que la complexité va arriver, après.
(Genre connecter le cloud kubernetes du site A et tous ses réseaux virtuels sur le coeur du site B)
Ah, très bonne remarque : Kubernetes, Docker, OpenStack et consorts, toutes ces technos « modernes », ont été faite avec zéro IPv6 en tête. Ce sont des archis entièrement basées sur du NATtage dans tous les sens, pour lesquelles on a mis IPv6 à posteriori pour faire joli. Alors forcément c'est moche. Les mecs qui ont fabriqué ces horreurs n'y bitent rien en réseau, et c'est une tragédie pour des soft soit-disant modernes.
Ce qui me ramène encore une fois à mon point initial : le problème est dans les softs qui sont codés à contrario de l'archi Internet, et qui se comportent donc très mal avec IPv6. C'est là que le bât blesse et qu'il faut améliorer les choses pour qu'IPv6 perce mieux.
[^] # Re: Tout doucement alors
Posté par benoar . En réponse au journal L'IPv6 et moi. Évalué à 2.
Bon, je vois que tu viens du monde de l'industrie, et moi je connais IPv6 par le prisme libriste et académique, mais je vais essayer de comprendre ce que tu racontes (je suis intéressé parce qu'en particulier, les déploiements multicast longue distance réels je n'en ai malheureusement jamais vu en concret) :
Je ne comprends pas ce qui pose problème : le principe des adresses « bien connues » c'est d'avoir une base commune d'identifiant spécifique à chaque application. Pour NDP il en utilise quelque peu pour fonctionner, et tes IGP aussi ; IPv6 « à la base » n'est même pas définit en fonction de ça.
Pour les choix, je t'ai vu citer OSPFv3 et IS-IS pour les IGP, mais c'est à peu près tout. Les méthodes de « virtualisation » de réseau, je ne sais pas exactement de quoi tu parles, ça peut recouper des pratiques qui je pense n'ont pas leur place en IPv6.
En fait, le problèmes commence déjà ici selon l'approche que j'ai évoquée : si tu te dis que tu as forcément besoin d'un eVPN pour commencer, c'est déjà que tu as un problème applicatif sur la manière dont le réseau est imbriqué avec les applications. Du routage simple devrait théoriquement suffire. Je sais bien que c'est la réalité du terrain, il faut faire avec, mais j'essaye de montrer en quoi IPv6 est handicapé par ces pratiques, pour lesquelles il n'est pas mieux fait qu'IPv4 (à part peut-être grâce à sa taille d'adressage, qui permet de faire des bidouilles d'encapsulation/traduction plus facilement ; mais ça reste des bidouilles).
Pourquoi ? Parce qu'elles sont mal scopées à la base ? Problème de configuration alors, comme je l'évoquais au début, qui est le compagnon des problèmes applicatifs.
Je ne sais pas ce qu'est WKM, mais si tu parles de ne pas partager les VLAN je suppose que tu parles de routage pur, et à ce moment-là les méthodes de configuration des deux sites sont complètement indépendantes ! Je ne vois pas où est le problème encore une fois d'avoir ces deux méthodes des deux côté (à part en complexité opérationnelle, mais ça n'est pas la faute d'IPv6).
Si WKM est un mécanisme de Microsoft pour provisionner les machines, je supputes que c'est pour contourner le fait que MS a toujours refusé de faire du provisionning des resolvers DNS par RA avec RDNSS et oblige à passer par DHCPv6, et que l'admin devait avoir la flemme. Toujours pas la faute d'IPv6 !
Là je te suis un peu moins : oui, si tu veux échanger tes tables de routage entre tes deux IGP, ça va être un peu plus galère. Mais bon, à défaut de machine qui pourrait mélanger les deux (je suppose que bird le fait en libre, mais tu as l'air d'être bloqué sur du Cisco/Juniper & co), tu peux toujours n'annoncer qu'un préfixe qui englobe tout de chaque côté, vu que de toutes façons on parle d'un seul lien entre deux sites, non ? Ou faire parler les deux en BGP (déjà fait ici ; ça rajoute un troisième larron, mais ça marche). Je n'ai par contre pas compris la deuxième partie.
Et tout ça c'est de la complication applicative — certes liée au routage — mais qui encore une fois n'est pas plus complexe qu'en IPv4. Tu peux regretter qu'IPv6 n'ai pas unifié tous les IGP, mais il n'a pas de pouvoir magique pour mettre tout le monde d'accord sur l'applicatif ; déjà que standardiser sur un format de paquet commun c'était galère...
Je ne vois pas la nécessité de reconfigurer « tous les équipments » : ceux en bordure, oui, le reste je ne comprends pas. Pour les mécanismes dispos, ça dépend de la politique de ton constructeur, et c'était pareil en v4 (avec moins de maturité pour v6, je l'accorde), mais tu peux toujours passer par des workaround moins optimisés également. Je ne vois pas de complexité « en plus », à défaut d'être mieux qu'IPv4 sur ce point précis.
Pourquoi vouloir étendre un L2 ? C'est évident que la complexité va arriver, après.
Ah, très bonne remarque : Kubernetes, Docker, OpenStack et consorts, toutes ces technos « modernes », ont été faite avec zéro IPv6 en tête. Ce sont des archis entièrement basées sur du NATtage dans tous les sens, pour lesquelles on a mis IPv6 à posteriori pour faire joli. Alors forcément c'est moche. Les mecs qui ont fabriqué ces horreurs n'y bitent rien en réseau, et c'est une tragédie pour des soft soit-disant modernes.
Ce qui me ramène encore une fois à mon point initial : le problème est dans les softs qui sont codés à contrario de l'archi Internet, et qui se comportent donc très mal avec IPv6. C'est là que le bât blesse et qu'il faut améliorer les choses pour qu'IPv6 perce mieux.