C'est effectivement une des raisons, et c'est un truc qui nous concerne nous développeurs car c'est parce que les applications sont tellement mal codées que le NAT64 « brut » a eu besoin d'être suppléé par du 464XLAT : dans les deux cas, ce qui circule sur le réseau de l'opérateur (avant d'arriver aux traducteurs) est de l'IPv6 « pur » (c'est le cas pour presque tout le réseau de Free aujourd'hui, je pense), et le « bénéfice » du 464XLAT c'est uniquement d'apporter un adressage local IPv4 (une re-traduction, en gros) afin de plaire aux hôtes qui ont des outils déficients en IPv6, et présenter une API ancienne aux applications qui ne sont pas capables d'utiliser des sockets correctement. En effet, l'API des sockets a été prévue pour que la transition puisse se faire en douceur, mais dans beaucoup de cas les logiciels sont implémentés à la truelle et font de la merde. Le NAT64, qui aurait pu fonctionner si des socket AF_INET6 étaient simplement directement utilisées (pour les softs IPv6-only qui comptent sur la présence de traducteurs sur le réseau) ou si les softs utilisaient correctement getaddrinfo(3), se plante au point qu'on est obligé de simuler un réseau et une API IPv4 pour faire fonctionner correctement les applis : c'est moche.
C'est le deuxième chantier qui est à mon avis encore gigantesque, après les manques des réseaux de certains opérateurs : faire que les applis et les framework arrêtent de réinventer la roue en ajoutant des couches « d'abstraction » qui collent complètement au modèle d'Internet NATé (ce qui est la cas de toutes les technos citées plus haut) et sont inadaptables à IPv6 au point où on en est obligé d'émuler IPv4 pour que ça « marche » (pour les « clients » seulement, car le 464XLAT pour les serveurs, ça n'est pas trop ça, il faudra faire autre chose).
[^] # Re: Pour ce que ça change...
Posté par benoar . En réponse au journal Fini l'obligation de compatibilité IPv6 par la loi. Évalué à 3.
C'est effectivement une des raisons, et c'est un truc qui nous concerne nous développeurs car c'est parce que les applications sont tellement mal codées que le NAT64 « brut » a eu besoin d'être suppléé par du 464XLAT : dans les deux cas, ce qui circule sur le réseau de l'opérateur (avant d'arriver aux traducteurs) est de l'IPv6 « pur » (c'est le cas pour presque tout le réseau de Free aujourd'hui, je pense), et le « bénéfice » du 464XLAT c'est uniquement d'apporter un adressage local IPv4 (une re-traduction, en gros) afin de plaire aux hôtes qui ont des outils déficients en IPv6, et présenter une API ancienne aux applications qui ne sont pas capables d'utiliser des sockets correctement. En effet, l'API des sockets a été prévue pour que la transition puisse se faire en douceur, mais dans beaucoup de cas les logiciels sont implémentés à la truelle et font de la merde. Le NAT64, qui aurait pu fonctionner si des socket AF_INET6 étaient simplement directement utilisées (pour les softs IPv6-only qui comptent sur la présence de traducteurs sur le réseau) ou si les softs utilisaient correctement getaddrinfo(3), se plante au point qu'on est obligé de simuler un réseau et une API IPv4 pour faire fonctionner correctement les applis : c'est moche.
C'est le deuxième chantier qui est à mon avis encore gigantesque, après les manques des réseaux de certains opérateurs : faire que les applis et les framework arrêtent de réinventer la roue en ajoutant des couches « d'abstraction » qui collent complètement au modèle d'Internet NATé (ce qui est la cas de toutes les technos citées plus haut) et sont inadaptables à IPv6 au point où on en est obligé d'émuler IPv4 pour que ça « marche » (pour les « clients » seulement, car le 464XLAT pour les serveurs, ça n'est pas trop ça, il faudra faire autre chose).