Hispanopedia Wiki
Articulo de referencia

Lista de mecanismos de transición a IPv6

Para aumentar la implementación de IPv6 en Internet , se han propuesto diversos mecanismos de transición para facilitar este proceso. Dado que IPv6 no es directamente interopera...

Hispanopedia WikiContenido en espanolLectura gratuita

Para aumentar la implementación de IPv6 en Internet , se han propuesto diversos mecanismos de transición para facilitar este proceso. Dado que IPv6 no es directamente interoperable con su protocolo predecesor, IPv4 , los mecanismos de transición están diseñados para permitir que los hosts de ambos tipos de red se comuniquen con cualquier otro host.

Para cumplir con sus criterios técnicos, IPv6 debe contar con un plan de transición sencillo desde el IPv4 actual. [ 1 ] El Grupo de Trabajo de Ingeniería de Internet (IETF) organiza grupos de trabajo y debates a través de los procesos de Borradores de Internet y Solicitud de Comentarios del IETF para desarrollar estas tecnologías de transición con ese fin. Algunos mecanismos básicos de transición a IPv6 se definen en el RFC 4213.

Traducción IP/ICMP sin estado

La traducción IP/ ICMP sin estado ( SIIT ) traduce entre los formatos de encabezado de paquete en IPv6 e IPv4 . [ 2 ] El método SIIT define una clase de direcciones IPv6 llamadas direcciones traducidas a IPv4 . [ 3 ] Tienen el prefijo ::ffff:0:0:0 / 96 y pueden escribirse como ::ffff:0:abcd , en el que la dirección con formato IPv4 abcd se refiere a un nodo habilitado para IPv6 . El prefijo se eligió para producir una suma de verificación de valor cero para evitar cambios en la suma de verificación del encabezado del protocolo de transporte. [ 4 ] El algoritmo puede usarse en una solución que permite que los hosts IPv6 que no tienen una dirección IPv4 asignada permanentemente se comuniquen con hosts solo IPv4. La especificación no aborda los detalles de asignación de direcciones y enrutamiento. SIIT puede verse como un caso especial de traducción de direcciones de red sin estado .

La especificación es un producto del grupo de trabajo NGTRANS IETF y fue redactada inicialmente en febrero de 2000 por E. Nordmark de Sun Microsystems . [ 5 ] Fue revisada en 2011, [ 6 ] y en 2016 se publicó su revisión actual. [ 4 ]

Agente de túneles

Un intermediario de túneles proporciona conectividad IPv6 encapsulando el tráfico IPv6 en enlaces de tránsito de Internet IPv4, generalmente mediante 6in4 . Esto establece túneles IPv6 dentro de la Internet IPv4. Los túneles pueden gestionarse con el Protocolo de Configuración de Túneles (TSP) [ 7 ] o AYIYA [ 8 ] .

6º

6rd fue desarrollado por Rémi Després . [ 9 ] [ 10 ] Es un mecanismo para facilitar el despliegue rápido del servicio IPv6 en infraestructuras IPv4 de proveedores de servicios de Internet ( ISP ). Utiliza asignaciones de direcciones sin estado entre direcciones IPv4 e IPv6 , y transmite paquetes IPv6 a través de túneles automáticos que siguen las mismas rutas optimizadas entre nodos de clientes que los paquetes IPv4 . [ 11 ]

Se utilizó para un despliegue inicial a gran escala de un servicio IPv6 con direcciones nativas durante 2007 (RFC 5569 [ 12 ] ). La especificación estándar del protocolo se encuentra en RFC 5969. [ 13 ]

Traducción de relevo de transporte

El método de traducción de retransmisión de transporte ( TRT ) actúa como un dispositivo intermedio entre dos hosts. La función del traductor es convertir direcciones IPv6 a IPv4 y viceversa. TRT realiza esta traducción mediante el mapeo de direcciones IP y una dirección IP personalizada. [ 14 ]

Por ejemplo, si se transmiten paquetes desde una dirección IPv6 ( fec0:0:0:1:: / 64 ) a una dirección IPv4 ( 10.1.1.1 ), la dirección sería fec0:0:0:1::10.1.1.1 . Los paquetes se enrutan primero hacia el traductor mediante un protocolo IPv6/TCP y luego desde el traductor al host IPv4 mediante un protocolo IPv4/TCP. [ 15 ]

