INTERCONEXIÓN DE REDES

CAPÍTULO 4
INTERNET - IPv6

Autor: Dr. Félix F. Alvarez Paliza

Dpto. Telecomunicaciones
UCLV
 72

El protocolo de Interconexión versión 6 (IPv6)

En respuesta a las necesidades de un gran espacio de direcciones, un nuevo protocolo de
Interconexión de Redes (Internet Protocol) comenzó a desarrollarse a partir de la búsqueda de una
nueva generación IP, la misma comenzó con la RFC 1752.
En ella la IETF sentó las bases de los requisitos a alcanzar y posteriormente fueron apareciendo
nuevas propuestas de RFC hasta llegar a la RFC 2460 con IPv6.

IPv6 llegó con campos de direcciones fuente y destino de 128 bits, es decir,
[Link].[Link].[Link].456 direcciones (67 mil billones de direcciones
por cada milímetro cuadrado de superficie del planeta), lo que supone un margen suficiente amplio
de maniobra durante bastante tiempo y no ocurriera lo que Vint Cert pensó en la década de los 70 del
siglo pasado; al crear IPv4 con un campo de direcciones de 32 bits y considerar que con 4.300 millones
direcciones serían suficientes.
En la Figura 4.43 se muestra una comparación de la gama de direcciones entre IPv4 e IPv6.

Fig.4.43 Comparación de la gama de direcciones entre IPv4 e IPv6

La transición a IPv6 ha sido un proceso lento que ha durado varios años, pero ya el 8 de Junio del
2011 se hizo la prueba de fuego con el primer Día Mundial de IP v6 ( World IPv6 Day), donde los cien
sitios web más visitados del mundo (Yahoo!, Facebook, Bing, Akamai, Google y otros) durante 24
horas ofrecieron sus servicios bajo direcciones IPv6 para comprobar que todo marcha correctamente
y que esta transición con su avance, apenas afecta a los usuarios.

El 6 de junio de 2012 quedó en la historia como el día en que Internet cambió para siempre y se
comenzó a usar en forma masiva IPv6,
El Lanzamiento Mundial de IPv6 consistió en el mayor esfuerzo global para habilitar la nueva
tecnología de la red. Desde ese día miles de sitios ofrecen su contenido y pueden ser accedidos a
través del protocolo IPv6. Las principales organizaciones y compañías de Internet de todo el mundo
(proveedores de acceso, proveedores de servicios, fabricantes de hardware, sistemas operativos y de
equipos de redes domésticas) se involucraron en la iniciativa y comenzaron a utilizar el nuevo protocolo
de Interconexión.
Durante años ha estado ocurriendo la transición de IPv4 a IPv6, pero no queda ninguna duda de que
el siglo XXI es el siglo de IPv6.
Se puede resumir que la aparición del protocolo IPv6 está dado por las insuficiencias de IPv4:
 Agotamiento de direcciones
Notas del Profesor Titular, Dr. C. Ing. Félix F. Alvarez Paliza, Dpto. Telecomunicaciones, UCLV
 73

 Explosión de las tablas de rutas

 Seguridad deficiente
 No ofrecía Calidad de Servicio (QoS)
 No previsto para tráfico en tiempo real y movilidad

El diseño de IPv6, como es lógico influenciado por IPv4, dejando lo malo y tomando lo bueno, teniendo
el mismo entre sus aspectos más significativos:
 Un formato sencillo
 Etiqueta de flujo
 El soporte de extensiones y opciones mejoradas
 Extensiones de Autenticación y Seguridad
 Incremento del campo de dirección a 128 bits.
 Autoconfiguración de las direcciones IP.
 Enrutamiento de multidifusión mejorado.
 Incorporación del direccionamiento tipo Anycast

Formato del Encabezado IPv6

En la RFC 2460 se especifica el Protocolo IPv6 (Internet Protocol, IPv6), donde el encabezado o
cabecera del protocolo IP versión 6 no es mas que una evolución de la versión 4, en la misma no se
han introducido grandes cambios de contenido o estructura, sino que simplemente se ha mejorado y
optimizado con los conocimientos y experiencias adquiridas durante años.
En la misma se han dejado 40 octetos y 8 campos, se han suprimido algunos campos redundantes u
obsoletos y se han ampliado algunas características para hacer frente a las nuevas necesidades de
los usuarios, tal como se aprecia en la Figura 4.44.

Fig.4.44 Estructura del encabezado de un Paquete IPv6.

La nueva estructura de la cabecera del protocolo IP versión 6 se caracteriza principalmente por dos
particularidades:
1. Direcciones de 128 bits. Se ha creado una nueva estructura de direccionamiento que aumenta
su tamaño de 32 bits a 128 bits. Este aumento es consecuencia del gran aumento que ha sufrido
INTERNET en los últimos años, agotando el número de direcciones existentes y colapsando las
tablas de encaminamiento de los Enrutadores (Routers).

2. Encabezado de longitud fija. Con el objetivo de minimizar el tiempo necesario para procesar
y encaminar los paquetes por INTERNET, se adopta un formato fijo. De esta forma se agiliza el
tráfico de paquetes y se suprimen opciones poco utilizadas. No obstante se mantiene la

Notas del Profesor Titular, Dr. C. Ing. Félix F. Alvarez Paliza, Dpto. Telecomunicaciones, UCLV
 74

posibilidad de especificar opciones, pero ya sin formar parte de la cabecera IP como ocurría
anteriormente.
El protocolo IP versión 6 sigue siendo al igual que las versiones anteriores, un protocolo no fiable y
sin conexión.

Fig.4.45 Comparación de campos IPv4 e IPv6

En la figura 4.45 se observa que el único campo que se mantiene en la misma posición y con el mismo
significado que en formatos anteriores es el de versión, debido a que durante el tiempo de implantación
de la nueva versión convivirán simultáneamente la Versión (identifica 4 o 6). De esta forma, los
Enrutadores podrán determinar rápidamente si el paquete que reciben es de una versión u otra.
Se han suprimido seis campos (tamaño de cabecera, tipo de servicio, número de identificación del
paquete, banderas, numero de octetos del paquete fragmentado y el chequeo de error o suma chequeo
del encabezado) respecto la versión 4 del protocolo IP.

A continuación se analizarán los diferentes campos de la cabecera de un paquete IPv6:

El campo de Clase de Tráfico (Class), consta de 8 bits que permiten asignar diferentes tipos de
categorías o prioridades a los paquetes. Este campo es una de las nuevas aportaciones para
conseguir algunos tipos de aplicaciones (videoconferencia, telefonía...) puedan realizarse en tiempo
real.
El campo de Etiqueta de flujo (Flow Label), consta de 20 bits que permiten especificar que una serie
de paquetes deben recibir el mismo trato. Esto es aplicable por ejemplo a una serie de paquetes que
van del mismo origen al mismo destino y con las mismas opciones. Junto con el campo de clase (Class)
permiten aplicaciones en tiempo real (ver nuevas RFC 6437 y 6436 que eliminan la RFC 3697 y
actualizan la RFC 2460).
El campo de Longitud del campo de datos o carga útil (Payload Length), consta de 16 bits que
permiten identificar el tamaño del campo de datos en octetos (no incluye el encabezado pues este es
de tamaño fijo ahora). Un tamaño máximo de datos permisible es de 2^16 = 65536 bytes (64K).

El campo de Límite e Saltos (Hop Limit), consta de 8 bits que indican el número máximo de
Enrutadores (Routers) que puede atravesar un paquete hasta llegar a su destino. Este campo es el
equivalente al tiempo de vida (TTL) de la versión 4.
Cuando un paquete llega a un Enrutador y es conducido hacia otro Enrutador, este campo es
disminuido en una unidad. Este campo es necesario para evitar que los paquetes circulen infinitamente
por la red, eliminándose al llegar a 0 (su valor máximo es de 2^8 = 256).

Notas del Profesor Titular, Dr. C. Ing. Félix F. Alvarez Paliza, Dpto. Telecomunicaciones, UCLV
 75

De este tamaño podemos deducir que para que exista comunicación entre dos estaciones conectadas
a INTERNET deben de estar alejadas como máximo por 255 saltos.
Es sorprendente que aunque se haya ampliado considerablemente (de 32 bits a 128 bits) el número
de estaciones que pueden conectarse a INTERNET, se mantenga la esperanza de que la distancia
entre dos estaciones no pasará ese valor.
Los protocolos de nivel superior (TCP, UDP...) pueden a su vez implementar algún tipo de control
sobre los paquetes duplicados o huérfanos, utilizando por ejemplo un sistema de control del tiempo
usando relojes con marcas de tiempo (timestamps) como se define en [RFC1323].

