Descripción del protocolo

El estándar original de 1993 del protocolo DHCP está definido a través de los siguientes documentos:

• RFC 1531
• RFC 1532 (describe las opciones de configuración)

Actualizados en 1997 en los:

• RFC 2131
• RFC 2132 (describe las opciones de configuración)

Este protocolo abierto está implementado con una arquitectura cliente/servidor, que es la filosofía de los protocolos de la pila TCP/IP. El servidor escucha por el puerto 67 y el cliente por el 68 (el agente de retransmisión, relay agent, usa el 67 y el 68), usando UDP como protocolo de transporte.

El protocolo DHCP permite tres métodos de asignación de direcciones IP:

• Asignación estática: Consiste en que el administrador de la red configura el servidor DHCP para que asigne una IP fija a determinados equipos. Esto es posible gracias a que los clientes DHCP cuando hacen una solicitud de IP, se identifican (MAC u opción client identifier), lo que permite la asignación de una IP específica.
• Asignación dinámica: Con este método, el servidor DHCP dispone de uno o varios rangos (pools) de IP (al menos uno por cada segmento de red para los que se atienden peticiones de clientes), y cuando recibe una solicitud, este selecciona una del pool adecuado y la asigna con un tiempo de alquiler (lease time), tiempo que se podrá prorrogar, o en caso contrario, el cliente debe dejar de usar la IP y comenzar una nueva solicitud, ya que si no se quedará sin acceso a la red.
• Asignación automática: La especificación del DHCP habla de este método, a través del cual el servidor DHCP asigna una IP como en la asignación dinámica pero de forma permanente. Muchos servidores no implementan este método, como el servidor de ISC (es el que utilizaremos) y el de Microsoft. En estos casos, este comportamiento puede simularse asignando mucho tiempo de alquiler, que puede llegar hasta 2³²-2 segundos.

En una configuración de un servidor DHCP se pueden mezclar los tres métodos de asignación de IP anteriores.

El protocolo DHCP define un conjunto de mensajes que se intercambian el cliente y el servidor DHCP para que el primero consiga una configuración de red sin intervención humana.

Este intercambio de mensajes, cuando un cliente solicita por primera vez una IP, puede verse en el siguiente vídeo:

El cliente, al conectarse a la red, necesita contactar con un servidor DHCP y conseguir una configuración de red. Para ello envía un mensaje de broadcast intentando localizar los potenciales servidores disponibles. Cuando el servidor DHCP recibe este mensaje, contesta con otro mensaje de broadcast, donde este se identifica, y además oferta una IP libre, apropiada para el segmento de red del cliente, junto con otros parámetros necesarios. En este mensaje va también la dirección MAC del cliente, que de esta forma sabe que es para él. La dirección MAC del cliente le llegó al servidor en el primer mensaje.

Una vez que la oferta llega al cliente, un nuevo mensaje de broadcast es enviado por el cliente, donde se solicita (requiere) una IP y unos parámetros de red determinados, concretamente los ofertados por el servidor seleccionado. Este mensaje es necesario pues en la red puede haber varios servidores DHCP (por seguridad, por si un servidor falla, ya que es un servicio crítico; cada servidor serviría un rango distinto dentro de la misma subred) y este paso, es el que permite seleccionar a uno de ellos (normalmente el algoritmo de elección que se implementa consiste en coger al primero que llega), reutilizando, los servidores rechazados, las IP que ofertaron.

Si el mensaje de requerimiento llega a tiempo al servidor, éste no habrá ofertado la IP a otro cliente, y por lo tanto, la reserva definitivamente para el cliente en cuestión, registrándola junto con su tiempo de alquiler, y a continuación, le envía un último mensaje de broadcast de aceptación, tras el cual, el cliente se configura y también, de forma local, registra la IP y el resto de parámetros, para un uso posterior.

Cuando un equipo se reinicia, recupera su última configuración de red e intenta confirmar que puede utilizarla mandando un mensaje al servidor DHCP con todos los parámetros de red; pero esto sucederá siempre que la IP no esté caducada, pues si este fuese el caso, el cliente empieza desde el principio como si nunca hubiera tenido una IP asignada.

