stringtranslate.com

dirección IPv6

Descomposición de una dirección IPv6 en su forma binaria

Una dirección del 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 una computadora o un nodo de red que participa en una red de computadoras 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 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 las redes: direccionamiento unicast, 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 solo a 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 dirección de difusión directa.

Una dirección de multidifusión también es utilizada por múltiples 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 direccionamiento de difusión . La función tradicional de la transmisión está incluida en 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 utilizando reglas establecidas para asociar los valores de estos grupos de bits con características de direccionamiento especiales.

Formato de dirección unidifusión y anycast

Las direcciones unidifusión y anycast normalmente se componen de dos partes lógicas: un prefijo de red de 64 bits utilizado para el 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 más pequeño. Los bits del campo ID de subred están disponibles para que el administrador de la red defina subredes dentro de la red determinada. 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 redes privadas IPv4 .

El campo de prefijo contiene el valor binario 1111110. El bit L es para 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 ( fe80:: / 64 prefijo de dirección local de enlace), lo que las hace no enrutables.

Formato de dirección de multidifusión

Las direcciones de multidifusión se forman según 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 nodos solicitados 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 de cualquier difusión 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 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 al máximo. 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 o flujos de texto, y comparar 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 dar lugar a representaciones muy breves de direcciones IPv6. Por ejemplo, la dirección localhost (bucle invertido), 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 conocida notación de punto decimal de IPv4 , 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 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 principal 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 están escritos en notación CIDR . Una red se indica con la primera dirección del bloque (que termina completamente en ceros), una barra diagonal (/) 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 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 diagonal (/) seguida de un número en decimal cuyo valor es la longitud del prefijo de la red en bits. Por ejemplo, un bloque de direcciones con 48 bits en el prefijo se indica con / 48 . Un bloque de este tipo 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 caracteres de 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 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 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 alcance (con índice de zona)

Para direcciones con un alcance distinto al global (como se describe en § Alcances de direcciones), y en particular para direcciones de enlace local, la elección de la interfaz de red para enviar un paquete puede depender de a qué zona pertenece la dirección. La misma dirección puede ser válida en diferentes zonas y ser utilizada 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 pueden seguir siendo idénticos, lo que hace que el sistema operativo no pueda seleccionar una interfaz saliente basándose en la información de la tabla de enrutamiento (que es prefijo- basado).

Para resolver la ambigüedad en las direcciones textuales, seEl índice de zona debe agregarse 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 compatibles universalmente, el índice de zona también puede ser una cadena dependiente de la implementación. La dirección de enlace local

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 (usar un nombre de interfaz ) es habitual en la mayoría de los sistemas operativos tipo Unix (por ejemplo, BSD , Linux , macOS ). [12] Esta última (que utiliza un número de interfaz) es la única sintaxis en Microsoft Windows , pero como la compatibilidad con esta sintaxis es obligatoria según el 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, donde 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 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 realmente 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, se debe escapar 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 tanto, el uso de direcciones IPv6 también es ilegal en nombres UNC. Por este motivo, Microsoft implementó un algoritmo de transcripción para representar una dirección IPv6 en forma de nombre de dominio que se puede utilizar en rutas UNC. Para ello, 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

se escribe como

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

Esta notación la resuelve automáticamente el software de Microsoft de forma local, sin necesidad de realizar consultas 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

se escribe 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 direcciones de unidifusión , se definen dos ámbitos: enlace local y global.

Las direcciones de enlace local y la dirección de bucle invertido tienen un alcance de enlace local , lo que significa que solo se pueden utilizar en una única red conectada directamente. Todas las demás direcciones (incluidas las direcciones locales únicas ) tienen 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 de enlace local en la red conectada directamente. .

Las direcciones locales únicas tienen alcance global, pero no se administran globalmente. Como resultado, sólo otros hosts en el mismo dominio administrativo (por ejemplo, una organización) o dentro de un dominio administrativo cooperante pueden llegar a dichas direcciones, si se enrutan adecuadamente. Como su alcance es global, estas direcciones son válidas como 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.

cualquier transmisión

Las direcciones anycast son sintácticamente idénticas e indistinguibles de las direcciones unicast. Su única diferencia es administrativa. Por lo tanto, los alcances para las direcciones anycast son los mismos que para 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 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 se delega a la Autoridad de Números Asignados de Internet (IANA) [16] 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 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. [17]

