IPv6 en France : la situation s’améliore… mais « la transition est encore loin d’être suffisante »

IPv6 en France : la situation s’améliore… mais « la transition est encore loin d’être suffisante »

Alors qu’IPv6 a déjà 23 ans !

Avatar de l'auteur
Sébastien Gavois

Publié dans

Internet

30/11/2021 14 minutes
74

IPv6 en France : la situation s’améliore… mais « la transition est encore loin d’être suffisante »

Si vous avez envie de profiter d’IPv6 sur votre accès Internet fixe, il faut privilégier Free ou Orange ; à contrario Bouygues Telecom est largement en tête sur le mobile. C’est une condition nécessaire, mais pas suffisante. Comme le rappelle l’Arcep, bon nombre d’autres maillons de la chaine trainent des pieds.

Le régulateur des télécoms vient de mettre en ligne son baromètre annuel sur l’adoption d’IPv6. Cette norme n’a rien de nouveau puisque, pour rappel, elle a été finalisée en 1998 : « La transition vers le protocole IPv6 a démarré en 2003. Cependant, en 2021, Internet n’en est encore qu’à la phase de cohabitation. 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 ».

En Europe, la pénurie a déjà deux ans

Or, comme nous l’avons déjà expliqué à maintes reprises, le marché fait face à une pénurie d’adresses IPv4 depuis maintenant deux ans ; le RIPE NCC (le registre régional d'adresses IP qui alloue les IPv4 pour l'Europe et le Moyen-Orient) l’a officiellement annoncé en novembre 2019.

L'Arcep rappelle que « faire perdurer Internet en IPv4 ne l’empêchera pas de fonctionner, mais l’empêchera de grandir ». Deux principaux points sont mis en avant : « dysfonctionnement de certaines catégories de services » et « barrière à l’entrée significative à l’encontre des nouveaux acteurs », qui ont du mal à obtenir des adresses IPv4. 

Les fournisseurs d’accès à Internet (FAI) ne sont pas épargnés : « Les principaux opérateurs français (Bouygues Telecom, Orange, SFR) ont déjà affecté entre environ 93 % et 98 % des adresses IPv4 qu’ils possèdent, à fin juin 2021 ». Free n’a pas communiqué ses chiffres, impossible donc de savoir ce qu’il en est. 

Avant de penser à remplacer IPv4 par IPv6 il faut migrer l’ensemble des sites, équipements et FAI vers la « nouvelle » norme. Un changement brutal est impossible à mettre en place, il doit donc s’inscrire dans la durée… mais le constat de l’Arcep est le même année après année : cela traine des pieds. 

IPv6 sur le fixe : plus de 99 % chez Free, 4,1 % chez SFR

Comme à son habitude, l’Arcep propose un coup d’œil global des différents maillons de la chaine technique. Les ordinateurs et smartphones sont capables d’utiliser IPv6 sans problème depuis des années, contrairement aux objets connectés où la migration est faible, voire nulle : IPv6 est intégré « mais n’est pas activé par le constructeur ».

Arcep IPv6 baromètre novembre 2021

Les équipementiers sont de bons élèves avec un taux très important de matériel compatible : Cisco, Juniper et Nokia ont « indiqué que toutes leurs solutions réseau commercialisées (routeurs, etc.) étaient systématiquement compatibles IPv6p », affirme l’Arcep.

Problème, ce n’est pas le cas des systèmes d’informations des entreprises/administration, des hébergeurs et des fournisseurs de contenus. Les FAI, les opérateurs mobiles, l’infrastructure DNS et les transitaires représentent le ventre mou, avec une migration partielle, derrière laquelle se cachent de grandes disparités.

Chez les FAI français sur le fixe, Free arrive encore largement en tête avec plus de 99 % de clients activés en IPv6 (99 % en 2020), c’est-à-dire dont la box « émet et reçoit effectivement du trafic en IPv6, soit grâce à une activation manuelle de sa part, soit grâce à l’activation effectuée par l’opérateur ».

Arcep IPv6 baromètre novembre 2021

Orange reste en seconde position avec 83 % de clients activés (+8 points en un an). Bouygues Telecom est loin derrière avec 44 % (+16 points) et SFR ferme de nouveau la marche avec 4,1 % seulement (+3,5 points). En deux ans, Free, Orange et Bouygues Telecom ont tous progressé (avec une hausse d’environ 20 points en moyenne), tandis que SFR a… reculé de 3,6 points (6,7 % en 2019 et 1,6 % en 2020).

Le régulateur se penche aussi sur le cas des clients « IPv6-ready », c’est-à-dire quand l’utilisateur est « en mesure d’activer lui-même IPv6 sur sa box (le réseau et la box sont compatibles) ».

Puisque les clients de Free sont activés, ils sont évidemment « ready », sauf sur la 4G Fixe où le taux de IPv6-ready est de 0 %. Idem chez Bouygues Telecom et Orange. Seule SFR se distingue sur la 4G Fixe avec 100 % de clients éligibles, mais seulement 30 % à en profiter dans la pratique.

SFR pourrait avoir de meilleurs résultats globaux puisque 100 % de son réseau xDSL et 42 % de son réseau FTTH est IPv6-ready… pour seulement 1 et 11 % respectivement de clients activés en IPv6. « La politique d’activation d’IPv6 sur les box des principaux opérateurs explique » cette différence. 

On remarque que le réseau de collecte en xDSL (utilisé pour le dégroupage par Bouygues Telecom, Free et SFR) est à 0 % de clients IPv6-ready chez l’ensemble des opérateurs alternatifs.

Arcep IPv6 baromètre novembre 2021

SFR reste complètement à la ramasse sur ses prévisions

Les FAI se livrent aussi à un exercice de prévision pour les années à venir. Si l’on compare avec celles de l’année dernière, on voit assez peu de changement dans les stratégies générales. 

Orange et Bouygues Telecom prévoient de rejoindre (ou de fortement s’approcher) de Free d’ici mi-2024 avec des taux de clients activés entre 90 et 100 % pour le premier, et 85 à 95 % pour le second. La marque au carré rouge prévoit de rester à la traine encore plusieurs années. Mi-2024, elle ne pense pas dépasser… 35 %. 

« Désactiver » IPv6, le pare-feu optionnel chez Free, partage d’IP

L’Arcep distribue des bons points : « il n’est pas possible de désactiver IPv6 sur les box de Bouygues Telecom, Free et SFR (en FttH), ce qui constitue une bonne pratique. Pour le reste des clients SFR en xDSL, l’activation doit être réalisée par le client, via un paramétrage de la box ». 

Se pose aussi la question des protections : « Bouygues Telecom, Orange et SFR suivent une autre bonne pratique qui consiste à mettre en place pour leurs clients un pare-feu IPv6 activé par défaut et qui peut être configuré. Free propose un pare-feu uniquement en option et non configurable ». Pour rappel, en IPv6 chaque appareil dispose de sa propre adresse et peut donc être visible directement depuis Internet sans firewall propre à chaque appareil. 

Le régulateur se penche sur le partage des adresses IPv4 entre les clients, une technique mise en place par les FAI pour faire face à la pénurie : « La majorité des clients du réseau fixe de Free (75% en xDSL et 85% en FttH) ainsi qu’une faible part des clients de Bouygues Telecom (5% en xDSL et 2% en FttH) ont une adresse IPv4 partagée. Cependant, ces opérateurs proposent gratuitement une adresse IPv4 dédiée sur demande […] Depuis cette année, certains clients de SFR ont également une adresse IPv4 partagée (8% en FttH) et cet opérateur ne propose pas d’adresse IPv4 dédiée sur demande ».

FAI alternatifs et pour les pros

Le gendarme des télécoms ne se limite pas aux quatre « gros » opérateurs et propose aussi une analyse de ceux ayant entre 5 000 et 3 millions de clients. Orne THD est toujours en tête avec 100 % de clients activés en IPv6, suivis par Vialis à 88 % (+87 points) et Coriolis Telecom à 72 % (- 4 points). Les autres sont à moins de 25 % d’activés.

« Les taux de clients activés en IPv6 chez Coriolis (72%), K-Net (17%) et OVH Télécom (19%) ont diminué par rapport à l’année dernière, ce qui semble préoccupant », regrette l’Autorité. Bon nombre de FAI (Alsatis, Bigblu, Canal+, Nordnet, Ozone, SFR Carïbe et Réunion Mayotte, Tubéo, VidéoFutur et Wifirst) sont à 0 % et les prévisions pour mi-2022 sont assez peu encourageantes dans l’ensemble. 

Arcep IPv6 baromètre novembre 2021

L’Autorité rappelle que « suite aux signalements reçus sur la plateforme "J’alerte l’Arcep" concernant les difficultés de certaines entreprises pour obtenir des offres IPv6 de la part de leurs opérateurs », elle propose désormais un baromètre pour des offres Pro. Bouygues Telecom est à 53 % (+23 points) de clients activés en IPv6, Orange à 11 % (+10 points) et SFR se distingue de nouveau avec… moins de 1 % (stable sur un an).

