[Andromeda90]

Buenas,

Abro este hilo porque creo que hay un tema técnico que cada vez afecta a más gente: el uso de CG-NAT en IPv4.

Muchos usuarios ya no tenemos una IPv4 pública, tenemos una compartida, así que no podemos abrir puertos ni aceptar conexiones entrantes, lo que limita bastante la capacidad de compartir archivos. Sin embargo, en muchos casos sí tenemos IPv6 nativa, con dirección pública y accesible desde Internet.

El problema es que, si el tracker no soporta IPv6, esa conectividad no se puede aprovechar.

En realidad, desde el lado del usuario sería bastante simple:
solo habría que abrir el puerto en el firewall del router para permitir conexiones entrantes por IPv6 en el puerto que use el cliente BitTorrent. No hace falta NAT ni redirecciones.

Además, la mayoría de clientes actuales ya soportan IPv6 sin problema.

Creo que esto podría ayudar a que más usuarios puedan compartir correctamente, especialmente los que estamos detrás de CG-NAT.

Relacionado con esto, hay otro hilo que puede tener bastante que ver:

https://foro.unionfansub.com/showthread.php?tid=21556

Igual añadir soporte IPv6 podría ser parte de la solución o una mejora interesante a medio plazo.

Un saludo.

---

Por cierto, revisando cosas antiguas, hace unos años escribí este post en otro foro que creo que puede venir bien como referencia práctica sobre este tema:

https://bandaancha.eu/foros/abrir-puertos-bittorrent-digi-cg-nat-1748493

Básicamente explico cómo, aun estando detrás de CG-NAT en IPv4, se pueden recibir conexiones entrantes usando IPv6 simplemente creando una regla en el firewall del router para el puerto que use el cliente.

No es nada especial ni complicado, pero puede servir para entender por qué tener soporte IPv6 en el tracker sería útil para los que estamos en esta situación.

Lo dejo por aquí por si a alguien le resulta interesante o quiere probarlo.

---

Por aportar un ejemplo real, dejo esta captura de un archivo que estoy compartiendo actualmente en otro tracker


https://imgur.com/g8q6104

Como se puede ver, está recibiendo conexiones entrantes por IPv6 (Las tres primeras lineas IPv6), aun estando detrás de CG-NAT en IPv4.
En este caso simplemente tengo abierto el puerto correspondiente en el firewall del router.

Es decir, funcionar funciona sin problemas cuando hay soporte IPv6.

Lo comento porque puede servir como referencia práctica para los que estén en la misma situación.

[Hav4k]

¿Y usar alternativas autogestionadas como Pangolin con VPS que permita Torrent?

https://bandaancha.eu/foros/pangolin-alternativa-tuneles-cloudflare-1759621

Conste, no lo he probado y no śe con certeza si los administradores de Union Fansub lo permitirán en su tracker semiprivado.

Un cordial saludo.

[Kumicho]

IPv4 no puede comunicarse con IPv6, así que usar IPv6 dejaría fuera a mucho gente sin opción alternativa.

[Andromeda90]

(07 Apr 2026)Kumicho escribió:  IPv4 no puede comunicarse con IPv6, así que usar IPv6 dejaría fuera a mucho gente sin opción alternativa.

Permitir que el tracker registre IPv6 no implica en absoluto dejar de usar IPv4 ni cambiar el funcionamiento actual.

IPv4 y IPv6 coexisten sin problema. Los clientes que solo tengan IPv4 seguirán funcionando exactamente igual que ahora. Lo único que cambia es que los clientes que estén detrás de CG-NAT pero dispongan de IPv6 pública podrán recibir conexiones entrantes desde otros peers con IPv6, algo que con IPv4 no es posible en muchos casos.

Es decir, no se sustituye nada: se añade una opción adicional de conectividad.

Esto es especialmente útil hoy en día porque muchos ISP usan CG-NAT en IPv4, lo que impide abrir puertos entrantes, mientras que sí asignan IPv6 pública. Permitir IPv6 en el tracker simplemente aprovecha esa conectividad disponible.

De hecho, en la captura que adjunté se puede ver claramente que el cliente mantiene conexiones tanto IPv4 como IPv6 simultáneamente, y el estado es normal ("Both peers complete"). Eso demuestra que no hay incompatibilidad ni reemplazo, sino coexistencia.

[Kumicho]

Sí sustituye porque el usuario con IPv6 dejará de estar disponible para los clientes IPv4.

[Andromeda90]

(09 Apr 2026)Kumicho escribió:  Sí sustituye porque el usuario con IPv6 dejará de estar disponible para los clientes IPv4.

Yo creo que aquí se están mezclando dos cosas distintas.

He hecho una prueba descargando un torrent oficial de Ubuntu (que usa trackers con soporte IPv6), y como se puede ver en la captura, aparecen peers tanto con direcciones IPv6 como IPv4 al mismo tiempo. Es decir, el swarm funciona en dual-stack sin ningún problema.

https://ubuntu.com/download/alternative-downloads

