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 &
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 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] [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] 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] 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] 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] 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: [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] 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 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 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 R&D à 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: 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 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] 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 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 :::dddd::/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 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 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] 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 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 20:54:55 Michel Py wrote: > Avant que j'oublie, je pense à ouvrir un MacDo juste en face de l'immeuble > à Rémy, est-ce qu'il y a des investisseurs potentiels sur la liste? :-D Cherche pas on a déjà un Quick :) > Comme Thomas le faisait remarquer: > > Thomas Mangin a écrit: > > Mais c'est vrai que tout serai mieux si une ligne DSL > > coutait €300 par mois ... ou pas ! > > L'accès à l'Internet, c'est un peu comme les automobiles: la marge est dans > le haut de gamme. Donc c'est vrai que Mme Michu paie en partie la facture > du power user, mais elle n'est pas la seule et l'accès "entreprise" paie > aussi. Donc ne pas oublier que si l'accès grand public à 30€ (que la > plupart des lecteurs utilisent et souvent abusent) est dispo, c'est parce > que quelqu'un d'autre paie. Je vais poser une question bête, mais si y'a vraiment pas de marge, pourquoi on en fait ? Comment un opérateur qui ne fait que les particuliers peut-il être rentable ? > >> Michel Py a écrit: > >> Si le câble est en rade (ça arrive quand même pas tous les jours), > >> je change le Default Gateway dans DHCP, tout le monde fait un > >> release/renew et rame sur le T1 en attendant que le câble revienne. > > > > Radu-Adrian Feurdean a écrit: > > Non. Pas envisageable. Il faut que ca marche meme en absence > > du guru local (le seul capable de demarrer un cmd.exe). Et tout > > ca sans surcout > > Bah tu mets un raccourci sur le bureau du serveur, c'est quand même pas si > difficile.. Sinon, on a inventé un truc magique qui s'appelle un "langage de script" qui permet de dire à l'ordinateur de faire des trucs tout seul. Enfin j'dis ça comme ça :D > Remarque, si IPv6 ne te plait pas, tu peux toujours faire comme moi et la > majorité silencieuse: ne pas t'en servir :P C'est sûr, au moins en IPv4 on a du NAT :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 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 ? -- 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 Saturday 02 July 2011 21:37:02 Jérôme Nicolle wrote: > Le 2 juillet 2011 21:16, Rémy Sanchez 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 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] 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 06:06:07 Michel Py wrote: > La quand même faudrait arrêter de rêver un peu; 150 gugusses sur 1 aDSL > pourri et tu t'étonnes que ça rame? C'est comme d'essayer de faire du QOS. > Bon je vais te la donner la solution: 150 x €10/mois ça fait €1500 par > mois, à ce prix là tu peux avoir un bon tuyau. Une ligne aDSL, ce n'est > pas fait pour connecter 150 étudiants. Toi tu es en train de demander une > connexion pour 150 personnes pour gratos ou presque. Non, _j'ai_ une connexion pour 150 personnes pour gratos ou presque. Avec du load-balancing. Qui détecte les (nombreux) défauts de connexion en quelques dizaines de secondes. (Et qui répare ça tout seul 95% du temps). Et de la QoS assez efficace d'ailleurs, si on compare le avant et le après. Et même un cold- corridor entre les chambres, mais seulement quand on ouvre la fenêtre du couloir en hiver. Le service n'est pas idéal ? Qu'importe, personne ne veut payer plus, ça doit être que c'est suffisant. Par contre avec une ADSL de moins, là ça pleure. La seule et unique solution, c'est du multi-homing du pauvre, point. Tant que j'ai pas le même en IPv6, il m'est impossible de déployer IPv6. Et à mon avis y'a tout un tas de structures de taille intermédiaires qui ont effectivement besoin de 2 ADSL, mais n'ont ni la nécessité ni les moyens de se payer mieux. Moralité : sans une bidouille du genre NAT66, tu fout du plomb dans l'aile d'un paquet de gens. > Faudrait de temps en temps se mettre dans les pompes du FAI aussi; tu veux > le beurre, l'argent du beurre, et le cul de la crémière. En fait, ça m'arrive de sortir de ma cave et de voir ce qu'il se passe chez les autres ;) Je comprends parfaitement pourquoi ça me coûterait aussi cher d'avoir mieux, et c'est exactement pour ça que je me contente de ce que j'ai. 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 Friday 01 July 2011 16:20:33 Michel Py wrote: > Mauvais argument. Si tu as une raison valable d'être multihomé, tu as > quelques sous dans des poches. Avant le multihoming, tu vas commencer par > des disques en miroir, une carte raid, une alim redondante, un onduleur... Pas sur lavie.com :) > Et puis quand tu as besoin du multihoming, tu ne fais pas ça avec de l'aDSL > à la Michu. Tu mets ton serveur 1U dans une colo. Mes 150 humains à déservir je les met dans une baie avec un cold corridor pour faire classe ? De base pour des serveurs l'idée ne me serait même passée par la tête de les foutre derrière une ADSL... Je suis dans une zone où l'ADSL est pourri (bout de ligne) et où tout autre solution me coûte un facteur 10. Je rejoins Yoann : si tu es du côté eyeball, ta seule solution pour augmenter la taille de ton tuyau c'est d'agréger plusieurs tuyaux (sans BGP), et donc du NAT66. Après c'est comme tout, le NAT66 est bien pour cet usage, dans l'absolu y'a un tas de cas où ça serait une hérésie de l'utiliser. Mais l'existence de la techno est très importante pour des cas comme celui au dessus, car c'est la seule solution qui ne coûte pas les yeux de la tête, que ce soit en €, en temps humain ou en compétences. Mes 2 centimes, -- 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] Publication du decret LCEN sur les logs services Internet
On 03/01/2011 12:36 PM, Alexandre Archambault wrote: > C'était une question qui revenait régulièrement ici, à savoir qu'est ce que > je suis censé loguer en tant que FSI. > > Après 7 années de gestation difficile, le décret LCEN sur les logs services > Internet a été publié au JO de ce jour. > > <http://www.legifrance.gouv.fr/affichTexte.do;jsessionid=B751B8F7F3F02CB8342572AD305DECB1.tpdjo15v_3?cidTexte=JORFTEXT23646013&categorieLien=id> > > Attention, c'est d'application immédiate, sans délai préalable pour mettre en > place l'usine à gaz qui permettra de tout loger / restituer dans les > meilleurs délais alors qu'en face ils ne semblent guère pressés d'en terminer > avec le papier. > > -- > Alec, Est-ce que quelqu'un a compris le décret ? À l'époque de la LCEN j'étais au collège, je n'avais pas pris le temps de tout comprendre la loi... Qu'est-ce qu'un identifiant de connexion ? L'identifiant attribué à l'abonné c'est son IPv4 publique et l'identifiant du terminal c'est son IPv4 privée ? Et c'est quoi les "caractéristiques de la ligne de l'abonné" ? On doit quand même pas calculer l'atténuation de chaque lien ADSL qui se connecte sur le site... Sans oublier : en tant que personne "dont l'activité est d'offrir un accès à des services de communication au public en ligne" (enfin, si j'ai bien compris), je dois journaliser ces informations. Je veux bien, mais ils parlent de quelle(s) couche(s) ? L'heure de début et de fin de la connexion je veux bien, sur du non connecté on fait quoi ? En gros, ils supposent que le seul protocole d'Internet est le HTTP ou quoi ? -- 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] 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
Re: [FRnOG] IPv4 Exhaustion: RIPE NCC Update
On 02/03/2011 05:52 PM, Michel Py wrote: > La fin du monde tant attendue ha ! On vous avait prévenu que ça arrivait ! -- 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 > | >:-) > | > | > > ==> 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 p
Re: [FRnOG] Re: [FRnOG] Questionnement d'un administrateur système sur l'IPv6
On Tue, 14 Dec 2010 15:38:52 +0100, Mohsen Souissi 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 :-) 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. -- Rémy Sanchez --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [FRnOG] Re: [FRnOG] Re: [FRnOG] Re: [ FRnOG] Questionnement d'un administrateur systè me sur l'IPv6
On 12/14/2010 02:51 AM, Rémy Sanchez wrote: > 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... Bon je savais que j'aurais dû me réveiller avant d'envoyer ce mail, ce que je viens de dire là est parfaitement débile. Reprenons. En gros à mon avis soit le trafic non HTTP est négligeable et dans ce cas là tu le néglige, soit il ne l'est pas, et dans ce cas là : * soit tu cherche à mettre un place un proxy pour ce protocole en réutilisant le même concept que pour le HTTP * soit tu fais tout passer sur une ligne, tu estimes la conso que ça aura et tu compenses en déséquilibrant la répartition du HTTP * soit c'est une appli pour laquelle tu a suffisament de contrôle sur "l'autre bout" pour faire un VPN et du routage propre (j'suis toujours pas complètement réveillé, alors c'est à mettre entre parenthèses) -- 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: > - 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] 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] 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: 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 : % 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'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: [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 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
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
[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 :) 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... -- Rémy Sanchez signature.asc Description: OpenPGP digital signature
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 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: [FRnOG] Re: Une loi de compatibilité IPv6 ? (ceci n'est pas un troll)
On Fri, 10 Dec 2010 15:35:22 +0100, Yves Dubromelle wrote: 2^24 adresses en 10.0.0.0 ça ne suffit pas pour un réseau privé ??? Non, je veux mes 18 trillions d'IPv6 :) -->[ ] -- 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 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] Une loi de compatibilité IPv6 ? (ceci n'est pas un troll)
On Fri, 10 Dec 2010 14:14:11 +0100, Clément Game 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-wdi&met=sp_pop_totl&idim=country:FRA&dl=fr&hl=fr&q=population+en+france -- 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" 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 03:29 PM, Pierre Chapuis wrote: > On Wed, 24 Nov 2010 22:02:08 +0100, Rémy Sanchez > 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 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 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 12:40 AM, Rémi Bouhl wrote: > Tout le monde a compris le problème (plein de gens, font des trucs > très différents en HTTP, pas assez de BP pour tous). Justement, pas vraiment. C'est une vision plus globale : l'usage des réseaux change, est-ce qu'il faut pas changer la manière des les administrer ? C'est une question de fond, abstraite, générique, pour faire de la théorie pure et se demander si les choses doivent rester comme ça. > C'est juste que la solution "fouiller au niveau 7" n'a pas l'air > d'être la seule réponse, ni même la meilleure. > > L'idée plusieurs fois évoquée de partager la BP équitablement (pour > être précis: de garantir un minimum à chaque utilisateur, en toutes > circonstances) est plus simple à mettre en place, plus propre > éthiquement et techniquement, et garantit en toutes circonstances un > équilibre entre les usages. > > Pourquoi ne pas l'envisager? Si bah forcément avec ce qu'on a c'est ce qu'on risque de faire (quoi qu'on s'en sort bien autrement là). Faut pas croire, on a travaillé les différentes configs et maintenant on a un service de qualité très raisonnable tant qu'on cherche pas à voir une vidéo sur youtube. Mais en fin de compte, si elle était possible, est-ce que l'autre approche que je propose serait intéressante ? Je ne cherche pas du tout à la réaliser pour l'instant, je suis à la recherche d'avis purement théoriques, pour savoir si ça serait une bonne pratique, si ça apporterait quelque chose, ... Et au passage si la solution dont je parle existe déjà, ça m'intéresse aussi. -- Rémy Sanchez signature.asc Description: OpenPGP digital signature
Re: [FRnOG] Firewall HTTP
On 11/24/2010 11:33 PM, David Ramahefason wrote: > Je ne te comprend pas trop tu expose un problème précis mais tu ne > veux pas qu'on se focalise dessus. > Tu voulais discuter de quoi exactement ?? Savoir s'il était possible > de faire de la classification de paquets en L7 ?? > La réponse est oui, cela existe depuis plus de dix ans (Packeteer / > Allot et sans doute des solutions Open Source). > Sinon tu as a ta disposition tout plein de "tricks" pour jouer avec la > Qos sur tes équipements et la solution "à la Virgin" me semble > est la plus intéressante pour toi. Avec mon problème précis, je remarque que le HTTP permet de servir un nombre varié d'applications en réseau. Et finalement, plus d'applications passent par le HTTP que par du TCP ou de l'UDP directement. La question porte donc sur les capacités des logiciels actuels en L7 : sont-ils capable de différencier les différentes applications et de prendre en compte leurs spécificités ? Et par là, je veux dire que de plus en plus le HTTP prends la forme d'un protocole niveau 4 voire 3, et par conséquent il y a peut être besoin de le changer la manière dont on le traite. Par exemple, est-ce que les outils actuels sont conçu pour pouvoir reconnaître un accélérateur de téléchargement qui prends simultanément 10 morceaux d'un fichier sur megaupload ? De reconnaître long poll et de lui donner une forte priorité pour baisser la latence ? Le tout avec la configuration par défaut/peu de configuration ? [*] Si les outils actuels en sont incapable, est-ce que cela aurait un intérêt de créer un tel outil ? Les avis sur la QoS semblent partagés, est-ce que cela est vraiment utile ? Peut être qu'aujourd'hui le problème n'est pas flagrant, mais on voit de plus en plus d'applications faire du (quasi) "temps réel". On s'éloigne vraiment loin du principe initial du HTTP... D'où mes interrogations, pour éviter de se retrouver totalement désarmé dans un monde où le HTTP écrase les autres protocoles et où l'on se retrouve sans aucune visibilité sur les types de service. J'ai enfin réussi à bien expliquer ma question ? J'peux recommencer sinon j'suis plus à ça près -_- -- Rémy Sanchez [*] Je sais que le réseau automagique n'existe pas et qu'il faut un minimum savoir ce que l'on fait. Cependant, dans le cas présent tous les gens qui mettraient en place ce genre de solutions auraient à peu près les mêmes problèmes, donc finalement ça ne sert à rien d'écrire la conf indéfiniment... 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" > 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] Firewall HTTP
On 11/24/2010 09:53 PM, Xavier Beaudouin wrote: > Y a un truc que tu peux faire avec squid c'est différencier les "objets" > courts (ajax / traitement de texte / chat [ok je sors]) et les > téléchargements lourds... > Bon c'est du tweak de conf mais ça se fait. C'est plus où moins là où je veux en venir : c'est des choses qu'on fait, mais c'est ni évident ni standard. -- 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 : >> 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 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 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: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 Wed, 24 Nov 2010 17:29:37 +0100, Mehdi AMINI 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 Wed, 24 Nov 2010 08:25:14 -0800, "Michel Py" 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 16:59:47 +0100, Rémi Bouhl 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 16:57:50 +0100, Julien Richer 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:13:36 +0100, Raphaël Jacquot 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 14:57:56 +0100, Mathias WMN 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/
[FRnOG] Firewall HTTP
Bonjour à tous, Les dernières tendances en terme de n'importe quoi consistent à faire passer à peu près tout ce qu'on peut par du HTTP, à tel point qu'on a pratiquement "remplacé" le TCP. Après tout, toutes les applications web passent par du HTTP, or c'est plutôt vaste : distribution de contenu, messagerie instantanée, flux vidéo, traitement de texte, ... Sans oublier toutes les applications qui utilisent le HTTP (par exemple MSN) pour faire passer leur protocole en environnement "restreint", ou carrément les tunnels. En bref, le port 80 est toujours ouvert, soit directement, soit à travers un proxy. Et c'est la porte ouverte à toutes les fenêtres... En fin de compte, serait-il cohérent d'imaginer une application analogue à un firewall, qui au lieu de s'en prendre au TCP s'attaque directement au HTTP ? Ça y est je vois déjà tous les canons pointés en ma direction pour me signaler qu'on a déjà des proxys, IDS et tout un tas de trucs dans le genre. C'est d'ailleurs pour ça que je demande si l'idée est cohérente ou si c'est du grand n'importe quoi. Cependant, je pense à des fonctionnalités qui m'ont l'air difficile à configurer dans les outils pré-cités, comme par exemple différencier les types de flux pour y assigner des priorités (long poll et dérivées, page standard, gros fichier, accélérateur de téléchargements, ...), reconnaître les sous protocoles (comme au dessus, MSN), reconnaître les tunnels, s'en prendre aussi au HTTPS, ... En bref, pouvoir traiter tout ce qui passe par du HTTP comme un flux TCP/IP avec un numéro de protocole et un tag pour la QoS. Les outils que j'ai rencontré jusque là ne permettent pas de faire ça simplement (Squid, pf, iptables pour ceux que j'ai vraiment utilisé), après étant relativement novice en réseau j'ai assez peu touché aux autres outils et aux appliances proprio, donc mon panorama est restreint. Donc qu'en pensez vous, lecteurs avisés de FRnOG ? Un tel outil serait-il utile ? Pour qui ? Qu'y verriez vous à l'intérieur ? Est-ce que j'ai complètement fumé la moquette ? NDLR : l'idée ici est de débattre des fonctionnalités d'un tel produit, non de la manière dont on pourrait les implémenter... Allez c'est parti pour une après midi à prendre des baffes :) -- 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 Tue, 23 Nov 2010 09:56:48 +0100, "Jacot Antoine" 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: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] Présentations RIPE 61 en ligne
On Thu, 18 Nov 2010 13:57:25 +0100, Mohsen Souissi 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: 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 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] 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: Afficher la liste de ses « diplômes » dans le .signature (Was: Hijacked the Internet
On Thu, 18 Nov 2010 09:13:40 +0100, wrote: 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 Les écoles d'ingénieur ça sert à me donner du temps libre pour faire autre chose d'utile :) -- Rémy Sanchez --- Liste de diffusion du FRnOG http://www.frnog.org/
[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: [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
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 14:34:27 +0200, Raphaël Jacquot 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 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/
