Bon, je ne peux pas m'empêcher de commencer le panel maintenant. :)
Le 2013-09-20 10:24, Stephane Bortzmeyer a écrit :
L'idée du CGN (un terme marketing, qu'il vaudrait mieux remplacer par NAT 444 pour « deux NAT sur le trajet d'un paquet IPv4 »)
1. CGN est un terme qui a été voté en désespoir de cause par le working-group BEHAVE. Il y avait plusieurs belles propositions du genre Large-Scale NAT, Multi-User NAT, etc. Mais le fait était que CGN était déjà un terme populaire et bien compris, alors on l'a gardé. Le marketing a gagné.
2. CGN n'implique pas NAT444. Voir la définition ici: http://tools.ietf.org/html/rfc6888#section-2 En particulier ce contre-exemple: Another possible topology is one for hotspots, where there is no customer premise or customer premises equipment (CPE), but where a CGN serves a bunch of customers who don't trust each other; hence, fairness is an issue. One important difference with the previous topology is the absence of a second layer of NAT. This, however, has no impact on CGN requirements since they are driven by fairness and robustness in the service provided to customers, which applies in both cases.
est de faire beaucoup d'efforts et de dépenser beaucoup d'argent pour ne *pas* migrer vers IPv6. Au lieu de déployer IPv6, ce qui simplifierait beaucoup les choses, notamment pour les applications,
Les ISPs sont coincés (peut-être qu'ils ont une part de responsabilité). Ils n'ont pas le pouvoir de migrer toutes les applications et tous les fournisseurs de contenu à IPv6. Donc ils *doivent* continuer de fournir de l'IPv4 à leurs clients. La migration à IPv6 a peu de chose à voir avec ça. Un ISP ayant migré tous ses clients à IPv6 doit toujours leur fournir de l'IPv4. CGN est un moyen pour le faire.
Soyons optimistes, il y a eu des améliorations entre les tests de 2010 et ceux de 2011, notamment grâce à l'utilisation plus fréquente de STUN ou de relais permettant de contourner les problèmes du NAT. Le RFC ne parle pas de l'aspect économique mais je note que, lorsqu'on évalue le coût des CGN, il faut voir que c'est aux auteurs d'application de payer pour les FAI, en augmentant la complexité de leurs applications pour contourner les obstacles.
...tout comme ils doivent payer pour porter leurs applications à IPv6. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
