Comment limiter le débit et bloquer les abus IPv6 par préfixe /64

Presque tous les limiteurs de débit, mécanismes de limitation des connexions et listes de blocage IP en production ont été conçus pour l'IPv4, où le modèle mental est simple : une adresse, à peu près un utilisateur. Comptez les requêtes par adresse, bannissez l'adresse, passez à autre chose. Ce modèle est discrètement devenu faux. Dès que votre trafic inclut de l'IPv6 (et c'est le cas d'une part importante et croissante), l'unité que vous comptez ne correspond plus à une personne, et toute défense fondée sur « une adresse » se met à fuir.

Ce n'est pas un cas limite subtil. C'est la différence entre un limiteur de débit qui fonctionne et un limiteur qu'un attaquant traverse sans encombre pendant que vos tableaux de bord affichent une jolie série d'adresses à une seule requête. La solution n'est pas d'ajouter des règles. C'est de compter la bonne chose, le même réflexe que pour vérifier les robots d'exploration IA et les bots par plage d'IP, où le bloc CIDR publié compte plus que n'importe quelle adresse isolée. Le comptage par préfixe est une couche de la détection des bots par leur adresse IP ; les autres vous disent à quel type de réseau appartient le préfixe.

L'habitude IPv4 qui casse en IPv6

En IPv4, la rareté des adresses vous rendait service. Il n'existe qu'environ 4,3 milliards d'adresses, elles coûtent cher, et dans l'immense majorité des cas un abonné reçoit une seule adresse publique à la fois. « Les requêtes de ce /32 » et « les requêtes de cet utilisateur » étaient donc assez proches pour être traitées comme une seule et même chose. Bannissez le /32 et vous gênez, au pire, le foyer ou le NAT qui se trouve derrière.

L'IPv6 supprime la rareté, et avec elle cette hypothèse. L'adresse fait 128 bits au lieu de 32 (huit groupes de quatre chiffres hexadécimaux), et la philosophie de conception est tout sauf économe. Au lieu de rationner des adresses uniques, l'IPv6 attribue à chaque client un bloc d'adresses. Le plus petit bloc qu'on puisse recevoir est énorme, et c'est ce bloc, et non l'adresse individuelle, qui constitue la véritable identité de l'utilisateur.

Si votre limiteur compte encore par adresse complète en IPv6, un auteur d'abus n'a besoin ni d'un botnet ni d'un pool de proxys. Il lui faut une attribution IPv6 ordinaire et une boucle for.

Un abonné, 18 trillions d'adresses

Voici le chiffre qui recadre tout le problème. Le plus petit bloc routable normalement attribué à un utilisateur final IPv6 est un /64 : les 64 premiers bits désignent le réseau, les 64 derniers lui appartiennent et il les remplit comme il veut. Cela laisse 2^64 adresses utilisables dans le sous-réseau d'un seul abonné :

2^64 = 18 446 744 073 709 551 616 adresses : environ 18,4 trillions, toutes appartenant à un seul utilisateur, toutes également routables.

Deux faits rendent cela inévitable plutôt qu'anecdotique. D'abord, l'autoconfiguration d'adresses sans état (SLAAC), la méthode standard par laquelle les hôtes IPv6 s'attribuent eux-mêmes une adresse, exige un /64 complet par sous-réseau ; vous ne pouvez rien attribuer de plus petit à un réseau local ordinaire. Ensuite, les recommandations de plan d'adressage que suivent les RIR (RFC 6177 / BCP 157) demandent aux FAI de donner à chaque site final une attribution généreuse, couramment un /56 ou un /48, et jamais moins d'un /64. L'abondance est la raison d'être même du protocole.