Tras el envío anterior, el servidor comprueba si la IP puede utilizarla el cliente. En caso afirmativo, se lo confirma con un mensaje de aceptación, y en caso negativo, el mensaje será de rechazo y el cliente tendrá que empezar el proceso desde el inicio tal como se ha visto anteriormente. Este último caso, puede ocurrir cuando un equipo se apaga en un segmento de red y se enciende en otro, de modo que el cliente intenta confirmar la configuración que tenía en el antiguo segmento de red y el servidor, al darse cuenta de que está en un segmento distinto, le rechaza la propuesta (requerimiento) y el cliente comienza de nuevo desde el principio.

En el caso anterior, si el cliente no recibiera respuesta del servidor, la decisión del cliente es la de configurarse con los antiguos parámetros de red que tenía, siempre y cuando dicha IP no hubiera caducado, como ya se ha comentado.

Un servidor DHCP deduce a qué segmento de red está conectado un cliente basándose en el campo giaddr:

• Si el cliente y el servidor están en segmentos distintos, un software, denominado agente de retransmisión (relay agent) conectado en el segmento de red del cliente, debe reenviar los mensajes al servidor, y en ese paso, el relay agent incluye en el campo giaddr la dirección de su tarjeta de red por la que ha recibido el mensaje. La red de esta IP debe ser la red a la que pertenezca la IP que se le proponga al cliente.
• Si el cliente y el servidor están en el mismo segmento, el campo giaddr está a 0.0.0.0, pues al no intervenir ningún agente de retransmisión, este campo no se modifica, y por lo tanto el segmento del cliente será el mismo en el que está conectada la tarjeta de red del servidor por el que entró la solicitud. En consecuencia, el servidor, a través de la IP de dicha tarjeta, sabrá a qué red debe pertenecer la IP a asignar al cliente.

Como se mencionó anteriormente, los clientes de DHCP se presentan al servidor incluyendo información identificadora en los mensajes que envía. Sos dos los datos que se utilizan para ello:

• La dirección MAC de la tarjeta de red del cliente.
• La opción denominada client identifier, que puede contener cualquier cadena de texto.

Esta última es más flexible que la primera, pues si se cambia la tarjeta de red, el cliente se identificaría con otra MAC, lo cual no sucedería con la opción client identifier.

El servidor DHCP para identificar a los clientes utiliza la información anterior junto con la dirección del segmento de red al que pertenece el cliente, por lo que en realidad, solo se exige que la opción client identifier sea diferente dentro de cada segmento de red, y no diferente dentro de toda la red.

En el documento RFC 2131, las operaciones que un cliente DHCP puede realizar se describen como una máquina de transición de estados, la cual se muestra en la siguiente diagrama:

Veamos de forma escueta el diagrama anterior:

Cuando un cliente no tiene una dirección IP válida, se dice que está en el estado INIT. Durante el proceso de configuración inicial, el cliente normalmente se mueve al estado SELECTING, y en el momento en el que está configurado correctamente con una dirección IP, se mueve al estado BOUND. Cuando se reinicia el cliente o se apaga y posteriormente se enciende, se comienza en el estado INIT-REBOOT, y después de que se confirme que su dirección IP es válida, se mueve al estado BOUND. Si un servidor envía un mensaje DHCPNAK al cliente, el cliente vuelve al estado INIT.

Antes de que expire el tiempo de concesión (alquiler, lease) de la dirección IP del cliente, este entra en estado de RENEWING e intenta extender su contrato de arrendamiento mediante el envío de un mensaje unicast al servidor del que obtuvo su dirección IP. El cliente espera un tiempo, y si no recibe respuesta a su solicitud de renovación, entra en el estado de REBINDING y difunde un mensaje broadcast para extender su contrato de alquiler en cualquier servidor disponible. Si el contrato de arrendamiento expira sin que el cliente renueve con éxito su concesión, el cliente vuelve al estado INIT.

Veamos ahora, con un poco más de detalle, las distintas situaciones entre un cliente y un servidor DHCP:

OBTENCIÓN DE LA CONFIGURACIÓN INICIAL:

Cuando un equipo configurado para utilizar DHCP se conecta a una red, se determina si tiene una dirección IP válida. Un cliente puede tener una dirección no válida por varios motivos:

• Es nuevo y aún no ha recibido nunca una IP (no interviene el servidor).
• El tiempo de alquiler de la anterior IP ha expirado (no interviene el servidor).
• El cliente se ha movido de segmento de red, y al proponerle al servidor usar la IP que tenía, este se la rechaza (DHCPNACK) por ser una dirección no válida en el nuevo segmento donde se ha conectado (interviene el servidor).

