IPv6 et ses mystères ! Ses RFC nombreuses et compliquées ! Ses mises en place de façon acrobatique pour cause de diçaïdeur pressay (« C’est dans le vent, on en parle, il faut qu’on y soit pour hier »), ou, au contraire, trop lentes (« C’est bon on a le temps, de toute façon, c’est compliqué, on n’y connaît rien et ça ne sert à rien »).
Tout ça et bien d’autres choses encore vous attendent dans le Lothaire YARDING (Yet Another Reference for Delivering IPv6 to the Next Generation).
Il s’agit d’un état de l’art sur l’IPv6 très récent (été 2012), avec des exemples d’expérimentations des différentes technologies environnantes. Ce contenu s’adresse à la fois aux personnes qui n’ont aucune connaissance en IPv6 et à ceux qui en ont déjà une bonne maîtrise, mais qui n’ont pas une idée claire de ce qui est réellement utilisable actuellement.
Ce document est à mi‐chemin entre les documentations sur l’IPv6 trop simplistes et celles qui sont trop théoriques.
Lothaire YARDING est un document issu du stage de deuxième année d’ESIAL (TELECOM Nancy) de Julien Vaubourg, au sein de l’équipe réseau Lothaire (dont je fais partie), et servira de documentation aux correspondants du réseau Lothaire en prévision de migrations à IPv6. Il est publié sous licence CC by-sa.
- un yarding est une petite cour attenante à un poulailler permettant aux poules de s’ébattre joyeusement, tels des paquets IPv6 en liberté.
P.‐S. : Ceci ne constitue en rien une annonce officielle de l’équipe réseau Lothaire. Mais, je pars du principe qu’une doc sur IPv6 ne vaut que si on la diffuse rapidement.
Aller plus loin
- Le PDF (10 Mio) (3246 clics)
- Archive du .tex (172 clics)
- Dépôt Git (protocole Git) (286 clics)
# transparence entre IP v6 et IP v4
Posté par Nicolas Boulay (site web personnel) . Évalué à 5.
Une fois résolu le problème de l'infrastructure réseau, il me semble que le plus gros problème sera dans les applications elle-mêmes.
Il me semble que l'api socket unix classique est IP v4 et que l'on doit faire des changements pour utiliser IP V6. Est-ce qu'il existe des library qui masquent ces différences, permettant de fonctionner dans les 2 versions de façon transparentes ?
"La première sécurité est la liberté"
[^] # Re: transparence entre IP v6 et IP v4
Posté par rewind (Mastodon) . Évalué à 7.
getaddrinfo(3) avec un super exemple qui montre comment s'y prendre…
[^] # Re: transparence entre IP v6 et IP v4
Posté par cedric . Évalué à 6.
J'ose esperer que tous les toolkits incluant un support reseau le font de maniere transparente. <pub>En tout cas, c'est le cas pour les EFLs.</pub>
[^] # Re: transparence entre IP v6 et IP v4
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 5.
Bas niveau : getaddrinfo() en C
Haut niveau : libcurl ou libneon en C
Et tous les équivalents dans les autres langages (le problème est largement spécifique à C)
[^] # Re: transparence entre IP v6 et IP v4
Posté par Christophe Turbout . Évalué à 3.
les principales difficultés ne viennent pas du full V4 ou full V6 mais de la double pile. De fait, lors de l'utilisation de la double pile, un logiciel compatible peut utiliser les 2 versions et c'est là que le bas blesse car il arrive parfois qu'on ne sache pas quelle est la version IP qui va être testée en premier niveau applicatif et ça mène parfois à des comportements pour le moins douteux.
# Intéressant
Posté par lenod . Évalué à 2.
Excellente initiative.
Mais attention, tu devrais redimensionner tes images avant (e.g. xkcd), parce que ça rend un peu flou.
Ah, et le lien git est cassé.
[^] # Re: Intéressant
Posté par ju (site web personnel) . Évalué à 3.
Ce serait surtout merveilleux que xkcd file des versions vectorielles de ses strips :). Pour le git, c'est parce que c'est pas du http mais du protocole git (à utiliser avec git clone).
[^] # Re: Intéressant
Posté par Framasky (site web personnel) . Évalué à 4.
Je pense que le problème vient de linuxfr et de sa transformation des url.
Donc le lien git correct est git://git.fiat-tux.fr/yarding.git
Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.
[^] # Re: Intéressant
Posté par lenod . Évalué à 2.
Effectivement …
Pourquoi suis-je redirigé vers le bon lien si j'ouvre le lien normalement, alors que je suis redirigé vers git.com si je l'ouvre dans un nouvel onglet ?
# IPv6 et écologie
Posté par Pierre-Marie D . Évalué à 9.
J'ai l'impression que l'IPv6 c'est un peu un problème similaire à l'écologie.
Tout le monde est d'accord pour dire que c'est bien et qu'il faudrait qu'on s'y mette tous, mais tout le monde traîne des pieds parce que ça fait changer (habitudes ou autres) et parce qu'il n'y a pas de ROI immédiat (ou peu par rapport à l'investissement).
Pas contre quand y a des subventions…
[^] # Re: IPv6 et écologie
Posté par Nicolas Boulay (site web personnel) . Évalué à 5.
Contrairement à l'écologie, la catastrophe pourrait avoir lieu avant 2020. Cela remplace le bug de l'an 2000.
"La première sécurité est la liberté"
[^] # Re: IPv6 et écologie
Posté par reno . Évalué à 7.
Moui, sauf que pour IPv6 c'est totalement "maîtrisé" par les humains, l'écologie très, très peu ce qui fait une grosse différence.
[^] # Re: IPv6 et écologie
Posté par Pierre-Marie D . Évalué à 0.
Je pense qu'on peut faire bcp plus qu'on ne le crois ou qu'on ne nous le laisse penser (qui a dit lobby ?).
Moi je m'y mettrais encore plus quand il y aura au moins 2 écolos 100% d'accord entre eux. ;-)
P.S : La Tesla model S a un écran de 17 tactile embarqué, c'est classe, et en plus elle est jolie !
[^] # Re: IPv6 et écologie
Posté par DerekSagan . Évalué à 10.
Bah si fallait attendre de trouver 2 linuxiens 100% d'accord avec eux pour ne plus se dire que Linux c'est pas pour moi…
[^] # Re: IPv6 et écologie
Posté par Joff54 . Évalué à -2.
Il y a a aussi une histoire de pognon (un peu comme l'écologie). Changé le matos non compatible IPv6, ça peut couter…
[^] # Re: IPv6 et écologie
Posté par Larry Cow . Évalué à 3.
Il y a aussi une historie d'écologie : changer tout le matériel non-compatible ça peut polluer…
[^] # Re: IPv6 et écologie
Posté par DerekSagan . Évalué à 3.
Oui, j'ai toujours été troublé par les démarches green IT consistant à jeter des serveurs pour en acheter des nouveaux sous prétexte qu'ils sont un peu moins consommateurs en électricité par rapport à leur puissance CPU: troquer des kilowatts contre des kilos de polluants…
[^] # Re: IPv6 et écologie
Posté par gnuzer (site web personnel) . Évalué à 3.
C'est triste ton avis sur linuxfr.
[^] # Re: IPv6 et écologie
Posté par Maclag . Évalué à 1.
Aucun rapport, c'est parce qu'on se dit que d'ici à ce que la migration vers IPv6 soit indispensable, on aura assisté à un cataclysme planétaire et ce sera plus la peine.
------------->[ ]
# Support site web
Posté par Philippe Martin . Évalué à 1.
Très intéressant, merci.
Ça me motive pour faire passer les sites web que je gère à bien marcher en IPv6. Je ne trouve nulle part une doc ou un livre très pragmatique expliquant quoi faire pour qu'un site web soit accessible en IPv6 (sur un serveur Linux chez OVH dans mon cas). Et comment tester que ça marche, depuis un FAI (Free en l'occurence).
Merci d'avance pour vos tuyaux.
[^] # Re: Support site web
Posté par ju (site web personnel) . Évalué à 2.
OVH : Tu peux activer l'IPv6 depuis ton manager.
Site : C'est pas plus compliqué qu'en IPv4, faut juste s'assurer que ça écoute bien en IPv6 (apache + ipv6 ça doit donner pas mal de résultats dans un moteur de recherches).
FAI : Tu dois activer l'IPv6 depuis ton interface Free, et vérifier avec Wireshark que c'est contacté en IPv6, ou bien simplement faire afficher ton adresse IP quelque part sur le site web en question.
[^] # Re: Support site web
Posté par Buf (Mastodon) . Évalué à 2.
Faut pas oublier d'ajouter les entrées DNS avec l'adresse ipv6 du serveur.
[^] # Re: Support site web
Posté par ju (site web personnel) . Évalué à 1.
Pour le coup, si c'est OVH qui est chargé de résoudre la zone, il me semble qu'il se charge tout seul de la compléter quand on active l'IPv6.
[^] # Re: Support site web
Posté par Framasky (site web personnel) . Évalué à 2.
¿ T'es sûr de ton coup ? J'ai l'IPv6 sur mon serveur OVH mais ça ne transforme pas automatiquement mes enregistrements A en AAAA.
Si je fais un dig AAAA sur une adresse *.fiat-tux.fr uniquement enregistrée en A, je n'ai pas de réponse (et heureusement !)
Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.
[^] # Re: Support site web
Posté par ju (site web personnel) . Évalué à 1.
J'ai constaté ça pour un mutualisé en fait, donc c'est possible en effet qu'il soit moins envahissant pour du dédié.
[^] # Re: Support site web
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 7.
Pour tester, c'est simple :
Site qui a v6 :
On voit les adresses v6, c'est bon.
Site qui n'a pas v6 (il a bien une adresse mais v4 seulement) :
[^] # Re: Support site web
Posté par yanntech . Évalué à 5.
Ah oui:
voir mon poste suivant ;)
[^] # Re: Support site web
Posté par Bernez . Évalué à 1. Dernière modification le 23 septembre 2012 à 09:51.
Dans le même genre :
[^] # Re: Support site web
Posté par Philippe Martin . Évalué à 1.
En effet, comme il est dit dans l'article, il n'y a pas de quoi casser la patte à une poule pour configurer un site en IPv6 aujourd'hui.
et un test avec curl -6 fonctionne correctement.
Merci à tous pour ces tuyaux.
[^] # Re: Support site web
Posté par Zenitram (site web personnel) . Évalué à 3. Dernière modification le 18 septembre 2012 à 16:08.
Et s'assurer que tous les outils (par exemple : de stats par pays qui doit accepter une IP v6, l'antispam des commentaires basé sur les IP, les projets internes qui ont stocké l'adresse sur 4 octets…) son compatibles.
Si c'est si simple, mais pourquoi diable LinuxFr (le serveur, le réseau pour accéder au site…) n'est toujours pas en IPv6?
C'est bien plus compliqué que tu veux faire croire.
[^] # Re: Support site web
Posté par Philippe Martin . Évalué à 6.
Oups pardon, je voulais mettre un peu d'optimisme dans l'IPv6. D'accord, je voulais dire que pour un site qui ne tient pas compte des IPs, qui est hébergé chez OVH (qui semble avoir tout le matériel qui va bien pour gérer ça), avec une version Debian récente, et un FAI qui gère aussi l'IPv6, on pouvait arriver à faire un premier curl -6 en quelques minutes.
Mais bon d'accord, je ne le ferai plus : IPv6, c'est trop compliqué, je préfère laisser ça aux générations futures Et je ne ferai plus non plus de jeu de mot foireux … des poules et des hommes … casser des pattes à un canard … des poules … des canards…
Bon d'accord je sors … Tchao !
[^] # Re: Support site web
Posté par ManuxFr (site web personnel) . Évalué à 2.
Bonjour,
La doc suivante devrait répondre à tes questions concernant le DualStack…http://www.deltageek.fr/configurer-ipv6-serveur-linux/
Cas concret de la doc : Serveur Linux chez OVH et testé avec une connexion Free :)
# ipv6 sur linuxfr
Posté par yanntech . Évalué à 10.
Et en attendant il n'y a pas d'ipv6 sur linuxfr ;)
Pourtant online propose de l'ipv6 depuis un bail.
[^] # Re: ipv6 sur linuxfr
Posté par Firwen (site web personnel) . Évalué à 2.
+1
[^] # Re: ipv6 sur linuxfr
Posté par Nonolapéro . Évalué à 7.
Il faut pertinenter dans le suivi pas ici
http://linuxfr.org/suivi/support-ipv6
[^] # Re: ipv6 sur linuxfr
Posté par Maclag . Évalué à 3.
Je crois qu'ils sont ouverts aux contributions pour faire ça proprement et pas juste un truc bancal qui marche les vendredi soir de pleine lune avec comme principal modif un logo "Marche avec IPv6!" en page d'accueil.
# patches ?
Posté par mickabouille . Évalué à 2.
Chap 1.1 en bas de la page 11, "enrailler", je suppose que c'est enrayer ?
[^] # Re: patches ?
Posté par mickabouille . Évalué à 2.
Page 12, 2e paragraphe, "quiconque
n'aurait".[^] # Re: patches ?
Posté par ju (site web personnel) . Évalué à 3.
Merci beaucoup, j'ai commité les corrections sur le git (j'attend un peu que le serveur soit moins sollicité pour regénérer le pdf).
N'hésite pas si tu as d'autres réflexions !
[^] # Re: patches ?
Posté par mickabouille . Évalué à 3.
Bah j'ai un peu peur que le système de commentaire de linuxfr ne soit pas trop adapté :)
Après, avec un dépôt git, on peut il est vrai penser à d'autres solutions…
[^] # Re: patches ?
Posté par ju (site web personnel) . Évalué à 2. Dernière modification le 18 septembre 2012 à 18:53.
Sinon il y a toujours mon courriel en haut à gauche du document, qui est aussi une adresse jabber.
# Merci l'ESIAL !
Posté par Firwen (site web personnel) . Évalué à 2.
Merci cet article.
ça fait plaisir de voir l'ESIAL, Nancy et lothaire cité sur DLFP au passage.
(un ex-nancéen)
# Téléphone
Posté par jcr83 . Évalué à 1.
La première phrase est fausse, ça fait mauvais effet …
> Jusqu’à 1985, les numéros de téléphones français comportaient sept chiffres
C'est inexact, il y en avait 8 :
- pour Paris, le chiffre 1, plus 7 chiffres
- pour la province, 2 chiffres pour le département, plus 6 chiffres
Cela permettait donc d'avoir 100 millions de numéros (en fait un peu moins, puisque les numéros ne pouvaient pas commencer par le chiffre 1, ni le chiffre 0 me semble-t-il).
[^] # Re: Téléphone
Posté par jcr83 . Évalué à 0.
En réalité, ils pouvaient commencer par zéro.
[^] # Re: Téléphone
Posté par mickabouille . Évalué à 4.
Je me souviens même d'avoir utilisé des numéros de téléphone à 6 chiffres. Je ne me souviens pas s'il y avait des particularités liées à la province ou pas, je n'appelais que de province à province. En fait, j'ai même jamais téléphone plus loin que 30 Km de chez moi à l'époque.
Après, on a ajouté un numéro supplémentaire (par département ou groupe de département), pour moi c'était le 45 (Charente).
Après, on m'a rajouté le 05 (Sud-Ouest).
Enfin j'étais tout gamin…
[^] # Re: Téléphone
Posté par Antoine J. . Évalué à 10.
À cette époque (début des années 80), dans ma cambrousse seules quelques maisons avaient une ligne de téléphone. Ainsi, chez mes parents, c'était un téléphone public. Les voisins et les gens de passage venaient téléphoner, chez nous. Il y avait un compteur qui nous permettait de les faire payer à l'unité et de faire un (très léger) bénéfice. Et puis il y avait les gens qui appelaient chez nous parce qu'il voulaient dire quelque chose à un voisin et nous (moi ou l'un de mes frères et sœurs) partions à vélo pour prévenir que untel était mort ou qu'il fallait rappeler tel numéro. Parfois on nous donnait un petit pourboire ou quelques bonbons.
J'étais gamin et je ne suis pas encore très vieux, c'est fou comme ça à changé ces dernières années les télécommunications.
[^] # Re: Téléphone
Posté par ju (site web personnel) . Évalué à 1.
D'après la page wikipédia sur la numérotation téléphonique en France, à partir de 70, il n'y avait que 5 indicatifs différents, en plus des 7 chiffres : 1, 3, 6, 7 et 8. Ce qui correspond à peu près à 50 millions de possibilités. Le chiffre exact importe peu, c'est l'ordre d'idée qui est intéressant.
Je corrige en :
# ipv8
Posté par Joris Dedieu (site web personnel) . Évalué à 6.
Les RIR qui clament haut et fort : faites de l'ipv6 ! faites de l'ipv6 !
IPv6 c'est 0.8% du trafic de google (http://www.google.com/ipv6/statistics.html) et moins de 90000 hits/s chez akamai (http://www.akamai.com/ipv6/). A ma connaissance, aucun FAI de masse, n'active ça par défaut.
Pour faire de l'IPv6, il ne suffit pas de peerer avec Hurican Electric. Il faut pouvoir avoir un routage de qualité, sans trous, propre à satisfaire les clients. Si c'est faire de l'IPv6 pour ensuite expliquer comment forcer IPv4 c'est totalement sans intérêt. Hors il arrive souvent qu'il y ait des trous dans la raquette notamment aux extrémités.
Une petite boite ne va pas se payer les frais d'une migration si presque aucun de ses clients n'utilise cette possibilité. Dans le domaine HT, ça fait Hype. La réalité c'est qu'aujourd'hui placer ses serveurs et ses DNS sous IPv6 cela ne sert à rien. Et pourtant, il y a sans doute beaucoup plus de serveurs en IPv6 que de clients.
Finalement les petites boites sont mises sous pression pour cause de pénurie d'IpV4. Les grosses boites qui ont encore de la marge ne font rien et les RIR exhortent le soleil a resurgir de derrière l'horizon.
C'est donc sur les FAI qu'il faut coller la pression. En exigeant de l'IPv6 par défaut. Bon courage à tous :)
[^] # Re: ipv8
Posté par Zenitram (site web personnel) . Évalué à 1.
un IP coûte toujours que 1€ (un /24 à 300€), c'est rien en coût. Si il y a vraiment pénurie, pourquoi les prix n'augmentent pas pour calmer les ardeurs? Si il y a pénurie et pas de passage en IPv6, c'est aussi de la faute des RIR qui ne s'occupent pas de suffisamment motiver les hébergeurs et FAI à y passer… Le choc sera rude du fait de la non anticipation réelle (par le seul truc qui fasse réagir les entreprises) des RIR…
[^] # Re: ipv8
Posté par geb . Évalué à 4.
Tes sources ne sont pas bonnes: Une ressource (AS, plage IPv4 ou IPv6) c'est 50€/an. Sauf que maintenant (dernier /8) il faut être LIR pour pouvoir demander, 1,3k€/an et 2,2k€ de frais d'entrée c'est assez cher pour toi ;) ?
[^] # Re: ipv8
Posté par Zenitram (site web personnel) . Évalué à -5.
https://www.ovh.com/fr/serveurs_dedies/blocs_ip_ripe.xml
Pour commander un Bloc IP Fail-Over Ripe, rendez-vous dans votre Manager v3
Taille du bloc Frais d'installation Frais mensuel
4 5.99€ HT (7.16€ TTC) 0 € / Mois
8 9.99€ HT (11.95€ TTC)
16 17.99€ HT (21.52€ TTC)
32 34.99€ HT (41.85€ TTC)
64 69.99€ HT (83.71€ TTC)
128 139.99€ HT (167.43€ TTC)
256 279.99€ HT (334.87€ TTC)
[^] # Re: ipv8
Posté par Anonyme . Évalué à 6.
Cool, des IP routables uniquement chez OVH.
Merci Zenitram de nous exposer ta science !
[^] # Re: ipv8
Posté par Zenitram (site web personnel) . Évalué à 1.
C'est le prix d'une adresse IP quand j'en ai besoin d'une. Pas besoin d'aller vers IPv6 donc. J’achèterai le même prix si je change d'hébergeur.
La réalité ne vous plait peut-être pas, mais c'est bien le prix d'une adresse IP quand une personne a besoin d'être accessible. Qu'elle ne soit pas PI, on s'en fou un peu grâce aux DNS.
[^] # Re: ipv8
Posté par Joris Dedieu (site web personnel) . Évalué à 9.
Oui, il y a ceux qui ont du stock et qui brade ça aux
spammerspersonnes ne souhaitant pas être blacklistés. Et ceux qui n'en ont pas et qui galèrent. C'est justement le problème. Si tu te lances aujourd'hui. Tu fais comment pour monter ton AS avec ton misérable /22 ? Tu grattes, tu fais gaffes et surtout tu ne brades pas tes IPs.Pour ce qui est de l'IP failover d'OVH, je trouve infect ce type de pratiques. Je n'irai pour rien au monde vendre un /24 à mes clients sans justification. Il ont une IP avec leur serveur/vm et autant d'IP qu'ils en ont besoin pour le SSL ou pour faire du load-balancing ou du failover. Par contre il est hors de question que je vende des subnet pour qu'ils évitent d'être blacklistés. Si le RIP faisait son boulot ce type de pratique non conforme aux règles qu'il a édicté serait sanctionné. Mais il préfère empocher les cotisations et incanter IPv6.
La pénurie d'IPv4 c'est les gros opérateurs contre les petits. Ceux qui ont du stock contre ceux qui n'en ont pas. Le pied qui écrase les cafards. Je ne dis pas ça pour OVH en particulier. Mis à part cette histoire de failover vraiment hideuse, se sont des gens correct et compétents.
[^] # Re: ipv8
Posté par Zenitram (site web personnel) . Évalué à 0. Dernière modification le 18 septembre 2012 à 20:42.
C'est tout le sens de mon constat : les RIR n'ont pas fait assez attention à ne pas en refiler n'importe comment, et ce comportement (laisser d'autres comportements pas corrects de la part d'autres personnes) est possible sans impact financier pour le demandeur.
Perso, je trouve normal qu'OVH le fasse si il peut le faire, son but est d'attirer des clients. J'accuse plutôt celui qui l'autorise à le faire, le gendarme qui n'a pas fait son boulot.
[^] # Re: ipv8
Posté par benja . Évalué à 1.
J'accuse plutôt celui qui l'autorise à le faire, le gendarme qui n'a pas fait son boulot.
Belle philosophie :)
[^] # Re: ipv8
Posté par Juke (site web personnel) . Évalué à 1.
Quand un de tes clients en respecte pas le contrat, accuses tu aussi le gendarme ?
[^] # Re: ipv8
Posté par Zenitram (site web personnel) . Évalué à 3.
Tu dénonces le contrat et le client se retrouve mal. Classique. Ce ne fut pas fait, ça veut dire que c'était accepté. C'est un choix de leur part, mais il a des conséquences.
[^] # Re: ipv8
Posté par gnuzer (site web personnel) . Évalué à 1.
Un scénario cool, ce serait de mettre au point rapidement la boî-boîte auto-hébergement pour Average Joe, et ensuite balancer de grosses campagnes de pub expliquant que la boî-boîte ne marche bien que quand on est chez [liste des FAI qui proposent une IP publique fixe]. Les FAI qui ne sont pas dans la liste parce qu'ils font du NAT/de l'IP dynamique devraient passer rapidement à IPv6.
La partie la plus dure là-dedans, c'est de trouver une ou deux killer-features qui permettront de présenter l'auto-hébergement comme indispensable au quidam moyen. Pour l'instant j'ai pas trouvé.
[^] # Re: ipv8
Posté par geb . Évalué à 7.
C'est surtout pas super réaliste de compter que le déploiement de l'auto-hébergement pour tous aide à déployer IPv6 ;-)
[^] # Re: ipv8
Posté par Kerro . Évalué à 9.
Clairement, il vaut mieux une appli pour visualiser du pr0n.
[^] # Re: ipv8
Posté par Nonolapéro . Évalué à 5.
À ce sujet, le point de vue de Benjamin Bayart est intéressant. Dans un billet de blog de fdn où il explique que les règles édictées pour IPv4 ont été bêtement transposées à IPv6 ce qui mène à des absurdités, je cite :
[^] # Re: ipv8
Posté par Zenitram (site web personnel) . Évalué à -4.
D'un autre côté, on a inventé le DNS aussi pour éviter d'être dépendant d'une adresse IP qui n'est qu'un numéro. On a juste à changer l'IP dans le DNS quand on change d'hébergeur.
J'ai peut-être pas suivi un truc, mais ça sert à quoi, en pratique, une IP "PI"?
[^] # Re: ipv8
Posté par ashgan . Évalué à 2.
relis l'article de FDN, c'est pas si mal expliqué: un bloc PI (Provider Independant) est un bloc d'adresses qui te sont nominativement attribuées, et non pas une adresse appartenant à ton fournisseur qui te la "loue" le temps de la durée du contrat.
[^] # Re: ipv8
Posté par Ambroise . Évalué à 2.
De ce que j'ai compris :
Et, le jour où truc-muche veut quitter Tartempion, et bien il garde son plan d'adressage.
J'espère ne pas trop m'être trompé.
[^] # Re: ipv8
Posté par Anonyme . Évalué à 1.
C’est plutôt correcte, néanmoins c’est LIR pour Local Internet Registery.
[^] # Re: ipv8
Posté par Zenitram (site web personnel) . Évalué à 0.
Le jour où il veut quitter Tartempion, il prend de nouvelles IP chez y pur le même prix dérisoire et change son DNS et basta. Ma question est bien de savoir pourquoi le "PI" est important vu qu'on a DNS (et pourquoi on ne fait pas ces adresses plus cher pour éviter un manque brut d'un coup. Bref, c'est la base d'une gestion à long terme que d’augmenter le prix artificiellement au fur et à mesure pour inciter à passer à autre chose. PI ou pas)
[^] # Re: ipv8
Posté par Guillaume Denry (site web personnel) . Évalué à 3.
Peut-être pour la mobilité, lorsqu'on souhaite une haute disponibilité "couche basse" de ses connexions en passant de provider en provider.
Mais c'est peut-être un besoin anecdotique et peut-être solvable par d'autres moyens techniques, je sais pas trop.
[^] # Re: ipv8
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 3.
Pourquoi est-ce que le PI est important ? Si on n'a qu'un FAI, pas trop, sauf si on veut héberger ses propres serveurs DNS (pour lesquels on ne peut pas faire appel au DNS pour trouver leur adresse).
Le PI devient beaucoup plus intéressant lorsqu'on est multi-homé (plusieurs FAI), ce qui est bien utile pour la résilience.
[^] # Re: ipv8
Posté par Zenitram (site web personnel) . Évalué à 2. Dernière modification le 18 septembre 2012 à 23:07.
Le changement des adresses IP des serveurs DNS se fait assez facilement, et assez souvent d'ailleurs. C'est quoi le soucis avec les DNS pour la majorité des gens? Je suis bien conscient qu'il y a des cas problématiques (tu l'indiques sur ton blog), mais pour tous les gens à qui on essaye de vendre IPv6 ou le IPv4 PI, ça fait pschit comme argument.
J'imagine très bien qu'il y a des gens pour qui c'est important (IP codées en dur, sécurité renforcée…). Seulement, ce n'est pas le cas pour la majorité des gens qui achètent des IP (avec leur serveur filé par leur hébergeur). Et pour cette majorité, le prix est toujours bien faible, même aujourd'hui où il parait qu'on est en manque d'adresse c'est horrible. Aujourd'hui, je peux acheter un bloc (non PI certes, mais comme pour beaucoup de monde ça suffit, c'est ce beaucoup de monde qu'il faut regarder) chez OVH ou autre pour pas cher.
Ici, on se focalise sur ces fameuses PI ou le besoin de garder des IP fixes en oubliant que la majorité des IP ne sont pas PI, que les gens à qui on demande de passer à IPv6 n'ont pas de PI. Forcément, si on parle que de PI en oubliant la majorité des gens, on tire à côté et IPv6 ne risque pas d'être "vendu" avant le "mur" du vrai manque qui va arriver violemment, toujours à cause de cette politique. Dommage, cette transition aurait pu être mieux gérée, avec une gestion à long terme, et la on va se prendre le mur en pleine tronche du jour au lendemain avec un seul /8 qui reste (bon, 3 mois près si j'ai bien suivi la politique des RIR qui demandent à ce que les autres n'aient que 3 mois de réserve).
Bref, si on parlait de la majorité des gens, ceux à qui on veut "vendre" IPv6, plutôt que des exceptions? N'est-ce pas se tromper de cible en parlant de ces PI? Le serveur LinuxFr a un adresse PI?
[^] # Re: ipv8
Posté par Kaane . Évalué à 4.
sauf si on veut héberger ses propres serveurs DNS (pour lesquels on ne peut pas faire appel au DNS pour trouver leur adresse).
Non, là on passe par la config du registrar - toujours pas besoin de PI. J'héberge mes propres DNS, je les ai déjà changé plusieurs fois de place et d'hebergeur moyennant 10 secondes de config sur l'interface web de mon registrar.
Le PI devient beaucoup plus intéressant lorsqu'on est multi-homé (plusieurs FAI), ce qui est bien utile pour la résilience.
Je vieux bien l'adresse et le numero des FAI qui font du routage sur des plages modeste (au hasard un /28) - Déjà sur un /24 ils font la gueule et il faut être très bon client chez eux (comprendre que le jour ou tu n'es plus bon client, tu n'as plus de routage).
Je ne pense pas qu'IPv6 améliore ce problème (Et vu les horreurs que nous sort le RFC tous les dix jours, j'aurais plutôt tendance à penser qu'il va empirer).
[^] # Re: ipv8
Posté par Ambroise . Évalué à 1.
Car on prend le cas d'un FAI.
Et que un FAI qui fourni des adresses IP publique à client, il aimerait bien ne pas avoir à changer toutes les adresses de ses boitiers de terminaison (modem, router) car il change de LIR…
Et une par importante de ces équipements n'ont pas forcement de DNS.
Évidement, pour l'entreprise lambda, ce n'est pas forcement très utile.
[^] # Re: ipv8
Posté par Anonyme . Évalué à 6.
Et quand tu dois renuméroter toute ton infra, tu fais comment ?
Sérieusement, chacun son métier quoi… On avait compris que le tiens n’est pas celui d’admin sys/admin réseau.
[^] # Re: ipv8
Posté par Zenitram (site web personnel) . Évalué à -7.
Effectivement, ce n'est pas mon métier. Mais ma formation me permet de douter des compétences d'une personne qui veut des adresses IP fixes et que ça embête de changer l'IP de son serveur car ça demanderai trop de boulot. Chacun son plaisir de travailler pour rien, on va dire.
[^] # Re: ipv8
Posté par Anonyme . Évalué à 10.
Putain, mais des serveurs tu sais combien on en a au taff ?
Tu t’imagines si, du jour au lendemain, on doit tout renuméroter ? Tu imagines changer tout le routage interne, les règles de parefeu, les interco, etc ? Pire que ça, tu imagines si on va voir nos client en leur disant que eux doivent renuméroter ?
Je pense que tu ne vois même pas la charge de travail que ça peut être.
Sérieusement, je me permets pas de te dire que c’est mal, tu utilise tel ou tel coding style et que c’est de la merde alors reste dans ton domaine de compétence et, quand tu ne sais pas instruit toi…
[^] # Re: ipv8
Posté par Framasky (site web personnel) . Évalué à 1.
+1
Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.
[^] # Re: ipv8
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 5.
Une bonne lecture sur la question de la rénumérotation est le RFC 5887 http://www.bortzmeyer.org/5887.html
[^] # Re: ipv8
Posté par ondex2 . Évalué à 5.
Tout est dit : si tu n'a qu'un serveur on s'en fout. Comme Arcaik, je travaille dans une TPE (hébergeur/FAI). Je gère au quotidien quelques centaines de serveurs (95% Linux, 5% Windows et FreeBSD) et une quarantaine d'équipements réseaux (commutateur, routeur, pare-feu).
Pour changer de plan IP, ça implique :
- prévenir tous les clients que le changement va avoir lieu
- configurer le nouveau plan IP en parallèle de l'ancien sur toute la couche réseau
- Vérifier toutes les règles de filtrage, que la supervision est à jour, …
- ajouter la nouvelle IP à chaque serveur
- valider pour chaque serveur qu'il est prêt à passer sur la nouvelle IP (vérifier avec le client)
- Retirer l'ancienne IP de chaque serveur
- Réparer les merdes (parce qu'il y en aura)
- Déconfigurer l'ancien plan IP
Pour nous, avec deux /21 et un /23, c'est un minimum de 6 mois du début à la fin (oui, on est qu'en IPv4 pour le moment, mais on aura mis en prod IPv6 avant février prochain).
Toutes ces étapes sont nécessaires car tu ne sais jamais où sont utilisé tes IP. Dans tes DNS (là tu as la main), mais aussi dans les zones DNS de tes clients (qui sont parfois gérer à l'étranger à cause de certains TLD). Les IP peuvent être inscrite en dur dans un équipement (j'ai le cas d'un client qui fait de l'embarqué, un changement d'IP pour lui c'est une galère)
C'est sûr, on peux aussi y aller comme des bourrin comme tu le suggère, mais alors là c'est l'assurance d'une grosse gamelle !
[^] # Re: ipv8
Posté par Anonyme . Évalué à 2.
Les utilisateurs de Linux c’est 0.8% du trafic de Google. À ma connaissance aucun constructeur de masse ne l’installe par défaut.
Sinon, moins ironiquement : rien qu’en France, pour le grand publique il y a Free et SFR qui font de l’IPv6 et aussi pas mal de FAI pour professionnels (Nerim, etc.).
Désolé de te contredire mais je travail dans une TPE (un FAI pro) et le calcul est vite fait : on a qu’un petit /21 on ne pourra plus en avoir d’autre sûrement, il ne reste qu’IPv6 pour exister sur Internet.
Les personnes qui ont « oublié » IPv6 jusqu’à aujourd’hui auront un train de retard qu’il ne pourront que difficilement rattraper.
[^] # Re: ipv8
Posté par Joris Dedieu (site web personnel) . Évalué à 2.
Je disais bien "A ma connaissance, aucun FAI de masse, n'active ça par défaut". Ce n'est pas le cas de Free en tout cas. Donc mis à part les personnes éclairées, personne ne l'utilise.
Je travaille aussi dans une petite boite. On a activé ipv6 depuis plus d'un an. Cela represent une partie tellement minime du trafic qu'elle est presque non quantifiable. Le dual stack n'est pas prêt de disparaître. C'est un fait.
Ce que j'essayais de mettre en exergue c'est que tant que les FAI ne l'auront pas déployé massivement (on parle pas du truc optionnel pour faire plaisir), l'IPv6 ne résoudra pas ton problème. Tu devra gérer la pénurie. Ou te procurer des IPv4 par d'autre moyens.
[^] # Re: ipv8
Posté par Juke (site web personnel) . Évalué à 3.
Il me semble que c'est maintenant activé par defaut.
[^] # Re: ipv8
Posté par dleducq . Évalué à 1.
Pas pour tout le monde :
"Vous pouvez en zone dégroupée bénéficier d'une connectivité au protocole IPv6."
Quand on ne l'est pas, ce qui est mon cas, pas d'IPV6…
[^] # Re: ipv8
Posté par ahuillet (site web personnel) . Évalué à 5.
le grand public
C'est pourtant pas compliqué…
[^] # Re: ipv8
Posté par Anonyme . Évalué à -1.
J'ai jamais su la règle pour publique/public.
On dit d'une chose qu'elle est publique mais on parle du public c'est ça ?
[^] # Re: ipv8
Posté par netsurfeur . Évalué à 9.
C'est pourtant simple:
[^] # Re: ipv8
Posté par ju (site web personnel) . Évalué à 2.
Concernant Free, il ne faut pas oublier qu'ils font du 6rd. Si les adresses IPv6 qu'ils distribuent semblent donc venir d'un réseau natif, ça n'est pas du tout le cas : comme indiqué dans yarding, un sniffeur placé entre une Freebox et la prise téléphonique murale ne verra passer que de l'IPv4.
La seule exception c'est pour les lignes FTTH qui sont en IPv6 de bout en bout (ce point va être ajouté dans yarding).
[^] # Re: ipv8
Posté par NilugeKiWi . Évalué à 2.
Je suis chez Free en FTTH et j'utilise 6rd. Ça a changé récemment? (mon setup date de moins d'un an).
[^] # Re: ipv8
Posté par ju (site web personnel) . Évalué à 2.
Le 6rd côté Free est totalement transparent, comment en es-tu sûr ?
[^] # Re: ipv8
Posté par NilugeKiWi . Évalué à 2.
Je n'utilise pas la freebox. J'ai été parmi les premiers à avoir la joie de recevoir la freebox optique v2, qui est une freebox adsl v5 recyclée avec un autre firmware, et la prise optique est déportée dans un boîtier externe ethernet <-> fibre. La freebox ne tient pas les débits annoncés (100Mbps en dl théoriques, le matériel tient 20Mbps en routeur et 50Mbps en bridge, sans la freebox on monte plus de 100Mbps; plus d'infos sur ce bug, et sur ce long thread).
Bref j'ai configuré du rd6 à la main et ça fonctionne bien. Si entre temps ils sont passés en ipv6 natif il faudrait que je reconfigure tout ça.
# DHCPv6 et Prefix delegation
Posté par abraxas . Évalué à 3.
Merci beaucoup de rendre cela public, c'est très intéressant et ce n'est pas facile de trouver des sources lisibles à ce sujet (se farcir les RFC c'est un peu pénible quand on veut juste se connecter à Internet).
Un truc dont ton PDF ne parle pas (et c'est normal puisque la problématique c'est le réseau interne), c'est comment ça se passe en pratique pour le client d'un FAI.
De ce que j'ai compris chez Free (qui attribue des /64), tout se fait avec NDP (le routeur de Free fait sa pub et annonce la plage dispo et les DNS). Mais je suis chez OVH (nobox) qui donne des /56, et il faut passer par DHCPv6 et le "prefix delegation" (le serveur dhcp te délègue le /56 en même temps qu'il t'attribue une IP qui n'est pas dans ce /56, et tu en fais ce que tu veux derrière). Je n'ai peut-être pas suffisamment creusé la question mais j'ai l'impression que c'est la seule façon de déléguer dynamiquement un /56 (ou toute plage strictement plus grosse que /64), c-à-d qu'il me semble que NDP ne peut pas faire ça.
Du coup si demain l'IPv6 se démocratise (et que les FAI attribuent des /56 ou même des /48) j'imagine que ça sera la technique utilisée par défaut (ils ne vont pas configurer statiquement les box quand même), et donc ça sera important. Le problème avec l'implémentation actuelle c'est qu'il y a deux programmes séparés (dhcpv6-client et radvd) qui devraient discuter pour faire ça, mais ce n'est pas encore le cas. Du coup je n'ai pas trouvé d'autre moyen que de demander le prefix delegation avec DHCPv6, mais en configurant radvd statiquement (c'est un peu con).
Si quelqu'un a mieux compris comment tout ça est sensé fonctionner, je lui serai reconnaissant de me (nous) faire partager sa science!
[^] # Re: DHCPv6 et Prefix delegation
Posté par Framasky (site web personnel) . Évalué à 2.
Non, non, pas mon pdf, celui de Ju :-)
Ju, une réponse ?
Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.
[^] # Re: DHCPv6 et Prefix delegation
Posté par ju (site web personnel) . Évalué à 2.
N'ayant pas une ligne Free (mais plutôt libre et neutre), je ne peux pas vérifier, mais j'ai un gros doute sur le fait qu'il utilise NDP pour la diffusion des DNS. Comme démontré dans le document, le RDNSS qui permet cela est encore loin d'être suffisamment démocratisé (notamment parce qu'il est apparu plus tard). Au delà de ses possibilités d'administration plus puissantes (comme le DDNS), c'est principalement pour cette raison que le DHCPv6 est encore très utilisé, a minima en complément du NDP.
Concernant radvd, son nom signifie Router ADVertisement Daemon, il ne concerne donc pas les clients. Et le NDP n'a pas de contrainte particulière, à ma connaissance, concernant la taille du préfixe qu'il peut annoncer via ses RA.
[^] # Re: DHCPv6 et Prefix delegation
Posté par abraxas . Évalué à 1.
Pour Free je ne sais pas je n'ai pas non plus, mais pour le DNS j'imagine qu'il se contente de l'IPv4.
J'avais cru comprendre que tout routeur doit ignorer les RA (mais avec un sysctl on peut changer ça sous Linux au moins).
Si tout doit marcher automagiquement avec le NDP, il va falloir que le routeur à la maison analyse les RA venant du routeur des FAI, et décide d'attribuer telle plage à tels clients, en envoyant à son tour des RA et en configurant les route.
Existe-t-il un programme qui se charge de ça sous Linux?
Concernant la taille du préfixe dans les RA, si celui-ci est plus court que /64, par exemple /56, est-ce que les clients peuvent mettre n'importe quoi pour les 8 bits suivants?
[^] # Re: DHCPv6 et Prefix delegation
Posté par ju (site web personnel) . Évalué à 1.
Effectivement les équipements réseaux et les serveurs n'ont pas intérêt à se sentir concernés par les modes d'autoconfiguration, quelqu'ils soient.
Concernant l'organisation de ton réseau domestique, il y a effectivement de nouvelles questions qui se posent. Non pas à cause de l'IPv6, mais à cause de la disparition des NAT. Ce problème est expliqué, avec l'exemple des associations MAC-IP (autrefois assurées par l'ARP mais maintenant à la charge du NDP), dans le document, en tête de la section Auconfiguration et DNS. Tu verras que la solution est le proxy NDP, qui se met en place directement avec la commande ip sous GNU/Linux. Tu trouveras plein de tutos sur la toile, dont celui-ci (qui évoque aussi le brouting).
Concernant l'utilisation des bits dans tes adresses, tu pourras effectivement mettre à peu près ce que tu veux dans ces 8 bits de réseau, mais il semble judicieux de se contraindre à quelques bonnes pratiques (dont tu peux prendre connaissance dans la section du même nom, du document).
[^] # Re: DHCPv6 et Prefix delegation
Posté par abraxas . Évalué à 1.
Merci, dans mon cas (je ne sais pas si OVH fait "mal" son boulot ou pas), les RA que mon routeur reçoit sur la ligne ont les flags M (managed) à 1 et O (other) à 0, ainsi qu'un préfixe de 128 bits. Je crois que je n'ai pas la possibilité de configurer "sans état" (avec un proxy NDP) du coup.
Mais même si OVH avait choisi d'utiliser NDP, j'ai l'impression que le proxy NDP n'est pas optimal: cela ne permet pas d'organiser son/ses réseau(x) domestique(s) comme on veut derrière (dynamiquement). Ou alors est-ce qu'il y a une implémentation permettant au routeur domestique de reçevoir le préfixe du FAI en NDP (en supposant uniquement la longueur du préfixe comme connue à l'avance) et de "segmenter" derrière, en NDP toujours (sans même se préoccuper des DNS)?
[^] # Re: DHCPv6 et Prefix delegation
Posté par geb . Évalué à 2.
De mémoire (à confirmer donc), si, et un apt-get install rdnssd devrait faire le boulot. En attendant, les DNS v4 sont effectivement envoyés en DHCP(v4). Cela a le mérite de marcher en failback :).
[^] # Re: DHCPv6 et Prefix delegation
Posté par abraxas . Évalué à 1.
Et merci à ju donc!
[^] # Re: DHCPv6 et Prefix delegation
Posté par Ambroise . Évalué à 1. Dernière modification le 19 septembre 2012 à 08:26.
Si : il suffit d'installer une rdnssd pour voir son fichier hosts mis à jour par le infos envoyées par la Freebox…
[^] # Re: DHCPv6 et Prefix delegation
Posté par ju (site web personnel) . Évalué à 2.
Je n'ai évidemment aucun doute sur le fait que GNU/Linux soit performant :). Mais le fait est que c'est actuellement le seul qui soit vraiment capable de le faire (cf. yarding), et encore, ça n'est pas installé nativement sur les distros.
Pour que l'IPv6 se démocratise, il faudra que ça soit un peu plus qu'une histoire de geeks…
[^] # Re: DHCPv6 et Prefix delegation
Posté par benoar . Évalué à 2.
Normalement, il faudrait effectivement que le client DHCPv6 et radvd dialoguent. Ça n'est pas encore tout à fait automatique actuellement, mais j'espère que ça arrivera dans les distributions bientôt. Car tout ça, ça ne reste qu'une histoire de scripting à faire quand ton client dhcp reçoit un préfixe.
# Fiouf
Posté par Snarky . Évalué à 1.
140 pages ! J'attendrai la sortie du film !
Sinon, ça m'a l'air très intéressant. Je vais étudier ça a tête reposé ! Peut être que enfin, j'arriverai a faire migrer ma société du IPv6 :)
# English grammar
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 2.
I may very well be wrong, but I am pretty sure that you meant "Yet Another Reference for Delivering IPv6 to the Next Generation."
[^] # Re: English grammar
Posté par ju (site web personnel) . Évalué à 2.
This problem was already fixed in the document but not in the post.
# IPV6, Nat, Firewall et réseaux locaux
Posté par sifu . Évalué à 3.
Hello,
J'ai pas encore lu l'ensemble du document mais pour moi ce qui est le plus obscure/inquiétant est de savoir ce qui va se passer pour mon réseau local.
Actuellement, j'ai une configuration assez classique:
Box -> Routeur WRT54G avec OpenWRT -> PC, Smartphones etc.
Le routeur fait office de pare-feu et de passerelle NAT afin que tout le monde puisse se connecter au grand ternet.
Voilà, de ce que j'ai compris, IP v6 va permettre de se passer du NAT et donc tout le monde aura une adresse publique.
Je suppose que mon FAI me donne une plage d'IP et que c'est à moi (sans doute à mon routeur de déterminer l'adresse publique des machines).
Quid de la sécurité ?
Le NAT m'offre (un semblant ?) de sécurité car les machines ne sont pas vraiment accessibles depuis l'extérieur.
Du coup, il va falloir sérieusement revoir les règles du firewall, non ?
Machine IP v4 ?
Les trucs comme les consoles qui n'ont pas de support d'IP v6 sont exclus d'internet.
Faut-il que mon routeur continue à faire du NAT pour eux ?
Voilà. J'aimerais bien m'y mettre mais j'ai un peur d'ouvrir la boîte de pandore.
Merci.
[^] # Re: IPV6, Nat, Firewall et réseaux locaux
Posté par geb . Évalué à 3.
Oui. Mais installer un firewall statefull, cela se fait en 3 minutes. De mémoire:
Laisse passer les paquets correspondants aux flux déjà établis.:
ip6tables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
Drop le reste:
ip6tables -A INPUT -j DROP
[^] # Re: IPV6, Nat, Firewall et réseaux locaux
Posté par croux . Évalué à 2.
Un tel exemple de chaine INPUT, me fait dire que la règle de filtrage proposée est d'une part destinée à être appliquée à chaque machine du réseau (et non pas au routeur (FORWARD) alors que ce serait plus pertinant dans l'optique du remplacement du NAT), et d'autre part qu'elle est suceptible de bloquer les mécanismes de découverte du préfix IPv6 utilisé pour définir les adresses globales (celles qui sont routables sur internet).
[^] # Re: IPV6, Nat, Firewall et réseaux locaux
Posté par geb . Évalué à 2.
C'est vrai, j'ai fais ça un petit peu trop en vitesse (moinssez moi). Une version plus correcte, serait:
ip6tables -A FORWARD -p icmpv6 -j ACCEPT
ip6tables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
ip6tables -A FORWARD -j DROP
Concernant l'ICMPv6, de mémoire, il sert pas seulement à la découverte du prefix global et de l'adresse qui lui est associée aussi à la construction des adresses locales, ainsi qu'à la communication entre les machines elles même puisse ce qu'il remplace l'ARP et à la gestion de la fragmentation. Il est donc très fortement recommandé de ne pas le dropper. Si l'on souhaite filtrer certaines choses (pour ne pas répondre aux ping par exemple, même si je doute de la pertinence de cette idée), une bonne source d'informations est la https://tools.ietf.org/html/rfc4890 qui contient des exemples ip6tables à la fin.
[^] # Re: IPV6, Nat, Firewall et réseaux locaux
Posté par geb . Évalué à 2.
Erf, je ne peux pas éditer mon commentaire. La version précédente ne marcherait pas. Celle ci par contre devrait être bonne:
ip6tables -A FORWARD -p icmpv6 -j ACCEPT
ip6tables -A FORWARD -i $interface_publique -j FWD_FROM_PUB
ip6tables -A FORWARD -i $interface_privée -j FWD_FROM_PRIV
ip6tables -A FORWARD -j LOGDROP
ip6tables -A FWD_FROM_PUB -m state --state RELATED,ESTABLISHED -j ACCEPT
ip6tables -A FWD_FROM_PUB -j DROP
ip6tables -A FWD_FROM_PRIV -i $interface_privée -j ACCEPT
ip6tables -A FORWARD -j DROP
[^] # Re: IPV6, Nat, Firewall et réseaux locaux
Posté par Patrick Lamaizière (site web personnel) . Évalué à 2.
Mon dieu mon dieu mon dieu…
block
pass in on int_if
pass out
Je dis ça…
les pixels au peuple !
[^] # Re: IPV6, Nat, Firewall et réseaux locaux
Posté par Anonyme . Évalué à 3.
Oui, dit rien, tes règles sont incompréhensible comparé aux règles iptables !
[^] # Re: IPV6, Nat, Firewall et réseaux locaux
Posté par zebra3 . Évalué à 4.
Perso, je trouve la config de Shorewall très lisible.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: IPV6, Nat, Firewall et réseaux locaux
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 2.
Ouais…
<ironique>
Enfin trois lignes plutôt lisibles et écrites en une seule fois plutôt que 8 lignes relativement cryptiques
</ironique>
Bon, ok, la version Packet Filter serait un poil plus longues que les trois lignes présentées mais côté lecture, perso, je préfère.
[^] # Re: IPV6, Nat, Firewall et réseaux locaux
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 2.
Comme on parle juste d'IPv6, ça, c'est bien comme premier jet (Attention à la complexité et au manque de lisibilité qui piquent les yeux)
[^] # Re: IPV6, Nat, Firewall et réseaux locaux
Posté par sifu . Évalué à 1.
Oki doki.
Pour le coup, cela mérite un peu d'investissement, si je veux pas mettre en branle mon réseau local …
[^] # Re: IPV6, Nat, Firewall et réseaux locaux
Posté par Anonyme . Évalué à 3.
Et comme ça tu bloque même ce que les RFC interdisent de bloquer.
[^] # Re: IPV6, Nat, Firewall et réseaux locaux
Posté par ju (site web personnel) . Évalué à 2.
Comme expliqué dans yarding, on a énormément associé la sécurité au NAT au fil des années, depuis que l'appauvrissement des adresses nous a obligé à le mettre en place de façon systématique. Il n'y a pourtant aucun rapport entre cette notion et celle de pare-feu.
Ce dernier peut (doit !) être déployé aussi bien pour l'IPv4 que pour l'IPv6, et le fait que toutes les adresses soient publiques (ce qui est initialement naturel, et ce que les nouvelles générations d'informaticiens découvrent) n'est pas synonyme de passoire.
Pour une box grand public, j'imagine qu'un pare-feu intelligemment configuré remplacera à terme le NAT obsolète.
[^] # Re: IPV6, Nat, Firewall et réseaux locaux
Posté par Guillaume Denry (site web personnel) . Évalué à 1.
"Aucun rapport", "aucun rapport", bin si y'a quand même le rapport qu'une IP derrière un NAT n'est pas directement joignable de l'extérieur par des trucs du genre script kiddies, alors que sans NAT elle le serait.
Alors arrêtez de dire que y'a "aucun rapport". Que le NAT ne soit pas un moyen convenable de faire de la sécurité, 100% d'accord, l'élément de sécurité (aussi petit soit-il) du NAT est un effort de bord, mais il existe quand même et on doit trouver d'ailleurs son pendant côté IPv6 en adoptant des règles spécifiques.
[^] # Re: IPV6, Nat, Firewall et réseaux locaux
Posté par Anonyme . Évalué à 2.
Dans le cas d'un NAT où une IP externe est mappée sur une et une seul IP interne cette phrase est fausse.
Pour offrir la fonctionnalité « machine non accessible de l'extérieur », je pense que c'est bon, on a ce qu'il faut depuis longtemps, ça s'appelle un parefeu.
[^] # Re: IPV6, Nat, Firewall et réseaux locaux
Posté par Guillaume Denry (site web personnel) . Évalué à 1.
Je parlais implicitement de N -> 1, qui est le cas de la plupart des entreprises qui mettent en place du NAT et qui n'ont pas toutes une classe A à leur disposition.
Il n'empêche que le NAT (je précise masquerading pour ceux qui font semblant de ne pas comprendre mon propos) a pour effet de bord de cacher les machines, ce qui est un élément constitutif de sécurité. Pour le reste, je répète que je n'ai jamais écris que le NAT se substituait à un firewall, juste que la phrase "le NAT n'a aucun rapport avec la sécurité" que j'entends régulièrement me semble un peu extrême.
C'est bien simple, prend un réseau d'entreprise classique IPv4 avec un NAT N->1 ET un Firewall, maintenant, tu rends soudainement publiques toutes les adresses de ton réseau, on va voir si le NAT ne rajoutait pas une petite couche de sécurité.
[^] # Re: IPV6, Nat, Firewall et réseaux locaux
Posté par Anonyme . Évalué à 4.
Je comprends pas comment tu arrives à une telle conclusion…
Le NAT n'apporte pas plus de sécurité qu'un parfeu qui DROP tout sauf RELATED,ESTABLISHED. Donc, si ton parefeu est bien configuré, tu peux virer le NAT, ça ne changera rien.
[^] # Re: IPV6, Nat, Firewall et réseaux locaux
Posté par Guillaume Denry (site web personnel) . Évalué à 2.
Je parle de PME, de configurations multiples et variées, plus ou moins bien foutues où le NAT est utilisé (aussi) pour cacher les machines internes de l'extérieur.
Le NAT est utilisé à mauvais escient mais ça "fonctionne" quand même => c'est le frontal qui se prend les attaques et les machines derrière ne peuvent physiquement pas être jointes directement, sauf à faire de la translation de port ou bien du BIMAP.
Un peu de nuance, c'est tout ce que je fais remarquer. Il y a beaucoup de gens qui utilisent cet aspect "dissimulation des réseaux internes" du masquerading EN plus des options de firewalling.
Et puis, autre chose, avec le NAT N->1, c'est l'IP du firewall qui sort, avec IPv6, on a N IP qui sortent, alors certes, il y a des stratégies existantes d'anonymisation des IP, mais c'est également un autre aspect du NAT qu'on "perd".
[^] # Re: IPV6, Nat, Firewall et réseaux locaux
Posté par ju (site web personnel) . Évalué à 3. Dernière modification le 19 septembre 2012 à 17:02.
Oui, un effet de bord, effectivement. Et c'est un effet de bord sur lequel ne comptent pas les réseaux d'entreprise, qui assurent le contrôle des accès via un pare-feu indépendant, IPv6 ou non. La sécurité est donc un élément à part entière, indépendante de la notion de NAT.
Pour un réseau domestique en IPv4, le NAT et les règles de PAT assurent effectivement cette notion de pare-feu, du moins pour tout ce qui vient de l'extérieur. Mais peu importe, puisqu'un simple pare-feu dans les box suffira à le remplacer, et de façon plus avantageuse.
[^] # Re: IPV6, Nat, Firewall et réseaux locaux
Posté par Florent Fourcot . Évalué à 1.
Pour la question de la "sécurité" du NAT, tu peux lire cet article qui résume très bien la situation : http://www.bortzmeyer.org/nat-et-securite.html
Pour les équipements uniquement IPv4 par contre effectivement c'est la merde, ils ne pourront jamais marcher en v6. Mais tu peux activer l'IPv6 sans s'inquiéter pour eux, la fin du dual-stack n'est pas pour aujourd'hui…
[^] # Re: IPV6, Nat, Firewall et réseaux locaux
Posté par sifu . Évalué à 1.
Il ne fonctionneront pas en IPv6. Ok. Mais alors faut-il prévoir une installation spécifique sur le routeur ou bien est-ce naturellement pris en compte par cette nouvelle version ?
Merci.
# Mise à jour suite aux remarques
Posté par ju (site web personnel) . Évalué à 2.
Voir ce journal, pour ce qui est des mises à jour effectuées depuis la diffusion de la dépêche.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.