Passons au côté de l'attaquant. Parcourir ces adresses n'a rien de coûteux ni d'astucieux. C'est une option de socket intégrée. Le flag Linux IP_FREEBIND permet à un processus de se lier à n'importe quelle adresse d'un préfixe routé localement, et d'émettre depuis celle-ci, sans configurer au préalable chaque adresse sur une interface, et des outils publics comme le très cité projet freebind encapsulent exactement cela en « utiliser une nouvelle adresse source pour chaque connexion ». Donnez-lui un /64 routé et il émettra du trafic depuis 18 trillions de sources distinctes, sans aucun coût.

La limite de débit par /128 ne ralentit donc cela d'aucun facteur. Chaque requête ressemble à une toute nouvelle adresse vue une seule fois. Les compteurs de votre limiteur ne dépassent jamais un, votre liste de blocage se remplit de millions d'entrées à un seul hit qui ne correspondent à rien, et l'attaque se poursuit à pleine vitesse tout en paraissant, sur le papier, parfaitement distribuée.

La hiérarchie d'attribution IPv6, et ce que signifie chaque niveau

Pour limiter la bonne unité, vous devez savoir ce que représente réellement chaque longueur de préfixe. Les préfixes IPv6 sont de simples blocs CIDR (la même notation /n qu'en IPv4, où un nombre plus petit couvre plus d'adresses), mais les frontières conventionnelles en disent long sur qui se trouve de l'autre côté.

La forme de la décision découle du tableau. Le /128 n'est jamais l'unité. Le /64 est le plancher : la portée la plus étroite qui corresponde encore à un acteur, et donc la valeur par défaut. Tout ce qui est plus large est une escalade à laquelle vous ne recourez que lorsque vous avez la preuve que l'attribution plus large, dans son ensemble, est le problème.

Règle n° 1 : limiter le débit IPv6 par préfixe, en partant du /64

Le seul changement qui corrige l'essentiel des dégâts consiste à cesser de compter par adresse et à compter par /64. Concrètement, pour chaque requête IPv6 entrante, dérivez le /64 en conservant les quatre premiers hextets (64 bits) et utilisez cela comme clé pour les compteurs de limitation de débit, les décomptes de tentatives de connexion et les recherches dans la liste de blocage.

Tous les outils de périphérie courants le prennent déjà en charge, vous avez donc rarement à le construire vous-même :

• nginx : construisez la clé de limite à partir d'un bloc map/geo qui masque l'IPv6 au /64, puis passez-la à limit_req_zone / limit_conn_zone au lieu de $binary_remote_addr.
• HAProxy : appliquez un masque de 64 bits à la source lorsque vous construisez les clés de stick-table, afin que src soit agrégé au /64 plutôt qu'à l'adresse complète.
• Cloudflare et la plupart des CDN / WAF : traitent déjà l'IPv6 par blocs /64 pour leur propre logique de limitation de débit et de challenge ; reproduisez cette granularité dans vos règles d'origine pour que les deux couches concordent.
• Le limiteur de votre propre application : remplacez le remote_addr brut par la clé /64 ci-dessus avant qu'il n'atteigne Redis, le token bucket ou le compteur.

Faites seulement cela, et l'attaque par rotation gratuite retombe à ce qu'elle devrait être : 18 trillions d'adresses deviennent un seul compteur, et l'auteur de l'abus est limité exactement comme s'il était une seule adresse IPv4. C'est la ligne de code la plus rentable de tout le sujet.

Règle n° 2 : élargir au /56 et au /48 en cas de persistance

Se baser sur le /64 règle le cas de l'attaquant qui fait tourner les adresses à l'intérieur d'un sous-réseau. L'échelon suivant est l'attaquant qui fait tourner les sous-réseaux, car un abonné détient souvent non pas un /64 mais tout un /56 ou /48 qui en est rempli, et les outils du type freebind peuvent aussi les parcourir.

Le signal pour élargir est la persistance : de nouveaux /64 qui continuent de mal se comporter tout en partageant un préfixe parent commun. Quand vous constatez cela, toute l'attribution est une seule entité et doit être traitée comme telle.

