Vivien,
Elad est très sérieux dans son raisonnement, il agresse tous ceux qui sont contre lui, et il est *candidat* au Board du RIPE.
Je vais copier coller la réponse de Johann sur FRnOG parce qu'il est hors de question de laisser ce genre de bêtises sur ce forum sans débunk :
Pour répondre un peu plus sur la partie technique, car j'imagine que beaucoup de gens ici n'ont pas pris le temps de lire l'ensemble du thread.
Ou n'ont tout simplement pas le background technique suffisant (ce n'est pas une insulte) pour juger en profondeur de celle-ci.
TECHNIQUEMENT PARLANT :
Son idée, c'est de dire qu'on va créé une extension d'IPv4, qui utiliserait la même structure de paquet et qui serait en plus rétrocompatible.
Cela permettrait de doubler le nombre d'IPv4 disponible et donc d'éviter l'apocalypse. Ça c'est la promesse papier électorale.
Humainement parlant, on aurait les IPv4 classiques [0-255].[0-255].[0-255].[0-255] et les IPv4+ [0-65535].[0-65535].
Côté équipement, il propose d'utilisé le bit "réservé" dans la partie FLAG du header IPv4 pour indiqué si c'est de l'IPv4+.
Après tout, pourquoi pas, même si on sait d'expérience qu'un bit ou une plage d'IP réservée est souvent difficile à utilisé dans le futur.
Mais la où ça commence à sentir mauvais, c'est quand on lit le détail de la technique et du déploiement.
Celui-ci propose d'utiliser les autres bits de la partie FLAG, le bit DF (don't fragment) et MF (more fragment), qui eux sont utilisés dans nos réseaux pour la gestion de la fragmentation.
C'est à dire qu'à partir de ce moment dans la lecture, on casse tout ce qui est mécanisme de fragmentation de paquet sur les réseaux IPv4 "legacy".
Ces bits DF et MF seraient utilisés pour savoir si l'adresse source ou de destination est au format IPv4+. Pour la rétrocompatibilité avec IPv4.
Où clairement j'ai halluciné, c'est sur la justification de pourquoi ces bits :
- Le champs ToS peut être modifié sur le chemin
- Le champs IP-ID peut être modifié sur le chemin
- Les champs DF et MF ne peuvent pas modifiés sur le chemin (!?!!!??)
Ce monsieur justifie que les bits de fragmentation sont "optional by design" et que si on connait la MTU, on en a en faite pas besoin.
Ce qui est absolument faux, c'est d'ailleurs tout le principe de la chose.
On ne peut pas connaitre la MTU sans MTU Path discovery, qui se base sur... le DF bit (et ICMP, souvent filtré d'ailleurs). Aie.
D'ailleurs, on ne peut pas être sur que le chemin aura la même MTU dans le temps. Vous pouvez très bien avoir un changement de route au milieu du chemin qui change la MTU maximal disponible.
Si un routeur sur le chemin passe d'un réseau à un autre avec une MTU plus petite, il fragmentera de lui-même les paquets si le bit DF n'est pas activé.
Alors bien sur, par contre il pense bien à créé une nouvelle méthode de détection de MTU pour son IPv4+, mais ça ne semble pas le déranger plus que cela de casser celle d'IPv4.
Je pense que cela vient du fait qu'il ne sait simplement comment fonctionne la fragmentation et BGP.
Bon déjà à ce moment la, on sait que c'est mort.
Mais si on continue de lire un peu son idée de déploiement, on tombe littéralement de sa chaise :
- Il suffit de réunir une table ronde avec les 5 RIR, une personne représentante par d'OS, et une personne de chaque équipementier. Et magiquement cela sera adopté par tous.
- Il suffira de mettre à jour chaque OS via les mises à jour automatiques (il aime beaucoup insisté sur les mises à jour automatiques dans ses messages) et chaque routeur BGP (parfois automatiquement, parfois non).
- Et hop, voila ça fonctionnera comme par magie
L'argument fort serait que les LIR pourraient avoir beaucoup de nouvelles IPs et donc qu'ils feront pression sur leurs fournisseurs pour que IPv4+ soit disponible sur leurs réseaux.
On a vu ce que donnait IPv6 qui rajoute encore plus d'adresse IP, mais on va dire que ce n'est pas toute à fait la même chose ;-)
Et encore plus fort, c'est que pour lui, on peut partir sur un déploiement en 2, 4, allez au pire 8 semaines (!). En proposant plein d'IP d'un coup si on déploie vite.
En effet, on aurait la mise à jour automatique des OS et seul les routeurs BGP devrait avoir une "petite mise à jour".
Parceque ce n'est "qu'une petite modification du header".
Bon, un peu de sérieux.
Les problématiques de sa proposition :
1) Il casse la fragmentation d'IPv4
2) Il utilise un bit réservé qui posera sans doute soucis sur des vieux équipements
3) Une table ronde, si elle avait la moindre chance d’exister un jour (ce que je doute), ne garantie en rien le résultat d'adoption universelle. Et un concours de muscle ne changera rien.
4) Il sous estime totalement le processus de mise à jour. Non ça ne sera pas qu'une simple "petite mise à jour software". Déjà parce-que beaucoup d'équipements actif sur internet ne reçoivent plus de mise à jour de leur constructeur pour ce genre de chose. On a encore de vieux OS en production qui supporte pas IPv6, alors IPv4+, je ne parle pas des milliards d’objet IoT chinois (ou non) perdu partout dans le monde. Et j'ose même pas imaginer les tablettes/smartphones dans l'histoire.
4.5) La grande majorité des équipements réseaux actuels, surtout chez les opérateurs, se basent sur des ASIC ou équivalent qui sont construit pour IPv4 et IPv6.
La moindre modification demanderait de réécrire le firmware hardware, voir un changement d'ASIC (dur de s'avancer sans la vision constructeur).
5) En plus, il occulte totalement la partie intégration des ces "nouvelles IPs" dans la table de routage. Aucun volet technique n'est présent à ce sujet.
Comment l'équipement doit le gérer? Ça a une influence sur la RIB et la FIB de chaque routeur et donc le comportement des ASIC.
Pourtant, un paquet sont but c'est d'être forwarder vers son destinataire, oublier cette partie est un peu étonnant.
6) On ne parle pas non plus de l'intégration de ces nouvelles IPs dans le protocole BGP. J'imagine qu'il faudra une nouvelle AFI?
Puis comment on les forwards sur les interconnexions? Il faudra sans doute rajouter une IPv4+ sur les intercos opérateurs?
Ou ca sera "compatible" via IPv4 classique? La encore, aucune information, aucune étude et aucun PoC...
D'ailleurs, si un paquet IPv4+ passe par un routeur IPv4 non mis à jour, il sera router vers la mauvaise adresses IP legacy correspondante.
Ça sera assez cocasse quand même, surtout avec de l'UDP. Ça va donner de nouvelle manière de DDoS intéressante :-)
6.5) On ne parle pas du toute de l'intégration de BGP, mais pas non plus des IGP. Quid de OSPF, ISIS, EIGRP? Ce sont des protocoles indépendants et qui devront aussi recevoir une mise à jour, sinon ca ne marchera pas.
Et je ne suis pas certain que beaucoup soit chaud pour pousser en production un patch "tout frais" de leur IGP, au risque de vautré leur réseau.
7) Il n'a aucune idée de commence marche un process de mise à jour d'un opérateur Ce n'est pas une mise à jour automatique avec deux clique dans une UI. On choisi une version cible, on la test en lab, on la valide, on peut faire des bugfix avec le constructeur.
Une fois la validation effectuée, on déploie la nouvelle version progressivement sur l'ensemble du backbone, souvent sur plusieurs long mois. Chez un opérateur, on évite de faire des mises à jours tout les mois de nos équipements.
8 ) Il faudra que l'ensemble des OS, de systèmes de sécurités et box opérateurs soient mise à jour (en oubliant volontairement la partie opérateur)
Si un seul équipement actif (NAT, comme sur une box domestique) ou l'OS n'est pas à jour, ca ne marchera pas correctement. D'ailleurs, il faudra aussi que l'ensemble des équipements de sécurité, type firewall, IDS et IPS soit mise à jour.
9) Il oublie totalement la partie logiciel qui utilise internet C'est bien beau de mettre à jour l'OS... mais il oublie qu'il faut que les applications soient mise à jour pour être rendu compatible. On ne rend pas compatible une application en mettant à jour l'OS. Il faut la rendre compatible avec le nouveau format d'IP et tout ce que cela implique.
10) Il oublie totalement la partie "3rd"/dépendance J'imagine qu'on voudra mettre des nom de domaine sur ces nouvelles IPs. Du coup, il faudra aussi mettre à jour les serveurs DNS pour les prendre en charge avec un nouveau type d'enregistrement. Cela rajoute une couche et un délai.
10) Il oublie totalement la partie humain Je ne crois pas une seconde que tout les DSI/RSI du monde seront d'accord sans la moindre question ou étude avant
11) Ca va encore ralentir l'adaptation d'IPv6 bordel de merde.
Et j'imagine que j'oublie sans doute des choses.
Je suis désolé pour ceux qui ont vu la belle promesse électorale de Elad. Mais clairement, l'idée aurait été intéressante il y a 20 ou 25 ans, maintenant on a IPv6 qui a passé l'ensemble des points bloquants.
Et contrairement à ce Elad raconte, non IPv6 n'est pas <5-10% des connexions, cela augmente chaque année et d'après Google 30% des connexions seraient compatible. D'après les courbes de Google, cela grossit de 5% par année. Donc si la tendance se poursuit, on dépassera les 50% avant 2025.