Cuando en los años 70 se diseñó el principal protocolo de Internet, ipv4, no se pensaba en el

tremendo auge que tendría Internet en el mundo. Ni siquiera se pensaba que la informática tendría
un papel tan destacado ni que hubiese tantos ordenadores en tan breve espacio de tiempo. Prueba de
ello son declaraciones como las siguientes:
• Vint Cerf (uno de los padres de Internet): "Pensé que 4 mil millones de direcciones serían
suficientes".
• Thomas Watson (1943), presidente de IBM: "En el mundo sólo hay mercado para 5
computadoras".
• Ken Olsen, fundador de Digital Equipment: "No hay motivo alguno para que alguien quiera
tener un ordenador en casa".
Alguna de las limitaciones de IPv4 que IPv6 mejora son:
1. Escasez de direcciones (se encuentran prácticamente agotadas y sería así de no ser por
NAT). Esto es debido al mal reparto de direcciones que se hizo antes del auge de Internet,
más que a una escasez real. El mal reparto también influyó sobre el routing.
2. El mecanismo de routing, que es ahora más eficiente. En la actualidad las tablas de
encaminamiento de los troncales de Internet son gigantescas, provocado en gran medida por
una asignación caprichosa de direcciones en su día. Esto es especialmente importante en la
DFZ (Default Free Zone). Además, la cabecera de IPv6 está preparada para ser procesada en
bloques de 64 bits, para mayor eficacia de los procesadores de 64 bits.
3. Uso de protocolos como NAT y DHCP. El ejemplo de NAT es el más claro ejemplo de
protocolo totalmente innecesario si existiesen suficientes direcciones IP en el mundo, como
ocurre con IPv6. NAT es incompatible con el uso de determinados protocolos, como
Kerberos, RTP (Real-Time Trasport Protocol), algunas funcionalidades de IPsec, etc.
4. Necesidad de protocolos 'añadidos' para aumentar su funcionalidad, como QoS o IPsec entre
otros, protocolos que a veces han presentado problemas de incompatibilidad al usar más de
uno de ellos simultáneamente.
El protocolo IPv4 puede albergar un máximo de 4.294.967.296 direcciones, mientras que IPv6
alcanza las 340.282.366.920.938.463.463.374.607.431.768.211.456, una cantidad casi inimaginable
para un ser humano. Con IPv6 es posible dar a cada ordenador una IP pública, sin necesidad de
utilizar NAT (u otras técnicas) y sin importar si está dentro de una red local privada o no.
Paradójicamente, antes de adentrarnos más en IPv6 vamos a ver cómo se desactiva el uso de IPv6
en distribuciones Linux:
sysctl -w net.ipv6.conf.eth0.autoconf=0
o
sysctl -w net.ipv6.conf.all.autoconf=0
Formato de una dirección IPv6. Extraído del RFC4291.
De forma semejante a las direcciones IPv4 donde se tenía una parte de red y otra de host, en IPv6 se
tienen también dos partes. La parte 'de red' recibe aquí el nombre de prefijo mientras que la parte de
host se denomina Identificador de Interfaz o IID (ver RFC7136).
Las direcciones IPv6 se representan en hexadecimal mediante el siguiente formato:
xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx. Donde cada x representa un dígito en notación
hexadecimal. No está prohibido el uso de mayúsculas para representar los caracteres en
hexadecimal de una IPv6, aunque el RFC 5952 advierte de posibles problemas de legibilidad al usar
mayúsculas, ya que la 'D' se puede confundir con un '0' y la 'B' con un '8' e indica que se deben usar
minúsculas (apartados 3.4.3 y 4.3.).
Este formato es "comprimible" mediante varias opciones, recogidas también en el RFC 5952:
Quitando los ceros a la izquierda en cada grupo de 4 dígitos en hexadecimal que aparezca separado
por ':' (dos puntos). Ejemplo: la dirección 3ffe:0b80:1b64:0001:0000:0000:0000:0002 se representa
normalmente así: 3ffe:b80:1b64:1:0:0:0:2, acortando su longitud. Se sigue la indicación de que los
ceros a la izquierda no tienen valor en cada grupo de 4 dígitos en hexadecimal (en cada grupo de
16-bits).
Eliminando una cadena de ceros consecutivos que aparezca en la dirección. Sólo se puede eliminar
una única cadena de ceros, por lo que si hay más de una cadena consecutiva de ceros se tendrá que
elegir por eliminar sólo una de ellas, normalmente la más larga. Por ejemplo, la dirección
3ffe:b80:1b64:1:0:0:0:2 puede comprimirse como 3ffe:b80:1b64:1::2, que es bastante más corto.
La dirección de loopback, que en IPv4 es "127.0.0.1" es, en IPv6, ::1 (0:0:0:0:0:0:0:1).
IPv4 e IPv6 pueden convivir juntas. Una dirección IPv4 puede 'convertirse' en una dirección IPv6
mediante la nomenclatura ::ffff:w.x.y.z, siendo w.x.y.z la dirección en formato IPv4. De este modo
se puede alcanzar una dirección IPv4 utilizando redes IPv6.
Representación de direcciones en IPv6
La representación de las direcciones IPv6 sigue el siguiente esquema:
Forma 1ª o notación extendida: Se representa como X:X:X:X:X:X:X:X, donde “X” es un valor en
hexadecimal de 16 bits, de la porción correspondiente a la dirección IPv6. No es preciso escribir los
ceros a la izquierda de cada campo. 
Ejemplos:
fedc:ba98:7654:3210:fedc:ba98:7654:3210
2080:0:0:0:8:30:20a:428b
Como no es necesario poner los ceros a la izquierda de cada uno de los campos, la dirección
2010:0e67:0432:0:0:0:0:0123 puede (y debe) escribirse: 2010:e67:432:0:0:0:0:123
Forma 2ª o notación comprimida (Zero Compression): Dado que, por el direccionamiento que se
ha definido, podrán existir largas cadenas de bits “cero”, se permite la escritura de su abreviación,
mediante el uso de “::”, que representa múltiples grupos consecutivos de 16 bits “cero”. Este
símbolo sólo puede aparecer una vez en la dirección IPv6. En caso de que haya más de un grupo de
ceros se debe usar el más largo para comprimirlo. Si son de igual longitud, el RFC 5952 da
flexibilidad para que se pueda elegir cualquiera de las opciones, pero recomienda comprimir el
primer grupo.
Ejemplos:
Las direcciones:
2080:0:0:0:8:30:20a:428b (una dirección unicast)
ff01:0:0:0:0:0:0:101 (una dirección multicast)
0:0:0:0:0:0:0:1 (la dirección loopback)
0:0:0:0:0:0:0:0 (una dirección no especificada)
Pueden representarse como:
2080::8:30:20a:428b (una dirección unicast)
ff01::101 (una dirección multicast)
::1 (la dirección loopback)
:: (una dirección no especificada)
Nota: El RFC5952 hace una recomendación de que no se utilice esta compresión para un único
grupo de ceros de 16 bits, de cara a facilitar la legibilidad por el ser humano, a pesar del RFC4291
que no decía nada al respecto.
Forma 3ª o notación mixta: Otra forma muy conveniente en entornos mixtos IPv4/IPv6, es
x:x:x:x:x:x:d.d.d.d, donde “x” representa valores hexadecimales de 16 bits (6 porciones de mayor
peso), y “d” representa valores decimales (estándar IPv4) de las 4 porciones de 8 bits de menor
peso. 
Ejemplos:
Las direcciones:
0:0:0:0:0:0:d01:4403
0:0:0:0:0:ffff:8190:3426
Pueden representarse como:
::13.1.68.3
::ffff:129.144.52.38
Representación de un socket en IPv6
Son representaciones válidas de dirección y puerto en IPv6 según el RFC5952 las siguientes:
• [2001:db8::1]:80
• 2001:db8::1:80
• 2001:db8::1.80
• 2001:db8::1 port 80
• 2001:db8::1p80
• 2001:db8::1#80

