Florent Fourcot a écrit 398 commentaires

Bim, pris en flagrant délit de contresens, j'ai honte (m'apprendra à écrire "de mémoire lu y'a trois mois").

Il reste qu'ils ne garantissent pas l'IP fixe, et que ça restera une option payante pour les entreprises. Si quelqu'un ne souhaite pas d'IP fixe, il lui suffit de couper son routeur "suffisamment longtemps".

Et un martIP au shaker, pas à la cuillère.

> Il présuppose de la façon dont va être mise en place la v6 par les acteurs du net.

Je présuppose surtout que l'IPv6 n'a aucune raison d'être mise en place de façon différente que l'IPv4. Des FAI fournissent des IP statiques, d'autres des dynamiques, et je suis persuadé que cela continuera. Mais je ne suis pas monsieur soleil, cela est clair.


> Deuxièmement, il s'arrête à un instant T de la situation actuelle sans prendre en compte le chemin que prend le net actuellement.

Ça m'intéresse de savoir "le chemin que le net prend actuellement.". Et les conséquences sur le sujet. Mon but n'est pas de dire que je détiens la vérité, mais d'en discuter :-)


> Trois, il diffuse en filigrane l'idée que puisque nous sommes déjà pisté, un peu plus ou un peu ce n'est pas grave.

Que nous sommes déjà en situation d'être pisté me semble évident. Que nous le sommes en partie, aussi. Que ce n'est pas grave, ce n'est certainement pas mon propos. Je dis juste que quelqu'un qui souhaite réellement être anonyme doit passer par des applications spécialisées, et que la version du protocole IP n'y changera rien.

Effectivement, +problèmes.

La phrase deviendrait : "L'introduction de l'IPv6 peut poser des problèmes d'architectures à ces réseaux."

Outre les réponses "blagues", de telles idées existent. Cela s'appelle les HIP, et permet de contacter quelqu'un uniquement avec un identifiant. En dessous, y'a de la cryptographie à clef publique pour certifier à qui tu parles. Il y a beaucoup de RFC qui en parlent, alors je te conseille le très bon résumé ici : http://www.bortzmeyer.org/hip-resume.html

C'est bien évidemment le genre de trucs qui ne marchent qu'avec la dernière version du protocole IP :-)

> - les questions graves sur la vie privée

FOUTAISES

> Oui... ou alors on verra fleurir des abonnements /128, des /127 et cie jusqu'à /64 en fonction du prix que tu mets.

Ce qui ne serait pas conforme aux RFC.

Et vu le nombre d'IPv6 disponibles, un FAI n'aurait vraiment aucune raison de le faire. Hormis emmerder les usagers.

Ces services passeront probablement à un filtrage par préfixe, ce qui n'est pas si galère que ça (et tant pis pour les dégâts collatéraux...).

J'ai pas dit qu'il existait des avantages, juste que ce sera aux différents FAI de choisir leurs politiques.

L'avantage des IPs dynamiques, ça pourrait être de faire chier les gens qui tentent d'héberger du contenu chez eux. Ça peut être un critère pour certains FAI (il y a Internet, et Internet...). Ils peuvent aussi le faire par peur de la paranoïa des utilisateurs, qui exerceront une pression pour que leurs IPs changent.

> Oui je comprends, mais je ne vois pas pourquoi on a besoin d'une RFC pour ça.

Parce que sinon, c'est le bordel. Faut bien gérer les histoires de doublons, de durée de vie, de compatibilité avec l'existant.

> mieux vaut passer par un proxy

Si tu veux être anonyme, ne passe pas par un proxy. Mais par des chaînes de proxy (ou par tor), genre ça : http://anon.inf.tu-dresden.de/index_en.html

