IPv6

El Protocolo de Internet versión 6 (IPv6) es la versión más reciente del Protocolo de Internet (IP), el protocolo de comunicaciones que proporciona un sistema de identificación y ubicación para computadoras en redes y enruta el tráfico a través de Internet. IPv6 fue desarrollado por el Grupo de Trabajo de Ingeniería de Internet (IETF, por sus siglas en inglés) para abordar el problema largamente anticipado del agotamiento de las direcciones IPv4 y está destinado a reemplazar a IPv4. En diciembre de 1998, IPv6 se convirtió en un borrador de estándar para el IETF, que posteriormente lo ratificó como estándar de Internet el 14 de julio de 2017.

A los dispositivos en Internet se les asigna una dirección IP única para identificación y definición de ubicación. Con el rápido crecimiento de Internet después de la comercialización en la década de 1990, se hizo evidente que se necesitarían muchas más direcciones para conectar dispositivos que las que tenía disponible el espacio de direcciones IPv4. En 1998, el IETF había formalizado el protocolo sucesor. IPv6 utiliza direcciones de 128 bits, lo que teóricamente permite 2 o aproximadamente3,4 × 10 direcciones totales. El número real es un poco más pequeño, ya que se reservan múltiples rangos para uso especial o se excluyen por completo del uso. Los dos protocolos no están diseñados para ser interoperables y, por lo tanto, la comunicación directa entre ellos es imposible, lo que complica el paso a IPv6. Sin embargo, se han ideado varios mecanismos de transición para rectificar esto.

IPv6 proporciona otros beneficios técnicos además de un espacio de direccionamiento más grande. En particular, permite métodos de asignación de direcciones jerárquicas que facilitan la agregación de rutas a través de Internet y, por lo tanto, limitan la expansión de las tablas de enrutamiento. El uso del direccionamiento de multidifusión se amplía y simplifica, y proporciona una optimización adicional para la prestación de servicios. Los aspectos de movilidad, seguridad y configuración del dispositivo se han considerado en el diseño del protocolo.

Las direcciones IPv6 se representan como ocho grupos de cuatro dígitos hexadecimales cada uno, separados por dos puntos. La representación plena podrá acortarse; por ejemplo, 2001:0db8:0000:0000:0000:8a2e:0370:7334 se convierte en 2001:db8::8a2e:370:7334.

Principales características

IPv6 es un protocolo de capa de Internet para interconexión de redes conmutadas por paquetes y proporciona transmisión de datagramas de extremo a extremo a través de múltiples redes IP, siguiendo de cerca los principios de diseño desarrollados en la versión anterior del protocolo, Protocolo de Internet Versión 4 (IPv4).

Además de ofrecer más direcciones, IPv6 también implementa características que no están presentes en IPv4. Simplifica los aspectos de la configuración de direcciones, la renumeración de redes y los anuncios de enrutadores al cambiar de proveedor de conectividad de red. Simplifica el procesamiento de paquetes en los enrutadores al colocar la responsabilidad de la fragmentación de paquetes en los puntos finales. El tamaño de la subred IPv6 está estandarizado fijando el tamaño de la parte del identificador de host de una dirección en 64 bits.

La arquitectura de direccionamiento de IPv6 se define en RFC 4291 y permite tres tipos diferentes de transmisión: unicast, anycast y multicast.

Motivación y origen

Agotamiento de direcciones IPv4

El Protocolo de Internet Versión 4 (IPv4) fue la primera versión del Protocolo de Internet utilizada públicamente. IPv4 fue desarrollado como un proyecto de investigación por la Agencia de Proyectos de Investigación Avanzada de Defensa (DARPA), una agencia del Departamento de Defensa de los Estados Unidos, antes de convertirse en la base de Internet y la World Wide Web. IPv4 incluye un sistema de direccionamiento que utiliza identificadores numéricos de 32 bits. Estas direcciones generalmente se muestran en notación decimal de puntos como valores decimales de cuatro octetos, cada uno en el rango de 0 a 255, u 8 bits por número. Por lo tanto, IPv4 proporciona una capacidad de direccionamiento de 2 o aproximadamente 4300 millones de direcciones. El agotamiento de direcciones no fue inicialmente una preocupación en IPv4, ya que originalmente se suponía que esta versión era una prueba de los conceptos de red de DARPA.Durante la primera década de funcionamiento de Internet, se hizo evidente que debían desarrollarse métodos para conservar el espacio de direcciones. A principios de la década de 1990, incluso después del rediseño del sistema de direccionamiento utilizando un modelo de red sin clases, quedó claro que esto no sería suficiente para evitar el agotamiento de las direcciones IPv4 y que se necesitaban más cambios en la infraestructura de Internet.

Los últimos bloques de direcciones de nivel superior sin asignar de 16 millones de direcciones IPv4 fueron asignados en febrero de 2011 por la Autoridad de Números Asignados de Internet (IANA) a los cinco registros regionales de Internet (RIR). Sin embargo, cada RIR aún tiene grupos de direcciones disponibles y se espera que continúe con las políticas de asignación de direcciones estándar hasta que quede un bloque de enrutamiento entre dominios sin clases (CIDR) /8. Después de eso, solo se proporcionarán bloques de 1024 direcciones (/22) desde los RIR a un registro local de Internet (LIR). A partir de septiembre de 2015, todo el Centro de Información de Redes de Asia-Pacífico (APNIC), el Centro de Coordinación de Redes de Réseaux IP Européens (RIPE_NCC), el Centro de Información de Redes de América Latina y el Caribe (LACNIC) y el Registro Americano de Números de Internet (ARIN) han alcanzado este escenario.Esto deja al African Network Information Center (AFRINIC) como el único registro regional de Internet que aún usa el protocolo normal para distribuir direcciones IPv4. A partir de noviembre de 2018, la asignación mínima de AFRINIC es /22 o 1024 direcciones IPv4. Un LIR puede recibir una asignación adicional cuando se haya utilizado aproximadamente el 80% de todo el espacio de direcciones.