Voyez-le comme un compteur qui remonte. Conservez le décompte par /64 comme unité de base, mais suivez aussi les abus agrégés à chaque /56 et /48. Lorsqu'un préfixe parent franchit un seuil qu'aucun client légitime n'atteindrait (de nombreux /64 enfants distincts, tous fautifs dans un court laps de temps), appliquez la limite au niveau parent et laissez-la couvrir tous les enfants d'un coup. C'est ainsi que vous gardez une longueur d'avance sur un attaquant qui possède une grande attribution sans pénaliser ceux qui en possèdent une petite et se comportent bien.

Règle n° 3 : élargir selon le type de réseau, pas par réflexe

L'escalade a un mode d'échec, et c'est le plus coûteux : élargissez trop, et un seul bannissement efface des milliers d'utilisateurs innocents. Un /48 peut correspondre à une entreprise, ou à une tranche d'un opérateur mobile. Un /32 n'est presque jamais un seul acteur ; c'est généralement un FAI ou un hébergeur entier. Le signal de persistance vous dit que le préfixe parent est impliqué ; il ne vous dit pas combien de personnes réelles se trouvent derrière. Pour cela, vous devez savoir de quel type de réseau il s'agit.

C'est précisément là qu'une requête IP justifie sa place dans le pipeline. Un appel à l'API de recherche IP sur une adresse représentative du préfixe fautif vous dit si vous avez affaire à de l'infrastructure louée, que vous pouvez agréger de façon agressive, ou à un accès grand public, que vous devez traiter avec ménagement.

Les champs qui déterminent jusqu'où vous pouvez élargir sans risque :

Voici ce que renvoie cette requête pour une véritable adresse IPv6, le DNS public de Google à 2001:4860:4860::8888, interrogée le 5 octobre 2026 (abrégé ; les résultats changent à mesure que les plages évoluent) :

Les deux moitiés de la réponse répondent à deux questions différentes. asn_type: "hosting", connection_type: "datacenter" et is_hosting: true indiquent que le préfixe est de l'infrastructure : élargir un blocage au-delà du /64 ne toucherait donc pas des foyers. Mais scoring.fraud_score vaut 15 et recommended_action vaut allow : l'adresse elle-même ne présente aucun signal de VPN, de Tor ou d'abus, et detection_methods ne liste que datacenter_ip et no_ptr_datacenter. Le type de réseau vous dit jusqu'où vous pouvez élargir ; ce sont vos propres compteurs de persistance qui doivent fournir la raison d'élargir tout court. Un préfixe d'hébergement qui ne s'est jamais mal comporté reste ouvert.

La lecture est directionnelle, et elle reflète le même principe que les raisons du score de risque qui ajoutent et qui retranchent : certains champs vous permettent d'agir plus durement, d'autres vous disent de vous retenir.

Google Ads compte de la même façon : son API accepte 2001:db8::/48 comme une seule entrée d'exclusion d'IP, donc un /48 coûte l'un de vos 500 emplacements d'exclusion Google Ads.

La discipline est celle que nous défendons en détail dans détecter le trafic anonymisé sans bloquer de vrais clients : sur un préfixe hosting ou datacenter, vous pouvez élargir le blocage en toute confiance, car un paiement ou une inscription n'a aucune raison honnête de provenir d'une baie de serveurs. C'est le même indice que nous détaillons dans ce qu'est une adresse IP de datacenter. Sur un préfixe mobile ou residential, vous gardez une portée étroite et laissez le score de risque, et non un large bannissement CIDR, porter la charge. Élargir par réflexe, c'est ainsi qu'un limiteur de débit devient discrètement une panne pour de vrais utilisateurs.

Règle n° 4 : laisser la réputation des préfixes décroître

