IPv6 : des poules et des hommes

Posté par (page perso) . Édité par Davy Defaud, baud123, Benoît Sibaud, Xavier Teyssier, tuiu pol et NeoX. Modéré par baud123. Licence CC by-sa
Tags :
54
18
sept.
2012
Internet

IPv6 et ses mystères ! Ses RFC nombreuses et compliquées ! Ses mises en place de façon acrobatique pour cause de diçaïdeur pressay (« C’est dans le vent, on en parle, il faut qu’on y soit pour hier »), ou, au contraire, trop lentes (« C’est bon on a le temps, de toute façon, c’est compliqué, on n’y connaît rien et ça ne sert à rien »).

Tout ça et bien d’autres choses encore vous attendent dans le Lothaire YARDING (Yet Another Reference for Delivering IPv6 to the Next Generation).

Il s’agit d’un état de l’art sur l’IPv6 très récent (été 2012), avec des exemples d’expérimentations des différentes technologies environnantes. Ce contenu s’adresse à la fois aux personnes qui n’ont aucune connaissance en IPv6 et à ceux qui en ont déjà une bonne maîtrise, mais qui n’ont pas une idée claire de ce qui est réellement utilisable actuellement.

Ce document est à mi‐chemin entre les documentations sur l’IPv6 trop simplistes et celles qui sont trop théoriques.

Lothaire YARDING est un document issu du stage de deuxième année d’ESIAL (TELECOM Nancy) de Julien Vaubourg, au sein de l’équipe réseau Lothaire (dont je fais partie), et servira de documentation aux correspondants du réseau Lothaire en prévision de migrations à IPv6. Il est publié sous licence CC by-sa.

  • un yarding est une petite cour attenante à un poulailler permettant aux poules de s’ébattre joyeusement, tels des paquets IPv6 en liberté.