Para permitir una agregación de rutas eficiente y reducir así el tamaño de las tablas de enrutamiento de Internet, actualmente solo se asigna para su uso en Internet una octava parte del espacio total de direcciones ( 2000:: / 3 ) . 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 bloques de / 23 hasta / 12 . [18]

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

Luego, las direcciones generalmente se distribuyen en bloques de tamaño / 48 a / 56 a los usuarios finales. [23] 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 / 8 bloques de direcciones IPv4, que son las asignaciones más grandes de direcciones IPv4. El conjunto total, sin embargo, es suficiente en el futuro previsible, porque hay 2.128 ( exactamente 340.282.366.920.938.463.463.374.607.431.768.211.456) o alrededor de3,4 × 10 38 (340 undecillones ) de direcciones IPv6 únicas.

Cada RIR puede dividir cada uno de sus múltiples / 23 bloques 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 desde su bloque asignado / 48 , cada una con 2 64 (18,446,744,073,709,551,616) direcciones. Por el contrario, todo el espacio de direcciones IPv4 tiene sólo 2 32 (exactamente 4.294.967.296 o aproximadamente4,3 × 10 9 ) direcciones.

Por diseño, sólo 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 traducción de direcciones de red (NAT) con fines de conservación de direcciones. NAT se ha utilizado cada vez más en redes IPv4 para ayudar a aliviar el agotamiento de las direcciones IPv4 .

Asignación especial

Los RIR asignan el espacio de direcciones independiente del proveedor directamente al usuario final desde el rango especial 2001:678:: / 29 y permite a los clientes realizar cambios de proveedor sin tener que volver a numerar 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 la comunicación 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 todo en ceros) se reserva como 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, seguidos por el ID anycast de 7 bits. Los prefijos de la red pueden tener cualquier longitud a efectos 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 domésticos IPv6 móviles . La dirección con valor 0x7f (todos los bits 1) está reservada y no puede utilizarse. No se han realizado más asignaciones de este rango, por lo que los valores del 0x00 al 0x7d también están reservados.

Direcciones especiales

Hay una serie de direcciones con un significado especial en IPv6. [28] Representan menos del 2% de todo el espacio de direcciones:

Direcciones de unidifusión

Dirección no especificada

Las aplicaciones pueden escuchar en una o más interfaces específicas las conexiones entrantes, que se muestran en 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 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 (unidifusión, multidifusión y otras) no especificadas en otra parte de una tabla de enrutamiento.

Direcciones locales

Direcciones locales únicas

Transición desde IPv4

Direcciones de propósito especial

IANA ha reservado un bloque de direcciones de ID Sub-TLA para asignaciones especiales [28] [38] 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:

Documentación

Desechar

Obsoleto y obsoleto

Ver § 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 administradas por la Autoridad de Números Asignados de Internet (IANA). [41]

Dirección de multidifusión del 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 unicast o anycast de la interfaz. Estas direcciones permiten la resolución de direcciones de capa de enlace a través del Protocolo de descubrimiento de vecinos (NDP) en el enlace sin perturbar 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 unicast o anycast configuradas.

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

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 o se 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 configuración automática de direcciones sin estado (SLAAC), [42] 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. [43]

Identificador de interfaz

Los 64 bits inferiores de estas direcciones se completan con un identificador de interfaz de 64 bits. Este debería 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 es necesario unir varios grupos de multidifusión para el descubrimiento de vecinos. Para ello se utiliza una dirección multicast, 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 un 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 para determinar la unicidad de esa dirección mediante mensajes de solicitud de vecino y anuncio de vecino ( ICMPv6 tipo 135 y 136). Mientras se encuentra en el proceso de establecer la 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 y envía solicitudes vecinas, 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 , para que pueda recibir anuncios de vecinos .

Si un nodo recibe una solicitud de vecino con su propia dirección tentativa como dirección de destino, entonces su dirección no es única. Lo mismo ocurre si el nodo recibe un anuncio de vecino con la dirección provisional como fuente del anuncio. Sólo después de haber establecido con éxito que una dirección es única podrá ser asignada y utilizada por una interfaz.

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

Duración de la dirección

