Dirección IPv6
Etiqueta para identificar una interfaz de red de una computadora u otro nodo de red
Descomposición de una dirección IPv6 en su forma binaria

Una dirección de protocolo de Internet versión 6 ( dirección IPv6 ) es una etiqueta numérica que se utiliza para identificar y localizar una interfaz de red de un ordenador o un nodo de red que participa en una red informática que utiliza IPv6 . Las direcciones IP se incluyen en el encabezado del paquete para indicar el origen y el destino de cada paquete. La dirección IP del destino se utiliza para tomar decisiones sobre el enrutamiento de los paquetes IP a otras redes.

IPv6 es el sucesor de la primera infraestructura de direccionamiento de Internet , el Protocolo de Internet versión 4 (IPv4). A diferencia de IPv4, que definía una dirección IP como un valor de 32 bits, las direcciones IPv6 tienen un tamaño de 128 bits. Por lo tanto, en comparación, IPv6 tiene un espacio de direcciones enormemente ampliado .

Métodos de direccionamiento

Las direcciones IPv6 se clasifican según las principales metodologías de direccionamiento y enrutamiento comunes en redes: direccionamiento unicast, direccionamiento anycast y direccionamiento multicast. [1]

Una dirección unicast identifica una única interfaz de red. El protocolo de Internet envía los paquetes enviados a una dirección unicast a esa interfaz específica.

Una dirección anycast se asigna a un grupo de interfaces, que normalmente pertenecen a nodos diferentes. Un paquete enviado a una dirección anycast se entrega sólo a una de las interfaces miembro, normalmente el host más cercano, según la definición de distancia del protocolo de enrutamiento. Las direcciones anycast no se pueden identificar fácilmente, tienen el mismo formato que las direcciones unicast y se diferencian sólo por su presencia en la red en varios puntos. Casi cualquier dirección unicast se puede utilizar como dirección anycast.

Una dirección de multidifusión también es utilizada por varios hosts que adquieren el destino de la dirección de multidifusión al participar en el protocolo de distribución de multidifusión entre los enrutadores de la red. Un paquete que se envía a una dirección de multidifusión se entrega a todas las interfaces que se han unido al grupo de multidifusión correspondiente. IPv6 no implementa el direccionamiento de difusión . La función tradicional de difusión se subsume mediante el direccionamiento de multidifusión al grupo de multidifusión local de enlace de todos los nodos ff02::1 . Sin embargo, no se recomienda el uso del grupo de todos los nodos, y la mayoría de los protocolos IPv6 utilizan grupos de multidifusión local de enlace específicos del protocolo para evitar perturbar cada interfaz en una red determinada.

Formatos de dirección

Una dirección IPv6 consta de 128 bits. [1] Para cada una de las principales metodologías de direccionamiento y enrutamiento, se reconocen varios formatos de dirección dividiendo los 128 bits de dirección en grupos de bits y utilizando reglas establecidas para asociar los valores de estos grupos de bits con características de direccionamiento especiales.

Formato de dirección unicast y anycast

Las direcciones unicast y anycast generalmente se componen de dos partes lógicas: un prefijo de red de 64 bits utilizado para enrutamiento y un identificador de interfaz de 64 bits utilizado para identificar la interfaz de red de un host.

Formato de dirección de unidifusión general (el tamaño del prefijo de enrutamiento varía)
pedacitos48 (o más)16 (o menos)64
campoprefijo de enrutamientoID de subredidentificador de interfaz

El prefijo de red (el prefijo de enrutamiento combinado con el ID de subred ) está contenido en los 64 bits más significativos de la dirección. El tamaño del prefijo de enrutamiento puede variar; un tamaño de prefijo mayor significa un tamaño de ID de subred menor. Los bits del campo de ID de subred están disponibles para que el administrador de red defina subredes dentro de la red dada. El identificador de interfaz de 64 bits se establece automáticamente de forma aleatoria, se obtiene de un servidor DHCPv6 o se asigna manualmente. (Históricamente, se generaba automáticamente a partir de la dirección MAC de la interfaz utilizando el formato EUI-64 modificado , pero este método ahora no se recomienda por razones de privacidad. [2] )

Las direcciones locales únicas son direcciones análogas a las direcciones de red privada IPv4 .

Formato de dirección local único
pedacitos71401664
campoprefijoyoaleatorioID de subredidentificador de interfaz

El campo de prefijo contiene el valor binario 1111110. El bit L es el de las direcciones asignadas localmente; el rango de direcciones con L establecido en cero no está definido actualmente. El campo aleatorio se elige aleatoriamente una vez, al inicio del prefijo de enrutamiento / 48 .

Una dirección de enlace local también se basa en el identificador de interfaz, pero utiliza un formato diferente para el prefijo de red.

Formato de dirección de enlace local
pedacitos105464
campoprefijocerosidentificador de interfaz

El campo de prefijo contiene el valor binario 1111111010. Los 54 ceros que siguen hacen que el prefijo de red total sea el mismo para todas las direcciones de enlace local ( prefijo de dirección de enlace local fe80:: / 64 ), lo que las hace no enrutables.

Formato de dirección de multidifusión

Las direcciones de multidifusión se forman de acuerdo con varias reglas de formato específicas, según la aplicación.

Formato general de dirección de multidifusión
pedacitos844112
campoprefijobanderaCarolina del SurIdentificación del grupo

Para todas las direcciones de multidifusión, el campo de prefijo contiene el valor binario 11111111.

Actualmente, tres de los cuatro bits de bandera en el campo flg están definidos; [1] el bit de bandera más significativo está reservado para uso futuro.

Indicadores de dirección de multidifusión [3]
pocobanderaSignificado cuando 0Significado cuando 1
8reservadoreservadoreservado
9R (Encuentro) [4]Punto de encuentro no incrustadoPunto de encuentro incrustado
10P (Prefijo) [5]Sin información de prefijoDirección basada en prefijo de red
11T (Transitorio) [1]Dirección de multidifusión conocidaDirección de multidifusión asignada dinámicamente

El campo de alcance de cuatro bits ( sc ) se utiliza para indicar dónde la dirección es válida y única.

Además, el campo de alcance se utiliza para identificar direcciones de multidifusión especiales, como el nodo solicitado .

Formato de dirección de multidifusión de nodo solicitado
pedacitos84479924
campoprefijobanderaCarolina del Surcerosunosdirección de unidifusión

El campo sc(ope) contiene el valor binario 0010 (enlace local). Las direcciones de multidifusión de nodo solicitado se calculan como una función de las direcciones de unidifusión o anycast de un nodo. Una dirección de multidifusión de nodo solicitado se crea copiando los últimos 24 bits de una dirección de unidifusión o anycast a los últimos 24 bits de la dirección de multidifusión.

Formato de dirección de multidifusión basado en prefijo de unidifusión [4] [5]
pedacitos8444486432
campoprefijobanderaCarolina del SurresRiidoPlenoprefijo de redIdentificación del grupo

Las direcciones de multidifusión con ámbito de enlace utilizan un formato comparable. [6]


Representación

Una dirección IPv6 se representa como ocho grupos de cuatro dígitos hexadecimales , cada grupo representa 16 bits [a] Los grupos están separados por dos puntos (:). Un ejemplo de una dirección IPv6 es:

2001:0db8:85a3:0000:0000:8a2e:0370:7334

Los estándares proporcionan flexibilidad en la representación de direcciones IPv6. La representación completa de ocho grupos de cuatro dígitos se puede simplificar mediante varias técnicas, eliminando partes de la representación. En general, las representaciones se acortan tanto como sea posible. Sin embargo, esta práctica complica varias operaciones comunes, a saber, la búsqueda de una dirección específica o un patrón de direcciones en documentos de texto o flujos de datos, y la comparación de direcciones para determinar la equivalencia. Para mitigar estas complicaciones, el IETF ha definido un formato canónico para representar direcciones IPv6 en texto: [9]

  • Los dígitos hexadecimales siempre se comparan sin distinguir entre mayúsculas y minúsculas, pero las recomendaciones de la IETF sugieren el uso de solo letras minúsculas. Por ejemplo, se prefiere 2001:db8::1 en lugar de 2001:DB8::1 ;
  • Se suprimen los ceros iniciales en cada campo de 16 bits, pero cada grupo debe conservar al menos un dígito. Por ejemplo, 2001:0db8::0001:0000 se representa como 2001:db8::1:0 ;
  • La secuencia más larga de campos consecutivos de todos ceros se reemplaza por dos puntos ( :: ). Si la dirección contiene múltiples ejecuciones de campos de todos ceros del mismo tamaño, para evitar ambigüedades, se comprime el que está más a la izquierda. Por ejemplo, 2001:db8:0:0:1:0:0:1 se representa como 2001:db8::1:0:0:1 en lugar de como 2001:db8:0:0:1::1 . :: no se utiliza para representar un solo campo de todos ceros. Por ejemplo, 2001:db8:0:0:0:0:2:1 se acorta a 2001:db8::2:1 , pero 2001:db8:0000:1:1:1:1:1 se representa como 2001:db8:0:1:1:1:1:1 .

Estos métodos pueden generar representaciones muy breves de direcciones IPv6. Por ejemplo, la dirección local (bucle), 0:0:0:0:0:0:0:1 , y la dirección IPv6 no especificada, 0:0:0:0:0:0:0:0:0 , se reducen a ::1 y :: , respectivamente.