RIPE NCC anunció que se había quedado sin direcciones IPv4 el 25 de noviembre de 2019 y pidió un mayor progreso en la adopción de IPv6.

Se espera ampliamente que Internet utilice IPv4 junto con IPv6 en el futuro previsible.

Comparación con IPv4

En Internet, los datos se transmiten en forma de paquetes de red. IPv6 especifica un nuevo formato de paquete, diseñado para minimizar el procesamiento de encabezados de paquetes por parte de los enrutadores. Debido a que los encabezados de los paquetes IPv4 y los paquetes IPv6 son significativamente diferentes, los dos protocolos no son interoperables. Sin embargo, la mayoría de los protocolos de capa de aplicación y de transporte necesitan poco o ningún cambio para operar sobre IPv6; las excepciones son los protocolos de aplicación que incorporan direcciones de capa de Internet, como el Protocolo de transferencia de archivos (FTP) y el Protocolo de tiempo de red (NTP), donde el nuevo formato de dirección puede causar conflictos con la sintaxis del protocolo existente.

Espacio de direcciones más grande

La principal ventaja de IPv6 sobre IPv4 es su mayor espacio de direcciones. El tamaño de una dirección IPv6 es de 128 bits, en comparación con los 32 bits de IPv4. Por lo tanto, el espacio de direcciones tiene 2 = 340 282 366 920 938 463 463 374 607 431 768 211 456 direcciones (aproximadamente3,4 × 10). Algunos bloques de este espacio y algunas direcciones específicas están reservados para usos especiales.

Si bien este espacio de direcciones es muy grande, no fue la intención de los diseñadores de IPv6 asegurar la saturación geográfica con direcciones utilizables. Más bien, las direcciones más largas simplifican la asignación de direcciones, permiten la agregación de rutas eficiente y permiten la implementación de funciones de direccionamiento especiales. En IPv4, se desarrollaron métodos complejos de enrutamiento entre dominios sin clase (CIDR) para aprovechar al máximo el pequeño espacio de direcciones. El tamaño estándar de una subred en IPv6 es de 2 direcciones, aproximadamente cuatro mil millones de veces el tamaño de todo el espacio de direcciones IPv4. Por lo tanto, la utilización real del espacio de direcciones será pequeña en IPv6, pero la administración de la red y la eficiencia del enrutamiento mejorarán con el gran espacio de subred y la agregación jerárquica de rutas.

Multidifusión

La multidifusión, la transmisión de un paquete a múltiples destinos en una sola operación de envío, es parte de la especificación base en IPv6. En IPv4, esta es una característica opcional (aunque comúnmente implementada). El direccionamiento de multidifusión IPv6 tiene características y protocolos en común con la multidifusión IPv4, pero también proporciona cambios y mejoras al eliminar la necesidad de ciertos protocolos. IPv6 no implementa la transmisión IP tradicional, es decir, la transmisión de un paquete a todos los hosts en el enlace adjunto utilizando una dirección de transmisión especial y, por lo tanto, no define las direcciones de transmisión. En IPv6, se logra el mismo resultado enviando un paquete al enlace local de todos los nodosgrupo de multidifusión en la dirección ff02::1, que es similar a la multidifusión IPv4 a la dirección 224.0.0.1. IPv6 también proporciona nuevas implementaciones de multidifusión, incluida la incorporación de direcciones de puntos de encuentro en una dirección de grupo de multidifusión de IPv6, lo que simplifica la implementación de soluciones entre dominios.

En IPv4, es muy difícil para una organización obtener incluso una asignación de grupo de multidifusión enrutable globalmente, y la implementación de soluciones entre dominios es arcana. Las asignaciones de direcciones de unidifusión por parte de un registro de Internet local para IPv6 tienen al menos un prefijo de enrutamiento de 64 bits, lo que genera el tamaño de subred más pequeño disponible en IPv6 (también 64 bits). Con una asignación de este tipo, es posible incorporar el prefijo de dirección de unidifusión en el formato de dirección de multidifusión IPv6, al mismo tiempo que se proporciona un bloque de 32 bits, los bits menos significativos de la dirección o aproximadamente 4200 millones de identificadores de grupo de multidifusión. Por lo tanto, cada usuario de una subred IPv6 tiene automáticamente disponible un conjunto de grupos de multidifusión específicos de fuente enrutables globalmente para aplicaciones de multidifusión.

Configuración automática de direcciones sin estado (SLAAC)

Los hosts IPv6 se configuran automáticamente. Cada interfaz tiene una dirección local de enlace autogenerada y, cuando se conecta a una red, se realiza la resolución de conflictos y los enrutadores proporcionan prefijos de red a través de anuncios de enrutador. La configuración sin estado de los enrutadores se puede lograr con un protocolo especial de renumeración de enrutadores. Cuando sea necesario, los hosts pueden configurar direcciones con estado adicionales a través del Protocolo de configuración dinámica de host versión 6 (DHCPv6) o direcciones estáticas manualmente.