El Campo de la Próxima Cabecera o Encabezado siguiente (Next Header) es un valor de 8 bits

que indica al router si tras el paquete tiene algún tipo de extensión u opción, tal como se muestra en
la Figura 4.46.

Fig. 4.46 Paquete IPv6 con cabecera de 40 Bytes y la extensión de Cabecera (NH)

A los paquetes IPv6 con carga (payload) superiores a 65535 octetos (Bytes) se les denomina
Jumbogramas, aspecto que se abordará más adelante.
Las extensiones de cabecera son de longitud variable y dentro de cada una de ella va a estar presente
el campo de “Próxima Cabecera” (Next Header).
Este campo tiene valores compatibles con aquellos especificados por el campo de protocolo de IP
versión 4 pero con algunas diferencias. En IPv6 se definen una serie de cabeceras de extensión que
se colocan justo después de los datos en forma de cadena (daisy chain) y que permiten al usuario
personalizar el tipo de paquete. De tal forma que un paquete puede tener varias extensiones de
cabecera tan solo indicando en el campo de siguiente cabecera de cada una de ellas el tipo de la
cabecera que vendrá a continuación, tal como se muestra en la Fig.4.47.

Fig.4.47. Ejemplo de paquetes IPv6 con diferentes extensiones de cabeceras

Siempre la última extensión va a indicar en el campo NH el protocolo de nivel superior que va en la
carga, por ejemplo si es TCP, UDP, ICMP, etc.

Notas del Profesor Titular, Dr. C. Ing. Félix F. Alvarez Paliza, Dpto. Telecomunicaciones, UCLV
 76

A continuación se muestran valores típicos decimales del campo NH para indicar las extensiones de
cabeceras:

Las extensiones de cabecera de un paquete IPv6, pueden ser una o varias cabeceras consecutivas
pero siguiendo un orden que es importante, y pese a no existir un formato rígido para establecer este
orden, en la RFC 2460 se recomienda el orden siguiente:
1. Extensión de Cabecera de Opciones entre saltos (Hop-by-hop Options Header).
2. Extensión de Cabecera de Opciones de destino (Destination Options Header).
3. Extensión de Cabecera de Encaminamiento (Routing Header).
4. Extensión de Cabecera de Fragmentación (Fragment Header).
5. Extensión de Cabecera de Autenticación (Authentication Header).
6. Extensión de Cabecera de Encapsulado Seguro (Encapsulation security payload)
7. Extensión de Cabecera de Opciones (Destination Options Header).
8. Cabecera de Protocolo de nivel superior (TCP, UDP...).
O sea que las extensiones de cabecera tienen que ser procesadas en orden, tal como se muestra en
la Figura 4.48.

Fig.4.48 Orden típico de las extensiones de cabecera de un paquete IPv6.

A continuación se analizarán las diferentes Extensiones de Cabeceras y sus campos:

 Extensión de Cabecera de Opciones entre Saltos (Hop-By-Hop Options Header).

Notas del Profesor Titular, Dr. C. Ing. Félix F. Alvarez Paliza, Dpto. Telecomunicaciones, UCLV
 77

La extensión de cabecera HBH es utilizada para especificar los parámetros de entrega en cada salto
de la trayectoria de destino. La misma es identificada por el valor 0 en el campo NH del encabezado
de IPv6.
En la Figura 4.49 se muestra la estructura de los campos de Extensión de la cabecera HBH, constando
la misma de tres partes: Próxima cabecera, Longitud de extensión de la cabecera y las opciones.

Fig. 4.49 Estructura de los campos de extensión de cabecera de tipo HBH

Esta extensión de cabecera permite especificar Opciones que serán procesadas por todos los Routers
intermedios. Esta extensión tiene que ser examinada por todo Router, pues la misma especifica si se
manipula o descarta el paquete IPv6.
El valor de la Longitud de la Extensión (Header Extension Length) es el número de bloques de 8 Bytes
en el encabezado de extensión de Opciones HBH, no incluyendo los primero 8 Bytes. Por lo que para
una Opción de HBH con 8 Bytes el campo de longitud será 0.
Una Opción es un conjunto de campos que describen las características específicas de la entrega de
los paquetes y ofrece relleno.
Las opciones son envidas en la cabecera de Opciones de HBH, a su vez cada Opción es codificada
en el formato TLV (type-length-value) muy comúnmente utilizado en los protocolos TCP/IP.

A continuación en la Figura 4.50 se muestra el formato de campo de Opciones, donde se especifica

el tipo de Opción (Option Type), la longitud del campo de Opción (Option Length) y los datos de la
Opción (Option Data).

Fig.4.50 Formato del campo de Opciones

El campo de tipo de Opción identifica la Opción y determina la forma en que serán manipulados los
datos en procesamiento en el nodo. El campo de longitud indica el número de Bytes en la Opción, no
incluyendo los campos de Tipo ni el de Longitud. Los datos de la Opción son los datos asociados con
la Opción.
Opciones de Relleno (Padding Options) son utilizadas para asegurar la demarcación de 8 Bytes.
Entre las Opciones que tiene la extensión de cabecera HBH están:
- Relleno de 1 Byte Pad1
- Relleno de N Bytes PadN
- Para enviar Jumbogramas
- Para alertar Routers (puede ser utilizada por RSVP)
Opción Pad1
La misma es definida en la RFC2460 y es utilizada para insertar un simple Octeto (Byte) de relleno tal
que las Opciones HBH y las de Destino tengan en sus encabezados un límite de 8 Bytes y se cumplan
Notas del Profesor Titular, Dr. C. Ing. Félix F. Alvarez Paliza, Dpto. Telecomunicaciones, UCLV
 78

con los requerimientos de alineación. La Opción Pad1 no tiene requerimientos de alineación y el campo
de Tipo (Option Type = 0). La misma consta de un simple octeto y no tiene nada en los campos de
longitud y valor. Con el tipo de opción a 0 la opción es saltada si no es reconocida y esta no permite
cambios en tránsito.
Opción PadN
También está definida en la RFC 2460 y es utilizada para inserta dos o más octetos de relleno tal que
los encabezados de las opciones HBH y de Destino caigan en la frontera de 8 Bytes y puedan
acomodar las exigencias de alineación de las opciones.
Esta opción PadN tiene un “1” en el campo de Tipo, el campo de Longitud es fijado con el numero de
octetos de rellenos presentes, seguidos de 0 o más octetos de relleno. Con el campo de Tipo en “1” la
opción es saltada si no es reconocida y esta no es permitida que cambie en tránsito.

Jumbogramas (paquete IPv6 mayores de 64KBytes)

Según la RFC 2675, un Jumbograma es un paquete IPV6 que contiene una carga útil de más
de 64.535 Bytes. En la Figura 4.51 se muestra el formato de la opción Jumbo Payload, esta lleva un
campo de longitud de 32 bits con el fin de permitir la transmisión de paquetes IPV6 con carga útil entre
64.536 Bytes y [Link] Bytes.

Fig.4.51 Formato de la opción de Jumbograma

Para poder transmitir Jumbogramas se necesita que en el campo Next Header esté la opción Hop-by-
Hop, la cual identifica un Jumbograma, tal como se muestra en la Fig.4.52.
Tanto el origen como el destino y de cada uno de los routers intermedios deben permitir en sus redes
el envío de más de 64K y contiene un valor de 32 bits especificando el tamaño del datagrama. Así,
los Jumbogramas tienen un máximo de [Link] (2^32).

Fig. 4.52 Encabezado de un paquete IPv6 con cabecera HBH para Jumbogramas

Notas del Profesor Titular, Dr. C. Ing. Félix F. Alvarez Paliza, Dpto. Telecomunicaciones, UCLV
 79

La forma de especificar un Jumbograma es situar el tamaño de los datos (Payload Length) a 0 en el

datagrama IP, tal como se muestra en la figura anterior y utilizar el sistema de cabeceras de extensión
definidas en la versión 6.
El campo de Tipo de Opción es fijado a 194 (0xc2 Hex) el paquete es descartado y un mensaje ICMPv6
de problemas de parámetros es enviado si la opción no es reconocida y la dirección de destino no es
una dirección de grupo (multicast).
El protocolo IPv6 en Windows Server 2012, Windows Server 2008 R2, Windows Server 2008, Windows
8, Windows 7, and Windows Vista soporta la llegada de Jumbogramas al nivel o capa IPv6, pero este
no tiene soporte para TCP y UDP para enviar o recibir Jumbogramas.
La cabecera correspondiente al Jumbograma deberá ser procesada por todos los Enrutadores
intermedios.
Se dispone de 32 bits (2^32 = [Link] bytes = 4 Gigabytes) para la especificación del tamaño
del datagrama.

 Extensión de Cabecera de Opciones de Destino (Destination Options Header, DO, 60).

