Nunca nos quedamos sin direcciones. Nos quedamos sin ganas.

Hay una historia que la industria británica cuenta sobre IPv6, y va así. El cambio es difícil. El equipo es viejo. Los clientes no lo piden. No hay dinero en ello. Algún día, cuando el caso de negocio dé la vuelta, nos pondremos a ello.

Cada parte de eso es una mentira que la industria se cuenta a sí misma para no tener que hacer ningún trabajo.

IPv6 se especificó en diciembre de 1995. Yo llegué a él a través de la 6bone, el banco de pruebas experimental que lo llevaba antes de que la internet de verdad lo hiciera, y corrí tanto la pila de Linux como la pila de Microsoft Research en Windows XP para ver en qué se diferenciaban. Mi acceso vino de Hurricane Electric.

La 6bone se apagó el 6 de junio de 2006, así que me mudé al túnel automático 6to4, y más tarde a un túnel de Hurricane Electric — todavía gratis, y te enrutan un /48 con solo pedirlo. IPv6 nativo llegó a mi casa en 2017, cuando cambié de ISP a Zen.

Así que durante casi veinte años mi IPv6 vino de una empresa de tránsito estadounidense que lo regalaba, en vez de de cualquiera de los ISP británicos a los que pagaba. Hurricane Electric repartía /48 enrutados a cualquiera que quisiera uno. Mi propio proveedor me vendería una IPv4 estática por cinco libras al mes.

Las fechas dicen el resto. El IETF mató la 6bone en 2006 y dejó obsoletos los relés anycast de 6to4 en mayo de 2015, llamando al mecanismo «unsuitable for widespread deployment and use in the Internet» — inadecuado para el despliegue y el uso generalizados en internet. Sobreviví a dos mecanismos de transición oficiales esperando a que un ISP británico me diera una dirección. El día que la 6bone se apagó, treinta y siete de los cuarenta proveedores británicos del gráfico de abajo aún no habían pedido una asignación al registro. Veintidós de ellos — más de la mitad — no la pidieron hasta 2015 o después, el año en que el IETF también se rindió con 6to4.

Ha venido encendido por defecto en cada sistema operativo que alguien corre desde Windows Vista en 2007. No cuesta nada extra del registro. El ISP más grande que lo intentó en este país terminó el trabajo en tres años con un equipo que cabría en una sala de reuniones, y ganó un premio por ello.

Treinta años pasada la especificación. Catorce años pasado el día en que internet lo encendió de forma permanente. Y la respuesta en este país fue romper internet a propósito, envolver la parte rota en más maquinaria, y facturarle al cliente la molestia.

Eso no es un problema de coste. Es un problema de no dar la gana, y lleva pasando veinte años.

Lo que medí, y cómo

Todo lo de abajo es o trabajo de otro, enlazado, o un número que produje yo mismo. Donde es mío, el script que lo contó está en la descarga de abajo, corrido tal como se publica. La única excepción son los totales de direcciones, y explico cómo se calculan esos en las salvedades. Cuatro fuentes públicas, todas gratis: los ficheros de delegación del registro, el volcado de la tabla de enrutamiento de RIPE, la base de datos de RIPE, y el DNS. Donde tomé una muestra en vez de medirlo todo, lo digo.

Los números de enrutamiento vienen de dos conjuntos de ficheros públicos.

El primero son los ficheros de delegación, uno por registro regional, que listan cada bloque de direcciones y número de AS que ese registro ha repartido, el país al que está registrado, y un identificador opaco de la organización que lo tiene. El de RIPE cubre Europa y Oriente Medio, y es el que importa para el Reino Unido — pero unas pocas docenas de números de AS registrados en el Reino Unido están en los ficheros de ARIN y APNIC en su lugar, y la comparación más abajo necesita todos. Los míos se generaron el 26 y el 27 de agosto de 2026.

El segundo es el volcado de la tabla de enrutamiento global del Routing Information Service de RIPE, que lista cada prefijo en BGP y el número de AS que lo anuncia. IPv4 e IPv6 vienen como ficheros separados. El mío se generó a las 18:06 UTC del 27 de agosto de 2026.

Ponlos juntos y puedes responder una pregunta que nadie en la industria británica quiere que se haga en voz alta: de las redes que este país registró, ¿cuántas han encendido de verdad IPv6?

Saca los números de AS registrados a GB de los ficheros de delegación, saca cada número de AS que origina un prefijo de los volcados del RIS, y haz comm de las dos listas una contra otra por familia de direcciones. Eso da la primera tabla de abajo. Una trampa que vale la pena nombrar: ordena léxicamente, no con sort -n. comm compara cadenas, y una entrada ordenada numéricamente te da en silencio la respuesta equivocada en vez de un error que notarías.

Cambia GB por cualquier otro código de país y obtienes la fila de ese país en la tabla de comparación más abajo. 05-country-row.sh hace exactamente eso.

Los números a nivel de organización usan el octavo campo, que es el identificador opaco del registro para la cuenta que tiene cada recurso. Estos se quedan solo en el fichero de RIPE — los identificadores son locales a cada registro, así que concatenar cinco de ellos contaría la misma empresa dos veces en vez de fusionarla. Las organizaciones británicas son miembros de RIPE, así que RIPE es donde están. Así de muchas tienen un número de AS y nada de IPv6 en absoluto:

03-org-no-ipv6.sh las cuenta. Y 04-silent-holders.py es el que más importa. Las organizaciones que tienen IPv6, están vivas en BGP, y no anuncian nada de él.

Cuatro salvedades antes de los números, porque importan y prefiero decirlas a que me las echen en cara.

Los identificadores de organización son por cuenta de registro, así que una empresa que corre varias cuentas cuenta más de una vez.

Anunciar un prefijo IPv6 en BGP no es lo mismo que dar IPv6 a un cliente. Es el suelo, no el techo. Una red que no anuncia nada desde luego no lo ha desplegado. Una red que anuncia algo podría seguir estando sentada sobre ello.

Los totales de direcciones colapsan los prefijos solapados. Una red que anuncia un /16 junto a cuatro /17 sacados de él está anunciando 65 536 direcciones, no 196 608, y contar los prefijos ingenuamente infla a los grandes tenedores por dos o tres veces. Uso ipaddress.collapse_addresses de Python antes de sumar.

La lista de cincuenta sitios web de más adelante es una muestra que elegí a mano, no una medición de todo el país. Unos cincuenta distintos darían una fracción distinta. Ilustra un patrón en vez de probar una proporción, y nombro los que menciono según voy.

Los dos primeros de esos hacen los números de enrutamiento más amables con la industria que la verdad.

El recuento

Casi seis de cada diez redes británicas vivas no llevan IPv6 en absoluto. No parcialmente. No detrás de un flag. No en un laboratorio. Ni un prefijo.

Ahora la parte que acaba con el argumento del coste para siempre.

De las 2 363 organizaciones británicas que tienen un número de AS, 1 113 — 47,1 % — no tienen asignación de IPv6 de ningún tipo. Nunca se la han pedido al registro.

Una membresía del RIPE NCC cuesta 1 800 EUR al año para 2026, plana, y esa cuota cubre tus asignaciones. Un /29 de IPv6 te da 524 288 subredes del tamaño de toda la internet IPv4. Es gratis con una membresía que estas organizaciones ya están pagando, y llega en un par de días.

La mitad de ellas nunca rellenó el formulario.

Y de las que sí lo hicieron, 463 organizaciones británicas tienen espacio IPv6, anuncian IPv4 al mundo cada día, y no anuncian nada de IPv6 en absoluto. Eso es el 44,7 % de los tenedores de IPv6 británicos que están vivos en BGP.

Léelo otra vez, porque es todo el artículo en una frase. Pidieron las direcciones. Les dieron las direcciones. Las metieron en una hoja de cálculo. Luego nadie se molestó en teclearlas en un router.

No puedes explicar eso con dinero. Nadie gastó nada. No hay factura, ni compra, ni caso de negocio, ni petición de capital. Hay una cosa gratis sentada en una cuenta de registro, y un departamento de ingeniería que no ha abierto el ticket en catorce años.

Quién está en esa lista

Estas son las redes británicas más grandes que anuncian IPv4 y nada de IPv6, por la cantidad de espacio de direcciones que de verdad anuncian, el 27 de agosto de 2026. Los nombres vienen de la base de datos de RIPE, que te dirá quién tiene cualquiera de ellos:

curl -s https://rest.db.ripe.net/ripe/aut-num/AS15914.json \
  | python3 -c 'import sys,json; a=json.load(sys.stdin)["objects"]["object"][0]["attributes"]["attribute"]; print(next(x["value"] for x in a if x["name"]=="org"))'

Mira esa lista e intenta decir las palabras «barrera de coste» sin reírte.

Cuatro de los bancos de compensación. Una firma global de contabilidad cuyo producto entero es decirle a otra gente cómo llevar sus asuntos. Una empresa de tecnología de defensa. Un proveedor de hosting cuyos clientes le pagan por saber esto. Un negocio de conectividad de internet de las cosas, que vende tarjetas SIM, sin IPv6.

Entre todas, las redes británicas que no anuncian nada de IPv6 están sentadas sobre 4 232 232 direcciones IPv4. El mercado de transferencia promedió $20,04 por dirección en la primera mitad de 2026, así que eso es una tenencia que vale algo al norte de ochenta millones de dólares. Que es la razón real por la que ninguna de ellas se ha movido: son ricas en direcciones, así que la escasez es problema de otro, y la fontanería a largo plazo de internet no es el trabajo de nadie en particular.

Eso no es una estrategia. Eso es estar cómodo.

El fichero de delegación lleva la fecha en que cada bloque se repartió, así que puedes ver exactamente cuán cómodo:

grep -E '\|ipv4\|(141\.228|155\.131|155\.136|161\.2)\.0\.0\|' \
  delegated-ripencc-extended-latest | cut -d'|' -f4,5,6

Barclays ha tenido 141.228.0.0/16 desde el 6 de agosto de 1990. Nationwide y NatWest cogieron los suyos en noviembre de 1991, con cuatro días de diferencia. British Airways obtuvo 161.2.0.0/16 en abril de 1992. Estos son bloques clase B de antes de que existiera la web, repartidos cuando las direcciones eran gratis y nadie contaba.

Todo el que vino después de ellos paga por eso. AWS empezó a cobrar $0,005 la hora por cada dirección IPv4 pública el 1 de febrero de 2024 — $43,80 al año, cada una — y dijo claramente por qué: el coste de adquirir una «has risen more than 300% over the past 5 years» — ha subido más de un 300 % en los últimos 5 años. La escasez es real y tiene un precio. Solo que no la paga la gente que tiene cuatro millones de direcciones que consiguió gratis en 1991.

