|
|
Procesos de Neighbor Discovery (Descubrimiento de vecino)
El protocolo ND (Neighbor Discovery o Descubrimiento de vecino) proporciona intercambios de mensajes para los siguientes procesos:
Para obtener información acerca de la configuración automática de direcciones, consulte "Configuración automática de direcciones". Para obtener información acerca de la determinación del salto siguiente, consulte "Algoritmo de host de envío".
Para facilitar interacciones entre nodos vecinos, en RFC 2461 se definen las siguientes estructuras de datos de host como ejemplo de cómo se puede almacenar información para procesos ND:
Almacena la dirección IP de vínculo de un vecino, su dirección de nivel de vínculo correspondiente y una indicación de la posibilidad de acceso al vecino. La caché de vecino equivale a la caché de ARP en IPv4.
Almacena información acerca de direcciones IP de salto siguiente o de reenvío para los destinos a los que se ha enviado tráfico recientemente. Las entradas de la caché de destino contienen la dirección IP de destino (local o remota), la dirección IP de salto siguiente resuelta anteriormente y la unidad MTU de ruta de acceso para el destino.
Enumera los prefijos del vínculo. Cada entrada de la lista de prefijos define un intervalo de direcciones IP para destinos a los que se puede tener acceso directo (vecinos). Esta lista se llena con prefijos anunciados por enrutadores en el mensaje Router Advertisement (Anuncio de enrutador).
Enumera direcciones IP que corresponden a enrutadores del vínculo que envían mensajes Router Advertisement y pueden ser enrutadores predeterminados.
En RFC 2461 se definen estas estructuras de datos como ejemplo de un modelo conceptual de host IPv6. No es necesaria una implementación de IPv6 para crear estas estructuras de datos exactamente, siempre y cuando el comportamiento externo del host sea coherente con las especificaciones de RFC 2461. Por ejemplo, la implementación de IPv6 de Microsoft Research e IPv6 Technology Preview para Windows 2000 utilizan una tabla de enrutamiento en lugar de una lista de prefijos y una lista de enrutadores predeterminados.
Resolución de direcciones
El proceso de resolución de direcciones para los nodos IPv6 consiste en el intercambio de mensajes Neighbor Solicitation (Solicitud de vecino) y Neighbor Advertisement (Anuncio de vecino) para resolver la dirección de nivel de vínculo de la dirección de salto siguiente en el vínculo para un destino dado. El host remitente envía un mensaje Neighbor Solicitation de multidifusión para la interfaz apropiada. La dirección de multidifusión del mensaje Neighbor Solicitation es la dirección de multidifusión de nodo solicitado derivada de la dirección IP de destino. El mensaje Neighbor Solicitation incluye la dirección de nivel de vínculo del host de envío en la opción Source Link-Layer Address (Dirección de nivel de vínculo de origen). Para obtener información acerca de cómo determina un host la dirección de salto siguiente para un destino, consulte "Algoritmo de host de envío".
Cuando el host de destino recibe el mensaje Neighbor Solicitation, actualiza su propia caché de vecino basándose en la dirección de origen del mensaje Neighbor Solicitation y la dirección de nivel de vínculo especificada en la opción Source Link-Layer Address. A continuación, el nodo de destino envía un anuncio de vecino de unidifusión al remitente del mensaje Neighbor Solicitation. El mensaje Neighbor Advertisement incluye la opción Target Link-Layer Address (Dirección de nivel de vínculo de destino).
Después de recibir el mensaje Neighbor Advertisement del destino, el host de envío actualiza su caché de vecino con una entrada para el destino basada en la información que se especifique en la opción Target Link-Layer Address. En este momento, se puede enviar tráfico IPv6 de unidifusión entre el host de envío y el destino del mensaje Neighbor Solicitation.
El Host A tiene la dirección MAC Ethernet 00-AA-00-11-11-11 y una dirección local de vínculo correspondiente FE80::2AA:FF:FE11:1111. El Host B tiene la dirección MAC Ethernet 00-AA-00-22-22-22 y una dirección local de vínculo FE80::2AA:FF:FE22:2222. Para enviar un paquete al Host B, el Host A debe utilizar la resolución de direcciones para resolver la dirección de nivel de vínculo del Host B.
A partir de la dirección IP del Host B, el Host A envía un mensaje Neighbor Solicitation (Solicitud de vecino) multidifusión de nodo solicitado a la dirección FF02::1:FF22:2222, tal como se muestra en la figura 53.
Figura 53 Solicitud de vecino multidifusión
para la resolución de direcciones
El Host B, que ha registrado la
dirección de multidifusión de nodo solicitado 33-33-22-22-22-22 con su
adaptador Ethernet, recibe y procesa la solicitud de vecino. El Host B responde
con un mensaje Neighbor Advertisement (Anuncio de vecino) de unidifusión, tal
como se muestra en la figura 54.
Figura 54 Anuncio de vecino de
unidifusión para la resolución de direcciones
Detección de dirección duplicada
Los nodos IPv4 utilizan mensajes ARP Request (Solicitud de ARP) y un método denominado ARP gratuito para detectar una dirección IP duplicada en el vínculo local. De forma similar, los nodos IPv6 utilizan el mensaje Neighbor Advertisement (Anuncio de vecino) para detectar el uso de direcciones duplicadas en el vínculo local.
Con la función ARP gratuito de IPv4, los campos Source Protocol Address (Dirección de protocolo de origen) y Target Protocol Address (Dirección de protocolo de destino) del encabezado del mensaje ARP Request se establecen en la dirección IPv4 cuya duplicación se está detectando. En la detección de direcciones duplicadas de IPv6, el campo Target Address (Dirección de destino) del mensaje Neighbor Solicitation (Solicitud de vecino) se establece en la dirección IPv6 cuya duplicación se está detectando.
La detección de direcciones duplicadas se diferencia de la resolución de direcciones en lo siguiente:
Cuando se recibe el anuncio de vecino multidifusión con el campo Target Address (Dirección objetivo) establecido en la dirección IP para la que se detecta la duplicación, el nodo deshabilita el uso de la dirección IP duplicada en la interfaz. Si el nodo no recibe un anuncio de vecino que impida el uso de la dirección IPv6, inicializa la dirección en la interfaz.
El Host B tiene una dirección local de vínculo FE80::2AA:FF:FE22:2222. El Host A intenta utilizar la dirección local de vínculo FE80::2AA:FF:FE22:2222. Sin embargo, antes de que el Host A pueda utilizar esta dirección local de vínculo, debe comprobar su unicidad a través de la detección de direcciones duplicadas.
El Host A envía un mensaje Neighbor
Solicitation de multidifusión de nodo solicitado a la dirección
FF02::1:FF22:2222, tal como se muestra en la figura 55.
Figura 55 Solicitud de vecino multidifusión para la detección de direcciones duplicadas
El Host B, que ha registrado la
dirección de multidifusión de nodo solicitado 33-33-22-22-22-22 con su
adaptador Ethernet, recibe y procesa la solicitud de vecino. El Host B detecta
que la dirección de origen es la dirección no especificada. Entonces, el Host B
responde con un mensaje Neighbor Advertisement (Anuncio de vecino) de
multidifusión, tal como se muestra en la figura 56.
Figura 56 Anuncio de vecino
multidifusión para la detección de direcciones duplicadas
Router Discovery (Descubrimiento de enrutadores)
El descubrimiento de enrutadores es el proceso mediante el cual los nodos intentan descubrir el conjunto de enrutadores del vínculo local. El descubrimiento de enrutadores en IPv6 es similar al proceso ICMP Router Discovery para IPv4, que se describe en RFC 1256.
Una diferencia importante entre el descubrimiento de enrutadores de ICMPv4 y de IPv6 es el mecanismo mediante el cual se selecciona un nuevo enrutador predeterminado cuando el actual deja de estar disponible. En el descubrimiento de enrutadores ICMPv4, el mensaje Router Advertisement incluye un campo Advertisement Lifetime (Tiempo de vida de anuncio). El tiempo de vida de anuncio es el tiempo tras el cual se puede considerar que el enrutador deja de estar disponible, cuando escucha su último mensaje Router Advertisement. En el peor de los casos, un enrutador puede dejar de estar disponible y los hosts no intentarán descubrir un nuevo enrutador predeterminado hasta que haya transcurrido el tiempo de Router Advertisement.
IPv6 tiene un campo Router Lifetime (Tiempo de vida de enrutador) en el mensaje Router Advertisement. Este campo indica el tiempo durante el cual el enrutador se puede considerar un enrutador predeterminado. Sin embargo, si el enrutador predeterminado actual deja de estar disponible, la condición se detecta a través del proceso de detección de inaccesibilidad a un vecino, en lugar de a través del campo Router Lifetime del mensaje Router Advertisement. Dado que la detección de inaccesibilidad a un vecino determina que ya no se puede tener acceso al enrutador, se elige inmediatamente un nuevo enrutador de la lista de enrutadores predeterminados. Para obtener más información, consulte "Detección de inaccesibilidad a un vecino".
Además de configurar un enrutador predeterminado, con el descubrimiento de enrutadores de IPv6 también se configura lo siguiente:
Los procesos de descubrimiento de enrutadores IPv6 son los siguientes:
El Host A tiene la dirección MAC Ethernet 00-AA-00-11-11-11 y una dirección local de vínculo correspondiente FE80::2AA:FF:FE11:1111. El Enrutador 1 tiene la dirección MAC Ethernet 00-AA-00-22-22-22 y una dirección local de vínculo correspondiente FE80::2AA:FF:FE22:2222. Para reenviar paquetes a destinos situados fuera del vínculo, el Host A debe descubrir la presencia del Enrutador 1.
El Host A envía un mensaje Router
Solicitation de multidifusión a la dirección FF02::2, tal como se muestra en la
figura 57.
Figura 57 Solicitud de enrutador
multidifusión para el descubrimiento de enrutadores y prefijos
El Enrutador 1, que ha registrado
la dirección de multidifusión 33-33-00-00-00-02 con su adaptador Ethernet,
recibe y procesa la solicitud de enrutador. El Enrutador 1 responde con un
mensaje Router Advertisement (Anuncio de enrutador) de unidifusión que contiene
parámetros de configuración y prefijos de vínculo local, tal como se muestra en
la figura 58.
Figura 58 Anuncio de enrutador
unidifusión para el descubrimiento de enrutadores y prefijos
Detección de inaccesibilidad a un vecino
La accesibilidad se define como la capacidad de enviar correctamente un paquete IPv6 al nodo vecino y que el paquete sea recibido y procesado correctamente por el nivel IPv6 del vecino. Para un nodo que envía un paquete a un enrutador, el paquete se entrega al nivel IPv6 del enrutador y, después, se reenvía al salto siguiente. Para un nodo que envía un paquete a un nodo vecino, el paquete se envía al nivel IPv6 del nodo. Es importante tener en cuenta que la definición de accesibilidad no implica la entrega en un nodo remoto a través de un enrutador, sólo al enrutador vecino.
Cuando un vecino está inaccesible, IPv6 detecta la situación e intenta corregirla. Para determinar si un vecino está accesible, IPv6 se basa en los protocolos de nivel superior que indican el progreso de la comunicación o en la recepción de un mensaje Neighbor Advertisement (Anuncio de vecino) enviado en respuesta a un mensaje Neighbor Solicitation (Solicitud de vecino) de unidifusión.
En el caso del tráfico de tipo TCP, el progreso de la comunicación se indica cuando se reciben nuevos datos o segmentos de confirmación de datos enviados. Para el tráfico de tipo UDP, puede que no haya indicación de progreso. En tal caso, el nodo envía mensajes Neighbor Solicitation (Solicitud de vecino) de unidifusión al vecino del salto siguiente para supervisar de forma continua la posibilidad de acceso al mismo.
Sólo se considera prueba de posibilidad de acceso la recepción de un mensaje Neighbor Advertisement que se ha solicitado. El mensaje Neighbor Advertisement solicitado, cuyo indicador Solicited (Solicitado) está establecido en el valor 1, sólo se envía en respuesta a un mensaje Neighbor Solicitation. Los mensajes Neighbor Advertisement o Router Advertisement (Anuncio de enrutador) no solicitados no se consideran pruebas de posibilidad de acceso.
El proceso de detección de imposibilidad de acceso a vecino permite detectar una posibilidad de acceso simétrica. En este caso, los paquetes deben ser capaces de viajar desde y hacia el nodo vecino. Cuando se envía un mensaje Neighbor Solicitation y se recibe un anuncio de vecino solicitado, se confirma la ruta de acceso entre ambos nodos. Para un mensaje Neighbor Advertisement o Router Advertisement no solicitados, sólo se confirma la ruta de acceso del nodo que envía el mensaje. Esto se denomina posibilidad de acceso asimétrica.
Para un nodo local específico, la posibilidad de acceso sólo es confirmada por el nodo que envía el mensaje Neighbor Solicitation y recibe el mensaje Neighbor Advertisement. El nodo que envía el mensaje Neighbor Advertisement no recibe ninguna confirmación de que dicho mensaje llegó al nodo previsto. Para que dos nodos vecinos determinen la posibilidad de acceso, cada uno de ellos debe intercambiar con el otro mensajes Neighbor Solicitation y Neighbor Advertisement.
La posibilidad de acceso de un nodo vecino se determina mediante al supervisar el estado de la entrada del nodo vecino en la caché del vecino. En RFC 2461 se definen los siguientes estados para una entrada de caché de vecino:
Se lleva a cabo en este momento la resolución de direcciones IPv6, en la que se utiliza una solicitud de vecino multidifusión de nodo solicitado. El estado INCOMPLETE se especifica cuando se crea una nueva entrada de caché de vecino, pero aún no tiene la dirección de nivel de vínculo correspondiente del nodo. El número de mensajes Neighbor Solicitation de multidifusión que se envían antes de abandonar el proceso de resolución de direcciones y quitar la entrada de caché de vecino se especifica mediante una variable que se puede configurar. RFC 2461 utiliza el nombre de variable MAX_MULTICAST_SOLICIT y recomienda un valor de 3.
La posibilidad de acceso se ha confirmado al recibir un mensaje Neighbor Advertisement de unidifusión solicitado. La entrada de caché de vecino permanece en estado REACHABLE hasta que transcurre el número de milisegundos que se indica en el campo Reachable Time (Tiempo de accesible) del mensaje Router Advertisement (Anuncio de enrutador).
El tiempo de posibilidad de acceso (desde que se recibió la confirmación de posibilidad de acceso) ha finalizado. La entrada de caché de vecino pasa al estado STALE después de que se anule el valor (milisegundos) del campo Reachable Time y se mantiene en ese estado hasta que se envía un paquete al vecino. El estado STALE también se especifica cuando se recibe un mensaje Neighbor Advertisement no solicitado que anuncia una dirección de nivel de vínculo.
Para que los protocolos de nivel superior tengan tiempo de proporcionar una confirmación de posibilidad de acceso antes de enviar mensajes Neighbor Solicitation, el estado de la caché de vecino cambia a DELAY y espera durante un período de tiempo que se puede configurar. En RFC 2461 se utiliza el nombre de variable DELAY_FIRST_PROBE_TIME y se recomienda un valor de 5 segundos. Si no se recibe ninguna confirmación de posibilidad de acceso durante el tiempo de retardo, la entrada pasa al estado PROBE (Sondeo) y se envía un mensaje Neighbor Solicitation de unidifusión.
La confirmación de posibilidad de acceso está en progreso para una entrada de caché de vecino que se encontraba en los estados STALE y DELAY. Los mensajes Neighbor Solicitation de unidifusión se envían a intervalos que corresponden al valor especificado en el campo Retrans Timer (Cronómetro de retransmisión) en el mensaje Router Advertisement recibido por el host. El número mensajes Neighbor Solicitation que se envían antes de abandonar el proceso de detección de posibilidad de acceso y quitar la entrada de caché de vecino se especifica mediante una variable que se puede configurar. En RFC 2461, se utiliza el nombre de variable MAX_UNICAST_SOLICITS y se recomienda un valor de 3.
En la figura 59 se muestra el diagrama de estados de una entrada en la caché de vecino.
Figura 59 Estados de una entrada de
caché de vecino
Si el vecino al que no se puede tener acceso es un enrutador, el host elige a otro enrutador de la lista de enrutadores predeterminados y lleva a cabo la resolución de direcciones y la detección inaccesibilidad.
Si un enrutador se convierte en host, debe enviar un mensaje Neighbor Advertisement de multidifusión con el indicador Router (Enrutador) configurado con el valor 0. Si un host recibe un mensaje Neighbor Advertisement de un enrutador en el que el indicador Router está establecido en el valor 0, el host quita el enrutador de la lista de enrutadores predeterminados y, si es necesario, elige otro enrutador.
Los enrutadores utilizan la función
de redirección para informar a los hosts de origen de un vecino más adecuado
para el primer salto al que se debe reenviar el tráfico para un destino
determinado. Existen dos casos en los que se utiliza la redirección:
1.
Un
enrutador informa a un host de origen de la dirección IP de un enrutador
disponible en el vínculo local que se encuentra "más próximo" al
destino. La "proximidad" se utiliza en el enrutamiento para alcanzar
el segmento de red de destino. Esta condición puede darse cuando hay varios
enrutadores en un segmento de red y el host de origen elige un enrutador
predeterminado que no resulta el más apropiado para llegar al destino.
2.
Un
enrutador informa a un host de origen de que el destino es un vecino (se
encuentra en el mismo vínculo que el host de origen). Esta condición puede
darse cuando la lista de prefijos de un host no incluye el prefijo del destino.
Como el destino no coincide con un prefijo de la lista, el host de origen
reenvía el paquete a su enrutador predeterminado.
En el proceso de redirección IPv6
se siguen los pasos que se describen a continuación:
1.
El
host de origen reenvía un paquete de unidifusión a su enrutador predeterminado.
2.
El
enrutador procesa el paquete y detecta que la dirección del host de origen
corresponde a un vecino. Además, detecta que la dirección del host de origen y
del salto siguiente se encuentran en el mismo vínculo.
3.
El
enrutador reenvía el paquete a la dirección de salto siguiente adecuada.
4.
El
enrutador envía un mensaje Redirect al host de origen. En el campo Target
Address (Dirección de destino) del mensaje Redirect se especifica la dirección
de salto siguiente del nodo a la que el host de origen debería enviar los
paquetes dirigidos al destino.
Para
los paquetes que se redirigen a un enrutador, el campo Target Address se
establece en la dirección local de vínculo del enrutador. Para los paquetes que
se redirigen a un host, el campo Target Address se establece en la dirección de
destino del paquete enviado inicialmente.
El
mensaje Redirect incluye la opción Redirected Header (Encabezado de
redirección). También puede incluir la opción Target Link-Layer Address (Dirección
de nivel de vínculo de destino).
5.
Al
recibir el mensaje Redirect, el host de origen actualiza la entrada de la
dirección de destino en la caché de destino con la dirección especificada en el
campo Target Address. Si se incluye la opción Target Link-Layer Address en el
mensaje Redirect, su contenido se emplea para crear o actualizar la entrada de
caché de vecino correspondiente.
Los mensajes Redirect sólo son enviados por el primer enrutador de la ruta de acceso entre el host de origen y el destino. Los hosts nunca envían mensajes Redirect y los enrutadores nunca actualizan las tablas de enrutamiento al recibir un mensaje Redirect.
El Host A tiene la dirección MAC Ethernet 00-AA-00-11-11-11 y la dirección local de vínculo correspondiente FE80::2AA:FF:FE11:1111. También tiene la dirección local de sitio FEC0::1:2AA:FF:FE11:1111/64. El Enrutador 1 tiene la dirección MAC Ethernet 00-AA-00-22-22-22 y la dirección local de vínculo correspondiente FE80::2AA:FF:FE22:2222. También tiene la dirección local de sitio FEC0::1:2AA:FF:FE22:2222/64. El Enrutador 2 tiene la dirección MAC Ethernet 00-AA-00-33-33-33 y la dirección local de vínculo correspondiente FE80::2AA:FF:FE33:3333. También tiene la dirección local de sitio FEC0::1:2AA:FF:FE33:3333/64. El Host A envía un paquete a un host situado fuera del vínculo a la dirección FEC0::2:2AA:FF:FE99:9999 (que no se muestra) y utiliza el Enrutador 1 como enrutador predeterminado. Sin embargo, el Enrutador 2 es el mejor enrutador para llegar al destino.
El Host A envía el paquete destinado a FEC0::2:2AA:FF:FE99:9999 al Enrutador 1, tal como se muestra en la figura 60.
Figura 60 Paquete de unidifusión
reenviado por el nodo de origen
El Enrutador 1 recibe el paquete del Host A y detecta que el Host A es un vecino. También detecta que el Host A y la dirección de salto siguiente para el destino se encuentran en el mismo vínculo. A partir del contenido de su tabla de enrutamiento local, el Enrutador 2 reenvía el paquete de unidifusión recibido del Host 2 al Enrutador 2, tal como se muestra en la figura 61.
Figura 61 Paquete de unidifusión
reenviado por el enrutador
Para informar al Host A de que los siguientes paquetes destinados a FEC0::2:2AA:EE:FE99:9999 se deben enviar al Enrutador 2, el Enrutador 1 envía un mensaje Redirect al Host A, tal como se muestra en la figura 62.
Figura 62 Mensaje Redirect (Redirección)
enviado por el enrutador