Bonjour,D'une part la proposition a 20 ans de retard (c'est pas le premier à chercher à gratter de la place dans le header pour étendre l'IPv4), mais les problèmes sont les mêmes que pour IPv6 hormis la double stack.
La réalité (et c'est expliqué environ 50 fois dans le thread du RIPE), c'est que tu dois adapter quand même les équipements concernés, que le bit en question peut être réécrit ou reset ou utilisé et dans ce cas tu perds l'extension, que pire encore sur une non prise en compte de ce bit, tu peux te retrouver avec une IP dupliquée qui peut poser des problèmes sur des ACL et que comme dit Radu, à un moment en end point tu as une IP qui est 32 bits sans rien d'autre et que voilà.
Si c'est pour taper dans les trucs non prévus, autant exploiter la classe E 240.0.0.0/4 réservée pour utilisation future (quel futur ?). A priori Windows le gère pas, mais ce serait surement plus simple de débloquer ça qu'utiliser un bit "magique".
La proposition n'a aucun fondement concret, aucune sous couche technique, aucun POC, aucune proposition solide.
Le mec utilise une méthode bien à la mode pour essayer de se faire élire en promettant des trucs magiques (sa proposition anti-spam est du même accabit), c'est du Trump like quoi. Sachant que le RIPE n'est pas l'organisme qui décide de tout ça en plus.
Je suis effrayé de voir qu'un tel ce non sens a réussi à générer autant de volume de discussions et je m'inquiète de voir des gens croire en ce marabout de l'an 2020. Entre Trump et les débilités qu'on voit concernant Coronavirus et la 5G régulièrement, j'espère qu'au moins la communauté des membres du RIPE a globalement plus de discernement que ça.
Voilà que même au RIPE on se tape de promesses de politiciens... Fred Le 09/05/2020 à 16:51, Bruno LEAL DE SOUSA a écrit :
Bonjour Johann et bonjour à tous, Merci pour ces explications mais j'ai juste répondu un peu vite et pas dans le bon sens. En effet lorsqu'on regarde en détail sa proposition et surtout ses méthodes cela fait peur et l'application semble impossible voir catastrophique. Après je pense que la réflexion qu'il a apporté a juste 10 ou 20 ans de retard. Il aurait fallu y songer avant de propulseur IPv6. Je pense que le passage de IPv4 à IPv6 est juste trop brutal et mal organisé aujourd'hui. Beaucoup vont se casser les dents en termes de sécurité dans les années à venir à cause de ce changement trop brutal. Un changement ne peut être réussi que quand il est adapté, pas trop brusque et accompagné. Je trouve donc dommage que ce genre de proposition ou de réflexion apparaissent bien trop tard. Maintenant il est certain que ces propositions manquent de sens et de possibilité de réalisation. Des belles promesses de politiciens encore... Espérons qu'il ne réussisse pas à gagner le combat des élections. Bonne journée à tous. Bruno LEAL DE SOUSA 06.01.23.45.96 Le sam. 9 mai 2020 à 16:38, 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 conseild'administration duRIPE 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 294967296 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.htmlLe 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 vousdemandevotre 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 del'IPv4 », il existe deux autres solutions techniques que jem'efforcerai demettre 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.htmlUne 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 heurespourchaque demande d'assistance, après quoi le membre du RIPE pourraévaluer laqualité du service reçu et marquer si la demande d'assistance a étérésolueou non, et si ce n'est pas le cas, l'assistance de niveau 2 recevra automatiquement la demande d'assistance). Chaque aspect du RIPEchangerapour ê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 laRIPEsoit une organisation efficace. Lorsque RIPE soit devenue uneorganisationefficace, 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 vosinté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.htmlDans ce lien ci-dessus, l'actuelle présidente du conseild'administrationdu RIPE, Maria Hall, candidate à sa réélection, a soutenu lanomination del'actuel président du conseil d'administration du RIPE, ChristianKaufmann,candidat lui aussi à sa réélection. Dans sa « Raison de la nominationducandidat : » vous pouvez voir que la ligne « Raison de la nomination du candidat: » apparaît deux fois. Il y a une deuxième ligne « Raison delanomination du candidat : » juste après la première ligne « Raison de la nomination du candidat: » parce que Maria a copié tout le paragraphequeChristian 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 etl'aenvoyé à Maria. Maria, notre membre actuel du Conseild'administration, aégalement trompé la communauté lorsqu'elle ne l'a même pas lu mais afaitun copier-coller (y compris le titre) pour qu'on ait l'impression quecelavient d'elle. Elle ne l'a même pas lu et n'a fait qu'un copier-colleravecle titre. C'est pourquoi le titre « Raison de la nomination ducandidat : »apparaît deux fois. Est-ce le genre de membres du conseild'administrationque vous voulez ? Voilà notre président actuel du conseild'administration,Chrisitan Kaufmann, qui essaie d'être réélu et qui trompe lacommunauté ;voilà notre membre du conseil d'administration, Maria Hall, qui prendpartà cette manipulation de la communauté avec lui. Ils essaient de sefaireréé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 lesdépenses duRIPE d'environ 30 millions d'euros par an. Qui sait où vont cesdépensesalors 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 verscespersonnes du conseil d'administration du RIPE. Ils prétendent ensuitequedes accords de confidentialité ont été signés et refusent de fourniraucuneinformation 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, jeferaide RIPE une organisation transparente à 100%. Aucune dépense ne seracachéeaux 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. Veuillezprendreune minute de votre temps pour vous inscrire pour le vote en lignelors dela 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-ViolationIl s'agit d'une présentation que cette organisation a écrite surelle-mêmeet selon laquelle elle reçoit régulièrement une quantité considérablededonnées sur la vie privée obtenues illégalement de la part de sociétésetd'organisations Internet, et les partage ensuite de manière illégale(sansaucun mandat) avec les forces de l'ordre. L'auteur de cette présentation était un coprésident du groupe detravailanti-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 surRIPEet que « Le Projet Spamhaus » ne fera plus de mal aux membres de RIPE. « Le Projet Spamhaus » continuera à avoir des membres de sa mafia dansleRIPE, ce qui faussera le fonctionnement du RIPE avec la politique et l'agenda du « Projet Spamhaus », si vous n'agissez pas et si vous neprenezpas 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 duRIPE,les résultats du vote du 13 de ce mois ne seront pas fiables. Si vousavezl'intention de voter pour moi, je vous demande de m'envoyer un message électronique à ce sujet, pour me permettre de garder une trace de ceuxquivoteront pour moi et de s'assurer que « Le Projet Spamhaus » nemanipulerapas 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/