En estos casos, el cliente pasa al estado INIT porque no tiene una dirección válida.

Cuando el cliente se inicia en el estado INIT, el cliente y el servidor intercambian los siguientes cuatro mensajes:

1. Mensaje DHCPDISCOVER: El cliente difunde (broadcast) un mensaje DHCPDISCOVER, y el mensaje se entrega a todos los servidores DHCP existentes en el mismo segmento de red del cliente. Este mensaje también es recibido por los agentes de retransmisión del segmento de red del cliente y se reenvía a otros servidores DHCP situados en segmentos de red distintos al del cliente. La trama del mensaje lleva como MAC de origen la de la tarjeta de red del cliente, la IP origen del paquete es 0.0.0.0, el campo DHCP "client hardware address" (chaddr) lleva la MAC del cliente y el campo DHCP "client IP address" (ciaddr) contiene 0.0.0.0. También, el cliente genera un número aleatorio que guarda en el campo Transaction ID, y cuyo valor debe venir en el mismo campo de la respuesta.
   
2. Mensaje DHCPOFFER: Después de que el servidor recibe el mensaje DHCPDISCOVER, identifica (como se explicó anteriormente) el segmento de red al que pertenece el cliente y encuentra una dirección IP de la subred adecuada para asignársela. Dicha IP la pone en un mensaje DHCPOFFER, concretamente dentro del campo "your IP address" (yiaddr). El servidor también incluye en este mensaje otros parámetros de configuración, según lo definido en el archivo de configuración del servidor. Después de que el servidor ha completado el mensaje DHCPOFFER, envía el mensaje de vuelta al cliente como broadcast, pero hoy en día, es muy habitual, que dicho mensaje se mande en modo unicast. El cliente se identifica con el campo chaddr que lleva su MAC, además el campo ciaddr contiene 0.0.0.0. El servidor se identifica en el mensaje con el campo DHCP "next server IP address" (siaddr) donde coloca su IP, además de colocarla también en la opción "DHCP server identifier". Como identificador de la transacción, el servidor coloca el mismo valor que le llego en dicho campo dentro del mensaje DHCPDISCOVER.
   
3. Mensaje DHCPREQUEST: Después de que el cliente recibe el(los) mensaje(s) DHCPOFFER, envía un mensaje DHCPREQUEST como broadcast con los datos de la oferta elegida para que el servidor la confirme, y entre dichos datos va la IP asignada (opción Requested IP Address). Entre estos datos va la dirección del servidor elegido (opción DHCP Server Identifier). Los servidores no elegidos, si los hubiera, reincorporarán la IP ofrecida al pool de direcciones para servirla a otras solicitudes. También aquí, el cliente genera un nuevo número aleatorio como identificador de la transacción, que deberá devolverse en la respuesta.
   
4. Mensaje DHCPACK: Después de recibir el mensaje DHCPREQUEST, el servidor comprueba la dirección y los parámetros de configuración requeridos para asegurar que la dirección todavía está disponible y los parámetros son correctos. Registra la dirección asignada y envía el mensaje DHCPACK para que el cliente se configure definitivamente. El cliente cuando recibe este mensaje y se configura, también registra localmente los valores de la concesión. En el caso de que el servidor hubiera asignado la IP a otro cliente antes de recibir el mensaje DHCPREQUEST del primero, se le envía al cliente el mensaje DHCPNACK, rechazando el requerimiento y el cliente vuelve de esta forma al estado INIT. Este mensaje es de tipo broadcast, pero también, igual que sucede con el mensaje DHCPOFFER, actualmente, con mayor frecuencia el servicio DHCP usa tráfico unicast. El identificador de la transacción que va en este mensaje es el mismo que llegó en el mensaje anterior (DHCPREQUEST).
   

En el caso de que hubieran dos servidores DHCP en el mismo segmento de red, el intercambio de mensajes sería el siguiente, donde el cliente aceptará la primera oferta que le llegue:

