stringtranslate.com

Dirección IPv6

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.

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 .

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.

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.

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.

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 .

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.

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]

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:

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:

Direcciones unicast

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

Direcciones locales únicas

Transición desde IPv4

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:

Documentación

Desechar

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]

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:

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.

Notas históricas

Direcciones obsoletas y en desuso

Misceláneas

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.

Enlaces externos