Ce dernier ne prévoit pas franchement de changement dans les années à venir. Free s’est pour rappel lancé sur ce marché en mars de cette année, mais il n’est pas encore dans ce baromètre.

SFR se réveille sur le mobile, Free complétement à la ramasse 

Sur le mobile, c’est le statu quo dans les deux extrêmes : 87 % des clients de Bouygues Telecom sous Android et plus de 99 % de ceux sur iOS sont activés en IPv6, contre respectivement… 1 et 0 % chez Free Mobile. Orange continue de progresser doucement sur iPhone avec 66 % (+6 points) et Android avec 47 % (+12 points).

SFR se réveille enfin avec 13 % des terminaux Android et 90 % de ceux sous iOS activés en IPv6. Lors du précédent baromètre, la marque au carré rouge ne dépassait pas 0,2 % dans les deux cas. Elle prévoit désormais de passer à 60/70 % de clients Android activés en IPv6 d’ici mi-2024 et plus de 99 % sur iOS dans le même temps

Orange prévoit 65 à 75 % sur Android et 90 à 100 % sur iOS, contre respectivement 85 à 95 % et +99 % pour Bouygues Telecom. Reste donc le cas du vilain petit canard sur le mobile : Free Mobile, qui n’a tout simplement pas donné ses prévisions pour les années à venir. 

Le régulateur invite par contre l’ensemble des opérateurs à « accélérer le déploiement d’IPv6 sur leurs offres "data
uniquement" ». C’est particulièrement le cas sur iOS où SFR n’est qu’à 50 %, Bouygues Telecom à 23 % et Orange à 14 %, bien loin des taux des iPhone sans partage de connexion.

Arcep IPv6 baromètre novembre 2021

La foire des MVNO, certains ne comptent même pas décoller du 0 %

Chez les opérateurs virtuels, c’est très variable également. Nordnet et Ozone sont à plus de 50 %, Prixtel, Bazile Telecom et La Poste Mobile et Afone sont entre 27 et 46 %. Euro Information Telecom (Auchan, Cdiscount, CIC/Crédit Mutuel et NRJ Mobile) qui a été rachetée par Bouygues Telecom est à 16 %.

China Telecom, Coriolis, Lebara, Lycamobile, Syma et Transatel sont à 0 %… et ne prévoient pas de bouger d’ici mi-2022. Ceux pour qui les activations ont déjà commencé anticipent par contre une hausse des activations, souvent aux alentours d’une vingtaine de points. 

Arcep IPv6 baromètre novembre 2021

Les hébergeurs sont « un des principaux goulots d’étranglement »

Passons maintenant de l’autre côté des tuyaux, avec les hébergeurs pour commencer. La situation n’est pas reluisante et ils « représentent encore l’un des principaux goulots d’étranglement dans la migration vers IPv6 : sur les principaux sites visités par les Français selon le classement Alexa, seuls 29% sont accessibles en IPv6 (contre 26% en octobre 2020) ». Le régulateur rappelle qu’il considère un site comme accessible en IPv6 lorsqu’il dispose d’un enregistrement IPv6 (« AAAA ») au niveau du serveur DNS.

Par contre, 62 % des pages sont accessibles en IPv6, un chiffre bien supérieur à celui des hébergeurs. Cette différence s’explique simplement : « les petits fournisseurs de contenu proposent souvent des sites web (au nombre de pages consultées généralement faible) non compatibles avec IPv6 ». 

Sur les 3,52 millions de sites web en .fr, .re, .pm, .yt, .tf et .wf, seulement 20 % sont disponibles en IPv6, contre 17,9 % l’année dernière et 10,5 % en 2015. « Le rythme de cette évolution semble loin de pouvoir permettre une transition complète dans les prochaines années », regrette l’Autorité. 

Arcep IPv6 baromètre novembre 2021

Attention, ces chiffres cachent une autre réalité : le taux de sites accessibles en IPv6 est en baisse chez certains hébergeurs. Il passe de 98 à 58,4 % chez Cloudflare, de 11,1 à 6,1 % chez Amazon, de 1,1 à 0 % chez Wix… OVHcloud grimpe au contraire de 6 points pour arriver à 12,2 %. Il pousse l’ensemble vers le haut puisqu’il représente plus de 1,4 million de domaines loin devant ses concurrents : Ionos est second avec 390 000, Gandi 3e avec 264 000, etc.

Sujet d’inquiétude pour l’Arcep : le spectre d’un Internet scindé avec IPv4 d’un côté et IPv6 de l’autre. Alors qu’il y avait 514 sites en IPv6-only en 2020, il y en a désormais le double (1028) cette année. Les clients en IPv4 ne peuvent donc pas y accéder. Si vous êtes chez Free Mobile ou chez SFR sur le fixe par exemple, ce n’est pas gagné…

Mails : Google largement en tête, Scaleway second (loin derrière)

Concernant les hébergeurs mail, la situation est facile à résumer : il y a « un très fort retard : seuls 7,4% des serveurs mail sont à ce jour adressés en IPv6 sur l’intégralité des .fr, .re, .pm, .yt, .tf et .wf (contre 6 % à mi-2021) ». Avec une hausse de seulement 1,4 point, il faudra encore des années… 

L’Autorité en rajoute une couche : « un certain nombre d’entre eux comportent un niveau de redondance en IPv6 inférieur à celui atteint en IPv4, et est donc susceptible de poser des problèmes de résilience ». Seul Google fait office de bon élève avec plus de 90 %, les autres n’ont que quelques pouièmes en IPv6, excepté Scaleway (14,3 %).

À contrario, l’infrastructure DNS est « le secteur le plus en avance dans la transition vers IPv6 avec environ 75% des serveurs faisant autorité supportant IPv6. Environ 72 % des serveurs DNS garantissent une résilience d’IPv6 équivalente à celle d’IPv4 (niveau de redondance identique) ». 

Arcep IPv6 baromètre novembre 2021Arcep IPv6 baromètre novembre 2021

L’État ne montre toujours pas l’exemple

L’Arcep propose enfin une analyse des sites et services en ligne de l’État (.gouv.fr) car, pour l’Autorité, « l’exemplarité de l’État dans la transition vers IPv6 étant un des leviers importants pour accélérer la migration »… mais ce n’est pas gagné. « La grande majorité ne soit encore accessible qu’en IPv4 et que la progression soit très limitée par rapport à l’année dernière » : 2,9 % des sites principaux (+0.8 point) et 0,9 % (-0,7 point) des sites secondaires.

L’hébergement mail est toujours à 0 %, le DNS passe de 45,5 à 55 %. 

Arcep IPv6 baromètre novembre 2021

Utilisation d'IPv6 : la France 4e en Europe, 6e dans le monde

Dernier point de l’observatoire, le taux d’utilisation d’IPv6. Il « représente le pourcentage d’utilisateurs en IPv6 mesuré au niveau d’un hébergeur (qui propose déjà IPv6) » : « Ce taux tel qu’observé par Google atteint à ce jour presque 50 % en France ».

« Au niveau mondial, la France passe de la dixième place à fin 2020 à la sixième place aujourd’hui en termes de taux d’utilisation d’IPv6 d’après la médiane des quatre principales sources de données publiquement disponibles pour évaluer l’utilisation d’IPv6 (Google, Akamai, Facebook et Apnic) ». L’Inde est largement en tête avec 65,8 % (+2,2 % en un an), tandis que la Roumanie est 30e avec 22 %.

L’Hexagone est le quatrième pays européen derrière la Belgique (54,5 %), l’Allemagne (51,6 %) et la Grèce (49 %). De grosses disparités existent sur le vieux continent : la médiane de l’Europe de l’Ouest est à 46,7 % d’utilisation en IPv6, contre 29,4 % pour le Nord, 10,7 % pour l’Est et 9,1 % pour le Sud. 

Après avoir publié un guide sur « pourquoi passer à IPv6 » à destination des entreprises, l’Arcep en met en ligne un nouveau sur « comment passer à IPv6 ». Il est publié par la task-force IPv6 du régulateur et « destiné prioritairement aux experts des systèmes d’information des entreprises afin de les aider à mettre en œuvre la transition vers IPv6 ».

Arcep IPv6 baromètre novembre 2021
74

Écrit par Sébastien Gavois

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

En Europe, la pénurie a déjà deux ans

IPv6 sur le fixe : plus de 99 % chez Free, 4,1 % chez SFR

SFR reste complètement à la ramasse sur ses prévisions

« Désactiver » IPv6, le pare-feu optionnel chez Free, partage d’IP

FAI alternatifs et pour les pros

SFR se réveille sur le mobile, Free complétement à la ramasse 

La foire des MVNO, certains ne comptent même pas décoller du 0 %

Les hébergeurs sont « un des principaux goulots d’étranglement »

Mails : Google largement en tête, Scaleway second (loin derrière)