Se recomienda usar el primero, pero todos son admisibles. Así nos podemos encontrar casos como:
:::80
que sería la forma comprimida de:
0:0:0:0:0:0:0:0:80
y podría representar el puerto 80 en cualquier interfaz IPv6 disponible.
Representación de prefijos
En IPv6 a la parte de red se le denomina prefijo. Un prefijo se representa de modo similar a cómo se
representaban las direcciones de red en IPv4 con CIDR, es decir, la dirección se rellena con ceros
hasta el final y a continuación y separado por una barra se indica la longitud del prefijo. Ejemplo
(extraído del RFC): Las siguientes son formas válidas (o legales en terminología original) de
representar un prefijo:
• 2001:db8:0000:cd30:0000:0000:0000:0000/60
• 2001:db8::cd30:0:0:0:0/60
• 2001:db8:0:cd30::/60

Sin embargo las siguientes formas no son 'legales' (respecto al prefijo representado anteriormente):
• 2001:db8:0:cd3/60: porque no se incluye la dirección completa. Además no corresponde a
los prefijos anteriormente representados al quitarle un cero al final de un bloque de 16-bits.
• 2001:db8::cd30/60: porque no se expandiría en 2001:db8:0:0:0:0:0:cd30/60
• 2001:db8::cd3/60: por motivos citados en los anteriores

