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/
