Re: [FRnOG] [TECH] Email du RIPE
Il me semble avoir lu quelque part que part que le fournisseur du /22 incriminé était Completel. Ne serait-il pas plus judicieux de demander à Cptl de mettre tout ca a jour au lieu de vouloir en faire une question de principe avec le RIPE? Parceque là la question de principe elle serait plutot enver le fournisseur qui fait défaut sur la bonne tenue de ses infos avec le RIPE qu'envers le RIPE qui essaye de faire le ménage... Enfin si l'on a du temps et de l'argent à perdre pourquoi pas. Le 2013-03-26 00:52, Fréderic a écrit : Le 25/03/2013 23:06, Clement Cavadore a écrit : On Mon, 2013-03-25 at 22:58 +0100, Radu-Adrian Feurdean wrote: On Mon, Mar 25, 2013, at 12:14, Fréderic wrote: Nous avons un bloc PI et nous n'avons jamais eu de relation avec le RIPE. Quelqu'un a bien eu cette relation pour votre compte. Have fun a jouer le con avec eux :) C'est vraiment bête d'avoir un /22 en PI, et de vouloir jouer au con pour tenter d'économiser 50€/an. ce n'est pas une question d'economiser 50 euros/an puis que nous payons déjà un avocat pour préparer notre défense, c'est donc principalement une question de principe. Cordialement. --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [TECH] RFC 6908: Deployment Considerations for Dual-Stack Lite
Alors, ceux et celles ici qui ont déployé DS-Lite sont d'accord avec ces considérations opérationnelles ? RFC 6908 : Deployment Considerations for Dual-Stack Lite http://www.bortzmeyer.org/6908.html Auteur(s) du RFC: Y. Lee (Comcast), R. Maglione (Telecom Italia), C. Williams (MCSR Labs), C. Jacquenet (France Telecom), M. Boucadair (France Telecom) DS-Lite est une des nombreuses techniques de transition / co-existence IPv4 / IPv6. Elle est normalisée dans le RFC 6333. Ce nouveau RFC se penche plutôt sur des problèmes opérationnels : comment déployer DS-Lite, quels pièges éviter, etc. DS-Lite (Dual-Stack Lite) est conçu pour un FAI récent, qui vient d'arriver et n'a donc pas pu obtenir d'adresses IPv4, toutes épuisées http://www.bortzmeyer.org/epuisement-ipv4.html. Ce FAI a donc dû numéroter son réseau en IPv6, et comme ses clients ont encore de l'IPv4 à la maison, et comme ils souhaitent accéder à des machines Internet qui sont encore uniquement en IPv4, le FAI en question va donc devoir 1) NATer les adresses de ses clients (RFC 3022) vers le monde extérieur 2) tunneler leurs paquets depuis leur réseau local IPv4 (RFC 2463) jusqu'au CGN, en passant par le réseau purement IPv6 du FAI. C'est là que DS-Lite intervient (RFC 6333). Apparemment, il n'y a eu qu'un seul déploiement effectif de DS-Lite chez un vrai FAI (le RFC ne dit pas lequel) et ce RFC 6908 est largement tiré de cette expérience réelle. Il est donc une lecture intéressante pour les opérateurs qui aiment le concret. Ce RFC est en deux parties : les questions liées à l'AFTR et celles liées au B4. Vous ne savez pas ce qu'est un AFTR ou un B4 ? Vous n'avez pas envie de lire le RFC 6333 qui explique cela ? Alors, en deux mots, l'AFTR (Address Family Transition Router) est le gros routeur NAT (le CGN) situé entre le FAI et l'Internet. Et le B4 (Basic Bridging Broadband element) est chez le client, typiquement dans sa box et représente le point d'entrée du tunnel, du « lien virtuel » (soft wire). Prononcez les sigles à voix haute : le B4 est avant le tunnel (before) et l'AFTR après (after). Donc, bien qu'il soit « après », notre RFC commence par l'AFTR (section 2). D'abord, comme DS-Lite utilise un tunnel, il va y avoir des problèmes dus à la MTU inférieure. Le RFC recommande donc d'essayer de faire un lien entre le B4 et l'AFTR ayant une MTU d'au moins 1540 octets pour que, après avoir retiré les 40 octets de l'encapsulation dans le tunnel, on ait les 1500 octets d'Ethernet. Si ce n'est pas possible, alors le B4 et l'AFTR vont devoir gérer la fragmentation. Comme le réassemblage des paquets est une opération coûteuse en ressources (il faut garder les fragments en mémoire tant que tout n'est pas arrivé), la tâche va être particulièrement lourde pour l'AFTR (des milliers de tunnels peuvent se terminer sur un seul AFTR). Il faut les dimensionner largement ! (C'est un problème général des CGN.) Ensuite, il faut penser à la journalisation. Le principe de DS-Lite est que tous les clients du FAI partageront la poignée d'adresses IPv4 publiques que NATeront les AFTR. Si un client fait quelque chose de mal (par exemple accéder à un site Web qui déplait au gouvernement), il faut pouvoir l'identifier. Un observateur situé à l'extérieur a vu une adresses IPv4 du FAI et des milliers de clients pouvaient être derrière. L'AFTR doit donc noter au moins l'adresse IPv6 du B4 (elle est spécifique à chaque client) et le port source utilisé après le NAT (en espérant que l'observateur extérieur ne notera pas que l'adresse IPv4 source mais aussi le port, cf. RFC 6302). Les adresses IP partagées sont une plaie du NAT, ce n'est pas nouveau (RFC 6269). Par exemple, si une adresse IPv4 est mise sur une liste noire suite à son comportement http://lci.tf1.fr/high-tech/2007-07/polemique-quand-wikipedia-punit-sci ences-4890331.html, ce seront des centaines ou des milliers de B4 qui seront privés de connectivité IPv4. Si le destinataire ne tient pas compte du RFC 6302 et bloque sur la seule base de l'adresse IPv4, le support téléphonique du FAI qui a déployé DS-Lite va exploser. (Un travail est en cours à l'IETF pour aider à l'identification de l'utilisateur derrière un CGN. Mais il n'est pas terminé et, de toute façon ne sera pas forcément déployé. L'obstination de tant d'acteurs à rester en IPv4 va se payer cher.) Un problème analogue se posera si le FAI veut faire de la comptabilité des octets échangés, et s'il ne met pas cette fonction dans le CPE. Le tunnel et le NAT rendront cette analyse plus compliquée (section 2.6). À noter que le RFC 6519 normalise des extensions à Radius pour les problèmes particuliers de DS-Lite. Mais tout ceci n'est rien par rapport aux problèmes de fiabilité que posent les AFTR. L'Internet normal est très robuste car les équipements intermédiaires (les routeurs) n'ont pas d'état : s'ils redémarrent, rien n'est perdu.
[FRnOG] Re: [MISC] SDN et la neutralité du réseau
On Mon, Mar 25, 2013 at 07:19:42PM +0100, Olivier Cochard-Labbé oliv...@cochard.me wrote a message of 24 lines which said: Si j'ai bien compris, dans un SDN on ne route plus un paquet en fonction de son IP de destination mais en fonction de plusieurs paramètres tel que: IP source, IP dest, TCP source, TCP dest, etc… D'autres techniques permettent de faire cela, par exemple FlowSpec http://www.bortzmeyer.org/5575.html. Je dirais que c'est comme la QoS, tout dépend de qui l'utilise (réseau privé ? Ouvert au public ?) et comment. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Email du RIPE
On Tue, Mar 26, 2013, at 0:52, Fréderic wrote: déjà un avocat pour préparer notre défense, c'est donc principalement une question de principe. Je repete donc la question : pour obtenir quoi ? RIPE NCC n'etat pas soumise a la justice Francaise(*), tu comptes obliger tes transitaires a annoncer ton bloc par decision de justice ? Tu veux coute-que coute gagner, quitte a fermer boutique ? Tu sais que pour ouvrir un nouveau boutique il va falloir recommencer de zero, dans des conditions moins bonnes, et en faisant exactement ce que tu ne veux pas faire maintenant ? --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Email du RIPE
Je pense plutôt, qu'il se sent frustré qu'il faille répondre à une autorité supérieure pour la gestion de ses ip. Franchement, les RIR et les règles sont mises en place justement pou éviter le chaos et que l'on ai plus des /8 et des /16 qui trainent dans la nature. Lorsque dans 1 an, tu auras besoin d'ip tu seras bien content que le ripe ai pu récupérer des @ip d'une société qui n'existe plus depuis 5 ans et dont les ip étaient soient inutilisées soit utilisées scrupuleusement par son ancien LIR. Par ailleurs, comme l'a indiqué Matoa, le ripe est une association qui est dirigé par ses membres . Donc, comme demandé Nous estimons que cela doit rester communautaire et non centralisé, c'est déjà le cas pour la partie communautaire. Si la base du ripe tombe, le routage ne va pas stopper d'un seul coup de baguette magique ( bon , certains updates de routes ne passeront plus pour ceux qui scriptent sur la base du ripe en direct ), car ce n'est que déclaratif. Cependant, si tu ne déclares pas tes objets route par exemple, tu pourrais ne pas avoir beaucoup de trafic in via certain transitaire qui filtrent sur ces objets :) -- Raphael MAUNIER Jaguar Network France Le 26 mars 2013 à 08:51, s.lesim...@b-and-c.net a écrit : Il me semble avoir lu quelque part que part que le fournisseur du /22 incriminé était Completel. Ne serait-il pas plus judicieux de demander à Cptl de mettre tout ca a jour au lieu de vouloir en faire une question de principe avec le RIPE? Parceque là la question de principe elle serait plutot enver le fournisseur qui fait défaut sur la bonne tenue de ses infos avec le RIPE qu'envers le RIPE qui essaye de faire le ménage... Enfin si l'on a du temps et de l'argent à perdre pourquoi pas. Le 2013-03-26 00:52, Fréderic a écrit : Le 25/03/2013 23:06, Clement Cavadore a écrit : On Mon, 2013-03-25 at 22:58 +0100, Radu-Adrian Feurdean wrote: On Mon, Mar 25, 2013, at 12:14, Fréderic wrote: Nous avons un bloc PI et nous n'avons jamais eu de relation avec le RIPE. Quelqu'un a bien eu cette relation pour votre compte. Have fun a jouer le con avec eux :) C'est vraiment bête d'avoir un /22 en PI, et de vouloir jouer au con pour tenter d'économiser 50€/an. ce n'est pas une question d'economiser 50 euros/an puis que nous payons déjà un avocat pour préparer notre défense, c'est donc principalement une question de principe. Cordialement. --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: [MISC] SDN et la neutralité du réseau
Bonjour, Pour revenir à la notion de neutralité, il me semble, d'après mes lectures, qu'openflow et le concept de sdn en général sont plus destinés à gérer des flux backbones (où dans tous les cas la notion de neutralité est toute relative) et pas forcément du trafic public (internet). L'effet sur la neutralité de l'internet me paraît donc relativement faible. L'exemple de qui me vient à l'esprit est un papier de Google ( http://www.wired.com/wiredenterprise/2012/04/going-with-the-flow-google/) sur leur utilisation d'openflow, principalement utilisé pour gérer les lourds flux applicatifs et de réplication. Le trafic public, autrement dit le trafic internet reste géré de façon classique. Je vois mal openflow être utilisé frontalement sur des réseaux publics. L’intérêt me semble limité pour un trafic disparate. Cordialement. 2013/3/26 Stephane Bortzmeyer bortzme...@nic.fr On Mon, Mar 25, 2013 at 07:19:42PM +0100, Olivier Cochard-Labbé oliv...@cochard.me wrote a message of 24 lines which said: Si j'ai bien compris, dans un SDN on ne route plus un paquet en fonction de son IP de destination mais en fonction de plusieurs paramètres tel que: IP source, IP dest, TCP source, TCP dest, etc… D'autres techniques permettent de faire cela, par exemple FlowSpec http://www.bortzmeyer.org/5575.html. Je dirais que c'est comme la QoS, tout dépend de qui l'utilise (réseau privé ? Ouvert au public ?) et comment. --- Liste de diffusion du FRnOG http://www.frnog.org/ -- Alexis Savin Ingénieur Systèmes/Réseaux/Sécurité --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [MISC] [ARCEP] Dispositif de mesure et de suivi de la qualité du service fixe d’accès à l’internet
Tiens, une décision de l'ARCEP dont on n'a pas parlé sur FRnog ? http://seenthis.net/messages/125117 C'est parce que tout le monde est d'accord ? :-) --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [MISC] Acces au 100.40.0.0/17 depuis SFR
Bonjour, Nous avons du mal a atteindre le 100.40.0.0/17 depuis un acces SFR. L'annonce BGP arrive correctement, mais nous n'arrivons pas a joindre un site heberge dans cette plage (www.grc.org pour ceux que ca interesse) D'ailleurs ce meme site n'est pas joignable de n'importe quel acces SFR grand public (ADSL, 3G, etc) Depuis notre autre fournisseur (Renater) l'acces se passe bien. C'est aussi le cas des 2/3 acces grand public que nous avons pu tester (Free, Orange) Nous avons un ticket en cours chez SFR (ouvert depuis pres de 3 semaines maintenant) et je souhaitait savoir si d'autres parmi vous ont constate des problemes d'acces a ce prefix depuis vos differents reseaux. Outre la gene que ca induit, j'essaie de voir quel types de scenarios peuvent aboutir a ce genre de trou noir du moins tres selectif. Merci de vos retours. --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [MISC] [ARCEP] Dispositif de mesure et de suivi de la qualité du service fixe d’accès à l’internet
Intéressant en effet, reste à voir si des sanctions pourront être appliquées .. sinon ça ne sert à rien.. http://www.arcep.fr/index.php?id=8571tx_gsactualite_pi1[uid]=1597tx_gsactualite_pi1[annee]=tx_gsactualite_pi1[theme]=tx_gsactualite_pi1[motscle]=tx_gsactualite_pi1[backID]=26cHash=2c3599b6047b4fba07add189077b08d9 A++ Bruno -Message d'origine- De : frnog-requ...@frnog.org [mailto:frnog-requ...@frnog.org] De la part de Stephane Bortzmeyer Envoyé : mardi 26 mars 2013 10:12 À : frnog-m...@frnog.org Objet : [FRnOG] [MISC] [ARCEP] Dispositif de mesure et de suivi de la qualité du service fixe d’accès à l’internet Tiens, une décision de l'ARCEP dont on n'a pas parlé sur FRnog ? http://seenthis.net/messages/125117 C'est parce que tout le monde est d'accord ? :-) --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [MISC] [ARCEP] Dispositif de mesure et de suivi de la qualité du service fixe d’accès à l’internet
On Tue, Mar 26, 2013 at 11:01:02AM +0100, Bruno CAVROS / SKIWEBCENTER br...@skiwebcenter.fr wrote a message of 33 lines which said: si des sanctions pourront être appliquées Non. Aucune base légale pour cela. (IANAL mais Alex Archambault va corriger si je me trompe.) --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [MISC] Acces au 100.40.0.0/17 depuis SFR
On Tue, Mar 26, 2013 at 10:26:43AM +0100, Youssef Ghorbal youssef.ghor...@gmail.com wrote a message of 25 lines which said: Nous avons du mal a atteindre le 100.40.0.0/17 depuis un acces SFR. traceroute ? Car, d'après RIS, la visibilité de ce préfixe est quasi-parfaite. --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] Re: [MISC] [ARCEP] Dispositif de mesure et de suivi de la qualité du service fixe d’accès à l’internet
OK, donc ça ne servira à rien, et pour le moment je pense que Monsieur Archambault n'est peut être pas le mieux placé pour s'exprimer... :/ A ce propos, la video du frnog ? toujours en phase de négociations ? A++ Bruno -Message d'origine- De : frnog-requ...@frnog.org [mailto:frnog-requ...@frnog.org] De la part de 'Stephane Bortzmeyer' Envoyé : mardi 26 mars 2013 11:04 À : Bruno CAVROS / SKIWEBCENTER Cc : frnog-m...@frnog.org Objet : [FRnOG] Re: [MISC] [ARCEP] Dispositif de mesure et de suivi de la qualité du service fixe d’accès à l’internet On Tue, Mar 26, 2013 at 11:01:02AM +0100, Bruno CAVROS / SKIWEBCENTER br...@skiwebcenter.fr wrote a message of 33 lines which said: si des sanctions pourront être appliquées Non. Aucune base légale pour cela. (IANAL mais Alex Archambault va corriger si je me trompe.) --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Acces au 100.40.0.0/17 depuis SFR
Salut Youssef, On Tue, Mar 26, 2013 at 10:26:43AM +0100, Youssef Ghorbal wrote: Bonjour, Nous avons du mal a atteindre le 100.40.0.0/17 depuis un acces SFR. L'annonce BGP arrive correctement, mais nous n'arrivons pas a joindre un site heberge dans cette plage (www.grc.org pour ceux que ca interesse) D'ailleurs ce meme site n'est pas joignable de n'importe quel acces SFR grand public (ADSL, 3G, etc) Depuis notre autre fournisseur (Renater) l'acces se passe bien. C'est aussi le cas des 2/3 acces grand public que nous avons pu tester (Free, Orange) Humm, ça sent le soucis de MTU ou assimilé, dit comme ça. Sylvain --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] [ARCEP] Dispositif de mesure et de suivi de la qualité du service fixe d’accès à l’internet
Le 26/03/2013 10:12, Stephane Bortzmeyer a écrit : Tiens, une décision de l'ARCEP dont on n'a pas parlé sur FRnog ? http://seenthis.net/messages/125117 C'est parce que tout le monde est d'accord ? :-) Personnellement, j'adore l'annonce qui dit l'ARCEP met en place un dispositif et qui se transforme en Les opérateurs doivent mettre en place un dispositif et communiquer les résultats à l'ARCEP au fur et à mesure qu'on lit la décision. M'enfin, heureusement que Afin de ne pas engendrer de coûts disproportionnés au regard des objectifs poursuivis, l’obligation de mesure et de publication d’indicateurs de qualité du service d’accès à l’internet n’a pas vocation à s’appliquer à tous les opérateurs. .. On va pouvoir vaquer à nos occupations :) (Je sais, nous ne sommes pas vendredi ..) --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [MISC] Acces au 100.40.0.0/17 depuis SFR
Bonjour, à tout hasard quel est l'IP source de votre connexion ? Allez, je vote pour 109.*, comme 99% des cas d'impossibilité d'accès qu'on nous remonte. En effet, ce bloc d'IP que nous a alloué en partie le RIPE en fév. 2009 était considéré comme bogon jusqu'alors ... Manque de chance, bon nombre d'implémenteurs de telles bogon-lists ont oublié que de telles listes se mettent à jour régulièrement (surtout avec la pénurie Ipv4). Et au final, ce sont nous et nos clients qui se retrouvent pénalisés (quand ce n'est pas accusés à tord de filtrage). De mon côté je vais essayer de prendre contact avec l'hébergeur pour lui faire mettre à jour ses filtres. Cordialement, -- David Gavarret – Architecte Système Expert SFR / Direction Réseau / Terminaux Plates-Formes de Services -Message d'origine- De : frnog-requ...@frnog.org [mailto:frnog-requ...@frnog.org] De la part de Youssef Ghorbal Envoyé : mardi 26 mars 2013 10:27 À : frnog-m...@frnog.org Objet : [FRnOG] [MISC] Acces au 100.40.0.0/17 depuis SFR Bonjour, Nous avons du mal a atteindre le 100.40.0.0/17 depuis un acces SFR. L'annonce BGP arrive correctement, mais nous n'arrivons pas a joindre un site heberge dans cette plage (www.grc.org pour ceux que ca interesse) D'ailleurs ce meme site n'est pas joignable de n'importe quel acces SFR grand public (ADSL, 3G, etc) Depuis notre autre fournisseur (Renater) l'acces se passe bien. C'est aussi le cas des 2/3 acces grand public que nous avons pu tester (Free, Orange) Nous avons un ticket en cours chez SFR (ouvert depuis pres de 3 semaines maintenant) et je souhaitait savoir si d'autres parmi vous ont constate des problemes d'acces a ce prefix depuis vos differents reseaux. Outre la gene que ca induit, j'essaie de voir quel types de scenarios peuvent aboutir a ce genre de trou noir du moins tres selectif. Merci de vos retours. --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Email du RIPE
Le 26/03/2013 17:43, Sylvain Vallerot a écrit : On 26/03/2013 00:52, Fréderic wrote: ce n'est pas une question d'economiser 50 euros/an puis que nous payons déjà un avocat pour préparer notre défense, c'est donc principalement une question de principe. pas une question d'argent !? une question de principe !? SEGFAULT - LAVIE.COM ADDRESS SPACE RESTRICTIONS VIOLATED dans le principe y a aussi une question d'argent. mais pas une question d'economiser a+ --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
