Dirección IPv6

Una dirección IPv6 (proveniente de dirección de Internet Protocol versión 6) es una etiqueta numérica usada para identificar una (elemento de comunicación/conexión) de un ordenador o nodo de red participando en una red IPv6.

Las direcciones IP se usan para identificar de manera única una interfaz de red de un host, localizarlo en la red y de ese modo encaminar paquetes IP entre hosts. Con este objetivo, las direcciones IP aparecen en campos de la cabecera IP indicando el origen y destino del paquete.

IPv6 es el sucesor del primer protocolo de direccionamiento de Internet, Internet Protocol versión 4 (IPv4). A diferencia de IPv4, que utiliza una dirección IP de 32 bits, las direcciones IPv6 tienen un tamaño de 128 bits. Por lo tanto, IPv6 tiene un espacio de direcciones mucho más amplio que IPv4.

Tipos de direcciones IPv6

Las direcciones IPv6 se clasifican según las políticas de direccionamiento y encaminamiento más comunes en redes: direcciones unicast, anycast y multicast.^[1]

Una dirección unicast identifica una única interfaz de red. El protocolo de Internet entrega los paquetes enviados a una dirección unicast a la interfaz específica.
Una dirección anycast es asignada a un grupo de interfaces, normalmente de nodos diferentes. Un paquete enviado a una dirección anycast se entrega únicamente a uno de los miembros, típicamente el host con menos coste, según la definición de métrica del protocolo de encaminamiento. Las direcciones anycast no se identifican fácilmente pues tienen el mismo formato que las unicast, diferenciándose únicamente por estar presente en varios puntos de la red. Casi cualquier dirección unicast puede utilizarse como dirección anycast.
Una dirección multicast también es usada por múltiples interfaces, que consiguen la dirección multicast participando en el protocolo de multidifusión (multicast) entre los routers de red. Un paquete enviado a una dirección multicast es entregado a todos los interfaces que se hayan unido al grupo multicast correspondiente.

IPv6 no implementa direcciones broadcast. El mismo efecto puede lograrse enviando un paquete al grupo de multicast de enlace-local todos los nodos (all-nodes) ff02::1. Sin embargo, no se recomienda el uso del grupo all-nodes, y la mayoría de protocolos IPv6 usa un grupo multicast de enlace-local exclusivo en lugar de molestar a todos los interfaces de la red.

Formatos de dirección

Una dirección IPv6 está formada por 128 bits.^[1] Las direcciones se clasifican en diferentes tipos: unicast, multicast y anycast. Cada uno de los tipos define valores específicos para subgrupos de los 128 bits, asociando dicho valor con las características especiales del tipo.

Formato de dirección Unicast y Anycast

Las direcciones unicast y anycast generalmente se dividen en dos grupos lógicos: los primeros 64 bits identifican el prefijo de red, y son usados para encaminamiento; los últimos 64 bits identifican el interface de red del host.

Ejemplo de formato de dirección unicast (el tamaño del *routing-prefix* es variable)
bits	48 (o más)	16 (o menos)	64
campo	routing prefix	subnet id	interface identifier

El prefijo de red (network prefix), que consiste en el prefijo de encaminamiento (routing prefix) junto al identificador de subred (subnet id), está situado en los 64 bits más significativos de la dirección IPv6. El tamaño del routing prefix puede variar; un prefijo de mayor tamaño significa un tamaño menor para subnet id. El subnet id permite a los administradores de red definir subredes dentro de la red disponible.

Los 64 bits de identificador del interface (interface identifier) son generados automáticamente con la dirección MAC del interface y el algoritmo EUI-64 modificado, obtenidos de un servidor DHCPv6, establecidos aleatoriamente o asignados manualmente.

Una dirección de enlace-local es una dirección unicast, pero usando un valor específico para el network prefix.

Formato de dirección de enlace-local
bits	10	54	64
campo	prefijo	ceros	interface identifier

El campo prefijo contiene el valor binario 1111111010 (fe80::/10). Los 54 ceros siguientes consiguen que el prefijo de red sea el mismo para todas las direcciones locales, y por tanto no enrutable.

Formato de dirección Multicast

Véase también: Direcciones IPv6 multicast

Las direcciones multicast se construyen en función de determinadas reglas, dependiendo de la aplicación.

Formato general de dirección multicast
bits	8	4	4	112
campo	prefix	flags	scope	group ID
valor	`11111111`	`0RPT`	`XXXX`

El campo prefix mantiene el valor binario 11111111 para cualquier dirección multicast.

Actualmente se utilizan 3 de los 4 bits del campo flags (flags);^[1] el bit de flag más significativo está reservado para uso futuro.

Flags de la dirección Multicast^[2]
Flag	0	1
R (Rendezvous)^[3]	Rendezvous point not embedded (traducción no necesaria)	Rendezvous point embedded (traducción necesaria)
P (Prefijo)^[4]	Sin información de prefijo	Dirección basada en prefijo de red
T (Transitoria)^[5]	Dirección multicast mundialmente válida (permanente)	Dirección multicast asignada dinámicamente (temporal)

Los 4-bits del campo scope (ámbito) se utilizan para indicar dónde la dirección es válida y única.

Hay direcciones multicast especiales, como la Solicited-node:

Formato de dirección multicast Solicited-node
bits	8	4	4	79	9	24
campo	prefix	flags	scope	ceros	unos	dirección unicast
valor	`11111111`	`0000`	`0010`	`00000000...00000000`	`111111111`

Los campos prefix y scope tienen los valores binarios 11111111 y 0010. Las direcciones multicast Solicited-node son construidas a partir de la dirección unicast o anycast, copiando los últimos 24 bits de la dirección unicast o anycast en los últimos 24 bits de la dirección multicast.

Formato de dirección multicast Prefijo-Unicast *(unicast-prefix-based)*^[6]^[7]
bits	8	4	4	4	4	8	64	32
campo	prefix	flgs	sc	res	riid	plen	prefijo de red	group ID

Las direcciones multicast de multidifusión (link-scoped) usan un formato parecido.^[8]

Representación

Una dirección IPv6 (128 bits) se representa mediante ocho grupos de cuatro dígitos hexadecimales, cada grupo representando 16 bits (dos octetos). Los grupos se separan mediante dos puntos (:). Un ejemplo de dirección IPv6 podría ser:

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

Los dígitos hexadecimales no son sensibles a mayúsculas/minúsculas, pero se aconseja la utilización de minúsculas.^[9]

Esta representación completa puede ser simplificada de varias maneras, eliminando partes de la representación.

Ceros iniciales