L’État ne montre toujours pas l’exemple

Utilisation d'IPv6 : la France 4e en Europe, 6e dans le monde

Le brief de ce matin n'est pas encore là

Partez acheter vos croissants
Et faites chauffer votre bouilloire,
Le brief arrive dans un instant,
Tout frais du matin, gardez espoir.

Commentaires (74)


Depuis cette année, certains clients de SFR ont également une adresse IPv4 partagée (8% en FttH) et cet opérateur ne propose pas d’adresse IPv4 dédiée sur demande



Grosse faute de l’ARCEP, si c’est possible de revenir en IPV4 FullStack ce que j’ai fait.


Apparemment c’est un cauchemard dans certains cas pour retrouver une IPv4 full stack…


Etre_Libre

Apparemment c’est un cauchemard dans certains cas pour retrouver une IPv4 full stack…


Oui, je confirme. Mais tu peux le faire. ça m’a pris juste 1 mois que les personnes ont compris ma demande avec le support à l’étranger.


C’est de l’IPv6 natif chez Free ou toujours du 6in4 (ou 6to4, je ne sais plus) ?



Sur les 3,52 millions de sites web en .fr, .re, .pm, .yt, .tf et .wf, seulement 20 % sont disponibles en IPv6, contre 17,9 % l’année dernière et 10,5 % en 2015. « Le rythme de cette évolution semble loin de pouvoir permettre une transition complète dans les prochaines années », regrette l’Autorité.




Par exemple, toujours pas d’IPv6 sur NXI


Je sais que certains ont une passion pour la redondance, mais


David_L

Je sais que certains ont une passion pour la redondance, mais


Pourtant votre serveur propose bien des adresses IPv6 🤔



$ nslookup nextinpact.com
Server: 9.9.9.9
Address: 9.9.9.9#53

Non-authoritative answer:
Name: nextinpact.com
Address: 104.26.14.7
Name: nextinpact.com
Address: 104.26.15.7
Name: nextinpact.com
Address: 172.67.68.75
Name: nextinpact.com
Address: 2606:4700:20::681a:f07
Name: nextinpact.com
Address: 2606:4700:20::ac43:444b
Name: nextinpact.com
Address: 2606:4700:20::681a:e07


Édite : Oups, j’ai utilisé le mauvais nom de domaine, j’ai oublié que le site pointait vers www.nextinpact.com 😅


Bonjour,



pour des questions ou des remarques sur le guide, le principal auteur est ici :D


Vu que tu as l’air de t’y connaitre en IPv6 :D
Tu aurais un bon guide ou des docs assez complets à recommander pour maitriser la tech ? Quelque chose qui va au dela de l’explication du format d’addresse sans etre au niveau ingé++.



Le soucis de l’IPV6 c’est que c’est assez complexe de base et surtout ça s’est beaucoup étoffé avec les années, avec -d’après ce que j’ai compris- d’innombrables applications de la tech pour faire de la translation ipv4/ipv6 ou encore pour “émuler” le NAT IPv4. Le tout rend le sujet effrayant pour les techos qui sont supposés passer de l’IPv4 à l’IPv6 dans les entreprises.



Mes connaissances “basiques++” sur le sujet datant d’il y a quelques années me semblent à chaque fois obsolètes et difficile de trouver un bon guide (et à jour) dans cette foret.


Merci pour le long sujet, un article très intéressant !



à quand un moyen plus incisif pour limiter le partage d’ipv4, faut les pousser un peu !



j’admets quand même garder les ipv4 au boulot, c’est bien plus simple ! :)


A noter que l’Arcep propose les schémas dans une meilleure qualité dans un .zip pour la presse sur un lien situé en bas de la page https://www.arcep.fr/cartes-et-donnees/nos-publications-chiffrees/transition-ipv6/barometre-annuel-de-la-transition-vers-ipv6-en-france.html (cela vous évite d’avoir a extraire les schémas du PDF et permet une meilleure qualité)



Il y a également des statistiques IPv6, sur le top 100 des pays avec le plus d’internaute sur https://www.arcep.fr/la-regulation/grands-dossiers-internet-et-numerique/lipv6/statistiques-ipv6.html


J’avais de l’IPv6 mais Bouygues Telecom à décider la semaine dernière de me désactiver l’IPv6. Je ne sais pas pourquoi et eux non plus mais ils ne savent pas me la remettre.



thedark_ a dit:


Depuis cette année, certains clients de SFR ont également une adresse IPv4 partagée (8% en FttH) et cet opérateur ne propose pas d’adresse IPv4 dédiée sur demande



Grosse faute de l’ARCEP, si c’est possible de revenir en IPV4 FullStack ce que j’ai fait.




Ils proposent 3 modes sur demande de ce que j’ai vu :




  • Full stack ipv4

  • Dual Stack ipv4 + IPv6

  • CGNat IPv4 + full stack IPv6


SFR avance et recule au fil des semaines, il est difficile d’établir un état à date.



selon le classement Alexa, seuls 29% sont accessibles en IPv613




J’ai dû m’endormir quelques millénaires… :transpi:



 



(c’est signalé)



JCLB a dit:


SFR avance et recule au fil des semaines, il est difficile d’établir un état à date.




En ADSL chez SFR, IPv6 marchait aléatoirement ces dernières années (erreur indiquée par la box), mais cette année ça a l’air stable. Par contre, en effet il faut l’activer manuellement.



Par contre je ne m’expliquerai jamais pourquoi on refile des préfixes /64 ou /48 à des particuliers, c’est vraiment complètement débile. Je sais bien qu’on a vraiment beaucoup beaucoup d’adresses, mais pourquoi avoir fait des adresses aussi longues si c’est pour que la moitié de cette longueur ne serve à rien ?



Krymson a dit:



j’admets quand même garder les ipv4 au boulot, c’est bien plus simple ! :)




C’est curieux que tant de monde trouve cela plus compliqué alors que c’est bien plus simple. Plus besoin de plan d’adressage et plus besoin de DHCP.



EUI64 pour tout le monde donc le fichier DNS ou Host au choix se fait à partir des adresses MAC et des suffixes externes et/ou internes (ULA). DNS pour tout y compris pour samba: Plus de WINS non plus.



Il est vrai que les maintenues de samba ne facilitent pas la transition voir qu’ils la freinent mais j’ai réussi obtenir un samba exclusivement IPv6.
Pour ceux que cela intéresse, c’est en regardant le fichier obtenu sur un Synology que j’ai compris comment bloquer smbv1 et ipv4. Par contre, je n’ai pas encore réussi à virer samba V2.



Chez moi, le pihole fait DNS et diffus le préfixe ULA pour les services locaux et la box diffusé le préfixe global pour le web. En entreprise, on peut tout passer en ULA et mettre un firewall proxy pour le web et c’est réglé.


Quelqu’un sait si on peut faire du multi-wan en IPv6 (donc avec des préfixes attribués différents) sans NAT ?



Actuellement, afin que chaque appareil du réseau local puisse passer indifféremment et automatiquement par un WAN ou un autre en fonction de divers critères et de la disponibilité des WAN, je n’ai pas trouvé d’autre solution que celle que j’appliquais en IPv4 : adressage local sur le réseau local, puis NAT à la volée avec l’adresse que le routeur a reçue depuis le WAN où ça doit sortir.



C’est pas que ça marche mal mais il y a peut-être mieux à faire, et pour héberger des serveurs on reste à faire du port forwarding comme en IPv4, ce qui n’est pas génial.


Inodemus

Quelqu’un sait si on peut faire du multi-wan en IPv6 (donc avec des préfixes attribués différents) sans NAT ?



Actuellement, afin que chaque appareil du réseau local puisse passer indifféremment et automatiquement par un WAN ou un autre en fonction de divers critères et de la disponibilité des WAN, je n’ai pas trouvé d’autre solution que celle que j’appliquais en IPv4 : adressage local sur le réseau local, puis NAT à la volée avec l’adresse que le routeur a reçue depuis le WAN où ça doit sortir.



C’est pas que ça marche mal mais il y a peut-être mieux à faire, et pour héberger des serveurs on reste à faire du port forwarding comme en IPv4, ce qui n’est pas génial.


Ça dépend de ta volonté d’exposer tes serveurs sur Internet. Quand tu vois le niveau de sécurité des serveurs cloud, ça me fais un peu peur d’avoir la totalité des serveurs d’une infra accessible sur Internet.


Inodemus

Quelqu’un sait si on peut faire du multi-wan en IPv6 (donc avec des préfixes attribués différents) sans NAT ?



Actuellement, afin que chaque appareil du réseau local puisse passer indifféremment et automatiquement par un WAN ou un autre en fonction de divers critères et de la disponibilité des WAN, je n’ai pas trouvé d’autre solution que celle que j’appliquais en IPv4 : adressage local sur le réseau local, puis NAT à la volée avec l’adresse que le routeur a reçue depuis le WAN où ça doit sortir.



