Pourquoi ajouter IPv6 au Load Balancer SGTM ?

Ajouter un frontend dual‑stack évite la traduction NAT64 qui modifie l’IP client et casse la déduplication des événements (ex. Meta CAPI). Voir Google Cloud Load Balancing IPv6 et les recommandations Meta Conversions API pour détails (cloud.google.com, developers.facebook.com).

Comment l’IP casse le matching sans IPv6

Je détaille pourquoi l’IP casse le matching quand le Load Balancer n’expose que IPv4, et comment NAT64 intervient pour les clients IPv6.

Qu’est‑ce que NAT64 et pourquoi il intervient. NAT64 est une traduction d’adresses réseau permettant à un client IPv6 d’accéder à un service IPv4 en traduisant paquets IPv6→IPv4 (RFC 6146). Lorsque le Load Balancer n’écoute que des adresses IPv4, l’infrastructure réseau (ou un service Cloud) applique NAT64 pour rendre le service accessible aux clients IPv6. Voir spécifications RFC : https://datatracker.ietf.org/doc/html/rfc6146 et doc Google Cloud sur IPv6 pour les Load Balancers : https://cloud.google.com/load-balancing/docs/ipv6.

Comment Cloud Load Balancer transmet l’IP client. Le Load Balancer HTTP(S) de Google enregistre l’IP source et la propage au backend via l’en‑tête X-Forwarded-For (XFF). Lorsque la connexion a été traduite par NAT64, la valeur XFF contient l’adresse IPv4 traduite, pas l’IPv6 originelle du client. Cloud Run et SGTM reçoivent donc cette IP IPv4 dans X-Forwarded-For et l’utilisent comme « client IP ». Documentation : https://cloud.google.com/load-balancing/docs/ipv6.

Pourquoi l’IP sert au matching et à la déduplication. Les serveurs tags (ex. Meta Conversions API) utilisent l’adresse IP comme l’un des éléments d’identification pour associer un hit navigateur (pixel) à un hit serveur (CAPI). La logique de déduplication repose sur des clés combinées comme event_id (identifiant d’événement), client_ip_address et user_agent. Si l’IP côté serveur ne correspond pas à l’IP du pixel client, la règle échoue et les événements ne sont pas dédupliqués correctement, générant soit des doublons soit des pertes d’appariement. Voir guide Meta Conversions API sur déduplication : https://developers.facebook.com/docs/marketing-api/conversions-api/deduplication.

Découvrez égalementGuide GTM, Consent Mode v2 et sandbox Shopify

Exemple séquentiel (5 étapes).

• Client IPv6 Envoie requête pixel avec IPv6 et user_agent.
• NAT64 Traduit la session IPv6 en IPv4 pour atteindre un LB IPv4 (traduction d’adresse).
• Load Balancer Reçoit la requête, met X-Forwarded-For = adresse IPv4 traduite et transmet au backend (Cloud Run/SGTM).
• SGTM Envoie événement serveur (CAPI) à Meta en utilisant l’IP issue de XFF (IPv4 traduite) et le même event_id/user_agent.
• Meta Compare L’IP du pixel (IPv6) et l’IP serveur (IPv4 traduite) ; n’observe pas de correspondance → déduplication échouée.

Pour contexte chiffré, l’adoption IPv6 côté utilisateur est élevée (≈40%+ au niveau mondial selon Google IPv6 statistics), ce qui rend le problème fréquent : https://www.google.com/ipv6/statistics.html.

Quels prérequis avant de commencer

Avant d’ajouter IPv6 au Load Balancer SGTM, je m’assure que l’infrastructure existante est saine et que j’ai les accès nécessaires. Voici la checklist détaillée et les vérifications rapides à faire pour éviter des interruptions ou des erreurs de routage.

• Vérifier le déploiement SGTM sur Cloud Run (URL interne, domaine configuré).

  Exécuter la commande pour récupérer l’URL du service Cloud Run et confirmer que le domaine personnalisé est mappé. Risque : si le service n’est pas joignable, le LB en IPv6 n’apportera pas d’accès.

  gcloud run services describe SERVICE --region REGION --format="value(status.url)"

