Livre IPv6 - User contributions [en]

Protocolo DHCPv6

2012-09-01T23:44:22Z

Jincera: /* Adquisición de la dirección del servidor DHCP */

{{ eSuivi| Protocolo de Descubrimiento de vecinos |Protocolo de descubrimiento de vecinos |Implementación de la autoconfiguración|Implementación de la autoconfiguración}}

__TOC__

==Principios ==

La autoconfiguración o (configuración automática) con y sin estado, busca reducir el esfuerzo de instalación de dispositivos IPv6. La diferencia entre ambas es que la primera ofrece más información de configuración y permite un mayor control sobre la asignación de parámetros de configuración.

Un parámetro de configuración representa información útil para que un dispositivo pueda configurar su interfaz de red con el fin de establecer comunicaciones sobre su enlace o en Internet. El conjunto de parámetros de configuración incluye la siguiente información:

* de direccionamiento, de enrutamiento,
* del servidor de nombres (DNS),
* del servicio de información de red (NIS)
* etcétera.

Cabe resaltar que la información de enrutamiento no está contemplada en los mecanismos de autoconfiguración de IPv6 con o sin estado, sino por el procedimiento de descubrimiento de enrutadores de ICMPv6. Las dos técnicas de autoconfiguración no son mutuamente exclusivas, pueden coexistir en un mismo entorno. Por ejemplo, una máquina puede obtener su dirección unicast global mediante la autoconfiguración sin estado, y recuperar la información sobre el servicio de nombres (DNS) vía la configuración automática con estado.

El mecanismo de configuración automática con estado sigue un modelo de cliente-servidor y se basa en el uso de DHCPv6 (''Dynamic Host ConfigurationProtocol'' para IPv6) como ocurre con DHCP para IPv4, aunque hay grandes diferencias en el código: DHCP en IPv4 no es más que una extensión del protocolo BOOTP, por lo que tiene una funcionalidad limitada. En cambio, el protocolo DHCPv6 permite establecer los parámetros de configuración de un servidor DHCP para un cliente IPv6.

El cliente IPv6 representa un dispositivo que busca tener conectividad global IPv6 y solicita la información de configuración necesaria para poder establecer esta conectividad. El servidor DHCP constituye un punto central que reagrupa los parámetros de configuración. No necesariamente se ubica en el mismo enlace que el cliente, en cuyo caso, la información DHCP puede inercambiarse a través de un relevo. El servidor puede contener información de configuración para dispositivos ubicados en distintos enlaces. El cliente DHCP debe establecer una conexión directa ya sea con el relevo o con el propio servidor DHCP.

El relevo funciona como un "proxy" DHCP que se limita a retransmitir los mensajes DHCP; es transparente a la información intercambiada y no modifica en absoluto los mensajes DHCP intercambiados entre el servidor y el cliente. El proxy encapsula los mensajes DHCP del cliente en un formato específico (''cf'' figura Estructura de los mensajes de relevo) y realiza la operación inversa, es decir, desencapsula los mensajes provenientes del servidor para su entrega al cliente. El servidor forma el mensaje que debe ser recibido por el cliente, y, si no tiene comunicación directa con él, lo encapsula en un mensaje DHCP dirigido al proxy.

Para conocer el estado de los recursos administrados (representados por los parámetros de configuración), el servidor DHCP mantiene una lista de asociaciones entre los parámetros asignados y el cliente. El cliente no puede ser identificado con su dirección unicast ya que ésta es parte de los parámetros otorgados por el servidor DHCP. Por ello, el servidor utiliza un identificador particular: el DUID (''DHCP Unique IDentifier''). El DUID es creado por el cliente y lo identifica a él (al nodo), no a una interfaz. Se han propuesto varios esquemas para generarlo, por ejemplo, a partir de la dirección de enlace local, completada con un elemento que garantice la exclusividad, como un sello de tiempo (''timestamp''). Una vez que el cliente genera un DUID, éste debe ser invariable, incluso si llegara a cambiar su dirección de enlace local.

En realidad, sí es posible utilizar la dirección de enlace local del cliente como identificador, pero no se garantiza que éste sea único en todo el dominio; únicamente se puede asegurar su unicidad a nivel del enlace. Sin embargo, ésta tiene las siguientes ventajas:

* Queda determinada por el cliente durante la primera fase de la configuración automática (''cf'' Configuración automática y el control),
* es permanente para el cliente (no habrá renumeración ni cambio de dirección mientras la tarjeta de red no se cambie).

La asignación de direcciones a cliente es administrada por el servidor bajo la noción de un contenedor llamado IA (''Identity Association''). Una IA se define como una lista (posiblemente vacía) de direcciones IPv6. La idea es que cada cliente tendrá una IA por interfaz; esta IA estará asignada de forma permanente a la interfaz. Por este conducto, la gestión del tiempo de vida de las direcciones o la renumeración del cliente es realizada por el servidor, lo que simplifica el formato de los mensajes y el control de las direcciones.

Conforme al modelo cliente-servidor, los intercambios de información están formados por solicitudes y respuestas. Una transacción suele comenzar a iniciativa del cliente mediante una solicitud DHCP. La confiabilidad del mecanismo queda en manos del cliente, quien reenviará la solicitud DHCP hasta recibir una respuesta, o tener la certeza de que el servidor DHCP no está disponible. DHCPv6 es un protocolo de aplicación que utiliza UDP como protocolo de transporte. El cliente envía sus solicitudes al puerto 547 y recibirá las respuestas en el puerto 546. Típicamente, los mensajes UDP se encapsulan en paquetes IPv6. Además de las comunicaciones punto a punto, DHCPv6 también se sirve de comunicaciones multicast para el descubrimiento de servidores en un sitio.

==Formato de mensajes DHCPv6 ==

El protocolo DHCPv6 se describe en el RFC 3315. Al igual que numerosos protocolos de Internet, el protocolo de intercambio de información está desacoplado de la información en sí misma. La información intercambiada puede cambiar y evolucionar rápidamente sin afectar los mecanismos de este intercambio. Esta separación ofrece al protocolo una estabilidad y cierta capacidad para ser extendido. Esta separación entre el protocolo y la información puede observarse en la estructura misma de las unidades protocolarias. Una unidad del protocolo DHCP sigue el patrón clásico de las estructuras protocolarias: una cabecera que contiene la información propia al protocolo, seguida de una carga útil que alberga la información aplicativa.

En la terminología de DHCP, se le llama mensaje a una unidad del protocolo DHCPv6. Cada mensaje DHCP tiene un formato de encabezado idéntico. Desde este punto de vista, DHCP sigue los principios que condujeron al diseño del segmento TCP: un formato único para todo el conjunto de funciones de TCP. Estos principios privilegian la simplificación en el proceso de desarrollo del protocolo.

La figura Estructura de los mensajes DHCPv6 muestra la estructura de un mensaje DHCPv6. La cabecera se divide en tres partes:

[[Image: CS57.gif]]

* La información de comando codificada en una palabra de 32 bits, designa la función DHCP relacionada con el intercambio. Esta parte contiene el tipo de mensaje y un identificador del intercambio. El primer campo (de 8 bits) muestra el tipo de mensaje y define la función del mensaje en el protocolo. Como su nombre lo indica, el campo ''transaction-ID'' tiene por objeto identificar el intercambio desde el punto de vista del cliente. Le permite asociar las respuestas recibidas a las solicitudes que ha formulado.
* La información de direccionamiento se utiliza para especificar la dirección IPv6 del servidor DHCP. Indica la dirección de la interfaz utilizada por el servidor en la transacción.
* El campo de opciones se utiliza para transmitir las informaciones de configuración. Es un campo de longitud variable cuya codificación sigue el clásico esquema "TLV", es decir, el Tipo de la opción, la Longitud en octetos del elemento que le sigue, que es el Valor del parámetro. El tipo se codifica en dos octetos. El campo de longitud también ocupa dos octetos aún si valor del parámetro es nulo o si éste tiene una longitud fija.

Los mensajes utilizados para la comunicación entre el servidor y el proxy de relevo, son diferentes. Un mensaje de relevo encapsula como una opción, la información del mensaje DHCP del servidor al cliente. El mensaje de relevo tiene un prefijo de enlace que que indica la interfaz del relevo a través de la cual se recibió el mensaje DHCP, o por la que debe ser enviado. La dirección de enlace local del cliente contiene la dirección de la interfaz a configurar en el cliente.

El protocolo DHCPv6 incluye 12 mensajes DHCP distintos:

* Solicitud DHCP (''DHCP Solicit''): <br> Mensaje de solicitud de presencia de servidores DHCP. Se transmite hacia un servidor o un proxy DHCP. Un cliente envía este mensaje para localizar los servidores DHCP.

* Anuncio DHCP (''DHCP Advertise''): <br> Mensaje de presencia de servidores DHCP. Se emite en respuesta a un mensaje de solicitud DHCP para comunicar la dirección IP de un servidor DHCP. El destinatario es el cliente si se encuentra en el mismo enlace que el servidor; de lo contrario, se envía al proxy del cliente.

* Consulta DHCP (''DHCP Request''): <br> Mensaje de solicitud de parámetros de configuración por un cliente sin dirección.
* Confirmación DHCP (''DHCP Confirm''): <br> Mensaje de solicitud de confirmación sobre la validez de los parámetros asignados al cliente.
* Renovación DHCP (''DHCP Renew''): <br> Mensaje de solicitud para prolongar el uso de la dirección IP asignada.
* Reasignación DHCP (''DHCP Rebind''): <br> Igual al mensaje anterior, pero puede ser otro servidor DHCP el que responde, y no necesariamente el que asignó la dirección IP.
* Respuesta DHCP (''DHCP Reply''): <br> Mensaje enviado por el servidor en respuesta a una petición del cliente. Contiene los valores de los parámetros de configuración solicitados.
* Liberación DHCP (''DHCP Release''): <br> Mensaje emitido por el cliente para notificar la liberación de las direcciones IP previamente asignadas por el servidor.
* Denegación DHCP (''DHCP Decline): <br> Mensaje de un cliente indicando que una o varias de las direcciones asignadas ya están siendo utilizadas en su enlace.
* Notificación de reconfiguración DHCP (''DHCP reconfigure-init''): <br> Mensaje enviado por el servidor para notificar al cliente que existen nuevos valores para los parámetros de configuración. El cliente debe iniciar una nueva transacción para adquirir esta información.
* Encapsulación de relevo (''Relay-Forward''): <br> Mensaje del proxy para transportar los mensajes del cliente hacia el servidor. El mensaje del cliente se encapsula en este mensaje.
* Encapsulación del servidor (''Relay-Reply''): <br> Mensaje generado por el servidor hacia el proxy con información destinada al cliente. El proxy extrae el mensaje para el cliente y lo transmitirá sobre el enlace correspondiente.

El intercambio de información entre el cliente y el servidor DHCP se realiza por medio de opciones. La información se divide en tres categorías (''cf'' Tabla Opciones DHCPv6).
* Información temporal. Se refiere a recursos de red solicitados por el cliente y asignados por el servidor por un período determinado. Actualmente, el único tipo de recurso temporal es la dirección IP, cuya gestión se realiza bajo el concepto de IA.
* Información de carácter general. Se refiere al conjunto de parámetros normalmente presentados para la configuración de una máquina IPv6.
* Información específica a DHCP.

{|
|+'''Opciones DHCPv6'''
! Designación || Definición
|-style="background:silver"
|Asociación de identificación (IA) || Lista de direcciones IPv6 de una interfaz de cliente.
|-
|Consultas de opciones (ORO) || Lista de información de configuración solicitada por el cliente.
|-style="background:silver"
|Servidor de Nombres de Dominio || Lista de servidores DNS autorizados por el cliente.
|-
|Dominio de búsqueda || Lista de nombres de dominio que un cliente puede utilizar en la búscada de nombres de DNS.
|-style="background:silver"
|Mensaje cliente || Para la encapsulación del mensaje DHCP del cliente para el proxy
|-
|Mensaje servidor || Para la encapsulación del mensaje DHCP del servidor para el proxy
|-style="background:silver"
|Dirección IPv4 DSTM || Informa al cliente que la dirección asignada es una dirección IPv4 mapeada a IPv6
|-
|Autenticación || Para autenticar al emisor del mensaje DHCP y validar su integridad.
|-style="background:silver"
|Unicast servidor || Para notificar al cliente la dirección unicast del servidor y así establecer la comunicación sin ayuda del proxy. En este caso, el cliente debe tener una dirección unicast válida.
|-
|Identificador DHCP (DUID) || identificador permanente del cliente.
|-style="background:silver"
|Preferencia || Mecanismo ofrecido al cliente para elegir el servidor DHCP. El servidor seleccionado será responsable de proporcionar los parámetros de configuración para ese cliente.
|}

== Adquisición de la dirección del servidor DHCP ==

Para poder configurarse, un dispositivo debe encontrar un servidor DHCP, para lo cual emite un mensaje de Solicitud DHCP. Arma este mensaje mediante el llenado del campo de identificación de la transacción y agregando la opción DUID. El mensaje se envía en modo multicast (dirección <tt>FF02::01:02</tt>) a todos los agentes DHCP en el enlace. El grupo de agentes incluye tanto a los servidores como a los relevos DHCP en un dominio administrativo. Este mensaje no puede ser enrutado pues el cliente utiliza su dirección [[Direccionamiento-Fundamentos#Direccionamiento local: Direcciones locales al enlace|de enlace local.]] Si el servidor no está en el mismo enlace que el cliente, debe haber un relevo en el enlace; por ello es que se utiliza una dirección multicast de cobertura local al enlace.

Cuando esta operación debe cruzar un proxy, el mensaje de Solicitud se encapsula en el campo opción de un mensaje de encapsulación de relevo, teniendo como prefijo el de la interfaz sobre la que el proxy recibe este mensaje. Dependiendo de la configuración del proxy, el mensaje se envía en modo unicast o en multicast para un grupo de servidores DHCP con la dirección por omisión de servidores DHCP del sitio (<tt>FF05::1:3</tt>) o una dirección de grupo propia a ese sitio.

Cuando el mensaje de Solicitud DHCP llega al servidor, éste responde con un mensaje de Anuncio DHPC, indicando su dirección en el campo "Dirección del servidor" y copiando el identificador de transacción que recibió en el mensaje de solicitud. El servidor puede agregar una opción de preferencia. Esta preferencia, codificada en 8 bits, indica la voluntad que tiene el servidor de atender al cliente. El cliente retendrá al servidor que haya presentado el valor de preferencia más alto. De esta manera, se puede realizar un balanceo de carga entre los servidores. Enseguida se emite el mensaje de Anuncio DHCP en unicast directamente al cliente o a través del proxy.

Como la comunicación se establece a través del protocolo de transporte UDP, que no es fiable, DHCP incluye un mecanismo muy sencillo para mejorar la fiabilidad. Cada mensaje de solicitud DHCP emitido, debe recibir un acuse de recibo con otro mensaje DHCP. El iniciador de una operación DHCP detecta que se ha perdido un mensaje con la ayuda de un temporizador. Cuando éste expira, se retranmsite un mensaje DHCP idéntico.

{{ eSuivi| Protocolo de Descubrimiento de vecinos |Protocolo de descubrimiento de vecinos |Implementación de la autoconfiguración|Implementación de la autoconfiguración}}

Protocolo DHCPv6

2012-07-18T22:44:37Z

Jincera: /* Adquisición de la dirección del servidor DHCP */

{{ eSuivi| Protocolo de Descubrimiento de vecinos |Protocolo de descubrimiento de vecinos |Implementación de la autoconfiguración|Implementación de la autoconfiguración}}

__TOC__

==Principios ==

La autoconfiguración o (configuración automática) con y sin estado, busca reducir el esfuerzo de instalación de dispositivos IPv6. La diferencia entre ambas es que la primera ofrece más información de configuración y permite un mayor control sobre la asignación de parámetros de configuración.

Un parámetro de configuración representa información útil para que un dispositivo pueda configurar su interfaz de red con el fin de establecer comunicaciones sobre su enlace o en Internet. El conjunto de parámetros de configuración incluye la siguiente información:

* de direccionamiento, de enrutamiento,
* del servidor de nombres (DNS),
* del servicio de información de red (NIS)
* etcétera.

Cabe resaltar que la información de enrutamiento no está contemplada en los mecanismos de autoconfiguración de IPv6 con o sin estado, sino por el procedimiento de descubrimiento de enrutadores de ICMPv6. Las dos técnicas de autoconfiguración no son mutuamente exclusivas, pueden coexistir en un mismo entorno. Por ejemplo, una máquina puede obtener su dirección unicast global mediante la autoconfiguración sin estado, y recuperar la información sobre el servicio de nombres (DNS) vía la configuración automática con estado.

El mecanismo de configuración automática con estado sigue un modelo de cliente-servidor y se basa en el uso de DHCPv6 (''Dynamic Host ConfigurationProtocol'' para IPv6) como ocurre con DHCP para IPv4, aunque hay grandes diferencias en el código: DHCP en IPv4 no es más que una extensión del protocolo BOOTP, por lo que tiene una funcionalidad limitada. En cambio, el protocolo DHCPv6 permite establecer los parámetros de configuración de un servidor DHCP para un cliente IPv6.

El cliente IPv6 representa un dispositivo que busca tener conectividad global IPv6 y solicita la información de configuración necesaria para poder establecer esta conectividad. El servidor DHCP constituye un punto central que reagrupa los parámetros de configuración. No necesariamente se ubica en el mismo enlace que el cliente, en cuyo caso, la información DHCP puede inercambiarse a través de un relevo. El servidor puede contener información de configuración para dispositivos ubicados en distintos enlaces. El cliente DHCP debe establecer una conexión directa ya sea con el relevo o con el propio servidor DHCP.

El relevo funciona como un "proxy" DHCP que se limita a retransmitir los mensajes DHCP; es transparente a la información intercambiada y no modifica en absoluto los mensajes DHCP intercambiados entre el servidor y el cliente. El proxy encapsula los mensajes DHCP del cliente en un formato específico (''cf'' figura Estructura de los mensajes de relevo) y realiza la operación inversa, es decir, desencapsula los mensajes provenientes del servidor para su entrega al cliente. El servidor forma el mensaje que debe ser recibido por el cliente, y, si no tiene comunicación directa con él, lo encapsula en un mensaje DHCP dirigido al proxy.

Para conocer el estado de los recursos administrados (representados por los parámetros de configuración), el servidor DHCP mantiene una lista de asociaciones entre los parámetros asignados y el cliente. El cliente no puede ser identificado con su dirección unicast ya que ésta es parte de los parámetros otorgados por el servidor DHCP. Por ello, el servidor utiliza un identificador particular: el DUID (''DHCP Unique IDentifier''). El DUID es creado por el cliente y lo identifica a él (al nodo), no a una interfaz. Se han propuesto varios esquemas para generarlo, por ejemplo, a partir de la dirección de enlace local, completada con un elemento que garantice la exclusividad, como un sello de tiempo (''timestamp''). Una vez que el cliente genera un DUID, éste debe ser invariable, incluso si llegara a cambiar su dirección de enlace local.

En realidad, sí es posible utilizar la dirección de enlace local del cliente como identificador, pero no se garantiza que éste sea único en todo el dominio; únicamente se puede asegurar su unicidad a nivel del enlace. Sin embargo, ésta tiene las siguientes ventajas:

* Queda determinada por el cliente durante la primera fase de la configuración automática (''cf'' Configuración automática y el control),
* es permanente para el cliente (no habrá renumeración ni cambio de dirección mientras la tarjeta de red no se cambie).

La asignación de direcciones a cliente es administrada por el servidor bajo la noción de un contenedor llamado IA (''Identity Association''). Una IA se define como una lista (posiblemente vacía) de direcciones IPv6. La idea es que cada cliente tendrá una IA por interfaz; esta IA estará asignada de forma permanente a la interfaz. Por este conducto, la gestión del tiempo de vida de las direcciones o la renumeración del cliente es realizada por el servidor, lo que simplifica el formato de los mensajes y el control de las direcciones.

Conforme al modelo cliente-servidor, los intercambios de información están formados por solicitudes y respuestas. Una transacción suele comenzar a iniciativa del cliente mediante una solicitud DHCP. La confiabilidad del mecanismo queda en manos del cliente, quien reenviará la solicitud DHCP hasta recibir una respuesta, o tener la certeza de que el servidor DHCP no está disponible. DHCPv6 es un protocolo de aplicación que utiliza UDP como protocolo de transporte. El cliente envía sus solicitudes al puerto 547 y recibirá las respuestas en el puerto 546. Típicamente, los mensajes UDP se encapsulan en paquetes IPv6. Además de las comunicaciones punto a punto, DHCPv6 también se sirve de comunicaciones multicast para el descubrimiento de servidores en un sitio.

==Formato de mensajes DHCPv6 ==

El protocolo DHCPv6 se describe en el RFC 3315. Al igual que numerosos protocolos de Internet, el protocolo de intercambio de información está desacoplado de la información en sí misma. La información intercambiada puede cambiar y evolucionar rápidamente sin afectar los mecanismos de este intercambio. Esta separación ofrece al protocolo una estabilidad y cierta capacidad para ser extendido. Esta separación entre el protocolo y la información puede observarse en la estructura misma de las unidades protocolarias. Una unidad del protocolo DHCP sigue el patrón clásico de las estructuras protocolarias: una cabecera que contiene la información propia al protocolo, seguida de una carga útil que alberga la información aplicativa.

En la terminología de DHCP, se le llama mensaje a una unidad del protocolo DHCPv6. Cada mensaje DHCP tiene un formato de encabezado idéntico. Desde este punto de vista, DHCP sigue los principios que condujeron al diseño del segmento TCP: un formato único para todo el conjunto de funciones de TCP. Estos principios privilegian la simplificación en el proceso de desarrollo del protocolo.

La figura Estructura de los mensajes DHCPv6 muestra la estructura de un mensaje DHCPv6. La cabecera se divide en tres partes:

[[Image: CS57.gif]]

* La información de comando codificada en una palabra de 32 bits, designa la función DHCP relacionada con el intercambio. Esta parte contiene el tipo de mensaje y un identificador del intercambio. El primer campo (de 8 bits) muestra el tipo de mensaje y define la función del mensaje en el protocolo. Como su nombre lo indica, el campo ''transaction-ID'' tiene por objeto identificar el intercambio desde el punto de vista del cliente. Le permite asociar las respuestas recibidas a las solicitudes que ha formulado.
* La información de direccionamiento se utiliza para especificar la dirección IPv6 del servidor DHCP. Indica la dirección de la interfaz utilizada por el servidor en la transacción.
* El campo de opciones se utiliza para transmitir las informaciones de configuración. Es un campo de longitud variable cuya codificación sigue el clásico esquema "TLV", es decir, el Tipo de la opción, la Longitud en octetos del elemento que le sigue, que es el Valor del parámetro. El tipo se codifica en dos octetos. El campo de longitud también ocupa dos octetos aún si valor del parámetro es nulo o si éste tiene una longitud fija.

Los mensajes utilizados para la comunicación entre el servidor y el proxy de relevo, son diferentes. Un mensaje de relevo encapsula como una opción, la información del mensaje DHCP del servidor al cliente. El mensaje de relevo tiene un prefijo de enlace que que indica la interfaz del relevo a través de la cual se recibió el mensaje DHCP, o por la que debe ser enviado. La dirección de enlace local del cliente contiene la dirección de la interfaz a configurar en el cliente.

El protocolo DHCPv6 incluye 12 mensajes DHCP distintos:

* Solicitud DHCP (''DHCP Solicit''): <br> Mensaje de solicitud de presencia de servidores DHCP. Se transmite hacia un servidor o un proxy DHCP. Un cliente envía este mensaje para localizar los servidores DHCP.

* Anuncio DHCP (''DHCP Advertise''): <br> Mensaje de presencia de servidores DHCP. Se emite en respuesta a un mensaje de solicitud DHCP para comunicar la dirección IP de un servidor DHCP. El destinatario es el cliente si se encuentra en el mismo enlace que el servidor; de lo contrario, se envía al proxy del cliente.

* Consulta DHCP (''DHCP Request''): <br> Mensaje de solicitud de parámetros de configuración por un cliente sin dirección.
* Confirmación DHCP (''DHCP Confirm''): <br> Mensaje de solicitud de confirmación sobre la validez de los parámetros asignados al cliente.
* Renovación DHCP (''DHCP Renew''): <br> Mensaje de solicitud para prolongar el uso de la dirección IP asignada.
* Reasignación DHCP (''DHCP Rebind''): <br> Igual al mensaje anterior, pero puede ser otro servidor DHCP el que responde, y no necesariamente el que asignó la dirección IP.
* Respuesta DHCP (''DHCP Reply''): <br> Mensaje enviado por el servidor en respuesta a una petición del cliente. Contiene los valores de los parámetros de configuración solicitados.
* Liberación DHCP (''DHCP Release''): <br> Mensaje emitido por el cliente para notificar la liberación de las direcciones IP previamente asignadas por el servidor.
* Denegación DHCP (''DHCP Decline): <br> Mensaje de un cliente indicando que una o varias de las direcciones asignadas ya están siendo utilizadas en su enlace.
* Notificación de reconfiguración DHCP (''DHCP reconfigure-init''): <br> Mensaje enviado por el servidor para notificar al cliente que existen nuevos valores para los parámetros de configuración. El cliente debe iniciar una nueva transacción para adquirir esta información.
* Encapsulación de relevo (''Relay-Forward''): <br> Mensaje del proxy para transportar los mensajes del cliente hacia el servidor. El mensaje del cliente se encapsula en este mensaje.
* Encapsulación del servidor (''Relay-Reply''): <br> Mensaje generado por el servidor hacia el proxy con información destinada al cliente. El proxy extrae el mensaje para el cliente y lo transmitirá sobre el enlace correspondiente.

El intercambio de información entre el cliente y el servidor DHCP se realiza por medio de opciones. La información se divide en tres categorías (''cf'' Tabla Opciones DHCPv6).
* Información temporal. Se refiere a recursos de red solicitados por el cliente y asignados por el servidor por un período determinado. Actualmente, el único tipo de recurso temporal es la dirección IP, cuya gestión se realiza bajo el concepto de IA.
* Información de carácter general. Se refiere al conjunto de parámetros normalmente presentados para la configuración de una máquina IPv6.
* Información específica a DHCP.

{|
|+'''Opciones DHCPv6'''
! Designación || Definición
|-style="background:silver"
|Asociación de identificación (IA) || Lista de direcciones IPv6 de una interfaz de cliente.
|-
|Consultas de opciones (ORO) || Lista de información de configuración solicitada por el cliente.
|-style="background:silver"
|Servidor de Nombres de Dominio || Lista de servidores DNS autorizados por el cliente.
|-
|Dominio de búsqueda || Lista de nombres de dominio que un cliente puede utilizar en la búscada de nombres de DNS.
|-style="background:silver"
|Mensaje cliente || Para la encapsulación del mensaje DHCP del cliente para el proxy
|-
|Mensaje servidor || Para la encapsulación del mensaje DHCP del servidor para el proxy
|-style="background:silver"
|Dirección IPv4 DSTM || Informa al cliente que la dirección asignada es una dirección IPv4 mapeada a IPv6
|-
|Autenticación || Para autenticar al emisor del mensaje DHCP y validar su integridad.
|-style="background:silver"
|Unicast servidor || Para notificar al cliente la dirección unicast del servidor y así establecer la comunicación sin ayuda del proxy. En este caso, el cliente debe tener una dirección unicast válida.
|-
|Identificador DHCP (DUID) || identificador permanente del cliente.
|-style="background:silver"
|Preferencia || Mecanismo ofrecido al cliente para elegir el servidor DHCP. El servidor seleccionado será responsable de proporcionar los parámetros de configuración para ese cliente.
|}

== Adquisición de la dirección del servidor DHCP ==

Para poder configurarse, un dispositivo debe encontrar un servidor DHCP, para lo cual emite un mensaje de Solicitud DHCP. Arma este mensaje mediante el llenado del campo de identificación de la transacción y agregando la opción DUID. El mensaje se envía en modo multicast (dirección <tt>FF02::01:02</tt>) a todos los agentes DHCP en el enlace. El grupo de agentes incluye tanto a los servidores como a los relevos DHCP en un dominio administrativo. Este mensaje no puede ser enrutado pues el cliente utiliza su dirección [[Direccionamiento-Fundamentos#Direccionamiento local: Direcciones locales al enlace|de enlace local.]] Si el servidor no está en el mismo enlace que el cliente, debe haber un relevo en el enlace; por ello es que se utiliza una dirección multicast de cobertura local al enlace.

Cuando esta operación debe cruzar un proxy, el mensaje de Solicitud se encapsula en el campo opción de un mensaje de encapsulación de relevo, teniendo como prefijo el de la interfaz sobre la que el proxy recibe este mensaje. Dependiendo de la configuración del proxy, el mensaje se envía en modo unicast o en multicast para un grupo de servidores DHCP con la dirección por omisión de servidores DHCP del sitio (<tt>FF05::1:3</tt>) o una dirección de grupo propia a ese sitio.

Cuando el mensaje de Solicitud DHCP llega al servidor, éste responde con un mensaje de Anuncio DHPC, indicando su dirección en el campo "Dirección del servidor" y copiando el identificador de transacción que recibió en el mensaje de solicitud. El servidor puede agregar una opción de preferencia. Esta preferencia, codificada en 8 bits, indica la voluntad que tiene el servidor de atender al cliente. El cliente retendrá al servidor que haya presentado el valor de preferencia más alto. De esta manera, se puede realizar un balanceo de carga entre los servidores. Enseguida se emite el mensaje de Anuncio DHCP en unicast directamente al cliente o a través del proxy.

Como la comunicación se establece a través del protocolo de transporte UDP, que no es fiable, DHCP incluye un mecanismo muy sencillo para mejorar la fiabilidad. Cada mensaje de solicitud DHCP imitido, debe recibir un acuse de recibo con otro mensaje DHCP. El iniciador de una operación DHCP detecta que se ha perdido un mensaje con la ayuda de un temporizador. Cuando éste expira, se retranmsite un mensaje DHCP idéntico.

{{ eSuivi| Protocolo de Descubrimiento de vecinos |Protocolo de descubrimiento de vecinos |Implementación de la autoconfiguración|Implementación de la autoconfiguración}}

Protocolo DHCPv6

2012-07-18T22:28:32Z

Jincera: /* Adquisición de la dirección del servidor DHCP */

{{ eSuivi| Protocolo de Descubrimiento de vecinos |Protocolo de descubrimiento de vecinos |Implementación de la autoconfiguración|Implementación de la autoconfiguración}}

__TOC__

==Principios ==

La autoconfiguración o (configuración automática) con y sin estado, busca reducir el esfuerzo de instalación de dispositivos IPv6. La diferencia entre ambas es que la primera ofrece más información de configuración y permite un mayor control sobre la asignación de parámetros de configuración.

Un parámetro de configuración representa información útil para que un dispositivo pueda configurar su interfaz de red con el fin de establecer comunicaciones sobre su enlace o en Internet. El conjunto de parámetros de configuración incluye la siguiente información:

* de direccionamiento, de enrutamiento,
* del servidor de nombres (DNS),
* del servicio de información de red (NIS)
* etcétera.

Cabe resaltar que la información de enrutamiento no está contemplada en los mecanismos de autoconfiguración de IPv6 con o sin estado, sino por el procedimiento de descubrimiento de enrutadores de ICMPv6. Las dos técnicas de autoconfiguración no son mutuamente exclusivas, pueden coexistir en un mismo entorno. Por ejemplo, una máquina puede obtener su dirección unicast global mediante la autoconfiguración sin estado, y recuperar la información sobre el servicio de nombres (DNS) vía la configuración automática con estado.

El mecanismo de configuración automática con estado sigue un modelo de cliente-servidor y se basa en el uso de DHCPv6 (''Dynamic Host ConfigurationProtocol'' para IPv6) como ocurre con DHCP para IPv4, aunque hay grandes diferencias en el código: DHCP en IPv4 no es más que una extensión del protocolo BOOTP, por lo que tiene una funcionalidad limitada. En cambio, el protocolo DHCPv6 permite establecer los parámetros de configuración de un servidor DHCP para un cliente IPv6.

El cliente IPv6 representa un dispositivo que busca tener conectividad global IPv6 y solicita la información de configuración necesaria para poder establecer esta conectividad. El servidor DHCP constituye un punto central que reagrupa los parámetros de configuración. No necesariamente se ubica en el mismo enlace que el cliente, en cuyo caso, la información DHCP puede inercambiarse a través de un relevo. El servidor puede contener información de configuración para dispositivos ubicados en distintos enlaces. El cliente DHCP debe establecer una conexión directa ya sea con el relevo o con el propio servidor DHCP.

El relevo funciona como un "proxy" DHCP que se limita a retransmitir los mensajes DHCP; es transparente a la información intercambiada y no modifica en absoluto los mensajes DHCP intercambiados entre el servidor y el cliente. El proxy encapsula los mensajes DHCP del cliente en un formato específico (''cf'' figura Estructura de los mensajes de relevo) y realiza la operación inversa, es decir, desencapsula los mensajes provenientes del servidor para su entrega al cliente. El servidor forma el mensaje que debe ser recibido por el cliente, y, si no tiene comunicación directa con él, lo encapsula en un mensaje DHCP dirigido al proxy.

Para conocer el estado de los recursos administrados (representados por los parámetros de configuración), el servidor DHCP mantiene una lista de asociaciones entre los parámetros asignados y el cliente. El cliente no puede ser identificado con su dirección unicast ya que ésta es parte de los parámetros otorgados por el servidor DHCP. Por ello, el servidor utiliza un identificador particular: el DUID (''DHCP Unique IDentifier''). El DUID es creado por el cliente y lo identifica a él (al nodo), no a una interfaz. Se han propuesto varios esquemas para generarlo, por ejemplo, a partir de la dirección de enlace local, completada con un elemento que garantice la exclusividad, como un sello de tiempo (''timestamp''). Una vez que el cliente genera un DUID, éste debe ser invariable, incluso si llegara a cambiar su dirección de enlace local.

En realidad, sí es posible utilizar la dirección de enlace local del cliente como identificador, pero no se garantiza que éste sea único en todo el dominio; únicamente se puede asegurar su unicidad a nivel del enlace. Sin embargo, ésta tiene las siguientes ventajas:

* Queda determinada por el cliente durante la primera fase de la configuración automática (''cf'' Configuración automática y el control),
* es permanente para el cliente (no habrá renumeración ni cambio de dirección mientras la tarjeta de red no se cambie).

La asignación de direcciones a cliente es administrada por el servidor bajo la noción de un contenedor llamado IA (''Identity Association''). Una IA se define como una lista (posiblemente vacía) de direcciones IPv6. La idea es que cada cliente tendrá una IA por interfaz; esta IA estará asignada de forma permanente a la interfaz. Por este conducto, la gestión del tiempo de vida de las direcciones o la renumeración del cliente es realizada por el servidor, lo que simplifica el formato de los mensajes y el control de las direcciones.

Conforme al modelo cliente-servidor, los intercambios de información están formados por solicitudes y respuestas. Una transacción suele comenzar a iniciativa del cliente mediante una solicitud DHCP. La confiabilidad del mecanismo queda en manos del cliente, quien reenviará la solicitud DHCP hasta recibir una respuesta, o tener la certeza de que el servidor DHCP no está disponible. DHCPv6 es un protocolo de aplicación que utiliza UDP como protocolo de transporte. El cliente envía sus solicitudes al puerto 547 y recibirá las respuestas en el puerto 546. Típicamente, los mensajes UDP se encapsulan en paquetes IPv6. Además de las comunicaciones punto a punto, DHCPv6 también se sirve de comunicaciones multicast para el descubrimiento de servidores en un sitio.

==Formato de mensajes DHCPv6 ==

El protocolo DHCPv6 se describe en el RFC 3315. Al igual que numerosos protocolos de Internet, el protocolo de intercambio de información está desacoplado de la información en sí misma. La información intercambiada puede cambiar y evolucionar rápidamente sin afectar los mecanismos de este intercambio. Esta separación ofrece al protocolo una estabilidad y cierta capacidad para ser extendido. Esta separación entre el protocolo y la información puede observarse en la estructura misma de las unidades protocolarias. Una unidad del protocolo DHCP sigue el patrón clásico de las estructuras protocolarias: una cabecera que contiene la información propia al protocolo, seguida de una carga útil que alberga la información aplicativa.

En la terminología de DHCP, se le llama mensaje a una unidad del protocolo DHCPv6. Cada mensaje DHCP tiene un formato de encabezado idéntico. Desde este punto de vista, DHCP sigue los principios que condujeron al diseño del segmento TCP: un formato único para todo el conjunto de funciones de TCP. Estos principios privilegian la simplificación en el proceso de desarrollo del protocolo.

La figura Estructura de los mensajes DHCPv6 muestra la estructura de un mensaje DHCPv6. La cabecera se divide en tres partes:

[[Image: CS57.gif]]

* La información de comando codificada en una palabra de 32 bits, designa la función DHCP relacionada con el intercambio. Esta parte contiene el tipo de mensaje y un identificador del intercambio. El primer campo (de 8 bits) muestra el tipo de mensaje y define la función del mensaje en el protocolo. Como su nombre lo indica, el campo ''transaction-ID'' tiene por objeto identificar el intercambio desde el punto de vista del cliente. Le permite asociar las respuestas recibidas a las solicitudes que ha formulado.
* La información de direccionamiento se utiliza para especificar la dirección IPv6 del servidor DHCP. Indica la dirección de la interfaz utilizada por el servidor en la transacción.
* El campo de opciones se utiliza para transmitir las informaciones de configuración. Es un campo de longitud variable cuya codificación sigue el clásico esquema "TLV", es decir, el Tipo de la opción, la Longitud en octetos del elemento que le sigue, que es el Valor del parámetro. El tipo se codifica en dos octetos. El campo de longitud también ocupa dos octetos aún si valor del parámetro es nulo o si éste tiene una longitud fija.

Los mensajes utilizados para la comunicación entre el servidor y el proxy de relevo, son diferentes. Un mensaje de relevo encapsula como una opción, la información del mensaje DHCP del servidor al cliente. El mensaje de relevo tiene un prefijo de enlace que que indica la interfaz del relevo a través de la cual se recibió el mensaje DHCP, o por la que debe ser enviado. La dirección de enlace local del cliente contiene la dirección de la interfaz a configurar en el cliente.

El protocolo DHCPv6 incluye 12 mensajes DHCP distintos:

* Solicitud DHCP (''DHCP Solicit''): <br> Mensaje de solicitud de presencia de servidores DHCP. Se transmite hacia un servidor o un proxy DHCP. Un cliente envía este mensaje para localizar los servidores DHCP.

* Anuncio DHCP (''DHCP Advertise''): <br> Mensaje de presencia de servidores DHCP. Se emite en respuesta a un mensaje de solicitud DHCP para comunicar la dirección IP de un servidor DHCP. El destinatario es el cliente si se encuentra en el mismo enlace que el servidor; de lo contrario, se envía al proxy del cliente.

* Consulta DHCP (''DHCP Request''): <br> Mensaje de solicitud de parámetros de configuración por un cliente sin dirección.
* Confirmación DHCP (''DHCP Confirm''): <br> Mensaje de solicitud de confirmación sobre la validez de los parámetros asignados al cliente.
* Renovación DHCP (''DHCP Renew''): <br> Mensaje de solicitud para prolongar el uso de la dirección IP asignada.
* Reasignación DHCP (''DHCP Rebind''): <br> Igual al mensaje anterior, pero puede ser otro servidor DHCP el que responde, y no necesariamente el que asignó la dirección IP.
* Respuesta DHCP (''DHCP Reply''): <br> Mensaje enviado por el servidor en respuesta a una petición del cliente. Contiene los valores de los parámetros de configuración solicitados.
* Liberación DHCP (''DHCP Release''): <br> Mensaje emitido por el cliente para notificar la liberación de las direcciones IP previamente asignadas por el servidor.
* Denegación DHCP (''DHCP Decline): <br> Mensaje de un cliente indicando que una o varias de las direcciones asignadas ya están siendo utilizadas en su enlace.
* Notificación de reconfiguración DHCP (''DHCP reconfigure-init''): <br> Mensaje enviado por el servidor para notificar al cliente que existen nuevos valores para los parámetros de configuración. El cliente debe iniciar una nueva transacción para adquirir esta información.
* Encapsulación de relevo (''Relay-Forward''): <br> Mensaje del proxy para transportar los mensajes del cliente hacia el servidor. El mensaje del cliente se encapsula en este mensaje.
* Encapsulación del servidor (''Relay-Reply''): <br> Mensaje generado por el servidor hacia el proxy con información destinada al cliente. El proxy extrae el mensaje para el cliente y lo transmitirá sobre el enlace correspondiente.

El intercambio de información entre el cliente y el servidor DHCP se realiza por medio de opciones. La información se divide en tres categorías (''cf'' Tabla Opciones DHCPv6).
* Información temporal. Se refiere a recursos de red solicitados por el cliente y asignados por el servidor por un período determinado. Actualmente, el único tipo de recurso temporal es la dirección IP, cuya gestión se realiza bajo el concepto de IA.
* Información de carácter general. Se refiere al conjunto de parámetros normalmente presentados para la configuración de una máquina IPv6.
* Información específica a DHCP.

{|
|+'''Opciones DHCPv6'''
! Designación || Definición
|-style="background:silver"
|Asociación de identificación (IA) || Lista de direcciones IPv6 de una interfaz de cliente.
|-
|Consultas de opciones (ORO) || Lista de información de configuración solicitada por el cliente.
|-style="background:silver"
|Servidor de Nombres de Dominio || Lista de servidores DNS autorizados por el cliente.
|-
|Dominio de búsqueda || Lista de nombres de dominio que un cliente puede utilizar en la búscada de nombres de DNS.
|-style="background:silver"
|Mensaje cliente || Para la encapsulación del mensaje DHCP del cliente para el proxy
|-
|Mensaje servidor || Para la encapsulación del mensaje DHCP del servidor para el proxy
|-style="background:silver"
|Dirección IPv4 DSTM || Informa al cliente que la dirección asignada es una dirección IPv4 mapeada a IPv6
|-
|Autenticación || Para autenticar al emisor del mensaje DHCP y validar su integridad.
|-style="background:silver"
|Unicast servidor || Para notificar al cliente la dirección unicast del servidor y así establecer la comunicación sin ayuda del proxy. En este caso, el cliente debe tener una dirección unicast válida.
|-
|Identificador DHCP (DUID) || identificador permanente del cliente.
|-style="background:silver"
|Preferencia || Mecanismo ofrecido al cliente para elegir el servidor DHCP. El servidor seleccionado será responsable de proporcionar los parámetros de configuración para ese cliente.
|}

== Adquisición de la dirección del servidor DHCP ==

Para poder configurarse, un dispositivo debe encontrar un servidor DHCP, para lo cual emite un mensaje de Solicitud DHCP. Arma este mensaje mediante el llenado del campo de identificación de la transacción y agregando la opción DUID. El mensaje se envía en modo multicast (dirección <tt>FF02::01:02</tt>) a todos los agentes DHCP en el enlace. El grupo de agentes incluye tanto a los servidores como a los relevos DHCP en un dominio administrativo. Este mensaje no puede ser enrutado pues el cliente utiliza su dirección [[Direccionamiento-Fundamentos#Direccionamiento local: Direcciones locales al enlace|de enlace local.]] Si el servidor no está en el mismo enlace que el cliente, debe haber un relevo en el enlace; por ello es que se utiliza una dirección multicast de cobertura local al enlace.

{{ eSuivi| Protocolo de Descubrimiento de vecinos |Protocolo de descubrimiento de vecinos |Implementación de la autoconfiguración|Implementación de la autoconfiguración}}

Protocolo DHCPv6

2012-07-18T22:28:10Z

Jincera: /* Adquisición de la dirección del servidor DHCP */

{{ eSuivi| Protocolo de Descubrimiento de vecinos |Protocolo de descubrimiento de vecinos |Implementación de la autoconfiguración|Implementación de la autoconfiguración}}

__TOC__

==Principios ==

La autoconfiguración o (configuración automática) con y sin estado, busca reducir el esfuerzo de instalación de dispositivos IPv6. La diferencia entre ambas es que la primera ofrece más información de configuración y permite un mayor control sobre la asignación de parámetros de configuración.

Un parámetro de configuración representa información útil para que un dispositivo pueda configurar su interfaz de red con el fin de establecer comunicaciones sobre su enlace o en Internet. El conjunto de parámetros de configuración incluye la siguiente información:

* de direccionamiento, de enrutamiento,
* del servidor de nombres (DNS),
* del servicio de información de red (NIS)
* etcétera.

Cabe resaltar que la información de enrutamiento no está contemplada en los mecanismos de autoconfiguración de IPv6 con o sin estado, sino por el procedimiento de descubrimiento de enrutadores de ICMPv6. Las dos técnicas de autoconfiguración no son mutuamente exclusivas, pueden coexistir en un mismo entorno. Por ejemplo, una máquina puede obtener su dirección unicast global mediante la autoconfiguración sin estado, y recuperar la información sobre el servicio de nombres (DNS) vía la configuración automática con estado.

El mecanismo de configuración automática con estado sigue un modelo de cliente-servidor y se basa en el uso de DHCPv6 (''Dynamic Host ConfigurationProtocol'' para IPv6) como ocurre con DHCP para IPv4, aunque hay grandes diferencias en el código: DHCP en IPv4 no es más que una extensión del protocolo BOOTP, por lo que tiene una funcionalidad limitada. En cambio, el protocolo DHCPv6 permite establecer los parámetros de configuración de un servidor DHCP para un cliente IPv6.

El cliente IPv6 representa un dispositivo que busca tener conectividad global IPv6 y solicita la información de configuración necesaria para poder establecer esta conectividad. El servidor DHCP constituye un punto central que reagrupa los parámetros de configuración. No necesariamente se ubica en el mismo enlace que el cliente, en cuyo caso, la información DHCP puede inercambiarse a través de un relevo. El servidor puede contener información de configuración para dispositivos ubicados en distintos enlaces. El cliente DHCP debe establecer una conexión directa ya sea con el relevo o con el propio servidor DHCP.

El relevo funciona como un "proxy" DHCP que se limita a retransmitir los mensajes DHCP; es transparente a la información intercambiada y no modifica en absoluto los mensajes DHCP intercambiados entre el servidor y el cliente. El proxy encapsula los mensajes DHCP del cliente en un formato específico (''cf'' figura Estructura de los mensajes de relevo) y realiza la operación inversa, es decir, desencapsula los mensajes provenientes del servidor para su entrega al cliente. El servidor forma el mensaje que debe ser recibido por el cliente, y, si no tiene comunicación directa con él, lo encapsula en un mensaje DHCP dirigido al proxy.

Para conocer el estado de los recursos administrados (representados por los parámetros de configuración), el servidor DHCP mantiene una lista de asociaciones entre los parámetros asignados y el cliente. El cliente no puede ser identificado con su dirección unicast ya que ésta es parte de los parámetros otorgados por el servidor DHCP. Por ello, el servidor utiliza un identificador particular: el DUID (''DHCP Unique IDentifier''). El DUID es creado por el cliente y lo identifica a él (al nodo), no a una interfaz. Se han propuesto varios esquemas para generarlo, por ejemplo, a partir de la dirección de enlace local, completada con un elemento que garantice la exclusividad, como un sello de tiempo (''timestamp''). Una vez que el cliente genera un DUID, éste debe ser invariable, incluso si llegara a cambiar su dirección de enlace local.

En realidad, sí es posible utilizar la dirección de enlace local del cliente como identificador, pero no se garantiza que éste sea único en todo el dominio; únicamente se puede asegurar su unicidad a nivel del enlace. Sin embargo, ésta tiene las siguientes ventajas:

* Queda determinada por el cliente durante la primera fase de la configuración automática (''cf'' Configuración automática y el control),
* es permanente para el cliente (no habrá renumeración ni cambio de dirección mientras la tarjeta de red no se cambie).

La asignación de direcciones a cliente es administrada por el servidor bajo la noción de un contenedor llamado IA (''Identity Association''). Una IA se define como una lista (posiblemente vacía) de direcciones IPv6. La idea es que cada cliente tendrá una IA por interfaz; esta IA estará asignada de forma permanente a la interfaz. Por este conducto, la gestión del tiempo de vida de las direcciones o la renumeración del cliente es realizada por el servidor, lo que simplifica el formato de los mensajes y el control de las direcciones.

Conforme al modelo cliente-servidor, los intercambios de información están formados por solicitudes y respuestas. Una transacción suele comenzar a iniciativa del cliente mediante una solicitud DHCP. La confiabilidad del mecanismo queda en manos del cliente, quien reenviará la solicitud DHCP hasta recibir una respuesta, o tener la certeza de que el servidor DHCP no está disponible. DHCPv6 es un protocolo de aplicación que utiliza UDP como protocolo de transporte. El cliente envía sus solicitudes al puerto 547 y recibirá las respuestas en el puerto 546. Típicamente, los mensajes UDP se encapsulan en paquetes IPv6. Además de las comunicaciones punto a punto, DHCPv6 también se sirve de comunicaciones multicast para el descubrimiento de servidores en un sitio.

==Formato de mensajes DHCPv6 ==

El protocolo DHCPv6 se describe en el RFC 3315. Al igual que numerosos protocolos de Internet, el protocolo de intercambio de información está desacoplado de la información en sí misma. La información intercambiada puede cambiar y evolucionar rápidamente sin afectar los mecanismos de este intercambio. Esta separación ofrece al protocolo una estabilidad y cierta capacidad para ser extendido. Esta separación entre el protocolo y la información puede observarse en la estructura misma de las unidades protocolarias. Una unidad del protocolo DHCP sigue el patrón clásico de las estructuras protocolarias: una cabecera que contiene la información propia al protocolo, seguida de una carga útil que alberga la información aplicativa.

En la terminología de DHCP, se le llama mensaje a una unidad del protocolo DHCPv6. Cada mensaje DHCP tiene un formato de encabezado idéntico. Desde este punto de vista, DHCP sigue los principios que condujeron al diseño del segmento TCP: un formato único para todo el conjunto de funciones de TCP. Estos principios privilegian la simplificación en el proceso de desarrollo del protocolo.

La figura Estructura de los mensajes DHCPv6 muestra la estructura de un mensaje DHCPv6. La cabecera se divide en tres partes:

[[Image: CS57.gif]]

* La información de comando codificada en una palabra de 32 bits, designa la función DHCP relacionada con el intercambio. Esta parte contiene el tipo de mensaje y un identificador del intercambio. El primer campo (de 8 bits) muestra el tipo de mensaje y define la función del mensaje en el protocolo. Como su nombre lo indica, el campo ''transaction-ID'' tiene por objeto identificar el intercambio desde el punto de vista del cliente. Le permite asociar las respuestas recibidas a las solicitudes que ha formulado.
* La información de direccionamiento se utiliza para especificar la dirección IPv6 del servidor DHCP. Indica la dirección de la interfaz utilizada por el servidor en la transacción.
* El campo de opciones se utiliza para transmitir las informaciones de configuración. Es un campo de longitud variable cuya codificación sigue el clásico esquema "TLV", es decir, el Tipo de la opción, la Longitud en octetos del elemento que le sigue, que es el Valor del parámetro. El tipo se codifica en dos octetos. El campo de longitud también ocupa dos octetos aún si valor del parámetro es nulo o si éste tiene una longitud fija.

Los mensajes utilizados para la comunicación entre el servidor y el proxy de relevo, son diferentes. Un mensaje de relevo encapsula como una opción, la información del mensaje DHCP del servidor al cliente. El mensaje de relevo tiene un prefijo de enlace que que indica la interfaz del relevo a través de la cual se recibió el mensaje DHCP, o por la que debe ser enviado. La dirección de enlace local del cliente contiene la dirección de la interfaz a configurar en el cliente.

El protocolo DHCPv6 incluye 12 mensajes DHCP distintos:

* Solicitud DHCP (''DHCP Solicit''): <br> Mensaje de solicitud de presencia de servidores DHCP. Se transmite hacia un servidor o un proxy DHCP. Un cliente envía este mensaje para localizar los servidores DHCP.

* Anuncio DHCP (''DHCP Advertise''): <br> Mensaje de presencia de servidores DHCP. Se emite en respuesta a un mensaje de solicitud DHCP para comunicar la dirección IP de un servidor DHCP. El destinatario es el cliente si se encuentra en el mismo enlace que el servidor; de lo contrario, se envía al proxy del cliente.

* Consulta DHCP (''DHCP Request''): <br> Mensaje de solicitud de parámetros de configuración por un cliente sin dirección.
* Confirmación DHCP (''DHCP Confirm''): <br> Mensaje de solicitud de confirmación sobre la validez de los parámetros asignados al cliente.
* Renovación DHCP (''DHCP Renew''): <br> Mensaje de solicitud para prolongar el uso de la dirección IP asignada.
* Reasignación DHCP (''DHCP Rebind''): <br> Igual al mensaje anterior, pero puede ser otro servidor DHCP el que responde, y no necesariamente el que asignó la dirección IP.
* Respuesta DHCP (''DHCP Reply''): <br> Mensaje enviado por el servidor en respuesta a una petición del cliente. Contiene los valores de los parámetros de configuración solicitados.
* Liberación DHCP (''DHCP Release''): <br> Mensaje emitido por el cliente para notificar la liberación de las direcciones IP previamente asignadas por el servidor.
* Denegación DHCP (''DHCP Decline): <br> Mensaje de un cliente indicando que una o varias de las direcciones asignadas ya están siendo utilizadas en su enlace.
* Notificación de reconfiguración DHCP (''DHCP reconfigure-init''): <br> Mensaje enviado por el servidor para notificar al cliente que existen nuevos valores para los parámetros de configuración. El cliente debe iniciar una nueva transacción para adquirir esta información.
* Encapsulación de relevo (''Relay-Forward''): <br> Mensaje del proxy para transportar los mensajes del cliente hacia el servidor. El mensaje del cliente se encapsula en este mensaje.
* Encapsulación del servidor (''Relay-Reply''): <br> Mensaje generado por el servidor hacia el proxy con información destinada al cliente. El proxy extrae el mensaje para el cliente y lo transmitirá sobre el enlace correspondiente.

El intercambio de información entre el cliente y el servidor DHCP se realiza por medio de opciones. La información se divide en tres categorías (''cf'' Tabla Opciones DHCPv6).
* Información temporal. Se refiere a recursos de red solicitados por el cliente y asignados por el servidor por un período determinado. Actualmente, el único tipo de recurso temporal es la dirección IP, cuya gestión se realiza bajo el concepto de IA.
* Información de carácter general. Se refiere al conjunto de parámetros normalmente presentados para la configuración de una máquina IPv6.
* Información específica a DHCP.

{|
|+'''Opciones DHCPv6'''
! Designación || Definición
|-style="background:silver"
|Asociación de identificación (IA) || Lista de direcciones IPv6 de una interfaz de cliente.
|-
|Consultas de opciones (ORO) || Lista de información de configuración solicitada por el cliente.
|-style="background:silver"
|Servidor de Nombres de Dominio || Lista de servidores DNS autorizados por el cliente.
|-
|Dominio de búsqueda || Lista de nombres de dominio que un cliente puede utilizar en la búscada de nombres de DNS.
|-style="background:silver"
|Mensaje cliente || Para la encapsulación del mensaje DHCP del cliente para el proxy
|-
|Mensaje servidor || Para la encapsulación del mensaje DHCP del servidor para el proxy
|-style="background:silver"
|Dirección IPv4 DSTM || Informa al cliente que la dirección asignada es una dirección IPv4 mapeada a IPv6
|-
|Autenticación || Para autenticar al emisor del mensaje DHCP y validar su integridad.
|-style="background:silver"
|Unicast servidor || Para notificar al cliente la dirección unicast del servidor y así establecer la comunicación sin ayuda del proxy. En este caso, el cliente debe tener una dirección unicast válida.
|-
|Identificador DHCP (DUID) || identificador permanente del cliente.
|-style="background:silver"
|Preferencia || Mecanismo ofrecido al cliente para elegir el servidor DHCP. El servidor seleccionado será responsable de proporcionar los parámetros de configuración para ese cliente.
|}

== Adquisición de la dirección del servidor DHCP ==

Para poder configurarse, un dispositivo debe encontrar un servidor DHCP, para lo cual emite un mensaje de Solicitud DHCP. Arma este mensaje mediante el llenado del campo de identificación de la transacción y agregando la opción DUID. El mensaje se envía en modo multicast (dirección <tt>FF02 :: 01:02</tt>) a todos los agentes DHCP en el enlace. El grupo de agentes incluye tanto a los servidores como a los relevos DHCP en un dominio administrativo. Este mensaje no puede ser enrutado pues el cliente utiliza su dirección [[Direccionamiento-Fundamentos#Direccionamiento local: Direcciones locales al enlace|de enlace local.]] Si el servidor no está en el mismo enlace que el cliente, debe haber un relevo en el enlace; por ello es que se utiliza una dirección multicast de cobertura local al enlace.

{{ eSuivi| Protocolo de Descubrimiento de vecinos |Protocolo de descubrimiento de vecinos |Implementación de la autoconfiguración|Implementación de la autoconfiguración}}

Protocolo DHCPv6

2012-07-18T22:24:09Z

Jincera:

{{ eSuivi| Protocolo de Descubrimiento de vecinos |Protocolo de descubrimiento de vecinos |Implementación de la autoconfiguración|Implementación de la autoconfiguración}}

__TOC__

==Principios ==

La autoconfiguración o (configuración automática) con y sin estado, busca reducir el esfuerzo de instalación de dispositivos IPv6. La diferencia entre ambas es que la primera ofrece más información de configuración y permite un mayor control sobre la asignación de parámetros de configuración.

Un parámetro de configuración representa información útil para que un dispositivo pueda configurar su interfaz de red con el fin de establecer comunicaciones sobre su enlace o en Internet. El conjunto de parámetros de configuración incluye la siguiente información:

* de direccionamiento, de enrutamiento,
* del servidor de nombres (DNS),
* del servicio de información de red (NIS)
* etcétera.

Cabe resaltar que la información de enrutamiento no está contemplada en los mecanismos de autoconfiguración de IPv6 con o sin estado, sino por el procedimiento de descubrimiento de enrutadores de ICMPv6. Las dos técnicas de autoconfiguración no son mutuamente exclusivas, pueden coexistir en un mismo entorno. Por ejemplo, una máquina puede obtener su dirección unicast global mediante la autoconfiguración sin estado, y recuperar la información sobre el servicio de nombres (DNS) vía la configuración automática con estado.

El mecanismo de configuración automática con estado sigue un modelo de cliente-servidor y se basa en el uso de DHCPv6 (''Dynamic Host ConfigurationProtocol'' para IPv6) como ocurre con DHCP para IPv4, aunque hay grandes diferencias en el código: DHCP en IPv4 no es más que una extensión del protocolo BOOTP, por lo que tiene una funcionalidad limitada. En cambio, el protocolo DHCPv6 permite establecer los parámetros de configuración de un servidor DHCP para un cliente IPv6.

El cliente IPv6 representa un dispositivo que busca tener conectividad global IPv6 y solicita la información de configuración necesaria para poder establecer esta conectividad. El servidor DHCP constituye un punto central que reagrupa los parámetros de configuración. No necesariamente se ubica en el mismo enlace que el cliente, en cuyo caso, la información DHCP puede inercambiarse a través de un relevo. El servidor puede contener información de configuración para dispositivos ubicados en distintos enlaces. El cliente DHCP debe establecer una conexión directa ya sea con el relevo o con el propio servidor DHCP.

El relevo funciona como un "proxy" DHCP que se limita a retransmitir los mensajes DHCP; es transparente a la información intercambiada y no modifica en absoluto los mensajes DHCP intercambiados entre el servidor y el cliente. El proxy encapsula los mensajes DHCP del cliente en un formato específico (''cf'' figura Estructura de los mensajes de relevo) y realiza la operación inversa, es decir, desencapsula los mensajes provenientes del servidor para su entrega al cliente. El servidor forma el mensaje que debe ser recibido por el cliente, y, si no tiene comunicación directa con él, lo encapsula en un mensaje DHCP dirigido al proxy.

Para conocer el estado de los recursos administrados (representados por los parámetros de configuración), el servidor DHCP mantiene una lista de asociaciones entre los parámetros asignados y el cliente. El cliente no puede ser identificado con su dirección unicast ya que ésta es parte de los parámetros otorgados por el servidor DHCP. Por ello, el servidor utiliza un identificador particular: el DUID (''DHCP Unique IDentifier''). El DUID es creado por el cliente y lo identifica a él (al nodo), no a una interfaz. Se han propuesto varios esquemas para generarlo, por ejemplo, a partir de la dirección de enlace local, completada con un elemento que garantice la exclusividad, como un sello de tiempo (''timestamp''). Una vez que el cliente genera un DUID, éste debe ser invariable, incluso si llegara a cambiar su dirección de enlace local.

En realidad, sí es posible utilizar la dirección de enlace local del cliente como identificador, pero no se garantiza que éste sea único en todo el dominio; únicamente se puede asegurar su unicidad a nivel del enlace. Sin embargo, ésta tiene las siguientes ventajas:

* Queda determinada por el cliente durante la primera fase de la configuración automática (''cf'' Configuración automática y el control),
* es permanente para el cliente (no habrá renumeración ni cambio de dirección mientras la tarjeta de red no se cambie).

La asignación de direcciones a cliente es administrada por el servidor bajo la noción de un contenedor llamado IA (''Identity Association''). Una IA se define como una lista (posiblemente vacía) de direcciones IPv6. La idea es que cada cliente tendrá una IA por interfaz; esta IA estará asignada de forma permanente a la interfaz. Por este conducto, la gestión del tiempo de vida de las direcciones o la renumeración del cliente es realizada por el servidor, lo que simplifica el formato de los mensajes y el control de las direcciones.

Conforme al modelo cliente-servidor, los intercambios de información están formados por solicitudes y respuestas. Una transacción suele comenzar a iniciativa del cliente mediante una solicitud DHCP. La confiabilidad del mecanismo queda en manos del cliente, quien reenviará la solicitud DHCP hasta recibir una respuesta, o tener la certeza de que el servidor DHCP no está disponible. DHCPv6 es un protocolo de aplicación que utiliza UDP como protocolo de transporte. El cliente envía sus solicitudes al puerto 547 y recibirá las respuestas en el puerto 546. Típicamente, los mensajes UDP se encapsulan en paquetes IPv6. Además de las comunicaciones punto a punto, DHCPv6 también se sirve de comunicaciones multicast para el descubrimiento de servidores en un sitio.

==Formato de mensajes DHCPv6 ==

El protocolo DHCPv6 se describe en el RFC 3315. Al igual que numerosos protocolos de Internet, el protocolo de intercambio de información está desacoplado de la información en sí misma. La información intercambiada puede cambiar y evolucionar rápidamente sin afectar los mecanismos de este intercambio. Esta separación ofrece al protocolo una estabilidad y cierta capacidad para ser extendido. Esta separación entre el protocolo y la información puede observarse en la estructura misma de las unidades protocolarias. Una unidad del protocolo DHCP sigue el patrón clásico de las estructuras protocolarias: una cabecera que contiene la información propia al protocolo, seguida de una carga útil que alberga la información aplicativa.

En la terminología de DHCP, se le llama mensaje a una unidad del protocolo DHCPv6. Cada mensaje DHCP tiene un formato de encabezado idéntico. Desde este punto de vista, DHCP sigue los principios que condujeron al diseño del segmento TCP: un formato único para todo el conjunto de funciones de TCP. Estos principios privilegian la simplificación en el proceso de desarrollo del protocolo.

La figura Estructura de los mensajes DHCPv6 muestra la estructura de un mensaje DHCPv6. La cabecera se divide en tres partes:

[[Image: CS57.gif]]

* La información de comando codificada en una palabra de 32 bits, designa la función DHCP relacionada con el intercambio. Esta parte contiene el tipo de mensaje y un identificador del intercambio. El primer campo (de 8 bits) muestra el tipo de mensaje y define la función del mensaje en el protocolo. Como su nombre lo indica, el campo ''transaction-ID'' tiene por objeto identificar el intercambio desde el punto de vista del cliente. Le permite asociar las respuestas recibidas a las solicitudes que ha formulado.
* La información de direccionamiento se utiliza para especificar la dirección IPv6 del servidor DHCP. Indica la dirección de la interfaz utilizada por el servidor en la transacción.
* El campo de opciones se utiliza para transmitir las informaciones de configuración. Es un campo de longitud variable cuya codificación sigue el clásico esquema "TLV", es decir, el Tipo de la opción, la Longitud en octetos del elemento que le sigue, que es el Valor del parámetro. El tipo se codifica en dos octetos. El campo de longitud también ocupa dos octetos aún si valor del parámetro es nulo o si éste tiene una longitud fija.

Los mensajes utilizados para la comunicación entre el servidor y el proxy de relevo, son diferentes. Un mensaje de relevo encapsula como una opción, la información del mensaje DHCP del servidor al cliente. El mensaje de relevo tiene un prefijo de enlace que que indica la interfaz del relevo a través de la cual se recibió el mensaje DHCP, o por la que debe ser enviado. La dirección de enlace local del cliente contiene la dirección de la interfaz a configurar en el cliente.

El protocolo DHCPv6 incluye 12 mensajes DHCP distintos:

* Solicitud DHCP (''DHCP Solicit''): <br> Mensaje de solicitud de presencia de servidores DHCP. Se transmite hacia un servidor o un proxy DHCP. Un cliente envía este mensaje para localizar los servidores DHCP.

* Anuncio DHCP (''DHCP Advertise''): <br> Mensaje de presencia de servidores DHCP. Se emite en respuesta a un mensaje de solicitud DHCP para comunicar la dirección IP de un servidor DHCP. El destinatario es el cliente si se encuentra en el mismo enlace que el servidor; de lo contrario, se envía al proxy del cliente.

* Consulta DHCP (''DHCP Request''): <br> Mensaje de solicitud de parámetros de configuración por un cliente sin dirección.
* Confirmación DHCP (''DHCP Confirm''): <br> Mensaje de solicitud de confirmación sobre la validez de los parámetros asignados al cliente.
* Renovación DHCP (''DHCP Renew''): <br> Mensaje de solicitud para prolongar el uso de la dirección IP asignada.
* Reasignación DHCP (''DHCP Rebind''): <br> Igual al mensaje anterior, pero puede ser otro servidor DHCP el que responde, y no necesariamente el que asignó la dirección IP.
* Respuesta DHCP (''DHCP Reply''): <br> Mensaje enviado por el servidor en respuesta a una petición del cliente. Contiene los valores de los parámetros de configuración solicitados.
* Liberación DHCP (''DHCP Release''): <br> Mensaje emitido por el cliente para notificar la liberación de las direcciones IP previamente asignadas por el servidor.
* Denegación DHCP (''DHCP Decline): <br> Mensaje de un cliente indicando que una o varias de las direcciones asignadas ya están siendo utilizadas en su enlace.
* Notificación de reconfiguración DHCP (''DHCP reconfigure-init''): <br> Mensaje enviado por el servidor para notificar al cliente que existen nuevos valores para los parámetros de configuración. El cliente debe iniciar una nueva transacción para adquirir esta información.
* Encapsulación de relevo (''Relay-Forward''): <br> Mensaje del proxy para transportar los mensajes del cliente hacia el servidor. El mensaje del cliente se encapsula en este mensaje.
* Encapsulación del servidor (''Relay-Reply''): <br> Mensaje generado por el servidor hacia el proxy con información destinada al cliente. El proxy extrae el mensaje para el cliente y lo transmitirá sobre el enlace correspondiente.

El intercambio de información entre el cliente y el servidor DHCP se realiza por medio de opciones. La información se divide en tres categorías (''cf'' Tabla Opciones DHCPv6).
* Información temporal. Se refiere a recursos de red solicitados por el cliente y asignados por el servidor por un período determinado. Actualmente, el único tipo de recurso temporal es la dirección IP, cuya gestión se realiza bajo el concepto de IA.
* Información de carácter general. Se refiere al conjunto de parámetros normalmente presentados para la configuración de una máquina IPv6.
* Información específica a DHCP.

{|
|+'''Opciones DHCPv6'''
! Designación || Definición
|-style="background:silver"
|Asociación de identificación (IA) || Lista de direcciones IPv6 de una interfaz de cliente.
|-
|Consultas de opciones (ORO) || Lista de información de configuración solicitada por el cliente.
|-style="background:silver"
|Servidor de Nombres de Dominio || Lista de servidores DNS autorizados por el cliente.
|-
|Dominio de búsqueda || Lista de nombres de dominio que un cliente puede utilizar en la búscada de nombres de DNS.
|-style="background:silver"
|Mensaje cliente || Para la encapsulación del mensaje DHCP del cliente para el proxy
|-
|Mensaje servidor || Para la encapsulación del mensaje DHCP del servidor para el proxy
|-style="background:silver"
|Dirección IPv4 DSTM || Informa al cliente que la dirección asignada es una dirección IPv4 mapeada a IPv6
|-
|Autenticación || Para autenticar al emisor del mensaje DHCP y validar su integridad.
|-style="background:silver"
|Unicast servidor || Para notificar al cliente la dirección unicast del servidor y así establecer la comunicación sin ayuda del proxy. En este caso, el cliente debe tener una dirección unicast válida.
|-
|Identificador DHCP (DUID) || identificador permanente del cliente.
|-style="background:silver"
|Preferencia || Mecanismo ofrecido al cliente para elegir el servidor DHCP. El servidor seleccionado será responsable de proporcionar los parámetros de configuración para ese cliente.
|}

== Adquisición de la dirección del servidor DHCP ==

Para poder configurarse, un dispositivo debe encontrar un servidor DHCP, para lo cual emite un mensaje de Solicitud DHCP. Arma este mensaje mediante el llenado del campo de identificación de la transacción y agregando la opción DUID. El mensaje se envía en modo multicast (dirección <tt>FF02 :: 01:02</tt>) a todos los agentes DHCP en el enlace. El grupo de agentes incluye tanto a los servidores como a los relevos DHCP en un dominio administrativo. Este mensaje no puede ser enrutado pues el cliente utiliza su dirección [[Direcciones locales al enlace|de enlace local.]] Si el servidor no está en el mismo enlace que el cliente, debe haber un relevo en el enlace; por ello es que se utiliza una dirección multicast de cobertura local al enlace.

{{ eSuivi| Protocolo de Descubrimiento de vecinos |Protocolo de descubrimiento de vecinos |Implementación de la autoconfiguración|Implementación de la autoconfiguración}}

Protocolo DHCPv6

2012-07-17T00:51:04Z

Jincera: /* Formato de mensajes DHCPv6 */

{{ eSuivi| Protocolo de Descubrimiento de vecinos |Protocolo de descubrimiento de vecinos |Implementación de la autoconfiguración|Implementación de la autoconfiguración}}

__TOC__

==Principios ==

La autoconfiguración o (configuración automática) con y sin estado, busca reducir el esfuerzo de instalación de dispositivos IPv6. La diferencia entre ambas es que la primera ofrece más información de configuración y permite un mayor control sobre la asignación de parámetros de configuración.

Un parámetro de configuración representa información útil para que un dispositivo pueda configurar su interfaz de red con el fin de establecer comunicaciones sobre su enlace o en Internet. El conjunto de parámetros de configuración incluye la siguiente información:

* de direccionamiento, de enrutamiento,
* del servidor de nombres (DNS),
* del servicio de información de red (NIS)
* etcétera.

Cabe resaltar que la información de enrutamiento no está contemplada en los mecanismos de autoconfiguración de IPv6 con o sin estado, sino por el procedimiento de descubrimiento de enrutadores de ICMPv6. Las dos técnicas de autoconfiguración no son mutuamente exclusivas, pueden coexistir en un mismo entorno. Por ejemplo, una máquina puede obtener su dirección unicast global mediante la autoconfiguración sin estado, y recuperar la información sobre el servicio de nombres (DNS) vía la configuración automática con estado.

El mecanismo de configuración automática con estado sigue un modelo de cliente-servidor y se basa en el uso de DHCPv6 (''Dynamic Host ConfigurationProtocol'' para IPv6) como ocurre con DHCP para IPv4, aunque hay grandes diferencias en el código: DHCP en IPv4 no es más que una extensión del protocolo BOOTP, por lo que tiene una funcionalidad limitada. En cambio, el protocolo DHCPv6 permite establecer los parámetros de configuración de un servidor DHCP para un cliente IPv6.

El cliente IPv6 representa un dispositivo que busca tener conectividad global IPv6 y solicita la información de configuración necesaria para poder establecer esta conectividad. El servidor DHCP constituye un punto central que reagrupa los parámetros de configuración. No necesariamente se ubica en el mismo enlace que el cliente, en cuyo caso, la información DHCP puede inercambiarse a través de un relevo. El servidor puede contener información de configuración para dispositivos ubicados en distintos enlaces. El cliente DHCP debe establecer una conexión directa ya sea con el relevo o con el propio servidor DHCP.

El relevo funciona como un "proxy" DHCP que se limita a retransmitir los mensajes DHCP; es transparente a la información intercambiada y no modifica en absoluto los mensajes DHCP intercambiados entre el servidor y el cliente. El proxy encapsula los mensajes DHCP del cliente en un formato específico (''cf'' figura Estructura de los mensajes de relevo) y realiza la operación inversa, es decir, desencapsula los mensajes provenientes del servidor para su entrega al cliente. El servidor forma el mensaje que debe ser recibido por el cliente, y, si no tiene comunicación directa con él, lo encapsula en un mensaje DHCP dirigido al proxy.

Para conocer el estado de los recursos administrados (representados por los parámetros de configuración), el servidor DHCP mantiene una lista de asociaciones entre los parámetros asignados y el cliente. El cliente no puede ser identificado con su dirección unicast ya que ésta es parte de los parámetros otorgados por el servidor DHCP. Por ello, el servidor utiliza un identificador particular: el DUID (''DHCP Unique IDentifier''). El DUID es creado por el cliente y lo identifica a él (al nodo), no a una interfaz. Se han propuesto varios esquemas para generarlo, por ejemplo, a partir de la dirección de enlace local, completada con un elemento que garantice la exclusividad, como un sello de tiempo (''timestamp''). Una vez que el cliente genera un DUID, éste debe ser invariable, incluso si llegara a cambiar su dirección de enlace local.

En realidad, sí es posible utilizar la dirección de enlace local del cliente como identificador, pero no se garantiza que éste sea único en todo el dominio; únicamente se puede asegurar su unicidad a nivel del enlace. Sin embargo, ésta tiene las siguientes ventajas:

* Queda determinada por el cliente durante la primera fase de la configuración automática (''cf'' Configuración automática y el control),
* es permanente para el cliente (no habrá renumeración ni cambio de dirección mientras la tarjeta de red no se cambie).

La asignación de direcciones a cliente es administrada por el servidor bajo la noción de un contenedor llamado IA (''Identity Association''). Una IA se define como una lista (posiblemente vacía) de direcciones IPv6. La idea es que cada cliente tendrá una IA por interfaz; esta IA estará asignada de forma permanente a la interfaz. Por este conducto, la gestión del tiempo de vida de las direcciones o la renumeración del cliente es realizada por el servidor, lo que simplifica el formato de los mensajes y el control de las direcciones.

Conforme al modelo cliente-servidor, los intercambios de información están formados por solicitudes y respuestas. Una transacción suele comenzar a iniciativa del cliente mediante una solicitud DHCP. La confiabilidad del mecanismo queda en manos del cliente, quien reenviará la solicitud DHCP hasta recibir una respuesta, o tener la certeza de que el servidor DHCP no está disponible. DHCPv6 es un protocolo de aplicación que utiliza UDP como protocolo de transporte. El cliente envía sus solicitudes al puerto 547 y recibirá las respuestas en el puerto 546. Típicamente, los mensajes UDP se encapsulan en paquetes IPv6. Además de las comunicaciones punto a punto, DHCPv6 también se sirve de comunicaciones multicast para el descubrimiento de servidores en un sitio.

==Formato de mensajes DHCPv6 ==

El protocolo DHCPv6 se describe en el RFC 3315. Al igual que numerosos protocolos de Internet, el protocolo de intercambio de información está desacoplado de la información en sí misma. La información intercambiada puede cambiar y evolucionar rápidamente sin afectar los mecanismos de este intercambio. Esta separación ofrece al protocolo una estabilidad y cierta capacidad para ser extendido. Esta separación entre el protocolo y la información puede observarse en la estructura misma de las unidades protocolarias. Una unidad del protocolo DHCP sigue el patrón clásico de las estructuras protocolarias: una cabecera que contiene la información propia al protocolo, seguida de una carga útil que alberga la información aplicativa.

En la terminología de DHCP, se le llama mensaje a una unidad del protocolo DHCPv6. Cada mensaje DHCP tiene un formato de encabezado idéntico. Desde este punto de vista, DHCP sigue los principios que condujeron al diseño del segmento TCP: un formato único para todo el conjunto de funciones de TCP. Estos principios privilegian la simplificación en el proceso de desarrollo del protocolo.

La figura Estructura de los mensajes DHCPv6 muestra la estructura de un mensaje DHCPv6. La cabecera se divide en tres partes:

[[Image: CS57.gif]]

* La información de comando codificada en una palabra de 32 bits, designa la función DHCP relacionada con el intercambio. Esta parte contiene el tipo de mensaje y un identificador del intercambio. El primer campo (de 8 bits) muestra el tipo de mensaje y define la función del mensaje en el protocolo. Como su nombre lo indica, el campo ''transaction-ID'' tiene por objeto identificar el intercambio desde el punto de vista del cliente. Le permite asociar las respuestas recibidas a las solicitudes que ha formulado.
* La información de direccionamiento se utiliza para especificar la dirección IPv6 del servidor DHCP. Indica la dirección de la interfaz utilizada por el servidor en la transacción.
* El campo de opciones se utiliza para transmitir las informaciones de configuración. Es un campo de longitud variable cuya codificación sigue el clásico esquema "TLV", es decir, el Tipo de la opción, la Longitud en octetos del elemento que le sigue, que es el Valor del parámetro. El tipo se codifica en dos octetos. El campo de longitud también ocupa dos octetos aún si valor del parámetro es nulo o si éste tiene una longitud fija.

Los mensajes utilizados para la comunicación entre el servidor y el proxy de relevo, son diferentes. Un mensaje de relevo encapsula como una opción, la información del mensaje DHCP del servidor al cliente. El mensaje de relevo tiene un prefijo de enlace que que indica la interfaz del relevo a través de la cual se recibió el mensaje DHCP, o por la que debe ser enviado. La dirección de enlace local del cliente contiene la dirección de la interfaz a configurar en el cliente.

El protocolo DHCPv6 incluye 12 mensajes DHCP distintos:

* Solicitud DHCP (''DHCP Solicit''): <br> Mensaje de solicitud de presencia de servidores DHCP. Se transmite hacia un servidor o un proxy DHCP. Un cliente envía este mensaje para localizar los servidores DHCP.

* Anuncio DHCP (''DHCP Advertise''): <br> Mensaje de presencia de servidores DHCP. Se emite en respuesta a un mensaje de solicitud DHCP para comunicar la dirección IP de un servidor DHCP. El destinatario es el cliente si se encuentra en el mismo enlace que el servidor; de lo contrario, se envía al proxy del cliente.

* Consulta DHCP (''DHCP Request''): <br> Mensaje de solicitud de parámetros de configuración por un cliente sin dirección.
* Confirmación DHCP (''DHCP Confirm''): <br> Mensaje de solicitud de confirmación sobre la validez de los parámetros asignados al cliente.
* Renovación DHCP (''DHCP Renew''): <br> Mensaje de solicitud para prolongar el uso de la dirección IP asignada.
* Reasignación DHCP (''DHCP Rebind''): <br> Igual al mensaje anterior, pero puede ser otro servidor DHCP el que responde, y no necesariamente el que asignó la dirección IP.
* Respuesta DHCP (''DHCP Reply''): <br> Mensaje enviado por el servidor en respuesta a una petición del cliente. Contiene los valores de los parámetros de configuración solicitados.
* Liberación DHCP (''DHCP Release''): <br> Mensaje emitido por el cliente para notificar la liberación de las direcciones IP previamente asignadas por el servidor.
* Denegación DHCP (''DHCP Decline): <br> Mensaje de un cliente indicando que una o varias de las direcciones asignadas ya están siendo utilizadas en su enlace.
* Notificación de reconfiguración DHCP (''DHCP reconfigure-init''): <br> Mensaje enviado por el servidor para notificar al cliente que existen nuevos valores para los parámetros de configuración. El cliente debe iniciar una nueva transacción para adquirir esta información.
* Encapsulación de relevo (''Relay-Forward''): <br> Mensaje del proxy para transportar los mensajes del cliente hacia el servidor. El mensaje del cliente se encapsula en este mensaje.
* Encapsulación del servidor (''Relay-Reply''): <br> Mensaje generado por el servidor hacia el proxy con información destinada al cliente. El proxy extrae el mensaje para el cliente y lo transmitirá sobre el enlace correspondiente.

El intercambio de información entre el cliente y el servidor DHCP se realiza por medio de opciones. La información se divide en tres categorías (''cf'' Tabla Opciones DHCPv6).
* Información temporal. Se refiere a recursos de red solicitados por el cliente y asignados por el servidor por un período determinado. Actualmente, el único tipo de recurso temporal es la dirección IP, cuya gestión se realiza bajo el concepto de IA.
* Información de carácter general. Se refiere al conjunto de parámetros normalmente presentados para la configuración de una máquina IPv6.
* Información específica a DHCP.

{|
|+'''Opciones DHCPv6'''
! Designación || Definición
|-style="background:silver"
|Asociación de identificación (IA) || Lista de direcciones IPv6 de una interfaz de cliente.
|-
|Consultas de opciones (ORO) || Lista de información de configuración solicitada por el cliente.
|-style="background:silver"
|Servidor de Nombres de Dominio || Lista de servidores DNS autorizados por el cliente.
|-
|Dominio de búsqueda || Lista de nombres de dominio que un cliente puede utilizar en la búscada de nombres de DNS.
|-style="background:silver"
|Mensaje cliente || Para la encapsulación del mensaje DHCP del cliente para el proxy
|-
|Mensaje servidor || Para la encapsulación del mensaje DHCP del servidor para el proxy
|-style="background:silver"
|Dirección IPv4 DSTM || Informa al cliente que la dirección asignada es una dirección IPv4 mapeada a IPv6
|-
|Autenticación || Para autenticar al emisor del mensaje DHCP y validar su integridad.
|-style="background:silver"
|Unicast servidor || Para notificar al cliente la dirección unicast del servidor y así establecer la comunicación sin ayuda del proxy. En este caso, el cliente debe tener una dirección unicast válida.
|-
|Identificador DHCP (DUID) || identificador permanente del cliente.
|-style="background:silver"
|Preferencia || Mecanismo ofrecido al cliente para elegir el servidor DHCP. El servidor seleccionado será responsable de proporcionar los parámetros de configuración para ese cliente.
|}

{{ eSuivi| Protocolo de Descubrimiento de vecinos |Protocolo de descubrimiento de vecinos |Implementación de la autoconfiguración|Implementación de la autoconfiguración}}

Protocolo DHCPv6

2012-07-17T00:49:56Z

Jincera: /* Formato de mensajes DHCPv6 */

{{ eSuivi| Protocolo de Descubrimiento de vecinos |Protocolo de descubrimiento de vecinos |Implementación de la autoconfiguración|Implementación de la autoconfiguración}}

__TOC__

==Principios ==

La autoconfiguración o (configuración automática) con y sin estado, busca reducir el esfuerzo de instalación de dispositivos IPv6. La diferencia entre ambas es que la primera ofrece más información de configuración y permite un mayor control sobre la asignación de parámetros de configuración.

Un parámetro de configuración representa información útil para que un dispositivo pueda configurar su interfaz de red con el fin de establecer comunicaciones sobre su enlace o en Internet. El conjunto de parámetros de configuración incluye la siguiente información:

* de direccionamiento, de enrutamiento,
* del servidor de nombres (DNS),
* del servicio de información de red (NIS)
* etcétera.

Cabe resaltar que la información de enrutamiento no está contemplada en los mecanismos de autoconfiguración de IPv6 con o sin estado, sino por el procedimiento de descubrimiento de enrutadores de ICMPv6. Las dos técnicas de autoconfiguración no son mutuamente exclusivas, pueden coexistir en un mismo entorno. Por ejemplo, una máquina puede obtener su dirección unicast global mediante la autoconfiguración sin estado, y recuperar la información sobre el servicio de nombres (DNS) vía la configuración automática con estado.

El mecanismo de configuración automática con estado sigue un modelo de cliente-servidor y se basa en el uso de DHCPv6 (''Dynamic Host ConfigurationProtocol'' para IPv6) como ocurre con DHCP para IPv4, aunque hay grandes diferencias en el código: DHCP en IPv4 no es más que una extensión del protocolo BOOTP, por lo que tiene una funcionalidad limitada. En cambio, el protocolo DHCPv6 permite establecer los parámetros de configuración de un servidor DHCP para un cliente IPv6.

El cliente IPv6 representa un dispositivo que busca tener conectividad global IPv6 y solicita la información de configuración necesaria para poder establecer esta conectividad. El servidor DHCP constituye un punto central que reagrupa los parámetros de configuración. No necesariamente se ubica en el mismo enlace que el cliente, en cuyo caso, la información DHCP puede inercambiarse a través de un relevo. El servidor puede contener información de configuración para dispositivos ubicados en distintos enlaces. El cliente DHCP debe establecer una conexión directa ya sea con el relevo o con el propio servidor DHCP.

El relevo funciona como un "proxy" DHCP que se limita a retransmitir los mensajes DHCP; es transparente a la información intercambiada y no modifica en absoluto los mensajes DHCP intercambiados entre el servidor y el cliente. El proxy encapsula los mensajes DHCP del cliente en un formato específico (''cf'' figura Estructura de los mensajes de relevo) y realiza la operación inversa, es decir, desencapsula los mensajes provenientes del servidor para su entrega al cliente. El servidor forma el mensaje que debe ser recibido por el cliente, y, si no tiene comunicación directa con él, lo encapsula en un mensaje DHCP dirigido al proxy.

Para conocer el estado de los recursos administrados (representados por los parámetros de configuración), el servidor DHCP mantiene una lista de asociaciones entre los parámetros asignados y el cliente. El cliente no puede ser identificado con su dirección unicast ya que ésta es parte de los parámetros otorgados por el servidor DHCP. Por ello, el servidor utiliza un identificador particular: el DUID (''DHCP Unique IDentifier''). El DUID es creado por el cliente y lo identifica a él (al nodo), no a una interfaz. Se han propuesto varios esquemas para generarlo, por ejemplo, a partir de la dirección de enlace local, completada con un elemento que garantice la exclusividad, como un sello de tiempo (''timestamp''). Una vez que el cliente genera un DUID, éste debe ser invariable, incluso si llegara a cambiar su dirección de enlace local.

En realidad, sí es posible utilizar la dirección de enlace local del cliente como identificador, pero no se garantiza que éste sea único en todo el dominio; únicamente se puede asegurar su unicidad a nivel del enlace. Sin embargo, ésta tiene las siguientes ventajas:

* Queda determinada por el cliente durante la primera fase de la configuración automática (''cf'' Configuración automática y el control),
* es permanente para el cliente (no habrá renumeración ni cambio de dirección mientras la tarjeta de red no se cambie).

La asignación de direcciones a cliente es administrada por el servidor bajo la noción de un contenedor llamado IA (''Identity Association''). Una IA se define como una lista (posiblemente vacía) de direcciones IPv6. La idea es que cada cliente tendrá una IA por interfaz; esta IA estará asignada de forma permanente a la interfaz. Por este conducto, la gestión del tiempo de vida de las direcciones o la renumeración del cliente es realizada por el servidor, lo que simplifica el formato de los mensajes y el control de las direcciones.

Conforme al modelo cliente-servidor, los intercambios de información están formados por solicitudes y respuestas. Una transacción suele comenzar a iniciativa del cliente mediante una solicitud DHCP. La confiabilidad del mecanismo queda en manos del cliente, quien reenviará la solicitud DHCP hasta recibir una respuesta, o tener la certeza de que el servidor DHCP no está disponible. DHCPv6 es un protocolo de aplicación que utiliza UDP como protocolo de transporte. El cliente envía sus solicitudes al puerto 547 y recibirá las respuestas en el puerto 546. Típicamente, los mensajes UDP se encapsulan en paquetes IPv6. Además de las comunicaciones punto a punto, DHCPv6 también se sirve de comunicaciones multicast para el descubrimiento de servidores en un sitio.

==Formato de mensajes DHCPv6 ==

El protocolo DHCPv6 se describe en el RFC 3315. Al igual que numerosos protocolos de Internet, el protocolo de intercambio de información está desacoplado de la información en sí misma. La información intercambiada puede cambiar y evolucionar rápidamente sin afectar los mecanismos de este intercambio. Esta separación ofrece al protocolo una estabilidad y cierta capacidad para ser extendido. Esta separación entre el protocolo y la información puede observarse en la estructura misma de las unidades protocolarias. Una unidad del protocolo DHCP sigue el patrón clásico de las estructuras protocolarias: una cabecera que contiene la información propia al protocolo, seguida de una carga útil que alberga la información aplicativa.

En la terminología de DHCP, se le llama mensaje a una unidad del protocolo DHCPv6. Cada mensaje DHCP tiene un formato de encabezado idéntico. Desde este punto de vista, DHCP sigue los principios que condujeron al diseño del segmento TCP: un formato único para todo el conjunto de funciones de TCP. Estos principios privilegian la simplificación en el proceso de desarrollo del protocolo.

La figura Estructura de los mensajes DHCPv6 muestra la estructura de un mensaje DHCPv6. La cabecera se divide en tres partes:

[[Image: CS57.gif]]

* La información de comando codificada en una palabra de 32 bits, designa la función DHCP relacionada con el intercambio. Esta parte contiene el tipo de mensaje y un identificador del intercambio. El primer campo (de 8 bits) muestra el tipo de mensaje y define la función del mensaje en el protocolo. Como su nombre lo indica, el campo ''transaction-ID'' tiene por objeto identificar el intercambio desde el punto de vista del cliente. Le permite asociar las respuestas recibidas a las solicitudes que ha formulado.
* La información de direccionamiento se utiliza para especificar la dirección IPv6 del servidor DHCP. Indica la dirección de la interfaz utilizada por el servidor en la transacción.
* El campo de opciones se utiliza para transmitir las informaciones de configuración. Es un campo de longitud variable cuya codificación sigue el clásico esquema "TLV", es decir, el Tipo de la opción, la Longitud en octetos del elemento que le sigue, que es el Valor del parámetro. El tipo se codifica en dos octetos. El campo de longitud también ocupa dos octetos aún si valor del parámetro es nulo o si éste tiene una longitud fija.

Los mensajes utilizados para la comunicación entre el servidor y el proxy de relevo, son diferentes. Un mensaje de relevo encapsula como una opción, la información del mensaje DHCP del servidor al cliente. El mensaje de relevo tiene un prefijo de enlace que que indica la interfaz del relevo a través de la cual se recibió el mensaje DHCP, o por la que debe ser enviado. La dirección de enlace local del cliente contiene la dirección de la interfaz a configurar en el cliente.

El protocolo DHCPv6 incluye 12 mensajes DHCP distintos:

* Solicitud DHCP (''DHCP Solicit''): <br> Mensaje de solicitud de presencia de servidores DHCP. Se transmite hacia un servidor o un proxy DHCP. Un cliente envía este mensaje para localizar los servidores DHCP.

* Anuncio DHCP (''DHCP Advertise''): <br> Mensaje de presencia de servidores DHCP. Se emite en respuesta a un mensaje de solicitud DHCP para comunicar la dirección IP de un servidor DHCP. El destinatario es el cliente si se encuentra en el mismo enlace que el servidor; de lo contrario, se envía al proxy del cliente.

* Consulta DHCP (''DHCP Request''): <br> Mensaje de solicitud de parámetros de configuración por un cliente sin dirección.
* Confirmación DHCP (''DHCP Confirm''): <br> Mensaje de solicitud de confirmación sobre la validez de los parámetros asignados al cliente.
* Renovación DHCP (''DHCP Renew''): <br> Mensaje de solicitud para prolongar el uso de la dirección IP asignada.
* Reasignación DHCP (''DHCP Rebind''): <br> Igual al mensaje anterior, pero puede ser otro servidor DHCP el que responde, y no necesariamente el que asignó la dirección IP.
* Respuesta DHCP (''DHCP Reply''): <br> Mensaje enviado por el servidor en respuesta a una petición del cliente. Contiene los valores de los parámetros de configuración solicitados.
* Liberación DHCP (''DHCP Release''): <br> Mensaje emitido por el cliente para notificar la liberación de las direcciones IP previamente asignadas por el servidor.
* Denegación DHCP (''DHCP Decline): <br> Mensaje de un cliente indicando que una o varias de las direcciones asignadas ya están siendo utilizadas en su enlace.
* Notificación de reconfiguración DHCP (''DHCP reconfigure-init''): <br> Mensaje enviado por el servidor para notificar al cliente que existen nuevos valores para los parámetros de configuración. El cliente debe iniciar una nueva transacción para adquirir esta información.
* Encapsulación de relevo (''Relay-Forward''): <br> Mensaje del proxy para transportar los mensajes del cliente hacia el servidor. El mensaje del cliente se encapsula en este mensaje.
* Encapsulación del servidor (''Relay-Reply''): <br> Mensaje generado por el servidor hacia el proxy con información destinada al cliente. El proxy extrae el mensaje para el cliente y lo transmitirá sobre el enlace correspondiente.

El intercambio de información entre el cliente y el servidor DHCP se realiza por medio de opciones. La información se divide en tres categorías (''cf'' Tabla de opciones de DHCPv6).
* Información temporal. Se refiere a recursos de red solicitados por el cliente y asignados por el servidor por un período determinado. Actualmente, el único tipo de recurso temporal es la dirección IP, cuya gestión se realiza bajo el concepto de IA.
* Información de carácter general. Se refiere al conjunto de parámetros normalmente presentados para la configuración de una máquina IPv6.
* Información específica a DHCP.

{|
|+'''Opciones DHCPv6'''
! Designación || Definición
|-style="background:silver"
|Asociación de identificación (IA) || Lista de direcciones IPv6 de una interfaz de cliente.
|-
|Consultas de opciones (ORO) || Lista de información de configuración solicitada por el cliente.
|-style="background:silver"
|Servidor de Nombres de Dominio || Lista de servidores DNS autorizados por el cliente.
|-
|Dominio de búsqueda || Lista de nombres de dominio que un cliente puede utilizar en la búscada de nombres de DNS.
|-style="background:silver"
|Mensaje cliente || Para la encapsulación del mensaje DHCP del cliente para el proxy
|-
|Mensaje servidor || Para la encapsulación del mensaje DHCP del servidor para el proxy
|-style="background:silver"
|Dirección IPv4 DSTM || Informa al cliente que la dirección asignada es una dirección IPv4 mapeada a IPv6
|-
|Autenticación || Para autenticar al emisor del mensaje DHCP y validar su integridad.
|-style="background:silver"
|Unicast servidor || Para notificar al cliente la dirección unicast del servidor y así establecer la comunicación sin ayuda del proxy. En este caso, el cliente debe tener una dirección unicast válida.
|-
|Identificador DHCP (DUID) || identificador permanente del cliente.
|-style="background:silver"
|Preferencia || Mecanismo ofrecido al cliente para elegir el servidor DHCP. El servidor seleccionado será responsable de proporcionar los parámetros de configuración para ese cliente.
|}

{{ eSuivi| Protocolo de Descubrimiento de vecinos |Protocolo de descubrimiento de vecinos |Implementación de la autoconfiguración|Implementación de la autoconfiguración}}

Protocolo DHCPv6

2012-07-17T00:47:15Z

Jincera:

{{ eSuivi| Protocolo de Descubrimiento de vecinos |Protocolo de descubrimiento de vecinos |Implementación de la autoconfiguración|Implementación de la autoconfiguración}}

__TOC__

==Principios ==

La autoconfiguración o (configuración automática) con y sin estado, busca reducir el esfuerzo de instalación de dispositivos IPv6. La diferencia entre ambas es que la primera ofrece más información de configuración y permite un mayor control sobre la asignación de parámetros de configuración.

Un parámetro de configuración representa información útil para que un dispositivo pueda configurar su interfaz de red con el fin de establecer comunicaciones sobre su enlace o en Internet. El conjunto de parámetros de configuración incluye la siguiente información:

* de direccionamiento, de enrutamiento,
* del servidor de nombres (DNS),
* del servicio de información de red (NIS)
* etcétera.

Cabe resaltar que la información de enrutamiento no está contemplada en los mecanismos de autoconfiguración de IPv6 con o sin estado, sino por el procedimiento de descubrimiento de enrutadores de ICMPv6. Las dos técnicas de autoconfiguración no son mutuamente exclusivas, pueden coexistir en un mismo entorno. Por ejemplo, una máquina puede obtener su dirección unicast global mediante la autoconfiguración sin estado, y recuperar la información sobre el servicio de nombres (DNS) vía la configuración automática con estado.

El mecanismo de configuración automática con estado sigue un modelo de cliente-servidor y se basa en el uso de DHCPv6 (''Dynamic Host ConfigurationProtocol'' para IPv6) como ocurre con DHCP para IPv4, aunque hay grandes diferencias en el código: DHCP en IPv4 no es más que una extensión del protocolo BOOTP, por lo que tiene una funcionalidad limitada. En cambio, el protocolo DHCPv6 permite establecer los parámetros de configuración de un servidor DHCP para un cliente IPv6.

El cliente IPv6 representa un dispositivo que busca tener conectividad global IPv6 y solicita la información de configuración necesaria para poder establecer esta conectividad. El servidor DHCP constituye un punto central que reagrupa los parámetros de configuración. No necesariamente se ubica en el mismo enlace que el cliente, en cuyo caso, la información DHCP puede inercambiarse a través de un relevo. El servidor puede contener información de configuración para dispositivos ubicados en distintos enlaces. El cliente DHCP debe establecer una conexión directa ya sea con el relevo o con el propio servidor DHCP.

El relevo funciona como un "proxy" DHCP que se limita a retransmitir los mensajes DHCP; es transparente a la información intercambiada y no modifica en absoluto los mensajes DHCP intercambiados entre el servidor y el cliente. El proxy encapsula los mensajes DHCP del cliente en un formato específico (''cf'' figura Estructura de los mensajes de relevo) y realiza la operación inversa, es decir, desencapsula los mensajes provenientes del servidor para su entrega al cliente. El servidor forma el mensaje que debe ser recibido por el cliente, y, si no tiene comunicación directa con él, lo encapsula en un mensaje DHCP dirigido al proxy.

Para conocer el estado de los recursos administrados (representados por los parámetros de configuración), el servidor DHCP mantiene una lista de asociaciones entre los parámetros asignados y el cliente. El cliente no puede ser identificado con su dirección unicast ya que ésta es parte de los parámetros otorgados por el servidor DHCP. Por ello, el servidor utiliza un identificador particular: el DUID (''DHCP Unique IDentifier''). El DUID es creado por el cliente y lo identifica a él (al nodo), no a una interfaz. Se han propuesto varios esquemas para generarlo, por ejemplo, a partir de la dirección de enlace local, completada con un elemento que garantice la exclusividad, como un sello de tiempo (''timestamp''). Una vez que el cliente genera un DUID, éste debe ser invariable, incluso si llegara a cambiar su dirección de enlace local.

En realidad, sí es posible utilizar la dirección de enlace local del cliente como identificador, pero no se garantiza que éste sea único en todo el dominio; únicamente se puede asegurar su unicidad a nivel del enlace. Sin embargo, ésta tiene las siguientes ventajas:

* Queda determinada por el cliente durante la primera fase de la configuración automática (''cf'' Configuración automática y el control),
* es permanente para el cliente (no habrá renumeración ni cambio de dirección mientras la tarjeta de red no se cambie).

La asignación de direcciones a cliente es administrada por el servidor bajo la noción de un contenedor llamado IA (''Identity Association''). Una IA se define como una lista (posiblemente vacía) de direcciones IPv6. La idea es que cada cliente tendrá una IA por interfaz; esta IA estará asignada de forma permanente a la interfaz. Por este conducto, la gestión del tiempo de vida de las direcciones o la renumeración del cliente es realizada por el servidor, lo que simplifica el formato de los mensajes y el control de las direcciones.

Conforme al modelo cliente-servidor, los intercambios de información están formados por solicitudes y respuestas. Una transacción suele comenzar a iniciativa del cliente mediante una solicitud DHCP. La confiabilidad del mecanismo queda en manos del cliente, quien reenviará la solicitud DHCP hasta recibir una respuesta, o tener la certeza de que el servidor DHCP no está disponible. DHCPv6 es un protocolo de aplicación que utiliza UDP como protocolo de transporte. El cliente envía sus solicitudes al puerto 547 y recibirá las respuestas en el puerto 546. Típicamente, los mensajes UDP se encapsulan en paquetes IPv6. Además de las comunicaciones punto a punto, DHCPv6 también se sirve de comunicaciones multicast para el descubrimiento de servidores en un sitio.

==Formato de mensajes DHCPv6 ==

El protocolo DHCPv6 se describe en el RFC 3315. Al igual que numerosos protocolos de Internet, el protocolo de intercambio de información está desacoplado de la información en sí misma. La información intercambiada puede cambiar y evolucionar rápidamente sin afectar los mecanismos de este intercambio. Esta separación ofrece al protocolo una estabilidad y cierta capacidad para ser extendido. Esta separación entre el protocolo y la información puede observarse en la estructura misma de las unidades protocolarias. Una unidad del protocolo DHCP sigue el patrón clásico de las estructuras protocolarias: una cabecera que contiene la información propia al protocolo, seguida de una carga útil que alberga la información aplicativa.

En la terminología de DHCP, se le llama mensaje a una unidad del protocolo DHCPv6. Cada mensaje DHCP tiene un formato de encabezado idéntico. Desde este punto de vista, DHCP sigue los principios que condujeron al diseño del segmento TCP: un formato único para todo el conjunto de funciones de TCP. Estos principios privilegian la simplificación en el proceso de desarrollo del protocolo.

La figura Estructura de los mensajes DHCPv6 muestra la estructura de un mensaje DHCPv6. La cabecera se divide en tres partes:

[[Image: CS57.gif]]

* La información de comando codificada en una palabra de 32 bits, designa la función DHCP relacionada con el intercambio. Esta parte contiene el tipo de mensaje y un identificador del intercambio. El primer campo (de 8 bits) muestra el tipo de mensaje y define la función del mensaje en el protocolo. Como su nombre lo indica, el campo ''transaction-ID'' tiene por objeto identificar el intercambio desde el punto de vista del cliente. Le permite asociar las respuestas recibidas a las solicitudes que ha formulado.
* La información de direccionamiento se utiliza para especificar la dirección IPv6 del servidor DHCP. Indica la dirección de la interfaz utilizada por el servidor en la transacción.
* El campo de opciones se utiliza para transmitir las informaciones de configuración. Es un campo de longitud variable cuya codificación sigue el clásico esquema "TLV", es decir, el Tipo de la opción, la Longitud en octetos del elemento que le sigue, que es el Valor del parámetro. El tipo se codifica en dos octetos. El campo de longitud también ocupa dos octetos aún si valor del parámetro es nulo o si éste tiene una longitud fija.

Los mensajes utilizados para la comunicación entre el servidor y el proxy de relevo, son diferentes. Un mensaje de relevo encapsula como una opción, la información del mensaje DHCP del servidor al cliente. El mensaje de relevo tiene un prefijo de enlace que que indica la interfaz del relevo a través de la cual se recibió el mensaje DHCP, o por la que debe ser enviado. La dirección de enlace local del cliente contiene la dirección de la interfaz a configurar en el cliente.

El protocolo DHCPv6 incluye 12 mensajes DHCP distintos:

* Solicitud DHCP (''DHCP Solicit''): <br> Mensaje de solicitud de presencia de servidores DHCP. Se transmite hacia un servidor o un proxy DHCP. Un cliente envía este mensaje para localizar los servidores DHCP.

* Anuncio DHCP (''DHCP Advertise''): <br> Mensaje de presencia de servidores DHCP. Se emite en respuesta a un mensaje de solicitud DHCP para comunicar la dirección IP de un servidor DHCP. El destinatario es el cliente si se encuentra en el mismo enlace que el servidor; de lo contrario, se envía al proxy del cliente.

* Consulta DHCP (''DHCP Request''): <br> Mensaje de solicitud de parámetros de configuración por un cliente sin dirección.
* Confirmación DHCP (''DHCP Confirm''): <br> Mensaje de solicitud de confirmación sobre la validez de los parámetros asignados al cliente.
* Renovación DHCP (''DHCP Renew''): <br> Mensaje de solicitud para prolongar el uso de la dirección IP asignada.
* Reasignación DHCP (''DHCP rebind): <br> Igual al mensaje anterior, pero puede ser otro servidor DHCP el que responde, y no necesariamente el que asignó la dirección IP.
* Respuesta DHCP (''DHCP Reply''): <br> Mensaje enviado por el servidor en respuesta a una petición del cliente. Contiene los valores de los parámetros de configuración solicitados.
* Liberación DHCP (''DHCP Release''): <br> Mensaje emitido por el cliente para notificar la liberación de las direcciones IP previamente asignadas por el servidor.
* Denegación DHCP (''DHCP Decline): <br> Mensaje de un cliente indicando que una o varias de las direcciones asignadas ya están siendo utilizadas en su enlace.
* Notificación de reconfiguración DHCP (''DHCP reconfigure-init''): <br> Mensaje enviado por el servidor para notificar al cliente que existen nuevos valores para los parámetros de configuración. El cliente debe iniciar una nueva transacción para adquirir esta información.
* Encapsulación de relevo (''Relay-Forward''): <br> Mensaje del proxy para transportar los mensajes del cliente hacia el servidor. El mensaje del cliente se encapsula en este mensaje.
* Encapsulación del servidor (''Relay-Reply''): <br> Mensaje generado por el servidor hacia el proxy con información destinada al cliente. El proxy extrae el mensaje para el cliente y lo transmitirá sobre el enlace correspondiente.

El intercambio de información entre el cliente y el servidor DHCP se realiza por medio de opciones. La información se divide en tres categorías (''cf'' Tabla de opciones de DHCPv6).
* Información temporal. Se refiere a recursos de red solicitados por el cliente y asignados por el servidor por un período determinado. Actualmente, el único tipo de recurso temporal es la dirección IP, cuya gestión se realiza bajo el concepto de IA.
* Información de carácter general. Se refiere al conjunto de parámetros normalmente presentados para la configuración de una máquina IPv6.
* Información específica a DHCP.

{|
|+'''Opciones DHCPv6'''
! Designación || Definición
|-style="background:silver"
|Asociación de identificación (IA) || Lista de direcciones IPv6 de una interfaz de cliente.
|-
|Consultas de opciones (ORO) || Lista de información de configuración solicitada por el cliente.
|-style="background:silver"
|Servidor de Nombres de Dominio || Lista de servidores DNS autorizados por el cliente.
|-
|Dominio de búsqueda || Lista de nombres de dominio que un cliente puede utilizar en la búscada de nombres de DNS.
|-style="background:silver"
|Mensaje cliente || Para la encapsulación del mensaje DHCP del cliente para el proxy
|-
|Mensaje servidor || Para la encapsulación del mensaje DHCP del servidor para el proxy
|-style="background:silver"
|Dirección IPv4 DSTM || Informa al cliente que la dirección asignada es una dirección IPv4 mapeada a IPv6
|-
|Autenticación || Para autenticar al emisor del mensaje DHCP y validar su integridad.
|-style="background:silver"
|Unicast servidor || Para notificar al cliente la dirección unicast del servidor y así establecer la comunicación sin ayuda del proxy. En este caso, el cliente debe tener una dirección unicast válida.
|-
|Identificador DHCP (DUID) || identificador permanente del cliente.
|-style="background:silver"
|Preferencia || Mecanismo ofrecido al cliente para elegir el servidor DHCP. El servidor seleccionado será responsable de proporcionar los parámetros de configuración para ese cliente.
|}

{{ eSuivi| Protocolo de Descubrimiento de vecinos |Protocolo de descubrimiento de vecinos |Implementación de la autoconfiguración|Implementación de la autoconfiguración}}

Protocolo DHCPv6

2012-07-12T23:45:09Z

Jincera:

Protocolo DHCPv6

2012-07-11T18:00:27Z

Jincera:

Protocolo DHCPv6

2012-07-11T17:58:06Z

Jincera: New page: {{ eSuivi| Protocolo de Descubrimiento de vecinos |Protocolo de descubrimiento de vecinos |Implementación de la autoconfiguración|Implementación de la autoconfiguración}} ==Principios...

Tabla de contenido

2012-07-11T17:57:27Z

Jincera: /* Configuración automática y control */

__NOTOC__

= [[Preambulo|Preámbulo]] =

=[[Introduccion|Introducción]] =

= Direccionamiento =
''Capítulo actualizado en fase de revisión; enviar comentarios o correcciones a GT-IPv6-Formation@g6.asso.fr''

* [[Direccionamiento-Fundamentos|Aspectos Fundamentales de Direccionamiento]]
* [[Direccionamiento-Implementaciones|Implementaciones]]
* [[Direccionamiento-Preguntas Abiertas|Preguntas abiertas]]: Anycast
* [[Direccionamiento-Investigacion|Problemas de investigación]]
* [[Direccionamiento-Historia|Histórico]]
* [[Direccionamiento-Referencias|Referencias]]
* [[Direccionamiento-Cuestionario|Cuestionario]]

= Protocolos de red y de transporte =
''Capítulo actualizado en fase de revisión; enviar comentarios o correcciones a GT-IPv6-Formation@g6.asso.fr''

* [[Formato de paquete IPv6]]
* [[Formato de mensaje ICMPv6]]
* [[Ejemplos de paquetes]]
* [[Pseudo-encabezado]]
* Preguntas abiertas: [[eIPv6 QO|Las extensiones]].
* [[eIPv6 Ref|Referencias]]
* [[eIPv6 QCM|Cuestionario]]

= Configuración automática y control =
''Capítulo actualizado en fase de revisión; enviar comentarios o correcciones a GT-IPv6-Formation@g6.asso.fr''

* [[Protocolo de Descubrimiento de vecinos]]
* [[Protocolo DHCPv6|DHCPv6]]
* [[Implementación de la configuración automática]]
* [[Buenas prácticas de la configuración automática]]
* [[Actividades de investigación sobre la configuración automática]]
* [[Cuestionario sobre la configuración automática]]

= [[Nombramiento|Asignación de nombres]] =
''Capítulo actualizado en fase de revisión; enviar comentarios o correcciones a GT-IPv6-Formation@g6.asso.fr''

= [[Infraestructura para la transmisión]] =
* [[Redes de difusión]]
* [[Redes NBMA]]
* [[Enlaces punto a punto]]
* [[Túneles]]
* [[IPv6 en la telefonía móvil (UMTS)]]

= [[Instalación de un dispositivo]] =
* [[eSolaris|Solaris]]
* [[eWindows|Windows]]
* [[eMacintosh|Macintosh]]
* [[eLinux|Linux]]
* [[eBSD|BSD]]

= [[Enrutamiento]] =
* [[Enrutamiento#estatico|Enrutamiento estático]]
* [[Enrutamiento#protocolos|Protocolos de enrutamiento]]
* [[Enrutamiento#interno|Enrutamiento interno]]
** [[eRIPng|RIPng]]
** [[eISIS|ISIS]]
** [[eOSPFv3|OSPFv3]]
* [[Enrutamiento externo]]
* [[eMPLS|MPLS]]
** [[La técnica 6PE]]
*** [[Ejemplo de implementación de 6PE]]
** [[Redes virtuales privadas IPv6 sobre MPLS]]
* [[eBGP|BGP]]

= [[Configuración de enrutadores]] =
* [[Configuración de enrutadores#interfaces|Configuración de interfaces]]
** Ethernet ([[eEtherAlcatel|OmnisSwitch Alcatel]], [[eEtherCisco|Cisco]], [[eEtherJuniper|Juniper]])
** POS ([[ePOSCisco|Cisco]], [[ePOSJuniper|Juniper]])
** ATM ([[eATMJuniper|Juniper]])
** Túnel IPv6 en IPv4 ([[eTunAlcatel|OmnisSwitch Alcatel]], [[eTunCisco|Cisco]], [[eTunJuniper|Juniper]])
* [[Configuración de enrutadores#enlace|Anuncio de prefijo sobre un enlace]] ([[eNDAlcatel|OmnisSwitch Alcatel]], [[eNDCisco|Cisco]], [[eNDJuniper|Juniper]])
* [[Configuración de enrutamiento]]
** Enrutamiento estático: [[eStaticAlcatel|OmnisSwitch Alcatel]], [[eStaticCisco|Cisco]], [[eStaticJuniper|Juniper]]
** lEnrutamiento interno:
*** RIP: [[eRIPAlcatel|OmnisSwitch Alcatel]], [[eRIPCisco|Cisco]],
*** ISIS: [[eISISCisco|Cisco]], [[eISISJuniper|Juniper]]
*** OSPF: [[eOSPFCisco|Cisco]], [[eOSPFJuniper|Juniper]]
** Enrutamiento externo ([[eBGPCisco|Cisco]], [[eBGPJuniper|Juniper]])
* [[Utilización de una computadora como enrutador]] ([[Enrutador Solaris|Solaris]], [[Enrutador Linux|Linux]], [[Enrutador FreeBSD|FreeBSD]], [[Enrutador NetBSD|NetBSD]])
* [[Utilización de una computadora como enrutador#quagga|Quagga y Zebra]]

= [[eMulticast|Multicast]] =
* [[Direccionamiento multicast]]
* [[Multicast IPv6 sobre el enlace local]]
** [[Multicast IPv6 sobre el enlace local#Gestión de abonados sobre el enlace local: MLD|Gestión de abonados sobre el enlace local: MLD]]
*** [[Ejemplos de funcionamiento de MLDv1]]
** [[Gestión de abonados sobre el enlace local: MLD versión 2]]
*** [[Ejemplos de funcionamiento de MLDv2]]
** [[Proxy de encaminamiento (forwarding) MLD]]
** [[Difusión du multicast IPv6 sobre el enlace local]]
* [[Construcción del árbol multicast - PIM|PIM]]
** [[Construcción del árbol multicast - PIM#El protocolo PIM SM - Sparse-Mode|El protocolo PIM SM - Sparse-Mode]]
** [[El protocolo PIM SSM - Source Specific Multicast]]
* [[Multicast IPv6 inter-dominio]]
* [[Despliegue de multicast]]
* [[Coexistencia con multicast IPv4]]
* [[Estudio práctico del despliegue de multicast IPv6]]

= [[Seguridad]] =
* [[Seguridad#introduccion|Introducción]]
* [[Seguridad#analisis|Análisis de riesgos]]
* [[Enfoque elegido por el IETF]]
* [[Asociación de seguridad]]
* [[Extensión de autenticación AH]]
* [[Extension de confidencialidad ESP]]
* [[Gestión de asociaciones y de llaves]]
** [[Gestión de asociaciones y de llaves#arquitectura|Arquitectura]]
** [[Intercambios ISAKMP/IKEv1]]
** [[IKE Versión 2]]
* [[Llaves públicas: infrastructuras y certificados]]
* [[Architecturas clásicas de implementación de IPsec]]
* [[Despliegue de un par de SA IPsec]]
* [[Crítica de IPsec]]
* [[Comparación entre VPN IPsec y VPN SSL]]

=[[Movilidad en IPv6]]=
* [[Movilidad en IPv6#introduccion|Introducción]]
* [[Gestión de la movilidad en IPv6]]
** [[Gestión de la movilidad en IPv6#IETF|El enfoque del IETF]]
** [[Gestión de la movilidad en IPv6#vue|Vista general de la gestión de la movilidad en IPv6]]
** [[Desplazamiento de móviles]]
* [[Encabezados de movilidad]]
**[[Encabezados de movilidad#Formato|Formato general de un paquete]]
* [[Riesgos introducidos por la movilidad y limitaciones]]
**[[Aseguramiento de la señalización con los nodos correspondientes]]
**[[Protección de la señalización con el protocolo IPsec]]
* [[Mejoramiento de la gestión de movilidad IPv6]]
* [[Soporte de la movilidad de redes ]]
* [[Ejemplo de despliegue de la pila LIVSIX]]

=[[Integración de IPv6 y de las aplicaciones]]=
*[[Estado de estandarización en el IETF]]
*[[Utilización de mecanismos de integración de IPv6]]
*[[Despliegue de IPv6 y mecanismos de integración]]
**[[Despliegue de IPv6 y mecanismos de integración#nucleo|Despliegue de IPv6 en el núcleo de la red]]
**[[Despliegue IPv6 de los proveedores de acceso (ISP)]]
**[[Acceso de empresas y de usuarios finales a la Internet IPv6]]
*[[Mecanismos de interoperabilidad]]
**[[Mecanismos de interoperabilidad#relevos|Relevos de aplicativos]]

=[[Programación de aplicaciones]]=
* [[Interfaz de programacion "socket" IPv6]]
** [[Interfaz de programacion "socket" IPv6#change|Qué ha cambiado]]
** [[Interfaz de programacion "socket" IPv6#struct|Las estructuras de datos de direcciones]]
** [[La interfaz socket]]
** [[La interfaz socket#wildcard|La dirección "wildcard"]]
** [[La interfaz socket#loopback|La dirección de ''loopback'']]
** [[Las primitivas de conversión entre nombres y direcciones]]
** [[Las primitivas de conversión entre nombres y direcciones#conv|Las funciones de conversión numéricas de direcciones]]
* [[Comando haah (''host-address-address-host'')]]
*[[Ejemplo de cliente/servidor TCP]]
*[[mini-ping]]
*[[Utilización de multicast]]
*[[Programación avanzada]]
**[[La implementación]]
**[[Ejemplo mini-ping revisitado]]

=[[Administración]]=
* [[Administración#MIBIPv6|MIB IPv6]]
* [[Administración#adm|Administración de redes IPv6]]
* [[Despliegue para los constructores]]
* [[Despliegue para los constructores#plateformes|Las plataformas]]
* [[Aplicaciones específicas]]
* [[Aplicaciones específicas#conclusion|Conclusión]]

=[[Historia de la estandarización de IPv6]]=
*[[Historia de la estandarización de IPv6#stand|La estandarisación de Internet]]
*[[La estandarización de IPv6]]

=[[Bases whois]]=

= [[Bibliografía]] =

Tabla de contenido

2012-07-11T17:56:34Z

Jincera: /* Configuración automática y control */

__NOTOC__

= [[Preambulo|Preámbulo]] =

=[[Introduccion|Introducción]] =

= Direccionamiento =
''Capítulo actualizado en fase de revisión; enviar comentarios o correcciones a GT-IPv6-Formation@g6.asso.fr''

* [[Direccionamiento-Fundamentos|Aspectos Fundamentales de Direccionamiento]]
* [[Direccionamiento-Implementaciones|Implementaciones]]
* [[Direccionamiento-Preguntas Abiertas|Preguntas abiertas]]: Anycast
* [[Direccionamiento-Investigacion|Problemas de investigación]]
* [[Direccionamiento-Historia|Histórico]]
* [[Direccionamiento-Referencias|Referencias]]
* [[Direccionamiento-Cuestionario|Cuestionario]]

= Protocolos de red y de transporte =
''Capítulo actualizado en fase de revisión; enviar comentarios o correcciones a GT-IPv6-Formation@g6.asso.fr''

* [[Formato de paquete IPv6]]
* [[Formato de mensaje ICMPv6]]
* [[Ejemplos de paquetes]]
* [[Pseudo-encabezado]]
* Preguntas abiertas: [[eIPv6 QO|Las extensiones]].
* [[eIPv6 Ref|Referencias]]
* [[eIPv6 QCM|Cuestionario]]

= Configuración automática y control =
''Capítulo actualizado en fase de revisión; enviar comentarios o correcciones a GT-IPv6-Formation@g6.asso.fr''

* [[Protocolo de Descubrimiento de vecinos]]
* [[eDHCPv6|DHCPv6]]
* [[Implementación de la configuración automática]]
* [[Buenas prácticas de la configuración automática]]
* [[Actividades de investigación sobre la configuración automática]]
* [[Cuestionario sobre la configuración automática]]

= [[Nombramiento|Asignación de nombres]] =
''Capítulo actualizado en fase de revisión; enviar comentarios o correcciones a GT-IPv6-Formation@g6.asso.fr''

= [[Infraestructura para la transmisión]] =
* [[Redes de difusión]]
* [[Redes NBMA]]
* [[Enlaces punto a punto]]
* [[Túneles]]
* [[IPv6 en la telefonía móvil (UMTS)]]

= [[Instalación de un dispositivo]] =
* [[eSolaris|Solaris]]
* [[eWindows|Windows]]
* [[eMacintosh|Macintosh]]
* [[eLinux|Linux]]
* [[eBSD|BSD]]

= [[Enrutamiento]] =
* [[Enrutamiento#estatico|Enrutamiento estático]]
* [[Enrutamiento#protocolos|Protocolos de enrutamiento]]
* [[Enrutamiento#interno|Enrutamiento interno]]
** [[eRIPng|RIPng]]
** [[eISIS|ISIS]]
** [[eOSPFv3|OSPFv3]]
* [[Enrutamiento externo]]
* [[eMPLS|MPLS]]
** [[La técnica 6PE]]
*** [[Ejemplo de implementación de 6PE]]
** [[Redes virtuales privadas IPv6 sobre MPLS]]
* [[eBGP|BGP]]

= [[Configuración de enrutadores]] =
* [[Configuración de enrutadores#interfaces|Configuración de interfaces]]
** Ethernet ([[eEtherAlcatel|OmnisSwitch Alcatel]], [[eEtherCisco|Cisco]], [[eEtherJuniper|Juniper]])
** POS ([[ePOSCisco|Cisco]], [[ePOSJuniper|Juniper]])
** ATM ([[eATMJuniper|Juniper]])
** Túnel IPv6 en IPv4 ([[eTunAlcatel|OmnisSwitch Alcatel]], [[eTunCisco|Cisco]], [[eTunJuniper|Juniper]])
* [[Configuración de enrutadores#enlace|Anuncio de prefijo sobre un enlace]] ([[eNDAlcatel|OmnisSwitch Alcatel]], [[eNDCisco|Cisco]], [[eNDJuniper|Juniper]])
* [[Configuración de enrutamiento]]
** Enrutamiento estático: [[eStaticAlcatel|OmnisSwitch Alcatel]], [[eStaticCisco|Cisco]], [[eStaticJuniper|Juniper]]
** lEnrutamiento interno:
*** RIP: [[eRIPAlcatel|OmnisSwitch Alcatel]], [[eRIPCisco|Cisco]],
*** ISIS: [[eISISCisco|Cisco]], [[eISISJuniper|Juniper]]
*** OSPF: [[eOSPFCisco|Cisco]], [[eOSPFJuniper|Juniper]]
** Enrutamiento externo ([[eBGPCisco|Cisco]], [[eBGPJuniper|Juniper]])
* [[Utilización de una computadora como enrutador]] ([[Enrutador Solaris|Solaris]], [[Enrutador Linux|Linux]], [[Enrutador FreeBSD|FreeBSD]], [[Enrutador NetBSD|NetBSD]])
* [[Utilización de una computadora como enrutador#quagga|Quagga y Zebra]]

= [[eMulticast|Multicast]] =
* [[Direccionamiento multicast]]
* [[Multicast IPv6 sobre el enlace local]]
** [[Multicast IPv6 sobre el enlace local#Gestión de abonados sobre el enlace local: MLD|Gestión de abonados sobre el enlace local: MLD]]
*** [[Ejemplos de funcionamiento de MLDv1]]
** [[Gestión de abonados sobre el enlace local: MLD versión 2]]
*** [[Ejemplos de funcionamiento de MLDv2]]
** [[Proxy de encaminamiento (forwarding) MLD]]
** [[Difusión du multicast IPv6 sobre el enlace local]]
* [[Construcción del árbol multicast - PIM|PIM]]
** [[Construcción del árbol multicast - PIM#El protocolo PIM SM - Sparse-Mode|El protocolo PIM SM - Sparse-Mode]]
** [[El protocolo PIM SSM - Source Specific Multicast]]
* [[Multicast IPv6 inter-dominio]]
* [[Despliegue de multicast]]
* [[Coexistencia con multicast IPv4]]
* [[Estudio práctico del despliegue de multicast IPv6]]

= [[Seguridad]] =
* [[Seguridad#introduccion|Introducción]]
* [[Seguridad#analisis|Análisis de riesgos]]
* [[Enfoque elegido por el IETF]]
* [[Asociación de seguridad]]
* [[Extensión de autenticación AH]]
* [[Extension de confidencialidad ESP]]
* [[Gestión de asociaciones y de llaves]]
** [[Gestión de asociaciones y de llaves#arquitectura|Arquitectura]]
** [[Intercambios ISAKMP/IKEv1]]
** [[IKE Versión 2]]
* [[Llaves públicas: infrastructuras y certificados]]
* [[Architecturas clásicas de implementación de IPsec]]
* [[Despliegue de un par de SA IPsec]]
* [[Crítica de IPsec]]
* [[Comparación entre VPN IPsec y VPN SSL]]

=[[Movilidad en IPv6]]=
* [[Movilidad en IPv6#introduccion|Introducción]]
* [[Gestión de la movilidad en IPv6]]
** [[Gestión de la movilidad en IPv6#IETF|El enfoque del IETF]]
** [[Gestión de la movilidad en IPv6#vue|Vista general de la gestión de la movilidad en IPv6]]
** [[Desplazamiento de móviles]]
* [[Encabezados de movilidad]]
**[[Encabezados de movilidad#Formato|Formato general de un paquete]]
* [[Riesgos introducidos por la movilidad y limitaciones]]
**[[Aseguramiento de la señalización con los nodos correspondientes]]
**[[Protección de la señalización con el protocolo IPsec]]
* [[Mejoramiento de la gestión de movilidad IPv6]]
* [[Soporte de la movilidad de redes ]]
* [[Ejemplo de despliegue de la pila LIVSIX]]

=[[Integración de IPv6 y de las aplicaciones]]=
*[[Estado de estandarización en el IETF]]
*[[Utilización de mecanismos de integración de IPv6]]
*[[Despliegue de IPv6 y mecanismos de integración]]
**[[Despliegue de IPv6 y mecanismos de integración#nucleo|Despliegue de IPv6 en el núcleo de la red]]
**[[Despliegue IPv6 de los proveedores de acceso (ISP)]]
**[[Acceso de empresas y de usuarios finales a la Internet IPv6]]
*[[Mecanismos de interoperabilidad]]
**[[Mecanismos de interoperabilidad#relevos|Relevos de aplicativos]]

=[[Programación de aplicaciones]]=
* [[Interfaz de programacion "socket" IPv6]]
** [[Interfaz de programacion "socket" IPv6#change|Qué ha cambiado]]
** [[Interfaz de programacion "socket" IPv6#struct|Las estructuras de datos de direcciones]]
** [[La interfaz socket]]
** [[La interfaz socket#wildcard|La dirección "wildcard"]]
** [[La interfaz socket#loopback|La dirección de ''loopback'']]
** [[Las primitivas de conversión entre nombres y direcciones]]
** [[Las primitivas de conversión entre nombres y direcciones#conv|Las funciones de conversión numéricas de direcciones]]
* [[Comando haah (''host-address-address-host'')]]
*[[Ejemplo de cliente/servidor TCP]]
*[[mini-ping]]
*[[Utilización de multicast]]
*[[Programación avanzada]]
**[[La implementación]]
**[[Ejemplo mini-ping revisitado]]

=[[Administración]]=
* [[Administración#MIBIPv6|MIB IPv6]]
* [[Administración#adm|Administración de redes IPv6]]
* [[Despliegue para los constructores]]
* [[Despliegue para los constructores#plateformes|Las plataformas]]
* [[Aplicaciones específicas]]
* [[Aplicaciones específicas#conclusion|Conclusión]]

=[[Historia de la estandarización de IPv6]]=
*[[Historia de la estandarización de IPv6#stand|La estandarisación de Internet]]
*[[La estandarización de IPv6]]

=[[Bases whois]]=

= [[Bibliografía]] =

Tabla de contenido

2012-07-11T17:56:10Z

Jincera: /* Configuración automática y control */

__NOTOC__

= [[Preambulo|Preámbulo]] =

=[[Introduccion|Introducción]] =

= Direccionamiento =
''Capítulo actualizado en fase de revisión; enviar comentarios o correcciones a GT-IPv6-Formation@g6.asso.fr''

* [[Direccionamiento-Fundamentos|Aspectos Fundamentales de Direccionamiento]]
* [[Direccionamiento-Implementaciones|Implementaciones]]
* [[Direccionamiento-Preguntas Abiertas|Preguntas abiertas]]: Anycast
* [[Direccionamiento-Investigacion|Problemas de investigación]]
* [[Direccionamiento-Historia|Histórico]]
* [[Direccionamiento-Referencias|Referencias]]
* [[Direccionamiento-Cuestionario|Cuestionario]]

= Protocolos de red y de transporte =
''Capítulo actualizado en fase de revisión; enviar comentarios o correcciones a GT-IPv6-Formation@g6.asso.fr''

* [[Formato de paquete IPv6]]
* [[Formato de mensaje ICMPv6]]
* [[Ejemplos de paquetes]]
* [[Pseudo-encabezado]]
* Preguntas abiertas: [[eIPv6 QO|Las extensiones]].
* [[eIPv6 Ref|Referencias]]
* [[eIPv6 QCM|Cuestionario]]

= Configuración automática y control =
''Capítulo actualizado en fase de revisión; enviar comentarios o correcciones a GT-IPv6-Formation@g6.asso.fr''

* [[Protocolo de Descubrimiento de vecinos]]
* [[_DHCPv6|DHCPv6]]
* [[Implementación de la configuración automática]]
* [[Buenas prácticas de la configuración automática]]
* [[Actividades de investigación sobre la configuración automática]]
* [[Cuestionario sobre la configuración automática]]

= [[Nombramiento|Asignación de nombres]] =
''Capítulo actualizado en fase de revisión; enviar comentarios o correcciones a GT-IPv6-Formation@g6.asso.fr''

= [[Infraestructura para la transmisión]] =
* [[Redes de difusión]]
* [[Redes NBMA]]
* [[Enlaces punto a punto]]
* [[Túneles]]
* [[IPv6 en la telefonía móvil (UMTS)]]

= [[Instalación de un dispositivo]] =
* [[eSolaris|Solaris]]
* [[eWindows|Windows]]
* [[eMacintosh|Macintosh]]
* [[eLinux|Linux]]
* [[eBSD|BSD]]

= [[Enrutamiento]] =
* [[Enrutamiento#estatico|Enrutamiento estático]]
* [[Enrutamiento#protocolos|Protocolos de enrutamiento]]
* [[Enrutamiento#interno|Enrutamiento interno]]
** [[eRIPng|RIPng]]
** [[eISIS|ISIS]]
** [[eOSPFv3|OSPFv3]]
* [[Enrutamiento externo]]
* [[eMPLS|MPLS]]
** [[La técnica 6PE]]
*** [[Ejemplo de implementación de 6PE]]
** [[Redes virtuales privadas IPv6 sobre MPLS]]
* [[eBGP|BGP]]

= [[Configuración de enrutadores]] =
* [[Configuración de enrutadores#interfaces|Configuración de interfaces]]
** Ethernet ([[eEtherAlcatel|OmnisSwitch Alcatel]], [[eEtherCisco|Cisco]], [[eEtherJuniper|Juniper]])
** POS ([[ePOSCisco|Cisco]], [[ePOSJuniper|Juniper]])
** ATM ([[eATMJuniper|Juniper]])
** Túnel IPv6 en IPv4 ([[eTunAlcatel|OmnisSwitch Alcatel]], [[eTunCisco|Cisco]], [[eTunJuniper|Juniper]])
* [[Configuración de enrutadores#enlace|Anuncio de prefijo sobre un enlace]] ([[eNDAlcatel|OmnisSwitch Alcatel]], [[eNDCisco|Cisco]], [[eNDJuniper|Juniper]])
* [[Configuración de enrutamiento]]
** Enrutamiento estático: [[eStaticAlcatel|OmnisSwitch Alcatel]], [[eStaticCisco|Cisco]], [[eStaticJuniper|Juniper]]
** lEnrutamiento interno:
*** RIP: [[eRIPAlcatel|OmnisSwitch Alcatel]], [[eRIPCisco|Cisco]],
*** ISIS: [[eISISCisco|Cisco]], [[eISISJuniper|Juniper]]
*** OSPF: [[eOSPFCisco|Cisco]], [[eOSPFJuniper|Juniper]]
** Enrutamiento externo ([[eBGPCisco|Cisco]], [[eBGPJuniper|Juniper]])
* [[Utilización de una computadora como enrutador]] ([[Enrutador Solaris|Solaris]], [[Enrutador Linux|Linux]], [[Enrutador FreeBSD|FreeBSD]], [[Enrutador NetBSD|NetBSD]])
* [[Utilización de una computadora como enrutador#quagga|Quagga y Zebra]]

= [[eMulticast|Multicast]] =
* [[Direccionamiento multicast]]
* [[Multicast IPv6 sobre el enlace local]]
** [[Multicast IPv6 sobre el enlace local#Gestión de abonados sobre el enlace local: MLD|Gestión de abonados sobre el enlace local: MLD]]
*** [[Ejemplos de funcionamiento de MLDv1]]
** [[Gestión de abonados sobre el enlace local: MLD versión 2]]
*** [[Ejemplos de funcionamiento de MLDv2]]
** [[Proxy de encaminamiento (forwarding) MLD]]
** [[Difusión du multicast IPv6 sobre el enlace local]]
* [[Construcción del árbol multicast - PIM|PIM]]
** [[Construcción del árbol multicast - PIM#El protocolo PIM SM - Sparse-Mode|El protocolo PIM SM - Sparse-Mode]]
** [[El protocolo PIM SSM - Source Specific Multicast]]
* [[Multicast IPv6 inter-dominio]]
* [[Despliegue de multicast]]
* [[Coexistencia con multicast IPv4]]
* [[Estudio práctico del despliegue de multicast IPv6]]

= [[Seguridad]] =
* [[Seguridad#introduccion|Introducción]]
* [[Seguridad#analisis|Análisis de riesgos]]
* [[Enfoque elegido por el IETF]]
* [[Asociación de seguridad]]
* [[Extensión de autenticación AH]]
* [[Extension de confidencialidad ESP]]
* [[Gestión de asociaciones y de llaves]]
** [[Gestión de asociaciones y de llaves#arquitectura|Arquitectura]]
** [[Intercambios ISAKMP/IKEv1]]
** [[IKE Versión 2]]
* [[Llaves públicas: infrastructuras y certificados]]
* [[Architecturas clásicas de implementación de IPsec]]
* [[Despliegue de un par de SA IPsec]]
* [[Crítica de IPsec]]
* [[Comparación entre VPN IPsec y VPN SSL]]

=[[Movilidad en IPv6]]=
* [[Movilidad en IPv6#introduccion|Introducción]]
* [[Gestión de la movilidad en IPv6]]
** [[Gestión de la movilidad en IPv6#IETF|El enfoque del IETF]]
** [[Gestión de la movilidad en IPv6#vue|Vista general de la gestión de la movilidad en IPv6]]
** [[Desplazamiento de móviles]]
* [[Encabezados de movilidad]]
**[[Encabezados de movilidad#Formato|Formato general de un paquete]]
* [[Riesgos introducidos por la movilidad y limitaciones]]
**[[Aseguramiento de la señalización con los nodos correspondientes]]
**[[Protección de la señalización con el protocolo IPsec]]
* [[Mejoramiento de la gestión de movilidad IPv6]]
* [[Soporte de la movilidad de redes ]]
* [[Ejemplo de despliegue de la pila LIVSIX]]

=[[Integración de IPv6 y de las aplicaciones]]=
*[[Estado de estandarización en el IETF]]
*[[Utilización de mecanismos de integración de IPv6]]
*[[Despliegue de IPv6 y mecanismos de integración]]
**[[Despliegue de IPv6 y mecanismos de integración#nucleo|Despliegue de IPv6 en el núcleo de la red]]
**[[Despliegue IPv6 de los proveedores de acceso (ISP)]]
**[[Acceso de empresas y de usuarios finales a la Internet IPv6]]
*[[Mecanismos de interoperabilidad]]
**[[Mecanismos de interoperabilidad#relevos|Relevos de aplicativos]]

=[[Programación de aplicaciones]]=
* [[Interfaz de programacion "socket" IPv6]]
** [[Interfaz de programacion "socket" IPv6#change|Qué ha cambiado]]
** [[Interfaz de programacion "socket" IPv6#struct|Las estructuras de datos de direcciones]]
** [[La interfaz socket]]
** [[La interfaz socket#wildcard|La dirección "wildcard"]]
** [[La interfaz socket#loopback|La dirección de ''loopback'']]
** [[Las primitivas de conversión entre nombres y direcciones]]
** [[Las primitivas de conversión entre nombres y direcciones#conv|Las funciones de conversión numéricas de direcciones]]
* [[Comando haah (''host-address-address-host'')]]
*[[Ejemplo de cliente/servidor TCP]]
*[[mini-ping]]
*[[Utilización de multicast]]
*[[Programación avanzada]]
**[[La implementación]]
**[[Ejemplo mini-ping revisitado]]

=[[Administración]]=
* [[Administración#MIBIPv6|MIB IPv6]]
* [[Administración#adm|Administración de redes IPv6]]
* [[Despliegue para los constructores]]
* [[Despliegue para los constructores#plateformes|Las plataformas]]
* [[Aplicaciones específicas]]
* [[Aplicaciones específicas#conclusion|Conclusión]]

=[[Historia de la estandarización de IPv6]]=
*[[Historia de la estandarización de IPv6#stand|La estandarisación de Internet]]
*[[La estandarización de IPv6]]

=[[Bases whois]]=

= [[Bibliografía]] =

Tabla de contenido

2012-07-11T17:55:44Z

Jincera: /* Configuración automática y control */

__NOTOC__

= [[Preambulo|Preámbulo]] =

=[[Introduccion|Introducción]] =

= Direccionamiento =
''Capítulo actualizado en fase de revisión; enviar comentarios o correcciones a GT-IPv6-Formation@g6.asso.fr''

* [[Direccionamiento-Fundamentos|Aspectos Fundamentales de Direccionamiento]]
* [[Direccionamiento-Implementaciones|Implementaciones]]
* [[Direccionamiento-Preguntas Abiertas|Preguntas abiertas]]: Anycast
* [[Direccionamiento-Investigacion|Problemas de investigación]]
* [[Direccionamiento-Historia|Histórico]]
* [[Direccionamiento-Referencias|Referencias]]
* [[Direccionamiento-Cuestionario|Cuestionario]]

= Protocolos de red y de transporte =
''Capítulo actualizado en fase de revisión; enviar comentarios o correcciones a GT-IPv6-Formation@g6.asso.fr''

* [[Formato de paquete IPv6]]
* [[Formato de mensaje ICMPv6]]
* [[Ejemplos de paquetes]]
* [[Pseudo-encabezado]]
* Preguntas abiertas: [[eIPv6 QO|Las extensiones]].
* [[eIPv6 Ref|Referencias]]
* [[eIPv6 QCM|Cuestionario]]

= Configuración automática y control =
''Capítulo actualizado en fase de revisión; enviar comentarios o correcciones a GT-IPv6-Formation@g6.asso.fr''

* [[Protocolo de Descubrimiento de vecinos]]
* [[ DHCPv6|DHCPv6]]
* [[Implementación de la configuración automática]]
* [[Buenas prácticas de la configuración automática]]
* [[Actividades de investigación sobre la configuración automática]]
* [[Cuestionario sobre la configuración automática]]

= [[Nombramiento|Asignación de nombres]] =
''Capítulo actualizado en fase de revisión; enviar comentarios o correcciones a GT-IPv6-Formation@g6.asso.fr''

= [[Infraestructura para la transmisión]] =
* [[Redes de difusión]]
* [[Redes NBMA]]
* [[Enlaces punto a punto]]
* [[Túneles]]
* [[IPv6 en la telefonía móvil (UMTS)]]

= [[Instalación de un dispositivo]] =
* [[eSolaris|Solaris]]
* [[eWindows|Windows]]
* [[eMacintosh|Macintosh]]
* [[eLinux|Linux]]
* [[eBSD|BSD]]

= [[Enrutamiento]] =
* [[Enrutamiento#estatico|Enrutamiento estático]]
* [[Enrutamiento#protocolos|Protocolos de enrutamiento]]
* [[Enrutamiento#interno|Enrutamiento interno]]
** [[eRIPng|RIPng]]
** [[eISIS|ISIS]]
** [[eOSPFv3|OSPFv3]]
* [[Enrutamiento externo]]
* [[eMPLS|MPLS]]
** [[La técnica 6PE]]
*** [[Ejemplo de implementación de 6PE]]
** [[Redes virtuales privadas IPv6 sobre MPLS]]
* [[eBGP|BGP]]

= [[Configuración de enrutadores]] =
* [[Configuración de enrutadores#interfaces|Configuración de interfaces]]
** Ethernet ([[eEtherAlcatel|OmnisSwitch Alcatel]], [[eEtherCisco|Cisco]], [[eEtherJuniper|Juniper]])
** POS ([[ePOSCisco|Cisco]], [[ePOSJuniper|Juniper]])
** ATM ([[eATMJuniper|Juniper]])
** Túnel IPv6 en IPv4 ([[eTunAlcatel|OmnisSwitch Alcatel]], [[eTunCisco|Cisco]], [[eTunJuniper|Juniper]])
* [[Configuración de enrutadores#enlace|Anuncio de prefijo sobre un enlace]] ([[eNDAlcatel|OmnisSwitch Alcatel]], [[eNDCisco|Cisco]], [[eNDJuniper|Juniper]])
* [[Configuración de enrutamiento]]
** Enrutamiento estático: [[eStaticAlcatel|OmnisSwitch Alcatel]], [[eStaticCisco|Cisco]], [[eStaticJuniper|Juniper]]
** lEnrutamiento interno:
*** RIP: [[eRIPAlcatel|OmnisSwitch Alcatel]], [[eRIPCisco|Cisco]],
*** ISIS: [[eISISCisco|Cisco]], [[eISISJuniper|Juniper]]
*** OSPF: [[eOSPFCisco|Cisco]], [[eOSPFJuniper|Juniper]]
** Enrutamiento externo ([[eBGPCisco|Cisco]], [[eBGPJuniper|Juniper]])
* [[Utilización de una computadora como enrutador]] ([[Enrutador Solaris|Solaris]], [[Enrutador Linux|Linux]], [[Enrutador FreeBSD|FreeBSD]], [[Enrutador NetBSD|NetBSD]])
* [[Utilización de una computadora como enrutador#quagga|Quagga y Zebra]]

= [[eMulticast|Multicast]] =
* [[Direccionamiento multicast]]
* [[Multicast IPv6 sobre el enlace local]]
** [[Multicast IPv6 sobre el enlace local#Gestión de abonados sobre el enlace local: MLD|Gestión de abonados sobre el enlace local: MLD]]
*** [[Ejemplos de funcionamiento de MLDv1]]
** [[Gestión de abonados sobre el enlace local: MLD versión 2]]
*** [[Ejemplos de funcionamiento de MLDv2]]
** [[Proxy de encaminamiento (forwarding) MLD]]
** [[Difusión du multicast IPv6 sobre el enlace local]]
* [[Construcción del árbol multicast - PIM|PIM]]
** [[Construcción del árbol multicast - PIM#El protocolo PIM SM - Sparse-Mode|El protocolo PIM SM - Sparse-Mode]]
** [[El protocolo PIM SSM - Source Specific Multicast]]
* [[Multicast IPv6 inter-dominio]]
* [[Despliegue de multicast]]
* [[Coexistencia con multicast IPv4]]
* [[Estudio práctico del despliegue de multicast IPv6]]

= [[Seguridad]] =
* [[Seguridad#introduccion|Introducción]]
* [[Seguridad#analisis|Análisis de riesgos]]
* [[Enfoque elegido por el IETF]]
* [[Asociación de seguridad]]
* [[Extensión de autenticación AH]]
* [[Extension de confidencialidad ESP]]
* [[Gestión de asociaciones y de llaves]]
** [[Gestión de asociaciones y de llaves#arquitectura|Arquitectura]]
** [[Intercambios ISAKMP/IKEv1]]
** [[IKE Versión 2]]
* [[Llaves públicas: infrastructuras y certificados]]
* [[Architecturas clásicas de implementación de IPsec]]
* [[Despliegue de un par de SA IPsec]]
* [[Crítica de IPsec]]
* [[Comparación entre VPN IPsec y VPN SSL]]

=[[Movilidad en IPv6]]=
* [[Movilidad en IPv6#introduccion|Introducción]]
* [[Gestión de la movilidad en IPv6]]
** [[Gestión de la movilidad en IPv6#IETF|El enfoque del IETF]]
** [[Gestión de la movilidad en IPv6#vue|Vista general de la gestión de la movilidad en IPv6]]
** [[Desplazamiento de móviles]]
* [[Encabezados de movilidad]]
**[[Encabezados de movilidad#Formato|Formato general de un paquete]]
* [[Riesgos introducidos por la movilidad y limitaciones]]
**[[Aseguramiento de la señalización con los nodos correspondientes]]
**[[Protección de la señalización con el protocolo IPsec]]
* [[Mejoramiento de la gestión de movilidad IPv6]]
* [[Soporte de la movilidad de redes ]]
* [[Ejemplo de despliegue de la pila LIVSIX]]

=[[Integración de IPv6 y de las aplicaciones]]=
*[[Estado de estandarización en el IETF]]
*[[Utilización de mecanismos de integración de IPv6]]
*[[Despliegue de IPv6 y mecanismos de integración]]
**[[Despliegue de IPv6 y mecanismos de integración#nucleo|Despliegue de IPv6 en el núcleo de la red]]
**[[Despliegue IPv6 de los proveedores de acceso (ISP)]]
**[[Acceso de empresas y de usuarios finales a la Internet IPv6]]
*[[Mecanismos de interoperabilidad]]
**[[Mecanismos de interoperabilidad#relevos|Relevos de aplicativos]]

=[[Programación de aplicaciones]]=
* [[Interfaz de programacion "socket" IPv6]]
** [[Interfaz de programacion "socket" IPv6#change|Qué ha cambiado]]
** [[Interfaz de programacion "socket" IPv6#struct|Las estructuras de datos de direcciones]]
** [[La interfaz socket]]
** [[La interfaz socket#wildcard|La dirección "wildcard"]]
** [[La interfaz socket#loopback|La dirección de ''loopback'']]
** [[Las primitivas de conversión entre nombres y direcciones]]
** [[Las primitivas de conversión entre nombres y direcciones#conv|Las funciones de conversión numéricas de direcciones]]
* [[Comando haah (''host-address-address-host'')]]
*[[Ejemplo de cliente/servidor TCP]]
*[[mini-ping]]
*[[Utilización de multicast]]
*[[Programación avanzada]]
**[[La implementación]]
**[[Ejemplo mini-ping revisitado]]

=[[Administración]]=
* [[Administración#MIBIPv6|MIB IPv6]]
* [[Administración#adm|Administración de redes IPv6]]
* [[Despliegue para los constructores]]
* [[Despliegue para los constructores#plateformes|Las plataformas]]
* [[Aplicaciones específicas]]
* [[Aplicaciones específicas#conclusion|Conclusión]]

=[[Historia de la estandarización de IPv6]]=
*[[Historia de la estandarización de IPv6#stand|La estandarisación de Internet]]
*[[La estandarización de IPv6]]

=[[Bases whois]]=

= [[Bibliografía]] =

Tabla de contenido

2012-07-11T17:54:53Z

Jincera: /* Configuración automática y control */

__NOTOC__

= [[Preambulo|Preámbulo]] =

=[[Introduccion|Introducción]] =

= Direccionamiento =
''Capítulo actualizado en fase de revisión; enviar comentarios o correcciones a GT-IPv6-Formation@g6.asso.fr''

* [[Direccionamiento-Fundamentos|Aspectos Fundamentales de Direccionamiento]]
* [[Direccionamiento-Implementaciones|Implementaciones]]
* [[Direccionamiento-Preguntas Abiertas|Preguntas abiertas]]: Anycast
* [[Direccionamiento-Investigacion|Problemas de investigación]]
* [[Direccionamiento-Historia|Histórico]]
* [[Direccionamiento-Referencias|Referencias]]
* [[Direccionamiento-Cuestionario|Cuestionario]]

= Protocolos de red y de transporte =
''Capítulo actualizado en fase de revisión; enviar comentarios o correcciones a GT-IPv6-Formation@g6.asso.fr''

* [[Formato de paquete IPv6]]
* [[Formato de mensaje ICMPv6]]
* [[Ejemplos de paquetes]]
* [[Pseudo-encabezado]]
* Preguntas abiertas: [[eIPv6 QO|Las extensiones]].
* [[eIPv6 Ref|Referencias]]
* [[eIPv6 QCM|Cuestionario]]

= Configuración automática y control =
''Capítulo actualizado en fase de revisión; enviar comentarios o correcciones a GT-IPv6-Formation@g6.asso.fr''

* [[Protocolo de Descubrimiento de vecinos]]
* [[eDHCPv6|DHCPv6]]
* [[Implementación de la configuración automática]]
* [[Buenas prácticas de la configuración automática]]
* [[Actividades de investigación sobre la configuración automática]]
* [[Cuestionario sobre la configuración automática]]

= [[Nombramiento|Asignación de nombres]] =
''Capítulo actualizado en fase de revisión; enviar comentarios o correcciones a GT-IPv6-Formation@g6.asso.fr''

= [[Infraestructura para la transmisión]] =
* [[Redes de difusión]]
* [[Redes NBMA]]
* [[Enlaces punto a punto]]
* [[Túneles]]
* [[IPv6 en la telefonía móvil (UMTS)]]

= [[Instalación de un dispositivo]] =
* [[eSolaris|Solaris]]
* [[eWindows|Windows]]
* [[eMacintosh|Macintosh]]
* [[eLinux|Linux]]
* [[eBSD|BSD]]

= [[Enrutamiento]] =
* [[Enrutamiento#estatico|Enrutamiento estático]]
* [[Enrutamiento#protocolos|Protocolos de enrutamiento]]
* [[Enrutamiento#interno|Enrutamiento interno]]
** [[eRIPng|RIPng]]
** [[eISIS|ISIS]]
** [[eOSPFv3|OSPFv3]]
* [[Enrutamiento externo]]
* [[eMPLS|MPLS]]
** [[La técnica 6PE]]
*** [[Ejemplo de implementación de 6PE]]
** [[Redes virtuales privadas IPv6 sobre MPLS]]
* [[eBGP|BGP]]

= [[Configuración de enrutadores]] =
* [[Configuración de enrutadores#interfaces|Configuración de interfaces]]
** Ethernet ([[eEtherAlcatel|OmnisSwitch Alcatel]], [[eEtherCisco|Cisco]], [[eEtherJuniper|Juniper]])
** POS ([[ePOSCisco|Cisco]], [[ePOSJuniper|Juniper]])
** ATM ([[eATMJuniper|Juniper]])
** Túnel IPv6 en IPv4 ([[eTunAlcatel|OmnisSwitch Alcatel]], [[eTunCisco|Cisco]], [[eTunJuniper|Juniper]])
* [[Configuración de enrutadores#enlace|Anuncio de prefijo sobre un enlace]] ([[eNDAlcatel|OmnisSwitch Alcatel]], [[eNDCisco|Cisco]], [[eNDJuniper|Juniper]])
* [[Configuración de enrutamiento]]
** Enrutamiento estático: [[eStaticAlcatel|OmnisSwitch Alcatel]], [[eStaticCisco|Cisco]], [[eStaticJuniper|Juniper]]
** lEnrutamiento interno:
*** RIP: [[eRIPAlcatel|OmnisSwitch Alcatel]], [[eRIPCisco|Cisco]],
*** ISIS: [[eISISCisco|Cisco]], [[eISISJuniper|Juniper]]
*** OSPF: [[eOSPFCisco|Cisco]], [[eOSPFJuniper|Juniper]]
** Enrutamiento externo ([[eBGPCisco|Cisco]], [[eBGPJuniper|Juniper]])
* [[Utilización de una computadora como enrutador]] ([[Enrutador Solaris|Solaris]], [[Enrutador Linux|Linux]], [[Enrutador FreeBSD|FreeBSD]], [[Enrutador NetBSD|NetBSD]])
* [[Utilización de una computadora como enrutador#quagga|Quagga y Zebra]]

= [[eMulticast|Multicast]] =
* [[Direccionamiento multicast]]
* [[Multicast IPv6 sobre el enlace local]]
** [[Multicast IPv6 sobre el enlace local#Gestión de abonados sobre el enlace local: MLD|Gestión de abonados sobre el enlace local: MLD]]
*** [[Ejemplos de funcionamiento de MLDv1]]
** [[Gestión de abonados sobre el enlace local: MLD versión 2]]
*** [[Ejemplos de funcionamiento de MLDv2]]
** [[Proxy de encaminamiento (forwarding) MLD]]
** [[Difusión du multicast IPv6 sobre el enlace local]]
* [[Construcción del árbol multicast - PIM|PIM]]
** [[Construcción del árbol multicast - PIM#El protocolo PIM SM - Sparse-Mode|El protocolo PIM SM - Sparse-Mode]]
** [[El protocolo PIM SSM - Source Specific Multicast]]
* [[Multicast IPv6 inter-dominio]]
* [[Despliegue de multicast]]
* [[Coexistencia con multicast IPv4]]
* [[Estudio práctico del despliegue de multicast IPv6]]

= [[Seguridad]] =
* [[Seguridad#introduccion|Introducción]]
* [[Seguridad#analisis|Análisis de riesgos]]
* [[Enfoque elegido por el IETF]]
* [[Asociación de seguridad]]
* [[Extensión de autenticación AH]]
* [[Extension de confidencialidad ESP]]
* [[Gestión de asociaciones y de llaves]]
** [[Gestión de asociaciones y de llaves#arquitectura|Arquitectura]]
** [[Intercambios ISAKMP/IKEv1]]
** [[IKE Versión 2]]
* [[Llaves públicas: infrastructuras y certificados]]
* [[Architecturas clásicas de implementación de IPsec]]
* [[Despliegue de un par de SA IPsec]]
* [[Crítica de IPsec]]
* [[Comparación entre VPN IPsec y VPN SSL]]

=[[Movilidad en IPv6]]=
* [[Movilidad en IPv6#introduccion|Introducción]]
* [[Gestión de la movilidad en IPv6]]
** [[Gestión de la movilidad en IPv6#IETF|El enfoque del IETF]]
** [[Gestión de la movilidad en IPv6#vue|Vista general de la gestión de la movilidad en IPv6]]
** [[Desplazamiento de móviles]]
* [[Encabezados de movilidad]]
**[[Encabezados de movilidad#Formato|Formato general de un paquete]]
* [[Riesgos introducidos por la movilidad y limitaciones]]
**[[Aseguramiento de la señalización con los nodos correspondientes]]
**[[Protección de la señalización con el protocolo IPsec]]
* [[Mejoramiento de la gestión de movilidad IPv6]]
* [[Soporte de la movilidad de redes ]]
* [[Ejemplo de despliegue de la pila LIVSIX]]

=[[Integración de IPv6 y de las aplicaciones]]=
*[[Estado de estandarización en el IETF]]
*[[Utilización de mecanismos de integración de IPv6]]
*[[Despliegue de IPv6 y mecanismos de integración]]
**[[Despliegue de IPv6 y mecanismos de integración#nucleo|Despliegue de IPv6 en el núcleo de la red]]
**[[Despliegue IPv6 de los proveedores de acceso (ISP)]]
**[[Acceso de empresas y de usuarios finales a la Internet IPv6]]
*[[Mecanismos de interoperabilidad]]
**[[Mecanismos de interoperabilidad#relevos|Relevos de aplicativos]]

=[[Programación de aplicaciones]]=
* [[Interfaz de programacion "socket" IPv6]]
** [[Interfaz de programacion "socket" IPv6#change|Qué ha cambiado]]
** [[Interfaz de programacion "socket" IPv6#struct|Las estructuras de datos de direcciones]]
** [[La interfaz socket]]
** [[La interfaz socket#wildcard|La dirección "wildcard"]]
** [[La interfaz socket#loopback|La dirección de ''loopback'']]
** [[Las primitivas de conversión entre nombres y direcciones]]
** [[Las primitivas de conversión entre nombres y direcciones#conv|Las funciones de conversión numéricas de direcciones]]
* [[Comando haah (''host-address-address-host'')]]
*[[Ejemplo de cliente/servidor TCP]]
*[[mini-ping]]
*[[Utilización de multicast]]
*[[Programación avanzada]]
**[[La implementación]]
**[[Ejemplo mini-ping revisitado]]

=[[Administración]]=
* [[Administración#MIBIPv6|MIB IPv6]]
* [[Administración#adm|Administración de redes IPv6]]
* [[Despliegue para los constructores]]
* [[Despliegue para los constructores#plateformes|Las plataformas]]
* [[Aplicaciones específicas]]
* [[Aplicaciones específicas#conclusion|Conclusión]]

=[[Historia de la estandarización de IPv6]]=
*[[Historia de la estandarización de IPv6#stand|La estandarisación de Internet]]
*[[La estandarización de IPv6]]

=[[Bases whois]]=

= [[Bibliografía]] =

Tabla de contenido

2012-07-11T17:54:17Z

Jincera: /* Configuración automática y control */

__NOTOC__

= [[Preambulo|Preámbulo]] =

=[[Introduccion|Introducción]] =

= Direccionamiento =
''Capítulo actualizado en fase de revisión; enviar comentarios o correcciones a GT-IPv6-Formation@g6.asso.fr''

* [[Direccionamiento-Fundamentos|Aspectos Fundamentales de Direccionamiento]]
* [[Direccionamiento-Implementaciones|Implementaciones]]
* [[Direccionamiento-Preguntas Abiertas|Preguntas abiertas]]: Anycast
* [[Direccionamiento-Investigacion|Problemas de investigación]]
* [[Direccionamiento-Historia|Histórico]]
* [[Direccionamiento-Referencias|Referencias]]
* [[Direccionamiento-Cuestionario|Cuestionario]]

= Protocolos de red y de transporte =
''Capítulo actualizado en fase de revisión; enviar comentarios o correcciones a GT-IPv6-Formation@g6.asso.fr''

* [[Formato de paquete IPv6]]
* [[Formato de mensaje ICMPv6]]
* [[Ejemplos de paquetes]]
* [[Pseudo-encabezado]]
* Preguntas abiertas: [[eIPv6 QO|Las extensiones]].
* [[eIPv6 Ref|Referencias]]
* [[eIPv6 QCM|Cuestionario]]

= Configuración automática y control =
''Capítulo actualizado en fase de revisión; enviar comentarios o correcciones a GT-IPv6-Formation@g6.asso.fr''

* [[Protocolo de Descubrimiento de vecinos]]
* [[DHCPv6|DHCPv6]]
* [[Implementación de la configuración automática]]
* [[Buenas prácticas de la configuración automática]]
* [[Actividades de investigación sobre la configuración automática]]
* [[Cuestionario sobre la configuración automática]]

= [[Nombramiento|Asignación de nombres]] =
''Capítulo actualizado en fase de revisión; enviar comentarios o correcciones a GT-IPv6-Formation@g6.asso.fr''

= [[Infraestructura para la transmisión]] =
* [[Redes de difusión]]
* [[Redes NBMA]]
* [[Enlaces punto a punto]]
* [[Túneles]]
* [[IPv6 en la telefonía móvil (UMTS)]]

= [[Instalación de un dispositivo]] =
* [[eSolaris|Solaris]]
* [[eWindows|Windows]]
* [[eMacintosh|Macintosh]]
* [[eLinux|Linux]]
* [[eBSD|BSD]]

= [[Enrutamiento]] =
* [[Enrutamiento#estatico|Enrutamiento estático]]
* [[Enrutamiento#protocolos|Protocolos de enrutamiento]]
* [[Enrutamiento#interno|Enrutamiento interno]]
** [[eRIPng|RIPng]]
** [[eISIS|ISIS]]
** [[eOSPFv3|OSPFv3]]
* [[Enrutamiento externo]]
* [[eMPLS|MPLS]]
** [[La técnica 6PE]]
*** [[Ejemplo de implementación de 6PE]]
** [[Redes virtuales privadas IPv6 sobre MPLS]]
* [[eBGP|BGP]]

= [[Configuración de enrutadores]] =
* [[Configuración de enrutadores#interfaces|Configuración de interfaces]]
** Ethernet ([[eEtherAlcatel|OmnisSwitch Alcatel]], [[eEtherCisco|Cisco]], [[eEtherJuniper|Juniper]])
** POS ([[ePOSCisco|Cisco]], [[ePOSJuniper|Juniper]])
** ATM ([[eATMJuniper|Juniper]])
** Túnel IPv6 en IPv4 ([[eTunAlcatel|OmnisSwitch Alcatel]], [[eTunCisco|Cisco]], [[eTunJuniper|Juniper]])
* [[Configuración de enrutadores#enlace|Anuncio de prefijo sobre un enlace]] ([[eNDAlcatel|OmnisSwitch Alcatel]], [[eNDCisco|Cisco]], [[eNDJuniper|Juniper]])
* [[Configuración de enrutamiento]]
** Enrutamiento estático: [[eStaticAlcatel|OmnisSwitch Alcatel]], [[eStaticCisco|Cisco]], [[eStaticJuniper|Juniper]]
** lEnrutamiento interno:
*** RIP: [[eRIPAlcatel|OmnisSwitch Alcatel]], [[eRIPCisco|Cisco]],
*** ISIS: [[eISISCisco|Cisco]], [[eISISJuniper|Juniper]]
*** OSPF: [[eOSPFCisco|Cisco]], [[eOSPFJuniper|Juniper]]
** Enrutamiento externo ([[eBGPCisco|Cisco]], [[eBGPJuniper|Juniper]])
* [[Utilización de una computadora como enrutador]] ([[Enrutador Solaris|Solaris]], [[Enrutador Linux|Linux]], [[Enrutador FreeBSD|FreeBSD]], [[Enrutador NetBSD|NetBSD]])
* [[Utilización de una computadora como enrutador#quagga|Quagga y Zebra]]

= [[eMulticast|Multicast]] =
* [[Direccionamiento multicast]]
* [[Multicast IPv6 sobre el enlace local]]
** [[Multicast IPv6 sobre el enlace local#Gestión de abonados sobre el enlace local: MLD|Gestión de abonados sobre el enlace local: MLD]]
*** [[Ejemplos de funcionamiento de MLDv1]]
** [[Gestión de abonados sobre el enlace local: MLD versión 2]]
*** [[Ejemplos de funcionamiento de MLDv2]]
** [[Proxy de encaminamiento (forwarding) MLD]]
** [[Difusión du multicast IPv6 sobre el enlace local]]
* [[Construcción del árbol multicast - PIM|PIM]]
** [[Construcción del árbol multicast - PIM#El protocolo PIM SM - Sparse-Mode|El protocolo PIM SM - Sparse-Mode]]
** [[El protocolo PIM SSM - Source Specific Multicast]]
* [[Multicast IPv6 inter-dominio]]
* [[Despliegue de multicast]]
* [[Coexistencia con multicast IPv4]]
* [[Estudio práctico del despliegue de multicast IPv6]]

= [[Seguridad]] =
* [[Seguridad#introduccion|Introducción]]
* [[Seguridad#analisis|Análisis de riesgos]]
* [[Enfoque elegido por el IETF]]
* [[Asociación de seguridad]]
* [[Extensión de autenticación AH]]
* [[Extension de confidencialidad ESP]]
* [[Gestión de asociaciones y de llaves]]
** [[Gestión de asociaciones y de llaves#arquitectura|Arquitectura]]
** [[Intercambios ISAKMP/IKEv1]]
** [[IKE Versión 2]]
* [[Llaves públicas: infrastructuras y certificados]]
* [[Architecturas clásicas de implementación de IPsec]]
* [[Despliegue de un par de SA IPsec]]
* [[Crítica de IPsec]]
* [[Comparación entre VPN IPsec y VPN SSL]]

=[[Movilidad en IPv6]]=
* [[Movilidad en IPv6#introduccion|Introducción]]
* [[Gestión de la movilidad en IPv6]]
** [[Gestión de la movilidad en IPv6#IETF|El enfoque del IETF]]
** [[Gestión de la movilidad en IPv6#vue|Vista general de la gestión de la movilidad en IPv6]]
** [[Desplazamiento de móviles]]
* [[Encabezados de movilidad]]
**[[Encabezados de movilidad#Formato|Formato general de un paquete]]
* [[Riesgos introducidos por la movilidad y limitaciones]]
**[[Aseguramiento de la señalización con los nodos correspondientes]]
**[[Protección de la señalización con el protocolo IPsec]]
* [[Mejoramiento de la gestión de movilidad IPv6]]
* [[Soporte de la movilidad de redes ]]
* [[Ejemplo de despliegue de la pila LIVSIX]]

=[[Integración de IPv6 y de las aplicaciones]]=
*[[Estado de estandarización en el IETF]]
*[[Utilización de mecanismos de integración de IPv6]]
*[[Despliegue de IPv6 y mecanismos de integración]]
**[[Despliegue de IPv6 y mecanismos de integración#nucleo|Despliegue de IPv6 en el núcleo de la red]]
**[[Despliegue IPv6 de los proveedores de acceso (ISP)]]
**[[Acceso de empresas y de usuarios finales a la Internet IPv6]]
*[[Mecanismos de interoperabilidad]]
**[[Mecanismos de interoperabilidad#relevos|Relevos de aplicativos]]

=[[Programación de aplicaciones]]=
* [[Interfaz de programacion "socket" IPv6]]
** [[Interfaz de programacion "socket" IPv6#change|Qué ha cambiado]]
** [[Interfaz de programacion "socket" IPv6#struct|Las estructuras de datos de direcciones]]
** [[La interfaz socket]]
** [[La interfaz socket#wildcard|La dirección "wildcard"]]
** [[La interfaz socket#loopback|La dirección de ''loopback'']]
** [[Las primitivas de conversión entre nombres y direcciones]]
** [[Las primitivas de conversión entre nombres y direcciones#conv|Las funciones de conversión numéricas de direcciones]]
* [[Comando haah (''host-address-address-host'')]]
*[[Ejemplo de cliente/servidor TCP]]
*[[mini-ping]]
*[[Utilización de multicast]]
*[[Programación avanzada]]
**[[La implementación]]
**[[Ejemplo mini-ping revisitado]]

=[[Administración]]=
* [[Administración#MIBIPv6|MIB IPv6]]
* [[Administración#adm|Administración de redes IPv6]]
* [[Despliegue para los constructores]]
* [[Despliegue para los constructores#plateformes|Las plataformas]]
* [[Aplicaciones específicas]]
* [[Aplicaciones específicas#conclusion|Conclusión]]

=[[Historia de la estandarización de IPv6]]=
*[[Historia de la estandarización de IPv6#stand|La estandarisación de Internet]]
*[[La estandarización de IPv6]]

=[[Bases whois]]=

= [[Bibliografía]] =

EDHCPv6

2012-07-11T17:53:40Z

Jincera: New page: {{ eSuivi| Protocolo de Descubrimiento de vecinos |Protocolo de Descubrimiento de vecinos |Implementación de la autoconfiguración|Implementación de la autoconfiguración}} ==Principios...

{{ eSuivi| Protocolo de Descubrimiento de vecinos |Protocolo de Descubrimiento de vecinos |Implementación de la autoconfiguración|Implementación de la autoconfiguración}}

==Principios ==

La autoconfiguración o (configuración automática) con y sin estado, busca reducir el esfuerzo de instalación de dispositivos IPv6. La diferencia entre ambas es que la primera ofrece más información de configuración y permite un mayor control sobre la asignación de parámetros de configuración.

Un parámetro de configuración representa información útil para que un dispositivo pueda configurar su interfaz de red con el fin de establecer comunicaciones sobre su enlace o en Internet. El conjunto de parámetros de configuración incluye la siguiente información:

* de direccionamiento, de enrutamiento,
* del servidor de nombres (DNS),
* del servicio de información de red (NIS)
* etcétera.

Cabe resaltar que la información de enrutamiento no está contemplada en los mecanismos de autoconfiguración de IPv6 con o sin estado, sino por el procedimiento de descubrimiento de enrutadores de ICMPv6. Las dos técnicas de autoconfiguración no son mutuamente exclusivas, pueden coexistir en un mismo entorno. Por ejemplo, una máquina puede obtener su dirección unicast global mediante la autoconfiguración sin estado, y recuperar la información sobre el servicio de nombres (DNS) vía la configuración automática con estado.

El mecanismo de configuración automática con estado sigue un modelo de cliente-servidor y se basa en el uso de DHCPv6 (''Dynamic Host ConfigurationProtocol'' para IPv6) como ocurre con DHCP para IPv4, aunque hay grandes diferencias en el código: DHCP en IPv4 no es más que una extensión del protocolo BOOTP, por lo que tiene una funcionalidad limitada. En cambio, el protocolo DHCPv6 permite establecer los parámetros de configuración de un servidor DHCP para un cliente IPv6.

El cliente IPv6 representa un dispositivo que busca tener conectividad global IPv6 y solicita la información de configuración necesaria para poder establecer esta conectividad. El servidor DHCP constituye un punto central que reagrupa los parámetros de configuración. No necesariamente se ubica en el mismo enlace que el cliente, en cuyo caso, la información DHCP puede inercambiarse a través de un relevo. El servidor puede contener información de configuración para dispositivos ubicados en distintos enlaces. El cliente DHCP debe establecer una conexión directa ya sea con el relevo o con el propio servidor DHCP.

El relevo funciona como un "proxy" DHCP que se limita a retransmitir los mensajes DHCP; es transparente a la información intercambiada y no modifica en absoluto los mensajes DHCP intercambiados entre el servidor y el cliente. El proxy encapsula los mensajes DHCP del cliente en un formato específico (''cf'' figura Estructura de los mensajes de relevo) y realiza la operación inversa, es decir, desencapsula los mensajes provenientes del servidor para su entrega al cliente. El servidor forma el mensaje que debe ser recibido por el cliente, y, si no tiene comunicación directa con él, lo encapsula en un mensaje DHCP dirigido al proxy.

{{ eSuivi| Protocolo de Descubrimiento de vecinos |Protocolo de Descubrimiento de vecinos |Implementación de la autoconfiguración|Implementación de la autoconfiguración}}

Protocolo de Descubrimiento de vecinos

2012-07-07T01:19:01Z

Jincera: /* Ciclo de vida de una dirección */

{{eSuivi|Tabla de contenido|Incio del capítulo|DHCPv6|DHCPv6}}

__TOC__

El protocolo de descubrimiento de vecinos (NDP, ''Neighbor Discovery Protocol'') permite a un dispositivo integrarse en el ambiente local, es decir, el enlace sobre el cual se transmiten físicamente los paquetes IPv6. Permite establecer un diálogo con los equipos (estaciones y enrutadores) conectados sobre el mismo medio. No se pretende que un dispositivo conozca con exactitud la lista de todos los demás dispositivos conectados al enlace, sino de proveer un mecanismo para dialogar con quien necesite hacerlo.

El protocolo utiliza cinco tipos de mensajes ICMPv6 (ver Valores de los campos de tipo y código de ICMPv6). El campo número de saltos de la cabecera IPv6 contiene el valor 255. Este valor parece demasiado grande para datagramas que no debieran ser enrutados fuera del enlace físico. En realidad, si un equipo recibe un datagrama con un valor menor, significa que la información proviene de otra red y que ya ha atravesado al menos un enrutador. Por ello, los datagramas que tienen un valor diferente de 255 deben ser ignorados por el receptor.

{{Tableau eICMPv6}}

El protocolo realiza varias funciones:

* Resolución de direcciones. El principio es muy similar al del protocolo ARP de IPv4. La principal diferencia consiste en el uso de mensajes ICMPv6 estándar en lugar de definir otro protocolo de capa 3. Con esto se consigue una mayor flexibilidad de uso, especialmente en las redes que no soportan la difusión de mensajes. Al igual que en IPv4, el protocolo se encarga de construir tablas de correspondencia entre las direcciones IPv6 y las físicas.
* <div vecinos id="NUD"> Detección de inaccesibilidad de vecinos (NUD, ''Neighbor Unreachability Detection''). Esta función, que no existe en IPv4, permite eliminar de las tablas de configuración de un equipo, los vecinos que se han vuelto inaccesibles (por fallas, cambio de domicilio, ...). Si un enrutador deja de estar disponible, la tabla de enrutamiento puede ser modificada para considerar otra ruta. </div>
* Configuración. La configuración automática de los dispositivos es uno de los principales atractivos de IPv6. Se implementan varias funcionalidades del protocolo de descubrimiento de vecinos:
**Descubrimiento de enrutadores. Este protocolo permite que los dispositivos identifiquen a los enrutadores que se encuentran en su enlace físico. En IPv4, esta función la proporciona el protocolo ''ICMP Router Discovery''.
** Descubrimiento de prefijos. El dispositivo conoce el o los prefijos de red de acuerdo a los anuncios realizados por los enrutadores. Agregando su identificador de interfaz, el dispositivo construye su o sus direcciones IPv6. No hay un mecanismo equivalente para las direcciones IPv4 ya que son demasiado cortas para realizar la auto-configuración.
** Detección de direcciones duplicadas. Dado que las direcciones se configuran de forma automática, existen riesgos de error en caso de tener equipos con identificadores repetidos. Este protocolo verifica que ningún otro equipo en el enlace tiene la misma dirección IPv6. Esta función es una evolución del ARP gratuito en IPv4 emitido durante la inicialización de la interfaz.
** Descubrimiento de parámetros. Este protocolo permite que los dispositivos conozcan los distintos parámetros del enlace físico, por ejemplo, el tamaño de MTU, el número máximo de saltos permitido (valor original del campo número de saltos), si la configuración automática con estado (como [[Configuración con estado: DHCPv6|DHCPv6]]) está activa, etc. No existe un equivalente de esta funcionalidad en IPv4.
* Indicación de redirección. Este mensaje se utiliza cuando un enrutador conoce una trayectoria mejor (medida en número de saltos) para alcanzar un destino.
:En IPv4 una indicación de redireccionamiento sólo puede servir para corregir la dirección del enrutador utilizado para acceder a una máquina fuera de la red local. Los dispositivos deben conocer todas las direcciones correspondientes a equipos conectados en su propia red local.
:EnIPv6, la correspondencia entre prefijo y red local es menos rígida. Es de esperar que un dispositivo no conozca todos los prefijos de su red local (si ésta es compartida por varios prefijos), o que un prefijo se comparta entre varios enlaces (lo que corresponde a una generalización del modelo de redes lógicas IP sobre ATM). Bajo algunas configuraciones, la máquina emitirá sus paquetes al enrutador aún si el destinatario se encuentra en el mismo segmento que el emisor. En este caso, el enrutador emitirá un mensaje de redirección para que la continuación del diálogo entre ellos haga de manera directa (véanse los ejemplos [[#IR|Indicación de redirección]]).
:En el caso más extremo, podría imaginarse en IPv6 que un dispositivo puede ser configurado para comunicarse únicamente con su enrutador por omisión. ICMPv6 ''redirect'' puede utilizarse entonces, para informar al dispositivo de destinatarios ubicados en el mismo enlace.

En IPv6 se especifican dos métodos de autoconfiguración para las direcciones unicast global:

* Autoconfiguración sin estado (''stateless autoconfiguration'', RFC 2462). Se utiliza cuando no es necesaria una gestión administrativa de las direcciones asignadas dentro de un sitio. Estos mecanismos se describen más adelante en este capítulo.
* Autoconfiguración con estado (''statefull autoconfiguration''). Se utiliza cuando un sitio requiere de un control estricto de la asignación de direcciones (''cf'' [[Configuración con estado: DHCPv6 | DHCPv6]]).

Sin embargo, el uso de DHCPv6 para obtener la dirección se controla mediante el protocolo de descubrimiento de vecinos.

= Datos transmitidos por los mensajes =

La principal motivación detrás del Protocolo de Descubrimiento de vecinos es unificar varios protocolos existentes en IPv4. En particular, la mayor parte de los datos utiliza un formato de opciones común, lo que simplifica la implementación del protocolo. El formato contiene los campos: tipo, longitud (en palabras de 64 bits), y datos. La baja precisión de campo longitud, presentará un desperdicio de espacio, pero permite una alineación de las opciones en palabras de 64 bits, lo que permite un procesamiento optimizado.

{{NB-Opciones}}

== <div id="física">Dirección física de la fuente/destino</div> ==

<tikz title="Formato de la opción dirección física fuente/destino">
\clip (0.2, 5.7) rectangle (11.1,6.7);
% \draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=1/2}};
\draw (2.9, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{lenght }};
\draw (5.3, 6) node (addr) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Link Layer Address}};

\draw [draw=white, thick] (addr.north east) -- (addr.south east);
\draw [draw=white, thick] (addr.north east) -- +(-2, 0);
\draw [draw=white, thick] (addr.south east) -- +(-2, 0);

\draw [dashed] (addr.north east) -- (addr.south east);
\draw [dashed] (addr.north east) -- +(-2, 0);
\draw [dashed] (addr.south east) -- +(-2, 0);
</tikz>

La figura ''Formato de la opción dirección física fuente/destino'' presenta estas opciones. El tipo 1 designa la dirección física de la fuente y el tipo 2 la dirección del destino.

El campo ''length'' es el tamaño en palabras de 64 bits de la opción. Por lo tanto, para el caso de una dirección MAC con longitud de 6 octetos, contiene el valor 1.

El RFC 2464 define el formato para las direcciones MAC-48 utilizadas en las redes Ethernet y Wi-Fi. El RFC 4944 define el formato para las direcciones MAC-16 y MAC-64 utilizadas en las redes de sensores bajo la norma IEEE 802.15.4.

== <div id="información">Información sobre el prefijo</div> ==

<tikz title="Formato de la opción información sobre el prefijo">
\clip (0.2, 2) rectangle (11.1, 7);
% \draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=3}};
\draw (2.9, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{length =4 }};
\draw (5.3, 6) node (addr) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm] {\tiny{Prefix Length}};
\draw (7.7, 6) node (bitL) [right, shade, top color=blue!15, bottom color=blue!5,, draw, minimum height=0.5cm, minimum width=.3cm]{}; \draw (bitL.text) node {\tiny{L}};
\draw (8, 6) node (bitA) [right, shade, top color=blue!15, bottom color=blue!5,, draw, minimum height=0.5cm, minimum width=.3cm]{};\draw (bitA.text) node {\tiny{A}};
\draw (8.3, 6) node (bitR) [right, shade, top color=blue!15, bottom color=blue!5,, draw, minimum height=0.5cm, minimum width=.3cm]{};\draw (bitR.text) node {\tiny{R}};
\draw (8.6, 6) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=1.5cm] {\tiny{Reserved}};

\draw (0.5, 5.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Valid Lifetime}};

\draw (0.5, 5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Prefered Lifetime}};

\draw (0.5, 4.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Reserved}};

\draw (0.5, 4) node (addr1) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{}};
\draw (0.5, 3.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{}};
\draw (0.5, 3) node (addr3) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Prefix}};
\draw (0.5, 2.5) node (addr4) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{}};

\draw [color=blue!10, very thick] (addr1.south east) -- (addr1.south west);
\draw [color=blue!10, very thick] (addr2.south east) -- (addr2.south west);
\draw [color=blue!10, very thick] (addr3.south east) -- (addr3.south west);
</tikz>

Esta opción contiene las informaciones sobre el prefijo para permitir una configuración automática de los dispositivos. El campo tipo tiene el valor 3 y el de longitud, 4. La figura ''Formato de la opción información sobre el prefijo'' muestra el formato de esta opción:

* El campo ''Prefix lenght'' indica cuántos bits son significativos para el prefijo anunciado en un campo siguiente.
* El bit <tt>L</tt> indica, cuando vale 1, que el prefijo permite indicar que todos los demás dispositivos que comparten el mismo prefijo, están en el mismo enlace, por lo que el emisor puede contactarlos directamente. En caso contrario, el dispositivo envía el paquete hacia el enrutador. Si éste último sabe que el emisor puede contactar directamente al destinatario, emitirá un mensaje ICMPv6 de indicación de redirección.
* El bit <tt>A</tt> indica, cuando vale 1, que el prefijo anunciado puede utilizarse para formar la dirección del dispositivo.
* El bit <tt>R</tt>, indica, cuando vale 1, que el campo prefijo contiene la dirección global de un enrutador ''agente base''. Los bits de mayor peso aún pueden utilizarse para formar un prefijo.
* El campo duración de validez indica, en segundos, la duración durante la cual el prefijo es válido.
* El campo duración preferente indica la duración, en segundos, durante la cual una dirección formada con el protocolo de configuración sin estado se mantiene ''preferente'' (''cf'' [[Planes de direccionamiento|Tiempo de vida de las direcciones]]).

Para estos dos campos, un valor de <tt>0xffffffff</tt> representa una duración infinita. Estos campos pueden servir durante la fase de transición de un proveedor de acceso a otro; es decir, de un prefijo a otro.
* El campo reservado permite alinear el prefijo a una frontera de palabra de 64 bits.
* El campo prefijo contiene el valor de prefijo anunciado sobre el enlace. Para mantener una alineación de 64 bits para el resto de datos del paquete, este campo tiene una longitud fija de 128 bits.

== <div id="redirigida">Cabecera de redirección </div> ==

<tikz title="Formato de la opción cabecera de redirección">
\clip (0.2, 3.1) rectangle (11.1, 7);
% \draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=5}};
\draw (2.9, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{length =1 }};
\draw (5.3, 6) node (addr) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Reserved}};

\draw (0.5, 5.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Reserved}};

\draw (0.5, 4.25) node (context) [right, shade, top color=purple!50, bottom color=purple!10, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{IPv6 Header and Data}};
</tikz>

Esta opción es utilizada por el mensaje de indicación de redirección. Permite encapsular los primeros octetos del paquete IPv6 que provocó la emisión de este mensaje, como ocurre con los mensajes de error de ICMPv6.

El campo tipo tiene el valor 4. El tamaño de esta opción debe evitar que el paquete IPv6 rebase los 1280 octetos (''cf'' figura ''Formato de la opción cabecera de redirección''). Sin embargo, el paquete debe contener la mayor cantidad de información posible.

== <div id="MTU">MTU</div> ==

<tikz title="Formato de la opción MTU">

\clip (0.2, 5.1) rectangle (11.1, 7);
% \draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=5}};
\draw (2.9, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{lenght =1 }};
\draw (5.3, 6) node (addr) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Reserved}};

\draw (0.5, 5.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{MTU}};
</tikz>

Esta opción permite notificar a los dispositivos el tamaño máximo de datos que pueden ser transmitidos sobre el enlace. La figura ''Formato de la opción MTU'' muestra su estructura. No es necesario difundir esta información si el dispositivo utiliza siempre el tamaño máximo permitido. Por ejemplo, sobre las redes Ethernet, los dispositivos utilizarán el valor 1,500. En cambio, en las redes Token Ring o FDDI, con frecuencia es necesario especificar si los equipos pueden utilizar la longitud máxima o un tamaño inferior para permitir el uso de puentes en la red.

En esta opción, el campo tipo tiene un valor de 5 y el de longitud, de 1.

=Mensajes estándar de Descubrimiento de vecinos =

Además de las cinco opciones básicas descritas en la tabla ''Utilización de las opciones en los mensajes de descubrimiento de vecinos'', existen otras específicas para la movilidad y para las redes NBMA (''Non Broadcast Multiple Access'').

{|
|+ Utilización de las opciones en los mensajes de descubrimiento de vecinos
| width = 150 | || width = 100 |[[#RS|Solicitud de]] || width = 100 |[[#RA|Anuncio de]] || width = 100 |[[#NS|Solicitud de]] ||width = 100 | [[#NA|Anuncio de]] ||width = 100 |[[#IR|Indicación de]]
|-
| || [[#RS|enrutador]] || [[#RA|enrutador]] || [[#NS|un vecino]] || [[#NA| un vecino]] || [[#IR|redirección]]
|-style="background:silver"
|[[#física |Dirección física de la fuente]] || presente || presente || presente || ||
|-
|[[# física | Dirección física del destino]] || || || || presente || presente
|-style="background:silver"
|[[#información|Información sobre el prefijo]] || || ≥ 1 || || ||
|-
|[[#redirigida |Cabecera de redirección]] || || || || || presente
|-style="background:silver"
| [[#MTU |MTU]] || || posible || || ||
|}

Las distintas funcionalidades de descubrimiento de vecinos utilizan cinco mensajes: dos para el diálogo entre un dispositivo y un enrutador, dos para el diálogo entre vecinos, y uno para la redirección. Cada uno de estos mensajes puede incluir opciones adicionales.

== <div id="RS">Solicitud de enrutador</div> ==

<tikz title="Formato de los paquetes de solicitud de enrutador">
\clip (0.2, 3.5) rectangle (11.1,7.1);
%\draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=133}};
\draw (2.9, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code =0 }};
\draw (5.3, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};
\draw (0.5, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Reserved}};

\draw (0.5, 4.25) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Options:\\
- Source link-layer address
}};
</tikz>

El mensaje de solicitud de enrutador (''cf'' figura Formato de los paquetes de solicitud de enrutador) es emitido al iniciar un dispositivo para recibir más rápidamente la información del enrutador. Este mensaje se envía a la dirección IPv6 multicast reservada a los enrutadores en el mismo enlace <tt>FF02::2</tt>. Si el dispositivo aún no conoce su dirección fuente, se utiliza la dirección no especificada.

El campo opción normalmente contiene la dirección física del dispositivo.

== <div id="RA">Anuncio de enrutador</div> ==

<tikz title="Formato de los paquetes de anuncio de enrutador">
\clip (0.2, 1.5) rectangle (11.1,7.1);
%\draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=134}};
\draw (2.9, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code =0 }};
\draw (5.3, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};

\draw (0.5, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Cur. Hop Lim.}};
\draw (2.9, 5.5) node (bitM) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{}; \draw (bitM.text) node {\tiny{M}};
\draw (3.2, 5.5) node (bitO) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{};\draw (bitO.text) node {\tiny{O}};
\draw (3.5, 5.5) node (bitH) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{};\draw (bitH.text) node {\tiny{H}};
\draw (3.8, 5.5) node (res) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=1.5cm]{\tiny{reserved}};
\draw (5.3, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Router Lifetime}};

\draw (0.5, 5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=9.6cm]{\tiny{Reachable Time}};
\draw (0.5, 4.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=9.6cm]{\tiny{Retrans Time}};

\draw (0.5, 3.25) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Options:\\
Source link-layer address\\
MTU\\
Prefix Information (may be repeated)\\
}};
</tikz>

Este mensaje (''cf'' figura ''Formato de los paquetes de anuncio de enrutador'') es emitido periódicamente por los enrutadores, o bien, en respuesta a un mensaje de solicitud de enrutador generado por un dispositivo. El campo dirección fuente contiene la dirección de enlace local del enrutador, mientras que el campo dirección destino contiene la dirección del dispositivo que generó la solicitud, o la dirección de todas las estaciones (<tt>ff02::01</tt>).

Cuando el campo de máximo número de saltos tiene un valor distinto de cero, muestra el valor que podría colocarse en el campo de número de saltos de los paquetes emitidos. El bit <tt>M</tt> indica que una dirección del dispositivo debe ser obtenida mediante un protocolo de configuración (''cf'' [[Configuración con estado:DHCPv6]]). El bit <tt>O</tt> también indica la presencia de un servicio de configuración para obtener información adicional a la dirección. Si no es posible obtener la dirección mediante un servidor, el dispositivo procede a realizar una configuración sin estado, concatenando su identificador de interfaz a los prefijos que conoce. El bit <tt>H</tt> indica que el enrutador puede ser utilizado como agente base por un nodo móvil (''cf'' [[Desplazamientos_de_móviles#Anuncio_del_agente_base |Anuncio del agente base]]).

El campo tiempo de vida del enrutador indica el período (en segundos) durante el cual el equipo que emite el anuncio realizará funciones de enrutador por omisión. El valor máximo corresponde a 18 horas 12 minutos, pero como este mensaje se emite periódicamente, en la práctica no existe un límite para el tiempo de vida de un enrutador. Un valor de <tt>0</tt> indica que el dispositivo no cumple con las funciones de enrutador por omisión. Este tiempo de vida no se aplica a las opciones transportadas por este mensaje.

El campo duración de accesibilidad indica el período (en milisegundos) durante el cual una información almacenada en la memoria caché de la máquina (por ejemplo, la tabla de correspondencia entre las direcciones IPv6 y las físicas) puede ser considerada como válida. Al vencimiento de este tiempo, se emite un mensaje de detección de inaccesibilidad para verificar la pertinencia de la información almacenada.

El campo temporización de retransmisión muestra el período (en milisegundos) entre dos emisiones no solicitadas de este mensaje. Permite que los demás equipos puedan detectar la inaccesibilidad de un enrutador.

Este mensaje puede transportar las siguientes opciones:

* dirección física de la fuente,
* MTU,
* información sobre el prefijo (uno o varios).

== <div Id="NS"> Solicitud de un vecino </div> ==

<tikz title="Formato de los paquetes de solicitud de un vecino">

\clip (0.2, 1.5) rectangle (11.1,7.1);
%\draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=135}};
\draw (2.9, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code =0 }};
\draw (5.3, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};

\draw (0.5, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=9.6cm]{\tiny{Reserved}};

\draw (0.5, 4.25) node (context) [right, shade, top color=blue!50, bottom color=blue=!10, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Target Address}};

\draw (0.5, 2.25) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Options:\\
Source link-layer address\\
}};
</tikz>

Este mensaje (''cf'' figura ''Formato de los paquetes de solicitud de un vecino'') permite obtener información a partir de un equipo vecino, es decir, localizado en el mismo enlace físico (o conectado a través de puentes). El mensaje puede ser emitido explícitamente a él, o enviado con una dirección de difusión. En el caso de determinación de la dirección física, éste corresponde a la solicitud de ARP en IPv4.

El campo dirección fuente del paquete IPv6 contiene ya sea la dirección local al enlace, una dirección global o la dirección no especificada. El campo destino puede contener la dirección de difusión múltiple solicitada correspondiente a la dirección buscada (''cf'' [[Direccionamiento_multicast#Identificador_de_grupo|Identificador de grupo]]) o la dirección del dispositivo (en el caso de una detección de inaccesibilidad de vecinos, ''NUD'').

El campo dirección del destino contiene la dirección IPv6 del equipo buscado. El campo opción generalmente contiene la dirección física de la fuente.

== <div Id="NA"> Anuncio de un vecino</div> ==

<tikz title="Formato de los paquetes de anuncio de un vecino">

\clip (0.2, 1.5) rectangle (11.1,7.1);
%\draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=136}};
\draw (2.9, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code =0 }};
\draw (5.3, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};

\draw (0.5, 5.5) node (bitR) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{}; \draw (bitR.text) node {\tiny{R}};
\draw (0.8, 5.5) node (bitS) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{}; \draw (bitS.text) node {\tiny{S}};
\draw (1.1, 5.5) node (bitO) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{}; \draw (bitO.text) node {\tiny{O}};
\draw (1.4, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=8.7cm]{\tiny{Reserved}};

\draw (0.5, 4.25) node (context) [right, shade, top color=blue!50, bottom color=blue=!10, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Target Address}};

\draw (0.5, 2.25) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Options:\\
Source link-layer address\\
}};
</tikz>

Este mensaje (''cf'' figura ''Formato de los paquetes de anuncio de un vecino'') se emite en respuesta a una solicitud, aunque también puede ser emitido de forma espontánea para propagar la información de cambio de dirección física, o del estado de "enrutador". Para el caso de la determinación de la dirección física, es equivalente a la respuesta ARP en IPv4.

* El bit <tt> R </tt> se pone a 1 si el remitente es un enrutador. Este bit se utiliza para permitir la detección de un enrutador que se convierte en un equipo ordinario.
* El bit <tt> S </tt> en 1 indica que este anuncio se emite en respuesta a una solicitud.
* El bit <tt> O </tt> en 1 indica que este anuncio debe borrar las informaciones anteriores que se encuentran almacenadas en la memoria cachés de otros equipos, en especial la tabla que contiene las direcciones físicas.
* El campo dirección del destino contiene, si el bit<tt> S </tt> es 1, el valor del campo dirección del destino de la solicitud a la que está respondiendo este mensaje. Si el bit <tt> S </tt> es 0, este campo contiene la dirección IPv6 local al enlace del equipo emisor.
* La opción dirección física del destino contiene la dirección física del emisor.

== <div id="IR">Indicación de redirección</div> ==

<tikz title="Formato de los paquetes de indicación de redirección">
\clip (0.2, 0) rectangle (11.1,7.1);
%\draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=137}};
\draw (2.9, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code =0 }};
\draw (5.3, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};

\draw (0.5, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=9.6cm]{\tiny{Reserved}};

\draw (0.5, 4.25) node (context) [right, shade, top color=blue!50, bottom color=blue=!10, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Target Address}};

\draw (0.5, 2.25) node (context) [right, shade, top color=blue!50, bottom color=blue=!10, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Destination Address}};

\draw (0.5, 0.5) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=1.5cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Options:\\
Target link-layer address\\
Redirected Header\\
}};
</tikz>

La técnica de redirección es la misma que en IPv4. Un dispositivo sólo conoce los prefijos de las redes a las que está conectado directamente y la dirección de un enrutador por omisión. Si la ruta se puede optimizar, el enrutador por omisión envía un mensaje para indicar que existe un camino más corto. De hecho, como en IPv6 el enrutador por omisión se establece de forma automática, las rutas no necesariamente son las mejores (''cf'' figura ''Enrutamiento por omisión no óptimo'').

Otro caso particular en IPv6 ocurre con los dispositivos que se encuentran en el mismo enlace físico, pero tienen diferentes prefijos. La comunicación entre ellos pasa inicialmente a traves de enrutador por omisión hasta que éste notifica que existe una ruta directa entre ellos.

La figura ''Formato de los paquetes de indicación de redirección'' muestra el formato del mensaje:

* El campo dirección objetivo (''Target address'') contiene la dirección IPv6 del equipo hacia el que los paquetes deben ser enviados.
* El campo dirección destino contiene la dirección IPv6 del dispositivo que está siendo redirigido hacia la dirección objetivo.

Cuando la redirección apunta a un dispositivo situado en el mismo enlace, la dirección objetivo y de destino son las mismas.

Las opciones incluyen la dirección física de un nuevo enrutador y la cabecera del paquete redirigido.

Este mensaje se puede utilizar de la misma forma que en IPv4. Un dispositivo solamente tiene una ruta por omisión para acceder a equipos con un prefijo diferente. En consecuencia, envía su paquete al enrutador por omisión, quien observa que el prefijo destino es accesible a través de la misma subred que el emisor. El enrutador por omisión reenvía el paquete y notifica al emisor que puede contactar directamente a las máquinas que poseen el prefijo del destino.

IPv6 también utiliza este mensaje para optimizar la resolución fuera del enlace para el [[#Caso de redes NBMA |caso de redes NBMA]].

= Configuración automática =
Tradicionalmente, la configuración de una interfaz de red de una máquina se hacía manualmente. Esto suele ser un trabajo lento y propenso a errores. Con IPv6, se automatiza el proceso de configuración y se introducen, al mismo tiempo, mecanismos de funcionamiento inmediato (''plug and play'') a la interfaz de red. La configuración automática significa que un dispositivo obtendrá toda la información necesaria para su conexión a una red local IP sin ninguna intervención humana. En el caso ideal, cualquier usuario desempaca su nuevo equipo, lo conecta a la red local y lo ve funcionar sin tener que introducir la información propia de "especialistas". Ahora vamos a discutir otro aspecto de la configuración automática de IPv6, la auto-configuración de direcciones, que tiene como objetivos:

* La adquisición de una dirección cuando un dispositivo está conectado a una red por primera vez;
* la posibilidad de asignar otros prefijos, o de renumerar un dispositivo.

El proceso de configuración automática de direcciones IPv6 incluye la creación de una dirección local al enlace, la agregación a grupos multicast solicitados, la verificación de la unicidad de la dirección local al enlace y la creación de direcciones unicast global.

La tarea del enrutador es importante en la configuración automática. Indica a la máquina, mediante los bits de la cabecera (''cf'' [[#RA|anuncio de enrutador]]), del mensaje de anuncio de los enrutadores, el método a conservar y eventualmente proporcionar la información necesaria para su configuración. El bit <tt> M </tt> (''configuración de dirección administrada'') puesto a 1 indica que el equipo no debe crear por sí mismo una dirección a partir de su identificador de interfaz y de los prefijos recibidos, sino que debe solicitarla explícitamente ante un servidor de direcciones. El bit O <tt> </tt> (''otra configuración de estado'') indica que el dispositivo debe consultar el servidor para obtener otros parámetros distintos de la dirección. El algoritmo para el proceso de configuración automática de direcciones se desglosa de la siguiente manera:

* La primera fase consiste en crear la dirección local al enlace.
* Una vez que la unicidad de esta dirección es verificada, el dispositivo está listo para comunicarse con otras máquinas en el enlace.
* El dispositivo debe tratar de adquirir un mensaje de anuncio de enrutadores para determinar el método de obtención de la dirección unicast global.
* Si hay un enrutador en el enlace, el dispositivo debe aplicar el método especificado por el mensaje de anuncio de enrutadores, a saber:
** La configuración automática sin estado,
** la configuración automática con estado.
* Si no hay ningún enrutador en el enlace, el dispositivo debe tratar de obtener la dirección unicast global por el método de configuración automática con estado. Si el intento falla, no hay más que hacer. Las comunicaciones sólo podrán hacerse sobre el enlace con la dirección local al enlace, pues el dispositivo no tendrá una dirección con la cobertura necesaria que le permita comunicarse con otras máquinas fuera del enlace.

==Ciclo de vida de una dirección==

Al generalizar en IPv6 el plan de direccionamiento CIDR, los prefijos quedan, en todos los casos, siendo propiedad de los operadores. Ya no pueden otorgarse "a perpetuidad" a los dispositivos. Para facilitar la renumeración de una máquina, la asignación de una dirección a una interfaz es temporal, las direcciones IPv6 no se entregan, sino que se prestan. Se asocia un tiempo de vida a la dirección, que indica el tiempo durante el cual la dirección pertenece a la interfaz. Cuando el tiempo de vida se ha agotada, la dirección deja de ser válida, se suprime de la interfaz y queda potencialmente éste puede prolongarse indefinidamente. La dirección local al enlace tiene un tiempo de vida ilimitado.

<tikz title="Estados sucesivos de una dirección en una interfaz">

\draw [thick, ->] (0,2) -- (9.5,2);

\draw [->] (1,4) node [above=10pt] {\tiny{allocation}}-- (1,2);
\draw (1, 2) node [rectangle, minimum width=1cm, minimum height=1cm, fill, left color=black!10, right color=black!20, draw=black, above right] (tentative) {};
\draw (tentative.south east) node [rectangle, minimum width=3cm, minimum height=1cm, fill, left color=green, right color=green!50, draw=black, above right] (preferred) {};
\draw (preferred.south east) node [rectangle, minimum width=2cm, minimum height=1cm, fill, left color=orange , right color=orange!50!red, draw=black, above right] (deprecated) {};
\draw (deprecated.south east) node [rectangle, minimum width=2cm, minimum height=1cm, fill, color=red, draw=black, above right] (novalid) {};

\draw (tentative.text) node {\tiny{Tentative}};
\draw (preferred.text) node {\tiny{Preferred}};
\draw (deprecated.text) node {\tiny{Deprecated}};
\draw (novalid.text) node {\tiny{Invalid}};

\draw [dotted] (tentative.south west) -- +(0, -1);
\draw [dotted] (preferred.south west) -- +(0, -1);
\draw [dotted] (deprecated.south west) -- +(0, -1);
\draw [dotted] (novalid.south west) -- +(0, -1);

\draw [dashed, <->] ([yshift=-0.5cm]tentative.south west) -- node [above] {\tiny{DAD}} ([yshift=-0.5cm] preferred.south west) ;

\draw [dashed, <->] ([yshift=-0.5cm]preferred.south west) -- node [above] {\tiny{Valid}} ([yshift=-0.5cm] novalid.south west) ;

</tikz>

La renumeración de una interfaz consiste en pasar de una dirección a otra. Durante una renumeración, no es aconsejable cambiar repentinamente de dirección, de lo contrario, todas las comunicaciones TCP que la utilizan como identificador de conexión, se cortarían inmediatamente. Esto conllevaría importantes perturbaciones a nivel de las aplicaciones.

Por ello, para facilitar esta transición se implementó un mecanismo de obsolescencia que invalida gradualmente una dirección. Este mecanismo se sirve de la capacidad de asignación de varias direcciones válidas a una misma interfaz. Para elegir la dirección a utilizar, se le asocia un estado que indica en qué fase de su tiempo de vida se encuentra con respecto a la interfaz. El primero de esos estados se conoce como preferido: no hay ninguna restricción de uso. Poco antes de su invalidación, la dirección pasa a un estado de depreciado. En él se desaconseja el uso de la dirección, pero no está prohibido. Una dirección depreciada ya no debe ser utilizada como dirección fuente de nuevas comunicaciones (como el establecimiento de conexión TCP), pero todavía puede emplearse como dirección fuente de comunicaciones ya establecidas. Los paquetes recibidos a una dirección depreciada seguirán siendo entregados normalmente. El control de la duración de cada estad de una dirección válida se efectúa agregando un tiempo de vida al estado preferido.
La figura '''Estados sucesivos de una dirección en una interfaz''' representa los diferentes estados que toma una dirección cuando se asigna a una interfaz.

== Creación de la dirección local al enlace ==

<tikz title=" Creación de la dirección local al enlace">
\clip (0, 0) rectangle (10,7);
% \draw[help lines] (0,0) grid (10,7 );

\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,3)--(9,3);

\pgfputat{\pgfxy(0.8,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,5)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,3)--(1.5,5);
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (8,3)--(8,5);

\draw (1.5,4.5) node {\small{FE80::IID1}};
\draw (1.5,4) node {\small{$\alpha$::IID1/64}};

\draw (8, 4.5) node {\small{FE80::IID2}};

</tikz>

Durante la inicialización de la interfaz, el dispositivo construye un identificador de interfaz que debe ser único en el enlace. Este identificador se utiliza la dirección de [[ Identificador_de_interfaz#EUI-64 | EUI-64]]. El principio básico para crear la direcciónIPv6 consiste en unir un prefijo con el identificador. La dirección local al enlace se crea tomando el prefijo de Enlace_local (<tt>FE80::/64</tt>). La dirección creada de esa manera, todavía no puede ser utilizada; tiene un estado temporal pues el dispositivo debe comprobar la exclusividad de esta dirección en el enlace mediante el procedimiento de detección de direcciones duplicadas. Si se encuentra que la dirección local al enlace no es única, se suspende la autoconfiguración y será necesario proceder a una configuración manual.

Una vez que se ha asegurado la unicidad de la dirección local al enlace, ésta se considera una dirección válida para la interfaz, con lo que termina la prima fase del proceso de autoconfiguración.

==<div id="DAD"> Detección de una dirección duplicada </div>==

<tikz title="Emisión de un NS en una detección de Dir. duplicada (DAD)">
\clip (0, 0) rectangle (10,7);
% \draw[help lines] (0,0) grid (10,7 );

\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,3)--(9,3);

\pgfputat{\pgfxy(0.8,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,5)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,3)--(1.5,5);
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (8,3)--(8,5);

\draw (7.8, 5) -- (7.8, 3.2);
\draw [<->] (1, 3.2) -- node [above] {\tiny{::/0 -$>$ solicited (FE80:IID2) : NS (who has FE80::IID2?)}}(9, 3.2) ;

</tikz>

Para comprobar la exclusividad de direcciones locales al enlace o de direcciones unicast, los dispositivos deben ejecutar un algoritmo de detección de direcciones duplicadas (DAD) antes poder utilizarlas. El algoritmo usa los mensajes ICMPv6 [[Protocolo_de_Descubrimiento_de_vecinos#NS|solicitud de un vecino]] y [[#NA|anuncio de un vecino.]] Si se detecta una dirección que ya está en uso, ésta no podrá ser asignada a la interfaz, la autoconfiguración automática debe suspenderse y será necesario proceder a una configuración manual. Durante la ejecución del algoritmo DAD, la dirección es considerada como "provisional" hasta tener la confirmación de su unicidad. Una dirección provisional se asigna a una interfaz únicamente para recibir los mensajes de solicitud y anuncio de un vecino. Otros mensajes recibidos, son ignorados. El algoritmo DAD consiste en enviar un mensaje de solicitud de un vecino colocando en el campo de dirección objetivo la dirección provisional. Para distinguir el algoritmo DAD del de Descubrimiento de vecinos, el paquete IPv6 que contiene un mensaje de solicitud de un vecino tiene como dirección fuente una dirección no determinada. Así se presentan tres casos:

* Se recibe un mensaje de anucio de un vecino: Significa que la dirección provisional está siendo utilizada como válida por otro dispositivo, por lo que ésta no es única y no puede ser retenida por el dispositivo.
* Se recibe un mensaje de solicitud de un vecino como parte del algoritmo DAD. La dirección provisional también es provisional para otra máquina. En este caso, la dirección provisional no puede ser utilizada por ninguna de ellas.
* No se recibe ningún mensaje durante un segundo (valor por omisión). La dirección provisional es única, por lo que su estado pasa de provisional a válida y se le asigna a la interfaz.

Obsérvese que este algoritmo no proporciona una fiabilidad absoluta, especialmente cuando el enlace está segmentado.

== Autoconfiguración sin estado ==

<tikz title="Emisión de un RS">
\clip (0, 0) rectangle (10,7);
% \draw[help lines] (0,0) grid (10,7 );

\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,3)--(9,3);

\pgfputat{\pgfxy(0.8,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,5)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,3)--(1.5,5);
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (8,3)--(8,5);

\draw (7.8, 5) -- (7.8, 3.2);
\draw [<->] (1, 3.2) -- node [above] {\tiny{FE80::IID2 -$>$ FF02::2 : RS }} (9, 3.2) ;

</tikz>

La configuración automática sin estado (RFC 2462) no requiere de ninguna configuración manual de los dispositivos, una configuración mínima para los enrutadores, y tampoco necesita de servidores adicionales. Se sirve del protocolo ICMPv6 y puede operar aún sin la presencia de enrutadores. En cambio, sí requiere de una subred con soporte a la difusión de paquetes. Este método sólo aplica para los dispositivos; no puede ser utilizada para configurar enrutadores. El principio básico de este mecanismo consiste en que una máquina genera su dirección IPv6 a partir de información local y de la proporcionada por un enrutador. El enrutador proporciona información sobre la subred asociada al enlace; anuncia el prefijo.

<tikz title="Recepción de un RA">
\clip (0, 0) rectangle (10,7);
% \draw[help lines] (0,0) grid (10,7 );

\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,3)--(9,3);

\pgfputat{\pgfxy(0.8,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,5)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,3)--(1.5,5);
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (8,3)--(8,5);

\draw [->] (1.7,5) -- (1.7, 3.2) -- node [above = 10pt] {\tiny{FE80::IID1 -$>$ FE80::IID2}} node [above] {\tiny{RA ($\alpha$::/64, DHCPv6, MTU=1500, HL=64, {bit {\tt M=1}) }}} (7.8, 3.2) -- (7.8, 5);

</tikz>

Al igual que para la creación de la dirección de enlace local, la dirección unicast global se obtiene al concatenar el prefijo con el identificador de la interfaz. El prefijo se obtiene del mensaje de anuncio de enrutador, más concretamente, de la opción de ''información sobre el prefijo''. Si bien debe verificarse la unicidad de todas las direcciones unicast, en el caso de una dirección unicast obtenida mediante la configuración automática sin estado, esto no es obligatorio, pues la unicidad del identificador de la interfaz ya fue comprobada durante la configuración de la dirección local al enlace. Dado que el identificador es el mismo, no puede haber ambigüedad sobre la exclusividad de la dirección unicast global creada de esta forma.

La renumeración de los dispositivos en un enlace se realiza mediante enrutadores que transfieren las direcciones utilizadas a un estado depreciado y al mismo tiempo anuncian el nuevo prefijo con el que los dispositivos pueden re-crear una dirección preferida.

===Caso de redes NBMA ===

<tikz title="Off Link NDP: Primera etapa">
\clip (0, 0) rectangle (11,7);
% \draw[help lines] (0,0) grid (10,7 );

\pgfputat{\pgfxy(4.5,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}
\pgfputat{\pgfxy(1.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[decorate,decoration={zigzag}, color=black!60, ->, very thick] (8,3)-- node [above, color=black] {\tiny{FE80::IID2 -$>$ FF02::2 : RS}} (5,5);

</tikz>

Las redes NBMA (''Non Broadcast Multiple Access'') se caracterizan por no contar con un mecanismo de difusión hacia todos los dispositivos. Esto conduce a dos situiaciones posibles:
* ausencia total de difusión, como en las redes públicas (telefónica, ATM, …) en las que un solo destinatario puede ser contactado a la vez
* posibilidad de difusión por un número limitado de equipos, como es el caso de las redes de radio tipo 3G, WiMAX, en las que la estación base tiene la posibilidad de difundir datos hacia todos los equipos, pero esto no es posible en el sentido inverso (desde un dispositivo).

<tikz title="Off Link NDP: Segunda etapa">
\clip (0, 0) rectangle (11,7);
% \draw[help lines] (0,0) grid (10,7 );

\pgfputat{\pgfxy(4.5,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}
\pgfputat{\pgfxy(1.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[decorate,decoration={zigzag}, color=black!60, ->, very thick] (5, 5)-- node [above, color=black] {\tiny{RA ($\alpha$::/64, DHCPv6, OffLink, MTU=1500, HL=64, {bit {\tt M=1}})}} (8,3);

</tikz>

Un comportamiento de redes NBMA también puede ser deseable para limitar las restricciones de consumo energético. Por ejemplo, en el caso de redes de sensores, la difusión, o la difusión restringida (multicast) son costosas en consumo de energía pues todos los dispositivos deben procesar el mensaje y algunos deberán retransmitirlo.

<tikz title="Off Link NDP: Tercera etapa">
\clip (0, 0) rectangle (11,7);
% \draw[help lines] (0,0) grid (10,7 );

\pgfputat{\pgfxy(4.5,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}
\pgfputat{\pgfxy(1.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[decorate,decoration={zigzag}, color=black!60, ->, very thick] (8,3)-- node [left, near start, color=black] {\tiny{$\alpha$::IID2 -$>$ $\alpha$::IID3 : DATA}} (5,5);

\draw[decorate,decoration={zigzag}, color=black!60, ->, very thick] (5,5)-- node [left, midway, color=black] {\tiny{$\alpha$::IID2 -$>$ $\alpha$::IID3 : DATA}} (2,3);

</tikz>

Para estos casos, el protocolo de descubrimiento de vecinos cuenta con un modo NBMA llamado también ''OffLink'', el cual solamente autoriza el diálogo con un enrutador. Los intercambios comienzan de la misma forma:
* El dispositivo que desea insertarse en la red, emite un mensaje RS (''Router Sollicitation'') utilizando la dirección destino FF02::2 (todos los enrutadores sobre el enlace. La red NBMA deberá enviar este mensaje hacia un enrutador.
* El enrutador responde poniendo el bit <tt>L</tt> (OffLink) a 1 en la opción [[#información|Información sobre el prefijo]], indicando que todos los intercambios deben pasar por él.
* El dispositivo construye su dirección global concatenando el prefijo a su identificador de interfaz.
* El dispositivo envía sistemáticamente todos los paquetes a la dirección física del enrutador. Éste, que tiene una visión global de la red, los reenvía hacia el destinatario apropiado.

<tikz title="Off Link NDP: Cuarta etapa (opcional)">
\clip (0, 0) rectangle (11,7);
% \draw[help lines] (0,0) grid (10,7 );

\pgfputat{\pgfxy(4.5,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}
\pgfputat{\pgfxy(1.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[decorate,decoration={zigzag}, color=black!60, ->, very thick] (8,3)-- node [left, near end, color=black] {\tiny{$\alpha$::IID2 -$>$ $\alpha$::IID3 : DATA}} (5,5);

\draw[decorate,decoration={zigzag}, color=black!60, ->, very thick] (5,5)-- node [left, midway, color=black] {\tiny{$\alpha$::IID2 -$>$ $\alpha$::IID3 : DATA}} (2,3);

\draw[decorate,decoration={triangles}, color=black!60, ->, thick, ] (5,5) to [bend left] node [right, near start, color=black] {\tiny{REDIRECT $\alpha$::IID3 : MAC3}} (8,3);

\draw [color=black!60, ->, very thick, dotted] (8,3)-- node [above, midway, color=black] {\tiny{$\alpha$::IID2 -$>$ $\alpha$::IID3 : DATA}} (2,3);

</tikz>

* Si la tecnología del enlace lo permite y si la política de gestión de red lo autoriza, el enrutador tiene la posibilidad de optimizar el tráfico, notificando al dispositivo la verdadera dirección del destinatario, emitiendo un mensaje de [[#IR|indicación de redirección]] (''ICMP Redirect''). Los paquetes subsecuentes ya no pasarán por el enrutador.

===Caso de redes móviles===

La detección de duplicación de direcciones es un proceso relativamente largo, pues un dispositivo que desea garantizar la unicidad de su dirección, debe emitir un mensaje NS y esperar que no haya respuesta. Además, dado que es posible que la red pierda los mensajes NS, el dispositivo podría intentar varias veces de resolver su propia dirección antes de garantizar su unicidad. Por último, el mismo proceso se repite para las direcciones de enlace local y unicast global. En consecuencia, se requiere de varios segundos antes de que un dispositivo pueda emitir paquetes hacia la red. Para equipos móviles, este retardo, que se suma a los de descubierta de vecinos y a la autentificación, puede conducir a interrupciones de conectividad (por ejemplo, para aplicaciones de voz sobre IP).

El RFC 4429 flexibiliza esta situación al permitir que un sitio utilice su dirección aún si no se ha garantizado su unicidad. Este comportamiento es llamado DAD optimista (''optimistic DAD''). El estado tentativo (ver [[#Ciclo de vida de una dirección| Ciclo de vida de una dirección]] se remplaza por un estado ''optimista'' durante el cual la exclusividad de la dirección no está garantizada pero se permite su uso. Paralelamente, se emite un DAD clásico. Los mensajes NS se emiten con el bit <tt>O</tt> (''Override'') apagado para que los caches de ND no se actualicen en caso de que esa dirección ya existiera en la red.

==Descubrimiento de MTU==

<tikz title="Descubrimiento de MTU primera fase: envío de un paquete demasiado grande">
\clip (0, 0) rectangle (11,8);
%\draw[help lines] (0,0) grid (10,7 );

\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,2)--(9,2);

\pgfputat{\pgfxy(0.8,3)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,3)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,2)--(1.5,3);
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (8,2)--(8,3);

\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,4)--(1.5,5);
\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,5)--(9,5);
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (5.5,5)--(5.5,6);
\pgfputat{\pgfxy(5,6)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}
\draw (8, 3.6) node {\small{A}};
\draw (5.5, 6.6) node {\small{B}};
\draw (1.5, 3.6) node {\small{R}};

\draw (1.5,1.5) node {\small{MTU=1500}};
\draw (1.5,5.5) node {\small{MTU=1280}};

\draw (9.5, 3.5) node {\tiny{PMTU(*)=1500}};

\draw [<-] (1.7,3) -- (1.7, 2.2) -- node [above = 10pt] { \tiny{A-$>$ B Size=1500}} (7.8, 2.2) -- (7.8, 3);
}
</tikz>

Por razones de eficacia, generalmente es preferible que la información intercambiada entre dispositivos esté contenida en datagramas de tamaño máximo. Este tamaño depende de la ruta seguida por los datagramas y es igual al tamaño más grande autorizado por el conjunto de enlaces recorridos. Se le llama PMTU, ''Path Maximum Transmission Unit'' (Unidad de transferencia de tamaño máximo sobre la trayectoria).

Inicialmente, el dispositivo supone que el PMTU de una cierta trayectoria es igual al MTU del enlace al que está directamente conectado. Si sucede que los paquetes enviados por ese camino exceden el tamaño máximo autorizado por un enlace intermedio, el enrutador correspondiente eliminará esos paquetes y enviará un mensaje de error ICMPv6 tipo “paquete demasiado grande” donde indicará el MTU aceptable. Con esa información, el dispositivo reducirá el PMTU apropiado para esa ruta.

Es posible que se deban efectuar varias iteraciones antes de obtener el PMTU que permita que los paquetes lleguen a su destino sin exceder el MTU de cada enlace recorrido. El protocolo IPv6 garantiza que el MTU de todos los enlaces no puede ser menor de 1,280 octetos, por lo que éste es el umbral mínimo para el PMTU. Dado que este protocolo puede sufrir pérdidas de paquetes, se deja a las capas superiores gestionar la fiabilidad de la comunicación y restransmitir paquetes si es necesario (paquete 6 del ejemplo).

<tikz title=" Descubrimiento de MTU segunda fase: recepción de un mensaje ICMPv6">
\clip (0, 0) rectangle (11,8);
%\draw[help lines] (0,0) grid (10,7 );

\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,2)--(9,2);

\pgfputat{\pgfxy(0.8,3)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,3)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,2)--(1.5,3);
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (8,2)--(8,3);

\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,4)--(1.5,5);
\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,5)--(9,5);
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (5.5,5)--(5.5,6);
\pgfputat{\pgfxy(5,6)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}
\draw (8, 3.6) node {\small{A}};
\draw (5.5, 6.6) node {\small{B}};
\draw (1.5, 3.6) node {\small{R}};

\draw (1.5,1.5) node {\small{MTU=1500}};
\draw (1.5,5.5) node {\small{MTU=1280}};

\draw (9.5, 3.5) node {\tiny{PMTU(*)=1500}};

\draw [->] (1.7,3) -- (1.7, 2.2) -- node [above = 10pt] { \tiny{R-$>$ A ICMP6 Error: Packet too big}} node [above] {\tiny{MTU=1280}} (7.8, 2.2) -- (7.8, 3);
\draw (9.5, 3) node {\alert{\tiny{PMTU(B)=1280}}};

</tikz>

Si bien la determinación del PMTU se hace esencialmente durante los primeros intercambios entre los dispositivos comunicantes, es posible que pueda reactivarse durante una comunicación activa si, debido a un cambio de ruta, se debe recorrer un enlace con mayores restricciones de tamaño.

El emisor verifica también que el PMTU no ha aumentado enviando esporádicamente un paquete más grande. Si éste cruza la red sin problemas, el valor del PMTU se incrementará.

Cabe señalar que el algoritmo de descubrimiento de PMTU funciona igual para las comunicaciones punto a punto, o multipunto. En este último caso, el PMTU será el mínimo permitido para el conjunto de caminos hacia cada sitio destinatario del grupo de difusión.

La información de PMTU se utiliza de distintas formas dependiendo del ambiente en el que los datos a transmitir se segmentan:

* si se utiliza un protocolo tipo TCP, éste realizará la fragmentación de forma transparente a las aplicaciones en función de la información de PMTU que le comunique la capa IPv6.
* si se utiliza un protocolo tipo UDP, la responsabilidad de la fragmentación recaerá en una capa superior, eventualmente en la aplicación. Será necesario que ésta:
** (1) pueda informarse del valor de PMTU autorizado, aún si éste cambia posteriormente, y
** (2) pueda fragmentar los datos en consecuencia. Para que estas dos condiciones se cumplan, IPv6 ha retenido un mecanismo de fragmentación (ver [[eIPv6_QO#Fragmentación|fragmentación]]).

<tikz title=" Descubrimiento de MTU tercera fase: Emisión de un paquete de tamaño adecuado">
\clip (0, 0) rectangle (11,8);
%\draw[help lines] (0,0) grid (10,7 );

\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,2)--(9,2);

\pgfputat{\pgfxy(0.8,3)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,3)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,2)--(1.5,3);
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (8,2)--(8,3);

\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,4)--(1.5,5);
\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,5)--(9,5);
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (5.5,5)--(5.5,6);
\pgfputat{\pgfxy(5,6)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}
\draw (8, 3.6) node {\small{A}};
\draw (5.5, 6.6) node {\small{B}};
\draw (1.5, 3.6) node {\small{R}};

\draw (1.5,1.5) node {\small{MTU=1500}};
\draw (1.5,5.5) node {\small{MTU=1280}};

\draw (9.5, 3.5) node {\tiny{PMTU(*)=1500}};
\draw (9.5, 3) node {\alert{\tiny{PMTU(B)=1280}}};
\draw [<-] (1.7,3) -- (1.7, 2.2) -- node [above = 10pt] { \tiny{A-$>$ B Size=1280}} (7.8, 2.2) -- (7.8, 3);
\draw [->] (1.7,4) -- (1.7, 4.8) -- (5.3, 4.8) -- (5.3, 6);
</tikz>

Hay otro aspecto relacionado con la identificación de caminos para poder asociarles la información de PMTU. El implementador cuenta con varias posibilidades. Por ejemplo, puede identificar un camino por la dirección destino o por el identificador de flujo si este campo se utiliz, o por la ruta seguida en el caso en que ésta sea impuesta (ver [[Las extensiones#enrutamiento|enrutamiento]]).

Por último, se bien se recomienda encarecidamente que cada dispositivo implemente el mecanismo de detección de PMTU, éste no es obligatorio. Por lo tanto, un equipo que no cuente con él (por ejemplo, una ROM de arranque) deberá restringir el tamaño de los paquetes al mínimo permitido, es decir, 1,280 octetos.

{{eSuivi|Tabla de contenido|Incio del capítulo|DHCPv6|DHCPv6}}

Protocolo de Descubrimiento de vecinos

2012-07-07T01:17:14Z

Jincera: /* Descubrimiento de MTU */

Protocolo de Descubrimiento de vecinos

2012-07-07T01:15:01Z

Jincera: /* Descubrimiento de MTU */

{{eSuivi|Tabla de contenido|Incio del capítulo|DHCPv6|DHCPv6}}

__TOC__

El protocolo de descubrimiento de vecinos (NDP, ''Neighbor Discovery Protocol'') permite a un dispositivo integrarse en el ambiente local, es decir, el enlace sobre el cual se transmiten físicamente los paquetes IPv6. Permite establecer un diálogo con los equipos (estaciones y enrutadores) conectados sobre el mismo medio. No se pretende que un dispositivo conozca con exactitud la lista de todos los demás dispositivos conectados al enlace, sino de proveer un mecanismo para dialogar con quien necesite hacerlo.

El protocolo utiliza cinco tipos de mensajes ICMPv6 (ver Valores de los campos de tipo y código de ICMPv6). El campo número de saltos de la cabecera IPv6 contiene el valor 255. Este valor parece demasiado grande para datagramas que no debieran ser enrutados fuera del enlace físico. En realidad, si un equipo recibe un datagrama con un valor menor, significa que la información proviene de otra red y que ya ha atravesado al menos un enrutador. Por ello, los datagramas que tienen un valor diferente de 255 deben ser ignorados por el receptor.

{{Tableau eICMPv6}}

El protocolo realiza varias funciones:

* Resolución de direcciones. El principio es muy similar al del protocolo ARP de IPv4. La principal diferencia consiste en el uso de mensajes ICMPv6 estándar en lugar de definir otro protocolo de capa 3. Con esto se consigue una mayor flexibilidad de uso, especialmente en las redes que no soportan la difusión de mensajes. Al igual que en IPv4, el protocolo se encarga de construir tablas de correspondencia entre las direcciones IPv6 y las físicas.
* <div vecinos id="NUD"> Detección de inaccesibilidad de vecinos (NUD, ''Neighbor Unreachability Detection''). Esta función, que no existe en IPv4, permite eliminar de las tablas de configuración de un equipo, los vecinos que se han vuelto inaccesibles (por fallas, cambio de domicilio, ...). Si un enrutador deja de estar disponible, la tabla de enrutamiento puede ser modificada para considerar otra ruta. </div>
* Configuración. La configuración automática de los dispositivos es uno de los principales atractivos de IPv6. Se implementan varias funcionalidades del protocolo de descubrimiento de vecinos:
**Descubrimiento de enrutadores. Este protocolo permite que los dispositivos identifiquen a los enrutadores que se encuentran en su enlace físico. En IPv4, esta función la proporciona el protocolo ''ICMP Router Discovery''.
** Descubrimiento de prefijos. El dispositivo conoce el o los prefijos de red de acuerdo a los anuncios realizados por los enrutadores. Agregando su identificador de interfaz, el dispositivo construye su o sus direcciones IPv6. No hay un mecanismo equivalente para las direcciones IPv4 ya que son demasiado cortas para realizar la auto-configuración.
** Detección de direcciones duplicadas. Dado que las direcciones se configuran de forma automática, existen riesgos de error en caso de tener equipos con identificadores repetidos. Este protocolo verifica que ningún otro equipo en el enlace tiene la misma dirección IPv6. Esta función es una evolución del ARP gratuito en IPv4 emitido durante la inicialización de la interfaz.
** Descubrimiento de parámetros. Este protocolo permite que los dispositivos conozcan los distintos parámetros del enlace físico, por ejemplo, el tamaño de MTU, el número máximo de saltos permitido (valor original del campo número de saltos), si la configuración automática con estado (como [[Configuración con estado: DHCPv6|DHCPv6]]) está activa, etc. No existe un equivalente de esta funcionalidad en IPv4.
* Indicación de redirección. Este mensaje se utiliza cuando un enrutador conoce una trayectoria mejor (medida en número de saltos) para alcanzar un destino.
:En IPv4 una indicación de redireccionamiento sólo puede servir para corregir la dirección del enrutador utilizado para acceder a una máquina fuera de la red local. Los dispositivos deben conocer todas las direcciones correspondientes a equipos conectados en su propia red local.
:EnIPv6, la correspondencia entre prefijo y red local es menos rígida. Es de esperar que un dispositivo no conozca todos los prefijos de su red local (si ésta es compartida por varios prefijos), o que un prefijo se comparta entre varios enlaces (lo que corresponde a una generalización del modelo de redes lógicas IP sobre ATM). Bajo algunas configuraciones, la máquina emitirá sus paquetes al enrutador aún si el destinatario se encuentra en el mismo segmento que el emisor. En este caso, el enrutador emitirá un mensaje de redirección para que la continuación del diálogo entre ellos haga de manera directa (véanse los ejemplos [[#IR|Indicación de redirección]]).
:En el caso más extremo, podría imaginarse en IPv6 que un dispositivo puede ser configurado para comunicarse únicamente con su enrutador por omisión. ICMPv6 ''redirect'' puede utilizarse entonces, para informar al dispositivo de destinatarios ubicados en el mismo enlace.

En IPv6 se especifican dos métodos de autoconfiguración para las direcciones unicast global:

* Autoconfiguración sin estado (''stateless autoconfiguration'', RFC 2462). Se utiliza cuando no es necesaria una gestión administrativa de las direcciones asignadas dentro de un sitio. Estos mecanismos se describen más adelante en este capítulo.
* Autoconfiguración con estado (''statefull autoconfiguration''). Se utiliza cuando un sitio requiere de un control estricto de la asignación de direcciones (''cf'' [[Configuración con estado: DHCPv6 | DHCPv6]]).

Sin embargo, el uso de DHCPv6 para obtener la dirección se controla mediante el protocolo de descubrimiento de vecinos.

= Datos transmitidos por los mensajes =

La principal motivación detrás del Protocolo de Descubrimiento de vecinos es unificar varios protocolos existentes en IPv4. En particular, la mayor parte de los datos utiliza un formato de opciones común, lo que simplifica la implementación del protocolo. El formato contiene los campos: tipo, longitud (en palabras de 64 bits), y datos. La baja precisión de campo longitud, presentará un desperdicio de espacio, pero permite una alineación de las opciones en palabras de 64 bits, lo que permite un procesamiento optimizado.

{{NB-Opciones}}

== <div id="física">Dirección física de la fuente/destino</div> ==

<tikz title="Formato de la opción dirección física fuente/destino">
\clip (0.2, 5.7) rectangle (11.1,6.7);
% \draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=1/2}};
\draw (2.9, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{lenght }};
\draw (5.3, 6) node (addr) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Link Layer Address}};

\draw [draw=white, thick] (addr.north east) -- (addr.south east);
\draw [draw=white, thick] (addr.north east) -- +(-2, 0);
\draw [draw=white, thick] (addr.south east) -- +(-2, 0);

\draw [dashed] (addr.north east) -- (addr.south east);
\draw [dashed] (addr.north east) -- +(-2, 0);
\draw [dashed] (addr.south east) -- +(-2, 0);
</tikz>

La figura ''Formato de la opción dirección física fuente/destino'' presenta estas opciones. El tipo 1 designa la dirección física de la fuente y el tipo 2 la dirección del destino.

El campo ''length'' es el tamaño en palabras de 64 bits de la opción. Por lo tanto, para el caso de una dirección MAC con longitud de 6 octetos, contiene el valor 1.

El RFC 2464 define el formato para las direcciones MAC-48 utilizadas en las redes Ethernet y Wi-Fi. El RFC 4944 define el formato para las direcciones MAC-16 y MAC-64 utilizadas en las redes de sensores bajo la norma IEEE 802.15.4.

== <div id="información">Información sobre el prefijo</div> ==

<tikz title="Formato de la opción información sobre el prefijo">
\clip (0.2, 2) rectangle (11.1, 7);
% \draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=3}};
\draw (2.9, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{length =4 }};
\draw (5.3, 6) node (addr) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm] {\tiny{Prefix Length}};
\draw (7.7, 6) node (bitL) [right, shade, top color=blue!15, bottom color=blue!5,, draw, minimum height=0.5cm, minimum width=.3cm]{}; \draw (bitL.text) node {\tiny{L}};
\draw (8, 6) node (bitA) [right, shade, top color=blue!15, bottom color=blue!5,, draw, minimum height=0.5cm, minimum width=.3cm]{};\draw (bitA.text) node {\tiny{A}};
\draw (8.3, 6) node (bitR) [right, shade, top color=blue!15, bottom color=blue!5,, draw, minimum height=0.5cm, minimum width=.3cm]{};\draw (bitR.text) node {\tiny{R}};
\draw (8.6, 6) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=1.5cm] {\tiny{Reserved}};

\draw (0.5, 5.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Valid Lifetime}};

\draw (0.5, 5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Prefered Lifetime}};

\draw (0.5, 4.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Reserved}};

\draw (0.5, 4) node (addr1) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{}};
\draw (0.5, 3.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{}};
\draw (0.5, 3) node (addr3) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Prefix}};
\draw (0.5, 2.5) node (addr4) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{}};

\draw [color=blue!10, very thick] (addr1.south east) -- (addr1.south west);
\draw [color=blue!10, very thick] (addr2.south east) -- (addr2.south west);
\draw [color=blue!10, very thick] (addr3.south east) -- (addr3.south west);
</tikz>

Esta opción contiene las informaciones sobre el prefijo para permitir una configuración automática de los dispositivos. El campo tipo tiene el valor 3 y el de longitud, 4. La figura ''Formato de la opción información sobre el prefijo'' muestra el formato de esta opción:

* El campo ''Prefix lenght'' indica cuántos bits son significativos para el prefijo anunciado en un campo siguiente.
* El bit <tt>L</tt> indica, cuando vale 1, que el prefijo permite indicar que todos los demás dispositivos que comparten el mismo prefijo, están en el mismo enlace, por lo que el emisor puede contactarlos directamente. En caso contrario, el dispositivo envía el paquete hacia el enrutador. Si éste último sabe que el emisor puede contactar directamente al destinatario, emitirá un mensaje ICMPv6 de indicación de redirección.
* El bit <tt>A</tt> indica, cuando vale 1, que el prefijo anunciado puede utilizarse para formar la dirección del dispositivo.
* El bit <tt>R</tt>, indica, cuando vale 1, que el campo prefijo contiene la dirección global de un enrutador ''agente base''. Los bits de mayor peso aún pueden utilizarse para formar un prefijo.
* El campo duración de validez indica, en segundos, la duración durante la cual el prefijo es válido.
* El campo duración preferente indica la duración, en segundos, durante la cual una dirección formada con el protocolo de configuración sin estado se mantiene ''preferente'' (''cf'' [[Planes de direccionamiento|Tiempo de vida de las direcciones]]).

Para estos dos campos, un valor de <tt>0xffffffff</tt> representa una duración infinita. Estos campos pueden servir durante la fase de transición de un proveedor de acceso a otro; es decir, de un prefijo a otro.
* El campo reservado permite alinear el prefijo a una frontera de palabra de 64 bits.
* El campo prefijo contiene el valor de prefijo anunciado sobre el enlace. Para mantener una alineación de 64 bits para el resto de datos del paquete, este campo tiene una longitud fija de 128 bits.

== <div id="redirigida">Cabecera de redirección </div> ==

<tikz title="Formato de la opción cabecera de redirección">
\clip (0.2, 3.1) rectangle (11.1, 7);
% \draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=5}};
\draw (2.9, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{length =1 }};
\draw (5.3, 6) node (addr) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Reserved}};

\draw (0.5, 5.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Reserved}};

\draw (0.5, 4.25) node (context) [right, shade, top color=purple!50, bottom color=purple!10, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{IPv6 Header and Data}};
</tikz>

Esta opción es utilizada por el mensaje de indicación de redirección. Permite encapsular los primeros octetos del paquete IPv6 que provocó la emisión de este mensaje, como ocurre con los mensajes de error de ICMPv6.

El campo tipo tiene el valor 4. El tamaño de esta opción debe evitar que el paquete IPv6 rebase los 1280 octetos (''cf'' figura ''Formato de la opción cabecera de redirección''). Sin embargo, el paquete debe contener la mayor cantidad de información posible.

== <div id="MTU">MTU</div> ==

<tikz title="Formato de la opción MTU">

\clip (0.2, 5.1) rectangle (11.1, 7);
% \draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=5}};
\draw (2.9, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{lenght =1 }};
\draw (5.3, 6) node (addr) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Reserved}};

\draw (0.5, 5.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{MTU}};
</tikz>

Esta opción permite notificar a los dispositivos el tamaño máximo de datos que pueden ser transmitidos sobre el enlace. La figura ''Formato de la opción MTU'' muestra su estructura. No es necesario difundir esta información si el dispositivo utiliza siempre el tamaño máximo permitido. Por ejemplo, sobre las redes Ethernet, los dispositivos utilizarán el valor 1,500. En cambio, en las redes Token Ring o FDDI, con frecuencia es necesario especificar si los equipos pueden utilizar la longitud máxima o un tamaño inferior para permitir el uso de puentes en la red.

En esta opción, el campo tipo tiene un valor de 5 y el de longitud, de 1.

=Mensajes estándar de Descubrimiento de vecinos =

Además de las cinco opciones básicas descritas en la tabla ''Utilización de las opciones en los mensajes de descubrimiento de vecinos'', existen otras específicas para la movilidad y para las redes NBMA (''Non Broadcast Multiple Access'').

{|
|+ Utilización de las opciones en los mensajes de descubrimiento de vecinos
| width = 150 | || width = 100 |[[#RS|Solicitud de]] || width = 100 |[[#RA|Anuncio de]] || width = 100 |[[#NS|Solicitud de]] ||width = 100 | [[#NA|Anuncio de]] ||width = 100 |[[#IR|Indicación de]]
|-
| || [[#RS|enrutador]] || [[#RA|enrutador]] || [[#NS|un vecino]] || [[#NA| un vecino]] || [[#IR|redirección]]
|-style="background:silver"
|[[#física |Dirección física de la fuente]] || presente || presente || presente || ||
|-
|[[# física | Dirección física del destino]] || || || || presente || presente
|-style="background:silver"
|[[#información|Información sobre el prefijo]] || || ≥ 1 || || ||
|-
|[[#redirigida |Cabecera de redirección]] || || || || || presente
|-style="background:silver"
| [[#MTU |MTU]] || || posible || || ||
|}

Las distintas funcionalidades de descubrimiento de vecinos utilizan cinco mensajes: dos para el diálogo entre un dispositivo y un enrutador, dos para el diálogo entre vecinos, y uno para la redirección. Cada uno de estos mensajes puede incluir opciones adicionales.

== <div id="RS">Solicitud de enrutador</div> ==

<tikz title="Formato de los paquetes de solicitud de enrutador">
\clip (0.2, 3.5) rectangle (11.1,7.1);
%\draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=133}};
\draw (2.9, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code =0 }};
\draw (5.3, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};
\draw (0.5, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Reserved}};

\draw (0.5, 4.25) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Options:\\
- Source link-layer address
}};
</tikz>

El mensaje de solicitud de enrutador (''cf'' figura Formato de los paquetes de solicitud de enrutador) es emitido al iniciar un dispositivo para recibir más rápidamente la información del enrutador. Este mensaje se envía a la dirección IPv6 multicast reservada a los enrutadores en el mismo enlace <tt>FF02::2</tt>. Si el dispositivo aún no conoce su dirección fuente, se utiliza la dirección no especificada.

El campo opción normalmente contiene la dirección física del dispositivo.

== <div id="RA">Anuncio de enrutador</div> ==

<tikz title="Formato de los paquetes de anuncio de enrutador">
\clip (0.2, 1.5) rectangle (11.1,7.1);
%\draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=134}};
\draw (2.9, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code =0 }};
\draw (5.3, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};

\draw (0.5, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Cur. Hop Lim.}};
\draw (2.9, 5.5) node (bitM) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{}; \draw (bitM.text) node {\tiny{M}};
\draw (3.2, 5.5) node (bitO) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{};\draw (bitO.text) node {\tiny{O}};
\draw (3.5, 5.5) node (bitH) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{};\draw (bitH.text) node {\tiny{H}};
\draw (3.8, 5.5) node (res) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=1.5cm]{\tiny{reserved}};
\draw (5.3, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Router Lifetime}};

\draw (0.5, 5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=9.6cm]{\tiny{Reachable Time}};
\draw (0.5, 4.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=9.6cm]{\tiny{Retrans Time}};

\draw (0.5, 3.25) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Options:\\
Source link-layer address\\
MTU\\
Prefix Information (may be repeated)\\
}};
</tikz>

Este mensaje (''cf'' figura ''Formato de los paquetes de anuncio de enrutador'') es emitido periódicamente por los enrutadores, o bien, en respuesta a un mensaje de solicitud de enrutador generado por un dispositivo. El campo dirección fuente contiene la dirección de enlace local del enrutador, mientras que el campo dirección destino contiene la dirección del dispositivo que generó la solicitud, o la dirección de todas las estaciones (<tt>ff02::01</tt>).

Cuando el campo de máximo número de saltos tiene un valor distinto de cero, muestra el valor que podría colocarse en el campo de número de saltos de los paquetes emitidos. El bit <tt>M</tt> indica que una dirección del dispositivo debe ser obtenida mediante un protocolo de configuración (''cf'' [[Configuración con estado:DHCPv6]]). El bit <tt>O</tt> también indica la presencia de un servicio de configuración para obtener información adicional a la dirección. Si no es posible obtener la dirección mediante un servidor, el dispositivo procede a realizar una configuración sin estado, concatenando su identificador de interfaz a los prefijos que conoce. El bit <tt>H</tt> indica que el enrutador puede ser utilizado como agente base por un nodo móvil (''cf'' [[Desplazamientos_de_móviles#Anuncio_del_agente_base |Anuncio del agente base]]).

El campo tiempo de vida del enrutador indica el período (en segundos) durante el cual el equipo que emite el anuncio realizará funciones de enrutador por omisión. El valor máximo corresponde a 18 horas 12 minutos, pero como este mensaje se emite periódicamente, en la práctica no existe un límite para el tiempo de vida de un enrutador. Un valor de <tt>0</tt> indica que el dispositivo no cumple con las funciones de enrutador por omisión. Este tiempo de vida no se aplica a las opciones transportadas por este mensaje.

El campo duración de accesibilidad indica el período (en milisegundos) durante el cual una información almacenada en la memoria caché de la máquina (por ejemplo, la tabla de correspondencia entre las direcciones IPv6 y las físicas) puede ser considerada como válida. Al vencimiento de este tiempo, se emite un mensaje de detección de inaccesibilidad para verificar la pertinencia de la información almacenada.

El campo temporización de retransmisión muestra el período (en milisegundos) entre dos emisiones no solicitadas de este mensaje. Permite que los demás equipos puedan detectar la inaccesibilidad de un enrutador.

Este mensaje puede transportar las siguientes opciones:

* dirección física de la fuente,
* MTU,
* información sobre el prefijo (uno o varios).

== <div Id="NS"> Solicitud de un vecino </div> ==

<tikz title="Formato de los paquetes de solicitud de un vecino">

\clip (0.2, 1.5) rectangle (11.1,7.1);
%\draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=135}};
\draw (2.9, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code =0 }};
\draw (5.3, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};

\draw (0.5, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=9.6cm]{\tiny{Reserved}};

\draw (0.5, 4.25) node (context) [right, shade, top color=blue!50, bottom color=blue=!10, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Target Address}};

\draw (0.5, 2.25) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Options:\\
Source link-layer address\\
}};
</tikz>

Este mensaje (''cf'' figura ''Formato de los paquetes de solicitud de un vecino'') permite obtener información a partir de un equipo vecino, es decir, localizado en el mismo enlace físico (o conectado a través de puentes). El mensaje puede ser emitido explícitamente a él, o enviado con una dirección de difusión. En el caso de determinación de la dirección física, éste corresponde a la solicitud de ARP en IPv4.

El campo dirección fuente del paquete IPv6 contiene ya sea la dirección local al enlace, una dirección global o la dirección no especificada. El campo destino puede contener la dirección de difusión múltiple solicitada correspondiente a la dirección buscada (''cf'' [[Direccionamiento_multicast#Identificador_de_grupo|Identificador de grupo]]) o la dirección del dispositivo (en el caso de una detección de inaccesibilidad de vecinos, ''NUD'').

El campo dirección del destino contiene la dirección IPv6 del equipo buscado. El campo opción generalmente contiene la dirección física de la fuente.

== <div Id="NA"> Anuncio de un vecino</div> ==

<tikz title="Formato de los paquetes de anuncio de un vecino">

\clip (0.2, 1.5) rectangle (11.1,7.1);
%\draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=136}};
\draw (2.9, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code =0 }};
\draw (5.3, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};

\draw (0.5, 5.5) node (bitR) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{}; \draw (bitR.text) node {\tiny{R}};
\draw (0.8, 5.5) node (bitS) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{}; \draw (bitS.text) node {\tiny{S}};
\draw (1.1, 5.5) node (bitO) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{}; \draw (bitO.text) node {\tiny{O}};
\draw (1.4, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=8.7cm]{\tiny{Reserved}};

\draw (0.5, 4.25) node (context) [right, shade, top color=blue!50, bottom color=blue=!10, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Target Address}};

\draw (0.5, 2.25) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Options:\\
Source link-layer address\\
}};
</tikz>

Este mensaje (''cf'' figura ''Formato de los paquetes de anuncio de un vecino'') se emite en respuesta a una solicitud, aunque también puede ser emitido de forma espontánea para propagar la información de cambio de dirección física, o del estado de "enrutador". Para el caso de la determinación de la dirección física, es equivalente a la respuesta ARP en IPv4.

* El bit <tt> R </tt> se pone a 1 si el remitente es un enrutador. Este bit se utiliza para permitir la detección de un enrutador que se convierte en un equipo ordinario.
* El bit <tt> S </tt> en 1 indica que este anuncio se emite en respuesta a una solicitud.
* El bit <tt> O </tt> en 1 indica que este anuncio debe borrar las informaciones anteriores que se encuentran almacenadas en la memoria cachés de otros equipos, en especial la tabla que contiene las direcciones físicas.
* El campo dirección del destino contiene, si el bit<tt> S </tt> es 1, el valor del campo dirección del destino de la solicitud a la que está respondiendo este mensaje. Si el bit <tt> S </tt> es 0, este campo contiene la dirección IPv6 local al enlace del equipo emisor.
* La opción dirección física del destino contiene la dirección física del emisor.

== <div id="IR">Indicación de redirección</div> ==

<tikz title="Formato de los paquetes de indicación de redirección">
\clip (0.2, 0) rectangle (11.1,7.1);
%\draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=137}};
\draw (2.9, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code =0 }};
\draw (5.3, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};

\draw (0.5, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=9.6cm]{\tiny{Reserved}};

\draw (0.5, 4.25) node (context) [right, shade, top color=blue!50, bottom color=blue=!10, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Target Address}};

\draw (0.5, 2.25) node (context) [right, shade, top color=blue!50, bottom color=blue=!10, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Destination Address}};

\draw (0.5, 0.5) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=1.5cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Options:\\
Target link-layer address\\
Redirected Header\\
}};
</tikz>

La técnica de redirección es la misma que en IPv4. Un dispositivo sólo conoce los prefijos de las redes a las que está conectado directamente y la dirección de un enrutador por omisión. Si la ruta se puede optimizar, el enrutador por omisión envía un mensaje para indicar que existe un camino más corto. De hecho, como en IPv6 el enrutador por omisión se establece de forma automática, las rutas no necesariamente son las mejores (''cf'' figura ''Enrutamiento por omisión no óptimo'').

Otro caso particular en IPv6 ocurre con los dispositivos que se encuentran en el mismo enlace físico, pero tienen diferentes prefijos. La comunicación entre ellos pasa inicialmente a traves de enrutador por omisión hasta que éste notifica que existe una ruta directa entre ellos.

La figura ''Formato de los paquetes de indicación de redirección'' muestra el formato del mensaje:

* El campo dirección objetivo (''Target address'') contiene la dirección IPv6 del equipo hacia el que los paquetes deben ser enviados.
* El campo dirección destino contiene la dirección IPv6 del dispositivo que está siendo redirigido hacia la dirección objetivo.

Cuando la redirección apunta a un dispositivo situado en el mismo enlace, la dirección objetivo y de destino son las mismas.

Las opciones incluyen la dirección física de un nuevo enrutador y la cabecera del paquete redirigido.

Este mensaje se puede utilizar de la misma forma que en IPv4. Un dispositivo solamente tiene una ruta por omisión para acceder a equipos con un prefijo diferente. En consecuencia, envía su paquete al enrutador por omisión, quien observa que el prefijo destino es accesible a través de la misma subred que el emisor. El enrutador por omisión reenvía el paquete y notifica al emisor que puede contactar directamente a las máquinas que poseen el prefijo del destino.

IPv6 también utiliza este mensaje para optimizar la resolución fuera del enlace para el [[#Caso de redes NBMA |caso de redes NBMA]].

= Configuración automática =
Tradicionalmente, la configuración de una interfaz de red de una máquina se hacía manualmente. Esto suele ser un trabajo lento y propenso a errores. Con IPv6, se automatiza el proceso de configuración y se introducen, al mismo tiempo, mecanismos de funcionamiento inmediato (''plug and play'') a la interfaz de red. La configuración automática significa que un dispositivo obtendrá toda la información necesaria para su conexión a una red local IP sin ninguna intervención humana. En el caso ideal, cualquier usuario desempaca su nuevo equipo, lo conecta a la red local y lo ve funcionar sin tener que introducir la información propia de "especialistas". Ahora vamos a discutir otro aspecto de la configuración automática de IPv6, la auto-configuración de direcciones, que tiene como objetivos:

* La adquisición de una dirección cuando un dispositivo está conectado a una red por primera vez;
* la posibilidad de asignar otros prefijos, o de renumerar un dispositivo.

El proceso de configuración automática de direcciones IPv6 incluye la creación de una dirección local al enlace, la agregación a grupos multicast solicitados, la verificación de la unicidad de la dirección local al enlace y la creación de direcciones unicast global.

La tarea del enrutador es importante en la configuración automática. Indica a la máquina, mediante los bits de la cabecera (''cf'' [[#RA|anuncio de enrutador]]), del mensaje de anuncio de los enrutadores, el método a conservar y eventualmente proporcionar la información necesaria para su configuración. El bit <tt> M </tt> (''configuración de dirección administrada'') puesto a 1 indica que el equipo no debe crear por sí mismo una dirección a partir de su identificador de interfaz y de los prefijos recibidos, sino que debe solicitarla explícitamente ante un servidor de direcciones. El bit O <tt> </tt> (''otra configuración de estado'') indica que el dispositivo debe consultar el servidor para obtener otros parámetros distintos de la dirección. El algoritmo para el proceso de configuración automática de direcciones se desglosa de la siguiente manera:

* La primera fase consiste en crear la dirección local al enlace.
* Una vez que la unicidad de esta dirección es verificada, el dispositivo está listo para comunicarse con otras máquinas en el enlace.
* El dispositivo debe tratar de adquirir un mensaje de anuncio de enrutadores para determinar el método de obtención de la dirección unicast global.
* Si hay un enrutador en el enlace, el dispositivo debe aplicar el método especificado por el mensaje de anuncio de enrutadores, a saber:
** La configuración automática sin estado,
** la configuración automática con estado.
* Si no hay ningún enrutador en el enlace, el dispositivo debe tratar de obtener la dirección unicast global por el método de configuración automática con estado. Si el intento falla, no hay más que hacer. Las comunicaciones sólo podrán hacerse sobre el enlace con la dirección local al enlace, pues el dispositivo no tendrá una dirección con la cobertura necesaria que le permita comunicarse con otras máquinas fuera del enlace.

==Ciclo de vida de una dirección==

Al generalizar en IPv6 el plan de direccionamiento CIDR, los prefijos quedan, en todos los casos, siendo propiedad de los operadores. Ya no pueden otorgarse "a perpetuidad" a los dispositivos. Para facilitar la renumeración de una máquina, la asignación de una dirección a una interfaz es temporal, las direcciones IPv6 no se entregan, sino que se prestan. Se asocia un tiempo de vida a la dirección, que indica el tiempo durante el cual la dirección pertenece a la interfaz. Cuando el tiempo de vida se ha agotada, la dirección deja de ser válida, se suprime de la interfaz y queda potencialmente éste puede prolongarse indefinidamente. La dirección local al enlace tiene un tiempo de vida ilimitado.

<tikz title="Estados sucesivos de una dirección en una interfaz">

\draw [thick, ->] (0,2) -- (9.5,2);

\draw [->] (1,4) node [above=10pt] {\tiny{allocation}}-- (1,2);
\draw (1, 2) node [rectangle, minimum width=1cm, minimum height=1cm, fill, left color=black!10, right color=black!20, draw=black, above right] (tentative) {};
\draw (tentative.south east) node [rectangle, minimum width=3cm, minimum height=1cm, fill, left color=green, right color=green!50, draw=black, above right] (preferred) {};
\draw (preferred.south east) node [rectangle, minimum width=2cm, minimum height=1cm, fill, left color=orange , right color=orange!50!red, draw=black, above right] (deprecated) {};
\draw (deprecated.south east) node [rectangle, minimum width=2cm, minimum height=1cm, fill, color=red, draw=black, above right] (novalid) {};

\draw (tentative.text) node {\tiny{Tentative}};
\draw (preferred.text) node {\tiny{Preferred}};
\draw (deprecated.text) node {\tiny{Deprecated}};
\draw (novalid.text) node {\tiny{Invalid}};

\draw [dotted] (tentative.south west) -- +(0, -1);
\draw [dotted] (preferred.south west) -- +(0, -1);
\draw [dotted] (deprecated.south west) -- +(0, -1);
\draw [dotted] (novalid.south west) -- +(0, -1);

\draw [dashed, <->] ([yshift=-0.5cm]tentative.south west) -- node [above] {\tiny{DAD}} ([yshift=-0.5cm] preferred.south west) ;

\draw [dashed, <->] ([yshift=-0.5cm]preferred.south west) -- node [above] {\tiny{Valid}} ([yshift=-0.5cm] novalid.south west) ;

</tikz>

La renumeración de una interfaz consiste en pasar de una dirección a otra. Durante una renumeración, no es aconsejable cambiar repentinamente de dirección, de lo contrario, todas las comunicaciones TCP que la utilizan como identificador de conexión, se cortarían inmediatamente. Esto conllevaría importantes perturbaciones a nivel de las aplicaciones.

Por ello, para facilitar esta transición se implementó un mecanismo de obsolescencia que invalida gradualmente una dirección. Este mecanismo se sirve de la capacidad de asignación de varias direcciones válidas a una misma interfaz. Para elegir la dirección a utilizar, se le asocia un estado que indica en qué fase de su tiempo de vida se encuentra con respecto a la interfaz. El primero de esos estados se conoce como preferido: no hay ninguna restricción de uso. Poco antes de su invalidación, la dirección pasa a un estado de depreciado. En él se desaconseja el uso de la dirección, pero no está prohibido. Una dirección depreciada ya no debe ser utilizada como dirección fuente de nuevas comunicaciones (como el establecimiento de conexión TCP), pero todavía puede emplearse como dirección fuente de comunicaciones ya establecidas. Los paquetes recibidos a una dirección depreciada seguirán siendo entregados normalmente. El control de la duración de cada estad de una dirección válida se efectúa agregando un tiempo de vida al estado preferido.
La figura '''Estados sucesivos de una dirección en una interfaz''' representa los diferentes estados que toma una dirección cuando se asigna a una interfaz.

== Creación de la dirección local al enlace ==

<tikz title=" Creación de la dirección local al enlace">
\clip (0, 0) rectangle (10,7);
% \draw[help lines] (0,0) grid (10,7 );

\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,3)--(9,3);

\pgfputat{\pgfxy(0.8,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,5)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,3)--(1.5,5);
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (8,3)--(8,5);

\draw (1.5,4.5) node {\small{FE80::IID1}};
\draw (1.5,4) node {\small{$\alpha$::IID1/64}};

\draw (8, 4.5) node {\small{FE80::IID2}};

</tikz>

Durante la inicialización de la interfaz, el dispositivo construye un identificador de interfaz que debe ser único en el enlace. Este identificador se utiliza la dirección de [[ Identificador_de_interfaz#EUI-64 | EUI-64]]. El principio básico para crear la direcciónIPv6 consiste en unir un prefijo con el identificador. La dirección local al enlace se crea tomando el prefijo de Enlace_local (<tt>FE80::/64</tt>). La dirección creada de esa manera, todavía no puede ser utilizada; tiene un estado temporal pues el dispositivo debe comprobar la exclusividad de esta dirección en el enlace mediante el procedimiento de detección de direcciones duplicadas. Si se encuentra que la dirección local al enlace no es única, se suspende la autoconfiguración y será necesario proceder a una configuración manual.

Una vez que se ha asegurado la unicidad de la dirección local al enlace, ésta se considera una dirección válida para la interfaz, con lo que termina la prima fase del proceso de autoconfiguración.

==<div id="DAD"> Detección de una dirección duplicada </div>==

<tikz title="Emisión de un NS en una detección de Dir. duplicada (DAD)">
\clip (0, 0) rectangle (10,7);
% \draw[help lines] (0,0) grid (10,7 );

\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,3)--(9,3);

\pgfputat{\pgfxy(0.8,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,5)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,3)--(1.5,5);
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (8,3)--(8,5);

\draw (7.8, 5) -- (7.8, 3.2);
\draw [<->] (1, 3.2) -- node [above] {\tiny{::/0 -$>$ solicited (FE80:IID2) : NS (who has FE80::IID2?)}}(9, 3.2) ;

</tikz>

Para comprobar la exclusividad de direcciones locales al enlace o de direcciones unicast, los dispositivos deben ejecutar un algoritmo de detección de direcciones duplicadas (DAD) antes poder utilizarlas. El algoritmo usa los mensajes ICMPv6 [[Protocolo_de_Descubrimiento_de_vecinos#NS|solicitud de un vecino]] y [[#NA|anuncio de un vecino.]] Si se detecta una dirección que ya está en uso, ésta no podrá ser asignada a la interfaz, la autoconfiguración automática debe suspenderse y será necesario proceder a una configuración manual. Durante la ejecución del algoritmo DAD, la dirección es considerada como "provisional" hasta tener la confirmación de su unicidad. Una dirección provisional se asigna a una interfaz únicamente para recibir los mensajes de solicitud y anuncio de un vecino. Otros mensajes recibidos, son ignorados. El algoritmo DAD consiste en enviar un mensaje de solicitud de un vecino colocando en el campo de dirección objetivo la dirección provisional. Para distinguir el algoritmo DAD del de Descubrimiento de vecinos, el paquete IPv6 que contiene un mensaje de solicitud de un vecino tiene como dirección fuente una dirección no determinada. Así se presentan tres casos:

* Se recibe un mensaje de anucio de un vecino: Significa que la dirección provisional está siendo utilizada como válida por otro dispositivo, por lo que ésta no es única y no puede ser retenida por el dispositivo.
* Se recibe un mensaje de solicitud de un vecino como parte del algoritmo DAD. La dirección provisional también es provisional para otra máquina. En este caso, la dirección provisional no puede ser utilizada por ninguna de ellas.
* No se recibe ningún mensaje durante un segundo (valor por omisión). La dirección provisional es única, por lo que su estado pasa de provisional a válida y se le asigna a la interfaz.

Obsérvese que este algoritmo no proporciona una fiabilidad absoluta, especialmente cuando el enlace está segmentado.

== Autoconfiguración sin estado ==

<tikz title="Emisión de un RS">
\clip (0, 0) rectangle (10,7);
% \draw[help lines] (0,0) grid (10,7 );

\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,3)--(9,3);

\pgfputat{\pgfxy(0.8,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,5)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,3)--(1.5,5);
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (8,3)--(8,5);

\draw (7.8, 5) -- (7.8, 3.2);
\draw [<->] (1, 3.2) -- node [above] {\tiny{FE80::IID2 -$>$ FF02::2 : RS }} (9, 3.2) ;

</tikz>

La configuración automática sin estado (RFC 2462) no requiere de ninguna configuración manual de los dispositivos, una configuración mínima para los enrutadores, y tampoco necesita de servidores adicionales. Se sirve del protocolo ICMPv6 y puede operar aún sin la presencia de enrutadores. En cambio, sí requiere de una subred con soporte a la difusión de paquetes. Este método sólo aplica para los dispositivos; no puede ser utilizada para configurar enrutadores. El principio básico de este mecanismo consiste en que una máquina genera su dirección IPv6 a partir de información local y de la proporcionada por un enrutador. El enrutador proporciona información sobre la subred asociada al enlace; anuncia el prefijo.

<tikz title="Recepción de un RA">
\clip (0, 0) rectangle (10,7);
% \draw[help lines] (0,0) grid (10,7 );

\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,3)--(9,3);

\pgfputat{\pgfxy(0.8,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,5)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,3)--(1.5,5);
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (8,3)--(8,5);

\draw [->] (1.7,5) -- (1.7, 3.2) -- node [above = 10pt] {\tiny{FE80::IID1 -$>$ FE80::IID2}} node [above] {\tiny{RA ($\alpha$::/64, DHCPv6, MTU=1500, HL=64, {bit {\tt M=1}) }}} (7.8, 3.2) -- (7.8, 5);

</tikz>

Al igual que para la creación de la dirección de enlace local, la dirección unicast global se obtiene al concatenar el prefijo con el identificador de la interfaz. El prefijo se obtiene del mensaje de anuncio de enrutador, más concretamente, de la opción de ''información sobre el prefijo''. Si bien debe verificarse la unicidad de todas las direcciones unicast, en el caso de una dirección unicast obtenida mediante la configuración automática sin estado, esto no es obligatorio, pues la unicidad del identificador de la interfaz ya fue comprobada durante la configuración de la dirección local al enlace. Dado que el identificador es el mismo, no puede haber ambigüedad sobre la exclusividad de la dirección unicast global creada de esta forma.

La renumeración de los dispositivos en un enlace se realiza mediante enrutadores que transfieren las direcciones utilizadas a un estado depreciado y al mismo tiempo anuncian el nuevo prefijo con el que los dispositivos pueden re-crear una dirección preferida.

===Caso de redes NBMA ===

<tikz title="Off Link NDP: Primera etapa">
\clip (0, 0) rectangle (11,7);
% \draw[help lines] (0,0) grid (10,7 );

\pgfputat{\pgfxy(4.5,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}
\pgfputat{\pgfxy(1.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[decorate,decoration={zigzag}, color=black!60, ->, very thick] (8,3)-- node [above, color=black] {\tiny{FE80::IID2 -$>$ FF02::2 : RS}} (5,5);

</tikz>

Las redes NBMA (''Non Broadcast Multiple Access'') se caracterizan por no contar con un mecanismo de difusión hacia todos los dispositivos. Esto conduce a dos situiaciones posibles:
* ausencia total de difusión, como en las redes públicas (telefónica, ATM, …) en las que un solo destinatario puede ser contactado a la vez
* posibilidad de difusión por un número limitado de equipos, como es el caso de las redes de radio tipo 3G, WiMAX, en las que la estación base tiene la posibilidad de difundir datos hacia todos los equipos, pero esto no es posible en el sentido inverso (desde un dispositivo).

<tikz title="Off Link NDP: Segunda etapa">
\clip (0, 0) rectangle (11,7);
% \draw[help lines] (0,0) grid (10,7 );

\pgfputat{\pgfxy(4.5,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}
\pgfputat{\pgfxy(1.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[decorate,decoration={zigzag}, color=black!60, ->, very thick] (5, 5)-- node [above, color=black] {\tiny{RA ($\alpha$::/64, DHCPv6, OffLink, MTU=1500, HL=64, {bit {\tt M=1}})}} (8,3);

</tikz>

Un comportamiento de redes NBMA también puede ser deseable para limitar las restricciones de consumo energético. Por ejemplo, en el caso de redes de sensores, la difusión, o la difusión restringida (multicast) son costosas en consumo de energía pues todos los dispositivos deben procesar el mensaje y algunos deberán retransmitirlo.

<tikz title="Off Link NDP: Tercera etapa">
\clip (0, 0) rectangle (11,7);
% \draw[help lines] (0,0) grid (10,7 );

\pgfputat{\pgfxy(4.5,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}
\pgfputat{\pgfxy(1.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[decorate,decoration={zigzag}, color=black!60, ->, very thick] (8,3)-- node [left, near start, color=black] {\tiny{$\alpha$::IID2 -$>$ $\alpha$::IID3 : DATA}} (5,5);

\draw[decorate,decoration={zigzag}, color=black!60, ->, very thick] (5,5)-- node [left, midway, color=black] {\tiny{$\alpha$::IID2 -$>$ $\alpha$::IID3 : DATA}} (2,3);

</tikz>

Para estos casos, el protocolo de descubrimiento de vecinos cuenta con un modo NBMA llamado también ''OffLink'', el cual solamente autoriza el diálogo con un enrutador. Los intercambios comienzan de la misma forma:
* El dispositivo que desea insertarse en la red, emite un mensaje RS (''Router Sollicitation'') utilizando la dirección destino FF02::2 (todos los enrutadores sobre el enlace. La red NBMA deberá enviar este mensaje hacia un enrutador.
* El enrutador responde poniendo el bit <tt>L</tt> (OffLink) a 1 en la opción [[#información|Información sobre el prefijo]], indicando que todos los intercambios deben pasar por él.
* El dispositivo construye su dirección global concatenando el prefijo a su identificador de interfaz.
* El dispositivo envía sistemáticamente todos los paquetes a la dirección física del enrutador. Éste, que tiene una visión global de la red, los reenvía hacia el destinatario apropiado.

<tikz title="Off Link NDP: Cuarta etapa (opcional)">
\clip (0, 0) rectangle (11,7);
% \draw[help lines] (0,0) grid (10,7 );

\pgfputat{\pgfxy(4.5,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}
\pgfputat{\pgfxy(1.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[decorate,decoration={zigzag}, color=black!60, ->, very thick] (8,3)-- node [left, near end, color=black] {\tiny{$\alpha$::IID2 -$>$ $\alpha$::IID3 : DATA}} (5,5);

\draw[decorate,decoration={zigzag}, color=black!60, ->, very thick] (5,5)-- node [left, midway, color=black] {\tiny{$\alpha$::IID2 -$>$ $\alpha$::IID3 : DATA}} (2,3);

\draw[decorate,decoration={triangles}, color=black!60, ->, thick, ] (5,5) to [bend left] node [right, near start, color=black] {\tiny{REDIRECT $\alpha$::IID3 : MAC3}} (8,3);

\draw [color=black!60, ->, very thick, dotted] (8,3)-- node [above, midway, color=black] {\tiny{$\alpha$::IID2 -$>$ $\alpha$::IID3 : DATA}} (2,3);

</tikz>

* Si la tecnología del enlace lo permite y si la política de gestión de red lo autoriza, el enrutador tiene la posibilidad de optimizar el tráfico, notificando al dispositivo la verdadera dirección del destinatario, emitiendo un mensaje de [[#IR|indicación de redirección]] (''ICMP Redirect''). Los paquetes subsecuentes ya no pasarán por el enrutador.

===Caso de redes móviles===

La detección de duplicación de direcciones es un proceso relativamente largo, pues un dispositivo que desea garantizar la unicidad de su dirección, debe emitir un mensaje NS y esperar que no haya respuesta. Además, dado que es posible que la red pierda los mensajes NS, el dispositivo podría intentar varias veces de resolver su propia dirección antes de garantizar su unicidad. Por último, el mismo proceso se repite para las direcciones de enlace local y unicast global. En consecuencia, se requiere de varios segundos antes de que un dispositivo pueda emitir paquetes hacia la red. Para equipos móviles, este retardo, que se suma a los de descubierta de vecinos y a la autentificación, puede conducir a interrupciones de conectividad (por ejemplo, para aplicaciones de voz sobre IP).

El RFC 4429 flexibiliza esta situación al permitir que un sitio utilice su dirección aún si no se ha garantizado su unicidad. Este comportamiento es llamado DAD optimista (''optimistic DAD''). El estado tentativo (ver [[#Ciclo de vida de una dirección| Ciclo de vida de una dirección]] se remplaza por un estado ''optimista'' durante el cual la exclusividad de la dirección no está garantizada pero se permite su uso. Paralelamente, se emite un DAD clásico. Los mensajes NS se emiten con el bit <tt>O</tt> (''Override'') apagado para que los caches de ND no se actualicen en caso de que esa dirección ya existiera en la red.

==Descubrimiento de MTU==

<tikz title="Descubrimiento de MTU primera fase: envío de un paquete demasiado grande">
\clip (0, 0) rectangle (11,8);
%\draw[help lines] (0,0) grid (10,7 );

\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,2)--(9,2);

\pgfputat{\pgfxy(0.8,3)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,3)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,2)--(1.5,3);
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (8,2)--(8,3);

\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,4)--(1.5,5);
\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,5)--(9,5);
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (5.5,5)--(5.5,6);
\pgfputat{\pgfxy(5,6)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}
\draw (8, 3.6) node {\small{A}};
\draw (5.5, 6.6) node {\small{B}};
\draw (1.5, 3.6) node {\small{R}};

\draw (1.5,1.5) node {\small{MTU=1500}};
\draw (1.5,5.5) node {\small{MTU=1280}};

\draw (9.5, 3.5) node {\tiny{PMTU(*)=1500}};

\draw [<-] (1.7,3) -- (1.7, 2.2) -- node [above = 10pt] { \tiny{A-$>$ B Size=1500}} (7.8, 2.2) -- (7.8, 3);
}
</tikz>

Por razones de eficacia, generalmente es preferible que la información intercambiada entre dispositivos esté contenida en datagramas de tamaño máximo. Este tamaño depende de la ruta seguida por los datagramas y es igual al tamaño más grande autorizado por el conjunto de enlaces recorridos. Se le llama PMTU, ''Path Maximum Transmission Unit'' (Unidad de transferencia de tamaño máximo sobre la trayectoria).

Inicialmente, el dispositivo supone que el PMTU de una cierta trayectoria es igual al MTU del enlace al que está directamente conectado. Si sucede que los paquetes enviados por ese camino exceden el tamaño máximo autorizado por un enlace intermedio, el enrutador correspondiente eliminará esos paquetes y enviará un mensaje de error ICMPv6 tipo “paquete demasiado grande” donde indicará el MTU aceptable. Con esa información, el dispositivo reducirá el PMTU apropiado para esa ruta.

Es posible que se deban efectuar varias iteraciones antes de obtener el PMTU que permita que los paquetes lleguen a su destino sin exceder el MTU de cada enlace recorrido. El protocolo IPv6 garantiza que el MTU de todos los enlaces no puede ser menor de 1,280 octetos, por lo que éste es el umbral mínimo para el PMTU. Dado que este protocolo puede sufrir pérdidas de paquetes, se deja a las capas superiores gestionar la fiabilidad de la comunicación y restransmitir paquetes si es necesario (paquete 6 del ejemplo).

<tikz title=" Descubrimiento de MTU segunda fase: recepción de un mensaje ICMPv6">
\clip (0, 0) rectangle (11,8);
%\draw[help lines] (0,0) grid (10,7 );

\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,2)--(9,2);

\pgfputat{\pgfxy(0.8,3)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,3)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,2)--(1.5,3);
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (8,2)--(8,3);

\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,4)--(1.5,5);
\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,5)--(9,5);
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (5.5,5)--(5.5,6);
\pgfputat{\pgfxy(5,6)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}
\draw (8, 3.6) node {\small{A}};
\draw (5.5, 6.6) node {\small{B}};
\draw (1.5, 3.6) node {\small{R}};

\draw (1.5,1.5) node {\small{MTU=1500}};
\draw (1.5,5.5) node {\small{MTU=1280}};

\draw (9.5, 3.5) node {\tiny{PMTU(*)=1500}};

\draw [->] (1.7,3) -- (1.7, 2.2) -- node [above = 10pt] { \tiny{R-$>$ A ICMP6 Error: Packet too big}} node [above] {\tiny{MTU=1280}} (7.8, 2.2) -- (7.8, 3);
\draw (9.5, 3) node {\alert{\tiny{PMTU(B)=1280}}};

</tikz>

Si bien la determinación del PMTU se hace esencialmente durante los primeros intercambios entre los dispositivos comunicantes, es posible que pueda reactivarse durante una comunicación activa si, debido a un cambio de ruta, se debe recorrer un enlace con mayores restricciones de tamaño.

El emisor verifica también que el PMTU no ha aumentado enviando esporádicamente un paquete más grande. Si éste cruza la red sin problemas, el valor del PMTU se incrementará.

Cabe señalar que el algoritmo de descubrimiento de PMTU funciona igual para las comunicaciones punto a punto, o multipunto. En este último caso, el PMTU será el mínimo permitido para el conjunto de caminos hacia cada sitio destinatario del grupo de difusión.

La información de PMTU se utiliza de distintas formas dependiendo del ambiente en el que los datos a transmitir se segmentan:

* si se utiliza un protocolo tipo TCP, éste realizará la fragmentación de forma transparente a las aplicaciones en función de la información de PMTU que le comunique la capa IPv6.
* si se utiliza un protocolo tipo UDP, la responsabilidad de la fragmentación recaerá en una capa superior, eventualmente en la aplicación. Será necesario que ésta:
** (1) pueda informarse del valor de PMTU autorizado, aún si éste cambia posteriormente, y
** (2) pueda fragmentar los datos en consecuencia. Para que estas dos condiciones se cumplan, IPv6 ha retenido un mecanismo de fragmentación (ver [[IPv6_QO#Fragmentación|fragmentación]]).

<tikz title=" Descubrimiento de MTU tercera fase: Emisión de un paquete de tamaño adecuado">
\clip (0, 0) rectangle (11,8);
%\draw[help lines] (0,0) grid (10,7 );

\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,2)--(9,2);

\pgfputat{\pgfxy(0.8,3)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,3)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,2)--(1.5,3);
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (8,2)--(8,3);

\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,4)--(1.5,5);
\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,5)--(9,5);
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (5.5,5)--(5.5,6);
\pgfputat{\pgfxy(5,6)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}
\draw (8, 3.6) node {\small{A}};
\draw (5.5, 6.6) node {\small{B}};
\draw (1.5, 3.6) node {\small{R}};

\draw (1.5,1.5) node {\small{MTU=1500}};
\draw (1.5,5.5) node {\small{MTU=1280}};

\draw (9.5, 3.5) node {\tiny{PMTU(*)=1500}};
\draw (9.5, 3) node {\alert{\tiny{PMTU(B)=1280}}};
\draw [<-] (1.7,3) -- (1.7, 2.2) -- node [above = 10pt] { \tiny{A-$>$ B Size=1280}} (7.8, 2.2) -- (7.8, 3);
\draw [->] (1.7,4) -- (1.7, 4.8) -- (5.3, 4.8) -- (5.3, 6);
</tikz>

Hay otro aspecto relacionado con la identificación de caminos para poder asociarles la información de PMTU. El implementador cuenta con varias posibilidades. Por ejemplo, puede identificar un camino por la dirección destino o por el identificador de flujo si este campo se utiliz, o por la ruta seguida en el caso en que ésta sea impuesta (ver Las extensiones#enrutamiento|enrutamiento]]).

Por último, se bien se recomienda encarecidamente que cada dispositivo implemente el mecanismo de detección de PMTU, éste no es obligatorio. Por lo tanto, un equipo que no cuente con él (por ejemplo, una ROM de arranque) deberá restringir el tamaño de los paquetes al mínimo permitido, es decir, 1,280 octetos.

{{eSuivi|Tabla de contenido|Incio del capítulo|DHCPv6|DHCPv6}}

Protocolo de Descubrimiento de vecinos

2012-07-07T01:12:54Z

Jincera: /* Descubrimiento de MTU */

{{eSuivi|Tabla de contenido|Incio del capítulo|DHCPv6|DHCPv6}}

__TOC__

El protocolo de descubrimiento de vecinos (NDP, ''Neighbor Discovery Protocol'') permite a un dispositivo integrarse en el ambiente local, es decir, el enlace sobre el cual se transmiten físicamente los paquetes IPv6. Permite establecer un diálogo con los equipos (estaciones y enrutadores) conectados sobre el mismo medio. No se pretende que un dispositivo conozca con exactitud la lista de todos los demás dispositivos conectados al enlace, sino de proveer un mecanismo para dialogar con quien necesite hacerlo.

El protocolo utiliza cinco tipos de mensajes ICMPv6 (ver Valores de los campos de tipo y código de ICMPv6). El campo número de saltos de la cabecera IPv6 contiene el valor 255. Este valor parece demasiado grande para datagramas que no debieran ser enrutados fuera del enlace físico. En realidad, si un equipo recibe un datagrama con un valor menor, significa que la información proviene de otra red y que ya ha atravesado al menos un enrutador. Por ello, los datagramas que tienen un valor diferente de 255 deben ser ignorados por el receptor.

{{Tableau eICMPv6}}

El protocolo realiza varias funciones:

* Resolución de direcciones. El principio es muy similar al del protocolo ARP de IPv4. La principal diferencia consiste en el uso de mensajes ICMPv6 estándar en lugar de definir otro protocolo de capa 3. Con esto se consigue una mayor flexibilidad de uso, especialmente en las redes que no soportan la difusión de mensajes. Al igual que en IPv4, el protocolo se encarga de construir tablas de correspondencia entre las direcciones IPv6 y las físicas.
* <div vecinos id="NUD"> Detección de inaccesibilidad de vecinos (NUD, ''Neighbor Unreachability Detection''). Esta función, que no existe en IPv4, permite eliminar de las tablas de configuración de un equipo, los vecinos que se han vuelto inaccesibles (por fallas, cambio de domicilio, ...). Si un enrutador deja de estar disponible, la tabla de enrutamiento puede ser modificada para considerar otra ruta. </div>
* Configuración. La configuración automática de los dispositivos es uno de los principales atractivos de IPv6. Se implementan varias funcionalidades del protocolo de descubrimiento de vecinos:
**Descubrimiento de enrutadores. Este protocolo permite que los dispositivos identifiquen a los enrutadores que se encuentran en su enlace físico. En IPv4, esta función la proporciona el protocolo ''ICMP Router Discovery''.
** Descubrimiento de prefijos. El dispositivo conoce el o los prefijos de red de acuerdo a los anuncios realizados por los enrutadores. Agregando su identificador de interfaz, el dispositivo construye su o sus direcciones IPv6. No hay un mecanismo equivalente para las direcciones IPv4 ya que son demasiado cortas para realizar la auto-configuración.
** Detección de direcciones duplicadas. Dado que las direcciones se configuran de forma automática, existen riesgos de error en caso de tener equipos con identificadores repetidos. Este protocolo verifica que ningún otro equipo en el enlace tiene la misma dirección IPv6. Esta función es una evolución del ARP gratuito en IPv4 emitido durante la inicialización de la interfaz.
** Descubrimiento de parámetros. Este protocolo permite que los dispositivos conozcan los distintos parámetros del enlace físico, por ejemplo, el tamaño de MTU, el número máximo de saltos permitido (valor original del campo número de saltos), si la configuración automática con estado (como [[Configuración con estado: DHCPv6|DHCPv6]]) está activa, etc. No existe un equivalente de esta funcionalidad en IPv4.
* Indicación de redirección. Este mensaje se utiliza cuando un enrutador conoce una trayectoria mejor (medida en número de saltos) para alcanzar un destino.
:En IPv4 una indicación de redireccionamiento sólo puede servir para corregir la dirección del enrutador utilizado para acceder a una máquina fuera de la red local. Los dispositivos deben conocer todas las direcciones correspondientes a equipos conectados en su propia red local.
:EnIPv6, la correspondencia entre prefijo y red local es menos rígida. Es de esperar que un dispositivo no conozca todos los prefijos de su red local (si ésta es compartida por varios prefijos), o que un prefijo se comparta entre varios enlaces (lo que corresponde a una generalización del modelo de redes lógicas IP sobre ATM). Bajo algunas configuraciones, la máquina emitirá sus paquetes al enrutador aún si el destinatario se encuentra en el mismo segmento que el emisor. En este caso, el enrutador emitirá un mensaje de redirección para que la continuación del diálogo entre ellos haga de manera directa (véanse los ejemplos [[#IR|Indicación de redirección]]).
:En el caso más extremo, podría imaginarse en IPv6 que un dispositivo puede ser configurado para comunicarse únicamente con su enrutador por omisión. ICMPv6 ''redirect'' puede utilizarse entonces, para informar al dispositivo de destinatarios ubicados en el mismo enlace.

En IPv6 se especifican dos métodos de autoconfiguración para las direcciones unicast global:

* Autoconfiguración sin estado (''stateless autoconfiguration'', RFC 2462). Se utiliza cuando no es necesaria una gestión administrativa de las direcciones asignadas dentro de un sitio. Estos mecanismos se describen más adelante en este capítulo.
* Autoconfiguración con estado (''statefull autoconfiguration''). Se utiliza cuando un sitio requiere de un control estricto de la asignación de direcciones (''cf'' [[Configuración con estado: DHCPv6 | DHCPv6]]).

Sin embargo, el uso de DHCPv6 para obtener la dirección se controla mediante el protocolo de descubrimiento de vecinos.

= Datos transmitidos por los mensajes =

La principal motivación detrás del Protocolo de Descubrimiento de vecinos es unificar varios protocolos existentes en IPv4. En particular, la mayor parte de los datos utiliza un formato de opciones común, lo que simplifica la implementación del protocolo. El formato contiene los campos: tipo, longitud (en palabras de 64 bits), y datos. La baja precisión de campo longitud, presentará un desperdicio de espacio, pero permite una alineación de las opciones en palabras de 64 bits, lo que permite un procesamiento optimizado.

{{NB-Opciones}}

== <div id="física">Dirección física de la fuente/destino</div> ==

<tikz title="Formato de la opción dirección física fuente/destino">
\clip (0.2, 5.7) rectangle (11.1,6.7);
% \draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=1/2}};
\draw (2.9, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{lenght }};
\draw (5.3, 6) node (addr) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Link Layer Address}};

\draw [draw=white, thick] (addr.north east) -- (addr.south east);
\draw [draw=white, thick] (addr.north east) -- +(-2, 0);
\draw [draw=white, thick] (addr.south east) -- +(-2, 0);

\draw [dashed] (addr.north east) -- (addr.south east);
\draw [dashed] (addr.north east) -- +(-2, 0);
\draw [dashed] (addr.south east) -- +(-2, 0);
</tikz>

La figura ''Formato de la opción dirección física fuente/destino'' presenta estas opciones. El tipo 1 designa la dirección física de la fuente y el tipo 2 la dirección del destino.

El campo ''length'' es el tamaño en palabras de 64 bits de la opción. Por lo tanto, para el caso de una dirección MAC con longitud de 6 octetos, contiene el valor 1.

El RFC 2464 define el formato para las direcciones MAC-48 utilizadas en las redes Ethernet y Wi-Fi. El RFC 4944 define el formato para las direcciones MAC-16 y MAC-64 utilizadas en las redes de sensores bajo la norma IEEE 802.15.4.

== <div id="información">Información sobre el prefijo</div> ==

<tikz title="Formato de la opción información sobre el prefijo">
\clip (0.2, 2) rectangle (11.1, 7);
% \draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=3}};
\draw (2.9, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{length =4 }};
\draw (5.3, 6) node (addr) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm] {\tiny{Prefix Length}};
\draw (7.7, 6) node (bitL) [right, shade, top color=blue!15, bottom color=blue!5,, draw, minimum height=0.5cm, minimum width=.3cm]{}; \draw (bitL.text) node {\tiny{L}};
\draw (8, 6) node (bitA) [right, shade, top color=blue!15, bottom color=blue!5,, draw, minimum height=0.5cm, minimum width=.3cm]{};\draw (bitA.text) node {\tiny{A}};
\draw (8.3, 6) node (bitR) [right, shade, top color=blue!15, bottom color=blue!5,, draw, minimum height=0.5cm, minimum width=.3cm]{};\draw (bitR.text) node {\tiny{R}};
\draw (8.6, 6) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=1.5cm] {\tiny{Reserved}};

\draw (0.5, 5.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Valid Lifetime}};

\draw (0.5, 5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Prefered Lifetime}};

\draw (0.5, 4.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Reserved}};

\draw (0.5, 4) node (addr1) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{}};
\draw (0.5, 3.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{}};
\draw (0.5, 3) node (addr3) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Prefix}};
\draw (0.5, 2.5) node (addr4) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{}};

\draw [color=blue!10, very thick] (addr1.south east) -- (addr1.south west);
\draw [color=blue!10, very thick] (addr2.south east) -- (addr2.south west);
\draw [color=blue!10, very thick] (addr3.south east) -- (addr3.south west);
</tikz>

Esta opción contiene las informaciones sobre el prefijo para permitir una configuración automática de los dispositivos. El campo tipo tiene el valor 3 y el de longitud, 4. La figura ''Formato de la opción información sobre el prefijo'' muestra el formato de esta opción:

* El campo ''Prefix lenght'' indica cuántos bits son significativos para el prefijo anunciado en un campo siguiente.
* El bit <tt>L</tt> indica, cuando vale 1, que el prefijo permite indicar que todos los demás dispositivos que comparten el mismo prefijo, están en el mismo enlace, por lo que el emisor puede contactarlos directamente. En caso contrario, el dispositivo envía el paquete hacia el enrutador. Si éste último sabe que el emisor puede contactar directamente al destinatario, emitirá un mensaje ICMPv6 de indicación de redirección.
* El bit <tt>A</tt> indica, cuando vale 1, que el prefijo anunciado puede utilizarse para formar la dirección del dispositivo.
* El bit <tt>R</tt>, indica, cuando vale 1, que el campo prefijo contiene la dirección global de un enrutador ''agente base''. Los bits de mayor peso aún pueden utilizarse para formar un prefijo.
* El campo duración de validez indica, en segundos, la duración durante la cual el prefijo es válido.
* El campo duración preferente indica la duración, en segundos, durante la cual una dirección formada con el protocolo de configuración sin estado se mantiene ''preferente'' (''cf'' [[Planes de direccionamiento|Tiempo de vida de las direcciones]]).

Para estos dos campos, un valor de <tt>0xffffffff</tt> representa una duración infinita. Estos campos pueden servir durante la fase de transición de un proveedor de acceso a otro; es decir, de un prefijo a otro.
* El campo reservado permite alinear el prefijo a una frontera de palabra de 64 bits.
* El campo prefijo contiene el valor de prefijo anunciado sobre el enlace. Para mantener una alineación de 64 bits para el resto de datos del paquete, este campo tiene una longitud fija de 128 bits.

== <div id="redirigida">Cabecera de redirección </div> ==

<tikz title="Formato de la opción cabecera de redirección">
\clip (0.2, 3.1) rectangle (11.1, 7);
% \draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=5}};
\draw (2.9, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{length =1 }};
\draw (5.3, 6) node (addr) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Reserved}};

\draw (0.5, 5.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Reserved}};

\draw (0.5, 4.25) node (context) [right, shade, top color=purple!50, bottom color=purple!10, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{IPv6 Header and Data}};
</tikz>

Esta opción es utilizada por el mensaje de indicación de redirección. Permite encapsular los primeros octetos del paquete IPv6 que provocó la emisión de este mensaje, como ocurre con los mensajes de error de ICMPv6.

El campo tipo tiene el valor 4. El tamaño de esta opción debe evitar que el paquete IPv6 rebase los 1280 octetos (''cf'' figura ''Formato de la opción cabecera de redirección''). Sin embargo, el paquete debe contener la mayor cantidad de información posible.

== <div id="MTU">MTU</div> ==

<tikz title="Formato de la opción MTU">

\clip (0.2, 5.1) rectangle (11.1, 7);
% \draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=5}};
\draw (2.9, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{lenght =1 }};
\draw (5.3, 6) node (addr) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Reserved}};

\draw (0.5, 5.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{MTU}};
</tikz>

Esta opción permite notificar a los dispositivos el tamaño máximo de datos que pueden ser transmitidos sobre el enlace. La figura ''Formato de la opción MTU'' muestra su estructura. No es necesario difundir esta información si el dispositivo utiliza siempre el tamaño máximo permitido. Por ejemplo, sobre las redes Ethernet, los dispositivos utilizarán el valor 1,500. En cambio, en las redes Token Ring o FDDI, con frecuencia es necesario especificar si los equipos pueden utilizar la longitud máxima o un tamaño inferior para permitir el uso de puentes en la red.

En esta opción, el campo tipo tiene un valor de 5 y el de longitud, de 1.

=Mensajes estándar de Descubrimiento de vecinos =

Además de las cinco opciones básicas descritas en la tabla ''Utilización de las opciones en los mensajes de descubrimiento de vecinos'', existen otras específicas para la movilidad y para las redes NBMA (''Non Broadcast Multiple Access'').

{|
|+ Utilización de las opciones en los mensajes de descubrimiento de vecinos
| width = 150 | || width = 100 |[[#RS|Solicitud de]] || width = 100 |[[#RA|Anuncio de]] || width = 100 |[[#NS|Solicitud de]] ||width = 100 | [[#NA|Anuncio de]] ||width = 100 |[[#IR|Indicación de]]
|-
| || [[#RS|enrutador]] || [[#RA|enrutador]] || [[#NS|un vecino]] || [[#NA| un vecino]] || [[#IR|redirección]]
|-style="background:silver"
|[[#física |Dirección física de la fuente]] || presente || presente || presente || ||
|-
|[[# física | Dirección física del destino]] || || || || presente || presente
|-style="background:silver"
|[[#información|Información sobre el prefijo]] || || ≥ 1 || || ||
|-
|[[#redirigida |Cabecera de redirección]] || || || || || presente
|-style="background:silver"
| [[#MTU |MTU]] || || posible || || ||
|}

Las distintas funcionalidades de descubrimiento de vecinos utilizan cinco mensajes: dos para el diálogo entre un dispositivo y un enrutador, dos para el diálogo entre vecinos, y uno para la redirección. Cada uno de estos mensajes puede incluir opciones adicionales.

== <div id="RS">Solicitud de enrutador</div> ==

<tikz title="Formato de los paquetes de solicitud de enrutador">
\clip (0.2, 3.5) rectangle (11.1,7.1);
%\draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=133}};
\draw (2.9, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code =0 }};
\draw (5.3, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};
\draw (0.5, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Reserved}};

\draw (0.5, 4.25) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Options:\\
- Source link-layer address
}};
</tikz>

El mensaje de solicitud de enrutador (''cf'' figura Formato de los paquetes de solicitud de enrutador) es emitido al iniciar un dispositivo para recibir más rápidamente la información del enrutador. Este mensaje se envía a la dirección IPv6 multicast reservada a los enrutadores en el mismo enlace <tt>FF02::2</tt>. Si el dispositivo aún no conoce su dirección fuente, se utiliza la dirección no especificada.

El campo opción normalmente contiene la dirección física del dispositivo.

== <div id="RA">Anuncio de enrutador</div> ==

<tikz title="Formato de los paquetes de anuncio de enrutador">
\clip (0.2, 1.5) rectangle (11.1,7.1);
%\draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=134}};
\draw (2.9, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code =0 }};
\draw (5.3, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};

\draw (0.5, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Cur. Hop Lim.}};
\draw (2.9, 5.5) node (bitM) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{}; \draw (bitM.text) node {\tiny{M}};
\draw (3.2, 5.5) node (bitO) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{};\draw (bitO.text) node {\tiny{O}};
\draw (3.5, 5.5) node (bitH) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{};\draw (bitH.text) node {\tiny{H}};
\draw (3.8, 5.5) node (res) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=1.5cm]{\tiny{reserved}};
\draw (5.3, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Router Lifetime}};

\draw (0.5, 5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=9.6cm]{\tiny{Reachable Time}};
\draw (0.5, 4.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=9.6cm]{\tiny{Retrans Time}};

\draw (0.5, 3.25) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Options:\\
Source link-layer address\\
MTU\\
Prefix Information (may be repeated)\\
}};
</tikz>

Este mensaje (''cf'' figura ''Formato de los paquetes de anuncio de enrutador'') es emitido periódicamente por los enrutadores, o bien, en respuesta a un mensaje de solicitud de enrutador generado por un dispositivo. El campo dirección fuente contiene la dirección de enlace local del enrutador, mientras que el campo dirección destino contiene la dirección del dispositivo que generó la solicitud, o la dirección de todas las estaciones (<tt>ff02::01</tt>).

Cuando el campo de máximo número de saltos tiene un valor distinto de cero, muestra el valor que podría colocarse en el campo de número de saltos de los paquetes emitidos. El bit <tt>M</tt> indica que una dirección del dispositivo debe ser obtenida mediante un protocolo de configuración (''cf'' [[Configuración con estado:DHCPv6]]). El bit <tt>O</tt> también indica la presencia de un servicio de configuración para obtener información adicional a la dirección. Si no es posible obtener la dirección mediante un servidor, el dispositivo procede a realizar una configuración sin estado, concatenando su identificador de interfaz a los prefijos que conoce. El bit <tt>H</tt> indica que el enrutador puede ser utilizado como agente base por un nodo móvil (''cf'' [[Desplazamientos_de_móviles#Anuncio_del_agente_base |Anuncio del agente base]]).

El campo tiempo de vida del enrutador indica el período (en segundos) durante el cual el equipo que emite el anuncio realizará funciones de enrutador por omisión. El valor máximo corresponde a 18 horas 12 minutos, pero como este mensaje se emite periódicamente, en la práctica no existe un límite para el tiempo de vida de un enrutador. Un valor de <tt>0</tt> indica que el dispositivo no cumple con las funciones de enrutador por omisión. Este tiempo de vida no se aplica a las opciones transportadas por este mensaje.

El campo duración de accesibilidad indica el período (en milisegundos) durante el cual una información almacenada en la memoria caché de la máquina (por ejemplo, la tabla de correspondencia entre las direcciones IPv6 y las físicas) puede ser considerada como válida. Al vencimiento de este tiempo, se emite un mensaje de detección de inaccesibilidad para verificar la pertinencia de la información almacenada.

El campo temporización de retransmisión muestra el período (en milisegundos) entre dos emisiones no solicitadas de este mensaje. Permite que los demás equipos puedan detectar la inaccesibilidad de un enrutador.

Este mensaje puede transportar las siguientes opciones:

* dirección física de la fuente,
* MTU,
* información sobre el prefijo (uno o varios).

== <div Id="NS"> Solicitud de un vecino </div> ==

<tikz title="Formato de los paquetes de solicitud de un vecino">

\clip (0.2, 1.5) rectangle (11.1,7.1);
%\draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=135}};
\draw (2.9, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code =0 }};
\draw (5.3, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};

\draw (0.5, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=9.6cm]{\tiny{Reserved}};

\draw (0.5, 4.25) node (context) [right, shade, top color=blue!50, bottom color=blue=!10, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Target Address}};

\draw (0.5, 2.25) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Options:\\
Source link-layer address\\
}};
</tikz>

Este mensaje (''cf'' figura ''Formato de los paquetes de solicitud de un vecino'') permite obtener información a partir de un equipo vecino, es decir, localizado en el mismo enlace físico (o conectado a través de puentes). El mensaje puede ser emitido explícitamente a él, o enviado con una dirección de difusión. En el caso de determinación de la dirección física, éste corresponde a la solicitud de ARP en IPv4.

El campo dirección fuente del paquete IPv6 contiene ya sea la dirección local al enlace, una dirección global o la dirección no especificada. El campo destino puede contener la dirección de difusión múltiple solicitada correspondiente a la dirección buscada (''cf'' [[Direccionamiento_multicast#Identificador_de_grupo|Identificador de grupo]]) o la dirección del dispositivo (en el caso de una detección de inaccesibilidad de vecinos, ''NUD'').

El campo dirección del destino contiene la dirección IPv6 del equipo buscado. El campo opción generalmente contiene la dirección física de la fuente.

== <div Id="NA"> Anuncio de un vecino</div> ==

<tikz title="Formato de los paquetes de anuncio de un vecino">

\clip (0.2, 1.5) rectangle (11.1,7.1);
%\draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=136}};
\draw (2.9, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code =0 }};
\draw (5.3, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};

\draw (0.5, 5.5) node (bitR) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{}; \draw (bitR.text) node {\tiny{R}};
\draw (0.8, 5.5) node (bitS) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{}; \draw (bitS.text) node {\tiny{S}};
\draw (1.1, 5.5) node (bitO) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{}; \draw (bitO.text) node {\tiny{O}};
\draw (1.4, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=8.7cm]{\tiny{Reserved}};

\draw (0.5, 4.25) node (context) [right, shade, top color=blue!50, bottom color=blue=!10, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Target Address}};

\draw (0.5, 2.25) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Options:\\
Source link-layer address\\
}};
</tikz>

Este mensaje (''cf'' figura ''Formato de los paquetes de anuncio de un vecino'') se emite en respuesta a una solicitud, aunque también puede ser emitido de forma espontánea para propagar la información de cambio de dirección física, o del estado de "enrutador". Para el caso de la determinación de la dirección física, es equivalente a la respuesta ARP en IPv4.

* El bit <tt> R </tt> se pone a 1 si el remitente es un enrutador. Este bit se utiliza para permitir la detección de un enrutador que se convierte en un equipo ordinario.
* El bit <tt> S </tt> en 1 indica que este anuncio se emite en respuesta a una solicitud.
* El bit <tt> O </tt> en 1 indica que este anuncio debe borrar las informaciones anteriores que se encuentran almacenadas en la memoria cachés de otros equipos, en especial la tabla que contiene las direcciones físicas.
* El campo dirección del destino contiene, si el bit<tt> S </tt> es 1, el valor del campo dirección del destino de la solicitud a la que está respondiendo este mensaje. Si el bit <tt> S </tt> es 0, este campo contiene la dirección IPv6 local al enlace del equipo emisor.
* La opción dirección física del destino contiene la dirección física del emisor.

== <div id="IR">Indicación de redirección</div> ==

<tikz title="Formato de los paquetes de indicación de redirección">
\clip (0.2, 0) rectangle (11.1,7.1);
%\draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=137}};
\draw (2.9, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code =0 }};
\draw (5.3, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};

\draw (0.5, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=9.6cm]{\tiny{Reserved}};

\draw (0.5, 4.25) node (context) [right, shade, top color=blue!50, bottom color=blue=!10, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Target Address}};

\draw (0.5, 2.25) node (context) [right, shade, top color=blue!50, bottom color=blue=!10, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Destination Address}};

\draw (0.5, 0.5) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=1.5cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Options:\\
Target link-layer address\\
Redirected Header\\
}};
</tikz>

La técnica de redirección es la misma que en IPv4. Un dispositivo sólo conoce los prefijos de las redes a las que está conectado directamente y la dirección de un enrutador por omisión. Si la ruta se puede optimizar, el enrutador por omisión envía un mensaje para indicar que existe un camino más corto. De hecho, como en IPv6 el enrutador por omisión se establece de forma automática, las rutas no necesariamente son las mejores (''cf'' figura ''Enrutamiento por omisión no óptimo'').

Otro caso particular en IPv6 ocurre con los dispositivos que se encuentran en el mismo enlace físico, pero tienen diferentes prefijos. La comunicación entre ellos pasa inicialmente a traves de enrutador por omisión hasta que éste notifica que existe una ruta directa entre ellos.

La figura ''Formato de los paquetes de indicación de redirección'' muestra el formato del mensaje:

* El campo dirección objetivo (''Target address'') contiene la dirección IPv6 del equipo hacia el que los paquetes deben ser enviados.
* El campo dirección destino contiene la dirección IPv6 del dispositivo que está siendo redirigido hacia la dirección objetivo.

Cuando la redirección apunta a un dispositivo situado en el mismo enlace, la dirección objetivo y de destino son las mismas.

Las opciones incluyen la dirección física de un nuevo enrutador y la cabecera del paquete redirigido.

Este mensaje se puede utilizar de la misma forma que en IPv4. Un dispositivo solamente tiene una ruta por omisión para acceder a equipos con un prefijo diferente. En consecuencia, envía su paquete al enrutador por omisión, quien observa que el prefijo destino es accesible a través de la misma subred que el emisor. El enrutador por omisión reenvía el paquete y notifica al emisor que puede contactar directamente a las máquinas que poseen el prefijo del destino.

IPv6 también utiliza este mensaje para optimizar la resolución fuera del enlace para el [[#Caso de redes NBMA |caso de redes NBMA]].

= Configuración automática =
Tradicionalmente, la configuración de una interfaz de red de una máquina se hacía manualmente. Esto suele ser un trabajo lento y propenso a errores. Con IPv6, se automatiza el proceso de configuración y se introducen, al mismo tiempo, mecanismos de funcionamiento inmediato (''plug and play'') a la interfaz de red. La configuración automática significa que un dispositivo obtendrá toda la información necesaria para su conexión a una red local IP sin ninguna intervención humana. En el caso ideal, cualquier usuario desempaca su nuevo equipo, lo conecta a la red local y lo ve funcionar sin tener que introducir la información propia de "especialistas". Ahora vamos a discutir otro aspecto de la configuración automática de IPv6, la auto-configuración de direcciones, que tiene como objetivos:

* La adquisición de una dirección cuando un dispositivo está conectado a una red por primera vez;
* la posibilidad de asignar otros prefijos, o de renumerar un dispositivo.

El proceso de configuración automática de direcciones IPv6 incluye la creación de una dirección local al enlace, la agregación a grupos multicast solicitados, la verificación de la unicidad de la dirección local al enlace y la creación de direcciones unicast global.

La tarea del enrutador es importante en la configuración automática. Indica a la máquina, mediante los bits de la cabecera (''cf'' [[#RA|anuncio de enrutador]]), del mensaje de anuncio de los enrutadores, el método a conservar y eventualmente proporcionar la información necesaria para su configuración. El bit <tt> M </tt> (''configuración de dirección administrada'') puesto a 1 indica que el equipo no debe crear por sí mismo una dirección a partir de su identificador de interfaz y de los prefijos recibidos, sino que debe solicitarla explícitamente ante un servidor de direcciones. El bit O <tt> </tt> (''otra configuración de estado'') indica que el dispositivo debe consultar el servidor para obtener otros parámetros distintos de la dirección. El algoritmo para el proceso de configuración automática de direcciones se desglosa de la siguiente manera:

* La primera fase consiste en crear la dirección local al enlace.
* Una vez que la unicidad de esta dirección es verificada, el dispositivo está listo para comunicarse con otras máquinas en el enlace.
* El dispositivo debe tratar de adquirir un mensaje de anuncio de enrutadores para determinar el método de obtención de la dirección unicast global.
* Si hay un enrutador en el enlace, el dispositivo debe aplicar el método especificado por el mensaje de anuncio de enrutadores, a saber:
** La configuración automática sin estado,
** la configuración automática con estado.
* Si no hay ningún enrutador en el enlace, el dispositivo debe tratar de obtener la dirección unicast global por el método de configuración automática con estado. Si el intento falla, no hay más que hacer. Las comunicaciones sólo podrán hacerse sobre el enlace con la dirección local al enlace, pues el dispositivo no tendrá una dirección con la cobertura necesaria que le permita comunicarse con otras máquinas fuera del enlace.

==Ciclo de vida de una dirección==

Al generalizar en IPv6 el plan de direccionamiento CIDR, los prefijos quedan, en todos los casos, siendo propiedad de los operadores. Ya no pueden otorgarse "a perpetuidad" a los dispositivos. Para facilitar la renumeración de una máquina, la asignación de una dirección a una interfaz es temporal, las direcciones IPv6 no se entregan, sino que se prestan. Se asocia un tiempo de vida a la dirección, que indica el tiempo durante el cual la dirección pertenece a la interfaz. Cuando el tiempo de vida se ha agotada, la dirección deja de ser válida, se suprime de la interfaz y queda potencialmente éste puede prolongarse indefinidamente. La dirección local al enlace tiene un tiempo de vida ilimitado.

<tikz title="Estados sucesivos de una dirección en una interfaz">

\draw [thick, ->] (0,2) -- (9.5,2);

\draw [->] (1,4) node [above=10pt] {\tiny{allocation}}-- (1,2);
\draw (1, 2) node [rectangle, minimum width=1cm, minimum height=1cm, fill, left color=black!10, right color=black!20, draw=black, above right] (tentative) {};
\draw (tentative.south east) node [rectangle, minimum width=3cm, minimum height=1cm, fill, left color=green, right color=green!50, draw=black, above right] (preferred) {};
\draw (preferred.south east) node [rectangle, minimum width=2cm, minimum height=1cm, fill, left color=orange , right color=orange!50!red, draw=black, above right] (deprecated) {};
\draw (deprecated.south east) node [rectangle, minimum width=2cm, minimum height=1cm, fill, color=red, draw=black, above right] (novalid) {};

\draw (tentative.text) node {\tiny{Tentative}};
\draw (preferred.text) node {\tiny{Preferred}};
\draw (deprecated.text) node {\tiny{Deprecated}};
\draw (novalid.text) node {\tiny{Invalid}};

\draw [dotted] (tentative.south west) -- +(0, -1);
\draw [dotted] (preferred.south west) -- +(0, -1);
\draw [dotted] (deprecated.south west) -- +(0, -1);
\draw [dotted] (novalid.south west) -- +(0, -1);

\draw [dashed, <->] ([yshift=-0.5cm]tentative.south west) -- node [above] {\tiny{DAD}} ([yshift=-0.5cm] preferred.south west) ;

\draw [dashed, <->] ([yshift=-0.5cm]preferred.south west) -- node [above] {\tiny{Valid}} ([yshift=-0.5cm] novalid.south west) ;

</tikz>

La renumeración de una interfaz consiste en pasar de una dirección a otra. Durante una renumeración, no es aconsejable cambiar repentinamente de dirección, de lo contrario, todas las comunicaciones TCP que la utilizan como identificador de conexión, se cortarían inmediatamente. Esto conllevaría importantes perturbaciones a nivel de las aplicaciones.

Por ello, para facilitar esta transición se implementó un mecanismo de obsolescencia que invalida gradualmente una dirección. Este mecanismo se sirve de la capacidad de asignación de varias direcciones válidas a una misma interfaz. Para elegir la dirección a utilizar, se le asocia un estado que indica en qué fase de su tiempo de vida se encuentra con respecto a la interfaz. El primero de esos estados se conoce como preferido: no hay ninguna restricción de uso. Poco antes de su invalidación, la dirección pasa a un estado de depreciado. En él se desaconseja el uso de la dirección, pero no está prohibido. Una dirección depreciada ya no debe ser utilizada como dirección fuente de nuevas comunicaciones (como el establecimiento de conexión TCP), pero todavía puede emplearse como dirección fuente de comunicaciones ya establecidas. Los paquetes recibidos a una dirección depreciada seguirán siendo entregados normalmente. El control de la duración de cada estad de una dirección válida se efectúa agregando un tiempo de vida al estado preferido.
La figura '''Estados sucesivos de una dirección en una interfaz''' representa los diferentes estados que toma una dirección cuando se asigna a una interfaz.

== Creación de la dirección local al enlace ==

<tikz title=" Creación de la dirección local al enlace">
\clip (0, 0) rectangle (10,7);
% \draw[help lines] (0,0) grid (10,7 );

\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,3)--(9,3);

\pgfputat{\pgfxy(0.8,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,5)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,3)--(1.5,5);
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (8,3)--(8,5);

\draw (1.5,4.5) node {\small{FE80::IID1}};
\draw (1.5,4) node {\small{$\alpha$::IID1/64}};

\draw (8, 4.5) node {\small{FE80::IID2}};

</tikz>

Durante la inicialización de la interfaz, el dispositivo construye un identificador de interfaz que debe ser único en el enlace. Este identificador se utiliza la dirección de [[ Identificador_de_interfaz#EUI-64 | EUI-64]]. El principio básico para crear la direcciónIPv6 consiste en unir un prefijo con el identificador. La dirección local al enlace se crea tomando el prefijo de Enlace_local (<tt>FE80::/64</tt>). La dirección creada de esa manera, todavía no puede ser utilizada; tiene un estado temporal pues el dispositivo debe comprobar la exclusividad de esta dirección en el enlace mediante el procedimiento de detección de direcciones duplicadas. Si se encuentra que la dirección local al enlace no es única, se suspende la autoconfiguración y será necesario proceder a una configuración manual.

Una vez que se ha asegurado la unicidad de la dirección local al enlace, ésta se considera una dirección válida para la interfaz, con lo que termina la prima fase del proceso de autoconfiguración.

==<div id="DAD"> Detección de una dirección duplicada </div>==

<tikz title="Emisión de un NS en una detección de Dir. duplicada (DAD)">
\clip (0, 0) rectangle (10,7);
% \draw[help lines] (0,0) grid (10,7 );

\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,3)--(9,3);

\pgfputat{\pgfxy(0.8,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,5)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,3)--(1.5,5);
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (8,3)--(8,5);

\draw (7.8, 5) -- (7.8, 3.2);
\draw [<->] (1, 3.2) -- node [above] {\tiny{::/0 -$>$ solicited (FE80:IID2) : NS (who has FE80::IID2?)}}(9, 3.2) ;

</tikz>

Para comprobar la exclusividad de direcciones locales al enlace o de direcciones unicast, los dispositivos deben ejecutar un algoritmo de detección de direcciones duplicadas (DAD) antes poder utilizarlas. El algoritmo usa los mensajes ICMPv6 [[Protocolo_de_Descubrimiento_de_vecinos#NS|solicitud de un vecino]] y [[#NA|anuncio de un vecino.]] Si se detecta una dirección que ya está en uso, ésta no podrá ser asignada a la interfaz, la autoconfiguración automática debe suspenderse y será necesario proceder a una configuración manual. Durante la ejecución del algoritmo DAD, la dirección es considerada como "provisional" hasta tener la confirmación de su unicidad. Una dirección provisional se asigna a una interfaz únicamente para recibir los mensajes de solicitud y anuncio de un vecino. Otros mensajes recibidos, son ignorados. El algoritmo DAD consiste en enviar un mensaje de solicitud de un vecino colocando en el campo de dirección objetivo la dirección provisional. Para distinguir el algoritmo DAD del de Descubrimiento de vecinos, el paquete IPv6 que contiene un mensaje de solicitud de un vecino tiene como dirección fuente una dirección no determinada. Así se presentan tres casos:

* Se recibe un mensaje de anucio de un vecino: Significa que la dirección provisional está siendo utilizada como válida por otro dispositivo, por lo que ésta no es única y no puede ser retenida por el dispositivo.
* Se recibe un mensaje de solicitud de un vecino como parte del algoritmo DAD. La dirección provisional también es provisional para otra máquina. En este caso, la dirección provisional no puede ser utilizada por ninguna de ellas.
* No se recibe ningún mensaje durante un segundo (valor por omisión). La dirección provisional es única, por lo que su estado pasa de provisional a válida y se le asigna a la interfaz.

Obsérvese que este algoritmo no proporciona una fiabilidad absoluta, especialmente cuando el enlace está segmentado.

== Autoconfiguración sin estado ==

<tikz title="Emisión de un RS">
\clip (0, 0) rectangle (10,7);
% \draw[help lines] (0,0) grid (10,7 );

\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,3)--(9,3);

\pgfputat{\pgfxy(0.8,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,5)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,3)--(1.5,5);
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (8,3)--(8,5);

\draw (7.8, 5) -- (7.8, 3.2);
\draw [<->] (1, 3.2) -- node [above] {\tiny{FE80::IID2 -$>$ FF02::2 : RS }} (9, 3.2) ;

</tikz>

La configuración automática sin estado (RFC 2462) no requiere de ninguna configuración manual de los dispositivos, una configuración mínima para los enrutadores, y tampoco necesita de servidores adicionales. Se sirve del protocolo ICMPv6 y puede operar aún sin la presencia de enrutadores. En cambio, sí requiere de una subred con soporte a la difusión de paquetes. Este método sólo aplica para los dispositivos; no puede ser utilizada para configurar enrutadores. El principio básico de este mecanismo consiste en que una máquina genera su dirección IPv6 a partir de información local y de la proporcionada por un enrutador. El enrutador proporciona información sobre la subred asociada al enlace; anuncia el prefijo.

<tikz title="Recepción de un RA">
\clip (0, 0) rectangle (10,7);
% \draw[help lines] (0,0) grid (10,7 );

\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,3)--(9,3);

\pgfputat{\pgfxy(0.8,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,5)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,3)--(1.5,5);
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (8,3)--(8,5);

\draw [->] (1.7,5) -- (1.7, 3.2) -- node [above = 10pt] {\tiny{FE80::IID1 -$>$ FE80::IID2}} node [above] {\tiny{RA ($\alpha$::/64, DHCPv6, MTU=1500, HL=64, {bit {\tt M=1}) }}} (7.8, 3.2) -- (7.8, 5);

</tikz>

Al igual que para la creación de la dirección de enlace local, la dirección unicast global se obtiene al concatenar el prefijo con el identificador de la interfaz. El prefijo se obtiene del mensaje de anuncio de enrutador, más concretamente, de la opción de ''información sobre el prefijo''. Si bien debe verificarse la unicidad de todas las direcciones unicast, en el caso de una dirección unicast obtenida mediante la configuración automática sin estado, esto no es obligatorio, pues la unicidad del identificador de la interfaz ya fue comprobada durante la configuración de la dirección local al enlace. Dado que el identificador es el mismo, no puede haber ambigüedad sobre la exclusividad de la dirección unicast global creada de esta forma.

La renumeración de los dispositivos en un enlace se realiza mediante enrutadores que transfieren las direcciones utilizadas a un estado depreciado y al mismo tiempo anuncian el nuevo prefijo con el que los dispositivos pueden re-crear una dirección preferida.

===Caso de redes NBMA ===

<tikz title="Off Link NDP: Primera etapa">
\clip (0, 0) rectangle (11,7);
% \draw[help lines] (0,0) grid (10,7 );

\pgfputat{\pgfxy(4.5,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}
\pgfputat{\pgfxy(1.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[decorate,decoration={zigzag}, color=black!60, ->, very thick] (8,3)-- node [above, color=black] {\tiny{FE80::IID2 -$>$ FF02::2 : RS}} (5,5);

</tikz>

Las redes NBMA (''Non Broadcast Multiple Access'') se caracterizan por no contar con un mecanismo de difusión hacia todos los dispositivos. Esto conduce a dos situiaciones posibles:
* ausencia total de difusión, como en las redes públicas (telefónica, ATM, …) en las que un solo destinatario puede ser contactado a la vez
* posibilidad de difusión por un número limitado de equipos, como es el caso de las redes de radio tipo 3G, WiMAX, en las que la estación base tiene la posibilidad de difundir datos hacia todos los equipos, pero esto no es posible en el sentido inverso (desde un dispositivo).

<tikz title="Off Link NDP: Segunda etapa">
\clip (0, 0) rectangle (11,7);
% \draw[help lines] (0,0) grid (10,7 );

\pgfputat{\pgfxy(4.5,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}
\pgfputat{\pgfxy(1.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[decorate,decoration={zigzag}, color=black!60, ->, very thick] (5, 5)-- node [above, color=black] {\tiny{RA ($\alpha$::/64, DHCPv6, OffLink, MTU=1500, HL=64, {bit {\tt M=1}})}} (8,3);

</tikz>

Un comportamiento de redes NBMA también puede ser deseable para limitar las restricciones de consumo energético. Por ejemplo, en el caso de redes de sensores, la difusión, o la difusión restringida (multicast) son costosas en consumo de energía pues todos los dispositivos deben procesar el mensaje y algunos deberán retransmitirlo.

<tikz title="Off Link NDP: Tercera etapa">
\clip (0, 0) rectangle (11,7);
% \draw[help lines] (0,0) grid (10,7 );

\pgfputat{\pgfxy(4.5,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}
\pgfputat{\pgfxy(1.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[decorate,decoration={zigzag}, color=black!60, ->, very thick] (8,3)-- node [left, near start, color=black] {\tiny{$\alpha$::IID2 -$>$ $\alpha$::IID3 : DATA}} (5,5);

\draw[decorate,decoration={zigzag}, color=black!60, ->, very thick] (5,5)-- node [left, midway, color=black] {\tiny{$\alpha$::IID2 -$>$ $\alpha$::IID3 : DATA}} (2,3);

</tikz>

Para estos casos, el protocolo de descubrimiento de vecinos cuenta con un modo NBMA llamado también ''OffLink'', el cual solamente autoriza el diálogo con un enrutador. Los intercambios comienzan de la misma forma:
* El dispositivo que desea insertarse en la red, emite un mensaje RS (''Router Sollicitation'') utilizando la dirección destino FF02::2 (todos los enrutadores sobre el enlace. La red NBMA deberá enviar este mensaje hacia un enrutador.
* El enrutador responde poniendo el bit <tt>L</tt> (OffLink) a 1 en la opción [[#información|Información sobre el prefijo]], indicando que todos los intercambios deben pasar por él.
* El dispositivo construye su dirección global concatenando el prefijo a su identificador de interfaz.
* El dispositivo envía sistemáticamente todos los paquetes a la dirección física del enrutador. Éste, que tiene una visión global de la red, los reenvía hacia el destinatario apropiado.

<tikz title="Off Link NDP: Cuarta etapa (opcional)">
\clip (0, 0) rectangle (11,7);
% \draw[help lines] (0,0) grid (10,7 );

\pgfputat{\pgfxy(4.5,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}
\pgfputat{\pgfxy(1.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[decorate,decoration={zigzag}, color=black!60, ->, very thick] (8,3)-- node [left, near end, color=black] {\tiny{$\alpha$::IID2 -$>$ $\alpha$::IID3 : DATA}} (5,5);

\draw[decorate,decoration={zigzag}, color=black!60, ->, very thick] (5,5)-- node [left, midway, color=black] {\tiny{$\alpha$::IID2 -$>$ $\alpha$::IID3 : DATA}} (2,3);

\draw[decorate,decoration={triangles}, color=black!60, ->, thick, ] (5,5) to [bend left] node [right, near start, color=black] {\tiny{REDIRECT $\alpha$::IID3 : MAC3}} (8,3);

\draw [color=black!60, ->, very thick, dotted] (8,3)-- node [above, midway, color=black] {\tiny{$\alpha$::IID2 -$>$ $\alpha$::IID3 : DATA}} (2,3);

</tikz>

* Si la tecnología del enlace lo permite y si la política de gestión de red lo autoriza, el enrutador tiene la posibilidad de optimizar el tráfico, notificando al dispositivo la verdadera dirección del destinatario, emitiendo un mensaje de [[#IR|indicación de redirección]] (''ICMP Redirect''). Los paquetes subsecuentes ya no pasarán por el enrutador.

===Caso de redes móviles===

La detección de duplicación de direcciones es un proceso relativamente largo, pues un dispositivo que desea garantizar la unicidad de su dirección, debe emitir un mensaje NS y esperar que no haya respuesta. Además, dado que es posible que la red pierda los mensajes NS, el dispositivo podría intentar varias veces de resolver su propia dirección antes de garantizar su unicidad. Por último, el mismo proceso se repite para las direcciones de enlace local y unicast global. En consecuencia, se requiere de varios segundos antes de que un dispositivo pueda emitir paquetes hacia la red. Para equipos móviles, este retardo, que se suma a los de descubierta de vecinos y a la autentificación, puede conducir a interrupciones de conectividad (por ejemplo, para aplicaciones de voz sobre IP).

El RFC 4429 flexibiliza esta situación al permitir que un sitio utilice su dirección aún si no se ha garantizado su unicidad. Este comportamiento es llamado DAD optimista (''optimistic DAD''). El estado tentativo (ver [[#Ciclo de vida de una dirección| Ciclo de vida de una dirección]] se remplaza por un estado ''optimista'' durante el cual la exclusividad de la dirección no está garantizada pero se permite su uso. Paralelamente, se emite un DAD clásico. Los mensajes NS se emiten con el bit <tt>O</tt> (''Override'') apagado para que los caches de ND no se actualicen en caso de que esa dirección ya existiera en la red.

==Descubrimiento de MTU==

<tikz title="Descubrimiento de MTU primera fase: envío de un paquete demasiado grande">
\clip (0, 0) rectangle (11,8);
%\draw[help lines] (0,0) grid (10,7 );

\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,2)--(9,2);

\pgfputat{\pgfxy(0.8,3)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,3)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,2)--(1.5,3);
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (8,2)--(8,3);

\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,4)--(1.5,5);
\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,5)--(9,5);
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (5.5,5)--(5.5,6);
\pgfputat{\pgfxy(5,6)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}
\draw (8, 3.6) node {\small{A}};
\draw (5.5, 6.6) node {\small{B}};
\draw (1.5, 3.6) node {\small{R}};

\draw (1.5,1.5) node {\small{MTU=1500}};
\draw (1.5,5.5) node {\small{MTU=1280}};

\draw (9.5, 3.5) node {\tiny{PMTU(*)=1500}};

\draw [<-] (1.7,3) -- (1.7, 2.2) -- node [above = 10pt] { \tiny{A-$>$ B Size=1500}} (7.8, 2.2) -- (7.8, 3);
}
</tikz>

Por razones de eficacia, generalmente es preferible que la información intercambiada entre dispositivos esté contenida en datagramas de tamaño máximo. Este tamaño depende de la ruta seguida por los datagramas y es igual al tamaño más grande autorizado por el conjunto de enlaces recorridos. Se le llama PMTU, ''Path Maximum Transmission Unit'' (Unidad de transferencia de tamaño máximo sobre la trayectoria).

Inicialmente, el dispositivo supone que el PMTU de una cierta trayectoria es igual al MTU del enlace al que está directamente conectado. Si sucede que los paquetes enviados por ese camino exceden el tamaño máximo autorizado por un enlace intermedio, el enrutador correspondiente eliminará esos paquetes y enviará un mensaje de error ICMPv6 tipo “paquete demasiado grande” donde indicará el MTU aceptable. Con esa información, el dispositivo reducirá el PMTU apropiado para esa ruta.

Es posible que se deban efectuar varias iteraciones antes de obtener el PMTU que permita que los paquetes lleguen a su destino sin exceder el MTU de cada enlace recorrido. El protocolo IPv6 garantiza que el MTU de todos los enlaces no puede ser menor de 1,280 octetos, por lo que éste es el umbral mínimo para el MTU. Dado que este protocolo puede sufrir pérdidas de paquetes, se deja a las capas superiores gestionar la fiabilidad de la comunicación y restransmitir paquetes si es necesario (paquete 6 del ejemplo).

<tikz title=" Descubrimiento de MTU segunda fase: recepción de un mensaje ICMPv6">
\clip (0, 0) rectangle (11,8);
%\draw[help lines] (0,0) grid (10,7 );

\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,2)--(9,2);

\pgfputat{\pgfxy(0.8,3)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,3)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,2)--(1.5,3);
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (8,2)--(8,3);

\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,4)--(1.5,5);
\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,5)--(9,5);
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (5.5,5)--(5.5,6);
\pgfputat{\pgfxy(5,6)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}
\draw (8, 3.6) node {\small{A}};
\draw (5.5, 6.6) node {\small{B}};
\draw (1.5, 3.6) node {\small{R}};

\draw (1.5,1.5) node {\small{MTU=1500}};
\draw (1.5,5.5) node {\small{MTU=1280}};

\draw (9.5, 3.5) node {\tiny{PMTU(*)=1500}};

\draw [->] (1.7,3) -- (1.7, 2.2) -- node [above = 10pt] { \tiny{R-$>$ A ICMP6 Error: Packet too big}} node [above] {\tiny{MTU=1280}} (7.8, 2.2) -- (7.8, 3);
\draw (9.5, 3) node {\alert{\tiny{PMTU(B)=1280}}};

</tikz>

Si bien la determinación del PMTU se hace esencialmente durante los primeros intercambios entre los dispositivos comunicantes, es posible que pueda reactivarse durante una comunicación activa si, debido a un cambio de ruta, se debe recorrer un enlace con mayores restricciones de tamaño.

El emisor verifica también que el PMTU no ha aumentado enviando esporádicamente un paquete más grande. Si éste cruza la red sin problemas, el valor del PMTU se incrementará.

Cabe señalar que el algoritmo de descubrimiento de PMTU funciona igual para las comunicaciones punto a punto, o multipunto. En este último caso, el PMTU será el mínimo permitido para el conjunto de caminos hacia cada sitio destinatario del grupo de difusión.

La información de PMTU se utiliza de distintas formas dependiendo del ambiente en el que los datos a transmitir se segmentan:

* si se utiliza un protocolo tipo TCP, éste realizará la fragmentación de forma transparente a las aplicaciones en función de la información de PMTU que le comunique la capa IPv6.
* si se utiliza un protocolo tipo UDP, la responsabilidad de la fragmentación recaerá en una capa superior, eventualmente en la aplicación. Será necesario que ésta:
** (1) pueda informarse del valor de PMTU autorizado, aún si éste cambia posteriormente, y
** (2) pueda fragmentar los datos en consecuencia. Para que estas dos condiciones se cumplan, IPv6 ha retenido un mecanismo de fragmentación (ver [[IPv6_QO#Fragmentación|fragmentación]]).

<tikz title=" Descubrimiento de MTU tercera fase: Emisión de un paquete de tamaño adecuado">
\clip (0, 0) rectangle (11,8);
%\draw[help lines] (0,0) grid (10,7 );

\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,2)--(9,2);

\pgfputat{\pgfxy(0.8,3)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,3)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,2)--(1.5,3);
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (8,2)--(8,3);

\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,4)--(1.5,5);
\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,5)--(9,5);
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (5.5,5)--(5.5,6);
\pgfputat{\pgfxy(5,6)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}
\draw (8, 3.6) node {\small{A}};
\draw (5.5, 6.6) node {\small{B}};
\draw (1.5, 3.6) node {\small{R}};

\draw (1.5,1.5) node {\small{MTU=1500}};
\draw (1.5,5.5) node {\small{MTU=1280}};

\draw (9.5, 3.5) node {\tiny{PMTU(*)=1500}};
\draw (9.5, 3) node {\alert{\tiny{PMTU(B)=1280}}};
\draw [<-] (1.7,3) -- (1.7, 2.2) -- node [above = 10pt] { \tiny{A-$>$ B Size=1280}} (7.8, 2.2) -- (7.8, 3);
\draw [->] (1.7,4) -- (1.7, 4.8) -- (5.3, 4.8) -- (5.3, 6);
</tikz>

Hay otro aspecto relacionado con la identificación de caminos para poder asociarles la información de PMTU. El implementador cuenta con varias posibilidades. Por ejemplo, puede identificar un camino por la dirección destino o por el identificador de flujo si este campo se utiliz, o por la ruta seguida en el caso en que ésta sea impuesta (ver Las extensiones#enrutamiento|enrutamiento]]).

Por último, se bien se recomienda encarecidamente que cada dispositivo implemente el mecanismo de detección de PMTU, éste no es obligatorio. Por lo tanto, un equipo que no cuente con él (por ejemplo, una ROM de arranque) deberá restringir el tamaño de los paquetes al mínimo permitido, es decir, 1,280 octetos.

{{eSuivi|Tabla de contenido|Incio del capítulo|DHCPv6|DHCPv6}}

Protocolo de Descubrimiento de vecinos

2012-07-07T01:10:37Z

Jincera:

{{eSuivi|Tabla de contenido|Incio del capítulo|DHCPv6|DHCPv6}}

__TOC__

El protocolo de descubrimiento de vecinos (NDP, ''Neighbor Discovery Protocol'') permite a un dispositivo integrarse en el ambiente local, es decir, el enlace sobre el cual se transmiten físicamente los paquetes IPv6. Permite establecer un diálogo con los equipos (estaciones y enrutadores) conectados sobre el mismo medio. No se pretende que un dispositivo conozca con exactitud la lista de todos los demás dispositivos conectados al enlace, sino de proveer un mecanismo para dialogar con quien necesite hacerlo.

El protocolo utiliza cinco tipos de mensajes ICMPv6 (ver Valores de los campos de tipo y código de ICMPv6). El campo número de saltos de la cabecera IPv6 contiene el valor 255. Este valor parece demasiado grande para datagramas que no debieran ser enrutados fuera del enlace físico. En realidad, si un equipo recibe un datagrama con un valor menor, significa que la información proviene de otra red y que ya ha atravesado al menos un enrutador. Por ello, los datagramas que tienen un valor diferente de 255 deben ser ignorados por el receptor.

{{Tableau eICMPv6}}

El protocolo realiza varias funciones:

* Resolución de direcciones. El principio es muy similar al del protocolo ARP de IPv4. La principal diferencia consiste en el uso de mensajes ICMPv6 estándar en lugar de definir otro protocolo de capa 3. Con esto se consigue una mayor flexibilidad de uso, especialmente en las redes que no soportan la difusión de mensajes. Al igual que en IPv4, el protocolo se encarga de construir tablas de correspondencia entre las direcciones IPv6 y las físicas.
* <div vecinos id="NUD"> Detección de inaccesibilidad de vecinos (NUD, ''Neighbor Unreachability Detection''). Esta función, que no existe en IPv4, permite eliminar de las tablas de configuración de un equipo, los vecinos que se han vuelto inaccesibles (por fallas, cambio de domicilio, ...). Si un enrutador deja de estar disponible, la tabla de enrutamiento puede ser modificada para considerar otra ruta. </div>
* Configuración. La configuración automática de los dispositivos es uno de los principales atractivos de IPv6. Se implementan varias funcionalidades del protocolo de descubrimiento de vecinos:
**Descubrimiento de enrutadores. Este protocolo permite que los dispositivos identifiquen a los enrutadores que se encuentran en su enlace físico. En IPv4, esta función la proporciona el protocolo ''ICMP Router Discovery''.
** Descubrimiento de prefijos. El dispositivo conoce el o los prefijos de red de acuerdo a los anuncios realizados por los enrutadores. Agregando su identificador de interfaz, el dispositivo construye su o sus direcciones IPv6. No hay un mecanismo equivalente para las direcciones IPv4 ya que son demasiado cortas para realizar la auto-configuración.
** Detección de direcciones duplicadas. Dado que las direcciones se configuran de forma automática, existen riesgos de error en caso de tener equipos con identificadores repetidos. Este protocolo verifica que ningún otro equipo en el enlace tiene la misma dirección IPv6. Esta función es una evolución del ARP gratuito en IPv4 emitido durante la inicialización de la interfaz.
** Descubrimiento de parámetros. Este protocolo permite que los dispositivos conozcan los distintos parámetros del enlace físico, por ejemplo, el tamaño de MTU, el número máximo de saltos permitido (valor original del campo número de saltos), si la configuración automática con estado (como [[Configuración con estado: DHCPv6|DHCPv6]]) está activa, etc. No existe un equivalente de esta funcionalidad en IPv4.
* Indicación de redirección. Este mensaje se utiliza cuando un enrutador conoce una trayectoria mejor (medida en número de saltos) para alcanzar un destino.
:En IPv4 una indicación de redireccionamiento sólo puede servir para corregir la dirección del enrutador utilizado para acceder a una máquina fuera de la red local. Los dispositivos deben conocer todas las direcciones correspondientes a equipos conectados en su propia red local.
:EnIPv6, la correspondencia entre prefijo y red local es menos rígida. Es de esperar que un dispositivo no conozca todos los prefijos de su red local (si ésta es compartida por varios prefijos), o que un prefijo se comparta entre varios enlaces (lo que corresponde a una generalización del modelo de redes lógicas IP sobre ATM). Bajo algunas configuraciones, la máquina emitirá sus paquetes al enrutador aún si el destinatario se encuentra en el mismo segmento que el emisor. En este caso, el enrutador emitirá un mensaje de redirección para que la continuación del diálogo entre ellos haga de manera directa (véanse los ejemplos [[#IR|Indicación de redirección]]).
:En el caso más extremo, podría imaginarse en IPv6 que un dispositivo puede ser configurado para comunicarse únicamente con su enrutador por omisión. ICMPv6 ''redirect'' puede utilizarse entonces, para informar al dispositivo de destinatarios ubicados en el mismo enlace.

En IPv6 se especifican dos métodos de autoconfiguración para las direcciones unicast global:

* Autoconfiguración sin estado (''stateless autoconfiguration'', RFC 2462). Se utiliza cuando no es necesaria una gestión administrativa de las direcciones asignadas dentro de un sitio. Estos mecanismos se describen más adelante en este capítulo.
* Autoconfiguración con estado (''statefull autoconfiguration''). Se utiliza cuando un sitio requiere de un control estricto de la asignación de direcciones (''cf'' [[Configuración con estado: DHCPv6 | DHCPv6]]).

Sin embargo, el uso de DHCPv6 para obtener la dirección se controla mediante el protocolo de descubrimiento de vecinos.

= Datos transmitidos por los mensajes =

La principal motivación detrás del Protocolo de Descubrimiento de vecinos es unificar varios protocolos existentes en IPv4. En particular, la mayor parte de los datos utiliza un formato de opciones común, lo que simplifica la implementación del protocolo. El formato contiene los campos: tipo, longitud (en palabras de 64 bits), y datos. La baja precisión de campo longitud, presentará un desperdicio de espacio, pero permite una alineación de las opciones en palabras de 64 bits, lo que permite un procesamiento optimizado.

{{NB-Opciones}}

== <div id="física">Dirección física de la fuente/destino</div> ==

<tikz title="Formato de la opción dirección física fuente/destino">
\clip (0.2, 5.7) rectangle (11.1,6.7);
% \draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=1/2}};
\draw (2.9, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{lenght }};
\draw (5.3, 6) node (addr) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Link Layer Address}};

\draw [draw=white, thick] (addr.north east) -- (addr.south east);
\draw [draw=white, thick] (addr.north east) -- +(-2, 0);
\draw [draw=white, thick] (addr.south east) -- +(-2, 0);

\draw [dashed] (addr.north east) -- (addr.south east);
\draw [dashed] (addr.north east) -- +(-2, 0);
\draw [dashed] (addr.south east) -- +(-2, 0);
</tikz>

La figura ''Formato de la opción dirección física fuente/destino'' presenta estas opciones. El tipo 1 designa la dirección física de la fuente y el tipo 2 la dirección del destino.

El campo ''length'' es el tamaño en palabras de 64 bits de la opción. Por lo tanto, para el caso de una dirección MAC con longitud de 6 octetos, contiene el valor 1.

El RFC 2464 define el formato para las direcciones MAC-48 utilizadas en las redes Ethernet y Wi-Fi. El RFC 4944 define el formato para las direcciones MAC-16 y MAC-64 utilizadas en las redes de sensores bajo la norma IEEE 802.15.4.

== <div id="información">Información sobre el prefijo</div> ==

<tikz title="Formato de la opción información sobre el prefijo">
\clip (0.2, 2) rectangle (11.1, 7);
% \draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=3}};
\draw (2.9, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{length =4 }};
\draw (5.3, 6) node (addr) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm] {\tiny{Prefix Length}};
\draw (7.7, 6) node (bitL) [right, shade, top color=blue!15, bottom color=blue!5,, draw, minimum height=0.5cm, minimum width=.3cm]{}; \draw (bitL.text) node {\tiny{L}};
\draw (8, 6) node (bitA) [right, shade, top color=blue!15, bottom color=blue!5,, draw, minimum height=0.5cm, minimum width=.3cm]{};\draw (bitA.text) node {\tiny{A}};
\draw (8.3, 6) node (bitR) [right, shade, top color=blue!15, bottom color=blue!5,, draw, minimum height=0.5cm, minimum width=.3cm]{};\draw (bitR.text) node {\tiny{R}};
\draw (8.6, 6) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=1.5cm] {\tiny{Reserved}};

\draw (0.5, 5.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Valid Lifetime}};

\draw (0.5, 5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Prefered Lifetime}};

\draw (0.5, 4.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Reserved}};

\draw (0.5, 4) node (addr1) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{}};
\draw (0.5, 3.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{}};
\draw (0.5, 3) node (addr3) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Prefix}};
\draw (0.5, 2.5) node (addr4) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{}};

\draw [color=blue!10, very thick] (addr1.south east) -- (addr1.south west);
\draw [color=blue!10, very thick] (addr2.south east) -- (addr2.south west);
\draw [color=blue!10, very thick] (addr3.south east) -- (addr3.south west);
</tikz>

Esta opción contiene las informaciones sobre el prefijo para permitir una configuración automática de los dispositivos. El campo tipo tiene el valor 3 y el de longitud, 4. La figura ''Formato de la opción información sobre el prefijo'' muestra el formato de esta opción:

* El campo ''Prefix lenght'' indica cuántos bits son significativos para el prefijo anunciado en un campo siguiente.
* El bit <tt>L</tt> indica, cuando vale 1, que el prefijo permite indicar que todos los demás dispositivos que comparten el mismo prefijo, están en el mismo enlace, por lo que el emisor puede contactarlos directamente. En caso contrario, el dispositivo envía el paquete hacia el enrutador. Si éste último sabe que el emisor puede contactar directamente al destinatario, emitirá un mensaje ICMPv6 de indicación de redirección.
* El bit <tt>A</tt> indica, cuando vale 1, que el prefijo anunciado puede utilizarse para formar la dirección del dispositivo.
* El bit <tt>R</tt>, indica, cuando vale 1, que el campo prefijo contiene la dirección global de un enrutador ''agente base''. Los bits de mayor peso aún pueden utilizarse para formar un prefijo.
* El campo duración de validez indica, en segundos, la duración durante la cual el prefijo es válido.
* El campo duración preferente indica la duración, en segundos, durante la cual una dirección formada con el protocolo de configuración sin estado se mantiene ''preferente'' (''cf'' [[Planes de direccionamiento|Tiempo de vida de las direcciones]]).

Para estos dos campos, un valor de <tt>0xffffffff</tt> representa una duración infinita. Estos campos pueden servir durante la fase de transición de un proveedor de acceso a otro; es decir, de un prefijo a otro.
* El campo reservado permite alinear el prefijo a una frontera de palabra de 64 bits.
* El campo prefijo contiene el valor de prefijo anunciado sobre el enlace. Para mantener una alineación de 64 bits para el resto de datos del paquete, este campo tiene una longitud fija de 128 bits.

== <div id="redirigida">Cabecera de redirección </div> ==

<tikz title="Formato de la opción cabecera de redirección">
\clip (0.2, 3.1) rectangle (11.1, 7);
% \draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=5}};
\draw (2.9, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{length =1 }};
\draw (5.3, 6) node (addr) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Reserved}};

\draw (0.5, 5.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Reserved}};

\draw (0.5, 4.25) node (context) [right, shade, top color=purple!50, bottom color=purple!10, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{IPv6 Header and Data}};
</tikz>

Esta opción es utilizada por el mensaje de indicación de redirección. Permite encapsular los primeros octetos del paquete IPv6 que provocó la emisión de este mensaje, como ocurre con los mensajes de error de ICMPv6.

El campo tipo tiene el valor 4. El tamaño de esta opción debe evitar que el paquete IPv6 rebase los 1280 octetos (''cf'' figura ''Formato de la opción cabecera de redirección''). Sin embargo, el paquete debe contener la mayor cantidad de información posible.

== <div id="MTU">MTU</div> ==

<tikz title="Formato de la opción MTU">

\clip (0.2, 5.1) rectangle (11.1, 7);
% \draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=5}};
\draw (2.9, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{lenght =1 }};
\draw (5.3, 6) node (addr) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Reserved}};

\draw (0.5, 5.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{MTU}};
</tikz>

Esta opción permite notificar a los dispositivos el tamaño máximo de datos que pueden ser transmitidos sobre el enlace. La figura ''Formato de la opción MTU'' muestra su estructura. No es necesario difundir esta información si el dispositivo utiliza siempre el tamaño máximo permitido. Por ejemplo, sobre las redes Ethernet, los dispositivos utilizarán el valor 1,500. En cambio, en las redes Token Ring o FDDI, con frecuencia es necesario especificar si los equipos pueden utilizar la longitud máxima o un tamaño inferior para permitir el uso de puentes en la red.

En esta opción, el campo tipo tiene un valor de 5 y el de longitud, de 1.

=Mensajes estándar de Descubrimiento de vecinos =

Además de las cinco opciones básicas descritas en la tabla ''Utilización de las opciones en los mensajes de descubrimiento de vecinos'', existen otras específicas para la movilidad y para las redes NBMA (''Non Broadcast Multiple Access'').

{|
|+ Utilización de las opciones en los mensajes de descubrimiento de vecinos
| width = 150 | || width = 100 |[[#RS|Solicitud de]] || width = 100 |[[#RA|Anuncio de]] || width = 100 |[[#NS|Solicitud de]] ||width = 100 | [[#NA|Anuncio de]] ||width = 100 |[[#IR|Indicación de]]
|-
| || [[#RS|enrutador]] || [[#RA|enrutador]] || [[#NS|un vecino]] || [[#NA| un vecino]] || [[#IR|redirección]]
|-style="background:silver"
|[[#física |Dirección física de la fuente]] || presente || presente || presente || ||
|-
|[[# física | Dirección física del destino]] || || || || presente || presente
|-style="background:silver"
|[[#información|Información sobre el prefijo]] || || ≥ 1 || || ||
|-
|[[#redirigida |Cabecera de redirección]] || || || || || presente
|-style="background:silver"
| [[#MTU |MTU]] || || posible || || ||
|}

Las distintas funcionalidades de descubrimiento de vecinos utilizan cinco mensajes: dos para el diálogo entre un dispositivo y un enrutador, dos para el diálogo entre vecinos, y uno para la redirección. Cada uno de estos mensajes puede incluir opciones adicionales.

== <div id="RS">Solicitud de enrutador</div> ==

<tikz title="Formato de los paquetes de solicitud de enrutador">
\clip (0.2, 3.5) rectangle (11.1,7.1);
%\draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=133}};
\draw (2.9, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code =0 }};
\draw (5.3, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};
\draw (0.5, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Reserved}};

\draw (0.5, 4.25) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Options:\\
- Source link-layer address
}};
</tikz>

El mensaje de solicitud de enrutador (''cf'' figura Formato de los paquetes de solicitud de enrutador) es emitido al iniciar un dispositivo para recibir más rápidamente la información del enrutador. Este mensaje se envía a la dirección IPv6 multicast reservada a los enrutadores en el mismo enlace <tt>FF02::2</tt>. Si el dispositivo aún no conoce su dirección fuente, se utiliza la dirección no especificada.

El campo opción normalmente contiene la dirección física del dispositivo.

== <div id="RA">Anuncio de enrutador</div> ==

<tikz title="Formato de los paquetes de anuncio de enrutador">
\clip (0.2, 1.5) rectangle (11.1,7.1);
%\draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=134}};
\draw (2.9, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code =0 }};
\draw (5.3, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};

\draw (0.5, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Cur. Hop Lim.}};
\draw (2.9, 5.5) node (bitM) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{}; \draw (bitM.text) node {\tiny{M}};
\draw (3.2, 5.5) node (bitO) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{};\draw (bitO.text) node {\tiny{O}};
\draw (3.5, 5.5) node (bitH) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{};\draw (bitH.text) node {\tiny{H}};
\draw (3.8, 5.5) node (res) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=1.5cm]{\tiny{reserved}};
\draw (5.3, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Router Lifetime}};

\draw (0.5, 5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=9.6cm]{\tiny{Reachable Time}};
\draw (0.5, 4.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=9.6cm]{\tiny{Retrans Time}};

\draw (0.5, 3.25) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Options:\\
Source link-layer address\\
MTU\\
Prefix Information (may be repeated)\\
}};
</tikz>

Este mensaje (''cf'' figura ''Formato de los paquetes de anuncio de enrutador'') es emitido periódicamente por los enrutadores, o bien, en respuesta a un mensaje de solicitud de enrutador generado por un dispositivo. El campo dirección fuente contiene la dirección de enlace local del enrutador, mientras que el campo dirección destino contiene la dirección del dispositivo que generó la solicitud, o la dirección de todas las estaciones (<tt>ff02::01</tt>).

Cuando el campo de máximo número de saltos tiene un valor distinto de cero, muestra el valor que podría colocarse en el campo de número de saltos de los paquetes emitidos. El bit <tt>M</tt> indica que una dirección del dispositivo debe ser obtenida mediante un protocolo de configuración (''cf'' [[Configuración con estado:DHCPv6]]). El bit <tt>O</tt> también indica la presencia de un servicio de configuración para obtener información adicional a la dirección. Si no es posible obtener la dirección mediante un servidor, el dispositivo procede a realizar una configuración sin estado, concatenando su identificador de interfaz a los prefijos que conoce. El bit <tt>H</tt> indica que el enrutador puede ser utilizado como agente base por un nodo móvil (''cf'' [[Desplazamientos_de_móviles#Anuncio_del_agente_base |Anuncio del agente base]]).

El campo tiempo de vida del enrutador indica el período (en segundos) durante el cual el equipo que emite el anuncio realizará funciones de enrutador por omisión. El valor máximo corresponde a 18 horas 12 minutos, pero como este mensaje se emite periódicamente, en la práctica no existe un límite para el tiempo de vida de un enrutador. Un valor de <tt>0</tt> indica que el dispositivo no cumple con las funciones de enrutador por omisión. Este tiempo de vida no se aplica a las opciones transportadas por este mensaje.

El campo duración de accesibilidad indica el período (en milisegundos) durante el cual una información almacenada en la memoria caché de la máquina (por ejemplo, la tabla de correspondencia entre las direcciones IPv6 y las físicas) puede ser considerada como válida. Al vencimiento de este tiempo, se emite un mensaje de detección de inaccesibilidad para verificar la pertinencia de la información almacenada.

El campo temporización de retransmisión muestra el período (en milisegundos) entre dos emisiones no solicitadas de este mensaje. Permite que los demás equipos puedan detectar la inaccesibilidad de un enrutador.

Este mensaje puede transportar las siguientes opciones:

* dirección física de la fuente,
* MTU,
* información sobre el prefijo (uno o varios).

== <div Id="NS"> Solicitud de un vecino </div> ==

<tikz title="Formato de los paquetes de solicitud de un vecino">

\clip (0.2, 1.5) rectangle (11.1,7.1);
%\draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=135}};
\draw (2.9, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code =0 }};
\draw (5.3, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};

\draw (0.5, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=9.6cm]{\tiny{Reserved}};

\draw (0.5, 4.25) node (context) [right, shade, top color=blue!50, bottom color=blue=!10, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Target Address}};

\draw (0.5, 2.25) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Options:\\
Source link-layer address\\
}};
</tikz>

Este mensaje (''cf'' figura ''Formato de los paquetes de solicitud de un vecino'') permite obtener información a partir de un equipo vecino, es decir, localizado en el mismo enlace físico (o conectado a través de puentes). El mensaje puede ser emitido explícitamente a él, o enviado con una dirección de difusión. En el caso de determinación de la dirección física, éste corresponde a la solicitud de ARP en IPv4.

El campo dirección fuente del paquete IPv6 contiene ya sea la dirección local al enlace, una dirección global o la dirección no especificada. El campo destino puede contener la dirección de difusión múltiple solicitada correspondiente a la dirección buscada (''cf'' [[Direccionamiento_multicast#Identificador_de_grupo|Identificador de grupo]]) o la dirección del dispositivo (en el caso de una detección de inaccesibilidad de vecinos, ''NUD'').

El campo dirección del destino contiene la dirección IPv6 del equipo buscado. El campo opción generalmente contiene la dirección física de la fuente.

== <div Id="NA"> Anuncio de un vecino</div> ==

<tikz title="Formato de los paquetes de anuncio de un vecino">

\clip (0.2, 1.5) rectangle (11.1,7.1);
%\draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=136}};
\draw (2.9, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code =0 }};
\draw (5.3, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};

\draw (0.5, 5.5) node (bitR) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{}; \draw (bitR.text) node {\tiny{R}};
\draw (0.8, 5.5) node (bitS) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{}; \draw (bitS.text) node {\tiny{S}};
\draw (1.1, 5.5) node (bitO) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{}; \draw (bitO.text) node {\tiny{O}};
\draw (1.4, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=8.7cm]{\tiny{Reserved}};

\draw (0.5, 4.25) node (context) [right, shade, top color=blue!50, bottom color=blue=!10, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Target Address}};

\draw (0.5, 2.25) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Options:\\
Source link-layer address\\
}};
</tikz>

Este mensaje (''cf'' figura ''Formato de los paquetes de anuncio de un vecino'') se emite en respuesta a una solicitud, aunque también puede ser emitido de forma espontánea para propagar la información de cambio de dirección física, o del estado de "enrutador". Para el caso de la determinación de la dirección física, es equivalente a la respuesta ARP en IPv4.

* El bit <tt> R </tt> se pone a 1 si el remitente es un enrutador. Este bit se utiliza para permitir la detección de un enrutador que se convierte en un equipo ordinario.
* El bit <tt> S </tt> en 1 indica que este anuncio se emite en respuesta a una solicitud.
* El bit <tt> O </tt> en 1 indica que este anuncio debe borrar las informaciones anteriores que se encuentran almacenadas en la memoria cachés de otros equipos, en especial la tabla que contiene las direcciones físicas.
* El campo dirección del destino contiene, si el bit<tt> S </tt> es 1, el valor del campo dirección del destino de la solicitud a la que está respondiendo este mensaje. Si el bit <tt> S </tt> es 0, este campo contiene la dirección IPv6 local al enlace del equipo emisor.
* La opción dirección física del destino contiene la dirección física del emisor.

== <div id="IR">Indicación de redirección</div> ==

<tikz title="Formato de los paquetes de indicación de redirección">
\clip (0.2, 0) rectangle (11.1,7.1);
%\draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=137}};
\draw (2.9, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code =0 }};
\draw (5.3, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};

\draw (0.5, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=9.6cm]{\tiny{Reserved}};

\draw (0.5, 4.25) node (context) [right, shade, top color=blue!50, bottom color=blue=!10, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Target Address}};

\draw (0.5, 2.25) node (context) [right, shade, top color=blue!50, bottom color=blue=!10, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Destination Address}};

\draw (0.5, 0.5) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=1.5cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Options:\\
Target link-layer address\\
Redirected Header\\
}};
</tikz>

La técnica de redirección es la misma que en IPv4. Un dispositivo sólo conoce los prefijos de las redes a las que está conectado directamente y la dirección de un enrutador por omisión. Si la ruta se puede optimizar, el enrutador por omisión envía un mensaje para indicar que existe un camino más corto. De hecho, como en IPv6 el enrutador por omisión se establece de forma automática, las rutas no necesariamente son las mejores (''cf'' figura ''Enrutamiento por omisión no óptimo'').

Otro caso particular en IPv6 ocurre con los dispositivos que se encuentran en el mismo enlace físico, pero tienen diferentes prefijos. La comunicación entre ellos pasa inicialmente a traves de enrutador por omisión hasta que éste notifica que existe una ruta directa entre ellos.

La figura ''Formato de los paquetes de indicación de redirección'' muestra el formato del mensaje:

* El campo dirección objetivo (''Target address'') contiene la dirección IPv6 del equipo hacia el que los paquetes deben ser enviados.
* El campo dirección destino contiene la dirección IPv6 del dispositivo que está siendo redirigido hacia la dirección objetivo.

Cuando la redirección apunta a un dispositivo situado en el mismo enlace, la dirección objetivo y de destino son las mismas.

Las opciones incluyen la dirección física de un nuevo enrutador y la cabecera del paquete redirigido.

Este mensaje se puede utilizar de la misma forma que en IPv4. Un dispositivo solamente tiene una ruta por omisión para acceder a equipos con un prefijo diferente. En consecuencia, envía su paquete al enrutador por omisión, quien observa que el prefijo destino es accesible a través de la misma subred que el emisor. El enrutador por omisión reenvía el paquete y notifica al emisor que puede contactar directamente a las máquinas que poseen el prefijo del destino.

IPv6 también utiliza este mensaje para optimizar la resolución fuera del enlace para el [[#Caso de redes NBMA |caso de redes NBMA]].

= Configuración automática =
Tradicionalmente, la configuración de una interfaz de red de una máquina se hacía manualmente. Esto suele ser un trabajo lento y propenso a errores. Con IPv6, se automatiza el proceso de configuración y se introducen, al mismo tiempo, mecanismos de funcionamiento inmediato (''plug and play'') a la interfaz de red. La configuración automática significa que un dispositivo obtendrá toda la información necesaria para su conexión a una red local IP sin ninguna intervención humana. En el caso ideal, cualquier usuario desempaca su nuevo equipo, lo conecta a la red local y lo ve funcionar sin tener que introducir la información propia de "especialistas". Ahora vamos a discutir otro aspecto de la configuración automática de IPv6, la auto-configuración de direcciones, que tiene como objetivos:

* La adquisición de una dirección cuando un dispositivo está conectado a una red por primera vez;
* la posibilidad de asignar otros prefijos, o de renumerar un dispositivo.

El proceso de configuración automática de direcciones IPv6 incluye la creación de una dirección local al enlace, la agregación a grupos multicast solicitados, la verificación de la unicidad de la dirección local al enlace y la creación de direcciones unicast global.

La tarea del enrutador es importante en la configuración automática. Indica a la máquina, mediante los bits de la cabecera (''cf'' [[#RA|anuncio de enrutador]]), del mensaje de anuncio de los enrutadores, el método a conservar y eventualmente proporcionar la información necesaria para su configuración. El bit <tt> M </tt> (''configuración de dirección administrada'') puesto a 1 indica que el equipo no debe crear por sí mismo una dirección a partir de su identificador de interfaz y de los prefijos recibidos, sino que debe solicitarla explícitamente ante un servidor de direcciones. El bit O <tt> </tt> (''otra configuración de estado'') indica que el dispositivo debe consultar el servidor para obtener otros parámetros distintos de la dirección. El algoritmo para el proceso de configuración automática de direcciones se desglosa de la siguiente manera:

* La primera fase consiste en crear la dirección local al enlace.
* Una vez que la unicidad de esta dirección es verificada, el dispositivo está listo para comunicarse con otras máquinas en el enlace.
* El dispositivo debe tratar de adquirir un mensaje de anuncio de enrutadores para determinar el método de obtención de la dirección unicast global.
* Si hay un enrutador en el enlace, el dispositivo debe aplicar el método especificado por el mensaje de anuncio de enrutadores, a saber:
** La configuración automática sin estado,
** la configuración automática con estado.
* Si no hay ningún enrutador en el enlace, el dispositivo debe tratar de obtener la dirección unicast global por el método de configuración automática con estado. Si el intento falla, no hay más que hacer. Las comunicaciones sólo podrán hacerse sobre el enlace con la dirección local al enlace, pues el dispositivo no tendrá una dirección con la cobertura necesaria que le permita comunicarse con otras máquinas fuera del enlace.

==Ciclo de vida de una dirección==

Al generalizar en IPv6 el plan de direccionamiento CIDR, los prefijos quedan, en todos los casos, siendo propiedad de los operadores. Ya no pueden otorgarse "a perpetuidad" a los dispositivos. Para facilitar la renumeración de una máquina, la asignación de una dirección a una interfaz es temporal, las direcciones IPv6 no se entregan, sino que se prestan. Se asocia un tiempo de vida a la dirección, que indica el tiempo durante el cual la dirección pertenece a la interfaz. Cuando el tiempo de vida se ha agotada, la dirección deja de ser válida, se suprime de la interfaz y queda potencialmente éste puede prolongarse indefinidamente. La dirección local al enlace tiene un tiempo de vida ilimitado.

<tikz title="Estados sucesivos de una dirección en una interfaz">

\draw [thick, ->] (0,2) -- (9.5,2);

\draw [->] (1,4) node [above=10pt] {\tiny{allocation}}-- (1,2);
\draw (1, 2) node [rectangle, minimum width=1cm, minimum height=1cm, fill, left color=black!10, right color=black!20, draw=black, above right] (tentative) {};
\draw (tentative.south east) node [rectangle, minimum width=3cm, minimum height=1cm, fill, left color=green, right color=green!50, draw=black, above right] (preferred) {};
\draw (preferred.south east) node [rectangle, minimum width=2cm, minimum height=1cm, fill, left color=orange , right color=orange!50!red, draw=black, above right] (deprecated) {};
\draw (deprecated.south east) node [rectangle, minimum width=2cm, minimum height=1cm, fill, color=red, draw=black, above right] (novalid) {};

\draw (tentative.text) node {\tiny{Tentative}};
\draw (preferred.text) node {\tiny{Preferred}};
\draw (deprecated.text) node {\tiny{Deprecated}};
\draw (novalid.text) node {\tiny{Invalid}};

\draw [dotted] (tentative.south west) -- +(0, -1);
\draw [dotted] (preferred.south west) -- +(0, -1);
\draw [dotted] (deprecated.south west) -- +(0, -1);
\draw [dotted] (novalid.south west) -- +(0, -1);

\draw [dashed, <->] ([yshift=-0.5cm]tentative.south west) -- node [above] {\tiny{DAD}} ([yshift=-0.5cm] preferred.south west) ;

\draw [dashed, <->] ([yshift=-0.5cm]preferred.south west) -- node [above] {\tiny{Valid}} ([yshift=-0.5cm] novalid.south west) ;

</tikz>

La renumeración de una interfaz consiste en pasar de una dirección a otra. Durante una renumeración, no es aconsejable cambiar repentinamente de dirección, de lo contrario, todas las comunicaciones TCP que la utilizan como identificador de conexión, se cortarían inmediatamente. Esto conllevaría importantes perturbaciones a nivel de las aplicaciones.

Por ello, para facilitar esta transición se implementó un mecanismo de obsolescencia que invalida gradualmente una dirección. Este mecanismo se sirve de la capacidad de asignación de varias direcciones válidas a una misma interfaz. Para elegir la dirección a utilizar, se le asocia un estado que indica en qué fase de su tiempo de vida se encuentra con respecto a la interfaz. El primero de esos estados se conoce como preferido: no hay ninguna restricción de uso. Poco antes de su invalidación, la dirección pasa a un estado de depreciado. En él se desaconseja el uso de la dirección, pero no está prohibido. Una dirección depreciada ya no debe ser utilizada como dirección fuente de nuevas comunicaciones (como el establecimiento de conexión TCP), pero todavía puede emplearse como dirección fuente de comunicaciones ya establecidas. Los paquetes recibidos a una dirección depreciada seguirán siendo entregados normalmente. El control de la duración de cada estad de una dirección válida se efectúa agregando un tiempo de vida al estado preferido.
La figura '''Estados sucesivos de una dirección en una interfaz''' representa los diferentes estados que toma una dirección cuando se asigna a una interfaz.

== Creación de la dirección local al enlace ==

<tikz title=" Creación de la dirección local al enlace">
\clip (0, 0) rectangle (10,7);
% \draw[help lines] (0,0) grid (10,7 );

\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,3)--(9,3);

\pgfputat{\pgfxy(0.8,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,5)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,3)--(1.5,5);
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (8,3)--(8,5);

\draw (1.5,4.5) node {\small{FE80::IID1}};
\draw (1.5,4) node {\small{$\alpha$::IID1/64}};

\draw (8, 4.5) node {\small{FE80::IID2}};

</tikz>

Durante la inicialización de la interfaz, el dispositivo construye un identificador de interfaz que debe ser único en el enlace. Este identificador se utiliza la dirección de [[ Identificador_de_interfaz#EUI-64 | EUI-64]]. El principio básico para crear la direcciónIPv6 consiste en unir un prefijo con el identificador. La dirección local al enlace se crea tomando el prefijo de Enlace_local (<tt>FE80::/64</tt>). La dirección creada de esa manera, todavía no puede ser utilizada; tiene un estado temporal pues el dispositivo debe comprobar la exclusividad de esta dirección en el enlace mediante el procedimiento de detección de direcciones duplicadas. Si se encuentra que la dirección local al enlace no es única, se suspende la autoconfiguración y será necesario proceder a una configuración manual.

Una vez que se ha asegurado la unicidad de la dirección local al enlace, ésta se considera una dirección válida para la interfaz, con lo que termina la prima fase del proceso de autoconfiguración.

==<div id="DAD"> Detección de una dirección duplicada </div>==

<tikz title="Emisión de un NS en una detección de Dir. duplicada (DAD)">
\clip (0, 0) rectangle (10,7);
% \draw[help lines] (0,0) grid (10,7 );

\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,3)--(9,3);

\pgfputat{\pgfxy(0.8,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,5)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,3)--(1.5,5);
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (8,3)--(8,5);

\draw (7.8, 5) -- (7.8, 3.2);
\draw [<->] (1, 3.2) -- node [above] {\tiny{::/0 -$>$ solicited (FE80:IID2) : NS (who has FE80::IID2?)}}(9, 3.2) ;

</tikz>

Para comprobar la exclusividad de direcciones locales al enlace o de direcciones unicast, los dispositivos deben ejecutar un algoritmo de detección de direcciones duplicadas (DAD) antes poder utilizarlas. El algoritmo usa los mensajes ICMPv6 [[Protocolo_de_Descubrimiento_de_vecinos#NS|solicitud de un vecino]] y [[#NA|anuncio de un vecino.]] Si se detecta una dirección que ya está en uso, ésta no podrá ser asignada a la interfaz, la autoconfiguración automática debe suspenderse y será necesario proceder a una configuración manual. Durante la ejecución del algoritmo DAD, la dirección es considerada como "provisional" hasta tener la confirmación de su unicidad. Una dirección provisional se asigna a una interfaz únicamente para recibir los mensajes de solicitud y anuncio de un vecino. Otros mensajes recibidos, son ignorados. El algoritmo DAD consiste en enviar un mensaje de solicitud de un vecino colocando en el campo de dirección objetivo la dirección provisional. Para distinguir el algoritmo DAD del de Descubrimiento de vecinos, el paquete IPv6 que contiene un mensaje de solicitud de un vecino tiene como dirección fuente una dirección no determinada. Así se presentan tres casos:

* Se recibe un mensaje de anucio de un vecino: Significa que la dirección provisional está siendo utilizada como válida por otro dispositivo, por lo que ésta no es única y no puede ser retenida por el dispositivo.
* Se recibe un mensaje de solicitud de un vecino como parte del algoritmo DAD. La dirección provisional también es provisional para otra máquina. En este caso, la dirección provisional no puede ser utilizada por ninguna de ellas.
* No se recibe ningún mensaje durante un segundo (valor por omisión). La dirección provisional es única, por lo que su estado pasa de provisional a válida y se le asigna a la interfaz.

Obsérvese que este algoritmo no proporciona una fiabilidad absoluta, especialmente cuando el enlace está segmentado.

== Autoconfiguración sin estado ==

<tikz title="Emisión de un RS">
\clip (0, 0) rectangle (10,7);
% \draw[help lines] (0,0) grid (10,7 );

\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,3)--(9,3);

\pgfputat{\pgfxy(0.8,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,5)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,3)--(1.5,5);
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (8,3)--(8,5);

\draw (7.8, 5) -- (7.8, 3.2);
\draw [<->] (1, 3.2) -- node [above] {\tiny{FE80::IID2 -$>$ FF02::2 : RS }} (9, 3.2) ;

</tikz>

La configuración automática sin estado (RFC 2462) no requiere de ninguna configuración manual de los dispositivos, una configuración mínima para los enrutadores, y tampoco necesita de servidores adicionales. Se sirve del protocolo ICMPv6 y puede operar aún sin la presencia de enrutadores. En cambio, sí requiere de una subred con soporte a la difusión de paquetes. Este método sólo aplica para los dispositivos; no puede ser utilizada para configurar enrutadores. El principio básico de este mecanismo consiste en que una máquina genera su dirección IPv6 a partir de información local y de la proporcionada por un enrutador. El enrutador proporciona información sobre la subred asociada al enlace; anuncia el prefijo.

<tikz title="Recepción de un RA">
\clip (0, 0) rectangle (10,7);
% \draw[help lines] (0,0) grid (10,7 );

\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,3)--(9,3);

\pgfputat{\pgfxy(0.8,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,5)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,3)--(1.5,5);
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (8,3)--(8,5);

\draw [->] (1.7,5) -- (1.7, 3.2) -- node [above = 10pt] {\tiny{FE80::IID1 -$>$ FE80::IID2}} node [above] {\tiny{RA ($\alpha$::/64, DHCPv6, MTU=1500, HL=64, {bit {\tt M=1}) }}} (7.8, 3.2) -- (7.8, 5);

</tikz>

Al igual que para la creación de la dirección de enlace local, la dirección unicast global se obtiene al concatenar el prefijo con el identificador de la interfaz. El prefijo se obtiene del mensaje de anuncio de enrutador, más concretamente, de la opción de ''información sobre el prefijo''. Si bien debe verificarse la unicidad de todas las direcciones unicast, en el caso de una dirección unicast obtenida mediante la configuración automática sin estado, esto no es obligatorio, pues la unicidad del identificador de la interfaz ya fue comprobada durante la configuración de la dirección local al enlace. Dado que el identificador es el mismo, no puede haber ambigüedad sobre la exclusividad de la dirección unicast global creada de esta forma.

La renumeración de los dispositivos en un enlace se realiza mediante enrutadores que transfieren las direcciones utilizadas a un estado depreciado y al mismo tiempo anuncian el nuevo prefijo con el que los dispositivos pueden re-crear una dirección preferida.

===Caso de redes NBMA ===

<tikz title="Off Link NDP: Primera etapa">
\clip (0, 0) rectangle (11,7);
% \draw[help lines] (0,0) grid (10,7 );

\pgfputat{\pgfxy(4.5,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}
\pgfputat{\pgfxy(1.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[decorate,decoration={zigzag}, color=black!60, ->, very thick] (8,3)-- node [above, color=black] {\tiny{FE80::IID2 -$>$ FF02::2 : RS}} (5,5);

</tikz>

Las redes NBMA (''Non Broadcast Multiple Access'') se caracterizan por no contar con un mecanismo de difusión hacia todos los dispositivos. Esto conduce a dos situiaciones posibles:
* ausencia total de difusión, como en las redes públicas (telefónica, ATM, …) en las que un solo destinatario puede ser contactado a la vez
* posibilidad de difusión por un número limitado de equipos, como es el caso de las redes de radio tipo 3G, WiMAX, en las que la estación base tiene la posibilidad de difundir datos hacia todos los equipos, pero esto no es posible en el sentido inverso (desde un dispositivo).

<tikz title="Off Link NDP: Segunda etapa">
\clip (0, 0) rectangle (11,7);
% \draw[help lines] (0,0) grid (10,7 );

\pgfputat{\pgfxy(4.5,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}
\pgfputat{\pgfxy(1.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[decorate,decoration={zigzag}, color=black!60, ->, very thick] (5, 5)-- node [above, color=black] {\tiny{RA ($\alpha$::/64, DHCPv6, OffLink, MTU=1500, HL=64, {bit {\tt M=1}})}} (8,3);

</tikz>

Un comportamiento de redes NBMA también puede ser deseable para limitar las restricciones de consumo energético. Por ejemplo, en el caso de redes de sensores, la difusión, o la difusión restringida (multicast) son costosas en consumo de energía pues todos los dispositivos deben procesar el mensaje y algunos deberán retransmitirlo.

<tikz title="Off Link NDP: Tercera etapa">
\clip (0, 0) rectangle (11,7);
% \draw[help lines] (0,0) grid (10,7 );

\pgfputat{\pgfxy(4.5,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}
\pgfputat{\pgfxy(1.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[decorate,decoration={zigzag}, color=black!60, ->, very thick] (8,3)-- node [left, near start, color=black] {\tiny{$\alpha$::IID2 -$>$ $\alpha$::IID3 : DATA}} (5,5);

\draw[decorate,decoration={zigzag}, color=black!60, ->, very thick] (5,5)-- node [left, midway, color=black] {\tiny{$\alpha$::IID2 -$>$ $\alpha$::IID3 : DATA}} (2,3);

</tikz>

Para estos casos, el protocolo de descubrimiento de vecinos cuenta con un modo NBMA llamado también ''OffLink'', el cual solamente autoriza el diálogo con un enrutador. Los intercambios comienzan de la misma forma:
* El dispositivo que desea insertarse en la red, emite un mensaje RS (''Router Sollicitation'') utilizando la dirección destino FF02::2 (todos los enrutadores sobre el enlace. La red NBMA deberá enviar este mensaje hacia un enrutador.
* El enrutador responde poniendo el bit <tt>L</tt> (OffLink) a 1 en la opción [[#información|Información sobre el prefijo]], indicando que todos los intercambios deben pasar por él.
* El dispositivo construye su dirección global concatenando el prefijo a su identificador de interfaz.
* El dispositivo envía sistemáticamente todos los paquetes a la dirección física del enrutador. Éste, que tiene una visión global de la red, los reenvía hacia el destinatario apropiado.

<tikz title="Off Link NDP: Cuarta etapa (opcional)">
\clip (0, 0) rectangle (11,7);
% \draw[help lines] (0,0) grid (10,7 );

\pgfputat{\pgfxy(4.5,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}
\pgfputat{\pgfxy(1.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[decorate,decoration={zigzag}, color=black!60, ->, very thick] (8,3)-- node [left, near end, color=black] {\tiny{$\alpha$::IID2 -$>$ $\alpha$::IID3 : DATA}} (5,5);

\draw[decorate,decoration={zigzag}, color=black!60, ->, very thick] (5,5)-- node [left, midway, color=black] {\tiny{$\alpha$::IID2 -$>$ $\alpha$::IID3 : DATA}} (2,3);

\draw[decorate,decoration={triangles}, color=black!60, ->, thick, ] (5,5) to [bend left] node [right, near start, color=black] {\tiny{REDIRECT $\alpha$::IID3 : MAC3}} (8,3);

\draw [color=black!60, ->, very thick, dotted] (8,3)-- node [above, midway, color=black] {\tiny{$\alpha$::IID2 -$>$ $\alpha$::IID3 : DATA}} (2,3);

</tikz>

* Si la tecnología del enlace lo permite y si la política de gestión de red lo autoriza, el enrutador tiene la posibilidad de optimizar el tráfico, notificando al dispositivo la verdadera dirección del destinatario, emitiendo un mensaje de [[#IR|indicación de redirección]] (''ICMP Redirect''). Los paquetes subsecuentes ya no pasarán por el enrutador.

===Caso de redes móviles===

La detección de duplicación de direcciones es un proceso relativamente largo, pues un dispositivo que desea garantizar la unicidad de su dirección, debe emitir un mensaje NS y esperar que no haya respuesta. Además, dado que es posible que la red pierda los mensajes NS, el dispositivo podría intentar varias veces de resolver su propia dirección antes de garantizar su unicidad. Por último, el mismo proceso se repite para las direcciones de enlace local y unicast global. En consecuencia, se requiere de varios segundos antes de que un dispositivo pueda emitir paquetes hacia la red. Para equipos móviles, este retardo, que se suma a los de descubierta de vecinos y a la autentificación, puede conducir a interrupciones de conectividad (por ejemplo, para aplicaciones de voz sobre IP).

El RFC 4429 flexibiliza esta situación al permitir que un sitio utilice su dirección aún si no se ha garantizado su unicidad. Este comportamiento es llamado DAD optimista (''optimistic DAD''). El estado tentativo (ver [[#Ciclo de vida de una dirección| Ciclo de vida de una dirección]] se remplaza por un estado ''optimista'' durante el cual la exclusividad de la dirección no está garantizada pero se permite su uso. Paralelamente, se emite un DAD clásico. Los mensajes NS se emiten con el bit <tt>O</tt> (''Override'') apagado para que los caches de ND no se actualicen en caso de que esa dirección ya existiera en la red.

==Descubrimiento de MTU==

<tikz title="Descubrimiento de MTU primera fase: envío de un paquete demasiado grande">
\clip (0, 0) rectangle (11,8);
%\draw[help lines] (0,0) grid (10,7 );

\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,2)--(9,2);

\pgfputat{\pgfxy(0.8,3)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,3)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,2)--(1.5,3);
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (8,2)--(8,3);

\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,4)--(1.5,5);
\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,5)--(9,5);
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (5.5,5)--(5.5,6);
\pgfputat{\pgfxy(5,6)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}
\draw (8, 3.6) node {\small{A}};
\draw (5.5, 6.6) node {\small{B}};
\draw (1.5, 3.6) node {\small{R}};

\draw (1.5,1.5) node {\small{MTU=1500}};
\draw (1.5,5.5) node {\small{MTU=1280}};

\draw (9.5, 3.5) node {\tiny{PMTU(*)=1500}};

\draw [<-] (1.7,3) -- (1.7, 2.2) -- node [above = 10pt] { \tiny{A-$>$ B Size=1500}} (7.8, 2.2) -- (7.8, 3);
}
</tikz>

Por razones de eficacia, generalmente es preferible que la información intercambiada entre dispositivos esté contenida en datagramas de tamaño máximo. Este tamaño depende de la ruta seguida por los datagramas y es igual al tamaño más grande autorizada por el conjunto de enlaces recorridos. Se le llama PMTU, ''Path Maximum Transmission Unit'' (Unidad de transferencia de tamaño máximo sobre la trayectoria).

Inicialmente, el dispositivo supone que el PMTU de una cierta trayectoria es igual al MTU del enlace al que está directamente conectado. Si sucede que los paquetes enviados por ese camino exceden el tamaño máximo autorizado por un enlace intermedio, el enrutador correspondiente eliminará esos paquetes y enviará un mensaje de error ICMPv6 tipo “paquete demasiado grande” donde indicará el MTU aceptable. Con esa información, el dispositivo reducirá el PMTU apropiado para esa ruta.

Es posible que se deban efectuar varias iteraciones antes de obtener el PMTU que permita que los paquetes lleguen a su destino sin exceder el MTU de cada enlace recorrido. El protocolo IPv6 garantiza que el MTU de todos los enlaces no puede ser menor de 1,280 octetos, por lo que éste es el umbral mínimo para el MTU. Dado que este protocolo puede sufrir pérdidas de paquetes, se deja a las capas superiores gestionar la fiabilidad de la comunicación y restransmitir paquetes si es necesario (paquete 6 del ejemplo).

<tikz title=" Descubrimiento de MTU segunda fase: recepción de un mensaje ICMPv6">
\clip (0, 0) rectangle (11,8);
%\draw[help lines] (0,0) grid (10,7 );

\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,2)--(9,2);

\pgfputat{\pgfxy(0.8,3)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,3)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,2)--(1.5,3);
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (8,2)--(8,3);

\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,4)--(1.5,5);
\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,5)--(9,5);
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (5.5,5)--(5.5,6);
\pgfputat{\pgfxy(5,6)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}
\draw (8, 3.6) node {\small{A}};
\draw (5.5, 6.6) node {\small{B}};
\draw (1.5, 3.6) node {\small{R}};

\draw (1.5,1.5) node {\small{MTU=1500}};
\draw (1.5,5.5) node {\small{MTU=1280}};

\draw (9.5, 3.5) node {\tiny{PMTU(*)=1500}};

\draw [->] (1.7,3) -- (1.7, 2.2) -- node [above = 10pt] { \tiny{R-$>$ A ICMP6 Error: Packet too big}} node [above] {\tiny{MTU=1280}} (7.8, 2.2) -- (7.8, 3);
\draw (9.5, 3) node {\alert{\tiny{PMTU(B)=1280}}};

</tikz>

Si bien la determinación del PMTU se hace esencialmente durante los primeros intercambios entre los dispositivos comunicantes, es posible que pueda reactivarse durante una comunicación activa si, debido a un cambio de ruta, se debe recorrer un enlace con mayores restricciones de tamaño.

El emisor verifica también que el PMTU no ha aumentado enviando esporádicamente un paquete más grande. Si éste cruza la red sin problemas, el valor del PMTU se incrementará.

Cabe señalar que el algoritmo de descubrimiento de PMTU funciona igual para las comunicaciones punto a punto, o multipunto. En este último caso, el PMTU será el mínimo permitido para el conjunto de caminos hacia cada sitio destinatario del grupo de difusión.

La información de PMTU se utiliza de distintas formas dependiendo del ambiente en el que los datos a transmitir se segmentan:

* si se utiliza un protocolo tipo TCP, éste realizará la fragmentación de forma transparente a las aplicaciones en función de la información de PMTU que le comunique la capa IPv6.
* si se utiliza un protocolo tipo UDP, la responsabilidad de la fragmentación recaerá en una capa superior, eventualmente en la aplicación. Será necesario que ésta:
** (1) pueda informarse del valor de PMTU autorizado, aún si éste cambia posteriormente, y
** (2) pueda fragmentar los datos en consecuencia. Para que estas dos condiciones se cumplan, IPv6 ha retenido un mecanismo de fragmentación (ver [[IPv6_QO#Fragmentación|fragmentación]]).

<tikz title=" Descubrimiento de MTU tercera fase: Emisión de un paquete de tamaño adecuado">
\clip (0, 0) rectangle (11,8);
%\draw[help lines] (0,0) grid (10,7 );

\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,2)--(9,2);

\pgfputat{\pgfxy(0.8,3)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,3)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,2)--(1.5,3);
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (8,2)--(8,3);

\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,4)--(1.5,5);
\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,5)--(9,5);
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (5.5,5)--(5.5,6);
\pgfputat{\pgfxy(5,6)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}
\draw (8, 3.6) node {\small{A}};
\draw (5.5, 6.6) node {\small{B}};
\draw (1.5, 3.6) node {\small{R}};

\draw (1.5,1.5) node {\small{MTU=1500}};
\draw (1.5,5.5) node {\small{MTU=1280}};

\draw (9.5, 3.5) node {\tiny{PMTU(*)=1500}};
\draw (9.5, 3) node {\alert{\tiny{PMTU(B)=1280}}};
\draw [<-] (1.7,3) -- (1.7, 2.2) -- node [above = 10pt] { \tiny{A-$>$ B Size=1280}} (7.8, 2.2) -- (7.8, 3);
\draw [->] (1.7,4) -- (1.7, 4.8) -- (5.3, 4.8) -- (5.3, 6);
</tikz>

Hay otro aspecto relacionado con la identificación de caminos para poder asociarles la información de PMTU. El implementador cuenta con varias posibilidades. Por ejemplo, puede identificar un camino por la dirección destino o por el identificador de flujo si este campo se utiliz, o por la ruta seguida en el caso en que ésta sea impuesta (ver Las extensiones#enrutamiento|enrutamiento]]).

Por último, se bien se recomienda encarecidamente que cada dispositivo implemente el mecanismo de detección de PMTU, éste no es obligatorio. Por lo tanto, un equipo que no cuente con él (por ejemplo, una ROM de arranque) deberá restringir el tamaño de los paquetes al mínimo permitido, es decir, 1,280 octetos.

{{eSuivi|Tabla de contenido|Incio del capítulo|DHCPv6|DHCPv6}}

Protocolo de Descubrimiento de vecinos

2012-07-05T19:04:13Z

Jincera:

{{eSuivi|Tabla de contenido|Incio del capítulo|DHCPv6|DHCPv6}}

__TOC__

El protocolo de descubrimiento de vecinos (NDP, ''Neighbor Discovery Protocol'') permite a un dispositivo integrarse en el ambiente local, es decir, el enlace sobre el cual se transmiten físicamente los paquetes IPv6. Permite establecer un diálogo con los equipos (estaciones y enrutadores) conectados sobre el mismo medio. No se pretende que un dispositivo conozca con exactitud la lista de todos los demás dispositivos conectados al enlace, sino de proveer un mecanismo para dialogar con quien necesite hacerlo.

El protocolo utiliza cinco tipos de mensajes ICMPv6 (ver Valores de los campos de tipo y código de ICMPv6). El campo número de saltos de la cabecera IPv6 contiene el valor 255. Este valor parece demasiado grande para datagramas que no debieran ser enrutados fuera del enlace físico. En realidad, si un equipo recibe un datagrama con un valor menor, significa que la información proviene de otra red y que ya ha atravesado al menos un enrutador. Por ello, los datagramas que tienen un valor diferente de 255 deben ser ignorados por el receptor.

{{Tableau eICMPv6}}

El protocolo realiza varias funciones:

* Resolución de direcciones. El principio es muy similar al del protocolo ARP de IPv4. La principal diferencia consiste en el uso de mensajes ICMPv6 estándar en lugar de definir otro protocolo de capa 3. Con esto se consigue una mayor flexibilidad de uso, especialmente en las redes que no soportan la difusión de mensajes. Al igual que en IPv4, el protocolo se encarga de construir tablas de correspondencia entre las direcciones IPv6 y las físicas.
* <div vecinos id="NUD"> Detección de inaccesibilidad de vecinos (NUD, ''Neighbor Unreachability Detection''). Esta función, que no existe en IPv4, permite eliminar de las tablas de configuración de un equipo, los vecinos que se han vuelto inaccesibles (por fallas, cambio de domicilio, ...). Si un enrutador deja de estar disponible, la tabla de enrutamiento puede ser modificada para considerar otra ruta. </div>
* Configuración. La configuración automática de los dispositivos es uno de los principales atractivos de IPv6. Se implementan varias funcionalidades del protocolo de descubrimiento de vecinos:
**Descubrimiento de enrutadores. Este protocolo permite que los dispositivos identifiquen a los enrutadores que se encuentran en su enlace físico. En IPv4, esta función la proporciona el protocolo ''ICMP Router Discovery''.
** Descubrimiento de prefijos. El dispositivo conoce el o los prefijos de red de acuerdo a los anuncios realizados por los enrutadores. Agregando su identificador de interfaz, el dispositivo construye su o sus direcciones IPv6. No hay un mecanismo equivalente para las direcciones IPv4 ya que son demasiado cortas para realizar la auto-configuración.
** Detección de direcciones duplicadas. Dado que las direcciones se configuran de forma automática, existen riesgos de error en caso de tener equipos con identificadores repetidos. Este protocolo verifica que ningún otro equipo en el enlace tiene la misma dirección IPv6. Esta función es una evolución del ARP gratuito en IPv4 emitido durante la inicialización de la interfaz.
** Descubrimiento de parámetros. Este protocolo permite que los dispositivos conozcan los distintos parámetros del enlace físico, por ejemplo, el tamaño de MTU, el número máximo de saltos permitido (valor original del campo número de saltos), si la configuración automática con estado (como [[Configuración con estado: DHCPv6|DHCPv6]]) está activa, etc. No existe un equivalente de esta funcionalidad en IPv4.
* Indicación de redirección. Este mensaje se utiliza cuando un enrutador conoce una trayectoria mejor (medida en número de saltos) para alcanzar un destino.
:En IPv4 una indicación de redireccionamiento sólo puede servir para corregir la dirección del enrutador utilizado para acceder a una máquina fuera de la red local. Los dispositivos deben conocer todas las direcciones correspondientes a equipos conectados en su propia red local.
:EnIPv6, la correspondencia entre prefijo y red local es menos rígida. Es de esperar que un dispositivo no conozca todos los prefijos de su red local (si ésta es compartida por varios prefijos), o que un prefijo se comparta entre varios enlaces (lo que corresponde a una generalización del modelo de redes lógicas IP sobre ATM). Bajo algunas configuraciones, la máquina emitirá sus paquetes al enrutador aún si el destinatario se encuentra en el mismo segmento que el emisor. En este caso, el enrutador emitirá un mensaje de redirección para que la continuación del diálogo entre ellos haga de manera directa (véanse los ejemplos [[#IR|Indicación de redirección]]).
:En el caso más extremo, podría imaginarse en IPv6 que un dispositivo puede ser configurado para comunicarse únicamente con su enrutador por omisión. ICMPv6 ''redirect'' puede utilizarse entonces, para informar al dispositivo de destinatarios ubicados en el mismo enlace.

En IPv6 se especifican dos métodos de autoconfiguración para las direcciones unicast global:

* Autoconfiguración sin estado (''stateless autoconfiguration'', RFC 2462). Se utiliza cuando no es necesaria una gestión administrativa de las direcciones asignadas dentro de un sitio. Estos mecanismos se describen más adelante en este capítulo.
* Autoconfiguración con estado (''statefull autoconfiguration''). Se utiliza cuando un sitio requiere de un control estricto de la asignación de direcciones (''cf'' [[Configuración con estado: DHCPv6 | DHCPv6]]).

Sin embargo, el uso de DHCPv6 para obtener la dirección se controla mediante el protocolo de descubrimiento de vecinos.

= Datos transmitidos por los mensajes =

La principal motivación detrás del Protocolo de Descubrimiento de vecinos es unificar varios protocolos existentes en IPv4. En particular, la mayor parte de los datos utiliza un formato de opciones común, lo que simplifica la implementación del protocolo. El formato contiene los campos: tipo, longitud (en palabras de 64 bits), y datos. La baja precisión de campo longitud, presentará un desperdicio de espacio, pero permite una alineación de las opciones en palabras de 64 bits, lo que permite un procesamiento optimizado.

{{NB-Opciones}}

== <div id="física">Dirección física de la fuente/destino</div> ==

<tikz title="Formato de la opción dirección física fuente/destino">
\clip (0.2, 5.7) rectangle (11.1,6.7);
% \draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=1/2}};
\draw (2.9, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{lenght }};
\draw (5.3, 6) node (addr) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Link Layer Address}};

\draw [draw=white, thick] (addr.north east) -- (addr.south east);
\draw [draw=white, thick] (addr.north east) -- +(-2, 0);
\draw [draw=white, thick] (addr.south east) -- +(-2, 0);

\draw [dashed] (addr.north east) -- (addr.south east);
\draw [dashed] (addr.north east) -- +(-2, 0);
\draw [dashed] (addr.south east) -- +(-2, 0);
</tikz>

La figura ''Formato de la opción dirección física fuente/destino'' presenta estas opciones. El tipo 1 designa la dirección física de la fuente y el tipo 2 la dirección del destino.

El campo ''length'' es el tamaño en palabras de 64 bits de la opción. Por lo tanto, para el caso de una dirección MAC con longitud de 6 octetos, contiene el valor 1.

El RFC 2464 define el formato para las direcciones MAC-48 utilizadas en las redes Ethernet y Wi-Fi. El RFC 4944 define el formato para las direcciones MAC-16 y MAC-64 utilizadas en las redes de sensores bajo la norma IEEE 802.15.4.

== <div id="información">Información sobre el prefijo</div> ==

<tikz title="Formato de la opción información sobre el prefijo">
\clip (0.2, 2) rectangle (11.1, 7);
% \draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=3}};
\draw (2.9, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{length =4 }};
\draw (5.3, 6) node (addr) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm] {\tiny{Prefix Length}};
\draw (7.7, 6) node (bitL) [right, shade, top color=blue!15, bottom color=blue!5,, draw, minimum height=0.5cm, minimum width=.3cm]{}; \draw (bitL.text) node {\tiny{L}};
\draw (8, 6) node (bitA) [right, shade, top color=blue!15, bottom color=blue!5,, draw, minimum height=0.5cm, minimum width=.3cm]{};\draw (bitA.text) node {\tiny{A}};
\draw (8.3, 6) node (bitR) [right, shade, top color=blue!15, bottom color=blue!5,, draw, minimum height=0.5cm, minimum width=.3cm]{};\draw (bitR.text) node {\tiny{R}};
\draw (8.6, 6) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=1.5cm] {\tiny{Reserved}};

\draw (0.5, 5.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Valid Lifetime}};

\draw (0.5, 5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Prefered Lifetime}};

\draw (0.5, 4.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Reserved}};

\draw (0.5, 4) node (addr1) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{}};
\draw (0.5, 3.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{}};
\draw (0.5, 3) node (addr3) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Prefix}};
\draw (0.5, 2.5) node (addr4) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{}};

\draw [color=blue!10, very thick] (addr1.south east) -- (addr1.south west);
\draw [color=blue!10, very thick] (addr2.south east) -- (addr2.south west);
\draw [color=blue!10, very thick] (addr3.south east) -- (addr3.south west);
</tikz>

Esta opción contiene las informaciones sobre el prefijo para permitir una configuración automática de los dispositivos. El campo tipo tiene el valor 3 y el de longitud, 4. La figura ''Formato de la opción información sobre el prefijo'' muestra el formato de esta opción:

* El campo ''Prefix lenght'' indica cuántos bits son significativos para el prefijo anunciado en un campo siguiente.
* El bit <tt>L</tt> indica, cuando vale 1, que el prefijo permite indicar que todos los demás dispositivos que comparten el mismo prefijo, están en el mismo enlace, por lo que el emisor puede contactarlos directamente. En caso contrario, el dispositivo envía el paquete hacia el enrutador. Si éste último sabe que el emisor puede contactar directamente al destinatario, emitirá un mensaje ICMPv6 de indicación de redirección.
* El bit <tt>A</tt> indica, cuando vale 1, que el prefijo anunciado puede utilizarse para formar la dirección del dispositivo.
* El bit <tt>R</tt>, indica, cuando vale 1, que el campo prefijo contiene la dirección global de un enrutador ''agente base''. Los bits de mayor peso aún pueden utilizarse para formar un prefijo.
* El campo duración de validez indica, en segundos, la duración durante la cual el prefijo es válido.
* El campo duración preferente indica la duración, en segundos, durante la cual una dirección formada con el protocolo de configuración sin estado se mantiene ''preferente'' (''cf'' [[Planes de direccionamiento|Tiempo de vida de las direcciones]]).

Para estos dos campos, un valor de <tt>0xffffffff</tt> representa una duración infinita. Estos campos pueden servir durante la fase de transición de un proveedor de acceso a otro; es decir, de un prefijo a otro.
* El campo reservado permite alinear el prefijo a una frontera de palabra de 64 bits.
* El campo prefijo contiene el valor de prefijo anunciado sobre el enlace. Para mantener una alineación de 64 bits para el resto de datos del paquete, este campo tiene una longitud fija de 128 bits.

== <div id="redirigida">Cabecera de redirección </div> ==

<tikz title="Formato de la opción cabecera de redirección">
\clip (0.2, 3.1) rectangle (11.1, 7);
% \draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=5}};
\draw (2.9, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{length =1 }};
\draw (5.3, 6) node (addr) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Reserved}};

\draw (0.5, 5.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Reserved}};

\draw (0.5, 4.25) node (context) [right, shade, top color=purple!50, bottom color=purple!10, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{IPv6 Header and Data}};
</tikz>

Esta opción es utilizada por el mensaje de indicación de redirección. Permite encapsular los primeros octetos del paquete IPv6 que provocó la emisión de este mensaje, como ocurre con los mensajes de error de ICMPv6.

El campo tipo tiene el valor 4. El tamaño de esta opción debe evitar que el paquete IPv6 rebase los 1280 octetos (''cf'' figura ''Formato de la opción cabecera de redirección''). Sin embargo, el paquete debe contener la mayor cantidad de información posible.

== <div id="MTU">MTU</div> ==

<tikz title="Formato de la opción MTU">

\clip (0.2, 5.1) rectangle (11.1, 7);
% \draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=5}};
\draw (2.9, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{lenght =1 }};
\draw (5.3, 6) node (addr) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Reserved}};

\draw (0.5, 5.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{MTU}};
</tikz>

Esta opción permite notificar a los dispositivos el tamaño máximo de datos que pueden ser transmitidos sobre el enlace. La figura ''Formato de la opción MTU'' muestra su estructura. No es necesario difundir esta información si el dispositivo utiliza siempre el tamaño máximo permitido. Por ejemplo, sobre las redes Ethernet, los dispositivos utilizarán el valor 1,500. En cambio, en las redes Token Ring o FDDI, con frecuencia es necesario especificar si los equipos pueden utilizar la longitud máxima o un tamaño inferior para permitir el uso de puentes en la red.

En esta opción, el campo tipo tiene un valor de 5 y el de longitud, de 1.

=Mensajes estándar de Descubrimiento de vecinos =

Además de las cinco opciones básicas descritas en la tabla ''Utilización de las opciones en los mensajes de descubrimiento de vecinos'', existen otras específicas para la movilidad y para las redes NBMA (''Non Broadcast Multiple Access'').

{|
|+ Utilización de las opciones en los mensajes de descubrimiento de vecinos
| width = 150 | || width = 100 |[[#RS|Solicitud de]] || width = 100 |[[#RA|Anuncio de]] || width = 100 |[[#NS|Solicitud de]] ||width = 100 | [[#NA|Anuncio de]] ||width = 100 |[[#IR|Indicación de]]
|-
| || [[#RS|enrutador]] || [[#RA|enrutador]] || [[#NS|un vecino]] || [[#NA| un vecino]] || [[#IR|redirección]]
|-style="background:silver"
|[[#física |Dirección física de la fuente]] || presente || presente || presente || ||
|-
|[[# física | Dirección física del destino]] || || || || presente || presente
|-style="background:silver"
|[[#información|Información sobre el prefijo]] || || ≥ 1 || || ||
|-
|[[#redirigida |Cabecera de redirección]] || || || || || presente
|-style="background:silver"
| [[#MTU |MTU]] || || posible || || ||
|}

Las distintas funcionalidades de descubrimiento de vecinos utilizan cinco mensajes: dos para el diálogo entre un dispositivo y un enrutador, dos para el diálogo entre vecinos, y uno para la redirección. Cada uno de estos mensajes puede incluir opciones adicionales.

== <div id="RS">Solicitud de enrutador</div> ==

<tikz title="Formato de los paquetes de solicitud de enrutador">
\clip (0.2, 3.5) rectangle (11.1,7.1);
%\draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=133}};
\draw (2.9, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code =0 }};
\draw (5.3, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};
\draw (0.5, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Reserved}};

\draw (0.5, 4.25) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Options:\\
- Source link-layer address
}};
</tikz>

El mensaje de solicitud de enrutador (''cf'' figura Formato de los paquetes de solicitud de enrutador) es emitido al iniciar un dispositivo para recibir más rápidamente la información del enrutador. Este mensaje se envía a la dirección IPv6 multicast reservada a los enrutadores en el mismo enlace <tt>FF02::2</tt>. Si el dispositivo aún no conoce su dirección fuente, se utiliza la dirección no especificada.

El campo opción normalmente contiene la dirección física del dispositivo.

== <div id="RA">Anuncio de enrutador</div> ==

<tikz title="Formato de los paquetes de anuncio de enrutador">
\clip (0.2, 1.5) rectangle (11.1,7.1);
%\draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=134}};
\draw (2.9, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code =0 }};
\draw (5.3, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};

\draw (0.5, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Cur. Hop Lim.}};
\draw (2.9, 5.5) node (bitM) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{}; \draw (bitM.text) node {\tiny{M}};
\draw (3.2, 5.5) node (bitO) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{};\draw (bitO.text) node {\tiny{O}};
\draw (3.5, 5.5) node (bitH) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{};\draw (bitH.text) node {\tiny{H}};
\draw (3.8, 5.5) node (res) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=1.5cm]{\tiny{reserved}};
\draw (5.3, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Router Lifetime}};

\draw (0.5, 5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=9.6cm]{\tiny{Reachable Time}};
\draw (0.5, 4.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=9.6cm]{\tiny{Retrans Time}};

\draw (0.5, 3.25) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Options:\\
Source link-layer address\\
MTU\\
Prefix Information (may be repeated)\\
}};
</tikz>

Este mensaje (''cf'' figura ''Formato de los paquetes de anuncio de enrutador'') es emitido periódicamente por los enrutadores, o bien, en respuesta a un mensaje de solicitud de enrutador generado por un dispositivo. El campo dirección fuente contiene la dirección de enlace local del enrutador, mientras que el campo dirección destino contiene la dirección del dispositivo que generó la solicitud, o la dirección de todas las estaciones (<tt>ff02::01</tt>).

Cuando el campo de máximo número de saltos tiene un valor distinto de cero, muestra el valor que podría colocarse en el campo de número de saltos de los paquetes emitidos. El bit <tt>M</tt> indica que una dirección del dispositivo debe ser obtenida mediante un protocolo de configuración (''cf'' [[Configuración con estado:DHCPv6]]). El bit <tt>O</tt> también indica la presencia de un servicio de configuración para obtener información adicional a la dirección. Si no es posible obtener la dirección mediante un servidor, el dispositivo procede a realizar una configuración sin estado, concatenando su identificador de interfaz a los prefijos que conoce. El bit <tt>H</tt> indica que el enrutador puede ser utilizado como agente base por un nodo móvil (''cf'' [[Desplazamientos_de_móviles#Anuncio_del_agente_base |Anuncio del agente base]]).

El campo tiempo de vida del enrutador indica el período (en segundos) durante el cual el equipo que emite el anuncio realizará funciones de enrutador por omisión. El valor máximo corresponde a 18 horas 12 minutos, pero como este mensaje se emite periódicamente, en la práctica no existe un límite para el tiempo de vida de un enrutador. Un valor de <tt>0</tt> indica que el dispositivo no cumple con las funciones de enrutador por omisión. Este tiempo de vida no se aplica a las opciones transportadas por este mensaje.

El campo duración de accesibilidad indica el período (en milisegundos) durante el cual una información almacenada en la memoria caché de la máquina (por ejemplo, la tabla de correspondencia entre las direcciones IPv6 y las físicas) puede ser considerada como válida. Al vencimiento de este tiempo, se emite un mensaje de detección de inaccesibilidad para verificar la pertinencia de la información almacenada.

El campo temporización de retransmisión muestra el período (en milisegundos) entre dos emisiones no solicitadas de este mensaje. Permite que los demás equipos puedan detectar la inaccesibilidad de un enrutador.

Este mensaje puede transportar las siguientes opciones:

* dirección física de la fuente,
* MTU,
* información sobre el prefijo (uno o varios).

== <div Id="NS"> Solicitud de un vecino </div> ==

<tikz title="Formato de los paquetes de solicitud de un vecino">

\clip (0.2, 1.5) rectangle (11.1,7.1);
%\draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=135}};
\draw (2.9, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code =0 }};
\draw (5.3, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};

\draw (0.5, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=9.6cm]{\tiny{Reserved}};

\draw (0.5, 4.25) node (context) [right, shade, top color=blue!50, bottom color=blue=!10, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Target Address}};

\draw (0.5, 2.25) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Options:\\
Source link-layer address\\
}};
</tikz>

Este mensaje (''cf'' figura ''Formato de los paquetes de solicitud de un vecino'') permite obtener información a partir de un equipo vecino, es decir, localizado en el mismo enlace físico (o conectado a través de puentes). El mensaje puede ser emitido explícitamente a él, o enviado con una dirección de difusión. En el caso de determinación de la dirección física, éste corresponde a la solicitud de ARP en IPv4.

El campo dirección fuente del paquete IPv6 contiene ya sea la dirección local al enlace, una dirección global o la dirección no especificada. El campo destino puede contener la dirección de difusión múltiple solicitada correspondiente a la dirección buscada (''cf'' [[Direccionamiento_multicast#Identificador_de_grupo|Identificador de grupo]]) o la dirección del dispositivo (en el caso de una detección de inaccesibilidad de vecinos, ''NUD'').

El campo dirección del destino contiene la dirección IPv6 del equipo buscado. El campo opción generalmente contiene la dirección física de la fuente.

== <div Id="NA"> Anuncio de un vecino</div> ==

<tikz title="Formato de los paquetes de anuncio de un vecino">

\clip (0.2, 1.5) rectangle (11.1,7.1);
%\draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=136}};
\draw (2.9, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code =0 }};
\draw (5.3, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};

\draw (0.5, 5.5) node (bitR) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{}; \draw (bitR.text) node {\tiny{R}};
\draw (0.8, 5.5) node (bitS) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{}; \draw (bitS.text) node {\tiny{S}};
\draw (1.1, 5.5) node (bitO) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{}; \draw (bitO.text) node {\tiny{O}};
\draw (1.4, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=8.7cm]{\tiny{Reserved}};

\draw (0.5, 4.25) node (context) [right, shade, top color=blue!50, bottom color=blue=!10, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Target Address}};

\draw (0.5, 2.25) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Options:\\
Source link-layer address\\
}};
</tikz>

Este mensaje (''cf'' figura ''Formato de los paquetes de anuncio de un vecino'') se emite en respuesta a una solicitud, aunque también puede ser emitido de forma espontánea para propagar la información de cambio de dirección física, o del estado de "enrutador". Para el caso de la determinación de la dirección física, es equivalente a la respuesta ARP en IPv4.

* El bit <tt> R </tt> se pone a 1 si el remitente es un enrutador. Este bit se utiliza para permitir la detección de un enrutador que se convierte en un equipo ordinario.
* El bit <tt> S </tt> en 1 indica que este anuncio se emite en respuesta a una solicitud.
* El bit <tt> O </tt> en 1 indica que este anuncio debe borrar las informaciones anteriores que se encuentran almacenadas en la memoria cachés de otros equipos, en especial la tabla que contiene las direcciones físicas.
* El campo dirección del destino contiene, si el bit<tt> S </tt> es 1, el valor del campo dirección del destino de la solicitud a la que está respondiendo este mensaje. Si el bit <tt> S </tt> es 0, este campo contiene la dirección IPv6 local al enlace del equipo emisor.
* La opción dirección física del destino contiene la dirección física del emisor.

== <div id="IR">Indicación de redirección</div> ==

<tikz title="Formato de los paquetes de indicación de redirección">
\clip (0.2, 0) rectangle (11.1,7.1);
%\draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=137}};
\draw (2.9, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code =0 }};
\draw (5.3, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};

\draw (0.5, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=9.6cm]{\tiny{Reserved}};

\draw (0.5, 4.25) node (context) [right, shade, top color=blue!50, bottom color=blue=!10, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Target Address}};

\draw (0.5, 2.25) node (context) [right, shade, top color=blue!50, bottom color=blue=!10, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Destination Address}};

\draw (0.5, 0.5) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=1.5cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Options:\\
Target link-layer address\\
Redirected Header\\
}};
</tikz>

La técnica de redirección es la misma que en IPv4. Un dispositivo sólo conoce los prefijos de las redes a las que está conectado directamente y la dirección de un enrutador por omisión. Si la ruta se puede optimizar, el enrutador por omisión envía un mensaje para indicar que existe un camino más corto. De hecho, como en IPv6 el enrutador por omisión se establece de forma automática, las rutas no necesariamente son las mejores (''cf'' figura ''Enrutamiento por omisión no óptimo'').

Otro caso particular en IPv6 ocurre con los dispositivos que se encuentran en el mismo enlace físico, pero tienen diferentes prefijos. La comunicación entre ellos pasa inicialmente a traves de enrutador por omisión hasta que éste notifica que existe una ruta directa entre ellos.

La figura ''Formato de los paquetes de indicación de redirección'' muestra el formato del mensaje:

* El campo dirección objetivo (''Target address'') contiene la dirección IPv6 del equipo hacia el que los paquetes deben ser enviados.
* El campo dirección destino contiene la dirección IPv6 del dispositivo que está siendo redirigido hacia la dirección objetivo.

Cuando la redirección apunta a un dispositivo situado en el mismo enlace, la dirección objetivo y de destino son las mismas.

Las opciones incluyen la dirección física de un nuevo enrutador y la cabecera del paquete redirigido.

Este mensaje se puede utilizar de la misma forma que en IPv4. Un dispositivo solamente tiene una ruta por omisión para acceder a equipos con un prefijo diferente. En consecuencia, envía su paquete al enrutador por omisión, quien observa que el prefijo destino es accesible a través de la misma subred que el emisor. El enrutador por omisión reenvía el paquete y notifica al emisor que puede contactar directamente a las máquinas que poseen el prefijo del destino.

IPv6 también utiliza este mensaje para optimizar la resolución fuera del enlace para el [[#Caso de redes NBMA |caso de redes NBMA]].

= Configuración automática =
Tradicionalmente, la configuración de una interfaz de red de una máquina se hacía manualmente. Esto suele ser un trabajo lento y propenso a errores. Con IPv6, se automatiza el proceso de configuración y se introducen, al mismo tiempo, mecanismos de funcionamiento inmediato (''plug and play'') a la interfaz de red. La configuración automática significa que un dispositivo obtendrá toda la información necesaria para su conexión a una red local IP sin ninguna intervención humana. En el caso ideal, cualquier usuario desempaca su nuevo equipo, lo conecta a la red local y lo ve funcionar sin tener que introducir la información propia de "especialistas". Ahora vamos a discutir otro aspecto de la configuración automática de IPv6, la auto-configuración de direcciones, que tiene como objetivos:

* La adquisición de una dirección cuando un dispositivo está conectado a una red por primera vez;
* la posibilidad de asignar otros prefijos, o de renumerar un dispositivo.

El proceso de configuración automática de direcciones IPv6 incluye la creación de una dirección local al enlace, la agregación a grupos multicast solicitados, la verificación de la unicidad de la dirección local al enlace y la creación de direcciones unicast global.

La tarea del enrutador es importante en la configuración automática. Indica a la máquina, mediante los bits de la cabecera (''cf'' [[#RA|anuncio de enrutador]]), del mensaje de anuncio de los enrutadores, el método a conservar y eventualmente proporcionar la información necesaria para su configuración. El bit <tt> M </tt> (''configuración de dirección administrada'') puesto a 1 indica que el equipo no debe crear por sí mismo una dirección a partir de su identificador de interfaz y de los prefijos recibidos, sino que debe solicitarla explícitamente ante un servidor de direcciones. El bit O <tt> </tt> (''otra configuración de estado'') indica que el dispositivo debe consultar el servidor para obtener otros parámetros distintos de la dirección. El algoritmo para el proceso de configuración automática de direcciones se desglosa de la siguiente manera:

* La primera fase consiste en crear la dirección local al enlace.
* Una vez que la unicidad de esta dirección es verificada, el dispositivo está listo para comunicarse con otras máquinas en el enlace.
* El dispositivo debe tratar de adquirir un mensaje de anuncio de enrutadores para determinar el método de obtención de la dirección unicast global.
* Si hay un enrutador en el enlace, el dispositivo debe aplicar el método especificado por el mensaje de anuncio de enrutadores, a saber:
** La configuración automática sin estado,
** la configuración automática con estado.
* Si no hay ningún enrutador en el enlace, el dispositivo debe tratar de obtener la dirección unicast global por el método de configuración automática con estado. Si el intento falla, no hay más que hacer. Las comunicaciones sólo podrán hacerse sobre el enlace con la dirección local al enlace, pues el dispositivo no tendrá una dirección con la cobertura necesaria que le permita comunicarse con otras máquinas fuera del enlace.

==Ciclo de vida de una dirección==

Al generalizar en IPv6 el plan de direccionamiento CIDR, los prefijos quedan, en todos los casos, siendo propiedad de los operadores. Ya no pueden otorgarse "a perpetuidad" a los dispositivos. Para facilitar la renumeración de una máquina, la asignación de una dirección a una interfaz es temporal, las direcciones IPv6 no se entregan, sino que se prestan. Se asocia un tiempo de vida a la dirección, que indica el tiempo durante el cual la dirección pertenece a la interfaz. Cuando el tiempo de vida se ha agotada, la dirección deja de ser válida, se suprime de la interfaz y queda potencialmente éste puede prolongarse indefinidamente. La dirección local al enlace tiene un tiempo de vida ilimitado.

<tikz title="Estados sucesivos de una dirección en una interfaz">

\draw [thick, ->] (0,2) -- (9.5,2);

\draw [->] (1,4) node [above=10pt] {\tiny{allocation}}-- (1,2);
\draw (1, 2) node [rectangle, minimum width=1cm, minimum height=1cm, fill, left color=black!10, right color=black!20, draw=black, above right] (tentative) {};
\draw (tentative.south east) node [rectangle, minimum width=3cm, minimum height=1cm, fill, left color=green, right color=green!50, draw=black, above right] (preferred) {};
\draw (preferred.south east) node [rectangle, minimum width=2cm, minimum height=1cm, fill, left color=orange , right color=orange!50!red, draw=black, above right] (deprecated) {};
\draw (deprecated.south east) node [rectangle, minimum width=2cm, minimum height=1cm, fill, color=red, draw=black, above right] (novalid) {};

\draw (tentative.text) node {\tiny{Tentative}};
\draw (preferred.text) node {\tiny{Preferred}};
\draw (deprecated.text) node {\tiny{Deprecated}};
\draw (novalid.text) node {\tiny{Invalid}};

\draw [dotted] (tentative.south west) -- +(0, -1);
\draw [dotted] (preferred.south west) -- +(0, -1);
\draw [dotted] (deprecated.south west) -- +(0, -1);
\draw [dotted] (novalid.south west) -- +(0, -1);

\draw [dashed, <->] ([yshift=-0.5cm]tentative.south west) -- node [above] {\tiny{DAD}} ([yshift=-0.5cm] preferred.south west) ;

\draw [dashed, <->] ([yshift=-0.5cm]preferred.south west) -- node [above] {\tiny{Valid}} ([yshift=-0.5cm] novalid.south west) ;

</tikz>

La renumeración de una interfaz consiste en pasar de una dirección a otra. Durante una renumeración, no es aconsejable cambiar repentinamente de dirección, de lo contrario, todas las comunicaciones TCP que la utilizan como identificador de conexión, se cortarían inmediatamente. Esto conllevaría importantes perturbaciones a nivel de las aplicaciones.

Por ello, para facilitar esta transición se implementó un mecanismo de obsolescencia que invalida gradualmente una dirección. Este mecanismo se sirve de la capacidad de asignación de varias direcciones válidas a una misma interfaz. Para elegir la dirección a utilizar, se le asocia un estado que indica en qué fase de su tiempo de vida se encuentra con respecto a la interfaz. El primero de esos estados se conoce como preferido: no hay ninguna restricción de uso. Poco antes de su invalidación, la dirección pasa a un estado de depreciado. En él se desaconseja el uso de la dirección, pero no está prohibido. Una dirección depreciada ya no debe ser utilizada como dirección fuente de nuevas comunicaciones (como el establecimiento de conexión TCP), pero todavía puede emplearse como dirección fuente de comunicaciones ya establecidas. Los paquetes recibidos a una dirección depreciada seguirán siendo entregados normalmente. El control de la duración de cada estad de una dirección válida se efectúa agregando un tiempo de vida al estado preferido.
La figura '''Estados sucesivos de una dirección en una interfaz''' representa los diferentes estados que toma una dirección cuando se asigna a una interfaz.

== Creación de la dirección local al enlace ==

<tikz title=" Creación de la dirección local al enlace">
\clip (0, 0) rectangle (10,7);
% \draw[help lines] (0,0) grid (10,7 );

\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,3)--(9,3);

\pgfputat{\pgfxy(0.8,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,5)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,3)--(1.5,5);
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (8,3)--(8,5);

\draw (1.5,4.5) node {\small{FE80::IID1}};
\draw (1.5,4) node {\small{$\alpha$::IID1/64}};

\draw (8, 4.5) node {\small{FE80::IID2}};

</tikz>

Durante la inicialización de la interfaz, el dispositivo construye un identificador de interfaz que debe ser único en el enlace. Este identificador se utiliza la dirección de [[ Identificador_de_interfaz#EUI-64 | EUI-64]]. El principio básico para crear la direcciónIPv6 consiste en unir un prefijo con el identificador. La dirección local al enlace se crea tomando el prefijo de Enlace_local (<tt>FE80::/64</tt>). La dirección creada de esa manera, todavía no puede ser utilizada; tiene un estado temporal pues el dispositivo debe comprobar la exclusividad de esta dirección en el enlace mediante el procedimiento de detección de direcciones duplicadas. Si se encuentra que la dirección local al enlace no es única, se suspende la autoconfiguración y será necesario proceder a una configuración manual.

Una vez que se ha asegurado la unicidad de la dirección local al enlace, ésta se considera una dirección válida para la interfaz, con lo que termina la prima fase del proceso de autoconfiguración.

==<div id="DAD"> Detección de una dirección duplicada </div>==

<tikz title="Emisión de un NS en una detección de Dir. duplicada (DAD)">
\clip (0, 0) rectangle (10,7);
% \draw[help lines] (0,0) grid (10,7 );

\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,3)--(9,3);

\pgfputat{\pgfxy(0.8,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,5)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,3)--(1.5,5);
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (8,3)--(8,5);

\draw (7.8, 5) -- (7.8, 3.2);
\draw [<->] (1, 3.2) -- node [above] {\tiny{::/0 -$>$ solicited (FE80:IID2) : NS (who has FE80::IID2?)}}(9, 3.2) ;

</tikz>

Para comprobar la exclusividad de direcciones locales al enlace o de direcciones unicast, los dispositivos deben ejecutar un algoritmo de detección de direcciones duplicadas (DAD) antes poder utilizarlas. El algoritmo usa los mensajes ICMPv6 [[Protocolo_de_Descubrimiento_de_vecinos#NS|solicitud de un vecino]] y [[#NA|anuncio de un vecino.]] Si se detecta una dirección que ya está en uso, ésta no podrá ser asignada a la interfaz, la autoconfiguración automática debe suspenderse y será necesario proceder a una configuración manual. Durante la ejecución del algoritmo DAD, la dirección es considerada como "provisional" hasta tener la confirmación de su unicidad. Una dirección provisional se asigna a una interfaz únicamente para recibir los mensajes de solicitud y anuncio de un vecino. Otros mensajes recibidos, son ignorados. El algoritmo DAD consiste en enviar un mensaje de solicitud de un vecino colocando en el campo de dirección objetivo la dirección provisional. Para distinguir el algoritmo DAD del de Descubrimiento de vecinos, el paquete IPv6 que contiene un mensaje de solicitud de un vecino tiene como dirección fuente una dirección no determinada. Así se presentan tres casos:

* Se recibe un mensaje de anucio de un vecino: Significa que la dirección provisional está siendo utilizada como válida por otro dispositivo, por lo que ésta no es única y no puede ser retenida por el dispositivo.
* Se recibe un mensaje de solicitud de un vecino como parte del algoritmo DAD. La dirección provisional también es provisional para otra máquina. En este caso, la dirección provisional no puede ser utilizada por ninguna de ellas.
* No se recibe ningún mensaje durante un segundo (valor por omisión). La dirección provisional es única, por lo que su estado pasa de provisional a válida y se le asigna a la interfaz.

Obsérvese que este algoritmo no proporciona una fiabilidad absoluta, especialmente cuando el enlace está segmentado.

== Autoconfiguración sin estado ==

<tikz title="Emisión de un RS">
\clip (0, 0) rectangle (10,7);
% \draw[help lines] (0,0) grid (10,7 );

\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,3)--(9,3);

\pgfputat{\pgfxy(0.8,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,5)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,3)--(1.5,5);
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (8,3)--(8,5);

\draw (7.8, 5) -- (7.8, 3.2);
\draw [<->] (1, 3.2) -- node [above] {\tiny{FE80::IID2 -$>$ FF02::2 : RS }} (9, 3.2) ;

</tikz>

La configuración automática sin estado (RFC 2462) no requiere de ninguna configuración manual de los dispositivos, una configuración mínima para los enrutadores, y tampoco necesita de servidores adicionales. Se sirve del protocolo ICMPv6 y puede operar aún sin la presencia de enrutadores. En cambio, sí requiere de una subred con soporte a la difusión de paquetes. Este método sólo aplica para los dispositivos; no puede ser utilizada para configurar enrutadores. El principio básico de este mecanismo consiste en que una máquina genera su dirección IPv6 a partir de información local y de la proporcionada por un enrutador. El enrutador proporciona información sobre la subred asociada al enlace; anuncia el prefijo.

<tikz title="Recepción de un RA">
\clip (0, 0) rectangle (10,7);
% \draw[help lines] (0,0) grid (10,7 );

\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,3)--(9,3);

\pgfputat{\pgfxy(0.8,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,5)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,3)--(1.5,5);
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (8,3)--(8,5);

\draw [->] (1.7,5) -- (1.7, 3.2) -- node [above = 10pt] {\tiny{FE80::IID1 -$>$ FE80::IID2}} node [above] {\tiny{RA ($\alpha$::/64, DHCPv6, MTU=1500, HL=64, {bit {\tt M=1}) }}} (7.8, 3.2) -- (7.8, 5);

</tikz>

Al igual que para la creación de la dirección de enlace local, la dirección unicast global se obtiene al concatenar el prefijo con el identificador de la interfaz. El prefijo se obtiene del mensaje de anuncio de enrutador, más concretamente, de la opción de ''información sobre el prefijo''. Si bien debe verificarse la unicidad de todas las direcciones unicast, en el caso de una dirección unicast obtenida mediante la configuración automática sin estado, esto no es obligatorio, pues la unicidad del identificador de la interfaz ya fue comprobada durante la configuración de la dirección local al enlace. Dado que el identificador es el mismo, no puede haber ambigüedad sobre la exclusividad de la dirección unicast global creada de esta forma.

La renumeración de los dispositivos en un enlace se realiza mediante enrutadores que transfieren las direcciones utilizadas a un estado depreciado y al mismo tiempo anuncian el nuevo prefijo con el que los dispositivos pueden re-crear una dirección preferida.

===Caso de redes NBMA ===

<tikz title="Off Link NDP: Primera etapa">
\clip (0, 0) rectangle (11,7);
% \draw[help lines] (0,0) grid (10,7 );

\pgfputat{\pgfxy(4.5,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}
\pgfputat{\pgfxy(1.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[decorate,decoration={zigzag}, color=black!60, ->, very thick] (8,3)-- node [above, color=black] {\tiny{FE80::IID2 -$>$ FF02::2 : RS}} (5,5);

</tikz>

Las redes NBMA (''Non Broadcast Multiple Access'') se caracterizan por no contar con un mecanismo de difusión hacia todos los dispositivos. Esto conduce a dos situiaciones posibles:
* ausencia total de difusión, como en las redes públicas (telefónica, ATM, …) en las que un solo destinatario puede ser contactado a la vez
* posibilidad de difusión por un número limitado de equipos, como es el caso de las redes de radio tipo 3G, WiMAX, en las que la estación base tiene la posibilidad de difundir datos hacia todos los equipos, pero esto no es posible en el sentido inverso (desde un dispositivo).

<tikz title="Off Link NDP: Segunda etapa">
\clip (0, 0) rectangle (11,7);
% \draw[help lines] (0,0) grid (10,7 );

\pgfputat{\pgfxy(4.5,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}
\pgfputat{\pgfxy(1.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[decorate,decoration={zigzag}, color=black!60, ->, very thick] (5, 5)-- node [above, color=black] {\tiny{RA ($\alpha$::/64, DHCPv6, OffLink, MTU=1500, HL=64, {bit {\tt M=1}})}} (8,3);

</tikz>

Un comportamiento de redes NBMA también puede ser deseable para limitar las restricciones de consumo energético. Por ejemplo, en el caso de redes de sensores, la difusión, o la difusión restringida (multicast) son costosas en consumo de energía pues todos los dispositivos deben procesar el mensaje y algunos deberán retransmitirlo.

<tikz title="Off Link NDP: Tercera etapa">
\clip (0, 0) rectangle (11,7);
% \draw[help lines] (0,0) grid (10,7 );

\pgfputat{\pgfxy(4.5,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}
\pgfputat{\pgfxy(1.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[decorate,decoration={zigzag}, color=black!60, ->, very thick] (8,3)-- node [left, near start, color=black] {\tiny{$\alpha$::IID2 -$>$ $\alpha$::IID3 : DATA}} (5,5);

\draw[decorate,decoration={zigzag}, color=black!60, ->, very thick] (5,5)-- node [left, midway, color=black] {\tiny{$\alpha$::IID2 -$>$ $\alpha$::IID3 : DATA}} (2,3);

</tikz>

Para estos casos, el protocolo de descubrimiento de vecinos cuenta con un modo NBMA llamado también ''OffLink'', el cual solamente autoriza el diálogo con un enrutador. Los intercambios comienzan de la misma forma:
* El dispositivo que desea insertarse en la red, emite un mensaje RS (''Router Sollicitation'') utilizando la dirección destino FF02::2 (todos los enrutadores sobre el enlace. La red NBMA deberá enviar este mensaje hacia un enrutador.
* El enrutador responde poniendo el bit <tt>L</tt> (OffLink) a 1 en la opción [[#información|Información sobre el prefijo]], indicando que todos los intercambios deben pasar por él.
* El dispositivo construye su dirección global concatenando el prefijo a su identificador de interfaz.
* El dispositivo envía sistemáticamente todos los paquetes a la dirección física del enrutador. Éste, que tiene una visión global de la red, los reenvía hacia el destinatario apropiado.

<tikz title="Off Link NDP: Cuarta etapa (opcional)">
\clip (0, 0) rectangle (11,7);
% \draw[help lines] (0,0) grid (10,7 );

\pgfputat{\pgfxy(4.5,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}
\pgfputat{\pgfxy(1.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[decorate,decoration={zigzag}, color=black!60, ->, very thick] (8,3)-- node [left, near end, color=black] {\tiny{$\alpha$::IID2 -$>$ $\alpha$::IID3 : DATA}} (5,5);

\draw[decorate,decoration={zigzag}, color=black!60, ->, very thick] (5,5)-- node [left, midway, color=black] {\tiny{$\alpha$::IID2 -$>$ $\alpha$::IID3 : DATA}} (2,3);

\draw[decorate,decoration={triangles}, color=black!60, ->, thick, ] (5,5) to [bend left] node [right, near start, color=black] {\tiny{REDIRECT $\alpha$::IID3 : MAC3}} (8,3);

\draw [color=black!60, ->, very thick, dotted] (8,3)-- node [above, midway, color=black] {\tiny{$\alpha$::IID2 -$>$ $\alpha$::IID3 : DATA}} (2,3);

</tikz>

* Si la tecnología del enlace lo permite y si la política de gestión de red lo autoriza, el enrutador tiene la posibilidad de optimizar el tráfico, notificando al dispositivo la verdadera dirección del destinatario, emitiendo un mensaje de [[#IR|indicación de redirección]] (''ICMP Redirect''). Los paquetes subsecuentes ya no pasarán por el enrutador.

{{eSuivi|Tabla de contenido|Incio del capítulo|DHCPv6|DHCPv6}}

Protocolo de Descubrimiento de vecinos

2012-07-05T18:57:03Z

Jincera: /* Caso de redes NBMA */

{{eSuivi|Tabla de contenido|Incio del capítulo|DHCPv6|DHCPv6}}

__TOC__

El protocolo de descubrimiento de vecinos (NDP, ''Neighbor Discovery Protocol'') permite a un dispositivo integrarse en el ambiente local, es decir, el enlace sobre el cual se transmiten físicamente los paquetes IPv6. Permite establecer un diálogo con los equipos (estaciones y enrutadores) conectados sobre el mismo medio. No se pretende que un dispositivo conozca con exactitud la lista de todos los demás dispositivos conectados al enlace, sino de proveer un mecanismo para dialogar con quien necesite hacerlo.

El protocolo utiliza cinco tipos de mensajes ICMPv6 (ver Valores de los campos de tipo y código de ICMPv6). El campo número de saltos de la cabecera IPv6 contiene el valor 255. Este valor parece demasiado grande para datagramas que no debieran ser enrutados fuera del enlace físico. En realidad, si un equipo recibe un datagrama con un valor menor, significa que la información proviene de otra red y que ya ha atravesado al menos un enrutador. Por ello, los datagramas que tienen un valor diferente de 255 deben ser ignorados por el receptor.

{{Tableau eICMPv6}}

El protocolo realiza varias funciones:

* Resolución de direcciones. El principio es muy similar al del protocolo ARP de IPv4. La principal diferencia consiste en el uso de mensajes ICMPv6 estándar en lugar de definir otro protocolo de capa 3. Con esto se consigue una mayor flexibilidad de uso, especialmente en las redes que no soportan la difusión de mensajes. Al igual que en IPv4, el protocolo se encarga de construir tablas de correspondencia entre las direcciones IPv6 y las físicas.
* <div vecinos id="NUD"> Detección de inaccesibilidad de vecinos (NUD, ''Neighbor Unreachability Detection''). Esta función, que no existe en IPv4, permite eliminar de las tablas de configuración de un equipo, los vecinos que se han vuelto inaccesibles (por fallas, cambio de domicilio, ...). Si un enrutador deja de estar disponible, la tabla de enrutamiento puede ser modificada para considerar otra ruta. </div>
* Configuración. La configuración automática de los dispositivos es uno de los principales atractivos de IPv6. Se implementan varias funcionalidades del protocolo de descubrimiento de vecinos:
**Descubrimiento de enrutadores. Este protocolo permite que los dispositivos identifiquen a los enrutadores que se encuentran en su enlace físico. En IPv4, esta función la proporciona el protocolo ''ICMP Router Discovery''.
** Descubrimiento de prefijos. El dispositivo conoce el o los prefijos de red de acuerdo a los anuncios realizados por los enrutadores. Agregando su identificador de interfaz, el dispositivo construye su o sus direcciones IPv6. No hay un mecanismo equivalente para las direcciones IPv4 ya que son demasiado cortas para realizar la auto-configuración.
** Detección de direcciones duplicadas. Dado que las direcciones se configuran de forma automática, existen riesgos de error en caso de tener equipos con identificadores repetidos. Este protocolo verifica que ningún otro equipo en el enlace tiene la misma dirección IPv6. Esta función es una evolución del ARP gratuito en IPv4 emitido durante la inicialización de la interfaz.
** Descubrimiento de parámetros. Este protocolo permite que los dispositivos conozcan los distintos parámetros del enlace físico, por ejemplo, el tamaño de MTU, el número máximo de saltos permitido (valor original del campo número de saltos), si la configuración automática con estado (como [[Configuración con estado: DHCPv6|DHCPv6]]) está activa, etc. No existe un equivalente de esta funcionalidad en IPv4.
* Indicación de redirección. Este mensaje se utiliza cuando un enrutador conoce una trayectoria mejor (medida en número de saltos) para alcanzar un destino.
:En IPv4 una indicación de redireccionamiento sólo puede servir para corregir la dirección del enrutador utilizado para acceder a una máquina fuera de la red local. Los dispositivos deben conocer todas las direcciones correspondientes a equipos conectados en su propia red local.
:EnIPv6, la correspondencia entre prefijo y red local es menos rígida. Es de esperar que un dispositivo no conozca todos los prefijos de su red local (si ésta es compartida por varios prefijos), o que un prefijo se comparta entre varios enlaces (lo que corresponde a una generalización del modelo de redes lógicas IP sobre ATM). Bajo algunas configuraciones, la máquina emitirá sus paquetes al enrutador aún si el destinatario se encuentra en el mismo segmento que el emisor. En este caso, el enrutador emitirá un mensaje de redirección para que la continuación del diálogo entre ellos haga de manera directa (véanse los ejemplos [[#IR|Indicación redirección]]).
:En el caso más extremo, podría imaginarse en IPv6 que un dispositivo puede ser configurado para comunicarse únicamente con su enrutador por omisión. ICMPv6 ''redirect'' puede utilizarse entonces, para informar al dispositivo de destinatarios ubicados en el mismo enlace.

En IPv6 se especifican dos métodos de autoconfiguración para las direcciones unicast global:

* Autoconfiguración sin estado (''stateless autoconfiguration'', RFC 2462). Se utiliza cuando no es necesaria una gestión administrativa de las direcciones asignadas dentro de un sitio. Estos mecanismos se describen más adelante en este capítulo.
* Autoconfiguración con estado (''statefull autoconfiguration''). Se utiliza cuando un sitio requiere de un control estricto de la asignación de direcciones (''cf'' [[Configuración con estado: DHCPv6 | DHCPv6]]).

Sin embargo, el uso de DHCPv6 para obtener la dirección se controla mediante el protocolo de descubrimiento de vecinos.

= Datos transmitidos por los mensajes =

La principal motivación detrás del Protocolo de Descubrimiento de vecinos es unificar varios protocolos existentes en IPv4. En particular, la mayor parte de los datos utiliza un formato de opciones común, lo que simplifica la implementación del protocolo. El formato contiene los campos: tipo, longitud (en palabras de 64 bits), y datos. La baja precisión de campo longitud, presentará un desperdicio de espacio, pero permite una alineación de las opciones en palabras de 64 bits, lo que permite un procesamiento optimizado.

{{NB-Opciones}}

== <div id="física">Dirección física de la fuente/destino</div> ==

<tikz title="Formato de la opción dirección física fuente/destino">
\clip (0.2, 5.7) rectangle (11.1,6.7);
% \draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=1/2}};
\draw (2.9, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{lenght }};
\draw (5.3, 6) node (addr) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Link Layer Address}};

\draw [draw=white, thick] (addr.north east) -- (addr.south east);
\draw [draw=white, thick] (addr.north east) -- +(-2, 0);
\draw [draw=white, thick] (addr.south east) -- +(-2, 0);

\draw [dashed] (addr.north east) -- (addr.south east);
\draw [dashed] (addr.north east) -- +(-2, 0);
\draw [dashed] (addr.south east) -- +(-2, 0);
</tikz>

La figura ''Formato de la opción dirección física fuente/destino'' presenta estas opciones. El tipo 1 designa la dirección física de la fuente y el tipo 2 la dirección del destino.

El campo ''length'' es el tamaño en palabras de 64 bits de la opción. Por lo tanto, para el caso de una dirección MAC con longitud de 6 octetos, contiene el valor 1.

El RFC 2464 define el formato para las direcciones MAC-48 utilizadas en las redes Ethernet y Wi-Fi. El RFC 4944 define el formato para las direcciones MAC-16 y MAC-64 utilizadas en las redes de sensores bajo la norma IEEE 802.15.4.

== <div id="información">Información sobre el prefijo</div> ==

<tikz title="Formato de la opción información sobre el prefijo">
\clip (0.2, 2) rectangle (11.1, 7);
% \draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=3}};
\draw (2.9, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{length =4 }};
\draw (5.3, 6) node (addr) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm] {\tiny{Prefix Length}};
\draw (7.7, 6) node (bitL) [right, shade, top color=blue!15, bottom color=blue!5,, draw, minimum height=0.5cm, minimum width=.3cm]{}; \draw (bitL.text) node {\tiny{L}};
\draw (8, 6) node (bitA) [right, shade, top color=blue!15, bottom color=blue!5,, draw, minimum height=0.5cm, minimum width=.3cm]{};\draw (bitA.text) node {\tiny{A}};
\draw (8.3, 6) node (bitR) [right, shade, top color=blue!15, bottom color=blue!5,, draw, minimum height=0.5cm, minimum width=.3cm]{};\draw (bitR.text) node {\tiny{R}};
\draw (8.6, 6) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=1.5cm] {\tiny{Reserved}};

\draw (0.5, 5.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Valid Lifetime}};

\draw (0.5, 5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Prefered Lifetime}};

\draw (0.5, 4.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Reserved}};

\draw (0.5, 4) node (addr1) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{}};
\draw (0.5, 3.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{}};
\draw (0.5, 3) node (addr3) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Prefix}};
\draw (0.5, 2.5) node (addr4) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{}};

\draw [color=blue!10, very thick] (addr1.south east) -- (addr1.south west);
\draw [color=blue!10, very thick] (addr2.south east) -- (addr2.south west);
\draw [color=blue!10, very thick] (addr3.south east) -- (addr3.south west);
</tikz>

Esta opción contiene las informaciones sobre el prefijo para permitir una configuración automática de los dispositivos. El campo tipo tiene el valor 3 y el de longitud, 4. La figura ''Formato de la opción información sobre el prefijo'' muestra el formato de esta opción:

* El campo ''Prefix lenght'' indica cuántos bits son significativos para el prefijo anunciado en un campo siguiente.
* El bit <tt>L</tt> indica, cuando vale 1, que el prefijo permite indicar que todos los demás dispositivos que comparten el mismo prefijo, están en el mismo enlace, por lo que el emisor puede contactarlos directamente. En caso contrario, el dispositivo envía el paquete hacia el enrutador. Si éste último sabe que el emisor puede contactar directamente al destinatario, emitirá un mensaje ICMPv6 de indicación de redirección.
* El bit <tt>A</tt> indica, cuando vale 1, que el prefijo anunciado puede utilizarse para formar la dirección del dispositivo.
* El bit <tt>R</tt>, indica, cuando vale 1, que el campo prefijo contiene la dirección global de un enrutador ''agente base''. Los bits de mayor peso aún pueden utilizarse para formar un prefijo.
* El campo duración de validez indica, en segundos, la duración durante la cual el prefijo es válido.
* El campo duración preferente indica la duración, en segundos, durante la cual una dirección formada con el protocolo de configuración sin estado se mantiene ''preferente'' (''cf'' [[Planes de direccionamiento|Tiempo de vida de las direcciones]]).

Para estos dos campos, un valor de <tt>0xffffffff</tt> representa una duración infinita. Estos campos pueden servir durante la fase de transición de un proveedor de acceso a otro; es decir, de un prefijo a otro.
* El campo reservado permite alinear el prefijo a una frontera de palabra de 64 bits.
* El campo prefijo contiene el valor de prefijo anunciado sobre el enlace. Para mantener una alineación de 64 bits para el resto de datos del paquete, este campo tiene una longitud fija de 128 bits.

== <div id="redirigida">Cabecera de redirección </div> ==

<tikz title="Formato de la opción cabecera de redirección">
\clip (0.2, 3.1) rectangle (11.1, 7);
% \draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=5}};
\draw (2.9, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{length =1 }};
\draw (5.3, 6) node (addr) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Reserved}};

\draw (0.5, 5.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Reserved}};

\draw (0.5, 4.25) node (context) [right, shade, top color=purple!50, bottom color=purple!10, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{IPv6 Header and Data}};
</tikz>

Esta opción es utilizada por el mensaje de indicación de redirección. Permite encapsular los primeros octetos del paquete IPv6 que provocó la emisión de este mensaje, como ocurre con los mensajes de error de ICMPv6.

El campo tipo tiene el valor 4. El tamaño de esta opción debe evitar que el paquete IPv6 rebase los 1280 octetos (''cf'' figura ''Formato de la opción cabecera de redirección''). Sin embargo, el paquete debe contener la mayor cantidad de información posible.

== <div id="MTU">MTU</div> ==

<tikz title="Formato de la opción MTU">

\clip (0.2, 5.1) rectangle (11.1, 7);
% \draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=5}};
\draw (2.9, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{lenght =1 }};
\draw (5.3, 6) node (addr) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Reserved}};

\draw (0.5, 5.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{MTU}};
</tikz>

Esta opción permite notificar a los dispositivos el tamaño máximo de datos que pueden ser transmitidos sobre el enlace. La figura ''Formato de la opción MTU'' muestra su estructura. No es necesario difundir esta información si el dispositivo utiliza siempre el tamaño máximo permitido. Por ejemplo, sobre las redes Ethernet, los dispositivos utilizarán el valor 1,500. En cambio, en las redes Token Ring o FDDI, con frecuencia es necesario especificar si los equipos pueden utilizar la longitud máxima o un tamaño inferior para permitir el uso de puentes en la red.

En esta opción, el campo tipo tiene un valor de 5 y el de longitud, de 1.

=Mensajes estándar de Descubrimiento de vecinos =

Además de las cinco opciones básicas descritas en la tabla ''Utilización de las opciones en los mensajes de descubrimiento de vecinos'', existen otras específicas para la movilidad y para las redes NBMA (''Non Broadcast Multiple Access'').

{|
|+ Utilización de las opciones en los mensajes de descubrimiento de vecinos
| width = 150 | || width = 100 |[[#RS|Solicitud de]] || width = 100 |[[#RA|Anuncio de]] || width = 100 |[[#NS|Solicitud de]] ||width = 100 | [[#NA|Anuncio de]] ||width = 100 |[[#IR|Indicación de]]
|-
| || [[#RS|enrutador]] || [[#RA|enrutador]] || [[#NS|un vecino]] || [[#NA| un vecino]] || [[#IR|redirección]]
|-style="background:silver"
|[[#física |Dirección física de la fuente]] || presente || presente || presente || ||
|-
|[[# física | Dirección física del destino]] || || || || presente || presente
|-style="background:silver"
|[[#información|Información sobre el prefijo]] || || ≥ 1 || || ||
|-
|[[#redirigida |Cabecera de redirección]] || || || || || presente
|-style="background:silver"
| [[#MTU |MTU]] || || posible || || ||
|}

Las distintas funcionalidades de descubrimiento de vecinos utilizan cinco mensajes: dos para el diálogo entre un dispositivo y un enrutador, dos para el diálogo entre vecinos, y uno para la redirección. Cada uno de estos mensajes puede incluir opciones adicionales.

== <div id="RS">Solicitud de enrutador</div> ==

<tikz title="Formato de los paquetes de solicitud de enrutador">
\clip (0.2, 3.5) rectangle (11.1,7.1);
%\draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=133}};
\draw (2.9, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code =0 }};
\draw (5.3, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};
\draw (0.5, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Reserved}};

\draw (0.5, 4.25) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Options:\\
- Source link-layer address
}};
</tikz>

El mensaje de solicitud de enrutador (''cf'' figura Formato de los paquetes de solicitud de enrutador) es emitido al iniciar un dispositivo para recibir más rápidamente la información del enrutador. Este mensaje se envía a la dirección IPv6 multicast reservada a los enrutadores en el mismo enlace <tt>FF02::2</tt>. Si el dispositivo aún no conoce su dirección fuente, se utiliza la dirección no especificada.

El campo opción normalmente contiene la dirección física del dispositivo.

== <div id="RA">Anuncio de enrutador</div> ==

<tikz title="Formato de los paquetes de anuncio de enrutador">
\clip (0.2, 1.5) rectangle (11.1,7.1);
%\draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=134}};
\draw (2.9, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code =0 }};
\draw (5.3, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};

\draw (0.5, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Cur. Hop Lim.}};
\draw (2.9, 5.5) node (bitM) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{}; \draw (bitM.text) node {\tiny{M}};
\draw (3.2, 5.5) node (bitO) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{};\draw (bitO.text) node {\tiny{O}};
\draw (3.5, 5.5) node (bitH) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{};\draw (bitH.text) node {\tiny{H}};
\draw (3.8, 5.5) node (res) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=1.5cm]{\tiny{reserved}};
\draw (5.3, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Router Lifetime}};

\draw (0.5, 5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=9.6cm]{\tiny{Reachable Time}};
\draw (0.5, 4.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=9.6cm]{\tiny{Retrans Time}};

\draw (0.5, 3.25) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Options:\\
Source link-layer address\\
MTU\\
Prefix Information (may be repeated)\\
}};
</tikz>

Este mensaje (''cf'' figura ''Formato de los paquetes de anuncio de enrutador'') es emitido periódicamente por los enrutadores, o bien, en respuesta a un mensaje de solicitud de enrutador generado por un dispositivo. El campo dirección fuente contiene la dirección de enlace local del enrutador, mientras que el campo dirección destino contiene la dirección del dispositivo que generó la solicitud, o la dirección de todas las estaciones (<tt>ff02::01</tt>).

Cuando el campo de máximo número de saltos tiene un valor distinto de cero, muestra el valor que podría colocarse en el campo de número de saltos de los paquetes emitidos. El bit <tt>M</tt> indica que una dirección del dispositivo debe ser obtenida mediante un protocolo de configuración (''cf'' [[Configuración con estado:DHCPv6]]). El bit <tt>O</tt> también indica la presencia de un servicio de configuración para obtener información adicional a la dirección. Si no es posible obtener la dirección mediante un servidor, el dispositivo procede a realizar una configuración sin estado, concatenando su identificador de interfaz a los prefijos que conoce. El bit <tt>H</tt> indica que el enrutador puede ser utilizado como agente base por un nodo móvil (''cf'' [[Desplazamientos_de_móviles#Anuncio_del_agente_base |Anuncio del agente base]]).

El campo tiempo de vida del enrutador indica el período (en segundos) durante el cual el equipo que emite el anuncio realizará funciones de enrutador por omisión. El valor máximo corresponde a 18 horas 12 minutos, pero como este mensaje se emite periódicamente, en la práctica no existe un límite para el tiempo de vida de un enrutador. Un valor de <tt>0</tt> indica que el dispositivo no cumple con las funciones de enrutador por omisión. Este tiempo de vida no se aplica a las opciones transportadas por este mensaje.

El campo duración de accesibilidad indica el período (en milisegundos) durante el cual una información almacenada en la memoria caché de la máquina (por ejemplo, la tabla de correspondencia entre las direcciones IPv6 y las físicas) puede ser considerada como válida. Al vencimiento de este tiempo, se emite un mensaje de detección de inaccesibilidad para verificar la pertinencia de la información almacenada.

El campo temporización de retransmisión muestra el período (en milisegundos) entre dos emisiones no solicitadas de este mensaje. Permite que los demás equipos puedan detectar la inaccesibilidad de un enrutador.

Este mensaje puede transportar las siguientes opciones:

* dirección física de la fuente,
* MTU,
* información sobre el prefijo (uno o varios).

== <div Id="NS"> Solicitud de un vecino </div> ==

<tikz title="Formato de los paquetes de solicitud de un vecino">

\clip (0.2, 1.5) rectangle (11.1,7.1);
%\draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=135}};
\draw (2.9, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code =0 }};
\draw (5.3, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};

\draw (0.5, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=9.6cm]{\tiny{Reserved}};

\draw (0.5, 4.25) node (context) [right, shade, top color=blue!50, bottom color=blue=!10, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Target Address}};

\draw (0.5, 2.25) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Options:\\
Source link-layer address\\
}};
</tikz>

Este mensaje (''cf'' figura ''Formato de los paquetes de solicitud de un vecino'') permite obtener información a partir de un equipo vecino, es decir, localizado en el mismo enlace físico (o conectado a través de puentes). El mensaje puede ser emitido explícitamente a él, o enviado con una dirección de difusión. En el caso de determinación de la dirección física, éste corresponde a la solicitud de ARP en IPv4.

El campo dirección fuente del paquete IPv6 contiene ya sea la dirección local al enlace, una dirección global o la dirección no especificada. El campo destino puede contener la dirección de difusión múltiple solicitada correspondiente a la dirección buscada (''cf'' [[Direccionamiento_multicast#Identificador_de_grupo|Identificador de grupo]]) o la dirección del dispositivo (en el caso de una detección de inaccesibilidad de vecinos, ''NUD'').

El campo dirección del destino contiene la dirección IPv6 del equipo buscado. El campo opción generalmente contiene la dirección física de la fuente.

== <div Id="NA"> Anuncio de un vecino</div> ==

<tikz title="Formato de los paquetes de anuncio de un vecino">

\clip (0.2, 1.5) rectangle (11.1,7.1);
%\draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=136}};
\draw (2.9, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code =0 }};
\draw (5.3, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};

\draw (0.5, 5.5) node (bitR) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{}; \draw (bitR.text) node {\tiny{R}};
\draw (0.8, 5.5) node (bitS) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{}; \draw (bitS.text) node {\tiny{S}};
\draw (1.1, 5.5) node (bitO) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{}; \draw (bitO.text) node {\tiny{O}};
\draw (1.4, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=8.7cm]{\tiny{Reserved}};

\draw (0.5, 4.25) node (context) [right, shade, top color=blue!50, bottom color=blue=!10, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Target Address}};

\draw (0.5, 2.25) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Options:\\
Source link-layer address\\
}};
</tikz>

Este mensaje (''cf'' figura ''Formato de los paquetes de anuncio de un vecino'') se emite en respuesta a una solicitud, aunque también puede ser emitido de forma espontánea para propagar la información de cambio de dirección física, o del estado de "enrutador". Para el caso de la determinación de la dirección física, es equivalente a la respuesta ARP en IPv4.

* El bit <tt> R </tt> se pone a 1 si el remitente es un enrutador. Este bit se utiliza para permitir la detección de un enrutador que se convierte en un equipo ordinario.
* El bit <tt> S </tt> en 1 indica que este anuncio se emite en respuesta a una solicitud.
* El bit <tt> O </tt> en 1 indica que este anuncio debe borrar las informaciones anteriores que se encuentran almacenadas en la memoria cachés de otros equipos, en especial la tabla que contiene las direcciones físicas.
* El campo dirección del destino contiene, si el bit<tt> S </tt> es 1, el valor del campo dirección del destino de la solicitud a la que está respondiendo este mensaje. Si el bit <tt> S </tt> es 0, este campo contiene la dirección IPv6 local al enlace del equipo emisor.
* La opción dirección física del destino contiene la dirección física del emisor.

== <div id="IR">Indicación de redirección</div> ==

<tikz title="Formato de los paquetes de indicación de redirección">
\clip (0.2, 0) rectangle (11.1,7.1);
%\draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=137}};
\draw (2.9, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code =0 }};
\draw (5.3, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};

\draw (0.5, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=9.6cm]{\tiny{Reserved}};

\draw (0.5, 4.25) node (context) [right, shade, top color=blue!50, bottom color=blue=!10, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Target Address}};

\draw (0.5, 2.25) node (context) [right, shade, top color=blue!50, bottom color=blue=!10, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Destination Address}};

\draw (0.5, 0.5) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=1.5cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Options:\\
Target link-layer address\\
Redirected Header\\
}};
</tikz>

La técnica de redirección es la misma que en IPv4. Un dispositivo sólo conoce los prefijos de las redes a las que está conectado directamente y la dirección de un enrutador por omisión. Si la ruta se puede optimizar, el enrutador por omisión envía un mensaje para indicar que existe un camino más corto. De hecho, como en IPv6 el enrutador por omisión se establece de forma automática, las rutas no necesariamente son las mejores (''cf'' figura ''Enrutamiento por omisión no óptimo'').

Otro caso particular en IPv6 ocurre con los dispositivos que se encuentran en el mismo enlace físico, pero tienen diferentes prefijos. La comunicación entre ellos pasa inicialmente a traves de enrutador por omisión hasta que éste notifica que existe una ruta directa entre ellos.

La figura ''Formato de los paquetes de indicación de redirección'' muestra el formato del mensaje:

* El campo dirección objetivo (''Target address'') contiene la dirección IPv6 del equipo hacia el que los paquetes deben ser enviados.
* El campo dirección destino contiene la dirección IPv6 del dispositivo que está siendo redirigido hacia la dirección objetivo.

Cuando la redirección apunta a un dispositivo situado en el mismo enlace, la dirección objetivo y de destino son las mismas.

Las opciones incluyen la dirección física de un nuevo enrutador y la cabecera del paquete redirigido.

Este mensaje se puede utilizar de la misma forma que en IPv4. Un dispositivo solamente tiene una ruta por omisión para acceder a equipos con un prefijo diferente. En consecuencia, envía su paquete al enrutador por omisión, quien observa que el prefijo destino es accesible a través de la misma subred que el emisor. El enrutador por omisión reenvía el paquete y notifica al emisor que puede contactar directamente a las máquinas que poseen el prefijo del destino.

IPv6 también utiliza este mensaje para optimizar la resolución fuera del enlace para el [[#Caso de redes NBMA |caso de redes NBMA]].

= Configuración automática =
Tradicionalmente, la configuración de una interfaz de red de una máquina se hacía manualmente. Esto suele ser un trabajo lento y propenso a errores. Con IPv6, se automatiza el proceso de configuración y se introducen, al mismo tiempo, mecanismos de funcionamiento inmediato (''plug and play'') a la interfaz de red. La configuración automática significa que un dispositivo obtendrá toda la información necesaria para su conexión a una red local IP sin ninguna intervención humana. En el caso ideal, cualquier usuario desempaca su nuevo equipo, lo conecta a la red local y lo ve funcionar sin tener que introducir la información propia de "especialistas". Ahora vamos a discutir otro aspecto de la configuración automática de IPv6, la auto-configuración de direcciones, que tiene como objetivos:

* La adquisición de una dirección cuando un dispositivo está conectado a una red por primera vez;
* la posibilidad de asignar otros prefijos, o de renumerar un dispositivo.

El proceso de configuración automática de direcciones IPv6 incluye la creación de una dirección local al enlace, la agregación a grupos multicast solicitados, la verificación de la unicidad de la dirección local al enlace y la creación de direcciones unicast global.

La tarea del enrutador es importante en la configuración automática. Indica a la máquina, mediante los bits de la cabecera (''cf'' [[#RA|anuncio de enrutador]]), del mensaje de anuncio de los enrutadores, el método a conservar y eventualmente proporcionar la información necesaria para su configuración. El bit <tt> M </tt> (''configuración de dirección administrada'') puesto a 1 indica que el equipo no debe crear por sí mismo una dirección a partir de su identificador de interfaz y de los prefijos recibidos, sino que debe solicitarla explícitamente ante un servidor de direcciones. El bit O <tt> </tt> (''otra configuración de estado'') indica que el dispositivo debe consultar el servidor para obtener otros parámetros distintos de la dirección. El algoritmo para el proceso de configuración automática de direcciones se desglosa de la siguiente manera:

* La primera fase consiste en crear la dirección local al enlace.
* Una vez que la unicidad de esta dirección es verificada, el dispositivo está listo para comunicarse con otras máquinas en el enlace.
* El dispositivo debe tratar de adquirir un mensaje de anuncio de enrutadores para determinar el método de obtención de la dirección unicast global.
* Si hay un enrutador en el enlace, el dispositivo debe aplicar el método especificado por el mensaje de anuncio de enrutadores, a saber:
** La configuración automática sin estado,
** la configuración automática con estado.
* Si no hay ningún enrutador en el enlace, el dispositivo debe tratar de obtener la dirección unicast global por el método de configuración automática con estado. Si el intento falla, no hay más que hacer. Las comunicaciones sólo podrán hacerse sobre el enlace con la dirección local al enlace, pues el dispositivo no tendrá una dirección con la cobertura necesaria que le permita comunicarse con otras máquinas fuera del enlace.

==Ciclo de vida de una dirección==

Al generalizar en IPv6 el plan de direccionamiento CIDR, los prefijos quedan, en todos los casos, siendo propiedad de los operadores. Ya no pueden otorgarse "a perpetuidad" a los dispositivos. Para facilitar la renumeración de una máquina, la asignación de una dirección a una interfaz es temporal, las direcciones IPv6 no se entregan, sino que se prestan. Se asocia un tiempo de vida a la dirección, que indica el tiempo durante el cual la dirección pertenece a la interfaz. Cuando el tiempo de vida se ha agotada, la dirección deja de ser válida, se suprime de la interfaz y queda potencialmente éste puede prolongarse indefinidamente. La dirección local al enlace tiene un tiempo de vida ilimitado.

<tikz title="Estados sucesivos de una dirección en una interfaz">

\draw [thick, ->] (0,2) -- (9.5,2);

\draw [->] (1,4) node [above=10pt] {\tiny{allocation}}-- (1,2);
\draw (1, 2) node [rectangle, minimum width=1cm, minimum height=1cm, fill, left color=black!10, right color=black!20, draw=black, above right] (tentative) {};
\draw (tentative.south east) node [rectangle, minimum width=3cm, minimum height=1cm, fill, left color=green, right color=green!50, draw=black, above right] (preferred) {};
\draw (preferred.south east) node [rectangle, minimum width=2cm, minimum height=1cm, fill, left color=orange , right color=orange!50!red, draw=black, above right] (deprecated) {};
\draw (deprecated.south east) node [rectangle, minimum width=2cm, minimum height=1cm, fill, color=red, draw=black, above right] (novalid) {};

\draw (tentative.text) node {\tiny{Tentative}};
\draw (preferred.text) node {\tiny{Preferred}};
\draw (deprecated.text) node {\tiny{Deprecated}};
\draw (novalid.text) node {\tiny{Invalid}};

\draw [dotted] (tentative.south west) -- +(0, -1);
\draw [dotted] (preferred.south west) -- +(0, -1);
\draw [dotted] (deprecated.south west) -- +(0, -1);
\draw [dotted] (novalid.south west) -- +(0, -1);

\draw [dashed, <->] ([yshift=-0.5cm]tentative.south west) -- node [above] {\tiny{DAD}} ([yshift=-0.5cm] preferred.south west) ;

\draw [dashed, <->] ([yshift=-0.5cm]preferred.south west) -- node [above] {\tiny{Valid}} ([yshift=-0.5cm] novalid.south west) ;

</tikz>

La renumeración de una interfaz consiste en pasar de una dirección a otra. Durante una renumeración, no es aconsejable cambiar repentinamente de dirección, de lo contrario, todas las comunicaciones TCP que la utilizan como identificador de conexión, se cortarían inmediatamente. Esto conllevaría importantes perturbaciones a nivel de las aplicaciones.

Por ello, para facilitar esta transición se implementó un mecanismo de obsolescencia que invalida gradualmente una dirección. Este mecanismo se sirve de la capacidad de asignación de varias direcciones válidas a una misma interfaz. Para elegir la dirección a utilizar, se le asocia un estado que indica en qué fase de su tiempo de vida se encuentra con respecto a la interfaz. El primero de esos estados se conoce como preferido: no hay ninguna restricción de uso. Poco antes de su invalidación, la dirección pasa a un estado de depreciado. En él se desaconseja el uso de la dirección, pero no está prohibido. Una dirección depreciada ya no debe ser utilizada como dirección fuente de nuevas comunicaciones (como el establecimiento de conexión TCP), pero todavía puede emplearse como dirección fuente de comunicaciones ya establecidas. Los paquetes recibidos a una dirección depreciada seguirán siendo entregados normalmente. El control de la duración de cada estad de una dirección válida se efectúa agregando un tiempo de vida al estado preferido.
La figura '''Estados sucesivos de una dirección en una interfaz''' representa los diferentes estados que toma una dirección cuando se asigna a una interfaz.

== Creación de la dirección local al enlace ==

<tikz title=" Creación de la dirección local al enlace">
\clip (0, 0) rectangle (10,7);
% \draw[help lines] (0,0) grid (10,7 );

\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,3)--(9,3);

\pgfputat{\pgfxy(0.8,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,5)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,3)--(1.5,5);
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (8,3)--(8,5);

\draw (1.5,4.5) node {\small{FE80::IID1}};
\draw (1.5,4) node {\small{$\alpha$::IID1/64}};

\draw (8, 4.5) node {\small{FE80::IID2}};

</tikz>

Durante la inicialización de la interfaz, el dispositivo construye un identificador de interfaz que debe ser único en el enlace. Este identificador se utiliza la dirección de [[ Identificador_de_interfaz#EUI-64 | EUI-64]]. El principio básico para crear la direcciónIPv6 consiste en unir un prefijo con el identificador. La dirección local al enlace se crea tomando el prefijo de Enlace_local (<tt>FE80::/64</tt>). La dirección creada de esa manera, todavía no puede ser utilizada; tiene un estado temporal pues el dispositivo debe comprobar la exclusividad de esta dirección en el enlace mediante el procedimiento de detección de direcciones duplicadas. Si se encuentra que la dirección local al enlace no es única, se suspende la autoconfiguración y será necesario proceder a una configuración manual.

Una vez que se ha asegurado la unicidad de la dirección local al enlace, ésta se considera una dirección válida para la interfaz, con lo que termina la prima fase del proceso de autoconfiguración.

==<div id="DAD"> Detección de una dirección duplicada </div>==

<tikz title="Emisión de un NS en una detección de Dir. duplicada (DAD)">
\clip (0, 0) rectangle (10,7);
% \draw[help lines] (0,0) grid (10,7 );

\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,3)--(9,3);

\pgfputat{\pgfxy(0.8,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,5)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,3)--(1.5,5);
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (8,3)--(8,5);

\draw (7.8, 5) -- (7.8, 3.2);
\draw [<->] (1, 3.2) -- node [above] {\tiny{::/0 -$>$ solicited (FE80:IID2) : NS (who has FE80::IID2?)}}(9, 3.2) ;

</tikz>

Para comprobar la exclusividad de direcciones locales al enlace o de direcciones unicast, los dispositivos deben ejecutar un algoritmo de detección de direcciones duplicadas (DAD) antes poder utilizarlas. El algoritmo usa los mensajes ICMPv6 [[Protocolo_de_Descubrimiento_de_vecinos#NS|solicitud de un vecino]] y [[#NA|anuncio de un vecino.]] Si se detecta una dirección que ya está en uso, ésta no podrá ser asignada a la interfaz, la autoconfiguración automática debe suspenderse y será necesario proceder a una configuración manual. Durante la ejecución del algoritmo DAD, la dirección es considerada como "provisional" hasta tener la confirmación de su unicidad. Una dirección provisional se asigna a una interfaz únicamente para recibir los mensajes de solicitud y anuncio de un vecino. Otros mensajes recibidos, son ignorados. El algoritmo DAD consiste en enviar un mensaje de solicitud de un vecino colocando en el campo de dirección objetivo la dirección provisional. Para distinguir el algoritmo DAD del de Descubrimiento de vecinos, el paquete IPv6 que contiene un mensaje de solicitud de un vecino tiene como dirección fuente una dirección no determinada. Así se presentan tres casos:

* Se recibe un mensaje de anucio de un vecino: Significa que la dirección provisional está siendo utilizada como válida por otro dispositivo, por lo que ésta no es única y no puede ser retenida por el dispositivo.
* Se recibe un mensaje de solicitud de un vecino como parte del algoritmo DAD. La dirección provisional también es provisional para otra máquina. En este caso, la dirección provisional no puede ser utilizada por ninguna de ellas.
* No se recibe ningún mensaje durante un segundo (valor por omisión). La dirección provisional es única, por lo que su estado pasa de provisional a válida y se le asigna a la interfaz.

Obsérvese que este algoritmo no proporciona una fiabilidad absoluta, especialmente cuando el enlace está segmentado.

== Autoconfiguración sin estado ==

<tikz title="Emisión de un RS">
\clip (0, 0) rectangle (10,7);
% \draw[help lines] (0,0) grid (10,7 );

\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,3)--(9,3);

\pgfputat{\pgfxy(0.8,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,5)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,3)--(1.5,5);
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (8,3)--(8,5);

\draw (7.8, 5) -- (7.8, 3.2);
\draw [<->] (1, 3.2) -- node [above] {\tiny{FE80::IID2 -$>$ FF02::2 : RS }} (9, 3.2) ;

</tikz>

La configuración automática sin estado (RFC 2462) no requiere de ninguna configuración manual de los dispositivos, una configuración mínima para los enrutadores, y tampoco necesita de servidores adicionales. Se sirve del protocolo ICMPv6 y puede operar aún sin la presencia de enrutadores. En cambio, sí requiere de una subred con soporte a la difusión de paquetes. Este método sólo aplica para los dispositivos; no puede ser utilizada para configurar enrutadores. El principio básico de este mecanismo consiste en que una máquina genera su dirección IPv6 a partir de información local y de la proporcionada por un enrutador. El enrutador proporciona información sobre la subred asociada al enlace; anuncia el prefijo.

<tikz title="Recepción de un RA">
\clip (0, 0) rectangle (10,7);
% \draw[help lines] (0,0) grid (10,7 );

\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,3)--(9,3);

\pgfputat{\pgfxy(0.8,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,5)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,3)--(1.5,5);
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (8,3)--(8,5);

\draw [->] (1.7,5) -- (1.7, 3.2) -- node [above = 10pt] {\tiny{FE80::IID1 -$>$ FE80::IID2}} node [above] {\tiny{RA ($\alpha$::/64, DHCPv6, MTU=1500, HL=64, {bit {\tt M=1}) }}} (7.8, 3.2) -- (7.8, 5);

</tikz>

Al igual que para la creación de la dirección de enlace local, la dirección unicast global se obtiene al concatenar el prefijo con el identificador de la interfaz. El prefijo se obtiene del mensaje de anuncio de enrutador, más concretamente, de la opción de ''información sobre el prefijo''. Si bien debe verificarse la unicidad de todas las direcciones unicast, en el caso de una dirección unicast obtenida mediante la configuración automática sin estado, esto no es obligatorio, pues la unicidad del identificador de la interfaz ya fue comprobada durante la configuración de la dirección local al enlace. Dado que el identificador es el mismo, no puede haber ambigüedad sobre la exclusividad de la dirección unicast global creada de esta forma.

La renumeración de los dispositivos en un enlace se realiza mediante enrutadores que transfieren las direcciones utilizadas a un estado depreciado y al mismo tiempo anuncian el nuevo prefijo con el que los dispositivos pueden re-crear una dirección preferida.

===Caso de redes NBMA ===

<tikz title="Off Link NDP: Primera etapa">
\clip (0, 0) rectangle (11,7);
% \draw[help lines] (0,0) grid (10,7 );

\pgfputat{\pgfxy(4.5,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}
\pgfputat{\pgfxy(1.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[decorate,decoration={zigzag}, color=black!60, ->, very thick] (8,3)-- node [above, color=black] {\tiny{FE80::IID2 -$>$ FF02::2 : RS}} (5,5);

</tikz>

Las redes NBMA (''Non Broadcast Multiple Access'') se caracterizan por no contar con un mecanismo de difusión hacia todos los dispositivos. Esto conduce a dos situiaciones posibles:
* ausencia total de difusión, como en las redes públicas (telefónica, ATM, …) en las que un solo destinatario puede ser contactado a la vez
* posibilidad de difusión por un número limitado de equipos, como es el caso de las redes de radio tipo 3G, WiMAX, en las que la estación base tiene la posibilidad de difundir datos hacia todos los equipos, pero esto no es posible en el sentido inverso (desde un dispositivo).

<tikz title="Off Link NDP: Segunda etapa">
\clip (0, 0) rectangle (11,7);
% \draw[help lines] (0,0) grid (10,7 );

\pgfputat{\pgfxy(4.5,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}
\pgfputat{\pgfxy(1.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[decorate,decoration={zigzag}, color=black!60, ->, very thick] (5, 5)-- node [above, color=black] {\tiny{RA ($\alpha$::/64, DHCPv6, OffLink, MTU=1500, HL=64, {bit {\tt M=1}})}} (8,3);

</tikz>

Un comportamiento de redes NBMA también puede ser deseable para limitar las restricciones de consumo energético. Por ejemplo, en el caso de redes de sensores, la difusión, o la difusión restringida (multicast) son costosas en consumo de energía pues todos los dispositivos deben procesar el mensaje y algunos deberán retransmitirlo.

<tikz title="Off Link NDP: Tercera etapa">
\clip (0, 0) rectangle (11,7);
% \draw[help lines] (0,0) grid (10,7 );

\pgfputat{\pgfxy(4.5,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}
\pgfputat{\pgfxy(1.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[decorate,decoration={zigzag}, color=black!60, ->, very thick] (8,3)-- node [left, near start, color=black] {\tiny{$\alpha$::IID2 -$>$ $\alpha$::IID3 : DATA}} (5,5);

\draw[decorate,decoration={zigzag}, color=black!60, ->, very thick] (5,5)-- node [left, midway, color=black] {\tiny{$\alpha$::IID2 -$>$ $\alpha$::IID3 : DATA}} (2,3);

</tikz>

Para estos casos, el protocolo de descubrimiento de vecinos cuenta con un modo NBMA llamado también ''OffLink'', el cual solamente autoriza el diálogo con un enrutador. Los intercambios comienzan de la misma forma:
* El dispositivo que desea insertarse en la red, emite un mensaje RS (''Router Sollicitation'') utilizando la dirección destino FF02::2 (todos los enrutadores sobre el enlace. La red NBMA deberá enviar este mensaje hacia un enrutador.
* El enrutador responde poniendo el bit <tt>L</tt> (OffLink) a 1 en la opción [[#información|Información sobre el prefijo]], indicando que todos los intercambios deben pasar por él.
* El dispositivo construye su dirección global concatenando el prefijo a su identificador de interfaz.
* El dispositivo envía sistemáticamente todos los paquetes a la dirección física del enrutador. Éste, que tiene una visión global de la red, los reenvía hacia el destinatario apropiado.

<tikz title="Off Link NDP: Cuarta etapa (opcional)">
\clip (0, 0) rectangle (11,7);
% \draw[help lines] (0,0) grid (10,7 );

\pgfputat{\pgfxy(4.5,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}
\pgfputat{\pgfxy(1.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[decorate,decoration={zigzag}, color=black!60, ->, very thick] (8,3)-- node [left, near end, color=black] {\tiny{$\alpha$::IID2 -$>$ $\alpha$::IID3 : DATA}} (5,5);

\draw[decorate,decoration={zigzag}, color=black!60, ->, very thick] (5,5)-- node [left, midway, color=black] {\tiny{$\alpha$::IID2 -$>$ $\alpha$::IID3 : DATA}} (2,3);

\draw[decorate,decoration={triangles}, color=black!60, ->, thick, ] (5,5) to [bend left] node [right, near start, color=black] {\tiny{REDIRECT $\alpha$::IID3 : MAC3}} (8,3);

\draw [color=black!60, ->, very thick, dotted] (8,3)-- node [above, midway, color=black] {\tiny{$\alpha$::IID2 -$>$ $\alpha$::IID3 : DATA}} (2,3);

</tikz>

* Si la tecnología del enlace lo permite y si la política de gestión de red lo autoriza, el enrutador tiene la posibilidad de optimizar el tráfico, notificando al dispositivo la verdadera dirección del destinatario, emitiendo un mensaje de [[#IR|indicación de redirección]] (''ICMP Redirect''). Los paquetes subsecuentes ya no pasarán por el enrutador.

{{eSuivi|Tabla de contenido|Incio del capítulo|DHCPv6|DHCPv6}}

Protocolo de Descubrimiento de vecinos

2012-07-05T18:56:03Z

Jincera: /* Caso de redes NBMA */

{{eSuivi|Tabla de contenido|Incio del capítulo|DHCPv6|DHCPv6}}

__TOC__

El protocolo de descubrimiento de vecinos (NDP, ''Neighbor Discovery Protocol'') permite a un dispositivo integrarse en el ambiente local, es decir, el enlace sobre el cual se transmiten físicamente los paquetes IPv6. Permite establecer un diálogo con los equipos (estaciones y enrutadores) conectados sobre el mismo medio. No se pretende que un dispositivo conozca con exactitud la lista de todos los demás dispositivos conectados al enlace, sino de proveer un mecanismo para dialogar con quien necesite hacerlo.

El protocolo utiliza cinco tipos de mensajes ICMPv6 (ver Valores de los campos de tipo y código de ICMPv6). El campo número de saltos de la cabecera IPv6 contiene el valor 255. Este valor parece demasiado grande para datagramas que no debieran ser enrutados fuera del enlace físico. En realidad, si un equipo recibe un datagrama con un valor menor, significa que la información proviene de otra red y que ya ha atravesado al menos un enrutador. Por ello, los datagramas que tienen un valor diferente de 255 deben ser ignorados por el receptor.

{{Tableau eICMPv6}}

El protocolo realiza varias funciones:

* Resolución de direcciones. El principio es muy similar al del protocolo ARP de IPv4. La principal diferencia consiste en el uso de mensajes ICMPv6 estándar en lugar de definir otro protocolo de capa 3. Con esto se consigue una mayor flexibilidad de uso, especialmente en las redes que no soportan la difusión de mensajes. Al igual que en IPv4, el protocolo se encarga de construir tablas de correspondencia entre las direcciones IPv6 y las físicas.
* <div vecinos id="NUD"> Detección de inaccesibilidad de vecinos (NUD, ''Neighbor Unreachability Detection''). Esta función, que no existe en IPv4, permite eliminar de las tablas de configuración de un equipo, los vecinos que se han vuelto inaccesibles (por fallas, cambio de domicilio, ...). Si un enrutador deja de estar disponible, la tabla de enrutamiento puede ser modificada para considerar otra ruta. </div>
* Configuración. La configuración automática de los dispositivos es uno de los principales atractivos de IPv6. Se implementan varias funcionalidades del protocolo de descubrimiento de vecinos:
**Descubrimiento de enrutadores. Este protocolo permite que los dispositivos identifiquen a los enrutadores que se encuentran en su enlace físico. En IPv4, esta función la proporciona el protocolo ''ICMP Router Discovery''.
** Descubrimiento de prefijos. El dispositivo conoce el o los prefijos de red de acuerdo a los anuncios realizados por los enrutadores. Agregando su identificador de interfaz, el dispositivo construye su o sus direcciones IPv6. No hay un mecanismo equivalente para las direcciones IPv4 ya que son demasiado cortas para realizar la auto-configuración.
** Detección de direcciones duplicadas. Dado que las direcciones se configuran de forma automática, existen riesgos de error en caso de tener equipos con identificadores repetidos. Este protocolo verifica que ningún otro equipo en el enlace tiene la misma dirección IPv6. Esta función es una evolución del ARP gratuito en IPv4 emitido durante la inicialización de la interfaz.
** Descubrimiento de parámetros. Este protocolo permite que los dispositivos conozcan los distintos parámetros del enlace físico, por ejemplo, el tamaño de MTU, el número máximo de saltos permitido (valor original del campo número de saltos), si la configuración automática con estado (como [[Configuración con estado: DHCPv6|DHCPv6]]) está activa, etc. No existe un equivalente de esta funcionalidad en IPv4.
* Indicación de redirección. Este mensaje se utiliza cuando un enrutador conoce una trayectoria mejor (medida en número de saltos) para alcanzar un destino.
:En IPv4 una indicación de redireccionamiento sólo puede servir para corregir la dirección del enrutador utilizado para acceder a una máquina fuera de la red local. Los dispositivos deben conocer todas las direcciones correspondientes a equipos conectados en su propia red local.
:EnIPv6, la correspondencia entre prefijo y red local es menos rígida. Es de esperar que un dispositivo no conozca todos los prefijos de su red local (si ésta es compartida por varios prefijos), o que un prefijo se comparta entre varios enlaces (lo que corresponde a una generalización del modelo de redes lógicas IP sobre ATM). Bajo algunas configuraciones, la máquina emitirá sus paquetes al enrutador aún si el destinatario se encuentra en el mismo segmento que el emisor. En este caso, el enrutador emitirá un mensaje de redirección para que la continuación del diálogo entre ellos haga de manera directa (véanse los ejemplos [[#IR|Indicación redirección]]).
:En el caso más extremo, podría imaginarse en IPv6 que un dispositivo puede ser configurado para comunicarse únicamente con su enrutador por omisión. ICMPv6 ''redirect'' puede utilizarse entonces, para informar al dispositivo de destinatarios ubicados en el mismo enlace.

En IPv6 se especifican dos métodos de autoconfiguración para las direcciones unicast global:

* Autoconfiguración sin estado (''stateless autoconfiguration'', RFC 2462). Se utiliza cuando no es necesaria una gestión administrativa de las direcciones asignadas dentro de un sitio. Estos mecanismos se describen más adelante en este capítulo.
* Autoconfiguración con estado (''statefull autoconfiguration''). Se utiliza cuando un sitio requiere de un control estricto de la asignación de direcciones (''cf'' [[Configuración con estado: DHCPv6 | DHCPv6]]).

Sin embargo, el uso de DHCPv6 para obtener la dirección se controla mediante el protocolo de descubrimiento de vecinos.

= Datos transmitidos por los mensajes =

La principal motivación detrás del Protocolo de Descubrimiento de vecinos es unificar varios protocolos existentes en IPv4. En particular, la mayor parte de los datos utiliza un formato de opciones común, lo que simplifica la implementación del protocolo. El formato contiene los campos: tipo, longitud (en palabras de 64 bits), y datos. La baja precisión de campo longitud, presentará un desperdicio de espacio, pero permite una alineación de las opciones en palabras de 64 bits, lo que permite un procesamiento optimizado.

{{NB-Opciones}}

== <div id="física">Dirección física de la fuente/destino</div> ==

<tikz title="Formato de la opción dirección física fuente/destino">
\clip (0.2, 5.7) rectangle (11.1,6.7);
% \draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=1/2}};
\draw (2.9, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{lenght }};
\draw (5.3, 6) node (addr) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Link Layer Address}};

\draw [draw=white, thick] (addr.north east) -- (addr.south east);
\draw [draw=white, thick] (addr.north east) -- +(-2, 0);
\draw [draw=white, thick] (addr.south east) -- +(-2, 0);

\draw [dashed] (addr.north east) -- (addr.south east);
\draw [dashed] (addr.north east) -- +(-2, 0);
\draw [dashed] (addr.south east) -- +(-2, 0);
</tikz>

La figura ''Formato de la opción dirección física fuente/destino'' presenta estas opciones. El tipo 1 designa la dirección física de la fuente y el tipo 2 la dirección del destino.

El campo ''length'' es el tamaño en palabras de 64 bits de la opción. Por lo tanto, para el caso de una dirección MAC con longitud de 6 octetos, contiene el valor 1.

El RFC 2464 define el formato para las direcciones MAC-48 utilizadas en las redes Ethernet y Wi-Fi. El RFC 4944 define el formato para las direcciones MAC-16 y MAC-64 utilizadas en las redes de sensores bajo la norma IEEE 802.15.4.

== <div id="información">Información sobre el prefijo</div> ==

<tikz title="Formato de la opción información sobre el prefijo">
\clip (0.2, 2) rectangle (11.1, 7);
% \draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=3}};
\draw (2.9, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{length =4 }};
\draw (5.3, 6) node (addr) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm] {\tiny{Prefix Length}};
\draw (7.7, 6) node (bitL) [right, shade, top color=blue!15, bottom color=blue!5,, draw, minimum height=0.5cm, minimum width=.3cm]{}; \draw (bitL.text) node {\tiny{L}};
\draw (8, 6) node (bitA) [right, shade, top color=blue!15, bottom color=blue!5,, draw, minimum height=0.5cm, minimum width=.3cm]{};\draw (bitA.text) node {\tiny{A}};
\draw (8.3, 6) node (bitR) [right, shade, top color=blue!15, bottom color=blue!5,, draw, minimum height=0.5cm, minimum width=.3cm]{};\draw (bitR.text) node {\tiny{R}};
\draw (8.6, 6) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=1.5cm] {\tiny{Reserved}};

\draw (0.5, 5.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Valid Lifetime}};

\draw (0.5, 5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Prefered Lifetime}};

\draw (0.5, 4.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Reserved}};

\draw (0.5, 4) node (addr1) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{}};
\draw (0.5, 3.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{}};
\draw (0.5, 3) node (addr3) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Prefix}};
\draw (0.5, 2.5) node (addr4) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{}};

\draw [color=blue!10, very thick] (addr1.south east) -- (addr1.south west);
\draw [color=blue!10, very thick] (addr2.south east) -- (addr2.south west);
\draw [color=blue!10, very thick] (addr3.south east) -- (addr3.south west);
</tikz>

Esta opción contiene las informaciones sobre el prefijo para permitir una configuración automática de los dispositivos. El campo tipo tiene el valor 3 y el de longitud, 4. La figura ''Formato de la opción información sobre el prefijo'' muestra el formato de esta opción:

* El campo ''Prefix lenght'' indica cuántos bits son significativos para el prefijo anunciado en un campo siguiente.
* El bit <tt>L</tt> indica, cuando vale 1, que el prefijo permite indicar que todos los demás dispositivos que comparten el mismo prefijo, están en el mismo enlace, por lo que el emisor puede contactarlos directamente. En caso contrario, el dispositivo envía el paquete hacia el enrutador. Si éste último sabe que el emisor puede contactar directamente al destinatario, emitirá un mensaje ICMPv6 de indicación de redirección.
* El bit <tt>A</tt> indica, cuando vale 1, que el prefijo anunciado puede utilizarse para formar la dirección del dispositivo.
* El bit <tt>R</tt>, indica, cuando vale 1, que el campo prefijo contiene la dirección global de un enrutador ''agente base''. Los bits de mayor peso aún pueden utilizarse para formar un prefijo.
* El campo duración de validez indica, en segundos, la duración durante la cual el prefijo es válido.
* El campo duración preferente indica la duración, en segundos, durante la cual una dirección formada con el protocolo de configuración sin estado se mantiene ''preferente'' (''cf'' [[Planes de direccionamiento|Tiempo de vida de las direcciones]]).

Para estos dos campos, un valor de <tt>0xffffffff</tt> representa una duración infinita. Estos campos pueden servir durante la fase de transición de un proveedor de acceso a otro; es decir, de un prefijo a otro.
* El campo reservado permite alinear el prefijo a una frontera de palabra de 64 bits.
* El campo prefijo contiene el valor de prefijo anunciado sobre el enlace. Para mantener una alineación de 64 bits para el resto de datos del paquete, este campo tiene una longitud fija de 128 bits.

== <div id="redirigida">Cabecera de redirección </div> ==

<tikz title="Formato de la opción cabecera de redirección">
\clip (0.2, 3.1) rectangle (11.1, 7);
% \draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=5}};
\draw (2.9, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{length =1 }};
\draw (5.3, 6) node (addr) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Reserved}};

\draw (0.5, 5.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Reserved}};

\draw (0.5, 4.25) node (context) [right, shade, top color=purple!50, bottom color=purple!10, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{IPv6 Header and Data}};
</tikz>

Esta opción es utilizada por el mensaje de indicación de redirección. Permite encapsular los primeros octetos del paquete IPv6 que provocó la emisión de este mensaje, como ocurre con los mensajes de error de ICMPv6.

El campo tipo tiene el valor 4. El tamaño de esta opción debe evitar que el paquete IPv6 rebase los 1280 octetos (''cf'' figura ''Formato de la opción cabecera de redirección''). Sin embargo, el paquete debe contener la mayor cantidad de información posible.

== <div id="MTU">MTU</div> ==

<tikz title="Formato de la opción MTU">

\clip (0.2, 5.1) rectangle (11.1, 7);
% \draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=5}};
\draw (2.9, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{lenght =1 }};
\draw (5.3, 6) node (addr) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Reserved}};

\draw (0.5, 5.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{MTU}};
</tikz>

Esta opción permite notificar a los dispositivos el tamaño máximo de datos que pueden ser transmitidos sobre el enlace. La figura ''Formato de la opción MTU'' muestra su estructura. No es necesario difundir esta información si el dispositivo utiliza siempre el tamaño máximo permitido. Por ejemplo, sobre las redes Ethernet, los dispositivos utilizarán el valor 1,500. En cambio, en las redes Token Ring o FDDI, con frecuencia es necesario especificar si los equipos pueden utilizar la longitud máxima o un tamaño inferior para permitir el uso de puentes en la red.

En esta opción, el campo tipo tiene un valor de 5 y el de longitud, de 1.

=Mensajes estándar de Descubrimiento de vecinos =

Además de las cinco opciones básicas descritas en la tabla ''Utilización de las opciones en los mensajes de descubrimiento de vecinos'', existen otras específicas para la movilidad y para las redes NBMA (''Non Broadcast Multiple Access'').

{|
|+ Utilización de las opciones en los mensajes de descubrimiento de vecinos
| width = 150 | || width = 100 |[[#RS|Solicitud de]] || width = 100 |[[#RA|Anuncio de]] || width = 100 |[[#NS|Solicitud de]] ||width = 100 | [[#NA|Anuncio de]] ||width = 100 |[[#IR|Indicación de]]
|-
| || [[#RS|enrutador]] || [[#RA|enrutador]] || [[#NS|un vecino]] || [[#NA| un vecino]] || [[#IR|redirección]]
|-style="background:silver"
|[[#física |Dirección física de la fuente]] || presente || presente || presente || ||
|-
|[[# física | Dirección física del destino]] || || || || presente || presente
|-style="background:silver"
|[[#información|Información sobre el prefijo]] || || ≥ 1 || || ||
|-
|[[#redirigida |Cabecera de redirección]] || || || || || presente
|-style="background:silver"
| [[#MTU |MTU]] || || posible || || ||
|}

Las distintas funcionalidades de descubrimiento de vecinos utilizan cinco mensajes: dos para el diálogo entre un dispositivo y un enrutador, dos para el diálogo entre vecinos, y uno para la redirección. Cada uno de estos mensajes puede incluir opciones adicionales.

== <div id="RS">Solicitud de enrutador</div> ==

<tikz title="Formato de los paquetes de solicitud de enrutador">
\clip (0.2, 3.5) rectangle (11.1,7.1);
%\draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=133}};
\draw (2.9, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code =0 }};
\draw (5.3, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};
\draw (0.5, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Reserved}};

\draw (0.5, 4.25) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Options:\\
- Source link-layer address
}};
</tikz>

El mensaje de solicitud de enrutador (''cf'' figura Formato de los paquetes de solicitud de enrutador) es emitido al iniciar un dispositivo para recibir más rápidamente la información del enrutador. Este mensaje se envía a la dirección IPv6 multicast reservada a los enrutadores en el mismo enlace <tt>FF02::2</tt>. Si el dispositivo aún no conoce su dirección fuente, se utiliza la dirección no especificada.

El campo opción normalmente contiene la dirección física del dispositivo.

== <div id="RA">Anuncio de enrutador</div> ==

<tikz title="Formato de los paquetes de anuncio de enrutador">
\clip (0.2, 1.5) rectangle (11.1,7.1);
%\draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=134}};
\draw (2.9, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code =0 }};
\draw (5.3, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};

\draw (0.5, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Cur. Hop Lim.}};
\draw (2.9, 5.5) node (bitM) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{}; \draw (bitM.text) node {\tiny{M}};
\draw (3.2, 5.5) node (bitO) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{};\draw (bitO.text) node {\tiny{O}};
\draw (3.5, 5.5) node (bitH) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{};\draw (bitH.text) node {\tiny{H}};
\draw (3.8, 5.5) node (res) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=1.5cm]{\tiny{reserved}};
\draw (5.3, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Router Lifetime}};

\draw (0.5, 5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=9.6cm]{\tiny{Reachable Time}};
\draw (0.5, 4.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=9.6cm]{\tiny{Retrans Time}};

\draw (0.5, 3.25) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Options:\\
Source link-layer address\\
MTU\\
Prefix Information (may be repeated)\\
}};
</tikz>

Este mensaje (''cf'' figura ''Formato de los paquetes de anuncio de enrutador'') es emitido periódicamente por los enrutadores, o bien, en respuesta a un mensaje de solicitud de enrutador generado por un dispositivo. El campo dirección fuente contiene la dirección de enlace local del enrutador, mientras que el campo dirección destino contiene la dirección del dispositivo que generó la solicitud, o la dirección de todas las estaciones (<tt>ff02::01</tt>).

Cuando el campo de máximo número de saltos tiene un valor distinto de cero, muestra el valor que podría colocarse en el campo de número de saltos de los paquetes emitidos. El bit <tt>M</tt> indica que una dirección del dispositivo debe ser obtenida mediante un protocolo de configuración (''cf'' [[Configuración con estado:DHCPv6]]). El bit <tt>O</tt> también indica la presencia de un servicio de configuración para obtener información adicional a la dirección. Si no es posible obtener la dirección mediante un servidor, el dispositivo procede a realizar una configuración sin estado, concatenando su identificador de interfaz a los prefijos que conoce. El bit <tt>H</tt> indica que el enrutador puede ser utilizado como agente base por un nodo móvil (''cf'' [[Desplazamientos_de_móviles#Anuncio_del_agente_base |Anuncio del agente base]]).

El campo tiempo de vida del enrutador indica el período (en segundos) durante el cual el equipo que emite el anuncio realizará funciones de enrutador por omisión. El valor máximo corresponde a 18 horas 12 minutos, pero como este mensaje se emite periódicamente, en la práctica no existe un límite para el tiempo de vida de un enrutador. Un valor de <tt>0</tt> indica que el dispositivo no cumple con las funciones de enrutador por omisión. Este tiempo de vida no se aplica a las opciones transportadas por este mensaje.

El campo duración de accesibilidad indica el período (en milisegundos) durante el cual una información almacenada en la memoria caché de la máquina (por ejemplo, la tabla de correspondencia entre las direcciones IPv6 y las físicas) puede ser considerada como válida. Al vencimiento de este tiempo, se emite un mensaje de detección de inaccesibilidad para verificar la pertinencia de la información almacenada.

El campo temporización de retransmisión muestra el período (en milisegundos) entre dos emisiones no solicitadas de este mensaje. Permite que los demás equipos puedan detectar la inaccesibilidad de un enrutador.

Este mensaje puede transportar las siguientes opciones:

* dirección física de la fuente,
* MTU,
* información sobre el prefijo (uno o varios).

== <div Id="NS"> Solicitud de un vecino </div> ==

<tikz title="Formato de los paquetes de solicitud de un vecino">

\clip (0.2, 1.5) rectangle (11.1,7.1);
%\draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=135}};
\draw (2.9, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code =0 }};
\draw (5.3, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};

\draw (0.5, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=9.6cm]{\tiny{Reserved}};

\draw (0.5, 4.25) node (context) [right, shade, top color=blue!50, bottom color=blue=!10, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Target Address}};

\draw (0.5, 2.25) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Options:\\
Source link-layer address\\
}};
</tikz>

Este mensaje (''cf'' figura ''Formato de los paquetes de solicitud de un vecino'') permite obtener información a partir de un equipo vecino, es decir, localizado en el mismo enlace físico (o conectado a través de puentes). El mensaje puede ser emitido explícitamente a él, o enviado con una dirección de difusión. En el caso de determinación de la dirección física, éste corresponde a la solicitud de ARP en IPv4.

El campo dirección fuente del paquete IPv6 contiene ya sea la dirección local al enlace, una dirección global o la dirección no especificada. El campo destino puede contener la dirección de difusión múltiple solicitada correspondiente a la dirección buscada (''cf'' [[Direccionamiento_multicast#Identificador_de_grupo|Identificador de grupo]]) o la dirección del dispositivo (en el caso de una detección de inaccesibilidad de vecinos, ''NUD'').

El campo dirección del destino contiene la dirección IPv6 del equipo buscado. El campo opción generalmente contiene la dirección física de la fuente.

== <div Id="NA"> Anuncio de un vecino</div> ==

<tikz title="Formato de los paquetes de anuncio de un vecino">

\clip (0.2, 1.5) rectangle (11.1,7.1);
%\draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=136}};
\draw (2.9, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code =0 }};
\draw (5.3, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};

\draw (0.5, 5.5) node (bitR) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{}; \draw (bitR.text) node {\tiny{R}};
\draw (0.8, 5.5) node (bitS) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{}; \draw (bitS.text) node {\tiny{S}};
\draw (1.1, 5.5) node (bitO) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{}; \draw (bitO.text) node {\tiny{O}};
\draw (1.4, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=8.7cm]{\tiny{Reserved}};

\draw (0.5, 4.25) node (context) [right, shade, top color=blue!50, bottom color=blue=!10, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Target Address}};

\draw (0.5, 2.25) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Options:\\
Source link-layer address\\
}};
</tikz>

Este mensaje (''cf'' figura ''Formato de los paquetes de anuncio de un vecino'') se emite en respuesta a una solicitud, aunque también puede ser emitido de forma espontánea para propagar la información de cambio de dirección física, o del estado de "enrutador". Para el caso de la determinación de la dirección física, es equivalente a la respuesta ARP en IPv4.

* El bit <tt> R </tt> se pone a 1 si el remitente es un enrutador. Este bit se utiliza para permitir la detección de un enrutador que se convierte en un equipo ordinario.
* El bit <tt> S </tt> en 1 indica que este anuncio se emite en respuesta a una solicitud.
* El bit <tt> O </tt> en 1 indica que este anuncio debe borrar las informaciones anteriores que se encuentran almacenadas en la memoria cachés de otros equipos, en especial la tabla que contiene las direcciones físicas.
* El campo dirección del destino contiene, si el bit<tt> S </tt> es 1, el valor del campo dirección del destino de la solicitud a la que está respondiendo este mensaje. Si el bit <tt> S </tt> es 0, este campo contiene la dirección IPv6 local al enlace del equipo emisor.
* La opción dirección física del destino contiene la dirección física del emisor.

== <div id="IR">Indicación de redirección</div> ==

<tikz title="Formato de los paquetes de indicación de redirección">
\clip (0.2, 0) rectangle (11.1,7.1);
%\draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=137}};
\draw (2.9, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code =0 }};
\draw (5.3, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};

\draw (0.5, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=9.6cm]{\tiny{Reserved}};

\draw (0.5, 4.25) node (context) [right, shade, top color=blue!50, bottom color=blue=!10, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Target Address}};

\draw (0.5, 2.25) node (context) [right, shade, top color=blue!50, bottom color=blue=!10, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Destination Address}};

\draw (0.5, 0.5) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=1.5cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Options:\\
Target link-layer address\\
Redirected Header\\
}};
</tikz>

La técnica de redirección es la misma que en IPv4. Un dispositivo sólo conoce los prefijos de las redes a las que está conectado directamente y la dirección de un enrutador por omisión. Si la ruta se puede optimizar, el enrutador por omisión envía un mensaje para indicar que existe un camino más corto. De hecho, como en IPv6 el enrutador por omisión se establece de forma automática, las rutas no necesariamente son las mejores (''cf'' figura ''Enrutamiento por omisión no óptimo'').

Otro caso particular en IPv6 ocurre con los dispositivos que se encuentran en el mismo enlace físico, pero tienen diferentes prefijos. La comunicación entre ellos pasa inicialmente a traves de enrutador por omisión hasta que éste notifica que existe una ruta directa entre ellos.

La figura ''Formato de los paquetes de indicación de redirección'' muestra el formato del mensaje:

* El campo dirección objetivo (''Target address'') contiene la dirección IPv6 del equipo hacia el que los paquetes deben ser enviados.
* El campo dirección destino contiene la dirección IPv6 del dispositivo que está siendo redirigido hacia la dirección objetivo.

Cuando la redirección apunta a un dispositivo situado en el mismo enlace, la dirección objetivo y de destino son las mismas.

Las opciones incluyen la dirección física de un nuevo enrutador y la cabecera del paquete redirigido.

Este mensaje se puede utilizar de la misma forma que en IPv4. Un dispositivo solamente tiene una ruta por omisión para acceder a equipos con un prefijo diferente. En consecuencia, envía su paquete al enrutador por omisión, quien observa que el prefijo destino es accesible a través de la misma subred que el emisor. El enrutador por omisión reenvía el paquete y notifica al emisor que puede contactar directamente a las máquinas que poseen el prefijo del destino.

IPv6 también utiliza este mensaje para optimizar la resolución fuera del enlace para el [[#Caso de redes NBMA |caso de redes NBMA]].

= Configuración automática =
Tradicionalmente, la configuración de una interfaz de red de una máquina se hacía manualmente. Esto suele ser un trabajo lento y propenso a errores. Con IPv6, se automatiza el proceso de configuración y se introducen, al mismo tiempo, mecanismos de funcionamiento inmediato (''plug and play'') a la interfaz de red. La configuración automática significa que un dispositivo obtendrá toda la información necesaria para su conexión a una red local IP sin ninguna intervención humana. En el caso ideal, cualquier usuario desempaca su nuevo equipo, lo conecta a la red local y lo ve funcionar sin tener que introducir la información propia de "especialistas". Ahora vamos a discutir otro aspecto de la configuración automática de IPv6, la auto-configuración de direcciones, que tiene como objetivos:

* La adquisición de una dirección cuando un dispositivo está conectado a una red por primera vez;
* la posibilidad de asignar otros prefijos, o de renumerar un dispositivo.

El proceso de configuración automática de direcciones IPv6 incluye la creación de una dirección local al enlace, la agregación a grupos multicast solicitados, la verificación de la unicidad de la dirección local al enlace y la creación de direcciones unicast global.

La tarea del enrutador es importante en la configuración automática. Indica a la máquina, mediante los bits de la cabecera (''cf'' [[#RA|anuncio de enrutador]]), del mensaje de anuncio de los enrutadores, el método a conservar y eventualmente proporcionar la información necesaria para su configuración. El bit <tt> M </tt> (''configuración de dirección administrada'') puesto a 1 indica que el equipo no debe crear por sí mismo una dirección a partir de su identificador de interfaz y de los prefijos recibidos, sino que debe solicitarla explícitamente ante un servidor de direcciones. El bit O <tt> </tt> (''otra configuración de estado'') indica que el dispositivo debe consultar el servidor para obtener otros parámetros distintos de la dirección. El algoritmo para el proceso de configuración automática de direcciones se desglosa de la siguiente manera:

* La primera fase consiste en crear la dirección local al enlace.
* Una vez que la unicidad de esta dirección es verificada, el dispositivo está listo para comunicarse con otras máquinas en el enlace.
* El dispositivo debe tratar de adquirir un mensaje de anuncio de enrutadores para determinar el método de obtención de la dirección unicast global.
* Si hay un enrutador en el enlace, el dispositivo debe aplicar el método especificado por el mensaje de anuncio de enrutadores, a saber:
** La configuración automática sin estado,
** la configuración automática con estado.
* Si no hay ningún enrutador en el enlace, el dispositivo debe tratar de obtener la dirección unicast global por el método de configuración automática con estado. Si el intento falla, no hay más que hacer. Las comunicaciones sólo podrán hacerse sobre el enlace con la dirección local al enlace, pues el dispositivo no tendrá una dirección con la cobertura necesaria que le permita comunicarse con otras máquinas fuera del enlace.

==Ciclo de vida de una dirección==

Al generalizar en IPv6 el plan de direccionamiento CIDR, los prefijos quedan, en todos los casos, siendo propiedad de los operadores. Ya no pueden otorgarse "a perpetuidad" a los dispositivos. Para facilitar la renumeración de una máquina, la asignación de una dirección a una interfaz es temporal, las direcciones IPv6 no se entregan, sino que se prestan. Se asocia un tiempo de vida a la dirección, que indica el tiempo durante el cual la dirección pertenece a la interfaz. Cuando el tiempo de vida se ha agotada, la dirección deja de ser válida, se suprime de la interfaz y queda potencialmente éste puede prolongarse indefinidamente. La dirección local al enlace tiene un tiempo de vida ilimitado.

<tikz title="Estados sucesivos de una dirección en una interfaz">

\draw [thick, ->] (0,2) -- (9.5,2);

\draw [->] (1,4) node [above=10pt] {\tiny{allocation}}-- (1,2);
\draw (1, 2) node [rectangle, minimum width=1cm, minimum height=1cm, fill, left color=black!10, right color=black!20, draw=black, above right] (tentative) {};
\draw (tentative.south east) node [rectangle, minimum width=3cm, minimum height=1cm, fill, left color=green, right color=green!50, draw=black, above right] (preferred) {};
\draw (preferred.south east) node [rectangle, minimum width=2cm, minimum height=1cm, fill, left color=orange , right color=orange!50!red, draw=black, above right] (deprecated) {};
\draw (deprecated.south east) node [rectangle, minimum width=2cm, minimum height=1cm, fill, color=red, draw=black, above right] (novalid) {};

\draw (tentative.text) node {\tiny{Tentative}};
\draw (preferred.text) node {\tiny{Preferred}};
\draw (deprecated.text) node {\tiny{Deprecated}};
\draw (novalid.text) node {\tiny{Invalid}};

\draw [dotted] (tentative.south west) -- +(0, -1);
\draw [dotted] (preferred.south west) -- +(0, -1);
\draw [dotted] (deprecated.south west) -- +(0, -1);
\draw [dotted] (novalid.south west) -- +(0, -1);

\draw [dashed, <->] ([yshift=-0.5cm]tentative.south west) -- node [above] {\tiny{DAD}} ([yshift=-0.5cm] preferred.south west) ;

\draw [dashed, <->] ([yshift=-0.5cm]preferred.south west) -- node [above] {\tiny{Valid}} ([yshift=-0.5cm] novalid.south west) ;

</tikz>

La renumeración de una interfaz consiste en pasar de una dirección a otra. Durante una renumeración, no es aconsejable cambiar repentinamente de dirección, de lo contrario, todas las comunicaciones TCP que la utilizan como identificador de conexión, se cortarían inmediatamente. Esto conllevaría importantes perturbaciones a nivel de las aplicaciones.

Por ello, para facilitar esta transición se implementó un mecanismo de obsolescencia que invalida gradualmente una dirección. Este mecanismo se sirve de la capacidad de asignación de varias direcciones válidas a una misma interfaz. Para elegir la dirección a utilizar, se le asocia un estado que indica en qué fase de su tiempo de vida se encuentra con respecto a la interfaz. El primero de esos estados se conoce como preferido: no hay ninguna restricción de uso. Poco antes de su invalidación, la dirección pasa a un estado de depreciado. En él se desaconseja el uso de la dirección, pero no está prohibido. Una dirección depreciada ya no debe ser utilizada como dirección fuente de nuevas comunicaciones (como el establecimiento de conexión TCP), pero todavía puede emplearse como dirección fuente de comunicaciones ya establecidas. Los paquetes recibidos a una dirección depreciada seguirán siendo entregados normalmente. El control de la duración de cada estad de una dirección válida se efectúa agregando un tiempo de vida al estado preferido.
La figura '''Estados sucesivos de una dirección en una interfaz''' representa los diferentes estados que toma una dirección cuando se asigna a una interfaz.

== Creación de la dirección local al enlace ==

<tikz title=" Creación de la dirección local al enlace">
\clip (0, 0) rectangle (10,7);
% \draw[help lines] (0,0) grid (10,7 );

\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,3)--(9,3);

\pgfputat{\pgfxy(0.8,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,5)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,3)--(1.5,5);
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (8,3)--(8,5);

\draw (1.5,4.5) node {\small{FE80::IID1}};
\draw (1.5,4) node {\small{$\alpha$::IID1/64}};

\draw (8, 4.5) node {\small{FE80::IID2}};

</tikz>

Durante la inicialización de la interfaz, el dispositivo construye un identificador de interfaz que debe ser único en el enlace. Este identificador se utiliza la dirección de [[ Identificador_de_interfaz#EUI-64 | EUI-64]]. El principio básico para crear la direcciónIPv6 consiste en unir un prefijo con el identificador. La dirección local al enlace se crea tomando el prefijo de Enlace_local (<tt>FE80::/64</tt>). La dirección creada de esa manera, todavía no puede ser utilizada; tiene un estado temporal pues el dispositivo debe comprobar la exclusividad de esta dirección en el enlace mediante el procedimiento de detección de direcciones duplicadas. Si se encuentra que la dirección local al enlace no es única, se suspende la autoconfiguración y será necesario proceder a una configuración manual.

Una vez que se ha asegurado la unicidad de la dirección local al enlace, ésta se considera una dirección válida para la interfaz, con lo que termina la prima fase del proceso de autoconfiguración.

==<div id="DAD"> Detección de una dirección duplicada </div>==

<tikz title="Emisión de un NS en una detección de Dir. duplicada (DAD)">
\clip (0, 0) rectangle (10,7);
% \draw[help lines] (0,0) grid (10,7 );

\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,3)--(9,3);

\pgfputat{\pgfxy(0.8,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,5)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,3)--(1.5,5);
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (8,3)--(8,5);

\draw (7.8, 5) -- (7.8, 3.2);
\draw [<->] (1, 3.2) -- node [above] {\tiny{::/0 -$>$ solicited (FE80:IID2) : NS (who has FE80::IID2?)}}(9, 3.2) ;

</tikz>

Para comprobar la exclusividad de direcciones locales al enlace o de direcciones unicast, los dispositivos deben ejecutar un algoritmo de detección de direcciones duplicadas (DAD) antes poder utilizarlas. El algoritmo usa los mensajes ICMPv6 [[Protocolo_de_Descubrimiento_de_vecinos#NS|solicitud de un vecino]] y [[#NA|anuncio de un vecino.]] Si se detecta una dirección que ya está en uso, ésta no podrá ser asignada a la interfaz, la autoconfiguración automática debe suspenderse y será necesario proceder a una configuración manual. Durante la ejecución del algoritmo DAD, la dirección es considerada como "provisional" hasta tener la confirmación de su unicidad. Una dirección provisional se asigna a una interfaz únicamente para recibir los mensajes de solicitud y anuncio de un vecino. Otros mensajes recibidos, son ignorados. El algoritmo DAD consiste en enviar un mensaje de solicitud de un vecino colocando en el campo de dirección objetivo la dirección provisional. Para distinguir el algoritmo DAD del de Descubrimiento de vecinos, el paquete IPv6 que contiene un mensaje de solicitud de un vecino tiene como dirección fuente una dirección no determinada. Así se presentan tres casos:

* Se recibe un mensaje de anucio de un vecino: Significa que la dirección provisional está siendo utilizada como válida por otro dispositivo, por lo que ésta no es única y no puede ser retenida por el dispositivo.
* Se recibe un mensaje de solicitud de un vecino como parte del algoritmo DAD. La dirección provisional también es provisional para otra máquina. En este caso, la dirección provisional no puede ser utilizada por ninguna de ellas.
* No se recibe ningún mensaje durante un segundo (valor por omisión). La dirección provisional es única, por lo que su estado pasa de provisional a válida y se le asigna a la interfaz.

Obsérvese que este algoritmo no proporciona una fiabilidad absoluta, especialmente cuando el enlace está segmentado.

== Autoconfiguración sin estado ==

<tikz title="Emisión de un RS">
\clip (0, 0) rectangle (10,7);
% \draw[help lines] (0,0) grid (10,7 );

\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,3)--(9,3);

\pgfputat{\pgfxy(0.8,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,5)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,3)--(1.5,5);
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (8,3)--(8,5);

\draw (7.8, 5) -- (7.8, 3.2);
\draw [<->] (1, 3.2) -- node [above] {\tiny{FE80::IID2 -$>$ FF02::2 : RS }} (9, 3.2) ;

</tikz>

La configuración automática sin estado (RFC 2462) no requiere de ninguna configuración manual de los dispositivos, una configuración mínima para los enrutadores, y tampoco necesita de servidores adicionales. Se sirve del protocolo ICMPv6 y puede operar aún sin la presencia de enrutadores. En cambio, sí requiere de una subred con soporte a la difusión de paquetes. Este método sólo aplica para los dispositivos; no puede ser utilizada para configurar enrutadores. El principio básico de este mecanismo consiste en que una máquina genera su dirección IPv6 a partir de información local y de la proporcionada por un enrutador. El enrutador proporciona información sobre la subred asociada al enlace; anuncia el prefijo.

<tikz title="Recepción de un RA">
\clip (0, 0) rectangle (10,7);
% \draw[help lines] (0,0) grid (10,7 );

\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,3)--(9,3);

\pgfputat{\pgfxy(0.8,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,5)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,3)--(1.5,5);
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (8,3)--(8,5);

\draw [->] (1.7,5) -- (1.7, 3.2) -- node [above = 10pt] {\tiny{FE80::IID1 -$>$ FE80::IID2}} node [above] {\tiny{RA ($\alpha$::/64, DHCPv6, MTU=1500, HL=64, {bit {\tt M=1}) }}} (7.8, 3.2) -- (7.8, 5);

</tikz>

Al igual que para la creación de la dirección de enlace local, la dirección unicast global se obtiene al concatenar el prefijo con el identificador de la interfaz. El prefijo se obtiene del mensaje de anuncio de enrutador, más concretamente, de la opción de ''información sobre el prefijo''. Si bien debe verificarse la unicidad de todas las direcciones unicast, en el caso de una dirección unicast obtenida mediante la configuración automática sin estado, esto no es obligatorio, pues la unicidad del identificador de la interfaz ya fue comprobada durante la configuración de la dirección local al enlace. Dado que el identificador es el mismo, no puede haber ambigüedad sobre la exclusividad de la dirección unicast global creada de esta forma.

La renumeración de los dispositivos en un enlace se realiza mediante enrutadores que transfieren las direcciones utilizadas a un estado depreciado y al mismo tiempo anuncian el nuevo prefijo con el que los dispositivos pueden re-crear una dirección preferida.

===Caso de redes NBMA ===

<tikz title="Off Link NDP: Primera etapa">
\clip (0, 0) rectangle (11,7);
% \draw[help lines] (0,0) grid (10,7 );

\pgfputat{\pgfxy(4.5,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}
\pgfputat{\pgfxy(1.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[decorate,decoration={zigzag}, color=black!60, ->, very thick] (8,3)-- node [above, color=black] {\tiny{FE80::IID2 -$>$ FF02::2 : RS}} (5,5);

</tikz>

Las redes NBMA (''Non Broadcast Multiple Access'') se caracterizan por no contar con un mecanismo de difusión hacia todos los dispositivos. Esto conduce a dos situiaciones posibles:
* ausencia total de difusión, como en las redes públicas (telefónica, ATM, …) en las que un solo destinatario puede ser contactado a la vez
* posibilidad de difusión por un número limitado de equipos, como es el caso de las redes de radio tipo 3G, WiMAX, en las que la estación base tiene la posibilidad de difundir datos hacia todos los equipos, pero esto no es posible en el sentido inverso (desde un dispositivo).

<tikz title="Off Link NDP: Segunda etapa">
\clip (0, 0) rectangle (11,7);
% \draw[help lines] (0,0) grid (10,7 );

\pgfputat{\pgfxy(4.5,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}
\pgfputat{\pgfxy(1.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[decorate,decoration={zigzag}, color=black!60, ->, very thick] (5, 5)-- node [above, color=black] {\tiny{RA ($\alpha$::/64, DHCPv6, OffLink, MTU=1500, HL=64, {bit {\tt M=1}})}} (8,3);

</tikz>

Un comportamiento de redes NBMA también puede ser deseable para limitar las restricciones de consumo energético. Por ejemplo, en el caso de redes de sensores, la difusión, o la difusión restringida (multicast) son costosas en consumo de energía pues todos los dispositivos deben procesar el mensaje y algunos deberán retransmitirlo.

<tikz title="Off Link NDP: Tercera etapa">
\clip (0, 0) rectangle (11,7);
% \draw[help lines] (0,0) grid (10,7 );

\pgfputat{\pgfxy(4.5,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}
\pgfputat{\pgfxy(1.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[decorate,decoration={zigzag}, color=black!60, ->, very thick] (8,3)-- node [left, near start, color=black] {\tiny{$\alpha$::IID2 -$>$ $\alpha$::IID3 : DATA}} (5,5);

\draw[decorate,decoration={zigzag}, color=black!60, ->, very thick] (5,5)-- node [left, midway, color=black] {\tiny{$\alpha$::IID2 -$>$ $\alpha$::IID3 : DATA}} (2,3);

</tikz>

Para estos casos, el protocolo de descubrimiento de vecinos cuenta con un modo NBMA llamado también ''OffLink'', el cual solamente autoriza el diálogo con un enrutador. Los intercambios comienzan de la misma forma:
* El dispositivo que desea insertarse en la red, emite un mensaje RS (''Router Sollicitation”) utilizando la dirección destino FF02::2 (todos los enrutadores sobre el enlace. La red NBMA deberá enviar este mensaje hacia un enrutador.
* El enrutador responde poniendo el bit <tt>L</tt> (OffLink) a 1 en la opción [[#información|Información sobre el prefijo]], indicando que todos los intercambios deben pasar por él.
* El dispositivo construye su dirección global concatenando el prefijo a su identificador de interfaz.
* El dispositivo envía sistemáticamente todos los paquetes a la dirección física del enrutador. Éste, que tiene una visión global de la red, los reenvía hacia el destinatario apropiado.

<tikz title="Off Link NDP: Cuarta etapa (opcional)">
\clip (0, 0) rectangle (11,7);
% \draw[help lines] (0,0) grid (10,7 );

\pgfputat{\pgfxy(4.5,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}
\pgfputat{\pgfxy(1.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[decorate,decoration={zigzag}, color=black!60, ->, very thick] (8,3)-- node [left, near end, color=black] {\tiny{$\alpha$::IID2 -$>$ $\alpha$::IID3 : DATA}} (5,5);

\draw[decorate,decoration={zigzag}, color=black!60, ->, very thick] (5,5)-- node [left, midway, color=black] {\tiny{$\alpha$::IID2 -$>$ $\alpha$::IID3 : DATA}} (2,3);

\draw[decorate,decoration={triangles}, color=black!60, ->, thick, ] (5,5) to [bend left] node [right, near start, color=black] {\tiny{REDIRECT $\alpha$::IID3 : MAC3}} (8,3);

\draw [color=black!60, ->, very thick, dotted] (8,3)-- node [above, midway, color=black] {\tiny{$\alpha$::IID2 -$>$ $\alpha$::IID3 : DATA}} (2,3);

</tikz>

* Si la tecnología del enlace lo permite y si la política de gestión de red lo autoriza, el enrutador tiene la posibilidad de optimizar el tráfico, notificando al dispositivo la verdadera dirección del destinatario, emitiendo un mensaje de [[#IR|indicación de redirección]] (''ICMP Redirect''). Los paquetes subsecuentes ya no pasarán por el enrutador.

{{eSuivi|Tabla de contenido|Incio del capítulo|DHCPv6|DHCPv6}}

Protocolo de Descubrimiento de vecinos

2012-07-05T18:55:11Z

Jincera: /* Caso de redes NBMA */

{{eSuivi|Tabla de contenido|Incio del capítulo|DHCPv6|DHCPv6}}

__TOC__

El protocolo de descubrimiento de vecinos (NDP, ''Neighbor Discovery Protocol'') permite a un dispositivo integrarse en el ambiente local, es decir, el enlace sobre el cual se transmiten físicamente los paquetes IPv6. Permite establecer un diálogo con los equipos (estaciones y enrutadores) conectados sobre el mismo medio. No se pretende que un dispositivo conozca con exactitud la lista de todos los demás dispositivos conectados al enlace, sino de proveer un mecanismo para dialogar con quien necesite hacerlo.

El protocolo utiliza cinco tipos de mensajes ICMPv6 (ver Valores de los campos de tipo y código de ICMPv6). El campo número de saltos de la cabecera IPv6 contiene el valor 255. Este valor parece demasiado grande para datagramas que no debieran ser enrutados fuera del enlace físico. En realidad, si un equipo recibe un datagrama con un valor menor, significa que la información proviene de otra red y que ya ha atravesado al menos un enrutador. Por ello, los datagramas que tienen un valor diferente de 255 deben ser ignorados por el receptor.

{{Tableau eICMPv6}}

El protocolo realiza varias funciones:

* Resolución de direcciones. El principio es muy similar al del protocolo ARP de IPv4. La principal diferencia consiste en el uso de mensajes ICMPv6 estándar en lugar de definir otro protocolo de capa 3. Con esto se consigue una mayor flexibilidad de uso, especialmente en las redes que no soportan la difusión de mensajes. Al igual que en IPv4, el protocolo se encarga de construir tablas de correspondencia entre las direcciones IPv6 y las físicas.
* <div vecinos id="NUD"> Detección de inaccesibilidad de vecinos (NUD, ''Neighbor Unreachability Detection''). Esta función, que no existe en IPv4, permite eliminar de las tablas de configuración de un equipo, los vecinos que se han vuelto inaccesibles (por fallas, cambio de domicilio, ...). Si un enrutador deja de estar disponible, la tabla de enrutamiento puede ser modificada para considerar otra ruta. </div>
* Configuración. La configuración automática de los dispositivos es uno de los principales atractivos de IPv6. Se implementan varias funcionalidades del protocolo de descubrimiento de vecinos:
**Descubrimiento de enrutadores. Este protocolo permite que los dispositivos identifiquen a los enrutadores que se encuentran en su enlace físico. En IPv4, esta función la proporciona el protocolo ''ICMP Router Discovery''.
** Descubrimiento de prefijos. El dispositivo conoce el o los prefijos de red de acuerdo a los anuncios realizados por los enrutadores. Agregando su identificador de interfaz, el dispositivo construye su o sus direcciones IPv6. No hay un mecanismo equivalente para las direcciones IPv4 ya que son demasiado cortas para realizar la auto-configuración.
** Detección de direcciones duplicadas. Dado que las direcciones se configuran de forma automática, existen riesgos de error en caso de tener equipos con identificadores repetidos. Este protocolo verifica que ningún otro equipo en el enlace tiene la misma dirección IPv6. Esta función es una evolución del ARP gratuito en IPv4 emitido durante la inicialización de la interfaz.
** Descubrimiento de parámetros. Este protocolo permite que los dispositivos conozcan los distintos parámetros del enlace físico, por ejemplo, el tamaño de MTU, el número máximo de saltos permitido (valor original del campo número de saltos), si la configuración automática con estado (como [[Configuración con estado: DHCPv6|DHCPv6]]) está activa, etc. No existe un equivalente de esta funcionalidad en IPv4.
* Indicación de redirección. Este mensaje se utiliza cuando un enrutador conoce una trayectoria mejor (medida en número de saltos) para alcanzar un destino.
:En IPv4 una indicación de redireccionamiento sólo puede servir para corregir la dirección del enrutador utilizado para acceder a una máquina fuera de la red local. Los dispositivos deben conocer todas las direcciones correspondientes a equipos conectados en su propia red local.
:EnIPv6, la correspondencia entre prefijo y red local es menos rígida. Es de esperar que un dispositivo no conozca todos los prefijos de su red local (si ésta es compartida por varios prefijos), o que un prefijo se comparta entre varios enlaces (lo que corresponde a una generalización del modelo de redes lógicas IP sobre ATM). Bajo algunas configuraciones, la máquina emitirá sus paquetes al enrutador aún si el destinatario se encuentra en el mismo segmento que el emisor. En este caso, el enrutador emitirá un mensaje de redirección para que la continuación del diálogo entre ellos haga de manera directa (véanse los ejemplos [[#IR|Indicación redirección]]).
:En el caso más extremo, podría imaginarse en IPv6 que un dispositivo puede ser configurado para comunicarse únicamente con su enrutador por omisión. ICMPv6 ''redirect'' puede utilizarse entonces, para informar al dispositivo de destinatarios ubicados en el mismo enlace.

En IPv6 se especifican dos métodos de autoconfiguración para las direcciones unicast global:

* Autoconfiguración sin estado (''stateless autoconfiguration'', RFC 2462). Se utiliza cuando no es necesaria una gestión administrativa de las direcciones asignadas dentro de un sitio. Estos mecanismos se describen más adelante en este capítulo.
* Autoconfiguración con estado (''statefull autoconfiguration''). Se utiliza cuando un sitio requiere de un control estricto de la asignación de direcciones (''cf'' [[Configuración con estado: DHCPv6 | DHCPv6]]).

Sin embargo, el uso de DHCPv6 para obtener la dirección se controla mediante el protocolo de descubrimiento de vecinos.

= Datos transmitidos por los mensajes =

La principal motivación detrás del Protocolo de Descubrimiento de vecinos es unificar varios protocolos existentes en IPv4. En particular, la mayor parte de los datos utiliza un formato de opciones común, lo que simplifica la implementación del protocolo. El formato contiene los campos: tipo, longitud (en palabras de 64 bits), y datos. La baja precisión de campo longitud, presentará un desperdicio de espacio, pero permite una alineación de las opciones en palabras de 64 bits, lo que permite un procesamiento optimizado.

{{NB-Opciones}}

== <div id="física">Dirección física de la fuente/destino</div> ==

<tikz title="Formato de la opción dirección física fuente/destino">
\clip (0.2, 5.7) rectangle (11.1,6.7);
% \draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=1/2}};
\draw (2.9, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{lenght }};
\draw (5.3, 6) node (addr) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Link Layer Address}};

\draw [draw=white, thick] (addr.north east) -- (addr.south east);
\draw [draw=white, thick] (addr.north east) -- +(-2, 0);
\draw [draw=white, thick] (addr.south east) -- +(-2, 0);

\draw [dashed] (addr.north east) -- (addr.south east);
\draw [dashed] (addr.north east) -- +(-2, 0);
\draw [dashed] (addr.south east) -- +(-2, 0);
</tikz>

La figura ''Formato de la opción dirección física fuente/destino'' presenta estas opciones. El tipo 1 designa la dirección física de la fuente y el tipo 2 la dirección del destino.

El campo ''length'' es el tamaño en palabras de 64 bits de la opción. Por lo tanto, para el caso de una dirección MAC con longitud de 6 octetos, contiene el valor 1.

El RFC 2464 define el formato para las direcciones MAC-48 utilizadas en las redes Ethernet y Wi-Fi. El RFC 4944 define el formato para las direcciones MAC-16 y MAC-64 utilizadas en las redes de sensores bajo la norma IEEE 802.15.4.

== <div id="información">Información sobre el prefijo</div> ==

<tikz title="Formato de la opción información sobre el prefijo">
\clip (0.2, 2) rectangle (11.1, 7);
% \draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=3}};
\draw (2.9, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{length =4 }};
\draw (5.3, 6) node (addr) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm] {\tiny{Prefix Length}};
\draw (7.7, 6) node (bitL) [right, shade, top color=blue!15, bottom color=blue!5,, draw, minimum height=0.5cm, minimum width=.3cm]{}; \draw (bitL.text) node {\tiny{L}};
\draw (8, 6) node (bitA) [right, shade, top color=blue!15, bottom color=blue!5,, draw, minimum height=0.5cm, minimum width=.3cm]{};\draw (bitA.text) node {\tiny{A}};
\draw (8.3, 6) node (bitR) [right, shade, top color=blue!15, bottom color=blue!5,, draw, minimum height=0.5cm, minimum width=.3cm]{};\draw (bitR.text) node {\tiny{R}};
\draw (8.6, 6) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=1.5cm] {\tiny{Reserved}};

\draw (0.5, 5.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Valid Lifetime}};

\draw (0.5, 5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Prefered Lifetime}};

\draw (0.5, 4.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Reserved}};

\draw (0.5, 4) node (addr1) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{}};
\draw (0.5, 3.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{}};
\draw (0.5, 3) node (addr3) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Prefix}};
\draw (0.5, 2.5) node (addr4) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{}};

\draw [color=blue!10, very thick] (addr1.south east) -- (addr1.south west);
\draw [color=blue!10, very thick] (addr2.south east) -- (addr2.south west);
\draw [color=blue!10, very thick] (addr3.south east) -- (addr3.south west);
</tikz>

Esta opción contiene las informaciones sobre el prefijo para permitir una configuración automática de los dispositivos. El campo tipo tiene el valor 3 y el de longitud, 4. La figura ''Formato de la opción información sobre el prefijo'' muestra el formato de esta opción:

* El campo ''Prefix lenght'' indica cuántos bits son significativos para el prefijo anunciado en un campo siguiente.
* El bit <tt>L</tt> indica, cuando vale 1, que el prefijo permite indicar que todos los demás dispositivos que comparten el mismo prefijo, están en el mismo enlace, por lo que el emisor puede contactarlos directamente. En caso contrario, el dispositivo envía el paquete hacia el enrutador. Si éste último sabe que el emisor puede contactar directamente al destinatario, emitirá un mensaje ICMPv6 de indicación de redirección.
* El bit <tt>A</tt> indica, cuando vale 1, que el prefijo anunciado puede utilizarse para formar la dirección del dispositivo.
* El bit <tt>R</tt>, indica, cuando vale 1, que el campo prefijo contiene la dirección global de un enrutador ''agente base''. Los bits de mayor peso aún pueden utilizarse para formar un prefijo.
* El campo duración de validez indica, en segundos, la duración durante la cual el prefijo es válido.
* El campo duración preferente indica la duración, en segundos, durante la cual una dirección formada con el protocolo de configuración sin estado se mantiene ''preferente'' (''cf'' [[Planes de direccionamiento|Tiempo de vida de las direcciones]]).

Para estos dos campos, un valor de <tt>0xffffffff</tt> representa una duración infinita. Estos campos pueden servir durante la fase de transición de un proveedor de acceso a otro; es decir, de un prefijo a otro.
* El campo reservado permite alinear el prefijo a una frontera de palabra de 64 bits.
* El campo prefijo contiene el valor de prefijo anunciado sobre el enlace. Para mantener una alineación de 64 bits para el resto de datos del paquete, este campo tiene una longitud fija de 128 bits.

== <div id="redirigida">Cabecera de redirección </div> ==

<tikz title="Formato de la opción cabecera de redirección">
\clip (0.2, 3.1) rectangle (11.1, 7);
% \draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=5}};
\draw (2.9, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{length =1 }};
\draw (5.3, 6) node (addr) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Reserved}};

\draw (0.5, 5.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Reserved}};

\draw (0.5, 4.25) node (context) [right, shade, top color=purple!50, bottom color=purple!10, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{IPv6 Header and Data}};
</tikz>

Esta opción es utilizada por el mensaje de indicación de redirección. Permite encapsular los primeros octetos del paquete IPv6 que provocó la emisión de este mensaje, como ocurre con los mensajes de error de ICMPv6.

El campo tipo tiene el valor 4. El tamaño de esta opción debe evitar que el paquete IPv6 rebase los 1280 octetos (''cf'' figura ''Formato de la opción cabecera de redirección''). Sin embargo, el paquete debe contener la mayor cantidad de información posible.

== <div id="MTU">MTU</div> ==

<tikz title="Formato de la opción MTU">

\clip (0.2, 5.1) rectangle (11.1, 7);
% \draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=5}};
\draw (2.9, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{lenght =1 }};
\draw (5.3, 6) node (addr) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Reserved}};

\draw (0.5, 5.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{MTU}};
</tikz>

Esta opción permite notificar a los dispositivos el tamaño máximo de datos que pueden ser transmitidos sobre el enlace. La figura ''Formato de la opción MTU'' muestra su estructura. No es necesario difundir esta información si el dispositivo utiliza siempre el tamaño máximo permitido. Por ejemplo, sobre las redes Ethernet, los dispositivos utilizarán el valor 1,500. En cambio, en las redes Token Ring o FDDI, con frecuencia es necesario especificar si los equipos pueden utilizar la longitud máxima o un tamaño inferior para permitir el uso de puentes en la red.

En esta opción, el campo tipo tiene un valor de 5 y el de longitud, de 1.

=Mensajes estándar de Descubrimiento de vecinos =

Además de las cinco opciones básicas descritas en la tabla ''Utilización de las opciones en los mensajes de descubrimiento de vecinos'', existen otras específicas para la movilidad y para las redes NBMA (''Non Broadcast Multiple Access'').

{|
|+ Utilización de las opciones en los mensajes de descubrimiento de vecinos
| width = 150 | || width = 100 |[[#RS|Solicitud de]] || width = 100 |[[#RA|Anuncio de]] || width = 100 |[[#NS|Solicitud de]] ||width = 100 | [[#NA|Anuncio de]] ||width = 100 |[[#IR|Indicación de]]
|-
| || [[#RS|enrutador]] || [[#RA|enrutador]] || [[#NS|un vecino]] || [[#NA| un vecino]] || [[#IR|redirección]]
|-style="background:silver"
|[[#física |Dirección física de la fuente]] || presente || presente || presente || ||
|-
|[[# física | Dirección física del destino]] || || || || presente || presente
|-style="background:silver"
|[[#información|Información sobre el prefijo]] || || ≥ 1 || || ||
|-
|[[#redirigida |Cabecera de redirección]] || || || || || presente
|-style="background:silver"
| [[#MTU |MTU]] || || posible || || ||
|}

Las distintas funcionalidades de descubrimiento de vecinos utilizan cinco mensajes: dos para el diálogo entre un dispositivo y un enrutador, dos para el diálogo entre vecinos, y uno para la redirección. Cada uno de estos mensajes puede incluir opciones adicionales.

== <div id="RS">Solicitud de enrutador</div> ==

<tikz title="Formato de los paquetes de solicitud de enrutador">
\clip (0.2, 3.5) rectangle (11.1,7.1);
%\draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=133}};
\draw (2.9, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code =0 }};
\draw (5.3, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};
\draw (0.5, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Reserved}};

\draw (0.5, 4.25) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Options:\\
- Source link-layer address
}};
</tikz>

El mensaje de solicitud de enrutador (''cf'' figura Formato de los paquetes de solicitud de enrutador) es emitido al iniciar un dispositivo para recibir más rápidamente la información del enrutador. Este mensaje se envía a la dirección IPv6 multicast reservada a los enrutadores en el mismo enlace <tt>FF02::2</tt>. Si el dispositivo aún no conoce su dirección fuente, se utiliza la dirección no especificada.

El campo opción normalmente contiene la dirección física del dispositivo.

== <div id="RA">Anuncio de enrutador</div> ==

<tikz title="Formato de los paquetes de anuncio de enrutador">
\clip (0.2, 1.5) rectangle (11.1,7.1);
%\draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=134}};
\draw (2.9, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code =0 }};
\draw (5.3, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};

\draw (0.5, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Cur. Hop Lim.}};
\draw (2.9, 5.5) node (bitM) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{}; \draw (bitM.text) node {\tiny{M}};
\draw (3.2, 5.5) node (bitO) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{};\draw (bitO.text) node {\tiny{O}};
\draw (3.5, 5.5) node (bitH) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{};\draw (bitH.text) node {\tiny{H}};
\draw (3.8, 5.5) node (res) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=1.5cm]{\tiny{reserved}};
\draw (5.3, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Router Lifetime}};

\draw (0.5, 5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=9.6cm]{\tiny{Reachable Time}};
\draw (0.5, 4.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=9.6cm]{\tiny{Retrans Time}};

\draw (0.5, 3.25) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Options:\\
Source link-layer address\\
MTU\\
Prefix Information (may be repeated)\\
}};
</tikz>

Este mensaje (''cf'' figura ''Formato de los paquetes de anuncio de enrutador'') es emitido periódicamente por los enrutadores, o bien, en respuesta a un mensaje de solicitud de enrutador generado por un dispositivo. El campo dirección fuente contiene la dirección de enlace local del enrutador, mientras que el campo dirección destino contiene la dirección del dispositivo que generó la solicitud, o la dirección de todas las estaciones (<tt>ff02::01</tt>).

Cuando el campo de máximo número de saltos tiene un valor distinto de cero, muestra el valor que podría colocarse en el campo de número de saltos de los paquetes emitidos. El bit <tt>M</tt> indica que una dirección del dispositivo debe ser obtenida mediante un protocolo de configuración (''cf'' [[Configuración con estado:DHCPv6]]). El bit <tt>O</tt> también indica la presencia de un servicio de configuración para obtener información adicional a la dirección. Si no es posible obtener la dirección mediante un servidor, el dispositivo procede a realizar una configuración sin estado, concatenando su identificador de interfaz a los prefijos que conoce. El bit <tt>H</tt> indica que el enrutador puede ser utilizado como agente base por un nodo móvil (''cf'' [[Desplazamientos_de_móviles#Anuncio_del_agente_base |Anuncio del agente base]]).

El campo tiempo de vida del enrutador indica el período (en segundos) durante el cual el equipo que emite el anuncio realizará funciones de enrutador por omisión. El valor máximo corresponde a 18 horas 12 minutos, pero como este mensaje se emite periódicamente, en la práctica no existe un límite para el tiempo de vida de un enrutador. Un valor de <tt>0</tt> indica que el dispositivo no cumple con las funciones de enrutador por omisión. Este tiempo de vida no se aplica a las opciones transportadas por este mensaje.

El campo duración de accesibilidad indica el período (en milisegundos) durante el cual una información almacenada en la memoria caché de la máquina (por ejemplo, la tabla de correspondencia entre las direcciones IPv6 y las físicas) puede ser considerada como válida. Al vencimiento de este tiempo, se emite un mensaje de detección de inaccesibilidad para verificar la pertinencia de la información almacenada.

El campo temporización de retransmisión muestra el período (en milisegundos) entre dos emisiones no solicitadas de este mensaje. Permite que los demás equipos puedan detectar la inaccesibilidad de un enrutador.

Este mensaje puede transportar las siguientes opciones:

* dirección física de la fuente,
* MTU,
* información sobre el prefijo (uno o varios).

== <div Id="NS"> Solicitud de un vecino </div> ==

<tikz title="Formato de los paquetes de solicitud de un vecino">

\clip (0.2, 1.5) rectangle (11.1,7.1);
%\draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=135}};
\draw (2.9, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code =0 }};
\draw (5.3, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};

\draw (0.5, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=9.6cm]{\tiny{Reserved}};

\draw (0.5, 4.25) node (context) [right, shade, top color=blue!50, bottom color=blue=!10, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Target Address}};

\draw (0.5, 2.25) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Options:\\
Source link-layer address\\
}};
</tikz>

Este mensaje (''cf'' figura ''Formato de los paquetes de solicitud de un vecino'') permite obtener información a partir de un equipo vecino, es decir, localizado en el mismo enlace físico (o conectado a través de puentes). El mensaje puede ser emitido explícitamente a él, o enviado con una dirección de difusión. En el caso de determinación de la dirección física, éste corresponde a la solicitud de ARP en IPv4.

El campo dirección fuente del paquete IPv6 contiene ya sea la dirección local al enlace, una dirección global o la dirección no especificada. El campo destino puede contener la dirección de difusión múltiple solicitada correspondiente a la dirección buscada (''cf'' [[Direccionamiento_multicast#Identificador_de_grupo|Identificador de grupo]]) o la dirección del dispositivo (en el caso de una detección de inaccesibilidad de vecinos, ''NUD'').

El campo dirección del destino contiene la dirección IPv6 del equipo buscado. El campo opción generalmente contiene la dirección física de la fuente.

== <div Id="NA"> Anuncio de un vecino</div> ==

<tikz title="Formato de los paquetes de anuncio de un vecino">

\clip (0.2, 1.5) rectangle (11.1,7.1);
%\draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=136}};
\draw (2.9, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code =0 }};
\draw (5.3, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};

\draw (0.5, 5.5) node (bitR) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{}; \draw (bitR.text) node {\tiny{R}};
\draw (0.8, 5.5) node (bitS) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{}; \draw (bitS.text) node {\tiny{S}};
\draw (1.1, 5.5) node (bitO) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{}; \draw (bitO.text) node {\tiny{O}};
\draw (1.4, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=8.7cm]{\tiny{Reserved}};

\draw (0.5, 4.25) node (context) [right, shade, top color=blue!50, bottom color=blue=!10, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Target Address}};

\draw (0.5, 2.25) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Options:\\
Source link-layer address\\
}};
</tikz>

Este mensaje (''cf'' figura ''Formato de los paquetes de anuncio de un vecino'') se emite en respuesta a una solicitud, aunque también puede ser emitido de forma espontánea para propagar la información de cambio de dirección física, o del estado de "enrutador". Para el caso de la determinación de la dirección física, es equivalente a la respuesta ARP en IPv4.

* El bit <tt> R </tt> se pone a 1 si el remitente es un enrutador. Este bit se utiliza para permitir la detección de un enrutador que se convierte en un equipo ordinario.
* El bit <tt> S </tt> en 1 indica que este anuncio se emite en respuesta a una solicitud.
* El bit <tt> O </tt> en 1 indica que este anuncio debe borrar las informaciones anteriores que se encuentran almacenadas en la memoria cachés de otros equipos, en especial la tabla que contiene las direcciones físicas.
* El campo dirección del destino contiene, si el bit<tt> S </tt> es 1, el valor del campo dirección del destino de la solicitud a la que está respondiendo este mensaje. Si el bit <tt> S </tt> es 0, este campo contiene la dirección IPv6 local al enlace del equipo emisor.
* La opción dirección física del destino contiene la dirección física del emisor.

== <div id="IR">Indicación de redirección</div> ==

<tikz title="Formato de los paquetes de indicación de redirección">
\clip (0.2, 0) rectangle (11.1,7.1);
%\draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=137}};
\draw (2.9, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code =0 }};
\draw (5.3, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};

\draw (0.5, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=9.6cm]{\tiny{Reserved}};

\draw (0.5, 4.25) node (context) [right, shade, top color=blue!50, bottom color=blue=!10, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Target Address}};

\draw (0.5, 2.25) node (context) [right, shade, top color=blue!50, bottom color=blue=!10, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Destination Address}};

\draw (0.5, 0.5) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=1.5cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Options:\\
Target link-layer address\\
Redirected Header\\
}};
</tikz>

La técnica de redirección es la misma que en IPv4. Un dispositivo sólo conoce los prefijos de las redes a las que está conectado directamente y la dirección de un enrutador por omisión. Si la ruta se puede optimizar, el enrutador por omisión envía un mensaje para indicar que existe un camino más corto. De hecho, como en IPv6 el enrutador por omisión se establece de forma automática, las rutas no necesariamente son las mejores (''cf'' figura ''Enrutamiento por omisión no óptimo'').

Otro caso particular en IPv6 ocurre con los dispositivos que se encuentran en el mismo enlace físico, pero tienen diferentes prefijos. La comunicación entre ellos pasa inicialmente a traves de enrutador por omisión hasta que éste notifica que existe una ruta directa entre ellos.

La figura ''Formato de los paquetes de indicación de redirección'' muestra el formato del mensaje:

* El campo dirección objetivo (''Target address'') contiene la dirección IPv6 del equipo hacia el que los paquetes deben ser enviados.
* El campo dirección destino contiene la dirección IPv6 del dispositivo que está siendo redirigido hacia la dirección objetivo.

Cuando la redirección apunta a un dispositivo situado en el mismo enlace, la dirección objetivo y de destino son las mismas.

Las opciones incluyen la dirección física de un nuevo enrutador y la cabecera del paquete redirigido.

Este mensaje se puede utilizar de la misma forma que en IPv4. Un dispositivo solamente tiene una ruta por omisión para acceder a equipos con un prefijo diferente. En consecuencia, envía su paquete al enrutador por omisión, quien observa que el prefijo destino es accesible a través de la misma subred que el emisor. El enrutador por omisión reenvía el paquete y notifica al emisor que puede contactar directamente a las máquinas que poseen el prefijo del destino.

IPv6 también utiliza este mensaje para optimizar la resolución fuera del enlace para el [[#Caso de redes NBMA |caso de redes NBMA]].

= Configuración automática =
Tradicionalmente, la configuración de una interfaz de red de una máquina se hacía manualmente. Esto suele ser un trabajo lento y propenso a errores. Con IPv6, se automatiza el proceso de configuración y se introducen, al mismo tiempo, mecanismos de funcionamiento inmediato (''plug and play'') a la interfaz de red. La configuración automática significa que un dispositivo obtendrá toda la información necesaria para su conexión a una red local IP sin ninguna intervención humana. En el caso ideal, cualquier usuario desempaca su nuevo equipo, lo conecta a la red local y lo ve funcionar sin tener que introducir la información propia de "especialistas". Ahora vamos a discutir otro aspecto de la configuración automática de IPv6, la auto-configuración de direcciones, que tiene como objetivos:

* La adquisición de una dirección cuando un dispositivo está conectado a una red por primera vez;
* la posibilidad de asignar otros prefijos, o de renumerar un dispositivo.

El proceso de configuración automática de direcciones IPv6 incluye la creación de una dirección local al enlace, la agregación a grupos multicast solicitados, la verificación de la unicidad de la dirección local al enlace y la creación de direcciones unicast global.

La tarea del enrutador es importante en la configuración automática. Indica a la máquina, mediante los bits de la cabecera (''cf'' [[#RA|anuncio de enrutador]]), del mensaje de anuncio de los enrutadores, el método a conservar y eventualmente proporcionar la información necesaria para su configuración. El bit <tt> M </tt> (''configuración de dirección administrada'') puesto a 1 indica que el equipo no debe crear por sí mismo una dirección a partir de su identificador de interfaz y de los prefijos recibidos, sino que debe solicitarla explícitamente ante un servidor de direcciones. El bit O <tt> </tt> (''otra configuración de estado'') indica que el dispositivo debe consultar el servidor para obtener otros parámetros distintos de la dirección. El algoritmo para el proceso de configuración automática de direcciones se desglosa de la siguiente manera:

* La primera fase consiste en crear la dirección local al enlace.
* Una vez que la unicidad de esta dirección es verificada, el dispositivo está listo para comunicarse con otras máquinas en el enlace.
* El dispositivo debe tratar de adquirir un mensaje de anuncio de enrutadores para determinar el método de obtención de la dirección unicast global.
* Si hay un enrutador en el enlace, el dispositivo debe aplicar el método especificado por el mensaje de anuncio de enrutadores, a saber:
** La configuración automática sin estado,
** la configuración automática con estado.
* Si no hay ningún enrutador en el enlace, el dispositivo debe tratar de obtener la dirección unicast global por el método de configuración automática con estado. Si el intento falla, no hay más que hacer. Las comunicaciones sólo podrán hacerse sobre el enlace con la dirección local al enlace, pues el dispositivo no tendrá una dirección con la cobertura necesaria que le permita comunicarse con otras máquinas fuera del enlace.

==Ciclo de vida de una dirección==

Al generalizar en IPv6 el plan de direccionamiento CIDR, los prefijos quedan, en todos los casos, siendo propiedad de los operadores. Ya no pueden otorgarse "a perpetuidad" a los dispositivos. Para facilitar la renumeración de una máquina, la asignación de una dirección a una interfaz es temporal, las direcciones IPv6 no se entregan, sino que se prestan. Se asocia un tiempo de vida a la dirección, que indica el tiempo durante el cual la dirección pertenece a la interfaz. Cuando el tiempo de vida se ha agotada, la dirección deja de ser válida, se suprime de la interfaz y queda potencialmente éste puede prolongarse indefinidamente. La dirección local al enlace tiene un tiempo de vida ilimitado.

<tikz title="Estados sucesivos de una dirección en una interfaz">

\draw [thick, ->] (0,2) -- (9.5,2);

\draw [->] (1,4) node [above=10pt] {\tiny{allocation}}-- (1,2);
\draw (1, 2) node [rectangle, minimum width=1cm, minimum height=1cm, fill, left color=black!10, right color=black!20, draw=black, above right] (tentative) {};
\draw (tentative.south east) node [rectangle, minimum width=3cm, minimum height=1cm, fill, left color=green, right color=green!50, draw=black, above right] (preferred) {};
\draw (preferred.south east) node [rectangle, minimum width=2cm, minimum height=1cm, fill, left color=orange , right color=orange!50!red, draw=black, above right] (deprecated) {};
\draw (deprecated.south east) node [rectangle, minimum width=2cm, minimum height=1cm, fill, color=red, draw=black, above right] (novalid) {};

\draw (tentative.text) node {\tiny{Tentative}};
\draw (preferred.text) node {\tiny{Preferred}};
\draw (deprecated.text) node {\tiny{Deprecated}};
\draw (novalid.text) node {\tiny{Invalid}};

\draw [dotted] (tentative.south west) -- +(0, -1);
\draw [dotted] (preferred.south west) -- +(0, -1);
\draw [dotted] (deprecated.south west) -- +(0, -1);
\draw [dotted] (novalid.south west) -- +(0, -1);

\draw [dashed, <->] ([yshift=-0.5cm]tentative.south west) -- node [above] {\tiny{DAD}} ([yshift=-0.5cm] preferred.south west) ;

\draw [dashed, <->] ([yshift=-0.5cm]preferred.south west) -- node [above] {\tiny{Valid}} ([yshift=-0.5cm] novalid.south west) ;

</tikz>

La renumeración de una interfaz consiste en pasar de una dirección a otra. Durante una renumeración, no es aconsejable cambiar repentinamente de dirección, de lo contrario, todas las comunicaciones TCP que la utilizan como identificador de conexión, se cortarían inmediatamente. Esto conllevaría importantes perturbaciones a nivel de las aplicaciones.

Por ello, para facilitar esta transición se implementó un mecanismo de obsolescencia que invalida gradualmente una dirección. Este mecanismo se sirve de la capacidad de asignación de varias direcciones válidas a una misma interfaz. Para elegir la dirección a utilizar, se le asocia un estado que indica en qué fase de su tiempo de vida se encuentra con respecto a la interfaz. El primero de esos estados se conoce como preferido: no hay ninguna restricción de uso. Poco antes de su invalidación, la dirección pasa a un estado de depreciado. En él se desaconseja el uso de la dirección, pero no está prohibido. Una dirección depreciada ya no debe ser utilizada como dirección fuente de nuevas comunicaciones (como el establecimiento de conexión TCP), pero todavía puede emplearse como dirección fuente de comunicaciones ya establecidas. Los paquetes recibidos a una dirección depreciada seguirán siendo entregados normalmente. El control de la duración de cada estad de una dirección válida se efectúa agregando un tiempo de vida al estado preferido.
La figura '''Estados sucesivos de una dirección en una interfaz''' representa los diferentes estados que toma una dirección cuando se asigna a una interfaz.

== Creación de la dirección local al enlace ==

<tikz title=" Creación de la dirección local al enlace">
\clip (0, 0) rectangle (10,7);
% \draw[help lines] (0,0) grid (10,7 );

\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,3)--(9,3);

\pgfputat{\pgfxy(0.8,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,5)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,3)--(1.5,5);
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (8,3)--(8,5);

\draw (1.5,4.5) node {\small{FE80::IID1}};
\draw (1.5,4) node {\small{$\alpha$::IID1/64}};

\draw (8, 4.5) node {\small{FE80::IID2}};

</tikz>

Durante la inicialización de la interfaz, el dispositivo construye un identificador de interfaz que debe ser único en el enlace. Este identificador se utiliza la dirección de [[ Identificador_de_interfaz#EUI-64 | EUI-64]]. El principio básico para crear la direcciónIPv6 consiste en unir un prefijo con el identificador. La dirección local al enlace se crea tomando el prefijo de Enlace_local (<tt>FE80::/64</tt>). La dirección creada de esa manera, todavía no puede ser utilizada; tiene un estado temporal pues el dispositivo debe comprobar la exclusividad de esta dirección en el enlace mediante el procedimiento de detección de direcciones duplicadas. Si se encuentra que la dirección local al enlace no es única, se suspende la autoconfiguración y será necesario proceder a una configuración manual.

Una vez que se ha asegurado la unicidad de la dirección local al enlace, ésta se considera una dirección válida para la interfaz, con lo que termina la prima fase del proceso de autoconfiguración.

==<div id="DAD"> Detección de una dirección duplicada </div>==

<tikz title="Emisión de un NS en una detección de Dir. duplicada (DAD)">
\clip (0, 0) rectangle (10,7);
% \draw[help lines] (0,0) grid (10,7 );

\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,3)--(9,3);

\pgfputat{\pgfxy(0.8,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,5)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,3)--(1.5,5);
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (8,3)--(8,5);

\draw (7.8, 5) -- (7.8, 3.2);
\draw [<->] (1, 3.2) -- node [above] {\tiny{::/0 -$>$ solicited (FE80:IID2) : NS (who has FE80::IID2?)}}(9, 3.2) ;

</tikz>

Para comprobar la exclusividad de direcciones locales al enlace o de direcciones unicast, los dispositivos deben ejecutar un algoritmo de detección de direcciones duplicadas (DAD) antes poder utilizarlas. El algoritmo usa los mensajes ICMPv6 [[Protocolo_de_Descubrimiento_de_vecinos#NS|solicitud de un vecino]] y [[#NA|anuncio de un vecino.]] Si se detecta una dirección que ya está en uso, ésta no podrá ser asignada a la interfaz, la autoconfiguración automática debe suspenderse y será necesario proceder a una configuración manual. Durante la ejecución del algoritmo DAD, la dirección es considerada como "provisional" hasta tener la confirmación de su unicidad. Una dirección provisional se asigna a una interfaz únicamente para recibir los mensajes de solicitud y anuncio de un vecino. Otros mensajes recibidos, son ignorados. El algoritmo DAD consiste en enviar un mensaje de solicitud de un vecino colocando en el campo de dirección objetivo la dirección provisional. Para distinguir el algoritmo DAD del de Descubrimiento de vecinos, el paquete IPv6 que contiene un mensaje de solicitud de un vecino tiene como dirección fuente una dirección no determinada. Así se presentan tres casos:

* Se recibe un mensaje de anucio de un vecino: Significa que la dirección provisional está siendo utilizada como válida por otro dispositivo, por lo que ésta no es única y no puede ser retenida por el dispositivo.
* Se recibe un mensaje de solicitud de un vecino como parte del algoritmo DAD. La dirección provisional también es provisional para otra máquina. En este caso, la dirección provisional no puede ser utilizada por ninguna de ellas.
* No se recibe ningún mensaje durante un segundo (valor por omisión). La dirección provisional es única, por lo que su estado pasa de provisional a válida y se le asigna a la interfaz.

Obsérvese que este algoritmo no proporciona una fiabilidad absoluta, especialmente cuando el enlace está segmentado.

== Autoconfiguración sin estado ==

<tikz title="Emisión de un RS">
\clip (0, 0) rectangle (10,7);
% \draw[help lines] (0,0) grid (10,7 );

\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,3)--(9,3);

\pgfputat{\pgfxy(0.8,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,5)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,3)--(1.5,5);
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (8,3)--(8,5);

\draw (7.8, 5) -- (7.8, 3.2);
\draw [<->] (1, 3.2) -- node [above] {\tiny{FE80::IID2 -$>$ FF02::2 : RS }} (9, 3.2) ;

</tikz>

La configuración automática sin estado (RFC 2462) no requiere de ninguna configuración manual de los dispositivos, una configuración mínima para los enrutadores, y tampoco necesita de servidores adicionales. Se sirve del protocolo ICMPv6 y puede operar aún sin la presencia de enrutadores. En cambio, sí requiere de una subred con soporte a la difusión de paquetes. Este método sólo aplica para los dispositivos; no puede ser utilizada para configurar enrutadores. El principio básico de este mecanismo consiste en que una máquina genera su dirección IPv6 a partir de información local y de la proporcionada por un enrutador. El enrutador proporciona información sobre la subred asociada al enlace; anuncia el prefijo.

<tikz title="Recepción de un RA">
\clip (0, 0) rectangle (10,7);
% \draw[help lines] (0,0) grid (10,7 );

\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,3)--(9,3);

\pgfputat{\pgfxy(0.8,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,5)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,3)--(1.5,5);
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (8,3)--(8,5);

\draw [->] (1.7,5) -- (1.7, 3.2) -- node [above = 10pt] {\tiny{FE80::IID1 -$>$ FE80::IID2}} node [above] {\tiny{RA ($\alpha$::/64, DHCPv6, MTU=1500, HL=64, {bit {\tt M=1}) }}} (7.8, 3.2) -- (7.8, 5);

</tikz>

Al igual que para la creación de la dirección de enlace local, la dirección unicast global se obtiene al concatenar el prefijo con el identificador de la interfaz. El prefijo se obtiene del mensaje de anuncio de enrutador, más concretamente, de la opción de ''información sobre el prefijo''. Si bien debe verificarse la unicidad de todas las direcciones unicast, en el caso de una dirección unicast obtenida mediante la configuración automática sin estado, esto no es obligatorio, pues la unicidad del identificador de la interfaz ya fue comprobada durante la configuración de la dirección local al enlace. Dado que el identificador es el mismo, no puede haber ambigüedad sobre la exclusividad de la dirección unicast global creada de esta forma.

La renumeración de los dispositivos en un enlace se realiza mediante enrutadores que transfieren las direcciones utilizadas a un estado depreciado y al mismo tiempo anuncian el nuevo prefijo con el que los dispositivos pueden re-crear una dirección preferida.

===Caso de redes NBMA ===

<tikz title="Off Link NDP: Primera etapa">
\clip (0, 0) rectangle (11,7);
% \draw[help lines] (0,0) grid (10,7 );

\pgfputat{\pgfxy(4.5,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}
\pgfputat{\pgfxy(1.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[decorate,decoration={zigzag}, color=black!60, ->, very thick] (8,3)-- node [above, color=black] {\tiny{FE80::IID2 -$>$ FF02::2 : RS}} (5,5);

</tikz>

Las redes NBMA (''Non Broadcast Multiple Access'') se caracterizan por no contar con un mecanismo de difusión hacia todos los dispositivos. Esto conduce a dos situiaciones posibles:
* ausencia total de difusión, como en las redes públicas (telefónica, ATM, …) en las que un solo destinatario puede ser contactado a la vez
* posibilidad de difusión por un número limitado de equipos, como es el caso de las redes de radio tipo 3G, WiMAX, en las que la estación base tiene la posibilidad de difundir datos hacia todos los equipos, pero esto no es posible en el sentido inverso (desde un dispositivo).

<tikz title="Off Link NDP: Segunda etapa">
\clip (0, 0) rectangle (11,7);
% \draw[help lines] (0,0) grid (10,7 );

\pgfputat{\pgfxy(4.5,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}
\pgfputat{\pgfxy(1.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[decorate,decoration={zigzag}, color=black!60, ->, very thick] (5, 5)-- node [above, color=black] {\tiny{RA ($\alpha$::/64, DHCPv6, OffLink, MTU=1500, HL=64, {bit {\tt M=1}})}} (8,3);

</tikz>

Un comportamiento de redes NBMA también puede ser deseable para limitar las restricciones de consumo energético. Por ejemplo, en el caso de redes de sensores, la difusión, o la difusión restringida (multicast) son costosas en consumo de energía pues todos los dispositivos deben procesar el mensaje y algunos deberán retransmitirlo.

<tikz title="Off Link NDP: Tercera etapa">
\clip (0, 0) rectangle (11,7);
% \draw[help lines] (0,0) grid (10,7 );

\pgfputat{\pgfxy(4.5,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}
\pgfputat{\pgfxy(1.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[decorate,decoration={zigzag}, color=black!60, ->, very thick] (8,3)-- node [left, near start, color=black] {\tiny{$\alpha$::IID2 -$>$ $\alpha$::IID3 : DATA}} (5,5);

\draw[decorate,decoration={zigzag}, color=black!60, ->, very thick] (5,5)-- node [left, midway, color=black] {\tiny{$\alpha$::IID2 -$>$ $\alpha$::IID3 : DATA}} (2,3);

</tikz>

Para estos casos, el protocolo de descubrimiento de vecinos cuenta con un modo NBMA llamado también ''OffLink'', el cual solamente autoriza el diálogo con un enrutador. Los intercambios comienzan de la misma forma:
* El dispositivo que desea insertarse en la red, emite un mensaje RS ('' Router Sollicitation”) utilizando la dirección destino FF02::2 (todos los enrutadores sobre el enlace. La red NBMA deberá enviar este mensaje hacia un enrutador.
* El enrutador responde poniendo el bit <tt>L</tt> (OffLink) a 1 en la opción [[#información|Información sobre el prefijo]], indicando que todos los intercambios deben pasar por él.
* El dispositivo construye su dirección global concatenando el prefijo a su identificador de interfaz.
* El dispositivo envía sistemáticamente todos los paquetes a la dirección física del enrutador. Éste, que tiene una visión global de la red, los reenvía hacia el destinatario apropiado.

<tikz title="Off Link NDP: Cuarta etapa (opcional)">
\clip (0, 0) rectangle (11,7);
% \draw[help lines] (0,0) grid (10,7 );

\pgfputat{\pgfxy(4.5,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}
\pgfputat{\pgfxy(1.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[decorate,decoration={zigzag}, color=black!60, ->, very thick] (8,3)-- node [left, near end, color=black] {\tiny{$\alpha$::IID2 -$>$ $\alpha$::IID3 : DATA}} (5,5);

\draw[decorate,decoration={zigzag}, color=black!60, ->, very thick] (5,5)-- node [left, midway, color=black] {\tiny{$\alpha$::IID2 -$>$ $\alpha$::IID3 : DATA}} (2,3);

\draw[decorate,decoration={triangles}, color=black!60, ->, thick, ] (5,5) to [bend left] node [right, near start, color=black] {\tiny{REDIRECT $\alpha$::IID3 : MAC3}} (8,3);

\draw [color=black!60, ->, very thick, dotted] (8,3)-- node [above, midway, color=black] {\tiny{$\alpha$::IID2 -$>$ $\alpha$::IID3 : DATA}} (2,3);

</tikz>

* Si la tecnología del enlace lo permite y si la política de gestión de red lo autoriza, el enrutador tiene la posibilidad de optimizar el tráfico, notificando al dispositivo la verdadera dirección del destinatario, emitiendo un mensaje de [[#IR|indicación de redirección]] (''ICMP Redirect''). Los paquetes subsecuentes ya no pasarán por el enrutador.

{{eSuivi|Tabla de contenido|Incio del capítulo|DHCPv6|DHCPv6}}

Protocolo de Descubrimiento de vecinos

2012-07-05T18:54:34Z

Jincera: /* Autoconfiguración sin estado */

{{eSuivi|Tabla de contenido|Incio del capítulo|DHCPv6|DHCPv6}}

__TOC__

El protocolo de descubrimiento de vecinos (NDP, ''Neighbor Discovery Protocol'') permite a un dispositivo integrarse en el ambiente local, es decir, el enlace sobre el cual se transmiten físicamente los paquetes IPv6. Permite establecer un diálogo con los equipos (estaciones y enrutadores) conectados sobre el mismo medio. No se pretende que un dispositivo conozca con exactitud la lista de todos los demás dispositivos conectados al enlace, sino de proveer un mecanismo para dialogar con quien necesite hacerlo.

El protocolo utiliza cinco tipos de mensajes ICMPv6 (ver Valores de los campos de tipo y código de ICMPv6). El campo número de saltos de la cabecera IPv6 contiene el valor 255. Este valor parece demasiado grande para datagramas que no debieran ser enrutados fuera del enlace físico. En realidad, si un equipo recibe un datagrama con un valor menor, significa que la información proviene de otra red y que ya ha atravesado al menos un enrutador. Por ello, los datagramas que tienen un valor diferente de 255 deben ser ignorados por el receptor.

{{Tableau eICMPv6}}

El protocolo realiza varias funciones:

* Resolución de direcciones. El principio es muy similar al del protocolo ARP de IPv4. La principal diferencia consiste en el uso de mensajes ICMPv6 estándar en lugar de definir otro protocolo de capa 3. Con esto se consigue una mayor flexibilidad de uso, especialmente en las redes que no soportan la difusión de mensajes. Al igual que en IPv4, el protocolo se encarga de construir tablas de correspondencia entre las direcciones IPv6 y las físicas.
* <div vecinos id="NUD"> Detección de inaccesibilidad de vecinos (NUD, ''Neighbor Unreachability Detection''). Esta función, que no existe en IPv4, permite eliminar de las tablas de configuración de un equipo, los vecinos que se han vuelto inaccesibles (por fallas, cambio de domicilio, ...). Si un enrutador deja de estar disponible, la tabla de enrutamiento puede ser modificada para considerar otra ruta. </div>
* Configuración. La configuración automática de los dispositivos es uno de los principales atractivos de IPv6. Se implementan varias funcionalidades del protocolo de descubrimiento de vecinos:
**Descubrimiento de enrutadores. Este protocolo permite que los dispositivos identifiquen a los enrutadores que se encuentran en su enlace físico. En IPv4, esta función la proporciona el protocolo ''ICMP Router Discovery''.
** Descubrimiento de prefijos. El dispositivo conoce el o los prefijos de red de acuerdo a los anuncios realizados por los enrutadores. Agregando su identificador de interfaz, el dispositivo construye su o sus direcciones IPv6. No hay un mecanismo equivalente para las direcciones IPv4 ya que son demasiado cortas para realizar la auto-configuración.
** Detección de direcciones duplicadas. Dado que las direcciones se configuran de forma automática, existen riesgos de error en caso de tener equipos con identificadores repetidos. Este protocolo verifica que ningún otro equipo en el enlace tiene la misma dirección IPv6. Esta función es una evolución del ARP gratuito en IPv4 emitido durante la inicialización de la interfaz.
** Descubrimiento de parámetros. Este protocolo permite que los dispositivos conozcan los distintos parámetros del enlace físico, por ejemplo, el tamaño de MTU, el número máximo de saltos permitido (valor original del campo número de saltos), si la configuración automática con estado (como [[Configuración con estado: DHCPv6|DHCPv6]]) está activa, etc. No existe un equivalente de esta funcionalidad en IPv4.
* Indicación de redirección. Este mensaje se utiliza cuando un enrutador conoce una trayectoria mejor (medida en número de saltos) para alcanzar un destino.
:En IPv4 una indicación de redireccionamiento sólo puede servir para corregir la dirección del enrutador utilizado para acceder a una máquina fuera de la red local. Los dispositivos deben conocer todas las direcciones correspondientes a equipos conectados en su propia red local.
:EnIPv6, la correspondencia entre prefijo y red local es menos rígida. Es de esperar que un dispositivo no conozca todos los prefijos de su red local (si ésta es compartida por varios prefijos), o que un prefijo se comparta entre varios enlaces (lo que corresponde a una generalización del modelo de redes lógicas IP sobre ATM). Bajo algunas configuraciones, la máquina emitirá sus paquetes al enrutador aún si el destinatario se encuentra en el mismo segmento que el emisor. En este caso, el enrutador emitirá un mensaje de redirección para que la continuación del diálogo entre ellos haga de manera directa (véanse los ejemplos [[#IR|Indicación redirección]]).
:En el caso más extremo, podría imaginarse en IPv6 que un dispositivo puede ser configurado para comunicarse únicamente con su enrutador por omisión. ICMPv6 ''redirect'' puede utilizarse entonces, para informar al dispositivo de destinatarios ubicados en el mismo enlace.

En IPv6 se especifican dos métodos de autoconfiguración para las direcciones unicast global:

* Autoconfiguración sin estado (''stateless autoconfiguration'', RFC 2462). Se utiliza cuando no es necesaria una gestión administrativa de las direcciones asignadas dentro de un sitio. Estos mecanismos se describen más adelante en este capítulo.
* Autoconfiguración con estado (''statefull autoconfiguration''). Se utiliza cuando un sitio requiere de un control estricto de la asignación de direcciones (''cf'' [[Configuración con estado: DHCPv6 | DHCPv6]]).

Sin embargo, el uso de DHCPv6 para obtener la dirección se controla mediante el protocolo de descubrimiento de vecinos.

= Datos transmitidos por los mensajes =

La principal motivación detrás del Protocolo de Descubrimiento de vecinos es unificar varios protocolos existentes en IPv4. En particular, la mayor parte de los datos utiliza un formato de opciones común, lo que simplifica la implementación del protocolo. El formato contiene los campos: tipo, longitud (en palabras de 64 bits), y datos. La baja precisión de campo longitud, presentará un desperdicio de espacio, pero permite una alineación de las opciones en palabras de 64 bits, lo que permite un procesamiento optimizado.

{{NB-Opciones}}

== <div id="física">Dirección física de la fuente/destino</div> ==

<tikz title="Formato de la opción dirección física fuente/destino">
\clip (0.2, 5.7) rectangle (11.1,6.7);
% \draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=1/2}};
\draw (2.9, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{lenght }};
\draw (5.3, 6) node (addr) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Link Layer Address}};

\draw [draw=white, thick] (addr.north east) -- (addr.south east);
\draw [draw=white, thick] (addr.north east) -- +(-2, 0);
\draw [draw=white, thick] (addr.south east) -- +(-2, 0);

\draw [dashed] (addr.north east) -- (addr.south east);
\draw [dashed] (addr.north east) -- +(-2, 0);
\draw [dashed] (addr.south east) -- +(-2, 0);
</tikz>

La figura ''Formato de la opción dirección física fuente/destino'' presenta estas opciones. El tipo 1 designa la dirección física de la fuente y el tipo 2 la dirección del destino.

El campo ''length'' es el tamaño en palabras de 64 bits de la opción. Por lo tanto, para el caso de una dirección MAC con longitud de 6 octetos, contiene el valor 1.

El RFC 2464 define el formato para las direcciones MAC-48 utilizadas en las redes Ethernet y Wi-Fi. El RFC 4944 define el formato para las direcciones MAC-16 y MAC-64 utilizadas en las redes de sensores bajo la norma IEEE 802.15.4.

== <div id="información">Información sobre el prefijo</div> ==

<tikz title="Formato de la opción información sobre el prefijo">
\clip (0.2, 2) rectangle (11.1, 7);
% \draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=3}};
\draw (2.9, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{length =4 }};
\draw (5.3, 6) node (addr) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm] {\tiny{Prefix Length}};
\draw (7.7, 6) node (bitL) [right, shade, top color=blue!15, bottom color=blue!5,, draw, minimum height=0.5cm, minimum width=.3cm]{}; \draw (bitL.text) node {\tiny{L}};
\draw (8, 6) node (bitA) [right, shade, top color=blue!15, bottom color=blue!5,, draw, minimum height=0.5cm, minimum width=.3cm]{};\draw (bitA.text) node {\tiny{A}};
\draw (8.3, 6) node (bitR) [right, shade, top color=blue!15, bottom color=blue!5,, draw, minimum height=0.5cm, minimum width=.3cm]{};\draw (bitR.text) node {\tiny{R}};
\draw (8.6, 6) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=1.5cm] {\tiny{Reserved}};

\draw (0.5, 5.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Valid Lifetime}};

\draw (0.5, 5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Prefered Lifetime}};

\draw (0.5, 4.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Reserved}};

\draw (0.5, 4) node (addr1) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{}};
\draw (0.5, 3.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{}};
\draw (0.5, 3) node (addr3) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Prefix}};
\draw (0.5, 2.5) node (addr4) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{}};

\draw [color=blue!10, very thick] (addr1.south east) -- (addr1.south west);
\draw [color=blue!10, very thick] (addr2.south east) -- (addr2.south west);
\draw [color=blue!10, very thick] (addr3.south east) -- (addr3.south west);
</tikz>

Esta opción contiene las informaciones sobre el prefijo para permitir una configuración automática de los dispositivos. El campo tipo tiene el valor 3 y el de longitud, 4. La figura ''Formato de la opción información sobre el prefijo'' muestra el formato de esta opción:

* El campo ''Prefix lenght'' indica cuántos bits son significativos para el prefijo anunciado en un campo siguiente.
* El bit <tt>L</tt> indica, cuando vale 1, que el prefijo permite indicar que todos los demás dispositivos que comparten el mismo prefijo, están en el mismo enlace, por lo que el emisor puede contactarlos directamente. En caso contrario, el dispositivo envía el paquete hacia el enrutador. Si éste último sabe que el emisor puede contactar directamente al destinatario, emitirá un mensaje ICMPv6 de indicación de redirección.
* El bit <tt>A</tt> indica, cuando vale 1, que el prefijo anunciado puede utilizarse para formar la dirección del dispositivo.
* El bit <tt>R</tt>, indica, cuando vale 1, que el campo prefijo contiene la dirección global de un enrutador ''agente base''. Los bits de mayor peso aún pueden utilizarse para formar un prefijo.
* El campo duración de validez indica, en segundos, la duración durante la cual el prefijo es válido.
* El campo duración preferente indica la duración, en segundos, durante la cual una dirección formada con el protocolo de configuración sin estado se mantiene ''preferente'' (''cf'' [[Planes de direccionamiento|Tiempo de vida de las direcciones]]).

Para estos dos campos, un valor de <tt>0xffffffff</tt> representa una duración infinita. Estos campos pueden servir durante la fase de transición de un proveedor de acceso a otro; es decir, de un prefijo a otro.
* El campo reservado permite alinear el prefijo a una frontera de palabra de 64 bits.
* El campo prefijo contiene el valor de prefijo anunciado sobre el enlace. Para mantener una alineación de 64 bits para el resto de datos del paquete, este campo tiene una longitud fija de 128 bits.

== <div id="redirigida">Cabecera de redirección </div> ==

<tikz title="Formato de la opción cabecera de redirección">
\clip (0.2, 3.1) rectangle (11.1, 7);
% \draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=5}};
\draw (2.9, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{length =1 }};
\draw (5.3, 6) node (addr) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Reserved}};

\draw (0.5, 5.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Reserved}};

\draw (0.5, 4.25) node (context) [right, shade, top color=purple!50, bottom color=purple!10, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{IPv6 Header and Data}};
</tikz>

Esta opción es utilizada por el mensaje de indicación de redirección. Permite encapsular los primeros octetos del paquete IPv6 que provocó la emisión de este mensaje, como ocurre con los mensajes de error de ICMPv6.

El campo tipo tiene el valor 4. El tamaño de esta opción debe evitar que el paquete IPv6 rebase los 1280 octetos (''cf'' figura ''Formato de la opción cabecera de redirección''). Sin embargo, el paquete debe contener la mayor cantidad de información posible.

== <div id="MTU">MTU</div> ==

<tikz title="Formato de la opción MTU">

\clip (0.2, 5.1) rectangle (11.1, 7);
% \draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=5}};
\draw (2.9, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{lenght =1 }};
\draw (5.3, 6) node (addr) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Reserved}};

\draw (0.5, 5.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{MTU}};
</tikz>

Esta opción permite notificar a los dispositivos el tamaño máximo de datos que pueden ser transmitidos sobre el enlace. La figura ''Formato de la opción MTU'' muestra su estructura. No es necesario difundir esta información si el dispositivo utiliza siempre el tamaño máximo permitido. Por ejemplo, sobre las redes Ethernet, los dispositivos utilizarán el valor 1,500. En cambio, en las redes Token Ring o FDDI, con frecuencia es necesario especificar si los equipos pueden utilizar la longitud máxima o un tamaño inferior para permitir el uso de puentes en la red.

En esta opción, el campo tipo tiene un valor de 5 y el de longitud, de 1.

=Mensajes estándar de Descubrimiento de vecinos =

Además de las cinco opciones básicas descritas en la tabla ''Utilización de las opciones en los mensajes de descubrimiento de vecinos'', existen otras específicas para la movilidad y para las redes NBMA (''Non Broadcast Multiple Access'').

{|
|+ Utilización de las opciones en los mensajes de descubrimiento de vecinos
| width = 150 | || width = 100 |[[#RS|Solicitud de]] || width = 100 |[[#RA|Anuncio de]] || width = 100 |[[#NS|Solicitud de]] ||width = 100 | [[#NA|Anuncio de]] ||width = 100 |[[#IR|Indicación de]]
|-
| || [[#RS|enrutador]] || [[#RA|enrutador]] || [[#NS|un vecino]] || [[#NA| un vecino]] || [[#IR|redirección]]
|-style="background:silver"
|[[#física |Dirección física de la fuente]] || presente || presente || presente || ||
|-
|[[# física | Dirección física del destino]] || || || || presente || presente
|-style="background:silver"
|[[#información|Información sobre el prefijo]] || || ≥ 1 || || ||
|-
|[[#redirigida |Cabecera de redirección]] || || || || || presente
|-style="background:silver"
| [[#MTU |MTU]] || || posible || || ||
|}

Las distintas funcionalidades de descubrimiento de vecinos utilizan cinco mensajes: dos para el diálogo entre un dispositivo y un enrutador, dos para el diálogo entre vecinos, y uno para la redirección. Cada uno de estos mensajes puede incluir opciones adicionales.

== <div id="RS">Solicitud de enrutador</div> ==

<tikz title="Formato de los paquetes de solicitud de enrutador">
\clip (0.2, 3.5) rectangle (11.1,7.1);
%\draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=133}};
\draw (2.9, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code =0 }};
\draw (5.3, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};
\draw (0.5, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Reserved}};

\draw (0.5, 4.25) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Options:\\
- Source link-layer address
}};
</tikz>

El mensaje de solicitud de enrutador (''cf'' figura Formato de los paquetes de solicitud de enrutador) es emitido al iniciar un dispositivo para recibir más rápidamente la información del enrutador. Este mensaje se envía a la dirección IPv6 multicast reservada a los enrutadores en el mismo enlace <tt>FF02::2</tt>. Si el dispositivo aún no conoce su dirección fuente, se utiliza la dirección no especificada.

El campo opción normalmente contiene la dirección física del dispositivo.

== <div id="RA">Anuncio de enrutador</div> ==

<tikz title="Formato de los paquetes de anuncio de enrutador">
\clip (0.2, 1.5) rectangle (11.1,7.1);
%\draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=134}};
\draw (2.9, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code =0 }};
\draw (5.3, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};

\draw (0.5, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Cur. Hop Lim.}};
\draw (2.9, 5.5) node (bitM) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{}; \draw (bitM.text) node {\tiny{M}};
\draw (3.2, 5.5) node (bitO) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{};\draw (bitO.text) node {\tiny{O}};
\draw (3.5, 5.5) node (bitH) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{};\draw (bitH.text) node {\tiny{H}};
\draw (3.8, 5.5) node (res) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=1.5cm]{\tiny{reserved}};
\draw (5.3, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Router Lifetime}};

\draw (0.5, 5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=9.6cm]{\tiny{Reachable Time}};
\draw (0.5, 4.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=9.6cm]{\tiny{Retrans Time}};

\draw (0.5, 3.25) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Options:\\
Source link-layer address\\
MTU\\
Prefix Information (may be repeated)\\
}};
</tikz>

Este mensaje (''cf'' figura ''Formato de los paquetes de anuncio de enrutador'') es emitido periódicamente por los enrutadores, o bien, en respuesta a un mensaje de solicitud de enrutador generado por un dispositivo. El campo dirección fuente contiene la dirección de enlace local del enrutador, mientras que el campo dirección destino contiene la dirección del dispositivo que generó la solicitud, o la dirección de todas las estaciones (<tt>ff02::01</tt>).

Cuando el campo de máximo número de saltos tiene un valor distinto de cero, muestra el valor que podría colocarse en el campo de número de saltos de los paquetes emitidos. El bit <tt>M</tt> indica que una dirección del dispositivo debe ser obtenida mediante un protocolo de configuración (''cf'' [[Configuración con estado:DHCPv6]]). El bit <tt>O</tt> también indica la presencia de un servicio de configuración para obtener información adicional a la dirección. Si no es posible obtener la dirección mediante un servidor, el dispositivo procede a realizar una configuración sin estado, concatenando su identificador de interfaz a los prefijos que conoce. El bit <tt>H</tt> indica que el enrutador puede ser utilizado como agente base por un nodo móvil (''cf'' [[Desplazamientos_de_móviles#Anuncio_del_agente_base |Anuncio del agente base]]).

El campo tiempo de vida del enrutador indica el período (en segundos) durante el cual el equipo que emite el anuncio realizará funciones de enrutador por omisión. El valor máximo corresponde a 18 horas 12 minutos, pero como este mensaje se emite periódicamente, en la práctica no existe un límite para el tiempo de vida de un enrutador. Un valor de <tt>0</tt> indica que el dispositivo no cumple con las funciones de enrutador por omisión. Este tiempo de vida no se aplica a las opciones transportadas por este mensaje.

El campo duración de accesibilidad indica el período (en milisegundos) durante el cual una información almacenada en la memoria caché de la máquina (por ejemplo, la tabla de correspondencia entre las direcciones IPv6 y las físicas) puede ser considerada como válida. Al vencimiento de este tiempo, se emite un mensaje de detección de inaccesibilidad para verificar la pertinencia de la información almacenada.

El campo temporización de retransmisión muestra el período (en milisegundos) entre dos emisiones no solicitadas de este mensaje. Permite que los demás equipos puedan detectar la inaccesibilidad de un enrutador.

Este mensaje puede transportar las siguientes opciones:

* dirección física de la fuente,
* MTU,
* información sobre el prefijo (uno o varios).

== <div Id="NS"> Solicitud de un vecino </div> ==

<tikz title="Formato de los paquetes de solicitud de un vecino">

\clip (0.2, 1.5) rectangle (11.1,7.1);
%\draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=135}};
\draw (2.9, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code =0 }};
\draw (5.3, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};

\draw (0.5, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=9.6cm]{\tiny{Reserved}};

\draw (0.5, 4.25) node (context) [right, shade, top color=blue!50, bottom color=blue=!10, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Target Address}};

\draw (0.5, 2.25) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Options:\\
Source link-layer address\\
}};
</tikz>

Este mensaje (''cf'' figura ''Formato de los paquetes de solicitud de un vecino'') permite obtener información a partir de un equipo vecino, es decir, localizado en el mismo enlace físico (o conectado a través de puentes). El mensaje puede ser emitido explícitamente a él, o enviado con una dirección de difusión. En el caso de determinación de la dirección física, éste corresponde a la solicitud de ARP en IPv4.

El campo dirección fuente del paquete IPv6 contiene ya sea la dirección local al enlace, una dirección global o la dirección no especificada. El campo destino puede contener la dirección de difusión múltiple solicitada correspondiente a la dirección buscada (''cf'' [[Direccionamiento_multicast#Identificador_de_grupo|Identificador de grupo]]) o la dirección del dispositivo (en el caso de una detección de inaccesibilidad de vecinos, ''NUD'').

El campo dirección del destino contiene la dirección IPv6 del equipo buscado. El campo opción generalmente contiene la dirección física de la fuente.

== <div Id="NA"> Anuncio de un vecino</div> ==

<tikz title="Formato de los paquetes de anuncio de un vecino">

\clip (0.2, 1.5) rectangle (11.1,7.1);
%\draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=136}};
\draw (2.9, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code =0 }};
\draw (5.3, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};

\draw (0.5, 5.5) node (bitR) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{}; \draw (bitR.text) node {\tiny{R}};
\draw (0.8, 5.5) node (bitS) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{}; \draw (bitS.text) node {\tiny{S}};
\draw (1.1, 5.5) node (bitO) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{}; \draw (bitO.text) node {\tiny{O}};
\draw (1.4, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=8.7cm]{\tiny{Reserved}};

\draw (0.5, 4.25) node (context) [right, shade, top color=blue!50, bottom color=blue=!10, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Target Address}};

\draw (0.5, 2.25) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Options:\\
Source link-layer address\\
}};
</tikz>

Este mensaje (''cf'' figura ''Formato de los paquetes de anuncio de un vecino'') se emite en respuesta a una solicitud, aunque también puede ser emitido de forma espontánea para propagar la información de cambio de dirección física, o del estado de "enrutador". Para el caso de la determinación de la dirección física, es equivalente a la respuesta ARP en IPv4.

* El bit <tt> R </tt> se pone a 1 si el remitente es un enrutador. Este bit se utiliza para permitir la detección de un enrutador que se convierte en un equipo ordinario.
* El bit <tt> S </tt> en 1 indica que este anuncio se emite en respuesta a una solicitud.
* El bit <tt> O </tt> en 1 indica que este anuncio debe borrar las informaciones anteriores que se encuentran almacenadas en la memoria cachés de otros equipos, en especial la tabla que contiene las direcciones físicas.
* El campo dirección del destino contiene, si el bit<tt> S </tt> es 1, el valor del campo dirección del destino de la solicitud a la que está respondiendo este mensaje. Si el bit <tt> S </tt> es 0, este campo contiene la dirección IPv6 local al enlace del equipo emisor.
* La opción dirección física del destino contiene la dirección física del emisor.

== <div id="IR">Indicación de redirección</div> ==

<tikz title="Formato de los paquetes de indicación de redirección">
\clip (0.2, 0) rectangle (11.1,7.1);
%\draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=137}};
\draw (2.9, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code =0 }};
\draw (5.3, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};

\draw (0.5, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=9.6cm]{\tiny{Reserved}};

\draw (0.5, 4.25) node (context) [right, shade, top color=blue!50, bottom color=blue=!10, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Target Address}};

\draw (0.5, 2.25) node (context) [right, shade, top color=blue!50, bottom color=blue=!10, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Destination Address}};

\draw (0.5, 0.5) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=1.5cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Options:\\
Target link-layer address\\
Redirected Header\\
}};
</tikz>

La técnica de redirección es la misma que en IPv4. Un dispositivo sólo conoce los prefijos de las redes a las que está conectado directamente y la dirección de un enrutador por omisión. Si la ruta se puede optimizar, el enrutador por omisión envía un mensaje para indicar que existe un camino más corto. De hecho, como en IPv6 el enrutador por omisión se establece de forma automática, las rutas no necesariamente son las mejores (''cf'' figura ''Enrutamiento por omisión no óptimo'').

Otro caso particular en IPv6 ocurre con los dispositivos que se encuentran en el mismo enlace físico, pero tienen diferentes prefijos. La comunicación entre ellos pasa inicialmente a traves de enrutador por omisión hasta que éste notifica que existe una ruta directa entre ellos.

La figura ''Formato de los paquetes de indicación de redirección'' muestra el formato del mensaje:

* El campo dirección objetivo (''Target address'') contiene la dirección IPv6 del equipo hacia el que los paquetes deben ser enviados.
* El campo dirección destino contiene la dirección IPv6 del dispositivo que está siendo redirigido hacia la dirección objetivo.

Cuando la redirección apunta a un dispositivo situado en el mismo enlace, la dirección objetivo y de destino son las mismas.

Las opciones incluyen la dirección física de un nuevo enrutador y la cabecera del paquete redirigido.

Este mensaje se puede utilizar de la misma forma que en IPv4. Un dispositivo solamente tiene una ruta por omisión para acceder a equipos con un prefijo diferente. En consecuencia, envía su paquete al enrutador por omisión, quien observa que el prefijo destino es accesible a través de la misma subred que el emisor. El enrutador por omisión reenvía el paquete y notifica al emisor que puede contactar directamente a las máquinas que poseen el prefijo del destino.

IPv6 también utiliza este mensaje para optimizar la resolución fuera del enlace para el [[#Caso de redes NBMA |caso de redes NBMA]].

= Configuración automática =
Tradicionalmente, la configuración de una interfaz de red de una máquina se hacía manualmente. Esto suele ser un trabajo lento y propenso a errores. Con IPv6, se automatiza el proceso de configuración y se introducen, al mismo tiempo, mecanismos de funcionamiento inmediato (''plug and play'') a la interfaz de red. La configuración automática significa que un dispositivo obtendrá toda la información necesaria para su conexión a una red local IP sin ninguna intervención humana. En el caso ideal, cualquier usuario desempaca su nuevo equipo, lo conecta a la red local y lo ve funcionar sin tener que introducir la información propia de "especialistas". Ahora vamos a discutir otro aspecto de la configuración automática de IPv6, la auto-configuración de direcciones, que tiene como objetivos:

* La adquisición de una dirección cuando un dispositivo está conectado a una red por primera vez;
* la posibilidad de asignar otros prefijos, o de renumerar un dispositivo.

El proceso de configuración automática de direcciones IPv6 incluye la creación de una dirección local al enlace, la agregación a grupos multicast solicitados, la verificación de la unicidad de la dirección local al enlace y la creación de direcciones unicast global.

La tarea del enrutador es importante en la configuración automática. Indica a la máquina, mediante los bits de la cabecera (''cf'' [[#RA|anuncio de enrutador]]), del mensaje de anuncio de los enrutadores, el método a conservar y eventualmente proporcionar la información necesaria para su configuración. El bit <tt> M </tt> (''configuración de dirección administrada'') puesto a 1 indica que el equipo no debe crear por sí mismo una dirección a partir de su identificador de interfaz y de los prefijos recibidos, sino que debe solicitarla explícitamente ante un servidor de direcciones. El bit O <tt> </tt> (''otra configuración de estado'') indica que el dispositivo debe consultar el servidor para obtener otros parámetros distintos de la dirección. El algoritmo para el proceso de configuración automática de direcciones se desglosa de la siguiente manera:

* La primera fase consiste en crear la dirección local al enlace.
* Una vez que la unicidad de esta dirección es verificada, el dispositivo está listo para comunicarse con otras máquinas en el enlace.
* El dispositivo debe tratar de adquirir un mensaje de anuncio de enrutadores para determinar el método de obtención de la dirección unicast global.
* Si hay un enrutador en el enlace, el dispositivo debe aplicar el método especificado por el mensaje de anuncio de enrutadores, a saber:
** La configuración automática sin estado,
** la configuración automática con estado.
* Si no hay ningún enrutador en el enlace, el dispositivo debe tratar de obtener la dirección unicast global por el método de configuración automática con estado. Si el intento falla, no hay más que hacer. Las comunicaciones sólo podrán hacerse sobre el enlace con la dirección local al enlace, pues el dispositivo no tendrá una dirección con la cobertura necesaria que le permita comunicarse con otras máquinas fuera del enlace.

==Ciclo de vida de una dirección==

Al generalizar en IPv6 el plan de direccionamiento CIDR, los prefijos quedan, en todos los casos, siendo propiedad de los operadores. Ya no pueden otorgarse "a perpetuidad" a los dispositivos. Para facilitar la renumeración de una máquina, la asignación de una dirección a una interfaz es temporal, las direcciones IPv6 no se entregan, sino que se prestan. Se asocia un tiempo de vida a la dirección, que indica el tiempo durante el cual la dirección pertenece a la interfaz. Cuando el tiempo de vida se ha agotada, la dirección deja de ser válida, se suprime de la interfaz y queda potencialmente éste puede prolongarse indefinidamente. La dirección local al enlace tiene un tiempo de vida ilimitado.

<tikz title="Estados sucesivos de una dirección en una interfaz">

\draw [thick, ->] (0,2) -- (9.5,2);

\draw [->] (1,4) node [above=10pt] {\tiny{allocation}}-- (1,2);
\draw (1, 2) node [rectangle, minimum width=1cm, minimum height=1cm, fill, left color=black!10, right color=black!20, draw=black, above right] (tentative) {};
\draw (tentative.south east) node [rectangle, minimum width=3cm, minimum height=1cm, fill, left color=green, right color=green!50, draw=black, above right] (preferred) {};
\draw (preferred.south east) node [rectangle, minimum width=2cm, minimum height=1cm, fill, left color=orange , right color=orange!50!red, draw=black, above right] (deprecated) {};
\draw (deprecated.south east) node [rectangle, minimum width=2cm, minimum height=1cm, fill, color=red, draw=black, above right] (novalid) {};

\draw (tentative.text) node {\tiny{Tentative}};
\draw (preferred.text) node {\tiny{Preferred}};
\draw (deprecated.text) node {\tiny{Deprecated}};
\draw (novalid.text) node {\tiny{Invalid}};

\draw [dotted] (tentative.south west) -- +(0, -1);
\draw [dotted] (preferred.south west) -- +(0, -1);
\draw [dotted] (deprecated.south west) -- +(0, -1);
\draw [dotted] (novalid.south west) -- +(0, -1);

\draw [dashed, <->] ([yshift=-0.5cm]tentative.south west) -- node [above] {\tiny{DAD}} ([yshift=-0.5cm] preferred.south west) ;

\draw [dashed, <->] ([yshift=-0.5cm]preferred.south west) -- node [above] {\tiny{Valid}} ([yshift=-0.5cm] novalid.south west) ;

</tikz>

La renumeración de una interfaz consiste en pasar de una dirección a otra. Durante una renumeración, no es aconsejable cambiar repentinamente de dirección, de lo contrario, todas las comunicaciones TCP que la utilizan como identificador de conexión, se cortarían inmediatamente. Esto conllevaría importantes perturbaciones a nivel de las aplicaciones.

Por ello, para facilitar esta transición se implementó un mecanismo de obsolescencia que invalida gradualmente una dirección. Este mecanismo se sirve de la capacidad de asignación de varias direcciones válidas a una misma interfaz. Para elegir la dirección a utilizar, se le asocia un estado que indica en qué fase de su tiempo de vida se encuentra con respecto a la interfaz. El primero de esos estados se conoce como preferido: no hay ninguna restricción de uso. Poco antes de su invalidación, la dirección pasa a un estado de depreciado. En él se desaconseja el uso de la dirección, pero no está prohibido. Una dirección depreciada ya no debe ser utilizada como dirección fuente de nuevas comunicaciones (como el establecimiento de conexión TCP), pero todavía puede emplearse como dirección fuente de comunicaciones ya establecidas. Los paquetes recibidos a una dirección depreciada seguirán siendo entregados normalmente. El control de la duración de cada estad de una dirección válida se efectúa agregando un tiempo de vida al estado preferido.
La figura '''Estados sucesivos de una dirección en una interfaz''' representa los diferentes estados que toma una dirección cuando se asigna a una interfaz.

== Creación de la dirección local al enlace ==

<tikz title=" Creación de la dirección local al enlace">
\clip (0, 0) rectangle (10,7);
% \draw[help lines] (0,0) grid (10,7 );

\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,3)--(9,3);

\pgfputat{\pgfxy(0.8,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,5)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,3)--(1.5,5);
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (8,3)--(8,5);

\draw (1.5,4.5) node {\small{FE80::IID1}};
\draw (1.5,4) node {\small{$\alpha$::IID1/64}};

\draw (8, 4.5) node {\small{FE80::IID2}};

</tikz>

Durante la inicialización de la interfaz, el dispositivo construye un identificador de interfaz que debe ser único en el enlace. Este identificador se utiliza la dirección de [[ Identificador_de_interfaz#EUI-64 | EUI-64]]. El principio básico para crear la direcciónIPv6 consiste en unir un prefijo con el identificador. La dirección local al enlace se crea tomando el prefijo de Enlace_local (<tt>FE80::/64</tt>). La dirección creada de esa manera, todavía no puede ser utilizada; tiene un estado temporal pues el dispositivo debe comprobar la exclusividad de esta dirección en el enlace mediante el procedimiento de detección de direcciones duplicadas. Si se encuentra que la dirección local al enlace no es única, se suspende la autoconfiguración y será necesario proceder a una configuración manual.

Una vez que se ha asegurado la unicidad de la dirección local al enlace, ésta se considera una dirección válida para la interfaz, con lo que termina la prima fase del proceso de autoconfiguración.

==<div id="DAD"> Detección de una dirección duplicada </div>==

<tikz title="Emisión de un NS en una detección de Dir. duplicada (DAD)">
\clip (0, 0) rectangle (10,7);
% \draw[help lines] (0,0) grid (10,7 );

\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,3)--(9,3);

\pgfputat{\pgfxy(0.8,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,5)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,3)--(1.5,5);
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (8,3)--(8,5);

\draw (7.8, 5) -- (7.8, 3.2);
\draw [<->] (1, 3.2) -- node [above] {\tiny{::/0 -$>$ solicited (FE80:IID2) : NS (who has FE80::IID2?)}}(9, 3.2) ;

</tikz>

Para comprobar la exclusividad de direcciones locales al enlace o de direcciones unicast, los dispositivos deben ejecutar un algoritmo de detección de direcciones duplicadas (DAD) antes poder utilizarlas. El algoritmo usa los mensajes ICMPv6 [[Protocolo_de_Descubrimiento_de_vecinos#NS|solicitud de un vecino]] y [[#NA|anuncio de un vecino.]] Si se detecta una dirección que ya está en uso, ésta no podrá ser asignada a la interfaz, la autoconfiguración automática debe suspenderse y será necesario proceder a una configuración manual. Durante la ejecución del algoritmo DAD, la dirección es considerada como "provisional" hasta tener la confirmación de su unicidad. Una dirección provisional se asigna a una interfaz únicamente para recibir los mensajes de solicitud y anuncio de un vecino. Otros mensajes recibidos, son ignorados. El algoritmo DAD consiste en enviar un mensaje de solicitud de un vecino colocando en el campo de dirección objetivo la dirección provisional. Para distinguir el algoritmo DAD del de Descubrimiento de vecinos, el paquete IPv6 que contiene un mensaje de solicitud de un vecino tiene como dirección fuente una dirección no determinada. Así se presentan tres casos:

* Se recibe un mensaje de anucio de un vecino: Significa que la dirección provisional está siendo utilizada como válida por otro dispositivo, por lo que ésta no es única y no puede ser retenida por el dispositivo.
* Se recibe un mensaje de solicitud de un vecino como parte del algoritmo DAD. La dirección provisional también es provisional para otra máquina. En este caso, la dirección provisional no puede ser utilizada por ninguna de ellas.
* No se recibe ningún mensaje durante un segundo (valor por omisión). La dirección provisional es única, por lo que su estado pasa de provisional a válida y se le asigna a la interfaz.

Obsérvese que este algoritmo no proporciona una fiabilidad absoluta, especialmente cuando el enlace está segmentado.

== Autoconfiguración sin estado ==

<tikz title="Emisión de un RS">
\clip (0, 0) rectangle (10,7);
% \draw[help lines] (0,0) grid (10,7 );

\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,3)--(9,3);

\pgfputat{\pgfxy(0.8,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,5)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,3)--(1.5,5);
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (8,3)--(8,5);

\draw (7.8, 5) -- (7.8, 3.2);
\draw [<->] (1, 3.2) -- node [above] {\tiny{FE80::IID2 -$>$ FF02::2 : RS }} (9, 3.2) ;

</tikz>

La configuración automática sin estado (RFC 2462) no requiere de ninguna configuración manual de los dispositivos, una configuración mínima para los enrutadores, y tampoco necesita de servidores adicionales. Se sirve del protocolo ICMPv6 y puede operar aún sin la presencia de enrutadores. En cambio, sí requiere de una subred con soporte a la difusión de paquetes. Este método sólo aplica para los dispositivos; no puede ser utilizada para configurar enrutadores. El principio básico de este mecanismo consiste en que una máquina genera su dirección IPv6 a partir de información local y de la proporcionada por un enrutador. El enrutador proporciona información sobre la subred asociada al enlace; anuncia el prefijo.

<tikz title="Recepción de un RA">
\clip (0, 0) rectangle (10,7);
% \draw[help lines] (0,0) grid (10,7 );

\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,3)--(9,3);

\pgfputat{\pgfxy(0.8,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,5)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,3)--(1.5,5);
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (8,3)--(8,5);

\draw [->] (1.7,5) -- (1.7, 3.2) -- node [above = 10pt] {\tiny{FE80::IID1 -$>$ FE80::IID2}} node [above] {\tiny{RA ($\alpha$::/64, DHCPv6, MTU=1500, HL=64, {bit {\tt M=1}) }}} (7.8, 3.2) -- (7.8, 5);

</tikz>

Al igual que para la creación de la dirección de enlace local, la dirección unicast global se obtiene al concatenar el prefijo con el identificador de la interfaz. El prefijo se obtiene del mensaje de anuncio de enrutador, más concretamente, de la opción de ''información sobre el prefijo''. Si bien debe verificarse la unicidad de todas las direcciones unicast, en el caso de una dirección unicast obtenida mediante la configuración automática sin estado, esto no es obligatorio, pues la unicidad del identificador de la interfaz ya fue comprobada durante la configuración de la dirección local al enlace. Dado que el identificador es el mismo, no puede haber ambigüedad sobre la exclusividad de la dirección unicast global creada de esta forma.

La renumeración de los dispositivos en un enlace se realiza mediante enrutadores que transfieren las direcciones utilizadas a un estado depreciado y al mismo tiempo anuncian el nuevo prefijo con el que los dispositivos pueden re-crear una dirección preferida.

===Caso de redes NBMA ===

<tikz title="Off Link NDP: Primera etapa">
\clip (0, 0) rectangle (11,7);
% \draw[help lines] (0,0) grid (10,7 );

\pgfputat{\pgfxy(4.5,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}
\pgfputat{\pgfxy(1.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[decorate,decoration={zigzag}, color=black!60, ->, very thick] (8,3)-- node [above, color=black] {\tiny{FE80::IID2 -$>$ FF02::2 : RS}} (5,5);

</tikz>

Las redes NBMA (''Non Broadcast Multiple Access'') se caracterizan por no contar con un mecanismo de difusión hacia todos los dispositivos. Esto conduce a dos situiaciones posibles:
* ausencia total de difusión, como en las redes públicas (telefónica, ATM, …) en las que un solo destinatario puede ser contactado a la vez
* posibilidad de difusión por un número limitado de equipos, como es el caso de las redes de radio tipo 3G, WiMAX, en las que la estación base tiene la posibilidad de difundir datos hacia todos los equipos, pero esto no es posible en el sentido inverso (desde un dispositivo).

<tikz title="Off Link NDP: Segunda etapa">
\clip (0, 0) rectangle (11,7);
% \draw[help lines] (0,0) grid (10,7 );

\pgfputat{\pgfxy(4.5,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}
\pgfputat{\pgfxy(1.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[decorate,decoration={zigzag}, color=black!60, ->, very thick] (5, 5)-- node [above, color=black] {\tiny{RA ($\alpha$::/64, DHCPv6, OffLink, MTU=1500, HL=64, {bit {\tt M=1}})}} (8,3);

</tikz>

Un comportamiento de redes NBMA también puede ser deseable para limitar las restricciones de consumo energético. Por ejemplo, en el caso de redes de sensores, la difusión, o la difusión restringida (multicast) son costosas en consumo de energía pues todos los dispositivos deben procesar el mensaje y algunos deberán retransmitirlo.

<tikz title="Off Link NDP: Tercera etapa">
\clip (0, 0) rectangle (11,7);
% \draw[help lines] (0,0) grid (10,7 );

\pgfputat{\pgfxy(4.5,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}
\pgfputat{\pgfxy(1.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[decorate,decoration={zigzag}, color=black!60, ->, very thick] (8,3)-- node [left, near start, color=black] {\tiny{$\alpha$::IID2 -$>$ $\alpha$::IID3 : DATA}} (5,5);

\draw[decorate,decoration={zigzag}, color=black!60, ->, very thick] (5,5)-- node [left, midway, color=black] {\tiny{$\alpha$::IID2 -$>$ $\alpha$::IID3 : DATA}} (2,3);

</tikz>

Para estos casos, el protocolo de descubrimiento de vecinos cuenta con un modo NBMA llamado también ''OffLink'', el cual solamente autoriza el diálogo con un enrutador. Los intercambios comienzan de la misma forma:
* El dispositivo que desea insertarse en la red, emite un mensaje RS ('' Router Sollicitation”) utilizando la dirección destino FF02::2 (todos los enrutadores sobre el enlace. La red NBMA deberá enviar este mensaje hacia un enrutador.
* El enrutador responde poniendo el bit <tt>L</tt> (OffLink) a 1 en la opción [[#información|Información sobre el prefijo]], indicando que todos los intercambios deben pasar por él.
* El dispositivo construye su dirección global concatenando el prefijo a su identificador de interfaz.
* El dispositivo envía sistemáticamente todos los paquetes a la dirección física del enrutador. Éste, que tiene una visión global de la red, los reenvía hacia el destinatario apropiado.

<tikz title="Off Link NDP: Cuarta etapa (opcional)">
\clip (0, 0) rectangle (11,7);
% \draw[help lines] (0,0) grid (10,7 );

\pgfputat{\pgfxy(4.5,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}
\pgfputat{\pgfxy(1.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[decorate,decoration={zigzag}, color=black!60, ->, very thick] (8,3)-- node [left, near end, color=black] {\tiny{$\alpha$::IID2 -$>$ $\alpha$::IID3 : DATA}} (5,5);

\draw[decorate,decoration={zigzag}, color=black!60, ->, very thick] (5,5)-- node [left, midway, color=black] {\tiny{$\alpha$::IID2 -$>$ $\alpha$::IID3 : DATA}} (2,3);

\draw[decorate,decoration={triangles}, color=black!60, ->, thick, ] (5,5) to [bend left] node [right, near start, color=black] {\tiny{REDIRECT $\alpha$::IID3 : MAC3}} (8,3);

\draw [color=black!60, ->, very thick, dotted] (8,3)-- node [above, midway, color=black] {\tiny{$\alpha$::IID2 -$>$ $\alpha$::IID3 : DATA}} (2,3);

</tikz>

* Si la tecnología de enlace lo permite y si la política de gestión de red lo autoriza, el enrutador tiene la posibilidad de optimizar el tráfico, notificando al dispositivo la verdadera dirección del destinatario, emitiendo un mensaje de [[#IR|indicación de redirección]] (''ICMP Redirect''). Los paquetes subsecuentes ya no pasarán por el enrutador.

{{eSuivi|Tabla de contenido|Incio del capítulo|DHCPv6|DHCPv6}}

Protocolo de Descubrimiento de vecinos

2012-07-05T18:53:56Z

Jincera:

{{eSuivi|Tabla de contenido|Incio del capítulo|DHCPv6|DHCPv6}}

__TOC__

El protocolo de descubrimiento de vecinos (NDP, ''Neighbor Discovery Protocol'') permite a un dispositivo integrarse en el ambiente local, es decir, el enlace sobre el cual se transmiten físicamente los paquetes IPv6. Permite establecer un diálogo con los equipos (estaciones y enrutadores) conectados sobre el mismo medio. No se pretende que un dispositivo conozca con exactitud la lista de todos los demás dispositivos conectados al enlace, sino de proveer un mecanismo para dialogar con quien necesite hacerlo.

El protocolo utiliza cinco tipos de mensajes ICMPv6 (ver Valores de los campos de tipo y código de ICMPv6). El campo número de saltos de la cabecera IPv6 contiene el valor 255. Este valor parece demasiado grande para datagramas que no debieran ser enrutados fuera del enlace físico. En realidad, si un equipo recibe un datagrama con un valor menor, significa que la información proviene de otra red y que ya ha atravesado al menos un enrutador. Por ello, los datagramas que tienen un valor diferente de 255 deben ser ignorados por el receptor.

{{Tableau eICMPv6}}

El protocolo realiza varias funciones:

* Resolución de direcciones. El principio es muy similar al del protocolo ARP de IPv4. La principal diferencia consiste en el uso de mensajes ICMPv6 estándar en lugar de definir otro protocolo de capa 3. Con esto se consigue una mayor flexibilidad de uso, especialmente en las redes que no soportan la difusión de mensajes. Al igual que en IPv4, el protocolo se encarga de construir tablas de correspondencia entre las direcciones IPv6 y las físicas.
* <div vecinos id="NUD"> Detección de inaccesibilidad de vecinos (NUD, ''Neighbor Unreachability Detection''). Esta función, que no existe en IPv4, permite eliminar de las tablas de configuración de un equipo, los vecinos que se han vuelto inaccesibles (por fallas, cambio de domicilio, ...). Si un enrutador deja de estar disponible, la tabla de enrutamiento puede ser modificada para considerar otra ruta. </div>
* Configuración. La configuración automática de los dispositivos es uno de los principales atractivos de IPv6. Se implementan varias funcionalidades del protocolo de descubrimiento de vecinos:
**Descubrimiento de enrutadores. Este protocolo permite que los dispositivos identifiquen a los enrutadores que se encuentran en su enlace físico. En IPv4, esta función la proporciona el protocolo ''ICMP Router Discovery''.
** Descubrimiento de prefijos. El dispositivo conoce el o los prefijos de red de acuerdo a los anuncios realizados por los enrutadores. Agregando su identificador de interfaz, el dispositivo construye su o sus direcciones IPv6. No hay un mecanismo equivalente para las direcciones IPv4 ya que son demasiado cortas para realizar la auto-configuración.
** Detección de direcciones duplicadas. Dado que las direcciones se configuran de forma automática, existen riesgos de error en caso de tener equipos con identificadores repetidos. Este protocolo verifica que ningún otro equipo en el enlace tiene la misma dirección IPv6. Esta función es una evolución del ARP gratuito en IPv4 emitido durante la inicialización de la interfaz.
** Descubrimiento de parámetros. Este protocolo permite que los dispositivos conozcan los distintos parámetros del enlace físico, por ejemplo, el tamaño de MTU, el número máximo de saltos permitido (valor original del campo número de saltos), si la configuración automática con estado (como [[Configuración con estado: DHCPv6|DHCPv6]]) está activa, etc. No existe un equivalente de esta funcionalidad en IPv4.
* Indicación de redirección. Este mensaje se utiliza cuando un enrutador conoce una trayectoria mejor (medida en número de saltos) para alcanzar un destino.
:En IPv4 una indicación de redireccionamiento sólo puede servir para corregir la dirección del enrutador utilizado para acceder a una máquina fuera de la red local. Los dispositivos deben conocer todas las direcciones correspondientes a equipos conectados en su propia red local.
:EnIPv6, la correspondencia entre prefijo y red local es menos rígida. Es de esperar que un dispositivo no conozca todos los prefijos de su red local (si ésta es compartida por varios prefijos), o que un prefijo se comparta entre varios enlaces (lo que corresponde a una generalización del modelo de redes lógicas IP sobre ATM). Bajo algunas configuraciones, la máquina emitirá sus paquetes al enrutador aún si el destinatario se encuentra en el mismo segmento que el emisor. En este caso, el enrutador emitirá un mensaje de redirección para que la continuación del diálogo entre ellos haga de manera directa (véanse los ejemplos [[#IR|Indicación redirección]]).
:En el caso más extremo, podría imaginarse en IPv6 que un dispositivo puede ser configurado para comunicarse únicamente con su enrutador por omisión. ICMPv6 ''redirect'' puede utilizarse entonces, para informar al dispositivo de destinatarios ubicados en el mismo enlace.

En IPv6 se especifican dos métodos de autoconfiguración para las direcciones unicast global:

* Autoconfiguración sin estado (''stateless autoconfiguration'', RFC 2462). Se utiliza cuando no es necesaria una gestión administrativa de las direcciones asignadas dentro de un sitio. Estos mecanismos se describen más adelante en este capítulo.
* Autoconfiguración con estado (''statefull autoconfiguration''). Se utiliza cuando un sitio requiere de un control estricto de la asignación de direcciones (''cf'' [[Configuración con estado: DHCPv6 | DHCPv6]]).

Sin embargo, el uso de DHCPv6 para obtener la dirección se controla mediante el protocolo de descubrimiento de vecinos.

= Datos transmitidos por los mensajes =

La principal motivación detrás del Protocolo de Descubrimiento de vecinos es unificar varios protocolos existentes en IPv4. En particular, la mayor parte de los datos utiliza un formato de opciones común, lo que simplifica la implementación del protocolo. El formato contiene los campos: tipo, longitud (en palabras de 64 bits), y datos. La baja precisión de campo longitud, presentará un desperdicio de espacio, pero permite una alineación de las opciones en palabras de 64 bits, lo que permite un procesamiento optimizado.

{{NB-Opciones}}

== <div id="física">Dirección física de la fuente/destino</div> ==

<tikz title="Formato de la opción dirección física fuente/destino">
\clip (0.2, 5.7) rectangle (11.1,6.7);
% \draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=1/2}};
\draw (2.9, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{lenght }};
\draw (5.3, 6) node (addr) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Link Layer Address}};

\draw [draw=white, thick] (addr.north east) -- (addr.south east);
\draw [draw=white, thick] (addr.north east) -- +(-2, 0);
\draw [draw=white, thick] (addr.south east) -- +(-2, 0);

\draw [dashed] (addr.north east) -- (addr.south east);
\draw [dashed] (addr.north east) -- +(-2, 0);
\draw [dashed] (addr.south east) -- +(-2, 0);
</tikz>

La figura ''Formato de la opción dirección física fuente/destino'' presenta estas opciones. El tipo 1 designa la dirección física de la fuente y el tipo 2 la dirección del destino.

El campo ''length'' es el tamaño en palabras de 64 bits de la opción. Por lo tanto, para el caso de una dirección MAC con longitud de 6 octetos, contiene el valor 1.

El RFC 2464 define el formato para las direcciones MAC-48 utilizadas en las redes Ethernet y Wi-Fi. El RFC 4944 define el formato para las direcciones MAC-16 y MAC-64 utilizadas en las redes de sensores bajo la norma IEEE 802.15.4.

== <div id="información">Información sobre el prefijo</div> ==

<tikz title="Formato de la opción información sobre el prefijo">
\clip (0.2, 2) rectangle (11.1, 7);
% \draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=3}};
\draw (2.9, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{length =4 }};
\draw (5.3, 6) node (addr) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm] {\tiny{Prefix Length}};
\draw (7.7, 6) node (bitL) [right, shade, top color=blue!15, bottom color=blue!5,, draw, minimum height=0.5cm, minimum width=.3cm]{}; \draw (bitL.text) node {\tiny{L}};
\draw (8, 6) node (bitA) [right, shade, top color=blue!15, bottom color=blue!5,, draw, minimum height=0.5cm, minimum width=.3cm]{};\draw (bitA.text) node {\tiny{A}};
\draw (8.3, 6) node (bitR) [right, shade, top color=blue!15, bottom color=blue!5,, draw, minimum height=0.5cm, minimum width=.3cm]{};\draw (bitR.text) node {\tiny{R}};
\draw (8.6, 6) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=1.5cm] {\tiny{Reserved}};

\draw (0.5, 5.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Valid Lifetime}};

\draw (0.5, 5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Prefered Lifetime}};

\draw (0.5, 4.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Reserved}};

\draw (0.5, 4) node (addr1) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{}};
\draw (0.5, 3.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{}};
\draw (0.5, 3) node (addr3) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Prefix}};
\draw (0.5, 2.5) node (addr4) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{}};

\draw [color=blue!10, very thick] (addr1.south east) -- (addr1.south west);
\draw [color=blue!10, very thick] (addr2.south east) -- (addr2.south west);
\draw [color=blue!10, very thick] (addr3.south east) -- (addr3.south west);
</tikz>

Esta opción contiene las informaciones sobre el prefijo para permitir una configuración automática de los dispositivos. El campo tipo tiene el valor 3 y el de longitud, 4. La figura ''Formato de la opción información sobre el prefijo'' muestra el formato de esta opción:

* El campo ''Prefix lenght'' indica cuántos bits son significativos para el prefijo anunciado en un campo siguiente.
* El bit <tt>L</tt> indica, cuando vale 1, que el prefijo permite indicar que todos los demás dispositivos que comparten el mismo prefijo, están en el mismo enlace, por lo que el emisor puede contactarlos directamente. En caso contrario, el dispositivo envía el paquete hacia el enrutador. Si éste último sabe que el emisor puede contactar directamente al destinatario, emitirá un mensaje ICMPv6 de indicación de redirección.
* El bit <tt>A</tt> indica, cuando vale 1, que el prefijo anunciado puede utilizarse para formar la dirección del dispositivo.
* El bit <tt>R</tt>, indica, cuando vale 1, que el campo prefijo contiene la dirección global de un enrutador ''agente base''. Los bits de mayor peso aún pueden utilizarse para formar un prefijo.
* El campo duración de validez indica, en segundos, la duración durante la cual el prefijo es válido.
* El campo duración preferente indica la duración, en segundos, durante la cual una dirección formada con el protocolo de configuración sin estado se mantiene ''preferente'' (''cf'' [[Planes de direccionamiento|Tiempo de vida de las direcciones]]).

Para estos dos campos, un valor de <tt>0xffffffff</tt> representa una duración infinita. Estos campos pueden servir durante la fase de transición de un proveedor de acceso a otro; es decir, de un prefijo a otro.
* El campo reservado permite alinear el prefijo a una frontera de palabra de 64 bits.
* El campo prefijo contiene el valor de prefijo anunciado sobre el enlace. Para mantener una alineación de 64 bits para el resto de datos del paquete, este campo tiene una longitud fija de 128 bits.

== <div id="redirigida">Cabecera de redirección </div> ==

<tikz title="Formato de la opción cabecera de redirección">
\clip (0.2, 3.1) rectangle (11.1, 7);
% \draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=5}};
\draw (2.9, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{length =1 }};
\draw (5.3, 6) node (addr) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Reserved}};

\draw (0.5, 5.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Reserved}};

\draw (0.5, 4.25) node (context) [right, shade, top color=purple!50, bottom color=purple!10, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{IPv6 Header and Data}};
</tikz>

Esta opción es utilizada por el mensaje de indicación de redirección. Permite encapsular los primeros octetos del paquete IPv6 que provocó la emisión de este mensaje, como ocurre con los mensajes de error de ICMPv6.

El campo tipo tiene el valor 4. El tamaño de esta opción debe evitar que el paquete IPv6 rebase los 1280 octetos (''cf'' figura ''Formato de la opción cabecera de redirección''). Sin embargo, el paquete debe contener la mayor cantidad de información posible.

== <div id="MTU">MTU</div> ==

<tikz title="Formato de la opción MTU">

\clip (0.2, 5.1) rectangle (11.1, 7);
% \draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=5}};
\draw (2.9, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{lenght =1 }};
\draw (5.3, 6) node (addr) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Reserved}};

\draw (0.5, 5.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{MTU}};
</tikz>

Esta opción permite notificar a los dispositivos el tamaño máximo de datos que pueden ser transmitidos sobre el enlace. La figura ''Formato de la opción MTU'' muestra su estructura. No es necesario difundir esta información si el dispositivo utiliza siempre el tamaño máximo permitido. Por ejemplo, sobre las redes Ethernet, los dispositivos utilizarán el valor 1,500. En cambio, en las redes Token Ring o FDDI, con frecuencia es necesario especificar si los equipos pueden utilizar la longitud máxima o un tamaño inferior para permitir el uso de puentes en la red.

En esta opción, el campo tipo tiene un valor de 5 y el de longitud, de 1.

=Mensajes estándar de Descubrimiento de vecinos =

Además de las cinco opciones básicas descritas en la tabla ''Utilización de las opciones en los mensajes de descubrimiento de vecinos'', existen otras específicas para la movilidad y para las redes NBMA (''Non Broadcast Multiple Access'').

{|
|+ Utilización de las opciones en los mensajes de descubrimiento de vecinos
| width = 150 | || width = 100 |[[#RS|Solicitud de]] || width = 100 |[[#RA|Anuncio de]] || width = 100 |[[#NS|Solicitud de]] ||width = 100 | [[#NA|Anuncio de]] ||width = 100 |[[#IR|Indicación de]]
|-
| || [[#RS|enrutador]] || [[#RA|enrutador]] || [[#NS|un vecino]] || [[#NA| un vecino]] || [[#IR|redirección]]
|-style="background:silver"
|[[#física |Dirección física de la fuente]] || presente || presente || presente || ||
|-
|[[# física | Dirección física del destino]] || || || || presente || presente
|-style="background:silver"
|[[#información|Información sobre el prefijo]] || || ≥ 1 || || ||
|-
|[[#redirigida |Cabecera de redirección]] || || || || || presente
|-style="background:silver"
| [[#MTU |MTU]] || || posible || || ||
|}

Las distintas funcionalidades de descubrimiento de vecinos utilizan cinco mensajes: dos para el diálogo entre un dispositivo y un enrutador, dos para el diálogo entre vecinos, y uno para la redirección. Cada uno de estos mensajes puede incluir opciones adicionales.

== <div id="RS">Solicitud de enrutador</div> ==

<tikz title="Formato de los paquetes de solicitud de enrutador">
\clip (0.2, 3.5) rectangle (11.1,7.1);
%\draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=133}};
\draw (2.9, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code =0 }};
\draw (5.3, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};
\draw (0.5, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Reserved}};

\draw (0.5, 4.25) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Options:\\
- Source link-layer address
}};
</tikz>

El mensaje de solicitud de enrutador (''cf'' figura Formato de los paquetes de solicitud de enrutador) es emitido al iniciar un dispositivo para recibir más rápidamente la información del enrutador. Este mensaje se envía a la dirección IPv6 multicast reservada a los enrutadores en el mismo enlace <tt>FF02::2</tt>. Si el dispositivo aún no conoce su dirección fuente, se utiliza la dirección no especificada.

El campo opción normalmente contiene la dirección física del dispositivo.

== <div id="RA">Anuncio de enrutador</div> ==

<tikz title="Formato de los paquetes de anuncio de enrutador">
\clip (0.2, 1.5) rectangle (11.1,7.1);
%\draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=134}};
\draw (2.9, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code =0 }};
\draw (5.3, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};

\draw (0.5, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Cur. Hop Lim.}};
\draw (2.9, 5.5) node (bitM) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{}; \draw (bitM.text) node {\tiny{M}};
\draw (3.2, 5.5) node (bitO) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{};\draw (bitO.text) node {\tiny{O}};
\draw (3.5, 5.5) node (bitH) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{};\draw (bitH.text) node {\tiny{H}};
\draw (3.8, 5.5) node (res) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=1.5cm]{\tiny{reserved}};
\draw (5.3, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Router Lifetime}};

\draw (0.5, 5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=9.6cm]{\tiny{Reachable Time}};
\draw (0.5, 4.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=9.6cm]{\tiny{Retrans Time}};

\draw (0.5, 3.25) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Options:\\
Source link-layer address\\
MTU\\
Prefix Information (may be repeated)\\
}};
</tikz>

Este mensaje (''cf'' figura ''Formato de los paquetes de anuncio de enrutador'') es emitido periódicamente por los enrutadores, o bien, en respuesta a un mensaje de solicitud de enrutador generado por un dispositivo. El campo dirección fuente contiene la dirección de enlace local del enrutador, mientras que el campo dirección destino contiene la dirección del dispositivo que generó la solicitud, o la dirección de todas las estaciones (<tt>ff02::01</tt>).

Cuando el campo de máximo número de saltos tiene un valor distinto de cero, muestra el valor que podría colocarse en el campo de número de saltos de los paquetes emitidos. El bit <tt>M</tt> indica que una dirección del dispositivo debe ser obtenida mediante un protocolo de configuración (''cf'' [[Configuración con estado:DHCPv6]]). El bit <tt>O</tt> también indica la presencia de un servicio de configuración para obtener información adicional a la dirección. Si no es posible obtener la dirección mediante un servidor, el dispositivo procede a realizar una configuración sin estado, concatenando su identificador de interfaz a los prefijos que conoce. El bit <tt>H</tt> indica que el enrutador puede ser utilizado como agente base por un nodo móvil (''cf'' [[Desplazamientos_de_móviles#Anuncio_del_agente_base |Anuncio del agente base]]).

El campo tiempo de vida del enrutador indica el período (en segundos) durante el cual el equipo que emite el anuncio realizará funciones de enrutador por omisión. El valor máximo corresponde a 18 horas 12 minutos, pero como este mensaje se emite periódicamente, en la práctica no existe un límite para el tiempo de vida de un enrutador. Un valor de <tt>0</tt> indica que el dispositivo no cumple con las funciones de enrutador por omisión. Este tiempo de vida no se aplica a las opciones transportadas por este mensaje.

El campo duración de accesibilidad indica el período (en milisegundos) durante el cual una información almacenada en la memoria caché de la máquina (por ejemplo, la tabla de correspondencia entre las direcciones IPv6 y las físicas) puede ser considerada como válida. Al vencimiento de este tiempo, se emite un mensaje de detección de inaccesibilidad para verificar la pertinencia de la información almacenada.

El campo temporización de retransmisión muestra el período (en milisegundos) entre dos emisiones no solicitadas de este mensaje. Permite que los demás equipos puedan detectar la inaccesibilidad de un enrutador.

Este mensaje puede transportar las siguientes opciones:

* dirección física de la fuente,
* MTU,
* información sobre el prefijo (uno o varios).

== <div Id="NS"> Solicitud de un vecino </div> ==

<tikz title="Formato de los paquetes de solicitud de un vecino">

\clip (0.2, 1.5) rectangle (11.1,7.1);
%\draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=135}};
\draw (2.9, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code =0 }};
\draw (5.3, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};

\draw (0.5, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=9.6cm]{\tiny{Reserved}};

\draw (0.5, 4.25) node (context) [right, shade, top color=blue!50, bottom color=blue=!10, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Target Address}};

\draw (0.5, 2.25) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Options:\\
Source link-layer address\\
}};
</tikz>

Este mensaje (''cf'' figura ''Formato de los paquetes de solicitud de un vecino'') permite obtener información a partir de un equipo vecino, es decir, localizado en el mismo enlace físico (o conectado a través de puentes). El mensaje puede ser emitido explícitamente a él, o enviado con una dirección de difusión. En el caso de determinación de la dirección física, éste corresponde a la solicitud de ARP en IPv4.

El campo dirección fuente del paquete IPv6 contiene ya sea la dirección local al enlace, una dirección global o la dirección no especificada. El campo destino puede contener la dirección de difusión múltiple solicitada correspondiente a la dirección buscada (''cf'' [[Direccionamiento_multicast#Identificador_de_grupo|Identificador de grupo]]) o la dirección del dispositivo (en el caso de una detección de inaccesibilidad de vecinos, ''NUD'').

El campo dirección del destino contiene la dirección IPv6 del equipo buscado. El campo opción generalmente contiene la dirección física de la fuente.

== <div Id="NA"> Anuncio de un vecino</div> ==

<tikz title="Formato de los paquetes de anuncio de un vecino">

\clip (0.2, 1.5) rectangle (11.1,7.1);
%\draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=136}};
\draw (2.9, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code =0 }};
\draw (5.3, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};

\draw (0.5, 5.5) node (bitR) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{}; \draw (bitR.text) node {\tiny{R}};
\draw (0.8, 5.5) node (bitS) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{}; \draw (bitS.text) node {\tiny{S}};
\draw (1.1, 5.5) node (bitO) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{}; \draw (bitO.text) node {\tiny{O}};
\draw (1.4, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=8.7cm]{\tiny{Reserved}};

\draw (0.5, 4.25) node (context) [right, shade, top color=blue!50, bottom color=blue=!10, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Target Address}};

\draw (0.5, 2.25) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Options:\\
Source link-layer address\\
}};
</tikz>

Este mensaje (''cf'' figura ''Formato de los paquetes de anuncio de un vecino'') se emite en respuesta a una solicitud, aunque también puede ser emitido de forma espontánea para propagar la información de cambio de dirección física, o del estado de "enrutador". Para el caso de la determinación de la dirección física, es equivalente a la respuesta ARP en IPv4.

* El bit <tt> R </tt> se pone a 1 si el remitente es un enrutador. Este bit se utiliza para permitir la detección de un enrutador que se convierte en un equipo ordinario.
* El bit <tt> S </tt> en 1 indica que este anuncio se emite en respuesta a una solicitud.
* El bit <tt> O </tt> en 1 indica que este anuncio debe borrar las informaciones anteriores que se encuentran almacenadas en la memoria cachés de otros equipos, en especial la tabla que contiene las direcciones físicas.
* El campo dirección del destino contiene, si el bit<tt> S </tt> es 1, el valor del campo dirección del destino de la solicitud a la que está respondiendo este mensaje. Si el bit <tt> S </tt> es 0, este campo contiene la dirección IPv6 local al enlace del equipo emisor.
* La opción dirección física del destino contiene la dirección física del emisor.

== <div id="IR">Indicación de redirección</div> ==

<tikz title="Formato de los paquetes de indicación de redirección">
\clip (0.2, 0) rectangle (11.1,7.1);
%\draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=137}};
\draw (2.9, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code =0 }};
\draw (5.3, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};

\draw (0.5, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=9.6cm]{\tiny{Reserved}};

\draw (0.5, 4.25) node (context) [right, shade, top color=blue!50, bottom color=blue=!10, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Target Address}};

\draw (0.5, 2.25) node (context) [right, shade, top color=blue!50, bottom color=blue=!10, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Destination Address}};

\draw (0.5, 0.5) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=1.5cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Options:\\
Target link-layer address\\
Redirected Header\\
}};
</tikz>

La técnica de redirección es la misma que en IPv4. Un dispositivo sólo conoce los prefijos de las redes a las que está conectado directamente y la dirección de un enrutador por omisión. Si la ruta se puede optimizar, el enrutador por omisión envía un mensaje para indicar que existe un camino más corto. De hecho, como en IPv6 el enrutador por omisión se establece de forma automática, las rutas no necesariamente son las mejores (''cf'' figura ''Enrutamiento por omisión no óptimo'').

Otro caso particular en IPv6 ocurre con los dispositivos que se encuentran en el mismo enlace físico, pero tienen diferentes prefijos. La comunicación entre ellos pasa inicialmente a traves de enrutador por omisión hasta que éste notifica que existe una ruta directa entre ellos.

La figura ''Formato de los paquetes de indicación de redirección'' muestra el formato del mensaje:

* El campo dirección objetivo (''Target address'') contiene la dirección IPv6 del equipo hacia el que los paquetes deben ser enviados.
* El campo dirección destino contiene la dirección IPv6 del dispositivo que está siendo redirigido hacia la dirección objetivo.

Cuando la redirección apunta a un dispositivo situado en el mismo enlace, la dirección objetivo y de destino son las mismas.

Las opciones incluyen la dirección física de un nuevo enrutador y la cabecera del paquete redirigido.

Este mensaje se puede utilizar de la misma forma que en IPv4. Un dispositivo solamente tiene una ruta por omisión para acceder a equipos con un prefijo diferente. En consecuencia, envía su paquete al enrutador por omisión, quien observa que el prefijo destino es accesible a través de la misma subred que el emisor. El enrutador por omisión reenvía el paquete y notifica al emisor que puede contactar directamente a las máquinas que poseen el prefijo del destino.

IPv6 también utiliza este mensaje para optimizar la resolución fuera del enlace para el [[#Caso de redes NBMA |caso de redes NBMA]].

= Configuración automática =
Tradicionalmente, la configuración de una interfaz de red de una máquina se hacía manualmente. Esto suele ser un trabajo lento y propenso a errores. Con IPv6, se automatiza el proceso de configuración y se introducen, al mismo tiempo, mecanismos de funcionamiento inmediato (''plug and play'') a la interfaz de red. La configuración automática significa que un dispositivo obtendrá toda la información necesaria para su conexión a una red local IP sin ninguna intervención humana. En el caso ideal, cualquier usuario desempaca su nuevo equipo, lo conecta a la red local y lo ve funcionar sin tener que introducir la información propia de "especialistas". Ahora vamos a discutir otro aspecto de la configuración automática de IPv6, la auto-configuración de direcciones, que tiene como objetivos:

* La adquisición de una dirección cuando un dispositivo está conectado a una red por primera vez;
* la posibilidad de asignar otros prefijos, o de renumerar un dispositivo.

El proceso de configuración automática de direcciones IPv6 incluye la creación de una dirección local al enlace, la agregación a grupos multicast solicitados, la verificación de la unicidad de la dirección local al enlace y la creación de direcciones unicast global.

La tarea del enrutador es importante en la configuración automática. Indica a la máquina, mediante los bits de la cabecera (''cf'' [[#RA|anuncio de enrutador]]), del mensaje de anuncio de los enrutadores, el método a conservar y eventualmente proporcionar la información necesaria para su configuración. El bit <tt> M </tt> (''configuración de dirección administrada'') puesto a 1 indica que el equipo no debe crear por sí mismo una dirección a partir de su identificador de interfaz y de los prefijos recibidos, sino que debe solicitarla explícitamente ante un servidor de direcciones. El bit O <tt> </tt> (''otra configuración de estado'') indica que el dispositivo debe consultar el servidor para obtener otros parámetros distintos de la dirección. El algoritmo para el proceso de configuración automática de direcciones se desglosa de la siguiente manera:

* La primera fase consiste en crear la dirección local al enlace.
* Una vez que la unicidad de esta dirección es verificada, el dispositivo está listo para comunicarse con otras máquinas en el enlace.
* El dispositivo debe tratar de adquirir un mensaje de anuncio de enrutadores para determinar el método de obtención de la dirección unicast global.
* Si hay un enrutador en el enlace, el dispositivo debe aplicar el método especificado por el mensaje de anuncio de enrutadores, a saber:
** La configuración automática sin estado,
** la configuración automática con estado.
* Si no hay ningún enrutador en el enlace, el dispositivo debe tratar de obtener la dirección unicast global por el método de configuración automática con estado. Si el intento falla, no hay más que hacer. Las comunicaciones sólo podrán hacerse sobre el enlace con la dirección local al enlace, pues el dispositivo no tendrá una dirección con la cobertura necesaria que le permita comunicarse con otras máquinas fuera del enlace.

==Ciclo de vida de una dirección==

Al generalizar en IPv6 el plan de direccionamiento CIDR, los prefijos quedan, en todos los casos, siendo propiedad de los operadores. Ya no pueden otorgarse "a perpetuidad" a los dispositivos. Para facilitar la renumeración de una máquina, la asignación de una dirección a una interfaz es temporal, las direcciones IPv6 no se entregan, sino que se prestan. Se asocia un tiempo de vida a la dirección, que indica el tiempo durante el cual la dirección pertenece a la interfaz. Cuando el tiempo de vida se ha agotada, la dirección deja de ser válida, se suprime de la interfaz y queda potencialmente éste puede prolongarse indefinidamente. La dirección local al enlace tiene un tiempo de vida ilimitado.

<tikz title="Estados sucesivos de una dirección en una interfaz">

\draw [thick, ->] (0,2) -- (9.5,2);

\draw [->] (1,4) node [above=10pt] {\tiny{allocation}}-- (1,2);
\draw (1, 2) node [rectangle, minimum width=1cm, minimum height=1cm, fill, left color=black!10, right color=black!20, draw=black, above right] (tentative) {};
\draw (tentative.south east) node [rectangle, minimum width=3cm, minimum height=1cm, fill, left color=green, right color=green!50, draw=black, above right] (preferred) {};
\draw (preferred.south east) node [rectangle, minimum width=2cm, minimum height=1cm, fill, left color=orange , right color=orange!50!red, draw=black, above right] (deprecated) {};
\draw (deprecated.south east) node [rectangle, minimum width=2cm, minimum height=1cm, fill, color=red, draw=black, above right] (novalid) {};

\draw (tentative.text) node {\tiny{Tentative}};
\draw (preferred.text) node {\tiny{Preferred}};
\draw (deprecated.text) node {\tiny{Deprecated}};
\draw (novalid.text) node {\tiny{Invalid}};

\draw [dotted] (tentative.south west) -- +(0, -1);
\draw [dotted] (preferred.south west) -- +(0, -1);
\draw [dotted] (deprecated.south west) -- +(0, -1);
\draw [dotted] (novalid.south west) -- +(0, -1);

\draw [dashed, <->] ([yshift=-0.5cm]tentative.south west) -- node [above] {\tiny{DAD}} ([yshift=-0.5cm] preferred.south west) ;

\draw [dashed, <->] ([yshift=-0.5cm]preferred.south west) -- node [above] {\tiny{Valid}} ([yshift=-0.5cm] novalid.south west) ;

</tikz>

La renumeración de una interfaz consiste en pasar de una dirección a otra. Durante una renumeración, no es aconsejable cambiar repentinamente de dirección, de lo contrario, todas las comunicaciones TCP que la utilizan como identificador de conexión, se cortarían inmediatamente. Esto conllevaría importantes perturbaciones a nivel de las aplicaciones.

Por ello, para facilitar esta transición se implementó un mecanismo de obsolescencia que invalida gradualmente una dirección. Este mecanismo se sirve de la capacidad de asignación de varias direcciones válidas a una misma interfaz. Para elegir la dirección a utilizar, se le asocia un estado que indica en qué fase de su tiempo de vida se encuentra con respecto a la interfaz. El primero de esos estados se conoce como preferido: no hay ninguna restricción de uso. Poco antes de su invalidación, la dirección pasa a un estado de depreciado. En él se desaconseja el uso de la dirección, pero no está prohibido. Una dirección depreciada ya no debe ser utilizada como dirección fuente de nuevas comunicaciones (como el establecimiento de conexión TCP), pero todavía puede emplearse como dirección fuente de comunicaciones ya establecidas. Los paquetes recibidos a una dirección depreciada seguirán siendo entregados normalmente. El control de la duración de cada estad de una dirección válida se efectúa agregando un tiempo de vida al estado preferido.
La figura '''Estados sucesivos de una dirección en una interfaz''' representa los diferentes estados que toma una dirección cuando se asigna a una interfaz.

== Creación de la dirección local al enlace ==

<tikz title=" Creación de la dirección local al enlace">
\clip (0, 0) rectangle (10,7);
% \draw[help lines] (0,0) grid (10,7 );

\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,3)--(9,3);

\pgfputat{\pgfxy(0.8,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,5)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,3)--(1.5,5);
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (8,3)--(8,5);

\draw (1.5,4.5) node {\small{FE80::IID1}};
\draw (1.5,4) node {\small{$\alpha$::IID1/64}};

\draw (8, 4.5) node {\small{FE80::IID2}};

</tikz>

Durante la inicialización de la interfaz, el dispositivo construye un identificador de interfaz que debe ser único en el enlace. Este identificador se utiliza la dirección de [[ Identificador_de_interfaz#EUI-64 | EUI-64]]. El principio básico para crear la direcciónIPv6 consiste en unir un prefijo con el identificador. La dirección local al enlace se crea tomando el prefijo de Enlace_local (<tt>FE80::/64</tt>). La dirección creada de esa manera, todavía no puede ser utilizada; tiene un estado temporal pues el dispositivo debe comprobar la exclusividad de esta dirección en el enlace mediante el procedimiento de detección de direcciones duplicadas. Si se encuentra que la dirección local al enlace no es única, se suspende la autoconfiguración y será necesario proceder a una configuración manual.

Una vez que se ha asegurado la unicidad de la dirección local al enlace, ésta se considera una dirección válida para la interfaz, con lo que termina la prima fase del proceso de autoconfiguración.

==<div id="DAD"> Detección de una dirección duplicada </div>==

<tikz title="Emisión de un NS en una detección de Dir. duplicada (DAD)">
\clip (0, 0) rectangle (10,7);
% \draw[help lines] (0,0) grid (10,7 );

\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,3)--(9,3);

\pgfputat{\pgfxy(0.8,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,5)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,3)--(1.5,5);
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (8,3)--(8,5);

\draw (7.8, 5) -- (7.8, 3.2);
\draw [<->] (1, 3.2) -- node [above] {\tiny{::/0 -$>$ solicited (FE80:IID2) : NS (who has FE80::IID2?)}}(9, 3.2) ;

</tikz>

Para comprobar la exclusividad de direcciones locales al enlace o de direcciones unicast, los dispositivos deben ejecutar un algoritmo de detección de direcciones duplicadas (DAD) antes poder utilizarlas. El algoritmo usa los mensajes ICMPv6 [[Protocolo_de_Descubrimiento_de_vecinos#NS|solicitud de un vecino]] y [[#NA|anuncio de un vecino.]] Si se detecta una dirección que ya está en uso, ésta no podrá ser asignada a la interfaz, la autoconfiguración automática debe suspenderse y será necesario proceder a una configuración manual. Durante la ejecución del algoritmo DAD, la dirección es considerada como "provisional" hasta tener la confirmación de su unicidad. Una dirección provisional se asigna a una interfaz únicamente para recibir los mensajes de solicitud y anuncio de un vecino. Otros mensajes recibidos, son ignorados. El algoritmo DAD consiste en enviar un mensaje de solicitud de un vecino colocando en el campo de dirección objetivo la dirección provisional. Para distinguir el algoritmo DAD del de Descubrimiento de vecinos, el paquete IPv6 que contiene un mensaje de solicitud de un vecino tiene como dirección fuente una dirección no determinada. Así se presentan tres casos:

* Se recibe un mensaje de anucio de un vecino: Significa que la dirección provisional está siendo utilizada como válida por otro dispositivo, por lo que ésta no es única y no puede ser retenida por el dispositivo.
* Se recibe un mensaje de solicitud de un vecino como parte del algoritmo DAD. La dirección provisional también es provisional para otra máquina. En este caso, la dirección provisional no puede ser utilizada por ninguna de ellas.
* No se recibe ningún mensaje durante un segundo (valor por omisión). La dirección provisional es única, por lo que su estado pasa de provisional a válida y se le asigna a la interfaz.

Obsérvese que este algoritmo no proporciona una fiabilidad absoluta, especialmente cuando el enlace está segmentado.

== Autoconfiguración sin estado ==

<tikz title="Emisión de un RS">
\clip (0, 0) rectangle (10,7);
% \draw[help lines] (0,0) grid (10,7 );

\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,3)--(9,3);

\pgfputat{\pgfxy(0.8,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,5)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,3)--(1.5,5);
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (8,3)--(8,5);

\draw (7.8, 5) -- (7.8, 3.2);
\draw [<->] (1, 3.2) -- node [above] {\tiny{FE80::IID2 -$>$ FF02::2 : RS }} (9, 3.2) ;

</tikz>

La configuración automática sin estado (RFC 2462) no requiere de ninguna configuración manual de los dispositivos, una configuración mínima para los enrutadores, y tampoco necesita de servidores adicionales. Se sirve del protocolo ICMPv6 y puede operar aún sin la presencia de enrutadores. En cambio, sí requiere de una subred con soporte a la difusión de paquetes. Este método sólo aplica para los dispositivos; no puede ser utilizada para configurar enrutadores. El principio básico de este mecanismo consiste en que una máquina genera su dirección IPv6 a partir de información local y de la proporcionada por un enrutador. El enrutador proporciona información sobre la subred asociada al enlace; anuncia el prefijo.

<tikz title="Recepción de un RA">
\clip (0, 0) rectangle (10,7);
% \draw[help lines] (0,0) grid (10,7 );

\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,3)--(9,3);

\pgfputat{\pgfxy(0.8,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,5)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,3)--(1.5,5);
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (8,3)--(8,5);

\draw [->] (1.7,5) -- (1.7, 3.2) -- node [above = 10pt] {\tiny{FE80::IID1 -$>$ FE80::IID2}} node [above] {\tiny{RA ($\alpha$::/64, DHCPv6, MTU=1500, HL=64, {bit {\tt M=1}) }}} (7.8, 3.2) -- (7.8, 5);

</tikz>

Al igual que para la creación de la dirección de enlace local, la dirección unicast global se obtiene al concatenar el prefijo con el identificador de la interfaz. El prefijo se obtiene del mensaje de anuncio de enrutador, más concretamente, de la opción de ''información sobre el prefijo''. Si bien debe verificarse la unicidad de todas las direcciones unicast, en el caso de una dirección unicast obtenida mediante la configuración automática sin estado, esto no es obligatorio, pues la unicidad del identificador de la interfaz ya fue comprobada durante la configuración de la dirección local al enlace. Dado que el identificador es el mismo, no puede haber ambigüedad sobre la exclusividad de la dirección unicast global creada de esta forma.

La renumeración de los dispositivos en un enlace se realiza mediante enrutadores que transfieren las direcciones utilizadas a un estado depreciado y al mismo tiempo anuncian el nuevo prefijo con el que los dispositivos pueden re-crear una dirección preferida.

===Caso de redes NBMA ===

<tikz title="Off Link NDP: Primera etapa">
\clip (0, 0) rectangle (11,7);
% \draw[help lines] (0,0) grid (10,7 );

\pgfputat{\pgfxy(4.5,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}
\pgfputat{\pgfxy(1.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[decorate,decoration={zigzag}, color=black!60, ->, very thick] (8,3)-- node [above, color=black] {\tiny{FE80::IID2 -$>$ FF02::2 : RS}} (5,5);

</tikz>

Las redes NBMA (''Non Broadcast Multiple Access'') se caracterizan por no contar con un mecanismo de difusión hacia todos los dispositivos. Esto conduce a dos situiaciones posibles:
* ausencia total de difusión, como en las redes públicas (telefónica, ATM, …) en las que un solo destinatario puede ser contactado a la vez
* posibilidad de difusión por un número limitado de equipos, como es el caso de las redes de radio tipo 3G, WiMAX, en las que la estación base tiene la posibilidad de difundir datos hacia todos los equipos, pero esto no es posible en el sentido inverso (desde un dispositivo).

<tikz title="Off Link NDP: Segunda etapa">
\clip (0, 0) rectangle (11,7);
% \draw[help lines] (0,0) grid (10,7 );

\pgfputat{\pgfxy(4.5,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}
\pgfputat{\pgfxy(1.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[decorate,decoration={zigzag}, color=black!60, ->, very thick] (5, 5)-- node [above, color=black] {\tiny{RA ($\alpha$::/64, DHCPv6, OffLink, MTU=1500, HL=64, {bit {\tt M=1}})}} (8,3);

</tikz>

Un comportamiento de redes NBMA también puede ser deseable para limitar las restricciones de consumo energético. Por ejemplo, en el caso de redes de sensores, la difusión, o la difusión restringida (multicast) son costosas en consumo de energía pues todos los dispositivos deben procesar el mensaje y algunos deberán retransmitirlo.

<tikz title="Off Link NDP: Tercera etapa">
\clip (0, 0) rectangle (11,7);
% \draw[help lines] (0,0) grid (10,7 );

\pgfputat{\pgfxy(4.5,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}
\pgfputat{\pgfxy(1.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[decorate,decoration={zigzag}, color=black!60, ->, very thick] (8,3)-- node [left, near start, color=black] {\tiny{$\alpha$::IID2 -$>$ $\alpha$::IID3 : DATA}} (5,5);

\draw[decorate,decoration={zigzag}, color=black!60, ->, very thick] (5,5)-- node [left, midway, color=black] {\tiny{$\alpha$::IID2 -$>$ $\alpha$::IID3 : DATA}} (2,3);

</tikz>

Para estos casos, el protocolo de descubrimiento de vecinos cuenta con un modo NBMA llamado también ''OffLink'', el cual solamente autoriza el diálogo con un enrutador. Los intercambios comienzan de la misma forma:
* El dispositivo que desea insertarse en la red, emite un mensaje RS ('' Router Sollicitation”) utilizando la dirección destino FF02::2 (todos los enrutadores sobre el enlace. La red NBMA deberá enviar este mensaje hacia un enrutador.
* El enrutador responde poniendo el bit <tt>L</tt> (OffLink) a 1 en la opción [[#información|Información sobre el prefijo]], indicando que todos los intercambios deben pasar por él.
* El dispositivo construye su dirección global concatenando el prefijo a su identificador de interfaz.
* El dispositivo envía sistemáticamente todos los paquetes a la dirección física del enrutador. Éste, que tiene una visión global de la red, los reenvía hacia el destinatario apropiado.

<tikz title="Off Link NDP: Cuarta etapa (opcional)">
\clip (0, 0) rectangle (11,7);
% \draw[help lines] (0,0) grid (10,7 );

\pgfputat{\pgfxy(4.5,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}
\pgfputat{\pgfxy(1.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[decorate,decoration={zigzag}, color=black!60, ->, very thick] (8,3)-- node [left, near end, color=black] {\tiny{$\alpha$::IID2 -$>$ $\alpha$::IID3 : DATA}} (5,5);

\draw[decorate,decoration={zigzag}, color=black!60, ->, very thick] (5,5)-- node [left, midway, color=black] {\tiny{$\alpha$::IID2 -$>$ $\alpha$::IID3 : DATA}} (2,3);

\draw[decorate,decoration={triangles}, color=black!60, ->, thick, ] (5,5) to [bend left] node [right, near start, color=black] {\tiny{REDIRECT $\alpha$::IID3 : MAC3}} (8,3);

\draw [color=black!60, ->, very thick, dotted] (8,3)-- node [above, midway, color=black] {\tiny{$\alpha$::IID2 -$>$ $\alpha$::IID3 : DATA}} (2,3);

</tikz>

* Si la tecnología de enlace lo permite y si la política de gestión de red lo autoriza, el enrutador tiene la posibilidad de optimizar el tráfico, notificando al dispositivo la verdadera dirección del destinatario, emitiendo un mensaje de [[#IR|indicación de redirección]] (''ICMP Redirect''). Los paquetes subsecuentes ya no pasarán por el enrutador.

{{eSuivi|Tabla de contenido|Incio del capítulo|DHCPv6|DHCPv6}}

Protocolo de Descubrimiento de vecinos

2012-07-04T22:08:06Z

Jincera: /* Detección de una dirección duplicada */

{{eSuivi|Tabla de contenido|Incio del capítulo|DHCPv6|DHCPv6}}

__TOC__

El protocolo de descubrimiento de vecinos (NDP, ''Neighbor Discovery Protocol'') permite a un dispositivo integrarse en el ambiente local, es decir, el enlace sobre el cual se transmiten físicamente los paquetes IPv6. Permite establecer un diálogo con los equipos (estaciones y enrutadores) conectados sobre el mismo medio. No se pretende que un dispositivo conozca con exactitud la lista de todos los demás dispositivos conectados al enlace, sino de proveer un mecanismo para dialogar con quien necesite hacerlo.

El protocolo utiliza cinco tipos de mensajes ICMPv6 (ver Valores de los campos de tipo y código de ICMPv6). El campo número de saltos de la cabecera IPv6 contiene el valor 255. Este valor parece demasiado grande para datagramas que no debieran ser enrutados fuera del enlace físico. En realidad, si un equipo recibe un datagrama con un valor menor, significa que la información proviene de otra red y que ya ha atravesado al menos un enrutador. Por ello, los datagramas que tienen un valor diferente de 255 deben ser ignorados por el receptor.

{{Tableau eICMPv6}}

El protocolo realiza varias funciones:

* Resolución de direcciones. El principio es muy similar al del protocolo ARP de IPv4. La principal diferencia consiste en el uso de mensajes ICMPv6 estándar en lugar de definir otro protocolo de capa 3. Con esto se consigue una mayor flexibilidad de uso, especialmente en las redes que no soportan la difusión de mensajes. Al igual que en IPv4, el protocolo se encarga de construir tablas de correspondencia entre las direcciones IPv6 y las físicas.
* <div vecinos id="NUD"> Detección de inaccesibilidad de vecinos (NUD, ''Neighbor Unreachability Detection''). Esta función, que no existe en IPv4, permite eliminar de las tablas de configuración de un equipo, los vecinos que se han vuelto inaccesibles (por fallas, cambio de domicilio, ...). Si un enrutador deja de estar disponible, la tabla de enrutamiento puede ser modificada para considerar otra ruta. </div>
* Configuración. La configuración automática de los dispositivos es uno de los principales atractivos de IPv6. Se implementan varias funcionalidades del protocolo de descubrimiento de vecinos:
**Descubrimiento de enrutadores. Este protocolo permite que los dispositivos identifiquen a los enrutadores que se encuentran en su enlace físico. En IPv4, esta función la proporciona el protocolo ''ICMP Router Discovery''.
** Descubrimiento de prefijos. El dispositivo conoce el o los prefijos de red de acuerdo a los anuncios realizados por los enrutadores. Agregando su identificador de interfaz, el dispositivo construye su o sus direcciones IPv6. No hay un mecanismo equivalente para las direcciones IPv4 ya que son demasiado cortas para realizar la auto-configuración.
** Detección de direcciones duplicadas. Dado que las direcciones se configuran de forma automática, existen riesgos de error en caso de tener equipos con identificadores repetidos. Este protocolo verifica que ningún otro equipo en el enlace tiene la misma dirección IPv6. Esta función es una evolución del ARP gratuito en IPv4 emitido durante la inicialización de la interfaz.
** Descubrimiento de parámetros. Este protocolo permite que los dispositivos conozcan los distintos parámetros del enlace físico, por ejemplo, el tamaño de MTU, el número máximo de saltos permitido (valor original del campo número de saltos), si la configuración automática con estado (como [[Configuración con estado: DHCPv6|DHCPv6]]) está activa, etc. No existe un equivalente de esta funcionalidad en IPv4.
* Indicación de redirección. Este mensaje se utiliza cuando un enrutador conoce una trayectoria mejor (medida en número de saltos) para alcanzar un destino.
:En IPv4 una indicación de redireccionamiento sólo puede servir para corregir la dirección del enrutador utilizado para acceder a una máquina fuera de la red local. Los dispositivos deben conocer todas las direcciones correspondientes a equipos conectados en su propia red local.
:EnIPv6, la correspondencia entre prefijo y red local es menos rígida. Es de esperar que un dispositivo no conozca todos los prefijos de su red local (si ésta es compartida por varios prefijos), o que un prefijo se comparta entre varios enlaces (lo que corresponde a una generalización del modelo de redes lógicas IP sobre ATM). Bajo algunas configuraciones, la máquina emitirá sus paquetes al enrutador aún si el destinatario se encuentra en el mismo segmento que el emisor. En este caso, el enrutador emitirá un mensaje de redirección para que la continuación del diálogo entre ellos haga de manera directa (véanse los ejemplos [[#IR|Indicación redirección]]).
:En el caso más extremo, podría imaginarse en IPv6 que un dispositivo puede ser configurado para comunicarse únicamente con su enrutador por omisión. ICMPv6 ''redirect'' puede utilizarse entonces, para informar al dispositivo de destinatarios ubicados en el mismo enlace.

En IPv6 se especifican dos métodos de autoconfiguración para las direcciones unicast global:

* Autoconfiguración sin estado (''stateless autoconfiguration'', RFC 2462). Se utiliza cuando no es necesaria una gestión administrativa de las direcciones asignadas dentro de un sitio. Estos mecanismos se describen más adelante en este capítulo.
* Autoconfiguración con estado (''statefull autoconfiguration''). Se utiliza cuando un sitio requiere de un control estricto de la asignación de direcciones (''cf'' [[Configuración con estado: DHCPv6 | DHCPv6]]).

Sin embargo, el uso de DHCPv6 para obtener la dirección se controla mediante el protocolo de descubrimiento de vecinos.

= Datos transmitidos por los mensajes =

La principal motivación detrás del Protocolo de Descubrimiento de vecinos es unificar varios protocolos existentes en IPv4. En particular, la mayor parte de los datos utiliza un formato de opciones común, lo que simplifica la implementación del protocolo. El formato contiene los campos: tipo, longitud (en palabras de 64 bits), y datos. La baja precisión de campo longitud, presentará un desperdicio de espacio, pero permite una alineación de las opciones en palabras de 64 bits, lo que permite un procesamiento optimizado.

{{NB-Opciones}}

== <div id="física">Dirección física de la fuente/destino</div> ==

<tikz title="Formato de la opción dirección física fuente/destino">
\clip (0.2, 5.7) rectangle (11.1,6.7);
% \draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=1/2}};
\draw (2.9, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{lenght }};
\draw (5.3, 6) node (addr) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Link Layer Address}};

\draw [draw=white, thick] (addr.north east) -- (addr.south east);
\draw [draw=white, thick] (addr.north east) -- +(-2, 0);
\draw [draw=white, thick] (addr.south east) -- +(-2, 0);

\draw [dashed] (addr.north east) -- (addr.south east);
\draw [dashed] (addr.north east) -- +(-2, 0);
\draw [dashed] (addr.south east) -- +(-2, 0);
</tikz>

La figura ''Formato de la opción dirección física fuente/destino'' presenta estas opciones. El tipo 1 designa la dirección física de la fuente y el tipo 2 la dirección del destino.

El campo ''length'' es el tamaño en palabras de 64 bits de la opción. Por lo tanto, para el caso de una dirección MAC con longitud de 6 octetos, contiene el valor 1.

El RFC 2464 define el formato para las direcciones MAC-48 utilizadas en las redes Ethernet y Wi-Fi. El RFC 4944 define el formato para las direcciones MAC-16 y MAC-64 utilizadas en las redes de sensores bajo la norma IEEE 802.15.4.

== <div id="información">Información sobre el prefijo</div> ==

<tikz title="Formato de la opción información sobre el prefijo">
\clip (0.2, 2) rectangle (11.1, 7);
% \draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=3}};
\draw (2.9, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{length =4 }};
\draw (5.3, 6) node (addr) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm] {\tiny{Prefix Length}};
\draw (7.7, 6) node (bitL) [right, shade, top color=blue!15, bottom color=blue!5,, draw, minimum height=0.5cm, minimum width=.3cm]{}; \draw (bitL.text) node {\tiny{L}};
\draw (8, 6) node (bitA) [right, shade, top color=blue!15, bottom color=blue!5,, draw, minimum height=0.5cm, minimum width=.3cm]{};\draw (bitA.text) node {\tiny{A}};
\draw (8.3, 6) node (bitR) [right, shade, top color=blue!15, bottom color=blue!5,, draw, minimum height=0.5cm, minimum width=.3cm]{};\draw (bitR.text) node {\tiny{R}};
\draw (8.6, 6) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=1.5cm] {\tiny{Reserved}};

\draw (0.5, 5.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Valid Lifetime}};

\draw (0.5, 5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Prefered Lifetime}};

\draw (0.5, 4.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Reserved}};

\draw (0.5, 4) node (addr1) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{}};
\draw (0.5, 3.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{}};
\draw (0.5, 3) node (addr3) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Prefix}};
\draw (0.5, 2.5) node (addr4) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{}};

\draw [color=blue!10, very thick] (addr1.south east) -- (addr1.south west);
\draw [color=blue!10, very thick] (addr2.south east) -- (addr2.south west);
\draw [color=blue!10, very thick] (addr3.south east) -- (addr3.south west);
</tikz>

Esta opción contiene las informaciones sobre el prefijo para permitir una configuración automática de los dispositivos. El campo tipo tiene el valor 3 y el de longitud, 4. La figura ''Formato de la opción información sobre el prefijo'' muestra el formato de esta opción:

* El campo ''Prefix lenght'' indica cuántos bits son significativos para el prefijo anunciado en un campo siguiente.
* El bit <tt>L</tt> indica, cuando vale 1, que el prefijo permite indicar que todos los demás dispositivos que comparten el mismo prefijo, están en el mismo enlace, por lo que el emisor puede contactarlos directamente. En caso contrario, el dispositivo envía el paquete hacia el enrutador. Si éste último sabe que el emisor puede contactar directamente al destinatario, emitirá un mensaje ICMPv6 de indicación de redirección.
* El bit <tt>A</tt> indica, cuando vale 1, que el prefijo anunciado puede utilizarse para formar la dirección del dispositivo.
* El bit <tt>R</tt>, indica, cuando vale 1, que el campo prefijo contiene la dirección global de un enrutador ''agente base''. Los bits de mayor peso aún pueden utilizarse para formar un prefijo.
* El campo duración de validez indica, en segundos, la duración durante la cual el prefijo es válido.
* El campo duración preferente indica la duración, en segundos, durante la cual una dirección formada con el protocolo de configuración sin estado se mantiene ''preferente'' (''cf'' [[Planes de direccionamiento|Tiempo de vida de las direcciones]]).

Para estos dos campos, un valor de <tt>0xffffffff</tt> representa una duración infinita. Estos campos pueden servir durante la fase de transición de un proveedor de acceso a otro; es decir, de un prefijo a otro.
* El campo reservado permite alinear el prefijo a una frontera de palabra de 64 bits.
* El campo prefijo contiene el valor de prefijo anunciado sobre el enlace. Para mantener una alineación de 64 bits para el resto de datos del paquete, este campo tiene una longitud fija de 128 bits.

== <div id="redirigida">Cabecera de redirección </div> ==

<tikz title="Formato de la opción cabecera de redirección">
\clip (0.2, 3.1) rectangle (11.1, 7);
% \draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=5}};
\draw (2.9, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{length =1 }};
\draw (5.3, 6) node (addr) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Reserved}};

\draw (0.5, 5.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Reserved}};

\draw (0.5, 4.25) node (context) [right, shade, top color=purple!50, bottom color=purple!10, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{IPv6 Header and Data}};
</tikz>

Esta opción es utilizada por el mensaje de indicación de redirección. Permite encapsular los primeros octetos del paquete IPv6 que provocó la emisión de este mensaje, como ocurre con los mensajes de error de ICMPv6.

El campo tipo tiene el valor 4. El tamaño de esta opción debe evitar que el paquete IPv6 rebase los 1280 octetos (''cf'' figura ''Formato de la opción cabecera de redirección''). Sin embargo, el paquete debe contener la mayor cantidad de información posible.

== <div id="MTU">MTU</div> ==

<tikz title="Formato de la opción MTU">

\clip (0.2, 5.1) rectangle (11.1, 7);
% \draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=5}};
\draw (2.9, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{lenght =1 }};
\draw (5.3, 6) node (addr) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Reserved}};

\draw (0.5, 5.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{MTU}};
</tikz>

Esta opción permite notificar a los dispositivos el tamaño máximo de datos que pueden ser transmitidos sobre el enlace. La figura ''Formato de la opción MTU'' muestra su estructura. No es necesario difundir esta información si el dispositivo utiliza siempre el tamaño máximo permitido. Por ejemplo, sobre las redes Ethernet, los dispositivos utilizarán el valor 1,500. En cambio, en las redes Token Ring o FDDI, con frecuencia es necesario especificar si los equipos pueden utilizar la longitud máxima o un tamaño inferior para permitir el uso de puentes en la red.

En esta opción, el campo tipo tiene un valor de 5 y el de longitud, de 1.

=Mensajes estándar de Descubrimiento de vecinos =

Además de las cinco opciones básicas descritas en la tabla ''Utilización de las opciones en los mensajes de descubrimiento de vecinos'', existen otras específicas para la movilidad y para las redes NBMA (''Non Broadcast Multiple Access'').

{|
|+ Utilización de las opciones en los mensajes de descubrimiento de vecinos
| width = 150 | || width = 100 |[[#RS|Solicitud de]] || width = 100 |[[#RA|Anuncio de]] || width = 100 |[[#NS|Solicitud de]] ||width = 100 | [[#NA|Anuncio de]] ||width = 100 |[[#IR|Indicación de]]
|-
| || [[#RS|enrutador]] || [[#RA|enrutador]] || [[#NS|un vecino]] || [[#NA| un vecino]] || [[#IR|redirección]]
|-style="background:silver"
|[[#física |Dirección física de la fuente]] || presente || presente || presente || ||
|-
|[[# física | Dirección física del destino]] || || || || presente || presente
|-style="background:silver"
|[[#información|Información sobre el prefijo]] || || ≥ 1 || || ||
|-
|[[#redirigida |Cabecera de redirección]] || || || || || presente
|-style="background:silver"
| [[#MTU |MTU]] || || posible || || ||
|}

Las distintas funcionalidades de descubrimiento de vecinos utilizan cinco mensajes: dos para el diálogo entre un dispositivo y un enrutador, dos para el diálogo entre vecinos, y uno para la redirección. Cada uno de estos mensajes puede incluir opciones adicionales.

== <div id="RS">Solicitud de enrutador</div> ==

<tikz title="Formato de los paquetes de solicitud de enrutador">
\clip (0.2, 3.5) rectangle (11.1,7.1);
%\draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=133}};
\draw (2.9, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code =0 }};
\draw (5.3, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};
\draw (0.5, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Reserved}};

\draw (0.5, 4.25) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Options:\\
- Source link-layer address
}};
</tikz>

El mensaje de solicitud de enrutador (''cf'' figura Formato de los paquetes de solicitud de enrutador) es emitido al iniciar un dispositivo para recibir más rápidamente la información del enrutador. Este mensaje se envía a la dirección IPv6 multicast reservada a los enrutadores en el mismo enlace <tt>FF02::2</tt>. Si el dispositivo aún no conoce su dirección fuente, se utiliza la dirección no especificada.

El campo opción normalmente contiene la dirección física del dispositivo.

== <div id="RA">Anuncio de enrutador</div> ==

<tikz title="Formato de los paquetes de anuncio de enrutador">
\clip (0.2, 1.5) rectangle (11.1,7.1);
%\draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=134}};
\draw (2.9, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code =0 }};
\draw (5.3, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};

\draw (0.5, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Cur. Hop Lim.}};
\draw (2.9, 5.5) node (bitM) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{}; \draw (bitM.text) node {\tiny{M}};
\draw (3.2, 5.5) node (bitO) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{};\draw (bitO.text) node {\tiny{O}};
\draw (3.5, 5.5) node (bitH) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{};\draw (bitH.text) node {\tiny{H}};
\draw (3.8, 5.5) node (res) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=1.5cm]{\tiny{reserved}};
\draw (5.3, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Router Lifetime}};

\draw (0.5, 5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=9.6cm]{\tiny{Reachable Time}};
\draw (0.5, 4.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=9.6cm]{\tiny{Retrans Time}};

\draw (0.5, 3.25) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Options:\\
Source link-layer address\\
MTU\\
Prefix Information (may be repeated)\\
}};
</tikz>

Este mensaje (''cf'' figura ''Formato de los paquetes de anuncio de enrutador'') es emitido periódicamente por los enrutadores, o bien, en respuesta a un mensaje de solicitud de enrutador generado por un dispositivo. El campo dirección fuente contiene la dirección de enlace local del enrutador, mientras que el campo dirección destino contiene la dirección del dispositivo que generó la solicitud, o la dirección de todas las estaciones (<tt>ff02::01</tt>).

Cuando el campo de máximo número de saltos tiene un valor distinto de cero, muestra el valor que podría colocarse en el campo de número de saltos de los paquetes emitidos. El bit <tt>M</tt> indica que una dirección del dispositivo debe ser obtenida mediante un protocolo de configuración (''cf'' [[Configuración con estado:DHCPv6]]). El bit <tt>O</tt> también indica la presencia de un servicio de configuración para obtener información adicional a la dirección. Si no es posible obtener la dirección mediante un servidor, el dispositivo procede a realizar una configuración sin estado, concatenando su identificador de interfaz a los prefijos que conoce. El bit <tt>H</tt> indica que el enrutador puede ser utilizado como agente base por un nodo móvil (''cf'' [[Desplazamientos_de_móviles#Anuncio_del_agente_base |Anuncio del agente base]]).

El campo tiempo de vida del enrutador indica el período (en segundos) durante el cual el equipo que emite el anuncio realizará funciones de enrutador por omisión. El valor máximo corresponde a 18 horas 12 minutos, pero como este mensaje se emite periódicamente, en la práctica no existe un límite para el tiempo de vida de un enrutador. Un valor de <tt>0</tt> indica que el dispositivo no cumple con las funciones de enrutador por omisión. Este tiempo de vida no se aplica a las opciones transportadas por este mensaje.

El campo duración de accesibilidad indica el período (en milisegundos) durante el cual una información almacenada en la memoria caché de la máquina (por ejemplo, la tabla de correspondencia entre las direcciones IPv6 y las físicas) puede ser considerada como válida. Al vencimiento de este tiempo, se emite un mensaje de detección de inaccesibilidad para verificar la pertinencia de la información almacenada.

El campo temporización de retransmisión muestra el período (en milisegundos) entre dos emisiones no solicitadas de este mensaje. Permite que los demás equipos puedan detectar la inaccesibilidad de un enrutador.

Este mensaje puede transportar las siguientes opciones:

* dirección física de la fuente,
* MTU,
* información sobre el prefijo (uno o varios).

== <div Id="NS"> Solicitud de un vecino </div> ==

<tikz title="Formato de los paquetes de solicitud de un vecino">

\clip (0.2, 1.5) rectangle (11.1,7.1);
%\draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=135}};
\draw (2.9, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code =0 }};
\draw (5.3, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};

\draw (0.5, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=9.6cm]{\tiny{Reserved}};

\draw (0.5, 4.25) node (context) [right, shade, top color=blue!50, bottom color=blue=!10, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Target Address}};

\draw (0.5, 2.25) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Options:\\
Source link-layer address\\
}};
</tikz>

Este mensaje (''cf'' figura ''Formato de los paquetes de solicitud de un vecino'') permite obtener información a partir de un equipo vecino, es decir, localizado en el mismo enlace físico (o conectado a través de puentes). El mensaje puede ser emitido explícitamente a él, o enviado con una dirección de difusión. En el caso de determinación de la dirección física, éste corresponde a la solicitud de ARP en IPv4.

El campo dirección fuente del paquete IPv6 contiene ya sea la dirección local al enlace, una dirección global o la dirección no especificada. El campo destino puede contener la dirección de difusión múltiple solicitada correspondiente a la dirección buscada (''cf'' [[Direccionamiento_multicast#Identificador_de_grupo|Identificador de grupo]]) o la dirección del dispositivo (en el caso de una detección de inaccesibilidad de vecinos, ''NUD'').

El campo dirección del destino contiene la dirección IPv6 del equipo buscado. El campo opción generalmente contiene la dirección física de la fuente.

== <div Id="NA"> Anuncio de un vecino</div> ==

<tikz title="Formato de los paquetes de anuncio de un vecino">

\clip (0.2, 1.5) rectangle (11.1,7.1);
%\draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=136}};
\draw (2.9, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code =0 }};
\draw (5.3, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};

\draw (0.5, 5.5) node (bitR) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{}; \draw (bitR.text) node {\tiny{R}};
\draw (0.8, 5.5) node (bitS) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{}; \draw (bitS.text) node {\tiny{S}};
\draw (1.1, 5.5) node (bitO) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{}; \draw (bitO.text) node {\tiny{O}};
\draw (1.4, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=8.7cm]{\tiny{Reserved}};

\draw (0.5, 4.25) node (context) [right, shade, top color=blue!50, bottom color=blue=!10, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Target Address}};

\draw (0.5, 2.25) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Options:\\
Source link-layer address\\
}};
</tikz>

Este mensaje (''cf'' figura ''Formato de los paquetes de anuncio de un vecino'') se emite en respuesta a una solicitud, aunque también puede ser emitido de forma espontánea para propagar la información de cambio de dirección física, o del estado de "enrutador". Para el caso de la determinación de la dirección física, es equivalente a la respuesta ARP en IPv4.

* El bit <tt> R </tt> se pone a 1 si el remitente es un enrutador. Este bit se utiliza para permitir la detección de un enrutador que se convierte en un equipo ordinario.
* El bit <tt> S </tt> en 1 indica que este anuncio se emite en respuesta a una solicitud.
* El bit <tt> O </tt> en 1 indica que este anuncio debe borrar las informaciones anteriores que se encuentran almacenadas en la memoria cachés de otros equipos, en especial la tabla que contiene las direcciones físicas.
* El campo dirección del destino contiene, si el bit<tt> S </tt> es 1, el valor del campo dirección del destino de la solicitud a la que está respondiendo este mensaje. Si el bit <tt> S </tt> es 0, este campo contiene la dirección IPv6 local al enlace del equipo emisor.
* La opción dirección física del destino contiene la dirección física del emisor.

== <div id="IR">Indicación de redirección</div> ==

<tikz title="Formato de los paquetes de indicación de redirección">
\clip (0.2, 0) rectangle (11.1,7.1);
%\draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=137}};
\draw (2.9, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code =0 }};
\draw (5.3, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};

\draw (0.5, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=9.6cm]{\tiny{Reserved}};

\draw (0.5, 4.25) node (context) [right, shade, top color=blue!50, bottom color=blue=!10, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Target Address}};

\draw (0.5, 2.25) node (context) [right, shade, top color=blue!50, bottom color=blue=!10, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Destination Address}};

\draw (0.5, 0.5) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=1.5cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Options:\\
Target link-layer address\\
Redirected Header\\
}};
</tikz>

La técnica de redirección es la misma que en IPv4. Un dispositivo sólo conoce los prefijos de las redes a las que está conectado directamente y la dirección de un enrutador por omisión. Si la ruta se puede optimizar, el enrutador por omisión envía un mensaje para indicar que existe un camino más corto. De hecho, como en IPv6 el enrutador por omisión se establece de forma automática, las rutas no necesariamente son las mejores (''cf'' figura ''Enrutamiento por omisión no óptimo'').

Otro caso particular en IPv6 ocurre con los dispositivos que se encuentran en el mismo enlace físico, pero tienen diferentes prefijos. La comunicación entre ellos pasa inicialmente a traves de enrutador por omisión hasta que éste notifica que existe una ruta directa entre ellos.

La figura ''Formato de los paquetes de indicación de redirección'' muestra el formato del mensaje:

* El campo dirección objetivo (''Target address'') contiene la dirección IPv6 del equipo hacia el que los paquetes deben ser enviados.
* El campo dirección destino contiene la dirección IPv6 del dispositivo que está siendo redirigido hacia la dirección objetivo.

Cuando la redirección apunta a un dispositivo situado en el mismo enlace, la dirección objetivo y de destino son las mismas.

Las opciones incluyen la dirección física de un nuevo enrutador y la cabecera del paquete redirigido.

Este mensaje se puede utilizar de la misma forma que en IPv4. Un dispositivo solamente tiene una ruta por omisión para acceder a equipos con un prefijo diferente. En consecuencia, envía su paquete al enrutador por omisión, quien observa que el prefijo destino es accesible a través de la misma subred que el emisor. El enrutador por omisión reenvía el paquete y notifica al emisor que puede contactar directamente a las máquinas que poseen el prefijo del destino.

IPv6 también utiliza este mensaje para optimizar la resolución fuera del enlace para el [[#Caso de redes NBMA |caso de redes NBMA]].

= Configuración automática =
Tradicionalmente, la configuración de una interfaz de red de una máquina se hacía manualmente. Esto suele ser un trabajo lento y propenso a errores. Con IPv6, se automatiza el proceso de configuración y se introducen, al mismo tiempo, mecanismos de funcionamiento inmediato (''plug and play'') a la interfaz de red. La configuración automática significa que un dispositivo obtendrá toda la información necesaria para su conexión a una red local IP sin ninguna intervención humana. En el caso ideal, cualquier usuario desempaca su nuevo equipo, lo conecta a la red local y lo ve funcionar sin tener que introducir la información propia de "especialistas". Ahora vamos a discutir otro aspecto de la configuración automática de IPv6, la auto-configuración de direcciones, que tiene como objetivos:

* La adquisición de una dirección cuando un dispositivo está conectado a una red por primera vez;
* la posibilidad de asignar otros prefijos, o de renumerar un dispositivo.

El proceso de configuración automática de direcciones IPv6 incluye la creación de una dirección local al enlace, la agregación a grupos multicast solicitados, la verificación de la unicidad de la dirección local al enlace y la creación de direcciones unicast global.

La tarea del enrutador es importante en la configuración automática. Indica a la máquina, mediante los bits de la cabecera (''cf'' [[#RA|anuncio de enrutador]]), del mensaje de anuncio de los enrutadores, el método a conservar y eventualmente proporcionar la información necesaria para su configuración. El bit <tt> M </tt> (''configuración de dirección administrada'') puesto a 1 indica que el equipo no debe crear por sí mismo una dirección a partir de su identificador de interfaz y de los prefijos recibidos, sino que debe solicitarla explícitamente ante un servidor de direcciones. El bit O <tt> </tt> (''otra configuración de estado'') indica que el dispositivo debe consultar el servidor para obtener otros parámetros distintos de la dirección. El algoritmo para el proceso de configuración automática de direcciones se desglosa de la siguiente manera:

* La primera fase consiste en crear la dirección local al enlace.
* Una vez que la unicidad de esta dirección es verificada, el dispositivo está listo para comunicarse con otras máquinas en el enlace.
* El dispositivo debe tratar de adquirir un mensaje de anuncio de enrutadores para determinar el método de obtención de la dirección unicast global.
* Si hay un enrutador en el enlace, el dispositivo debe aplicar el método especificado por el mensaje de anuncio de enrutadores, a saber:
** La configuración automática sin estado,
** la configuración automática con estado.
* Si no hay ningún enrutador en el enlace, el dispositivo debe tratar de obtener la dirección unicast global por el método de configuración automática con estado. Si el intento falla, no hay más que hacer. Las comunicaciones sólo podrán hacerse sobre el enlace con la dirección local al enlace, pues el dispositivo no tendrá una dirección con la cobertura necesaria que le permita comunicarse con otras máquinas fuera del enlace.

==Ciclo de vida de una dirección==

Al generalizar en IPv6 el plan de direccionamiento CIDR, los prefijos quedan, en todos los casos, siendo propiedad de los operadores. Ya no pueden otorgarse "a perpetuidad" a los dispositivos. Para facilitar la renumeración de una máquina, la asignación de una dirección a una interfaz es temporal, las direcciones IPv6 no se entregan, sino que se prestan. Se asocia un tiempo de vida a la dirección, que indica el tiempo durante el cual la dirección pertenece a la interfaz. Cuando el tiempo de vida se ha agotada, la dirección deja de ser válida, se suprime de la interfaz y queda potencialmente éste puede prolongarse indefinidamente. La dirección local al enlace tiene un tiempo de vida ilimitado.

<tikz title="Estados sucesivos de una dirección en una interfaz">

\draw [thick, ->] (0,2) -- (9.5,2);

\draw [->] (1,4) node [above=10pt] {\tiny{allocation}}-- (1,2);
\draw (1, 2) node [rectangle, minimum width=1cm, minimum height=1cm, fill, left color=black!10, right color=black!20, draw=black, above right] (tentative) {};
\draw (tentative.south east) node [rectangle, minimum width=3cm, minimum height=1cm, fill, left color=green, right color=green!50, draw=black, above right] (preferred) {};
\draw (preferred.south east) node [rectangle, minimum width=2cm, minimum height=1cm, fill, left color=orange , right color=orange!50!red, draw=black, above right] (deprecated) {};
\draw (deprecated.south east) node [rectangle, minimum width=2cm, minimum height=1cm, fill, color=red, draw=black, above right] (novalid) {};

\draw (tentative.text) node {\tiny{Tentative}};
\draw (preferred.text) node {\tiny{Preferred}};
\draw (deprecated.text) node {\tiny{Deprecated}};
\draw (novalid.text) node {\tiny{Invalid}};

\draw [dotted] (tentative.south west) -- +(0, -1);
\draw [dotted] (preferred.south west) -- +(0, -1);
\draw [dotted] (deprecated.south west) -- +(0, -1);
\draw [dotted] (novalid.south west) -- +(0, -1);

\draw [dashed, <->] ([yshift=-0.5cm]tentative.south west) -- node [above] {\tiny{DAD}} ([yshift=-0.5cm] preferred.south west) ;

\draw [dashed, <->] ([yshift=-0.5cm]preferred.south west) -- node [above] {\tiny{Valid}} ([yshift=-0.5cm] novalid.south west) ;

</tikz>

La renumeración de una interfaz consiste en pasar de una dirección a otra. Durante una renumeración, no es aconsejable cambiar repentinamente de dirección, de lo contrario, todas las comunicaciones TCP que la utilizan como identificador de conexión, se cortarían inmediatamente. Esto conllevaría importantes perturbaciones a nivel de las aplicaciones.

Por ello, para facilitar esta transición se implementó un mecanismo de obsolescencia que invalida gradualmente una dirección. Este mecanismo se sirve de la capacidad de asignación de varias direcciones válidas a una misma interfaz. Para elegir la dirección a utilizar, se le asocia un estado que indica en qué fase de su tiempo de vida se encuentra con respecto a la interfaz. El primero de esos estados se conoce como preferido: no hay ninguna restricción de uso. Poco antes de su invalidación, la dirección pasa a un estado de depreciado. En él se desaconseja el uso de la dirección, pero no está prohibido. Una dirección depreciada ya no debe ser utilizada como dirección fuente de nuevas comunicaciones (como el establecimiento de conexión TCP), pero todavía puede emplearse como dirección fuente de comunicaciones ya establecidas. Los paquetes recibidos a una dirección depreciada seguirán siendo entregados normalmente. El control de la duración de cada estad de una dirección válida se efectúa agregando un tiempo de vida al estado preferido.
La figura '''Estados sucesivos de una dirección en una interfaz''' representa los diferentes estados que toma una dirección cuando se asigna a una interfaz.

== Creación de la dirección local al enlace ==

<tikz title=" Creación de la dirección local al enlace">
\clip (0, 0) rectangle (10,7);
% \draw[help lines] (0,0) grid (10,7 );

\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,3)--(9,3);

\pgfputat{\pgfxy(0.8,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,5)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,3)--(1.5,5);
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (8,3)--(8,5);

\draw (1.5,4.5) node {\small{FE80::IID1}};
\draw (1.5,4) node {\small{$\alpha$::IID1/64}};

\draw (8, 4.5) node {\small{FE80::IID2}};

</tikz>

Durante la inicialización de la interfaz, el dispositivo construye un identificador de interfaz que debe ser único en el enlace. Este identificador se utiliza la dirección de [[ Identificador_de_interfaz#EUI-64 | EUI-64]]. El principio básico para crear la direcciónIPv6 consiste en unir un prefijo con el identificador. La dirección local al enlace se crea tomando el prefijo de Enlace_local (<tt>FE80::/64</tt>). La dirección creada de esa manera, todavía no puede ser utilizada; tiene un estado temporal pues el dispositivo debe comprobar la exclusividad de esta dirección en el enlace mediante el procedimiento de detección de direcciones duplicadas. Si se encuentra que la dirección local al enlace no es única, se suspende la autoconfiguración y será necesario proceder a una configuración manual.

Una vez que se ha asegurado la unicidad de la dirección local al enlace, ésta se considera una dirección válida para la interfaz, con lo que termina la prima fase del proceso de autoconfiguración.

==<div id="DAD"> Detección de una dirección duplicada </div>==

<tikz title="Emisión de un NS en una detección de Dir. duplicada (DAD)">
\clip (0, 0) rectangle (10,7);
% \draw[help lines] (0,0) grid (10,7 );

\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,3)--(9,3);

\pgfputat{\pgfxy(0.8,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,5)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,3)--(1.5,5);
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (8,3)--(8,5);

\draw (7.8, 5) -- (7.8, 3.2);
\draw [<->] (1, 3.2) -- node [above] {\tiny{::/0 -$>$ solicited (FE80:IID2) : NS (who has FE80::IID2?)}}(9, 3.2) ;

</tikz>

Para comprobar la exclusividad de direcciones locales al enlace o de direcciones unicast, los dispositivos deben ejecutar un algoritmo de detección de direcciones duplicadas (DAD) antes poder utilizarlas. El algoritmo usa los mensajes ICMPv6 [[Protocolo_de_Descubrimiento_de_vecinos#NS|solicitud de un vecino]] y [[#NA|anuncio de un vecino.]] Si se detecta una dirección que ya está en uso, ésta no podrá ser asignada a la interfaz, la autoconfiguración automática debe suspenderse y será necesario proceder a una configuración manual. Durante la ejecución del algoritmo DAD, la dirección es considerada como "provisional" hasta tener la confirmación de su unicidad. Una dirección provisional se asigna a una interfaz únicamente para recibir los mensajes de solicitud y anuncio de un vecino. Otros mensajes recibidos, son ignorados. El algoritmo DAD consiste en enviar un mensaje de solicitud de un vecino colocando en el campo de dirección objetivo la dirección provisional. Para distinguir el algoritmo DAD del de Descubrimiento de vecinos, el paquete IPv6 que contiene un mensaje de solicitud de un vecino tiene como dirección fuente una dirección no determinada. Así se presentan tres casos:

* Se recibe un mensaje de anucio de un vecino: Significa que la dirección provisional está siendo utilizada como válida por otro dispositivo, por lo que ésta no es única y no puede ser retenida por el dispositivo.
* Se recibe un mensaje de solicitud de un vecino como parte del algoritmo DAD. La dirección provisional también es provisional para otra máquina. En este caso, la dirección provisional no puede ser utilizada por ninguna de ellas.
* No se recibe ningún mensaje durante un segundo (valor por omisión). La dirección provisional es única, por lo que su estado pasa de provisional a válida y se le asigna a la interfaz.

Obsérvese que este algoritmo no proporciona una fiabilidad absoluta, especialmente cuando el enlace está segmentado.

== Autoconfiguración sin estado ==

<tikz title="Emisión de un RS">
\clip (0, 0) rectangle (10,7);
% \draw[help lines] (0,0) grid (10,7 );

\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,3)--(9,3);

\pgfputat{\pgfxy(0.8,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,5)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,3)--(1.5,5);
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (8,3)--(8,5);

\draw (7.8, 5) -- (7.8, 3.2);
\draw [<->] (1, 3.2) -- node [above] {\tiny{FE80::IID2 -$>$ FF02::2 : RS }} (9, 3.2) ;

</tikz>

La configuración automática sin estado (RFC 2462) no requiere de ninguna configuración manual de los dispositivos, una configuración mínima para los enrutadores, y tampoco necesita de servidores adicionales. Se sirve del protocolo ICMPv6 y puede operar aún sin la presencia de enrutadores. En cambio, sí requiere de una subred con soporte a la difusión de paquetes. Este método sólo aplica para los dispositivos; no puede ser utilizada para configurar enrutadores. El principio básico de este mecanismo consiste en que una máquina genera su dirección IPv6 a partir de información local y de la proporcionada por un enrutador. El enrutador proporciona información sobre la subred asociada al enlace; anuncia el prefijo.

{{eSuivi|Tabla de contenido|Incio del capítulo|DHCPv6|DHCPv6}}

Protocolo de Descubrimiento de vecinos

2012-07-04T22:07:49Z

Jincera: /* Configuración automática */

{{eSuivi|Tabla de contenido|Incio del capítulo|DHCPv6|DHCPv6}}

__TOC__

El protocolo de descubrimiento de vecinos (NDP, ''Neighbor Discovery Protocol'') permite a un dispositivo integrarse en el ambiente local, es decir, el enlace sobre el cual se transmiten físicamente los paquetes IPv6. Permite establecer un diálogo con los equipos (estaciones y enrutadores) conectados sobre el mismo medio. No se pretende que un dispositivo conozca con exactitud la lista de todos los demás dispositivos conectados al enlace, sino de proveer un mecanismo para dialogar con quien necesite hacerlo.

El protocolo utiliza cinco tipos de mensajes ICMPv6 (ver Valores de los campos de tipo y código de ICMPv6). El campo número de saltos de la cabecera IPv6 contiene el valor 255. Este valor parece demasiado grande para datagramas que no debieran ser enrutados fuera del enlace físico. En realidad, si un equipo recibe un datagrama con un valor menor, significa que la información proviene de otra red y que ya ha atravesado al menos un enrutador. Por ello, los datagramas que tienen un valor diferente de 255 deben ser ignorados por el receptor.

{{Tableau eICMPv6}}

El protocolo realiza varias funciones:

* Resolución de direcciones. El principio es muy similar al del protocolo ARP de IPv4. La principal diferencia consiste en el uso de mensajes ICMPv6 estándar en lugar de definir otro protocolo de capa 3. Con esto se consigue una mayor flexibilidad de uso, especialmente en las redes que no soportan la difusión de mensajes. Al igual que en IPv4, el protocolo se encarga de construir tablas de correspondencia entre las direcciones IPv6 y las físicas.
* <div vecinos id="NUD"> Detección de inaccesibilidad de vecinos (NUD, ''Neighbor Unreachability Detection''). Esta función, que no existe en IPv4, permite eliminar de las tablas de configuración de un equipo, los vecinos que se han vuelto inaccesibles (por fallas, cambio de domicilio, ...). Si un enrutador deja de estar disponible, la tabla de enrutamiento puede ser modificada para considerar otra ruta. </div>
* Configuración. La configuración automática de los dispositivos es uno de los principales atractivos de IPv6. Se implementan varias funcionalidades del protocolo de descubrimiento de vecinos:
**Descubrimiento de enrutadores. Este protocolo permite que los dispositivos identifiquen a los enrutadores que se encuentran en su enlace físico. En IPv4, esta función la proporciona el protocolo ''ICMP Router Discovery''.
** Descubrimiento de prefijos. El dispositivo conoce el o los prefijos de red de acuerdo a los anuncios realizados por los enrutadores. Agregando su identificador de interfaz, el dispositivo construye su o sus direcciones IPv6. No hay un mecanismo equivalente para las direcciones IPv4 ya que son demasiado cortas para realizar la auto-configuración.
** Detección de direcciones duplicadas. Dado que las direcciones se configuran de forma automática, existen riesgos de error en caso de tener equipos con identificadores repetidos. Este protocolo verifica que ningún otro equipo en el enlace tiene la misma dirección IPv6. Esta función es una evolución del ARP gratuito en IPv4 emitido durante la inicialización de la interfaz.
** Descubrimiento de parámetros. Este protocolo permite que los dispositivos conozcan los distintos parámetros del enlace físico, por ejemplo, el tamaño de MTU, el número máximo de saltos permitido (valor original del campo número de saltos), si la configuración automática con estado (como [[Configuración con estado: DHCPv6|DHCPv6]]) está activa, etc. No existe un equivalente de esta funcionalidad en IPv4.
* Indicación de redirección. Este mensaje se utiliza cuando un enrutador conoce una trayectoria mejor (medida en número de saltos) para alcanzar un destino.
:En IPv4 una indicación de redireccionamiento sólo puede servir para corregir la dirección del enrutador utilizado para acceder a una máquina fuera de la red local. Los dispositivos deben conocer todas las direcciones correspondientes a equipos conectados en su propia red local.
:EnIPv6, la correspondencia entre prefijo y red local es menos rígida. Es de esperar que un dispositivo no conozca todos los prefijos de su red local (si ésta es compartida por varios prefijos), o que un prefijo se comparta entre varios enlaces (lo que corresponde a una generalización del modelo de redes lógicas IP sobre ATM). Bajo algunas configuraciones, la máquina emitirá sus paquetes al enrutador aún si el destinatario se encuentra en el mismo segmento que el emisor. En este caso, el enrutador emitirá un mensaje de redirección para que la continuación del diálogo entre ellos haga de manera directa (véanse los ejemplos [[#IR|Indicación redirección]]).
:En el caso más extremo, podría imaginarse en IPv6 que un dispositivo puede ser configurado para comunicarse únicamente con su enrutador por omisión. ICMPv6 ''redirect'' puede utilizarse entonces, para informar al dispositivo de destinatarios ubicados en el mismo enlace.

En IPv6 se especifican dos métodos de autoconfiguración para las direcciones unicast global:

* Autoconfiguración sin estado (''stateless autoconfiguration'', RFC 2462). Se utiliza cuando no es necesaria una gestión administrativa de las direcciones asignadas dentro de un sitio. Estos mecanismos se describen más adelante en este capítulo.
* Autoconfiguración con estado (''statefull autoconfiguration''). Se utiliza cuando un sitio requiere de un control estricto de la asignación de direcciones (''cf'' [[Configuración con estado: DHCPv6 | DHCPv6]]).

Sin embargo, el uso de DHCPv6 para obtener la dirección se controla mediante el protocolo de descubrimiento de vecinos.

= Datos transmitidos por los mensajes =

La principal motivación detrás del Protocolo de Descubrimiento de vecinos es unificar varios protocolos existentes en IPv4. En particular, la mayor parte de los datos utiliza un formato de opciones común, lo que simplifica la implementación del protocolo. El formato contiene los campos: tipo, longitud (en palabras de 64 bits), y datos. La baja precisión de campo longitud, presentará un desperdicio de espacio, pero permite una alineación de las opciones en palabras de 64 bits, lo que permite un procesamiento optimizado.

{{NB-Opciones}}

== <div id="física">Dirección física de la fuente/destino</div> ==

<tikz title="Formato de la opción dirección física fuente/destino">
\clip (0.2, 5.7) rectangle (11.1,6.7);
% \draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=1/2}};
\draw (2.9, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{lenght }};
\draw (5.3, 6) node (addr) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Link Layer Address}};

\draw [draw=white, thick] (addr.north east) -- (addr.south east);
\draw [draw=white, thick] (addr.north east) -- +(-2, 0);
\draw [draw=white, thick] (addr.south east) -- +(-2, 0);

\draw [dashed] (addr.north east) -- (addr.south east);
\draw [dashed] (addr.north east) -- +(-2, 0);
\draw [dashed] (addr.south east) -- +(-2, 0);
</tikz>

La figura ''Formato de la opción dirección física fuente/destino'' presenta estas opciones. El tipo 1 designa la dirección física de la fuente y el tipo 2 la dirección del destino.

El campo ''length'' es el tamaño en palabras de 64 bits de la opción. Por lo tanto, para el caso de una dirección MAC con longitud de 6 octetos, contiene el valor 1.

El RFC 2464 define el formato para las direcciones MAC-48 utilizadas en las redes Ethernet y Wi-Fi. El RFC 4944 define el formato para las direcciones MAC-16 y MAC-64 utilizadas en las redes de sensores bajo la norma IEEE 802.15.4.

== <div id="información">Información sobre el prefijo</div> ==

<tikz title="Formato de la opción información sobre el prefijo">
\clip (0.2, 2) rectangle (11.1, 7);
% \draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=3}};
\draw (2.9, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{length =4 }};
\draw (5.3, 6) node (addr) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm] {\tiny{Prefix Length}};
\draw (7.7, 6) node (bitL) [right, shade, top color=blue!15, bottom color=blue!5,, draw, minimum height=0.5cm, minimum width=.3cm]{}; \draw (bitL.text) node {\tiny{L}};
\draw (8, 6) node (bitA) [right, shade, top color=blue!15, bottom color=blue!5,, draw, minimum height=0.5cm, minimum width=.3cm]{};\draw (bitA.text) node {\tiny{A}};
\draw (8.3, 6) node (bitR) [right, shade, top color=blue!15, bottom color=blue!5,, draw, minimum height=0.5cm, minimum width=.3cm]{};\draw (bitR.text) node {\tiny{R}};
\draw (8.6, 6) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=1.5cm] {\tiny{Reserved}};

\draw (0.5, 5.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Valid Lifetime}};

\draw (0.5, 5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Prefered Lifetime}};

\draw (0.5, 4.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Reserved}};

\draw (0.5, 4) node (addr1) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{}};
\draw (0.5, 3.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{}};
\draw (0.5, 3) node (addr3) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Prefix}};
\draw (0.5, 2.5) node (addr4) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{}};

\draw [color=blue!10, very thick] (addr1.south east) -- (addr1.south west);
\draw [color=blue!10, very thick] (addr2.south east) -- (addr2.south west);
\draw [color=blue!10, very thick] (addr3.south east) -- (addr3.south west);
</tikz>

Esta opción contiene las informaciones sobre el prefijo para permitir una configuración automática de los dispositivos. El campo tipo tiene el valor 3 y el de longitud, 4. La figura ''Formato de la opción información sobre el prefijo'' muestra el formato de esta opción:

* El campo ''Prefix lenght'' indica cuántos bits son significativos para el prefijo anunciado en un campo siguiente.
* El bit <tt>L</tt> indica, cuando vale 1, que el prefijo permite indicar que todos los demás dispositivos que comparten el mismo prefijo, están en el mismo enlace, por lo que el emisor puede contactarlos directamente. En caso contrario, el dispositivo envía el paquete hacia el enrutador. Si éste último sabe que el emisor puede contactar directamente al destinatario, emitirá un mensaje ICMPv6 de indicación de redirección.
* El bit <tt>A</tt> indica, cuando vale 1, que el prefijo anunciado puede utilizarse para formar la dirección del dispositivo.
* El bit <tt>R</tt>, indica, cuando vale 1, que el campo prefijo contiene la dirección global de un enrutador ''agente base''. Los bits de mayor peso aún pueden utilizarse para formar un prefijo.
* El campo duración de validez indica, en segundos, la duración durante la cual el prefijo es válido.
* El campo duración preferente indica la duración, en segundos, durante la cual una dirección formada con el protocolo de configuración sin estado se mantiene ''preferente'' (''cf'' [[Planes de direccionamiento|Tiempo de vida de las direcciones]]).

Para estos dos campos, un valor de <tt>0xffffffff</tt> representa una duración infinita. Estos campos pueden servir durante la fase de transición de un proveedor de acceso a otro; es decir, de un prefijo a otro.
* El campo reservado permite alinear el prefijo a una frontera de palabra de 64 bits.
* El campo prefijo contiene el valor de prefijo anunciado sobre el enlace. Para mantener una alineación de 64 bits para el resto de datos del paquete, este campo tiene una longitud fija de 128 bits.

== <div id="redirigida">Cabecera de redirección </div> ==

<tikz title="Formato de la opción cabecera de redirección">
\clip (0.2, 3.1) rectangle (11.1, 7);
% \draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=5}};
\draw (2.9, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{length =1 }};
\draw (5.3, 6) node (addr) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Reserved}};

\draw (0.5, 5.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Reserved}};

\draw (0.5, 4.25) node (context) [right, shade, top color=purple!50, bottom color=purple!10, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{IPv6 Header and Data}};
</tikz>

Esta opción es utilizada por el mensaje de indicación de redirección. Permite encapsular los primeros octetos del paquete IPv6 que provocó la emisión de este mensaje, como ocurre con los mensajes de error de ICMPv6.

El campo tipo tiene el valor 4. El tamaño de esta opción debe evitar que el paquete IPv6 rebase los 1280 octetos (''cf'' figura ''Formato de la opción cabecera de redirección''). Sin embargo, el paquete debe contener la mayor cantidad de información posible.

== <div id="MTU">MTU</div> ==

<tikz title="Formato de la opción MTU">

\clip (0.2, 5.1) rectangle (11.1, 7);
% \draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=5}};
\draw (2.9, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{lenght =1 }};
\draw (5.3, 6) node (addr) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Reserved}};

\draw (0.5, 5.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{MTU}};
</tikz>

Esta opción permite notificar a los dispositivos el tamaño máximo de datos que pueden ser transmitidos sobre el enlace. La figura ''Formato de la opción MTU'' muestra su estructura. No es necesario difundir esta información si el dispositivo utiliza siempre el tamaño máximo permitido. Por ejemplo, sobre las redes Ethernet, los dispositivos utilizarán el valor 1,500. En cambio, en las redes Token Ring o FDDI, con frecuencia es necesario especificar si los equipos pueden utilizar la longitud máxima o un tamaño inferior para permitir el uso de puentes en la red.

En esta opción, el campo tipo tiene un valor de 5 y el de longitud, de 1.

=Mensajes estándar de Descubrimiento de vecinos =

Además de las cinco opciones básicas descritas en la tabla ''Utilización de las opciones en los mensajes de descubrimiento de vecinos'', existen otras específicas para la movilidad y para las redes NBMA (''Non Broadcast Multiple Access'').

{|
|+ Utilización de las opciones en los mensajes de descubrimiento de vecinos
| width = 150 | || width = 100 |[[#RS|Solicitud de]] || width = 100 |[[#RA|Anuncio de]] || width = 100 |[[#NS|Solicitud de]] ||width = 100 | [[#NA|Anuncio de]] ||width = 100 |[[#IR|Indicación de]]
|-
| || [[#RS|enrutador]] || [[#RA|enrutador]] || [[#NS|un vecino]] || [[#NA| un vecino]] || [[#IR|redirección]]
|-style="background:silver"
|[[#física |Dirección física de la fuente]] || presente || presente || presente || ||
|-
|[[# física | Dirección física del destino]] || || || || presente || presente
|-style="background:silver"
|[[#información|Información sobre el prefijo]] || || ≥ 1 || || ||
|-
|[[#redirigida |Cabecera de redirección]] || || || || || presente
|-style="background:silver"
| [[#MTU |MTU]] || || posible || || ||
|}

Las distintas funcionalidades de descubrimiento de vecinos utilizan cinco mensajes: dos para el diálogo entre un dispositivo y un enrutador, dos para el diálogo entre vecinos, y uno para la redirección. Cada uno de estos mensajes puede incluir opciones adicionales.

== <div id="RS">Solicitud de enrutador</div> ==

<tikz title="Formato de los paquetes de solicitud de enrutador">
\clip (0.2, 3.5) rectangle (11.1,7.1);
%\draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=133}};
\draw (2.9, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code =0 }};
\draw (5.3, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};
\draw (0.5, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Reserved}};

\draw (0.5, 4.25) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Options:\\
- Source link-layer address
}};
</tikz>

El mensaje de solicitud de enrutador (''cf'' figura Formato de los paquetes de solicitud de enrutador) es emitido al iniciar un dispositivo para recibir más rápidamente la información del enrutador. Este mensaje se envía a la dirección IPv6 multicast reservada a los enrutadores en el mismo enlace <tt>FF02::2</tt>. Si el dispositivo aún no conoce su dirección fuente, se utiliza la dirección no especificada.

El campo opción normalmente contiene la dirección física del dispositivo.

== <div id="RA">Anuncio de enrutador</div> ==

<tikz title="Formato de los paquetes de anuncio de enrutador">
\clip (0.2, 1.5) rectangle (11.1,7.1);
%\draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=134}};
\draw (2.9, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code =0 }};
\draw (5.3, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};

\draw (0.5, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Cur. Hop Lim.}};
\draw (2.9, 5.5) node (bitM) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{}; \draw (bitM.text) node {\tiny{M}};
\draw (3.2, 5.5) node (bitO) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{};\draw (bitO.text) node {\tiny{O}};
\draw (3.5, 5.5) node (bitH) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{};\draw (bitH.text) node {\tiny{H}};
\draw (3.8, 5.5) node (res) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=1.5cm]{\tiny{reserved}};
\draw (5.3, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Router Lifetime}};

\draw (0.5, 5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=9.6cm]{\tiny{Reachable Time}};
\draw (0.5, 4.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=9.6cm]{\tiny{Retrans Time}};

\draw (0.5, 3.25) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Options:\\
Source link-layer address\\
MTU\\
Prefix Information (may be repeated)\\
}};
</tikz>

Este mensaje (''cf'' figura ''Formato de los paquetes de anuncio de enrutador'') es emitido periódicamente por los enrutadores, o bien, en respuesta a un mensaje de solicitud de enrutador generado por un dispositivo. El campo dirección fuente contiene la dirección de enlace local del enrutador, mientras que el campo dirección destino contiene la dirección del dispositivo que generó la solicitud, o la dirección de todas las estaciones (<tt>ff02::01</tt>).

Cuando el campo de máximo número de saltos tiene un valor distinto de cero, muestra el valor que podría colocarse en el campo de número de saltos de los paquetes emitidos. El bit <tt>M</tt> indica que una dirección del dispositivo debe ser obtenida mediante un protocolo de configuración (''cf'' [[Configuración con estado:DHCPv6]]). El bit <tt>O</tt> también indica la presencia de un servicio de configuración para obtener información adicional a la dirección. Si no es posible obtener la dirección mediante un servidor, el dispositivo procede a realizar una configuración sin estado, concatenando su identificador de interfaz a los prefijos que conoce. El bit <tt>H</tt> indica que el enrutador puede ser utilizado como agente base por un nodo móvil (''cf'' [[Desplazamientos_de_móviles#Anuncio_del_agente_base |Anuncio del agente base]]).

El campo tiempo de vida del enrutador indica el período (en segundos) durante el cual el equipo que emite el anuncio realizará funciones de enrutador por omisión. El valor máximo corresponde a 18 horas 12 minutos, pero como este mensaje se emite periódicamente, en la práctica no existe un límite para el tiempo de vida de un enrutador. Un valor de <tt>0</tt> indica que el dispositivo no cumple con las funciones de enrutador por omisión. Este tiempo de vida no se aplica a las opciones transportadas por este mensaje.

El campo duración de accesibilidad indica el período (en milisegundos) durante el cual una información almacenada en la memoria caché de la máquina (por ejemplo, la tabla de correspondencia entre las direcciones IPv6 y las físicas) puede ser considerada como válida. Al vencimiento de este tiempo, se emite un mensaje de detección de inaccesibilidad para verificar la pertinencia de la información almacenada.

El campo temporización de retransmisión muestra el período (en milisegundos) entre dos emisiones no solicitadas de este mensaje. Permite que los demás equipos puedan detectar la inaccesibilidad de un enrutador.

Este mensaje puede transportar las siguientes opciones:

* dirección física de la fuente,
* MTU,
* información sobre el prefijo (uno o varios).

== <div Id="NS"> Solicitud de un vecino </div> ==

<tikz title="Formato de los paquetes de solicitud de un vecino">

\clip (0.2, 1.5) rectangle (11.1,7.1);
%\draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=135}};
\draw (2.9, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code =0 }};
\draw (5.3, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};

\draw (0.5, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=9.6cm]{\tiny{Reserved}};

\draw (0.5, 4.25) node (context) [right, shade, top color=blue!50, bottom color=blue=!10, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Target Address}};

\draw (0.5, 2.25) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Options:\\
Source link-layer address\\
}};
</tikz>

Este mensaje (''cf'' figura ''Formato de los paquetes de solicitud de un vecino'') permite obtener información a partir de un equipo vecino, es decir, localizado en el mismo enlace físico (o conectado a través de puentes). El mensaje puede ser emitido explícitamente a él, o enviado con una dirección de difusión. En el caso de determinación de la dirección física, éste corresponde a la solicitud de ARP en IPv4.

El campo dirección fuente del paquete IPv6 contiene ya sea la dirección local al enlace, una dirección global o la dirección no especificada. El campo destino puede contener la dirección de difusión múltiple solicitada correspondiente a la dirección buscada (''cf'' [[Direccionamiento_multicast#Identificador_de_grupo|Identificador de grupo]]) o la dirección del dispositivo (en el caso de una detección de inaccesibilidad de vecinos, ''NUD'').

El campo dirección del destino contiene la dirección IPv6 del equipo buscado. El campo opción generalmente contiene la dirección física de la fuente.

== <div Id="NA"> Anuncio de un vecino</div> ==

<tikz title="Formato de los paquetes de anuncio de un vecino">

\clip (0.2, 1.5) rectangle (11.1,7.1);
%\draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=136}};
\draw (2.9, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code =0 }};
\draw (5.3, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};

\draw (0.5, 5.5) node (bitR) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{}; \draw (bitR.text) node {\tiny{R}};
\draw (0.8, 5.5) node (bitS) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{}; \draw (bitS.text) node {\tiny{S}};
\draw (1.1, 5.5) node (bitO) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{}; \draw (bitO.text) node {\tiny{O}};
\draw (1.4, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=8.7cm]{\tiny{Reserved}};

\draw (0.5, 4.25) node (context) [right, shade, top color=blue!50, bottom color=blue=!10, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Target Address}};

\draw (0.5, 2.25) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Options:\\
Source link-layer address\\
}};
</tikz>

Este mensaje (''cf'' figura ''Formato de los paquetes de anuncio de un vecino'') se emite en respuesta a una solicitud, aunque también puede ser emitido de forma espontánea para propagar la información de cambio de dirección física, o del estado de "enrutador". Para el caso de la determinación de la dirección física, es equivalente a la respuesta ARP en IPv4.

* El bit <tt> R </tt> se pone a 1 si el remitente es un enrutador. Este bit se utiliza para permitir la detección de un enrutador que se convierte en un equipo ordinario.
* El bit <tt> S </tt> en 1 indica que este anuncio se emite en respuesta a una solicitud.
* El bit <tt> O </tt> en 1 indica que este anuncio debe borrar las informaciones anteriores que se encuentran almacenadas en la memoria cachés de otros equipos, en especial la tabla que contiene las direcciones físicas.
* El campo dirección del destino contiene, si el bit<tt> S </tt> es 1, el valor del campo dirección del destino de la solicitud a la que está respondiendo este mensaje. Si el bit <tt> S </tt> es 0, este campo contiene la dirección IPv6 local al enlace del equipo emisor.
* La opción dirección física del destino contiene la dirección física del emisor.

== <div id="IR">Indicación de redirección</div> ==

<tikz title="Formato de los paquetes de indicación de redirección">
\clip (0.2, 0) rectangle (11.1,7.1);
%\draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=137}};
\draw (2.9, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code =0 }};
\draw (5.3, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};

\draw (0.5, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=9.6cm]{\tiny{Reserved}};

\draw (0.5, 4.25) node (context) [right, shade, top color=blue!50, bottom color=blue=!10, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Target Address}};

\draw (0.5, 2.25) node (context) [right, shade, top color=blue!50, bottom color=blue=!10, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Destination Address}};

\draw (0.5, 0.5) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=1.5cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Options:\\
Target link-layer address\\
Redirected Header\\
}};
</tikz>

La técnica de redirección es la misma que en IPv4. Un dispositivo sólo conoce los prefijos de las redes a las que está conectado directamente y la dirección de un enrutador por omisión. Si la ruta se puede optimizar, el enrutador por omisión envía un mensaje para indicar que existe un camino más corto. De hecho, como en IPv6 el enrutador por omisión se establece de forma automática, las rutas no necesariamente son las mejores (''cf'' figura ''Enrutamiento por omisión no óptimo'').

Otro caso particular en IPv6 ocurre con los dispositivos que se encuentran en el mismo enlace físico, pero tienen diferentes prefijos. La comunicación entre ellos pasa inicialmente a traves de enrutador por omisión hasta que éste notifica que existe una ruta directa entre ellos.

La figura ''Formato de los paquetes de indicación de redirección'' muestra el formato del mensaje:

* El campo dirección objetivo (''Target address'') contiene la dirección IPv6 del equipo hacia el que los paquetes deben ser enviados.
* El campo dirección destino contiene la dirección IPv6 del dispositivo que está siendo redirigido hacia la dirección objetivo.

Cuando la redirección apunta a un dispositivo situado en el mismo enlace, la dirección objetivo y de destino son las mismas.

Las opciones incluyen la dirección física de un nuevo enrutador y la cabecera del paquete redirigido.

Este mensaje se puede utilizar de la misma forma que en IPv4. Un dispositivo solamente tiene una ruta por omisión para acceder a equipos con un prefijo diferente. En consecuencia, envía su paquete al enrutador por omisión, quien observa que el prefijo destino es accesible a través de la misma subred que el emisor. El enrutador por omisión reenvía el paquete y notifica al emisor que puede contactar directamente a las máquinas que poseen el prefijo del destino.

IPv6 también utiliza este mensaje para optimizar la resolución fuera del enlace para el [[#Caso de redes NBMA |caso de redes NBMA]].

= Configuración automática =
Tradicionalmente, la configuración de una interfaz de red de una máquina se hacía manualmente. Esto suele ser un trabajo lento y propenso a errores. Con IPv6, se automatiza el proceso de configuración y se introducen, al mismo tiempo, mecanismos de funcionamiento inmediato (''plug and play'') a la interfaz de red. La configuración automática significa que un dispositivo obtendrá toda la información necesaria para su conexión a una red local IP sin ninguna intervención humana. En el caso ideal, cualquier usuario desempaca su nuevo equipo, lo conecta a la red local y lo ve funcionar sin tener que introducir la información propia de "especialistas". Ahora vamos a discutir otro aspecto de la configuración automática de IPv6, la auto-configuración de direcciones, que tiene como objetivos:

* La adquisición de una dirección cuando un dispositivo está conectado a una red por primera vez;
* la posibilidad de asignar otros prefijos, o de renumerar un dispositivo.

El proceso de configuración automática de direcciones IPv6 incluye la creación de una dirección local al enlace, la agregación a grupos multicast solicitados, la verificación de la unicidad de la dirección local al enlace y la creación de direcciones unicast global.

La tarea del enrutador es importante en la configuración automática. Indica a la máquina, mediante los bits de la cabecera (''cf'' [[#RA|anuncio de enrutador]]), del mensaje de anuncio de los enrutadores, el método a conservar y eventualmente proporcionar la información necesaria para su configuración. El bit <tt> M </tt> (''configuración de dirección administrada'') puesto a 1 indica que el equipo no debe crear por sí mismo una dirección a partir de su identificador de interfaz y de los prefijos recibidos, sino que debe solicitarla explícitamente ante un servidor de direcciones. El bit O <tt> </tt> (''otra configuración de estado'') indica que el dispositivo debe consultar el servidor para obtener otros parámetros distintos de la dirección. El algoritmo para el proceso de configuración automática de direcciones se desglosa de la siguiente manera:

* La primera fase consiste en crear la dirección local al enlace.
* Una vez que la unicidad de esta dirección es verificada, el dispositivo está listo para comunicarse con otras máquinas en el enlace.
* El dispositivo debe tratar de adquirir un mensaje de anuncio de enrutadores para determinar el método de obtención de la dirección unicast global.
* Si hay un enrutador en el enlace, el dispositivo debe aplicar el método especificado por el mensaje de anuncio de enrutadores, a saber:
** La configuración automática sin estado,
** la configuración automática con estado.
* Si no hay ningún enrutador en el enlace, el dispositivo debe tratar de obtener la dirección unicast global por el método de configuración automática con estado. Si el intento falla, no hay más que hacer. Las comunicaciones sólo podrán hacerse sobre el enlace con la dirección local al enlace, pues el dispositivo no tendrá una dirección con la cobertura necesaria que le permita comunicarse con otras máquinas fuera del enlace.

==Ciclo de vida de una dirección==

Al generalizar en IPv6 el plan de direccionamiento CIDR, los prefijos quedan, en todos los casos, siendo propiedad de los operadores. Ya no pueden otorgarse "a perpetuidad" a los dispositivos. Para facilitar la renumeración de una máquina, la asignación de una dirección a una interfaz es temporal, las direcciones IPv6 no se entregan, sino que se prestan. Se asocia un tiempo de vida a la dirección, que indica el tiempo durante el cual la dirección pertenece a la interfaz. Cuando el tiempo de vida se ha agotada, la dirección deja de ser válida, se suprime de la interfaz y queda potencialmente éste puede prolongarse indefinidamente. La dirección local al enlace tiene un tiempo de vida ilimitado.

<tikz title="Estados sucesivos de una dirección en una interfaz">

\draw [thick, ->] (0,2) -- (9.5,2);

\draw [->] (1,4) node [above=10pt] {\tiny{allocation}}-- (1,2);
\draw (1, 2) node [rectangle, minimum width=1cm, minimum height=1cm, fill, left color=black!10, right color=black!20, draw=black, above right] (tentative) {};
\draw (tentative.south east) node [rectangle, minimum width=3cm, minimum height=1cm, fill, left color=green, right color=green!50, draw=black, above right] (preferred) {};
\draw (preferred.south east) node [rectangle, minimum width=2cm, minimum height=1cm, fill, left color=orange , right color=orange!50!red, draw=black, above right] (deprecated) {};
\draw (deprecated.south east) node [rectangle, minimum width=2cm, minimum height=1cm, fill, color=red, draw=black, above right] (novalid) {};

\draw (tentative.text) node {\tiny{Tentative}};
\draw (preferred.text) node {\tiny{Preferred}};
\draw (deprecated.text) node {\tiny{Deprecated}};
\draw (novalid.text) node {\tiny{Invalid}};

\draw [dotted] (tentative.south west) -- +(0, -1);
\draw [dotted] (preferred.south west) -- +(0, -1);
\draw [dotted] (deprecated.south west) -- +(0, -1);
\draw [dotted] (novalid.south west) -- +(0, -1);

\draw [dashed, <->] ([yshift=-0.5cm]tentative.south west) -- node [above] {\tiny{DAD}} ([yshift=-0.5cm] preferred.south west) ;

\draw [dashed, <->] ([yshift=-0.5cm]preferred.south west) -- node [above] {\tiny{Valid}} ([yshift=-0.5cm] novalid.south west) ;

</tikz>

La renumeración de una interfaz consiste en pasar de una dirección a otra. Durante una renumeración, no es aconsejable cambiar repentinamente de dirección, de lo contrario, todas las comunicaciones TCP que la utilizan como identificador de conexión, se cortarían inmediatamente. Esto conllevaría importantes perturbaciones a nivel de las aplicaciones.

Por ello, para facilitar esta transición se implementó un mecanismo de obsolescencia que invalida gradualmente una dirección. Este mecanismo se sirve de la capacidad de asignación de varias direcciones válidas a una misma interfaz. Para elegir la dirección a utilizar, se le asocia un estado que indica en qué fase de su tiempo de vida se encuentra con respecto a la interfaz. El primero de esos estados se conoce como preferido: no hay ninguna restricción de uso. Poco antes de su invalidación, la dirección pasa a un estado de depreciado. En él se desaconseja el uso de la dirección, pero no está prohibido. Una dirección depreciada ya no debe ser utilizada como dirección fuente de nuevas comunicaciones (como el establecimiento de conexión TCP), pero todavía puede emplearse como dirección fuente de comunicaciones ya establecidas. Los paquetes recibidos a una dirección depreciada seguirán siendo entregados normalmente. El control de la duración de cada estad de una dirección válida se efectúa agregando un tiempo de vida al estado preferido.
La figura '''Estados sucesivos de una dirección en una interfaz''' representa los diferentes estados que toma una dirección cuando se asigna a una interfaz.

== Creación de la dirección local al enlace ==

<tikz title=" Creación de la dirección local al enlace">
\clip (0, 0) rectangle (10,7);
% \draw[help lines] (0,0) grid (10,7 );

\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,3)--(9,3);

\pgfputat{\pgfxy(0.8,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,5)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,3)--(1.5,5);
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (8,3)--(8,5);

\draw (1.5,4.5) node {\small{FE80::IID1}};
\draw (1.5,4) node {\small{$\alpha$::IID1/64}};

\draw (8, 4.5) node {\small{FE80::IID2}};

</tikz>

Durante la inicialización de la interfaz, el dispositivo construye un identificador de interfaz que debe ser único en el enlace. Este identificador se utiliza la dirección de [[ Identificador_de_interfaz#EUI-64 | EUI-64]]. El principio básico para crear la direcciónIPv6 consiste en unir un prefijo con el identificador. La dirección local al enlace se crea tomando el prefijo de Enlace_local (<tt>FE80::/64</tt>). La dirección creada de esa manera, todavía no puede ser utilizada; tiene un estado temporal pues el dispositivo debe comprobar la exclusividad de esta dirección en el enlace mediante el procedimiento de detección de direcciones duplicadas. Si se encuentra que la dirección local al enlace no es única, se suspende la autoconfiguración y será necesario proceder a una configuración manual.

Una vez que se ha asegurado la unicidad de la dirección local al enlace, ésta se considera una dirección válida para la interfaz, con lo que termina la prima fase del proceso de autoconfiguración.

==<div id="DAD"> Detección de una dirección duplicada </div>==

<tikz title="Emisión de un NS en una detección de Dir. duplicada (DAD)">
\clip (0, 0) rectangle (10,7);
% \draw[help lines] (0,0) grid (10,7 );

\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,3)--(9,3);

\pgfputat{\pgfxy(0.8,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,5)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,3)--(1.5,5);
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (8,3)--(8,5);

\draw (7.8, 5) -- (7.8, 3.2);
\draw [<->] (1, 3.2) -- node [above] {\tiny{::/0 -$>$ solicited (FE80:IID2) : NS (who has FE80::IID2?)}}(9, 3.2) ;

</tikz>

Para comprobar la exclusividad de direcciones locales al enlace o de direcciones unicast, los dispositivos deben ejecutar un algoritmo de detección de direcciones duplicadas (DAD) antes poder utilizarlas. El algoritmo usa los mensajes ICMPv6 [[Protocolo_de_Descubrimiento_de_vecinos#NS|solicitud de un vecino]] y [[Protocolo_de_Descubrimiento_de_vecinos#NA|anuncio de un vecino.]] Si se detecta una dirección que ya está en uso, ésta no podrá ser asignada a la interfaz, la autoconfiguración automática debe suspenderse y será necesario proceder a una configuración manual. Durante la ejecución del algoritmo DAD, la dirección es considerada como "provisional" hasta tener la confirmación de su unicidad. Una dirección provisional se asigna a una interfaz únicamente para recibir los mensajes de solicitud y anuncio de un vecino. Otros mensajes recibidos, son ignorados. El algoritmo DAD consiste en enviar un mensaje de solicitud de un vecino colocando en el campo de dirección objetivo la dirección provisional. Para distinguir el algoritmo DAD del de Descubrimiento de vecinos, el paquete IPv6 que contiene un mensaje de solicitud de un vecino tiene como dirección fuente una dirección no determinada. Así se presentan tres casos:

* Se recibe un mensaje de anucio de un vecino: Significa que la dirección provisional está siendo utilizada como válida por otro dispositivo, por lo que ésta no es única y no puede ser retenida por el dispositivo.
* Se recibe un mensaje de solicitud de un vecino como parte del algoritmo DAD. La dirección provisional también es provisional para otra máquina. En este caso, la dirección provisional no puede ser utilizada por ninguna de ellas.
* No se recibe ningún mensaje durante un segundo (valor por omisión). La dirección provisional es única, por lo que su estado pasa de provisional a válida y se le asigna a la interfaz.

Obsérvese que este algoritmo no proporciona una fiabilidad absoluta, especialmente cuando el enlace está segmentado.

== Autoconfiguración sin estado ==

<tikz title="Emisión de un RS">
\clip (0, 0) rectangle (10,7);
% \draw[help lines] (0,0) grid (10,7 );

\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,3)--(9,3);

\pgfputat{\pgfxy(0.8,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,5)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,3)--(1.5,5);
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (8,3)--(8,5);

\draw (7.8, 5) -- (7.8, 3.2);
\draw [<->] (1, 3.2) -- node [above] {\tiny{FE80::IID2 -$>$ FF02::2 : RS }} (9, 3.2) ;

</tikz>

La configuración automática sin estado (RFC 2462) no requiere de ninguna configuración manual de los dispositivos, una configuración mínima para los enrutadores, y tampoco necesita de servidores adicionales. Se sirve del protocolo ICMPv6 y puede operar aún sin la presencia de enrutadores. En cambio, sí requiere de una subred con soporte a la difusión de paquetes. Este método sólo aplica para los dispositivos; no puede ser utilizada para configurar enrutadores. El principio básico de este mecanismo consiste en que una máquina genera su dirección IPv6 a partir de información local y de la proporcionada por un enrutador. El enrutador proporciona información sobre la subred asociada al enlace; anuncia el prefijo.

{{eSuivi|Tabla de contenido|Incio del capítulo|DHCPv6|DHCPv6}}

Protocolo de Descubrimiento de vecinos

2012-07-04T22:06:48Z

Jincera: /* Detección de una dirección duplicada */

{{eSuivi|Tabla de contenido|Incio del capítulo|DHCPv6|DHCPv6}}

__TOC__

El protocolo de descubrimiento de vecinos (NDP, ''Neighbor Discovery Protocol'') permite a un dispositivo integrarse en el ambiente local, es decir, el enlace sobre el cual se transmiten físicamente los paquetes IPv6. Permite establecer un diálogo con los equipos (estaciones y enrutadores) conectados sobre el mismo medio. No se pretende que un dispositivo conozca con exactitud la lista de todos los demás dispositivos conectados al enlace, sino de proveer un mecanismo para dialogar con quien necesite hacerlo.

El protocolo utiliza cinco tipos de mensajes ICMPv6 (ver Valores de los campos de tipo y código de ICMPv6). El campo número de saltos de la cabecera IPv6 contiene el valor 255. Este valor parece demasiado grande para datagramas que no debieran ser enrutados fuera del enlace físico. En realidad, si un equipo recibe un datagrama con un valor menor, significa que la información proviene de otra red y que ya ha atravesado al menos un enrutador. Por ello, los datagramas que tienen un valor diferente de 255 deben ser ignorados por el receptor.

{{Tableau eICMPv6}}

El protocolo realiza varias funciones:

* Resolución de direcciones. El principio es muy similar al del protocolo ARP de IPv4. La principal diferencia consiste en el uso de mensajes ICMPv6 estándar en lugar de definir otro protocolo de capa 3. Con esto se consigue una mayor flexibilidad de uso, especialmente en las redes que no soportan la difusión de mensajes. Al igual que en IPv4, el protocolo se encarga de construir tablas de correspondencia entre las direcciones IPv6 y las físicas.
* <div vecinos id="NUD"> Detección de inaccesibilidad de vecinos (NUD, ''Neighbor Unreachability Detection''). Esta función, que no existe en IPv4, permite eliminar de las tablas de configuración de un equipo, los vecinos que se han vuelto inaccesibles (por fallas, cambio de domicilio, ...). Si un enrutador deja de estar disponible, la tabla de enrutamiento puede ser modificada para considerar otra ruta. </div>
* Configuración. La configuración automática de los dispositivos es uno de los principales atractivos de IPv6. Se implementan varias funcionalidades del protocolo de descubrimiento de vecinos:
**Descubrimiento de enrutadores. Este protocolo permite que los dispositivos identifiquen a los enrutadores que se encuentran en su enlace físico. En IPv4, esta función la proporciona el protocolo ''ICMP Router Discovery''.
** Descubrimiento de prefijos. El dispositivo conoce el o los prefijos de red de acuerdo a los anuncios realizados por los enrutadores. Agregando su identificador de interfaz, el dispositivo construye su o sus direcciones IPv6. No hay un mecanismo equivalente para las direcciones IPv4 ya que son demasiado cortas para realizar la auto-configuración.
** Detección de direcciones duplicadas. Dado que las direcciones se configuran de forma automática, existen riesgos de error en caso de tener equipos con identificadores repetidos. Este protocolo verifica que ningún otro equipo en el enlace tiene la misma dirección IPv6. Esta función es una evolución del ARP gratuito en IPv4 emitido durante la inicialización de la interfaz.
** Descubrimiento de parámetros. Este protocolo permite que los dispositivos conozcan los distintos parámetros del enlace físico, por ejemplo, el tamaño de MTU, el número máximo de saltos permitido (valor original del campo número de saltos), si la configuración automática con estado (como [[Configuración con estado: DHCPv6|DHCPv6]]) está activa, etc. No existe un equivalente de esta funcionalidad en IPv4.
* Indicación de redirección. Este mensaje se utiliza cuando un enrutador conoce una trayectoria mejor (medida en número de saltos) para alcanzar un destino.
:En IPv4 una indicación de redireccionamiento sólo puede servir para corregir la dirección del enrutador utilizado para acceder a una máquina fuera de la red local. Los dispositivos deben conocer todas las direcciones correspondientes a equipos conectados en su propia red local.
:EnIPv6, la correspondencia entre prefijo y red local es menos rígida. Es de esperar que un dispositivo no conozca todos los prefijos de su red local (si ésta es compartida por varios prefijos), o que un prefijo se comparta entre varios enlaces (lo que corresponde a una generalización del modelo de redes lógicas IP sobre ATM). Bajo algunas configuraciones, la máquina emitirá sus paquetes al enrutador aún si el destinatario se encuentra en el mismo segmento que el emisor. En este caso, el enrutador emitirá un mensaje de redirección para que la continuación del diálogo entre ellos haga de manera directa (véanse los ejemplos [[#IR|Indicación redirección]]).
:En el caso más extremo, podría imaginarse en IPv6 que un dispositivo puede ser configurado para comunicarse únicamente con su enrutador por omisión. ICMPv6 ''redirect'' puede utilizarse entonces, para informar al dispositivo de destinatarios ubicados en el mismo enlace.

En IPv6 se especifican dos métodos de autoconfiguración para las direcciones unicast global:

* Autoconfiguración sin estado (''stateless autoconfiguration'', RFC 2462). Se utiliza cuando no es necesaria una gestión administrativa de las direcciones asignadas dentro de un sitio. Estos mecanismos se describen más adelante en este capítulo.
* Autoconfiguración con estado (''statefull autoconfiguration''). Se utiliza cuando un sitio requiere de un control estricto de la asignación de direcciones (''cf'' [[Configuración con estado: DHCPv6 | DHCPv6]]).

Sin embargo, el uso de DHCPv6 para obtener la dirección se controla mediante el protocolo de descubrimiento de vecinos.

= Datos transmitidos por los mensajes =

La principal motivación detrás del Protocolo de Descubrimiento de vecinos es unificar varios protocolos existentes en IPv4. En particular, la mayor parte de los datos utiliza un formato de opciones común, lo que simplifica la implementación del protocolo. El formato contiene los campos: tipo, longitud (en palabras de 64 bits), y datos. La baja precisión de campo longitud, presentará un desperdicio de espacio, pero permite una alineación de las opciones en palabras de 64 bits, lo que permite un procesamiento optimizado.

{{NB-Opciones}}

== <div id="física">Dirección física de la fuente/destino</div> ==

<tikz title="Formato de la opción dirección física fuente/destino">
\clip (0.2, 5.7) rectangle (11.1,6.7);
% \draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=1/2}};
\draw (2.9, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{lenght }};
\draw (5.3, 6) node (addr) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Link Layer Address}};

\draw [draw=white, thick] (addr.north east) -- (addr.south east);
\draw [draw=white, thick] (addr.north east) -- +(-2, 0);
\draw [draw=white, thick] (addr.south east) -- +(-2, 0);

\draw [dashed] (addr.north east) -- (addr.south east);
\draw [dashed] (addr.north east) -- +(-2, 0);
\draw [dashed] (addr.south east) -- +(-2, 0);
</tikz>

La figura ''Formato de la opción dirección física fuente/destino'' presenta estas opciones. El tipo 1 designa la dirección física de la fuente y el tipo 2 la dirección del destino.

El campo ''length'' es el tamaño en palabras de 64 bits de la opción. Por lo tanto, para el caso de una dirección MAC con longitud de 6 octetos, contiene el valor 1.

El RFC 2464 define el formato para las direcciones MAC-48 utilizadas en las redes Ethernet y Wi-Fi. El RFC 4944 define el formato para las direcciones MAC-16 y MAC-64 utilizadas en las redes de sensores bajo la norma IEEE 802.15.4.

== <div id="información">Información sobre el prefijo</div> ==

<tikz title="Formato de la opción información sobre el prefijo">
\clip (0.2, 2) rectangle (11.1, 7);
% \draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=3}};
\draw (2.9, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{length =4 }};
\draw (5.3, 6) node (addr) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm] {\tiny{Prefix Length}};
\draw (7.7, 6) node (bitL) [right, shade, top color=blue!15, bottom color=blue!5,, draw, minimum height=0.5cm, minimum width=.3cm]{}; \draw (bitL.text) node {\tiny{L}};
\draw (8, 6) node (bitA) [right, shade, top color=blue!15, bottom color=blue!5,, draw, minimum height=0.5cm, minimum width=.3cm]{};\draw (bitA.text) node {\tiny{A}};
\draw (8.3, 6) node (bitR) [right, shade, top color=blue!15, bottom color=blue!5,, draw, minimum height=0.5cm, minimum width=.3cm]{};\draw (bitR.text) node {\tiny{R}};
\draw (8.6, 6) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=1.5cm] {\tiny{Reserved}};

\draw (0.5, 5.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Valid Lifetime}};

\draw (0.5, 5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Prefered Lifetime}};

\draw (0.5, 4.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Reserved}};

\draw (0.5, 4) node (addr1) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{}};
\draw (0.5, 3.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{}};
\draw (0.5, 3) node (addr3) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Prefix}};
\draw (0.5, 2.5) node (addr4) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{}};

\draw [color=blue!10, very thick] (addr1.south east) -- (addr1.south west);
\draw [color=blue!10, very thick] (addr2.south east) -- (addr2.south west);
\draw [color=blue!10, very thick] (addr3.south east) -- (addr3.south west);
</tikz>

Esta opción contiene las informaciones sobre el prefijo para permitir una configuración automática de los dispositivos. El campo tipo tiene el valor 3 y el de longitud, 4. La figura ''Formato de la opción información sobre el prefijo'' muestra el formato de esta opción:

* El campo ''Prefix lenght'' indica cuántos bits son significativos para el prefijo anunciado en un campo siguiente.
* El bit <tt>L</tt> indica, cuando vale 1, que el prefijo permite indicar que todos los demás dispositivos que comparten el mismo prefijo, están en el mismo enlace, por lo que el emisor puede contactarlos directamente. En caso contrario, el dispositivo envía el paquete hacia el enrutador. Si éste último sabe que el emisor puede contactar directamente al destinatario, emitirá un mensaje ICMPv6 de indicación de redirección.
* El bit <tt>A</tt> indica, cuando vale 1, que el prefijo anunciado puede utilizarse para formar la dirección del dispositivo.
* El bit <tt>R</tt>, indica, cuando vale 1, que el campo prefijo contiene la dirección global de un enrutador ''agente base''. Los bits de mayor peso aún pueden utilizarse para formar un prefijo.
* El campo duración de validez indica, en segundos, la duración durante la cual el prefijo es válido.
* El campo duración preferente indica la duración, en segundos, durante la cual una dirección formada con el protocolo de configuración sin estado se mantiene ''preferente'' (''cf'' [[Planes de direccionamiento|Tiempo de vida de las direcciones]]).

Para estos dos campos, un valor de <tt>0xffffffff</tt> representa una duración infinita. Estos campos pueden servir durante la fase de transición de un proveedor de acceso a otro; es decir, de un prefijo a otro.
* El campo reservado permite alinear el prefijo a una frontera de palabra de 64 bits.
* El campo prefijo contiene el valor de prefijo anunciado sobre el enlace. Para mantener una alineación de 64 bits para el resto de datos del paquete, este campo tiene una longitud fija de 128 bits.

== <div id="redirigida">Cabecera de redirección </div> ==

<tikz title="Formato de la opción cabecera de redirección">
\clip (0.2, 3.1) rectangle (11.1, 7);
% \draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=5}};
\draw (2.9, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{length =1 }};
\draw (5.3, 6) node (addr) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Reserved}};

\draw (0.5, 5.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Reserved}};

\draw (0.5, 4.25) node (context) [right, shade, top color=purple!50, bottom color=purple!10, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{IPv6 Header and Data}};
</tikz>

Esta opción es utilizada por el mensaje de indicación de redirección. Permite encapsular los primeros octetos del paquete IPv6 que provocó la emisión de este mensaje, como ocurre con los mensajes de error de ICMPv6.

El campo tipo tiene el valor 4. El tamaño de esta opción debe evitar que el paquete IPv6 rebase los 1280 octetos (''cf'' figura ''Formato de la opción cabecera de redirección''). Sin embargo, el paquete debe contener la mayor cantidad de información posible.

== <div id="MTU">MTU</div> ==

<tikz title="Formato de la opción MTU">

\clip (0.2, 5.1) rectangle (11.1, 7);
% \draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=5}};
\draw (2.9, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{lenght =1 }};
\draw (5.3, 6) node (addr) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Reserved}};

\draw (0.5, 5.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{MTU}};
</tikz>

Esta opción permite notificar a los dispositivos el tamaño máximo de datos que pueden ser transmitidos sobre el enlace. La figura ''Formato de la opción MTU'' muestra su estructura. No es necesario difundir esta información si el dispositivo utiliza siempre el tamaño máximo permitido. Por ejemplo, sobre las redes Ethernet, los dispositivos utilizarán el valor 1,500. En cambio, en las redes Token Ring o FDDI, con frecuencia es necesario especificar si los equipos pueden utilizar la longitud máxima o un tamaño inferior para permitir el uso de puentes en la red.

En esta opción, el campo tipo tiene un valor de 5 y el de longitud, de 1.

=Mensajes estándar de Descubrimiento de vecinos =

Además de las cinco opciones básicas descritas en la tabla ''Utilización de las opciones en los mensajes de descubrimiento de vecinos'', existen otras específicas para la movilidad y para las redes NBMA (''Non Broadcast Multiple Access'').

{|
|+ Utilización de las opciones en los mensajes de descubrimiento de vecinos
| width = 150 | || width = 100 |[[#RS|Solicitud de]] || width = 100 |[[#RA|Anuncio de]] || width = 100 |[[#NS|Solicitud de]] ||width = 100 | [[#NA|Anuncio de]] ||width = 100 |[[#IR|Indicación de]]
|-
| || [[#RS|enrutador]] || [[#RA|enrutador]] || [[#NS|un vecino]] || [[#NA| un vecino]] || [[#IR|redirección]]
|-style="background:silver"
|[[#física |Dirección física de la fuente]] || presente || presente || presente || ||
|-
|[[# física | Dirección física del destino]] || || || || presente || presente
|-style="background:silver"
|[[#información|Información sobre el prefijo]] || || ≥ 1 || || ||
|-
|[[#redirigida |Cabecera de redirección]] || || || || || presente
|-style="background:silver"
| [[#MTU |MTU]] || || posible || || ||
|}

Las distintas funcionalidades de descubrimiento de vecinos utilizan cinco mensajes: dos para el diálogo entre un dispositivo y un enrutador, dos para el diálogo entre vecinos, y uno para la redirección. Cada uno de estos mensajes puede incluir opciones adicionales.

== <div id="RS">Solicitud de enrutador</div> ==

<tikz title="Formato de los paquetes de solicitud de enrutador">
\clip (0.2, 3.5) rectangle (11.1,7.1);
%\draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=133}};
\draw (2.9, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code =0 }};
\draw (5.3, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};
\draw (0.5, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Reserved}};

\draw (0.5, 4.25) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Options:\\
- Source link-layer address
}};
</tikz>

El mensaje de solicitud de enrutador (''cf'' figura Formato de los paquetes de solicitud de enrutador) es emitido al iniciar un dispositivo para recibir más rápidamente la información del enrutador. Este mensaje se envía a la dirección IPv6 multicast reservada a los enrutadores en el mismo enlace <tt>FF02::2</tt>. Si el dispositivo aún no conoce su dirección fuente, se utiliza la dirección no especificada.

El campo opción normalmente contiene la dirección física del dispositivo.

== <div id="RA">Anuncio de enrutador</div> ==

<tikz title="Formato de los paquetes de anuncio de enrutador">
\clip (0.2, 1.5) rectangle (11.1,7.1);
%\draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=134}};
\draw (2.9, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code =0 }};
\draw (5.3, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};

\draw (0.5, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Cur. Hop Lim.}};
\draw (2.9, 5.5) node (bitM) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{}; \draw (bitM.text) node {\tiny{M}};
\draw (3.2, 5.5) node (bitO) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{};\draw (bitO.text) node {\tiny{O}};
\draw (3.5, 5.5) node (bitH) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{};\draw (bitH.text) node {\tiny{H}};
\draw (3.8, 5.5) node (res) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=1.5cm]{\tiny{reserved}};
\draw (5.3, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Router Lifetime}};

\draw (0.5, 5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=9.6cm]{\tiny{Reachable Time}};
\draw (0.5, 4.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=9.6cm]{\tiny{Retrans Time}};

\draw (0.5, 3.25) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Options:\\
Source link-layer address\\
MTU\\
Prefix Information (may be repeated)\\
}};
</tikz>

Este mensaje (''cf'' figura ''Formato de los paquetes de anuncio de enrutador'') es emitido periódicamente por los enrutadores, o bien, en respuesta a un mensaje de solicitud de enrutador generado por un dispositivo. El campo dirección fuente contiene la dirección de enlace local del enrutador, mientras que el campo dirección destino contiene la dirección del dispositivo que generó la solicitud, o la dirección de todas las estaciones (<tt>ff02::01</tt>).

Cuando el campo de máximo número de saltos tiene un valor distinto de cero, muestra el valor que podría colocarse en el campo de número de saltos de los paquetes emitidos. El bit <tt>M</tt> indica que una dirección del dispositivo debe ser obtenida mediante un protocolo de configuración (''cf'' [[Configuración con estado:DHCPv6]]). El bit <tt>O</tt> también indica la presencia de un servicio de configuración para obtener información adicional a la dirección. Si no es posible obtener la dirección mediante un servidor, el dispositivo procede a realizar una configuración sin estado, concatenando su identificador de interfaz a los prefijos que conoce. El bit <tt>H</tt> indica que el enrutador puede ser utilizado como agente base por un nodo móvil (''cf'' [[Desplazamientos_de_móviles#Anuncio_del_agente_base |Anuncio del agente base]]).

El campo tiempo de vida del enrutador indica el período (en segundos) durante el cual el equipo que emite el anuncio realizará funciones de enrutador por omisión. El valor máximo corresponde a 18 horas 12 minutos, pero como este mensaje se emite periódicamente, en la práctica no existe un límite para el tiempo de vida de un enrutador. Un valor de <tt>0</tt> indica que el dispositivo no cumple con las funciones de enrutador por omisión. Este tiempo de vida no se aplica a las opciones transportadas por este mensaje.

El campo duración de accesibilidad indica el período (en milisegundos) durante el cual una información almacenada en la memoria caché de la máquina (por ejemplo, la tabla de correspondencia entre las direcciones IPv6 y las físicas) puede ser considerada como válida. Al vencimiento de este tiempo, se emite un mensaje de detección de inaccesibilidad para verificar la pertinencia de la información almacenada.

El campo temporización de retransmisión muestra el período (en milisegundos) entre dos emisiones no solicitadas de este mensaje. Permite que los demás equipos puedan detectar la inaccesibilidad de un enrutador.

Este mensaje puede transportar las siguientes opciones:

* dirección física de la fuente,
* MTU,
* información sobre el prefijo (uno o varios).

== <div Id="NS"> Solicitud de un vecino </div> ==

<tikz title="Formato de los paquetes de solicitud de un vecino">

\clip (0.2, 1.5) rectangle (11.1,7.1);
%\draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=135}};
\draw (2.9, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code =0 }};
\draw (5.3, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};

\draw (0.5, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=9.6cm]{\tiny{Reserved}};

\draw (0.5, 4.25) node (context) [right, shade, top color=blue!50, bottom color=blue=!10, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Target Address}};

\draw (0.5, 2.25) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Options:\\
Source link-layer address\\
}};
</tikz>

Este mensaje (''cf'' figura ''Formato de los paquetes de solicitud de un vecino'') permite obtener información a partir de un equipo vecino, es decir, localizado en el mismo enlace físico (o conectado a través de puentes). El mensaje puede ser emitido explícitamente a él, o enviado con una dirección de difusión. En el caso de determinación de la dirección física, éste corresponde a la solicitud de ARP en IPv4.

El campo dirección fuente del paquete IPv6 contiene ya sea la dirección local al enlace, una dirección global o la dirección no especificada. El campo destino puede contener la dirección de difusión múltiple solicitada correspondiente a la dirección buscada (''cf'' [[Direccionamiento_multicast#Identificador_de_grupo|Identificador de grupo]]) o la dirección del dispositivo (en el caso de una detección de inaccesibilidad de vecinos, ''NUD'').

El campo dirección del destino contiene la dirección IPv6 del equipo buscado. El campo opción generalmente contiene la dirección física de la fuente.

== <div Id="NA"> Anuncio de un vecino</div> ==

<tikz title="Formato de los paquetes de anuncio de un vecino">

\clip (0.2, 1.5) rectangle (11.1,7.1);
%\draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=136}};
\draw (2.9, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code =0 }};
\draw (5.3, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};

\draw (0.5, 5.5) node (bitR) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{}; \draw (bitR.text) node {\tiny{R}};
\draw (0.8, 5.5) node (bitS) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{}; \draw (bitS.text) node {\tiny{S}};
\draw (1.1, 5.5) node (bitO) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{}; \draw (bitO.text) node {\tiny{O}};
\draw (1.4, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=8.7cm]{\tiny{Reserved}};

\draw (0.5, 4.25) node (context) [right, shade, top color=blue!50, bottom color=blue=!10, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Target Address}};

\draw (0.5, 2.25) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Options:\\
Source link-layer address\\
}};
</tikz>

Este mensaje (''cf'' figura ''Formato de los paquetes de anuncio de un vecino'') se emite en respuesta a una solicitud, aunque también puede ser emitido de forma espontánea para propagar la información de cambio de dirección física, o del estado de "enrutador". Para el caso de la determinación de la dirección física, es equivalente a la respuesta ARP en IPv4.

* El bit <tt> R </tt> se pone a 1 si el remitente es un enrutador. Este bit se utiliza para permitir la detección de un enrutador que se convierte en un equipo ordinario.
* El bit <tt> S </tt> en 1 indica que este anuncio se emite en respuesta a una solicitud.
* El bit <tt> O </tt> en 1 indica que este anuncio debe borrar las informaciones anteriores que se encuentran almacenadas en la memoria cachés de otros equipos, en especial la tabla que contiene las direcciones físicas.
* El campo dirección del destino contiene, si el bit<tt> S </tt> es 1, el valor del campo dirección del destino de la solicitud a la que está respondiendo este mensaje. Si el bit <tt> S </tt> es 0, este campo contiene la dirección IPv6 local al enlace del equipo emisor.
* La opción dirección física del destino contiene la dirección física del emisor.

== <div id="IR">Indicación de redirección</div> ==

<tikz title="Formato de los paquetes de indicación de redirección">
\clip (0.2, 0) rectangle (11.1,7.1);
%\draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=137}};
\draw (2.9, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code =0 }};
\draw (5.3, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};

\draw (0.5, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=9.6cm]{\tiny{Reserved}};

\draw (0.5, 4.25) node (context) [right, shade, top color=blue!50, bottom color=blue=!10, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Target Address}};

\draw (0.5, 2.25) node (context) [right, shade, top color=blue!50, bottom color=blue=!10, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Destination Address}};

\draw (0.5, 0.5) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=1.5cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Options:\\
Target link-layer address\\
Redirected Header\\
}};
</tikz>

La técnica de redirección es la misma que en IPv4. Un dispositivo sólo conoce los prefijos de las redes a las que está conectado directamente y la dirección de un enrutador por omisión. Si la ruta se puede optimizar, el enrutador por omisión envía un mensaje para indicar que existe un camino más corto. De hecho, como en IPv6 el enrutador por omisión se establece de forma automática, las rutas no necesariamente son las mejores (''cf'' figura ''Enrutamiento por omisión no óptimo'').

Otro caso particular en IPv6 ocurre con los dispositivos que se encuentran en el mismo enlace físico, pero tienen diferentes prefijos. La comunicación entre ellos pasa inicialmente a traves de enrutador por omisión hasta que éste notifica que existe una ruta directa entre ellos.

La figura ''Formato de los paquetes de indicación de redirección'' muestra el formato del mensaje:

* El campo dirección objetivo (''Target address'') contiene la dirección IPv6 del equipo hacia el que los paquetes deben ser enviados.
* El campo dirección destino contiene la dirección IPv6 del dispositivo que está siendo redirigido hacia la dirección objetivo.

Cuando la redirección apunta a un dispositivo situado en el mismo enlace, la dirección objetivo y de destino son las mismas.

Las opciones incluyen la dirección física de un nuevo enrutador y la cabecera del paquete redirigido.

Este mensaje se puede utilizar de la misma forma que en IPv4. Un dispositivo solamente tiene una ruta por omisión para acceder a equipos con un prefijo diferente. En consecuencia, envía su paquete al enrutador por omisión, quien observa que el prefijo destino es accesible a través de la misma subred que el emisor. El enrutador por omisión reenvía el paquete y notifica al emisor que puede contactar directamente a las máquinas que poseen el prefijo del destino.

IPv6 también utiliza este mensaje para optimizar la resolución fuera del enlace para el [[#Caso de redes NBMA |caso de redes NBMA]].

= Configuración automática =
Tradicionalmente, la configuración de una interfaz de red de una máquina se hacía manualmente. Esto suele ser un trabajo lento y propenso a errores. Con IPv6, se automatiza el proceso de configuración y se introducen, al mismo tiempo, mecanismos de funcionamiento inmediato (''plug and play'') a la interfaz de red. La configuración automática significa que un dispositivo obtendrá toda la información necesaria para su conexión a una red local IP sin ninguna intervención humana. En el caso ideal, cualquier usuario desempaca su nuevo equipo, lo conecta a la red local y lo ve funcionar sin tener que introducir la información propia de "especialistas". Ahora vamos a discutir otro aspecto de la configuración automática de IPv6, la auto-configuración de direcciones, que tiene como objetivos:

* La adquisición de una dirección cuando un dispositivo está conectado a una red por primera vez;
* la posibilidad de asignar otros prefijos, o de renumerar un dispositivo.

El proceso de configuración automática de direcciones IPv6 incluye la creación de una dirección local al enlace, la agregación a grupos multicast solicitados, la verificación de la unicidad de la dirección local al enlace y la creación de direcciones unicast global.

La tarea del enrutador es importante en la configuración automática. Indica a la máquina, mediante los bits de la cabecera (ver [[#RA|anuncio de enrutador]]), del mensaje de anuncio de los enrutadores, el método a conservar y eventualmente proporcionar la información necesaria para su configuración. El bit <tt> M </tt> (''configuración de dirección administrada'') puesto a 1 indica que el equipo no debe crear por sí mismo una dirección a partir de su identificador de interfaz y de los prefijos recibidos, sino que debe solicitarla explícitamente ante un servidor de direcciones. El bit O <tt> </tt> (''otra configuración de estado'') indica que el dispositivo debe consultar el servidor para obtener otros parámetros distintos de la dirección. El algoritmo para el proceso de configuración automática de direcciones se desglosa de la siguiente manera:

* La primera fase consiste en crear la dirección local al enlace.
* Una vez que la unicidad de esta dirección es verificada, el dispositivo está listo para comunicarse con otras máquinas en el enlace.
* El dispositivo debe tratar de adquirir un mensaje de anuncio de enrutadores para determinar el método de obtención de la dirección unicast global.
* Si hay un enrutador en el enlace, el dispositivo debe aplicar el método especificado por el mensaje de anuncio de enrutadores, a saber:
** La configuración automática sin estado,
** la configuración automática con estado.
* Si no hay ningún enrutador en el enlace, el dispositivo debe tratar de obtener la dirección unicast global por el método de configuración automática con estado. Si el intento falla, no hay más que hacer. Las comunicaciones sólo podrán hacerse sobre el enlace con la dirección local al enlace, pues el dispositivo no tendrá una dirección con la cobertura necesaria que le permita comunicarse con otras máquinas fuera del enlace.

==Ciclo de vida de una dirección==

Al generalizar en IPv6 el plan de direccionamiento CIDR, los prefijos quedan, en todos los casos, siendo propiedad de los operadores. Ya no pueden otorgarse "a perpetuidad" a los dispositivos. Para facilitar la renumeración de una máquina, la asignación de una dirección a una interfaz es temporal, las direcciones IPv6 no se entregan, sino que se prestan. Se asocia un tiempo de vida a la dirección, que indica el tiempo durante el cual la dirección pertenece a la interfaz. Cuando el tiempo de vida se ha agotada, la dirección deja de ser válida, se suprime de la interfaz y queda potencialmente éste puede prolongarse indefinidamente. La dirección local al enlace tiene un tiempo de vida ilimitado.

<tikz title="Estados sucesivos de una dirección en una interfaz">

\draw [thick, ->] (0,2) -- (9.5,2);

\draw [->] (1,4) node [above=10pt] {\tiny{allocation}}-- (1,2);
\draw (1, 2) node [rectangle, minimum width=1cm, minimum height=1cm, fill, left color=black!10, right color=black!20, draw=black, above right] (tentative) {};
\draw (tentative.south east) node [rectangle, minimum width=3cm, minimum height=1cm, fill, left color=green, right color=green!50, draw=black, above right] (preferred) {};
\draw (preferred.south east) node [rectangle, minimum width=2cm, minimum height=1cm, fill, left color=orange , right color=orange!50!red, draw=black, above right] (deprecated) {};
\draw (deprecated.south east) node [rectangle, minimum width=2cm, minimum height=1cm, fill, color=red, draw=black, above right] (novalid) {};

\draw (tentative.text) node {\tiny{Tentative}};
\draw (preferred.text) node {\tiny{Preferred}};
\draw (deprecated.text) node {\tiny{Deprecated}};
\draw (novalid.text) node {\tiny{Invalid}};

\draw [dotted] (tentative.south west) -- +(0, -1);
\draw [dotted] (preferred.south west) -- +(0, -1);
\draw [dotted] (deprecated.south west) -- +(0, -1);
\draw [dotted] (novalid.south west) -- +(0, -1);

\draw [dashed, <->] ([yshift=-0.5cm]tentative.south west) -- node [above] {\tiny{DAD}} ([yshift=-0.5cm] preferred.south west) ;

\draw [dashed, <->] ([yshift=-0.5cm]preferred.south west) -- node [above] {\tiny{Valid}} ([yshift=-0.5cm] novalid.south west) ;

</tikz>

La renumeración de una interfaz consiste en pasar de una dirección a otra. Durante una renumeración, no es aconsejable cambiar repentinamente de dirección, de lo contrario, todas las comunicaciones TCP que la utilizan como identificador de conexión, se cortarían inmediatamente. Esto conllevaría importantes perturbaciones a nivel de las aplicaciones.

Por ello, para facilitar esta transición se implementó un mecanismo de obsolescencia que invalida gradualmente una dirección. Este mecanismo se sirve de la capacidad de asignación de varias direcciones válidas a una misma interfaz. Para elegir la dirección a utilizar, se le asocia un estado que indica en qué fase de su tiempo de vida se encuentra con respecto a la interfaz. El primero de esos estados se conoce como preferido: no hay ninguna restricción de uso. Poco antes de su invalidación, la dirección pasa a un estado de depreciado. En él se desaconseja el uso de la dirección, pero no está prohibido. Una dirección depreciada ya no debe ser utilizada como dirección fuente de nuevas comunicaciones (como el establecimiento de conexión TCP), pero todavía puede emplearse como dirección fuente de comunicaciones ya establecidas. Los paquetes recibidos a una dirección depreciada seguirán siendo entregados normalmente. El control de la duración de cada estad de una dirección válida se efectúa agregando un tiempo de vida al estado preferido.
La figura '''Estados sucesivos de una dirección en una interfaz''' representa los diferentes estados que toma una dirección cuando se asigna a una interfaz.

== Creación de la dirección local al enlace ==

<tikz title=" Creación de la dirección local al enlace">
\clip (0, 0) rectangle (10,7);
% \draw[help lines] (0,0) grid (10,7 );

\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,3)--(9,3);

\pgfputat{\pgfxy(0.8,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,5)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,3)--(1.5,5);
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (8,3)--(8,5);

\draw (1.5,4.5) node {\small{FE80::IID1}};
\draw (1.5,4) node {\small{$\alpha$::IID1/64}};

\draw (8, 4.5) node {\small{FE80::IID2}};

</tikz>

Durante la inicialización de la interfaz, el dispositivo construye un identificador de interfaz que debe ser único en el enlace. Este identificador se utiliza la dirección de [[ Identificador_de_interfaz#EUI-64 | EUI-64]]. El principio básico para crear la direcciónIPv6 consiste en unir un prefijo con el identificador. La dirección local al enlace se crea tomando el prefijo de Enlace_local (<tt>FE80::/64</tt>). La dirección creada de esa manera, todavía no puede ser utilizada; tiene un estado temporal pues el dispositivo debe comprobar la exclusividad de esta dirección en el enlace mediante el procedimiento de detección de direcciones duplicadas. Si se encuentra que la dirección local al enlace no es única, se suspende la autoconfiguración y será necesario proceder a una configuración manual.

Una vez que se ha asegurado la unicidad de la dirección local al enlace, ésta se considera una dirección válida para la interfaz, con lo que termina la prima fase del proceso de autoconfiguración.

==<div id="DAD"> Detección de una dirección duplicada </div>==

<tikz title="Emisión de un NS en una detección de Dir. duplicada (DAD)">
\clip (0, 0) rectangle (10,7);
% \draw[help lines] (0,0) grid (10,7 );

\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,3)--(9,3);

\pgfputat{\pgfxy(0.8,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,5)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,3)--(1.5,5);
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (8,3)--(8,5);

\draw (7.8, 5) -- (7.8, 3.2);
\draw [<->] (1, 3.2) -- node [above] {\tiny{::/0 -$>$ solicited (FE80:IID2) : NS (who has FE80::IID2?)}}(9, 3.2) ;

</tikz>

Para comprobar la exclusividad de direcciones locales al enlace o de direcciones unicast, los dispositivos deben ejecutar un algoritmo de detección de direcciones duplicadas (DAD) antes poder utilizarlas. El algoritmo usa los mensajes ICMPv6 [[Protocolo_de_Descubrimiento_de_vecinos#NS|solicitud de un vecino]] y [[Protocolo_de_Descubrimiento_de_vecinos#NA|anuncio de un vecino.]] Si se detecta una dirección que ya está en uso, ésta no podrá ser asignada a la interfaz, la autoconfiguración automática debe suspenderse y será necesario proceder a una configuración manual. Durante la ejecución del algoritmo DAD, la dirección es considerada como "provisional" hasta tener la confirmación de su unicidad. Una dirección provisional se asigna a una interfaz únicamente para recibir los mensajes de solicitud y anuncio de un vecino. Otros mensajes recibidos, son ignorados. El algoritmo DAD consiste en enviar un mensaje de solicitud de un vecino colocando en el campo de dirección objetivo la dirección provisional. Para distinguir el algoritmo DAD del de Descubrimiento de vecinos, el paquete IPv6 que contiene un mensaje de solicitud de un vecino tiene como dirección fuente una dirección no determinada. Así se presentan tres casos:

* Se recibe un mensaje de anucio de un vecino: Significa que la dirección provisional está siendo utilizada como válida por otro dispositivo, por lo que ésta no es única y no puede ser retenida por el dispositivo.
* Se recibe un mensaje de solicitud de un vecino como parte del algoritmo DAD. La dirección provisional también es provisional para otra máquina. En este caso, la dirección provisional no puede ser utilizada por ninguna de ellas.
* No se recibe ningún mensaje durante un segundo (valor por omisión). La dirección provisional es única, por lo que su estado pasa de provisional a válida y se le asigna a la interfaz.

Obsérvese que este algoritmo no proporciona una fiabilidad absoluta, especialmente cuando el enlace está segmentado.

== Autoconfiguración sin estado ==

<tikz title="Emisión de un RS">
\clip (0, 0) rectangle (10,7);
% \draw[help lines] (0,0) grid (10,7 );

\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,3)--(9,3);

\pgfputat{\pgfxy(0.8,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,5)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,3)--(1.5,5);
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (8,3)--(8,5);

\draw (7.8, 5) -- (7.8, 3.2);
\draw [<->] (1, 3.2) -- node [above] {\tiny{FE80::IID2 -$>$ FF02::2 : RS }} (9, 3.2) ;

</tikz>

La configuración automática sin estado (RFC 2462) no requiere de ninguna configuración manual de los dispositivos, una configuración mínima para los enrutadores, y tampoco necesita de servidores adicionales. Se sirve del protocolo ICMPv6 y puede operar aún sin la presencia de enrutadores. En cambio, sí requiere de una subred con soporte a la difusión de paquetes. Este método sólo aplica para los dispositivos; no puede ser utilizada para configurar enrutadores. El principio básico de este mecanismo consiste en que una máquina genera su dirección IPv6 a partir de información local y de la proporcionada por un enrutador. El enrutador proporciona información sobre la subred asociada al enlace; anuncia el prefijo.

{{eSuivi|Tabla de contenido|Incio del capítulo|DHCPv6|DHCPv6}}

Protocolo de Descubrimiento de vecinos

2012-07-04T22:06:06Z

Jincera: /* Detección de una dirección duplicada */

{{eSuivi|Tabla de contenido|Incio del capítulo|DHCPv6|DHCPv6}}

__TOC__

El protocolo de descubrimiento de vecinos (NDP, ''Neighbor Discovery Protocol'') permite a un dispositivo integrarse en el ambiente local, es decir, el enlace sobre el cual se transmiten físicamente los paquetes IPv6. Permite establecer un diálogo con los equipos (estaciones y enrutadores) conectados sobre el mismo medio. No se pretende que un dispositivo conozca con exactitud la lista de todos los demás dispositivos conectados al enlace, sino de proveer un mecanismo para dialogar con quien necesite hacerlo.

El protocolo utiliza cinco tipos de mensajes ICMPv6 (ver Valores de los campos de tipo y código de ICMPv6). El campo número de saltos de la cabecera IPv6 contiene el valor 255. Este valor parece demasiado grande para datagramas que no debieran ser enrutados fuera del enlace físico. En realidad, si un equipo recibe un datagrama con un valor menor, significa que la información proviene de otra red y que ya ha atravesado al menos un enrutador. Por ello, los datagramas que tienen un valor diferente de 255 deben ser ignorados por el receptor.

{{Tableau eICMPv6}}

El protocolo realiza varias funciones:

* Resolución de direcciones. El principio es muy similar al del protocolo ARP de IPv4. La principal diferencia consiste en el uso de mensajes ICMPv6 estándar en lugar de definir otro protocolo de capa 3. Con esto se consigue una mayor flexibilidad de uso, especialmente en las redes que no soportan la difusión de mensajes. Al igual que en IPv4, el protocolo se encarga de construir tablas de correspondencia entre las direcciones IPv6 y las físicas.
* <div vecinos id="NUD"> Detección de inaccesibilidad de vecinos (NUD, ''Neighbor Unreachability Detection''). Esta función, que no existe en IPv4, permite eliminar de las tablas de configuración de un equipo, los vecinos que se han vuelto inaccesibles (por fallas, cambio de domicilio, ...). Si un enrutador deja de estar disponible, la tabla de enrutamiento puede ser modificada para considerar otra ruta. </div>
* Configuración. La configuración automática de los dispositivos es uno de los principales atractivos de IPv6. Se implementan varias funcionalidades del protocolo de descubrimiento de vecinos:
**Descubrimiento de enrutadores. Este protocolo permite que los dispositivos identifiquen a los enrutadores que se encuentran en su enlace físico. En IPv4, esta función la proporciona el protocolo ''ICMP Router Discovery''.
** Descubrimiento de prefijos. El dispositivo conoce el o los prefijos de red de acuerdo a los anuncios realizados por los enrutadores. Agregando su identificador de interfaz, el dispositivo construye su o sus direcciones IPv6. No hay un mecanismo equivalente para las direcciones IPv4 ya que son demasiado cortas para realizar la auto-configuración.
** Detección de direcciones duplicadas. Dado que las direcciones se configuran de forma automática, existen riesgos de error en caso de tener equipos con identificadores repetidos. Este protocolo verifica que ningún otro equipo en el enlace tiene la misma dirección IPv6. Esta función es una evolución del ARP gratuito en IPv4 emitido durante la inicialización de la interfaz.
** Descubrimiento de parámetros. Este protocolo permite que los dispositivos conozcan los distintos parámetros del enlace físico, por ejemplo, el tamaño de MTU, el número máximo de saltos permitido (valor original del campo número de saltos), si la configuración automática con estado (como [[Configuración con estado: DHCPv6|DHCPv6]]) está activa, etc. No existe un equivalente de esta funcionalidad en IPv4.
* Indicación de redirección. Este mensaje se utiliza cuando un enrutador conoce una trayectoria mejor (medida en número de saltos) para alcanzar un destino.
:En IPv4 una indicación de redireccionamiento sólo puede servir para corregir la dirección del enrutador utilizado para acceder a una máquina fuera de la red local. Los dispositivos deben conocer todas las direcciones correspondientes a equipos conectados en su propia red local.
:EnIPv6, la correspondencia entre prefijo y red local es menos rígida. Es de esperar que un dispositivo no conozca todos los prefijos de su red local (si ésta es compartida por varios prefijos), o que un prefijo se comparta entre varios enlaces (lo que corresponde a una generalización del modelo de redes lógicas IP sobre ATM). Bajo algunas configuraciones, la máquina emitirá sus paquetes al enrutador aún si el destinatario se encuentra en el mismo segmento que el emisor. En este caso, el enrutador emitirá un mensaje de redirección para que la continuación del diálogo entre ellos haga de manera directa (véanse los ejemplos [[#IR|Indicación redirección]]).
:En el caso más extremo, podría imaginarse en IPv6 que un dispositivo puede ser configurado para comunicarse únicamente con su enrutador por omisión. ICMPv6 ''redirect'' puede utilizarse entonces, para informar al dispositivo de destinatarios ubicados en el mismo enlace.

En IPv6 se especifican dos métodos de autoconfiguración para las direcciones unicast global:

* Autoconfiguración sin estado (''stateless autoconfiguration'', RFC 2462). Se utiliza cuando no es necesaria una gestión administrativa de las direcciones asignadas dentro de un sitio. Estos mecanismos se describen más adelante en este capítulo.
* Autoconfiguración con estado (''statefull autoconfiguration''). Se utiliza cuando un sitio requiere de un control estricto de la asignación de direcciones (''cf'' [[Configuración con estado: DHCPv6 | DHCPv6]]).

Sin embargo, el uso de DHCPv6 para obtener la dirección se controla mediante el protocolo de descubrimiento de vecinos.

= Datos transmitidos por los mensajes =

La principal motivación detrás del Protocolo de Descubrimiento de vecinos es unificar varios protocolos existentes en IPv4. En particular, la mayor parte de los datos utiliza un formato de opciones común, lo que simplifica la implementación del protocolo. El formato contiene los campos: tipo, longitud (en palabras de 64 bits), y datos. La baja precisión de campo longitud, presentará un desperdicio de espacio, pero permite una alineación de las opciones en palabras de 64 bits, lo que permite un procesamiento optimizado.

{{NB-Opciones}}

== <div id="física">Dirección física de la fuente/destino</div> ==

<tikz title="Formato de la opción dirección física fuente/destino">
\clip (0.2, 5.7) rectangle (11.1,6.7);
% \draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=1/2}};
\draw (2.9, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{lenght }};
\draw (5.3, 6) node (addr) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Link Layer Address}};

\draw [draw=white, thick] (addr.north east) -- (addr.south east);
\draw [draw=white, thick] (addr.north east) -- +(-2, 0);
\draw [draw=white, thick] (addr.south east) -- +(-2, 0);

\draw [dashed] (addr.north east) -- (addr.south east);
\draw [dashed] (addr.north east) -- +(-2, 0);
\draw [dashed] (addr.south east) -- +(-2, 0);
</tikz>

La figura ''Formato de la opción dirección física fuente/destino'' presenta estas opciones. El tipo 1 designa la dirección física de la fuente y el tipo 2 la dirección del destino.

El campo ''length'' es el tamaño en palabras de 64 bits de la opción. Por lo tanto, para el caso de una dirección MAC con longitud de 6 octetos, contiene el valor 1.

El RFC 2464 define el formato para las direcciones MAC-48 utilizadas en las redes Ethernet y Wi-Fi. El RFC 4944 define el formato para las direcciones MAC-16 y MAC-64 utilizadas en las redes de sensores bajo la norma IEEE 802.15.4.

== <div id="información">Información sobre el prefijo</div> ==

<tikz title="Formato de la opción información sobre el prefijo">
\clip (0.2, 2) rectangle (11.1, 7);
% \draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=3}};
\draw (2.9, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{length =4 }};
\draw (5.3, 6) node (addr) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm] {\tiny{Prefix Length}};
\draw (7.7, 6) node (bitL) [right, shade, top color=blue!15, bottom color=blue!5,, draw, minimum height=0.5cm, minimum width=.3cm]{}; \draw (bitL.text) node {\tiny{L}};
\draw (8, 6) node (bitA) [right, shade, top color=blue!15, bottom color=blue!5,, draw, minimum height=0.5cm, minimum width=.3cm]{};\draw (bitA.text) node {\tiny{A}};
\draw (8.3, 6) node (bitR) [right, shade, top color=blue!15, bottom color=blue!5,, draw, minimum height=0.5cm, minimum width=.3cm]{};\draw (bitR.text) node {\tiny{R}};
\draw (8.6, 6) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=1.5cm] {\tiny{Reserved}};

\draw (0.5, 5.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Valid Lifetime}};

\draw (0.5, 5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Prefered Lifetime}};

\draw (0.5, 4.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Reserved}};

\draw (0.5, 4) node (addr1) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{}};
\draw (0.5, 3.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{}};
\draw (0.5, 3) node (addr3) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Prefix}};
\draw (0.5, 2.5) node (addr4) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{}};

\draw [color=blue!10, very thick] (addr1.south east) -- (addr1.south west);
\draw [color=blue!10, very thick] (addr2.south east) -- (addr2.south west);
\draw [color=blue!10, very thick] (addr3.south east) -- (addr3.south west);
</tikz>

Esta opción contiene las informaciones sobre el prefijo para permitir una configuración automática de los dispositivos. El campo tipo tiene el valor 3 y el de longitud, 4. La figura ''Formato de la opción información sobre el prefijo'' muestra el formato de esta opción:

* El campo ''Prefix lenght'' indica cuántos bits son significativos para el prefijo anunciado en un campo siguiente.
* El bit <tt>L</tt> indica, cuando vale 1, que el prefijo permite indicar que todos los demás dispositivos que comparten el mismo prefijo, están en el mismo enlace, por lo que el emisor puede contactarlos directamente. En caso contrario, el dispositivo envía el paquete hacia el enrutador. Si éste último sabe que el emisor puede contactar directamente al destinatario, emitirá un mensaje ICMPv6 de indicación de redirección.
* El bit <tt>A</tt> indica, cuando vale 1, que el prefijo anunciado puede utilizarse para formar la dirección del dispositivo.
* El bit <tt>R</tt>, indica, cuando vale 1, que el campo prefijo contiene la dirección global de un enrutador ''agente base''. Los bits de mayor peso aún pueden utilizarse para formar un prefijo.
* El campo duración de validez indica, en segundos, la duración durante la cual el prefijo es válido.
* El campo duración preferente indica la duración, en segundos, durante la cual una dirección formada con el protocolo de configuración sin estado se mantiene ''preferente'' (''cf'' [[Planes de direccionamiento|Tiempo de vida de las direcciones]]).

Para estos dos campos, un valor de <tt>0xffffffff</tt> representa una duración infinita. Estos campos pueden servir durante la fase de transición de un proveedor de acceso a otro; es decir, de un prefijo a otro.
* El campo reservado permite alinear el prefijo a una frontera de palabra de 64 bits.
* El campo prefijo contiene el valor de prefijo anunciado sobre el enlace. Para mantener una alineación de 64 bits para el resto de datos del paquete, este campo tiene una longitud fija de 128 bits.

== <div id="redirigida">Cabecera de redirección </div> ==

<tikz title="Formato de la opción cabecera de redirección">
\clip (0.2, 3.1) rectangle (11.1, 7);
% \draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=5}};
\draw (2.9, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{length =1 }};
\draw (5.3, 6) node (addr) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Reserved}};

\draw (0.5, 5.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Reserved}};

\draw (0.5, 4.25) node (context) [right, shade, top color=purple!50, bottom color=purple!10, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{IPv6 Header and Data}};
</tikz>

Esta opción es utilizada por el mensaje de indicación de redirección. Permite encapsular los primeros octetos del paquete IPv6 que provocó la emisión de este mensaje, como ocurre con los mensajes de error de ICMPv6.

El campo tipo tiene el valor 4. El tamaño de esta opción debe evitar que el paquete IPv6 rebase los 1280 octetos (''cf'' figura ''Formato de la opción cabecera de redirección''). Sin embargo, el paquete debe contener la mayor cantidad de información posible.

== <div id="MTU">MTU</div> ==

<tikz title="Formato de la opción MTU">

\clip (0.2, 5.1) rectangle (11.1, 7);
% \draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=5}};
\draw (2.9, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{lenght =1 }};
\draw (5.3, 6) node (addr) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Reserved}};

\draw (0.5, 5.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{MTU}};
</tikz>

Esta opción permite notificar a los dispositivos el tamaño máximo de datos que pueden ser transmitidos sobre el enlace. La figura ''Formato de la opción MTU'' muestra su estructura. No es necesario difundir esta información si el dispositivo utiliza siempre el tamaño máximo permitido. Por ejemplo, sobre las redes Ethernet, los dispositivos utilizarán el valor 1,500. En cambio, en las redes Token Ring o FDDI, con frecuencia es necesario especificar si los equipos pueden utilizar la longitud máxima o un tamaño inferior para permitir el uso de puentes en la red.

En esta opción, el campo tipo tiene un valor de 5 y el de longitud, de 1.

=Mensajes estándar de Descubrimiento de vecinos =

Además de las cinco opciones básicas descritas en la tabla ''Utilización de las opciones en los mensajes de descubrimiento de vecinos'', existen otras específicas para la movilidad y para las redes NBMA (''Non Broadcast Multiple Access'').

{|
|+ Utilización de las opciones en los mensajes de descubrimiento de vecinos
| width = 150 | || width = 100 |[[#RS|Solicitud de]] || width = 100 |[[#RA|Anuncio de]] || width = 100 |[[#NS|Solicitud de]] ||width = 100 | [[#NA|Anuncio de]] ||width = 100 |[[#IR|Indicación de]]
|-
| || [[#RS|enrutador]] || [[#RA|enrutador]] || [[#NS|un vecino]] || [[#NA| un vecino]] || [[#IR|redirección]]
|-style="background:silver"
|[[#física |Dirección física de la fuente]] || presente || presente || presente || ||
|-
|[[# física | Dirección física del destino]] || || || || presente || presente
|-style="background:silver"
|[[#información|Información sobre el prefijo]] || || ≥ 1 || || ||
|-
|[[#redirigida |Cabecera de redirección]] || || || || || presente
|-style="background:silver"
| [[#MTU |MTU]] || || posible || || ||
|}

Las distintas funcionalidades de descubrimiento de vecinos utilizan cinco mensajes: dos para el diálogo entre un dispositivo y un enrutador, dos para el diálogo entre vecinos, y uno para la redirección. Cada uno de estos mensajes puede incluir opciones adicionales.

== <div id="RS">Solicitud de enrutador</div> ==

<tikz title="Formato de los paquetes de solicitud de enrutador">
\clip (0.2, 3.5) rectangle (11.1,7.1);
%\draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=133}};
\draw (2.9, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code =0 }};
\draw (5.3, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};
\draw (0.5, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Reserved}};

\draw (0.5, 4.25) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Options:\\
- Source link-layer address
}};
</tikz>

El mensaje de solicitud de enrutador (''cf'' figura Formato de los paquetes de solicitud de enrutador) es emitido al iniciar un dispositivo para recibir más rápidamente la información del enrutador. Este mensaje se envía a la dirección IPv6 multicast reservada a los enrutadores en el mismo enlace <tt>FF02::2</tt>. Si el dispositivo aún no conoce su dirección fuente, se utiliza la dirección no especificada.

El campo opción normalmente contiene la dirección física del dispositivo.

== <div id="RA">Anuncio de enrutador</div> ==

<tikz title="Formato de los paquetes de anuncio de enrutador">
\clip (0.2, 1.5) rectangle (11.1,7.1);
%\draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=134}};
\draw (2.9, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code =0 }};
\draw (5.3, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};

\draw (0.5, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Cur. Hop Lim.}};
\draw (2.9, 5.5) node (bitM) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{}; \draw (bitM.text) node {\tiny{M}};
\draw (3.2, 5.5) node (bitO) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{};\draw (bitO.text) node {\tiny{O}};
\draw (3.5, 5.5) node (bitH) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{};\draw (bitH.text) node {\tiny{H}};
\draw (3.8, 5.5) node (res) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=1.5cm]{\tiny{reserved}};
\draw (5.3, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Router Lifetime}};

\draw (0.5, 5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=9.6cm]{\tiny{Reachable Time}};
\draw (0.5, 4.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=9.6cm]{\tiny{Retrans Time}};

\draw (0.5, 3.25) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Options:\\
Source link-layer address\\
MTU\\
Prefix Information (may be repeated)\\
}};
</tikz>

Este mensaje (''cf'' figura ''Formato de los paquetes de anuncio de enrutador'') es emitido periódicamente por los enrutadores, o bien, en respuesta a un mensaje de solicitud de enrutador generado por un dispositivo. El campo dirección fuente contiene la dirección de enlace local del enrutador, mientras que el campo dirección destino contiene la dirección del dispositivo que generó la solicitud, o la dirección de todas las estaciones (<tt>ff02::01</tt>).

Cuando el campo de máximo número de saltos tiene un valor distinto de cero, muestra el valor que podría colocarse en el campo de número de saltos de los paquetes emitidos. El bit <tt>M</tt> indica que una dirección del dispositivo debe ser obtenida mediante un protocolo de configuración (''cf'' [[Configuración con estado:DHCPv6]]). El bit <tt>O</tt> también indica la presencia de un servicio de configuración para obtener información adicional a la dirección. Si no es posible obtener la dirección mediante un servidor, el dispositivo procede a realizar una configuración sin estado, concatenando su identificador de interfaz a los prefijos que conoce. El bit <tt>H</tt> indica que el enrutador puede ser utilizado como agente base por un nodo móvil (''cf'' [[Desplazamientos_de_móviles#Anuncio_del_agente_base |Anuncio del agente base]]).

El campo tiempo de vida del enrutador indica el período (en segundos) durante el cual el equipo que emite el anuncio realizará funciones de enrutador por omisión. El valor máximo corresponde a 18 horas 12 minutos, pero como este mensaje se emite periódicamente, en la práctica no existe un límite para el tiempo de vida de un enrutador. Un valor de <tt>0</tt> indica que el dispositivo no cumple con las funciones de enrutador por omisión. Este tiempo de vida no se aplica a las opciones transportadas por este mensaje.

El campo duración de accesibilidad indica el período (en milisegundos) durante el cual una información almacenada en la memoria caché de la máquina (por ejemplo, la tabla de correspondencia entre las direcciones IPv6 y las físicas) puede ser considerada como válida. Al vencimiento de este tiempo, se emite un mensaje de detección de inaccesibilidad para verificar la pertinencia de la información almacenada.

El campo temporización de retransmisión muestra el período (en milisegundos) entre dos emisiones no solicitadas de este mensaje. Permite que los demás equipos puedan detectar la inaccesibilidad de un enrutador.

Este mensaje puede transportar las siguientes opciones:

* dirección física de la fuente,
* MTU,
* información sobre el prefijo (uno o varios).

== <div Id="NS"> Solicitud de un vecino </div> ==

<tikz title="Formato de los paquetes de solicitud de un vecino">

\clip (0.2, 1.5) rectangle (11.1,7.1);
%\draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=135}};
\draw (2.9, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code =0 }};
\draw (5.3, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};

\draw (0.5, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=9.6cm]{\tiny{Reserved}};

\draw (0.5, 4.25) node (context) [right, shade, top color=blue!50, bottom color=blue=!10, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Target Address}};

\draw (0.5, 2.25) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Options:\\
Source link-layer address\\
}};
</tikz>

Este mensaje (''cf'' figura ''Formato de los paquetes de solicitud de un vecino'') permite obtener información a partir de un equipo vecino, es decir, localizado en el mismo enlace físico (o conectado a través de puentes). El mensaje puede ser emitido explícitamente a él, o enviado con una dirección de difusión. En el caso de determinación de la dirección física, éste corresponde a la solicitud de ARP en IPv4.

El campo dirección fuente del paquete IPv6 contiene ya sea la dirección local al enlace, una dirección global o la dirección no especificada. El campo destino puede contener la dirección de difusión múltiple solicitada correspondiente a la dirección buscada (''cf'' [[Direccionamiento_multicast#Identificador_de_grupo|Identificador de grupo]]) o la dirección del dispositivo (en el caso de una detección de inaccesibilidad de vecinos, ''NUD'').

El campo dirección del destino contiene la dirección IPv6 del equipo buscado. El campo opción generalmente contiene la dirección física de la fuente.

== <div Id="NA"> Anuncio de un vecino</div> ==

<tikz title="Formato de los paquetes de anuncio de un vecino">

\clip (0.2, 1.5) rectangle (11.1,7.1);
%\draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=136}};
\draw (2.9, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code =0 }};
\draw (5.3, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};

\draw (0.5, 5.5) node (bitR) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{}; \draw (bitR.text) node {\tiny{R}};
\draw (0.8, 5.5) node (bitS) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{}; \draw (bitS.text) node {\tiny{S}};
\draw (1.1, 5.5) node (bitO) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{}; \draw (bitO.text) node {\tiny{O}};
\draw (1.4, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=8.7cm]{\tiny{Reserved}};

\draw (0.5, 4.25) node (context) [right, shade, top color=blue!50, bottom color=blue=!10, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Target Address}};

\draw (0.5, 2.25) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Options:\\
Source link-layer address\\
}};
</tikz>

Este mensaje (''cf'' figura ''Formato de los paquetes de anuncio de un vecino'') se emite en respuesta a una solicitud, aunque también puede ser emitido de forma espontánea para propagar la información de cambio de dirección física, o del estado de "enrutador". Para el caso de la determinación de la dirección física, es equivalente a la respuesta ARP en IPv4.

* El bit <tt> R </tt> se pone a 1 si el remitente es un enrutador. Este bit se utiliza para permitir la detección de un enrutador que se convierte en un equipo ordinario.
* El bit <tt> S </tt> en 1 indica que este anuncio se emite en respuesta a una solicitud.
* El bit <tt> O </tt> en 1 indica que este anuncio debe borrar las informaciones anteriores que se encuentran almacenadas en la memoria cachés de otros equipos, en especial la tabla que contiene las direcciones físicas.
* El campo dirección del destino contiene, si el bit<tt> S </tt> es 1, el valor del campo dirección del destino de la solicitud a la que está respondiendo este mensaje. Si el bit <tt> S </tt> es 0, este campo contiene la dirección IPv6 local al enlace del equipo emisor.
* La opción dirección física del destino contiene la dirección física del emisor.

== <div id="IR">Indicación de redirección</div> ==

<tikz title="Formato de los paquetes de indicación de redirección">
\clip (0.2, 0) rectangle (11.1,7.1);
%\draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=137}};
\draw (2.9, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code =0 }};
\draw (5.3, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};

\draw (0.5, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=9.6cm]{\tiny{Reserved}};

\draw (0.5, 4.25) node (context) [right, shade, top color=blue!50, bottom color=blue=!10, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Target Address}};

\draw (0.5, 2.25) node (context) [right, shade, top color=blue!50, bottom color=blue=!10, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Destination Address}};

\draw (0.5, 0.5) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=1.5cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Options:\\
Target link-layer address\\
Redirected Header\\
}};
</tikz>

La técnica de redirección es la misma que en IPv4. Un dispositivo sólo conoce los prefijos de las redes a las que está conectado directamente y la dirección de un enrutador por omisión. Si la ruta se puede optimizar, el enrutador por omisión envía un mensaje para indicar que existe un camino más corto. De hecho, como en IPv6 el enrutador por omisión se establece de forma automática, las rutas no necesariamente son las mejores (''cf'' figura ''Enrutamiento por omisión no óptimo'').

Otro caso particular en IPv6 ocurre con los dispositivos que se encuentran en el mismo enlace físico, pero tienen diferentes prefijos. La comunicación entre ellos pasa inicialmente a traves de enrutador por omisión hasta que éste notifica que existe una ruta directa entre ellos.

La figura ''Formato de los paquetes de indicación de redirección'' muestra el formato del mensaje:

* El campo dirección objetivo (''Target address'') contiene la dirección IPv6 del equipo hacia el que los paquetes deben ser enviados.
* El campo dirección destino contiene la dirección IPv6 del dispositivo que está siendo redirigido hacia la dirección objetivo.

Cuando la redirección apunta a un dispositivo situado en el mismo enlace, la dirección objetivo y de destino son las mismas.

Las opciones incluyen la dirección física de un nuevo enrutador y la cabecera del paquete redirigido.

Este mensaje se puede utilizar de la misma forma que en IPv4. Un dispositivo solamente tiene una ruta por omisión para acceder a equipos con un prefijo diferente. En consecuencia, envía su paquete al enrutador por omisión, quien observa que el prefijo destino es accesible a través de la misma subred que el emisor. El enrutador por omisión reenvía el paquete y notifica al emisor que puede contactar directamente a las máquinas que poseen el prefijo del destino.

IPv6 también utiliza este mensaje para optimizar la resolución fuera del enlace para el [[#Caso de redes NBMA |caso de redes NBMA]].

= Configuración automática =
Tradicionalmente, la configuración de una interfaz de red de una máquina se hacía manualmente. Esto suele ser un trabajo lento y propenso a errores. Con IPv6, se automatiza el proceso de configuración y se introducen, al mismo tiempo, mecanismos de funcionamiento inmediato (''plug and play'') a la interfaz de red. La configuración automática significa que un dispositivo obtendrá toda la información necesaria para su conexión a una red local IP sin ninguna intervención humana. En el caso ideal, cualquier usuario desempaca su nuevo equipo, lo conecta a la red local y lo ve funcionar sin tener que introducir la información propia de "especialistas". Ahora vamos a discutir otro aspecto de la configuración automática de IPv6, la auto-configuración de direcciones, que tiene como objetivos:

* La adquisición de una dirección cuando un dispositivo está conectado a una red por primera vez;
* la posibilidad de asignar otros prefijos, o de renumerar un dispositivo.

El proceso de configuración automática de direcciones IPv6 incluye la creación de una dirección local al enlace, la agregación a grupos multicast solicitados, la verificación de la unicidad de la dirección local al enlace y la creación de direcciones unicast global.

La tarea del enrutador es importante en la configuración automática. Indica a la máquina, mediante los bits de la cabecera (ver [[#RA|anuncio de enrutador]]), del mensaje de anuncio de los enrutadores, el método a conservar y eventualmente proporcionar la información necesaria para su configuración. El bit <tt> M </tt> (''configuración de dirección administrada'') puesto a 1 indica que el equipo no debe crear por sí mismo una dirección a partir de su identificador de interfaz y de los prefijos recibidos, sino que debe solicitarla explícitamente ante un servidor de direcciones. El bit O <tt> </tt> (''otra configuración de estado'') indica que el dispositivo debe consultar el servidor para obtener otros parámetros distintos de la dirección. El algoritmo para el proceso de configuración automática de direcciones se desglosa de la siguiente manera:

* La primera fase consiste en crear la dirección local al enlace.
* Una vez que la unicidad de esta dirección es verificada, el dispositivo está listo para comunicarse con otras máquinas en el enlace.
* El dispositivo debe tratar de adquirir un mensaje de anuncio de enrutadores para determinar el método de obtención de la dirección unicast global.
* Si hay un enrutador en el enlace, el dispositivo debe aplicar el método especificado por el mensaje de anuncio de enrutadores, a saber:
** La configuración automática sin estado,
** la configuración automática con estado.
* Si no hay ningún enrutador en el enlace, el dispositivo debe tratar de obtener la dirección unicast global por el método de configuración automática con estado. Si el intento falla, no hay más que hacer. Las comunicaciones sólo podrán hacerse sobre el enlace con la dirección local al enlace, pues el dispositivo no tendrá una dirección con la cobertura necesaria que le permita comunicarse con otras máquinas fuera del enlace.

==Ciclo de vida de una dirección==

Al generalizar en IPv6 el plan de direccionamiento CIDR, los prefijos quedan, en todos los casos, siendo propiedad de los operadores. Ya no pueden otorgarse "a perpetuidad" a los dispositivos. Para facilitar la renumeración de una máquina, la asignación de una dirección a una interfaz es temporal, las direcciones IPv6 no se entregan, sino que se prestan. Se asocia un tiempo de vida a la dirección, que indica el tiempo durante el cual la dirección pertenece a la interfaz. Cuando el tiempo de vida se ha agotada, la dirección deja de ser válida, se suprime de la interfaz y queda potencialmente éste puede prolongarse indefinidamente. La dirección local al enlace tiene un tiempo de vida ilimitado.

<tikz title="Estados sucesivos de una dirección en una interfaz">

\draw [thick, ->] (0,2) -- (9.5,2);

\draw [->] (1,4) node [above=10pt] {\tiny{allocation}}-- (1,2);
\draw (1, 2) node [rectangle, minimum width=1cm, minimum height=1cm, fill, left color=black!10, right color=black!20, draw=black, above right] (tentative) {};
\draw (tentative.south east) node [rectangle, minimum width=3cm, minimum height=1cm, fill, left color=green, right color=green!50, draw=black, above right] (preferred) {};
\draw (preferred.south east) node [rectangle, minimum width=2cm, minimum height=1cm, fill, left color=orange , right color=orange!50!red, draw=black, above right] (deprecated) {};
\draw (deprecated.south east) node [rectangle, minimum width=2cm, minimum height=1cm, fill, color=red, draw=black, above right] (novalid) {};

\draw (tentative.text) node {\tiny{Tentative}};
\draw (preferred.text) node {\tiny{Preferred}};
\draw (deprecated.text) node {\tiny{Deprecated}};
\draw (novalid.text) node {\tiny{Invalid}};

\draw [dotted] (tentative.south west) -- +(0, -1);
\draw [dotted] (preferred.south west) -- +(0, -1);
\draw [dotted] (deprecated.south west) -- +(0, -1);
\draw [dotted] (novalid.south west) -- +(0, -1);

\draw [dashed, <->] ([yshift=-0.5cm]tentative.south west) -- node [above] {\tiny{DAD}} ([yshift=-0.5cm] preferred.south west) ;

\draw [dashed, <->] ([yshift=-0.5cm]preferred.south west) -- node [above] {\tiny{Valid}} ([yshift=-0.5cm] novalid.south west) ;

</tikz>

La renumeración de una interfaz consiste en pasar de una dirección a otra. Durante una renumeración, no es aconsejable cambiar repentinamente de dirección, de lo contrario, todas las comunicaciones TCP que la utilizan como identificador de conexión, se cortarían inmediatamente. Esto conllevaría importantes perturbaciones a nivel de las aplicaciones.

Por ello, para facilitar esta transición se implementó un mecanismo de obsolescencia que invalida gradualmente una dirección. Este mecanismo se sirve de la capacidad de asignación de varias direcciones válidas a una misma interfaz. Para elegir la dirección a utilizar, se le asocia un estado que indica en qué fase de su tiempo de vida se encuentra con respecto a la interfaz. El primero de esos estados se conoce como preferido: no hay ninguna restricción de uso. Poco antes de su invalidación, la dirección pasa a un estado de depreciado. En él se desaconseja el uso de la dirección, pero no está prohibido. Una dirección depreciada ya no debe ser utilizada como dirección fuente de nuevas comunicaciones (como el establecimiento de conexión TCP), pero todavía puede emplearse como dirección fuente de comunicaciones ya establecidas. Los paquetes recibidos a una dirección depreciada seguirán siendo entregados normalmente. El control de la duración de cada estad de una dirección válida se efectúa agregando un tiempo de vida al estado preferido.
La figura '''Estados sucesivos de una dirección en una interfaz''' representa los diferentes estados que toma una dirección cuando se asigna a una interfaz.

== Creación de la dirección local al enlace ==

<tikz title=" Creación de la dirección local al enlace">
\clip (0, 0) rectangle (10,7);
% \draw[help lines] (0,0) grid (10,7 );

\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,3)--(9,3);

\pgfputat{\pgfxy(0.8,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,5)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,3)--(1.5,5);
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (8,3)--(8,5);

\draw (1.5,4.5) node {\small{FE80::IID1}};
\draw (1.5,4) node {\small{$\alpha$::IID1/64}};

\draw (8, 4.5) node {\small{FE80::IID2}};

</tikz>

Durante la inicialización de la interfaz, el dispositivo construye un identificador de interfaz que debe ser único en el enlace. Este identificador se utiliza la dirección de [[ Identificador_de_interfaz#EUI-64 | EUI-64]]. El principio básico para crear la direcciónIPv6 consiste en unir un prefijo con el identificador. La dirección local al enlace se crea tomando el prefijo de Enlace_local (<tt>FE80::/64</tt>). La dirección creada de esa manera, todavía no puede ser utilizada; tiene un estado temporal pues el dispositivo debe comprobar la exclusividad de esta dirección en el enlace mediante el procedimiento de detección de direcciones duplicadas. Si se encuentra que la dirección local al enlace no es única, se suspende la autoconfiguración y será necesario proceder a una configuración manual.

Una vez que se ha asegurado la unicidad de la dirección local al enlace, ésta se considera una dirección válida para la interfaz, con lo que termina la prima fase del proceso de autoconfiguración.

==<div id="DAD"> Detección de una dirección duplicada </div>==

<tikz title="Emisión de un NS en una detección de Dir. duplicada (DAD)">
\clip (0, 0) rectangle (10,7);
% \draw[help lines] (0,0) grid (10,7 );

\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,3)--(9,3);

\pgfputat{\pgfxy(0.8,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,5)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,3)--(1.5,5);
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (8,3)--(8,5);

\draw (7.8, 5) -- (7.8, 3.2);
\draw [<->] (1, 3.2) -- node [above] {\tiny{::/0 -$>$ solicited (FE80:IID2) : NS (who has FE80::IID2?)}}(9, 3.2) ;

</tikz>

Para comprobar la exclusividad de direcciones locales al enlace o de direcciones unicast, los dispositivos deben ejecutar un algoritmo de detección de direcciones duplicadas (DAD) antes poder utilizarlas. El algoritmo usa los mensajes ICMPv6 [[Descubrimiento de vecinos#NS|solicitud de un vecino]] y [[Protocolo_de_Descubrimiento_de_vecinos#NA|anuncio de un vecino.]] Si se detecta una dirección que ya está en uso, ésta no podrá ser asignada a la interfaz, la autoconfiguración automática debe suspenderse y será necesario proceder a una configuración manual. Durante la ejecución del algoritmo DAD, la dirección es considerada como "provisional" hasta tener la confirmación de su unicidad. Una dirección provisional se asigna a una interfaz únicamente para recibir los mensajes de solicitud y anuncio de un vecino. Otros mensajes recibidos, son ignorados. El algoritmo DAD consiste en enviar un mensaje de solicitud de un vecino colocando en el campo de dirección objetivo la dirección provisional. Para distinguir el algoritmo DAD del de Descubrimiento de vecinos, el paquete IPv6 que contiene un mensaje de solicitud de un vecino tiene como dirección fuente una dirección no determinada. Así se presentan tres casos:

* Se recibe un mensaje de anucio de un vecino: Significa que la dirección provisional está siendo utilizada como válida por otro dispositivo, por lo que ésta no es única y no puede ser retenida por el dispositivo.
* Se recibe un mensaje de solicitud de un vecino como parte del algoritmo DAD. La dirección provisional también es provisional para otra máquina. En este caso, la dirección provisional no puede ser utilizada por ninguna de ellas.
* No se recibe ningún mensaje durante un segundo (valor por omisión). La dirección provisional es única, por lo que su estado pasa de provisional a válida y se le asigna a la interfaz.

Obsérvese que este algoritmo no proporciona una fiabilidad absoluta, especialmente cuando el enlace está segmentado.

== Autoconfiguración sin estado ==

<tikz title="Emisión de un RS">
\clip (0, 0) rectangle (10,7);
% \draw[help lines] (0,0) grid (10,7 );

\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,3)--(9,3);

\pgfputat{\pgfxy(0.8,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,5)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,3)--(1.5,5);
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (8,3)--(8,5);

\draw (7.8, 5) -- (7.8, 3.2);
\draw [<->] (1, 3.2) -- node [above] {\tiny{FE80::IID2 -$>$ FF02::2 : RS }} (9, 3.2) ;

</tikz>

La configuración automática sin estado (RFC 2462) no requiere de ninguna configuración manual de los dispositivos, una configuración mínima para los enrutadores, y tampoco necesita de servidores adicionales. Se sirve del protocolo ICMPv6 y puede operar aún sin la presencia de enrutadores. En cambio, sí requiere de una subred con soporte a la difusión de paquetes. Este método sólo aplica para los dispositivos; no puede ser utilizada para configurar enrutadores. El principio básico de este mecanismo consiste en que una máquina genera su dirección IPv6 a partir de información local y de la proporcionada por un enrutador. El enrutador proporciona información sobre la subred asociada al enlace; anuncia el prefijo.

{{eSuivi|Tabla de contenido|Incio del capítulo|DHCPv6|DHCPv6}}

Protocolo de Descubrimiento de vecinos

2012-07-04T22:05:01Z

Jincera: /* Anuncio de un vecino */

{{eSuivi|Tabla de contenido|Incio del capítulo|DHCPv6|DHCPv6}}

__TOC__

El protocolo de descubrimiento de vecinos (NDP, ''Neighbor Discovery Protocol'') permite a un dispositivo integrarse en el ambiente local, es decir, el enlace sobre el cual se transmiten físicamente los paquetes IPv6. Permite establecer un diálogo con los equipos (estaciones y enrutadores) conectados sobre el mismo medio. No se pretende que un dispositivo conozca con exactitud la lista de todos los demás dispositivos conectados al enlace, sino de proveer un mecanismo para dialogar con quien necesite hacerlo.

El protocolo utiliza cinco tipos de mensajes ICMPv6 (ver Valores de los campos de tipo y código de ICMPv6). El campo número de saltos de la cabecera IPv6 contiene el valor 255. Este valor parece demasiado grande para datagramas que no debieran ser enrutados fuera del enlace físico. En realidad, si un equipo recibe un datagrama con un valor menor, significa que la información proviene de otra red y que ya ha atravesado al menos un enrutador. Por ello, los datagramas que tienen un valor diferente de 255 deben ser ignorados por el receptor.

{{Tableau eICMPv6}}

El protocolo realiza varias funciones:

* Resolución de direcciones. El principio es muy similar al del protocolo ARP de IPv4. La principal diferencia consiste en el uso de mensajes ICMPv6 estándar en lugar de definir otro protocolo de capa 3. Con esto se consigue una mayor flexibilidad de uso, especialmente en las redes que no soportan la difusión de mensajes. Al igual que en IPv4, el protocolo se encarga de construir tablas de correspondencia entre las direcciones IPv6 y las físicas.
* <div vecinos id="NUD"> Detección de inaccesibilidad de vecinos (NUD, ''Neighbor Unreachability Detection''). Esta función, que no existe en IPv4, permite eliminar de las tablas de configuración de un equipo, los vecinos que se han vuelto inaccesibles (por fallas, cambio de domicilio, ...). Si un enrutador deja de estar disponible, la tabla de enrutamiento puede ser modificada para considerar otra ruta. </div>
* Configuración. La configuración automática de los dispositivos es uno de los principales atractivos de IPv6. Se implementan varias funcionalidades del protocolo de descubrimiento de vecinos:
**Descubrimiento de enrutadores. Este protocolo permite que los dispositivos identifiquen a los enrutadores que se encuentran en su enlace físico. En IPv4, esta función la proporciona el protocolo ''ICMP Router Discovery''.
** Descubrimiento de prefijos. El dispositivo conoce el o los prefijos de red de acuerdo a los anuncios realizados por los enrutadores. Agregando su identificador de interfaz, el dispositivo construye su o sus direcciones IPv6. No hay un mecanismo equivalente para las direcciones IPv4 ya que son demasiado cortas para realizar la auto-configuración.
** Detección de direcciones duplicadas. Dado que las direcciones se configuran de forma automática, existen riesgos de error en caso de tener equipos con identificadores repetidos. Este protocolo verifica que ningún otro equipo en el enlace tiene la misma dirección IPv6. Esta función es una evolución del ARP gratuito en IPv4 emitido durante la inicialización de la interfaz.
** Descubrimiento de parámetros. Este protocolo permite que los dispositivos conozcan los distintos parámetros del enlace físico, por ejemplo, el tamaño de MTU, el número máximo de saltos permitido (valor original del campo número de saltos), si la configuración automática con estado (como [[Configuración con estado: DHCPv6|DHCPv6]]) está activa, etc. No existe un equivalente de esta funcionalidad en IPv4.
* Indicación de redirección. Este mensaje se utiliza cuando un enrutador conoce una trayectoria mejor (medida en número de saltos) para alcanzar un destino.
:En IPv4 una indicación de redireccionamiento sólo puede servir para corregir la dirección del enrutador utilizado para acceder a una máquina fuera de la red local. Los dispositivos deben conocer todas las direcciones correspondientes a equipos conectados en su propia red local.
:EnIPv6, la correspondencia entre prefijo y red local es menos rígida. Es de esperar que un dispositivo no conozca todos los prefijos de su red local (si ésta es compartida por varios prefijos), o que un prefijo se comparta entre varios enlaces (lo que corresponde a una generalización del modelo de redes lógicas IP sobre ATM). Bajo algunas configuraciones, la máquina emitirá sus paquetes al enrutador aún si el destinatario se encuentra en el mismo segmento que el emisor. En este caso, el enrutador emitirá un mensaje de redirección para que la continuación del diálogo entre ellos haga de manera directa (véanse los ejemplos [[#IR|Indicación redirección]]).
:En el caso más extremo, podría imaginarse en IPv6 que un dispositivo puede ser configurado para comunicarse únicamente con su enrutador por omisión. ICMPv6 ''redirect'' puede utilizarse entonces, para informar al dispositivo de destinatarios ubicados en el mismo enlace.

En IPv6 se especifican dos métodos de autoconfiguración para las direcciones unicast global:

* Autoconfiguración sin estado (''stateless autoconfiguration'', RFC 2462). Se utiliza cuando no es necesaria una gestión administrativa de las direcciones asignadas dentro de un sitio. Estos mecanismos se describen más adelante en este capítulo.
* Autoconfiguración con estado (''statefull autoconfiguration''). Se utiliza cuando un sitio requiere de un control estricto de la asignación de direcciones (''cf'' [[Configuración con estado: DHCPv6 | DHCPv6]]).

Sin embargo, el uso de DHCPv6 para obtener la dirección se controla mediante el protocolo de descubrimiento de vecinos.

= Datos transmitidos por los mensajes =

La principal motivación detrás del Protocolo de Descubrimiento de vecinos es unificar varios protocolos existentes en IPv4. En particular, la mayor parte de los datos utiliza un formato de opciones común, lo que simplifica la implementación del protocolo. El formato contiene los campos: tipo, longitud (en palabras de 64 bits), y datos. La baja precisión de campo longitud, presentará un desperdicio de espacio, pero permite una alineación de las opciones en palabras de 64 bits, lo que permite un procesamiento optimizado.

{{NB-Opciones}}

== <div id="física">Dirección física de la fuente/destino</div> ==

<tikz title="Formato de la opción dirección física fuente/destino">
\clip (0.2, 5.7) rectangle (11.1,6.7);
% \draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=1/2}};
\draw (2.9, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{lenght }};
\draw (5.3, 6) node (addr) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Link Layer Address}};

\draw [draw=white, thick] (addr.north east) -- (addr.south east);
\draw [draw=white, thick] (addr.north east) -- +(-2, 0);
\draw [draw=white, thick] (addr.south east) -- +(-2, 0);

\draw [dashed] (addr.north east) -- (addr.south east);
\draw [dashed] (addr.north east) -- +(-2, 0);
\draw [dashed] (addr.south east) -- +(-2, 0);
</tikz>

La figura ''Formato de la opción dirección física fuente/destino'' presenta estas opciones. El tipo 1 designa la dirección física de la fuente y el tipo 2 la dirección del destino.

El campo ''length'' es el tamaño en palabras de 64 bits de la opción. Por lo tanto, para el caso de una dirección MAC con longitud de 6 octetos, contiene el valor 1.

El RFC 2464 define el formato para las direcciones MAC-48 utilizadas en las redes Ethernet y Wi-Fi. El RFC 4944 define el formato para las direcciones MAC-16 y MAC-64 utilizadas en las redes de sensores bajo la norma IEEE 802.15.4.

== <div id="información">Información sobre el prefijo</div> ==

<tikz title="Formato de la opción información sobre el prefijo">
\clip (0.2, 2) rectangle (11.1, 7);
% \draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=3}};
\draw (2.9, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{length =4 }};
\draw (5.3, 6) node (addr) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm] {\tiny{Prefix Length}};
\draw (7.7, 6) node (bitL) [right, shade, top color=blue!15, bottom color=blue!5,, draw, minimum height=0.5cm, minimum width=.3cm]{}; \draw (bitL.text) node {\tiny{L}};
\draw (8, 6) node (bitA) [right, shade, top color=blue!15, bottom color=blue!5,, draw, minimum height=0.5cm, minimum width=.3cm]{};\draw (bitA.text) node {\tiny{A}};
\draw (8.3, 6) node (bitR) [right, shade, top color=blue!15, bottom color=blue!5,, draw, minimum height=0.5cm, minimum width=.3cm]{};\draw (bitR.text) node {\tiny{R}};
\draw (8.6, 6) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=1.5cm] {\tiny{Reserved}};

\draw (0.5, 5.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Valid Lifetime}};

\draw (0.5, 5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Prefered Lifetime}};

\draw (0.5, 4.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Reserved}};

\draw (0.5, 4) node (addr1) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{}};
\draw (0.5, 3.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{}};
\draw (0.5, 3) node (addr3) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Prefix}};
\draw (0.5, 2.5) node (addr4) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{}};

\draw [color=blue!10, very thick] (addr1.south east) -- (addr1.south west);
\draw [color=blue!10, very thick] (addr2.south east) -- (addr2.south west);
\draw [color=blue!10, very thick] (addr3.south east) -- (addr3.south west);
</tikz>

Esta opción contiene las informaciones sobre el prefijo para permitir una configuración automática de los dispositivos. El campo tipo tiene el valor 3 y el de longitud, 4. La figura ''Formato de la opción información sobre el prefijo'' muestra el formato de esta opción:

* El campo ''Prefix lenght'' indica cuántos bits son significativos para el prefijo anunciado en un campo siguiente.
* El bit <tt>L</tt> indica, cuando vale 1, que el prefijo permite indicar que todos los demás dispositivos que comparten el mismo prefijo, están en el mismo enlace, por lo que el emisor puede contactarlos directamente. En caso contrario, el dispositivo envía el paquete hacia el enrutador. Si éste último sabe que el emisor puede contactar directamente al destinatario, emitirá un mensaje ICMPv6 de indicación de redirección.
* El bit <tt>A</tt> indica, cuando vale 1, que el prefijo anunciado puede utilizarse para formar la dirección del dispositivo.
* El bit <tt>R</tt>, indica, cuando vale 1, que el campo prefijo contiene la dirección global de un enrutador ''agente base''. Los bits de mayor peso aún pueden utilizarse para formar un prefijo.
* El campo duración de validez indica, en segundos, la duración durante la cual el prefijo es válido.
* El campo duración preferente indica la duración, en segundos, durante la cual una dirección formada con el protocolo de configuración sin estado se mantiene ''preferente'' (''cf'' [[Planes de direccionamiento|Tiempo de vida de las direcciones]]).

Para estos dos campos, un valor de <tt>0xffffffff</tt> representa una duración infinita. Estos campos pueden servir durante la fase de transición de un proveedor de acceso a otro; es decir, de un prefijo a otro.
* El campo reservado permite alinear el prefijo a una frontera de palabra de 64 bits.
* El campo prefijo contiene el valor de prefijo anunciado sobre el enlace. Para mantener una alineación de 64 bits para el resto de datos del paquete, este campo tiene una longitud fija de 128 bits.

== <div id="redirigida">Cabecera de redirección </div> ==

<tikz title="Formato de la opción cabecera de redirección">
\clip (0.2, 3.1) rectangle (11.1, 7);
% \draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=5}};
\draw (2.9, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{length =1 }};
\draw (5.3, 6) node (addr) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Reserved}};

\draw (0.5, 5.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Reserved}};

\draw (0.5, 4.25) node (context) [right, shade, top color=purple!50, bottom color=purple!10, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{IPv6 Header and Data}};
</tikz>

Esta opción es utilizada por el mensaje de indicación de redirección. Permite encapsular los primeros octetos del paquete IPv6 que provocó la emisión de este mensaje, como ocurre con los mensajes de error de ICMPv6.

El campo tipo tiene el valor 4. El tamaño de esta opción debe evitar que el paquete IPv6 rebase los 1280 octetos (''cf'' figura ''Formato de la opción cabecera de redirección''). Sin embargo, el paquete debe contener la mayor cantidad de información posible.

== <div id="MTU">MTU</div> ==

<tikz title="Formato de la opción MTU">

\clip (0.2, 5.1) rectangle (11.1, 7);
% \draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=5}};
\draw (2.9, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{lenght =1 }};
\draw (5.3, 6) node (addr) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Reserved}};

\draw (0.5, 5.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{MTU}};
</tikz>

Esta opción permite notificar a los dispositivos el tamaño máximo de datos que pueden ser transmitidos sobre el enlace. La figura ''Formato de la opción MTU'' muestra su estructura. No es necesario difundir esta información si el dispositivo utiliza siempre el tamaño máximo permitido. Por ejemplo, sobre las redes Ethernet, los dispositivos utilizarán el valor 1,500. En cambio, en las redes Token Ring o FDDI, con frecuencia es necesario especificar si los equipos pueden utilizar la longitud máxima o un tamaño inferior para permitir el uso de puentes en la red.

En esta opción, el campo tipo tiene un valor de 5 y el de longitud, de 1.

=Mensajes estándar de Descubrimiento de vecinos =

Además de las cinco opciones básicas descritas en la tabla ''Utilización de las opciones en los mensajes de descubrimiento de vecinos'', existen otras específicas para la movilidad y para las redes NBMA (''Non Broadcast Multiple Access'').

{|
|+ Utilización de las opciones en los mensajes de descubrimiento de vecinos
| width = 150 | || width = 100 |[[#RS|Solicitud de]] || width = 100 |[[#RA|Anuncio de]] || width = 100 |[[#NS|Solicitud de]] ||width = 100 | [[#NA|Anuncio de]] ||width = 100 |[[#IR|Indicación de]]
|-
| || [[#RS|enrutador]] || [[#RA|enrutador]] || [[#NS|un vecino]] || [[#NA| un vecino]] || [[#IR|redirección]]
|-style="background:silver"
|[[#física |Dirección física de la fuente]] || presente || presente || presente || ||
|-
|[[# física | Dirección física del destino]] || || || || presente || presente
|-style="background:silver"
|[[#información|Información sobre el prefijo]] || || ≥ 1 || || ||
|-
|[[#redirigida |Cabecera de redirección]] || || || || || presente
|-style="background:silver"
| [[#MTU |MTU]] || || posible || || ||
|}

Las distintas funcionalidades de descubrimiento de vecinos utilizan cinco mensajes: dos para el diálogo entre un dispositivo y un enrutador, dos para el diálogo entre vecinos, y uno para la redirección. Cada uno de estos mensajes puede incluir opciones adicionales.

== <div id="RS">Solicitud de enrutador</div> ==

<tikz title="Formato de los paquetes de solicitud de enrutador">
\clip (0.2, 3.5) rectangle (11.1,7.1);
%\draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=133}};
\draw (2.9, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code =0 }};
\draw (5.3, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};
\draw (0.5, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Reserved}};

\draw (0.5, 4.25) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Options:\\
- Source link-layer address
}};
</tikz>

El mensaje de solicitud de enrutador (''cf'' figura Formato de los paquetes de solicitud de enrutador) es emitido al iniciar un dispositivo para recibir más rápidamente la información del enrutador. Este mensaje se envía a la dirección IPv6 multicast reservada a los enrutadores en el mismo enlace <tt>FF02::2</tt>. Si el dispositivo aún no conoce su dirección fuente, se utiliza la dirección no especificada.

El campo opción normalmente contiene la dirección física del dispositivo.

== <div id="RA">Anuncio de enrutador</div> ==

<tikz title="Formato de los paquetes de anuncio de enrutador">
\clip (0.2, 1.5) rectangle (11.1,7.1);
%\draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=134}};
\draw (2.9, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code =0 }};
\draw (5.3, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};

\draw (0.5, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Cur. Hop Lim.}};
\draw (2.9, 5.5) node (bitM) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{}; \draw (bitM.text) node {\tiny{M}};
\draw (3.2, 5.5) node (bitO) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{};\draw (bitO.text) node {\tiny{O}};
\draw (3.5, 5.5) node (bitH) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{};\draw (bitH.text) node {\tiny{H}};
\draw (3.8, 5.5) node (res) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=1.5cm]{\tiny{reserved}};
\draw (5.3, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Router Lifetime}};

\draw (0.5, 5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=9.6cm]{\tiny{Reachable Time}};
\draw (0.5, 4.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=9.6cm]{\tiny{Retrans Time}};

\draw (0.5, 3.25) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Options:\\
Source link-layer address\\
MTU\\
Prefix Information (may be repeated)\\
}};
</tikz>

Este mensaje (''cf'' figura ''Formato de los paquetes de anuncio de enrutador'') es emitido periódicamente por los enrutadores, o bien, en respuesta a un mensaje de solicitud de enrutador generado por un dispositivo. El campo dirección fuente contiene la dirección de enlace local del enrutador, mientras que el campo dirección destino contiene la dirección del dispositivo que generó la solicitud, o la dirección de todas las estaciones (<tt>ff02::01</tt>).

Cuando el campo de máximo número de saltos tiene un valor distinto de cero, muestra el valor que podría colocarse en el campo de número de saltos de los paquetes emitidos. El bit <tt>M</tt> indica que una dirección del dispositivo debe ser obtenida mediante un protocolo de configuración (''cf'' [[Configuración con estado:DHCPv6]]). El bit <tt>O</tt> también indica la presencia de un servicio de configuración para obtener información adicional a la dirección. Si no es posible obtener la dirección mediante un servidor, el dispositivo procede a realizar una configuración sin estado, concatenando su identificador de interfaz a los prefijos que conoce. El bit <tt>H</tt> indica que el enrutador puede ser utilizado como agente base por un nodo móvil (''cf'' [[Desplazamientos_de_móviles#Anuncio_del_agente_base |Anuncio del agente base]]).

El campo tiempo de vida del enrutador indica el período (en segundos) durante el cual el equipo que emite el anuncio realizará funciones de enrutador por omisión. El valor máximo corresponde a 18 horas 12 minutos, pero como este mensaje se emite periódicamente, en la práctica no existe un límite para el tiempo de vida de un enrutador. Un valor de <tt>0</tt> indica que el dispositivo no cumple con las funciones de enrutador por omisión. Este tiempo de vida no se aplica a las opciones transportadas por este mensaje.

El campo duración de accesibilidad indica el período (en milisegundos) durante el cual una información almacenada en la memoria caché de la máquina (por ejemplo, la tabla de correspondencia entre las direcciones IPv6 y las físicas) puede ser considerada como válida. Al vencimiento de este tiempo, se emite un mensaje de detección de inaccesibilidad para verificar la pertinencia de la información almacenada.

El campo temporización de retransmisión muestra el período (en milisegundos) entre dos emisiones no solicitadas de este mensaje. Permite que los demás equipos puedan detectar la inaccesibilidad de un enrutador.

Este mensaje puede transportar las siguientes opciones:

* dirección física de la fuente,
* MTU,
* información sobre el prefijo (uno o varios).

== <div Id="NS"> Solicitud de un vecino </div> ==

<tikz title="Formato de los paquetes de solicitud de un vecino">

\clip (0.2, 1.5) rectangle (11.1,7.1);
%\draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=135}};
\draw (2.9, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code =0 }};
\draw (5.3, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};

\draw (0.5, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=9.6cm]{\tiny{Reserved}};

\draw (0.5, 4.25) node (context) [right, shade, top color=blue!50, bottom color=blue=!10, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Target Address}};

\draw (0.5, 2.25) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Options:\\
Source link-layer address\\
}};
</tikz>

Este mensaje (''cf'' figura ''Formato de los paquetes de solicitud de un vecino'') permite obtener información a partir de un equipo vecino, es decir, localizado en el mismo enlace físico (o conectado a través de puentes). El mensaje puede ser emitido explícitamente a él, o enviado con una dirección de difusión. En el caso de determinación de la dirección física, éste corresponde a la solicitud de ARP en IPv4.

El campo dirección fuente del paquete IPv6 contiene ya sea la dirección local al enlace, una dirección global o la dirección no especificada. El campo destino puede contener la dirección de difusión múltiple solicitada correspondiente a la dirección buscada (''cf'' [[Direccionamiento_multicast#Identificador_de_grupo|Identificador de grupo]]) o la dirección del dispositivo (en el caso de una detección de inaccesibilidad de vecinos, ''NUD'').

El campo dirección del destino contiene la dirección IPv6 del equipo buscado. El campo opción generalmente contiene la dirección física de la fuente.

== <div Id="NA"> Anuncio de un vecino</div> ==

<tikz title="Formato de los paquetes de anuncio de un vecino">

\clip (0.2, 1.5) rectangle (11.1,7.1);
%\draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=136}};
\draw (2.9, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code =0 }};
\draw (5.3, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};

\draw (0.5, 5.5) node (bitR) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{}; \draw (bitR.text) node {\tiny{R}};
\draw (0.8, 5.5) node (bitS) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{}; \draw (bitS.text) node {\tiny{S}};
\draw (1.1, 5.5) node (bitO) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{}; \draw (bitO.text) node {\tiny{O}};
\draw (1.4, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=8.7cm]{\tiny{Reserved}};

\draw (0.5, 4.25) node (context) [right, shade, top color=blue!50, bottom color=blue=!10, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Target Address}};

\draw (0.5, 2.25) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Options:\\
Source link-layer address\\
}};
</tikz>

Este mensaje (''cf'' figura ''Formato de los paquetes de anuncio de un vecino'') se emite en respuesta a una solicitud, aunque también puede ser emitido de forma espontánea para propagar la información de cambio de dirección física, o del estado de "enrutador". Para el caso de la determinación de la dirección física, es equivalente a la respuesta ARP en IPv4.

* El bit <tt> R </tt> se pone a 1 si el remitente es un enrutador. Este bit se utiliza para permitir la detección de un enrutador que se convierte en un equipo ordinario.
* El bit <tt> S </tt> en 1 indica que este anuncio se emite en respuesta a una solicitud.
* El bit <tt> O </tt> en 1 indica que este anuncio debe borrar las informaciones anteriores que se encuentran almacenadas en la memoria cachés de otros equipos, en especial la tabla que contiene las direcciones físicas.
* El campo dirección del destino contiene, si el bit<tt> S </tt> es 1, el valor del campo dirección del destino de la solicitud a la que está respondiendo este mensaje. Si el bit <tt> S </tt> es 0, este campo contiene la dirección IPv6 local al enlace del equipo emisor.
* La opción dirección física del destino contiene la dirección física del emisor.

== <div id="IR">Indicación de redirección</div> ==

<tikz title="Formato de los paquetes de indicación de redirección">
\clip (0.2, 0) rectangle (11.1,7.1);
%\draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=137}};
\draw (2.9, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code =0 }};
\draw (5.3, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};

\draw (0.5, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=9.6cm]{\tiny{Reserved}};

\draw (0.5, 4.25) node (context) [right, shade, top color=blue!50, bottom color=blue=!10, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Target Address}};

\draw (0.5, 2.25) node (context) [right, shade, top color=blue!50, bottom color=blue=!10, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Destination Address}};

\draw (0.5, 0.5) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=1.5cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Options:\\
Target link-layer address\\
Redirected Header\\
}};
</tikz>

La técnica de redirección es la misma que en IPv4. Un dispositivo sólo conoce los prefijos de las redes a las que está conectado directamente y la dirección de un enrutador por omisión. Si la ruta se puede optimizar, el enrutador por omisión envía un mensaje para indicar que existe un camino más corto. De hecho, como en IPv6 el enrutador por omisión se establece de forma automática, las rutas no necesariamente son las mejores (''cf'' figura ''Enrutamiento por omisión no óptimo'').

Otro caso particular en IPv6 ocurre con los dispositivos que se encuentran en el mismo enlace físico, pero tienen diferentes prefijos. La comunicación entre ellos pasa inicialmente a traves de enrutador por omisión hasta que éste notifica que existe una ruta directa entre ellos.

La figura ''Formato de los paquetes de indicación de redirección'' muestra el formato del mensaje:

* El campo dirección objetivo (''Target address'') contiene la dirección IPv6 del equipo hacia el que los paquetes deben ser enviados.
* El campo dirección destino contiene la dirección IPv6 del dispositivo que está siendo redirigido hacia la dirección objetivo.

Cuando la redirección apunta a un dispositivo situado en el mismo enlace, la dirección objetivo y de destino son las mismas.

Las opciones incluyen la dirección física de un nuevo enrutador y la cabecera del paquete redirigido.

Este mensaje se puede utilizar de la misma forma que en IPv4. Un dispositivo solamente tiene una ruta por omisión para acceder a equipos con un prefijo diferente. En consecuencia, envía su paquete al enrutador por omisión, quien observa que el prefijo destino es accesible a través de la misma subred que el emisor. El enrutador por omisión reenvía el paquete y notifica al emisor que puede contactar directamente a las máquinas que poseen el prefijo del destino.

IPv6 también utiliza este mensaje para optimizar la resolución fuera del enlace para el [[#Caso de redes NBMA |caso de redes NBMA]].

= Configuración automática =
Tradicionalmente, la configuración de una interfaz de red de una máquina se hacía manualmente. Esto suele ser un trabajo lento y propenso a errores. Con IPv6, se automatiza el proceso de configuración y se introducen, al mismo tiempo, mecanismos de funcionamiento inmediato (''plug and play'') a la interfaz de red. La configuración automática significa que un dispositivo obtendrá toda la información necesaria para su conexión a una red local IP sin ninguna intervención humana. En el caso ideal, cualquier usuario desempaca su nuevo equipo, lo conecta a la red local y lo ve funcionar sin tener que introducir la información propia de "especialistas". Ahora vamos a discutir otro aspecto de la configuración automática de IPv6, la auto-configuración de direcciones, que tiene como objetivos:

* La adquisición de una dirección cuando un dispositivo está conectado a una red por primera vez;
* la posibilidad de asignar otros prefijos, o de renumerar un dispositivo.

El proceso de configuración automática de direcciones IPv6 incluye la creación de una dirección local al enlace, la agregación a grupos multicast solicitados, la verificación de la unicidad de la dirección local al enlace y la creación de direcciones unicast global.

La tarea del enrutador es importante en la configuración automática. Indica a la máquina, mediante los bits de la cabecera (ver [[#RA|anuncio de enrutador]]), del mensaje de anuncio de los enrutadores, el método a conservar y eventualmente proporcionar la información necesaria para su configuración. El bit <tt> M </tt> (''configuración de dirección administrada'') puesto a 1 indica que el equipo no debe crear por sí mismo una dirección a partir de su identificador de interfaz y de los prefijos recibidos, sino que debe solicitarla explícitamente ante un servidor de direcciones. El bit O <tt> </tt> (''otra configuración de estado'') indica que el dispositivo debe consultar el servidor para obtener otros parámetros distintos de la dirección. El algoritmo para el proceso de configuración automática de direcciones se desglosa de la siguiente manera:

* La primera fase consiste en crear la dirección local al enlace.
* Una vez que la unicidad de esta dirección es verificada, el dispositivo está listo para comunicarse con otras máquinas en el enlace.
* El dispositivo debe tratar de adquirir un mensaje de anuncio de enrutadores para determinar el método de obtención de la dirección unicast global.
* Si hay un enrutador en el enlace, el dispositivo debe aplicar el método especificado por el mensaje de anuncio de enrutadores, a saber:
** La configuración automática sin estado,
** la configuración automática con estado.
* Si no hay ningún enrutador en el enlace, el dispositivo debe tratar de obtener la dirección unicast global por el método de configuración automática con estado. Si el intento falla, no hay más que hacer. Las comunicaciones sólo podrán hacerse sobre el enlace con la dirección local al enlace, pues el dispositivo no tendrá una dirección con la cobertura necesaria que le permita comunicarse con otras máquinas fuera del enlace.

==Ciclo de vida de una dirección==

Al generalizar en IPv6 el plan de direccionamiento CIDR, los prefijos quedan, en todos los casos, siendo propiedad de los operadores. Ya no pueden otorgarse "a perpetuidad" a los dispositivos. Para facilitar la renumeración de una máquina, la asignación de una dirección a una interfaz es temporal, las direcciones IPv6 no se entregan, sino que se prestan. Se asocia un tiempo de vida a la dirección, que indica el tiempo durante el cual la dirección pertenece a la interfaz. Cuando el tiempo de vida se ha agotada, la dirección deja de ser válida, se suprime de la interfaz y queda potencialmente éste puede prolongarse indefinidamente. La dirección local al enlace tiene un tiempo de vida ilimitado.

<tikz title="Estados sucesivos de una dirección en una interfaz">

\draw [thick, ->] (0,2) -- (9.5,2);

\draw [->] (1,4) node [above=10pt] {\tiny{allocation}}-- (1,2);
\draw (1, 2) node [rectangle, minimum width=1cm, minimum height=1cm, fill, left color=black!10, right color=black!20, draw=black, above right] (tentative) {};
\draw (tentative.south east) node [rectangle, minimum width=3cm, minimum height=1cm, fill, left color=green, right color=green!50, draw=black, above right] (preferred) {};
\draw (preferred.south east) node [rectangle, minimum width=2cm, minimum height=1cm, fill, left color=orange , right color=orange!50!red, draw=black, above right] (deprecated) {};
\draw (deprecated.south east) node [rectangle, minimum width=2cm, minimum height=1cm, fill, color=red, draw=black, above right] (novalid) {};

\draw (tentative.text) node {\tiny{Tentative}};
\draw (preferred.text) node {\tiny{Preferred}};
\draw (deprecated.text) node {\tiny{Deprecated}};
\draw (novalid.text) node {\tiny{Invalid}};

\draw [dotted] (tentative.south west) -- +(0, -1);
\draw [dotted] (preferred.south west) -- +(0, -1);
\draw [dotted] (deprecated.south west) -- +(0, -1);
\draw [dotted] (novalid.south west) -- +(0, -1);

\draw [dashed, <->] ([yshift=-0.5cm]tentative.south west) -- node [above] {\tiny{DAD}} ([yshift=-0.5cm] preferred.south west) ;

\draw [dashed, <->] ([yshift=-0.5cm]preferred.south west) -- node [above] {\tiny{Valid}} ([yshift=-0.5cm] novalid.south west) ;

</tikz>

La renumeración de una interfaz consiste en pasar de una dirección a otra. Durante una renumeración, no es aconsejable cambiar repentinamente de dirección, de lo contrario, todas las comunicaciones TCP que la utilizan como identificador de conexión, se cortarían inmediatamente. Esto conllevaría importantes perturbaciones a nivel de las aplicaciones.

Por ello, para facilitar esta transición se implementó un mecanismo de obsolescencia que invalida gradualmente una dirección. Este mecanismo se sirve de la capacidad de asignación de varias direcciones válidas a una misma interfaz. Para elegir la dirección a utilizar, se le asocia un estado que indica en qué fase de su tiempo de vida se encuentra con respecto a la interfaz. El primero de esos estados se conoce como preferido: no hay ninguna restricción de uso. Poco antes de su invalidación, la dirección pasa a un estado de depreciado. En él se desaconseja el uso de la dirección, pero no está prohibido. Una dirección depreciada ya no debe ser utilizada como dirección fuente de nuevas comunicaciones (como el establecimiento de conexión TCP), pero todavía puede emplearse como dirección fuente de comunicaciones ya establecidas. Los paquetes recibidos a una dirección depreciada seguirán siendo entregados normalmente. El control de la duración de cada estad de una dirección válida se efectúa agregando un tiempo de vida al estado preferido.
La figura '''Estados sucesivos de una dirección en una interfaz''' representa los diferentes estados que toma una dirección cuando se asigna a una interfaz.

== Creación de la dirección local al enlace ==

<tikz title=" Creación de la dirección local al enlace">
\clip (0, 0) rectangle (10,7);
% \draw[help lines] (0,0) grid (10,7 );

\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,3)--(9,3);

\pgfputat{\pgfxy(0.8,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,5)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,3)--(1.5,5);
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (8,3)--(8,5);

\draw (1.5,4.5) node {\small{FE80::IID1}};
\draw (1.5,4) node {\small{$\alpha$::IID1/64}};

\draw (8, 4.5) node {\small{FE80::IID2}};

</tikz>

Durante la inicialización de la interfaz, el dispositivo construye un identificador de interfaz que debe ser único en el enlace. Este identificador se utiliza la dirección de [[ Identificador_de_interfaz#EUI-64 | EUI-64]]. El principio básico para crear la direcciónIPv6 consiste en unir un prefijo con el identificador. La dirección local al enlace se crea tomando el prefijo de Enlace_local (<tt>FE80::/64</tt>). La dirección creada de esa manera, todavía no puede ser utilizada; tiene un estado temporal pues el dispositivo debe comprobar la exclusividad de esta dirección en el enlace mediante el procedimiento de detección de direcciones duplicadas. Si se encuentra que la dirección local al enlace no es única, se suspende la autoconfiguración y será necesario proceder a una configuración manual.

Una vez que se ha asegurado la unicidad de la dirección local al enlace, ésta se considera una dirección válida para la interfaz, con lo que termina la prima fase del proceso de autoconfiguración.

==<div id="DAD"> Detección de una dirección duplicada </div>==

<tikz title="Emisión de un NS en una detección de Dir. duplicada (DAD)">
\clip (0, 0) rectangle (10,7);
% \draw[help lines] (0,0) grid (10,7 );

\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,3)--(9,3);

\pgfputat{\pgfxy(0.8,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,5)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,3)--(1.5,5);
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (8,3)--(8,5);

\draw (7.8, 5) -- (7.8, 3.2);
\draw [<->] (1, 3.2) -- node [above] {\tiny{::/0 -$>$ solicited (FE80:IID2) : NS (who has FE80::IID2?)}}(9, 3.2) ;

</tikz>

Para comprobar la exclusividad de direcciones locales al enlace o de direcciones unicast, los dispositivos deben ejecutar un algoritmo de detección de direcciones duplicadas (DAD) antes poder utilizarlas. El algoritmo usa los mensajes ICMPv6 [[Descubrimiento de vecinos#NS|solicitud de un vecino]] y [[Descubrimiento de vecinos#NA|anuncio de un vecino.]] Si se detecta una dirección que ya está en uso, ésta no podrá ser asignada a la interfaz, la autoconfiguración automática debe suspenderse y será necesario proceder a una configuración manual. Durante la ejecución del algoritmo DAD, la dirección es considerada como "provisional" hasta tener la confirmación de su unicidad. Una dirección provisional se asigna a una interfaz únicamente para recibir los mensajes de solicitud y anuncio de un vecino. Otros mensajes recibidos, son ignorados. El algoritmo DAD consiste en enviar un mensaje de solicitud de un vecino colocando en el campo de dirección objetivo la dirección provisional. Para distinguir el algoritmo DAD del de Descubrimiento de vecinos, el paquete IPv6 que contiene un mensaje de solicitud de un vecino tiene como dirección fuente una dirección no determinada. Así se presentan tres casos:

* Se recibe un mensaje de anucio de un vecino: Significa que la dirección provisional está siendo utilizada como válida por otro dispositivo, por lo que ésta no es única y no puede ser retenida por el dispositivo.
* Se recibe un mensaje de solicitud de un vecino como parte del algoritmo DAD. La dirección provisional también es provisional para otra máquina. En este caso, la dirección provisional no puede ser utilizada por ninguna de ellas.
* No se recibe ningún mensaje durante un segundo (valor por omisión). La dirección provisional es única, por lo que su estado pasa de provisional a válida y se le asigna a la interfaz.

Obsérvese que este algoritmo no proporciona una fiabilidad absoluta, especialmente cuando el enlace está segmentado.

== Autoconfiguración sin estado ==

<tikz title="Emisión de un RS">
\clip (0, 0) rectangle (10,7);
% \draw[help lines] (0,0) grid (10,7 );

\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,3)--(9,3);

\pgfputat{\pgfxy(0.8,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,5)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,3)--(1.5,5);
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (8,3)--(8,5);

\draw (7.8, 5) -- (7.8, 3.2);
\draw [<->] (1, 3.2) -- node [above] {\tiny{FE80::IID2 -$>$ FF02::2 : RS }} (9, 3.2) ;

</tikz>

La configuración automática sin estado (RFC 2462) no requiere de ninguna configuración manual de los dispositivos, una configuración mínima para los enrutadores, y tampoco necesita de servidores adicionales. Se sirve del protocolo ICMPv6 y puede operar aún sin la presencia de enrutadores. En cambio, sí requiere de una subred con soporte a la difusión de paquetes. Este método sólo aplica para los dispositivos; no puede ser utilizada para configurar enrutadores. El principio básico de este mecanismo consiste en que una máquina genera su dirección IPv6 a partir de información local y de la proporcionada por un enrutador. El enrutador proporciona información sobre la subred asociada al enlace; anuncia el prefijo.

{{eSuivi|Tabla de contenido|Incio del capítulo|DHCPv6|DHCPv6}}

Protocolo de Descubrimiento de vecinos

2012-07-04T22:04:30Z

Jincera: /* Anuncio de vecino */

{{eSuivi|Tabla de contenido|Incio del capítulo|DHCPv6|DHCPv6}}

__TOC__

El protocolo de descubrimiento de vecinos (NDP, ''Neighbor Discovery Protocol'') permite a un dispositivo integrarse en el ambiente local, es decir, el enlace sobre el cual se transmiten físicamente los paquetes IPv6. Permite establecer un diálogo con los equipos (estaciones y enrutadores) conectados sobre el mismo medio. No se pretende que un dispositivo conozca con exactitud la lista de todos los demás dispositivos conectados al enlace, sino de proveer un mecanismo para dialogar con quien necesite hacerlo.

El protocolo utiliza cinco tipos de mensajes ICMPv6 (ver Valores de los campos de tipo y código de ICMPv6). El campo número de saltos de la cabecera IPv6 contiene el valor 255. Este valor parece demasiado grande para datagramas que no debieran ser enrutados fuera del enlace físico. En realidad, si un equipo recibe un datagrama con un valor menor, significa que la información proviene de otra red y que ya ha atravesado al menos un enrutador. Por ello, los datagramas que tienen un valor diferente de 255 deben ser ignorados por el receptor.

{{Tableau eICMPv6}}

El protocolo realiza varias funciones:

* Resolución de direcciones. El principio es muy similar al del protocolo ARP de IPv4. La principal diferencia consiste en el uso de mensajes ICMPv6 estándar en lugar de definir otro protocolo de capa 3. Con esto se consigue una mayor flexibilidad de uso, especialmente en las redes que no soportan la difusión de mensajes. Al igual que en IPv4, el protocolo se encarga de construir tablas de correspondencia entre las direcciones IPv6 y las físicas.
* <div vecinos id="NUD"> Detección de inaccesibilidad de vecinos (NUD, ''Neighbor Unreachability Detection''). Esta función, que no existe en IPv4, permite eliminar de las tablas de configuración de un equipo, los vecinos que se han vuelto inaccesibles (por fallas, cambio de domicilio, ...). Si un enrutador deja de estar disponible, la tabla de enrutamiento puede ser modificada para considerar otra ruta. </div>
* Configuración. La configuración automática de los dispositivos es uno de los principales atractivos de IPv6. Se implementan varias funcionalidades del protocolo de descubrimiento de vecinos:
**Descubrimiento de enrutadores. Este protocolo permite que los dispositivos identifiquen a los enrutadores que se encuentran en su enlace físico. En IPv4, esta función la proporciona el protocolo ''ICMP Router Discovery''.
** Descubrimiento de prefijos. El dispositivo conoce el o los prefijos de red de acuerdo a los anuncios realizados por los enrutadores. Agregando su identificador de interfaz, el dispositivo construye su o sus direcciones IPv6. No hay un mecanismo equivalente para las direcciones IPv4 ya que son demasiado cortas para realizar la auto-configuración.
** Detección de direcciones duplicadas. Dado que las direcciones se configuran de forma automática, existen riesgos de error en caso de tener equipos con identificadores repetidos. Este protocolo verifica que ningún otro equipo en el enlace tiene la misma dirección IPv6. Esta función es una evolución del ARP gratuito en IPv4 emitido durante la inicialización de la interfaz.
** Descubrimiento de parámetros. Este protocolo permite que los dispositivos conozcan los distintos parámetros del enlace físico, por ejemplo, el tamaño de MTU, el número máximo de saltos permitido (valor original del campo número de saltos), si la configuración automática con estado (como [[Configuración con estado: DHCPv6|DHCPv6]]) está activa, etc. No existe un equivalente de esta funcionalidad en IPv4.
* Indicación de redirección. Este mensaje se utiliza cuando un enrutador conoce una trayectoria mejor (medida en número de saltos) para alcanzar un destino.
:En IPv4 una indicación de redireccionamiento sólo puede servir para corregir la dirección del enrutador utilizado para acceder a una máquina fuera de la red local. Los dispositivos deben conocer todas las direcciones correspondientes a equipos conectados en su propia red local.
:EnIPv6, la correspondencia entre prefijo y red local es menos rígida. Es de esperar que un dispositivo no conozca todos los prefijos de su red local (si ésta es compartida por varios prefijos), o que un prefijo se comparta entre varios enlaces (lo que corresponde a una generalización del modelo de redes lógicas IP sobre ATM). Bajo algunas configuraciones, la máquina emitirá sus paquetes al enrutador aún si el destinatario se encuentra en el mismo segmento que el emisor. En este caso, el enrutador emitirá un mensaje de redirección para que la continuación del diálogo entre ellos haga de manera directa (véanse los ejemplos [[#IR|Indicación redirección]]).
:En el caso más extremo, podría imaginarse en IPv6 que un dispositivo puede ser configurado para comunicarse únicamente con su enrutador por omisión. ICMPv6 ''redirect'' puede utilizarse entonces, para informar al dispositivo de destinatarios ubicados en el mismo enlace.

En IPv6 se especifican dos métodos de autoconfiguración para las direcciones unicast global:

* Autoconfiguración sin estado (''stateless autoconfiguration'', RFC 2462). Se utiliza cuando no es necesaria una gestión administrativa de las direcciones asignadas dentro de un sitio. Estos mecanismos se describen más adelante en este capítulo.
* Autoconfiguración con estado (''statefull autoconfiguration''). Se utiliza cuando un sitio requiere de un control estricto de la asignación de direcciones (''cf'' [[Configuración con estado: DHCPv6 | DHCPv6]]).

Sin embargo, el uso de DHCPv6 para obtener la dirección se controla mediante el protocolo de descubrimiento de vecinos.

= Datos transmitidos por los mensajes =

La principal motivación detrás del Protocolo de Descubrimiento de vecinos es unificar varios protocolos existentes en IPv4. En particular, la mayor parte de los datos utiliza un formato de opciones común, lo que simplifica la implementación del protocolo. El formato contiene los campos: tipo, longitud (en palabras de 64 bits), y datos. La baja precisión de campo longitud, presentará un desperdicio de espacio, pero permite una alineación de las opciones en palabras de 64 bits, lo que permite un procesamiento optimizado.

{{NB-Opciones}}

== <div id="física">Dirección física de la fuente/destino</div> ==

<tikz title="Formato de la opción dirección física fuente/destino">
\clip (0.2, 5.7) rectangle (11.1,6.7);
% \draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=1/2}};
\draw (2.9, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{lenght }};
\draw (5.3, 6) node (addr) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Link Layer Address}};

\draw [draw=white, thick] (addr.north east) -- (addr.south east);
\draw [draw=white, thick] (addr.north east) -- +(-2, 0);
\draw [draw=white, thick] (addr.south east) -- +(-2, 0);

\draw [dashed] (addr.north east) -- (addr.south east);
\draw [dashed] (addr.north east) -- +(-2, 0);
\draw [dashed] (addr.south east) -- +(-2, 0);
</tikz>

La figura ''Formato de la opción dirección física fuente/destino'' presenta estas opciones. El tipo 1 designa la dirección física de la fuente y el tipo 2 la dirección del destino.

El campo ''length'' es el tamaño en palabras de 64 bits de la opción. Por lo tanto, para el caso de una dirección MAC con longitud de 6 octetos, contiene el valor 1.

El RFC 2464 define el formato para las direcciones MAC-48 utilizadas en las redes Ethernet y Wi-Fi. El RFC 4944 define el formato para las direcciones MAC-16 y MAC-64 utilizadas en las redes de sensores bajo la norma IEEE 802.15.4.

== <div id="información">Información sobre el prefijo</div> ==

<tikz title="Formato de la opción información sobre el prefijo">
\clip (0.2, 2) rectangle (11.1, 7);
% \draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=3}};
\draw (2.9, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{length =4 }};
\draw (5.3, 6) node (addr) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm] {\tiny{Prefix Length}};
\draw (7.7, 6) node (bitL) [right, shade, top color=blue!15, bottom color=blue!5,, draw, minimum height=0.5cm, minimum width=.3cm]{}; \draw (bitL.text) node {\tiny{L}};
\draw (8, 6) node (bitA) [right, shade, top color=blue!15, bottom color=blue!5,, draw, minimum height=0.5cm, minimum width=.3cm]{};\draw (bitA.text) node {\tiny{A}};
\draw (8.3, 6) node (bitR) [right, shade, top color=blue!15, bottom color=blue!5,, draw, minimum height=0.5cm, minimum width=.3cm]{};\draw (bitR.text) node {\tiny{R}};
\draw (8.6, 6) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=1.5cm] {\tiny{Reserved}};

\draw (0.5, 5.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Valid Lifetime}};

\draw (0.5, 5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Prefered Lifetime}};

\draw (0.5, 4.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Reserved}};

\draw (0.5, 4) node (addr1) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{}};
\draw (0.5, 3.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{}};
\draw (0.5, 3) node (addr3) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Prefix}};
\draw (0.5, 2.5) node (addr4) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{}};

\draw [color=blue!10, very thick] (addr1.south east) -- (addr1.south west);
\draw [color=blue!10, very thick] (addr2.south east) -- (addr2.south west);
\draw [color=blue!10, very thick] (addr3.south east) -- (addr3.south west);
</tikz>

Esta opción contiene las informaciones sobre el prefijo para permitir una configuración automática de los dispositivos. El campo tipo tiene el valor 3 y el de longitud, 4. La figura ''Formato de la opción información sobre el prefijo'' muestra el formato de esta opción:

* El campo ''Prefix lenght'' indica cuántos bits son significativos para el prefijo anunciado en un campo siguiente.
* El bit <tt>L</tt> indica, cuando vale 1, que el prefijo permite indicar que todos los demás dispositivos que comparten el mismo prefijo, están en el mismo enlace, por lo que el emisor puede contactarlos directamente. En caso contrario, el dispositivo envía el paquete hacia el enrutador. Si éste último sabe que el emisor puede contactar directamente al destinatario, emitirá un mensaje ICMPv6 de indicación de redirección.
* El bit <tt>A</tt> indica, cuando vale 1, que el prefijo anunciado puede utilizarse para formar la dirección del dispositivo.
* El bit <tt>R</tt>, indica, cuando vale 1, que el campo prefijo contiene la dirección global de un enrutador ''agente base''. Los bits de mayor peso aún pueden utilizarse para formar un prefijo.
* El campo duración de validez indica, en segundos, la duración durante la cual el prefijo es válido.
* El campo duración preferente indica la duración, en segundos, durante la cual una dirección formada con el protocolo de configuración sin estado se mantiene ''preferente'' (''cf'' [[Planes de direccionamiento|Tiempo de vida de las direcciones]]).

Para estos dos campos, un valor de <tt>0xffffffff</tt> representa una duración infinita. Estos campos pueden servir durante la fase de transición de un proveedor de acceso a otro; es decir, de un prefijo a otro.
* El campo reservado permite alinear el prefijo a una frontera de palabra de 64 bits.
* El campo prefijo contiene el valor de prefijo anunciado sobre el enlace. Para mantener una alineación de 64 bits para el resto de datos del paquete, este campo tiene una longitud fija de 128 bits.

== <div id="redirigida">Cabecera de redirección </div> ==

<tikz title="Formato de la opción cabecera de redirección">
\clip (0.2, 3.1) rectangle (11.1, 7);
% \draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=5}};
\draw (2.9, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{length =1 }};
\draw (5.3, 6) node (addr) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Reserved}};

\draw (0.5, 5.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Reserved}};

\draw (0.5, 4.25) node (context) [right, shade, top color=purple!50, bottom color=purple!10, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{IPv6 Header and Data}};
</tikz>

Esta opción es utilizada por el mensaje de indicación de redirección. Permite encapsular los primeros octetos del paquete IPv6 que provocó la emisión de este mensaje, como ocurre con los mensajes de error de ICMPv6.

El campo tipo tiene el valor 4. El tamaño de esta opción debe evitar que el paquete IPv6 rebase los 1280 octetos (''cf'' figura ''Formato de la opción cabecera de redirección''). Sin embargo, el paquete debe contener la mayor cantidad de información posible.

== <div id="MTU">MTU</div> ==

<tikz title="Formato de la opción MTU">

\clip (0.2, 5.1) rectangle (11.1, 7);
% \draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=5}};
\draw (2.9, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{lenght =1 }};
\draw (5.3, 6) node (addr) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Reserved}};

\draw (0.5, 5.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{MTU}};
</tikz>

Esta opción permite notificar a los dispositivos el tamaño máximo de datos que pueden ser transmitidos sobre el enlace. La figura ''Formato de la opción MTU'' muestra su estructura. No es necesario difundir esta información si el dispositivo utiliza siempre el tamaño máximo permitido. Por ejemplo, sobre las redes Ethernet, los dispositivos utilizarán el valor 1,500. En cambio, en las redes Token Ring o FDDI, con frecuencia es necesario especificar si los equipos pueden utilizar la longitud máxima o un tamaño inferior para permitir el uso de puentes en la red.

En esta opción, el campo tipo tiene un valor de 5 y el de longitud, de 1.

=Mensajes estándar de Descubrimiento de vecinos =

Además de las cinco opciones básicas descritas en la tabla ''Utilización de las opciones en los mensajes de descubrimiento de vecinos'', existen otras específicas para la movilidad y para las redes NBMA (''Non Broadcast Multiple Access'').

{|
|+ Utilización de las opciones en los mensajes de descubrimiento de vecinos
| width = 150 | || width = 100 |[[#RS|Solicitud de]] || width = 100 |[[#RA|Anuncio de]] || width = 100 |[[#NS|Solicitud de]] ||width = 100 | [[#NA|Anuncio de]] ||width = 100 |[[#IR|Indicación de]]
|-
| || [[#RS|enrutador]] || [[#RA|enrutador]] || [[#NS|un vecino]] || [[#NA| un vecino]] || [[#IR|redirección]]
|-style="background:silver"
|[[#física |Dirección física de la fuente]] || presente || presente || presente || ||
|-
|[[# física | Dirección física del destino]] || || || || presente || presente
|-style="background:silver"
|[[#información|Información sobre el prefijo]] || || ≥ 1 || || ||
|-
|[[#redirigida |Cabecera de redirección]] || || || || || presente
|-style="background:silver"
| [[#MTU |MTU]] || || posible || || ||
|}

Las distintas funcionalidades de descubrimiento de vecinos utilizan cinco mensajes: dos para el diálogo entre un dispositivo y un enrutador, dos para el diálogo entre vecinos, y uno para la redirección. Cada uno de estos mensajes puede incluir opciones adicionales.

== <div id="RS">Solicitud de enrutador</div> ==

<tikz title="Formato de los paquetes de solicitud de enrutador">
\clip (0.2, 3.5) rectangle (11.1,7.1);
%\draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=133}};
\draw (2.9, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code =0 }};
\draw (5.3, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};
\draw (0.5, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Reserved}};

\draw (0.5, 4.25) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Options:\\
- Source link-layer address
}};
</tikz>

El mensaje de solicitud de enrutador (''cf'' figura Formato de los paquetes de solicitud de enrutador) es emitido al iniciar un dispositivo para recibir más rápidamente la información del enrutador. Este mensaje se envía a la dirección IPv6 multicast reservada a los enrutadores en el mismo enlace <tt>FF02::2</tt>. Si el dispositivo aún no conoce su dirección fuente, se utiliza la dirección no especificada.

El campo opción normalmente contiene la dirección física del dispositivo.

== <div id="RA">Anuncio de enrutador</div> ==

<tikz title="Formato de los paquetes de anuncio de enrutador">
\clip (0.2, 1.5) rectangle (11.1,7.1);
%\draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=134}};
\draw (2.9, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code =0 }};
\draw (5.3, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};

\draw (0.5, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Cur. Hop Lim.}};
\draw (2.9, 5.5) node (bitM) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{}; \draw (bitM.text) node {\tiny{M}};
\draw (3.2, 5.5) node (bitO) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{};\draw (bitO.text) node {\tiny{O}};
\draw (3.5, 5.5) node (bitH) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{};\draw (bitH.text) node {\tiny{H}};
\draw (3.8, 5.5) node (res) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=1.5cm]{\tiny{reserved}};
\draw (5.3, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Router Lifetime}};

\draw (0.5, 5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=9.6cm]{\tiny{Reachable Time}};
\draw (0.5, 4.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=9.6cm]{\tiny{Retrans Time}};

\draw (0.5, 3.25) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Options:\\
Source link-layer address\\
MTU\\
Prefix Information (may be repeated)\\
}};
</tikz>

Este mensaje (''cf'' figura ''Formato de los paquetes de anuncio de enrutador'') es emitido periódicamente por los enrutadores, o bien, en respuesta a un mensaje de solicitud de enrutador generado por un dispositivo. El campo dirección fuente contiene la dirección de enlace local del enrutador, mientras que el campo dirección destino contiene la dirección del dispositivo que generó la solicitud, o la dirección de todas las estaciones (<tt>ff02::01</tt>).

Cuando el campo de máximo número de saltos tiene un valor distinto de cero, muestra el valor que podría colocarse en el campo de número de saltos de los paquetes emitidos. El bit <tt>M</tt> indica que una dirección del dispositivo debe ser obtenida mediante un protocolo de configuración (''cf'' [[Configuración con estado:DHCPv6]]). El bit <tt>O</tt> también indica la presencia de un servicio de configuración para obtener información adicional a la dirección. Si no es posible obtener la dirección mediante un servidor, el dispositivo procede a realizar una configuración sin estado, concatenando su identificador de interfaz a los prefijos que conoce. El bit <tt>H</tt> indica que el enrutador puede ser utilizado como agente base por un nodo móvil (''cf'' [[Desplazamientos_de_móviles#Anuncio_del_agente_base |Anuncio del agente base]]).

El campo tiempo de vida del enrutador indica el período (en segundos) durante el cual el equipo que emite el anuncio realizará funciones de enrutador por omisión. El valor máximo corresponde a 18 horas 12 minutos, pero como este mensaje se emite periódicamente, en la práctica no existe un límite para el tiempo de vida de un enrutador. Un valor de <tt>0</tt> indica que el dispositivo no cumple con las funciones de enrutador por omisión. Este tiempo de vida no se aplica a las opciones transportadas por este mensaje.

El campo duración de accesibilidad indica el período (en milisegundos) durante el cual una información almacenada en la memoria caché de la máquina (por ejemplo, la tabla de correspondencia entre las direcciones IPv6 y las físicas) puede ser considerada como válida. Al vencimiento de este tiempo, se emite un mensaje de detección de inaccesibilidad para verificar la pertinencia de la información almacenada.

El campo temporización de retransmisión muestra el período (en milisegundos) entre dos emisiones no solicitadas de este mensaje. Permite que los demás equipos puedan detectar la inaccesibilidad de un enrutador.

Este mensaje puede transportar las siguientes opciones:

* dirección física de la fuente,
* MTU,
* información sobre el prefijo (uno o varios).

== <div Id="NS"> Solicitud de un vecino </div> ==

<tikz title="Formato de los paquetes de solicitud de un vecino">

\clip (0.2, 1.5) rectangle (11.1,7.1);
%\draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=135}};
\draw (2.9, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code =0 }};
\draw (5.3, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};

\draw (0.5, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=9.6cm]{\tiny{Reserved}};

\draw (0.5, 4.25) node (context) [right, shade, top color=blue!50, bottom color=blue=!10, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Target Address}};

\draw (0.5, 2.25) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Options:\\
Source link-layer address\\
}};
</tikz>

Este mensaje (''cf'' figura ''Formato de los paquetes de solicitud de un vecino'') permite obtener información a partir de un equipo vecino, es decir, localizado en el mismo enlace físico (o conectado a través de puentes). El mensaje puede ser emitido explícitamente a él, o enviado con una dirección de difusión. En el caso de determinación de la dirección física, éste corresponde a la solicitud de ARP en IPv4.

El campo dirección fuente del paquete IPv6 contiene ya sea la dirección local al enlace, una dirección global o la dirección no especificada. El campo destino puede contener la dirección de difusión múltiple solicitada correspondiente a la dirección buscada (''cf'' [[Direccionamiento_multicast#Identificador_de_grupo|Identificador de grupo]]) o la dirección del dispositivo (en el caso de una detección de inaccesibilidad de vecinos, ''NUD'').

El campo dirección del destino contiene la dirección IPv6 del equipo buscado. El campo opción generalmente contiene la dirección física de la fuente.

== <div Id="NA"> Anuncio de un vecino</div> ==

<tikz title="Formato de los paquetes de anuncio de vecino">

\clip (0.2, 1.5) rectangle (11.1,7.1);
%\draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=136}};
\draw (2.9, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code =0 }};
\draw (5.3, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};

\draw (0.5, 5.5) node (bitR) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{}; \draw (bitR.text) node {\tiny{R}};
\draw (0.8, 5.5) node (bitS) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{}; \draw (bitS.text) node {\tiny{S}};
\draw (1.1, 5.5) node (bitO) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{}; \draw (bitO.text) node {\tiny{O}};
\draw (1.4, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=8.7cm]{\tiny{Reserved}};

\draw (0.5, 4.25) node (context) [right, shade, top color=blue!50, bottom color=blue=!10, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Target Address}};

\draw (0.5, 2.25) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Options:\\
Source link-layer address\\
}};
</tikz>

Este mensaje (''cf'' figura ''Formato de los paquetes de anuncio de vecino'') se emite en respuesta a una solicitud, aunque también puede ser emitido de forma espontánea para propagar la información de cambio de dirección física, o del estado de "enrutador". Para el caso de la determinación de la dirección física, es equivalente a la respuesta ARP en IPv4.

* El bit <tt> R </tt> se pone a 1 si el remitente es un enrutador. Este bit se utiliza para permitir la detección de un enrutador que se convierte en un equipo ordinario.
* El bit <tt> S </tt> en 1 indica que este anuncio se emite en respuesta a una solicitud.
* El bit <tt> O </tt> en 1 indica que este anuncio debe borrar las informaciones anteriores que se encuentran almacenadas en la memoria cachés de otros equipos, en especial la tabla que contiene las direcciones físicas.
* El campo dirección del destino contiene, si el bit<tt> S </tt> es 1, el valor del campo dirección del destino de la solicitud a la que está respondiendo este mensaje. Si el bit <tt> S </tt> es 0, este campo contiene la dirección IPv6 local al enlace del equipo emisor.
* La opción dirección física del destino contiene la dirección física del emisor.

== <div id="IR">Indicación de redirección</div> ==

<tikz title="Formato de los paquetes de indicación de redirección">
\clip (0.2, 0) rectangle (11.1,7.1);
%\draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=137}};
\draw (2.9, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code =0 }};
\draw (5.3, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};

\draw (0.5, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=9.6cm]{\tiny{Reserved}};

\draw (0.5, 4.25) node (context) [right, shade, top color=blue!50, bottom color=blue=!10, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Target Address}};

\draw (0.5, 2.25) node (context) [right, shade, top color=blue!50, bottom color=blue=!10, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Destination Address}};

\draw (0.5, 0.5) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=1.5cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Options:\\
Target link-layer address\\
Redirected Header\\
}};
</tikz>

La técnica de redirección es la misma que en IPv4. Un dispositivo sólo conoce los prefijos de las redes a las que está conectado directamente y la dirección de un enrutador por omisión. Si la ruta se puede optimizar, el enrutador por omisión envía un mensaje para indicar que existe un camino más corto. De hecho, como en IPv6 el enrutador por omisión se establece de forma automática, las rutas no necesariamente son las mejores (''cf'' figura ''Enrutamiento por omisión no óptimo'').

Otro caso particular en IPv6 ocurre con los dispositivos que se encuentran en el mismo enlace físico, pero tienen diferentes prefijos. La comunicación entre ellos pasa inicialmente a traves de enrutador por omisión hasta que éste notifica que existe una ruta directa entre ellos.

La figura ''Formato de los paquetes de indicación de redirección'' muestra el formato del mensaje:

* El campo dirección objetivo (''Target address'') contiene la dirección IPv6 del equipo hacia el que los paquetes deben ser enviados.
* El campo dirección destino contiene la dirección IPv6 del dispositivo que está siendo redirigido hacia la dirección objetivo.

Cuando la redirección apunta a un dispositivo situado en el mismo enlace, la dirección objetivo y de destino son las mismas.

Las opciones incluyen la dirección física de un nuevo enrutador y la cabecera del paquete redirigido.

Este mensaje se puede utilizar de la misma forma que en IPv4. Un dispositivo solamente tiene una ruta por omisión para acceder a equipos con un prefijo diferente. En consecuencia, envía su paquete al enrutador por omisión, quien observa que el prefijo destino es accesible a través de la misma subred que el emisor. El enrutador por omisión reenvía el paquete y notifica al emisor que puede contactar directamente a las máquinas que poseen el prefijo del destino.

IPv6 también utiliza este mensaje para optimizar la resolución fuera del enlace para el [[#Caso de redes NBMA |caso de redes NBMA]].

= Configuración automática =
Tradicionalmente, la configuración de una interfaz de red de una máquina se hacía manualmente. Esto suele ser un trabajo lento y propenso a errores. Con IPv6, se automatiza el proceso de configuración y se introducen, al mismo tiempo, mecanismos de funcionamiento inmediato (''plug and play'') a la interfaz de red. La configuración automática significa que un dispositivo obtendrá toda la información necesaria para su conexión a una red local IP sin ninguna intervención humana. En el caso ideal, cualquier usuario desempaca su nuevo equipo, lo conecta a la red local y lo ve funcionar sin tener que introducir la información propia de "especialistas". Ahora vamos a discutir otro aspecto de la configuración automática de IPv6, la auto-configuración de direcciones, que tiene como objetivos:

* La adquisición de una dirección cuando un dispositivo está conectado a una red por primera vez;
* la posibilidad de asignar otros prefijos, o de renumerar un dispositivo.

El proceso de configuración automática de direcciones IPv6 incluye la creación de una dirección local al enlace, la agregación a grupos multicast solicitados, la verificación de la unicidad de la dirección local al enlace y la creación de direcciones unicast global.

La tarea del enrutador es importante en la configuración automática. Indica a la máquina, mediante los bits de la cabecera (ver [[#RA|anuncio de enrutador]]), del mensaje de anuncio de los enrutadores, el método a conservar y eventualmente proporcionar la información necesaria para su configuración. El bit <tt> M </tt> (''configuración de dirección administrada'') puesto a 1 indica que el equipo no debe crear por sí mismo una dirección a partir de su identificador de interfaz y de los prefijos recibidos, sino que debe solicitarla explícitamente ante un servidor de direcciones. El bit O <tt> </tt> (''otra configuración de estado'') indica que el dispositivo debe consultar el servidor para obtener otros parámetros distintos de la dirección. El algoritmo para el proceso de configuración automática de direcciones se desglosa de la siguiente manera:

* La primera fase consiste en crear la dirección local al enlace.
* Una vez que la unicidad de esta dirección es verificada, el dispositivo está listo para comunicarse con otras máquinas en el enlace.
* El dispositivo debe tratar de adquirir un mensaje de anuncio de enrutadores para determinar el método de obtención de la dirección unicast global.
* Si hay un enrutador en el enlace, el dispositivo debe aplicar el método especificado por el mensaje de anuncio de enrutadores, a saber:
** La configuración automática sin estado,
** la configuración automática con estado.
* Si no hay ningún enrutador en el enlace, el dispositivo debe tratar de obtener la dirección unicast global por el método de configuración automática con estado. Si el intento falla, no hay más que hacer. Las comunicaciones sólo podrán hacerse sobre el enlace con la dirección local al enlace, pues el dispositivo no tendrá una dirección con la cobertura necesaria que le permita comunicarse con otras máquinas fuera del enlace.

==Ciclo de vida de una dirección==

Al generalizar en IPv6 el plan de direccionamiento CIDR, los prefijos quedan, en todos los casos, siendo propiedad de los operadores. Ya no pueden otorgarse "a perpetuidad" a los dispositivos. Para facilitar la renumeración de una máquina, la asignación de una dirección a una interfaz es temporal, las direcciones IPv6 no se entregan, sino que se prestan. Se asocia un tiempo de vida a la dirección, que indica el tiempo durante el cual la dirección pertenece a la interfaz. Cuando el tiempo de vida se ha agotada, la dirección deja de ser válida, se suprime de la interfaz y queda potencialmente éste puede prolongarse indefinidamente. La dirección local al enlace tiene un tiempo de vida ilimitado.

<tikz title="Estados sucesivos de una dirección en una interfaz">

\draw [thick, ->] (0,2) -- (9.5,2);

\draw [->] (1,4) node [above=10pt] {\tiny{allocation}}-- (1,2);
\draw (1, 2) node [rectangle, minimum width=1cm, minimum height=1cm, fill, left color=black!10, right color=black!20, draw=black, above right] (tentative) {};
\draw (tentative.south east) node [rectangle, minimum width=3cm, minimum height=1cm, fill, left color=green, right color=green!50, draw=black, above right] (preferred) {};
\draw (preferred.south east) node [rectangle, minimum width=2cm, minimum height=1cm, fill, left color=orange , right color=orange!50!red, draw=black, above right] (deprecated) {};
\draw (deprecated.south east) node [rectangle, minimum width=2cm, minimum height=1cm, fill, color=red, draw=black, above right] (novalid) {};

\draw (tentative.text) node {\tiny{Tentative}};
\draw (preferred.text) node {\tiny{Preferred}};
\draw (deprecated.text) node {\tiny{Deprecated}};
\draw (novalid.text) node {\tiny{Invalid}};

\draw [dotted] (tentative.south west) -- +(0, -1);
\draw [dotted] (preferred.south west) -- +(0, -1);
\draw [dotted] (deprecated.south west) -- +(0, -1);
\draw [dotted] (novalid.south west) -- +(0, -1);

\draw [dashed, <->] ([yshift=-0.5cm]tentative.south west) -- node [above] {\tiny{DAD}} ([yshift=-0.5cm] preferred.south west) ;

\draw [dashed, <->] ([yshift=-0.5cm]preferred.south west) -- node [above] {\tiny{Valid}} ([yshift=-0.5cm] novalid.south west) ;

</tikz>

La renumeración de una interfaz consiste en pasar de una dirección a otra. Durante una renumeración, no es aconsejable cambiar repentinamente de dirección, de lo contrario, todas las comunicaciones TCP que la utilizan como identificador de conexión, se cortarían inmediatamente. Esto conllevaría importantes perturbaciones a nivel de las aplicaciones.

Por ello, para facilitar esta transición se implementó un mecanismo de obsolescencia que invalida gradualmente una dirección. Este mecanismo se sirve de la capacidad de asignación de varias direcciones válidas a una misma interfaz. Para elegir la dirección a utilizar, se le asocia un estado que indica en qué fase de su tiempo de vida se encuentra con respecto a la interfaz. El primero de esos estados se conoce como preferido: no hay ninguna restricción de uso. Poco antes de su invalidación, la dirección pasa a un estado de depreciado. En él se desaconseja el uso de la dirección, pero no está prohibido. Una dirección depreciada ya no debe ser utilizada como dirección fuente de nuevas comunicaciones (como el establecimiento de conexión TCP), pero todavía puede emplearse como dirección fuente de comunicaciones ya establecidas. Los paquetes recibidos a una dirección depreciada seguirán siendo entregados normalmente. El control de la duración de cada estad de una dirección válida se efectúa agregando un tiempo de vida al estado preferido.
La figura '''Estados sucesivos de una dirección en una interfaz''' representa los diferentes estados que toma una dirección cuando se asigna a una interfaz.

== Creación de la dirección local al enlace ==

<tikz title=" Creación de la dirección local al enlace">
\clip (0, 0) rectangle (10,7);
% \draw[help lines] (0,0) grid (10,7 );

\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,3)--(9,3);

\pgfputat{\pgfxy(0.8,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,5)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,3)--(1.5,5);
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (8,3)--(8,5);

\draw (1.5,4.5) node {\small{FE80::IID1}};
\draw (1.5,4) node {\small{$\alpha$::IID1/64}};

\draw (8, 4.5) node {\small{FE80::IID2}};

</tikz>

Durante la inicialización de la interfaz, el dispositivo construye un identificador de interfaz que debe ser único en el enlace. Este identificador se utiliza la dirección de [[ Identificador_de_interfaz#EUI-64 | EUI-64]]. El principio básico para crear la direcciónIPv6 consiste en unir un prefijo con el identificador. La dirección local al enlace se crea tomando el prefijo de Enlace_local (<tt>FE80::/64</tt>). La dirección creada de esa manera, todavía no puede ser utilizada; tiene un estado temporal pues el dispositivo debe comprobar la exclusividad de esta dirección en el enlace mediante el procedimiento de detección de direcciones duplicadas. Si se encuentra que la dirección local al enlace no es única, se suspende la autoconfiguración y será necesario proceder a una configuración manual.

Una vez que se ha asegurado la unicidad de la dirección local al enlace, ésta se considera una dirección válida para la interfaz, con lo que termina la prima fase del proceso de autoconfiguración.

==<div id="DAD"> Detección de una dirección duplicada </div>==

<tikz title="Emisión de un NS en una detección de Dir. duplicada (DAD)">
\clip (0, 0) rectangle (10,7);
% \draw[help lines] (0,0) grid (10,7 );

\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,3)--(9,3);

\pgfputat{\pgfxy(0.8,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,5)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,3)--(1.5,5);
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (8,3)--(8,5);

\draw (7.8, 5) -- (7.8, 3.2);
\draw [<->] (1, 3.2) -- node [above] {\tiny{::/0 -$>$ solicited (FE80:IID2) : NS (who has FE80::IID2?)}}(9, 3.2) ;

</tikz>

Para comprobar la exclusividad de direcciones locales al enlace o de direcciones unicast, los dispositivos deben ejecutar un algoritmo de detección de direcciones duplicadas (DAD) antes poder utilizarlas. El algoritmo usa los mensajes ICMPv6 [[Descubrimiento de vecinos#NS|solicitud de un vecino]] y [[Descubrimiento de vecinos#NA|anuncio de un vecino.]] Si se detecta una dirección que ya está en uso, ésta no podrá ser asignada a la interfaz, la autoconfiguración automática debe suspenderse y será necesario proceder a una configuración manual. Durante la ejecución del algoritmo DAD, la dirección es considerada como "provisional" hasta tener la confirmación de su unicidad. Una dirección provisional se asigna a una interfaz únicamente para recibir los mensajes de solicitud y anuncio de un vecino. Otros mensajes recibidos, son ignorados. El algoritmo DAD consiste en enviar un mensaje de solicitud de un vecino colocando en el campo de dirección objetivo la dirección provisional. Para distinguir el algoritmo DAD del de Descubrimiento de vecinos, el paquete IPv6 que contiene un mensaje de solicitud de un vecino tiene como dirección fuente una dirección no determinada. Así se presentan tres casos:

* Se recibe un mensaje de anucio de un vecino: Significa que la dirección provisional está siendo utilizada como válida por otro dispositivo, por lo que ésta no es única y no puede ser retenida por el dispositivo.
* Se recibe un mensaje de solicitud de un vecino como parte del algoritmo DAD. La dirección provisional también es provisional para otra máquina. En este caso, la dirección provisional no puede ser utilizada por ninguna de ellas.
* No se recibe ningún mensaje durante un segundo (valor por omisión). La dirección provisional es única, por lo que su estado pasa de provisional a válida y se le asigna a la interfaz.

Obsérvese que este algoritmo no proporciona una fiabilidad absoluta, especialmente cuando el enlace está segmentado.

== Autoconfiguración sin estado ==

<tikz title="Emisión de un RS">
\clip (0, 0) rectangle (10,7);
% \draw[help lines] (0,0) grid (10,7 );

\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,3)--(9,3);

\pgfputat{\pgfxy(0.8,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,5)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,3)--(1.5,5);
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (8,3)--(8,5);

\draw (7.8, 5) -- (7.8, 3.2);
\draw [<->] (1, 3.2) -- node [above] {\tiny{FE80::IID2 -$>$ FF02::2 : RS }} (9, 3.2) ;

</tikz>

La configuración automática sin estado (RFC 2462) no requiere de ninguna configuración manual de los dispositivos, una configuración mínima para los enrutadores, y tampoco necesita de servidores adicionales. Se sirve del protocolo ICMPv6 y puede operar aún sin la presencia de enrutadores. En cambio, sí requiere de una subred con soporte a la difusión de paquetes. Este método sólo aplica para los dispositivos; no puede ser utilizada para configurar enrutadores. El principio básico de este mecanismo consiste en que una máquina genera su dirección IPv6 a partir de información local y de la proporcionada por un enrutador. El enrutador proporciona información sobre la subred asociada al enlace; anuncia el prefijo.

{{eSuivi|Tabla de contenido|Incio del capítulo|DHCPv6|DHCPv6}}

Protocolo de Descubrimiento de vecinos

2012-07-04T22:03:40Z

Jincera:

{{eSuivi|Tabla de contenido|Incio del capítulo|DHCPv6|DHCPv6}}

__TOC__

El protocolo de descubrimiento de vecinos (NDP, ''Neighbor Discovery Protocol'') permite a un dispositivo integrarse en el ambiente local, es decir, el enlace sobre el cual se transmiten físicamente los paquetes IPv6. Permite establecer un diálogo con los equipos (estaciones y enrutadores) conectados sobre el mismo medio. No se pretende que un dispositivo conozca con exactitud la lista de todos los demás dispositivos conectados al enlace, sino de proveer un mecanismo para dialogar con quien necesite hacerlo.

El protocolo utiliza cinco tipos de mensajes ICMPv6 (ver Valores de los campos de tipo y código de ICMPv6). El campo número de saltos de la cabecera IPv6 contiene el valor 255. Este valor parece demasiado grande para datagramas que no debieran ser enrutados fuera del enlace físico. En realidad, si un equipo recibe un datagrama con un valor menor, significa que la información proviene de otra red y que ya ha atravesado al menos un enrutador. Por ello, los datagramas que tienen un valor diferente de 255 deben ser ignorados por el receptor.

{{Tableau eICMPv6}}

El protocolo realiza varias funciones:

* Resolución de direcciones. El principio es muy similar al del protocolo ARP de IPv4. La principal diferencia consiste en el uso de mensajes ICMPv6 estándar en lugar de definir otro protocolo de capa 3. Con esto se consigue una mayor flexibilidad de uso, especialmente en las redes que no soportan la difusión de mensajes. Al igual que en IPv4, el protocolo se encarga de construir tablas de correspondencia entre las direcciones IPv6 y las físicas.
* <div vecinos id="NUD"> Detección de inaccesibilidad de vecinos (NUD, ''Neighbor Unreachability Detection''). Esta función, que no existe en IPv4, permite eliminar de las tablas de configuración de un equipo, los vecinos que se han vuelto inaccesibles (por fallas, cambio de domicilio, ...). Si un enrutador deja de estar disponible, la tabla de enrutamiento puede ser modificada para considerar otra ruta. </div>
* Configuración. La configuración automática de los dispositivos es uno de los principales atractivos de IPv6. Se implementan varias funcionalidades del protocolo de descubrimiento de vecinos:
**Descubrimiento de enrutadores. Este protocolo permite que los dispositivos identifiquen a los enrutadores que se encuentran en su enlace físico. En IPv4, esta función la proporciona el protocolo ''ICMP Router Discovery''.
** Descubrimiento de prefijos. El dispositivo conoce el o los prefijos de red de acuerdo a los anuncios realizados por los enrutadores. Agregando su identificador de interfaz, el dispositivo construye su o sus direcciones IPv6. No hay un mecanismo equivalente para las direcciones IPv4 ya que son demasiado cortas para realizar la auto-configuración.
** Detección de direcciones duplicadas. Dado que las direcciones se configuran de forma automática, existen riesgos de error en caso de tener equipos con identificadores repetidos. Este protocolo verifica que ningún otro equipo en el enlace tiene la misma dirección IPv6. Esta función es una evolución del ARP gratuito en IPv4 emitido durante la inicialización de la interfaz.
** Descubrimiento de parámetros. Este protocolo permite que los dispositivos conozcan los distintos parámetros del enlace físico, por ejemplo, el tamaño de MTU, el número máximo de saltos permitido (valor original del campo número de saltos), si la configuración automática con estado (como [[Configuración con estado: DHCPv6|DHCPv6]]) está activa, etc. No existe un equivalente de esta funcionalidad en IPv4.
* Indicación de redirección. Este mensaje se utiliza cuando un enrutador conoce una trayectoria mejor (medida en número de saltos) para alcanzar un destino.
:En IPv4 una indicación de redireccionamiento sólo puede servir para corregir la dirección del enrutador utilizado para acceder a una máquina fuera de la red local. Los dispositivos deben conocer todas las direcciones correspondientes a equipos conectados en su propia red local.
:EnIPv6, la correspondencia entre prefijo y red local es menos rígida. Es de esperar que un dispositivo no conozca todos los prefijos de su red local (si ésta es compartida por varios prefijos), o que un prefijo se comparta entre varios enlaces (lo que corresponde a una generalización del modelo de redes lógicas IP sobre ATM). Bajo algunas configuraciones, la máquina emitirá sus paquetes al enrutador aún si el destinatario se encuentra en el mismo segmento que el emisor. En este caso, el enrutador emitirá un mensaje de redirección para que la continuación del diálogo entre ellos haga de manera directa (véanse los ejemplos [[#IR|Indicación redirección]]).
:En el caso más extremo, podría imaginarse en IPv6 que un dispositivo puede ser configurado para comunicarse únicamente con su enrutador por omisión. ICMPv6 ''redirect'' puede utilizarse entonces, para informar al dispositivo de destinatarios ubicados en el mismo enlace.

En IPv6 se especifican dos métodos de autoconfiguración para las direcciones unicast global:

* Autoconfiguración sin estado (''stateless autoconfiguration'', RFC 2462). Se utiliza cuando no es necesaria una gestión administrativa de las direcciones asignadas dentro de un sitio. Estos mecanismos se describen más adelante en este capítulo.
* Autoconfiguración con estado (''statefull autoconfiguration''). Se utiliza cuando un sitio requiere de un control estricto de la asignación de direcciones (''cf'' [[Configuración con estado: DHCPv6 | DHCPv6]]).

Sin embargo, el uso de DHCPv6 para obtener la dirección se controla mediante el protocolo de descubrimiento de vecinos.

= Datos transmitidos por los mensajes =

La principal motivación detrás del Protocolo de Descubrimiento de vecinos es unificar varios protocolos existentes en IPv4. En particular, la mayor parte de los datos utiliza un formato de opciones común, lo que simplifica la implementación del protocolo. El formato contiene los campos: tipo, longitud (en palabras de 64 bits), y datos. La baja precisión de campo longitud, presentará un desperdicio de espacio, pero permite una alineación de las opciones en palabras de 64 bits, lo que permite un procesamiento optimizado.

{{NB-Opciones}}

== <div id="física">Dirección física de la fuente/destino</div> ==

<tikz title="Formato de la opción dirección física fuente/destino">
\clip (0.2, 5.7) rectangle (11.1,6.7);
% \draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=1/2}};
\draw (2.9, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{lenght }};
\draw (5.3, 6) node (addr) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Link Layer Address}};

\draw [draw=white, thick] (addr.north east) -- (addr.south east);
\draw [draw=white, thick] (addr.north east) -- +(-2, 0);
\draw [draw=white, thick] (addr.south east) -- +(-2, 0);

\draw [dashed] (addr.north east) -- (addr.south east);
\draw [dashed] (addr.north east) -- +(-2, 0);
\draw [dashed] (addr.south east) -- +(-2, 0);
</tikz>

La figura ''Formato de la opción dirección física fuente/destino'' presenta estas opciones. El tipo 1 designa la dirección física de la fuente y el tipo 2 la dirección del destino.

El campo ''length'' es el tamaño en palabras de 64 bits de la opción. Por lo tanto, para el caso de una dirección MAC con longitud de 6 octetos, contiene el valor 1.

El RFC 2464 define el formato para las direcciones MAC-48 utilizadas en las redes Ethernet y Wi-Fi. El RFC 4944 define el formato para las direcciones MAC-16 y MAC-64 utilizadas en las redes de sensores bajo la norma IEEE 802.15.4.

== <div id="información">Información sobre el prefijo</div> ==

<tikz title="Formato de la opción información sobre el prefijo">
\clip (0.2, 2) rectangle (11.1, 7);
% \draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=3}};
\draw (2.9, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{length =4 }};
\draw (5.3, 6) node (addr) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm] {\tiny{Prefix Length}};
\draw (7.7, 6) node (bitL) [right, shade, top color=blue!15, bottom color=blue!5,, draw, minimum height=0.5cm, minimum width=.3cm]{}; \draw (bitL.text) node {\tiny{L}};
\draw (8, 6) node (bitA) [right, shade, top color=blue!15, bottom color=blue!5,, draw, minimum height=0.5cm, minimum width=.3cm]{};\draw (bitA.text) node {\tiny{A}};
\draw (8.3, 6) node (bitR) [right, shade, top color=blue!15, bottom color=blue!5,, draw, minimum height=0.5cm, minimum width=.3cm]{};\draw (bitR.text) node {\tiny{R}};
\draw (8.6, 6) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=1.5cm] {\tiny{Reserved}};

\draw (0.5, 5.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Valid Lifetime}};

\draw (0.5, 5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Prefered Lifetime}};

\draw (0.5, 4.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Reserved}};

\draw (0.5, 4) node (addr1) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{}};
\draw (0.5, 3.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{}};
\draw (0.5, 3) node (addr3) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Prefix}};
\draw (0.5, 2.5) node (addr4) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{}};

\draw [color=blue!10, very thick] (addr1.south east) -- (addr1.south west);
\draw [color=blue!10, very thick] (addr2.south east) -- (addr2.south west);
\draw [color=blue!10, very thick] (addr3.south east) -- (addr3.south west);
</tikz>

Esta opción contiene las informaciones sobre el prefijo para permitir una configuración automática de los dispositivos. El campo tipo tiene el valor 3 y el de longitud, 4. La figura ''Formato de la opción información sobre el prefijo'' muestra el formato de esta opción:

* El campo ''Prefix lenght'' indica cuántos bits son significativos para el prefijo anunciado en un campo siguiente.
* El bit <tt>L</tt> indica, cuando vale 1, que el prefijo permite indicar que todos los demás dispositivos que comparten el mismo prefijo, están en el mismo enlace, por lo que el emisor puede contactarlos directamente. En caso contrario, el dispositivo envía el paquete hacia el enrutador. Si éste último sabe que el emisor puede contactar directamente al destinatario, emitirá un mensaje ICMPv6 de indicación de redirección.
* El bit <tt>A</tt> indica, cuando vale 1, que el prefijo anunciado puede utilizarse para formar la dirección del dispositivo.
* El bit <tt>R</tt>, indica, cuando vale 1, que el campo prefijo contiene la dirección global de un enrutador ''agente base''. Los bits de mayor peso aún pueden utilizarse para formar un prefijo.
* El campo duración de validez indica, en segundos, la duración durante la cual el prefijo es válido.
* El campo duración preferente indica la duración, en segundos, durante la cual una dirección formada con el protocolo de configuración sin estado se mantiene ''preferente'' (''cf'' [[Planes de direccionamiento|Tiempo de vida de las direcciones]]).

Para estos dos campos, un valor de <tt>0xffffffff</tt> representa una duración infinita. Estos campos pueden servir durante la fase de transición de un proveedor de acceso a otro; es decir, de un prefijo a otro.
* El campo reservado permite alinear el prefijo a una frontera de palabra de 64 bits.
* El campo prefijo contiene el valor de prefijo anunciado sobre el enlace. Para mantener una alineación de 64 bits para el resto de datos del paquete, este campo tiene una longitud fija de 128 bits.

== <div id="redirigida">Cabecera de redirección </div> ==

<tikz title="Formato de la opción cabecera de redirección">
\clip (0.2, 3.1) rectangle (11.1, 7);
% \draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=5}};
\draw (2.9, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{length =1 }};
\draw (5.3, 6) node (addr) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Reserved}};

\draw (0.5, 5.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Reserved}};

\draw (0.5, 4.25) node (context) [right, shade, top color=purple!50, bottom color=purple!10, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{IPv6 Header and Data}};
</tikz>

Esta opción es utilizada por el mensaje de indicación de redirección. Permite encapsular los primeros octetos del paquete IPv6 que provocó la emisión de este mensaje, como ocurre con los mensajes de error de ICMPv6.

El campo tipo tiene el valor 4. El tamaño de esta opción debe evitar que el paquete IPv6 rebase los 1280 octetos (''cf'' figura ''Formato de la opción cabecera de redirección''). Sin embargo, el paquete debe contener la mayor cantidad de información posible.

== <div id="MTU">MTU</div> ==

<tikz title="Formato de la opción MTU">

\clip (0.2, 5.1) rectangle (11.1, 7);
% \draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=5}};
\draw (2.9, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{lenght =1 }};
\draw (5.3, 6) node (addr) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Reserved}};

\draw (0.5, 5.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{MTU}};
</tikz>

Esta opción permite notificar a los dispositivos el tamaño máximo de datos que pueden ser transmitidos sobre el enlace. La figura ''Formato de la opción MTU'' muestra su estructura. No es necesario difundir esta información si el dispositivo utiliza siempre el tamaño máximo permitido. Por ejemplo, sobre las redes Ethernet, los dispositivos utilizarán el valor 1,500. En cambio, en las redes Token Ring o FDDI, con frecuencia es necesario especificar si los equipos pueden utilizar la longitud máxima o un tamaño inferior para permitir el uso de puentes en la red.

En esta opción, el campo tipo tiene un valor de 5 y el de longitud, de 1.

=Mensajes estándar de Descubrimiento de vecinos =

Además de las cinco opciones básicas descritas en la tabla ''Utilización de las opciones en los mensajes de descubrimiento de vecinos'', existen otras específicas para la movilidad y para las redes NBMA (''Non Broadcast Multiple Access'').

{|
|+ Utilización de las opciones en los mensajes de descubrimiento de vecinos
| width = 150 | || width = 100 |[[#RS|Solicitud de]] || width = 100 |[[#RA|Anuncio de]] || width = 100 |[[#NS|Solicitud de]] ||width = 100 | [[#NA|Anuncio de]] ||width = 100 |[[#IR|Indicación de]]
|-
| || [[#RS|enrutador]] || [[#RA|enrutador]] || [[#NS|un vecino]] || [[#NA| un vecino]] || [[#IR|redirección]]
|-style="background:silver"
|[[#física |Dirección física de la fuente]] || presente || presente || presente || ||
|-
|[[# física | Dirección física del destino]] || || || || presente || presente
|-style="background:silver"
|[[#información|Información sobre el prefijo]] || || ≥ 1 || || ||
|-
|[[#redirigida |Cabecera de redirección]] || || || || || presente
|-style="background:silver"
| [[#MTU |MTU]] || || posible || || ||
|}

Las distintas funcionalidades de descubrimiento de vecinos utilizan cinco mensajes: dos para el diálogo entre un dispositivo y un enrutador, dos para el diálogo entre vecinos, y uno para la redirección. Cada uno de estos mensajes puede incluir opciones adicionales.

== <div id="RS">Solicitud de enrutador</div> ==

<tikz title="Formato de los paquetes de solicitud de enrutador">
\clip (0.2, 3.5) rectangle (11.1,7.1);
%\draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=133}};
\draw (2.9, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code =0 }};
\draw (5.3, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};
\draw (0.5, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Reserved}};

\draw (0.5, 4.25) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Options:\\
- Source link-layer address
}};
</tikz>

El mensaje de solicitud de enrutador (''cf'' figura Formato de los paquetes de solicitud de enrutador) es emitido al iniciar un dispositivo para recibir más rápidamente la información del enrutador. Este mensaje se envía a la dirección IPv6 multicast reservada a los enrutadores en el mismo enlace <tt>FF02::2</tt>. Si el dispositivo aún no conoce su dirección fuente, se utiliza la dirección no especificada.

El campo opción normalmente contiene la dirección física del dispositivo.

== <div id="RA">Anuncio de enrutador</div> ==

<tikz title="Formato de los paquetes de anuncio de enrutador">
\clip (0.2, 1.5) rectangle (11.1,7.1);
%\draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=134}};
\draw (2.9, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code =0 }};
\draw (5.3, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};

\draw (0.5, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Cur. Hop Lim.}};
\draw (2.9, 5.5) node (bitM) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{}; \draw (bitM.text) node {\tiny{M}};
\draw (3.2, 5.5) node (bitO) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{};\draw (bitO.text) node {\tiny{O}};
\draw (3.5, 5.5) node (bitH) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{};\draw (bitH.text) node {\tiny{H}};
\draw (3.8, 5.5) node (res) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=1.5cm]{\tiny{reserved}};
\draw (5.3, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Router Lifetime}};

\draw (0.5, 5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=9.6cm]{\tiny{Reachable Time}};
\draw (0.5, 4.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=9.6cm]{\tiny{Retrans Time}};

\draw (0.5, 3.25) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Options:\\
Source link-layer address\\
MTU\\
Prefix Information (may be repeated)\\
}};
</tikz>

Este mensaje (''cf'' figura ''Formato de los paquetes de anuncio de enrutador'') es emitido periódicamente por los enrutadores, o bien, en respuesta a un mensaje de solicitud de enrutador generado por un dispositivo. El campo dirección fuente contiene la dirección de enlace local del enrutador, mientras que el campo dirección destino contiene la dirección del dispositivo que generó la solicitud, o la dirección de todas las estaciones (<tt>ff02::01</tt>).

Cuando el campo de máximo número de saltos tiene un valor distinto de cero, muestra el valor que podría colocarse en el campo de número de saltos de los paquetes emitidos. El bit <tt>M</tt> indica que una dirección del dispositivo debe ser obtenida mediante un protocolo de configuración (''cf'' [[Configuración con estado:DHCPv6]]). El bit <tt>O</tt> también indica la presencia de un servicio de configuración para obtener información adicional a la dirección. Si no es posible obtener la dirección mediante un servidor, el dispositivo procede a realizar una configuración sin estado, concatenando su identificador de interfaz a los prefijos que conoce. El bit <tt>H</tt> indica que el enrutador puede ser utilizado como agente base por un nodo móvil (''cf'' [[Desplazamientos_de_móviles#Anuncio_del_agente_base |Anuncio del agente base]]).

El campo tiempo de vida del enrutador indica el período (en segundos) durante el cual el equipo que emite el anuncio realizará funciones de enrutador por omisión. El valor máximo corresponde a 18 horas 12 minutos, pero como este mensaje se emite periódicamente, en la práctica no existe un límite para el tiempo de vida de un enrutador. Un valor de <tt>0</tt> indica que el dispositivo no cumple con las funciones de enrutador por omisión. Este tiempo de vida no se aplica a las opciones transportadas por este mensaje.

El campo duración de accesibilidad indica el período (en milisegundos) durante el cual una información almacenada en la memoria caché de la máquina (por ejemplo, la tabla de correspondencia entre las direcciones IPv6 y las físicas) puede ser considerada como válida. Al vencimiento de este tiempo, se emite un mensaje de detección de inaccesibilidad para verificar la pertinencia de la información almacenada.

El campo temporización de retransmisión muestra el período (en milisegundos) entre dos emisiones no solicitadas de este mensaje. Permite que los demás equipos puedan detectar la inaccesibilidad de un enrutador.

Este mensaje puede transportar las siguientes opciones:

* dirección física de la fuente,
* MTU,
* información sobre el prefijo (uno o varios).

== <div Id="NS"> Solicitud de un vecino </div> ==

<tikz title="Formato de los paquetes de solicitud de un vecino">

\clip (0.2, 1.5) rectangle (11.1,7.1);
%\draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=135}};
\draw (2.9, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code =0 }};
\draw (5.3, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};

\draw (0.5, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=9.6cm]{\tiny{Reserved}};

\draw (0.5, 4.25) node (context) [right, shade, top color=blue!50, bottom color=blue=!10, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Target Address}};

\draw (0.5, 2.25) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Options:\\
Source link-layer address\\
}};
</tikz>

Este mensaje (''cf'' figura ''Formato de los paquetes de solicitud de un vecino'') permite obtener información a partir de un equipo vecino, es decir, localizado en el mismo enlace físico (o conectado a través de puentes). El mensaje puede ser emitido explícitamente a él, o enviado con una dirección de difusión. En el caso de determinación de la dirección física, éste corresponde a la solicitud de ARP en IPv4.

El campo dirección fuente del paquete IPv6 contiene ya sea la dirección local al enlace, una dirección global o la dirección no especificada. El campo destino puede contener la dirección de difusión múltiple solicitada correspondiente a la dirección buscada (''cf'' [[Direccionamiento_multicast#Identificador_de_grupo|Identificador de grupo]]) o la dirección del dispositivo (en el caso de una detección de inaccesibilidad de vecinos, ''NUD'').

El campo dirección del destino contiene la dirección IPv6 del equipo buscado. El campo opción generalmente contiene la dirección física de la fuente.

== <div Id="NA"> Anuncio de vecino</div> ==

<tikz title="Formato de los paquetes de anuncio de vecino">

\clip (0.2, 1.5) rectangle (11.1,7.1);
%\draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=136}};
\draw (2.9, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code =0 }};
\draw (5.3, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};

\draw (0.5, 5.5) node (bitR) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{}; \draw (bitR.text) node {\tiny{R}};
\draw (0.8, 5.5) node (bitS) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{}; \draw (bitS.text) node {\tiny{S}};
\draw (1.1, 5.5) node (bitO) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{}; \draw (bitO.text) node {\tiny{O}};
\draw (1.4, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=8.7cm]{\tiny{Reserved}};

\draw (0.5, 4.25) node (context) [right, shade, top color=blue!50, bottom color=blue=!10, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Target Address}};

\draw (0.5, 2.25) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Options:\\
Source link-layer address\\
}};
</tikz>

Este mensaje (''cf'' figura ''Formato de los paquetes de anuncio de vecino'') se emite en respuesta a una solicitud, aunque también puede ser emitido de forma espontánea para propagar la información de cambio de dirección física, o del estado de "enrutador". Para el caso de la determinación de la dirección física, es equivalente a la respuesta ARP en IPv4.

* El bit <tt> R </tt> se pone a 1 si el remitente es un enrutador. Este bit se utiliza para permitir la detección de un enrutador que se convierte en un equipo ordinario.
* El bit <tt> S </tt> en 1 indica que este anuncio se emite en respuesta a una solicitud.
* El bit <tt> O </tt> en 1 indica que este anuncio debe borrar las informaciones anteriores que se encuentran almacenadas en la memoria cachés de otros equipos, en especial la tabla que contiene las direcciones físicas.
* El campo dirección del destino contiene, si el bit<tt> S </tt> es 1, el valor del campo dirección del destino de la solicitud a la que está respondiendo este mensaje. Si el bit <tt> S </tt> es 0, este campo contiene la dirección IPv6 local al enlace del equipo emisor.
* La opción dirección física del destino contiene la dirección física del emisor.

== <div id="IR">Indicación de redirección</div> ==

<tikz title="Formato de los paquetes de indicación de redirección">
\clip (0.2, 0) rectangle (11.1,7.1);
%\draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=137}};
\draw (2.9, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code =0 }};
\draw (5.3, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};

\draw (0.5, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=9.6cm]{\tiny{Reserved}};

\draw (0.5, 4.25) node (context) [right, shade, top color=blue!50, bottom color=blue=!10, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Target Address}};

\draw (0.5, 2.25) node (context) [right, shade, top color=blue!50, bottom color=blue=!10, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Destination Address}};

\draw (0.5, 0.5) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=1.5cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Options:\\
Target link-layer address\\
Redirected Header\\
}};
</tikz>

La técnica de redirección es la misma que en IPv4. Un dispositivo sólo conoce los prefijos de las redes a las que está conectado directamente y la dirección de un enrutador por omisión. Si la ruta se puede optimizar, el enrutador por omisión envía un mensaje para indicar que existe un camino más corto. De hecho, como en IPv6 el enrutador por omisión se establece de forma automática, las rutas no necesariamente son las mejores (''cf'' figura ''Enrutamiento por omisión no óptimo'').

Otro caso particular en IPv6 ocurre con los dispositivos que se encuentran en el mismo enlace físico, pero tienen diferentes prefijos. La comunicación entre ellos pasa inicialmente a traves de enrutador por omisión hasta que éste notifica que existe una ruta directa entre ellos.

La figura ''Formato de los paquetes de indicación de redirección'' muestra el formato del mensaje:

* El campo dirección objetivo (''Target address'') contiene la dirección IPv6 del equipo hacia el que los paquetes deben ser enviados.
* El campo dirección destino contiene la dirección IPv6 del dispositivo que está siendo redirigido hacia la dirección objetivo.

Cuando la redirección apunta a un dispositivo situado en el mismo enlace, la dirección objetivo y de destino son las mismas.

Las opciones incluyen la dirección física de un nuevo enrutador y la cabecera del paquete redirigido.

Este mensaje se puede utilizar de la misma forma que en IPv4. Un dispositivo solamente tiene una ruta por omisión para acceder a equipos con un prefijo diferente. En consecuencia, envía su paquete al enrutador por omisión, quien observa que el prefijo destino es accesible a través de la misma subred que el emisor. El enrutador por omisión reenvía el paquete y notifica al emisor que puede contactar directamente a las máquinas que poseen el prefijo del destino.

IPv6 también utiliza este mensaje para optimizar la resolución fuera del enlace para el [[#Caso de redes NBMA |caso de redes NBMA]].

= Configuración automática =
Tradicionalmente, la configuración de una interfaz de red de una máquina se hacía manualmente. Esto suele ser un trabajo lento y propenso a errores. Con IPv6, se automatiza el proceso de configuración y se introducen, al mismo tiempo, mecanismos de funcionamiento inmediato (''plug and play'') a la interfaz de red. La configuración automática significa que un dispositivo obtendrá toda la información necesaria para su conexión a una red local IP sin ninguna intervención humana. En el caso ideal, cualquier usuario desempaca su nuevo equipo, lo conecta a la red local y lo ve funcionar sin tener que introducir la información propia de "especialistas". Ahora vamos a discutir otro aspecto de la configuración automática de IPv6, la auto-configuración de direcciones, que tiene como objetivos:

* La adquisición de una dirección cuando un dispositivo está conectado a una red por primera vez;
* la posibilidad de asignar otros prefijos, o de renumerar un dispositivo.

El proceso de configuración automática de direcciones IPv6 incluye la creación de una dirección local al enlace, la agregación a grupos multicast solicitados, la verificación de la unicidad de la dirección local al enlace y la creación de direcciones unicast global.

La tarea del enrutador es importante en la configuración automática. Indica a la máquina, mediante los bits de la cabecera (ver [[#RA|anuncio de enrutador]]), del mensaje de anuncio de los enrutadores, el método a conservar y eventualmente proporcionar la información necesaria para su configuración. El bit <tt> M </tt> (''configuración de dirección administrada'') puesto a 1 indica que el equipo no debe crear por sí mismo una dirección a partir de su identificador de interfaz y de los prefijos recibidos, sino que debe solicitarla explícitamente ante un servidor de direcciones. El bit O <tt> </tt> (''otra configuración de estado'') indica que el dispositivo debe consultar el servidor para obtener otros parámetros distintos de la dirección. El algoritmo para el proceso de configuración automática de direcciones se desglosa de la siguiente manera:

* La primera fase consiste en crear la dirección local al enlace.
* Una vez que la unicidad de esta dirección es verificada, el dispositivo está listo para comunicarse con otras máquinas en el enlace.
* El dispositivo debe tratar de adquirir un mensaje de anuncio de enrutadores para determinar el método de obtención de la dirección unicast global.
* Si hay un enrutador en el enlace, el dispositivo debe aplicar el método especificado por el mensaje de anuncio de enrutadores, a saber:
** La configuración automática sin estado,
** la configuración automática con estado.
* Si no hay ningún enrutador en el enlace, el dispositivo debe tratar de obtener la dirección unicast global por el método de configuración automática con estado. Si el intento falla, no hay más que hacer. Las comunicaciones sólo podrán hacerse sobre el enlace con la dirección local al enlace, pues el dispositivo no tendrá una dirección con la cobertura necesaria que le permita comunicarse con otras máquinas fuera del enlace.

==Ciclo de vida de una dirección==

Al generalizar en IPv6 el plan de direccionamiento CIDR, los prefijos quedan, en todos los casos, siendo propiedad de los operadores. Ya no pueden otorgarse "a perpetuidad" a los dispositivos. Para facilitar la renumeración de una máquina, la asignación de una dirección a una interfaz es temporal, las direcciones IPv6 no se entregan, sino que se prestan. Se asocia un tiempo de vida a la dirección, que indica el tiempo durante el cual la dirección pertenece a la interfaz. Cuando el tiempo de vida se ha agotada, la dirección deja de ser válida, se suprime de la interfaz y queda potencialmente éste puede prolongarse indefinidamente. La dirección local al enlace tiene un tiempo de vida ilimitado.

<tikz title="Estados sucesivos de una dirección en una interfaz">

\draw [thick, ->] (0,2) -- (9.5,2);

\draw [->] (1,4) node [above=10pt] {\tiny{allocation}}-- (1,2);
\draw (1, 2) node [rectangle, minimum width=1cm, minimum height=1cm, fill, left color=black!10, right color=black!20, draw=black, above right] (tentative) {};
\draw (tentative.south east) node [rectangle, minimum width=3cm, minimum height=1cm, fill, left color=green, right color=green!50, draw=black, above right] (preferred) {};
\draw (preferred.south east) node [rectangle, minimum width=2cm, minimum height=1cm, fill, left color=orange , right color=orange!50!red, draw=black, above right] (deprecated) {};
\draw (deprecated.south east) node [rectangle, minimum width=2cm, minimum height=1cm, fill, color=red, draw=black, above right] (novalid) {};

\draw (tentative.text) node {\tiny{Tentative}};
\draw (preferred.text) node {\tiny{Preferred}};
\draw (deprecated.text) node {\tiny{Deprecated}};
\draw (novalid.text) node {\tiny{Invalid}};

\draw [dotted] (tentative.south west) -- +(0, -1);
\draw [dotted] (preferred.south west) -- +(0, -1);
\draw [dotted] (deprecated.south west) -- +(0, -1);
\draw [dotted] (novalid.south west) -- +(0, -1);

\draw [dashed, <->] ([yshift=-0.5cm]tentative.south west) -- node [above] {\tiny{DAD}} ([yshift=-0.5cm] preferred.south west) ;

\draw [dashed, <->] ([yshift=-0.5cm]preferred.south west) -- node [above] {\tiny{Valid}} ([yshift=-0.5cm] novalid.south west) ;

</tikz>

La renumeración de una interfaz consiste en pasar de una dirección a otra. Durante una renumeración, no es aconsejable cambiar repentinamente de dirección, de lo contrario, todas las comunicaciones TCP que la utilizan como identificador de conexión, se cortarían inmediatamente. Esto conllevaría importantes perturbaciones a nivel de las aplicaciones.

Por ello, para facilitar esta transición se implementó un mecanismo de obsolescencia que invalida gradualmente una dirección. Este mecanismo se sirve de la capacidad de asignación de varias direcciones válidas a una misma interfaz. Para elegir la dirección a utilizar, se le asocia un estado que indica en qué fase de su tiempo de vida se encuentra con respecto a la interfaz. El primero de esos estados se conoce como preferido: no hay ninguna restricción de uso. Poco antes de su invalidación, la dirección pasa a un estado de depreciado. En él se desaconseja el uso de la dirección, pero no está prohibido. Una dirección depreciada ya no debe ser utilizada como dirección fuente de nuevas comunicaciones (como el establecimiento de conexión TCP), pero todavía puede emplearse como dirección fuente de comunicaciones ya establecidas. Los paquetes recibidos a una dirección depreciada seguirán siendo entregados normalmente. El control de la duración de cada estad de una dirección válida se efectúa agregando un tiempo de vida al estado preferido.
La figura '''Estados sucesivos de una dirección en una interfaz''' representa los diferentes estados que toma una dirección cuando se asigna a una interfaz.

== Creación de la dirección local al enlace ==

<tikz title=" Creación de la dirección local al enlace">
\clip (0, 0) rectangle (10,7);
% \draw[help lines] (0,0) grid (10,7 );

\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,3)--(9,3);

\pgfputat{\pgfxy(0.8,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,5)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,3)--(1.5,5);
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (8,3)--(8,5);

\draw (1.5,4.5) node {\small{FE80::IID1}};
\draw (1.5,4) node {\small{$\alpha$::IID1/64}};

\draw (8, 4.5) node {\small{FE80::IID2}};

</tikz>

Durante la inicialización de la interfaz, el dispositivo construye un identificador de interfaz que debe ser único en el enlace. Este identificador se utiliza la dirección de [[ Identificador_de_interfaz#EUI-64 | EUI-64]]. El principio básico para crear la direcciónIPv6 consiste en unir un prefijo con el identificador. La dirección local al enlace se crea tomando el prefijo de Enlace_local (<tt>FE80::/64</tt>). La dirección creada de esa manera, todavía no puede ser utilizada; tiene un estado temporal pues el dispositivo debe comprobar la exclusividad de esta dirección en el enlace mediante el procedimiento de detección de direcciones duplicadas. Si se encuentra que la dirección local al enlace no es única, se suspende la autoconfiguración y será necesario proceder a una configuración manual.

Una vez que se ha asegurado la unicidad de la dirección local al enlace, ésta se considera una dirección válida para la interfaz, con lo que termina la prima fase del proceso de autoconfiguración.

==<div id="DAD"> Detección de una dirección duplicada </div>==

<tikz title="Emisión de un NS en una detección de Dir. duplicada (DAD)">
\clip (0, 0) rectangle (10,7);
% \draw[help lines] (0,0) grid (10,7 );

\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,3)--(9,3);

\pgfputat{\pgfxy(0.8,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,5)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,3)--(1.5,5);
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (8,3)--(8,5);

\draw (7.8, 5) -- (7.8, 3.2);
\draw [<->] (1, 3.2) -- node [above] {\tiny{::/0 -$>$ solicited (FE80:IID2) : NS (who has FE80::IID2?)}}(9, 3.2) ;

</tikz>

Para comprobar la exclusividad de direcciones locales al enlace o de direcciones unicast, los dispositivos deben ejecutar un algoritmo de detección de direcciones duplicadas (DAD) antes poder utilizarlas. El algoritmo usa los mensajes ICMPv6 [[Descubrimiento de vecinos#NS|solicitud de un vecino]] y [[Descubrimiento de vecinos#NA|anuncio de un vecino.]] Si se detecta una dirección que ya está en uso, ésta no podrá ser asignada a la interfaz, la autoconfiguración automática debe suspenderse y será necesario proceder a una configuración manual. Durante la ejecución del algoritmo DAD, la dirección es considerada como "provisional" hasta tener la confirmación de su unicidad. Una dirección provisional se asigna a una interfaz únicamente para recibir los mensajes de solicitud y anuncio de un vecino. Otros mensajes recibidos, son ignorados. El algoritmo DAD consiste en enviar un mensaje de solicitud de un vecino colocando en el campo de dirección objetivo la dirección provisional. Para distinguir el algoritmo DAD del de Descubrimiento de vecinos, el paquete IPv6 que contiene un mensaje de solicitud de un vecino tiene como dirección fuente una dirección no determinada. Así se presentan tres casos:

* Se recibe un mensaje de anucio de un vecino: Significa que la dirección provisional está siendo utilizada como válida por otro dispositivo, por lo que ésta no es única y no puede ser retenida por el dispositivo.
* Se recibe un mensaje de solicitud de un vecino como parte del algoritmo DAD. La dirección provisional también es provisional para otra máquina. En este caso, la dirección provisional no puede ser utilizada por ninguna de ellas.
* No se recibe ningún mensaje durante un segundo (valor por omisión). La dirección provisional es única, por lo que su estado pasa de provisional a válida y se le asigna a la interfaz.

Obsérvese que este algoritmo no proporciona una fiabilidad absoluta, especialmente cuando el enlace está segmentado.

== Autoconfiguración sin estado ==

<tikz title="Emisión de un RS">
\clip (0, 0) rectangle (10,7);
% \draw[help lines] (0,0) grid (10,7 );

\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,3)--(9,3);

\pgfputat{\pgfxy(0.8,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,5)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,3)--(1.5,5);
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (8,3)--(8,5);

\draw (7.8, 5) -- (7.8, 3.2);
\draw [<->] (1, 3.2) -- node [above] {\tiny{FE80::IID2 -$>$ FF02::2 : RS }} (9, 3.2) ;

</tikz>

La configuración automática sin estado (RFC 2462) no requiere de ninguna configuración manual de los dispositivos, una configuración mínima para los enrutadores, y tampoco necesita de servidores adicionales. Se sirve del protocolo ICMPv6 y puede operar aún sin la presencia de enrutadores. En cambio, sí requiere de una subred con soporte a la difusión de paquetes. Este método sólo aplica para los dispositivos; no puede ser utilizada para configurar enrutadores. El principio básico de este mecanismo consiste en que una máquina genera su dirección IPv6 a partir de información local y de la proporcionada por un enrutador. El enrutador proporciona información sobre la subred asociada al enlace; anuncia el prefijo.

{{eSuivi|Tabla de contenido|Incio del capítulo|DHCPv6|DHCPv6}}

Protocolo de Descubrimiento de vecinos

2012-07-03T17:31:00Z

Jincera:

Protocolo de Descubrimiento de vecinos

2012-07-03T17:21:16Z

Jincera:

Direccionamiento-Fundamentos

2012-07-03T17:02:23Z

Jincera: /* Direccionamiento local : Direcciones locales al enlace */

{{esuivi |Introduccion|Introducción|Direccionamiento-Implementaciones|Implementaciones}}

El formato y la representación de las direcciones son las modificaciones más notables para el usuario experimentado y para el ingeniero de red en esta nueva versión del protocolo: las direcciones en IPv6 también son fijas pero pasan de 32 a 128 bits. Aunque los principios son muy similares a los utilizados en IPv4, en una primera instancia el nuevo direccionamiento parece mucho más complejo. Resulta interesante conocer los principios y las reglas de atribución antes de entrar en los detalles del protocolo.

El presente capítulo muestra los distintos tipos de direcciones. Explica en detalle el plan de direccionamiento agregado que ha sido elegido para construir la Internet IPv6. También describe la forma de constituir una dirección IPv6.

= Aspectos fundamentales del direccionamiento IPv6=

==<div id="representacion">Representación de direcciones ==

La representación textual de una dirección IPv6 se efectúa dividiendo la palabra de 128 bits en 8 palabras de 16 bits en formato hexadecimal, separadas por el caracter ":". Por ejemplo:

<tt>2001:0DB8:0000:0000:0400:A987:6543:210F</tt>

No es necesario escribir los ceros a la izquierda de un campo:

<tt>2001:DB8:0:0:400:A987:6543:210F</tt>

Además, varios campos nulos consecutivos, pueden abreviarse como "::". Así, la dirección anterior puede escribirse como:

<tt>2001:DB8::400:A987:6543:210F</tt>

Naturalmente, para evitar ambigüedades, la abreviación "::" sólo puede usarse una vez en una dirección. Los casos extremos son la dirección indefinida (utilizada para designar las rutas por omisión), que tiene todos los bits en cero y que se escribe de manera compacta como:

<tt>::</tt>

y la dirección de bucle local (''loopback''), equivalente al prefijo <tt>127/8</tt> en IPv4, en la que todos los bits son cero excepto el último. Ésta se escribe de forma compacta como:

<tt>::1</tt>

La representación de prefijos de red IPv6 es similar a la notación CIDR (RFC 1519) para los prefijos IPv4. Así, un prefijo IPv6 sigue el formato representado por la notación:

dirección-ipv6/longitud-del-prefijo-en-bits

Se permite el uso de formatos abreviados con "::"

<tt>2001:0DB8:7654:3210:0000:0000:0000:0000/64
2001:DB8:7654:3210:0:0:0:0/64
2001:DB8:7654:3210::/64</tt>

Debe tenerse precaución al utilizar esta notación con prefijos que no terminan en un bloque de 16 bits. Por ejemplo, el prefijo <tt>3EDC:BA98:7654:3::/56</tt> equivale en realidad a <tt>3EDC:BA98:7654:0000::/56</tt> pues se escribe <tt>3EDC:BA98:7654:0003::/56</tt>.

Es posible combinar el prefijo de red y el identificador de la interfaz en una sola notacion. Así, esta dirección IPv6
<tt>2001:DB8:7654:3210:945:1321:ABA8:F4E2/64</tt>
indica que el prefijo de red está constituido por los primeros 64 bits.

{{HorsTexte|Aprender a derrochar|Dada su longitud, una buena regla de gestión consiste en relajar las restricciones sobre las longitudes del prefijo. Así, al utilizar múltiplos de 4 cuando sea posible, permite tener un prefijo que cabe en el valor desplegado. En el ejemplo siguiente, como 47 no es múltiplo de 4, <tt>2001:DB0:1234::/47</tt>, representa los prefijos que comienzan por <tt>2001:DB0:1234</tt> y por <tt>2001:DB0:1235</tt>}}

Estas representaciones pueden parecer mucho más complejas que con IPv4, pero en realidad, las direcciones lógicas o concisas se forman a través de reglas precisas. Estas reglas facilitan fuertemente la manipulación y la memorización de direcciones, como se verá más adelante (''cf'' Direccionamiento global).

En algunos casos una dirección (o varias direcciones) IPv4 puede estar contenida en una dirección IPv6. Para destacarlas puede utilizarse la notación clásica de IPv4, es decir cuatro octetos en representación decimal separados por un punto, dentro de una dirección IPv6. De esta forma,

<tt>::128.12.13.14</tt>

representa una dirección IPv6 compuesta por 96 bits en cero, seguidos de los 32 bits de la dirección IPv4 <tt>128.12.13.14</tt>

En ocasiones es necesario manipular las direcciones IPv6 literalmente. El caracter ":" utilizado para separar las palabras, puede crear ambigüedades. Ese es el caso, por ejemplo, con las URL en las que el mismo caracter también se puede utilizar para especificar el número de puerto. Así, la URL:

<tt><nowiki>http://2001:DB8:12::1:8000/</nowiki></tt>

podría representar tanto el puerto 8000 en el dispositivo con dirección IPv6 <tt>2001:DB8:12::1</tt>, como el dispositivo <tt>2001:DB8:12::1:8000</tt> que utiliza el puerto por omisión. Para evitar esta ambigüedad, el RFC 2732 propone delimitar la dirección IPv6 entre corchetes cuadrados "[ ]". Dependiendo del caso, la dirección precedente se escribiría:

<tt><nowiki>http://[2001:DB8:12::1]:8000/</nowiki></tt>

o

<tt><nowiki>http://[2001:DB8:12::1:8000]/</nowiki></tt>

Esta representación puede extenderse a otros dominios, como X-window o al protocolo de señalización para telefonía SIP.

== Tipos de direcciones ==

IPv6 reconoce tres tipos de direcciones: unicast, multicast y anycast. El tipo de dirección define la cardinalidad de la comunicación, es decir, a cuántos destinatarios debe ser entregado el paquete.

El primero de estos tipos, la dirección unicast, identifica de manera única una interfaz. Un paquete enviado a ese tipo de dirección será entregado a la interfaz correspondiente.
Entre las direcciones unicast, se pueden distinguir aquéllas que tienen una cobertura global, es decir, designan sin ambigüedad un destinatario sobre la red Internet, y las que tienen cobertura local (en el enlace o en el sitio). Estas últimas no pueden ser enrutadas sobre Internet. Es decir, un paquete que tenga una dirección destino con cobertura local, será ignorado y eliminado por un enrutador de Internet. La cobertura de una dirección señala el límite de la propiedad de unicidad.

Una dirección tipo multicast (difusión restringida) designa a un grupo de interfaces que pertenecen, en general, a nodos distintos que pueden ubicarse en cualquier parte de Internet. Cuando un paquete tiene una dirección destino multicast, éste se envía por la red a todas las interfaces miembros de ese grupo.

Cabe resaltar que desaparecen las direcciones de difusión (''broadcast'') que existían en IPv4; éstas son remplazadas por direcciones tipo multicast. La dirección de difusión puede ser imitada por una dirección mulitcast constituyendo un grupo que incluya todos los nodos. La ausencia de direcciones de difusión evita los problemas de saturación en las redes locales conmutadas. Por ello, una red IPv6 tiene un mejor desempeño en términos de factor de escala, sobre este tipo de redes.

El último tipo de dirección, anycast, se deriva de la oficialización de propuestas hechas para IPv4 (RFC 1546). Como en el caso multicast, una dirección de tipo anycast designa un grupo de interfaces. La principal diferencia consiste en que cuando un paquete tiene una dirección destino anycast, éste es enviado a alguno de los miembros del grupo, no a todos. El receptor del paquete podría ser, por ejemplo, el más cercano de acuerdo a la métrica de usada por los protocolos de enrutamiento. Este tipo de dirección es principalmente experimental. Consulte [[eAnycast|Direcciones anycast]] para más información.

Algunos tipos de direcciones se identifican por su prefijo (RFC 3513). La tabla siguiente muestra la lista de estos prefijos (fuente: http://www.iana.org/assignments/ipv6-address-space). El bloque "reservado" del prefijo <tt>0::/8</tt> es utilizado por las direcciones llamadas ''especiales'' (dirección indeterminada, de bucle (''loop''), mapeada, compatible). Se observa que más del 70% del espacio disponible no se ha asignado, lo que permite contar con una gran flexibilidad para el futuro.

{|
!Prefijo IPv6!!Asignar!!Referencia
|-style="background:silver"
|<tt>0000::/8</tt>||[[Otros tipos de direcciones|Reservado para la transición y para ''loopback'']]||RFC 3513
|-
|<tt>0100::/8</tt>||Reservado||RFC 3513
|-style="background:silver"
|<tt>0200::/7</tt>||Reservado (Ej. [[Otros tipos de direcciones#Direcciones NSAP|NSAP]])||RFC 4048
|-
|<tt>0400::/6</tt>||Reservado (Ej. IPX)||RFC 3513
|-style="background:silver"
|<tt>0800::/5</tt>||Reservado||RFC 3513
|-
|<tt>1000::/4</tt>||Reservado||RFC 3513
|-style="background:silver"
|<tt>2000::/3</tt>||[[Unicast-global|Unicast global]]||RFC 3513
|-
|<tt>4000::/3</tt>||Reservado||RFC 3513
|-style="background:silver"
|<tt>6000::/3</tt>||Reservado||RFC 3513
|-
|<tt>8000::/3</tt>||Reservado||RFC 3513
|-style="background:silver"
|<tt>A000::/3</tt>||Reservado||RFC 3513
|-
|<tt>C000::/3</tt>||Reservado||RFC 3513
|-style="background:silver"
|<tt>E000::/4</tt>||Reservado||RFC 3513
|-
|<tt>F000::/5</tt>||Reservado||RFC 3513
|-style="background:silver"
|<tt>F800::/6</tt>||Reservado||RFC 3513
|-
|<tt>FC00::/7</tt>||[[Site local#ula|Unicast local única]]||RFC 4193
|-style="background:silver"
|<tt>FE00::/9</tt> ||Reservado||RFC 3513
|-
|<tt>FE80::/10</tt>||[[Enlace_local|Local al enlace]]||RFC 3513
|-style="background:silver"
|<tt>FEC0::/10</tt>||Reservado||RFC 3879
|-
|<tt>FF00::/8</tt>||Multicast||RFC 3513
|}

Generalmente, una interfaz poseerá varias direcciones IPv6. En IPv4 este comportamiento es excepcional, pero resulta trivial en IPv6.

= Direccionamiento global: Plan de direccionamiento agregado =

Este plan, propuesto en el RFC 3587, especifica la estructura de direccionamiento IPv6 definida en el RFC 3513, estableciendo el tamaño de cada bloque. Se gestiona de la misma manera que CIDR en IPv4. Una dirección incluye tres niveles de jerarquía:

<tikz title="Direcciones Globales">
\clip (0.0, 0) rectangle (11.5,7);
% \draw[help lines] (0,0) grid (10,6);

% \draw (0, 6.6) node [right] {Direccion Unicast Global:};

\draw (0,5) node [right, draw, shade, top color = yellow, minimum width=1cm, minimum height=1cm] {\tt{001}};
\draw (1,5) node [right, draw, shade, top color = green, minimum width=3cm, minimum height=1cm] {Prefijo Global};
\draw (4,5) node [right, draw, shade, top color = blue, minimum width=1.5cm, minimum height=1cm] {SID};
\draw (5.5,5) node [right, draw, shade, top color = black!50, minimum width=4.8cm, minimum height=1cm] {ID Interfaz};

\draw (0.5, 5.7) node {\tiny{3}};
\draw (2.5, 5.7) node {\tiny{45}};
\draw (4.7, 5.7) node {\tiny{16}};
\draw (8, 5.7) node {\tiny{64}};

\draw [snake=brace, mirror snake] (0, 4.20) -- (4, 4.20) node [below, midway] {\tiny{
\ifthenelse{\equal{francais}{true}}{Topología Pública}{topologia publica}}
} node [below = 8pt, midway] {\tiny{Dada por el proveedor}} ;
\draw [snake=brace, mirror snake] (4, 4.20) -- (5.5, 4.20) node [below, midway] {\tiny{topologia local}} node [below = 8pt, midway] {\tiny{Dada por el Ing. de red}} ;
\draw [snake=brace, mirror snake] (5.5, 4.20) -- (10.3, 4.20) node [below, midway] {\tiny{Dir. enlace}} node [below = 8pt, midway] {\tiny{Config. automatica o manual}} ;
</tikz>

* una topología pública (llamada "Prefijo Global") codificada en 48 bits asignados por el proveedor de acceso (ISP, ''Internet Service Provider'';
* una topología de sitio codificada en 16 bits (denominada "ID de subred, SID"). Este campo se utiliza para codificar los números de subred del sitio;
* un [[identificador de interfaz]] de 64 bits (llamado "ID de interfaz") para distinguir los diferentes dispositivos en el enlace.

==Estructuración del prefijo global (GP)==

{{HorsTexte|Para comprender los tamaños|France Télécom (FT) obtuvo de RIPE-NCC un prefijo <tt>/19</tt>. Si se descartan los primeros tres bits, <tt>001</tt>, que designan el plan de direccionamiento, entonces es posible tener 2<sup>16</sup> operadores. Considerando que hay 192 países en la ONU, cada uno podría albergar a 320 operadores del tamaño de FT; cada uno de ellos podría asignar hasta 2<sup>29</sup> prefijos <tt>/48</tt>, lo que equivale a 536,870,912 sitios}}

Aparte del prefijo <tt>2002::</tt> que está reservado para el mecanismo de transición [[6to4]], este espacio es administrado jerárquicamente como en IPv4. El IANA delega a las cinco autoridades regionales ([http://www.iana.org/numbers/ RIR]) prefijos (con una longitud actual de 12 bits, ''cf'' http://www.iana.org/assignments/ipv6-unicast-address-assignments) que redistribuyen entre los ISP de su región. En función de su tamaño, los operadores reciben un prefijo mayor o menor. En el sitio http://www.sixxs.net/tools/grh/ se pueden observar en tiempo real las asignaciones de prefijos por región, operador y país.

En la actualidad se reconoce que el prefijo asignado por un operador a sus clientes puede ser también de longitud <tt>/56</tt>, pues si se mantiene la asignación de prefijos de longitud 48 para los sitios terminales y se integran las redes domésticas, los operadores pueden justificar la necesidad de un número importante de direcciones, que las autoridades regionales no podrían rechazar.

{{ToDo|Añadir cómo obtener un prefijo en RIPE-NCC (o en otro RIR)}}

==Estructuración del identificador de subred (SID) ==

No se tienen reglas para la asignación de identificadores de subred dentro de un sitio. Se pueden utilizar varias técnicas (no excluyentes) como:

* enumerar de forma incremental las subredes: 0001, 0002, ... Esta técnica es fácil de implementar en las redes experimentales, pero puede dar lugar a un esquema de direccionamiento plano, difícil de recordar. Se puede utilizar, por ejemplo, para una subred dedicada a los servidores con el fin de simplificar la escritura y la memorización de direcciones;
* utilizar el número de VLAN. Permite no tener que memorizar múltiples niveles de numeración;
* separar los tipos de redes y utilizar las cifras a la izquierda para designarlos. Esta técnica facilita las reglas de filtrado, utilizando al mismo tiempo reglas adecuadas para la gestión de estas subredes en el segmento del lado derecho. A manera de ejemplo, la siguiente tabla contiene el plan de numeración de una universidad con varios planteles, tomando en cuenta las diferentes comunidades de usuarios:

{|
!Comunidad !! 4bits !! width="50%"|8bits !! 4bits
|-style="background:silver"
| Infraestructura || 0 || colspan=2 | valores específicos
|-
| Pruebas || 1 || colspan=2 | valores específicos
|-style="background:silver"
| Túneles || 6 || colspan=2 | asignación de /60 a los usuarios
|-
| Invitados Wi-Fi || 8 || colspan=2 | valores específicos
|-style="background:silver"
| Personal || A || Entidad || Subred
|-
| Estudiantes || E || Entidad || Subred
|-style="background:silver"
| Otros (Start up, etc.) || F || colspan=2 | valores específicos
|+ Asignación de SID en una universidad
|}

De esta manera, el prefijo:
* <tt>2001:DB8:1234::/52</tt> será para la creación de la infraestructura; en particular, las direcciones de interfaz de los enrutadores, serán asignadas de este espacio;
* <tt>2001:DB8:1234:8000::/52</tt> será para la red Wi-Fi de los invitados. La forma en que los 12 bits del SID sobrantes serán administrados, no se especifica;
* <tt>2001:DB8:1234:E000::/52</tt> será para la red de los estudiantes. La entidad representa la localización geográfica del plantel. En cada uno de estos campi, será posible tener hasta 16 subredes diferentes para cada comunidad.

=== Direccionamiento local: Direcciones locales al enlace ===

Las direcciones del tipo Enlace_local (''link local use address'') sólo son válidas dentro del enlace, es decir, sobre el conjunto de interfaces directamente accesibles sin la intervención de un enrutador, por ejemplo, dispositivos en una misma red local Ethernet, máquinas unidas por una conexión PPP, o puntos extremos de un túnel. Las direcciones locales al enlace se configuran automáticamente al inicializar la interfaz y permiten la comunicación entre nodos vecinos. La dirección se obtiene concatenando el prefijo <tt>FE80::/64</tt> a los 64 bits del [[Identificador de interfaz|identificador de interfaz]]. Aunque generalmente el identificador de interfaz está basado en la dirección MAC, no se compromete la privacidad ya que, a diferencia de las direcciones globales, las locales al enlace nunca salen de la red donde son utilizadas.

<tikz title="Direcciones locales al enlace">
% \draw (0, 3) node [right] {Link-Local Address:};
\draw (0,1.5) node [right, draw, shade, top color = yellow, minimum width=1.5cm, minimum height=1cm] {FE80};
\draw (1.5,1.5) node [right, draw, minimum width=4cm, minimum height=1cm] {0...0};
\draw (5.5,1.5) node [right, draw, shade, top color = black!50, minimum width=4.8cm, minimum height=1cm] {Interface ID};

\draw (0.7, 2.2) node {\tiny{10}};
\draw (3.5, 2.2) node {\tiny{54}};
\draw (8, 2.2) node {\tiny{64}};

\draw [snake=brace, mirror snake] (5.5, 0.8) -- (10.3, 0.8) node [below, midway] {\tiny{link address}} node [below = 8pt, midway] {\tiny{auto-configuration}} ;
</tikz>

Estas direcciones se utilizan por los protocolos de configuración de dirección global, de descubrimiento de vecinos (''neighbor discovery'') y de descubrimiento de enrutadores (''router discovery''). Se trata de mecanismos, el primero de ellos para suplantar al protocolo ARP (''Address Resolution Protocol''), que permiten que una red local se configure automáticamente (ver [[Descubrimiento de vecinos]]). También son muy utilizadas por los protocolos de enrutamiento tanto para el intercambio de datos (''cf'' RIPng, OSPFv3), como en las tablas de enrutamiento dado que el campo "siguiente enrutador" se refiere siempre a un dispositivo directamente accesible dentro del enlace.
{{HorsTexte|Unicidad sobre el enlace|Las direcciones locales al enlace son únicas al interior de un enlace. Esto lo garantiza el protocolo de detección de direcciones duplicadas (ver [[Configuracion automatica#DAD|Detección de dirección duplicada]]). En cambio, la duplicación de direcciones locales al enlace en dos enlaces distintos o entre dos interfaces de un mismo nodo, está permitida.}}

En ningún caso un enrutador podrá retransmitir un paquete que tenga como dirección fuente o destino una dirección de tipo Enlace_local.

El hecho de que estas direcciones tengan una cobertura tan corta, las limita en la práctica a casos en los que se necesita un arranque automático (''bootstrap''). Su uso no debe generalizarse para aplicaciones convencionales en condiciones de operación estable.

==== Ámbito de una dirección (''scoped address'') ====

Una dirección local al enlace (o una multicast) no indica de forma intrínseca la interfaz de salida ya que todas las interfaces comparten el mismo prefijo <tt>fe80::/10</tt>. Por consiguiente, es necesario indicar explícitamente a través de qué interfaz deben emitirse los paquetes. Bajo algunos sistemas operativos (BSD, Mac OS, Windows), ésta se puede especificar agregando al final de la dirección el nombre de la interfaz deseada, precedida del caracter "%". Bajo Linux, la interfaz de salida se designa mediante un argumento, generalmente "<tt>-I</tt>".

===Dirección local única===

El RFC 4193 define un nuevo formato de dirección unicast: las direcciones locales únicas (ULA: ''Unique Local Address''). Estas direcciones son para uso local. No están pensadas para ser enrutadas en Internet, sino dentro de un área acotada, como un sitio o un número limitado de sitios. Con un prefijo de 48 bits, pueden ser manipuladas como las direcciones globales, con un identificador de Subred (SID) de 16 bits y un identificador de interfaz (IID) de 64 bits.

Las direcciones locales únicas se crean utilizando un identificador global (''Global ID'') generado de forma pseudo-aleatoria. Estas direcciones tienen el formato siguiente:


* <tt>Prefix</tt> (7 bits): <tt>FC00::/7</tt> prefijo para identificar las direcciones IPv6 locales (''ULA'')
* <tt>L</tt> (1 bit): Puesto a 1, el prefijo es asignado localmente. El valor 0 está reservado para usos futuros.
* <tt>Global ID</tt> (40 bits): Identificador global utilizado para la creación de un prefijo "único" (''Globally Unique Prefix'').
* <tt>Subnet ID</tt> (16 bits): Identificador de subred al interior del sitio.
* <tt>Interface ID</tt> (64 bits): El identificador de interfaz, tal como está definido en [[Identificador de interfaz]].

El sitio http://www.sixxs.net/tools/grh/ula/ permite crear y registrar su propia dirección ULA a partir de una dirección MAC.

<tikz title="Direcciones locales únicas">
\clip (0, 0) rectangle (11,4);
% \draw[help lines] (0,0) grid (10,3);

% \draw (0, 3.6) node [right] {Unique Local IPv6 Unicast Addresses:};

\draw (0,2) node [right, draw, shade, top color = yellow, minimum width=1.5cm, minimum height=1cm] {FD};
\draw (1.5,2) node [right, draw, shade, top color = green, minimum width=3cm, minimum height=1cm] {Random Value};
\draw (4.5,2) node [right, draw, shade, top color = blue, minimum width=1cm, minimum height=1cm] {SID};
\draw (5.5,2) node [right, draw, shade, top color = black!50, minimum width=4.8cm, minimum height=1cm] {Interface ID};

\draw (0.7, 2.7) node {\tiny{8}};
\draw (2.7, 2.7) node {\tiny{40}};
\draw (4.7, 2.7) node {\tiny{16}};
\draw (8, 2.7) node {\tiny{64}};

\draw [snake=brace, mirror snake] (0, 1.20) -- (4.5, 1.20) node [below, midway] {\tiny{private topology}} node [below = 8pt, midway] {\tiny{Not Routable in the Internet}} ;
\draw [snake=brace, mirror snake] (4.5, 1.20) -- (5.5, 1.20) node [below, midway] {\tiny{local topology}};
\draw [snake=brace, mirror snake] (5.5, 1.20) -- (10.3, 1.20) node [below, midway] {\tiny{link address}} ;
</tikz>

Este tipo de dirección permite aislar la numeración externa e interna. En IPv4, el uso de un prefijo privado (como <tt>10/8</tt>) evita que un sitio deba renumerar su red si cambia de proveedor de acceso. Un traductor de direcciones, NAT (que llamaremos NAT44 en lo que resta de este documento), permite convertir el direccionamiento privado en público.

Con las direcciones tipo ULA es posible reproducir este comportamiento en IPv6. Un dispositivo en la orilla de la red convertirá el prefijo privado en público. Este equipo, inicialmente llamado NAT66, ha sido renombrado NPTv6 (''Network Prefix Translation'') para enfatizar que no tiene las mismas limitaciones que el NAT de IPv4.

Los prefijos ULA se caracterizan por una secuencia aleatoria de 40 bits después del prefijo <tt>FC::/7</tt>. Este valor único permite esquivar los problemas encontrados en IPv4 al fusionar dos redes privadas. Dado que el riesgo de colisión entre dos valores aleatorios de 40 bits es relativamente bajo, si dos redes se fusionan, el hecho de tener prefijos únicos evita problemas de interconexión.

= Estructuración del identificador de interfaz (IID) =

Si en un principio el identificador de interfaz debía derivarse de la dirección de nivel 2 para facilitar la auto-configuración, esto es cada vez menos necesario. De hecho, existen varios métodos para formar el identificador de interfaz de 64 bits:

* manual,
* a partir de la dirección de nivel 2 de la interfaz,
* aleatorio,
* criptográfico

== Manual ==

{{HorsTexte|La resolución de DNS |La resolución de DNS es el caso más palpable: Cada máquina en la red debe configurarse con la dirección IPv6 del servidor DNS. Si debe cambiarse la tarjeta de red del servidor, todas las máquinas en el dominio deberán reconfigurarse. Si no se desea utilizar los protocolos de configuración automática, como DHCPv6, es preferible asignar una dirección manual al resolvedor DNS.}}

Para los servidores más utilizados, puede ser recomendable asignar manualmente las direcciones a sus interfaces, pues en este caso la dirección IPv6 es fácil de recordar y el servidor se puede acceder incluso si el DNS no está activo.
Existen varias técnicas más o menos mnemotécnicas:

* Incrementar el número de identificador de interfaz para cada nuevo servidor creado

<tt>2001:DB8:1234:1::1</tt>
<tt>2001:DB8:1234:1::2</tt>
...

* recuperar el último octeto de la dirección IPv4 como identificador de interfaz. Por ejemplo, si un servidor tiene la dirección IPv4 <tt>192.0.2.123</tt>, su dirección IPv6 será:

<tt>2001:DB8:1234:1::7B</tt>
o simplemente
<tt>2001:DB8:1234:1::123</tt>

* recuperar la dirección IPv4 como identificador de interfaz, aunque ello tenga el inconveniente de generar direcciones más largas a escribir:

<tt>2001:DB8:1234:1::192.0.2.123</tt>

== A partir de la dirección de nivel 2 de la interfaz ==

La ventaja de utilizar una dirección de nivel 2 para formar el identificador de interfaz, es que casi siempre puede asegurarse que este valor es único. Además, se mantiene estable mientras la tarjeta de red de la máquina no cambie. Sin embargo, estos valores son difíciles de memorizar.

Las direcciones locales al enlace se construyen de esta manera. Para las direcciones globales, su uso sólo es aconsejable para los equipos cliente y privilegiar los identificadores de interfaz manuales para los servidores.

Dado que estos identificadores de interfaz son estables en el tiempo, cada vez que un individuo cambia de red, cambia de prefijo, pero se mantiene el mismo identificador de interfaz. En consecuencia, este identificador podría ser utilizados para rastrear los movimientos de un individuo. En realidad este es un riesgo bajo, pues las ''cookies'' creadas por los servidores Web son mucho más eficaces para ello (aunque ese ya no es un problema de red). Otra desventaja es que, como la dirección MAC contiene el identificador del fabricante, es posible mostrar al exterior de la red qué tipo de equipo se está utilizando.

Si estos inconvenientes son considerados importantes por la empresa, el identificador de interfaz de direcciones globales se pueden generar al azar.

=== EUI-64 ===

<tikz title="Transformación de una dirección MAC en identificador de interfaz">

\clip (0, 1) rectangle (11,5);
% \draw[help lines] (0,0) grid (11,4);

\draw (2, 1.5) node [right, shade, top color = yellow, minimum width=1cm, minimum height=0.5cm] {\tiny{\tt{\_\_\_\_\_\_\alert{u}g}}};
\draw (3, 1.5) node [right, shade, top color = yellow, minimum width=2cm, minimum height=0.5cm] {\tiny{Vendor}};
\draw (2, 1.25) rectangle+(3, 0.5);

\draw (5, 1.5) node [right, draw, shade, top color = blue!80, minimum width=5cm, minimum height=0.5cm] {\tiny{Serial Number}};

</tikz>

La IEEEE definió un identificador global de 64 bits (formato EUI 64) para las redes IEEE 1394 (''firewire'') o IEEE 802.15.4 (redes de sensores) con miras a su utilización en el dominio de las redes domesticas. El IEEE describe las reglas para transformar un identificador MAC de 48 bits en un EUI-64.

Existen varios métodos para construir el identificador:
{{HorsTexte|Orden de transmisión|El orden de los bits no debe prestarse a confusión. En su representación numérica, el primer bit a transmitir es el menos significativo, es decir, el bit en la extrema derecha. De esta manera, sobre el medio físico se envía primero el bit <tt>g</tt>, después el bit <tt>u</tt> y después los subsecuentes. }}

* Si un dispositivo o una interfaz posee un identificador global IEEE EUI-64, éste tendrá la estructura descrita en la figura "Identificador global IEEE EUI-64.
: Los primeros 24 bits del identificador EUI-64 designan al constructor (al igual que en las direcciones MAC IEEE 802). Los otros 40 bits corresponden al número de serie (las direcciones MAC IEEE 802 solo utilizan 24 bits). Los dos bits <tt>u</tt> (séptimo bit del primer octeto) y <tt>g</tt> (octavo bit del primer octeto) tienen un significado especial:
:* <tt>u</tt> (Universal) vale <tt>0</tt> si el identificador EUI-64 es universal;
:* <tt>g</tt> (Grupo) indica si la dirección es individual (<tt>g = 0</tt>), es decir, designa un solo dispositivo en la red, o de grupo (<tt>g = 1</tt>), por ejemplo, una dirección multicast.

<tikz title="Identificador de interfaz derivado de EUI-64">

\clip (0, 1) rectangle (11,5);
% \draw[help lines] (0,0) grid (11,4);

\draw (2, 1.5) node [right, shade, top color = yellow, minimum width=1cm, minimum height=0.5cm] {\tiny{\tt{\_\_\_\_\_\_\alert{1}0}}};
\draw (3, 1.5) node [right, shade, top color = yellow, minimum width=2cm, minimum height=0.5cm] {\tiny{Vendor}};
\draw (2, 1.25) rectangle+(3, 0.5);

\draw (5, 1.5) node [right, draw, shade, top color = blue!80, minimum width=5cm, minimum height=0.5cm] {\tiny{Serial Number}};

</tikz>
* El identificador de interfaz de 64 bits se deriva de EUI-64 invirtiendo el bit <tt>u</tt> (ver figura Identificador de interfaz derivado de EUI-64), ya que para la formación de direcciones IPv6 se ha optado por utilizar <tt>1</tt> para denotar la unicidad mundial de la dirección. Este cambio en la semántica del bit permite conservar el valor <tt>0</tt> para una numeración manual en la que las interfaces simplemente comienzan a enumerarse a partir del valor <tt>1</tt>.

===MAC-48===

<tikz title="Transformación de una dirección MAC en identificador de interfaz">

\clip (0, 1) rectangle (11,5);
% \draw[help lines] (0,0) grid (11,4);

\only<2-> {
\draw (3, 4.5) node [right, shade, top color = yellow, minimum width=1cm, minimum height=0.5cm] {\tiny{\tt{\_\_\_\_\_\_00}}};
\draw (4, 4.5) node [right, shade, top color = yellow, minimum width=2cm, minimum height=0.5cm] {\tiny{Vendor}};
\draw (3, 4.25) rectangle+(3, 0.5);

\draw (0,4.5) node [right] {MAC-48};

\draw (6, 4.5) node [right, draw, shade, top color = blue!80, minimum width=3cm, minimum height=0.5cm] {\tiny{Serial Number}};

\draw (2, 3) node [right, shade, top color = yellow, minimum width=1cm, minimum height=0.5cm] {\tiny{\tt{\_\_\_\_\_\_00}}};
\draw (3, 3) node [right, shade, top color = yellow, minimum width=2cm, minimum height=0.5cm] {\tiny{Vendor}};
\draw (2, 2.75) rectangle+(3, 0.5);

\draw (7, 3) node [right, draw, shade, top color = blue!80, minimum width=3cm, minimum height=0.5cm] {\tiny{Serial Number}};

\draw (6,4.5) -- (6, 4) -- (5, 3.5) -- (5, 3);
\draw (6,4) -- (7, 3.5) -- (7, 3);
\draw (3, 4.5) -- (3, 4) -- (2, 3.5) -- (2, 3);
\draw (9, 4.5) -- (9, 4) -- (10, 3.5) -- (10, 3);

\draw (5, 3) node [right, draw, shade, top color = red!50, minimum width=2cm, minimum height=0.5cm] {\tiny{\tt{0xFFFE}}};

\draw (0,3) node [right] {EUI-64};
}

\only<3-> {

\draw (2, 1.5) node [right, shade, top color = yellow, minimum width=1cm, minimum height=0.5cm] {\tiny{\tt{\_\_\_\_\_\_\alert{1}0}}};
\draw (3, 1.5) node [right, shade, top color = yellow, minimum width=2cm, minimum height=0.5cm] {\tiny{Vendor}};
\draw (2, 1.25) rectangle+(3, 0.5);

\draw (7, 1.5) node [right, draw, shade, top color = blue!80, minimum width=3cm, minimum height=0.5cm] {\tiny{Serial Number}};

\draw (5, 1.5) node [right, draw, shade, top color = red!50, minimum width=2cm, minimum height=0.5cm] {\tiny{\tt{0xFFFE}}};

\draw (2,3) -- (2, 1.5);
\draw (10,3) -- (10, 1.5);
\draw (0,1.5) node [right] {IID};
}

</tikz>

* Si una interfaz posee una dirección MAC IEEE 802 universal de 48 bits (es el caso, por ejemplo, de las interfaces Ethernet o Wi-Fi), la dirección primero se convierte en EUI-64, después el bit <tt>u</tt> se pone a <tt> 1 </tt> como en el caso anterior. La figura muestra este proceso.

===Casos Particulares===

* Si una interfaz posee una dirección local única en el enlace pero no universal (es el caso, por ejemplo, del formato de dirección IEEE 802 de dos octetos, o de una dirección de red Appletalk), el identificador de interfaz se forma a partir de esta dirección, agregando bits a <tt>0</tt> en la cabecera hasta completar los 64 bits.

{{HorsTexte|Error del IETF|Cabe señalar que el IETF se equivocó al definir el algoritmo de conversión, pues el valor que se agrega,<tt>0xFFFE</tt>, le corresponde a EUI-48, es decir, a ''identificadores'', mientras que en Ethernet se utilizan MAC-48, es decir, ''direcciones'' (sirven para transportar tramas hacia el destinatario apropiado). El valor correcto debió ser <tt>0xFFFF</tt>. Como este error no tiene consecuencia alguna para la identificación de los dispositivos, nunca ha sido corregido.}}

* Si una interfaz no cuenta con ninguna dirección (por ejemplo, las interfaces utilizadas para los enlaces PPP), y si la máquina no tiene un identificador EUI-64, no hay un método único para formar el identificador de interfaz. Se aconseja utilizar el identificador de otra interfaz (si esta existe y tiene una dirección MAC), una configuración manual, o bien, la generación de un identificador aleatorio con el bit <tt>u</tt> puesto en 0. <br> En caso de conflicto (por ejemplo, si los dos extremos de un enlace escogieron el mismo valor), éste será detectado al inicializar la dirección Enlace_local de la interfaz y el conflicto deberá resolverse de forma manual.

== Valor aleatorio ==

Como ya se ha mencionado, un identificador de interfaz basado en las direcciones MAC, podría acarrear problemas de privacidad, pues identifica claramente la máquina de un usuario que, aún si se desplaza de una red a otra, conserva este identificador. Por ello, seria posible ubicar a un individuo que utiliza un dispositivo móvil, en su oficina, en su hogar, o durante sus desplazamientos. Este es un problema similar al del identificador que se encuentra en los procesadores Pentium III.

[[image:Windows7-IIDalea.png|500px|right]]

Para terminar pronto con cualquier amenaza de boicot a un protocolo que "pudiera comprometer la vida privada", se han propuesto otros algoritmos para formar un identificador de interfaz, basados en la generación de valores aleatorios (ver RFC 3041). Un usuario especialmente desconfiado puede utilizar estos mecanismos. El identificador de interfaz podría ser elegido aleatoriamente, o bien formado a partir de valores precedentes como lo hace MD5, o generado al azar si la máquina no puede recordar los valores entre una inicialización y otra. Periódicamente la dirección es colocada en el estado "depreciado" y se elige un nuevo identificador de interfaz. Las conexiones ya establecidas continuarán utilizando el valor anterior, mientras que las conexiones nuevas tomarán la dirección actualizada.

Este método fue adoptado por Microsoft. En Windows XP, la interfaz tiene dos direcciones IPv6 globales. La primera posee un identificador de interfaz derivado de la dirección MAC y se utiliza para las aplicaciones s que esperan una conexión sobre la máquina (''i.e.'' las aplicaciones de servidor). Esta dirección, siendo estable, puede ser publicada en el DNS. La segunda posee un identificador de interfaz generado aleatoriamente que cambia todos los días y se utiliza para las aplicaciones cliente. En Windows 7, se generaliza este comportamiento, ya que el identificador de interfaz de la dirección permanente también es generado al azar. Con ello se evita anunciar la marca de la máquina o el tipo de tarjeta de red, contenido en los primeros octetos del identificador de interfaz.

Este método también está presente, pero de forma opcional, en Linux y en los sistemas operativos BSD como Mac OS.

Por supuesto, estos mecanismos tienen una razón de ser; es necesario que el dispositivo no se registre bajo un mismo nombre en un servidor DNS inverso, o que el registro de ''cookies'' en un navegador Web para identificar al usuario, esté imposibilitado.

Como contra partida, resulta mucho más difícil para un administrador de red el poder filtrar el tráfico de estas máquinas precisamente porque cambian su dirección periódicamente.

== Criptografia ==

{{HorsTexte|Un tema de investigación activo|El uso de estas direcciones no se ha generalizado aún. Las utilizan Shim6 para la gestión de la multi-domiciliación o SEND para asegurar el descubrimiento de vecinos.}}

Si bien un identificador aleatorio ofrece un fuerte anonimato para la fuente del paquete, se han hecho propuestas en el IETF para vincular el identificador de interfaz a la llave pública del emisor. El RFC 3972 define este principio (CGA : ''Cryptographic Generated Addresses''). Esto podría servir para asegurar los protocolos de descubierta de vecinos, o bien, para la gestión de la multi-domiciliación.

=Direcciones multicast=
{{HorsTexte|Cobertura y cobertura|No hay que confundir la cobertura de una dirección Enlace_local o multicast que designa la interfaz por la que será emitido el paquete, y la cobertura de un grupo multicast, que designa el alcance de la cobertura}}
Esta sección describe brevemente el sistema de direccionamiento multicast IPv6. Se centra únicamente en las direcciones utilizadas localmente por los protocolos vinculados directamente con IPv6 (Descubrimiento de vecinos, DHCPv6, ...). Para más información sobre multicast en general, consulte el capítulo [[eMulticast|Multicast]]. La figura 'Estructura de la dirección IPv6 Multicast' presenta el formato de las direcciones IPv6 de multicast descrito en el RFC 3513.

<tikz title="Estructura de la dirección IPv6 Multicast">
\clip (0, 1) rectangle (11,4);
% \draw[help lines] (0,0) grid (10,4 );

% \draw (0, 3.6) node [right] {Generic Format:};

\draw (0,2) node [right, draw, shade, top color = yellow, minimum width=2cm, minimum height=1cm] {FF};
\draw (2,2) node [right, draw, shade, top color = yellow, minimum width=1cm, minimum height=1cm] {\tiny{\tt{xRPT}}};
\draw (3,2) node [right, draw, shade, top color = yellow, minimum width=1cm, minimum height=1cm] {\tiny{scope}};
\draw (4,2) node [right, draw, shade, top color = black!50, minimum width=6cm, minimum height=1cm] {Group ID};

\draw (1, 2.7) node {\tiny{8}};
\draw (2.5, 2.7) node {\tiny{4}};
\draw (3.5, 2.7) node {\tiny{4}};
\draw (7, 2.7) node {\tiny{112}};

</tikz>

Las direcciones multicast IPv6 se derivan del prefijo <tt>FF00::/8</tt>. El campo bandera de 4 bits se define de la siguiente manera:

* Inicialmente, sólo el bit <tt>T</tt> (''Transient'') de este campo se describe en el RFC 3513. El valor <tt>0</tt> indica una dirección multicast bien conocida, administrada por una autoridad. El valor <tt>1</tt> indica una dirección temporal.
* Los bits <tt>P</tt> y <tt>R</tt> se describen en el RFC 3306 y en el draft Internet sobre RP embebido (RFC 3956).
* El bit más significativo de este campo aún no ha sido asignado.

El campo bandera permite definir varias direcciones multicast IPv6, las cuales se describirán en las secciones siguientes.

El campo ‘‘scope’’ de la dirección multicast IPv6 permite limitar la cobertura. Mientras que en IPv4 la cobertura de un paquete está limitada por el campo TTL (''Time To Live''), aquí también se pueden definir prefijos para limitar el alcance de las direcciones. Los siguientes valores han sido definidos en el RFC 2373:

* 1 - node-local : Los paquetes no salen del dispositivo; esta dirección sirve para la comunicación entre aplicaciones dentro de la máquina.
* 2 - link-local : La cobertura se limita a la red local; los paquetes no pueden cruzar enrutadores multicast. Este valor se utiliza en especial por el protocolo de descubrimiento de vecinos.
* 3 - subnet-local : Este tipo no se ha definido oficialmente, pero aparece en algunos documentos. Permite diferenciar entre un enlace físico y uno lógico (formado por un agrupamiento de varios enlaces físicos) que comparten el mismo prefijo IPv6.
* 4 - admin-local
* 5 - site-local
* 8 - organisation-local
* E - global
* Los valores de cobertura 0 y F están reservados.

El sitio http://www.iana.org/assignments/ipv6-multicast-addresses muestra las direcciones multicast definidas. La tabla siguiente enlista las más utilizadas:

{|
!Dirección multicast !! Uso
|-style="background:silver"
| FF01::1 || All Nodes Address
|-
| FF01::2 || All Routers Address
|-style="background:silver"
| FF02::1 || All Nodes Address
|-
| FF02::2 || All Routers Address
|-style="background:silver"
| FF02::5 || OSPFIGP
|-
| FF02::6 || OSPFIGP Designated Routers
|-style="background:silver"
| FF02::9 || RIP Routers
|-
| FF02::C || UPnP [http://http://www.upnp.org/download/Annex%20A%20-%20IPv6.doc]
|-style="background:silver"
| FF02::1:2 || All-dhcp-agents
|-
| FF03::C || UPnP [http://http://www.upnp.org/download/Annex%20A%20-%20IPv6.doc]
|-style="background:silver"
| FF04::C || UPnP [http://http://www.upnp.org/download/Annex%20A%20-%20IPv6.doc]
|-
| FF05::2 || All Routers Address
|-style="background:silver"
| FF05::C || UPnP [http://http://www.upnp.org/download/Annex%20A%20-%20IPv6.doc]
|-
| FF05::1:3 || All-dhcp-servers
|-style="background:silver"
| FF0X::101 || Network Time Protocol (NTP)
|}

==Direccionamiento Multicast Solicitado==

IPv6 no permite el uso de la difusión generalizada (''Broadcast'') cuando la difusión restringida (multicast) está disponible. Así, los protocolos como ''Neighbor Discovery'', encargado de establecer la relación entre las direcciones IPv6 y las direcciones MAC (en vez de ARP en IPv4) deben utilizar una dirección multicast. Para incrementar la eficacia, en vez de utilizar la dirección <tt>FF02::1</tt>, que involucra a todos los dispositivos en el enlace, las direcciones multicast solicitado permiten reducir considerablemente el número de equipos que recibirán la solicitud.

<tikz title="Construcción de la dirección Multicast Solicitada">
\clip (0, 0) rectangle (10,4);
%\draw[help lines] (0,0) grid (10,4 );

\draw (2, 3.75) node (mac) [right, draw, shade, top color = blue!80, minimum width=3cm, minimum height=0.5cm] {\tiny{\tt{01-02-03-04-05-06}}};

\draw (0, 2.75) node (LL) [right, draw, shade, top color = green!80, minimum width=3cm, minimum height=0.5cm] {\tiny{\tt{FE80::0102:03FF:FE04:0506}}};

\draw (4, 2.75) node (GP) [right, draw, shade, top color = green!80, minimum width=3cm, minimum height=0.5cm] {\tiny{\tt{GP:0102:03FF:FE04:0506}}};

\draw [->] (mac) -- (LL);
\draw [->] (mac) -- (GP);

\draw (8, 2.75) node (manuel) [right, draw, shade, top color = green!80, minimum width=1cm, minimum height=0.5cm] {\tiny{\tt{GP::1}}};

\draw (2.5, 1.75) node (MS1) [right, draw, shade, top color = red!80, minimum width=1cm, minimum height=0.5cm] {\tiny{\tt{FF02::1:FF04:0506}}};
\draw [->] (LL) -- (MS1);
\draw [->] (GP) -- (MS1);

\draw (7.4, 1.75) node (MS2) [right, draw, shade, top color = red!80, minimum width=1cm, minimum height=0.5cm] {\tiny{\tt{FF02::1:FF00:0001}}};
\draw [->] (manuel) -- (MS2);

\draw (2.5, 0.75) node (mac2) [right, draw, shade, top color = blue!80, minimum width=1cm, minimum height=0.5cm] {\tiny{\tt{33-33-FF-04-05-06}}};
\draw [->] (MS1) -- (mac2);

\draw (7.4, 0.75) node (mac3) [right, draw, shade, top color = blue!80, minimum width=1cm, minimum height=0.5cm] {\tiny{\tt{33-33-FF-00-00-01}}};
\draw [->] (MS2) -- (mac3);
</tikz>

La figura <i>Construcción de la dirección Multicast Solicitada</i> muestra cómo transformar una dirección IPv6 unicast en una dirección multicast solicitada. Se deben tomar los últimos tres octetos de la dirección unicast, y concatenarlos al prefijo IPv6 multicast <tt>FF02::1:FF00:0/104</tt>.

En el ejemplo mostrado, las dos direcciones derivadas de una dirección MAC, conducen a la misma dirección de multicast solicitada, mientras que la configuración manual de una interfaz genera otra dirección multicast solicitada. Puede observarse que el riesgo de que dos máquinas sobre un enlace tengan la misma dirección multicast solicitada, es muy bajo. Para las generadas a partir de una dirección MAC, sería necesario que los últimos tres octetos sean idénticos, lo cual es imposible para un mismo fabricante y la probabilidad de tener sobre el mismo enlace, tarjetas de red de dos fabricantes distintos que coincidan en el número de serie (tres últimos octetos), es muy baja. Bajo la enumeración manual de las interfaces, un dispositivo que tenga la dirección <tt>GP::<b>01</b>00:0001</tt> llevaría a generar la misma dirección multicast solicitada <tt>FF02::1:FF00:0001</tt>, pero esta numeración manual de interfaces, no resulta lógica.

{{HorsTexte|Solicitud de vecinos|El algoritmo de descubrimiento de direcciones de nivel 3 de vecinos (incluído en el protocolo ‘‘Neighbor Discovery’’) funciona de la siguiente manera. El dispositivo que busca un vecino del que conoce su dirección IPv6, ejecuta el algoritmo descrito anteriormente. Envía la solicitud utilizando la dirección MAC obtenida; sólo la máquina que posea esa dirección será incorporada al grupo; por tanto, será la única que pueda recibir y responder a la solicitud.}}

El ejemplo muestra la conversión de la dirección multicas a nivel IPv6, en dirección multicast de nivel 2. Es muy específico a la tecnología y a la forma en que se implementa el multicas de nivel 2. Para las redes Ethernet (y sus derivados, como WiFi), los cuatro últimos olctetos de la dirección multicast solicitada se agregan al prefijo <tt>33-33</tt>.

{{esuivi |Introduccion|Introducción|Direccionamiento-Implementaciones|Implementaciones}}

Protocolo de Descubrimiento de vecinos

2012-07-02T00:29:11Z

Jincera:

Protocolo de Descubrimiento de vecinos

2012-07-02T00:27:04Z

Jincera: /* Configuración automática */

Protocolo de Descubrimiento de vecinos

2012-07-02T00:24:19Z

Jincera: /* Configuración automática */

Protocolo de Descubrimiento de vecinos

2012-07-02T00:20:14Z

Jincera: /* Configuración automática */

Protocolo de Descubrimiento de vecinos

2012-07-02T00:19:30Z

Jincera: /* Configuración automática */

Protocolo de Descubrimiento de vecinos

2012-07-02T00:17:45Z

Jincera:

Protocolo de Descubrimiento de vecinos

2012-06-28T14:50:49Z

Jincera: /* Indicación de redirección */

Protocolo de Descubrimiento de vecinos

2012-06-28T14:50:01Z

Jincera: /* Indicación de redirección */

Protocole de Découverte des voisins

2012-06-28T14:49:20Z

Jincera: /* Indication de redirection */

{{Suivi|Table_des_matières|Début du chapitre|DHCPv6|DHCPv6}}

__TOC__
Le protocole de découverte des voisins ou NDP (''Neighbor Discovery Protocol'') permet à un équipement de s'intégrer dans l'environnement local, c'est-à-dire le lien sur lequel sont physiquement transmis les paquets IPv6. Il permet de dialoguer avec les équipements connectés au même support (stations et routeurs). Il ne s'agit pas pour un équipement de connaître exactement la liste de tous les autres équipements connectés sur le lien, mais uniquement de gérer ceux avec qui il dialogue.

Le protocole utilise cinq types de messages ICMPv6 (voir Valeurs des champs type et code d'ICMPv6). Le champ nombre de sauts de l'en-tête IPv6 contient la valeur 255. Cette valeur sembler trop grande pour des datagrammes qui ne doivent pas être routés hors du lien physique ; en fait si un équipement reçoit un datagramme avec une valeur plus petite, cela signifie que l'information provient d'un autre réseau et qu'elle a déjà traversée un routeur. Les datagramme ayant une valeur différent de 255 doivent être ignorés par le récepteur.

{{Tableau ICMPv6}}

Le protocole réalise les différentes fonctions :

* Résolution d'adresses. Le principe est très proche du protocole ARP que l'on trouve avec IPv4. La principale différence vient de l'emploi de messages standards ICMPv6 à la place de la définition d'un autre protocole de niveau 3. Cela confère une plus grande souplesse d'utilisation en particulier sur les réseaux qui ne supportent pas la diffusion. Comme pour IPv4, ce protocole construit des tables de mise en correspondance entre les adresses IPv6 et physiques.
* <div id="NUD">Détection d'inaccessibilité des voisins ou NUD (''Neighbor Unreachability Detection''). Cette fonction n'existe pas en IPv4. Elle permet d'effacer des tables de configuration d'un équipement les voisins qui sont devenus inaccessibles (panne, changement d'adresse,...). Si un routeur devient inaccessible, la table de routage peut être modifiée pour prendre en compte une autre route.</div>
* Configuration. La configuration automatique des équipements est l'un des attraits principaux d'IPv6. Plusieurs fonctionnalités du protocole de découverte des voisins sont mises en oeuvre :
** Découverte des routeurs. Ce protocole permet aux équipements de déterminer les routeurs qui sont sur leur lien physique. Dans IPv4, ces fonctionnalités sont assurées par le protocole ICMP Router Discovery.
** Découverte des préfixes. L'équipement apprend le ou les préfixes du réseau en fonction des annonces faites par les routeurs. En y ajoutant l'identifiant d'interface de l'équipement, celui-ci construit son ou ses adresses IPv6. Il n'existe pas d'équivalent pour le protocole IPv4 puisque les adresses sont trop courtes pour faire de l'auto-configuration.
** Détection des adresses dupliquées. Comme les adresses sont construites automatiquement, il existe des risques d'erreurs en cas d'identité de deux identifiants. Ce protocole teste qu'aucun autre équipement sur le lien ne possède la même adresse IPv6. Cette fonctionnalité est une évolution de l'ARP gratuit d'IPv4 émis à l'initialisation de l'interface.
** Découverte des paramètres. Ce protocole permet aux équipements d'apprendre les différents paramètres du lien physique, par exemple, la taille du MTU, le nombre de sauts maximal autorisé (valeur initiale du champ nombre de sauts), si la configuration automatique avec état (comme [[Configuration avec état :DHCPv6|DHCPv6]]) est active... Il n'existe pas d'équivalent en IPv4.
* Indication de redirection. Ce message est utilisé quand un routeur connaît une route meilleure (en nombre de sauts) pour aller à une destination.
:En IPv4 une indication de redirection ne peut servir qu'à corriger l'adresse du routeur utilisé pour accéder à une machine hors du réseau local. Les machines doivent connaître toutes les adresses correspondant aux réseaux locaux.
:Avec IPv6, la correspondance entre préfixe et réseau local est moins stricte. Il est prévu qu'un matériel ne connaisse pas tous les préfixes de son réseau local (si celui-ci est partagé par plusieurs préfixes), ou qu'un préfixe soit partagé entre plusieurs liens (une généralisation du modèle des réseaux logiques d'IP sur ATM). Dans certaines configurations, la machine émettra ses paquets au routeur alors que le destinataire se trouve sur le même segment que l'émetteur. Si c'est le cas, le routeur émettra un message de redirection pour que la suite du dialogue se fasse directement (cf. exemples [[Découverte_de_voisins#IR|Indication de redirection]]).
:Dans le cas le plus extrême, on peut imaginer en IPv6 qu'un équipement peut être configuré pour dialoguer uniquement avec son routeur par défaut. ICMPv6 «redirect» est alors utilisé pour informer l'équipement des destinataires sur le même lien.

IPv6 spécifie deux méthodes d'autoconfiguration pour l'adresse unicast globale :

* l'autoconfiguration sans état (''stateless autoconfiguration'', RFC 2462) ; elle est utilisée quand la gestion administrative des adresses attribuées n'est pas nécessaire au sein d'un site. Ces mécanismes sont décrits dans la suite de ce chapitre.
* l'autoconfiguration avec état (''stateful autoconfiguration'') ; elle est retenue lorsqu'un site demande un contrôle strict de l'attribution des adresses (cf. [[Configuration avec état :DHCPv6|DHCPv6]]).

Mais l'utilisation de DHCPv6 pour obtenir l'adresse est pilotée par le protocole de découverte des voisins.

= Données véhiculées par les messages =

L'intérêt du protocole de découverte des voisins est d'unifier différents protocoles qui existent dans IPv4. En particulier la plupart des données utilise un format d'options commun, ce qui simplifie la mise en oeuvre du protocole. Le format contient les champs type, longueur en mots de 64 bits, données. La faible précision du champ longueur va introduire une perte de place. En contre-partie, elle va permettre aussi un alignement des options sur des mots de 64 bits, ce qui optimise leur traitement.

{{NB-options}}

== <div id="physique">Adresse physique de la source/cible</div> ==

<tikz title="Format de l'option adresse physique source/cible">
\clip (0.2, 5.7) rectangle (11.1,6.7);
% \draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=1/2}};
\draw (2.9, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{lenght }};
\draw (5.3, 6) node (addr) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Link Layer Address}};

\draw [draw=white, thick] (addr.north east) -- (addr.south east);
\draw [draw=white, thick] (addr.north east) -- +(-2, 0);
\draw [draw=white, thick] (addr.south east) -- +(-2, 0);

\draw [dashed] (addr.north east) -- (addr.south east);
\draw [dashed] (addr.north east) -- +(-2, 0);
\draw [dashed] (addr.south east) -- +(-2, 0);
</tikz>

La figure Format de l'option adresse physique source/cible donne le format de ces options. Le type 1 est réservé à l'adresse physique de la source et le type 2 à l'adresse de la cible.

Le champ «longueur» est la taille en mots de 64 bits de l'option. Dans le cas d'une adresse MAC, d'une longueur de 6 octets, il contient donc la valeur 1.

Le RFC 2464 définit le format pour les adresses MAC-48 utilisés dans les réseaux Ethernet et Wi-Fi. Le RFC 4944 définit le format pour les MAC-16 et MAC-64 utilisés dans les réseaux de capteurs reposant sur la norme IEEE 802.15.4.

== <div id="information">Information sur le préfixe</div> ==

<tikz title="Format de l'option information sur le préfixe">
\clip (0.2, 2) rectangle (11.1, 7);
% \draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=3}};
\draw (2.9, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{length =4 }};
\draw (5.3, 6) node (addr) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm] {\tiny{Prefix Length}};
\draw (7.7, 6) node (bitL) [right, shade, top color=blue!15, bottom color=blue!5,, draw, minimum height=0.5cm, minimum width=.3cm]{}; \draw (bitL.text) node {\tiny{L}};
\draw (8, 6) node (bitA) [right, shade, top color=blue!15, bottom color=blue!5,, draw, minimum height=0.5cm, minimum width=.3cm]{};\draw (bitA.text) node {\tiny{A}};
\draw (8.3, 6) node (bitR) [right, shade, top color=blue!15, bottom color=blue!5,, draw, minimum height=0.5cm, minimum width=.3cm]{};\draw (bitR.text) node {\tiny{R}};
\draw (8.6, 6) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=1.5cm] {\tiny{Reserved}};

\draw (0.5, 5.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Valid Lifetime}};

\draw (0.5, 5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Prefered Lifetime}};

\draw (0.5, 4.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Reserved}};

\draw (0.5, 4) node (addr1) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{}};
\draw (0.5, 3.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{}};
\draw (0.5, 3) node (addr3) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Prefix}};
\draw (0.5, 2.5) node (addr4) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{}};

\draw [color=blue!10, very thick] (addr1.south east) -- (addr1.south west);
\draw [color=blue!10, very thick] (addr2.south east) -- (addr2.south west);
\draw [color=blue!10, very thick] (addr3.south east) -- (addr3.south west);
</tikz>

Cette option contient les informations sur le préfixe pour permettre une configuration automatique des équipements. Le champ type vaut 3 et le champ longueur vaut 4. La figure Format de l'option information sur le préfixe donne le format de l'option :

* Le champ lg.préfixe indique combien de bits sont significatifs pour le préfixe annoncé dans un champ suivant.
* Le bit <tt>L</tt> indique, quand il est à 1, que le préfixe permet d'indiquer que tous les autres équipements partageant le même préfixe sont sur le même lien. L'émetteur peut donc directement les joindre. Dans le cas contraire, l'équipement émet le paquet vers le routeur. Si ce dernier sait que l'équipement émetteur peut joindre directement le destinataire, il émettra un message ICMPv6 d'indication de redirection.
* Le bit <tt>A</tt> indique, quand il est à 1, que le préfixe annoncé peut être utilisé pour construire l'adresse de l'équipement.
* Le bit <tt>R</tt>, indique, quand il est à 1, que le champ préfixe contient l'adresse globale d'un routeur «agent mère». Les bits de poids fort peuvent toujours être utilisés pour construire un préfixe.
* Le champ durée de validité indique en secondes la durée pendant laquelle le préfixe est valide.
* Le champ durée préférable indique la durée en secondes pendant laquelle une adresse construite avec le protocole de configuration sans état demeure «préférable» (cf. [[Plans d'adressage|Durée de vie des adresses]]).

Pour ces deux champs, une valeur de <tt>0xffffffff</tt> représente une durée infinie. Ces champs peuvent servir dans la phase de passage d'un fournisseur d'accès à un autre ; c'est-à-dire d'un préfixe à un autre.
* Le champ réservé permet d'aligner le préfixe sur une frontière de mot de 64 bits.
* Le champ préfixe contient la valeur de préfixe annoncé sur le lien. Pour maintenir un alignement sur 64 bits pour le reste des données du paquet, ce champ a une longueur fixe de 128 bits.

== <div id="redirigee">En-tête redirigée</div> ==

<tikz title="Format de l'option en-tête redirigée">
\clip (0.2, 3.1) rectangle (11.1, 7);
% \draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=5}};
\draw (2.9, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{length =1 }};
\draw (5.3, 6) node (addr) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Reserved}};

\draw (0.5, 5.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Reserved}};

\draw (0.5, 4.25) node (context) [right, shade, top color=purple!50, bottom color=purple!10, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{IPv6 Header and Data}};
</tikz>

Cette option est utilisée par le message d'indication de redirection. Elle permet d'encapsuler les premiers octets du paquet IPv6 qui a provoqué l'émission de ce message comme dans le cas des messages ICMPv6 d'erreur.

Le type vaut 4 et la taille de cette option ne doit pas conduire à un paquet IPv6 dépassant 1280 octets (cf. figure Format de l'option en-tête redirigée). Par contre le paquet doit contenir le maximum d'information possible.

== <div id="MTU">MTU</div> ==

<tikz title="Format de l'option MTU'">

\clip (0.2, 5.1) rectangle (11.1, 7);
% \draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=5}};
\draw (2.9, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{lenght =1 }};
\draw (5.3, 6) node (addr) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Reserved}};

\draw (0.5, 5.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{MTU}};
</tikz>

Cette option permet d'informer les équipements sur la taille maximale des données pouvant être émises sur le lien. La figure Format de l'option MTU donne le format de cette option. Il n'est pas nécessaire de diffuser cette information si l'équipement utilise toujours la taille maximale permise. Par exemple, sur les réseaux Ethernet, les équipements utiliseront la valeur 1 500. Par contre pour les réseaux anneau à jeton ou FDDI, il est souvent nécessaire de préciser si les équipements doivent utiliser la valeur maximale permise ou une valeur inférieure pour autoriser l'utilisation de ponts.

Le champ type vaut 5 et le champ longueur 1.

=Messages standards de Découverte des voisins=

En plus des cinq options générales décrites dans le tableau Utilisation des options dans les messages de découverte des voisins, il existe d'autres options spécifiques pour la mobilité et les réseaux NBMA (''Non Broadcast Multiple Access'').

{|
|+ Utilisation des options dans les messages de découverte des voisins
| width = 150 | || width = 100 |[[#RS|sollicitation du]] || width = 100 |[[#RA|annonce du]] || width = 100 |[[#NS|sollicitation]] ||width = 100 | [[#NA|annonce]] ||width = 100 |[[#IR|indication de]]
|-
| || [[#RS|routeur]] || [[#RA|routeur]] || [[#NS|d'un voisin]] || [[#NA|d'un voisin]] || [[#IR|redirection]]
|-style="background:silver"
|[[#physique |adresse physique de la source]] || présent || présent || présent || ||
|-
|[[#physique |adresse physique de la cible]] || || || || présent || présent
|-style="background:silver"
|[[#information|information sur le préfixe]] || || ≥ 1 || || ||
|-
|[[#redirigee |en-tête redirigée]] || || || || || présent
|-style="background:silver"
| [[#MTU |MTU]] || || possible || || ||
|}

Les différentes fonctionnalités de découverte des voisins utilisent 5 messages : 2 pour le dialogue entre un équipement et un routeur, 2 pour le dialogue entre voisins et un dernier pour la redirection. Chacun de ces messages peut contenir des options.

== <div id="RS">Sollicitation du routeur</div> ==

<tikz title="Format des paquets de sollicitation du routeur">
\clip (0.2, 3.5) rectangle (11.1,7.1);
%\draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=133}};
\draw (2.9, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code =0 }};
\draw (5.3, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};
\draw (0.5, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Reserved}};

\draw (0.5, 4.25) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Options:\\
- Source link-layer address
}};
</tikz>

Le message de sollicitation d'un routeur (cf. figure Format des paquets de sollicitation du routeur) est émis par un équipement au démarrage pour recevoir plus rapidement des informations du routeur. Ce message est émis à l'adresse IPv6 de multicast réservée aux routeurs sur le même lien <tt>ff02::2</tt>. Si l'équipement ne connaît pas encore son adresse source, l'adresse non spécifiée est utilisée.

Le champ option contient normalement l'adresse physique de l'équipement.

== <div id="RA">Annonce du routeur</div> ==

<tikz title="Format des paquets d'annonce du routeur">
\clip (0.2, 1.5) rectangle (11.1,7.1);
%\draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=134}};
\draw (2.9, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code =0 }};
\draw (5.3, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};

\draw (0.5, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Cur. Hop Lim.}};
\draw (2.9, 5.5) node (bitM) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{}; \draw (bitM.text) node {\tiny{M}};
\draw (3.2, 5.5) node (bitO) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{};\draw (bitO.text) node {\tiny{O}};
\draw (3.5, 5.5) node (bitH) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{};\draw (bitH.text) node {\tiny{H}};
\draw (3.8, 5.5) node (res) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=1.5cm]{\tiny{reserved}};
\draw (5.3, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Router Lifetime}};

\draw (0.5, 5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=9.6cm]{\tiny{Reachable Time}};
\draw (0.5, 4.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=9.6cm]{\tiny{Retrans Time}};

\draw (0.5, 3.25) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Options:\\
Source link-layer address\\
MTU\\
Prefix Information (may be repeated)\\
}};
</tikz>

Ce message (cf. figure Format des paquets d'annonce du routeur) est émis périodiquement par les routeurs ou en réponse à un message de sollicitation d'un routeur par un équipement. Le champ adresse source contient l'adresse locale au lien du routeur, le champ destination contient soit l'adresse de l'équipement qui a émis la sollicitation, soit l'adresse de toutes les stations (<tt>ff02::01</tt>).

Un champ saut max. non nul donne la valeur qui pourrait être placée dans le champ nombre de sauts des paquets émis. Le bit <tt>M</tt> indique qu'une adresse de l'équipement doit être obtenue avec un protocole de configuration (cf. [[Configuration avec état :DHCPv6]]). Le bit <tt>O</tt> indique aussi la présence d'un service de configuration mais pour la récupération d'informations autres que l'adresse. Si l'adresse ne peut être obtenue d'un serveur, l'équipement procède à une configuration sans état en concaténant aux préfixes qu'il connaît son identifiant d'interface. Le bit <tt>H</tt> indique que le routeur peut être utilisé comme «agent mère» pour un noeud mobile (cf. [[Déplacements_des_mobiles#Avertissement_de_l'agent_mère|Avertissement de l'agent mère]]).

Le champ durée de vie du routeur donne, en secondes, la période pendant laquelle l'équipement annonçant effectuera les fonctions de routeur par défaut. La valeur maximale correspond à 18 heures 12 minutes, mais comme ce message est émis périodiquement il n'y a pas de limite théorique à la durée de vie d'un routeur. Une valeur de <tt>0</tt> indique que l'équipement ne remplit pas les fonctions de routeur par défaut. Cette durée de vie ne s'applique pas aux options que ce message véhicule.

Le champ durée d'accessibilité indique la durée en millisecondes pendant laquelle une information contenue dans le cache de la machine peut être considérée comme valide (par exemple, la table de correspondance entre adresse IPv6 et adresse physique). Au bout de cette période, un message de détection d'inaccessibilité est émis pour vérifier la pertinence de l'information.

Le champ temporisation de retransmission donne en millisecondes la période entre deux émissions non sollicitées de ce message. Il sert aux autres équipements pour détecter une inaccessibilité du routeur.

Ce message peut véhiculer les options :

* adresse physique de la source,
* MTU,
* information sur le préfixe (une ou plus).

== <div id="NS">Sollicitation d'un voisin</div> ==

<tikz title="Format des paquets de sollicitation d'un voisin">

\clip (0.2, 1.5) rectangle (11.1,7.1);
%\draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=135}};
\draw (2.9, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code =0 }};
\draw (5.3, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};

\draw (0.5, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=9.6cm]{\tiny{Reserved}};

\draw (0.5, 4.25) node (context) [right, shade, top color=blue!50, bottom color=blue=!10, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Target Address}};

\draw (0.5, 2.25) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Options:\\
Source link-layer address\\
}};
</tikz>

Ce message (cf. figure Format des paquets de sollicitation d'un voisin) permet d'obtenir des informations d'un équipement voisin, c'est-à-dire situé sur le même lien physique (ou connecté via des ponts). Le message peut lui être explicitement envoyé ou émis sur une adresse de diffusion. Dans le cas de la détermination de l'adresse physique, il correspond à la requête ARP du protocole IPv4.

Le champ adresse source du paquet IPv6 contient soit l'adresse locale au lien adresse lien-local, soit une adresse globale, soit l'adresse non spécifiée. Le champ destination contient soit l'adresse de multicast sollicité correspondant à l'adresse recherchée (cf. [[Adressage_multicast#Identifiant_de_groupe|Identifiant de groupe]]), soit l'adresse de l'équipement (dans le cas d'une détection d'inaccessibilité des voisins, NUD )

Le champ adresse de la cible contient l'adresse IPv6 de l'équipement cherché. Le champ option contient en général l'adresse physique de la source.

== <div id="NA">Annonce d'un voisin</div> ==

<tikz title="Format des paquets d'annonce d'un voisin">

\clip (0.2, 1.5) rectangle (11.1,7.1);
%\draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=136}};
\draw (2.9, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code =0 }};
\draw (5.3, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};

\draw (0.5, 5.5) node (bitR) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{}; \draw (bitR.text) node {\tiny{R}};
\draw (0.8, 5.5) node (bitS) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{}; \draw (bitS.text) node {\tiny{S}};
\draw (1.1, 5.5) node (bitO) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=.3cm]{}; \draw (bitO.text) node {\tiny{O}};
\draw (1.4, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=8.7cm]{\tiny{Reserved}};

\draw (0.5, 4.25) node (context) [right, shade, top color=blue!50, bottom color=blue=!10, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Target Address}};

\draw (0.5, 2.25) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Options:\\
Source link-layer address\\
}};
</tikz>

Ce message (cf. figure Format des paquets d'annonce d'un voisin) est émis en réponse à une sollicitation, mais il peut aussi être émis spontanément pour propager une information de changement d'adresse physique, ou de statut «routeur». Dans le cas de la détermination d'adresse physique, il correspond à la réponse ARP pour le protocole IPv4.

* Le bit <tt>R</tt> est mis à 1 si l'émetteur est un routeur. Ce bit est utilisé pour permettre la détection d'un routeur qui redevient un équipement ordinaire.
* Le bit <tt>S</tt> mis à 1 indique que cette annonce est émise en réponse à une sollicitation.
* Le bit <tt>O</tt> mis à 1 indique que cette annonce doit effacer les informations précédentes qui se trouvent dans les caches des autres équipements, en particulier la table contenant les adresses physiques.
* Le champ adresse de la cible contient, si le bit <tt>S</tt> est à 1, la valeur du champ adresse de la cible de la sollicitation auquel ce message répond. Si le bit <tt>S</tt> est à 0, ce champ contient l'adresse IPv6 lien-local de l'équipement émetteur.
* L'option adresse physique de la cible contient l'adresse physique de l'émetteur.

== <div id="IR">Indication de redirection</div> ==

<tikz title="Format des paquets d'indication de redirection">
\clip (0.2, 0) rectangle (11.1,7.1);
%\draw[help lines] (0,0) grid (11,6);

\draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}};

\draw (0.5, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=137}};
\draw (2.9, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code =0 }};
\draw (5.3, 6) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};

\draw (0.5, 5.5) node (context) [right, shade, top color=blue, draw, minimum height=0.5cm, minimum width=9.6cm]{\tiny{Reserved}};

\draw (0.5, 4.25) node (context) [right, shade, top color=blue!50, bottom color=blue=!10, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Target Address}};

\draw (0.5, 2.25) node (context) [right, shade, top color=blue!50, bottom color=blue=!10, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Destination Address}};

\draw (0.5, 0.5) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=1.5cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Options:\\
Target link-layer address\\
Redirected Header\\
}};
</tikz>

La technique de redirection est la même que dans IPv4. Un équipement ne connaît que les préfixes des réseaux auxquels il est directement attaché et l'adresse d'un routeur par défaut. Si la route peut être optimisée, le routeur par défaut envoie ce message pour indiquer qu'une route plus courte existe. En effet, avec IPv6, comme le routeur par défaut est appris automatiquement, la route n'est pas forcément la meilleure (cf. figure Routage par défaut non optimal).

Un autre cas d'utilisation particulier à IPv6 concerne des stations situées sur un même lien physique mais ayant des préfixes différents. Ces machines passent dans un premier temps par le routeur par défaut. Ce dernier les avertit qu'une route directe existe.

La figure Format des paquets d'indication de redirection donne le format du message :

* Le champ adresse cible contient l'adresse IPv6 de l'équipement vers lequel les paquets doivent être émis.
* Le champ adresse destination contient l'adresse IPv6 de l'équipement pour lequel la redirection s'applique.

Dans le cas de la redirection vers un équipement se situant sur le même lien, l'adresse cible et la destination sont identiques.

Les options contiennent l'adresse physique du nouveau routeur et l'en-tête du paquet redirigé.

Ce message peut être utilisé de la même manière qu'en IPv4. Une machine n'a qu'une route par défaut pour atteindre un équipement se trouvant sur un autre préfixe. Elle envoie donc son paquet au routeur qui s'aperçoit que le préfixe de destination est accessible par le même sous réseau que l'émetteur. Il relaie le paquet et informe la source qu'elle peut directement joindre le routeur menant vers le préfixe.

IPv6 utilise aussi ce message pour optimiser la résolution Hors-Lien dans le [[#Cas des réseaux NBMA|cas de réseaux NBMA]].

=Configuration automatique=
Traditionnellement, la configuration d'une interface réseau d'une machine demande une configuration manuelle. C'est un travail souvent long et source d'erreurs. Avec IPv6, cette configuration est automatisée, introduisant par là-même des caractéristiques de fonctionnement immédiat (''plug and play'') à l'interface réseau. La configuration automatique signifie qu'une machine obtient toutes les informations nécessaires à sa connexion à un réseau local IP sans aucune intervention humaine. Dans le cas idéal, un utilisateur quelconque déballe son nouvel ordinateur, le connecte au réseau local et le voit fonctionner sans devoir y introduire des informations de "spécialiste". Nous allons maintenant étudier l'autre aspect de l'autoconfiguration de IPv6 qui est l'autoconfiguration d'adresses. Celle-ci a pour objectif :

* l'acquisition d'une adresse quand une machine est attachée à un réseau pour la première fois ;
* la possibilité d'attribuer d'autres préfixes, voire de renuméroter une machine.

Le processus d'autoconfiguration d'adresse d'IPv6 comprend la création d'une adresse lien-local, l'attachement aux groupes de multicast sollicités, la vérification de l'unicité de l'adresse lien-local et la construction d'adresses unicast globales.

Le rôle du routeur est important dans l'autoconfiguration. Il dicte à la machine, par des bits (cf. [[Découverte de voisins#RA|Annonce du routeur]]) de l'en-tête du message d'annonce de routeurs, la méthode à retenir et fournit éventuellement les informations nécessaires à sa configuration. Le bit <tt>M</tt> (''Managed address configuration'') mis à 1 indique que l'équipement ne doit pas construire lui-même l'adresse à partir de son identifiant d'interface et des préfixes reçus, mais doit explicitement demander son adresse auprès d'une application d'un serveur d'adresses. Le bit <tt>O</tt> (''Other stateful configuration'') indique que l'équipement doit interroger le serveur de configuration pour obtenir des paramètres autre que l'adresse. L'algorithme de la procédure d'autoconfiguration d'adresse se décompose de la manière suivante :

* La toute première étape consiste à créer l'adresse lien-local.
* Une fois l'unicité de cette adresse vérifiée, la machine est en mesure de communiquer avec les autres machines du lien.
* La machine doit chercher à acquérir un message d'annonce du routeur pour déterminer la méthode d'obtention de l'adresse unicast globale.
* S'il y a un routeur sur le lien, la machine doit appliquer la méthode indiquée par le message d'annonce de routeurs, à savoir :
** l'autoconfiguration sans état,
** l'autoconfiguration avec état.
* En l'absence de routeur sur le lien, la machine doit essayer d'acquérir l'adresse unicast globale par la méthode d'autoconfiguration avec état. Si la tentative échoue, c'est terminé. Les communications se feront uniquement sur le lien avec l'adresse lien-local. La machine n'a pas une adresse avec une portée qui l'autorise à communiquer avec des machines autres que celles du lien.

==Cycle de vie d'une adresse==

IPv6 généralisant le plan d'adressage CIDR, les préfixes restent dans tous les cas la propriété des opérateurs. Il ne peuvent plus être attribués "à vie" aux équipements. Pour faciliter la renumérotation d'une machine l'attribution d'une adresse à une interface est faite temporairement, les adresses IPv6 ne sont pas données mais prêtées. Une durée de vie est associée à l'adresse qui indique le temps pendant lequel l'adresse appartient à l'interface. Quand la durée de vie est épuisée, l'adresse devient invalide, elle est supprimée de l'interface et devient potentiellement assignable à une autre interface. Une adresse invalide ne doit jamais être utilisée comme adresse dans des communications. La valeur par défaut de la durée de vie d'une adresse est de 30 jours, mais cette durée peut être prolongée, ou portée à l'infini. L'adresse lien-local a une durée de vie illimitée.

<tikz title="États successifs d'une adresse sur une interface">

\draw [thick, ->] (0,2) -- (9.5,2);

\draw [->] (1,4) node [above=10pt] {\tiny{allocation}}-- (1,2);
\draw (1, 2) node [rectangle, minimum width=1cm, minimum height=1cm, fill, left color=black!10, right color=black!20, draw=black, above right] (tentative) {};
\draw (tentative.south east) node [rectangle, minimum width=3cm, minimum height=1cm, fill, left color=green, right color=green!50, draw=black, above right] (preferred) {};
\draw (preferred.south east) node [rectangle, minimum width=2cm, minimum height=1cm, fill, left color=orange , right color=orange!50!red, draw=black, above right] (deprecated) {};
\draw (deprecated.south east) node [rectangle, minimum width=2cm, minimum height=1cm, fill, color=red, draw=black, above right] (novalid) {};

\draw (tentative.text) node {\tiny{Tentative}};
\draw (preferred.text) node {\tiny{Preferred}};
\draw (deprecated.text) node {\tiny{Deprecated}};
\draw (novalid.text) node {\tiny{Invalid}};

\draw [dotted] (tentative.south west) -- +(0, -1);
\draw [dotted] (preferred.south west) -- +(0, -1);
\draw [dotted] (deprecated.south west) -- +(0, -1);
\draw [dotted] (novalid.south west) -- +(0, -1);

\draw [dashed, <->] ([yshift=-0.5cm]tentative.south west) -- node [above] {\tiny{DAD}} ([yshift=-0.5cm] preferred.south west) ;

\draw [dashed, <->] ([yshift=-0.5cm]preferred.south west) -- node [above] {\tiny{Valid}} ([yshift=-0.5cm] novalid.south west) ;

</tikz>

La renumérotation d'une interface d'une machine consiste à passer d'une adresse à une autre. Lors d'une renumérotation, il n'est pas souhaitable de changer brusquement d'adresse, sinon toutes les communications TCP, qui l'utilisent comme identificateur de connexion, seraient immédiatement coupées. Ceci entraînerait des perturbations importantes au niveau des applications.

Pour faciliter cette transition, un mécanisme d'obsolescence est donc mis en place pour invalider progressivement une adresse. Ce mécanisme s'appuie sur la capacité d'affectation de plusieurs adresses valides à une même interface. Ensuite pour effectuer le choix de l'adresse à utiliser, un état est associé. Il indique dans quelle phase de sa durée de vie une adresse se situe vis à vis de l'interface. Le premier de ces états est qualifié de préféré : l'utilisation n'est aucunement restreinte. Peu avant son invalidation l'adresse passe dans un état de déprécié. Dans cet état, l'utilisation de l'adresse est déconseillée, mais pas interdite. L'adresse dépréciée ne doit plus être utilisée comme adresse de source pour les nouvelles communications (comme l'établissement de connexion TCP). Par contre l'adresse dépréciée peut encore servir d'adresse de source dans le cas des communications existantes. Les paquets reçus à une adresse dépréciée continuent à être remis normalement. Le contrôle de la durée de chaque état d'une adresse valide est effectué en ajoutant une durée de vie à l'état préféré.
La figure '''États successifs d'une adresse sur une interface''' représente les différents états que prend une adresse lorsqu'elle est allouée à une interface.

==Création de l'adresse lien-local==

<tikz title="Création de l'adresse lien-local">
\clip (0, 0) rectangle (10,7);
% \draw[help lines] (0,0) grid (10,7 );

\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,3)--(9,3);

\pgfputat{\pgfxy(0.8,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,5)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,3)--(1.5,5);
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (8,3)--(8,5);

\draw (1.5,4.5) node {\small{FE80::IID1}};
\draw (1.5,4) node {\small{$\alpha$::IID1/64}};

\draw (8, 4.5) node {\small{FE80::IID2}};

</tikz>
À l'initialisation de son interface, la machine construit un identifiant pour l'interface qui doit être unique au lien. Cet identifiant utilise l'adresse [[Identifiant_d'interface#EUI-64|EUI-64]]. Le principe de base de la création d'adresse IPv6 est de marier un préfixe avec l'identifiant. L'adresse lien-local est créée en prenant le préfixe lien-local (<tt>FE80::/64</tt>) qui est fixé. L'adresse ainsi constituée est encore interdite d'usage. Elle possède un état provisoire car la machine doit vérifier l'unicité de cette adresse sur le lien au moyen de la procédure de détection d'adresse dupliquée. Si la machine détermine l'adresse lien-local n'est pas unique, l'autoconfiguration s'arrête et une intervention manuelle est nécessaire.

Une fois que l'assurance sur l'unicité de l'adresse lien-local est obtenue, l'adresse provisoire devient une adresse valide pour l'interface. La première phase de l'autoconfiguration est achevée.

==<div id="DAD"> Détection d'adresse dupliquée </div>==

<tikz title="Emission d'un NS lors d'un DAD">
\clip (0, 0) rectangle (10,7);
% \draw[help lines] (0,0) grid (10,7 );

\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,3)--(9,3);

\pgfputat{\pgfxy(0.8,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,5)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,3)--(1.5,5);
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (8,3)--(8,5);

\draw (7.8, 5) -- (7.8, 3.2);
\draw [<->] (1, 3.2) -- node [above] {\tiny{::/0 -$>$ solicited (FE80:IID2) : NS (who has FE80::IID2?)}}(9, 3.2) ;

</tikz>
Pour vérifier l'unicité des adresses lien-local ou unicast, les machines doivent exécuter un algorithme de Détection d'Adresse Dupliquée (DAD) avant de les utiliser. L'algorithme utilise les messages ICMPv6 [[Découverte de voisins#NS|sollicitation d'un voisin]] et [[Découverte de voisins#NA|annonce d'un voisin]]. Si une adresse déjà en service est découverte, elle ne pourra être attribuée à l'interface. L'autoconfiguration s'arrête et une intervention humaine devient obligatoire. Une adresse est qualifiée de "provisoire" pendant l'exécution de l'algorithme DAD et ce jusqu'à la confirmation de son unicité. Une adresse provisoire est assignée à une interface uniquement pour recevoir les messages de sollicitation et d'annonce d'un voisin. Les autres messages reçus sont ignorés. L'algorithme DAD consiste à envoyer un message sollicitation d'un voisin avec dans le champ adresse de la cible l'adresse provisoire. Afin de distinguer l'algorithme DAD de celui de découverte des voisins, le paquet IPv6 contenant un message de sollicitation d'un voisin a comme adresse de source l'adresse indéterminée. Trois cas se présentent :

* Un message annonce d'un voisin est reçu : l'adresse provisoire est utilisée comme adresse valide par une autre machine. L'adresse provisoire n'est pas unique et ne peut être retenue.
* Un message sollicitation d'un voisin est reçu dans le cadre d'une procédure DAD; l'adresse provisoire est également une adresse provisoire pour une autre machine. L'adresse provisoire ne peut être utilisée par aucune des machines.
* Rien n'est reçu au bout d'une seconde (valeur par défaut) : l'adresse provisoire est unique, elle passe de l'état de provisoire à celle de valide et elle est assignée à l'interface.

A noter que cet algorithme n'offre pas une fiabilité absolue, notamment lorsque le lien est coupé.

== Autoconfiguration sans état ==

<tikz title="Emission d'un RS">
\clip (0, 0) rectangle (10,7);
% \draw[help lines] (0,0) grid (10,7 );

\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,3)--(9,3);

\pgfputat{\pgfxy(0.8,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,5)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,3)--(1.5,5);
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (8,3)--(8,5);

\draw (7.8, 5) -- (7.8, 3.2);
\draw [<->] (1, 3.2) -- node [above] {\tiny{FE80::IID2 -$>$ FF02::2 : RS }} (9, 3.2) ;

</tikz>

L'autoconfiguration sans état (RFC 2462) ne demande aucune configuration manuelle des machines, une configuration minimum pour les routeurs et aucun serveur supplémentaire. Elle se sert du protocole ICMPv6 et peut fonctionner sans la présence de routeurs. Elle nécessite cependant un sous-réseau à diffusion. Cette méthode ne s'applique que pour les machines et ne peut être retenue pour la configuration des routeurs. Le principe de base de l'autoconfiguration sans état est qu'une machine génère son adresse IPv6 à partir d'informations locales et d'informations fournies par un routeur. Le routeur fournit à la machine les informations sur le sous-réseau associé au lien, il donne le préfixe.

<tikz title="Réception d'un RA">
\clip (0, 0) rectangle (10,7);
% \draw[help lines] (0,0) grid (10,7 );

\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,3)--(9,3);

\pgfputat{\pgfxy(0.8,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,5)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,3)--(1.5,5);
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (8,3)--(8,5);

\draw [->] (1.7,5) -- (1.7, 3.2) -- node [above = 10pt] {\tiny{FE80::IID1 -$>$ FE80::IID2}} node [above] {\tiny{RA ($\alpha$::/64, DHCPv6, MTU=1500, HL=64, {bit {\tt M=1}) }}} (7.8, 3.2) -- (7.8, 5);

</tikz>

Comme pour la création de l'adresse lien-local, l'adresse unicast globale est obtenue en concaténant le préfixe avec l'identifiant de l'interface. Le préfixe provient du message d'annonce de routeurs et plus précisément de l'option «information sur le préfixe». Bien qu'il faille vérifier l'unicité de toutes les adresses unicast, dans le cas d'une adresse unicast obtenue par autoconfiguration sans état cela n'est pas obligatoire. En effet, l'unicité de l'identifiant de l'interface a déjà été contrôlé dans l'étape de création de l'adresse lien-local. L'identifiant étant le même, il n'y a plus aucune ambiguïté sur son unicité. L'adresse unicast globale constituée est aussi unique que celle lien-local.

La renumérotation des machines d'un lien s'effectue au moyen des routeurs qui passent les adresses utilisées dans un état déprécié et annoncent en même temps le nouveau préfixe. Les machines pourront recréer une adresse préférée.

===Cas des réseaux NBMA===

<tikz title="Off Link NDP: première étape">
\clip (0, 0) rectangle (11,7);
% \draw[help lines] (0,0) grid (10,7 );

\pgfputat{\pgfxy(4.5,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}
\pgfputat{\pgfxy(1.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[decorate,decoration={zigzag}, color=black!60, ->, very thick] (8,3)-- node [above, color=black] {\tiny{FE80::IID2 -$>$ FF02::2 : RS}} (5,5);

</tikz>

Les réseaux NBMA (''Non Broadcast Multiple Access'') se caractérisent par un absence de diffusion de tous vers tous, ce qui conduit à deux comportements possibles :
* absence totale de diffusion, comme dans les réseaux publics (téléphonique, ATM,...) où un seul correspondant peut être joint à la fois
* posssibilité de diffusion par un nombre restreint d'équipement comme par exemple les réseaux radio de type 3G, WiMAX où la station de base a la possibilité de diffuser des données vers tous les équipements tandis que l'inverse n'est pas possible.

<tikz title="Off Link NDP: Deuxième étape">
\clip (0, 0) rectangle (11,7);
% \draw[help lines] (0,0) grid (10,7 );

\pgfputat{\pgfxy(4.5,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}
\pgfputat{\pgfxy(1.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[decorate,decoration={zigzag}, color=black!60, ->, very thick] (5, 5)-- node [above, color=black] {\tiny{RA ($\alpha$::/64, DHCPv6, OffLink, MTU=1500, HL=64, {bit {\tt M=1}})}} (8,3);

</tikz>

Le comportement en réseau NBMA peut être également souhaité pour limiter les contraintes énergétiques. En effet, par exemple dans le cas des réseaux de capteurs, le multicast/broadcast est couteux en énergie puisque tous les équipements vont devoir traiter le message et certains devront le retransmettre.

<tikz title="Off Link NDP: Troisième étape">
\clip (0, 0) rectangle (11,7);
% \draw[help lines] (0,0) grid (10,7 );

\pgfputat{\pgfxy(4.5,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}
\pgfputat{\pgfxy(1.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[decorate,decoration={zigzag}, color=black!60, ->, very thick] (8,3)-- node [left, near start, color=black] {\tiny{$\alpha$::IID2 -$>$ $\alpha$::IID3 : DATA}} (5,5);

\draw[decorate,decoration={zigzag}, color=black!60, ->, very thick] (5,5)-- node [left, midway, color=black] {\tiny{$\alpha$::IID2 -$>$ $\alpha$::IID3 : DATA}} (2,3);

</tikz>

Pour ces cas de figures, le protocole de découverte de voisins possède un mode NBMA appelé également OffLink qui n'autorise le dialoque qu'avec un routeur. Les échanges commencent de la même manière :
* l'équipement qui souhaite s'insérer dans le réseau, émet en utilisant l'adresse de destination FF02::2 (tous les routeurs du lien), un message RS (Router Sollicitation). Le réseau NBMA devant envoyer ce message vers un routeur.
* Le routeur répond en positionnant le bit <tt>L</tt> (OffLink) à 1 dans l'option [[#information|Information sur le préfixe]], indiquant que tous les échanges devront passer par lui.
* L'équipement construit son adresse globale en concaténant le préfixe à son identifiant d'interface.
* L'équipement envoie systématiquement tous les paquets à l'adresse physique du routeur et celui-ci qui a une vision globale du réseau les réémet vers le bon destinataire.
<tikz title="Off Link NDP: Quatrième étape (optionnelle)">
\clip (0, 0) rectangle (11,7);
% \draw[help lines] (0,0) grid (10,7 );

\pgfputat{\pgfxy(4.5,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}
\pgfputat{\pgfxy(1.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[decorate,decoration={zigzag}, color=black!60, ->, very thick] (8,3)-- node [left, near end, color=black] {\tiny{$\alpha$::IID2 -$>$ $\alpha$::IID3 : DATA}} (5,5);

\draw[decorate,decoration={zigzag}, color=black!60, ->, very thick] (5,5)-- node [left, midway, color=black] {\tiny{$\alpha$::IID2 -$>$ $\alpha$::IID3 : DATA}} (2,3);

\draw[decorate,decoration={triangles}, color=black!60, ->, thick, ] (5,5) to [bend left] node [right, near start, color=black] {\tiny{REDIRECT $\alpha$::IID3 : MAC3}} (8,3);

\draw [color=black!60, ->, very thick, dotted] (8,3)-- node [above, midway, color=black] {\tiny{$\alpha$::IID2 -$>$ $\alpha$::IID3 : DATA}} (2,3);

</tikz>

* Si la technologie du lien le permet et si la politique de gestion du réseau l'autorise, le routeur a la possibilité d'optimiser le trafic en information l'équipement de la véritable adresse du destinataire. Le routeur émet un message d'[[#IR|indication de redirection]] (''ICMP Redirect'') pour informer l'équipement de l'adresse physique du destinataire. Les paquets suivants ne transiteront plus par le routeur central.

===Cas des réseaux Mobiles===

La duplication d'adresses est un processus relativement long puisqu'un equipement qui souhaite garantir l'unicité de son adresses doit être un message NS et attendre une absence de réponse. De plus, comme le réseau peut perdre les messages NS, un équipement peut tenter plusieurs fois de résoudre sa propre adresse avant de la garantir unique. Finalement, le processus se répète pour l'adresse lien-local et l'adresse globale. Il faut donc plusieurs secondes avant qu'un équipement puisse envoyer des paquets sur le réseau. En situation de mobilité, ce délais qui s'ajoute à ceux de la découverte des réseaux disponibles, à l'authentification peut conduire à des ruptures de connectivité (par exemple pour la voix sur IP).

Le RFC 4429 rend plus tolérant la détection d'adresse dupliquée en autorisant un site à utiliser son adresse bien qu'elle n'ait pas été encore garantie unique. Ce comportement est appelé DAD optimiste (''optimistic DAD''). L'état tentative de l'adresse (voir [[#Cycle de vie d'une adresse|Cycle de vie d'une adresse]] est remplacé par l'état optimiste pendant lequel l'unicité de l'adresse n'est pas garanti mais qui permet son utilisation. En parallèle, un DAD classique est lancé. les messages NS sont émis avec le bit O (Override) à 0 pour que les caches ND ne soit pas mis à jour au cas où cette adresse existerait déjà sur le réseau.

==Découverte du MTU==

<tikz title="Découverte du MTU première phase : envoi d'un paquet trop grand">
\clip (0, 0) rectangle (11,8);
%\draw[help lines] (0,0) grid (10,7 );

\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,2)--(9,2);

\pgfputat{\pgfxy(0.8,3)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,3)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,2)--(1.5,3);
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (8,2)--(8,3);

\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,4)--(1.5,5);
\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,5)--(9,5);
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (5.5,5)--(5.5,6);
\pgfputat{\pgfxy(5,6)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}
\draw (8, 3.6) node {\small{A}};
\draw (5.5, 6.6) node {\small{B}};
\draw (1.5, 3.6) node {\small{R}};

\draw (1.5,1.5) node {\small{MTU=1500}};
\draw (1.5,5.5) node {\small{MTU=1280}};

\draw (9.5, 3.5) node {\tiny{PMTU(*)=1500}};

\draw [<-] (1.7,3) -- (1.7, 2.2) -- node [above = 10pt] { \tiny{A-$>$ B Size=1500}} (7.8, 2.2) -- (7.8, 3);
}
</tikz>

Pour des considérations d'efficacité, il est généralement préférable que les informations échangées entre équipements soient contenues dans des datagrammes de taille maximale. Cette taille dépend du chemin suivi par les datagrammes et est égale à la plus grande taille autorisée par l'ensemble des liens traversés. Elle est de ce fait appelée PMTU, ou Path Maximum Transmission Unit (unité de transfert de taille maximale sur le chemin).

Initialement, l'équipement émetteur fait l'hypothèse que le PMTU d'un certain chemin est égal au MTU du lien auquel il est directement attaché. S'il s'avère que les paquets transmis sur ce chemin excèdent la taille maximale autorisée par un lien intermédiaire, alors le routeur associé détruit ces paquets et retourne un message d'erreur ICMPv6 de type «paquet trop grand», en y indiquant le MTU accepté. Fort de ces informations, l'équipement émetteur réduit le PMTU supposé pour ce chemin.

Plusieurs itérations peuvent être nécessaires avant d'obtenir un PMTU permettant à tout paquet d'arriver à l'équipement destinataire sans jamais excéder le MTU de chaque lien traversé. Le protocole IPv6 garantit que le MTU de tout lien ne peut descendre en dessous de 1 280 octets, valeur qui constitue ainsi une borne inférieure pour le PMTU. Ce protocole reposant sur la perte de paquets, il est laissé le soin aux couches supérieures de gérer la fiabilité de la communication en retransmettant si nécessaire (paquet 6 de l'exemple).
<tikz title="Découverte du MTU seconde phase: reception d'un message ICMPv6">
\clip (0, 0) rectangle (11,8);
%\draw[help lines] (0,0) grid (10,7 );

\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,2)--(9,2);

\pgfputat{\pgfxy(0.8,3)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,3)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,2)--(1.5,3);
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (8,2)--(8,3);

\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,4)--(1.5,5);
\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,5)--(9,5);
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (5.5,5)--(5.5,6);
\pgfputat{\pgfxy(5,6)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}
\draw (8, 3.6) node {\small{A}};
\draw (5.5, 6.6) node {\small{B}};
\draw (1.5, 3.6) node {\small{R}};

\draw (1.5,1.5) node {\small{MTU=1500}};
\draw (1.5,5.5) node {\small{MTU=1280}};

\draw (9.5, 3.5) node {\tiny{PMTU(*)=1500}};

\draw [->] (1.7,3) -- (1.7, 2.2) -- node [above = 10pt] { \tiny{R-$>$ A ICMP6 Error: Packet too big}} node [above] {\tiny{MTU=1280}} (7.8, 2.2) -- (7.8, 3);
\draw (9.5, 3) node {\alert{\tiny{PMTU(B)=1280}}};

</tikz>

Si la détermination du PMTU se fait essentiellement lors des premiers échanges entre les équipements concernés, elle peut également être revue en cours de transfert si, suite à un changement de route, un lien plus contraignant est traversé.

L'émetteur vérifie aussi que le PMTU n'a pas augmenté en envoyant de temps en temps un paquet plus grand. Si celui-ci traverse le réseau sans problème, la valeur du PMTU est augmentée.

Signalons enfin que l'algorithme de découverte du PMTU fonctionne indifféremment avec des échanges point-à-point ou multipoints. Dans ce dernier cas, le PMTU sera le PMTU minimal permis par l'ensemble des chemins vers chaque site destinataire du groupe de diffusion.

L'exploitation de l'information de PMTU se fait de plusieurs façons suivant l'endroit où les données à transmettre sont segmentées :

* si un protocole de type TCP est utilisé, celui-ci assurera la segmentation de façon transparente pour les applications, en fonction des informations de PMTU que pourra lui communiquer la couche IPv6.
* si un protocole de type UDP est utilisé, alors cette segmentation devra être assurée par une couche supérieure, éventuellement l'application. Il faut donc que celle-ci
** (1) puisse être informée du PMTU autorisé, même dans le cas où celui-ci change par la suite, et
** (2) puisse segmenter ses données en conséquence. Parce que ces deux conditions ne sont pas toujours réunies, IPv6 a conservé un mécanisme de fragmentation (voir [[IPv6_QO#Fragmentation|fragmentation]]).
<tikz title="Découverte du MTU troisième phase: Emission d'un paquet de taille correcte">
\clip (0, 0) rectangle (11,8);
%\draw[help lines] (0,0) grid (10,7 );

\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,2)--(9,2);

\pgfputat{\pgfxy(0.8,3)}{\pgfbox[left,base]{\pgfuseimage{router}}}
\pgfputat{\pgfxy(7.5,3)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}

\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,2)--(1.5,3);
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (8,2)--(8,3);

\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,4)--(1.5,5);
\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,5)--(9,5);
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (5.5,5)--(5.5,6);
\pgfputat{\pgfxy(5,6)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}
\draw (8, 3.6) node {\small{A}};
\draw (5.5, 6.6) node {\small{B}};
\draw (1.5, 3.6) node {\small{R}};

\draw (1.5,1.5) node {\small{MTU=1500}};
\draw (1.5,5.5) node {\small{MTU=1280}};

\draw (9.5, 3.5) node {\tiny{PMTU(*)=1500}};
\draw (9.5, 3) node {\alert{\tiny{PMTU(B)=1280}}};
\draw [<-] (1.7,3) -- (1.7, 2.2) -- node [above = 10pt] { \tiny{A-$>$ B Size=1280}} (7.8, 2.2) -- (7.8, 3);
\draw [->] (1.7,4) -- (1.7, 4.8) -- (5.3, 4.8) -- (5.3, 6);
</tikz>
Un deuxième aspect concerne l'identification des chemins afin de pouvoir y associer les informations de PMTU. Plusieurs possibilités, laissées à l'implémenteur, sont possibles. Un chemin peut être identifié par l'adresse destination, ou par l'identificateur de flux si celui-ci est utilisé, ou par la route suivie dans le cas où elle est imposée (voir [[Les extensions#Routage|routage]]).

Enfin, s'il est fortement recommandé que chaque équipement supporte le mécanisme de recherche du PMTU, ce n'est pas obligatoire. Ainsi, un équipement qui n'en dispose pas (par exemple une ROM de boot) devra restreindre la taille de tout paquet transmis au MTU minimal que doit supporter tout lien, soit 1280 octets.
{{Suivi|Table_des_matières|Début du chapitre|DHCPv6|DHCPv6}}

Protocolo de Descubrimiento de vecinos

2012-06-28T14:48:59Z

Jincera:

Protocolo de Descubrimiento de vecinos

2012-06-28T14:20:05Z

Jincera: /* Solicitud de un vecino */