Merci Johann, Bruno, et autres personnes du groupe, Vos retours d’expert et vos précisions technique confirme ma position et ont approfondie ma connaissance sur le sujet.
Christophe Plessis > Le 9 mai 2020 à 16:39, Johann <ado...@gmail.com> a écrit : > > Bonjour Bruno, > > 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à parceque beaucoup d'équipements actif sur internet ne recoivent 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. > > Johann > >> Le sam. 9 mai 2020 à 16:05, Johann <ado...@gmail.com> a écrit : >> >> Bonjour Bruno, >> >> Ce qui me fait peur dans l'histoire, c'est que j'imagine que votre >> remarque est sérieuse et à prendre au 1er degré. >> Cela veut sans doute dire que des personnes LIR auprès de qui il s'amuse à >> spammer via des emails trouvés et utilisés contre toute règle du RIPE (pour >> lequel il se présente, je rappel...) pourrait le penser aussi et être >> tenter de voter pour lui. >> >> Je ne m'attarderais pas sur l'email spam, je pense que chaque personne un >> minimum censé se sera aperçu du n'importe quoi qui le compose. >> Par contre, aucune de ses propositions (pour avoir plus d'IP, lutter >> contre le spam (activité qu'il pratique donc), ou contre les DDoS) n'a de >> réel base technique ou même un moindre PoC. >> Pour des gens du métier, par exemple ceux qui construisent des réseaux, on >> s'aperçoit du non sens technique après 10 lignes sur chacune de ces >> propositions. >> >> Il ne s'est pas gêné pour spammer une mailing-list du RIPE dédiée aux >> questions autour de l'adhésion. Quand on lui fait remarqué que c'est pas le >> bon endroit, c'est pas triste... >> D'ailleurs à chaque remarque ou simple question au sujet de ses >> propositions, la réponse semble être la même à chaque fois : >> - Soit on ment car on est contre lui et qu'on fait partie du complot >> (lequel? Je ne comprends toujours pas son histoire) >> - Bah on a qu'à continué comme cela alors (le fameux "my way or noway"), >> surtout sur son "anti-DDoS magique" >> - On le diffame (alors que la plus part du temps, c'est l'inverse) >> - On est le gang des "proipv6" et on veut empêcher toute alternatif (oh >> mon dieu...) >> - C'est pas nous qui fixons les règles (sauf que lui non plus, il y a des >> chartes par exemple) >> >> Du coup, c'est compliqué de débattre sur ses propositions, vu qu'on est >> face à un mur. >> Mur qui d'ailleurs se présente à un poste qui demande quand même des >> qualités de dialogues et d'ouverture. Bref... >> Nous n'avons jamais une vrai réponse aux questions techniques. >> Entre deux attaques, diffamation ou théorie du complot, on arrive parfois >> à avoir quelques éléments mais peu probant techniquement. >> J'ai pris beaucoup de temps à lire presque l'intégralité des échanges >> disponible et c'est réellement une perte de temps. >> >> Clairement, c'est une personne à qui il faut éviter de donner de >> l'importance et ne surtout pas voter. >> C'est un élément toxique pour la communauté, comme j'en ai déjà vu par le >> passé. >> >> P.S : Juste pour rappel, ce n'est pas le RIPE qui décide tout seul dans >> son coin des protocoles. >> Si nous voulons proposé un protocole, on passe comme tout le monde par le >> chemin classique, pour que cela devienne après un long chemin une RFC. >> >> Johann >> >> >> Le ven. 8 mai 2020 à 19:24, Bruno LEAL DE SOUSA <bruno.ld.so...@gmail.com> >> a écrit : >> >>> Hello, >>> >>> Je ne connais pas ce fameux candidat mais au vu de la complexité >>> d'adoption >>> de l'IPv6 et de l'attachement à l'IPv4, proposer ce type de solution est >>> intelligent et encourageant ! >>> >>> A suivre... >>> >>> Bruno LEAL DE SOUSA >>> 06.01.23.45.96 >>> >>> Le ven. 8 mai 2020 à 15:42, Christophe PLESSIS <cples...@safeo.fr> a >>> écrit : >>> >>>> Bonjour, >>>> Avez vous reçu cette information pour augmenter le nombre d’ipv4 ? Quel >>>> est votre avis ? >>>> A bon entendeur. >>>> Christophe >>>> >>>> De : Elad Cohen <e...@bitcoin.host> >>>> Envoyé : vendredi 8 mai 2020 00:06 >>>> À : contact <cont...@safeo.fr> >>>> Objet : Message important concernant les élections du RIPE >>>> >>>> Bonjour, >>>> >>>> Je m'appelle Elad Cohen et je suis candidat au conseil d'administration >>> du >>>> RIPE lors des prochaines élections, qui auront lieu le 13 de ce mois. >>>> >>>> J'ai créé une solution technique avec laquelle il y aura plus de 4 294 >>> 967 >>>> 296 adresses IPv4 pour les 5 registres Internet régionaux, y compris le >>>> RIPE, vous pouvez en savoir plus à ce sujet ici : >>>> >>>> >>> https://www.ripe.net/ripe/mail/archives/members-discuss/2020-April/003676.html >>>> >>>> Le problème « d'épuisement d'IPv4 » sera derrière nous et chaque membre >>>> RIPE recevra au moins un /21 d'adresses IPv4 gratuites si je suis élu. >>>> Personne d'autre ne mettra en œuvre ma solution technique, je vous >>> demande >>>> votre vote en ligne. Sans votre vote en ligne à la prochaine assemblée >>>> générale du RIPE, ma solution technique ci-dessus ne sera pas mise en >>> œuvre. >>>> >>>> Veuillez vous inscrire au vote en ligne pour les élections du RIPE en >>>> utilisant le lien suivant : >>>> https://www.ripe.net/s/gm-registration-may-2020 >>>> >>>> Si vous rencontrez un problème pour vous inscrire au vote en ligne, >>>> veuillez envoyer un courrier électronique à a...@ripe.net<mailto: >>>> a...@ripe.net> >>>> >>>> --- >>>> >>>> Outre la solution technique susmentionnée au problème de « l'épuisement >>> de >>>> l'IPv4 », il existe deux autres solutions techniques que je >>> m'efforcerai de >>>> mettre en œuvre si j'ai l'honneur d'être élu : >>>> >>>> >>>> Une solution technique au problème mondial du spam par courrier >>>> électronique : >>>> >>>> >>> https://www.ripe.net/ripe/mail/archives/members-discuss/2020-April/003778.html >>>> >>>> Une solution technique au problème mondial de l'amplification de >>>> l'usurpation du DDoS : >>>> >>>> >>> https://www.ripe.net/ripe/mail/archives/members-discuss/2020-April/003902.html >>>> >>>> --- >>>> >>>> Si vous votez pour moi et que je suis élu, je ferai en sorte que RIPE >>>> devienne : >>>> >>>> - Une organisation 100% transparente. >>>> >>>> - Une organisation centrée sur le LIR (il y aura un ANS de 24 heures >>> pour >>>> chaque demande d'assistance, après quoi le membre du RIPE pourra >>> évaluer la >>>> qualité du service reçu et marquer si la demande d'assistance a été >>> résolue >>>> ou non, et si ce n'est pas le cas, l'assistance de niveau 2 recevra >>>> automatiquement la demande d'assistance). Chaque aspect du RIPE changera >>>> pour être centré sur le LIR et non sur la bureaucratie. >>>> >>>> Une organisation efficace en termes de dépenses de RIPE, je veillerai >>>> personnellement sur chaque dépense de RIPE afin de m'assurer que la RIPE >>>> soit une organisation efficace. Lorsque RIPE soit devenue une >>> organisation >>>> efficace, les cotisations annuelles des membres de RIPE seront >>>> considérablement réduites. >>>> >>>> Je vous demande de vous inscrire pour le vote en ligne en utilisant le >>>> lien suivant : >>>> https://www.ripe.net/s/gm-registration-may-2020 >>>> >>>> --- >>>> >>>> Le RIPE est géré par des personnes qui ne se soucient pas de vos >>> intérêts, >>>> vous pouvez en voir l'exemple à travers les deux liens suivants : >>>> >>>> >>>> >>> https://www.ripe.net/ripe/mail/archives/agm-nominations/2020-April/000692.html >>>> >>>> Dans ce lien ci-dessus, l'actuelle présidente du conseil >>> d'administration >>>> du RIPE, Maria Hall, candidate à sa réélection, a soutenu la nomination >>> de >>>> l'actuel président du conseil d'administration du RIPE, Christian >>> Kaufmann, >>>> candidat lui aussi à sa réélection. Dans sa « Raison de la nomination du >>>> candidat : » vous pouvez voir que la ligne « Raison de la nomination du >>>> candidat: » apparaît deux fois. Il y a une deuxième ligne « Raison de la >>>> nomination du candidat : » juste après la première ligne « Raison de la >>>> nomination du candidat: » parce que Maria a copié tout le paragraphe que >>>> Christian lui a envoyé sur lui-même, Christian notre président du RIPE >>>> trompe la communauté et il a écrit tout ce paragraphe sur lui-même et >>> l'a >>>> envoyé à Maria. Maria, notre membre actuel du Conseil d'administration, >>> a >>>> également trompé la communauté lorsqu'elle ne l'a même pas lu mais a >>> fait >>>> un copier-coller (y compris le titre) pour qu'on ait l'impression que >>> cela >>>> vient d'elle. Elle ne l'a même pas lu et n'a fait qu'un copier-coller >>> avec >>>> le titre. C'est pourquoi le titre « Raison de la nomination du candidat >>> : » >>>> apparaît deux fois. Est-ce le genre de membres du conseil >>> d'administration >>>> que vous voulez ? Voilà notre président actuel du conseil >>> d'administration, >>>> Chrisitan Kaufmann, qui essaie d'être réélu et qui trompe la communauté >>> ; >>>> voilà notre membre du conseil d'administration, Maria Hall, qui prend >>> part >>>> à cette manipulation de la communauté avec lui. Ils essaient de se faire >>>> réélire de quelque manière que ce soit. S'ils trompent la communauté de >>>> cette manière, pouvons-nous leur faire confiance pour gérer les >>> dépenses du >>>> RIPE d'environ 30 millions d'euros par an. Qui sait où vont ces dépenses >>>> alors que toute demande d'un membre du RIPE pour des informations >>>> détaillées sur les dépenses est redirigée de la direction du RIPE vers >>> ces >>>> personnes du conseil d'administration du RIPE. Ils prétendent ensuite >>> que >>>> des accords de confidentialité ont été signés et refusent de fournir >>> aucune >>>> information détaillé. Peut-on leur faire confiance ? >>>> >>>> J'ai 20 ans d'expérience technique et près de 10 ans d'expérience en >>>> gestion et en finance. Si vous votez pour moi et que je suis élu, je >>> ferai >>>> de RIPE une organisation transparente à 100%. Aucune dépense ne sera >>> cachée >>>> aux membres de RIPE et lorsque j'aurais réduit les dépenses et augmenté >>>> l'efficacité de l'organisation de RIPE, elle pourra considérablement >>>> réduire les frais annuels de tous les membres de RIPE. >>>> >>>> Environ 2 000 membres se sont inscrits pour le vote en ligne alors que >>>> plus de 23 000 membres du RIPE ne se sont pas inscrits. Veuillez prendre >>>> une minute de votre temps pour vous inscrire pour le vote en ligne lors >>> de >>>> la prochaine assemblée générale en ligne grâce au lien suivant : >>>> https://www.ripe.net/s/gm-registration-may-2020 >>>> >>>> --- >>>> >>>> Ma dernière partie concerne l'organisation anonyme illégale « >>>> L'Organisation Spamhaus », cette organisation anonyme illégale contrôle >>>> RIPE en coulisses. Vous pouvez en savoir plus sur cette organisation >>>> anonyme illicite en utilisant le lien suivant : >>>> >>>> >>> https://www.scribd.com/document/445894312/Spamhaus-Illegal-Private-Data-Violation >>>> >>>> Il s'agit d'une présentation que cette organisation a écrite sur >>> elle-même >>>> et selon laquelle elle reçoit régulièrement une quantité considérable de >>>> données sur la vie privée obtenues illégalement de la part de sociétés >>> et >>>> d'organisations Internet, et les partage ensuite de manière illégale >>> (sans >>>> aucun mandat) avec les forces de l'ordre. >>>> >>>> L'auteur de cette présentation était un coprésident du groupe de travail >>>> anti-abus du RIPE. Selon cette présentation et selon l'auteur de la >>>> présentation, le RIPE compte actuellement davantage de membres de >>>> l'organisation anonyme illégale « Le Projet Spamhaus ». >>>> >>>> Les membres de la mafia du « Projet Spamhaus » apportent leur agenda et >>>> leur politique au RIPE. Si vous votez pour moi et que je suis élu, je >>>> m'assurerai que « Le Projet Spamhaus » n'aura plus aucune emprise sur >>> RIPE >>>> et que « Le Projet Spamhaus » ne fera plus de mal aux membres de RIPE. >>>> >>>> « Le Projet Spamhaus » continuera à avoir des membres de sa mafia dans >>> le >>>> RIPE, ce qui faussera le fonctionnement du RIPE avec la politique et >>>> l'agenda du « Projet Spamhaus », si vous n'agissez pas et si vous ne >>> prenez >>>> pas une minute de votre temps pour vous inscrire au vote unique en >>>> utilisant le lien suivant : >>>> https://www.ripe.net/s/gm-registration-may-2020 >>>> >>>> En raison des membres de la mafia du « Projet Spamhaus » au sein du >>> RIPE, >>>> les résultats du vote du 13 de ce mois ne seront pas fiables. Si vous >>> avez >>>> l'intention de voter pour moi, je vous demande de m'envoyer un message >>>> électronique à ce sujet, pour me permettre de garder une trace de ceux >>> qui >>>> voteront pour moi et de s'assurer que « Le Projet Spamhaus » ne >>> manipulera >>>> pas les résultats des élections prochaines de RIPE. >>>> >>>> Meilleures salutations, >>>> Elad >>>> >>>> --------------------------- >>>> Liste de diffusion du FRnOG >>>> http://www.frnog.org/ >>>> >>> >>> --------------------------- >>> Liste de diffusion du FRnOG >>> http://www.frnog.org/ >>> >> > > --------------------------- > Liste de diffusion du FRnOG > http://www.frnog.org/ --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
