DHCPv6

El Protocolo de Configuración Dinámica de Hosts para IPv6 (DHCPv6) es un protocolo único para , cliente-servidor, definido en la RFC 3315 de la IETF, que proporciona una configuración administrada de dispositivos sobre IPv6.

Introducción

Aunque IPv6 resuelve la auto configuración de direcciones, lo cual es la principal motivación de DHCP en IPv4. DHCPv6^[1] aún tiene más sentido, ya que le brinda más control al administrador de la red sobre las asignaciones, así como mayor amplitud en la configuración de servicios de red.

DHCPv6 puede trabajar de forma conjunta con el mecanismo “stateless”. El administrador de red determina que procesos se van a emplear a través de los mensajes “RA” de ICMPv6. También permite a los clientes la solicitud de múltiples direcciones IPv6, que no era posible en IPv4 ni a través del mecanismo “stateless”.

DHCPv6 funciona sobre el protocolo de transporte UDP. El cliente utiliza una dirección link-local u otra determinada a través de otros mecanismos para transmitir y recibir los mensajes DHCPv6.

Los servidores DHCPv6 reciben mensajes de los clientes utilizando una dirección reservada multicast. Un cliente DHCPv6 transmite la mayoría de los mensajes a la dirección anteriormente mencionada por lo que no es necesario que el cliente sea configurado con dirección unicast del servidor DHCPv6.

Para permitir que un cliente DHCPv6 pueda enviar un mensaje a un servidor DHCPv6 al que no está unido por el mismo enlace deberá haber un agente DHCPv6 de retransmisión que se encargará de transmitir los mensajes entre cliente y servidor en ambos sentidos de la comunicación.

Una vez que el cliente ha determinado la dirección de un servidor, se podrá, bajo algunas circunstancias enviar mensaje directamente al servidor utilizando su dirección unicast.

Para solicitar la asignación de una o más direcciones IPv6 así como información de configuración , un cliente primero tiene que localizar al servidor DHCPv6 y luego hacer la petición al servidor para la asignación de dirección y otra información de configuración.

Constantes DHCPv6

Direcciones Multicast

All_DHCP_Relay_Agents_and_Servers (FF02::1:2). Una dirección link-local multicast usada por el cliente para comunicarse con los agentes de transmisión y servidores vecinos. Todos los servidores y agentes de restransmisión son miembros de este grupo multicast.
All_DHCP_servers (FF05::1:3). Una dirección site-local multicast, usado por los agentes de retransmisión para comunicarse con los servidores, ya sea porque quiere enviar el mensaje a todos los servidores o porque no conoce la dirección unicast de los servidores.

Puertos UDP

Clientes 546 UDP

Servidores y agentes de retransmisión 547 UDP

Tipos de Mensaje DHCPv6

La siguiente tabla muestra los tipos de mensaje DHCPv6 así como su función.

Nombre del Mensaje	Msg-type	Descripción
SOLICIT	1	Un cliente manda un mensaje SOLICIT para localizar servidores.
ADVERTISE	2	El servidor en un mensaje ADVERTISE para indicar que está disponible para el servicio, en respuesta al mensaje de solicitud recibido de un cliente.
REQUEST	3	Un cliente manda un mensaje REQUEST para solicitar los parámetros de configuración, incluyendo la dirección IP, de un servidor específico.
CONFIRM	4	Un cliente envía un mensaje CONFIRM a cualquier servidor disponible para determinar si las direcciones que se asignaron siguen siendo válidas.
RENEW	5	Un cliente manda un mensaje RENEW al servidor que originalmente proporcionó la dirección del cliente y los parámetros de configuración para extender los tiempos de vida en la dirección asignada y actualizar los parámetros de configuración.
REBIND	6	Un cliente envía el mensaje REBIND a cualquier servidor disponible para extender los tiempos de vida en la dirección asignada a los clientes y para actualizar otros parámetros de configuración. Este mensaje solo se envía cuando el cliente no obtiene respuesta del mensaje RENEW.
REPLY	7	Un servidor manda un mensaje de REPLY conteniendo las direcciones asignadas y los parámetros de configuración en respuesta a un mensaje SOLICIT, REQUEST, RENEW, REBIND recibido del cliente. También se manda este mensaje pero conteniendo únicamente los parámetros de configuración en respuesta a un mensaje INFORMATION-REQUEST. También se manda un mensaje REPLY en respuesta a un mensaje CONFIRM confirmando o denegando la validez de la dirección asignada al cliente que envía el mensaje CONFIRM. Y por último también se envía un mensaje de REPLY para realizar un asentimiento de recepción de los mensajes RELEASE y DECLINE.
RELEASE	8	Un cliente manda un mensaje de RELEASE al servidor que le asignó las direcciones IP para indicar que no usará más una o varias de las direcciones asignadas.
DECLINE	9	Un cliente envía un mensaje DECLINE para indicar al servidor que una o varias de las direcciones que tiene asignadas por el servidor están siendo utilizadas en el enlace en el que el cliente está conectado.
RECONFIGURE	10	Un servidor envía un mensaje de RECONFIGURE a un cliente para informarle de que el servidor tiene unos parámetros de configuración nuevos o actualizados, entonces el cliente iniciará una transacción RENEW/REPLY o INFORMATION-REQUEST/REPLY con el servidor para obtener la nueva configuración.
INFORMATION-REQUEST	11	Un cliente envía un mensaje INFORMATION-REQUEST al servidor para pedir los parámetros de configuración sin pedir ninguna dirección IP.
RELAY-FORW	12	Un agente de retransmisión envía un mensaje RELAY-FORWARDING al servidor, ya sea él mismo o a través de otro agente de transmisión. El mensaje recibido, a través de un cliente o a través de otro agente de retransmisión se encapsula en una opción del mensaje RELAY-FORWARDING.
RELAY-REPL	13	Un servidor envía un mensaje RELAY-REPLY un agente de retransmisión conteniendo el mensaje que el agente de retransmisión debe entregar al cliente. Este mensaje puede ser reenviado por varios agentes de retransmisión. El servidor encapsula el mensaje al cliente como una opción dentro del mensaje RELAY-REPLY.

