Alexandre Archambault a écrit :
Selon Steven Le Roux le 7/11/07 14:48:
Sinon Fred (ou Rani), tu dis que c'est buggué, vous avez expérimenté ça en
interne ? quel troubles d'usage rencontrez vous ?
Cela a déjà été dit et redit. Que c'est pour l'instant pas vraiment
réplicable à large échelle (scalable). En gros, cela revient à créer encore
plus de problèmes (pas nécessairement techniques, mais surtout
opérationnels, logistiques, financiers...) que c'était censé en résoudre.
Et comme ici c'est plutôt le modèle de la Ford T (un seul modèle, une seule
couleur, et hop, des millions d'exemplaires pour en faire un bien simple et
fonctionnel accessible au plus grand nombre), mieux vaut rester sur ce qui
fonctionne le moins mal plutôt que de se pignoler sur des usines à gaz comme
le relevait Dave Burstein il y a peu.
Comme le disaient d'autres, tant que la demande ne sera pas là pour
justifier de délaisser d'autres trucs qui pour l'instant sont objectivement
un peu plus prioritaires, on (ie au niveau macro) se satisfait pleinement de
l'existant.
Alec,
Quel enfer ce fil.
Chez moi, je gère un /19 saturé et le RIPE me pose bien des soucis
administratif pour obtenir un autre /19 en IPv4.
En outre, je gère autant de téléphones IP et autant de IPSTB et pour ces
deux classes d'objets, je préfére de loin les administrer en IPv6 : Pas
de STUN, pas de NAT, un plan IP cohérent sans recoupement, etc.
Penser que l'adresse EUI des objets correspondent directement à
l'adresse IPv6, c'est du point de vue administratif un sacré bonne idée.
Franchement, j'enseigne IPv6 en école d'ingénieur, je le pratique depuis
des années et je n'y trouve que des avantages.
ICMPv6 qui englobe à lui seul ICMP, ARP et IGMP, c'est aussi une sacrée
bonne idée.
Alors oui, vive IPv6.
PS : si vous voulez un serveur sur une réseau IPv6 public, vous pouvez
me contacter.