Los ceros iniciales de cada grupo pueden omitirse, aunque cada grupo debe contener al menos un dígito hexadecimal.^[1] De ese modo, la dirección IPv6 ejemplo podría escribirse:

2001:db8:85a3:0:0:8a2e:370:7334

Grupos de ceros

Uno o más grupos de ceros pueden ser sustituidos por dos puntos.^[1] Esta sustitución puede realizarse únicamente una vez en la dirección. En caso contrario, obtendríamos una representación ambigua. Si pueden hacerse varias sustituciones, debemos hacer la de mayor número de grupos; si el número de grupos es igual, debemos hacer la situada más a la izquierda.^[9] Con esta regla, reduciríamos aún más la dirección ejemplo:

2001:db8:85a3::8a2e:370:7334

La dirección de loopback, 0:0:0:0:0:0:0:1, y la dirección IPv6 indefinida, 0:0:0:0:0:0:0:0, se reducen a ::1 y :: respectivamente.

Notación decimal con puntos

Durante la transición de Internet de IPv4 a IPv6 será típico operar en entornos de doble direccionamiento (IPv4 e IPv6). Por este motivo se ha introducido una notación especial para expresar direcciones IPv6 que sean IPv4-mapeada o IPv4-compatible, representando los últimos 32 bits de la dirección IPv6 en el formato decimal con puntos usado en IPv4.

Por ejemplo, la dirección IPv6 del tipo IPv4-mapeada ::ffff:c000:280 se puede representar como ::ffff:192.0.2.128, mostrando claramente la dirección IPv4 mapeada dentro de la IPv6.

Redes

Una red IPv6 utiliza un grupo de direcciones IPv6 contiguas, de un tamaño potencia de dos. La parte inicial de las direcciones es idéntica para todos los hosts de una red, y se llama dirección de red o prefijo de encaminamiento (routing prefix). Las direcciones de red se escriben en notación CIDR. Una red se representa por la primera dirección del grupo (que debe terminar en ceros), una barra (/), y el número de bits del prefijo en decimal. Por ejemplo, la red 2001:db8:1234::/48 comienza en la dirección 2001:0db8:1234:0000:0000:0000:0000:0000 y finaliza en 2001:0db8:1234:ffff:ffff:ffff:ffff:ffff.

Veámoslo con mayor detalle:

2001:db8:1234::/48  → Dirección de Red
2001:0db8:1234:0000:0000:0000:0000:0000/48 → Dirección de red sin comprimir
---- Red ----- --------- Host ---------

2001:0db8:1234:0000:0000:0000:0000:0001 → Primera dirección IPv6 de la red
2001:0db8:1234:ffff:ffff:ffff:ffff:ffff → Última dirección IPv6 de la red

Es posible indicar directamente el prefijo de encaminamiento de una dirección de interfaz mediante notación CIDR. Por ejemplo, una interfaz con dirección 2001:db8:a::123 perteneciente a la subred 2001:db8:a::/64 puede escribirse 2001:db8:a::123/64.

Tamaño del grupo de direcciones

El tamaño del grupo de direcciones se representa únicamente con una barra (/) y el tamaño del prefijo de red en decimal, sin indicar qué direcciones específicas están en el grupo. Por ejemplo, un grupo de direcciones con prefijo de 48 bits se indica /48; este grupo contiene 2^{128 − 48} = 2⁸⁰ direcciones. Cuanto menor sea el tamaño del prefijo de red, mayor el grupo de direcciones para hosts: un grupo /21 es 8 veces mayor que uno /24.

Direcciones IPv6 literales en recursos de red

Los dos puntos (:) en las direcciones IPv6 pueden entrar en conflicto con otras sintaxis ya establecidas, como URIs y URLs. En una URL, los dos puntos se han utilizado tradicionalmente como separación entre una dirección de host (que puede ser una dirección IP) y el puerto de red.^[10] Para solucionar este problema, las direcciones IPv6 literales se encierran entre corchetes cuando es necesario, por ejemplo:

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

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

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

Direcciones IPv6 literales en rutas UNC

En sistemas operativos Microsoft Windows, las direcciones IPv4 son identificadores válidos en rutas UNC (Uniform Naming Convention). Un ejemplo de ruta UNC utilizando dirección IPv4 sería:

\\192.168.0.1\CarpetaCompartida\Recurso

Sin embargo, el carácter dos puntos es ilegal en una ruta UNC. Por tanto, el uso de direcciones IPv6 es también ilegal en rutas UNC. Por este motivo, Microsoft ha implementado un algoritmo de sustitución para representar direcciones IPv6 como nombres de dominio, que sí pueden usarse en rutas UNC. Microsoft registró y reservó el dominio ipv6-literal.net en Internet. Las direcciones IPv6 se transcriben como subdominio dentro de ese espacio de nombres, del siguiente modo:

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

es traducido a:

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

lo que daría lugar a una ruta UNC del tipo:

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

Esta notación es resuelta automáticamente por el software de Microsoft sin hacer peticiones a servidores DNS.

Si la dirección IPv6 contiene un índice de zona, es añadida a la dirección después del carácter 's':

fe80--1s4.ipv6-literal.net

Ámbito de direcciones IPv6

Toda dirección IPv6, excepto la dirección indefinida (::), tiene un "ámbito" (scope en inglés),^[11] que determina en qué partes de la red es válida.

En direccionamiento unicast, las direcciones de enlace-local y la dirección de loopback tienen ámbito de enlace local, es decir, deben ser usadas en la red directamente conectada. El resto de direcciones, excepto aquellas privadas, tienen ámbito global (o universal), que significa que son mundialmente enrutables y pueden ser usadas para conectarse a direcciones de ámbito global en cualquier lugar, o a direcciones de ámbito enlace-local en la red directamente conectada.

El ámbito de una dirección anycast se define del mismo modo que en las direcciones unicast.

Para multicast, los cuatro bits menos significativos del segundo octeto de una dirección multicast (ff0X::) identifican el ámbito, es decir, hasta dónde se propaga el tráfico multicast. Los ámbitos^[1] definidos actualmente son:

Ámbito dirección IPv6 Multicast
Valor	Ámbito (scope)	Descripción
`0x0`	reserved
`0x1`	interface-local	El ámbito interface-local abarca solo una única interfaz de un nodo, y es útil solo para la transmisión loopback del tráfico multicast.
`0x2`	link-local	Los ámbitos de enlace-local y site-local abarcan las mismas regiones que los ámbitos unicast correspondientes.
`0x4`	admin-local	El ámbito admin-local es el más pequeño que debe ser configurado manualmente, es decir, no deriva automáticamente de la conexión física sin relación alguna con multicast.
`0x5`	site-local	Los ámbitos de enlace-local y site-local abarcan las mismas regiones que los ámbitos unicast correspondientes.
`0x8`	organization-local	El ámbito de organization-local abarca múltiples ubicaciones que pertenecen a la misma organización.
`0xe`	global
`0xf`	reserved