C’est pas que ça marche mal mais il y a peut-être mieux à faire, et pour héberger des serveurs on reste à faire du port forwarding comme en IPv4, ce qui n’est pas génial.


Pour du multihoming soit tu fais double adresse routable partout, et tu ne maîtrise pas bien ce qui se passe en DNS interne en plus de devoir maintenir des ACL doublées.
Soit tu prends un ULA et tu fais du NPTv6 pour translater vers l’un ou l’autre préfixe en sortie. Attention la précédence ULA est inférieure à IPv4. L’idéal est de demander un PI à son LIR pour l’adressage interne.



Inodemus a dit:


Par contre je ne m’expliquerai jamais pourquoi on refile des préfixes /64 ou /48 à des particuliers, c’est vraiment complètement débile. Je sais bien qu’on a vraiment beaucoup beaucoup d’adresses, mais pourquoi avoir fait des adresses aussi longues si c’est pour que la moitié de cette longueur ne serve à rien ?




Une adresse machine fait toujours 64 bits de long en IPv6 donc un préfixe de 64 bits est le standard. L’avantage d’avoir plus de préfixes est de pouvoir séparer les réseaux. Par exemple pour séparer Ethernet et wifi pour des raisons de sécurité. Mais il est vrai que 48 bits pour un particulier, c’est du gâchis.



Côté machine, il est important de perdre le réflexe de vouloir compter les adresses. De fait, une adresse machine est soit aléatoire, soit fixe.
Quand elle est fixé, ce qui est pratique en entreprise ou dans un environnement un tant soit peu contrôlé, elle peut-être basée sur l’adresse MAC, ce qui donne une adresse EUI64, soit être une clef publique mais ce dernier cas doit être moins intéressant.
Pour gérer un parc de machines avec EUI64, il suffit donc de connaître les adresses MAC et on peut en déduire l’adresse qu’elles vont s’attribuer.



Vraiment, IPv4, c’est un truc du passé.



Krymson a dit:


j’admets quand même garder les ipv4 au boulot, c’est bien plus simple ! :)




Ça dépend de la taille du réseau d’entreprise géré: j’ai vu récemment qq-part la création de mini sous-réseaux IPv4 en /27 pour pouvoir créer de nouveaux vlan.
Ailleurs, ce sont des sites de production qui ont dû être arrêtés pour refaire le plan d’adressage suite à un rachat d’un concurrent qui utilisaient le même…



Après l’étude de l’ARCEP porte sur le web, mais quand les boîtes ont des progiciels qu’elles upgradent au mieux tous les 5 ans vu les coûts engendrés, et que ces vielles versions ne gèrent pas IPv6, ben tu n’as pas le choix.



Par contre je suis curieux de savoir comment le monde du jeux vidéo se débrouille (ou pas…) avec IPv6: pour les clients des boutiques (Steam, Epic, Ubisoft, GOG,…) comme pour les jeux en lignes (Rocket League, PUBG, Fortnite et j’en passe), voir les consoles (Xbox, PS4/5, Switch).


L’étude porte sur le Web mais le guide sur du Système d’Information corporate d’entreprise.



Pour l’instant le secteur du JV est pas très IPv6 compliant, hormis l’usage spécial de Teredo chez XBOX.



ça viendra avec la disponibilité grandissante de v6 chez les particuliers et les effets négatifs du partage d’IPv4 qui finira par provoquer des plaintes chez les joueurs.


La Switch n’est pour le moment pas compatible IPv6, donc les jeux encore moins… J’aimerai pas être chez Free, ça doit être compliqué de jouer en ligne…


Ce truc va t’il finir par percer ? Ou ça va être le plus gros échec technique mondiale ?


Ça ne pourra pas être un échec vu que, de gré ou de force, il faudra que ça passe pour que tout puisse continuer à fonctionner. Techniquement, il n’y a absolument aucun souci. La seule question est jusqu’où attendront ils ? Beaucoup attendent juste d’être au bord du précipice pour sauter le pas.


Tous les documents disponibles ne semble exister qu’à destination des entreprises…
En existe-t-il à destination des particuliers (si cela peut être utile) afin que tous les connectés aient la possibilité de passer en V6.
Pour des particuliers qui n’ont que leur ordi, leur téléphone, éventuellement une smart TV…
Pour ceux qui ont plusieurs ordi et Tph, un NAS, une imprimante sur leur réseaux, etc.
Pour ceux qui des tables de forçages des @IP dans leur réseaux pour les périph connus par leur routeur, etc
Mon propos peut paraître idiot, mais si cela peut, tant soit peu, réduire l’usage d’un système devenant obsolète (et cela sans complication certainement pour 50% des particuliers).


Dans l’annexe du guide je donne l’exemple d’un accès à un service derrière une livebox. (Ouverture firewall et gestion de l’adresse)



Pour l’adressage, la section dédiée comporte entre autres les différents mécanismes d’attribution d’adresse, applicable également chez un particulier bien que la box ait la main sur ce que défini le RA sans paramétrage possible.


JCLB

Dans l’annexe du guide je donne l’exemple d’un accès à un service derrière une livebox. (Ouverture firewall et gestion de l’adresse)



Pour l’adressage, la section dédiée comporte entre autres les différents mécanismes d’attribution d’adresse, applicable également chez un particulier bien que la box ait la main sur ce que défini le RA sans paramétrage possible.


Merci pour le guide.
Je viens de le télécharger.
Il faut vraiment que je m’y plonge dans cet IPv6.


A quand une obligation pour les sites de l’Etat d’utiliser l’IPV6 ?



Se7h a dit:


La Switch n’est pour le moment pas compatible IPv6, donc les jeux encore moins… J’aimerai pas être chez Free, ça doit être compliqué de jouer en ligne…




Je suis chez free et j’ai bien les 2 ip fullstacks, et mon fils n’a aucun problème pour jouer avec sa switch. Qui soit dit en passant est compatible ipv6 depuis la version 10.


Et après vérification ca ne marche pas l’ipv6 sur switch :D


Vous faites donc parti des 20% de Freenautes chanceux ^^



À mon avis, il faudrait voir avec les clients Free les plus récents, qui ne doivent pas avoir cette chance.



Je serai curieux de savoir comment ça se passe de vouloir jouer à la Switch en ligne via une IP partagé. Tu es condamné à ne pas pouvoir jouer à certains jeux, ou à tous les jeux ? Et les ports attribués aux clients sont permanents ou ils changent pour donner la chance quelques jours pour le client A et quelques jours plus tard au client B ?


Se7h

Vous faites donc parti des 20% de Freenautes chanceux ^^



À mon avis, il faudrait voir avec les clients Free les plus récents, qui ne doivent pas avoir cette chance.



Je serai curieux de savoir comment ça se passe de vouloir jouer à la Switch en ligne via une IP partagé. Tu es condamné à ne pas pouvoir jouer à certains jeux, ou à tous les jeux ? Et les ports attribués aux clients sont permanents ou ils changent pour donner la chance quelques jours pour le client A et quelques jours plus tard au client B ?


Ça marche aussi très bien pour les nouveaux clients.
Il suffit de demander une IP fullstack dans son espace abonné et on l’a au bout de quelques minutes.



JeanM64 a dit:


Tous les documents disponibles ne semble exister qu’à destination des entreprises… En existe-t-il à destination des particuliers (si cela peut être utile) afin que tous les connectés aient la possibilité de passer en V6. Pour des particuliers qui n’ont que leur ordi, leur téléphone, éventuellement une smart TV… Pour ceux qui ont plusieurs ordi et Tph, un NAS, une imprimante sur leur réseaux, etc. Pour ceux qui des tables de forçages des @IP dans leur réseaux pour les périph connus par leur routeur, etc Mon propos peut paraître idiot, mais si cela peut, tant soit peu, réduire l’usage d’un système devenant obsolète (et cela sans complication certainement pour 50% des particuliers).




Il n’y a absolument aucun sujet pour les particuliers :
Les postes connectés sont en DHCP (ie : attribution automatiques des IP) avec des IP attribués par la box/routeur (majoritairement fourni par l’opérateur, donc).



En gros en France, les opérateurs nationaux appuierait sur le bouton de leur box compatibles (ie : Fournir automatiquement une IPv6 à côté de l’IPv4 en DHCP par la box), on pourrait tous être en IPv6 si il est gêré par l’équipement , ce qui est le cas de quasiment tout les end-devices (sauf cas particulier bien sûr).



Ca fait des années que tout le monde pourrait sauter le pas (dont les entreprises car je confirme, IPv6 c’est BEAUCOUP plus simple que IPv4 pour la segmentation/Sécurité) mais ce sont les middlebox qui coincent (FireWall, load-balancer et la quasi-intégralité des équipements de sécurité qui ne fonctionnent soient pas en IPv6, soit sont bridés en fonctionnalités).



Inodemus a dit:


Par contre je ne m’expliquerai jamais pourquoi on refile des préfixes /64 ou /48 à des particuliers, c’est vraiment complètement débile. Je sais bien qu’on a vraiment beaucoup beaucoup d’adresses, mais pourquoi avoir fait des adresses aussi longues si c’est pour que la moitié de cette longueur ne serve à rien ?




En adressage SLAAC, ton sous réseau doit obligatoirement être un /64
Globalement la norme fait qu’on ne refile pas moins qu’un /64 à un sous réseau. (ce qui permet de faire du SLAAC à chaque fois et donc de rendre transparent l’utilisation d’ipv6)
Ca laisse quand même un /64 pour le reste du monde (soit un nombre astronomique de sous réseaux)
Je suis d’accord qu’un /48 est du gâchis mais ne pas oublier qu’une ipv4 est l’équivalent d’un /32 (donc avec un /48, on peut distribuer 65000 clients de plus qu’avec une ipv4)



thedark_ a dit:


Depuis cette année, certains clients de SFR ont également une adresse IPv4 partagée (8% en FttH) et cet opérateur ne propose pas d’adresse IPv4 dédiée sur demande



Grosse faute de l’ARCEP, si c’est possible de revenir en IPV4 FullStack ce que j’ai fait.




C’est l’information donnée par SFR (pas d’IPv4 dédiée pour les clients qui ont une IPv4 mutualisée) et vu la difficulté pour obtenir une IPv4 dédiée, on ne peut pas dire qu’il existe vraiment une option pour avoir une IPv4 dédiée. Ce n’est disponible ni sur l’espace client et le support niveau 1 n’est pas en mesure de proposer une IPv4 dédiée.


Quid du filtrage par-feux des box en IPV6 ? N’étant pas un spcécialiste IPV6, s’il faut refaire toutes les rgèles firewall existantes en IPV6, bonjour la galère.
D’autres parts, quels risques pour les machines qui sont vulnérables (sans qu’on le sache) et addressables d’Internet. ça ne risque pas d’être la fête côté attaque et equipement zombies ?
CE serait intéressant d’avoir les expériences de ceux qui ont pu l’implémenter en intégral (et qui ont eu le temps de le faire proprement :-) )



Inodemus a dit:


Par contre je ne m’expliquerai jamais pourquoi on refile des préfixes /64 ou /48 à des particuliers, c’est vraiment complètement débile. Je sais bien qu’on a vraiment beaucoup beaucoup d’adresses, mais pourquoi avoir fait des adresses aussi longues si c’est pour que la moitié de cette longueur ne serve à rien ?




Sur le fixe tous les opérateurs proposent plus que /64, ce qui permet d’avoir un réseau invité séparé du réseau domestique par exemple (/64 pour chacun).



Sur le mobile, les opérateurs n’attribuent que /64 et Alexandre Petrescu explique pourquoi un /64 est trop petit pour l’IPv6 sur le mobile
https://lafibre.info/arcep/rapport-etat-internet-2021/msg881214/#msg881214



JCLB a dit:


pour des questions ou des remarques sur le guide, le principal auteur est ici :D




C’est pas une question ni une remarque, mais merci pour le guide :yes:



Inodemus a dit:


Quelqu’un sait si on peut faire du multi-wan en IPv6 (donc avec des préfixes attribués différents) sans NAT ?



Actuellement, afin que chaque appareil du réseau local puisse passer indifféremment et automatiquement par un WAN ou un autre en fonction de divers critères et de la disponibilité des WAN, je n’ai pas trouvé d’autre solution que celle que j’appliquais en IPv4 : adressage local sur le réseau local, puis NAT à la volée avec l’adresse que le routeur a reçue depuis le WAN où ça doit sortir.



C’est pas que ça marche mal mais il y a peut-être mieux à faire, et pour héberger des serveurs on reste à faire du port forwarding comme en IPv4, ce qui n’est pas génial.




Commençons par l’adresse de machine:
En IPv6, tes machines peuvent avoir autant d’adresse que voulu et en général, c’est une à deux par préfixe: une EUI64 pour être joignable et une aléatoire pour aller naviguer tranquille sur Internet sans se faire pister.



Perso, je préfère désactiver l’adresse aléatoire pour maitriser les accès (qui s’est connecté en ssh sur mon serveur, qui peut entrer en wifi…). Je ne sais pas encore séparer ce réglage selon les préfixes car c’est utile sur Internet et gênant en local.



Les adresses machines basée sur les adresse MAC des ports réseau sont idéales pour gérer un parc de machines car les adresses générées sont parfaitement anticipables.



Puis, parlons préfixes
De base, une machine s’attribue une ou deux adresses avec le préfixe fe80::/64 pour chaque interface réseau (l’équivalent des adresses 169.254.0.0/16 en IPv4). Sur ces adresses spéciales, il faut à chaque fois préciser le numéro ou l’identifiant d’interface réseau, ce qui est assez galère donc je ne conseille pas d’utiliser ces adresses pour vos services réseau ssh, samba, sql ou autre.
Elles sont pratiques pour des protocoles du type BONJOUR.



En IPv6, rien n’interdit d’avoir plusieurs routeurs (sauf quand un réac met en place DHCPv6 par mauvaise habitude: oubliez cette source de problème et de perte de temps).



Chaque routeur annonce un préfixe et sa capacité à relayer des messages ailleurs et pour chaque préfixe annoncé sur ton réseau, tes machines vont se concocter des adresses IP toute seules.
Le préfixe est annoncé sur demande spécifique (quand une machine rejoint le réseau), et à intervalle régulier.



Tu peux également utiliser un raspberry pi pour annoncer un préfixe sans routage pour créer des adresses locales ULA (équivalent des 10.0.0.0/8, 172.16.0.0/12 et 192.1686.0.0/16). C’est idéal pour le traffic purement local ou routable entre sites pour une entreprise multinationnale.
C’est ce que j’utilise pour samba, pour l’imprimante réseau (IPv6 only aussi), et le NAS. Ce trafic ne peut pas se retrouver par erreur sur Internet de cette manière.



Donc, si tu as N routeurs, tu aura N préfixes annoncés sur ton réseau et autant d’adresses ou de paires d’adresses.



Et pour que tout cela fonctionne, aucune configuration particulière n’est requise. Les machines vont créer leurs métriques au fil de l’eau et préférer tel ou tel routeur selon la qualité de service.



Conclusion
Passer à IPv6 c’est avant tout perdre des réflexes bien ancrés:




  • Une machine n’a pas une adresse IP d’un seul type mais peut cumuler les trois (auto-attribuée, locale et globale): pas de choix à réaliser entre fromage, dessert et fruit ;

  • Aucun plan d’adressage n’est nécessaire: un listing d’adresses MAC et de noms de machine et hop le DNS est configuré ;

  • Aucune prise de tête en cas de changement de préfixes locaux ou globaux suite à un changement de FAI ou de fusion entre deux entreprises ;

  • Aucun serveur DHCP n’est nécessaire : c’est même totalement contre-productif ;

  • Aucun routeur additionnel n’est nécessaire pour bénéficier de plusieurs accès WAN ;

  • Aucune translation d’adresse n’est nécessaire pour quoi que ce soit.



Il y a pleins d’autres avantages mais je vais m’arrêter à ceux là car ils sont assez parlants.


Merci beaucoup wanou pour cette super réponse que je ne manquerai pas d’étudier un peu plus en détail à une heure un peu moins tardive. Il me vient cependant rapidement quelques remarques :




Perso, je préfère désactiver l’adresse aléatoire pour maitriser les accès (qui s’est connecté en ssh sur mon serveur, qui peut entrer en wifi…). Je ne sais pas encore séparer ce réglage selon les préfixes car c’est utile sur Internet et gênant en local.




Je ne suis pas sûr qu’on puisse séparer ce paramètre suivant les préfixes, il me semble même que sur certains clients (Android ?), on ne peut pas désactiver l’adresse aléatoire du tout. Et sous Windows ça se fait mais c’est un peu galère.




Chaque routeur annonce un préfixe et sa capacité à relayer des messages ailleurs et pour chaque préfixe annoncé sur ton réseau, tes machines vont se concocter des adresses IP toute seules.




OK ça je ne savait pas que ça marchait avec plusieurs préfixes à la fois, comme dit dans mon message au-dessus.




Et pour que tout cela fonctionne, aucune configuration particulière n’est requise. Les machines vont créer leurs métriques au fil de l’eau et préférer tel ou tel routeur selon la qualité de service.




Ca par contre je ne veux pas, je veux que ce soit le routeur qui décide, pas les machines, car la notion de qualité de service varie en fonction du type d’utilisation. Certaines utilisations demandent du débit, d’autres un bon ping. Certaines machines sont plus génératrices de trafic que d’autres, et il n’est pas souhaité que celles-ci s’accaparent tous les WAN à la fois si plusieurs sources de trafic fonctionnent en même temps dessus, en ne laissant que des miettes et des gros pings aux autres.