Autoconfiguración IPv6
Existen dos modos de autoconfiguración en IPv6:
1. Autoconfiguración con estado o statefull: es semejante a la existente en IPv4 y se realiza
mediante DHCP, en este caso DHCPv6. Para aprender más consultar el rfc sobre
DHCPv6 RFC 3315.
2. Autoconfiguración sin estado o stateless: IPv6 es capaz de asignar direcciones en función de
la dirección MAC del dispositivo de red. El proceso es el siguiente:
1. El host crea primero una dirección local de enlace. Esto se logra tomando el prefijo
local de enlace de 10 bits (1111 1110 10), agregándole 54 ceros y agregándole el
identificador de interfaz de 64 bits, que cualquier host sabe cómo generar a partir de
su tarjeta de interfaz. El resultado es una dirección de enlace local de 128 bits.
2. El host luego verifica que la dirección local de enlace sea única y no esté siendo
usada por otro host. Como se supone que el identificador de interfaz es único, la 
dirección local de enlace generada es única con una gran probabilidad. Sin embargo,
para estar seguro, el host envía un neighbor solicitation message y espera un
neighbor advertisement message. Si algún host en la subred está usando esta
dirección local de enlace, el proceso falla y el host no puede autoconfigurarse,
necesita usar otro medio como DHCP para este propósito.
3. Si se pasa la prueba de unicidad de la dirección local de enlace, el host almacena esta
dirección  como  su  dirección  local  de  enlace  (para  comunicación  privada),  pero
aún necesita una dirección unicast global. El host entonces envía un router
solicitation message a un enrutador local. Si existe un enrutador corriendo en la red,
el host recibe un router advertisement message que incluye el prefijo unicast  global
y el prefijo de subred que el host necesita para agregar a su identificador de interfaz
para generar su dirección unicast global. Si el enrutador no puede ayudar al host con
la configuración, éste informa al host en el router advertisement message. El host
entonces necesita usar otros mecanismos para su configuración.
Visto de forma práctica
Supongamos la MAC: 00:1e:33:3b:5a:94
Los últimos 6 dígitos en hexadecimal (24 bits) se corresponden con los últimos de la dirección
IPv6:
xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xx3b:5a94
Los 4 anteriores en hexadecimal serán fffe según marcan los RFCs:
xxxx:xxxx:xxxx:xxxx:xxxx:xxff:fe3b:5a94
Para los 6 dígitos anteriores en hexadecimal se usan los 6 primeros de la MAC, pero con una
variación en el primer byte. La variación consiste en complementar el segundo bit menos
significativo, llamado bit 'u', bit 'u/l' o bit universal/local debido a que se puede usar para indicar el
alcance o ámbito (scope) de la dirección. En nuestro caso el primer byte es 00, lo que en binario
sería 00000000. Al complementar el segundo bit menos significativo se obtendría: 00000010.
La dirección IPv6 va quedando así:
xxxx:xxxx:xxxx:xxxx:021e:33ff:fe3b:5a94
Con esto se completa el identificador de host, pues se usa máscara /64. El valor resultante,
equivalente en nuestro ejemplo a:
021e:33ff:fe3b:5a94
recibe el nombre de Modified EUI-64 o Interfaz Única Extendida Modificada.
El prefijo de red es el de una dirección unicast local de enlace:
fe80:0000:0000:0000:021e:33ff:fe3b:5a94
Podríamos comprimir esta dirección tal y como vimos con anterioridad, primero eliminando el cero
a la izquierda del 5º byte:
fe80:0000:0000:0000:21e:33ff:fe3b:5a94
Y posteriormente comprimiendo la cadena de ceros:
fe80::21e:33ff:fe3b:5a94
Una imagen vale más que mil palabras:

Además, la dirección unicast local de enlace autoconfigurada sin estado se considera provisional
hasta que se comprueba que no hay vecinos con la misma dirección. Esto se realiza mediante
mensajes ICMPv6 de Neighbor Solicitation. Si un host responde con la misma IP se suspende la
autoconfiguración y necesitaría ser configurada de forma manual o vía DHCP6.
Una vez configurada la IP el host intenta comunicar con los enrutadores. El prefijo de red se
completa con la información obtenida de los routers, siempre y cuando estos lo difundan mediante
mensajes ICMPv6. Si no lo hacen, el host intentará una autoconfiguración con estado, que sólo será
posible si hay un servidor DHCPv6 a la escucha.
El segundo bit menos significativo del IID o Identificador de Interfaz, como hemos visto, recibe el
nombre de bit 'u' y puede contener un valor de cero para indicar ámbito local o de 1 para indicar
ámbito universal.
El bit menos significativo es el bit de grupo (group) o bit 'g' e identifica cuando una dirección es
individual o de grupo, es decir, si identifica a una sola interfaz o no.

NOTA: Sistemas Windows

Tipos de direcciones:
• Unicast: Consiste en el envío de información a un único destinatario. Es equivalente al
usado en IPv4. Todas las direcciones unicast salvo las que comiencen con 000 deben utilizar
una máscara /64 según se indica en los RFCs.
• Anycast: la información se envía a 'uno cualquiera'. Teóricamente llegará al mejor destino
posible de la red. Generalmente es el más cercano o primero en responder. En Internet, una
dirección IP se puede alcanzar desde varios puntos diferentes. Los routers intermedios
encaminan el paquete hasta el destino más cercano. Por ejemplo 3ffe:b80:1daf:1::/64 es un
identificador anycast de un 6bone. Un paquete enviado a una dirección anycast es recibido y
procesado por el host con menor tiempo de latencia.
Estas direcciones son nuevas en IPv6 y permiten proveer de un mecanismo de redundancia,
de forma que otro host pueda hacerse cargo de determinado tráfico si otro cae.
• Multicast: es el envío de información a múltiples destinatarios. En la actualidad el multicast
sólo se puede usar en ambientes corporativos y se aplica sólo para transmisiones en vivo.
La multidifusión envía los mensajes sobre cada enlace de la red sólo una vez cuando el
camino es el mismo para todos los destinatarios y crea copias cuando los caminos para
alcanzar los diferentes destinatarios se dividen. Esto lo hace más eficiente y reduce el
tráfico.
Antes del envío de la información, deben establecerse una serie de parámetros. Para poder
recibirla, es necesario establecer lo que se denomina "grupo multicast". Ese grupo multicast
tiene asociado una dirección de internet.
Como se puede ver, en IPv6 no existen direcciones broadcast (su función es sustituida por
direcciones multicast).
Tipos de direcciones IPv6 con direcciones IPv4 embebidas
Se definen dos tipos:
 • Mapeadas a IPv4
Una dirección indicando un nodo IPv6 con una dirección que se puede mapear unívocamente al espacio IPv4.
Tienen el prefijo IP 0:0:0:0:0:ffff. Por ejemplo, 0:0:0:0:0:ffff:9.180.214.114. Por ejemplo un desarrollador de
software puede implementar una aplicación sólo para IPv6 pero dicha aplicación puede funcionar para IPv4 con
direcciones mapeadas.

• Compatibles con IPv4

Una dirección IPv6 que indica un nodo sólo IPv4. Tienen el prefijo IP 0:0:0:0:0:0. Por
ejemplo, 0:0:0:0:0:0:9.180.214.114. Las direcciones compatibles con IPv4 y las mapeadas a
IPv4 utilizan el mismo espacio de direcciones. El prefijo sólo indica si el nodo soporta o no
IPv6. Las direcciones compatibles con IPv4 se consideran ya obsoletas.

El resto son sólo IPv6. En una dirección sólo IPv6 los 32 bits de menor peso no contienen
necesariamente una dirección IPv4. Los 96 bits de orden superior son distintos de 0:0:0:0:0:ffff o
0:0:0:0:0:0.

Espacio de direcciones
Según el RFC4291 el espacio de direcciones queda así:

Localización Prefijo Fracción del espacio

(en binario) de direcciones

Reservado 0000 0000 1/256

No Asignado 0000 0001 1/256

Reservado para NSAP 0000 001 1/128

Reservado para IPX 0000 010 1/128

No Asignado 0000 011 1/128