Les proxys c'est vraiment le niveau zéro d'anonymat. Soit tu contrôles le serveur, est t'es au mieux dans un ensemble de connaissances qui utilisent ton proxy, soit tu ne le contrôle pas et l'administrateur connaît l'ensemble de tes actions.
Le nettoyage de ton navigateur n'est pas si simple, car pour éviter les empreintes il faut au contraire se mêler aux plus nombreux (et quelqu'un avec flash et java désactivé, n'est pas dans les plus nombreux...).

> Parce que c'est quand même parier sur la bonne volonté des FAI pour nous fournir une plage d'adresse ip.

Ils vont être obligés de te fournir un préfixe d'au moins de taille /64, sinon tu ne pourra connecter qu'une seule machine. Donc je ne m'en fais pas trop, ils seront de bonne volonté.

Concernant Tor, le passage à l'IPv6 n'est pas trivial. En fait, pour maintenir la cohérence du réseau, il est hors de question qu'une partie du réseau Tor ne soit pas joignable par une autre. C'est bien expliqué dans leur FAQ : https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/TorFAQ#TorshouldsupportIPv6.

Tant qu'ils n'ont pas résolu le problème de façon élégante, l'IPv6 n'arrivera pas sur le réseau Tor.

> Si je me trompe pas (là, j'ai besoin de confirmation), avec IPv6 on risque très fort d'avoir des IP statiques....

Il n'y a aucune raison technique d'avoir des IP statiques à la place d'IP dynamiques, c'est au FAI de choisir sa politique d'attribution de préfixes. Si les IP dynamiques étaient au départ justifiées pour un meilleure taux d'attribution, ce n'est plus vrai avec l'apparition des offres illimitées et des box qui sont de toute façon connectée en permanence (ou au moins toute en même temps aux heures de pointes).

Pourtant, les FAI n'ont pas revus (sauf free) cette politique.


Ensuite, concernant l'IPv6 il existe les extensions de vie privée, la RFC la plus récente à ce sujet étant la 4941. Bonne nouvelle pour madame Michu, c'est activé par défaut sur le système d'exploitation qui a la majorité des parts de marché.

Donc non, je ne vois pas de risques pour la vie privée. Bien moins en tout cas que des méthodes bien plus efficaces sur les couches supérieures : http://www.eff.org/deeplinks/2010/01/tracking-by-user-agent

Le libre, c'est souvent une philosophie qui permet à l'utilisateur de configurer son logiciel. Qui permet également à l'utilisateur de définir des consommations de ressource maximales, ce genre de trucs.

Mais Skype, c'est tout l'inverse. Et c'est ce qui permet son succès, à vrai dire. En forçant les utilisateurs à se déclarer relais ou super nœud, ils ont une architecture ultra résistante. Ils se permettent aussi d'ouvrir des ports sur les NAT avec toutes les méthodes connues (UPnP notamment), genre de trucs qui habituellement ne se fait pas sans l'accord de l'utilisateur dans un logiciel libre.

Je pense vraiment que la communauté a les compétences pour programmer un logiciel équivalent. Mais que jamais on arriverait sans forcer les utilisateurs à une telle architecture.

L'autriche est donc le 17ième Länder caché de l'Allemagne ? Et la région Wallonne une annexe de la France, car c'est la même langue après tout ?

Interfaces Web. C'est le principe même de Weboob. Si tu veux plus d'informations sur l'architecture, et une réponse à ta question :

http://linuxfr.org/2010/08/06/27217.html

http://linuxfr.org/2010/11/07/27554.html

Baroin manque un peu d'imagination sur cette citation. Il ne fait que reprendre les propos de Henri Guaino (conseiller spécial à l'Élysée) qui avait déclaré après les blagues sur les auvergnats de Brice Hortefeux « La transparence absolue, c'est le début du totalitarisme ».

Oui, mais non. J'importe les QIF que ma banque accepte de bien me fournir (avec les bugs qui vont avec) environ une fois par mois. Utile pour suivre l'évolution des dépenses par catégorie, et un suivi efficace.

