Non, non
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.
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. Typiquement si tu fais du eVPN pour relier deux réseaux 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.
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.
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.
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.
Le plus souvent c'est un bazar sans nom et tu es obligé de passer par la case interruption de service.
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. (Genre connecter le cloud kubernetes du site A et tous ses réseaux virtuels sur le coeur du site B)
[^] # Re: Tout doucement alors
Posté par Kaane . En réponse au journal L'IPv6 et moi. Évalué à 0.
Non, non
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.
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. Typiquement si tu fais du eVPN pour relier deux réseaux 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.
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.
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.
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.
Le plus souvent c'est un bazar sans nom et tu es obligé de passer par la case interruption de service.
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. (Genre connecter le cloud kubernetes du site A et tous ses réseaux virtuels sur le coeur du site B)