Cómo quedamos frente a países como nosotros

Dos números por país. El primero es la proporción de su gente que llega a Google por IPv6 nativo, que es la medición de Google el 25 de agosto de 2026. El segundo es la proporción de sus redes vivas que anuncian un prefijo IPv6, que es la mía, de los mismos ficheros de arriba. Lo he limitado a economías desarrolladas. Compararnos con países que llegaron tarde a internet no te dice nada sobre nosotros. Ordenado por gente.

Sexto de quince. Francia tiene la mitad más de su gente en IPv6 que nosotros, con la misma cadena de suministro europea, bajo los mismos proveedores de equipo, con los mismos clientes diciéndoles que nadie lo pide. Alemania está veintitrés puntos por delante de nosotros en usuarios y veintidós puntos por delante en redes.

Las dos columnas de porcentaje no concuerdan entre sí, y el desacuerdo es la historia.

El porcentaje de usuarios de un país lo fijan tres o cuatro empresas. El porcentaje de redes lo fija todo el mundo demás. Cuando el primero es alto y el segundo es bajo, significa que las grandes redes de acceso hicieron el trabajo y el resto del país fue de gorra sobre ellas.

Estados Unidos es el caso más claro: el 56,6 % de su gente está en IPv6 y solo el 25,9 % de sus redes lo está. Los operadores de cable y móvil llevan a casi todos. Las otras dieciocho mil redes estadounidenses no hicieron nada.

La nuestra es el mismo truco con números más pequeños — 53,7 % de usuarios contra 42,3 % de redes. Ese 53,7 % no es un logro nacional. Es Sky y BT, y un error de redondeo de todos los demás.

Noruega y Suecia son la contraforma honesta: menos usuarios en IPv6 que nosotros, más redes llevándolo. Más de su industria ha hecho de verdad el trabajo, y son los ISP de consumo los que van rezagados en vez del gremio.

Y una fila merece una mirada más de cerca, porque es la que la gente busca cuando quiere sentirse mejor sobre nosotros.

Corea del Sur es el peor país de esta lista, con diferencia. De 916 redes coreanas vivas, 61 anuncian IPv6. Sesenta y una.

Algo de la banda ancha doméstica más rápida de la Tierra, una industria de chips que imprime dinero, y el 94,7 % de sus redes nunca lo encendió. Los tres grandes operadores — KT, SK Broadband y LG U+ — lo anuncian todos, que es por lo que el 18,1 % de los usuarios coreanos lo tiene. Las otras ochocientas cincuenta redes no hicieron nada.

Sea cual sea la excusa ahí, no es el dinero, no es la capacidad, y no es el estado de la fibra.

Veinte años atornillando cosas

Aquí está lo que la industria construyó en vez de teclear las direcciones.

Cuando las direcciones empezaron a escasear, la respuesta fue el NAT a escala de operador: pon cientos de clientes detrás de una dirección IPv4 pública y traduce entre ellos. Todo lo de abajo existe para hacer eso sobrevivible, y cada uno de estos documentos es una pieza de trabajo de ingeniería que alguien eligió hacer en vez de desplegar IPv6.

Mira la forma de eso. Cada elemento de la lista es más difícil que la doble pila. Tunelizar IPv4 dentro de IPv6 es estrictamente más trabajo que enrutar IPv6, porque tienes que enrutar el IPv6 de todos modos para llevar el túnel. Traducir entre familias es más trabajo que no traducir. Un NAT a escala de operador es una caja con estado en medio de tu red, con planificación de capacidad, conmutación por error, tablas de sesión, asignación de bloques de puertos, pasarelas de capa de aplicación para los protocolos que rompe, y una tubería de logs dimensionada para una obligación legal.

La doble pila es una familia de direcciones, un protocolo de enrutamiento que ya corres, y una política de cortafuegos que ya escribiste.

La industria miró esas dos opciones y eligió la cara, veinte años seguidos, porque la cara se podía comprar y la barata había que entenderla. Comprar una caja es un ejercicio de compras. Encender IPv6 significa que alguien en el edificio tiene que saber cómo funciona la red.

Qué rompe esto de verdad

Para quien piense que esto es estética, aquí está lo que una dirección compartida le cuesta a tus usuarios, en el orden en que te van a llamar por ello.

Nada puede llegar desde fuera. Sin reenvío de puertos, así que nada autoalojado, ninguna consola de juegos actuando de host, ninguna VPN sitio a sitio sin un relé, ninguna cámara de seguridad sin la nube del fabricante, ningún acceso remoto a la cosa del otro emplazamiento. Cada una de esas se reemplaza por un servicio de encuentro de terceros, que es otra empresa que tiene tus datos porque tu proveedor no te dio una dirección.

Heredas las reputaciones de desconocidos. Comparte una dirección con unos pocos cientos de personas y compartes su comportamiento. Límites de tasa, CAPTCHA, bloqueos de Wikipedia, errores de geolocalización de streaming y puntuación de fraude te caen todos a ti por algo que hizo otro.

Los puertos se agotan. Un NAT a escala de operador tiene 65 535 puertos por dirección pública por protocolo, y una sola sesión de navegador moderno se come docenas. Sobresuscribe y el fallo no es un error limpio. Es un fallo lento, intermitente, irreproducible que parece todo excepto lo que es, y quema días de tiempo de soporte por incidente.

Cada apaño hay que mantenerlo para siempre, por gente que podría haber gastado ese tiempo en el arreglo.

Y luego está el que dejó de ser una molestia y se volvió el problema de todos. Nadie puede decir quién hizo qué.

El apaño que llegó al Parlamento

Una vez que cientos de clientes comparten una dirección, una dirección ya no identifica a nadie. Así que la policía no puede resolver una dirección IP a una persona, y la respuesta a eso no fue IPv6. Fue legislación.

La sección 21 de la Counter-Terrorism and Security Act 2015 enmendó el régimen de retención de datos específicamente para que el Secretary of State pudiera obligar a los proveedores a retener los datos extra necesarios «to link the unique attributes of a public Internet Protocol (IP) address to the person (or device) using it at any given time» — para enlazar los atributos únicos de una dirección IP pública con la persona (o dispositivo) que la usa en un momento dado. Las notas explicativas son tajantes sobre por qué hacía falta: los proveedores «may share IP addresses between multiple users, and the providers generally have no business purpose for keeping a log of who used each address at a specific point in time» — pueden compartir direcciones IP entre varios usuarios, y generalmente no tienen razón comercial para llevar un registro de quién usó cada dirección en un momento concreto.

Léelo como un ingeniero en vez de como un abogado. La industria rompió la atribución para ahorrarse trabajo, y el Parlamento aprobó una ley que la obliga a construir un sistema de logs para tapar la rotura.

Dos años después Europol lo dijo claro. En octubre de 2017 publicó una llamada a la industria para dejar de usar el NAT a escala de operador, con cifras: el 90 % de los proveedores de acceso a internet móvil y el 50 % de los de línea fija habían adoptado una tecnología que les impedía identificar a sus propios abonados. El entonces director ejecutivo de Europol dijo que el CGN «has created a serious online capability gap in law enforcement efforts to investigate and attribute crime» — ha creado una grave brecha de capacidad en línea en los esfuerzos de las fuerzas del orden para investigar y atribuir el delito —, y señaló que «forces judiciary and law enforcement authorities to investigate many more individuals than would normally be necessary» — obliga a las autoridades judiciales y policiales a investigar a muchos más individuos de los que normalmente sería necesario.

Europol también dijo la parte callada. El NAT a escala de operador «was supposed to be a temporary solution until the transition to IPv6 was completed» — se suponía que era una solución temporal hasta que se completara la transición a IPv6. En cambio la industria siguió aumentando su uso mientras el reemplazo estaba ahí, terminado, gratis e ignorado.

Así que el coste de no desplegar IPv6 incluye: una pieza de legislación primaria, una obligación de retención a escala nacional, gente inocente arrastrada a investigaciones porque compartió una dirección con alguien que no era inocente, y una brecha de capacidad continua que la policía describe como un problema de seguridad pública.

Nadie puso eso en el caso de negocio. Nunca aparece en la diapositiva de «IPv6 no tiene retorno de inversión», porque no lo pagan los que lo causaron.

No solo esconde a los criminales. Los ayuda.

El argumento de la atribución es el que hacen las fuerzas del orden, y va de coger a la gente después del hecho. Hay un segundo argumento que se hace mucho menos a menudo y es peor: compartir direcciones degrada activamente las defensas que impiden que los ataques ocurran siquiera.

Este no es mi análisis. El IETF publicó el catálogo en RFC 6269, Issues with IP Address Sharing, en junio de 2011. Eso fue antes de que el Reino Unido desplegara la mayor parte del NAT a escala de operador que ahora corre. Sus palabras llanas: compartir direcciones «creates a vector for attack amplification in numerous ways» — crea un vector para la amplificación de ataques de numerosas maneras.

Aquí está lo que advirtió que se rompería, y se rompió.

Los límites de tasa y los bloqueos dejan de funcionar. La defensa estándar contra la adivinación de contraseñas y el relleno de credenciales es contar los fallos por dirección y meter al infractor en un rincón de penalización. Comparte esa dirección entre cientos de personas y el contador está midiendo una multitud. El RFC 6269 es tajante sobre el resultado: «In the presence of widespread large-scale address sharing, penalty box solutions to service abuse simply will not work» — en presencia de un uso compartido de direcciones generalizado y a gran escala, las soluciones de rincón de penalización contra el abuso de servicio simplemente no funcionarán. Los inicios de sesión fallidos de un usuario bloquean a todos los demás, así que los operadores suben los umbrales, y subir los umbrales es lo que el atacante quería.

El bloqueo por listas se vuelve daño colateral. Bloquea al spammer y bloqueas la calle en la que vive. Así que el operador sensato deja de bloquear, y el abuso continúa desde una dirección que nadie se atreve a tocar.

Las máquinas infectadas se quedan infectadas. Los feeds de abuso y las notificaciones de malware llegan como una dirección y una marca de tiempo. Detrás de un CGN sin registro de puertos, el proveedor no puede decir cuál de sus clientes corre el bot, así que al cliente nunca se le avisa y la infección sigue arriba. Peor, el RFC 6269 nota el problema inverso: «someone else’s worm can interfere with the ability to access the service for other subscribers sharing the same IP address» — el gusano de otro puede interferir con la capacidad de acceder al servicio para otros abonados que comparten la misma dirección IP.

