Pour quelle raison celui qui signe les chèques en ferait un pour ça ?
Oui, tu pointes effectivement les bonnes raisons, et je sais bien que les coûts immédiats sont souvent énormes et dissuasifs. Les arguments que je présente sur « dé-complexifier » l'applicatif et la gestion réseau sont des arguments de long terme, et c'est très peu entendu dans ces structures intermédiaires.
Un autre problème qui vient avec l'IPv6 pour ces structures : ça les lie fortement à leur opérateur. Et souvent, elles aiment pas ça (et je les comprend).
Alors ça dépend de comment tu le fais : encore une fois, ça concerne l'applicatif, et c'est un chantier énorme. J'ai souvent recommandé de revenir à une gestion saine du DNS et augmenter son utilisation dans l'applicatif, car c'est le seul moyen de se défaire du couplage des applications avec les adresses : ce dont tu parles, c'est parce que tout le monde hardcode l'adressage et se lie à sa structure, ce qui amène des complications horribles en cas de renumérotation, effectivement. Et tous les devs et tous les frameworks aujourd'hui ont cette tare... alors qu'historiquement, l'utilisation des noms était beaucoup plus développée, et le NAT est venu casser cette dynamique car il rend compliqué l'utilisation des noms. C'est triste, mais c'est un combat nécessaire pour améliorer le réseau de manière générale.
Ensuite, tu peux également choisir de te préparer à l'utilisation d'adresses multiples, avec des préfixes d'origine différentes, ou alors d'adresses changeantes, afin de te défaire de cette dépendance. Ça doit être galère sans DNS, mais c'est une possibilité.
Le jour où tu veux changer d'opérateur, tu dois refaire tout ton plan d'adressage interne.
Alors, si tu ne te débrouilles pas trop mal, tu referas les configurations d'adressage de tes équipements, mais tu ne changeras pas la structure, vue que normalement ton nouvel opérateur t'offriras un préfixe assez grand pour faire un adressage similaire au précédent. Tu traduis juste le préfixe, quoi, même si je comprends la galère du changement de conf. Si tu décides de te baser sur les noms comme proposé plus haut, ça peut même être grandement simplifié. Et tu pourras même avoir de l'adressage multiple avec deux opérateurs upstream si tu le veux.
Et il ne faut pas croire que la transition d'opérateur est toujours rose même en IPv4 : tu as l'air de parler de professionnels maîtrisant bien leurs réseau, et j'ai déjà vu des transitions IPv4 où une partie de l'expertise est « avalée » par l'opérateur réseau pour différentes raisons (manque de compétences internes à l'entreprise, offre commerciales préférées par les dirigeants, etc) et les changements nécessaires aux équipements afin de gérer le ré-adressage sont substantielles !
À moins de n'utiliser que les adresses fd00:/8 en interne, mais du coup, ça supprime une partie des avantages de l'IPv6.
Ça dépend, tu peux aussi essayer de le faire « bien » : tu as en adressage pérenne en ULA (même pas forcément NATé upstream, uniquement pour la communication intra-entreprise), auquel tu peux ajouter des adresse de préfixes globaux de tes FAI pour les besoins d'accès (facile, laisse l'autoconf activée) ou de proposition de service (plus difficile mais réalisable). Comme d'habitude, il faut prendre le réflexe en IPv6 de penser que les technos peuvent s'ajouter, même si gérer la diversité augmenté bien sûr la complexité.
Avoir des ULA par défaut (non routées/NATées upstream) avec un ou des préfixes supplémentaires routés, c'est la configuration adoptée par défaut depuis quelques années par OpenWrt : tu vas me dire que ça n'est pas pour un contexte professionnel, mais je trouve que c'est une très bonne solution même dans ce contexte, qui peut satisfaire les exigences de stabilités comme celles d'atteignabilité globale. Encore une fois, bien sûr que ça amène un peu plus de complexité dans le réseau et la configuration des applications, mais en enlève aussi au niveau des NATs.
Bref, de mon point de vue, c'est surtout pour ces structures intermédiaires (mais nombreuses) que l'IPv6 représente un coût démesuré par rapport aux gains (à peu de choses près nuls)
Je pense que tu vises juste pour leurs appréhensions, mais je pense personnellement qu'il y a moyen de montrer que la réalité peut être plus simple en choisissant des stratégies de migration adaptées. Je suis par contre d'accord que ces stratégies que je propose ne sont pour l'instant pas souvent déployées, et très peu d'offres professionnelles sont proposées.
[^] # Re: Pour ce que ça change...
Posté par benoar . En réponse au journal Fini l'obligation de compatibilité IPv6 par la loi. Évalué à 3. Dernière modification le 13 février 2021 à 12:17.
Oui, tu pointes effectivement les bonnes raisons, et je sais bien que les coûts immédiats sont souvent énormes et dissuasifs. Les arguments que je présente sur « dé-complexifier » l'applicatif et la gestion réseau sont des arguments de long terme, et c'est très peu entendu dans ces structures intermédiaires.
Alors ça dépend de comment tu le fais : encore une fois, ça concerne l'applicatif, et c'est un chantier énorme. J'ai souvent recommandé de revenir à une gestion saine du DNS et augmenter son utilisation dans l'applicatif, car c'est le seul moyen de se défaire du couplage des applications avec les adresses : ce dont tu parles, c'est parce que tout le monde hardcode l'adressage et se lie à sa structure, ce qui amène des complications horribles en cas de renumérotation, effectivement. Et tous les devs et tous les frameworks aujourd'hui ont cette tare... alors qu'historiquement, l'utilisation des noms était beaucoup plus développée, et le NAT est venu casser cette dynamique car il rend compliqué l'utilisation des noms. C'est triste, mais c'est un combat nécessaire pour améliorer le réseau de manière générale.
Ensuite, tu peux également choisir de te préparer à l'utilisation d'adresses multiples, avec des préfixes d'origine différentes, ou alors d'adresses changeantes, afin de te défaire de cette dépendance. Ça doit être galère sans DNS, mais c'est une possibilité.
Alors, si tu ne te débrouilles pas trop mal, tu referas les configurations d'adressage de tes équipements, mais tu ne changeras pas la structure, vue que normalement ton nouvel opérateur t'offriras un préfixe assez grand pour faire un adressage similaire au précédent. Tu traduis juste le préfixe, quoi, même si je comprends la galère du changement de conf. Si tu décides de te baser sur les noms comme proposé plus haut, ça peut même être grandement simplifié. Et tu pourras même avoir de l'adressage multiple avec deux opérateurs upstream si tu le veux.
Et il ne faut pas croire que la transition d'opérateur est toujours rose même en IPv4 : tu as l'air de parler de professionnels maîtrisant bien leurs réseau, et j'ai déjà vu des transitions IPv4 où une partie de l'expertise est « avalée » par l'opérateur réseau pour différentes raisons (manque de compétences internes à l'entreprise, offre commerciales préférées par les dirigeants, etc) et les changements nécessaires aux équipements afin de gérer le ré-adressage sont substantielles !
Ça dépend, tu peux aussi essayer de le faire « bien » : tu as en adressage pérenne en ULA (même pas forcément NATé upstream, uniquement pour la communication intra-entreprise), auquel tu peux ajouter des adresse de préfixes globaux de tes FAI pour les besoins d'accès (facile, laisse l'autoconf activée) ou de proposition de service (plus difficile mais réalisable). Comme d'habitude, il faut prendre le réflexe en IPv6 de penser que les technos peuvent s'ajouter, même si gérer la diversité augmenté bien sûr la complexité.
Avoir des ULA par défaut (non routées/NATées upstream) avec un ou des préfixes supplémentaires routés, c'est la configuration adoptée par défaut depuis quelques années par OpenWrt : tu vas me dire que ça n'est pas pour un contexte professionnel, mais je trouve que c'est une très bonne solution même dans ce contexte, qui peut satisfaire les exigences de stabilités comme celles d'atteignabilité globale. Encore une fois, bien sûr que ça amène un peu plus de complexité dans le réseau et la configuration des applications, mais en enlève aussi au niveau des NATs.
Je pense que tu vises juste pour leurs appréhensions, mais je pense personnellement qu'il y a moyen de montrer que la réalité peut être plus simple en choisissant des stratégies de migration adaptées. Je suis par contre d'accord que ces stratégies que je propose ne sont pour l'instant pas souvent déployées, et très peu d'offres professionnelles sont proposées.