Sondage L'IPv6 prendra quand...

Posté par . Licence CC by-sa.
Tags :
7
22
sept.
2018

Cela fait maintenant 20 ans que l'IPv6 est pour demain, si bien qu'on pourrait se demander si ceux qui pensent toujours que c'est l'avenir ne vivent pas dans le passé. Et vous, pensez-vous qu'il existe encore des obstacles à la propagation d'IPv6 ?

  • les administrateurs seront moins paresseux :
    428
    (13.0 %)
  • tout le monde aura été formé :
    153
    (4.6 %)
  • les vieux barbus auront pris leur retraite :
    209
    (6.3 %)
  • il n'y aura vraiment plus d'adresses IPv4 disponibles :
    1120
    (34.0 %)
  • un standard de NAT sur IPv6 fera consensus :
    351
    (10.7 %)
  • les poules auront des dents :
    1031
    (31.3 %)

Total : 3292 votes

La liste des options proposées est volontairement limitée : tout l'intérêt (ou son absence) de ce type de sondage réside dans le fait de forcer les participants à faire un choix. Les réponses multiples sont interdites pour les mêmes raisons. Il est donc inutile de se plaindre au sujet du faible nombre de réponses proposées, ou de l'impossibilité de choisir plusieurs réponses. 76,78% des sondés estiment que ces sondages sont ineptes.
  • # Pas d'IP failover en v6 chez online, ovh, hetzner...

    Posté par (page perso) . Évalué à 9 (+7/-0).

    Il y a des gens qui ont déjà réussi un ip failover en v6 ? (un truc qui marche dans la seconde, hein, pas un changement d'enregistrement DNS…)

    Adhérer à l'April, ça vous tente ?

  • # il reste des IPv4 disponible ?

    Posté par (page perso) . Évalué à 3 (+3/-0).

    Je me trompe peut-être, mais il me semblait qu'il n'y avait plu d'IPv4 disponible et que tout avait été vendu , non ?
    ( du coup, c'est de la revente au détail d'adresse IP ? )

    Essaie pour vivre sans brider les utilisateurs https://www.indiegogo.com/projects/iwinote

    • [^] # Re: il reste des IPv4 disponible ?

      Posté par (page perso) . Évalué à 10 (+7/-0).

      Le RIPE est arrivé au bout de son dernier /8 mais il reste encore des IP qu'il a récupéré https://www.ripe.net/publications/ipv6-info-centre/about-ipv6/ipv4-exhaustion/ipv4-available-pool

      L'ARIN n'a plus d'IP depuis 2015.

      Les autres RIR sont en train aussi de distribuer les dernières IP.

      Mais il faut savoir que ces IP étaient distribuées gratuitement (ou presque). Et, surtout au début d'IP, certains ont reçu beaucoup plus d'IP qu'ils en ont besoin (ou n'ont plus les mêmes besoins), du coup, ils peuvent les revendre. Pour l'instant, les prix ne sont pas encore très élevé, donc on est loin d'une pénurie.

      ( du coup, c'est de la revente au détail d'adresse IP ? )

      C'est loin d'être du détail, il y a des transactions qui se font sur des /16 (216 IP) alors que le RIPE distribuait des /21 (211 IP).

      « 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: il reste des IPv4 disponible ?

        Posté par (page perso) . Évalué à 2 (+0/-0).

        De toutes façons le nombre d'IPv4 disponibles n'est pas un bloqueur en soi, de nombreux fournisseurs d'accès mettant plusieurs personnes derrière la même IP.

        • [^] # Re: il reste des IPv4 disponible ?

          Posté par (page perso) . Évalué à 5 (+2/-0).

          C'est un problème pour les fournisseurs de service plus que pour les FAI.

          « 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: il reste des IPv4 disponible ?

            Posté par . Évalué à 2 (+0/-0).

            Même pas, la quasi totalité des services ne nécessitent pas d'adresse IP individuelle, sauf peut-être l'email (et encore, c'est devenu tellement coûteux à gérer que les petits fournisseurs externalisent ce service maintenant).

            Membre de l'april, et vous ? http://www.april.org/adherer

            • [^] # Re: il reste des IPv4 disponible ?

              Posté par (page perso) . Évalué à 4 (+1/-0).

              S'ils mutualisent les IP, ils sont obliger de fournir un service de reverse proxy très fiable. Ce qui a un coût non 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: il reste des IPv4 disponible ?

                Posté par . Évalué à 6 (+4/-0).

                Ouais, faut payer ses admins sys, ça a un coût non négligeable.

                • Yth.
              • [^] # Re: il reste des IPv4 disponible ?

                Posté par . Évalué à 2 (+1/-1).

                Ce n'est pas très coûteux, maintenant que les configurations sont gérées par des outils et que tout est virtualisé, fournir un tel service ne coûte rien. Au pire il y a des appliances, basées sur du logiciel libre ou non, qui font ça et se configurent en 3 clics ou appels à l'api.
                Et une fois qu'on a une architecture basée sur du NAT, passer à IPv6 est très coûteux. À mon avis si IPv6 avait gardé les principes d'adresses privées et de NAT d'IPv4, ça ferait longtemps qu'on aurait migré je pense, parce qu'en dehors des coûts de migration il y a plein d'avantages à IPv6.

                Membre de l'april, et vous ? http://www.april.org/adherer

                • [^] # Re: il reste des IPv4 disponible ?

                  Posté par (page perso) . Évalué à 9 (+6/-0).

                  Ce n'est pas très coûteux,

                  C'est beaucoup plus coûteux que de router une IP (surtout avec de la haute disponibilité), sinon les héberbergeurs ne factureraient pas ce service plus cher.

                  Et une fois qu'on a une architecture basée sur du NAT, passer à IPv6 est très coûteux.

                  Je ne vois pas pourquoi. Soit on garde le NAT, soit on fait une stack IPv6 sans NAT, mais dans les deux cas, ça se met en place assez facilement.

                  À mon avis si IPv6 avait gardé les principes d'adresses privées

                  Tu veux parler de fc00::/7 ?

                  Et pour le NAT, ça existe en IPv6, il n'y a pas besoin que ce soit dans le protocole, c'est un détail d'implémentation.

                  « 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: il reste des IPv4 disponible ?

                  Posté par . Évalué à 3 (+1/-0). Dernière modification le 23/10/18 à 18:54.

                  À mon avis si IPv6 avait gardé les principes d'adresses privées et de NAT d'IPv4

                  Moi j'attends l'IPV6 avec un truc un peu mieux que du /64 pour pouvoir virer le NAT chez moi. Donc, non, merci, pas de NAT en IPV6.

  • # Coût du NAT

    Posté par (page perso) . Évalué à 10 (+8/-0).

    Quand le coût du NAT deviendra tellement élevé qu'il n'en vaudra plus la peine. Et je parle aussi des coûts liés au début. Quand une adresse IP est modifiée quatre fois sur le chemin (parce qu'elle passe dans plusieurs tunnel entre plusieurs boîtes qui ont des plans d'adressage qui se chevauchent) ça complique le debug.

    C'est aussi un coût pour les opérateurs qui doivent empiler les cgnat. Ce n'est pas pour rien que les opérateurs GSM américains passent à 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: Coût du NAT

      Posté par (page perso) . Évalué à 9 (+6/-0).

      J'ai oublié aussi de parler des coûts lié à la table de routage qui s'agrandit 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: Coût du NAT

        Posté par . Évalué à 8 (+6/-0).

        ça reste quand même hallucinant que ce protocole vieux de 40 ans (yep, la première publication de TCP/IP, c'est 1978) tienne encore le coup. C'est qu'il est solide le pépé. Je pense qu'il va enterrer les ingé qui l'ont conçu celui-là, voire même ceux qui l'ont déployé partout.

        Faut pas gonfler Gérard Lambert quand il répare sa mobylette.

        • [^] # Re: Coût du NAT

          Posté par (page perso) . Évalué à 4 (+1/-0).

          C'est parce qu'il y a très peu dans le protocole (je ne sais pas si c'était voulu ou un coup de chance). Notamment, il peut fonctionner avec des algorithmes de gestion de la congestion différents.

          Après, c'est aussi un problème. Depuis 20 ans, c'est quasiment impossible d'utiliser autre chose avec pas mal de matériel, donc on se rabat dessus et parfois, on le tord pour qu'on puisse y faire rentrer notre besoin.

          « 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: Coût du NAT

            Posté par . Évalué à 10 (+8/-0).

            Oui, il y a très peu dans le protocole, certes, mais, a mon avis, la raison du succès d'IP tiens dans la mise en application d'une invention géniale, les réseaux informatique à base de datagramme. Le truc qui a fait que ça a pu passer à l’échelle.

            Les réseaux des telco l'époque étaient basé sur du circuit virtuel. ça supposait le maintien de session dans le cœur de réseau et donc, ça ne pouvait pas grossir au delà d'une certaine limite lié à la mémoire des machines et leur capacité de traitement.

            En cassant ce principe, le réseau peu grossir virtuellement de manière infinie. Certes la table de routage grossi, mais ça reste relativement raisonnable. La capacité de traitement des routeurs limite seulement le débit du réseau, mais pas vraiment pas sa taille en terme d'extrémités connectées.

            Faut pas gonfler Gérard Lambert quand il répare sa mobylette.

    • [^] # Re: Coût du NAT

      Posté par (page perso) . Évalué à 6 (+5/-1).

      Quand le coût du NAT deviendra tellement élevé qu'il n'en vaudra plus la peine. Et je parle aussi des coûts liés au début. Quand une adresse IP est modifiée quatre fois sur le chemin (parce qu'elle passe dans plusieurs tunnel entre plusieurs boîtes qui ont des plans d'adressage qui se chevauchent) ça complique le debug.

      J'aimerai être aussi optimiste que toi.

      En pratique, 90% du trafique est maintenant du trafique HTTP / WebSocket ou autre verrue ajouté sur HTTP qui n'a pas de problème avec le NAT traversal. Donc NAT ou pas, c'est pratiquement transparent pour l'utilisateur final…

      Et tant que l'utilisateur final ne sera pas impacté, rien ne changera.

      Encore pire, une bonne partie de ce même trafique est du trafique mobile, venant de téléphones qui ne gère pas ou mal IPv6.

      • [^] # Re: Coût du NAT

        Posté par (page perso) . Évalué à 8 (+5/-0). Dernière modification le 22/09/18 à 11:44.

        Donc NAT ou pas, c'est pratiquement transparent pour l'utilisateur final…

        Si tu lis le mon message, je ne parle pas de problème pour l’utilisateur final mais pour ceux qui gèrent les réseaux. Ce n’est pas le NAT de la box qui pose problème mais l’empilement de CGNAT côté opérateur ou les différents NAT entre différents réseau chez celui qui fournit le service.

        Encore pire, une bonne partie de ce même trafique est du trafique mobile, venant de téléphones qui ne gère pas ou mal IPv6.

        Tu as des preuves sur cette mauvaise gestion de l’IPv6 ? Parce que Akamai voit 71% (en 2016) des utilisateurs Verizon Wireless en Ipv6 (L’article complet).

        « 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: Coût du NAT

          Posté par (page perso) . Évalué à 6 (+4/-0).

          Si tu lis le mon message, je ne parle pas de problème pour l’utilisateur final mais pour ceux qui gèrent les réseaux. Ce n’est pas le NAT de la box qui pose problème mais l’empilement de CGNAT côté opérateur ou les différents NAT entre différents réseau chez celui qui fournit le service.

          J'ai bien compris ton message. Mais je ne suis pas réellement convaincu par cet argument là. L'empilement des NATS est une chose qui est déja en place et dont les opérateurs sont habitués depuis des années. Ils peuvent le rester encore pour beaucoup d'autres.

          Tu as des preuves sur cette mauvaise gestion de l’IPv6 ? Parce que Akamai voit 71% (en 2016) des utilisateurs Verizon Wireless en Ipv6 (L’article complet).

          Je voyage pas mal. Et la quasi intégralité des pays où j'ai été et utiliser le réseau mobile, j'étais en IPv4, peu importe le provider. Verizon est l'exception, non la règle.

          La liste des pays inclue la quasi intégralité de l'Europe, le Canada, Les états Unis, la Chine, le Japon, la Corée…. même situation partout.

          • [^] # Re: Coût du NAT

            Posté par (page perso) . Évalué à 7 (+4/-0). Dernière modification le 22/09/18 à 13:09.

            L'empilement des NATS est une chose qui est déja en place et dont les opérateurs sont habitués depuis des années.

            Alors là, je ne suis pas d’accord. J’ai vu plus d’une fois des problèmes liés au NAT, soit à l’équipement soit parce qu’il y avait des incompréhensions entre équipes qui ne parlaient pas des mêmes range IP. Ça a un coût et plus les réseaux grandissent, plus les NAT s’empilent plus ces erreurs arrivent.

            Je voyage pas mal. Et la quasi intégralité des pays où j'ai été et utiliser le réseau mobile, j'étais en IPv4, peu importe le provider. Verizon est l'exception, non la règle.

            Oui, Verizon ou Sprint sont l’exception. Mais j’ai cité cet exemple parce que tu affirmes que les devices mobiles gèrent mal l’IPv6. Or, comment Verizon arriverait à 76% d’IPv6 si ces devices gèrent mal l'IPv6.

            Je n’ai jamais dit que l’IPv6 était répandue, sinon le sondage ne serait pas là (même si ça arrive, 20% du total des requêtes Google sont 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: Coût du NAT

              Posté par (page perso) . Évalué à 4 (+2/-0).

              Alors là, je ne suis pas d’accord. J’ai vu plus d’une fois des problèmes liés au NAT, soit à l’équipement soit parce qu’il y avait des incompréhensions entre équipes qui ne parlaient pas des mêmes range IP. Ça a un coût et plus les réseaux grandissent, plus les NAT s’empilent plus ces erreurs arrivent.

              Je ne travaille pas directement pour les FAIs, donc tu es certainement plus informé que moi sur ça. J'espère par ailleurs que tu as raison, car la situation sur le mobile ( en Europe ) est déprimante ( et je reste gentille ).

              Le fait que la plupart des logiciels de VoIP, vidéo call sur smartphone sont victime d'une instabilité permanente est par ailleurs souvent lié à ça ….

          • [^] # Re: Coût du NAT

            Posté par . Évalué à 2 (+2/-1). Dernière modification le 22/09/18 à 13:16.

            Je voyage pas mal. Et la quasi intégralité des pays où j'ai été et utiliser le réseau mobile, j'étais en IPv4, peu importe le provider. Verizon est l'exception, non la règle.

            En Belgique tout les utilisateurs de Voo (2ieme FAI) sont en dual IPv4/IPv6. Quant à Proximus/Belgacom (1er FAI), si je ne me trompe, avec la BBOX3 c'est aussi du dual IPv4/IPv6*1 et BBOX2 par contre c'est IPv4.

            *1 par contre pas mal: "proximus ipv6" sur google, second résultat on y lit le service support qui conseil a un client de désactiver IPv6 … :D

            Donation : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat (Bitcoin | Bitcoin Cash)

            • [^] # Re: Coût du NAT

              Posté par (page perso) . Évalué à 5 (+2/-0).

              Il parlait du mobile, pas du fixe.

              « 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

  • # Pour les utilisateurs ordinaires...

    Posté par (page perso) . Évalué à 1 (+2/-2).

    Quand Free les FAIs proposeront de l'IPv6 qui fonctionne?

    Je sais, c'est méchant… Mais en bon citoyen qui milite pour que l'on délaisse les standards obsolètes et que l'on aille de l'avant, j'avais passé la box de mes parents en IPv6. Moralité, après une série de bugs (connexion lente, hôtes non trouvés, etc) j'ai tout repassé en IPv4 (et là, tout marche). D'un autre côté, la box de mon FAI en Suisse est une box militante: même l'IPv4 fonctionne n’importe comment (les redirections d’adresses sont buguées à mort)…

    • [^] # Re: Pour les utilisateurs ordinaires...

      Posté par (page perso) . Évalué à 5 (+4/-0). Dernière modification le 24/09/18 à 17:25.

      L'IPV n'existera que lorsque cela sera transparent pour l'utilisateur final ie celui qui ne sait pas qu'il est en ipv4 et qui s'en fout. C'est donc les FAI qui feront la transition lorsque cela leur plaira. Aujourd'hui je ne pense pas que la pénurie d'adresse soit un problème aigu. Les solutions sont prêtes sur le papier et l'implémentation encore en rodage. Nous sommes toutes proportion gardés dans la même situation que les ptt quand il a fallu passer d'une numérotation de six à 8 puis dix chiffres, sauf que personne ne retient une adresse ip pour envoyer un email. Bref l'ipv6 viendra et personne ne le saura, sauf vous bien sûr.

    • [^] # Jeunisme

      Posté par . Évalué à 3 (+6/-4).

      J'espère que ce message est une blague pour parodier ceux qui croient que toute nouvelle spécification rend les précédentes obsolètes, sinon tu risques de ne pas aimer la suite !

      Il n'y a que 3 façons de rendre un standard obsolète :

      1. l'évolution : le standard est complété pour répondre de façon nouvelle aux nouveaux besoins, en ne modifiant pas du tout ou qu'à la marge la façon dont il répond aux besoins pré-existants. Dans les RFC cela est indiqué clairement par un entête "Obsoletes" dans la RFC du nouveau standard proposé

      2. la concurrence : le standard qui répondait à un besoin a été supplanté par un standard de fait qui écrase le marché, soit à cause d'un monopole (tels les formats de fichiers de Microsoft à une époque), soit à cause d'un consensus des acteurs du marché (essentiellement dans ce qui concerne la sécurité, ou avec des comités de type W3C ou OSI)

      3. l'inusage : le standard a été proposé, personne ne s'y est opposé, mais il n'a jamais pris. Lire les RFC est parfois démoralisant, le nombre de protocoles qu'on déteste pour lesquels des successeurs existent est impressionnant

      Pour l'IPv6, nous ne sommes dans aucun de ces 3 cas (pas de compatibilité v4, aucun intérêt pour les opérateurs existants, et IPv4 écrase l'usage). Jamais on ne peut déclarer que quelque chose est obsolète alors que l'usage montre le contraire, et franchement je crois ici qu'on est dans le cas n°3 : l'IPv6 est déjà obsolète parce qu'inutilisé, ça fait plus de 10 ans que c'est pour demain. Je crois que l'IPv4 aura le même destin que le HTML : il sera déclaré mort par tous ceux qui le contournaient, et au final redeviendra la norme après une simple évolution de l'existant (je parierais sur un augmentation du nombre d'octets des adresses).

      Je ne sais pas si des moins de 20 ans ont déjà utilisé dans leur navigateur du flash, du silverlight ou une jvm… on ne les voit plus ceux qui décrétaient HTML obsolète.

      Membre de l'april, et vous ? http://www.april.org/adherer

      • [^] # Re: Jeunisme

        Posté par (page perso) . Évalué à 10 (+8/-0).

        Si l'IPv6 a de l'intérêt pour les opérateurs. Comme je l'ai dit certains en ont besoin comme Verizon pour le mobile, Microsoft a publié plusieurs articles sur l'intérêt d'IPv6 en datacenter, où 224 IP, ce n'est pas assez, Cloudflare voit du trafic IPv6 venir de Chine, Google a 20% de trafic en IPv6. Le nat a un coût et les opérateurs se mettent à IPv6.

        Dire aujourd'hui qu'IPv6 est inutilisé, c'est faut. Il est loin d'être majoritaire, mais il est clairement présent.

        « 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

  • # Il manque la réponse la plus plausible de toutes

    Posté par . Évalué à 10 (+19/-1).

    • Apple sortira un iBidule uniquement compatible avec le protocole magique et révolutionnaire iPV6; là vous verrez tous les opérateurs telco se sortir les doigts du cul sur les infra et les éditeurs de sites web se dépêcher de souscrire l'option "IPV6 Professionnal compatible +" chez leurs hébergeurs

    BeOS le faisait il y a 15 ans !

  • # Déjà pris

    Posté par (page perso) . Évalué à 5 (+3/-1).

    L'IPv6 a déjà pris : tous les opérateurs s'y sont mis, et son adoption augmente régulièrement.
    La courbe Google montre qu'on obtient 5% de plus tous les 2 ans, on arrive à 25% du traffic. Donc dans 10 ans on serait à 50% du traffic, c'est pas mal pour un changement non indispensable, non?

    ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

    • [^] # Re: Déjà pris

      Posté par . Évalué à 1 (+3/-4).

      5% par an depuis 10 ans me semble au contraire montrer une absence d'adoption phénoménale, pour ce qui devait être le standard avant la fin des années 2000. Encore aujourd'hui, bien que je travaille avec un paquet de grosses sociétés chez un opérateur, je n'ai à ce jour qu'un seul client qui a demandé l'IPv6, j'ai même obtenu que dans les bonnes pratique de déploiement de serveurs on désactive ce truc inutile. Certes toute l'infra réseau est prête (comme chez tous les opérateurs, ils n'ont rien contre IPv6 sur le principe, ils attendent la demande), parce qu'on a cru à une époque que ça deviendrait le standard (sauf moi peut-être qui n'y crois plus depuis 10 ans), mais il n'y a ni demande, ni besoin… aucune raison de l'utiliser.

      Membre de l'april, et vous ? http://www.april.org/adherer

      • [^] # Re: Déjà pris

        Posté par (page perso) . Évalué à 5 (+2/-0).

        ncore aujourd'hui, bien que je travaille avec un paquet de grosses sociétés chez un opérateur

        Une grosse société classique, ça n'a pas beaucoup de serveur ni de service exposés et un plan d'adressage existant, c'est loin d'être le client idéal, ce sont d'ailleurs ceux qui migrent en dernier sur IPv6. Le seul avantage, c'est d'éviter de l'empilement de NAT lors de tunnel VPN avec d'autres sociétés.

        « 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: Déjà pris

      Posté par . Évalué à 5 (+5/-0). Dernière modification le 25/09/18 à 16:41.

      Pas tous certains ce sont retrouvé avec des IPv4 mutualisés. Ils se sont rendu compte en faisant un serveur chez eux et que ça ne pointait pas chez alors que l'IP était la bonne.

  • # LinuxFr

    Posté par . Évalué à 10 (+31/-1). Dernière modification le 24/09/18 à 20:43.

    [x] quand LinuxFr.org sera en IPv6

    Le basculement vers IPv6 ne peut se faire que si les grands acteurs du net tels que LinuxFr.org décident de faire le pas.

  • # IUT

    Posté par . Évalué à 7 (+7/-0).

    Quand on arrêtera d'enseigner aux étudiants (futurs informaticiens) que l'ipv6 a plein d'avantages mais qu'on ne peut pas vraiment leur faire tester parce que… euh le pôle informatique à autre chose à faire que de le mettre en place.

    Depuis mon bureau dans une grande université française, je ne peux pas accéder à mes machines à la maison (l'interface pour le port-forwarding de mon FAI n'est pas terrible (et je hais les interfaces web), et c'est pourtant peut-être le meilleur).

    • [^] # Re: IUT

      Posté par (page perso) . Évalué à 10 (+10/-0).

      T'as aucune excuse, le seul rôle du pôle informatique est d'apprendre à l'étudiant à les contourner !!! (et lire man ssh, redirection de port et le réseau par effet de bord)

      La première chose apprise en IUT a été de monter un tunnel SSH sur un proxy à la maison pour avoir de l'internet dans les salles de classes quand c'était bloqué.

      L'admin s'en est rendu compte et a laissé en place son PALC (proxy à la con) contournable, pour lui si on arrive à le contourner c'est qu'on a appris ce qu'il fallait apprendre de réseau dans l'IUT.

      • [^] # Re: IUT

        Posté par . Évalué à 6 (+6/-0).

        Bon admin, pas changer admin !

        bépo powered

  • # Mutualisation des IPv4

    Posté par . Évalué à -8 (+0/-9). Dernière modification le 25/09/18 à 16:36.

    L'IPv6 est mal fichu et l'IPv4 peut très bien rester longtemps si on mutualise les IP.

    Franchement il aurait pas pu simplement faire un nouveau protocole identique mais en augmentant le nombre max de chaque groupe (au lieu de 255.255.255.255 max aller jusqu'à 1024.1024.1024.1024) en plus ç’aurait été rétrocompatible, mais pourquoi faire simple quand on peut faire compliqué.

    • [^] # Re: Mutualisation des IPv4

      Posté par (page perso) . Évalué à 10 (+10/-0).

      1023.1023.1023.1023 pour ton quartet de dectet (enfin truc de 10 bits) j'imagine. Maintenant si même le créateur de l'IPv4-et-un-plus-je-vous-le-mets-quand-même commence par se gourrer, je ne sais pas si c'est un bon signe pour l'avenir de ce « nouveau protocole identique » prometteur.

      • [^] # Re: Mutualisation des IPv4

        Posté par (page perso) . Évalué à 9 (+9/-0).

        C'est bien connu les headers des paquets IP contiennent l'adresse sous forme d'une chaine de caractères de longueur 15 donc on peut pas aller au delà de "999.999.999.999" (bon après on peut commencer à utiliser des lettres mais ça serait moins beau j'imagine). La question c'est pourquoi se limiter à 255 du coup … Ils sont vraiment stupides ces gars qui bossent sur IPv6 !

        • [^] # Re: Mutualisation des IPv4

          Posté par (page perso) . Évalué à 6 (+4/-0). Dernière modification le 25/09/18 à 19:27.

          Ah non, ils ont pensé aux lettres ! Ils ont juste oublié les trois quarts de l’alphabet (sans compter les lettres hors alphabet anglais).

          « 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: Mutualisation des IPv4

            Posté par (page perso) . Évalué à 4 (+3/-1).

            Avec des adresses IPv4 en unicode c'est tout de suite plus vaste : on va jusqu'à FFFFF.FFFFF.FFFFF.FFFFF, soit 10 octets. IPv6 est enterré sans rien changer au protocole \o/

      • [^] # Re: Mutualisation des IPv4

        Posté par (page perso) . Évalué à 8 (+6/-0).

        Maintenant si même le créateur de l'IPv4-et-un-plus-je-vous-le-mets-quand-même commence par se gourrer, je ne sais pas si c'est un bon signe pour l'avenir de ce « nouveau protocole identique » prometteur.

        Y a un long résumé à ce sujet chez bortzmeyer : http://www.bortzmeyer.org/ipv6-compatibilite.html

        Adhérer à l'April, ça vous tente ?

    • [^] # Re: Mutualisation des IPv4

      Posté par (page perso) . Évalué à 10 (+7/-0).

      en plus ç’aurait été rétrocompatible

      Non. Le matériel est fait pour lire et stocker des champs de bits à des emplacements spécifiques. Si tu sors des 32 bits des adresses IP, tu casse toute la compatibilité.

      « 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

  • # C'est plus facile de retenir une ipv4 de tête qu'une ipv6...

    Posté par (page perso) . Évalué à 0 (+3/-3).

    Et quand on passe sa journée à jongler entre les machines ça aide.

    D'ailleurs, je n'ai pas compris le 128bits par rapport au 64bits.

    En 64bits, on aurait eu 4 paquets hexa de 4 caractères, ABCD:EF01:2345:6789, ce qui reste jouable pour la mémoire humaine et on aurait eu ~1019 adresses, ~4 milliards de fois plus que maintenant.
    Les adresses en ipv4 seraient restées en 0000:0000:127.0.0.1.

    Mais non, il fallait aussi mettre l'adresse MAC de 48 bits (qu'on peut modifier à la volée sur pratiquement tous les OS) et on a eu 16 bits de sous domaine, donc 64bits qui ont une faible valeur ajoutée pour le routage, car la carte réseau réagit sur l'IP, et là son adresse MAC fait partie de l'IP.
    Du coup, changement de carte réseau (si on reste dans la norme), soit l'IP du serveur change, soit on force l'adresse MAC de la carte réseau.
    Et donc, je ne vois pas la faciliter de maintenance d'un réseau.

    Surtout que l'argument utilisé est de pouvoir identifier exactement le device connecté (adresse MAC).
    Et là je pose 2 questions:
    - qui a déjà vu un SI ou tous les équipements étaient consolidés dans un référentiel unique et "A JOUR" ? (vu que c'est bien pour ça qu'on se paye 64 bits de plus dans la gueule).
    - quid du changement de matériel (carte réseau en panne) et du spoofing "MAC" ?

    Du coup, pour moi ipv6, c'est 2 blocs de 64bits (table de routage sur 64 bits sur les backbones), le premier pour déterminer l'organisation qui gère les 64bits suivants (16bits + 48 bits d'adresse MAC, table de routage sur 64bits interne)
    et du coup, c'est impossible de retenir une adresse ipv6 peuplée (sans pouvoir utiliser les raccourcis ":" ::TOTO:TITI::…)
    exemple: A9B7:EF01:85DE:123F:456:0A56:BC07:FE48
    64bits : A9B7:EF01:85DE:123F
    ipv4: 133.222.18.63 (85DE:123F)

    Et tous ceux qui vont dire "et le DNS", avez vous jamais travaillé dans une entreprise ou la moindre demande "d'évolution/changement" est empilée jusqu'à ce que la pile d'incidents "prioritaire" (refaire la conf de la cafetière connecté de la direction ) soit épuisé, et vous vous trouvez pendant quelques jours à +oo à utiliser des IP numériques en attendant.

    Et je pense que c'est un facteur carrément non négligeable de la "paresse des administrateurs" (ainsi que plus l'adresse IP est grande, plus grande est l'erreur de saisie).

    • [^] # Re: C'est plus facile de retenir une ipv4 de tête qu'une ipv6...

      Posté par . Évalué à 1 (+1/-1). Dernière modification le 26/09/18 à 14:53.

      Du coup, changement de carte réseau (si on reste dans la norme), soit l'IP du serveur change, soit on force l'adresse MAC de la carte réseau.
      Et donc, je ne vois pas la faciliter de maintenance d'un réseau.

      Si tu as fixé l'IP via MAC et que tu changes de carte réseau en IPv4, tu devras aussi aller rectifier le tir.
      Si tu utilises une conf côté client pour fixer l'IP (se que je trouve pas propre mais passons), tu peux très bien rajouter un chtit script qui change l'adresse MAC pour qu'elle soit identique après changement de carte. (note que toutes les cartes ne sont pas compatible)

      quid du changement de matériel (carte réseau en panne) et du spoofing "MAC" ?

      La même chose qu'en IPv4?

      Et tous ceux qui vont dire "et le DNS", avez vous jamais travaillé dans une entreprise ou la moindre demande "d'évolution/changement" est empilée jusqu'à ce que la pile d'incidents "prioritaire" (refaire la conf de la cafetière connecté de la direction ) soit épuisé, et vous vous trouvez pendant quelques jours à +oo à utiliser des IP numériques en attendant.

      Est-ce la faute à IPv6?
      Quand tu fais dans l'auto-hébergement, tu es confrontés à tout cela tout les jours ^ ^
      Ma solution magique de secours à préconiser serait simplement de mettre en place un VPN avec ip statique à l'intérieur. Ainsi quand il y a du mouvement dans ton network, cela n'impacte pas le VPN. (et comme c'est lui qui fixe l'ip, les machines peuvent changer d'ip lan/wan ou de carte réseau )

      Le défaut d'IPv6 c'est l'installation de machine : genre tu branches une foscam sur ton réseau. Déjà t'es pas sur qu'elle soit compatible IPv6, mais en prime tu vas galérer pour trouver son adresse IP pour pouvoir la paramétrer via sa webui (sauf si tu as accès au routeur, se qui n'est pas toujours le cas dans les collocs etc).

      Donation : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat (Bitcoin | Bitcoin Cash)

      • [^] # Re: C'est plus facile de retenir une ipv4 de tête qu'une ipv6...

        Posté par (page perso) . Évalué à 1 (+2/-1).

        Si tu as fixé l'IP via MAC et que tu changes de carte réseau en IPv4, tu devras aussi aller rectifier le tir.

        Sauf que c'est un choix de l'administrateur pour ipv4 d'associer une IP avec une adresse MAC dans sa gestion/configuration du réseau et des règles de flux.

        Dans la norme ipv6, les derniers 48bits sont l'adresse MAC.
        Donc 48 bits de "perdus" (c'est déjà un espace 65536 plus grand que l'espace des adresses ipv4).

        Pour l'instant, rien de ce que j'ai pu lire donnait un avantage tellement important à ipv6 (en dehors de dépasser 232 adresses) pour accepter qu'il ne soit pas "human friendly".

        Et je continue de penser que 264 adresses auraient été largement suffisant (ça fait ~2.63 milliards d'adresse par humain vivant sur terre, je sais bien que l'IoT est à la mode, mais il y avait largement la marge).

        • [^] # Re: C'est plus facile de retenir une ipv4 de tête qu'une ipv6...

          Posté par (page perso) . Évalué à 6 (+3/-0).

          Tu ne tiens pas compte que la table de routage. Avoir un préfixe énorme permet de garder une table de routage petite.

          « 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: C'est plus facile de retenir une ipv4 de tête qu'une ipv6...

            Posté par (page perso) . Évalué à -2 (+0/-2).

            Je ne comprend pas bien cette remarque.
            32bits seront toujours une table de routage plus petite que 128bits, à moins que je ne comprenne rien à l'arithmétique.
            Même en ayant un préfixe de 80bits au niveau d'une organisation, l'organisation se contente des 48bits d'adresse MAC pour la table de routage interne, 48 > 32 a priori.

            • [^] # Re: C'est plus facile de retenir une ipv4 de tête qu'une ipv6...

              Posté par (page perso) . Évalué à 6 (+3/-0).

              Je parle de la table de routage d’Internet (pour les autres, c’est souvent beaucoup plus petit). Alors, oui, en théorie, en ne tenant pas compte des usages actuels, on pourrait monter à 232 routes en IPv4 et beaucoup en IPv6 mais ce n’est pas du tout le cas.

              Le problème, en IPv4, c’est que comme l’espace d’adressage est très réduit, on a des routes pour des tout petits préfixes (/22, /23, /24). Par qu’on a des préfixes qu’on découpe pour que tout le monde ait un petit morceau. Et qu’il n’est pas possible facilement d’agréger cela.

              En IPv6, les morceaux sont beaucoup plus grands, par défaut, le RIPE distribue des /56, ce qui fait 256 réseaux de 264 hosts. Ça laisse de la marge pour s’organiser. Mais il est possible d’avoir des allocations plus grandes. Orange a par exemple un /19, ce qui fait 245 réseaux de 264 hosts. Autant dire qu’il y a de quoi s’organiser. En pratique, cela veut dire que des entreprises qui ont des dizaines de routes publiées sur Internet en IPv4 en auront moins de 5 en IPv6.

              En pratique donc, il y a plus de 730 000 routes publiées en IPv4 et moins de 60 000 en IPv6 (soit douze fois moins). Même si effectivement, l’IPv6 est moins déployé, beaucoup de monde annonce déjà des réseaux IPv6 sans qu’ils soient déployés et les réseaux déployés couvrent potentiellement beaucoup plus de machines potentielles que les réseaux IPv4 actuellement publiés.

              « 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: C'est plus facile de retenir une ipv4 de tête qu'une ipv6...

                Posté par (page perso) . Évalué à -1 (+1/-2).

                Donc pour les administrateurs réseaux en amont de ces "grossistes", ça sera plus simple car effectivement, il délègue l'effort de routage à ces "grossistes".

                D'après l'exemple d'orange, Orange va avoir 2109 adresses à sa disposition (277 [~=1,5x1023] fois plus que toutes les adresses théoriques ipv4 !)
                même 245 est 8192 fois plus gros que toutes les adresses théoriques ipv4.

                ça veut dire que la densité des adresses va être très faible, donc une majorité des adresses ne sera jamais affectés, par contre on va se taper la manipulation des 16 octets (ou 32 caractères ascii en hexa [0-9A-F] + les 7 séparateurs ":")°°°.

                En s'étalant comme ça, on va avoir les mêmes problèmes que pour ipv4 ou des larges plages d'adresses ont été réservés au début, et maintenant, on bouche les trous https://xkcd.com/195/ (2006) et plus récent https://bl.ocks.org/vasturiano/8aceecba58f115c81853879a691fd94f

                On voit bien que dans ipv6,
                - le protocole prévoit 2 plages 64 bits, une première plage en 264 bits pour le "routage général" vers des organisations, et 264 bits pour le routage interne de ladites organisation, c'est un routage en 2 temps.
                - pouvoir identifier chaque serveur/poste client avec une IP unique (suppression du NAT et faciliter les statistiques/filtrage/sécurité en ayant du point à point "pur" et relié à l'origine du protocole à l'adresse MAC).

                Pour le premier point, je n'ai rien contre le fait de sortir d'ipv4, mais 264 adresses (16 caractères ascii en hexa [0-9A-F] + les 3 séparateurs ":" ) auraient permis d'avoir un espace d'adressage très large (selon la philosophie ipv6, 2 plages de 32 bits, ou autre répartition exemple : 40+24) et in fine 2128 adresses, ça reste "overkill" °--°

                Pour le second point, pour l'exemple typique d'un site web, qui mettrait un serveur web (apache/java/php/.net/votre techno préférée…) directement exposé sur le web (y compris sa vraie IP), sans passer par des couches réseaux (comme un firewall/reverse-proxy/IDS/..).
                Donc en pratique, une organisation qui aurait 264 adresses internes (la partie droite des 128bits) , c'est "overkill" aussi, puisqu'elle va forcément mettre une translation entre les adresses internes et externes.

                °°° Parce qu'il faut bien saisir cette pu*@n d'adresse à rallonge un jour ou l'autre dans le SI (au moins dans le DNS et dans la conf réseau du serveur, et si le réseau est un peu plus évolué, les plages d'adresses/ip/hostname dans le firewall, reverse-proxy, …) et il y aura des erreurs de saisies (cf. le point suivant sur les administrateurs "lambda" a qui ça va casser les pieds).

                °--° IPV6 a sûrement des avantages pour les "backbones" qui ont a priori de meilleurs administrateurs réseaux que l'entreprise lambda, mais ça va bien emmerder tous les administrateurs réseaux "lambda" au quotidien.

                • [^] # Re: C'est plus facile de retenir une ipv4 de tête qu'une ipv6...

                  Posté par (page perso) . Évalué à 4 (+1/-0).

                  En s'étalant comme ça, on va avoir les mêmes problèmes que pour ipv4

                  Non, justement, comme on a plus de place, et qu'on prévoit justement que chacun puisse s'étendre. On a justement pas le même problème qu'en IPv4.

                  le protocole prévoit 2 plages 64 bits, une première plage en 264 bits pour le "routage général" vers des organisations, et 264 bits pour le routage interne de ladites organisation, c'est un routage en 2 temps.

                  Je ne comprends pas du tout ce que tu veux dire. Le principe du routage reste le même qu'en IPv4. Il y a des adresses de réseau et une partie identifiant l'hôte.

                  Pour le second point, pour l'exemple typique d'un site web, qui mettrait un serveur web (apache/java/php/.net/votre techno préférée…) directement exposé sur le web (y compris sa vraie IP), sans passer par des couches réseaux (comme un firewall/reverse-proxy/IDS/..).
                  Donc en pratique, une organisation qui aurait 264 adresses internes (la partie droite des 128bits) , c'est "overkill" aussi, puisqu'elle va forcément mettre une translation entre les adresses internes et externes.

                  Je ne comprends pas ce que tu veux dire, il n'y a pas de firewall mais il y a une translation d'adresse (pourquoi ?). Mais sinon, ce n'est pas parce que ce n'est pas accessible directement d'Internet que ça ne doit pas être globalement adressé. Et même les machines qui ne sont pas des serveurs web ont besoins de se connecter au net (pour récupérer ses mises à jour par exemple).

                  Parce qu'il faut bien saisir cette pu*@n d'adresse à rallonge un jour ou l'autre dans le SI (

                  Bof, on automatise de plus en plus, c'est le serveur DHCP qui pousse cela ou le serveur qui va pusher ses informations.

                  il y aura des erreurs de saisies

                  On s'en sort bien avec les clefs SSH bien plus longue.

                  « 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: C'est plus facile de retenir une ipv4 de tête qu'une ipv6...

                    Posté par (page perso) . Évalué à 1 (+1/-0).

                    De toute manière, c'est l'ipv6 la nouvelle norme, on va faire avec, hein, pas le choix de toute maniére :-)

                    C'est le côté "TINA" de la justification des 128bits qui me fait soulever un sourcil.

                    C'est un peu de l'uchronie, "et si on avait choisit du 64bits à l'époque (ce qui est déja 4 milliard de sous réseaux "ipv4")", et bien je pense qu'on aurait pas été à l'étroit, et on aurait quand même eu une densité d'adresse faible.
                    C'est de "l'esthétisme technique" pour une forme plus compacte et qui aurait rempli les mêmes fonctions.
                    Mais bon, ce n'est pas la mode de notre société, qui est "bigger", better", …" ("bigger" et "better", faut voir, ça dépend des cas, ça ne marche pas toujours) dés que ça ne va pas "assez vite".

                    Bref, je ne trouve pas que ipv6 était la solution la plus "élégante" au problème du manque d'adresse IP.

                    Les clefs SSH, et bien c'est bien le bordel à gérer quand tu n'as que quelques certificats et le nombre d'intervention dessus se compte maximum sur les doigts d'une main dans l'année (pas d'automatismes acquis, je me doutes qu'il y a des postes ou on bouffe assez régulièrement pour que ça deviennent des automatismes).
                    Mais bon là aussi, c'est la norme, on fait avec.

              • [^] # Re: C'est plus facile de retenir une ipv4 de tête qu'une ipv6...

                Posté par (page perso) . Évalué à 2 (+0/-0). Dernière modification le 28/09/18 à 19:52.

                par défaut, le RIPE distribue des /56

                C’est /32 par défaut : https://www.ripe.net/publications/docs/ripe-655#minimum_allocation

    • [^] # Re: C'est plus facile de retenir une ipv4 de tête qu'une ipv6...

      Posté par (page perso) . Évalué à 4 (+2/-0).

      C'est toujours d'actualité cette histoire d'adresse MAC dans les IPv6 ? Il me semblait que ça avait été modifié pour des raisons de vie privée. Je n'arrive pas à retrouver de source (j'ai pas cherché longtemps, je suis au boulot) mais les IPv6 de mes 2 cartes réseaux n'ont pas de lien immédiat avec leurs adresse MAC (Linux 4.15).

      La connaissance libre : https://zestedesavoir.com

    • [^] # Re: C'est plus facile de retenir une ipv4 de tête qu'une ipv6...

      Posté par . Évalué à 2 (+0/-0).

      qui a déjà vu un SI ou tous les équipements étaient consolidés dans un référentiel unique et "A JOUR" ?

      Moi (mais tout dépend de ce que tu entends par "à jour").

      • [^] # Re: C'est plus facile de retenir une ipv4 de tête qu'une ipv6...

        Posté par (page perso) . Évalué à 0 (+0/-0).

        Un référentiel ou tu peux avoir a peu près confiance (modulo création/migration/destruction des quelques jours précédents dans une file d'attente de saisie manuelle/automatique) que toutes tes machines "actives" sont listées et que leur fonction est décrite (ça peut être un pauvre "serveur courriel" comme description).

        Pas un référentiel a trou, parce qu'il n'est plus utilisé depuis sa mise en place ou sporadiquement avec des mise à jour à trou.

        • [^] # Re: C'est plus facile de retenir une ipv4 de tête qu'une ipv6...

          Posté par . Évalué à 4 (+2/-0). Dernière modification le 28/09/18 à 13:21.

          Donc, je confirme, j'ai vu ça. Tout était indiqué dans le référentiel (No de série du serveur, des disques, etc …). Je ne sais pas si ils allaient jusqu'à référencer les addresses MAC, mais s'il avait fallu le faire ça n'aurait pas posé gros problèmes pour mettre à jour l'appli.

          A partir du moment ou tu bases tes produits d'infrastructure sur cette base de données, tu es obligé d'avoir un référentiel à jour (pas de supervision ni de branchement réseau si ta machine est pas dans le référentiel).

  • # Il manque une réponse

    Posté par . Évalué à 1 (+0/-0).

    Juste après que linuxfr soit accessible en IPv6 :-p

  • # Amusant

    Posté par . Évalué à 3 (+1/-0).

    Amusant, le fait que la seconde meilleure réponse soit celle concernant les poules montre que personne n'y croit plus vraiment.

    Il y a quelques années j'étais optimiste, je me disais que les FAI et les pro allaient forcément devoir s'y mettre car on avait une date précise de fin des IPv4. Et finalement rien n'a changé, on peut toujours avoir une IPv4 publique avec un vps à 2,99HT/mois autrement dit une misère. Et puis dans toutes les infra pro où j'ai pu fourrer mon nez, l'IPv6 semble très loin tant les réseaux sont pensés pour l'IPv4 avec du nat et srcnat à gogo. Il y a aussi le réflex de pas mal de windowsiens de désactivation immédiate de l'IPv6 soi disant parce que ça évite des problèmes de réseau.

    Bref je n'y crois plus vraiment. Il faudrait un grand cataclysme pour motiver les différents acteurs.

    • [^] # Re: Amusant

      Posté par (page perso) . Évalué à 4 (+1/-0).

      Comme je l'ai déjà dis dans les autres commentaires, je ne suis pas d'accord. Oui, il est encore facile d'avoir des IPv4 mais le coût monte (il suffit de voir les prix de revente). Bien sûr, c'est loin d'être impayable mais c'est beaucoup plus cher qu'il y a quelques années. Et les réseaux grossissent, ce qui fait qu'IPv4 a un coût d'exploitation (en matériel et en jour.homme) notamment lié à l'empilement de NAT.

      Ensuite, IPv6 se répand, ça n'arrive pas du jour au lendemanin mais ça progresse petit à petit. Google a 20% de ses requêtes en IPv6. Verizon aux États-Unis a mis les mobiles en IPv6. Il y a aussi un FAI indien qui s'est mis à l'IPv6 (et ça fait un paquet d'utilisateur). En Belgique, les principaux FAI distribuent des IPv6 à tout le monde.

      « 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

  • # Quand ça sera implémenté complètement dans linux?

    Posté par . Évalué à 2 (+0/-0).

    Zut quoi, je faisais quelques recherches pour essayer d'avoir un protocole sécurisé ultra-léger (pour de l'embarqué) entre un client et plusieurs serveurs qui se connaissent à l'install, je tombe sur la mention qu'IPsec est implémenté dans le header d'IPv6 (qui est juste 2 fois plus gros qu'IPv4: on passe de 20 octets minimum à 40 octets minimum, quand c'est pour trimballer 10 pauvres octets à la minute, ça fait cher de l'overhead quand même).
    Je me dis «tiens, ben si ça me vire l'épine de la sécurité du pied, je veux bien voir si ça vaut le coup d'envoyer chier la compat IPv4!», je lis la manpage et….

    IPSec support for EH and AH headers is missing

    hé merde…. ceci dit, avec la change, le

    This man page is not complete

    qui suit implique peut-être qu'en fait, si?

    Bon, je vais quand même aller me renseigner sur le sujet, après tout, je ne sais même pas encore ce que sont ces machins, et puis, même si linux n'implémente pas ça, p'tet que d'autres systèmes le font, eux (ça serait l'occase de changer de noyal).

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.