Je fais un nouveau sujet car vu les retours en privé, je pense qu'il y a de quoi dire encore et cela devrait intéresser d'autres personnes.
Déjà merci pour vos remerciements en privé, à croire que le sujet est tellement délicat que recueillir un peu d'information parait bénéfique à tous.
Pour continuer la discussion, - en réponse à Denis qui me dit être content de voir des personnes qui n'ont pas peur d'ipv6, j'ai eu un déclic tout bête mais quand je relis mes bouquins ipv6 ou les cours il y a 10 ans cela n'était pas le même discours. C'est simplement les assignations de subnet.
Pour ceux qui ont été sensibilisé à l'ipv6, on a tous entendu, "faut attribuer un /64 minimum à chaque serveur" Du coup on pense organisation de routage alors que non c'est complètement faux. Il faut voir cela autrement.
Cela vient du fait qu'effectivement quand on prend un serveur dédié chez Toto hébergement, on a toujours un /64 attribué au serveur. Mais dans les faits on utilise une ip.
Si on est là pour faire du hosting maitrisé avec infogérance (c'est mon cas). On a affecté un /64 par client comme y a 10 ans où on attribuait des PI /24. Après les serveurs dedans ont une seule adresse ip (c'est déjà pas mal) et font parti du subnet. On ne route pas un subnet vers un serveur comme chez les loueurs de serveurs qui font cela pour pas avoir à gérer vos demandes d'ipv6.
Bref je ne sais plus qui m'avait fait faire ce déclic, qu'il en soit remercié, on enlève toute la problématique routage qu'on m'avait présenté depuis 10 ans. Et là tout devient simple, chaque client à son subnet /64 regroupé dans une allocation plus grande. Après qu'on décide de faire des passerelles dédiées à chaque subnet ou que l'on mette un routage global, chacun son archi.
- pour répondre à Sylvain, oui tout faire en dual stack en se trainant du nat sur le v4 et du routage sur le v6 c'est juste impossible à maintenir sur le long terme ou alors il faut consommer autant d'ipv4 que de v6 pour un serveur si on veut éviter la redirection de ports...
Donc dans les best practices quand je vois dual stack partout en étape, je dis non, c'est trop complexe de maintenir une qualité de service avec les mêmes configurations sur les deux couches.
Pour terminer enfin, je suis technique certes mais je suis aussi le patron, donc quand la technique voit des avantages, le patron est souvent d'accord :D même si ça mange du temps. C'est aussi cela qui aide à franchir le pas, là où un décideur verra l'argent perdu dans cette manipulation... Question de point de vue et de priorité.
Bonjour,
Le 20 nov. 2012 à 17:42, Wallace a écrit :
Pour ceux qui ont été sensibilisé à l'ipv6, on a tous entendu, "faut attribuer un /64 minimum à chaque serveur" Du coup on pense organisation de routage alors que non c'est complètement faux. Il faut voir cela autrement.
Reformulons ! ;) Il faudrait attribuer un /64 minimum par subnet (en pratique tu peux prendre des libertés avec les RFC et rediviser si tu es seul admin sur ton archi et que tu ne fais pas de SLAAC). Or sur les serveurs dédiés classiques le serveur est le seul sur son subnet (VLAN dédié avec le routeur), donc tu as un subnet pour toi tout seul.
Cela vient du fait qu'effectivement quand on prend un serveur dédié chez Toto hébergement, on a toujours un /64 attribué au serveur. Mais dans les faits on utilise une ip.
Définit "on". ;) Tu peux utiliser plusieurs IPs, c'est même une bonne pratique. Pour ma part j'utilise une IP par service: * PFX::25 : Postfix * PFX::53 : Bind * PFX::80 : Apache * PFX::143 : Dovecot Je peux filtrer plus facilement, si je grossis et veux demander une machine supplémentaire sur le même préfixe je ne touche pas au DNS, etc.
Si on est là pour faire du hosting maitrisé avec infogérance (c'est mon cas). On a affecté un /64 par client comme y a 10 ans où on attribuait des PI /24. Après les serveurs dedans ont une seule adresse ip (c'est déjà pas mal) et font parti du subnet. On ne route pas un subnet vers un serveur comme chez les loueurs de serveurs qui font cela pour pas avoir à gérer vos demandes d'ipv6.
Justement ils ne routent malheureusement pas un subnet vers le serveur. Ils attribuent le /64 sur le subnet situé entre le serveur et le routeur et envoient des Neighbor Sollicitation pour remplir leur cache. Donc si je comprends bien, tu demandes à la location d'un nouveau serveur quelle IP de leur /64 ils veulent attribuer à leur nouveau serveur ? C'est ... dommage...
Cordialement Emmanuel Thierry
Le 20/11/2012 18:21, Emmanuel Thierry a écrit :
Bonjour,
Le 20 nov. 2012 à 17:42, Wallace a écrit :
Pour ceux qui ont été sensibilisé à l'ipv6, on a tous entendu, "faut attribuer un /64 minimum à chaque serveur" Du coup on pense organisation de routage alors que non c'est complètement faux. Il faut voir cela autrement.
Reformulons ! ;) Il faudrait attribuer un /64 minimum par subnet (en pratique tu peux prendre des libertés avec les RFC et rediviser si tu es seul admin sur ton archi et que tu ne fais pas de SLAAC). Or sur les serveurs dédiés classiques le serveur est le seul sur son subnet (VLAN dédié avec le routeur), donc tu as un subnet pour toi tout seul.
Oui pour les loueurs d'infra c'est normal.
Cela vient du fait qu'effectivement quand on prend un serveur dédié chez Toto hébergement, on a toujours un /64 attribué au serveur. Mais dans les faits on utilise une ip.
Définit "on". ;)
Moi et mes collègues :D
Tu peux utiliser plusieurs IPs, c'est même une bonne pratique. Pour ma part j'utilise une IP par service:
- PFX::25 : Postfix
- PFX::53 : Bind
- PFX::80 : Apache
- PFX::143 : Dovecot
Je peux filtrer plus facilement, si je grossis et veux demander une machine supplémentaire sur le même préfixe je ne touche pas au DNS, etc.
C'est une façon de voir. Par contre demander une machine sur le même préfix, je n'ai pas vu cette possibilité chez Online, OVH, Heptzner tu as forcément un nouveau subnet par serveur sauf dans le cas du vrack OVH. C'est d'ailleurs pour cela qu'ipv6 ne décolle pas sur les dédiés, il n'y a pas possibilité de basculer les ip, donc gros plantage à prévoir en cas de panne matériel.
Si on est là pour faire du hosting maitrisé avec infogérance (c'est mon cas). On a affecté un /64 par client comme y a 10 ans où on attribuait des PI /24. Après les serveurs dedans ont une seule adresse ip (c'est déjà pas mal) et font parti du subnet. On ne route pas un subnet vers un serveur comme chez les loueurs de serveurs qui font cela pour pas avoir à gérer vos demandes d'ipv6.
Justement ils ne routent malheureusement pas un subnet vers le serveur. Ils attribuent le /64 sur le subnet situé entre le serveur et le routeur et envoient des Neighbor Sollicitation pour remplir leur cache. Donc si je comprends bien, tu demandes à la location d'un nouveau serveur quelle IP de leur /64 ils veulent attribuer à leur nouveau serveur ? C'est ... dommage...
Les serveurs que l'on propose à nos clients font forcément partie d'une offre de service plus large, donc on est responsable de leurs infrastructures, de leurs machines (infogérance), des liens réseaux, ... Donc dans les projets on décide d'un point de vue architecture des besoins en ip.
Le 21 nov. 2012 à 11:54, Wallace a écrit :
Le 20/11/2012 18:21, Emmanuel Thierry a écrit :
Tu peux utiliser plusieurs IPs, c'est même une bonne pratique. Pour ma part j'utilise une IP par service:
- PFX::25 : Postfix
- PFX::53 : Bind
- PFX::80 : Apache
- PFX::143 : Dovecot
Je peux filtrer plus facilement, si je grossis et veux demander une machine supplémentaire sur le même préfixe je ne touche pas au DNS, etc.
C'est une façon de voir. Par contre demander une machine sur le même préfix, je n'ai pas vu cette possibilité chez Online, OVH, Heptzner tu as forcément un nouveau subnet par serveur sauf dans le cas du vrack OVH. C'est d'ailleurs pour cela qu'ipv6 ne décolle pas sur les dédiés, il n'y a pas possibilité de basculer les ip, donc gros plantage à prévoir en cas de panne matériel.
En effet. Par contre sur votre infra ça pourrait avoir du sens.
Justement ils ne routent malheureusement pas un subnet vers le serveur. Ils attribuent le /64 sur le subnet situé entre le serveur et le routeur et envoient des Neighbor Sollicitation pour remplir leur cache. Donc si je comprends bien, tu demandes à la location d'un nouveau serveur quelle IP de leur /64 ils veulent attribuer à leur nouveau serveur ? C'est ... dommage...
Les serveurs que l'on propose à nos clients font forcément partie d'une offre de service plus large, donc on est responsable de leurs infrastructures, de leurs machines (infogérance), des liens réseaux, ... Donc dans les projets on décide d'un point de vue architecture des besoins en ip.
Après si jamais vous vous arrangez de mettre toutes les machines d'un même client sur le même switch et le même routeur (donc le même lien) ou au pire sur le même VLAN, ça reste tout à fait propre. Je n'avais pas compris, je croyais que vous redécoupiez leur /64 en différents subnet et ça c'est moins propre (je veux dire quand on peut l'éviter c'est mieux ! ;)).
Cordialement Emmanuel Thierry
Le 21/11/2012 13:28, Emmanuel Thierry a écrit :
Après si jamais vous vous arrangez de mettre toutes les machines d'un même client sur le même switch et le même routeur (donc le même lien) ou au pire sur le même VLAN, ça reste tout à fait propre. Je n'avais pas compris, je croyais que vous redécoupiez leur /64 en différents subnet et ça c'est moins propre (je veux dire quand on peut l'éviter c'est mieux ! ;)).
Un /64 ça se redécoupe sans soucis, ce n'est qu'une best practice. /64 pour un client final même si on découpe ça reste très propre. En fait le /64 minimum c'est surtout pour permettre de mettre l'adresse mac en autoconfiguration derrière le préfix, de pouvoir mettre un ipv4 transformée en v6 (même là un /64 c'est trop grand).
Pour le moment on a qu'un /56, on a de la marge le temps qu'ipv6 décolle et comme on se concentre au début du bloc (plusieurs /64 au début du /56) pour le moment, on aura la possibilité de migrer à loisir vers d'autres subnet si besoin.
On Tue, Nov 20, 2012, at 17:42, Wallace wrote:
Si on est là pour faire du hosting maitrisé avec infogérance (c'est mon cas). On a affecté un /64 par client comme y a 10 ans où on attribuait des PI /24.
Comme nous ne sommes plus il y a 10ans, vaut mieux allouer un /56 par client "standard", voir un /48 si le client est "suffisamment grand" (chacun est libre de definir ca).
Ca permet : - d'avoir plusieurs subnets par client. chaque subnet = 1 x /64 (subnet, pas serveur) - de mieux gerer l'espace d'addressage - de mieux gerer la securite par client. - d'avoir de la marcge pour l'eventuelle croissance de l'archi du client.
Dans le cas improbable ou tu arrives a "griller" tout ton /32, avec enormement de clients (un /32 = 16M x /56 = 64K x /48, donc......), tu peux toujours demander un deuxieme, alouer un /56 par client est suppose passer sans probleme (c'est juste qu ca n'a du jamais arriver a personne).
Bref je ne sais plus qui m'avait fait faire ce déclic, qu'il en soit remercié, on enlève toute la problématique routage qu'on m'avait présenté depuis 10 ans. Et là tout devient simple
Il y a plusieurs choses dans l'IPv6 dont il faut oublier parfois qu'ils existent pour que les choses deviennent simples.
Sinon, content de savoir qu'il y a aussi d'autres gens qui poussent les choses un peu plus loin. Ca change de l'omnipresent "wait and see".
Le 20/11/2012 23:23, Radu-Adrian Feurdean a écrit :
On Tue, Nov 20, 2012, at 17:42, Wallace wrote:
Si on est là pour faire du hosting maitrisé avec infogérance (c'est mon cas). On a affecté un /64 par client comme y a 10 ans où on attribuait des PI /24.
Comme nous ne sommes plus il y a 10ans, vaut mieux allouer un /56 par client "standard", voir un /48 si le client est "suffisamment grand" (chacun est libre de definir ca).
Ca permet :
- d'avoir plusieurs subnets par client. chaque subnet = 1 x /64
(subnet, pas serveur)
- de mieux gerer l'espace d'addressage
- de mieux gerer la securite par client.
- d'avoir de la marcge pour l'eventuelle croissance de l'archi du
client.
Dans le cas improbable ou tu arrives a "griller" tout ton /32, avec enormement de clients (un /32 = 16M x /56 = 64K x /48, donc......), tu peux toujours demander un deuxieme, alouer un /56 par client est suppose passer sans probleme (c'est juste qu ca n'a du jamais arriver a personne).
C'est un point de vue, mais j'ai constaté que laisser des trous importants d'ip libres ne sert à rien à part pré réserver des millions d'adresses et apporter des erreurs de configurations. Typiquement entre deux adresses où juste un pauvre caractère est changé en plein milieu de l'adresse, cela perturbe tout le monde, les clients, les admsys.
Alors que prendre la première ip disponible dans un seul subnet d'un client c'est tellement plus proche de la pratique actuelle. Après pour ce qui est du routage pour un même client, on peut largement subdiviser un /64. Il y avait eu une très bonne présentation à un FRNog sur le subnetting ipv6 pour un opérateur. Je vais voir à retrouver le lien.
Pour le découpage excessif, certes on a beaucoup de marge, mais je n'ai pas envie de repartir sur un modèle comme à l'époque des PI en ipv4.
Bref je ne sais plus qui m'avait fait faire ce déclic, qu'il en soit remercié, on enlève toute la problématique routage qu'on m'avait présenté depuis 10 ans. Et là tout devient simple
Il y a plusieurs choses dans l'IPv6 dont il faut oublier parfois qu'ils existent pour que les choses deviennent simples.
Y a aussi une chose dont je n'ai pas parlé et qui me semble primordial, c'est la gestion systématique des ip avec un dns. Manipuler les ipv6 à la main c'est juste galère et on arrête pas de se tromper. Pire on arrive pas à les retenir, ça viendra sans doute avec le temps quoique déjà qu'on retient plus les numéros de téléphone avec nos carnets d'adresses. Du coup on fait toute la gestion par dns, on retient que le nom de la machine et on a un modèle de sous domaine par client. La machine client comporte toujours dans son nom le nom ou abréviation du client ce qui fait qu'avec un hostname ou un fqdn on sait toujours à qui appartient la machine.
Sinon, content de savoir qu'il y a aussi d'autres gens qui poussent les choses un peu plus loin. Ca change de l'omnipresent "wait and see".
Comme j'ai toujours essayé dans mes précédentes entreprises de pousser les évolutions technologiques plutôt que de les subir et que cela n’avançait jamais, à présent c'est moi qui décide c'est donc beaucoup plus simple à gérer.
Bonjour,
Le 21 nov. 2012 à 13:26, Wallace a écrit :
Le 20/11/2012 23:23, Radu-Adrian Feurdean a écrit :
On Tue, Nov 20, 2012, at 17:42, Wallace wrote:
Si on est là pour faire du hosting maitrisé avec infogérance (c'est mon cas). On a affecté un /64 par client comme y a 10 ans où on attribuait des PI /24.
Comme nous ne sommes plus il y a 10ans, vaut mieux allouer un /56 par client "standard", voir un /48 si le client est "suffisamment grand" (chacun est libre de definir ca).
Ca permet :
- d'avoir plusieurs subnets par client. chaque subnet = 1 x /64
(subnet, pas serveur)
- de mieux gerer l'espace d'addressage
- de mieux gerer la securite par client.
- d'avoir de la marcge pour l'eventuelle croissance de l'archi du
client.
Dans le cas improbable ou tu arrives a "griller" tout ton /32, avec enormement de clients (un /32 = 16M x /56 = 64K x /48, donc......), tu peux toujours demander un deuxieme, alouer un /56 par client est suppose passer sans probleme (c'est juste qu ca n'a du jamais arriver a personne).
C'est un point de vue, mais j'ai constaté que laisser des trous importants d'ip libres ne sert à rien à part pré réserver des millions d'adresses et apporter des erreurs de configurations. Typiquement entre deux adresses où juste un pauvre caractère est changé en plein milieu de l'adresse, cela perturbe tout le monde, les clients, les admsys.
Je vais expliquer ce que j'ai cru comprendre de la bonne pratique du /64 par subnet (hormis les IX dont il est recommandé qu'ils utilisent des /127). A vrai dire même mon opinion personnelle penchait auparavant pour toujours diviser un /64 quelque soient les circonstances, je suis moins catégorique maintenant. Déjà ce n'est pas pour réserver des milliards d'adresses que la pratique du /64 par subnet est optée, c'est plutôt pour assurer une cohérence dans le routage. L'une des hantises avouée du RIPE NCC (sans être membre, il suffit de lire les documents publics) est de s'assurer que le déploiement d'IPv6 ne pollue pas les tables de routage comme cela peut être le cas aujourd'hui avec la désagrégation des préfixes IPv4. Pour cela, il faut une politique unique, quelque soit le cas d'usage (réseau résidentiel ou serveurs). Avec une taille minimale des PI IPv6 à /48 et une taille minimale des PA IPv6 à /32, on s'attend donc que la granularité du routage soit dans ces eaux là. Si sur une plateforme tu assignes un /64 par client et que pour une raison ou une autre un jour tu veuilles migrer ce client vers une autre plateforme ou un autre AS tu seras a priori obligé de polluer les tables de routages de tes peers (a vrai dire je ne suis même pas sûr que quand IPv6 sera réellement déployé ce genre d'annonces seront acceptées).
Ensuite on peut aussi considérer cette pratique par rapport à du firewalling ou du blacklisting. La granularité minimale acceptable du blacklisting en IPv6 est le /64, car c'est le plus grand préfixe à partir duquel tu peux être à peu près certain (par rapport aux standards) qu'il appartient ou est contrôlé par une entité unique (utilisateur pour le cas d'une connexion résidentielle, sysadmin pour le cas d'un serveur), donc tu peux te faire plaisir à bannir le /64 entier. A noter que l'on pourrait choisir de blacklister des /128 mais dans ce cas c'est courir le risque de se faire DoS son firewall avec une simple connexion Freebox (2^64 règles de firewall ça fait mal ! ;)). Par conséquent, si l'un des serveurs du /64 se fait compromettre tous seront blacklistés (notamment pour des MX). C'est moins grave dans ton cas vu que c'est un /64 par client unique. C'est inadmissible par contre dans le cas de Amen qui à voir leur site offre 2 adresses (!!!) IPv6 par serveur (j'attends la confirmation du service client que ce sont bien 2 /128).
Pour résumer, je paraphraserais un collègue qui me disait "en IPv6 il faut réapprendre à gaspiller", ce que je commence à comprendre. On considère par convention (et par standard) que les 64 premiers bits de l'adresse sont réservés au réseau et les /64 derniers bits sont dévolus à l'hôte. Pour cela, l'équivalent d'un /24 IPv4 n'est pas un /64 IPv6 mais plutôt un /48 IPv6. On aurait un truc du genre: /12 IPv6 <=> /8 IPv4 (allocations RIR) /32 IPv6 <=> /16 - /22 IPv4 (allocations PA) /48 IPv6 <=> /24 IPv4 (assignations PI) /64 IPv6 <=> /32 IPv4 (hôte) A ce titre les assignations d'IPv6 sur les dédibox (/48) paraissent par contre un peu démesurées Note que je ne cherche pas à critiquer ton setup, je fais exactement le même genre de choses dans certains cas, par contre c'est un adressage qui je pense peut avoir ses limites.
Au passage si tu veux discuter de ton point de vue le G6 accueille les opérateurs et administrateurs système les bras ouverts ! ;)
Il y avait eu une très bonne présentation à un FRNog sur le subnetting ipv6 pour un opérateur. Je vais voir à retrouver le lien.
Ca m'intéresse ! :)
Cordialement. Emmanuel Thierry
Le 22/11/2012 11:14, Emmanuel Thierry a écrit :
Il y avait eu une très bonne présentation à un FRNog sur le subnetting ipv6 pour un opérateur. Je vais voir à retrouver le lien. Ca m'intéresse ! :)
Hop retrouvé
message ici http://www.mail-archive.com/frnog@frnog.org/msg14362.html document là http://www.as8218.eu/frnog-ipv6-subnetting.pdf
Le jeudi 22 novembre 2012 à 18:59, Wallace écrivait:
Hop retrouvé message ici http://www.mail-archive.com/frnog@frnog.org/msg14362.html document là http://www.as8218.eu/frnog-ipv6-subnetting.pdf
Le redacteur de la-dite prez vient de me souffler dans l'oreillette que la version sur as8218.net n'est pas maintenue et qu'il faut allez là pour la version kivabien http://www.maunier.fr/tech/ipv6-subnetting
Le PDF est le même, mais les mises à jour seront faites sur ce site
F.
Le 22/11/2012 19:09, Snarf a écrit :
Le redacteur de la-dite prez vient de me souffler dans l'oreillette que la version sur as8218.net n'est pas maintenue et qu'il faut allez là pour la version kivabien http://www.maunier.fr/tech/ipv6-subnetting Le PDF est le même, mais les mises à jour seront faites sur ce site F.
Super merci pour l'info!
Le 22/11/2012 11:14, Emmanuel Thierry a écrit :
Je vais expliquer ce que j'ai cru comprendre de la bonne pratique du /64 par subnet (hormis les IX dont il est recommandé qu'ils utilisent des /127). A vrai dire même mon opinion personnelle penchait auparavant pour toujours diviser un /64 quelque soient les circonstances, je suis moins catégorique maintenant. Déjà ce n'est pas pour réserver des milliards d'adresses que la pratique du /64 par subnet est optée, c'est plutôt pour assurer une cohérence dans le routage. L'une des hantises avouée du RIPE NCC (sans être membre, il suffit de lire les documents publics) est de s'assurer que le déploiement d'IPv6 ne pollue pas les tables de routage comme cela peut être le cas aujourd'hui avec la désagrégation des préfixes IPv4. Pour cela, il faut une politique unique, quelque soit le cas d'usage (réseau résidentiel ou serveurs). Avec une taille minimale des PI IPv6 à /48 et une taille minimale des PA IPv6 à /32, on s'attend donc que la granularité du routage soit dans ces eaux là. Si sur une plateforme tu assignes un /64 par client et que pour une raison ou une autre un jour tu veuilles migrer ce client vers une autre plateforme ou un autre AS tu seras a priori obligé de polluer les tables de routages de tes peers (a vrai dire je ne suis même pas sûr que quand IPv6 sera réellement déployé ce genre d'annonces seront acceptées).
Alors oui cela peut se comprendre pour la table de routage, quand on voit le prix de la ram pour un routeur qui est vraiment abusé, j'imagine pas la full view internet v6 dans 50 ans ou plus ...
Néanmoins mon constat est que le réseau n'aime pas déjà à l'heure actuelle couper des blocs et les annoncer à droite à gauche sur un même réseau. Si le routage simple n'est pas possible c'est changement d'adressage. Pour ce qui est d'un client qui partirait avec son subnet chez un autre prestataire, je ne suis pas non plus obligé de lui fournir une PI ipv6 dans mon bloc principal. Je doute que si on demande à un loueur d'infra de router notre bloc v6 ailleurs il accepte.
La mobilité des ipv6 pour moi c'est sur des AP pour des personnes, pas pour des serveurs. D'ailleurs il me semble que la norme pour prévoir la mobilité n'est pas encore au point et refusé par pas mal de monde.
Donc vis à vis de ce redécoupage, je pense pas être gêné, au pire j'attribue un nouveau subnet pour des manips ou une migration.
Ensuite on peut aussi considérer cette pratique par rapport à du firewalling ou du blacklisting. La granularité minimale acceptable du blacklisting en IPv6 est le /64, car c'est le plus grand préfixe à partir duquel tu peux être à peu près certain (par rapport aux standards) qu'il appartient ou est contrôlé par une entité unique (utilisateur pour le cas d'une connexion résidentielle, sysadmin pour le cas d'un serveur), donc tu peux te faire plaisir à bannir le /64 entier. A noter que l'on pourrait choisir de blacklister des /128 mais dans ce cas c'est courir le risque de se faire DoS son firewall avec une simple connexion Freebox (2^64 règles de firewall ça fait mal ! ;)). Par conséquent, si l'un des serveurs du /64 se fait compromettre tous seront blacklistés (notamment pour des MX). C'est moins grave dans ton cas vu que c'est un /64 par client unique. C'est inadmissible par contre dans le cas de Amen qui à voir leur site offre 2 adresses (!!!) IPv6 par serveur (j'attends la confirmation du service client que ce sont bien 2 /128).
Là effectivement y a un gros risque. Mais apprendre à gaspiller c'est revenir dans les années 80/90 et penser qu'un /8 ipv4 serait trop petit pour un réseau de machines (sans virtualisation).
Pour résumer, je paraphraserais un collègue qui me disait "en IPv6 il faut réapprendre à gaspiller", ce que je commence à comprendre. On considère par convention (et par standard) que les 64 premiers bits de l'adresse sont réservés au réseau et les /64 derniers bits sont dévolus à l'hôte. Pour cela, l'équivalent d'un /24 IPv4 n'est pas un /64 IPv6 mais plutôt un /48 IPv6. On aurait un truc du genre: /12 IPv6 <=> /8 IPv4 (allocations RIR) /32 IPv6 <=> /16 - /22 IPv4 (allocations PA) /48 IPv6 <=> /24 IPv4 (assignations PI) /64 IPv6 <=> /32 IPv4 (hôte)
Oui ça c'est ce que le l'on voit partout. Mais bonjour la gestion ipma ... mais aussi la sécurité. Truc tout bête la plupart des gens vont mettre une ipv6 par machine, à tous les coups elle va finir par :1 Pour scanner un réseau suffira de prendre tous les /64 possible et tester la :1 pour savoir le nombre d'os derrière?
Cette vue me gêne et me dérange dans la gestion, dans le quotidien, ... aucune chance d'apprendre à retenir un préfix ...
A ce titre les assignations d'IPv6 sur les dédibox (/48) paraissent par contre un peu démesurées Note que je ne cherche pas à critiquer ton setup, je fais exactement le même genre de choses dans certains cas, par contre c'est un adressage qui je pense peut avoir ses limites.
Oui on discute :) au final le but est aussi d'agir, si je suis pas clean sur les précos mais qu'au moins le service est délivré en v6 alors j'ai déjà fait avancer la chose. Au moins on aura de la place pour refaire l'adressage si besoin plus tard, on ferra pas comme un client y a quelques années qui a changer l'avant dernier digit de son /24 ipv4 pour ré-adresser ses machines avant de revenir sur son subnet, sans mesurer les conséquences bgp ...
Au passage si tu veux discuter de ton point de vue le G6 accueille les opérateurs et administrateurs système les bras ouverts ! ;)
Il faudrait y penser :) on va déjà expérimenter un peu, sans doute apprendre de nos erreurs et on verra bien ce que l'on peut apporter ou pas. Sachant que des personnes sont dessus depuis plus de 15 ans, ils ont du faire le tour de toutes les questions avant nous, faut juste tenter d'en savoir un peu plus.
On 22/11/2012 19:12, Wallace wrote:
Néanmoins mon constat est que le réseau n'aime pas déjà à l'heure actuelle couper des blocs et les annoncer à droite à gauche sur un même réseau. Si le routage simple n'est pas possible c'est changement d'adressage.
C'est un constat en v6 ? Parce que les recommandations du Ripe sont que les /48 soient routables et à ce que j'ai lu sur les listes d'opérateurs, c'est le cas chez la très vaste majorité des opérateurs.
Pour ce qui est d'un client qui partirait avec son subnet chez un autre prestataire, je ne suis pas non plus obligé de lui fournir une PI ipv6 dans mon bloc principal.
Il y a contradiction entre "PI" et "dans mon bloc principal".
En IPv4 la technique classique et normale de multihoming d'un FAI (par exemple) était qu'il annonce son bout de PA avec son AS à ses transitaires. Je n'ai vu aucune documentation qui indique que cette politique du Ripe ait changé.
Je doute que si on demande à un loueur d'infra de router notre bloc v6 ailleurs il accepte.
Un loueur d'infra je ne sais pas, mais un commercial vendeur de transit j'en suis moins sur. Assez probable que j'essaie prochainement, je tâcherai de penser à vous faire un retour.
Sachant que des personnes sont dessus depuis plus de 15 ans, ils ont du faire le tour de toutes les questions avant nous, faut juste tenter d'en savoir un peu plus.
Il y a une "best current opérational practices", ratifiée au Nanog 54 et qui donc émane de gens plutôt dans le coup, probablement une bonne référence.
Le 22 nov. 2012 à 19:12, Wallace wallace@morkitu.org a écrit :
Le 22/11/2012 11:14, Emmanuel Thierry a écrit :
A ce titre les assignations d'IPv6 sur les dédibox (/48) paraissent par contre un peu démesurées Note que je ne cherche pas à critiquer ton setup, je fais exactement le même genre de choses dans certains cas, par contre c'est un adressage qui je pense peut avoir ses limites.
Oui on discute :) au final le but est aussi d'agir, si je suis pas clean sur les précos mais qu'au moins le service est délivré en v6 alors j'ai déjà fait avancer la chose.
Sur ce point je suis entièrement d'accord. Et c'est suffisamment rare pour qu'on le souligne !
Au passage si tu veux discuter de ton point de vue le G6 accueille les opérateurs et administrateurs système les bras ouverts ! ;)
Il faudrait y penser :) on va déjà expérimenter un peu, sans doute apprendre de nos erreurs et on verra bien ce que l'on peut apporter ou pas.
A vrai dire il y a pour le moment plus d'académiques que d'opérationnels, on aime bien avoir des retours et des discussions des gens qui font de la prod. D'ailleurs c'est marrant on retrouve exactement le même genre de discussions sur ipv6tech@g6.asso.fr ! ;)
Cordialement Emmanuel Thierry
-
Emmanuel Thierry -
Radu-Adrian Feurdean -
Snarf -
Sylvain Vallerot -
Wallace