Que un tracker soporte IPv6 no significa que todos los peers tengan que usar IPv6, ni que desaparezcan los IPv4. Cada cliente se conecta con lo que tenga disponible. Si uno solo tiene IPv4, se conecta por IPv4; si tiene ambas, usará ambas.

En resumen:

– Un tracker puede soportar IPv6
– Los peers pueden ser IPv4, IPv6 o ambos
– Ver direcciones IPv4 en un torrent con IPv6 es completamente normal

La captura que he puesto lo demuestra bastante claro.



https://imgur.com/a/xQASYnA

Por cierto, no se como hacer para que se vean las imagines en el foro

[Kumicho]

No has entendido lo que he dicho. Resumido: con CG-NAT IPv4 puede conectarse con alguien que tiene IPv6, sin CG-NAT no puede.

[Andromeda90]

(Hoy)Kumicho escribió:  No has entendido lo que he dicho. Resumido: con CG-NAT IPv4 puede conectarse con alguien que tiene IPv6, sin CG-NAT no puede.

¿Qué tiene que ver el CG-NAT con la conectividad IPv6?

Operadores como DIGI, por ejemplo, suelen tener a sus usuarios detrás de CG-NAT en IPv4. Hasta ahí, correcto.
Pero al mismo tiempo, esos mismos usuarios suelen disponer también de una dirección IPv6 pública, que permite recibir conexiones entrantes sin necesidad de abrir puertos en IPv4.

Un tracker, al final, es simplemente una guía telefónica.

Nada más sofisticado que eso.

En el caso del tracker del foro, esa guía contiene direcciones IP y puertos de escucha en IPv4 de los peers que están compartiendo el torrent.

Los trackers que soportan IPv6 lo único que hacen es ampliar esa agenda:

además de las direcciones IPv4, incluyen también las direcciones IPv6 de los usuarios que disponen de ellas y utilizan un cliente compatible.

No es algo especialmente exótico ni experimental; lleva funcionando así bastantes años.

Te pongo un ejemplo práctico.

El torrent del tracker del foro:

[Kakumei Subs] Sousou no Frieren S02

En el tracker del foro, únicamente aparecen direcciones IPv4.

Sin embargo, ese mismo torrent se ha compartido también en otro tracker que sí soporta IPv6, y en su lista se pueden ver usuarios compartiendo tanto mediante IPv4 como mediante IPv6.

Aquí se puede observar claramente cómo se está compartiendo usando ambos protocolos:

https://imgur.com/a/mR9oAck

Disculpad si puedo resultar insistente; simplemente intento explicar cómo funciona el mecanismo.

Al final, un tracker no deja de ser una lista de direcciones, y uno que soporta IPv6 es aquel que, además de devolver direcciones IPv4, también incluye las direcciones IPv6 de los usuarios que las tienen disponibles.

[Riyen]

El problema afecta a un subconjunto pequeño: usuarios con CG-NAT y con IPv6 pública funcional. Para ese subconjunto ya existen soluciones del lado del cliente (salir del CG-NAT por un euro, VPN con port forward, seedbox barato, Pangolin/WireGuard/Tailscale en un VPS gratuito tipo Oracle como comentaba el compañero, etc.) que no requieren tocar absolutamente nada del tracker.

Además, en un tracker de preservación de nicho -donde el valor no es la difusión masiva (como los que citas: Ubuntu, etc) sino mantener vivos torrents con dos o tres seeders- introducir IPv6 fragmenta el swarm. Los peers que solo anuncien por IPv6 (o añadiendo IPv4 tras un CGNAT) resultan invisibles para los usuarios solo-IPv4, que no son pocos: gente que desactiva la pila IPv6 por fugas de DNS, MTU rotos en túneles, problemas con VPN, clientes viejos o firewalls domésticos mal configurados. Hoy la regla implícita "si entras, contribuyes por IPv4" mantiene a todo el mundo en el mismo swarm por obligación; abrir IPv6 rompe esa cohesión, crea dos bandos asimétricos y hará que seeders sean inalcanzables.

Pero pongamos que se hiciera: añadir IPv6 a un tracker privado tampoco es activar un flag. Implica tocar el software del tracker (announce/scrape dual-stack, BEP 7/BEP 24), el frontend, el reverse proxy, el esquema de base de datos (peers con dos familias de direcciones en vez de una), la contabilidad de ratio y antitrampas (un mismo usuario ahora son dos endpoints, hay que correlacionarlos sin romper bans ni permitir doble cuenta), el sistema de moderación por IP, los logs, y probablemente el parser de announce si es custom. Todo eso sobre un stack que hoy asume IPv4 en muchos sitios implícitamente.

Personalmente, lo veo como un coste alto y concentrado en una persona (Kumicho), beneficio bajo y repartido entre pocos usuarios que además tienen alternativa, y encima con un efecto secundario negativo sobre la salud del swarm.

[XMX]

Diría que el mensaje de Ryen es una excelente explicación. Dudas aclaradas, al menos para mí.