Franchement, je n'ai pas l'impression que les services logiciels les plus répandus ne soient pas compatibles IPv6.
Les services « les plus répandus », oui, mais ceux qui créent des services au-dessus et qui cassent tout en les utilisant mal...
Par contre, des opérateurs ou des fournisseurs d'accès qui ne fournissent pas de connectivité IPv6 correcte, ça existe encore
Oui ça c'est vrai que c'est l'autre gros point noir ; je m'y était juste tellement habitué que je n'y fais plus gaffe. Mais ça n'est pas près d'arriver, vu que c'est pour des raisons commerciales : offrir de l'IPv6, c'est ouvrir le marché de se abonnés captifs derrière leur NAT « protecteur »...
Je me doute bien qu'il y a quelques bouts de code de-ci de-là qui ne connaissent que AF_INET, mais ce n'est pas le problème dominant.
C'est le problème dominant de la couche « service » uniquement, mais ça n'est pas rien. C'est également une des excuses des opérateurs : les applications « n'en ont pas besoin », vu que tout est codé pour s'abstraire d'IP à cause des NAT et de réinventer des couches d'abstraction usine à gaz en-dessous.
Corrigeons : très peu de gens se soucient de l'API socket parce qu'ils développent des services réseaux à un plus haut niveau, en se basant sur un canevas logiciel ou au minimum une couche d'abstraction existante. On est en 2017...
Oui, mais souvent ils l'utilisent mal... Par exemple, au-delà des sockets pur, savoir utiliser getaddrinfo() : tu vas me dire que c'est abstrait par les framework, mais non, souvent soit ils ne l'utilisent pas, soient ils l'utilisent mal ; on doit normalement itérer sur les résultats pour jauger la connectivité, pour des raisons de transition, de répartition, et de disponibilité. Encore une fois, ces frameworks veulent souvent abstraire ça et rajouter un couche, et foutent la grouille parce qu'ils n'ont pas compris que seule l'application elle-même peut prendre des décisions sur le choix des destinations en fonction de leur atteignabilité.
[^] # Re: Quand quelqu'un l'aura codé
Posté par benoar . En réponse au journal À quand l’IPv6 sur LinuxFr.org ?. Évalué à -2.
Les services « les plus répandus », oui, mais ceux qui créent des services au-dessus et qui cassent tout en les utilisant mal...
Oui ça c'est vrai que c'est l'autre gros point noir ; je m'y était juste tellement habitué que je n'y fais plus gaffe. Mais ça n'est pas près d'arriver, vu que c'est pour des raisons commerciales : offrir de l'IPv6, c'est ouvrir le marché de se abonnés captifs derrière leur NAT « protecteur »...
C'est le problème dominant de la couche « service » uniquement, mais ça n'est pas rien. C'est également une des excuses des opérateurs : les applications « n'en ont pas besoin », vu que tout est codé pour s'abstraire d'IP à cause des NAT et de réinventer des couches d'abstraction usine à gaz en-dessous.
Oui, mais souvent ils l'utilisent mal... Par exemple, au-delà des sockets pur, savoir utiliser getaddrinfo() : tu vas me dire que c'est abstrait par les framework, mais non, souvent soit ils ne l'utilisent pas, soient ils l'utilisent mal ; on doit normalement itérer sur les résultats pour jauger la connectivité, pour des raisons de transition, de répartition, et de disponibilité. Encore une fois, ces frameworks veulent souvent abstraire ça et rajouter un couche, et foutent la grouille parce qu'ils n'ont pas compris que seule l'application elle-même peut prendre des décisions sur le choix des destinations en fonction de leur atteignabilité.