Re: [FRnOG] [MISC] En tant que FAI, preferez vous beaucoup de connexion courtes, ou du keepalive?
Le 10/11/2012 09:00, Emmanuel Thierry a écrit : Bonjour, Le 9 nov. 2012 à 13:54, Dominique Rousseau a écrit : Pour vous opérateurs, ça change quelque chose le modèle push serveur - client (et donc le fait d'avoir des connexions persistantes)? Pour compléter ce que dit Jerome (en gros du point de vue réseau, on s'en fout, si le nombre de paquets est équivalent), y'a une catégorie de gens qui « font du réseau », qui ne seront pas complètement d'accord. Il s'agit de ceux qui font du NAT, et qui donc, doivent maintenir une table d'états des connexions établies. Pour eux, une connexion établie qui n'a pas d'activité (pendant X secondes), elle va couter de la ressource mémoire. (mais ceux qui font/vont-faire du Carrier-Grade-NAT sauront surement en dire plus :o) Du coup tu peux appliquer la stratégie contraire: faire essentiellement des connexions keepalive pour surcharger les CGN d'un opérateur qui refuse encore de passer à IPv6, par exemple au hasard un opérateur qui porte le nom de la couleur de son logo ! Il n'y a pas de reel refus de la part de l'opérateur au fruit juteux mais necessité de le faire d'une manièrer structurée et organisée avec audit, étude d'impact et budgétisation. C'est qu'il est un chouillat plus compliqué son réseau que celui de Joe La Frite avec ses 2 lambdas et ses 3 peerings hein ;) La chose etait prévue pour 2013 au dernieres nouvelles... Donc plutot T4 2014 voir 2015 en tenant compte des reports/retards habituels. D'ailleurs je me demande comment les opérateurs vont gérer le multiplexage de (n * 65536) ports vers 65536 ports. Une limite en dur par utilisateur ? Que vont-ils faire des connexions en surplus (refuser la nouvelle connexion ou dropper une vieille connexion) ? Vont-ils encore avoir le droit d'appeler ça un service d'accès à Internet ? Cordialement Emmanuel Thierry --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Re: cadeau - KMZ zonage optique FT
Merci du suivi et d'avoir levé le lièvre... Seb. Le 09/11/2012 18:01, Jérôme Nicolle a écrit : Bonjour à tous, Le zonage optique a été mis à jour le 5/11. Alors qu'on s'attendait à l'augmentation régulière du nombre de communes couvertes, la dernière version fait apparaître une forte baisse du nombre de communes appartenant aux zones 02 et 03. J'ai sollicité la DIVOP pour quelques explications. Je mettrai la carte à jour dès que l'anomalie est confirmée. Références : http://www.orange.com/fr/content/download/7152/104969/version/1/file/couverture+ethernet+5+nov+2012.xls http://www.orange.com/fr/content/download/5905/85187/version/2/file/ZonageoptiqueEthernet%28C2EetCELAN%29publile9dcembre2011.pdf @+ On 15/08/2012 07:47, Jérôme Nicolle wrote: Plop, Comme j'ai pris l'habitude de tout géo-référencer sur mes réseaux, il me manquait une carte d'éligibilité aux offres CEE/CEL pour repérer rapidement les liens intéressants à migrer. J'ai donc assemblé une carte au format KMZ (Google Earth) que vous pourrez trouver là : http://dedibox.nicolbolas.org/CELAN/CELAN-eligibilite-redist.kmz (gaffe, c'est un peu lourd : 19Mo) Pour ceux qui n'ont pas google earth sous la main, une paire de screenshots : http://dedibox.nicolbolas.org/CELAN/CELAN-elig-screenshot.png http://dedibox.nicolbolas.org/CELAN/CELAN-elig-screenshot2.png (vert/orange/rouge : zones O1, O2 et O3. Rien : bah... rien.) Je n'ai pas mis les emplacements des SRTHD, il y a une crasse juridique sur le document qui les énumère et j'ai pas spécialement envie de causer à un avocat dans les mois qui viennent. Pour le reste, c'est CC-BY-SA et ODbL. Enjoy ;) P.S. : j'ai posté dans misc pour pas froisser le dictateur, mais ça me semble coller avec tech, et comme tout le monde ne lit pas misc, le découpage de liste et la modération crétine priverons certains du bonus. Votre avis ? --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [TECH] Les RFCs sur le protocole réseau ILNP sont sortis
Je vous ai déjà embêté plusieurs fois avec les protocoles réseaux qui séparent l'identificateur d'une machine de son localisateur (contrairement à l'adresse IP actuelle, qui mélange les deux). Il existe trois de ces protocoles qui sont normalisés ou proches de l'être, un qui fonctionne dans les routeurs, en tunnelant le trafic (LISP, dont les RFC sont prêts mais bloqués par deux drafts auxiliaires pas encore publiés). Et deux qui ne fonctionnent que dans les machines terminales (pas besoin de toucher à votre infra) et sont considérés par leurs promoteurs comme les seuls « vrais » protocoles de séparation ID/Loc. Ce sont HIP et le nouveau ILNP, dont les RFC viennent de sortir. Par contre, si vous êtes impatients de déployer, notez que ILNP est le moins implémenté des trois. Pour l'instant, ces RFC sont surtout utiles au programmeur, à l'étudiant, au curieux. L'opérateur réseau devra attendre la prochaine phase pour tester ILNP. http://www.bortzmeyer.org/6740.html Auteur(s) du RFC: RJ Atkinson (Consultant), SN Bhatti (U. St Andrews) Le protocole ILNP vient d'être spécifié dans une série de neuf RFC, dont ce RFC 6740 est le point de départ, décrivant l'architecture générale d'ILNP. ILNP appartient à la famille des protocoles à séparation de l'identificateur et du localisateur http://www.bortzmeyer.org/separation-identificateur-localisateur.html. Ces protocoles visent à résoudre une limite fondamentale de l'Internet : l'adresse IP est utilisée à la fois comme *identificateur* (nommer une machine, par exemple pendant la durée d'une session TCP) et comme localisateur (indiquer son point d'attachement au réseau). Cette confusion rend certaines configurations, notamment le multi-homing et la mobilité, très difficiles. Ce n'est pas qu'ILNP soit le premier protocole à vouloir séparer ces deux fonctions. Avant de donner le feu vert à la publication de ces RFC, l'IESG a notamment examiné HIP http://www.bortzmeyer.org/hip-resume.html et LISP http://www.bortzmeyer.org/lisp-wg.html, avant de conclure qu'ILNP avait des caractéristiques suffisamment originales pour qu'il soit intéressant qu'il soit décrit dans des RFC. ILNP avait été choisi par les présidents du groupe de recherche Routage de l'IRTF comme étant la base des futurs travaux sur une meilleure architecture pour l'Internet (travaux décrits dans le RFC 6115). S'il faut le résumer en cinq points : * ILNP est défini comme une architecture abstraite, avec plusieurs concrétisations possibles. Celle décrite dans ces RFC est compatible avec l'Internet actuel (une autre, plus « table rase », serait possible). * ILNP fonctionne entièrement dans les machines terminales, les routeurs ne sont pas changés. * Chaque machine ILNP a au moins un Identificateur et au moins un Localisateur. En IPv6, ils sont indiqués dans chaque paquet (ILNP peut aussi tourner au dessus d'IPv4 mais c'est plus complexe.) * Pour trouver le Localisateur d'une machine qu'on veut contacter, la méthode standard est d'utiliser le DNS (ILNP repose nettement plus sur le DNS que ses concurrents). * Les changements de localisateur en cours de session sont faits par un nouveau message ICMP, Locator Update. Ces derniers sont sécurisés par un *numnique http://www.bortzmeyer.org/nonce.html*, nombre imprévisible envoyé au début de la session. Bon, après cette introduction rapide, voyons tout en détail. D'abord, pourquoi veut-on à tout prix séparer identificateur et localisateur ? Le mieux est de relire le RFC 4984 pour avoir tous les détails. Disons que l'actuelle confusion de l'identificateur et du localisateur est pénible pour : * La croissance des tables de routage : pour avoir des adresss IP stables, certains réservent du PI et l'annoncent dans la table de routage globale. * Le multi-homing : sans adresses PI, pas de moyen facile de gérer les adresses de ses fournisseurs d'accès. * La mobilité : changer d'endroit ou de fournisseur casse les connexions TCP en cours. Face à ces problèmes, des tas de propositions pour améliorer les mécanismes d'adressage et de nommage dans l'Internet ont été faites : RFC 814, RFC 1498, RFC 2101, RFC 2956 et bien d'autres. La conclusion était souvent la même : le mélange de fonctions d'identification d'une machine et de sa localisation dans le réseau est une mauvaise idée. Ces fonctions devraient être séparées. Il y a un petit poblème terminologique ici : les architectures où ces fonctions sont séparées sont parfois toutes appelées « séparation de l'identificateur et du localisateur ». Mais notre RFC adopte un vocabulaire plus strict. Il réserve ce terme de « séparation de l'identificateur et du localisateur » aux architectures (comme ILNP) où la séparation est faite dès le début (dans les machines terminales) et utilise le terme de « map and encapsulate » (qu'on trouve souvent abrégé en map-and-encap) aux architectures qui utilisent un tunnel pour transporter
Re: [FRnOG] [TECH] En tant que FAI, preferez vous beaucoup de connexion courtes, ou du keepalive?
salut manu, Le 10 novembre 2012 09:00, Emmanuel Thierry a écrit : Du coup tu peux appliquer la stratégie contraire: faire essentiellement des connexions keepalive pour surcharger les CGN d'un opérateur qui refuse encore de passer à IPv6, par exemple au hasard un opérateur qui porte le nom de la couleur de son logo ! Hum, peut-être que d'autres auront d'autres infos plus récentes/précises, mais Orange ne refuse pas de passer à ipv6, tu ne peux pas dire ça. C'est juste que c'est un très gros réseau, avec beaucoup d'équipements, et donc forcément des soucis de compatibilité avec ipv6, donc ça prend du temps. Coté OBS en revanche, l'ipv6 n'est pas activé par défaut, mais c'est possible. Je n'ai pas vu beaucoup de vpn clients dual stack mais il y en a, cf [0], et les accès internet sont également compatibles (cf [1]). Quand tu auras un réseau aussi grand et complexe à gérer on pourra en reparler ;) /pierre [0] http://www.orange-business.com/fr/presse/communiques/offres/IPv6.html [1] http://www.orange-business.com/fr/entreprise/communication/reseaux-internet/internet/business-internet/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] En tant que FAI, preferez vous beaucoup de connexion courtes, ou du keepalive?
Hi, Le 10 novembre 2012 16:29, Pierre Emeriaud petrus...@gmail.com a écrit : Coté OBS en revanche, l'ipv6 n'est pas activé par défaut, mais c'est possible. Je n'ai pas vu beaucoup de vpn clients dual stack mais il y en a, cf [0], et les accès internet sont également compatibles (cf [1]). Je confirme et ça juste marche (tant en MPLS qu'en Internet). Et s'il n'y a pas plus de VRF en dual stack c'est que la demande n'est semble il pas forcement foudroyante pour le moment. Pour la partie Internet mon petit doigt me dit que J. Nicolle a surement son mot à dire. Cdt, --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Les RFCs sur le protocole réseau ILNP sont sortis
Très bonne synthèse. Saleem Batthi, sera en visite à Annecy au printemps 2013 pour une semaine. Au cas ou des personnes voudrait avoir des infos de première main,, il fera un talk sur ILNP. Kv Le 10 nov. 2012 à 10:58, Stephane Bortzmeyer bortzme...@nic.fr a écrit : Je vous ai déjà embêté plusieurs fois avec les protocoles réseaux qui séparent l'identificateur d'une machine de son localisateur (contrairement à l'adresse IP actuelle, qui mélange les deux). Il existe trois de ces protocoles qui sont normalisés ou proches de l'être, un qui fonctionne dans les routeurs, en tunnelant le trafic (LISP, dont les RFC sont prêts mais bloqués par deux drafts auxiliaires pas encore publiés). Et deux qui ne fonctionnent que dans les machines terminales (pas besoin de toucher à votre infra) et sont considérés par leurs promoteurs comme les seuls « vrais » protocoles de séparation ID/Loc. Ce sont HIP et le nouveau ILNP, dont les RFC viennent de sortir. Par contre, si vous êtes impatients de déployer, notez que ILNP est le moins implémenté des trois. Pour l'instant, ces RFC sont surtout utiles au programmeur, à l'étudiant, au curieux. L'opérateur réseau devra attendre la prochaine phase pour tester ILNP. http://www.bortzmeyer.org/6740.html Auteur(s) du RFC: RJ Atkinson (Consultant), SN Bhatti (U. St Andrews) Le protocole ILNP vient d'être spécifié dans une série de neuf RFC, dont ce RFC 6740 est le point de départ, décrivant l'architecture générale d'ILNP. ILNP appartient à la famille des protocoles à séparation de l'identificateur et du localisateur http://www.bortzmeyer.org/separation-identificateur-localisateur.html. Ces protocoles visent à résoudre une limite fondamentale de l'Internet : l'adresse IP est utilisée à la fois comme *identificateur* (nommer une machine, par exemple pendant la durée d'une session TCP) et comme localisateur (indiquer son point d'attachement au réseau). Cette confusion rend certaines configurations, notamment le multi-homing et la mobilité, très difficiles. Ce n'est pas qu'ILNP soit le premier protocole à vouloir séparer ces deux fonctions. Avant de donner le feu vert à la publication de ces RFC, l'IESG a notamment examiné HIP http://www.bortzmeyer.org/hip-resume.html et LISP http://www.bortzmeyer.org/lisp-wg.html, avant de conclure qu'ILNP avait des caractéristiques suffisamment originales pour qu'il soit intéressant qu'il soit décrit dans des RFC. ILNP avait été choisi par les présidents du groupe de recherche Routage de l'IRTF comme étant la base des futurs travaux sur une meilleure architecture pour l'Internet (travaux décrits dans le RFC 6115). S'il faut le résumer en cinq points : * ILNP est défini comme une architecture abstraite, avec plusieurs concrétisations possibles. Celle décrite dans ces RFC est compatible avec l'Internet actuel (une autre, plus « table rase », serait possible). * ILNP fonctionne entièrement dans les machines terminales, les routeurs ne sont pas changés. * Chaque machine ILNP a au moins un Identificateur et au moins un Localisateur. En IPv6, ils sont indiqués dans chaque paquet (ILNP peut aussi tourner au dessus d'IPv4 mais c'est plus complexe.) * Pour trouver le Localisateur d'une machine qu'on veut contacter, la méthode standard est d'utiliser le DNS (ILNP repose nettement plus sur le DNS que ses concurrents). * Les changements de localisateur en cours de session sont faits par un nouveau message ICMP, Locator Update. Ces derniers sont sécurisés par un *numnique http://www.bortzmeyer.org/nonce.html*, nombre imprévisible envoyé au début de la session. Bon, après cette introduction rapide, voyons tout en détail. D'abord, pourquoi veut-on à tout prix séparer identificateur et localisateur ? Le mieux est de relire le RFC 4984 pour avoir tous les détails. Disons que l'actuelle confusion de l'identificateur et du localisateur est pénible pour : * La croissance des tables de routage : pour avoir des adresss IP stables, certains réservent du PI et l'annoncent dans la table de routage globale. * Le multi-homing : sans adresses PI, pas de moyen facile de gérer les adresses de ses fournisseurs d'accès. * La mobilité : changer d'endroit ou de fournisseur casse les connexions TCP en cours. Face à ces problèmes, des tas de propositions pour améliorer les mécanismes d'adressage et de nommage dans l'Internet ont été faites : RFC 814, RFC 1498, RFC 2101, RFC 2956 et bien d'autres. La conclusion était souvent la même : le mélange de fonctions d'identification d'une machine et de sa localisation dans le réseau est une mauvaise idée. Ces fonctions devraient être séparées. Il y a un petit poblème terminologique ici : les architectures où ces fonctions sont séparées sont parfois toutes appelées « séparation de l'identificateur et du localisateur ». Mais notre RFC adopte un
Re: [FRnOG] [TECH] Les RFCs sur le protocole réseau ILNP sont sortis
merci pour ce coup de projecteur. Vrai qu'il s'agit là d'un sérieux espoir pour simplifier le contexte actuel (multihoming, VM entre datacenters, transition V4/V6, mobilité ...). Ces initiatives, pour certaines bien avancées, sont des concepts qui ne remettent pas tout en cause mais révolutionnent en venant se greffer sur le socle actuel. Les surcouches de haut niveau pour répondre à de nouveaux besoins est une tendance à intensifier et s'appuyant sur la capilarité actuelle, car en réalité, logiciellement, il est déjà possible de tout faire, le challenge n'en reste pas moins la standardisation sans oublier la stabilité. J'ai pour ma part une préférence pour LISP, car par exemple, je regrette l'usage de DNS dans ILNP, j'entends par là, par exemple, les notions de TTL sur les records sous la barre des 1000s. Même si peu d'impact sur les perf, on risque de ne plus réussir à passer un zonecheck de l'AFNIC si on continue comme ça :) Le DNS étant destiné également à évoluer et l'imbrication peut engendrer des effets de bords (genre DNSSEC), le mieux est encore de fonctionner par empilement en évitant de créer trop de dépendances. Il y a tout de même une fâcheuse tendance à embarquer DNS dans les constructions de solution, je pense par exemple à SPF, DKIM ... :) Sinon 'est un peu dommage que ces initiatives ne soient pas encore assez connues parmi les experts car il s'agit là de travaux très prometteurs, à suivre aussi par les opérateurs et sur lesquels, eux aussi, doivent contribuer car le futur se dessine d'abord ensemble. Cyril HLAKKACHE From: Stephane Bortzmeyer Date: 2012-11-10 10:58 To: frnog-tech Subject: [FRnOG][TECH] Les RFCs sur le protocole réseau ILNP sont sortis Je vous ai déjà embêté plusieurs fois avec les protocoles réseaux qui séparent l'identificateur d'une machine de son localisateur (contrairement à l'adresse IP actuelle, qui mélange les deux). Il existe trois de ces protocoles qui sont normalisés ou proches de l'être, un qui fonctionne dans les routeurs, en tunnelant le trafic (LISP, dont les RFC sont prêts mais bloqués par deux drafts auxiliaires pas encore publiés). Et deux qui ne fonctionnent que dans les machines terminales (pas besoin de toucher à votre infra) et sont considérés par leurs promoteurs comme les seuls « vrais » protocoles de séparation ID/Loc. Ce sont HIP et le nouveau ILNP, dont les RFC viennent de sortir. Par contre, si vous êtes impatients de déployer, notez que ILNP est le moins implémenté des trois. Pour l'instant, ces RFC sont surtout utiles au programmeur, à l'étudiant, au curieux. L'opérateur réseau devra attendre la prochaine phase pour tester ILNP. http://www.bortzmeyer.org/6740.html Auteur(s) du RFC: RJ Atkinson (Consultant), SN Bhatti (U. St Andrews) Le protocole ILNP vient d'être spécifié dans une série de neuf RFC, dont ce RFC 6740 est le point de départ, décrivant l'architecture générale d'ILNP. ILNP appartient à la famille des protocoles à séparation de l'identificateur et du localisateur http://www.bortzmeyer.org/separation-identificateur-localisateur.html. Ces protocoles visent à résoudre une limite fondamentale de l'Internet : l'adresse IP est utilisée à la fois comme *identificateur* (nommer une machine, par exemple pendant la durée d'une session TCP) et comme localisateur (indiquer son point d'attachement au réseau). Cette confusion rend certaines configurations, notamment le multi-homing et la mobilité, très difficiles. Ce n'est pas qu'ILNP soit le premier protocole à vouloir séparer ces deux fonctions. Avant de donner le feu vert à la publication de ces RFC, l'IESG a notamment examiné HIP http://www.bortzmeyer.org/hip-resume.html et LISP http://www.bortzmeyer.org/lisp-wg.html, avant de conclure qu'ILNP avait des caractéristiques suffisamment originales pour qu'il soit intéressant qu'il soit décrit dans des RFC. ILNP avait été choisi par les présidents du groupe de recherche Routage de l'IRTF comme étant la base des futurs travaux sur une meilleure architecture pour l'Internet (travaux décrits dans le RFC 6115). S'il faut le résumer en cinq points : * ILNP est défini comme une architecture abstraite, avec plusieurs concrétisations possibles. Celle décrite dans ces RFC est compatible avec l'Internet actuel (une autre, plus « table rase », serait possible). * ILNP fonctionne entièrement dans les machines terminales, les routeurs ne sont pas changés. * Chaque machine ILNP a au moins un Identificateur et au moins un Localisateur. En IPv6, ils sont indiqués dans chaque paquet (ILNP peut aussi tourner au dessus d'IPv4 mais c'est plus complexe.) * Pour trouver le Localisateur d'une machine qu'on veut contacter, la méthode standard est d'utiliser le DNS (ILNP repose nettement plus sur le DNS que ses concurrents). * Les changements de localisateur en cours de session sont faits par un nouveau message ICMP, Locator Update. Ces derniers
Re: [FRnOG] [TECH] En tant que FAI, preferez vous beaucoup de connexion courtes, ou du keepalive?
Le 10 nov. 2012 à 17:07, Thomas Barandon t.baran...@gmail.com a écrit : Hi, Le 10 novembre 2012 16:29, Pierre Emeriaud petrus...@gmail.com a écrit : Coté OBS en revanche, l'ipv6 n'est pas activé par défaut, mais c'est possible. Je n'ai pas vu beaucoup de vpn clients dual stack mais il y en a, cf [0], et les accès internet sont également compatibles (cf [1]). Je confirme et ça juste marche (tant en MPLS qu'en Internet). Et s'il n'y a pas plus de VRF en dual stack c'est que la demande n'est semble il pas forcement foudroyante pour le moment. Pour la partie Internet mon petit doigt me dit que J. Nicolle a surement son mot à dire. Puisqu'on parle d'Internet OBS et d'IPv6, est-ce que quelqu'un a des soucis de perf vers google (notamment visible sur youtube et gmail) ? En IPv4 ca fonctionne très bien mais en IPv6 c'est souvent lent... :/ --- Liste de diffusion du FRnOG http://www.frnog.org/