Al igual que IPv4, IPv6 admite direcciones IP únicas a nivel mundial. El diseño de IPv6 pretendía volver a enfatizar el principio de extremo a extremo del diseño de red que se concibió originalmente durante el establecimiento de la primera Internet al hacer obsoleta la traducción de direcciones de red. Por lo tanto, cada dispositivo en la red es globalmente direccionable directamente desde cualquier otro dispositivo.

Una dirección IP estable, única y globalmente direccionable facilitaría el seguimiento de un dispositivo a través de las redes. Por lo tanto, dichas direcciones son una preocupación de privacidad particular para los dispositivos móviles, como computadoras portátiles y teléfonos celulares. Para abordar estos problemas de privacidad, el protocolo SLAAC incluye lo que normalmente se denomina "direcciones de privacidad" o, más correctamente, "direcciones temporales", codificadas en RFC 4941, "Extensiones de privacidad para la configuración automática de direcciones sin estado en IPv6". Las direcciones temporales son aleatorias e inestables. Un dispositivo de consumo típico genera una nueva dirección temporal todos los días e ignorará el tráfico dirigido a una dirección anterior después de una semana. Las direcciones temporales son utilizadas por defecto por Windows desde XP SP1,macOS desde (Mac OS X) 10.7, Android desde 4.0 e iOS desde la versión 4.3. El uso de direcciones temporales por parte de las distribuciones de Linux varía.

Volver a numerar una red existente para un nuevo proveedor de conectividad con diferentes prefijos de enrutamiento es un gran esfuerzo con IPv4. Sin embargo, con IPv6, cambiar el prefijo anunciado por algunos enrutadores puede, en principio, volver a numerar una red completa, ya que los identificadores de host (los 64 bits menos significativos de una dirección) pueden ser autoconfigurados de forma independiente por un host.

El método de generación de direcciones SLAAC depende de la implementación. IETF recomienda que las direcciones sean deterministas pero semánticamente opacas.

IPsec

La seguridad del protocolo de Internet (IPsec) se desarrolló originalmente para IPv6, pero encontró una implementación generalizada primero en IPv4, para lo cual se rediseñó. IPsec era una parte obligatoria de todas las implementaciones del protocolo IPv6,e Internet Key Exchange (IKE), pero con RFC 6434 la inclusión de IPsec en las implementaciones de IPv6 se rebajó a una recomendación porque se consideró poco práctico exigir la implementación completa de IPsec para todos los tipos de dispositivos que pueden usar IPv6. Sin embargo, a partir de RFC 4301, las implementaciones del protocolo IPv6 que implementan IPsec deben implementar IKEv2 y deben admitir un conjunto mínimo de algoritmos criptográficos. Este requisito ayudará a que las implementaciones de IPsec sean más interoperables entre dispositivos de diferentes proveedores. El encabezado de autenticación IPsec (AH) y el encabezado de carga útil de seguridad de encapsulación (ESP) se implementan como encabezados de extensión IPv6.

Procesamiento simplificado por enrutadores

El encabezado del paquete en IPv6 es más simple que el encabezado de IPv4. Muchos campos de uso poco frecuente se han movido a extensiones de encabezado opcionales. Con el encabezado del paquete IPv6 simplificado, el proceso de reenvío de paquetes por parte de los enrutadores se ha simplificado. Aunque los encabezados de los paquetes IPv6 tienen al menos el doble del tamaño de los encabezados de los paquetes IPv4, el procesamiento de los paquetes que solo contienen el encabezado IPv6 base por parte de los enrutadores puede, en algunos casos, ser más eficiente, porque se requiere menos procesamiento en los enrutadores debido a que los encabezados están alineados. para que coincida con los tamaños de palabra comunes. Sin embargo, muchos dispositivos implementan la compatibilidad con IPv6 en el software (a diferencia del hardware), lo que da como resultado un rendimiento de procesamiento de paquetes muy bajo.Además, para muchas implementaciones, el uso de encabezados de extensión hace que la CPU del enrutador procese los paquetes, lo que genera un rendimiento deficiente o incluso problemas de seguridad.

Además, un encabezado de IPv6 no incluye una suma de verificación. La suma de comprobación del encabezado IPv4 se calcula para el encabezado IPv4 y los enrutadores deben volver a calcularlo cada vez que el tiempo de vida (llamado límite de salto en el protocolo IPv6) se reduce en uno. La ausencia de una suma de verificación en el encabezado de IPv6 promueve el principio de extremo a extremo del diseño de Internet, que preveía que la mayor parte del procesamiento en la red ocurre en los nodos hoja. Se supone que la protección de la integridad de los datos encapsulados en el paquete IPv6 está garantizada tanto por la capa de enlace como por la detección de errores en los protocolos de capa superior, a saber, el Protocolo de control de transmisión (TCP) y el Protocolo de datagramas de usuario (UDP) en el transporte. capa. Por lo tanto, mientras que IPv4 permitía que los encabezados de datagramas UDP no tuvieran suma de control (indicado por 0 en el campo del encabezado), IPv6 requiere una suma de control en los encabezados UDP.