Su formato es el mismo que el de la cabecera de Opciones de Salto HBH (Next Header, Header
Extension Length, Options), la misma es utilizada para especificar parámetros de la entrega de
paquetes en destinos intermedios o finales.

Fig.4.53. Extensión de Cabecera de Opciones de Destino

La cabecera es identificada cuando un paquete llega una cabecera extra, especifica en el paquete
que tipo de cabecera le sigue con un código numérico.
Con este formato se permite que aquellos Enrutadores intermedios que no necesiten interpretarlas
puedan evitarlas sin perder tiempo de proceso. El primer campo es como siempre el de siguiente
cabecera (Next Header), que nos permite indicar la presencia de más cabeceras

La cabecera de Opciones de Destino (DO) es utilizada de dos formas:

a) Si una cabecera de Rumbo (Routing) está presente, esta especifica las opciones de entrega o
procesamiento en cada destino intermedio. En este caso la cabecera DO precede a la cabecera
de Rumbo.
b) Si la cabecera de Rumbo no está presente o si esta cabecera esta después de la cabecera de
Rumbo entonces esta cabecera especifica la entrega o el procesamiento al final del destino.

Un ejemplo de Opción de Destino es la conocida como Opción de Dirección de Residencia (Home

Address Option) en IPv6 Móvil definida en la RFC 6274.

 Extensión Cabecera de Encaminamiento (Routing Header)

Tiene la misma función que en la opción existente en IPv4. Son cuatro bytes (valor máximo de cada
opción 2^8 = 256) de cabecera a los que se añade una serie de direcciones de 128 bits que

Notas del Profesor Titular, Dr. C. Ing. Félix F. Alvarez Paliza, Dpto. Telecomunicaciones, UCLV
 80

corresponden a los Enrutadores por los que debe pasar el paquete hasta llegar a su destino, tal como
se muestra en la Figura 4.54.

Fig.4.54 Extensión de Cabecera de Enrutamiento

El primer campo es el de Cabecera Siguiente (Next Header), la versión 6 utiliza un sistema de cadena
(daisy chain) dónde se pueden especificar múltiples cabeceras.

A continuación viene el Longitud de la Extensión de la Cabecera (Header Extension Length) que es el

tamaño total de la cabecera en palabras de 64 bits (incluyendo todas las direcciones especificadas).

El tipo de Enrutamiento (Routing Type) es la política que se debe seguir en el encaminamiento, la tipo
0 indica Enrutamiento Fuente (Source Routing). En este tipo de enrutamiento fuente, si el Enrutador
aparece en la lista de direcciones especificadas, se quita de la lista, ejecuta el decremento del campo
de segmentos restantes y busca cual de la lista está mas cerca para enviar el paquete. Si no aparece
en la lista, se limita a encaminarlo ignorando esta opción).
El número de Segmentos Pendientes (Segments Left) es un valor que indica el número de direcciones
de encaminamiento que aún restan. De esta forma, al llegar a 0 significa que el paquete ha alcanzado
su destino.
A continuación en la Figura 4.55 se muestra un ejemplo de Enrutamiento Fuente y cómo se utiliza la
extensión de cabecera de enrutamiento.

Fig. 4.55 Ejemplo de Enrutamiento Fuente de un paquete IPv6.

 Extensión de Cabecera de fragmentación (Fragmentation Header)

En IPv6 existe una cabecera de fragmentación para que en el origen, y no en los routers intermedios
como en la versión 4, se pueda fragmentar la carga de un paquete (payload) de una cantidad de datos
superior al soportado el nivel de enlace (Maximun Transfer Unit, MTU) en varios paquetes de tamaño
inferior que son independientes entre si y pueden ser reenviados por separados en caso de necesidad.
Notas del Profesor Titular, Dr. C. Ing. Félix F. Alvarez Paliza, Dpto. Telecomunicaciones, UCLV
 81

El primer campo de Cabecera Siguiente (Next Header) va aparecer al inicio, el mismo indica el
siguiente tipo (si hay) de cabecera que nos encontraremos, tal como se muestra en la Figura 4.56.

Fig.4.56. Extensión de Cabecera Fragmentación

El siguiente campo también es un byte que actualmente esta reservado y debe ser puesto a 0.
El campo de Desplazamiento de Fragmento (Fragment Offset) indica los 13 bits más significativos del
desplazamiento, asumiendo pues que la fragmentación es en múltiplos de 64. En la versión 4 se
usaban también 13 bits, pero eran los menos significativos, obligando a multiplicar por 8 para obtener
el desplazamiento total del byte, cosa que ahora no es necesaria.
Los 2 bits siguientes están reservados para futuros usos. Finalmente el último bit es el bit de mas
fragmentos (More), que es puesto a1 en todos los fragmentos y a 0 en el último.

Cuando un paquete IPv6 es fragmentado este es dividido en dos partes:

- Parte indivisible, que es la parte original del paquete IPv6 que tiene que ser
procesada por los nodos intermedios entre el nodo fuente y el destino.
La misma consta del encabezado IPv6, la extensión HBH, la extensión DO
para los destinos intermedios y la cabecera de Rutas.
- Parte Fragmentada, es la que solo tiene que ser procesada por el nodo de
destino final. La misma consta de la cabecera de Autenticación, la
cabeceras de Seguridad del encapsulado, la de extensión DO para el
destino final y las PDU.
Por lo que cada paquete IPv6 fragmentado consta de la parte indivisible, el encabezado de
fragmentación y un pedazo de la parte fragmentada, tal como se muestra en la Figura 4.57

Fig.4.57 Proceso de Fragmentación de un paquete IPv6

Notas del Profesor Titular, Dr. C. Ing. Félix F. Alvarez Paliza, Dpto. Telecomunicaciones, UCLV
 82

 Cabecera de Autenticación (Authentication Header)

Es una de las novedades más importantes en la versión 6 del protocolo IP. Debe estar situada entre
la cabecera IP y los datos del paquete.

[Link]ón de Cabecera de autenticación

La presencia de una cabecera de autenticación no modifica de ninguna manera el comportamiento del

resto de protocolos de nivel superior como TCP o UDP. Esta cabecera tan solo proporciona una
seguridad implícita del origen del paquete. De esta forma los protocolos superiores deben rechazar
los paquetes que no estén adecuadamente autenticados.

Tal como se muestra en la Figura 4.58 el primer campo indica la Cabecera Siguiente (Next Header)
que nos encontraremos tras esta. A continuación nos encontramos la Longitud de los datos (Payload
Length) especificado en palabras de 32 bits y un campo de 16 bits reservado que debe ser inicializado
a 0. Después nos encontramos con el índice de Parámetros de Seguridad (Security Parameters Index)
y el campo de Número de Secuencia (Sequence Number field) que ocupan 32 bits cada uno.
Finalmente vienen los Datos de Autenticación (Authentication Data) que es un campo de longitud
variable, lo que puede observarse en la Figura 4.59.

Fig.4.59 .Posición de la extensión de la cabecera de autenticación

Tal y como se ha visto, un paquete puede incluir más de una Extensión de cabecera. Esto no debería
suponer ningún problema para los Enrutadores intermedios encargados de encaminarlo hasta su
destino. De esta forma, las cabeceras son procesadas por los Enrutadores a medida que estas llegan,
sin ineficiencias. Este sistema de proceso ha sido comparado con las distintas capas de una cebolla
(onion-peeling), dónde cada cabecera es una capa.

Notas del Profesor Titular, Dr. C. Ing. Félix F. Alvarez Paliza, Dpto. Telecomunicaciones, UCLV
 83

De todas formas es importante señalar que hay algunas cabeceras con mayor importancia que otras,
como la Cabecera de Autenticación (Authentication Header) que obliga a descartar todo el paquete si
es incorrecta o la Cabecera de Fragmentación (Fragmentation Header) que obliga a la recomposición
de los paquetes.
Deben de consultarse las nuevas RFC 6564 y 5871 que introducen aspectos nuevos en las
extensiones de los encabezados actualizando la RFC 2460.

Campo de Direcciones IPv6

 El mismo está conformado por 128 Bits que permiten 3.4 x 1038 direcciones, muy superior
a las 4 300 millones de direcciones de IP V4.
 El Enrutamiento es sin clases, de forma similar a CIDR visto en IP V4.
 La Notación de las direcciones será en Hexadecimal, agrupados en 8 cadenas de 16 Bits
separados por dos puntos (:).

Representación de direcciones IPv6

Las direcciones IPv6 se van a representar como 8 grupos de 16 Bits separadas por el carácter dos
puntos (“:”),donde cada grupo se representa por cuatro dígitos hexadecimales (0,1,2,,,,,9,A,B,C,D,E y
F) , tal como se muestra a continuación en la Figura 4.60.

