6.1.1. Descripción del protocolo

6.1.1.1. Comunicación

La comunicación se realiza entre el puerto 67/UDP del servidor y el puerto 68/UDP del cliente y puede ir encaminada a distintos propósitos:

  1. Pedir la concesión de una dirección IP.

  2. Pedir la renovación de la IP ya concedida.

  3. Pedir la anulación de la concesión.

Analicémoslo por separado.

6.1.1.1.1. Concesión

EL protocolo se inicia cuando un cliente que requiere una configuración de red, la pide mediante el envío de un paquete DHCPdiscover. Dado que el cliente aún no tiene configuración de red, la IP de origen se fija a 0.0.0.0 y la dirección de destino la de broadcast universal (tanto en capa 3, 255.255.255.255, como en capa 2, FF:FF:FF:FF:FF:FF).

Como consecuencia, el paquete llegará a cualquier máquina dentro de la red y, si alguna es un servidor DHCP, esta responderá enviando un paquete DHCPoffer en el que le propone una dirección IP libre. Este paquete usa como dirección de origen la IP del servidor y como dirección de destino la IP ofrecida, aunque antiguamente se usaba la dirección de broadcast universal.

Si el cliente acepta la IP, entonces envía una petición formal al servidor mediante un paquete DHCPrequest en la que incluye una lista de parámetros de red1 cuyos valores le gustaría que el servidor le proporcionara. Esta lista de parámetros es una lista de números enteros, ya que cada parámetro de red está representado por un número. Tales parámetros se refieren a la máscara de red, la dirección IP, los servidores DNS, etc. Este paquete tiene las mismas direcciones de origen y de destino que el paquete DHCPdiscover, puesto que el cliente sigue sin estar configurado.

Recibido el paquete anterior, el servidor responde con un paquete DHCPack donde se incluyen unos campos iniciales con cierta información (la IP ofertada, la dirección del siguiente servidor, etc.) y el valor de los parámetros que el cliente le requirió. Entre ellos (es el número 51), está el que define el periodo de vigencia de la concesión. Las direcciones de origen y destino son las mismas que para el paquete DHCPoffer. Cuando el paquete es recibido por el cliente, este podrá por fin configurar su interfaz y particicpar normalmente en las comunicaciones de la red.

../../_images/concesion.png

6.1.1.1.2. Renovación

Cuando la concesión de una IP está próxima a expirar, el cliente envía un paquete DHCPrequest en que pide al servidor que prorrogue la concesión. Este paquete tiene las mismas direcciones de origen y destino que las explicadas para el DHCPrequest que se explicó en el caso anterior.

Si el servidor accede, entonces devolverá un paquete DHCPack con la configuración de red y el cliente disfrutará de la concesión otro periodo de tiempo.

../../_images/renovacion.png

6.1.1.1.3. Revocación

Si el cliente desea renunciar a la concesión antes de que acabe el plazo (por ejemplo, porque piensa apagarse y no desea seguir ocupando la dirección IP), puede entonces enviar al servidor un paquete DHCPrelease que utiliza como dirección de origen la IP del cliente y como dirección de destino la del servidor. Al recibir este paquete el servidor dará por finalizada la concesión y liberará la IP para que pueda ser entregada de nuevo

../../_images/anulacion.png

Si el cliente no envía este aviso, el servidor esperará a que el plazo expire par liberar la IP. Es más, si posteriormente el mismo cliente por cualquier razón, inicia la petición de una nueva IP con un paquete DHCPrequest (veáse el siguiente apartado) y sugiere una distinta que está libre, el servidor se la concederá sin liberar la IP anterior, cuyo plazo puede aún no haberse cumplido.

Nota

Para que esta circunstancia no se produzca y un mismo cliente siempre consuma una IP es necesario fijar en el servidor ISC la directiva:

one-lease-per-cliente  on;

6.1.1.1.4. Otros casos

Los tres casos anteriores son los más habituales, pero pueden darse otros. Uno común se produce cuando el cliente, sin la concesión previa de una determinada IP, envía directamente al servidor un paquete DHCPrequest en que sugiere que se le conceda una determinada IP.

Si la IP está libre y está dentro del rango de concesión, el servidor aceptará la sugerencia y enviará un paquete DHCPack. En cambio, si no es así y el servidor se ha definido como autoritario, enviará un paquete DHCPnack con el que rechazará la sugerencia. Este paquete tiene como IP de origen el servidor y como IP de destino la de broadcast universal. Ante la negativa, el cliente comenzara la petición enviando un paquete DHCPdiscover.

Nota

Una lectura muy entretenida sobre lo que someramente se ha expuesto aquí son los RFC 2131 y RFC 2132. El primero describe el protocolo y el contenido de los paquetes y el segundo las distintas opciones DHCP.

