Ou encore cette manie d'envoyer des solicit alors qu'on a rien demandé et qui m'oblige à bloquer la distribution d'adresses.

Qu'est ce qu'ils ont cassé? Et qu'est ce que tu bloques du coup?

Si tu veux garder ton architecture à base de tunnels VxLAN, je pense que faire du MSS clamping pour TCPv4 et laisser PMTUd se débrouiller en IPv6 doit le faire.

Sinon tu me préconiserais quoi comme autre archi ?

J'ai hésité avec du GRE ou PPPoE. Mais je les avais écarté car pour GRE, ça fait une couche de routage en plus (avec les difficultés que ça implique pour le DHCP) et le PPPoE, ça à l'air bien galère à configurer pour pas grand chose (je n'ai jamais touché à la partie v6). Mais peut-être que c'est pas si pire et que Hugues pourrait nous en dire un peu plus 

VxLAN est pas mal, perso je n'ai rien contre :-) C'est L2 donc probablement plus facile à gérer pour ce que tu veux faire.

Aujourd'hui tu termines ce tunnel VxLAN sur une raspi. Est-ce que tu ne pourrais pas le faire directement sur le routeur, et mettre tes VM dans un (ou plusieurs) VLAN avec leur propre /64? Ca ferait moins d'équipements.

Le VLAN termine bien sur le routeur. Le rasp sert juste de bridge. Ça fait : Debian (portable) > [eth0/vxlan] raspi [eth0.40] > pont wifi > [eth0.40] OpenWRT. Par contre avoir plusieurs /64, je sens que ça va être ingérable, si je veux me mettre à compartimenter j'ai pas fini avec une dizaine de VM (et bien plus sur mon fixe)                                                                                                                                                                                 

Est-ce tu me confirme que les interfaces VxLAN sur OWRT se comportent comme n'importe quelle autre ? Je peux donc y mettre une IPv4, un DHCP et l'attribution automatique en v6 ? Si je veux intégrer le VLAN actuel pour desservir mes VM fixes, il me suffit de faire un bridge entre les 2 donc ? (et ça sera donc le bridge qui porte l'IP).

 J'espère par contre que ça sera pas trop galère car faut tout gérer dans /etc/config/network. Je n'ai pas upgrade, donc adieu la gestion avec luci bien pratique il faut dire (dispo à partir de la 21 de ce j'ai vu [luci-proto-vxlan]) Je suis toujours en 19.07 qui tourne au poil car il y avait des problèmes de possible bootloop jusqu'à récemment sur la 22.03, apparemment corrigé sur la dernière révision et je n'avais pas du tout envie de le planter n'ayant pas le matos adéquat en cas de pépin.

J'ai toujours ce plan de tenter de forcer l'activation du CLAT sur une interface arbitraire, mais bon, faut se frotter à Windows.

J'avais essayé de bidouiller le registre sans succès. Du genre, faire croire au système que l'interface est de type WWAN, mais tout ce que ça faisait, c'est me la faire disparaître du panneau de config.

Yep, ils ignorent les flags des RA, c'est clairement une violation des specs. Poussé par la mentalité entreprise de vouloir faire du DHCP comme en IPv4, je suppose (qu'on se le dise, le 1er client de MS, c'est l'IT entreprise).
Je suppose que tu dois pouvoir influer sur ces comportements depuis des commandes PowerShell magiques, ou en changeant des valeurs dans le "registre" de Windows.

Alors là aussi, ce n'est pas simple. Le seul moyen que j'ai trouvé est de désactiver le DHCPv6 mais on perd les DNS du coup. Aucune idée s'il est possible de récupérer le comportement de 7 juste en bidouillant le registre et sans désactiver le DHCPv6.

Ce n'est pas aussi facile que je le pensais.  Avant de déployer sur mon routeur, je test d'abord en VM et j'ai bien fait : ça ne fonctionne pas... là j'essaie de connecter un OWRT avec mon raspi.

Le vxlan monte bien, par contre, j'ai un paquet sur deux des destination unreachable au milieu des requêtes ARP. Et aucun autre trafic. On dirait qu'il n'arrive pas à apprendre les MACs du sous réseau....
root@OpenWrt:~# arp
IP address       HW type     Flags       HW address            Mask     Device
192.168.10.1     0x1         0x0         00:00:00:00:00:00     *        vxlan0
192.168.1.10     0x1         0x2         b8:27:eb:ea:xx:xx     *        eth1
192.168.45.202   0x1         0x2         08:00:27:0a:59:36     *        br-lan
192.168.1.1      0x1         0x2         18:1e:78:1a:xx:xx     *        eth1
192.168.10.253   0x1         0x0         00:00:00:00:00:00     *        vxlan0

192.168.10.x est le sous réseau des VM.

De plus j'ai droit à des duplication d'adresses... qui n'existent pas. Pour je ne sais quelle raison, mon RPi répond aussi à la requête ARP que c'est lui qui porte l'adresse de mon routeur principal juste après celui-ci. Alors que je n'ai pas attribué d'adresse au bridge  Chose qui ne se produit pas avec la debian en face. Pour régler le problème, j'ai donc attribué une adresse au bridge et la duplication a disparue.

Bon, c'est pire que ça : je ne sais pas si je m'en rends compte que maintenant, mais le simple fait de faire un ifup/ifdown sur le bridge me fait gicler l'ipv6 de eth0... Pourtant il me semble bien qu'au tout début, j'ai essayé diverses config avec ifup/down à chaque fois et ça n'a eu aucun effet.

Et même en mettant une ipv6 fixe, elle disparaît aussi 

Y'a un truc que je fais de travers ou quoi ?

EDIT : J'ai essayé en VM, et même comportement. On dirait que c'est lié au VLAN, qui entraîne l'interface parente avec, comme si ça faisait un ifup/down pas propre qui ne reconfigure pas la stack ipv6.