RFC 2131 Dynamic Host Configuration Protocol (DHCP) SEBASTIÁN PEÑALOZA R.

RFC 2131 “Dynamic Host Configuration Protocol (DHCP)”

En el presente texto se describen las funcionalidades del protocolo DHCP. Se enuncian las
principales características, se estudian las funciones que posibilita el protocolo y se analizan los
distintos tipos de mensajes intercambiados entre un cliente y un servidor DHCP.

DHCP es un protocolo que cumple dos funciones:

1. Permitir la entrega de parámetros de configuración de un host desde un servidor DHCP

hasta dicho equipo.
2. Proveer un mecanismo para la asignación de direcciones de red IP a los host que así lo
requieran.

Es así como este protocolo esta construido sobre la base de un modelo cliente- servidor. El
servidor DHCP será el encargado de entregar estos dos servicios mencionados a los host o
clientes.

Mensaje DHCP

Desde el punto de vista del cliente, DHCP es una extensión del mecanismo utilizado en el
protocolo de asignación automática de dirección IP, BOOTP (Bootstrap Protocol). Lo anterior
permite que los clientes BOOTP puedan interactuar con el servidor DHCP sin tener que alterar su
software de inicialización. En este sentido, DHCP fue desarrollado diferenciándose de BOOTP
en ciertos aspectos como por ej. el que algunos campos en el formato de mensaje han sido
renombrados como “options” y se ha ampliado la función de algunos campos.

A continuación se muestra el formato de un mensaje DHCP con sus campos bien definidos (entre
paréntesis se entrega el número de octetos correspondiente a cada campo):

op (1) htype (1) hlen (1) hops (1)

xid (4)
secs (2) flags (2)
ciaddr (4)
yiaddr (4)
siaddr (4)
giaddr (4)
chaddr (16)
sname (64)
file (128)
options (variable)

Fig. 1. Formato de mensaje DHCP.

1
RFC 2131 Dynamic Host Configuration Protocol (DHCP) SEBASTIÁN PEÑALOZA R.

La siguiente es una breve descripción de los distintos campos presentados en la fig. 1.:

Campo Descripción
Op Indica tipo de mensaje. Request o respuesta BOOTP.
htype Tipo de dirección de hardware (ej. 1= 10MbEth).
hlen Largo de dirección de hardware (ej. 6= 10MbEth).
hops Clientes lo setean en 0.
xid ID de transacción. Nº aleatorio para identificarse entre cliente y servidor.
secs Llenado por el cliente. Segundos transcurridos desde que el cliente ha
solicitado dirección IP o renovación.
flags Se utilizan para trabajar con clientes que no aceptan unicast.
ciaddr Dirección IP del cliente. (Se llena para estados especiales).
yiaddr Dirección IP del cliente.
siaddr Dirección IP del próximo servidor en uso.
giaddr Dirección IP de agente relacionador.
chaddr Dirección de hardware de cliente.
sname Nombre opcional del host servidor.
file Nombre de archivo de BOOT.
options Campo de parámetros opcional.
Tabla 1. Descripción de los campos de mensaje DHCP.

Parámetros de configuración

La primera función de DHCP es proveer los parámetros de configuración a los hosts. Para
ello, este protocolo implementa un repositorio o depósito donde se alojan dichos parámetros al
cuál se podrá acceder mediante una llave que puede ser definida de diferentes formas:

Par (Dirección IP de la subred, Dirección de hardware): Permite el uso del mismo

hardware en diferentes subredes.
Par (Dirección IP de la subred – Nombre del host): Permite que la interfaz de red
pueda cambiarse por otra nueva (tarjeta de red defectuosa por ej.), siendo identificado el
cliente por el nombre de host.

El protocolo DHCP define como llave el par (Dirección IP de la subred, Dirección de hardware) a
menos que se necesite el uso de la otra opción.

La interfaz entre el cliente y el repositorio requiere de un protocolo de mensajes para hacer los
request y recibir las respuestas desde el servidor con los parámetros de configuración.