Et si un WAN tombe en panne, il y a les déviations de secours à gérer, différentes elles aussi suivant les machines. Pour ces raisons, il me semble que c’est le routeur (et un seul centralisé) qui doit répartir le trafic en suivant des règles, ce qui implique de pouvoir identifier les machines dans ces règles, et donc d’avoir soit des adresses non aléatoires, soit une autre méthode d’identification.




Il y a pleins d’autres avantages mais je vais m’arrêter à ceux là car ils sont assez parlants.




Je ne l’ai jamais nié, et je ne me suis pas inspiré d’IPv4 (enfin, pas volontairement) pour décider de ma configuration actuelle IPv6, c’est juste qu’après recherche, je n’ai juste pas trouvé d’autre configuration qui correspond à ce que je veux faire. Ca ne veut pas dire qu’elle n’existe pas, d’où ma demande ici.



macintosh_plus a dit:


Ça dépend de ta volonté d’exposer tes serveurs sur Internet. Quand tu vois le niveau de sécurité des serveurs cloud, ça me fais un peu peur d’avoir la totalité des serveurs d’une infra accessible sur Internet.




C’est un autre sujet ça, celui du firewall. Avant d’en arriver là, il faut d’abord arriver à exposer ses serveurs sur Internet, dans le cas que j’ai cité je n’y suis pas arrivé. Si j’y étais arrivé, je me serais ensuite occupé du firewall.




JCLB a dit:


Pour du multihoming soit tu fais double adresse routable partout, et tu ne maîtrise pas bien ce qui se passe en DNS interne en plus de devoir maintenir des ACL doublées.
Soit tu prends un ULA et tu fais du NPTv6 pour translater vers l’un ou l’autre préfixe en sortie. Attention la précédence ULA est inférieure à IPv4. L’idéal est de demander un PI à son LIR pour l’adressage interne.




Double adresse routable, on peut diffuser 2 préfixes sur un seul LAN (donc 2 passerelles ?) ? Et les clients vont vraiment prendre les 2 adresses et pas s’arrêter au premier préfixe qu’ils reçoivent ? Aussi, ce sont les clients dans ce cas qui choisiront quelle adresse utiliser et donc par quel WAN passer, moi je voudrais que ce soit le routeur, et si je bloque un WAN au niveau du routeur, je doute qu’ils décident d’essayer l’autre adresse.



Je vais me renseigner sur NPTv6, merci du tuyau.




Hiigara a dit:


En adressage SLAAC, ton sous réseau doit obligatoirement être un /64 Globalement la norme fait qu’on ne refile pas moins qu’un /64 à un sous réseau. (ce qui permet de faire du SLAAC à chaque fois et donc de rendre transparent l’utilisation d’ipv6) Ca laisse quand même un /64 pour le reste du monde (soit un nombre astronomique de sous réseaux)




Oui, je sais qu’il en reste beaucoup quand-même, mais bon, les adresses auraient été plus courte en réduisant côté suffixe que ça n’aurait pas fait de mal me semble-t-il. Le principe du SLAAC est toujours un peu étrange puisqu’il consiste à utiliser une adresse matérielle censée être unique au monde pour l’incorporer entière dans une adresse censée être unique à un (petit) sous-réseau, ce qui est une idée un peu bizarre.




Je suis d’accord qu’un /48 est du gâchis mais ne pas oublier qu’une ipv4 est l’équivalent d’un /32 (donc avec un /48, on peut distribuer 65000 clients de plus qu’avec une ipv4)




Non, pas 65 000 clients de plus, mais 65 000 fois plus de clients.



Fbanzay a dit:


Quid du filtrage par-feux des box en IPV6 ? N’étant pas un spcécialiste IPV6, s’il faut refaire toutes les rgèles firewall existantes en IPV6, bonjour la galère. D’autres parts, quels risques pour les machines qui sont vulnérables (sans qu’on le sache) et addressables d’Internet. ça ne risque pas d’être la fête côté attaque et equipement zombies ? CE serait intéressant d’avoir les expériences de ceux qui ont pu l’implémenter en intégral (et qui ont eu le temps de le faire proprement :-) )




L’attaque des machines en IPV6 est considérablement moins important qu’en IPv4 pour une raison simple: sniffer les adresses prend exactement 16•10¹² plus de temps.



Donc, si tes machines n’ont pas une adresse publique connue (via un DNS par exemple), il va être difficile pour un attaquant d’aller la trouver.



Avec l’utilisation d’adresses machines aléatoire par windows et linux (sûrement MAC aussi), même un site malintentionné aura du mal à garder le lien avec les machines s’il conserve les adresses des visiteurs.



Les seules machines trouvables seront donc celles qui sont volontairement visibles et vraisemblablement bien protégées.



Pour en revenir à ta question, les renvois de port des box sont avant tout des contournements du NAT. Un vrai pare-feux gère aussi le traffic sortant et permet de gérer finement les services machine par machine. Un vrai pare-feux permet de bloquer des adresses entrantes…



Windows et linux se protègent très bien avec leurs vrais pare-feux intégrés et l’ajout d’un pare-feux supplémentaire n’est pas nécessaire pour un particulier selon moi.



La vraie menace selon moi vient des vulnérabilités des navigateurs web des machines connectées. C’est le principal vecteur d’infection et cela n’est pas lié à l’utilisation d’IPv6.



Inodemus a dit:


Double adresse routable, on peut diffuser 2 préfixes sur un seul LAN (donc 2 passerelles ?) ? Et les clients vont vraiment prendre les 2 adresses et pas s’arrêter au premier préfixe qu’ils reçoivent ?




On peut diffuser autant de préfixes que l’on veut et les machines vont se créer des adresses pour chacun d’eux.




Inodemus a dit:


Aussi, ce sont les clients dans ce cas qui choisiront quelle adresse utiliser et donc par quel WAN passer, moi je voudrais que ce soit le routeur, et si je bloque un WAN au niveau du routeur, je doute qu’ils décident d’essayer l’autre adresse.




Si un routeur disparait, son préfixe ne sera plus annoncé et les machines arrêterons de s’en servir. C’est la base pour supporter le roaming.



wanou a dit:




  • Aucun plan d’adressage n’est nécessaire: un listing d’adresses MAC et de noms de machine et hop le DNS est configuré ;

  • Aucune prise de tête en cas de changement de préfixes locaux ou globaux suite à un changement de FAI ou de fusion entre deux entreprises ;

  • Aucun serveur DHCP n’est nécessaire : c’est même totalement contre-productif ;




Je me permet de nuancer ces points



à ce jour il n’y a pas de mécanisme pour dire aux équipements de filtrage autres de faire des trucs du genre “applique cette règle sur XXXXX:réseau:hote avec xxxxx dynamique provenant du FAI.
Les ACL sont statiques dans à peu près tout les sytèmes, et il n’est pas question de scripter un truc qui arrive sans prévenir (une renumérotation FAI) et s’applique instantanément. “Désolé chef, tout le SI a planté 15 min le temps qu’ansible passe partout refaire les ACL” :mad2:



Et encore moi pour suivre le changement d’IP des hôtes.
Pour ces raisons l’usage d’un espace d’adressage PI avec du NPTv6 si on ne peut annoncer son PI en BGP est plus simple.



ça pourrait faire l’objet d’une RFC ceci étant, genre Dynamic learned prefix IPv6 based rule




Inodemus a dit:


Double adresse routable, on peut diffuser 2 préfixes sur un seul LAN (donc 2 passerelles ?) ? Et les clients vont vraiment prendre les 2 adresses et pas s’arrêter au premier préfixe qu’ils reçoivent ? Aussi, ce sont les clients dans ce cas qui choisiront quelle adresse utiliser et donc par quel WAN passer, moi je voudrais que ce soit le routeur, et si je bloque un WAN au niveau du routeur, je doute qu’ils décident d’essayer l’autre adresse.




Si les 2 RA ont le même niveau de priorité, les clients prennent le préfixe qui a le plus de bits en commun avec l’adresse de destination. Ce point précis peut être utilisé volontairement d’ailleurs. Je cite dans le guide l’exemple d’un réseau dédié à la sauvegarde, mais avec des interfaces différentes.


“L’Arcep distribue des bons points : « il n’est pas possible de désactiver IPv6 sur les box de Bouygues Telecom, Free et SFR (en FttH)”



Alors je suis sur une Box SFR en FttH et l’IPv6 est complètement désactivable !
Bon, le fait est que l’activer ne change rien et ne donne absolument pas accès à une adresse IPv6 …



Egalement, chez Free Mobile, il suffit d’activer l’IPv6 dans ses paramètres de compte et basta, problème réglé, chose que j’ai fait depuis décembre 2020 a son activation, et j’ai jamais eu de soucis (sur Android, pour une raison inconnue, l’IPv6 chez Free Mobile sur iPhone ne veut pas fonctionner)


Pour moi l’ipv6 et la freebox pop est une vraie galère ! J’utilise Openmptcprouter pour agréger la 4g et la ligne ADSL (4 mb/s -> 500ko/s).



