Journal L'apocalypse arrive

Posté par  . Licence CC By‑SA.
Étiquettes :
38
2
fév.
2014

Cher journal,

Je t'écris peu mais ce n'est pas vraiment un bookmark. Au fosdem, où je suis pour le moment, ils ont mis le WiFi par défaut en IPv6 uniquement (avec DNS64 (donc des DNS menteurs) et NAT64 pour avoir quand même un minimum fonctionnel). Et c'est là qu'on se rend compte qu'on se rend compte que rien ne fonctionne si on n'a pas d'IPv4 (Android ne considère pas qu'il a un réseau s'il ne reçoit pas d'IPv4, ça a l'air de marcher avec iOS mais pas à tous les coup, opensuse ne veut pas non plus se connecter (la version en cours de développement fonctionne normalement).

Ils l'avaient annoncé, le but de la manœuvre était que les gens découvrent les problèmes (ça, c'est fait) et les corrige (ça, on verra l'année prochaine).

Et pour ceux qui n'ont pas lu ma première phrase, une nURL

  • # Et ailleurs ?

    Posté par  (site web personnel) . Évalué à 6.

    Par pure curiosité, as-tu des informations sur la prise en charge des réseaux IPv6 only pour les OS de Microsoft (Windows et Windows Phone), OS X ou d'autres distrib GNU/Linux ? (Voire pourquoi pas *BSD). Ça peut être intéressant d'avoir une vision un peu plus globale sur tout ce qui existe.

    • [^] # Re: Et ailleurs ?

      Posté par  . Évalué à 4.

      Je n'ai rien d'autre comme infos, j'ai mis toutes celles que j'avais entendues.

      « 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: Et ailleurs ?

      Posté par  . Évalué à 2.

      je pense que c'est surtout les applications qui ont des problèmes. Je me connecte souvent en ipv6 only avec du linux et du BSD sans problème. J'imagine que c'est les outils similaires à NetworkManager et compagnie qui créent des problèmes au dessus.

  • # Précisions ?

    Posté par  . Évalué à 4.

    DNS64 ? NAT64 ?
    De quoi s'agit-il ?
    Je pensais (en fait non, je ne pense pas, j'en suis sûr) qu'en IPv6 tout le monde avait une IP publique et donc pas besoin de NAT.

    • [^] # Re: Précisions ?

      Posté par  . Évalué à 4.

      64 pour conversion d'adresse IPv6 en IPv4.

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

    • [^] # Re: Précisions ?

      Posté par  (site web personnel) . Évalué à 4.

      DNS64 ? NAT64 ?
      De quoi s'agit-il ?

      DNS64, NAT64

      (oui, je sais, elle est facile…)

      Je pensais (en fait non, je ne pense pas, j'en suis sûr) qu'en IPv6 tout le monde avait une IP publique et donc pas besoin de NAT.

      tu es sûr qu'il est absolument interdit d'avoir un réseau privé et donc des adresses privées en IPv6? Comment techniquement on me l'interdit? De ce que je connais, IPv6 facilite l'usage de tout public (grande plage d'adresses, comme au début d'IPv4), mais n'interdit pas les adresses privées (comme on avait de l'IPv4 privé bien avant un manque d'adresses), donc l'admin fait un peu ce qu'il veut et donc "tout le monde a une adresse IPv6 publique" n'est pas garanti. Et puis bon, il faut bien accéder à des machines IPv4-only donc faire quand même une translation quelque part pour ces machines, sinon ça fait pas foule de machines joignables. Enfin, c'est ce que j'imagine.

      • [^] # Re: Précisions ?

        Posté par  . Évalué à 2.

        tu es sûr qu'il est absolument interdit d'avoir un réseau privé et donc des adresses privées en IPv6? Comment techniquement on me l'interdit? De ce que je connais, IPv6 facilite l'usage de tout public (grande plage d'adresses, comme au début d'IPv4), mais n'interdit pas les adresses privées (comme on avait de l'IPv4 privé bien avant un manque d'adresses), donc l'admin fait un peu ce qu'il veut et donc "tout le monde a une adresse IPv6 publique" n'est pas garanti. Et puis bon, il faut bien accéder à des machines IPv4-only donc faire quand même une translation quelque part pour ces machines, sinon ça fait pas foule de machines joignables. Enfin, c'est ce que j'imagine.

        Il n'a pas dit que c'etait interdit, il a dit qu'il n'y en avait pas besoin et il a raison.

        • [^] # Re: Précisions ?

          Posté par  (site web personnel) . Évalué à -10. Dernière modification le 03 février 2014 à 09:40.

          Il n'a pas dit que c'etait interdit,

          Il a dit, je cite "en IPv6 tout le monde avait une IP publique", je demande comment on fait pour m'interdire d'avoir une IP privée (seule manière d'avoir tout en IP publique). Ou alors je te demande comment on fait pour que en IPv6 tout le monde avait une IP publique sans interdire à moi d'avoir une adresse IP privée (pas un peu contradictoire?)

          il a dit qu'il n'y en avait pas besoin

          Je demande à ce que tu me cite l'endroit où il dit ça…

          et il a raison.

          J'ai donné des raisons qui disent le contraire (genre j'ai un réseau IPv6 privé, genre je souhaite accédé à un réseau IPv4)

          Bref, ça fait beaucoup d'affirmations sans démonstration alors que c'est loin d'être évident, la je vois juste une utilisation théorique qui exclut plein de possibilités… Si c'est si "clean", je dmeande à ce que vous m'expliquiez comment vous faites pour que ce soit aussi clean dans la vraie vie. Si il a raison et que tu confirmes, tu pourras me dire comment il a raison.

          • [^] # Re: Précisions ?

            Posté par  . Évalué à 10.

            Aujourd'hui, au pays des moules, Zenitram n'a toujours pas compris la différence entre un langage informatique et un langage naturel…

            • [^] # Re: Précisions ?

              Posté par  (site web personnel) . Évalué à -10. Dernière modification le 03 février 2014 à 10:03.

              Ou alors je fais juste remarquer que l'usage classique n'est pas l'usage de tout le monde.
              Tu ne verras alors aucun problème à ce que je dise que les gens utilisent soit Windows soit Mac OS X, car c'est qu'aux pays des moules qu'il y quelques utilisateurs de Linux, c'est le langage naturel voyons (tant pis pour les minorités, quelle idée de ne pas exclure les linuxiens quand on fournis un service…). Ou qu'en dehors des moules, c'est IPv4 et c'est tout (c'est évident voyons, qu'elle idée de faire IPv6 c'est que pour les moules)

              Bref, tout ce que je voulais dire c'est qu'il y a des cas où c'est faux, et les oublier est ne pas comprendre la raison de pas mal de protocoles, et se limiter dans la réflexion est s'interdire de réfléchir à des évolution, rester dans le passé. "en IPv6 tout le monde a une IP publique" est faux, c'est tout, que ça te plaise ou pas, et ce n'est pas de la théorie de moule (exemple : une entreprise ne veut pas d'IP publiques pour ses machines internes pour des question de sécurité ou par habitude avec IPv4).

              • [^] # Re: Précisions ?

                Posté par  (site web personnel) . Évalué à 10. Dernière modification le 03 février 2014 à 10:50.

                exemple : une entreprise ne veut pas d'IP publiques pour ses machines internes pour des question de sécurité ou par habitude avec IPv4.

                Dans ce cas je dirai à cette entreprise de changer d'admin system, car c'est un gland qui ne connaît pas la différence entre NAT et pare-feu.

                l'IPv6 autorise bien evidemment d'avoir des plages privées, ceci dit, avoir un préfix complet IPv6 est aussi simple qu'avoir une seul et unique IPV4.

                Faire du NAT en IPv6, c'est cumuler à la fois les problèmes de IPV6 et les problèmes de IPV4.
                Autrement dit, celui qui fait du NAT ( je parle de vrai NAT, pas de NAT64 ) IPV6 merite avant tout un pied au cul.

                • [^] # Re: Précisions ?

                  Posté par  . Évalué à 6.

                  Mon ami vous faîtes une erreur grotesque,

                  Vous confondez allègrement NAT et NAPT.

                  Le NAT en IPv6 garde une utilité certaine dans le cadre des renumérotations dû à un changement d'opérateur et du fait de la difficulté de disposer d'un bloc d'adresses PI (provider independant). Il n'est pas dérangeant d'avoir une IP privée unique masquée par une adresse IP publique unique elle aussi.

                  Les problèmes d'IPv4 proviennent de l'utilisation massive du NAPT qui masque des adresses IP privées derrière une seule et unique adresse IP publique.

                  Le NAT n'est pas mort, il est très utile et permet la mise à l'échelle. C'est le NAPT le frangin démoniaque, lui doit mourir (en souffrant de préférence). Son grand frère le CGNAT marque l'apocalypse.

                  Le NAT64 reste un mal nécessaire, mais c'est vrai qu'Androïd devrait se dépêcher de trouver une solution au problème évoqué dans le journal.

                  "Gentoo" is an ancient african word, meaning "Read the F*ckin' Manual". "Gentoo" also means "I am what I am because you all are freaky n3rdz"

                  • [^] # Re: Précisions ?

                    Posté par  (site web personnel) . Évalué à 5. Dernière modification le 03 février 2014 à 12:42.

                    Mon ami vous faîtes une erreur grotesque,

                    Vous confondez allègrement NAT et NAPT.

                    Pas vraiment, tu joues juste avec une notion sémantique.
                    Et ce qui est assez drôle en soit c'est que tes deux liens pointent exactement vers la même page wikipedia.

                    Le lien correcte serait cette page ( http://en.wikipedia.org/wiki/Network_Address_and_Port_Translation ) avec l'explication sur la notion entre NAT "one to one" et NAPT.
                    L'utilisation du terme "NAT" est communément admise pour NAPT, qui est l'usage le plus courant en IPV4. Le NAT "one to one" ou "à pool" étant insuffisant depuis longtemps en IPV4. Mais peu importe.

                    Le problème de la renumérotation, comme tu le signales, peut être corriger simplement avec DHCPv6 et une gestion un tant soit peut correcte des préfixes alloués.

                    Et il est fortement dérangeant d'avoir une IP privée unique masquée par une adresse IP publique unique elle aussi.
                    Car ça ne fait que réintroduire (partiellement certes) les problèmes du NAT inhérent à l'utilisation de protocoles "sales" ( type FTP, SIP ou tout protocole qui transmet une adresse client pour un bénéfice plus que douteux.

                    Ce genre d'opération est juste une honte d'un point de vue réseau, un bricolage réintroduit, mis en place par des admins qui, une fois de plus, méritent un coup de pied au cul.

                    • [^] # Re: Précisions ?

                      Posté par  . Évalué à 3.

                      Le problème de la renumérotation, comme tu le signales, peut être corriger simplement avec DHCPv6 et une gestion un tant soit peut correcte des préfixes alloués.

                      Qui t'as dit que je voulais m'embêter avec DHCPv6 alors que l'autoconfiguration stateless est si simple à mettre en œuvre ?

                      Car ça ne fait que réintroduire (partiellement certes) les problèmes du NAT inhérent à l'utilisation de protocoles "sales" ( type FTP, SIP ou tout protocole qui transmet une adresse client

                      Protocoles "sales"? Mieux vaudrait donc les nettoyer …

                      Je reconnais que c'est un problème, mais dans la balance des entreprises seul l'usage donnera la bonne pratique. Et tu conviendra qu'il n'y a pas foule pour se jeter au bain.

                      Je dis juste que le NAT garde un intérêt — discutable comme toute technologie de concession — alors que le NAPT doit disparaître. C'est mal barré avec l'arrivée du CGNAT qui d'après un certain Stéphane Richard serait viable commercialement jusqu'à 60$ l'adresse IPv4 publique.

                      "Gentoo" is an ancient african word, meaning "Read the F*ckin' Manual". "Gentoo" also means "I am what I am because you all are freaky n3rdz"

                      • [^] # Re: Précisions ?

                        Posté par  (site web personnel) . Évalué à 4. Dernière modification le 03 février 2014 à 14:06.

                        Qui t'as dit que je voulais m'embêter avec DHCPv6 alors que l'autoconfiguration stateless est si simple à mettre en œuvre ?

                        ça peut aussi être fait avec une configuration stateless, c'est juste un peu plus casse gueule. Mais il faut savoir ce qu'on veut.
                        De manière général ( et c'est le cas où je travaille ), les entreprises préfèrent DHCPv6 car ça permet
                        - configuration centralisée.
                        - traçage plus aisée
                        - éviter quelques problèmes potentiels de spoofing liés aux mechanismes du RA.
                        - éviter les problèmes de trash-cache quand des clients sont configurés comme des pingres et spam des messages RD toutes les 500 ms.

                        Mais c'est une question de choix, effectivement. Je ne cautionne ni l'un ni l'autre, libre à chacun.

                        Protocoles "sales"? Mieux vaudrait donc les nettoyer …

                        Va dire ça aux inventeurs du petit dernier "WebRTC", qui est pratiquement aussi "sale" que les autres :)
                        Sont considérés comme "sales" un peu prés tout protocole tentant de faire du pair à paire ceci dit.

                        Je reconnais que c'est un problème, mais dans la balance des entreprises seul l'usage donnera la bonne pratique. Et tu conviendra qu'il n'y a pas foule pour se jeter au bain.

                        Entièrement d'accord, d'où ma motivation pour botter le cul des administrateurs systèmes :D

                        Je dis juste que le NAT garde un intérêt — discutable comme toute technologie de concession — alors que le NAPT doit disparaître. C'est mal barré avec l'arrivée du CGNAT qui d'après un certain Stéphane Richard serait viable commercialement jusqu'à 60$ l'adresse IPv4 publique.

                        Entièrement d'accord également, excepté que je suis bien moins tolérant avec le simple NAT "one to one" que toi. Pour tout un tas de raison que j'ai exposé dans le post parallèle au tiens.

                        • [^] # Re: Précisions ?

                          Posté par  . Évalué à 2.

                          • éviter quelques problèmes potentiels de spoofing liés aux mechanismes du RA.

                          Hum ? Il dit qu'il ne voit pas le rapport. En DHCPv6, il y a toujours les RA (indispensables pour trouver la route par défaut). Et si c'est pour parler de spoofer les adresses des clients, je ne vois pas en quoi c'est plus difficile à faire avec un DHCP qu'avec de la génération sans état.

                          • éviter les problèmes de trash-cache quand des clients sont configurés comme des pingres et spam des messages RD toutes les 500 ms.

                          Et ça marche vraiment ? Cf juste au dessus, pour DHCPv6, on envoie juste des RA avec le drapeau Managed (qui désactive les adresses EUI-64, et demande au gentil client de faire une requête DHCP, mais si le client est bugué ça coincera toujours).

                    • [^] # Re: Précisions ?

                      Posté par  (site web personnel) . Évalué à 10. Dernière modification le 03 février 2014 à 13:44.

                      Pour complémenter ce que j'avance juste au dessus, car après relecture, mon poste parait presque aussi extrémiste que ceux de Zenit, ce qui est déja effrayant en soit.

                      L'IPv6 autorise un retour à une stack réseau "propre", même si la notion de propre est toute relative en réseau, sans translation d'addresse ( NAT ) et encore moins de translation de port (NAPT) pour reprendre ton commentaire.

                      Ce qui permettrait, sur le long terme, et si les FAI / admins jouent le jeu, d'éliminer définitivement la nécessiter de serveur STUN, ICE ou autre jouet du genre, d'introspection de paquets pour les protocols sales ( FTP ou SIP ), les incompatibilités avec ces même protocoles en versions sécurisés, les problèmes d'instabilités qui viennent avec les implémentations [chinoises/du stagiaire] de certains mappers, etc…

                      Tu affirmes à juste titre que "le NAPT le frangin démoniaque, lui doit mourir (en souffrant de préférence). Son grand frère le CGNAT marque l'apocalypse." et tu as parfaitement raison.

                      Mais le NAT de base, même "one to one" est déja en soit une pervertion avec son lot de problèmes que je verrai avec joie éradiqué de cette planète.

    • [^] # Re: Précisions ?

      Posté par  . Évalué à 10.

      Pour compléter les réponses précédentes et t'éviter de cliquer sur les liens. DNS64, c'est un DNS menteur qui va convertir les réponses qui sont uniquement en IPv4 (donc enregistrement A du DNS sans enregistrement AAAA) en enregistrement IPv6 avec une conversion d'adresse vers un préfixe particulier. Le NAT64, il convertit une IPv6 dans un préfixe particulier vers une IPv4 correspondante. Avec ces deux techniques, ça te permet d'aller sur des sites uniquement disponible en IPv4 (comme ici, en pratique, je n'ai pas pu testé vu que je n'avais aucun appareil qui fonctionnait uniquement en IPv6) avec une configuration uniquement IPv6 sur le client (après, il y a du dual-stack dans un routeur plus loin).

      « 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: Précisions ?

      Posté par  (site web personnel, Mastodon) . Évalué à 4.

      Le RFC sur NAT64 est le 6146 Celui sur DNS64 est le 6147

  • # Pour Android, c'est normal

    Posté par  (site web personnel) . Évalué à 3.

    En supposant que la page suivante est correcte :
    https://en.wikipedia.org/wiki/Comparison_of_IPv6_support_in_operating_systems

    On peut supposer que en effet sur Android le support IPv6 est incomplet, notamment face à iOS ou Windows Phone.
    D'ailleurs, il y a un rapport de bogue toujours actif sur le sujet : https://code.google.com/p/android/issues/detail?id=3389

    Normalement GNU/Linux supporte très bien la situation mais faute de tests d'envergure certains bogues peuvent ressurgir.

    Je trouve l'initiative sympa, espérons que cela sera l'occasion de corriger certains bogues.

    Moi je pense que la situation n'est pas si catastrophique, Windows/Mac OS X et GNU/Linux supportent l'IPv6 depuis plus de 10 ans, ceux qui n'ont pas son support sont plutôt marginaux. D'autant que le passage à l'IPv6 peut être progressif, il y a des astuces pour ça le temps de mettre à jour les systèmes et corriger les problème avant de supprimer l'IPv4.

    • [^] # Re: Pour Android, c'est normal

      Posté par  . Évalué à 6.

      ceux qui n'ont pas son support sont plutôt marginaux

      Android n'est pas marginal.

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: Pour Android, c'est normal

        Posté par  (site web personnel) . Évalué à 1.

        Non, mais un patch peut arriver, en tout cas pour ceux qui ont une version > 4.0 peuvent raisonnablement y espérer si ça venait à être comblé.
        Et les solutions palliatives le temps de la migration peuvent permettre de rendre les versions non patchés fonctionnels le temps de leur retrait de la circulation.

        • [^] # Re: Pour Android, c'est normal

          Posté par  . Évalué à 3.

          Non, mais un patch peut arriver, en tout cas pour ceux qui ont une version > 4.0 peuvent raisonnablement y espérer si ça venait à être comblé.

          Si tu commence comme ça, ça n'a plus de sens de parler de ce qui fonctionne pou pas en IPv6 tout peut potentiellement du moins, on peut raisonnablement espérer que ça fonctionne ou ça va fonctionner.

          Et les solutions palliatives le temps de la migration peuvent permettre de rendre les versions non patchés fonctionnels le temps de leur retrait de la circulation.

          Bien sûr il n'y a aucun problème pour déployer l'IPv6 faire de la double stack ne pose que peut de problème/

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

        • [^] # Re: Pour Android, c'est normal

          Posté par  . Évalué à 5.

          en tout cas pour ceux qui ont une version > 4.0 peuvent raisonnablement y espérer si ça venait à être comblé.

          Ouais, et il leur restera plus qu'a attendre de changer de telephone pour en profiter, vu comment les operateurs se depechent a mettre a jour leur parc android.

          Linuxfr, le portail francais du logiciel libre et du neo nazisme.

          • [^] # Re: Pour Android, c'est normal

            Posté par  . Évalué à 2.

            En même temps, vu que les opérateurs mobiles et les FAI sont très très liés quand ce n'est pas simplement une seule entreprise, je les imagine mal passer les réseaux domestiques en IPv6 brutalement et larguer ainsi leurs clients mobiles.

      • [^] # Re: Pour Android, c'est normal

        Posté par  . Évalué à 0.

        Ca se discute.
        En vente pures, oui, android est tres fort.

        En utilisation d'applis, j'ai toujours vu un rapport 7 a 10, sur toutes les metriques (traffic pur, engagement, conversion, ltv), entre ios et android en faveur d'ios (applis grand publics gratuites). Sur le marche us, certes, mais ca suffit pas a expliquer une telle disparite.
        C'est pas marginal, mais c'est tres loin de faire la majorite, et android pese au final tres peu dans la balance des decisions.

        En clair, si on se retrouve a devoir faire un choix "faire une feature ios only ou se limiter a ipv4", le choix sera vite fait, et pas dans le sens que tu penses.

        Linuxfr, le portail francais du logiciel libre et du neo nazisme.

        • [^] # Re: Pour Android, c'est normal

          Posté par  . Évalué à 4.

          J'ai pas dis qu'il était majoritaire, j'ai dis que ce n'est pas OS marginal. Il a une base d'utilisateur conséquente et grand publique, continue d'être développé et continue sa croissance. Après est-ce qu'il rapporte de l'argent aux fournisseurs de contenu, je ne sais (mais j'm'en fou).

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: Pour Android, c'est normal

        Posté par  . Évalué à 7.

        • Android supporte l'IPv6
        • Android se connecte de préférence en IPv6 si disponible

        Par contre Android à besoin de l'IPv4 pour se considérer en ligne.

        À pars au Fosdem c'est pas demain la veille qu'on verra des réseaux IPv6 only, c'est pas compliqué de fournir un IPv4 NATé de merde à coté d'un IPv6 natif.

        • [^] # Re: Pour Android, c'est normal

          Posté par  (site web personnel) . Évalué à 4.

          Lors du CCC, c'était aussi le cas ( juste pour info ).

          Donc ça fait 2 fois en 2 mois que j'ai le souci :)

          ( du coup, j'ai presque envie de faire ça chez moi )

          • [^] # Re: Pour Android, c'est normal

            Posté par  (site web personnel) . Évalué à -8.

            Quel soucis pour le FOSDEM? Tu passes sur le réseau "dual stack" et c'est réglé ;-).
            En réalité, ça reste du truc de geek pour le plaisir dans des évenement très très précis (et encore, tu changes de réseau et fini, c'est plus pour le plaisir de tester qu'autre chose, du moins pour le FOSDEM) car comme dit Tonton Benoit un IPv4 NATé marche très très bienet ce n'est pas demain qu'il sera enlevé (et pas sûr que je verrai le jour ou IPv4 sera supprimé).

            Certes c'est un bug qu'Android ne soit pas doué sans IPv4, mais ça reste un bug très mineur.

            • [^] # Re: Pour Android, c'est normal

              Posté par  . Évalué à 10.

              En réalité, ça reste du truc de geek pour le plaisir dans des évenement très très précis

              C'est un peu comme la neutralité du réseau. Les non-geek s'en foutent pas mal. Ils veulent acheter un abonnement pour voir facebook, youtube ou wikipedia. IPv6 permet d'avoir un réseau point à point complet sans distinguer un serveur d'un client.

              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

        • [^] # Re: Pour Android, c'est normal

          Posté par  . Évalué à 2.

          Par contre Android à besoin de l'IPv4 pour se considérer en ligne.

          C'est quoi la subtilité ?

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

          • [^] # Re: Pour Android, c'est normal

            Posté par  (Mastodon) . Évalué à 4.

            Ça veut dire que tu lui fournis une adresse IPv4 non routée, et une IPv6 parfaitement routée, ton Android sera content et sera en ligne (puisqu'adresse IPv4) et fonctionnel (puisque l'IPv6 fonctionne).
            Ça veut dire que pour avoir des Android sous pur IPv6 il suffit de faire un petit bricolage sans réelle conséquence, ni difficulté.

            Yth.

            • [^] # Re: Pour Android, c'est normal

              Posté par  . Évalué à 1.

              Ma question est pourtant simple : ça veut dire quoi qu'il se considère en ligne ou pas ? Ça impact quoi ? Ça veut dire qu'il a configuré son interface mais qu'il n'en fait rien ? Ça se traduit par quoi « ne pas se considérer en ligne » ?

              Je me fou de la solution, je veux déjà comprendre le problème.

              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

              • [^] # Re: Pour Android, c'est normal

                Posté par  . Évalué à -4.

                En gros configure ipv4 && configure ipv6.

                Après j'ai pas testé depuis longtemps et j'ai pas de réseau IPv6 only sous la main pour approfondir.

              • [^] # Re: Pour Android, c'est normal

                Posté par  . Évalué à 3.

                L'OS a besoin de savoir si il est connecté à Internet ou pas, Android a besoin d'ipv4 pour considérer qu'il l'est.
                Du coup il va essayer d'établir une connexion avec de la 3G par exemple, les interfaces pour dire aux applications si la connexion réseau est disponible vont répondre non.

                • [^] # Re: Pour Android, c'est normal

                  Posté par  . Évalué à 0. Dernière modification le 03 février 2014 à 14:28.

                  À l'époque où j'ai essayé (Android 2.3, ça date) l'IPv6 n'étais tout simplement pas configuré tant qu'aucune configuration IPv4 n'étais active.

                  Sur linuxfr, quand même, j’aurai pensé qu'on comprendrait le sens de l’opérateur '&&', c'est peut-être pas du français, mais ici y'a beaucoup plus de shophones que de francophones normalement !

                  Là je vient de voir sur mon portable, en fait ifconfig retourne plus rien sur cette rom LG de merd*, donc je ne sait même plus comment contrôler l'état des interfaces réseaux. Bon à part passer sous cyanogen, c'est prévu, mais pas dans l’immédiat.

                  • [^] # Re: Pour Android, c'est normal

                    Posté par  . Évalué à 0.

                    Sur linuxfr, quand même, j’aurai pensé qu'on comprendrait le sens de l’opérateur '&&', c'est peut-être pas du français, mais ici y'a beaucoup plus de shophones que de francophones normalement !

                    Non désolé j'ai du mal à comprendre non pas ton opérateur, mais le sujet de ta (on va être indulgent) « phrase ». Je ne savais pas si c'était de l'impératif ou du présent de vérité général. En fait comme il n'y avait pas de sujet je me suis même pas posé la question pour moi c'était de l'impératif et tu était entrain de me donner ta solution perso.

                    Sincèrement écrire comme tu l'a fait pour moi c'est pas mieux ke Dkrir an fo & tik.

                    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                  • [^] # Re: Pour Android, c'est normal

                    Posté par  . Évalué à 2.

                    Là je vient de voir sur mon portable, en fait ifconfig retourne plus rien sur cette rom LG de merd*, donc je ne sait même plus comment contrôler l'état des interfaces réseaux. Bon à part passer sous cyanogen, c'est prévu, mais pas dans l’immédiat.

                    Tu peux peut être utiliser netstat -ie ou la commande ip addr.

                    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • # J'y étais, tout va bien !

    Posté par  . Évalué à 10.

    Salut

    J'étais au FOSDEM ce week-end, et j'ai utilisé le Wifi sur une Fedora 20 et j'ai absolument pas remarqué qu'on était en IP v6. Tout à fonctionner correctement. Je viens d'apprendre que tout était en IPv6.

    Comme quoi, y'a des choses qui fonctionnent :)

    Aurélien

    • [^] # Re: J'y étais, tout va bien !

      Posté par  . Évalué à 6.

      Cela a été annoncé sur https://fosdem.org/2014/news/2014-02-01-pushing-ipv6/

      Il y avait plusieurs SSID disponibles :

      • FOSDEM resté en IPv6-only à ma connaissance
      • FOSDEM-v6 pour être certain de rester en IPv6
      • FOSDEM-dualstack pour les équipements défaillants

      Cela serait intéressant d'avoir les stats de connexions par types d'équipements, à voir si les équipes du FOSDEM trouveront le temps :-)
      Ainsi que les statistiques des sites ayant eu besoin de DNS64 comme palliatif pour fonctionner (dont LinuxFr.org :/).

      J'ai eu accès SSH, HTTP/HTTPS, ntpdate, rsync… à mes sites « habituels » avec une Mageia 2 (oui, j'ai du retard, la Mageia 4 est sortie pour le FOSDEM :D). Pour mon vieil android 2.3.4, le FOSDEM-dualstack fonctionnait de même (pas le -v6 qui ne savait pas voir qu'il était connecté :/).

    • [^] # Re: J'y étais, tout va bien !

      Posté par  (site web personnel) . Évalué à 5.

      Tout à fonctionner correctement.

      Presque tout a fonctionné correctement…

  • # DNS menteur?

    Posté par  (site web personnel) . Évalué à 1.

    avec DNS64 (donc des DNS menteurs)

    De ma compréhension, un DNS menteur est un DNS qui t'envoie vers une page non désirée (bref, de la pub) pour une adresse qui n'existe pas. De ma compréhension, DNS64 n'est qu'un intermédiaire technique qui "traduit" une réponse A en réponse AAAA et tu as toujours la page désirée si le site est la, et une erreur si le domaine n'existe pas.
    Donc pourquoi appeler DNS64 un DNS menteur?

    • [^] # Re: DNS menteur?

      Posté par  . Évalué à 10.

      Un DNS menteur c'est un DNS qui te donne des infos qui ne sont pas celles des SOA. Un DNS64, ça n'est pas utilisable avec DNSSEC par exemple. Tu voudrais faire une attaque MitM, tu ferrais exactement la même chose (rediriger les requêtes à destination du site désiré vers un serveur tier (le NAT64 ici)).

      Je ne dis pas que c'est une mauvaise chose (je pense même que c'est une bonne chose dans ce cas), ils nous mentent pour notre bien.

      « 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: DNS menteur?

        Posté par  (site web personnel) . Évalué à 3. Dernière modification le 02 février 2014 à 22:45.

        Un DNS64, ça n'est pas utilisable avec DNSSEC par exemple.

        Et c'est un argument de poids.
        OK, je comprend mieux la dénomination, merci.

        Tu voudrais faire une attaque MitM, tu ferrais exactement la même chose

        Mais dans ce cas précis, le certificat SSL du domaine est toujours valide, non? Donc c'est pas vraiment MitM car tu ne peux pas tricher sur le contenu du site…

        • [^] # Re: DNS menteur?

          Posté par  . Évalué à 3.

          Mais dans ce cas précis, le certificat SSL du domaine est toujours valide, non? Donc c'est pas vraiment MitM car tu ne peux pas tricher sur le contenu du site…

          On peut faire des attaques MitM uniquement en HTTP.

          « 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: DNS menteur?

        Posté par  (site web personnel) . Évalué à 4.

        Un DNS menteur c'est un DNS qui te donne des infos qui ne sont pas celles des SOA.

        Oui mais c'est mal dit. C'est un DNS qui donne des réponses qui ne correspondent pas aux réponses officielles données par les serveurs qui font autorité sur les zones concernées. Les enregistrements SOA n'a pas grand chose à faire là-dedans.

      • [^] # Re: DNS menteur?

        Posté par  (site web personnel) . Évalué à 5.

        ils nous mentent pour notre bien

        Nous tenons à vous rappeler que Nous n'existons pas.

        La Cabale.

  • # Bizarre

    Posté par  . Évalué à 5.

    opensuse ne veut pas non plus se connecter (la version en cours de développement fonctionne normalement).

    Ça fait pourtant un temps certain que NetworkManager permet de décocher l'IPv4 et cocher que IPv6, cela devrait normalement fonctionner sans problème sur un réseau IPv6 only.

    • [^] # Re: Bizarre

      Posté par  . Évalué à 4.

      Normalement, ça devrait marcher et au stand opensuse un type m'a dit qu'il regarderait l'origine du problème s'il a le temps.

      « 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

  • # Refaire la config

    Posté par  (site web personnel) . Évalué à 3.

    Est-ce qu'il y a une page qui explique le code utilisé et la config pour refaire le test chez nous ? (et monter un réseau full ipv6 à la maison !)

    • [^] # Re: Refaire la config

      Posté par  . Évalué à 2.

      T'as cherché sur google ?

      Oups je sort…

      Plus sérieusement c'est un poil complexe a réaliser, voici quelques connaissances à maîtriser avant de ce lancer :
      - bien connaître TCP/IP
      - bien maîtriser les concepts de base d'IPv6 (types d'adresses, autoconfiguration stateless/statefull, etc…)
      - Avoir déjà bidouiller BIND9, Zebra
      - Savoir installer TAYGA et comprendre les tenants et aboutissants (les entrées les sorties, le NAT etc…)

      Et après ça devrait rouler :)

      "Gentoo" is an ancient african word, meaning "Read the F*ckin' Manual". "Gentoo" also means "I am what I am because you all are freaky n3rdz"

    • [^] # Re: Refaire la config

      Posté par  (site web personnel) . Évalué à 2.

      Un orga du FOSDEM m'a répondu avec la config utilisée sur un routeur Cisco :
      https://supportforums.cisco.com/docs/DOC-39925

      • [^] # Re: Refaire la config

        Posté par  . Évalué à 0.

        Hello,

        To configure this we used as upstream link:
interface GigabitEthernet0/0/0
  description ---------- Uplink to COLT ----------------
   ip address 213.246.232.54 255.255.255.252
  ...
  ipv6 address 2001:920:0:1::5F/127
  nat64 enable

        Je me trompe sûrement, mais il me semblait qu'en IPv6 on déconseillait formellement d'allouer moins qu'un /64, même pour une interco (2 ips perdus dans un /64, oui m'sieur). C'est moi qui ait mal compris ?

        • [^] # Re: Refaire la config

          Posté par  . Évalué à 1.

          Demande à OVH dans leur dernier Kimsufi (ce qu'il fait qu'ils n'arrivent plus à faire de reverse DNS sur les IPv6…).
          Mais c'est vrai que c'est super crade comme solution.

        • [^] # Re: Refaire la config

          Posté par  . Évalué à 2.

          C'est parfaitement faux.

          Le /64 n'est obligatoire que dans le cas de l'auto configuration stateless. Les /127 point à point et les adresses d'administration /128 garde un intérêt et sont complètement utilisables.

          La stack ipv6 ne change rien au routage classless, les routes sont toujours transmises avec leur masque.

          "Gentoo" is an ancient african word, meaning "Read the F*ckin' Manual". "Gentoo" also means "I am what I am because you all are freaky n3rdz"

          • [^] # Re: Refaire la config

            Posté par  . Évalué à 2. Dernière modification le 04 février 2014 à 15:11.

            Rha ben je suis perplexe du coup :-)

            D'un côté je lis ça :
            http://www.bortzmeyer.org/6164.html

            Qui semble dire qu'avant, on conseillait de faire du /64, puis finalement, du /127 est conseillé (peut être que M. Bortzmeyer qui passe dans le coin pourra nous préciser si c'est toujours d'actualité ?).

            De l'autre, sur le site du RIPE, ici : http://www.ripe.net/lir-services/training/material/IPv6-for-LIRs-Training-Course/Preparing-an-IPv6-Addressing-Plan.pdf

            2.3. /64 Subnets
            IPv6 addresses don't have a fixed structure, like the class A/B/C system originally used with IPv4.
            However, IPv6 subnets should be /64 prefixes. Other subnet sizes are possible, but may get in
            the way of mechanisms such as stateless address autoconfiguration (see section 5.1). So very
            small subnets, such as a point-to-point link, use the same size IPv6 address block as very large
            subnets, such as a large Ethernet containing a number of Ethernet switches

            Je dis ça notamment parce que j'ai assisté au cours IPv6 du RIPE récemment, et les gens là bas insistaient lourdement pour ne jamais faire plus que /64 (sous peine de devenir fou, c'était à peu près le message). Après, que les adresses /127 restent utilisables en soit ne me choque pas, je suis d'accord avec toi. C'était plutôt de l'ordre de la recommandation.

            J'ai l'impression que j'ai compris de travers du coup…

            • [^] # Re: Refaire la config

              Posté par  . Évalué à 2.

              C'est logique si tu relis bien le message auquel tu réponds : les /64 c'est pour des subnets où tu accueilleras des machines qui font de l'autoconfiguration. Le /127 c'est pour le cas particulier des liaisons point à point, souvent entre deux routeurs. Le truc, c'est que si tu es un admin « lambda », tu n'as peut-être pas eu souvent l'occasion de rencontrer le deuxième cas. Je pense que c'est pour ça que dans les formations on insiste plutôt sur le premier, beaucoup plus courant.

              • [^] # Re: Refaire la config

                Posté par  . Évalué à 1.

                Le RIPE s'adressait quand même pas mal à des admins réseaux, j'osais espérer qu'ils nous filent les vrais bonnes pratiques… Et ils conseillaient de faire du /64, même pour une interco de ce type. Certains avaient dit "euh oui mais bon, ça gâche quand même pas mal d'adresses !", ce à quoi le RIPE répondait "t'inquiètes pas, on a prévu méga méga méga large, c'est pas pour rien". C'est ce que j'ai l'impression de retrouver dans le pdf que j'ai linké d'ailleurs. Ce cas particulier avait bien été abordé, y compris dans de petits exercices.

                Encore une fois, je suis d'accord au niveau du routage, IPv6 ne change rien, donc tout reste possible, mais j'avais cru comprendre que le consensus c'était au plus petit du /64 pour quoi que ce soit (autoconf ou point à point, qu'importe, malgré la perte d'adresses). Bref, je radote et tourne en rond, je vais arrêter là :D Merchi pour vos remarques.

                • [^] # Re: Refaire la config

                  Posté par  . Évalué à 2.

                  Le RIPE s'adressait quand même pas mal à des admins réseaux, j'osais espérer qu'ils nous filent les vrais bonnes pratiques…

                  Oui c'est vrai, j'avais omis ce point.

                  Et ils conseillaient de faire du /64, même pour une interco de ce type. Certains avaient dit "euh oui mais bon, ça gâche quand même pas mal d'adresses !", ce à quoi le RIPE répondait "t'inquiètes pas, on a prévu méga méga méga large, c'est pas pour rien". C'est ce que j'ai l'impression de retrouver dans le pdf que j'ai linké d'ailleurs. Ce cas particulier avait bien été abordé, y compris dans de petits exercices.

                  Je pense que du coup, c'est que chacun a son avis et n'en démord pas. Le /127 pour un lien point-à-point a semble-t-il été populaire au début, puis a été déconseillé par la RFC 3627, puis a re-été « autorisé » par la RFC6164. Je pense que vu cet historique, le consensus n'est toujours pas complètement atteint :-)

                  Encore une fois, je suis d'accord au niveau du routage, IPv6 ne change rien, donc tout reste possible, mais j'avais cru comprendre que le consensus c'était au plus petit du /64 pour quoi que ce soit (autoconf ou point à point, qu'importe, malgré la perte d'adresses).

                  En tous cas, je n'ai pas dit que /127 était bien pour tous les liens point-à-point : je pense par exemple aux liens PPP des VPNs, où pouvoir faire du RFC 4941 (Privacy Extensions for SLAAC in IPv6) est utile. Bref, il faut adapter à chaque situation.

                  • [^] # Re: Refaire la config

                    Posté par  . Évalué à 1.

                    Je pense que du coup, c'est que chacun a son avis et n'en démord pas. Le /127 pour un lien point-à-point a semble-t-il été populaire au début, puis a été déconseillé par la RFC 3627, puis a re-été « autorisé » par la RFC6164. Je pense que vu cet historique, le consensus n'est toujours pas complètement atteint :-)

                    Il me semble que l'utilisation des /127 pour des liaisons point à point vise à contourner un problème de sécurité potentiel sur les routeurs ; en scannant l'espace d'adressage d'un réseau point à point en /64 porté par un routeur et en déclenchant à répétition le mécanisme de découverte de ses voisins, cela pourrait mener à épuiser un certain nombre de ces ressources (mémoire,cpu, etc),

                    Le détail de tout ça est dans la RFC 6583

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

  • # Comment vivre avec un réseau IPv6 pur ?

    Posté par  (site web personnel) . Évalué à 3.

    Matthieu Herrb avait fait un papier sur "Comment vivre avec un réseau IPv6 pur ?"
    https://2011.jres.org/archives/57/paper57_article.pdf
    (ça date un peu mais intéressant)

    les pixels au peuple !

Suivre le flux des commentaires

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