Événement G6 - IPv6 - 11 avril 2012 - Paris

Posté par  . Édité par Manuel Menal et Benoît Sibaud. Modéré par baud123.
Étiquettes :
19
5
avr.
2012
Technologie

Le 6 juin 2012 l'ISOC organise le lancement officiel et définitif d'IPv6 avec le World IPv6 Launch. Le G6 et les grands acteurs de l'Internet français se mobilisent en organisant une journée de préparation et d'échanges afin que la France ait la place qu'elle mérite dans ce lancement mondial. Si au niveau des infrastructures, la France se place à un haut niveau (en particulier grâce à Free qui propose IPv6 à tous ses clients ADSL dégroupés), il n'en va pas de même aux niveaux des fournisseurs de contenus et de services.

Le 11 avril 2012 représente une première étape dans la préparation en France du lancement mondial prévu le 6 juin. Ce sera l'occasion de réunir pionniers IPv6, constructeurs et acteurs qui se lancent afin de faire le point sur les besoins en matière de déploiement et les moyens existants ou à mettre à disposition pour y parvenir. La journée comportera notamment des présentations, des témoignages, des débats sur les solutions et les technologies disponibles pour activer IPv6 à partir du 6 juin.

De nombreux acteurs de tous horizons ont déjà répondu présents :

  • Enseignement et recherche (Telecoms ParisTech, Telecom Bretagne, G6),
  • Opérateur de transit et de services (NeoTelecoms, AFNIC),
  • Constructeurs (Cisco Systems, Juniper Networks, Stonesoft).

Et pour mettre un peu d'animation dans les démos des équipementiers, BreakingPoint Systems nous a concocté des plans de tests IPv6 très poussés.

Vous trouverez toutes les informations sur cet événement sur la page http://g6.asso.fr/launch/

Le programme présenté sur le site n'est pas encore finalisé et nous espérons voir la liste des partenaires s'agrandir !

L'inscription est évidemment gratuite, néanmoins, merci d'envoyer un mail à info@g6.asso.fr.

Rendez-vous le 11 avril à Telecom ParisTech.