Parámetros de Transmisión y Retransmisión

Parámetro	Valor por Defecto	Descripción
SOL_MAX_DELAY	1 s	Máximo retardo del primer mensaje SOLICIT
SOL_TIMEOUT	1 s	Tiempo inicial de espera del mensaje SOLICIT
SOL_MAX_RT	120 s	Máximo tiempo de espera del mensaje SOLICIT
REQ_TIMEOUT	1 s	Tiempo de espera inicial de un mensaje REQUEST
REQ_MAX_RT	30 s	Tiempo máximo de espera de un mensaje REQUEST
REQ_MAX_RC	10	Número máximo de reintentos del mensaje REQUEST
CNF_MAX_DELAY	1 s	Tiempo máximo de retardo del primer mensaje CONFIRM
CNF_TIMEOUT	1 s	Tiempo de espera inicial del mensaje CONFIRM
CNF_MAX_RT	4 s	Tiempo de espera máximo de un mensaje CONFIRM
CNF_MAX_RD	10 s	Duración máxima de un mensaje CONFIRM
REN_TIMEOUT	10 s	Tiempo de espera inicial del mensaje RENEW
REN_MAX_RT	600 s	Tiempo de espera máximo para un mensaje RENEW
REB_TIMEOUT	10 s	Tiempo de espera inicial para un mensaje REBIND
REB_MAX_RT	600 s	Tiempo de espera máximo para un mensaje REBIND
INF_MAX_DELAY	1 s	Retardo máximo del primer mensaje INFORMATION-REQUEST
INF_TIMEOUT	1 s	Tiempo de espera inicial para un mensaje INFORMATION-REQUEST
INF_MAX_RT	120 s	Tiempo máximo de espera del mensaje INFORMATION-REQUEST
REL_TIMEOUT	1 s	Tiempo de espera inicial del mensaje RELEASE
REL_MAX_RC	5	Máximo de intentos de mensaje RELEASE
DEC_TIMEOUT	1 s	Tiempo inicial de espera para el mensaje DECLINE
DEC_MAX_RC	5	Máximo intentos de mensaje DECLINE
REC_TIMEOUT	2 s	Tiempo de espera inicial del mensaje RECONFIGURE
REC_MAX_RC	8	Intentos máximos de enviar el mensaje RECONFIGURE
HOP_COUNT_LIMIT	32	Máximo número de saltos en un mensaje RELAY-FORWARD

Códigos de Estado

Código	Nombre
0	Success
1	UnspecFail
2	NoAddrAvail
3	NoBinding
4	NotOnLink
5	UseMulticast
6	NoPrefixAvail
7	UnknownQueryType
8	MalformedQuery
9	NotConfigured
10	NotAllowed
11	QueryTerminated
12-255	Sin Asignar

Formato de mensajes Cliente-Servidor

Todos los mensajes DHCPv6 enviados entre clientes y servidor comparten un formato de cabecera fijo e idéntico y un formato variable en el área de opciones. Las opciones se guardan seguidamente sin relleno entre ellas. En la siguiente figura se puede ver un diagrama de la composición de dicho mensaje en el que se pueden identificar los siguientes campos:

Tipo de mensaje. Identifica el tipo de mensaje DHCP.
Identificador de transacción. Número identificativo de un intercambio de mensajes.
Opciones. Este campo es variable.

Formato de mensaje DHCPv6 entre cliente y servidor

Formato de mensajes entre Agentes de Retransmisión Y Servidores

Los agentes de retransmisión intercambian mensajes con servidores para retransmitir mensajes entre servidores y clientes que no están conectados en el mismo enlace.

Formato de mensaje entre agentes de retransmisión DHCPv6

Hay dos tipos de mensajes de agente de retransmisión , pero ambos comparten el mismo formato:

Tipo de mensaje. RELAY-FORW o RELAY-REPL
Link-address. Una dirección global o site-local que será usada por el servidor para identificar el enlace en el que se encuentra el cliente.
Peer-address. La dirección del cliente o del agente de retransmisión desde el que se recibió el mensaje que tiene que ser retransmitido.
Opciones. Debe incluir una opción llamada “Relay Message Options”, y además puede incluir otras opciones.

