La Fibre
Télécom => Réseau => 
IPv6 => Discussion démarrée par: vivien le 14 novembre 2025 à 15:49:02
-
L’IPv6 forum appel à la migration vers IPv6 natif seul (sans IPv4)
Dans les grands pays, le taux de pénétration d'IPv6 dépasse les 51 % au sein des grandes entreprises et de certains réseaux gouvernementaux. Par conséquent, le moment est venu pour le Forum IPv6 d'appeler à une transition mondiale complète vers l'IPv6 pour tous les réseaux d'entreprises et gouvernementaux, et ce, pour plusieurs raisons. En effet, le déploiement d'une double pile (IPv4/NAT) n'est qu'une solution temporaire, engendrant des dépenses et un temps considérables. L'IPv6, quant à elle, représente la vision d'un Internet de production véritablement nouveau, capable de prendre en charge les nouvelles technologies telles que l'IA, la 6G, la blockchain, l'IoT P2P et tous les secteurs d'activité (chaînes d'approvisionnement, Internet industriel, etc.).
La transition vers le tout IPv6 est prise en charge par NAT64 et DNS64 : NAT64 (Network Address and Protocol Translation des clients IPv6 vers les serveurs IPv4) et DNS64 (extensions DNS pour NAT64) sont des mécanismes clés de transition IPv6 qui permettent aux clients IPv6 d’accéder aux ressources IPv4. Ils sont largement déployés dans les réseaux mobiles pour la connectivité IPv6 uniquement, souvent associés à 464XLAT pour une compatibilité applicative plus étendue.
Le document va donnes des exemples aux États-Unis, en Europe, en Chine, au Japon et en Arabie saoudite. En annexe, on retrouve la description du NAT64, DNS64 et 464XLAT.
(cliquez sur la miniature ci-dessous - le document est au format PDF)
(https://lafibre.info/images/ipv6/202511_ipv6_forum_appel_migration_vers_ipv6_only.avif) (https://lafibre.info/images/ipv6/202511_ipv6_forum_appel_migration_vers_ipv6_only.pdf)
-
Voici la traduction de ce qui est dit sur l'Europe :
L'adoption de NAT64 et DNS64 est généralisée au sein de l'Union européenne, sous l'effet conjugué d'une politique européenne, de l'évolution des réseaux mobiles et des stratégies cloud des entreprises. Cette approche est plus décentralisée qu'en Chine ou qu'aux États-Unis, où un mandat fédéral unique est en vigueur, mais elle n'en est pas moins profondément ancrée. Voici une analyse de l'utilisation au sein des entreprises et des institutions gouvernementales de l'UE. Entreprises de l'UE utilisant NAT64/DNS64
Voici une analyse de l'utilisation au sein des entreprises et des institutions gouvernementales de l'UE.
Entreprises de l'UE utilisant NAT64/DNS64
Les principaux opérateurs télécoms européens et les entreprises spécialisées dans le cloud sont les moteurs de cette tendance, à l'image de la tendance mondiale.
1. Deutsche Telekom (Allemagne), Orange (France), Telefónica (Espagne), Vodafone (Groupe, fortement présent en Europe) :
• Usage : Il s'agit du cas d'usage le plus important et le plus répandu. Les opérateurs de réseaux mobiles européens déploient massivement NAT64/DNS64 sur leurs réseaux 4G/5G.
• Raison : La motivation est la même que pour les opérateurs du monde entier : gérer efficacement la pénurie d'adresses IPv4 et simplifier l'architecture réseau. Ils attribuent par défaut des adresses IPv6 aux smartphones. Lorsqu'un utilisateur doit accéder à une application ou un site web compatible uniquement avec IPv4, le réseau de l'opérateur effectue la traduction de manière transparente grâce à NAT64/DNS64. Cette pratique est courante dans le secteur.
2. SAP (Allemagne) :
• Usage : Leader mondial des logiciels d'entreprise et des services cloud, SAP utilise très probablement NAT64/DNS64 au sein de ses propres centres de données et de son infrastructure cloud. Cela leur permet de créer de nouveaux environnements serveurs IPv6 évolutifs tout en maintenant la connectivité aux systèmes existants et à l'Internet IPv4.
• Preuve : SAP est un membre éminent du Conseil allemand IPv6 et promeut activement l'adoption d'IPv6, ce qui implique intrinsèquement la connaissance et l'utilisation des technologies de transition modernes.
3. Bosch (Allemagne) et Siemens (Allemagne) :
• Utilisation : Ces géants industriels sont des acteurs clés de l'Internet industriel des objets (IIoT) et de l'Industrie 4.0. Pour leurs déploiements IoT à grande échelle, l'utilisation de capteurs et d'appareils IPv6 est la seule solution évolutive à long terme. NAT64/DNS64 offre à ces appareils un accès contrôlé aux plateformes de gestion cloud, même si elles fonctionnent encore en IPv4.
4. Fournisseurs de cloud européens (par exemple, OVHcloud en France, T-Systems de Deutsche Telekom) :
• Utilisation : À l’instar de leurs homologues américains et chinois, ces fournisseurs proposent le service NAT64/DNS64 aux clients qui déploient des machines virtuelles et des conteneurs fonctionnant exclusivement en IPv6, leur permettant ainsi d’accéder à Internet via IPv4.
Utilisation par les administrations et le secteur public de l'UE
Le déploiement est piloté par un cadre politique européen descendant, bien que sa mise en œuvre varie selon les États membres.
1. La Commission européenne :
• Rôle : La Commission définit l'orientation stratégique. Sa « Stratégie européenne de déploiement d'IPv6 » et le règlement européen sur la cybersécurité encouragent, voire imposent, l'adoption d'IPv6 dans les administrations publiques et les infrastructures critiques des États membres.
• Directive : Sans imposer de technologie spécifique comme NAT64, la nécessité de se préparer à IPv6 et l'efficacité économique des réseaux exclusivement IPv6 font de NAT64/DNS64 un choix logique et recommandé.
2. Réseaux des administrations nationales (par exemple, Allemagne, France, Pays-Bas) :
• Utilisation : Les États membres technologiquement avancés intègrent activement IPv6 à leurs réseaux gouvernementaux. Par exemple :
• L'Office fédéral allemand de la sécurité des systèmes d'information (BSI) fournit des directives techniques détaillées pour le déploiement d'IPv6, incluant des spécifications pour les mécanismes de transition tels que NAT64.
• Les gouvernements néerlandais et français disposent de plans d'action publics pour IPv6 depuis plusieurs années.
• Mise en œuvre : À mesure que ces gouvernements modernisent leurs réseaux internes et leurs centres de données, ils construisent de plus en plus de nouveaux segments exclusivement IPv6 et utilisent NAT64/DNS64 pour la connectivité aux systèmes internes existants basés sur IPv4 et à l'Internet public IPv4. Il s'agit d'une stratégie courante pour réduire la complexité et les coûts.
3. Le réseau GÉANT (Réseau paneuropéen de données pour la recherche et l'éducation) :
• Qui : L'équivalent européen du réseau chinois CERNET2.
• Utilisation : GÉANT et ses réseaux nationaux de recherche et d'éducation (NREN) associés à travers l'Europe sont des leaders mondiaux du déploiement d'IPv6. Ils exploitent activement des réseaux pilotes et des bancs d'essai exclusivement IPv6 pour leurs utilisateurs (universités, instituts de recherche). Dans ces environnements, NAT64/DNS64 est un service essentiel qui permet aux chercheurs d'accéder à l'ensemble d'Internet.
4. ENISA (Agence de l'Union européenne pour la cybersécurité) :
• Rôle : ENISA promeut IPv6 comme un élément fondamental d'une infrastructure Internet pérenne et sécurisée. Leurs rapports et lignes directrices reconnaissent et décrivent le rôle des technologies de transition, justifiant ainsi leur utilisation dans les secteurs public et privé.
En conclusion, l’utilisation de NAT64 et DNS64 dans l’UE est mature et stratégique. Elle constitue l’épine dorsale de la connectivité Internet mobile moderne pour des centaines de millions d’utilisateurs et un élément clé pour la prochaine génération d’infrastructures numériques industrielles et gouvernementales, le tout soutenu par un cadre politique cohérent, bien que fédéré.
-
Le taux de pénétration IPv6 ne reflète malheureusement pas le niveau de dépendance à IPv4.
C'est bien d'avoir IPv6 de dispo mais si tu as ne serait-ce qu'un seul service IPv4 à utiliser il faut maintenir la double pile.
Et migrer 100% des services est encore bien plus lourd que de "juste" ajouter IPv6 en double pile.
Surtout que la stat est trompeuse puisqu'elle ne cible que les "grandes entreprises" et les gouvernements, pas les petites et les moyennes...
Je bosse dans l'info (en ESN) et le réseau de ma boîte est toujours 100% IPv4...
Bref, il y a encore du boulot ^^
-
Commencer par rendre les services de l'état en v6.
Avec une deadline comme la facturation électronique.
Genre les douanes ou les impôts pour que tous les services de compta soient obligés de parler en v6.
-
Bref, il y a encore du boulot ^^
Il reste beaucoup de travail pour pouvoir éteindre IPv4.
La transition vers le protocole IPv6 a débuté en 2003, malgré cela, en 2025, on en est toujours qu'à la phase de coexistence.
Pour le moment, on a fait le plus simple : mettre IPv6 sur le mobile et les box grand public. Les entreprises sont sur le chemin critique.
(https://lafibre.info/images/ipv6/202511_chronologie_des_protocoles_sur_internet.webp)
Les spécifications IPv6 ont été finalisées en 1998. Elles intègrent des fonctions pouvant renforcer la sécurité par défaut et optimiser le routage. Surtout, IPv6 offre une quasi-infinité d'adresses : 667 millions de milliards d'adresses IPv6 pour chaque millimètre carré de surface terrestre.
Du fait de la complexité actuelle d’internet, la migration d’IPv4 vers IPv6 ne peut être effectuée brutalement en un seul jour. Elle se réalise donc progressivement, en déployant IPv6 en parallèle d’IPv4 (phase de cohabitation). Une fois que tous les acteurs auront migré vers le nouveau protocole, IPv6 remplacera définitivement IPv4 (phase d’extinction d’IPv4).
La transition vers le protocole IPv6 a débuté en 2003. Malgré cela, en 2025, internet n'en est encore qu'à la phase de cohabitation. Les protocoles IPv4 et IPv6 vont coexister, tant qu'IPv6 n’a pas été généralisé au niveau de tous les maillons de la chaîne d’internet. Les réseaux des grandes entreprises sont sur le chemin critique.
-
Le taux de pénétration IPv6 ne reflète malheureusement pas le niveau de dépendance à IPv4.
C'est bien d'avoir IPv6 de dispo mais si tu as ne serait-ce qu'un seul service IPv4 à utiliser il faut maintenir la double pile.
Tu peux faire tout un réseau interne en IPv6 Only avec le DNS64 et NAT64, comme donné en exemple par les entreprises qui ont migré.
C'est un double pile à maintenir sur un périmètre très limité (en gros le service DNS64 et NAT 64 + les services accessibles en externe).
Tout ton réseau interne pourrait rester en IPv6 Only.
Je dis pas que c'est simple, la transistion IPv6 n'est pas simple en elle même, mais largement possible.
Après ce qui manque c'est clairement un intérêt financier à passer à ce modèle. Seules les entreprises d'IoT ou qui ont besoin de beaucoup d'adresses ont migrée en réalité (pour l'aspect financier).
Je encore beaucoup de mal à voir comment on va s'en sortir si il n'y a pas un vrai avantage financier à migrer en v6.
-
Tu peux faire tout un réseau interne en IPv6 Only avec le DNS64 et NAT64
J'aurais adoré mais coté IoT c'est pas vraiment gérable, beaucoup de trucs reposent encore sur une stack IPv4 en local
-
J'aurais adoré mais coté IoT c'est pas vraiment gérable, beaucoup de trucs reposent encore sur une stack IPv4 en local
Pareil.. j'ai essayé, un calvaire, je reste en dual stack pour le moment. Trop de produit IoT même du récent qui ne gère pas du tout ipv6...
-
Il reste beaucoup de travail pour pouvoir éteindre IPv4.
La transition vers le protocole IPv6 a débuté en 2003. Malgré cela, en 2025, internet n'en est encore qu'à la phase de cohabitation. Les protocoles IPv4 et IPv6 vont coexister, tant qu'IPv6 n’a pas été généralisé au niveau de tous les maillons de la chaîne d’internet. Les réseaux des grandes entreprises sont sur le chemin critique.
j' ai aperçu de l'ipv6 sur le réseau Renater 2 (liens ATM FT) aux environ de 2000, mais un peu avant 2003, c'était en phase pilote, il me semble, mais il y avait des adresses ipv6 sur les routeurs du réseau.
-
2003, c'est la date à laquelle IPv6 a commencé à se déployer sur internet.
Avant, c'était plus sur un réseau expérimental (entre réseau de recherche par exemple).
Mais oui, IPv6 a existé avant 2003. Le composant pour avoir IPv6 était d'ailleurs proposé sur le CD de Windows XP (sortie en octobre 2001). Pour Windows NT 3.5 et Windows 2000, il n'était pas sur le CD (composant sorti après) et devait être téléchargé. Windows 95 / 98 / Me n'ont jamais eu de possibilité d'avoir l'IPv6, c'est un point qui inquiétait pour la transition au début, car ce sont des systèmes d'exploitations populaires.
Document de juin 2002 de l'Arcep (enfin à l’époque c'était l'ART) :
(cliquez sur la miniature ci-dessous - le document est au format PDF)
(https://lafibre.info/images/ipv6/200206_idate_etude_ipv6.png) (https://lafibre.info/images/ipv6/200206_idate_etude_ipv6.pdf)
Ce document est vraiment amusant à lire... Le gros point noir pour la transition à l'époque, c'est Windows 95/98 :
Extrait :
Les ordinateurs s’appuyant sur les Windows 95 et Windows 98 (majorité du parc PC aujourd’hui installé) ne seront jamais compatibles IPv6.
(https://lafibre.info/images/ipv6/200206_idate_etude_ipv6_1.png)
-
J'aurais adoré mais coté IoT c'est pas vraiment gérable, beaucoup de trucs reposent encore sur une stack IPv4 en local
Je suis d'accord mais on est quand même à la marge. J'espère que c'est pas juste un réseau IoT qui empêche le passage en IPv6 only.
Tu peux passer 95% du réseau en IPv6 et garder quelques trucs legacy (comme l'IoT ou même d'autres trucs) en IPv4.
Ça reste plus simple que tout mettre en dual stack.
Ce qui est quand même prioritaire c'est d'être "IPv6 ready" avec le reste du monde. Avoir un accès internet avec de l'IPv6 et que les accès entrant acceptent de l'IPv6.
-
Il faudrait préciser :
- IPv6 sur le WAN + DS-LITE sur les morceaux qui restent désespérément en IPv4 (et perso je vois pas la mort de certain truc ipv4 avant 40 ans ...) + Dual Stack LAN
ou
- IPv6 Only dans le DUR, des deux cotés du routeur de bordure ???
Mon avis perso :
- Grand Public : IPv6 Only dans 10 ans.
- Entreprise (et Pro / PME ..) IPv6 + DS-LITE pour encore 30 ans. Le temps de remplacer les pilotes des gros monstres industriels + qq fournisseurs en Dual (ou tunnel IPv4 over IPv6)
LeVieux
-
Salut,
Je n'ai pas franchi le cap ipv6 only non plus dans mon home lan.
Vous souleviez le cas iot.
Mais comment gérez vous le routage inter-réseaux internes, notament dans un vpn ip type wireguard?
exemple, 2 box avec 2 réseaux ipv6 /64 publics ( délégation réseau ipv6 fournis par le FAI), disons ipv6-fai1-reseau1/64 et ipv6-fai2-reseau1/64
un lien vpn joignable en ipv6 entre les 2 réseaux, mais aujoud'hui mes clients vpn, n'ont qu'une ipv4 privée dans le vpn. Et donc pour router entre les 2 lans, c'est ipv4 only.
Comment faire pour que les 2 réseaux locaux se parlent en passant par le vpn ?
Quel type d'adresse ipv6 attribuer au client dans le vpn, un réseau publique ipv6-fai1-reseau2/64, une adresse ULA ?
Ensuite, vous routez ipv6-fai1-reseau1/64 et ipv6-fai2-reseau1/64 par le vpn ?
-
Je bosse dans l'info (en ESN) et le réseau de ma boîte est toujours 100% IPv4...
Bref, il y a encore du boulot ^^
J'ai encore beaucoup de mal à voir comment on va s'en sortir si il n'y a pas un vrai avantage financier à migrer en v6.
Entreprise (et Pro / PME ..) IPv6 + DS-LITE pour encore 30 ans. Le temps de remplacer les pilotes des gros monstres industriels + qq fournisseurs en Dual (ou tunnel IPv4 over IPv6)
Même si la migration sera lente et coûteuse, on peut espérer qu’elle n’entravera pas les innovations en IPv6 ni ne poussera à réintroduire des mécanismes IPv4 dépassés.
-
J'ai déployé l'IPv6 à mon ancien travail. À mon actuel, où je n'ai plus d'impulsion sur le réseau, c'est un FAI qui n'a même pas demandé un préfixe. En partant du principe que ce n'est pas le seul, nous ne sommes pas sortis de l'auberge.
-
Mais comment gérez vous le routage inter-réseaux internes, notament dans un vpn ip type wireguard?
exemple, 2 box avec 2 réseaux ipv6 /64 publics ( délégation réseau ipv6 fournis par le FAI), disons ipv6-fai1-reseau1/64 et ipv6-fai2-reseau1/64
un lien vpn joignable en ipv6 entre les 2 réseaux, mais aujoud'hui mes clients vpn, n'ont qu'une ipv4 privée dans le vpn. Et donc pour router entre les 2 lans, c'est ipv4 only.
Comment faire pour que les 2 réseaux locaux se parlent en passant par le vpn ?
Quel type d'adresse ipv6 attribuer au client dans le vpn, un réseau publique ipv6-fai1-reseau2/64, une adresse ULA ?
Ensuite, vous routez ipv6-fai1-reseau1/64 et ipv6-fai2-reseau1/64 par le vpn ?
Ce n'est pas différent d'en IPv4. Les préfixes globaux des 2 côtés restent utilisés pour le trafic hors VPN, routés comme ils le sont par le routeur. Pour joindre le 2e LAN :
- Tu dédies un /64 au service VPN de son routeur, ou tu en routes ou délègues un par DHCPv6 à la machine VPN si elle est séparée
- Tu configures sur le client le sous-réseau du LAN en face (ou ::/0 si tu veux faire passer tout le trafic) dans AllowedIPs
- Tu configures sur le client une adresse IPv6 du préfixe dédié
Tu peux certes aussi utiliser un préfixe ULA si c'est uniquement pour joindre les machines du LAN, ou faire du NAT pour Internet mais à ce moment, autant utiliser un préfixe GUA.
-
Salut,
Je n'ai pas franchi le cap ipv6 only non plus dans mon home lan.
Vous souleviez le cas iot.
Mais comment gérez vous le routage inter-réseaux internes, notament dans un vpn ip type wireguard?
exemple, 2 box avec 2 réseaux ipv6 /64 publics ( délégation réseau ipv6 fournis par le FAI), disons ipv6-fai1-reseau1/64 et ipv6-fai2-reseau1/64
un lien vpn joignable en ipv6 entre les 2 réseaux, mais aujoud'hui mes clients vpn, n'ont qu'une ipv4 privée dans le vpn. Et donc pour router entre les 2 lans, c'est ipv4 only.
Comment faire pour que les 2 réseaux locaux se parlent en passant par le vpn ?
Quel type d'adresse ipv6 attribuer au client dans le vpn, un réseau publique ipv6-fai1-reseau2/64, une adresse ULA ?
Ensuite, vous routez ipv6-fai1-reseau1/64 et ipv6-fai2-reseau1/64 par le vpn ?
Salut,
si ils ne vont pas sur internet, je mettrais des ULA qui servent à ça, mais si ils doivent aller sur internet, il faut une translation de préfixe .
-
A l'époque du tout cloud, il viendra peut etre un moment ou les offres des grands providers de ce type de solutions ( MS, AWS ..) seront plus cher en ipv4 only ou vraiment plus complexe à mettre en oeuvre donc plus cher sur le réseau entreprise. Cela ferait bouger les choses.
-
Ce n'est pas différent d'en IPv4. Les préfixes globaux des 2 côtés restent utilisés pour le trafic hors VPN, routés comme ils le sont par le routeur. Pour joindre le 2e LAN :
- Tu dédies un /64 au service VPN de son routeur, ou tu en routes ou délègues un par DHCPv6 à la machine VPN si elle est séparée
- Tu configures sur le client le sous-réseau du LAN en face (ou ::/0 si tu veux faire passer tout le trafic) dans AllowedIPs
- Tu configures sur le client une adresse IPv6 du préfixe dédié
Tu peux certes aussi utiliser un préfixe ULA si c'est uniquement pour joindre les machines du LAN, ou faire du NAT pour Internet mais à ce moment, autant utiliser un préfixe GUA.
salut,
faire du routage quand on n'a qu'un /64 côté FAI, c'est pas facile, ou alors du dhcpv6 ou des adresses statiques, on ne peut plus faire de SLAAC dans les sous réseaux.
-
Dans le contexte de dr191, rien ne dit qu'on ne dispose pas d'un préfixe plus grand des 2 côtés. Et si tu te réfères au tableau du baromètre IPv6, les FAI fixes français qui fournissent plus d'un /64 ne sont pas rares et sont même heureusement l'écrasante majorité.
-
Dans le contexte de dr191, rien ne dit qu'on ne dispose pas d'un préfixe plus grand des 2 côtés. Et si tu te réfères au tableau du baromètre IPv6, les FAI fixes français qui fournissent plus d'un /64 ne sont pas rares et sont même heureusement l'écrasante majorité.
Merci,
En effet, j'ai un des réseaux chez free, donc plusieurs /64.
Ca fait juste "bizarre" de mettre des ip publiques dans un réseau vpn. Les vieilles habitudes ont la vie dure.
-
Compréhensible, mais il faut se remémorer que les adresses IPv4 RFC1918 n'étaient même pas vouées à être utilisées couramment, et on aurait dû finir avec des adresses publiques partout à la base. Ce qui est mieux rendu possible en IPv6.
-
Oui, un effort important a été fait pour pouvoir partager les IPv4 et retarder l'échéance de la migration vers IPv6.
Certains étaient contre, afin de faire une transition rapide vers IPv6.
-
Salut,
Je n'ai pas franchi le cap ipv6 only non plus dans mon home lan.
Vous souleviez le cas iot.
Mais comment gérez vous le routage inter-réseaux internes, notament dans un vpn ip type wireguard?
exemple, 2 box avec 2 réseaux ipv6 /64 publics ( délégation réseau ipv6 fournis par le FAI), disons ipv6-fai1-reseau1/64 et ipv6-fai2-reseau1/64
un lien vpn joignable en ipv6 entre les 2 réseaux, mais aujoud'hui mes clients vpn, n'ont qu'une ipv4 privée dans le vpn. Et donc pour router entre les 2 lans, c'est ipv4 only.
Comment faire pour que les 2 réseaux locaux se parlent en passant par le vpn ?
Quel type d'adresse ipv6 attribuer au client dans le vpn, un réseau publique ipv6-fai1-reseau2/64, une adresse ULA ?
Ensuite, vous routez ipv6-fai1-reseau1/64 et ipv6-fai2-reseau1/64 par le vpn ?
On peut très bien garder de l'IPv4 pour du réseau privé dans un VPN sur IPv6. Sinon c'est ULA.
Quel besoin d'avoir de l'IPv6 pour le trafic dans le VPN?
Pour moi l'avenir c'est IPv6 comme transport 'public' globale bout en bout et IPv4 dans des overlays VPN (facon Tailscale par exemple). Avoir un telle séparation renforce la sécurité et evite les mauvaises configuration: IPv6 only pour l'acces public, IPv4 pour l'inter sites VPN, et IPv6 link-local pour le trafic LAN direct.
Autant a une époque je voyais tout en "IPv6 only", autant aujourd'hui je suis plus partisan d'une approche de ce style.
-
On peut très bien garder de l'IPv4 pour du réseau privé dans un VPN sur IPv6. Sinon c'est ULA.
Quel besoin d'avoir de l'IPv6 pour le trafic dans le VPN?
Pour moi l'avenir c'est IPv6 comme transport 'public' globale bout en bout et IPv4 dans des overlays VPN (facon Tailscale par exemple). Avoir un telle séparation renforce la sécurité et evite les mauvaises configuration: IPv6 only pour l'acces public, IPv4 pour l'inter sites VPN, et IPv6 link-local pour le trafic LAN direct.
Autant a une époque je voyais tout en "IPv6 only", autant aujourd'hui je suis plus partisan d'une approche de ce style.
hehe,
voire même juste un bridge L2 comme vpn :) en point à point ça doit se faire.
-
Autant a une époque je voyais tout en "IPv6 only", autant aujourd'hui je suis plus partisan d'une approche de ce style.
C'est navrant. Cela donne l'impression de faire du surplace. Le MOOC « Sécurité des Réseaux Informatiques (https://www.fun-mooc.fr/fr/cours/securite-des-reseaux-informatiques/) » fait référence aux VPN
mais les adresses IP des exemples apparaissent encore en version 4. L'IA aide parfois à s'y retrouver mais peut également induire en
erreur avec des biais (ainsi que « des hallucinations » assez fréquentes). De plus, la pile protocolaire IPv6 ou les pratiques continuent
d'évoluer (c.f. l'usage des adresses ULA).
-
@basilix
De ce que je vois dans les tendances lourdes coté Orange, on devrait glisser vers un IPv6 partout, mais avec du transport en Dual Stack partout pour les cas qui restent scotchés en IPv4.
Pour le GP, la vraie question va être celle de l'auto hébergement. Tant que l'on reste en IPv4 pour les connexions entrante pour le GP, cela aura beaucoup de mal à changer.
Là y'a deux grandes philosophie :
- on fait tout sortir vers des cloud pour les points de connexions (perso je n'aime pas, mais c'est de loin le plus simple)
- on a une vraie injonction de rendre cela "simple" des comités de normalisation divers et variés. Avec tout ce que cela signifie de DynDns IPv6, de Reverse, de TLS sur ce genre de chose et d'ouverture de FW plus où moins à la volé (là non plus pas très chaud ...)
Sinon, on aura une tendance à 5 ou 10 ans :
- WAN IPv6
- majorité des services en IPv6
- qq services en IPv4 plutôt entreprise
- LAN Dual Stack et protocole au choix (y'a plusieurs options) pour assurer le pontage vers les provider de service en IPv4.
- autohébergement en IPv6 qui restera du niveau des GeeK++
- sans parler des LAN IoT (matter et autres) que perso je mettrais bien totalement isolé du WAN si possible. Qu'ils soient en IPv4 ou IPv6.
LeVieux
-
On peut très bien garder de l'IPv4 pour du réseau privé dans un VPN sur IPv6. Sinon c'est ULA.
Quel besoin d'avoir de l'IPv6 pour le trafic dans le VPN?
Pour moi l'avenir c'est IPv6 comme transport 'public' globale bout en bout et IPv4 dans des overlays VPN (facon Tailscale par exemple). Avoir un telle séparation renforce la sécurité et evite les mauvaises configuration: IPv6 only pour l'acces public, IPv4 pour l'inter sites VPN, et IPv6 link-local pour le trafic LAN direct.
Autant a une époque je voyais tout en "IPv6 only", autant aujourd'hui je suis plus partisan d'une approche de ce style.
C'est intéressant comme approche mais pourquoi "IPv4 pour l'inter sites VPN" ?
Côté pro, nous avons entamé doucement notre migration vers du LAN en dual stack, même si l'absence d'IPv6 de notre FAI ne nous pousse pas vraiment à nous dépêcher. Personnellement, avec plusieurs sites et VLANs à gérer, je trouve quand même les ULA pour le trafic très très pratique sur le côté où je ne me retrouve jamais avec deux LAN qui se chevauchent, etc.
Mais bon j'ai quand même du mal à imaginer quant est-ce que je pourrai complètement couper mon IPv4 privée.
-
- autohébergement en IPv6 qui restera du niveau des GeeK++
Ce qui bloque l'auto-hébergement en IPv6 chez Orange, c'est que le firewall doit être reconfiguré à chaque changement de préfixe IPv6.
Cela serait bien de trouver une solution : préfixe IPv6 fixe ou firewall qui peut prendre en charge la migration des règles vers le nouveau préfixe automatiquement.
-
+1. Et c'est très dommage avec un /56. Surtout que le préfixe vendu comme stable ne l'est pas ou plus : il s'est mis à virevolter tous les 3 mois chez mes parents.
Je ne suis pas contre avoir mes connexions entrantes en IPv6 seulement, bien au contraire, ça simplifie les configurations. Et c'est le cas pour mes services dont je suis le seul utilisateur. Mais je ne peux pas envisager ça pour ce qui est public, je n'ai pas le contrôle sur la présence de l'IPv6 chez les visiteurs.
-
Comme l'a dit levieuxatorange, DynDNS v6 facilite grandement la vie à ce niveau.
J'ai qu'un seul domaine à retenir, et un sous-domaine en fonction du service, et basta.
Honnêtement, plus besoin d'IPv4, sachant qu'au boulot on est en v6, sur mon mobile, je suis en v6 aussi...
Les connexions en v4 c'est devenu anecdotique.
-
Comme l'a dit levieuxatorange, DynDNS v6 facilite grandement la vie à ce niveau.
J'ai qu'un seul domaine à retenir, et un sous-domaine en fonction du service, et basta.
Honnêtement, plus besoin d'IPv4, sachant qu'au boulot on est en v6, sur mon mobile, je suis en v6 aussi...
Les connexions en v4 c'est devenu anecdotique.
Et côté boulot, comment gérez-vous le fait d'avoir plusieurs liens WAN ? Vous diffusez tous les préfixes avec préférences, NTPv6 ?
-
C'est du PPPoE. Donc quand la session tombe en même temps que le lien ça réauthente sur l'autre et zou tout repart.
-
@levieuxatorange:
On peut potentiellement abaisser le niveau de compétences requis pour faire de l'auto-hébergement en IPv6.
De mon point de vue on pourrait se baser sur une solution ouverte du type OpenWrt et automatiser.
Remarque : Je prends OpenWrt comme référence car je le trouve assez classique. C'est un projet communautaire
basé sur GNU/Linux et on peut y contribuer lorsqu'on a acquis « les fondamentaux » et en mode Do It Yourself sans
forcément faire partie d'un groupe tout en tirant parti des efforts et avancées collectives.
Ce n'est pas sûrement pas à la portée de tous et cela prendrait un certain temps.
Il y a quelques années j'hébergeais mon blogue derrière une Livebox 2 sur un Raspberry Pi 2B en utilisant YunoHost
et en ayant des notions d'admin. système GNU/Linux (utilisateur averti) mais aucune en réseautique. J'ai abandonné
car je voulais plus de flexibilité et une meilleure compréhension de ce que je faisais.
Du moins c'est ce que je crois car je n'ai pas suffisamment de recul. Il faut que cela reste fiable et sécurisé. Dans mon
cas, cela frise l'expérimental (j'essaye d'intégrer des choses que je maîtrise plus ou moins pour passer au niveau suivant).
YunoHost, par celleux qui en ont l'usage ! - YunoHost - JdLL2025 (https://videos-libr.es/w/1hDvUjeS29ftQQX7bWGwVk?start=28m31s)
-
+1 : il est possible de faciliter l'auto-hébergement IPv6, avec des tutoriels, mais surtout une évolution du soft coté box.
Coté Orange, le firewall doit impérativement évoluer.
-
Ce qui bloque l'auto-hébergement en IPv6 chez Orange, c'est que le firewall doit être reconfiguré à chaque changement de préfixe IPv6.
Cela serait bien de trouver une solution : préfixe IPv6 fixe ou firewall qui peut prendre en charge la migration des règles vers le nouveau préfixe automatiquement.
Au fond, l' Arcep n'a pas le pouvoir de contrôler ces changements de préfixes client ? On ne peut pas imposer des préfixes fixes ou plus durables ?
Autant sur les ipv4, vu la rareté croissante, on pouvait comprendre de faire tourner au fur et à mesure des libérations, et encore, maintenant c'est compensé par les CGNat, d'ailleurs les ipv4 sont bien plus fixes.
-
Au fond, l' Arcep n'a pas le pouvoir de contrôler ces changements de préfixes client ? On ne peut pas imposer des préfixes fixes ou plus durables ?
Les opérateurs peuvent tout à fait proposer des préfixes qui changent à la fréquence de leur souhait. Il y a des règles en France, mais aussi une grande liberté.
Maintenant, pourquoi Orange fait ce changement de préfixe ? Pour répondre à une contrainte CNIL. Étonné, vu que les autres opérateurs n'ont pas cette pratique, j'ai contacté la CNIL sur ce sujet et la réponse est que la CNIL n’impose pas une telle obligation sur les adresses IP. J'en ai encore discuté récemment, la personne de la CNIL en question ayant rejoint l'Arcep.
Je sais qu'Orange perd des clients avec ce changement régulier d'IPv4 et IPv6, je pense que le sujet pourrait être ré-ouvert entre Orange et la CNIL.
=> IP fixe Orange et changement une fois par an minimum pour des questions CNIL (https://lafibre.info/orange-les-news/ip-fixe-orange-55180/)
-
Hello
Sujet complexe ici :
Orange choisi de changer les IP/prefix pour optimiser les écoulements réseau. C'est lié à notre architecture. Qui est quand même mesurée par l'ARCEP comme étant très bonne.
On perd effectivement une partie des clients GP à cause des changement d'IP/Préfix, mais on en gagne une autre grâce à la qualité de l'écoulement des flux.
Pour l'instant le sentiment est que la balance est positive entre les deux mouvements.
Avoir une injonction de fixer un préfix par ligne reviendrait à imposer d'une manière où une autre une architecture à l'ensemble des FAI.
Pas certain que cela soit dans le job de l'ARCOM...
Sans parler des question de remembrement du réseau qui seraient sérieusement figé...
Concernant le FW (IPv4 et IPv6), pour le GP, l'uPNP pour ouvrir les ports est considéré comme le plus adéquat.
En sécu, cela me froisse perso, mais pour le GP, le vrai (pas vous, si vous êtes ici, vous n'êtes pas du GP, mais de l'expert averti utilisant une ligne GP, totalement pas la même chose), c'est jugé comme le bon équilibrage fonctionnalité sécu.
Le changement à 300 jours obligatoire, c'est pour ne pas s'embêter avec la CNIL, mais le changement dès que le réseau le nécessite, celui là n'a rien à voir avec la CNIL :)
Aligner tout le monde sur un minima de 1 fois par an permet aussi le vidage lent des pool et rééquilibrage qand on prévoit ce genre de chose. En IPv6, on fait cela lentement, en IPv4, c'est genre dans la semaine ...
Bref :
- sujet complexe avec des choix de gestions et d'archi propres à chaque FAI.
- qui touche aussi aux processus
- et avec des impacts d'optimisation des flux et latences.
Perso je n'ai aucune idée de comment font les autres FAI pour l'équilibrage de flux à grande échelle.
Et pour les FW et la connectivité entrante .... vaste question. @vivien j'ai plein d'idée aussi, mais cela couvre les besoins de 1 à 5% de la population cible, donc complexe à faire prendre en compte dans les requirements du Mkt.
Sauf si cela se profil en généralisation ... Mais pour l'instant c'est pas flagrant.
Faudrait que l'on en parle Offline autour d'une biere d'expert à expert (et pas de ARCOM à ORANGE ...)
LeVieux
-
Concernant le FW (IPv4 et IPv6), pour le GP, l'uPNP pour ouvrir les ports est considéré comme le plus adéquat.
En sécu, cela me froisse perso, mais pour le GP, le vrai (pas vous, si vous êtes ici, vous n'êtes pas du GP, mais de l'expert averti utilisant une ligne GP, totalement pas la même chose)
Si la solution au changement de prefixe c'est l'UPNP, ça fait peur quand même.
J'ai pas de livebox en face de moi pour voir, mais si à chaque changement de prefixe il faut reconfigurer toutes les règles firewall pour y inclure le nouveau préfixe, c'est quand même un gros frein à l'auto-hébergement en IPv6.
Pour le DNS, le DynDNS pourrait être suffisant.
Donc je soutiens les remarques de Vivien et autres, le firewall de la livebox devrait pouvoir ouvrir des règles indépendamment du préfixe.
-
Par curiosité, j'aimerais bien comprendre quelle optimisation des flux impose une renumérotation périodique des clients, un changement d'architecture ça n'explique pas vraiment. j'imagine.
-
Un opérateur peut avoir besoin de déplacer les clients, pour de nombreuses raisons :
- POP avec trop de client, il est scindé en deux (donc la moitié est déplacé avec changement d'IP)
- en ADSL quand un réseau se vide pour éviter de garder des pools IP vides.
- changement des équipements qui portent les IP (ex: nouvelle génération)
- changement d'architecture (ex: quand Bouygues est passé du niveau 3 au niveau 2 sur les OLT / DSLAM)
- ...
C'est ce qui fait les IP changent typiquement tous les 10 ans avec Free, Bouygues ou SFR. C'est typique, on a des clients qui restent 15 ans avec la même IP et d'autres qui ont moins de chance, avec deux changements d'IP en 10 ans.
-
Si la solution au changement de prefixe c'est l'UPNP, ça fait peur quand même.
Par curiosité je viens de regarder sur ma LB courante (un LB4 sur la ligne où je suis) :
- l'ouverture en IPv6 peut se faire au port sans spécifier le HOST destination (genre IPV6any/IPv6any port 8443 ACCEPT
=> ce qui ouvrira le port 8443 sur l'ensemble des HOST IPv6 du LAN.
=> il faut que l'attaquant ait la cible directe pour trouver le bon host dans le /64 du LAN
=> en choisissant un port non standard on est à l'objectif de 'nouvrir que sur un host
- l'ouverture peut se faire en désignant le HOST "par son nom". La LB est supposé maintenir le lien entre le HOST et l'IPv6 utilisée
=> cela répondrait bien au besoin
=> j'ai jamais regardé comment la LB maintient ce lien ?
=> permet d'utiliser un port standard.
On peut donc faire autrement que avec l'uPNP pour les gens le désirant.
Je vais tester d'ailleurs pour voir ce que cela donne.
LeVieux
-
Le /64 du lan ...
et si l'adresse est dans l'autre (à priori, si ça n'a pas changé, la lbx ne peut en router qu'un autre, malgré un /56 fourni).
à vérifier, mais je pense qu'en ipv4 le lien entre nom et adresse est fait par le dhcp, je doute que ça fonctionne avec une adresse ipv4 en dur.
est ce que sur le second /64 en délégation, tout est bloqué aussi ?
-
Un opérateur peut avoir besoin de déplacer les clients, pour de nombreuses raisons :
- POP avec trop de client, il est scindé en deux (donc la moitié est déplacé avec changement d'IP)
- en ADSL quand un réseau se vide pour éviter de garder des pools IP vides.
- changement des équipements qui portent les IP (ex: nouvelle génération)
- changement d'architecture (ex: quand Bouygues est passé du niveau 3 au niveau 2 sur les OLT / DSLAM)
- ...
C'est ce qui fait les IP changent typiquement tous les 10 ans avec Free, Bouygues ou SFR. C'est typique, on a des clients qui restent 15 ans avec la même IP et d'autres qui ont moins de chance, avec deux changements d'IP en 10 ans.
je ne vois là dedans guère d'éléments qui justifient de renuméroter:
si on divise en deux matériellement, on qu'on rajoute du monde, c'est avec une nouvelle plage, mais ça ne change pas forcément les anciens, tant qu'on a de la réserve, mais bon en V6, ça va, changement des équipements, je ne vois pas pourquoi ça change le plan de numérotation de l'existant.
-
Maintenant, pourquoi Orange fait ce changement de préfixe ? Pour répondre à une contrainte CNIL. Étonné, vu que les autres opérateurs n'ont pas cette pratique, j'ai contacté la CNIL sur ce sujet et la réponse est que la CNIL n’impose pas une telle obligation sur les adresses IP. J'en ai encore discuté récemment, la personne de la CNIL en question ayant rejoint l'Arcep.
Je sais qu'Orange perd des clients avec ce changement régulier d'IPv4 et IPv6, je pense que le sujet pourrait être ré-ouvert entre Orange et la CNIL.
=> IP fixe Orange et changement une fois par an minimum pour des questions CNIL (https://lafibre.info/orange-les-news/ip-fixe-orange-55180/)
Y a ZERO contrainte CNIL sur la durée d'une allocation d'une IP ou d'un préfixe.
Vous pouvez me claquer la gueule anytime en me sortant noir sur blanc cette règle CNIL. Dans l'attente c'est une légende. Et ce que fait Orange de son stock d'IP le regarde.
-
Y a ZERO contrainte CNIL sur la durée d'une allocation d'une IP ou d'un préfixe.
Vous pouvez me claquer la gueule anytime en me sortant noir sur blanc cette règle CNIL. Dans l'attente c'est une légende. Et ce que fait Orange de son stock d'IP le regarde.
Il n'y a effectivement AUCUNE règle concernant une IP de plus d'un an.
Il y a plein de règles concernant la rétention des infos de connexions et logs sur une durée de plus de 1 an.
Et changer l'IP une fois par an est un moyen simple de répondre à la règle sur la durée de rétention des infos et logs.
On peut dire effectivement que Orange fait simple, mais dans tous le fatras des règles que Orange doit suivre, c'est une position comme une autre concernant le deuxième points.
Levieux
-
je ne vois là dedans guère d'éléments qui justifient de renuméroter:
si on divise en deux matériellement, on qu'on rajoute du monde, c'est avec une nouvelle plage, mais ça ne change pas forcément les anciens, tant qu'on a de la réserve, mais bon en V6, ça va, changement des équipements, je ne vois pas pourquoi ça change le plan de numérotation de l'existant.
Je donne des exemples :
1/ tu as un site qui grossi et qui a trop de clients.
Il faut savoir qu'il y a des contraintes ANSSI de sécurisation si un même site à plus de xxxxx clients. Il peut donc être avantageux de déplacer des boucles de collecte sur un nouveau site pour ne pas dépasser ce seuil qui génère des contraintes. Prenons l'est de la France, tu as des sites en région parisienne et Strasbourg, mais rien entre les deux : tu vas créer le POP de Reims et mettre toutes les boucles autour dessus : les clients vont changer d'IP et même la latence sera différente : Si tu étais sur Reims et sur le POP de Strasbourg, tu aurais une latence moindre en basculant sur le nouveau POP. Par contre, si tu es dans l'est de la Seine-et-Marne et que ta boucle passe sur Reims, la latence sera plus importante que l'ancien POP en Île-de-France.
La latence n'est souvent pas le critère le plus important pour l'opérateur qui fait en sorte que son réseau soit résilient : quel que soit l'endroit où une coupure fibre se produit, il doit être en mesure découler le trafic sans saturation via les autres liens. Cela peut nécessiter beaucoup de calculs pour fixer les métriques.
2/ Changement d'équipement
Le changement d'équipement peut nécessiter de changer les clients d'IP. Les nouveaux équipements étant généralement plus capacitaire et cela peut être plus simple pour un opérateur de lui mettre une nouvelle plage IP si c'est lui qui porte les IP. Oui, il serait peut-être possible de permettre aux clients de conserver leurs IP, mais c'est bien plus compliqué. C'est comme construire un pont au-dessus d'une route ou voie ferrée : on sait faire sans interrompre le trafic, mais c'est bien plus simple en coupant le trafic.
Bref, il y a plein de raisons qui font que quand le réseau évolue, l'IP peut changer. Maintenant, ce sont des cas rares. Prenons l'exemple de Free : Les clients ont changé de préfixe IPv6 quand ils sont passés sur la nouvelle architecture IPv6 only sur le réseau de collecte avec IPv4 mutualisée entre 4 clients.
Quand je vois que des DSLAM sont décommissionnés, je pense que les derniers clients sont migrés sur un autre DSLAM et donc changement d'IP.
C'est pour cela que les opérateurs ne s'engagent pas sur une IP fixe, mais que l'IP est mentionnée comme étant stable.
-
Avoir une injonction de fixer un préfix par ligne reviendrait à imposer d'une manière où une autre une architecture à l'ensemble des FAI.
Pas certain que cela soit dans le job de l'ARCOM...
Non, et c'est heureux.
C'est toujours stupéfiant, ce besoin de soviétisme, chez certains. Car bon, si ça ne convient pas, il y a de la concurrence disponible.
Au demeurant et plus généralement, pas de liberté = pas de développement d'Internet, pas de nouvelles technologies, on serait toujours en X25, etc.
-
- l'ouverture peut se faire en désignant le HOST "par son nom". La LB est supposé maintenir le lien entre le HOST et l'IPv6 utilisée
=> cela répondrait bien au besoin
=> j'ai jamais regardé comment la LB maintient ce lien ?
=> permet d'utiliser un port standard.
Ca semble répondre au besoin oui. Pas de livebox en ma possession pour voir ça.
-
Il n'y a effectivement AUCUNE règle concernant une IP de plus d'un an.
Il y a plein de règles concernant la rétention des infos de connexions et logs sur une durée de plus de 1 an.
Et changer l'IP une fois par an est un moyen simple de répondre à la règle sur la durée de rétention des infos et logs.
On peut dire effectivement que Orange fait simple, mais dans tous le fatras des règles que Orange doit suivre, c'est une position comme une autre concernant le deuxième points.
Levieux
Alors, là, je ne vois vraiment pas le rapport avec les logs de connexion pendant un an ni leur destruction au bout d'un an du moment que les logs sont horodatés.
-
Si tu gardes des usages sur chaque adresse IP, le fait de changer d'IP fait que tu ne relies plus les infos au même client.
Mais en étant tatillon, Orange garde la trace du couple utilisateur ⇿ IP donc il est probablement possible de réassigner des données à un utilisateur, même après son changement d'IP.
-
- l'ouverture peut se faire en désignant le HOST "par son nom". La LB est supposé maintenir le lien entre le HOST et l'IPv6 utilisée
=> cela répondrait bien au besoin
=> j'ai jamais regardé comment la LB maintient ce lien ?
=> permet d'utiliser un port standard.
Dans "Mes équipements connectés", la Livebox ne liste qu'une IPv6 (ça semble être l'IP temporaire, mais peut-être que ce n'est pas toujours le cas).
Dans la réponse DNS, elle liste les deux IPv6 (temporaire et stable), ce qui n'est d'ailleurs pas forcément une bonne idée.
Pour un usage d'hébergement, idéalement la règle de firewall devrait être sur l'IPv6 stable uniquement.
-
Il y a plein de règles concernant la rétention des infos de connexions et logs sur une durée de plus de 1 an.
Ce qui est demandé c'est expirer les backups et les journaux. Même si l'IP dure 10 ans c'est OK ... puisque tu as flingué les backups. Et c'est conforme.
Changer l'IP tous les ans et garder les backups 3 ans c'est pas bon.
Le un an max c'est lui qui l'impose, pas la CNIL, en même temps que l'obligation de faire le journal.
https://www.legifrance.gouv.fr/codes/article_lc/LEGIARTI000043887545
Après dans la pratique on a vu que la vidéo de Benalla du 1er mai n'était pas expirée au bout des 30 jours comme prévu... on espère les opérateurs plus performants que la pref de police de paris.
Si tu gardes des usages sur chaque adresse IP, le fait de changer d'IP fait que tu ne relies plus les infos au même client.
Bien sûr que si puisque tu as gardé les usages de l'ancienne et de la nouvelle IP. Sinon dans une requisition le juge va pas choper le bon pour le mettre en taule, et il a un an pour faire sa réquisition (ou la HADOPI krrkrrkrr). Au delà de un an les journaux et les backups sont détruits plus personne ne peut remonter les connexions faites à partir de cette IP. .
-
Tiens d'ailleurs,
quand il y a une demande d'identification sur adresse IPV6, la recherche se fait tout le préfixe ou sur l'adresse /128 indiquée par le plaignant uniquement ?
Le préfixe identifie un utilisateur, mais le /128 n'identifie personne en particulier, surtout qu'il change toutes les 24h pour le même utilisateur avec la privacy.
Bon après, le /128 donne le préfixe, forcément, j'ai rien dit :)
-
Tiens d'ailleurs,
quand il y a une demande d'identification sur adresse IPV6, la recherche se fait tout le préfixe ou sur l'adresse /128 indiquée par le plaignant uniquement ?
Le préfixe identifie un utilisateur, mais le /128 n'identifie personne en particulier, surtout qu'il change toutes les 24h pour le même utilisateur avec la privacy.
Bon après, le /128 donne le préfixe, forcément, j'ai rien dit :)
On identifie pas l'utilisateur mais le titulaire de la ligne :p Du coup dans la réponse : l'IPv6 appartient à un préfixe /64../56... délégué au titulaire XXX. Et si besoin entre telle et telle date.
Comme quand tu te fais flasher... on envoie la prune au proprio de la carte grise
-
pour l'hebergement la delegation de prefix semble être la solution la plus pereine (et la tendance par ailleurs vu qu'elle arrive sur Android). Apres tout ca serait bien d'utiliser le /56 et pas juste le 1er /64.
Le problème du moins chez Orange c'est qu'on a aucun façon simple d'ouvrir les flux vers un /64 délégué sans passer en mode personnalisé. et la encore y'a pas ouverture 'full' mais juste une liste préfinie de protocoles...
idéalement il faudrait juste pouvoir specifier des délégations réservées (via DUID ou @MAC) et une option pour ouvrir ou pas le firewall pour une délégation réservée.
(https://i.imgur.com/5Du0RLb.png)
si une machine fait une demande DHCPv6-PD avec cette @MAC elle recevra le prefix d'index 1 (2a01:xxxx:xxxx:9001::/64 dans ce cas) et le parefeu laisse tout passé pour ce préfix.
C'est completement dynamique, si le préfix global du client change, le préfix délégué aussi mais c'est toujours le meme prefix index (1 ici).
Ca ne me semble pas compliqué à mettre en oeuvre mais sans doute pas concevable pour ceux qui décident chez Orange donc on continuera a remplacer nos livebox...
-
J'avais essayé ça aussi il y a quelques années sur une LB4, mais elle ne déléguait qu'un seul /64, et de taille /64 bien sûr, si bien (mal plutôt) que ça ne permet qu'un seul réseau en plus derrière, il faudrait pouvoir déléguer un /62 au moins. Je me demandais si ça avait été amélioré, par contre, je ne me souviens pas avoir vu ce paramètre firewall=non, c'était un peu le même bazar sur une box 7 SFR, il fallait jouer avec un espèce de DMZ et mettre le préfixe dedans, Bouygues je ne sais pas, Freebox on peut déléguer 7 x /64 en plus et pas de parefeu du tout.
-
c'est un mockup que j'ai fait pas l'interface réelle...
en l'état la livebox peut déléguer plusieurs /64 mais pas un /63 ou plus grand.
-
Ca ne me semble pas compliqué à mettre en oeuvre mais sans doute pas concevable pour ceux qui décident chez Orange donc on continuera a remplacer nos livebox...
C'est un problème de volume de ceux qui demandent ... On se bat aussi en interne pour remonter vos demandes et faire entrer cela dans le train ... Mais on est quoi 15 000 à demander ce genre de trucs ? sur 12 Millions de client Orange ...
On a fait passer la Préfix Delegation en /64 sur le profil GP car il était dispo dans le profil PRO ... On a pas réussi sur un masque plus gros, on demandait de pouvoir déléguer un /62, potentiellement /61 (8 */64 dans le /56 dispo à la boxe)
On espère que le PRO auront le besoin et que cela sera fait ..
Avec une règle de FW complémentaire qui est : tout est ouvert sur les Préfix Délégué, charge au routeur / FW suivant de gérer le truc
Et c'est pour cela que l'on a décidé de vous supporter (même si de manière limité), vous qui remplacez la boxe par un routeur totalement à votre main.
LeVieux
-
Ce qui serait intéressant dans la possibilité de déléguer le plus grand masque existant (un /57 en aval), est qu'en supposant qu'on puisse se contenter de 128 sous-réseaux (tout le grand public), c'est tout de suite beaucoup moins handicapant de laisser la Livebox dans réseau tout en utilisant son propre routeur.
Le problème actuel de laisser le routeur opérateur en place est le double NAT en IPv4, mais le besoin de la connectivité IPv4 se fait de moins en moins sentir. Je ne sais pas quand on peut s'attendre à ce que l'IPv6 soit largement déployée sur les réseaux d'accès au point que l'IPv4 reste là pour faire joli, mais à ce point de bascule, ça + une délégation du plus gros préfixe possible permettra l'absence enfin totale de compromis pour auto-héberger.
-
Supporter les alternatives est déjà une avancée. Des solutions techniques existent ou sont en voie de développement.
Mais c'est un sujet épineux (ou complexe).
-
Certains pare-feux de routeurs supportent les préfixes dynamiques des FAIs. Mais les diverses solutions ont leurs avantages et inconvénients.
OpenWrt permet de le faire facilement. Mais la documentation n'est pas adaptée au néophyte.
Add a VLAN to OPNsense in Just 26 Clicks Across 6 Screens (https://mtlynch.io/notes/opnsense-clicks)
-
Le problème actuel de laisser le routeur opérateur en place est le double NAT en IPv4, mais le besoin de la connectivité IPv4 se fait de moins en moins sentir. Je ne sais pas quand on peut s'attendre à ce que l'IPv6 soit largement déployée sur les réseaux d'accès au point que l'IPv4 reste là pour faire joli, mais à ce point de bascule, ça + une délégation du plus gros préfixe possible permettra l'absence enfin totale de compromis pour auto-héberger.
Coté Orange, on fait du DS-LITE (cela va sortir bientot)
Y'aurait possibilité de faire le DS-LITE depuis le routeur interne (celui qui gère les préfixes délégués) directement, donc sans double NAT.
Et donc en gérant le plan d'IPv4 que vous voulez derrière votre routeur
Je vous en parlerai quand cela sera possible. Et que l'on aura décider de vous l'ouvrir, que l'on aura fait une maquette pour documenter ... (en documentant ce qui est nécessaire)
LeVieux
-
Coté Orange, on fait du DS-LITE (cela va sortir bientot)
Y'aurait possibilité de faire le DS-LITE depuis le routeur interne (celui qui gère les préfixes délégués) directement, donc sans double NAT.
Et donc en gérant le plan d'IPv4 que vous voulez derrière votre routeur
Je vous en parlerai quand cela sera possible. Et que l'on aura décider de vous l'ouvrir, que l'on aura fait une maquette pour documenter ... (en documentant ce qui est nécessaire)
LeVieux
Cela pourra être intéréssant, surtout pour les nombreux utilisateurs de matériel Ubiquiti qui vient de rendre DS-LITE disponible sur les gateways.
-
Honnêtement, tant qu’il n’y a pas un vrai moteur économique derrière, on restera coincés en coexistence. Le modèle “IPv6 only + NAT64/DNS64” fonctionne très bien techniquement, mais sans contrainte financière ou réglementaire, les entreprises n’auront aucune raison d’accélérer.
-
@Janarita
Qui a envie de rester dans le modèle IPv4 ?
On sait depuis les années 1990 que ce protocole ne passe pas à l’échelle, et dans une société toujours plus numérique, ce sera encore plus problématique.
Il faudra agir et réparer en profondeur, plutôt que de bricoler avec deux ou trois bouts de ficelle. Si au moins on pouvait adopter une posture claire au lieu de
prolonger l’impasse d’IPv4 afin de ne pas passer à côté des enjeux. Si l'on pouvait réduire les spéculations sur les usages et passer au concret.
-
IPV4, CU, 3G, ça en fait des trucs à démonter ...
-
Coté Orange, on fait du DS-LITE (cela va sortir bientot)
Y'aurait possibilité de faire le DS-LITE depuis le routeur interne (celui qui gère les préfixes délégués) directement, donc sans double NAT.
Et donc en gérant le plan d'IPv4 que vous voulez derrière votre routeur
Je vous en parlerai quand cela sera possible. Et que l'on aura décider de vous l'ouvrir, que l'on aura fait une maquette pour documenter ... (en documentant ce qui est nécessaire)
LeVieux
Salut, ça sera en 2025 ?
-
C'est déjà presque terminé 2025.
Il y a un gel en fin d'année, donc non, ce n'est pas possible.
La question est plus de savoir si c'est 2026 ou 2027.
-
Salut, ça sera en 2025 ?
Techniquement oui.
Reste les phases de FUT pour bien valider le fonctionnement transparent pour les Utilisateurs cibles avant mise en place.
Donc probablement début 2026 pour l'ouverture plus large.
Et je rappelle ce que j'ai dit ailleurs : pour ceux qui ont des routeurs à la place des boxe : AUCUN changement.
Je ferais les specs (enfin je vous ferais une version synthétique minimale des specs) pour ceux qui voudront se lancer avec nous.
LeVieux
-
Il me semble que seules les LB4 / LB5 ont l'onglet CGN.
Donc j'en déduis que les modèles plus récents ne sont pas encore prêts, et que soit il faudra une mise à jour avant le début du déploiement côté réseau, soit seules certaines Livebox seront concernées au début.
-
Coté Orange, on fait du DS-LITE (cela va sortir bientot)
Y'aurait possibilité de faire le DS-LITE depuis le routeur interne (celui qui gère les préfixes délégués) directement, donc sans double NAT.
Et donc en gérant le plan d'IPv4 que vous voulez derrière votre routeur
Je vous en parlerai quand cela sera possible. Et que l'on aura décider de vous l'ouvrir, que l'on aura fait une maquette pour documenter ... (en documentant ce qui est nécessaire)
LeVieux
J'ai essayé de me renseigner un peu sur ce DS-LITE. Mais si je comprends bien, il n'y a plus d'IP publiqué IPv4 côté user ?
Ca voudrait dire qu'il n'est plus vraiment possible d'héberger des services en IPv4.
Ou alors j'ai mal compris ?
Comment ça va être gérer niveau transition chez Orange ? Je suppose que la plupart des personnes ne redirigent rien en interne, mais pour des personnes auto-hébergeant des petits serveurs ça ne fonctionnera plus ? Il y aura peut être un sorte de opt-out ?
-
Il y a déjà une option dans les Livebox pour désactiver le DS-LITE, avant même qu'il ne soit déployé, ça a fait l'objet de plusieurs sujets sur le forum. En DS-LITE, il n'y a plus d'IPv4 publique mais (je crois) une IP dans 192.0.2.0/24, vers laquelle la Livebox fait du NAT et qui est une extrémité du tunnel v4. L'autre est terminée par l'AFTR chez l'opérateur, et ça forme le tunnel IPv4 dans IPv6.
La redirection de port reste possible, comme chez Bouygues où tu as une plage de 8192 ports, mais ça dépend de l'implémentation de l'opérateur et la plage qui t'est attribuée est évidemment aléatoire et peut ne pas correspondre avec ce que tu veux rediriger.
-
L'intérêt du DS LITE c'est de pas avoir l'IPv4 dans l'accès (encore une fois, si j'ai bien compris).
Si au final c'est une option désactivable ça veut dire qu'Orange va devoir garder le dual stack partout, donc je comprends pas trop l'intérêt ?
-
Ce sera désactivé par une petite partie des utilisateurs. Il faut garder à l'esprit que des millions comme ma mère n'ont même jamais dû ouvrir l'interface de la box. Et il faudra bien conserver de l'IPv4 dans le cœur de réseau tant qu'il reste des ressources en IPv4.
-
Cela va permettre d'économiser des millions d'IPv4.
Je rappelle que depuis 2019 le RIPE n'alloue plus de nouveaux blocs IPv4 (sauf des blocs de 1024 IP pour de nouvelles entités).
Orange a des IPv4 d'avances, mais à un moment, il faut faire de la place pour les nouveaux besoins.
(https://lafibre.info/images/ipv6/202507_arcep_barometre_ipv6_2025_01_historique_epuisement_ipv4.webp)
-
C'est plus clair merci :)
-
L'inconvénient du DS-Lite est que le réseau local reste en double pile. Avec NAT64 + DNS64 on repousse IPv4 en bordure de réseau.
Cela ne résout pas le problème d'allocation des IPv4 puisque le routeur reste en double pile. Mais on peut mieux se situer dans sa
transition vers IPv6.
-
Cela va permettre d'économiser des millions d'IPv4.
Je rappelle que depuis 2019 le RIPE n'alloue plus de nouveaux blocs IPv4 (sauf des blocs de 1024 IP pour de nouvelles entités).
Orange a des IPv4 d'avances, mais à un moment, il faut faire de la place pour les nouveaux besoins.
J'entends souvent qu'il reste un bon paquet d'adresses ipv4 à Orange par rapport à d'autres, ce stock inutilisé a une bonne valeur marchande spéculative dans les circonstances actuelles.
Si l'usage se perd globalement, il faudra des gens qui continuent à se développer en ipv4 sous peine de faire perdre toute valeur à ce stock, c'est vrai qu'on en est encore loin, mais ça peut aider à comprendre que Orange ne se précipite pas à favoriser la migration de ses clients.
-
L'inconvénient du DS-Lite est que le réseau local reste en double pile. Avec NAT64 + DNS64 on repousse IPv4 en bordure de réseau.
Cela ne résout pas le problème d'allocation des IPv4 puisque le routeur reste en double pile. Mais on peut mieux se situer dans sa
transition vers IPv6.
Pour ne pas avoir de régression, le 464XLAT est nécessaire, car sinon, il y a des cas où cela ne fonctionne pas. En effet, certains terminaux ont des IPv4 codées en dur ou pir, utilisent un DNS codé en dur, qui n'est pas un DNS64 et qui est joignable en IPv4.
La mise en ouvre du 464XLAT n'est pas si simple hors du cas du mobile.
Il me semble que Microsoft limite son utilisation dans Windows à l'usage des connexions mobile (quand le PC a une connectivité 4G/5G) et que Microsoft ne permet pas son usage pour une entreprise qui souhaiterait virer IPv4 de son réseau local.
-
L'inconvénient du DS-Lite est que le réseau local reste en double pile. Avec NAT64 + DNS64 on repousse IPv4 en bordure de réseau.
Cela ne résout pas le problème d'allocation des IPv4 puisque le routeur reste en double pile. Mais on peut mieux se situer dans sa
transition vers IPv6.
Le routeur est double pile uniquement sur le LAN, avec une @IP RFC1918.
Et j'ai des trucs sur mon LAN perso qui sont et resteront en IPv4 only (en tout cas avant de trouver le chemin vers la benne)
LeVieux
-
Il me semble que Microsoft limite son utilisation dans Windows à l'usage des connexions mobile (quand le PC a une connectivité 4G/5G) et que Microsoft ne permet pas son usage pour une entreprise qui souhaiterait virer IPv4 de son réseau local.
Je confirme, mais ils ont annoncés travailler dessus et c'est pour "bientôt". Quand cela sera le cas, je me pencherais sur enfin passer mon lan ipv6 only (avec un dns64 et nat64 de dispo "si besoin"). Pour le moment, rester en dual-stack est bien plus simple et permet de bénéficier des deux mondes sans ce prendre top la tête niveau configuration additionnel.
-
J'entends souvent qu'il reste un bon paquet d'adresses ipv4 à Orange par rapport à d'autres, ce stock inutilisé a une bonne valeur marchande spéculative dans les circonstances actuelles.
Si l'usage se perd globalement, il faudra des gens qui continuent à se développer en ipv4 sous peine de faire perdre toute valeur à ce stock, c'est vrai qu'on en est encore loin, mais ça peut aider à comprendre que Orange ne se précipite pas à favoriser la migration de ses clients.
Hello
Moi qui suis pas loin des gens gérant tout cela, je te le dis : c'est une légende urbaine ...
Cela a été vrai y'a 10 ans (quand l'IPv4 valait rien d'ailleurs au 2nd marché ..) mais plus maintenant ....
LeVieux
-
Il y a quand même un petit stock d'IPV4 attaché au DSL qui devrait bientôt se libérer :D
-
Il y a quand même un petit stock d'IPV4 attaché au DSL qui devrait bientôt se libérer :D
On le bascule en FTTH au fur et à mesure ....
Plus ceux qui sont en RTC Only et qui vont passer en VoIPOnly sur FTTH.
Entre 500K et 3 Millions en plus ....
Et là ...... oups
-
Du coup même avec du DS LITE il faut continuer à implémenter du Dual Stack jusqu'à l'utilisateur dans le cas où il cocherait l'option enlevant le DS LITE (l'exemple du l'autohébergement en IPv4) ?
Donc Orange doit continuer à fournir du Dual Stack un peu partout ?
L'intérêt est surtout de ne pas pousser une ipv4 publique à tous les user, j'ai bon ?
-
On le bascule en FTTH au fur et à mesure ....
Plus ceux qui sont en RTC Only et qui vont passer en VoIPOnly sur FTTH.
Entre 500K et 3 Millions en plus ....
Et là ...... oups
Pour les abonnés en VoIPOnly, il n'y a à priori pas de raison de faire autre chose que du full V6.
-
Du coup même avec du DS LITE il faut implémenté du Dual Stack jusqu'à l'utilisateur dans le cas où il cocherait l'option enlevant le DS LITE (l'exemple du l'autohébergement en IPv4) ?
Donc Orange doit continuer à fournir du Dual Stack un peu partout ?
On détecte normalement (il peut y avoir des ratés...) et on sort ceux qui sont en auto hébergement du scope CGN DS-LITE.
Il resteront en DualStack IPv4 dédiées.
Le scope de population qui ne fait pas d'autohébergement est suffisant pour démarrer assez largement et par les cas simples.
Et avec les bascules des autohébergeur en IPv6, on devrait pouvoir faire évoluer cela dans le temps (long, le temps)
L'intérêt est surtout de ne pas pousser une ipv4 publique à tous les user, j'ai bon ?
Pouvoir le faire partout, mais pas le pousser à tous, oui c'est bien l'idée.
LeVieux
-
Pour les abonnés en VoIPOnly, il n'y a à priori pas de raison de faire autre chose que du full V6.
Exacte, sauf si le matos télémédical (pour les ainés par exemple) apparait sur le LAN et qu'il n'est pas IPv6
On doit donc pouvoir faire les deux. D'où le DS-LITE et le CGN
LeVieux
-
les entreprises qui avaient un vrai besoin d’IPv6 l’ont déjà fait et investi, le reste n’a pas vraiment d’urgence à basculer leur IPv4
-
On détecte normalement (il peut y avoir des ratés...) et on sort ceux qui sont en auto hébergement du scope CGN DS-LITE.
Il resteront en DualStack IPv4 dédiées.
Cette détection ne serait pas basée par hasard sur les clients qui ont un équipement en DMZ ?
-
Pour ne pas avoir de régression, le 464XLAT est nécessaire, car sinon, il y a des cas où cela ne fonctionne pas. En effet, certains terminaux ont des IPv4 codées en dur ou pir, utilisent un DNS codé en dur, qui n'est pas un DNS64 et qui est joignable en IPv4.
La mise en ouvre du 464XLAT n'est pas si simple hors du cas du mobile.
Il me semble que Microsoft limite son utilisation dans Windows à l'usage des connexions mobile (quand le PC a une connectivité 4G/5G) et que Microsoft ne permet pas son usage pour une entreprise qui souhaiterait virer IPv4 de son réseau local.
Microsoft va inclure le CLAT (https://techcommunity.microsoft.com/blog/networkingblog/windows-clat-enters-private-preview-a-milestone-for-ipv6-adoption/4459534) dans Windows 11.
Cela devient technique sur GNU/Linux. Voir Jool CLAT (https://www.jool.mx/en/464xlat.html).
-
Je pense qu'on peut faire les choses simplement.
Le routeur intègre le CLAT (e.g. Jool) et le DNS64 (e.g. unbound). On crée plusieurs sous-réseaux. On installe le PLAT (NAT64, e.g. Jool) sur une station (e.g. nano-ordinateur).
Certains réseaux sont en IPv6 (voire en double pile) et d'autres sont en IPv4 (îlots isolés). Mais le plus simple est d'installer le CLAT sur chaque station du réseau IPv6.
Et j'ai des trucs sur mon LAN perso qui sont et resteront en IPv4 only (en tout cas avant de trouver le chemin vers la benne).
Si ces machines ont besoin d'un accès Internet...
À voire si cela pourrait fonctionner dans l'attente du support CLAT de Microsoft dans Windows 11. C'est une bêtise (il faut de l'IPv4 sur le réseau donc autant utiliser IPv4 + IPv6).
Après réflexion, c'est inutile (double NAT alors que le routeur est en double pile sur l'interface WAN). Cela n'est valable que si le PLAT se trouvait dans le réseau du FAI.
-
Bonjour,
De mon côté, ma transition vers full IPv6 est très lente.
Sur mes 4 lignes internet, en comptant les box/modems, seule la moitié est IPv6.. dont aucune pour mes usages PC par internet mobile (panne longe du fixe ou plus de fixe).
Mais en cas de nécessité absolue (comme une planification à la chinoise de la fin de l'IPv4), alors avec un peu d'investissement de ma part je pourrai basculer rapidement en full IPv6.
Je joins ma situation à ce sujet, qui n'a pas fondamentalement évolué depuis la date indiquée.