Los enrutadores IPv6 no realizan la fragmentación de IP. Los hosts IPv6 son necesarios para realizar el descubrimiento de la MTU de la ruta, realizar la fragmentación de un extremo a otro o enviar paquetes que no superen la unidad de transmisión máxima (MTU) predeterminada, que es de 1280 octetos.

Movilidad

A diferencia del IPv4 móvil, el IPv6 móvil evita el enrutamiento triangular y, por lo tanto, es tan eficiente como el IPv6 nativo. Los enrutadores IPv6 también pueden permitir que subredes completas se muevan a un nuevo punto de conexión del enrutador sin volver a numerar.

Encabezados de extensión

El encabezado del paquete IPv6 tiene un tamaño mínimo de 40 octetos (320 bits). Las opciones se implementan como extensiones. Esto brinda la oportunidad de extender el protocolo en el futuro sin afectar la estructura del paquete central. Sin embargo, RFC 7872 señala que algunos operadores de red descartan paquetes IPv6 con encabezados de extensión cuando atraviesan sistemas autónomos de tránsito.

Jumbogramas

IPv4 limita los paquetes a 65 535 (2 −1) octetos de carga útil. Un nodo IPv6 puede manejar opcionalmente paquetes por encima de este límite, denominados jumbogramas, que pueden tener un tamaño de hasta 4 294 967 295 (2 −1) octetos. El uso de jumbogramas puede mejorar el rendimiento en enlaces de alta MTU. El uso de jumbogramas se indica mediante el encabezado de extensión Jumbo Payload Option.

Paquetes IPv6

Un paquete IPv6 tiene dos partes: un encabezado y una carga útil.

El encabezado consta de una parte fija con una funcionalidad mínima requerida para todos los paquetes y puede ir seguido de extensiones opcionales para implementar funciones especiales.

El encabezado fijo ocupa los primeros 40 octetos (320 bits) del paquete IPv6. Contiene las direcciones de origen y destino, la clase de tráfico, el conteo de saltos y el tipo de extensión opcional o carga útil que sigue al encabezado. Este campo Siguiente encabezado le dice al receptor cómo interpretar los datos que siguen al encabezado. Si el paquete contiene opciones, este campo contiene el tipo de opción de la siguiente opción. El campo "Siguiente encabezado" de la última opción apunta al protocolo de capa superior que se transporta en la carga útil del paquete.

El uso actual del campo de clase de tráfico IPv6 lo divide entre un punto de código de servicios diferenciados de 6 bits y un campo de notificación de congestión explícita de 2 bits.

Los encabezados de extensión contienen opciones que se utilizan para el tratamiento especial de un paquete en la red, por ejemplo, para el enrutamiento, la fragmentación y la seguridad mediante el marco IPsec.

Sin opciones especiales, una carga útil debe ser inferior a 64 kB. Con una opción de carga útil gigante (en un encabezado de extensión de opciones Hop-By-Hop), la carga útil debe ser inferior a 4 GB.

A diferencia de IPv4, los enrutadores nunca fragmentan un paquete. Se espera que los hosts usen Path MTU Discovery para hacer que sus paquetes sean lo suficientemente pequeños para llegar al destino sin necesidad de fragmentarlos. Consulte Fragmentación de paquetes IPv6.

Direccionamiento

Las direcciones IPv6 tienen 128 bits. El diseño del espacio de direcciones IPv6 implementa una filosofía de diseño diferente a la de IPv4, en la que se utilizó la división en subredes para mejorar la eficiencia de la utilización del pequeño espacio de direcciones. En IPv6, el espacio de direcciones se considera lo suficientemente grande para el futuro previsible, y una subred de área local siempre usa 64 bits para la parte del host de la dirección, designada como identificador de interfaz, mientras que los 64 bits más significativos se usan como enrutamiento. prefijo. Si bien ha existido el mito de que las subredes IPv6 son imposibles de escanear, RFC 7707 señala que los patrones resultantes de algunas técnicas y algoritmos de configuración de direcciones IPv6 permiten el escaneo de direcciones en muchos escenarios del mundo real.

Dirección de representación

Los 128 bits de una dirección IPv6 se representan en 8 grupos de 16 bits cada uno. Cada grupo se escribe como cuatro dígitos hexadecimales (a veces llamados hextetos o más formalmente hexadectetos e informalmente quibble o quad-nibble) y los grupos están separados por dos puntos (:). Un ejemplo de esta representación es 2001:0db8:0000:0000:0000:ff00:0042:8329.

Por conveniencia y claridad, la representación de una dirección IPv6 se puede acortar con las siguientes reglas:

• Se eliminan uno o más ceros iniciales de cualquier grupo de dígitos hexadecimales, lo que normalmente se hace con todos los ceros iniciales. Por ejemplo, el grupo 0042 se convierte en 42.
• Las secciones consecutivas de ceros se reemplazan con dos puntos (::). Esto solo se puede usar una vez en una dirección, ya que el uso múltiple haría que la dirección fuera indeterminada. RFC 5952 requiere que no se usen dos puntos dobles para indicar una sola sección de ceros omitida.

Un ejemplo de aplicación de estas reglas:Dirección inicial: 2001:0db8:0000:0000:0000:ff00:0042:8329.Después de eliminar todos los ceros iniciales de cada grupo: 2001:db8:0:0:0:ff00:42:8329.Después de omitir secciones consecutivas de ceros: 2001:db8::ff00:42:8329.