Durante la transición de Internet de IPv4 a IPv6, es habitual operar en un entorno de direccionamiento mixto. Para estos casos de uso, se ha introducido una notación especial, que expresa las direcciones IPv6 mapeadas a IPv4 y compatibles con IPv4 escribiendo los 32 bits menos significativos de una dirección en la notación decimal con punto de IPv4 habitual , mientras que los 96 bits más significativos se escriben en formato IPv6. Por ejemplo, la dirección IPv6 mapeada a IPv4 ::ffff:c000:0280 se escribe como ::ffff:192.0.2.128 , expresando así claramente la dirección IPv4 original que se mapeó a IPv6.

Redes

Una red IPv6 utiliza un bloque de direcciones que es un grupo contiguo de direcciones IPv6 de un tamaño que es una potencia de dos . El conjunto de bits inicial de las direcciones es idéntico para todos los hosts de una red determinada y se denomina dirección de red o prefijo de enrutamiento .

Los rangos de direcciones de red se escriben en notación CIDR . Una red se denota por la primera dirección del bloque (que termina en ceros), una barra (/) y un valor decimal igual al tamaño en bits del prefijo. Por ejemplo, la red escrita como 2001:db8:1234:: / 48 comienza en la dirección 2001:db8:1234:0000:0000:0000:0000:0000 y termina en 2001:db8:1234:ffff:ffff:ffff:ffff:ffff .

El prefijo de enrutamiento de una dirección de interfaz se puede indicar directamente con la dirección utilizando la notación CIDR. Por ejemplo, la configuración de una interfaz con la dirección 2001:db8:a::123 conectada a la subred 2001:db8:a:: / 64 se escribe como 2001:db8:a::123 / 64 .

Tamaños de bloques de direcciones

El tamaño de un bloque de direcciones se especifica escribiendo una barra (/) seguida de un número en decimal cuyo valor es la longitud del prefijo de red en bits. Por ejemplo, un bloque de direcciones con 48 bits en el prefijo se indica mediante / 48 . Un bloque de este tipo contiene 2 128 − 48 = 2 80 direcciones. Cuanto menor sea la longitud del prefijo de red, mayor será el bloque: un bloque / 21 es 8 veces más grande que un bloque / 24 .

Direcciones IPv6 literales en identificadores de recursos de red

Los caracteres de dos puntos (:) en las direcciones IPv6 pueden entrar en conflicto con la sintaxis establecida de los identificadores de recursos, como las URI y las URL . Los dos puntos se utilizan convencionalmente para terminar la ruta del host antes de un número de puerto . [10] Para aliviar este conflicto, las direcciones IPv6 literales se encierran entre corchetes en dichos identificadores de recursos, por ejemplo:

http://[2001:db8:85a3:8d3:1319:8a2e:370:7348]/

Cuando la URL también contiene un número de puerto, la notación es:

https://[2001:db8:85a3:8d3:1319:8a2e:370:7348]:443/

donde el 443 final es el número de puerto del ejemplo.

Direcciones IPv6 literales con ámbito (con índice de zona)

En el caso de direcciones con un alcance distinto del global (como se describe en § Ámbitos de direcciones), y en particular para direcciones locales de enlace, la elección de la interfaz de red para enviar un paquete puede depender de la zona a la que pertenece la dirección. La misma dirección puede ser válida en diferentes zonas y estar en uso por un host diferente en cada una de esas zonas. Incluso si una única dirección no está en uso en diferentes zonas, los prefijos de dirección para las direcciones en esas zonas pueden seguir siendo idénticos, lo que hace que el sistema operativo no pueda seleccionar una interfaz de salida en función de la información de la tabla de enrutamiento (que se basa en prefijos).

Para resolver la ambigüedad en las direcciones textuales, unaEl índice de zona debe ir adjunto a la dirección. El índice de zona está separado de la dirección por unsigno de porcentaje(%).[11]Aunque los índices de zona numéricos deben ser universalmente compatibles, el índice de zona también puede ser una cadena dependiente de la implementación. La dirección local del enlace

fe80::1ff:fe23:4567:890a

Podría expresarse por

fe80::1ff:fe23:4567:890a%eth2 [b]

o

fe80::1ff:fe23:4567:890a%3

El primero (usando un nombre de interfaz ) es habitual en la mayoría de los sistemas operativos tipo Unix (por ejemplo, BSD , Linux , macOS ). [12] El último (usando un número de interfaz) es la única sintaxis en Microsoft Windows , pero como el soporte para esta sintaxis es obligatorio por estándar, también está disponible en otros sistemas operativos. [c]

Los sistemas operativos basados ​​en BSD (incluido macOS) también admiten una sintaxis alternativa no estándar, en la que se codifica un índice de zona numérica en la segunda palabra de 16 bits de la dirección. Por ejemplo:

fe80:3::1ff:fe23:4567:890a

En todos los sistemas operativos mencionados anteriormente, el índice de zona para direcciones locales de enlace en realidad se refiere a una interfaz, no a una zona. Como varias interfaces pueden pertenecer a la misma zona (por ejemplo, cuando están conectadas a la misma red), en la práctica, dos direcciones con diferentes identificadores de zona pueden ser equivalentes y referirse al mismo host en el mismo enlace. [d]

Cuando se utiliza en identificadores uniformes de recursos (URI), el uso del signo de porcentaje provoca un conflicto de sintaxis, por lo tanto, debe escaparse mediante codificación de porcentaje , [13] por ejemplo:

http://[fe80::1ff:fe23:4567:890a %25 eth0]/

Direcciones IPv6 literales en nombres de ruta UNC

En los sistemas operativos Microsoft Windows , las direcciones IPv4 son identificadores de ubicación válidos en los nombres de ruta de la Convención de nomenclatura uniforme (UNC). Sin embargo, los dos puntos son un carácter ilegal en un nombre de ruta UNC. Por lo tanto, el uso de direcciones IPv6 también es ilegal en los nombres UNC. Por este motivo, Microsoft implementó un algoritmo de transcripción para representar una dirección IPv6 en forma de un nombre de dominio que se puede utilizar en rutas UNC. Para este propósito, Microsoft registró y reservó el dominio de segundo nivel ipv6-literal.net en Internet (aunque abandonó el dominio en enero de 2014 [14] ). Las direcciones IPv6 se transcriben como un nombre de host o un nombre de subdominio dentro de este espacio de nombres , de la siguiente manera:

2001:db8:85a3:8d3:1319:8a2e:370:7348

está escrito como

2001-db8-85a3-8d3-1319-8a2e-370-7348.ipv6-literal.net

Esta notación se resuelve automáticamente de forma local mediante el software de Microsoft, sin ninguna consulta a los servidores de nombres DNS.

Si la dirección IPv6 contiene un índice de zona, se agrega a la parte de la dirección después de un carácter "s":

fe80::1ff:fe23:4567:890a%3

está escrito como

fe80--1ff-fe23-4567-890a s3 .ipv6-literal.net

Ámbitos de dirección

Cada dirección IPv6, excepto la dirección no especificada ( : :), tiene un alcance , [11] que especifica en qué parte de la red es válida.

Unidifusión

Para las direcciones de unidifusión , se definen dos ámbitos: enlace local y global.

Las direcciones locales de enlace y la dirección de bucle invertido tienen un alcance local de enlace , lo que significa que solo se pueden usar en una única red conectada directamente. Todas las demás direcciones (incluidas las direcciones locales únicas ) tienen un alcance global (o universal ), lo que significa que son potencialmente enrutables globalmente y se pueden usar para conectarse a direcciones con alcance global en cualquier lugar o a direcciones con alcance local de enlace en la red conectada directamente.

Las direcciones locales únicas tienen un alcance global, pero no se administran globalmente. Como resultado, solo otros hosts en el mismo dominio administrativo (por ejemplo, una organización) o dentro de un dominio administrativo cooperativo pueden acceder a dichas direcciones, si se enrutan correctamente. Como su alcance es global, estas direcciones son válidas como dirección de origen cuando se comunica con cualquier otra dirección de alcance global, aunque puede resultar imposible enrutar paquetes desde el destino de regreso al origen.

Anycast

Las direcciones anycast son sintácticamente idénticas a las direcciones unicast y no se pueden distinguir de ellas. La única diferencia es administrativa. Por lo tanto, los alcances de las direcciones anycast son los mismos que los de las direcciones unicast.

Multidifusión

En el caso de direcciones de multidifusión , los cuatro bits menos significativos del segundo octeto de dirección ( ff0 s : :) identifican el ámbito de la dirección , es decir, el dominio en el que se debe propagar el paquete de multidifusión. Los ámbitos predefinidos y reservados son:

Valores de alcance [1] : 2,7 
ValorNombre del alcanceNotas
0x0reservado
0x1interfaz localEl ámbito de interfaz local abarca solo una única interfaz en un nodo y es útil únicamente para la transmisión de multidifusión en bucle.
0x2enlace localEl alcance del enlace local abarca la misma región topológica que el alcance de unidifusión correspondiente.
0x3reino localEl alcance local del reino se define como mayor que el alcance local del enlace, se determina automáticamente por la topología de la red y no debe ser mayor que los siguientes alcances. [15]
0x4administrador localEl ámbito local de administración es el ámbito más pequeño que debe configurarse administrativamente, es decir, no se deriva automáticamente de la conectividad física u otra configuración no relacionada con la multidifusión.
0x5sitio localEl alcance local del sitio está destinado a abarcar un solo sitio perteneciente a una organización.
0x8organización-localEl alcance local de la organización está destinado a abarcar todos los sitios que pertenecen a una sola organización.
0xeglobalEl alcance global abarca todos los nodos accesibles en Internet: no tiene límites.
0xfreservado

Todos los demás ámbitos no están asignados y están disponibles para que los administradores definan regiones adicionales.

Espacio de dirección

Asignación general

La gestión del proceso de asignación de direcciones IPv6 está delegada a la Autoridad de Números Asignados de Internet (IANA) [16] por el Consejo de Arquitectura de Internet y el Grupo Directivo de Ingeniería de Internet . Su función principal es la asignación de grandes bloques de direcciones a los registros regionales de Internet (RIR), que tienen la tarea delegada de asignación a los proveedores de servicios de red y otros registros locales. La IANA mantiene la lista oficial de asignaciones del espacio de direcciones IPv6 desde diciembre de 1995. [17]

Para permitir una agregación de rutas eficiente, reduciendo así el tamaño de las tablas de enrutamiento de Internet, actualmente sólo una octava parte del espacio total de direcciones ( 2000:: / 3 ) está asignado para su uso en Internet . El resto del espacio de direcciones IPv6 está reservado para uso futuro o para propósitos especiales. El espacio de direcciones se asigna a los RIR en bloques de / 23 hasta / 12 . [18]

Los RIR asignan bloques más pequeños a los registros de Internet locales que los distribuyen a los usuarios . Estos suelen tener tamaños que van desde / 19 a / 32. [19] [20] [21] Los registros de asignación de unidifusión global se pueden encontrar en los distintos RIR u otros sitios web. [22]

Las direcciones se distribuyen generalmente en bloques de tamaño de / 48 a / 56 a los usuarios finales. [23] Las direcciones IPv6 se asignan a las organizaciones en bloques mucho más grandes en comparación con las asignaciones de direcciones IPv4: la asignación recomendada es un bloque de / 48 que contiene 2 80 direcciones, siendo 2 48 o aproximadamente2,8 × 10 14 veces más grande que todo el espacio de direcciones IPv4 de 2 32 direcciones y aproximadamente7,2 × 10 16 veces más grande que los bloques / 8 de direcciones IPv4, que son las asignaciones más grandes de direcciones IPv4. Sin embargo, el conjunto total es suficiente para el futuro previsible, porque hay 2 128 (exactamente 340 282 366 920 938 463 463 374 607 431 768 211 456) o aproximadamente3,4 × 10 38 (340 undecillones ) direcciones IPv6 únicas.

Cada RIR puede dividir cada uno de sus múltiples bloques / 23 en 512 / 32 bloques, normalmente uno para cada ISP; un ISP puede dividir su bloque / 32 en 65 536 / 48 bloques, normalmente uno para cada cliente; [24] los clientes pueden crear 65 536 / 64 redes a partir de su bloque / 48 asignado, cada una con 2 64 (18.446.744.073.709.551.616) direcciones. En contraste, todo el espacio de direcciones IPv4 tiene solo 2 32 (exactamente 4.294.967.296 o aproximadamente4,3 × 10 9 ) direcciones.

Por diseño, solo se utilizará activamente una pequeña fracción del espacio de direcciones. El gran espacio de direcciones garantiza que las direcciones estén casi siempre disponibles, lo que hace innecesario el uso de la traducción de direcciones de red (NAT) para fines de conservación de direcciones. La NAT se ha utilizado cada vez más en redes IPv4 para ayudar a aliviar el agotamiento de direcciones IPv4 .

Asignación especial

El espacio de direcciones independiente del proveedor es asignado directamente al usuario final por los RIR a partir del rango especial 2001:678:: / 29 y permite a los clientes realizar cambios de proveedor sin tener que renumerar sus redes.

A los puntos de intercambio de Internet (IXP) se les asignan direcciones especiales de los rangos 2001:7f8:: / 32 , 2001:504:: / 30 y 2001:7fa:: / 32 [25] para comunicarse con sus ISP conectados .

A los servidores de nombres raíz se les han asignado direcciones del rango 2001:7f8:: / 29 . [26]

Direcciones anycast reservadas

La dirección más baja dentro de cada prefijo de subred (el identificador de interfaz establecido en todos los ceros) se reserva como la dirección anycast del enrutador de subred . [1] Las aplicaciones pueden usar esta dirección cuando se comunican con cualquiera de los enrutadores disponibles, ya que los paquetes enviados a esta dirección se entregan a un solo enrutador.

Las 128 direcciones más altas dentro de cada prefijo de subred / 64 están reservadas para usarse como direcciones anycast. [27] Estas direcciones generalmente tienen los primeros 57 bits del identificador de interfaz establecidos en 1, seguido del ID anycast de 7 bits. Los prefijos para la red pueden tener cualquier longitud para fines de enrutamiento, pero se requiere que las subredes tengan una longitud de 64 bits. La dirección con el valor 0x7e en los 7 bits menos significativos se define como una dirección anycast de agentes locales IPv6 móviles . La dirección con el valor 0x7f (todos los bits 1) está reservada y no se puede usar. No se han realizado más asignaciones de este rango, por lo que todos los valores restantes, 0x00 a 0x7d, también están reservados.

Direcciones especiales

Hay una serie de direcciones con un significado especial en IPv6. [28] La IANA mantiene un registro de estas direcciones de propósito especial. [29] Representan menos del 2% de todo el espacio de direcciones:

Bloques de direcciones especiales
Bloque de direcciones (CIDR)Primera direcciónÚltima direcciónNúmero de direccionesUsoObjetivo
::/128::::1SoftwareDirección no especificada
::1/128::1::11AnfitriónDirección de bucle invertido : una interfaz virtual que envía todo el tráfico de regreso a sí misma, el host local.
::ffff:0:0/96::ffff:0.0.0.0 ::ffff:0:0::ffff:255.255.255.255 ::ffff:ffff:ffff2 32SoftwareDirecciones asignadas a IPv4
::ffff:0:0:0/96::ffff:0:0.0.0.0 ::ffff:0:0:0::ffff:0:255.255.255.255 ::ffff:0:ffff:ffff2 32SoftwareDirecciones traducidas a IPv4
64:ff9b::/9664:ff9b::0.0.0.0 64:ff9b::0:064:ff9b::255.255.255.255 64:ff9b::ffff:ffff2 32La Internet globalTraducción IPv4/IPv6 [30]
64:ff9b:1::/4864:ff9b:1::64:ff9b:1:ffff:ffff:ffff:ffff:ffff2 80 , con 2 48 para cada IPv4Internet privadoTraducción IPv4/IPv6 [31]
100::/64100::100::ffff:ffff:ffff:ffff2 64EnrutamientoDescartar prefijo [32]
2001::/322001::2001:0:ffff:ffff:ffff:ffff:ffff:ffff2 96La Internet globalTúnel de Teredo [33]
2001:20::/282001:20::2001:2f:ffff:ffff:ffff:ffff:ffff:ffff2 100SoftwareORQUÍDEA v2 [34]
2001:db8::/322001:db8::2001:db8:ffff:ffff:ffff:ffff:ffff:ffff2 96DocumentaciónDirecciones utilizadas en la documentación y código fuente de ejemplo [35]
2002::/162002::2002:ffff:ffff:ffff:ffff:ffff:ffff:ffff2 112La Internet globalEl esquema de direccionamiento 6to4 (en desuso) [36]
3fff::/203fff::3fff:fff:ffff:ffff:ffff:ffff:ffff:ffff:ffff2 108DocumentaciónDirecciones utilizadas en la documentación y código fuente de ejemplo [37]
5f00::/165f00::5f00:ffff:ffff:ffff:ffff:ffff:ffff:ffff2 112EnrutamientoEnrutamiento de segmentos IPv6 (SRv6) [38]
fc00::/7fc00::fdff:ffff:ffff:ffff:ffff:ffff:ffff:ffff2 121Internet privadoDirección local única [39]
fe80::/64 desde fe80::/10fe80::fe80::ffff:ffff:ffff:ffff2 64EnlaceDirección de enlace local
ff00::/8ff00::ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff2 120La Internet globalDirección de multidifusión

Direcciones unicast

Dirección no especificada

  • :: / 128  – La dirección con todos los bits cero se denominadirección no especificada(correspondiente a 0.0.0.0 / 32 en IPv4). Esta dirección nunca debe asignarse a una interfaz y solo debe usarse en software antes de que la aplicación haya aprendido la dirección de origen de su host apropiada para una conexión pendiente. Los enrutadores no deben reenviar paquetes con la dirección no especificada.

Las aplicaciones pueden escuchar en una o más interfaces específicas las conexiones entrantes, que se muestran en las listas de conexiones a Internet activas mediante una dirección IP específica (y un número de puerto, separados por dos puntos). Cuando se muestra la dirección no especificada, significa que una aplicación está escuchando las conexiones entrantes en todas las interfaces disponibles.