Fig.4.60 Ejemplo de representación de una dirección IPv6

Hay dos formas convencionales con que se pueden representar las direcciones IP V6 como cadenas
de texto:
- La forma preferida es x:x:x:x:x:x:x:x , donde las x son cuatro dígitos hexadecimales de las 8 partes
de 16 Bits con que cuenta una dirección.
De esta forma se puede utilizar la notación hexadecimal, que permite una representación más
compacta que una ristras de 128 unos y ceros.
[Link]
- Una segunda forma es la abreviada, debido a algunos métodos de situar ciertos estilos de IP V6,
especialmente para casos de direcciones que tienen largas cadenas de Bits “0”. Permitiendo esa forma
compactar estas direcciones tan voluminosas, se aceptaron una serie de simplificaciones:
Notas del Profesor Titular, Dr. C. Ing. Félix F. Alvarez Paliza, Dpto. Telecomunicaciones, UCLV
 84

 Supresión de los ceros redundantes situados a la izquierda.

 Simplificación de los ceros consecutivos mediante el uso del prefijo ‘::’, tanto delante como
detrás.
Por ejemplo para la dirección anterior de ejemplo sería: 6500::123:4577:89ab:cddf
 Este prefijo tan sólo puede ser utilizado una vez en una misma dirección.

En la Figura 4.61 se muestra un ejemplo de representar mediante dos opciones una dirección IPv6
de forma abreviada. En el centro la dirección IPv6 normal y en la parte superior la primera opción y en
la parte inferior una segunda opción.

Fig.4.61 Ejemplo de representación de una dirección IPv6 de forma abreviada

Se puede hacer de forma abreviada de una forma u otra pero no se pueden repetir más de una vez
los doble puntos para abreviar.

A continuación se muestran varios ejemplos de direcciones representadas de forma abreviada:

a) [Link] puede ser representada como ff01::101
b) [Link] puede ser representada por ::1
c) [Link] puede ser representada por ::

Para una dirección IPv4 tal como se muestra a continuación a modo de ejemplo la dirección: [Link]
se representará como -> [Link][Link] , permitiéndose el uso de la notación decimal y en
forma comprimida sería ::[Link], pero sin embargo esta no es la forma permitida de representación.

En IP V6 va a ser muy común el empleo de prefijos de direcciones IPV6, similar a la forma de prefijos
utilizados en IP V4 cuando se escribían direcciones sin clases bajo la notación de CIDR.

La especificación de un prefijo de direccionamiento en la versión 6 se realizará mediante la forma

dirección_ipv6/ longitud-prefijo

Notas del Profesor Titular, Dr. C. Ing. Félix F. Alvarez Paliza, Dpto. Telecomunicaciones, UCLV
 85

Donde la dirección IPv6 será escrita en una de las formas especificadas con anterioridad y la longitud
del prefijo un valor decimal que indica cuantos Bits contiguos de izquierda a derecha comprenden el
mismo.
Si tenemos el prefijo de 40 bits que abarca los dígitos hexadecimales [Link] en la dirección
[Link] se especificará como [Link]/40.

Se debe tener mucho cuidado con las simplificaciones siempre que se indican prefijos.

En la RFC 5952 de 2010, se actualiza la RFC 4291 de 2006, dado que la misma era muy flexible en
la representación de una dirección IPv6 y ello ha provocado una serie de problemas: búsqueda de
direcciones en hojas de cálculo, en ficheros de texto, en diagramas de redes, etc.
Por lo que se adoptaron una serie de decisiones en la RFC 5952 que tienen que cumplirse, tales como:
a) Los ceros delanteros tienen que ser suprimidos. Por ejemplo la dirección [Link] no
es aceptada y tiene que ser representada como [Link].
b) Un simple campo de 16 bits 0000 tiene que ser representado por 0.
c) El empleo del símbolo "::" tiene que ser utilizado a su máxima capacidad. Por ejemplo la
dirección [Link] tiene que ser recortada a [Link]. De forma análoga la
dirección [Link] no es aceptada debido a que el símbolo "::" podría haber sido utilizado
para producir una representación más corta [Link].
d) El símbolo "::" no tiene que ser utilizado para acortar un solo campo de 16 Bits a [Link] ejemplo
la representación de la dirección [Link] es correcta , pero la representación de
ella como [Link] no es correcta.
e) Cuando hay un opción alternativa en la colocación del símbolo "::" , la más larga de ellas con
campos de 16 Bits a 0 tiene que ser acortada. Por ejemplo en la dirección [Link],
la más larga tiene que ser acortada y quedar como [Link].
f) Cuando los campos de 16 Bits a 0 consecutivos tienen igual longitud , tal como se muestra a
continuación en la dirección [Link]), la primera secuencia de ceros tiene que ser
acortada , tal como se muestra a continuación a partir del ejemplo dado [Link].
g) Los caracteres "a", "b", "c", "d", "e" y "f" tienen que ser representados en letras
minúsculas en direcciones IPv6.
h) Hay muchas formas de combinar direcciones IPv6 y números de puertos. El estilo utilizando
corchetes [ ] debe ser utilizado, a modo de ejemplo se muestra a continuación una
representación de una dirección [Link] : 80.

Notas del Profesor Titular, Dr. C. Ing. Félix F. Alvarez Paliza, Dpto. Telecomunicaciones, UCLV
 86

Visión general de una red IPv6

Antes de analizar los tipos direcciones que hay en IPv6 es vital tener una idea de la estructura de una
Red IPv6 y sus componentes básicos. En la Figura 4.62 se muestra un esquema simplificado de una
red IPv6 de una organización o empresa, constituida por tres subredes (A, B y C) interconectadas por
Routers o Switch de capa 3. A su vez la red está conectada a través de un ISP a Internet.

Fig.4.62 Componentes básicos de una Red IPv6

Se pueden observar 4 enlaces (link) y tres subredes, estando los enlaces poblados por estaciones
(Host) y terminados por un Enrutador (Router). El enlace 4 es la red DMZ que termina en uno de sus
extremos con el Enrutador (Router) de Borde. Los enlaces 2 y 3 son administrados por la subred B,
mientras que el enlace 1 es administrado por la subred A y la subred C es adjunta a la DMZ sobre el
enlace 4.
Como se muestra en la figura, una red IPv6 tiene esencialmente los mismos componentes que una
red IPv4. Sin embargo en la terminología que emplea IPv6 hay diferencias con respecto a la
terminología utilizada por IPv4.
Luego vamos a utilizar los términos definidos en las RFC 2460:
- Nodo IPv6, es un dispositivo que implementa IPv6, con una dirección IPv6 y una interfaz que
está configurada para soportar IPv6. Este término genérico se aplica tanto a Estaciones (Host )
como a Enrutadores (Routers).
- Enrutador IPv6 (Router IPv6), es un nodo que conduce paquetes IPv6 que no están
explícitamente dirigidos hacia el mismo.
- Estación (Host) IPv6, es cualquier nodo que no es un Router, puede tener más de una interfaz
que esté configurada para soportar IPv6. Las estaciones no conducen paquetes.
- Enlace (link), es simple medio de red adjunta, limitada sobre sus extremos por un Enrutador
(Router).
- Vecino (Neighbor), es un nodo IPv6 que está sobre el mismo enlace que un nodo local.
- Subred IPv6, es el segmento administrado de una red IPv6. Los componentes de ella pueden
corresponderse con todos los nodos sobre el enlace igual que en IPv4. Es importante destacar
que IPv6 soporta subredes de múltiples enlaces (multilink), donde los nodos sobre más de un
enlace pueden ser componentes de una simple subred. Tal es el caso de la figura donde los
Enlaces 2 y 3 son componentes de la subred B

Notas del Profesor Titular, Dr. C. Ing. Félix F. Alvarez Paliza, Dpto. Telecomunicaciones, UCLV
 87

Tipos de direcciones IPv6

El esquema de direcciones actual de IPv6 es definido en la RFC 4291 de Febrero de 2006, la cuál
declara obsoleta la RFC 3513. La misma define la estructura de direcciones del protocolo IPv6 y
también incluye el modelo de direcciones, la representación textual de las direcciones, las definiciones
de direcciones y las direcciones requeridas por un nodo.

Las direcciones IP V6 son de 128 Bits y se utilizan para identificar interfaces y conjuntos de interfaces.
Para ello se establecen tres tipos de direcciones:

Única (Unicast): Identifica a un interfaz sencillo. Por lo que un paquete enviado a una dirección Única
es entregado a la interfaz identificada por la dirección de destino.