La dirección de loopback 0000:0000:0000:0000:0000:0000:0000:0001 se define en RFC 5156 y se abrevia a ::1 usando ambas reglas.

Como una dirección IPv6 puede tener más de una representación, el IETF ha emitido un estándar propuesto para representarlas en texto.

Debido a que las direcciones IPv6 contienen dos puntos y las URL usan dos puntos para separar el host del número de puerto, RFC2732 especifica que una dirección IPv6 utilizada como parte del host de una URL debe estar entre corchetes, por ejemplo, http://[2001:db8:4006:812::200e] o http://[2001:db8:4006:812::200e]:8080/path/page.html.

Dirección de enlace local

Todas las interfaces de los hosts IPv6 requieren una dirección local de enlace, que tiene el prefijo fe80:: / 10. Este prefijo se combina con un sufijo de 64 bits, que el host puede calcular y asignar por sí mismo sin la presencia o la cooperación de un componente de red externo como un servidor DHCP, en un proceso denominado configuración automática de direcciones de enlace local.

Los 64 bits inferiores de la dirección local de enlace (el sufijo) se derivaron originalmente de la dirección MAC de la tarjeta de interfaz de red subyacente. Como este método de asignación de direcciones causaría cambios de dirección no deseados cuando se reemplazaran las tarjetas de red defectuosas, y como también sufría una serie de problemas de seguridad y privacidad, RFC 8064 reemplazó el método original basado en MAC con el método basado en hash especificado en RFC 7217.

Unicidad de dirección y solicitud de enrutador

IPv6 utiliza un nuevo mecanismo para asignar direcciones IP a direcciones de capa de enlace (direcciones MAC), porque no admite el método de direccionamiento de difusión, en el que se basa la funcionalidad del Protocolo de resolución de direcciones (ARP) en IPv4. IPv6 implementa el Protocolo de descubrimiento de vecinos (NDP, ND) en la capa de enlace, que se basa en ICMPv6 y transmisión de multidifusión. Los hosts IPv6 verifican la unicidad de sus direcciones IPv6 en una red de área local (LAN) mediante el envío de un mensaje de solicitud de vecino que solicita la dirección de capa de enlace de la dirección IP. Si cualquier otro host en la LAN está usando esa dirección, responde.

Un host que presenta una nueva interfaz IPv6 primero genera una dirección local de enlace única utilizando uno de varios mecanismos diseñados para generar una dirección única. Si se detecta una dirección no única, el host puede volver a intentarlo con una dirección recién generada. Una vez que se establece una dirección local de enlace única, el host IPv6 determina si la LAN está conectada en este enlace a cualquier interfaz de enrutador que admita IPv6. Lo hace enviando un mensaje de solicitud de enrutador ICMPv6 a todos los enrutadoresgrupo de multidifusión con su dirección de enlace local como origen. Si no hay respuesta después de un número predeterminado de intentos, el host concluye que no hay enrutadores conectados. Si recibe una respuesta, conocida como anuncio de enrutador, de un enrutador, la respuesta incluye la información de configuración de la red para permitir el establecimiento de una dirección global única con un prefijo de red de unidifusión adecuado. También hay dos bits de bandera que le dicen al host si debe usar DHCP para obtener más información y direcciones:

• El bit Administrar, que indica si el host debe o no usar DHCP para obtener direcciones adicionales en lugar de depender de una dirección configurada automáticamente desde el anuncio del enrutador.
• El otro bit, que indica si el host debe o no obtener otra información a través de DHCP. La otra información consta de una o más opciones de información de prefijo para las subredes a las que está conectado el host, una vida útil para el prefijo y dos indicadores:
  • En enlace: si se establece este indicador, el host tratará todas las direcciones en la subred específica como si estuvieran en enlace y les enviará paquetes directamente en lugar de enviarlos a un enrutador durante el tiempo de vida determinado.
  • Dirección: esta bandera le dice al host que realmente cree una dirección global.

Direccionamiento global

El procedimiento de asignación de direcciones globales es similar a la construcción de direcciones locales. El prefijo se obtiene de los anuncios de enrutadores en la red. Los anuncios de varios prefijos hacen que se configuren varias direcciones.

La autoconfiguración de direcciones sin estado (SLAAC) requiere un bloque de direcciones / 64, como se define en RFC 4291. A los registros locales de Internet se les asignan al menos 32 bloques , que se dividen entre las redes subordinadas. La recomendación inicial establecía la asignación de una subred / 48 a sitios de consumidores finales (RFC 3177). Esto fue reemplazado por RFC 6177, que "recomienda otorgar a los sitios de inicio significativamente más de un / 64, pero tampoco recomienda que a cada sitio de inicio se le otorgue un / 48 ". / 56s se consideran específicamente. Queda por ver si los ISP respetarán esta recomendación. Por ejemplo, durante las pruebas iniciales, los clientes de Comcast recibieron una sola red / 64.

IPv6 en el sistema de nombres de dominio

En el Sistema de nombres de dominio (DNS), los nombres de host se asignan a direcciones IPv6 mediante registros de recursos AAAA ("quad-A"). Para la resolución inversa, el IETF reservó el dominio ip6.arpa, donde el espacio de nombres se divide jerárquicamente por la representación hexadecimal de 1 dígito de las unidades nibble (4 bits) de la dirección IPv6. Este esquema se define en RFC 3596.

