Re: [FRnOG] [TECH] Projet IPv6-only chez MS
Ca marche quand même pas trop mal pour certains types d'environnement voire de pays (la belgique par exemple ou certains pays scandinaves) . Mais à mon humble avis, tout ça ne peut qu'évoluer qu'avec l'usage. Le protocole offre de nombreuses portes ouvertes, c'est aussi pour ça que rien n'est totalement figé. Mais seul l'usage et les itérations successives peuvent contribuer à améliorer son fonctionnement. Le 29/01/2017 à 13:45, David Ponzone a écrit : > Plus je lis de choses sur IPv6, moins j'ai le sentiment de technos sèches. > Pour l'attribution automatique d'adresses sur le lan par exemple: > DHCPv6 pas fonctionnel sur toutes les plateformes > SLAAC pas secure sans la RFC7217, à priori pas implémentée par Redmond > > C'est un peu comme faire de l'IPv4 en 1985 > > David Ponzone > > > >> Le 29 janv. 2017 à 11:36, Jean Théry <jean.thery.fr...@olympus-zone.net> a >> écrit : >> >> Perso j'en ai déployé pas mal >> >> aucun bug coté firewall (pf) >> >> par contre sur des serveur qui doivent faire de la résolution et >> comparer à des base genre rbl (avec postfix et co) >> >> c'est ... compliqué :) >> >> typiquement c'est l'usage client qui pose le seul problème que j'ai vu, >> à savoir le comportement de certains OS de chez redmond qui ne considère >> pas toujours l'absence d'ipv4 comme "normale" (résolution d'un hôte >> impossible selon qu'on accède au resolver DNS en ipv6 ou ipv4. >> >> >>> Le 29/01/2017 à 09:30, Willy MANGA a écrit : >>> Bonjour, >>> >>> >>>> Le 29/01/2017 à 01:44, Sébastien Lesimple a écrit : >>>>> On 28/01/2017 22:03, Wallace wrote: >>>>> [...] >>>> En revanche, si MS décide d'etre IPv6 Only, les GAFA vont suivre très >>>> très vite et on va enfin pouvoir mettre v4 a la retraite en quelques >>>> années. ENFIN! >>> Sauf erreur, au jour d'aujourd'hui le réseau interne de Facebook doit >>> déjà être à 100% en IPv6-only [1] >>> >>> Amazon commence déjà à déployer progressivement IPv6 dans leur réseau et >>> le met à disposition de ses clients. Ca aide des gens comme Twitter... >>> >>> >>> >>> 1. >>> http://www.internetsociety.org/deploy360/resources/case-study-facebook-moving-to-an-ipv6-only-internal-network/ >>> >> >> >> --- >> Liste de diffusion du FRnOG >> http://www.frnog.org/ > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ > -- Willy Manga freenode: ongolaBoy Ubuntu Cameroonian Loco Team https://launchpad.net/~manga-willy signature.asc Description: OpenPGP digital signature
Re: [FRnOG] [TECH] Projet IPv6-only chez MS
Bonjour, Le 29/01/2017 à 01:44, Sébastien Lesimple a écrit : > On 28/01/2017 22:03, Wallace wrote: >>[...] > En revanche, si MS décide d'etre IPv6 Only, les GAFA vont suivre très > très vite et on va enfin pouvoir mettre v4 a la retraite en quelques > années. ENFIN! Sauf erreur, au jour d'aujourd'hui le réseau interne de Facebook doit déjà être à 100% en IPv6-only [1] Amazon commence déjà à déployer progressivement IPv6 dans leur réseau et le met à disposition de ses clients. Ca aide des gens comme Twitter... 1. http://www.internetsociety.org/deploy360/resources/case-study-facebook-moving-to-an-ipv6-only-internal-network/ -- Willy Manga freenode: ongolaBoy Ubuntu Cameroonian Loco Team https://launchpad.net/~manga-willy signature.asc Description: OpenPGP digital signature
Re: [FRnOG] Re: [MISC] Quelqu'un pourrait ajuster sa technique pour saturer Internet
Bonjour, Le 16/09/2016 à 07:19, Kavé Salamatian a écrit : > Bonjour à tous >>[...] > Pas trop. Je fais du monitoring BGP multi-points et je peux confirmer > la croissance d’essai de Hijack BGP à grande échelle et coordonnés > depuis quelques mois. J’ai contacté Bruce et nos observations > concorde. Il se passe réellement quelque chose …… Peut être des personnes/entités qui se disent que la transition IANA à venir laissera une petite faille qu'ils souhaiteraient exploiter ... Bien évidemment je ne le souhaite pas mais comme dans la vie il n'y a pas que des «gentils» ... :) -- Willy Manga freenode: ongolaBoy Ubuntu Cameroonian Loco Team https://launchpad.net/~manga-willy signature.asc Description: OpenPGP digital signature
Re: [FRnOG] [TECH] Comment interroger zen.spamhaus.org (et autres RBL) correctement.
Bonjour Michel, Le 06/03/2017 à 18:59, Michel Py a écrit : > Bonjour à tous, > > [...] > Comme je doutais un peu des services to mon forwarder DNS, j'ai mis > un forwarder conditionnel pour zen.spamhaus.org et çà aide mais > pourtant il y en a encore un peu qui passe au travers des mailles du > filet. Pas possible/souhaitable d'avoir un résolveur correct en interne qui ferait lui même ce travail au lieu de passer par un forwarder ? -- Willy Manga freenode: ongolaBoy Ubuntu Cameroonian Loco Team https://launchpad.net/~manga-willy signature.asc Description: OpenPGP digital signature
Re: [FRnOG] [MISC] comparatif *technique* des FAI "grand public"
Bonjour, Le 24/08/2017 à 10:18, Grégoire G a écrit : > [...] > Bonjour, > > j'avais observé il y a quelques années que chez Bouyggues, le port 53 était > filtré. > C'est à dire qu'on ne pouvait pas avoir son propre résolveur récursif. Dans ce style https://davenull.tuxfamily.org/mitm-as-a-service-3g-edition-by-bouygues/ ? ;) -- Willy Manga @ongolaboy https://ongola.blogspot.com/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Google Proxy ?
Bonjour, Le 17/10/2017 à 08:39, David Ponzone a écrit : > Bonjour tous, > > Je viens de voir des requêtes sur des sites chez nous venant de 66.249.93.17 > dont le reverse est google-proxy-66-249-93-17.google.com, et à priori ce sont > des clients à nous qui se sont connectés de cette manière. > J'ai trouvé des références à des techniques pour utiliser des proxy chez > Google datant d'il y a 3 ou 4 ans (http://www.gmodules.com/ig/proxy?url=….) > mais ça ne marche plus à priori. > > Il y a un moyen officiel (simple à mettre en oeuvre) d'utiliser les proxy > Google (genre avec un plugin Chrome que j'aurais raté) ? Est-ce que tu ne ferais pas référence à la fonctionnalité présente dans Chrome (sur mobile uniquement ?) d'activer l'option «économiseur de données» ? Celle-ci en réalité place toutes les requêtes justement derrière un proxy de google ... -- Willy Manga @ongolaboy https://ongola.blogspot.com/ signature.asc Description: OpenPGP digital signature
Re: [FRnOG] [TECH] demande d'infos sur achats d'IP
Hello, Le 21/05/2018 à 11:03, Julien Escario a écrit : > Le 21/05/2018 à 11:24, Olivier Lange a écrit : >[...] > Au alors, on peut aussi se bouger la nouille et mettre du dual-stack partout, > voire pour du web/mail, créer un reverse proxy propre et mettre les backends > en ipv6-only derrière. Avoir une infra du 21ème siècle en somme ;-) Je n'ai pas osé le suggérer mais pourtant ... :) > Et sinon, un peu d'implication dans les votes sur les policies ne fait pas de > mal (à défaut de voter pour des gens que l'on ne connaît pas à des postes que > l'on ne comprend pas ;-). Oui, si les TOUS les membres s'impliquaient un peu plus dans ces réunions ça serait bien et plus représentatif des besoins de la communauté. Sur ce point on a le même problème à AFRINIC. L'impression que j'ai est que beaucoup d'entités/personnes considèrent les RIR comme des boutiques et c'est bien dommage. > Bon, ok, je reviens d'une semaine de RIPE Meeting, forcément remonté comme un > coucou suisse sur ces questions. :) -- Willy Manga @ongolaboy https://ongola.blogspot.com/ signature.asc Description: OpenPGP digital signature
Re: [FRnOG] [TECH] Un autre pavé, IPv6
Bonjour, Le 09/03/2018 à 12:48, Michel Hostettler a écrit : > Bonjour, > [...] > J'envisage de proposer un nouveau cours IPv6, sous l'angle > opérationnel des opérateurs (des freins aux leviers). Pour l'instant > notre cours IPv6 est plutôt théorique, abstrait... Quelques paragraphes sur le rôle des RIR (à l'instar du RIPE) et de l'IETF seraient appropriés à mon humble avis. Ce n'est certes pas spécifique à IPv6 mais ça permet de savoir où se définissent les protocoles, les règles d'assignation/allocation. Surtout faire comprendre que ces règles dépendent d'une communauté dont tout le monde dépend et chacun peut (et devrait même) y donner son avis :) -- Willy Manga @ongolaboy https://ongola.blogspot.com/ signature.asc Description: OpenPGP digital signature
Re: [FRnOG] [MISC] IPv4, c'était bien tant que ça a duré
Bonjour, Le 19/04/2018 à 09:05, Wallace a écrit : > Je pense aussi que la solution de dire on coupe tout à telle date me > parait être la meilleure solution. > > Mais je doute que la décision vienne des gros acteurs OS qui sont déjà > très bien fourni en IP. > > A mon avis ça viendra de pays qui diront on a pas assez d'adresse pour > tout le monde et le CGNAT on en veut plus ou pas, IPv6 obligatoire à > telle date. [...] Si INTERPOL arrive à convaincre les Etats de la nécessité d'utiliser IPv6 et si ces derniers réalisent ce que ça leur apportera en matière d'identification, ça sera un grand pas à mon humble avis... -- Willy Manga @ongolaboy https://ongola.blogspot.com/ signature.asc Description: OpenPGP digital signature
Re: [FRnOG] [MISC] IPv4, c'était bien tant que ça a duré
'lut, Le 18/04/2018 à 07:50, Joffrey Fontaine a écrit : > Hello, mais je crois qu'à un moment, certains en ont abusé (on ne se poser > pas la question de disponibilité des ips) > Dans l'université ou je bosse, on a un /16. Toutes les imprimantes ont une ip > publique ! c'est en train de changer, mais historiquement on vient de loin .. A une époque j'aurais vu cela comme un abus mais je trouve normal d'avoir des IP publiques mêmes pour des imprimantes. Plus encore en IPv6 (avoir des adresses globalement routables). Le plus important étant les règles de filtrage et les autorisations ;) -- Willy Manga @ongolaboy https://ongola.blogspot.com/ signature.asc Description: OpenPGP digital signature
Re: [FRnOG] [MISC] encore et toujours l'antispam microsoft.
'jour Le 20/03/2018 à 18:22, Michel Py a écrit : >> [...] > C'est là ou tu ne nous convainc pas. On a essayé, çà a rien changé. Je > suppose qu'en y consacrant sa vie... > Là ou le bat blesse c'est que le problème est concentré autour d'UN vendeur. Idem dans le domaine de la bureautique et des formats. Bref ... -- Willy Manga @ongolaboy https://ongola.blogspot.com/ signature.asc Description: OpenPGP digital signature
Re: [FRnOG] [TECH] Projet IPv6-only chez MS
Bonjour, Le 25/01/2017 à 16:19, David Ponzone a écrit : > https://labs.ripe.net/Members/mirjam/ipv6-only-at-microsoft En un an et demi il s'en est passé des choses chez eux ... Notamment le fait que SLAAC soit désormais pris en compte (à partir de Windows 10), des corrections pour DHCPv6,... Une présentation datant de Juillet 2017 : https://www.youtube.com/watch?v=nd0vgU6WbPo Et plus récemment un résumé des dernières avancées https://blog.apnic.net/2018/09/17/microsoft-making-progress-towards-ipv6-only/ . Convaincu ??? :) -- Willy Manga @ongolaboy https://ongola.blogspot.com/ signature.asc Description: OpenPGP digital signature
[FRnOG] [MISC] Jinglepings
Réservé à ceux qui disposent d'IPv6 :) Illuminez ce tableau en pinguant les 160x120 LEDs qui disposent chacune d'une adresse IPv6 https://www.jinglepings.com/ -- Willy Manga @ongolaboy https://ongola.blogspot.com/ signature.asc Description: OpenPGP digital signature
Re: [FRnOG] [TECH] Attaque sur les DNS ?
Bonjour, Le 23/02/2019 à 14:29, Vincent Duvernet a écrit : > Bonjour, > > Je viens de voir passer cet article : > https://www.ouest-france.fr/high-tech/internet/des-attaques-informatiques-massives-contre-des-noms-de-domaine-internet-6233756 > Certains ont vu passer des faits concrets ? Cet article [1] en anglais présentent les différentes attaques/menaces recensées à ce sujet. L'ICANN à ce sujet recommande à tout le monde de déployer DNSSEC [2]. Ce n'est bien sur par l'outil ultime mais ça permet de rendre plus difficile ces attaques... 1. https://krebsonsecurity.com/2019/02/a-deep-dive-on-the-recent-widespread-dns-hijacking-attacks/ 2. https://www.icann.org/news/announcement-2019-02-22-en -- Willy Manga @ongolaboy https://ongola.blogspot.com/ signature.asc Description: OpenPGP digital signature
Re: [FRnOG] [MISC] Adoption de nouveaux protocoles
Bonjour, Le 11/03/2019 à 12:32, Toussaint OTTAVI a écrit : > > Le 11/03/2019 à 10:27, Samuel Thibault a écrit : >> Pour que tout reste possible, oui. > C'est quoi, "tout" ? >[...] > Qui peut citer un seul exemple d'une application concrète, dans laquelle > 3 milliards de machines ou de personnes ont besoin d'en contacter 3 > milliards d'autres ? Sauf erreur le besoin d'IPv6 ne se résume pas en terme de quantité d'adresses exploitables. C'est bien évidemment la première chose qui vient en tête . Mais il y a aussi, et c'est ce qui moi m'intéresse le plus, la possibilité de segmenter plus finement des niveaux hiérarchiques. On peut se permettre d'avoir presque autant de niveaux qu'on souhaite et faire en sorte que tous soient globalement routables sur Internet ET en fonction des politiques de sécurité qu'on se sera fixées. > Dans tous les domaines de la vie courante, sur ce qui reste encore de > notre sympathique planète, on cherche aujourd'hui à optimiser, > rationaliser, économiser, réduire les consommations et les empreintes > carbone. Et nous, nous devrions nous permettre le luxe de gaspiller des > milliards de milliards d'adresses, dont seul un pourcentage > infinitésimal de combinaisons sera réellement utilisé ? C'est en IPv4 qu'on avait fait du gaspillage surtout au début. Pourquoi ça dérange certains de (re)partir sur de bonnes bases en pensant sur les décennies (voire les siècles) à venir ? :) . Pour le moment nous n'utilisons que 2000::/3 pour les adresses globalement routables -- Willy Manga @ongolaboy https://ongola.blogspot.com/ signature.asc Description: OpenPGP digital signature
Re: [FRnOG] [MISC] Adoption de nouveaux protocoles
Hello. Le 06/03/2019 à 19:40, Radu-Adrian Feurdean a écrit : > [...] > Dual-stack c'est un bon premier pas. Encore mieux c'est de commencer a > pousser v6-only cote client + NAT64 & DNS64. Ou encore mieux et s'il devenait standard [1], ça serait v6-only + IPv4aaS :) 1. https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-ipv4aas/ -- Willy Manga @ongolaboy https://ongola.blogspot.com/ signature.asc Description: OpenPGP digital signature
Re: [FRnOG] [MISC] Adoption de nouveaux protocoles
Bonjour, Le 11/03/2019 à 19:25, Michel Py a écrit : >> David Ponzone a écrit : >> Et bien justement, au sujet du déploiement d’IPv6, un mec vient >> d’envoyer cette présentation qu’il a fait au dernier RIPE summit. >> https://ripe77.ripe.net/presentations/29-ipv6-only_v12_16-9.pdf >[...] > T'as vu combien il y a de mécanismes de transition (p.8) ? > Et l'usine à gaz p.36 ? > Pour l'effet K.I.S.S cool, c'est raté. Ceux qui déploient un nouveau réseau/service devrait intégrer dès le début IPv6. Ca sera nettement plus facile par la suite. Pour tout le reste, c'est clair que l'évolution dépend du contexte. Quant aux différents mécanismes, ça dépend d'où on regarde. S'il n y avait pas de propositions certains auraient râlé en se plaignant qu'on veut les obliger à passer radicalement à IPv6. Tous ces mécanismes ont le mérite d'exister et d'encourager chacun suivant son contexte à pouvoir franchir le pas. Mais à mon humble avis, le problème n'est pas principalement technique. C'est un problème de volonté et de motivation. Aussi bien dans les milieux lucratifs que non lucratifs (c'est dommage de ne pas voir plus d'universités déployer IPv6 dans leurs réseaux par exemple) En tout cas pour ceux qui utilisent IPv6, ça marche très bien et aimeraient bien se passer de tomber sur des ressources qui ne sont qu'en v4-only. -- Willy Manga @ongolaboy https://ongola.blogspot.com/ signature.asc Description: OpenPGP digital signature
Re: [FRnOG] [MISC] Adoption de nouveaux protocoles
Bonjour, Le 08/03/2019 à 00:22, "Florent H. CARRÉ (COLUNDRUM)" a écrit : > Bonsoir la liste, >[...] > À l'heure actuelle, le passage en full IPv6 est actuellement bloqué de mon > côté parce qu'on perdrait l'avantage d'avoir un firewall d'étage, un firewall > global de site … Avec une bonne compréhension des adresses et un bonne répartition des plages d'adresses, ça sera encore plus facile en v6 pour ton ou tes firewall. Exemple si tu disposes d'un /48 , ton firewall global appliquerait les politiques les plus 'souples' et au fur et à mesure que tu sois obligé d'avoir un réseau particulier (dans un /52, /56, ...) , tu aurais des règles plus strictes. > On filtre à fond et surtout on est des anti-upnp. > (On a même prévu de basculer sur freeDiameter à la place de freeRadius, on > est à fond sur le TLS & co (U2F…) en ce moment même en interne). > > Les serveurs sont tous en automatisation extrême : on a un Ansible AWX qui > tourne avec des jobs qui sont exécutés toutes les 5/10/30 minutes suivant ce > que les jobs font afin d'avoir constamment un parc conforme aux attentes > notamment pour les règles firewall (inclus dans un job tournant toutes les 5 > minutes). > > C'est extrême mais au moins, on arrive à dormir sur nos 2 oreilles sur ce > point. > > Mais que faire pour les postes clients/utilisateurs ? On a de tout et c'est > bien le problème sans oublier le BYOD. Je ne connais pas ton contexte mais en segmentant le réseau en vlan et en confinant chaque catégorie d'utilisateurs dans un vlan dédié contribue à améliorer la gestion. > On doit mettre du firewall de partout et c'est le problème de ne plus avoir > de firewall global … > > On fait un SSID spécial BYOD mais comment éviter de supprimer l'IPv6 dans ce > cas ? Il y a de grandes entreprises qui ont des réseaux wifi pour invité sur IPv6 [1] si ça peut te rassurer. Elles les utilisent notamment pour tous leurs personnels qui souhaitent avoir du wifi pour leurs smartphones. 1. Exemple... https://youtu.be/nd0vgU6WbPo?t=1538 > [...] > On a dans les cartons le fait d'attribuer des IPv6 dédiés par site web > (pourquoi la landing et le serveur d'API devrait utiliser la même IP publique > ?), par service (une pour le ssh admin, une pour le backup) et bien d'autres > … avec notamment du local only et de l'ouvert vers internet suivant les cas. Il y en a qui attribue un /64 par conteneur [2] . Le plus important est de bien structurer son déploiement. 2. (page 62) https://www.ipv6.org.uk/wp-content/uploads/2018/10/FB_IPv6-UK-Council_Dec2017.pdf > Seulement les bastions ssh, les serveurs web et autres nécessaires seraient > disponible sur internet tandis que les restants seraient exclusivement en > local only. Tu pourrais attribuer plusieurs adresses unicast aux serveurs sur différentes plages. Une pour plage pour les accès publiques et une pour les accès internes. > [...] > Peut-être que je suis l'un de ceux qui ne veut pas rester dans l'ombre, ose > le dire, cherche des solutions (ne plus trop penser NAT notamment) et espère > qu'un jour, on soit en IPv6 only (LAN et WAN). Courage. De manière incrémentale , c'est possible :) > Je ne lance pas une bouteille à la mer mais je dois admettre que > personnellement, je suis preneur de retours d'expériences et même d'échange > pour mettre en place (migration) une dual-stack la plus efficiente et surtout > open source (pas de black box sinon j'aurais déjà toqué à la porte de > CP). Ca serait intéressant de participer par exemple à au moins une réunion du RIPE [3] et/ou de consulter les supports de présentation déposés en ligne [4]. La prochaine réunion , RIPE78, aura lieu en islande en Mai. Ca te permettra de discuter avec un grand nombre de personnes et aussi de comprendre plusieurs enjeux :) 3. https://www.ripe.net/participate/meetings/ripe-meetings 4. https://ripe.ripe.net/archives/ où est le numéro de la réunion > N'y aurait-il pas un moyen de faire une sorte de référentiel (BCP book) signé > FRnOG sur le sujet ? Je t'aurai conseillé un MOOC «Objectif IPv6» [5] mais il n y a pas d'inscription en ce moment. A défaut de connaitre des initiatives sur le sol français, il faut consulter les différentes possibilités de formation [6] avec le RIPE NCC. 5. https://www.fun-mooc.fr/courses/course-v1:MinesTelecom+04012+session04/about 6. https://www.ripe.net/support/training -- Willy Manga @ongolaboy https://ongola.blogspot.com/ signature.asc Description: OpenPGP digital signature
Re: [FRnOG] [TECH] DNS adressage publique et privé d'un même domaine
Bonjour, si le problème de fond est d'autoriser ou pas d'atteindre une cible suivant d'où on vient, une des solutions serait de rajouter des adresses IPv6 (unicast) partout. Tu aurais une seule entrée dans le fichier de zone et le plus important est d'avoir des règles de filtrage correctes ;) Le 08/02/2019 à 15:27, AYANIDES, Jean-Philippe a écrit : > Bonjour, > > je n'arrive pas à trouver une réponse justifiée à la question suivante, alors > je m'adresse à vous sur conseil de mes collègues (désolé si ce sont des > questions bêtes et rebattues, je n'ai rien trouvé dans les archives de la > frnog) : > > dans le cadre d'une organisation example.com, à supposer que la zone > corp.example.com ne soit pas répliquée dans les DNS publiques example.com > ouverts sur internet, est-il possible et/ou non déconseillé, dans les DNS > internes > > - de résoudre un enregistrement A a.corp.example.com en adresse privée ? (de > façon générale, on a tendance à utiliser des noms locaux avec un TLD .local > mais l'IETF ne le recommande pas, cf. > https://tools.ietf.org/html/rfc6762#appendix-G). > > - de résoudre un même SOA corp.example.com avec une adresse IP privée depuis > le DNS interne privé et une adresse publique depuis le serveur DNS interne > publique ? > > - de résoudre certains enregistrements A du domaine corp.example.com en > adresses publiques et d'autres en adresses privées ? > > Si rien n'est possible proprement, quelle alternative peut-on trouver ? > faut-il segmenter en nommant par exemple tout ce qui est adressage publique > en pub.corp.example.com et tout ce qui est en adressage privé en > priv.example.com ? > > Je vous avoue que je ne suis pas familier avec la RFC… > > Merci > > Jean-Philippe -- Willy Manga @ongolaboy https://ongola.blogspot.com/ signature.asc Description: OpenPGP digital signature
Re: [FRnOG] [MISC] l'Internet de la cohabitation
. On 22/05/2019 05:31, Michel Py wrote: > Lecture légère de milieu de semaine : > > > > https://www.internetgovernance.org/2019/01/04/is-there-hope-for-ipv6/ > https://www.internetgovernance.org/2019/02/20/report-on-ipv6-get-ready-for-a-mixed-internet-world/ yoshi:~ yoshi$ dig +short www.internetgovernance.org internetgovernance.org. yoshi:~ yoshi$ dig +short internetgovernance.org yoshi:do yoshi$ Ok. Les IPv6-only peuvent-ils avoir le droit de lire aussi svp ? :) P.S: Ca s'active très facilement depuis le panel de Linode ... -- Willy Manga @ongolaboy https://ongola.blogspot.com/ signature.asc Description: OpenPGP digital signature
Re: [FRnOG] [MISC] l'Internet de la cohabitation
. On 22/05/2019 20:56, Michel Py wrote: >> Willy Manga a écrit : >> Les IPv6-only peuvent-ils avoir le droit de lire aussi svp ? :) > > Bien sur que oui, en utilisant XLAT464, NAT64, DNS64, ou une des autres > méthodes plus ou moins batardes qui existent. Elles ont le mérite d'exister et chacune répond à un contexte. Contextes qui dépendent à 98% de ceux qui utilisent IPv4 :) . Mais le problème n'est plus la technique depuis quelques années au moins dans la très grande majorité des cas. Le problème, si c'en est même un, ce sont les Hommes et l'économie. > La balkanisation de l'Internet sous nos yeux. Je suis de ceux qui encourageront toujours à suivre les standards de l'Internet (tels que proposés,discutés, approuvés au sein de l'IETF). Et pour le cas d'espèce à recommander de passer progressivement IPv6 (je laisse DNSSEC; DANE; RPKI pour plus tard ou sur une autre liste ) Je ne vais pas dénigrer les usages que certains veulent faire perdurer avec IPv4; c'est leur choix. Mais il ne faut pas dénigrer non plus ce qui est fait aussi pour faire avancer le fonctionnement de l'Internet et effrayer les sceptiques ou nouveaux. -- Willy Manga @ongolaboy https://ongola.blogspot.com/ signature.asc Description: OpenPGP digital signature
[FRnOG] [TECH] Firewall IPv6 chez Free (et les autres)
Bonjour, je ne suis pas un client de FREE mais j'ai vu passé une mise à jour de FREE relative à IPv6 sur leurs freebox server [0]. C'est une bonne nouvelle mais il serait aussi intéressant de fournir des règles de filtrage par défaut dans les boîtiers. Au moins des restrictions sur le trafic entrant. Cette tâche[1] ouverte à l'époque et qui n'avait pas autant d'importance devrait à mon humble avis être revue et corrigée (si ce n'est pas déjà en cours) De manière plus générale, je pense que ça doit amener tous les opérateurs à le prévoir dans les mises à jour de leurs CPE et autres terminaux ... 0. https://dev.freebox.fr/blog/?p=5382 1. https://dev.freebox.fr/bugs/task/4110 -- Willy Manga @ongolaboy https://ongola.blogspot.com/ signature.asc Description: OpenPGP digital signature
Re: [FRnOG] [MISC] La taxe sur IPv4
. On 16/10/2019 16:57, Denis Fondras wrote: > [...] > Le plus judicieux est de prendre le problème par l'autre bout et que tous les > services accessibles publiquement le soient en IPv6 (comme le fait le DoD). Ou les hollandais présenté ce lundi à l'ouverture du meeting du RIPE https://ripe79.ripe.net/archives/video/164 https://ripe79.ripe.net/wp-content/uploads/presentations/14-20191014-RIPE79_presentation_VNG_R_V1.43_FINAL.pdf -- Willy Manga @ongolaboy https://ongola.blogspot.com/ signature.asc Description: OpenPGP digital signature
Re: [FRnOG] [MISC] La taxe sur IPv4
. On 16/10/2019 14:40, David Ponzone wrote: >>[...] > Je pense que ce que Michel voulait dire, c’est que quand le DoD a annoncé une > migration en v6, cela signifiait une migration de tous leurs desktop en > dual-stock au moins, voir en v6 pur. Et ça fait beaucoup de desktop. Est-ce parce qu'ils auraient passé tous leurs postes en IPv6 que cela allait vous convaincre ? :) > Le site du NIST ne donne aucune idée du déploiement du v6 en interne, juste > de l’avancement de la migration de la façade, le site web. > C’est pas que le site Web du DoD soit en v6 qui va pousser les gros FAI à > migrer :) Au moins la grande majorité est désormais accessible en IPv6. Je suis sur que si ce n'était pas le cas, on aurait jasé :) . -- Willy Manga @ongolaboy https://ongola.blogspot.com/ signature.asc Description: OpenPGP digital signature
Re: [FRnOG] [MISC] La taxe sur IPv4
. On 15/10/2019 14:47, David Ponzone wrote: > Je suis tombé là-dessus un peu par hasard: > > https://bfmbusiness.bfmtv.com/01-business-forum/la-migration-des-reseaux-ipv6-vers-un-veritable-enjeu-220837.html > > <https://bfmbusiness.bfmtv.com/01-business-forum/la-migration-des-reseaux-ipv6-vers-un-veritable-enjeu-220837.html> > > Ca date de 2003. > > Question pour l’Ami Américain: alors, il a migré en IPv6 le DoD ? Statistiques (en temps réel ici) https://fedv6-deployment.antd.nist.gov/cfo.html -- Willy Manga @ongolaboy https://ongola.blogspot.com/ signature.asc Description: OpenPGP digital signature
Re: [FRnOG] [MISC] RIPE IPv4 run-out
. On 02/10/2019 14:06, Sébastien Lesimple wrote: > Et les TAAF/Polynésie/Wallis-Futuna/Nouvelle Calédonie/Clipperton, c'est > considéré comment niveau APNIC/RIPE? C'est dans la région de l'APNIC https://www.apnic.net/about-apnic/corporate-documents/documents/corporate/apnic-service-region/ -- Willy Manga @ongolaboy https://ongola.blogspot.com/ signature.asc Description: OpenPGP digital signature
Re: IPv6 Q (Was Re: [FRnOG] [MISC] La taxe sur IPv4)
Hello, On 11/10/2019 13:00, Julien Escario wrote: > Le 11/10/2019 à 10:30, David Ponzone a écrit : >> Je pense qu’il serait surtout intéressant de partager les échecs, et surtout >> les définitifs (ceux qu’on n’a pas réussi à transformer en succès). > > Bonne idée ! > > Je me lance : côté serveur, on trouve pas mal de docs sur le net sur la > manière de configurer un subnet IPv6 sur son serveur quand on est chez > tel ou tel hébergeur. Une liste [1] qui se complète depuis quelques jours 1. https://docs.google.com/spreadsheets/d/1gpHAfvsE_1mNcdHbrj1Uc4YFr0XspX76dfXGRA6eDFc/edit?usp=sharing Si vous en connaissez d'autres, il faudra laisser un commentaire à Lee. > [...] > P.S. : ça manque encore cruellement de doc 'simple' sur le déploiement > IPv6 pour certains use case basiques : sur un LAN d'entreprise, sur un > réseau de collecte *PPP, sur un réseau routé publiquement (Aka DMZ), etc > ... pour que les admins puissent s'y retrouver facilement. A AFRINIC nous avons un webinaire [2] pour en parler/discuter le 17 Octobre 2019 à 12h30 UTC+0 . Donc si ça intéresse certain(e)s ... Mais plus proche de vous, la semaine prochaine lors du RIPE79[3] il y aura certainement des sujets intéressants à ce propos. 2. https://zoom.us/webinar/register/6015629166471/WN_DjHYOKewT1OIiewznX-gJw 3. https://ripe79.ripe.net/ -- Willy Manga @ongolaboy https://ongola.blogspot.com/ signature.asc Description: OpenPGP digital signature
Re: [FRnOG] [MISC] C'est moi ou Le troll du dredi est mal en point?
Hello On 21/12/2019 09:59, Florent CARRÉ wrote: > [...] > - pourquoi les opérateurs assignent un /64 par connexion cliente? C'est recommandé au niveau de ce BCOP : RIPE-690 [1] Cela permet d'englober tout ce qui est possible avec chaque type de client. Et pour être même plus fin, sur chaque /64 on peut définir un /127 (voire un /126 pour ceux qui ne suivent pas la RFC6164) pour les liaisons point à point. > En IPv6, j'ai un /64, est-ce normal un tel gâchis d'IP? Ou suis-je trop en > mode IPv4 avec le manque d'IP? En IPv6 Ce n'est pas le nombre d'adresses qui compte mais plutôt le *type* d'usage qui sera fait de cette portion qui est le plus important. A chaque type, un préfixe dédié et ceci vaut pour toutes les couches du réseau (bordure, coeur de réseau, accès,...) 1. https://www.ripe.net/publications/docs/ripe-690#4-1-1---64-prefix-from-a-dedicated-pool-of-ipv6-prefixes -- Willy Manga @ongolaboy https://ongola.blogspot.com/ signature.asc Description: OpenPGP digital signature
Re: [FRnOG] Re: [TECH] Demande de vidage partiel de caches DNS
. On 20/02/2020 20:17, Thomas Quinot wrote: > [...] > La zone étant restée correcte chez le registre, je suppose que les > résolveurs DNSSEC validants auront juste rejeté les mauvaises infos. > J'ai bon ? La zone assemblee-nationale.fr n'est pas signée. Donc par conséquent la validation ne peut pas s'appliquer ici malheureusement. -- Willy Manga @ongolaboy https://ongola.blogspot.com/ signature.asc Description: OpenPGP digital signature
Re: [FRnOG] [TECH] Big brother ou pas
Bonjour, On 04/09/2020 03:01, David Ponzone wrote: > Spécialistes du mobile, > > Il m’est arrivé un truc étrange aujourd’hui. > J’étais en ligne sur mon mobile Orange avec un mobile SFR à l’étranger. > Au bout de quelques minutes de conversation (de qualité moyenne), j’ai senti > que mon interlocuteur n’entendait plus ce que je disais. Et pour cause, j’ai > fini par réaliser que j’entendais le replay de tout ce qu’il m’avait dit > depuis le début. Je lui ai fait un sms et il m’a confirmé que de son côté ca > avait raccroché. > Je vous jure que j’ai pas rêvé. Tu n'as pas rêvé. J'ai très régulièrement eu ce problème l'année passée en émettant des appels depuis Maurice (MyT) vers le Cameroun (ORANGE,MTN). A tel point que je me suis habitué à faire 59 secondes à chaque fois si je voulais absolument utiliser ce mode de communication. Cette année un peu moins mais c'est parce que je me suis résigné à ne plus trop essayer. Je suis sur qu'il y a d'autres types problèmes similaires entre d'autres réseaux téléphoniques. -- Willy Manga @ongolaboy https://ongola.blogspot.com/ signature.asc Description: OpenPGP digital signature
Re: [FRnOG] [TECH]: Microsoft Teams et serveur
Bonjour, (je me limite ici à ce qu'il faut considérer avant teams) On 22/06/2020 18:20, Anthony Frnog wrote: > Bonjour, > > [...]> Le client possède déjà son propre serveur mail (sous Postfix) et d'après ce > que j'ai pu voir sur des documentations Microsoft, il faut (faudrait) > rediriger les champs MX su domaines vers ceux de Microsoft. > > Est-ce exacte? Oui si l'objectif est de migrer également les boîtes aux lettres. Si je considère que votre domaine est exemple.com, il y aura toujours un nom de domaine spécifique (du style exemple.onmicrosoft.com) qui sera créé pour la gestion de tout ce qui se fera dans le "tenant". Il y aura des informations à configurer entre le "tenant" MICROSOFT et l'infrastructure existante pour effectuer la passerelle: des entrées dans le fichier de zone exemple.com notamment. > Si oui, comment le client fait-il pour toujours recevoir les mails entrants > sur son serveur mails? Le MX du fichier de zone exemple.com continuera à pointer sur le serveur postfix. Maintenant au niveau de la livraison du message: - si vous migrez les boîtes aux lettres dans le tenant Microsoft, il faudra relayer les messages vers le domaine exemple.onmicrosoft.com - si les messages sont toujours stockés hors du tenant, ça sera comme d'habitude livrés dans exemple.com > Si certains d'entre vous ont déjà mis en place Teams tout en conservant le > serveur mail du client, je suis preneur de toutes remarques. Je n'ai pas utilisé teams mais ça sera quelque chose à voir après car il faudra vous accorder sur plein de choses dont: - la gestion du DNS - la gestion des boîtes aux lettres - la gestion de tous les services autour d'office365 fournis avec le package choisi - et quelque part la gestion de teams :) -- Willy Manga @ongolaboy https://ongola.blogspot.com/ signature.asc Description: OpenPGP digital signature
Re: [FRnOG] [TECH][BGP] Traffic arrivant sur un seul lien au lieu de deux
Bonjour, On 09/06/2021 20:09, Mathieu KERN via frnog wrote: > Bonjour a tous, > > J'ai un problème avec notre AS34536 que j'ai du mal a comprendre, nous avons > deux liens, avec cogent et SFR, et annonçons nos préfixes 80.77.225.0/24 et > 80.77.224.0/24 des deux cotés, en utilisant l'AS prepending pour ne faire > rentrer que l'un des prefixes pour chaque lien quand ils sont fonctionnels. > Le 224 passe par SFR ( AS1557) et le 225 devrais passer par cogent, mais ce > n'est pas le cas depuis plusieurs jours, alors que la configuration n'a pas > changé depuis des semaines. > > Hors en regardant plusieurs looking glass je ne vois pas de problème > d'annonces. J'ai même demandé a cogent, qui me confirme que eux même > reçoivent bien nos annonces BGP avec les bons chemins. > > Si quelqu' un peut m'orienter dans le bonne direction, je lui en serais > reconnaissant. Ce n'est pas forcément lié mais est-ce que vous pourriez aligner vos annonces avec les objets route (dans la base IRR du RIPE) ? il y a présentement : - 1 objet route pour 80.77.225.0/24 avec pour origine as12670 - aucun objet route ni pour 80.77.225.0/24 ou 80.77.224.0/24 avec pour origine as34536 - pas de ROA aussi (mais ça peut être l'objet d'un autre débat) -- Willy Manga @ongolaboy https://ongola.blogspot.com/ OpenPGP_signature Description: OpenPGP digital signature
Re: [FRnOG] [TECH] Le prix des adresses IPv4
On 28/06/2021 20:49, Vincent Habchi wrote: > Hey, > >> Oh certainement pas l'état Américain ni l'ONU. L'ICANN serait probablement >> le choix le plus répandu, mais ne fait pas l’unanimité. > > Quels sont les autres ? > > Merci pour le point historique ! > > Mais cette histoire de non-propriété est un peu problématique. > Qu’arriverait-il si quelqu’un se mettait à publier une route pour un segment > (disons, pour faire moins conflictuel, non attribué) sans l’autorisation du > régional correspondant, ou de l’ICANN ? Et défendait son bout de gras en > disant que, puisque les adresses sont, pour ainsi dire, res nullius, rien ne > l’empêche de s’en attribuer un morceau ? Raison pour laquelle il existe IANA et les RIR pour 'ordonner' et classifier les ressources Internet. Par 'ressources Internet' j'entends IPv4 mais aussi IPv6 et numéros de système autonome (bien sur il y a d'autres types d'identifiants gérés par IANA mais tel n'est pas l'objet ici). Les RIR par la même occasion proposent plusieurs outils dont: - les régistres de ressources internet (IRR)[1] dont les objets qui figurent au centre sont _route_ pour IPv4 et _route6_ pour IPv6 . - les _ROA_ grace à l'infrastructure RPKI qui est un certificat numérique qui ne peut être généré que par l'entité qui a reçu une allocation/assignation et qui indique quel numéro d'AS a le droit d'annoncer un préfixe (IPv4 ou IPv6) Ceci concerne les membres dans un RIR donné. Ils vont donc rajouter des informations supplémentaires aux ressources allouées ou assignées par le RIR respectif. De l'autre côté, n'importe quel opérateur réseau sur Internet peut construire ses politiques de routage en se basant en priorité sur les informations produites dans les bases IRR et les ROA générés ... Une règle pouvant être de ne pas accepter de préfixe si on ne trouve pas d'objet route(6) conforme ou de rejeter les ROA invalides par exemple ... Je dis "en priorité" parce qu'ils existent en dehors des régistres mis en place par les RIR d'autres régistres ... chacun ayant ses règles que je ne commenterais pas... 1. j'espère n'avoir pas trop mal traduit :P -- Willy Manga @ongolaboy https://ongola.blogspot.com/ OpenPGP_signature Description: OpenPGP digital signature
Re: [FRnOG] [MISC] IPv6 potentiellement plus dangereuse qu'IPv4 ?
Bonjour, On 26/04/2021 22:02, Michel Py via frnog wrote: >> Michel Py a écrit : >> [...] > Hélas non, ça fait toujours 2^(128 - 29), les 64 bits de droite étant > disponibles :-( (à moins de bloquer dès le départ à /64). > Et puis, même si ça n'était "que" 2^(128 - 29 - 64), ça ferait quand même > 2^35 soit 34.359.738.368, suffisamment pour exploser ta blacklist. > Un PC peut se reconfigurer lui-même, peut-être pas avec complètement 2^64, > mais suffisamment pour être trop énorme pour suivre. > Je n'y connais pas vraiment grand-chose, faudrait regarder dans les environs > de ça : > https://tools.ietf.org/html/rfc4941 C'est désormais la RFC8981 qui la remplace totalement https://tools.ietf.org/html/rfc8981 "Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6" >> (Par contre je ne comprends par comment cela pourrait préserver la vie >> privée de changer d'adresse dans une plage /64). > > C'est une histoire de suivi (tracking) et de corrélation. Tout comme les > cookies, big data suis ton adresse IP. Exemple typique : je suis en train de > surfer dur mon PC, et le peu de pub qui passe à travers sont à propos de > switch, d'optiques, ou autres. Ma femme achète un sous-tif en ligne (de son > PC, pas du mien), et bam tout d'un coup les pubs que je reçois sont de la > lingerie féminine. Comment tu crois que ça arrive ? On est tous les deux > derrière NAT sur la même IP publique. Big data. Je pense que ces opérateurs ont des mécanismes qui ne se basent pas seulement sur l'IP pour "caractériser" une personne. > Vu que avec IPv6 soi-disant il n'y a pas de NAT, chaque PC serait (en plus de > l'IP de la famille) identifiable individuellement, l'adresse IPv6 étant une > fonction de l'adresse MAC (les 64 bits de droite). Ce qui permettrait un > suivi encore plus pointu et les GAFA de mettre leur nez encore plus profond. > L'idée c'était donc que, dans la plage du subnet local /64, l'adresse du PC > change régulièrement, ce qui en théorie empêcherait le tracking. Sauf que il y a tellement de méthodes pour tracker que l'utilité est douteuse. Je serais plus fin en disant "chaque interface réseau" et non juste PC peut avoir au moins une adresse globalement routable (mais dans la pratique c'est souvent au moins 2). Même si je doute que tous les systèmes d'exploitation implémentent absolument la RFC 8981 à l'heure actuelle; la plupart, sinon tous, n'emploieront jamais l'adresse IPv6 générée à partir de l'adresse MAC (EUI-64) pour le traffic de *sortie*. Il y a plusieurs autres mécanismes pour générer des adresses. En terme de privacy, ici ce qui compte c'est que si mon interface réseau (ou plus grossièrement mon PC) se retrouve dans un autre LAN, chez moi ou ailleurs, les adresses générées de manière temporaire n'auront pas les mêmes "caractéristiques" d'un réseau à l'autre. La RFC https://tools.ietf.org/html/rfc7721 résume toutes les considérations à prendre en compte en terme de sécurité et privacy pour IPv6. Le tableau 1 fait un résumé de l'analyse. -- Willy Manga @ongolaboy https://ongola.blogspot.com/ OpenPGP_signature Description: OpenPGP digital signature
Re: [FRnOG] [MISC] IPv6 potentiellement plus dangereuse qu'IPv4 ?
. On 27/04/2021 20:06, Michel Py wrote: >> [...] > >> Même si je doute que tous les systèmes d'exploitation implémentent >> absolument la >> RFC 8981 à l'heure actuelle; la plupart, sinon tous, n'emploieront jamais >> l'adresse >> IPv6 générée à partir de l'adresse MAC (EUI-64) pour le traffic de *sortie*. > > Aucune importance, le merdiciel va générer sa propre adresse et la choisir > pour envoyer son trafic. > Disons que ton réseau local soit 2001:DB8:CAFE:BABE::/64. Rien ne t'empêche > de prendre : > 2001:DB8:CAFE:BABE::1 pour ton routeur > 2001:DB8:CAFE:BABE::2 pour ton serveur > 2001:DB8:CAFE:BABE::3 pour ton iPBX > Etc. En partant du même principe, le merdiciel peut prendre n'importe > laquelle des 2^64 adresses disponibles. Sauf qu'ici si tu comptes plus d'un type d'usage, alors tu mettras chaque type d'usage dans son propre LAN. Pour suivre ton exemple, - ton routeur auras bien sur une interface dans chacun des LAN (donc chacun des /64), - tu auras à minima un autre /64 pour tes serveurs - et un autre /64 pour tous les PC, smartphone,... de la maison .. Un usage = 1 LAN Moi typiquement pour aller plus loin j'aurais eu : - un /60 pour mes serveurs où certains auront des VM avec chacune un /64 derrière (oui, même pour la mini VM dans un virtualbox, lxc de ma machine xyz,...) - un /60 pour les besoins de la maison contenant - un /64 pour mon réseau de caméra - un /64 pour les PC de la maison - un /64 pour toute la domotique - un /64 pour le wifi des interfaces connus - un /64 pour le wifi "guest" - et ainsi de suite, pour tous les types d'usage possible et inimaginable. J'espère que les uns et les autres comprendront pourquoi c'est vachement plus intéressant d'allouer au moins un /56 pour un client résidentiel ;) Madame Michu ne fera pas tout ça bien sur mais c'est possible de proposer des services aux clients résidentiels et les placer chacun dans son propre LAN. Chaque usage étant "cloisonné" avec les ACL qui vont bien avec. > En ayant un réseau d'une taille aussi importante, dont l'adresse n'est pas > réécrite par NAT, on a créé deux nouveaux profils d'attaque : > > - Changer d'adresse souvent pour éviter de se faire bloquer par les systèmes > de blacklist. > - Attaquer directement les systèmes de blacklist en générant tellement > d'entrées qu'ils s'effondrent. > > Dans les deux cas, la solution évidente est de blacklister le /64 dont lequel > l'adresse fait partie, au lieu de blacklister l'adresse elle-même. Oui, bien sur que tu bloqueras le /64 en question "temporairement". Mais je pense que la résolution du problème de fond sera, de manière ultime, qu'il y ait une remontée d'informations quelque part et des échanges entre gestionnaires réseaux (responsables) quand le problème est important et localisé. Etant donné que les blocs de chaque client sont "uniques", le FAI peut plus facilement localiser la source du problème. Pour tout cela (et bien d'autres) ... chaque type d'utilisateur trouvera un intérêt à utiliser IPv6 :) -- Willy Manga @ongolaboy https://ongola.blogspot.com/ OpenPGP_signature Description: OpenPGP digital signature
Re: [FRnOG] [MISC] IPv6 potentiellement plus dangereuse qu'IPv4 ?
On 27/04/2021 21:22, David Ponzone wrote: >> >> J'espère que les uns et les autres comprendront pourquoi c'est vachement >> plus intéressant d'allouer au moins un /56 pour un client résidentiel ;) >> >> Madame Michu ne fera pas tout ça bien sur mais c'est possible de >> proposer des services aux clients résidentiels et les placer chacun dans >> son propre LAN. Chaque usage étant "cloisonné" avec les ACL qui >> vont >> bien avec. > > Je serais curieux de savoir quels sont les systèmes domo et autres (sono, media server, etc…) qui marchent encore en segmentant comme ça avec des ACL entres les LAN :) > Déjà que la plupart des mécanismes automagiques ne marchent plus si tu > sépares ton LAN en 2 subnet IP… A aucun moment on ne subdivise un /64 dans ce que je propose :) . Je n'ai pas un cas pratique sous la main mais si pour les besoins d'usage un certain nombre d'équipements doivent absolument être dans le même LAN (le même /64) alors ils resteront dans le même réseau. Un usage = 1 LAN = 1x/64 Le cas le plus simple sera 2 LANs: 1 pour tout ce qui est connu à la maison et 1 autre pour les invités. Ce que j'indique est plus un appel aux constructeurs/intégrateurs à prendre en compte la manière dont des services peuvent exploiter de manière efficiente IPv6 (multicast inclu). -- Willy Manga @ongolaboy https://ongola.blogspot.com/ OpenPGP_signature Description: OpenPGP digital signature
Re: [FRnOG] [MISC] IPv6 potentiellement plus dangereuse qu'IPv4 ?
On 27/04/2021 22:49, David Ponzone wrote: >> >> A aucun moment on ne subdivise un /64 dans ce que je propose :) . Je >> n'ai pas un cas pratique sous la main mais si pour les besoins d'usage >> un certain nombre d'équipements doivent absolument être dans le >> même LAN >> (le même /64) alors ils resteront dans le même réseau. >> >> Un usage = 1 LAN = 1x/64 >> > > Oui tu as bien plusieurs /64 non ? oui > Tu dis "- ton routeur auras bien sur une interface dans chacun des LAN (donc > chacun des /64), ». > Donc ton app iPhone Hue par exemple ne verra pas le pont Philips Hue > automagiquement. Oui il faudra router sinon ils restent dans le même réseau. -- Willy Manga @ongolaboy https://ongola.blogspot.com/ OpenPGP_signature Description: OpenPGP digital signature
Re: [FRnOG] [MISC] La "backdoor" de Chrome
Bonjour, On 07/04/2021 02:22, N R wrote: > Bonsoir, >[...] > > Le fond de tout ça c'est la confiance qu'on peut accorder à ce à quoi > on se connecte et comme Michel Py l'a bien dit, c'est un marché comme > un autre. C'est pour ça qu'il y a DANE où (en gros) la confiance ne repose pas sur des Autorités de Certification mais sur les enregistrements fournis dans le fichier de zone signé (donc DNSSEC) par son gestionnaire. Ce qui, à mon humble avis, devrait avoir plus de crédit étant donné qu'il n y a plus d'intermédiaire dans la chaîne de confiance entre le demandeur de la ressource et le propriétaire de la ressource. -- Willy Manga @ongolaboy https://ongola.blogspot.com/ OpenPGP_signature Description: OpenPGP digital signature
Re: [FRnOG] [TECH] Subnet ip publique sur LAN
On 16/03/2021 14:42, David Ponzone wrote: > Oui enfin, ça dépend si on parle d’un /29 avec 4 PC actifs ou d’un /16 avec > 3000 PC actifs. > > Faut surtout regarder à qui appartiennent les IP Publiques en question. > Si c’est à l’autre bout de la Terra, peu de chance que ça pose problème un > jour. Je pense qu'il vaut mieux toujours être prudent; sans compter sur le fait qu'il y a des solutions plus perennes. ex:AS8003 qui annonce depuis peu - 7.0.0.0/8 - 11.0.0.0/8 - 22.0.0.0/8 Discussion (en anglais) à ce sujet ici [1] Quand un bloc est alloué à une organisation, il vaut mieux le considérer tel quel (et donc ne pas l'utiliser à son propre compte) même s'il n'est pas routé sur l'Internet. 1. https://mailman.nanog.org/pipermail/nanog/2021-March/212569.html -- Willy Manga @ongolaboy https://ongola.blogspot.com/ OpenPGP_signature Description: OpenPGP digital signature
Re: [FRnOG] [TECH] Subnet ip publique sur LAN
On 16/03/2021 14:25, Fabien H wrote: > Solution propre : changer le LAN pour respecter la RFC Solution *plus* propre et perenne: - repenser le réseau de manière à inclure IPv6 - implémenter un mécanisme de transition soit à son niveau ou mieux en fonction de ce que le FAI pourrait proposer ou à négocier - si l'organisation est éligible, elle peut demander ses propres ressources IPv6 au RIPE NCC - si elle n'est pas éligible, négocier avec le FAI afin d'obtenir un bloc IPv6 spécifique -- Willy Manga @ongolaboy https://ongola.blogspot.com/ OpenPGP_signature Description: OpenPGP digital signature
Re: [FRnOG] [MISC] Curieux spam post-FRnog
Hello, On 28/03/2022 17:11, frnog.kap...@antichef.net wrote: On lundi 28 mars 2022 15:11:10 CEST Stephane Bortzmeyer - bortzme...@nic.fr wrote: [...] Le corps du message est en français mais avec des tournures de phrases qu'on emploit pas en français et un lien onedrive pour trouver une supposée facture. Le lien malveillant qui permet de rendre le processus viral si on tombe dedans. En dessous une citation tronquée du message que j'avais envoyé en novembre dernier sur la liste. A $DAYJOB nous avons aussi eu le même type de message en février mais en anglais. Aux premiers abords, dans le contexte géopolitique du moment ça a l'apparence des premières étapes d'une cyber attaque soit provenant de la Russie, soit de faux drapeau pour se faire passer pour la Russie. Une tentative qui ratisse large, et qui a parmi ses cibles clairement des stratégiques comme celui des opérateurs de réseaux. À voir si cette campagne d'intrusion vise d'autres secteurs, à suivre. Je pense qu'au delà du contexte actuel, c'est une 'nouvelle' approche de spaming: trouver un moyen de s'introduire dans une boîte aux lettres, reprendre des anciennes correspondances, rajouter au dessus d'un vrai message un lien vers un site malveillant et envoyer un courriel à toutes les personnes trouvées dans la boîte. -- Willy Manga @ongolaboy https://ongola.blogspot.com/ OpenPGP_signature Description: OpenPGP digital signature
Re: [FRnOG] [Tech] Contact SFR ? (pas de route IPv6 SFR/Renater)
Bonjour, On 30/05/2022 12:42, geoffroy desvernay via frnog wrote: Bonjour à toustes, Depuis bien 2 semaines, les utilisateurs SFR (mobile et dsl) ne peuvent plus joindre l'IPv6 du réseau renater (as2200), j'ai l'impression que ça concerne (au moins) le préfixe 2001:660::/32. la seule source d'infos que j'ai trouvé est leur looking-glass http://peering.sfr.net/index.php?task=lg (le traceroute se perd avant de sortir du réseau SFR) Il y a pourtant plusieurs routes qui mènent vers AS2200 (RENATER) pour ce préfixe IPv6 . Exemple en regardant ici https://lg.ring.nlnog.net/prefix_detail/lg01/ipv6?q=2001:660::/32 A mon humble avis, il faudrait regarder du côté du réseau de SFR. -- Willy Manga @ongolaboy https://ongola.blogspot.com/ OpenPGP_signature Description: OpenPGP digital signature
Re: [FRnOG] [TECH] Appel aux retour d'expérience LAN ipv6 single stack.
Bonjour, On 27/01/2023 14:24, Pierre Colombier via frnog wrote: Bonjour, j'aimerai savoir si certains d'entre vous on déjà essayé de passer un LAN en ipv6 seul avec un nat 6to4 sur la gateway (voir encore plusieurs sauts plus loin) pour aller consulter les sites qui sont uniquement accessibles en v4 ? Si possible il faudrait raccourcir le nombre de sauts (au moins avec la passerelle NAT64); c'est au moins ce que peut permettre IPv6 dans certains contextes. Et si oui, comment gérez vous la problématique du DNS64 ? (C'est à dire fournir les records dans le préfixe 6to4 pour les sites qui n'ont que du A.) Plusieurs résolveurs l'implémentent soit en se servant d'un préfixe generique prevue ( 64:ff9b::/96 ) ou bien en choisissant un /96 dans son propre bloc. Mais bien sur ceci n'est qu'à usage interne. Ici: unbound,bind mais powerdns-recursor et knot-resolver font aussi l'affaire. Pour simplifier, l'hôte envoie une requête , le résolveur constate qu'elle n'existe pas et 'fabrique' une réponse en en se servant du préfixe configuré plus haut. L'hôte se servira donc de cette adresse factice pour échanger à l'aide de la passerelle NAT64. Et finalement avec quel niveau de succès et/ou d'emmerdement ? Tant que la resource à distance s'identifie avec un nom complètement qualifié, ça juste marche. Sinon il faut envisager une autre technique de transition du genre 464XLAT -- Willy Manga @ongolaboy https://ongola.blogspot.com/ OpenPGP_signature Description: OpenPGP digital signature
Re: [FRnOG] [TECH] Appel aux retour d'expérience LAN ipv6 single stack.
. On 27/01/2023 17:08, Rémi Desgrange wrote: En 2020, pendant le confinement, j’avais des collègues qui avaient des cartes SIM Bouygues dans des box 4G (je n’ai plus le modèle). A ce moment-là, je ne sais pas si des choses ont changé, si les box étaient mal configurées, il n’avait pas d’ipv4. Certains des mécanismes déjà décrits dans le thread étaient mis en œuvres. Je sais que l’accès à github en ssh ne fonctionnait pas. Est-ce que la peinture n'était pas fraiche côté Bouygues, était-ce une mauvaise conf du routeur 4G ? Je ne sais pas, mais peut-être que ça vaut le coup de vérifier que les autres protocoles fonctionnent. En tout cas par ici, acceder a github fonctionne sans pb depuis un poste IPv6-only http://paste.debian.net/1268641/ -- Willy Manga @ongolaboy https://ongola.blogspot.com/ OpenPGP_signature Description: OpenPGP digital signature
Re: [FRnOG] [TECH] Appel aux retour d'expérience LAN ipv6 single stack.
. On 28/01/2023 01:35, Pierre Colombier via frnog wrote: merci pour vos réponses. Sur le plan technique c'est à peu près ce à quoi je m'attendais. [...] DNSSEC ? Toutes les considérations sont évaluées dans le RFC (informationnel) 8683 [1] qui donne des directives sur le déploiement de NAT64/464XLAT. La section 4 couvre les cas à considérer pour DNSSEC. 1. https://www.rfc-editor.org/rfc/rfc8683.html Et puis un usager reste libre d'utiliser le résolveur de son choix. Ou alors d'avoir une application qui au lieu d'employer la résolution de nom configurée du réseau fait du DOH sur Cloudflare qui ne sera pas au courant qu'il faut générer des dans le bon préfixe. Un usager c'est (un peu) comme un cours d'eau. Il cherchera toujours des voies de contournement. Du coup j'ai de sérieux doutes sur le fait que ça puisse se faire de façon vraiment transparente et c'est sur ce point que les lumières de la liste m'intéressent. Tout dépend du contexte où l'on se trouve.. car au final tout dépendra du type de réseau, des contraintes, objectifs et des utilisateurs. Mais il y a toujours une approche possible avec ses avantages et inconvénients. -- Willy Manga @ongolaboy https://ongola.blogspot.com/ OpenPGP_signature Description: OpenPGP digital signature
Re: [FRnOG] [TECH] Bloc IPv4 hijacké par un AS bizarre
Bonjour, On 10/08/2023 18:45, admin wrote: Bonjour à tous, [...] -> on en sait absolument rien. Le bloc est hijacké par AS7018. Ils se sont permis de prendre le posession de mon bloc, d'ignorer les ROA/RPKI, et ont quand même annoncé. Le fait d'avoir couvert par un ROA limite au moins cette propagation. C'est ce qui permet que certains ne voient que l'annonce légitime. Comme ici https://lg.ring.nlnog.net/prefix?saved=vSSI4m0iCA [...] J'ai envoyé des abuse partout, des mails de partout pour faire sauter cet AS qui me gêne, mais rien n'y fait. Je suis un peu désamparé. Par défaut ce que j'aurais conseillé dans cet ordre: 1. écrire à l'adresse d'abuse de AT ab...@att.com 2. Contacter les transits qui laissent propager : 3320,6461,16557 3. Signaler dans la liste NANOG .. -- Willy Manga @ongolaboy https://ongola.blogspot.com/ OpenPGP_signature Description: OpenPGP digital signature
Re: [FRnOG] [TECH] Bloc IPv4 hijacké par un AS bizarre
. On 11/08/2023 04:31, Johann wrote: Hello, Pour le leak qui est accepté par AS6461, je viens de fixer la chose. On a encore un ou deux routeurs qui sont en attente de déploiement des validateurs RPKI sur les peers, et malheureusement on avait un peering AT dessus... C'est toujours mieux que rien :) Par contre, je ne sais pas si c'est normal, mais j'ai l'impression que 91.217.219.0/24 n'est plus annoncé par AS51741? [...] si, si exemple: https://lg.ring.nlnog.net/prefix?saved=3YdCTvoYVL -- Willy Manga @ongolaboy https://ongola.blogspot.com/ OpenPGP_signature Description: OpenPGP digital signature
Re: [FRnOG] [TECH] Quel est le DNS utilisé par un mobile selon l'OS et l'ISP ?
Bonsoir, On 28/06/2023 18:28, Laurent Barme wrote: [...] Avec un peu de chance, ce site pourrait répondre à ta question : https://www.dnsleaktest.com/ Une autre plateforme (plus outillée) et qui fonctionne aussi bien en IPv4 qu'IPv6 : https://bgp.tools/ En ouvrant la page et après quelques secondes, la première colonne fournit des informations sur ton 'origine': IP, AS,résolveurs successifs,... [...] Je me demande bien pourquoi ce serveur (57.37.84.182) intercepterait mes requêtes DNS et comment il font pour savoir ça ? Je ne pense pas qu'il "intercepte" mais plutôt qu'il reçoit tes requêtes depuis un résolveur plus proche de toi. Ce dernier a certainement dans sa configuration 'déléguer' la résolution à d'autres résolveurs dont celui que tu mentionnes. Et ça peut continuer ainsi suivant comment sont configurés les résolveurs sur le chemin. Bien évidemment si ton résolveur ne délègue pas, il fera lui même tout le processus de recherche (depuis les serveurs racines). Celles ou ceux qui ont des résolveurs ainsi configurés ne verront pas d'autres serveurs apparaîtrent lors du test en utilisant une des plateformes citées plus haut. -- Willy Manga @ongolaboy https://ongola.blogspot.com/ OpenPGP_signature Description: OpenPGP digital signature
Re: [FRnOG] [TECH] Equinix Remote Access
On 03/05/2023 13:10, Nicolas Parpandet wrote: à l'heure des ILO, Idrac, IPMI, Intel vPro, de la Virtualisation ..., ça te sert encore ? Je suppose que la bête est plus vieille que tout ça :) -- Willy Manga @ongolaboy https://ongola.blogspot.com/ OpenPGP_signature Description: OpenPGP digital signature
Re: [FRnOG] [MISC] 240/4 strikes back
. On 12/02/2024 14:54, Jérôme Marteaux wrote: Le 12/02/2024 à 11:12, Pierre Colombier via frnog a écrit : [...] Et c'est sans doute là la faiblesse d'ipv6, ça n'apporte quasiment rien de ce qu'ipv4 sait faire. Ca dépend de ce qu'on fait et où on se place.. Juste un au hasard. Absolument tout dans mon réseau peut être adressé de manière unique depuis le même bloc parent avec toutes les nuances que je veux dans le sous-bloc approprié. -- Willy Manga @ongolaboy https://ongola.blogspot.com/ OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [FRnOG] Re: [MISC] [Infosec] Incident de sécurité Orange Spain
. On 06/01/2024 00:40, Jérôme Marteaux wrote: [...] C'est beaucoup moins souple qu'Internet, mais ça ajoute une couche de sécurité (ça n'empêche pas ceux qui mettent en place du NAT/reverse proxy pour y simplifier l'accès). L'obscurantisme n'est pas idéal non plus, mais pour quelque chose d'aussi sensible que les objets routes et l'utilisation qui en est faite, de cacher ça derrière un VPN serait un moindre mal. La sécurité dépendra toujours du maillon le plus faible qui est généralement l'utilisateur des systèmes. A mon humble avis, l'éducation et la sensibilisation des utilisateurs est à toujours considérer sérieusement. Après bien sur on diversifie les voies et moyens pour sécuriser les données et le moyen de transport et réagir face aux incidents. Le VPN strictement parlant n'est pas ce qui apporte de la sécurité. -- Willy Manga @ongolaboy https://ongola.blogspot.com/ OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [FRnOG] [MISC] dgfip refusé par gmail
. On 29/02/2024 14:49, David Ponzone wrote: D’ailleurs, y a des domaines qui ont de l’IPv6 dans le SPF ? J’en trouve pas. Au hasard .. Tous les RIR :) Et puis comme l'a dit Stéphane B. dans un autre courriel, d'autres (comme moi) optent pour une déclaration 'implicite' . Personnellement je trouve que ça évite de dupliquer des informations si tous les MX de son domaine sont tous bien connus. -- Willy Manga --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [MISC] IPv6 en entreprise derrière 2 upstreams (was Re: 240/4 strikes back)
Hi On 12/02/2024 21:35, Maximus . wrote: Hello, Dans notre cas, y’a 1 gros problème pour passer en IPv6 Sur le site on a 2 opérateurs, chacun donne 1 /48. Comment je fait pour adresser ? Fondamentalement, le problème ici n'est pas tant IPv6. L'idéal serait d'avoir son ou ses propres blocs d'adresses (IPv4 et IPv6) En IPv4, je laisse d'autres personnes mieux expérimentées indiquer comment obtenir un bloc dans votre région. En IPv6 ca serait se voir assigner un "IPv6 PI". La procédure est ici https://www.ripe.net/manage-ips-and-asns/ipv6/request-ipv6/how-to-request-an-ipv6-pi-assignment/ Dans tous les cas, une fois le(s) bloc(s) assigné(s), Si vous faites du BGP, il faudra bien évidemment l'annoncer à tous vos upstreams. Si vous ne faites pas de BGP, vous pourrez demander à vos upstreams d'annoncer vos préfixes pour vous. Ce qui compte dans les deux contextes, c'est d'avoir des objets 'route' et des ROA qui correspondent à ce qui doit être annoncé En IPv4, suivant l’accès internet utilisé, ça sera naté par l’IP de l’interface utilisé pour soritr. Une passerelle dans tous les cas a des interfaces vers les upstreams et vers les réseaux locaux. Je ne vois rien de sorcier ici. Il n y 'aurait juste pas besoin de faire du NAT si vous vous disposez de votre propre préfixe; il faudra juste router en fonction du réseau de destination. Mais en IPv6, si j’adresse avec le /48 de l’opérateur 1, comment je fais pour sortir par l’opérateur 2 ? Du nat ? Si les ressources dans le réseau doivent utiliser indifféremment n'importe quelle liaison, à mon humble avis, il vaut mieux avoir ses propres préfixes. Dans ce scénario, votre passerelle pourra faire du load-balancing. Même en IPv6 ça fonctionne, les solutions existent. Oh le nat évoqué en IPv6, de l’urticaire se déclenche chez certains ;) Dans le pire des cas, vous pouvez même faire du NAT1:1 en IPv6. C'est une IP pour une autre IP et non une IP pour 10,20,50 autres derrière. -- Willy Manga --- Liste de diffusion du FRnOG http://www.frnog.org/
