Un peu péremptoire. L'IPv6 me sauve littéralement le cul, il n'y a que grâce à ça que je peux auto-héberger ce que j'ai actuellement sur ma connexion chez moi, dont une bon nombre de serveurs/services web qui ont tous besoin du même port.

Pour te dire que si je n'avais pas IPv6 je n'aurais pas pu prendre en main mon RPI ( en remote et pas la porte d'a coté ) dont son IPv4 avait disparu ( problème de DHCP à un moment donné ) 

Les plus gros site du monde n'ont aucun problème, à mon avis c'est que vous ne savez pas parametrer les choses de la bonne façon.
 

Dans ce cas, ne t’encombre pas avec des ULA sauf pour ton VLAN 30. Si ton pare-feu est bien configuré avec toutes les connexions entrantes bloquées (sauf initiées de l’intérieur), tes appareils ne sont pas plus vulnérables avec des GUA.

Les plus gros site du monde n'ont aucun problème, à mon avis c'est que vous ne savez pas parametrer les choses de la bonne façon.
 

Ça n’a absolument aucun rapport avec la problématique que j’ai mentionnée

Pour aider un peu à comprendre les différentes adresses ipv6, j'aime bien cette carte :
https://www.ripe.net/media/documents/ipv6_reference_card.pdf

et surtout merci aux rares qui y ont répondu, sans polluer le forum (j'adore ceux qui disent "ben t'a ka te renseigner", ben oui, c'est exactement ce qu'il fait ici ;-)

Je lis, je m'informe et je fais des tests, mais cela n'est pas suffisant pour tout comprendre. Au moins toi, tu as compris l'utilité d'un forum.

Moi aussi, je cherche à comprendre IPV6.

Je n'ai pas de problème d'IPv6 puisque il est déjà opérationnelle dans mon Debian (ainsi quze l'IPv4) sous "systemd-networkd". Je précise que j'ai transformé mon ordinateur en routeur afin de tester le bypasse de la BOX SFR et c'est opérationnel. J'ai plutôt un problème dans l'organisation de l'adressage IPv6 que je désire implanter dans mon Debian. C'est plus une méconnaissance qu'un problème réel.

J'ai testé "radvd" cette après-midi, ça fonctionne très bien, sauf que c'est du stateless (le SLAAC) et ce n'est pas du tout ce que je recherche. J'avais cru comprendre que l'affectation du préfixe se faisait dynamiquement, par concaténation au suffixe.

Dans mon organisation, je dois gérer deux préfixes (peut être même plus), le premier venant du serveur SFR et qui se nomme "la délégation du préfixe IPv6", ça fonctionne déjà au niveau du routeur. Le seconde étant l'ULA "fe70:abcd:effe:dcba", que je n'ai pas encore implanté. Je n'ai toujours pas compris comment substituer dynamiquement les préfixes dans les serveurs DHCPv6 et DNSv6 alors que ceux-ci sont en dur. Par exemple DNSMASQ, que j'ai déjà utilisé avec mes Raspberry Pi.

Enfin presque, car fe80: etc ne marche pas dans les règles du firewall, il faut mettre la GUA. Oui, mais starlink me change le préfix de temps en temps...

Si je passe par ma BOX SFR pour renseigner le serveur DHCPv4 ainsi que DHCPv6, je n'ai pas le choix, je suis obligé d'utiliser "192.168.1.0/24" ainsi que le préfixe de "la délégation du préfixe IPv6" venant de SFR. Je ne peux pas les modifier.

Avant de mettre en dur "fe80::f000" dans la configuration de NetworkManager de mes Raspberry Pi, j'avais utilisé udev où j'associe l'adresse IP à l'adresse MAC. L'inconvénient de cette méthode est double. Je dois le faire en dur, et le faire dans tous les OS que j'utilise. Pas pratique du tout.

Le but est justement de le centraliser dans le routeur afin que cela soit accessible partout dans le réseau local, de rendre l'affectation du préfixe dynamique, et de ne pas outrepasser les règles du réseau.

@ Mjules : pour ce qui nous intéresse, cela se résume à :
--> 2000/3 pour GUA
--> fc00::/7 pour ULA
--> fe80::/10 pour LLA

@ tous : si quelqu'un pouvait expliquer comment rendre dynamique l'affectation des préfixes, aux suffixes qui sont renseignés dans le serveur DHCPv6, je suis preneur. Merci.

Merci à Artemus24 de poser ces questions, et surtout merci aux rares qui y ont répondu, sans polluer le forum (j'adore ceux qui disent "ben t'a ka te renseigner", ben oui, c'est exactement ce qu'il fait ici ;-)

Tu ne sauras pas le quart de ce qu'il faut en procédant ainsi. De là, aboutir à un bon résultat est irréalisable.
Parole d'autodidacte ! Il faut arrêter de prendre les gens pour des c**ns.

Pourquoi est-ce que vous voulez tous crypter (chiffrer) vos tunnels?

Quelques % de CPU si tu chiffres en chacha-poly ou en AES et tu gagnes:
1) la confidentialité des échanges (on ne voit pas ce qui passe dedans, dont éventuellement les mots de passe dans le cas de HTTP ou de protocoles antiques tels que SMB),
2) l'authenticité de la machine au bout du tunnel,
3) l'intégrité des données qui transitent.

2) et 3) sont liés et sont selon moi importants pour s'assurer que le VPN maintient bien le périmètre de sécurité qu'il est sensé assurer.
Cas pratique il y a un paquet d'années, quand des tunnels 6in4 étaient utilisés pour accéder au réseau IPv6 depuis une connexion n'en fournissant pas, je voyais passer des paquets 6in4 arriver depuis plusieurs sources, non sollicités, qui étaient selon moi des tentatives d'injection de paquets à l'intérieur du tunnel.

Dans ce cas, effectivement, si tout ce qu'on y fait passer est du traffic déjà authentifié et chiffre (par exemple ssh ou https), ce traffic est protégé.
Par contre, il y a toujours possibilité d'injecter du traffic dans ton tunnel pour usurper ton identité (à fins malicieuses/illegales le plus souvent). Et si le traffic n'est pas chiffré et/ou authentifié au niveau applicatif, aïe.

Est-ce que c'est juste le marketing (à gerber) de SurfShark / Nord-VPN / CyberGhost qui déteint sur tout le monde?

Payer pour nordVPN ou autre VPN commercial quand tu vis en europe occidentale, j'ai jamais compris, mais le marketing fait des miracles. De surcroît quand ces utilisateurs surfent avec Google Chrome.

Si c'est juste pour du trafic Internet classique, pour contourner une IPv4 public qui change trop souvent, un VPN non chiffré suffit amplement, ça ne bouffe pas de ressource CPU inutile, ça permet facilement d'atteindre des débits de malade.

Oui, éventuellement si tu maintiens les deux bouts du tunnel, tu peux désactiver le chiffrement. Mais encore une fois, est-ce utile au vu du faible coût CPU et de ce qu'on perd ?
On est assez HS, mais l'époque où l'on pouvait se reposer sur un opérateur pour des services de tunneling/VPN est pour moi révolue. D'une part en termes de sécurité/contrôle, mais aussi parce que mes clients industriels se réveillent tout doucement à la cybersécurité, et qu'ils s'attendent (à raison) que le traffic soit chiffré de bout en bout entre les deux firewalls en leur possession.