El control de acceso basado en direcciones falla. Cada lista de permitidos construida sobre la dirección de origen ahora admite una multitud en vez de un cliente.

Y una defensa se debilita de forma medible en vez de solo embotarse. Los ataques TCP a ciegas dependen de adivinar la quíntupla, y la mitigación de la industria es aleatorizar el puerto de origen (RFC 6056). Un NAT a escala de operador le da a cada abonado una porción del rango de puertos en vez de todo él. En palabras del RFC 6269, «with shared IPv4 addresses, the port selection space is reduced» — con direcciones IPv4 compartidas, el espacio de selección de puertos se reduce. El apaño para la escasez de direcciones saca entropía directamente de un mecanismo antiataque.

Luego está la parte que debería preocupar a cualquiera, independientemente de lo que piense sobre la policía. Si el servidor no registró los puertos de origen y el NAT no registró los destinos, el RFC 6269 deletrea lo que un proveedor debe hacer cuando llega una solicitud legal: «would need to disclose the identity of all subscribers who had active sessions on the NAT during the time period in question. This may be a large number of subscribers» — tendría que revelar la identidad de todos los abonados que tuvieron sesiones activas en el NAT durante el periodo en cuestión. Esto puede ser un número grande de abonados.

La alternativa a identificar a un abonado culpable es entregar las identidades de varios cientos de inocentes. Ese es el resultado real de privacidad de compartir direcciones, y es lo opuesto del que sus defensores le atribuyen.

Tres cosas tienen que alinearse, y nadie está obligado a proveer ninguna

La gente asume que los logs existen en algún sitio y es cuestión de pedirlos. En su mayoría no existen, y la razón es aritmética en vez de mala voluntad.

Para convertir una dirección compartida de vuelta en un hogar, tres cosas separadas deben haber ido todas bien:

1. El servidor del otro extremo registró el puerto de origen. RFC 6302 pidió a los servidores de cara a internet que registraran el puerto de origen y la marca de tiempo junto a la dirección, en 2011. Es una recomendación. Nadie la hace cumplir, y muchísimos servidores todavía registran solo la dirección. En cuyo punto el rastro está muerto antes de llegar al extremo británico.
2. El proveedor guardó el mapeo. Cada sesión, durante meses.
3. Los relojes concordaron. El RFC 6269 advierte que en un CGN ocupado «even very small amounts of clock skew between a third party’s server and the CGN operator will result in ambiguity about which customer was using a specific port at a given time» — incluso cantidades muy pequeñas de desfase de reloj entre el servidor de un tercero y el operador del CGN resultarán en ambigüedad sobre qué cliente usaba un puerto concreto en un momento dado.

Falla cualquiera y no tienes nada. Y la del medio es donde se desmorona, porque los documentos de estándares contienen las cuentas.

RFC 7422 puso números reales. Los operadores reportaron unas 33 000 conexiones por hogar al día. A unos 150 bytes por entrada de log eso son 5 MB por abonado al día, 150 MB al mes. Para un proveedor con un millón de abonados: 150 terabytes de logs al mes, 1,8 petabytes al año — para guardar durante los seis a doce meses que la ley espera, y buscar bajo demanda.

Y nunca es un solo log. NAT444, el caso para el que el RFC 7422 dimensiona sus entradas, pone una traducción en el router del cliente y otra en el operador, y cada puerta que un paquete cruza tiene que anotar lo que hizo. Reconstruir una sola sesión significa correlacionar tablas separadas, guardadas por partes separadas, contra el problema de los relojes de arriba. La evidencia llega en pedazos de sistemas distintos, o no llega.

Y el dinero es solo la mitad. Capturar registros de sesión a esa tasa, enviarlos a algún sitio, indexarlos para que una solicitud legal vuelva en horas en vez de semanas, y guardar el lote durante un año es un proyecto de ingeniería de datos. No hay panel para ello y no hay caja que comprar. Tiene que construirlo alguien que entienda lo que está construyendo, y eso no es apuntar y hacer clic, lo que en esta industria está bastante cerca de decir que no se construye.

Nadie iba a pagar por ello tampoco. Y el IETF lo sabía, que es por lo que RFC 6888 dice a los operadores lo opuesto de lo que la seguridad pública necesita: «A CGN’s port allocation scheme SHOULD minimize log volume» — el esquema de asignación de puertos de un CGN DEBERÍA minimizar el volumen de logs, justificado porque «huge log volumes can be problematic to CGN operators» — los volúmenes enormes de logs pueden ser problemáticos para los operadores de CGN. El RFC 7422 existe con el único propósito de recortar esa factura.

Así que el consejo de diseño a la industria es registrar menos, la economía dice que 1,8 petabytes al año es inasumible, y la expectativa legal es un registro completo. Esas no pueden ser todas ciertas a la vez, y la que cede es el registro.

Por eso Europol encontró que la mayoría de los proveedores de acceso no pueden identificar a un abonado cuando se les sirve una orden legal. No porque sean obstructivos. Porque lo que se pedía nunca fue económicamente posible de guardar, y a nadie se le obligó nunca.

Dos cosas se siguen de eso, y son mías en vez de la cita de nadie.

Primero: una gran parte de las conexiones a internet británicas son inatribuibles por construcción. El móvil es el caso más claro, y la medición independiente lo pone más alto que Europol, en el 95 %. Así que el anonimato que solía requerir Tor, o una VPN que alguien tenía que comprar, es ahora el ajuste de fábrica en una conexión móvil británica — emitido gratis con la SIM, a todos, incluida la pequeña cantidad de gente que todo el aparato se supone que debe encontrar.

Segundo, y peor: romper el método barato y dirigido es lo que produce la demanda del caro e indiscriminado. Cuando puedes servir una orden sobre una dirección y obtener un hogar, no necesitas nada más. Cuando eso deja de funcionar, el Estado no se encoge de hombros. Echa mano de algo más amplio. Eso es lo que fue la Ley de 2015: un deber de retención sobre toda la base de abonados, para responder preguntas sobre un puñado de personas.

Nada de eso existe en el otro lado. Nada se traduce, así que no hay ningún registro por conexión que guardar en absoluto. La dirección en el log del servidor del otro extremo ya es el prefijo del abonado: un registro, escrito una vez cuando la línea se aprovisionó, en un sistema. Incluso un proveedor que rota prefijos a diario escribe unos pocos cientos al año por cliente, contra los doce millones a los que llegan 33 000 conexiones al día. No es que IPv6 registre menos. No hay nada que registrar.

La gente que escribió el apaño lo sabía. En medio de una especificación escrita sin más razón que hacer el CGN asequible de registrar, se pararon a anotar que «native IPv6 will offer subscribers a better experience than CGN» — el IPv6 nativo ofrecerá a los abonados una mejor experiencia que el CGN.

Una industria declinó gastar una quincena por red en un protocolo gratis, y el país obtuvo un régimen de retención de datos en su lugar.

¿Arreglar esto protegería a los niños mejor que la Online Safety Act?

Quiero tener cuidado aquí, porque es fácil hacer este argumento mal y la versión mal hecha merece la paliza que se llevaría.

Empieza con cómo corre de verdad una investigación de abuso infantil. Una plataforma detecta el material y lo denuncia. La denuncia lleva una dirección y una marca de tiempo. La policía sirve al proveedor de acceso para convertir eso en un abonado, y el abonado es una dirección en el mundo real con una puerta. Esa es toda la cadena, y cada paso después depende del anterior.

Ahora pon un NAT a escala de operador en el medio. La denuncia sigue llegando. La dirección sigue resolviendo. A varios cientos de hogares, y Europol encontró investigaciones «dropped or delayed» — abandonadas o retrasadas — como resultado. Sus ejemplos de casos incluyen un fiscal incapaz de identificar a los miembros de un foro que apoyaba a ISIS, así que la acusación no ocurrió, y HMRC rastreando fraude fiscal masivo a direcciones móviles y encontrando las pistas «frustrated from the outset» — frustradas desde el principio.

La CyberTipline de NCMEC recibió 21,3 millones de denuncias en 2025 y refirió más de 18,8 millones a las fuerzas del orden, incluidas más de 53 000 que involucraban a un niño en peligro inmediato. NCMEC también registra que más del 10 % de las denuncias de la industria llegaron con información demasiado pobre para averiguar a qué jurisdicción enviarlas. Esa cifra no es cosa del CGNAT y no afirmo que lo sea — pero te dice en qué parte de esta tubería mueren los casos. Mueren en los metadatos.

Así que la versión honesta de la comparación es esta. El NAT a escala de operador rompe la propia última milla de la Online Safety Act. El Parlamento ha impuesto deberes de detectar y denunciar, y ha dejado la red de acceso incapaz de resolver lo que se denuncia. Puedes aprobar tantos deberes de denuncia como quieras. Si el paso final devuelve una multitud, la denuncia es papel.

Y el coste de las dos cosas no es ni remotamente comparable. La Ley es la mayor pieza de regulación de internet que este país ha intentado — miles de servicios en su alcance, un regulador escribiendo códigos durante años, verificación de edad corriendo a millones de comprobaciones al día, y un problema de elusión lo bastante grande como para que el Parlamento haya debatido el uso de VPN en los Lores. IPv6 no cuesta nada del registro y le lleva a un equipo competente un par de semanas. Una de esas se le ha exigido a toda la industria. La otra nunca se le ha pedido a nadie.

Tres cosas hay que decir claramente, porque el argumento no vale nada sin ellas.

Uno. No es un sustituto, y no lo propongo como tal. IPv6 no hace nada para impedir que un niño de doce años encuentre pornografía. No hace nada sobre los sistemas de recomendación, la reproducción automática o el streaming en vivo. No hace nada sobre el material alojado en otro país, que es la mayor parte. Esos son los problemas para los que la Ley se escribió y ningún cambio de protocolo los toca.

Dos. IPv6 no es una capa de identidad, y quien lo venda como tal lo está vendiendo de más. Las extensiones de privacidad rotan la dirección de un dispositivo por diseño, así que la dirección de la máquina no es la cosa estable. Lo estable es el prefijo delegado a la línea — el /56 que Sky ha estado dando a cada abonado desde 2016. Eso resuelve a un abonado, que es exactamente la resolución que una solicitud legal necesita, y nada más. Es una restauración de lo que una sola dirección IPv4 por línea solía dar, no una nueva capacidad de vigilancia.

