• # Précédemment

    Posté par  (site web personnel) . Évalué à 4 (+1/-0).

    • [^] # Re: Précédemment

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

      C'est abandonné depuis 2021.
      Il est probable que la spécification IPv8 subisse le même sort 😉

      • [^] # Re: Précédemment

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

        C'est parce que ces protocoles ne répondent pas à TOUS les besoins.

        Laissez-moi vous présenter IPv42, LA solution!

      • [^] # Re: Précédemment

        Posté par  (site web personnel, Mastodon) . Évalué à 7 (+4/-0).

        La réaction de l'IETF est de se demander quelle est la solution la plus rapide pour mettre ce document à la poubelle. La procédure normale serait d'attendre son expriration sans rien faire, mais des sites de news commencent à s'emparer du sujet et à raconter n'importe quoi (par exemple que c'est un projet de l'IETF, alors ou'ils l'ont juste reçu et publié).

        • [^] # Re: Précédemment

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

          Un des problèmes est que cet avertissement bien mis en évidence :

          This document is an Internet-Draft (I-D). Anyone may submit an I-D to the IETF. This I-D is not endorsed by the IETF and has no formal standing in the IETF standards process.

          n'est présent que sur les URL du type : https://datatracker.ietf.org/doc/draft-thain-ipv8/ pas sur celle que j'ai donné et que l'on prend un malin plaisir à transmettre.

          Un autre problème est de prendre le temps d'en lire le contenu. Il est assez évident, sans être spécialiste des réseaux, que cela relève de la fumisterie (comme IPv10 😁). Mais je suppose que la mention IETF agit comme argument d'autorité…

  • # L'année de l'IPv6

    Posté par  (site web personnel, Mastodon) . Évalué à 7 (+4/-0).

    Selon les statistiques de Google, l'adoption d'IPv6 est sur le point de dépasser les 50% du traffic reçu par Google cette année.

    La France semble en tête du classement avec 86% des utilisateurs qui requêtent déjà Google en IPv6.

    Est-ce que c'est le bon moment pour se dire qu'il faudrait mettre en place un nouveau protocole?

    • [^] # Re: L'année de l'IPv6

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

      Surtout pour un protocole qui prend bien soin d’être « compatible » IPv4 mais n’a pas un seul mot sur la transition depuis IPv6…

      • [^] # Re: L'année de l'IPv6

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

        Ben là je suppose qu'ils considèrent que l'adoption d'IPv6 est globalement un échec (pas sûr que Google soir la référence absolue du trafic mondial). Alors l'idée est certainement de l'abandonner (ou au moins arrêter de le déployer d'avantage) et passer à IPv8.

        Avec l'inertie de l'industrie, j'ai du mal à voir ça arriver.

        • [^] # Re: L'année de l'IPv6

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

          Google n'est probablement pas la référence mais ça montre tout de même qu'on peut difficilement ignorer ipv6

          https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

          • [^] # Re: L'année de l'IPv6

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

            IPv6 [RFC8200] addressed address exhaustion but did not address management fragmentation. After 25 years of deployment effort IPv6 carries a minority of global internet traffic. The operational cost of the dual-stack transition model, combined with the absence of management improvement, proved commercially unacceptable.

            Apparemment si, on peut, suffit de l'écrire!

          • [^] # Re: L'année de l'IPv6

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

            Oui, d'ailleurs google se fait sans doute tromper par les systèmes qui supportent les deux mais utilisent ipv4 par défaut ou aléatoirement.

    • [^] # Re: L'année de l'IPv6

      Posté par  . Évalué à 2 (+0/-0). Dernière modification le 16 avril 2026 à 21:25.

      Selon les statistiques de Google, l'adoption d'IPv6 est sur le point de dépasser les 50% du traffic reçu par Google cette année.

      Qu'est ce que c'est long……

  • # Et pourquoi pas ?

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

    IPv4 is a proper subset of IPv8.

    J'ai lu que ça tellement que je pense que c'est une bonne idée tellement que je me dis que si ça se trouve ça suffira à le faire adopter.

    Bon, je vais tacher de lire la suite maintenant :)

    En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

    • [^] # Re: Et pourquoi pas ?

      Posté par  (site web personnel, Mastodon) . Évalué à 3 (+1/-0).

      Une bonne idée qui va saper l’avancée de v6 non ?

      “It is seldom that liberty of any kind is lost all at once.” ― David Hume

    • [^] # Re: Et pourquoi pas ?

      Posté par  (site web personnel) . Évalué à 3 (+1/-0). Dernière modification le 16 avril 2026 à 17:08.

      Bon, je vais tacher de lire la suite maintenant :)

      pense à nettoyer ensuite, bon ça te rajoute une tâche :p

      • [^] # Re: Et pourquoi pas ?

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

        tiens pour l'auto-punition je ne me corrige pas.

        notons que les anglo-saxons ont gardé le 's' avec leur task (tout comme forest, hospital…)

        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

        • [^] # Re: Et pourquoi pas ?

          Posté par  (site web personnel, Mastodon) . Évalué à 2 (+0/-0).

          Tu me rappelles que je faisais remarquer l’autre que c’est souvent un « s » gardé en anglais qui s’est masqué en « ^ » en français : tâche, forêt, hôpital…

          “It is seldom that liberty of any kind is lost all at once.” ― David Hume

          • [^] # Re: Et pourquoi pas ?

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

            rien à voir avec l'anglais, qui n'en a qu'un héritage…

            on parle bien de forestiers, d'agents hospitalier… pour tâche, ça vient du latin tasca mais je serais bien en mal de trouver un dérivé similaire ;-)
            https://www.synonyme-du-mot.com/les-articles/pourquoi-laccent-circonflexe-remplace-le-s

            • [^] # Re: Et pourquoi pas ?

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

              oui c'est juste que je pense pas à citer 'task' dans la liste des mots que les Anglois ont conservé du vieux François qu'ils parloeint au Moyen-Âge.

              En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

            • [^] # Re: Et pourquoi pas ?

              Posté par  (site web personnel, Mastodon) . Évalué à 2 (+0/-0).

              Nous disons la même chose (que « l’accent circonflexe remplace ainsi souvent soit un s disparu » en français …et qui réapparait dans d’autres formes)1 Mon interlocuteur étant anglophone il était normal que je lui fasse le parallèle.2


              1. J’aime bien le cas : fenêtre, fenêtrage, fenestrage, défenestration. 

              2. Plus exactement, je lui faisais remarquer que l’accent circonflexe n’était pas si courant et qu’en le rencontrant, la plupart du temps il suffit d’ôter le chapeau et saluer en s devant, et si le mot lui est connu alors c’est le mot original qui leur est parvenu du « vieux » françois et qui peut réapparaitre dans d’autres formes (et j’avais donné l’exemple d’hospitalier). 

              “It is seldom that liberty of any kind is lost all at once.” ― David Hume

    • [^] # Re: Et pourquoi pas ?

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

      Le timing est très mal choisi, ipv6 est déjà une réalité et implémenté ipv8 signifierait gérer une double stack ipv6/ipv8 car ipv8 n'est pas du tout compatible ipv6. Par ailleurs, de ce que j'en lis la spécification met de côté la plupart des évolutions d'ipv6. Ipv6 n'est pas ipv4 avec plus d'addresses. Il y à des gros changement en particulier dans les couches bas niveau.

      Par ailleurs pour ceux qui trouve cool que les ipv4 soient un sous groupe des ipv8, c'est déjà plus ou moins le cas avec ipv6 du moment que l'ont passe par un traducteur (comprendre nat64), une partie de l'addressage ipv6 est explicitement reservé à ça.

      Dans tout les cas, ipv8 ne peut pas fournir de solution magique, la transition ne peut qu'être pénible.

    • [^] # Re: Et pourquoi pas ?

      Posté par  (site web personnel) . Évalué à 5 (+3/-0).

      The IPv8 header is 8 octets longer than the IPv4 header.

      Donc c'est pas un subset au sens « binaire-compatible », juste en termes de fonctionnalité. Une implem de ipv4 qui reçoit un paquet ipv8 ne va pas savoir où aller chercher l'adresse source et destination, parce qu'ils ne sont pas au même endroit en IPv4 et IPv8.

      Je ne vois pas en quoi ça résout le problème de la dual-stack, même si on fait abstraction d'IPv6.

  • # Pourquoi IPv6 est-il aussi compliqué ? (article en Anglais)

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

    Le court article Why is IPv6 so complicated? propose une rétrospective et une argumentation de pourquoi il était inévitable[1] que la transition d'IPv4 à IPv6 soit aussi longue.

    Il y a un chouette tableau au milieu :

    To state this in graphical form, here's a diagram, showing who can talk to who, assuming the simplistic model of IPng with 64 bit addresses:

                  OLD    DUAL   NEW     
                ----------------------
            OLD |  32  |  32  |  XX  |      
                |------|------|------|
           DUAL |  32  |  64  |  64  |
                |------|------|------|
            NEW |  XX  |  64  |  64  |
                ----------------------
    
  • # Meow MRRP

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

    Une draft qui a plus de chances d'être implémentée qu'"IPv8": https://datatracker.ietf.org/doc/draft-meow-mrrp/

    Je pense qu'en voyant le draft IPv8 la plupart des gens ont pensé que le poisson avait un peu en retard.

    • [^] # Re: Meow MRRP

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

      Pour ce document spécifique, le UUoC est fortement recommandé :

      cat <(curl https://www.ietf.org/archive/id/draft-meow-mrrp-00.txt)
      

      C'est par ailleurs LE protocole de choix pour les services en .meow.

Envoyer un commentaire

Suivre le flux des commentaires

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