Interconexión de Redes IP-5-IPv6-Protocolos Asociados

INTERCONEXIÓN DE REDES
CAPÍTULO 5
IPv6- PROTOCOLOS ASOCIADOS
Autor: Dr. Félix F. Alvarez Paliza

Dpto. Telecomunicaciones
UCLV
98
Protocolos Asociados a IPv6

Para que el protocolo de Interconexión IPv4 pudiera funcionar adecuadamente, tenía asociado a él un
grupo de protocolos: ARP, RARP, ICMP, IGMP, etc.
De forma análoga para que el protocolo IPv6 pueda funcionar adecuadamente, va a tener un grupo de
protocolos asociados: ND (Neighbor Discovery), MLDv2 (Multicast Listener Discovery), PathMTU, etc.
Con la única diferencia de que todos van a utilizar a ICMPv6 para la transmisión de sus mensajes,
aspecto que no era así en IPv4.
En la Figura 5.70 se muestra una comparación de los protocolos asociados a IPv4 y los asociados a
IPv6.
Fig.5.70 Comparación de protocolos asociados a IPv4 e IPv6
Protocolo ICMPv6
Este protocolo está definido en la RFC 4443 (obsoleta la RFC 2463) y en la misma se describe el
formato de todos los mensajes de control para IPv6. ICMPv6 cubre las características que tenía ICMP
en IPv4 de control de error, control de administración, reporte de errores, ofrece simple eco, etc. Pero
además el mismo tiene 5 tipos de mensajes de control que utiliza el protocolo de Descubrimiento de
Vecinos (ND) y además 3 tipos de mensajes de control que utiliza el Protocolo de Descubrir Escuchas
Múltiples (MLD).
O sea que ICMPv6 es parte integral de IPv6 y tiene que ser implementado por todo nodo IPv6 según
se establece en la RFC 4443.
El mismo es utilizado tanto en el proceso de auto configuración, como en el de descubrir vecinos como
en el de descubrir los oyentes de grupos (multicast) y otros protocolos más utilizados en IPv6.
Un aspecto interesante estriba en que muchos de los mensajes serán utilizando direcciones IPv6 de
Grupo (Multicast) que son mapeadas a direcciones de nivel de enlace principalmente de tipo Ethernet.
Todo mensaje ICMPv6 está precedido por una cabecera IPv6 y cero o más cabeceras de extensión.
El encabezado ICMPv6 es identificado por un valor de 58 decimal en el campo NH `precedente.

Los mensajes ICMPv6 tienen el formato general siguiente:
Notas del Profesor Titular, Dr. C. Ing. Félix F. Alvarez Paliza, Dpto. Telecomunicaciones, UCLV
99
Fig.5.71 Formato general de un mensaje ICMPv6
El campo de Tipo (Type) indica el tipo de mensaje, su valor determina el formato del resto del mensaje.
El campo de código depende del tipo de mensaje, el mismo es utilizado para crear un nivel adicional
de de granularidad de los mensajes.
El campo de suma chequeo es utilizado para detectar la corrupción de los datos en el mensaje ICMPv6
y parte de la cabecera de IPv6.
Los mensajes de ICMPv6 son agrupados en dos grandes grupos:
Mensajes de Error (tipos de mensajes de 0 a 127)
Mensajes informacionales (tipos de mensajes de 128 a 255)
El campo de Tipo (Type) precisa los tipos de mensajes y está organizado como sigue:
1 – 4 Mensajes de Error
128 – 129 Ping
130 – 132 Membresía de Grupos
133 – 137 Descubriendo Vecinos (Neighbor discovery)
En la figura 5.72 se muestran los principales tipos de mensajes de ICMPv6 en apoyo a los protocolos
asociados a IPv6.
Fig. 5.72 Tipos de mensajes que posee ICMPv6
Como se aprecia en la figura anterior, entre los mensajes de reporte de error de ICMPv6 están:
1 Destino inalcanzable (Destination Unreachable )
2 Paquete demasiado grande (Packet Too Big )
100
3 Tiempo excedido (Time Exceeded)

4 Problema con parámetros (Parameter Problem)
100 Privado para experimentación
101 Privado para experimentación
127 Reservado para expansión de ICMPv6 en mensajes de error
Entre los mensajes de información de ICMPv6:

128 Petición de Eco (Echo Request)
129 Respuesta de Eco (Echo Reply)
A su vez dentro de cada tipo de mensaje, el campo de código ayuda a precisar mejor la función de
cada mensaje, tal como se muestra a continuación con algunos ejemplos:
Destino Inalcanzable (Destination Unreachable)
Código 0 – No hay ruta para el destino
Código 1 - No se puede alcanzar el destino por razones administrativas
Código 2 – No asignado
Código 3 - Dirección inalcanzable
Código 3 – Puerto inalcanzable
Paquete demasiado grande

Código 0 – Parámetro es fijado para la MTU del próximo salto.
Permitido para la determinación de la MTU.
Entre los mensajes de información están los generados por la aplicación de Ping, el cuál de forma
similar a lo realizado en IPv4 genera los mensajes:
128 Petición de Eco (Echo Request) – código 0
129 Respuesta de Eco (Echo Reply)
Los otros mensajes forman parte de los protocolos para Descubrir Vecinos (Neighbor Discovery) y el
de Descubrir Oyentes de Grupos (Multicast Listener Discovery).
Protocolo de Descubrimiento de Vecinos (Neighbor Discovery, ND)

Los nodos IPv6 sobre el mismo enlace utilizan el protocolo ND para descubrir la presencia entre sí los
vecinos, para determinar las direcciones de nivel de enlace, para encontrar los Enrutadores y para
mantener la información de capacidad de ser alcanzado acerca de las trayectorias para activar vecinos.
El protocolo de Descubrimiento de Vecinos (ND) se especifica en la RFC 4861 (obsoleta la 2461).
Es un protocolo de IPv6 que comprende un conjunto de mensajes y procesos, con el cual un nodo que
se incorpora a una red descubre la presencia de otros nodos en su mismo enlace. ND reemplaza al
protocolo ARP (Address Resolution Protocol) e incorpora las funcionalidades de otros protocolos.
También se ocupa de mantener la consistencia de la cache de vecinos, donde se almacena la
información relativa al contexto de la red a la que está directamente conectado un nodo.
El protocolo de Descubrimiento de Vecinos de IPv6 es utilizado por las estaciones y los enrutadores
(hosts y routers) con los propósitos siguientes:
 Determinar las direcciones de nivel de enlace (dirección MAC) de sus nodos vecinos
 Encontrar Enrutadores vecinos
101
 Determinar prefijos y otros datos de configuración de la red

 Detectar direcciones duplicadas
 Determinar la accesibilidad de los Enrutadores
 Re-direccionamiento de paquetes
 Autoconfiguración de direcciones.
Este protocolo define una serie de mecanismos y procesos usados para resolver el problema
relacionado con la interacción entre los nodos de un mismo enlace.
A continuación se describe cada uno de los mecanismos y procesos:

 Descubrimiento de Enrutadores (Router Discovery): permite a las Estaciones (hosts)
localizar los Enrutadores que residen en el mismo enlace.
 Descubrimiento de Prefijos (Prefix Discovery): proceso por el cual una Estación (host)
descubre los prefijos de red del enlace. Su objetivo es poder distinguir entre máquinas
directamente conectadas y máquinas que requieren el enrutamiento de un Enrutador para poder
comunicarse.
 Descubrimiento de Parámetros (Parameter Discovery): permite a una Estación (host)
descubrir parámetros adicionales del enlace como la MTU o parámetros de Internet como el
Límite de Saltos (Hop Limit) usado en los paquetes salientes.
 Autoconfiguración de Direcciones (Address Autoconfiguration): introduce los mecanismos
necesarios para permitir que las Estaciones (hosts) se configuren mediante el proceso conocido
como SLAAC (stateless). Ya no es prioritaria la utilización de DHCP (autoconfiguración de tipo
stateful) para la obtención automática de direcciones.
 Resolución de Direcciones (Address Resolution): permite resolver o determinar para una
dirección IPv6 una dirección MAC, es decir, el equivalente al protocolo ARP en IPv4.
 Determinación del Próximo Salto (Next-Hop Determination): proceso mediante el cual un
nodo determina la dirección IPv6 del vecino que se encargará de reenviar el paquete hacia la
dirección de destino.
 Detección de No accesibilidad de Vecino (Neighbor Unreachability Detection): permite
determinar cuándo un nodo ya no está disponible dentro del enlace.
 Detección de Dirección Duplicada (Duplicate Address Detection): proceso a través del cual
un nodo determina si un nodo vecino está o no utilizando la dirección IPv6 solicitada. Se usa
para prevenir las colisiones de las direcciones IPv6 durante el proceso de autoconfiguración.
 Función de Reorientación (Redirect Function): proceso por el cual un Enrutador informa a
una Estación de una Ruta mejor para llegar a un determinado destino.
El protocolo ND trabaja con 5 tipos de mensajes para desarrollar los procesos enunciados con
anterioridad.
Estos mensajes son:
• Anuncio de Router (Router Advertisement, RA)
• Solicitud de Router (Router Solicitation, RS)
• Solicitud de Vecino (Neighbor Solicitation, NS)
• Anuncio de Vecino (Neighbor Advertisement, NA)
• Reorientación (Redirect)
Mensajes de Anuncio de Router (RA)
Los Anuncios de Router (RA) son emitidos periódicamente por un Enrutador a todos los nodos
mediante direcciones de multidifusión (multicast) de alcance local (link scope) conteniendo: una lista
102
de prefijos utilizados en el enlace (link) para autoconfiguración, un posible valor del Máximo Límite de
Saltos y el valor de la MTU.
En la Figura 5.73 se puede apreciar la estructura de los mensajes de Anuncios de Enrutador en sus
diferentes situaciones.
Fig. 5.73 Estructura de un Mensaje de Anuncio de Router (RA)

Es importante observar la cabecera IPv6 y la cabecera MAC, a fin de relacionar la dirección de destino
de nivel de enlace que puede tener la trama MAC relacionada con la dirección IPv6 de destino y en
dependencia de si el mensaje RA es de un anuncio general de un Enrutador o si es de una respuesta
del Enrutador ante una Solicitud de Router (RS) por una estación.
Cuando es un anuncio general periódico de un Enrutador dirigido a todos en el enlace, la dirección
IPv6 es una dirección de grupo ff02::1 (multicast para todas las estaciones en el enlace) y la dirección
MAC correspondiente de destino es 33-33-00-00-00-01. Como medida de seguridad observe que el
límite de saltos es fijado a 255, por lo que si alguna estación recibe un anuncio con un valor diferente
no emitirá ninguna respuesta.
Dentro del mensaje se puede apreciar la información que brinda el Enrutador la cual es ampliada a
continuación:
103
Después del campo de Límite de Saltos sigue el campo de Banderas, donde se tiene información
importante:
- La Bandera M es conocida como la Bandera de Gestión de Configuración (Autoconfig Managed
Config Flag). Cuando la misma es fijada a 1 entonces especifica que la configuración es con
estado (Stateful Configuration, o sea con DHCPv6). Si la misma está a 0 indica que el nodo
sobre este enlace utilizará la configuración sin estado (Stateless Address Autoconfiguration
(SLAAC)).
- La Bandera O cuando es fijada a 1 especifica que los nodos sobre el enlace utilizan DHCPv6
para otra información no relacionada con direcciones. En este caso el cliente de DHCPv6
enviará un mensaje de solicitud de información para obtener una configuración adicional.
- En la RFC 6275 se define la función de la Bandera H para IPv6 Móvil (Home Address Flag)
Mensajes de Solicitud de Router (RS)
Los mensajes de Solicitud de Router (RS) son emitidos por las estaciones (host) que necesitan de los
Anuncios de Routers (RA) inmediatamente en el arranque.
Por lo que envían la Solicitud de Enrutador a todos los Enrutadores mediante direcciones Multicast
(de alcance en el enlace, link scope).
En la Figura 5.74 se muestra la estructura de un mensaje RS, en la misma se puede observar como
la dirección IPv6 de destino es la ff02::2 (multicast para todos los Enrutadores en el enlace) y la
dirección MAC es la de grupo 33-33-00-00-00-02.
Fig. 5.74 Estructura de un Mensaje de Solicitud de Router (RS)
Se mantiene como medida de seguridad que el límite de saltos es fijado a 255, por lo que si alguna
estación recibe una solicitud con un valor diferente no emitirá ninguna respuesta.
Dentro del mensaje enviado por una estación ante una solicitud está la dirección de nivel de enlace
correspondiente a la misma.
Mensajes de Solicitud de Vecinos (NS)
Los mensajes de Solicitud de Vecinos (NS) se utilizan para descubrir la dirección de nivel de enlace
de un nodo vecino o para confirmar una dirección de nivel de enlace previamente determinada.
Estos mensajes son muy parecidos a la solicitud ARP (ARP Request) de IPv4, lo que estos se hacían
mediante mensajes de difusión y ahora son mensajes de grupos (multicast).
104
Puede observarse en la Figura 5.75 la cabecera IPv6 de un mensaje de Solicitud de Vecino (RS) que
la dirección fuente puede ser una dirección única IPv6 asignada a la interfaz que envía o que puede
ser una dirección no especificada (::) para el caso de que aún no tenga dirección asignada dicha
interfaz. La dirección de destino puede ser una dirección de multidifusión (multicast) de Nodo-
Solicitado o una dirección única ya conocida con anterioridad. En este ejemplo se considera que se
está enviando un mensaje NS para resolver una dirección de nivel de enlace y solo aparece una
supuesta dirección de nodo solicitado.
Se mantiene como medida de seguridad que el límite de saltos es fijado a 255, por lo que si alguna
estación recibe una solicitud con un valor diferente no emitirá ninguna respuesta
Fig.5.75 Estructura de un mensaje de Solicitud de Vecino (NS) para resolver una dirección MAC
La dirección de Multidifusión de Nodo-Solicitado es construida con el prefijo ff02::1:ff00:0/104 y los

ultimo 24 bits (6 dígitos hexadecimales)de una dirección única IPv6 (generalmente de enlace local
fe80::/10). Para este ejemplo se consideró la dirección IPv6 fe80::ce97:7fce/128.
A continuación en la Figura 5.76 se muestra el proceso de conformación de una dirección de grupo

multicast de Nodo- Solicitado partiendo de una dirección IPv6 única.
Fig.5.76 Ejemplo de Dirección de Nodo-Solicitado

105
Cuando se envían paquetes IPv6 de multidifusión sobre un enlace Ethernet, la dirección de destino
MAC correspondiente es: 33-33-mm-mm-mm-mm.
Donde mm-mm-mm-mm es una asignación directa de los últimos 32 Bits (8 dígitos hexadecimales)
de la dirección IPv6 de multidifusión.
Por lo que en la Figura 5.77 se puede apreciar cómo se conforma la dirección MAC en correspondencia
con la dirección de nodo solicitado de la Figura anterior.
Fig. 5.77 Acotamiento (Mapped) de Direcciones MAC con direcciones IPv6 Multicast
Mensajes de Anuncio de Vecinos (NA)

Los Mensajes de Anuncios de Vecinos son emitidos para responder a un mensaje de Solicitud de
Vecino (NS) o para anunciar el cambio de una dirección física (link-layer). En este último caso se
envía a todos los nodos mediante una dirección de multidifusión (multicast). Esta es muy parecida a la
ARP Response de IPv4.
A continuación en la Figura 5.78 se muestra un mensaje NA, donde el campo de la dirección MAC de
destino puede ser único si el mismo es una respuesta a una solicitud NS. Mientras que si el mismo es
un anuncio no solicitado, entonces la dirección MAC es fijada a 33-33-00-00-00-01, la cual es una
dirección de grupo (multicast) para todos los nodos en el enlace local.
En la cabecera IPv6 igualmente en correspondencia de la situación la dirección fuerte será una

dirección única en correspondencia con la interfaz que envía. Mientras que la dirección IPv6 de destino
será única en caso de una respuesta a una solicitud de Vecino (NS). En el caso de un Anuncio de
Vecino no solicitado, la dirección será una de Grupo para todos los nodos en el enlace local (ff02::1).
El límite de saltos será fijado a 255 como medida de seguridad.
106
Fig.5.78 Estructura de un mensaje de Anuncio de Vecino (NA)
El campo de dirección IP Objetivo (Target IP) indica la dirección IP que está siendo anunciada, por lo
que este campo es de 128 bits. Para el caso de mensajes NA de respuesta a mensajes NS solicitados,
la dirección objetivo es fijada al valor de dirección correspondiente a NS.
Para mensajes de anuncio NA (no solicitados) la dirección objetivo es la dirección cuyo rol o dirección
de nivel de enlace ha cambiado.
Para facilitar la interacción entre nodos vecinos en la RFC 4861 se establece una estructura de datos
en las estaciones con vistas almacenar los datos durante el proceso de Descubrir Vecinos (ND).
- Zona de Almacenamiento de Vecinos (Neighbor cache), en ella se almacenan las
direcciones IPv6 de cada vecino y su correspondiente dirección de nivel de enlace, así
como el estado de alcance de los vecinos. El mismo es equivalente al ARP en IPv4.
- Zona de Almacenamiento de Destinos (Destination cache), donde se almacenan las
direcciones del próximo salto para alcanzar los destinos a los cuáles se ha enviado
tráfico. Cada entrada en esta zona contiene la dirección IP de destino (local o remota),
la dirección del próximo salto y la MTU de la trayectoria para ese destino.
- Lista de prefijos, la cual contiene los prefijos sobre el enlace. Cada entrada en esta lista
define un rango de direcciones IP para los destinos que son directamente alcanzables
(vecinos). Esta lista es poblada a partir de los prefijos anunciados por los Enrutadores
mediante sus mensajes RA.
- Lista de Enrutadores por defecto, contiene la dirección IP de los Enrutadores sobre el
enlace que tienen que enviar mensajes RA y que son elegibles para ello.
107
Protocolo para Descubrir Oyentes de Multidifusión (Multicast Listener Discovery, MLD)

Algunas aplicaciones, tales como juegos de entretenimiento, videos, televisión, etc. Requieren del
envío de paquetes a múltiples receptores. Por lo que se necesita alguna forma de enviar paquetes a
grupos que están bien definidos, algunos numéricamente grandes por lo que enviar un paquete
diferente a cada receptor encarece la situación.
De otro lado la difusión (broadcast) a todos, incrementa el tráfico y es una pérdida de tiempo para
muchos receptores al recibir mensajes en que no están interesados.
El envío de mensajes a un grupo es llamado Multidifusión (multicast), por lo que se requiere de alguna
forma de crear grupos y desintegrar grupos, así como cuales Enrutadores son miembros de un grupo.
La consumación de estas tareas no es competencia de los algoritmos de enrutamiento.
Por ahora se considerará que cada grupo es identificado por una dirección de multidifusión
El protocolo para Descubrir Oyentes de Multidifusión es utilizado en los sistemas IPv6 de forma similar
al protocolo IGMP en IPv4. En su primera versión de MLD (MLDv1) implementó la funcionalidad de
IGMPv2 y en la segunda versión de MLD (MLDv2) se utilizó la funcionalidad de IGMPv3.
MLD se utiliza para intercambiar información acerca del estado de pertenencia entre los enrutadores
IPv6 que admiten la multidifusión y los miembros de grupos de multidifusión en un segmento de red.
Las Estaciones (hosts) miembros individuales informan acerca de la pertenencia de ellas a los grupos
de multidifusión y los Enrutadores de multidifusión sondean periódicamente el estado de la
pertenencia.
MLD fue definido originalmente en el documento RFC 2710 (Multicast Listener Discovery for IPv6),
esta RFC fue actualizada posteriormente por la RFC 3810 (Multicast Listener Discovery Version 2
(MLDv2)), que a su vez fue actualizada en el 2006 por la RFC 4604 (Using Internet Group
Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2
(MLDv2) for Source-Specific Multicast).
El protocolo MLDv2 es una traducción del protocolo IGMPv3 (RFC3376) para la semántica de IPv6.
Si se compara MLDv2 con MLDv1 se verá que incorpora el filtrado de la fuente, que no es más que la
habilidad de un nodo de reportar interés en escuchar los paquetes solo provenientes de una dirección
fuente específica.
Necesitando soportar Multidifusión Específica de la Fuente, más conocida por sus siglas SSM (Source-
Specific Multicast, RFC3569), o de todos menos de una dirección fuente específica, enviado a una
dirección de multidifusión particular.
En la RFC 4604 se especifica que IGMPv3 y MLDv2 son protocolos que permiten a una Estación (host)
informar a los Enrutadores Vecinos de su deseo para recibir transmisiones de multidifusión (multicast)
IPv4 e IPv6. En ella se reitera el concepto conocido como Multidifusión Específica de la Fuente (SSM).
La cual es una forma de multidifusión en la que a un receptor le es exigido especificar las direcciones
del nivel de red de la fuente y la dirección de destino de multidifusión para poder recibir transmisión de
multidifusión.
MLD es un protocolo asimétrico, dado que el mismo específica el comportamiento separado para los
oyentes de multidifusión (por ejemplo las estaciones y enrutadores que escuchan direcciones de
multidifusión) y Enrutadores de multidifusión. El propósito de MLD es el de posibilitar que cada
Enrutador de Multidifusión aprenda, para cada uno de sus enlaces directamente conectado, cuales
son las direcciones de multidifusión y cuáles son las fuentes interesadas en escuchar.
108
La información recolectada por MLD es ofrecida a cualquiera de los protocolos de Enrutamiento para
que sea utilizada por los Enrutadores. A fin de que los paquetes de multidifusión (multicast) sean
entregados a todos los enlaces donde hay oyentes interesados en tales paquetes.
Los Enrutadores de Multidifusión solo necesitan conocer que al menos uno de los nodos sobre un
enlace está escuchando paquetes para una dirección de multidifusión particular, desde una fuente
particular.
En la RFC 2710 se estableció que MLD es un sub-protocolo de ICMPv6 y que los tipos de mensajes
son un subconjunto de los mensajes de ICMPv6. Los mensajes MLD son identificados en la cabecera
de los paquetes IPv6 con el valor 58 en el campo de Próxima cabecera.
Además se estableció que todos los mensajes serían enviados con una dirección IPv6 fuente Local
de Enlace (link local), con un límite de saltos (Hop Limit) de 1, con una opción de Alerta de Enrutador
(Router Alert) en una cabecera tipo Opciones HBH (Hop-by-Hop Options).
La opción de Alerta de Enrutador es necesaria para provocar que los Enrutadores examinen los
mensajes MLD enviados a direcciones de Grupo (multicast) en los cuales ellos mismos no tienen
interés.
Los mensajes MLD tienen el formato siguiente:
Definiéndose originalmente en la RFC 2710 tres tipos de mensajes:

- Búsqueda de Oyentes de Multidifusión (Multicast Listener Query, tipo 130
decimal), donde un Enrutador de multidifusión envía este mensaje para sondear un
segmento de red en busca de los miembros del grupo. Las consultas pueden ser
generales (solicitan la pertenencia a todos los grupos de direcciones) o específicas
(solicitan la pertenencia a un grupo específico de dirección de multidifusión).
- Reporte de Oyente de Multidifusión (Multicast Listener Report, tipo 131 decimal),
una Estación envía este mensaje cuando desea unirse a un grupo de multidifusión o
como respuesta a una consulta de escucha de multidifusión MLD enviada por un
enrutador.
- Escucha de multidifusión terminada (Multicast Listener Done, tipo 132), una
Estación envía este mensaje cuando al abandonar un grupo de estaciones (hosts) podría
ser el último miembro de ese grupo en el segmento de red.
Mensaje de Búsqueda de Oyentes de Multidifusión

Un mensaje MLD de este tipo equivale al mensaje IGMPv2 de Consulta de pertenencia a grupo de
Estaciones (Host Membership Query). El mismo es utilizado por un enrutador para consultar un vínculo
conectado para estaciones a la escucha.
109
En el encabezado IPv6, la dirección de origen es la dirección local de vínculo de la interfaz en la que

se envía la consulta. El campo Límite de saltos se establece en el valor 1. Para una Búsqueda General
la dirección de destino es la dirección de multidifusión de todos los nodos de ámbito local de vínculo
(FF02::1). Para una Búsqueda Específica entonces la dirección de destino es la dirección de
multidifusión específica que se consulta.
En el mensaje MLD el campo Tipo se establece en el valor 130 y el campo Código se establece en 0.
Después del campo Suma de Comprobación o de Chequeo, se encuentran los campos de 16 bits
Retardo máximo de respuesta (Maximum Response Delay) y el campo Reservado. El campo de
Máximo retardo de respuesta especifica la cantidad de tiempo máxima en milisegundos en la que un
miembro del grupo de multidifusión debe informar de su pertenencia al grupo mediante un mensaje de
Reporte MLD. En la Búsqueda de Oyentes General, el campo de Dirección de multidifusión se
establece como dirección no especificada (::). En un mensaje de Búsqueda de Oyentes con
direcciones específicas, el campo de Dirección de multidifusión se establece con la dirección de
multidifusión específica que se consulta.
Mensaje de Reporte de Oyente de Multidifusión (Multicast Listener Report)

Una escucha de multidifusión utiliza este mensaje para informar del interés por recibir tráfico de
multidifusión para una dirección de multidifusión determinada o para responder a un mensaje de tipo
Multicast Listener Query.
Un mensaje MLD de Reporte de Oyente de Multidifusión equivale al mensaje IGMPv2 Host
Membership Report (Pertenencia a grupo de hosts). Lo utiliza un nodo de escucha para informar de
su interés en recibir tráfico de multidifusión en una dirección de multidifusión específica o responder a
un mensaje MLD de Búsqueda General o Específico.
se envía el informe. El campo Límite de saltos se establece en el valor 1 y la dirección de destino es
la dirección de multidifusión.
En el mensaje MLD de Reporte de Oyente de Multidifusión, el campo Tipo se establece en 131 y el
campo de Código se establece en el valor 0. El campo de Máximo Retardo de respuesta no se utiliza
en este tipo de mensajes y se establece en 0. El campo de Dirección de multidifusión se configura
con la dirección de multidifusión específica.
Mensaje de Escucha de multidifusión terminada (Multicast Listener Done)

Una escucha de multidifusión utiliza este tipo de mensaje para informar de que ya no tiene interés en
recibir tráfico de multidifusión para una dirección de multidifusión determinada.
Un mensaje MLD de Escucha de multidifusión terminada equivale al mensaje IGMPv2 de Abandonar
grupo (Leave Group). Lo utiliza un nodo de escucha para informar a los enrutadores locales de que el
desea terminar la escucha a una dirección de multidifusión específica.
se envía el informe. El campo de Límite de saltos se establece en el valor 1 y la dirección de destino
es la dirección de multidifusión de todos los enrutadores de ámbito local de vínculo (ff02::2).
En este tipo de mensaje MLD el campo de Tipo se establece en el valor 132 y el campo de Código se
establece en el valor 0. El campo de Máximo Retardo de Respuesta no se utiliza y se establece en 0.
El campo de Dirección de multidifusión se configura con la dirección de multidifusión específica para
la dirección que el nodo de envío informa a los enrutadores locales de que ya no está a la escucha.
Posteriormente en MLDv2 (RFC 3810) se especificaron dos nuevos tipos de mensajes:

- uno relacionado con el Mensaje de Búsqueda de Oyentes de Multidifusión (tipo 130)
110
- - Y otro relacionado con el Mensaje de Reporte de Oyente de Multidifusión (tipo 143).

Mientras que para mantener la operatividad con los nodos que implementan MLDv1 se mantuvieron
dos tipos de mensajes:
- Versión 1 de Mensaje de Reporte de Oyente de Multidifusión (tipo 131, RFC 2710)
- Versión 1 de Mensaje de Escucha de multidifusión terminada (tipo 132, RFC 2710)
Los tipos de mensajes no identificados tienes que ser ignorados, mientras que otros tipos de mensajes
pueden ser utilizados por nuevas versiones o extensiones de MLD por lo los protocolos de
enrutamiento o para otros usos.
El formato del Mensaje de Reporte de Oyente de Multidifusión es ampliado en MLDv2 con nuevos
campos lo que no lo hace compatible con MLDv1, de ahí que se dejara el versión 1.
El Interrogador (Querier) envía esta consulta cuando desea conocer si alguna de las fuentes de las
listas de direcciones de Multidifusión específicas tiene algún oyente en algún enlace adjunto
El interrogador envía periódicamente consultas generales, para conocer la información de dirección
de escucha de multidifusión desde un enlace adjunto. Estas consultas se utilizan para crear y actualizar
la dirección de multidifusión de escucha dentro de todos los Enrutadores de multidifusión en el enlace.
Los nodos responden a estas preguntas al reportar su estado de escucha de dirección de Grupo.
En la Versión 2 los mensajes de Reporte de Oyente de Multidifusión (tipo 143) son enviados por los
nodos IP para reportar a los Enrutadores vecinos el estado de escucha de multidifusión o para cambiar
el estado de escucha de sus interfaces.
Los mensajes de reporte también cambiaron su formato con un nuevo campo de número de registros
de direcciones de multidifusión (1-M) y los registros para cada una de las direcciones de multidifusión.
Donde a su vez cada registro de direcciones de multidifusión tiene un formato con varios campos.
Es importante conocer que los protocolos de nivel superior y las aplicaciones que están corriendo
sobre un nodo de escucha de direcciones de multidifusión utilizan llamadas de interfaces de servicios
específicas para indagar al nivel IP y habilitar o deshabilitar la recepción de paquetes enviados hacía
una dirección de multidifusión específica. El nodo mantiene el estado de Escucha de Direcciones de
Multidifusión para cada enchufe (socket) sobre el cual las llamadas de interface de servicio han sido
invocadas. Además de este estado de escucha por enchufe, un nodo tiene también que mantener o
calcular el estado de escucha de cada una de sus interfaces.
Conceptualmente el estado consta de un conjunto de registros (records), donde cada uno contiene
una dirección IPv6 de multidifusión, un filtro de modo y una lista de fuente. El filtro de modo puede ser
de INCLUIR O EXCLUIR. En el modo de Incluir (INCLUDE) la recepción de paquetes enviados hacia
una dirección de multidifusión especificada es habilitada “solo” desde las direcciones fuentes listadas
en la lista.
Mientras que en el modo Excluir la recepción de paquetes enviados hacia una determinada dirección
de multidifusión es habilitada para todas las direcciones, “excepto” aquella listada en la lista fuente.
A lo sumo un registro existe por dirección de multidifusión para una interfaz determinada.
Este estado por cada interfaz es obtenido como resultado del estado por cada enchufe, pero con la
diferencia de que cuando sockets diferentes tienen modos de filtro diferentes o listas de fuentes para
una misma dirección de multidifusión e interfaz.
Después que un paquete de multidifusión ha sido aceptado desde una interfaz por el nivel IP, su ulterior
entrega a la aplicación conectada a un enchufe particular, depende del estado de escucha del enchufe
111
y posiblemente también de otras condiciones; tales como el puerto del nivel de transporte del enchufe
comprometido.
En la RFC 4604 se reitera que IGMPv3 y MLDv2 son protocolos que permiten a una Estación (host)
informar a los Enrutadores Vecinos de su deseo para recibir transmisiones de multidifusión (multicast)
IPv4 e IPv6. En ella se define el concepto conocido como Multidifusión Específica de la Fuente (SSM).
La cual es una forma de multidifusión en la que a un receptor le es exigido especificar las direcciones
del nivel de red de la fuente y la dirección de destino de multidifusión para poder recibir transmisión de
multidifusión.
En la RFC 5186 se especifica que tanto IGMPv3 y MLDv2 requiere de nuevos comportamientos dentro
de los protocolos de Enrutamiento. Por lo que la información fuente adicional contenida en sus
mensajes necesita que los protocolos de enrutamiento la utilicen y gestionen.
Autoconfiguración
Uno de los aspectos más útiles de IPv6 es su capacidad para auto configurarse automáticamente, aun
sin el uso de un protocolo de configuración de direcciones tal como DHCPv6. Una Estación (host) IPv6
puede automáticamente configurar una dirección de enlace local para cada interface.
Una estación puede determinar las direcciones de sus enrutadores vecinos, direcciones adicionales
de configuración sin estado (stateless), prefijos de enlace, y otros parámetros de configuración
mediante los mensajes de Solicitud y Anuncios de Enrutadores. En los mensajes de aviso de los
enrutadores se incluyen banderas que indican cuando un protocolo de configuración de direcciones
(tal como DHCPv6) debe ser usado para configuración adicional.
Existen tres tipos de autoconfiguración:

 Autoconfiguración sin estado (IPv6 Stateless Address Autoconfiguration, SLAAC)
En la RFC 4862 se especifican los pasos que una estación toma en decidir cómo auto configurar sus
interfaces en IPv6. Algunos autores lo denominan sin servidor (“serverless”).
En este tipo la configuración de direcciones y otros parámetros está basada en la recepción de
mensajes de aviso de los Enrutadores (Routers Advertisement messages). Estos mensajes tienen las
banderas de Configuración de direcciones de gestión (¨Managed Address Configuration¨) y de
Configuraciòn con estado (Öther Stateful Configuration¨) fijadas a 0. Ellos incluyen uno o más
opciones de Información de Prefijo (Prefix Information options), cada uno con su bandera Autónoma
(Autonomous flag) fijada a 1.
 Autoconfiguración con estado (stateful) o DHCPv6
En la RFC 3315 se define el protocolo dinámico DHCPv6 para establecer parámetros de configuración
de direcciones stateful o stateless para los host IPv6.
La diferencia principal entre Stateless y Stateful en configuración del servidor DHCP es: Stateful
significa que toda la información que requiere el host la obtendrá de un servidor DHCPv6 mientras
que “Stateless” significa que información adicional a la red y prefijo la obtendrá del servidor DHCPv6.
En la RFC 3736 posee un sub-grupo del RFC 3315 enfocado exclusivamente en la configuración
“stateless”.
Es importante señalar que entre las modificaciones de la RFC4862 con respecto a la RFC2462, se
eliminó el término ¨Stateful configuration¨, el cual se prestaba a confusión, y simplemente se usa
¨DHCPv6¨ como más apropiado.
112
 Mezcla de SLAAC y DHCPv6

La tercera variante de autoconfiguración es la mezcla de las dos anteriores. La configuración se
basa en la recepción de mensajes de advertencia de los enrutadores (Routers Advertisement
messages) que incluyen opciones de Información de Prefijo (Prefix Information options), cada uno
con su bandera Autónoma (Autonomous flag) fijada a 1, y tienen las banderas de ¨Managed Address
Configuration¨ y Öther Stateful Configuration¨ fijadas a 1.
O sea que SLAAC y DHCPv6 abordan de forma diferente la configuración y satisfacen diferentes
exigencias. Por lo que en dependencia de las necesidades de la administración de la red se adaptara
uno de ellos. En general ni uno ni otro ofrece una solución que encuentre todas las exigencias, pues
ninguno de los dos es completo.
Esta configuración está basada en el uso de un protocolo de configuración de direcciones tal como
DHCPv6, para obtener las direcciones y otros parámetros de configuración. Un host usa
autoconfiguración DHCPv6 cuando recibe un mensaje de advertencia del enrutador (Routers
Advertisement message) sin opciones de Información de Prefijo (Prefix Information options) y además
las banderas de ¨Managed Address Configuration¨ y Öther Stateful Configuration¨ son fijadas a 1. Un
host puede también usar autoconfiguración DHCPv6 cuando no existe enrutador presente en el enlace
local.
Para comprender mejor el proceso de autoconfiguración es necesario conocer los diferentes estados
en que pueden estar las direcciones auto configuradas:
- Tentativo o Provisional: Es cuando la dirección está en el proceso de ser verificada como
única. Esta verificación ocurre a través del proceso de detección de direcciones
duplicadas. Un nodo no puede recibir tráfico único (unicast) dirigido a una dirección
tentativa. Con esta dirección sin embargo puede recibir y procesar mensajes de Aviso de
vecinos que han sido enviados durante la detección de direcciones.
- Válido o Vigente: En este estado la dirección puede ser utilizada para enviar y recibir
tráfico único (unicast). El estado Válido incluye los estados de Preferido o Desfavorecido.
La suma de los tiempos que una dirección permanece en los estados Válido, Preferido y
Desfavorecido está determinada por el campo de Tiempo de Vida Válido en la
información de prefijo de un mensaje RA o en el campo de Tiempo de Vida Válido de
una opción de Identificación (IA) de DHCPv6.
- Preferido: En este estado la dirección es válida, su unicidad ha sido verificada y puede
ser utilizada para comunicaciones sin límite. Un nodo puede enviar y recibir tráfico único
hacia o desde una dirección preferida. El período de tiempo que una dirección puede
permanecer en estado Preferido está determinado por el campo de Tiempo de Vida
Preferido en la opción de Información de Prefijo de un mensaje RA o en el campo de
Tiempo de Vida Válido de una opción de Identificación (IA) de DHCPv6.
- Desfavorecido: En este estado la dirección es válida y su unicidad ha sido verificada pero
su uso es desalentado para nuevas comunicaciones. Las sesiones de comunicación
existentes puede aún estar usando direcciones en este estado.
- Inválido: En este estado la dirección no puede ser largamente utilizada para enviar o
recibir tráfico único. Una dirección entra en este estado después que el Tiempo de Vida
Válido expira.
113
O sea que una dirección auto configurada pasa por diferentes estados, pudiéndose apreciar en la
Figura 5.79 la relación entre los estados durante el transcurso de los tiempos de vida Preferido y de
vida Válido.
Fig.5.79 Relación entre el estado de una dirección y sus tiempos de duración de vida
Proceso de Autoconfiguración
El proceso de autoconfiguración de direcciones definido en la RFC 4862 para una interfaz de un nodo
IPv6 es el siguiente:
1. Una dirección Local de Enlace en estado tentativo es obtenida como resultado de un
prefijo fe80::/64 y un identificador de Interfaz en formato EUI-64.
2. Utilizando la detección de direcciones duplicadas para verificar su unicidad, un mensaje
de solicitud de Vecino (NS) es enviado con el campo de dirección objetivo (Target
Address) fijado como dirección local de enlace en estado tentativo.
3. Si un mensaje de Anuncio de Vecino (NA) es recibido en respuesta al mensaje NS, y el
mismo indica que otro nodo está utilizando esa dirección local de enlace, entonces el
proceso de auto configuración se detiene. En este momento la configuración manual
tendrá que ser ejecutada en el nodo.
4. Si ningún mensaje NA es recibido, entonces la dirección Local de Enlace es considerada
como única y pasa al estado Válido. La dirección de enlace local es inicializada por la
interfaz. Por lo que la dirección de Grupo (multicast) de nivel de enlace denominada de
Nodo-Solicitado correspondiente a esa dirección de enlace local será registrada con el
adaptador de red.
Para una estación IPv6 la autoconfiguración de direcciones continua de la forma siguiente:
1- La estación (host) envía un mensaje RS solicitando enrutador. Mientras que los
Enrutadores envían periódicamente mensajes de tipo RA, las estaciones no esperan y
envían hasta tres mensajes RS.
2- Si ningún mensaje RA es recibido, la estación utiliza un protocolo de configuración de
direcciones para obtener direcciones y otros parámetros de configuración.
3- Si un mensaje RA es recibido entonces son fijados los parámetros de límite de saltos,
tiempo de alcance, tiempo de retransmisión y la MTU (si esta opción está presente).
4- Para cada opción de Información de Prefijo presente, entonces ocurren las acciones
siguientes:
a) Si la bandera de Enlace (On- Link) está a 1, entonces el prefijo es añadido a la lista.
b) Si la bandera de Autonomía (Autonomus) está fijada a 1, el prefijo y un identificador de
interfaz apropiado son utilizados para obtener una dirección tentativa.
114
c) La detección de direcciones duplicadas es utilizada para verificar la unicidad de la

dirección tentativa.
d) Si la dirección tentativa está en uso, entonces no es inicializado el empleo de esa
dirección tentativa.
e) Si la dirección tentativa no está en uso, entonces la dirección es inicializada. Lo que
incluye fijar los tiempos de vida válidos y preferidos a partir de los valores de estos
campos de Información de Prefijo. Si hace falta esto incluye registrar la dirección de
grupo de nivel de enlace de la dirección correspondiente de Nodo-Solicitado para la
nueva dirección con el adaptador de red.
5- Si la bandera de Configuración de Dirección de Gestión (Managed Address Configuration)
está fijada a 1 en el mensaje RA, entonces una dirección del protocolo de configuración es
utilizada para obtener direcciones adicionales.
6- Si la bandera de Configuración plena (Other Stateful Configuration) está fijada a 1 en el
mensaje RA, el protocolo de configuración de direcciones es utilizado para obtener los
parámetros de configuración adicionales.
El proceso de autoconfiguración abarca crear una dirección de Enlace Local y verificar su unicidad
sobre un enlace, determinando que información debe ser autoconfigurada (direcciones, otra
información o ambas).
El mecanismo de configuración sin estado (stateless) no requiere configuración manual del host,
mínima (o ninguna) configuración de enrutadores y no requiere servidores adicionales. Permite al host
generar su propia dirección usando una combinación de la información disponible localmente, y la
información ofrecida por los enrutadores. Los enrutadores informan el prefijo que identifica la
subred(es) asociadas con un enlace, mientras que el host genera un ïdentificador de interface¨ que
identifica únicamente una interface en una subred. La dirección se forma por la combinación de ambos.
En ausencia del enrutador, un host puede solamente generar una dirección de enlace local; que es
suficiente para permitir la comunicación entre nodos conectados al mismo enlace.
Una dirección global se forma por la unión de un identificador de interface a un prefijo de longitud
apropiada. Los prefijos se obtienen de las opciones de información de prefijos (Prefix Information
options) contenida en los mensajes RA (Router Advertisements).
A continuación se muestra la Figura 5.80 del proceso de autoconfiguración sin estado (Stateless),
donde se puede observar que la dirección única global IPv6 se forma del prefijo de la subred más la
dirección del identificador de la interfaz generada a partir de la dirección MAC del nivel de enlace.
115
. Fig.5.80 Proceso de autoconfiguración SLAAC
En el mismo las estaciones (Host) pueden enviar mensajes de Solicitud de Enrutadores (RS) y
escuchar los Anuncios de los Enrutadores (RA) sobre la subred local, con vistas a obtener los prefijos
de subred de 64 Bits y otros parámetros a partir de los mensajes RA.
Se debe recordar que las estaciones calculan el identificador de Interfaz (ID de interfaz) en formato
EUI-64 a partir de la dirección MAC y lo concatenan con el prefijo de subred enviado por el Enrutador
para formar la dirección IPv6.
Por ejemplo considere:

Prefijo de enlace enviado en el mensajes RA: 2001:db8:abcd:1234::/64
Dirección MAC de la interfaz en la Host: 00:1b:63:94:9d:73
Identificador de Interfaz en formato EUI-64: 021b:63ff:fe94:9d73
Dirección IPv6 resultante: 2001:db8:abcd:1234:021b:63ff:fe94:9d73
Direcciones autoconfiguradas para el protocolo IPv6 en el Sistema Operativo Windows.

Por defecto las siguientes direcciones IPv6 son configuradas de forma automática para el protocolo
IPv6 en Windows Server 2012, Windows Server 2008 R2, Windows Server 2008, Windows 8, Windows
7 y Windows Vista:
- Direcciones Locales de Enlace utilizando identificadores de interfaces derivados
aleatoriamente, que son son asignadas para todas las interfaces de Red de Área Local
(LAN)
- Si es incluido un prefijo global o local único en una opción de Información de Prefijo con
la bandera de Autonomía fijada a 1 de un mensaje RA, entonces una Dirección Global
única o Local única utilizando aleatoriamente identificadores de interfaces será asignada
a la interfaz de la LAN que recibió el RA.
Este es el comportamiento por defecto para Windows 8, Windows 7 y Windows Vista. Mientras que
Windows Server 2012, Windows Server 2008 R2 y Windows Server 2008 no crean direcciones
temporales por defecto.
Se pueden habilitar direcciones temporales con el comando:
netsh interface ipv6 set privacy enabled
En Windows Server 2012, con el comando:
Set-NetIPv6Protocol -UseTemporaryAddresses Enabled Windows PowerShell

Interconexión de Redes IP-5-IPv6-Protocolos Asociados

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Interconexión de Redes IP-5-IPv6-Protocolos Asociados

Cargado por

Copyright:

Formatos disponibles

INTERCONEXIÓN DE REDES

Autor: Dr. Félix F. Alvarez Paliza

Protocolos Asociados a IPv6

Fig.5.70 Comparación de protocolos asociados a IPv4 e IPv6

El encabezado ICMPv6 es identificado por un valor de 58 decimal en el campo NH `precedente.