Identificador Único DHCP (DUID)

Cada cliente DHCPv6 o servidor DHCPv6 tiene un DUID. Los servidores DHCPv6 usan DUIDs para identificar a los clientes para la selección de parámetros de configuración y para asociar las IAs con los clientes. Los clientes usan DUIDs para identificar al servidor en mensajes en los que el servidor debe ser identificado.

Tanto cliente como servidor tratan los DUIDs como valores opacos y sólo deben compararlos por igualdad. Ambos en ningún caso interpretan los DUIDs. El DUID es transportado en el campo opciones ya que tiene una longitud variable y no se requiere en todos los mensajes DHCPv6.

El DUID consiste en un campo de dos octetos representando el tipo de código seguido por un número variables de octetos que representan el identificador real. Un DUID no puede ser más largo de 128 bytes (sin incluir el tipo de código).

Asociación de Identidad (IA)

Una asociación de identidad (IA) es una construcción a través de la cual un servidor y un cliente pueden identificar, agrupar y gestionar un conjunto de direcciones IPv6 relacionadas. Cada IA consiste en un IAID (Identificador de Asociación de Identidad) y la información de configuración asociada.

Un cliente debe asociar al menos una IA distinta para cada uno de sus interfaces de red para los que está pidiendo la asignación de direcciones IPv6 por el servidor DHCPv6. El cliente utiliza la IA asignada a una interfaz para obtener la información de configuración desde el servidor para esa interfaz. Cada IA debe de estar asociada única y exclusivamente con una sola interfaz.

El IAID identifica de forma única a la IA y debe ser elegido para ser único entre los IAIDs en el cliente. El IAID es elegido por el cliente. Para cualquier uso de una IA por parte del cliente el IAID para esa IA debe ser consistente cuando se reinicie el cliente DHCPv6, para lo cual el cliente debe de almacenarlo en una memoria no volátil o usar un algoritmo que haga que el IAID generado cada vez que se reinicia el cliente DHCPv6 coincida con el anterior siempre y cuando la configuración no haya cambiado.

Selección de direcciones para asignar a una IA

Un servidor selecciona direcciones para ser asignadas a un IA de acuerdo con la política de asignación de direcciones determinada por el administrador del servidor y la información específica que el servidor determina sobre el cliente de alguna combinación de las siguientes opciones:

El enlace al que está conectado el cliente. El servidor determina el enlace de la siguiente manera:
- Si el servidor recibe el mensaje directamente desde el cliente y la dirección de origen en el datagrama IP que se ha recibido es una dirección link-local, entonces significa que el cliente está en el mismo enlace que la interfaz del servidor que ha recibido el mensaje.
- Si el servidor recibe el mensaje reenviado por una agente de retransmisión , entonces el cliente está en el mismo enlace que la interfaz indicada en el campo link-address del mensaje proveniente del agente de retransmisión.
- Si el servidor recibe el mensaje directamente desde el cliente y la dirección origen del datagrama IP que está en el mensaje que se ha recibido no es una dirección link-local entonces el cliente esta en un enlace identificado por la dirección de origen en el datagrama IP.
El DUID suministrado por el cliente.
Otra información de opciones suministrado por el cliente.
Otra información suministrado por el agente de retransmisión en el campo opciones

Gestión de Direcciones Temporales

Un cliente puede pedir la asignación de una dirección temporal (RFC 3041). El manejo que hace DHCPv6 de la asignación de estas direcciones no es diferente al del resto de direcciones. Los clientes piden direcciones temporales y el servidor DHCPv6 se las asigna. Las direcciones temporales se encapsulan en la opción de Asociación de Identidad para Direcciones Temporales (IA_TA). Cada IA_TA contiene como máximo una dirección temporal para cada uno de los prefijo en el enlace al que el cliente está conectado.

Solicitud de Servidor DHCPv6

El cliente es responsable de crear IAs y de pedir que el servidor le asigne direcciones IPv6 para la IA, primero crea una IA y le asigna un IAID. Después envía un mensaje SOLICIT conteniendo la opción IA describiendo la IA.

Un cliente utiliza el mensaje SOLICIT para descubrir servidores DHCP configurados para asignar direcciones o devolver otros parámetros. El primer mensaje de petición por parte del cliente en la interfaz debe de ser retrasado por un periodo de tiempo aleatorio entre 0 y SOL_MAX_RT. El servidor por otro lado enviará mensajes ADVERTISE en respuesta a un mensaje SOLICIT válido recibido anunciando la disponibilidad del servidor para el cliente.

El servidor puede añadir una opción Preferencia para llevar el valor de preferencia en el mensaje ADVERTISE. Si no se añade ninguno se le asignara un valor por defecto de 0.El servidor incluye opciones que más adelante podrá retornar al cliente en un mensaje REPLY. Esta información puede ser usada por el cliente para elegir un mensaje ADVERTISE cuando tiene más de uno.

