J'ai craqué pour une mise à jour de ma connexion Internet vers la fibre. La tentation d'avoir enfin un upload décent, mais également un tout nouveau routeur qui savait parler IPv6.
Ça marche du premier coup
Ce fut étonnamment facile, finalement. Une fois le routeur installé, je fis un ping chez google. Miracle!
64 bytes from lhr25s12-in-x04.1e100.net (2a00:1450:4009:80d::2004): icmp_seq=8 ttl=53 time=3.05 ms
Parce qu'en fait, les OS sont déjà prêts. Le DHCP du routeur a fourni à la machine une IPv4 et une IPv6. Quand je rendre une adresse dans le navigateur, Linux fait fait une requête DNS, préfère l'IPv6 si elle est disponible, et roule ma poule.
Le DNS
En fait, il y a une astuce. Mon fournisseur d'accès à Internet (British Telecom, je vis à Londres) n'a en fait que des DNS IPv4. Ce qui veut dire que la majorité de leurs utilisateurs sur les nouveaux routeurs ont des IPv6 (et même énormément, ce sont des /64), mais ne les utilisent pas, puisque le DNS ne leur donnera qu'une IPv4 pour se connecter.
Seulement, cela faisait bien longtemps que je n'utilisais pas leurs DNS, et m’adressais directement aux DNS racines via un bind9 correctement configuré, lequel va par défaut chercher à la fois les IPv4 et les IPv6. Donc chez moi, ça marche.
C'est quand même dommage, non ? Cela veut dire qu'il suffirait à Mr British Telecom d'un petit changement au niveau du DNS pour que tout d'un coup, une proportion non négligeable des utilisateurs se mettent à utiliser l'IPv6 par défaut, ce qui pourrait attirer l’œil du décideur pressé. Alors pourquoi ne le font-ils pas ? Peut-être qu'ils s'attendent à ce que cela casse certains sites, navigateurs, applications ou que sais-je d'autre, et que le coût d'une fraction de leurs utilisateurs furax appelant le support demeure trop important ? Mystère.
Et l'offre, dans tout ça ?
C'est pas tout d'avoir une IPv6, encore faut-il pouvoir se connecter avec quelque part. Ça tombe bien, le niveau de support des 500 plus gros sites est aimablement fourni ici.
Le résultat n'est pas trop surprenant : il n'y en a pas beaucoup. L'on retrouve les grosses boites orientées techno (Google avec Youtube et Blogspot, Facebook, Office, Netflix), les geeks (Wikipedia, Pirate Bay, Telegram, Patreon) et quelques institutionnels éclairés (europa.eu). De manière surprenante, Bitbucket y est, mais pas Github. Et Amazon, manifestement, ça ne les intéresse absolument pas.
Est-ce que parce que Google et Facebook, dans leur désir de nous suivre partout, trouvent en une IPv6 vraisemblablement fixe une donnée intéressante, alors qu'Amazon ne s'intéresse à nous que sur son site, sur lequel l'on est certainement déjà loggé de toutes façons ?
On remarquera également que la Chine ne s'intéresse absolument pas à l'IPv6, ce qui, pour un pays très centralisé où il suffirait d'un mot du parti pour que tout le monde s'y mette, est un petit peu étonnant. Je me demande si l'explication est que le l'IPv6 poserait de gros soucis de filtrage ciblé, ce qui empêche probablement beaucoup plus les instances dirigeantes de dormir que le manque d’adresses IPv4.
J'ai également pu configurer mon hébergement OVH pour qu'il accepte les connections IPv6. Peut-être qu'un nouvel hébergement serait déjà pré-configuré, mais en attendant, c'est encore dommage ! Pourquoi ne pas automatiquement configurer tous leurs clients pour augmenter l'adoption ?
Conclusion
On y vient doucement, finalement. Peut-être que petit à petit, tout le monde va s'y mettre, et que sans s'en rendre compte, un jour, dans 20 ans, on nous dira qu'on éteint officiellement IPv4, un peu comme on a éteint le Minitel, et personne (ou presque) ne se plaindra.
En attendant, c'est vrai que pour l'utilisateur lambda, l'intérêt, c'est epsilon.
# fichage
Posté par abriotde . Évalué à -2.
La comparaison avec minitel ne marche pas car le minitel était répandu qu'en France et au moment de son arrêt personne ne l'utilisait plus depuis 20ans.
Pour ton FAI, le problème est que ses logiciels ne sont sans doute pas très compatible IPV6 et surtout une partie trop faible de son réseau le gère. Mais il y a aussi sans doute une autre raison moins avouable, avec IPV4, ils font du fichage plus facilement un peu comme la Chine. Ils le font pour la pub, pour les services de renseignements, pour les abonnés premium…
[^] # Re: fichage
Posté par J Avd . Évalué à 6.
Désolé de péter tes illusions, mais IPv6 va être BEAUCOUP plus pratique pour la surveillance…
On oublie l'adresse MAC directement inscrite dans l'adresse, parce qu'on l'a viré de la conf par défaut (trop gros passera pas)…
Mais même avec une adresse IP "randomisée", il suffira de 4 métadonnées de type :
* tiens c'est marrant il est connecté à tel fournisseur SMTP
* tiens il utilise tel serveur DNS
* tiens il va synchroniser sa météo sur tel URL
* tiens il se connecte à Cloudtoto puis Cloudloulou puis Cloudmachin
=> It's a match !
Avec IPv6 tu vas être le grain de sable repérable à 5000 km.
"Gentoo" is an ancient african word, meaning "Read the F*ckin' Manual". "Gentoo" also means "I am what I am because you all are freaky n3rdz"
[^] # Re: fichage
Posté par claudex . Évalué à 8.
Sauf qu'avec les adresses randomisées, tu peux en changer toutes les 10 minutes. Ce qui n'est pas possible en IPv4. Il reste le préfixe, mais ça, c'est le même problème qu'en IPv4.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: fichage
Posté par voxdemonix . Évalué à -4. Dernière modification le 28 septembre 2019 à 13:53.
Tu peux tout a fait changer d'IPv4 toutes les dix minutes ou mieux encore : quand ton logiciel de téléchargement a dépassé les quotas de téléchargement (comportement de JDownloader).
[^] # Re: fichage
Posté par claudex . Évalué à 6.
Ce que tu décris est un fonctionnement particulier de ton FAI, tu n'as aucune garantie de changer d'IP. Alors qu'avec IPv6, tu peux changer d'adresse sans casser les sessions en cours (tu garde l'ancienne pendant un certain temps) et avec un peu de bricolage, tu peux même utiliser des IP différentes pour des sites différents.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: fichage
Posté par voxdemonix . Évalué à -2. Dernière modification le 28 septembre 2019 à 17:47.
C'est juste de l'IP dynamique. En .Be le FAI principal ayant un monopole propose cette offre par défaut : c'est donc un cas général ici.
Ça dépends des offres des FAIs.
Voir les petites lignes sous les offres, où on trouve entre autre qu'illimité pour un marketeux ça signifie entre 250Go et 700Go. 😅
Pratique pour des serveurs, du point de vue user par contre Tor Browser/Orbot reste bien plus facile et sécurisé. Sans compter l'aspect smartphone (et la galère du bridage tout azimut).
[^] # Re: fichage
Posté par claudex . Évalué à 3.
On parle d'Internet pas du réseau en Belgique. En plus, Voo et Telenet ont suffisamment de part de marché pour ne pas être négligeable.
Mauvais FAI, changer de FAI. Je suis chez Edpnet et je n'ai pas de problème de quota.
Non, pour un serveur ce n'est pas pratique du tout de changer d'IP en fonction du client.
Tu mélange un peu tout. C'est une autre problématique que l'IP source et n'a pas grand chose à faire dans une comparaison IPv4/IPv6.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: fichage
Posté par voxdemonix . Évalué à -6. Dernière modification le 28 septembre 2019 à 21:33.
Ne t'en déplaise, c'est un morceau d'internet. Et si JDownloader a créé une option spécifique pour les connexions en IP dynamique, c'est que de nombreux fournisseurs d'accès internet proposent ce type de connexion à travers le monde.
Donc l'affirmation de départ comme quoi "on ne peut changer d'adresse IPv4 toutes les dix minutes" est bien fausse. Le protocole ne l'interdit pas et plein de gens peuvent l'expérimenter par eux-mêmes.
Je pensais plus tôt aux communications inter-serveurs 😋
Tiens en passant : qui attribue les IPv6 ?
C'est le routeur qui reçoit une plage puis la distribue aux clients réseau; ou bien c'est le FAI qui attribue directement les plages aux clients réseaux du routeur ? (le second cas de figure permettant de faire entrer Big Brother dans le LAN)
Tu parles d'un mécanisme permettant de perturber le tracking via IP. Mais sur smartphone les options sont très très très limitées (sauf éventuellement a passer par des apps rarement gratuite, encore moins libre), hors Tor fait déjà le job de façon plus simple et efficace (y compris en 3-4-5G).
Donc même si l'un empêche pas l'autre, ce mécanisme sera plus réservé aux féru de réseaux ou au dev d'apps.
[^] # Re: fichage
Posté par Sufflope (site web personnel) . Évalué à 5.
Elle est bien vraie. L'existence de situations particulières où via une bidouille tu peux changer d'IP ne rend pas valide ton affirmation comme quoi on peut.
[^] # Re: fichage
Posté par voxdemonix . Évalué à -4. Dernière modification le 28 septembre 2019 à 23:47.
Tant de mauvaise foi… La mouvance habituelle "pro-IPv6 anti-IPv4".
On parle de millions de BBOX qui changent d'IP toutes seules en cas de reboot, coupure réseau ou simplement a la demande.
Loin du cas particulier…
Pourquoi vouloir propager de la fausse information techniques sur linuxfr ?
[^] # Re: fichage
Posté par claudex . Évalué à 6.
Personne ne nie que tu change d'IP quand ta box se reconnecte. Mais ce n'est pas ce qui se passe chez tous les FAI dans le monde. Donc tu ne peux pas dire que c'est une fonctionnalité d'IPv4 (d'ailleurs, tu change aussi de prefix IPv6 chez Belgacom quand tu te reconnecte, personne ne dit que c'est automatique de changer de préfix). Ensuite, tu n'as aucune garantie que l'IP soit différente, même si ça marche la plupart du temps. Enfin, une reconnexion, ça prend tu temps. Si tu fais ça vraiment toutes les dix minutes. Tu ne peux pas regarder un film en streaming. Alors, que c'est bien possible en IPv6.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: fichage
Posté par voxdemonix . Évalué à -5. Dernière modification le 29 septembre 2019 à 13:47.
Pourtant c'est une belle et bien une feature.
Si la majorité des français sont en statique, la majorité des belges sont en dynamique.
Le protocole permet donc les deux types de connexions (se serait chiant pour configurer un LAN avancé si non), avec conditions suivant le FAI (IP dédiée ou partagée, nombre d'IP, etc, etc) .
Changer d'adresse IP volontairement s'accompagne généralement d'une action côté logiciel client :
- que se soit sur Diablo2 ou tu déconnectes ton bot de Battlenet avant de changer d'IP pour échapper au Realm Down
- que se soit sur ton navigateur ou tu quittes l'onglet Uptobox puis tu supprimes cookies, caches etc (CTRL+MAJ+DELETE => all) avant de relancer ton download.
La "transition douce" ne va guère changer grand chose vu que tu es obligé d'attendre que l'IP précédente soit morte pour être sur de ne pas te voir ré-affecter ton identité/token de la précédente à la nouvelle IP.
Ou alors il faut que ton logiciel soit spécifiquement prévu pour (se qui est possible pour un truc comme JDownloader, pour Firefox c'est plus douteux).
Bête question, mais qu'est-ce qui dit qu'en IPv6 il n'y aura pas strictement pareil ? Que les smartphone sur connexion 5G ne se verrons pas attribuer des IPv6 statiques (complète ou préfix) afin de faciliter le tracking chers à nos dictatures ?
[^] # Re: fichage
Posté par Faya . Évalué à 10.
Il te dit que ce n'est pas une feature d'IPv4 . C'est une feature de ton FAI (et ptêt de d'autres FAI) mais IPvXY ce sont des protocoles internet = globaux = la planète. Tu peux pas te baser sur une feature qui marche pour 0,0032 des internautes du globe pour asséner "oui c'est possible".
Sans compter que ta feature demande de couper la connexion… C'est un peu une anti-feature, faut comparer à fonctionnalités égales (changer sans perdre la connexion). C'est comme si on te parlait de l'USB hotplug et que tu répondes "ah mais c'est déjà possible avec mon disque IDE, faut juste que je redémarre la machine".
[^] # Re: fichage
Posté par Kerro . Évalué à 4.
Avec Free ADSL je ne peux pas.
Avec SFR fibre je ne peux pas.
[^] # Re: fichage
Posté par Anonyme . Évalué à 3.
Est-ce que tu peux préciser ? À priori tu peux utiliser une ip différente pour chacune de ses connexions, étant donné que ton fournisseur te fourni le plus souvent un range de plusieurs milliards d'adresses. Il est tout à fait possible de faire en sorte que chaque connexion sur chaque service soit faite depuis une ip différente. Bon si on connaît le subnet qui t'es attribué, on peut en déduire que ces adresses appartiennent à un même abonné, mais pas forcément à un même utilisateur du coup.
[^] # Re: fichage
Posté par ʭ ☯ . Évalué à 3.
Faux. Mon entreprise utilisait des services minitel jusqu'à son extinction!
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: fichage
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 4.
Euh, ce n'est pas parce que France Télécom a fermé les numéros 3615, 3617, etc que le Minitel est mort.
Il faut se connecter par exemple au 01 8421 8115, qui propose plusieurs services listés à la fin de cet article:
https://medium.com/@cq94/dragster-restauration-du-serveur-minitel-pour-macintosh-7ac6b6f3f890
à quand LinuxFR sur Minitel?
[^] # Re: fichage
Posté par ʭ ☯ . Évalué à 2.
Effectivement, je parlais de l'extinction du vénérable 3611, qui nous a obligés à trouver un annuaire sur internet. Mine de rien, nos besoins en débit réseau ont explosé, malgrè un squid en cache.
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
# DHCP
Posté par Damien Thébault . Évalué à 7.
Juste pour pinailler, ce n'est sans doute pas en DHCP que l'adresse IPV6 à été récupérée, mais plutôt en RA (Router Announcement).
[^] # Re: DHCP
Posté par Emeric . Évalué à 6.
en IPv6 les deux modes existent : SLAAC et DHCPv6
[^] # Re: DHCP
Posté par Anonyme . Évalué à 2.
Et les deux ne sont pas mutuellement exclusif, tu peux avoir du RA avec le bit « other configuration » à 1 pour dire au client de faire aussi du DHCPv6.
[^] # Re: DHCP
Posté par claudex . Évalué à 4.
C'est pour ça qu'il dit "sans doute pas", ça m'étonnerait que sa box ait un routeur DHCPv6 et l'utilise par défaut.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
# Grosse erreur sur le DNS...
Posté par Pinaraf . Évalué à 10.
Ce n'est pas du tout ça.
Un serveur DNS, qu'il soit en IPv4 ou en IPv6, va répondre une IPv4 à une requête A et une IPv6 à une requête AAAA, et ton système émet ces requêtes AAAA uniquement parce qu'il a désormais une connectivité IPv6.
Rien ne t'interdit, sur un système sans IPv6, de faire ces requêtes AAAA. Je suis présentement en déplacement professionnel, dans un hôtel sans IPv6, et pourtant:
Donc ton opérateur ne commet pas d'erreur grave en ne fournissant pas de DNS en IPv6.
[^] # Re: Grosse erreur sur le DNS...
Posté par J Avd . Évalué à 5.
Oui je confirme, la manière de se connecter au serveur DNS n'a rien à voir avec les informations reçues, sinon ça signifierait qu'il y a un plan DNS IPv4 et un autre IPv6, on serait pas prêt de passer à IPv6 :'(
Donc la zone example.net contient les enregistrement A (pour les IPv4) et les enregistrement AAAA (pour IPv6), et le serveur répond selon les questions posés et non pas selon le mode de connexion.
#my2cents ^^'7
"Gentoo" is an ancient african word, meaning "Read the F*ckin' Manual". "Gentoo" also means "I am what I am because you all are freaky n3rdz"
# Tout doucement alors
Posté par Kaane . Évalué à 9.
La raison principale pour laquelle les ISP ne passent pas en IPv6 c'est qu'IPv6 marche très très mal. A un moment il va falloir enlever les œillères et admettre ce fait.
IPv6 c'est utile en bordure de réseau - et d'ailleurs assez utilisé en IoT - mais en cœur de réseau ou en architecture de société c'est l'horreur. Chaque équipement, chaque système de virtualisation de réseau, chaque OS a une interprétation subtilement différente des parties de la norme qu'ils ont décidés d'implémenter avec la version en cours.
Et c'est l'horreur absolue.
Alors effectivement ça converge lentement vers un état de l'art qu'on pourrait qualifier de standard, mais principalement à cause des téléphones portables et des tablettes, en mode /64 et le plus souvent mappé en 1:1 ou en 1:n vers des adresses IPv4 en NAT ou en CG-NAT.
Faire de l'overlay non unicast en IPv6 (eVPN/VXLAN) est un casse tête sans fin. Même les constructeurs recommandent vivement de laisser tout ce qui est multicast et broadcast dans l'underlay (ou alors de passer tous les équipements chez eux et d'utiliser leur protocole propriétaire)
En IPv6 on peut certes fusionner facilement deux plages privées de deux entreprises/ISP différents, mais quand il s'agit de fusionner des branches réseaux entières (avec plusieurs plages, du routage, de la propagation DNS dynamique par segment etc.) c'est le mur.
Aujourd'hui IPv6 est très utilisé dans le cas ou Jean-Kevin veut aller consulter FaceBook sur son portable avant de regarder Youtube sur sa tablette, parce que les liens, les routes, les équipements à faire dialoguer sont compris et archi-connus d'avance. Mais pour quasiment tous les autres cas ça demande 50 jours de consulting d'un expert équipement à 2000€/j pour un résultat qui peine à tenir un an.
Le monde avait besoin de namespaces TCP (ce que VXLan fournit plus ou moins) - et on lui a fourni un jouet de laboratoire. Curieusement ça a du mal à prendre.
[^] # Re: Tout doucement alors
Posté par Firwen (site web personnel) . Évalué à 10.
Ça j'ai envie de dire, c'est le cas avec toutes les normes réseaux. Il n'y a que le temps qui amène une convergence. Même en 2019, il n'y a pas un seul endpoint SIP qui implémente la norme complètement.
Tu peux expliquer pourquoi je suis curieux ? Le multicast en V6 est pas si différent du V4.
Tu as un cas concret ?
En théorie en V6, tu es censé balancé le concept de plage privée tout ensemble et de rester sur des plages publiques avec un bon firewall. Donc fusionner des branches réseaux n'est pas censé être un cas courant non ?
[^] # Re: Tout doucement alors
Posté par Kaane . Évalué à 9. Dernière modification le 27 septembre 2019 à 09:32.
Déjà IPv6 a 25 ans. Donc je ne sais pas trop combien de temps il va falloir pour amener la convergence - Mais on ne parle même pas de ça. On parle de moments ou il y avait X RFC pour offrir une fonctionnalité et ou chaque constructeur défendait son choix et son implémentation au détriment de tout le reste. Le seul truc comparable que je vois en SIP c'est quand tu dois t'abonner sur un serveur - dans certains cas il faut faire une demande à vide pour obtenir les infos dont tu as besoin, dans d'autres cas surtout pas. Ça fait longtemps que je n'ai pas eu de soucis avec le protocole SIP ceci dit. (Mais bon j'en fait rarement aussi)
Ça devrait marcher, mais ça marche pas. Tu te creuse la tête, tu cherches - tu apelles Arista/Juniper/Cisco et ils te disent tous "Pour le multicast, n'utilisez pas l'overlay, utilisez l'underlay". Bref j'ai pas vraiment le pourquoi, mais j'ai vu des gens capable de réciter les 12 000 RFC IPv6 de mémoire se gratter la tête et laisser tomber. Gros drops de paquets, problème de routages, effets de bords sur le NDP et j'en passe.
Ben déjà le cas ou ça la branche réseau qui sert pour l'admin des firewalls et des routeurs. Là tu as vraiment pas envie d'utiliser des adresses publiques. Donc tu utilises des adresses privées. Sauf que du coup tu n'as pas le multicast - si tu collectes des timeseries ou que tu fais des audits qui nécessitent du multicast (hint: tous les ISP et tous les data-center publics sont légalement contraints de le faire) tu dois donc créer une deuxième branche. Idem pour les liaisons SAN. Idem si tu vends des liens ou des équipements monitorés à tes clients. Donc tu bricoles et tu fais des choix pour avoir tes segments et tes branches bien isolées. Et quand tu dois interconnecter deux cœurs de réseaux - tu te rends compte que l'admin en face a fait d'autres choix. Pas forcément de mauvais choix d'ailleurs, juste incompatibles. Ça se débloque à la longue - mais si il y une urgence à interconnecter, il va y avoir une solution bricolé en IPv4 sur la plage réseau de la triche AMPRNet. C'est très moche mais ca fait le taf.
[^] # Re: Tout doucement alors
Posté par Firwen (site web personnel) . Évalué à 8.
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".
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.
Ç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.
J'ai du mal à voir pourquoi le multi-cast serait un problème en V6, quand le multi-cast lui même est utilisé pour les fonctionalités coeur du standard, incluant RA et NDP. Ça ressemble plutot à une faute constructeur qui s'est foiré lamentablement en implémentant son overlay maison.
Tu as un cas en tête où utiliser un prefix privé cause un pb pour le multi-cast ? ( en restant dans un scenario où tu ne cast pas au delà du segment )
[^] # Re: Tout doucement alors
Posté par Kaane . É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.
[^] # Re: Tout doucement alors
Posté par Firwen (site web personnel) . Évalué à 6.
Yep, comme en v4 où les prefix de multi-cast sont spécifiques.
Ma question est plus : en quoi avoir un préfix v6 privé t'empèche d'avoir du multi-cast dessus ?
[^] # Re: Tout doucement alors
Posté par Kaane . É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 Renault (site web personnel) . Évalué à 10.
Oui mais non.
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.
C'est une question de volonté c'est tout. L'IPv6 n'apporte rien commercialement parlant (ou presque) et techniquement il n'est pas nécessaire en plus d'opérer une transition coûteuse et difficile à mettre en place.
Mais ceux qui ont eu la volonté de franchir le pas y sont parvenus depuis un moment et sans problèmes d'envergure. Il suffit de voir aussi en France que les expérimentations IPv6 entre les opérateurs n'a pas suivi le même calendrier, certains ont même sauté le pas récemment (Free je crois) en l'activant par défaut et non en option comme ce fut le cas pendant des années. Tandis que d'autres n'en sont qu'à évaluer la technologie encore.
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. On peut comprendre que les opérateurs ne se bougent pas trop.
[^] # Re: Tout doucement alors
Posté par Alex G. . Évalué à 1.
Yep, il faudrait une taxe du gouvernement :-)
Sur les ISP et sur les hébergeurs !
[^] # Re: Tout doucement alors
Posté par Anonyme . Évalué à 3.
Le gain commercial est là : moins de charge et de configuration chiante sur les routeurs (le NAT ça coute cher, la fragmentation est géré par le client, la full-view est moins lourde), pas besoin de maintenir une liste de
DateTime:SrcIP:SrcPort:DstIP:DstPortpour répondre à la justice, etc.[^] # Re: Tout doucement alors
Posté par Kaane . É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 Anonyme . Évalué à 7.
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 ?
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.
[^] # Re: Tout doucement alors
Posté par Kaane . É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 Anonyme . Évalué à 7.
C’est quoi un « fournisseur d’accès backbone » pour toi ? Un transitaire ?
Si c’est ça, dans les 2 cas c’est la même chose, tous les ISP savent s’interconnecter en BGP, c’est toi qui amène IS-IS dans l’équation.
Une fusion d’entreprises c’est toujours une galère, mais je préfère mile fois ajouter « un routeur » (façon de parler) entre deux réseaux IPv6 pour qu’ils communiquent entre eux, plutôt que de devoir renuméroter deux réseaux où les admins ont chacun choisit
10.0.0.0/8.Je comprends toujours pas ce que tu entends pas interconnexion, tu dois pas avoir la même définition que les autres. En tout cas, des AS qui s’interconnectent en IPv6 y en a des centaines (exemple plus ou moins au hasard) :
Seulement les fainéants et les gros qui ne savent/peuvent pas prendre de décisions rapides.
[^] # Re: Tout doucement alors
Posté par Kaane . É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 Anonyme . Évalué à 5.
Si tu n’agrèges pas en bordure, c’est ton problème, pas celui qu’IPv6. C’est la même chose en IPv4.
D’ailleurs, tu parles de « petite plage », mais pour remettre les choses dans leur contexte, la convention actuelle sur les interconnexions entre AS, c’est de ne pas accepter de subnet plus petit que /24 en IPv4 ou /56 en IPv6.
Ces adresses ne sont pas privés.
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, une volonté de faire les choses à ta façon et de surtout pas t’adapter : on parle de peering/transit, tu parles d’IS-IS (comparable à OSPF, donc pas utilisé pour de l’interconnexion entre AS).
Bref, on tourne en rond là.
[^] # Re: Tout doucement alors
Posté par Kaane . É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 Florian Hatat . Évalué à 5.
Je ne sais pas si on peut vraiment compter sur le fait que 44/8 n'est pas routé, Amazon vient d'en acheter une partie : https://www.bortzmeyer.org/vente-reseau-44.html
[^] # Re: Tout doucement alors
Posté par Kaane . É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 Anonyme . Évalué à 4. Dernière modification le 29 septembre 2019 à 14:36.
Tu dis ça, mais ensuite tu dis :
Donc on est pas du tout sur de l'interco L2.
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") j'en ai vu souvent quand je bossais pour un ISP en France. L'ISP en question fournissait aussi ce type de service.
Le cœur de reseau du dit FAI était dual-stack et une partie du backbobe etait transporté sur des interco L2 fourni par un autre operateur.
Ç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.
[^] # Re: Tout doucement alors
Posté par Kaane . É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 benoar . Évalué à 3.
En fait, ce que tu sembles décrire, c'est principalement un problème d'application client : l'adressage est complètement imbriqué « dans » les applications, qui ont besoin d'un routage particulier pour fonctionner correctement, et que tu essayes de recréer.
C'est selon moi un des problèmes principaux qui freine IPv6, et pas tant que ça l'accès réseau. Depuis toujours les devs inventent des softs qui ne respectent pas du tout la séparation du réseau et l'applicatif, les admins les configurent n'importe comment, et du coup tu empiles des LANs dans tous les sens. Forcément, IPv6 ne règle rien à ce problème si les devs continuent de garder la tête dans le sable.
La « solution IPv6 » dans ce cas est de corriger ces applications (bon courage !), et à ce moment-là tu n'aurais plus du tout besoin de tunneler quoi que ce soit, juste de mettre quelques policies IPsec (par exemple). Ça sera le nirvana !
[^] # Re: Tout doucement alors
Posté par Kaane . É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 benoar . Évalué à 2.
Bon, je vois que tu viens du monde de l'industrie, et moi je connais IPv6 par le prisme libriste et académique, mais je vais essayer de comprendre ce que tu racontes (je suis intéressé parce qu'en particulier, les déploiements multicast longue distance réels je n'en ai malheureusement jamais vu en concret) :
Je ne comprends pas ce qui pose problème : le principe des adresses « bien connues » c'est d'avoir une base commune d'identifiant spécifique à chaque application. Pour NDP il en utilise quelque peu pour fonctionner, et tes IGP aussi ; IPv6 « à la base » n'est même pas définit en fonction de ça.
Pour les choix, je t'ai vu citer OSPFv3 et IS-IS pour les IGP, mais c'est à peu près tout. Les méthodes de « virtualisation » de réseau, je ne sais pas exactement de quoi tu parles, ça peut recouper des pratiques qui je pense n'ont pas leur place en IPv6.
En fait, le problèmes commence déjà ici selon l'approche que j'ai évoquée : si tu te dis que tu as forcément besoin d'un eVPN pour commencer, c'est déjà que tu as un problème applicatif sur la manière dont le réseau est imbriqué avec les applications. Du routage simple devrait théoriquement suffire. Je sais bien que c'est la réalité du terrain, il faut faire avec, mais j'essaye de montrer en quoi IPv6 est handicapé par ces pratiques, pour lesquelles il n'est pas mieux fait qu'IPv4 (à part peut-être grâce à sa taille d'adressage, qui permet de faire des bidouilles d'encapsulation/traduction plus facilement ; mais ça reste des bidouilles).
Pourquoi ? Parce qu'elles sont mal scopées à la base ? Problème de configuration alors, comme je l'évoquais au début, qui est le compagnon des problèmes applicatifs.
Je ne sais pas ce qu'est WKM, mais si tu parles de ne pas partager les VLAN je suppose que tu parles de routage pur, et à ce moment-là les méthodes de configuration des deux sites sont complètement indépendantes ! Je ne vois pas où est le problème encore une fois d'avoir ces deux méthodes des deux côté (à part en complexité opérationnelle, mais ça n'est pas la faute d'IPv6).
Si WKM est un mécanisme de Microsoft pour provisionner les machines, je supputes que c'est pour contourner le fait que MS a toujours refusé de faire du provisionning des resolvers DNS par RA avec RDNSS et oblige à passer par DHCPv6, et que l'admin devait avoir la flemme. Toujours pas la faute d'IPv6 !
Là je te suis un peu moins : oui, si tu veux échanger tes tables de routage entre tes deux IGP, ça va être un peu plus galère. Mais bon, à défaut de machine qui pourrait mélanger les deux (je suppose que bird le fait en libre, mais tu as l'air d'être bloqué sur du Cisco/Juniper & co), tu peux toujours n'annoncer qu'un préfixe qui englobe tout de chaque côté, vu que de toutes façons on parle d'un seul lien entre deux sites, non ? Ou faire parler les deux en BGP (déjà fait ici ; ça rajoute un troisième larron, mais ça marche). Je n'ai par contre pas compris la deuxième partie.
Et tout ça c'est de la complication applicative — certes liée au routage — mais qui encore une fois n'est pas plus complexe qu'en IPv4. Tu peux regretter qu'IPv6 n'ai pas unifié tous les IGP, mais il n'a pas de pouvoir magique pour mettre tout le monde d'accord sur l'applicatif ; déjà que standardiser sur un format de paquet commun c'était galère…
Je ne vois pas la nécessité de reconfigurer « tous les équipments » : ceux en bordure, oui, le reste je ne comprends pas. Pour les mécanismes dispos, ça dépend de la politique de ton constructeur, et c'était pareil en v4 (avec moins de maturité pour v6, je l'accorde), 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.
Pourquoi vouloir étendre un L2 ? C'est évident que la complexité va arriver, après.
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. Alors forcément c'est moche. Les mecs qui ont fabriqué ces horreurs n'y bitent rien en réseau, et c'est une tragédie pour des soft soit-disant modernes.
Ce qui me ramène encore une fois à mon point initial : le problème est dans les softs qui sont codés à contrario de l'archi Internet, et qui se comportent donc très mal avec IPv6. C'est là que le bât blesse et qu'il faut améliorer les choses pour qu'IPv6 perce mieux.
[^] # Re: Tout doucement alors
Posté par Kaane . É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 Firwen (site web personnel) . Évalué à 2.
Amazon a toujours traîné les pieds pour IPV6, ils sont d'ailleurs le seul entre Microsoft, Google, Facebook, Amazon and Cloudflare qui ne resolve pas en v6 actuellement.
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.
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
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… Car GAFA… Car wikipedia… car IoT… Car server perso.
[^] # Re: Tout doucement alors
Posté par Kaane . É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 Firwen (site web personnel) . Évalué à 3.
Honnêtement ? Comme tout chez Amazon: le pognon.
Ils n'ont que très peu d’intérêt commercial à le faire tant qu'il n'y a pas une forte demande.
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.
Yep, mais de mon expérience ça tend à converger vers une solution IP + MQTT or CoAP.
Ben tu viens justement de pointer le problème: Tant qu'il y a de la musique, tout le monde dance. Tant qu'il y a des IPv4 encore disponible, personne n'en a rien à foutre sauf quelques avant gardiste.
Et quand le prix des plages v4 va monter exponentiellement, tout le monde va paniquer et tourner en rond.
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".
[^] # Re: Tout doucement alors
Posté par Kaane . É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 Firwen (site web personnel) . Évalué à 2.
Est-ce que c'est étonnant ?
En tant que provider il y a deux scenario :
Je fournis un réseau interne / services internes et je peux rester sur plage privée IPV4, les problèmes viennent quand on commence à interconnecté.
Je fournis un service externe.. Et là le V4 devient obligatoire, car 80% de la planète n'a pas de connectivité IPV6 en endpoint ( telephone, wifi publique, maison ) car la majorité des providers s'en battent les steaks.
Yep, Cf ce que je disais avant : Tout le monde s'en fout. Encore une fois, ça n'a rien d'une contrainte technique.
Et même pas, prends la connectivié smartphone en France. Un bon paquet de provider n'a jamais donné une seul IPv6 publique sur son réseau.
Si tu veux connaitre ma solution pour un déploiement IPV6 global: Que l'Union Européenne foute PV à chaque fournisseur d'accés qui connecte un device à Internet sans une IPv6 publique. Je te parie qu'en moins de 2 ans tous tes problèmes seront magiquement résolus.
[^] # Re: Tout doucement alors
Posté par Kaane . É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 Anonyme . Évalué à 3.
Tu te garde bien de citer Facebook dans ta réponse, mais ils ont un réseau IPv6-only des font-ends jusqu’aux serveurs, et ils ont probablement des problématiques peu commune en terme de topologie et d’interconnexion.
[^] # Re: Tout doucement alors
Posté par Kaane . É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 Anonyme . Évalué à 2.
Quand je bossais pour un FAI en France, on avait livré des chambres étudiantes en dual-stack et on avait au moins 60% du trafic qui sortait en IPv6.
Je doute que des acteurs comme Youtube proposeraient de l’IPv6 si ça dégradait le service pour leurs clients.
[^] # Re: Tout doucement alors
Posté par benoar . Évalué à 2. Dernière modification le 11 octobre 2019 à 11:57.
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 !
Oui, très bien, ce sont des bidouilles qui existent pour palier les manques du protocole IPv4 ! Je peux comprendre que tu aies besoin de temps en temps de bidouiller pour IPv6, mais ça n'est pas fondamentalement nécessaire, bien que pratique. Donc oui, IPv6 tel qu'implémenté aujourd'hui sur un certains nombre de matos n'a pas toutes les bidouilles anti-IP disponibles. Je ne dirais pas que c'est un mal si grave. Le problème est donc dans la pratique IP(v6) de ceux qui exploient (mal) le réseau ; il n'y a effictevement aucun intérêt de faire de l'IPv6 pour ces cas-là…
Tout ça n'est pas du routage, hein : c'est comment bidouiller un faux L2 pour faire de l'encapsulation en plein millieu d'un segment. C'est tout moisi, et IPv6 permet de faire mieux avec du routage simple. Mais je suis d'accord qu'il faut que les applis soit adaptées à ce modèle (pourtant très ancien) pour que ça marche. C'est toujours ma remarque initiale.
Parce que tu ne remets pas en cause tes pratiques issues d'IPv4.
Ça c'est du bullshit qui 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.
La constatation est effectivement pertinente.
La techno n'est par contre pas responsable de ça : si tu veux reproduire en IPv6 les mêmes modèles pourris qu'en IPv4, ça ne sert strictement à rien de vouloir passer à IPv6. L'intérêt de passer à IPv6 se situe dans la compréhension des mécanismes qu'il apporte pour donner ces propriétés de fiabilité, d'uniformisation, de simplicité.
Mais d'un autre côté, c'est quelque-chose qui va contre tes intérêts de spécialiste réseau qui est prêt à monter des archis ultra-complexes pour résoudre les problèmes d'IPv4. Je comprends que tu ne veuilles pas comprendre.
[^] # Re: Tout doucement alors
Posté par Kaane . É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 benoar . Évalué à 2. Dernière modification le 14 octobre 2019 à 13:36.
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 qui sont sur ton réseau ont été conçues pour ne pas utiliser le routage (et marcher uniquement sur un segment L2), c'est à dire ne pas être IP au sens où il a été inventé (que ça soit v4 ou v6, hein). C'est triste, et c'est la réalité je l'admet, mais comme je dis depuis le début, c'est un problème applicatif de faire « transitionner » ces services vers IPv6, pas un problème réseau, car étendre un L2 à petaouchnok n'a pas de sens en IP à la base : c'est une bidouille, qui n'a effectivement à priori pas été reportée sur un certain nombre d'équipements pour IPv6. 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, etc. Reste en IPv4, ça marche très bien comme ça !
Alors pourquoi fais-tu de l'IPv6 ? Tu es masochistes ?
Oui, ça n'a pas de sens, car cela veut dire que tes services/applications sont incrustées dans ton medium Ethernet, que tu essayes péniblement de virtualiser. Ce n'est pas la manière dont Internet a été conçu, qui est basé sur le fait que les applications utilisent des IP (v4 ou v6) comme identifiant sur le réseau, avec éventuellement adresses de groupe multicast (qui semble être ton cas et qui est effectivement un peu plus complexe que l'unicast), et doivent être complètement indépendantes du medium sous-jacent. 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. Par contre, l'architecture d'Internet, basée sur des adresses routées globalement (ce qui est aujourd'hui impossible à appliquer en IPv4 vu la pénurie, même si le principe date bien d'IPv4), t'apporte une solution applicative. Et c'est ça qui bloque la transition IPv6 : les développeurs, les intégrateurs, les éditeurs ne s'y mettent pas. D'où le peu d'intérêt pour un réseau IPv6 derrière, selon moi.
Ta question n'a pas de sens. Je pense réellement que tu ne sais pas ce qu'est le routage : décider de la direction de sortie d'un paquet au format IP, en regardant l'adresse de destination qu'il contient, selon une « table de routage » qui interconnecte des réseaux issus de mediums divers et variés. C'est une couche d'unification qui sert de base aux applications, et d'abstraction aux L2 existants.
Si c'est non-IP, ça sera forcément une bidouille inhérente à la nature des paquets que tu manipules, qui ne tire donc aucun avantage d'IP, et qui n'a donc pas d'intérêt à être convertie en IPv6.
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. Vu que ça n'est pas le cas, tu auras à monter toi un overlay IPv6 avec des routeurs gérant les abonnements et le routage multicast, avec un routage VPN IPv6 multisite « classique ». Pas de config spécifique à cette application dans un seul de tes routeurs/switchs, hein ! C'est ça « l'architecture Internet ». Si ta caméra est IPv4 seulement, c'est un peu triste et il va falloir attaquer les mécanismes de transition IPv4/IPv6 multicast, que je connais mal et que je croyaient aborder au début de cette discussion avec toi. Je pense que c'est faisable, en tous cas beaucoup plus que les bidouilles liées à Ethernet évoquées plus haut.
Pour conclure, je ne dis pas que tes bidouilles ne doivent pas être intégrées dans le « grand plan » de transition à IPv6, hein, juste qu'elles doivent rester dans le monde IPv4, qui sera converti/encapsulé/traduit selon les schémas classiques de transition IPv4/IPv6.
[^] # Re: Tout doucement alors
Posté par benoar . Évalué à 2.
Pardon je sais pas à quoi je pensais en racontant ça, mais ça n'est pas ce que je voulais décrire : une adresse de groupe donnée par le DNS par exemple serait rentrée par ton mec (ou quelqu'un l'aurait provisionné), et ceux qui veulent « capter » la diffusion s'inscrieraient pour le recevoir. Zéro configuration intermédiaire, puisque c'est géré par les routeurs multicast intermédiaires (MP-BGP entre domaines, ce que tu veux en interne, même du statique si tu veux vraiment rentrer des trucs à la main), ou alors par des mécanismes comme RFC 3306 qui permettent de se balader facilement en unicast entre préfixes, vu qu'IPv6 a des adresse assez grandes pour qu'une adresse multicast y encapsule l'adresse d'un /64 !
Pour ton cas d'usage, j'y verrais même plutôt un multicast SSM puisque tu ne t'intéresse qu'au flux d'un seul émetteur. Ton routeur local écoute les diffuseurs / demandes d'abonnement en MLVv2, et gère le routage upstream comme je l'ai dis plus haut.
C'est ça l'architecture Internet.
[^] # Re: Tout doucement alors
Posté par Kaane . É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 barmic 🦦 . Évalué à 1.
Déjà chapeau devoir un débat ici tenir aussi longtemps sans que ce devienne une foire. C'est sincère.
Je suis très très loin de ta compréhension du réseau et je ne cherche absolument pas à remettre en cause ce que tu dis, mais il y a un truc que je n'ai pas compri. Que viennent faire les protocoles non-IP dans le passage (ou non) à IPv6 ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Tout doucement alors
Posté par Kaane . É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 barmic 🦦 . Évalué à 1.
Merci pour ta réponse, je comprends un peu mieux.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Tout doucement alors
Posté par Anonyme . Évalué à 3.
Ça fait juste 15 jours qu’on te dit que c’est faux, c’est pas en le répétant que ça deviendra vrai.
J’ai déjà fait de l’IPv6 sur des lien L2 encapsulé sans soucis.
[^] # Re: Tout doucement alors
Posté par Kaane . É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 Anonyme . Évalué à 3.
C’est pas un débat, ça fait 150 commentaires que Kaane explique qu’il veut interconnecter plusieurs site en L2 et qu’il arrive pas à faire de l’IPv6 par dessus et ça fait 150 commentaires qu’on est plusieurs à lui dire que, si, ça marche et que le problème est probablement ailleurs que dans IPv6.
Ça tourne en rond depuis 15 jours. Ce « débat » n’a aucun intérêt et quelqu’un qui passerait par là dans sa quête de monter un réseau IPv6 n’apprendrait rien du tout.
[^] # Re: Tout doucement alors
Posté par barmic 🦦 . Évalué à 1.
J'ai pas parlé de la qualité de votre débat. Juste que ça n'était pas parti en live… Bon mon intervention à fait capoter la chose.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Tout doucement alors
Posté par benoar . Évalué à 2.
Bon, je vais essayer une dernière fois :
Essaye de t'ouvrir un peu l'esprit, on est là pour essayer de se comprendre…
Te rends-tu comptes que le premier est beaucoup plus complexe que le second ? Parce que ton « L2 étendu » il n'a pas les propriétés simples d'Ethernet, mais c'est un bordel spécifique (tu précises pas au fait : c'est quoi exactement ? je lis que tu fais du SPB, mais sur des liens dédiés, du VXLAN, L2TPv3 ou autre ?) qu'on a tordu pour faire ressembler à Ethernet : pas étonnant que ça s'adapte mal.
La topologie ça ne devrait avoir de sens que physiquement : pourquoi veux-tu « virtualiser » un réseau au-dessus d'IP ? Encore une fois, c'est parce que tes applis sont codées en termes de flux non-IP, et qu'il faut donc faire bouger le réseau pour que ça marche correctement. En philosophie IP, tu changes l'IP dans l'application sans changer la topologie réseau. Au pire si tu peux pas tu peux NATer, mais ça reste plus simple que de « monter une topologie réseau en dynamique ».
J'essaye vraiment de te faire penser au problème plus profond que tu essayes de résoudre. Je ne jette pas par la fenêtre les vieux protocoles, hein, on les encapsule/traduit sur IPv6, mais essaye de voir ce pour quoi est fait IP, plutôt que de te dire « IP est mort, il y a mieux ».
En fait, ton « problème » (de mon point de vue ; tu dois voir strictement l'inverse pour moi) c'est d'avoir choisi Ethernet comme base « d'interconnexion » de réseau, et de vouloir après y placer tout dessus. Moi, je fais l'inverse : IP est ma base, et tout doit passer dessus.
Ethernet est un medium qui doit pouvoir broadcaster/multicaster selon des règles qui sont déjà sûrement complexes dans un L2 physique normal (avec IGMP-snooping & co), mais sur du virtualiser je n'ose même pas imaginer la complexité du bousin. Là-dessus, tu veux y balader un protocole plus puissant, puisque n'utilisant pas de circuit, alors que ton transport sous-jacent est déjà sûrement orienté circuit. Ça ne peut pas bien fonctionner ! Saltzer l'a déjà dis il y a 50 ans avec son « end-to-end argument », essayer de gérer de la complexité dans les couches basses, c'est voué à l'échec. Tous les protocoles à circuit qui sont arrivés après IP se sont vautrés (X.25, ATM, Frame Relay), parce que ça ne marche pas ! Alors aujourd'hui on a encore MPLS qui reste (bon, là ce n'est pas circuit, mais c'est un truc qui veut faire de la dégradation de service — le vrai rôle de la QoS — afin d'avoir de la valeur commerciale) mais l'efficacité d'IP n'est plus à démontrer.
L'ironie du truc, c'est que le transport sous-jacent d'un certain nombre de tes liens « virtualisés », ça doit être… IP ! Moi je te dis enlève ton Ethernet intermédiaire (aujourd'hui tu fais IP-Ethernet-IP) et passe directement à IP.
Je sais bien que tu es orienté par ton activité professionnelle, mais là quand même la mauvaise foi…
Si ces gens doivent « résoudre » les problèmes d'IPv6, c'est parce qu'il veulent le réinventer au-dessus de leur propre techno, afin d'être LA couche d'abstraction sur laquelle se baser. C'est comme ça que marche le commerce, en devenant la couche indispensable. Internet a montré qu'en ayant une couche la moins intéressante, la plus neutre, on est le plus efficace, même si c'est commercialement moins intéressant.
Il n'y a pas de problème avec IPv6 si tu n'essayes pas de le refaire fonctionner au-dessus de ta techno proprio super-méga-top qui n'est en fait pas capable de s'adapter à ses capacités. Tous les protocoles spécifique que tu cites dans ton post finiront pas passer pas dessus IP (et c'est sûrement déjà le cas pour un certain nombre de tes fournisseurs, ça se trouve !), parce que c'est le moyen le moins cher et le plus efficace.
C'est quoi Internet pour toi ? Si c'est interconnecter des L2 par des technos complexes, je pense que tu te méprends. Mais tu n'es pas le seul : j'avais vu un mec de chez Gandi il y a quelques années proposer d'interconnecter tous les L2 privés avec des règles complexes (et du SPB je crois, justement) afin de créer un « grand réseau global »… réinventer Internet, toujours ! (il doit y avoir une citation comme pour Unix sur « ceux qui n'ont pas compris Internet sont condamnés à le réinventer, en moins bien »)
IPv6 est fait pour être LA couche d'interconnexion des réseaux. Tu feras toujours passer autant de trucs divers et variés dessus, mais étendre des L2 et « virtualiser », à terme, ça sera une petite activité spécifique au-dessus d'IP, pour ceux qui ne savent pas tirer avantage de l'architecture IP. Même IPv4 est « virtualisé » aujourd'hui avec l'IETF qui prépare « IPv4 as a Service » au-dessus d'IPv6.
[^] # Re: Tout doucement alors
Posté par Anonyme . Évalué à 7. Dernière modification le 27 septembre 2019 à 20:53.
Les /64 ou /56 (ou peu importe) ne sont que des conventions, en réalité tu fais ce que tu veux (les subnets d’interco en /126 ou /127 c’est courant par exemple). La seul chose que /64 permet c’est l’auto-configuration.
Et si tu voulais dire par là : les opérateurs ne proposent que du /64 ou /56 et pas plus gros, alors c’est que tu parle pas aux bons opérateurs. Par exemple, j’ai plusieurs /48 pour mon infra personnel.
Il y a un avantage pas du tout théorique à IPv6 par rapport à IPv4 (si on met de côté tous les avantages techniques) : n’importe qui peut exister sur internet avec ses ressources propres à moindre frais (devenir LIR auprès du RIPE c’est 2000€ à l’inscription et 1500€/an). Avec IPv4 y a plus rien de dispo et tu dois te payer des allocs au marché gris/noir.
[^] # Re: Tout doucement alors
Posté par Anonyme . Évalué à 5.
Comme en IPvVieux en fait ?
Et pourquoi pas ?
Y a aucune différence, dans tous les cas t’auras probablement un pare-feu devant pour filtrer d’où on peut s’y connecter et de l’authentification.
[^] # Re: Tout doucement alors
Posté par Kaane . É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 claudex . Évalué à 3.
Voire, tu n'annonce/route pas ce préfixe. Comme avec les adresses privée IPv4.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
# Question sans doute bête ...
Posté par Christophe B. (site web personnel) . Évalué à 1. Dernière modification le 27 septembre 2019 à 12:02.
Le routeur gère l'IPV6 mais les pare feux ?
Ne serait ce pas aussi a cause de ces derniers que tout le monde freinent pour l'IPV6
ou globalement il sont tous prêt pour gérer efficacement de l'IPV6 ?
[^] # Re: Question sans doute bête ...
Posté par ʭ ☯ . Évalué à 2.
Bonne remarque, que je lie à la depêche sur Mageia. Mageia avait dans son CCM* un perfeu graphique qui ne gérait que l'IPv4. M'étant mis à IPv6, je savais utiliser la CLI pour le parefeu. Il y a un an , j'ai craqué. Maintenant Mageia 7 a le pare-feu IPv6 dans le CCM.
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Question sans doute bête ...
Posté par Patrick Lamaizière (site web personnel) . Évalué à 1. Dernière modification le 01 octobre 2019 à 15:35.
ça dépend des pare-feux mais normalement oui.
Ceci dit des fois tu as deux versions d'un même outil, une pour l'ipv4 et une pour l'ipv6 (par exemple bird avant version 2). Je ne sais pas trop où en est Linux mais c'était aussi le cas d'iptable / iptable6, je trouve que c'est une hérésie d'avoir deux configs séparées qui oblige à dupliquer les règles avec toutes les erreurs possibles que cela engendre.
Enfin bon chez nous pour pas s'emmerder on a mis un "block inet6" dans pf.conf et ça marche très bien.
les pixels au peuple !
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.