Cualesquiera (Anycast): Es un identificador para un conjunto de interfaces, típicamente

pertenecientes a diferentes nodos. Un paquete enviado a una dirección de destino de este tipo solo
alcanzará a la interfaz más cercana, acorde a los protocolos de enrutamiento que miden la distancia.

Mutidifusiòn (Multicast): Es un identificador de un grupo de interfaces, típicamente pertenecientes a

nodos diferentes. Luego un paquete enviado hacia una dirección de este tipo es entregado a todas las
interfaces identificadas por esa dirección de grupo.

No hay direcciones de difusión (broadcast) en IP v6, su función es reemplazada por las direcciones de
Grupo o Multidifusión (multicast).

Es importante destacar que las direcciones IP v6 de cualquier tipo son asignadas a una interfaz y no
a nodos.
Una dirección IPv6 única (Unicast) se refiere a una simple interfaz. Cuando una interfaz pertenece a
un solo nodo, entonces esta dirección única puede ser utilizada también para identificar al nodo.
Toda interfaz requiere tener al menos una dirección Local de Enlace Única (Link Local unicast
address). Mientras que una simple interfaz puede tener múltiples direcciones IP V6 de cualquier tipo
(unicast, anycast and multicast).

Las RFC 5952 y 6052 actualizan la RFC 4291, también se analizarán más adelante otras RFC que
introducen nuevos aspectos en direcciones únicas y de grupos.

Para la identificación del tipo de direcciones IPv6 se utilizan los 8 Bits más significativos de la dirección,
tal como se muestra en la tabla siguiente:

Notas del Profesor Titular, Dr. C. Ing. Félix F. Alvarez Paliza, Dpto. Telecomunicaciones, UCLV
 88

Tipo de Prefijo Notación CIDR Observaciones

Dirección Binario
No 000…..0 : : /128 128 Bits a “0”, no es asignada a ningún nodo.
especificada
Loopback 000…..1 : : 1/128 Un nodo IP V6 envía un paquete a si mismo. No
(lazo) es asignada a ningún nodo.
Multicast 11111111 FF00::/8
Link Local 111111010 FE80::/10
Unicast
Global Todas las
Unicast demás
Es destacable que las direcciones de tipo Anycast son tomadas del espacio de direcciones Unicast
(de cualquier alcance) y no son distinguibles sintácticamente.
En la RFC 4291 se declara obsoleta la RFC 3513 y las direcciones Únicas son agregadas con
prefijos de cualquier longitud (tal como se indica en la tabla anterior).

Tipos de Direcciones Únicas (Unicast)

Las direcciones únicas caen en las siguientes categorías:
- Únicas Globales (Global Unicast)
- Únicas Locales de Enlace (Link-Local unicast)
- Únicas de Locales de Sitio (Site-Local unicast) – No utilizada acorde a la RFC 4291.
- Únicas Locales - (Unique Local IPv6 Unicast Addresses, RFC 4193)

Las Direcciones Locales de Sitios (Site Local Unicast) fueron desaprobadas, o sea declaradas no
necesarias en la RFC 4291, sin embargo hay otras direcciones únicas locales definidas con otros fines
en la RFC 4193 que se abordarán más adelante.

Cada una de ellas tiene un alcance limitado; para mostrar con más claridad la funcionalidad de las
direcciones se muestra la figura 4.63.

Fig.4.63 Direcciones globales, de sitio local (desaprobadas) y de enlace local.

El grupo de direcciones Únicas (Unicast) representa aquellas direcciones que identifican un único
punto final en una comunicación.

Notas del Profesor Titular, Dr. C. Ing. Félix F. Alvarez Paliza, Dpto. Telecomunicaciones, UCLV
 89

En la Fig.4.64 veremos cómo representar una dirección Global Única, donde se utilizan n bits para
identificar la red (asignadas por una autoridad), m bits para identificar la subred y generalmente los
últimos 64 bits para identificar la interfaz.

Fig. 4.64 Formato de una dirección Global Única

Observe que se toma de ejemplo la dirección [Link]/32 acorde a la RFC 3849, que indica utilizar
ese prefijo para cuestiones de documentos. Por ello verán en la mayoría de los libros de texto el uso
de este prefijo.

A continuación se muestra un ejemplo de una dirección Única Global:

[Link]

En el mismo se muestran los 128 bits de la dirección IPv6, donde los primeros 48 bits,
[Link], contienen el prefijo de localización que representa la topología pública. Los
siguientes 16 bits, 0015, contienen la identificación de la subred (ID subnet), representando la topología
privada de la localización. Los 64 bits restantes mas a la derecha, [Link], contiene la
identificación de la interfaz (interface ID).

Notas del Profesor Titular, Dr. C. Ing. Félix F. Alvarez Paliza, Dpto. Telecomunicaciones, UCLV
 90

En realidad el prefijo de enrutamiento global es un valor que está jerárquicamente estructurado como
se aprecia en la figura y el mismo es un valor asignado a un sitio por una autoridad de registros
regionales (RIR) a un ISP o a una autoridad nacional. Siguiéndole después el identificador de la
Subred (subset ID), el cuál es un identificador del enlace dentro del sitio y posteriormente el
identificador de la interfaz.

Todas las direcciones Únicas Globales (GUA), aparte de aquellas que comiencen con ceros binarios,
tendrán un campo de identificación de la interfaz (ID Interface field) de 64 Bits. Mientras que las que
comiencen con ceros binarios no tendrán limitantes en el tamaño de la estructura de la ID de la interfaz.
Este es el caso de direcciones IP V4 empotradas como direcciones IPV6.
Para ampliar sobre las direcciones Únicas Globales puede referirse a la RFC 3587 que aún está
vigente.

Direcciones Únicas de Locales de Enlace (Link- Local Unicast Address)

Estas son utilizadas para su uso sobre enlaces locales y las mismas tienen el formato de los primeros
10 Bits (1111111010), después 54 Bits a “0” y por último 64 Bits para Identificar la interfaz, tal como
se muestra en la Fig.4.64.

Fig. 4.65 Formato de una dirección Única Local de Enlace

La representación hexadecimal del prefijo de 10 bits anterior es: fe80

Posteriormente está la identificación de la interfaz con 64 bits, que generalmente son obtenidos de la
dirección MAC de 48 bits de la interfaz.
Por ejemplo la dirección: fe80::23a1:b152

Estas direcciones son designadas para ser utilizadas para direccionamiento sobre un simple enlace
con propósitos tales como configuración automática de direcciones, descubrimiento de vecinos o
cuando no hay Enrutadores presentes.

Por ejemplo las direcciones de enlace local son utilizadas para comunicarse entre estaciones sobre el
enlace, sobre un simple enlace de una red IPv6 sin la intervención o utilización de un Enrutador (por
ejemplo dentro de un segmento de LAN, una VLAN, etc.). Este tipo de direccionamiento puede ser
utilizado para alcanzar a un colega de una misma empresa en un edificio, considerando que están en
la misma LAN, sin necesidad de un Enrutador.

O sea que el alcance de una dirección Local de Enlace es del enlace y un Enrutador IPv6 no conducirá
tráfico de este tipo más allá del enlace. Una dirección Local de Enlace va a ser utilizada para descubrir
vecinos (Neighbor Discovery, RFC 2461) y este proceso es configurado automáticamente aún en la
ausencia de todas las otras direcciones.
Un Enrutador IPv6 no conduce tráfico de enlace local por detrás del enlace, para ello refiérase a la
Figura 4.62 donde se representan los componentes básicos de una red IPv6.
Es importante conocer el campo de acción de una dirección de Enlace-Local, y en la RFC 4007 se
define que la misma es para excepcionalmente identificar interfaces dentro de un simple enlace
solamente.

Notas del Profesor Titular, Dr. C. Ing. Félix F. Alvarez Paliza, Dpto. Telecomunicaciones, UCLV
 91

Que pasa que un nodo puede tener varias interfaces y es necesario un identificador de zona, también
conocido como identificador de alcance (ID scope).
Por lo que en la RFC 4007 se establece que los identificadores de zona son estrictamente locales al
nodo y se representan por <address% <zone_id>>.
En el sistema operativo Windows el identificador de zona para el enlace local es típicamente el
identificador de interfaz.
Por eso cuando se ejecuta el comando ipconfig /all en Windows se muestran las direcciones IPv6 de
enlace local con un % para identificar las interfaces a las cuales han sido asignadas las direcciones.
A modo de ejemplo observe la dirección: fe80::ffff:ffff:fffd%5

Direcciones de Sitios locales (fueron desaprobadas en la RFC 4291)

