Una dirección de Protocolo de Internet versión 6 ( dirección IPv6 ) es una etiqueta numérica que se usa para identificar y ubicar una interfaz de red de una computadora o un nodo de red que participa en una red de computadoras usando 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 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 definió 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 muy ampliado .
Métodos de direccionamiento
Las direcciones IPv6 se clasifican según las metodologías de direccionamiento y enrutamiento principales comunes en las redes: direccionamiento unidifusión, direccionamiento anycast y direccionamiento multicast. [1]
Una dirección de unidifusión identifica una única interfaz de red. El Protocolo de Internet entrega paquetes enviados a una dirección de unidifusión a esa interfaz específica.
Una dirección anycast se asigna a un grupo de interfaces, que generalmente pertenecen a diferentes nodos. Un paquete enviado a una dirección anycast se entrega a solo una de las interfaces miembro, generalmente el host más cercano, de acuerdo con 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 solo se diferencian por su presencia en la red en múltiples puntos. Casi cualquier dirección de unidifusión se puede emplear como una 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 participando en el protocolo de distribución de multidifusión entre los enrutadores de 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 la transmisión está subsumida por 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 un grupo de multidifusión local de enlace dedicado para evitar perturbar todas las interfaces de la red.
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 usando reglas establecidas para asociar los valores de estos grupos de bits con características especiales de direccionamiento.
Formato de dirección unicast y anycast
Las direcciones unicast y anycast se componen típicamente de dos partes lógicas: un prefijo de red de 64 bits que se usa para el enrutamiento y un identificador de interfaz de 64 bits que se usa para identificar la interfaz de red de un host.
bits | 48 (o más) | 16 (o menos) | 64 |
---|---|---|---|
campo | prefijo de enrutamiento | ID de subred | identificador 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 más grande significa un tamaño de identificación de subred más pequeño. Los bits del campo de identificación de subred están disponibles para que el administrador de la red defina subredes dentro de la red dada. El identificador de interfaz de 64 bits se genera automáticamente a partir de la dirección MAC de la interfaz utilizando el formato EUI-64 modificado , se obtiene de un servidor DHCPv6 , se establece automáticamente de forma aleatoria o se asigna manualmente.
Las direcciones locales únicas son direcciones análogas a las direcciones de red privada IPv4 .
bits | 7 | 1 | 40 | dieciséis | 64 |
---|---|---|---|---|---|
campo | prefijo | L | aleatorio | ID de subred | identificador de interfaz |
El campo de prefijo contiene el valor binario 1111110. El bit L es cero para direcciones asignadas globalmente y uno para direcciones asignadas localmente. 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 usa un formato diferente para el prefijo de red.
bits | 10 | 54 | 64 |
---|---|---|---|
campo | prefijo | ceros | identificador 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 ( fe80 :: / 64 prefijo de dirección de enlace local ), haciéndolos 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.
bits | 8 | 4 | 4 | 112 |
---|---|---|---|---|
campo | prefijo | flg | Carolina del Sur | Identificación del grupo |
El prefijo contiene el valor binario 11111111 para cualquier dirección de multidifusión.
Actualmente, se definen 3 de los 4 bits de bandera en el campo flg ; [1] el bit de bandera más significativo está reservado para uso futuro.
un poco | bandera | Significado cuando 0 | Significado cuando 1 |
---|---|---|---|
8 | reservado | reservado | reservado |
9 | R (encuentro) [3] | Punto de encuentro no integrado | Punto de encuentro incrustado |
10 | P (prefijo) [4] | Sin información de prefijo | Dirección basada en el prefijo de red |
11 | T (transitorio) [1] | Dirección de multidifusión conocida | Dirección de multidifusión asignada dinámicamente |
El campo de alcance de 4 bits ( sc ) se utiliza para indicar dónde la dirección es válida y única.
Hay direcciones de multidifusión especiales, como Solicited Node.
bits | 8 | 4 | 4 | 79 | 9 | 24 |
---|---|---|---|---|---|---|
campo | prefijo | flg | Carolina del Sur | ceros | unos | direcció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 en 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 unidifusión o anycast en los últimos 24 bits de la dirección de multidifusión.
bits | 8 | 4 | 4 | 4 | 4 | 8 | 64 | 32 |
---|---|---|---|---|---|---|---|---|
campo | prefijo | flg | Carolina del Sur | res | riid | plen | prefijo de red | Identificación del grupo |
Las direcciones de multidifusión con ámbito de enlace utilizan un formato comparable. [5]
Representación
Una dirección IPv6 se representa como ocho grupos de cuatro dígitos hexadecimales , cada grupo representa 16 bits (dos octetos , un grupo a veces también llamado hexteto [6] [7] ). 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 brindan flexibilidad en la representación de direcciones IPv6. La representación completa de ocho grupos de cuatro dígitos puede simplificarse 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, buscar una dirección específica o un patrón de dirección en documentos de texto o secuencias, y comparar direcciones para determinar la equivalencia. Para mitigar estas complicaciones, el IETF ha definido un formato canónico en RFC 5952 para representar direcciones IPv6 en texto: [8]
Los dígitos hexadecimales siempre se comparan sin distinción entre mayúsculas y minúsculas, pero las recomendaciones de IETF sugieren el uso de solo letras minúsculas. Por ejemplo, se prefiere 2001: db8 :: 1 sobre 2001: DB8 :: 1 .
Se suprimen los ceros iniciales en cada campo de 16 bits, pero cada grupo debe retener al menos un dígito en el caso del grupo todo ceros. Por ejemplo, 2001: 0db8 :: 0001: 0000 se representa como 2001: db8 :: 1: 0 . El campo todo cero que se presenta explícitamente se representa como 0 .
La secuencia más larga de campos todos ceros consecutivos se reemplaza con dos dos puntos ("::"). Si la dirección contiene múltiples ejecuciones de campos todos cero, entonces es el más a la izquierda el que está comprimido para evitar ambigüedades. Por ejemplo, 2001: db8: 0: 0: 1: 0: 0: 1 se representa como 2001: db8 :: 1: 0: 0: 1 en lugar de 2001: db8: 0: 0: 1 :: 1 .
"::" no se utiliza para representar un solo campo todo cero. Por ejemplo, 2001: db8: 0: 0: 0: 0: 2: 1 se abrevia 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 dar lugar a representaciones muy breves de direcciones IPv6. Por ejemplo, la dirección localhost (loopback), 0: 0: 0: 0: 0: 0: 0: 1 , y la dirección IPv6 no especificada, 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 tales casos de uso, se ha introducido una notación especial, que expresa direcciones IPv6 asignadas a IPv4 y compatibles con IPv4 escribiendo los 32 bits menos significativos de una dirección en la notación decimal de puntos IPv4 familiar , mientras que los 96 bits más significativos están escritos en formato IPv6. Por ejemplo, la dirección IPv6 asignada a IPv4 :: ffff: c000: 0280 se escribe como :: ffff: 192.0.2.128 , expresando así claramente la dirección IPv4 original que se asignó a IPv6.
Redes
Una red IPv6 usa un bloque de direcciones que es un grupo contiguo de direcciones IPv6 de un tamaño que es una potencia de dos . El conjunto inicial de bits 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 indica mediante 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 puede indicarse directamente con la dirección mediante notación CIDR. Por ejemplo, la configuración de una interfaz con la dirección 2001: db8: a :: 123 conectado 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 inclinada (/) seguida de un número en decimal cuyo valor es la longitud del prefijo de red en bits, en lugar de especificar explícitamente qué direcciones están en el bloque. Por ejemplo, un bloque de direcciones con 48 bits en el prefijo se indica con / 48 . Dicho bloque contiene 2 128 - 48 = 2 80 direcciones. Cuanto menor sea el valor 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 dos puntos (:) en las direcciones IPv6 pueden entrar en conflicto con la sintaxis establecida de los identificadores de recursos, como URI y URL . Los dos puntos se han utilizado tradicionalmente para terminar la ruta del host antes de un número de puerto . [9] Para aliviar este conflicto, las direcciones IPv6 literales se incluyen 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)
Para direcciones con un alcance diferente al global (como se describe a continuación ), y en particular para direcciones de enlace local, 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 sola dirección no está en uso en diferentes zonas, los prefijos de dirección para las direcciones en esas zonas aún pueden ser idénticos, lo que hace que el sistema operativo no pueda seleccionar una interfaz saliente basada en la información en la tabla de enrutamiento (que es prefijo- basado).
Para resolver la ambigüedad en las direcciones textuales, un El índice de zona debe agregarse a la dirección, los dos separados por unsigno de porcentaje(%). [10] La sintaxis de los índices de zona es una cadena dependiente de la implementación, aunque los índices de zona numéricos también deben ser soportados universalmente. La dirección de enlace local
- fe80 :: 1ff: fe23: 4567: 890a
podría ser expresado por
- fe80 :: 1ff: fe23: 4567: 890a% eth2
o:
- fe80 :: 1ff: fe23: 4567: 890a% 3
El primero (usando un nombre de interfaz ) es habitual en la mayoría de los sistemas operativos similares a Unix (por ejemplo, BSD , Linux , macOS ). Este último (utilizando un número de interfaz) es la sintaxis estándar en Microsoft Windows , pero como la compatibilidad con esta sintaxis es obligatoria, también está disponible en otros sistemas operativos.
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érico en la segunda palabra de 16 bits de la dirección. P.ej:
- fe80: 3 :: 1ff: fe23: 4567: 890a
En todos los sistemas operativos mencionados anteriormente, el índice de zona para direcciones de enlace local 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 al mismo conmutador ), en la práctica, dos direcciones con diferentes identificadores de zona pueden ser equivalentes y hacer referencia al mismo host en el mismo enlace.
Uso de índices de zona en URI
Cuando se usa en identificadores uniformes de recursos (URI), el uso del signo de porcentaje causa un conflicto de sintaxis, por lo tanto, debe escaparse mediante la codificación de porcentaje , [11] 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 esta razón, Microsoft implementó un algoritmo de transcripción para representar una dirección IPv6 en forma de nombre de dominio que se puede usar en rutas UNC. Para ello, Microsoft registró y reservó el dominio de segundo nivel ipv6-literal.net en Internet (aunque cedió el dominio en enero de 2014 [12] ). 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 del carácter 's':
- fe80 :: 1ff: fe23: 4567: 890a% 3
está escrito como
- fe80--1ff-fe23-4567-890a s3 .ipv6-literal.net
Ámbitos de direcciones
Cada dirección IPv6, excepto la dirección no especificada ( ::) , tiene un "alcance", [10] que especifica en qué parte de la red es válida.
Unidifusión
Para las direcciones de unidifusión , se definen dos ámbitos: local de enlace y global.
Las direcciones de enlace local y la dirección de bucle de retorno tienen un alcance de enlace local , lo que significa que solo se pueden utilizar en una única red conectada directamente (enlace). Todas las demás direcciones (incluidas las direcciones locales únicas ) tienen un alcance global (o universal ), lo que significa que son (o podrían ser) enrutables globalmente y se pueden usar para conectarse a direcciones con alcance global en cualquier lugar, oa direcciones con alcance local de enlace. en la red conectada directamente. Los paquetes con un origen o destino en un ámbito no se pueden enrutar a un ámbito diferente. [13]
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 cooperante pueden llegar a tales direcciones, si se enrutan correctamente. Como su alcance es global, estas direcciones son válidas como una dirección de origen cuando se comunican con cualquier otra dirección de alcance global, aunque puede ser imposible enrutar paquetes desde el destino de regreso al origen.
Anycast
Las direcciones Anycast son sintácticamente idénticas e indistinguibles de las direcciones unicast. Su única diferencia es administrativa. Por tanto, los alcances de las direcciones anycast son los mismos que los de las direcciones unicast.
Multidifusión
Para direcciones de multidifusión , los cuatro bits menos significativos del segundo octeto de dirección ( ff0 s : :) identifican la dirección s cope, es decir, el dominio en el que debe propagarse el paquete de multidifusión. Los ámbitos predefinidos y reservados [1] son:
Valor | Nombre de alcance | Notas |
---|---|---|
0x0 | reservado | |
0x1 | interfaz-local | El alcance de la interfaz local abarca solo una interfaz única en un nodo y solo es útil para la transmisión de bucle invertido de multidifusión. |
0x2 | enlace-local | El ámbito de enlace local abarca la misma región topológica que el ámbito de unidifusión correspondiente. |
0x3 | reino-local | El ámbito de ámbito local se define como mayor que el de enlace local, determinado automáticamente por la topología de la red y no debe ser mayor que los siguientes ámbitos. [14] |
0x4 | admin-local | El ámbito local de administrador es el ámbito más pequeño que debe configurarse administrativamente, es decir, no derivado automáticamente de la conectividad física u otra configuración no relacionada con la multidifusión. |
0x5 | sitio-local | El alcance local del sitio está destinado a abarcar un único sitio que pertenece a una organización. |
0x8 | organización-local | El alcance local de la organización está destinado a abarcar todos los sitios que pertenecen a una sola organización. |
0xe | global | El alcance global abarca todos los nodos accesibles en Internet, es ilimitado. |
0xf | reservado |
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) [15] por la Junta 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 ha mantenido la lista oficial de asignaciones del espacio de direcciones IPv6 desde diciembre de 1995. [16]
Actualmente, sólo una octava parte del espacio total de direcciones se asigna para su uso en Internet , 2000 :: / 3 , con el fin de proporcionar una agregación de rutas eficiente , reduciendo así el tamaño de las tablas de enrutamiento de Internet; el resto del espacio de direcciones IPv6 está reservado para uso futuro o para fines especiales. El espacio de direcciones se asigna a los RIR en grandes bloques de / 23 hasta / 12 . [17]
Los RIR asignan bloques más pequeños a los registros locales de Internet que los distribuyen a los usuarios. Estos suelen estar en tamaños de / 19 a / 32 . [18] [19] [20] Las direcciones se distribuyen normalmente en bloques de tamaño / 48 a / 56 a los usuarios finales. [21]
Los registros de asignación de unidifusión global se pueden encontrar en los diversos RIR u otros sitios web. [22]
Las direcciones IPv6 se asignan a organizaciones en bloques mucho más grandes en comparación con las asignaciones de direcciones IPv4; la asignación recomendada es un bloque / 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. El conjunto total, sin embargo, 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 billones de billones de billones) de direcciones IPv6 únicas.
Cada RIR puede dividir cada una de sus múltiples / 23 bloques en 512 / 32 bloques, típicamente uno para cada ISP; un ISP puede dividir su / 32 bloque en 65 536 / 48 bloques, típicamente uno para cada cliente; [23] clientes pueden crear 65 536 / 64 redes de su asignado / 48 bloques, cada uno de 2 tienen 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á realmente una fracción muy pequeña del espacio de direcciones. El gran espacio de direcciones asegura que las direcciones estén casi siempre disponibles, lo que hace que el uso de la traducción de direcciones de red (NAT) para fines de conservación de direcciones sea completamente innecesario. NAT se ha utilizado cada vez más en redes IPv4 para ayudar a aliviar el agotamiento de las direcciones IPv4 .
Asignación especial
Para permitir cambios de proveedor sin volver a numerar, el espacio de direcciones independiente del proveedor , asignado directamente al usuario final por los RIR, se toma del rango especial 2001: 678 :: / 29 .
A los Puntos de Intercambio de Internet (IXP) se les asignan direcciones especiales del rango 2001: 7f8 :: / 29 para la comunicación con sus ISP conectados . [24] A los servidores de nombres raíz se les han asignado direcciones del mismo rango.
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 hablan 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. [25] Estas direcciones suelen tener los primeros 57 bits del identificador de interfaz establecidos en 1, seguidos por el ID de difusión por proximidad de 7 bits. Los prefijos de la red, incluidas las subredes, deben tener una longitud de 64 bits, en cuyo caso el bit universal / local debe establecerse en 0 para indicar que la dirección no es única globalmente. La dirección con valor 0x7e en los 7 bits menos significativos se define como una dirección anycast de agentes domésticos IPv6 móviles . La dirección con valor 0x7f (todos los bits 1) está reservada y no se puede utilizar. No se realizan más asignaciones de este rango, por lo que los valores 0x00 a 0x7d también están reservados.
Direcciones especiales
Hay una serie de direcciones con un significado especial en IPv6. [26] Representan menos del 2% de todo el espacio de direcciones:
Bloque de direcciones (CIDR) | Primera direccion | Ultima direccion | Numero de direcciones | Uso | Propósito |
---|---|---|---|---|---|
:: / 0 | :: | ffff: ffff: ffff: ffff: ffff: ffff: ffff: ffff | 2 128 | Enrutamiento | Ruta predeterminada (sin ruta específica) |
:: / 128 | :: | :: | 1 | Software | Dirección no especificada |
:: 1/128 | :: 1 | :: 1 | 1 | Anfitrión | Dirección de bucle invertido: una interfaz virtual que devuelve todo el tráfico a sí mismo, el host local. |
:: ffff: 0: 0/96 | :: ffff: 0.0.0.0 | :: ffff: 255.255.255.255 | 2 128−96 = 2 32 =4 294 967 296 | Software | Direcciones asignadas IPv4 |
:: ffff: 0: 0: 0/96 | :: ffff: 0: 0.0.0.0 | :: ffff: 0: 255.255.255.255 | 2 32 | Software | Direcciones IPv4 traducidas |
64: ff9b :: / 96 | 64: ff9b :: 0.0.0.0 | 64: ff9b :: 255.255.255.255 | 2 32 | Internet global | Traducción de IPv4 / IPv6 [27] |
100 :: / 64 | 100 :: | 100 :: ffff: ffff: ffff: ffff | 2 64 | Enrutamiento | Descartar prefijo [28] |
2001: 0000: / 32 | 2001 :: | 2001 :: ffff: ffff: ffff: ffff: ffff: ffff | 2 96 | Internet global | Túnel de Teredo [29] |
2001: 20 :: / 28 | 2001: 20 :: | 2001: 2f: ffff: ffff: ffff: ffff: ffff: ffff | 2 100 | Software | ORCHIDv2 [30] |
2001: db8 :: / 32 | 2001: db8 :: | 2001: db8: ffff: ffff: ffff: ffff: ffff: ffff | 2 96 | Documentación | Direcciones utilizadas en la documentación y código fuente de ejemplo [31] |
2002 :: / 16 | 2002 :: | 2002: ffff: ffff: ffff: ffff: ffff: ffff: ffff | 2 112 | Internet global | El esquema de direccionamiento 6to4 (obsoleto) [32] |
fc00 :: / 7 | fc00 :: | fdff: ffff: ffff: ffff: ffff: ffff: ffff: ffff | 2 121 | Internets privadas | Dirección local única [33] |
fe80 :: / 10 | fe80 :: | fe80 :: ffff: ffff: ffff: ffff | 2 64 | Enlace | Dirección de enlace local |
ff00 :: / 8 | ff00 :: | ffff: ffff: ffff: ffff: ffff: ffff: ffff: ffff | 2 120 | Internet global | Dirección de multidifusión |
Direcciones de unidifusión
Ruta por defecto
- :: / 0 : ladirección deruta predeterminada(correspondiente a 0.0.0.0 / 0 en IPv4) para direcciones de destino (unidifusión, multidifusión y otras) no especificadas en ninguna otra parte de una tabla de enrutamiento.
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 debe usarse solo en el software antes de que la aplicación haya aprendido la dirección de origen de su host adecuada para una conexión pendiente. Los enrutadores no deben reenviar paquetes con la dirección no especificada.
Las aplicaciones pueden estar escuchando en una o más interfaces específicas para conexiones entrantes, que se muestran en listas de conexiones de Internet activas por 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 conexiones entrantes en todas las interfaces disponibles.
Direcciones locales
- Identificados :: 1 / 128 - Elbucle de retornode direcciones es un unicastlocalhostdirección (correspondiente a 127.0.0.1 / 8 en IPv4).
Si una aplicación en un host envía paquetes a esta dirección, la pila de IPv6 volverá a colocar estos paquetes en la misma interfaz virtual. - fe80 :: / 10 : las direcciones en el prefijo local de enlace solo son válidas y únicas en un único enlace (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 (54 bits cero), lo que produce un formato efectivo de fe80 :: / 64 . Los 64 bits menos significativos se eligen generalmente como la dirección de hardware de la interfaz construida enformatoEUI-64 modificado. Serequiereuna dirección de enlace localen cada interfaz habilitada para IPv6; en otras palabras, las aplicaciones pueden depender de 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 diseñadas para la comunicación local [33] (comparable alas direcciones privadas IPv4 10.0.0.0 / 8 , 172.16.0.0 / 12 y 192.168.0.0 / 16 ).
Solo se pueden enrutar dentro de un conjunto de sitios que cooperan. El bloque se divide en dos mitades. La mitad inferior del bloque ( fc00 :: / 8 ) estaba destinada a prefijos asignados globalmente, pero aún no se ha definido un método de asignación. La mitad superior ( fd00 :: / 8 ) se utiliza para direcciones "probabilísticamente únicas" en las que elprefijo / 8 se combina con unnúmeropseudoaleatoriogenerado localmente de 40 bitspara obtener unprefijo privado / 48 . La forma en que se elige un número de 40 bits da como resultado una probabilidad insignificante de que dos sitios que deseen fusionarse o comunicarse entre sí utilicen el mismo número de 40 bits y, por lo tanto, utilicen el mismoprefijo / 48 . [33]
Transición de IPv4
- :: ffff: 0: 0 / 96 - Este prefijo se utiliza paralos mecanismos de transición IPv6y designada como unadirección IPv6 asignada de IPv4.
Con algunas excepciones, este tipo de dirección permite el uso transparente de losprotocolosde lacapa de transportesobre IPv4 a través de lainterfaz de programación de aplicaciones dered IPv6. Las aplicaciones de servidor solo necesitan abrir un únicosocket deescuchapara manejar las conexiones de los clientes que utilizan protocolos IPv6 o IPv4. Los clientes IPv6 se manejarán 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 IPv4.
- :: ffff: 0: 0: 0 / 96 - Un prefijo utilizado paradirecciones traducidas-IPv4.
Estos son utilizados por elprotocolo de traducción de IP / ICMP sin estado (SIIT). [34] - 64: ff9b :: / 96 - El prefijo "conocido".
Las direcciones con este prefijo se utilizan para la traducción automática de IPv4 / IPv6. [27]
- 2002 :: / 16 : este prefijo se usó paraeldireccionamiento6to4(también se usóuna dirección de la red IPv4 192.88.99.0 / 24 ).
El esquema de direccionamiento 6to4 está obsoleto. [32]
Direcciones de propósito especial
- IANA ha reservado un bloque de direcciones llamado 'Sub-TLA ID' para asignaciones especiales [26] [35] de 2001 :: / 23 (dividido en el rango de 64 prefijos de red 2001: 0000 :: / 29 a 2001: 01f8 :: / 29 ). Actualmente se asignan tres asignaciones de este bloque:
- 2001 :: / 32 - Utilizado paratúneles Teredo.
- 2001: 2 :: / 48 - Se utiliza para laevaluación comparativa deIPv6 (correspondiente a 198.18.0.0 / 15 para la evaluación comparativa de IPv4).
Asignado al Grupo de Trabajo de Metodología de Benchmarking (BMWG). [36] - 2001: 20 :: / 28 - ORCHIDv2 (Identificadores hash criptográficos enrutables superpuestos). [30]
Estas son direcciones IPv6 no enrutadas que se utilizan para identificadores hash criptográficos.
Documentación
- 2001: db8 :: / 32 - Este prefijo se usa en la documentación [31] (correspondiente a 192.0.2.0 / 24 , 198.51.100.0 / 24 y 203.0.113.0 / 24 en IPv4). [37]
Las direcciones deben usarse en cualquier lugar donde se proporcione una dirección IPv6 de ejemplo o se describan escenarios de redes modelo.
Descarte
- 100 :: / 64 : este prefijo se utiliza para descartar tráfico. [28]
Direcciones obsoletas y obsoletas
Direcciones de multidifusión
Las direcciones de multidifusión ff0x :: donde x es cualquier valor hexadecimal están reservadas [1] y no deben asignarse a ningún grupo de multidifusión. La Autoridad de Números Asignados de Internet (IANA) administra las reservas de direcciones. [38]
Algunas direcciones de multidifusión IPv6 comunes son las siguientes:
Habla a | Descripción | Ámbitos disponibles |
---|---|---|
ff0X :: 1 | Dirección de todos los nodos, identificar el grupo de todos los nodos IPv6 | Disponible en el alcance 1 (interfaz local) y 2 (enlace local):
|
ff0X :: 2 | Todos los enrutadores | Disponible en el alcance 1 (interfaz local), 2 (enlace local) y 5 (sitio local):
|
ff02 :: 5 | OSPFIGP | 2 (enlace local) |
ff02 :: 6 | Enrutadores designados OSPFIGP | 2 (enlace local) |
ff02 :: 9 | RIP routers | 2 (enlace local) |
ff02 :: a | EIGRP routers | 2 (enlace local) |
ff02 :: d | Todos los enrutadores PIM | 2 (enlace local) |
ff02 :: 1a | Todos los enrutadores RPL | 2 (enlace local) |
ff0X :: fb | mDNSv6 | Disponible en todos los ámbitos |
ff0X :: 101 | Todos los servidores NTP | Disponible en todos los ámbitos |
ff02 :: 1: 1 | Nombre del enlace | 2 (enlace local) |
ff02 :: 1: 2 | Todos los agentes dhcp ( DHCPv6 ) | 2 (enlace local) |
ff02 :: 1: 3 | Resolución de nombres de multidifusión local de enlace | 2 (enlace local) |
ff05 :: 1: 3 | Todos los servidores dhcp ( DHCPv6 ) | 5 (local del sitio) |
ff02 :: 1: ff00: 0/104 | Dirección de multidifusión de nodo solicitado . Vea abajo | 2 (enlace local) |
ff02 :: 2: ff00: 0/104 | Consultas de información de nodo | 2 (enlace local) |
Dirección de multidifusión de nodo solicitado
Los 24 bits menos significativos del ID de grupo de direcciones de multidifusión del nodo solicitado se rellenan con los 24 bits menos significativos de la dirección 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 molestar a todos los nodos de la red local. Se requiere que un host se una a un grupo de multidifusión de nodo solicitado para cada una de sus direcciones de unidifusión o anycast configuradas.
Autoconfiguración de direcciones sin estado
Al iniciar el sistema, un nodo crea automáticamente una dirección de enlace local en cada interfaz habilitada para IPv6, incluso si las direcciones enrutables globalmente se configuran manualmente u obtienen a través de "protocolos de configuración" (ver más abajo). Lo hace de forma independiente y sin ninguna configuración previa mediante la autoconfiguración de direcciones sin estado (SLAAC), [39] 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 usan el Protocolo de descubrimiento de vecinos para crear una dirección unidifusión enrutable globalmente: el host envía solicitudes de solicitud de enrutador y un enrutador IPv6 responde con una asignación de prefijo. [40]
Los 64 bits inferiores de estas direcciones se rellenan con un identificador de interfaz de 64 bits en formato EUI-64 modificado . Este identificador generalmente lo comparten todas las direcciones configuradas automáticamente de esa interfaz, lo que tiene la ventaja de que solo se debe unir un grupo de multidifusión para el descubrimiento de vecinos. Para esto, se utiliza una dirección de multidifusión, formado a partir de la red de prefijo FF02 :: 1: FF00: 0 / 104 y los 24 bits menos significativos de la dirección.
EUI-64 modificado
Un identificador de interfaz de 64 bits suele derivarse de su dirección MAC de 48 bits . Una dirección MAC 00-0C-29-0C-47-D5 se convierte en un EUI-64 de 64 bits insertando FF-FE en el medio: 00-0C-29 -FF-FE -0C-47-D5 . Cuando se utiliza este EUI-64 para formar una dirección IPv6, se modifica: [1] el significado del bit Universal / Local (el séptimo bit más significativo del EUI-64, comenzando desde 1) se invierte, 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).
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 anuncio de vecino ( ICMPv6 tipo 135 y 136). Mientras está en el proceso de establecer unicidad, una dirección tiene un estado tentativo .
El nodo se une a la dirección de multidifusión del nodo solicitado para la dirección tentativa (si aún no lo ha hecho) y envía solicitudes de vecinos, con la dirección tentativa como dirección de destino y la dirección no especificada ( :: / 128 ) como dirección de origen. El nodo también se une a la dirección de multidifusión de todos los hosts ff02 :: 1 , por lo que podrá recibir anuncios de vecinos .
Si un nodo recibe una solicitud de vecino con su propia dirección tentativa como dirección de destino, esa dirección no es única. Lo mismo ocurre si el nodo recibe un anuncio vecino con la dirección tentativa como fuente del anuncio. Solo después de haber establecido con éxito que una dirección es única, puede ser asignada y utilizada por una interfaz.
Duración de la dirección
Cada dirección IPv6 que está vinculada a una interfaz tiene una vida útil fija. La vida útil es infinita, a menos que se configure en un período más corto. Hay dos tiempos de vida que gobiernan el estado de una dirección: el tiempo de vida preferido y el tiempo de vida válido . [41] Los tiempos de vida se pueden configurar en enrutadores que proporcionan los valores utilizados para la configuración automática, o se pueden especificar cuando se configuran manualmente las direcciones en las interfaces.
Cuando se asigna una dirección a una interfaz, obtiene el estado "preferido", que mantiene durante su vida útil preferida. Una vez que expira esa vida útil, el estado pasa a ser "obsoleto" y no se deben realizar nuevas conexiones utilizando esta dirección. La dirección se vuelve "inválida" después de que su período de validez también expira; la dirección se elimina de la interfaz y puede asignarse en otro lugar de Internet .
Nota: En la mayoría de los casos, la vida útil no expira porque los nuevos anuncios de enrutador (RA) actualizan los temporizadores. Pero si no hay más RA, eventualmente transcurre el tiempo de vida preferido y la dirección se vuelve "obsoleta".
Direcciones temporales
Las direcciones MAC estáticas y únicas a nivel mundial, utilizadas por la autoconfiguración de direcciones sin estado para crear identificadores de interfaz, ofrecen la oportunidad de rastrear el equipo del usuario, a través del tiempo y los cambios de prefijo de red IPv6, y por tanto a los usuarios. [42] Para reducir la posibilidad de que la identidad de un usuario esté vinculada permanentemente a una parte de la dirección IPv6, un nodo puede crear direcciones temporales con identificadores de interfaz basados en cadenas de bits aleatorias que varían en el tiempo [43] y vidas relativamente cortas (de horas a días), después de lo cual se reemplazan con nuevas direcciones.
Las direcciones temporales se pueden usar como dirección de origen para las conexiones de origen, mientras que los hosts externos usan una dirección pública al consultar el Sistema de nombres de dominio.
Las interfaces de red configuradas para IPv6 utilizan direcciones temporales de forma predeterminada en OS X Lion y sistemas Apple posteriores, así como en Windows Vista , Windows 2008 Server y sistemas Microsoft posteriores.
Direcciones generadas criptográficamente
Como medio para mejorar la seguridad del Protocolo de descubrimiento de vecinos, las direcciones generadas criptográficamente (o CGA) se introdujeron en 2005 [44] como parte del Protocolo de descubrimiento de vecinos seguro (SEND).
Dicha dirección se genera mediante dos funciones hash que toman varias entradas. El primero usa una clave pública y un modificador aleatorio; este último se incrementa repetidamente hasta que se adquiere una cantidad específica de cero bits del hash resultante. (Comparable con el campo 'prueba de trabajo' en la minería de Bitcoin ). 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 añaden 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 satisface el requisito de ser una CGA válida. De esta manera, la comunicación se puede establecer entre direcciones confiables exclusivamente.
Direcciones de privacidad estables
El uso de direcciones autoconfiguradas sin estado tiene serias implicaciones para las preocupaciones de seguridad y privacidad, [45] porque la dirección de hardware subyacente (por lo general, la dirección MAC ) está expuesta más allá de la red local, lo que permite el seguimiento de las actividades de los usuarios y la correlación de las cuentas de los usuarios con otras 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.
Se introdujeron direcciones de privacidad estables para remediar estas deficiencias. Son estables dentro de una red específica pero cambian cuando se mueven a otra, para mejorar la privacidad. Se eligen de forma 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ífico de la implementación, pero se recomienda utilizar 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 al prefijo de red de 64 bits, para producir una dirección de 128 bits. Si el prefijo de red es menor que 64 bits, se utilizan más bits del hash. Si la dirección resultante no entra en conflicto con las direcciones existentes o reservadas, se asigna a la interfaz.
Selección de dirección predeterminada
Las interfaces de red habilitadas para IPv6 generalmente tienen más de una dirección IPv6, por ejemplo, una dirección de enlace local y una dirección global. También pueden tener direcciones temporales que cambian después de que haya expirado una determinada vida útil. IPv6 introduce los conceptos de alcance de dirección y preferencia de selección, lo que genera múltiples opciones para la selección de direcciones de origen y destino en la comunicación con otro host.
El algoritmo de selección de preferencias publicado en RFC 6724 selecciona la dirección más apropiada para usar en las comunicaciones con un destino en particular, incluido el uso de direcciones mapeadas IPv4 en implementaciones de doble pila . [46] Utiliza una tabla de preferencias configurable que asocia cada prefijo de enrutamiento con un nivel de precedencia. La tabla predeterminada tiene el siguiente contenido: [46]
Prefijo | Precedencia | Etiqueta | Uso |
---|---|---|---|
:: 1/128 | 50 | 0 | Localhost |
:: / 0 | 40 | 1 | Unidifusión predeterminada |
:: ffff: 0: 0/96 | 35 | 4 | Dirección IPv6 asignada a IPv4 |
2002 :: / 16 | 30 | 2 | 6to4 |
2001 :: / 32 | 5 | 5 | Túnel de Teredo |
fc00 :: / 7 | 3 | 13 | Dirección local única |
:: / 96 | 1 | 3 | Direcciones compatibles con IPv4 (obsoletas) |
fec0 :: / 10 | 1 | 11 | Dirección local del sitio (obsoleta) |
3ffe :: / 16 | 1 | 12 | 6bone (devuelto) |
La configuración predeterminada da preferencia al uso de IPv6 y selecciona las direcciones de destino dentro del ámbito más pequeño posible, de modo que se prefiere la comunicación local de enlace sobre las rutas enrutadas globalmente cuando, por lo demás, es igualmente adecuado. La tabla de políticas de prefijos es similar a una tabla de enrutamiento, con el valor de precedencia que actúa como el rol de un costo de enlace, donde una preferencia más alta se expresa como un valor más grande. Se prefiere que las direcciones de origen tengan el mismo valor de etiqueta que la dirección de destino. Las direcciones se hacen coincidir con los prefijos en función de la secuencia de bits más significativa coincidente 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 del Sistema de nombres de dominio (DNS).
Para minimizar el tiempo de establecimiento de conexiones cuando hay varias direcciones disponibles para la comunicación, se diseñó el algoritmo Happy Eyeballs . Consulta el sistema de nombres de dominio en busca de direcciones IPv6 e IPv4 del host de destino, clasifica las direcciones candidatas utilizando la tabla de selección de direcciones predeterminada e intenta establecer conexiones en paralelo. La primera conexión que se establece anula 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 . [47] Para la búsqueda 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.
Como 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, una computadora host llamada derrick en la zona example.com tiene la dirección local única fdda: 5cc1: 23: 4 :: 1f . Su registro de direcciones 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.4.0.0.0.3.2.0.0.1.cc5.addfip6.arpa. EN PTR derrick.example.com.
Este registro de puntero puede estar definido 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 se pueden transmitir a través de transportes IPv6 o IPv4 independientemente de la familia de direcciones de los datos solicitados.
NOMBRE | Nombre de dominio |
TIPO | AAAA (28) |
CLASE | Internet (1) |
TTL | Tiempo para vivir en segundos |
RDLENGTH | Longitud del campo RDATA |
RDATA | Dirección IPv6 de 128 bits, orden de bytes de red |
Notas históricas
Direcciones obsoletas y obsoletas
- El prefijo local del sitio fec0 :: / 10 especifica que la dirección es válida solo dentro de la red del sitio de una organización. Formaba parte de la arquitectura de direccionamiento original [48] en diciembre de 1995, pero su uso fue desaprobado en septiembre de 2004 [49] porque la definición del término sitio era ambigua, lo que conducía a reglas de enrutamiento confusas. Las nuevas redes no deben admitir este tipo especial de dirección. En octubre de 2005, una nueva especificación [33] reemplazó este tipo de dirección con direcciones locales únicas .
- El bloque de direcciones 200 :: / 7 se definió como un prefijo asignado a NSAP de OSI establecido en agosto de 1996, [50] [51] pero quedó obsoleto en diciembre de 2004. [52]
- El prefijo de valor cero de 96 bits :: / 96 , originalmente conocido como direcciones compatibles con IPv4 , se mencionó en 1995 [48] pero se describió por primera vez en 1998. [53] [ verificación fallida ] Este rango de direcciones se utilizó para representar IPv4 direcciones dentro de una tecnología de transición IPv6. Dicha dirección IPv6 tiene sus primeros 96 bits (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ó con fines de prueba para la red 6bone en diciembre de 1998. [53] Antes de eso, el bloque de direcciones 5f00 :: / 8 se utilizó para este propósito. Ambos bloques de direcciones se devolvieron al grupo de direcciones en junio de 2006. [54]
- Debido a problemas operativos con 6to4, el uso del bloque de direcciones 2002 :: / 16 está disminuyendo, ya que el mecanismo 6to4 está en desuso desde mayo de 2015. [32] Aunque el bloque de direcciones IPv4 192.88.99.0 / 24 está en desuso, 2002 :: / 16 es no.
- En abril de 2007, se asignó el bloque de direcciones 2001: 10 :: / 28 para identificadores hash criptográficos enrutables superpuestos (ORCHID). [55] Estaba destinado a un uso experimental. En septiembre de 2014 se especificó una segunda versión de ORCHID, [30] y con la introducción del bloque 2001: 20 :: / 28, el bloque original se devolvió a IANA .
Diverso
- 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, la Junta de Arquitectura de Internet (IAB) revirtió esta intención y decidió en 2001 que arpa debería conservar su función original. Los dominios en ip6.int se trasladaron a ip6.arpa [56] y la zona ip6.int se eliminó oficialmente el 6 de junio de 2006.
- En marzo de 2011, el IETF perfeccionó las recomendaciones para la asignación de bloques de direcciones a los sitios finales. [21] En lugar de asignar un / 48 , / 64 o / 128 (según las opiniones de IAB e IESG de 2001), [57] los proveedores de servicios de Internet deberían considerar la posibilidad de asignar bloques más pequeños (por ejemplo, a / 56 ) a los usuarios finales. Las políticas de los registros regionales de ARIN , RIPE y APNIC fomentan las asignaciones de / 56 cuando corresponda. [21]
- Originalmente, existían dos propuestas para traducir nombres de dominio a direcciones IPv6: una usando registros AAAA, [58] la otra usando registros A6. [59] Los registros AAAA, el método que prevaleció, son comparables a los registros A para IPv4, proporcionando un mapeo simple del nombre de host a la dirección IPv6. El método que utiliza registros A6 utilizó un esquema jerárquico, en el que el mapeo de los grupos subsiguientes de bits de dirección se especificaba mediante registros A6 adicionales, lo que brinda la posibilidad de volver a numerar todos los hosts de una red cambiando un solo registro A6. Como no se consideró que los beneficios percibidos del formato A6 superaran los costos percibidos, [60] [61] [62] [63] el método pasó a estado experimental en 2002, [61] y finalmente a estado histórico en 2012. [63]
- En 2009, se descubrió que muchos solucionadores de DNS en enrutadores y dispositivos NAT de redes domésticas manejaban registros AAAA de manera incorrecta. [64] Algunos de estos simplemente eliminaron las solicitudes de DNS para dichos registros, en lugar de devolver correctamente la respuesta negativa de DNS adecuada. Debido a que la solicitud se descarta, el host que envía la solicitud tiene que esperar a que se active un tiempo de espera. Esto a menudo provoca una ralentización al conectarse a hosts IPv6 / IPv4 de doble pila, ya que el software cliente esperará a que falle la conexión IPv6 antes de intentar IPv4.
Referencias
- ^ a b c d e f g h i R. Hinden; S. Deering (febrero de 2006). Arquitectura de direccionamiento IP versión 6 . Grupo de trabajo en red. doi : 10.17487 / RFC4291 . RFC 4291 . Actualizado por: RFC 5952, RFC 6052, RFC 7136, RFC 7346, RFC 7371, RFC 8064.
- ^ Silvia Hagen (mayo de 2006). IPv6 Essentials (segunda ed.). O'Reilly. ISBN 978-0-596-10058-2.
- ^ a b 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 en red. doi : 10.17487 / RFC3956 . RFC 3956 .
- ^ a b B. Haberman; D. Thaler (agosto de 2002). Direcciones de multidifusión IPv6 basadas en prefijo unidifusión . Grupo de trabajo en red. doi : 10.17487 / RFC3306 . RFC 3306 .
- ^ JS. Parque; MK. Espinilla; HJ. Kim (abril de 2006). Un método para generar direcciones de multidifusión IPv6 con alcance de enlace . Grupo de trabajo en red. doi : 10.17487 / RFC4489 . RFC 4489 .
- ^ Graziani, Rick (2012). Fundamentos de IPv6: un enfoque sencillo para comprender IPv6 . Prensa de Cisco . pag. 55. ISBN 978-0-13-303347-2.
- ^ Coffeen, Tom (2014). Planificación de direcciones IPv6: diseño de un plan de direcciones para el futuro . O'Reilly Media . pag. 170. ISBN 978-1-4919-0326-1.
- ^ S. Kawamura; M. Kawashima (agosto de 2010). Una recomendación para la representación de texto de direcciones IPv6 . IETF . doi : 10.17487 / RFC5952 . ISSN 2070-1721 . RFC 5952 .
- ^ 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 .
- ^ a b S. Deering ; B. Haberman; T. Jinmei; E. Nordmark; B. Zill (marzo de 2005). Arquitectura de direcciones de ámbito IPv6 . Grupo de trabajo en red. doi : 10.17487 / RFC4007 . RFC 4007 .
- ^ Representación de identificadores de zona IPv6 en literales de direcciones e identificadores uniformes de recursos . Tools.ietf.org. Consultado el 9 de julio de 2013.
- ^ "Historial del dominio ipv6-literal.net" . quien.es . Consultado el 20 de octubre de 2014 .
- ^ "Zonas de alcance" . Centro de conocimiento de IBM . 27 de septiembre de 2013 . Consultado el 13 de diciembre de 2019 .
Los paquetes que contienen una dirección de origen o destino de un ámbito determinado se pueden enrutar solo dentro de la misma zona de alcance y no se pueden enrutar entre diferentes instancias de la zona de alcance.
- ^ R Droms (agosto de 2014). Ámbitos de direcciones de multidifusión IPv6 . IETF . doi : 10.17487 / RFC7346 . ISSN 2070-1721 . RFC 7346 .
- ^ Gestión de asignación de direcciones IPv6 . Grupo de trabajo en red, IETF . Diciembre de 1995. doi : 10.17487 / RFC1881 . RFC 1881 .
- ^ Espacio de direcciones IPv6 en IANA . Iana.org (29 de octubre de 2010). Consultado el 28 de septiembre de 2011.
- ^ Asignaciones de direcciones de unidifusión IPv6 , IANA
- ^ DE-TELEKOM-20050113 db.ripe.net. Consultado el 28 de septiembre de 2011.
- ^ "Manual de políticas de recursos numéricos ARIN: asignación inicial a los ISP" .
- ^ "Política de asignación y asignación de direcciones RIPE NCC IPv6: asignación mínima" .
- ^ a b c T. Narten; G. Houston; L. Roberts (marzo de 2011). Asignación de direcciones IPv6 a sitios finales . IETF . doi : 10.17487 / RFC6177 . BCP 157. RFC 6177 .
- ^ por ejemplo . Iana.org. Consultado el 28 de septiembre de 2011.
- ^ "Planes de direccionamiento IPv6" . Wiki de ARIN IPv6 . Consultado el 15 de julio de 2018 .
Todos los clientes obtienen una / 48 a menos que puedan demostrar que necesitan más de 65k subredes. [...] Si tiene muchos clientes consumidores, es posible que desee asignar / 56 s a sitios residenciales privados.
- ^ "Espacio de direcciones gestionado por el RIPE NCC" . Consultado el 22 de mayo de 2011 .
- ^ D. Johnson; S. Deering (marzo de 1999). Direcciones Anycast de subred IPv6 reservadas . Grupo de trabajo en red. doi : 10.17487 / RFC2526 . RFC 2526 .
- ^ a b M. Cotton; L. Vegoda; R. Bonica; B. Haberman (abril de 2013). Registros de direcciones IP para fines especiales . Grupo de trabajo de ingeniería de Internet . doi : 10.17487 / RFC6890 . BCP 153. RFC 6890 . Actualizado por RFC 8190.
- ^ a b C. Bao; C. Huitema; M. Bagnulo; M. Boucadair; X. Li (octubre de 2010). Direccionamiento IPv6 de traductores IPv4 / IPv6 . Grupo de trabajo de ingeniería de Internet . doi : 10.17487 / RFC6052 . RFC 6052 .
- ^ a b 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 . RFC 6666 .
- ^ RFC 4680
- ^ a b c J. Laganier; F. Dupont (septiembre de 2014). Un prefijo IPv6 para identificadores hash criptográficos enrutables superpuestos versión 2 (ORCHIDv2) . Grupo de trabajo de ingeniería de Internet . doi : 10.17487 / RFC7343 . RFC 7343 .
- ^ a b G. Huston; A. Señor; P. Smith (julio de 2004). Prefijo de dirección IPv6 Reservado para documentación . Grupo de trabajo en red. doi : 10.17487 / RFC3849 . RFC 3849 .
- ^ a b c O. Troan (mayo de 2015). B. Carpenter (ed.). Desactivación 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 .
- ^ a b c d R. Hinden; B. Haberman (octubre de 2005). Direcciones de unidifusión IPv6 locales únicas . Grupo de trabajo en red. doi : 10.17487 / RFC4193 . RFC 4193 .
- ^ C. Bao; X. Li; F. Baker ; T. Anderson; F. Gont (junio de 2016). Algoritmo de traducción IP / ICMP sin estado . doi : 10.17487 / RFC7915 . RFC 7915 .
- ^ R. Hinden; S. Deering ; R. Fink; T. Hain (septiembre de 2000). Asignaciones iniciales de ID de Sub-TLA de IPv6 . Grupo de trabajo en red. doi : 10.17487 / RFC2928 . RFC 2928 .
- ^ 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 en red. doi : 10.17487 / RFC5180 . RFC 5180 .
- ^ 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 .
- ^ Direcciones de multidifusión de la versión 6 del protocolo de Internet de IANA .
- ^ S. Thomson; T. Narten; T. Jinmei (septiembre de 2007). Autoconfiguración de direcciones IPv6 sin estado . Grupo de trabajo en red. doi : 10.17487 / RFC4862 . RFC 4862 .
- ^ T. Narten; E. Nordmark; W. Simpson; H. Holiman (septiembre de 2007). Vecino Discovery para IP versión 6 (IPv6) . Grupo de trabajo en red. doi : 10.17487 / RFC4861 . RFC 4861 .
- ^ Iljitsch van Beijnum (2006). "Internos de IPv6" . El diario de protocolo de Internet . 9 (3). págs. 16-29.
- ^ Las implicaciones de privacidad del direccionamiento IPv6 sin estado . Portal.acm.org (21 de abril de 2010). Consultado el 28 de septiembre de 2011.
- ^ T. Narten; R. Draves; S. Krishnan (septiembre de 2007). Extensiones de privacidad para la configuración automática de direcciones sin estado en IPv6 . Grupo de trabajo en red. doi : 10.17487 / RFC4941 . RFC 4941 .
- ^ T. Aura (marzo de 2005). Direcciones generadas criptográficamente (CGA) . Grupo de trabajo en red IETF . doi : 10.17487 / RFC3972 . RFC 3972 .
- ^ F. Gont (abril de 2014). Un método para generar identificadores de interfaz semánticamente opacos con autoconfiguración de direcciones sin estado IPv6 (SLAAC) . IETF . doi : 10.17487 / RFC7217 . ISSN 2070-1721 . RFC 7217 .
- ^ a b 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 .
- ^ S. Thomson; C. Huitema; V. Ksinant; M. Souissi (octubre de 2003). Extensiones de DNS para admitir la versión 6 de IP . Grupo de trabajo en red. doi : 10.17487 / RFC3596 . RFC 3596 .
- ^ a b R. Hinden; S. Deering (diciembre de 1995). Arquitectura de direccionamiento IP versión 6 . Grupo de trabajo en red. doi : 10.17487 / RFC1884 . RFC 1884 .
- ^ C. Huitema; B. Carpenter (septiembre de 2004). Desactivación de direcciones locales del sitio . Grupo de trabajo en red. doi : 10.17487 / RFC3879 . RFC 3879 .
- ^ G. Houston (agosto de 2005). Cambios propuestos al formato del registro IANA IPv6 . Grupo de trabajo en red. doi : 10.17487 / RFC4147 . RFC 4147 .
- ^ J. Bound; B. Carpintero; D. Harrington; J. Houldsworth; A. Lloyd (agosto de 1996). OSI NSAP e IPv6 . Grupo de trabajo en red. doi : 10.17487 / RFC1888 . RFC 1888 . Obsoleto por RFC 4048.
- ^ B. Carpenter (abril de 2005). RFC 1888 es obsoleto . doi : 10.17487 / RFC4048 . RFC 4048 .
- ^ a b R. Hinden; R. Fink; J. Postel (diciembre de 1998). Asignación de direcciones de prueba IPv6 . doi : 10.17487 / RFC2471 . RFC 2471 . Obsoleto por RFC 3701.
- ^ R. Fink; R. Hinden (marzo de 2004). Eliminación gradual de 6bone (asignación de direcciones de prueba IPv6) . Grupo de trabajo en red. doi : 10.17487 / RFC3701 . RFC 3701 .
- ^ P. Nikander; J. Laganier; F. Dupont (abril de 2007). Un prefijo IPv6 para identificadores hash criptográficos enrutables superpuestos (ORCHID) . Grupo de trabajo en red. doi : 10.17487 / RFC4843 . RFC 4843 .
- ^ R. Bush (agosto de 2001). Delegación de IP6.ARPA . doi : 10.17487 / RFC3152 . RFC 3152 . Obsoleto por RFC 3596
- ^ IAB ; IESG (septiembre de 2001). Recomendaciones de IAB / IESG sobre asignaciones de direcciones IPv6 a sitios . doi : 10.17487 / RFC3177 . RFC 3177 .
- ^ S. Thomson; C. Huitema (diciembre de 1995). Extensiones de DNS para admitir IP versión 6 . Grupo de trabajo en red. doi : 10.17487 / RFC1886 . RFC 1886 . Obsoleto por RFC 3596.
- ^ M. Crawford; C. Huitema (julio de 2000). Extensiones de DNS para admitir la agregación y renumeración de direcciones IPv6 . doi : 10.17487 / RFC2874 . RFC 2874 .
- ^ Comparación de AAAA y A6 (¿realmente necesitamos A6?) , Jun-ichiro itojun Hagino, (julio de 2001)
- ^ a b R. Bush; A. Durand; B. Fink; O. Gudmundsson; T. Hain (agosto de 2002). Representación de direcciones de Protocolo de Internet versión 6 (IPv6) en el Sistema de nombres de dominio (DNS) . Grupo de trabajo en red. doi : 10.17487 / RFC3363 . RFC 3363 ..
- ^ R. Austein (agosto de 2002). Compensaciones en la compatibilidad con el sistema de nombres de dominio (DNS) para el protocolo de Internet versión 6 (IPv6) . Grupo de trabajo en red. doi : 10.17487 / RFC3364 . RFC 3364 .
- ^ a b S. Jiang; D. Conrad; B. Carpenter (marzo de 2012). Moviendo A6 al estado histórico . IETF . doi : 10.17487 / RFC6536 . RFC 6536 .
- ^ Y. Morishita; T. Jinmei (mayo de 2005). Mal comportamiento común frente a consultas DNS para direcciones IPv6 . doi : 10.17487 / RFC4074 . RFC 4074 .
enlaces externos
- Direcciones de multidifusión IP versión 6
- Beijnum, van, Iljitsch (2005). Ejecutando IPv6 . ISBN 978-1-59059-527-5.
- Elz, Robert (1 de abril de 1996). Una representación compacta de direcciones IPv6 (RFC1924) . IETF . doi : 10.17487 / RFC1924 . RFC 1924 .
Representa cualquier dirección IPv6 en 20 octetos.
Este RFC humorístico especifica una forma alternativa de representar direcciones IPv6, utilizando una codificación base-85.