Para hacer un poco más de hincapié en el tipo de tráfico (unicast o broadcast) de los cuatro mensajes anteriores, hay que decir en primer lugar, que el flujo de estos mensajes es posible porque DHCP hace uso de una característica específica del protocolo UDP, que consiste en que los mensajes UDP se pueden transmitir con la dirección IP no válida de origen 0.0.0.0, si al host de origen aún no se le ha asignado una dirección IP. En consecuencia, esto es lo que permite que un cliente DHCP se pueda comunicar con un servidor DHCP antes de que el propio cliente tenga una IP válida, y por lo tanto los mensajes DHCPDISCOVER y DHCPREQUEST del cliente, se van a transmitir en modo broadcast, con la dirección IP de destino 255.255.255.255 (broadcast limitado) y la IP de origen 0.0.0.0, que como hemos dicho no es ningún impedimento para UDP.

Por otro lado, el cliente se identifica dentro de estos mensajes poniendo la dirección MAC de su tarjeta de red en el campo "MAC de origen" de la trama y en el campo "client hardware address" (chaddr) de la cabecera del protocolo DHCP, siendo este último campo el que utiliza el servidor DHCP para saber con qué cliente está hablando. Hay otro campo en la cabecera del protocolo DHCP denominado "client IP address" (ciaddr) cuyo valor en estos mensajes DHCP es 0.0.0.0, que indica que el cliente aún no tiene IP.

En el caso de que el servidor DHCP se encuentre en un segmento de red distinto al del cliente, el que recibiría del mismo modo los mensajes anteriores sería el agente de retransmisión (agent relay), el cual los retransmitiría hacia el servidor como mensajes unicast, pues estos dos interlocutores sí tienen asignada una IP válida.

En cuanto a los mensajes del servidor al cliente, DHCPOFFER y DHCPACK, estos pueden enviarse tanto en modo unicast como broadcast, y va a depender de las características de implementación de la pila TCP/IP del cliente. Hoy en día, lo habitual es que el envío de estos mensajes sea unicast, pues las implementaciones actuales de la pila TCP/IP permite aceptar datagramas que vengan con una IP de destino unicast que aún no ha sido configurada en el equipo (cliente en este caso). El mensaje llega gracias a que la trama sí lleva la dirección MAC del cliente, la cual fue enviada por este al servidor, como se mencionó anteriormente. Pero hay implementaciones que esto no lo permiten, y entonces el cliente se lo comunica al servidor a través del campo "flag", con lo cual el servidor envía los mensajes al cliente usando la dirección de broadcast limitado (255.255.255.255). Por lo tanto, si el campo "flag" de los mensajes DHCPDISCOVER y DHCPREQUEST contiene un 0, el envío de los mensajes DHCPOFFER y DHCPACK será unicast, y será broadcast si el valor es distinto de cero. El campo "flag" es un campo de bit y concretamente es el bit más significativo el que se pone a 1, el resto de bits no se utilizan, su valor es 0 y están para un uso futuro.

CONFIRMACIÓN DE UNA IP TRAS UN REINICIO:

Cada vez que se reinicia un cliente, este comprueba si tiene registrada una dirección IP con un contrato de arrendamiento que aún no haya caducado y en caso afirmativo, se pasa al estado INIT-REBOOT e intenta confirmar que su dirección sigue siendo válida con los siguientes mensajes:

1. Mensaje DHCPREQUEST: El cliente envía la dirección IP para ser confirmada en un mensaje DHCPREQUEST como broadcast, el cual es recibido y comprobado por todos los servidores DHCP que están configurados en el segmento de red al que está conectado el cliente. Esta dirección podría no ser válida si el cliente se ha cambiado de segmento de red, o si el administrador de la red ha decidido cambiar el direccionamiento del segmento de red. La trama del mensaje lleva como MAC de origen la de la tarjeta de red del cliente, la IP origen del paquete es 0.0.0.0, el campo chaddr lleva la MAC del cliente, el campo ciaddr contiene 0.0.0.0 y la IP que tuvo el cliente la última vez e intenta que se la vuelvan a asignar, va en la opción "Requested IP Address" junto con el resto de opciones que tuvo la asignación de dicha IP. En el campo Transaction ID se coloca un número aleatorio que se espera recibir en la respuesta dentro del mismo campo.
   

