stringtranslate.com

Mecanismo de transición de IPv6

Un mecanismo de transición IPv6 es una tecnología que facilita la transición de Internet desde la infraestructura del Protocolo de Internet versión 4 (IPv4) en uso desde 1983 al sistema de direccionamiento y enrutamiento sucesor del Protocolo de Internet versión 6 (IPv6). Como las redes IPv4 e IPv6 no son directamente interoperables, las tecnologías de transición están diseñadas para permitir que los hosts de cualquiera de los dos tipos de red se comuniquen con cualquier otro host.

Para cumplir con sus criterios técnicos, IPv6 debe tener un plan de transición sencillo a partir del actual IPv4. [1] El Grupo de Trabajo de Ingeniería de Internet (IETF) lleva a cabo 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 hacia ese objetivo. Algunos mecanismos básicos de transición de IPv6 se definen en la RFC 4213.

Traducción de 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 comprobación de valor cero para evitar cambios en la suma de comprobación del encabezado del protocolo de transporte. [4] El algoritmo se puede utilizar en una solución que permite que los hosts IPv6 que no tienen una dirección IPv4 asignada permanentemente se comuniquen con hosts que solo tienen IPv4. La especificación no aborda los detalles de asignación de direcciones y enrutamiento. SIIT se puede considerar 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]

Corredor de túneles

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

6º

6rd fue desarrollado por Rémi Després . Es un mecanismo para facilitar la rápida implementación del servicio IPv6 en las infraestructuras IPv4 de los 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 los nodos de los clientes que los paquetes IPv4 .

Se utilizó para una implementación temprana a gran escala de un servicio IPv6 con direcciones nativas durante 2007 (RFC 5569 [9] ). La especificación estándar del protocolo se encuentra en RFC 5969. [10]

Traducción de retransmisión de transporte

RFC 3142 define el método Transport Relay Translation ( TRT ). TRT actúa como un dispositivo intermedio entre dos hosts. La función del traductor es convertir direcciones IPV6 en direcciones IPV4 y viceversa. TRT logra esta traducción a través de la asignación de direcciones IP y una dirección IP personalizada. [11]

Por ejemplo, si se van a transmitir 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 hacia el traductor primero a través de un protocolo IPv6/TCP y luego desde el traductor al host IPv4 a través de un protocolo IPv4/TCP. [12]

TRT emplea una operación similar a la traducción DNS entre registros AAAA y A, conocida como DNS-ALG, tal como se define en RFC 2694. [13]

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, p. ej., 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. A continuación, el servidor NAT64 crea una asignación NAT entre la dirección IPv6 y la dirección IPv4, lo que les permite comunicarse. [14]

DNS64

DNS64 describe un servidor DNS que, cuando se le solicitan los registros AAAA de un dominio , pero solo encuentra 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 RFC 6147. [15]

Hay dos problemas notables con este mecanismo de transición:

# El solucionador DNS 2606:4700:4700:64 sintetiza registros AAAA para # ipv6test.google.com en 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

Sistema internacional de alerta temprana (ISATAP)

ISATAP (Protocolo de direccionamiento automático de túnel dentro del sitio) es un mecanismo de transición IPv6 diseñado para transmitir paquetes IPv6 entre nodos de doble pila en la parte superior de 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 (NBMA) virtual, de modo que no requiere que la infraestructura de red IPv4 subyacente admita la multidifusión.

464XLAT

464XLAT (RFC 6877) permite a los clientes en redes que sólo admiten IPv6 acceder a servicios de Internet que sólo admiten IPv4, como Skype. [17] [18]

El cliente utiliza un traductor SIIT para convertir los 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 sólo admite IPv4. El traductor de cliente puede implementarse en el propio cliente o en un dispositivo intermedio y se lo conoce como CLAT (Customer-side transLATor). El traductor NAT64, o PLAT (Provider-side transLATor), debe poder llegar tanto al servidor como al cliente (a través del CLAT). El uso de NAT64 limita las conexiones a un modelo cliente-servidor que utiliza UDP, TCP e ICMP.

Implementaciones

Dual-Stack Lite (DS-Lite)

DS Lite

