Le 22/04/2014 09:04, Stephane Bortzmeyer a écrit :
[...]
Mais le NAT a de nombreux inconvénients et l'un des buts d'IPv6
était justement de s'en débarasser (ceci dit, si vous voulez tenter
l'aventure, il existe un RFC sur ce sujet, le RFC 6296, cf. section
7.1).
(c'est la 7.1 du RFC7157, juste pour clarification).
Au sujet du NAT IPv6 (non pas NPT "Network Prefix Translation") il
existe un RFC5902 de l'IAB qui dit en gros combien il est méchant. Le NAT.
Linux kernel implémente IPv6 NAT, et aussi NPT (2 choses différentes), à
utiliser sans modération.
Le NPT n'est pas interdit au point que NAT l'est (il est juste
EXPERIMENTAL, tandis que NAT IPv6 RFC n'existera jamais dire jamais),
mais il a certains inconvénients par rapport au NAT. PAr exemple, si
l'opérateur donne seulement un préfixe /64 alors NPT n'est pas
utilisable en même temps que SLAAC/Ethernet, alors que NAT si.
(p.ex. un opérateur cellulaire donne seulement un /64 au smartphone, et
alors ce smartphone ne peut pas faire du 'tethering' avec NPT, mais il
le peut avec NAT).
Autre solution, faire du beau "multi-homing" propre avec des adresses
PI et BGP. Mais c'est complètement hors de portée de la petite
organisation, notamment par les ressources humaines que cela
nécessite. (Voir le RFC 3582 pour un cahier des charges d'une
solution idéale pour le "multi-homing".)
Je vous le dis tout de suite, il n'existe pas encore de solution
propre et déployable pour ce problème. À court terme, le RFC 6296
reste la seule solution.
Je suis d'accord.
Alex
_______________________________________________
G6 -- Association Francophone pour la promotion d'IPv6 (http://www.g6.asso.fr)
Liste IPv6tech IPv6tech@g6.asso.fr
Info : http://mail.g6.asso.fr/mailman/listinfo/ipv6tech