2
RFC 2131 Dynamic Host Configuration Protocol (DHCP) SEBASTIÁN PEÑALOZA R.

Asignación de dirección IP

La segunda función del protocolo DHCP es la asignación de direcciones IP. Para ello
existirán tres mecanismos distintos. Se utilizará uno o varios de estos mecanismos según sea la
política del administrador de red:

1. Asignación automática: El servidor DHCP asigna una dirección IP permanente al

cliente.
2. Asignación dinámica: En este caso el servidor asigna la dirección IP por un periodo de
tiempo determinado o hasta que el cliente deje de utilizarla.
3. Asignación manual: La dirección es asignada por el administrador de red en forma
manual. En este caso el servidor DHCP se utiliza simplemente para enviar dicha
dirección.

De los tres mecanismos anteriores uno de los más útiles es la asignación dinámica debido a que
es la única que permite el re-uso de una dirección IP que un cliente deja de utilizar. Así es posible
distribuir un numero acotado de direcciones IP entre clientes según las vayan requiriendo. El
mecanismo de operación de la asignación dinámica es el siguiente:

Un cliente hace request de dirección IP por un periodo determinado de tiempo.

El servidor DHCP garantiza que no se reasignará dicha dirección dentro del
tiempo especificado y asume que entregará esa única dirección al cliente cada vez
que éste solicite una.
El cliente puede extender dicho tiempo con request sucesivos.
Si el cliente deja de ocupar la dirección puede publicar un mensaje dando aviso de
esto al servidor.
El cliente puede solicitar una dirección IP permanente, definiendo un tiempo de
uso “infinito”. El servidor por su parte establecerá tiempos extendidos pero finitos,
asegurándose así que el uso de la dirección IP sea el adecuado.
Cuando exista déficit de direcciones el servidor deberá reasignar de acuerdo a los
parámetros de configuración del repositorio (uso de direcciones cuyo tiempo ha
expirado).

3
RFC 2131 Dynamic Host Configuration Protocol (DHCP) SEBASTIÁN PEÑALOZA R.

Interacción Cliente - Servidor DHCP

La interacción entre un cliente y un servidor estará dada principalmente por el intercambio

de cierto tipos de mensajes DHCP. A continuación se describen los diferentes tipos:

Mensaje Uso
DHCPDISCOVER Cliente envía broadcast para localizar servidores
disponibles.
DHCPOFFER Mensaje de servidor a cliente en respuesta a
DHCPDISCOVER con oferta de parámetros de
configuración.
DHCPREQUEST Mensaje de cliente a servidor. Puede indicar un request de
parámetros del servidor escogido, confirmar la correcta
asignación de dirección antigua después de una
interrupción o extender el tiempo de uso de una dirección
IP.
DHCPACK Servidor a cliente. Entrega de parámetros y dirección IP
acordada.
DHCPNAK Servidor a cliente. Indica que no puede entregar dirección
IP acordada.
DHCPDECLINE Cliente a servidor indicando que la dirección IP está
ocupada.
DHCPRELEASE Cliente a servidor liberando la dirección IP utilizada,
cancelando antes del tiempo de extinción.
DHCPINFORM Cliente a servidor preguntando por parámetros locales de
configuración. El cliente ya tiene configurada de forma
externa la dirección IP.

Tabla 2. Tipos de mensaje DHCP y su uso.

El siguiente es un resumen de los intercambios de información entre un cliente y un servidor

DHCP considerando el formato y los tipos de mensajes DHCP presentados anteriormente:

1. El cliente envía un mensaje DHCPDISCOVER (broadcast) dentro de su subred física.

Este mensaje podría incluir sugerencias en cuanto a valores para la dirección y el tiempo
de uso de ella.

2. Cada servidor DHCP responderá con un mensaje DHCPOFFER que incluye una
dirección IP disponible en el campo “yiaddr”, además de otros parámetros.

4
RFC 2131 Dynamic Host Configuration Protocol (DHCP) SEBASTIÁN PEÑALOZA R.

