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 _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