La tecnología Dual-Stack Lite no implica la asignación de una dirección IPv4 a los equipos en las instalaciones del cliente (CPE) para proporcionar acceso a Internet. [31] El CPE distribuye direcciones IPv4 privadas para los clientes de LAN, de acuerdo con el requisito de red en la red de área local. El CPE encapsula los paquetes IPv4 dentro de los paquetes IPv6. El CPE utiliza su conexión IPv6 global para entregar el paquete al NAT de nivel de operador (CGN) del ISP , que tiene una dirección IPv4 global. El paquete IPv4 original se recupera y se realiza NAT sobre el paquete IPv4 y se enruta a Internet IPv4 público. El CGN identifica de forma única los flujos de tráfico al registrar la dirección IPv6 pública del CPE, la dirección IPv4 privada y el número de puerto TCP o UDP como una sesión.

La versión ligera 4over6 extiende DS-Lite al trasladar la funcionalidad NAT del lado del ISP al CPE, lo que elimina la necesidad de implementar NAT de nivel de operador. [32] 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 rastreado para cada suscriptor, lo que mejora la escalabilidad de la infraestructura de traducción.

Enrutamiento de V4 a V6

El enrutamiento V4 a través de v6 es una técnica en la que las direcciones IPv4 se asignan solo a los hosts finales, mientras que a los enrutadores intermedios solo se les asignan direcciones IPv6. Las rutas IPv4 se propagan de la manera habitual y no se emplea traducción ni encapsulación de paquetes, sino que se utiliza un siguiente salto IPv6. El enrutamiento V4 a través de v6 reduce la cantidad de administración necesaria, ya que solo es necesario asignar direcciones IPv6 a la red central, pero aún así requiere que la red central pueda reenviar paquetes IPv4.

V4-via-v6 se define para el protocolo de puerta de enlace de borde (BGP) [33] y el protocolo de enrutamiento Babel . [34] Se ha implementado el demonio de enrutamiento de Internet Bird [35] y en babeld . [36]

MAPA

Mapping of Address and Port (MAP) es una propuesta de transición de Cisco IPv6 que combina la traducción de direcciones de puerto A+P con la tunelización de paquetes IPv4 a través de la red IPv6 interna de un proveedor de ISP . [37] MAP-T [38] y MAP-E [39] entraron en la vía de estándares en julio de 2015, y Sky Italia ha implementado MAP-T en sus servicios de Internet a principios del año 2021. [40]

Proyectos de propuestas

Los siguientes mecanismos aún se están discutiendo o han sido abandonados por el IETF:

4º

El Despliegue Residual de IPv4 (4rd) es un mecanismo experimental [41] 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 capa de transporte. Se trata de una variante sin estado del modelo A+P .

Mecanismos obsoletos

El IETF ha dejado obsoletos estos mecanismos:

NAT-PT

La traducción de direcciones de red/traducción de protocolo ( NAT-PT ) se define en RFC 2766, pero debido a numerosos problemas, quedó obsoleta en RFC 4966 y pasó a ser un método histórico. Generalmente se utiliza junto con una implementación de puerta de enlace a nivel de aplicación DNS (DNS-ALG).

NAPT-PT

Aunque es casi idéntico a NAT-PT, Network Address Port Translation + Protocol Translation , que también se describe en RFC 2766, agrega la traducción de los puertos y la dirección. Esto se hace principalmente para evitar que dos hosts de un lado del mecanismo utilicen el mismo puerto expuesto del otro lado del mecanismo, lo que podría causar inestabilidad en la aplicación y fallas de seguridad. Este mecanismo ha quedado obsoleto en RFC 4966.

Implementaciones

Véase también