• Confirmer que le Load Balancer global redirige déjà le trafic HTTPS vers Cloud Run.

  Vérifier que le Backend est un Serverless NEG (Network Endpoint Group) pointant sur Cloud Run ou équivalent. Risque : mauvaise configuration du backend provoque des erreurs 502/503.

  gcloud compute url-maps describe URL_MAP_NAME --global

• Vérifier que le frontend IPv4 HTTPS est opérationnel et qu’un certificat TLS valide existe.
  

  Découvrez égalementPourquoi utiliser Google Tag Manager pour votre tracking ?

  Contrôler l’existence du certificat (managed ou uploadé) et l’association avec la règle de forwarding/target HTTPS proxy. Risque : certificat manquant empêche l’établissement TLS.

  gcloud compute ssl-certificates list --global
  gcloud compute forwarding-rules list --global --filter="loadBalancingScheme=EXTERNAL"

• Accès et rôles requis.

  Prévoir au minimum les rôles Compute Network Admin et Load Balancer Editor dans le projet GCP, accès à votre fournisseur DNS pour créer un enregistrement AAAA (type DNS pour IPv6), et accès console pour réserver des adresses IP globales. Risque : manque d’accès bloque la configuration IPv6.

• Vérifications DNS et TLS rapides.

  Contrôler la résolution A/AAAA et l’état du certificat depuis votre poste ou CI. Risque : absence d’enregistrement AAAA signifie qu’IPv6 ne sera pas routé.

  

  dig +short A example.com
  dig +short AAAA example.com
  openssl s_client -connect example.com:443 -servername example.com /dev/null | openssl x509 -noout -subject -dates

Comment réserver l’adresse IPv6 et ajouter l’enregistrement DNS

Je réserve une adresse IPv6 externe statique dans GCP, puis je crée un enregistrement DNS AAAA qui pointe dessus pour que votre Load Balancer soit reachable en IPv6.

Réserver l’adresse IPv6 (Console)

• Ouvrir la Console GCP > VPC network > External IP addresses.
• Cliquer sur « Reserve static address », choisir « Global » si l’IP servira un load balancer global, sélectionner IPv6 comme version, ajouter une description et valider.

Découvrez égalementBibliothèque de 25 JavaScript personnalisés Google Tag Manager.

Réserver l’adresse IPv6 (gcloud)

gcloud compute addresses create sgtm-ipv6 --global --ip-version=IPV6 --description="SGTM IPv6"

Cette commande provient de la documentation officielle Google Cloud (vérifier et adapter si nécessaire, notamment le paramètre –network-tier). Source : https://cloud.google.com/compute/docs/ip-addresses/reserve-static-external-ip-address

Récupérer l’adresse IPv6 réservée

• Via Console : revenir à VPC network > External IP addresses et lire la colonne « Address ».
• Via gcloud : utiliser la commande de description ou de liste, par exemple :

  gcloud compute addresses describe sgtm-ipv6 --global --format="get(address)"

Créer l’enregistrement DNS AAAA (chez votre registrar ou DNS provider)

• Exemple d’enregistrement à créer : Nom : sgtm.example.com, Type : AAAA (AAAA signifie mapping d’un nom DNS vers une adresse IPv6), Valeur : 2001:db8:xxxx::yyyy (adresse réservée).
• TTL recommandé : entre 300 et 3600 secondes selon la politique de déploiement et tolérance aux changements.

Propagation et vérification

• La propagation DNS peut prendre quelques minutes à quelques heures selon le TTL et caches intermédiaires.
• Vérifier avec dig : dig AAAA sgtm.example.com +short ou utiliser un vérificateur DNS IPv6 en ligne (par ex. DNS Checker).

Captures d’écran suggérées : page de réservation d’adresse dans la Console GCP, résultat de la commande gcloud describe, et l’interface de votre registrar montrant l’enregistrement AAAA.

Note sur la coexistence A + AAAA (dual‑stack)

Vous pouvez associer simultanément un enregistrement A (IPv4) et un enregistrement AAAA (IPv6) au même nom de domaine pour fournir dual‑stack. Les clients choisiront IPv6 si leur pile réseau et leur connectivité le permettent.

Comment créer la certificate map et ajouter le frontend IPv6

Pour activer IPv6 sur votre Load Balancer HTTPS, il faut d’abord créer une certificate map et y attacher le(s) certificat(s), puis ajouter un second frontend HTTPS en IPv6 qui utilisera cette map.

