Protocolo DHCP: Características, Funcionamiento y Alternativas
Enviado por Anónimo y clasificado en Informática y Telecomunicaciones
Escrito el en 
español con un tamaño de 28,89 KB
2.1. Introducción
Ya sea en el hogar, en el trabajo, en un aeropuerto o en una cafetería, siempre existirá alguna red que estará disponible para su uso. La gran mayoría de esas redes serán redes inalámbricas, aunque también es posible que en otras ocasiones sean accesibles a través de rosetas de conexión. En cualquier caso y sea cual sea el método de conexión, lo más probable es que dentro de esa red exista algún servidor encargado de suministrar los datos de configuración IP.
A lo largo de esta unidad, se describirá el servicio encargado de llevar a cabo esta configuración.
2.2. Protocolo DHCP
El protocolo DHCP (Dynamic Host Configuration Protocol, Protocolo de Configuración Dinámica de Host) es un protocolo de la capa de aplicación encargado de configurar automática y dinámicamente los parámetros de conexión de los equipos cliente de una red. Es utilizado en arquitecturas cliente-servidor y da nombre a los servidores que lo implementan.
Este servicio se encuentra embebido incluso en los routers domésticos que los ISP suministran a cada cliente.
2.2.1. Carácterísticas y funcionamiento
El servidor DHCP posee un listado con direcciones IP que van asignándose a los clientes que solicitan parámetros de configuración y conocerá, en todo momento, los dispositivos a los que les ha concedido parámetros de conexión, así como el momento en el que lo ha hecho.
Un servidor que implementa el protocolo DHCP puede trabajar de tres formas diferentes, combinando algunas de ellas incluso al mismo tiempo:
Asignación estática: el servidor asigna una dirección IP concreta a una máquina determinada, la cual es identificada por la dirección MAC o el identificador de cliente. Evita que se conecten clientes no identificados.
Asignación automática: el servidor asigna una dirección IP a una máquina cliente la primera vez que hace la solicitud al servidor DHCP y este la puede utilizar hasta que decida liberarla. Se suele utilizar en escenarios con un número reducido de clientes que se conectan de forma frecuente.
Asignación dinámica: el servidor dispone de un rango de direcciones IP que se ofrece a los clientes que solicitan parámetros válidos de conexión cuando se levantan en la red. Es el único método que permite la reutilización dinámica de las direcciones IP, lo cual facilita la instanación de nuevas máquinas cliente (suele utilizarse en redes con un elevado número de clientes).
2.2.2. Mensajes
Toda comunicación conlleva un intercambio de mensajes que están claramente tipificados por el protocolo:
DHCPDISCOVER: permite descubrir la existencia de posibles servidores DHCP en la red. Se envía mediante difusión (broadcast
). Lo realiza el cliente a través del puerto 68 por UDP.DHCPOFFER: es la respuesta con la concesión ofrecida al cliente. Incluye una dirección de red disponible en el campo "yiaddr" y otros parámetros de configuración en DHCP options. Lo realiza el servidor a través del puerto 67 por UDP.
DHCPREQUEST: indica qué servidor de los que han emitido un DHCPOFFER se ha seleccionado (notificándose también de esta manera que los demás se han descartado). También se utiliza para renovar la concesión. Lo realiza el cliente a través del puerto 68 por UDP.
DHCPACK: contiene los parámetros de configuración de la solicitud del cliente y se utiliza para confirmar la concesión al cliente. Lo realiza el servidor a través del puerto 67 por UDP.
DHCPNACK: deniega la solicitud que hace el cliente para establecer unos datos de configuración (por ejemplo, la dirección IP que solicitó no es válida para la subred en la que se encuentra o ya no la puede asignar porque fue asignada a otro equipo). Lo realiza el servidor a través del puerto 67 por UDP.
DHCPDECLINE: el cliente notifica que la dirección concedida está en uso, por lo que se rechaza la concesión (normalmente, porque otro usuario la asignó manualmente). Lo realiza el cliente a través del puerto 68 por UDP.
DHCPRELEASE: libera la concesión actualmente en uso. Lo realiza el cliente a través del puerto 68 por UDP.
DHCPINFORM: permite solicitar parámetros extras de configuración local (nombre de dominio, servidores DNS del dominio, ...). La respuesta del servidor será un DHCPACK. Lo realiza el cliente a través del puerto 68 por UDP.
Asignación, renovación y liberación
A continuación, se describirá el intercambio típico de mensajes entre clientes y servidores DHCP mediante los cuales se realiza la asignación, renovación y posterior liberación de los parámetros de red.
A) Asignación
El cliente inunda la red con un mensaje
DHCPDISCOVER ( con el que pretende obtener una asignación de datos de configuración válidos. En el mensaje se pueden sugerir determinados parámetros (tiempo de la concesión, dirección sugerida, ...).- El servidor recibe el mensaje DHCPDISCOVER y prepara la respuesta DHCPOFFER (unicast) que incluye una dirección de red disponible (campo "yiaddr"), así como otros parámetros de configuración DHCP.
Los servidores deben comprobar que la dirección de red ofrecida no esté ya en uso, pues podría haberla establecido manualmente otro cliente de la red. Para ello pueden sondear la dirección ofrecida con un ICMP Echo Request.
Aunque no es obligatorio, el servidor puede resevar la dirección de red ofrecida temporalmente para evitar la asignación de la misma dirección de red ofrecida a otro cliente.
- El cliente selecciona una oferta entre todas las recibidas (generalmente, la primera que llegó o la que mejor se ajusta a las posibles sugerencias que incluyó en el DHCPDISCOVER).
Una vez elegida la oferta, prepara y difunde un mensaje DHCPREQUEST (broadcast) con el que identifica al servidor del que se ha seleccionado la oferta y, al mismo tiempo, descarta al resto (mediante la opción "server identifier"). Puede incluir otras opciones que especifican los valores de configuración deseados.
Si el cliente no recibe ofertas en el tiempo máximo de espera establecido, se reiniciará el proceso de asignación mediante un DHCPDISCOVER (paso 1).
- El servidor recibe el DHCPREQUEST difundido desde el cliente:
Si se le notifica a través del mismo que su oferta no ha sido seleccionada, marcará de nuevo la dirección que ofrecíó como disponible.
En caso contrario:
Intentará hacer persistente la oferta que hizo al cliente y responderá con un mensaje DHCPACK que contiene los parámetros de configuración de la solicitud (ninguno debe ser incompatible con los del mensaje DHCPOFFER anterior).
Si el servidor seleccionado no es capaz de satisfacer el mensaje DHCPREQUEST (la dirección de red solicitada puede haberse asignado a otro cliente justo antes), el servidor debe responder con un mensaje DHCPNACK.
- Si el cliente recibe un mensaje DHCPAK con los parámetros de configuración, realizará una validación final de los mismos (mediante el protocolo ARP comprobará que la dirección de red asignada no esté siendo utilizada ya):
Si todo ha ido bien y no se ha detectado que la dirección se esté utilizando previamente, el cliente quedará configurado conforme a los datos recibidos durante el tiempo máximo establecido en la concesión.
- Si, por el contrario, el cliente detecta que la dirección ya está en uso, enviará un mensaje DHCPDECLINE al servidor y reiniciará el proceso de asignación mediante un DHCPDISCOVER (paso 1).
Si el cliente recibe un mensaje DHCPNACK, reiniciará el proceso de asignación mediante un DHCPDISCOVER (paso 1).
B) Renovación
- Las concesiones tienen un tiempo máximo de caducidad conocido como lease time, pero los clientes no esperan a agotarlo para iniciar el proceso de renovación (pues eso supondría comenzar de nuevo con el proceso de configuración mediante un DHCPDISCOVER). Además del tiempo de concesión, existen otros dos tiempos más:
Renewal time (T1): es el tiempo tras el cual el cliente debe intentar hacer la renovación con el servidor DHCP que le ofrecíó la concesión. Puede ser indicado explícitamente por el servidor o, en caso contrario, establecerse directamente por parte del cliente al 50% del tiempo total de la concesión. Una vez alcanzado este tiempo, el cliente procederá a enviar un mensaje DHCPREQUEST (unicast) al servidor que le brindó la configuración con la intención de renovarla.
- Rebinding time (T2): es el tiempo transcurrido el cual el cliente debe enlazar con un servidor DHCP para recibir la renovación de la concesión que está próxima a expirar (solo en caso de no haberse obtenido respuesta por parte del servidor cuando T1 expiró). Puede ser indicado explícitamente por el servidor o, en caso contrario, establecerse directamente por parte del cliente al 87,5% del tiempo total de la concesión. Una vez alcanzado este tiempo, el cliente procederá a difundir mensajes DHCPREQUEST (broadcast) solicitando concesión desde cualquier servidor DHCP (incluido el que le concedíó los parámetros de configuración iniciales, que ahora sí podría estar escuchándole).
Si el servidor acepta la solicitud de renovación de la concesión, enviará un mensaje DHCPACK (unicast). En caso contrario (dirección inválida, dirección ya en uso o concesión realizada por otro servidor en otra red), enviará un mensaje DHCPNACK.
- Si el cliente recibe un mensaje DHCPACK, continuará utilizando los datos de configuración y reestablecerá su periodo de validez. Si recibe un mensaje DHCPNACK o el tiempo de concesión expira sin obtener respuesta del servidor, reiniciará el proceso de obtención de parámetros mediante un DHCPDISCOVER (paso 1).
C) Liberación
- El cliente podrá renunciar a su contrato de arrendamiento iniciando el proceso de liberación mediante el envío de un mensaje DCHPRELEASE al servidor. Esta comunicación es unidirecciónal (no necesita respuesta) y puede motivarla un apagado del equipo, la inhabilitación de interfaz de red o cualquier otra circunstancia que así lo requiera (de no llevarse a cabo, la concesión continuará siendo válida en el servidor hasta que expire su periodo de validez). Algunos clientes envían un mensaje DHCPRELEASE para finalizar el contrato de arrendamiento cuando van a ser apagados/desconectados, pero no es obligatorio hacerlo (la ventaja inherente a ello es que se permite que las direcciones puedan reutilizarse lo antes posible). Sin embargo, los clientes se verán obligados a comenzar el proceso de asignación desde el principio emitiendo un mensaje DHCPDISCOVER cuando arranquen nuevamente.
Reasignación de concesión
En el escenario anterior se parte del supuesto de que el cliente se inicia sin disponer de una concesión previa. Sin embargo, es posible que el equipo cliente se apaque y se encienda de nuevo mientras la concesión sigue siendo válida. En esta situación, el cliente puede solicitar el restablecimiento del arrendamiento existente si realizar todo el proceso completo de asignación. Este proceso se denomina reasignación y consta de los siguientes pasos:
El cliente prepara y difunde un mensaje DHCPREQUEST (broadcast) con información sobre la concesión actual pero, a diferencia del mensaje preparado en el paso 3 del proceso de Asignación, ahora no incluirá la opción que identifica al servidor.
- El servidor recibe el DHCPREQUEST difundido desde el cliente:
Si tiene información sobre la concesión indicada:
Si es válida, responderá con un mensaje DHCPACK.
Si no es válida, responderá con un mensaje DHCPNACK.
Si no tiene información sobre la concesión, no responderá.
A partir de este punto, el proceso es similar al del proceso de Asignación desde el punto 5.
Servidores autorizados
Se puede dar el caso de que un cliente intente renovar la concesión y emita sus mensajes de renovación DHCPREQUEST justo después de haber accedido a una red diferente de aquella en la que estaba cuando obtuvo la concesión. En este caso, el servidor DHCP de la nueva red escuchará los mensajes (pero para una dirección que no ha proporcionado él). Si este servidor se ha configurado como no autorizado, obviará esas solicitudes de renovación con la finalidad de que sea el servidor DHCP original de esas concesiones el que se encargue de renovarlas. Sin embargo, dicho servidor no será accesible al cliente, por lo que será imposible que la concesión se renueve y el servidor quedará mal configurado y sin conexión hasta que la concesión expire (lo cual podría suponer una considerable demora).
Para mitigar este problema, un servidor DHCP puede configurarse como autorizado. Así, tan pronto como detecte un cliente mal configurado que pretende renovar su concesión, le enviará un mensaje DHCPNACK, forzando de esta manera a liberar sus datos actuales de configuración y a comenzar de nuevo el proceso de solicitud de concesión con un mensaje DHCPDISCOVER que será atendido esta vez por el servidor correcto para dicha red.
2.2.3. Ámbitos, rangos, exclusiones, reservas y concesiones (leases)
Un ámbito, en DHCP, es la agrupación administrativa de clientes de una subred a los que se les suministran determinados parámetros de conexión. Dentro de cada ámbito se definien rangos de direcciones, exclusiones y reservas.
El mecanismo mediante el cual el servidor DHCP gestiona las direcciones IP suministradas se basa en el empleo de intervalos de direcciones conocidos como rangos. Estos son conjuntos de direcciones consecutivas que están disponibles para ofrecerse a los clientes que necesitan una configuración de red.
Dentro de esos rangos pueden existir direcciones que no deban ofrecerse a los clientes por tratarse de direciones especiales o que están siendo utilizadas de forma permanente por algún equipo de la red. Se denomina exclusión a cada una de estas direcciones.
De todo el rango de direcciones, también es posible hacer reservas de aquellas que se desea adjudicar a determinados equipos (por ejemplo, un cliente concreto o un servidor que debe configurarse siempre igual, pero que no se ha configurado de forma manual). Para asociar concesiones con clientes, se hace uso de la dirección MAC o el identificador del cliente.
Como resultado de las asignaciones de direcciones que se van haciendo a los clientes, se irán creando concesiones (leases). Estas se almacenarán en los servidores junto con los periodos máximos de validez de las mismas con la finalidad de que puedan liberarse aquellas que vayan caducando y, de esta manera, evitar que se agote el número de direcciones disponible.
2.3. Alternativas a DHCP
Dado que no siembre es posible encontrar un servidor DHCP desde el que realizar la configuración de la interfaz de red, es importante conocer qué mecanismos alternativos existen para evitar dejar aislado al dispositivo dentro de la red. Entre ellos, se encuentran:
2.3.1. Configuración manual
En ausencia de mecanismos de configuración automática, o incluso en presencia de ellos, es posible realizar la configuración de las interfaces de forma manual. Como datos mínimos de configuración en un equipo que trabajará sobre la pila de protocolos TCP/IP siempre será necesario establecer la dirección IP y la máscara (en caso de trabajar con IPv4) o la dirección IP y la longitud del prefijo de red (si se trabaja con IPv6).
2.3.2. APIPA (IPv4)
Puede parecer que, si el dispositivo se ha configurado para obtener una dirección en una interfaz de red de forma automática y no existe un servidor DHCP que ofrezca dichos datos, este quedará incomunicado incluso habiéndose conectado a la red (independientemente de si la conexión se ha realizado por WiFi o por cable).
En SSOO de la familia Microsoft, la implementación de este mecanismo se conoce como APIPA (Automatic Private Internet Protocol Addressing, Direccionamiento Pivado Automático del Protocolo de Internet), aunque también puede conocerse como Auto-IP. Descrito en la RFC 3927, aparecíó por primera vez en Windows 98 y desde entonces se ha incluido en todas las versiones posteriores (el equivalente en SSOO Linux es el demonio de configuración automática de direcciones Link-Local IPv4 avahi-autoipd).
Gracias a APIPA, los equipos configurados para obtener sus parámetros de conexión de forma automática pueden obtener una dirección IP y máscara con la finalidad de permitir una funcionalidad básica. Antes de proponer una dirección de red detecta, por medio de paquetes broadcast, si está en uso (en cuyo caso elegirá otra dirección entre las disponibles). Este servicio no excluye a DHCP, puesto que la asignación realizada mediante este mecanismo es temporal (cada cinco minutos debe intentar conectar nuevamente con algún servidor DHCP).
La agencia de asignación de números de Internet (IANA) reservó las direcciones privada IPv4 de clase B 169.254.0.0/16 para direccionamiento IP privado automático, excluyéndose la primera y la última del rango por pertenecer a la dirección de red y broadcast respectivamente (bloque link-local definido en el RFC 3330).
2.3.3. SLAAC (IPv6)
En IPv6, el mecanismo empleado para asignación automática de IP en interfaces de red es SLAAC (StateLess Address AutoConfiguration), que está descrito en la RFC 4862. Este mecanismo funciona de la siguiente manera:
Un nodo arranca su sistema y crea automáticamente una dirección de enlace local no enrutable con el prefijo ff80::/10 en cada interfaz habilitada para IPv6.
A través de esa interfaz de enlace local, el nodo recibe un mensaje ICMPv6 134 (Router Advertisement o RA) desde el router, con el que este le notifica que él es el router del segmento de red y le suministra parámetros de configuración de la capa de Internet, entre los que se encuentra una de las siguientes opciones:
Opción 1 SLAAC: el nodo debe utilizar la información del prefijo y gateway suministrada por el router (no se suministra más información).
Opción 2 SLAAC y DHCPv6: similar a la opción 1, pero debe completarse la configuración (servidores DNS) mediante consultas a un servidor DHCPv6.
Opción 3 DHCPv6: se indica al nodo que debe obtener toda la configuración desde un servidor DHCPv6.
Los mensajes RA son emitidos por el router de forma periódica a la dirección multicast ff01::1, aunque también pueden ser emitidos como respuesta a un mensaje ICMPv6 133 (Router Solicitation o RS) a la dirección de enlace local del nodo que lo envió para conocer quién era el router del segmento.
2.5. Protocolo BOOTP
Aunque se ha descrito en detalle qué es y en qué consiste el protocolo DHCP, aún no se ha mencionado que sus orígenes residen en el protocolo BOOTP (Bootstrap Protocol). Este protocolo de red está descrito en la RFC 951 y, al igual que DHCP, trabaja sobre UDP. Lo utilizan los clientes para obtener una dirección IP automáticamente y, una vez asignada, cargar la imagen de un SO con el que arrancar mediante el protocolo TFTP.
Inicialmente era necesario introducir un dispositivo previo de arranque específico en el equipo (disquete) para poder después iniciar el cliente BOOTP desde él, pero hoy en día esta funcionalidad ya se incluye de base en casi la totalidad de las BIOS y UEFI del mercado.