Tres. La propiedad que frustra a la policía también frustra a todos los demás que te rastrean, y hay gente que lo valora. Ser uno de quinientos detrás de una dirección compartida es cobertura de multitud genuina contra el perfilado comercial. No creo que valga lo que cuesta — es cobertura comprada haciendo el abuso inatribuible y los límites de tasa inútiles, y es cobertura que las plataformas en su mayoría atraviesan igualmente con cookies y huellas digitales. Pero es un argumento real y merece decirse en vez de ignorarse.

Así que no, esto no es IPv6 en vez de la Online Safety Act. Es que Gran Bretaña escribió la ley de seguridad en línea más cara de su historia sobre una fontanería que sabía rota, cuando el arreglo era gratis, bien documentado, y estaba disponible todo el tiempo que se redactaba el proyecto de ley.

Qué pedir en realidad

No una prohibición. Una prohibición es el instrumento equivocado y saldría por la culata.

No queda IPv4 para repartir — RIPE está vacío desde noviembre de 2019, y un proveedor nuevo obtiene un solo /24 de una lista de espera. Proscribe el uso compartido de direcciones mañana y el pequeño operador no puede conectar clientes en absoluto, mientras que las empresas sentadas sobre bloques clase B de 1990 siguen intactas. Atrincheraría exactamente a la gente de la que va este artículo.

El mejor instrumento ya existe y alguien ya ha corrido el experimento.

En 2012 la policía federal de Bélgica, su regulador de telecomunicaciones, su Consejo de Fiscales Generales y su asociación de ISP firmaron un código de conducta voluntario de dos páginas. Máximo 16 abonados detrás de una dirección IPv4. Limitar el uso de CGN. Empezar a adoptar IPv6.

Para 2017 la mayoría de los operadores belgas estaban dentro del límite, uno había bajado a 8, y la policía belga veía una media de cuatro usuarios por dirección móvil. El propio resumen de Europol de por qué es la parte que vale la pena leer dos veces: los mayores proveedores «are quickly moving towards IPv6 because no financial interest to invest in CGN anymore» — se mueven rápido hacia IPv6 porque ya no hay interés financiero en invertir en CGN. Limita la sobresuscripción y la economía del apaño se derrumba, porque un NAT que solo puede apilar dieciséis personas no es más barato que el protocolo que no necesita ninguna.

Ese año Bélgica tenía la mayor adopción de IPv6 del mundo con el 49 %, cuando Gran Bretaña y Francia estaban en el 14 % y España e Italia estaban por debajo del 1 %. Bélgica sigue siendo tercera en la tabla de países de arriba, con el 72,8 %.

Esa es la petición. No «no puedes compartir direcciones» — no puedes vender una conexión que es a la vez inatribuible y no tiene IPv6. El direccionamiento compartido junto a un IPv6 que funciona está bien. Así es como opera cada red móvil de la Tierra. El direccionamiento compartido sin IPv6 es vender un servicio roto y cobrarle al público las consecuencias.

Sky demostró que se podía hacer, hace once años

Si de verdad fuera difícil, nadie en el Reino Unido lo habría logrado.

Sky empezó un proyecto interno de IPv6 a principios de 2013 y terminó en 2016, con aproximadamente el 90 % de su base de línea fija — unos cinco millones de usuarios — recogiendo IPv6 y usándolo. Su ingeniero lo escribió todo en RIPE Labs: 6PE por el núcleo MPLS, peering y tránsito con doble pila, atributos RADIUS para habilitarlo por abonado, trabajo de firmware en siete modelos de CPE incluidos cinco heredados, y mejoras de capacidad en RADIUS y DNS.

Tres años, un ISP, y el mismo cobre de Openreach sobre el que todos los demás vendían. ISPreview reportó el final en septiembre de 2016, con Sky esperando el 95 % de su base para el final de ese año, y Sky se llevó el premio Jim Bound IPv6 por ello.

Su consejo fue: «Do not underestimate the work required to enable IPv6, and do not leave it to the last minute to begin the journey» — no subestimes el trabajo que hace falta para habilitar IPv6, y no lo dejes para el último minuto para empezar el viaje.

Once años después, la mayor parte de la industria sigue en el último minuto, y tratándolo como un sitio donde vivir.

Todo el mundo ha tenido las direcciones durante años

Sky fue el primero de los grandes ISP. No estuvo ni cerca de ser el primero del país, y ni un proveedor de esta lista puede decir que estaba esperando al registro.

RIPE estampa la fecha de asignación en el nombre del bloque, así que puedes comprobar cualquiera de ellos tú mismo:

whois -h whois.ripe.net 2a01:4b00::/32 | grep -E 'netname|^org:'
# netname:  UK-BCUBE-20110225   -> Hyperoptic, allocated 25 February 2011

Cada fecha de abajo vino de esa consulta contra la propia asignación del proveedor, cotejada contra el fichero de delegación. Los grandes ISP están en negrita, el resto son los constructores de fibra completa. Si los clientes obtienen de verdad IPv6 viene de la encuesta de ISPreview según se actualizó en marzo de 2025, y del rastreador móvil para las redes de teléfono.

Cuarenta proveedores. Cada uno ha tenido espacio de direcciones IPv6 durante al menos tres años, la mayoría durante más de una década — y diecisiete de ellos todavía no se lo dan a un cliente.

Hyperoptic ha tenido 2a01:4b00::/32 desde febrero de 2011. Quince años construyendo fibra en bloques de pisos, vendiendo conexiones gigabit, y poniendo a la gente detrás de un NAT a escala de operador con una asignación IPv6 sin usar en los libros. Trooli ha tenido el suyo trece años. Truespeed y Airband diez.

Andrews & Arnold es contra quien medir al resto. Un pequeño ISP en Bracknell con una fracción de los clientes y los ingenieros de cualquier otro de esa lista, dando IPv6 a cada línea desde 2002, y una de las empresas detrás de 6UK. TalkTalk cogió su asignación tres meses antes y todavía no la entrega a los consumidores.

Virgin Media cogió su bloque tres semanas antes de que Zen cogiera el suyo. Zen lo entregó, y yo he estado al final de uno de sus /48 desde entonces. Virgin sigue diciendo «cuando estemos listos».

Y mira el fondo de la tabla. Squirrel, brsk, Lit Fibre y Octaplus consiguieron todos sus asignaciones en los últimos seis años y todos entregan IPv6, mientras que proveedores que tienen espacio desde 2011 no lo hacen. Empezar tarde no es el obstáculo. Empezar siquiera lo es.

Dos nombres de esa encuesta no están en el gráfico, y la razón es la misma para ambos. Cuckoo es una marca minorista que compra acceso mayorista sobre Openreach, CityFibre y otros, y Freedom Fibre es una red mayorista cuyos clientes vienen a través de socios minoristas. Ninguno tiene su propio espacio de direcciones, así que IPv6 es una decisión de otro para ellos. iDNET está marcado con un asterisco porque el suyo es una asignación independiente de proveedor en vez de una asignación propia.

El que lo zanja

Si quieres el argumento reducido a una sola empresa, es Plusnet.

BT compró Plusnet en enero de 2007. Plusnet está bajo la propia cuenta RIPE de British Telecommunications, así que ha tenido acceso a la asignación IPv6 de BT desde junio de 2010. BT entrega IPv6. EE, la otra empresa hermana, entrega IPv6. ISPreview notó que BT y Plusnet incluso usan routers de cliente casi idénticos, llamando al hueco «somewhat of a peculiarity» — algo así como una peculiaridad.

Plusnet probó IPv6 en 2011 y urgió públicamente al resto de la industria a ponerse a ello. En 2019 dijo que lo lanzaría en la primavera de 2020. En 2021 esperaba «to make good progress over the coming year» — hacer buen progreso a lo largo del próximo año. En noviembre de 2023 corrió una prueba de tres meses en dos emplazamientos en Chesterfield y Sheffield, con unos veinte empleados y clientes amistosos.

En abril de 2026 su propio foro de clientes seguía preguntando dónde había ido a parar IPv6.

Una empresa matriz. Una asignación de direcciones. Hardware casi idéntico. Ingenieros que trabajan para el mismo grupo y pueden bajar por el pasillo hasta la gente que ya lo hizo. Tres marcas, y una de ellas no puede gestionar en quince años lo que las otras dos terminaron.

Sea lo que sea lo que detiene esto, no es la tecnología, el dinero, el equipo, ni el espacio de direcciones. Es alguien decidiendo que no es su problema este trimestre, quince años seguidos.

Virgin Media, dieciséis años de «cuando estemos listos»

El otro extremo de la escala merece nombrarse, porque la cronología es cuestión de registro público y es notable.

Marzo de 2010: un cliente pregunta en el propio foro de Virgin Media cuándo llega IPv6. La respuesta es «cuando estemos listos».

Noviembre de 2016: Virgin le dice a ISPreview que planea adoptar IPv6 para mediados de 2017. No lo hace.

Junio de 2018: se reporta una prueba de consumo. Diciembre de 2018: una tercera presentación al UK IPv6 Council, insinuando 2019.

2021: una declaración de que están «continuing to plan our IPV6 deployment having tested several solutions and intend to introduce IPV6 for our customers in future» — continuando planeando nuestro despliegue de IPV6 habiendo probado varias soluciones y con la intención de introducir IPV6 para nuestros clientes en el futuro.

Febrero de 2024: Virgin Media bloquea el hilo del foro de catorce años.

Agosto de 2026: todavía nada.

Dieciséis años. En ese tiempo la empresa fue comprada, se fusionó con O2, reconstruyó su núcleo dos veces y reemplazó todo su parque de routers. En ningún momento nadie añadió una familia de direcciones. Bloquear el hilo es la cosa más honesta de esa lista. Es el momento en que dejaron de fingir y empezaron a gestionar la queja en vez del problema.

Los altnets no tenían excusa alguna

Los constructores de fibra completa eran la oportunidad de empezar limpio. Redes nuevas, equipo nuevo, sin legado, ingenieros contratados esta década. Mira dónde se sientan en la tabla de asignaciones y la mayoría de ellos cogió el espacio de direcciones y se paró.

Así que una empresa que levantó dinero institucional para construir una red de fibra nuevecita levantó las calles, sopló fibra a cien mil hogares, compró routers nuevos, escribió una pila de aprovisionamiento nueva. Y puso a sus clientes detrás de una dirección compartida en una red sin IPv6, en 2026, con el espacio de direcciones ya sentado en su propia cuenta de registro.