Cependant, aucun rapport avec boobank/weboob. Cela permet une gestion journalière du compte, de façon complètement automatique. Ton QIF à télécharger, il va pas pas t'envoyer une alerte car un compte est trop bas (un chèque donné y'a 6 mois, oublié depuis mais déposé seulement aujourd'hui ?). Et ça c'est ultra pratique, car ma banque n'est même pas capable de m'envoyer un mail pour me le signaler (alors que me faire payer un SMS surtaxé, elle sait faire). Il ne va pas te permettre non plus de faire un virement en une ligne de commande pour régler le problème.

Weboob est pour moi un énorme gain de temps. Plus besoin de se connecter sur le site web de ma banque, de me battre avec leur matrice "sécurisée" ou mon voisin peut lire derrière mon épaule. Cela n'a pas d'équivalent actuellement pour ce que j'en sais. Même parmi les "services en ligne". Weboob en réalité permet de faire ce que d'autres banques permettent nativement : http://en.wikipedia.org/wiki/FinTS

Avec ça, tu peux télécharger tes comptes directement depuis n'importe quel logiciel de compta. Et automatiser le processus. Sauf que le FinTS, c'est pas près d'arriver en France.

> Arrêtez de cracher sur un produit que vous n'avez même pas en main.

Je ne sais pas si tu as bien lu mon commentaire, mais une grosse partie de ma critique était justement sur le temps de livraison. Livrer en plus de 5 mois un produit annoncé livré en 15 jours, en débitant immédiatement le prix de la commande, c'est pour moi une façon scandaleuse de faire. Et refuser une annulation de commande dans des conditions pareilles (changement de produit + de délais) également. Le plus frustrant était probablement l'absence complète de communication (ils ne répondent pas aux mails, pas au téléphone...).

Le produit avec un ventilateur est peut-être un bon produit. Mais ce n'est pas ce que j'ai commandé.

Ma conclusion est la même que mon commentaire précédent, j'espère bien réussir à en faire quelque chose (d'autant que j'en ai acheté deux, un pour un ami et un pour moi). Et en mettant les doigts dans les câbles (en commençant par débrancher ce ventilateur). Mais je ne suis pas prêt d'oublier la façon dont globalscale traite ses clients.

Comme toi, je suis tombé dans la même arnaque. Commandé en mai (et annoncé pour 15 jours plus tard), reçu fin octobre. Entre les deux, changements de spécifications et ajout d'un ventilateur. Et impossibilité d'annuler la commande, malgré de multiples demandes (sachant que le débit sur la carte, il a été fait dès le mois de mai, forcément...).

J'ai pas encore le produit sous la main (car entre temps, j'ai eu le temps de déménager, et le truc d'arriver très loin...). Mais as-tu tenté de le "sauver" ? Remplacer le ventilateur par un autre truc ? Virer des composants inutiles ? J'ai vu notamment sur le Planet Debian des trucs comme ça : http://bzed.de//posts/2010/09/refactoring_the_guruplug_server_plus/

Malgré l'arnaque évidente de la part de GlobalScale, j'espère tout de même réussir à faire quelque chose d'utilisable avec ce truc...

> Par exemple en faisant un encodage à la utf-8 :
>les adresses existante continue d'être valide, mais on a la possibilité d'avoir de nouvelles adresses étendue.

Ce qui est dommage, c'est que l'une des grandes contraintes est d'avoir un adressage à taille fixe, pour des problèmes de perfs. Cette proposition n'aurait donc eu aucune chance de passer à l'IETF.

> Premièrement sur la compatibilité IPv4/IPv6, ça aurait été trop dur dans la norme IPv6 de dire que les 2^32 adresses possibles sont en fait IPv4 ??? (ou un autre préfixe)

C'est le principe de 6to4, pour chaque adresse IPv4, on a une bijection vers un /48 en IPv6. Sauf que ça ne change rien. Il faut toujours qu'un administrateur passe pour configurer la chose.

