Cómo limitar la tasa y bloquear el abuso de IPv6 por prefijo /64

Casi todos los limitadores de tasa, los frenos de inicio de sesión y las listas de bloqueo de IP en producción se diseñaron pensando en IPv4, donde el modelo mental es sencillo: una dirección, más o menos un usuario. Cuenta las peticiones por dirección, bloquea la dirección y sigue adelante. Ese modelo se ha vuelto erróneo sin hacer ruido. En cuanto tu tráfico incluye IPv6 (y una parte grande y creciente lo incluye), la unidad que estás contando deja de corresponderse con una persona, y toda defensa basada en "una dirección" empieza a hacer aguas.

No es un caso límite sutil. Es la diferencia entre un limitador de tasa que funciona y uno que un atacante atraviesa sin problemas mientras tus paneles muestran una ordenada fila de direcciones con una sola petición cada una. La solución no son más reglas. Es contar lo correcto, el mismo hábito que hay detrás de verificar rastreadores de IA y bots por rango de IP, donde el bloque CIDR publicado importa más que cualquier dirección individual. Contar por prefijo es una de las capas de la detección de bots por su dirección IP; las demás te dicen a qué tipo de red pertenece el prefijo.

El hábito de IPv4 que falla en IPv6

En IPv4, la escasez de direcciones te hacía un favor. Solo hay unos 4.300 millones de direcciones, son caras y lo más habitual con diferencia es que un abonado tenga una única dirección pública en cada momento. Así que "peticiones desde este /32" y "peticiones de este usuario" eran lo bastante parecidas como para tratarlas igual. Bloquea el /32 y molestarás, como mucho, al hogar o al NAT que hay detrás.

IPv6 elimina la escasez y, con ella, la suposición. La dirección tiene 128 bits en lugar de 32 (ocho grupos de cuatro dígitos hexadecimales), y la filosofía de diseño es lo contrario de la austeridad. En lugar de racionar direcciones individuales, IPv6 entrega a cada cliente un bloque de ellas. El bloque más pequeño que recibe cualquiera es enorme, y ese bloque, no la dirección individual, es la identidad real del usuario.

Si tu limitador sigue contando por dirección completa en IPv6, un abusador no necesita una botnet ni un pool de proxies. Necesita una asignación IPv6 corriente y un bucle for.

Un abonado, 18 trillones de direcciones

Esta es la cifra que replantea todo el problema. El bloque enrutable más pequeño que se asigna normalmente a un usuario final de IPv6 es un /64: los primeros 64 bits son la red y los últimos 64 bits son suyos para rellenarlos como quiera. Eso deja 2^64 direcciones utilizables dentro de la subred de un solo abonado:

2^64 = 18.446.744.073.709.551.616 direcciones: unos 18,4 trillones, todas pertenecientes a un solo usuario y todas igual de enrutables.

Dos hechos hacen que esto sea inevitable y no una rareza. Primero, la autoconfiguración de direcciones sin estado (SLAAC), la forma estándar en que los hosts IPv6 se asignan direcciones a sí mismos, exige un /64 completo por subred; no puedes entregar nada más pequeño a una LAN normal. Segundo, las directrices de planificación de direcciones que siguen los RIRs (RFC 6177 / BCP 157) indican a los ISPs que den a cada sitio final una asignación generosa, normalmente un /56 o un /48, y nunca menos de un /64. La abundancia es la esencia misma del protocolo.

Ahora, el lado del atacante. Recorrer esas direcciones no es caro ni ingenioso. Es una opción de socket integrada. El flag IP_FREEBIND de Linux permite a un proceso vincularse y enviar desde cualquier dirección dentro de un prefijo enrutado localmente sin configurar antes cada dirección en una interfaz, y herramientas públicas como el muy citado proyecto freebind empaquetan justo eso en "usa una dirección de origen nueva para cada conexión". Dale un /64 enrutado y emitirá tráfico desde 18 trillones de orígenes distintos sin coste alguno.

Así que el límite de tasa por /128 no lo frena en ninguna medida. Cada petición parece una dirección completamente nueva vista una sola vez. Los contadores de tu limitador nunca pasan de uno, tu lista de bloqueo se llena de millones de entradas de un solo acierto y no coincide con nada, y el ataque avanza a toda velocidad mientras parece, sobre el papel, perfectamente distribuido.

La jerarquía de asignación de IPv6 y qué significa cada nivel

