Cher nal,
Il y a quelques années, on avait parlé (même ici, il me semble) de la loi obligeant les constructeurs à rendre les « équipements terminaux » compatibles IPv6 à partir de 2018. Cette loi, c'est la loi n° 2016-1321 du 7 octobre 2016 « pour une République numérique ». Je retrouve entre autres cette référence sur NextInpact : https://www.nextinpact.com/article/23904/101547-fibre-ipv6-neutralite-du-net-ce-que-loi-numerique-change-aux-telecoms.
Et bien l'article consacrant cette obligation, le n° 42 (!), vient d'être abrogé début décembre dernier par la loi n° 2020-1525 du 7 décembre 2020 d'accélération et de simplification de l'action publique (« ASAP », quel humour).
Cette loi a été dénoncée comme un « fourre-tout » qui dérégule plein de choses (je vous laisse consulter les autres articles, qui parlent de tout sauf de télécommunications), et la ministre Pannier-Runacher a même fait pression « gravement » pour que les députés ne déposent pas de recours contre, selon Mediapart.
Certains me rétorqueront que l'application concrète de cet article n'a peut-être pas vu de percées très visibles, mais sa suppression serait due à la pression des opérateurs et fabricants, selon un cabinet d'avocat que j'ai trouvé en cherchant sur le sujet : https://cms.law/fr/fra/publication/que-prevoit-le-projet-de-loi-sur-la-surtransposition. C'est donc que ça aurait pu être une loi intéressante pour faire pression, mais maintenant c'est trop tard…
Bon, rendez-vous dans 20 ans peut-être pour tenter d'arriver à commencer à faire un peu plus d'IPv6 en pratique…
# Fascinant
Posté par Christophe G. . Évalué à 10.
C'est fascinant cette constante en France d'avoir des bonnes idées / chercheurs / lois et de tout laisser tomber sous la pression des lobbies…
Merci pour ce travail de veille en tout cas, je pense que pas mal de monde est passé à côté de l'info !
Fais-moi plaisir, apporte-moi une clope, un whisky et toi. -- Matmatah
[^] # Re: Fascinant
Posté par benoar . Évalué à 7.
Perso c'était même pas une veille, je suis tombé par hasard dessus, en partant de la fiche Wikipédia de Pannier-Runacher (oui, je creuse loin…).
# Pour ce que ça change...
Posté par dani . Évalué à 1.
Bof, il pourrait y avoir toutes les lois du monde, ça changera rien au fait que dans 20 ans, on sera toujours à faire majoritairement de l'ipv4. La législation ne pourra pas faire grand chose contre le cuisant échec de l'ipv6
[^] # Re: Pour ce que ça change...
Posté par claudex . Évalué à 10.
Pour Google, on est à plus de 50% d'IPv6 en Belgique, en Inde, en Malaysie et en Allemagne, en France et aux USA, on est à presque 45%, je doute qu'il faille attendre 20 ans pour dépasser les 50% https://www.google.fr/ipv6/statistics.html#tab=per-country-ipv6-adoption
« 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: Pour ce que ça change...
Posté par vv222 . Évalué à 7. Dernière modification le 06 février 2021 à 14:01.
Avoir accès à une IPv6 c’est une chose, que les services qui nous intéressent soient joignables sans IPv4 c’est tout autre chose ;)
Google est un bon exemple d’ailleurs, vu qu’il était encore récemment impossible d’envoyer des mails à destination de GMail autrement qu’en forçant le passage par IPv4. Je n’ai pas retesté depuis un moment (j’ai mieux à faire de mon temps), donc je ne sais pas si c’est toujours d’actualité.
[^] # Re: Pour ce que ça change...
Posté par claudex . Évalué à 8.
Ça fait un bout de temps que j'envoie mes mails en IPv6 vers Gmail (j'ai même eu un soucis d'être en spam parce que je n'avais pas de reverse sur mon ipv6). Si tu veux critiquer Google, il y a plutôt GCP qui manque d'ipv6 en interne.
« 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: Pour ce que ça change...
Posté par vv222 . Évalué à 7.
Quand j’ai monté mon serveur mail, j’avais beau avoir un reverse correct sur mon IPv6, aucun mail adressé à une adresse @gmail.com n’arrivait à destination (pas même classé comme spam) jusqu’à ce que je force le passage par IPv4 spécifiquement pour le domaine gmail.com. (si je me fie à la date de dernière modification du fichier de conf, c’était encore un souci en 2017)
De ton retour je comprends que ce n’est plus utile aujourd’hui, je vais peut-être pouvoir arrêter le traitement particulier de ce domaine dans ce cas.
Je ne cherche pas particulièrement à critiquer Google, et de toutes façons je ne sais pas ce qu’est GCP ;P
Ce que je voulais mettre en avant c’est que même les gros sont à la ramasse côté fonctionnement avec IPv6. J’ai cité l’exemple de Google parce que c’en est un qui m’a touché directement, mais je ne doute pas que ce soit similaire chez les autres.
[^] # Re: Pour ce que ça change...
Posté par claudex . Évalué à 4.
Je n'ai plus de log pour vérifier, mais je suis presque sûr que j'envoyais des mails en ipv6 chez gmail en 2016. Donc je ne suis pas sûr que ce soit un problème d'ipv6. Tu as acheté ton préfixe à un spammeur russe ?
« 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: Pour ce que ça change...
Posté par vv222 . Évalué à 3.
Ah ah ah…
C'est une IP parfaitement propre fournie par un FAI associatif local.
Au passage, seul Google a posé ce souci, même Microsoft (!!) n'a pas nécessité de configuration particulière.
Tiens, je me demande si ce n'est pas ce guide que j'avais suivi : https://tanguy.ortolo.eu/blog/article109/google-ipv6-smtp-restrictions
[^] # Re: Pour ce que ça change...
Posté par _kaos_ . Évalué à 6.
Salut,
Tu peux avoir une IP parfaitement propre mais te retrouver dans une RBL quand même, juste parce que le voisin fait n'importe quoi.
Et crois-moi ou pas, c'est vachement plus rapide de bannir un range que traiter IP par IP ;)
Matricule 23415
[^] # Re: Pour ce que ça change...
Posté par Christophe "CHiPs" PETIT (site web personnel) . Évalué à 2.
GCP = Google Cloud Platform => https://fr.wikipedia.org/wiki/Google_Cloud_Platform
[^] # Re: Pour ce que ça change...
Posté par Anonyme . Évalué à 6. Dernière modification le 06 février 2021 à 21:03.
La majorité de mon trafic passe en IPv6 et pour avoir travaillé pour un FAI régional français, dédié aux professionnels, c’est pas seulement vrai pour le trafic grand public.
[^] # Re: Pour ce que ça change...
Posté par vv222 . Évalué à 7. Dernière modification le 07 février 2021 à 02:51.
La quasi-totalité du mien aussi ;)
Mais il reste quand même quelques services massifs coincés en IPv4 aujourd’hui, dont LinuxFR et GitHub. Ou dans le genre moins rigolo, les services en ligne de la CAF et de Pôle Emploi.
[^] # Re: Pour ce que ça change...
Posté par ll0zz (Mastodon) . Évalué à 1.
Et Skype en version gratuite… :o
[^] # Re: Pour ce que ça change...
Posté par Firwen (site web personnel) . Évalué à 10.
Bien au contraire, l’échec de l'IPv6 est surtout législatif et absolument pas technique.
Les différents acteurs en place n'ont aucun intérêt économique au changement IPv4 -> IPv6 : Ni les FAIs, ni les grands Cloud providers / hébergeurs. Pour eux c'est une source de coût, pas de bénéfices. Et ce sont déja les propriétaires des quelques tranches IPv4 existantes.
Le seul moyen réel de forcer réellement l'IPV6 est de manière politique en le forçant à la fois sur les FAIs et sur les hébergeurs.
Car au vu du status quo-actuel, on s'oriente à grande vitesse vers du NAT-Naté-dans-du-NAT. Dans un monde merveilleux où posséder une adresse IP sera un privilège de multi-nationale et d'universitaire.
[^] # Re: Pour ce que ça change...
Posté par dani . Évalué à -4. Dernière modification le 08 février 2021 à 17:45.
Une solution technique qui a besoin de législation pour s'imposer est sans doute une mauvaise solution technique. Soit il y a un vrai besoin d'IPv6, et il devrait se déployer naturellement. Soit il n'y en a pas besoin, donc les acteurs traînent les pieds. Mais dans ce cas, pourquoi la législation devrait forcer son déploiement, si il n'y en a pas besoin ? Non pas qu'il n'y a aucun intérêt à y passer, mais ça semble apporter plus de problèmes que de solutions. L'IPv4 est de toute façon là pour rester. Donc on devra se taper une double stack indéfiniment. Du coup, la solution à la pénurie d'IP qu'est le NAT, aussi imparfaite soit-elle, est elle aussi là pour rester. Déployer l'IPv6 ne fait qu'ajouter toute une montagne de problèmes et de coûts supplémentaires, sans véritable gain (dans la majorité des cas)
[^] # Re: Pour ce que ça change...
Posté par fearan . Évalué à 10.
hum…
Je me demande pourquoi l'ABS est obligatoire, après tout c'est une solution technique imposée par le législatif?
On pourrait aussi en dire de même pour les normes antipollution.
Quant on commence à devoir choisir son FAI en fonction de la possibilité d'avoir une full IP plutôt qu'un tiers ou un quart des ports disponible; ça commence à sentir mauvais.
Non ce n'est pas une solution; c'est un contournement de problème.
Pourquoi ne pas implémenter que l'IPv6 ? C'est géré par les OS, les navigateurs, le réseau, les DNS… Ah je reconnais que c'est plus chiant à taper.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Pour ce que ça change...
Posté par dani . Évalué à -5.
La question est plutôt : pourquoi implémenter l'IPv6. Puisqu'il ne permet pas grand chose de plus que l'IPv4 dans l'énorme majorité des cas. Et est bien plus complexe (et donc coûteux) à mettre en place. Quand à faire de l'IPv6 only, je vois pas qui se permettrait de faire ça. Ça n'a aucun sens de se couper de la plus grosse partie d'Internet. Il faut et faudra pendant encore des décennies de l'IPv4 (que ça soit en dual stack ou via du 6to4)
[^] # Re: Pour ce que ça change...
Posté par Psychofox (Mastodon) . Évalué à 3.
en quoi est-il plus complexe?
[^] # Re: Pour ce que ça change...
Posté par dani . Évalué à 3.
Pratiquement tout, puisque IPv6 ne fait que s'ajouter à l'existant, et qu'il est quand même bien différents de son grand frère. Plus de proxy ARP (ok, il faut voir pour faire du proxy NDP à la place), plus de failover/loadbalancing de lien WAN (à part les gros qui peuvent négocier des échanges BGP de leurs plages avec différents providers), énormément de choix à faire : je fais du statique, du SLAAC, du DHCPv6 ? Mon provider me fournit un /48, ou bien un /56, ou encore un /64. Avec délégation de préfixe ? Comment je redécoupe en réseaux étanches en interne. Et tous ces choix doivent être refait pour s'adapter à chaque situations, parce que les fournisseurs ne font pas tous pareil (l'IPv6 entre OVH et Scaleway par exemple, et pas du tout géré pareil).
Ah oui aussi, je dois dupliquer toutes les règles de pare feu. Et toutes les entrées DNS.
Enfin bref, c'est évident qu'IPv6 est extraordinairement complexe par rapport aux gains apportés maintenant (petit à petit, les gains seront plus importants, et donc le coût baissera, mais on n'y est pas encore …)
[^] # Re: Pour ce que ça change...
Posté par benoar . Évalué à 10.
Les limitations que tu pointes sont pertinentes, même si dans l'absolu il existe des équivalents IPv6 à presque tout (et il existe de meilleures manières de faire que ce que tu cites, qui sont des conceptions « anciennes » et problématiques de voir le réseau). Mais c'est sûr que viser le dual-stack, c'est multiplier par plus que deux la complexité : la vraie bonne solution, qui est poussée par pas mal de monde aujourd'hui, est de faire de l'IPv6 uniquement et de compter sur les technologies de transition pour relier les deux mondes.
Ensuite, la complexité que tu vois sur l'adressage et le routage du réseau, c'est en définitive pour simplifier l'aval du réseau, qui est aujourd'hui un sac de nœud sans nom : regarde la gueule des technos réseau autour d'OpenStack, Docker et k8s, c'est un bordel immonde ; ou alors toutes les technos client pour « traverser » les NAT. Le problème est effectivement que comme le bordel a été « factorisé » dans ces technos et t'es livré inclus de base, on ne le « voit » plus, du coup on ne comprends pas l'intérêt d'avoir un réseau avec un plan d'adressage correct. Mais peut-être qu'un jour certains apprécieront, quand ils auront compris qu'on peut simplifier l'infra et l'applicatif avec une technologie réseau — car c'est le vrai but d'Internet à la base, de faciliter l'interopérabilité d'applications.
Bref, le dual-stack c'est compliqué, c'est sûr, et quand on réalisera qu'on pourra simplifier l'applicatif avec un réseau plus simple, l'IPv6 commencera peut-être à prendre.
[^] # Re: Pour ce que ça change...
Posté par Firwen (site web personnel) . Évalué à 3.
Exactement. Une bonne solution de transition serait de l'IPV6 only coté client avec un NAT64/DNS64 sur la box / passerelle maison pour la transition.
Une des raisons principale pour laquelle ça n'a jamais été fait est que jusqu’à encore récemment, le support IPV6 des smartphones / imprimantes lambda était encore relativement précaire.
[^] # Re: Pour ce que ça change...
Posté par claudex . Évalué à 3.
Non, une des raisons que ça n'a pas été mis en place, c'est qu'il y a pas mal de services qui fonctionnent mal (ou pas) avec du nat64. T-mobile a essayé, ils ont dû trouver une autre solution https://www.internetsociety.org/resources/deploy360/2014/case-study-t-mobile-us-goes-ipv6-only-using-464xlat/
« 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: Pour ce que ça change...
Posté par GG (site web personnel) . Évalué à 3.
Ça date de 2014 quand même.
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: Pour ce que ça change...
Posté par benoar . Évalué à 3.
C'est effectivement une des raisons, et c'est un truc qui nous concerne nous développeurs car c'est parce que les applications sont tellement mal codées que le NAT64 « brut » a eu besoin d'être suppléé par du 464XLAT : dans les deux cas, ce qui circule sur le réseau de l'opérateur (avant d'arriver aux traducteurs) est de l'IPv6 « pur » (c'est le cas pour presque tout le réseau de Free aujourd'hui, je pense), et le « bénéfice » du 464XLAT c'est uniquement d'apporter un adressage local IPv4 (une re-traduction, en gros) afin de plaire aux hôtes qui ont des outils déficients en IPv6, et présenter une API ancienne aux applications qui ne sont pas capables d'utiliser des sockets correctement. En effet, l'API des sockets a été prévue pour que la transition puisse se faire en douceur, mais dans beaucoup de cas les logiciels sont implémentés à la truelle et font de la merde. Le NAT64, qui aurait pu fonctionner si des socket AF_INET6 étaient simplement directement utilisées (pour les softs IPv6-only qui comptent sur la présence de traducteurs sur le réseau) ou si les softs utilisaient correctement getaddrinfo(3), se plante au point qu'on est obligé de simuler un réseau et une API IPv4 pour faire fonctionner correctement les applis : c'est moche.
C'est le deuxième chantier qui est à mon avis encore gigantesque, après les manques des réseaux de certains opérateurs : faire que les applis et les framework arrêtent de réinventer la roue en ajoutant des couches « d'abstraction » qui collent complètement au modèle d'Internet NATé (ce qui est la cas de toutes les technos citées plus haut) et sont inadaptables à IPv6 au point où on en est obligé d'émuler IPv4 pour que ça « marche » (pour les « clients » seulement, car le 464XLAT pour les serveurs, ça n'est pas trop ça, il faudra faire autre chose).
[^] # Re: Pour ce que ça change...
Posté par Anonyme . Évalué à 2.
Je crois pas que Free propose de service IPv6-only et pour le dualstack, ils font du 6rd ou de l’IPv6 native (dépendamment de mode de connexion).
[^] # Re: Pour ce que ça change...
Posté par dani . Évalué à 3.
Pour clarifier mon point de vue : je travaille principalement pour des PME.
Pour des particuliers qui se contentent de se brancher derrière une box, oui, IPv6 n'apporte pas vraiment de contrainte. Tu branches, ça marche et voilà. Pour les grands groupes, ils ont des équipes dédiées, et de bonnes raisons de passer sur IPv6 (saturation des plages RFC1918, pb d'interco de site, coût des équipements se chargeant du NAT, conquêtes de marchés émergents potentiellement en IPv6 uniquement etc.)
Puis au milieu de ça, il y a les structures intermédiaires. Chez qui les équipes techniques sont déjà sous dimensionnées (quand elles existent), les coûts des équipements se chargeant du NAT sont négligeables, il n'y a pas de pb de saturation de plages privées, pas ou peu de pb d'interco de sites, et tous leurs clients peuvent les joindre en IPv4. Bref, dans ces cas là, l'IPv6 n'apporte pas de gain. Ni à court, ni à moyen terme. Pour quelle raison celui qui signe les chèques en ferait un pour ça ?
Un autre problème qui vient avec l'IPv6 pour ces structures : ça les lie fortement à leur opérateur. Et souvent, elles aiment pas ça (et je les comprend). Le jour où tu veux changer d'opérateur, tu dois refaire tout ton plan d'adressage interne. À moins de n'utiliser que les adresses fd00:/8 en interne, mais du coup, ça supprime une partie des avantages de l'IPv6.
Bref, de mon point de vue, c'est surtout pour ces structures intermédiaires (mais nombreuses) que l'IPv6 représente un coût démesuré par rapport aux gains (à peu de choses près nuls)
[^] # Re: Pour ce que ça change...
Posté par claudex . Évalué à 5.
Pas forcément, ton nat peut être stateless et donc facile à implémenter (et à exposer des ports). Et sinon, si tu utilises des IP publiques, tu doit juste changer le préfixe, la renumération est vite fait (mais c'est quand même problématique). Après un PI au RIPE, ça ne coûte pas si cher (mais ce n'est pas négligeable).
« 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: Pour ce que ça change...
Posté par benoar . Évalué à 2.
À ma connaissance il n'y avait plus de PI IPv6 au RIPE depuis un bout de temps, à part pour les IX. Le document de leur politique concernant les PI https://www.ripe.net/publications/docs/ripe-738#IPv6_PI_Assignments n'a pas l'air de le préciser, c'est étrange.
[^] # Re: Pour ce que ça change...
Posté par claudex . Évalué à 3.
Il me semble que c'est le PI pour les ipv4 qui est fini depuis un moment, pas l'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: Pour ce que ça change...
Posté par benoar . Évalué à 1.
C'était pas une question de pénurie, mais une politique : les PI provoquent l'augmentation du nombre de routes de la DFZ et de la désaggrégation, et un des buts d'IPv6 est d'aggréger au maximum, donc ils ont (de mémoire) arrêté d'en faire, même si au début (il y a pas mal de temps quand même) c'était autorisé sans y avoir trop réfléchi histoire de faire « comme en IPv4 » (qui lui a vu l'arrêt des PI avec la pénurie). C'est resté pour les IX qui sont des cas spécifiques et limités, mais c'est tout. Encore une fois, je ne trouve pas de document pour appuyer mes dires.
[^] # Re: Pour ce que ça change...
Posté par Anonyme . Évalué à 2.
Tu te trompes. Il suffit d’être LIR et de prouver que tu es interconnecté avec au moins 2 autres AS pour avoir un PI.
Tu peux même le faire en tant que particulier : https://snapserv.net/services/ripe/.
[^] # Re: Pour ce que ça change...
Posté par benoar . Évalué à 3. Dernière modification le 13 février 2021 à 12:17.
Oui, tu pointes effectivement les bonnes raisons, et je sais bien que les coûts immédiats sont souvent énormes et dissuasifs. Les arguments que je présente sur « dé-complexifier » l'applicatif et la gestion réseau sont des arguments de long terme, et c'est très peu entendu dans ces structures intermédiaires.
Alors ça dépend de comment tu le fais : encore une fois, ça concerne l'applicatif, et c'est un chantier énorme. J'ai souvent recommandé de revenir à une gestion saine du DNS et augmenter son utilisation dans l'applicatif, car c'est le seul moyen de se défaire du couplage des applications avec les adresses : ce dont tu parles, c'est parce que tout le monde hardcode l'adressage et se lie à sa structure, ce qui amène des complications horribles en cas de renumérotation, effectivement. Et tous les devs et tous les frameworks aujourd'hui ont cette tare… alors qu'historiquement, l'utilisation des noms était beaucoup plus développée, et le NAT est venu casser cette dynamique car il rend compliqué l'utilisation des noms. C'est triste, mais c'est un combat nécessaire pour améliorer le réseau de manière générale.
Ensuite, tu peux également choisir de te préparer à l'utilisation d'adresses multiples, avec des préfixes d'origine différentes, ou alors d'adresses changeantes, afin de te défaire de cette dépendance. Ça doit être galère sans DNS, mais c'est une possibilité.
Alors, si tu ne te débrouilles pas trop mal, tu referas les configurations d'adressage de tes équipements, mais tu ne changeras pas la structure, vue que normalement ton nouvel opérateur t'offriras un préfixe assez grand pour faire un adressage similaire au précédent. Tu traduis juste le préfixe, quoi, même si je comprends la galère du changement de conf. Si tu décides de te baser sur les noms comme proposé plus haut, ça peut même être grandement simplifié. Et tu pourras même avoir de l'adressage multiple avec deux opérateurs upstream si tu le veux.
Et il ne faut pas croire que la transition d'opérateur est toujours rose même en IPv4 : tu as l'air de parler de professionnels maîtrisant bien leurs réseau, et j'ai déjà vu des transitions IPv4 où une partie de l'expertise est « avalée » par l'opérateur réseau pour différentes raisons (manque de compétences internes à l'entreprise, offre commerciales préférées par les dirigeants, etc) et les changements nécessaires aux équipements afin de gérer le ré-adressage sont substantielles !
Ça dépend, tu peux aussi essayer de le faire « bien » : tu as en adressage pérenne en ULA (même pas forcément NATé upstream, uniquement pour la communication intra-entreprise), auquel tu peux ajouter des adresse de préfixes globaux de tes FAI pour les besoins d'accès (facile, laisse l'autoconf activée) ou de proposition de service (plus difficile mais réalisable). Comme d'habitude, il faut prendre le réflexe en IPv6 de penser que les technos peuvent s'ajouter, même si gérer la diversité augmenté bien sûr la complexité.
Avoir des ULA par défaut (non routées/NATées upstream) avec un ou des préfixes supplémentaires routés, c'est la configuration adoptée par défaut depuis quelques années par OpenWrt : tu vas me dire que ça n'est pas pour un contexte professionnel, mais je trouve que c'est une très bonne solution même dans ce contexte, qui peut satisfaire les exigences de stabilités comme celles d'atteignabilité globale. Encore une fois, bien sûr que ça amène un peu plus de complexité dans le réseau et la configuration des applications, mais en enlève aussi au niveau des NATs.
Je pense que tu vises juste pour leurs appréhensions, mais je pense personnellement qu'il y a moyen de montrer que la réalité peut être plus simple en choisissant des stratégies de migration adaptées. Je suis par contre d'accord que ces stratégies que je propose ne sont pour l'instant pas souvent déployées, et très peu d'offres professionnelles sont proposées.
[^] # Re: Pour ce que ça change...
Posté par Thomas Debesse (site web personnel) . Évalué à 4.
pour le privilégié.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Pour ce que ça change...
Posté par Faya . Évalué à 5. Dernière modification le 08 février 2021 à 18:57.
Le temps donc le coût ?
Quand je monte une instance chez OVH, l'IPv4 supplémentaire me coûte 2€ et elle est accessible partout et par tous. C'est un peu comme SPF, je n'ai pas eu à m'en préoccuper pendant longtemps vu que mes emails arrivaient avec ou sans. Quand ils ont commencé à se faire jeter, je l'ai paramétré. Si mon service non-IPv6 commence à n'être plus accessible à certains j'aurai une bonne raison d'y passer du temps mais en attendant "Ça juste marche"©. Après la problématique doit-être différente pour ceux qui ont besoin d'un grand nombre d'adresses (comme Free). Ils ont sûrement estimé que couper les IP en 4 coûterait moins cher pour l'instant.
[^] # Re: Pour ce que ça change...
Posté par Anonyme . Évalué à 5.
Ça s’appelle la paresse et on est d’accord que c’est le seul argument qui freine réellement le déploiement d’IPv6.
[^] # Re: Pour ce que ça change...
Posté par dani . Évalué à 5.
On a tous des ressources limitées. Ne pas les allouer à un déploiement d'IPv6 (qui en demande beaucoup, sans apporter d'intérêt immédiat) n'est pas déconnant, et n'a rien à voir avec de la paresse. C'est juste de l'arbitrage.
[^] # Re: Pour ce que ça change...
Posté par Firwen (site web personnel) . Évalué à 7.
J'ai vraiment du mal avec ce genre d'excuses.
90% des services accessibles de nos jours sont via HTTP et derrière CDN type Cloudflare (ou alternative) ou un cluster de reverse proxy.
Même si vous utilisez IPv4 en interne, ajouter le support IPv6 sur la gate du CDN et éditez les 4 entrées DNS qui vont bien c'est histoire de 20s.
Donc oui c'est souvent de la paresse, de la méconnaissance ou (en entreprise) la fuite de responsabilités. Mais l'argument est rarement technique ni financé.
[^] # Re: Pour ce que ça change...
Posté par Faya . Évalué à 3.
C'est 20s si tu sais ce que tu fais. Mes connaissances en infra réseau sont limitées, je n'ai pas d'ingénieur réseau/système et mes clients non plus (d'ailleurs ils ne savent pas ce que c'est et à quoi ça sert) et ce n'est pas du tout mon coeur de métier. Donc à moins d'avoir une bonne raison de m'y mettre je préfère faire autre chose de plus intéressant (me concernant) et plus rentable.
Qu'on ne s'y trompe pas, je suis bien conscient de l'utilité d'ipv6 mais en la matière je suivrai le mouvement. Supporter les 2 stacks là tout de suite dans mon coin on est d'accord que l'intérêt est limité. Suis pas Google.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 7.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Pour ce que ça change...
Posté par dani . Évalué à 0.
C'est bien là le cœur du problème : la transition ne sera jamais terminée.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Pour ce que ça change...
Posté par barmic 🦦 . Évalué à 5.
Il est possible que cela n'arrive jamais ou pas dans le sens que tu imagine. Si le coût global d'IPv4 va dépasser celui d'IPv6, il est possible que le coût par acteur ne dépasse celui d'IPv6.
Sauf s'il est construit à la demande parce que personne ne peut se permettre de se passer d'IPv4.
Par contre oui, si un jour google change le pagerank pour tenir compte d'IPv6 par exemple, ça accélèrera le mouvement, mais c'est pas pour tout de suite.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 8.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Pour ce que ça change...
Posté par fearan . Évalué à 4.
Elle estlà les opérateurs filent des tranches d'IP à leur abonnés si tu veux faire un serveur perso à domicile, faut réclamer une full IP
et il y a aussi quelques risque inhérent à partager son IP :
https://www.numerama.com/magazine/12554-suspecte-a-tort-d-avoir-partage-4500-fichiers-pedophiles-avec-son-adresse-ip.html
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Pour ce que ça change...
Posté par barmic 🦦 . Évalué à 0. Dernière modification le 11 février 2021 à 00:00.
Il le ferra peut être quand ce sera jugé prioritaire et acceptable.
Google ne peut pas se permettre ça. Il ne peux pas se couper de tous les pays très mal déservi qui n'auront pas IPv6. On parle d'une entreprise qui veut être partout pas qui veut se couper d'éventuelles données. Quand ils ont tué IE ça a était fait au dépend des choix de l'entreprise (c'est quelques ingé qui ont choisi de leur propre initiative).
2 ans :D :D :D
La proportion d'IPv4 chute après que des entreprises, dont le business est d'aggréger le maximum de données, arrêtent de le supporter ? J'ai comme un doute.
Oui oui bon les FAI qui sont concerné préfèrent le NAT, mais oui il doit bien exister un monde où les gens passent à IPv6 par manque d'IPv4.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Pour ce que ça change...
Posté par Anonyme . Évalué à 7.
Oui, tu as raison de rire, parce que c’est déjà le cas (de mémoire c’est entre 15 et 30 USD l’adresse actuellement).
Mais même si c’était pas le cas, quand tu te lances et que t’as besoin de ressource, ça fait vraiment pas plaisir de devoir passer par le marché noir pour pouvoir prétendre à une existence sur Internet.
Non, le prix des équipements qui sont capable de gérer du CGN sont peut-être abordable pour Orange, mais beaucoup moins pour un FAI de région.
L’IPv4 c’est aussi un énorme frein à la concurrence.
La réalité est exactement l’inverse de ce que tu écris là, il n’y a pas de pays mal desservi en IPv6, il y a de la place pour tout le monde (plusieurs fois).
Par contre, tous les RIR sont à cours d’IPv4 (sauf AFRINIC, mais ils se font bien piller la gueule, comme si on était encore au temps de la colonisation, donc ça durera pas longtemps).
[^] # Re: Pour ce que ça change...
Posté par barmic 🦦 . Évalué à 2.
2 ans pour que l'IPv6 soit majoritaire ça n'est pas possible.
Là tu parle de la théorie. Celle qui dit aussi qu'IPv6 est majoritaire depuis 15 ans, mais dans les faits il n'y a pas d'IPv6 en Affrique actuellement, il n'y en a pas en Russie, en Amérique latine hors argentine non plus, globalement l'Asie hors Inde/Thaïland et Japon non plus. Tu pense que ce petit monde peut faire le switch en 2 ans ?
Et non la SEO ne poussera pas l'Affrique à passer en IPv6 en 2 ans.
La réalité dont tu parle tu en a une image ici par exemple : https://www.google.com/intl/fr/ipv6/statistics.html?25%#tab=per-country-ipv6-adoption
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Pour ce que ça change...
Posté par claudex . Évalué à 7.
Les FAI ont quand même l'air de bouger tous seuls.
Justement, le cgnat et autres, ça finit par couter, il vaut mieux faire du stateless. Et c'est sans doute ce qui fait bouger les FAI. Et je pense que c'est une des raisons qui va faire migrer vers IPv6, IPv4 finit par coûter. En matériel avec le nat qui demande des ressources et pose certains problèmes. Mais aussi dans l'organisation, quand tu dois faire du nat au sein même de ton réseau (suite à des rachats ou à des extensions), ça te complique pas mal la vie et est source d'erreur et donc d'indisponibilité.
« 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: Pour ce que ça change...
Posté par Firwen (site web personnel) . Évalué à 2.
Tout à fait. Mais les FAIs ne sont pas les seuls dans la balance. Tant que les grands hébergeurs ne seront pas forcé à fournir un adressage V6 sur tout ce qui est publique, les FAIs devront garder leur X niveaux de NATs.
Les hébergeurs ne sont pas les seuls à blâmer d'ailleurs.
L'état de IPV6 dans le monde des "gadgets" IoT et périphériques grands publiques est ridicule alors que ce serait les premiers à en bénéficier.
[^] # Re: Pour ce que ça change...
Posté par claudex . Évalué à 4.
Quand IPv4 marchera moins bien chez les FAI, les hébergeurs passeront à 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: Pour ce que ça change...
Posté par vv222 . Évalué à 9.
Pour ceux qui ont vu Le Magnifique, avec Belmondo, cette situation me fait très fortement penser à l'embrouille entre le plombier et l'électricien ;)
En gros une salle de bains dans un état déplorable doit être retapée, un électricien et un plombier doivent tous les deux passer pour ça. Face à l'ampleur des dégâts, le plombier refuse de bosser tant que le réseau électrique n'est pas remis aux normes… et l'électricien refuse de son côté de toucher à quoi que ce soit tant que l'eau continue à fuir de partout.
# Où est l'intérêt de leur point de vue ?
Posté par Quinane . Évalué à 4.
Qu'en est-il des autres pays ? Car j'ai du mal à comprendre l'intérêt.
Quel serait l'intérêt des opérateurs à avoir des équipements non compatibles IPv6 ? Qui plus est pour les fabricants ?
Les ETTD ne sont-ils pas déjà massivement compatibles IPv6 ? Ou ces députés auraient-ils la naïveté de croire que cette abrogation aurait une quelconque importance ?
Le seul intérêt que je pourrais comprendre est que l'IPv6 permettrait à nouveau le paradigme de la décharge des ETCD et donc potentiellement un peu moins de contrôle pour les états ?
[^] # Re: Où est l'intérêt de leur point de vue ?
Posté par benoar . Évalué à 7.
Je ne pense pas que le but soit de freiner la compatibilité IPv6, mais juste d'éviter de se prendre des procès pour non-conformité. Bon, c'est vrai que du coup, sans punition les opérateurs/fabricants peuvent plus facilement traîner des pieds…
Beaucoup d'articles dans cette loi suppriment des obligations pour les entreprises qui existaient pour faire les choses « bien », ça n'est pas pour qu'elles le fassent forcément moins (mmhh) mais pour qu'on n'ait pas de recours pour les emmerder si elles ne le font pas.
La dérégulation, quoi : le « marché » s'en charge, pas « besoin » de loi pour ça.
[^] # Re: Où est l'intérêt de leur point de vue ?
Posté par Quinane . Évalué à 1.
C'est plus clair, merci. Mais cela concerne surtout du coup les opérateurs (non 5G, d'après barmic ci-dessous), pas les fabricants.
[^] # Re: Où est l'intérêt de leur point de vue ?
Posté par Christophe "CHiPs" PETIT (site web personnel) . Évalué à 5.
Merci de ne pas parler en code : https://fr.wikipedia.org/wiki/%C3%89quipement_terminal_de_circuit_de_donn%C3%A9es
[^] # Re: Où est l'intérêt de leur point de vue ?
Posté par dinomasque . Évalué à -1.
Parler d'ETTD dans une discussion technique sur le protocole IP me paraissais plutôt raisonnable s'agissant d'un acronyme français que l'on apprend généralement tout au début des cursus académiques sur les réseaux.
BeOS le faisait il y a 20 ans !
[^] # Re: Où est l'intérêt de leur point de vue ?
Posté par claudex . Évalué à 6. Dernière modification le 08 février 2021 à 13:55.
Il est possible que ce soit un terme franco-français (voire utilisé uniquement dans le milieu académique).
« 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: Où est l'intérêt de leur point de vue ?
Posté par vv222 . Évalué à 8. Dernière modification le 08 février 2021 à 16:57.
Autrement dit, du jargon.
[^] # Re: Où est l'intérêt de leur point de vue ?
Posté par Christophe "CHiPs" PETIT (site web personnel) . Évalué à 3.
Bonjour,
Avec mes connaissances réseau actuelles, centrées sur IPv4 et essentiellement acquises au fil de l'eau, je m'intéresse à IPv6, mais je ne connais pas le jargon associé, qu'il soit en anglais ou en français.
L'intérêt de ce genre d'articles sur LinuxFR est en bonne partie de "vulgariser" et de comprendre les enjeux, et l'utilisation de ce jargon peut en repousser plus d'un (la barrière technique est déjà assez haute pour que le vocabulaire demande à être explicité).
Sans rancune,
[^] # Re: Où est l'intérêt de leur point de vue ?
Posté par Quinane . Évalué à 2.
Merci d'avoir ajouter le lien Wikipedia.
# Hum ?
Posté par barmic 🦦 . Évalué à 3.
Tes liens expliquent que ça n'est pas très utile (numerama explique que ce qui freine IPv6 c'est pas les terminaux, mais les réseaux) et que c'était difficilement applicable (le lien de l'avocat1).
Te ce qui est des réseaux aujourd'hui l'arcep contraint tout opérateur souhaitant proposer de la 5G a passer en IPv6.
L'avocat tente aussi d'expliquer autre chose par rapport à une autre loi, mais j'ai rien compris et j'ai la flemme de relire 7 dis le passage pour comprendre. ↩
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Documents IPv6 ARCEP
Posté par Cyril Chaboisseau (Mastodon) . Évalué à 4. Dernière modification le 07 février 2021 à 23:06.
…En parlant de l'ARCEP, ils ont mis à jour début décembre 2020 leur rapport sur l'état d'internet en France ainsi que le baromètre annuel de la transition vers IPv6 en France.
C'est vraiment très complet.
Tout est là:
https://www.arcep.fr/la-regulation/grands-dossiers-internet-et-numerique/lipv6.html
[^] # Re: Hum ?
Posté par benoar . Évalué à 4.
Tu aurais le lien de l'article Numérama ? Pour le frein, oui effectivement ce sont surtout les réseaux aujourd'hui, même si ça s'est amélioré comme le signale l'ARCEP dans son compte-rendu cité plus bas.
Pour des raisons un peu moisies dans l'absolu, même si ça se comprend légalement : la France transcrit une directive de manière plus contraignante (l'obligation d'IPv6 n'est pas mentionné au niveau européen), absence d'un calendrier précis de transition, et l'obligation serait « disproportionnée ». Ils parlent de la disproportion de s'adapter au marché français seul, sans parler du fait que l'obligation pour le Brésil est déjà en place depuis plusieurs années, par exemple (avec ses propres limitations, certes).
Tu as des sources là-dessus ? Je ne suis pas du tout un spécialiste 5G, mais des trucs que j'ai glané, la 5G est basiquement très orientée IPv6, voire promouvant l'IPv6-seul. Ça n'est pas pour rien que Huawei est le leader dans les RFC proposant de passer à « l'IPv4-as-a-Service », c'est-à-dire faire des réseaux uniquement IPv6, avec IPv4 « en option » pour ceux qui ont vraiment besoin de l'ancien monde… (basiquement c'est juste des méthodes de découverte de ponts NAT64 ou autre techno de transition).
[^] # Re: Hum ?
Posté par barmic 🦦 . Évalué à 4.
Désolé je voulais dire nextimpact : https://www.nextinpact.com/article/23904/101547-fibre-ipv6-neutralite-du-net-ce-que-loi-numerique-change-aux-telecoms#headlines-container
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# L'explication de Bortzmeyer
Posté par Quinane . Évalué à 10. Dernière modification le 08 février 2021 à 23:23.
Stéphane Bortzmeyer explique la lente adoption de l'IPv6 par l'échec du marché.
Un coût plus grand mais mutualisé est finalement moins grand pour chaque opérateur.
Le pionnier dans l'IPv6 ferait donc une dépense en avance sans réel bénéfice immédiat.
Cela ne répond pas vraiment au sujet initial mais apporte un élément de réponse au reste du fil.
[^] # Re: L'explication de Bortzmeyer
Posté par Faya . Évalué à 6.
Sachant que cet article va sur ses 14 ans… C'est encourageant /s
# Les coûts et gains de IPv6 restent invisibles tant que l'on reste en IPv4 only
Posté par Legrego . Évalué à 0.
Il est difficile de mesurer l'intérêt d'IPv6 tant que le travail n'est pas fait, au moins partiellement, puisque le trafic IPv6 n'est pas visible avant.
J'ai vu des coûts cachés bizarres. Exemple: un serveur cups accessible en IPv4 tout le temps, mais dont on va perdre l'accès en IPv6 (niveau routeur) sur les PC/Linux clients quelques heures après le boot. Pourquoi ? Comment ? Il faut activer IPv6 pour voir le soucis.
Mais Ipv6 a parfois un vrai gain tangible pour les terminaux: contourner la politique de l'admin réseaux, quand l'admin n'a pas le temps de vérifier les problèmes induits par sa politique. Par exemple, sur un réseau universitaire wifi faisant partie de la fédération "eduroam", le filtrage sortant par port est acceptable (déconseillé mais hélas acceptable). Il est donc parfois utilisé ! Mais en plus des ports http/https/ssh/VPNs/emails/FTP, un réseaux "eduroam" doit aussi laisser passer le protocole 41: les tunnels IPv6 (vive les brokers ! cf https://www.eduroam.fr/specif_tecnik). Et hop ! (OK, ça marche aussi avec un VPN externe, mais ce n'est pas la question :-) )
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.