> > > > Ceci dit, je ne suis pas convaincu même par DS-Lite; ça a les mêmes ennuis > si ce n'est pire qu'un CGN v4, surtout en matière de logs. Bonjour l'usine à > gaz pour loguer quelle adresse v4 tu donnes à un client à travers IPv6 et > retransformes en IPv4 public quelque part ailleurs. > > +1 Cout de la mise en place d'IPv6 sur le réseau : 10 Cout du log du CGN : 10E(beaucoup) Tu donnes de la connectivité en v6, tu conserves la connectivité en v4 ... mais a quel prix ? (les opérateurs mobiles le savent bien, puisque peu d'APN sont en v4 publique, en général c'est du prive + CGN)
Attention a un truc tout de meme : le CGN qu'on peut faire dans le cas de DSLite n'est pas du vrai CGN, il est un peu plus intelligent que ça. L'AFTR (truc qui finit le tunnel DSLite) gère un NAT enrichi par un champ : l'IPv6 sur laquelle a été initiée le tunnel. Ce qui fait qu'on peut logguer un truc du style <hh:mm:ss> <ipv4 privee + ipv6 du tunnel ==> ipv4 publique>. Cela etant dit dans le cas d'une requisition judiciaire, tu as toujours 1 IPv4 publique = N clients, donc après il faut s'en sortir avec de l'inspection de service, et la on tombe dans des solutions de DPI etc. A noter aussi que le NAT dans le cas du DSLite est optionnel, et qu'on peut bien mapper directement du trafic en v4 public. Interet ? Sur un reseau FAI, offrir de la connectivite v4+v6, et pour les 10% de clients "geek" offrir un service d'IPv4 publique dédiée. Ok c'est quand même une régression, mais bon, on se console comme on peut ... Apres, on ne parle plus de mécanisme de transition pour DSLite mais bien d'un mécanisme de gestion du manque de v4 publique... On est loin du dual-stack ! Et pour les gens qui codent dans le kernel, le truc marrant avec DSLite, c'est que la stabilite de la pile v4 depend directement de la stabilite de la pile v6. Autrement dit, a chaque développement, tu touches a la pile v6 = tu dois re-valider tout le fonctionnement de la pile v4 = joie !
