Le monsieur fait tout de même parti du conseil scientifique que consulte Macron pour cette crise. On peut pas dire qu'il est ignoré.
Il n'est pas ignoré. Mais il n'est pas non plus considéré comme le référent principal. C'est l'équipe de l'hôpital de la Pitié Salpêtrière qui a ce titre. Donc il n'est perçu comme le numéro 1.
Tout d'abord, il est visiblement publié sans revue dans le journal de son voisin de paillasse.
Ça s'appelle une publication d'urgence. Pour une publication dans un cycle classique, il faut une revue par les pairs, c'est à dire par des experts en maladies infectieuses contagieuses. Déjà normalement ça prend des jours, mais là en plus les différents experts sur le sujet sont un poil occupé.
Après sur les experts reconnus en ce qui concerne le sujet (maladies infectieuses contagieuses donc) en France il y en a 3 qui bossent à la Pitié Salpêtrière sur un protocole Lopinavir-Ritonavir. Les 5 autres à part le professeur Raoult sont aussi à l'IHU Marseille (le centre hospitalier du professeur Raoult). Donc le papier validé en urgence par le "voisin de paillasse" ça se justifie assez facilement.
Ensuite, outre le faiblesse des échantillons (26 puis 20 personnes dans le groupe test, 14 dans le groupe témoin), il n'y a pas de double aveugle, ni de placebo pour le groupe témoin.
Oui c'est comme ça qu'on fait les premiers tests - sur un échantillon très réduit. C'est comme ça qu'on obtient l'autorisation de faire le test étendu.
L'absence de placebo c'est normal, il n'y a pas d'effet placebo qui affecte la charge virale d'un patient le (patient peut se sentir mieux avec un placebo, mais il garde une charge virale équivalente à celui d'une personne qui ne reçoit pas le placebo)
L'absence de double aveugle est liée au point précédent. Comme on mesure des quantités qualifiées objectivement (charge virale) la capacité des médecins à favoriser tel ou tel type de patient par rapport à un autre est quand même limité. Ceci dit ça aurait été mieux en effet (même si médicalement ça ne sert pas forcément, ça aurait pu permettre de couper court à certaines questions stériles)
Pour finir l'exclusion des 6 personnes. C'est tout à fait normale, l'étude porte sur des personnes infectées récemment, non sur-infectées par des maladies opportunistes. Les 6 personnes exclues de l'étude tombent dans un de ces deux cas, voire les deux. Conserver leurs données aurait faussé le test. De plus même en supposant qu'il ait triché pour améliorer ses résultats, on a quand même 20 personnes sur 26 avec une charge virale minimale au bout de 6 jours au lieu de 20. 77% de réussite du traitement en première approche - ça reste très honorable.
Pour finir, le but de M. Raoult était de reproduire en France le plus vite possible les résultats d'une étude chinoise (avec un petit bonus pour l'utilisation de l'azithromycine en double emploi comme barrière cellulaire et anti-biotique de prévention des maladies pulmonaires opportunistes)
Pour finir, de manière plus anecdotique, le monsieur raconte allègrement n'importe quoi lors d'interview (ça ne remet pas en cause directement son travail, mais bon, ça n'invite pas non plus à la confiance).
Oui enfin le monsieur est quand même considéré comme numéro un mondial sur le sujet par tout le monde sauf la France.
J'ignore pourquoi il annonce qu'une étude sur 20 personnes peut être plus significative qu'une étude sur 10 000 personnes. Je suis sur qu'il a une bonne raison.
Si je devais faire une hypothèse je dirais qu'il s'agit de la perturbation par des facteurs extérieurs. On peut raisonnablement faire le suivi d'une maladie sur 20 à 100 personnes à l'exclusion de tout facteur extérieur. Sur 10 000 c'est plus complexe.
Et on est bien opportuniste puisqu'on sort un livre le 23 mars 2020 titré "Epidémies : vrais dangers et fausses alertes" (et un sous titre avec covid-19 dedans, évidemment).
Ça on peut va pas dire le contraire. Le Professeur Raoult multiplie les brevets, publications et sources de revenus para-médicales. Mais peut-on vraiment lui en vouloir - il a grandement fait avancer la médecine, ne serait-ce qu'au niveau des détections et des diagnostiques. Là ou le gouvernement Hollande fermait 17 500 lits dans les établissements hospitaliers, lui avec ses financements parallèles il en ouvrait 1000 sur la région Aix-Marseille. On peut ne pas aimer le procédé, mais là il y a quand même légitime défense de son pôle.
La chloroquine peut provoquer des réactions grave, on ne peut pas la donner comme ça à un large public.
Dans l'ordre
a) Avant que tous les paludismes du monde ne soient résistant à la nivaquine, on faisait exactement ça.
b) Il y a effectivement des cas de chocs anaphylactiques suite à la prise continue de chloroquine - mais si on est en environnement hospitalier il y a très peu de chance que ce soit un problème grave. Il faut bien sur un suivi et un contrôle, mais le problème ici est nettement plus logistique (pas assez de lits, pas assez de médecins) que sanitaire (Le médicament a 70 ans, ses effets indésirables sont connus). Il y a des protocoles pour ce genre de cas (Par exemple rester à l’hôpital pendant environ 2/3h après la prise du médicament problématique pour ne pas encombrer les lits mais être suivi quand même en cas de soucis. Vu l'avancement de la crise même ça n'est plus possible aujourd'hui.)
c) Il ne s'agit pas ici de chloroquine mais d'hydroxychloroquine qui est nettement moins problématique.
d) Le protocole du Dr Raoult ne préconise absolument pas de distribuer le Plaquenil comme des bonbons à la sortie des écoles, mais de faire le test systématique des patients pour les coronavirus (pas que Covid-19) et en cas d'infection + symptômes de soigner systématiquement. Il y a une décision à prendre dans le cas d'une infection asymptomatique (traitement ou pas ?) Son opinion est qu'il faudrait soigner là aussi, mais admets que ce n'est qu'une opinion.
Le ministre a (quasi, 24h) directement dit ok pour étendre les test
Oui enfin après avoir refusé de prendre en compte les études Chinoises sur le sujet qui appliquaient le protocole du Dr Raoult (Le protocole initial était Plaquenil + Doxycycline, mis au point lors des précédentes épidémies liées à des coronavirus) et qui démontraient son efficacité il y a plus de trois semaines et avoir trainé des pieds pour autoriser l'étude réduite alors que les tests in vitro était très positifs. (En plus de ne pas commander les amorces pour la détection du coronavirus par PCR).
Mais principalement les points les plus importants qui sont soulevés sont les suivants :
Aujourd'hui la Chine est à la pointe dans de nombreux domaines, notamment en ce qui concerne les maladies infectieuses. Peut-on se permettre de remettre en cause leurs études ? Très honnêtement aujourd'hui en tant que non médecin j'ai nettement moins confiance en les études du CDC américain (cough Glyphosate cough) qu'en celle des universités chinoises.
Il y a dix ans il fallait plusieurs jours pour faire des tests sur les maladies infectieuses: détection, traitement, réponse, validation. Aujourd'hui ça peut être fait en quelques heures. Il faudrait probablement dépoussiérer les protocoles d'autorisation des traitements pour prendre en compte ces avancées technologiques.
Alors tout ton post parle de recompilation alors que ça n'est pas du tout ce que je promeus ! Au contraire, utiliser des programmes libres utilisant toutes les instructions que tu veux, déjà compilés par ta distro, puisque (dans mon hypothèse) tu n'as pas à te soucier de problèmes de programmes qui ne seraient pas de confiance puisque tu n'utilises que des programmes libres de confiance (ceux de Debian).
Là le soucis n'est pas tant là confiance dans les logiciels installés que la confiance dans l'ensemble de l'environnement. On est dans un cas ou n'importe quel utilisateur qui arrive à faire s’exécuter n'importe quel programme, même dans un environnement ultra protégé (c'est à dire des droits limités, du SELinux, des cgroups et autre posix capabilities) peut aller lire le contenu du processus d'à coté, voire de la vm d'à coté si elle tourne sur le même processeur physique.
Pour Spectre 2 il y avait trois solutions : soit interdire à tes utilisateurs d’exécuter le moindre processus qui n'est pas certifié. (Donc pas de virtulisation, mais aussi pas de developpement Java, Erlang, Javascript, .Net et j'en passe). Pas évident en environnement professionnel.
Deuxièmement désactiver les options processeurs impactées au niveau du bios (quand c'était possible) ou recompiler l'ensemble des process tournants sur le système sans utiliser les optimisations à risque. Mais là forcément les perfs peuvent prendre cher dans certains cas.
Dernière solution : recompiler le noyau et tous les modules et processus privilégiés (anti-virus, firewall, pilote, tout ce qui utilise des DMA etc.) avec retpoline. Impact de perfs limité dans la majorité des cas, mais il faut bootstrapper tout le système coeur… Du fun quoi…
Après, une attaque « via des logiciels établis » est toujours possible
C'est pas une attaque via un logiciel existant dans lequel tu vas réussir à provoquer un comportement à risque, du moins pas dans le sens ou tu utilises PHP ou Bind pour executer du code avec les droits root. Tu peux forcer le CPU à dumper le contenu d'un bloc du L1 dans le L2 et le récupérer depuis un compte lambda.
je préfère me concentrer sur d'autres facteurs (avoir des machines bien à jour, bien configurées) que de psychoter sur un problème avec une probabilité d'arriver minimale.
Si un jour un crétin trouve un autre exploit de la faille et le met en ligne "pour rire", la probabilité que ça arrive deviendra maximale en quelques heures. On est littéralement à un script près d'avoir un utilisateur non privilégié qui peut dumper le cache L1 du processeur dans un fichier. Après on peut considérer que la probabilité qu'un tel script voit le jour est très faible, c'est un choix. Mais dans tout un tas d’environnements, notamment quand on offre des capacités à ses clients pour exécuter du code custom, c'est quand même un vrai gros risque.
Alors déplorer aujourd'hui que « ça n'est pas possible, ma bonne dame », c'est oublier qu'on a troqué des choses qui existaient et qui marchaient très bien
Je ne suis pas vraiment d'accord. Certes on peut (et c'est toujours vrai aujourd'hui) se préparer un système aux petits oignons en compilant tout manuellement. Mais très peu de gens ont les compétences pour créer et maintenir un tel système.
Désactiver un jeu d'instruction à la compilation, voire dans certains cas dès la phase de configuration, c'est déjà loin d'être évident sur des processeurs modernes. En plus on se retrouve avec un système unique, sur lequel si des bugs spécifiques apparaissent, il faut les gérer seul ou quasiment.
Là il s'agit (si on veut être prudent) de désactiver complètement les fonctionnalités RTM et HLE (et tout ce qui touche à l'hyperthreading, mais ça ça se fait bien). Non seulement il va y avoir un impact vraiment fort sur les perfs qui n'est pas forcément acceptable professionnellement, mais en plus il faut adapter tes fichiers de config et de compilation pour ainsi dire type de machine par type de machine.
A titre d'exemple mon ingesteur de données custom 0MQ+ScyllaDB se prenait 70% de pertes de perfs jusqu'à l'arrivée de retpoline au moment de SPECTRE/MELTDOWN. Pas évident de devoir choisir entre tourner à 30% de perfs ou tripler la facture d'hébergement.
Je ne vois pas comment on peut écarter un tel bon système en disant qu'il n'existe pas d'alternative au tout « j'exécute n'importe quel binaire » d'aujourd'hui.
Ça n'est absolument pas la question, certes Debian a des paquets binaires que l'on peut auditer, mais si tu dois compiler quoi que ce soit à la mimine, si tu veux un kernel optimisé ou si tu as besoin du moindre pilote (même libre) qui effectue une étape de compilation au déploiement du package - tu rentres dans le rouge immédiatement.
En fait même si tu ne prends que des packages standards libres Debian, tu vas probablement te retrouver dans le rouge quand même. Déjà pas mal de packages, modules et pilotes sont compilés avec la capacité de détecter et d'activer au runtime des optimisations CPU (crypto, NUMA, HLE etc.), ensuite tu fais quoi si tu as un environnement qui utilise ces instructions ? Tu recompile et tu redéploies tout ? (Dans le cas de retpoline, c'est ce qui s'est passé…)
Généralement si tu bosses dans tout un tas de domaines tu vas chercher à exploiter au maximum ton infrastructure, donc laisser le compilateur optimiser pour toi en mettant un -march qui correspond à ton architecture. Aller choisir les flags à la main un par un est complexe, surtout que les gars chez GCC ne s'attendent absolument pas à avoir un processeur qui possède le flag X mais pas le flag Y - vu qu'il existe exactement 0 processeur réel dans cette situation.
Donc tu te retrouves à essuyer les plâtres sur des configs de compilation qui n'ont aucun sens. Ou tu désactives les fonctions au niveau kernel (ou microcode) et tu regardes ce qui casse. Et clairement c'est pas un job que n'importe qui peut faire, et comme la majorité des boites n'a pas d'Ulrich Drepper sous la main…
Bref utiliser Debian avec des packages traçables n'évite absolument pas le problème. Ça mitige un peu dans le sens ou effectivement tu n’exécutes pas un code tiers qui a une intention malicieuse à la base - mais pour autant ça ne bloque pas une attaque via des logiciels établis.
Encore une fois, il faut voir dans quel contexte c'est exploitable : pour des gens qui font tourner du code malveillant utilisant les instructions TSX. Qui fait ça ? Ceux qui installent du code venu de n'importe où, sans vérifier. Vous étonnez-vous qu'après il y ait des problèmes ?
Ne pas confondre la méthode d'exploitation de la faille qui a été trouvée et la faille elle-même. Outre l'exploitation de la faille, il reste la problématique de fond : le cache L1 permet à un processus B d'accéder à des informations mémoire d'un processus A. Même si là les chercheurs précise bien qu'ils n'ont pas de pistes pour un autre type d'attaque qui permettrait d'exploiter cette faille, ça ne veut pas dire qu'une autre attaque n'existe pas et n'existera jamais.
Bref, cette attaque est encore une fois très spécifique, et n'affecteront jamais des personnes qui utilisent uniquement du logiciel libre et maîtrisent leur informatique.
En effet, mais ça veut dire quoi "maitriser son informatique". Tout compiler soit-même à la mimine en s'assurant que l'instruction TSX (et d'autres instructions interagissant avec les échanges de données inter-coeurs, on est jamais trop prudent) ne sont jamais utilisées ? On parle d'une faille hardware là. Le moindre pilote client de base de données ou wrapper Vagrant (et on va pas parler de Docker, KVM, XEN et co.) peuvent potentiellement permettre un nouveau vecteur d'attaque. Il doit pas y avoir grand monde avec le temps, les compétences et la volonté de "maitriser son informatique" à ce point.
J’ai déjà fait de l’IPv6 sur des lien L2 encapsulé sans soucis.
Sérieusement ? Tu m'intéresse réellement. Tout fonctionnait ? Le Well Knwown multicast passait bien d'un site à l'autre ? Le NDP dans l'overlay détectait bien toutes les équipements ? Bref le L2 apparaissait bien comme intègre ?
Aucun moyen depuis le réseau overlay de détecter la virtualisation ?
Que viennent faire les protocoles non-IP dans le passage (ou non) à IPv6 ?
Sur la plupart des protocoles de transport existant, tu peux te permettre de raisonner en mode "trames" et te contenter de faire du transport bêtement. Du coup tu peux si besoin est encapsuler tout ça et le balader d'un bout à l'autre de ton réseau et même au delà si tu en as besoin.
IPv6 supporte assez mal ce genre de clowneries, et tu te ramasses des effets de bords, des retry, des logs etc. Du coup il se retrouve mécaniquement relégué au rôle de gadget activé pour faire plaisir (ou pour pouvoir peerer avec les GAFA) dans pas mal de réseaux.
Tu te retrouves donc assez vite dans l'incapacité de pouvoir servir de grosses demande clients de type L2 virtualisé, CAN ou MAN sans leur refourguer d'abord des liens dédiés en pagaille. Et là bien sur toute la marge est pour le fournisseur de lien et toi tu peine à rentabiliser tes équipements.
Cette incompatibilité majeure entre les mécanismes fondamentaux d'IPv6 et la réalité des commandes clients est à mon sens le plus gros frein aux investissements de ce coté.
Grosso-modo le message que je voulais faire passer au début est que ce n'est pas parce qu'il n'y a pas eu d'investissements qu'IPv6 n'est pas viable, mais c'est parce que IPv6 n'est pas viable mécaniquement (et non pas financièrement) qu'il n'y a pas eu d'investissement.
Mais tu as raison le thread et les dialogues de sourds ont un peu trop duré. Je déclare mes opposants dans ce débat vainqueurs par lassitude et je retourne virtualiser des L2 pour le fun et le profit.
J'ai vraiment l'impression qu'on ne se comprend pas : ici, ton besoin (étendre un L2 où tu veux dans le monde) est issu de contraintes applicatives qui sont que certaines applis ou certains services
Non.
Il existe un vaste monde dans lequel il y a littéralement des centaines de protocoles transport/réseau qui ne sont pas IP (v4 ou v6). Des transpondeurs satellites jusqu'au téléphone portable (ou pas), des équipements d'imagerie médicale jusqu'au camera 8k des matchs de foot, des commutateurs télécoms aux émulateurs de circuits…
Il y aussi pas mal de contraintes physiques qui s'appliquent et qui font que TCP/IP ou UDP/IP n'est pas une solution optimale ou même viable. Un exemple : IS-IS. Tu vois un moyen de faire rentrer IS-IS dans IPv6 ? Ca n'aurait aucun sens.
Et bien figure toi que le mec qui reçoit le flux de 50 caméras dans un stade et qui veut pouvoir faire la prod sans déplacer 12 camions de régies - en vrai il s'en moque d'IPv6. Il veut son SDI et son RTP. Idem pour le mec qui a besoin de surveiller en vrai temps réel 25 sites proches en cas d'alerte orage. Aucun des deux ne va switcher sur un protocole moins efficace, plus prône à l'erreur etc.
Ce mec si je veux pouvoir le servir sur ses gros besoins je dois faire une croix sur l'IPv6 sur mes meilleurs liens. Ce que tous les opérateurs font.
Parce que ça n'aurait strictement aucun intérêt de faire la même merde en v6 : qu'est-ce que ça va t'apporter de dire « j'étends mon L2 sur IPv6 » ? Tu ne te bases pas sur le routage, tu ne dépends pas du nombre d'adresse
Déjà j'aimerai pouvoir dire "je fais rentrer IPv6 ans un L2 étendu" et non pas "j'étend mon L2 sur IPv6". Mais surtout virtualiser un réseau de nos jour c'est la base. Pouvoir monter une topologie réseau en dynamique à la demande sans déplacer un seul équipement physique c'est ce vers quoi tout le monde tend. Ça ne te plait pas tant pis. Infrastructure As A Service ils appellent ça. Tu cliques trois fois sur le mulot et tu as trois appliances internet facing avec tes IP et un backend connecté sur X serveurs de calculs, des lambdas, des serveurs de stockage (virtualisés aussi) etc. Sur ce réseau étendu à la demande je veux le routage IPv6, et les adresses, et le multicast, et IPv6 mobile (Non je déconnne).
Alors pourquoi fais-tu de l'IPv6 ? Tu es masochistes ?
J'ai pas les moyens de me payer plusieurs coeurs de réseau, et du coup ça m'arrangerait de pouvoir faire passer les clients qui payent et IPv6 sur les mêmes tuyaux. Ça m'arrangerai de pouvoir virtualiser le truc pour que si ça ne marche pas je puisse restaurer la config précédente en 3 clicks du même mulot mort que précédemment. Mais si c'est pas possible, le choix est vite fait.
Si ton appli dépend d'Ethernet, elle n'est pas codée selon les principes d'Internet
Je n'ai pas d'appli. Je ne fait que du transport. Idéalement je ne devrais même pas avoir besoin de savoir ce que je transporte. Maintenant soyons clair au niveau transport, aujourd'hui, tout repose sur Ethernet. IPv6 over Token ça n'existe pas, IPv6 over Frame Relay est mort (et il y avait pas grand monde pour pleurer le jour de l'enterrement), les 802.1x sont pour ainsi dire assimilable à Ethernet dans 99.9% des cas. (Je dis ça et je fais du SPB et de l'IS-IS)
Si ton appli dépend d'Ethernet, elle n'est pas codée selon les principes d'Internet (bis repetita). IPv6 ne t'apportera absolument rien pour régler ça dans le réseau
Mais je ne demande rien à IPv6 moi. Je voudrais juste qu'il puisse rentrer dans le même tuyau que les autres de façon à ce que je puisse faire mon transport sans me demander comment l'admin du site d'en face a implémenter la gestion de la distribution des adresses DNS et si ça va avoir un impact.
Ah, enfin une demande applicative ! Si l'Internet multicasté public était disponible, ton mec aurait juste à rentrer les trois noms DNS des sites distants (ou quelqu'un l'aurait provisionné pour lui) et ça marcherait sans toucher un seul routeur ou switch, sur Internet tout court.
Non c'est pas de l'IP, ça n'en sera probablement jamais (trop complexe à synchroniser au niveau des flux) et ce ne sera jamais public. Et une fois de plus je ne fais que fournir du transport. Et avec un L2 étendu ça marche tout seul.
Pour conclure, je ne dis pas que tes bidouilles ne doivent pas être intégrées dans le « grand plan » de transition à IPv6
Il y a pas de "grand plan" de transition à IPv6. Il y a 3 acteurs qui font 50% du trafic mondial et qui forcent les ISP à implémenter la partie des RFCs IPv6 qui les interressent pour avoir du peering. Et un peu de bordure de réseau pour IPv6 sur mobiles.
Les bidouilles qui permettent de faire de la haute dispo ou de la virtualisation de réseau se répartissent en une multitude de protocoles plus ou moins libre (Salut à toi VRRP) et de nouveaux protocoles proprios apparaissent tous les jours pour le transport de médias, le monitoring temps réel, le clustering etc. On multiplie les techniques type VLan (802.1aq, VxLAN, MPLS) ou de splits de ports dispo (CGNAT).
Tu peux te dire que ce sont des gens qui n'ont pas compris internet, que c'est par incompétence ou appât du gain, et assimiler tous les efforts, l'argent et le temps qui sont dépensés à résoudre de novo les problèmes qu'IPv6 est supposé effacer à du gaspillage. Mais il faut voir la réalité en face : IPv6 ne correspond pas au besoin d'un internet moderne. Pour l'instant personne n'ose proposer un protocole concurrent de peur de déclencher une seconde guerre des protocoles internet, mais franchement entre la concentration des routes et l'alourdissement légal pour les petits, on va droit vers un pile de transport entièrement piloté par un consortium.
Posté par Kaane .
En réponse au journal L'IPv6 et moi.
Évalué à 2.
Dernière modification le 12 octobre 2019 à 15:18.
Que l'Union Européenne foute PV à chaque fournisseur d'accés qui connecte un device à Internet sans une IPv6 publique.
Ça aurait le même effet que de mettre une amende à toutes les personnes qui font des documents officiels en autre chose qu'en LaTex.
Personne ne le ferai, et la plupart des gens préfèreraient payer l’amende ou bricoler un truc ou techniquement tu as une IPv6 publique mais tout est bloqué.
Désolé, mais tu mélanges plusieurs choses : déjà, de faire passer un certains nombre des adresses ça n'a pas de sens, puisque le multicast tel que tu le décris (je pensais que tu parlais de multicast routé au début) est basé sur l'utilisation des capacités du medium sous-jacent, qui est indifférent à ce qui se passe dessus (adresses en 33:33:* pour Ethernet par exemple). Mais je comprends alors que tu parles d'étendre un L2 ou tu snoop le multicast pour le propager : bref, ça n'est pas du tout du routage, mais de la bidouille pour étendre un réseau mal fait, peut-être à cause d'applis mal utilisées ou mal configurées !
Je reprend, je veux (quelque soit la méthode utilisée) créer un réseau L2 virtuel. L2 dans L3 si tu veux. Dans ce cadre je n'ai aucun outil ou appliance qui me permettent de dire que tel ou tel paquet multicast L2 virtualisé doit être routé de telle ou telle façon L3.
En bref dans l'exemple que je donne je veux qu'un paquet multicast émis sur de l'overlay L2 virtualisé traverse un réseau routé L3 et ressorte de l'autre coté en tant que paquet L2 virtualisé à 10, 100, 1000km de là.
Oui, très bien, ce sont des bidouilles qui existent pour palier les manques du protocole IPv4 !
Mais même si tu as raison, je m'en fous - je peux spanner mon L2 sur N sites non connectés par des circuits et faire mon taf.
Ça c'est du bullshit qui n'a pas de sens.
Donc MPLS, eVPN, GRE et j'en passe n'ont pas de sens ? Virtualiser un L2, ou faire que tes agents qui sont en déplacement puissent travailler à distance comme si ils étaient sur place (pour de vrai hein, en full ethernet) ça n'a pas de sens ?
Tu peux faire tout ça avec du routage simple. En fait je pense que tu ne sais pas ce qu'est le routage réellement.
OK comment je "route" simplement de la trame ethernet non IP ? Comment je load-balance ou que je mets en haute dispo un réseau complet avec tout ce qui transite dessus (y compris tout ce qui est non IP). Comment je fais qu'un mec qui branche une caméra à Cannes puisse la multicaster sur 3 sites de production différents sans toucher un seul instant à la config d'un seul routeur ou switch ? (de toute façon il est cameraman et il a autre chose à faire).
Que les choses soient claires, je sais virtualiser un L2 ethernet de façon transparente pour quasiment tout sauf Fibrechannel et IPv6. Et encore Fibrechannel c'est vraiment mourant et en plus en insistant un peu ça finit par passer (mais c'est pas complètement transparent)
Je n'ai jamais travaillé en profondeur avec Facebook et je ne connais personne qui y a bossé. Donc je ne peux pas dire grand chose dessus. Ceci dit Facebook au niveau flux ils sont impressionnants par la quantité de données, mais niveau complexité des traitements strictement réseau il sont quand même nettement en dessous d'un Amazon ou d'un Google à mon avis.
Vu les sommes qu'ils dépensent pour racheter un maximum d'IPv4 publiques, ça doit venir d'ailleurs.
Le fait que les autres l'ont fait montre que c'est faisable. Même mon petit Cloud pro-vider Suisse du coin me donne un support IPv6 actuellement.
Ah mais moi aussi j'ai offert du full IPv6 à qui le demandait. Sauf que a) personne ne demande et b) la question concerne le cœur de réseau et les réseau virtualisés. En bordure de réseau ça marche.
Et quand le prix des plages v4 va monter exponentiellement, tout le monde va paniquer et tourner en rond.
Le prix des IPv4 est déjà prohibitif dans tout un tas de pays. Le pool ARIN est vide depuis 2015. Et pourtant IPv6 ne prend toujours pas - à part sur de nouveaux besoin en bordure de réseau comme avec les smartphones.
La tu pointes un autre problème. Un bon nombre de sys admins n'est pas formé à IPv6 et surtout pas intéressé "tant que ça marche".
Contre proposition : "Un bon nombre de sysadmins sont des gens intelligents curieux et passionnés, si IPv6 ne prend pas c'est qu'il est beaucoup trop casse gueule et complexe à maintenir"
Ça je sais, la question à se poser est pourquoi ? Pourquoi le réseau avec le plus d'endpoints public au monde n'utilise que très très peu IPv6.
ils sont d'ailleurs le seul entre Microsoft, Google, Facebook, Amazon and Cloudflare qui ne resolve pas en v6 actuellement.
Cloudlflare c'est un peu spécial, ils auraient du mal à être crédible en gros experts du CDN/WebFront si ils n'avaient pas IPv6.
Google, ils ont un bon support IPv6 pour la pub. Ils veulent pas passer à coté du marché Chinois ou Africain et ils veulent pouvoir autant que possible traquer les utilisateurs. C'est pour ça qu'ils encouragent les sites à avoir une résolution IPv6 en boostant leur ranking. Mais honnêtement la Chine est resté protégée et l'Afrique est pas encore franchement sur Internet. Au moins ça leur permet de traquer les smartphones - ceci dit avec les parts de marché Android, ils avaient déjà gagné cette partie là.
Microsoft a clairement vraiment beaucoup investi dans IPv6 - c'est même les seuls a avoir autant planché sur le sujet chez les institutionnels. Problème pour parer à toutes les éventualités ils ont créé masse de piles et de cartes virtuelles. On est monté à 5 dans les différentes versions de windows. Ca a pas vraiment encouragé à franchir le pas. Bien au contraire. Et puis on va rester poli et pas parler de l'IPv6 sur Azure, encore que ça s'améliore.
ZigBee a rien avoir avec IPV6. ZigBee c'estp as du layer 3 mais quasiment un protocol full stack L2 -> L7. Spécialisé dans le low-power, middle range, il joue clairement pas dans la même cours.
Certes, mais toutes les installations datacenter que j'ai vu c'est IPv6 côté collecteur puis immédiatement ZigBee pour tout le reste. Il y a bien un tentative de faire du 6TOLWPAN ici ou là - mais ça a pas l'air de prendre des masses. Bref IPv6 utilisé uniquement pour l'adressage et tout le reste de la pile en ZigBee c'est le plus courant.
La plupart de l'IOT domotique et autre de nos jours n'utilise plus ZigBee mais IPv4/V6 avec MQTT ou CoAP en layer 7
Chez les installation de particuliers libristes peut-être. Mais en domotique "pro" j'ai vu du Crestron, du KNX, du ZWave et du ZigBee chez les particuliers. Partfois de l'AMX.
Chez les hotels du Lutron, de l'AMX et d'autres protocoles et équipements proprios.
Le truc c'est que personne ne sait reprendre la maintenance d'une installation IPv6 + protocoles IPv6 ouverts. Si la société qui te fait l'install disparait tu es bon pour tout démonter et recommencer de 0.
Il y a du vrai mais c'est clairement exagéré. Chez moi (home), au alentours de 30% du traffic sort et rentre en IPv6
Oui coté d'un particulier sachant on peut faire de l'IPv6. Mais honnêtement à part par curiosité intellectuelle, ça n'apporte pas grand chose.
Puisqu'on est sur les expériences perso - dans toutes les grosses installs que j'ai fait pour des hôtels ou des entreprises, si un lien tombe et affecte les routes IPv4, j'avais même pas le temps de recevoir les remontés de sonde que déjà un client m'appellait pour se plaindre (et mes routes backups démarrent et convergent en moins de 10 minutes)
IPv6 pouvait rester par terre plusieurs jours - j'ai jamais eu une plainte. (Une remarque une fois d'un admin réseau pointilleux après 48h)
A l'époque (il y a 4 ans) j'avais 650 000 routes + peering IPv4 et 320 000 routes + peering IPv6. Certes on avait 12-15% du traffic qui passait par IPv6 mais ca représentait moins de 1000 routes différentes par mois. En IPv4 on était sur 85 000 routes distinctes par mois.
, mais tu peux toujours passer par des workaround moins optimisés également. Je ne vois pas de complexité « en plus », à défaut d'être mieux qu'IPv4 sur ce point précis.
Non. IPv6 a besoin du multicast pour fonctionner correctement - et ce WKM (Well Known Multicast - norme IPv6) ne passe pas toutes les appliances ou tous les routeurs de la même façon. En bref tu as besoin de faire passer un certains nombre des adresses de https://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml d'un bout à l'autre d'un lien routé (comprendre pas un circuit).
En IPv4 j'ai énormément d'options pour créer un réseau virtuel L2 réparti sur 15 sites non connectés en direct. Du du PPPOE, du GRE, du VxLAN. Je peux snooper les multicasts etc.
En IPv6 j'ai rien. Pas un routeur, pas un switch, pas une appliance à qui je puisse dire "sur tel vlan la trame multicast tu la traites, mais sur l'autre vlan tu encapsule et tu transmet par l'overlay/le tunnel/le lien virtuel"
Et du coup je peux pas créer un réseau niveau 2 virtuel en IPv6
Pourquoi vouloir étendre un L2 ? C'est évident que la complexité va arriver, après.
Parce que c'est quelque chose dont on a tout le temps besoin. Parce que en IPv4 ça a toujours marché et que ça permet d'avoir une couche réseau unifiée au niveau opérationnel différente de l'infrastructure. Donc load balancing, haute dispo, partage de ressources (niveau interco et peering notamment) etc.
Je ne vois pas la nécessité de reconfigurer « tous les équipments »
Si tu te retrouves dans la situation ou tu fusionne deux coeurs de réseaux ou par exemple l'annonce du ::3 se fait par SLAAC et que tu veux utiliser celui qui est sur l'autre site, tu te retrouves dans la situation ou tu dois passer sur tous les équipements pour faire que l'info multicasté du site 1 arrive sur le site 2.
Ah, très bonne remarque : Kubernetes, Docker, OpenStack et consorts, toutes ces technos « modernes », ont été faite avec zéro IPv6 en tête. Ce sont des archis entièrement basées sur du NATtage dans tous les sens, pour lesquelles on a mis IPv6 à posteriori pour faire joli.
Oui et VMWare, DC/OS-Marathon, OpenFlow, Vyatta … Dingue non ? Même Amazon qui fabrique du VPC comme d'autres mangent des cacahuètes préconisent IPv4 dès que ton archi devient un peu complexe niveau flux.
Même les gens qui font de l'IOT utilisent IPv6 pour l'adressage mais passent en ZigBee dès que possible pour le transport.
Donc si on résume : IPv6 fonctionne très bien et peut tout faire, c'est juste que les constructeurs, les opérateurs, les développeurs de softs, les fournisseurs de solutions de virtualisation - que ce soit propriétaire ou libre, coté client ou coté réseau - ne veulent pas, ou ne pannent rien ou les deux.
Aucune raison de se remettre en cause donc. Tout va bien…
Non, non
Le problème principal est que IPv6 a besoin de nombreux mécanismes en plus du transport unicast pour fonctionner. Entre autre (mais pas seulement) du well known multicast et de tout un tas de protocoles qui utilisent ce well known multicast.
Pour tous ces mécanismes il existe le plus souvent plusieurs choix, qui sont incompatibles les uns avec les autres et qui en plus passent souvent mal les méthodes de virtualisation de réseau. Typiquement si tu fais du eVPN pour relier deux réseaux tu vas avoir vraiment beaucoup de mal à faire que les infos multicasts passent correctement d'une branche de réseau à l'autre via l'overlay.
Par exemple tu veux fusionner les cœurs de réseau de deux sites, mais tu veux que les bordures de réseau et les vlans internes restent chacun sur leur site. De ton coté tu utilises SLAAC + DHCPv6 static pour configurer tes machines internes - de l'autre l'admin utilise aussi SLAAC mais utilise le WKM pour mettre le DNS sur la gateway en ::3.
Après de ton coté les routes convergent en utilisant IS-IS, mais de l'autre coté tout est réglé pour utiliser OSPFv3. OSPFv3 est aussi utilisé pour les segments sur la même branche entre switchs/routeurs alors que toi pour ces segments là tu utilises NDP.
Et bien bonne chance pour réussir ta mission sans reconfigurer tous les équipements d'un coté ou de l'autre, voire en racheter au cas ou certains mécanismes ne sont pas disponibles.
Le plus souvent c'est un bazar sans nom et tu es obligé de passer par la case interruption de service.
Et là on essaye de faire un lien pur L2. Bien sur à chaque fois que l'on remonte un layer on se prend une couche de complexité supplémentaire. (Genre connecter le cloud kubernetes du site A et tous ses réseaux virtuels sur le coeur du site B)
Honnêtement, ce que tu décris (une interco L2, tu fais ce que tu veux dessus, du BGP de l'IS-IS, de l'OSPF et l'opérateur ne le "vois pas")
Une connexion L2 (C'est à dire un lien dédié, un lambda, bref dès que ton circuit correspond à une réalité physique) - là effectivement il n'y a pas de soucis.
Un lien virtuel (donc avec un intermédiaire dans ta connexion) ça n'est jamais 100% transparent en IPv6. Ça peut être masqué de l'opérateur et sans effet de bord pour lui (chiffrement, tunnels, mélange des deux). Mais typiquement les paquets et les équipements ne vont pas se comporter de la même façon. Le well-known multicast ne va pas passer, le ndp va faire des trucs bizarres, les routeurs vont perdre le nord etc.
Ça je sais pas, en tout cas tu sembles pas vouloir te remettre en question, tu préfères accuser IPv6 de problèmes qu'il n'a pas et c'est dommage.
Niveau ne pas vouloir se remettre en cause, je pense que dans le cadre du débat "Pourquoi IPv6 n'a pas pris en 25 ans ?", je ne suis même pas dans le camps qui a un problème de déni.
Oui, même si je pense qu'ils vont laisser dormir le truc un petit moment. Il y a pas mal de sociétés qui utilisent cette plage comme une plage privée - dont amazon… (C'est dingue le nombre de sociétés qui semblent incompétentes à utiliser IPv6 même quand ils en ont franchement besoin).
Donc le temps de faire le ménage chez eux et d'attendre que leurs clients et peers fassent de même, je pense qu'on est tranquille jusqu'en janvier.
Après je rechigne un peut à utiliser la 255/8 - mais il reste encore de 240/8 à 254/8 pour faire du bricolage.
En finalité je dirais que personnellement je n'utilise ce truc que le temps de rendre compatible les cœurs de réseau et d'attendre la livraison des liens dédiés. En général moins de 12 mois. Par contre je connais des boites qui vont vraiment faire la gueule… A commencer par à peu près tous les gros opérateurs français.
Je sais, d’où mon c'est moche. Mais comme elles ne sont pas routées non plus…
C’est toi qui le dit, parce que tu es dans un cas d’usage particulier : fusion d’entreprise, plusieurs sites avec des "routes" trop petite pour être annoncées globalement
Ben moi depuis le début je suis dans le cas d'un opérateur qui doit interconnecter deux cœurs de réseau (donc nécessairement au niveau L2) et qui doit également préserver les interco L2 qu'il a vendu à ses clients - pour du CAN et du MAN notamment.
Je suis grosso-modo dans la situation
LAN1 <--> opérateur tiers <--> LAN2 ou
LAN1 <--> Mon réseau + opérateur tiers <--> LAN2 Avec LAN1 et LAN2 qui fonctionnent comme un MAN ou un CAN en mode full ou partial L2 et l'opérateur tiers qui fournit les annonces de route et la bande passante.
Ben en IPv6 je sais pas faire de façon à ce que (par exemple) tout le multicast remonte sur le LAN1. En direct les opérateurs tiers refusent, en eVPN/VXLAN tous les constructeurs me disent que ça ne marche pas. Dans les tunnels en OSPF je perds le well known multicast. En IS-IS avec du GRE ca marchotte mais il faut que la topologie soit compatible, sinon on a vite fait de faire des boucles entre les routeurs et il ne faut pas faire de snooping sinon blam etc.
En IPv4 je sais faire.
Hors ils se trouve qu'en tant qu'opérateur Télécom ou transporteur de médias (SDI et compagnie) c'est un problème auquel on est confronté tout le temps.
Donc le cœur de réseau reste principalement en IPv4, parce qu'au moins on a des solutions (même si ça implique d'utiliser des plages d'adresses qui ne sont pas officiellement privées comme la 44/8 et la 240/4 et les plages de test)
Maintenant c'est surement que je suis fainéant et incompétent, que toutes les personnes avec qui je travaille son fainéantes et incompétentes, que tous les opérateurs que j'utilise sont fainéants et incompétents et que tous les constructeurs sont fainéants et incompétents.
C’est quoi un « fournisseur d’accès backbone » pour toi ? Un transitaire ?
Transitaire, peereur, annonceur - toute personne qui fournit ton accès principal si tu n'es pas tier 1.
Si c’est ça, dans les 2 cas c’est la même chose, tous les ISP savent s’interconnecter en BGP
Tous les gros oui. Mais si tu viens avec une petite plage IP et qu'en plus tes routes se baladent entre plusieurs sites, tu vas te faire jeter. C'est pourquoi généralement quand tu as des tranches IP modestes il faut que tu ais un annonceur qui expose tes routes au niveau public et qui fasse les liens.
plutôt que de devoir renuméroter deux réseaux où les admins ont chacun choisit 10.0.0.0/8.
Typiquement si j'ai deux entreprises et que je veux mutualiser une ressource (un plateau régie au hasard) je préfère 100 fois faire du mapping ip 1:1 avec DNS dynamique qui fera que les adresses 10.0.0.0/8 d'un site seront mappés sur les adresses 44.0.0.0/8 d'un autre site que de devoir me dépatouiller à essayer de faire dialoguer intelligemment l'IS-IS de la boite 1 avec l'OSPFv3 de la boite 2.
En fait je préfère faire du NAT64 dans les deux boites et faire un mapping des adresses qui m’intéressent via 44.0.0.0/8. C'est immonde mais ça n'a pas d'effet de bord et ça marche.
tout cas, des AS qui s’interconnectent en IPv6 y en a des centaines (exemple plus ou moins au hasard) :
Oui ça se fait, mais c'est très très pénible.
Seulement les fainéants et les gros qui ne savent/peuvent pas prendre de décisions rapides.
C’est bien de balancer des sigles, mais tu mélange plein de trucs qui n’ont rien à voir entre eux. Quel rapport entre des interco, IPv6 mobile, IS-IS, NDP et DHCPv6 ?
En plus j'avais fait gaffe à les mettre dans l'ordre. Quand tu fais de l'IPv6 tu as beaucoup de choix à faire. Entre IS-IS et OSPFv3, entre SLAAC et DHCPv6 (avec ou sans NAT66) - jusqu'ou tu laisse monter et ce que tu laisses passer dans le well known multicast etc. - ces choix sont plus ou moins incompatibles les uns avec les autres.
Si tu veux du L2 et faire ce que tu veux dessus, va chez un fournisseur qui te fais des interco L2, mais n’accuse pas IPv6 de problèmes qui n’ont rien à voir.
Je suis opérateur et je veux faire du peering/merger mon coeur de réseau suite à un rachat/changer de fournisseur d'accès backbone.
Et bien entendu je veux aussi migrer mes clients à qui j'offre aujourd'hui des prestations CAN ou MAN.
Quand je dis que IPv6 ne marche pas pour les ISP, ça veut dire en tant qu'ISP (ou opérateur tel, ou transporteur de contenu vidéos) à chaque fois que je dois m'interconnecter avec un autre ISP (ou…) c'est une galère sans nom.
D’où le fait que les opérateurs soient restés aussi éloignés que possible, aussi longtemps que possible d'IPv6.
Et pourquoi pas ?
Y a aucune différence, dans tous les cas t’auras probablement un pare-feu devant pour filtrer.
Tu mets la plage IP de management de tes firewalls derrière tes firewalls ?
Tu mets ton routage SAN derrière une authentification dont la clef se trouve sur les SAN ?
Cela fait des années que des opérateurs nationaux d'envergure ont passé le cap et que d'autres attendent. On peut penser à Proximus en Belgique qui détient une bonne part de marché et qui a fait la transition nationalement depuis un moment.
Ah bon je peux aller chez Proximus et ils vont me faire la prise en charge full de mes segments de réseaux entreprise avec transport IS-IS site à site ? Ils routent IPv6 mobile ?
Je vais faire du NDP CAN ou MAN ? De la façon dont je l'entend ? (C'est à dire qu'ils sont OK si je fais IS-IS+segments privés NAT 66+DHCPv6 ou de l'OSPFv3+SLAAC)
Je suis prêt à parier que comme ce sont des "gros", si je veux interconnecter mes AS avec eux ils vont me filer une liste assez stricts de protocoles et de méthodes que je dois suivre. Et suivant les choix que j'ai effectué je vais soit devoir changer complètement mon réseau, soit devoir créer des tunnels dans tous les sens, soit monter des étages et des étages de mapping et de transformation.
Et après si je veux m'interconnecter à deux ou plus providers, ça devient vraiment drôle.
Bien sur que dans le cas ou tu maitrises totalement tes clients (en tant que provider tu leur file l'adresse, la config et souvent le matos) avec pour seul but de faire du point à point sur le web, ça marche.
Le principal problème de l'IPv6 c'est que c'est un changement majeur, qui nécessite une période de transition, qui est donc une opération coûteuse financièrement et un peu délicate techniquement pour un gain commercial faible.
Mais il y en a eu plein des changements majeurs qui était couteux financièrement, délicat techniquement et pour un gain commercial faible. Quand SFR a commencer à vendre des téléphones de voiture, ils avaient très peu de clients. Ils avaient littéralement déployés des balises un peu partout en France pour 200 VRP et 30 chefs d'entreprise technophiles.
Quand internet est sorti des universités, pareil. Personne n'y croyait, et personne ne voulait recréer pour ainsi dire ex-nihilo une nième gestion de circuits.
Et là tout le monde veut des lots d'adresses IP publiques pour gérer des réseaux PME, tout le monde veut du routage dynamique cross-site, tout le monde demande de la flexibilité d'adressage et de la migration de segments. Et au lieu de ça on a des ::64 ou au mieux des ::56 et on ne peut même pas choisir ses subnetid ou migrer un groupid.
IPv6 ne prend pas parce que personne n'en veut. Personne n'en veut parce que ça n'apporte que des ennuis, et aucun des "avantages" théoriques d'IPv6 n'est utilisable à moins d'avoir assez de poids parmi les acteurs d'internet pour exiger que les personnes qui ont besoin de s'interconnecter à vous fassent ce que vous demandez.
Pour tous les autres c'est liaison dédiée et VPN, routage statique et réseau privé.
Ma question est plus : en quoi avoir un préfix v6 privé t'empèche d'avoir du multi-cast dessus ?
Ca empêche pas, mais ca fait un vrai réseau par dessus. Ca a un impact au niveau routage interne, il faut que les cartes prennent plusieurs MAC si il n'y a pas de carte dédiées pour le multicast (et la plupart des équipements n'en ont pas). il faut souvent rajouter des segments de réseaux si on ne veut pas que du multicast transpire plus loin que ce qu'on voudrait au cas il y a du snooping. Mais il faut faire gaffe à ne pas bloquer le multicast "de base" d'IPv6 quand on écrit les règles de ségrégation. Il y a moult choix à faire qui vont de OSPFv3 ou IS-IS à vlan ou snooping ou les deux.
Et quand tu dois merger deux coeurs de réseaux ou deux admins distincts ont fait des choix distincts - ben ça grince.
Posté par Kaane .
En réponse au journal L'IPv6 et moi.
Évalué à 5.
Dernière modification le 27 septembre 2019 à 10:05.
La convergence apparait quand tu l'utilises à l'échelle généralement. IPv6 a été pendant 20 ans à -2% d'adoption car tout le monde s'en foutait: "c'était pour demain".
Pas parce que c'était pour demain, parce que pour les ISP ca ne marchait pas. Que les normes et les RFC s'updataient et s'invalidaient plus vite qu'on ne pouvait suivre et que les constructeurs essayaient quand même un peu de vendre les machines qu'ils venaient de passer 2 ans de R&D à concevoir avant de revoir leur copie.
SIP au passage est de 1999. Donc pas si loin, et pourtant c'est toujours le bordel pour avoir un système de join / notifications qui marche cross soft-phone et des implémentations qui traversent les NAT correctement.
Le NAT Transversal ça a toujours été pénible. Pour le join/notification sur une archi que tu maitrises de bout en bout et des logiciels IPBX pro dans mes souvenirs ca marchait pas trop mal. Maintenant c'est vrai que si tu ne maitrises qu'un seul des segments, l'autre bout peut avoir fait un switch SIP/SS7 un peu à l'arrache et tu perds des messages.
Ça selon moi c'est une fausse excuse. Si le constructeur est pas foutu de se justifier sur "pourquoi" ça marche pas, c'est sa faute, pas celui du standard.
Quand les trois plus gros constructeurs du marché n'arrivent pas à fournir une fonctionnalité que tous les gros clients du monde demande (multicast dans l'overlay, pour tout ce qui est cloud ça serait vraiment, vraiment bien) il faut commencer à remettre en cause le standard.
Tu as un cas en tête où utiliser un prefix privé cause un pb pour le multi-cast
Les préfixes privés dans IPv6 sont par définition unicast.
[^] # Re: Méthodologie à améliorer
Posté par Kaane . En réponse au journal Coronavirus : vers une sortie de crise ?. Évalué à 2.
Il n'est pas ignoré. Mais il n'est pas non plus considéré comme le référent principal. C'est l'équipe de l'hôpital de la Pitié Salpêtrière qui a ce titre. Donc il n'est perçu comme le numéro 1.
[^] # Re: Méthodologie à améliorer
Posté par Kaane . En réponse au journal Coronavirus : vers une sortie de crise ?. Évalué à 7.
Ça s'appelle une publication d'urgence. Pour une publication dans un cycle classique, il faut une revue par les pairs, c'est à dire par des experts en maladies infectieuses contagieuses. Déjà normalement ça prend des jours, mais là en plus les différents experts sur le sujet sont un poil occupé.
Après sur les experts reconnus en ce qui concerne le sujet (maladies infectieuses contagieuses donc) en France il y en a 3 qui bossent à la Pitié Salpêtrière sur un protocole Lopinavir-Ritonavir. Les 5 autres à part le professeur Raoult sont aussi à l'IHU Marseille (le centre hospitalier du professeur Raoult). Donc le papier validé en urgence par le "voisin de paillasse" ça se justifie assez facilement.
Oui c'est comme ça qu'on fait les premiers tests - sur un échantillon très réduit. C'est comme ça qu'on obtient l'autorisation de faire le test étendu.
L'absence de placebo c'est normal, il n'y a pas d'effet placebo qui affecte la charge virale d'un patient le (patient peut se sentir mieux avec un placebo, mais il garde une charge virale équivalente à celui d'une personne qui ne reçoit pas le placebo)
L'absence de double aveugle est liée au point précédent. Comme on mesure des quantités qualifiées objectivement (charge virale) la capacité des médecins à favoriser tel ou tel type de patient par rapport à un autre est quand même limité. Ceci dit ça aurait été mieux en effet (même si médicalement ça ne sert pas forcément, ça aurait pu permettre de couper court à certaines questions stériles)
Pour finir l'exclusion des 6 personnes. C'est tout à fait normale, l'étude porte sur des personnes infectées récemment, non sur-infectées par des maladies opportunistes. Les 6 personnes exclues de l'étude tombent dans un de ces deux cas, voire les deux. Conserver leurs données aurait faussé le test. De plus même en supposant qu'il ait triché pour améliorer ses résultats, on a quand même 20 personnes sur 26 avec une charge virale minimale au bout de 6 jours au lieu de 20. 77% de réussite du traitement en première approche - ça reste très honorable.
Pour finir, le but de M. Raoult était de reproduire en France le plus vite possible les résultats d'une étude chinoise (avec un petit bonus pour l'utilisation de l'azithromycine en double emploi comme barrière cellulaire et anti-biotique de prévention des maladies pulmonaires opportunistes)
Oui enfin le monsieur est quand même considéré comme numéro un mondial sur le sujet par tout le monde sauf la France.
J'ignore pourquoi il annonce qu'une étude sur 20 personnes peut être plus significative qu'une étude sur 10 000 personnes. Je suis sur qu'il a une bonne raison.
Si je devais faire une hypothèse je dirais qu'il s'agit de la perturbation par des facteurs extérieurs. On peut raisonnablement faire le suivi d'une maladie sur 20 à 100 personnes à l'exclusion de tout facteur extérieur. Sur 10 000 c'est plus complexe.
Ça on peut va pas dire le contraire. Le Professeur Raoult multiplie les brevets, publications et sources de revenus para-médicales. Mais peut-on vraiment lui en vouloir - il a grandement fait avancer la médecine, ne serait-ce qu'au niveau des détections et des diagnostiques. Là ou le gouvernement Hollande fermait 17 500 lits dans les établissements hospitaliers, lui avec ses financements parallèles il en ouvrait 1000 sur la région Aix-Marseille. On peut ne pas aimer le procédé, mais là il y a quand même légitime défense de son pôle.
[^] # Re: Inertie?
Posté par Kaane . En réponse au journal Coronavirus : vers une sortie de crise ?. Évalué à 8.
Dans l'ordre
a) Avant que tous les paludismes du monde ne soient résistant à la nivaquine, on faisait exactement ça.
b) Il y a effectivement des cas de chocs anaphylactiques suite à la prise continue de chloroquine - mais si on est en environnement hospitalier il y a très peu de chance que ce soit un problème grave. Il faut bien sur un suivi et un contrôle, mais le problème ici est nettement plus logistique (pas assez de lits, pas assez de médecins) que sanitaire (Le médicament a 70 ans, ses effets indésirables sont connus). Il y a des protocoles pour ce genre de cas (Par exemple rester à l’hôpital pendant environ 2/3h après la prise du médicament problématique pour ne pas encombrer les lits mais être suivi quand même en cas de soucis. Vu l'avancement de la crise même ça n'est plus possible aujourd'hui.)
c) Il ne s'agit pas ici de chloroquine mais d'hydroxychloroquine qui est nettement moins problématique.
d) Le protocole du Dr Raoult ne préconise absolument pas de distribuer le Plaquenil comme des bonbons à la sortie des écoles, mais de faire le test systématique des patients pour les coronavirus (pas que Covid-19) et en cas d'infection + symptômes de soigner systématiquement. Il y a une décision à prendre dans le cas d'une infection asymptomatique (traitement ou pas ?) Son opinion est qu'il faudrait soigner là aussi, mais admets que ce n'est qu'une opinion.
Oui enfin après avoir refusé de prendre en compte les études Chinoises sur le sujet qui appliquaient le protocole du Dr Raoult (Le protocole initial était Plaquenil + Doxycycline, mis au point lors des précédentes épidémies liées à des coronavirus) et qui démontraient son efficacité il y a plus de trois semaines et avoir trainé des pieds pour autoriser l'étude réduite alors que les tests in vitro était très positifs. (En plus de ne pas commander les amorces pour la détection du coronavirus par PCR).
Mais principalement les points les plus importants qui sont soulevés sont les suivants :
Aujourd'hui la Chine est à la pointe dans de nombreux domaines, notamment en ce qui concerne les maladies infectieuses. Peut-on se permettre de remettre en cause leurs études ? Très honnêtement aujourd'hui en tant que non médecin j'ai nettement moins confiance en les études du CDC américain (cough Glyphosate cough) qu'en celle des universités chinoises.
Il y a dix ans il fallait plusieurs jours pour faire des tests sur les maladies infectieuses: détection, traitement, réponse, validation. Aujourd'hui ça peut être fait en quelques heures. Il faudrait probablement dépoussiérer les protocoles d'autorisation des traitements pour prendre en compte ces avancées technologiques.
[^] # Re: « Vulnérabilité » pour des cas d'utilisation spécifiques
Posté par Kaane . En réponse au journal Nouvelle vulnérabilité pour les processeurs Intel : l’attaque CacheOut. Évalué à 4.
Là le soucis n'est pas tant là confiance dans les logiciels installés que la confiance dans l'ensemble de l'environnement. On est dans un cas ou n'importe quel utilisateur qui arrive à faire s’exécuter n'importe quel programme, même dans un environnement ultra protégé (c'est à dire des droits limités, du SELinux, des cgroups et autre posix capabilities) peut aller lire le contenu du processus d'à coté, voire de la vm d'à coté si elle tourne sur le même processeur physique.
Pour Spectre 2 il y avait trois solutions : soit interdire à tes utilisateurs d’exécuter le moindre processus qui n'est pas certifié. (Donc pas de virtulisation, mais aussi pas de developpement Java, Erlang, Javascript, .Net et j'en passe). Pas évident en environnement professionnel.
Deuxièmement désactiver les options processeurs impactées au niveau du bios (quand c'était possible) ou recompiler l'ensemble des process tournants sur le système sans utiliser les optimisations à risque. Mais là forcément les perfs peuvent prendre cher dans certains cas.
Dernière solution : recompiler le noyau et tous les modules et processus privilégiés (anti-virus, firewall, pilote, tout ce qui utilise des DMA etc.) avec retpoline. Impact de perfs limité dans la majorité des cas, mais il faut bootstrapper tout le système coeur… Du fun quoi…
C'est pas une attaque via un logiciel existant dans lequel tu vas réussir à provoquer un comportement à risque, du moins pas dans le sens ou tu utilises PHP ou Bind pour executer du code avec les droits root. Tu peux forcer le CPU à dumper le contenu d'un bloc du L1 dans le L2 et le récupérer depuis un compte lambda.
Si un jour un crétin trouve un autre exploit de la faille et le met en ligne "pour rire", la probabilité que ça arrive deviendra maximale en quelques heures. On est littéralement à un script près d'avoir un utilisateur non privilégié qui peut dumper le cache L1 du processeur dans un fichier. Après on peut considérer que la probabilité qu'un tel script voit le jour est très faible, c'est un choix. Mais dans tout un tas d’environnements, notamment quand on offre des capacités à ses clients pour exécuter du code custom, c'est quand même un vrai gros risque.
[^] # Re: « Vulnérabilité » pour des cas d'utilisation spécifiques
Posté par Kaane . En réponse au journal Nouvelle vulnérabilité pour les processeurs Intel : l’attaque CacheOut. Évalué à 4.
Je ne suis pas vraiment d'accord. Certes on peut (et c'est toujours vrai aujourd'hui) se préparer un système aux petits oignons en compilant tout manuellement. Mais très peu de gens ont les compétences pour créer et maintenir un tel système.
Désactiver un jeu d'instruction à la compilation, voire dans certains cas dès la phase de configuration, c'est déjà loin d'être évident sur des processeurs modernes. En plus on se retrouve avec un système unique, sur lequel si des bugs spécifiques apparaissent, il faut les gérer seul ou quasiment.
Là il s'agit (si on veut être prudent) de désactiver complètement les fonctionnalités RTM et HLE (et tout ce qui touche à l'hyperthreading, mais ça ça se fait bien). Non seulement il va y avoir un impact vraiment fort sur les perfs qui n'est pas forcément acceptable professionnellement, mais en plus il faut adapter tes fichiers de config et de compilation pour ainsi dire type de machine par type de machine.
A titre d'exemple mon ingesteur de données custom 0MQ+ScyllaDB se prenait 70% de pertes de perfs jusqu'à l'arrivée de retpoline au moment de SPECTRE/MELTDOWN. Pas évident de devoir choisir entre tourner à 30% de perfs ou tripler la facture d'hébergement.
Ça n'est absolument pas la question, certes Debian a des paquets binaires que l'on peut auditer, mais si tu dois compiler quoi que ce soit à la mimine, si tu veux un kernel optimisé ou si tu as besoin du moindre pilote (même libre) qui effectue une étape de compilation au déploiement du package - tu rentres dans le rouge immédiatement.
En fait même si tu ne prends que des packages standards libres Debian, tu vas probablement te retrouver dans le rouge quand même. Déjà pas mal de packages, modules et pilotes sont compilés avec la capacité de détecter et d'activer au runtime des optimisations CPU (crypto, NUMA, HLE etc.), ensuite tu fais quoi si tu as un environnement qui utilise ces instructions ? Tu recompile et tu redéploies tout ? (Dans le cas de retpoline, c'est ce qui s'est passé…)
Généralement si tu bosses dans tout un tas de domaines tu vas chercher à exploiter au maximum ton infrastructure, donc laisser le compilateur optimiser pour toi en mettant un -march qui correspond à ton architecture. Aller choisir les flags à la main un par un est complexe, surtout que les gars chez GCC ne s'attendent absolument pas à avoir un processeur qui possède le flag X mais pas le flag Y - vu qu'il existe exactement 0 processeur réel dans cette situation.
Donc tu te retrouves à essuyer les plâtres sur des configs de compilation qui n'ont aucun sens. Ou tu désactives les fonctions au niveau kernel (ou microcode) et tu regardes ce qui casse. Et clairement c'est pas un job que n'importe qui peut faire, et comme la majorité des boites n'a pas d'Ulrich Drepper sous la main…
Bref utiliser Debian avec des packages traçables n'évite absolument pas le problème. Ça mitige un peu dans le sens ou effectivement tu n’exécutes pas un code tiers qui a une intention malicieuse à la base - mais pour autant ça ne bloque pas une attaque via des logiciels établis.
[^] # Re: « Vulnérabilité » pour des cas d'utilisation spécifiques
Posté par Kaane . En réponse au journal Nouvelle vulnérabilité pour les processeurs Intel : l’attaque CacheOut. Évalué à 5.
Ne pas confondre la méthode d'exploitation de la faille qui a été trouvée et la faille elle-même. Outre l'exploitation de la faille, il reste la problématique de fond : le cache L1 permet à un processus B d'accéder à des informations mémoire d'un processus A. Même si là les chercheurs précise bien qu'ils n'ont pas de pistes pour un autre type d'attaque qui permettrait d'exploiter cette faille, ça ne veut pas dire qu'une autre attaque n'existe pas et n'existera jamais.
En effet, mais ça veut dire quoi "maitriser son informatique". Tout compiler soit-même à la mimine en s'assurant que l'instruction TSX (et d'autres instructions interagissant avec les échanges de données inter-coeurs, on est jamais trop prudent) ne sont jamais utilisées ? On parle d'une faille hardware là. Le moindre pilote client de base de données ou wrapper Vagrant (et on va pas parler de Docker, KVM, XEN et co.) peuvent potentiellement permettre un nouveau vecteur d'attaque. Il doit pas y avoir grand monde avec le temps, les compétences et la volonté de "maitriser son informatique" à ce point.
[^] # Re: Tout doucement alors
Posté par Kaane . En réponse au journal L'IPv6 et moi. Évalué à 1.
Sérieusement ? Tu m'intéresse réellement. Tout fonctionnait ? Le Well Knwown multicast passait bien d'un site à l'autre ? Le NDP dans l'overlay détectait bien toutes les équipements ? Bref le L2 apparaissait bien comme intègre ?
Aucun moyen depuis le réseau overlay de détecter la virtualisation ?
[^] # Re: Tout doucement alors
Posté par Kaane . En réponse au journal L'IPv6 et moi. Évalué à 1.
Sur la plupart des protocoles de transport existant, tu peux te permettre de raisonner en mode "trames" et te contenter de faire du transport bêtement. Du coup tu peux si besoin est encapsuler tout ça et le balader d'un bout à l'autre de ton réseau et même au delà si tu en as besoin.
IPv6 supporte assez mal ce genre de clowneries, et tu te ramasses des effets de bords, des retry, des logs etc. Du coup il se retrouve mécaniquement relégué au rôle de gadget activé pour faire plaisir (ou pour pouvoir peerer avec les GAFA) dans pas mal de réseaux.
Tu te retrouves donc assez vite dans l'incapacité de pouvoir servir de grosses demande clients de type L2 virtualisé, CAN ou MAN sans leur refourguer d'abord des liens dédiés en pagaille. Et là bien sur toute la marge est pour le fournisseur de lien et toi tu peine à rentabiliser tes équipements.
Cette incompatibilité majeure entre les mécanismes fondamentaux d'IPv6 et la réalité des commandes clients est à mon sens le plus gros frein aux investissements de ce coté.
Grosso-modo le message que je voulais faire passer au début est que ce n'est pas parce qu'il n'y a pas eu d'investissements qu'IPv6 n'est pas viable, mais c'est parce que IPv6 n'est pas viable mécaniquement (et non pas financièrement) qu'il n'y a pas eu d'investissement.
Mais tu as raison le thread et les dialogues de sourds ont un peu trop duré. Je déclare mes opposants dans ce débat vainqueurs par lassitude et je retourne virtualiser des L2 pour le fun et le profit.
[^] # Re: Tout doucement alors
Posté par Kaane . En réponse au journal L'IPv6 et moi. Évalué à 1.
Non.
Il existe un vaste monde dans lequel il y a littéralement des centaines de protocoles transport/réseau qui ne sont pas IP (v4 ou v6). Des transpondeurs satellites jusqu'au téléphone portable (ou pas), des équipements d'imagerie médicale jusqu'au camera 8k des matchs de foot, des commutateurs télécoms aux émulateurs de circuits…
Il y aussi pas mal de contraintes physiques qui s'appliquent et qui font que TCP/IP ou UDP/IP n'est pas une solution optimale ou même viable. Un exemple : IS-IS. Tu vois un moyen de faire rentrer IS-IS dans IPv6 ? Ca n'aurait aucun sens.
Et bien figure toi que le mec qui reçoit le flux de 50 caméras dans un stade et qui veut pouvoir faire la prod sans déplacer 12 camions de régies - en vrai il s'en moque d'IPv6. Il veut son SDI et son RTP. Idem pour le mec qui a besoin de surveiller en vrai temps réel 25 sites proches en cas d'alerte orage. Aucun des deux ne va switcher sur un protocole moins efficace, plus prône à l'erreur etc.
Ce mec si je veux pouvoir le servir sur ses gros besoins je dois faire une croix sur l'IPv6 sur mes meilleurs liens. Ce que tous les opérateurs font.
Déjà j'aimerai pouvoir dire "je fais rentrer IPv6 ans un L2 étendu" et non pas "j'étend mon L2 sur IPv6". Mais surtout virtualiser un réseau de nos jour c'est la base. Pouvoir monter une topologie réseau en dynamique à la demande sans déplacer un seul équipement physique c'est ce vers quoi tout le monde tend. Ça ne te plait pas tant pis. Infrastructure As A Service ils appellent ça. Tu cliques trois fois sur le mulot et tu as trois appliances internet facing avec tes IP et un backend connecté sur X serveurs de calculs, des lambdas, des serveurs de stockage (virtualisés aussi) etc. Sur ce réseau étendu à la demande je veux le routage IPv6, et les adresses, et le multicast, et IPv6 mobile (Non je déconnne).
J'ai pas les moyens de me payer plusieurs coeurs de réseau, et du coup ça m'arrangerait de pouvoir faire passer les clients qui payent et IPv6 sur les mêmes tuyaux. Ça m'arrangerai de pouvoir virtualiser le truc pour que si ça ne marche pas je puisse restaurer la config précédente en 3 clicks du même mulot mort que précédemment. Mais si c'est pas possible, le choix est vite fait.
Je n'ai pas d'appli. Je ne fait que du transport. Idéalement je ne devrais même pas avoir besoin de savoir ce que je transporte. Maintenant soyons clair au niveau transport, aujourd'hui, tout repose sur Ethernet. IPv6 over Token ça n'existe pas, IPv6 over Frame Relay est mort (et il y avait pas grand monde pour pleurer le jour de l'enterrement), les 802.1x sont pour ainsi dire assimilable à Ethernet dans 99.9% des cas. (Je dis ça et je fais du SPB et de l'IS-IS)
Mais je ne demande rien à IPv6 moi. Je voudrais juste qu'il puisse rentrer dans le même tuyau que les autres de façon à ce que je puisse faire mon transport sans me demander comment l'admin du site d'en face a implémenter la gestion de la distribution des adresses DNS et si ça va avoir un impact.
Non c'est pas de l'IP, ça n'en sera probablement jamais (trop complexe à synchroniser au niveau des flux) et ce ne sera jamais public. Et une fois de plus je ne fais que fournir du transport. Et avec un L2 étendu ça marche tout seul.
Il y a pas de "grand plan" de transition à IPv6. Il y a 3 acteurs qui font 50% du trafic mondial et qui forcent les ISP à implémenter la partie des RFCs IPv6 qui les interressent pour avoir du peering. Et un peu de bordure de réseau pour IPv6 sur mobiles.
Les bidouilles qui permettent de faire de la haute dispo ou de la virtualisation de réseau se répartissent en une multitude de protocoles plus ou moins libre (Salut à toi VRRP) et de nouveaux protocoles proprios apparaissent tous les jours pour le transport de médias, le monitoring temps réel, le clustering etc. On multiplie les techniques type VLan (802.1aq, VxLAN, MPLS) ou de splits de ports dispo (CGNAT).
Tu peux te dire que ce sont des gens qui n'ont pas compris internet, que c'est par incompétence ou appât du gain, et assimiler tous les efforts, l'argent et le temps qui sont dépensés à résoudre de novo les problèmes qu'IPv6 est supposé effacer à du gaspillage. Mais il faut voir la réalité en face : IPv6 ne correspond pas au besoin d'un internet moderne. Pour l'instant personne n'ose proposer un protocole concurrent de peur de déclencher une seconde guerre des protocoles internet, mais franchement entre la concentration des routes et l'alourdissement légal pour les petits, on va droit vers un pile de transport entièrement piloté par un consortium.
[^] # Re: Tout doucement alors
Posté par Kaane . En réponse au journal L'IPv6 et moi. Évalué à 2. Dernière modification le 12 octobre 2019 à 15:18.
Ça aurait le même effet que de mettre une amende à toutes les personnes qui font des documents officiels en autre chose qu'en LaTex.
Personne ne le ferai, et la plupart des gens préfèreraient payer l’amende ou bricoler un truc ou techniquement tu as une IPv6 publique mais tout est bloqué.
[^] # Re: Tout doucement alors
Posté par Kaane . En réponse au journal L'IPv6 et moi. Évalué à 2.
Je reprend, je veux (quelque soit la méthode utilisée) créer un réseau L2 virtuel. L2 dans L3 si tu veux. Dans ce cadre je n'ai aucun outil ou appliance qui me permettent de dire que tel ou tel paquet multicast L2 virtualisé doit être routé de telle ou telle façon L3.
En bref dans l'exemple que je donne je veux qu'un paquet multicast émis sur de l'overlay L2 virtualisé traverse un réseau routé L3 et ressorte de l'autre coté en tant que paquet L2 virtualisé à 10, 100, 1000km de là.
Mais même si tu as raison, je m'en fous - je peux spanner mon L2 sur N sites non connectés par des circuits et faire mon taf.
Donc MPLS, eVPN, GRE et j'en passe n'ont pas de sens ? Virtualiser un L2, ou faire que tes agents qui sont en déplacement puissent travailler à distance comme si ils étaient sur place (pour de vrai hein, en full ethernet) ça n'a pas de sens ?
OK comment je "route" simplement de la trame ethernet non IP ? Comment je load-balance ou que je mets en haute dispo un réseau complet avec tout ce qui transite dessus (y compris tout ce qui est non IP). Comment je fais qu'un mec qui branche une caméra à Cannes puisse la multicaster sur 3 sites de production différents sans toucher un seul instant à la config d'un seul routeur ou switch ? (de toute façon il est cameraman et il a autre chose à faire).
Que les choses soient claires, je sais virtualiser un L2 ethernet de façon transparente pour quasiment tout sauf Fibrechannel et IPv6. Et encore Fibrechannel c'est vraiment mourant et en plus en insistant un peu ça finit par passer (mais c'est pas complètement transparent)
[^] # Re: Tout doucement alors
Posté par Kaane . En réponse au journal L'IPv6 et moi. Évalué à 1.
Je n'ai jamais travaillé en profondeur avec Facebook et je ne connais personne qui y a bossé. Donc je ne peux pas dire grand chose dessus. Ceci dit Facebook au niveau flux ils sont impressionnants par la quantité de données, mais niveau complexité des traitements strictement réseau il sont quand même nettement en dessous d'un Amazon ou d'un Google à mon avis.
[^] # Re: Tout doucement alors
Posté par Kaane . En réponse au journal L'IPv6 et moi. Évalué à 1.
Vu les sommes qu'ils dépensent pour racheter un maximum d'IPv4 publiques, ça doit venir d'ailleurs.
Ah mais moi aussi j'ai offert du full IPv6 à qui le demandait. Sauf que a) personne ne demande et b) la question concerne le cœur de réseau et les réseau virtualisés. En bordure de réseau ça marche.
Le prix des IPv4 est déjà prohibitif dans tout un tas de pays. Le pool ARIN est vide depuis 2015. Et pourtant IPv6 ne prend toujours pas - à part sur de nouveaux besoin en bordure de réseau comme avec les smartphones.
Contre proposition : "Un bon nombre de sysadmins sont des gens intelligents curieux et passionnés, si IPv6 ne prend pas c'est qu'il est beaucoup trop casse gueule et complexe à maintenir"
[^] # Re: Tout doucement alors
Posté par Kaane . En réponse au journal L'IPv6 et moi. Évalué à 1.
Ça je sais, la question à se poser est pourquoi ? Pourquoi le réseau avec le plus d'endpoints public au monde n'utilise que très très peu IPv6.
Cloudlflare c'est un peu spécial, ils auraient du mal à être crédible en gros experts du CDN/WebFront si ils n'avaient pas IPv6.
Google, ils ont un bon support IPv6 pour la pub. Ils veulent pas passer à coté du marché Chinois ou Africain et ils veulent pouvoir autant que possible traquer les utilisateurs. C'est pour ça qu'ils encouragent les sites à avoir une résolution IPv6 en boostant leur ranking. Mais honnêtement la Chine est resté protégée et l'Afrique est pas encore franchement sur Internet. Au moins ça leur permet de traquer les smartphones - ceci dit avec les parts de marché Android, ils avaient déjà gagné cette partie là.
Microsoft a clairement vraiment beaucoup investi dans IPv6 - c'est même les seuls a avoir autant planché sur le sujet chez les institutionnels. Problème pour parer à toutes les éventualités ils ont créé masse de piles et de cartes virtuelles. On est monté à 5 dans les différentes versions de windows. Ca a pas vraiment encouragé à franchir le pas. Bien au contraire. Et puis on va rester poli et pas parler de l'IPv6 sur Azure, encore que ça s'améliore.
Certes, mais toutes les installations datacenter que j'ai vu c'est IPv6 côté collecteur puis immédiatement ZigBee pour tout le reste. Il y a bien un tentative de faire du 6TOLWPAN ici ou là - mais ça a pas l'air de prendre des masses. Bref IPv6 utilisé uniquement pour l'adressage et tout le reste de la pile en ZigBee c'est le plus courant.
Chez les installation de particuliers libristes peut-être. Mais en domotique "pro" j'ai vu du Crestron, du KNX, du ZWave et du ZigBee chez les particuliers. Partfois de l'AMX.
Chez les hotels du Lutron, de l'AMX et d'autres protocoles et équipements proprios.
Le truc c'est que personne ne sait reprendre la maintenance d'une installation IPv6 + protocoles IPv6 ouverts. Si la société qui te fait l'install disparait tu es bon pour tout démonter et recommencer de 0.
Oui coté d'un particulier sachant on peut faire de l'IPv6. Mais honnêtement à part par curiosité intellectuelle, ça n'apporte pas grand chose.
Puisqu'on est sur les expériences perso - dans toutes les grosses installs que j'ai fait pour des hôtels ou des entreprises, si un lien tombe et affecte les routes IPv4, j'avais même pas le temps de recevoir les remontés de sonde que déjà un client m'appellait pour se plaindre (et mes routes backups démarrent et convergent en moins de 10 minutes)
IPv6 pouvait rester par terre plusieurs jours - j'ai jamais eu une plainte. (Une remarque une fois d'un admin réseau pointilleux après 48h)
A l'époque (il y a 4 ans) j'avais 650 000 routes + peering IPv4 et 320 000 routes + peering IPv6. Certes on avait 12-15% du traffic qui passait par IPv6 mais ca représentait moins de 1000 routes différentes par mois. En IPv4 on était sur 85 000 routes distinctes par mois.
[^] # Re: Tout doucement alors
Posté par Kaane . En réponse au journal L'IPv6 et moi. Évalué à 1.
Non. IPv6 a besoin du multicast pour fonctionner correctement - et ce WKM (Well Known Multicast - norme IPv6) ne passe pas toutes les appliances ou tous les routeurs de la même façon. En bref tu as besoin de faire passer un certains nombre des adresses de https://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml d'un bout à l'autre d'un lien routé (comprendre pas un circuit).
En IPv4 j'ai énormément d'options pour créer un réseau virtuel L2 réparti sur 15 sites non connectés en direct. Du du PPPOE, du GRE, du VxLAN. Je peux snooper les multicasts etc.
En IPv6 j'ai rien. Pas un routeur, pas un switch, pas une appliance à qui je puisse dire "sur tel vlan la trame multicast tu la traites, mais sur l'autre vlan tu encapsule et tu transmet par l'overlay/le tunnel/le lien virtuel"
Et du coup je peux pas créer un réseau niveau 2 virtuel en IPv6
Parce que c'est quelque chose dont on a tout le temps besoin. Parce que en IPv4 ça a toujours marché et que ça permet d'avoir une couche réseau unifiée au niveau opérationnel différente de l'infrastructure. Donc load balancing, haute dispo, partage de ressources (niveau interco et peering notamment) etc.
Oui et VMWare, DC/OS-Marathon, OpenFlow, Vyatta … Dingue non ? Même Amazon qui fabrique du VPC comme d'autres mangent des cacahuètes préconisent IPv4 dès que ton archi devient un peu complexe niveau flux.
Même les gens qui font de l'IOT utilisent IPv6 pour l'adressage mais passent en ZigBee dès que possible pour le transport.
Donc si on résume : IPv6 fonctionne très bien et peut tout faire, c'est juste que les constructeurs, les opérateurs, les développeurs de softs, les fournisseurs de solutions de virtualisation - que ce soit propriétaire ou libre, coté client ou coté réseau - ne veulent pas, ou ne pannent rien ou les deux.
Aucune raison de se remettre en cause donc. Tout va bien…
[^] # Re: Tout doucement alors
Posté par Kaane . En réponse au journal L'IPv6 et moi. Évalué à 0.
Non, non
Le problème principal est que IPv6 a besoin de nombreux mécanismes en plus du transport unicast pour fonctionner. Entre autre (mais pas seulement) du well known multicast et de tout un tas de protocoles qui utilisent ce well known multicast.
Pour tous ces mécanismes il existe le plus souvent plusieurs choix, qui sont incompatibles les uns avec les autres et qui en plus passent souvent mal les méthodes de virtualisation de réseau. Typiquement si tu fais du eVPN pour relier deux réseaux tu vas avoir vraiment beaucoup de mal à faire que les infos multicasts passent correctement d'une branche de réseau à l'autre via l'overlay.
Par exemple tu veux fusionner les cœurs de réseau de deux sites, mais tu veux que les bordures de réseau et les vlans internes restent chacun sur leur site. De ton coté tu utilises SLAAC + DHCPv6 static pour configurer tes machines internes - de l'autre l'admin utilise aussi SLAAC mais utilise le WKM pour mettre le DNS sur la gateway en ::3.
Après de ton coté les routes convergent en utilisant IS-IS, mais de l'autre coté tout est réglé pour utiliser OSPFv3. OSPFv3 est aussi utilisé pour les segments sur la même branche entre switchs/routeurs alors que toi pour ces segments là tu utilises NDP.
Et bien bonne chance pour réussir ta mission sans reconfigurer tous les équipements d'un coté ou de l'autre, voire en racheter au cas ou certains mécanismes ne sont pas disponibles.
Le plus souvent c'est un bazar sans nom et tu es obligé de passer par la case interruption de service.
Et là on essaye de faire un lien pur L2. Bien sur à chaque fois que l'on remonte un layer on se prend une couche de complexité supplémentaire. (Genre connecter le cloud kubernetes du site A et tous ses réseaux virtuels sur le coeur du site B)
[^] # Re: Tout doucement alors
Posté par Kaane . En réponse au journal L'IPv6 et moi. Évalué à -1.
Une connexion L2 (C'est à dire un lien dédié, un lambda, bref dès que ton circuit correspond à une réalité physique) - là effectivement il n'y a pas de soucis.
Un lien virtuel (donc avec un intermédiaire dans ta connexion) ça n'est jamais 100% transparent en IPv6. Ça peut être masqué de l'opérateur et sans effet de bord pour lui (chiffrement, tunnels, mélange des deux). Mais typiquement les paquets et les équipements ne vont pas se comporter de la même façon. Le well-known multicast ne va pas passer, le ndp va faire des trucs bizarres, les routeurs vont perdre le nord etc.
Niveau ne pas vouloir se remettre en cause, je pense que dans le cadre du débat "Pourquoi IPv6 n'a pas pris en 25 ans ?", je ne suis même pas dans le camps qui a un problème de déni.
[^] # Re: Tout doucement alors
Posté par Kaane . En réponse au journal L'IPv6 et moi. Évalué à 0.
Oui, même si je pense qu'ils vont laisser dormir le truc un petit moment. Il y a pas mal de sociétés qui utilisent cette plage comme une plage privée - dont amazon… (C'est dingue le nombre de sociétés qui semblent incompétentes à utiliser IPv6 même quand ils en ont franchement besoin).
Donc le temps de faire le ménage chez eux et d'attendre que leurs clients et peers fassent de même, je pense qu'on est tranquille jusqu'en janvier.
Après je rechigne un peut à utiliser la 255/8 - mais il reste encore de 240/8 à 254/8 pour faire du bricolage.
En finalité je dirais que personnellement je n'utilise ce truc que le temps de rendre compatible les cœurs de réseau et d'attendre la livraison des liens dédiés. En général moins de 12 mois. Par contre je connais des boites qui vont vraiment faire la gueule… A commencer par à peu près tous les gros opérateurs français.
[^] # Re: Tout doucement alors
Posté par Kaane . En réponse au journal L'IPv6 et moi. Évalué à 2.
Je sais, d’où mon c'est moche. Mais comme elles ne sont pas routées non plus…
Ben moi depuis le début je suis dans le cas d'un opérateur qui doit interconnecter deux cœurs de réseau (donc nécessairement au niveau L2) et qui doit également préserver les interco L2 qu'il a vendu à ses clients - pour du CAN et du MAN notamment.
Je suis grosso-modo dans la situation
LAN1 <--> opérateur tiers <--> LAN2
LAN1 <--> Mon réseau + opérateur tiers <--> LAN2
Ben en IPv6 je sais pas faire de façon à ce que (par exemple) tout le multicast remonte sur le LAN1. En direct les opérateurs tiers refusent, en eVPN/VXLAN tous les constructeurs me disent que ça ne marche pas. Dans les tunnels en OSPF je perds le well known multicast. En IS-IS avec du GRE ca marchotte mais il faut que la topologie soit compatible, sinon on a vite fait de faire des boucles entre les routeurs et il ne faut pas faire de snooping sinon blam etc.
En IPv4 je sais faire.
Hors ils se trouve qu'en tant qu'opérateur Télécom ou transporteur de médias (SDI et compagnie) c'est un problème auquel on est confronté tout le temps.
Donc le cœur de réseau reste principalement en IPv4, parce qu'au moins on a des solutions (même si ça implique d'utiliser des plages d'adresses qui ne sont pas officiellement privées comme la 44/8 et la 240/4 et les plages de test)
Maintenant c'est surement que je suis fainéant et incompétent, que toutes les personnes avec qui je travaille son fainéantes et incompétentes, que tous les opérateurs que j'utilise sont fainéants et incompétents et que tous les constructeurs sont fainéants et incompétents.
[^] # Re: Tout doucement alors
Posté par Kaane . En réponse au journal L'IPv6 et moi. Évalué à 1.
Transitaire, peereur, annonceur - toute personne qui fournit ton accès principal si tu n'es pas tier 1.
Tous les gros oui. Mais si tu viens avec une petite plage IP et qu'en plus tes routes se baladent entre plusieurs sites, tu vas te faire jeter. C'est pourquoi généralement quand tu as des tranches IP modestes il faut que tu ais un annonceur qui expose tes routes au niveau public et qui fasse les liens.
Typiquement si j'ai deux entreprises et que je veux mutualiser une ressource (un plateau régie au hasard) je préfère 100 fois faire du mapping ip 1:1 avec DNS dynamique qui fera que les adresses 10.0.0.0/8 d'un site seront mappés sur les adresses 44.0.0.0/8 d'un autre site que de devoir me dépatouiller à essayer de faire dialoguer intelligemment l'IS-IS de la boite 1 avec l'OSPFv3 de la boite 2.
En fait je préfère faire du NAT64 dans les deux boites et faire un mapping des adresses qui m’intéressent via 44.0.0.0/8. C'est immonde mais ça n'a pas d'effet de bord et ça marche.
Oui ça se fait, mais c'est très très pénible.
Oui….
[^] # Re: Tout doucement alors
Posté par Kaane . En réponse au journal L'IPv6 et moi. Évalué à 2.
En plus j'avais fait gaffe à les mettre dans l'ordre. Quand tu fais de l'IPv6 tu as beaucoup de choix à faire. Entre IS-IS et OSPFv3, entre SLAAC et DHCPv6 (avec ou sans NAT66) - jusqu'ou tu laisse monter et ce que tu laisses passer dans le well known multicast etc. - ces choix sont plus ou moins incompatibles les uns avec les autres.
Je suis opérateur et je veux faire du peering/merger mon coeur de réseau suite à un rachat/changer de fournisseur d'accès backbone.
Et bien entendu je veux aussi migrer mes clients à qui j'offre aujourd'hui des prestations CAN ou MAN.
Quand je dis que IPv6 ne marche pas pour les ISP, ça veut dire en tant qu'ISP (ou opérateur tel, ou transporteur de contenu vidéos) à chaque fois que je dois m'interconnecter avec un autre ISP (ou…) c'est une galère sans nom.
D’où le fait que les opérateurs soient restés aussi éloignés que possible, aussi longtemps que possible d'IPv6.
[^] # Re: Tout doucement alors
Posté par Kaane . En réponse au journal L'IPv6 et moi. Évalué à -2.
Tu mets la plage IP de management de tes firewalls derrière tes firewalls ?
Tu mets ton routage SAN derrière une authentification dont la clef se trouve sur les SAN ?
[^] # Re: Tout doucement alors
Posté par Kaane . En réponse au journal L'IPv6 et moi. Évalué à 2.
Ah bon je peux aller chez Proximus et ils vont me faire la prise en charge full de mes segments de réseaux entreprise avec transport IS-IS site à site ? Ils routent IPv6 mobile ?
Je vais faire du NDP CAN ou MAN ? De la façon dont je l'entend ? (C'est à dire qu'ils sont OK si je fais IS-IS+segments privés NAT 66+DHCPv6 ou de l'OSPFv3+SLAAC)
Je suis prêt à parier que comme ce sont des "gros", si je veux interconnecter mes AS avec eux ils vont me filer une liste assez stricts de protocoles et de méthodes que je dois suivre. Et suivant les choix que j'ai effectué je vais soit devoir changer complètement mon réseau, soit devoir créer des tunnels dans tous les sens, soit monter des étages et des étages de mapping et de transformation.
Et après si je veux m'interconnecter à deux ou plus providers, ça devient vraiment drôle.
Bien sur que dans le cas ou tu maitrises totalement tes clients (en tant que provider tu leur file l'adresse, la config et souvent le matos) avec pour seul but de faire du point à point sur le web, ça marche.
Mais il y en a eu plein des changements majeurs qui était couteux financièrement, délicat techniquement et pour un gain commercial faible. Quand SFR a commencer à vendre des téléphones de voiture, ils avaient très peu de clients. Ils avaient littéralement déployés des balises un peu partout en France pour 200 VRP et 30 chefs d'entreprise technophiles.
Quand internet est sorti des universités, pareil. Personne n'y croyait, et personne ne voulait recréer pour ainsi dire ex-nihilo une nième gestion de circuits.
Et là tout le monde veut des lots d'adresses IP publiques pour gérer des réseaux PME, tout le monde veut du routage dynamique cross-site, tout le monde demande de la flexibilité d'adressage et de la migration de segments. Et au lieu de ça on a des ::64 ou au mieux des ::56 et on ne peut même pas choisir ses subnetid ou migrer un groupid.
IPv6 ne prend pas parce que personne n'en veut. Personne n'en veut parce que ça n'apporte que des ennuis, et aucun des "avantages" théoriques d'IPv6 n'est utilisable à moins d'avoir assez de poids parmi les acteurs d'internet pour exiger que les personnes qui ont besoin de s'interconnecter à vous fassent ce que vous demandez.
Pour tous les autres c'est liaison dédiée et VPN, routage statique et réseau privé.
[^] # Re: Tout doucement alors
Posté par Kaane . En réponse au journal L'IPv6 et moi. Évalué à 2.
Ca empêche pas, mais ca fait un vrai réseau par dessus. Ca a un impact au niveau routage interne, il faut que les cartes prennent plusieurs MAC si il n'y a pas de carte dédiées pour le multicast (et la plupart des équipements n'en ont pas). il faut souvent rajouter des segments de réseaux si on ne veut pas que du multicast transpire plus loin que ce qu'on voudrait au cas il y a du snooping. Mais il faut faire gaffe à ne pas bloquer le multicast "de base" d'IPv6 quand on écrit les règles de ségrégation. Il y a moult choix à faire qui vont de OSPFv3 ou IS-IS à vlan ou snooping ou les deux.
Et quand tu dois merger deux coeurs de réseaux ou deux admins distincts ont fait des choix distincts - ben ça grince.
[^] # Re: Tout doucement alors
Posté par Kaane . En réponse au journal L'IPv6 et moi. Évalué à 5. Dernière modification le 27 septembre 2019 à 10:05.
Pas parce que c'était pour demain, parce que pour les ISP ca ne marchait pas. Que les normes et les RFC s'updataient et s'invalidaient plus vite qu'on ne pouvait suivre et que les constructeurs essayaient quand même un peu de vendre les machines qu'ils venaient de passer 2 ans de R&D à concevoir avant de revoir leur copie.
Le NAT Transversal ça a toujours été pénible. Pour le join/notification sur une archi que tu maitrises de bout en bout et des logiciels IPBX pro dans mes souvenirs ca marchait pas trop mal. Maintenant c'est vrai que si tu ne maitrises qu'un seul des segments, l'autre bout peut avoir fait un switch SIP/SS7 un peu à l'arrache et tu perds des messages.
Quand les trois plus gros constructeurs du marché n'arrivent pas à fournir une fonctionnalité que tous les gros clients du monde demande (multicast dans l'overlay, pour tout ce qui est cloud ça serait vraiment, vraiment bien) il faut commencer à remettre en cause le standard.
Les préfixes privés dans IPv6 sont par définition unicast.