On Thu, Sep 05, 2019 at 02:20:38PM +0200, Stephane Bortzmeyer wrote: > On Thu, Sep 05, 2019 at 01:34:19PM +0200, > Nicolas DEFFAYET <nicolas...@deffayet.com> wrote > a message of 195 lines which said: > > > L'IPv6 demande parfois des changements très profonds dans un système > > d'information. Un exemple: dans la base SQL le champ pour stocker > > l'adresse IP n'est pas adapté pour l'adresse IPv6, il faut modifier > > la table dans la base de donnée. > > C'est une affirmation générale, ou bien l'observation d'un cas qui se > produit parfois dans certaines organisations ? Parce que PostgreSQL a > le type INET (adresse IP) depuis au moins dix ans, probablement bien > plus. Évidemment, si le DBA a mis l'adresse IP dans un champ INTEGER, > ça ne marchera pas, mais j'espère que tous les DBA ne font pas de > bếtises comme ça.
Personnellement, et malheureusement, le champ IP, je le vois plus souvent stocké dans un varchar(15) que dans un champ dédié. > > Ensuite il y a la problématique du dual-stack IPv4-IPv6. Le bon sens > > veut que l'on tente d'abord une connection en IPv6 puis en cas > > d'échec on failback en IPv4. Le souci c'est que si le réseau IPv6 > > est défaillant, le failback introduit une certaine latence vu que > > l'on attend un timeout avant de basculer. > > Ceci dit, ce problème a une solution depuis longtemps (RFC 6555, avril > 2012) et qui est effectivement mise en œuvre dans Safari, Firefox, > etc. Comme pour beaucoup de problème en IPv6, il y a des solutions mais à part quelques soft répandu, il y a beaucoup de problème. Cas pratique que j'ai vécu chez moi quand ma connexion IPv6 était cassé, les images twitter ne se chargeaient plus dans l'application Android (les images sont disponible en IPv6 mais le texte...). --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