Y luego varios de ellos cobran £5 al mes por una IPv4 pública estática.

Quitaron la cosa que funcionaba, declinaron entregar el reemplazo gratis, y convirtieron la rotura resultante en una partida de tu factura. Hay una palabra para un modelo de negocio que fabrica un fallo y luego vende el arreglo, y no es «innovación».

Los sitios web lo delatan

La tabla de enrutamiento muestra lo que hacen las redes. El DNS muestra lo que hacen todos los demás. Así que el 27 de agosto de 2026 puse cincuenta de los sitios más conocidos del Reino Unido en un fichero — administración central, los bancos, los grandes minoristas, las telecos, transporte y unas pocas universidades — y le pregunté a cada uno si responde en IPv6:

while read -r d; do
  n=$(dig +short AAAA "$d" | grep -c ':')
  printf '%-46s %s\n' "$d" "$([ "$n" -gt 0 ] && echo AAAA || echo none)"
done < sites.txt | sort -k2

Luego comprobé cada respuesta contra un segundo resolutor, porque un servidor recursivo teniendo un mal día no es un hallazgo:

dig @1.1.1.1 +short AAAA www.tesco.com | grep -c ':'

Diecisiete de cincuenta tenían un registro AAAA. Treinta y tres no, y ambos resolutores coincidieron en cada uno.

Los que no tienen IPv6 incluyen www.bbc.co.uk, www.nhs.uk, www.hmrc.gov.uk, www.hsbc.co.uk, www.barclays.co.uk, www.lloydsbank.com, www.santander.co.uk, www.tesco.com, www.johnlewis.com, www.marksandspencer.com, www.britishairways.com, tfl.gov.uk, monzo.com — un banco fundado en 2015, sin nada heredado — y, mi favorito, www.sky.com.

Sky. La empresa que puso cinco millones de clientes en IPv6 y ganó un premio por ello. Su propio sitio web no responde en IPv6.

Ahora la parte que prueba la tesis más allá de toda discusión.

Quince de los diecisiete que sí tienen IPv6 lo consiguieron de un proveedor, no de sí mismos. Resolví cada uno y busqué quién posee la dirección que respondió:

whois -h whois.radb.net -- "$(dig +short AAAA www.sainsburys.co.uk | grep ':' | head -1)" | grep -i descr

www.gov.uk y www.cam.ac.uk responden desde Fastly. ico.org.uk, www.parliament.uk, www.ofcom.org.uk, www.asda.com, www.autotrader.co.uk, www.nationalrail.co.uk y www.jisc.ac.uk responden desde Cloudflare, que enciende IPv6 para todos por defecto. natwest.com y nationwide.co.uk responden desde Azure Front Door. www.legalandgeneral.com y www.screwfix.com responden desde CloudFront. www.sainsburys.co.uk y www.next.co.uk responden desde Akamai.

Dos lo hicieron ellos mismos: Imperial College London, respondiendo desde su propio espacio de direcciones, y el propio sitio del UK IPv6 Council. Una universidad y la gente cuyo propósito entero es IPv6. Esa es la lista.

Y www.tesco.com, www.sky.com y www.nhs.uk también están en Akamai — el mismo CDN, el mismo producto — y no tienen nada de IPv6.

Akamai ha sido explícito sobre esto desde junio de 2022: «Akamai has enabled IPv4+IPv6 dual-stack as the default for our CDN delivery products for many years, meaning that customers have needed to opt-out for content to be IPv4-only» — Akamai ha habilitado la doble pila IPv4+IPv6 por defecto en sus productos de entrega CDN desde hace muchos años, lo que significa que los clientes han tenido que optar por salirse para que el contenido sea solo IPv4. Añadieron que hicieron el cambio fácil, incluso a través de la API.

Mismo proveedor. Misma plataforma. Encendido por defecto. Una organización lo dejó en paz y otra entró y lo apagó, o mantuvo una configuración antigua que nadie ha leído desde entonces. Sainsbury’s tiene IPv6 y Tesco no, y la diferencia entre ellos es un solo flag de configuración y la atención de alguien.

Después de eso no queda argumento de coste ni argumento de complejidad en pie. Solo queda si alguien estaba prestando atención.

En toda la muestra la regla se sostiene: donde IPv6 llega como el valor por defecto de un proveedor, Gran Bretaña lo tiene. Donde una organización británica habría tenido que decidir algo, no lo tiene. Dos sitios de cincuenta, y uno de esos era el IPv6 Council.

Lo que nos lleva a la industria del servicio gestionado

Los ISP de consumo se llevan la culpa del CGNAT, y se la han ganado. Pero la capa que hace más daño es la que vende experiencia: los proveedores de servicios gestionados, los integradores, los equipos de red subcontratados, las consultorías que escriben el diseño de bajo nivel.

Vuelve a la lista de las redes británicas más grandes sin IPv6 — los bancos, British Airways, PwC, QinetiQ. Esas no son startups improvisadas. Son empresas que pagan un montón de dinero para que otro lleve su red, o emplean un gran equipo para llevarla ellas mismas. Cada uno de esos números de AS tiene un documento de diseño detrás, un proceso de cambios, una junta de revisión de arquitectura, y un proveedor con «red» en su nombre. Ni uno de ellos produjo un plan de IPv6.

El patrón es el mismo dondequiera que lo mires:

La plantilla es IPv4. El estándar de construcción, el conjunto de reglas del cortafuegos, las comprobaciones de monitorización, el IPAM, el runbook, el plan de recuperación ante desastres, el paquete de entrega al cliente — todo IPv4, escrito una vez, clonado durante una década. Añadir una familia de direcciones significa editarlo todo, y a nadie le pagan por editarlo.

Nadie lo pidió. Esta es la frase que acaba cada conversación de IPv6 en esta industria, y es una confesión. Nadie pidió TLS 1.3 tampoco. Nadie te pidió que dejaras de usar SMBv1. Los clientes compran el resultado y te pagan por saber lo que el resultado exige. «El cliente no lo pidió» significa «no quiero aprenderlo y ellos no pueden decírmelo».

RFC 1918 se siente infinito. El diez-punto son 16,7 millones de direcciones, así que una red interna nunca se siente escasa, así que nunca hay un evento forzoso. Luego llega la fusión, ambos parques están en 10.0.0.0/8, y la respuesta es otra década de NAT de subredes solapadas y un documento explicando qué dirección falsa significa cuál real — más maquinaria, otra vez, para evitar la familia de direcciones que lo habría hecho un no-problema.

IPv6 expone la competencia. Este es el de verdad. La doble pila no te deja esconderte.

Tienes que saber qué es de verdad tu política de cortafuegos, porque tienes que escribirla dos veces. Tienes que saber qué aspecto tiene tu DNS. Tienes que entender el descubrimiento de vecinos, la delegación de prefijos, y qué hace tu CPE con un /56.

Un ingeniero que se ha ido tirando con el NAT como un control de seguridad accidental se entera, delante de gente, de que nunca lo fue. Hay carreras de veinte años en esta industria construidas sobre esa única confusión.

Así que no se propone. No porque cueste dinero — no cuesta — sino porque proponerlo significa hacerse dueño de ello, y hacerse dueño de ello significa aprenderlo.

Eso es lo que quiero decir con vaguería de tuétano. No perezoso en el sentido de no trabajar duro. Esta industria trabaja extremadamente duro. Trabaja duro en el NAT a escala de operador, y en explicarle a un cliente por qué su CCTV ya no conecta desde fuera. Hará cualquier cantidad de trabajo, siempre que el trabajo sea del tipo que puedes comprar en vez del que tienes que entender.

Y eso está a punto de dejar de ser cuestión de gusto. El Cyber Security and Resilience Bill que ahora pasa por el Parlamento enmendaría las NIS Regulations para arrastrar dentro, entre otros, a los «managed service providers (organisations that provide third-party IT services to other businesses)» — proveedores de servicios gestionados (organizaciones que proveen servicios de TI de terceros a otras empresas). Todavía no es ley. Cuando lo sea, la detección, el registro y la denuncia de incidentes dejan de ser líneas de producto que esta capa vende y se vuelven deberes que tiene que cumplir.

Ponlo al lado de la cadena de más arriba. Resolver cualquier denuncia de abuso empieza con un servidor del otro extremo que haya registrado un puerto de origen, y el servidor del otro extremo es muy a menudo una de las cajas de estas empresas. La gente que pronto tendrá que probar que puede detectar y denunciar un incidente es la misma gente a la que actualmente no se la puede convencer de habilitar una familia de direcciones, o de leer una captura de paquetes cuando un túnel no quiere levantarse.

Las tres excusas

Oirás las mismas tres cada vez, y ninguna dura un minuto.

«La doble pila es dos de todo.» La corrí en producción en Nominet, en balanceadores de carga F5 delante del registro .uk, así que sé lo que vale la objeción. También lo es la capa de NAT que compraste en su lugar, y esa se sienta en el camino del tráfico con una tabla de sesión, un modelo de capacidad, una historia de conmutación por error y una obligación de logs atada. Nunca estuviste eligiendo entre complejidad y simplicidad. Elegiste la complejidad que venía con una factura.

«El equipo no lo soporta.» En 2006, justo. En 2026 significa que tu equipo está fuera de soporte, que es una cosa peor de admitir que la que intentabas no decir.

«No hay ingresos en ello.» No hay ingresos en las copias de seguridad tampoco.

Las cosas que la gente publica

Las excusas de arriba son lo que oyes en una reunión. Debajo de ellas hay una capa de afirmaciones técnicas que se repiten en hilos de foro, secciones de comentarios y respuestas de LinkedIn cada vez que sale IPv6, y la mayoría llevan equivocadas más de una década.

Parte de esto es confusión honesta y parte es una persona que ha decidido no aprender algo echando mano de una razón. De cualquier modo vale la pena repasarlo, porque estas afirmaciones hacen trabajo real. Son lo que un ingeniero le repite a un jefe que no puede comprobarlas.

«El NAT es mi cortafuegos. IPv6 pone cada dispositivo directo en internet.»

Esta es la grande y está al revés. La protección que la gente atribuye al NAT viene de que no hay ninguna correspondencia hasta que algo de dentro pide una — que es un cortafuegos con estado, y es el cortafuegos el que hace el trabajo, no la traducción. El IETF lo dijo en RFC 4864 en 2007: ese papel, «often marketed as a firewall, is really an arbitrary artifact» — a menudo comercializado como un cortafuegos, es en realidad un artefacto arbitrario —, donde un cortafuegos de verdad te da «explicit and more comprehensive management controls» — controles de gestión explícitos y más completos.

