Despliegue residual de IPv4

El despliegue residual de IPv4 ( 4rd ) es un mecanismo de transición a IPv6 para proveedores de servicios de Internet que permite el despliegue del protocolo de Internet versión 6 (IPv6), manteniendo al mismo tiempo el servicio IPv4 para los clientes. El protocolo y ejemplos de aplicaciones se especifican en el RFC 7600.

El despliegue residual de IPv4 tiene tres características principales:

• Topología de malla: entre dos puntos finales, los paquetes IPv4 toman las mismas rutas directas que los paquetes IPv6. ^{[ 1 ]}
• Direcciones IPv4 compartidas: para hacer frente a la inevitable escasez de direcciones IPv4, se puede asignar una dirección IPv4 común a varios clientes, con conjuntos de puertos TCP/UDP distintos asignados a cada uno (una aplicación del modelo general A+P de la RFC 6346).
• Funcionamiento sin estado: las conversiones de paquetes IPv4 a paquetes IPv6 al entrar en el dominio, y viceversa al salir del dominio, no tienen estado (es decir, no se necesita ningún estado por cliente en los nodos de borde del dominio).

En comparación con otros mecanismos especificados por la IETF que tienen las mismas características principales, es decir, MAP-E (RFC 7597, RFC 7598, RFC 2473) y MAP-T (RFC 7599, RFC 7598, RFC 6145), su propiedad distintiva es que admite simultáneamente:

• Transparencia total de la fragmentación IPv4: con esta función, se conserva la compatibilidad con el descubrimiento de MTU de ruta de RFC 4821, recomendado en RFC 6349. Sin ella, dondequiera que los firewalls filtren los paquetes ICMP, los sistemas finales que admiten RFC 4821 ^{[ 2 ]} pierden su capacidad de aprovechar las rutas que admiten paquetes grandes .
• Aplicabilidad de las inspecciones de paquetes IPv6 a IPv4: al atravesar dominios exclusivos de IPv6, los paquetes IPv4 convertidos son paquetes IPv6 ordinarios, con su contenido sin cambios y válido en IPv6. ^{[ 3 ]} Por lo tanto, los filtros IPv6 que se realizan dentro del dominio exclusivo de IPv6, por ejemplo, para listas de control de acceso , cachés web , inspecciones profundas de paquetes , son, implícita y automáticamente, efectivos en paquetes IPv4 que atraviesan el dominio.

MAP-E solo admite lo primero, y MAP-T solo admite lo segundo.

Si un ISP quiere ofrecer servicio IPv4 residual en un dominio exclusivamente IPv6 y proporciona equipos en las instalaciones del cliente a todos sus clientes de este dominio, puede elegir entre MAP-E, MAP-T o 4rd, teniendo en cuenta que MAP-E y MAP-T están especificados en RFC estándar, mientras que 4rd está especificado, al menos hasta ahora, en un RFC experimental (véase la sección Historial más abajo): el mecanismo elegido sigue siendo puramente interno a cada dominio.

La clave que permite combinar la transparencia de fragmentación de IPv4 con la inspección profunda de paquetes IPv6 en un único diseño es el uso de una traducción de paquetes reversible en las entradas y salidas del dominio. ^{[ 3 ]} Esto es posible porque las cabeceras de los paquetes IPv6, debidamente complementadas con sus cabeceras de fragmento cuando sea necesario, son lo suficientemente grandes como para codificar en ellas, de forma ad hoc según se detalla en la RFC 7600, toda la información útil de la cabecera IPv4. (Esto no era posible en 6rd , el mecanismo de tunelización para IPv6 a través de dominios solo IPv4, porque las cabeceras IPv4 son demasiado pequeñas para contener toda la información de la cabecera IPv6).

Las opciones de capa IP de IPv4 no son compatibles en 4rd, pero sin consecuencias prácticas porque los sistemas finales ya están adaptados al hecho de que, por razones de seguridad, muchas rutas filtran las opciones de capa IP de IPv4. ^{[ 4 ]}

