Un journal parlait très récemment d'adresses privées apparaissant sur un traceroute. Les cas sont en effet tellement légions qu'on ne s'en émeut plus trop.
Mais les développeurs du noyau pensent à nous, pour occuper les longues soirées d'hiver. Il va désormais être possible de router 127.0.0.0/8. On va pouvoir voir des requêtes ARP pour (et en provenance) de 127.10.11.12, et tout ce qui va avec.
Admirez également la justification du commit. « C'est pas vraiment interdit, et on manque tellement d'adresses IP ». Franchement le ping de plus de 10ms en direction de ce réseau particulier, ça me manquait depuis que mon ordinateur n'est jamais réellement chargé.
# Un peu de calcul
Posté par calandoa . Évalué à 7.
Enfin bon, on a vraiment besoin de 16580608 adresses (si je ne m'abuse) pour désigner le _localhost_ ?
[^] # Re: Un peu de calcul
Posté par Florent Fourcot . Évalué à 9. Dernière modification le 02 octobre 2012 à 15:05.
Si tu trouves que c'est trop, tu peux passer en IPv6, une seule adresse est réservée (pour une fois qu'on a moins d'adresse en v6 qu'en v4…).
À vrai dire, la pertinence de réserver tout un /8 est probablement à discuter. Mais ça, c'était il y a longtemps qu'il fallait y réfléchir (et d'autres l'ont fait, cf IPv6). Ce dont je suis à peu près certain, c'est qu'il est une très mauvaise idée de s'affranchir des règles des RFC et de commencer à faire n'importe quoi avec ce sous-réseau réservé. Surtout vu le nombre d'adresses IP privées déjà prévues à cet effet.
[^] # Re: Un peu de calcul
Posté par William Steve Applegate (site web personnel) . Évalué à 1.
Pour l'adresse de bouclage, c'est exact, mais sinon, toute la plage 0::/8 est réservée :
Ce qui nous fait du coup la bagatelle de 1329227995784915872903807060280344576 adresses réservées. Au moins, l'IETF ne manquera pas de place pour ses expérimentations ;-)
Envoyé depuis mon PDP 11/70
[^] # Re: Un peu de calcul
Posté par CHP . Évalué à 3.
Dans les faits, y'a beaucoup de gens qui utilisent autre chose que 127.0.0.1 pour localhost ? Perso j'ai jamais vu autre chose que 127.0.0.1, je pensais meme que c'etait la seule ip reservée au localhost avant de lire ce journal
[^] # Re: Un peu de calcul
Posté par Kerro . Évalué à 2.
J'utilise une adresse de type 127.a.b.c pour chaque service visible uniquement en local. Par exemple le serveur DNS (alors que le cache est visible depuis l'extérieur). Cela dit je pourrais faire sans.
J'utilise également ça pour quelques hacks immondes (redirection ipfilter) afin que certains logiciels un peu cons soient correctement enfermés. Mais pareil, je pourrais faire sans.
[^] # Re: Un peu de calcul
Posté par Antoine . Évalué à 3.
Ça peut servir, par exemple si tu veux avoir plusieurs démons locaux écoutant sur le même port.
[^] # NTP
Posté par Arthur Accroc . Évalué à 3.
Vu dans le fichier de configuration de ntpd :
C’est commenté par défaut. Décommenté, ça permet à un serveur local de continuer de synchroniser ses clients sur son horloge quand il n’a pas accès à de vraies sources ntp.
Plus précisément, s’il n’a plus de source, ntpd n’indique plus le temps à ses clients.
Ça, ça définit une fausse source locale, basée sur l’horloge interne, avec une très basse priorité, qui fait qu’elle n’est pas prise en considération s’il y a une source sérieuse accessible.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
# Dangereux
Posté par inico (site web personnel) . Évalué à 3.
Il y a pas mal de zone DNS en blackhole 127.127.127.127 et assimilé.
Va y avoir de la casse …
# Boarf, parait logique.
Posté par Batchyx . Évalué à 6.
Vu comment le noyau fonctionne, je trouve que c'est une bonne chose. Ça permet de rendre 127/8 moins spécial, et il manquerai pas grand chose pour que ce comportement soit activé de base et qu'on puisse simplifier un peu le code, sans qu'il y ai de changement visibles par l'utilisateur qui verra toujours ses 127/8 droppés en entrée s'il n'a rien fait de spécial.
127/8 serait alors juste configuré par défaut comme une plage d'adresses de l'interface lo (donc réservée à l'hôte) et serait traité comme toutes les autres. Et si tu voulait router cette plage d'adresse quand même, il faudrait juste commencer par aller virer la route qui dit que ça appartient à l'interface lo (comme indiqué dans le patch).
# Avis personnel
Posté par galactikboulay . Évalué à -1.
Pour moi, ce patch c'est du gros n'importe quoi de gars qui n'a jamais fait de réseau de sa vie.
"On manque tellement d'adresses IP" -> de toute façon qu'est-ce que ça change ? ça ne sera jamais routé sur l'Internet public. Pour du local, il y a déjà 172.16.0.0/12, 192.168.0.0/16 et 10.0.0.0/8, je crois qu'il y a quand même de quoi faire!
S'il se sent concerné par un manque d'adresses IP, qu'il travaille au déploiement d'IPv6, ça sera certainement plus utile.
[^] # Re: Avis personnel
Posté par Frédéric Perrin (site web personnel) . Évalué à 3.
En 2005, des gens comme Comcast avaient déjà épuisé 10/8 pour leur propre tambouille (http://www.nanog.org/meetings/nanog37/presentations/alain-durand.pdf, page 5.
[^] # Re: Avis personnel
Posté par Frédéric Perrin (site web personnel) . Évalué à 2.
Et je ne retrouve pas le lien, mais je suis tombé il n'y a pas longtemps sur quelqu'un qui expliquait que certains réseaux utilisaient des IP publiques pour des réseaux qui ne sont pas connectés à Internet (ou pour lesquels il suffirait d'un proxy oueb pour les lusers) parce qu'il y a un besion d'accepter des VPN depuis d'autres réseaux ; mais si les deux bouts du VPN utilisent la même plage d'IP privées, ça va faire du caca…
Tout ça pour dire que non, 3 plages d'IP privées ce n'est pas suffisant.
[^] # Re: Avis personnel
Posté par galactikboulay . Évalué à 5.
Oui, et donc plutôt de continuer à faire de la tambouille moisie en IPv4, la conclusion de Comcast, c'est qu'il faut passer … à IPv6.
[^] # Re: Avis personnel
Posté par ckyl . Évalué à 5. Dernière modification le 02 octobre 2012 à 23:16.
Faut être sévèrement burné, ou avoir des problèmes mentaux, pour dire que Thomas Graf est un gars "qui n'a jamais fait de réseau de sa vie". Je te conseil vivement d'aller interroger l'historique de ta copie locale du repository git de Linux…
Et toi ?
[^] # Re: Avis personnel
Posté par galactikboulay . Évalué à -6.
Ah je note que pondre du code pour le noyau Linux fait automatiquement du développeur un expert réseau, c'est magique !
[^] # Re: Avis personnel
Posté par ckyl . Évalué à 6.
C'est juste l'un des top contributeur de la pile réseau de Linux et des outils associés depuis près de 10 ans, je suis sur qu'il serait intéressé si tu donnais des cours.
Avec un peu d'expérience dans le développement et en étant un peu moins imbus de soit même on peut imaginer de manière non exhaustive que:
- Il y a une raison architectural au changement (comme indiqué plus haut ça peut nettoyer en évitant des exceptions)
- Il y a des gens qui en ont le besoin et qui ont réussi à le convaincre (ou le payer). Ça n’entraîne aucune régression pour les autres donc pas de soucis.
- Il y a une bonne raison, sans qu'un client ait eu besoin de le demander
- Il a tord
Mais même si il avait tord sur ce coup, vouloir persister à dire que c'est une branque alors que toi t'es un gros cador du réseau qui a tout compris c'est un peu lamentable comme comportement. La version constructive, si on pense avoir quelque chose d'intéressant à dire sur le sujet, c'est d'aller discuter en public du sujet avec l'auteur. Par exemple si on regarde là: http://permalink.gmane.org/gmane.linux.network/233392 il y a un début de réponse sur la motivation du changement.
[^] # Re: Avis personnel
Posté par galactikboulay . Évalué à -8.
Tu sais utiliser autre chose que des arguments d'autorité (et traiter les autres de débiles mentaux accessoirement) ?
Encore une fois, parce que tu n'as toujours pas l'air d'avoir saisi le sens de ma remarque, ce n'est pas parce que c'est un très bon développeur que ça fait de lui un expert réseau, ce qui est un domaine assez différent.
Son patch risque d'inciter les gens à faire des choses sales. D'ailleurs il dit que c'est orienté "host internal", mais l'exemple qu'il donne, c'est de router un morceau de 127. vers eth0, et que ça ne le dérange pas que les gens utilisent ça pour leur adressage interne dans leur réseau…
Et pourtant la RFC recommande quand même fortement que ça ne se balade pas sur les liens.
[^] # Re: Avis personnel
Posté par ckyl . Évalué à 5.
Aucun argument d'autorité simplement commencer par se dire que les autres ne sont pas forcément plus cons que soi. Donc chercher à comprendre, et leur demander si on arrive pas à trouver la réponse. Après on peut exprimer son désaccord sur ce point, voir émettre des doutes sur les compétences de la personne en cas extrème. C'est vachement plus constructif et respectueux que d'arriver avec ses gros sabots.
Maintenant oui pour moi ça s'applique encore plus que le CV du mec est l'un des plus rempli de son domaine et qu'il ne sort pas de n'importe où. Ce qui n'empêche pas de faire des conneries hein.
[^] # Re: Avis personnel
Posté par barmic . Évalué à 4.
C'est probablement mieux que de traiter les gens d’incompétents sans donner d'arguments. Enfin j'dis ça j'dis rien.
Pour contre dire le travail de quelqu'un qui bosse depuis longtemps sur les problématique réseau dans le noyau linux il en faut un peu plus que quelqu'un qui affirme que 3 plages d'adresses privées suffisent. Par exemple il faudrait que tu commence à avoir un argument ça sera cool.
Les règles codées en dur c'est mal, quelque soit la RFC, la norme ISO où je ne sais quoi. Ce n'est pas parce que c'est un fonctionnement paramétrable que ça ignore les RFC. Tu pense qu'il faudrait que le noyau possède des règles en dure pour faire pointer example.com, example.net et example.org vers l'IANA parce que si on commence à requêter un serveur DNS pour ça on risque de ne plus suivre la RFC2606 ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Avis personnel
Posté par galactikboulay . Évalué à -1.
J'ai déjà répondu plus haut: si tu as épuisé les 3 plages d'adresses privées disponibles en IPv4, il va falloir sérieusement se pencher sur l'utilisation d'IPv6 pour répondre à ton besoin. C'est ce qu'a fait Comcast assez tôt, plutôt que de rajouter de la rustine. L'auteur du patch cite comme exemple "For example to address a pool of virtual guests behind a load balancer" => pourquoi ne pas les adresser directement en IPv6 ?
Quand Microsoft, Apple ou je ne sais qui ne suivent pas les RFC et introduisent des incompatibilités, les libristes poussent une gueulante, et à juste titre. Par contre là, c'est un développeur du noyau Linux donc ça devient acceptable ? J'aurais bien aimé voir les réactions si c'était MS qui avaient pondu ce truc tiens.
Après, ton exemple de example.{com,net,org} est juste ridicule (on passera sur le fait que ce n'est pas le noyau qui fait la résolution DNS), ces domaines étant affectés à l'IANA. L'IANA te garantit juste que tu peux les utiliser en test, et qu'elle ne les affectera pas à une autre entité. En pratique, ça marche comme n'importe quel autre domaine, donc il n'y a rien à coder en dur nulle part, que ce soit noyau ou résolveur DNS.
[^] # Re: Avis personnel
Posté par ckyl . Évalué à 2.
Hey choupinet le comportement par défaut n'a pas changé et personne ne te demande d'avoir un comportement qui dévie de ce que disent les RFC. Après de toute façon si tu veux cradouter tu cradoutes…
[^] # Re: Avis personnel
Posté par Batchyx . Évalué à 4.
Justement.
Toi tu pourra certainement lui faire des cours sur comment faire un réseau des grands pères, filaire 100 mbit avec 0.00000001%⁻de pertes entre des machines qui sont toujours branchées, allumées, joignables (en unicast et multicast) et présentes, qui ne bougent jamais et qui forment un réseau bien géré, bien préparé à l'avance, ou la norme est respectée scrupuleusement par les équipements et des administrateurs.
Sauf que lui il pourra t'apprendre ce qu'est un OS généraliste et pourquoi ce n'est pas la même chose qu'un OS pour desktop et serveurs. Et que c'est largement mieux quand Linux possède les fonctionnalités pour faire ou recréer ce que tu demande, plutôt que d'avoir une partie non-négligeable de tes utilisateurs qui appliquent des ribambelles de patch écrits par des gorets qui plantent dans tout les sens pour faire la même chose. Surtout quand ces utilisateurs font parti de ceux qui sont obligés de savoir coder pour faire ce qu'ils font.
Dans le cas ou tu est dans une machine virtuelle, eth0 pourrai être ta seule interface vers l'hôte. Nulle par il dit qu'il veut router 127/8 à travers un vrai lien…
Après, tu connais rien sur sa configuration. Si ça se trouve, son load balancer marche déjà en IPv6, mais il veut qu'il puisse aussi marcher indépendamment en v4 sans avoir à réserver des adresses sur le vrai réseau.
Et qu'est ce que tu veux qu'un développeur noyau fasse de plus pour déployer IPv6 quand tu à déjà une stack qui marche ?! Ça serait plutôt aux experts réseaux de ton genre de se bouger le cul. Ça et les développeurs d'applis en espace utilisateur.
[^] # Re: Avis personnel
Posté par galactikboulay . Évalué à 0.
Oui mais justement, le 127.0.0.0/8 n'est pas censé sortir de la machine (qu'elle soit virtuelle ou pas). D'ailleurs ce subnet a un rôle bien précis, c'est le loopback, rien d'autre. Est-ce que c'est stupide d'avoir réservé à l'origine un /8 pour ça ? A l'heure actuelle, oui, ça parait complètement saugrenu (évidemment à l'époque où ça a été décidé, personne ne pensait qu'IPv4 aurait un tel succès).
Justement, rien de plus, ils ont développé tout ce qu'il fallait, tout est là. En fait, ils ne devraient même pas se préoccuper de savoir si il y a encore des adresses dispo en v4 ou pas. Trouver des solutions à ce genre de problématique et pondre les normes, c'est le boulot de l'IETF et autres.
A part le fait que je ne prétends pas être un expert, le problème est à mon sens de moins en moins à ce niveau, mais plus sur le "contenu" accessible en v6. Il suffit de voir le nombre de "gros" sites qui sont toujours en v4… Il y aussi le souci des FAI et des hébergeurs qui sont encore loin de tous proposer une connectivité v6 par défaut.
[^] # Re: Avis personnel
Posté par Frédéric Perrin (site web personnel) . Évalué à 1.
Ce n'est pas aux développeurs de suivre les RFC, mais l'inverse. Une RFC pour un nouveau protocole ou technique ne peut pas passer au stade de brouillons (Draft Standard) si elle ne dispose pas d'au moins deux implémentations. C'est un peu comme dans le LL : tu expérimentes dans ton coin, tu implémentes d'abord, et ensuite tu publies ta RFC et tu demandes à tout le monde de la suivre.
[^] # Re: Avis personnel
Posté par galactikboulay . Évalué à 0.
Là on ne parle pas de réaliser des prototypes pour de nouveaux protocoles, mais bien de suivre quelquechose d'existant.
On est dans la phase "Tu demandes à tout le monde de la suivre".
[^] # Re: Avis personnel
Posté par Batchyx . Évalué à 4.
Cette phrase n'a aucun sens. Oui, 127/8 n'est pas censé sortir d'une machine. Mais dire que ça ne doit pas sortir d'une machine virtuelle n'a aucun sens. Une machine virtuelle n'est qu'un détail d'implémentation d'un hôte, ce n'est pas une "machine" à proprement parler, et L'IETF n'a jamais rien normalisé sur les machines virtuelles, parce que ce n'est pas du réseau.
D'ailleurs, le terme "machine virtuelle" est bien vague. On parle de quoi exactement ? d'émulation de matériel ? de virtualisation ? de para-virtualisation ? d'OS contenus ? de namespaces ?
Dans certains cas, il y a effectivement une machine virtuelle, dans un autre cas, ce n'est juste qu'un programme. Quelque soit la techno utilisé, le fait que l'invité communique avec l'hôte à travers un pseudo-réseau, une pseudo-carte graphique ou une API interne reste qu'un détail d'implémentation. L'IETF ne va voir qu'une application qui tourne sur un hôte. Et tant que l'hôte (la vraie machine) n'envoie pas de la merde en 127/8 au autres, elle n'a pas son mot à dire.
Le fait que dans bien des cas on utilise un réseau pour faire quelque chose qui n'est pas du réseau ne reste qu'un détail d'implémentation tant que ça reste à l'intérieur de l'application. Et si cette application peut communiquer avec une autre application, elle choisi le protocole qu'elle veut. Tant qu'elle ne dit pas que "le protocole entre les deux applications est un réseau IP IETF valide" et qu'elle ne sort pas sur un réseau IETF, elle peut utiliser du pseudo-IP en 127/8 si ça lui chante. Moi je préfère quand ça n'utilise pas un pseudo-réseau si ça n'est pas un réseau. Mais on le fait souvent par facilité.
Par contre, si tu veux effectivement relier tes "machines virtuelles" au réseau, alors c'est très différent : tu est en train de transformer ton hôte en routeur (ou switch, comme tu veux), qui route entre un vrai réseau et quelquechose qui n'est pas un réseau ("réseau virtuel" si tu veux, mais ça reste que ce n'est pas un réseau), mais que tu veux faire passer pour un réseau. Là, l'IETF à son mot à dire (et il l'a déjà fait, il me semble) et tu à du 127/8 qui sort de tes "nœuds virtuels", alors tu viole effectivement la norme et donc tu fait chier.
Après, choisir de relier tes fausses machines en réseau ou pas, ça reste ton choix. Et tu sera peut-être obligé de relier tes fausses machines en réseau si tu fait tourner des OS non-coopératifs avec l'hôte qui croiront vraiment qu'ils ont une vraie interface réseau. Mais faire tourner des OS qui ne coopèrent pas avec l'hôte, c'est plutôt rare.
Mais de toute façon, un bon noyau généraliste comme Linux doit pouvoir gérer les deux cas. Et il le fait. Et si tu t'amuse à mal paramétrer ton noyau généraliste et qu'il envoie de la merde sur ton réseau, c'est ton problème. Si tu n'a pas envie que ça arrive, ne prend pas un noyau généraliste.
[^] # Re: Avis personnel
Posté par Spack . Évalué à 7.
Attention, le réseau 127.0.0.0/8 n'est pas destiné à sortir de la machine. Il serait de toute façon rejeté par tout autre équipement. L'auteur du patch explique bien qu'il s'agit d'utiliser ce réseau pour la cuisine interne du système.
Si ce n'est pas super propre car habitués autrement, ce n'est pas plus stupide tant que ça reste dans le système.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.