Cuando un host de doble pila consulta a un servidor DNS para resolver un nombre de dominio completo (FQDN), el cliente DNS del host envía dos solicitudes de DNS, una consultando registros A y la otra consultando registros AAAA. El sistema operativo host puede configurarse con una preferencia por las reglas de selección de direcciones RFC 6724.

Se utilizó un tipo de registro alternativo en las primeras implementaciones de DNS para IPv6, diseñado para facilitar la renumeración de la red, los registros A6 para la búsqueda directa y una serie de otras innovaciones, como etiquetas de cadena de bits y registros DNAME. Se define en RFC 2874 y sus referencias (con una discusión más detallada de los pros y los contras de ambos esquemas en RFC 3364), pero ha quedado en desuso a estado experimental (RFC 3363).

Mecanismos de transición

No se prevé que IPv6 reemplace a IPv4 instantáneamente. Ambos protocolos seguirán funcionando simultáneamente durante algún tiempo. Por lo tanto, se necesitan mecanismos de transición de IPv6 para permitir que los hosts de IPv6 lleguen a los servicios de IPv4 y permitir que los hosts y redes de IPv6 aislados se comuniquen entre sí a través de la infraestructura de IPv4.

Según Silvia Hagen, una implementación de doble pila de IPv4 e IPv6 en los dispositivos es la forma más fácil de migrar a IPv6. Muchos otros mecanismos de transición utilizan túneles para encapsular el tráfico IPv6 dentro de las redes IPv4 y viceversa. Esta es una solución imperfecta, que reduce la unidad de transmisión máxima (MTU) de un enlace y, por lo tanto, complica el descubrimiento de MTU de ruta y puede aumentar la latencia.

Implementación de IP de doble pila

Las implementaciones de IP de doble pila proporcionan pilas completas de protocolos IPv4 e IPv6 en el sistema operativo de una computadora o dispositivo de red además de la implementación de capa física común, como Ethernet. Esto permite que los hosts de doble pila participen en redes IPv6 e IPv4 simultáneamente. El método se define en RFC 4213.

Un dispositivo con implementación de doble pila en el sistema operativo tiene una dirección IPv4 e IPv6 y puede comunicarse con otros nodos en la LAN o Internet utilizando IPv4 o IPv6. Ambos protocolos IP utilizan el protocolo del Sistema de nombres de dominio (DNS) para resolver nombres de dominio completos (FQDN) y direcciones IP, pero la pila dual requiere que el servidor DNS de resolución pueda resolver ambos tipos de direcciones. Dicho servidor DNS de doble pila mantendría direcciones IPv4 en los registros A y direcciones IPv6 en los registros AAAA. Según el destino que se va a resolver, un servidor de nombres DNS puede devolver una dirección IP IPv4 o IPv6, o ambas. Es necesario configurar un mecanismo de selección de dirección predeterminado, o un protocolo preferido, ya sea en los hosts o en el servidor DNS. El IETF ha publicado Happy Eyeballs para ayudar a las aplicaciones de doble pila, para que puedan conectarse usando tanto IPv4 como IPv6, pero prefieren una conexión IPv6 si está disponible. Sin embargo, la pila dual también debe implementarse en todos los enrutadores entre el host y el servicio para el cual el servidor DNS ha devuelto una dirección IPv6. Los clientes de doble pila solo deben configurarse para preferir IPv6, si la red puede reenviar paquetes IPv6 utilizando las versiones IPv6 de los protocolos de enrutamiento. Cuando se implementan protocolos de redes de doble pila, la capa de aplicación se puede migrar a IPv6. si la red puede reenviar paquetes IPv6 utilizando las versiones IPv6 de los protocolos de enrutamiento. Cuando se implementan protocolos de redes de doble pila, la capa de aplicación se puede migrar a IPv6. si la red puede reenviar paquetes IPv6 utilizando las versiones IPv6 de los protocolos de enrutamiento. Cuando se implementan protocolos de redes de doble pila, la capa de aplicación se puede migrar a IPv6.

Si bien la pila dual es compatible con los principales proveedores de sistemas operativos y dispositivos de red, el hardware y los servidores de red heredados no son compatibles con IPv6.

Clientes de ISP con IPv6 orientado al público

Los proveedores de servicios de Internet (ISP) brindan cada vez más a sus clientes comerciales y privados direcciones de unidifusión global IPv6 orientadas al público. Sin embargo, si aún se usa IPv4 en la red de área local (LAN) y el ISP solo puede proporcionar una dirección IPv6 pública, las direcciones IPv4 LAN se traducen a la dirección IPv6 pública mediante NAT64, una traducción de direcciones de red (NAT) mecanismo. Algunos ISP no pueden proporcionar a sus clientes direcciones IPv4 e IPv6 públicas, por lo que admiten redes de doble pila, porque algunos ISP han agotado su conjunto de direcciones IPv4 enrutables globalmente. Mientras tanto, los clientes de ISP todavía intentan llegar a servidores web IPv4 y otros destinos.

Un porcentaje significativo de ISP en todas las zonas de registro regional de Internet (RIR) han obtenido espacio de direcciones IPv6. Esto incluye a muchos de los principales ISP y operadores de redes móviles del mundo, como Verizon Wireless, StarHub Cable, Chubu Telecommunications, Kabel Deutschland, Swisscom, T-Mobile, Internode y Telefónica.

