Re: [FRnOG] [TECH] UPNP ce protocole d'avenir
On Friday 01 February 2013 00:28:46 Guillaume Barrot wrote: Admettons pour UPNP IGD, mais IPv6 en lui même ne réglera pas la problématique UPNP AV (ie présentation de services). Et pourtant, c'était prévu dans les premiers drafts IPv6 : http://tools.ietf.org/html/draft-ietf-sip-discovery-03 Auto-configuration The connection procedures for a configuring a new system are reduced to the minimal set of plug it in, turn on the power, and run. - Each node is assigned an identifier, usually within the number space assigned to the local subnet. - The node discovers the routers attached to the local subnet, so that it can exchange packets with remote systems. - The node discovers the location of servers that it needs for configuration, loading, dumping, printing, and other services. - If desired, each node is assigned a name within the local domain. The name, and the associated identifiers, can be registered in the local domain name server. Je voudrais pas m'avancer, mais il parraîtrait que certains constructeurs auraient dégagé ces éléments du standard... Bonne nuit, -- Rémy Sanchez http://hyperthese.net/ signature.asc Description: This is a digitally signed message part.
Re: [FRnOG] [MISC] Pertes et latence importantes
On Wednesday 04 January 2012 22:55:53 Michel Py wrote: Si, il y a MacDo :P On attends :3 -- Rémy Sanchez http://hyperthese.net/ signature.asc Description: This is a digitally signed message part.
Re: [HS] Re: [GLPI #0000110] Nouveau ticket Re: [FRnOG] xDSL et nerim : réseau patraque ce jour ?
On Tuesday 22 November 2011 14:59:40 Guillaume Rousseau wrote: J'ai reçu ça pour mes deux e-mails postés sur la liste, il doit y avoir un souci quelque part... d'autres dans ce cas ? Quelqu'un qui répond réellement à cette adresse ? Ou adresse à supprimer de la liste ?... J'ai aussi reçu un ticket du genre ce matin... -- Rémy Sanchez http://hyperthese.net/ signature.asc Description: This is a digitally signed message part.
Re: [FRnOG] Re: [FRnOG] Optimiser le pair-à-pair
On Wednesday 16 November 2011 05:50:12 Michel Py wrote: Rémy Sanchez a écrit: J'objecte, ce qui disent les graphes (en moyenne) : - 10% du serveur - 33% en P2P - 57% en cache Donc ok seulement 1/3 du trafic est P2P, mais en fait ça fait un bon gros 3/4 des échanges réseau quand même. Ca c'est de l'interpolation approximative sans avoir les vraies données. Tu arrives à des conclusions hâtives qui sont plus du domaine de la boule de cristal que des statistiques. Je ne dis pas que c'est faux, mais ça reste des devinettes. Regarde les chiffres: 57% viennent du cache. En anglais, on dit qu'il y a un éléphant dans la pièce et que tu ne le vois pas. Le cache de Spotify est prédictif (en anglais: read-ahead, ceux qui configurent des cartes RAID seront familiers) (pour de bonnes raisons); par exemple, 30 secondes avant qu'un morceau commence à jouer, le logiciel prédit que c'est le prochain morceau qui va jouer, et commence à charger les donnés. Il est donc facile de comprendre qu'une partie conséquente des requêtes servies par le cache n'ont été transférées dans le cache que quelques secondes avant que l'utilisateur ne les demande, ce qui est le but du cache prédictif. On lit en avance, comme ça quand le réseau à un hoquet, l'utilisateur ne s'en rend pas compte. En simplifiant à mort, la raison pour laquelle on n'a pas 95% ou 98% de cache, c'est les mecs qui zappent comme des malades. Pour citer le papier, « Most playbacks (61%) occur in a predictable sequence, i.e. because the previous track played to its end, or because the user pressed the forward button. » Et « For t = 10, 30, the next scheduled track was played in 94%, and 92% of cases, respectively » Donc dans plus de 90% des cas la musique lue provient du prefetch. Et au passage personne n'écoute sa musique en zapant comme un gogol, je veux bien prendre les gens pour des cons, mais y'a des limites... Là où tes conclusions sont du domaine de la boule de cristal, c'est que tu n'as aucune donnée qui te dit quel est le pourcentage du cache qui est rempli avec le P2P et celui qui est rempli avec le serveur (pardon, le claoude). Encore une fois, fais-moi voir des données réelles, pas du vent. P'têt ben que c'est la même chose, p'têt ben qu'non. À priori on n'a pas compris le papier pareil. Pour vérifier j'ai envoyé un mail à l'auteur, comme ça on est sûr: « With prefetching there are essentially two cases, either the prefetched track begins playing or it does not. When it plays, prefetched data is accounted for as the source it arrives from, so it is already included in the network traffic reported. When it does not, I am not 100% sure off hand if that is included or not in our measurement. This case is fairly rare however (as we show that our threshold for prefetching are such that in 92% of cases, the user does begin playback of the next track) so I would not expect it to make a difference to ballpark statistics on the order of 1/4. If you're interested in the answer also for this case as well, just ask and I'll dig a bit. » Donc à priori, les 3/4 de trafic générés par P2P ne sont pas délirants. J'aimerais bien voir les stats de Spotify en ce qui concerne la répartition intra-AS / extra-AS car jusqu'à présent j'ai rien vu de bien concret. Là ou Spotify est bon c'est sur la qualité et ne pas tuer l'upstream, mais en ce qui concerne l'optimisation du trafic... Spotify ne fait pas le tri directement en fonction de l'ASN, ils donnent une note d'utilité à chaque peer et s'en servent quand ils doivent supprimer des peers. C'est là ou je ne suis pas convaincu. Pour le FAI, ce qui compte c'est la partie qui reste à l'intérieur de son AS, rien d'autre. Oui ça je sais, je supposais juste que le mécanisme pouvait éventuellement aider, au moins un chouilla. Mais effectivement je viens de vérifier, j'ai 2 peers du même FAI à tout casser sur la cinquentaine de peers connectés. Par contre ils sont majoritairement en France. Par contre regarde le RFC 5632, Comcast a bel et bien réussi ce genre de montage. RFC5632, c'est comme IPv6. Quand plus de zéro pourcent du trafic sera optimisé par RFC5632, réveilles-moi. Entre un pair en Australie, un à Trifouilly-les-Oies (pas tellement moins loin, pour moi) et un à 50 km dans l'AS de mon FAI, je vais t'expliquer comment ça marche: la solution P2P qui ne me donne que les 50Kpbs du mec a coté de chez moi, je vais la dégager vite fait aux dépens de la solution qui suce en plus le Mbps de Toto de Trifouilly-les-Oies et les 500Kbps de Bob de Sydney. On discute de la viabilité du concept ou alors de sa mise en production ? Comcast l'a testé et ça marche, pas besoin de chercher midi à 14h. C'est pas pour autant que tout le monde devrait l'avoir déployé depuis, ça demande encore du travail qui est actuellement effectué par le groupe ALTO ou le groupe PPSP par exemple. Contrairement à IPv6, les réseaux P2P fonctionnent et sont
Re: [FRnOG] RE: [FRnOG] Optimiser le pair-à-pair
On Tuesday 15 November 2011 05:15:27 Michel Py wrote: C'est vachement limitant aussi car on voit bien que dans le cas de Spotify seulement un tiers du trafic est P2P. J'objecte, ce qui disent les graphes (en moyenne) : - 10% du serveur - 33% en P2P - 57% en cache Donc ok seulement 1/3 du trafic est P2P, mais en fait ça fait un bon gros 3/4 des échanges réseau quand même. J'aimerais bien voir les stats de Spotify en ce qui concerne la répartition intra-AS / extra-AS car jusqu'à présent j'ai rien vu de bien concret. Là ou Spotify est bon c'est sur la qualité et ne pas tuer l'upstream, mais en ce qui concerne l'optimisation du trafic... Spotify ne fait pas le tri directement en fonction de l'ASN, ils donnent une note d'utilité à chaque peer et s'en servent quand ils doivent supprimer des peers. Par contre regarde le RFC 5632, Comcast a bel et bien réussi ce genre de montage. Là où je reste sceptique, c'est sur la vidéo (particulièrement en HD); j'ai bien peur que dans ce cas la part du P2P devienne une goutte d'eau dans la mer, si ça reste propre. J'ai pas finit de lire le papier de PPLive, si quelqu'un veut regarder: Y. Huang, T. Z. Fu, D.-M. Chiu, J. C. Lui, and C. Huang, “Challenges, design and analysis of a large-scale P2P-VoD system,” SIGCOMM Comput. Commun. Rev., vol. 38, no. 4, pp. 375–388, 2008. -- Rémy Sanchez http://hyperthese.net/ signature.asc Description: This is a digitally signed message part.
Re: [FRnOG] [MISC] Le troll (FR) multi-sujet du vendredi
On Saturday 12 November 2011 05:56:32 Michel Py wrote: Il y a 2 problèmes avec ton idée: 1. Les gros sous: combien tu vas donner au FAI pour qu'il t'ouvre l'upstream de la machinbox de Mme Michu, à coté de combien ça lui coûte? 2. D'un point de vu purement technique, le P2P c'est un désastre pour le réseau. La nature ayant horreur du vide, si la bande passante n'est pas disponible près de chez toi (la notion de proximité étant elle-même floue) le client ou la machinbox va aller chercher qui a les données. Je viens de télécharger une vidéo avec bittorent; une partie est venue de Suède, l'autre d'Australie, et juste maintenant je suis en train de seeder le même torrent pour un abonné Wanadoo à Pointe-à-Pitre, un autre abonné Wanadoo aux Pays-Bas, quelqu'un en Bolivie (100% vrai). Mais enfin, le CHC est totalement différent du P2P : il est contrôlé de manière à ce que le trafic reste à la maison. Bon, eh bien poste donc un business plan avec des chiffres (pas du vent) et je suis sûr que si ça tient la route, les investisseurs potentiels te contacteront. Comtpons un transit à 20€/mbps [1], et 100ko/s d'upload en moyenne chez chaque eyeball [2]. Maintenant prenons un FAI avec 1 000 000 d'eyeballs, si un système de CHC arrive à utiliser cet upload de manière optimale, c'est 800gbps (+ l'overhead IP, vu la mesure de l'upload) sous le coude, soit 16 millions d'€ en transit. Donc qu'est-ce que je donne aux FAI ? Des dizaines de millions d'euros d'économies. Sans discuter le reste des aspects boiteux que pourait prendre un business model basé sur ce concept, il y a au moins ça qui est clair. [1] http://www.tmcnet.com/channels/ip-transit/articles/118188-ip-transit- prices-decline-as-expected.htm [2] http://www.grenouille.com/ -- Rémy Sanchez http://hyperthese.net/ signature.asc Description: This is a digitally signed message part.
Re: [FRnOG] [MISC] Le troll (FR) multi-sujet du vendredi
On Saturday 05 November 2011 23:49:27 Michel Py wrote: Là ou ça devient un problème, c'est quand Rémy essaie de gagner des thunes en revendant du CHC. Vois-le comme tu veux, le CHC c'est une manière d'avoir de l'hébergement gratos, donc sur le DOS du FAI. C'est du contenu qu'on veut faire passer de toute façon, il vaut mieux un DOS sur le transit ET le cœur ou juste sur le cœur ? Bon je n'essaie pas de laver plus blanc que Bonux, mais comme je le disais plus tôt faudra pas venir se plaindre que les FAI considère le CHC comme un parasite. Le profiteur n'est ni Mme Michu ni son FAI, donc c'est l'un ou l'autre et probablement les deux qui vont finir par payer le fric que les gens qui vendent le CHC vont gagner. Comme tu l'expliquait, Akaimai fout des baies de serveur gratos chez les FAI pour éviter que le contenu ne transite plusieurs fois. Là c'est pareil mais sans l'électricité et la place à payer... Sans essayer d'être un moraliste, je ne vois pas ou est le bénéfice pour le consommateur ou pour l'Internet en général. Économiser de la bande passante au niveau global ? Avec le même Internet tu peux mettre plus de trucs dedans. -- Rémy Sanchez http://hyperthese.net/ signature.asc Description: This is a digitally signed message part.
Re: [FRnOG] [MISC] Le troll (FR) multi-sujet du vendredi
On Monday 07 November 2011 02:05:20 Rémi Bouhl wrote: C'est de l'espace (jusqu'à 10Go chez Free), fournit gratuitement à chaque abonné. Comment se fait-il que ce soit gratuit sur les serveurs du FAI mais inimaginable sur la ligne de l'abonné? Si on fait le compte, Free montre quand même un sacré acharnement à internaliser le trafic : les pages persos free.fr (qui ont perdu de la vitesse mais ont représenté une grosse partie de l'Internet français), les serveurs usenet avec les a.b.*, la tentative de megaupload (dl.free.fr), le youtube- like de la freebox (enfin je crois j'ai pas de TV pour tester), les dédibox/online.net, ... Enfin du coup j'ai du mal à voir pourquoi le CHC serait *contre* les FAI, pour moi ils peuvent carrément le vendre en tant que service de CDN en l'implémentant dans les box ou que sais-je du genre. Soit je rate un truc, soit Michel a décidé de redoubler de mauvaise foi, soit les deux :) -- Rémy Sanchez http://hyperthese.net/ signature.asc Description: This is a digitally signed message part.
Re: [FRnOG] Le troll du vendredi par Rémy
On Thursday 03 November 2011 10:33:51 Rémi Bouhl wrote: C'est aussi lié au déploiement de IPv6 afin de faciliter la joignabilité des machines dans des conditions diverses. Le passage de NAT sur IPv4 par les logiciels de P2P ça peut tomber en marche, mais ce n'est pas optimal. Je suppose que ça rendrait les choses plus faciles, mais si on en croit le papier de Spotify, ça n'est pas vraiment un problème ; de même pour Skype qui fonctionne dans pas mal d'environnements. -- Rémy Sanchez http://hyperthese.net/ signature.asc Description: This is a digitally signed message part.
Re: [FRnOG] Re: [FRnOG] Re: [FRnOG] Le troll du vendredi par Rémy
On Wednesday 02 November 2011 18:18:27 Antoine Drochon wrote: C'est pas tant l'instabilité à proprement dis que toute une industrie traumatisée par des années de P2P == evil. La stabilité on arrive à l'obtenir (merci l'hybridation). Gérer des centaines de milliers de serveurs, gérer des millions de bout de soft dans la nature, ça se fait, les botnets y arrivent bien :-) Là où c'est plus compliqué, c'est de convaincre les bonnes personnes. Boarf, si on veut le faire adopter il suffit de changer le nom, le présenter sous un autre angle, et voilà, c'est comme les NFC/RFID. Exemple : le CHC (Customer Hosted Content) est une technologie totalement nouvelle qui permet de réduire drastiquement les coûts en bande passante car elle permet d'héberger le contenu chez l'utilisateur de manière totalement sécurisée. Et pour les plus tenaces tu mets en FAQ des arguments pour dire que c'est totalement différent du P2P. -- Rémy Sanchez http://hyperthese.net/ signature.asc Description: This is a digitally signed message part.
Re: [FRnOG] Re: [FRnOG] Re: [FRnOG] Re: [FRnOG] Le troll du vendredi par Rémy
On Thursday 03 November 2011 02:00:06 Jérôme Nicolle wrote: Bullshit ! Ah bah quitte à parler marketing autant le faire bien ! RHIEN (ne) suggère que ce soit une voie d'avenir. À mon avis c'est tellement lié à l'upload que l'avenir de cette voie est le même que celui du déploiement de la fibre, qu'en pense-tu ? :3 Et au prochain épisode, RHIEN vs HADOPI (celle là c'était gratuit). -- Rémy Sanchez http://hyperthese.net/ signature.asc Description: This is a digitally signed message part.
Re: [FRnOG] trop de trolls
On Sunday 30 October 2011 09:02:34 Philippe Bourcier wrote: J'ai l'impression que ca répond pas mal au besoin. Intéressant, je me sens un peu visé du coup là, je ne pensais pas soulever autant de questions... Les tags je trouve ça intéresant car beaucoup plus fluide que les listes séparées, et c'est facile à utiliser, tant pour écrire les sujets que pour le filtrage. Ça évite un peu de se poser la question de la légitimité absolue d'un message et de faire corresponde les attentes plus facilement. En bref: +1 -- Rémy Sanchez http://hyperthese.net/ signature.asc Description: This is a digitally signed message part.
Re: [FRnOG] Re: Le troll du vendredi par Rémy
On Friday 28 October 2011 11:56:16 Stephane Bortzmeyer wrote: On Fri, Oct 28, 2011 at 04:35:59AM +0200, Rémy Sanchez remy.sanc...@hyperthese.net wrote a message of 102 lines which said: Maintenant, pourquoi pas distribuer du contenu légal en P2P ? Euh, ça se fait, cela fait bien longtemps qu'Ubuntu, WoW ou FreeBSD sont distribués ainsi. Certes, mais ça reste confidentiel, je pensais surtout à remplacer Akamai par un protocole similaire à celui de Spotify. je n'ai pas entendu parler d'autre gros fournisseur utiliser du P2P. « Gros fournisseur » et P2P me semblent un peu antinomiques, non ? L'intérêt de P2P est justement qu'on peut se passer des fournisseurs. Il me parait donc normal que le trafic P2P soit peu visible (surtout qu'il faut échapper à Amesys et TMG, donc on se cache). On ne se passera jamais de serveur centralisé, le P2P n'étant là que pour alléger les échanges. Et puis on peut changer « gros » par « avec beaucoup de clients », c'est un peu plus proche de l'idée que je voulais exprimer. Pourquoi pas un effort de standardisation pour remplacer les CDN par du P2P ? Mais il existe ! http://www.bortzmeyer.org/5693.html http://www.bortzmeyer.org/6029.html Au temps pour moi, j'ai pas dû chercher assez longtemps. Par contre je n'ai jamais entendu parler de déploiement de serveurs Alto. C'est bête, vu l'enjeu derrière les « IP géographiques » et toute la galère pour localiser au mieux l'utilisateur, ça serait pratique... Ou alors j'ai encore raté un truc ? Question bonux : est-ce que ça ne serait pas, en plus, la killer-app qu'attend IPv6 ? IPv6 n'attend pas de killer-app et ne l'a pas demandé. Bien au contraire, IPv6 a été conçu pour ne rien changer pour l'utilisateur. La célébrissime Mme Michu se moque que son film ait été téléchargé en IPv4 ou IPv6 et c'est très bien comme ça. Certes, mais prenons le cas hypothétique suivant : un opérateur d'eyeballs décide de fournir un service de distribution de contenu en P2P, car ça fait des tarifs vachement avantageux. Comment il s'en sort ? C'est plus simple avec de l'IPv6 qu'avec du CGN quoi. Sachant qu'on ne déploie pas IPv6 parce que ça coûte trop cher et que les autres n'ont pas encore IPv6 (en très simplifié), si l'IPv6 sert surtout à communiquer en interne, et qu'en plus il sert à faire gagner des sous, on peut voir pourquoi ça pousserait au déploiement. -- Rémy Sanchez http://hyperthese.net/ signature.asc Description: This is a digitally signed message part.
Re: [FRnOG] Le troll du vendredi par Rémy
On Friday 28 October 2011 11:29:27 p...@9online.fr wrote: Où l'on apprend que, comme toujours, ce sont les ayants-droits qui freinent. Je ne pense pas que les freins à l'utilisation du P2P aient changé. Je connais un peu le sujet, pour avoir travaillé il y a 4 ans au démarage d'une start-up qui a imaginé une solution innovante pour permettre à des ayants droits de garder le contrôle de contenus multimédia circulant massivement, par exemple sur Internet en P2P mais aussi sur des supports physiques. En gros, le contenu se dissémine et c'est seulement au moment où il veut l'utiliser que l'internaute est mis en relation avec l'ayant droit qui lui propose une contrepartie, marchande ou non : cela peut être payer un peu, remplir un formulaire ou toute autre interaction possible sur le web. J'ai ramé pendant 2 ans, face à des ayants droit européens de l'industrie du cinéma et de l'audiovisuel qui n'avaient aucune envie de se casser la tête pour diffuser leurs contenu sur Internet, et pour qui le P2P était un instrument du diable, à combattre par tous le smoyens. Aujourd'hui les choses bougent, et de gros ayants droit aux USA commencent à imaginer de se diffuser eux-mêmes sur le web, en s'affranchissant des Netflix, iTunes etc. Ils ont bien compris que les films en HD et 3D ne pouvaient pas être diffusés massivement en streaming. Et là évidemment le P2P est la solution rêvée. Du coup, la start-up dont je parlais, UbicMedia - http://www.ubicmedia.com - qui a gardé sa RD à Lyon et y recrute, a maintenant aussi un bureau à Los Angeles et des projets pilotes démarrent... avec des américains, pas des européens. A suivre... -- Pierre Justement j'ai pris Spotify en exemple, parce qu'ils diffusent de la musique, et c'est bien la preuve que la mentalité à changé. Du coup, ce genre de projet risque bien d'aboutir. Après la question des DRM, même si je n'aime pas ça, globalement d'un point de vue transport des données c'est pas exactement mon problème (neutralité :D). On parle bien de distribuer un bloc opaque de bits quoi. -- Rémy Sanchez http://hyperthese.net/ signature.asc Description: This is a digitally signed message part.
Re: [FRnOG] RE: [FRnOG] Le troll du vendredi par Rémy
On Friday 28 October 2011 05:19:27 Michel Py wrote: Microsoft (entre autres) a essaye; ca s'appellait three degrees, c'etait une appli P2P uniquement v6 (fallait des tunnels pour que ca marche). La killer app, c'est un peu la meme chose que la quete du Saint Graal Microsoft a toujours été en avance de toute façon (dropbox^Wle porte documents est apparu au moins dans windows 95 je crois), c'est juste qu'ils ont raison trop tôt. Après je ne cherchais pas vraiment de killer-app, c'est juste que comme dit dans un autre mail, à priori en IPv6 c'est quand même vachement plus simple. -- Rémy Sanchez http://hyperthese.net/ signature.asc Description: This is a digitally signed message part.
Re: [FRnOG] Le troll du vendredi par Rémy
On Friday 28 October 2011 13:52:28 Mathieu Goessens wrote: Parce que ça n'est pas si simple: Il y a beaucoup de contraintes qui, individuellement sont déjà difficiles à adresser, mais mises bout à bout deviennent assez casse tête. Par exemple, les problématiques réseaux que pointaient Stéphane, mais aussi, les problématiques de vie privée: tu veux vraiment que tes peers aient accès à la liste des sites que tu as visité ? Pris individuellement, il est facile d'adresser ces problèmes de vie privée. Le faire en conservant une bonne réactivité et une bonne expérience utilisateur est tout de suite plus compliqué et plus rigolo :) La vie n'est pas un long fleuve tranquile, et puis c'est bien plus marrant quand c'est compliqué :) Par contre, on ne peut que constater que des dizaines de millions d'utilisateurs se sont adonnés à des échanges sans protection. Je laisse à chacun le soin de déterminer si c'est une bonne idée... Et ce ne sont que deux exemples, il faudrait sans doute modifier quelque peu les protocoles, pour avoir un système ou tu choisies tes peers fonction de centre d'interêts, avoir des systèmes de poids dans le choix des peers fonction des interets et contraintes réseaux, avoir des architectures réseaux permettant une phase rapide de bootstrap, avoir une bonne experience utilisateur, avoir une killer-feature incitant au déploiement ... Je me disais que la killer-app, ou plutôt killer-feature, c'est le gain engendré. Il faut moins de serveurs et moins de bande passante, pour moi qui pensait vivre dans un monde où l'argent fait la loi, ça me semble suffisant. Ou alors, c'est que les gains ne sont pas si grands ? On m'a rarement laissé fouiller les comptes d'un fournisseur de contenu, mais globalement genre chez Akamai, Youtube ou Netflix, c'est quoi qui leur coûte le plus cher ? Je ne pense pas me planter en disant que la bande passante est un poste de dépense important. -- Rémy Sanchez http://hyperthese.net/ signature.asc Description: This is a digitally signed message part.
Re: [FRnOG] Re: [FRnOG] Le troll du vendredi par Rémy
On Friday 28 October 2011 22:13:02 Michel Py wrote: On m'a rarement laissé fouiller les comptes d'un fournisseur de contenu, mais globalement genre chez Akamai, Youtube ou Netflix, c'est quoi qui leur coûte le plus cher ? Je ne pense pas me planter en disant que la bande passante est un poste de dépense important. Un des modèles d'Akamai est qu'ils installent un de leurs serveurs chez le FAI gratuitement. Sans rentrer dans les détails éminemment variables et confidentiels, le FAI fournit les rack U et l'électricité, Akamai fournit le serveur et le support. Que gagne le FAI: quand 1000 blaireaux téléchargent le même contenu, ça lui coûte que 1 fois le transit. Que gagne Akamai: ils revendent à leur client 1000 fois un chargement de fichier qui leur a couté zéro, puisque sortant de leur cache installé chez le FAI et tout le monde est content. Attention à ne pas généraliser, ce n'est pas le seul modèle, mais dans ce cas-là la bande passante ne coûte rien à Akamai, car c'est du cache local. D'accord, grosso modo ce à quoi je pensais mais en version boite noire avec les resources à un autre endroit. Ça répond à ma question je crois :) Va falloir bosser pour ressortir de l'aDSL de Mme Michu la bande passante du PC d'Akamai connecté directement à GigE ou 10GigE sur le coeur du FAI. J'ai pas de stats valables pour appuyer mon propos, mais si on prends la somme de tous les uploads en continu, qu'est-ce que ça donne par rapport à la moyenne des downloads ? En heure de pointe, bien sûr... Enfin, oui je comprends bien que d'installer des serveurs c'est quand même plus simple que de croiser les doigts pour que les clients arrivent à sortir du NAT et fournissent un upload suffisant. À quand la fibre chez tout le monde, les débits symétriques et l'IPv6 généralisé ? :3 -- Rémy Sanchez http://hyperthese.net/ signature.asc Description: This is a digitally signed message part.
Re: [FRnOG] Re: Le troll du vendredi par Michel
On Friday 21 October 2011 10:57:14 Jérôme Nicolle wrote: Plus de libre communication entre tous les usagers du réseau, dépendance accrue aux opérateurs et éditeurs en place, moins de liberté d'innovation sur les protocoles requérant un réseau propre... Ce ne serait plus Internet mais une combinaison d'AOL, MSN et Google' Skynet... Merde, on maurait menti et il resterait autre chose du net ? (Comprendre : les eyeballs s'en tapent du reste, donc je vois vraiment pas pourquoi les opérateurs se gêneraient, malheureusement...) -- Rémy Sanchez signature.asc Description: This is a digitally signed message part.
Re: [FRnOG] Re: [FRnOG] Le FTTH, une impasse ?
On Saturday 08 October 2011 12:30:50 Jean-Paul Smets wrote: La clef pour developper rapidement le cloud reparti c est... ipv6. Cela permet de se passer de vpn et de ne plus avoir de NAT. On avait pense pour slapos a upnp ou des vpn repartis du genre tinc mais ipv6 propose la meilleure resilience sociale. C'est mignon de dire ça, mais y'a quand même encore 2 ou 3 couches de protocles à foutre par dessus IPv6 pour avoir quelquechose d'utilisable. Je sais pas exactement comment tu vois ça, mais moi je comprends qu'un protocole se chargerait de répartir en P2P les contenus chez les abonnés. Avant que ça s'affiche dans le navigateur de Mme Michu, il va falloir un paquet de mises à jour... -- Rémy Sanchez signature.asc Description: This is a digitally signed message part.
Re: [FRnOG] Re: [FRnOG] Le FTTH, une impasse ?
On Friday 07 October 2011 18:20:40 Stéphane Dupille wrote: On Fri, 07 Oct 2011 17:28:38 +0200, Clément Guivy wrote: La facture d'électricité est payée également je suppose, du coup ? Et l'assurance habitation ? Je ne crois pas, mais un abo au prix de la conso de deux serveurs, ça reste un bon deal. Bon, faut voir combien ils consomment, mais j'imagine que c'est plutôt des ATOM que des XEON, non ? Et je suppose que les clients de cette offre sont au courant que leurs serveurs sont hébergés dans le nec plus ultra de la sécurité et la fiabilité, à savoir chez madame michu derrière une connexion fibre grand public ? J'imagine que les données sont chiffrées, donc on s'en fout un peu, et qu'en plus les données sont réparties sur plusieurs serveurs, donc on peut perdre des serveurs. Et si en plus les données sont dispersées (un bout par ci par là), ça sécurise encore plus. Non, je trouve que c'est une EXCELLENTE idée. Et perso, en tant qu'utilisateur éventuel de ce genre de solutions, je préfère nettement savoir mes données chiffrées, dispersées et redondées chez plein de quidams que de les savoir chez Google, Apple ou DropBox. --- Liste de diffusion du FRnOG http://www.frnog.org/ Globalement, c'est pire que ça. On a tous des serveurs multimedias dans nos chaumières (je parle bien entendu des .+box), et ça ne sert qu'à router le misérable débit qui passe par l'ADSL. Et puis bon, du cloud hébergé chez l'utilisateur pour le coup c'est vraiment du cloud, avec des arguments cette fois. Un peu de chiffrage, de routage P2P overlay, et pouf. En plus, si je ne m'abuse ça règlerait un bon nombres de sushis liés au peering/transit dont on entend parler ces jours. Plus le temps passe, plus je, pauvre noob naïf, pense que ce genre d'architecture serait la solution. Mais si on cumule uploads inexistants avec le NAT, on va pas aller très loin. Si on met à part le succès des réseaux P2P du genre BitTorrent, ou des trucs proprios à la Spotify ou Skype, est-ce que des initiatives plus génériques sont mises au point/existent ? Disons typiquement, de quoi remplacer les CDN par exemple. -- Rémy Sanchez signature.asc Description: This is a digitally signed message part.
Re: [FRnOG] profil VDSL2 et débit en upload
On Friday 22 July 2011 20:28:09 Rémi Bouhl wrote: Dans ce conditions-là, le plus rapide, plus simple et moins cher est de prendre deux lignes, ça vous fera 1.4 Mbs. Et faire du multi-homing^Wload-balancing ?! C'est scandaleux ! Ah tiens, une porte... -- Rémy Sanchez signature.asc Description: This is a digitally signed message part.
Re: [FRnOG] Impacte de la latence et perte d’acquittement TCP sur le débit
On Sunday 10 July 2011 19:39:04 Vivien GUEANT wrote: Ma question : quel système d'exploitation ou paramètre linux utiliser pour avoir des bonnes performances avec une latence importante et un drop des acquittements au-delà de 222 ACK/s ? Augmente ta MTU. Ok je sors... Y'a eu un troll du genre sur NANOG, ça commence là http://mailman.nanog.org/pipermail/nanog/2010-November/027515.html à priori. Si ma mémoire est bonne ils font le tour des raisons de chute de débit, MTU ou non, et des éventuelles solutions. My 2 bitcoins, -- Rémy Sanchez signature.asc Description: This is a digitally signed message part.
Re: [FRnOG] Re: RFC 6296: IPv6-to-IPv6 Network Prefix Translation
On Sunday 03 July 2011 22:39:53 Stephane Bortzmeyer wrote: http://code.google.com/p/napt66/ Je ne l'ai pas testé. Fail : c'est Network Address PORT Translation. Le même qu'en IPv4 : « IPv6-to-IPv6 Network Address Port Translation (NAPT66) is a stateful IPv6 NAT mechanism. Just like IPv4 NAT, NAPT66 technique makes several hosts share a public IPv6 address. As a result, NAPT66 helps to hide the private network topology and promote network security. » -- Rémy Sanchez signature.asc Description: This is a digitally signed message part.
Re: [FRnOG] RFC 6296: IPv6-to-IPv6 Network Prefix Translation
On Monday 04 July 2011 11:35:50 Alain RICHARD wrote: Oui mais dans ce cas, comment mon ampoule sait laquelle de ses deux adresses (ou n adresses) elle doit utiliser pour sortir sur internet ? Cf le mail de Yves-Alexis Perez qui renvoie à la RFC kivabien http://www.mail-archive.com/frnog@frnog.org/msg15322.html -- Rémy Sanchez signature.asc Description: This is a digitally signed message part.
Re: [FRnOG] RFC 6296: IPv6-to-IPv6 Network Prefix Translation
On Monday 04 July 2011 21:11:42 Radu-Adrian Feurdean wrote: Entre un /64 et un autre /64, lequel gagne selon le longest prefix match ? Ça veut pas plutôt dire que ça choisit en fonction du nombre de bits en commun dans le début du préfixe ? Genre :::ddde::/64 gagnerait contre :::::/64 pour joindre :::::/64 -- Rémy Sanchez signature.asc Description: This is a digitally signed message part.
Re: [FRnOG] RFC 6296: IPv6-to-IPv6 Network Prefix Translation
On Sunday 03 July 2011 10:31:23 Thomas Mangin wrote: On 2 Jul 2011, at 23:10, Rémy Sanchez wrote: On Saturday 02 July 2011 23:23:13 Thomas Mangin wrote: C'es plutot pour la gateway avec deux uplinks qui peut faire du balancing facilement. Et tu fais ça avec 2 uplinks qui ont des préfixes différents sans NAT66 ? Oui, chaque machine a alors deux IP. Les deux IP sont toutes le deux globales, comme une machine avec deux interfaces et deux IP publiques mais avec une seule interface pour v6. Le seul truc est que je ne sais pas comment la machine va choisir son IP pour les connections sortantes .. Donc je suis sur que cela peut aider pour la résilience, maintenant pour le LB cela dépend de comment l'OS gère ses connexions sortantes. le mail de Yoann explique bien la limite de cette technique. Si c'est un hash par flux, pour les cas simple c'est tout bon, sinon, pas autant. Dans le cas du DC, tu peux alors router créer deux sessions BGP avec routeurs 1 et 2, annoncer des IP de services (installe sur lo0). Si le routeur tombe en rade, tu as alors toujours l'autre. Ca peut remplacer HSRP/VRRP pour les équipements sans RFC 5798 (VRRP pour IPv6) Thomas C'est sûr ça aide pour la résilience, mais quand comme moi tu cherches à grapiller le moindre bit/s que tu peux trouver, ça marche moins bien. Retour à la case NAT66, malheureusement. Enfin un truc qui m'étonne dans cette histoire, c'est pourquoi y'a personne qui vend des « dual-adsl aggrégés côté opérateur » (attention, terme marketing inventé à l'instant)... Y'a des protocoles pour faire ça proprement (au moins la RFC 1717), et ça élimine tout besoin de NATxx. Je suppose que c'est lié au fait que y'a qu'une seule prise téléphonique chez les gens normaux. -- Rémy Sanchez signature.asc Description: This is a digitally signed message part.
Re: [FRnOG] RFC 6296: IPv6-to-IPv6 Network Prefix Translation
On Sunday 03 July 2011 21:50:11 Michel Py wrote: Faudrait inventer un routeur WiFi triple radio, avec 2 radios dehors comme ça tu peux load-balancer le WiFi du MacDo et celui du Quick :P Ah, moi j'pensais plutôt au cluster de clef 3G, on a une BS Orange sur la tête. Remarque, on pourrait directement détourner la connexion de la BS... J'suis sûr, ils s'en rendraient même pas compte :3 -- Rémy Sanchez signature.asc Description: This is a digitally signed message part.
Re: [FRnOG] RFC 6296: IPv6-to-IPv6 Network Prefix Translation
On Sunday 03 July 2011 21:57:58 Thomas Mangin wrote: MPPP est une option (nous l'offrons), mais il faut faire attention car si les paires de cuivre ne prennent pas les même ducts, la différence cause des problèmes ... C'est peut-etre pour ca que ce n'est pas offer plus souvent, trop de cout du cote debugging ... Les mêmes ducts ? C'est quoi cette chose ? -- Rémy Sanchez signature.asc Description: This is a digitally signed message part.
Re: [FRnOG] Laissez-nous faire du multi-wan ( était: RFC 6296: IPv6-to-IPv6 Network Prefix Translation)
On Saturday 02 July 2011 09:50:13 Thomas Mangin wrote: 150, c'est une blague ?? !! Plus de 10 personnes par ligne, c'est une blague. La ligne ADSL a une limite sur le nombre de packets par secondes aussi !!. Quand tu comptes le nombre de paquet par machine que ne fait rien (DNS, anti-virus, twitter checks, ...) avoir plus de 20 personnes derrière une ligne DSL c'est se chercher des problèmes. Maintenant avec deux lignes, et avec un bon filtrage, NBAR ou ACL, du QOS, un cache et DNS interne, un grosse liste noire des sites populaires, ca peut marcher mais je préfère être alors etre sur une connexion 3G ! C'est tout à fait sérieux, et ça fonctionne bien mieux que chez certaines personnes seules sur leur ADSL. Inutile de m'expliquer qu'en théorie ça ne fonctionnera jamais, ça fait des années que ça tourne. Par contre, 150 personnes en 3G, ça risque de marcher moins bien :3 Maintenant ces solutions c'est du bricolage du client pour ne pas payer ce qu'il utilise et passer la facture au FAI. C'est comme pour les taxes, il y a des spécialistes pour vous réduire la facture mais quelqu'un doit toujours payer pour les services publiques Ces bricolages c'est une solution du client pour ne pas payer un service que de toute façon il ne peut pas payer. Rappellons aux auditeurs qui ne nous suivent pas depuis le début qu'une ADSL coûte 30€/mois alors qu'une fibre coûte 3000€/mois + 2 ou 3 bras en génie civil. Si tu paies 2 ADSL à 20 mégas qui en pratique te sortent du 6 mégas, à priori t'a le droit d'utiliser les 2x6 mégas à fond. Si c'était pas rentable fallait pas le vendre, je vois pas où est ton problème là dessus... C'est quand même pas un scoop que Mme Michu paie la bande passante des power-users, non ? Bien sûr, je ne dis pas que tout le monde devrait faire comme ça, il y a tout un tas de gens qui ont besoin d'autre chose un poil plus sérieux et qui seront tout à fait prêt à payer ce que ça coûte. Il faut des solutions pour tous les besoins et tous les moyens ! Mes 2 bitcoins, -- Rémy Sanchez signature.asc Description: This is a digitally signed message part.
Re: [FRnOG] RFC 6296: IPv6-to-IPv6 Network Prefix Translation
On Saturday 02 July 2011 20:19:02 Michel Py wrote: Rémy Sanchez a écrit: La seule et unique solution, c'est du multi-homing du pauvre, Appelles ça du load-balancing du pauvre, pas du multihoming. Admettons Tant que j'ai pas le même en IPv6, il m'est impossible de déployer IPv6. Je ne vois pas ou est ton problème; un hôte IPv6 peut avoir plusieurs adresses IPv6; tu crées un VLAN pour chaque FAI IPv6, et chaque PC a une adresse pour chaque FAI (dans le préfixe fourni par le FAI ou le tunnel broker). Je me suis toujours dit que c'était trop beau pour fonctionner, mais est-ce que quelqu'un a testé ? À priori les clients ne sont pas capables de balancer la charge 50/50 sur les deux routeurs, je me trompe ? Si tu paies 2 ADSL à 20 mégas qui en pratique te sortent du 6 mégas, à priori t'a le droit d'utiliser les 2x6 mégas à fond. Si c'était pas rentable fallait pas le vendre, je vois pas où est ton problème là dessus... C'est quand même pas un scoop que Mme Michu paie la bande passante des power-users, non ? Ca fait partie du jeu; attention quand même, à force de jouer au con des fois on finit par gagnervoir plus bas. Bien sûr, je ne dis pas que tout le monde devrait faire comme ça, il y a tout un tas de gens qui ont besoin d'autre chose un poil plus sérieux et qui seront tout à fait prêt à payer ce que ça coûte. Il faut des solutions pour tous les besoins et tous les moyens ! Voici ce que je peux avoir: Comcast Extreme 105 Downloads up to 105Mbps, uploads up to 10Mbps. $199.95 par mois Surewest Downloads Up to 50 Mbps / Uploads up to 50 Mbps 261.99 par mois Si ça c'est trop cher pour une petite société ou un troupeau de 150 étudiants La même en France, je signe tout de suite. Sauf que, à ma connaissance on a : * De l'ADSL à 15~40€/mois * De la SDSL à 100~500€/mois * De la fibre résidentielle à 30€/mois mais si t'es un power user tu te la met dans le cul (et ça se comprend !) * De la fibre pro à 1500€+ Sachant que plus t'es loin du réseau plus tu douilles, et que je suis loin du réseau... Bon et j'ai déjà eu l'aide de différentes personne de la liste pour tenter de trouver une meilleure connexion, mais on n'a jamais réussi à faire une proposition qui soit acceptée. [snip] 150, c'est une blague ?? !! Ah non c'est très sérieux, Rémy il a 150 étudiants sur 2 aDSL. Non mais j'exagère en disant 150, c'est plutôt 120 en temps normal. Ha-ha-ha. Plus de 10 personnes par ligne, c'est une blague. On est bien d'accord. J'ai envie de dire, on fait avec ce qu'on a :/ -- Rémy Sanchez signature.asc Description: This is a digitally signed message part.
Re: [FRnOG] RFC 6296: IPv6-to-IPv6 Network Prefix Translation
On Saturday 02 July 2011 21:37:02 Jérôme Nicolle wrote: Le 2 juillet 2011 21:16, Rémy Sanchez remy.sanc...@hyperthese.net a écrit : Sauf que, à ma connaissance on a : * De la fibre pro à 1500€+ Non, 100€ l'offre de base, avec 2k€ de FAS étalés et négociables (à l'époque) Sachant que plus t'es loin du réseau plus tu douilles, et que je suis loin du réseau... Non, 200m du cabinet de brassage optique le plus proche Bon et j'ai déjà eu l'aide de différentes personne de la liste pour tenter de trouver une meilleure connexion, mais on n'a jamais réussi à faire une proposition qui soit acceptée. Ah ben on a fait les propales que vous avez demandé, vous n'avez pas réussi à la faire passer à l'administration, vous ne pouvez vous en prendre qu'à Orange/TL1. Non mais j'exagère en disant 150, c'est plutôt 120 en temps normal. Ha-ha-ha. Faut préciser : le pr0n est bloqué. Plus maintenant J'ai envie de dire, on fait avec ce qu'on a :/ Et on se sort pas les doigts du c** pour régler le problème, surtout. C'est pas toi qui a passé des mois à faire un dossier comparatif pour répondre à toutes les contraintes administratives, et que finalement tes utilisateurs t'envoient te faire bip parce que 8€/mois c'est trop cher pour eux. Donc oui, j'ai besoin d'une bricole infâme pour la survie de mon réseau. Et ça m'étonnerait que je sois le seul. -- Rémy Sanchez signature.asc Description: This is a digitally signed message part.
Re: [FRnOG] RFC 6296: IPv6-to-IPv6 Network Prefix Translation
On Saturday 02 July 2011 23:11:28 Thomas Mangin wrote: Par flux ( hash source ip, source port , destination ip, destination port) ca passera surement tres bien. Tu veux dire que tous les OS et en particulier Windows Vista/7 font ça tout seul au simple fait de se voir attribuer 2 adresses globales ? -- Rémy Sanchez signature.asc Description: This is a digitally signed message part.
Re: [FRnOG] RFC 6296: IPv6-to-IPv6 Network Prefix Translation
On Friday 01 July 2011 09:53:49 Raphaël Jacquot wrote: j'ai un peu de mal a voir ce que ce genre de bricolages apporte par rapport a du routage entre les 2 sous réseaux. j'y vois au moins trois inconvénients * ca casse la transparence de bout en bout * ca bouffe éminemment plus de ressources dans le CPE * ca ne sécurise pas mieux que le NAT en v4 bref, c'est totalement inutile... T'a 2 box Orange forfait spécial Michu, un PC de bureau recyclé en routeur, et pas la moindre trace de sousous dans la popoche. Comment tu fais ton multi- homing ? -- Rémy Sanchez signature.asc Description: This is a digitally signed message part.
Re: [FRnOG] IPv6 partout
On Thursday 23 June 2011 19:03:29 j...@nexedi.com wrote: Bonjour, J'aimerais pouvoir déployer rapidement des réseaux IPv6 dans des salles de cours d'universités ou d'écoles d'ingénieur dont le réseau locale: 1- ne gère par IPv6 2- filtre tout sauf HTTP/TCP et HTTPS/TCP Une solution technique ira plus vite qu'une solution administrative (imaginez une université en Chine ou en France). J'ai besoin d'allouer 100 IPv6 par serveur. Avez-vous idée d'une telle solution ? Bien cordialement, JP Smets. PS. j'ai besoin de cela pour déployer également SlapOS http://www.slapos.org/ sur de la fibre Orange ou SFR qui n'a pas encore IPv6 PS2. pour l'instant je pense à de l'OpenVPN sur port 443 pour créer un lien non filtré + au choix un double NAT ou du miredo. miredo fonctionne bien mais n'alloue qu'une adresse. Si je comprends bien, tu veux faire un îlot IPv6 en milieu hostile pour de la démo technique ? Le miredo je ne suis pas convaincu, par contre un routeur avec un tunnel sur le port 443 ça me semble cohérent. Tu lui fait émettre ses RA (et éventuellement gérer du DHCPv6) sur le réseau et t'es tranquile pour faire tes 100 adresses par serveur. Pour tes fibres Orange ou SFR, tu peux faire le même concept mais avec un tunnel chez HE (http://www.tunnelbroker.net/, sur le protocole 41, et ils ont une beta du PPTP je crois), et tu aura un /48 directement si tu veux. -- Rémy Sanchez signature.asc Description: This is a digitally signed message part.
Re: [FRnOG] Le troll du vendredi par Michel
On 06/18/2011 04:06 AM, Rémi Bouhl wrote: Par contre y'a un point idiot dans Hadopi (enfin, pas qu'un). Si je poste du pédonazi depuis un hôtel celui-ci est censé garder des logs pour permettre de me retrouver. Si je télécharge illégalement, logs ou pas logs, l'hôtel est accusé de non sécurisation. Pour avoir ce genre de problème en pleine face, on s'était renseigné auprès d'HADOPI sur la question. Si j'ai bien compris, globalement HADOPI s'en cogne totalement de t'emmerder alors que t'es une entreprise, ils préfèrent s'acharner sur les particuliers et faire leur quota de mail. En théorie, au moindre souci de client choppé par HADOPI il suffit de les contacter et d'expliquer qu'on est une résidence/un hotel/whatever du genre pour éviter les problèmes. En théorie... -- Rémy Sanchez signature.asc Description: OpenPGP digital signature
Re: [FRnOG] Les RFC du groupe BEHAVE (NAT64) sont sortis
On 04/29/2011 02:07 PM, Guillaume Leclanche wrote: Raison #1 : Comment tu fais pour mapper tout l'Internet IPv6 dans une adresse IPv4 ? Pas forcément tout mapper, mais faire de la redirection de port. Par exemple, mettre des serveurs web sur des ports non 80 et l'indiquer dans le DNS. C'est tellement absurde comme solution que je suis sûr que les éditeurs de navigateur seraient fan. -- Rémy Sanchez signature.asc Description: OpenPGP digital signature
Re: [FRnOG] C'est vendredi, et pas n'importe lequel
On 04/01/2011 03:04 PM, Alain RICHARD wrote: Alors ça dors sur frnog ? Vous ne saviez pas qu'on n'a pas besoin d'IPV6 ? http://packetlife.net/blog/2011/apr/1/alternative-ipv6-works/ Pourtant justement à partir d'aujourd'hui on est entièrement préparé à IPv6. En effet, le dernier maillon de la chaîne de transit des données a enfin été mis à jour vers IPv6 : http://datatracker.ietf.org/doc/rfc6214/?include_text=1 -- Rémy Sanchez signature.asc Description: OpenPGP digital signature
Re: [FRnOG] Article sérieux et opérationnel bien que vendredi
On 03/25/2011 04:39 PM, guillaume.monne...@free.fr wrote: Ca me rappelle furieusement l'évolution d'HTTP : au début, beaucoup pensaient qu'ils suffirait de bloquer les protocoles autres que HTTP pour limiter l'usage au seul surf. Les marchands de FW ont gagné plein de sous avec du filtrage de ports. Résultat, touts les protocoles sont encapsulés au dessus d'HTTP, même pour de la VoIP (skype), ou le transfert de fichier (webdav). Du coup, on perd de la visibilité, car pour filtrer, les entreprises doivent désormais utiliser des FW 'avec états'. Tiens c'est étrange, ça me rappelle un troll que j'avais lancé :-° Entre ça, les pénuries d'IP, les DNS en P2P, et autres détails du genre, combien de temps va-t-on pouvoir conserver un Internet uniforme ? Comment éviter la fragmentation du réseau, tout en respectant les intérêts de l'utilisateur ? Est-ce qu'on a vu de tels problèmes se présenter avec les précédents moyens de telecommunication (poste, télégraphe, ...) ? En d'autres termes, est-ce que c'est une impression, ou alors est-ce qu'on est sérieusement dans la merde ? (il reste encore 10 minutes avant la fin de vendredi, j'ai le droit !) -- Rémy Sanchez signature.asc Description: OpenPGP digital signature
Re: Re : [FRnOG] Internet des Objets
On 03/04/2011 12:20 PM, Thioux nicolas wrote: Sans oublier l'atroce complexité engendrée pour un service finalement simplissime Donc, pourquoi développer avec le NAT et ne pas penser IPV6 dès la conception ? Pour faire dans la métaphore : si tu fais une voiture qui va aller sur un terrain accidenté, oui tu va la concevoir dès le départ pour s'y adapter, mais ça ne va pas l'empêcher de coûter plus cher d'une part, et de ne jamais pouvoir atteindre la vitesse que pourraît avoir une voiture de course sur circuit. L'IPV6 ne sera qu'un outil parmi d'autres pour arriver à cette évolution de l'Internet, mais pensez-vous qu'il s'agit d'une réelle évolution, et serait-ce une bonne évolution ? La fin du NAT, le retour de la connectivité pair à pair... Moi je vois ça comme une bonne évolution dans le sens où ça simplifie la création d'applications, et permet des choses impossibles par le NAT. -- Rémy Sanchez signature.asc Description: OpenPGP digital signature
Re: [FRnOG] Internet des Objets
Chouette, c'est vendredi :)
On 03/04/2011 01:51 AM, Emmanuel Thierry wrote:
Je ne comprends absolument pas pourquoi l'on parle constamment d'IPv6 pour la
domotique, comme si c'était *la* killer app. On sera toujours capable de
s'arranger avec son NAT444. Si on ne peut pas contacter un appareil ou un
capteur directement en end-to-end, il y aura toujours des gens intelligents
pour développer un four qui pushera régulièrement la cuisson du poulet sur un
serveur externe et demandera les commandes à effectuer.
Disons que si tu veux que ton frigo ait une connectivité Internet, c'est
ta seule option, le NAT444 a ses limites à la fois pour la mise à
l'échelle et pour l'établissement de connectivité point à point (comme
le NAT44, mais en pire, quoi).
Pourquoi est-ce que tu voudrais que ton frigo accède à Internet ? Pour
avoir la liste du contenu sur ton téléphone pendant que tu fais les
courses, par exemple.
Oui je sais, Facebook se ferait une joie de fournir un service qui
permet à ton frigo d'envoyer son status sur ton profil (sur le mur
c'est ça ?). Et puis le cloud computing ça va sauver la planète par ce
que c'est green et puis qu'en plus tu débranches ton cerveau.
Ou pas. Pour ma part je trouve ça débile d'avoir une ferme de serveurs
(sur lesquels je n'ai aucun contrôle) dans le seul but de pouvoir gérer
mon frigo. Alors qu'à côté j'ai mon modem/routeur (qui tourne de toute
façon) et mon frigo (qui tourne de toute façon), et qui ont largement la
puissance de calcul nécessaire pour fournir ce service (à supposer que
le frigo soit branché en IP).
Sans oublier l'atroce complexitée engendrée pour un service finalement
simplissime. Et d'ailleurs, si tu dois implémenter l'API Facebook dans
le contrôleur embarqué du frigo c'est une autre paire de manches qu'un
bête service UDP.
Je finirais par ajouter qu'une version light d'IPv6 existe pour
l'embarqué (6lowpan), et est à la base par exemple de la dernière
version de ZigBee. Donc en gros, ça va devenir le standard de facto.
Si les opérateurs majeurs veulent s'enfermer dans une technologie obsolète,
ils le peuvent, et ce sera nous (développeurs) qui serons bien obligés de
s'adapter...
Même chose version opérateur majeur : « on fournira IPv6 quand les gens
nous le demanderont », et c'est tout aussi compréhensible que ton point
de vue.
En ce qui concerne les développeurs, je vois ça comme ça : ils ont fait
preuve d'une incroyable ingéniosité pour contourner les limites d'IPv4
et du NAT, coûtant au passage une fortune en temps de conception
d'application, qu'on aurait eu mieux fait d'investir dans le déploiement
d'IPv6, ce qui au moins aurait été durable, mais passons.
Actuellement, on a des technologies de tunnel pour avoir de l'IPv6 dans
IPv4. De plus, les équipements domestiques (ordinateur, smartphone, ...)
gèrent tous plus ou moins bien l'IPv6. Ce qui veut dire qu'actuellement,
les développeurs ont toutes les cartes en main pour déployer des
applications IPv6-only chez le consomateur. Un peu comme une sorte de
{NAT,µPNP}++ quoi.
Le coût de mettre en place une solution de tunnel chez le client ? Je
suppose que ça va être un morceau un peu compliqué à développer. Par
contre ça sera mutualisable sur toutes les applis IPv6 qui vont sortir,
donc ça sera vite rentabilisé. Tout simplement par ce qu'une application
IPv6 est plus rapide à mettre en place qu'une application IPv4.
Quid des frais d'infrastructure ? Actuellement on est prêt à payer des
serveurs pour faire l'intermédiaire entre 2 machines NATées en IPv4,
donc je ne vois absolument pas pourquoi on ne pourraît pas se payer des
passerelles IPv6, sachant qu'en plus ces équipements sont voués à la
disparition.
On va me dire : l'intérêt d'avoir des serveurs au milieu c'est le
contrôle des données. Pour faire de la pub par exemple. Je veux bien,
mais quand tu va sur un site internet, et qu'il y a de la pub, le site
n'est pas hébergé par adSense pourtant. On peut appliquer le même
principe : l'application affiche de la pub, mais en supprimant les frais
liés à la gestion de ces données. Pour résumer, garde les revenus, mais
on supprime les frais. Moi ça me va comme principe :D
En d'autres termes : développeurs, à vous de jouer ;)
--
Rémy Sanchez
signature.asc
Description: OpenPGP digital signature
Re: [FRnOG] RE: [FRnOG] RE: [FRnOG] Ré: [FRnOG] À l'heure où l'on ne parle plus (ou presque) que d'IPv6
On 02/08/2011 08:58 AM, Michel Py wrote: Il y des mecs qui te feraient une statue en marbre ou en bronze si tu avais un /48 déployé chez Mme Michu aujourd'hui. /me attrape son annuaire et lance he.com Ahem. Et je suis d'accord avec Michel : le fait d'avoir un /48 par foyer permet d'avoir un standard, pour tous les concepteurs d'équipements ménager qui vont finir sur IP. Le jour où le frigo de Mme Michu communiquera en IPv6 avec l'ampoule de sa cuisine, il va falloir un réseau qui se configure tout seul, de manière algorithmique et non en choisissant soigneusement un plan d'adressage à la main. C'est le genre de choses qui sera largement plus flexible sur 16 bits que sur 8 ou moins. Et simplement aujourd'hui, si Mme Michu veut un wifi invité séparé de son réseau privé, personne ne sera en mesure de lui installer si elle n'a qu'un /64. Mon petit doigt me dit que cette histoire va encore finir en on vous avait prévenu... -- Rémy Sanchez signature.asc Description: OpenPGP digital signature
Re: [FRnOG] Re: Le troll du vendredi par Michel
On 02/04/2011 09:03 AM, Stephane Bortzmeyer wrote: Hélas pour ton plan d'affaires, cela n'est plus vrai : Ah, oui je sais, mais on parle d'arnaque hein... Suffit de dire que c'est pas compatible avec tous les navitateurs © -- Rémy Sanchez signature.asc Description: OpenPGP digital signature
Re: [FRnOG] IPv4 Exhaustion: RIPE NCC Update
On 02/03/2011 05:52 PM, Michel Py wrote: La fin du monde tant attendue mode +1h ha ! On vous avait prévenu que ça arrivait ! -- Rémy Sanchez signature.asc Description: OpenPGP digital signature
Re: [FRnOG] Le troll du vendredi par Michel
On 02/04/2011 06:22 AM, Michel Py wrote: gagner du pognon. Ah, moi j'avais pensé à créer une boite qui fait du proxying HTTPS. Genre, t'a un mutu chez OVH, et tu veux mettre ton site en HTTPS. Comme tu n'a qu'une IP, tu peux n'avoir qu'un seul site en HTTPS, donc l'idée c'est que ma boite te fournit l'IP en plus par le biais d'un proxy pour le site. Que l'activité soit viable ou pas, elle demande des masses d'IPv4, donc du coup ça permet de faire du stock, et de re-vendre la boite très cher dans quelques mois à quelqu'un en dèche grave d'IPv4. (Note: tu remarquera que j'ai quand même fait une tentative de début de troll) -- Rémy Sanchez signature.asc Description: OpenPGP digital signature
[FRnOG] Worskhop IPv6 Skills à Ghent
On 12/15/2010 05:28 PM, Mohsen Souissi wrote: On 14 Dec, Rémy Sanchez wrote: | [...] | | les conférenciers étaient complètement la tête dans les nuages | | (dommage ils ont l'air d'avoir des postes de décideurs...) | | == Pas d'accord. Cela parle des programmes de formation IPv6 et des | défis à venir. Certaines sont plutôt de terrain, d'autres d'ordre | politique-coordination, normal pour un atelier auquel on invite des | représentants de la CE, non ? Il faut savoir ce qu'on veut ;-) Les | bios des conférenciers sont en ligne et chacun se fera son opinion | :-) | | vendredi == J'ai bien noté ce tag, et je promets de répondre sérieusement quand même et de manière concise sans polémique :-) | Pour moi ça parlait surtout de l'incapacité de savoir combien de gens | ont eu leur logo IPv6... J'veux dire, toutes les questions récurrentes | du genre combien de gens sont certifiés ou combien de certifiés ont | utilisé leurs connaissances/combien de gens utilisant 6deploy ont | vraiment déployé IPv6 sont restées sans réponse. Même Cisco a eu du mal | à donner des chiffres... == Oui, c'est en effet regrettable, mais à leur décharge, c'est un boulot loin d'être évident. Suivre la trace de ceux qu'on forme et savoir ce qu'ils ont fait de leur savoir acquis n'est pas une tâche facile. Des chiffres, même approximatifs auraient tout de même aidé. | Quand quelqu'un suggère qu'il faille élargir la formation à tous les | utilisateurs du réseau (y compris les utilisateurs finaux) et que tu | (vous ?...) l'incendie, je trouve pas ça très très constructif, d'autant | plus que c'était quelqu'un qui vit exclusivement depuis des années du | déploiement d'IPv6, donc à priori il sait de quoi il parle. == Je trouve ça un peu exagéré :-) Le monsieur demandait un argument convainquant auprès des C*O pour aller vers IPv6. Je lui ai répondu que à différentes demandes, différentes réponses. Ceux qui demandent à être formés sont la cible des actions de formation, thème exclusif de l'atelier. Ceux qui ne sont pas encore convaincus de l'utilité d'IPv6 et qui sont parfois encore dans l'état de déni, ont besoin d'un effort d'un autre type (sensibilisation !), mais pas de formation à ce stade. Je regrette que mon propos ait été interprété de cette manière. Je crois qu'on ne parle pas du même... Je pensais à la personne habillée en noir avec des cheveux longs et une barbe, mais là la description me fait plutôt penser au monsieur avec un manteau gris (si ma mémoire est bonne) qui a posé au moins 4 fois la même question complètement hors sujet... | Moi j'ai clairement l'impression qu'on était encore dans une mentalité | où IPv6 sort des labos, et que pour l'instant le déploiement d'IPv6 est | un jeu qui se joue entre certaines branches de multinationales, quelques | universités/profs, et des morceaux de gouvernements, en ignorant | complètement la réalité^Wles autres acteurs. L'agenda de mise au point | des e-compétences c'est bien, mais ça va pas aider la PME de 5 personnes | qui fait tout sauf de l'informatique à déployer IPv6. == Encore une fois, c'est regrettable que vous soyez sorti avec cette impression. Je ne défends pas les intervenants, d'autant que je ne les connais pas (en tout cas très peu d'entre eux). Maintenant, sans tomber dans la publicité pour tel ou tel organisme de formation IPv6 en France ou en Europe, le retoutr d'expérience est claur : il y a une demande croissante de la part des companies commerciales qui veulent se formùer à IPv6 (loin des labos donc !), de peur de commencer à perdre des marchés. C'est une réalité, même si ça ne se bouscule pas (encore)... C'est ce que j'appelle le mode panic chez certains industriels (équipementiers en tête) qui ont peur d'être éliminés d'office d'appel d'offre IPv6 qui mettrait des conditions de compatibilité IPv6 (cf. document RIPE 501 à ce sujet : http://www.ripe.net/docs/ripe-501.html) | Je dis probablement ça par ce que je suis un connard de rookie qui a | découvert IPv6 y'a un an et qui fait chier son monde avec, mais comme le | disaient si bien certains des conférenciers, on est passé de quelques | geeks qui veulent découvrir IPv6 à un regroupement de tous les CxO d'une | multinationale dans la même pièce pour savoir comment déployer IPv6 | maintenant. M'enfin à priori il va falloir arrêter de faire des test | beds et allumer ça pour de bon d'ici pas trop longtemps, sous peine de | tuer la croissance des entreprises et l'innovation. == Entièrement d'accord (sauf sur la première phrase du paragraphe :-)) | /vendredi --- Liste de diffusion du FRnOG http://www.frnog.org/ troll sur la formation Je suis d'accord, c'est pas forcément évident de savoir combien de logos ils ont donné, et surtout étant donné le modèle de distribution qu'ils ont. De même, savoir si les gens ont vraiment utilisé 6diss
Re: [FRnOG] Re: [FRnOG] Questionnement d'un administrateur système sur l'IPv6
On Tue, 14 Dec 2010 15:38:52 +0100, Mohsen Souissi mohsen.soui...@nic.fr wrote: | NDLR : pour ceux que ça intéresse, le workshop était pas terrible | question contenu, == Je respecte votre point de vue même si je n'ai pas eu la même impression. | les conférenciers étaient complètement la tête dans les nuages | (dommage ils ont l'air d'avoir des postes de décideurs...) == Pas d'accord. Cela parle des programmes de formation IPv6 et des défis à venir. Certaines sont plutôt de terrain, d'autres d'ordre politique-coordination, normal pour un atelier auquel on invite des représentants de la CE, non ? Il faut savoir ce qu'on veut ;-) Les bios des conférenciers sont en ligne et chacun se fera son opinion :-) vendredi Pour moi ça parlait surtout de l'incapacité de savoir combien de gens ont eu leur logo IPv6... J'veux dire, toutes les questions récurrentes du genre combien de gens sont certifiés ou combien de certifiés ont utilisé leurs connaissances/combien de gens utilisant 6deploy ont vraiment déployé IPv6 sont restées sans réponse. Même Cisco a eu du mal à donner des chiffres... Quand quelqu'un suggère qu'il faille élargir la formation à tous les utilisateurs du réseau (y compris les utilisateurs finaux) et que tu (vous ?...) l'incendie, je trouve pas ça très très constructif, d'autant plus que c'était quelqu'un qui vit exclusivement depuis des années du déploiement d'IPv6, donc à priori il sait de quoi il parle. Moi j'ai clairement l'impression qu'on était encore dans une mentalité où IPv6 sort des labos, et que pour l'instant le déploiement d'IPv6 est un jeu qui se joue entre certaines branches de multinationales, quelques universités/profs, et des morceaux de gouvernements, en ignorant complètement la réalité^Wles autres acteurs. L'agenda de mise au point des e-compétences c'est bien, mais ça va pas aider la PME de 5 personnes qui fait tout sauf de l'informatique à déployer IPv6. Je dis probablement ça par ce que je suis un connard de rookie qui a découvert IPv6 y'a un an et qui fait chier son monde avec, mais comme le disaient si bien certains des conférenciers, on est passé de quelques geeks qui veulent découvrir IPv6 à un regroupement de tous les CxO d'une multinationale dans la même pièce pour savoir comment déployer IPv6 maintenant. M'enfin à priori il va falloir arrêter de faire des test beds et allumer ça pour de bon d'ici pas trop longtemps, sous peine de tuer la croissance des entreprises et l'innovation. /vendredi -- Rémy Sanchez --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [FRnOG] Questionnement d'un administr ateur système sur l'IPv6
On 12/12/2010 01:57 PM, Yoann Gini wrote: - Dans le cas plus spécifique du multiWAN. Comment est-il possible de gérer la répartition de charge sans faire de NAT ? J'reviens du workshop dont on parlait y'a quelques temps (http://www.training4ipv6.eu/index.php/workshop), du coup en discutant avec des gens il apparaît une autre solution : Tu passes ton réseau en IPv6 pur, sans IPv4. Pour ce qui est du load-balancing HTTP, tu fais faire ça au proxy il s'en sortira très bien (y compris pour se connecter à de l'IPv4). Pour les autres applications, soit tu considères qu'elles n'ont pas besoin de load-balancing, soit tu les répartis équitablement, soit c'est une appli métier et dans ce cas là tu peux probablement t'arranger avec l'autre bout du tuyau pour faire un VPN et du routage multi-chemins. (bon j'avoue la partie ipv6 pur c'est du bonus et non pas une nécessité) My 2 cents... NDLR : pour ceux que ça intéresse, le workshop était pas terrible question contenu, les conférenciers étaient complètement la tête dans les nuages (dommage ils ont l'air d'avoir des postes de décideurs...) -- Rémy Sanchez signature.asc Description: OpenPGP digital signature
[FRnOG] Re: [FRnOG] Re: [FRnOG] Re: [FRnOG] Quest ionnement d'un administrateur système sur l'IP v6
On 12/14/2010 12:09 AM, Yoann Gini wrote: Les répartir, équitablement tu penses, à quelle méthode ? Gérer à la main les routes par défauts des clients ? Une solution plus intéressante peut-être ? Je pensais regarder la moyenne de chaque protocole et répartir en gros 50/50 sur les 2 lignes, mais après tu peux aussi passer la moitié de tes clients dessus... On doit aussi pouvoir imaginer des proxys avec le même rôle que le proxy HTTP sur d'autres protocoles (SIP par exemple je suppose). Ça reste artisanal, mais comme tu dis c'est plus applicable qu'un range PI + BGP (surtout que la politique est de donner le moins de PI possible à priori...) -- Rémy Sanchez signature.asc Description: OpenPGP digital signature
[FRnOG] Re: [FRnOG] Questionnement d'un administr ateur système sur l'IPv6
On 12/12/2010 01:57 PM, Yoann Gini wrote: - Sans forcément avoir de multiWAN, si je change de FAI je change de préfixe IPv6, or le réseau a été construit à partir de ce préfixe (service interne, DNS, etc.). Actuellement si je change de FAI je n'ai aucun problème puisqu'en interne je n'ai que des IP privés. Avec l'IPv6 je ne vois pas trop comment on peut gérer ce cas, est-ce qu'il faut refaire tout l'adressage avec le changement de fournisseur ? En IPv6 tu a plusieurs adresses par interface : typiquement l'adresse globale, l'adresse locale, et l'adresse de lien. Ton adresse globale dépend de ton fournisseur, et elle peut être générée automatiquement par autoconf et/ou dhcp. À noter que l'autoconfiguration est prévue pour permettre la renumérotation des adresses : si tu annonces soudainement un nouveau préfixe, les machines gardent l'ancien préfixe quelques jour et prennent le nouveau aussi, ce qui te laisse un moment pour reconfigurer ton réseau. À noter aussi que le DHCPv6 permet de faire de la délégation de préfixe aux routeurs, mais à priori ça n'est pas très utilisé (implémenté). Ensuite ton adresse locale est composée d'un préfixe pseudo unique (tu peux le générer et le répertorier là par exemple : http://www.sixxs.net/tools/grh/ula/ ). Ce préfixe ne dépend pas de ton fournisseur, et n'est pas routé sur Internet (par contre tu peux le router comme tu veux sur ton réseau). En gros, comme les adresses privées IPv4 sauf qu'en plus le préfixe a très peu de chances d'être le même que celui d'une autre boite. Et puis l'adresse de lien local sert surtout à gérer le côté administratif du protocole, généralement on ne s'embête pas trop avec celle là (et elle n'est pas routable). En stateless les 64 derniers bits sont créés à partir de l'@MAC, est-ce qu'on a moyen de jouer avec ça ? Dans tout OS qui tient la route en théorie oui, à savoir que y'a une privacy extension qui existe et qui permet de générer les IP aléatoirement et de manière temporaire. Tu peux aussi faire une conf statique, d'ailleurs. Il me semblait avoir lu qu'une IPv6 incomplète est recomposée à partir du préfixe actuel, est-ce le cas ? Je ne suis pas sûr de comprendre la question... Une IPv6 c'est 64 bits de préfixe et 64 bits d'identifiant d'interface. Les 64 bits du début sont donnés par le routeur, et les 64 bits de la fin sont au choix de la machine (à condition de ne pas créer une adresse en double). Est-il préférable de maintenir un IPv4 interne pour ne pas devenir fou ? (please pas ça) J'aurais tendance à dire qu'il serait préférable de ne pas mettre d'IPv4 du tout dans le réseau et de maintenir la connectivité IPv4 avec du NAT64/DNS64, m'enfin ça c'est du gros extrémisme qui ne marche pas dans tous les cas. (C'est ce qui est utilisé dans le document que j'avais lié y'a quelques temps, http://ripe61.ripe.net/presentations/140-ripe_rome_jari.pdf) Par contre si tu passes en dual-stack, la solution par défaut aujourd'hui, tu va avoir IPv4 et IPv6 qui vont tourner séparément en même temps, en interne comme en externe. Va-t-il falloir revenir au NAT ? (please encore moins celle-là) Càd ? Du NAT en IPv6 ça n'existe pas, et même si ça devait arriver, ça ne serait jamais nécessaire vu le nombre d'adresses disponibles. - Dans le cas plus spécifique du multiWAN. Comment est-il possible de gérer la répartition de charge sans faire de NAT ? Sur celle là j'vais éviter de dire des conneries... -- Rémy Sanchez signature.asc Description: OpenPGP digital signature
[FRnOG] Re: [FRnOG] Re: [FRnOG] Re: [FRnOG] Re: [FRnOG] Questionnement d'un administrateur système sur l'IPv6
En vrac : * L'adresse link-local (celle de préfixe fe80::) est générée automatiquement, aucun routeur ne l'annonce. Cependant cette adresse est passablement chiante à utiliser (il faut systématiquement préciser le numéro d'interface, ce qui n'est même pas géré par tous les logiciels), n'est pas routable, et n'a pas les avantages de l'ULA, à savoir un préfixe pseudo-unique. Pour ces raisons, il est donc très largement plus pratique d'utiliser des ULA plutôt que des adresses link-local. Les ULA s'utilisent comme les adresses globales, à la différence que personne ne les routes vers Internet. * Les interfaces peuvent avoir plusieurs IP. De ce fait, un routeur peut annoncer plusieurs préfixe à la fois, y compris un préfixe ULA. De même, le DHCPv6 n'attribue pas une adresse, mais une liste d'adresses. D'ailleurs sur ce point là les leases sont passablement plus compliqués qu'avec IPv4... * Pour ton multi-wan, y'a une solution un peu moche que j'vais tester bientôt : faire un tunnel vers un serveur dédié, et l'utiliser pour sortir sur le net. D'ailleurs en théorie ça permet une répartition bien plus équilibrée qu'en utilisant les 2 lignes en round robin (puisqu'on équilibre aussi les paquets entrants). Pour ma part c'est insuffisant à cause de l'assymétrie de mes liens, alors j'vais tenter de faire du multilink ppp (c'est beaucoup plus drôle d'ailleurs). * L'utilisation du NAT64 c'était une blague, faudrait quand même avoir une sacrée paire de couilles pour balancer ça en entreprise... Remarque l'avantage c'est que ça casse automatiquement plein d'applications dont tu ne veux pas, comme le P2P :D -- Rémy Sanchez signature.asc Description: OpenPGP digital signature
[FRnOG] Re: [FRnOG] Questionnement d'un administrateur système sur l'IPv6
On 12/12/2010 07:36 PM, Jérôme Nicolle wrote: Waip, alors je faisait ça ya 4 ans, et c'est loin d'être optimal en ML-PPP. Il a du mal a prendre en compte la disparité des débits des liens, tout comme tu l'aurais avec du bonding sur des /dev/tap. Étrange, quand tu regardes la RFC ça explique justement que ça a été écrit pour ce genre de cas... Tu faisais ça avec que logiciel ? Pour l'instant je suis parti sur MPD [1], et concrètement c'est le seul que j'ai trouvé à avoir l'air de gérer ça... Par contre, pour le coup, tu peux compresser ce qui passe sur le tunnel, dans ton cas c'est pas anodin (si c'est bien pour MAIZ) Ouais, plus après mettre un proxy distant et tenter de booster la connexion avec lui (genre jouer avec les paramètres TCP, garder les connexions ouvertes entre le proxy local et le proxy distant, ...). [1] http://mpd.sourceforge.net/ -- Rémy Sanchez http://hyperthese.net signature.asc Description: OpenPGP digital signature
[FRnOG] Re: [FRnOG] Re: Questionnement d' un administrateur système sur l'IPv6
On 12/12/2010 08:33 PM, Stephane Bortzmeyer wrote: Et il n'existe pas de standard pour sa représentation texte, même si la syntaxe fe80::21e:8cff:fe76:29b6%eth0 est assez courante. Objection, c'est parfaitement standard d'après la RFC 4007, section 11. Elle donne le format suivant : address%zone_id Avec grosso modo zone_id qui est fournit par l'OS. Sous Windows c'est un index numérique, sous Linux le nom d'interface, ... Par contre si j'ai tout compris elle suggère qu'un OS devrait pouvoir choisir une adresse par défaut si l'interface n'est pas spécifiée, or Linux est totalement incapable de faire ça. J'ai compris de travers ou c'est une violation de la RFC ? * L'utilisation du NAT64 c'était une blague, faudrait quand même avoir une sacrée paire de couilles pour balancer ça en entreprise... Entre les nouveaux réseaux qui n'auront pas du tout d'adresse v4 et les anciens services qui ne se bougent pas pour migrer vers v6, il va donc falloir des greffes urgentes, car on n'aura pas le choix. Dans la mesure où tout comme du NAT44 il a besoin d'une IPv4 publique, pour un réseau de type purement utilisateur comme c'est le cas ici je pense que balancer ce genre de solution risque de faire plus de mal qu'autre chose. Par contre sur un réseau tout neuf pourquoi pas, à priori il y a peu de chances de casser les choses. -- Rémy Sanchez signature.asc Description: OpenPGP digital signature
[FRnOG] Re: [FRnOG] Questionnement d'u n administrateur système sur l'IPv6
On 12/12/2010 09:39 PM, Yoann Gini wrote: Même avec les éléments de réponses apportés je me vois mal gérer des blocs PI + BGP pour des entreprises de moins de 10 personnes qui ont deux pauvres ADSL. Or elles ont le besoin du multiWAN… Actuellement on rencontre un vrai problème de fiabilité de la connexion chez les clients qui ne peuvent pas dépasser la centaine d'euros par mois de frais de connexion. Je partage ta douleur... Il reste encore la solution dont je parlais (agréger les liens d'une manière ou d'une autre vers un serveur plus rapide)... Si tu prends un serveur que tu mutualises entre tes clients, ça ne devrait pas revenir trop cher au final. Bonus pour le fait que tu n'a plus qu'une seul IP de sortie, étant donné que le multi-IP pose des problèmes métaphysiques à certains sites (je ne pense pas aux putains de forums phpBB). Soit dit au passage : ça serait quand même vachement intéressant que les opérateurs proposent directement l'agrégation de lien... Je sais pas si certains d'entre vous le font déjà, mais en tout cas à priori c'est demandé. ~ sifflote ~ -- Rémy Sanchez signature.asc Description: OpenPGP digital signature
[FRnOG] Re: [FRnOG] Re: [FRnOG] Re: [FRnOG] Re: [FRnOG] Questionnement d 'un administrateur système sur l'IPv6
On 12/12/2010 10:14 PM, Jérôme Nicolle wrote: Le 12/12/10 21:07, Thomas Mangin a écrit : http://vh-net.fr/blog/ Cette solution marche quand tu as deux lignes aux carracteristiques très proches (débit et latence). Sinon, le débit cumulé sera le nombre de lignes * la vitesse de la plus lente, et une différence de latence importante créera une jigue énorme. Je confirme, vu que les débits sont complètement différents sur chaque ligne (2 ADSL avec une atténuation différente et 1 SDSL), déjà quand on fait du routage en round-robin sur les 3 ça ralenti tout, alors j'veux même pas imaginer avec ce genre de solution... Ce n'est pas la bande passante qui va faire mal, c'est la limite sure le nombre de packet par seconde que le DSLAM donne a chaque ligne. Car plus de machines veut dire plus de requetes DNS et autres, cela compte rapidement pour beaucoup ... Il y a un resolver avec cache et un proxy en local, justement pour limiter la casse à ce niveau. J'allais le dire :) On est pas fou non plus, et puis ça tourne comme ça depuis 5 ans... -- Rémy Sanchez signature.asc Description: OpenPGP digital signature
[FRnOG] Re: [FRnOG] Re: [FRnOG] Re: [FRnOG] Re: [FRnOG] Re: Une loi de compatibilité IPv6 ? (ceci n'est p as un troll)
On 12/11/2010 12:23 AM, Guillaume Leclanche wrote: Oui enfin faut pas exagérer, la raison pour laquelle tlm fait du NAT c'est historique. Les déploiements paquet on commencé tout petits et on a gardé la structure d'adressage. Le NAT est là, on connaît, ça marche, on garde. Sans parler du support IPv6 sur les end-devices qui était moisi (android/iphone) jusqu'à cette année. Maintenant les opérateurs sont à court de RFC1918 de toute façon. Ce sera probablement le principal vecteur de déploiement (en particulier pour LTE ?). Implémenté correctement dans Symbian depuis 2002 par contre il me semble :) accusations gratuites Le truc que je ne comprend pas, c'est que finalement plutôt que d'inventer des bidouilles pour contourner IPv4 pendant 10 ans, ça aurait coûté moins cher et été plus productif d'installer les nouveaux équipements/services en IPv6 directement... /accusations gratuites -- Rémy Sanchez signature.asc Description: OpenPGP digital signature
Re: [FRnOG] Une loi de compatibilité IPv6 ? (ceci n'est pas un troll)
On 12/11/2010 01:42 PM, Thomas Klein wrote: Pas tout a fait d'accord - ce n'est pas un échec - c'est juste long a mettre en place... Du côte des provider il y a très peu de contenu dans v6 - du cote client extrêmement peu de demande. Une loi ne va pas pouvoir régler ca - commencent déjà a mettre tout nos serveurs accessible en v6 - ca sera déjà une grande étape ... Si si, la loi aiderait : en gros, côté utilisateur personne ne veut d'IPv6 car il n'y a pas de contenu. Côté fournisseur de contenu, y'a pas d'utilisateurs. Et côté fournisseur d'accès/opérateurs y'a pas de demande ni d'un côté ni de l'autre. En fin de compte, c'est comme le dilemme du prisonnier : personne ne prend de risque et tout le monde y perd. Aujourd'hui disons que tu héberges des sites de e-commerce et que tu veuilles les passer en IPv6. Bah t'es coincé par ce que déjà ton/tes opérateur(s) ne gère(nt) pas, et en plus à cause des connexions cassées tu ne peux pas le faire sous peine de perdre des clients. Maintenant, si y'a une loi qui oblige les opérateurs à bouger, avec à côté le manque d'adresses qui fait aussi bouger les fournisseurs de contenu, finalement les utilisateurs vont automatiquement se retrouver face à du contenu IPv6. La loi servirait à donner la motivation manquante on va dire... D'ailleurs au RIPE 58 (+/- 2) Orange annonçait leur passage en IPv6 et que leurs clients en aurait en 2010. Il leur reste 2 semaines donc c'est un peu mal barré je suppose, mais est-ce que quelqu'un sait où ça en est ? -- Rémy Sanchez signature.asc Description: OpenPGP digital signature
Re: [FRnOG] Une loi de compatibilité IPv6 ? (ceci n'est pas un troll)
On Fri, 10 Dec 2010 14:14:11 +0100, Clément Game cg...@xooloo.net wrote: Quel etait le taux de penetration d'internet dans les foyers francais apres seulement 10ans d'exploitation commerciale ( disons la periode 1994-2004) ? I think i've made my point :-) C. 6,5 millions de Minitels en 1993 [1] (donc, le balbutiement de la micro-informatique) contre 20 millions d'accès haut débit en 2010 (donc à l'époque où on change les PC tellement souvent qu'on peut avoir un PC rien qu'en faisant les poubelles chez ses copains). Si on compare au nombre d'habitants [3], ça fait un minitel pour 9 personnes contre un accès haut débit pour 3 personnes. Donc on a à peine plus de 3 fois plus d'accès Internet que de Minitels après 20 ans de révolutions technologiques. D'ailleurs le Minitel a suffisamment bien marché pour qu'on fasse encore des blagues sur le 3615 dans les collèges aujourd'hui... Peut être que c'était pas le meilleur modèle économique, mais on est très très loin du flop là quand même. [1] http://latts.cnrs.fr/site/tele/rep1/Minitel2.doc [2] http://www.journaldunet.com/cc/02_equipement/equip_hautdebit_fr.shtml [3] http://www.google.com/publicdata?ds=wb-wdimet=sp_pop_totlidim=country:FRAdl=frhl=frq=population+en+france -- Rémy Sanchez --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: Une loi de compatibilité IPv6 ? (ceci n'est pas un troll)
On Fri, 10 Dec 2010 14:49:10 +0100, Francois Tigeot ftig...@zefyris.com wrote: Jérôme Nicolle wrote: Faut pas virer dans le sensationnel, mais il y a au moins un cas ou ça va être hyper problématique : les nouveaux FAI. Il y a pas mal de projets, de petites boites qui se lancent, surtout pour des déploiments de boucle locale. Elles ne seront allumées que dans 12 à 24 mois donc n'auront pas de v4. Ce seront les premiers réseaux d'eyeball full v6. Et clairement, aujourd'hui, ça marche pas. [repost suite à envoi trop rapide] Je ne suis pas d'accord sur ce point: on a aujourdh'ui solution pour faire voir des contenus v4 à des réseaux v6-only, c'est le nat64. Ca marche aussi bien/mal que le nat classique v4 vers v4. On a même des gens qui racontent leurs essais: http://tools.ietf.org/html/draft-arkko-ipv6-only-experience-02 La version courte : http://ripe61.ripe.net/presentations/140-ripe_rome_jari.pdf Et je confirme pour avoir testé ça chez moi, ça marche très bien :) Sauf quand y'a des litéraux IPv4, bien sûr... -- Rémy Sanchez --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: [FRnOG] Re: [FRnOG] Une loi de compatibilité IPv6 ? (ceci n'est pas un troll)
On Fri, 10 Dec 2010 16:52:13 +, Thomas Mangin thomas.man...@exa-networks.co.uk wrote: - Aucune leçon retenue des mauvaises spécifications d'IPv4 (RH0 ?). Je suppose que tu fait reference a http://www.faqs.org/rfcs/rfc5095.html Je regarde .. http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf - Tout ce que le point précédent implique au niveau implémentation : structures de données non alignées, code ultra complexe comparé à l'équivalent v4. Avez-vous déjà jeté un œil aux implémentations open source ? Non donc plus de détails serait apprécié. Pourquoi est-ce plus compliqué ? Les IP ne rentrent pas dans un mot (les long long long int n'existent pas), donc on est obligé de faire des structures un peu bizarres. M'enfin c'est rien de bien méchant je trouve... Après y'a des détails chiants, comme l'obligation de spécifier l'interface pour certaines adresses (lien local par exemple). Et sur des langages de haut niveau (Java, Python, ...), on a la même API, donc l'IPv6 est géré automagiquement. - Le PMTUD... ça ne marche déjà pas en IPv4 alors en IPv6... Résultat (et c'est toi Stéphane qui en parle le mieux sur ton blog) il serait envisagé de limiter la taille des paquets destinés aux nœuds non locaux à 1280 octets ? Et cela *12 ans* après la première RFC sur IPv6 ? On discute à l'IETF de choses aussi basiques, au moment où il ne reste quasi plus aucune adresses IPv4 disponible ??? PMTUD marche bien en IPv6 - il n'y a quasiment pas de firewall :D Google est pas d'accord avec toi :P Durant les dernières années, j'ai entendu la communauté réseau dénigrer IPv6 sans être constructif. Perso, je ne comprend pas pourquoi on a pas fait comme pour ASN32 avec les headers IPv4 mais bon, comme ca n'existe pas Par ce qu'on a changé pas mal de fonctions (pour le meilleur, en théorie), et que les adresses sont 4 fois plus grosses. IPv6 prends plus de place avec ses adresses, mais économise aussi 32 bits sur le reste des entêtes. (enfin, je présume) Je suppose qu'il y a 15 ans on avait le temps de voir venir l'épuisement des IPv4 et donc le luxe de casser la compatibilité... -- Rémy Sanchez --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: Re: [FRnOG] Une loi de compatibilit é IPv6 ? (ceci n'est pas un troll)
On 12/09/2010 01:43 PM, Simon Morvan wrote: Moi je ne peux pas justifier l'obtention d'IP mais je vais en avoir besoin dans les années qui viennent. Je ne suis donc pas sensé ? Que suis-je censé faire ? Était-ce sensé d'être censé faire des réserve (et accélérer l'exhaustion) ? Et puis même, admettons que j'ai des réserves pour 2 ans. Je suis tranquille pour 2 ans mais après ça je pourrais me gratter pour avoir de nouvelles adresses... -- Rémy Sanchez signature.asc Description: OpenPGP digital signature
Re: [FRnOG] Une loi de compatibilité IPv6 ? (ceci n'est pas un troll)
On Wed, 8 Dec 2010 10:51:22 +0100, Pierre Col p...@9online.fr wrote: Sérieusement, si on a obligé par la loi les fabricants de TV à intégrer un tuner TNT, pourquoi ne pas faire de même pour déployer du IPv6 ? Je pose la question : http://bit.ly/loi-IPv6 Ca vous semble délirant ? Bah, le gouvernement américain fait plus ou moins ça avec ses mandats OBM... Par contre gérer IPv6 c'est une notion très très très très large, étant donné tout ce qu'on a construit autour d'IPv4 qui prendra encore des années à porter en IPv6... On a même des morceaux pas finit, du genre l'IPv6 mobile ou le multicast, on sait pas encore vraiment si ça fonctionne à grande échelle. Une loi pour forcer l'arrivée d'IPv6 j'veux bien, mais celle proposé là est un peu complètement à côté de la plaque : les équipementiers gèrent tous un minimum d'IPv6 (au moins de quoi compenser IPv4), quand aux terminaux y'a pas de soucis à se faire non plus, c'est même limite si ils ne forcent pas la main à l'utilisateur (Apple avec ses AirPort qui font du 6to4 automatiquement ou encore Microsoft et ses tunnels Teredo, par exemple...). Le premier truc à changer aujourd'hui, c'est forcer les opérateurs à proposer IPv6 à leurs clients. Sans ça, c'est difficile pour les utilisateurs comme pour les fournisseurs de contenu de faire le premier pas... -- Rémy Sanchez --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Firewall HTTP
On 11/26/2010 12:56 PM, e-t172 wrote: Mon opinion, qui n'engage que moi, est que tu te trompes de problème. Ton problème n'est pas que tes utilisateurs ne peuvent pas faire de la VoIP pendant qu'ils ont Rapidshare qui tourne à plein régime. Ton problème c'est que tes utilisateurs puissent se marcher sur les pieds, c'est-à-dire que quelqu'un qui fait du DDL puisse faire chier son voisin qui lui n'a rien demandé et ne demande qu'à faire son entretien d'embauche via VoIP. Autrement dit, tu veux nous parler de différenciation par service, moi je veux te parler de différenciation par utilisateur. Pour moi, la meilleure solution à ton problème consiste à rétablir la « justice » (Fair Queuing) entre les utilisateurs. C'est-à-dire quelqu'un qui ouvre 1000 téléchargements ne puisse pas mettre tous les autres à genoux sous la congestion. Ça devrait même être une règle élémentaire de sécurité : un individu qui empêche tous les autres d'utiliser le réseau, on appelle ça un Denial of Service, non ? La solution est simple : au lieu de faire des queues par type de service (ToS), tu fais des queues par utilisateur (IP source). C'est possible sous Linux avec ESFQ, je ne sais pas pour les autres plateformes. Avec cette solution, tu as la garantie que la bande passante est découpée de manière équitable entre les différents hôtes de ton réseau. Imaginons que ton tuyau fait 10 Mbits, et que deux utilisateurs font du DDL. Eh bien les deux auront 5 Mbits chacun, même si l'un ouvre 100 connexions et l'autre 2. Plus intéressant : si quelqu'un fait du DDL et qu'un autre veut faire de la VoIP, la VoIP aura toujours priorité par rapport au DDL car elle consomme beaucoup moins de bande passante et n'atteindra donc jamais le quota. La VoIP passera donc comme sur des roulettes, et toute la bande passante nécessaire sera prise sur le téléchargement du voisin (qui l'aura bien cherché). Dans tous les cas l'utilisation du tuyau est optimale : par exemple le téléchargeur aura 9 Mbits et la VoIP en aura 1, car elle ne demande pas plus. Par contre, le point important ici, c'est que ces 1 Mbits sont *garantis* par le système. Le principal avantage est qu'il est impossible de tricher : l'utilisateur aura beau tenter de tunelliser ou de forger les champs ToS de ses paquets IP, ça ne changera strictement rien car tout est basé sur son adresse IP, qu'il est impossible de falsifier (enfin, j'espère). Un problème persiste cependant : si tu es vraiment fauché au niveau de la taille de ton tuyau, tu pourrais te retrouver avec 100 téléchargeurs sur un tuyau de 1 Mbits, ce qui fait que chaque personne se retrouve avec 10 kbits… et là, c'est l'horreur et même la VoIP ne passe plus. Comme cela a déjà été dit sur ce fil la vraie solution est d'augmenter la taille du tuyau, mais si ce n'est pas une option, je suggèrerais d'ajouter un burst qui permettrait à chaque utilisateur de dépasser son quota à condition qu'il ne le fasse pas trop longtemps. Ainsi les téléchargeurs auraient le burst épuisé en permanence car ils pompent en continu, mais par contre ceux qui font autre chose auraient du burst en réserve et gagneraient donc la priorité sur les téléchargeurs, jusqu'à un certain point. Par exemple avec un burst de 50 Mo, c'est plus que suffisant pour y caser une longue conversation en VoIP, qui passera comme sur des roulettes même avec 1 téléchargeurs fous à côté. En d'autres termes, le système « punit » automatiquement ceux qui pompent en continu sur le tuyau. Bon, avant toute chose j'aimerais préciser que dans mon mail de base je ne parlais absolument pas d'optimiser mon cas particulier, mais bien de lancer le débat sur l'intérêt de considérer le HTTP comme un protocole de transport dans les firewalls, par ce que le web change toussa, et mon cas particulier de débit trop faible n'était là que pour expliquer d'où me venait l'idée, que j'ai considérablement élargie depuis. Bref je l'ai dit assez de fois. Je suis entièrement d'accord avec le fait qu'il faille limiter la bande passante par utilisateur et non par connexion ! Et merci beaucoup pour tes arguments ainsi que tes informations, car c'est bien plus développé que ce que j'ai trouvé jusqu'à présent, ça va m'aider à avancer :) . @Rémi: oui nos utilisateurs sont authentifiés, donc on a une IP (enfin un subnet) par utilisateur. -- Rémy Sanchez signature.asc Description: OpenPGP digital signature
Re: [FRnOG] Firewall HTTP
On 11/25/2010 11:20 AM, Guillaume Esnault wrote: Cette discussion me met mal à l'aise. Ce genre d'outil relève de l'écoute sur le contenu ou le langage (Layer7). C'est comme si nous faisions des écoutes téléphoniques automatiques. Selon ce qui est dit il serait fait certaines actions. Certain organismes comme la NSA (Echelon) le pratiquent à grande échelle. Ce n'est pas légal et c'est dangereux. (cpdt, il n'y a pas encore de jurisprudence, il me semble) Il est certain que chez Digicube nous ne pratiquerons jamais ce genre de chose. L'usage d'un proxy tu classes ça comment alors ? Quand tu mets un proxy pour le cache c'est le même topo, sauf qu'en plus tu gardes les données... Et quand tu met un proxy pour bloquer les accès à certains sites, c'est encore pire (même si très franchement ne n'adhère pas du tout avec cette pratique là). C'est pas un peu extrême de comparer d'un côté la prioritarisation de certains flux pour améliorer le service qu'ils rendent et de l'autre côté Echelon ?... -- Rémy Sanchez signature.asc Description: OpenPGP digital signature
Re: [FRnOG] Firewall HTTP
On 11/25/2010 11:52 AM, Rémi Bouhl wrote: Le proxy sert de cache donc évite de re-télécharger plusieurs fois les mêmes contenus, tout simplement? Bon, avec le Web 2.0 c'est moins utile. Même pas, vu qu'avec le web 2.0 tout le monde va sur les^Wle même site (ça commence par face et ça finit par book), et qu'en plus tout le monde regarde le même contenu, et que tout ça est stocké sur un CDN, on se retrouve avec pas mal de contenu à mettre en cache vu par tout le monde. -- Rémy Sanchez signature.asc Description: OpenPGP digital signature
Re: [FRnOG] Firewall HTTP
On 11/25/2010 03:29 PM, Pierre Chapuis wrote: On Wed, 24 Nov 2010 22:02:08 +0100, Rémy Sanchez remy.sanc...@hyperthese.net wrote: Bon et finalement, est-ce que la QoS sert à quelquechose ? Par ce que si on résume, la QoS ne sert à rien quand on a assez de bande passante, et elle n'est pas assez efficace quand y'a pas assez de bande passante... Bien résumé. Encore plus court : la QoS sur un réseau IP ne sert à rien et est même néfaste. Je sais que tu ne veux pas en parler mais j'ai été exactement dans le même cas que toi avec ta résidence étudiante. Si tu ne peux pas limiter la taille du tuyau, la solution est de compter les paquets et/ou les octets qui passent dedans pour chaque utilisateur et de faire en sorte que la somme totale ne dépasse pas ton débit maximal. Pas besoin de regarder dans les paquets. Ça n'est pas de la QoS, c'est du best effort. Si tu commences à faire de la QoS, tu vas avoir deux profils d'utilisateurs : les geeks qui vont comprendre ce qui passe et tunneler dedans, et les gens normaux qui vont se faire avoir. En pratique, une simple limite en upload et en download par jour, semaine et/ou mois suffit dans ce genre de contexte. Après, tu es plus ou moins obligé de regarder dans les paquets IP quand même si tu es relié à un réseau du type Renater, mais c'est un autre problème... Donc le DiffServ co c'est une vaste fumisterie ? On s'est amusé à utiliser de précieux octets dans les entêtes IP pour rien ? Personne ne fait de QoS ? Je voudrais pas faire le mec relou qui met du temps à comprendre (même si à priori cette discussion gonfle tout le monde :/), mais j'ai du mal à me mettre en tête que tout ça ait été inventé pour rien... C'est quand même pas des clowns à l'IETF non ? -- Rémy Sanchez signature.asc Description: OpenPGP digital signature
Re: [FRnOG] Firewall HTTP
On Wed, 24 Nov 2010 14:57:56 +0100, Mathias WMN m.wo...@wm-networks.fr wrote: Bonjour, Ce que tu cherches, n'est-il pas du filtrage de niv 7 ? L'idée est de déterminée selon un pattern le flux, de le tagger et ensuite appliquer les régles que tu souhaites (filtrages, QoS ...). Cordialement, Probablement que ça rentre dans cette catégorie, mais ce que je veux surtout c'est pouvoir considérer le HTTP comme un protocole de niveau 4. Le nombre d'applications web et/ou passant par du HTTP est devenu tellement important que je pense qu'on a plutôt intérêt se mettre à la vitesse supérieure et considérer ce qui passe dans le HTTP comme des protocoles à part entière. Sinon avec quoi tu ferais ton filtrage de niveau 7 ? Une recherche rapide me donne ce genre de résultats : http://firewalls.smile.fr/L-offre-open-source-en-matiere-de-filtrage/Filtrage-niveau-7, qui préconise l'usage de Squid, ce qui comme je le disais dans le mail précédent n'est pas vraiment adapté à ce genre d'usages... (ou alors, j'ai raté un épisode :) ) -- Rémy Sanchez --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Firewall HTTP
On Wed, 24 Nov 2010 16:13:36 +0100, Raphaël Jacquot sxp...@sxpert.org wrote: On Wed, 2010-11-24 at 16:10 +0100, Rémy Sanchez wrote: Pour situer mon contexte et l'origine de mon idée : je m'occupe du réseau dans une résidence étudiante, avec un débit très limité par rapport au nombre d'utilisateurs. ne faudrait il pas commencer par la ? genre, augmenter le débit disponible de maniere substantielle, plutot que d'essayer de gerer la rareté de maniere sous-optimale ? On accepte les dons mensuels en virement, chèque ou espèce si tu veux :) Plus sérieusement, on fait ce qu'on peut, car on a des ressource matérielles et humaines limitées. Mais c'est pas du tout de ça que je voulais parler, en fait. L'idée me vient de là, mais dans mon cas précis on a pratiquement réglé tous nos problèmes. Le constat est que tout passe dans un énorme tuyau qu'est le HTTP et que peut être qu'il faudrait y mettre plus de contrôle à l'intérieur, avec des nouveaux outils plus adaptés que ce qu'on a aujourd'hui. -- Rémy Sanchez --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Firewall HTTP
On Wed, 24 Nov 2010 16:57:50 +0100, Julien Richer jul...@ywigo.fr wrote: Le 24 novembre 2010 16:10, Rémy Sanchez a écrit : Pour situer mon contexte et l'origine de mon idée : je m'occupe du réseau dans une résidence étudiante, avec un débit très limité par rapport au nombre d'utilisateurs. Et on ne peut pas dire que tout soit bloqué sur le réseau, on ouvre les ports à la demande. Seulement, j'aimerais que le débile de base qui télécharge 10 trucs en même temps n'empêche pas le type qui a entretient d'embauche de faire de la VoIP (le problème n'existe plus au fait, on a trouvé des solutions quand même). Comment tu prends la décision que - la conversation en voip est importante (entretien d'embauche ou teamspeak pendant un WoW ?) - le download n'est pas important (divX méchant illégale ou dossier important ?) Normalement la réponse est donc : - on fait de la Qos pour répartir au mieux le débit (et donc ne pas avantager celui qui ouvre 10 flux avec un download manager) - mais on ne regarde pas ce qu'il fait car 1- il fait ce qu'il veut 2- même avec de la bonne volonté tu n'arriveras jamais à savoir si c'est vraiment important ou pas sans te tromper Bien sûr qu'on n'écoute pas le contenu des conversations pour juger si elles sont importantes. C'était un exemple, pour illustrer un peu... Par contre en règle générale on veut que la VoIP aille vite alors que de lancer 10 connexions HTTP pour un même fichier c'est carrément pas fair play. Et si ça t'intéresse, des retours qu'on a eu, les gens font surtout de la VoIP pour WoW, un peu pour téléphoner à leurs parents, et de temps en temps pour un entretient d'embauche. Quand aux téléchargements c'est très souvent illégal mais on a eu des cas où des gens ont eu un service trop lent pour télécharger un fichier qui était important pour leur stage. Mais encore une fois, j'aimerais ne pas parler de ce problème en particulier. Plutôt, je viens ici pour savoir si quelqu'un voit une utilité ou une cohérence quelconque à un outil capable de comprendre le HTTP et les protocoles qui y circulent à l'intérieur, dans le but principal de faire de la QoS ? (et pourquoi pas bloquer les tunnels, bien que sur ce point je pense que la réponse soit assez claire). -- Rémy Sanchez --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Firewall HTTP
On Wed, 24 Nov 2010 16:59:47 +0100, Rémi Bouhl remibo...@gmail.com wrote: Je plussoie l'idée. Inutile d'aller chercher au niveau de la couche 7 ce que les gens font vraiment (et, à tout prendre, ce n'est pas à l'admin de décider de ce qui est prioritaire, même en faisant preuve de bon sens). Une répartition équitable en garantissant un minimum à chaque utilisateur, et le tour est joué :) Mes utilisateurs vont être content avec leur 100kbps par personne tiens :) Je ne parle pas de décider que tel ou tel site soit plus important, mais on a bien inventé la QoS pour une raison non ? Par exemple, pour que de la VoIP passe plus vite qu'un gros fichier qui passe en FTP. Bon maintenant si la VoIP et le gros fichier passent tous les deux par le HTTP, tu fais quoi ? Kif kif comme si y'avait pas de QoS ? C'est malheureux mais beaucoup de protocoles convergent vers le HTTP. Je veux pouvoir les distinguer pour avoir une qualité de service appropriée. Pas décider que les films de cul de Bob valent plus que les séries à l'eau de rose d'Alice. -- Rémy Sanchez --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] Firewall HTTP
On Wed, 24 Nov 2010 08:25:14 -0800, Michel Py mic...@arneill-py.sacramento.ca.us wrote: Rémi Bouhl Du coup je propose la solution couillue: ouvrir les vannes sur les autres ports. Laisser sortir ce qui était encapsulé en HTTP, afin qu'HTTP redevienne ce qu'il n'aurait pas du cesser d'être. Oyez braves utilisateurs, vous pouvez sortir en SSH, en VPN et en RDP, inutile de faire des tunnels HTTP. +1 Chaque fois qu'on rajoute une couche, quelqu'un invente une bidouille pour la contourner. A force, pour accéder à sa propre bécane à quelques kilomètres on va se retrouver avec une usine à gaz qui consomme la moitié de la bande passante en encapsulations successives et envoie le trafic en Suède via le Srilanka. +1 aussi J'suis le premier à vouloir faire ce que je veux du réseau. Et le premier à faire des tunnels. J'ai compris que le blocage des tunnels, c'est une mauvaise idée, et en fait c'est pas vraiment utile, donc sur ce point là c'est clair. Mais le fait est que là 95% du flux de données passe par du HTTP, et qu'on commence vraiment à avoir des types d'applications variées qui se distingues. Comme ce qu'on avait en TCP/UDP avant, mais remonté de quelques couches. J'y peux rien si Internet vire au n'importe quoi, mais j'ai envie de proposer des solutions pour garder un service de qualité :) . -- Rémy Sanchez --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Firewall HTTP
On Wed, 24 Nov 2010 17:29:37 +0100, Mehdi AMINI joker@gmail.com wrote: Salut, Je ne parle pas de décider que tel ou tel site soit plus important, mais on a bien inventé la QoS pour une raison non ? Par exemple, pour que de la VoIP passe plus vite qu'un gros fichier qui passe en FTP. Ben ouais la QoS c'est pour ça, mais pas besoin de monter au niveau 7 pour garantir ça... Bon maintenant si la VoIP et le gros fichier passent tous les deux par le HTTP, tu fais quoi ? L'erreur est là : pourquoi tes utilisateurs font de la VOIP en HTTP ? Parler de Qualité de Service et VOIP over HTTP dans la même phrase c'est possible ??? Si l'utilisateur ne veut pas utiliser autre chose que HTTP, tant pis pour lui :-) C'est malheureux mais beaucoup de protocoles convergent vers le HTTP. Je veux pouvoir les distinguer pour avoir une qualité de service appropriée. T'as des exemples réels ? Parceque à part la VOIP que t'as ressorti plusieurs fois, c'est quoi ces fameux protocoles au dessus d'HTTP qui méritent tant d'attention ? Ok j'avoue la VoIP c'était assez extrême, et y'a pas grand monde qui fait ça (voire, personne (sauf Skype ? je sais plus)). De toute façon ça serait débile, on leur ouvre toujours les ports de leur TS aux utilisateurs :) Pour moi, y'a plusieurs familles de (plus ou moins) protocoles qui émergent : * Le bon vieux HTTP standard, avec téléchargement de petits fichiers un par un. * Le HTTP toujours standard, mais avec du téléchargement de gros fichiers avec potentiellement des abus à l'aide d'accélérateurs de téléchargements. * Les protocoles internes aux applications, avec des micro-requêtes en Ajax. * Les long poll, comet et autres techniques de PUSH HTTP. En somme, pourquoi l'accès à un traitement de texte en ligne devrait être traité avec la même priorité qu'un téléchargement de masse ? Ce sont deux services totalement différents, avec des besoins totalement différents aussi. De la même manière qu'on va faire passer le SSH avant le FTP, la communication évènementielle de la dernière appli à la mode devrait passer avant un téléchargement sur megaupload. Pour répondre en diagonale aux autres messages : oui les utilisateurs qui font tout passer en HTTP sont débiles, mais en fait c'est le cas de n'importe qui surfant sur le web. C'est largement suboptimal, mais tout tend à tourner dans le navigateur. Et encore une fois je ne dis pas que c'est impossible à gérer avec ce qui existe (variante: oui il y a des solutions à mes problèmes, et oui je les utilises). Je suggère juste la création d'un outil adapté, qui au lieu de demander des heures à concevoir et tuner une config, permettra d'avoir une config par défaut qui marche directement, sans avoir à détourner les fonctionalités du logiciel. J'veux dire par là, oui on peut faire un proxy avec nfqueue, bash, wget, rsync et 2 ou 3 autres, mais c'est carrément pas aussi adapté que Squid. Je veux différencier les flux HTTP, mais Squid n'est pas adapté pour ça. -- Rémy Sanchez --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Firewall HTTP
On 11/24/2010 07:04 PM, Radu-Adrian Feurdean wrote: Pourquoi ? Pour qu'un service qui a besoin d'une bonne réactivité mais de peu de débit ne soit pas pénalisé par un service qui se fiche de la réactivité mais mange du débit à fond ? On a pas encore appris les lecons du controle au nieveaux 3 et 4 ? Faut imperativement faire les memes erreurs au niveau 7 ? Pas moi en tout cas, quelles sont-elles ? On m'a toujours vendu la QoS en disant que c'est trop cool, mais je suis curieux d'entendre des contre-arguments. -- Rémy Sanchez signature.asc Description: OpenPGP digital signature
Re: [FRnOG] Firewall HTTP
On 11/24/2010 07:19 PM, Radu-Adrian Feurdean wrote: Tu peux aussi revoir legerement ton architecture. Tu suggères ? -- Rémy Sanchez http://hyperthese.net signature.asc Description: OpenPGP digital signature
Re: [FRnOG] Firewall HTTP
On 11/24/2010 07:26 PM, Radu-Adrian Feurdean wrote: Pour la n-ieme fois, le rappel (en anglais cette fois): We're network admins. To us, data is just a protocol-overhead. Oublie tout ce qui depasse le niveau 3 !!! Tu peux encore faire du QoS nu niveau 3, faut juste revoir ton facon de voir les choses. Moi j'veux bien faire du DiffServ, mais à un moment faut qu'on me mette les champs à la bonne valeur. À ma connaissance, les navigateurs ne savent pas faire ça, et il n'existe pas d'outil (libre, vu que dans le commerce ça a l'air d'exister) pour différencier facilement les flux assez finement. D'où le problème initial de coder une application capable de faire de la QoS là dessus (ça peut juste vouloir dire qu'on met le DSCP à la bonne valeur). -- Rémy Sanchez signature.asc Description: OpenPGP digital signature
Re: [FRnOG] Firewall HTTP
On 11/24/2010 09:05 PM, Mattieu Baptiste wrote: 2010/11/24 Rémy Sanchez remy.sanc...@hyperthese.net: Moi j'veux bien faire du DiffServ, mais à un moment faut qu'on me mette les champs à la bonne valeur. À ma connaissance, les navigateurs ne savent pas faire ça, et il n'existe pas d'outil (libre, vu que dans le commerce ça a l'air d'exister) pour différencier facilement les flux assez finement. D'où le problème initial de coder une application capable de faire de la QoS là dessus (ça peut juste vouloir dire qu'on met le DSCP à la bonne valeur). Je me permets de répondre parce que je connais particulièrement bien la résidence dont tu parles ;) Tout ce que tu penses être tes problèmes sont des non-problèmes. Par contre, tu en as un vrai de problème : TU MANQUES DE BANDE PASSANTE. Tu te plains que tout le monde peut faire ce qu'il veut dans HTTP ? Ouvre avec modération le trafic que tu souhaites ne plus voir passer dans du HTTP... euh... mais je crois savoir que c'est déjà ce que tu fais actuellement... Tu te plains que tout le monde peut mettre tout ce qu'il veut dans HTTP donc il faudrait un outil top cool moumoutte pour filtrer (et faire je ne sais quels calculs magiques dont toi même tu ne sais expliquer, pour catégoriser les services qui passent dans HTTP) ? Et tu feras quoi quand un mec utilisera son propre outil non connu par l'outil top cool moumoutte, pour faire un VPN qui mettra son flux dans des balises normales HTML, ressemblant à du contenu normal... et que ce mec pompera l'intégralité de la bande passante... Tu n'es pas satisfait de squid ? De toute façon votre histoire de proxy ce n'est que du bullshit. Vous maintenez des stats sur l'utilisation du cache de votre proxy ? Vous avez des stats réels de l'utilisation avec/sans proxy à la longue ? Avec le *profil* de tes utilisateurs, le proxy sera inutile pour plusieurs raisons : - Sur facebook/youtube/WTF, les utilisateurs ne consultent que ce qui les intéressent eux, - De très nombreux sites ont une politique de cache ultra restrictive, - HTTPS ? Le cache... aujourd'hui il est dans le navigateur. Mis à part l'image du jour google et quelques conneries, le proxy ne sert à rien. La QoS (celle que tu entends) n'existe pas ? Eh oui... bienvenue dans le monde réel. Ta QoS tu la fait sur du niveau 3/4. Pour en faire dans HTTP, voir le cas d'utilisation d'un outil inconnu, top cool moumoutte, qui fait du VPN. Je vais encore le répéter, tu as un problème : la bande passante. Quelles que soient les bidouilles que tu arriveras à trouver, on reviendra au même problème initiale. Tu veux résoudre tes problèmes : UPGRADE. Enfin... comme le disent les autres réponses précédentes, ta tâche elle s'arrête au niveau 3/4. Au dessus, les utilisateurs font ce qu'ils veulent (et si ce n'est pas le cas, ils trouveront de toute façon une manière de faire ce qu'ils veulent). Tu as des abus réguliers ? Tu souhaites t'en débarrasser ? 1 C'est ton boulot quotidien d'admin. 2 A toi d'éduquer (aussi durement que tu le souhaites) les utilisateurs pour plus que ça ne se reproduise. 3 Un réseau en pilote automatique, je n'ai pas encore sorti ma boule de cristal, mais je te mets au défi de le trouver. Je voulais justement pas ramener la résidence en question sur le tapis par ce que je sais très bien que les problèmes viennent de la bande passante, et tu sais comme moi à quel point on n'a pas de budget. Donc c'est un peu une impasse. Quand à éduquer les utilisateurs... Déjà ils lisent pas les papiers/mails qu'on leur donne aussi court soient-ils, et en plus ils changent tous les ans. M'enfin, c'est pas le problème, ce troll là on l'a déjà assez souvent pour éviter de le ramener ici. La question était bel et bien générique, à savoir est-ce qu'un tel logiciel peut être intéressant dans un nombre suffisant de cas ? Je me demande si, étant donné que la quasi exclusivité du trafic est du HTTP, est-ce que ça a du sens d'essayer de le considérer administrativement comme un protocole de transport ? Bon et finalement, est-ce que la QoS sert à quelquechose ? Par ce que si on résume, la QoS ne sert à rien quand on a assez de bande passante, et elle n'est pas assez efficace quand y'a pas assez de bande passante... -- Rémy Sanchez signature.asc Description: OpenPGP digital signature
Re: [FRnOG] Firewall HTTP
On 11/24/2010 11:05 PM, Radu-Adrian Feurdean wrote: On Wed, 24 Nov 2010 22:02:08 +0100, Rémy Sanchez remy.sanc...@hyperthese.net said: par ce que je sais très bien que les problèmes viennent de la bande passante, et tu sais comme moi à quel point on n'a pas de budget. Donc T'as un probleme de bande passante, t'as de utilisateurs qui veulent de la bande passant ? 1. Augmente tes prix 2. Cree des services premium, plus chers, pour ceux qui veulent plus, qui te permettent de financer ta bande passante Et enfin, la BP est chere uniquement sur la boucle locale. Des que tu arrives dans un DC, ca coute presque rien (si jamais t'as encore de probleme en DC, tu prononce le mot magique Cogent et tout le monde rentre dans les rangs). On étudie la liaison IPoAC pour arriver au point de présence de Cogent le plus proche :) Y'a pas moyen d'avoir un centime de budget supplémentaire, pour l'instant on est bien parti pour rester sur le modèle actuel (y compris la facturation etc). C'est vraiment une petite échelle (~150 étudiants), donc rien de trop faisable à ce niveau. Mais s'il vous plaît, est-ce qu'on pourrait arrêter de parler de cette résidence ? Même si c'est un problème rencontré là bas qui m'a poussé à me poser la question, le but du jeu n'était pas de trouver un moyen magique de faire rentrer plus de choses dans le même tuyau. C'était juste une interrogation générique, que j'ai formulé et re-formulé 1 mail sur 2, donc je vais éviter de le refaire ici. En tout cas, merci à tous pour vos réponses :) -- Rémy Sanchez signature.asc Description: OpenPGP digital signature
RE: [FRnOG] black list d'IP en IPv6
On Tue, 23 Nov 2010 09:56:48 +0100, Jacot Antoine antoine.ja...@he-arc.ch wrote: Bonjour, Il ne faut pas non plus perdre de vue le mécanisme Temporary address interface identifiers (RFC 3041) mis en place par Microsoft dans Vista et Seven qui fait en sorte que l'adresse change volontairement souvent pour garantir un certain anonymat aux utilisateurs. (contrairement à l'EUI-64 qui donne toujours la même host portion de l'adresse). Donc pas terrible pour gérer des black-lists non plus. Salutations, Antoine Je serais d'avis de juste blacklister un subnet complet, ça forcera les administrateurs et madame Michu à assainir leur réseau (et puis madame Michu est déjà obligée de toute façon). Avec 18 trillions d'adresses à la disposition du (in)volontairement méchant utilisateur, ça va être dur de faire autrement :/ -- Rémy Sanchez --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] black list d'IP en IPv6
On 11/23/2010 07:53 PM, Antoine MUSSO wrote: Mon objectif est justement de ne pas bloquer tout le subnet (ex: /48) mais d'essayer de cibler l'utilisateur au plus juste. Ça dépend contre quoi tu te bats et avec quoi. Si je comprend bien, tu a un outil pour blacklister automatiquement des IP, en les détectant comme étant des botnets ? Déjà à priori le botnet est sur un seul réseau, donc besoin de bloquer uniquement un /64. Ensuite, au lieu de bloquer directement les subnets infectées, tu peux bloquer les IP une par une au début, et avoir un compteur : disons à partir de X IP bloquées, ça fait sauter le subnet. Le problème c'est surtout qu'on va se prendre une avalanche de requête nous demandant pourquoi on ne peut pas accéder au site. Et çà c'est réellement contre-productif. Tu as toujours la solution à la Google qui consiste à balancer un test de Turing à la gueule de l'utilisateur blacklisté pour qu'il prouve son humanité (enfin bien sûr, mettre 15 secondes à afficher la page et n'accepter qu'une connexion simultanée, pour éviter le flood et autre). Et puis un petit mail au cas où le problème persiste... -- Rémy Sanchez signature.asc Description: OpenPGP digital signature
Re: [FRnOG] black list d'IP en IPv6
On 11/23/2010 07:16 AM, Laurent GUERBY wrote: Quels sont les fournisseurs les plus radins actuellement ? En pratique ça descends en dessous du /64 pour l'utilisateur final ? Tu parles des fournisseurs grand public ? OVH donne un /64 et Free donne un /60 dont on n'utilise que le premier /64 (mais avec son propre modem on peut utiliser le reste). Si tu regarde à l'étranger, il me semble que XS4ALL donne un /56 voire un /48 à ses clients finaux. De même pour les tunnels de HE, on a un /64 de base et un /48 à la demande. -- Rémy Sanchez signature.asc Description: OpenPGP digital signature
Re: [FRnOG] RE: [FRnOG] lettre au père noël
On 11/21/2010 05:57 AM, Michel Py wrote: En anglais on appelle ça the killer app. C'est dans la lettre au père noël de l'IETF tous les ans depuis 15 ans. On se demande ce que le père noël fait, depuis 15 ans, serait-il devenu aveugle? (*) Ma maman m'a dit une fois le père noël est un vieux monsieur, il ne sait pas fabriquer des trucs modernes. Ceci explique cela :D -- Rémy Sanchez signature.asc Description: OpenPGP digital signature
[FRnOG] Re: [FRnOG] RE: [FRnOG] RE: [FRnOG] lettre au père noël
On 11/20/2010 08:01 PM, Michel Py wrote: En plus, ton adresse IPv6 si tu en avais une, elle va changer en permanence, donc tu utilises mobileIPv6, donc il te faut le home agent, donc tu as besoin du serveur avec une IP publique, donc puisque tu l'as déjà tu y laisses le blog et le serveur mail. CQFD Il est totalement impensable que ton opérateur te fournisse le home agent bien sûr... M'enfin mettre mon blog sur mon téléphone j'irais pas tenter le diable non plus, par contre on peut trouver des usages où ça aiderait pas mal, comme par exemple les push mails où pour le coup ça serait vraiment du push (ou alors faire tourner un logiciel de monitoring sur son téléphone, mais l'intérêt pour le grand public est un chouilla limité). Mais c'est pas vraiment dans l'intérêt des opérateurs je crois. Après comme on parle d'IPv6, si ça se trouve va y avoir un nouveau protocole magique super top-moumoute qui va demander obligatoirement l'IPv6 et que les opérateurs voudrons à tout prix l'avoir par ce que ça va leur faire gagner de l'argent en masse. Et comme on est dans une lettre au papa noël, on va espérer que Free fasse des efforts dans ce sens là :D Ho ho ho ho -- Rémy Sanchez signature.asc Description: OpenPGP digital signature
Re: [FRnOG] Re: Afficher la liste de ses « diplômes » dans le .signature (Was: Hijacked the Internet
On Thu, 18 Nov 2010 09:13:40 +0100, frede...@placenet.org wrote: atomicTroll/Mes parents avaient du temps, ils se sont occupés de moi et de ma scolarité, les profs ne m'ont pas servi à grand chose... L'ecole est juste un passe temps jusqu'à ce que tu deviennes grand... Nos fameuses Grandes ecoles Francaises, n'ont ni créé Google, Apple, Facebook etc... y a rien qui sort de ces ecolesque des impots... pour garantir la rente de leur parents/atomicTroll galaticTrollLes écoles d'ingénieur ça sert à me donner du temps libre pour faire autre chose d'utile :)/galacticTroll -- Rémy Sanchez --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: [FRnOG] Re: Afficher la liste de ses « diplômes » dans le .signature (Was: Hijacked the Internet
On Thu, 18 Nov 2010 09:33:05 +0100, Crazysky wrote: Pour l'IPV6, le problème c'est que la seule obligation du référentiel c'est d'être initier. Donc je vous laisse imaginer si on souhaite véritablement comprendre les tenants et aboutissant de cette techno pour pouvoir vraiment la manipuler. BOn après il y a aussi les divergences d'opinion. Car quand je vois le tech réseau de ma boite qui me dit que l'ipv6 ne sert à rien avec le NAT, je suis cencé comprendre quoi ? Que l'IPV6 n'est plus utile ? Pourtant de ce que je lis ici, c'est plutôt urgent. ( on va éviter le hors sujet ^^) Là on est dans un thread qui discute du re-routage de force d'Internet vers la Chine, à la base, donc bon le hors sujet... J'vais quand même faire mon emmerdeur sur l'IPv6 : le NAT a permit de démultiplier les IPv4, mais la techno a aussi ses limites. Je veux bien voir si du NAT444 tournera encore quand on aura tous un frigo sur IP... Sans oublier que le NAT demande lui même une IP publique, y'a bien un jour où on ne pourra plus rien brancher :/ Le NAT et autres solutions de contournement ne sont que des sursis pour IPv4, le problème c'est qu'on a tendance à l'oublier/ne pas le savoir/ne pas l'accepter. -- Rémy Sanchez
Re: [FRnOG] Re: [FRnOG] Re: Afficher la liste de ses « diplômes » dans le .signature (Was: Hijacked the Internet
On Thu, 18 Nov 2010 10:53:48 +0100, Clement Cavadore clem...@cavadore.net wrote: Nat de Nat de Nat ? :-) Juste NAT de NAT en fait. Mais rajoute une couche si tu veux c'est plus drôle :) Si on ne passe pas à IPv6, on te vendra plus un accès internet, mais plutôt une range de ports disponibles sur une IP publique... Remarque y'a une solution face à ça, il suffit de suivre les tendances actuelles : on considère le HTTP comme un protocole de niveau 3 et on pipeline tout à travers une seule connexion, comme ça plus de problèmes de port ! -- Rémy Sanchez --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Présentations RIPE 61 en ligne
On Thu, 18 Nov 2010 13:57:25 +0100, Mohsen Souissi mohsen.soui...@nic.fr wrote: Pour ceux qui comme moi n'ont pas eu la chance de participer à ce RIPE meeting 61 à Rome (cette semaine), voici une consolation : les supports de présentations en ligne : http://ripe61.ripe.net/programme/presentations/ Routage, IPv6 et DNS sont au menu mais bien d'autres choses intéressantes. Il y en a pour tous les goûts. Merci pour l'info :) Par contre il est très regrettable que les fichiers ne soient pas tous converti en PDF comme les années précédentes... Quelqu'un aurait de quoi lire des fichiers .key sous Linux, ou les versions PDF, ou me dire si Measuring IPv6 en vaut la peine ? -- Rémy Sanchez --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: [FRnOG] Re: [FRnOG] Re: [FRnOG] Afficher la liste de ses « diplômes » dans le .signature (Was: Hijacked the Internet
On Wed, 17 Nov 2010 12:06:02 +0100, Crazysky wrote: 2eme simple information, en se basant sur le fait qu'une entreprise qui se réfère au diplôme prend en compte le programme associé. Je comprend le bac +5. Car quand on voit le niveau demandé en BTS, c'est à peine si on doit savoir configurer un switch et faire du routage filtrage avec un routeur. Remarque, en BAC+5 on ne te demande même pas de savoir le faire :) -- Rémy Sanchez
[FRnOG] Re: [FRnOG] Re: [FRnOG] RE: Afficher la liste de ses « diplômes » dans le .signature (Was: Hijacked t he Internet
On 11/17/2010 11:00 PM, Sébastien FOUTREL wrote: A part ça, les derniers BTS info auxquels j'ai fait passer un entretien ne m'ont parlé que de classe A,B,C,D et pas de CIDR (sauf erreur l'usage des classes a été abandonné en 1996 [sinon on aurait épuisé les ipv4 en 98]). D'ailleurs est-ce que quelqu'un a une explication plausible sur pourquoi est-ce que les classes sont toujours enseignées, et même mises en avant, alors que ça n'est carrément plus à jour du tout... Dans le même genre : pourquoi est-ce qu'on enseigne encore l'IPv4 en ignorant royalement l'IPv6, alors qu'un élève formé aujourd'hui a largement plus intérêt à connaître l'IPv6 que l'IPv4 ?... (vendredi approche, j'y peux rien...) -- Rémy Sanchez signature.asc Description: OpenPGP digital signature
Re: [FRnOG] Re: [FRnOG] Re: Détection des botnets et protection des internautes
On Fri, 5 Nov 2010 11:49:16 +0100, Herve Le Guillou wrote: Bravo. Ca élève vachement le débat, des propos qui pourraient être tenus par tout kiddie qui n'a aucune idée de ce que peut être un environnement corporate lourd à gérer. Mais je sais, je sais, si je dis que ce n'est pas possible de changer de système d'exploitation pour plein d'utilisateurs en entreprise qui ne connaissent que Windows, et mal, on va me répondre qu'il suffit de changer les utilisateurs. Le jour où Linux sera impacté par autant de malware que Windows, on fera quoi ? Ca commence déjà à arriver sur Mac, avec au moins 5 éditeurs majeurs anti-viraux qui s'y mettent... RV. Mais tout le monde sait que Linux est meilleur que tous les autres OS. La preuve, il arrive à faire des boucles infinies en 5 secondes ! -- Rémy Sanchez http://hyperthese.net/
Re: [FRnOG] Il a Free, mais il a pas encore tout bien compris... (IPv6)
On Tue, 26 Oct 2010 09:59:25 +0200, Xavier Beaudouin k...@oav.net wrote: Bonjour, Je ressors un vieux thread d'il y a longtemps, mais c'est toujours intéressant de savoir les pb de déploiement IPv6 in the real life. Le problème de subnetter le subnet /64 donné par la FreeBox... Bref, on a une freebox avec un /32 ipv4 en dhcp - monowall - DMZ et LAN cas assez classic du mec qui essayes de protéger un poil son réseau domestique et limiter les effets de bords (type virus, en utilisant HAVP, proxy transparent etc...). Avec l'IPv6 on n'as pas encore vraiment de NAT (et j'aimerais personnellement qu'on ne retrouve pas cette saloperie, mais ceci n'est pas un appel a trolls) Alors quand on a un /64 sur la sortie de la freebox, comment on fait pour avoir sur les 2 lan spécifiques ... de l'IPv6 ? : - On laisse tomber (ce que fut mon cas pendant plus de 2 ans) - On bidouille (ce qui est mon cas now). J'ai eu besoin de bidouiller car je commence a faire des services IPv6 natif (merci relayd pour un vrai LB libre en passant), mais il faut aussi que je les utilisent pour détecter des emmerdes ... Et c'est là qu'il y a pb... J'ai free mais bon l'IPv6 c'est mort. J'ai cherché sur le clicodrome s'il y a avais possiblité de router un ou 2 subnet /64 sur une ipv6 interne - rien. Donc je pris l'option plan B le 6to4... Bon c'est très loin d'être super performant... mais ça marche... Alors une idée du plan je colles un option sur le pannel de free, car je mettrais pas mal de réseaux en production avec ce genre de choses moi ? Merci Xavier--- Liste de diffusion du FRnOG http://www.frnog.org/ Même problème ici. Pas moyen de mettre la main sur un des sous réseaux, même en faisant du 6rd directement... D'ailleurs messieurs de chez free, pourquoi est-ce que vous avez réservé le premier et le dernier subnet du /60 pour la freebox, au lieu de, disons, réserver un /61 pour la freebox et laisser les utilisateurs faire du 6rd eux-même sur l'autre /61 ? Personellement mon plan B va être d'utiliser du broutage pour mon réseau interne, et des tunnels chez HE pour les autres subnets (invités, wifi, ...). Moche mais je garde des perfs potables :/ Au passage : est-ce que Free a toujours ses passerelles 6to4 ? Car depuis chez moi je tombe sur une passerelle de HE à 100ms de ping... -- Rémy Sanchez --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Il a Free, mais il a pas encore tout bien compris... (IPv6)
On Tue, 26 Oct 2010 10:37:58 +0200, Mattieu Baptiste mattie...@gmail.com wrote: 2010/10/26 Rémy Sanchez remy.sanc...@hyperthese.net: Au passage : est-ce que Free a toujours ses passerelles 6to4 ? Car depuis chez moi je tombe sur une passerelle de HE à 100ms de ping... Tu as essayé de changer de passerelle ? Chez moi (92) j'ai moins de 40ms de ping sur la passerelle HE et environ 50ms de ping chez google. Au risque de dire une connerie, comment tu changes de passerelle ? Je parle de l'IP anycast 192.88.99.1, on n'est pas sensé pouvoir la changer celle là :/ Le gros avantage de HE est maintenant de pouvoir personnaliser ses reverse DNS IPv6. Chose impossible chez Free aujourd'hui. Le gros problème c'est qu'ils sont à 7 hops de chez moi (59)... Sachant que j'ai pas mal de trafic IPv6, ça m'embêterais de prendre trop de latence et d'overhead. Après c'est clair que le service de HE est sympa, entre les /48, les reverses et le BGP, y'a de quoi s'amuser :) -- Rémy Sanchez --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Il a Free, mais il a pas encore tout bien compris... (IPv6)
On Tue, 26 Oct 2010 11:17:58 +0200, Mattieu Baptiste mattie...@gmail.com wrote: Quand tu crées ton tunnel tu as à disposition un certain nombre de passerelles. Par exemple pour l'Europe : Amsterdam, NL [ 216.66.84.46 ] Frankfurt, DE [ 216.66.80.30 ] London, UK [ 216.66.80.26 ] Paris, FR [ 216.66.84.42 ] Stockholm, SE [ 216.66.80.90 ] Zurich, CH [ 216.66.80.98 ] Celles là ce sont les passerelles pour les tunnels explicites, mais en plus de ça ils ont des passerelles 6to4 qui répondent à l'IP anycast 192.88.99.1 comme prévu par la RFC. Ce qui fait que quand j'essaie de faire du 6to4 ça passe quand même par chez HE alors que je m'attendais à ce que Free ait laissé ses passerelles, donc obtenir un truc à peu près équivalent au 6rd en terme de perfs. -- Rémy Sanchez --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Il a Free, mais il a pas encore tout bien compris... (IPv6)
On Tue, 26 Oct 2010 11:42:20 +0200, Mattieu Baptiste mattie...@gmail.com wrote: Moi je ne te parle pas de 6to4 mais de tunnel gif(4), ie. du v6 sur du v4, ce qui marche très très bien. Pourquoi tu veux absolument faire du 6to4 (merdique) ? Ça aurait été intéressant dans le cas où Free aurait gardé ses passerelles, pour des questions de perfs. Maintenant à priori ce n'est pas le cas, donc ça n'a plus aucun intérêt. Mais je voulais vérifier si c'était un problème de routage chez moi, ou si Free avait effectivement éteint ses passerelles 6to4. -- Rémy Sanchez --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Il a Free, mais il a pas encore tout bien compris... (IPv6)
On Tue, 26 Oct 2010 11:28:16 +0200, Arnaud Houdelette t...@tzim.net wrote: Les 2 solutions ne pas viables sous FreeBSD. Et pour le proxy NDP, on perds completement l'un des interets d'IPv6 qui est l'autoconf. Avec le brouteur tu gardes ton autoconf, c'est juste que tu met un firewall entre le routeur et les clients... C'est tordu, moche et pas flexible, mais au moins ça marche. Je ne sais pas ce qu'attends free... l'ajout d'une route via l'interface me parrais pas franchement plus compliqué que ca (surtout qu'il me semble que tout le /60 est routé vers le boitier ADSL pour les télésites). D'après mes tests c'est le cas, d'ailleurs comme je le disais tout à l'heure ils ont réservé le dernier subnet pour les télésites, donc ça empêche de déléguer un préfixe à un autre routeur... A moins qu'ils préfèrent implémenter la délégation de préfixes DHCPv6 (DHCPv6-PD) ? Quelqu'un a déjà utilisé du DHCPv6 (en prod) ici ? Ça m'a l'air totalement boiteux pour l'instant, sous Linux du moins... -- Rémy Sanchez --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Il a Free, mais il a pas encore tout bien compris... (IPv6)
On Tue, 26 Oct 2010 11:35:12 +0100, Thomas Mangin thomas.man...@exa-networks.co.uk wrote: Je me demande simplement si ce n'est pas la taille de la mémoire des routeurs qui les poussent a ne pas ajouter la fonctionnalité. Si quelqu'un en sait plus, je suis curieux. Quelle taille mémoire ? Le /60 entier est routé vers la Freebox, et c'est pas 16 préfixes qui vont tuer une Freebox... -- Rémy Sanchez --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Il a Free, mais il a pas encore tout bien compris... (IPv6)
On Tue, 26 Oct 2010 10:19:27 +0200, Rémy Sanchez remy.sanc...@hyperthese.net wrote: Même problème ici. Pas moyen de mettre la main sur un des sous réseaux, même en faisant du 6rd directement... D'ailleurs messieurs de chez free, pourquoi est-ce que vous avez réservé le premier et le dernier subnet du /60 pour la freebox, au lieu de, disons, réserver un /61 pour la freebox et laisser les utilisateurs faire du 6rd eux-même sur l'autre /61 ? Auto-réponse : le premier subnet n'est pas considéré comme réservé par la Freebox, et fera parti des réseaux que l'on poura configurer. Donc y'aura bien un /61, mea culpa. -- Rémy Sanchez --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Il a Free, mais il a pas encore tout bien compris... (IPv6)
On Tue, 26 Oct 2010 14:23:15 +0200, Rémy Sanchez remy.sanc...@hyperthese.net wrote: Quelle taille mémoire ? Le /60 entier est routé vers la Freebox, et c'est pas 16 préfixes qui vont tuer une Freebox... Oups, 8, pas 16... -- Rémy Sanchez --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Il a Free, mais il a pas encore tout bien compris... (IPv6)
On Tue, 26 Oct 2010 13:38:55 +0100, Thomas Mangin thomas.man...@exa-networks.co.uk wrote: Je parle du réseau pas des freebox .. Mon réseau est loin d'être assez gros pour avoir besoin de me pencher sur la question avant quelques années :p Je vois pas où est ton problème en fait ? D'un point de vue infrastructure, Free route déjà toutes les plages vers les Freebox, comme les préfixes sont agrégés ça ne pose pas de problèmes de mémoire. Le seul élément à changer pour que ça marche, c'est la configuration de la Freebox. D'ailleurs à priori si tu remplace entièrement la Freebox, tu peux faire le tunnel 6rd toi même et avoir le /60. -- Rémy Sanchez --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Il a Free, mais il a pas encore tout bien compris... (IPv6)
On Tue, 26 Oct 2010 14:34:27 +0200, Raphaël Jacquot sxp...@sxpert.org wrote: On Tue, 2010-10-26 at 14:31 +0200, Rémy Sanchez wrote: On Tue, 26 Oct 2010 14:23:15 +0200, Rémy Sanchez remy.sanc...@hyperthese.net wrote: Quelle taille mémoire ? Le /60 entier est routé vers la Freebox, et c'est pas 16 préfixes qui vont tuer une Freebox... Oups, 8, pas 16... euh non, ca fait bien 16... 64-60 = 4 2^4 = 16 ;) -- Rémy Sanchez --- Liste de diffusion du FRnOG http://www.frnog.org/ Damned, pourquoi ici http://www.mail-archive.com/frnog@frnog.org/msg03955.html il parle de 4 réseaux dans un /61 alors ?... -- Rémy Sanchez --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Article sur le NAT64 chez Networkworld
On Fri, 22 Oct 2010 10:51:59 +0200, Francois Tigeot ftig...@zefyris.com wrote: L'article complet est ici (en anglais): http://www.networkworld.com/community/blog/testing-nat64-and-dns64 En résumé, les nouveaux réseaux IP seront déployés avec uniquement le support des adresses IPv6. Comme il existe encore énormèment de services qui ne sont disponibles qu'en IPv4, il faut cependant trouver moyen d'y accéder. C'est là qu'intervient la technologie NAT64. Le principe est simple: - les machines utilisent un resolver DNS spécial (DNS64) qui créée des enregistrements à partir des adresses des serveurs IPv4. - ces enregistrements DNS pointent sur un dispositif qui fait de la translation d'adresse entre les mondes IPv4 et IPv6. De cette façon, il est possible de déployer des réseaux uniquement IPv6 et de limiter les investissements nécessaires pour gérer IPv4 à un nombre très réduit de machines. Au moins un FAI (au Royaume-Uni) a déployé un système NAT64 en production. Il est possible de l'utiliser en changeant simplement l'adresse de son premier résolveur DNS. J'ai testé le dispositif et c'est bluffant: pour un poste client tout fonctionne exactement comme avec un NAT IPv4 vers IPv4 classique. C'est en cours de déploiement dans mon appart aussi, avec comme objectif de ne plus avoir d'adresse IPv4 sur mes machines :3 Ça marche bien, par contre quand tu ne passes pas par le DNS pour obtenir les IP, ça marche tout de suite moins bien... (exemple: Bit Torrent) Pour ceux que ça intéresse, http://www.viagenie.ca/publications/2009-11-06-3gpp-ietf-ipv6-shanghai-nat64.pdf (avec entre autre la justification du NAT64 face au NAT-PT) -- Rémy Sanchez --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] M6 replay depuis Bouygues Telecom : pourquoi on arrive aux USA ?
On Fri, 22 Oct 2010 11:56:03 +0100, Thomas Mangin thomas.man...@exa-networks.co.uk wrote: En theorie, oui, en pratique ce n'est pas aussi facile. Il n'y a toujours pas d'agrégation naturelle des IP par zones géographiques. Bah, de toute façon l'IPv4 est mort et l'IPv6 qui sera déployé mondialement d'ici 3 mois va gérer ça parfaitement :) -- Rémy Sanchez --- Liste de diffusion du FRnOG http://www.frnog.org/