Espacio de direccionamiento IPv6

Asignación general

El Internet Architecture Board (Comité de Arquitectura de Internet) y el Internet Engineering Steering Group (Dirección de Ingeniería de Internet) delegaron la asignación del direccionamiento IPv6 en la Internet Assigned Numbers Authority (IANA).^[12] Su función principal es la asignación de grandes bloques de direcciones a los Registros Regionales de Internet (RIRs por sus siglas en inglés), que tienen la tarea de asignar trozos menores a Proveedores de Internet u otros registros locales. IANA ha mantenido la lista oficial de las asignaciones del espacio de direcciones IPv6 desde diciembre de 1995.^[13]

Actualmente, solo la octava parte del espacio total de direcciones están disponibles para su uso en Internet. La mayor parte de las direcciones IPv6 están reservadas para uso futuro. Para conseguir agregación de rutas, reduciendo así el tamaño de las tablas de rutas de Internet, el rango 2000::/3 se asigna a los RIRs en grandes bloques desde /23 hasta /12.^[14]

Los RIRs asignan rangos menores a ISPs, que luego distribuyen en bloques de /48 a sus clientes. Los registros de asignaciones globales pueden encontrarse en los RIRs u otros webs.^[15]

Las direcciones IPv6 se asignan a las organizaciones en bloques mucho mayores a las asignaciones IPv4; la asignación recomendada es un rango /48, que es 2⁴⁸ o 2.8×10¹⁴ veces mayor que el direccionamiento IPv4 completo. A pesar de ello, el conjunto total es suficiente para el futuro previsible, pues hay 2¹²⁸ o sobre 3.4×10³⁸ direcciones IPv6.

Cada RIR puede dividir cada uno de sus bloques /23 en 512 bloques /32, normalmente uno para cada ISP. Un ISP puede dividir cada uno de sus rangos /32 en 65.536 bloques /48, normalmente uno para cada cliente.^[16] Los clientes pueden crear 65.536 redes /64 con su asignación /48, teniendo cada red un número de direcciones que es el cuadrado de todo el espacio de direcciones IPv4, que sólo tenía 2³² o 4.3×10⁹ direcciones.

Tal y como se ha diseñado, solo una pequeña fracción del espacio de direcciones se utilizarán realmente. El amplio espacio de direcciones asegura que prácticamente siempre habrá disponibilidad, lo que convertirá a la traducción de direcciones (NAT) en innecesaria desde un punto de vista de direccionamiento. NAT se utiliza actualmente sobre todo para aliviar el agotamiento de las direcciones IPv4, pero también tiene aspecto económico ya que el alquiler de direcciones IP tiene un coste. Desde un punto de vista de la seguridad evita exponer información de estructura y gestión interna de red hacia internet.

Direcciones anycast reservadas

La dirección más baja de cada subred (identificador de interface todo a ceros) está reservada como dirección anycast subnet-router (subred de router).^[1] Las aplicaciones pueden utilizar esta dirección destino para hablar con algún router de la subred, garantizando IPv6 que estos paquetes son entregados únicamente a un router de la subred.

Las 128 direcciones más altas de cada subred /64 están reservadas como direcciones anycast.^[17] Estas direcciones suelen tener los 57 primeros bits del identificador de interface a 1, seguidos de 7 bits de identificador anycast. Los prefijos de red, incluidos subredes, requieren tener 64 bits de longitud, en cuyo caso el bit universal/local debe ser puesto a 0 para indicar que la dirección no es globalmente única. Si la dirección tiene el valor 0x7e en los 7 bits menos significativos, se define como una dirección anycast de home agent (agente inicial) en IP Móvil. La dirección con los 7 bits menos significativos a 1 (valor 0x7f) está reservada y no puede ser usada. No hay más asignaciones, por lo que los valores desde 0x00 hasta 0x7d están reservados también.

Direcciones especiales

Existe direcciones con un significado especial en IPv6:^[18]

Bloques de direccionamiento especiales
Bloque de direcciones (CIDR)	Primera dirección	Última dirección	N.º de direcciones	Alcance	Propósito
::/0	::	ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff	2¹²⁸	Enrutamiento	Ruta por defecto
::/128	::		1	Software	Dirección sin especificar
::1/128	::1		1	Host	Dirección de loopback
::ffff:0:0/96	::ffff:0.0.0.0	::ffff:255.255.255.255	2³²	Software	Dirección IPv4 mapeada
::ffff:0:0:0/96	::ffff:0:0.0.0.0	::ffff:0:255.255.255.255	2³²	Software	Dirección IPv4 traducida
64:ff9b::/96	64:ff9b::0.0.0.0	64:ff9b::255.255.255.255	2³²	Internet	Traducción IPv4/IPv6.^[19]
100::/64	100::	100::ffff:ffff:ffff:ffff	2⁶⁴	Enrutamiento	Prefijo.^[20]
2001::/32	2001::	2001::ffff:ffff:ffff:ffff:ffff:ffff	2⁹⁶	Internet	Túnel Teredo.
2001:20::/28	2001:20::	2001:2f:ffff:ffff:ffff:ffff:ffff:ffff	2¹⁰⁰	Software	ORCHIDv2.^[21]
2001:db8::/32	2001:db8::	2001:db8:ffff:ffff:ffff:ffff:ffff:ffff	2⁹⁶	Documentación	Direcciones utilizadas en documentación y código fuente de ejemplo.^[22]
2002::/16	2002::	2002:ffff:ffff:ffff:ffff:ffff:ffff:ffff	2¹¹²	Internet	Esquema de direccionamiento 6to4 (ahora en desuso).^[23]
fc00::/7	fc00::	fdff:ffff:ffff:ffff:ffff:ffff:ffff:ffff	2¹²¹	Red privada	Dirección local única.^[24]
fe80::/10	fe80::	febf:ffff:ffff:ffff:ffff:ffff:ffff:ffff	2¹¹⁸	Enlace	Dirección de Enlace-Local.
ff00::/8	ff00::	ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff	2¹²⁰	Internet	Dirección multidifusión.

Direcciones Unicast

Dirección indefinida