Si el mensaje SOLICIT recibido del cliente contiene una o más opciones IA, el servidor debe incluir estas mismas opciones en el mensaje ADVERTISE conteniendo las direcciones que serían asignadas a dichas IAs. Si el servidor no pudiera asignar direcciones a cualquiera de las IAs recibidas en los siguientes mensajes de REQUEST deberá enviar un mensaje ADVERTISE al cliente incluyendo solo una opción de código de estado con valor NoAddrsAvail. Cuando el cliente reciba este ADVERTISE automáticamente lo descartará. El mensaje ADVERTISE debe transmitirse siempre de manera unicast en el enlace donde el mensaje SOLICIT fue recibido.

El cliente recogerá los mensajes ADVERTISE durante los primeros RT segundos, a menos que reciba un mensaje ADVERTISE con un valor de preferencia de 255. Si recibe dicho ADVERTISE inmediatamente inicia el intercambio de mensajes enviando un mensaje REQUEST al servidor que le mandó el mensaje ADVERTISE con preferencia 255. Si no recibe dicho mensaje pero tiene otros mensaje ADVERTISE cuando pase el tiempo RT entonces elegirá uno de ellos sobre la base de los siguientes criterios:

Los mensajes ADVERTISE que tengan el valor de preferencia de servidor más alto son preferibles al resto.
Dentro de un grupo de mensajes ADVERTISE con el mismo número de preferencia de servidor, el cliente puede elegir en función de la información que traiga el mensaje y elegir el de más interés para él.
El cliente puede elegir el servidor menos preferido si ese servidor tiene un mejor conjunto de parámetros anunciados, como las direcciones disponibles anunciadas en los IAs.

Después de elegir comenzará el intercambio de mensajes con dicho servidor enviando un mensaje REQUEST.

En caso de no tener ningún mensaje ADVERTISE transcurrido el tiempo RT se procederá a iniciar el proceso de retransmisión que finalizará cuando se obtenga un mensaje ADVERTISE.

Si el cliente ha incluido la opción Rapid Commit en el mensaje SOLICIT, el servidor responderá con un mensaje REPLY con una opción Rapid Commit en él y no con un mensaje ADVERTISE como hemos visto anteriormente. El cliente descartará todos los paquetes REPLY que vengan sin la opción Rapid Commit.

Intercambio de Configuración DHCPv6 iniciado por el cliente

Un cliente inicia un intercambio de mensajes con el servidor o servidores para adquirir o actualizar información de configuración de interés. También puede iniciar el intercambio de configuración como parte de un proceso de configuración de un sistema operativo, cuando sea requerido por la capa de aplicación o la configuración de direcciones sin estado o se requiera extender el tiempo de vida de una dirección.

Intercambio de Mensajes DHCPv6 iniciado desde el Cliente

El cliente usa los mensajes REQUEST, RENEW, REBIND, RELEASE y DECLINE durante el ciclo de vida normal de una dirección. También se usa el mensaje CONFIRM para validar la dirección cuando el cliente se ha movido a un nuevo enlace. Por último se utiliza el mensaje INFORMATION-REQUEST cuando se necesita información de configuración pero no una dirección.

Request

El cliente DHCP usa el mensaje REQUEST para rellenar IAs con direcciones y obtener además otra información de configuración. Esto se lleva a cabo incluyendo en el campo opciones del mensaje DHCP opciones IA. El servidor devolverá las direcciones y la información de configuración en los campos de opción IA en el mensaje de REPLY.

En este mensaje REQUEST incluye:

La opción Identificador del Cliente para identificarse con el servidor.
La identificación del servidor se incluye en la opción Identificador de Servidor.
La opción Request Option indica al servidor que opciones está interesado en recibir el cliente.

También puede incluir una opción Reconfigure Accept indicando si el cliente está apto o no para recibir mensaje RECONFIGURE desde el servidor.

Si el servidor se da cuenta de que algún prefijo en una o más direcciones IP proporcionadas por el cliente a través de las IAs no son apropiadas con el enlace mandará un mensaje REPLY con el código de estado NotOnLink.

Por otro lado, si el servidor no puede asignar alguna dirección a cualquier IA incluido en el mensaje del cliente responderá con un mensaje REPLY con el código de estado NoAddrAvail.

Para cada IA que el servidor pueda asignar direcciones, incluirá dicha IA con las direcciones y si se diera el caso algunos otros parámetros de configuración.

Confirm

Cada vez que un cliente pueda haberse movido a un nuevo enlace los prefijos asignados a las interfaces pueden no ser ya apropiados para el enlace en el que el cliente está ahora conectado.

Para comprobar si esto sucede el cliente debe de empezar un intercambio de mensajes CONFIRM/REPLY. Se incluye en este mensaje cualquier IA asignada a la interfaz que haya podido cambiarse a otro enlace, incluyendo las direcciones asociadas a esos IAs. Cualquier respuesta del servidor indica cual de esas direcciones siguen siendo apropiadas para enlace en que ahora están conectadas las interfaces a las que pertenecen.