Otro aspecto en el que la cuarta especificación va más allá de las de MAP-E y MAP-T se refiere a los datagramas IPv4 fragmentados. En las especificaciones MAP-E y MAP-T, los únicos comportamientos completamente descritos implican el reensamblaje de datagramas en la entrada del dominio antes del reenvío. ^{[ 5 ] [ 6 ]} Para mejorar el rendimiento percibido por el usuario, reducir el procesamiento de entrada del dominio y disminuir las oportunidades de ataque, la cuarta especificación incluye un algoritmo mediante el cual los fragmentos recibidos de datagramas grandes se reenvían uno por uno sobre la marcha. ^{[ 7 ]}

La primera especificación "4rd", a diferencia de la actual RFC 7600, utilizaba encapsulación IPv4 en paquetes IPv6, el único método de tunelización conocido en ese momento para garantizar la preservación completa de IPv4 en dominios exclusivamente IPv6. Fue la primera propuesta que combinó el mapeo de direcciones sin estado, la topología de malla y A+P . ^{[ 8 ] [ 9 ]}

A continuación se propuso otro enfoque A+P de malla sin estado , llamado dIVI. ^{[ 10 ]} En lugar de encapsulación, utilizaba dos traducciones sucesivas (de IPv4 a IPv6 y viceversa), basadas en las traducciones unidireccionales SIIT existentes de RFC 2765. En comparación con la encapsulación, tenía la ventaja de hacer que las inspecciones de paquetes IPv6 fueran aplicables a los paquetes UDP y TCP IPv4 traducidos, pero, debido a las limitaciones de SIIT , carecía de compatibilidad total con la fragmentación de IPv4 (y, en consecuencia, como se mencionó anteriormente, compatibilidad con el descubrimiento de MTU de ruta recomendado en RFC 6349).

En este contexto, la aprobación de uno de los dos diseños como estándar único parecía inalcanzable, a pesar del deseo general de uniformidad en el estándar. Entonces se tomaron dos caminos diferentes.

• Se propuso renombrar la cuarta solución de encapsulación como MAP-E , renombrar la traducción doble SIIT como MAP-T y asociarlas en una especificación combinada llamada MAP . ^{[ 11 ]} La idea era que, para satisfacer el objetivo de unicidad del estándar, una especificación con dos variantes (entre las cuales aún se necesita elegir una para cada dominio solo IPv6) podría considerarse equivalente a un único estándar. Pero no se llegó a un consenso sobre esta interpretación. ^{[ 12 ]}
• La otra se basó en el descubrimiento de que, como se mencionó anteriormente, era posible un algoritmo de doble traducción IPv4-IPv6 mejorado que combinara la aplicabilidad de las inspecciones de paquetes IPv6 a IPv4, como MAP-T, y la compatibilidad total con la fragmentación IPv4 como MAP-E. Como el acrónimo "4rd" ya no se usaba para la solución de encapsulación, esta solución se denominó 4rd . Se propuso adoptar este enfoque para un estándar único. ^{[ 13 ]} Pero, a pesar de la validación de su principio en una implementación, ^{[ 14 ]} no despertó interés entre los partidarios de MAP-E ni de MAP-T. ^{[ 12 ]}

Después de un largo debate, el grupo de trabajo Softwire ^{[ 15 ]} decidió, en agosto de 2012, que solo se estandarizaría MAP-E y que se podría continuar trabajando en 4rd y MAP-T, pero solo como experimental. ^{[ 12 ]}

Finalmente, en diciembre de 2014, el grupo de trabajo Softwire ^{[ 15 ]} cambió su decisión anterior y decidió poner MAP-T en la vía de estándares en paralelo con MAP-E, siempre que una nota en el RFC de MAP-T señalara su incompatibilidad con la ruta de descubrimiento de MTU del RFC 4821. ^{[ 16 ]}

Esto dejó a 4rd solo en la categoría Experimental (aunque con la posibilidad de que los ISP lo implementen, por sus ventajas funcionales, en dominios donde proporcionan equipos en las instalaciones del cliente a todos sus clientes).

Se considera que el ISP francés Free implementó 4rd para su experimento de FTTH en "áreas menos densas", a partir de diciembre de 2015. La implementación del modelo A+P implica la asignación de cuatro rangos de puertos contiguos a diferentes clientes para cada dirección IPv4. Free también fue conocido por ser el primer implementador de 6rd . ^{[ 17 ]}