::/128 — La dirección con todos sus bits a 0 se llama dirección indefinida (similar a la dirección 0.0.0.0 en IPv4).
Esta dirección no puede nunca ser asignada a ningún interface, pues se utiliza únicamente por el software de una aplicación antes de conocer la dirección origen de una conexión. Los routers no deben encaminar paquetes con la dirección indefinida.
Las aplicaciones pueden escuchar (listen) en uno o más interfaces por nuevas conexiones. Esto puede verse en un listado de conexiones activas con una dupla dirección IP y número de puerto separados por dos puntos. Cuando la aplicación está escuchando (listening) en todos los interfaces disponibles, aparece la dirección indefinida en dicho listado.

Ruta por defecto

::/0 — La ruta por defecto para tráfico unicast (correspondiente a la ruta a 0.0.0.0 con máscara 0.0.0.0 en IPv4).

Direcciones locales

::1/128 — La dirección de loopback es una dirección unicast del localhost. Si una aplicación en un host envía paquetes a esta dirección, la pila IPv6 enviará de vuelta los paquetes al mismo interface virtual (correspondiente a 127.0.0.1 en IPv4).
fe80::/10 — Las direcciones de prefijo enlace-local (link-local) son válidas (utilizables) y únicas (no repetidas) solo en la red local. Dentro de este rango de enlace local, solo se utiliza una subred (54 bits a cero), generando un formato eficaz de fe80::/64. Los 64 bits menos significativos suelen construirse a partir de la dirección hardware del interface en formato EUI-64 modificado. Las direcciones de enlace local son requeridas en todos los interfaces con IPv6 habilitado; por ello, las aplicaciones pueden aprovechar la existencia de direcciones de enlace local aun cuando no haya encaminamiento IPv6. Estas direcciones son comparables a las direcciones de auto-configuración 169.254.0.0/16 en IPv4.

Dirección local única