Cuando el servidor recibe este mensaje determina que direcciones son apropiadas para el enlace en el que el cliente está conectado. Si todas las direcciones aprueban se retorna un mensaje REPLY con estado Success. Si cualquiera de las direcciones no pasa el test se manda un mensaje REPLY con estado NotOnLink.

Renew

Para extender el tiempo de vida de una dirección asociada con un IA el cliente envía un mensaje RENEW al servidor del que obtuvo la dirección en cuestión.

Se debe incluir en el mensaje la dirección dentro de la opción IA que se encuentra dentro del campo de opciones del mensaje DHCPv6. El servidor determina el nuevo tiempo de vida para la dirección de acuerdo con su configuración administrativa. También puede añadir dentro del mismo mensaje nuevas direcciones al IA.

Por otro lado también las puede borrar poniendo el tiempo de vida a 0. El servidor controla el periodo de tiempo en el que los servidores deben de solicitar la extensión del tiempo de vida de una determinada dirección a través de los parámetros T1 y T2 asignados a una IA.

Cuando un servidor recibe un mensaje RENEW que contiene un IA del cliente, localiza el registro de ese cliente y verifica que la información que facilita ese cliente concuerda con la que él tiene almacenada. Si el resultado de esa comprobación es negativo el servidor envía un mensaje REPLY con estado NoBinding. Si por el contrario es positiva el servidor envía de vuelta el IA al cliente con nuevos tiempos de vida y tiempos T1 y T2.

Rebind

Cuando se cumple el tiempo T2 para una IA, que solo se cumplirá cuando un mensaje RENEW no obtenga respuesta, el cliente inicia un intercambio de mensajes REBIND/REPLY a cualquier servidor disponible.

En caso de no obtener respuesta tampoco por esta vía el cliente tendría otras opciones como por ejemplo:

Puede elegir utilizar un mensaje SOLICIT para intentar localizar nuevos servidores DHCPv6 y enviar un mensaje REQUEST para los IA expirados.
El cliente puede tener otras direcciones en otras IAs, por lo que puede elegir otra IA y descartar la dirección que ha agotado su tiempo de vida.

Al igual que en el caso anterior el servidor busca el registro del cliente que le ha enviado el mensaje REBIND incluyendo el IA. Si no se encuentra el registro y además el servidor considera que la dirección no es apropiada en el enlace al que el cliente está conectado envía el IA de vuelta con un tiempo de vida de 0, esto hará que el cliente descarte la dirección.

Si por el contrario encuentra el registro envía el nuevo tiempo de vida y los tiempos T1 y T2 en la IA del mensaje REPLY.

Information-Request

El cliente utiliza un mensaje INFORMATION-REQUEST para obtener información de configuración sin tener direcciones asignadas a él.El cliente debe incluir el Identificador de Cliente en las opciones para identificarse frente al servidor. Si el cliente no incluye este identificador el servidor no podrá enviar ninguna opción especifica para el cliente, por lo que el servidor decidirá no responder al mensaje.

Debe añadir también en el campo de opciones las configuraciones que está interesado en recibir. Cuando el servidor recibe este mensaje determina todos los parámetros de configuración apropiados para el cliente basándose en las políticas de configuración del servidor.

Release

Para liberar una o más direcciones el cliente envía un mensaje RELEASE al servidor.El cliente debe incluir el Identificador de Cliente en las opciones para identificarse frente al servidor. Se incluyen además las direcciones que se tienen que liberar en las IAs en el campo de opciones.

El cliente no puede usar una de las direcciones que quiere liberar para enviar el mensaje de RELEASE al servidor. Debido a que el mensaje de RELEASE se puede perder, el cliente debe retransmitir este mensaje si no se recibe un mensaje REPLY del servidor.

Una vez que el servidor recibe un mensaje RELEASE correcto examina los IAs y las direcciones dentro de ellos para validarlas. Si el servidor constata a través de su registro que esas direcciones están asignadas a ese cliente y que fue él el que las asignó las borra de las IAs de ese cliente y las pone las direcciones disponibles para otros clientes. Después de esto el servidor envía un mensaje REPLY con código de estado Success.

Decline

Si un cliente detecta que una o más direcciones que le han sido asignadas están siendo usadas por otro nodo envía un mensaje DECLINE al servidor para informar de que la dirección es sospechosa.

Cuando el servidor recibe un mensaje DECLINE, al igual que en el caso anterior, el servidor examina la dirección y si concuerda con la que él tiene asociada al registro de ese cliente y ha sido asignada por él las borra de los IAs que el cliente haya mandado en el mensaje DECLINE. Cuando este proceso se ha terminado el servidor envía un mensaje REPLY con código de estado Success.

Intercambio de configuración DHCPv6 iniciado por el Servidor

Un servidor inicia un intercambio de configuración para que los clientes DHCPv6 obtengan nuevas direcciones o nuevos parámetros de configuración. Esto ocurre cuando por ejemplo el servidor cambia de localización, se añade un nuevo servicio, etc.

Intercambio de Mensajes DHCPv6 iniciado desde el Servidor

Reconfigure

Un servidor envía un mensaje RECONFIGURE para provocar que los clientes inicien un intercambio de mensajes RENEW/REPLY o INFORMATION-REQUEST/REPLY con él.