En la configuración de la tabla de enrutamiento, la dirección no especificada se puede usar para representar la dirección de ruta predeterminada (correspondiente a 0.0.0.0 / 0 en IPv4) para direcciones de destino (unicast, multicast y otras) no especificadas en otra parte de una tabla de enrutamiento.

Direcciones locales

  • ::1 / 128  – Lade bucle invertidoes unade host local. Esta dirección corresponde a 127.0.0.1 / 8 en IPv4.
    Si una aplicación en un host envía paquetes a esta dirección, la pila IPv6 vuelve a enviar estos paquetes a la misma interfaz virtual.
  • fe80:: / 10  – Las direcciones en el prefijo de enlace local solo son válidas y únicas en la subred local. Este rango de direcciones es comparable a las direcciones de configuración automática 169.254.0.0 / 16 de IPv4.
    Dentro de este prefijo, solo se asigna una subred / 64 (hay 54 bits cero), lo que produce un formato efectivo de fe80:: / 64. Los 64 bits menos significativos se elegían anteriormente como la dirección de hardware de la interfaz construida enEUI-64 modificado, pero ahora son valores pseudoaleatorios para la privacidad. Se requiere unadirección de enlace localen cada interfaz habilitada para IPv6 y las aplicaciones pueden confiar en la existencia de una dirección de enlace local incluso cuando no hay enrutamiento IPv6.

Direcciones locales únicas

  • fc00:: / 7 —Las direcciones locales únicas(ULA) están destinadas a la comunicación local[39](comparables alas direcciones privadas IPv4 10.0.0.0 / 8 , 172.16.0.0 / 12 y 192.168.0.0 / 16 ).
    Son enrutables solo dentro de un conjunto de sitios cooperativos. El bloque se divide en dos mitades. La mitad inferior del bloque ( fc00:: / 8 ) estaba destinada a prefijos asignados globalmente, pero aún debe definirse un método de asignación. La mitad superior ( fd00:: / 8 ) se utiliza paraprobabilísticamente únicasen las que el prefijo / 8 se combina con un número pseudoaleatoriode 40 bits generado localmentepara obtener un prefijo privado / 48 . El procedimiento para seleccionar un número de 40 bits da como resultado solo una probabilidad insignificante de que dos sitios que desean fusionarse o comunicarse encuentren colisiones de direcciones, pero puedan usar el mismo prefijo / 48 .[39]

Transición desde IPv4

  • ::ffff:0:0 / 96 — Este prefijo se utiliza paralos mecanismos de transición de IPv6y se designa como unadirección IPv6 asignada a IPv4.
    Con algunas excepciones, este tipo de dirección permite el uso transparente de loscapa de transportesobre IPv4 a través de lainterfaz de programación de aplicaciones. En estade doble pila, las aplicaciones de servidor solo necesitan abrir un únicosocketpara manejar conexiones de clientes que utilizan protocolos IPv6 o IPv4. Los clientes IPv6 se manejan de forma nativa de forma predeterminada, y los clientes IPv4 aparecen como clientes IPv6 en su dirección IPv6 asignada a IPv4. La transmisión se maneja de manera similar; los sockets establecidos se pueden usar para transmitir datagramas IPv4 o IPv6, según el enlace a una dirección IPv6 o una dirección asignada a IPv4.
  • ::ffff:0:0:0 / 96 : prefijo utilizado paradirecciones traducidas a IPv4. Son utilizadas por elprotocoloStateless IP/ICMP Translation (SIIT)[40]
  • 64:ff9b:: / 96 — Elconocido prefijo. Las direcciones con este prefijo se utilizan para la traducción automática de IPv4/IPv6.[30]
  • 64:ff9b:1:: / 48 — Un prefijo para direcciones IPv4/IPv6 traducidas localmente. Las direcciones con este prefijo se pueden usar para múltiples mecanismos de traducción IPv4/IPv6 comoNAT64ySIIT.[31]En comparación con 64:ff9b:: / 96 , estas direcciones contienen su dirección IPv4 traducida en las posiciones 48-63 y 72-87.[30]Esto significa que para cada dirección IPv4 se asigna un prefijo IPv6 / 88 al dispositivo. Esto permite casos de uso similares a 6to4, donde una única dirección IPv4 pública se traduce en un prefijo. De esta manera, solo se requiere un nivel de NAT y los dispositivos no necesitan hacer NAT66 internamente si necesitan direcciones adicionales, por ejemplo, paraP2Pocontenedores docker.
  • 2002:: / 16 — Este prefijo se utilizó para6to4(también se utilizó el prefijo de la red IPv4, 192.88.99.0 / 24 ).
    El esquema de direccionamiento 6to4 está en desuso.[36]

Direcciones especiales

La IANA ha reservado un bloque de direcciones de ID de sub-TLA para asignaciones especiales [28] [41] de 2001:: / 23 (dividido en el rango de 64 prefijos de red 2001:0000:: / 29 a 2001:01f8:: / 29 ). Actualmente, se han asignado tres asignaciones de este bloque:

  • 2001:: / 32 — Se utiliza parala tunelización Teredo, unmecanismo de transición IPv6.
  • 2001:2:: / 48 — Se utiliza paraevaluarIPv6. Corresponde a 198.18.0.0 / 15, utilizado para evaluar IPv4. Asignado al Grupo de trabajo sobre metodología de evaluación comparativa (BMWG).[42]
  • 2001:20:: / 28 — Identificadores hash criptográficos enrutables superpuestos (ORCHIDv2).[34]Se trata de direcciones IPv6 no enrutadas que se utilizan para identificadores hash criptográficos.

Documentación

  • 2001:db8:: / 32 — Este prefijo se utiliza en la documentación[35][e]Las direcciones se deben utilizar en cualquier lugar donde se proporcione una dirección IPv6 de ejemplo o se describan escenarios de redes modelo.
  • 3fff:: / 20 — Este nuevo prefijo se asignó para tener en cuenta el modelado de redes a gran escala de la actualidad, que no se puede cubrir con un soloprefijo / 32. [37]

Desechar

  • 100:: / 64 — Este prefijo se utiliza para descartar tráfico.[32]

Obsoleto y en desuso

Ver § Direcciones obsoletas y en desuso

Direcciones de multidifusión

Las direcciones de multidifusión ff0x:: , donde x es cualquier valor hexadecimal, están reservadas [1] y administradas por la Autoridad de Números Asignados de Internet (IANA). [44]

Direcciones de multidifusión IPv6 comunes
DIRECCIÓNDescripciónÁmbitos disponibles
ff0x::1Todas las direcciones de los nodos identifican el grupo de todos los nodos IPv6Disponible en el ámbito 1 (interfaz local) y 2 (enlace local):
  • ff01::1 → Todos los nodos en la interfaz local
  • ff02::1 → Todos los nodos en el enlace local
ff0x::2Todos los enrutadoresDisponible en el alcance 1 (interfaz local), 2 (enlace local) y 5 (sitio local):
  • ff01::2 → Todos los enrutadores en la interfaz local
  • ff02::2 → Todos los enrutadores en el enlace local
  • ff05::2 → Todos los enrutadores en el sitio local
ff02::5OSPFIGP2 (enlace local)
ff02::6Enrutadores designados por OSPFIGP2 (enlace local)
ff02::9Enrutadores RIP2 (enlace local)
ff02::aEnrutadores EIGRP2 (enlace local)
ff02::cDescubrimiento dinámico de servicios web2 (enlace local)
ff02::dTodos los enrutadores PIM2 (enlace local)
ff02::1aTodos los enrutadores RPL2 (enlace local)
ff0x::fbmDNSv6Disponible en todos los ámbitos
ff0x::101Todos los servidores NTPDisponible en todos los ámbitos
ff02::1:1Nombre del enlace2 (enlace local)
ff02::1:2Todos los servidores DHCPv6 y agentes de retransmisión [45]2 (enlace local)
ff02::1:3Resolución de nombres de multidifusión de enlace local2 (enlace local)
ff05::1:3Un agente de retransmisión puede utilizar esta dirección para llegar a todos los servidores DHCPv6 del sitio. [45]5 (sitio local)
ff02::1:ff00:0/104Dirección de multidifusión de nodo solicitado (ver a continuación)2 (enlace local)
ff02::2:ff00:0/104Consultas de información de nodos2 (enlace local)

Dirección de multidifusión de nodo solicitado

Los 24 bits menos significativos del ID del grupo de direcciones de multidifusión del nodo solicitado se completan con los 24 bits menos significativos de la dirección de unidifusión o anycast de la interfaz. Estas direcciones permiten la resolución de direcciones de la capa de enlace a través del Protocolo de descubrimiento de vecinos (NDP) en el enlace sin perturbar a todos los nodos de la red local. Se requiere que un host se una a un grupo de multidifusión de nodos solicitados para cada una de sus direcciones de unidifusión o anycast configuradas.

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

Al iniciar el sistema, un nodo crea automáticamente una dirección local de enlace en cada interfaz habilitada para IPv6, incluso si las direcciones enrutables globalmente se configuran manualmente o se obtienen a través de protocolos de configuración (ver a continuación). Lo hace de forma independiente y sin ninguna configuración previa mediante la autoconfiguración de direcciones sin estado ( SLAAC ), [46] utilizando un componente del Protocolo de descubrimiento de vecinos . Esta dirección se selecciona con el prefijo fe80:: / 64 .