fc00::/7 — Las direcciones locales únicas (ULA's por sus siglas en inglés) se utilizan para comunicaciones locales. Son enrutables solo dentro de un ámbito cooperativo (similar a los rangos de direcciones privadas 10/8, 172.16/12, y 192.168/16 en IPv4).^[25] Las direcciones incluyen una secuencia pseudoaleatoria en el prefijo de encaminamiento (routing prefix) para minimizar el riesgo de conflictos en la interconexión de plataformas diferentes o si los paquetes se desvían a Internet. A pesar del uso restringido y local de estas direcciones, su ámbito es global, es decir, se esperan sean únicas (no repetidas) en todo el mundo.

Transición de IPv4

::ffff:0:0/96 — Este prefijo designa una dirección IPv6 IPv4-mapeada. Salvo pocas excepciones, este tipo de dirección permite el funcionamiento de protocolos de capa de transporte IPv4 en software (APIs) IPv6. Las aplicaciones servidoras solo tienen que abrir un socket en listening para aceptar conexiones de clientes usando protocolos IPv6 o IPv4. Los clientes IPv6 serán gestionados de modo nativo, mientras que los clientes IPv4 aparecerán como clientes IPv6 cuya dirección es una dirección IPv6 IPv4-mapeada. La transmisión se gestiona de modo similar; los sockets pueden transmitir datagramas IPv4 o IPv6, mediante la conexión a una dirección IPv6 nativa o a una dirección IPv4-mapeada. (Vea también Mecanismos de transición a IPv6.)
::ffff:0:0:0/96 — Un prefijo reservado para direcciones IPv4-traducidas, utilizadas por el protocolo Stateless IP/ICMP Translation (SIIT).
64:ff9b::/96 — El prefijo "Well-Known" (ya conocido). Este prefijo se utiliza para traducciones automáticas IPv4/IPv6.^[19]

Artículo principal: 6to4

2002::/16 — Esta red se utiliza para el direccionamiento 6to4. Se utiliza también una dirección de la red IPv4 192.88.99.0/24.

Direcciones de uso especial^[26]

IANA ha reservado un bloque de direcciones llamado 'Sub-TLA ID'^[27] que consisten en 64 prefijos de red desde 2001:0000::/29 hasta 2001:01f8::/29. Se han realizado tres asignaciones en este bloque:

Artículo principal: Teredo

2001::/32 — Usado por el protocolo de túneles Teredo (que también cae dentro de la categoría mecanismo de transición IPv6).
2001:2::/48 — Asignado a Benchmarking Methodology Working Group (BMWG)^[28] para comparativas (benchmarking) en IPv6 (similar a la red 198.18.0.0/15 para comparativas en IPv4).
2001:10::/28 — ORCHID (Overlay Routable Cryptographic Hash Identifiers).^[29] Son direcciones IPv6 no-enrutables usadas para identificadores criptográficos Hash.

Documentación

2001:db8::/32 — Este prefijo está reservado para documentación.^[22] Estas direcciones deben usarse siempre que alguien quiera escribir un ejemplo de dirección IPv6, o se plasmen modelos de red (similar a las redes 192.0.2.0/24, 198.51.100.0/24, y 203.0.113.0/24 en IPv4.)^[30]

Direcciones obsoletas

Vea al final las notas históricas.

Direcciones Multicast

Las direcciones multicast ff00::0/12 están reservadas y no deberían utilizarse para ningún grupo multicast. Para ver una lista completa de direcciones IPv6 multicast reservadas se debe visitar a Internet Assigned Numbers Authority (IANA).^[31]

A continuación se muestran algunas de las más usuales:

Dirección	Descripción	Ámbitos disponibles
`ff0X::1`	Dirección all-nodes (todos los nodos). Identifica al grupo de todos los nodos IPv6	Disponible en el ámbito (scope) 1 (interface-local) y 2 (link-local): `ff01::1` → Todos los nodos en el interface local `ff02::1` → Todos los nodos en el enlace local
`ff0X::2`	Dirección all-routers (todos los routers). Identifica al grupo de todos los routers IPv6	Disponible en el ámbito (scope) 1 (interface-local), 2 (link-local) y 5 (site-local): `ff01::2` → Todos los routers en el interface local `ff02::2` → Todos los routers en el enlace local `ff05::2` → Todos los routers en el site-local
`ff02::5`	OSPFIGP	2 (enlace-local)
`ff02::6`	OSPFIGP Designated Routers	2 (enlace-local)
`ff02::9`	Routers RIP	2 (enlace-local)
`ff02::a`	Routers EIGRP	2 (enlace-local)
`ff02::d`	Todos los routers PIM	2 (enlace-local)
`ff0X::fb`	mDNSv6	Disponible en todos los ámbitos
`ff0X::101`	Todos los servidores de NTP (Network Time Protocol)	Disponible en todos los ámbitos
`ff02::1:1`	Link Name	2 (enlace-local)
`ff02::1:2`	All-dhcp-agents	2 (enlace-local)
`ff02::1:3`	Link-local Multicast Name Resolution	2 (enlace-local)
`ff05::1:3`	All-dhcp-servers	5 (site-local)
`FF02::1:FF00:0000/104`	Dirección Solicited-Node. Véase explicación más abajo	2 (enlace-local)
`FF02:0:0:0:0:2:FF00::/104`	Node Information Queries	2 (enlace-local)

Dirección multicast Solicited-node

Los 24 bits menos significativos del group ID de una dirección Solicited-Node se rellenan con los 24 bits menos significativos de la dirección unicast o anycast. Estas direcciones permiten la resolución de la dirección de red vía Neighbor Discovery (NDP) en la red sin molestar a todos los hosts conectados (como ocurría con ARP en IPv4). Un host debe unirse (join) a un grupo multicast Solicited-Node para cada una de sus direcciones unicast o anycast

Configuración automática sin estado

Tras el arranque del sistema, un nodo crea automática una dirección de enlace-local en cada interface con IPv6 habilitado, aunque se hayan configurado manualmente u obtenido por DHCPv6 direcciones globales. Esto se realiza de modo automático, y sin ningún tipo de configuración previa gracias a la configuración automática sin estado (SLAAC, stateless address autoconfiguration),^[32] usando un componente del Neighbor Discovery Protocol. Esta dirección tendrá el prefijo fe80::/64.

Además, el host puede crear una dirección unicast encaminable cuando un router responde a su solicitud de router con una asignación de subred^[33]

Los 64 bits menos significativos de estas direcciones se rellenan con un identificador de interface de 64 bits en formato EUI-64 modificado. Este identificador se utiliza para todas las direcciones automáticas de ese interface, de modo que sólo se necesita un grupo multicast para unirse al neighbor discovery. Para ello utilizamos 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.

EUI-64 Modificado

El identificador de interfaz de 64 bits se deriva comúnmente de los 48 bits de la dirección MAC. Una dirección MAC 00:1D:BA:06:37:64 se convierte en una dirección EUI-64 de 64 bits insertando FF:FE en el medio: 00:1D:BA:FF:FE:06:37:64. Pero modificamos este EUI-64 cuando lo usamos para formar una dirección IPv6:^[1] invertimos el bit Universal/Local (el séptimo bit más significativo del EUI-64), de manera que un 0 en dicho bit del EUI-64 resultará un 1 en el EUI-64 Modificado. Para identificar la interfaz anterior en la red IPv6 2001:db8:1:2::/64 usaríamos la dirección 2001:db8:1:2:021d:baff:fe06:3764 (con el bit subrayado U/L invertido de 0 a 1).

La razón de modificar el bit U/L se debe a que cuando asignamos direcciones de modo manual a un interface, es probable que asignemos una del tipo 2001:db8:1:2::1/64 en lugar de la menos atractiva e intuitiva 2001:db8:1:2:0200::1/64. Cuando asignamos manualmente direcciones de enlace-local, la necesidad de esta modificación es más evidente: configuraremos manualmente una dirección corta fc80::1 en lugar de una larga fc80:0:0:0:0200::1. En resumen, modificamos EUI-64 para reducir las probabilidades de duplicidad entre direcciones manuales y automáticas.

Detección de direcciones duplicadas

La asignación de una dirección IPv6 unicast a un interface necesita de una prueba interna de su disponibilidad, utilizando los mensajes ICMPv6 tipo 135 (Neighbor Solicitation) y 136 (Neighbor Advertisement). Durante el proceso de verificación de disponibilidad, la dirección tiene un estado de dirección tentativa.

El nodo se une a la dirección multicast solicited-node para la dirección tentativa (si no lo ha hecho ya), y envía neighbor solicitations utilizando como dirección origen la dirección indefinida (::/128) y como dirección destino la dirección tentativa. El nodo también se une a la dirección de multicast all-nodes (todos los equipos) ff02::1, por lo que recibirá los anuncios del resto de equipos (Neighbor Advertisements).

Si un nodo recibe un solicitud (neighbor solicitation) con su dirección tentantiva como dirección destino, la dirección no es única. Tampoco podrá ser única si el nodo recibe un anuncio (neighbor advertisement) con la dirección tentativa como origen. Tan sólo después de haber verificado que la dirección es única, puede ser usada y asignada a un interface.

Tiempo de vida de la dirección

Cada dirección IPv6 vinculada a un interface tiene un tiempo de vida preestablecido. El tiempo de vida es infinito, salvo que se haya configurado un tiempo menor. Hay dos valores que rigen el tiempo de vida de una dirección: preferred lifetime (tiempo preferido) y valid lifetime (tiempo de validez).^[34] Estos tiempos de vida pueden configurarse en los routers que proveen los valores para autoconfiguración, o especificar durante la configuración manual de las direcciones en los interfaces.

Cuando se asigna una dirección a un interface tiene el estado preferred (preferido), que mantiene durante su preferred-lifetime. Tras expirar dicho tiempo de vida, el estado pasa a deprecated (obsoleto) y la dirección no podrá usarse para nuevas conexiones. La dirección pasa a invalid (inválida) cuando expira también su valid-lifetime; la dirección se elimina del interface y podrá ser asignada a cualquier host en Internet (está completamente libre).

Direcciones temporales

Las estáticas y mundialmente únicas direcciones MAC, usadas por la configuración automática sin estado para crear identificadores de interface, ofrecen una oportunidad para hacer un seguimiento de los equipos y usuarios a través del tiempo y de las distintas redes IPv6.^[35] Para reducir la atadura de la identidad del usuario a una porción de dirección IPv6, un host puede crear direcciones temporales con identificadores de interfaces basados en números aleatorios^[36] y tiempos de vida relativamente cortos (de horas o días), tras los cuales se reemplazan con nuevas direcciones.

Un host puede utilizar direcciones temporales como direcciones origen para conexiones salientes; mientras, el resto de hosts utilizará la dirección pública para acceder a él tras preguntar a DNS.

Los sistemas configurados en IPv6 en Windows Vista, Windows Server 2008 o versiones posteriores utilizan direcciones temporales por defecto.

Selección automática de dirección

Los interfaces de red habilitados para IPv6 tienen normalmente más de una dirección IPv6, por ejemplo una dirección de enlace-local y una dirección global, o direcciones permanentes versus temporales. IPv6 introduce los conceptos de alcance y preferencia, dando múltiples opciones para seleccionar la dirección origen y destino en comunicaciones con otros hosts.

El algoritmo de selección de preferencia,^[37] que elige la dirección más apropiada para usar en la comunicación con un destino concreto (incluyendo el uso de direcciones IPv4-mapeadas en implementaciones de doble pila) está basado en una tabla de preferencias configuradas por el usuario, que asocia cada prefijo de red con un nivel de prioridad. La tabla por defecto sería como la siguiente:^[37]

Tabla de Políticas de Prefijos
Prefijo	Prioridad	Etiqueta
`::1/128 ::/0 2002::/16 ::/96 ::ffff:0:0/96`	50 40 30 20 10	0 1 2 3 4

En una configuración por defecto, IPv6 tendrá mayor prioridad que IPv4, y también utilizará direcciones destino con el ámbito más pequeño posible, de modo que las comunicaciones de enlace-local son preferidas a caminos globales cuando ambos sean igualmente adecuados. La tabla de políticas de prefijos es similar a una tabla de rutas, con el valor de prioridad haciendo de coste de enlace y donde mayor preferencia es expresada como un valor mayor. Las direcciones origen candidatas se obtienen del Sistema Operativo, y las direcciones destino candidatas pueden ser consultadas vía Domain Name System (DNS). Después se cruzan con la tabla de políticas de prefijos, seleccionando el prefijo de mayor número de bits de entre las entradas donde la dirección IPv6 hace match.

Direcciones de Enlace-Local e Índice de Zonas

Debido a que todas las direcciones de enlace-local en un host tienen un prefijo común, no se pueden utilizar los procedimientos normales de encaminamiento para elegir el interface de salida en el envío de paquetes a un destino de enlace-local. Se necesita de un identificador especial, conocido como zone index (índice de zona),^[11] para proveer información de encaminamiento adicional; en el caso de direcciones de enlace-local, los índices de zona corresponden a identificadores de interface.

Al escribir textualmente una dirección, añadimos el índice de zona a la dirección separado por un signo de porcentaje (%). La sintaxis actual de los índices de zona depende del sistema operativo:

La pila IPv6 en Microsoft Windows utiliza índices de zona numéricos, p.ej. fe80::3%1. El índice se establece por el número de interface.
La mayoría de sistemas Unix (p.ej. BSD, Linux, Mac OS X) usa el nombre de interface como índice de zona: fe80::3%eth0.

La notación de índice de zona causa conflictos de sintaxis al usar la dirección para URIs o URLs, debido a que el carácter '%' se utiliza para el paso de parámetros.^[38]

Direcciones IPv6 en el DNS

Mediante el Domain Name System, los hostnames se mapean a direcciones IPv6 por registros AAAA, también llamados registros cuádruple-A. IETF ha reservado el dominio ip6.arpa para la resolución inversa de DNS, dividiendo el espacio de nombres jerárquicamente por cada dígito hexadecimal de la dirección IPv6. Esta traducción se define en el RFC 3596.

De igual modo que en IPv4, cada host está representado en el DNS por dos registros, un registro directo (address record) y un registro de resolución inversa. Por ejemplo, un equipo llamado servidor en la zona ejemplo.es' tiene la dirección local única fdda:5cc1:23:4::1f. Su registro cuádruple-A es

servidor.ejemplo.es.  IN  AAAA  fdda:5cc1:23:4::1f

y su resolución inversa 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.c.c.5.a.d.d.f.ip6.arpa.  IN  PTR   servidor.ejemplo.es.

Este registro inverso puede definirse en varias zonas, dependiendo de la cadena de delegación en la zona d.f.ip6.arpa.

El DNS es independiente del protocolo de transporte. Las peticiones y respuestas pueden ser transmitidas sobre IPv6 o Ipv4, independientemente del tipo de información transportada.

**Campos registro AAAA**
NAME	Nombre de Dominio
TYPE	AAAA (28)
CLASS	Internet (1)
TTL	Tiempo de vida en segundos
RDLENGTH	Longitud del campo RDATA
RDATA	Dirección IPv6 en formato texto^[1]

Transición

Desde 2009, muchos dispositivos NAT y routers en los hogares todavía gestionan incorrectamente los registros AAAA.^[39] Algunos de ellos simplemente desechan las peticiones DNS a estos registros, en lugar de devolver una respuesta negativa apropiada. Debido a que la petición es desechada, el host debe esperar el timeout de esa petición. Esto, a menudo, causa una percepción de lentitud en la conexión de hosts IPv6.

Notas históricas

El prefijo site-local fec0::/10 especifica que la dirección es válida únicamente dentro de la red de una organización. Formaba parte de la arquitectura de direccionamiento original^[40] en diciembre de 1995, pero su uso fue desaconsejado en septiembre de 2004,^[41] pues la definición del término inglés site era ambigua provocando reglas de routing confusas. Las nuevas redes no debían soportar este tipo especial de direcciones. En octubre de 2005, una nueva especificación^[24] sustituyó este tipo de direcciones por las direcciones locales únicas.

El bloque de direcciones 0200::/7 fue definido como un prefijo OSI NSAP-mapped en agosto de 1996,^[42]^[43] pero fue eliminado en diciembre de 2004.^[44]

El prefijo de 96-bits a cero ::/96, conocido originalmente como direcciones IPv4-compatibles, fue mencionado en 1995^[40] pero descrito por primera vez en 1998.^[45] Esta clase de direcciones se usaba para representar direcciones IPv4 dentro de tecnología IPv6, facilitando la transición. Era una dirección IPv6 con sus primeros (más significativos) 96 bits a cero, mientras que los últimos 32 bits eran la dirección IPv4 que representaban. En febrero de 2006 la Internet Engineering Task Force (IETF) ha desaconsejado la utilización de direcciones IPv4-compatibles.^[1] El único uso que se mantiene de este formato de dirección es al representar una dirección IPv4 en una tabla o base de datos con campos de tamaño fijos, que también deben ser capaces de almacenar direcciones IPv6.

La resolución inversa de direcciones IPv6 se configuraba originalmente en el Domain name system (DNS) en la zona ip6, bajo el dominio principal .int. La intención inicial era que el dominio .arpa fuese movido dentro de .int, pero se desechó en el año 2000 por la Internet Architecture Board (IAB). Por ello, el registro inicial bajo ip6.int debía moverse a ip6.arpa. La IAB lo formalizó en agosto de 2001.^[46] La zona ip6.int fue oficialmente eliminada el 6 de junio de 2006.

Se reservó el bloque de direcciones 3ffe::/16 para pruebas de la red 6bone en diciembre de 1998.^[45] Antes de eso se utilizaba el rango de direcciones 5F00::/8. Ambos rangos fueron liberados en junio de 2006, con la defunción del proyecto 6bone.^[47]

Referencias

↑ ^a ^b ^c ^d ^e ^f ^g ^h ⁱ ^j RFC 4291, IP Version 6 Addressing Architecture, R. Hinden, S. Deering (Febrero de 2006)
↑ Silvia Hagen (mayo de 2006). IPv6 Essentials (Second edición). O'Reilly. ISBN 978-0596100582.
↑ RFC 3956
↑ RFC 3306
↑ RFC 4291
↑ RFC 3306, Unicast-Prefix-based IPv6 Multicast Addresses, B. Haberman, D. Thaler (August 2002)
↑ RFC 3956, Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address P. Savola, B. Haberman (November 2004)
↑ RFC 4489, A Method for Generating Link-Scoped IPv6 Multicast Addresses, J-S. Park, M-K. Shin; H-J. Kim (April 2006)
↑ ^a ^b RFC 5952, "A Recommendation for IPv6 Address Text Representation", S. Kawamura, M. Kawashima, (August 2010)
↑ RFC 3986, Uniform Resource Identifier (URI): Generic Syntax, T. Berners-Lee, R. Fielding, L. Masinter (January 2005)
↑ ^a ^b RFC 4007, IPv6 Scoped Address Architecture, S.Deering, B. Haberman, T. Jinmei, E. Nordmark, B. Zill (March 2005)
↑ RFC 1881, IPv6 Address Allocation Management, Internet Architecture Board (December 1995)
↑ IPv6 address space at IANA
↑ IPv6 unicast address assignments, IANA
↑ por ejemplo, SIXXS Ghost Route Hunter
↑ «IPv6 Addressing Plans». ARIN IPv6 Wiki. Consultado el 18 de agosto de 2010. «All customers get one /48 unless they can show that they need more than 65k subnets. [...] If you have lots of consumer customers you may want to assign /56s to private residence sites.»
↑ RFC 2526,Reserved IPv6 Subnet Anycast Addresses, D. Johnson, S. Deering (March 1999)
↑ RFC 5156, Special-Use IPv6 Addresses, M. Blanchett (April 2008)
↑ ^a ^b IPv6 Addressing of IPv4/IPv6 Translators, doi:10.17487/RFC6052, RFC 6052 . Error en la cita: Etiqueta <ref> no válida; el nombre «rfc6052» está definido varias veces con contenidos diferentes
↑ A Discard Prefix for IPv6, doi:10.17487/RFC6666, RFC 6666 .
↑ An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2), doi:10.17487/RFC7343, RFC 7343 .
↑ ^a ^b IPv6 Address Prefix Reserved for Documentation, doi:10.17487/RFC3849, RFC 3849 . Error en la cita: Etiqueta <ref> no válida; el nombre «rfc3849» está definido varias veces con contenidos diferentes
↑ Deprecating the Anycast Prefix for 6to4 Relay Routers, doi:10.17487/RFC7526, BCP 196. RFC 7526 .
↑ ^a ^b Unique Local IPv6 Unicast Addresses, doi:10.17487/RFC4193, RFC 4193 . Error en la cita: Etiqueta <ref> no válida; el nombre «rfc4193» está definido varias veces con contenidos diferentes
↑ RFC 1978, Address Allocation for Private Internets, Y. Rekhter, B. Moskowitz, D. Karrenberg, G.J. De Groot, E. Lear (February 1996)
↑ RFC 4773, Administration of the IANA Special Purpose IPv6 Address Block, G. Huston (December 2006)
↑ RFC 2928, Initial IPv6 Sub-TLA ID Assignments, R. Hinden, S. Deering, R. Fink, T. Hain (September 2000) The Internet Society
↑ RFC 5180, IPv6 Benchmarking Methodology for Network Interconnect Devices, C. Popoviciu, A. Hamza, G. Van de Velde, D. Dugatkin (May 2008)
↑ RFC 4843 (experimental), An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers (ORCHID), P. Nikander, J. Laganier, F. Dupont (April 2007)
↑ RFC 5737, IPv4 Address Blocks Reserved for Documentation, J. Arkko, M. Cotton, L. Vegoda (January 2010), ISSN 2070-1721
↑ IANA Internet Protocol Version 6 Multicast Addresses. Internet Assigned Numbers Authority.
↑ RFC 4862, IPv6 Stateless Address Autoconfiguration, S. Thomson, T. Narten, T. Jinmei (September 2007)
↑ RFC 4861, Neighbor Discovery for IP version 6 (IPv6), T. Narten, E. Nordmark, W. Simpson, H. Holiman (September 2007)
↑ Iljitsch van Beijnum (2006). «IPv6 Internals». The Internet Protocol Journal 9 (3). pp. 16-29. Archivado desde el original el 7 de junio de 2011. Consultado el 10 de febrero de 2011.
↑ The privacy implications of stateless IPv6 addressing
↑ RFC 4941, Privacy Extensions for Stateless Address Autoconfiguration in IPv6, T. Narten, R. Draves, S. Krishnan (September 2007)
↑ ^a ^b RFC 3484, Default Address Selection for Internet Protocol version 6 (IPv6), R. Draves, The Internet Society (February 2003)
↑ Formats for IPv6 Scope Zone Identifiers in Literal Address Formats
↑ RFC 4074 Common Misbehavior Against DNS Queries for IPv6 Addresses, Y. Morishita, T. Jinmei. May 2005.
↑ ^a ^b RFC 1884, IP Version 6 Addressing Architecture, R. Hinden, S. Deering ()
↑ RFC 3879, Deprecating Site Local Addresses, C. Huitema, B. Carpenter ()
↑ RFC 4147, Proposed Changes to the Format of the IANA IPv6 Registry, G. Houston ()
↑ RFC 1888, OSI NSAPs and IPv6, J. Bound, B. Carpenter, D. Harrington, J. Houldsworth, A. Lloyd ()
↑ RFC 4048, RFC 1888 Is Obsolete, B. Carpenter ()
↑ ^a ^b RFC 2471, IPv6 Testing Address Allocation, R. Hinden, R. Fink, J. Postel ()
↑ RFC 3152, Delegation of IP6.ARPA, R. Bush ()
↑ RFC 3701, 6bone (IPv6 Testing Address Allocation) Phaseout, R. Fink, R. Hinden ()