Cada router IPv6 de consumo viene con denegación por defecto en la entrada. Obtienes la misma postura, de una política que alguien escribió, en vez de de un efecto secundario de quedarse sin direcciones. Y entonces puedes permitir exactamente la única cosa que querías permitir, en vez de la sesión de espiritismo del reenvío de puertos.

Si tu modelo de seguridad entero es «los atacantes no pueden encontrar mis dispositivos», no tenías un modelo de seguridad. Tenías NAT.

«IPv6 es más lento.»

Este merece una respuesta honesta en vez de un descarte, porque la verdad es mixta y la gente que lo dice no está simplemente equivocada.

Los proveedores de contenido que han optimizado para él miden ganancias: Facebook reportó cargas de página alrededor de un 15 % más rápidas sobre IPv6, Akamai alrededor de un 5 % en móvil. La medición más amplia de toda la internet de APNIC es menos halagadora y tiene los tiempos de ida y vuelta de IPv6 corriendo marginalmente más altos de media — del orden de un milisegundo más o menos, y mejorando con el tiempo.

Así que: a grandes rasgos empate, mejor donde alguien ha hecho el trabajo, ocasionalmente un pelo peor donde nadie lo ha hecho.

Vale la pena saber dónde se sienta de verdad el coste, porque la cabecera es lo que la gente imagina y la cabecera no es el problema.

Empieza con lo que IPv6 le quitó al router. IPv4 lleva una suma de comprobación de cabecera. El Time to Live cambia en cada salto, así que la suma de comprobación tiene que cambiar con él, y RFC 6583 lista «verifying and updating the checksum» — verificar y actualizar la suma de comprobación — como un paso en el propio proceso de reenvío. IPv6 no tiene ninguna. Ese paso simplemente se va.

Luego la longitud. Una cabecera IPv4 es variable, que es para lo que sirve IHL: un router lee una longitud antes de saber dónde empieza la carga útil. Una cabecera IPv6 son 40 bytes. Siempre. Cada campo se sienta en un desplazamiento fijo y nada hay que averiguarlo primero.

Luego la fragmentación. Los routers IPv4 pueden fragmentar en vuelo, que es por lo que Identification, Flags y Fragment Offset están en la cabecera siquiera. RFC 8200 es rotundo al respecto: «fragmentation in IPv6 is performed only by source nodes, not by routers along a packet’s delivery path» — la fragmentación en IPv6 la realizan solo los nodos de origen, no los routers a lo largo del camino de entrega de un paquete. Así que ese camino se va también.

Solo en el manejo de cabeceras IPv6 es el protocolo más barato de reenviar. Se construyó para serlo.

El único sitio donde sí cuesta más es por ruta, y eso resulta no importar. La clave de búsqueda pasó de 32 bits a 128, así que una entrada de reenvío IPv6 es más ancha y en mucho equipo ocupa dos ranuras de hardware donde una ruta IPv4 ocupa una. Todos paran el argumento ahí. Vale la pena ir un paso más allá, porque la tabla completa es cuatro veces más pequeña.

En el volcado del RIS generado a las 02:03 UTC del 28 de agosto de 2026 había 1 229 166 prefijos IPv4 en la tabla de enrutamiento global y 300 470 de IPv6. Cuatro veces más rutas IPv4, cada una un cuarto del ancho. Así que el almacenamiento en bruto de la clave sale empate técnico: 4,92 MB contra 4,81 MB. Ahora aplica la regla de dos-ranuras-por-ruta-IPv6 que preocupa a la gente. Una tabla IPv6 completa aún necesita cerca de la mitad de las entradas de hardware de una IPv4 completa.

Y la razón de que la tabla IPv4 sea tan grande es la propia escasez. 767 543 de esas 1,2 millones de rutas son /24 — el 62 % de toda la internet IPv4 sentada en el prefijo más largo que alguien aceptará, porque los bloques se trocearon, se vendieron y se anunciaron en pedazos por quien los compró. Cada uno de esos es un router en algún sitio que tiene una entrada que no necesitaría si el espacio no se hubiera agotado.

Así que el argumento de la memoria va al revés de como se cuenta en las reuniones. Llevar IPv6 es más barato en tu FIB que llevar IPv4, y se vuelve más barato cada año que el mercado de transferencia trocea otro /16 en dieciséis /24.

Y los picos de CPU que la gente de verdad sufre no son ninguno de esos. Un router moderno reenvía ambas familias en silicio a velocidad de línea. Lo que duele es cualquier cosa que empuja un paquete fuera de ese camino hacia el plano de control, que el RFC 6583 llama «a ‘slower’ software process running on a general purpose processor» — un proceso de software «más lento» corriendo en un procesador de propósito general. Ese procesador se dimensionó para protocolos de enrutamiento. Nunca para el tráfico.

Dos cosas le empujan paquetes. La primera son las cabeceras de extensión. Son una cadena en vez de un bloque fijo, así que una caja que quiere los puertos de capa 4 para una ACL o un hash de ECMP tiene que recorrer una lista de longitud variable para encontrarlos, y una cabecera de Opciones Hop-by-Hop «may be examined or processed by any node along a packet’s delivery path» — puede ser examinada o procesada por cualquier nodo a lo largo del camino de entrega de un paquete. En mucho equipo eso significa desviado.

La segunda es el descubrimiento de vecinos. Un /64 cubre billones de direcciones que nunca se asignarán, así que escanear uno pone a un router a resolver direcciones que no existen. RFC 6583 existe por eso, y lo llama una denegación de servicio.

Ambos tienen respuestas conocidas. Filtra Hop-by-Hop en el borde, limita la tasa de ND, pon un tope a la caché de vecinos. Ninguno es una razón de que el protocolo sea lento. Son razones de que un router sin configurar sea lento, y eso apunta a donde apunta el resto de este artículo.

Ahora pesa un milisegundo contra la alternativa que de verdad desplegaste — una caja de traducción con estado en el camino de cada conexión, sosteniendo una tabla de sesión, que rompe algunas de ellas directamente. Nadie se quedó parado veinte años por un milisegundo.

«Hay de sobra IPv4 por ahí, puedes simplemente comprarla.»

Puedes. Así es como se ve una escasez. Bloques repartidos por nada en 1990 ahora cambian de manos a unos $20 por dirección, y AWS factura $43,80 al año por cada una que uses.

Un mercado en una cosa no prueba que haya de sobra de ella. Prueba que alguien averiguó cómo cobrarte por la escasez.

Nadie iba a obligarlos nunca

El Reino Unido no tiene política sobre esto en absoluto, y nunca la ha tenido.

Hubo un intento. 6UK se montó en 2010 con £20 000 de dinero semilla del Department for Business, Innovation and Skills, respaldado por Vint Cerf, con LINX, AAISP, Timico y Easynet detrás. En diciembre de 2012 sus directores voluntarios dimitieron en la asamblea general, nadie se presentó a la junta, y se disolvió. Su veredicto de despedida: los incentivos de libre mercado son insuficientes, «one factor appears to dominate IPv6 adoption rates, namely government support» — un factor parece dominar las tasas de adopción de IPv6, a saber, el apoyo del gobierno —, y «countries with hands-off governments fall behind» — los países con gobiernos que no se meten se quedan atrás.

Catorce años después, eso es exactamente lo que pasó. El UK IPv6 Council sigue en marcha, pero un foro no es una palanca.

Compara los Estados Unidos, donde el memorándum M-21-07 de la OMB exigía que el 80 % de los activos federales habilitados para IP fueran solo-IPv6 para el final del año fiscal 2025. Las agencias lo incumplieron. Aun así tenían un número que incumplir, una fecha para incumplirlo, y alguien que tiene que levantarse y explicar el incumplimiento. Aquí no hay nada que incumplir, así que nadie ha tenido nunca que explicar nada.

El gobierno británico no exige IPv6 en sus propias compras de ninguna manera con sentido. Ofcom no lo mide. Ningún regulador pregunta por ello. Y así, predeciblemente, www.nhs.uk y www.hmrc.gov.uk no lo tienen, mientras que www.gov.uk sí. Y www.gov.uk solo lo tiene porque se sirve a través de Fastly, que encendió IPv6 hace años en nombre de otro.

He escrito antes sobre lo que pasa cuando nadie tiene un contrato sobre una industria — los mecanismos que funcionan resultan ser los que alguien con recursos elige operar, y si nadie lo hace, no pasa nada durante una década. IPv6 en el Reino Unido es ese patrón otra vez, sin siquiera un voto de los miembros al final.

Y no es que nadie se diera cuenta

La ausencia de un requisito sería decepcionante si esto hubiera pasado sin notarse. No pasó.

El Estado averiguó lo que hace el NAT a escala de operador y legisló sobre ello. El Parlamento miró el problema directo a los ojos, lo entendió lo bastante bien como para escribir ley sobre él, y escribió la ley que acomoda la rotura. «Exígeles que desplieguen el protocolo que lo elimina» o nunca se planteó o se planteó y se descartó.

Así que somos un país cuya posición declarada es que la atribución de IP importa lo bastante para legislación antiterrorista, y que no le pide a un solo proveedor que haga la cosa gratis que la restaura. Fraude, secuestro de cuentas, acoso, amenazas de muerte, denuncias de abuso infantil y terrorismo llegan todos a la red de acceso haciendo la misma pregunta, y para muchas conexiones británicas la respuesta honesta es «uno de estos varios cientos de hogares».

El National Cyber Security Centre es parte del GCHQ y publica guías sobre muchísimas cosas. No le exige IPv6 a nadie. Nadie en Gran Bretaña lo hace.

www.ncsc.gov.uk y www.gchq.gov.uk sí responden ambos en IPv6, eso sí. También la Internet Watch Foundation. Los tres porque están detrás de Cloudflare, que lo encendió para todos por defecto. www.police.uk no tiene ninguno.

Y lo que eso significa para los diecisiete

Diecisiete de los cuarenta proveedores de este artículo venden conexiones sin IPv6, y cerca de la mitad de los constructores de fibra completa ponen a los clientes detrás de un NAT a escala de operador.

No acuso a ninguno de ellos de un delito, y nadie en esos edificios está esperando uno.

Pero una conexión detrás de un NAT a escala de operador sin IPv6 no puede resolverse a un abonado. Eso no se discute. El IETF lo escribió en 2011, Europol en 2016 y 2017, el Parlamento en 2015 — todo publicado antes de que se comprara la mayor parte de este equipo. La alternativa era gratis, y estaba disponible todo el tiempo.

