On peut donc être concernés même si on n'utilise pas directement la virtualisation.

Perso, j'utilise les outils de virtualisation pour pouvoir faire enfin un truc banal depuis des années sous linux: ajouter une carte réseau sur un VLAN tout en conservant la carte principale pour les paquets sans l'entête 802.1q

C'était une galère sans nom quand seuls deux fabricants de cartes réseaux (intel et realtek), permettaient de le faire via un des pilotes spéciaux et une configuration un peu compliquée.

Pour ceux qui se demande pourquoi faire une telle chose, cela permet de circonscrire le traffic SMB au réseau local Ethernet. Ce qui est dans un VLAN n'est pas routé par les box et n'est pas disponible sur le wifi.

Attention de ne pas utiliser le VLAN 100 cependant avec une freebox car c'est celui utilisé entre le serveur et le lecteur multimédia: un préfixe IPv6 global y est annoncé et il est partagé sur le Wifi et les ports Ethernet.

Je suis déjà en full IPv6: sur mes VLAN, l'IPv4 est coupé et j'utilise des préfixes ULA donc je n'ai pas de problème de fuite vers l'extérieur.

le SMB sur IPv6 fonctionne très bien et permet de couper définitivement l’infâme service de nom netbios qui est mécaniquement incompatible IPv6.

Côté serveur, mes machines virtuelles sont quasiment à 100% en IPv6: c'est un mandataire inversé nginx qui reçois les connexions en IPv4 et les retransmet par détection de flux au bon serveur en IPv6 avec le protocole proxy.

Le traffic reste chiffré jusqu'au serveurs finaux car l'aiguillage se fait sur le flux lors de la phase de connexion SSL avec le paquet HELO. Pas besoin de gérer les certificats sur l’hôte.

Il me reste encore une dernière chose à faire pour bouter l'IPv4 de ces machines: mettre en place un NAT64 et un DNS64. Mais tayga est chiant à configurer donc je n'ai pas encore résussi.

C'est cool de lire cela. Je me sent moins seul.
IPv4, c'est le passé, et il est plus que temps de passer à la suite.
De mon côté, je m'active à lui creuser sa tombe et je fêterai dignement son enterrement.

évidemment que j'utilise TLS et au minimum 1.2

Globalement, le message que j'essaye de faire passer est pour ceux qui n'ont pas ton degré de compétences. Je reformule donc:

Avec les modules de type flux de nginx, il est possible de router automatiquement les connexions https vers la bonne destination et le protocole proxy sans sacrifier la confidentialité des échanges.

Le mandataire inverse est capable de déterminer cela à partir du tout premier paquet envoyé par le client https car ce paquet est en clair.

Le protocole proxy permet de transmettre au serveur destinataire l'adresse ip du client et d'autres informations.

Du coup, les flux https IPv4 arrivent au mandataire qui les renvoie en IPv6 au serveurs IPv6 only par protocole proxy sur des adresses ULA. Les flux IPv6 arrivent directement aux serveurs.

Bref, il est possible et même très simple d'arrêter de faire du NAT44 comme des idiots pour des serveurs en conteneurs ou en machines virtuelles en migrants sur IPv6

Je ne connais NTP que pour la synchronisation des horloge et NAT66 à tendance à me faire saigner les yeux.

Je ne comprend pas très bien pourquoi tu cherche à casser l'intérêt d'IPv6 et te limiter en type d'adresses avec du NAT66. Pour information, sous linux, un port réseau peut avoir jusqu'à 16 adresses simultanément (aucune idée pour windows). Tu as au minimum une adresse de lien local qui se crée toute seule et des adresses ULA ou globales qui peuvent être ajoutée de plusieurs manières en même temps.

En laissant IPv6 fonctionner en SLAAC, les mécanismes de roaming intégrés fonts que la transition d'un routeur à un autre en fonction de la qualité de service s'opère automagiquement.

Tu peux ainsi cumuler des adresses locales ULA pour les services internes et des adresses globales pour tout le reste: avec IPv6, tu as le beurre, l'argent du beurre et les faveur du crémier ou de la crémière (c'est selon).

Si tu cherche à protéger les machines du LAN, le firewall des routeurs est là pour cela. Pour anonymiser le traffic http, tu peux utiliser un proxy web à qui tes clients peuvent se connecter via une adresse ULA indépendante de tes adresses globales.

Là encore, pas besoin de s'encombrer avec un NAT66 qui n'a pas pour vocation de protéger quoi que ce soit et qui va donc te créer plus de problèmes que de gains.

Côté serveurs, s'ils doivent être accessibles de l'extérieur, il faut à un moment donné une ou des adresses globales et fixes pour les renseigner dans un DNS. Les serveurs peuvent se voir attribuer des adresses fixes de services en plus des adresses qui seraient auto attribuées par la configuration automatique. Cela permet aux serveurs d'utiliser l'adresse aléatoire pour les connexions sortantes et l’adresse fixe pour être contactés.

L'annonce de plusieurs préfixes ne pose pas de problèmes aux machines clientes, que ce soit sous linux qui gère jusqu'à 16 adresses IPv6 par port réseau ou sous windows dont je ne connaît pas la limite (elle est de manière sûre > 12).

Attention toutefois car une annonce de préfixe ajoute une route par défaut. Si tu annonce un préfixe local en // des préfixes globaux, il te faut impérativement mettre à 0 le temps de vie de la route par défaut correspondante. Sinon, du trafic à destination d'Internet va être envoyé au serveur qui annonce ce préfixe et ne sera pas en mesure de le router.

Si on en reviens à ton besoin, les couches réseau des machines clientes sont capables de noter dynamiquement la qualité de service des différents préfixes et vont naturellement prioriser les routes en fonction des « métriques », les notes de priorité attribuées à chaque route.

Le problème ne devrait donc pas se situer côté clients mais côté routeurs. Quand j'ai expérimenté la mise en parallèle d'une freebox et d'un routeur 4G, j'ai constaté que la freebox n'annonçait plus de préfixe si elle était démarrée après le routeur 4G.
Je n'ai pas pu expérimenter plus sur cette problématique car Bouygues a modifié ses APN et mon routeur ne peut plus être connecté en IPv6 sur décision unilatérale et débile de l'opérateur car il n'est pas compatible 464XLAT. Sachant que je voulait de l'IPv6 only, je me contre fout du 464XLAT.

Pour en revenir à la freebox, j'imagine qu'il s'agit pour free de pousser les entreprises à passer sur des offres pro et ce sont majoritairement les entreprises qui ont recours au « multi homing ».

En synthèse: IPv6 permet sans problèmes de mixer les routeurs directement et assurer une redondance sans nécessiter quoi que ce soit mais les opérateurs peuvent nous mettre des bâtons dans les roues et empêcher la redondance chez les particuliers.

La solution la plus en phase avec les principes de l'iPv6 est donc le NPT qui est sans état, ce qui est toujours préférable.

Après, tu as la possibilité de mettre en place un proxy web et proposer le service proxy sur un préfixe ULA aux machines clientes. Le proxy peut se trouver sur un serveur connecté aux routeurs et faire la balance de charge de son côté.