No Asignado 0000 1 1/32

No Asignado 0001 1/16

Direcciones Unicast Globales Agregables 001 1/8

No Asignado 010 1/8

No Asignado 011 1/8

No Asignado 100 1/8

 No Asignado 101 1/8

No Asignado 110 1/16

No Asignado 1110 1/32

No Asignado 1111 0 1/64

No Asignado 1111 10 1/128

No Asignado 1111 110 1/512

Direcciones Unicast Locales de Enlace 1111 1110 10 1/1024

Direcciones Unicast Locales de Sitio 1111 1110 11 1/1024

Direcciones Multicast 1111 1111 1/256

Como se puede apreciar se diferencian las direcciones Multicast de las Unicast, pero no ocurre lo
mismo con las Anycast. Las direcciones Anycast se toman del espacio de direcciones Unicast.
Direcciones especiales:

:: Se emplea en el arranque, cuando no hay dirección.

::1 Es la dirección de loopback

::1.2.3.4 Direcciones compatibles ipv4. No se suelen emplear.

::xxxx:xxxx Direcciones compatibles con IPv4. Se emplean para

túneles dinámicos IPv6 sobre IPv4. Permiten que
tráfico IPv6 se transmita por redes IPv4.

::ffff:xxxx:xxxx Direcciones mapeadas. Permiten que nodos que sólo

soportan IPv4 puedan trabajar en redes IPv6

fe8x:, fe9x:, feax, febx El prefijo de enlace local (link local) específica que
la dirección sólo es válida en el enlace físico local.

fecx:, fedx:, feex:, fefx El prefijo de sitio local (site-local prefix) indica que
la dirección sólo es válida dentro de un ámbito local.
El RFC 3879 lo declaró obsoleto, estableciendo que
los sistemas futuros no deben implementar ningún
soporte para este tipo de dirección especial. Se
deben sustituir por direcciones Local IPv6 Unicast.

ffxx:: Prefijo de multicast.

Nota importante: No existen las direcciones de difusión amplia (broadcast) en IPv6. En su lugar se
usa la dirección multicast ff01::1.
Cabecera IPv6
El formato de la cabecera es el siguiente:

4 12 16 24 32

Versión Prioridad Etiqueta de flujo

Longitud de la carga útil Siguiente Límite de saltos

cabecera

Dirección de origen (128 bits)

Dirección de destino (128 bits)

• Versión: tiene un valor igual a 6.

• Prioridad o Clase de tráfico (Priority or Traffic Class): Equivalente a ToS de IPv4.

• Etiqueta de flujo (flow label): Se emplea para gestionar tráfico en tiempo real.

• Longitud de la carga útil (payload length): Como su nombre indica, el tamaño de los datos.

• Siguiente cabecera (next header): Se utilizan cabeceras encadenadas de longitud fija, por lo
que desaparece además el campo de opciones.
• Límite de saltos (hop limit): Equivalente al TTL de IPv4.

La cabecera IPv6 es más grande que la cabecera IPv4, debido principalmente a que se cuadruplica
el tamaño de las direcciones (origen y destino). Sin embargo es más fácil de procesar debido a su
menor número de campos (de 12 a 8). Además tiene un formato adecuado para ser manejada por los
procesadores de 64 bits.
Los campos Priority y Flow Label permiten que IPv6 integre QoS (Quality of Service), CoS (Class
of Service), etc.
Como se puede apreciar se han eliminado los siguientes campos:
• Checksum: No es función de este nivel proveer de un mecanismo de control de errores.

• Fragmentación: Ahora se tiene que producir entre los extremos y se maneja mediante
mensajes ICMPv6. Desaparecen así los campos Identificación, Indicadores y Posición del
fragmento, aunque se incluyen (estos o similares) en la cabecera de fragmentación
(Fragment header).
• Header y Opciones: Ya no son necesarios con las cabeceras encadenadas de longitud fija.
Mediante el campo next header se pueden encadenar cabeceras, como se indica en el RFC 2460. De
esta forma, a fin de que el procedimiento de la cabecera del datagrama IP sea más rápido, se ha
dividido la cabecera del protocolo IPv6 en una cabecera básica y una o más cabecera de extensión.
Algunos ejemplos:
• Cabecera típica conteniendo protocolo del nivel de transporte:

IPv6 header TCP header + data

Next Header = TCP

• Cabecera de routing:

IPv6 header Routing header TCP header +