El servidor crea el mensaje RECONFIGURE y en el campo de opciones coloca su identificador a través del valor de su DUID y el identificador del cliente para el que va destinado este mensaje a través de su DUID. También puede incluir la opción Request para decirle al cliente por qué opciones debe preguntar en un próximo mensaje RENEW o INFORMATION-REQUEST.

Debido al riesgo de sufrir un ataque de denegación de servicio contra los clientes DHCPv6 es obligatorio el uso de la autenticación DHCP en el mensaje RECONFIGURE. El servidor enviará este mensaje mediante la dirección UNICAST del cliente. En caso de que no tuviera la dirección para acceder directamente al cliente creará un mensaje RELAY-REPLY para enviar el mensaje Reconfigure a través de un agente de Retransmisión.

En caso de tener que enviar el mensaje a más de un cliente el servidor enviará un mensaje por cliente. Si no se recibe respuesta a este mensaje Reconfigure por parte del cliente en REC_TIMEOUT se retransmitirá el mensaje y se doblará el valor de esa variable, si sigue sin haber respuesta se repetirá este proceso hasta que se alcance el tiempo REC_MAX_RC a partir del cual se considerará fracasado el intento de mandar el mensaje RECONFIGURE y se abortará.

Cuando el cliente reciba este mensaje RECONFIGURE responderá con un mensaje RENEW o INFORMATION-REQUEST dependiendo de lo que el servidor le haya mandado en el mensaje, mientras que se está realizando el proceso de Renew o Information-Request el cliente descartará todos los mensajes RECONFIGURE que le lleguen. El proceso que inicia el cliente ha sido definido ya en el apartado anterior.

Agentes de Retransmisión DHCPv6

Cuando un agente de retransmisión recibe un mensaje del cliente para ser retransmitido construye un mensaje RELAY-FORWARD, copia la dirección origen IP del datagrama que ha recibido en el campo Peer-Address, copia además el mensaje DHCPv6 recibido en la opción Relay Message del nuevo mensaje creado y coloca la opción Hop Limit a 32.

El agente de retransmisión coloca una dirección global o site-local con el prefijo asignado al enlace donde el cliente está solicitando una dirección en el campo link-address del mensaje RELAY-FORWARD y coloca el valor del hop-count a 0 y retrasmite el mensaje.

Intercambio de Mensajes DHCPv6 a través de Agentes de Retransmisión

Si el mensaje recibido por el agente de retransmisión es un mensaje RELAY-FORWARD con un Hop-count menor que el límite(en caso contrario lo descartaría) copia la dirección de origen del datagrama IP que ha recibido y la coloca en el campo Peer-address sube una unidad al hop-count y retransmite el mensaje.

Cuando el servidor recibe un mensaje del cliente a través de un mensaje RELAY-FORWARD crea un mensaje RELAY-REPLY para responder al cliente. Esta respuesta debe de estar retransmitida por los mismos agentes de retransmisión que transmitieron el mensaje del cliente.

Esto se hace así ya que el servidor crea un mensaje anidado, es decir el mensaje RELAY-REPLY para el primer agente de retransmisión al que se va enviar contiene una opción llamada Relay Message que contiene el mensaje para el siguiente agente de retransmisión y así sucesivamente hasta que se llegue al cliente.

En vista de esto cuando un agente de retransmisión recibe un mensaje RELAY-REPLY procesa todas las opciones contenidas en el mensaje incluida la opción Relay Message donde está el mensaje a reenviar. Extrae el mensaje y lo retransmite a la dirección contenida en el campo Peer-Address de dicho mensaje extraído.

Autenticación de mensajes DHCPv6

Para evitar ataques de denegación de servicio frente a clientes o de desconfiguración intencionada o incluso para restringir la asignación de direcciones a equipos conocidos para evitar ataques en redes en las que el medio físico no está protegido como por ejemplo en una red WiFi se emplea el mecanismo de autenticación DHCPv6 que está basado en el diseño de autenticación para DHCPv4.

La autenticación de mensajes DHCPv6 se consigue mediante el uso de la opción Authentication. La información transportada en esta opción se puede utilizar para identificar de forma fiable el origen de un mensaje DHCPv6 y para confirmar que el contenido del mensaje DHCPv6 no ha sido manipulado. Cualquier mensaje DHCPv6 no debe incluir más de una opción de autenticación.

Seguridad de mensajes enviados entre Servidores y Agentes de Retransmisión

Los agentes de retransmisión y los servidores que intercambian mensajes de manera segura utilizan los mecanismos de IPsec para IPv6. Si un mensaje del cliente es retransmitido por varios agentes de retransmisión cada uno de los agentes debe tener relaciones de confianza establecidas por pares independientes.

Detección de Repeticiones

El campo Método de Detección de Repeticiones (RDM) determina el tipo de detección de repetición usado en el campo Replay Detection. Usar un valor cambiante, como por ejemplo la hora exacta puede reducir el peligro de los ataques de repetición.

Protocolo de Autenticación Retardada