Le player POP utilise forcément l’ipv6 pour s’authentifier chez free, si je désactive l’ipv6 sur la freebox, je n’ai plus de télé. Si j’active l’ipv6 sur OMR avec un Nexthop sur la freebox, plus de TV.



Seule solution, désactiver l’ipv6 sur OMR et sur mes ordi. En ipv4, je sors sur OMR en ipv6 sur la freebox.



Le plus agaçant dans l’histoire, c’est que les services du player pop sortent pour la plupart en ipv4.
La freebox révolution utilisait un vlan avec le serveur et tout se passait bien.



(reply:1915807:Pieryck A.)




je savais pas pour free mobile, j’ai activé l’option.
L’avantage c’est que sur Android, on peut modifier l’AP




(quote:1:mobile.free.fr)
Sous Android : Connexions / Réseaux mobiles / Nom des points d’accès
Choisissez Protocole APN IPv6 au lieu de IPv4 pour l’APN Free uniquement




wanou a dit:


L’attaque des machines en IPV6 est considérablement moins important qu’en IPv4 pour une raison simple: sniffer les adresses prend exactement 16•10¹² plus de temps.




La vraie menace selon moi vient des vulnérabilités des navigateurs web des machines connectées. C’est le principal vecteur d’infection et cela n’est pas lié à l’utilisation d’IPv6.




Merci beaucoup pour ces explications ! Donc, avec des règles basique de blocage de flux rentrant pour des sessions non déjà établies, on serait déjà protégé (si on n’héberge rien chez soi ) ?



tukutt a dit:


Seule solution, désactiver l’ipv6 sur OMR et sur mes ordi. En ipv4, je sors sur OMR en ipv6 sur la freebox.




Dans ce genre de cas avec un équipement trop lié à la box ou l’opérateur, je branche l’équipement sur la box elle-même, à côté du câble qui va vers le routeur. Ainsi la tambouille spécifique se fait sur le petit réseau local entre la box et le routeur, sans polluer mon vrai réseau local derrière le routeur, sur lequel je fais ce que je veux.



Ca implique quand-même de pouvoir en pratique relier les 2 par un câble sans passer par un switch du réseau local, peut-être que dans certains cas c’est un problème, à mettre en balance avec les inconvénients de ne pas faire comme ca.




Fbanzay a dit:


Merci beaucoup pour ces explications ! Donc, avec des règles basique de blocage de flux rentrant pour des sessions non déjà établies, on serait déjà protégé (si on n’héberge rien chez soi ) ?




Normalement oui c’est ça l’idée, après si tu héberges des trucs, tu peux toujours mettre des exceptions, par machine et/ou par ports.



Inodemus a dit:


Je ne suis pas sûr qu’on puisse séparer ce paramètre suivant les préfixes, il me semble même que sur certains clients (Android ?), on ne peut pas désactiver l’adresse aléatoire du tout.




Sous les android récents, c’est l’adresse MAC qui est rendue aléatoire par défaut (pour protéger contre le pistage), mais un réglage permet d’utiliser sa vraie adresse MAC.
Dans touts les cas, la création d’une adresse de machine android est basé sur EUI64.



Comme j’utilise le filtrage par adresse MAC sur mon wifi en plus du mot de passe, je désactive l’adresse MAC aléatoire sur mes appareils android, windows et linux.



Une adresse MAC aléatoire peut se détecter facilement car le bit de poid 2 du premier octet est à 1 quand l’adresse n’est pas issue d’un préfixe MAC obtenu via l’IEEE.



Fbanzay a dit:


Merci beaucoup pour ces explications ! Donc, avec des règles basique de blocage de flux rentrant pour des sessions non déjà établies, on serait déjà protégé (si on n’héberge rien chez soi ) ?




C’est cela en effet. C’est ce que free propose avec la freebox. Cela peut convenir si aucun service n’est proposé.



Dans les faits, cela ne convient pas à grand monde car, même si on ne possède aucun serveur ou NAS à la maison, dès que l’on fait du peer-to-peer ou toute activité qui nécessite d’ouvrir une redirection de port en IPv4, on offre un service vers l’extérieur et on est bloqué.



Il me semble également que certains jeux exigent de pouvoir être contactés car ils reposent sur des technologies P2P pour leurs mises à jour par exemple.



Je rejoint donc la grogne contre free car je pense vraiment qu’ils se moquent de leurs clients sur ce coup.



Inodemus a dit:


Ca par contre je ne veux pas, je veux que ce soit le routeur qui décide, pas les machines, car la notion de qualité de service varie en fonction du type d’utilisation. Certaines utilisations demandent du débit, d’autres un bon ping. Certaines machines sont plus génératrices de trafic que d’autres, et il n’est pas souhaité que celles-ci s’accaparent tous les WAN à la fois si plusieurs sources de trafic fonctionnent en même temps dessus, en ne laissant que des miettes et des gros pings aux autres.




Il me semble que la solution dans ce cas est de mettre en place des VLAN et de gérer des préfixes IPv6 distincts pour chaque type de traffic. C’est ce qui est en place sur les box pour séparer les flux TV du reste. Les VLAN ont été créés justement pour la gestion des priorités et de la qualité de service il me semble. Page wiki de la norme 802.1q



Il y a également la possibilité d’utiliser un switchs managés et faire en sorte que les différents profils soient isolés.



JCLB a dit:


Je me permet de nuancer ces points



à ce jour il n’y a pas de mécanisme pour dire aux équipements de filtrage autres de faire des trucs du genre “applique cette règle sur XXXXX:réseau:hote avec xxxxx dynamique provenant du FAI. Les ACL sont statiques dans à peu près tout les sytèmes, et il n’est pas question de scripter un truc qui arrive sans prévenir (une renumérotation FAI) et s’applique instantanément. “Désolé chef, tout le SI a planté 15 min le temps qu’ansible passe partout refaire les ACL” :mad2:




En écrivant cela, j’avais en tête la problématique des plans d’adressage qu’il faut refaire totalement en cas de modification de la structure du réseau en IPv4. J’avais totalement zappé les ACL.



Globalement, même si l’adaptation ne se fait pas en un claquement de doigts, le fait d’avoir des adresses machines stables quelle que soit la structure de l’entreprise avec IPv6 doit sûrement simplifier la tâche non ?



wanou a dit:


Dans les faits, cela ne convient pas à grand monde car, même si on ne possède aucun serveur ou NAS à la maison, dès que l’on fait du peer-to-peer ou toute activité qui nécessite d’ouvrir une redirection de port en IPv4, on offre un service vers l’extérieur et on est bloqué.




Il n’y a plus de nos jours d’application grand public qui demande une redirection de port obligatoire. J’ai connu l’époque où c’était le cas, mais aujourd’hui ce n’est plus nécessaire pour la majorité.



Sinon il suffit d’ajouter une exception au firewall, sauf que c’est bien plus propre et plus flexible qu’une redirection de port IPv4 puisqu’on n’a pas à tricher sur les adresses. On peut autoriser l’accès à toute une machine si on a confiance, ou rendre accessible le même port de plusieurs machines, 2 choses impossibles en redirection de port IPv4.



Après je ne sais pas si la Freebox le permet, mais pour ma part j’ai abandonné depuis longtemps les routeurs et services intégrés aux box, je ne les utilise plus que pour ce qui se rapproche le plus d’un modem.




Il me semble également que certains jeux exigent de pouvoir être contactés car ils reposent sur des technologies P2P pour leurs mises à jour par exemple.




Je n’ai jamais eu de problème avec aucun jeu, ni pour jouer, ni pour les mises à jour. Et pourtant, en IPv4, j’ai n’ai pas activé uPNP, et l’implémentation de mon NAT n’est pas sujette aux techniques courantes de traversées de NAT, donc aucune chance que je reçoive de connexions entrantes sans que je l’ai décidé.




wanou a dit:


Il me semble que la solution dans ce cas est de mettre en place des VLAN et de gérer des préfixes IPv6 distincts pour chaque type de traffic.




Et du coup je n’ai plus du tout d’adressage local, je diffuse le préfixe du FAI sur le VLAN qui lui est dédié, et je n’utilise plus que les IPs publiques, même pour les communications locales y compris inter VLAN, avec donc un routeur qui route le trafic entre les VLAN (et fait DNS local au passage) pour éviter que ça passe par les WAN ?



Pourquoi pas, il faut que je me renseigne car je n’ai pas l’habitude des VLAN, je ne vois pas encore comment les clients seraient placés dans les VLAN hors utilisation d’un switch manageable. Mais je me demande si le NPTv6 n’est pas plus simple et flexible. Je vais étudier les 2 solutions, merci pour votre aide à tous.


Chez moi, j’ai remplacé la Livebox par un routeur maison (monté moi-même) sous OPNsense.