Si bien algunos ISP aún asignan a los clientes solo direcciones IPv4, muchos ISP asignan a sus clientes solo direcciones IPv6 o IPv4 e IPv6 de doble pila. Los ISP informan que la proporción del tráfico IPv6 de los clientes a través de su red oscila entre el 20 % y el 40 %, pero a mediados de 2017 el tráfico IPv6 solo representaba una fracción del tráfico total en varios grandes puntos de intercambio de Internet (IXP). AMS-IX informó que era del 2 % y SeattleIX informó del 7 %. Una encuesta de 2017 encontró que muchos clientes de DSL atendidos por un ISP de doble pila no solicitaron servidores DNS para resolver nombres de dominio totalmente calificados en direcciones IPv6. La encuesta también encontró que la mayoría del tráfico de los recursos del servidor web preparados para IPv6 aún se solicitaba y atendía a través de IPv4,

Tunelización

La base técnica para la tunelización, o la encapsulación de paquetes IPv6 en paquetes IPv4, se describe en RFC 4213. Cuando la red troncal de Internet era solo IPv4, uno de los protocolos de tunelización que se usaba con frecuencia era 6to4. La tunelización de Teredo también se usó con frecuencia para integrar las LAN IPv6 con la red troncal de Internet IPv4. Teredo se describe en RFC 4380 y permite que las redes de área local IPv6 hagan túneles a través de redes IPv4, al encapsular paquetes IPv6 dentro de UDP. El relé Teredo es un enrutador IPv6 que media entre un servidor Teredo y la red IPv6 nativa. Se esperaba que 6to4 y Teredo se implementaran ampliamente hasta que las redes de ISP cambiaran a IPv6 nativo, pero en 2014 las estadísticas de Google mostraron que el uso de ambos mecanismos se había reducido a casi 0.

Direcciones IPv6 asignadas a IPv4

Las implementaciones híbridas de doble pila de IPv6/IPv4 reconocen una clase especial de direcciones, las direcciones IPv6 asignadas a IPv4. Estas direcciones generalmente se escriben con un prefijo de 96 bits en el formato estándar de IPv6, y los 32 bits restantes se escriben en la notación decimal de puntos habitual de IPv4.

Las direcciones de este grupo constan de un prefijo de ceros de 80 bits, los siguientes 16 bits son unos y los 32 bits restantes menos significativos contienen la dirección IPv4. Por ejemplo, ::ffff:192.0.2.128 representa la dirección IPv4 192.0.2.128. Un formato anterior, llamado "dirección IPv6 compatible con IPv4", era ::192.0.2.128; sin embargo, este método está en desuso.

Debido a las importantes diferencias internas entre las pilas de protocolos IPv4 e IPv6, algunas de las funciones de nivel inferior disponibles para los programadores en la pila IPv6 no funcionan de la misma manera cuando se usan con direcciones asignadas a IPv4. Algunas pilas de IPv6 comunes no implementan la función de dirección mapeada de IPv4, ya sea porque las pilas de IPv6 e IPv4 son implementaciones separadas (por ejemplo, Microsoft Windows 2000, XP y Server 2003) o por cuestiones de seguridad (OpenBSD). En estos sistemas operativos, un programa debe abrir un socket separado para cada protocolo IP que utilice. En algunos sistemas, por ejemplo, el kernel de Linux, NetBSD y FreeBSD, esta característica está controlada por la opción de socket IPV6_V6ONLY.

El prefijo de dirección 64:ff9b::/96 es una clase de direcciones IPv6 integradas en IPv4 para usar en métodos de transición NAT64. Por ejemplo, 64:ff9b::192.0.2.128 representa la dirección IPv4 192.0.2.128.

Seguridad

Una serie de implicaciones de seguridad pueden surgir del uso de IPv6. Algunos de ellos pueden estar relacionados con los propios protocolos IPv6, mientras que otros pueden estar relacionados con fallas de implementación.

Redes en la sombra

La adición de nodos que tienen habilitado IPv6 de forma predeterminada por parte del fabricante del software, puede dar lugar a la creación inadvertida de redes en la sombra, lo que hace que el tráfico de IPv6 fluya hacia redes que solo tienen implementada la administración de seguridad de IPv4. Esto también puede ocurrir con las actualizaciones del sistema operativo, cuando el sistema operativo más nuevo habilita IPv6 de forma predeterminada, mientras que el anterior no. Si no se actualiza la infraestructura de seguridad para adaptarse a IPv6, el tráfico de IPv6 puede pasar por alto. Se han producido redes en la sombra en redes comerciales en las que las empresas están reemplazando los sistemas Windows XP que no tienen una pila IPv6 habilitada de manera predeterminada, con sistemas Windows 7 que sí la tienen.Por lo tanto, algunos implementadores de pilas de IPv6 recomendaron deshabilitar las direcciones mapeadas de IPv4 y, en su lugar, usar una red de doble pila donde sea necesario admitir tanto IPv4 como IPv6.

Fragmentación de paquetes IPv6

La investigación ha demostrado que el uso de la fragmentación se puede aprovechar para evadir los controles de seguridad de la red, de forma similar a IPv4. Como resultado, RFC 7112 requiere que el primer fragmento de un paquete IPv6 contenga la cadena de encabezado IPv6 completa, por lo que algunos casos de fragmentación muy patológicos están prohibidos. Además, como resultado de la investigación sobre la evasión de RA-Guard en RFC 7113, RFC 6980 desaprobó el uso de fragmentación con Neighbor Discovery y desalentó el uso de fragmentación con Secure Neighbor Discovery (SEND).

