Ce sont des leurres qui indiquent les futurs emplacements pour les antennes 3,5 GHz. On en voit depuis le début de la 5G. L'emplacement étant réservé administrativement à l'ANFR, ça doit répondre à un cas particulier, parce que c'est plutôt rare.

À moins que les règles du firewall windows ne bloquent les router advertisements dans le profil "public" (ce qui serait une aberration mais pas si étonnant que cela au vu de la qualité globale de Windows), il ne devrait pas y avoir de différence entre public/privé niveau IPv6. Je n'ai pas le souvenir d'avoir vu ca, je vais tester dans une VM.

Souvent, quand IPv6 ne se configure que plusieurs minutes après la connexion au réseau, c'est que le switch fait du spanning tree avec des timers beaucoup trop conservateurs et garde le port en blocking state pendant plus de ~10s. Vu que les clients émettent rarement plus de 3 router solicitations à quelques secondes d'intervalle, le routeur ne reçoit jamais de solicitation (puisque le switch drop toutes les trames arrivant sur le port). IPv6 est donc configuré à la prochaine émission périodique d'un RA par le routeur.

J'ai reproduit la situation sur tous les nouveaux ordinateurs ou nouvelles installations de Windows, sur une période de 8 ans où j'ai mon extension de Firefox qui donne la génération d'IP et depuis laquelle j'ai de l'IPv6. Je suis persuadé que ce n'est pas du STP parce qu'IPv4 fonctionne instantanément quel que soit la zone du pare-feu. Cependant, j'avais fini par vérifier les règles du pare-feu et j'avais déjà constaté assez tôt que les règles ne sont normalement pas problématiques parce qu'il autorise NS et RA sur toutes les zones.

J'ai pourtant remarqué que le problème était résolu aussi en joignant Windows à un domaine, ce qui change aussi la zone du pare-feu. Ça inculpait encore un peu plus la zone publique et remettait une pièce dans la machine mais le rapport énergie déployée à utilité du fin mot de l'histoire étant défavorable, j'admets que j'avais juste laissé tomber. Le mystère restant entier aujourd'hui, je mettrais bien ça sur le compte de Windows.

On peut tout à fait faire faire un refus implicite à iptables et à nftables. À moins que ça n'ait changé et sur les distributions que je connais, la stratégie de base des chaînes INPUT et FORWARD est sur ACCEPT. Et en effet, je trouverais pertinent de la mettre sur DROP pour imiter une box opérateur, pour ne garder autorisées que les connexions établies ou liées. Ainsi, plus de problèmes de vulnérabilité de noyau en tapant directement sur le routeur. Il peut toujours y avoir une exploitation depuis une machine du LAN ou un moyen détourné mais ça réduit déjà la surface d'attaque.

nftables remplaçant iptables, ça pourrait être une amélioration de n'utiliser que le premier à l'avenir.