INTERCONEXIÓN DE REDES CAPÍTULO 5 IPv6- PROTOCOLOS ASOCIADOS

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

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. 98 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:

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

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 101

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. 102 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:

Después del campo de Límite de Saltos sigue el campo de Banderas, donde se tiene información importante: - Cuando la Bandera M es fijada a 1, la misma 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. 103 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). 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 104 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

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. 105 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.

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. 107

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: 108 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.

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. 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 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. 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 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) 109

- - 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 110

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. 111 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 ( Other 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.

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 Other Stateful Configuration son fijadas a 1. Un host puede también usar autoconfiguración DHCPv6 cuando no existe enrutador presente en el enlace local. Ambas 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 Other Stateful Configuration fijadas a 1. 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. 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. 112

113 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 autocofiguració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. c) La detección de direcciones duplicadas es utilizada para verificar la unicidad de la dirección tentativa.

114 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 identificador 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.. Fig.5.80 Proceso de autoconfiguración SLAAC

115 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 DHCPv6 DHCPv6 es definido en la RFC 3315 para ofrecer configuración de direcciones de forma manifiesta o fijación de direcciones sin estado para estaciones IPv6. Una estación IPv6 utiliza un protocolo de configuración tal como el DHCPv6 en dependencia de las banderas en un mensaje RA enviado por un Enrutador vecino: - Si la bandera M (Managed Address Configuration) está fijada a 1, la misma indica que la estación tiene que utilizar un protocolo de configuración de estado (Stateful Autoconfiguration, DHCPv6) para obtener sus direcciones de forma manifiesta. Parecido a DHCP para IPv4 los componentes de la infraestructura de DHCPv6 constan de clientes que solicitan información y servidores que ofrecen la configuración. También están los agentes retransmisores o repetidores de mensajes entre clientes y servidores cuando los clientes esta en subredes donde no está el servidor DHCPv6. Un elemento significativo que diferencia a DHCPv6 y DHCP para IPv4 es que las estaciones no se configuran de forma automática a una subred directamente conectada, cuyo prefijo de 64 Bits es asignado por el Servidor DHCPv6. La ruta de la subred directamente conectada tiene que ser anunciada por un Enrutador que este sobre la subred mediante la fijación de la bandera Sobre el enlace (On-Link) en el campo de opción de Información de Prefijo del mensaje RS. Sin embargo si el anuncio del Enrutador no limpia la bandera de Autonomía (Autonomous) en la opción de Información de Ruta, la estación IPv6 receptora configurará dos direcciones IPv6: Una dirección IPv6 asignada por el servidor DHCPv6 y una dirección IPv6 sin estado generada por la estación basada en el prefijo anunciado. Este comportamiento podría también ocurrir si se tienen dos Enrutadores que no tengan la configuración acoplada (matched); uno con la bandera de autonomía fijada y otro sin ella. Para evitar esta situación y tener que la estación IPv6 solo use las direcciones asignadas por el servidor DHCPv6, hay que configurar los Enrutadores de aviso, con la bandera de Autonomía limpia (clear) en las opciones de Información de Prefijo. Un Enrutador IPv6 corriendo Windows no puede ser configurado para despejar la bandera de Autonomía en la opción de Información del Prefijo.

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 116