Protocolo ND de IPv6

IPv6 introduce el protocolo ND (Neighbor Discovery), tal como se describe en RFC 2461, Neighbor Discovery for IP Version 6 (IPv6).

Esta sección trata sobre las características siguientes del protocolo ND:

• Mensajes de ICMP del protocolo ND

• Proceso de configuración automática

• Solicitud e inasequibilidad de vecinos

• Algoritmo de detección de direcciones duplicadas

• Comparación del protocolo ND con ARP y protocolos relacionados con IPv4

Mensajes de ICMP del protocolo ND

El protocolo ND define cinco mensajes nuevos de ICMP (Internet Control Message Protocol). Dichos mensajes tienen los objetivos siguientes:

• Solicitud de enrutador: al activarse una interfaz, los hosts pueden enviar mensajes de solicitud de enrutador. Se solicita a los enrutadores que generen inmediatamente anuncios de enrutador, en lugar de hacerlo la próxima vez que se hubiera programado.

• Anuncio de enrutador: los enrutadores anuncian su presencia, así como varios parámetros de vínculos y de Internet. Los enrutadores anuncian de manera periódica o como respuesta a un mensaje de solicitud de enrutador. Los anuncios de enrutador contienen prefijos que se usan para la determinación de onlinks o configuración de direcciones, un valor de límite de salto propuesto, etcétera.

• Solicitud de vecino: los nodos envían mensajes de solicitud de vecino para determinar la dirección de capa de vínculo de un vecino. Los mensajes de solicitud de vecino también sirven para verificar que se pueda contactar con un vecino mediante una dirección de capa de vínculo almacenada en caché. Asimismo, las solicitudes de vecino se usan para detectar direcciones duplicadas.

• Anuncio de vecino: un nodo envía mensajes de anuncio de vecino como respuesta a un mensaje de solicitud de vecino. El nodo también puede enviar anuncios de vecino no solicitados para anunciar un cambio de dirección de capa de vínculo.

• Redirección: los enrutadores emplean mensajes de redirección para indicar a los hosts el mejor primer salto para acceder a un destino, o para indicar que el destino está en el mismo vínculo.

Proceso de configuración automática

Esta sección proporciona una descripción general de los pasos habituales que realizan las interfaces durante la configuración automática. La configuración automática se efectúa sólo en vínculos que permiten multidifusión.

1. Una interfaz que permite multidifusión se activa, por ejemplo, al iniciar el sistema de un nodo.

2. El nodo empieza el proceso de configuración automática generando una dirección local de vínculo para la interfaz.

   La dirección local de vínculo se forma a partir de la dirección MAC de la interfaz.

3. El nodo envía un mensaje de solicitud de vecino que contiene la dirección local de vínculo provisional como destino.

   La finalidad del mensaje es verificar que otro nodo del vínculo no esté utilizando ya la dirección de prueba. Tras verificarla, la dirección local de vínculo puede asignarse a una interfaz.

   1. Si la dirección propuesta ya la usa otro nodo, dicho nodo genera un anuncio de vecino para informar de ello.

   2. Si otro nodo intenta utilizar la misma dirección, dicho nodo también envía una solicitud de vecino para el destino.

      La cantidad de transmisiones y retransmisiones de solicitudes de vecino, así como el retraso entre solicitudes consecutivas, dependen de cada vínculo. Si es preciso, establezca estos parámetros.

4. Si un nodo determina que la dirección local de vínculo de prueba no es exclusiva, se detiene el proceso de configuración automática. De ser así, la dirección local de vínculo de la interfaz se debe configurar manualmente.

   Para simplificar la recuperación, puede especificar otro ID de interfaz que anule el predeterminado. De este modo, el mecanismo de configuración automática puede reanudar su funcionamiento con el nuevo ID de interfaz, que en principio es exclusivo.

5. Si un nodo determina que la dirección local de vínculo de prueba es exclusiva, el nodo la asigna a la interfaz.

   En ese momento, el nodo dispone de conectividad IP con nodos vecinos. Los demás pasos de la configuración automática los efectúan solamente hosts.

Obtención de un anuncio de enrutador