3. El cliente recibirá distintas ofertas por parte de los servidores DHCP. Luego, escogerá
alguno de los servidores de acuerdo a los parámetros que fueron ofertados en el mensaje
DHCPOFFER. Posteriormente envía un broadcast de un mensaje DHCPREQUEST que
deberá incluir un identificador de servidor (señalando cuál escogió). Por otra parte el
campo de dirección IP requerido de dicho mensaje será llenado con la dirección “yiaddr”
recibida previamente. Finalmente para asegurar que se esta contestando a los mismos
servidores que ofertaron, y no a otros, el campo de “secs” debe tener el mismo valor que
en el mensaje DHCPDISCOVER y se debe enviar el mensaje a la misma dirección IP de
broadcast que al inicio.

4. Los servidores reciben el mensaje DHCPREQUEST, haciéndoles saber cual fue escogido.
Este último compromete un espacio del repositorio y envía un mensaje DHCPACK al
cliente que contiene los parámetros de configuración. El campo de “yiaddr” de dicho
mensaje contiene la dirección IP asignada al cliente. Si el servidor no puede atender el
request debido a que por ejemplo ya asignó esa dirección IP, deberá responder con un
mensaje DHCPNAK.

5. El cliente recibe el mensaje DHCPACK con los parámetros de configuración. A esta

altura el cliente ya ha sido configurado y debiese realizar un chequeo final de los
parámetros (por ej. con ARP). Si resulta que la dirección IP ya está ocupada el cliente
debe enviar un mensaje DHCPDECLINE y reiniciar el proceso de configuración.

6. Por último, si el cliente decide dejar de usar la dirección IP asignada debiese enviar un
mensaje DHCPRELEASE al servidor.

El siguiente esquema resumen los pasos anteriormente señalados

5
RFC 2131 Dynamic Host Configuration Protocol (DHCP) SEBASTIÁN PEÑALOZA R.

Fig. 2. Línea de tiempo de mensajes intercambiados entre cliente y servidor DHCP.

Para entender los procesos que realiza tanto el cliente como el servidor a continuación se entrega
el contenido de los mensajes generados por uno y otro lado.

Servidor DHCP

Como se señaló en líneas previas, el servidor DHCP recibirá y enviará distintos tipos de mensajes
según sea el estado de la comunicación con el cliente. Luego, los campos de los mensajes serán
llenados acorde a las solicitudes y respuestas que se entreguen. Las siguientes tablas muestran el
contenido de los mensajes según su tipo para el lado servidor:

6
RFC 2131 Dynamic Host Configuration Protocol (DHCP) SEBASTIÁN PEÑALOZA R.

Tabla 3. Contenido de campos de mensajes emitidos por servidor.

Así mismo, en el campo habrá cierta información que debe ser incluida (MUST), se recomienda
incluirla (SHOULD), se recomienda no incluirla (SHOULD NOT), es opcional incluirla (MAY)
o que no debe ser incluida (MUST NOT). A continuación se entrega un resumen para los
mensajes que genera el servidor:

Tabla 4. Opciones para los mensajes generados por el servidor.

7
RFC 2131 Dynamic Host Configuration Protocol (DHCP) SEBASTIÁN PEÑALOZA R.

Cliente

Análogamente al servidor, el cliente genera ciertos mensajes en los que debe definirse el
contenido de los campos. Particularmente habrá cierta información que debe ser incluida y otra
que no. A continuación se presentan dos tablas que resumen toda esta información:

Tabla 5. Contenido de campos de mensajes emitidos por cliente.

8
RFC 2131 Dynamic Host Configuration Protocol (DHCP) SEBASTIÁN PEÑALOZA R.

Tabla 6. Opciones para los mensajes generados por el cliente.

Finalmente, el siguiente es un diagrama de estado para el cliente. Se puede observar las distintas
transiciones entre estados asociadas a los distintos mensajes recibidos y emitidos desde y hacia el
servidor DHCP. El estado inicial es señalado como INIT:

9
RFC 2131 Dynamic Host Configuration Protocol (DHCP) SEBASTIÁN PEÑALOZA R.

Fig. 3. Diagrama de estado para clientes DHCP.

10