TRT emplea una operación similar a la traducción DNS entre registros AAAA y A conocida como DNS ALG . [ 16 ]

NAT64

NAT64 y DNS64

NAT64 es un mecanismo que permite a los hosts IPv6 comunicarse con servidores IPv4. El servidor NAT64 es el punto final de al menos una dirección IPv4 y un segmento de red IPv6 de 32 bits, por ejemplo, 64:ff9b:: / 96. [ 3 ] El cliente IPv6 incorpora la dirección IPv4 con la que desea comunicarse utilizando estos bits y envía sus paquetes a la dirección resultante. El servidor NAT64 crea entonces una asignación NAT entre la dirección IPv6 y la dirección IPv4, permitiendo así la comunicación. [ 17 ] NAT64 se suele utilizar junto con DNS64.

DNS64

DNS64 describe un servidor DNS que, al solicitar los registros AAAA de un dominio pero encontrar únicamente registros A , sintetiza los registros AAAA a partir de los registros A. La primera parte de la dirección IPv6 sintetizada apunta a un traductor IPv6/IPv4 y la segunda parte incorpora la dirección IPv4 del registro A. El traductor en cuestión suele ser un servidor NAT64. La especificación estándar de DNS64 se encuentra en el RFC 6147. [ 18 ]

Este mecanismo de transición presenta dos problemas notables:

  • Solo funciona en los casos en que se utiliza DNS para encontrar la dirección del host remoto; si se utilizan literales IPv4, el servidor DNS64 nunca intervendrá.
  • Dado que el servidor DNS64 necesita devolver registros no especificados por el propietario del dominio, la validación DNSSEC contra la raíz fallará en los casos en que el servidor DNS que realiza la traducción no sea el servidor del propietario del dominio.
# El resolvedor DNS 2606:4700:4700:64 sintetiza registros AAAA para # ipv6test.google.com a una dirección NAT64: 64:ff9b::<original-ipv4> $ nslookup ipv6test.google.com 2606:4700:4700::64Respuesta no autorizada : ipv6test.google.com nombre canónico = ipv6test.l.google.com. Nombre : ipv6test.l.google.com Dirección : 64:ff9b::8efa:c3e4
Implementaciones

ISATAP

ISATAP (Protocolo de direccionamiento automático de túneles intra-sitio) es un mecanismo de transición a IPv6 diseñado para transmitir paquetes IPv6 entre nodos de doble pila sobre una red IPv4.

A diferencia de 6over4 (un protocolo similar más antiguo que utiliza multidifusión IPv4), ISATAP utiliza IPv4 como una capa de enlace de datos de red de acceso múltiple sin difusión virtual (NBMA), por lo que no requiere que la infraestructura de red IPv4 subyacente admita la multidifusión.

464XLAT

464XLAT [ 21 ] permite que los clientes en redes solo IPv6 accedan a servicios de Internet solo IPv4. [ 22 ] [ 23 ] Extiende NAT64 agregando otro paso de traducción inicial de IPv4 a IPv6, lo que permite que los clientes o aplicaciones solo IPv4 se comuniquen a través de conexiones solo IPv6.

El cliente utiliza un traductor SIIT para convertir paquetes de IPv4 a IPv6. Estos se envían a un traductor NAT64 , que los traduce de IPv6 a IPv4 y los envía a un servidor que solo admite IPv4.

El traductor del cliente puede implementarse en el propio cliente o en un dispositivo intermedio y se conoce como CLAT (Customer-side transLATor). El RFC 7335 especifica un prefijo IPv4 especial , 192.0.0.0/29, reservado por IANA para su uso en escenarios de transición a IPv4, conocido como Prefijo de Continuidad de Servicio IPv4 , que anteriormente estaba reservado específicamente para DS-Lite, pero que desde entonces se ha extendido para admitir cualquier mecanismo de transición de funcionamiento similar. La implementación de CLAT puede usar direcciones de este prefijo para la numeración interna, aunque los paquetes que contienen estas direcciones nunca se envían realmente a través de la red. 

