Bonjour à tous,

Je rencontre une problématique liée à l'utilisation d'adresses IPv6 ULA (fc00::/7) dans mon réseau privé, principalement dans un contexte Docker.

Contexte
J'ai un réseau étendu sur plusieurs FAI/pays/continents. Dans certains cas, je n'ai même pas IPV6 provisionné sur certains sites. Sans parler des potentiels changements de plage qui, du coup, casseraient mes conteneurs Docker.
J'ai un réseau privé VPN où j'utilise des adresses IPv6 ULA (fd42::/32). Cela me permet d'avoir quelque chose de stable et de standardisé.
L'implémentation principale est dans Docker. Voici un exemple de configuration réseau :

docker network create \
  --driver=bridge \
  --subnet=192.168.85.0/24 \
  --ipv6 --subnet=fd42:85::/32 \
  network_85_0
Les conteneurs disposent donc bien d'une adresse IPv6 ULA, et je configure du NAT pour permettre la sortie IPv6 via une machine passerelle ou en local si possible.
Problème
Malgré une connectivité IPv6 fonctionnelle avec NAT, les OS ne privilégient pas IPv6 dans ce cas précis. Cela semble être dû à :

La faible priorité accordée aux adresses ULA dans la table de préférence des OS (RFC 6724).
Le mécanisme "Happy Eyeballs" (RFC 6555), qui préfère IPv4 lorsque IPv6 semble sous-optimal.
Pour illustrer, voici un exemple :


# Test IPv4
curl https://ipv4v6.lafibre.info/ip.php
151.80.35.173

# Test IPv6
curl https://ipv6.lafibre.info/ip.php
2001:41d0:d:22ad::1
Même si l'IPv6 est configuré et fonctionnel (NAT), il n'est pas priorisé pour les communications sortantes.

Solutions envisagées
Modifier la table de préférence IPv6 sur les OS pour accorder plus de priorité aux adresses ULA (fc00::/7).
Mais cela implique une configuration manuelle sur toutes les machines.

Utiliser une plage aléatoire dans 2000::/3 (adresses globales) ex : 2001:2001:2001::/48 pour contourner le problème. Bien que cela soit techniquement faux, cela permettrait aux OS de prioriser IPv6. Le risque de conflit est minime, car les adresses choisies seraient probablement jamais attribuées.

Existe-t-il d'autres solutions élégantes pour forcer la priorisation d'IPv6 sur des ULA sans modifier tous les systèmes ?
Merci d'avance pour vos idées et suggestions !

> La faible priorité accordée aux adresses ULA dans la table de préférence des OS (RFC 6724).

Oui, c'est bien ca.

> Existe-t-il d'autres solutions élégantes pour forcer la priorisation d'IPv6 sur des ULA sans modifier tous les systèmes ?

Passer les containers en IPv6-only (avec un NAT64 quelque part dans le réseau pour l'accès IPv4, si ils en ont besoin) est-il envisageable ?
Pas de v4, pas possible de prioriser v4 :-)

Tu gagnes aussi niveau administration : une seule stack est toujours plus simple à administrer que deux (firewalls, routage, VPN, etc.).

Merci pour ta réponse, cela confirme ce que je pensais.

C'est bien pensé de passer par NAT64. J'utilise beaucoup trop l'IPv4 pour utiliser cette méthode qui, en plus, nécessiterait de reconfigurer les conteneurs :/

Je crois que je vais finir par utiliser ma méthode non élégante qui consiste à utiliser une plage IPv6 'publique'.

Peut-être que je ferais les choses de façon un minimum correcte et que je bloquerais un /48 sur tunnelbroker.net pour mon usage interne ....

C'est quoi l'intérêt d'utiliser IPv6 dans tes conteneurs si c'est pour sortir en IPv6 avec du NAT ?

C'est pour le trafic entrant ou sortant des conteneurs (trafic a l'initiative d'un conteneur? exposition d'un service en IPv6).

En pratique, le double stack est a éviter au maximum (même si a une époque c'était une approche recommandée) et le NAT IPv6 aussi.

Happy Eyeballs et la priorité ULA/IPv4 ce n'est pas la même chose. Beaucoup d'applications n'utilisent pas Happy Eyeballs.

Ce qui compte c'est le DNS. Si tu n'a pas d'entrées DNS IPv4 ca sera IPv6 qui sera toujours choisi. ULA ou pas.

Sinon d'autres approches comme tailscale.com qui permet du VPN directement dans les conteneurs (avec TSDProxy en plus si besoin).