Re: [FRnOG] [JOBS] [ASAP] Jeune admin cherche un bon DSI
Allez, ma petite contribution au troll... http://media.steampowered.com/apps/valve/Valve_NewEmployeeHandbook.pdf Le 26/06/2015 12:30, Arnaud Mombrial a écrit : Bé oui, pasque la dictature économique Européenne, c'est tellement plus seyant... Désolé, @Julien, j'ai pas pu m'empêcher, à réponse à deux balles, réponse à deux balles... Désolé également @v...@elynxit.fr dont la belle tentative de sortie du lot, va immanquablement finir en Trolldi. Le 26 juin 2015 12:16, Julien Schafer j.scha...@actilogie.com a écrit : Hum, en même temps le Venezuela comment dire... c'est ptet pas le meilleur pays pour prendre un exemple. -Message d'origine- De : frnog-requ...@frnog.org [mailto:frnog-requ...@frnog.org] De la part de Laurent Envoyé : vendredi 26 juin 2015 12:02 À : frnog@frnog.org Objet : Re: [FRnOG] [JOBS] [ASAP] Jeune admin cherche un bon DSI Le 26/06/2015 11:30, David Ponzone a écrit : Les employés qui recrutent leur manager, c'est peut-être ça la solution. *1200 salariés, pas de patron et aucune hiérarchie..* http://www.bastamag.net/Au-Venezuela-la-cooperative-Cecosesola-compte-1200-travailleurs-et-pas-un-chef --- Liste de diffusion du FRnOG http://www.frnog.org/ __ Information provenant d'ESET NOD32 Antivirus, version de la base des signatures de virus 11847 (20150626) __ Le message a été vérifié par ESET NOD32 Antivirus. http://www.eset.com --- Liste de diffusion du FRnOG http://www.frnog.org/ smime.p7s Description: Signature cryptographique S/MIME
[FRnOG] [TECH] RFC 7586: Scaling the Address Resolution Protocol for Large Data Centers (SARP)
http://www.bortzmeyer.org/7586.html Auteur(s) du RFC: Youval Nachum (Ixia), Linda Dunbar (Huawei), Ilan Yerushalmi, Tal Mizrahi (Marvell) Le problème de passage à l'échelle de protocoles de recherche d'adresse MAC des voisins, les protocoles comme ARP, sont connus depuis un certain temps, et documentés dans le RFC 6820. Résumé en deux mots, dans un grand centre de données non partitionné en sous-réseaux IP, le trafic ARP peut représenter une partie significative du travail à effectuer par les machines. Ce nouveau RFC expose une des solutions pour faire face à ce problème : SARP (Scaling the Address Resolution Protocol) fait appel à des relais ARP qui peuvent générer localement la plupart des réponses. Si le centre de données est rigoureusement découpé en sous-résaux IP (par exemple un sous-réseau, et donc un routeur par baie), il n'y a pas de problème ARP : le trafic ARP reste local. Mais si on veut profiter de la souplesse que permet la virtualisation, par exemple en déplaçat des machines virtuelles d'un bout à l'autre du centre de données en gardant leur adresse IP, on doit alors propager les requêtes ARP sur une bien plus grande distance et les problèmes de passage à l'échelle apparaissent (RFC 6820). La mémoire consommée par la FDB (Filtering Data Base, la table des adresses MAC connues) augmente, ainsi que le temps de traitement de tous ces paquets ARP diffusés. Les premières versions des brouillons ayant mené à ce RFC ne mentionnaient qu'ARP (RFC 826), protocole de résolution IP-MAC pour IPv4. Mais la version finale considère que le protocole marche aussi bien pour ND (RFC 4861), son équivalent pour IPv6. Seul le nom de la solution garde trace de cette préférence pour ARP. Dans le reste de cet article, je parlerais de ARP/ND. L'idée de base de SARP est que chaque domaine d'accès (un groupe de machines proches, par exemple dans la même baie ou dans la même rangée) ait un relais (SARP proxy) qui connaisse les adresses MAC de tout le domaine, et réponde aux requêtes ARP/ND pour les autres domaines avec sa propre adresse MAC. Ainsi, la taille de la table ARP des machines du domaine reste proportionnelle à la taille du domaine d'accès, pas au nombre total de machines (comme ce serait le cas avec un réseau « plat » classique, entièrement en couche 2, et sans SARP). Le relais SARP peut être l'hyperviseur d'un groupe de machines virtuelles (commutateur virtuel) ou bien il peut être dans un commutateur physique, ToR (Top of Rack) ou bien EoR (End of Row). En gros, le relais SARP est là où un domaine d'accès se connecte au cœur du réseau interne du centre de données. Ce doit être une grosse machine car elle va devoir stocker les adresses MAC de toutes les machines qui communiquent avec une machine d'un autre domaine d'accès. Et il peut aussi faire l'objet d'attaques délibérées (cf. section 4). La section 3 de notre RFC décrit plus en détail le fonctionnement de SARP. Si la machine source et la destination sont dans le même domaine d'accès (même baie, ou même rangée, selon l'endroit où se trouve le commutateur), ARP/ND fonctionne comme d'habitude et SARP n'intervient pas. Si la machine de destination est dans un autre sous-réseau IP, on passe alors par le routeur, selon le mécanisme normal de la couche 3. Mais si la destination est dans le même sous-réseau IP, mais dans un domaine d'accès différent ? Le relais SARP voit alors passer la requête ARP/ND. Si la réponse est dans son cache (qui associe des adresses IP à des adresses MAC), il répond avec sa propre adresse MAC (ainsi, les machines du domaine d'accès local ne sont pas noyées par des milliers d'adresses MAC de tout le centre de données). Sinon, il transmet à tous les domaines d'accès qui peuvent avoir cette adresse IP puis relaie la réponse. Seuls les relais SARP ont un cache qui contient des adresses MAC de tout le centre de données. Les machines ordinaires n'ont que les adresses MAC de leur propre domaine d'accès. Et pour transmettre un paquet de données ? La machine source, ayant reçu l'adresse MAC du relais SARP en réponse à sa requête ARP/ND va donc mettre sur le câble un paquet ayant pour adresse Ethernet de destination le relais SARP. Le relais SARP, utilisant son propre cache (qui, lui, est complet), remplace l'adresse MAC de destination par la « vraie », et l'adresse MAC source par la sienne (pour qu'une réponse puisse revenir), et remet le paquet sur le câble. Un tel mécanisme fait que des opérations comme la migration d'une VM d'un bout à l'autre du centre de données sont complètement invisibles. Les mécanismes normaux de résolution feront tout le travail. Cela suppose toutefois que la machine qui se déplace (ou plutôt son hyperviseur qui, contrairement à la VM, est conscient du déplacement) émette tout de suite un paquet ARP gratuit ou un paquet ND non sollicité, pour que les caches soient mis à jour
Re: [FRnOG] Re: Re: [MISC] Une documentation Ubuntu recommande d'utiliser des adresses déjà allouées
Je rejoins la team papy et me permets de venir mettre mon grain de sel... sur la pointe des pieds, car je me suis retenu d'écrire jusque-là, mais il y a des choses qui me gratouillent un peu. Je voudrais juste comprendre. Car je ne comprends rien à cet attachement touchant et, je j'en doute pas, intellectuellement reposant, mais objectivement pas très rationnel, pour papy v4. On Sun, Jun 28, 2015 at 10:58:27PM +0200, Pierre Lagoutte wrote: Mais non, mais non, ce n'est pas un pb d'apprentissage, mais de la bonne adaptation de v6 aux problèmes rencontrés en pratique (immaturité). On est plusieurs vieux cons ici, qui n'en sont pas à un nouveau protocole près. mais on pouvait légitiment espérer que v6 constituerait un progrès (notamment en simplicité d'usage), en gagnant en maturité (15 ans quand même...) Sur la simplicité, il suffit de jouer un tantinet à l'autohébergement : on voit tout de suite la différence entre 1 IPv4 sévèrement NATté en entrée et un /56 ou /64 IPv6. Beaucoup moins de galères en configuration HTTP ou firewall, en logs, etc. et pas un emm... supplémentaire en mal d'outillage approprié: que nenni, rien n'existe, On peut préciser de quel outillage on parle ? Les outils basiques classiques ont été portés à v6. Bon, je ne sais pas si certaines vieilleries propriétaires hors de prix ont été adaptées (coucou OpenView). Les éditeurs ont peut être l'œil rivé sur leur bilan comptable, tough (vive le libre). Et les présupposés du design de v6 ayant été très pauvres à l'époque (ce n'est pas forcément ici le lieu pour en discuter), ses implémentations et son écosystème s'avèrent malheureusement à la hauteur du désastre. Là encore, on peut préciser plutôt que de la jouer FUD ? Quand tout fonctionne au mieux: tout va bien, mais dépanner facilement c'est (et ça restera) autre chose. Je redoute la dissémination des déploiements, l'opacité et les difficultés de communication/échange technique autour de v6 (moins de personnes réellement qualifiées). Il y a moins de personnes qualifiées, donc il faut absolument éviter d'en augmenter le nombre ? Là non plus je ne pige pas le raisonnement. ... et je supporte les conseils visant à les limiter (en l'état) à la périphérie du réseau: il vaudrait mieux que v6 reste un protocole interne aux telcos. Là aussi... ça veut dire quoi techniquement concrètement ? IPv6 étant prioritairement fait pour délivrer massivement de l'espace adressage aux utilisateurs finaux, je ne vois vraiment pas le sens de le limiter aux telcos. C'est plutôt l'inverse qui est logique, et sans surprise c'est ce qui existe en déploiement (coucou le 6rd Free ou le L2TP SFR). Bon -- je comprends que ça fasse mal aux fesses des telcos à l'ancienne d'ouvrir l'abondance (truc dont ils ont horreur) sur un truc qu'ils monétisent chèrement (l'IPv4 publique et en particulier fixe). C'est le seul argument concret réel et business derrière le refus d'IPv6, mais forcément c'est plus difficile à vendre au client... -- Pierre Beyssac p...@fasterix.frmug.org --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Une documentation Ubuntu recommande d'utiliser des adresses déjà allouées
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 25/06/2015 10:09, Stephane Bortzmeyer a écrit : A décharge de l'auteur, ce genre de restriction codée en dur dans le code est complètement stupide. A charge de l'auteur, les plages non-annoncées pourraient être un jour réaffectées et réutilisées, comme ça avait été le cas avec les adresses en 5.x.x.x récupérées par OVH et usurpées par le logiciel de VPN Hamachi. (rappelez vous le gros bordel que c'était). Tant qu'on peut se conformer à la sacro-sainte RFC1918, on s'y conforme. Je connais quelques grosses boites qui sont en rade d'adresses privées, mais elles se comptent sur les doigts d'une main. Quand à IPv6, il arrive par la grande ou la petite porte mais il est inévitable. On rediscutera de pénurie quand on aura plus assez d'adresses IPv6 pour déployer Internet sur Pluton. Solarus. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJVkGh9AAoJEL4mZMECwpc0APMP/jY6+k/RI5kZ0U49Qx/qpEIP v4/hs/i2xpu4aC1diwsEWafwK5qcYb+VzWYWfFTvyvIGSciEavnmxpnPlEZRdla4 3LSxTQxIhf9HNtitEDxkuMtw/xpKHIhVbr4vmtD+wAy25t0ZrEryB+2hJlRVrCbm ucnAb40D14d4O5WHLIY9tjr79rDMAXCi0xpDSvGHPKCCHJJ2j9Sj44SyjdD5YXrd Ej8YHI4w1e97C9vRrG7ECZOAjPcN4kVn+q65GasKwS9ldl0As+/6xZnUkC5I/ES3 mFEtrcbZGlDPP7NkP82tuav71Fr/UnbS30u4a0m1AZldkOIVJJs55AXTBIC193n4 rRfGv/epVJUVbQ+IO5zBWrUDOwU1AUg/RyLCus4Ls+zF0/UhZ4l8W79UC/Odi2qt eTkHyF7PxKGFsvI8eDouaJOSWj3w0n3lVsZUPdA3NKgguj+3zI9l9TBWlgloBrPl 4liYyd/7WuLhgaHyNqNxRHCbxIBRsWz9Kpog69Dt27UvyJcJqGp+M7e68/8AbEUQ gOgUjikIugJHHFxAsLe9Wpmbt+zJ46P9r/kl+oFCIhIlFF4nvi/z6/BS+f1rc5QD SFU84FkoJTa9reFUTx/88RyRBne8kag3L+mUO+X6O+2+GdyzuUJ9Il3wqygMpp+6 t9mJiy2tpt1AkUKalLzV =P7Rd -END PGP SIGNATURE- --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Une documentation Ubuntu recommande d'utiliser des adresses déjà allouées
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 25/06/2015 10:09, Stephane Bortzmeyer a écrit : The Future Use range (240.0.0.0/8 through 255.0.0.0/8) is a particularly good set of IP addresses you might use, because most routers won't route it; however, some OSes, such as Windows, won't use it. A décharge de l'auteur, ce genre de restriction codée en dur dans le code est complètement stupide. A charge de l'auteur, les plages non-annoncées pourraient être un jour réaffectées et réutilisées, comme ça avait été le cas avec les adresses en 5.x.x.x récupérées par OVH et usurpées par le logiciel de VPN Hamachi. (rappelez vous le gros bordel que c'était). Tant qu'on peut se conformer à la sacro-sainte RFC1918, on s'y conforme. Je connais quelques grosses boites qui sont en rade d'adresses privées, mais elles se comptent sur les doigts d'une main. Quand à IPv6, il arrive par la grande ou la petite porte mais il est inévitable. On rediscutera de pénurie quand on aura plus assez d'adresses IPv6 pour déployer Internet sur Pluton. Solarus. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJVkGiBAAoJEL4mZMECwpc0UEwQAKj6Vu+O+NSzsq+n5OPurINh coxqHs7vQzJUxDHHJWSG5r/j/TYRQhDfqKOoh190M7xlIwC/M3qKHyXdisZEiLOU 0/u4ibX+vCzufrESpd7AttCBNMzmEntDwqD/8GeDZ9pGyQQSTxQV51XoLCaSy6zB NlPQ1HiBrScn6QtZlaXcwvurY82hTl682PW1OWAFV6BU9Kh275rcxA/sBMUbAPKs l9bsxIkgRyxj2GNL/3YUJn5KWQlIFvXJwcpu4rOCL9JZP30CYi+EEP2XBhrhKvUP 2HPAC4ZeNml8mGHSjsP3OQ5JkJ+eYOqiyXmWA8k9eGZLLIYahU3+6ERc6Ibxyagg JmnZOcw8aPwYWEhV8cQY6UUnE9IHM+1cwkQrARtkRz8XrQOi8Xld/XZ+sKoFyXks c72xXQKZgVSS8bnIQQ9B7G7+j61EW+HQU/FN5nDfftZiMOy6QxkzmQ8IpMSQ9FWG SOGJb3JNCmZ/zXpPtPE9wfWeLpyL0+5ux0g8Z+o6iEuLeEunGc6pnfYcpkznpNJI RiXVKS7pX/umbHRARWH32XR+Hn7Vy80Vzr0aLNHC/wJeeztSAjwC9N2+BKRamjVm OpsRSLDInrAt15VWtBWiNRzXeDTz005wD0W79ijH8eff5EWokgCxUWIXmTpe6wI9 gESK4beAlKC0eZL4YN7b =raxk -END PGP SIGNATURE- --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: Re: [MISC] Une documentation Ubuntu recommande d'utiliser des adresses déjà allouées
On Sat, Jun 27, 2015 at 06:34:10AM +0200, Pierre Lagoutte pie...@dratech.com wrote a message of 56 lines which said: C'est vrai: dual stack = deux fois plus de pb Alors, là, je vais faire mon vieux con, et virer Michel Py qui joue très mal ce rôle. Quand j'étais ingénieur réseaux (un vrai, pas un qui fait des PowerPoint aux réunions FRnog), sur le campus, on avait QUATRE protocoles différents. IPX, IPv4, Decnet (phase IV), AppleTalk. Et c'était avant qu'arrive Decnet phase V, totalement incompatible avec phase IV. Et on trouvait ça normal, et on plaignait nos collègues d'autres réseaux qui devaient se taper de l'IBM en prime. Et je me souviens d'une présentation par un commercial d'une boîte US peu connue qui nous présentait fièrement leur produit, un « routeur multi-protocoles ». (On avait avant un routeur par protocole.) Les jeunes d'aujourd'hui sont des bras cassés, ils paniquent à l'idée de gérer DEUX protocoles très proches. -- Team Papy --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: Re: [MISC] Une documentation Ubuntu recommande d'utiliser des adresses déjà allouées
Mais non, mais non, ce n'est pas un pb d'apprentissage, mais de la bonne adaptation de v6 aux problèmes rencontrés en pratique (immaturité). On est plusieurs vieux cons ici, qui n'en sont pas à un nouveau protocole près. mais on pouvait légitiment espérer que v6 constituerait un progrès (notamment en simplicité d'usage), en gagnant en maturité (15 ans quand même...) et pas un emm... supplémentaire en mal d'outillage approprié: que nenni, rien n'existe, Et les présupposés du design de v6 ayant été très pauvres à l'époque (ce n'est pas forcément ici le lieu pour en discuter), ses implémentations et son écosystème s'avèrent malheureusement à la hauteur du désastre. Quand tout fonctionne au mieux: tout va bien, mais dépanner facilement c'est (et ça restera) autre chose. Je redoute la dissémination des déploiements, l'opacité et les difficultés de communication/échange technique autour de v6 (moins de personnes réellement qualifiées). ... et je supporte les conseils visant à les limiter (en l'état) à la périphérie du réseau: il vaudrait mieux que v6 reste un protocole interne aux telcos. Pierre = Le 28/06/2015 22:18, Stephane Bortzmeyer a écrit : On Sat, Jun 27, 2015 at 06:34:10AM +0200, Pierre Lagoutte pie...@dratech.com wrote a message of 56 lines which said: C'est vrai: dual stack = deux fois plus de pb Alors, là, je vais faire mon vieux con, et virer Michel Py qui joue très mal ce rôle. Quand j'étais ingénieur réseaux (un vrai, pas un qui fait des PowerPoint aux réunions FRnog), sur le campus, on avait QUATRE protocoles différents. IPX, IPv4, Decnet (phase IV), AppleTalk. Et c'était avant qu'arrive Decnet phase V, totalement incompatible avec phase IV. Et on trouvait ça normal, et on plaignait nos collègues d'autres réseaux qui devaient se taper de l'IBM en prime. Et je me souviens d'une présentation par un commercial d'une boîte US peu connue qui nous présentait fièrement leur produit, un « routeur multi-protocoles ». (On avait avant un routeur par protocole.) Les jeunes d'aujourd'hui sont des bras cassés, ils paniquent à l'idée de gérer DEUX protocoles très proches. -- Team Papy --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [TECH] Help : Pb de DNS entre ORANGE-clients livebox-adsl et certains noms de domaine gérés par 1and1
Bonjour, Je cherche a bonne piste pour avancer sur ce qui suit. voir les traceroute en fin du mail, si cela aide à diagnostiquer Explication du contexte : depuis jeudi 25/6 les abonnés du FAI Orange ne peuvent plus accéder à une partie des sites web 1and1 en hébergement mutualisés, dont les ndd sont gérés par les dns 1and1. les dns forcés dans les livebox (non modifiables pour cause tv, télephone, sécurité) ne voient pas les ndd concernés (tests avec des nslookup, server ...) - pour mon cas : ne voient pas certains chez 1and1 depuis 2010 mais voient un autre ouvert en 2014 - cas abondamment cité sur le site communautaire d'entraide d'Orange depuis jeudi. Ces ndd sont connus des dns des autres FAI (grand public ou professionnels). Apparemment ils sont connus des ns préconisés par Orange pour les non livebox. MAIS PAS CONNUS des ns de Orange Livebox (server 80.10.246.136 ou 81.253.149.6 dsn-rtc-grp1-b.wanadoo.fr) qui ne font pas autorité, et se semblent pas s'actualiser. Quelqu'un aurait une piste ? ou la suggestion d'une autre liste ? coté 11 il est indiqué que le pb est repéré, que c'est à Orange de regarder ses dns ; Nous (clients grand public Orange) n'avons pas accès à un niveau suffisant du SAV Orange pour manifester le pb (la hot line suggère par exemple à certains de changer de PC et tout à l'avenant). Pour certains clients 11 hebergement, c'est critique : par exemple un gite rural qui ne reçoit plus de mails/commandes via son site de la part des clients Orange, qui ne le voient plus - la saison estivale commence mal ! --- une de mes contributions sur communaute.orange.fr (http://communaute.orange.fr/t5/ma-connexion/Probl%C3%A8me-DNS-Orange-Certains-domaines-inaccessibles/m-p/591160/highlight/false#M59858) _ En faisant des tests avec les autres dns d'Orange: http://assistance.orange.fr/les-adresses-dns-791.php (les DNS préconisés pour ceux qui n'ont pas de livebox) cmd nslookup server 80.10.246.2 (ou 80.10.246.129 dns-abo-static-a et -b.wanadoo.fr = les dns HORS LIVEBOX) monndd.fr - TROUVE server 80.10.246.136 (ou 81.253.149.6 dsn-rtc-grp1-b.wanadoo.fr = les DNS forcé dans la LIVEBOX) monndd.fr - PAS TROUVE; il y a bien un pb sur les DNS Orange propagés par le DHCP dans les LIVEBOX clients Alors que d'autres DNS Orange/wanadoo sont à jour - la synchro de certains DNS Orange fonctionne donc ; le pb est circonscrit à ceux qui sont forcés dans les LB - le ns faisant autorité pour l'un des ndd non trouvé via Orange LBox : ns-fr.1and1-dns.fr (217.160.80.4) voici les traceroute depuis Orange LB, puis depuis un lien SFR Connect du bureau _ Détermination de l'itinéraire vers ns-fr.1and1-dns.fr [217.160.80.4] avec un maximum de 30 sauts : 1 2 ms 1 ms 1 ms livebox.home [192.168.1.1] 220 ms19 ms19 ms 80.10.123.34 318 ms18 ms18 ms 10.125.90.74 419 ms19 ms19 ms ae44-0.niaub102.Aubervilliers.francetelecom.net [193.252.159.46] 531 ms31 ms31 ms 81.253.184.122 634 ms31 ms31 ms tengige0-6-0-34.lontr4.London.opentransit.net [193.251.242.81] 732 ms30 ms29 ms telia.GW.opentransit.net [193.251.248.70] 829 ms33 ms29 ms ldn-bb3-link.telia.net [213.155.136.74] 934 ms32 ms31 ms prs-bb3-link.telia.net [62.115.134.104] 1090 ms58 ms59 ms ffm-bb1-link.telia.net [62.115.143.88] 1158 ms58 ms59 ms ffm-b1-link.telia.net [62.115.141.221] 1256 ms49 ms50 ms 1o1internet-ic-309319-ffm-b1.c.telia.net [213.248.97.98] 13 *** Délai d'attente de la demande dépassé. 14 *** Délai d'attente de la demande dépassé. ... 18 *** Délai d'attente de la demande dépassé. Le même à partir d'une VM au bureau sur laquelle je viens de me connecter (lien fibre SFR CONNECT) C:\tracert NS-FR.1AND1-DNS.FR Détermination de l'itinéraire vers NS-FR.1AND1-DNS.FR [217.160.80.4] avec un maximum de 30 sauts : 11 ms1 ms1 ms 172.26.15.254 2 1 ms1 ms1 ms 161.145.62.62.rev.sfr.net [62.62.145.161] 31 ms1 ms1 ms 9.24.79.86.rev.sfr.net [86.79.24.9] 4 4 ms 2 ms 3 ms 10.122.3.109.rev.sfr.net [109.3.122.10] 5 1 ms 3 ms 1 ms 10.122.3.109.rev.sfr.net [109.3.122.10] 611 ms11 ms11 ms decix.bb-a.fra3.fra.de.oneandone.net [80.81.192.123] 711 ms11 ms10 ms ns-fr.1and1-dns.fr [217.160.80.4] Itinéraire déterminé. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Une documentation Ubuntu recommande d'utiliser des adresses déjà allouées
Le 2015-06-25 10:09, Stephane Bortzmeyer a écrit : The Future Use range (240.0.0.0/8 through 255.0.0.0/8) is a particularly good set of IP addresses you might use, because most routers won't route it; however, some OSes, such as Windows, won't use it. A décharge de l'auteur, ce genre de restriction codée en dur dans le code est complètement stupide. A charge de l'auteur, les plages non-annoncées pourraient être un jour réaffectées et réutilisées, comme ça avait été le cas avec les adresses en 5.x.x.x récupérées par OVH et usurpées par le logiciel de VPN Hamachi. (rappelez vous le gros bordel que c'était). Tant qu'on peut se conformer à la sacro-sainte RFC1918, on s'y conforme. Je connais quelques grosses boites qui sont en rade d'adresses privées, mais elles se comptent sur les doigts d'une main. Quand à IPv6, il arrive par la grande ou la petite porte mais il est inévitable. On rediscutera de pénurie quand on aura plus assez d'adresses IPv6 pour déployer Internet sur Pluton. Solarus. A décharge de l'auteur, ce genre de restriction codée en dur dans le code est complètement stupide. A charge de l'auteur, les plages non-annoncées pourraient être un jour réaffectées et réutilisées, comme ça avait été le cas avec les adresses en 5.x.x.x récupérées par OVH et usurpées par le logiciel de VPN Hamachi. (rappelez vous le gros bordel que c'était). Tant qu'on peut se conformer à la sacro-sainte RFC1918, on s'y conforme. Je connais quelques grosses boites qui sont en rade d'adresses privées, mais elles se comptent sur les doigts d'une main. Quand à IPv6, il arrive par la grande ou la petite porte mais il est inévitable. On rediscutera de pénurie quand on aura plus assez d'adresses IPv6 pour déployer Internet sur Pluton. Solarus. --- Liste de diffusion du FRnOG http://www.frnog.org/