El traductor NAT64, o PLAT (Provider-side transLATor), debe poder comunicarse tanto con el servidor como con el cliente (a través del CLAT). El PLAT es idéntico a un NAT64 independiente, y no es necesario realizar cambios por parte del proveedor para admitir 464XLAT. El uso de NAT64 limita las conexiones a un modelo cliente-servidor mediante UDP, TCP e ICMP.

Si se utiliza DNS64 en una red exclusivamente IPv6, la mayoría de las aplicaciones que necesitan conectarse a un servicio exclusivamente IPv4 ya iniciarán conexiones de forma nativa mediante IPv6 al prefijo NAT64. Esto significa que 464XLAT solo es necesario para las aplicaciones que no entienden IPv6, prefieren IPv4 o utilizan direcciones IPv4 codificadas.

Implementaciones
  • T-Mobile US pasó a usar solo IPv6 mediante 464XLAT. [ 24 ]
  • Orange Polska comenzó a ofrecer servicio solo IPv6 (CLAT/NAT64/DNS) en septiembre de 2013, migrando todas las pasarelas ADSL , VDSL y FTTH para enero de 2015. [ 25 ]
  • Telstra pasó a utilizar únicamente IPv6 para servicios móviles mediante 464XLAT en febrero de 2020. [ 26 ]
  • Android incluye una implementación nativa de CLAT desde Jelly Bean 4.3, lanzado en 2013. [ 27 ]
  • Windows 10 tiene una implementación nativa solo para WWAN de 464XLAT para escritorio y dispositivos móviles desde la actualización Creators Update de 2017. [ 28 ]
  • Windows 11 (26H1 y versiones anteriores) está limitado a la interfaz WWAN, al igual que Windows 10. Se agregó compatibilidad extendida con CLAT a otros dispositivos de red en las compilaciones de Windows Insider Canary (>=29599.1000). La implementación sigue el estándar RFC 7050 (consulta DNS ipv4only.arpa), RFC 8781 (PREF64) y RFC 8925 (opción DHCP 108). [ 29 ] .
  • macOS comienza a tener soporte nativo para CLAT en Ventura, lanzado en 2022. [ 30 ]
  • iOS cuenta con una implementación nativa de CLAT desde la versión 12.0, lanzada en 2018. [ 31 ] Además, Apple exige que todas las aplicaciones enviadas a la App Store funcionen en redes exclusivamente IPv6. [ 32 ]
  • clatd es una implementación de CLAT para Linux . [ 33 ]
  • NetworkManager a partir de la versión 1.58 (no publicada al 17-06-2026), NetworkManager incluye una implementación CLAT basada en BPF [ 34 ] [ 35 ]
  • OpenWRT tiene soporte opcional para clat a través del paquete 464xlat. [ 36 ]
  • FreeBSD ha implementado NAT64 CLAT desde la versión 12.1. [ 37 ]

Dual-Stack Lite (DS-Lite)

DS-Lite

La tecnología Dual-Stack Lite no implica la asignación de una dirección IPv4 al equipo del cliente (CPE) para proporcionar acceso a Internet. [ 38 ] El CPE distribuye direcciones IPv4 privadas para los clientes LAN, de acuerdo con los requisitos de red en la red de área local. El CPE encapsula paquetes IPv4 dentro de paquetes IPv6. El CPE utiliza su conexión IPv6 global para entregar el paquete al NAT de grado de operador (CGN) del ISP , que tiene una dirección IPv4 global. El paquete IPv4 original se recupera, se realiza la traducción de direcciones sobre el paquete IPv4 y se enruta a la Internet IPv4 pública. El enrutador NAT de grado de operador identifica de forma única los flujos de tráfico registrando el protocolo utilizado (por ejemplo, UDP, SCTP), la dirección IPv6 pública del cliente, la dirección IPv4 privada del nodo del cliente, el número de puerto del nodo del cliente si corresponde (por ejemplo, con UDP o TCP), y la dirección IPv4 y el número de puerto si corresponde, del nodo ascendente, como una sesión.

Lightweight 4over6 amplía DS-Lite al trasladar la funcionalidad NAT del lado del ISP al CPE, eliminando la necesidad de implementar NAT de nivel de operador. [ 39 ] Esto se logra asignando un rango de puertos para una dirección IPv4 compartida a cada CPE. Trasladar la funcionalidad NAT al CPE permite al ISP reducir la cantidad de estado que se rastrea para cada suscriptor, lo que mejora la escalabilidad de la infraestructura de traducción.

