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é.


Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Liste de diffusion du FRsAG
http://www.frsag.org/

Répondre à