Eso es lo que «ya nos ocuparemos de IPv6 algún día» significa, una vez que lo sigues hasta el final.

Qué hacer al respecto, en concreto

Corto, porque nada de ello es difícil. Ese es el sentido de todo el artículo.

Si compras conectividad: pon IPv6 en el pliego como un requisito de aprobado/suspenso, no un si-acaso. Pide doble pila nativa y un prefijo delegado, por escrito, y pregunta de qué tamaño.

Si la respuesta es un solo /64, sigue preguntando. RFC 6177 mató eso en 2011: dar a un sitio doméstico un solo /64 «precludes the expectation that even home sites will grow to support multiple subnets» — excluye la expectativa de que incluso los sitios domésticos crezcan para soportar varias subredes —, y está «strongly intended that even home sites be given multiple subnets worth of space, by default» — fuertemente pretendido que incluso a los sitios domésticos se les dé espacio para varias subredes, por defecto.

Lo que no hizo fue nombrar un tamaño. Retiró el viejo /48 general, dijo que la elección «is an issue for the operational community» — es un asunto de la comunidad operativa —, y dejó un ejemplo trabajado al pasar: un valor por defecto doméstico «of less than /48, such as a /56» — de menos de un /48, como un /56.

Los operadores lo respondieron ellos mismos. RIPE-690 es su propio documento de prácticas y es tajante. Un /48 cada uno si quieres un plan simple. Un /48 para negocio y un /56 para residencial si quieres uno pragmático. Cualquier cosa más larga que un /56 está «strongly discouraged» — fuertemente desaconsejada —, y un /64 no cumple los estándares de IPv6 y romperá las LAN de los clientes.

Así que el suelo es un /56, y es el propio número del IETF en vez de la preferencia de nadie. Sky ha dado uno a cada abonado desde 2016. Zen reparte un /48, que son 65 536. Un negocio no debería aceptar menos de un /48.

Si un proveedor te dice que un /48 a una casa es extravagante, un ISP británico lleva años haciéndolo mientras ellos aún estaban averiguando su postura.

Si corres un número de AS: probablemente ya tengas un /29 que nunca has anunciado. Comprueba.

AS=AS20712                                    # your AS number
ORG=$(whois -h whois.ripe.net "$AS" | awk '/^org:/{print $2; exit}')

# what IPv6 the registry has already given you
whois -h whois.ripe.net -- "-i org $ORG" | grep -i '^inet6num'

# what you are actually announcing of it
whois -h whois.ripe.net -- "-i origin $AS" | grep -i '^route6'

Si el primer comando imprime un prefijo y el segundo no imprime nada, eres uno de los 463.

Anúncialo, pon doble pila en tu borde y una VLAN interna, y pon un AAAA en un servicio público. Eso es una quincena de trabajo para un ingeniero y convierte tu organización de una estadística en la tabla de arriba en una que ha empezado.

Si corres un sitio web: comprueba si hay un registro AAAA. Si estás detrás de un CDN, probablemente sea un interruptor que puedes encender esta tarde sin coste. Si está apagado, alguien lo apagó.

Si vendes servicios gestionados: escribe IPv6 en el estándar de construcción y la plantilla de diseño de bajo nivel, una vez, y cada cliente después de eso lo obtiene por defecto. Nadie tiene que pedirlo, porque nadie pide TLS tampoco.

Si eres un ingeniero que nunca lo ha hecho: monta un laboratorio esta noche. Cerca del 90 % de mi propio tráfico corre sobre IPv6 nativo y es la cosa menos accidentada de mi red. Consigue un túnel o un VPS con un /64, pon direcciones en cosas, rómpelo, arréglalo. Lleva una tarde dejar de dar miedo y es la cosa más barata que puedes hacerle a tu carrera este año.

Las preguntas que no puedo zanjar

Todo lo de arriba te lo puedo mostrar. Esta parte es el trozo que sigo dándole vueltas, y no tengo una respuesta limpia a nada de ello.

¿Por qué unos sí y otros no?

Esta es la que importa, y los datos la hacen más extraña en vez de más clara.

Sky y Virgin Media vendieron banda ancha al mismo país, bajo el mismo regulador, al mismo tiempo. Uno terminó en 2016. El otro lleva diciendo «cuando estemos listos» desde 2010. Sainsbury’s y Tesco están en el mismo CDN, en un producto donde la doble pila es el valor por defecto, y uno tiene IPv6 y otro no. Noruega y Gran Bretaña compran a los mismos proveedores y el 66,9 % de las redes noruegas llevan IPv6 contra el 42,3 % de las nuestras.

Cada factor externo que podrías culpar se mantiene constante en esos pares. Mismo país, mismos proveedores, mismo equipo, mismos clientes, misma década, mismo regulador, mismo dinero. Y los resultados son opuestos.

Así que la causa no está en las circunstancias. Está dentro del edificio. En algún sitio de Sky había una persona que hizo de esto su asunto y siguió haciéndolo su asunto durante tres años. En los otros sitios no la había, o la había y a nadie por encima le importó. Esa es toda la variable, y no es una técnica.

Lo cual es una respuesta incómoda, porque no puedes comprarla, y no puedes ponerla en un documento de estrategia.

¿Es la formación?

En parte, y menos de lo que pensarías.

Mira otra vez las 463 empresas que tienen IPv6 que nunca han anunciado. Alguien en cada uno de esos edificios sabía lo bastante como para saber que lo necesitaba, sabía a quién preguntar, rellenó el formulario, y se lo emitieron. El conocimiento estaba ahí y la continuidad no.

La formación lleva a un ingeniero al punto de ser capaz. No lo lleva al punto de estar obligado a. Nadie ha tenido nunca una mala evaluación por no desplegar IPv6. Nadie ha perdido nunca un contrato por ello. Hasta que una de esas sea cierta, la formación va a la pila con todo lo demás que alguien aprendió en un curso y nunca usó.

¿Cuánto hasta que estemos todos en él?

Puedo poner un número a esta, y es peor de lo que esperaba.

Google ha medido la proporción de sus propios visitantes que llegan por IPv6 desde 2008. Tomando mediados de agosto cada año, para que sea comparable:

No estamos acelerando hacia el final. Estamos desacelerando por debajo de la mitad. Este año añadió 1,1 puntos, la menor ganancia en una década, contra 6,6 puntos en el año hasta agosto de 2017.

Traza una línea recta desde los últimos tres años y el mundo llega al 100 % en 2049. Trázala solo desde este año y es 2073. Ninguna es un pronóstico. Una curva que se aplana no llega a la cima por deriva en absoluto. Se estanca en algún sitio de los sesenta y el resto nunca se mueve, porque las redes que no lo han hecho para entonces son las que nada iba a mover nunca.

Me encantaría estar equivocado sobre eso. El número se ha hecho más pequeño cada año que lo he mirado.

¿Necesitamos una ley?

Esta es sobre la que más he ido y venido, y he aterrizado en «no la ley que la gente busca».

Contra un mandato: los americanos aprobaron el más fuerte que nadie tiene, y lo incumplieron. Un plazo no es un despliegue.

A favor de uno: el veredicto de despedida de 6UK en 2012 fue que los incentivos de libre mercado son insuficientes y que los países que se quedan atrás son los de gobiernos que no se meten. Catorce años de datos británicos están de acuerdo con ellos.

Y aquí está la parte que lo zanja. Este país ya ha legislado sobre este problema — solo que legisló en la dirección equivocada. Estuvimos dispuestos a legislar para acomodar el uso compartido de direcciones. Nunca hemos estado dispuestos a legislar para eliminarlo.

Lo que yo pediría no es una prohibición ni un objetivo, sino el instrumento belga descrito antes: un límite duro a cuántos abonados pueden compartir una dirección. No necesita direcciones nuevas, no deja a nadie fuera del mercado, y funciona sobre la economía en vez de sobre las buenas intenciones de nadie.

Un mandato por sí solo produce una cosa útil, y no es el despliegue. Es una persona con nombre que tiene que explicar el incumplimiento. Nunca hemos tenido una de esas.

¿Cómo nos pasamos a IPv4 tan rápido, entonces?

Porque alguien podía apagar el viejo.

La comparación es exacta, y casi nadie la hace. ARPANET corría el Network Control Program, que direccionaba hosts en 8 bits — 6 para el nodo y 2 para el host, así que 64 nodos de 4 máquinas, 256 hosts en total. A finales de los años setenta eso obviamente no era suficiente, y la respuesta fue un protocolo nuevo con una dirección más grande. El mismo problema que tenemos ahora, cuarenta y pico años antes.

Jon Postel publicó el plan de transición en noviembre de 1981. En marzo de 1982 el Departamento de Defensa de EE. UU. declaró TCP/IP su estándar oficial. Ambos protocolos corrieron uno al lado del otro, y el 1 de enero de 1983 se apagó NCP. Los hosts que no se habían convertido perdieron el acceso a la red. Vint Cerf recuerda las chapas de «I survived the TCP/IP switchover» que después llevaba la gente que lo superó.

Catorce meses del plan al día de la bandera.

Ahora cuenta lo que lo hizo posible. Unos pocos cientos de hosts, no cuatro mil millones. Una red, no cada red. Un financiador que poseía cada máquina en ella y pagaba los sueldos de todos los que las tocaban. Una sola organización capaz de fijar una fecha, y — esta es la parte que importa — capaz de hacer que el viejo protocolo dejara de funcionar en esa fecha.

Nada de esas cosas existe ahora, y esa es toda la respuesta. IPv4 no ganó porque la migración fuera fácil. Ganó porque había alguien en posición de acabar la discusión.

Nadie está en esa posición hoy. No hay autoridad que pueda apagar IPv4, y nunca la habrá. Lo que significa que esta transición no puede terminarse como se terminó la última — solo puede terminarse por varios miles de empresas cada una decidiendo, por su cuenta, molestarse.

Con los números de este año, eso aterriza en 2073. Noventa años después del día de la bandera.

Solíamos hacer las cosas como es debido

Un estándar es algo que mantienes cuando nadie está comprobando. Eso es todo. No hay inspector para esto, no hay certificado, no hay auditor que se presente y pida ver tu tabla de enrutamiento, y veinte años han mostrado ahora exactamente lo que este país hace con una obligación que nadie hace cumplir.

La dejamos caer, y luego compramos algo para tapar el hueco.