6.1.1.2. Anatomía del paquete

Ya se ha declarado que DHCP está basado en el protocolo de arranque más antiguo BOOTP, cuya descripción recoge el RFC 951. De hecho, un paquete DHCP es un paquete BOOTP en que los 64 bytes finales que codifican la información específica del vendedor vienen sustituidos por lo que se llaman opciones DHCP, más o menos estandarizadas por distintos RFC como el RFC 2132. Así pues, en un paquete podemos distinguir dos partes, una cabecera BOOTP y la lista de opciones DHCP, separadas ambas por un número mágico de 4 bytes:

../../_images/DHCP_packet.png

El número mágico en el protocolo BOOTP determina la forma en que debe interpretarse la información extendida del servidor. Para el protocolo DHCP el valor es 0x63825363.

Cabecera BOOTP

Contiene la información indispensable para facilitar una dirección IP al cliente. Tan sólo faltan en ella para lograr la configuración básica completa la dirección de la puerta de enlace y ls direcciones de los servidores DNS, que no era información necesaria para el propórito del protocolo BOOTP.

Nombre

Longitud

Descripcion

OP

1

Tipo de mensaje: 1 (cliente), 2 (servidor).

HTYPE

1

Tipo de dirección hardware (1 para MAC).

HLEN

1

Longitud en bytes de la dirección hardware.

HOPS

1

Contador (el cliente lo fija a 0) que se incrementa al pasar por un relay.

XID

4

Identificador de la comunicación para que el cliente sepa suya la respuesta del servidor.

SECS

2

Segundos desde el comienzo de la petición del cliente. Lo usan los relays.

FLAGS

2

Sólo se usa el 1 bit.

CIADDR

4

IP del cliente que solicita el propio cliente al servidor.

YIADDR

4

IP concedida al cliente por el servidor.

SIADDR

4

IP del servidor que continuará la secuencia de arranque.

GIADDR

4

IP del agente de relay. Si vale, cliente y servidor están en la misma red.

CHADDR

16

Dirección hardware del cliente (si estamos en ethernet, la MAC).

SNAME

64

Nombre del servidor DHCP (es opcional).

FILE

128

Nombre del fichero de arranque (ver pxe) hospedado en SIADDR.

Opciones DHCP

Las distintas opciones DHCP que pueden incluirse en el paquete permiten incorporan información adicional a la incluida en la cabecera. Todas empiezan por un byte inicial que les sirve de etiqueta y que podemos asimilar a un número entre 0 y 2552, de ahí que a lo largo del texto hablemos de la opción DHCP 3 o la opción 121, lo que ha de entenderse como la opción etiquetada con el número 3 o con el número 121.

Estas opciones pueden ser estándar, es decir, haberse definido en un RFC (el principal a este efecto es el RFC 2132) o no. En el caso de estas opciones no estándar lo habitual es que utilicen etiquetas que no han sido definidas en ningún RFC. Una lista exahustiva de estas opciones puede leerse en este enlace de la IANA.

En particular, nos interesa adelantar las dos opciones que nos permiten acabar de definir una configuración básica de red:

  • La 3, que define la puerta de enlace.

  • La 6, que define los direcciones de los servidores de nombres.

6.1.1.3. Identificación del cliente

Es obvio que el servidor debe ser capaz de identificar a cada cliente, a fin de saber si quien le pide una IP es aquel al que se la concedió anteriormente o por el contrario es otro diferente.

Podríamos estar tentados en pensar que la identificación se hace a través de la dirección MAC, pero no es cierto del todo. El protocolo establece que la forma en que el servidor identifica a los clientes es mediante el parámetro UID (en dhclient este parámetro se llama dhcp-client-identifier) que debe enviar el cliente al servidor. Sólo en caso de que el cliente no envíe este parámetro, el servidor se valdrá de la dirección MAC. Es importante tener esto presente, puesto que hay clientes que de modo predeterminado no mandan UID alguno (p.e. los que incorporan las interfaces para el arranque a través de la red) y otros que si lo hacen (como el de windows). Este hecho provoca que, si se cumple el RFC 2131 un mismo ordenador con una única tarjeta de red, pueda acaparar dos direcciones IP distintas si arranca con un sistema, no informa al servidor de que libera la IP y arranca luego con el otro.

Nota

Para el caso particular del servidor ISC a partir de su versión 4.3, existe una directiva que identifica exclusivamente a los clientes por la dirección MAC de la tarjeta (y rompe por tanto con la norma):

ignore-client-uids on;

Enlaces de interés

Notas al pie

1

Esta lista de parámetros es característica de cada cliente hasta el punto de que puede usarse como fingerprint para identificarlos.

2

Esta última etiqueta está reservada para significar que ya no hay más opciones en el paquete, asíq eu todo paquete se cerrará con esta opción.