Si el valor del campo de protocolo es 2 de la opción Authenticate el mensaje está usando el mecanismo “Delayed Authentication”. En este mecanismo el cliente pide autenticación en su mensaje SOLICIT, y el servidor responde con un mensaje ADVERTISE que contiene información de autenticación. Esta información de autenticación contiene un reto generado por el origen como un código de autenticación de mensaje (MAC) para proporcionar autenticación de mensaje y autenticación de la entidad.

El emisor del mensaje calcula el MAC utilizando el algoritmo de generación HMAC y la función de hash MD5. El mensaje DCPHv6 entero (poniendo el campo MAC en la opción de autenticación a 0) incluyendo la cabecera y el campo de opciones se usa como entrada de la función HMAC-MD5.

El receptor del mensaje calcula el HMAC-MD5 como lo hizo el emisor del mensaje y si concuerdan valida el mensaje y en caso contrario, lo descarta.

Cada cliente DHCPv6 tiene un conjunto de claves. Cada clave está identificada por <DHCP realm, DUID cliente, key-id>. Cada clave tiene un tiempo de vida limitado, por lo que no debe ser usada una vez haya pasado este tiempo.

El cliente y el servidor usan una de esas claves del cliente para autenticar los mensajes DHCPv6 durante un intercambio de mensajes.

Información de Autenticación DHCPv6 para el protocolo DELAYED AUTHENTICATION

Protocolo Reconfigure Key Authentication

El protocolo Reconfigure Key Authentication proporciona protección frente a la desconfiguración de un cliente mediante el uso de mensajes RECONFIGURE enviados por un servidor DHCP malicioso.

En este protocolo, el servidor DHCPv6 envía una clave Reconfigure al cliente en el primer intercambio de mensajes que tienen. El cliente guarda esta clave para autenticar los siguientes mensajes Reconfigure que mande dicho servidor. El servidor incluirá un HMAC creada a partir de la clave Reconfigure en los mensajes RECONFIGURE.

Ambas claves Reconfigure, la que envía al cliente en un principio y la HMAC enviada en los mensajes RECONFIGURE posteriores se llevan como la información de autenticación en la opción de Autenticación.

Este protocolo solo es utilizado si el cliente y el servidor no utilizan ningún otro protocolo de autenticación y tienen acordado el uso de mensajes RECONFIGURE.

Información de autenticación para protocolo RECONFIGURE KEY AUTHENTICATION

Opciones DHCPv6

Opciones Generales

Valor	Nombre	Descripción
1	OPTION_CLIENTID	La opción de Identificador de Cliente se usa para transportar un DUID identificando al cliente
2	OPTION_SERVERID	La Opción de Identificador de Servidor sirve para transportar un DUID identificando al Servidor
3	OPTION_IA_NA	La opción de Asociación de Identidad para Direcciones no Temporales se usa para transportar una IA_NA y parámetros y direcciones no temporales asociados a ella
4	OPTION_IA_TA	La opción de Asociación de Identidad para Direcciones Temporales se usa para transportar una IA_TA y parámetros y direcciones temporales asociados a ella como se define en la RFC 3041
5	OPTION_IAADDR	La Opción de Dirección IA se usa para especificar la dirección IPv6 asociada con una IA_NA o una IA_TA. Esta opción debe estar encapsulada dentro de una de las opciones anteriores (IA_NA o IA_TA)
6	OPTION_ORO	La opción de Petición de Opciones se usa para identificar una lista de opciones en un mensaje entre cliente y servidor
7	OPTION_PREFERENCE	La opción de Preferencia es enviada por un servidor para influir en la selección de servidor por parte del cliente
8	OPTION_ELAPSED_TIME	La opción de Tiempo Transcurrido indica cuanto tiempo el cliente ha estado intentado completar el intercambio de mensajes DHCPv6
9	OPTION_RELAY_MSG	La opción de Relay Message (Mensaje Retransmitido) transporta un mensaje DHCPv6 en un mensaje RELAY-FORWARD o RELAY-REPLY
10	Sin asignar	---
11	OPTION_AUTH	La opción de autenticación transporta la información de autenticación para autenticar la identidad y contenidos de un mensaje DHCPv6
12	OPTION_UNICAST	El servidor envía esta opción al cliente para indicarle al cliente que está permitido mandar mensajes Unicast al servidor
13	OPTION_STATUS_CODE	La opción de Código de Estado retorna una indicación de estado relativo al mensaje DHCPv6 u opción en el que aparece.
14	OPTION_RAPID_COMMIT	La opción Rapid Commit se usa para señalizar el uso de la asignación de direcciones con un intercambio de dos mensajes
15	OPTION_USER_CLASS	La opción clase de Usuario es utilizada por un cliente para identificar el tipo o categoría de uso o aplicaciones que representa
16	OPTION_VENDOR_CLASS	La opción Clase de Vendedor es utilizada por el cliente para identificar el vendedor que manufacturó el hardware sobre el que el cliente está corriendo
17	OPTION_VENDOR_OPTS	La opción de Información de Vendedor Específica se usa por clientes y servidores para intercambiarse información específica sobre un vendedor.
18	OPTION_INTERFACE_ID	El agente de Retransmisión puede enviar la opción Identificador de la Interfaz para identificar la interfaz por la cual recibió el mensaje del cliente
19	OPTION_RECONF_MSG	Un servidor incluye la opción Reconfigure Message en un mensaje RECONFIGURE para indicar al cliente si debe responder con un mensaje RENEW o INFORMATION-REQUEST
20	OPTION_RECONF_ACCEPT	Un cliente usa la opción de Reconfigure Accept para anunciar al servidor si el cliente está en disposición de aceptar mensajes RECONFIGURE