La dernière règle concerne le temps. Les listes de blocage IPv4 deviennent déjà obsolètes parce que les adresses sont réattribuées ; l'IPv6 aggrave la situation, car des préfixes entiers sont délégués, restitués puis redélégués, et le /64 qui martelait votre page de connexion le mois dernier peut appartenir aujourd'hui à un foyer ordinaire. Une liste de blocage permanente sur un espace d'adressage qui tourne devient peu à peu une liste d'endroits que vous ne pouvez plus atteindre sans risque.

Ne stockez donc pas de verdict permanent par préfixe. Stockez une réputation qui évolue :

• Augmentez en cas d'abus. Chaque requête fautive augmente le score du /64 et fait remonter un incrément plus petit vers ses parents /56 et /48.
• Faites décroître avec le temps. Si un préfixe reste calme, son score baisse selon un calendrier (des heures pour une limitation légère, des jours pour un blocage strict) jusqu'à repasser sous votre seuil, et le blocage se lève de lui-même.
• Agissez sur le score actuel, pas sur l'historique. Limitez, soumettez à un challenge ou bloquez selon le niveau de la réputation maintenant, afin qu'un préfixe assaini ou réattribué se rétablisse automatiquement au lieu de rester sur une liste que personne n'élague.
• Conservez les preuves. Stockez les signaux à l'origine de chaque changement de score (les detection_methods de la requête, le schéma de persistance) pour qu'un blocage large soit une décision que vous pouvez expliquer, et non une entrée mystérieuse.

La décroissance est ce qui garde l'ensemble du système honnête. Elle fait qu'une escalade agressive pendant une attaque ne devient pas une cicatrice permanente, et que votre liste de blocage reflète qui est hostile maintenant plutôt que qui l'a été un jour.

Pour commencer cette semaine

• Passez la clé du limiteur au /64. Partout où vous comptez ou bloquez actuellement par adresse, masquez d'abord l'IPv6 à ses 64 premiers bits. Ce seul changement bouche le trou de la rotation gratuite et ne représente généralement que quelques lignes dans nginx, HAProxy ou votre application.
• Ajoutez des compteurs agrégés pour le /56 et le /48. Suivez les abus agrégés aux préfixes parents pour qu'un attaquant qui fait tourner ses sous-réseaux déclenche une limite plus large, sans que vous élargissiez par défaut.
• Interrogez le réseau avant d'élargir. Pour toute escalade au-delà du /64, vérifiez asn_type / connection_type : agrégez librement sur l'hébergement, restez étroit sur le mobile et le résidentiel, ne bloquez jamais strictement une plage d'opérateur ou de CGNAT.
• Évaluez les cas ambigus. Lorsqu'un préfixe est partagé ou grand public, utilisez le fraud_score composite et la recommended_action par adresse plutôt qu'un bannissement CIDR brutal.
• Donnez une décroissance à chaque blocage. Stockez la réputation des préfixes avec une demi-vie, agissez sur le score actuel, et laissez l'espace réattribué se libérer automatiquement.

L'IPv6 n'a pas tant rendu la prévention des abus plus difficile qu'il en a changé l'unité. L'adresse n'est plus l'utilisateur ; le /64 l'est. Comptez cela, élargissez sur preuves, pondérez selon le type de réseau, et laissez le temps pardonner. Alors, chaque défense à laquelle vous vous fiez déjà en IPv4 fonctionne de nouveau.

Questions fréquentes

Pourquoi ne peut-on pas limiter le débit d'une adresse IPv6 comme celui d'une adresse IPv4 ?

Parce que les deux protocoles attribuent des quantités d'espace d'adressage très différentes par utilisateur. En IPv4, un abonné reçoit généralement une adresse : limiter par /32 (une adresse unique) revient donc à limiter par utilisateur. En IPv6, un seul abonné se voit couramment attribuer un /64 entier. Cela représente 2^64, soit environ 18,4 trillions d'adresses, et des outils comme IP_FREEBIND permettent à un processus d'émettre du trafic depuis n'importe quelle adresse de ce bloc, gratuitement. Limiter le débit ou bloquer un /128 (une adresse IPv6 unique) n'arrête donc rien : l'auteur de l'abus passe simplement à l'adresse suivante parmi 18 trillions. La bonne unité en IPv6 est le /64, pas le /128.