La fase siguiente de la configuración automática consiste en obtener un anuncio de enrutador o determinar que no hay enrutadores. Si hay enrutadores, éstos envían anuncios de enrutador para indicar la clase de configuración automática que debe ejecutar un host.

Los enrutadores envían periódicamente solicitudes de enrutador. No obstante, el retraso entre los sucesivos anuncios suele ser superior a lo que puede esperar un host que efectúa la configuración automática. Para obtener rápidamente un anuncio, el host envía una o varias solicitudes de enrutador al grupo multidifusión de todos los enrutadores.

Variables en la configuración de prefijos

Los anuncios de enrutador pueden contener también variables de prefijo con información que la configuración automática de direcciones emplea en la generación de prefijos. El campo de configuración automática de direcciones sin estado de los anuncios de enrutador se procesa de manera independiente. El indicador de configuración de direcciones, un campo de opción que contiene información de prefijo, indica si la opción se aplica también a la configuración automática sin estado. Si se aplica el campo de opción, otros campos de opciones contienen un prefijo de subred con valores continuamente vigentes. Estos valores indican la duración que tendrán la validez y preferencia de las direcciones creadas a partir del prefijo.

Debido a que los enrutadores generan periódicamente anuncios de enrutador, los hosts reciben anuncios nuevos de manera constante. Los hosts activados para IPv6 procesan la información que hay en cada anuncio. Los hosts se agregan a la información. También ponen al día la información recibida en anuncios anteriores.

Exclusividad de las direcciones

Por motivos de seguridad, antes de asignarse a la interfaz debe verificarse que todas las direcciones sean exclusivas. Es distinto en el caso de direcciones creadas con configuración automática sin estado. La exclusividad de una dirección la determina la parte de la dirección formada por un ID de interfaz. Por eso, si un nodo ya ha comprobado la exclusividad de una dirección local de vínculo, no hace falta verificar las direcciones adicionales una a una. Las direcciones deben crearse a partir del mismo ID de interfaz. Por su parte, debe comprobarse la exclusividad de todas las direcciones que se obtengan manualmente. Los administradores de sistemas de algunos sitios consideran que el esfuerzo y los recursos dedicados a detectar direcciones duplicadas son mayores que sus ventajas. En estos sitios, la detección de direcciones duplicadas se puede desactivar estableciendo un indicador de configuración según la interfaz.

Para acelerar el proceso de configuración automática, un host puede generar su propia dirección local de vínculo y verificar su exclusividad, mientras el host espera un anuncio de enrutador. Un enrutador podría retrasar durante unos segundos la respuesta a una solicitud de enrutador. Por lo tanto, el tiempo total que se necesita para completar la configuración automática puede ser considerablemente superior si los dos pasos se realizan en serie.

Solicitud e inasequibilidad de vecinos

El protocolo ND utiliza mensajes de solicitud de vecino para determinar si la misma dirección unidifusión tiene asignado más de un nodo. La detección de inasequibilidad de vecinos descubre el error de un vecino o de la ruta de reenvío del vecino. Esta clase de detección precisa la confirmación positiva de que los paquetes que se envían a un vecino lleguen realmente a su destino. Asimismo, la detección de inasequibilidad de vecinos determina que la capa IP del nodo procese correctamente los paquetes.

La detección de inasequibilidad de vecinos utiliza la confirmación a partir de dos puntos de referencia: los protocolos de capa superior y los mensajes de solicitud de vecino. Si es posible, los protocolos de capa superior brindan la confirmación positiva de que una conexión avanza en el reenvío. Por ejemplo, si se reciben reconocimientos de TCP, se confirma la correcta entrega de los datos enviados con anterioridad.

Si un nodo no obtiene una confirmación positiva de los protocolos de capa superior, dicho nodo envía mensajes de solicitud de vecino unidifusión. Estos mensajes solicitan anuncios de vecino como confirmación de asequibilidad a partir del próximo salto. Para reducir el tráfico redundante en la red, los mensajes sonda se envían sólo a los vecinos a los que el nodo esté enviando paquetes.

Algoritmo de detección de direcciones duplicadas