Fig.5.71 Formato general de un mensaje ICMPv6

Fig. 5.72 Tipos de mensajes que posee ICMPv6

3 Tiempo excedido (Time Exceeded)

Entre los mensajes de información de ICMPv6:

Paquete demasiado grande

Protocolo de Descubrimiento de Vecinos (Neighbor Discovery, ND)

 Determinar prefijos y otros datos de configuración de la red

A continuación se describe cada uno de los mecanismos y procesos:

Fig. 5.73 Estructura de un Mensaje de Anuncio de Router (RA)

Fig. 5.74 Estructura de un Mensaje de Solicitud de Router (RS)

La dirección de Multidifusión de Nodo-Solicitado es construida con el prefijo ff02::1:ff00:0/104 y los

A continuación en la Figura 5.76 se muestra el proceso de conformación de una dirección de grupo

Fig.5.76 Ejemplo de Dirección de Nodo-Solicitado

Mensajes de Anuncio de Vecinos (NA)

En la cabecera IPv6 igualmente en correspondencia de la situación la dirección fuerte será una

Fig.5.78 Estructura de un mensaje de Anuncio de Vecino (NA)

Protocolo para Descubrir Oyentes de Multidifusión (Multicast Listener Discovery, MLD)

Definiéndose originalmente en la RFC 2710 tres tipos de mensajes:

Mensaje de Búsqueda de Oyentes de Multidifusión

En el encabezado IPv6, la dirección de origen es la dirección local de vínculo de la interfaz en la que

Mensaje de Reporte de Oyente de Multidifusión (Multicast Listener Report)

Mensaje de Escucha de multidifusión terminada (Multicast Listener Done)

Posteriormente en MLDv2 (RFC 3810) se especificaron dos nuevos tipos de mensajes:

- - Y otro relacionado con el Mensaje de Reporte de Oyente de Multidifusión (tipo 143).

Existen tres tipos de autoconfiguración:

 Mezcla de SLAAC y DHCPv6

c) La detección de direcciones duplicadas es utilizada para verificar la unicidad de la

. Fig.5.80 Proceso de autoconfiguración SLAAC

Por ejemplo considere:

Direcciones autoconfiguradas para el protocolo IPv6 en el Sistema Operativo Windows.

También podría gustarte