Je respecte l'engagement des bénévoles, et tout particulièrement en période de galère.
Lecteur passif depuis plus de deux décennies (mais pas 27ans), linuxfr est une des mes principales sources de veille sur le numérique libre. J'ai hésité à répondre au post de de > Psychofox. Finalement je me suis dit pourquoi pas échanger, après tout un forum est fait pour partager les points de vue.
Maladresse ? Pas le bon fil de discussion ? Pas le bon moment ("too soon") ? Pas le bon format ? Pas pertinent ? Ok je peux l'entendre. Je n'ai peut être pas tous les codes sociaux pour cette assemblée.
J'espère que les efforts seront rapidement couronnés de succès et que vous retrouverez une infra opérationnelle et l'exploitation à votre main qui vous convient.
Je retourne dans le confort de l'anonymat du lectorat passif et silencieux. Bonne et longue continuation. Mon intérêt pour le site demeure intacte.
A l'avenir, je sais que je n'hésiterai pas… à m'abstenir.
Le protocole IPv6 est un protocole du millénaire/siècle dernier (RFC2460 de 1998, auquel s'est substitué le RFC8200 de 2017). Cela fait bientôt 25 ans que "je "prêche dans le désert" en enseignant IP en "v6 only" sous le regard narquois de collègues qui me prennent au mieux pour un illuminé ; si ce n'est un "psycho rigide". Depuis les années 2010 je conclus le cours en indiquant/espérant que tout nouveau segment réseau (VLAN) devrait être en v6 (aller, soyons indulgent à minima dual stack v6/v4).
Dès le début des années 2000. Les bonnes pratiques recommandaient aux développeurs d'application des développer uniquement en AF-INET6 en intégrant la totalité de l'espace d'adressage V4 dans l'espace d'adressage v6 derrière le préfixe ::ffff:0:0/96 "IPv4-mapped IPv6 address" du RFC3493 (adresse de la forme ::ffff:a.b.c.d). De cette manière la couche applicative ne manipule que des adresses v6 (gestion dynamique des adresses, règles de sécurisation (filtrage) et d'autorisation dans un seul format).
Je n'ai jamais compris pourquoi les dev de Google, aux alentours de 2014 pour kubernetes, ont codé en dur dans l'applicatif la gestion dynamique de l'adressage et sa sécurisation sur le préfixe privatif RFC1918 10.0.0.0/8 et le localhost 127.0.0.1. Résultat la gestion réseau dans les clusters k8s est d'une complexité "de dingue". Et il a fallu attendre pratiquement 7 années (k8S 1.23 (~2021) et supérieurs) pour ajuster le code de l'usine à gaz réseau IPv4 et commencer à avoir des clusters qui "marchouillent" en IPv6. Alors qu'en AF-INET6 et l'intégration "mapped IPv4 IPv6 address", kube aurait fonctionné correctement en dual stack dès la version 1.0. K8S aurait pu jouer le rôle de "killer application", attendue/espérée depuis 1998 qui aurait accéléré l'adoption (à l'instar du web de Tim Berner Lee et du protocole HTTP qui en quelques années, à partir de 1994, a imposé TCP/IP et relégué aux oubliettes les protocoles dominants de l'époque : OSI, X25, Netware, Netbios,… Alors qu'à l'époque TCP/IP n'était qu'un protocole universitaire snobbé par l'OSI et l'UIT-T). Quant à l'autre dominant du cloud, à savoir, Docker il a fallu patienter jusqu'à la v27 pour qu'IPv6 soit "facilité" ("Docker supporte IPv6 depuis la version 1.5, avec une configuration simplifiée à partir de Docker Engine v27 où l'activation d'IPv6 est désormais automatique sans nécessiter de modifications du daemon, et Docker Desktop 4.42 offre une prise en charge native d'IPv6". Si j'en crois le résumé IA de Qwuant : à vérifier!).
Cette archi n'a pas était monté en 2025
Effectivement et comme je viens de l'indiquer dans le monde des pods/conteneurs, pour les adminsys, jusqu'à il y a peu IPv6 restait une "quête".
Loin de moi l'idée de critiquer avec des idées toutes faites et ce n'est pas pendant le "coup de feu" qu'il faut lancer des sujets qui pourraient rapidement devnenir "trollesque".
Aussi ce qui suit est juste pour alimenter la réflexion pour d’éventuelles futures évolutions.
"En 2025 on monte encore des archi en IPv4 only" ?
Les archi "cloudesques" contemporaines à base de pods/conteneurs sont majoritairement orientées services (ou micro-services) applicatifs web (API REST) ? En général, sur ce type d'archi on dispose d'un frontal (parfois dénommé ingress-controler/load-balancer/reverse-proxy) qui relaie (et contrôle au passage) sur les services applicatifs en arrière plan. L'interface(s) externe(s) de ce frontal est "l'unique" interface qui serait dual-stack :une (ou des) IPv6 GUA(aka publique(s) et une ou(des) interfaces IPv4 publiques.
En 2025, l'arrière plan devrait être IPv6 only. L'ensemble des pods/conteneurs de services ainsi que l'interface(s) interne(s) de l'ingress-controler devraient être "confinées" dans un domaine de diffusion (VLAN) dédié. Avec uniquement des adresses LLA "fe80::xxxx:xxxx:xxxx:xxxx/64" (confinées donc non routables, ne permettant que les com entre voisins directs). Une interface IPv6 dispose d'autant d'adresses que nécessaires. Il y a toujours une LLA par défaut à l'activation de l'interface, mais l'admin peut en ajouter à sa convenance, y compris une LLA avec un IID (Interface ID) stable, opaque (ne révèle pas d'info sensible matérielle de l'interface). La stabilité de ces adresses les rendent aptes à ếtre gérées par le système de nommage et/ou l'IPAM. Elles sont destinées au flux applicatifs entrant. Non routables ces addresses nécessitent d'être suffixées par l'interface qui la porte par le séparateur '%' suivi de l'interface ("fe80::xxxx:xxxx:xxxx:xxxx%ethn" par exemple). Pour les appels systèmes sous forme d'URI il faut l'encadrer par des '[' ']' (https://[fe80::xxxx:xxxx:xxxx%ethn]:4443 par exemple).
L'avantage du plan d'adressage LLA est d'être indépendant de l'infrastructure, il devrait donc pouvoir être "relocalisé" facilement en cas de besoin. Si le VLAN en arrière plan doit être étendu mutli-site, in maillage VXLAN chiffré devrait pouvoir faire l'affaire.
Alternativement, il est également possible de gérer "classiquement" le réseau en arrière plan avec un plan d'adressage IPv6 privatif bâti sur un préfixe ULA (/48).
Pour ceux que cela intéresse : info détaillées sur les séquences 1 et 4 du MOOC "Objectif IPv6" sur France Université Numérique (ressources en CC-BY-SA). La session 10 s'achève la semaine prochaine, la session 11 devrait débuter à l'automne.
[^] # Re: plan d'adressage IPv4 only (RFC1918)... en 2025 ?
Posté par jlandru . En réponse à la dépêche Incident du 26 juin 2025 ayant touché les serveurs de production et de développement. Évalué à 1 (+1/-0).
Je respecte l'engagement des bénévoles, et tout particulièrement en période de galère.
Lecteur passif depuis plus de deux décennies (mais pas 27ans), linuxfr est une des mes principales sources de veille sur le numérique libre. J'ai hésité à répondre au post de de > Psychofox. Finalement je me suis dit pourquoi pas échanger, après tout un forum est fait pour partager les points de vue.
Maladresse ? Pas le bon fil de discussion ? Pas le bon moment ("too soon") ? Pas le bon format ? Pas pertinent ? Ok je peux l'entendre. Je n'ai peut être pas tous les codes sociaux pour cette assemblée.
J'espère que les efforts seront rapidement couronnés de succès et que vous retrouverez une infra opérationnelle et l'exploitation à votre main qui vous convient.
Je retourne dans le confort de l'anonymat du lectorat passif et silencieux. Bonne et longue continuation. Mon intérêt pour le site demeure intacte.
A l'avenir, je sais que je n'hésiterai pas… à m'abstenir.
Salut!
[^] # Re: plan d'adressage IPv4 only (RFC1918)... en 2025 ?
Posté par jlandru . En réponse à la dépêche Incident du 26 juin 2025 ayant touché les serveurs de production et de développement. Évalué à 3 (+3/-0).
[^] # Re: plan d'adressage IPv4 only (RFC1918)... en 2025 ?
Posté par jlandru . En réponse à la dépêche Incident du 26 juin 2025 ayant touché les serveurs de production et de développement. Évalué à 1 (+3/-2).
Le protocole IPv6 est un protocole du
millénaire/siècle dernier (RFC2460 de 1998, auquel s'est substitué le RFC8200 de 2017). Cela fait bientôt 25 ans que "je "prêche dans le désert" en enseignant IP en "v6 only" sous le regard narquois de collègues qui me prennent au mieux pour un illuminé ; si ce n'est un "psycho rigide". Depuis les années 2010 je conclus le cours en indiquant/espérant que tout nouveau segment réseau (VLAN) devrait être en v6 (aller, soyons indulgent à minima dual stack v6/v4).Dès le début des années 2000. Les bonnes pratiques recommandaient aux développeurs d'application des développer uniquement en AF-INET6 en intégrant la totalité de l'espace d'adressage V4 dans l'espace d'adressage v6 derrière le préfixe ::ffff:0:0/96 "IPv4-mapped IPv6 address" du RFC3493 (adresse de la forme ::ffff:a.b.c.d). De cette manière la couche applicative ne manipule que des adresses v6 (gestion dynamique des adresses, règles de sécurisation (filtrage) et d'autorisation dans un seul format).
Je n'ai jamais compris pourquoi les dev de Google, aux alentours de 2014 pour kubernetes, ont codé en dur dans l'applicatif la gestion dynamique de l'adressage et sa sécurisation sur le préfixe privatif RFC1918 10.0.0.0/8 et le localhost 127.0.0.1. Résultat la gestion réseau dans les clusters k8s est d'une complexité "de dingue". Et il a fallu attendre pratiquement 7 années (k8S 1.23 (~2021) et supérieurs) pour ajuster le code de l'usine à gaz réseau IPv4 et commencer à avoir des clusters qui "marchouillent" en IPv6. Alors qu'en AF-INET6 et l'intégration "mapped IPv4 IPv6 address", kube aurait fonctionné correctement en dual stack dès la version 1.0. K8S aurait pu jouer le rôle de "killer application", attendue/espérée depuis 1998 qui aurait accéléré l'adoption (à l'instar du web de Tim Berner Lee et du protocole HTTP qui en quelques années, à partir de 1994, a imposé TCP/IP et relégué aux oubliettes les protocoles dominants de l'époque : OSI, X25, Netware, Netbios,… Alors qu'à l'époque TCP/IP n'était qu'un protocole universitaire snobbé par l'OSI et l'UIT-T). Quant à l'autre dominant du cloud, à savoir, Docker il a fallu patienter jusqu'à la v27 pour qu'IPv6 soit "facilité" ("Docker supporte IPv6 depuis la version 1.5, avec une configuration simplifiée à partir de Docker Engine v27 où l'activation d'IPv6 est désormais automatique sans nécessiter de modifications du daemon, et Docker Desktop 4.42 offre une prise en charge native d'IPv6". Si j'en crois le résumé IA de Qwuant : à vérifier!).
Effectivement et comme je viens de l'indiquer dans le monde des pods/conteneurs, pour les adminsys, jusqu'à il y a peu IPv6 restait une "quête".
J'entame ma 64ieme année et à l'automne ma dernière rentrée, avec la satisfaction de constater que le France se maintient sur l' "IPv6 world podium", et qu'on arrive "enfin" à un point de bascule quant au traffic global en IPv6 natif. A ce sujet, vous trouverez des info détaillées sur l'avancement du déploiement en France sur le baromètre IPv6 annuel de l'ARCEP.
Mais avec le conservatisme des plateformes majeures du cloud je doute de voir IPv4 devenir, sous peu, une "langue morte".
# plan d'adressage IPv4 only (RFC1918)... en 2025 ?
Posté par jlandru . En réponse à la dépêche Incident du 26 juin 2025 ayant touché les serveurs de production et de développement. Évalué à 4 (+5/-1).
Loin de moi l'idée de critiquer avec des idées toutes faites et ce n'est pas pendant le "coup de feu" qu'il faut lancer des sujets qui pourraient rapidement devnenir "trollesque".
Aussi ce qui suit est juste pour alimenter la réflexion pour d’éventuelles futures évolutions.
"En 2025 on monte encore des archi en IPv4 only" ?
Les archi "cloudesques" contemporaines à base de pods/conteneurs sont majoritairement orientées services (ou micro-services) applicatifs web (API REST) ? En général, sur ce type d'archi on dispose d'un frontal (parfois dénommé ingress-controler/load-balancer/reverse-proxy) qui relaie (et contrôle au passage) sur les services applicatifs en arrière plan. L'interface(s) externe(s) de ce frontal est "l'unique" interface qui serait dual-stack :une (ou des) IPv6 GUA(aka publique(s) et une ou(des) interfaces IPv4 publiques.
En 2025, l'arrière plan devrait être IPv6 only. L'ensemble des pods/conteneurs de services ainsi que l'interface(s) interne(s) de l'ingress-controler devraient être "confinées" dans un domaine de diffusion (VLAN) dédié. Avec uniquement des adresses LLA "fe80::xxxx:xxxx:xxxx:xxxx/64" (confinées donc non routables, ne permettant que les com entre voisins directs). Une interface IPv6 dispose d'autant d'adresses que nécessaires. Il y a toujours une LLA par défaut à l'activation de l'interface, mais l'admin peut en ajouter à sa convenance, y compris une LLA avec un IID (Interface ID) stable, opaque (ne révèle pas d'info sensible matérielle de l'interface). La stabilité de ces adresses les rendent aptes à ếtre gérées par le système de nommage et/ou l'IPAM. Elles sont destinées au flux applicatifs entrant. Non routables ces addresses nécessitent d'être suffixées par l'interface qui la porte par le séparateur '%' suivi de l'interface ("fe80::xxxx:xxxx:xxxx:xxxx%ethn" par exemple). Pour les appels systèmes sous forme d'URI il faut l'encadrer par des '[' ']' (https://[fe80::xxxx:xxxx:xxxx%ethn]:4443 par exemple).
L'avantage du plan d'adressage LLA est d'être indépendant de l'infrastructure, il devrait donc pouvoir être "relocalisé" facilement en cas de besoin. Si le VLAN en arrière plan doit être étendu mutli-site, in maillage VXLAN chiffré devrait pouvoir faire l'affaire.
Alternativement, il est également possible de gérer "classiquement" le réseau en arrière plan avec un plan d'adressage IPv6 privatif bâti sur un préfixe ULA (/48).
Pour ceux que cela intéresse : info détaillées sur les séquences 1 et 4 du MOOC "Objectif IPv6" sur France Université Numérique (ressources en CC-BY-SA). La session 10 s'achève la semaine prochaine, la session 11 devrait débuter à l'automne.