La Fibre
Télécom => Réseau => 
IPv6 => Discussion démarrée par: vivien le 08 mai 2018 à 08:13:36
-
Adoption d’IPv6 en France : l’AOTA demande l’intervention de l’ARCEP
(https://lafibre.info/images/ipv6/logo_ipv6_75x100.png)
Depuis sa création, l’association a souhaité être force de propositions au profit de l’innovation dans le secteur des télécoms en France.
Face au retard français qui s’accumule chez l’ensemble des acteurs et chez les clients finals in fine, l’AOTA a ainsi proposé à l’ARCEP d’engager de nouvelles actions en faveur du déploiement plus rapide et mieux coordonné du protocole IPv6.
Cela a pour objet de mettre en exergue et mettre un terme à des situations préjudiciables à tous les acteurs de la chaîne de valeur :
- Chez certains opérateurs, un partage d’adresses IPv4 entre plusieurs clients (une IPv4 “découpée” en ressource attribuée à plusieurs utilisateurs)
- Chez certains opérateurs de taille modeste et adressant essentiellement le marché B2B, une incapacité croissante à fournir des plages d’IPv4 dédiées à un client avec son service d’accès Internet en comparaison avec des acteurs de plus grande taille disposant de ressources IPv4 suffisantes ou ayant la capacité financière à s’en procurer massivement via le “grey market” dont il conviendrait de mesurer les impacts négatifs sur l’intensité concurrentielle en France et en Europe
- Chez certains services en ligne, l’impossibilité de disposer de ressources pour soutenir le développement de leurs innovations (IoT, M2M, etc) et l’incompatibilité de réseaux d’accès et/ou terminaux empêchant l’accès à ces nouveaux services et applications
- Chez quelques opérateurs, des différences de qualité d’accès constatées par les utilisateurs finals entre un accès IPv4 et IPv6 pour accéder à des services distants (plateformes OTT telles que Netflix, etc)
Au-delà de sa mission de production d’un observatoire régulier, il semblerait judicieux que le régulateur observe désormais le respect des obligations qui incombent à l’ensemble des acteurs du marché (opérateurs, équipementiers…) : en effet selon la loi République Numérique, « à compter du 1er janvier 2018, tout nouvel équipement terminal, au sens de l’article L.32 du code des postes et des communications électroniques, destiné à la vente ou à la location sur le territoire français devait être compatible avec le protocole IPv6 ». Cela ne semble pas être le cas pour tous les fournisseurs d’accès (services fixes ou mobiles) en sus de problèmes d’accès à certains services Internet ressentis par les utilisateurs finals chez plusieurs acteurs.
Il conviendrait de mesurer désormais auprès des acteurs du marché si celle-ci est respectée et si des actions correctives sont menées spontanèment pour parvenir à une compatibilité native avec IPv6 de l’ensemble des terminaux vendus ou loués aux consommateurs et personnes morales. Et par extension, de l’avancée réelle du déploiement et de l’utilisation d’IPv6 dans les réseaux d’accès français. L’association a suggéré l’ouverture d’une enquête administrative à ce sujet afin de disposer de données fiables.
L’AOTA propose enfin que l’ARCEP initie la création d’un groupe de travail et/ou “comité d’experts IPv6” permettant, en lien avec l’obligation mentionnée précédemment, de faire de la France l’une des locomotives de l’Internet de demain en Europe. Ce comité pourrait, outre les principaux opérateurs, réunir aussi des équipementiers, représentants d’éditeurs de services spécialisés (IoT, etc), associations de collectivités, services de l’État (ANSSI, DISIC, etc), afin de proposer des pistes et actions communes pour déployer plus rapidement ce protocole incontournable. Ce groupe aurait la charge de synchroniser son travail avec le BEREC, et éventuellement avec d’autres régulateurs étrangers, dans l’objectif de mener avec eux une action de plus grande envergure pour favoriser l’usage d’IPv6 en lieu et place du protocole IPv4 devenu limitant techniquement et commercialement.
Source : AOTA (https://www.aota.fr/2018/05/07/france-deploiement-ipv6-aota-demande-lintervention-de-larcep/), le 7 mai 2018
-
raf@Cha0S:~$ dig www.aota.fr in any +short
93.115.96.203
raf@Cha0S:~$ dig www.aota.fr in aaaa +short
raf@Cha0S:~$
?!?!?!?!?!? .....passons.....
Il serait deja interessant que les membres de l'AOTA pratiquent le "Eat your own dog food" avant de demander l'intervention du regulateur. Sur les 41 membres de l'AOTA il y a seulement 5 qui ont leur site disponible en IPv6.
Mais bon, esperons que malgre tout, cette initiative donnera des resultats positifs (et reels).
-
Et j'en connais certains qui n'en ont ouvertement rien a foute... :)
Pour mon AS (dans la liste des mauvais élèves) ça arrive bientôt, faut que je migre les routeurs de bordure :)
Mais de manière générale, IPv6 chez les pros, c'est quelque chose de difficile a déployer, parce que c'est par nature un milieu bordélique, et que IPv6 nécessite un peu de rigueur, on ne peut plus se cacher derrière le NAT, faut faire du vrai routage, avoir de vraies politiques de firewall, etc...
-
Sur les 41 membres de l'AOTA il y a seulement 5 qui ont leur site disponible en IPv6.
Tu ne listes pas les bon et mauvais élèves ? ("Name and shame")
Ce n'est pas pour défendre l'AOTA, mais ce n'est pas le passage à IPv6 qui va permettre de résoudre la problématique de pénurie d'IPv4 qui bloquent le développement de plusieurs opérateurs de l'AOTA.
Même si, rêvons, tous les FAI offraient de l'IPv6 à 100% de leurs clients, les hébergeurs seraient toujours contraints de mettre de l'IPv4 sur chaque serveur car tous ceux qui consultent Internet depuis des grandes entreprises sont en IPv4. Quelle entreprise du CAC40 permet à ses salariés d'accéder à des sites en IPv6 only ? Quelle entreprise du CAC40 prévoit de permettre à ses salariés d'accéder à des sites IPv6 only ?
Mettre IPv6 sur ses serveurs ou ses clients ne résout en rien la pénurie d'IPv4, c'est pour cela que beaucoup ne sont pas motivés pour passer à IPv6 : cela ne résout pas les problèmes de pénurie d'IPv4.
Pour résoudre le problème de pénurie d'IPv4 il faut qu'IPv4 ne soit plus utilisé. On sait que les grandes entreprises resteront en IPv4 jusqu'au moment où IPv4 sera arrêté, même si leur FAI leur offre IPv6.
La question importante n'est donc pas quand on force les opérateurs a passer à IPv6, mais quand on force les opérateurs à retirer IPv4.
-
Beaucoup d'employés des grands comptes accèdent au web par des proxy donc le protocole IPv4 ou IPv6 importe peu. Il suffit juste que les proxy finaux soient dual stack.
-
Effectivement, quand c'est un proxy configuré dans la machine cela devrait fonctionner, vu que la requête DNS est effectuée par le proxy et non par le poste client.
Par contre, avec un proxy « transparent » la connexion sera établie en IPv4, même si le proxy final est dual-stack, non ?
Avec un proxy « transparent », la résolution DNS est effectuée sur le poste client, qui va partir en IPv4...
-
Le cas d'usage dans la majorité des grandes entreprises c'est quand même le proxy Web non ?
-
Oui, pour des raisons évidentes de sécurité la grande majorité des entreprises ont un proxy.
Après il y a différents niveaux de sécurité :
- Proxy transparent (celui-là, j'ai des doute qu'il permette de surfer sur des sites IPv6 si le réseau local est en IPv4)
- Proxy web configuré dans le système / navigateur web.
- Proxy Man In The Middle (transparent ou non)
L'objectif est d'analyser le trafic qui passe et filtrer par URL, mots-clés ou loguer les pages visitées. L'objectif peut être de bloquer des sites CSA 5, de piratage, violence,... certaines entreprises bloquent aussi les sites qui permettent de partager des documents, ce qui facilite la fuite de documents, quant les ports USB sont bloqués.
Un proxy Man In The Middle permet d'inspecter le trafic https. Sa présence se vérifie par le fait que tous les sites sont signés par un même certificat, installé par l’administrateur du poste.
Sans man in the middle, on est limité a l'analyse du trafic http.
-
la plupart ont du MitM. via les stratégies de groupe de Windows ils poussent leur propres CA racines sur les postes clients. De fait tout les sites en HTTPS sont donc "MiTMables" facilement (via Interception ssl d'un proxy transparent par exemple).
-
Chez Bouygues Telecom (8000 salariés), le proxy pour les salariés n'a pas de MitM en 2018 : le certificat est celui du site (Let's Encrypt pour LaFibre.info par exemple)
On est bien d’accord que le certificat affiché n'est pas celui du site en cas de MitM ?
Exemple de MitM réalisé ici par un anti-virus :
(https://lafibre.info/images/ssl/201512_certificat_signe_par_avast.png)
Pour revenir au sujet IPv6, tu es en phase sur le fait qu'un proxy transparent ne permettra pas d'accéder a des sites IPv6 only, si le réseau local est en IPv4 only ?
-
Si, je le fais via du SOCKS5 régulièrement.
-
Ah oui, avec le version 5 de SOCKS, la résolution DNS semble faite sur le serveur SOCKS, ce qui permet de partir en IPv6 si ce dernier est connecté en dual-stack.
-
Yep, c'est simple et rapide comme techno, j'aime bcp !
-
Très utile aussi à travers un tunnel ssh pour résoudre les noms du réseau auquel on est connecté. Je m'en sers tout le temps.
Ne pas oublier de cocher la petite case (sur firefox du moins) Utiliser un DNS distant lorsque SOCKS v5 est actif
C'était aussi la méthode pour contourner le proxy quand j'étais au lycée. Je me rappelle d'une fois où j'avais mis putty sur mon poste, le prof avait coupé l'accès au net et moi je continuais à naviguer pendant que les autres se retrouvaient sans connexion ;D Et il se demandait comment c'était possible, mais je n'ai rien dit.
-
Je faisais pareil ;D
-
C'était un serveur SLIS aussi je suppose ? Le port ssh grand ouvert pour les services académiques ?
-
Même pas, un OpenSUSE chelou.
Mon prof de réseau était un incompétent notoire qui assignait le réseau local sur un /8 public (et très utilisé en France) tout en ne sachant pas ce qu'est BGP ou IPv6... :)
-
Ouch... le réseau local du lycée ? ou un réseau de test en cours ? Si le premier ça craint :o
Chez nous c'était quand même mieux organisé, chaque salle avait un /24 privé (172.16.x.x) avec la possibilité de couper l'accès au net individuellement.
C'est d'ailleurs en lisant la doc du slis que je me suis rendu compte que le port 22 était ouvert, j'ai testé et ça a fonctionné, merci le libre :)
-
C'était sur le 80.0.0.0/8 :]
-
Ah oui d'accord... il avait pas froid aux yeux. Et vous aviez pas des problèmes d'accès des fois ? Bizarre que ce ne soit pas l'académie qui dicte les règles en matière de réseau (lycée privé ?)
Remarque, j'ai fait un stage dans une entreprise qui adressait ses postes en 192.1.1.x, et si j'ai bien cherché ce rang appartient à BBN Communications. Enfin dans ce cas y'a quand même beaucoup moins de chance de tomber dessus. Sans compter que l'accès au net était proxysé avec user/mdp, donc ça réduit encore les risques.
-
Evidemment que si, genre l'espace numérique de travail de l'école qui ne marchait pas :p
Comme je te dis, abruti...
-
Et ben... et personne ne lui a fait la réflexion ?
Parce que entre ne pas avoir certaines notions et utiliser des ip publiques pour adresser un LAN, faut revoir les fondamentaux à ce niveau ::)
-
Si si, moi. Les autres gens de la classe n'avaient aucune idée de ce qu'était une IP privée...
Mais en France, un élève qui corrige un prof, c'est très mal vu, alors que c'est juste normal...
-
Mais vu que ça concernait tout le lycée il n'a pas été viré pour incompétence ou un truc du genre ? Car j'imagine que ça devait aussi gêner l'administration...
-
Même si, rêvons, tous les FAI offraient de l'IPv6 à 100% de leurs clients, les hébergeurs seraient toujours contraints de mettre de l'IPv4 sur chaque serveur car tous ceux qui consultent Internet depuis des grandes entreprises sont en IPv4. Quelle entreprise du CAC40 permet à ses salariés d'accéder à des sites en IPv6 only ? Quelle entreprise du CAC40 prévoit de permettre à ses salariés d'accéder à des sites IPv6 only ?
Mettre IPv6 sur ses serveurs ou ses clients ne résout en rien la pénurie d'IPv4, c'est pour cela que beaucoup ne sont pas motivés pour passer à IPv6 : cela ne résout pas les problèmes de pénurie d'IPv4.
Pour résoudre le problème de pénurie d'IPv4 il faut qu'IPv4 ne soit plus utilisé. On sait que les grandes entreprises resteront en IPv4 jusqu'au moment où IPv4 sera arrêté, même si leur FAI leur offre IPv6.
Si tu vends de l'infrastructure "OVH-style" avec des serveurs individuels que tu exposes directement sur Internet, c'est sûr que tu es bien parti pour continuer à attribuer des IPv4 publiques encore longtemps.
Mais pour beaucoup d'utilisations, tes serveurs/instances sont souvent derrière des load-balancers ou dans des Virtual Networks. Dans ce cas, tu peux très bien te contenter d'attribuer de l'IPv4 publique seulement à tes frontaux exposés sur Internet. S'il y a besoin d'un accès aux instances individuelles, tu peux alors leur attribuer seulement une IPv6 (ou même pas d'IP publique du tout et utiliser une passerelle VPN).
Perso, je ne crois pas à la disparition d'IPv4. Les incitations à passer à de l'IPv6 (ou implèmenter du dual-stack) proprement ne sont pas assez fortes, et, faut le dire c'est quand même tout un bordel : cf tous les problèmes qu'on décrit sur ce forum à propos d'Ubuntu qui perd ses IP sur un reboot.
Autre anecdote : chez Orange, si vous souhaitez utiliser l'option IP fixe, vous perdez la connectivité IPv6. Un peu dommage pour une option qui est très utile pour les pros...
-
Tu ne listes pas les bon et mauvais élèves ? ("Name and shame")
Je vais lister les bons eleves, car ils sont bien moins nombreux:
- FullSave
- Voxity
- K-Net
- WideVOIP
- Netiwan
Le reste sont tous des "mauvais eleves". A eux ils faut rajouter deux "special guests - mauvais eleves" en relation avec le sujet : AOTA et ARCEP.
Apres, je peux comprendre qu'on peut etre "mauvais eleve" cote site web, mais "bon eleve" sur d'autres sujets comme le deploiement vers les clients, mais ca c'est plutot l'exception.
-
5 stars:
https://ip6.nl/#!k-net.fr
https://ip6.nl/#!voxity.fr
4 stars:
https://ip6.nl/#!fullsave.com
WideVoip
3 stars:
https://ip6.nl/#!netiwan.fr
-
A eux ils faut rajouter deux "special guests - mauvais eleves" en relation avec le sujet : AOTA et ARCEP.
L'ARCEP est en train de changer d'hébergeur pour un qui "supporte" IPv6.
-
A eux ils faut rajouter deux "special guests - mauvais eleves" en relation avec le sujet : AOTA et ARCEP.
A noter que le concurrent de l'AOTA, la FFT est lui en IPv6. (La FFT regroupe Arteria, Bouygues Telecom, Colt, Euro-Information Telecom, Hub One, Kosc Telecom, La Poste Mobile, Legos, Naxos, Orange, Prosodie, Altice-SFR, Verizon France et Worldline)
-
Du coté de l'AOTA, le serveur utilisé a bien une IPv6, juste qu'on a pas eu le temps de l'implanter sur le serveur web et sur l’enregistrement DNS du domaine. Notre première année d’existence a été assez ... intensive :)
Ça sera corrigé dans quelques jours.
-
L'ARCEP est en train de changer d'hébergeur pour un qui "supporte" IPv6.
C'est bien.
D'où tu le sais ?
-
De moi sur Twitter :p
https://twitter.com/huguesdelamure/status/991614914400800769
"@pbeyssac @AotaFr Ils sont entrain de changer d’hébergeur parce que l’actuel refuse d’implèmenter IPv6, c’est pas beau de médire sans savoir ;)"
-
@Hugues : ça n'a rien à voir avec le sujet, mais as-tu bien reçu mes derniers MP ?
-
Yep, mais je suis en congés :)
-
Ah ok. Je pensais qu'il y avait un bug. Bonnes vacances alors ;) (j'ai vu passer ta photo de saint-malo sur twitter j'y ai pensé après coup).
-
A noter que le concurrent de l'AOTA, la FFT est lui en IPv6.
Euh, c'est pas plutôt Alternative Télécom le "concurrent" de l'AOTA plutôt ?
-
J'ai déplacé les messages sur L'Arcep publie sa décision de règlement d'un différend opposant Orange à Free et Free mobile sur les modalités d'interconnexion IP et TDM : uniquement IPv6 pour Free vs uniquement IPv4 pour Orange (https://lafibre.info/ipv6/arcep-differend-ipv6/) dans le sujet qui lui est dédié.
-
J'ai 2 questions, pour m'aider à comprendre la situation (j'y connais rien en IPv6) :
* un client IPv6 only peut-il accéder à des serveurs IPv4 only, d'une façon ou d'une autre?
* un client IPv4 only peut-il accéder à des serveurs IPv6 only, d'une façon ou d'une autre?
Même si, rêvons, tous les FAI offraient de l'IPv6 à 100% de leurs clients, les hébergeurs seraient toujours contraints de mettre de l'IPv4 sur chaque serveur car tous ceux qui consultent Internet depuis des grandes entreprises sont en IPv4. Quelle entreprise du CAC40 permet à ses salariés d'accéder à des sites en IPv6 only ? Quelle entreprise du CAC40 prévoit de permettre à ses salariés d'accéder à des sites IPv6 only ?
Mettre IPv6 sur ses serveurs ou ses clients ne résout en rien la pénurie d'IPv4, c'est pour cela que beaucoup ne sont pas motivés pour passer à IPv6 : cela ne résout pas les problèmes de pénurie d'IPv4.
Pour résoudre le problème de pénurie d'IPv4 il faut qu'IPv4 ne soit plus utilisé. On sait que les grandes entreprises resteront en IPv4 jusqu'au moment où IPv4 sera arrêté, même si leur FAI leur offre IPv6.
La question importante n'est donc pas quand on force les opérateurs a passer à IPv6, mais quand on force les opérateurs à retirer IPv4.
Retirer IPv4? Ca n'est pas prêt d'arriver, on est d'accord?
Si on considère que l'ensemble des clients veulent accéder à l'ensemble des serveurs de la planète, alors il faut attendre que l'ensemble de la planète gère l'IPv6 avant de commencer à retirer des IPv4, non? Et c'est pas prêt d'arriver...
Existe-t-il des solution pour résoudre ce problème ?
Perso, j'ai du mal à voir comment on peut assurer cette transition à l'échelle de la planète entière.
Si d'un côté les opérateurs attendent l'extinction d'IPv4 pour basculer à IPv6, et si de l'autre côté l'extinction d'IPv4 ne peut se faire que si tout le monde a basculé en IPv6, on a un joli problème de poule et d'oeuf, de serpent qui se mord la queue, etc...
Leon.
-
J'ai 2 questions, pour m'aider à comprendre la situation (j'y connais rien en IPv6) :
* un client IPv6 only peut-il accéder à des serveurs IPv4 only, d'une façon ou d'une autre?
* un client IPv4 only peut-il accéder à des serveurs IPv6 only, d'une façon ou d'une autre?
IPv6 est incompatible avec IPv4 et inversement IPv6 est incompatibles avec IPv4.
Un client IPv6 only peut-il accéder à des serveurs IPv4 only, via du DNS64 et du NAT64 : Cela nécessites deux plateformes chez le FAI : Un DNS64 va renvoyer une IPv6 pour les sites IPv4 only. Un NAT64, une plateforme qui a des IPv4 publiques va natter la demande qui arrive en IPv6 vers le site IPv4 only, comme le fait un CG-NAT avec des IPv4 privées à la place des IPv6.
C'est en production sur les mobiles Android récent chez Bouygues Telecom, le but étant d'économiser des IPv4 privées.
Un client IPv4 only peut accéder à des serveurs IPv6 only via un mécanisme inverse : un proxy qui est lui connecté en IPv6 coté Internet et sur le réseau local en IPv4.
Retirer IPv4? Ca n'est pas prêt d'arriver, on est d'accord?
Si on considère que l'ensemble des clients veulent accéder à l'ensemble des serveurs de la planète, alors il faut attendre que l'ensemble de la planète gère l'IPv6 avant de commencer à retirer des IPv4, non? Et c'est pas prêt d'arriver...
Existe-t-il des solution pour résoudre ce problème ?
Perso, j'ai du mal à voir comment on peut assurer cette transition à l'échelle de la planète entière.
Si d'un côté les opérateurs attendent l'extinction d'IPv4 pour basculer à IPv6, et si de l'autre côté l'extinction d'IPv4 ne peut se faire que si tout le monde a basculé en IPv6, on a un joli problème de poule et d'oeuf, de serpent qui se mord la queue, etc...
Oui, ce n'est pas prêt d'arriver. Je pense que si on ne force pas les choses, dans 40 ans il y aura toujours de l'IPv4 chez les FAI (avec du CG-Nat). Cette situation va entrianer un prix de l'IPv4 qui augmente car si les FAI utilisent peu d'IPv4, les hébergeurs en ont toujours besoin.
D'où l'idée de forcer la fin de l'IPv4 dans 15 ans au niveau de l'Europe, avec si possible des grand sites comme Google qui arrêtent au niveau mondial IPv4, afin de forcer les pays qui ne sont pas eu Europe a passer aussi en IPv6.
-
Merci Vivien, ça confirme mes craintes.
De plus, une autre réflexion :
A priori, ça n'est pas du tout dans l'intérêt des "fournisseurs de contenu et d'applications" de basculer à IPv6. Voici mon raisonnement:
Vu la pénurie d'IPv4 qui se fait déjà sentir (de plus en plus d'utilisateurs ont une IP partagée), il devient de plus en plus difficile pour 2 utilisateurs finaux de communiquer en direct entre eux en IP. Je parle des gens qui veulent ouvrir des ports vers l'extérieur pour avoir une visibilité "publique", pour plein de raisons : P2P, alarme ou vidéo accessible à distance, serveur de jeu en local...
Une des solutions serait évidemment de passer à IPv6, pour que les utilisateurs puissent continuer à pouvoir communiquer en direct.
Mais une autre solution, c'est de passer par des serveurs centraux pour réaliser les mêmes fonctionnalités, tout en restant en IPv4. Solution en apparence beaucoup plus simple pour l'utilisateur final, quelle que soit sa configuration, même caché derrière un NAT (voire un proxy). On installe l'application, et ça fonctionne, point. Skype et plein d'autres services fonctionnent sur ce modèle.
Toutes les appli mobiles fonctionnent comme ça, et l'utilisateur final trouve ça très pratique : aucune question à se poser, ça marche et c'est tout.
Et là, c'est tout bénef pour les fournisseur de contenu ou d'applications, qui s'assurent que les utilisateurs passent durablement par leurs services, et leurs serveurs, plutôt que d'utiliser des solutions "ouvertes".
Bref, ces gens là n'ont pas forcèment intérêt à accélérer le basculement en IPv6.
Et comme je le disais dans un autre post, un gros hébergeur, fournisseur de cloud, solution cloud, sait facilement économiser des IPv4, et il a besoin de beaucoup moins d'IPv4 qu'il n'a de serveurs (grâce à des load balancer + reverse proxy). Donc la pénurie d'IPv4 n'est pas un problème pour lui.
Perso, pour mon propre usage, cette 2ieme solution me convient, mais je comprends qu'elle soit critiquée par les promoteurs d'un internet ouvert (j'entends déjà Benjamin Baillard gueuler d'ici). Le seul truc qui me dérange avec ce modèle, c'est qu'on n'a pas la garantie que les "services/serveurs" proposés par ces fournisseurs sont durables (entreprise qui coule, fusion d'entreprise, changement radical de politique).
Leon.
-
Si jamais on veut que la situation evolue, faut arreter de faire l'association IP = IPv4, mais passer a IP = IPv6.
La connectivite end-to-end en IPv4 est deja morte, il faut arreter d'inister sur le sujet. Meme si aujourd'hui le CGN n'est pas la regle pour les FAI "fixes", il va y avoir de plus en plus de clients concernes, chez de plus en plus de FAI.
Concernant l'interet, de deployer IPv6 (on ne passe pas "en IPv6", on deploie IPv6 au meme titre qu'IPv4), pour les FAI ca commence a etre evident à partir d'une certaine taille. Ca peut ne pas etre encore evident pour le petit FAI de 200-400 clients entreprise, mais des qu'on fait du grand public en masse ou on est assez grand meme cote "pro", ca commence a se voir. Sauf a etre sur une vision limite a "plus tard aujourd'hui".
Pour les hebergeurs/fournisseurs de contenu, ca va arriver. L'e-commerce risque d'etre le premier impacte par le CGN, les autres vont juste suivre.
Concernant le "tout centralise", il faut pas imaginer que faire du NAT pour 10 personnes (disons 20 devices et 200 connexions en simultanee) c'est le meme chose que faire du CGN pour 100000 clients (pareil, avec quelques centaines de connexions en simultanee par client). Le service s'il sera disponible en dual-stack va forcement etre mieux en IPv6 (ou le reseau devra garder moins - lire pas - de donnees sur l'etat des connexions).
Deja, si on veut en tant que FAI faire du IPv6 et l'offrir aux clients, la situation est nettement meilleure qu'il y a 2 ou 3 ans. Depuis fin avril, nous avons des clients avec IPv6 sur les 4 3 operateurs d'infrastructure, alors qu'il y a 3 ans c'etait quelque-chose de risque, possible chez un seul (sur 4 a l'epoque). En offre pro, c'est possible quasiment partout, et depuis un certain temps deja. Ca fait pas serieux de le dire, mais c'est vrai : YAKA !.
-
L'e-commerce risque d'etre le premier impacte par le CGN, [...]
Que veux tu dire? Impacté comment, pourquoi? Les CGN leur rendrait la vie difficile aux e-commerçants? Pourquoi ça?
Concernant le "tout centralise", il faut pas imaginer que faire du NAT pour 10 personnes (disons 20 devices et 200 connexions en simultanee) c'est le meme chose que faire du CGN pour 100000 clients (pareil, avec quelques centaines de connexions en simultanee par client).
Peux-tu être plus explicite, stp? Que veux tu dire? Que c'est complexe de faire du CGNAT pour 100 000 clients? Mais les opérateurs mobiles le font déjà depuis très longtemps, avec des débits qu'on n'aurait pas imaginé il y a 10 ans sur le mobile. Donc techniquement, ça ne semble pas être une si grande difficulté.
Bien évidemment, il faut rester dans des ratios "IP privée / IP publique" raisonnables, sinon on rencontre vite des problèmes. Mais rien qu'avec 10 IP privées pour 1 IP publique, le gain est énorme!
Et puis il y a les bidouilles de type free sur le fixe : sans rajouter d'équipement à priori, ils mutualisent 1 IP pour 4 accès, avec des plages de port bien définies pour chaque accès. C'est comme si leurs équipements considérait 2 bits supplèmentaires du champ "port client" pour les adresses IP clients.
Leon.
-
Bien évidemment, il faut rester dans des ratios "IP privée / IP publique" raisonnables, sinon on rencontre vite des problèmes. Mais rien qu'avec 10 IP privées pour 1 IP publique, le gain est énorme!
Certains mettent plusieurs centaines de clients par IP a un instant t. On peut même arriver a plus de 1000 clients simultanèment, ce qui pose des pb pour les applications qui utilisent de nombreuses connexions TCP. Certains applications n’apprécie pas qu'une port TCP fermée soit immédiatement ré-ouvert pour un autre usage, sans rester plusieurs secondes en TIME_WAIT. Quand on peu de port TCP disponibles, i est impossible de laisser les ports une minute dans l’état TIME_WAIT, sinon c'est la pénurie de port TCP.
C'est normal, et pas vraiment problématique
Une bonne explication sur ça:
L’état TIME-WAIT a deux buts : Le premier est d’empêcher les segments en retard d’être acceptés dans une connexion utilisant le même quadruplet (adresse source, port source, adresse cible, port cible). La RFC 1337 explique en détail ce qui peut arriver si l’état TIME-WAIT ne joue pas son rôle.
Le second but est d’assurer que l’hôte distant a bien fermé la connexion. Lorsque que le dernier ACK est perdu, l’hôte distant reste dans l’état LAST-ACK3. Si l’état TIME-WAIT n’existait pas, une connexion vers cet hôte pourrait être tentée. Le segment SYN peut alors être accueilli avec un RST.
La RFC 793 demande à ce que l’état TIME-WAIT dure au moins deux fois le MSL. Sur Linux, cette durée n’est pas configurable. Elle est définie dans include/net/tcp.h et vaut une minute
Les statistiques pour ce forum :
Je regarde les connexions TCP/IP sur lafibre.info.
C'est vraiment énorme le nombre de connexions en TIME_WAIT (274 !)
$ netstat -an|awk '/tcp/ {print $6}'|sort|uniq -c
1 CLOSE_WAIT
24 ESTABLISHED
3 FIN_WAIT1
36 FIN_WAIT2
2 LAST_ACK
9 LISTEN
274 TIME_WAIT
ESTABLISHED:La socket a une connexion établie.
SYN_SENT: La socket attend activement d'établir une connexion.
SYN_RECV: Une requête de connexion a été reçue du réseau.
FIN_WAIT1: La socket est fermée, et la connexion est en cours de terminaison.
FIN_WAIT2: La connexion est fermée, et la socket attend une terminaison du distant.
TIME_WAIT: La socket attend le traitement de tous les paquets encore sur le réseau avant d'entreprendre la fermeture.
CLOSED: La socket n'est pas utilisée.
CLOSE_WAIT: Le distant a arrêté, attendant la fermeture de la socket.
LAST_ACK: Le distant termine, et la socket est fermée. Attente d'acquittement.
LISTEN: La socket est à l'écoute de connexions entrantes. Ces sockets ne sont affichées que si le paramètre -a,--listening est fourni.
CLOSING: Les deux prises sont arrêtées mais toutes les données locales n'ont pas encore été envoyées.
UNKNOWN: L'état de la prise est inconnu.
-
Et là, c'est tout bénef pour les fournisseur de contenu ou d'applications, qui s'assurent que les utilisateurs passent durablement par leurs services, et leurs serveurs, plutôt que d'utiliser des solutions "ouvertes".
Bref, ces gens là n'ont pas forcèment intérêt à accélérer le basculement en IPv6.
Et comme je le disais dans un autre post, un gros hébergeur, fournisseur de cloud, solution cloud, sait facilement économiser des IPv4, et il a besoin de beaucoup moins d'IPv4 qu'il n'a de serveurs (grâce à des load balancer + reverse proxy). Donc la pénurie d'IPv4 n'est pas un problème pour lui.
Sauf qu'en pratique, c'est plutôt l'inverse qui se produit. Les "gros" proposent voire poussent IPv6 : Amazon, Microsoft Azure, Google Cloud Platform permettent tous à leurs clients d'exposer leurs services en IPv6 (c'est pas toujours hyper simple, mais c'est faisable).
De même, les gros fournisseurs de contenu (Netflix, Youtube, Facebook) ainsi que les principaux CDN (CloudFlare, Fastly, Akamai...) sont tous compatibles IPv6.
Je me trompe peut-être, mais je n'ai pas l'impression que la raréfaction des ressources en IPv4 fasse partie du business model des gros acteurs du Web. Leur intérêt est probablement plus en ayant (ou en fournissant) un accès "direct" à l'utilisateur final, en préférant de l'IPv6 plutôt que des étages de CG-NAT là où c'est possible.
-
Pour moi, le plus gros frein a v6, c'est les petits hébergeurs, et les petits FAIs.
C'est très con, les petits acteurs sont censés être plus réactifs et plus compétents, mais là non...
-
Pour moi, le plus gros frein a v6, c'est les petits hébergeurs, et les petits FAIs.
C'est très con, les petits acteurs sont censés être plus réactifs et plus compétents, mais là non...
Et je rajouterai les nombreuses entreprises (PME et autre), clientes d'un FAI, et qui ont un réseau interne pour lequel elles dépensent le moins d'argent possible, parfois avec des routeurs assez anciens et que personne n'administre réellement.
Pour les grosses entreprises, je ne me fais pas de soucis. S'il faut y passer, elles sauront faire. Mais pour les PME, ça va potentiellement coincer.
Leon.
-
Une fois que 90% du trafic sera en v6, on pourra virer v4 du backbone et laisser juste des NAT v6 vers v4 pour les dinosaures :)
Je ne suis pas très inquiet pour ça...
-
Une fois que 90% du trafic sera en v6, on pourra virer v4 du backbone et laisser juste des NAT v6 vers v4 pour les dinosaures :)
Je ne suis pas très inquiet pour ça...
du trafic en volume ou en session?
parce que en volume, rien qu'avec les GAFAM + Netflix qui sont deja en IPv6 on doit pas être loin des 90% pour les clients qui ont IPv6.
-
90% en volume.
Pour gérer un réseau ou 100% des hôtes sont en IPv6, je peux te confirmer qu'on en est loin :)
-
90% en volume.
Pour gérer un réseau ou 100% des hôtes sont en IPv6, je peux te confirmer qu'on en est loin :)
combien d’hôtes ? sont-ils représentatifs de la population générale ?
-
Une petite centaine maintenant.
Ben c'est des geeks, donc ils sont censés être plus utilisateurs même ! ;-)
-
parce que en volume, rien qu'avec les GAFAM + Netflix qui sont deja en IPv6 on doit pas être loin des 90% pour les clients qui ont IPv6.
G - oui, c'est eux qui prennent l'IPv6 le plus au serieux. Ca fait que c'et eux qui generent a peu pres moitie du traffic v6
A(pple) - v6 - negligeable
F - ratio v4/v5 presqu'au meme niveau que G, mais volume 5-6 fois moins important
A(kamai) - pas beaucoup de v6. deja que c'est difficile d'identifier le traffic Akamai en raison de la conception de leur systeme (de CDN)
M - assez peu de traffic v6
Netflix - etonnament peu de traffic v6 par rapport au v4.
Voila la situation de nos jours....
-
Pareil pour Netflix, j'ai beaucoup plus de v4 que de v6. Je pense que ça vient de certaines TV/Box pas compatibles, sans certitudes...
-
G - oui, c'est eux qui prennent l'IPv6 le plus au serieux. Ca fait que c'et eux qui generent a peu pres moitie du traffic v6
A(pple) - v6 - negligeable
F - ratio v4/v5 presqu'au meme niveau que G, mais volume 5-6 fois moins important
A(kamai) - pas beaucoup de v6. deja que c'est difficile d'identifier le traffic Akamai en raison de la conception de leur systeme (de CDN)
M - assez peu de traffic v6
Netflix - etonnament peu de traffic v6 par rapport au v4.
Voila la situation de nos jours....
pour un client qui a IPv6 ou quelque soit le client ?
-
Du coté de l'AOTA, le serveur utilisé a bien une IPv6, juste qu'on a pas eu le temps de l'implanter sur le serveur web et sur l’enregistrement DNS du domaine. Notre première année d’existence a été assez ... intensive :)
Ça sera corrigé dans quelques jours.
Le site web de l'AOTA arrive timidement en IPv6...
Le AAAA sur le domaine racine est oublié et les DNS ne gèrent pas IPv6 :
(https://lafibre.info/images/ipv6/201806_aota_web_ipv6_1.png)
A noter que dans mon cas la latence IPv6 (via Cogent) est plus basse que celle en IPv4 (via Ielo) :
(https://lafibre.info/images/ipv6/201806_aota_web_ipv6_2.png)
Derrière cette bonne nouvelle se cache une mauvaise : le peering n'est pas aussi développé en IPv6 qu'en IPv4.
-
pour un client qui a IPv6 ou quelque soit le client ?
Pour l'ensemble des clients (Coriolis). Je vais pas perde mon temps de faire de l'echantionnage par client.
D'ailleurs la distribution du traffic IPv6 cote Google dit beaucoup des types de clients qui utilisent IPv6 (massivement GP/residentiel) ou non (plutot pro/entreprise).
-
Derrière cette bonne nouvelle se cache une mauvaise : le peering n'est pas aussi développé en IPv6 qu'en IPv4.
Ça c'est bien vrai.
A noter que dans mon cas la latence IPv6 (via Cogent) est plus basse que celle en IPv4 (via Ielo) :
Pas par ici...
-
J'ai un ressenti un peu étrange vis à vis de ce communiqué de l'AOTA.
A part chouiner auprès du régulateur sans vraiment proposer de plan d'action (mis à part l’habitude très Française de vouloir créer un groupe de travail). Je ne vois pas bien ce que ça apporte.
Je me demande si il n'est pas un peu naïf de penser que l'ARCEP va faire avancer les choses ...