Tout mon réseau est IPv6 et pour les services hébergés chez moi, je passe tout par le reverse proxy haproxy intégré à OPNsense (Emby et des sites web). Aucune des IPv6 publiques n’est accessible de l’extérieur sauf celle du routeur évidemment. Les redirections du reverse proxy se font sur les noms de machines locales, donc même pas besoin de connaitre leur IPv6.



Ça permet en plus de gérer le chiffrement via Let’s Encrypt au niveau du routeur, les entêtes de sécurités (CSP), le DoT et de bloquer les publicités et divers sites.



J’ai activé UPNP pour les consoles (Xbox et Switch) avec des règles spécifiques pour ces appareils et aucun problème en filaire (en Wifi, la Switch n’arrive pas se connecter, impossible de trouver pourquoi).



Edtech a dit:


Les redirections du reverse proxy se font sur les noms de machines locales, donc même pas besoin de connaitre leur IPv6.




Qui fait la correspondance entre le nom et l’IPv6 locale, et comment est-ce tenu à jour si on rajoute une machine ?


C’est automatique, comme quand tu cherches à joindre une machine sous Windows sur un réseau local par son nom (\\nomdupc dans l’explorateur par exemple) et non par son IP.



J’ai configuré mon domaine public comme nom de domaine du réseau. Du coup, si le sous-domaine est déclaré au niveau du registrar, il est connu de l’extérieur et accessible via Internet, et dans le cas contraire, la machine n’est détectable qu’en local.



Exemple :
www.mondomaine.fr est déclaré au niveau du registrar et pointe vers le reverse proxy qui redirige vers serverweb.mondomaine.fr où serverweb est le nom du serveur Ubuntu qui supporte le serveur web nginx.



Comme mondomaine.fr est déclaré comme domaine LAN au niveau d’OPNsense, toutes les machines sont joignables via nommachine.mondomaine.fr à l’intérieur du LAN.



J’ai aussi précisé que IPv6 était à préférer dans haproxy.



Edtech a dit:


C’est automatique, comme quand tu cherches à joindre une machine sous Windows sur un réseau local par son nom (\\nomdupc dans l’explorateur par exemple) et non par son IP.




Automatique oui, mais par quel moyen ? Dans l’exemple que tu cites, la résolution de nomdupc se fait soit par netbios ou mDNS (sans serveur central ni table à maintenir), soit par DNS (avec serveur central et table à maintenir). Quel est le mécanisme employé dans ton cas, et s’il y a une table à maintenir, comment est-elle maintenue ?


Aucune idée en fait, je n’ai pas cherché, ça fonctionne nativement. Côté OPNsense, UnboundDNS est installé (ça me permet justement d’activer DoT) mais je ne pense pas que ça vienne de lui. Donc peut-être simplement via NetBios.



wanou a dit:


Comme j’utilise le filtrage par adresse MAC sur mon wifi en plus du mot de passe, je désactive l’adresse MAC aléatoire sur mes appareils android, windows et linux.




Et ça fonctionne ?
J’ai essayé chez moi et malheureusement je n’arrive pas à me connecter lorsque je fait ça (filtrage adresse MAC par liste blanche et adresse MAC fixe sur android).



J’ai l’impression qu’android attend d’être connecté au wifi pour déclarer son adresse MAC (même quand elle est fixe), sauf que quand le wifi bloque les adresse MAC inconnues, bah ça fonctionne pas…



Edtech a dit:


Aucune idée en fait, je n’ai pas cherché, ça fonctionne nativement. Côté OPNsense, UnboundDNS est installé (ça me permet justement d’activer DoT) mais je ne pense pas que ça vienne de lui. Donc peut-être simplement via NetBios.




netbios est un truc purement Microsoft, et en voie de disparition, donc je ne pense pas. Donc certainement soit un DNS alimenté par un DHCPv6 si tu en as un, sinon du mDNS, qui est un peu similaire à netbios sur le principe mais en plus standard et récent.



Certains serveurs DNS permettent de fonctionner en DNS classique + mDNS sans que les clients ne s’en rendent compte, peut-être que Unbound en fait partie, je ne sais pas. En tout cas merci de ta réponse et pour la description de ton réseau.



Mihashi a dit:


Et ça fonctionne ? J’ai essayé chez moi et malheureusement je n’arrive pas à me connecter lorsque je fait ça (filtrage adresse MAC par liste blanche et adresse MAC fixe sur android).



Cela fonctionne bien avec ma Freebox et mon modem 4g NETGEAR pour tous mes appareils Android.
Tu as dû louper une étape.



Bon, j’ai re-testé, et il devait y avoir un bug qui a été corrigé depuis, car ça fonctionne sans que je fasse rien (à part activer le filtrage par liste blanche)…


Ah bah, non.
Ça fonctionne si mon téléphone se connecte lorsque le filtrage MAC est désactivé et que je re-active le filtrage.
Mais ça ne fonctionne pas s’il doit se connecter lorsque le filtrage est activé.
Et ça ne le fait que lorsque le SSID est masqué…



Edtech a dit:


Aucune idée en fait, je n’ai pas cherché, ça fonctionne nativement. Côté OPNsense, UnboundDNS est installé (ça me permet justement d’activer DoT) mais je ne pense pas que ça vienne de lui. Donc peut-être simplement via NetBios.




Cela ne peut pas être Netbios en IPv6 car le service Netbios est basé exclusivement sur du broadcast. On le voit bien en entreprise quand les Switch flashent sur tous leurs ports à intervalles réguliers. Le traffic Netbios est donc une source de congestion selon moi.



En IPv6, cette bourse est désactivé et c’est une très bonne chose. Sur mes config samba sous linux, j’ai eu du mal à virer le service NMBD qui plantait vu que j’impose I’utilisation exclusive d’une adresse IPv6.



wanou a dit:


Cela ne peut pas être Netbios en IPv6 car le service Netbios est basé exclusivement sur du broadcast.




Je ne savais pas qu’il était désactivé en IPv6. netbios était prévu pour les petits réseaux qui n’ont pas de serveur central. A partir d’une certaine taille normalement on met un serveur WINS (équivalent d’un DNS pour netbios), voire un contrôleur de domaine, qui évite le trafic broadcast netbios qui devenait vite ingérable à l’époque des hubs.



Enfin on mettait, tout ça est en perte de vitesse maintenant il me semble et un DNS local remplace bien le WINS (mais effectivement ça fait peut-être revenir le trafic netbios de faire ça, je sais pas comment les Windows modernes gèrent ce cas), mais je n’ai pas fait récemment de réseaux Windows en entreprise, peut-être que c’est toujours d’actualité.


Mon IP V4 full stack me convient très bien. Aucun intérêt à migrer.



Inodemus a dit:


Et du coup je n’ai plus du tout d’adressage local, je diffuse le préfixe du FAI sur le VLAN qui lui est dédié, et je n’utilise plus que les IPs publiques, même pour les communications locales y compris inter VLAN, avec donc un routeur qui route le trafic entre les VLAN (et fait DNS local au passage) pour éviter que ça passe par les WAN ?




Tu peux avoir plusieurs segments d’adresses locales du type ULA.
Dans un préfixe ULA, tu as une partie sur 16 bits qui correspond à un numéro de site mais tu peux t’en servir en numéro de vlan.
Du coup, tu peux servir des préfixes dédiés à chaque vlan et router les paquets de l’un à l’autre.



Mihashi a dit:


Ah bah, non. Ça fonctionne si mon téléphone se connecte lorsque le filtrage MAC est désactivé et que je re-active le filtrage. Mais ça ne fonctionne pas s’il doit se connecter lorsque le filtrage est activé. Et ça ne le fait que lorsque le SSID est masqué…




Tout se passe comme si ton téléphone continuait à utiliser des adresses mac virtuelles. En désactivant la liste blanche, tu peux regarder les logs de connexion de ton wifi et voir quelles mac tu pêche.



wanou a dit:


Tout se passe comme si ton téléphone continuait à utiliser des adresses mac virtuelles.




C’est fort probable, le réglage de l’adresse MAC aléatoire/fixe se fait par SSID, peut être que le fait que le SSID soit masqué fait qu’android ne prend pas en compte le réglage comme il faut… :craint:



wanou a dit:


Du coup, tu peux servir des préfixes dédiés à chaque vlan et router les paquets de l’un à l’autre.




Oui c’est bien ce que je pensais et que j’avais dit en-dessous. Mais reste à voir comment mettre des machines dans un VLAN et d’autres dans un autre. Avec des switch manageable je vois, sans je vois pas. Et habituellement les switchs manageables sont chers, gros et bruyants, donc si je peux éviter, c’est mieux. Et il y a le cas des clients WiFi aussi, que je ne vais pas différencier en les branchant à un switch.



Mihashi a dit:


C’est fort probable, le réglage de l’adresse MAC aléatoire/fixe se fait par SSID, peut être que le fait que le SSID soit masqué fait qu’android ne prend pas en compte le réglage comme il faut… :craint:




Je ne savais pas que le SSID pouvait influencer ce réglage. Personnellement, je le réalise dans android directement.