Las mismas son utilizadas entre nodos que se comunican con otros nodos en la misma organización.
El alcance de la dirección de sitio local es el sitio en el cuál está la intranet de la organización. Este
tipo de direcciones pueden ser utilizadas para alcanzar dentro de una empresa a un colega que está
conectado a la telefonía IP de la intranet.
Las direcciones únicas de sitios locales son equivalente a los tres rangos de direcciones privadas
adoptadas en IPv4. O sea que estas van a ser direcciones localizadas dentro de una organización y
no van a ser difundidas.
En la Fig.4.66 se puede apreciar el formato de este tipo de dirección de Sitio Local.

Fig. 4.66 Formato de una dirección de Sitio Local

O sea que el comportamiento especial del prefijo definido en la RFC 3513 de fec0 no tiene que ser
soportado por las nuevas implementaciones y tiene que ser tratado el mismo como el de una dirección
única global.
Las implementaciones y despliegues existentes pueden continuar con el uso de este prefijo.
Sin embargo hay que tener cuidado con el concepto de Dirección Local IP V6 dada en la RFC 4193
donde se define un prefijo de 7 bits mas 41 bits para el identificador Global (Global ID, pseudo
aleatorio) que permite conformar las conocidas direcciones ULA.

Direcciones Únicas locales - (Unique Local IPv6 Unicast Addresses, RFC 4193)
Estas direcciones tienen alcance global dentro de una organización o empresa, pero que es para
comunicaciones locales dentro de un sitio y las mismas no serán ruteadas en Internet. O sea que no
sirven para navegar en Internet.
Las direcciones únicas locales son creadas utilizando una asignación seudo aleatoria de
identificador global con un prefijo, cuyo formato es el siguiente:
| 7 bits |1| 40 bits | 16 bits | 64 bits |
+--------+-+--------------+--------------+----------------------------+
| Prefix |L| Global ID | Subnet ID | Interface ID |
+--------+-+--------------+--------------+----------------------------+
Donde el Prefijo es fc00::/7 para su identificación como dirección única local
El bit L es fijado a 1 para indicar que es un prefijo asignado localmente.

Notas del Profesor Titular, Dr. C. Ing. Félix F. Alvarez Paliza, Dpto. Telecomunicaciones, UCLV
 92

Un identificador global de 40 Bits para crear prefijos únicos globales y un identificador de subredes
de 16 Bit, para identificar subredes dentro del sitio.
El identificador de interfaz es el definido ya en la RFC 4291y se abordará adelante.

Direcciones de Vecino más cercano (Anycast)

Una de las nuevas características presentes en IPv6 es la inclusión de un nuevo tipo de direcciones
de grupo denominada Anycast. Este tipo de dirección se diferencia de las direcciones de Grupo
(Multicast) en que la misma identifica a un grupo de interfaces sobre diferentes nodos, pero cuando
se envía un paquete hacía ellas solo alcanza a una interfaz (la más cercana).

Un uso esperado de las direcciones Anycast es el de identificar un conjunto de Enrutadores

pertenecientes a una organización que ofrece servicios de Internet. Tales direcciones pueden ser
utilizadas como direcciones intermedias en el encabezado de un enrutamiento IP V6. El encabezado
de enrutamiento ocasionará que un paquete sea entregado mediante una vía particular al proveedor
de servicio o a una secuencia de proveedores de servicio.
Otro posible uso está en identificar un conjunto de Enrutadores conectados a una subred particular, o
al conjunto de Enrutadores que ofrecen acceso a un dominio de enrutamiento particular.
La dirección Anycast de Enrutador-Subred es predefinida y su formato es mostrado en la figura
siguiente:

Fig.4.67. Formato de una dirección de tipo multidifusión

El formato de este tipo de direcciones es muy sencillo debido a que toda la carga se centra en el
sistema de encaminamiento. De esta forma, para cada Enrutador debe guardar un solo registro que le
indica cual es el miembro más cercano a él del grupo especificado, y al recibir un paquete con una
dirección de destino Anycast comprobar la existencia de este registro especial en su tabla de
encaminamiento o encaminar normalmente el paquete (ver RFC 2526).

Direcciones de Grupo (Multicast)

Las direcciones de Grupo fueron ya añadidas a la versión 4 del protocolo IP en 1988 con la definición
de la clase D. Aprovechando la experiencia obtenida desde entonces, y viendo su viabilidad se decidió
añadirlas en la especificación de la versión 6.

Este tipo de direcciones se caracteriza por ser comunes a un grupo de interfaces (típicamente sobre
diferentes nodos) de forma que un paquete enviado a esta dirección será distribuido a todos los
integrantes del grupo. Una interfaz puede pertenecer a un número cualesquiera de grupos de
multidifusión.
Estas direcciones tiene el formato mostrado en la Figura 4.68, donde podemos observar que la
misma tiene una estructura: ffXY:ZZZZ:ZZZZ:ZZZZ:ZZZZ:ZZZZ:ZZZZ:ZZZZ/16.

Notas del Profesor Titular, Dr. C. Ing. Félix F. Alvarez Paliza, Dpto. Telecomunicaciones, UCLV
 93

Fig.4.68 Formato de una dirección de tipo Grupo (Multicast)

El símbolo X que agrupa un conjunto de 4 bits denominado banderas (Flags O/R/P/T) dónde se
especifican una serie de opciones, aunque actualmente los tres primeros están reservados y deben
ser inicializados a 0 y el cuarto denominado transitorio (transient) e especifica si la dirección es local y
una vez finalizada la comunicación debe liberarse (valor 0) o si la dirección es fija y debe conservarse
(valor 1).
La bandera P es definida en la RFC 3306 y la R en la RFC 3956.
El símbolo Y también agrupa 4 bits que definen el alcance (Scope) de la comunicación, evitando que
los paquetes de una videoconferencia local salga a Internet o viceversa. Los valores de Y son: 0
(reservado), 1 (interfaz local), 2 (enlace local), 4 (administración local), 8 (organización local), E
(enfoque global) y F (reservado).

Varias direcciones son reservadas a partir de los identificadores de grupos para indicar “todas las
estaciones” y “todos los enrutadores” dentro de una red.
El campo de Alcance indica la extensión de la difusión (broadcast) y a continuación podremos observar
las diferentes direcciones de difusión más conocidas:

Dirección Significado
FF01::1 Todas las direcciones en un nodo
FF02::1 Todas las direcciones sobre un enlace
FF01::2 Todas las direcciones de Enrutadores sobre el nodo
FF02::2 Todos los Enrutadores sobre el enlace
FF05::2 Todos los Enrutadores en la organización

Las direcciones de grupo (multicast) en IPv6 reemplazan todas las formas de direcciones de difusión
(broadcast) de IPv4.
En la RFC 7371 de 2014 se actualiza la Arquitectura de direcciones IPv6 de Multidifusión
(Updates to the IPv6 Multicast Addressing Architecture), siendo asumido como un estándar y la misma
sirve para actualizar las RFC 3306, 3956 y la 4291.
En ese documento se actualiza la arquitectura de direcciones de multidifusión para IPv6 redefiniendo
los Bits reservados como banderas genéricas. También este documento ofrece una clasificación
relativa al uso de estas banderas.
En la RFC 7371 se le hacen 2 actualizaciones a la RFC 3306 y 4 actualizaciones a la RFC 3956.

Direcciones con significado especial

Este grupo de direcciones presenta cinco subtipos de direcciones especiales:
La dirección no especificada (Unespecified Address) está compuesta por 16 bytes nulos
([Link]) y puede representarse como ::, representa “no dirección” o “dirección no
especificada”, tal como [Link] era en IP v4. Sólo puede utilizarse como dirección inicial mientras se
inicializa y se recibe una dirección fija. También puede utilizarse para funciones internas que requieran
la especificación de una dirección IP.

Notas del Profesor Titular, Dr. C. Ing. Félix F. Alvarez Paliza, Dpto. Telecomunicaciones, UCLV
 94

La dirección interna (Loopback Address) se define como 15 bytes nulos y un byte con el último bit a 1
([Link]). Esta dirección es interna y de ninguna forma puede circular por la red o ser dirección
de origen o destino de un paquete. Su utilidad viene dada para las estaciones que no dispongan de
una conexión de red y deseen simular el comportamiento de la conexión a una red mediante una
dirección fantasma que nunca saldrá del propio ordenador.

Direcciones IPv6 con direcciones IPv4 incrustadas

Dos tipos de direcciones IPv6 son definidas para transportar una dirección IP v4 en los 32 bits menos
significativos de la dirección:
- Direcciones IPv6 compatibles con IPv4
- Direcciones IPv6 acotadas (mapped) con IPv4

Las direcciones IP v6 compatibles con IP v4 fueron definidas para la transición a IPv6 y el formato de
ellas es como sigue;