Véase también

Datos: Q11097

[rfc4291-1] ↑ ^a ^b ^c ^d ^e ^f ^g ^h ⁱ ^j RFC 4291, IP Version 6 Addressing Architecture, R. Hinden, S. Deering (Febrero de 2006)

[IPv6Essentials-2] Silvia Hagen (mayo de 2006). IPv6 Essentials (Second edición). O'Reilly. ISBN 978-0596100582.

[3] RFC 3956

[4] RFC 3306

[5] RFC 4291

[rfc3306-6] RFC 3306, Unicast-Prefix-based IPv6 Multicast Addresses, B. Haberman, D. Thaler (August 2002)

[rfc3956-7] RFC 3956, Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address P. Savola, B. Haberman (November 2004)

[rfc4489-8] RFC 4489, A Method for Generating Link-Scoped IPv6 Multicast Addresses, J-S. Park, M-K. Shin; H-J. Kim (April 2006)

[rfc5952-9] RFC 5952, "A Recommendation for IPv6 Address Text Representation", S. Kawamura, M. Kawashima, (August 2010)

[rfc3986-10] RFC 3986, Uniform Resource Identifier (URI): Generic Syntax, T. Berners-Lee, R. Fielding, L. Masinter (January 2005)

[rfc4007-11] RFC 4007, IPv6 Scoped Address Architecture, S.Deering, B. Haberman, T. Jinmei, E. Nordmark, B. Zill (March 2005)

