C'est pour du Debian 9 ( la dernière version stable quoi )

Merci pour le lien

sur debian 9:

l'interface sera surement enp1s0 au lieu de eth0 (a changer dans les  fichiers donc).
dhclient sera /sbin/dhclient et pas /usr/sbin/dhclient

apres le "sudo systemctl enable dhclient.service", fait un "sudo systemctl start dhclient.service" pour démarrer sans reboot. puis un "sudo systemctl status dhclient.service" pour voir si tu reçoit bien un lease pour le /56 du DUID.
Tu peux consulter le journal du client avec "sudo journalctl -b -u dhclient.service" (le -b = depuis le dernier reboot,  enleve cette option pour voir depuis toujours). c'est tres utile pour voir le renew et/ou des erreurs de DUID.

Comme indiqué dans la doc il faut aussi activé SLAAC dans l'interface. Pour ne pas configurer d'adresse SLAAC, cf la fin de https://documentation.online.net/en/dedicated-server/network/ipv6/slaac (c'est juste un choix ce n'est pas génant d'avoir aussi une IPv6 SLAAC en plus du bloc /56, faut juste pas mélanger les 2).

et les container vont se développer à l'avenir.

C'est surtout que les développeurs actuels, qui travaillent sur les applications de demain, utilisent des containers.

Si avec leur choix foireux les hébergeurs comme OVH, Online,  Ikoula,  etc rendre l'utilisation d'IPv6 avec les containers difficiles voir impossibles (cas d'un /128), les développeurs ne vont pas pousser non plus pour IPv6 et souvent ne vont meme pas tester leur applications avec IPv6... C'est un peu la poule et l’œuf...

Si on veut pour demain un avenir radieux a IPv6 , il faut aider les développeurs maintenant notamment par des infrastructures a destination des développeurs qui soient bien conçues et 'propres' au niveau IPv6.

Bof, l'appli doit juste pouvoir passer un NAT64, pas besoin d'avoir de la vraie compat v6...

bon comme d'hab la théorie et la pratique ... j'ai donc pris un Dedibox en test pour IPv6. le SLAAC marche mais c'est tout et comme déjà discuté c'est très limité.

Impossible de faire fonctionner un /56. Le support d'Online est dessus et c'est a priori déjà escaladé...

J'ai tenté avec Debian et je constate des erreurs dans le tuto qu'ils fournissent. Notamment a la fin de: https://documentation.online.net/fr/dedicated-server/network/ipv6/slaac

Les serveurs compatible SLAAC devront impérativement avoir cette option activée pour que l'IPv6 DUID fonctionne Préfixe IPv6 /48.
Si vous souhaitez desactiver la configuration via SLAAC, vous pouvez rajouter la ligne suivant dans votre configuration réseau: pre-up /sbin/sysctl -w net.ipv6.conf.eth1.accept_ra=0. Assurez-vous de remplacer eth1 par le nom correct de votre interface.

mais accept_ra=0 ca coupe aussi l’établissement du routage car la gateway est obtenue par ca...Le mec qui a écrit cela n'a clairement pas testé sa solution...Ce n'est pas le seul, car je croise pas mal de gens qui confondent accept_ra et autoconf a cause du comportement  par défaut.

Une bonne version serait :
accept_ra=1 (ou 2 si on a des VM ou plusieurs réseaux) - pour obtenir la gateway donc le routage
autoconf=0 - pour pas que l'interface s'autoconfigure une IP

Autre constatation qui montre le peu de soin vis a vis d'IPv6, c'est que ceci ne fonctionne pas si on veut le faire avec https://wiki.debian.org/NetworkConfiguration malgrés leur doc.

On devrait pouvoir faire un truc du genre:

iface eth0 inet6 static
        address 2001:0bc8:xxxx:xxxx::1/64
        netmask 64
        autoconf 0
        accept_ra 1 # ou 2

mais la ligne "autoconf 0" n'est pas considérée donc SLAAC se fait quand meme..on est donc obligé d'utiliser des sysctl dans un pre-up ou dans sysctl.conf

Autre probleme, dhclient arrive bien a obtenir un bail du prefix mais quand il fait cela il 'supprime' les addresses IPv6 déja configurées statiquement sur l'interface si elles sont dans le prefix...du coup on doit utiliser le script de hook dhcp pour reconfigurer l'interface...du coup la doc d'online n'est pas bonne non plus a ce niveau (ou j'ai loupé un truc).

Je tenterais une solution full systemd/networkd quand Online m'aura rendu le serveur (ils l'ont bloqué pour comprendre le problème).

Mais sur Ubuntu a cause de Netplan on sait que cette solution ne'est pas envisageable pour l'instant (ou alors faut virer netplan ce qui n'est pas un mal mais plus vraiment 'une config par défaut') (raison: https://bugs.launchpad.net/netplan/+bug/1771886 )

Bref l'impression que cela donne c'est que quasi personne n'utilise IPv6 chez Online et qu'aussi les devs des OS et logiciels ne testent pas a fond leur trucs sur IPv6...pourtant des softs importants comme Debian et ISC DHCP client...

Merci de ton retour.

La solution proposée par OVH pour l'IPv6 est donc l'exemple à suivre ?

OVH a 2 solutions. leur /128 des VPS est clairement non pas un exemple a suivre.

l'autre c'est un bloc statique /64 ... c'est que sur les dédiés. oui c'est plus simple mais du tout dynamique . OVH n'a pas d'annonce de route via RA et oblige d'utiliser a des gateway avec IP public. par contre OVH préconfigure le block quand ils fournissent l'OS, c'est un plus.

A pres c'est plus une question de 'cible' visée. Le pro qui sait configuré lui-meme IPv6 aura plus de souplesse/sécurité avec Online et son /48 (quand ca marche...).
Pour l'amateur/semi-pro sera plus OVH.

Mais pour les trucs simple (amateur, usage pro simple) aucun des 2 n'est un exemple a suivre... Je préfère Vultr.com qui propose un full /64 avec SLAAC/RA  (on n'est pas obligé de SLAAC l'IP mais on a la gateway automatiquement). bref la meme config qu'on trouve derriere une box comme Orange ou Free. Mais Vultr limite a un /64 ce qui peut réduire les usages aussi (on est obligé de faire du ND proxy pour le VPN par exemple).

mon classement:
  usage grand public: Vultr, OVH, Online
  usage pro/semi-pro: Online, Vultr, OVH

apres si on ne compare que les VPS et pas les dédiés,  OVH et Scaleway/Online sont tout les 2 a la rue avec leur limitation a /128 (et OVH bon dernier car le /128 est statique et pas SLAAC mais Online ne fait pas de reverse donc en fait ils se battent pour le fond du classement...).

Je n'ai testé IPv6 sur d'autre providers/hébergeurs (je mets a part GCP/AWS/Azure c'est pas le meme niveau) et je me méfie de la "théorie" des docs/marketing.

Chez OVH il y a un /64, ce qui est bidon puisqu'on peut pas router de sous-réseaux.

Hum si, ça va de /65 à /127.

Alors oui tu ne peux pas avoir un sous réseau avec de l'autoconf dedans, mais... who cares ?