Estandarización a través de RFCs

Propuestas de grupos de trabajo

Debido al crecimiento global anticipado de Internet, el Grupo de trabajo de ingeniería de Internet (IETF) a principios de la década de 1990 inició un esfuerzo para desarrollar un protocolo IP de próxima generación. A principios de 1992, aparecieron varias propuestas para un sistema de direccionamiento de Internet ampliado y, a fines de 1992, el IETF anunció una convocatoria de libros blancos. En septiembre de 1993, el IETF creó un área temporal ad hoc de IP de próxima generación (IPng) para tratar específicamente estos problemas. La nueva área estaba dirigida por Allison Mankin y Scott Bradner, y tenía una dirección con 15 ingenieros de diversos orígenes para el establecimiento de direcciones y la revisión preliminar de documentos:Los miembros del grupo de trabajo fueron J. Allard (Microsoft), Steve Bellovin (AT&T), Jim Bound (Digital Equipment Corporation), Ross Callon (Wellfleet), Brian Carpenter (CERN), Dave Clark (MIT), John Curran (NEARNET), Steve Deering (Xerox), Dino Farinacci (Cisco), Paul Francis (NTT), Eric Fleischmann (Boeing), Mark Knopper (Ameritech), Greg Minshall (Novell), Rob Ullmann (Lotus) y Lixia Zhang (Xerox).

El Grupo de Trabajo de Ingeniería de Internet adoptó el modelo IPng el 25 de julio de 1994, con la formación de varios grupos de trabajo IPng. En 1996, se publicó una serie de RFC que definían el Protocolo de Internet versión 6 (IPv6), comenzando con el RFC 1883. (La versión 5 fue utilizada por el Protocolo de transmisión de Internet experimental).

Estandarización RFC

El primer RFC en estandarizar IPv6 fue el RFC 1883 en 1995, que quedó obsoleto con el RFC 2460 en 1998. En julio de 2017, este RFC fue reemplazado por el RFC 8200, que elevó IPv6 a "Internet Standard" (el nivel de madurez más alto para los protocolos IETF).

Despliegue

La introducción en 1993 del Classless Inter-Domain Routing (CIDR) en el enrutamiento y la asignación de direcciones IP para Internet, y el amplio uso de la traducción de direcciones de red (NAT), retrasó el agotamiento de direcciones IPv4 para permitir el despliegue de IPv6, que comenzó a mediados de -2000s.

Las universidades estuvieron entre los primeros en adoptar IPv6. Virginia Tech implementó IPv6 en una ubicación de prueba en 2004 y luego amplió la implementación de IPv6 en toda la red del campus. Para 2016, el 82% del tráfico en su red usaba IPv6. El Imperial College London comenzó la implementación experimental de IPv6 en 2003 y, para 2016, el tráfico de IPv6 en sus redes promedió entre el 20 % y el 40 %. Una parte significativa de este tráfico IPv6 se generó a través de su colaboración de física de alta energía con el CERN, que se basa completamente en IPv6.

El Sistema de Nombres de Dominio (DNS) es compatible con IPv6 desde 2008. En el mismo año, IPv6 se utilizó por primera vez en un importante evento mundial durante los Juegos Olímpicos de Verano de Beijing 2008.

Para 2011, todos los principales sistemas operativos en uso en computadoras personales y sistemas de servidor tenían implementaciones de IPv6 con calidad de producción. Los sistemas de telefonía celular presentaron un gran campo de implementación para los dispositivos de Protocolo de Internet a medida que el servicio de telefonía móvil hizo la transición de las tecnologías 3G a 4G, en las que la voz se aprovisiona como un servicio de voz sobre IP (VoIP) que aprovecharía las mejoras de IPv6. En 2009, el operador celular estadounidense Verizon publicó las especificaciones técnicas de los dispositivos para operar en sus redes de "próxima generación". La especificación exigía la operación de IPv6 de acuerdo con las especificaciones de la versión 8 de 3GPP (marzo de 2009) y desaprobaba IPv4 como una capacidad opcional.

Se continuó con el despliegue de IPv6 en el backbone de Internet. En 2018, solo el 25,3 % de los aproximadamente 54 000 sistemas autónomos anunciaron prefijos IPv4 e IPv6 en la base de datos de enrutamiento del Protocolo de puerta de enlace fronteriza (BGP) global. Otras 243 redes anunciaron solo un prefijo IPv6. Las redes troncales de tránsito de Internet que ofrecían compatibilidad con IPv6 existían en todos los países del mundo, excepto en partes de África, Oriente Medio y China. A mediados de 2018, algunos de los principales ISP de banda ancha europeos habían implementado IPv6 para la mayoría de sus clientes. Sky UK proporcionó IPv6 a más del 86 % de sus clientes, Deutsche Telekom tuvo un despliegue de IPv6 del 56 %, XS4ALL en los Países Bajos tuvo un despliegue del 73 % y en Bélgica, los ISP de banda ancha VOO y Telenet tuvieron un despliegue de IPv6 del 73 % y el 63 %, respectivamente.En los Estados Unidos, el ISP de banda ancha Comcast tenía un despliegue de IPv6 de alrededor del 66%. En 2018, Comcast informó un estimado de 36,1 millones de usuarios de IPv6, mientras que AT&T informó de 22,3 millones de usuarios de IPv6.