Para limitar la unidad correcta tienes que saber qué representa realmente cada longitud de prefijo. Los prefijos IPv6 no son más que bloques CIDR (la misma notación /n que en IPv4, donde un número menor abarca más direcciones), pero los límites convencionales dicen algo sobre quién está al otro lado.

La forma de la decisión se desprende de la tabla. El /128 nunca es la unidad. El /64 es el suelo: el alcance más ajustado que sigue correspondiendo a un actor y, por tanto, el valor por defecto. Todo lo más amplio es una escalada a la que recurres solo cuando tienes evidencias de que la asignación más amplia, en su conjunto, es el problema.

Regla uno: limita la tasa de IPv6 por prefijo, empezando por el /64

El único cambio que arregla la mayor parte del problema es dejar de contar por dirección y empezar a contar por /64. En concreto, para cada petición IPv6 entrante, obtén el /64 conservando los cuatro primeros hextetos (64 bits) y usa eso como clave para los contadores de límite de tasa, los recuentos de intentos de inicio de sesión y las búsquedas en listas de bloqueo.

Todas las herramientas de borde habituales ya lo admiten, así que rara vez tendrás que construirlo tú:

• nginx: construye la clave del límite a partir de un bloque map/geo que enmascare IPv6 a /64 y pásala a limit_req_zone / limit_conn_zone en lugar de $binary_remote_addr.
• HAProxy: aplica una máscara de 64 bits al origen cuando construyas las claves de la stick-table, para que src se agregue al /64 en lugar de a la dirección completa.
• Cloudflare y la mayoría de CDNs / WAFs: ya tratan IPv6 en bloques /64 en su propia lógica de limitación de tasa y desafíos; replica esa granularidad en tus reglas de origen para que ambas capas coincidan.
• El limitador de tu propia app: sustituye el remote_addr sin procesar por la clave /64 anterior antes de que llegue a Redis, al token bucket o al contador.

Haz solo esto, y el ataque de rotación gratuita vuelve a ser lo que debería: 18 trillones de direcciones se convierten en un contador, y el abusador queda limitado exactamente como si fuera una única dirección IPv4. Es la línea de código más valiosa de todo este tema.

Regla dos: escala a /56 y /48 ante la persistencia

Usar el /64 como clave resuelve el caso del atacante que rota direcciones dentro de una subred. El siguiente escalón es el atacante que rota subredes, porque un abonado a menudo no tiene un solo /64 sino un /56 o un /48 entero lleno de ellos, y las herramientas al estilo de freebind también pueden recorrerlos.

La señal para ampliar es la persistencia: /64 nuevos que siguen portándose mal mientras comparten un prefijo padre común. Cuando lo veas, toda la asignación es una sola entidad y debe tratarse como tal.

Piénsalo como un contador que se acumula hacia arriba. Mantén el recuento por /64 como unidad base, pero registra también el abuso agregado a cada /56 y /48. Cuando un prefijo padre supere un umbral que ningún cliente legítimo alcanzaría (muchos /64 hijos distintos infringiendo en una ventana corta), aplica el límite a nivel del padre y deja que cubra a todos los hijos a la vez. Así te adelantas a un atacante que posee una asignación grande sin castigar a quienes tienen una pequeña y bien comportada.

Regla tres: amplía según el tipo de red, no por reflejo

La escalada tiene un modo de fallo, y es el caro: amplía demasiado y un solo bloqueo borra a miles de usuarios inocentes. Un /48 puede ser una empresa, o puede ser una porción de un operador móvil. Un /32 casi nunca es un único actor; suele ser un ISP o un proveedor de hosting entero. La señal de persistencia te dice que el prefijo padre está implicado; no te dice cuántas personas reales hay detrás. Para eso necesitas saber qué tipo de red es el prefijo.

Aquí es exactamente donde una consulta de IP se gana su lugar en el pipeline. Una llamada a la API de consulta de IP sobre una dirección representativa del prefijo infractor te dice si estás ante infraestructura alquilada que puedes agregar de forma agresiva o ante acceso de consumidores que debes tratar con cuidado.

Los campos que determinan hasta dónde puedes ampliar con seguridad:

Esto es lo que devuelve esa consulta para una dirección IPv6 real, Google Public DNS en 2001:4860:4860::8888, consultada el 5 de octubre de 2026 (recortado; los resultados cambian a medida que se mueven los rangos):