En IPv4, los protocolos de configuración típicos incluyen DHCP o PPP. Aunque existe DHCPv6 , los hosts IPv6 normalmente utilizan el Protocolo de descubrimiento de vecinos para crear una dirección de unidifusión enrutable globalmente: el host envía solicitudes de solicitud de enrutador y un enrutador IPv6 responde con una asignación de prefijo. [47]

Identificador de interfaz

Los 64 bits inferiores de estas direcciones se rellenan con un identificador de interfaz de 64 bits. Este debe ser un número pseudoaleatorio por razones de privacidad. También por razones de privacidad, el identificador de interfaz es diferente para cada dirección configurada automáticamente de esa interfaz. Esto tiene la desventaja de que se deben unir varios grupos de multidifusión para el descubrimiento de vecinos. Para esto, se utiliza la dirección de multidifusión del nodo solicitado, formada a partir del prefijo de red ff02::1:ff00:0 / 104 y los 24 bits menos significativos de la dirección.

Se puede derivar un identificador de interfaz de 64 bits a partir de la dirección MAC de 48 bits de la interfaz , aunque ahora se recomiendan direcciones de privacidad estables como predeterminadas. [2] Una dirección MAC 00-0C-29-0C-47-D5 se convierte en una EUI-64 de 64 bits insertando FF-FE en el medio: 00-0C-29- FF-FE -0C-47-D5 . [f]

Detección de direcciones duplicadas

La asignación de una dirección IPv6 de unidifusión a una interfaz implica una prueba interna de la unicidad de esa dirección mediante mensajes de solicitud de vecino y de anuncio de vecino ( tipos 135 y 136 de ICMPv6 ). Durante el proceso de establecimiento de la unicidad, una dirección tiene un estado tentativo .

El nodo se une a la dirección de multidifusión del nodo solicitado para obtener la dirección tentativa y envía solicitudes de vecinos, con la dirección tentativa como dirección de destino y la dirección no especificada ( :: / 128 ) como su dirección de origen. El nodo también se une a la dirección de multidifusión de todos los hosts ff02::1 , de modo que pueda recibir anuncios de vecinos .

Si un nodo recibe una solicitud de vecino con su propia dirección provisional como dirección de destino, entonces sabe que su dirección no es única. Lo mismo sucede si el nodo recibe un anuncio de vecino con la dirección provisional como origen del anuncio. Solo después de haber establecido con éxito que una dirección es única, se puede asignar y utilizar por una interfaz.

Cuando se asigna una dirección anycast a una interfaz (por ejemplo, una dirección anycast de un enrutador de subred), debido a la no unicidad inherente de este tipo de dirección, no se realiza la detección de direcciones duplicadas.

Dirección de por vida

Cada dirección IPv6 vinculada a una interfaz tiene una duración definida. Las duraciones son infinitas, a menos que se configuren con un período más corto. Hay dos duraciones que rigen el estado de una dirección: la duración preferida y la duración válida . [48] Las duraciones se pueden configurar en enrutadores que proporcionan los valores utilizados para la configuración automática, o se pueden especificar al configurar manualmente las direcciones en las interfaces.

Cuando se asigna una dirección a una interfaz, esta obtiene el estado "preferred" , que se mantiene durante su vida útil preferida. Una vez que expira dicha vida útil, el estado pasa a ser "obsoleto" y no se deben realizar nuevas conexiones utilizando esta dirección. [g] La dirección deja de ser válida una vez que también expira su vida útil válida; la dirección se elimina de la interfaz y se puede asignar a otro lugar de Internet .

Direcciones temporales

Las direcciones MAC estáticas y únicas a nivel mundial que se utilizan en la configuración automática de direcciones sin estado para crear identificadores de interfaz ofrecen una oportunidad de rastrear el equipo del usuario a través del tiempo y los cambios de prefijo de red IPv6. [49] Para reducir la posibilidad de que una identidad de usuario esté permanentemente vinculada a una parte de la dirección IPv6, un nodo puede crear direcciones temporales con identificadores de interfaz basados ​​en cadenas de bits aleatorios que varían con el tiempo [50] y duraciones de vida relativamente cortas (horas a días), después de lo cual se reemplazan con nuevas direcciones.

Las direcciones temporales se pueden utilizar como direcciones de origen para las conexiones originales, mientras que los hosts externos utilizan una dirección pública consultando el Sistema de nombres de dominio (DNS).

Las interfaces de red configuradas para IPv6 utilizan direcciones temporales de forma predeterminada en OS X Lion y sistemas Apple posteriores [ cita requerida ], así como en Windows Vista , Windows 2008 Server y sistemas Microsoft posteriores. [51]

Direcciones generadas criptográficamente

Como un medio para mejorar la seguridad del Protocolo de Descubrimiento de Vecinos, se introdujeron en 2005 [52] las direcciones generadas criptográficamente (CGA) como parte del protocolo de Descubrimiento de Vecinos Seguros (SEND).

Esta dirección se genera utilizando dos funciones hash que toman varias entradas. La primera utiliza una clave pública y un modificador aleatorio; el último se incrementa repetidamente hasta que se adquiere una cantidad específica de bits cero del hash resultante. [h] La segunda función hash toma el prefijo de red y el valor hash anterior. Los 64 bits menos significativos del segundo resultado hash se agregan al prefijo de red de 64 bits para formar una dirección de 128 bits.

Las funciones hash también se pueden utilizar para verificar si una dirección IPv6 específica cumple con el requisito de ser una CGA válida. De esta manera, se puede establecer una comunicación exclusivamente entre direcciones de confianza.

Direcciones de privacidad estables

El uso del formato EUI-64 modificado tiene serias implicaciones para la seguridad y la privacidad, [53] porque la dirección de hardware subyacente (normalmente la dirección MAC ) queda expuesta más allá de la red local, lo que permite el seguimiento de las actividades del usuario y la correlación de las cuentas de usuario con otra información. También permite estrategias de ataque específicas del proveedor y reduce el tamaño del espacio de direcciones para buscar objetivos de ataque.

Para solucionar estas deficiencias se introdujeron las direcciones de privacidad estables. Son estables dentro de una red específica, pero cambian al pasar a otra para mejorar la privacidad. Se eligen de manera determinista, pero aleatoria, en todo el espacio de direcciones de la red.

La generación de una dirección de privacidad estable se basa en una función hash que utiliza varios parámetros estables. Es específica de la implementación, pero se recomienda incluir al menos el prefijo de red, el nombre de la interfaz de red, un contador de direcciones duplicadas y una clave secreta. El valor hash resultante se utiliza para construir la dirección final: normalmente, los 64 bits menos significativos se concatenan con el prefijo de red de 64 bits, para obtener una dirección de 128 bits. Si el prefijo de red es menor de 64 bits, se utilizan más bits del hash. Si la dirección resultante no entra en conflicto con direcciones existentes o reservadas, se asigna a la interfaz. Los conflictos se resuelven ajustando el contador de direcciones duplicadas. [53]

Selección de dirección predeterminada

Las interfaces de red compatibles con IPv6 suelen tener más de una dirección IPv6, por ejemplo, una dirección local de enlace y una dirección global. También pueden tener direcciones temporales que cambian después de que transcurre un tiempo de vida determinado. IPv6 introduce los conceptos de alcance de dirección y preferencia de selección, lo que permite elegir varias direcciones de origen y destino en la comunicación con otro host.

El algoritmo de selección de preferencias selecciona la dirección más adecuada para utilizar en las comunicaciones con un destino en particular, incluido el uso de direcciones asignadas a IPv4 en implementaciones de doble pila . [54] Utiliza una tabla de preferencias configurable que asocia cada prefijo de enrutamiento con un nivel de precedencia. La tabla predeterminada tiene el siguiente contenido:

PrefijoPrecedenciaEtiquetaUso
::1/128500Servidor local
::/0401Unicast predeterminado
::ffff:0:0/96354Dirección IPv6 asignada a IPv4
2002::/163026 a 4
2001::/3255Túnel de Teredo
fc00::/7313Dirección local única
::/9613Direcciones compatibles con IPv4 (en desuso)
fec0::/10111Dirección local del sitio (obsoleta)
3ffe::/161126bone (devuelto)

La configuración predeterminada da preferencia al uso de IPv6 y selecciona direcciones de destino dentro del alcance más pequeño posible, de modo que se prefiera la comunicación local de enlace a las rutas enrutadas globalmente cuando, por lo demás, sean igualmente adecuadas. La tabla de políticas de prefijo es similar a una tabla de enrutamiento, en la que el valor de precedencia cumple la función de costo de enlace, donde una mayor preferencia se expresa como un valor mayor. Se prefiere que las direcciones de origen tengan el mismo valor de etiqueta que la dirección de destino. Las direcciones se emparejan con prefijos en función de la secuencia de bits más significativa que coincida más larga. Las direcciones de origen candidatas se obtienen del sistema operativo y las direcciones de destino candidatas se pueden consultar a través de DNS.

Para minimizar el tiempo necesario para establecer una conexión cuando hay varias direcciones disponibles para la comunicación, se diseñó el algoritmo Happy Eyeballs . Este algoritmo consulta el DNS en busca de direcciones IPv6 e IPv4 del host de destino, ordena las direcciones candidatas utilizando la tabla de selección de direcciones predeterminada e intenta establecer conexiones en paralelo. La primera conexión establecida cancela los intentos actuales y futuros de conectarse a otras direcciones.