Une certificate map est un objet qui lie des noms d’hôtes (SNI) à des certificats TLS. Google Cloud a introduit et recentré la gestion des certificats autour des certificate maps pour séparer la gestion des certificats de la configuration du proxy, faciliter les mappings SNI multi-domaines et permettre l’automatisation. Voir la doc officielle pour les détails : https://cloud.google.com/load-balancing/docs/ssl-certificates/certificate-maps

Étapes pour créer la certificate map.

• Console : Aller dans Network Services → Load balancing → Security → Certificate maps (ou TLS certificates), cliquer sur « Create Certificate Map », donner un nom global, puis ajouter des bindings (hostnames) vers vos certificats existants.
• gcloud (exemples à valider contre la doc officielle) :

  gcloud compute certificate-maps create my-cert-map --global
  gcloud compute certificate-maps add-binding my-cert-map --certificate=my-cert --name=www.example.com --global

• Explication : Le binding associe un nom SNI (www.example.com) au certificat géré ou importé.

Étapes pour ajouter le frontend IPv6 au Load Balancer.

• Réserver une adresse IPv6 globale dans VPC → External IP addresses.
• Console : Éditer le Load Balancer → Frontend configuration → Ajouter un frontend HTTPS → Choisir l’adresse IPv6 réservée → Port 443 → Proxy type HTTPS → Sélectionner la certificate map créée.
• gcloud (exemple) : Mettre à jour le target HTTPS proxy pour utiliser la certificate map, puis créer une forwarding rule globale pointant sur ce proxy avec –address= –ports=443.
• Checklist essentielle : Port = 443 ; Proxy = HTTPS (terminaison TLS au LB) ; Protocoles TLS supportés (1.2/1.3) ; IP version = IPv6 ; SNI/host binding via certificate map.
• Précision importante : Aucune modification côté Cloud Run n’est nécessaire puisque la terminaison TLS se fait au Load Balancer (le backend reçoit du trafic HTTP/1.1 ou HTTP/2 selon la config).

Captures d’écran suggérées : liste des certificate maps (bindings visibles), formulaire d’ajout de frontend IPv6 montrant l’adresse, et l’écran de confirmation du target HTTPS proxy.

Comment vérifier et valider le déploiement

Je décris ici les vérifications pratiques pour valider qu’IPv6 est correctement activé sur le Load Balancer SGTM et que le routage, les certificats et le matching côté fournisseur fonctionnent.

• Vérifier la résolution DNS AAAA : Exécutez la commande suivante pour obtenir l’adresse IPv6 annoncée.

  dig AAAA sgtm.example.com +short

  Une ligne contenant une adresse IPv6 (ex. 2001:db8::1) signifie que le nom résout en IPv6. Une sortie vide signifie absence d’AAAA et donc pas d’accès IPv6 via DNS.

• Tester la connectivité IPv6 depuis un client : Forcez curl à utiliser IPv6 et observez la négociation TLS et le health endpoint.

  curl -6 -v https://sgtm.example.com/health
  curl --resolve 'sgtm.example.com:443:[2001:db8::1]' -k https://sgtm.example.com/health

  Un code HTTP 200 et l’échange TLS OK confirment la connectivité. L’option –resolve force une résolution locale vers l’IP IPv6 donnée.

• Vérifier dans Google Cloud Console : Confirmez que le frontend IPv6 existe, que l’adresse IPv6 est attachée, que la certificate map (liaison certificat/TLS) est présente et que les backends sont en état healthy (santé).
• Vérifier X-Forwarded-For et logs : Contrôlez que l’en-tête X-Forwarded-For contient l’IP client IPv6 (ou l’IPv4 réelle si client IPv4). Exemple d’entrée Cloud Run (headers) :

  "headers": {
    "x-forwarded-for": "2001:db8::2, 35.191.0.0",
    "x-forwarded-proto": "https"
  }

  La première IP est l’IP client. Utilisez Cloud Logging pour filtrer les requêtes et vérifier.

• Tester le flux jusqu’au fournisseur (ex. Meta CAPI) : Envoyez un événement de test depuis un client IPv6 et un événement serveur via SGTM. Vérifiez côté fournisseur que l’événement reçu montre l’IPv6 dans le champ d’adresse source et que la déduplication (matching par event_id et par IP) fonctionne.