Las dos mitades de la respuesta contestan a dos preguntas distintas. asn_type: "hosting", connection_type: "datacenter" e is_hosting: true indican que el prefijo es infraestructura, así que ampliar un bloqueo más allá del /64 no afectaría a hogares. Pero scoring.fraud_score es 15 y recommended_action es allow: la dirección en sí no tiene ninguna señal de VPN, Tor ni abuso, y detection_methods solo enumera datacenter_ip y no_ptr_datacenter. El tipo de red te dice hasta dónde puedes ampliar; tus propios contadores de persistencia tienen que aportar el motivo para ampliar. Un prefijo de hosting que nunca se ha portado mal sigue abierto.

La lectura tiene dirección, y refleja el mismo principio que hay detrás de los motivos de la puntuación de riesgo que suman y restan: algunos campos te permiten actuar con más dureza y otros te dicen que te contengas.

Google Ads cuenta del mismo modo: su API acepta 2001:db8::/48 como una sola entrada de exclusión de IP, así que un /48 ocupa uno de tus 500 huecos de exclusión de Google Ads.

La disciplina es la misma que defendemos a fondo en detectar tráfico anonimizado sin bloquear a clientes reales: en un prefijo hosting o datacenter puedes ampliar el bloqueo con confianza, porque un checkout o un registro no tiene ninguna razón honesta para originarse en un rack de servidores. Es la misma señal delatora que explicamos en qué es una dirección IP de datacenter. En un prefijo mobile o residential mantienes el alcance ajustado y dejas que la puntuación de riesgo, y no un bloqueo CIDR amplio, cargue con el peso. Ampliar por reflejo es la forma en que un limitador de tasa se convierte en silencio en una caída del servicio para usuarios reales.

Regla cuatro: deja que la reputación de los prefijos decaiga

La última regla tiene que ver con el tiempo. Las listas de bloqueo de IPv4 ya se quedan obsoletas porque las direcciones se reasignan; IPv6 lo empeora, porque prefijos enteros se delegan, se devuelven y se vuelven a delegar, y el /64 que machacaba tu página de inicio de sesión el mes pasado puede pertenecer hoy a un hogar corriente. Una lista de bloqueo permanente sobre un espacio de direcciones que rota se convierte poco a poco en una lista de lugares a los que ya no puedes llegar con seguridad.

Así que no guardes un veredicto permanente por prefijo. Guarda una reputación que se mueva:

• Súbela ante el abuso. Cada petición infractora aumenta la puntuación del /64 y suma un incremento menor a sus padres /56 y /48.
• Haz que decaiga con el tiempo. Si un prefijo se mantiene tranquilo, su puntuación baja según un calendario (horas para una limitación suave, días para un bloqueo estricto) hasta que vuelve a quedar por debajo de tu umbral y el bloqueo se levanta solo.
• Actúa según la puntuación actual, no según el historial. Limita la tasa, desafía o bloquea en función de dónde está la reputación ahora, para que un prefijo reformado o reasignado se recupere automáticamente en lugar de quedarse en una lista que nadie depura.
• Conserva las evidencias. Guarda qué señales provocaron cada cambio de puntuación (los detection_methods de la consulta, el patrón de persistencia) para que un bloqueo amplio sea una decisión que puedas explicar, no una entrada misteriosa.

El decaimiento es lo que mantiene honesto todo el sistema. Significa que una escalada agresiva durante un ataque no se convierte en una cicatriz permanente, y que tu lista de bloqueo refleja quién es hostil ahora mismo y no quién lo fue alguna vez.

Para empezar esta semana

• Cambia la clave del limitador al /64. En todos los sitios donde ahora cuentas o bloqueas por dirección, enmascara primero IPv6 a sus primeros 64 bits. Este único cambio cierra el agujero de la rotación gratuita y suele ser cuestión de unas pocas líneas en nginx, HAProxy o tu app.
• Añade contadores acumulados para /56 y /48. Registra el abuso agregado a los prefijos padre para que un atacante que rota subredes active un límite más amplio, sin que tengas que ampliar por defecto.
• Consulta la red antes de ampliar. En cualquier escalada más allá del /64, comprueba asn_type / connection_type: agrega libremente en hosting, mantén un alcance estrecho en móvil y residencial, y nunca bloquees de forma estricta un rango de operador o de CGNAT.
• Puntúa los casos ambiguos. Cuando un prefijo sea compartido o de consumo, usa por dirección el fraud_score compuesto y el recommended_action en lugar de un bloqueo CIDR a lo bruto.
• Dale a cada bloqueo un decaimiento. Guarda la reputación de los prefijos con una vida media, actúa según la puntuación actual y deja que el espacio reasignado se limpie solo.

