RFC2131

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

1

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.


2

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.


3

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).


4

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.


5

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


6

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:


7

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.


8

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.


9

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:


10

Fig. 3. Diagrama de estado para clientes DHCP.

RFC2131

Documents

Transcript of RFC2131