data
Next Header = Routing Next Header = TCP

• Cabecera de paquete fragmentado:

IPv6 header Routing header Fragment header Fragment of

TCP.
Next Header = Routing Next Header = Fragment Next Header = TCP
TCP header
+ data

Consideraciones sobre las cabeceras IPv6

• En un paquete IPv6 puede haber cero, una o más cabeceras de Extensión.
 • Estas cabeceras se sitúan entre la cabecera IPv6 (básica) y la cabecera del protocolo de la
capa superior (capa de transporte).
• Las cabeceras existentes deben ser procesadas en el orden exacto en que aparecen en la
cabecera del paquete.
• En un paquete IPv6 puede haber cero, una o más cabeceras de Extensión.
• Estas cabeceras se sitúan entre la cabecera IPv6 y la cabecera del protocolo de la capa
superior (capa de transporte).
• Las cabeceras existentes deben ser procesadas en el orden exacto en que aparecen en la
cabecera del paquete.
• Cada cabecera de Extensión es identificada por el campo “Next Header” de la cabecera
precedente.
• Las cabeceras de Extensión son examinadas o procesadas solo por el nodo identificado en el
campo dirección de Destino de la cabecera IPv6...
... con una única excepción:
• Si la cabecera de Extensión es del tipo Opciones Hop-by-Hop, la información que lleva debe
ser examinada y procesada por cada uno de los nodos que se encuentran en la ruta del
paquete.
• Este tipo de cabecera debe seguir inmediatamente a la cabecera IPv6 y su valor de "Next
Header" es 0.
• Si en el campo "Dirección de destino" hay una dirección multicast, las cabeceras de
Extensión serán examinadas y procesadas por todos los nodos que pertenezcan al grupo
multicast.
• La longitud de cada cabecera de Extensión es un múltiplo de 8 bytes de forma que,
independientemente del número de ellas que se utilicen, siempre quedan alineadas.
Tipos de cabeceras de extensión
Los 6 tipos de cabeceras de Extensión que se definen en la RFC 2460 son:
• De opción Hop-by-Hop (RFC 2460): La información de esta cabecera debe ser examinada
Salto-a-Salto, es decir, en cada uno de los nodos de la ruta que ha de seguir el paquete.
• De enrutado (RFC 2460): Se utiliza para dar una lista de uno o más nodos que deben estar en
la ruta seguida por un paquete.
• De fragmento (RFC 2460): Un host IPv6 que quiere enviar un paquete a un destino IPv6
utiliza el llamado “Path MTU discovery” para determinar el tamaño máximo de paquete que
se puede utilizar en el path hasta ese destino. Si el paquete que hay que enviar es más grande
que el MTU soportado, el host origen fragmenta el paquete. Gracias a esta forma de actuar,
la fragmentación se gestiona de extremo a extremo, liberando a los routers del path de este
trabajo. En caso de que el "Path MTU discovery" falle, se usará el valor mínimo de "Path
MTU" en IPv6, 1280 bytes. El valor máximo es de 65536 bytes, en los cuales se incluye la
carga o payload del datagrama y los 40 bytes de la cabecera.
• De opciones de destino (RFC 2460): Estas cabeceras llevan información que será procesada,
exclusivamente, por el nodo de destino.
 • De autenticación (AH) (RFC 4302): Proporciona integridad y autenticación (que no
confidencialidad) para todos los paquetes de datos IP. Soporta distintos mecanismos de
autenticación.
• De carga útil de seguridad encriptada (Encrypted Security Payload =ESP) (RFC 4303):
Proporciona integridad, confidencialidad, autenticacion de datos y otras funciones para todos
los paquetes de datos IP.
La flexibilidad de esta arquitectura permitirá el desarrollo de nuevas cabeceras de Extensión en el
futuro, a medida que sean necesarias. Lo bueno de este sistema es que las nuevas cabeceras de
Extensión se pueden definir y usar sin cambiar la cabecera IPv6.
------- Ampliación --------------
Orden de procesamiento de las cabeceras
Si se le pide a un nodo que procese la siguiente cabecera pero no identifica el valor del campo
“Next Header”, descartará el paquete y enviará un mensaje “ICMPv6 Parameter Problem” al equipo
origen del paquete.
Según el RFC 2460, si en un paquete se usa más de una cabecera de Extensión, se debería respetar
el siguiente orden:
1. Cabecera IPv6.
2. Cabecera de Opciones Hop-by-Hop
3. Cabecera de opciones de destino (para opciones que tienen que ser procesadas por el primer
destino que aparece en el campo de dirección de destino, además de los destinos posteriores
enumerados en la cabecera de Routing).
4. Cabecera de enrutamiento (Routing)
5. Cabecera de Fragmento.
6. Cabecera de autenticación (Authentication header).
7. Cabecera de carga útil de seguridad encapsulada (Encapsulating Security Payload)
8. Cabecera de Opciones de Destino (para opciones a ser procesadas solo por el destino final
del paquete)
9. Cabecera de capa superior.
Cuando se encapsula IPv6 en IPv4, la cabecera de capa superior puede ser otra cabecera IPv6 y
puede contener cabeceras de Extensión que tienen que seguir las reglas mencionadas.
----------Fin de la Ampliación ------------------
Algunas diferencias con IPv4:
- Los campos de las direcciones reciben nombres específicos, denominamos “prefijo” a la parte de
la dirección hasta el nombre indicado (incluyéndolo).
- Dicho prefijo nos permite conocer dónde esta conectada una determinada dirección, es decir, su
ruta de encaminado.
- Cualquier campo puede contener sólo ceros o sólo unos (en binario), salvo que explícitamente se
indique lo contrario.
- Las direcciones IPv6, indistintamente de su tipo, son asignadas a interfaces, no nodos.
- Una única interfaz puede tener también varias direcciones IPv6 de cualquier tipo (unicast, anycast
o multicast) o ámbito.
- Al igual que en IPv4, se asocia un prefijo de subred con un enlace, y se pueden asociar múltiples
prefijos de subred a un mismo enlace.
Fragmentación
En ipv6, si un router recibe un datagrama mayor de lo que puede enviar, lo descarta y avisa al
emisor mediante un ICMP (en ipv4 lo fragmentaba y lo enviaba, con lo cual si se perdía un
fragmento había que retransmitir todo). Ahora es el emisor el que tiene que realizar la
fragmentación, liberando a los routers de este trabajo, y debe adaptarse a la MTU que le indique el
router en el paquete ICMP. Estos paquetes ICMP son ICMPv6, la versión soportada por ipv6. El
emisor agrega un nuevo encabezado llamado encabezado de fragmentación, que contiene
información de cada fragmento que se envía.
Neighbor Discovery Protocol (Descubrimiento de vecinos o descubrimiento próximo de hosts)
El NDP aparece desarrollado en el RFC 4861.
NDP realiza las siguientes funciones:
1. Viene a sustituir a ARP como protocolo que permite contactar con los hosts 'vecinos', es
decir, los que se encuentran directamente conectados a nivel de enlace. En realidad no es un
protocolo de red al uso, con una implementación independiente como sí lo era ARP, sino que
se limita a emplear mensajes ICMPv6 para llevar a cabo su misión. Por lo demás el
protocolo funciona de forma similar, creando tablas de correspondencia IPv6 – dirección
física.
2. NUD (Neighbor Unreachability Detection). Esta es una función que no existía en ipv4 y que
permite eliminar entradas de la tabla de enrutamiento si falla el enlace correspondiente.
3. Configuración automática:
• Descubrimiento de enrutadores: los routers pueden responder a solicitudes enviadas
por los clientes indicándoles su presencia como posible gateway de esa red.
• Descubrimiento de prefijos: Los enrutadores son los que divulgan los prefijos de red
mediante mensajes ICMPv6, de forma que un host puede autoconfigurarse utilizando
dicho prefijo para la parte de red de la dirección y usando la MAC para la parte de
host.
• Detección de direcciones ip duplicadas. En IPv6 existe mayor riesgo de duplicidad
de direcciones ya que pueden autoconfigurarse. Esta función es semejante al envío de
paquetes Gratuitous ARP.
• Cuando se detecta duplicidad de direcciones se observa lo siguiente
(ejemplo de salida del comando ip a):
inet6 2001:470:50ab:ac06::104/64 scope global dadfailed tentative
• Descubrimiento de parámetros, como el valor de MTU, si se utiliza configuración de
direcciones con estado (mediante DHCPv6), etc Esto no existía en IPv4.
4. Redirección: Esta funcionalidad también existía parcialmente en IPv4 y también se realizaba
mediante mensajes ICMP Redirect. Sin embargo, en IPv4 cada host debía conocer su
gateway y los mensajes ICMP Redirect sólo servían a modo informativo en la práctica.
¿Y cómo se relacionan las direcciones de nivel de enlace con las direcciones IPv6?
No hay ARP en IPv6. Sin embargo algún mecanismo debe existir para que un host pueda saber qué
dirección IP se asocia con qué dirección MAC (o viceversa). Esto es necesario para la
comunicación en el nivel de enlace.
ARP utiliza broadcast para enviar un ARP Request. Pero en IPv6 no existe el broadcast.
En lugar de ARP se utiliza el Neighbor Discovery Protocol, que proporciona el mecanismo para
asociar una ipv6 con su correspondiente MAC. Se usa multicast para los paquetes neighbor
Solicitation que serían como los equivalentes a los ARP Request que se emplean en IPv4. Si IGMP
está activo ningún nodo IPv4 podrá ver estos paquetes.
Las duplas dirección IPv6 - dirección MAC se almacenan en una tabla llamada Neighbor table. Esta
tabla es la equivalente en IPv6 de la tabla ARP usada en IPv4.
Al igual que sucede con la tabla ARP la Neighbor table también es dinámica y va cambiando. Se
envían paquetes Neighbor Solicitation cada vez que son necesarios y con la información recibida en
los paquetes de respuesta, que son paquetes Neighbor Advertisement, se mantiene la Neighbor
table.
En el momento en el que un router se añade a la red envía un Router Advertisement que contiene:
• Mac del router
• Prefijo de la red
• Parámetros que indican al host como conseguir su IPv6
• SLAAC
• Manual
• DHCP