Le problème, c'est qu'une machine IPv4 sans configuration qui reçoit un paquet IPv6, quel qu'il soit, il ne comprend pas. Quelles que soient les solutions de transitions, il faut une mise à jour pour qu'un équipement IPv4 soit capable de reconnaître un paquet IPv6. Et ça, c'est pour les solutions simples ou chaque équipement à une IPv4 publique. Tu rajoutes les NAT au dessus de ce bazar et c'est vraiment la merde.


> Je ne suis pas du tout convaincu par l'explication du h ratio pour démontrer qu'on avait ABSOLUMENT besoin de 128bits.

Ah oui, c'est certain. On aurait pu en mettre que 64. Et prendre le risque d'être emmerdé pour plus tard. Un peu comme les adresses IPv4, qui semblaient largement suffisantes sur 32 bits... Les 64 bits de poids faible ne sont pas perdus, loin de là. L'objectif d'IPv6 est de corriger les faiblesses de v4. Parmi ces faiblesses, il y avait l'obligation de DHCP pour attribuer un nombre très limité d'IP. Avec les 64 bits pour l'identifiant d'interface, on permet de l'auto-configuration sans état. Et sans risques de collisions.

On permet aussi les privacy-extensions, en tirant au hasard une adresse, toujours avec des risques de collisions très faibles. On permet aussi les adresses cryptographiques (CGA), qui permettront de sécuriser les réseaux qui en ont besoins.

Il est certain qu'en voyant IPv6 uniquement comme de l'IPv4 avec plus d'adresses, on ne va pas progresser. Cette nouvelle architecture est loin d'être anodine, on passe d'une gestion des adresses en nombre ultra-limité à un nombre quasi-infini, d'abondance. Ce sont des habitudes à changer, et probablement de nouveaux usages à voir apparaître.


Et autre chose, c'est quoi fondamentalement le problème d'utiliser 128 bits ? Qu'est-ce qui te dérange là-dedans ? Je préfère que des précautions soient prises pour éviter de passer à IPv7 dans 20 ans...

À moitié vrai. Le AAAA est demandé en même temps que le A, et ceci depuis pas mal de temps. Donc oui ça double le nombre de requêtes, mais ça ne devrait en théorie pas ralentir. Ce que par contre j'ai constaté, sur une FRITZ!Box et un routeur dont j'ai oublié le nom, c'est ça :

t0 A example.com -> Serveur DNS
t0 AAAA example.com -> Serveur DNS

t1 example.com = X.Y.Z.W <- Serveur DNS

t2 AAAA example.com -> Serveur DNS (timeout, par défaut c'est 5 secondes sous Linux)

t3 Server fail <- Serveur DNS


Avec t1~t0 et t2~t3, de l'ordre du négligeable, une requête DNS classique. Le timeout pour le AAAA fait très mal par contre. 5 secondes de perdues, c'est énorme. Et même si on envoie les deux requêtes en même temps, on n'utilise pas la première, on attend d'avoir les deux réponses (avant c'était pire. On attendait la réponse AAAA avant de demander le A).

Le serveur DNS tout pourri qui ne sait pas gérer les AAAA répondrait simplement à la première réponse une erreur ou l'absence de champ, tout irait bien. Mais là, ne renvoyer aucun paquet, c'est un désastre (et la seule solution pour avoir une navigation correcte est dans ce cas soit de désactiver les requêtes DNS IPv6 de son navigateur, soit de changer de serveur DNS. La première est plus facile pour pas mal de gens...).

La vrai raison des ralentissements que j'ai vu, c'est pas ça. C'est plutôt les DNS qui coincent. De nombreuses box et routeurs ne savent pas renvoyer des champs AAAA, mais ton système les demande quand même. Selon le type de réponse (pas de réponse ? Un message d'erreur du serveur ?) ça peut prendre plus ou moins de temps. Et ce lag est très désagréable.

Si, en effet. J'ai donc dit une connerie :-)

Voir l'option -c de grep, si on est vraiment un fainéant.