Resumen

  • En 2001, 6to4 permitía derivar un prefijo IPv6 de 2002::/16 a partir de una dirección IPv4 pública y atravesar IPv4 sin negociar cada túnel de antemano.
  • El anycast hizo después que el relé pareciera automático, pero ida y vuelta podían depender de operadores distintos, sin una responsabilidad común. Filtros, rutas deficientes y activación predeterminada convirtieron la comodidad en fallos repetidos.
  • La RFC 7526 dejó obsoleto en 2015 el mecanismo de relés anycast. No dejó obsoleto el 6to4 unicast básico ni eliminó 2002::/16, una frontera que aún importa al leer el registro.

Una dirección antes que un acuerdo

La parte más recordada de 6to4 es un cálculo. Se toman los 32 bits de una dirección IPv4 globalmente única, se colocan después del prefijo 2002 y el sitio obtiene un /48. La RFC 3056 expresaba el resultado como 2002:V4ADDR::/48. Una red sin servicio IPv6 nativo podía repartir internamente direcciones de ese prefijo. En el borde, un router 6to4 envolvía el paquete IPv6 directamente en IPv4 mediante el protocolo 41.

Publicada en febrero de 2001, la RFC 3056 describía el sistema como un mecanismo provisional y optativo, no como la arquitectura permanente de IPv6. Su promesa era más concreta: comunicar sitios a través de Internet IPv4 sin configurar un túnel para cada interlocutor y sin conseguir antes un prefijo IPv6 ordinario para ese fin. La dirección IPv4 era a la vez materia prima y localizador.

La facilidad tenía límites desde el inicio. Una dirección IPv4 privada no podía originar un prefijo 6to4 válido globalmente. Si la dirección IPv4 cambiaba, también lo hacía el prefijo IPv6 derivado. Y seguía haciendo falta alguien que transportara paquetes entre el mundo 6to4 y el IPv6 nativo. La construcción de la dirección se había automatizado; la conectividad universal, no.

El relé que desapareció de la vista

Entre dos sitios 6to4, la IPv4 incrustada en cada prefijo indicaba al otro extremo dónde enviar el túnel. Entre un sitio 6to4 y un destino IPv6 nativo, en cambio, se necesitaba un relé que entendiera ambos mundos.

La RFC 3068 dio una respuesta muy sencilla: compartir entre los routers relé una dirección IPv4 anycast, 192.88.99.1. El router 6to4 enviaba allí el tráfico y el enrutamiento IPv4 ordinario escogía un relé que anunciara la ruta. El usuario ya no tenía que descubrir ni configurar una pasarela concreta. Un mecanismo que antes requería cierto acuerdo operativo podía sentirse como un interruptor.

Ese interruptor ocultaba una asimetría. El relé elegido para la ida no tenía por qué ser el del retorno. Una red IPv6 nativa que enviara hacia 2002::/16 podía elegir otro relé, bajo otro operador y otra política de enrutamiento. Ninguno necesitaba saber que el otro existía. El éxito exigía servicios compatibles de varias organizaciones, pero el mecanismo no creaba entre ellas un contrato ni un dueño del viaje completo.

El problema no aparecía en el formato de la dirección. Una dirección 6to4 podía estar construida exactamente según la norma y, aun así, topar con un cortafuegos que descartara el protocolo 41, una ruta de relé ausente, un relé mal situado o un regreso a un agujero negro. El prefijo podía ser correcto y la experiencia fracasar.

Cuando la alternativa ocultaba el coste

La RFC 3964, publicada en 2004, se centró en la seguridad. Un relé debía considerar si el origen IPv4 del túnel coincidía con la dirección IPv4 incrustada en el origen 6to4. Sin filtros, el tráfico falsificado podía reflejarse, blanquearse a través del sistema de transición o resultar más difícil de atribuir. El documento no sostenía que todos los relés fueran hostiles; mostraba que la encapsulación automática cruzaba fronteras de confianza que una dirección no podía vigilar sola.

En 2011, la RFC 6343 ya describía un historial operativo más amplio: filtros contra el protocolo 41, relés inexistentes o inalcanzables y caminos que funcionaban en un sentido pero no en el otro. Citaba experimentos de la época con tasas de fallo de conexión 6to4 de aproximadamente entre el 9 y el 20 %. No era un censo mundial, pero bastaba para convertir una ayuda de transición en un problema visible de fiabilidad.

El coste se ocultaba a menudo en lugar de desaparecer. Una aplicación de doble pila podía probar IPv6, esperar a que fallara 6to4 y terminar usando IPv4. Para el usuario, la página solo parecía lenta. Los proveedores de software tenían motivos para preferir rutas nativas fiables y competir entre alternativas, como hicieron después estrategias del tipo Happy Eyeballs. Cada capa reducía su síntoma sin resolver la falta de un responsable del sistema de relés.

La activación predeterminada prolongó el patrón. Sin haber pedido 6to4, un usuario podía recibir del sistema operativo o del equipo de borde una dirección derivada y una aparente ruta IPv6. La RFC 6343 calificó esa práctica de mala y recomendó desactivar 6to4 de forma predeterminada. Era una inversión reveladora: la función atractiva por requerir poca coordinación pasaba a exigir una decisión informada para encenderse.

Retirar el atajo sin borrar la historia

La RFC 7526 formalizó la retirada en mayo de 2015. Dejó obsoleto el mecanismo anycast de 6to4, trasladó las RFC 3068 y 6732 al estado «Historic» y pidió cesar el anuncio de la ruta anycast y el servicio de 192.88.99.1. Las implementaciones debían desactivar 6to4 de forma predeterminada. El atajo público ya no era infraestructura de transición recomendada.

Es fácil confundir el alcance de la decisión. La RFC 7526 dijo expresamente que no dejaba obsoleto el mecanismo unicast básico de la RFC 3056 ni el prefijo 2002::/16. El registro actual de direcciones IPv6 de propósito especial de IANA sigue identificando ese bloque como 6to4. La presencia en el registro documenta una asignación arquitectónica; no promete que exista o se aconseje una ruta pública de relés.

Por eso la historia no termina con un borrado. El proceso de estándares podía retirar una recomendación operativa y conservar el vocabulario necesario para reconocer direcciones antiguas, arreglos administrados y sistemas residuales. Ver 2002::/16 hoy es evidencia del mecanismo, no de que su servicio anycast superara la revisión.