Opciones DHCPv6 para Servidores SIP

El protocolo de Inicialización de Sesión (SIP) es un protocolo de control de la capa de aplicación que puede iniciar, modificar, y terminar sesiones multimedias o llamadas. Existen opciones DHCPv6 que permiten a los clientes SIP^[2] puedan localizar un servidor local SIP que será usado para atender a las solicitudes SIP salientes.

Lista de Nombre de Dominio de Servidores SIP

Esta opción puede contener múltiples nombres de dominio, pero deben referirse a diferentes registros NAPTR, en lugar de diferentes registros A. Los clientes deben intentar conectarse a los diferentes servidores en el orden en los que están listados. Estos dominios tienen que estar listados en orden de preferencia.

Opción DHCPv6 para lista de nombres de dominio de Servidores SIP

Lista de Direcciones IPv6 de Servidores SIP

Esta opción especifica una lista de direcciones IPv6 indicando los proxy de salida disponibles para el cliente. Los servidores deben estar listados en orden de preferencia.

Opción DHCPv6 para lista de direcciones IPv6 de servidores SIP

Opciones de Configuración de DNS para DHCPv6

Existen opciones DHCPv6 que permiten a los servidores pasar una lista de servidores DNS^[3] disponibles o un dominio de búsqueda a los clientes.

Opción de DNS Recursive Name Server

La opción DNS Recursive Name Server proporciona una lista de una o más direcciones IPv6 de Servidores de DNS recursivo a los que el cliente puede enviar peticiones DNS. Los servidores DNS están ordenados en orden de preferencia.

Opción DHCPv6 para Lista de Nombres de Servidores DNS Recursivos

Opción de Lista de Dominios de Búsqueda

La Opción de Lista de Dominios de Búsqueda especifica la lista de dominio de búsqueda que el cliente tiene que usar cuando resuelva nombres de host con DNS. Esta opción hace que no se apliquen otros mecanismos de resolución de nombres.

Opción DHCPv6 para lista de Dominios de Búsqueda

Otras Opciones

Además de las opciones comentadas, existes más referentes a otras tecnologías puede encontrarlas en el sitio web de IANA^[4]

Servicio DHCPv6 Sin Estado para IPv6

Los nodos que han obtenido las direcciones IPv6 a través de cualquier otro mecanismo, como la autoconfiguración de direcciones sin estado o por configuración manual, pueden usar el servicio DHCPv6 sin estado^[5] para obtener otra información de configuración como la lista de servidores DNS recursivo.

Por lo tanto el servicio sin estado de DHCPv6 sólo proporciona información de configuración y no asignación de direcciones. El servidor es llamado sin estado porque no mantiene estado dinámico para clientes individuales.

Clientes y Servidores implementan los siguientes mensajes para el servicio DHCPv6 sin estado:

Information-Request
Reply
Relay-Forward
Relay-Reply

Véase también

Referencias

↑ Droms, R.; Bound, J.; Volz, B.; Lemon, T.; Perkins, C.; Carney, M. (2003) [rfc:3315 "Dynamic Host Configuration Protocol for Ipv6(DHCPv6)"], IETF RFC 3315
↑ Schulzrinne, H.; Volz, B. (2003) [rfc:3319 "Dynamic Host Configuration Protocol for Ipv6(DHCPv6) Options for Session Initiation Protocol (SIP)"] IETF RFC 3319
↑ Droms, R. (2003) [rfc:3646 "DNS Configuration options for Dynamic Host Configuration Protocol for IPv6"] IETF RFC 3646
↑ http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml
↑ Droms, R. (2004) [rfc:3736 "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6"], IETF RFC 3736

Enlaces externos

RFC 5007, "DHCPv6 Leasequery"

Datos: Q11170

[1] Droms, R.; Bound, J.; Volz, B.; Lemon, T.; Perkins, C.; Carney, M. (2003) [rfc:3315 "Dynamic Host Configuration Protocol for Ipv6(DHCPv6)"], IETF RFC 3315

[2] Schulzrinne, H.; Volz, B. (2003) [rfc:3319 "Dynamic Host Configuration Protocol for Ipv6(DHCPv6) Options for Session Initiation Protocol (SIP)"] IETF RFC 3319

[3] Droms, R. (2003) [rfc:3646 "DNS Configuration options for Dynamic Host Configuration Protocol for IPv6"] IETF RFC 3646

[4] ttp://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml

[5] Droms, R. (2004) [rfc:3736 "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6"], IETF RFC 3736

[1]

[2]

[3]

[4]

[5]