Referencias

  1. ^ Partridge, C.; Kastenholz, F. (diciembre de 1994). Criterios técnicos para elegir IP The Next Generation (IPng). doi : 10.17487/RFC1726 . RFC 1726.
  2. ^ F. Baker ; X. Li; C. Bao; K. Yin (abril de 2011). Marco para la traducción de IPv4/IPv6. Grupo de trabajo de ingeniería de Internet (IETF). doi : 10.17487/RFC6144 . ISSN  2070-1721. RFC 6144. Informativo.
  3. ^ ab 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 (IETF). doi : 10.17487/RFC6052 . ISSN  2070-1721. RFC 6052. Norma propuesta. Actualizaciones RFC 4291.
  4. ^ ab C. Bao; X. Li; F. Baker ; T. Anderson; F. Gont (junio de 2016). Algoritmo de traducción IP/ICMP sin estado. 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. Quedó 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 (IETF). doi : 10.17487/RFC6145 . ISSN  2070-1721. RFC 6145. Obsoleto. Quedó obsoleto según RFC 7915. Actualizado por RFC 6791 y 7757.
  7. ^ M. Blanchet; F. Parent (febrero de 2010). Agente de túneles IPv6 con el protocolo de configuración de túneles (TSP). doi : 10.17487/RFC5572 . ISSN  2070-1721. RFC 5572. Experimental.
  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. ^ Despres, R. (enero de 2010). Implementación rápida de IPv6 en infraestructuras IPv4 (6.º). doi : 10.17487/RFC5569 . RFC 5569.
  10. ^ Troan, O. (agosto de 2010). Implementación rápida de IPv6 en infraestructuras IPv4 (6.º) – Especificación del protocolo. doi : 10.17487/RFC5969 . RFC 5969.
  11. ^ Hagino, J.; Yamamoto, K. (junio de 2001). "Un traductor de retransmisión de transporte de IPv6 a IPv4". rfc-editor.org . Solicitud de comentarios Editor . Consultado el 28 de junio de 2024 .
  12. ^ Shanmugaraja, P. "Diseño e implementación de un traductor de retransmisión de transporte y sus mitigaciones de seguridad". researchgate.net . Research Gate . Consultado el 28 de junio de 2024 .
  13. ^ Heffernan, Andy; Tsirtsis, George; Srisuresh, Pyda; Akkiraju, Praveen (septiembre de 1999). "Extensiones DNS para traductores de direcciones de red (DNS_ALG)". rfc-editor.org . Consultado el 28 de junio de 2024 .
  14. ^ M. Bagnulo; P. Matthews; I. van Beijnum (abril de 2011). Stateful NAT64: Traducción de protocolos y direcciones de red desde clientes IPv6 a servidores IPv4. Grupo de trabajo de ingeniería de Internet (IETF). doi : 10.17487/RFC6146 . ISSN  2070-1721. RFC 6146. Norma propuesta.
  15. ^ Bagnulo, M.; Sullivan, A.; Matthews, P.; van Beijnum, I. (abril de 2011). DNS64: extensiones DNS para la traducción de direcciones de red desde clientes IPv6 a servidores IPv4. doi : 10.17487/RFC6147 . RFC 6147.
  16. ^ "README.DNS64". GitHub . Archivado desde el original el 7 de abril de 2024 . Consultado el 7 de abril de 2024 .
  17. ^ Žorž, Jan (3 de abril de 2013). «Video: Demostración en vivo de 464XLAT en el Congreso Mundial IPv6 en París». Internet Society . Archivado desde el original el 13 de septiembre de 2017. Consultado el 5 de agosto de 2013 .
  18. ^ "464XLAT: una solución para brindar servicios IPv4 a través de una red que solo admita IPv6". T-Mobile USA . Archivado desde el original el 12 de noviembre de 2020. Consultado el 5 de agosto de 2013 .
  19. ^ "Estudio de caso: T-Mobile US pasa a utilizar solo IPv6 con 464XLAT". Internet Society . 13 de junio de 2014. Archivado desde el original el 4 de febrero de 2024. Consultado el 15 de enero de 2023 .
  20. ^ Twardowska, Marta (6 de enero de 2015). "Orange Polska ha lanzado la primera solución IPv6 innovadora del mundo con SoftAtHome". Business Wire . Archivado desde el original el 2023-01-15 . Consultado el 2023-01-15 .
  21. ^ "Habilitación inalámbrica IPv6 de Telstra: pila única IPv6". 6 de febrero de 2020. Archivado desde el original el 12 de junio de 2023. Consultado el 12 de junio de 2023 .
  22. ^ Drown, Dan. "¿Qué es Android CLAT?". Notas de Dan . Archivado desde el original el 17 de diciembre de 2022. Consultado el 15 de enero de 2023 .
  23. ^ Havey, Daniel; Balasubramanian, Praveen (14 de febrero de 2019). "Características de la pila de red principal en la actualización Creators Update para Windows 10". Blog de redes de Microsoft . Archivado desde el original el 1 de febrero de 2023. Consultado el 15 de enero de 2023 .
  24. ^ "Windows 11 planea ampliar la compatibilidad con CLAT". Blog de redes de Microsoft . Archivado desde el original el 8 de marzo de 2024. Consultado el 7 de marzo de 2024 .
  25. ^ "Twitter" . Consultado el 27 de junio de 2022 .
  26. ^ "[v6ops] iOS12 solo IPv6" . Consultado el 5 de noviembre de 2018 .
  27. ^ van Beijnum, Iljitsch (16 de junio de 2015). "Apple a los desarrolladores de iOS: el servicio celular solo IPv6 llegará pronto, preparen sus aplicaciones". Ars Technica . Archivado desde el original el 28 de junio de 2016 . Consultado el 2 de julio de 2016 .
  28. ^ Anderson, Tore (20 de mayo de 2019). «clatd». GitHub . Archivado desde el original el 17 de diciembre de 2022 . Consultado el 15 de enero de 2023 .
  29. ^ "Paquete Wiki OpenWrt: 464xlat". OpenWrt . Consultado el 1 de abril de 2024 .
  30. ^ Baoi, Danilo G. (19 de junio de 2021). «Notas de la versión de FreeBSD 12.1-RELEASE». FreeBSD . Archivado desde el original el 15 de enero de 2023 . Consultado el 15 de enero de 2023 .
  31. ^ A. Durand; R. Droms; J. Woodyatt; Y. Lee (agosto de 2011). Implementaciones de banda ancha de doble pila Lite tras el agotamiento de IPv4. Grupo de trabajo de ingeniería de Internet (IETF). doi : 10.17487/RFC6333 . ISSN  2070-1721. RFC 6333. Norma propuesta.
  32. ^ 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. Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC7596 . ISSN  2070-1721. RFC 7596. Norma propuesta.
  33. ^ Le Faucheur, François; Rosen, Eric (mayo de 2009). Publicidad de información de accesibilidad de la capa de red IPv4 con un próximo salto IPv6. doi : 10.17487/RFC5549 . RFC 5549.
  34. ^ Chroboczek, Juliusz (mayo de 2022). Rutas Pv4 con un siguiente salto IPv6 en el protocolo de enrutamiento Babel. doi : 10.17487/RFC9229 . RFC 9229.
  35. ^ Rammhold, Andreas (15 de diciembre de 2020). «[RFC] Babel: Add v4viav6 Support». BIRD Internet Routing Daemon . Archivado desde el original el 2022-12-29 . Consultado el 2023-01-15 .
  36. ^ Chroboczek, Juliusz (5 de mayo de 2022). «[Babel-users] ANUNCIO: babeld-1.12». Listas de Debian Alioth . Archivado desde el original el 29 de diciembre de 2022. Consultado el 15 de enero de 2023 .
  37. ^ Mark Townsley (24 de septiembre de 2012). "Mapping Address + Port" (PDF) . Cisco. Archivado (PDF) del original el 29 de diciembre de 2022 . Consultado el 25 de septiembre de 2012 .
  38. ^ 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 (IETF). doi : 10.17487/RFC7599 . ISSN  2070-1721. RFC 7599. Norma propuesta.
  39. ^ 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 (IETF). doi : 10.17487/RFC7597 . ISSN  2070-1721. RFC 7597. Norma propuesta.
  40. ^ Patterson, Richard (mayo de 2021). «Solo IPv6 con MAP-T». Jornada de puertas abiertas de RIPE NCC . Archivado desde el original el 21 de febrero de 2023. Consultado el 1 de agosto de 2023 .
  41. ^ R. Despres; R. Penno; Y. Lee; G. Chen; M. Chen (julio de 2015). S. Jiang (ed.). Implementación residual de IPv4 a través de IPv6: una solución sin estado (4.º). Grupo de trabajo de ingeniería de Internet (IETF). doi : 10.17487/RFC7600 . ISSN  2070-1721. RFC 7600. Experimental.

Enlaces externos