Resumen

  • En 6rd, parte de la dirección IPv4 del equipo del cliente se incorpora al prefijo IPv6 que este recibe. Cambiar aquella dirección puede cambiar el direccionamiento de su red interna.
  • El dominio del proveedor no es una estrella en la que todo pasa por el relé. Los equipos de clientes del mismo dominio pueden comunicarse mediante túneles directos.
  • El reenvío sin estado por flujo sigue necesitando parámetros comunes, límites verificables y una decisión de salida. Conservar los prefijos al pasar a IPv6 nativo evita renumeración, pero exige incorporarlos al enrutamiento nativo.

Lo que no aparece en la fecha de lanzamiento

La fecha en que un operador empieza a ofrecer IPv6 es fácil de registrar. Más difícil es anotar qué decisiones del antiguo servicio siguen condicionando al nuevo. En 6rd, una de ellas es la asignación de la dirección IPv4 al cliente. Aunque el tráfico que se quiere transportar sea IPv6, esa dirección participa en la construcción del prefijo del sitio.

El mecanismo de RFC 5969 reutiliza la infraestructura IPv4 como medio de transporte. Calcula la información necesaria a partir de las direcciones, sin exigir al relé fronterizo una tabla de correspondencias por cada flujo. Es una simplificación real: permite introducir el servicio antes de que toda la red de acceso admita IPv6 de forma nativa.

Sin embargo, la reutilización no es independencia. El plan IPv4 proporciona una parte de la identidad IPv6 del cliente y puede limitar su duración. Una reasignación que parece rutinaria desde el inventario IPv4 puede provocar un cambio de prefijo en otra capa. La especificación advierte de esa posibilidad; este artículo no afirma haber medido una interrupción concreta.

El interés de 6rd está precisamente en ese intercambio. La entrada resulta más sencilla porque se aprovecha una estructura ya existente. A cambio, la organización debe conservar una visión de las obligaciones que hereda. Si el lanzamiento se da por cerrado y esa visión desaparece, el riesgo no procede de que el algoritmo deje de funcionar, sino de que siga funcionando mientras sus entradas cambian.

Una fórmula que distribuye capacidad

El prefijo delegado al cliente combina el prefijo 6rd del operador con los bits pertinentes de la dirección IPv4 del router de borde del cliente, denominado CE. Los bits iniciales comunes del espacio IPv4 pueden omitirse. IPv4MaskLen indica cuántos.

La longitud resultante es 6rdPrefixLen más 32 menos IPv4MaskLen. El ejemplo del RFC utiliza direcciones de 10/8: los primeros ocho bits son comunes y quedan veinticuatro por incorporar. Un prefijo 6rd /32 produce así un prefijo delegado /56.

Detrás de la aritmética hay una decisión de producto. Los bits empleados en distinguir a los clientes no quedan disponibles para subdividir su espacio interno. El operador no puede diseñar el plan de acceso como si la cantidad de subredes ofrecida al cliente fuera un asunto completamente independiente.

Conviene separar la validez del formato de la utilidad de la asignación. La opción DHCP exige que las longitudes pertinentes no superen los 128 bits disponibles. La discusión del direccionamiento recomienda un prefijo delegado /64 o más corto para permitir la autoconfiguración sin estado. Cumplir el límite del campo no demuestra que el cliente disponga de un plan adecuado para su sitio.

Las direcciones privadas tampoco eliminan el contexto. Pueden existir espacios IPv4 superpuestos en distintos dominios 6rd, siempre que estos tengan prefijos 6rd diferentes. Una dirección con significado dentro de un dominio no identifica por sí sola a un extremo en otro. Y este procedimiento no debe confundirse con repartir una dirección IPv4 compartida entre usuarios mediante conjuntos de puertos.

Por eso, una reorganización posterior de IPv4 puede afectar tanto a la continuidad como a la oferta de IPv6. El cambio quizá no altere la marca comercial ni el equipo de acceso. Aun así, habrá modificado uno de los datos que determina qué recibe el cliente.

Cinco semanas no son una promesa universal

El antecedente de Free/Iliad recogido en RFC 5569 explica por qué el enfoque resultó atractivo. Ese documento informativo relata cinco semanas desde la decisión del 7 de noviembre de 2007 hasta el despliegue operativo del 11 de diciembre. Más de 1,5 millones de clientes podían activar el servicio.

La cifra describe clientes elegibles, no usuarios activos simultáneos, tráfico observado ni satisfacción. Tampoco permite deducir el uso actual de 6rd. Es el relato de una implantación específica, publicado en 2010, y su precisión depende de mantener esas fechas y categorías.

