DHCPv6

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

Índice
Introducción
Constantes DHCPv6
Direcciones Multicast
Puertos UDP
Tipos de Mensaje DHCPv6
Parámetros de Transmisión y Retransmisión
Códigos de Estado
Formato de mensajes Cliente-Servidor
Formato de mensajes entre Agentes de Retransmisión Y Servidores
Identificador Único DHCP (DUID)
Asociación de Identidad (IA)
Selección de direcciones para asignar a una IA
Gestión de Direcciones Temporales
Solicitud de Servidor DHCPv6
Intercambio de Configuración DHCPv6 iniciado por el cliente
Request
Confirm
Renew
Rebind
Information-Request
Release
Decline
Intercambio de configuración DHCPv6 iniciado por el Servidor
Reconfigure
Agentes de Retransmisión DHCPv6
Autenticación de mensajes DHCPv6
Seguridad de mensajes enviados entre Servidores y Agentes de Retransmisión
Detección de Repeticiones
Protocolo de Autenticación Retardada
Protocolo Reconfigure Key Authentication
Opciones DHCPv6
Opciones Generales
Opciones DHCPv6 para Servidores SIP
Lista de Nombre de Dominio de Servidores SIP
Lista de Direcciones IPv6 de Servidores SIP
Opciones de Configuración de DNS para DHCPv6
Opción de DNS Recursive Name Server
Opción de Lista de Dominios de Búsqueda
Otras Opciones
Servicio DHCPv6 Sin Estado para IPv6
Referencias
Enlaces externos
Véase también

Introducción
Aunque IPv6 resuelve la auto configuración de direcciones, lo cual es la principal motivación de DHCP en IPv4. DHCPv61 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. o
Tdos 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 por que 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 547UDP

Tipos de Mensaje DHCPv6

La siguiente tabla muestra los tipos de mensaje DHCPv6 así como su función.
 Nombre del Msg-
Descripción
Mensaje type
SOLICIT 1 Un cliente manda un mensaje SOLICIT para localizar servidores.
El servidor en un mensaje ADVERTISE para indicar que está disponible para el servicio, en respuesta al
ADVERTISE 2
mensaje de solicitud recibido de un cliente.
Un cliente manda un mensaje REQUEST para solicitar los parámetros de configuración, incluyendo la
REQUEST 3
dirección IP, de un servidor específico.
Un cliente envía un mensaje CONFIRM a cualquier servidor disponible para determinar si las direcciones
CONFIRM 4
que se asignaron siguen siendo válidas.
Un cliente manda un mensaje RENEW al servidor que originalmente proporcionó la dirección del cliente y
RENEW 5 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.
Un cliente envía el mensaje REBIND a cualquier servidor disponible para extender los tiempos de vida en
REBIND 6 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 .
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
REPLY 7 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.
Un cliente manda un mensaje de RELEASE al servidor que le asigno las direcciones IP para indicar que no
RELEASE 8
usará más una o varias de las direcciones asignadas.
Un cliente envía un mensaje DECLINE para indicar al cliente que una o varias de las direcciones que tiene
DECLINE 9
asignadas por el servidor están siendo utilizadas en el enlace en el que el cliente está conectado.
Un servidor envía un mensaje de RECONFIGURE a un cliente para informarle de que el servidor tiene
RECONFIGURE 10 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- Un cliente envía un mensaje INFORMATION-REQUEST al servidor para pedir los parámetros de
11
REQUEST configuración sin pedir ninguna dirección IP
.
Un agente de retransmisión envía un mensaje RELAY-FORWARDING al servidor, ya sea él mismo o a
RELAY-FORW 12 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 RELA Y-FORWARDING.
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
RELAY-REPL 13
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 1s Máximo retardo del primer mensaje SOLICIT
SOL_TIMEOUT 1s Tiempo inicial de espera del mensaje SOLICIT
SOL_MAX_RT 120 s Máximo tiempo de espera del mensaje SOLICIT
REQ_TIMEOUT 1s 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 Numero máximo de reintentos del mensaje REQUEST
CNF_MAX_DELAY 1s Tiempo máximo de retardo del primer mensaje CONFIRM
CNF_TIMEOUT 1s Tiempo de espera inicial del mensaje CONFIRM
CNF_MAX_RT 4s 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 mensajeRENEW
REB_TIMEOUT 10 s Tiempo de espera inicial para un mensaje REBIND
REB_MAX_RT 600 s Tiempo de espera máximo para un mensajeREBIND
INF_MAX_DELAY 1s Retardo máximo del primer mensaje INFORMA
TION-REQUEST
INF_TIMEOUT 1s 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 1s Tiempo de espera inicial del mensaje RELEASE
REL_MAX_RC 5 Máximo de intentos de mensaje RELEASE
DEC_TIMEOUT 1s Tiempo inicial de espera para el mensaje DECLINE
DEC_MAX_RC 5 Máximo intentos de mensaje DECLINE
REC_TIMEOUT 2s 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 RELA
Y-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.

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) Formato de mensaje entre agentes de retransmisión DHCPv6
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 porgualdad.
i 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 lar
go 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 cuál 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 ADVER
TISE 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.

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 cibir
re 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 DHCPv6 iniciado desde el Cliente

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 REPL
Y.

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 REPL
Y 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 REPL
Y con código de estadoSuccess.

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 REPL
Y 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.

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 INFORMA
TION-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.

Intercambio de Mensajes DHCPv6 iniciado desde el Servidor

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.

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-

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

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 rediFi
W se emplea el mecanismo de
autenticación DHCPv6 que está basado en el diseño de autenticación paraDHCPv4.

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 DELA

YED 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 AUTHENTICA

TION

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

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

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
IANA4
Además de las opciones comentadas, existes más referentes a otras tecnologías puede encontrarlas en el sitio web de

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 estado5 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
Referencias
1. Droms, R.; Bound, J.; Volz, B.; Lemon, T.; Perkins, C.; Carney, M. (2003) "Dynamic Host Configuration Protocol for Ipv6(DHCPv6)" (htt
ps://tools.ietf.org/html/rfc3315), IETF RFC 3315
2. Schulzrinne, H.; Volz, B. (2003) "Dynamic Host Configuration Protocol for Ipv6(DHCPv6) Options for Session Initiation Protocol (SIP)"
(https://tools.ietf.org/html/rfc3319)IETF RFC 3319
3. Droms, R. (2003) "DNS Configuration options for Dynamic Host Configuration Protocol for IPv6" (https://tools.ietf.org/html/rfc3646)
IETF RFC 3646
4. http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml
5. Droms, R. (2004) "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6" (https://tools.ietf.org/html/rfc3736), IETF
RFC 3736

Enlaces externos
RFC 5007, "DHCPv6 Leasequery"

Véase también
IPv6
DNS
ICMPv6
IPsec

Obtenido de «https://es.wikipedia.org/w/index.php?title=DHCPv6&oldid=85613860
»

Se editó esta página por última vez el 5 oct 2015 a las 23:58.

El texto está disponible bajo laLicencia Creative Commons Atribución Compartir Igual 3.0
; pueden aplicarse cláusulas adicionales. Al usar
este sitio, usted acepta nuestrostérminos de uso y nuestra política de privacidad.
Wikipedia® es una marca registrada de laFundación Wikimedia, Inc., una organización sin ánimo de lucro.