| 80 bits | 16 | 32 bits |
+--------------------------------------+-------+-------------------------+
|0000...............................0000|0000 | Dirección IPv4 |
+--------------------------------------+-------+--------------------------+
Hay que señalar que la dirección IPv4 tiene que ser una dirección global única, para esta situación,
además de que ya esta forma es desaprobada, debido a que los mecanismos de transición no la
utilizan.

Las Direcciones IPv6 acotadas (mapped) con IP v4 es el utilizado actualmente para representar la
dirección de Nodos IP V4 como direcciones IP V6. El formato establecido en la RFC 4038 es el
siguiente:

| 80 bits | 16 | 32 bits |
+--------------------------------------+-----------------.--------------+
|0000..............................0000 | FFFF| IPv4 address |
+--------------------------------------+-------+------------------------+

Direcciones requeridas por un Nodo:

En la RFC 4291 se establece que una estación tiene que reconocer un conjunto de direcciones que la
identifican a ella misma:
- Una dirección Local de Enlace para cada interfaz
- Cualquier dirección única o Anycast que haya sido configurada para las interfaces del nodo
(Manual o Automáticamente).
- La dirección de lazo cerrado (loopback)
- La dirección de multidifusión de todos los nodos.
- La dirección de multidifusión del nodo solicitado por cada una de sus direcciones únicas y anycast.
- Las direcciones de multidifusión de todos los otros grupos a los cuáles el nodo pertenece.
Mientras que un Enrutador requiere reconocer todas las direcciones que la estación requiere reconocer
más las siguientes direcciones que lo identifican a él mismo:
- La dirección Anycast Subred-Router para todas las interfaces para los cuáles este está
configurado para actuar como Enrutador.
Notas del Profesor Titular, Dr. C. Ing. Félix F. Alvarez Paliza, Dpto. Telecomunicaciones, UCLV
 95

- Todas las otras direcciones Anycast con las cuáles él ha sido configurado.
- Todas las direcciones de multidifusión de todos los Enrutadores.
Es importante conocer que la RFC 6434 amplia los requisitos que debe tener un nodo IPv6 (IPv6
Node Requirements).

Identificador de Interfaz IPv6 (IPv6 Interface Identifier (ID))

El identificador de interfaz ( ID) está formado por los 64 bits menos significativos de una dirección única
IPv6. En IPv6 el identificador de Interfaz es de longitud fija y se escogió de 64 Bits para permitir el
mapeo o acotamiento de las direcciones MAC de 48 Bits utilizada por muchas de las redes de área
Local (LAN) tales como las Ethernet y las direcciones de 64 Bit de tipo MAC bajo el estándar IEEE
1394 y las tecnologías futuras de LAN.
Las formas en que un identificador de interfaz es determinado son las siguientes:
 Como se define en la RFC 4291 el mismo puede ser derivado a partir de la dirección en
formato EUI-64. Las direcciones EUI-64 pueden ser asignadas a un adaptador de red u
obtenidas de una dirección IEEE 802. Este es el comportamiento por defecto para IPv6
en Windows XP y Windows Server 2003.
 Como se define en la RFC 4941(Privacy Extensions for Stateless Address
Autoconfiguration in IPv6, obsoleta la RFC 3041), la interfaz LAN podría tener una
dirección temporalmente asignada, generada de forma aleatoria para ofrecer un grado
de anonimidad o privacidad.
 Asignada durante el proceso de Autoconfiguración con Servidor (Stateful Address
Autoconfiguration), caso de un servidor DHCPv6.
 Como se definió en la RFC 5072 un identificador de interfaz puede ser basado en una
dirección de nivel de enlace o números seriales. O esta puede ser generada
aleatoriamente cuando se configura PPP sobre una interfaz y no hay una dirección EUI-
64 disponible.
 Ser asignada manualmente durante la configuración.

Para obtener un identificador de interfaz de 64 bit para una dirección única IPv6, el Bit U/L en la
dirección EUI-64 es complementado. O sea si está a 1 en la dirección EUI-64 es pasado a 0 y si está
a 0 en la dirección EUI-64 es entonces fijado a 1.
La razón fundamental para complementar el bit U/L es el de ofrecer mayor comprensión sobre las
direcciones EUI-64 administradas localmente. Por ejemplo en un enlace punto a punto.
Sin embargo el caso de mayor interés es el convertir una dirección IEEE 802 para identificar una
interfaz en una dirección IPv6 única.
Luego los pasos a seguir son los siguientes:
- Primero acotar (mapped) la dirección IEEE 802 en una dirección EUI-64, tal como se muestra en
la figura 5.69.
- Insertar 0xFFFE
- Complementar el Bit U/L
.

Notas del Profesor Titular, Dr. C. Ing. Félix F. Alvarez Paliza, Dpto. Telecomunicaciones, UCLV
 96

Fig.4.69 Conversión de direcciones MAC de 48 Bits a formato EUI-64

De ahí que la componente Interfaz ID de una dirección IPv6 de unidifusión de 64 bits es capaz de
retener las diferentes variantes de direcciones MAC. O sea que la organización es relativamente simple
pues todas las direcciones MAC son convertidas al formato de 64 Bits y copiadas en el campo de
Interfaz ID con el bit U invertido, tal que el valor de “0” representa una dirección localmente asignada.
Estas direcciones únicas locales de enlace se construyen con el prefijo fe80::/10 y 64 bits que
representan la dirección física (MAC Address) de la tarjeta de red,
Es importante recordar que este proceso depende del sistema operativo, en el caso de Windows se
tiene que este es el comportamiento por defecto para IPv6 en Windows XP y Windows Server 2003.
Pero que para los sistemas operativos Windows Server 2012, Windows Server 2008 R2, Windows
Server 2008, Windows 8, Windows 7 y Windows Vista no es este, sino el que genera el identificador
de Interfaz de forma aleatoria y para poder aplicar este mecanismo hay que deshabilitarlo.

Con posterioridad en la RFC 4941 (Privacy extensions for Stateless Address Autoconfiguration)
se define un proceso para generar direcciones privadas o íntimas, con vistas a lograr una mayor
seguridad y protección de los identificadores de interfaz en el proceso SLAAC.

Las Direcciones Íntimas son derivadas de una dirección MAC tal como el proceso SLAAC, pero que
son pasadas a través de un algoritmo encriptado en una vía (1-way hash algorithm). Las mismas son
para cambiar en el tiempo, de ahí que su configuración tiene una duración o basada en políticas. Tales
como horas, días, en el arranque, en diferentes direcciones para diferentes aplicaciones o en los
diferentes criterios de valoración.
Muchos sistemas operativos implementan por defecto esta acción, por lo que habría que cancelar la
misma para poder apreciar el identificador ID de interfaz en formato EUI-64.

Un identificador de interfaz que es aleatoriamente generado para evitar los escaneos de direcciones
únicas en una subred. Este es el comportamiento por defecto para las interfaces IPv6 en los sistemas
operativos Windows Server 2012, Windows Server 2008 R2, Windows Server 2008, Windows 8,
Windows 7, and Windows Vista.
Para deshabilitar este comportamiento hay que utilizar los comandos siguientes:
Set-NetIPv6Protocol –Randomize Identifiers Disabled Windows PowerShell command (in Windows
Server 2012 and Windows 8) o el comando netsh interface ipv6 set global
randomizeidentifiers=disabled command.

Cuando este comportamiento es deshabilitado entonces IPv6 para Windows utilizara el identificador
de interfaz basado en el formato EUI-64.

Notas del Profesor Titular, Dr. C. Ing. Félix F. Alvarez Paliza, Dpto. Telecomunicaciones, UCLV
 97

Política de Distribución de Direcciones IPv6

Las direcciones IP tiene que ser únicas dentro de una determinad red para poder ofrecer el
enrutamiento y la comunicación.
De ahí que la Fuerza de Tarea de Internet (IETF) creó una organización responsable de la asignación
global del espacio de las direcciones IP, tanto de IPv4 como de IPv6. Ese organismo es conocido como
la IANA ( Internet Assigned Numbers Authority), siendo responsable de la asignación global del espacio
de direcciones IP y de otros parámetros dentro del conjunto de protocolos TCP/IP.
La IANA es en esencia el nivel superior de los registros de direcciones y asigna el espacio a los
Registros Regionales de Internet, conocidos por sus siglas en inglés RIR. Los cuales son enumerados
a continuación:
 AfriNIC (African Network Information Centre), la cuál abarca la región de Africa
 APNIC (Asia Pacific Network Information Centre), la cual abarca la región Asia/Pacífico
 ARIN (American Registry for Internet Numbers). Abarca América del Norte, Puerto Rico y