Sistema de nombres de dominio

En el Sistema de nombres de dominio , los nombres de host se asignan a direcciones IPv6 mediante registros de recursos AAAA , los llamados registros quad-A . [55] Para la búsqueda inversa, el IETF reservó el dominio ip6.arpa , donde el espacio de nombres está dividido jerárquicamente por la representación hexadecimal de 1 dígito de las unidades nibble (4 bits) de la dirección IPv6.

Al igual que en IPv4, cada host está representado en el DNS por dos registros DNS: un registro de dirección y un registro de puntero de mapeo inverso. Por ejemplo, un equipo host llamado derrick en la zona example.com tiene la dirección local única fdda:5cc1:23:4::1f . Su registro de dirección quad-A es

derrick.example.com. EN AAAA fdda:5cc1:23:4::1f

y su registro de puntero IPv6 es

f.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.4.0.0.0.3.2.0.0.1.cc5.addfip6.arpa. EN PTR derrick.example.com.

Este registro de puntero puede definirse en varias zonas, dependiendo de la cadena de delegación de autoridad en la zona dfip6.arpa.

El protocolo DNS es independiente de su protocolo de capa de transporte . Las consultas y respuestas pueden transmitirse mediante transportes IPv6 o IPv4 independientemente de la familia de direcciones de los datos solicitados.

Campos de registro AAAA
NOMBRENombre de dominio
TIPOAAAA (28)
CLASEInternet (1)
Tiempo de vida útilTiempo de vida, en segundos
LONGITUD DE RDLongitud del campo RDATA
Datos RDATADirección IPv6 de 128 bits en orden de bytes de red

Notas históricas

Direcciones obsoletas y en desuso

  • El prefijo de sitio local fec0:: / 10 especifica que la dirección es válida únicamente dentro de la red de sitios de una organización. Fue parte de la arquitectura de direccionamiento original en diciembre de 1995, [56] pero su uso quedó en desuso en septiembre de 2004 debido a que la definición del término sitio era ambigua, lo que generó reglas de enrutamiento confusas. Las redes nuevas no deben admitir este tipo especial de dirección. [57] En octubre de 2005, una nueva especificación reemplazó este tipo de dirección con direcciones locales únicas . [39]
  • El bloque de dirección 200:: / 7 se definió como un conjunto de prefijos asignados a NSAP de OSI en agosto de 1996, [58] [59] pero quedó obsoleto en diciembre de 2004. [60]
  • El prefijo de valor cero de 96 bits :: / 96 , conocido originalmente como direcciones compatibles con IPv4 , se mencionó en 1995 [56] pero nunca se describió por completo. Este rango de direcciones se utilizó para representar direcciones IPv4 dentro de una tecnología de transición a IPv6. Una dirección IPv6 de este tipo tiene sus primeros 96 bits (los más significativos) establecidos en cero, mientras que sus últimos 32 bits son la dirección IPv4 que se representa. En febrero de 2006, el Grupo de trabajo de ingeniería de Internet (IETF) desaprobó el uso de direcciones compatibles con IPv4. [1] El único uso restante de este formato de dirección es representar una dirección IPv4 en una tabla o base de datos con miembros de tamaño fijo que también deben poder almacenar una dirección IPv6.
  • El bloque de direcciones 3ffe:: / 16 se asignó para fines de prueba para la red 6bone en diciembre de 1998. [61] Antes de eso, se utilizó el bloque de direcciones 5f00:: / 8 para este propósito. Ambos bloques de direcciones se devolvieron al grupo de direcciones en junio de 2006. [62]
  • Debido a problemas operativos con 6to4, el uso del bloque de direcciones 2002:: / 16 está disminuyendo, ya que el mecanismo 6to4 está obsoleto desde mayo de 2015. [36] Aunque el bloque de direcciones IPv4 192.88.99.0/24 está obsoleto, 2002:: / 16 no lo está.
  • En abril de 2007, el bloque de direcciones 2001:10:: / 28 fue asignado para los Identificadores criptográficos hash enrutables superpuestos (ORCHID). [63] Estaba destinado a un uso experimental. En septiembre de 2014 se especificó una segunda versión de ORCHID, [34] y con la introducción del bloque 2001:20:: / 28, el bloque original fue devuelto a la IANA .

Misceláneas

  • Para la búsqueda DNS inversa , las direcciones IPv6 se registraron originalmente en la zona DNS ip6.int , porque se esperaba que el dominio de nivel superior arpa se retirara. En 2000, el Internet Architecture Board (IAB) revirtió esta intención y decidió en 2001 que arpa debía conservar su función original. Los dominios en ip6.int se trasladaron a ip6.arpa [64] y la zona ip6.int se eliminó oficialmente el 6 de junio de 2006.
  • En marzo de 2011, el IETF refinó las recomendaciones para la asignación de bloques de direcciones a los sitios finales. [23] En lugar de asignar un / 48 , / 64 o / 128 (según las opiniones de IAB e IESG de 2001), [65] los proveedores de servicios de Internet deberían considerar la asignación de bloques más pequeños (por ejemplo, un / 56 ) a los usuarios finales. Las políticas de los registros regionales ARIN , RIPE y APNIC alientan las asignaciones de / 56 cuando sea apropiado. [23]
  • Originalmente, existían dos propuestas para traducir nombres de dominio a direcciones IPv6: una que utilizaba registros AAAA, [66] la otra que utilizaba registros A6. [67] Los registros AAAA, el método que prevaleció, son comparables a los registros A para IPv4, proporcionando una asignación simple del nombre de host a la dirección IPv6. El método que utilizaba registros A6 utilizaba un esquema jerárquico, en el que la asignación de grupos subsiguientes de bits de dirección se especificaba mediante registros A6 adicionales, lo que proporcionaba la posibilidad de renumerar todos los hosts en una red cambiando un solo registro A6. Como se consideró que los beneficios percibidos del formato A6 no superaban los costos percibidos, [68] [69] [70] [71] el método pasó a estado experimental en 2002, [69] y finalmente a estado histórico en 2012. [71]
  • En 2009, se descubrió que muchos solucionadores de DNS en dispositivos NAT y enrutadores de redes domésticas manejaban registros AAAA de manera incorrecta. [72] Algunos de estos simplemente descartaban las solicitudes de DNS para dichos registros, en lugar de devolver correctamente la respuesta de DNS negativa apropiada. Debido a que se descarta la solicitud, el host que la envía tiene que esperar a que se agote el tiempo de espera para activarse. Esto a menudo provoca una mayor latencia al conectarse a hosts IPv6/IPv4 de doble pila, ya que el software del cliente espera a que falle la conexión IPv6 antes de intentar IPv4.

Notas

  1. ^ Una cantidad de 16 bits o dos octetos a veces también se denomina hexteto . [7] [8]
  2. ^ Suponiendo que eth2 es equivalente a la zona número 3. Este suele ser el caso, ya que los números de zona reales comienzan en 1 (siendo 0 la "zona predeterminada")
  3. ^ Aunque Windows admite la API RFC 3493 if_nametoindex()para convertir un nombre en un número de interfaz, no admite la extensión habitual "nombre después de %".
  4. ^ Las direcciones locales del sitio fec0::/10 ahora eliminadas también requieren un índice de zona. [12]
  5. ^ 192.0.2.0 / 24 , 198.51.100.0 / 24 y 203.0.113.0 / 24 se utilizan para la documentación en IPv4. [43]
  6. ^ Cuando se utiliza este EUI-64 para formar una dirección IPv6, se modifica: [1] se invierte el significado del bit Universal/Local (el séptimo bit más significativo del EUI-64, comenzando desde 1), de modo que un 1 ahora significa Universal . Para crear una dirección IPv6 con el prefijo de red 2001:db8:1:2:: / 64 , se obtiene la dirección 2001:db8:1:2:0 2 0c:29ff:fe0c:47d5 (con el bit Universal/Local , el segundo bit menos significativo del cuarteto subrayado, invertido a 1 en este caso porque la dirección MAC es universalmente única).
  7. ^ En la mayoría de los casos, la duración no expira porque los nuevos anuncios de enrutador (RA) actualizan los temporizadores. Pero si no hay más RA, con el tiempo la duración preferida expira y la dirección queda obsoleta .
  8. ^ Comparable con el campo de "prueba de trabajo" en la minería de Bitcoin .