2. Mensaje DHCPACK: Cuando el servidor recibe el mensaje DHCPREQUEST, extrae la dirección solicitada por el cliente y verifica que la dirección es válida y puede utilizarla. Entonces el servidor responde con un mensaje DHCPACK, donde van todos los parámetros de configuración que debe usar el cliente para configurarse, que no tienen que coincidir con los parámetros dados en la última asignación y enviados en el DHCPREQUEST, pues el fichero de configuración del servidor puede haber cambiado. Como identificador de la transacción se envía el valor recibido en el mensaje anterior (DHCPREQUEST). Si el cliente no recibiera la respuesta, éste se configurará con la antigua IP siempre que el alquiler no haya expirado. Este mensaje rellena los campos fijos yiaddr, siaddr y chaddr, además de las opciones variables que se hayan configurado. 
   

 

Algunos clientes DHCP, como por ejemplo el ISC DHCP Client, cuando se para el servicio al apagar el ordenador, envían un mensaje DHCPRELEASE, por lo que liberan su IP y cuando se reinicia el equipo comienzan en el estado INIT enviando un mensaje DHCPDISCOVER. Este comportamiento no lo tienen los clientes DHCP de Microsoft.

EXTENDIENDO EL ALQUILER DE LA DIRECCIÓN IP:

El servicio DHCP establece mecanismos para que un cliente pueda extender en el tiempo el contrato de arrendamiento de su IP antes de que este expire y tenga que dejar de usarla.

Un cliente DHCP amplía su contrato de arrendamiento mediante el envío de un mensaje unicast al servidor que le concedió la IP, solicitando más tiempo de alquiler. La solicitud de prórroga se envía en un mensaje DHCPREQUEST, y el cliente puede pedir el tiempo que desee. En este punto, el servidor DHCP comprueba que puede renovarla, decide la nueva duración de la extensión de la concesión y envía al cliente en un mensaje DHCPACK unicast el nuevo tiempo de alquiler. El servidor puede no extender el tiempo o incluso ignorar la solicitud, si así se configura.

Un cliente DHCP se dice que está en el estado de RENEWING cuando comienza el proceso de extensión del contrato de alquiler de su IP, y este proceso lo puede realizar cuantas veces lo necesite.

Tanto el servidor como el cliente, guardan los nuevos tiempos para un uso posterior. Estos tiempos se dan en segundos y son tres:

• El tiempo total del alquiler.
• El tiempo tras el cual se comenzará el proceso de renovación. Se le llama T1. Algunos servidores no suministran este tiempo y el cliente lo establece al 50% del tiempo total de la concesión.
• El tiempo transcurrido el cual el cliente vuelve a intentar renovar la IP cuando tras el primer intento no ha recibido respuesta del servidor. Se le llama T2 y al igual que con T1, algunos servidores no lo suministran y el cliente lo establece, en este caso, al 87.5% del tiempo total de la concesión.

 

Se dice que el cliente entra en el estado de REBINDING cuando estando en el estado de RENEWING, este no ha recibido respuesta del servidor y han transcurrido T2 segundos desde que comenzó el último contrato de arrendamiento. En este caso, el mensaje DHCPREQUEST es de tipo broadcast y no unicast, con el objetivo de contactar con todos los servidores DHCP y ver si alguno puede renovarle la concesión (podría suceder que el servidor hubiera cambiado de IP).

La respuesta del servidor en estos casos, también es con un mensaje DHCPACK unicast.

 En estos mensajes, los campos ciaddr, chaddr, yiaddr y siaddr se rellenan.

CUANDO EL TIEMPO DE CONCESIÓN EXPIRA:

Si un cliente no puede comunicarse con un servidor para renovar su concesión antes del vencimiento del contrato de arrendamiento, el cliente debe dejar de usar su dirección IP y volver al estado INIT, cortándose la comunicación por red hasta obtener una nueva IP.

MOVIENDO UN EQUIPO DE SEGMENTO DE RED:

Cuando un cliente es movido de segmento de red, al encenderse, se produce el siguiente intercambio de mensajes:

1. Mensaje DHCPREQUEST: Este mensaje se produce en el reinicio del equipo cliente (estado INIT-REBOOT), es broadcast y al llegar al servidor del nuevo segmento, este comprueba que la IP que se le solicita pertenece a otro segmento, por lo que la rechaza (si está configurado como authoritative).
   
2. Mensaje DHCPNACK: Con este mensaje, el servidor notifica al cliente que la IP que solicitó no es válida, con lo que el cliente descarta la IP y pasa al estado INIT, comenzando el proceso de cuatro mensajes que ya hemos visto.