VPS IPv6 seulement : 2 CAD de moins, l'IPv4 à portée

Une adresse IPv4 publique coûte cher, et elle ne sert pas toujours. Un serveur de compilation, un agent qui travaille en arrière-plan, un nœud de calcul ou une machine qu'on ne joint qu'en SSH n'attendent aucun visiteur en IPv4. Pour ces usages, chaque offre VPS existe désormais en IPv6 seulement, pour 2 CAD de moins par mois.

La VM n'a pas d'IPv4 publique, mais elle joint quand même tout l'Internet, y compris les sites qui n'ont toujours pas d'IPv6 : GitHub, ghcr.io, beaucoup d'API. Voici ce que vous obtenez, comment ça marche, et une démonstration sur une vraie machine.

1. Ce qui change, ce qui ne change pas

La remise vaut pour toutes les offres : 2 CAD par mois, 20 CAD par an, et le tarif horaire baisse dans la même proportion. Ressources, sauvegardes, console, trafic inclus : tout le reste est identique. Le choix se fait à la commande, pour la vie de la machine.

2. Commander une VM IPv6 seulement

Dans la console, la page de commande a une carte Réseau : choisissez « IPv6 seulement ». La remise s'affiche au mois, à l'année ou à l'heure selon le mode de facturation.

Par l'API, c'est un champ : "ipv4": false. Avec dry_run, l'appel vérifie tout et donne le prix sans rien créer.

curl -s -X POST "https://api.ffxf.net/v1/vms" \
     -H "Authorization: Bearer $FFXF_TOKEN" -H "Idempotency-Key: v6-demo-1" \
     -H 'Content-Type: application/json' \
     -d '{"plan":"nano","region":"montreal","image":"debian-13",
          "hostname":"v6-demo","billing":"hourly","ipv4":false,
          "ssh_keys":["SHA256:…"],"password_delivery":"none","dry_run":true}'

Le catalogue des régions indique aussi, par les champs ipv4 et ipv6, ce qui reste disponible. Quand les IPv4 viennent à manquer, une région passe en limited mais accepte toujours les VM IPv6 seulement.

3. Démonstration

Une Debian 13 livrée en IPv6 seulement, vue de l'intérieur. Elle n'a qu'une adresse globale, et aucune route IPv4 :

$ ip -br a
lo      UNKNOWN  127.0.0.1/8 ::1/128
eth0    UP       2602:f3a4:0:100::fff0/64 fe80::be24:11ff:fea6:616d/64

$ ip -4 route
$

GitHub n'a pas d'IPv6. Pourtant le nom se résout en une adresse IPv6, dans un préfixe particulier, 64:ff9b::/96 :

$ getent ahostsv6 github.com
64:ff9b::8c52:7204  STREAM github.com

Les huit derniers chiffres hexadécimaux sont l'IPv4 de GitHub : 8c52:7204 donne 140.82.114.4. La connexion passe :

$ curl -sI https://github.com | head -1
HTTP/2 200

$ curl -s https://api.ipify.org
23.159.52.25

$ dig +short -x 23.159.52.25
nat64.ffxf.net.

Vu de l'extérieur, la VM sort par l'IPv4 de notre passerelle, nat64.ffxf.net. Les sites qui ont de l'IPv6 sont joints directement, sans détour :

$ curl -s -o /dev/null -w '%{http_code} via %{remote_ip}\n' https://www.google.com
200 via 2001:4860:4827:7700::

Mises à jour système, git clone depuis GitHub, docker pull depuis Docker Hub ou ghcr.io : tout fonctionne. Sur nos tests, un téléchargement depuis GitHub tient environ 40 Mo/s à travers la passerelle. Windows Server et FreeBSD se comportent de la même façon : bureau à distance et SSH en IPv6, sortie IPv4 par la passerelle.

4. Comment ça marche : DNS64 et NAT64

Deux mécanismes standards travaillent ensemble.

• DNS64. Les résolveurs posés sur la VM (ceux de Cloudflare et de Google, en version DNS64) répondent normalement pour un nom qui a une adresse IPv6. Pour un nom qui n'a qu'une IPv4, ils fabriquent une adresse IPv6 en collant cette IPv4 au bout du préfixe 64:ff9b::/96.
• NAT64. Notre réseau envoie tout ce qui part vers 64:ff9b::/96 à une passerelle, qui traduit le paquet en IPv4, le fait sortir par sa propre adresse, puis traduit la réponse en sens inverse.

Pour le logiciel dans la VM, tout est transparent : il demande un nom, reçoit une adresse IPv6 et se connecte. Il n'y a rien à configurer.

5. Se connecter à la VM

Une VM IPv6 seulement n'est joignable que depuis un réseau IPv6. Beaucoup de connexions résidentielles et de réseaux mobiles le sont déjà. Pour vérifier la vôtre :

curl -6 -s https://api64.ipify.org && echo " : IPv6 disponible"

Si la commande n'affiche rien, trois solutions :

• la console KVM dans le navigateur, qui ne passe pas par le réseau de la VM ;
• un rebond SSH par une machine qui a les deux familles : ssh -J moi@bastion debian@vm-xxxxxxxxx.ffxf.zone ;
• un tunnel WireGuard depuis une autre de vos machines, comme dans notre guide VPN WireGuard sur un VPS.

6. Les limites à connaître

• Pas de visiteurs IPv4 directs. Un site public hébergé sur la VM ne sera vu que des visiteurs en IPv6. Placez-le derrière un proxy ou un CDN qui accepte une origine IPv6, ou prenez l'offre avec IPv4.
• Port 25 fermé vers l'IPv4. L'adresse de sortie est partagée : pour protéger sa réputation, le port 25 vers l'IPv4 est fermé, sans exception. Envoyez vos courriels par un relais authentifié sur le port 587.
• Adresses IPv4 écrites en dur. Un logiciel qui se connecte à une IPv4 sans passer par un nom ne profite pas du DNS64. Écrivez plutôt l'adresse traduite : 64:ff9b::1.1.1.1, par exemple.
• Choix définitif. Le réseau se choisit à la commande et ne change plus ensuite. Pour ajouter une IPv4 plus tard, il faut une nouvelle machine.

7. Pour qui ?

L'IPv6 seulement convient aux machines qui sortent beaucoup et reçoivent peu : intégration continue, agents IA, collecte de données, calcul, environnements de test, ou nœuds d'un réseau privé. Si vous servez un public en IPv4, gardez l'offre avec IPv4. Pour aller plus loin sur l'adressage, le DNS inverse et le pare-feu, voyez notre guide IPv6 sur un VPS.