Protocolo DHCPv6 - Revision history

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

2012-09-01T23:44:22Z

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

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

2012-07-18T22:44:37Z

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

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

2012-07-18T22:28:32Z

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

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

2012-07-18T22:28:10Z

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

Jincera at 22:24, 18 July 2012

2012-07-18T22:24:09Z

Jincera: /* Formato de mensajes DHCPv6 */

2012-07-17T00:51:04Z

‎Formato de mensajes DHCPv6

Jincera: /* Formato de mensajes DHCPv6 */

2012-07-17T00:49:56Z

‎Formato de mensajes DHCPv6

Jincera at 00:47, 17 July 2012

2012-07-17T00:47:15Z

Jincera at 23:45, 12 July 2012

2012-07-12T23:45:09Z

Jincera at 18:00, 11 July 2012

2012-07-11T18:00:27Z

@@ Line 108: / Line 108: @@
 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.
+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}}

← Older revision		Revision as of 22:44, 18 July 2012
Line 103:		Line 103:

	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.		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}}		{{ eSuivi\| Protocolo de Descubrimiento de vecinos \|Protocolo de descubrimiento de vecinos \|Implementación de la autoconfiguración\|Implementación de la autoconfiguración}}

@@ Line 102: / Line 102: @@
 == 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.
+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}}

@@ Line 102: / Line 102: @@
 == 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.
+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}}

← Older revision		Revision as of 22:24, 18 July 2012
Line 100:		Line 100:
	\|}		\|}

		+	== 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}}		{{ eSuivi\| Protocolo de Descubrimiento de vecinos \|Protocolo de descubrimiento de vecinos \|Implementación de la autoconfiguración\|Implementación de la autoconfiguración}}

@@ Line 67: / Line 67: @@
 * 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).
+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.

@@ Line 59: / Line 59: @@
 * 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.
+* 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.

← Older revision		Revision as of 00:47, 17 July 2012
Line 33:		Line 33:

	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.		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}}		{{ eSuivi\| Protocolo de Descubrimiento de vecinos \|Protocolo de descubrimiento de vecinos \|Implementación de la autoconfiguración\|Implementación de la autoconfiguración}}

← Older revision		Revision as of 23:45, 12 July 2012
Line 22:		Line 22:
	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.		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.


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

← Older revision		Revision as of 18:00, 11 July 2012
Line 1:		Line 1:
	{{ eSuivi\| Protocolo de Descubrimiento de vecinos \|Protocolo de descubrimiento de vecinos \|Implementación de la autoconfiguración\|Implementación de la autoconfiguración}}		{{ 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 ==		==Principios ==