Aller plus loin

  • # Free as a bird

    Posté par  . Évalué à 6.

    en particulier grâce à Free qui propose IPv6 à tous ses clients ADSL

    A tous ses clients ADSL dégroupés non ?

    Bref, jolie pub. M'enfin…
    Sinon Nerim a été initiateur en France. Et la Société Française de Radiotéléphone propose l'IPv6 également.
    Donc oui, grâce à différents opérateurs, La France aime l'IPv6.

    • [^] # Re: Free as a bird

      Posté par  . Évalué à 10.

      Le but n'est pas de faire de la pub.

      Par contre, free a tout de même été l'un des premiers opérateurs grand publique à proposer IPv6, a pas mal travaillé dessus au point de proposer des normes facilitant son déploiement (6rd), cela méritait d'être noté, car ce n'est pas pour rien que la France s'en sort si bien en terme d'IPv6. Si l'on regarde le nombre de réseaux, cela ne saute pas aux yeux, en revanche si l'on regarde le nombre d'internautes ayant un accès IPv6, ou la proportion de trafic IPv6 c'est tout de suite un peu plus marquant: https://www.google.com/intl/en/ipv6/statistics/.

      Par contre, tu as raison, ça n'est de mémoire, que pour les accès dégroupés, à corriger peut être ? :)

      • [^] # Re: Free as a bird

        Posté par  . Évalué à 1.

        Il pique les yeux ton graphique par pays effectivement.
        Je ne sais par quel bout commencer: IPv6 l'exception française? La France championne du monde de l'IPv6 ? Le champion du monde a moins de 5% d'IPv6 14 ans après la validation de la norme ? Bref je ne sais pas s'il faut rire ou pleurer.
        (14 ans c'est 9 périodes de Moore, des machines 512 fois plus puissantes pour le même prix)

        Cela dit les chiffres concernent les recherche google si je comprends bien donc il y a un sérieux biais (genre la Chine doit pas trop s'en servir). Et on ne parle pas des serveurs, sur lesquels les hosteurs français ne doivent pas être trop mauvais non plus (OVH, Online et Gandi proposant tous de l'IPv6 natif sauf erreur de ma part).

        • [^] # Re: Free as a bird

          Posté par  . Évalué à 3.

          La France championne du monde de l'IPv6 ? Le champion du monde a moins de 5% d'IPv6

          En fait c'est le Bhoutan qui est champion du monde avec 7,69% !!!

      • [^] # Re: Free as a bird

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

        Par contre, tu as raison, ça n'est de mémoire, que pour les accès dégroupés, à corriger peut être ? :)

        Corrigé.

      • [^] # Re: Free as a bird

        Posté par  . Évalué à 5.

        free a tout de même été l'un des premiers opérateurs grand publique à proposer IPv6, a pas mal travaillé dessus au point de proposer des normes facilitant son déploiement (6rd)
        Sauf que l'ipv6 proposé est assez limité :
        - plus de pare-feu/nat de la part de la box
        - si on met un routeur derrière on a perd l'auto-decouverte (le masque devient trop petit).

        En fait l'ipv6 a voulu innover,mais ne répond pas forcement au besoin qui sont rempli par dhcp et le nat (et oui le nat est utile meme en ipv6 : imaginez un réseau d'entreprise qui change de fournisseur, sans le nat il faut qu'il change les ip de tout son réseau interne …).

        C'est vraiment le manque d'ipv4 qui pousse vers ipv6 et pas les features d'ipv6 : ca montre quand meme qu'il y a un pb quelque part…

        • [^] # Re: Free as a bird

          Posté par  . Évalué à 6.

          En fait l'ipv6 a voulu innover,mais ne répond pas forcement au besoin qui sont rempli par dhcp et le nat (et oui le nat est utile meme en ipv6 : imaginez un réseau d'entreprise qui change de fournisseur, sans le nat il faut qu'il change les ip de tout son réseau interne …).

          C'est vraiment le manque d'ipv4 qui pousse vers ipv6 et pas les features d'ipv6 : ca montre quand meme qu'il y a un pb quelque part…

          Tu as plein de manières de répondre à ce besoin. Par exemple, tu peux faire du Nat avec IPv6 et utiliser un préfix local (ULA) en interne par exemple.

          Quelle différence dans ce cas ? C'est du nat stateless qui fait juste la correspondance $PREFIX1:$HOST $PREFIX2:$HOST et qui préserve la connectivité de bout en bout.

          • [^] # Re: Free as a bird

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

            La vraie solution qui me parait raisonnable est une interface ebtable sur la console free (feature déjà demandée dans leur bug tracker).
            IPV6 c'est bien, mais gérer le firewall sur chaque device, c'est un peu gavant.

          • [^] # Re: Free as a bird

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

            Par exemple, tu peux faire du Nat avec IPv6 et utiliser un préfix local (ULA) en interne par exemple.

            Oui mais le fait que de base il manque ULA ca fait un peu ma au cul.

            Pour revenir au commentaire précédent, suite à un changement de prefixe en 2008, ils pourraient en filer un un peu plus grand. Je ne sais pas pourquoi ce n'est pas fait.

        • [^] # Re: Free as a bird

          Posté par  . Évalué à 10.

          (et oui le nat est utile meme en ipv6 : imaginez un réseau d'entreprise qui change de fournisseur, sans le nat il faut qu'il change les ip de tout son réseau interne …).

          C'est pour ça qu'on utilise des noms de machine.

          THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

          • [^] # Re: Free as a bird

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

            Et ? Ça aide juste les utilisateurs qui n'ont pas à changer les noms qu'ils tapent. Je ne vois pas en quoi cela change le fait qu'il faut aller sur chacune des machines ayant une IP statique (chaque serveur, routeur, commutateur, point d'accès, probablement les imprimantes aussi. Seuls les hôtes en DHCP vont y échapper) et changer le préfixe réseau partout où il apparaît (et oui, il y a des tas d'endroits où il va se nicher : les conf' des multiples interfaces de ton serveur, mais aussi ton resolv.conf car ton serveur de noms interne va aussi changer d'adresse, le $mynetworks de ton Postfix, tes /etc/hosts.{allow,deny}, j'en passe et des meilleures).

            Bien sûr, tu peux utiliser un truc du genre clusterssh/mssh/pssh pour tenter de mettre à jour tout le monde en même temps, mais à moins que tes serveurs soient tous configurés de la même manière (même distrib', mêmes services, fichiers de conf' très proches), ça ne sera pas gagné pour autant. Sans compter qu'il faut préparer et tester un minimum. Perso, je vois facilement deux jours de perdus pour l'admin, plus les oublis qui vont générer des tensions (« vous n'arrivez plus à vous connecter ? Ah mince, j'ai dû oublier de mettre à jour le fichu pare-feu, un instant »). Et là, tes noms de machine, ça devient très secondaire.

            AMPSHA, ce qu'il aurait fallu écrire™ est « c'est pour ça qu'on prend des plages d'adresses portables et qu'on fait du bégépé ». Sauf que, tout d'un coup, entre les frais pour être LIR, le routeur pour faire ça et les deux transits avec BGP, ça ne coûte plus la même chose, et la proposition ne passera plus auprès d'une boîte moyenne qui se débrouille avec genre une ligne SDSL plus une ADSL. Donc, oui, ça me désole de le dire, mais (HIP et autres protocoles fumeux mis à part), le NAT est utile même en IPv6 (mais moins casse-bombons : si tu peux mapper une /48 à une autre /48, tu n'as pas besoin de PAT qui est la principale épine dans le pied du NAT44).

            Envoyé depuis mon PDP 11/70

        • [^] # Re: Free as a bird

          Posté par  . Évalué à 1.

          dhcp et le nat (et oui le nat est utile meme en ipv6 : imaginez un réseau d'entreprise qui change de fournisseur, sans le nat il faut qu'il change les ip de tout son réseau interne …)

          Mon petit point de vue :

          • Pour DHCP il faut attendre les normes anycast et que tout le monde se mette d'accord sur l'adresse anycast d'un serveur DNS
          • Pour le changement de FAI : tu met à jour ton DNS et tu laisse les machines en stateless déterminer le nouveau chemin (trop dur…)

          Le NAT c'est juste un vestigal de pouvoir des opérateurs (centralisé centralisé centralisé…) pour garder qq chose de vertical… En fait il suffit d'utiliser du stateless de mettre plusieurs routeur annonçant leur route, chaque interface va prendre plusieurs IPv6 sur chaque routeur et déterminera sa passerelle … Pour l'instant la détermination se fait au hasard (dernière adresse prise) mais on pourrait très bien faire intervenir le ping ou un protocole de routage pour déterminer le meilleur accès.


          Le top serait de prendre une route par défaut puis de tester chaque destination et d'allonger la table de routage du pc en fonction des destinations (tel prefixe plus court par tel fai, tel autre etc…)

          Le NAT c'est bon pour créer des goulets d'étranglements : VIVE le vrai réseau

          "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: Free as a bird

            Posté par  . Évalué à 3.

            Pour DHCP il faut attendre les normes anycast et que tout le monde se mette d'accord sur l'adresse anycast d'un serveur DNS

            Le DHCP a d'autres usages. Il est disponible en v6 (en stateless et statefull). Cela peut servir typiquement à rajouter une entrée DNS à volée.

            Pour le changement de FAI : tu met à jour ton DNS et tu laisse les machines en stateless déterminer le nouveau chemin (trop dur…)

            Ouais, mais nan. Tu assignes pas tes IPs de serveurs à coup de radvd…

            Le NAT c'est juste un vestigal de pouvoir des opérateurs (centralisé centralisé centralisé…) pour garder qq chose de vertical…

            Non, c'est une technologie, par définition neutre; tout dépend de ce que les gens en font. Et le NAT IPv6 n'a rien à voir avec le NAT IPv4; voir ma réponse au dessus ou http://www.bortzmeyer.org/6296.html.

            En fait il suffit d'utiliser du stateless de mettre plusieurs routeur annonçant leur route, chaque interface va prendre plusieurs IPv6 sur chaque routeur et déterminera sa passerelle … Pour l'instant la détermination se fait au hasard (dernière adresse prise) mais on pourrait très bien faire intervenir le ping ou un protocole de routage pour déterminer le meilleur accès.

            Non, tu peux indiquer des préférences (encore heureux).

            Le top serait de prendre une route par défaut puis de tester chaque destination et d'allonger la table de routage du pc en fonction des destinations (tel prefixe plus court par tel fai, tel autre etc…)

            Encore non. C'est le travail d'un protocole de routage ça. Ça n'est pas à ton routeur de faire des tracesroute à tout va pour chaque paquet.

            Le NAT c'est bon pour créer des goulets d'étranglements : VIVE le vrai réseau

            Toujours Non. Voir ce qu'est le nat IPv6 et son fonctionnement.

          • [^] # Re: Free as a bird

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

            En fait il suffit d'utiliser du stateless de mettre plusieurs routeur annonçant leur route, chaque interface va prendre plusieurs IPv6 sur chaque routeur et déterminera sa passerelle …

            Ouais, génial, je n'attendais que ça : des machines avec autant d'IP que j'ai de FAI, des emm…es en perspective lorsque le routeur perd sa connexion WAN mais envoie toujours des RA sur le LAN, etc. Chaque jour, je suis un peu plus persuadé qu'en fait, SLAAC, saylemal !

            Le top serait de prendre une route par défaut puis de tester chaque destination et d'allonger la table de routage du pc en fonction des destinations (tel prefixe plus court par tel fai, tel autre etc…)

            Et on appellerait ça… BGP¹ ! Non, sans rire, ça va être top moumoute de déboguer un problème réseau avec chaque machine qui se fait sa table de préfixes dans son coin. Trop bien.

            Les gars, heu… on pourrait revenir sur terre, là ? IPv6 était censé nous simplifier la vie. Là, on a déjà des ennuis à cause de SLAAC qui ne passe pas sur des préfixes plus petits qu'un /64, DHCPv6 qui ne distribue pas le routeur par défaut (apparemment, quelque chose a été fait de ce côté-là), dhcpd qui ne marche pas sur les liens point-à-point, IPV6CP qui ne distribue pas d'adresse globale comme le fait IPCP… Si c'est pour en plus rajouter des machins qui vont avoir pour effet de rendre les choses plus complexes, c'est pas la peine. Moi, je propose déjà qu'on attende d'avoir un dhcpd qui offre les mêmes fonctions que son pendant v4 histoire de pouvoir faire une transition à peu près tranquille. La suite, on verra un peu plus tard, mmmh ?

            ¹ Bon, en fait ça ressemblerait plus à une sorte d'ip sla monitor automatisé (pour ceux qui connaissent Cisco)

            Envoyé depuis mon PDP 11/70

            • [^] # Re: Free as a bird

              Posté par  . Évalué à 2.

              Ouais, génial, je n'attendais que ça : des machines avec autant d'IP que j'ai de FAI, des emm…es en perspective lorsque le routeur perd sa connexion WAN mais envoie toujours des RA sur le LAN, etc. Chaque jour, je suis un peu plus persuadé qu'en fait, SLAAC, saylemal !

              Je ne sais plus quelle RFC dit qu'il ne faut pas que ton routeur envoie de RA s'il n'a pas de connexion upstream.

              Là, on a déjà des ennuis à cause de SLAAC qui ne passe pas sur des préfixes plus petits qu'un /64,

              Bah forcément, l'algo n'a pas été fait pour. Et faire moins que /64, à part pour des cas très spéciaux, c'est pas bien.

              DHCPv6 qui ne distribue pas le routeur par défaut (apparemment, quelque chose a été fait de ce côté-là),

              De toutes façons c'est fait en RA (oui, on va devoir avoir RA + DHCPv6 de toutes façons).

              dhcpd qui ne marche pas sur les liens point-à-point,

              Ya un patch qui tourne il me semble.

              IPV6CP qui ne distribue pas d'adresse globale comme le fait IPCP

              Bah, ça n'est pas essentielle à une connexion PPP.

              Si c'est pour en plus rajouter des machins qui vont avoir pour effet de rendre les choses plus complexes, c'est pas la peine.

              C'est plus complexe parce que tu n'as pas qu'une seule adresse à gérer. Forcément, il faut un tout petit peu plus de boulot que quand on NAT.

              Moi, je propose déjà qu'on attende d'avoir un dhcpd qui offre les mêmes fonctions que son pendant v4 histoire de pouvoir faire une transition à peu près tranquille. La suite, on verra un peu plus tard, mmmh ?

              Bon, c'est clair qu'il reste des trucs pas tout à fait au point, mais on n'avancera jamais si personne ne s'y met.

              • [^] # Re: Free as a bird

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

                Je ne sais plus quelle RFC dit qu'il ne faut pas que ton routeur envoie de RA s'il n'a pas de connexion upstream.

                Et combien de routeurs (surtout parmi les modèles grand public) respectent vraiment les RFC ? La dernière fois que j'avais lu un article sur la question, ce n'était pas glorieux. Et c'est sans compter les bugs…

                Et faire moins que /64, à part pour des cas très spéciaux, c'est pas bien.

                Le « cas très spécial » étant que ton FAI te fournit juste un /64. À mon avis, ça risque d'être un cas très répandu (cf. Free, mais aussi tous les serveurs dédiés, par exemple, qui peuvent avoir besoin d'utiliser des sous-réseaux pour des groupes de VM, des concentrateurs VPN, etc.).

                De toutes façons c'est fait en RA (oui, on va devoir avoir RA + DHCPv6 de toutes façons).

                Si la route par défaut peut être donnée par DHCP, je ne mettrai certainement pas SLAAC en sus sur mes réseaux. Pourquoi faire compliqué quand on peut faire simple et connu ?

                Ya un patch qui tourne il me semble.

                Un patch qui n'a pas encore été appliqué upstream. Désolé, mais je ne suis pas trop chaud pour recompiler des trucs comme dhcpd avec des patches non maintenus sur un serveur de production.

                Bah, ça n'est pas essentielle à une connexion PPP.

                Tu plaisantes ? La machine connectée via PPP peut vouloir être joignable. Et pour ça, elle a besoin d'une adresse globalement routable. Et pour lui en attribuer une, il faut soit IPV6CP (raté), SLAAC (/cf./ ci-dessus la limitation qui tue pour les préfixes > /64) ou DHCP (pas de patch officiel). FAIL.

                C'est plus complexe parce que tu n'as pas qu'une seule adresse à gérer. Forcément, il faut un tout petit peu plus de boulot que quand on NAT.

                Non, c'est faux. Un pare-feu à maintien d'état se configure aussi vite qu'un NAT (et même plus facilement, tu fais juste tes FORWARD et pas les DNAT). Ce qui rend la chose casse-pieds, c'est les FAI pas cool qui ne te donnent pas un préfixe suffisant, les nouveautés conçues avec les pieds (SLAAC) et les trucs à moitié finis (DHCPv6). Et je le redis, pas besoin d'en rajouter comme le fait le monsieur à qui je réponds en proposant des machines qui se font des tables de routage dynamiques.

                Bon, c'est clair qu'il reste des trucs pas tout à fait au point, mais on n'avancera jamais si personne ne s'y met.

                Moi, je « m'y suis mis » (chez moi) depuis que mon FAI (Nerim) a fourni du dual-stack. Je ne pense pas être en retard. En revanche, en entreprise, pas question d'expérimenter avec des machins pas matures. Soit on donne les outils pour une transition simple, soit ça attendra.

                Envoyé depuis mon PDP 11/70

                • [^] # Re: Free as a bird

                  Posté par  . Évalué à 3.

                  Et combien de routeurs (surtout parmi les modèles grand public) respectent vraiment les RFC ?

                  Je m'y attendais à celle-là. Si tu pars de ce postulat, effectivement, rien ne va marcher.

                  Le « cas très spécial » étant que ton FAI te fournit juste un /64. À mon avis, ça risque d'être un cas très répandu (cf. Free[…])

                  C'est ton FAI qui fait de la merde. Je ne comprends pas pourquoi Free casse à ce point IPv6 alors qu'ils se veulent pionnier.

                  Si la route par défaut peut être donnée par DHCP, je ne mettrai certainement pas SLAAC en sus sur mes réseaux. Pourquoi faire compliqué quand on peut faire simple et connu ?

                  Il me semble qu'on peut effectivement l'envoyer par DHCP. Par contre, je ne suis pas sûr qu'une requête DHCPv6 soit envoyée si le SLAAC ne « répond pas » (bon, d'un côté, ça serait un peu con ; mais je n'ai jamais testé de tel setup). Après, quand tu parles de « simple et connu », DHCPv6 ça n'est pas simple, et pour l'instant ça n'est pas utilisé des masses il me semble, en tous cas comparé à SLAAC.

                  Un patch qui n'a pas encore été appliqué upstream. Désolé, mais je ne suis pas trop chaud pour recompiler des trucs comme dhcpd avec des patches non maintenus sur un serveur de production.

                  Ça va arriver bientôt. Oui, ça n'est pas normal d'avoir tant de retard, mais je suis un peu la liste, et ça fait à peine 6 mois qu'on commence à voir le nombre d'utilisations de DHCPv6 décoller.

                  Tu plaisantes ? La machine connectée via PPP peut vouloir être joignable. Et pour ça, elle a besoin d'une adresse globalement routable. Et pour lui en attribuer une, il faut soit IPV6CP (raté), SLAAC (/cf./ ci-dessus la limitation qui tue pour les préfixes > /64) ou DHCP (pas de patch officiel). FAIL.

                  Ça a été refusé par l'IETF dans IPV6CP parce que ça ferait redondant avec DHCPv6 (qui marche également sur du non-point à point, c'était l'argument contre — plutôt poussé par Cisco, il me semble), le SLAAC tu peux très bien le faire sur un lien PPP en /64, et DHCPv6, bah, c'est la manière recommandée par une RFC qui a à peine un an.

                  Non, c'est faux. Un pare-feu à maintien d'état se configure aussi vite qu'un NAT (et même plus facilement, tu fais juste tes FORWARD et pas les DNAT).

                  Je vois pas le rapport avec ce que je disais. Oui, un pare-feu se maintien plus facilement.

                  Ce qui rend la chose casse-pieds, c'est les FAI pas cool qui ne te donnent pas un préfixe suffisant, les nouveautés conçues avec les pieds (SLAAC) et les trucs à moitié finis (DHCPv6).

                  Pour les FAI, oui c'est clair, mais c'est pas comme si ça avait été répété des centaines de fois et que Free disent juste « on s'en branle » : c'est sûr qu'avec ce comportement, ça va faire avancer les choses. Pour les nouveautés « conçues avec les pieds », c'est plutôt que beaucoup de gens ont freiné pour les options dans les RA, peut-être par peur d'un truc qu'ils ne connaissent pas, et du coup, après, bien trop tard, ça a été intégré dans les RFC pour DHCPv6. Mais c'est encore assez récent.

                  Moi, je « m'y suis mis » (chez moi) depuis que mon FAI (Nerim) a fourni du dual-stack. Je ne pense pas être en retard. En revanche, en entreprise, pas question d'expérimenter avec des machins pas matures. Soit on donne les outils pour une transition simple, soit ça attendra.

                  Bah justement, à ce séminaire, j'ai vu des boîtes qui te proposent des jolis trucs qui marchent bien, si t'as envie de ça. Le libre traîne un tout petit peu, mais ça arrivera.

  • # 114ème lancement officiel d'IPv6

    Posté par  . Évalué à 3.

    lancement officiel et définitif d'IPv6

    J'aime beaucoup. C'est la première fois qu'on fait une journée IPv6 ou un lancement d'IPv6 dans les 10 dernières années, c'est clair. Mais bon si l'ISOC dit que celui-ci est définitif, c'est sûrement vrai. ;-)

    Aller, va, on finira bien par s'en servir quand même d'IPv6 (je veux dire à grande échelle).

    • [^] # Re: 114ème lancement officiel d'IPv6

      Posté par  . Évalué à 3.

      Tu as des liens vers ces autres lancements?

      « 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: 114ème lancement officiel d'IPv6

      Posté par  . Évalué à 1.

      Heu. Le dernier événement en date, et premier (à ma connaissance) vrai événement de déploiement d'IPv6 à grande échelle était le http://www.worldipv6day.org/. Plusieurs centaines de fournisseurs (et pas des moindre) y ont participé (de mémoire c'est suite à cet événement que la Société Française de Radiophonie dont on parlait plus haut a activé IPv6 par exemple; me corriger si je me trompe).

      Toutefois cet événement n'avait qu'une visé temporaire: activer IPv6 pendant quelques jours pour voir comment le réseau allait se comporter, et comment allait réagir les clients mal configurés ou connectés via des tunnels foireux.

      Aujourd'hui l'ISOC propose de réunir ces mêmes acteurs, mais cette fois de pousser un déploiement définitif. Regardes la liste sur http://www.worldipv6launch.org/participants/ ça te donnera une idée de l'ampleur de l'initiative (et cette liste est partielle ; ils ne listent pas les tout petits réseaux; à tord ou à raison d'ailleurs…)

  • # Présentation pour FDN

    Posté par  . Évalué à 9.

    C'est encore à confirmer, mais je ferai peut-être un « témoignage » pour FDN lors de ce séminaire. Pour rappel, on propose de l'IPv6 depuis début 2009 https://linuxfr.org/news/lipv6-d%C3%A9barque-chez-fdn (activé par défaut pour tout le monde depuis juin dernier) et toujours avec des nouveautés à venir, pour bientôt, j'espère.

  • # Fournisseurs de service

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

    Et à quand Linuxfr en ipv6 ? :D

    • [^] # Re: Fournisseurs de service

      Posté par  . Évalué à 2.

      C'est toujours la même réponse : linuxfr est hébergée par la Fondation Free, qui ne propose pas d'IPv6… ce qui est très dommage pour une boîte qui se veut à la pointe là-dessus. En tous cas, administrateurs de linuxfr, ça n'est pas en attendant qu'ils vous le proposent que ça va les faire bouger : faudrait peut-être leur demander de manière un peu plus insistante (oui, je sais, hébergement gracieux, pas gueuler, toussa).

      • [^] # Re: Fournisseurs de service

        Posté par  . Évalué à 2.

        Peut être est ce inutile d'attendre un accès natif: http://tunnelbroker.net/

      • [^] # Re: Fournisseurs de service

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

        Honnêtement, il faudrait surtout qu'un admin ait envie de s'y coller… Et la fondation Free peut fournir de l'IPv6.

        Dans l'immédiat, on a fini par traiter le souci noyau sur le second serveur, ça ouvre des perspectives.

        • [^] # Re: Fournisseurs de service

          Posté par  . Évalué à 2.

          Honnêtement, il faudrait surtout qu'un admin ait envie de s'y coller…

          Perso, je veux bien m'y coller, bien que je ne sois pas admin.

          Et la fondation Free peut fournir de l'IPv6.

          Ça c'est nouveau, je ne savais pas. Tant mieux.

          Dans l'immédiat, on a fini par traiter le souci noyau sur le second serveur, ça ouvre des perspectives.

          Mmhh… si tu le dis (j'avoue que je ne sais pas de quoi tu parles).

          Un des éventuels soucis, aussi, c'est la compatibilité du site lui-même, en rails ; il faudrait demander à Nono. Normalement, si rien de spécifique à l'IP n'est touché, je suppose que ça doit marcher sans trop de problèmes. Après, j'ai souvenir de l'ancien linuxfr qui gardait des sessions séparées par IP ; je ne retrouve pas ça dans le nouveau.

          Après un rapide coup de grep dans les sources, le seul endroit où on utilise une IP, pour les votes, est fait (il me semble ; j'y connais pas grand chose à ruby) de manière assez générique pour gérer les deux versions du protocole. Par contre, je vois un bon moyen d'abuser du système de vote limité à une voix par IP… (oui, c'est le problème en général pour IPv6 : il y a de grandes discussions en cours sur quel taille de préfixe blacklister pour le spam, en particulier)

          • [^] # Re: Fournisseurs de service

            Posté par  . Évalué à 3.

            (oui, c'est le problème en général pour IPv6 : il y a de grandes discussions en cours sur quel taille de préfixe blacklister pour le spam, en particulier)

            Une proposition avait été faite à ce sujet : les ISP fournissant IPv6 devraient indiquer la taille du préfixe attribué à chaque utilisateur final, dans le whois.

            Bon, on dirait qu'ils s'en foutent tous, Free y compris. Et c'est les mêmes qui ne vont pas activer IPv6 sur leurs serveurs SMTP à cause de la difficulté à blacklister le spam..

            La lenteur de mise en place d'IPv6, et ce genre de détails, me donnent l'impression qu'on est vraiment sorti du bel esprit coopératif qui a fondé Internet. J'ai peur pour l'avenir du réseau si les FAI se mettent à adopter automatiquement l'attitude "Ceci pourrait aider à lutter contre le spam de nos lusers, mais ça ne nous apporte rien, donc on ne le fait pas."

            THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

            • [^] # Re: Fournisseurs de service

              Posté par  . Évalué à 3.

              C'est marrant, j'ai essayé de retrouver le thread qui en parlait chez FDN, et il était initié par… toi :-)

              Une proposition avait été faite à ce sujet : les ISP fournissant IPv6 devraient indiquer la taille du préfixe attribué à chaque utilisateur final, dans le whois.

              Le contre-argument à ça, si je me rappelle bien, c'était que ça incite encore plus les gens à blacklister, puisqu'ils ont maintenant une « indication », alors que derrière il peut y avoir plein de raisons pour lesquelles on peut avoir un paquet d'utilisateurs différents. Bref, c'est souvent décriés par ceux qui sont contre le principe de blacklist en général.

              Bon, on dirait qu'ils s'en foutent tous, Free y compris. Et c'est les mêmes qui ne vont pas activer IPv6 sur leurs serveurs SMTP à cause de la difficulté à blacklister le spam..

              Ça c'est le deuxième problème de ce système : si quasi-personne ne le fait, effectivement, ça ne servira pas à grand chose.

              La lenteur de mise en place d'IPv6, et ce genre de détails, me donnent l'impression qu'on est vraiment sorti du bel esprit coopératif qui a fondé Internet. J'ai peur pour l'avenir du réseau si les FAI se mettent à adopter automatiquement l'attitude "Ceci pourrait aider à lutter contre le spam de nos lusers, mais ça ne nous apporte rien, donc on ne le fait pas."

              Ça montre qu'IPv6 ne s'est pas encore frotté à toutes les « merdes » de la pratique, en effet. Sur l'attitude coopérative, ça n'est aussi pas bon signe. Mais à mon avis, on peut trouver des solutions pour qu'IPv6 marche même sans ça.

              • [^] # Re: Fournisseurs de service

                Posté par  . Évalué à 6.

                C'est marrant, j'ai essayé de retrouver le thread qui en parlait chez FDN, et il était initié par… toi :-)

                À l'origine c'était mentionné sur FRnOG par Bortzmeyer mais je ne m'arrive pas à retrouver son message.

                Le contre-argument à ça, si je me rappelle bien, c'était que ça incite encore plus les gens à blacklister, puisqu'ils ont maintenant une « indication », alors que derrière il peut y avoir plein de raisons pour lesquelles on peut avoir un paquet d'utilisateurs différents.

                Si y'a un paquet d'utilisateurs différents qui ne sont pas sous la même "autorité" c'est que quelqu'un, quelque part, a merdé. Par exemple, a utilisé une seule connexion et foutu du NAT derrière. L'idée c'est justement de déclarer dans le whois "j'ai telle taille de bloc pour un même luser final", si c'est mal déclaré ou que le luser refourgue à 100 sites différents le même bloc, le caca n'est pas le fait de celui qui blackliste.

                Après, tu peux avoir 200 personnes sur un réseau d'entreprise dans le même bloc : en cas de blacklistage, les 200 vont hurler sur l'équipe d'admin du site, l'équipe d'admin du site va trouver la cause du problème et la résoudre. Ça reste cohérent (dans le sens où y'a une personne ou une équipe responsable dans ton bloc).

                Bref, c'est souvent décriés par ceux qui sont contre le principe de blacklist en général.

                Pour schématiser, je vois trois solutions (qui peuvent être mélangées) aux problèmes de spam/flood/attaque/bruteforce.. sur Internet :

                • La solution légale, on va demander des comptes au responsable de l'@IP d'origine. S'il est utilisateur final il prend pour son grade. S'il est intermédiaire technique (ça peut être un particulier, surtout en IPv6) il donne ses logs et on remonte la piste. Au final, on retombe soit sur un pays ou un ISP qui en a rien à tamponner de la pollution sur Internet (dans ce cas, tu peux passer à la solution 2 avec ses @IP), soit sur un vrai méchant (qui loue un dédié pour volontairement spammer/attaquer), et c'est une bonne idée de le condamner (pas juste fermer son serveur et qu'il en rouvre un deux jours plus tard ailleurs), soit sur un imbécile qui a installé un jeu cracké avec un troyen, et pour lequel il n'y a aucune raison non plus de le laisser emmerder le reste du monde (l'ignorance comme bouclier ça va 5 minutes),

                • La solution "cowboy", on emmerde les fauteurs de trouble en leur renvoyant le problème. Le blacklistage c'est typiquement ça : t'enverras pas de mails tant que y'aura une machine chez toi qui envoie du spam. Coût de traitement minimal pour la victime du spam, retour des emmerdes à l'envoyeur. Le problème c'est que ça coince les intermédiaires techniques s'ils ne peuvent pas rendre visible la différence entre leurs utilisateurs.. Free a eu ce problème avec ses abonnés ADSL, qui sont tous déclarés en spammeur sur je sais plus quelle RBL, parce que "dans le tas" y'a des cons qui spamment.

                • La solution débile, celle adoptée par la majorité : la victime des emmerdes utilise de l'énergie intellectuelle, du temps CPU et de la bande passante pour trier les spams, absorber les attaques, renforcer son système, parce qu'on considère comme "inévitable" qu'Internet soit un merdier immonde. Le problème, c'est que cette politique renforce énormément l'intérêt des plateformes qui centralisent (du type Facebook/Youtube/Twitter..) en proposant aux gens lambdas un "lieu sécurisé" dans lequel le maître des lieux va assurer sa police privée, virer les spammeurs.. et censurer ce qui ne lui plaît pas. Alors que vouloir assurer soi-même le service Internet (mail, hébergement..), c'est commencer par devoir construire un château fort sur la couche réseau afin de ne pas se faire emmerder.

                Après je suis conscient que cette vision des choses ne fait pas l'unanimité. Mais pour ma part j'aimerais pouvoir conseiller aux gens de "juste faire" "aptitude install postfix apache2" quand ils aimeraient savoir comment s'auto-héberger, sans qu'ils aient à passer l'étape du "et maintenant t'as 2H de config pour l'antispam sur tes mails et sur ton blog, fais gaffe y'en a tjs qui passe à travers."

                THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

                • [^] # Re: Fournisseurs de service

                  Posté par  . Évalué à 5.

                  L'idée c'est justement de déclarer dans le whois "j'ai telle taille de bloc pour un même luser final", si c'est mal déclaré ou que le luser refourgue à 100 sites différents le même bloc, le caca n'est pas le fait de celui qui blackliste.

                  Tu juges un peu vite à mon avis. Ce genre de question, de quelle est la légitimité de la personne à mettre pleins de gens derrière son préfixe ou pas, répartis en telle forme d'autorité, c'est la question centrale à étudier. Elle n'est pas évidente du tout, et dire « il n'a qu'à se conformer à ce modèle, point », c'est un peu autoritaire, je trouve. IPv6 permet tout un tas de types d'adressages, dont certains qu'on n'a encore sûrement pas étudié, et ça change pas mal le modèle de responsabilité « une IP = une personne responsable » d'IPv4.

                  Après, je n'ai pas de solution sous la main, alors forcément, ça ne fait pas beaucoup avancer le schmilblick. Je suis aussi pour un modèle de responsabilitation des gens, mais dans certaines limites, que je n'arrive pas bien à définir.

                  Pour schématiser, je vois trois solutions (qui peuvent être mélangées) aux problèmes de spam/flood/attaque/bruteforce.. sur Internet :

                  La solution légale,

                  Oui, c'est la solution bisounours, mais ça serait quand même bien qu'on s'appuie un peu plus souvent dessus quand on a la possibilité, parce qu'à ne jamais l'employer elle va devenir insignifiante.

                  La solution "cowboy",

                  Oui, beaucoup de monde continuera à l'employer, mais j'aimerais bien qu'elle soit vraiment limitée. Plus on favorisera à aller dans ce sens là, plus les autres en face utiliserons de nouvelles méthodes. C'est le chat et la souris : ne courrons pas trop vite, de toutes façons on se fera rattraper.

                  La solution débile,

                  C'est débile, certes, mais ça ne marche « pas trop mal ». Et le fait d'amener les gens vers les plateformes centralisées… je ne suis pas sûr que ça marche vraiment : ils retrouvent des spammeurs là-bas aussi, sauf qu'ils sont « légaux »… Vis à vis de la perception des gens, ça ne change donc pas grand chose.

                  Mais pour ma part j'aimerais pouvoir conseiller aux gens de "juste faire" "aptitude install postfix apache2" quand ils aimeraient savoir comment s'auto-héberger, sans qu'ils aient à passer l'étape du "et maintenant t'as 2H de config pour l'antispam sur tes mails et sur ton blog, fais gaffe y'en a tjs qui passe à travers."

                  Moi aussi. Mais pousser des solutions qui peuvent se retourner contre nous plus tard (éventuellement), ça n'aide pas.

                • [^] # Re: Fournisseurs de service

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

                  La solution légale, on va demander des comptes au responsable de l'@IP d'origine

                  As-tu vraiment envie d'aller fouiller des Whois et écrire à des abuse@ qui n'en ont le plus souvent rien à carrer pour chacun des débiles/bots qui font un portscan chez toi ? À l'époque (il y a une dizaine d'années), il y avait encore suffisamment peu de monde (tout est relatif) pour que ça vaille le coup, mais c'était déjà assez aléatoire. Aujourd'hui, honnêtement, je n'ai plus le temps : j'ai arrêté (c'était ça, ou je ne pouvais plus troller sur DLFP. Le choix a été vite fait). Le pare-feu/antispam, ça se configure une fois et c'est fini.

                  S'il est utilisateur final il prend pour son grade. S'il est intermédiaire technique (ça peut être un particulier, surtout en IPv6) il donne ses logs et on remonte la piste.

                  Demander des comptes, en prendre pour son grade, remonter la piste… Certes, inspecteur ;-) Mais si l'intermédiaire technique est un nœud de sortie TOR ? On fait quoi ? On le condamne pour avoir transmis sans le savoir le trafic d'un bot/spammeur ? Moi, dans le contexte actuel, je ne souhaite pas plus de traçabilité pour les utilisateurs du Net, et de responsabilité pour les intermédiaires. Bien au contraire (et je suis sérieux, je ne trouve pas le prix à payer si terrible).

                  Envoyé depuis mon PDP 11/70

                  • [^] # Re: Fournisseurs de service

                    Posté par  . Évalué à 3.

                    As-tu vraiment envie d'aller fouiller des Whois et écrire à des abuse@ qui n'en ont le plus souvent rien à carrer pour chacun des débiles/bots qui font un portscan chez toi ?

                    Il en a envie, il le fait et il a raison.

                    Le pare-feu/antispam, ça se configure une fois et c'est fini.

                    Sans compter tous les faux positifs, les faux négatifs, les vrais positifs et les vrais négatifs (qui est quoi, je ne sais jamais).

                    Pourquoi ne pas faire un script qui écrit un mail à abuse@ automatiquement ?

                    Mais si l'intermédiaire technique est un nœud de sortie TOR ? On fait quoi ?

                    Les connexions viennent de lui, son initié par lui (plus ou moins contre son gré, certe, mais par lui) il est donc utilisateur final.

                    • [^] # Re: Fournisseurs de service

                      Posté par  . Évalué à 2.

                      Les connexions viennent de lui, son initié par lui (plus ou moins contre son gré, certe, mais par lui) il est donc utilisateur final.

                      Il peut aussi être fournisseur de service (au sens de la LCEN), auquel cas il tient des logs et ses logs permettent de remonter à un autre fournisseur de service, ou à l'utilisateur final.

                      C'est d'ailleurs le plus gros reproche que je ferais à HADOPI : cette logique est cassée, un utilisateur ne peut pas décider de prêter/louer sa connexion à quelqu'un qu'il identifie et à qui il renvoie la balle en cas de publication de contrefaçon via le service fourni. Autrement dit, et ça c'est grave, HADOPI crée une différence majeure entre la connexion d'un particulier (qui doit se plier à l'obligation de sécurisation) et celle d'un "fournisseur de service" qui peut se contenter de tenir des logs. On ne va pas couper l'accès de Youtube au bout de la troisième publication de contrefaçon, on va couper l'accès de Claude Michu. Cette différence est totalement contraire à l'esprit d'Internet, où chaque utilisateur est supposé être égal aux autres. (Cette liberté impliquant une responsabilité, évidemment).

                      THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

                    • [^] # Re: Fournisseurs de service

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

                      Pourquoi ne pas faire un script qui écrit un mail à abuse@ automatiquement ?

                      Parce que l'abuse n'en a déjà pas grand-chose à faire quand tu lui écris un courriel à la main, alors un machin automatique, je ne donne pas cher du résultat.

                      Les connexions viennent de lui, son initié par lui (plus ou moins contre son gré, certe, mais par lui) il est donc utilisateur final.

                      … ben, c'est sûr, si tu vois les choses comme ça, pas de soucis, je respecte ton opinion et te propose de postuler chez la HADOPI pour aller couper l'accès aux gens qui laissent leur WiFi ouvert dès que quelqu'un va télécharger un film depuis leur connexion, c'est peu ou prou la même chose.

                      Envoyé depuis mon PDP 11/70

                      • [^] # Re: Fournisseurs de service

                        Posté par  . Évalué à 2. Dernière modification le 11 avril 2012 à 21:59.

                        gens qui laissent leur WiFi ouvert dès que quelqu'un va télécharger un film depuis leur connexion,

                        Sans oublier McDonalds, hôtels, et autres points d'accès plus ou moins à la one again…

                      • [^] # Re: Fournisseurs de service

                        Posté par  . Évalué à 3.

                        je respecte ton opinion et te propose de postuler chez la HADOPI pour aller couper l'accès aux gens qui laissent leur WiFi ouvert dès que quelqu'un va télécharger un film depuis leur connexion

                        Tu respecte mon opinion mais tu cherche à me décrédibilisé, c’est beau !

                        Bref, 2 choses :

                        • on considère qu’être nœud de sortie TOR c’est être fournisseur d’accès : tu maintiens de logs sont t’es dans l’illégalité ;
                        • on considère qu’être nœud de sortie TOR ce n’est pas être fournisseur d’accès : tu es utilisateurs final, c’est sur toi qu’on tape.

                        Perso, je suis plus tenté de dire que c’est la seconde solution qui est correcte puisque TOR est fait pour préserver anonymat et que les personnes hébergeant des nœud sont généralement des militants qui savent ce qu’ils risquent.

                        • [^] # Re: Fournisseurs de service

                          Posté par  . Évalué à 2.

                          J'ajoouterais que la perception qu'on a de ces problématiques est totalement faussée par le climat délétère qui règne actuellement sur Internet : lois liberticides pour empêcher la remise en cause du droit d'auteur, lois liberticides qui prennent le terrorisme ou la pédopornographie comme prétextes pour surveiller la population, et de l'autre côté laisser-aller total sur le spam, y compris émis par des entreprises françaises (SFR, France Creance..), depuis des @IP françaises, à destination d'internautes français.

                          Si on y ajoute la politique de "chacun pour soi" de la plupart des opérateurs, qui d'un côté prennent des mesures de rétorsion assez violentes contre les agressions extérieurs ( https://linuxfr.org/users/nh2/journaux/free-jai-rien-compris ), de l'autre ont tendance à laisser faire leurs propres abonnés parce que c'est rentable (cf OVH qui s'en fout d'être un nid à spam-DDOS-etc..), ou alors qui appliquent des mesures délirantes contre eux (Orange qui bloque le port 25 sans possibilité de déblocage..).

                          Tout est fait pour traiter l'internaute comme un enfant, il n'y a aucun traitement judiciaire sérieux. On se contente, d'une part de lui taper sur les doigts officieusement en cas de problème ou à titre préventif, d'autre part on s'en fout de respecter son droit à ne pas être spammé/surveillé/etc.. c'est logique que la plupart des gens, y compris militant pour un usage responsable d'Internet, soient à priori en faveur d'un anonymat et d'une dé-responsabilisation plus grands (foutus pour foutus, autant être libres), et pas d'un retour à un état de droit, y compris sur Internet. Mais, AMHA c'est une mauvaise réaction.

                          THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

            • [^] # Re: Fournisseurs de service

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

              Une proposition avait été faite à ce sujet : les ISP fournissant IPv6 devraient indiquer la taille du préfixe attribué à chaque utilisateur final, dans le whois.

              Sauf qu'un FAI peut très bien donner un /56 à un client résidentiel, et un /48 à un pro (par exemple) depuis le même /32. Il marque quoi dans ce cas-là ? Ou alors, on fait comme en v4 et on demande au FAI d'indiquer le client final dans le Whois pour chaque préfixe octroyé (et personne ne le fera, comme ils ne le font déjà pas en v4)…

              Envoyé depuis mon PDP 11/70

Suivre le flux des commentaires

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