La rapidez estaba respaldada por el control del software de los equipos de cliente, los relés y la infraestructura existente. El documento también describe una evolución del direccionamiento: una asignación inicial /32 con prefijos de cliente /64, seguida de una asignación /26 y prefijos /60 que permitían dieciséis LAN por cliente. Es la configuración histórica relatada; no significa que sumar 32 bits a /26 dé como resultado /60.

La fe de erratas de RFC 5569 aclara un detalle relevante. La corrección editorial verificada 2023 pasa al pasado una referencia a la asignación posterior: ya había ocurrido, no era una expectativa. Las otras entradas verificadas también son editoriales. No aportan nuevas mediciones ni establecen derechos actuales de asignación de espacio.

La lección empresarial, por tanto, no consiste en repetir «cinco semanas». Consiste en identificar qué control permitió ese plazo. Adoptar la fórmula no equivale a poder actualizar todo un parque de equipos ni a disponer del mismo margen de direccionamiento. El protocolo facilita una operación; la autoridad y la capacidad de ejecutarla pertenecen a la organización.

La concesión de IPv4 marca un límite aguas abajo

RFC 5969 recomienda asignaciones IPv4 de larga duración porque cambiar la dirección del CE cambia el prefijo IPv6 derivado. Esa variación puede alcanzar a la red del cliente. No hay que añadir una avería del algoritmo para que exista el efecto: es consecuencia de la relación que el algoritmo establece.

Cuando se conoce la duración de la concesión IPv4, las duraciones anunciadas a los equipos de la LAN o asociadas a prefijos delegados mediante DHCPv6 no deben superarla. Si la duración de IPv4 es desconocida, el documento recomienda los valores predeterminados de RFC 4861. Desconocer el límite no convierte el prefijo en permanente.

Aquí «concesión» se refiere al mecanismo de asignación del protocolo. No es el arrendamiento comercial de un bloque IPv4. Un operador puede conservar un bloque en su inventario mientras cambia la dirección concreta asignada a un cliente. Es esta última relación la que alimenta la derivación 6rd.

Tampoco se deduce que todos los clientes necesiten una dirección fija para siempre. La norma no define un contrato comercial único. Lo que impide es evaluar una reducción de las duraciones IPv4 sin considerar el trabajo que introduce en IPv6.

El problema organizativo puede surgir entre equipos competentes. Quien administra el conjunto de direcciones busca flexibilidad; quien presta IPv6 busca estabilidad; quien atiende al cliente recibe las consecuencias. Si cada uno mide solo su parte, una optimización local puede trasladar costes sin que nadie haya aprobado el efecto conjunto.

Una frontera con más de una ruta

6rd utiliza el prefijo propio del proveedor y un dominio definido, a diferencia del prefijo global fijo de 6to4. Eso cambia la capacidad de control. No demuestra, sin embargo, que todo el tráfico del dominio pase por un único punto de inspección.

Los CE del mismo dominio pueden intercambiar tráfico encapsulado directamente a través de IPv4. El relé fronterizo, o BR, se utiliza cuando los paquetes cruzan entre el dominio 6rd y la red IPv6 exterior. La distinción determina qué caminos hay que admitir y observar.

La corrección técnica verificada 3049 de RFC 5969 lo hace explícito. Modifica la formulación de seguridad para incluir, además de los BR conocidos, a otros CE del mismo dominio entre los emisores de los que un CE debe recibir tráfico. Una política basada exclusivamente en relés puede descartar comunicaciones legítimas.

En esa misma página figura la corrección técnica propuesta 3869, que fue rechazada. No debe aplicarse como si fuera una enmienda válida. El control compara la dirección IPv4 incorporada en la dirección IPv6 de origen interna con la dirección IPv4 de origen externa. No compara una dirección IPv6 completa como si perteneciera a la otra familia. La discrepancia se descarta y contabiliza como posible suplantación, pero el contador no identifica por sí solo una agresión ni a su responsable.

Además, el dominio depende de una configuración común coherente: máscara IPv4, prefijo 6rd, longitud del prefijo y direcciones de los BR. La opción DHCP 212 transmite parámetros para un dominio. Una opción válida activa normalmente la configuración automática, aunque el CE debe permitir deshabilitarla e ignorar la opción.

Por tanto, «sin estado» no significa «sin autoridad de configuración». La decisión sobre unos pocos parámetros puede tener un alcance amplio. Cuanto más depende el reenvío de una interpretación compartida, más importante resulta comprobar que esa interpretación realmente coincide en los equipos involucrados.