Cada dirección IPv6 vinculada a una interfaz tiene una vida útil definida. La vida útil es infinita, a menos que se configure para 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 . [44] La vida útil se puede configurar en enrutadores que proporcionan los valores utilizados para la configuración automática, o se pueden especificar al configurar manualmente 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 expire esa vida útil, el estado quedará 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; 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, utilizadas por la configuración automática 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 lo tanto, de los usuarios. [45] 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 [46] y vidas útiles relativamente cortas (de horas a días). después de lo cual se reemplazan con nuevas direcciones.

Las direcciones temporales se pueden usar como direcciones de origen para las conexiones de origen, mientras que los hosts externos usan una dirección pública consultando 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, en 2005 se introdujeron direcciones generadas criptográficamente (o CGA) [47] como parte del Protocolo de descubrimiento seguro de vecinos (SEND).

Dicha dirección se genera mediante dos funciones hash que requieren varias entradas. El primero utiliza 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 la 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 cumple con el requisito de ser un CGA válido. De esta manera, la comunicación se puede establecer exclusivamente entre direcciones confiables.

Direcciones de privacidad estables

El uso del formato EUI-64 modificado tiene serias implicaciones para la seguridad y la privacidad, [48] porque la dirección de hardware subyacente (generalmente la dirección MAC ) está expuesta más allá de la red local, lo que permite el seguimiento de las actividades del usuario y la correlación de sus datos. cuentas a 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.

Se introdujeron direcciones de privacidad estables para remediar estas deficiencias. Son estables dentro de una red específica pero cambian al pasar 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 con el 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 expire una determinada vida útil. IPv6 introduce los conceptos de alcance de direcciones 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 selecciona la dirección más apropiada para usar en las comunicaciones con un destino particular, incluido el uso de direcciones asignadas IPv4 en implementaciones de doble pila . [49] 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 prefiere la comunicación de enlace local a las rutas enrutadas globalmente cuando, por lo demás, es igualmente adecuada. La tabla de políticas de prefijo es similar a una tabla de enrutamiento, donde el valor de precedencia cumple la función del costo del enlace, donde una preferencia más alta se expresa como un valor mayor. Es preferible que las direcciones de origen tengan el mismo valor de etiqueta que la dirección de destino. Las direcciones se relacionan con prefijos basados ​​en la secuencia de bits más significativa y 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 ideó el algoritmo Happy Eyeballs . Consulta el sistema de nombres de dominio para 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 aborta 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 . [50] 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.

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, una computadora host llamada 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.ejemplo.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.0.4.0.0.0.3.2.0.0.1.cc5.addfip6.arpa. EN PTR derrick.example.com.

Este registro 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 podrán transmitirse a través de transportes IPv6 o IPv4 independientemente de la familia de direcciones de los datos solicitados.

Notas históricas

Direcciones obsoletas y obsoletas

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 if_nametoindex()API RFC 3493 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 ahora eliminadas de fec0::/10 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 . [40]
  6. ^ Cuando este EUI-64 se utiliza 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).
  7. ^ En la mayoría de los casos, la vida útil no caduca porque los nuevos anuncios de enrutador (RA) actualizan los temporizadores. Pero si no hay más RA, eventualmente la vida útil preferida transcurre y la dirección queda obsoleta .