IPv6 no ha hecho más difícil la prevención del abuso, sino que ha cambiado la unidad. La dirección ya no es el usuario; el /64 sí. Cuenta eso, escala según las evidencias, pondera según el tipo de red y deja que el tiempo se encargue de perdonar. Entonces todas las defensas en las que ya confías en IPv4 vuelven a funcionar.

Preguntas frecuentes

¿Por qué no se puede limitar la tasa de una dirección IPv6 igual que la de una dirección IPv4?

Porque los dos protocolos reparten una cantidad de espacio de direcciones por usuario muy distinta. En IPv4, un abonado suele recibir una sola dirección, así que limitar por /32 (una única dirección) es limitar por usuario. En IPv6, a un solo abonado se le asigna habitualmente un /64 entero. Eso son 2^64, unos 18,4 trillones de direcciones, y herramientas como IP_FREEBIND permiten a un proceso originar tráfico desde cualquier dirección de ese bloque sin coste. Limitar la tasa o meter en una lista de bloqueo un /128 (una única dirección IPv6) no detiene nada: el abusador simplemente usa la siguiente de 18 trillones de direcciones. La unidad correcta en IPv6 es el /64, no el /128.

¿Con qué longitud de prefijo debo limitar la tasa de IPv6?

Empieza por el /64. El /64 es el bloque más pequeño que se garantiza que pertenece a un único usuario final, porque SLAAC exige un /64 completo por subred y los ISPs asignan al menos un /64 a cada cliente. Calcula tus contadores y listas de bloqueo sobre los primeros 64 bits de la dirección y trata todo el /64 como un único actor. Cuando el abuso persiste a lo largo de muchos /64 del mismo cliente, escala el alcance al /56 (256 /64) y después al /48 (65.536 /64), que son los tamaños típicos de una asignación doméstica o empresarial completa.

¿Es seguro bloquear un /64 de IPv6 entero?

Casi siempre sí, y es más seguro que bloquear una única dirección IPv4. Un /64 está pensado para ser la subred de un solo abonado, así que bloquearlo rara vez afecta a un tercero ajeno, como sí ocurre con una dirección IPv4 compartida por CGNAT. El riesgo real está en los prefijos más amplios: un /48 o un /32 puede ser un ISP entero, un operador móvil o un rango de hosting compartido que abarca miles de usuarios sin relación entre sí. Amplía el alcance solo cuando el tipo de red lo justifique: de forma agresiva en prefijos de hosting o datacenter, con cautela en los móviles y residenciales.

¿Cómo sé hasta qué amplitud escalar un bloqueo?

Deja que lo decidan dos cosas: la persistencia y el tipo de red. Persistencia: si el abuso sigue reapareciendo desde /64 nuevos dentro del mismo /56 o /48, toda esa asignación es una sola entidad y amplías hasta ella. Tipo de red: una consulta que devuelve un ASN de hosting o datacenter significa que el prefijo es infraestructura y puedes agregar hacia arriba rápidamente; un operador móvil o un ISP residencial significa que puede haber muchos usuarios reales detrás del prefijo más amplio, así que te mantienes en un alcance estrecho y te apoyas en una puntuación de riesgo en lugar de un bloqueo estricto.

¿El CGNAT y las redes móviles cambian cómo debo gestionar IPv6?

Sí, en el extremo amplio. Un único /64 de IPv6 es normalmente un solo abonado incluso en móvil, así que limitar por /64 sigue siendo correcto. Pero los operadores móviles y los despliegues de 464XLAT/NAT64 pueden colocar a muchos abonados bajo un prefijo más amplio compartido, así que un bloqueo de amplitud /48 o /32 sobre un ASN móvil puede dejar fuera a una gran parte de los clientes de un operador. La regla es la misma que en IPv4: nunca bloquees de forma estricta un rango compartido por culpa de un solo actor malicioso. Puntúalo y reserva los bloqueos amplios para los prefijos de infraestructura.

¿Cuánto tiempo debe permanecer bloqueado un prefijo IPv6?

No para siempre. Los prefijos IPv6 se reasignan, y un /64 que abusó de ti el mes pasado puede ser otro cliente el mes que viene. Asocia a cada prefijo una reputación que decae en lugar de una entrada permanente: súbele la puntuación ante el abuso, deja que baje con el tiempo si no ocurre nada malo y retira el bloqueo automáticamente cuando decaiga por debajo de tu umbral. Una lista de bloqueo permanente sobre un espacio de direcciones que rota se convierte poco a poco en una lista de direcciones a las que ya no puedes llegar con seguridad.