El relé contesta; ¿qué se ha demostrado?

La ausencia de estado por flujo permite compartir una dirección IPv4 anycast entre BR. El resultado facilita ciertas decisiones de despliegue, pero exige prudencia al interpretar las pruebas. La respuesta de esa dirección no certifica que cada instancia ni cada destino exterior funcione igual.

RFC 5969 señala el riesgo de que numerosas comprobaciones periódicas de CE sobrecarguen el plano de control del BR. Si hace falta detectar la conectividad CE–BR, debe usarse un método del plano de datos que no requiera procesamiento especial en el plano de control del relé. El recorrido de retorno descrito demuestra ese trayecto de reenvío; no todos los caminos hacia Internet IPv6.

El tamaño de los paquetes añade otra condición. Un error ICMP dirigido a la dirección IPv4 anycast puede llegar a un BR distinto del que emitió el paquete original. El aprendizaje dinámico de la MTU del camino puede fallar y generar agujeros negros. Los BR anycast deben marcar la encapsulación para impedir fragmentación, evitando también que se mezclen fragmentos procedentes de relés con una misma dirección de origen durante el reensamblado.

La especificación ofrece el ejemplo de una MTU de túnel de 1480 bytes sobre un camino IPv4 bien gestionado de 1500 bytes. Cuando se desconoce la MTU pertinente, recomienda 1280. Son supuestos y orientaciones de diseño, no un resultado experimental de este artículo. Que pase una sonda pequeña no basta para dar por resuelto el comportamiento de paquetes mayores.

El cálculo no acredita al extremo

El análisis informativo RFC 6324, de 2011, estudia bucles en túneles automáticos IPv6 sobre IPv4 cuando divergen las hipótesis de enrutamiento y de interpretación de las direcciones. Su distinción más útil es sencilla: una dirección calculable no demuestra la existencia de un extremo autorizado del túnel.

En 6rd, los controles necesitan conocer los prefijos específicos del proveedor. No hay un único prefijo global que identifique todos los dominios. Las direcciones IPv4 privadas añaden dudas de ámbito que no se resuelven ignorando la configuración local.

El informe trata medidas de evitación operativa y, cuando corresponden, información coherente de vecinos o conjuntos limitados de extremos. No todas sus recomendaciones se aplican a todos los mecanismos. Una regla específica de ISATAP no puede presentarse como remedio general para 6rd.

Son condiciones de fallo posibles, no un censo de redes atacadas. El límite de saltos de IPv6 sigue siendo finito. No se han inyectado paquetes, ejecutado ataques ni probado despliegues para este artículo. La consulta de erratas de RFC 6324 no devolvió coincidencias al revisarla; ese dato no equivale a una evaluación de seguridad actual.

RFC 5969 también aborda la restricción de accesos no deseados a los relés y la consideración de otros relés conocidos en el dominio IPv4. Llamar «controlado por el proveedor» a un espacio no demuestra que sus límites estén bien aplicados. Del mismo modo, la existencia de una recomendación no permite acusar a un operador de incumplirla sin evidencia de su red.

Salir sin cambiar números también tiene trabajo

La transición posterior a IPv6 nativo no obliga siempre a renumerar a todos los clientes. RFC 5969 contempla tanto usar un bloque nuevo como conservar los prefijos delegados e introducirlos en el enrutamiento nativo. El cliente puede mantener su numeración mientras cambia el modo en que el operador le entrega tráfico.

La segunda opción preserva continuidad, pero no elimina la obligación. Lo que antes se obtenía mediante derivación debe quedar representado en el sistema de rutas. Y recuperar el bloque 6rd exige resolver la situación de los usuarios restantes, no solo retirar un equipo importante o cerrar el proyecto de acceso.

La Nota 32 de Lu Heng sobre el problema de agencia ofrece una forma de leer esta estructura: comparar quién decide con quién soporta las consecuencias. Aplicada aquí, pregunta si la autoridad sobre las asignaciones IPv4 incluye responsabilidad por los cambios en IPv6. No es prueba de que Lu Heng analizara 6rd ni una atribución de malas intenciones a un proveedor.

La Nota 36 sobre el propósito de BTW respalda una descripción estructural, sin convertir el análisis en campaña. No hace falta rechazar el atajo para exigir que se contabilicen sus condiciones.

El plan antiguo siguió mandando porque continuaba prestando un servicio. La medida de una transición bien gobernada no es que ese hecho desaparezca del relato, sino que siga siendo visible para quienes pueden cambiarlo.