Referencias

  1. ^ abcdefghi R. Hinden; S. Deering (febrero de 2006). Arquitectura de direccionamiento IP versión 6. Grupo de Trabajo de Red. doi : 10.17487/RFC4291 . RFC 4291. Proyecto de Norma. Obsoletos RFC 3513. Actualizado por RFC 5952, 6052, 7136, 7346, 7371 y 8064.
  2. ^ ab F. Gont; A. Cooper; D. Tálero; W. Liu (febrero de 2017). Recomendación sobre identificadores de interfaz IPv6 estables. 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). Incrustar la dirección del punto de encuentro (RP) en una dirección de multidifusión IPv6. Grupo de Trabajo de Red. doi : 10.17487/RFC3956 . RFC 3956. Norma propuesta. Actualizado por RFC 7371. Actualizaciones 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 Red. doi : 10.17487/RFC3306 . RFC 3306. Norma propuesta. Actualizado por RFC 3956, 4489 y 7371.
  6. ^ JS. Parque; mk. Espinilla; HJ. Kim (abril de 2006). Un método para generar direcciones de multidifusión IPv6 con ámbito de enlace. Grupo de Trabajo de Red. doi : 10.17487/RFC4489 . RFC 4489. Norma propuesta. Actualiza RFC 3306.
  7. ^ Graziani, Rick (2012). Fundamentos de IPv6: un enfoque sencillo para comprender IPv6. Prensa de Cisco . pag. 55.ISBN _ 978-0-13-303347-2.
  8. ^ Café, Tom (2014). Planificación de direcciones IPv6: diseño de un plan de direcciones para el futuro. Medios O'Reilly . pag. 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. Actualiza RFC 4291.
  10. ^ T. Berners-Lee ; R. Fielding ; L. Masinter (enero de 2005). Identificador uniforme de recursos (URI): sintaxis genérica. Grupo de Trabajo de Red. doi : 10.17487/RFC3986 . ETS 66. RFC 3986. Estándar de Internet 66. Obsoletos RFC 2732, 2396 y 1808. Actualizado por RFC 6874, 7320 y 8820. Actualiza RFC 1738.
  11. ^ ab S. Deering ; B. Haberman; T. Jinmei; E. Nordmark; B. Zill (marzo de 2005). Arquitectura de direcciones con alcance IPv6. Grupo de Trabajo de Red. doi : 10.17487/RFC4007 . RFC 4007. Norma propuesta. Actualizado por RFC 7346.
  12. ^ ab inet6(4) -  Manual de interfaces del kernel de FreeBSD "La implementación de KAME admite una notación de dirección IPv6 numérica extendida para direcciones de enlace local, como" fe80::1%de0" [...] draft-ietf-ipngwg-scopedaddr-format-02. TXT"
  13. ^ B. Carpintero ; 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. Actualiza RFC 3986.
  14. ^ "Historial de dominio ipv6-literal.net". quién es . 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. ^ Junta de Arquitectura de Internet ; Grupo Directivo de Ingeniería de Internet (diciembre de 1995). Gestión de asignación de direcciones IPv6. Grupo de Trabajo de Red. doi : 10.17487/RFC1881 . RFC 1881. Informativo.
  17. ^ Espacio de direcciones IPv6 en IANA. Iana.org (29 de octubre de 2010). Recuperado el 28 de septiembre de 2011.
  18. ^ Asignaciones de direcciones de unidifusión 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 numéricos ARIN: asignación inicial a los ISP".
  21. ^ "Política de asignación y asignació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. Houston; 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. Mejores prácticas comunes. Obsoleto RFC 3177.
  24. ^ "Planes de direccionamiento IPv6". Wiki ARIN IPv6 . Consultado el 15 de julio de 2018 . Todos los clientes obtienen uno / 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.
  25. ^ "¿Qué son los bogones?" . Consultado el 15 de noviembre de 2021 .
  26. ^ "Espacio de direcciones gestionado por RIPE NCC" . Consultado el 22 de mayo de 2011 .
  27. ^ D. Johnson; S. Deering (marzo de 1999). Direcciones Anycast de subred IPv6 reservadas. Grupo de Trabajo de Red. doi : 10.17487/RFC2526 . RFC 2526. Norma propuesta.
  28. ^ ab M. Algodón; L.Vegoda; B. Haberman (abril de 2013). R. Bonica (ed.). Registros de direcciones IP de propósito especial. IETF . doi : 10.17487/RFC6890 . ISSN  2070-1721. BCP 153. RFC 6890. Mejores prácticas comunes. Obsoletos RFC 4773, 5156, 5735 y 5736. Actualizado por RFC 8190.
  29. ^ ab C. Bao; C.Huitema ; M. Bagnulo; el señor Boucadair; X. Li (octubre de 2010). Direccionamiento IPv6 de traductores IPv4/IPv6. IETF . doi : 10.17487/RFC6052 . ISSN  2070-1721. RFC 6052. Norma propuesta. Actualiza RFC 4291.
  30. ^ 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.
  31. ^ ab N. Hilliard; D. Freedman (agosto de 2012). Un prefijo descartado para IPv6. Grupo de Trabajo de Ingeniería de Internet . doi : 10.17487/RFC6666 . ISSN  2070-1721. RFC 6666. Informativo.
  32. ^ S. Santesson (septiembre de 2006). Mensaje de protocolo de enlace TLS para datos complementarios. Grupo de Trabajo de Red. doi : 10.17487/RFC4680 . RFC 4680. Norma propuesta. Actualiza RFC 4346. Actualizado por RFC 8447 y 8996.
  33. ^ abc 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 . ISSN  2070-1721. RFC 7343. Norma propuesta. Obsoleto RFC 4843.
  34. ^ ab G. Houston; R. Señor; P. Smith (julio de 2004). Prefijo de dirección IPv6 reservado para documentación. Grupo de Trabajo de Red. doi : 10.17487/RFC3849 . RFC 3849. Informativo.
  35. ^ abc O. Troan (mayo de 2015). B. Carpintero (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. Obsoletos RFC 3068 y 6732.
  36. ^ abcd R. Hinden; B. Haberman (octubre de 2005). Direcciones unidifusión IPv6 locales únicas. Grupo de Trabajo de Red. doi : 10.17487/RFC4193 . RFC 4193. Norma propuesta.
  37. ^ C. Bao; X. Li; F. panadero ; 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. Obsoleto RFC 6145.
  38. ^ R. Hinden; S. Deering ; R. Fink; T. Hain (septiembre de 2000). Asignaciones iniciales de ID sub-TLA de IPv6. Grupo de Trabajo de Red. doi : 10.17487/RFC2928 . RFC 2928. Informativo.
  39. ^ 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 redes. Grupo de Trabajo de Red. doi : 10.17487/RFC5180 . RFC 5180. Informativo.
  40. ^ J. Arkko; M. Algodón; 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. Actualiza RFC 1166.
  41. ^ Direcciones de multidifusión del protocolo de Internet de la IANA versión 6.
  42. ^ S. Thomson; T. Narten; T. Jinmei (septiembre de 2007). Autoconfiguración de direcciones IPv6 sin estado. Grupo de Trabajo de Red. doi : 10.17487/RFC4862 . RFC 4862. Proyecto de Norma. Obsoleto RFC 2462. Actualizado por RFC 7527.
  43. ^ T.Narten; E. Nordmark; W. Simpson; H. Holiman (septiembre de 2007). Descubrimiento de vecinos para IP versión 6 (IPv6). Grupo de Trabajo de Red. doi : 10.17487/RFC4861 . RFC 4861. Proyecto de Norma. Obsoletos RFC 2461. Actualizado por RFC 5942, 6980, 7048, 7527, 7559, 8028, 8319, 8425 y 9131.
  44. ^ Iljitsch van Beijnum (2006). "Partes internas de IPv6". La revista del protocolo de Internet . vol. 9, núm. 3. págs. 16-29.
  45. ^ Las implicaciones para la privacidad del direccionamiento IPv6 sin estado. Portal.acm.org (21 de abril de 2010). Recuperado el 28 de septiembre de 2011.
  46. ^ F. Gont; S. Krishnan; T. Narten; R. Draves (febrero de 2021). Extensiones de dirección temporales para la configuración automática 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. Obsoleto RFC  4941.
  47. ^ T. Aura (marzo de 2005). Direcciones generadas criptográficamente (CGA). Grupo de Trabajo de Red. doi : 10.17487/RFC3972 . RFC 3972. Norma propuesta. Actualizado por RFC 4581 y 4982.
  48. ^ 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.
  49. ^ D. Tálero; 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. Obsoleto RFC 3484.
  50. ^ S. Thomson; C.Huitema; V. Ksinant; M. Souissi (octubre de 2003). Extensiones de DNS para admitir IP versión 6. Grupo de trabajo de red. doi : 10.17487/RFC3596 . RFC 3596. Estándar de Internet. Obsoletos RFC 3152 y 1886.
  51. ^ ab R. Hinden; S. Deering (diciembre de 1995). Arquitectura de direccionamiento IP versión 6. Grupo de Trabajo de Red. doi : 10.17487/RFC1884 . RFC 1884. Obsoleto. Obsoleto por RFC 2373.
  52. ^ C.Huitema ; B. Carpenter (septiembre de 2004). Desuso de direcciones locales del sitio. Grupo de Trabajo de Red. doi : 10.17487/RFC3879 . RFC 3879. Norma propuesta.
  53. ^ G. Houston (agosto de 2005). Cambios propuestos al formato del Registro IPv6 de IANA. Grupo de Trabajo de Red. doi : 10.17487/RFC4147 . RFC 4147. Informativo.
  54. ^ J. Encuadernado; B. Carpintero; D. Harrington; J. Houldsworth; A. Lloyd (agosto de 1996). NSAP OSI e IPv6. Grupo de Trabajo de Red. doi : 10.17487/RFC1888 . RFC 1888. Obsoleto. Obsoleto por RFC 4048. Actualizado por RFC  4548.
  55. ^ B. Carpenter (abril de 2005). RFC 1888 está obsoleto. doi : 10.17487/RFC4048 . RFC 4048. Informativo. Actualizado por RFC 4548.
  56. ^ R. Hinde; R. Fink; J. Postel (diciembre de 1998). Asignación de direcciones de prueba IPv6. Grupo de Trabajo en Red. doi : 10.17487/RFC2471 . RFC 2471. Obsoleto. Obsoleto por RFC 3701. Obsoleto por RFC 1897.
  57. ^ R. Fink; R. Hinden (marzo de 2004). Eliminación progresiva de 6bone (asignación de direcciones de prueba IPv6). Grupo de Trabajo de Red. doi : 10.17487/RFC3701 . RFC 3701. Informativo. Obsoleto RFC 2471.
  58. ^ P. Nikander; J. Laganier; F. Dupont (abril de 2007). Un prefijo IPv6 para identificadores hash criptográficos enrutables superpuestos (ORCHID). Grupo de Trabajo de Red. doi : 10.17487/RFC4843 . RFC 4843. Obsoleto. Obsoleto por RFC 7343.
  59. ^ R. Bush (agosto de 2001). Delegación de IP6.ARPA. Grupo de Trabajo de Red. doi : 10.17487/RFC3152 . BCP 49. RFC 3152. Obsoleto. Obsoleto por RFC 3596. Actualizaciones RFC 1886, 2553, 2766, 2772 y 2874
  60. ^ IAB ; IESG (septiembre de 2001). Recomendaciones de IAB/IESG sobre asignaciones de direcciones IPv6 a sitios. Grupo de Trabajo de Red. doi : 10.17487/RFC3177 . RFC 3177. Obsoleto. Obsoleto por RFC 6177.
  61. ^ S. Thomson; C. Huitema (diciembre de 1995). Extensiones DNS para soportar IP versión 6. Grupo de Trabajo de Red. doi : 10.17487/RFC1886 . RFC 1886. Obsoleto. Obsoleto por RFC  3596. Actualizado por RFC 2874 y 3152.
  62. ^ M. Crawford; C. Huitema (julio de 2000). Extensiones de DNS para admitir la agregación y renumeración de direcciones IPv6. Grupo de Trabajo de Red. doi : 10.17487/RFC2874 . RFC 2874. Histórico. Actualizado por RFC 3152, 3226, 3363 y 3364. Actualizaciones RFC 1886.
  63. ^ Comparación de AAAA y A6 (¿realmente necesitamos A6?), Jun-ichiro itojun Hagino, (julio de 2001)
  64. ^ ab R. Bush; A. Durand; B. Fink; O. Gudmundsson; T. Hain, eds. (Agosto de 2002). Representa direcciones del Protocolo de Internet versión 6 (IPv6) en el Sistema de nombres de dominio (DNS). Grupo de Trabajo de Red. doi : 10.17487/RFC3363 . RFC 3363. Informativo. Actualizaciones RFC 2673, 2874.
  65. ^ R. Austein (agosto de 2002). Compensaciones en el soporte del sistema de nombres de dominio (DNS) para el protocolo de Internet versión 6 (IPv6). Grupo de Trabajo de Red. doi : 10.17487/RFC3364 . RFC 3364. Informativo. Actualizaciones RFC 2673, 2874.
  66. ^ 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. Obsoleto por RFC  8341.
  67. ^ Y. Morishita; T. Jinmei (mayo de 2005). Mal comportamiento común frente a consultas DNS para direcciones IPv6. doi : 10.17487/RFC4074 . RFC 4074. Informativo.

enlaces externos