Para asegurarse de que todas las direcciones configuradas puedan ser exclusivas en un determinado vínculo, los nodos ejecutan en las direcciones un algoritmo de detección de direcciones duplicadas. Los nodos deben ejecutar el algoritmo antes de asignar las direcciones a una interfaz. El algoritmo de detección de direcciones duplicadas se ejecuta en todas las direcciones.

El proceso de configuración automática que se describe en esta sección detección de direcciones duplicadas sólo es válido para hosts, no para enrutadores. Debido a que la configuración automática de hosts emplea información anunciada por enrutadores, éstos se deben configurar por otros medios. Sin embargo, los enrutadores generan direcciones locales de vínculo mediante el mecanismo que se explica en este capítulo. Además, en principio los enrutadores deben superar correctamente el algoritmo de detección de direcciones duplicadas en todas las direcciones antes de asignar la dirección a una interfaz.

Anuncios de proxy

Un enrutador que acepta paquetes de parte de una dirección de destino puede ejecutar anuncios que no se anulan. El enrutador puede aceptar paquetes de parte de una dirección de destino que sea incapaz de responder a solicitudes de destino. En la actualidad no se especifica el uso de proxy. Ahora bien, el anuncio de proxy se puede utilizar para ocuparse de casos como nodos móviles que se han desplazado fuera del vínculo. El uso de proxy no se ha concebido como mecanismo general para controlador nodos que no implementen este protocolo.

Equilibrio de la carga entrante

Los nodos con interfaces duplicadas quizá deban equilibrar la carga de la recepción de paquetes entrantes en las distintas interfaces de red del mismo vínculo. Estos nodos disponen de varias direcciones locales de vínculo asignadas a la misma interfaz. Por ejemplo, un solo controlador de red puede representar a varias tarjetas de interfaz de red como una única interfaz lógica que dispone de varias direcciones locales de vínculo.

El equilibrio de carga se controla permitiendo que los enrutadores omitan la dirección local de vínculo de origen de los paquetes de anuncio de enrutador. Por consiguiente, los vecinos deben emplear mensajes de solicitud de vecino para aprender las direcciones locales de vínculo de los enrutadores. Los mensajes de anuncio de vecino devueltos pueden contener direcciones locales de vínculo diferentes, en función del que haya emitido la solicitud.

Cambio de dirección local de vínculo

Un nodo que sepa que se ha modificado su dirección local de vínculo puede enviar paquetes de anuncios de vecinos multidifusión no solicitados. El nodo puede enviar paquetes multidifusión a todos los nodos para actualizar las direcciones locales de vínculo almacenadas en caché que ya no sean válidas. El envío de anuncios no solicitados es una simple mejora del rendimiento. El algoritmo de detección de inasequibilidad de vecinos se asegura de que todos los nodos descubran la nueva dirección de manera fiable, aunque ello comporte un retraso algo mayor.

Comparación del protocolo ND con ARP y protocolos relacionados con IPv4

El funcionamiento del protocolo ND de IPv6 equivale a combinar los siguientes protocolos de IPv4: ARP (Address Resolution Protocol), ICMP (Internet Control Message Protocol), Router Discovery e ICMP Redirect. IPv4 carece de un protocolo general establecido y de un mecanismo para detectar la inasequibilidad de vecinos. Sin embargo, los requisitos de host especifican determinados algoritmos para la detección de portales inactivos. La detección de portales inactivos es un subconjunto de los problemas que soluciona la detección de inasequibilidad de vecinos.

En la lista siguiente se comparan el protocolo ND con el conjunto correspondiente de protocolos de IPv4.

• El descubrimiento de enrutador forma parte del conjunto básico de protocolos de IPv6. Los hosts de IPv6 no necesitan aplicar el comando snoop a los protocolos de enrutamiento para buscar un enrutador. IPv4 utiliza ARP, descubrimiento de enrutadores ICMP y redirección de ICMP para el descubrimiento de enrutador.

• Los anuncios de enrutador de IPv6 llevan direcciones locales de vínculo. Para resolver la dirección local de vínculo no hace falta un intercambio adicional de paquetes.