Enrutamiento V4-a-V6

El enrutamiento V4-via-v6 [ 40 ] es una técnica en la que las direcciones IPv4 se asignan únicamente a los hosts finales, mientras que a los enrutadores intermedios solo se les asignan direcciones IPv6. Las rutas IPv4 se propagan de forma habitual, sin emplear traducción ni encapsulación de paquetes, pero utilizando un siguiente salto IPv6. V4-via-v6 reduce la cantidad de gestión necesaria, ya que a la red central solo se le deben asignar direcciones IPv6, pero aún requiere que dicha red pueda reenviar paquetes IPv4.

V4-via-v6 está definido para el Protocolo de puerta de enlace de frontera (BGP) [ 41 ] y el protocolo de enrutamiento Babel . [ 42 ] Se ha implementado en el demonio de enrutamiento de Internet Bird [ 43 ] y en babeld . [ 44 ]

MAPA

El mapeo de direcciones y puertos (MAP) es una propuesta de transición de Cisco a IPv6 que combina la traducción de direcciones de puerto A+P con la tunelización de paquetes IPv4 sobre la red IPv6 interna de un proveedor de servicios de Internet . [ 45 ] MAP-T [ 46 ] y MAP-E [ 47 ] entraron en la vía de estandarización en julio de 2015, y Sky Italia ha implementado MAP-T en sus servicios de Internet ya en el año 2021. [ 48 ]

Proyectos de propuestas preliminares

Los siguientes mecanismos aún se están debatiendo o han sido descartados por la IETF:

4º

El despliegue residual de IPv4 (4rd) es un mecanismo experimental [ 49 ] para facilitar el despliegue residual del servicio IPv4 en redes IPv6 . Al igual que 6rd , utiliza asignaciones de direcciones sin estado entre IPv6 e IPv4 . Admite una extensión del direccionamiento IPv4 basada en puertos de la capa de transporte. Se trata de una variante sin estado del modelo A+P .

Mecanismos obsoletos

Estos mecanismos han sido desaconsejados por la IETF:

NAT-PT

La traducción de direcciones de red/traducción de protocolo ( NAT-PT ) se define en el RFC 2766, pero debido a numerosos problemas, ha quedado obsoleta con la introducción del RFC 4966 y se ha relegado a un estado histórico. Normalmente se utiliza junto con una implementación de puerta de enlace DNS a nivel de aplicación (DNS-ALG).

NAPT-PT

Si bien es casi idéntico a NAT-PT, la traducción de direcciones de red y de protocolos (NAT - PT), también descrita en la RFC 2766, añade la traducción de puertos además de la dirección. Esto se hace principalmente para evitar que dos hosts en un lado del mecanismo utilicen el mismo puerto expuesto en el otro lado, lo que podría causar inestabilidad en la aplicación y fallos de seguridad. Este mecanismo ha sido declarado obsoleto por la RFC 4966.

Implementaciones

  • CLATD , una implementación de CLAT/SIIT-DC Edge Relay para Linux
  • TAYGA , una implementación de NAT64 sin estado para Linux
  • Jool , una implementación SIIT y NAT64 con estado para Linux
  • naptd , NAT-PT a nivel de usuario
  • Enrutador de transición de familia de direcciones (AFTR) , una implementación de DS-Lite
  • Microsoft Forefront Unified Access Gateway , una solución de proxy inverso y VPN descontinuada que implementa DNS64 y NAT64.
  • BIND , el servidor DNS de dominio de nombres de Internet de Berkeley, implementa DNS64 desde la versión 9.8.
  • PF (cortafuegos) , el filtro de paquetes de OpenBSD admite la traducción de versiones IP desde la versión 5.1, incluye NAT64.

Véase también