algunas islas del Caribe.
 LACNIC (Regional Latin American and Caribbean IP Address Registry), abarca América Latina
y algunas islas del Caribe.
 RIPE NCC (Réseaux IP Européens Network Coordination Centre), abarca Europa,el este y
Asia Central.
En la Figura 4.70 se muestra el mapa del mundo con las regiones que abarcan los RIR.

Fig.4.70 Mapa del Mundo con las regiones que abarcan los RIR

Entre los objetivos de los Registro Regionales de Internet están:

- Unicidad, de forma tal que cada dirección IP tiene que ser única para el enrutamiento global.
- Registro, donde cada dirección IP tiene que ser accesible de forma tal que se eliminen
ambigüedades y pueda ayudar a descubrir desperfectos. Este registro es conocido como la base
de datos conocida como Whois. Hoy se tienen muchas bases whois operadas no solo por los RIR
sino también por los LIR e ISP.

Notas del Profesor Titular, Dr. C. Ing. Félix F. Alvarez Paliza, Dpto. Telecomunicaciones, UCLV
 98

- Agregación, de forma tal que permita una asignación jerárquica del espacio de direcciones de
forma tal que asegure el tráfico de enrutamiento en Internet. Sin agregación las tablas de rutas
estarían fragmentadas y esto podría crear tremendos cuellos de botella.
- Preservación, de forma tal que el espacio de direcciones sea distribuido acorde a las necesidades.
- Equidad, de forma tal que la asignación de direcciones sea imparcial, sobre necesidades
verdaderas y no en planes de largo término.
- Minimizar la carga de forma que el proceso para la solicitud y recepción sea dinámico.

En la Figura 4.70 se muestra la jerarquía de asignación del espacio de direcciones IPv6 y las
políticas sobre los tamaños. La asignación IPv6 mínima actual de la IANA a un RIR es /12,
mientras que la mínima de un RIR a un NIR o un LIR/ISP es de /32. Mientras que el espacio de
direcciones asignado por un LIR/ISP a un usuario final varía entre /48 y /64.

Fig.4.70 Jerarquía de asignación de direcciones IPv6 y las políticas de tamaño

Planificación de direcciones IPv6

Hay diferentes métodos para la asignación o planificación de las direcciones IPv6:
- Método de asignación Mejor-Adecuado (Best-Fit Method)
Este método de asignación pretende aproximarse para asignar el tamaño del bloque requerido
utilizando el más pequeño bloque disponible. Si se está utilizando la asignación de bloques de
igual tamaño (la cuál es la más recomendada por su simplicidad), entonces este método es
trivial. Sin embargo para optimizar el espacio de direcciones a asignar, un bloque no mayor que
el tamaño requerido debe ser asignado.
- Método de asignación esparcido (Sparse Allocation Method)
En la RFC 3531 se describe esta metodología de asignación esparcida.
- Método de asignación aleatoria (Random Allocation)

Sin embargo otros autores los clasifican de otra forma como:

- Método basado en las direcciones IPv4 existentes y traducirlas a IPv6 (IPv4 mapped IPv6)
- Método basado en la topología de la red
Notas del Profesor Titular, Dr. C. Ing. Félix F. Alvarez Paliza, Dpto. Telecomunicaciones, UCLV
 99

- Método basado en la organización

- Método basado en servicios

El método basado en la topología de la red asigna un bloque de direcciones para todas las
localizaciones dentro de los límites de la red. Por ejemplo una empresa que le ha sido asignada el
prefijo [Link]/48 por su proveedor y tiene diferentes sitios a través de un país, tal que la
topología es dividida en 8 regiones. Por lo que se podría seleccionar los primeros 4 Bits de los 16
disponibles para subredes para identificar las regiones. Con este esquema la red podrían tener 16
regiones y cada región podría tener a su vez 4096 subredes (2 EXP 12).

El método basado en la organización es raramente utilizado, dado que el mimo no promueve un

esquema de agregación eficiente.

El método basado en servicios o funciones permite asignar prefijos en base al tipo de servicio que es
ofrecido. Por ejemplo servicios de Voz sobre IP (VoIP), servicios de redes inalámbricas (WLAN), etc.
En muchas ocasiones se mezclan los métodos de asignación de direcciones IPv6, tal como se muestra
en la Figura 4.71.

Fig. 4.71 Ejemplo de mezcla de métodos de asignación de direcciones IPv6

En IPv6 también hay que tener en consideración la asignación de direcciones de las subredes IPv6
relacionadas con los números de las VLAN
Esto es principalmente en redes donde hay muchas subredes VLAN y ello facilita la simplificación de
la administración.
Los números de las VLAN emplean 12 Bit (o – 4096), mientras que los números de las subredes
emplean 16 Bits (considerando un prefijo de /48 para la organización).
Por lo que se pudieran utilizar los acercamientos siguientes a modo de ejemplo:
[Link] V V V V V V V V V V V V B B B B ::/ 64
[Link] B B B B V V V V V V V V V V V V ::/ 64

Sin embargo las direcciones IPv6 son escritas en notación hexadecimal, pero los números de las VLAN
son escritas en decimal. Tal que la aproximación anterior requiere de una conversión entre
hexadecimal y decimal, lo que oscurece la relación y niega la ventaja de simplificación.
Por lo que una aproximación preferible es tomar el número decimal de la VLAN y utilizar este en el
lugar del número hexadecimal de la subred.

Por ejemplo la VLAN 2783 simplemente se convierte en la subred [Link]/64

A continuación se muestra una tabla con diferentes opciones:
Notas del Profesor Titular, Dr. C. Ing. Félix F. Alvarez Paliza, Dpto. Telecomunicaciones, UCLV
 100

VLAN ID IPv6 decimal IPv6 hexadecimal (high) IPv6 hexadecimal (low)

1 [Link]/64 [Link]/64 [Link]/64

12 [Link]/64 [Link]/ 64 [Link]/ 64

2783 [Link]/64 [Link]/ 64 [Link]/ 64

4094 [Link]/64 [Link]/ 64 [Link]/ 64

En la aproximación anterior el tipo de uso (F) y la localización (L) no aparecen en la dirección IPv6, por
lo que no será posible optimizar las políticas de seguridad y las tablas de rutas
Sin embargo es posible combinar la codificación de la localización y el tipo de uso con el número de la
VLAN. Observe a continuación un ejemplo donde primero se codifica la localización y el tipo y después
el número de la VLAN.
V V V V V V V V V V V V
[Link] V V V V ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ::/ 64
L L L L T T T T B B B B
A continuación se muestra otro ejemplo de codificación del tipo de uso y posteriormente la localización
en el número de la VLAN, en los bits de la subred de las direcciones IPv6.
V V V V V V V V V V V V
[Link] V V V V ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ::/ 64
T T T T L L L L B B B B

Por la importancia del tema se resumen varias recomendaciones importantes cuando se construye el
plan de asignación de subredes IPv6:
 Utilice solo prefijos /64 para los segmentos que tengan sistemas finales (host attached),
dado que en el direccionamiento IPv6 un /64 es el tamaño estándar de subred para
direccionar interfaces.
 La excepción para el estándar /64 son las subredes utilizadas para los enlaces punto a
punto. En la RFC 6164 se establece que estos enlaces deben utilizar un /127, aunque el
uso de un /126 también se admite. Un /127 es posible debido a que IPv6 no tiene
direcciones de difusión (broadcast). Sin embargo la dirección con todos ceros en cada
subred es la dirección anycast de todos los enrutadores (Routers).
 Para consistencia con el plan de direcciones todo enlace punto a punto puede serle
asignado un /64 pero configurado con un simple /127 desde esta asignación.
 Un /126 permite que las direcciones de todos ceros (all-zeroes) sean saltadas, pero sin
embargo las direcciones 128 en cualquier subred son reservadas para direcciones
anycast (RFC 2526). Pero en la práctica esto no es problema.
 Un /120, permite evitar todas las direcciones anycast reservadas.
 Sin embargo un /112, permite evitar las direcciones anycast reservadas y tiene la ventaja
de que un valor hexadecimal de cuatro dígitos después de los dos puntos en la dirección
IPv6 identifican sistemas dentro de la subred.
 Tome ventaja de la topología de la red y de los puntos de agregación naturales para
resumir la información de los prefijos.
 Deje espacios en el plan de asignación de direcciones para futuros crecimientos
 Agrupe la asignación de subredes en múltiplos de 4 bits (/48, /52, /56, /60 ), pues aunque
este método reduce la granularidad disponible en el plan de direcciones, pero mejora la
legibilidad de los prefijos de red.

Notas del Profesor Titular, Dr. C. Ing. Félix F. Alvarez Paliza, Dpto. Telecomunicaciones, UCLV