Bonjour à tous
Je me demande si cela peut avoir un sens d'avoir son infrastructure interne en full ipv6 et monter une passerelle ipv4 pour que l'exterieur accède aux services publics ? Dans le cas où cela aurait un sens, y a t'il un moyen simple d'avoir son bloc ipv6 indépendant de son fournisseur d'accès ?
Bien à vous
Km
Le 5 déc. 2011 à 14:20, cam.lafit@azerttyu.net a écrit :
Bonjour à tous
Je me demande si cela peut avoir un sens d'avoir son infrastructure interne en full ipv6 et monter une passerelle ipv4 pour que l'exterieur accède aux services publics ? Dans le cas où cela aurait un sens, y a t'il un moyen simple d'avoir son bloc ipv6 indépendant de son fournisseur d'accès ?
Bien à vous
Km
Bonjour, Il me semble qu'il y a eu une présentation aux JRES à ce sujet. J'ai jamais réussi à la regarder en entier à cause de petits soucis de débit chez moi...
https://conf-ng.jres.org/2011/planning.html "57 : Comment vivre avec un réseau IPv6 pur"
Cordialement, Florian Maury
2011/12/5 cam.lafit@azerttyu.net cam.lafit@azerttyu.net
Bonjour à tous
Je me demande si cela peut avoir un sens d'avoir son infrastructure interne en full ipv6 et monter une passerelle ipv4 pour que l'exterieur accède aux services publics ? Dans le cas où cela aurait un sens, y a t'il un moyen simple d'avoir son bloc ipv6 indépendant de son fournisseur d'accès ?
Bien à vous
Km _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Bonjour,
Il me semble peu pertinent d'avoir une infrastructure interne full IPv6 si c'est pour avoir une passerelle en IPv4-only. Il peut par contre être intéressant d'avoir une infra en IPv6 si l'accès depuis l'extérieur peut se faire en IPv6 (avec fallback IPv4) et si l'accès vers l'extérieur se fait en IPv6 quand cela est possible (toujours avec un fallback IPv4 pour éviter de se retrouver coupé du monde).
*Hurricane Electric* (he.net) fournit des blocs IPv6 (/48 et /64). Ce sont des blocs PI (Provider Independant) qui se relient par tunnel. Ils donnent des exemples de configuration pour tous types d'OS/routeurs.
Cordialement,
Bonjour
Je me suis probablement mal exprimé l'idée n'est pas d'avoir du ipv4 only depuis le nain ternet mais bien l'un et l'autre. Actuellement c'est une infra que je dirais classique avec un conf ipv4 et un peu d'ipv6 expérimental instable.
Je me demande si ça vaut le coup d'avoir du ipv6 tout beau en interne accessible depuis le net pour ceux qui peuvent et intégrer une passerelle ipv4 pour maintenir la cohérence actuelle pour ceux qui ne sont que v4.
En tunnel borker, j'avais noté he et sixxs sans savoir ce que je pourrais en faire ensuite.
Est ce que certains d'entre nous ont dans des configuration de ce genre ?
Merci.
Km
bonjour , c'est typiquement du NAT64/DNS64 http://en.wikipedia.org/wiki/NAT64 http://www.bortzmeyer.org/6146.html
pour l'accés de l'exterieur , ca doit etre possible selon wikipedia
In general, NAT64 is designed to be used when the communications are initiated by IPv6 hosts. Some mechanisms (including static address mapping) exist to allow the reverse.
Message du 05/12/11 14:20 De : "cam.lafit@azerttyu.net" A : "French SysAdmin Group" Copie à : Objet : [FRsAG] Ipv6 interne et Ipv4 externe ?
Bonjour à tous
Je me demande si cela peut avoir un sens d'avoir son infrastructure interne en full ipv6 et monter une passerelle ipv4 pour que l'exterieur accède aux services publics ? Dans le cas où cela aurait un sens, y a t'il un moyen simple d'avoir son bloc ipv6 indépendant de son fournisseur d'accès ?
Bien à vous
Km _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
On 12/05/2011 03:22 PM, cd wrote:
bonjour , c'est typiquement du NAT64/DNS64 http://en.wikipedia.org/wiki/NAT64 http://www.bortzmeyer.org/6146.html
pour l'accés de l'exterieur , ca doit etre possible selon wikipedia
In general, NAT64 is designed to be used when the communications are initiated by IPv6 hosts. Some mechanisms (including static address mapping) exist to allow the reverse.
Attention quand meme, il ne faut pas oublier que NAT64 fonctionne uniquement avec 3 protocols (TCP, UDP et ICMP), qu'il y a des problématiques avec l'utilisation de DNSSEC, et quid de la façon de logger...
J'ai testé pendant un certains temps l'IPv6 only à la maison avec DNS64+NAT64, ca marche très bien dans 90% des usages, mais de la à l'implementer en entreprise ... le dualstack a encore de beau jours devant lui.
http://www.queret.net/blog/category/full-ipv6-story/
Yoann
Le 05/12/11 16:33, Yoann QUERET a écrit :
J'ai testé pendant un certains temps l'IPv6 only à la maison avec DNS64+NAT64, ca marche très bien dans 90% des usages, mais de la à l'implementer en entreprise ... le dualstack a encore de beau jours devant lui.
J'ajoute même qu'aucun de mes clients n'envisage de l'ipv6 en interne, ipv6 dit surtout dns interne à jour sinon impossible de se mémoriser et taper rapidement une adresse interne. Juste ce point là fait qu'ils ne sont pas motivés. Enfin beaucoup trop de matériel est ipv4 only comme les imprimantes / scanner réseau. Un autre frein rencontré c'est les entreprises qui montent pleins de tunnel vpn avec différents clients ou prestataires, à quoi bon mettre du dual stack là dessus, ipv6 only ca implique que tous les tiers soient en v6 aussi.
A mon sens il serait déjà bien que les accès soient dual stack, que les services hébergés (serveurs, cloud, saas, ...) soient dual stack avant que l'on ait réellement besoin d'ipv6 en interne.
Quelques retours d'experience sur NAT64 http://tools.ietf.org/html/draft-korhonen-behave-nat64-learn-analysis-02#sec... http://tools.ietf.org/html/draft-tan-v6ops-nat64-experiences-00 http://tools.ietf.org/html/draft-ietf-behave-nat64-learn-analysis-01
mais grosso modo tout ce qui n'utilise pas le dns ne fonctionne pas (SIP,RTSP), ainsi tout ce qui utilise directement des IPv4 dans le code (page web)
Le 05/12/2011 18:01, Wallace a écrit :
Le 05/12/11 16:33, Yoann QUERET a écrit :
J'ai testé pendant un certains temps l'IPv6 only à la maison avec DNS64+NAT64, ca marche très bien dans 90% des usages, mais de la à l'implementer en entreprise ... le dualstack a encore de beau jours devant lui.
J'ajoute même qu'aucun de mes clients n'envisage de l'ipv6 en interne, ipv6 dit surtout dns interne à jour sinon impossible de se mémoriser et taper rapidement une adresse interne. Juste ce point là fait qu'ils ne sont pas motivés.
perso , je trouve l'excuse un peu facile. que l'on soit en ipv6 ou v4, on a autant de ressources à gérer. seulement une fois que l'on a tapé le prefix plusieurs fois , ça rentre , et on s'en rapelle exemple 2001:db8:cafe ;) (j'exager un peu sur l'exemple) pour le reste de l'adresse il faut un moyen mnémotechnique pour le suffix genre :53 pour le dns
2001:db8:cafe::53
mais de toutes facons c'est du bricolage de bosser avec des ip. c'est pas dans l'esprit d'ipv6.
les IPAM vont avoir le vent en poupe ;) je ne suis pas expert windows 2008 mais , ca doit pas etre compliqué de monter un serveur dhcpv6 avec mise à jour dynamique du DNS
... A mon sens il serait déjà bien que les accès soient dual stack, que les services hébergés (serveurs, cloud, saas, ...) soient dual stack avant que l'on ait réellement besoin d'ipv6 en interne.
le soucis du dual-stack ,c'est du 95 % ipv4, meme si l'ipv6 est dispo aux deux bouts. aussi si le choix du v4 ou v6 n'est pas très bien implémenté par les applications, ,ca peut provoquer des timeout que l'on aurait pas avec un full ipv6
bref, il n'y a pas de solutions magiques :/
On Monday 05 December 2011 14:20:08 cam.lafit@azerttyu.net wrote:
Je me demande si cela peut avoir un sens d'avoir son infrastructure interne en full ipv6 et monter une passerelle ipv4 pour que l'exterieur accède aux services publics ?
Tout à fait : tourner en dual stack revient à maintenir 2 réseaux différents sur la même infrastructure, ce qui est tout sauf pratique.
En fonction de ce que fais tourner, différentes techniques sont utilisables. Si c'est pour du contenu HTTP par exemple, il suffit de foutre les LB en dual- stack, et ensuite de l'IPv6 sur le réseau interne.
Pour que des clients accèdent à l'Internet v4, t'a principalement le choix entre utiliser un proxy (donc seulement pour le HTTP) ou alors faire du NAT64/DNS64 (marche bien, au moins à petite échelle, mais ça casse quand même des trucs).
Dans le cas où cela aurait un sens, y a t'il un moyen simple d'avoir son bloc ipv6 indépendant de son fournisseur d'accès ?
http://www.ripe.net/ripe/docs/ripe-523#_8._IPv6_Provider
Par contre c'est pas forcément ce que tu cherches si le but est d'avoir un réseau interne privé en IPv6, les ULA sont plus adaptées et ne demandent pas de justification. Quitte à devoir utiliser du NAT66 par derrière, même si c'est litigieux pour certains :3
Le lundi 05 décembre 2011 à 20:48, Rémy Sanchez écrivait: [SNIP]
Tout à fait : tourner en dual stack revient à maintenir 2 réseaux différents sur la même infrastructure, ce qui est tout sauf pratique.
C'est bien tout le problème actuel. Savoir que choisir depends surtout de l'archi à migrer. Y'a moultes techniques pour deployer v6 suivant les contraintes.
La principale contraite ce sont les OS et les applicatifs derriere. Certains ne savent pas ce qu'est v6, pour eux, c'est simple, faut leur presenter du v4. D'autre, sur le papier c'est supporté, et c'est la que commence la chasse au bug a la con qui fait que v6 marche mais est pas forcement utlisable. Souvent sur les systèmes libres, c'est patché rapidement, mais faut encore pouvoir upgrader, ce qui n'est pas toujours faisable ni rentable.
En fonction de ce que fais tourner, différentes techniques sont utilisables. Si c'est pour du contenu HTTP par exemple, il suffit de foutre les LB en dual- stack, et ensuite de l'IPv6 sur le réseau interne.
"il suffit" c'est la que les problèmes arrivent en fait.
Sur la papier c'est tout mignon, mais dans la pratique, coté vendor, c'est pas encore ça. Tu te retrouves avec des cas a la con du genre "Ah oui, on vait du v6 sur le firewall machin en version truc mais faut upgrader les chassis" ou "oui on gère mais en fait on traite en software" ou "ah oui on sait LB du v6 vers des reals en v4 mais des fois ça donne un etat interminé, on ferra une release pour Q4 2012" (toute reference à Checkpoint et Cisco serait purement fortuite )
et encore, sans compter les débats trollesques sur le theme "quelle taille le subnet d'interco" ou "mm tiens, je fais faire du NAT a l'ancienne mais sur du v6"
[SNIP]
il faut se mettre au v6, c'est tres bien, mais surtout faut tout de suite se poser les bonnes questions pour ne pas recreer un reseau v4-like, et faire rentrer dans la boucle de reflexion les devs (ceux qui collent des IPv4 en hard dans les codes, par exemple, ou qui stocke les IPs sur un VARCHAR(15) dans une base), les sysadmins (nous quoi ;p), les gars du reseau ET les decideurs pressés qui doivent comprendre qu'il est probable que le passage a v6 implique pas mal de changement.
/2_cents_matinal
Snarf
Bonjour à tous
Alors désolé je ne vais pas quoter dans les règles de l'art vu que je vais répondre/compléter certainement dans le désordre et sans logique.
L'idée du PI me tente bien car bien que dans l'immédiat c'est de deployé en interne du ipv6, à terme il semble logique de le rendre public enfin une partie, donc faire du nat66 cela rajoute une surcouche pour le plaisir de continuer à perdre des cheveux.
J'ai un avantage c'est que je suis un peu tout à la fois (décideur / adminsys / ....) donc je peux me permettre de mettre tout le monde à la même table pour discuter. L'autre avantage c'est que j'ai une petite infrastructure (qui va prendre de l'ampleur un jour :) ce qui peut me permet de bosser des bases saines autant que possible.
Le désavantage c'est que je suis un peut tout à la fois (....) donc je bosse comme un pied et que je suis un peu sourd d'une oreille.
De ce que je comprends, il existe 2 options a peu près saine : -* gérer du dual stack sur l'ensemble de son infrastructure -* monter un nat/dns64
Dans les 2 cas on passe par un point de routage pour choper (via tunnel ou non) son réseau v6 public.
De ce que j'ai compris aussi la solution dns/nat64 ne garantit pas une simple conversion 1 ipv4 ==> 1 ipv6. Je n'ai pas encore lu assez les documents remontés pour comprendre pourquoi ce n'est pas si simple que ça.
Je me dit que dans l'immédiat le compris serait de déployer du dualstack sur l'ensemble de l'infrastructure et puis au fur et à mesure faire sauter le v4 au profit d'un nat/dns64
Km
On Tuesday 06 December 2011 10:07:43 cam.lafit@azerttyu.net wrote:
De ce que je comprends, il existe 2 options a peu près saine : -* gérer du dual stack sur l'ensemble de son infrastructure -* monter un nat/dns64
En règle générale, t'a plein de méthodes pour la compatibilité v4/v6 (tunnels, proxys, NAT, ...), faut "juste" choisir la/les bonnes. L'avantage c'est que les 3/4 du temps t'a surtout besoin du HTTP, et que les (reverse)proxys HTTP ça marche très bien, et souvent t'a pas besoin d'en mettre en place car t'en a déjà.
De ce que j'ai compris aussi la solution dns/nat64 ne garantit pas une simple conversion 1 ipv4 ==> 1 ipv6. Je n'ai pas encore lu assez les documents remontés pour comprendre pourquoi ce n'est pas si simple que ça.
340 sextillions d'IPv6 pour 4 milliards d'IPv4, c'est un bon argument non ? :P
Je me dit que dans l'immédiat le compris serait de déployer du dualstack sur l'ensemble de l'infrastructure et puis au fur et à mesure faire sauter le v4 au profit d'un nat/dns64
Ouais mais non, car si jamais tu fais du v4+v6 sur ton réseau, tu fais quand même l'effort de faire du v6, sauf qu'en plus tu continues l'effort de faire du v4 en même temps, alors que tu peux juste laisser la v4 sur les bords pour profiter d'un réseau v6 pur et parfait en interne :)
Ciao
De ce que j'ai compris aussi la solution dns/nat64 ne garanti pas une simple conversion 1 ipv4 ==> 1 ipv6. Je n'ai pas encore lu assez les documents remontés pour comprendre pourquoi ce n'est pas si simple que ça.
340 sextillions d'IPv6 pour 4 milliards d'IPv4, c'est un bon argument non ? :P
Oui j'ai bien compris : c'est pas bijectif. Et on ne peut pas faire entrer tout ipv6 dans ipv4 mais le contraire normalement oui. Si le réseau externe est ipv6 alors le réseau interne (si PI/nat66) est joignable de partout Si le réseau externe est ipv4 on devrait pourvoir associer chaque ipv4 à une ipv6 non ?
Pas de doute c'est pas moi qui fera l'expert en la matière :)
Km
On Tuesday 06 December 2011 15:47:35 cam.lafit@azerttyu.net wrote:
Si le réseau externe est ipv4 on devrait pourvoir associer chaque ipv4 à une ipv6 non ?
Ah, oui dans ce sens là ça marche, c'est même le principe de NAT64 : on map IPv4 derrière un préfixe IPv6 spécifique.
Le 06/12/2011 15:47, cam.lafit@azerttyu.net a écrit :
Oui j'ai bien compris : c'est pas bijectif. Et on ne peut pas faire entrer tout ipv6 dans ipv4 mais le contraire normalement oui. Si le réseau externe est ipv6 alors le réseau interne (si PI/nat66) est joignable de partout
le nat 66 n'a pas de raison d'exister vu le nombre d'ipv6 quasi-illimité
Si le réseau externe est ipv4 on devrait pourvoir associer chaque ipv4 à une ipv6 non ?
heu non plus, le nat64 c'est plutot dans l'idée du nat-pt
Pas de doute c'est pas moi qui fera l'expert en la matière :)
Km _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Bonsoir
2011/12/6 Christophe Dezé christophedeze@wanadoo.fr
le nat 66 n'a pas de raison d'exister vu le nombre d'ipv6 quasi-illimité
Si si, il y a des raisons ( http://www.bortzmeyer.org/6296.html ) même si on préfère l'appeler NPT ;)
On Tuesday 06 December 2011 09:43:30 Snarf wrote:
<snap>
Hey j'ai jamais dit que de déployer IPv6 était une sinécure : il faut choisir son matos avec une extrême attention, et il faut un petit moment pour arrriver à comprendre que même si la datasheet marque "IPv6" le support est quasi- inexistant, alors que si la datasheet ne dit rien ça peut très bien vouloir dire que le support d'IPv6 est aussi bon que celui d'IPv4.
Par contre, oui ça a du sens de faire une infra full-v6, même si ça va amaigrir pas mal le catalogue de produits.
-
cam.lafit＠azerttyu.net -
cd -
Christophe Dezé
-
Eric Ly -
Florian MAURY -
Romain Boissat -
Rémy Sanchez -
Snarf -
Wallace -
Yoann QUERET