Por su parte las estaciones envían un Neighbor Advertisement con:

• MAC de la estación
• IPv6 de la estación
• Opciones

Comandos a conocer:
En linux: ip neigh show
En Windows es muchísimo más facil e intuitivo: netsh interface ipv6 show neighbors interface
“INTERFACE“
ICMPv6
Los mensajes ICMPv6 que se emplean para estas funciones se pueden ver en el RFC 2461. Están
enumerados en la siguiente tabla:

Tipo Mensaje ICMPv6

133 Router Solicitation

134 Router Advertisement

 135 Neighbor Solicitation

136 Neighbor Advertisement

137 Redirect

NOTA: Por supuesto que existen muchos otros mensajes ICMPv6, como el echo Request, el Echo
Reply, etc, pero en la tabla anterior se han incluido sólo unos pocos que se emplean para
descubrimiento de vecinos y autoconfiguración.
Routing IPv6
El modelo de enrutamiento en IPv6 es jerárquico, es decir, las direcciones dependen
estrictamente de la topología de la red.
Un router procesa los paquetes IPv6 de forma parecida a lo que hace con IPv4, pero no igual.
Cuando recibe una trama (nivel de enlace) mira el protocolo que viene encapsulado dentro y si es
IPv6 comprueba si tiene información de ruteo para la dirección de destino especificada en el
paquete IPv6. Si varias entradas coinciden, le aplicará la más específica. Por ejemplo, supongamos
que la ip de destino es 8080::30:20A:428B y el router tiene las siguientes entradas en sus tablas de
routing:
8080::/32 via interfaz A
8080::/40 via interfaz B
En este caso se enviará a través de la interfaz B, ya que es más específica.
Si hay más de una ruta para un mismo prefijo se evalúan otras cosas como:
Peso de la ruta: cada ruta tiene asociado un entero entre 0 y 255. Se elige la ruta con menor valor.
Si la ruta fue aprendida mediante un protocolo de enrutamiento interno (como RIP, OSPF o IS-IS) o
mediante un protocolo externo (BGP, por ejemplo). Se prioriza los internos.
El siguiente paso es decrementar, normalmente en una unidad salvo que tenga indicado algo
diferente, el campo Hop-Limit (ver cabecera de IPv6).
Por último se envía el paquete por la interfaz adecuada.
Para realizar un ping mediante IPv6 es preciso indicar la interfaz a través de la cual se realiza.
Ejemplos:
ping fe80::5549:3176:540a:3e09%eth0
ping fe80::5549:3176:540a:3e09%1
En ambos casos se emplea el signo del % para indicar a continuación la interfaz.
Es posible que necesitemos hacer uso del modificador -6 (en Windows) o usar en su lugar el
comando ping6 (en Linux), por ejemplo si lo hacemos especificando un nombre FQDN:
ping6 www.iescierva.net
ping -6 www.iescierva.net