Referencias

  1. ^ abcdefghi R. Hinden; S. Deering (febrero de 2006). Arquitectura de direccionamiento IP versión 6. Grupo de trabajo de redes. doi : 10.17487/RFC4291 . RFC 4291. Borrador de norma. Obsoleto RFC 3513. Actualizado por RFC 5952, 6052, 7136, 7346, 7371 y 8064.
  2. ^ ab F. Gont; A. Cooper; D. Thaler; W. Liu (febrero de 2017). Recomendación sobre identificadores de interfaz IPv6 estables. Grupo de trabajo de ingeniería de Internet (IETF). doi : 10.17487/RFC8064 . RFC 8064. Norma propuesta. Actualizaciones RFC 2464, 2467, 2470, 2491, 2492, 2497, 2590, 3146, 3572, 4291, 4338, 4391, 5072 y 5121.
  3. ^ Silvia Hagen (mayo de 2006). Conceptos básicos de IPv6 (Segunda ed.). O'Reilly. ISBN 978-0-596-10058-2.
  4. ^ ab P. Savola; B. Haberman (noviembre de 2004). Incorporación de la dirección del punto de encuentro (RP) en una dirección de multidifusión IPv6. Grupo de trabajo de redes. doi : 10.17487/RFC3956 . RFC 3956. Norma propuesta. Actualizada por RFC 7371. Actualizaciones de RFC 3306.
  5. ^ ab B. Haberman; D. Thaler (agosto de 2002). Direcciones de multidifusión IPv6 basadas en prefijo de unidifusión. Grupo de trabajo de redes. doi : 10.17487/RFC3306 . RFC 3306. Norma propuesta. Actualizada por RFC 3956, 4489 y 7371.
  6. ^ JS. Park; MK. Shin; HJ. Kim (abril de 2006). Un método para generar direcciones de multidifusión IPv6 con alcance de enlace. Grupo de trabajo de redes. doi : 10.17487/RFC4489 . RFC 4489. Norma propuesta. Actualizaciones RFC 3306.
  7. ^ Graziani, Rick (2012). Fundamentos de IPv6: un enfoque sencillo para comprender IPv6. Cisco Press . pág. 55. ISBN 978-0-13-303347-2.
  8. ^ Coffeen, Tom (2014). Planificación de direcciones IPv6: diseño de un plan de direcciones para el futuro. O'Reilly Media . p. 170. ISBN 978-1-4919-0326-1.
  9. ^ S. Kawamura; M. Kawashima (agosto de 2010). Una recomendación para la representación de texto de direcciones IPv6. Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC5952 . ISSN  2070-1721. RFC 5952. Norma propuesta. Actualizaciones RFC 4291.
  10. ^ T. Berners-Lee ; R. Fielding ; L. Masinter (enero de 2005). Identificador uniforme de recursos (URI): sintaxis genérica. Grupo de trabajo en red. doi : 10.17487/RFC3986 . STD 66. RFC 3986. Estándar de Internet 66. Deja obsoletos los RFC 2732, 2396 y 1808. Actualizado por los RFC 6874, 7320 y 8820. Actualiza el RFC 1738.
  11. ^ ab S. Deering ; B. Haberman; T. Jinmei; E. Nordmark; B. Zill (marzo de 2005). Arquitectura de direcciones con ámbito IPv6. Grupo de trabajo de redes. doi : 10.17487/RFC4007 . RFC 4007. Norma propuesta. Actualizada por RFC 7346.
  12. ^ ab inet6(4) –  Manual de interfaces del núcleo de FreeBSD "La implementación de KAME admite una notación de dirección IPv6 numérica extendida para direcciones locales de enlace, como "fe80::1%de0" [...] draft-ietf-ipngwg-scopedaddr-format-02.txt"
  13. ^ B. Carpenter ; S. Cheshire; R. Hinden (febrero de 2013). Representación de identificadores de zona IPv6 en literales de dirección e identificadores uniformes de recursos. IETF . doi : 10.17487/RFC6874 . ISSN  2070-1721. RFC 6874. Norma propuesta. Actualizaciones RFC 3986.
  14. ^ "Historial del dominio ipv6-literal.net". who.is . Consultado el 20 de octubre de 2014 .
  15. ^ R. Droms (agosto de 2014). Alcances de direcciones de multidifusión IPv6. Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC7346 . ISSN  2070-1721. RFC 7346. Norma propuesta. Actualizaciones RFC 4007 y 4291.
  16. ^ Internet Architecture Board ; Internet Engineering Steering Group (diciembre de 1995). Gestión de asignación de direcciones IPv6. Grupo de trabajo de redes. doi : 10.17487/RFC1881 . RFC 1881. Informativo.
  17. ^ Espacio de direcciones IPv6 en IANA. Iana.org (29 de octubre de 2010). Consultado el 28 de septiembre de 2011.
  18. ^ Asignaciones de direcciones unicast IPv6, IANA
  19. ^ DE-TELEKOM-20050113 [ enlace muerto permanente ] db.ripe.net. Consultado el 28 de septiembre de 2011.
  20. ^ "Manual de políticas de recursos de números ARIN: asignación inicial a ISP".
  21. ^ "Política de asignación y distribución de direcciones IPv6 de RIPE NCC: asignación mínima".
  22. ^ por ejemplo. Iana.org. Recuperado el 28 de septiembre de 2011.
  23. ^ abc T. Narten; G. Huston; L. Roberts (marzo de 2011). Asignación de direcciones IPv6 a sitios finales. Grupo de trabajo de ingeniería de Internet (IETF). doi : 10.17487/RFC6177 . ISSN  2070-1721. BCP 157. RFC 6177. Mejor práctica común. Obsoleto RFC 3177.
  24. ^ "Planes de direccionamiento IPv6". Wiki IPv6 de ARIN . Consultado el 15 de julio de 2018. Todos los clientes obtienen un / 48 a menos que puedan demostrar que necesitan más de 65k subredes. [...] Si tiene muchos clientes consumidores, es posible que desee asignar / 56 a sitios residenciales privados.
  25. ^ "¿Qué son los Bogones?" . Consultado el 15 de noviembre de 2021 .
  26. ^ "Espacio de direcciones administrado por el NCC de RIPE" . Consultado el 22 de mayo de 2011 .
  27. ^ D. Johnson; S. Deering (marzo de 1999). Direcciones Anycast de subredes IPv6 reservadas. Grupo de trabajo de redes. doi : 10.17487/RFC2526 . RFC 2526. Norma propuesta.
  28. ^ ab M. Cotton; L. Vegoda; B. Haberman (abril de 2013). R. Bonica (ed.). Registros de direcciones IP para fines especiales. IETF . doi : 10.17487/RFC6890 . ISSN  2070-1721. BCP 153. RFC 6890. Mejor práctica actual 153. Deja obsoletos los RFC 4773, 5156, 5735 y 5736. Actualizado por el RFC 8190.
  29. ^ "Registro de direcciones IPv6 de propósito especial de la IANA". www.iana.org . Consultado el 2 de agosto de 2024 .
  30. ^ abc 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.
  31. ^ ab T. Anderson (agosto de 2017). Prefijo de traducción IPv4/IPv6 de uso local. Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC8215 . RFC 8215. Norma propuesta.
  32. ^ ab N. Hilliard; D. Freedman (agosto de 2012). Un prefijo de descarte para IPv6. Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC6666 . ISSN  2070-1721. RFC 6666. Informativo.
  33. ^ S. Santesson (septiembre de 2006). Mensaje de enlace TLS para datos complementarios. Grupo de trabajo de redes. doi : 10.17487/RFC4680 . RFC 4680. Norma propuesta. Actualizaciones de RFC 4346. Actualizado por RFC 8447 y 8996.
  34. ^ abc J. Laganier; F. Dupont (septiembre de 2014). Un prefijo IPv6 para identificadores criptográficos hash enrutables por superposición versión 2 (ORCHIDv2). Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC7343 . ISSN  2070-1721. RFC 7343. Norma propuesta. Deja obsoleta la RFC 4843.
  35. ^ ab G. Huston; A. Lord; P. Smith (julio de 2004). Prefijo de dirección IPv6 reservado para documentación. Grupo de trabajo de redes. doi : 10.17487/RFC3849 . RFC 3849. Informativo.
  36. ^ abc O. Troan (mayo de 2015). B. Carpenter (ed.). Desuso del prefijo Anycast para enrutadores de retransmisión 6to4. Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC7526 . BCP 196. RFC 7526. Mejores prácticas actuales. RFC 3068 y 6732 obsoletos .
  37. ^ ab G. Huston; N. Buraglio (agosto de 2024). Ampliación del espacio de documentación de IPv6. Grupo de trabajo de ingeniería de Internet (IETF). doi : 10.17487/RFC9637 . RFC 9637. Informativo. Actualizaciones RFC 3849.
  38. ^ Krishnan, S. (15 de febrero de 2024). Identificadores de segmentos SRv6 en la arquitectura de direccionamiento IPv6. IETF . ID draft-ietf-6man-sids-06 . Consultado el 13 de junio de 2024 .
  39. ^ abcd R. Hinden; B. Haberman (octubre de 2005). Direcciones IPv6 de unidifusión locales únicas. Grupo de trabajo de redes. doi : 10.17487/RFC4193 . RFC 4193. Norma propuesta.
  40. ^ C. Bao; X. Li; F. Baker ; T. Anderson; F. Gont (junio de 2016). Algoritmo de traducción IP/ICMP. Grupo de trabajo de ingeniería de Internet (IETF). doi : 10.17487/RFC7915 . RFC 7915. Norma propuesta. Deja obsoleta la RFC 6145.
  41. ^ R. Hinden; S. Deering ; R. Fink; T. Hain (septiembre de 2000). Asignaciones iniciales de ID de sub-TLA de IPv6. Grupo de trabajo de redes. doi : 10.17487/RFC2928 . RFC 2928. Informativo.
  42. ^ C. Popoviciu; A. Hamza; G. Van de Velde; D. Dugatkin (mayo de 2008). Metodología de evaluación comparativa de IPv6 para dispositivos de interconexión de red. Grupo de trabajo de redes. doi : 10.17487/RFC5180 . RFC 5180. Informativo.
  43. ^ J. Arkko; M. Cotton; L. Vegoda (enero de 2010). Bloques de direcciones IPv4 reservados para documentación. Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC5737 . ISSN  2070-1721. RFC 5737. Informativo. Actualizaciones RFC 1166.
  44. ^ "Registro de espacio de direcciones de multidifusión IPv6". Autoridad de Números Asignados de Internet .
  45. ^ ab T. Mrugalski; M. Siodelski; B. Volz; A. Yourtchenko; M. Richardson; S. Jiang; T. Lemon; T. Winters (noviembre de 2018). Protocolo de configuración dinámica de host para IPv6 (DHCPv6). IETF . doi : 10.17487/RFC8415 . ISSN  2070-1721. RFC 8415. Norma propuesta. Quedan obsoletas las RFC 3315, 3633, 3736, 4242, 7083, 7283 y 7550.
  46. ^ S. Thomson; T. Narten; T. Jinmei (septiembre de 2007). Configuración automática de direcciones sin estado de IPv6. Grupo de trabajo de redes. doi : 10.17487/RFC4862 . RFC 4862. Borrador de norma. Obsoleto RFC 2462. Actualizado por RFC 7527.
  47. ^ T. Narten; E. Nordmark; W. Simpson; H. Holiman (septiembre de 2007). Descubrimiento de vecinos para IP versión 6 (IPv6). Grupo de trabajo de redes. doi : 10.17487/RFC4861 . RFC 4861. Borrador de norma. Obsoleto RFC 2461. Actualizado por RFC 5942, 6980, 7048, 7527, 7559, 8028, 8319, 8425 y 9131.
  48. ^ Iljitsch van Beijnum (2006). "Partes internas de IPv6". La revista del protocolo de Internet . vol. 9, núm. 3. págs. 16-29.
  49. ^ Las implicaciones de privacidad de las direcciones IPv6 sin estado. Portal.acm.org (21 de abril de 2010). Recuperado el 28 de septiembre de 2011.
  50. ^ F. Gont; S. Krishnan; T. Narten; R. Draves (febrero de 2021). Extensiones de direcciones temporales para la autoconfiguración de direcciones sin estado en IPv6. Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC8981 . ISSN  2070-1721. RFC 8981. Norma propuesta. Deja obsoleta la RFC  4941.
  51. ^ "IPv6 en Windows" . Consultado el 25 de marzo de 2024 .
  52. ^ T. Aura (marzo de 2005). Direcciones generadas criptográficamente (CGA). Grupo de trabajo de redes. doi : 10.17487/RFC3972 . RFC 3972. Norma propuesta. Actualizada por RFC 4581 y 4982.
  53. ^ ab F. Gont (abril de 2014). Un método para generar identificadores de interfaz semánticamente opacos con configuración automática de direcciones sin estado IPv6 (SLAAC). Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC7217 . ISSN  2070-1721. RFC 7217. Norma propuesta.
  54. ^ D. Thaler; R. Draves; A. Matsumoto; T. Chown (septiembre de 2012). D. Thaler (ed.). Selección de dirección predeterminada para el Protocolo de Internet versión 6 (IPv6). IETF . doi : 10.17487/RFC6724 . ISSN  2070-1721. RFC 6724. Norma propuesta. Deja obsoleta la RFC 3484.
  55. ^ S. Thomson; C. Huitema; V. Ksinant; M. Souissi (octubre de 2003). Extensiones DNS para soportar IP versión 6. Grupo de trabajo de redes. doi : 10.17487/RFC3596 . RFC 3596. Estándar de Internet. Quedan obsoletos los RFC 3152 y 1886.
  56. ^ ab R. Hinden; S. Deering (diciembre de 1995). Arquitectura de direccionamiento IP versión 6. Grupo de trabajo de redes. doi : 10.17487/RFC1884 . RFC 1884. Obsoleto. Quedó obsoleto según RFC 2373.
  57. ^ C. Huitema ; B. Carpenter (septiembre de 2004). Desuso de direcciones locales de sitios. Grupo de trabajo de redes. doi : 10.17487/RFC3879 . RFC 3879. Norma propuesta.
  58. ^ G. Houston (agosto de 2005). Cambios propuestos al formato del registro IPv6 de la IANA. Grupo de trabajo de redes. doi : 10.17487/RFC4147 . RFC 4147. Informativo.
  59. ^ J. Bound; B. Carpenter; D. Harrington; J. Houldsworth; A. Lloyd (agosto de 1996). NSAPs OSI e IPv6. Grupo de trabajo de redes. doi : 10.17487/RFC1888 . RFC 1888. Obsoleto. Obsoleto por RFC 4048. Actualizado por RFC  4548.
  60. ^ B. Carpenter (abril de 2005). RFC 1888 está obsoleto. doi : 10.17487/RFC4048 . RFC 4048. Informativo. Actualizado por RFC 4548.
  61. ^ R. Hinden; R. Fink; J. Postel (diciembre de 1998). Asignación de direcciones para pruebas de IPv6. Grupo de trabajo de redes. doi : 10.17487/RFC2471 . RFC 2471. Obsoleto. Queda obsoleto según RFC 3701. Queda obsoleto según RFC 1897.
  62. ^ R. Fink; R. Hinden (marzo de 2004). Eliminación gradual de 6bone (asignación de direcciones de prueba IPv6). Grupo de trabajo de redes. doi : 10.17487/RFC3701 . RFC 3701. Informativo. RFC 2471 obsoleto .
  63. ^ P. Nikander; J. Laganier; F. Dupont (abril de 2007). Un prefijo IPv6 para identificadores criptográficos hash enrutables superpuestos (ORCHID). Grupo de trabajo de redes. doi : 10.17487/RFC4843 . RFC 4843. Obsoleto. Quedó obsoleto según RFC 7343.
  64. ^ R. Bush (agosto de 2001). Delegación de IP6.ARPA. Grupo de trabajo de redes. doi : 10.17487/RFC3152 . BCP 49. RFC 3152. Obsoleto. Quedó obsoleto por la RFC 3596. Actualizaciones RFC 1886, 2553, 2766, 2772 y 2874
  65. ^ IAB ; IESG (septiembre de 2001). Recomendaciones IAB/IESG sobre asignaciones de direcciones IPv6 a sitios. Grupo de trabajo de redes. doi : 10.17487/RFC3177 . RFC 3177. Obsoleto. Quedó obsoleto según RFC 6177.
  66. ^ S. Thomson; C. Huitema (diciembre de 1995). Extensiones DNS para soportar la versión 6 de IP. Grupo de Trabajo de Redes. doi : 10.17487/RFC1886 . RFC 1886. Obsoleto. Quedó obsoleto según RFC  3596. Actualizado por RFC 2874 y 3152.
  67. ^ M. Crawford; C. Huitema (julio de 2000). Extensiones DNS para soportar la agregación y renumeración de direcciones IPv6. Grupo de trabajo de redes. doi : 10.17487/RFC2874 . RFC 2874. Histórico. Actualizado por RFC 3152, 3226, 3363 y 3364. Actualizaciones RFC 1886.
  68. ^ Comparación entre AAAA y A6 (¿realmente necesitamos A6?), Jun-ichiro itojun Hagino, (julio de 2001)
  69. ^ ab R. Bush; A. Durand; B. Fink; O. Gudmundsson; T. Hain, eds. (agosto de 2002). Representación de direcciones del Protocolo de Internet versión 6 (IPv6) en el Sistema de nombres de dominio (DNS). Grupo de trabajo de redes. doi : 10.17487/RFC3363 . RFC 3363. Informativo. Actualizaciones RFC 2673 y 2874.
  70. ^ R. Austein (agosto de 2002). Compensaciones en la compatibilidad del sistema de nombres de dominio (DNS) con el protocolo de Internet versión 6 (IPv6). Grupo de trabajo de redes. doi : 10.17487/RFC3364 . RFC 3364. Informativo. Actualizaciones RFC 2673 y 2874.
  71. ^ ab A. Bierman; M. Bjorklund (marzo de 2012). Modelo de control de acceso del protocolo de configuración de red (NETCONF). Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC6536 . RFC 6536. Obsoleto. Quedó obsoleto según RFC 8341.
  72. ^ Y. Morishita; T. Jinmei (mayo de 2005). Errores comunes en las consultas DNS para direcciones IPv6. doi : 10.17487/RFC4074 . RFC 4074. Informativo.
  • Direcciones de multidifusión de IP versión 6
  • Beijnum, van, Iljitsch (2005). Ejecutando IPv6 . ISBN 978-1-59059-527-5.
  • R. Elz (1 de abril de 1996). Una representación compacta de direcciones IPv6. Grupo de trabajo de redes. doi : 10.17487/RFC1924 . RFC 1924. Informativo. Esta es una solicitud de comentarios por el Día de los Inocentes . Representa cualquier dirección IPv6 en 20 octetos. Esta divertida RFC especifica una forma alternativa de representar direcciones IPv6, utilizando una codificación base-85.
Obtenido de "https://es.wikipedia.org/w/index.php?title=Dirección_IPv6&oldid=1253148138"