Auteur Sujet: Adoption d’IPv6 en France: l’AOTA demande l’intervention de l’ARCEP  (Lu 15403 fois)

0 Membres et 1 Invité sur ce sujet


Leon

  • Client SFR sur réseau Numericable
  • Modérateur
  • *
  • Messages: 5 971
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.
« Modifié: 13 mai 2018 à 07:37:14 par Leon »

vivien

  • Administrateur
  • *
  • Messages: 47 083
    • Twitter LaFibre.info
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.

Leon

  • Client SFR sur réseau Numericable
  • Modérateur
  • *
  • Messages: 5 971
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.

raf

  • Expert France-IX
  • Expert
  • *
  • Messages: 645
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 !.

Leon

  • Client SFR sur réseau Numericable
  • Modérateur
  • *
  • Messages: 5 971
Citer
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?

Citer
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.

vivien

  • Administrateur
  • *
  • Messages: 47 083
    • Twitter LaFibre.info
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.

Gabi

  • Abonné SFR THD (câble)
  • *
  • Messages: 94

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.

Hugues

  • AS2027 MilkyWan
  • Modérateur
  • *
  • Messages: 12 424
  • Lyon (69) / St-Bernard (01)
    • Twitter
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...

Leon

  • Client SFR sur réseau Numericable
  • Modérateur
  • *
  • Messages: 5 971
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.

Hugues

  • AS2027 MilkyWan
  • Modérateur
  • *
  • Messages: 12 424
  • Lyon (69) / St-Bernard (01)
    • Twitter
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...

kgersen

  • Modérateur
  • Abonné Bbox fibre
  • *
  • Messages: 9 078
  • Paris (75)
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.