Je fournis ci‑dessous une checklist synthétique des tests à exécuter.

dig AAAA sgtm.example.com +short

curl -6 -v https://sgtm.example.com/health

Prêt à activer IPv6 pour restaurer la qualité de matching et la déduplication ?

La mise en place d’un frontend dual‑stack (IPv4+IPv6) sur votre Google Cloud Load Balancer résout la fuite silencieuse provoquée par NAT64 : les IP client sont conservées et les serveurs tags (ex. Meta CAPI) reçoivent la même adresse utilisée côté client, ce qui restaure la déduplication et la qualité de matching. L’opération n’implique aucune modification de Cloud Run, demande seulement une adresse IPv6 statique, un enregistrement AAAA et l’ajout d’un frontend IPv6 avec certificate map. Bénéfice direct : meilleurs taux de matching, moins de faux positifs de duplication et données serveur plus fiables pour vos conversions.

FAQ

• Pourquoi mon SGTM casse les déduplications quand mes utilisateurs sont en IPv6 ?
  Parce qu’un Load Balancer exposé uniquement en IPv4 force les clients IPv6 à passer par une traduction NAT64 ; SGTM reçoit alors une adresse IPv4 traduite (via X-Forwarded-For) qui ne correspond pas à l’IPv6 vue côté client, ce qui empêche le matching IP côté fournisseur (ex. Meta CAPI).
• Faut‑il modifier Cloud Run pour activer IPv6 sur le LB ?
  Non. La terminaison IPv6 se fait au niveau du Load Balancer. Cloud Run reste inchangé : il continuera de recevoir le trafic via le backend du LB.
• Quels DNS records faut‑il ajouter pour activer IPv6 ?
  Ajouter un enregistrement AAAA pour votre domaine pointant sur l’adresse IPv6 externe statique réservée dans Google Cloud. Conserver aussi l’enregistrement A pour IPv4 si vous voulez un mode dual‑stack.
• Qu’est‑ce qu’une certificate map et pourquoi l’utiliser ?
  La certificate map est le mécanisme récent de GCP pour associer des certificats TLS aux frontends du Load Balancer. Elle permet d’attacher proprement les certificats au nouveau frontend IPv6 ; suivez la doc GCP pour les commandes exactes.
• Comment vérifier que l’IPv6 règle bien le problème de déduplication ?
  Vérifiez la résolution DNS AAAA, testez la connectivité IPv6 (curl -6), inspectez les headers X-Forwarded-For dans les logs Cloud Run et lancez des événements test depuis un client IPv6. Contrôlez ensuite les rapports de déduplication côté fournisseur (ex. Meta CAPI) pour confirmer la restauration du matching.

A propos de l’auteur

Je suis Franck Scandolera, expert et formateur en tracking avancé server‑side, Analytics Engineering et intégration d’IA en entreprise. J’accompagne les équipes techniques à déployer des architectures SGTM robustes, incl. server‑side, Load Balancing, et automatisation No/Low Code (n8n). Références clients : Logis Hôtel, Yelloh Village, BazarChic, Fédération Française de Football, Texdecor. Responsable de l’agence webAnalyste et de l’organisme de formation Formations Analytics. Disponible pour aider votre entreprise => contactez‑moi.

Franck Scandolera

⭐ Analytics engineer, Data Analyst et Automatisation IA indépendant ⭐

• Ref clients : Logis Hôtel, Yelloh Village, BazarChic, Fédération Football Français, Texdecor…

Mon terrain de jeu :

• Data Analyst & Analytics engineering : tracking avancé (GA4, Matomo, Piano, GTM server, Tealium, Commander Act, e-commerce, CAPI, RGPD), entrepôt de données (BigQuery, Snowflake, PostgreSQL, ClickHouse), modèles (Airflow, dbt, Dataform), dashboards décisionnels (Looker, Power BI, Metabase, SQL, Python).
• Automatisation IA des taches Data, Marketing, RH, compta etc : conception de workflows intelligents robustes (n8n, App Script, scraping) connectés aux API de vos outils et LLM (OpenAI, Mistral, Claude…).
• Engineering IA pour créer des applications et agent IA sur mesure : intégration de LLM (OpenAI, Mistral…), RAG, assistants métier, génération de documents complexes, APIs, backends Node.js/Python.