El Protocolo de configuración dinámica de host ( DHCP ) es un protocolo de administración de red utilizado en redes de Protocolo de Internet (IP) para asignar automáticamente direcciones IP y otros parámetros de comunicación a dispositivos conectados a la red mediante una arquitectura cliente-servidor . [1]
La tecnología elimina la necesidad de configurar manualmente los dispositivos de red individualmente y consta de dos componentes de red, un servidor DHCP de red instalado centralmente y instancias cliente de la pila de protocolos en cada computadora o dispositivo. Cuando se conecta a la red, y posteriormente periódicamente, un cliente solicita un conjunto de parámetros del servidor mediante DHCP.
DHCP se puede implementar en redes que varían en tamaño, desde redes residenciales hasta redes de campus grandes y redes de ISP regionales. [2] Muchos enrutadores y puertas de enlace residenciales tienen capacidad de servidor DHCP. La mayoría de los enrutadores de redes residenciales reciben una dirección IP única dentro de la red del ISP. Dentro de una red local, un servidor DHCP asigna una dirección IP local a cada dispositivo.
Los servicios DHCP existen para redes que ejecutan el Protocolo de Internet versión 4 (IPv4), así como la versión 6 ( IPv6 ). La versión IPv6 del protocolo DHCP se denomina comúnmente DHCPv6 .
El Protocolo de resolución de direcciones inversas (RARP) se definió en 1984 [3] para la configuración de dispositivos simples, como estaciones de trabajo sin disco , con una dirección IP adecuada. Al actuar en la capa de enlace de datos , dificultó la implementación en muchas plataformas de servidores. Requería que hubiera un servidor presente en cada enlace de red individual. RARP fue reemplazado por el Protocolo Bootstrap (BOOTP) definido en septiembre de 1985. [4] Esto introdujo el concepto de agente de retransmisión, que permitía el reenvío de paquetes BOOTP a través de redes, permitiendo que un servidor BOOTP central sirviera hosts en muchas subredes IP.
DHCP se definió por primera vez en octubre de 1993. [5] [6] Se basa en BOOTP, pero puede asignar dinámicamente direcciones IP de un grupo y reclamarlas cuando ya no estén en uso. También se puede utilizar para ofrecer una amplia gama de parámetros de configuración adicionales a clientes IP, incluidos parámetros específicos de la plataforma. [7]
Cuatro años después, se agregaron el tipo de mensaje DHCPINFORM (usado para WPAD ) y otros pequeños cambios. Esta definición, de 1997, [8] sigue siendo el núcleo del estándar para las redes IPv4.
DHCPv6 se definió inicialmente en 2003. [9] Después de actualizaciones de muchos RFC posteriores, su definición fue reemplazada en 2018, [10] donde ahora se fusionaron la delegación de prefijos y la configuración automática de direcciones sin estado .
El Protocolo de Internet (IP) define cómo se comunican los dispositivos dentro y a través de redes locales en Internet. Un servidor DHCP puede administrar la configuración de IP para dispositivos en su red local, por ejemplo, asignando direcciones IP a esos dispositivos de forma automática y dinámica. [11]
DHCP opera según el modelo cliente-servidor . Cuando una computadora u otro dispositivo se conecta a una red, el software del cliente DHCP envía una consulta de transmisión DHCP solicitando la información necesaria. Cualquier servidor DHCP de la red puede atender la solicitud. El servidor DHCP administra un conjunto de direcciones IP e información sobre los parámetros de configuración del cliente, como la puerta de enlace predeterminada , el nombre de dominio , los servidores de nombres y los servidores de hora . Al recibir una solicitud DHCP, el servidor DHCP puede responder con información específica para cada cliente, previamente configurada por un administrador, o con una dirección específica y cualquier otra información válida para toda la red y para el período de tiempo por el cual se realiza la asignación ( arrendamiento) . ) es válida. Un cliente DHCP normalmente consulta esta información inmediatamente después del inicio y, posteriormente, periódicamente antes de que expire la información. Cuando un cliente DHCP actualiza una asignación, inicialmente solicita los mismos valores de parámetros, pero el servidor DHCP puede asignar una nueva dirección según las políticas de asignación establecidas por los administradores.
En redes grandes que constan de múltiples enlaces, un único servidor DHCP puede dar servicio a toda la red cuando cuenta con la ayuda de agentes de retransmisión DHCP ubicados en los enrutadores de interconexión. Dichos agentes transmiten mensajes entre clientes DHCP y servidores DHCP ubicados en diferentes subredes.
Según la implementación, el servidor DHCP puede tener tres métodos para asignar direcciones IP:
Los servicios DHCP se utilizan para el Protocolo de Internet versión 4 (IPv4) e IPv6 . Los detalles del protocolo para IPv4 e IPv6 difieren lo suficiente como para considerarlos protocolos separados. [12] Para el funcionamiento de IPv6, los dispositivos pueden utilizar alternativamente la configuración automática de direcciones sin estado . Los hosts IPv6 también pueden usar direccionamiento de enlace local para lograr operaciones restringidas al enlace de la red local.
El DHCP emplea un modelo de servicio sin conexión , utilizando el Protocolo de datagramas de usuario (UDP). Está implementado con dos números de puerto UDP para sus operaciones que son los mismos que para el protocolo bootstrap ( BOOTP ). El servidor escucha en el puerto UDP número 67 y el cliente escucha en el puerto UDP número 68.
Las operaciones de DHCP se dividen en cuatro fases: descubrimiento del servidor, oferta de arrendamiento de IP, solicitud de arrendamiento de IP y confirmación de arrendamiento de IP. Estas etapas a menudo se abrevian como DORA para descubrimiento, oferta, solicitud y reconocimiento.
La operación DHCP comienza cuando los clientes transmiten una solicitud. Si el cliente y el servidor están en dominios de transmisión diferentes , se puede utilizar un asistente DHCP o un agente de retransmisión DHCP. Los clientes que soliciten la renovación de un contrato de arrendamiento existente pueden comunicarse directamente a través de unidifusión UDP , ya que el cliente ya tiene una dirección IP establecida en ese momento. Además, hay un indicador BROADCAST (1 bit en el campo de indicadores de 2 bytes, donde todos los demás bits están reservados y, por lo tanto, se establecen en 0) que el cliente puede usar para indicar de qué manera (difusión o unidifusión) puede recibir el DHCPOFFER: 0x8000 para transmisión, 0x0000 para unidifusión. [8] Generalmente, el DHCPOFFER se envía mediante unidifusión. Para aquellos hosts que no pueden aceptar paquetes de unidifusión antes de que se configuren las direcciones IP, este indicador se puede utilizar para solucionar este problema.
El cliente DHCP transmite un mensaje DHCPDISCOVER en la subred de la red utilizando la dirección de destino 255.255.255.255 (difusión limitada) o la dirección de transmisión de subred específica (difusión dirigida). Un cliente DHCP también puede solicitar una dirección IP en el DHCPDISCOVER, que el servidor puede tener en cuenta al seleccionar una dirección a ofrecer.
Por ejemplo, si HTYPE se establece en 1, para especificar que el medio utilizado es Ethernet , HLEN se establece en 6 porque una dirección Ethernet (dirección MAC) tiene 6 octetos de longitud. El CHADDR se establece en la dirección MAC utilizada por el cliente. Algunas opciones también están configuradas.
Cuando un servidor DHCP recibe un mensaje DHCPDISCOVER de un cliente, que es una solicitud de concesión de dirección IP, el servidor DHCP reserva una dirección IP para el cliente y hace una oferta de concesión enviando un mensaje DHCPOFFER al cliente. Este mensaje contiene la identificación del cliente (tradicionalmente una dirección MAC), la dirección IP que ofrece el servidor, la máscara de subred, la duración del arrendamiento y la dirección IP del servidor DHCP que realiza la oferta. El servidor DHCP también puede tomar nota de la dirección MAC a nivel de hardware en la capa de transporte subyacente: según los RFC actuales , la dirección MAC de la capa de transporte puede usarse si no se proporciona ningún ID de cliente en el paquete DHCP.
El servidor DHCP determina la configuración basándose en la dirección de hardware del cliente como se especifica en el campo CHADDR (dirección de hardware del cliente). En el siguiente ejemplo, el servidor ( 192.168.1.1 ) especifica la dirección IP del cliente en el campo YIADDR (su dirección IP).
En respuesta a la oferta de DHCP, el cliente responde con un mensaje DHCPREQUEST, transmitido al servidor, [a] solicitando la dirección ofrecida. Un cliente puede recibir ofertas DHCP de varios servidores, pero solo aceptará una oferta DHCP. Antes de reclamar una dirección IP, el cliente transmitirá una solicitud ARP para encontrar si hay otro host presente en la red con la dirección IP propuesta. Si no hay respuesta, esta dirección no entra en conflicto con la de otro host, por lo que su uso es gratuito.
El cliente deberá enviar la opción de identificación del servidor en el mensaje DHCPREQUEST, indicando el servidor cuya oferta ha seleccionado el cliente. [8] : Sección 3.1, Punto 3 Cuando otros servidores DHCP reciben este mensaje, retiran cualquier oferta que hayan hecho al cliente y devuelven la dirección IP ofrecida al grupo de direcciones disponibles.
Cuando el servidor DHCP recibe el mensaje DHCPREQUEST del cliente, el proceso de configuración entra en su fase final. La fase de reconocimiento implica enviar un paquete DHCPACK al cliente. Este paquete incluye la duración del arrendamiento y cualquier otra información de configuración que el cliente pueda haber solicitado. En este punto, se completa el proceso de configuración de IP.
El protocolo espera que el cliente DHCP configure su interfaz de red con los parámetros negociados.
Después de que el cliente obtiene una dirección IP, debe probar la dirección recién recibida [8] : sec. 2.2 (por ejemplo, con el protocolo de resolución de direcciones ARP ) para evitar conflictos de direcciones causados por la superposición de grupos de direcciones de servidores DHCP. Si esta sonda encuentra otra computadora usando esa dirección, la computadora debe enviar DHCPDECLINE, transmisión, al servidor.
Un cliente DHCP puede solicitar más información que la que el servidor envió con el DHCPOFFER original. El cliente también podrá solicitar datos repetidos para una aplicación concreta. Por ejemplo, los navegadores utilizan DHCP Inform para obtener la configuración del proxy web a través de WPAD .
El cliente envía una solicitud al servidor DHCP para liberar la información DHCP y el cliente desactiva su dirección IP. Como los dispositivos cliente generalmente no saben cuándo los usuarios pueden desconectarlos de la red, el protocolo no exige el envío de DHCP Release .
Un servidor DHCP puede proporcionar parámetros de configuración opcionales al cliente. RFC 2132 describe las opciones de DHCP disponibles definidas por la Autoridad de Números Asignados de Internet (IANA): PARÁMETROS DHCP y BOOTP. [13]
Un cliente DHCP puede seleccionar, manipular y sobrescribir parámetros proporcionados por un servidor DHCP. En sistemas tipo Unix, este refinamiento a nivel de cliente normalmente se lleva a cabo de acuerdo con los valores en el archivo de configuración /etc/dhclient.conf .
Las opciones son cadenas de octetos de longitud variable. Esto se denomina codificación tipo-longitud-valor . El primer octeto es el código de opción, el segundo octeto es el número de octetos siguientes y los octetos restantes dependen del código. Por ejemplo, la opción de tipo de mensaje DHCP para una oferta aparecería como 0x35, 0x01, 0x02, donde 0x35 es el código 53 para "tipo de mensaje DHCP", 0x01 significa que sigue un octeto y 0x02 es el valor de "oferta".
Las siguientes tablas enumeran las opciones de DHCP disponibles. [14] [13]
Esta tabla enumera los tipos de mensajes DHCP, documentados en RFC 2132, RFC 3203, [15] RFC 4388, [16] RFC 6926 [17] y RFC 7724. [18] Estos códigos son el valor en la extensión DHCP 53, que se muestra en la tabla de arriba.
Existe una opción para identificar el proveedor y la funcionalidad de un cliente DHCP. La información es una cadena de caracteres u octetos de longitud variable que tiene un significado especificado por el proveedor del cliente DHCP. Un método mediante el cual un cliente DHCP puede comunicar al servidor que está utilizando un determinado tipo de hardware o firmware es establecer un valor en sus solicitudes DHCP llamado Identificador de clase de proveedor (VCI) (Opción 60).
El valor en el que se establece esta opción le da al servidor DHCP una pista sobre cualquier información adicional requerida que este cliente necesita en una respuesta DHCP. Algunos tipos de decodificadores configuran el VCI para informar al servidor DHCP sobre el tipo de hardware y la funcionalidad del dispositivo. Un punto de acceso inalámbrico del campus de Aruba , por ejemplo, proporciona el valor 'ArubaAP' como opción 60 en su mensaje DHCPDISCOVER. [19] El servidor DHCP puede luego aumentar su DHCPOFFER con una dirección IP de un controlador inalámbrico de Aruba en la opción 43, para que el punto de acceso sepa dónde registrarse.
La configuración de un VCI por parte del cliente permite que un servidor DHCP diferencie entre máquinas cliente y procese las solicitudes de ellas de manera adecuada.
La opción de información del agente de retransmisión (opción 82) especifica el contenedor para adjuntar subopciones a las solicitudes DHCP transmitidas entre una retransmisión DHCP y un servidor DHCP. [20]
En redes pequeñas, donde sólo se administra una subred IP, los clientes DHCP se comunican directamente con los servidores DHCP. Sin embargo, los servidores DHCP también pueden proporcionar direcciones IP para múltiples subredes. En este caso, un cliente DHCP que aún no ha adquirido una dirección IP no puede comunicarse directamente con un servidor DHCP que no esté en la misma subred, ya que la transmisión del cliente sólo puede recibirse en su propia subred.
Para permitir que los clientes DHCP en subredes no servidas directamente por servidores DHCP se comuniquen con servidores DHCP, se pueden instalar agentes de retransmisión DHCP en estas subredes. Un agente de retransmisión DHCP se ejecuta en un dispositivo de red, capaz de enrutar entre la subred del cliente y la subred del servidor DHCP. El cliente DHCP transmite en el enlace local; el agente de retransmisión recibe la transmisión y la transmite a uno o más servidores DHCP mediante unidifusión . Las direcciones IP de los servidores DHCP se configuran manualmente en el agente de retransmisión. El agente de retransmisión almacena su propia dirección IP, desde la interfaz en la que recibió la transmisión del cliente, en el campo GIADDR del paquete DHCP. El servidor DHCP utiliza el valor GIADDR para determinar la subred y, posteriormente, el grupo de direcciones correspondiente, desde el cual asignar una dirección IP. Cuando el servidor DHCP responde al cliente, envía la respuesta a la dirección GIADDR, nuevamente usando unidifusión. Luego, el agente de retransmisión retransmite la respuesta en la red local, mediante unidifusión (en la mayoría de los casos) a la dirección IP recién reservada, en una trama Ethernet dirigida a la dirección MAC del cliente. El cliente debe aceptar el paquete como propio, incluso cuando esa dirección IP aún no esté configurada en la interfaz. [8] : 25 Inmediatamente después de procesar el paquete, el cliente establece la dirección IP en su interfaz y está listo para la comunicación IP regular, inmediatamente después.
Si la implementación de la pila IP por parte del cliente no acepta paquetes de unidifusión cuando aún no tiene una dirección IP, el cliente puede configurar el bit de transmisión en el campo FLAGS al enviar un paquete DHCPDISCOVER. El agente de retransmisión utilizará la dirección IP de transmisión 255.255.255.255 (y la dirección MAC del cliente) para informar al cliente sobre el DHCPOFFER del servidor.
La comunicación entre el agente de retransmisión y el servidor DHCP normalmente utiliza un puerto UDP de origen y de destino de 67.
Un cliente DHCP puede recibir estos mensajes desde un servidor: [8] : Sección 4.4
El cliente pasa por los estados DHCP dependiendo de cómo responde el servidor a los mensajes que envía el cliente.
El DHCP garantiza la confiabilidad de varias maneras: renovación periódica, reenlace, [8] : Sección 4.4.5 y conmutación por error. A los clientes DHCP se les asignan arrendamientos que duran un período de tiempo. Los clientes comienzan a intentar renovar sus contratos de arrendamiento una vez que ha expirado la mitad del intervalo de arrendamiento. [8] : Sección 4.4.5 Párrafo 3 Lo hacen enviando un mensaje DHCPREQUEST de unidifusión al servidor DHCP que otorgó el contrato de arrendamiento original. Si ese servidor está inactivo o es inaccesible, no responderá al DHCPREQUEST . Sin embargo, en ese caso el cliente repite DHCPREQUEST de vez en cuando, [8] : Sección 4.4.5 Párrafo 8 [b] de modo que si el servidor DHCP vuelve a funcionar o vuelve a ser accesible, el cliente DHCP logrará contactarlo y renovar el contrato de arrendamiento.
Si no se puede acceder al servidor DHCP durante un período prolongado de tiempo, [8] : Sección 4.4.5 Párrafo 5, el cliente DHCP intentará volver a vincularse, transmitiendo su DHCPREQUEST en lugar de unidifundirlo. Debido a que se transmite , el mensaje DHCPREQUEST llegará a todos los servidores DHCP disponibles. Si algún otro servidor DHCP puede renovar el contrato de arrendamiento, lo hará en este momento.
Para que la nueva vinculación funcione, cuando el cliente contacta exitosamente con un servidor DHCP de respaldo, ese servidor debe tener información precisa sobre la vinculación del cliente. Mantener información vinculante precisa entre dos servidores es un problema complicado; Si ambos servidores pueden actualizar la misma base de datos de arrendamiento, debe haber un mecanismo para evitar conflictos entre las actualizaciones en los servidores independientes. Se presentó una propuesta para implementar servidores DHCP tolerantes a fallas al Grupo de Trabajo de Ingeniería de Internet, pero nunca se formalizó. [28] [c]
Si la nueva vinculación falla, el contrato de arrendamiento eventualmente expirará. Cuando el contrato de arrendamiento expire, el cliente deberá dejar de utilizar la dirección IP que se le otorgó en su contrato de arrendamiento. [8] : Sección 4.4.5 Párrafo 9 En ese momento, reiniciará el proceso DHCP desde el principio transmitiendo un DHCPDISCOVERmensaje. Dado que su contrato de arrendamiento ha expirado, aceptará cualquier dirección IP que se le ofrezca. Una vez que tenga una nueva dirección IP (presumiblemente de un servidor DHCP diferente), podrá volver a utilizar la red. Sin embargo, dado que su dirección IP cambió, se interrumpirán todas las conexiones en curso.
La metodología básica de DHCP fue desarrollada para redes basadas en el Protocolo de Internet versión 4 (IPv4). Desde el desarrollo y la implementación de redes IPv6 , DHCP también se ha utilizado para asignar parámetros en dichas redes, a pesar de las características inherentes de IPv6 para la configuración automática de direcciones sin estado . La versión IPv6 del protocolo se denomina DHCPv6 . [29]
El DHCP base no incluye ningún mecanismo de autenticación. [30 segundos. 7 Debido a esto, es vulnerable a una variedad de ataques. Estos ataques se dividen en tres categorías principales: [8] : sec. 7
Debido a que el cliente no tiene forma de validar la identidad de un servidor DHCP, se pueden operar servidores DHCP no autorizados (comúnmente llamados " DHCP fraudulentos ") en las redes, proporcionando información incorrecta a los clientes DHCP. [31] Esto puede servir como un ataque de denegación de servicio, impidiendo que el cliente obtenga acceso a la conectividad de la red, [32] o como un ataque de intermediario . [33] Debido a que el servidor DHCP proporciona al cliente DHCP direcciones IP del servidor, como la dirección IP de uno o más servidores DNS, [8] : sec. 7 un atacante puede convencer a un cliente DHCP para que realice sus búsquedas de DNS a través de su propio servidor DNS y, por lo tanto, puede proporcionar sus propias respuestas a las consultas de DNS del cliente. [34] Esto a su vez permite al atacante redirigir el tráfico de la red a través de sí mismo, permitiéndole espiar las conexiones entre el cliente y los servidores de red con los que contacta, o simplemente reemplazar esos servidores de red por los suyos propios. [34]
Debido a que el servidor DHCP no tiene un mecanismo seguro para autenticar al cliente, los clientes pueden obtener acceso no autorizado a direcciones IP presentando credenciales, como identificadores de cliente, que pertenecen a otros clientes DHCP. [31] Esto también permite a los clientes DHCP agotar el almacén de direcciones IP del servidor DHCP: al presentar nuevas credenciales cada vez que solicita una dirección, el cliente puede consumir todas las direcciones IP disponibles en un enlace de red en particular, evitando que otros clientes DHCP obteniendo servicio. [31]
DHCP proporciona algunos mecanismos para mitigar estos problemas. La extensión del protocolo Relay Agent Information Option [30] (generalmente denominada en la industria por su número real como Opción 82 [35] [36] ) permite a los operadores de red adjuntar etiquetas a los mensajes DHCP a medida que estos mensajes llegan a la red confiable del operador de red. . Luego, esta etiqueta se utiliza como token de autorización para controlar el acceso del cliente a los recursos de la red. Debido a que el cliente no tiene acceso a la red ascendente del agente de retransmisión, la falta de autenticación no impide que el operador del servidor DHCP confíe en el token de autorización. [30 segundos. 7
Otra extensión, Autenticación para mensajes DHCP [37] (RFC 3118), proporciona un mecanismo para autenticar mensajes DHCP. En 2002, esta extensión no había tenido una adopción generalizada debido a los problemas de administrar claves para una gran cantidad de clientes DHCP. [38] Un libro de 2007 sobre tecnologías DSL señaló que:
[H]o se identificaron numerosas vulnerabilidades de seguridad frente a las medidas de seguridad propuestas por RFC 3118. Este hecho, combinado con la introducción de 802.1x , ralentizó la implementación y la tasa de adopción de DHCP autenticado, y nunca se ha implementado ampliamente. [39]
Un libro de 2010 señala que:
[H]o ha habido muy pocas implementaciones de autenticación DHCP. Los desafíos de la gestión de claves y los retrasos en el procesamiento debido al cálculo de hash se han considerado un precio demasiado alto a pagar por los beneficios percibidos. [40]
Las propuestas arquitectónicas de 2008 implican la autenticación de solicitudes DHCP utilizando 802.1x o PANA (ambos transportan EAP ). [41] Se hizo una propuesta del IETF para incluir EAP en el propio DHCP, el llamado EAPoDHCP ; [42] esto no parece haber avanzado más allá del nivel del borrador del IETF, el último de los cuales data de 2010. [43]
{{cite journal}}: Citar diario requiere |journal=( ayuda )
Medios relacionados con el Protocolo de configuración dinámica de host (DHCP) en Wikimedia Commons