[rfc1881-12] RFC 1881, IPv6 Address Allocation Management, Internet Architecture Board (December 1995)

[13] IPv6 address space at IANA

[14] IPv6 unicast address assignments, IANA

[15] r ejemplo, SIXXS Ghost Route Hunter

[16] «IPv6 Addressing Plans». ARIN IPv6 Wiki. Consultado el 18 de agosto de 2010. «All customers get one /48 unless they can show that they need more than 65k subnets. [...] If you have lots of consumer customers you may want to assign /56s to private residence sites.»

[rfc2526-17] RFC 2526,Reserved IPv6 Subnet Anycast Addresses, D. Johnson, S. Deering (March 1999)

[rfc5156-18] RFC 5156, Special-Use IPv6 Addresses, M. Blanchett (April 2008)

[rfc6052-19] IPv6 Addressing of IPv4/IPv6 Translators, doi:10.17487/RFC6052, RFC 6052 . Error en la cita: Etiqueta <ref> no válida; el nombre «rfc6052» está definido varias veces con contenidos diferentes

[rfc6666-20] A Discard Prefix for IPv6, doi:10.17487/RFC6666, RFC 6666 .

[rfc7343-21] An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2), doi:10.17487/RFC7343, RFC 7343 .

[rfc3849-22] IPv6 Address Prefix Reserved for Documentation, doi:10.17487/RFC3849, RFC 3849 . Error en la cita: Etiqueta <ref> no válida; el nombre «rfc3849» está definido varias veces con contenidos diferentes