Sur quelle longueur de préfixe faut-il limiter le débit IPv6 ?

Commencez par le /64. Le /64 est le plus petit bloc garanti appartenir à un seul utilisateur final, car SLAAC exige un /64 complet par sous-réseau et les FAI attribuent au moins un /64 à chaque client. Basez vos compteurs et vos listes de blocage sur les 64 premiers bits de l'adresse et traitez le /64 entier comme un seul acteur. Lorsque l'abus persiste sur de nombreux /64 d'un même client, élargissez la portée au /56 (256 /64) puis au /48 (65 536 /64), qui sont les tailles habituelles de l'attribution complète d'un foyer ou d'une entreprise.

Est-il sûr de bloquer un /64 IPv6 entier ?

Presque toujours, oui, et c'est plus sûr que de bloquer une seule adresse IPv4. Un /64 est conçu pour être le sous-réseau d'un abonné : le bloquer touche rarement un tiers sans rapport, contrairement à une adresse IPv4 partagée en CGNAT. Le vrai risque se situe aux préfixes plus larges : un /48 ou un /32 peut correspondre à un FAI entier, à un opérateur mobile ou à une plage d'hébergement mutualisé couvrant des milliers d'utilisateurs sans lien entre eux. N'élargissez la portée que lorsque le type de réseau le justifie : de façon agressive sur les préfixes d'hébergement et de datacenter, avec prudence sur les préfixes mobiles et résidentiels.

Comment savoir jusqu'où élargir un blocage ?

Laissez deux éléments en décider : la persistance et le type de réseau. La persistance : si l'abus réapparaît sans cesse depuis de nouveaux /64 au sein du même /56 ou /48, toute cette attribution est une seule entité et vous élargissez jusqu'à elle. Le type de réseau : une requête qui renvoie un ASN d'hébergement ou de datacenter signifie que le préfixe est de l'infrastructure et que vous pouvez agréger rapidement ; un opérateur mobile ou un FAI résidentiel signifie que de nombreux utilisateurs réels peuvent se trouver derrière le préfixe plus large : restez étroit et appuyez-vous sur un score de risque plutôt que sur un bannissement strict.

Le CGNAT et les réseaux mobiles changent-ils la façon de traiter l'IPv6 ?

Oui, aux préfixes larges. Un /64 IPv6 correspond normalement à un seul abonné, même sur mobile, donc la limitation par /64 reste correcte. Mais les opérateurs mobiles et les déploiements 464XLAT/NAT64 peuvent placer de nombreux abonnés sous un préfixe plus large partagé : un bannissement au niveau d'un /48 ou d'un /32 sur un ASN mobile peut donc toucher une grande partie des clients d'un opérateur. La règle est la même qu'en IPv4 : ne bloquez jamais strictement une plage partagée sur la base d'un seul acteur malveillant. Évaluez-la, et réservez les bannissements larges aux préfixes d'infrastructure.

Combien de temps un préfixe IPv6 doit-il rester bloqué ?

Pas indéfiniment. Les préfixes IPv6 sont réattribués, et un /64 qui vous a attaqué le mois dernier peut appartenir à un autre client le mois prochain. Associez à chaque préfixe une réputation décroissante plutôt qu'une entrée permanente : augmentez son score en cas d'abus, laissez-le baisser avec le temps si rien de fâcheux ne se produit, et levez le blocage automatiquement dès qu'il passe sous votre seuil. Une liste de blocage permanente sur un espace d'adressage qui tourne devient peu à peu une liste d'adresses que vous ne pouvez plus atteindre sans risque.