Nada de eso es un fallo técnico y no fingiré que lo es. Gran Bretaña puede hacer este trabajo. Las habilidades están aquí, el equipo está aquí, el espacio de direcciones está emitido y sentado esperando en cuentas que ya estamos pagando. Lo que se ha ido es el instinto de hacer un trabajo como es debido porque es el trabajo — sin que te paguen extra por ello, y sin que alguien esté de pie sobre ti obligándote.

Pregunta qué lo detiene de verdad y aterrizas en el dinero, pero no de la manera que la gente quiere decir.

Un NAT a escala de operador tiene una orden de compra. Tiene un proveedor, un presupuesto, un descuento, un contrato de soporte y una fecha de renovación. Va en el plan de capital, se amortiza a lo largo de cinco años, y el nombre de alguien está en el caso de negocio. Entregarlo es una cosa visible a la que un jefe puede señalar en una evaluación.

IPv6 no tiene nada de eso. Sin factura, sin proveedor, sin renovación, nada que poner en un presupuesto y nada que a alguien se le vea haber comprado. Es solo trabajo, hecho como es debido, por gente que sabe lo que hace, sin retorno este trimestre. A nadie en esta industria lo han ascendido nunca por una cosa que nunca apareció en un presupuesto.

Como tal la opción más barata pierde, cada año, durante veinte años. No porque alguien lo sopesara y eligiera mal, sino porque aquí ha crecido una cultura de gestión que solo puede ver las partes de la ingeniería que llegan con un precio encima. Barato nunca fue el obstáculo. Infacturable lo fue. Eso es lo que parece cuando un negocio deja de preocuparse por los estándares y empieza a preocuparse solo por lo que puede poner en una factura, y es una elección hecha por gente pagada lo bastante bien como para saber más.

Luego está lo que nos vendieron en vez de una dirección, que debería enfadar a la gente más de lo que lo hace.

Internet se construyó para que cualquier máquina pudiera llegar a cualquier otra máquina directamente. No un detalle del diseño. El diseño. Es por lo que cualquiera con una conexión y una idea podía poner algo en pie que el mundo entero pudiera alcanzar. Pon a un cliente detrás de una dirección compartida y eso se acabó. Puedes preguntar, pero nunca puedes responder. Eres un consumidor de los servicios de otros, permanentemente, y nunca un proveedor de los tuyos.

Eso no es un desafortunado efecto secundario de una escasez. Es una re-arquitectura, y le conviene a todos los que la venden. La cámara que ahora necesita la nube del fabricante. El acceso remoto que ahora necesita el relé de alguien. La cosa que la gente solía correr en casa que ahora es una suscripción mensual. Cada una de esas es alguien que poseía una cosa siendo convertido en alguien que la alquila, y una conexión degradada en silencio de un sitio en internet a una ventana a la de otro.

Regalamos el medio de internet a un puñado de empresas en otro continente, y luego nos quedamos parados con cara de sorpresa de que acabara centralizado. No puedes ser autosuficiente en una conexión que no te deja alojar nada.

La autosuficiencia es la parte a la que sigo volviendo, porque este país ha dejado de esperarla de sí mismo. El instinto ahora es esperar. A un proveedor, un regulador, una subvención, un mandato, un cliente que llama y pregunta. Ninguno de esos viene. No hay señal de mercado en camino, ni política en redacción, ni plazo que alguien tenga que explicar por incumplir.

Lo que lo deja donde ha estado todo el tiempo. Una asignación gratis, sentada en una cuenta de registro con el nombre de tu empresa, y una quincena entre tú y haber hecho el trabajo bien.

Nadie viene a obligarte. Eso es exactamente por lo que cuenta.

Puedes comprobar si es tu edificio. El script está en la descarga al principio del artículo.

Fuentes

Todo lo de abajo se recuperó el 27 de agosto de 2026.

Los datos de los que medí. Cada número mío viene de estos. Son gratis, son públicos, y puedes repetir todo el asunto en una tarde.

• Ficheros de delegación del registro, uno por registro regional: RIPE NCC, APNIC, ARIN, LACNIC, AFRINIC. El de RIPE se generó el 26 de agosto de 2026, el resto el 27 de agosto de 2026.
• Volcados de la tabla de enrutamiento RIS de RIPE, riswhoisdump.IPv4.gz y riswhoisdump.IPv6.gz, generados a las 18:06 UTC del 27 de agosto de 2026.
• Interfaz REST de la base de datos de RIPE, para la organización detrás de cada número de AS.
• El DNS público, para el barrido de AAAA, cotejado contra un segundo resolutor.

Mediciones de otros.

• Estadísticas de IPv6 de Google — IPv6 nativo por país entre los propios visitantes de Google, cifras a 25 de agosto de 2026.
• APNIC sobre el rendimiento de IPv6 y sobre los malentendidos de seguridad de IPv6 — el cuadro medido en vez del del foro.
• Precios del mercado de transferencia de IPv4, primera mitad de 2026, resumiendo el análisis de CircleID de transacciones con precio público.

Estándares. Los apaños, en el orden en que se publicaron.

• RFC 3056 — túnel automático 6to4, febrero de 2001.
• RFC 3701 — el plan de retirada de la 6bone, fijando su apagado para el 6 de junio de 2006.
• RFC 7526 — dejando obsoletos los relés anycast de 6to4 y moviéndolos a Histórico, mayo de 2015.
• RFC 4864 — lo que el NAT da y no da, y por qué el cortafuegos que la gente cree tener es «un artefacto arbitrario», 2007.
• RFC 4941, RFC 7217 y RFC 8981 — direcciones temporales y opacas, que es por lo que la dirección IPv6 de un dispositivo no es un identificador estable.
• RFC 801 — el plan de transición NCP/TCP de Jon Postel, noviembre de 1981, fijando el día de la bandera del 1 de enero de 1983.
• RFC 1883 — la especificación original de IPv6, diciembre de 1995.
• RFC 6333 — DS-Lite, 2011.
• RFC 6056 — aleatorización del puerto de origen, la defensa que el CGN debilita, 2011.
• RFC 6269 — Issues with IP Address Sharing, junio de 2011. El propio catálogo del IETF de lo que el CGN rompe, incluidos el registro de abusos, los rincones de penalización, las listas negras, la aleatorización de puertos y la trazabilidad.
• RFC 791 y RFC 8200 — los dos formatos de cabecera, y por qué IPv6 quitó la suma de comprobación, la longitud variable y la fragmentación en vuelo.
• RFC 6583 — el agotamiento de la caché de descubrimiento de vecinos en un /64, y la división plano-de-reenvío contra plano-de-control que decide qué le cuesta CPU a un router.
• RFC 6177 — cuánto espacio de direcciones debería obtener un sitio final, 2011. Deja obsoleto el /48 general del RFC 3177, descarta el /64 único, y entrega el número real a la comunidad operativa.
• RIPE-690 — la propia respuesta de los operadores europeos a esa pregunta, octubre de 2017: /48 o /56 a un usuario final, nunca un /64.
• RFC 6302 — registra el puerto de origen, la marca de tiempo y el protocolo, 2011.
• RFC 6598 — espacio de direcciones compartido, 2012.
• RFC 6877 — 464XLAT, 2013.
• RFC 6888 — requisitos del NAT a escala de operador, 2013.
• RFC 7021 — el impacto del NAT a escala de operador en las aplicaciones, 2013.
• RFC 7422 — mapeo determinista para recortar el registro del CGN, 2014.
• RFC 7597 y RFC 7599 — MAP-E y MAP-T, 2015.
• World IPv6 Launch, 6 de junio de 2012.
• El corredor de túneles gratis de Hurricane Electric — donde muchos de nosotros conseguimos IPv6 mientras nuestros propios ISP no tenían ninguno.

Ley y política.

• Cyber Security and Resilience (Network and Information Systems) Bill 2024-26 — informe de la House of Commons Library sobre el proyecto de ley que traería a los proveedores de servicios gestionados dentro de las NIS Regulations.
• Counter-Terrorism and Security Act 2015, sección 21 — retención de datos de internet relevantes, y sus notas explicativas.
• Europol, octubre de 2017 — las fuerzas del orden pidiendo el fin del NAT a escala de operador, con las cifras del 90 % móvil y el 50 % fijo.
• Memorándum M-21-07 de la OMB — el requisito federal estadounidense de solo-IPv6, noviembre de 2020.
• Online Safety Act 2023.
• Europol EC3, Carrier Grade NAT and crime attribution online — la presentación de Gregory Mounier ante RIPE 74, con la encuesta de agosto de 2016 a las fuerzas del orden de la UE, los ejemplos de casos, y el código de conducta belga y sus resultados.
• Datos de la CyberTipline de NCMEC — volúmenes y referencias del informe de 2025.
• A Multi-perspective Analysis of Carrier-Grade NAT Deployment, ACM IMC 2016 — la medición independiente del uso de CGN por proveedores móviles y fijos.
• Esquema de tarifas del RIPE NCC 2026 — 1 800 EUR por cuenta LIR, plano.

Proveedores, en sus propias palabras.

• Akamai, junio de 2022 — la doble pila es el valor por defecto y los clientes tienen que optar por salirse de ella.
• AWS, 2023 — el cargo por IPv4 pública, y por qué.

Reportajes y el registro.

• El propio artículo de Sky en RIPE Labs — cómo se movieron cinco millones de usuarios.
• ISPreview, septiembre de 2016 — Sky completando el despliegue.
• CircleID, septiembre de 2016 — el premio Jim Bound IPv6.
• ISPreview, diciembre de 2012 — 6UK disolviéndose.
• Encuesta de IPv6 y CGNAT de altnets de ISPreview — abril de 2024, actualizada a marzo de 2025.
• ISPreview sobre la prueba de IPv6 de Plusnet, noviembre de 2023 — la prueba de 2011, el lanzamiento de 2020 incumplido, y la nota de que BT y Plusnet entregan routers casi idénticos.
• Un rastreador mantenido por la comunidad de las redes móviles británicas e IPv6 — reportado por usuarios en vez de oficial, y la fuente de qué redes móviles reparten IPv6 hoy.
• havevirginmediaenabledipv6yet.co.uk — la cronología de Virgin Media, de 2010 a ahora.
• Internet Society, septiembre de 2016 — Sky al 90 % de su base, cada abonado recibiendo un /56.
• Internet Society, septiembre de 2016 — el relato de Ron Broersma de la migración de NCP a TCP/IP de 1983, incluido el límite de 256 hosts y qué le pasó a quien incumplió el plazo.
• The Register, enero de 2013 — treinta años después del día de la bandera, y las chapas que la gente llevaba después.
• UK IPv6 Council.