Oui sauf que MilkyWan, Firewall etc... c'est chez moi, sauf que comme dit plus tôt, j'aurais aussi un serveur à mettre chez un copain, lui aussi chez Orange, et sans routeur tiers... Donc je peux ABSOLUMENT pas me permettre de devoir activer désactiver IPv6 avec Tailscale chez mon copain ou lui demander de le faire (c'est du bricolage), donc je dois faire marcher ce fichu routeur/pare-feu de Livebox, même si j'arrivais à passer chez MilkyWan...

Et aussi en regardant dans l'interface de la Livebox, lors du bug, la box ne reconnait tout simplement plus l'IPv6 de l'appareil donc aller sur un site marche mais reçevoir des requêtes d'un client ne passe plus... (et c'est pas les privacy extensions, enfin je pense pas)...

Bonne journée / bonne soirée

Cela fonctionne t'il dans une configuration standard ? Il serait peut-être avisé de simplifier.

Tu pourrais essayer de faire fonctionner Tailscale en passant directement par la Livebox sans routeur tiers.

Partir d'un cas fonctionnel permettrait de se concentrer sur ce qui ne l'est pas en réduisant la complexité.

Cela évite aux participants d'aller chercher midi à quatorze heures ou de résoudre des problèmes insolubles.

En fait, l'adresse IPv6 de l'appareil (que ça soit un routeur, un PC ou autre) disparait de la GUI de la box quand le bug arrive, l'IPv4 reste. L'appareil accéde toujours aux sites et services IPv6, mais ont ne peut plus joindre ses services de l'exterieur, cela arrive surtout quand l'appareil reste allumé mais que la Livebox redémarre, mais si la Livebox reste allumé et que c'est l'appareil qui redémarre, là ça bugue pas...

Bonne journée / bonne soirée

Le "bug" n'est-il pas tout simplement l'expiration de l'adresse IPv6 de la machine, parce que tu as utilisé une de ses adresses temporaires pour la règle de pare-feu ? Dans ce cas, la Livebox continue de rediriger du trafic vers une adresse qui n'est plus portée par aucun hôte.

Windows et Linux ont 3 modalités d'adressage IPv6 automatique :

• Adresse dynamique avec partie hôte aléatoire (RFC 4941)
• Adresse stable avec partie hôte aléatoire (RFC 7217)
• Adresse stable avec partie hôte personnalisée : attribut ip-token paramétrable avec iproute2 et une tâche cron, ou Network Manager.
• Adresse stable avec partie hôte constituée d'après l'adresse MAC (EUI-64)

Cette dernière méthode est aujourd'hui désactivée par défaut sauf dans les OS serveur Linux. Si du trafic entrant doit être initié vers la machine, il faut utiliser une des trois dernières selon la configuration de la machine mais je déconseille EUI-64.

$ ip -6 a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
    inet6 ::1/128 scope host noprefixroute
       valid_lft forever preferred_lft forever
2: enp15s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 2a01:e0a:a09:xxxx:d31d:4920:f74e:6ab4/64 scope global temporary dynamic
       valid_lft 171130sec preferred_lft 84552sec
    inet6 2a01:e0a:a09:xxxx:df33:2260:acca:c6fd/64 scope global dynamic mngtmpaddr noprefixroute
       valid_lft 2591802sec preferred_lft 604602sec
    inet6 fe80::7988:fd40:715e:852/64 scope link noprefixroute
       valid_lft forever preferred_lft forever

Il faut toujours utiliser une adresse qui ne porte pas les drapeaux temporary dynamic. Sous Windows, l'adresse stable est celle qui s'affiche devant "Adresse IPv6" que ce soit dans l'ancien ou le nouveau panneau de configuration, par opposition à "Adresse IPv6 temporaire". Mes serveurs ont tous l'EUI-64 désactivé, une IP statique et une ou plusieurs RFC4941 pour les connexions sortantes. Cependant, de toutes ces méthodes, une seule résiste aux changements de préfixe : l'utilisation d'ip-token. La partie hôte des adresses RFC 7217 change en même temps que le préfixe. Et si ça arrive, tu as une nouvelle adresse IPv6 à indiquer dans la Livebox pour rediriger le trafic. Mais, même à ça, je ne sais pas si la Livebox est suffisamment bien faite pour ne mettre à jour que la partie préfixe pour qu'en cas d'utilisation d'ip-token, le changement soit complètement transparent.