J'ai étudié en détail divers RFC pour intégrer proprement le mécanisme d'authentification dans OpenWrt.

Force est de constater que ce n'est pas conforme aux standards même en faisant des concessions sur l'usage du
protocole CHAP pour générer dynamiquement le jeton de configuration.

Le protocole « Token Configuration » du RFC3118 (DHCPv4) n'est pas été porté en DHCPv6 comme ce fut le cas pour
le protocole « Delayed Authentication » dans le RFC3315 (mais rendu obsolète depuis le RFC8415). Je trouve que c'est
plutôt embêtant d'inclure une extension propriétaire dans le client DHCPv6 odhcp6c de prplos puis OpenWrt.

Il faut tout de même reconnaître que le format de l'option d'authentification reste identique au standard et que cette
extension n'est pas aberrante.

De plus, on ne devrait pas spécifier l'option 11 dans l'Option Request Option car c'est formellement interdit par le RFC9915.
Je suppose qu'il en est de même pour l'option 90 dans la Parameter Request List en DHCPv4 même si ce n'est pas spécifié.

The Option Request option MUST NOT include the following option codes:
...
Authentication (see Section 21.11)
...

Hyperlien : https://www.rfc-editor.org/rfc/rfc9915.html#name-option-request-option

Si je fais ces remarques c'est parce que j'aurais voulu intégrer officiellement le support du protocole dans les serveurs DHCP
d'OpenWrt pour pouvoir activer la Livebox derrière mon routeur pour la téléphonie fixe. Cela aurait pu être valable si c'était
conforme aux standards sinon l'intérêt de le supporter est moindre dans le sens général.

C'est surtout que la fonction n'est pas supportée sur nos équipements 😅

Ah, les joies des BDD de geoIP et le capitalisme international sur les IPv4...

Il y a en effet une autre possibilité, c'est que DBUG TELECOM LTDA a récemment acquis ou loué des IP d'un opérateur espagnol.
De là que les IP soient encore physiquement en Espagne en usage, mais que les BDD ont déjà appris qui devait les utiliser...

Je n'arrive pas à avoir en recherche générale sans chiffre, mais c'est probablement un début par 45, 91, ou 185, si c'est cette hypothèse.

Le mode passthrough permet de laisser passer les annonces RA d'un routeur en amont (donc la Freebox), c'est vrai, c'est absent de certains routeurs donc j'ai tendance à oublier son existence. Mais comme le routeur est transparent, j'imagine qu'on ne peut pas utiliser de règles de pare-feu ni avoir plus d'un sous-réseau, donc ce n'est pas très flexible ni sécuritaire.

L'IPv6 n'a pas pour but de plus sécuriser le trafic qu'IPv4, ce n'est d'ailleurs pas le rôle de la couche réseau, sauf utilisation d'IPsec mais ce n'est pas un comportement par défaut.

mais alors ?...ou est l'intérêt d'une ipv6 si l'ipv4 est toujours affiché ?

Affichée où ? Si tu parles d'un site pour afficher ses adresses IP, ils sont une exception et utilisent tes connectivités IPv4 et IPv6 pour t'afficher les 2 adresses. Tous les autres sites compatibles IPv6 n'utilisent que ta connectivité IPv6 (sauf connexions supplémentaires vers d'autres CDN encore en IPv4) et le "bénéfice" est que grâce aux extensions de confidentialité, ton adresse IPv6 change régulièrement et le serveur ne peut pas t'associer à une adresse long terme. Cependant, le préfixe /64 reste le même et les sites ont des dizaines d'autres moyens de suivi à base de pixels de suivi, cookies, JS dans la page etc. L'adresse IP joue aujourd'hui un bien maigre rôle dans le combat contre le traçage en ligne.

je voulais utiliser WireGuard (vpn semble t'il utilisé gratuitement sur ce routeur)
pour protéger l'ensemble de l'installation qui se trouve derrière le flint2
mais comme il est derrière la freebox et que le port 51820 semble être utilisé pour cela
ça va être "chaud" de faire une redirection de port sur la freebox pour "atteindre" le flint2 non ?
ou alors je n'ai pas tout compris ?

Tu n'as plus de redirection de port à faire dans la Freebox, elle est complètement transparente comme c'est le Flint 2 qui porte l'adresse IPv4. Donc tu as juste à l'ouvrir dans son pare-feu, si ce n'est pas fait automatiquement par l'activation du service VPN. En revanche il faut bien comprendre qu'ouvrir le port ne sert qu'à se connecter à ton LAN depuis l'extérieur, si tu as des ressources auxquelles accéder.

Si tu veux utiliser un VPN pour joindre tout Internet depuis l'intérieur, c'est avec un client soit sur ton PC soit sur le routeur s'il le supporte, mais pas besoin d'ouvrir de port. Mais l'utilité est aujourd'hui nulle, je rejoins le consensus de tout le monde sur ce point.

IPvFoo, une petite extension sans prétention, pour vérifier si un site est compatible avec l'absence d'IPv4
L'extension est sans publicité, sans partage d'information et est open source (licence Apache 2.0, le code source est sur https://github.com/pmarks-net/ipvfoo )

Contrairement à une vérification DNS, ici, il faut que le serveur réponde effectivement en IPv6, sans quoi en cas d'utilisation du fallback IPv4, il sera noté IPv4.

Extension pour Firefox : https://addons.mozilla.org/fr/firefox/addon/ipvfoo/
Extension pour Chrome : https://chromewebstore.google.com/detail/ipvfoo/ecanpcehffngcegjmadlcijfolapggal

L'icône d'action d'IPvFoo affiche un grand 4 rouge ou un 6 vert pour indiquer si la page externe a été récupérée via IPv4 ou IPv6. Si la page se connecte à d'autres domaines, un 4 ou un 6 plus petit apparaît à côté.

Pour l'avoir testée pendant quelques mois, cette extension a un joli défaut : elle se contente d'une simple vérification, par requête DNS, pour voir si le site web dispose d'un enregistrement AAAA (ipv6).
Visiblement, c'est tout.
Le test le plus pertinent, reste de couper l'ipv4, soit au niveau de l'ordi, soit du routeur. Je fais parfois ce test, on constate que les docs contractuels et tarifaires d'orange ne sont pas accessibles en ipv6. Free mobile non plus (contrairement à free fixe). Et bcp de site ne redirigent pas leur site.fr vers www.site.fr
Couper l'ipv4 me parait la seule solution pour vérifier complètement la compatibilité d'un site web. Beaucoup en sont encore qu'à mi-chemin.