P.‐S. : Ceci ne constitue en rien une annonce officielle de l’équipe réseau Lothaire. Mais, je pars du principe qu’une doc sur IPv6 ne vaut que si on la diffuse rapidement.

  • # transparence entre IP v6 et IP v4

    Posté par . Évalué à 5.

    Une fois résolu le problème de l'infrastructure réseau, il me semble que le plus gros problème sera dans les applications elle-mêmes.

    Il me semble que l'api socket unix classique est IP v4 et que l'on doit faire des changements pour utiliser IP V6. Est-ce qu'il existe des library qui masquent ces différences, permettant de fonctionner dans les 2 versions de façon transparentes ?

    "La première sécurité est la liberté"

    • [^] # Re: transparence entre IP v6 et IP v4

      Posté par . Évalué à 7.

      getaddrinfo(3) avec un super exemple qui montre comment s'y prendre…

    • [^] # Re: transparence entre IP v6 et IP v4

      Posté par . Évalué à 6.

      J'ose esperer que tous les toolkits incluant un support reseau le font de maniere transparente. <pub>En tout cas, c'est le cas pour les EFLs.</pub>

    • [^] # Re: transparence entre IP v6 et IP v4

      Posté par (page perso) . Évalué à 5.

      Bas niveau : getaddrinfo() en C

      Haut niveau : libcurl ou libneon en C

      Et tous les équivalents dans les autres langages (le problème est largement spécifique à C)

    • [^] # Re: transparence entre IP v6 et IP v4

      Posté par . Évalué à 3.

      les principales difficultés ne viennent pas du full V4 ou full V6 mais de la double pile. De fait, lors de l'utilisation de la double pile, un logiciel compatible peut utiliser les 2 versions et c'est là que le bas blesse car il arrive parfois qu'on ne sache pas quelle est la version IP qui va être testée en premier niveau applicatif et ça mène parfois à des comportements pour le moins douteux.

  • # Intéressant

    Posté par . Évalué à 2.

    Excellente initiative.
    Mais attention, tu devrais redimensionner tes images avant (e.g. xkcd), parce que ça rend un peu flou.

    Ah, et le lien git est cassé.

    • [^] # Re: Intéressant

      Posté par (page perso) . Évalué à 3.

      Ce serait surtout merveilleux que xkcd file des versions vectorielles de ses strips :). Pour le git, c'est parce que c'est pas du http mais du protocole git (à utiliser avec git clone).

      • [^] # Re: Intéressant

        Posté par (page perso) . Évalué à 4.

        Je pense que le problème vient de linuxfr et de sa transformation des url.

        Donc le lien git correct est git://git.fiat-tux.fr/yarding.git

        It's a fez. I wear a fez now. Fezes are cool !

        • [^] # Re: Intéressant

          Posté par . Évalué à 2.

          Effectivement …
          Pourquoi suis-je redirigé vers le bon lien si j'ouvre le lien normalement, alors que je suis redirigé vers git.com si je l'ouvre dans un nouvel onglet ?

  • # IPv6 et écologie

    Posté par . Évalué à 9.

    J'ai l'impression que l'IPv6 c'est un peu un problème similaire à l'écologie.
    Tout le monde est d'accord pour dire que c'est bien et qu'il faudrait qu'on s'y mette tous, mais tout le monde traîne des pieds parce que ça fait changer (habitudes ou autres) et parce qu'il n'y a pas de ROI immédiat (ou peu par rapport à l'investissement).
    Pas contre quand y a des subventions…

    • [^] # Re: IPv6 et écologie

      Posté par . Évalué à 5.

      Contrairement à l'écologie, la catastrophe pourrait avoir lieu avant 2020. Cela remplace le bug de l'an 2000.

      "La première sécurité est la liberté"

    • [^] # Re: IPv6 et écologie

      Posté par . Évalué à 7.

      Moui, sauf que pour IPv6 c'est totalement "maîtrisé" par les humains, l'écologie très, très peu ce qui fait une grosse différence.

      • [^] # Re: IPv6 et écologie

        Posté par . Évalué à 0.

        Je pense qu'on peut faire bcp plus qu'on ne le crois ou qu'on ne nous le laisse penser (qui a dit lobby ?).
        Moi je m'y mettrais encore plus quand il y aura au moins 2 écolos 100% d'accord entre eux. ;-)

        P.S : La Tesla model S a un écran de 17 tactile embarqué, c'est classe, et en plus elle est jolie !

        • [^] # Re: IPv6 et écologie

          Posté par . Évalué à 10.

          Moi je m'y mettrais encore plus quand il y aura au moins 2 écolos 100% d'accord entre eux. ;-)

          Bah si fallait attendre de trouver 2 linuxiens 100% d'accord avec eux pour ne plus se dire que Linux c'est pas pour moi…

      • [^] # Re: IPv6 et écologie

        Posté par . Évalué à -2.

        Il y a a aussi une histoire de pognon (un peu comme l'écologie). Changé le matos non compatible IPv6, ça peut couter…

        • [^] # Re: IPv6 et écologie

          Posté par . Évalué à 3.

          Il y a aussi une historie d'écologie : changer tout le matériel non-compatible ça peut polluer…

          • [^] # Re: IPv6 et écologie

            Posté par . Évalué à 3.

            Oui, j'ai toujours été troublé par les démarches green IT consistant à jeter des serveurs pour en acheter des nouveaux sous prétexte qu'ils sont un peu moins consommateurs en électricité par rapport à leur puissance CPU: troquer des kilowatts contre des kilos de polluants…

    • [^] # Re: IPv6 et écologie

      Posté par (page perso) . Évalué à 3.

      Tout le monde est d'accord pour dire que c'est bien et qu'il faudrait qu'on s'y mette tous, mais tout le monde traîne des pieds

      C'est triste ton avis sur linuxfr.

    • [^] # Re: IPv6 et écologie

      Posté par . Évalué à 1.

      Aucun rapport, c'est parce qu'on se dit que d'ici à ce que la migration vers IPv6 soit indispensable, on aura assisté à un cataclysme planétaire et ce sera plus la peine.

      ------------->[ ]

  • # Support site web

    Posté par . Évalué à 1.

    Très intéressant, merci.

    Ça me motive pour faire passer les sites web que je gère à bien marcher en IPv6. Je ne trouve nulle part une doc ou un livre très pragmatique expliquant quoi faire pour qu'un site web soit accessible en IPv6 (sur un serveur Linux chez OVH dans mon cas). Et comment tester que ça marche, depuis un FAI (Free en l'occurence).

    Merci d'avance pour vos tuyaux.

    • [^] # Re: Support site web

      Posté par (page perso) . Évalué à 2.

      OVH : Tu peux activer l'IPv6 depuis ton manager.

      Site : C'est pas plus compliqué qu'en IPv4, faut juste s'assurer que ça écoute bien en IPv6 (apache + ipv6 ça doit donner pas mal de résultats dans un moteur de recherches).

      FAI : Tu dois activer l'IPv6 depuis ton interface Free, et vérifier avec Wireshark que c'est contacté en IPv6, ou bien simplement faire afficher ton adresse IP quelque part sur le site web en question.

      • [^] # Re: Support site web

        Posté par . Évalué à 2.

        Faut pas oublier d'ajouter les entrées DNS avec l'adresse ipv6 du serveur.

        • [^] # Re: Support site web

          Posté par (page perso) . Évalué à 1.

          Pour le coup, si c'est OVH qui est chargé de résoudre la zone, il me semble qu'il se charge tout seul de la compléter quand on active l'IPv6.

          • [^] # Re: Support site web

            Posté par (page perso) . Évalué à 2.

            ¿ T'es sûr de ton coup ? J'ai l'IPv6 sur mon serveur OVH mais ça ne transforme pas automatiquement mes enregistrements A en AAAA.
            Si je fais un dig AAAA sur une adresse *.fiat-tux.fr uniquement enregistrée en A, je n'ai pas de réponse (et heureusement !)

            It's a fez. I wear a fez now. Fezes are cool !

            • [^] # Re: Support site web

              Posté par (page perso) . Évalué à 1.

              J'ai constaté ça pour un mutualisé en fait, donc c'est possible en effet qu'il soit moins envahissant pour du dédié.

    • [^] # Re: Support site web

      Posté par (page perso) . Évalué à 7.

      Pour tester, c'est simple :

      Site qui a v6 :

          % curl -v -6 http://www.afnic.fr/ > /dev/null
      * About to connect() to www.afnic.fr port 80 (#0)
      *   Trying 2001:67c:2218:2::4:20...
        % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                       Dload  Upload   Total   Spent    Left  Speed
        0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0* connected
      * Connected to www.afnic.fr (2001:67c:2218:2::4:20) port 80 (#0)
      
      

      On voit les adresses v6, c'est bon.

      Site qui n'a pas v6 (il a bien une adresse mais v4 seulement) :

      % curl -v -6 http://www.fleurpellerin.fr/ > /dev/null     
      * getaddrinfo(3) failed for www.fleurpellerin.fr:80
      * Couldn't resolve host 'www.fleurpellerin.fr'
      * Closing connection #0
      curl: (6) Couldn't resolve host 'www.fleurpellerin.fr'
      
      
      • [^] # Re: Support site web

        Posté par . Évalué à 5.

        Ah oui:

        curl -6v http://linuxfr.org
        * getaddrinfo(3) failed for linuxfr.org:80
        * Couldn't resolve host 'linuxfr.org'
        * Closing connection #0
        curl: (6) Couldn't resolve host 'linuxfr.org'
        
        

        voir mon poste suivant ;)

        • [^] # Re: Support site web

          Posté par . Évalué à 1. Dernière modification le 23/09/12 à 09:51.

          Dans le même genre :

          curl -v -6 http://www.esial.uhp-nancy.fr
          * getaddrinfo(3) failed for www.esial.uhp-nancy.fr:80
          * Couldn't resolve host 'www.esial.uhp-nancy.fr'
          * Closing connection #0
          curl: (6) Couldn't resolve host 'www.esial.uhp-nancy.fr'
          
          
    • [^] # Re: Support site web

      Posté par . Évalué à 1.

      En effet, comme il est dit dans l'article, il n'y a pas de quoi casser la patte à une poule pour configurer un site en IPv6 aujourd'hui.

      1. Configuration du DNS (ou du /etc/hosts pour les premiers tests)
      2. Avec une debian chez OVH, tout est prêt, il y a juste à rajouter une IPv6 sur eth0, comme expliqué ici : http://guides.ovh.com/Ipv4Ipv6
      3. Chez Free, il faut configurer l'accès IPv6

      et un test avec curl -6 fonctionne correctement.

      Merci à tous pour ces tuyaux.

      • [^] # Re: Support site web

        Posté par (page perso) . Évalué à 3. Dernière modification le 18/09/12 à 16:08.

        il n'y a pas de quoi casser la patte à une poule pour configurer un site en IPv6 aujourd'hui.

        Et s'assurer que tous les outils (par exemple : de stats par pays qui doit accepter une IP v6, l'antispam des commentaires basé sur les IP, les projets internes qui ont stocké l'adresse sur 4 octets…) son compatibles.
        Si c'est si simple, mais pourquoi diable LinuxFr (le serveur, le réseau pour accéder au site…) n'est toujours pas en IPv6?

        C'est bien plus compliqué que tu veux faire croire.

        • [^] # Re: Support site web

          Posté par . Évalué à 6.

          Oups pardon, je voulais mettre un peu d'optimisme dans l'IPv6. D'accord, je voulais dire que pour un site qui ne tient pas compte des IPs, qui est hébergé chez OVH (qui semble avoir tout le matériel qui va bien pour gérer ça), avec une version Debian récente, et un FAI qui gère aussi l'IPv6, on pouvait arriver à faire un premier curl -6 en quelques minutes.

          Mais bon d'accord, je ne le ferai plus : IPv6, c'est trop compliqué, je préfère laisser ça aux générations futures Et je ne ferai plus non plus de jeu de mot foireux … des poules et des hommes … casser des pattes à un canard … des poules … des canards…

          Bon d'accord je sors … Tchao !

    • [^] # Re: Support site web

      Posté par (page perso) . Évalué à 2.

      Bonjour,
      La doc suivante devrait répondre à tes questions concernant le DualStack…http://www.deltageek.fr/configurer-ipv6-serveur-linux/

      Cas concret de la doc : Serveur Linux chez OVH et testé avec une connexion Free :)

  • # ipv6 sur linuxfr

    Posté par . Évalué à 10.

    Et en attendant il n'y a pas d'ipv6 sur linuxfr ;)
    Pourtant online propose de l'ipv6 depuis un bail.

  • # patches ?

    Posté par . Évalué à 2.

    Chap 1.1 en bas de la page 11, "enrailler", je suppose que c'est enrayer ?

    • [^] # Re: patches ?

      Posté par . Évalué à 2.

      Page 12, 2e paragraphe, "quiconque n'aurait".

      • [^] # Re: patches ?

        Posté par (page perso) . Évalué à 3.

        Merci beaucoup, j'ai commité les corrections sur le git (j'attend un peu que le serveur soit moins sollicité pour regénérer le pdf).

        N'hésite pas si tu as d'autres réflexions !

        • [^] # Re: patches ?

          Posté par . Évalué à 3.

          Bah j'ai un peu peur que le système de commentaire de linuxfr ne soit pas trop adapté :)

          Après, avec un dépôt git, on peut il est vrai penser à d'autres solutions…

          • [^] # Re: patches ?

            Posté par (page perso) . Évalué à 2. Dernière modification le 18/09/12 à 18:53.

            Sinon il y a toujours mon courriel en haut à gauche du document, qui est aussi une adresse jabber.

  • # Merci l'ESIAL !

    Posté par (page perso) . Évalué à 2.

    Merci cet article.
    ça fait plaisir de voir l'ESIAL, Nancy et lothaire cité sur DLFP au passage.

    (un ex-nancéen)

  • # Téléphone

    Posté par . Évalué à 1.

    La première phrase est fausse, ça fait mauvais effet …
    > Jusqu’à 1985, les numéros de téléphones français comportaient sept chiffres

    C'est inexact, il y en avait 8 :
    - pour Paris, le chiffre 1, plus 7 chiffres
    - pour la province, 2 chiffres pour le département, plus 6 chiffres

    Cela permettait donc d'avoir 100 millions de numéros (en fait un peu moins, puisque les numéros ne pouvaient pas commencer par le chiffre 1, ni le chiffre 0 me semble-t-il).

    • [^] # Re: Téléphone

      Posté par . Évalué à 0.

      En réalité, ils pouvaient commencer par zéro.

    • [^] # Re: Téléphone

      Posté par . Évalué à 4.

      Je me souviens même d'avoir utilisé des numéros de téléphone à 6 chiffres. Je ne me souviens pas s'il y avait des particularités liées à la province ou pas, je n'appelais que de province à province. En fait, j'ai même jamais téléphone plus loin que 30 Km de chez moi à l'époque.

      Après, on a ajouté un numéro supplémentaire (par département ou groupe de département), pour moi c'était le 45 (Charente).

      Après, on m'a rajouté le 05 (Sud-Ouest).

      Enfin j'étais tout gamin…

      • [^] # Re: Téléphone

        Posté par . Évalué à 10.

        À cette époque (début des années 80), dans ma cambrousse seules quelques maisons avaient une ligne de téléphone. Ainsi, chez mes parents, c'était un téléphone public. Les voisins et les gens de passage venaient téléphoner, chez nous. Il y avait un compteur qui nous permettait de les faire payer à l'unité et de faire un (très léger) bénéfice. Et puis il y avait les gens qui appelaient chez nous parce qu'il voulaient dire quelque chose à un voisin et nous (moi ou l'un de mes frères et sœurs) partions à vélo pour prévenir que untel était mort ou qu'il fallait rappeler tel numéro. Parfois on nous donnait un petit pourboire ou quelques bonbons.

        J'étais gamin et je ne suis pas encore très vieux, c'est fou comme ça à changé ces dernières années les télécommunications.

    • [^] # Re: Téléphone

      Posté par (page perso) . Évalué à 1.

      D'après la page wikipédia sur la numérotation téléphonique en France, à partir de 70, il n'y avait que 5 indicatifs différents, en plus des 7 chiffres : 1, 3, 6, 7 et 8. Ce qui correspond à peu près à 50 millions de possibilités. Le chiffre exact importe peu, c'est l'ordre d'idée qui est intéressant.

      Je corrige en :

      Avec les quelques indicatifs, cette numérotation permettait à environ 50 millions de personnes de communiquer ensemble, pour plus de 65 millions de français recensés actuellement (ajoutés aux nombreuses lignes professionnelles).
      
      
  • # ipv8

    Posté par (page perso) . Évalué à 6.

    Les RIR qui clament haut et fort : faites de l'ipv6 ! faites de l'ipv6 !

    IPv6 c'est 0.8% du trafic de google (http://www.google.com/ipv6/statistics.html) et moins de 90000 hits/s chez akamai (http://www.akamai.com/ipv6/). A ma connaissance, aucun FAI de masse, n'active ça par défaut.

    Pour faire de l'IPv6, il ne suffit pas de peerer avec Hurican Electric. Il faut pouvoir avoir un routage de qualité, sans trous, propre à satisfaire les clients. Si c'est faire de l'IPv6 pour ensuite expliquer comment forcer IPv4 c'est totalement sans intérêt. Hors il arrive souvent qu'il y ait des trous dans la raquette notamment aux extrémités.

    Une petite boite ne va pas se payer les frais d'une migration si presque aucun de ses clients n'utilise cette possibilité. Dans le domaine HT, ça fait Hype. La réalité c'est qu'aujourd'hui placer ses serveurs et ses DNS sous IPv6 cela ne sert à rien. Et pourtant, il y a sans doute beaucoup plus de serveurs en IPv6 que de clients.
    Finalement les petites boites sont mises sous pression pour cause de pénurie d'IpV4. Les grosses boites qui ont encore de la marge ne font rien et les RIR exhortent le soleil a resurgir de derrière l'horizon.

    C'est donc sur les FAI qu'il faut coller la pression. En exigeant de l'IPv6 par défaut. Bon courage à tous :)

    • [^] # Re: ipv8

      Posté par (page perso) . Évalué à 1.

      Les RIR qui clament haut et fort : faites de l'ipv6 ! faites de l'ipv6 !

      un IP coûte toujours que 1€ (un /24 à 300€), c'est rien en coût. Si il y a vraiment pénurie, pourquoi les prix n'augmentent pas pour calmer les ardeurs? Si il y a pénurie et pas de passage en IPv6, c'est aussi de la faute des RIR qui ne s'occupent pas de suffisamment motiver les hébergeurs et FAI à y passer… Le choc sera rude du fait de la non anticipation réelle (par le seul truc qui fasse réagir les entreprises) des RIR…

      • [^] # Re: ipv8

        Posté par . Évalué à 4.

        Tes sources ne sont pas bonnes: Une ressource (AS, plage IPv4 ou IPv6) c'est 50€/an. Sauf que maintenant (dernier /8) il faut être LIR pour pouvoir demander, 1,3k€/an et 2,2k€ de frais d'entrée c'est assez cher pour toi ;) ?

        • [^] # Re: ipv8

          Posté par (page perso) . Évalué à -5.

          Tes sources ne sont pas bonnes

          https://www.ovh.com/fr/serveurs_dedies/blocs_ip_ripe.xml

          Pour commander un Bloc IP Fail-Over Ripe, rendez-vous dans votre Manager v3
          Taille du bloc Frais d'installation Frais mensuel
          4 5.99€ HT (7.16€ TTC) 0 € / Mois
          8 9.99€ HT (11.95€ TTC)
          16 17.99€ HT (21.52€ TTC)
          32 34.99€ HT (41.85€ TTC)
          64 69.99€ HT (83.71€ TTC)
          128 139.99€ HT (167.43€ TTC)
          256 279.99€ HT (334.87€ TTC)

          • [^] # Re: ipv8

            Posté par . Évalué à 6.

            Cool, des IP routables uniquement chez OVH.

            Merci Zenitram de nous exposer ta science !

            • [^] # Re: ipv8

              Posté par (page perso) . Évalué à 1.

              C'est le prix d'une adresse IP quand j'en ai besoin d'une. Pas besoin d'aller vers IPv6 donc. J’achèterai le même prix si je change d'hébergeur.
              La réalité ne vous plait peut-être pas, mais c'est bien le prix d'une adresse IP quand une personne a besoin d'être accessible. Qu'elle ne soit pas PI, on s'en fou un peu grâce aux DNS.

          • [^] # Re: ipv8

            Posté par (page perso) . Évalué à 9.

            Pour commander un Bloc IP Fail-Over Ripe, rendez-vous dans votre Manager v3

            Oui, il y a ceux qui ont du stock et qui brade ça aux spammerspersonnes ne souhaitant pas être blacklistés. Et ceux qui n'en ont pas et qui galèrent. C'est justement le problème. Si tu te lances aujourd'hui. Tu fais comment pour monter ton AS avec ton misérable /22 ? Tu grattes, tu fais gaffes et surtout tu ne brades pas tes IPs.

            Pour ce qui est de l'IP failover d'OVH, je trouve infect ce type de pratiques. Je n'irai pour rien au monde vendre un /24 à mes clients sans justification. Il ont une IP avec leur serveur/vm et autant d'IP qu'ils en ont besoin pour le SSL ou pour faire du load-balancing ou du failover. Par contre il est hors de question que je vende des subnet pour qu'ils évitent d'être blacklistés. Si le RIP faisait son boulot ce type de pratique non conforme aux règles qu'il a édicté serait sanctionné. Mais il préfère empocher les cotisations et incanter IPv6.

            La pénurie d'IPv4 c'est les gros opérateurs contre les petits. Ceux qui ont du stock contre ceux qui n'en ont pas. Le pied qui écrase les cafards. Je ne dis pas ça pour OVH en particulier. Mis à part cette histoire de failover vraiment hideuse, se sont des gens correct et compétents.

            • [^] # Re: ipv8

              Posté par (page perso) . Évalué à 0. Dernière modification le 18/09/12 à 20:42.

              Oui, il y a ceux qui ont du stock et qui brade

              C'est tout le sens de mon constat : les RIR n'ont pas fait assez attention à ne pas en refiler n'importe comment, et ce comportement (laisser d'autres comportements pas corrects de la part d'autres personnes) est possible sans impact financier pour le demandeur.

              Je ne dis pas ça pour OVH en particulier.

              Perso, je trouve normal qu'OVH le fasse si il peut le faire, son but est d'attirer des clients. J'accuse plutôt celui qui l'autorise à le faire, le gendarme qui n'a pas fait son boulot.

              • [^] # Re: ipv8

                Posté par . Évalué à 1.

                J'accuse plutôt celui qui l'autorise à le faire, le gendarme qui n'a pas fait son boulot.

                Belle philosophie :)

              • [^] # Re: ipv8

                Posté par (page perso) . Évalué à 1.

                J'accuse plutôt celui qui l'autorise à le faire, le gendarme qui n'a pas fait son boulot.

                Quand un de tes clients en respecte pas le contrat, accuses tu aussi le gendarme ?

                • [^] # Re: ipv8

                  Posté par (page perso) . Évalué à 3.

                  Tu dénonces le contrat et le client se retrouve mal. Classique. Ce ne fut pas fait, ça veut dire que c'était accepté. C'est un choix de leur part, mais il a des conséquences.

    • [^] # Re: ipv8

      Posté par (page perso) . Évalué à 1.

      C'est donc sur les FAI qu'il faut coller la pression. En exigeant de l'IPv6 par défaut. Bon courage à tous :)

      Un scénario cool, ce serait de mettre au point rapidement la boî-boîte auto-hébergement pour Average Joe, et ensuite balancer de grosses campagnes de pub expliquant que la boî-boîte ne marche bien que quand on est chez [liste des FAI qui proposent une IP publique fixe]. Les FAI qui ne sont pas dans la liste parce qu'ils font du NAT/de l'IP dynamique devraient passer rapidement à IPv6.

      La partie la plus dure là-dedans, c'est de trouver une ou deux killer-features qui permettront de présenter l'auto-hébergement comme indispensable au quidam moyen. Pour l'instant j'ai pas trouvé.

      • [^] # Re: ipv8

        Posté par . Évalué à 7.

        Un scénario cool, ce serait de mettre au point rapidement la boî-boîte auto-hébergement pour Average Joe, et ensuite balancer de grosses campagnes de pub expliquant que la boî-boîte ne marche bien que quand on est chez [liste des FAI qui proposent une IP publique fixe]. Les FAI qui ne sont pas dans la liste parce qu'ils font du NAT/de l'IP dynamique devraient passer rapidement à IPv6.

        La partie la plus dure là-dedans, c'est de trouver une ou deux killer-features qui permettront de présenter l'auto-hébergement comme indispensable au quidam moyen. Pour l'instant j'ai pas trouvé.

        C'est surtout pas super réaliste de compter que le déploiement de l'auto-hébergement pour tous aide à déployer IPv6 ;-)

        • [^] # Re: ipv8

          Posté par (page perso) . Évalué à 9.

          Clairement, il vaut mieux une appli pour visualiser du pr0n.

          if (ipv4==true) {
             plantouille_de_temps_en_temps()
          }
          
          
    • [^] # Re: ipv8

      Posté par . Évalué à 5.

      Finalement les petites boites sont mises sous pression pour cause de pénurie d'IpV4. Les grosses boites qui ont encore de la marge ne font rien et les RIR exhortent le soleil a resurgir de derrière l'horizon.

      À ce sujet, le point de vue de Benjamin Bayart est intéressant. Dans un billet de blog de fdn où il explique que les règles édictées pour IPv4 ont été bêtement transposées à IPv6 ce qui mène à des absurdités, je cite :

      il est assez facile d'obtenir des adresses IP v4, mais pratiquement impossible d'obtenir des adresses IP v6 auprès du RIPE NCC.
      […]
      Mais la belle règle prévue pour v4 est appliquée pour v6. Donc, dans un bloc PI en v6, il est interdit de distribuer des sous-réseaux. Or pour raccorder un abonné en IP v6, il est fortement préconisé de lui attribuer tout un réseau.

      Ergo, il est interdit de raccorder des abonnés en IPv6 avec des blocs PI.

      • [^] # Re: ipv8

        Posté par (page perso) . Évalué à -4.

        D'un autre côté, on a inventé le DNS aussi pour éviter d'être dépendant d'une adresse IP qui n'est qu'un numéro. On a juste à changer l'IP dans le DNS quand on change d'hébergeur.

        J'ai peut-être pas suivi un truc, mais ça sert à quoi, en pratique, une IP "PI"?

        • [^] # Re: ipv8

          Posté par . Évalué à 2.

          relis l'article de FDN, c'est pas si mal expliqué: un bloc PI (Provider Independant) est un bloc d'adresses qui te sont nominativement attribuées, et non pas une adresse appartenant à ton fournisseur qui te la "loue" le temps de la durée du contrat.

        • [^] # Re: ipv8

          Posté par . Évalué à 2.

          De ce que j'ai compris :

          • l'entreprise Tartempion devient un LIP auprès de RIPE et peut donc distribuer des plages IP à des clients dans la page qui lui a été allouée par le RIPE.
          • Un FAI Associatif truc-muche décide de passer un contrat avec l'entreprise Tartempion pour la gestion de ses accès.
          • Mais afin de ne pas voir toutes ses adresses IP liées à Tartempion le jour où pour une raison ou une autre, il souhaiterait changer de fournisseur, il demande à son LIP de lui fournir une plage IP PI.
          • Donc, le LIP fais une demande de plage IP auprès de RIPE afin de fournir une plage IP qui ne soit pas dans la plage IP qui lui a été originellement attribuée et la fournie au FAI truc-muche.

          Et, le jour où truc-muche veut quitter Tartempion, et bien il garde son plan d'adressage.


          J'espère ne pas trop m'être trompé.

          • [^] # Re: ipv8

            Posté par . Évalué à 1.

            C’est plutôt correcte, néanmoins c’est LIR pour Local Internet Registery.

          • [^] # Re: ipv8

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

            Et, le jour où truc-muche veut quitter Tartempion, et bien il garde son plan d'adressage.

            Le jour où il veut quitter Tartempion, il prend de nouvelles IP chez y pur le même prix dérisoire et change son DNS et basta. Ma question est bien de savoir pourquoi le "PI" est important vu qu'on a DNS (et pourquoi on ne fait pas ces adresses plus cher pour éviter un manque brut d'un coup. Bref, c'est la base d'une gestion à long terme que d’augmenter le prix artificiellement au fur et à mesure pour inciter à passer à autre chose. PI ou pas)

            • [^] # Re: ipv8

              Posté par (page perso) . Évalué à 3.

              Ma question est bien de savoir pourquoi le "PI" est important vu qu'on a DNS

              Peut-être pour la mobilité, lorsqu'on souhaite une haute disponibilité "couche basse" de ses connexions en passant de provider en provider.
              Mais c'est peut-être un besoin anecdotique et peut-être solvable par d'autres moyens techniques, je sais pas trop.

            • [^] # Re: ipv8

              Posté par (page perso) . Évalué à 3.

              Pourquoi est-ce que le PI est important ? Si on n'a qu'un FAI, pas trop, sauf si on veut héberger ses propres serveurs DNS (pour lesquels on ne peut pas faire appel au DNS pour trouver leur adresse).

              Le PI devient beaucoup plus intéressant lorsqu'on est multi-homé (plusieurs FAI), ce qui est bien utile pour la résilience.

              • [^] # Re: ipv8

                Posté par (page perso) . Évalué à 2. Dernière modification le 18/09/12 à 23:07.

                Si on n'a qu'un FAI, pas trop, sauf si on veut héberger ses propres serveurs DNS (pour lesquels on ne peut pas faire appel au DNS pour trouver leur adresse).

                Le changement des adresses IP des serveurs DNS se fait assez facilement, et assez souvent d'ailleurs. C'est quoi le soucis avec les DNS pour la majorité des gens? Je suis bien conscient qu'il y a des cas problématiques (tu l'indiques sur ton blog), mais pour tous les gens à qui on essaye de vendre IPv6 ou le IPv4 PI, ça fait pschit comme argument.

                Le PI devient beaucoup plus intéressant lorsqu'on est multi-homé (plusieurs FAI), ce qui est bien utile pour la résilience.

                J'imagine très bien qu'il y a des gens pour qui c'est important (IP codées en dur, sécurité renforcée…). Seulement, ce n'est pas le cas pour la majorité des gens qui achètent des IP (avec leur serveur filé par leur hébergeur). Et pour cette majorité, le prix est toujours bien faible, même aujourd'hui où il parait qu'on est en manque d'adresse c'est horrible. Aujourd'hui, je peux acheter un bloc (non PI certes, mais comme pour beaucoup de monde ça suffit, c'est ce beaucoup de monde qu'il faut regarder) chez OVH ou autre pour pas cher.


                Ici, on se focalise sur ces fameuses PI ou le besoin de garder des IP fixes en oubliant que la majorité des IP ne sont pas PI, que les gens à qui on demande de passer à IPv6 n'ont pas de PI. Forcément, si on parle que de PI en oubliant la majorité des gens, on tire à côté et IPv6 ne risque pas d'être "vendu" avant le "mur" du vrai manque qui va arriver violemment, toujours à cause de cette politique. Dommage, cette transition aurait pu être mieux gérée, avec une gestion à long terme, et la on va se prendre le mur en pleine tronche du jour au lendemain avec un seul /8 qui reste (bon, 3 mois près si j'ai bien suivi la politique des RIR qui demandent à ce que les autres n'aient que 3 mois de réserve).

                Bref, si on parlait de la majorité des gens, ceux à qui on veut "vendre" IPv6, plutôt que des exceptions? N'est-ce pas se tromper de cible en parlant de ces PI? Le serveur LinuxFr a un adresse PI?

              • [^] # Re: ipv8

                Posté par . Évalué à 4.

                sauf si on veut héberger ses propres serveurs DNS (pour lesquels on ne peut pas faire appel au DNS pour trouver leur adresse).

                Non, là on passe par la config du registrar - toujours pas besoin de PI. J'héberge mes propres DNS, je les ai déjà changé plusieurs fois de place et d'hebergeur moyennant 10 secondes de config sur l'interface web de mon registrar.

                Le PI devient beaucoup plus intéressant lorsqu'on est multi-homé (plusieurs FAI), ce qui est bien utile pour la résilience.

                Je vieux bien l'adresse et le numero des FAI qui font du routage sur des plages modeste (au hasard un /28) - Déjà sur un /24 ils font la gueule et il faut être très bon client chez eux (comprendre que le jour ou tu n'es plus bon client, tu n'as plus de routage).

                Je ne pense pas qu'IPv6 améliore ce problème (Et vu les horreurs que nous sort le RFC tous les dix jours, j'aurais plutôt tendance à penser qu'il va empirer).

            • [^] # Re: ipv8

              Posté par . Évalué à 1.

              Car on prend le cas d'un FAI.
              Et que un FAI qui fourni des adresses IP publique à client, il aimerait bien ne pas avoir à changer toutes les adresses de ses boitiers de terminaison (modem, router) car il change de LIR…

              Et une par importante de ces équipements n'ont pas forcement de DNS.

              Évidement, pour l'entreprise lambda, ce n'est pas forcement très utile.

        • [^] # Re: ipv8

          Posté par . Évalué à 6.

          Et quand tu dois renuméroter toute ton infra, tu fais comment ?

          Sérieusement, chacun son métier quoi… On avait compris que le tiens n’est pas celui d’admin sys/admin réseau.

          • [^] # Re: ipv8

            Posté par (page perso) . Évalué à -7.

            On avait compris que le tiens n’est pas celui d’admin sys/admin réseau.

            Effectivement, ce n'est pas mon métier. Mais ma formation me permet de douter des compétences d'une personne qui veut des adresses IP fixes et que ça embête de changer l'IP de son serveur car ça demanderai trop de boulot. Chacun son plaisir de travailler pour rien, on va dire.

            • [^] # Re: ipv8

              Posté par . Évalué à 10.

              et que ça embête de changer l'IP de son serveur

              Putain, mais des serveurs tu sais combien on en a au taff ?

              Tu t’imagines si, du jour au lendemain, on doit tout renuméroter ? Tu imagines changer tout le routage interne, les règles de parefeu, les interco, etc ? Pire que ça, tu imagines si on va voir nos client en leur disant que eux doivent renuméroter ?

              Je pense que tu ne vois même pas la charge de travail que ça peut être.

              Sérieusement, je me permets pas de te dire que c’est mal, tu utilise tel ou tel coding style et que c’est de la merde alors reste dans ton domaine de compétence et, quand tu ne sais pas instruit toi…

            • [^] # Re: ipv8

              Posté par . Évalué à 5.

              et que ça embête de changer l'IP de son serveur

              Tout est dit : si tu n'a qu'un serveur on s'en fout. Comme Arcaik, je travaille dans une TPE (hébergeur/FAI). Je gère au quotidien quelques centaines de serveurs (95% Linux, 5% Windows et FreeBSD) et une quarantaine d'équipements réseaux (commutateur, routeur, pare-feu).

              Pour changer de plan IP, ça implique :
              - prévenir tous les clients que le changement va avoir lieu
              - configurer le nouveau plan IP en parallèle de l'ancien sur toute la couche réseau
              - Vérifier toutes les règles de filtrage, que la supervision est à jour, …
              - ajouter la nouvelle IP à chaque serveur
              - valider pour chaque serveur qu'il est prêt à passer sur la nouvelle IP (vérifier avec le client)
              - Retirer l'ancienne IP de chaque serveur
              - Réparer les merdes (parce qu'il y en aura)
              - Déconfigurer l'ancien plan IP

              Pour nous, avec deux /21 et un /23, c'est un minimum de 6 mois du début à la fin (oui, on est qu'en IPv4 pour le moment, mais on aura mis en prod IPv6 avant février prochain).

              Toutes ces étapes sont nécessaires car tu ne sais jamais où sont utilisé tes IP. Dans tes DNS (là tu as la main), mais aussi dans les zones DNS de tes clients (qui sont parfois gérer à l'étranger à cause de certains TLD). Les IP peuvent être inscrite en dur dans un équipement (j'ai le cas d'un client qui fait de l'embarqué, un changement d'IP pour lui c'est une galère)

              C'est sûr, on peux aussi y aller comme des bourrin comme tu le suggère, mais alors là c'est l'assurance d'une grosse gamelle !

    • [^] # Re: ipv8

      Posté par . Évalué à 2.

      Pv6 c'est 0.8% du trafic de google […] A ma connaissance, aucun FAI de masse, n'active ça par défaut.

      Les utilisateurs de Linux c’est 0.8% du trafic de Google. À ma connaissance aucun constructeur de masse ne l’installe par défaut.

      Sinon, moins ironiquement : rien qu’en France, pour le grand publique il y a Free et SFR qui font de l’IPv6 et aussi pas mal de FAI pour professionnels (Nerim, etc.).

      Une petite boite ne va pas se payer les frais d'une migration si presque aucun de ses clients n'utilise cette possibilité.

      Désolé de te contredire mais je travail dans une TPE (un FAI pro) et le calcul est vite fait : on a qu’un petit /21 on ne pourra plus en avoir d’autre sûrement, il ne reste qu’IPv6 pour exister sur Internet.

      Les personnes qui ont « oublié » IPv6 jusqu’à aujourd’hui auront un train de retard qu’il ne pourront que difficilement rattraper.

      • [^] # Re: ipv8

        Posté par (page perso) . Évalué à 2.

        Sinon, moins ironiquement : rien qu’en France, pour le grand publique il y a Free et SFR qui font de l’IPv6 et aussi pas mal de FAI pour professionnels (Nerim, etc.).

        Je disais bien "A ma connaissance, aucun FAI de masse, n'active ça par défaut". Ce n'est pas le cas de Free en tout cas. Donc mis à part les personnes éclairées, personne ne l'utilise.

        Désolé de te contredire mais je travail dans une TPE (un FAI pro) et le calcul est vite fait : on a qu’un petit /21 on ne pourra plus en avoir d’autre sûrement, il ne reste qu’IPv6 pour exister sur Internet.

        Je travaille aussi dans une petite boite. On a activé ipv6 depuis plus d'un an. Cela represent une partie tellement minime du trafic qu'elle est presque non quantifiable. Le dual stack n'est pas prêt de disparaître. C'est un fait.

        Ce que j'essayais de mettre en exergue c'est que tant que les FAI ne l'auront pas déployé massivement (on parle pas du truc optionnel pour faire plaisir), l'IPv6 ne résoudra pas ton problème. Tu devra gérer la pénurie. Ou te procurer des IPv4 par d'autre moyens.

        • [^] # Re: ipv8

          Posté par (page perso) . Évalué à 3.

          Ce n'est pas le cas de Free en tout cas

          Il me semble que c'est maintenant activé par defaut.

          • [^] # Re: ipv8

            Posté par . Évalué à 1.

            Pas pour tout le monde :

            "Vous pouvez en zone dégroupée bénéficier d'une connectivité au protocole IPv6."

            Quand on ne l'est pas, ce qui est mon cas, pas d'IPV6…

      • [^] # Re: ipv8

        Posté par (page perso) . Évalué à 5.

        le grand publique

        le grand public

        C'est pourtant pas compliqué…

        • [^] # Re: ipv8

          Posté par . Évalué à -1.

          J'ai jamais su la règle pour publique/public.

          On dit d'une chose qu'elle est publique mais on parle du public c'est ça ?

          • [^] # Re: ipv8

            Posté par . Évalué à 9.

            J'ai jamais su la règle pour publique/public.

            C'est pourtant simple:

            • masculin = public (le public, le domaine public)
            • féminin = publique (la réunion publique)
      • [^] # Re: ipv8

        Posté par (page perso) . Évalué à 2.

        Concernant Free, il ne faut pas oublier qu'ils font du 6rd. Si les adresses IPv6 qu'ils distribuent semblent donc venir d'un réseau natif, ça n'est pas du tout le cas : comme indiqué dans yarding, un sniffeur placé entre une Freebox et la prise téléphonique murale ne verra passer que de l'IPv4.

        La seule exception c'est pour les lignes FTTH qui sont en IPv6 de bout en bout (ce point va être ajouté dans yarding).

        • [^] # Re: ipv8

          Posté par . Évalué à 2.

          Je suis chez Free en FTTH et j'utilise 6rd. Ça a changé récemment? (mon setup date de moins d'un an).

          • [^] # Re: ipv8

            Posté par (page perso) . Évalué à 2.

            Le 6rd côté Free est totalement transparent, comment en es-tu sûr ?

            • [^] # Re: ipv8

              Posté par . Évalué à 2.

              Je n'utilise pas la freebox. J'ai été parmi les premiers à avoir la joie de recevoir la freebox optique v2, qui est une freebox adsl v5 recyclée avec un autre firmware, et la prise optique est déportée dans un boîtier externe ethernet <-> fibre. La freebox ne tient pas les débits annoncés (100Mbps en dl théoriques, le matériel tient 20Mbps en routeur et 50Mbps en bridge, sans la freebox on monte plus de 100Mbps; plus d'infos sur ce bug, et sur ce long thread).

              Bref j'ai configuré du rd6 à la main et ça fonctionne bien. Si entre temps ils sont passés en ipv6 natif il faudrait que je reconfigure tout ça.

  • # DHCPv6 et Prefix delegation

    Posté par . Évalué à 3.

    Merci beaucoup de rendre cela public, c'est très intéressant et ce n'est pas facile de trouver des sources lisibles à ce sujet (se farcir les RFC c'est un peu pénible quand on veut juste se connecter à Internet).
    Un truc dont ton PDF ne parle pas (et c'est normal puisque la problématique c'est le réseau interne), c'est comment ça se passe en pratique pour le client d'un FAI.
    De ce que j'ai compris chez Free (qui attribue des /64), tout se fait avec NDP (le routeur de Free fait sa pub et annonce la plage dispo et les DNS). Mais je suis chez OVH (nobox) qui donne des /56, et il faut passer par DHCPv6 et le "prefix delegation" (le serveur dhcp te délègue le /56 en même temps qu'il t'attribue une IP qui n'est pas dans ce /56, et tu en fais ce que tu veux derrière). Je n'ai peut-être pas suffisamment creusé la question mais j'ai l'impression que c'est la seule façon de déléguer dynamiquement un /56 (ou toute plage strictement plus grosse que /64), c-à-d qu'il me semble que NDP ne peut pas faire ça.
    Du coup si demain l'IPv6 se démocratise (et que les FAI attribuent des /56 ou même des /48) j'imagine que ça sera la technique utilisée par défaut (ils ne vont pas configurer statiquement les box quand même), et donc ça sera important. Le problème avec l'implémentation actuelle c'est qu'il y a deux programmes séparés (dhcpv6-client et radvd) qui devraient discuter pour faire ça, mais ce n'est pas encore le cas. Du coup je n'ai pas trouvé d'autre moyen que de demander le prefix delegation avec DHCPv6, mais en configurant radvd statiquement (c'est un peu con).
    Si quelqu'un a mieux compris comment tout ça est sensé fonctionner, je lui serai reconnaissant de me (nous) faire partager sa science!

    • [^] # Re: DHCPv6 et Prefix delegation

      Posté par (page perso) . Évalué à 2.

      Un truc dont ton PDF ne parle pas

      Non, non, pas mon pdf, celui de Ju :-)

      Ju, une réponse ?

      It's a fez. I wear a fez now. Fezes are cool !

    • [^] # Re: DHCPv6 et Prefix delegation

      Posté par (page perso) . Évalué à 2.

      N'ayant pas une ligne Free (mais plutôt libre et neutre), je ne peux pas vérifier, mais j'ai un gros doute sur le fait qu'il utilise NDP pour la diffusion des DNS. Comme démontré dans le document, le RDNSS qui permet cela est encore loin d'être suffisamment démocratisé (notamment parce qu'il est apparu plus tard). Au delà de ses possibilités d'administration plus puissantes (comme le DDNS), c'est principalement pour cette raison que le DHCPv6 est encore très utilisé, a minima en complément du NDP.

      Concernant radvd, son nom signifie Router ADVertisement Daemon, il ne concerne donc pas les clients. Et le NDP n'a pas de contrainte particulière, à ma connaissance, concernant la taille du préfixe qu'il peut annoncer via ses RA.

      • [^] # Re: DHCPv6 et Prefix delegation

        Posté par . Évalué à 1.

        Pour Free je ne sais pas je n'ai pas non plus, mais pour le DNS j'imagine qu'il se contente de l'IPv4.
        J'avais cru comprendre que tout routeur doit ignorer les RA (mais avec un sysctl on peut changer ça sous Linux au moins).
        Si tout doit marcher automagiquement avec le NDP, il va falloir que le routeur à la maison analyse les RA venant du routeur des FAI, et décide d'attribuer telle plage à tels clients, en envoyant à son tour des RA et en configurant les route.
        Existe-t-il un programme qui se charge de ça sous Linux?

        Concernant la taille du préfixe dans les RA, si celui-ci est plus court que /64, par exemple /56, est-ce que les clients peuvent mettre n'importe quoi pour les 8 bits suivants?

        • [^] # Re: DHCPv6 et Prefix delegation

          Posté par (page perso) . Évalué à 1.

          Effectivement les équipements réseaux et les serveurs n'ont pas intérêt à se sentir concernés par les modes d'autoconfiguration, quelqu'ils soient.

          Concernant l'organisation de ton réseau domestique, il y a effectivement de nouvelles questions qui se posent. Non pas à cause de l'IPv6, mais à cause de la disparition des NAT. Ce problème est expliqué, avec l'exemple des associations MAC-IP (autrefois assurées par l'ARP mais maintenant à la charge du NDP), dans le document, en tête de la section Auconfiguration et DNS. Tu verras que la solution est le proxy NDP, qui se met en place directement avec la commande ip sous GNU/Linux. Tu trouveras plein de tutos sur la toile, dont celui-ci (qui évoque aussi le brouting).

          Concernant l'utilisation des bits dans tes adresses, tu pourras effectivement mettre à peu près ce que tu veux dans ces 8 bits de réseau, mais il semble judicieux de se contraindre à quelques bonnes pratiques (dont tu peux prendre connaissance dans la section du même nom, du document).

          • [^] # Re: DHCPv6 et Prefix delegation

            Posté par . Évalué à 1.

            Merci, dans mon cas (je ne sais pas si OVH fait "mal" son boulot ou pas), les RA que mon routeur reçoit sur la ligne ont les flags M (managed) à 1 et O (other) à 0, ainsi qu'un préfixe de 128 bits. Je crois que je n'ai pas la possibilité de configurer "sans état" (avec un proxy NDP) du coup.
            Mais même si OVH avait choisi d'utiliser NDP, j'ai l'impression que le proxy NDP n'est pas optimal: cela ne permet pas d'organiser son/ses réseau(x) domestique(s) comme on veut derrière (dynamiquement). Ou alors est-ce qu'il y a une implémentation permettant au routeur domestique de reçevoir le préfixe du FAI en NDP (en supposant uniquement la longueur du préfixe comme connue à l'avance) et de "segmenter" derrière, en NDP toujours (sans même se préoccuper des DNS)?

        • [^] # Re: DHCPv6 et Prefix delegation

          Posté par . Évalué à 2.

          N'ayant pas une ligne Free (mais plutôt libre et neutre), je ne peux pas vérifier, mais j'ai un gros doute sur le fait qu'il utilise NDP pour la diffusion des DNS.

          Pour Free je ne sais pas je n'ai pas non plus, mais pour le DNS j'imagine qu'il se contente de l'IPv4.

          De mémoire (à confirmer donc), si, et un apt-get install rdnssd devrait faire le boulot. En attendant, les DNS v4 sont effectivement envoyés en DHCP(v4). Cela a le mérite de marcher en failback :).

      • [^] # Re: DHCPv6 et Prefix delegation

        Posté par . Évalué à 1.

        Et merci à ju donc!

      • [^] # Re: DHCPv6 et Prefix delegation

        Posté par . Évalué à 1. Dernière modification le 19/09/12 à 08:26.

        mais j'ai un gros doute sur le fait qu'il utilise NDP pour la diffusion des DNS

        Si : il suffit d'installer une rdnssd pour voir son fichier hosts mis à jour par le infos envoyées par la Freebox…

        • [^] # Re: DHCPv6 et Prefix delegation

          Posté par (page perso) . Évalué à 2.

          Je n'ai évidemment aucun doute sur le fait que GNU/Linux soit performant :). Mais le fait est que c'est actuellement le seul qui soit vraiment capable de le faire (cf. yarding), et encore, ça n'est pas installé nativement sur les distros.

          Pour que l'IPv6 se démocratise, il faudra que ça soit un peu plus qu'une histoire de geeks…

    • [^] # Re: DHCPv6 et Prefix delegation

      Posté par . Évalué à 2.

      Le problème avec l'implémentation actuelle c'est qu'il y a deux programmes séparés (dhcpv6-client et radvd) qui devraient discuter pour faire ça, mais ce n'est pas encore le cas. Du coup je n'ai pas trouvé d'autre moyen que de demander le prefix delegation avec DHCPv6, mais en configurant radvd statiquement (c'est un peu con).

      Normalement, il faudrait effectivement que le client DHCPv6 et radvd dialoguent. Ça n'est pas encore tout à fait automatique actuellement, mais j'espère que ça arrivera dans les distributions bientôt. Car tout ça, ça ne reste qu'une histoire de scripting à faire quand ton client dhcp reçoit un préfixe.

  • # Fiouf

    Posté par (page perso) . Évalué à 1.

    140 pages ! J'attendrai la sortie du film !
    Sinon, ça m'a l'air très intéressant. Je vais étudier ça a tête reposé ! Peut être que enfin, j'arriverai a faire migrer ma société du IPv6 :)

  • # English grammar

    Posté par (page perso) . Évalué à 2.

    (Yet Another Reference for Deliver IPv6 to the Next Generation).

    I may very well be wrong, but I am pretty sure that you meant "Yet Another Reference for Delivering IPv6 to the Next Generation."

  • # IPV6, Nat, Firewall et réseaux locaux

    Posté par . Évalué à 3.

    Hello,

    J'ai pas encore lu l'ensemble du document mais pour moi ce qui est le plus obscure/inquiétant est de savoir ce qui va se passer pour mon réseau local.

    Actuellement, j'ai une configuration assez classique:
    Box -> Routeur WRT54G avec OpenWRT -> PC, Smartphones etc.

    Le routeur fait office de pare-feu et de passerelle NAT afin que tout le monde puisse se connecter au grand ternet.

    Voilà, de ce que j'ai compris, IP v6 va permettre de se passer du NAT et donc tout le monde aura une adresse publique.
    Je suppose que mon FAI me donne une plage d'IP et que c'est à moi (sans doute à mon routeur de déterminer l'adresse publique des machines).

    Quid de la sécurité ?

    Le NAT m'offre (un semblant ?) de sécurité car les machines ne sont pas vraiment accessibles depuis l'extérieur.
    Du coup, il va falloir sérieusement revoir les règles du firewall, non ?

    Machine IP v4 ?

    Les trucs comme les consoles qui n'ont pas de support d'IP v6 sont exclus d'internet.
    Faut-il que mon routeur continue à faire du NAT pour eux ?

    Voilà. J'aimerais bien m'y mettre mais j'ai un peur d'ouvrir la boîte de pandore.

    Merci.

    • [^] # Re: IPV6, Nat, Firewall et réseaux locaux

      Posté par . Évalué à 3.

      Le NAT m'offre (un semblant ?) de sécurité car les machines ne sont pas vraiment accessibles depuis l'extérieur.
      Du coup, il va falloir sérieusement revoir les règles du firewall, non ?

      Oui. Mais installer un firewall statefull, cela se fait en 3 minutes. De mémoire:

      Laisse passer les paquets correspondants aux flux déjà établis.:
      ip6tables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
      Drop le reste:
      ip6tables -A INPUT -j DROP

      • [^] # Re: IPV6, Nat, Firewall et réseaux locaux

        Posté par . Évalué à 2.

        Un tel exemple de chaine INPUT, me fait dire que la règle de filtrage proposée est d'une part destinée à être appliquée à chaque machine du réseau (et non pas au routeur (FORWARD) alors que ce serait plus pertinant dans l'optique du remplacement du NAT), et d'autre part qu'elle est suceptible de bloquer les mécanismes de découverte du préfix IPv6 utilisé pour définir les adresses globales (celles qui sont routables sur internet).

        • [^] # Re: IPV6, Nat, Firewall et réseaux locaux

          Posté par . Évalué à 2.

          C'est vrai, j'ai fais ça un petit peu trop en vitesse (moinssez moi). Une version plus correcte, serait:

          ip6tables -A FORWARD -p icmpv6 -j ACCEPT
          ip6tables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
          ip6tables -A FORWARD -j DROP

          Concernant l'ICMPv6, de mémoire, il sert pas seulement à la découverte du prefix global et de l'adresse qui lui est associée aussi à la construction des adresses locales, ainsi qu'à la communication entre les machines elles même puisse ce qu'il remplace l'ARP et à la gestion de la fragmentation. Il est donc très fortement recommandé de ne pas le dropper. Si l'on souhaite filtrer certaines choses (pour ne pas répondre aux ping par exemple, même si je doute de la pertinence de cette idée), une bonne source d'informations est la https://tools.ietf.org/html/rfc4890 qui contient des exemples ip6tables à la fin.

          • [^] # Re: IPV6, Nat, Firewall et réseaux locaux

            Posté par . Évalué à 2.

            Erf, je ne peux pas éditer mon commentaire. La version précédente ne marcherait pas. Celle ci par contre devrait être bonne:

            ip6tables -A FORWARD -p icmpv6 -j ACCEPT
            ip6tables -A FORWARD -i $interface_publique -j FWD_FROM_PUB
            ip6tables -A FORWARD -i $interface_privée -j FWD_FROM_PRIV
            ip6tables -A FORWARD -j LOGDROP

            ip6tables -A FWD_FROM_PUB -m state --state RELATED,ESTABLISHED -j ACCEPT
            ip6tables -A FWD_FROM_PUB -j DROP
            ip6tables -A FWD_FROM_PRIV -i $interface_privée -j ACCEPT
            ip6tables -A FORWARD -j DROP

      • [^] # Re: IPV6, Nat, Firewall et réseaux locaux

        Posté par . Évalué à 3.

        Et comme ça tu bloque même ce que les RFC interdisent de bloquer.

    • [^] # Re: IPV6, Nat, Firewall et réseaux locaux

      Posté par (page perso) . Évalué à 2.

      Comme expliqué dans yarding, on a énormément associé la sécurité au NAT au fil des années, depuis que l'appauvrissement des adresses nous a obligé à le mettre en place de façon systématique. Il n'y a pourtant aucun rapport entre cette notion et celle de pare-feu.

      Ce dernier peut (doit !) être déployé aussi bien pour l'IPv4 que pour l'IPv6, et le fait que toutes les adresses soient publiques (ce qui est initialement naturel, et ce que les nouvelles générations d'informaticiens découvrent) n'est pas synonyme de passoire.

      Pour une box grand public, j'imagine qu'un pare-feu intelligemment configuré remplacera à terme le NAT obsolète.

      • [^] # Re: IPV6, Nat, Firewall et réseaux locaux

        Posté par (page perso) . Évalué à 1.

        Il n'y a pourtant aucun rapport entre cette notion et celle de pare-feu.

        "Aucun rapport", "aucun rapport", bin si y'a quand même le rapport qu'une IP derrière un NAT n'est pas directement joignable de l'extérieur par des trucs du genre script kiddies, alors que sans NAT elle le serait.
        Alors arrêtez de dire que y'a "aucun rapport". Que le NAT ne soit pas un moyen convenable de faire de la sécurité, 100% d'accord, l'élément de sécurité (aussi petit soit-il) du NAT est un effort de bord, mais il existe quand même et on doit trouver d'ailleurs son pendant côté IPv6 en adoptant des règles spécifiques.

        • [^] # Re: IPV6, Nat, Firewall et réseaux locaux

          Posté par . Évalué à 2.

          une IP derrière un NAT n'est pas directement joignable de l'extérieur

          Dans le cas d'un NAT où une IP externe est mappée sur une et une seul IP interne cette phrase est fausse.

          on doit trouver d'ailleurs son pendant côté IPv6 en adoptant des règles spécifiques.

          Pour offrir la fonctionnalité « machine non accessible de l'extérieur », je pense que c'est bon, on a ce qu'il faut depuis longtemps, ça s'appelle un parefeu.

          • [^] # Re: IPV6, Nat, Firewall et réseaux locaux

            Posté par (page perso) . Évalué à 1.

            Dans le cas d'un NAT où une IP externe est mappée sur une et une seul IP interne cette phrase est fausse.

            Je parlais implicitement de N -> 1, qui est le cas de la plupart des entreprises qui mettent en place du NAT et qui n'ont pas toutes une classe A à leur disposition.

            Pour offrir la fonctionnalité « machine non accessible de l'extérieur », je pense que c'est bon, on a ce qu'il faut depuis longtemps, ça s'appelle un parefeu.

            Il n'empêche que le NAT (je précise masquerading pour ceux qui font semblant de ne pas comprendre mon propos) a pour effet de bord de cacher les machines, ce qui est un élément constitutif de sécurité. Pour le reste, je répète que je n'ai jamais écris que le NAT se substituait à un firewall, juste que la phrase "le NAT n'a aucun rapport avec la sécurité" que j'entends régulièrement me semble un peu extrême.
            C'est bien simple, prend un réseau d'entreprise classique IPv4 avec un NAT N->1 ET un Firewall, maintenant, tu rends soudainement publiques toutes les adresses de ton réseau, on va voir si le NAT ne rajoutait pas une petite couche de sécurité.

            • [^] # Re: IPV6, Nat, Firewall et réseaux locaux

              Posté par . Évalué à 4.

              Je comprends pas comment tu arrives à une telle conclusion…

              Le NAT n'apporte pas plus de sécurité qu'un parfeu qui DROP tout sauf RELATED,ESTABLISHED. Donc, si ton parefeu est bien configuré, tu peux virer le NAT, ça ne changera rien.

              • [^] # Re: IPV6, Nat, Firewall et réseaux locaux

                Posté par (page perso) . Évalué à 2.

                si ton parefeu est bien configuré

                Je parle de PME, de configurations multiples et variées, plus ou moins bien foutues où le NAT est utilisé (aussi) pour cacher les machines internes de l'extérieur.
                Le NAT est utilisé à mauvais escient mais ça "fonctionne" quand même => c'est le frontal qui se prend les attaques et les machines derrière ne peuvent physiquement pas être jointes directement, sauf à faire de la translation de port ou bien du BIMAP.

                Un peu de nuance, c'est tout ce que je fais remarquer. Il y a beaucoup de gens qui utilisent cet aspect "dissimulation des réseaux internes" du masquerading EN plus des options de firewalling.
                Et puis, autre chose, avec le NAT N->1, c'est l'IP du firewall qui sort, avec IPv6, on a N IP qui sortent, alors certes, il y a des stratégies existantes d'anonymisation des IP, mais c'est également un autre aspect du NAT qu'on "perd".

        • [^] # Re: IPV6, Nat, Firewall et réseaux locaux

          Posté par (page perso) . Évalué à 3. Dernière modification le 19/09/12 à 17:02.

          Oui, un effet de bord, effectivement. Et c'est un effet de bord sur lequel ne comptent pas les réseaux d'entreprise, qui assurent le contrôle des accès via un pare-feu indépendant, IPv6 ou non. La sécurité est donc un élément à part entière, indépendante de la notion de NAT.

          Pour un réseau domestique en IPv4, le NAT et les règles de PAT assurent effectivement cette notion de pare-feu, du moins pour tout ce qui vient de l'extérieur. Mais peu importe, puisqu'un simple pare-feu dans les box suffira à le remplacer, et de façon plus avantageuse.

    • [^] # Re: IPV6, Nat, Firewall et réseaux locaux

      Posté par . Évalué à 1.

      Pour la question de la "sécurité" du NAT, tu peux lire cet article qui résume très bien la situation : http://www.bortzmeyer.org/nat-et-securite.html

      Pour les équipements uniquement IPv4 par contre effectivement c'est la merde, ils ne pourront jamais marcher en v6. Mais tu peux activer l'IPv6 sans s'inquiéter pour eux, la fin du dual-stack n'est pas pour aujourd'hui…

      • [^] # Re: IPV6, Nat, Firewall et réseaux locaux

        Posté par . Évalué à 1.

        Il ne fonctionneront pas en IPv6. Ok. Mais alors faut-il prévoir une installation spécifique sur le routeur ou bien est-ce naturellement pris en compte par cette nouvelle version ?
        Merci.

  • # Mise à jour suite aux remarques

    Posté par (page perso) . Évalué à 2.

    Voir ce journal, pour ce qui est des mises à jour effectuées depuis la diffusion de la dépêche.

Suivre le flux des commentaires

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