Referencias

  1. ↑ Partridge, C.; Kastenholz, F. (diciembre de 1994). Criterios técnicos para elegir IP The Next Generation (IPng) . IETF . doi : 10.17487/RFC1726 . RFC 1726 .
  2. ↑ F. Baker ; X. Li; C. Bao; K. Yin (abril de 2011). Marco para la traducción IPv4/IPv6 . Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC6144 . ISSN 2070-1721 . RFC 6144 . Informativo.
  3. 1 2 C. Bao; C. Huitema ; M. Bagnulo; M. Boucadair; X. Li (octubre de 2010). Direccionamiento IPv6 de traductores IPv4/IPv6 . Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC6052 . ISSN 2070-1721 . RFC 6052 . Norma propuesta. Actualiza la RFC 4291 . 
  4. 1 2 C. Bao; X. Li; F. Baker ; T. Anderson; F. Gont (junio de 2016). Algoritmo de traducción IP/ICMP sin estado . IETF . doi : 10.17487/RFC7915 . RFC 7915 .
  5. ↑ E. Nordmark (febrero de 2000). Algoritmo de traducción IP/ICMP sin estado (SIIT) . Grupo de trabajo de redes. doi : 10.17487/RFC2765 . RFC 2765 .Obsoleto. Obsoleto según RFC 6145 . 
  6. ↑ X. Li; C. Bao; F. Baker (abril de 2011). Algoritmo de traducción IP/ICMP . Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC6145 . ISSN 2070-1721 . RFC 6145 . Obsoleto. Obsoleto según RFC 7915. Actualizado por RFC 6791 y 7757 .  
  7. ↑ M. Blanchet; F. Parent (febrero de 2010). IPv6 Tunnel Broker con el Protocolo de Configuración de Túnel (TSP) . IETF . doi : 10.17487/RFC5572 . ISSN 2070-1721 . RFC 5572 . Experimental. Presentación independiente.
  8. ↑ A. Durand; P. Fasano; I. Guardini; D. Lento (enero de 2001). IPv6 Tunnel Broker . Grupo de trabajo de redes. doi : 10.17487/RFC3053 . RFC 3053 .Informativo.
  9. ↑ RFC 5569 . IETF . doi : 10.17487/RFC5569 .
  10. ↑ "IETF RFC 5569 - Despliegue rápido de IPv6 en infraestructuras IPv4 (6.ª)" .
  11. ↑ "Despliegue rápido de IPv6" (PDF) .
  12. ↑ Despres, R. (enero de 2010). Despliegue rápido de IPv6 en infraestructuras IPv4 (6.ª) . IETF . doi : 10.17487/RFC5569 . RFC 5569 .
  13. ↑ Troan, O. (agosto de 2010). Despliegue rápido de IPv6 en infraestructuras IPv4 (6.ª) – Especificación del protocolo . IETF . doi : 10.17487/RFC5969 . RFC 5969 .
  14. ↑ J. Hagino; K. Yamamoto (junio de 2001). Un traductor de retransmisión de transporte de IPv6 a IPv4 . Grupo de trabajo de redes. doi : 10.17487/RFC3142 . RFC 3142 .Informativo.
  15. ↑ Shanmugaraja, P. "Diseño e implementación de un traductor de retransmisión de transporte y sus medidas de mitigación de seguridad" . researchgate.net . Research Gate . Consultado el 28 de junio de 2024 .
  16. ↑ P. Srisuresh; G. Tsirtsis; P. Akkiraju; A. Heffernan (septiembre de 1999). Extensiones DNS para traductores de direcciones de red (DNS_ALG) . Grupo de trabajo de redes. doi : 10.17487/RFC2694 . RFC 2694 .Informativo.
  17. ↑ M. Bagnulo; P. Matthews; I. van Beijnum (abril de 2011). NAT64 con estado: traducción de direcciones de red y protocolos de clientes IPv6 a servidores IPv4 . Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC6146 . ISSN 2070-1721 . RFC 6146 . Norma propuesta.
  18. ↑ Bagnulo, M.; Sullivan, A.; Matthews, P.; van Beijnum, I. (abril de 2011). DNS64: Extensiones DNS para la traducción de direcciones de red de clientes IPv6 a servidores IPv4 . IETF . doi : 10.17487/RFC6147 . RFC 6147 .
  19. ↑ "README.DNS64" . GitHub . Archivado del original el 7 de abril de 2024. Consultado el 7 de abril de 2024 .
  20. ↑ "Servidor DNS de Technitium" . Technitium.com . Consultado el 6 de marzo de 2026 .{{cite web}}: CS1 mantenimiento: estado de la URL ( enlace )
  21. ↑ M. Mawatari; M. Kawashima; C. Byrne (abril de 2013). 464XLAT: Combinación de traducción con y sin estado . Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC6877 . ISSN 2070-1721 . RFC 6877 . Informativo.
  22. ↑ Žorž, Jan (3 de abril de 2013). "Vídeo: Demostración en directo de 464XLAT en el Congreso Mundial de IPv6 en París" . Internet Society . Archivado del original el 13 de septiembre de 2017. Consultado el 5 de agosto de 2013 .
  23. ↑ "464XLAT – Una solución para proporcionar servicios IPv4 sobre una red exclusivamente IPv6" . T-Mobile USA . Archivado del original el 12 de noviembre de 2020. Consultado el 5 de agosto de 2013 .
  24. ↑ "Estudio de caso: T-Mobile US adopta IPv6 exclusivamente mediante 464XLAT" . Internet Society . 13 de junio de 2014. Archivado del original el 4 de febrero de 2024. Consultado el 15 de enero de 2023 .
  25. ↑ Twardowska, Marta (6 de enero de 2015). "Orange Polska ha lanzado la primera solución innovadora de IPv6 del mundo con SoftAtHome" . Business Wire . Archivado del original el 15 de enero de 2023. Consultado el 15 de enero de 2023 .
  26. ↑ "Habilitación inalámbrica IPv6 de Telstra: pila única IPv6" . 6 de febrero de 2020. Archivado del original el 12 de junio de 2023. Consultado el 12 de junio de 2023 .
  27. ↑ Drown, Dan. "¿Qué es Android CLAT?" . Notas de Dan . Archivado del original el 17 de diciembre de 2022 . Recuperado el 15 de enero de 2023 .
  28. ↑ Havey, Daniel; Balasubramanian, Praveen (14 de febrero de 2019). "Características principales de la pila de red en la actualización Creators Update para Windows 10" . Blog de redes de Microsoft . Archivado del original el 1 de febrero de 2023. Consultado el 15 de enero de 2023 .
  29. ↑ "Anuncio de la vista previa pública de Windows CLAT" . Blog de redes de Microsoft . Consultado el 10 de junio de 2026 .
  30. ↑ "Twitter" . Consultado el 27 de junio de 2022 .
  31. ↑ " [ v6ops ] iOS12 IPv6-only" . Consultado el 5 de noviembre de 2018 .
  32. ↑ van Beijnum, Iljitsch (16 de junio de 2015). "Apple a los desarrolladores de iOS: el servicio celular solo con IPv6 llegará pronto, preparen sus aplicaciones" . Ars Technica . Archivado del original el 28 de junio de 2016. Consultado el 2 de julio de 2016 .
  33. ↑ Anderson, Tore (20 de mayo de 2019). "clatd" . GitHub . Archivado del original el 17 de diciembre de 2022. Recuperado el 15 de enero de 2023 .
  34. ↑ Strodl, Mary (12 de enero de 2025). "Agregar soporte para CLAT usando un programa BPF" . GitLab . Recuperado el 6 de febrero de 2025 .
  35. ↑ "NOTICIAS · 1.57.2-dev · NetworkManager / NetworkManager · GitLab" . GitLab . Consultado el 17-06-2026 .
  36. ↑ "Paquete Wiki de OpenWrt: 464xlat" . OpenWrt . Consultado el 1 de abril de 2024 .
  37. ↑ Baoi, Danilo G. (19 de junio de 2021). "Notas de la versión FreeBSD 12.1-RELEASE" . FreeBSD . Archivado del original el 15 de enero de 2023. Recuperado el 15 de enero de 2023 .
  38. ↑ A. Durand; R. Droms; J. Woodyatt; Y. Lee (agosto de 2011). Implementaciones de banda ancha Dual-Stack Lite tras el agotamiento de IPv4 . Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC6333 . ISSN 2070-1721 . RFC 6333 . Norma propuesta.
  39. ↑ Y. Cui; Q. Sun; M. Boucadair; T. Tsou; Y. Lee; I. Farrer (julio de 2015). Lightweight 4over6: An Extension to the Dual-Stack Lite Architecture . Internet Engineering Task Force . doi : 10.17487/RFC7596 . ISSN 2070-1721 . RFC 7596 . Norma propuesta.
  40. ↑ Chroboczek, Juliusz; Kumari, Warren; Høiland-Jørgensen, Toke (enero de 2025). Rutas IPv4 con un siguiente salto IPv6 . IETF . ID draft-chroboczek-intarea-v4-via-v6-03.
  41. ↑ Le Faucheur, François; Rosen, Eric (mayo de 2009). Publicidad de información de accesibilidad de la capa de red IPv4 con un siguiente salto IPv6 . IETF . doi : 10.17487/RFC5549 . RFC 5549 .
  42. ↑ Chroboczek, Juliusz (mayo de 2022). Rutas Pv4 con un siguiente salto IPv6 en el protocolo de enrutamiento Babel . IETF . doi : 10.17487/RFC9229 . RFC 9229 .
  43. ↑ Rammhold, Andreas (15 de diciembre de 2020). " [ RFC ] Babel: Agregar soporte para v4viav6" . BIRD Internet Routing Daemon . Archivado del original el 29 de diciembre de 2022. Recuperado el 15 de enero de 2023 .
  44. ↑ Chroboczek, Juliusz (5 de mayo de 2022). " [ Babel-users ] ANUNCIO: babeld-1.12" . Listas de Debian Alioth . Archivado del original el 29 de diciembre de 2022 . Recuperado el 15 de enero de 2023 .
  45. ↑ Mark Townsley (24 de septiembre de 2012). "Asignación de dirección + puerto" (PDF) . Cisco. Archivado (PDF) del original el 29 de diciembre de 2022. Consultado el 25 de septiembre de 2012 .
  46. ↑ X. Li; C. Bao; O. Troan; S. Matsushima; T. Murakami (julio de 2015). W. Dec (ed.). Mapeo de direcciones y puertos mediante traducción (MAP-T) . Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC7599 . ISSN 2070-1721 . RFC 7599 . Norma propuesta.
  47. ↑ W. Dec; X. Li; C. Bao; S. Matsushima; T. Murakami (julio de 2015). O. Troan; T. Taylor (eds.). Mapeo de direcciones y puertos con encapsulación (MAP-E) . Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC7597 . ISSN 2070-1721 . RFC 7597 . Norma propuesta.
  48. ↑ Patterson, Richard (mayo de 2021). "Solo IPv6 con MAP-T" . Jornada de puertas abiertas de RIPE NCC . Archivado del original el 21 de febrero de 2023. Consultado el 1 de agosto de 2023 .
  49. ↑ R. Despres; R. Penno; Y. Lee; G. Chen; M. Chen (julio de 2015). S. Jiang (ed.). Despliegue residual de IPv4 a través de IPv6: una solución sin estado (4.ª ed.) . Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC7600 . ISSN 2070-1721 . RFC 7600 . Experimental.
  • RFC 3089 – " Un mecanismo de puerta de enlace IPv6/IPv4 basado en SOCKS " , Informativo. 
  • RFC 6144 – " Marco para la traducción IPv4/IPv6 " , Informativo. 
  • RFC 6219 – " Diseño e implementación de la traducción IVI de la Red China de Educación e Investigación (CERNET) para la coexistencia y transición de IPv4/IPv6 " , Informativo. 
  • RFC 6535 – " Hosts de doble pila que utilizan "Bump-in-the-Host" (BIH), " Estándar propuesto. 
  • IPv6 en la práctica , Benedikt Stockebrand (2006), ISBN 3-540-24524-3
  • DJ Bernstein – El lío de IPv6
  • Christian y Tina Strauf – Cómo usar el traductor de relevos de transporte
  • Network World – Entendiendo Dual-Stack Lite Archivado el 20/10/2011 en Wayback Machine
  • Revisión técnica de IETE : Garantizar la interoperabilidad entre redes heterogéneas (IPv4/IPv6) sin utilizar la traducción de protocolos.
  • Transacciones KSII sobre Internet y sistemas de información: configuración de hosts para la detección automática de conectividad de red (IPv6, IPv6 en IPv4 o IPv4)