Donc pour les administrateurs réseaux en amont de ces "grossistes", ça sera plus simple car effectivement, il délègue l'effort de routage à ces "grossistes".
D'après l'exemple d'orange, Orange va avoir 2109 adresses à sa disposition (277 [~=1,5x1023] fois plus que toutes les adresses théoriques ipv4 !)
même 245 est 8192 fois plus gros que toutes les adresses théoriques ipv4.
ça veut dire que la densité des adresses va être très faible, donc une majorité des adresses ne sera jamais affectés, par contre on va se taper la manipulation des 16 octets (ou 32 caractères ascii en hexa [0-9A-F] + les 7 séparateurs ":")°°°.
On voit bien que dans ipv6,
- le protocole prévoit 2 plages 64 bits, une première plage en 264 bits pour le "routage général" vers des organisations, et 264 bits pour le routage interne de ladites organisation, c'est un routage en 2 temps.
- pouvoir identifier chaque serveur/poste client avec une IP unique (suppression du NAT et faciliter les statistiques/filtrage/sécurité en ayant du point à point "pur" et relié à l'origine du protocole à l'adresse MAC).
Pour le premier point, je n'ai rien contre le fait de sortir d'ipv4, mais 264 adresses (16 caractères ascii en hexa [0-9A-F] + les 3 séparateurs ":" ) auraient permis d'avoir un espace d'adressage très large (selon la philosophie ipv6, 2 plages de 32 bits, ou autre répartition exemple : 40+24) et in fine 2128 adresses, ça reste "overkill" °--°
Pour le second point, pour l'exemple typique d'un site web, qui mettrait un serveur web (apache/java/php/.net/votre techno préférée...) directement exposé sur le web (y compris sa vraie IP), sans passer par des couches réseaux (comme un firewall/reverse-proxy/IDS/..).
Donc en pratique, une organisation qui aurait 264 adresses internes (la partie droite des 128bits) , c'est "overkill" aussi, puisqu'elle va forcément mettre une translation entre les adresses internes et externes.
°°° Parce qu'il faut bien saisir cette pu*@n d'adresse à rallonge un jour ou l'autre dans le SI (au moins dans le DNS et dans la conf réseau du serveur, et si le réseau est un peu plus évolué, les plages d'adresses/ip/hostname dans le firewall, reverse-proxy, ...) et il y aura des erreurs de saisies (cf. le point suivant sur les administrateurs "lambda" a qui ça va casser les pieds).
°--° IPV6 a sûrement des avantages pour les "backbones" qui ont a priori de meilleurs administrateurs réseaux que l'entreprise lambda, mais ça va bien emmerder tous les administrateurs réseaux "lambda" au quotidien.
[^] # Re: C'est plus facile de retenir une ipv4 de tête qu'une ipv6...
Posté par darkleon . En réponse au sondage L'IPv6 prendra quand.... Évalué à -1.
Donc pour les administrateurs réseaux en amont de ces "grossistes", ça sera plus simple car effectivement, il délègue l'effort de routage à ces "grossistes".
D'après l'exemple d'orange, Orange va avoir 2109 adresses à sa disposition (277 [~=1,5x1023] fois plus que toutes les adresses théoriques ipv4 !)
même 245 est 8192 fois plus gros que toutes les adresses théoriques ipv4.
ça veut dire que la densité des adresses va être très faible, donc une majorité des adresses ne sera jamais affectés, par contre on va se taper la manipulation des 16 octets (ou 32 caractères ascii en hexa [0-9A-F] + les 7 séparateurs ":")°°°.
En s'étalant comme ça, on va avoir les mêmes problèmes que pour ipv4 ou des larges plages d'adresses ont été réservés au début, et maintenant, on bouche les trous https://xkcd.com/195/ (2006) et plus récent https://bl.ocks.org/vasturiano/8aceecba58f115c81853879a691fd94f
On voit bien que dans ipv6,
- le protocole prévoit 2 plages 64 bits, une première plage en 264 bits pour le "routage général" vers des organisations, et 264 bits pour le routage interne de ladites organisation, c'est un routage en 2 temps.
- pouvoir identifier chaque serveur/poste client avec une IP unique (suppression du NAT et faciliter les statistiques/filtrage/sécurité en ayant du point à point "pur" et relié à l'origine du protocole à l'adresse MAC).
Pour le premier point, je n'ai rien contre le fait de sortir d'ipv4, mais 264 adresses (16 caractères ascii en hexa [0-9A-F] + les 3 séparateurs ":" ) auraient permis d'avoir un espace d'adressage très large (selon la philosophie ipv6, 2 plages de 32 bits, ou autre répartition exemple : 40+24) et in fine 2128 adresses, ça reste "overkill" °--°
Pour le second point, pour l'exemple typique d'un site web, qui mettrait un serveur web (apache/java/php/.net/votre techno préférée...) directement exposé sur le web (y compris sa vraie IP), sans passer par des couches réseaux (comme un firewall/reverse-proxy/IDS/..).
Donc en pratique, une organisation qui aurait 264 adresses internes (la partie droite des 128bits) , c'est "overkill" aussi, puisqu'elle va forcément mettre une translation entre les adresses internes et externes.
°°° Parce qu'il faut bien saisir cette pu*@n d'adresse à rallonge un jour ou l'autre dans le SI (au moins dans le DNS et dans la conf réseau du serveur, et si le réseau est un peu plus évolué, les plages d'adresses/ip/hostname dans le firewall, reverse-proxy, ...) et il y aura des erreurs de saisies (cf. le point suivant sur les administrateurs "lambda" a qui ça va casser les pieds).
°--° IPV6 a sûrement des avantages pour les "backbones" qui ont a priori de meilleurs administrateurs réseaux que l'entreprise lambda, mais ça va bien emmerder tous les administrateurs réseaux "lambda" au quotidien.