Je fais un nouveau sujet car vu les retours en privé, je pense qu'il y a de quoi dire encore et cela devrait intéresser d'autres personnes.
Déjà merci pour vos remerciements en privé, à croire que le sujet est tellement délicat que recueillir un peu d'information parait bénéfique à tous.
Pour continuer la discussion, - en réponse à Denis qui me dit être content de voir des personnes qui n'ont pas peur d'ipv6, j'ai eu un déclic tout bête mais quand je relis mes bouquins ipv6 ou les cours il y a 10 ans cela n'était pas le même discours. C'est simplement les assignations de subnet.
Pour ceux qui ont été sensibilisé à l'ipv6, on a tous entendu, "faut attribuer un /64 minimum à chaque serveur" Du coup on pense organisation de routage alors que non c'est complètement faux. Il faut voir cela autrement.
Cela vient du fait qu'effectivement quand on prend un serveur dédié chez Toto hébergement, on a toujours un /64 attribué au serveur. Mais dans les faits on utilise une ip.
Si on est là pour faire du hosting maitrisé avec infogérance (c'est mon cas). On a affecté un /64 par client comme y a 10 ans où on attribuait des PI /24. Après les serveurs dedans ont une seule adresse ip (c'est déjà pas mal) et font parti du subnet. On ne route pas un subnet vers un serveur comme chez les loueurs de serveurs qui font cela pour pas avoir à gérer vos demandes d'ipv6.
Bref je ne sais plus qui m'avait fait faire ce déclic, qu'il en soit remercié, on enlève toute la problématique routage qu'on m'avait présenté depuis 10 ans. Et là tout devient simple, chaque client à son subnet /64 regroupé dans une allocation plus grande. Après qu'on décide de faire des passerelles dédiées à chaque subnet ou que l'on mette un routage global, chacun son archi.
- pour répondre à Sylvain, oui tout faire en dual stack en se trainant du nat sur le v4 et du routage sur le v6 c'est juste impossible à maintenir sur le long terme ou alors il faut consommer autant d'ipv4 que de v6 pour un serveur si on veut éviter la redirection de ports...
Donc dans les best practices quand je vois dual stack partout en étape, je dis non, c'est trop complexe de maintenir une qualité de service avec les mêmes configurations sur les deux couches.
Pour terminer enfin, je suis technique certes mais je suis aussi le patron, donc quand la technique voit des avantages, le patron est souvent d'accord :D même si ça mange du temps. C'est aussi cela qui aide à franchir le pas, là où un décideur verra l'argent perdu dans cette manipulation... Question de point de vue et de priorité.