Latest revision as of 00:44, 2 September 2012

Protocolo de descubrimiento de vecinos

Tabla de contenido

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.

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:

• 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):
  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):
  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):
  Mensaje de solicitud de parámetros de configuración por un cliente sin dirección.
• Confirmación DHCP (DHCP Confirm):
  Mensaje de solicitud de confirmación sobre la validez de los parámetros asignados al cliente.
• Renovación DHCP (DHCP Renew):
  Mensaje de solicitud para prolongar el uso de la dirección IP asignada.
• Reasignación DHCP (DHCP Rebind):
  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):
  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):
  Mensaje emitido por el cliente para notificar la liberación de las direcciones IP previamente asignadas por el servidor.
• Denegación DHCP (DHCP Decline):
  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):
  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):
  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):
  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.

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 FF02::01:02) 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 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 (FF05::1:3) 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.

Protocolo de descubrimiento de vecinos

Tabla de contenido

Implementación de la autoconfiguración