La Fibre
Télécom => Réseau => 
IPv6 => Discussion démarrée par: vivien le 10 octobre 2018 à 08:20:21
-
L'Arcep viens de publier son baromètre 2018 de la transition vers IPv6 : https://www.arcep.fr/cartes-et-donnees/nos-publications-chiffrees/transition-ipv6/barometre-annuel-de-la-transition-vers-ipv6-en-france.html
Arcep - Baromètre annuel de la transition vers IPv6* en France
10 octobre 2018
(https://lafibre.info/images/ipv6/201810_arcep_barometre_ipv6_00.png)
* L’Arcep précise que les constats et travaux évoqués dans le présent document concernent uniquement le réseau internet et ne s’appliquent pas à l’interconnexion privée entre deux acteurs, notamment l’interconnexion des réseaux de deux opérateurs pour la terminaison d’appel vocal en mode IP.
1/ Accélérer la transition vers IPv6 : un enjeu majeur de compétitivité et d’innovation
L’IPv4, pour Internet Protocol version 4, est utilisé depuis 1983 pour permettre à internet de fonctionner : chaque terminal sur le réseau internet (ordinateur, téléphone, serveur etc.) possède une adresse IPv4. Le protocole IPv4, utilisé sur internet dès ses débuts, offre un espace d'adressage de près de 4,3 milliards d'adresses IP. Or, le succès d'internet, la diversité des usages et la multiplication des objets connectés ont eu comme conséquence directe l'épuisement progressif des adresses IPv4, certaines régions du monde étant touchées plus que d'autres. Les quatre principaux opérateurs français (Bouygues Telecom, Free, Orange, SFR) ont déjà affecté entre environ 88% et 99% des adresses IPv4 qu’ils possèdent, à fin juin 2018*.
Les spécifications d’IPv6 ont été finalisées en 1998. Elles intègrent des fonctionnalités pouvant renforcer la sécurité par défaut et optimiser le routage. Surtout, IPv6 offre une quasi-infinité d’adresses : 667 millions d’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, d’abord en parallèle d’IPv4 (phase de cohabitation), puis, quand tous les acteurs auront migré, en remplacement total d’IPv4 (phase d’extinction).
La transition vers le protocole IPv6 a démarré en 2003. Cependant, en 2018, internet n’en est encore qu’au début de la phase de cohabitation.
La lenteur de la migration peut d’une part provoquer le dysfonctionnement de certaines catégories de services sur internet (systèmes de contrôle de maison connectée, jeux en réseau, etc.) du fait de systèmes de partage d’adresse IPv4 entre plusieurs clients mis en place pour faire face à la pénurie. D’autre part, elle est susceptible d’ériger une barrière à l’entrée à l’encontre des nouveaux acteurs du marché. En effet, IPv4 reste nécessaire tant que toute la chaîne technique d’internet n’aura pas migré entièrement vers IPv6. Dans le cas contraire, un site web qui ne serait pas en mesure d’avoir une adresse IPv4 ne sera pas accessible aux clients des FAI qui ne proposent pas d’IPv6. Or la date de fin de disponibilité de l’IPv4 en Europe approche. Estimée à fin 2021, elle entraîne d’ores et déjà une augmentation significative du prix des adresses IPv4, devenues les ressources rares de l’internet du XXIe siècle. Ce prix élevé augmente le coût d’entrée des nouveaux acteurs et engendre un risque de voir se développer un internet scindé en deux, IPv4 d’un côté et IPv6 de l’autre.
Face à cette pénurie annoncée et aux risques encourus, la transition vers un nouveau protocole de communication sur internet apparaît comme un enjeu majeur de compétitivité et d’innovation.
Évaluation et estimation du stock d'adresses IPv4 disponible :
(https://lafibre.info/images/ipv6/201810_arcep_barometre_ipv6_01.png)
* Données recueillies par l'Arcep auprès de FAI conformèment à la décision n°2018-0268.
-
2/ Une multitude d’acteurs, à différents degrés de transition
La migration vers IPv6 du réseau internet doit concerner tous les maillons de la chaîne technique afin d’assurer un fonctionnement de bout en bout du protocole internet.
Afin d'évaluer l'état de déploiement du protocole IPv6 en France de différents acteurs impliqués dans la transition, l'Arcep a retenu plusieurs indicateurs. Ces indicateurs sont calculés soit à partir des données collectées par l’Arcep conformèment à la décision n°2018-0268, soit à partir de données tierces* :
• Fournisseurs d’accès à internet (FAI) fixe :
◦ taux de clients IPv6-ready (ou « compatibles ») ;
◦ politique d’activation d’IPv6 dans les box ;
◦ taux de clients activés en IPv6.
• Opérateurs mobiles :
◦ taux de clients IPv6-ready ;
◦ taux de clients activés en IPv6.
• Hébergeurs et fournisseurs de contenu :
◦ taux de serveurs activés en IPv6 ;
◦ taux de nouveaux serveurs activés en IPv6 ;
◦ taux de sites web les plus visités en France accessibles en IPv6;
◦ taux de pages web les plus visitées en France accessibles en IPv6 (contenus IPv6) ;
◦ taux de sites web accessibles en IPv6 sur les sites web en .fr, .re .pm .yt .tf et .wf ;
◦ taux d’hébergement mails en IPv6 sur les sites web en .fr, .re .pm .yt .tf et .wf.
• Infrastructures DNS :
◦ taux de serveurs DNS accessibles en IPv6 sur les sites web en .fr, .re .pm .yt .tf et .wf.
• Équipementiers :
◦ compatibilité IPv6 des équipements (routeurs, etc.) commercialisés.
• Transitaires :
◦ taux de transitaires annonçant des routes IPv6 ;
◦ taux de transitaires annonçant des routes IPv6, pondéré par leur nombre de routes.
• Terminaux :
◦ Capacité des systèmes d’exploitation à fonctionner en IPv6.
Ces indicateurs complèmentaires permettent d'obtenir une vision d'ensemble de l'état des déploiements du protocole IPv6.
État d’avancement de la transition vers IPv6 au niveau des différents maillons de la chaîne technique :
(https://lafibre.info/images/ipv6/201810_arcep_barometre_ipv6_02.png)
* Cf. sources exactes dans les parties afférentes à chaque acteur.
-
3/ Fournisseurs d’accès à internet fixe (grand public)
Pour qu’une ligne fixe èmette et reçoive en IPv6, quatre conditions doivent être réunies :
• le réseau fixe utilisé doit être compatible IPv6 ;
• la box utilisée doit être compatible matériellement avec IPv6 et disposer d’un logiciel embarqué (firmware) capable de gérer ce protocole. Si la plupart des box proposées par les opérateurs en 2018 sont compatibles avec IPv6, certaines d’entre elles n’ont toujours pas de firmware adapté à l’IPv6.
Lorsque le réseau et la box sont compatibles IPv6, le client est dit « IPv6-ready » (cf. tableau ci-dessous).
• l’opérateur doit configurer à distance la box pour qu’elle utilise IPv6 (cf. tableau ci-dessous). Si le client est IPv6-ready mais que l’opérateur n’a pas activé IPv6, le client peut configurer lui-même sa box manuellement pour devenir un client « activé ». Cependant, la grande majorité des utilisateurs ne réalisant pas cette action spontanèment, une action de la part du FAI permettrait de faciliter la migration;
• le système d’exploitation du terminal utilisé doit être compatible et activé en IPv6 (cf. section « Terminaux » ci-après).
Taux de clients du réseau fixe IPv6-ready et politique d’activation des box des FAI de plus de 10 000 clients proposant IPv6 en France :
(https://lafibre.info/images/ipv6/201810_arcep_barometre_ipv6_03.png)
La politique d’activation d’IPv6 sur les box des principaux opérateurs explique la différence entre le taux de clients disposant d’IPv6 (IPv6-ready) et le taux de clients effectivement activés en IPv6 (qui èmettent et reçoivent du trafic IPv6).
Taux de clients du réseau fixe activés en IPv6 des principaux opérateurs en France :
(https://lafibre.info/images/ipv6/201810_arcep_barometre_ipv6_04.png)
Taux de clients du réseau fixe activés en IPv6 des opérateurs alternatifs et DROM en France :
(https://lafibre.info/images/ipv6/201810_arcep_barometre_ipv6_05.png)
Les quatre principaux opérateurs ont par ailleurs fourni leur prévision des taux des clients du réseau fixe activés en IPv6 à horizon un et trois ans.
Prévisions des taux de clients du réseau fixe activés en IPv6 des principaux opérateurs en France :
(https://lafibre.info/images/ipv6/201810_arcep_barometre_ipv6_06.png)
Alors que l’épuisement des adresses IPv4 est prévu à fin 2021, certains acteurs n’envisagent pas un déploiement sur leurs réseaux fixes qui permettrait de répondre à la pénurie à moyen terme, ce qui, comme indiqué plus haut, apparaît problématique.
-
4/ Opérateurs mobiles (grand public)
Pour qu’une ligne mobile èmette et reçoive du trafic en IPv6, trois conditions doivent être réunies :
• le réseau mobile utilisé doit être compatible IPv6, c’est-à-dire que l’Access Point Name ou APN doit être capable de gérer le protocole IPv6 (cf. tableau ci-dessous) ;
• le système d’exploitation du terminal doit être compatible IPv6 (cf. section « Terminaux » ci-après). Si c’est le cas de la quasi-totalité des smartphones récents, de nombreux modem-routeurs 4G ne sont toujours pas compatibles IPv6.
• l’opérateur doit activer à distance le terminal mobile pour qu’il utilise IPv6. Sous Android, il est possible de configurer manuellement l’APN en IPv6. Cependant, la grande majorité des utilisateurs n’activant pas spontanèment IPv6, une action de la part du FAI permettrait de faciliter la migration. L’activation manuelle n’est pas permise par un iPhone ;
Taux de clients sur les réseaux mobiles compatibles IPv6 par APN des principaux opérateurs en France :
(https://lafibre.info/images/ipv6/201810_arcep_barometre_ipv6_07.png)
La politique d’activation d’IPv6 des principaux opérateurs explique la différence entre le taux de clients disposant d’IPv6 et le taux de clients effectivement activés en IPv6 (qui èmettent et reçoivent du trafic IPv6).
Taux de clients du réseau mobile activés en IPv6 des principaux opérateurs en France :
(https://lafibre.info/images/ipv6/201810_arcep_barometre_ipv6_08.png)
Concernant le plan de transition vers l’IPv6 du réseau mobile des différents opérateurs à un et à trois ans :
Prévisions des taux de clients du réseau mobile activés en IPv6 des principaux opérateurs en France :
(https://lafibre.info/images/ipv6/201810_arcep_barometre_ipv6_09.png)
De façon encore plus marquée que sur les réseaux fixes, le rythme des déploiements futurs de l’IPv6 de la part des opérateurs mobiles risque fort de ne pas permettre de répondre au problème de pénurie générale d’adresses IPv4.
Plus particulièrement, en ce qui concerne les principaux opérateurs télécom en France :
• Si 100% des clients SFR sont déjà compatibles sur le xDSL et le FTTH (0% sur le câble), moins de 1% d’entre eux sont activés - c’est-à-dire èmettent et reçoivent effectivement en IPv6. Les activations à venir, bien qu’en hausse par rapport aux dernières annonces de l’opérateur, demeurent très insuffisantes (25-30% à mi-2021). Une grande majorité des clients n’activant pas IPv6 manuellement, l’Arcep invite SFR à réaliser cette activation par défaut comme la plupart des autres opérateurs. Quant aux réseaux mobiles : SFR prévoit moins de 10% de clients activés à mi-2021.
• L’Arcep note les efforts de déploiement de Bouygues Telecom sur les réseaux mobiles, mais regrette la chute des prévisions de migration sur les réseaux fixes : 40 à 50% de clients activés sont prévus à horizon mi-2021, contre 75 à 85% annoncés à fin 2020 dans le précédent baromètre.
• Sur les réseaux fixes, les taux actuels de clients activés de Free et Orange sont relativement élevés (respectivement 50% et 45%), mais les projections sur le même indicateur à mi-2021 ne permettent pas d’achever la transition à moyen terme (entre 75 et 85% pour les deux FAI). Sur les réseaux mobiles, le taux de clients activés prévu par Orange à mi-2021 est en hausse mais demeure limité (25-35%) ; l’Arcep regrette que Free Mobile n’ait pas été en mesure de lui transmettre des prévisions.
-
5/ Hébergeurs et les fournisseurs de contenu
Afin qu’IPv6 soit disponible au niveau d’un hébergeur, cinq conditions doivent être réunies :
• le réseau de l’hébergeur utilisé doit être compatible IPv6 ;
• le système d’exploitation du serveur doit être compatible IPv6 et sa pile IPv6 activée. C’est le cas de tous les systèmes d’exploitation des serveurs utilisés actuellement ;
• l’hébergeur doit préconfigurer le serveur pour utiliser un adressage IPv6 ;
Lorsque ces trois conditions sont réunies, l’hébergeur peut alors activer IPv6 au niveau de ses serveurs (cf. graphe de la partie 1).
• le fournisseur de contenu doit utiliser des applications serveurs (web, mail, etc.) gérant le protocole IPv6. C’est aujourd’hui majoritairement le cas par défaut ;
• le fournisseur de contenu doit configurer les DNS avec un enregistrement IPv6, afin que le nom de domaine propose d’utiliser IPv6.
Quand toutes ces conditions sont réunies, le service hébergé peut être accessible en IPv6 (cf. graphes de la partie 2).
Ainsi, contrairement à un fournisseur d’accès à internet qui peut activer à distance IPv6 sans nécessiter d’actions de la part de son client (le consommateur final), une ou plusieurs actions du client d’un hébergeur (le fournisseur de contenu) sont nécessaires pour que l’IPv6 soit utilisable de bout en bout.
5.1/ Infrastructure d’hébergement
L’Arcep tient à remercier les hébergeurs qui ont répondu à cette enquête facultative. On notera que la cartographie ainsi dressée n’est pas représentative de l’écosystème, les acteurs ayant souhaité participer correspondant probablement à ceux les plus avancés dans la transition.
Taux des serveurs activés en IPv6 de certains hébergeurs en France :
(https://lafibre.info/images/ipv6/201810_arcep_barometre_ipv6_10.png)
Les prévisions fournies ci-après se limitent au pourcentage de nouveaux serveurs commercialisés mi-2019 ou mi-2021 et livrés avec une IPv6 activée par défaut, l’hébergeur ne pouvant pas forcer un serveur déjà commercialisé à utiliser IPv6.
Prévisions des taux de nouveaux serveurs livrés avec une IPv6 activés par défaut pour certains hébergeurs en France :
(https://lafibre.info/images/ipv6/201810_arcep_barometre_ipv6_11.png)
Dans la suite de cette section, nous nous intéressons à deux types de services applicatifs : le web et le mail.
-
5.2/ Applications serveur
5.2.1/ Hébergement web
Les hébergeurs de sites web 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 26% sont accessibles en IPv6*. On considère un site comme accessible en IPv6 lorsqu’il dispose d’un enregistrement IPv6 (« AAAA ») au niveau du serveur DNS.
Il est à noter que le taux de pages web accessibles en IPv6 (contenus IPv6) est significativement plus élevé (61%*). En effet, les petits fournisseurs de contenu proposent souvent des sites web (au nombre de pages consultées généralement faible) non compatibles avec IPv6.
*Cisco 6lab au 28/09/2018. Données sur le Top 731 d’Alexa en France
(https://lafibre.info/images/ipv6/201810_arcep_barometre_ipv6_12.png)
Le taux de sites disponibles en IPv6 est uniquement de 16% lorsque l’on considère les 3 millions de sites web en .fr, .re .pm .yt .tf et .wf*. Ce pourcentage est en augmentation depuis 2015, mais le rythme de cette évolution semble loin de pouvoir permettre une transition complète d’ici fin 2021.
* Données Afnic
Évolution du taux des sites web accessibles en IPv6 sur les sites web .fr, .re .pm .yt .tf et .wft :
(https://lafibre.info/images/ipv6/201810_arcep_barometre_ipv6_13.png)
5.2.2/ Hébergement mail
La transition des hébergeurs mail connaît également un très fort retard : seuls 5,2% des serveurs mail sont à ce jour adressés en IPv6 sur l’intégralité des .fr .re .pm .yt .tf et .wf. Il est à noter qu’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*.
* Données Afnic, juillet 2018
Taux d’hébergement mail en IPv6 sur les noms de domaine .fr, .re .pm .yt .tf et .wf :
(https://lafibre.info/images/ipv6/201810_arcep_barometre_ipv6_14.png)
-
6/ Infrastructure DNS :
L’infrastructure DNS permet de traduire un nom de domaine, par exemple www.arcep.fr, en une adresse IP. C’est aujourd’hui le secteur le plus en avance dans la transition vers IPv6 avec 70% des serveurs autoritaires* supportant IPv6. Environ 66%** d’entre eux garantissent une résilience équivalente à celle d’IPv4 (niveau de redondance identique). Il est à noter que l’hébergement de DNS autoritaires est concentré sur un nombre restreint d’acteurs***.
* Un DNS autoritaire est un serveur DNS qui fait autorité pour un domaine, c'est-à-dire qu’il détient l’information quant à la résolution d’adresse pour le domaine, données Afnic, juillet 2018.
** Données Afnic, juillet 2018.
*** Observatoire de la résilience de l’Internet français 2014 de l’ANSSI.
Taux de serveurs DNS accessibles en IPv6 sur les noms de domaine .re .pm .yt .tf et .wf :
(https://lafibre.info/images/ipv6/201810_arcep_barometre_ipv6_15.png)
7/ Équipementiers
Les principaux équipementiers (Cisco, Juniper et Nokia) ont indiqué que toutes leurs solutions réseau commercialisées (routeurs, etc.) étaient systématiquement compatibles IPv6*.
Cette compatibilité ne garantit pas nécessairement un acheminement du trafic en IPv6, une configuration des routes IPv6 au niveau des routeurs par chaque acteur (FAI, hébergeur, transitaire etc.) étant nécessaire.
* Questionnaire Arcep de 2016
8/ Transitaires
27% des transitaires* opérant sur le territoire français peuvent gérer du trafic IPv6 (65 transitaires sur 240). Ce taux, pondéré par le nombre de clients de chaque transitaire, atteint environ 71% ; une grande partie des transitaires de petite taille ne gérant pas IPv6**.
* La méthodologie retenue par 6lab de Cisco consiste à considérer comme un « transitaire » tous les AS qui apparaissent sur un chemin AS de la table BGP et qui ne sont pas l'origine AS ou la destination.
** 6lab Cisco au 28/09/2018
(https://lafibre.info/images/ipv6/201810_arcep_barometre_ipv6_16.png)
-
9/ Terminaux
Pour qu’un terminal èmette et reçoive du trafic en IPv6, le système d’exploitation (Operating System - OS) doit être compatible IPv6, et IPv6 doit être activé par défaut.
Sur de nombreux objets connectés (système d’alarme, télévisions, etc.), IPv6 est intégré dans l’OS mais n’est pas activé par le constructeur de l’objet connecté.
Seules les versions de systèmes d’exploitation préinstallées sur des ordinateurs, tablettes ou smartphones à destination du grand public et encore maintenues (mises à jour de sécurité, etc.) sont étudiées ci-dessous.
Tous ces systèmes d’exploitation sont compatibles avec IPv6 qui est activé par défaut depuis de nombreuses années (IPv6 a été par exemple activé par défaut sous Windows depuis Windows Vista en 2007). Cependant, certains systèmes d’exploitation ne peuvent pas fonctionner correctement en IPv6 en absence d’IPv4 (i.e. dans le cas où IPv6 est le seul protocole disponible) car ils n’intègrent pas le support de la RFC 8106 Neighbor Discovery Protocol RDNSS.
(https://lafibre.info/images/ipv6/201810_arcep_barometre_ipv6_17.png)
-
10/ Où en est la France ?
Le taux d’utilisation d’IPv6 représente le pourcentage d’utilisateurs en IPv6 mesuré au niveau d’un hébergeur (qui propose déjà IPv6). Il donne donc une idée de l’état de la transition des terminaux, des FAI ou opérateurs mobiles, ainsi que des autres intermédiaires techniques lorsque l’hébergeur en question passe par des transitaires.
Ce taux tel qu’observé par Google atteint à ce jour environ 23% en France.
Évolution du taux d'utilisation d'IPv6 en France, tel qu'observé par Google (Source: Cisco - 6Lab) :
(https://lafibre.info/images/ipv6/201810_arcep_barometre_ipv6_18.png)
Les serveurs de Google étant habituellement situés au plus proche du client final, cet indicateur ne donne qu’une vision partielle de la situation réelle (le taux de transitaires empruntés utilisant IPv6 influe directement sur le nombre de connexions IPv6 initiées en France à destination d’internet mais n’est que marginalement pris en compte dans cet indicateur). Il est par ailleurs important de connaître le nombre d’hébergeurs effectivement capables de proposer IPv6, via le taux de sites web (ou de « contenus ») accessibles en IPv6.
La carte ci-dessous propose un comparatif entre les différents pays du monde sur les trois indicateurs mentionnés ci-dessus. En Europe, la France se situe dans la moyenne des pays, ni en tête de file (comme par exemple la Belgique), ni en queue de peloton.
État de la transition IPv6 dans le monde au 08 octobre 2018 (Source: Cisco - 6Lab) :
(https://lafibre.info/images/ipv6/201810_arcep_barometre_ipv6_19.png)
Source : Arcep - Baromètre 2018 de la transition vers IPv6 en France (https://www.arcep.fr/cartes-et-donnees/nos-publications-chiffrees/transition-ipv6/barometre-annuel-de-la-transition-vers-ipv6-en-france.html) le 10 octobre 2018.
-
Communiqué de presse Arcep : https://www.arcep.fr/actualites/les-communiques-de-presse/detail/n/transition-vers-ipv6.html
-
Tant qu'IPv6 ne sera pas correctement expliqué, il sera hors de question que je l'active sur mon modem SFR.
D'ailleurs, on ne sait toujours pas comment sécuriser ses périphériques, c'est totalement différent d'IPv4 (contrairement à ce que certains veulent faire croire). Donc, l'ARCEP peut bien se rouler par terre et ceux qui savent garder leurs connaissances pour eux, IPv6 ne décollera jamais vraiment.
Et on sait tous qu'il y a encore de la réserve en IPv4 pour encore de longues années.
-
Tant qu'IPv6 ne sera pas correctement expliqué, il sera hors de question que je l'active sur mon modem SFR.
Ça veut dire quoi pour toi ? :o
-
D'ailleurs, on ne sait toujours pas comment sécuriser ses périphériques, c'est totalement différent d'IPv4 (contrairement à ce que certains veulent faire croire).
La box a déjà un firewall hein… Et ne t’en déplaise, c’est exactement la même chose qu’en IPv4.
-
Et on sait tous qu'il y a encore de la réserve en IPv4 pour encore de longues années.
(https://media.giphy.com/media/3oz8xIroX3rtDKV1sY/giphy.gif)
-
La box a déjà un firewall hein… Et ne t’en déplaise, c’est exactement la même chose qu’en IPv4.
:o :o
-
Ça veut dire quoi pour toi ? :o
Je ne réponds qu'à toi (car les autres réponses posent peu ou prou la même question) : pour vous, c'est limpide, archi limpide. Pour beaucoup d'autres personnes, ça ne l'est pas du tout.
Configurer mon routeur en IpV4, je n'ai aucun souci. Très simple quand on connaît a minima le fonctionnement d'IPv4 (une adresse IP fixe externe et ton réseau local interne). En Ipv6, je n'ai rien compris du tout (je crois que chaque périphérique a sa propre adresse externe ou quelque chose du genre).
Donc, me certifier que c'est exactement la même chose, j'ai un gros doute quand même (sauf pour les personnes versées dans les méandres des architectures réseau).
D'ailleurs, l'intonation de certaines réponses me confortent dans mon assertion : ceux qui savent ne partagent pas leur savoir mais le conservent pour eux en prenant de haut ceux qui ne comprennent pas. C'est une façon de voir les choses, je ne la partage pas. Et cela contribue à freiner l'expansion d'IPv6. Et ces mêmes viennent ensuite râler du taux faible d'adoption d'IPv6.
J'ai posé à plusieurs reprises des questions sur IPv6 sur LaFibre, aucune réponse n'a été apportée malheureusement. En tout cas aucune permettant une meilleure compréhension d'IPv6 et son utilisation en réseau interne.
J'ai regardé ce forum : https://www.developpez.net/forums/d1438911/systemes/reseaux/architecture/fonctionnement-ipv6-reseau-local/
Hé bien, on y retrouve toutes les craintes que la plupart expose.
-
Bah, on est hors sujet, mais le tldr, c'est que ipv6 se comporte exactement comme ipv4. Et que tu ne connais pas ipv4.
Lance un autre sujet si tu veux continuer cette discussion
-
Ça me parait quand même un peu exagéré de dire ça. Il y a quand même une différence importante liée au fait qu'actuellement dans un contexte grand public IPv4 implique du NAT au niveau du réseau local alors que ce n'est pas le cas avec IPv6.
-
Ça me parait quand même un peu exagéré de dire ça. Il y a quand même une différence importante liée au fait qu'actuellement dans un contexte grand public IPv4 implique du NAT au niveau du réseau local alors que ce n'est pas le cas avec IPv6.
Exactement
Ce n'est pas de l'ipv4, qui pour rappel, permet une communication point à point au niveau 3
-
96 bits de plus, rien de magique et on supprime l’infamant NAT.
L'obtention d'une IP se fait avec plus de possibilités mais rien d'insurmontable. Pour moi le gros point noir est que beaucoup veulent conserver leurs vieux réflexes acquis en IPv4 ce qui n'est pas la bonne solution.
-
Bah, on est hors sujet, mais le tldr, c'est que ipv6 se comporte exactement comme ipv4. Et que tu ne connais pas ipv4.
Lance un autre sujet si tu veux continuer cette discussion
Je donnais mon ressenti sur le déploiement d'IPv6 et tu te comportes comme je l'expliquais (condescendant et méprisant). Si cela ne t'intéresse pas, va faire un tour sur un autre sujet ::)
-
IPv6 se comporte comme IPv4, mais la majorité des gens utilisent IPv4 incorrectement. En IPv6, chaque appareil a une IP, donc plus besoin de port-forwarder :-)
Ce n'est pas la faute des utilisateurs si ils utilisent mal v4, juste qu'on a tous pris des mauvaises habitudes pendant des années.
-
96 bits de plus, rien de magique et on supprime l’infamant NAT.
L'obtention d'une IP se fait avec plus de possibilités mais rien d'insurmontable. Pour moi le gros point noir est que beaucoup veulent conserver leurs vieux réflexes acquis en IPv4 ce qui n'est pas la bonne solution.
Exactement ! Je veux bien changer de réflexe si on m'explique comment en changer et commencer à basculer vers IPv6. ;)
Cela rejoint aussi l'argumentation de Hugues.
Donc, oui il faut réapprendre à utiliser IPv6 et laisser IPv4 derrière mais qui va se lancer dans cette bataille ?
-
Déjà, tu peux commencer par arrêter de raisonner en IP privées et publiques, et partir du principe que toutes les IP sont publiques !
Avec les changements que ca implique côté Firewall, DNS, ce genre de choses...
-
Déjà, tu peux commencer par arrêter de raisonner en IP privées et publiques, et partir du principe que toutes les IP sont publiques !
Avec les changements que ca implique côté Firewall, DNS, ce genre de choses...
Vi, ça je l'avais bien compris. Cela signifie donc un très gros travail par la suite.
Je pense que je remonterais un ancien sujet sur IPv6 prochainement.
-
J'imagine pas vraiment, j'ai appris IP avec v6, mais si tu le dis.. ;)
-
K-L je plussoie tes commentaires.
Je suis plutôt comme toi.
Je connais les grands principes théoriques de l'IPv6, mais je suis incapable de l'appliquer.
Globalement, le NAT c'est peut-être le mal, mais savoir que ta box fait firewall pour tout ton réseau c'est, je pense, ce qui rassure la majorité des gens.
Si tu as besoin d'accéder depuis internet à un ou plusieurs services, tu fais une petite redirection de port et au pire, tu sais que tu n'as que ce service à monitorer pour vérifier ta sécurité.
Demain avec ipv6, je ne me vois pas gérer la sécurité de tous les périphériques qui choppent une ipv6 public.
Encore moins, si je me retrouve face à une caméra chinoise avec un système complètement fermé.
Pour fini, le fait que avec ipv6 tu te retrouves avec plusieurs ipv6 pour un même périphérique (le coup des ipv6 temporaire), ben ça n'aide pas à la compréhension.
Les vieux réflexes ont la vie dure ...
-
Dans ce cas, suffit de mettre un Firewall sur la box... Comme maintenant en fait
-
Donc, oui il faut réapprendre à utiliser IPv6 et laisser IPv4 derrière mais qui va se lancer dans cette bataille ?
Je dirais que dans les utilisateurs d'internet, tu as 3 groupes.
- 90% d'utilisateurs lambda qui ne savent pas ce qu'est une IP. Pour eux, passer à IPv6 sera transparent
- 9,9% de "geeks" ou utilisateurs éclairés qui ont un NAS, font du port forwarding, etc... C'est cette catégorie qui doit tout réapprendre
- 0,1% d'experts sys/net qui savent exactement comment faire marcher tout ça et qui font de la v6 only et ce genre de folies
Je continue à penser qu'apprendre IPv6 sera absolument nécessaire et bénéfique pour la seconde catégorie.
-
La box a déjà un firewall hein… Et ne t’en déplaise, c’est exactement la même chose qu’en IPv4.
C'est demandé par la RFC 7084 : Basic Requirements for IPv6 Customer Edge Routers
Cf http://www.bortzmeyer.org/7084.html pour avoir un résumé en Français.
Tant qu'IPv6 ne sera pas correctement expliqué, il sera hors de question que je l'active sur mon modem SFR.
J'aime bien la solution de Coriolis :
1/ Firewall IPv6 qui filtre par défaut les flux entrants
2/ Impossibilité de désactiver IPv6
-
On peut aussi remarquer que chez certains FAI qui proposent de l'ipv6 aux particuliers, les peering ipv6 sont parfois mois bons.
Un exemple parmi d'autres : Les lenteurs chez Orange vers Facebook et les CDN utilisés par Facebook via IPv6.
C'est certes résolu depuis, mais c'est juste un exemple.
Avec comme conséquence, les clients qui râlent et qui désactivent IPv6 au niveau de la box du FAi au lieu de désactiver IPv6 dans le navigateur.
-
Dans ce cas, suffit de mettre un Firewall sur la box... Comme maintenant en fait
Tu es sûr que par défaut, toutes les box des opérateurs compatibles IPv6 bloquent tous les ports entrants IPv6 ?
Personnellement, je n'en suis pas sûr, et il faudra que je vérifie dans mon cas, pour Free.
La différence, c'est quand même que tous les périphériques ont une adresse publique en IPv6, et que le principe général est une connectivité de bout en bout en IPv6.
Maintenant, je ne suis pas plus inquiet que cela. L'IPv6 étant encore très rare sur Internet, toutes les attaques dont j'ai pu connaitre l'existence se faisaient en IPv4, et les serveurs C&C ont une adresse IPv4, et pas IPv6, à ma connaissance.
En tout cas, il est clair que pour les 9.9% de personnes qui connaissent l'existence d'IPv6, et ont des services hébergés (NAS...), l'incertitude sur le fait que leur serveur puissent être attaqué directement de l'extérieur les fait désactiver l'IPv6, ou plutôt, ne pas l'activer, par principe de précaution.
-
La Freebox ne bloque rien en IPv6 elle ne fait pas firewall. La Freebox permet d'exploiter tout le préfix fourni (un /60)
La Livebox fait firewall en IPv6 mais ne permet pas d'ouvrir totalement une IPv6 (on peut ouvrir que TCP ou UDP sur un port donné). La livebox ne permet pas d'exploiter tout le prefix IPv6 fourni (un /56).
bref les 2 acteurs français majeurs en IPv6 grand public sont a l'opposé complet sur la facon de gerer IPv6 dans leur box... ca n'aide pas vraiment a généraliser et démocratiser IPv6.
Peut-être que l'ARCEP doit intervenir et imposer un minimum de chose a ce niveau ?
-
Voilà ce qui engendrent des inquiétudes (en tout cas pour moi).
Chez Free, pas de firewall, tu sors à poil.
Chez Orange, tu ne sembles pas pouvoir faire ce que tu veux donc tu perds un des avantages significatifs de l'ipv6.
En tout cas, il est clair que pour les 9.9% de personnes qui connaissent l'existence d'IPv6, et ont des services hébergés (NAS...), l'incertitude sur le fait que leur serveur puissent être attaqué directement de l'extérieur les fait désactiver l'IPv6, ou plutôt, ne pas l'activer, par principe de précaution.
Je préfère surveiller mes qqs ports ouverts et faire confiance au firewall ipv4 que de remettre en question ton mon petit lan au changement d'opérateur ...
-
Chez Free, pas de firewall, tu sors à poil.
IPv6 intègre des mécanismes pour éviter cela, justement. (IPv6 Privacy Extensions)
-
C'est à dire ? Et comment cela s'applique aux box ?
-
Maintenant, je ne suis pas plus inquiet que cela. L'IPv6 étant encore très rare sur Internet, toutes les attaques dont j'ai pu connaitre l'existence se faisaient en IPv4, et les serveurs C&C ont une adresse IPv4, et pas IPv6, à ma connaissance.
IPv6 c’est environ le quart du trafic en Europe et plus de la moitié aux US.
-
C'est à dire ? Et comment cela s'applique aux box ?
Automatique. Partout.
L'IPv6 que tu utilises pour naviguer sur internet n'est pas celle qui porte des services et change régulièrement, ce qui limite grandement le risque d'attaque sans firewall
-
J'ai pas lu qu'il y avait eu de nombreux bugs justement sur l'IPv6 Privacy Extensions ?
Genre initialement ça devait être généré avec la MAC, puis ça marchait pas assez bien donc ça a changé, mais au final ce n'est pas si aléatoire ?
Perso, je trouve que c'est le foutoir ...
-
C'est aussi le foutoir parce que des gens cherchent à faire de la sécurité applicative au niveau 3
Étrangement, ça ne fonctionne pas trop.
-
L'IPv6 que tu utilises pour naviguer sur internet n'est pas celle qui porte des services et change régulièrement, ce qui limite grandement le risque d'attaque sans firewall
Pour empêcher le tracking, ok mais en termes d'attaques sur des services à l'écoute comportant des failles, n'est-ce pas une fausse illusion de sécurité par rapport à un firewall en entrée de réseau (ou un NAT sans port forwarding) ?
-
Chez Orange, tu ne sembles pas pouvoir faire ce que tu veux donc tu perds un des avantages significatifs de l'ipv6.
Par défaut, le firewall de la Livebox bloque les connexions entrantes (IPv4 et IPv6) sauf si une règle de NAT/PAT existe.
C'est d'ailleurs le comportement que devraient avoir toutes les box, mais je m'avance peut-être un peu là.
-
Par défaut, le firewall de la Livebox bloque les connexions entrantes (IPv4 et IPv6) sauf si une règle de NAT/PAT existe.
C'est d'ailleurs le comportement que devraient avoir toutes les box, mais je m'avance peut-être un peu là.
Et si tu souhaites ouvrir autre chose que TCP/UDP ? ou ouvrir tous les ports TCP sur une IP car service avec ports dynamiques ?
-
Pas possible de mettre en DMZ-like en ipv6 sur la Livebox ?
-
Et si tu souhaites ouvrir autre chose que TCP/UDP ? ou ouvrir tous les ports TCP sur une IP car service avec ports dynamiques ?
On parle de cas qui ne concernent plus la majorité du grand public qui souhaite juste s'assurer que son réseau sera toujours protégé un minimum par sa box (cf. inquiétudes de certains).
Tu auras toujours (j'imagine) la possibilité d'avoir des équipements en DMZ (sans firewall).
PS : Je viens de regarder, la DMZ est destinée à être utilisée pour de l'IPv4. Par contre, tu peux utiliser le firewall personnalisé pour l'IPv6.
J'imagine que si tu as des besoins particuliers (cf. Thornhill), tu peux bien personnaliser des règles de firewall. ;)
-
J'imagine que si tu as des besoins particuliers (cf. Thornhill), tu peux bien personnaliser des règles de firewall. ;)
Ce qui n'est pas forcèment rassurant et à la portée de l'utilisateur de base, en IPv6.
-
Ce qui n'est pas forcèment rassurant et à la portée de l'utilisateur de base, en IPv6.
Je ne vois pas en quoi. L'utilisateur de base n'aura rien à faire de particulier en IPv6, il utilisera le paramétrage par défaut du firewall qui bloque les requêtes entrantes (donc initiées depuis l'extérieur), le flux initié de l'intérieur sera autorisé (surf, jeux en ligne, etc.). C'est déjà ce qui est en place sur les Livebox en IPv4 (je ne m'avance pas pour les autres opérateurs).
Sinon, je ne vois pas en quoi ajouter une règle de firewall est plus compliqué qu'ajouter une règle de NAT/PAT en IPv4... Et c'est obligatoire aujourd'hui en IPv4 pour les besoins personnalisés (NAS, serveur web ou autre).
-
On en avais discuté avec Hugues, mais pour moi IPv6 il y a un méga problème pour les end user entreprises qui ont plusieurs opérateurs.
Comment faire pour ton adressage interne (non du PA n'est pas une option).
Pareil imagine la boite de 200 personnes qui change de provider qui doit tout reconf...
Je suis pour l'IPv6 mais je vois pas comment faire certaines choses. Je pense qu'il y a un gros manque d'explication pour certains (dont moi :D)
-
Ceci-dit l'ipv6 ça va compliquer les attaques par scanners. Quand tu obtient un ::/64 de ton FAI tu disposes d'Internet au carré adresses pour ton réseau local ! ;) Après pour les box un pare-feu simple avec blocage des nouvelles connexions entrantes et autorisation des connexions sortantes et établies en tcp et de l'upnp pour l'udp devrait suffire pour le grand public.
Expérience : j'ai un serveur sip "ouvert" IPV4/IPV6;je n'ai pas trace d'attaques des bots en ipv6, par contre en ipv4 ça y va !
Après les scripts pour bots ne sont peut-être pas IPV6-Ready !
-
En tout cas, ces échanges plus qu'intéressants ont commencé à prouver un manque de pédagogie flagrant concernant l'IPv6 (ce qui engendre forcèment des peurs à son sujet).
-
On en avais discuté avec Hugues, mais pour moi IPv6 il y a un méga problème pour les end user entreprises qui ont plusieurs opérateurs.
Comment faire pour ton adressage interne (non du PA n'est pas une option).
Pareil imagine la boite de 200 personnes qui change de provider qui doit tout reconf...
Je suis pour l'IPv6 mais je vois pas comment faire certaines choses. Je pense qu'il y a un gros manque d'explication pour certains (dont moi :D)
Pour moi, faire du multi-WAN sans BGP, c’est déjà pas une option, même en IPv4. C’est du bricolage à la sale.
Et pour la boîte qui change d’opérateur en IPv4, elle doit déjà tout reconfigurer, ça ne change pas grand chose :p
-
Heu et sinon pour en revenir au rapport. Non par ce que il s'agit de ça quand même.
Dans les données, on voit les estimations prochaines des opérateurs.
Pour free par exemple il pré oit jusqu'à 65% mi 2019.
Si toutes ces box depuis 2015 sont ipv6 compatible, cela renseigne quand même sur le parc de box plus ancienne non?
Genre freebox v5.
D'autre part pourquoi les réseaux de collecte ne sont pas en ipv6?
Cela ne pose pas un problème ?
-
On en avais discuté avec Hugues, mais pour moi IPv6 il y a un méga problème pour les end user entreprises qui ont plusieurs opérateurs.
Comment faire pour ton adressage interne (non du PA n'est pas une option).
Pareil imagine la boite de 200 personnes qui change de provider qui doit tout reconf...
Je suis pour l'IPv6 mais je vois pas comment faire certaines choses. Je pense qu'il y a un gros manque d'explication pour certains (dont moi :D)
l'ipv6 c'est de l'auto-configuration que tu peux piloter depuis tes routeurs/commutateurs. En cas de changement d'opérateur tu pourras changer juste de préfixe et puis ... plus de pénurie ! tu pourras acheter ton /64 ou mieux et le faire router par le founisseur de ton choix.
-
Pour free par exemple il pré oit jusqu'à 65% mi 2019.
Si toutes ces box depuis 2015 sont ipv6 compatible, cela renseigne quand même sur le parc de box plus ancienne non?
Genre freebox v5.
C'est la part activée, pas IPV6-ready, chez Free pour l'instant c'est le client qui active/désactive l'ipv6
-
l'ipv6 c'est de l'auto-configuration que tu peux piloter depuis tes routeurs/commutateurs. En cas de changement d'opérateur tu pourras changer juste de préfixe et puis ... plus de pénurie ! tu pourras acheter ton /64 ou mieux et le faire router par le founisseur de ton choix.
J'attends de voir le fournisseur qui acceptera de router ton /64 les transitaires n'acceptent que des /48 et tu dois déclarer que tu route un nouveau préfix. Je vais pas perdre un temps de fou à chaque nouveau client en blabla avec les fournisseurs.
Déjà les transitaires n'Pour moi, faire du multi-WAN sans BGP, c’est déjà pas une option, même en IPv4. C’est du bricolage à la sale.
Et pour la boîte qui change d’opérateur en IPv4, elle doit déjà tout reconfigurer, ça ne change pas grand chose :p
Non je suis pas d'accord, beaucoup de boites prennent des liens chez 2 opé et n'ont pas besoin d'un /24. de plus reconf un firewall en 10 min le temps de mettre ta nouvelle IP d'interco et changer 364 regle de NAT c'est plus simple que modifier tout tes enregistrements DNS interne, tes serveurs qui ne sont pas en dynamique etc...
Attention, je suis aussi un pro IPv6 mais dans le monde de l'entreprise ce n'est pas encore prêt d'arriver.
-
Quel beau post Vivien, grands mercis !
Je vais répondre un peu à tout le monde mon ressenti, mes idées, mon avis :
- Il faut que toutes les box des FAIs se comportent en IPV6 comme elles le font en IPV4, donc FW qui bloque l'entrant et autorise le sortant. Je note que c'est le bordel aujourd'hui entre les FAIs donc ^^
- Il faut un peu éduquer le end-user lambda (madame Michu), en mettant à jour la doc des box, des FAIs et tout et tout; En expliquant comment ouvrir des ports dans le FW (et non plus créer une règle DNAT). Faut par exemple plus parler de réseaux privés (192.168 machin), faut juste plus y faire allusion.
- Il faut bien sûr faire du PE (Privacy Extension), c'est le cas partout rassurez-moi ? :-D
A partir de là, le setup est vraiment tout comme avec IPV4. Tu fixes ton IP si t'as envie (par poste), ou tu laisses en auto-conf avec PE. Ceci pourra rassurer les plus refractaires ;-) C'est tout pareil ! (mais c'est plus simple et plus logique car end-2-end).
Je me permets aussi de préciser, qu'un g33k averti qui veut s’intéresser (donc pas madame Michu, ni l'ingé réseau qui déploit IPV6 tous les jours) trouvera quand même sur le Web tout ce qu'il faut pour se renseigner sur IPV6.
Ce forum permet de partager, après , enseigner le protocole de l'Internet , c'est le rôle des enseignants, des formations, des livres et de notre fabuleuse ressource le Web. Je me permets de partager une ressource (parmi beaucoup trop) pour un bon commencement, en français : https://inetdoc.net/articles/
-
Automatique. Partout.
L'IPv6 que tu utilises pour naviguer sur internet n'est pas celle qui porte des services et change régulièrement, ce qui limite grandement le risque d'attaque sans firewall
Alors question suivante, est-ce que box des opérateurs utilisent les privacy extension ? Par exemple Free (puisque Orange, c'est fermé par défaut).
-
A priori les privacy extension ça se passe plutôt au niveau des terminaux (c'est géré par l'OS).
-
A mon sens, un inconvénient "majeur" d'IPV6, c'est que le préfixe dépend du FAI. Sauf à avoir son AS et tout ce qui va bien...
Le dual-stack avec IPv4 va rester un moment la norme. D'ailleurs c'est toujours pas le sujet, mais la notion de DMZ est un peu abolie avec l'IPV6 ?
-
D'ailleurs c'est toujours pas le sujet, mais la notion de DMZ est un peu abolie avec l'IPV6 ?
Non pourquoi, la DMZ est plutôt une notion liée au firewall à l'origine.
-
Concernant les clients "IPv6-ready" :
- Je pensais Bouygues Telecom plus avancé que ça.
- C'est trompeur de mettre 100% pour SFR, le tunnel n'est pas une solution valable (activer l'IPv6 par défaut aujourd'hui serait suicidaire).
Ils auraient dû ne retenir que les IPv6 natives, ou avec un impact faible en terme de latence/débit (le 6rd chez Free à priori).
De même "le réseau fixe utilisé doit être compatible IPv6" est trompeur : avec un tunnel c'est une partie du réseau, voire rien du tout (un opérateur pourrait très bien offrir une IPv6 via un tunnel se terminant hors de son réseau, même si ce serait étrange à cause de tout le traffic YouTube/Netflix et autres qui s'y écoulerait). Donc les "100%" n'indiquent en aucun cas que la totalité du réseau de l'opérateur est compatible.
Ils mettent "impossibilité de désactiver l'IPv6" à "Non" pour Free, mais est-ce le cas pour les abonnés en 4rd ?
Il est peut-être possible de désactiver côté LAN, mais côté WAN c'est impossible.
-
A mon sens, un inconvénient "majeur" d'IPV6, c'est que le préfixe dépend du FAI. Sauf à avoir son AS et tout ce qui va bien...
Le dual-stack avec IPv4 va rester un moment la norme. D'ailleurs c'est toujours pas le sujet, mais la notion de DMZ est un peu abolie avec l'IPV6 ?
le prefix n'est pas un souci:
n'importe qui peut demander un /48 PI (=Provider Independent (PI) assignment) voir: https://www.ripe.net/manage-ips-and-asns/ipv6/request-ipv6
puis faire router par le ou les FAI qui fournissent les connexions.
On peut aussi faire son réseau interne en ULA et avoir un mécanisme 100% automatique d'attribution des GUA qui rend trivial le changement de prefix public. Tout les machines internes n'ont pas forcement besoin de GUA et c'est une facon de renforcer la sécurité.
-
le prefix n'est pas un souci:
n'importe qui peut demander un /48 PI (=Provider Independent (PI) assignment) voir: https://www.ripe.net/manage-ips-and-asns/ipv6/request-ipv6
puis faire router par le ou les FAI qui fournissent les connexions.
On peut aussi faire son réseau interne en ULA et avoir un mécanisme 100% automatique d'attribution des GUA qui rend trivial le changement de prefix public. Tout les machines internes n'ont pas forcement besoin de GUA et c'est une facon de renforcer la sécurité.
Oui mais c'est plutôt réservé aux abonnements "pro" le routage des subnet IPv6 ? Je vois mal Orange ou Free faire ce genre de presta pour les clients GP.
Pour avoir un /48 PI ça se passe comment? Faut un AS?
-
A priori les privacy extension ça se passe plutôt au niveau des terminaux (c'est géré par l'OS).
Donc à priori pas si automatique que cela, et que l'utilisateur doit configurer (ou au moins se préoccuper de savoir si l'OS le fait bien).
-
Oui mais c'est plutôt réservé aux abonnements "pro" le routage des subnet IPv6 ? Je vois mal Orange ou Free faire ce genre de presta pour les clients GP.
Pour avoir un /48 PI ça se passe comment? Faut un AS?
En même temps, je vois mal un public GP avoir besoin de son propre /48.
Pour un avoir un PI, tu n’as pas besoin d’AS, mais quitte à prendre son range, autant l’annoncer soit-même :D
-
C'est aussi le foutoir parce que des gens cherchent à faire de la sécurité applicative au niveau 3
Étrangement, ça ne fonctionne pas trop.
Je suppose que tu penses qu'il faut le faire au niveau applicatif ? Mais ce serait une vue bien théorique. Beaucoup d'utilisateurs ont un NAS qui n'est plus maintenu depuis des années, et un smartphone un an ou deux après l'achat.
Ce n'est pas trop rassurant d'avoir un NAS ou autre périphérique (caméra IP..) exposée sur Internet sans mise à jour...
-
Je me permets aussi de préciser, qu'un g33k averti qui veut s’intéresser (donc pas madame Michu, ni l'ingé réseau qui déploit IPV6 tous les jours) trouvera quand même sur le Web tout ce qu'il faut pour se renseigner sur IPV6.
Ce forum permet de partager, après , enseigner le protocole de l'Internet , c'est le rôle des enseignants, des formations, des livres et de notre fabuleuse ressource le Web. Je me permets de partager une ressource (parmi beaucoup trop) pour un bon commencement, en français : https://inetdoc.net/articles/
Peut-être, mais sur les principes et la mise en oeuvre générale. Il n'y a à ma connaissance pas beaucoup de sites qui traitent de la façon dont chaque opérateur gère l'IPv6, en fonction des versions de box, de comment activer tel service IPv6 selon l'opérateur, ou des précautions à prendre que l'on soit chez Orange, Free, Bouygues ou SFR, là encore en fonction des box, ou des technique (IPv6 natif, tunnel etc...) !
-
Pour free par exemple il pré oit jusqu'à 65% mi 2019.
Si toutes ces box depuis 2015 sont ipv6 compatible, cela renseigne quand même sur le parc de box plus ancienne non?
Genre freebox v5.
La réponse est dans le tableau ci-dessous : contrairement à Orange et Bouygues Telecom, Free n'active pas IPv6 pour les anciens clients.
Il y a donc un par important de clients avec une box compatible (la Freebox v5 est compatible) mais sans IPv6 activé. 99% des clients ne touchent pas à cette option (la preuve avec SFR qui a une grande partie de son réseau IPv6-ready mais qui a moins de 1% de clients avec IPv6 activé. Chez Bouygues Telecom il y a par contre peu de clients IPv6-Ready mais comme ils sont tous activés, mêmes les anciens clients, Bouygues dépasse SFR en %de clients activés.
Taux de clients du réseau fixe IPv6-ready et politique d’activation des box des FAI de plus de 10 000 clients proposant IPv6 en France :
(https://lafibre.info/images/ipv6/201810_arcep_barometre_ipv6_03.png)
D'autre part pourquoi les réseaux de collecte ne sont pas en ipv6?
Cela ne pose pas un problème ?
C'est possible techniquement de faire de l'IPv6 natif sur de la collecte Orange, mais souvent ce n'est pas la priorité des opérateurs.
-
- C'est trompeur de mettre 100% pour SFR, le tunnel n'est pas une solution valable (activer l'IPv6 par défaut aujourd'hui serait suicidaire).
Ils auraient dû ne retenir que les IPv6 natives, ou avec un impact faible en terme de latence/débit (le 6rd chez Free à priori).
La définition d'IPv6-ready, c'est un client qui est en mesure d'activer IPv6 sur sa box.
La notion de IPv6 natif ou non n'entre pas en considération.
SFR ne peut effectivement pas activer par défaut l'IPv6 avec tunnel, car cela demande des ressources réseaux (pour terminer le tunnel) et que cela a des impacts en terme de débit FTTH (limitation à moins de 200 Mb/s avec la Neufbox v6) et débit ADSL avec la NeufBox v4 (limitation à moins de 8 Mb/s)
Par contre SFR fait de plus en plus de l'IPv6 natif et là contrairement aux autres, IPv6 n'est pas activé par défaut.
-
Genre initialement ça devait être généré avec la MAC, puis ça marchait pas assez bien donc ça a changé, mais au final ce n'est pas si aléatoire ?
Non, tu confonds avec EUI-64.
Tu as une IP générée en EUI-64, et plusieurs en PE. C'est normal. Et oui ça fait bizarre d'avoir plusieurs IP sur la même machine, mais c'est normal :)
-
Je remarque qu'alors qu'il y a des dizaines de millions de clients mobiles, ce qui paraitrait propice à l'IPv6, le taux de clients connectés en IPv6 est particulièrement faible, de 0 à quelques pour cents. Les opérateurs préfèrent faire du CGNAT.
-
La RFC 4941 (Privacy Extensions for Stateless Address Autoconfiguration in IPv6) permet d'avoir une IP aléatoire, mais cela n’empêche pas un attaquant de t'attaquer quand il connaît ton IP.
Tes moindres fait et gestes sur Internet laissent des traces sur Internet.
Une explication de la RFC en Français par Stéphane Bortzmeyer: http://www.bortzmeyer.org/4941.html
-
le taux de clients connectés en IPv6 est particulièrement faible, de 0 à quelques pour cents. Les opérateurs préfèrent faire du CGNAT.
Il y a toujours du NAT pour les cibles disponibles uniquement en IPv4 (mais plus pour les cibles disponibles en IPv6)
Aujourd'hui Orange comme Bouygues ou les opérateurs américains déploient de l'IPv6 only sur le mobile. Le mobile à uniquement une IPv6. Pour joindre les sites en IPv4, on utilies du DNS64/NAT64 : Le DNS donne une IPv6 aux sites disponibles uniquement en IPv4, cette IPv6 étant celle du NAT64 qui lui a une connectivité IPv4.
Aujourd'hui les opérateurs ne déploiement pas d'IPv6 sur les iPhones pour deux raisons :
- Raison N°1 : Certains VPN ne passent pas avec le NAT64. Un exemple: OpenVPN inutilisable avec l'APN IPv6 4G Bouygues (https://lafibre.info/4g-bytel/4g-apn-ipv6-ipv4-vers-bbox-ftth-ip-fixe-ipv4-open-vpn/). Le cas remonté par oliviertoto92350 n'est pas un cas exceptionnel. C'est une régression connue. il faut donc que le client puisse désactiver IPv6 si son usage le nécessite, le temps que les VPN d'entreprises soient disponibles en IPv6. Or Apple ne permet pas de désactiver IPv6 : il faut l'activer pour tous les clients du FAI ou pas.
- Raison N°2 (qui reste acceptable) : iOS ne supporte pas 464XLAT. Il est donc impossible si tu tapes http://46.227.16.8/ de charger la page (et malheureusement, certains sites web ou logiciels mal codés utilisent des IP littérales pour accéder à des ressources)
-
SFR ne peut effectivement pas activer par défaut l'IPv6 avec tunnel, car cela demande des ressources réseaux (pour terminer le tunnel) et que cela a des impacts en terme de débit FTTH (limitation à moins de 200 Mb/s avec la Neufbox v6) et débit ADSL avec la NeufBox v4 (limitation à moins de 8 Mb/s)
C'est beaucoup moins que 200Mb/s, même sur la NB6VAC (je ne peux pas vérifier sur ma NB6V car le fichier de configuration ne donne plus d'IPv6 depuis juillet).
Par contre SFR fait de plus en plus de l'IPv6 natif et là contrairement aux autres, IPv6 n'est pas activé par défaut.
Est-ce qu'on a des abonnés qui ont basculé dessus récemment ? Soit le déploiement est extrêmement lent, soit il a été mis en pause puisque les premiers tests remontent à plusieurs années et les perspectives d'activation communiquées à l'ARCEP sont très faibles.
Les critères d'éligibilité n'ont pas été annoncés non plus à ma connaissance : des abonnés aléatoires pour tester ? Certains NRO/DSLAM ? Certains POP ?
- Raison N°2 (qui reste acceptable) : iOS ne supporte pas 464XLAT. Il est donc impossible si tu tape http://46.227.16.8/ de charger la page (et malheureusement, certains sites web ou logiciels mal codés utilisent des IP littérales pour accéder à des ressources)
Selon leur doc ils génèrent les IPv6 pour les IPv4 littérales eux-mêmes mais :
- C'est sur les APIs de résolution DNS, pas de manière transparente pour tout trafic IP : certaines applis pourraient ne pas fonctionner.
- Ca passe probablement par un serveur Apple et non pas celui de l'opérateur.
-
Selon leur doc ils génèrent les IPv6 pour les IPv4 littérales eux-mêmes mais :
- C'est sur les APIs de résolution DNS, pas de manière transparente pour tout trafic IP : certaines applis pourraient ne pas fonctionner.
- Ca passe probablement par un serveur Apple et non pas celui de l'opérateur.
Intéressant, je ne savais pas. Un client Appel en IPv6 only (on en trouve aux USA) pourrait donc ouvrir une IPv4 littérale ?
Tu as une source ?
Il reste le problème N°1, qui est aussi présent aux USA. Les servie clients des opérateurs américains renvoient la faute sur le VPN si il ne supporte pas IPv6 et il me semble qu'aux USA tous les opérateurs mobiles sont en IPv6 only, il n'est donc pas possible de passer à la concurrence pour résoudre le problème.
-
Intéressant, je ne savais pas. Un client Appel en IPv6 only (on en trouve aux USA) pourrait donc ouvrir une IPv4 littérale ?
Tu as une source ?
Il reste le problème N°1, qui est aussi présent aux USA. Les servie clients des opérateurs américains renvoient la faute sur le VPN si il ne supporte pas IPv6 et il me semble qu'aux USA tous les opérateurs mobiles sont en IPv6 only, il n'est donc pas possible de passer à la concurrence pour résoudre le problème.
https://developer.apple.com/library/archive/documentation/NetworkingInternetWeb/Conceptual/NetworkingOverview/UnderstandingandPreparingfortheIPv6Transition/UnderstandingandPreparingfortheIPv6Transition.html
If your app needs to connect to an IPv4-only server without a DNS hostname, use getaddrinfo to resolve the IPv4 address literal. If the current network interface doesn’t support IPv4, but supports IPv6, NAT64, and DNS64, performing this task will result in a synthesized IPv6 address.
La page dit le contraire un peu avant, mais ça semble être un oubli des anciennes versions.
Bref :
- les APIs de haut niveau devraient fonctionner de manière transparente
- pour les sockets il semble nécessaire d'utiliser getaddrinfo (ce qui n'est pas forcèment un réflexe pour une IP littérale, car normalement pour un code qui ne fait pas de résolution DNS, remplir sa "struct sockaddr" manuellement fonctionne), et de ne pas utiliser de fonctions qui ne supportent pas IPv6 à la base ou qui nécessitent de spécifier manuellement IPv4 ou IPv6 (gethostbyname, gethostbyaddr, ...).
Donc ça peut nécessiter des adaptations au niveau du code (par exemple dans curl : https://github.com/curl/curl/commit/01a49a7626ee4a226cd0b50d70591ab147d60ee0), contrairement à Android où le 464XLAT est beaucoup plus transparent.
-
Comment faire pour ton adressage interne (non du PA n'est pas une option).
Pareil imagine la boite de 200 personnes qui change de provider qui doit tout reconf...
+1, j'avais pas encore pensé à ça côté IPv6, c'est vrai que ça doit être un peu galère à gérer en cas de changement d'opérateur. ???
-
Chez SFR en FTTH, IPV6 est dispo, mais ca ne marche pas chez beaucoup de gens...
J'ai ouvert un incident au support qui ne propose rien d'autre que de reinitialiser la box en paramètres d'usines...
Ils s'en contrefichent.
-
Y'a pas si longtemps (en 2014) j'ai appris les classes d'adresses IPv4, A, B, C en IUT de Réseaux & Télécoms. Et je serai pas étonné que ce soit toujours le cas (même profs). Durant mes 2 années, nous n'avons eu 1 seul cours et 1 seul TP sur IPv6.
-
Formation similaire en 2006 : cours sur le 10 base 2...
-
Est-ce qu'on a des abonnés qui ont basculé dessus récemment ? Soit le déploiement est extrêmement lent, soit il a été mis en pause puisque les premiers tests remontent à plusieurs années et les perspectives d'activation communiquées à l'ARCEP sont très faibles.
Bonjour,
Abonné SFR en FTTH, dans un zone AMII SFR en cours de déploiement, donc sur des équipements très récents, avec un OLT changé il y a quelques semaines d’après mes sources : aucune trace d'ipv6 native, juste du teredo lorsque l'on active la ressource depuis l'interface de la box....
-
C'est moi, ou il n'y a ni OVH Telecom, ni les hébergements d'OVH dans ce baromètre? Normal?
-
OVH Telecom a du être considéré comme opérateur pro. L'observatoire est en effet limité aux offres grand public.
Prix hors taxe et pas d'offre TV, c'est plus une cible pro...
-
C'est vrai qu'OVH Telecom glisse de plus en plus vers le marché pro. C'est presque pensé que comme ça.
Soit, mais pourquoi aucune donnée pour OVH côté hébergeur? Surtout que l'IPv6 se développe petit à petit. Pourquoi le cacher?
-
Il est écrit "auprès des hébergeurs ayant souhaité participer à la collecte (sur base volontaire)".
Donc soit OVH n'a pas voulu participer (pour ne pas afficher un trop mauvais score ?), ou a oublié de répondre à l'ARCEP.
-
+1, j'avais pas encore pensé à ça côté IPv6, c'est vrai que ça doit être un peu galère à gérer en cas de changement d'opérateur. ???
Il me *semble* que la plage ULA servait justement à ça : En interne les IP sont "privée", comme en IPv4 , et typiquement les imprimantes & autre utilisent ça.
Ca n'empêche pas pour autant les postes d'avoir des IPv6 publique (avec privacy extension si nécessaire) pour sortir sur le net, vu qu'il y a plusieurs IPv6 par interface.
=> Du coup en cas de changement d'opérateur ben ca se passe bien : Les services interne restent sur les mêmes plages ULA, et les postes changent simplement de préfixe.
La seule chose à faire sera pour les serveurs (ie changer les DNS) mais ce sera le cas aussi en IPv4 - la seule alternative c'est de demander un /48 pour l'organisation, et de le faire router par son FAI (ce qui exclu de fait les particuliers & les petits pro - va demander en boutique Orange si ils veulent bien router ton /48 vers ta box...)
Je me demande si ce serait pas une bonne solution pour les box des FAI (en plus de placer un fw actif par défaut, firewall qui présente l'avantage de ne pas avoir besoin d'être stateful).
-
Il est écrit "auprès des hébergeurs ayant souhaité participer à la collecte (sur base volontaire)".
Donc soit OVH n'a pas voulu participer (pour ne pas afficher un trop mauvais score ?), ou a oublié de répondre à l'ARCEP.
Ok, merci.
Ils ne sont pas si mauvais que ça. Mais ne connaissant pas l'état exact de la concurrence avant cette publication, peut être un excès de prudence, en effet.
-
Online n'a pas participé non plus d'ailleurs.
-
Il me semble normal que les hébergeurs qui n'activent pas IPv6 par défaut (Online, le N°2 Français, Ikoula, le N°3 Français,...) ne répondent pas à cette enquête facultative.
Il faut féliciter ceux qui ont osé le faire...
(https://lafibre.info/images/ipv6/201810_arcep_barometre_ipv6_10.png)
Pour OVH je suis étonné de l'absence de réponse.
-
Pour info, OVH active IPv6 par défaut sur certains mutualisés et certains dédiés... Ils ne sont pas si mauvais que ça, vraiment.
-
OVH c'est un /128 par VPS... ou comment saloper IPv6 et transmettre un très mauvais exemple a ceux qui débute en IPv6.
-
Mouais, faut bien commencer quelque part.
L'hébergeur où j'ai mon site est pire sur ce point précis: https://obambu.com/fr/cloud/ . Mais une partie des offres te donne au moins de l'IPv6. Donc pour un début, why not.
La plupart ne mette qu'un seul IPv6 sur leur serveur vis à vis du trafic de leurs sites, même quand leur hébergeur en fournit plusieurs...
Edit: quand je dire pire, c'est le masque de sous-réseau qui n'est même pas classique. Sinon c'est tout de même plus d'IPv6.
-
Mouais, faut bien commencer quelque part.
L'hébergeur où j'ai mon site est pire sur ce point précis: https://obambu.com/fr/cloud/ . Mais une partie des offres te donne au moins de l'IPv6. Donc pour un début, why not.
La plupart ne mette qu'un seul IPv6 sur leur serveur vis à vis du trafic de leurs sites, même quand leur hébergeur en fournit plusieurs...
non faut pas commencer comme ca.
donner un /128 ou qu'une IPv6, 2 IPv6, etc c'est juste pas avoir compris IPv6 et vouloir bêtement transposer IPv4.
Le plus idiot d'ailleurs c'est qu'OVH propose jusqu'a 16 IPv4 par VPS (moyennant 2€ d'activation par IP, sans récurrent) mais rien de plus en IPv6. un /128 et c'est tout.
du coup, toute config a base de Docker est impossible à faire en IPv6 (ou alors moyennant d’horribles bidouilles).
a l'autre bout, des gens qui maîtrisent totalement IPv6, comme Hurricane Electric propose gratuitement un /48 !
-
Le plus idiot d'ailleurs c'est qu'OVH propose jusqu'a 16 IPv4 par VPS (moyennant 2€ d'activation par IP, sans récurrent) mais rien de plus en IPv6. un /128 et c'est tout.
Ah oui, quand même!^^
Chez Obambu, il y au moins plus d'IPv6 que d'IPv4, même en prenant toutes les options IPv4. :)
Pour le reste, cela viendra un jour, mais pas demain la veille je pense...
-
Chez Ikoula, c'est un /96 et la fin de l'IPv4 est incluse dans le début du /64 :
# The primary network interface
auto p4p1
iface p4p1 inet static
address 213.246.63.45
netmask 255.255.255.0
gateway 213.246.63.1
dns-nameservers 213.246.33.144 213.246.36.14 80.93.83.11 80.93.83.25
iface p4p1 inet6 static
address 2a00:c70:1:213:246:63:45:2
netmask 96
gateway 2a00:c70:1:213:246:63::1
-
Chez Ikoula, c'est un /96 et la fin de l'IPv4 est incluse dans le début du /64 :
À part quelques réseaux locaux de grandes entreprises qui n'ont plus autre chose que win10 côté Windows, du linux, du macOS, pas de Chrome OS, et n'acceptent que les Android et iOS côté mobiles, c'est tout de même prématuré pour faire de l'IPv6 only... Surtout pour un serveur internet.
-
La problématique de ce type de SI, c'est qu'il n'est pas pour le moment possible de faire des offres avec IPv6 sans IPv4 publiques.
Or un serveur de back-end ou de base de données, n'a pas besoin d'une IPv4 publique.
-
La problématique de ce type de SI, c'est qu'il n'est pas pour le moment possible de faire des offres avec IPv6 sans IPv4 publiques.
Il me semble que les serveurs sur des Linux récents peuvent gérer de l'IPv6 only.
Et ce n'est pas le cas de Windows Server 2016 ?
Or un serveur de back-end ou de base de données, n'a pas besoin d'une IPv4 publique.
Je suis d'accord sur ce point, si une alternative est possible bien entendu.
-
Le support de la RFC 8106 Neighbor Discovery Protocol RDNSS n'est pas supporté par Windows server 2016, donc il n'est possible d'avoir des serveurs DNS par ce moyen en IPv6 only. Windows Server 2019 comme les distributions linux sont compatible RFC 8106.
Maintenant, il est possible de configurer la chose à la main sous Windows server 2012 / 2012 R2 / 2016 ou via DHCPv6 (si le réseau si le supporte).
Le baromètre 2018 Arcep explique bien les choses en classant les systèmes d’exploitation client en fonction de la compatibilité RFC 8106 Neighbor Discovery Protocol RDNSS :
9/ Terminaux
Pour qu’un terminal èmette et reçoive du trafic en IPv6, le système d’exploitation (Operating System - OS) doit être compatible IPv6, et IPv6 doit être activé par défaut.
Sur de nombreux objets connectés (système d’alarme, télévisions, etc.), IPv6 est intégré dans l’OS mais n’est pas activé par le constructeur de l’objet connecté.
Seules les versions de systèmes d’exploitation préinstallées sur des ordinateurs, tablettes ou smartphones à destination du grand public et encore maintenues (mises à jour de sécurité, etc.) sont étudiées ci-dessous.
Tous ces systèmes d’exploitation sont compatibles avec IPv6 qui est activé par défaut depuis de nombreuses années (IPv6 a été par exemple activé par défaut sous Windows depuis Windows Vista en 2007). Cependant, certains systèmes d’exploitation ne peuvent pas fonctionner correctement en IPv6 en absence d’IPv4 (i.e. dans le cas où IPv6 est le seul protocole disponible) car ils n’intègrent pas le support de la RFC 8106 Neighbor Discovery Protocol RDNSS.
(https://lafibre.info/images/ipv6/201810_arcep_barometre_ipv6_17.png)
Celui qui est étonnant dans la liste, c'est Google Chrome OS. Pourquoi Google ne met pas le RFC 8106 Neighbor Discovery Protocol RDNSS dans cet OS alors qu'il est dans Android ?
-
Il y a aussi Ubuntu, donc probablement Linux, d'après le baromètre. Pas que Windows, donc.
Mais bon, les autres Linux c'est peut être la même histoire que Windows 10 mobile, ou Chrome OS.
> Windows 10 a été conçu avec un core. Le reste peut avoir de grosses différences. C'était déjà, sur le principe, le cas avant.
> Chrome OS se base sur du Linux, comme Android, mais comme côté Windows, Google a aussi voulu segmenter le marché des OS de son développement. Faut donc poser la question directement à Google (pour Chrome OS, on le fait via la plateforme des bugs pour Chromium OS, il répondent souvent).
> Ubuntu n'est pas tout dans Linux, donc là aussi, un doute pour les autres Linux.
Je posais la question pour Windows Server 2016, car il est aussi basé sur Windows 10. Donc ta réponse est étrange, à moins qu'il faille un Windows 10 un minimum à jour aussi.
-
Il y a aussi Ubuntu, donc probablement Linux, d'après le baromètre. Pas que Windows, donc.
Mais bon, les autres Linux c'est peut être la même histoire que Windows 10 mobile, ou Chrome OS.
Les piles IP ne changent pas entre les distributions, ou à la marge en fonction de la version des noyaux.
-
Il y a aussi Ubuntu, donc probablement Linux, d'après le baromètre. Pas que Windows, donc.
Ma phrase est très mal rédigée, je l'ai modifiée. Oui, les distributions Linux sont compatible Neighbor Discovery Protocol RDNSS depuis des année.
-
Celui qui est étonnant dans la liste, c'est Google Chrome OS. Pourquoi Google ne met pas le RFC 8106 Neighbor Discovery Protocol RDNSS dans cet OS alors qu'il est dans Android ?
ChromeOS supporte RDNSS.
ChromeOS supporte aussi les réseaux IPv6 sans IPv4.
Je ne sais qui sont vos sources mais ChromeOS évoluant tres rapidement il est fréquent que les wikipédia et autres ne soient pas du tout a jour concernant ChromeOS.
-
Simplement l'arcep, notre source, sur ce coup là.^^
Bon, pas à jour de leur côté donc.
Windows 10 à partir de 2017, je viens de remarquer cette mention.
Peut être plus récent pour Chrome OS, ou alors pas de release note exhaustive sur ce genre d'aspect.
En dehors de la poste et du télécom, l'arcep ne fait pas vraiment dans les tests par eux-même...
-
non faut pas commencer comme ca.
donner un /128 ou qu'une IPv6, 2 IPv6, etc c'est juste pas avoir compris IPv6 et vouloir bêtement transposer IPv4.
Le plus idiot d'ailleurs c'est qu'OVH propose jusqu'a 16 IPv4 par VPS (moyennant 2€ d'activation par IP, sans récurrent) mais rien de plus en IPv6. un /128 et c'est tout.
[...]
Là, c'est si on parle de Kimsufi, la marque/gamme à bas prix d'OVH. Parce-que les dédiés SoYouStart ou OVH disposent officiellement d'un /64.
D'ailleurs, en parlant de Kimsufi, ce n'est pas tout à fait exact - https://otacon22.com/2016/02/21/two-hosting-providers-ipv6-setups-compared-ovh-online-net/ (https://otacon22.com/2016/02/21/two-hosting-providers-ipv6-setups-compared-ovh-online-net/)
-
ChromeOS supporte RDNSS.
ChromeOS 67.0.3396.99 Does not support DHCPv6 or RDNSS.
Source 1 : https://en.wikipedia.org/wiki/Comparison_of_IPv6_support_in_operating_systems
Source 2 : https://github.com/openwrt/odhcpd/issues/86
Source 3 : https://utcc.utoronto.ca/~cks/space/blog/linux/QuickWirelessIPv6SetupII
Wikipedia ne serait pas à jour ?
J'ai creusé pour l'absence de compatibilité IPv6 de webOS annoncé sur cette même page. WebOS supporte bien IPv6, car j'ai réussi à avoir que le nouveau firmware désactive IPv6 en attendant la résolution d'un bug.
-
ChromeOS 67.0.3396.99 Does not support DHCPv6 or RDNSS.
Source 1 : https://en.wikipedia.org/wiki/Comparison_of_IPv6_support_in_operating_systems
Source 2 : https://github.com/openwrt/odhcpd/issues/86
Source 3 : https://utcc.utoronto.ca/~cks/space/blog/linux/QuickWirelessIPv6SetupII
Wikipedia ne serait pas à jour ?
J'ai creusé pour l'absence de compatibilité IPv6 de webOS annoncé sur cette même page. WebOS supporte bien IPv6, car j'ai réussi à avoir que le nouveau firmware désactive IPv6 en attendant la résolution d'un bug.
non c'est pas a jour.
Le bug tracker de ChromeOS fait mention déjà en 2015 du support de RDNSS: https://bugs.chromium.org/p/chromium/issues/detail?id=510283#c3
Mon pixelbook obtient bien une IPv6 et le dns.
Pour DHCPv6; je ferais un test jeudi. mais y'a rien dans le bugtracker a ce sujet. Il y a meme le support de DHCPv6-PD (delegation de prefix).
Je regardais plus en détail le code de Shill (= le Network Connection Manager de ChromeOS) mais y'a bien du DHCPv6 dans le code: https://chromium.googlesource.com/chromiumos/platform2/+/HEAD/shill/dhcp/dhcpv6_config.h
A noter que ChromeOS et Android n'utilise pas du tout le meme kernel ni la meme base. Ce sont des équipes différentes. La base de ChromeOS est aussi utilisé dans le Chromecast et le routeur Google Wifi.
-
Le problème avec ipv6 c'est publique, qd tu as des enfants, tu n'as pas trop envie qu'ils aient une ip publique.
Un proxy c'est qd même vachement bien, même le dialogue est le meilleurs contrôle parental.
-
Le problème avec ipv6 c'est publique, qd tu as des enfants, tu n'as pas trop envie qu'ils aient une ip publique.
Un proxy c'est qd même vachement bien, même le dialogue est le meilleurs contrôle parental.
what ? IPv4 privée ou IPv6 public ca change rien.
-
Le problème avec ipv6 c'est publique, qd tu as des enfants, tu n'as pas trop envie qu'ils aient une ip publique.
Un proxy c'est qd même vachement bien, même le dialogue est le meilleurs contrôle parental.
Euh... Mais on ne peut pas savoir QUI utilise l'ip. ???
-
Le problème avec ipv6 c'est publique, qd tu as des enfants, tu n'as pas trop envie qu'ils aient une ip publique.
Tes enfants, a mois de les avoir transformes en cyborgs, n'auront PAS d'adresse IP. Ni v4, ni v6, ni privee, ni publique. Les gadgets qu'ils utilisent - c'est autre chose. Mais NON, une adresse privee ne donne pas plus de securite. C'est un firewall qui le donne, et l'IPv6 n'exclut pas l'existence d'un firewall comme regle generale.
Un proxy c'est qd même vachement bien, même le dialogue est le meilleurs contrôle parental.
Un proxy, en regle generale c'est bien pour faire que certaines choses s'arretent de fonctionner (pas forcement celles que tu esperes). Si c'est ca que tu cherches, effectivement, c'est "vachement bien". Autrement, non.
-
NON, une adresse privee ne donne pas plus de securite. C'est un firewall qui le donne, et l'IPv6 n'exclut pas l'existence d'un firewall comme regle generale.
Qui sait configurer un firewall, surtout IPv6 ? Qui sait si sa box inclut ou pas un firewall qui bloque les connexions entrantes par défaut ou pas (Free ne la fait pas) ?
-
Pour le moment j'ai désactivé l'ipv6 aussi bien sur ma ligne fibre que sur mon smartphone sosh. J'ai remarqué que le peering Orange était clairement moins bon dès que l'ipv6 était activé: cela se ressent vers des petits services comme Google ou Twitter...
Dommage. Je reteste régulièrement mais pour le moment ce n'est top.
-
Pour Google, le peering est le même.
Pour twitter, il n'est même pas dispo en IPv6.
Effet nocébo...
-
Alors je ne sais pas si le problème via du peering par contre je constate très clairement une différence sur le chargement des médias sur twitter dès que l'ipv6 est activé tout comme les vidéos youtube par exemple. Et ce n'est absolument pas un effet placebo tellement c'est flagrant.
Personnellement je serai plutôt ravi de pouvoir l'activer ;)
-
Perso j'ai pas d'IPv4 quand je configure mon APN en IPv6 sur mon forfait Sosh.
Donc je ne peux pas accéder aux sites IPv4 only (Twitter par exemple)
-
Et ce n'est absolument pas un effet placebo tellement c'est flagrant.
Attention, placebo et nocebo c'est différent.
-
Pour twitter, il n'est même pas dispo en IPv6.
Les CDN sont dispo en IPv6 non ?
-
Les CDN sont dispo en IPv6 non ?
Apparemment oui : https://www.reddit.com/r/ipv6/comments/75ibgy/is_twitter_starting_to_roll_out_or_test_ipv6/
Mais pas tous ?
-
Perso j'ai pas d'IPv4 quand je configure mon APN en IPv6 sur mon forfait Sosh.
Donc je ne peux pas accéder aux sites IPv4 only (Twitter par exemple)
C'est le principe (aussi bien chez Bouygues Telecom que Orange) : IPv6 only sur le mobile. (vs dual stack sur le fixe)
Comment accéder aux sites IPv4 only ?
Tu est aidé par le NAT64 + DNS64 : Le DNS ne répond que des IPv6 (AAAA). Si le site est en IPv6 comme LaFibre.info, c'est son IPv6 qui est donné, fonctionnement normal. Si le site est uniquement disponible en IPv4, le DNS te donne l'IPv6 d'une plateforme de translation NAT64 qui elle à une patte en IPv4, comme le NAT classique. Bref tu utilises du NAT uniquement en IPv4 et pas en IPv6.
Mais que fait si tu accède à un site via son IP littérale ? (exemple http://46.227.16.8/ à la place de http://ipv4.lafibre.info/ )
Ton Smartphone Android (iOS ne propose pas de 464XLAT) va encapsuler ta requête jusqu’à une plateforme dédiée.
C'est pour cela que sur http://ip.lafibre.info/ l'IPv4 publique pour une requête littérale peut être différente de l'IPv4 publique quand tu joint le même site via une requête DNS.
(https://lafibre.info/images/ipv6/201706_iplafibre_ipv6.png)
Maintenant tous ces mécanismes sont automatiques et normalement tu as automatiquement accès aux sites IPv4, en littérale comme via le DNS. Cela serait bien de nous donner pus d'informations sur ton mobile, sa version d’Android et une copie d'écran de http://ip.lafibre.info/ sur ton mobile.
-
Effectivement @vivien suite à ton post j'ai finalement constaté que c'est l'option Private DNS de Android 9 qui me privé totalement de tout accès IPv4.
En effet lorsque j'utilise le DNS over TLS de Cloudflare (1dot1dot1dot1.cloudflare-dns.com) cela me coupe tout accès à IPv4 lorsque l'APN Orange est réglé sur IPv6, si je désactive l'option tout rentre dans l'ordre et le NAT64 + DNS64 fonctionne normalement.
-
Comment ça peut marcher la configuration d’un résolveur DNS en filant un nom de domaine ?
-
Comment ça peut marcher la configuration d’un résolveur DNS en filant un nom de domaine ?
Cloudflare l'explique dans son article sur comment activer Private DNS sur Android Pie : https://blog.cloudflare.com/enable-private-dns-with-1-1-1-1-on-android-9-pie (https://blog.cloudflare.com/enable-private-dns-with-1-1-1-1-on-android-9-pie)
Google requires a hostname for this field because of how mobile carriers are adapting to a dual-stack world in which IPv4 and IPv6 coexist. Companies are adopting IPv6 much more rapidly than generally expected, and all major mobile carriers in the US support it, including T-Mobile who has gone completely IPv6.
D'ailleurs Google à push cette solution pour que ça fonctionne entre autre chez T-Mobile (US) qui a un réseau full-IPv6.
-
Merci pour l’explication :)
C’est assez original comme façon de faire, je trouve. Autant demander deux résolveurs, un v6 et un v4.
(mais on s’éloigne un peu du sujet là)
-
D'ailleurs Google à push cette solution pour que ça fonctionne entre autre chez T-Mobile (US) qui a un réseau full-IPv6.
Mais toute utilisation d'un DNS tiers en IPv6 only casse le DNS64, et donc oblige tout le trafic IPv4 à passer par le tunnel 464XLAT.
-
Il devrait être possible de faire un DNS tiers 64, mais c'est compliqué il faut récupérer le préfixe IPv6 à utiliser pour les sites en IPv4.
-
non c'est pas a jour.
L'Arcep t'a écouté et Chrome OS est maintenant du coté "Environnement IPv6-only" : https://www.arcep.fr/cartes-et-donnees/nos-publications-chiffrees/transition-ipv6/barometre-annuel-de-la-transition-vers-ipv6-en-france.html
Il ne reste donc que Windows 10 mobile et les anciennes version de Windows dans les systèmes d’exploitation grand public toujours maintenus sans support de la RFC 8106 Neighbor Discovery Protocol RDNSS.
-
Cool.
Par contre je trouve que le rapport se focalise trop sur l'infrastructure (des tuyaux aux OS) et pas les usages/applications.
Certes l'infrastructure doit être 'IPv6 ready' mais quid des applications ?
Quand je dit application ce n'est pas serveur web style Apache ou NGinx mais Twitter par exemple ou Fortnite ou Twitch. Ce sont les ampoules connectés ou la domotique a base de Wifi/cloud en général.
Ce n'est pas parce qu'un site ou une application tourne sur de l’infrastructure 'ipv6 ready' qu'elle est forcement IPv6 compatible.
Si demain on coupe IPv4, qu'elle sont les grands services, jeux en ligne, applications mobiles ou fixes qui ne marchent plus ? C'est cela qui compte pour l'utilisateur final plus que l'infra.
-
Je me demande bien ce qu'attendent Amazon et Microsoft pour servir en ipv6... pas le budget sans doute ::)
C'est d'autant plus scandaleux qu'ils l'offrent à leur clients dans leur cloud respectifs depuis longtemps.
Pour google, c'est OK... Sauf qu'Android ne gère pas DHCPv6, et que ça frêne forcèment l'adoption d'ipv6 dans tout un tas de situations.
-
Si demain on coupe IPv4, qu'elle sont les grands services, jeux en ligne, applications mobiles ou fixes qui ne marchent plus ? C'est cela qui compte pour l'utilisateur final plus que l'infra.
Pour ce qui est des jeux, je dirais environ tous. Pour les applications fixes/mobiles, faut aller au cas par cas, mais y’a déjà pas mal de gros sites en IPv6 (google, facebook, youtube, tous les sites derrière cloudflare, etc.)
-
Sauf qu'Android ne gère pas DHCPv6, et que ça frêne forcèment l'adoption d'ipv6 dans tout un tas de situations.
Franchement 99% des gens qui reprennent cet argument n'ont aucune expérience réelle du déploiement d'IPv6.
Je n'ai pas vu un cas ou 'ca gene' vraiment en dehors de discours purement théorique de certains qu'on pas vraiment étudier / mis en oeuvre des cas réels.
Cet argument date d'au moins 2012 maintenant, soit plus de 6 ans et Google n'a toujours pas modifier Android pour le support de DHCPv6 statefull. Pensez vous vraiment que si la majorité des entreprises étaient vraiment 'gênées' par cela , la modification n'aurait pas été faite depuis ?
Je suis perplexe la dessus.
-
C'était gênant à l'époque où Windows ne supportait pas RFC 8106 Neighbor Discovery Protocol RDNSS et une entreprise souhaitait déployer de l'IPv6 only sur son réseau local (utilisation du proxy pour accéder à un site Internet en IPv4) ET avoir une seule méthode pour l’attribution des IPv6.
Il y a un site web où Microosft explique le problème qu'elle a rencontré en passant en IPv6 only en interne dans ses locaux.
Quelques mois aprés Windows 10 avait le support RFC 8106 Neighbor Discovery Protocol RDNSS !
Pour l'absence du support de DHCPv6 par Android, c'est que DHCPv6 ne permet pas un partage de connexion proprement et donc Android ne le supporte pas.
Pour moi il faut oublier DHCPv6 pour récupérer une simple IPv6 (pour un préfixe OK)
-
Certes l'infrastructure doit être 'IPv6 ready' mais quid des applications ?
Quand je dit application ce n'est pas serveur web style Apache ou NGinx mais Twitter par exemple ou Fortnite ou Twitch. Ce sont les ampoules connectés ou la domotique a base de Wifi/cloud en général.
Ce n'est pas parce qu'un site ou une application tourne sur de l’infrastructure 'ipv6 ready' qu'elle est forcement IPv6 compatible.
Si demain on coupe IPv4, qu'elle sont les grands services, jeux en ligne, applications mobiles ou fixes qui ne marchent plus ? C'est cela qui compte pour l'utilisateur final plus que l'infra.
Comment aborder ce point de manière non partielle ?
Le rapport aborde cette question avec 3 chiffres :
- l'ensemble des 3 millions de sites web en .fr, .re .pm .yt .tf et .wf (16% IPv6)
- Le top 731 d’Alexa en France (26% IPv6)
- Le taux de pages web accessibles en IPv6 sur le top 731 d’Alexa en France (61% IPv6)
Tu propose de faire du name and shame sur les principales applications ? Sur le top 50 Médiamétrie ?
La partie du rapport qui en parle :
5.2.1/ Hébergement web
Les hébergeurs de sites web 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 26% sont accessibles en IPv6*. On considère un site comme accessible en IPv6 lorsqu’il dispose d’un enregistrement IPv6 (« AAAA ») au niveau du serveur DNS.
Il est à noter que le taux de pages web accessibles en IPv6 (contenus IPv6) est significativement plus élevé (61%*). En effet, les petits fournisseurs de contenu proposent souvent des sites web (au nombre de pages consultées généralement faible) non compatibles avec IPv6.
*Cisco 6lab au 28/09/2018. Données sur le Top 731 d’Alexa en France
(https://lafibre.info/images/ipv6/201810_arcep_barometre_ipv6_12.png)
Le taux de sites disponibles en IPv6 est uniquement de 16% lorsque l’on considère les 3 millions de sites web en .fr, .re .pm .yt .tf et .wf*. Ce pourcentage est en augmentation depuis 2015, mais le rythme de cette évolution semble loin de pouvoir permettre une transition complète d’ici fin 2021.
* Données Afnic
Évolution du taux des sites web accessibles en IPv6 sur les sites web .fr, .re .pm .yt .tf et .wft :
(https://lafibre.info/images/ipv6/201810_arcep_barometre_ipv6_13.png)
-
Tu propose de faire du name and shame sur les principales applications ? Sur le top 50 Médiamétrie ?
Y'a pas mal de classements, référencement comme Alexa et Médiamétrie qui restent un peu coincé dans le passé. Le web est secondaire de nos jours, surtout pour les gros usages.
Le gros du trafic Youtube vient pas que du site web youtube.com mais des apps Youtube qu'on trouve dans les mobiles, tablettes et les STB/Smart TV. Idem pour Netflix.
Et le web pur n'est pas le plus difficile a rendre IPv6 compatible et il represente de moins en moins d'utilisation simplement parce que les gens utilisent de plus en plus des 'apps' plutot que des sites web.
Oui un label 'IPv6 only ready' sur les principales applications (pas que leur sites web) serait un plus.
Et pour le non web, par exemple en domotique, Philips Hue est souvent cité comme le plus utilisé. Est-ce que ca marche sur un réseau local sans IPv4 ? quid du controle a distance sans IPv4 ? etc
-
Hue c'est v4 Only, mais ça passe bien les NAT...
-
Et le web pur n'est pas le plus difficile a rendre IPv6 compatible et il represente de moins en moins d'utilisation simplement parce que les gens utilisent de plus en plus des 'apps' plutot que des sites web.
Oui enfin pour la majorité des apps elles utilisent que HTTP(S) avec des modèles d'API qui se greffe dessus : gRPC/GraphQL/REST/SOAP/JSON-RPC/Webhooks...
Apres il peut y avoir débat : est-ce que HTTP(S) c'est forcèment du web ?
-
Oui enfin pour la majorité des apps elles utilisent que HTTP(S) avec des modèles d'API qui se greffe dessus : gRPC/GraphQL/REST/SOAP/JSON-RPC/Webhooks...
Apres il peut y avoir débat : est-ce que HTTP(S) c'est forcèment du web ?
Etant du coté dev je peux te dire que c'est pas si simple. Certes c'est tres souvent http(s) le transport mais apres y'a plein de 'détails' qui font que ca va pas forcement fonctionner en IPv6. Notamment les ip qui se baladent en "dur" dans certains trucs ou le fait d'utiliser plusieurs services différents donc plusieurs flux http(s) vers différents serveurs et les interactions que ca engendre (typiquement Firebase par exemple).
Dans le meilleur des mondes théoriques ou tout les programmeurs sont excellents et respectent tous les API et les fondamentaux ... je dirais oui : apps mobiles ou site web c'est kifkif... sauf que dans le monde réel pas du tout.
-
Quand je vois le nombre de personnes n'ayant pas d'ipv6 en xdsl ou ftth même en ayant activé l'ipv6 dans la box (qui reste en "non connecté", sans recevoir de réponse dhcp / RA) chez SFR, je doute fortement qu'ils soient à 100% ipv6 ready...
-
Toutes les NeufBox proposent de l'IPv6, même les NeufBox plus maintenues comme les NeufBox v4.
Bref, pour moi SFR propose bien de l'IPv6 activable pour tous les clients ADSL / FTTH grand public.
On vois bien que peu de clients vont activer IPv6 et qu'il est donc nécessaire d'activer par défaut IPv6.
-
Ce que je dis, c'est que même en l'activant, beaucoup ne reçoivent pas d'ipv6.
-
Il y a un incident ?
Effectivement tu consultes le forum en IPv4.
Il y a un feu vert face à l'IPv6 dans l'interface de ta neufbox ?
http://ip.lafibre.info/ te permet de voir si tu as une IPv6 de bout en bout, (dans certains cas, il y a une IPv6 mais le système d’exploitation préfère utiliser IPv4 si le site est disponible en IPv4)
-
Il n'y a pas spécialement "d'incident", c'est assez connu comme état des choses, certains en parle sur ce même forum, et ailleurs si tu googlise "sfr ipv6 non connecté", tu tomberas sur pas mal de topics du genre : https://forum.sfr.fr/t5/Connexion-Internet-Fibre-WiFi/Box-fibre-plus-IPV6-activ%C3%A9-mais-quot-non-connect%C3%A9-quot/td-p/1945448
Et en sortant wireshark, on voit qu'on ne reçoit jamais de réponse aux requêtes... et l'ipv6 reste en "non connecté" comme état. Et ça à l'air d'être par zone géographique. Quelqu'un travaillant chez SFR m'a dit en off que l'ipv6 (native) était déployée progressivement sur les provider edge, mais qu'en effet ce n'était pas encore fait partout, et qu'il n'avait pas de planning (mais qu'il y en avait peut être un, il en ignorait juste l'éventuelle existence).
-
Si SFR compte les clients qui ont activé l'option pour la réponse à l'Arcep et non pas ceux chez qui IPv6 marche, on pourrait avoir moins de 0,9% des clients qui ont IPv6 réellement ...
Taux de clients du réseau fixe activés en IPv6 des principaux opérateurs en France :
(https://lafibre.info/images/ipv6/201810_arcep_barometre_ipv6_04.png)
-
Chez SFR, j'avais eu plusieurs problèmes avec l'ipv6 encapsulée en 2014/2015 quand j'étais beta-testeur ou sur d'autres lignes.
1) ipv6 attribuée, mais on ne sort jamais du réseau SFR ( 2 routeurs font du ping pong) (j'avais fait un sujet sur le forum de mémoire)
2) ipv 6 attribuée mais on ne dépasse pas le DSLAM
3 ) aucune ipv6 attribuée.
4) ça tombe en marche ...
Bref c'est un réseau à fiabiliser pour l'ipv6 ..
-
Sans compter l'aquisition Numéricable.
Moi j'ai SFR, suite au rachat NC, je suis donc en cable (DOCSIS), et je peux aller me brosser pour avoir de l'IPV6. Non disponible sur techno câble ....
L'option n'est même pas dans la box hein.
-
C'est NC (Altice) qui a racheté SFR en fait.
L'IPV6 existe sur la techno câble mais pas utilisée par SFR (cf https://lafibre.info/ornethd/1-milliard-de-merci-ornethd-marange-merci/ ).
-
Ouaip donc il faudrait aussi compter ça dans les chiffres de SFR : combien de pauvres âmes (comme moi !) sont chez SFR, en techno cable, et n'auront donc jamais accès à IPV6 ? (en tout cas pas pour demain)
:-(
-
Moui, ça me manque pas (je l'ai même aussi désactivé sur ma connexion FTTH).
-
Il me semble que IPv6 va arriver sur le câble, en 2020.
-
Il me semble que IPv6 va arriver sur le câble, en 2020.
Wouhouuu ! Bah j'attends du coup ^^
-
IPv6 en xDSL avec SFR me semble mal barré, plusieurs demandes au SC, ils "activent une option IPv6" mais jamais rien ne se passe, seulement bon à reset la NB6 ...
-
C'est marrant, dans mon wanservices2.xml, je suis bien en ipv6 native, mais j'ai toujours un LNS de renseigné... C'est normal ? Sinon, je me demande si c'est pas la cause de beaucoup de monde censé être en natif mais qui ne récupèrent jamais d'ip...
-
Ouaip donc il faudrait aussi compter ça dans les chiffres de SFR : combien de pauvres âmes (comme moi !) sont chez SFR, en techno cable, et n'auront donc jamais accès à IPV6 ? (en tout cas pas pour demain)
:-(
Si c'est une déléguation de service public, demande à ta commune de me refiler la concession pour 10 ans et je te mettrais ça illico presto :p
-
Free a annoncé qu'il allait prochainement supprimer la possibilité de désactiver IPv6 au niveau de la box. J'imagine que ça s'accompagnera de facto d'une activation d'IPv6 pour ceux chez qui cette option était désactivée.
Incidemment tout ça n'a aucun impact au niveau des postes clients sur lesquels IPv6 serait désactivé.
-
C'est le bouton qui permet de désactiver/activer l'IPv6 qui sera supprimé. Je me demande aussi s'il sera activé pour ceux qui l'avait désactivé...
-
C'est une bonne chose, cela a déjà été mis en place par Coriolis et Orne THD.
Free devrait fortement grimper en IPv6 quand cela sera fait.
Il restera les Freebox non dégroupées toujours en IPv4.
underground78 tu as une source pour l'info ?
-
tu as une source pour l'info ?
De ce que je comprends sur cet article -> https://ilovefree.actuly.fr/2019/03/26/free-annonce-que-la-prochaine-version-du-freebox-server-ne-permettra-plus-lactivation-ou-la-desactivation-de-lipv6/, visiblement c'est un changelog de l'app Freebox qui l'informe.
-
https://www.freenews.fr/freenews-edition-nationale-299/freebox-9/il-ne-sera-bientot-plus-possible-de-desactiver-ipv6-sur-freebox
L'article dit que la connexion 4G de la Delta ne fonctionne pas en IPv6, et suppose que le changement pourrait être une tentative de diminuer l’utilisation du réseau mobile.
Mais ça me semble très étrange, brider ou agir sur le choix des routes au niveau de la Freebox serait tout aussi efficace et beaucoup plus discret.
En plus Netflix utilise à priori l'IPv6 (à moins qu'il y ait un paramètre spécifique pour le réseau Free), et c'est un usage "officiel" de l'agrégation.
-
Si je ne me trompe pas, l'IPv6 n'est pas disponible sur le réseau freemobile ? Je ne sais pas si la solution "d'agrégation" de Free permet l'agrégation IPv4 et IPv6 ? D'après ce que j'avais compris, ce n'était pas une vrai agrégation, mais deux flux TCP différents.
-
Quelle est la date du prochain baromètre IPv6 ?
-
En novembre.
L'année dernière, le 10 octobre, c'était chaud pour avoir le retour de tous les opérateurs.
Cette année, il y aura tous les opérateurs de plus de 5000 clients, y compris sur les full-MVNO sur le mobile (sans oublier les DROM).
Il y aura probablement des informations supplèmentaires comme la présence de CG-NAt ou un autre mécanisme de partage d'IPv4 et le nombre de clients par IPv4 publique.
Pourquoi un tel délai alors que les informations sont demandées à fin juin ?
Pour les plupart des opérateurs, le questionnaire est mal rempli et il faut faire plusieurs aller / retour pour avoir la bonne réponse.
(Chaque aller / retour ce sont des semaines qui s'écoulent)
-
Merci vivien :)