• Los anuncios de enrutador llevan los prefijos de sitio para un vínculo. No hace falta un mecanismo aparte para configurar la máscara de red, como sucede con IPv4.

• Los anuncios de enrutador permiten la configuración automática de direcciones. En IPv4 no se implementa la configuración automática.

• El protocolo ND permite que los enrutadores de IPv6 anuncien una unidad de transmisión máxima (MTU, Maximum Transmission Unit) para hosts para utilizarse en el vínculo. Por lo tanto, todos los nodos emplean el mismo valor de MTU en los vínculos que carecen de una MTU bien definida. Podría ser que los hosts de IPv4 de una misma red tuvieran distintas MTU.

• A diferencia de las direcciones de emisión IPv4, las multidifusiones de resolución de direcciones IPv6 se distribuyen en cuatro mil millones (2^32) de direcciones multidifusión, lo cual reduce significativamente las interrupciones por resolución de direcciones en nodos que no sean el de destino. Además, no es recomendable interrumpir sistemas que no sean IPv6.

• Las redirecciones de IPv6 contienen la dirección local de vínculo del primer salto nuevo. Al recibir una redirección no hace falta una resolución de direcciones aparte.

• Una misma red IPv6 puede tener asociados varios prefijos de sitio. De forma predeterminada, los hosts aprenden todos los prefijos de sitio locales a partir de anuncios de enrutador. Sin embargo, es posible configurar los enrutadores para que omitan todos o algunos prefijos de anuncios de enrutador. En esos casos, los hosts dan por sentado que los destinos se encuentran en redes remotas. Por lo tanto, los hosts envían el tráfico a enrutadores. Así pues, un enrutador puede ejecutar redirecciones si es preciso.

• A diferencia de IPv4, el destinatario de un mensaje de redirección de IPv6 da por sentado que el próximo salto nuevo se da en la red local. En IPv4, un host hace caso omiso de los mensajes de redirección que especifiquen un próximo salto que no se ubique en la red local, conforme a la máscara de red. El mecanismo de redirección de IPv6 es análogo a la función XRedirect de IPv4. El mecanismo de redirección es útil en vínculos de soportes compartidos y de no emisión. En esta clase de redes, los nodos no deben comprobar todos los prefijos de destinos de vínculo local.

• La detección de inasequibilidad de vecinos de IPv6 mejora la distribución de paquetes si hay enrutadores que funcionan mal. Esta capacidad mejora la distribución de paquetes en vínculos con particiones o que funcionan parcialmente mal. Asimismo, mejora la distribución de paquetes en nodos que modifican sus direcciones locales de vínculo. Por ejemplo, los nodos móviles pueden salir de la red local sin perder ninguna clase de conectividad debido a memorias caché de ARP que hayan quedado obsoletas. IPv4 carece de método equivalente para la detección de inasequibilidad de vecinos.

• A diferencia de ARP, el protocolo ND detecta errores parciales en vínculos mediante la detección de inasequibilidad de vecinos. El protocolo ND evita el envío de tráfico a vecinos si no existe conectividad bidireccional.

• Las direcciones locales de vínculo permiten la identificación exclusiva de enrutadores y los hosts de IPv6 mantienen las asociaciones de enrutador. La capacidad de identificar enrutadores es necesaria en anuncios de enrutador y mensajes de redirección. Los hosts deben mantener asociaciones de enrutador si el sitio emplea prefijos globales nuevos. IPv4 carece de un método equiparable para la identificación de enrutadores.

• Debido a que los mensajes de protocolo ND tienen un límite de salto de 255 en la recepción, dicho protocolo es inmune a ataques de spoofing provenientes de nodos que no están en el vínculo. Por el contrario, los nodos que no están en vínculos de IPv4 pueden enviar mensajes de redirección de ICMP. Asimismo, los nodos que no están en vínculos de IPv4 pueden enviar mensajes de anuncio de enrutador.

• La colocación de resolución de direcciones en la capa de ICMP hace que el protocolo ND sea más independiente en cuanto a soportes que ARP. por consiguiente, se pueden utilizar la autenticación IP y los mecanismos de seguridad estándar.