[rfc7526-23] Deprecating the Anycast Prefix for 6to4 Relay Routers, doi:10.17487/RFC7526, BCP 196. RFC 7526 .

[rfc4193-24] Unique Local IPv6 Unicast Addresses, doi:10.17487/RFC4193, RFC 4193 . Error en la cita: Etiqueta <ref> no válida; el nombre «rfc4193» está definido varias veces con contenidos diferentes

[rfc1918-25] RFC 1978, Address Allocation for Private Internets, Y. Rekhter, B. Moskowitz, D. Karrenberg, G.J. De Groot, E. Lear (February 1996)

[rfc4773-26] RFC 4773, Administration of the IANA Special Purpose IPv6 Address Block, G. Huston (December 2006)

[rfc2928-27] RFC 2928, Initial IPv6 Sub-TLA ID Assignments, R. Hinden, S. Deering, R. Fink, T. Hain (September 2000) The Internet Society

[rfc5180-28] RFC 5180, IPv6 Benchmarking Methodology for Network Interconnect Devices, C. Popoviciu, A. Hamza, G. Van de Velde, D. Dugatkin (May 2008)

[rfc4843-29] RFC 4843 (experimental), An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers (ORCHID), P. Nikander, J. Laganier, F. Dupont (April 2007)

[rfc5737-30] RFC 5737, IPv4 Address Blocks Reserved for Documentation, J. Arkko, M. Cotton, L. Vegoda (January 2010), ISSN 2070-1721

[31] IANA Internet Protocol Version 6 Multicast Addresses. Internet Assigned Numbers Authority.

[rfc4862-32] RFC 4862, IPv6 Stateless Address Autoconfiguration, S. Thomson, T. Narten, T. Jinmei (September 2007)

[rfc4861-33] RFC 4861, Neighbor Discovery for IP version 6 (IPv6), T. Narten, E. Nordmark, W. Simpson, H. Holiman (September 2007)

[34] Iljitsch van Beijnum (2006). «IPv6 Internals». The Internet Protocol Journal 9 (3). pp. 16-29. Archivado desde el original el 7 de junio de 2011. Consultado el 10 de febrero de 2011.

[35] The privacy implications of stateless IPv6 addressing

[rfc4941-36] RFC 4941, Privacy Extensions for Stateless Address Autoconfiguration in IPv6, T. Narten, R. Draves, S. Krishnan (September 2007)

[rfc3484-37] RFC 3484, Default Address Selection for Internet Protocol version 6 (IPv6), R. Draves, The Internet Society (February 2003)

[38] Formats for IPv6 Scope Zone Identifiers in Literal Address Formats

[39] RFC 4074 Common Misbehavior Against DNS Queries for IPv6 Addresses, Y. Morishita, T. Jinmei. May 2005.

[rfc1884-40] RFC 1884, IP Version 6 Addressing Architecture, R. Hinden, S. Deering ()

[rfc3879-41] RFC 3879, Deprecating Site Local Addresses, C. Huitema, B. Carpenter ()

[rfc4147-42] RFC 4147, Proposed Changes to the Format of the IANA IPv6 Registry, G. Houston ()

[rfc1888-43] RFC 1888, OSI NSAPs and IPv6, J. Bound, B. Carpenter, D. Harrington, J. Houldsworth, A. Lloyd ()

[rfc4048-44] RFC 4048, RFC 1888 Is Obsolete, B. Carpenter ()

[rfc2471-45] RFC 2471, IPv6 Testing Address Allocation, R. Hinden, R. Fink, J. Postel ()

[rfc3152-46] RFC 3152, Delegation of IP6.ARPA, R. Bush ()

[rfc3701-47] RFC 3701, 6bone (IPv6 Testing Address Allocation) Phaseout, R. Fink, R. Hinden ()

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]

[16]

[17]

[18]

[19]

[20]

[21]

[22]

[23]

[24]

[25]

[26]

[27]

[28]

[29]

[30]

[31]

[32]

[33]

[34]

[35]

[36]

[37]

[38]

[39]

[40]

[41]

[42]

[43]

[44]

[45]

[46]

[47]