Protocolo de configuración dinámica de host (DHCP)

format_list_bulleted Contenido keyboard_arrow_down
ImprimirCitar

El Protocolo de configuración dinámica de host (DHCP) es un protocolo de administración de red que se utiliza 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.

La tecnología elimina la necesidad de configurar individualmente los dispositivos de red manualmente y consta de dos componentes de red, un servidor DHCP de red instalado centralmente e instancias de cliente de la pila de protocolos en cada computadora o dispositivo. Cuando se conecta a la red, y periódicamente a partir de entonces, un cliente solicita un conjunto de parámetros del servidor DHCP utilizando el protocolo DHCP.

DHCP se puede implementar en redes que varían en tamaño, desde redes residenciales hasta grandes redes de campus y redes ISP regionales. 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 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.

Historia

El Protocolo de resolución de dirección inversa (RARP) se definió en RFC 903 en 1984 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 servidor. Requería que un servidor estuviera presente en cada enlace de red individual. RARP fue reemplazado por el Protocolo Bootstrap (BOOTP) definido en RFC 951 en septiembre de 1985. Esto introdujo el concepto de un agente de retransmisión, que permitió el reenvío de paquetes BOOTP a través de redes, lo que permitió que un servidor BOOTP central sirviera hosts en muchas subredes IP.

DHCP 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 los clientes de IP, incluidos los parámetros específicos de la plataforma. DHCP se definió por primera vez en RFC 1531 en octubre de 1993, pero debido a errores en el proceso editorial se volvió a publicar casi de inmediato como RFC 1541.

Cuatro años más tarde, RFC 2131 agregó el tipo de mensaje DHCPINFORM y otros pequeños cambios, que a partir de 2021 sigue siendo el núcleo del estándar para redes IPv4, con actualizaciones en RFC 3396, RFC 4361, RFC 5494 y RFC 6842.

DHCPv6 se describió inicialmente por RFC 3315 en 2003. Después de las actualizaciones de muchos RFC posteriores, se reemplazó con RFC 8415, que se fusionó en la delegación de prefijos y la configuración automática de direcciones sin estado.

Visión general

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.

DHCP opera en base al modelo cliente-servidor. Cuando una computadora u otro dispositivo se conecta a una red, el software del cliente DHCP envía una consulta de difusión DHCP solicitando la información necesaria. Cualquier servidor DHCP en 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 tiempo. 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 por el período de tiempo para el cual la asignación (lease) es válida. Un cliente DHCP normalmente consulta esta información inmediatamente después del arranque y periódicamente antes de que caduque 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 solo servidor DHCP puede dar servicio a toda la red con la ayuda de agentes de retransmisión DHCP ubicados en los enrutadores interconectados. Dichos agentes retransmiten 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:Asignación dinámicaUn administrador de red reserva un rango de direcciones IP para DHCP, y cada cliente DHCP en la LAN está configurado para solicitar una dirección IP del servidor DHCP durante la inicialización de la red. El proceso de solicitud y concesión utiliza un concepto de arrendamiento con un período de tiempo controlable, lo que permite que el servidor DHCP recupere y luego reasigne las direcciones IP que no se renueven.Asignación automáticaEl servidor DHCP asigna permanentemente una dirección IP a un cliente solicitante de un rango definido por un administrador. Esto es como una asignación dinámica, pero el servidor DHCP mantiene una tabla de asignaciones de direcciones IP anteriores, de modo que puede asignar preferentemente a un cliente la misma dirección IP que tenía el cliente anteriormente.Asignación manualEste método también se denomina asignación de DHCP estática, asignación de direcciones fijas, reserva y vinculación de direcciones MAC/IP. Un administrador asigna un identificador único (una identificación de cliente o dirección MAC) para cada cliente a una dirección IP, que se ofrece al cliente solicitante. Los servidores DHCP pueden configurarse para recurrir a otros métodos si esto falla.

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 que puedan considerarse protocolos separados. 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 el direccionamiento local de enlace para lograr operaciones restringidas al enlace de red local.

Operación

El DHCP emplea un modelo de servicio sin conexión, utilizando el Protocolo de datagramas de usuario (UDP). Se implementa con dos números de puerto UDP para sus operaciones que son los mismos que para el protocolo bootstrap (BOOTP). El puerto UDP número 67 es el puerto de destino de un servidor, y el puerto UDP número 68 lo utiliza el cliente.

Las operaciones de DHCP se dividen en cuatro fases: detección de servidores, oferta de arrendamiento de IP, solicitud de arrendamiento de IP y reconocimiento de arrendamiento de IP. Estas etapas a menudo se abrevian como DORA para descubrimiento, oferta, solicitud y reconocimiento.

La operación de DHCP comienza cuando los clientes transmiten una solicitud. Si el cliente y el servidor están en diferentes dominios de difusión, se puede utilizar un auxiliar de DHCP o un agente de retransmisión de 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 DHCPOFFER: 0x8000 para difusión, 0x0000 para unidifusión. Por lo general, DHCPOFFER se envía a través de 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 usar para solucionar este problema.

Descubrimiento

El cliente DHCP difunde un mensaje DHCPDISCOVER en la subred de la red mediante la dirección de destino 255.255.255.255 (difusión limitada) o la dirección de difusión de la subred específica (difusión dirigida). Un cliente DHCP también puede solicitar su última dirección IP conocida. Si el cliente permanece conectado a la misma red, el servidor puede conceder la solicitud. De lo contrario, depende de si el servidor está configurado como autorizado o no. Un servidor autorizado niega la solicitud, lo que hace que el cliente emita una nueva solicitud. Un servidor no autorizado simplemente ignora la solicitud, lo que lleva a un tiempo de espera dependiente de la implementación para que el cliente caduque la solicitud y solicite una nueva dirección IP.

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 una longitud de 6 octetos. El CHADDR se establece en la dirección MAC utilizada por el cliente. También se establecen algunas opciones.

Ethernet: fuente = MAC del remitente; destino= FF:FF:FF:FF:FF:FF
IP: fuente= 0.0.0.0; destino= 255.255.255.255UDP: puerto de origen=68; puerto de destino=67
Octeto 0Octeto 1Octeto 2Octeto 3
OPTIPO HHLENLÚPULO
0x010x010x060x00
ID X
0x3903F326
SECSBANDERAS
0x00000x0000
CIADDR (dirección IP del cliente)
0x00000000
YIADDR (Tu dirección IP)
0x00000000
SIADDR (dirección IP del servidor)
0x00000000
GIADDR (dirección IP de la puerta de enlace)
0x00000000
CHADDR (dirección de hardware del cliente)
0x00053C04
0x8D590000
0x00000000
0x00000000
192 octetos de ceros o espacio de desbordamiento para opciones adicionales; Legado BOOTP.
galleta mágica
0x63825363
Opciones de DHCP
0x350101 53: 1 (DHCP Descubrir)
0x3204c0a80164 50: 192.168.1.100 solicitado
0x370401030f06 55 (Lista de solicitudes de parámetros):1 (Solicitar máscara de subred),3 (enrutador),15 (Nombre de Dominio),6 (Servidor de nombres de dominio)
0xff 255 (Marca final)

Oferta

Cuando un servidor DHCP recibe un mensaje DHCPDISCOVER de un cliente, que es una solicitud de arrendamiento de dirección IP, el servidor DHCP reserva una dirección IP para el cliente y realiza una oferta de arrendamiento mediante el envío de un mensaje DHCPOFFER al cliente. Este mensaje contiene la identificación del cliente del cliente (tradicionalmente una dirección MAC), la dirección IP que ofrece el servidor, la máscara de subred, la duración de la concesión 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 de nivel de hardware en la capa de transporte subyacente: de acuerdo con los RFC actuales, la dirección MAC de la capa de transporte se puede usar si no se proporciona una ID de cliente en el paquete DHCP.

El servidor DHCP determina la configuración según la dirección de hardware del cliente como se especifica en el campo CHADDR (dirección de hardware del cliente). Aquí el servidor, 192.168.1.1, especifica la dirección IP del cliente en el campo YIADDR (su dirección IP).

Ethernet: fuente = MAC del remitente; destino=dirección mac del cliente
IP: fuente= 192.168.1.1; destino= 192.168.1.100UDP: puerto de origen=67; puerto de destino=68
Octeto 0Octeto 1Octeto 2Octeto 3
OPTIPO HHLENLÚPULO
0x020x010x060x00
ID X
0x3903F326
SECSBANDERAS
0x00000x0000
CIADDR (dirección IP del cliente)
0x00000000
YIADDR (Tu dirección IP)
0xC0A80164 (192.168.1.100)
SIADDR (dirección IP del servidor)
0xC0A80101 (192.168.1.1)
GIADDR (dirección IP de la puerta de enlace)
0x00000000
CHADDR (dirección de hardware del cliente)
0x00053C04
0x8D590000
0x00000000
0x00000000
192 octetos de 0s; Legado BOOTP.
galleta mágica
0x63825363
Opciones de DHCP
53: 2 (Oferta DHCP)
1 (máscara de subred): 255.255.255.0
3 (enrutador): 192.168.1.1
51 (tiempo de arrendamiento de la dirección IP): 86400s (1 día)
54 (servidor DHCP): 192.168.1.1
6 (servidores DNS):9.7.10.15,9.7.10.16,9.7.10.18

Solicitud

En respuesta a la oferta DHCP, el cliente responde con un mensaje DHCPREQUEST, transmitido al servidor, solicitando la dirección ofrecida. Un cliente puede recibir ofertas de DHCP de varios servidores, pero solo aceptará una oferta de DHCP. Antes de reclamar una dirección IP, el cliente transmitirá una solicitud ARP para averiguar 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 es libre de usar.

El cliente debe enviar la opción de identificación del servidor en el mensaje DHCPREQUEST, indicando el servidor cuya oferta ha seleccionado el cliente. 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.

Ethernet: fuente = MAC del remitente; destino= FF:FF:FF:FF:FF:FF
IP: fuente= 0.0.0.0; destino= 255.255.255.255; UDP: puerto de origen=68; puerto de destino=67
Octeto 0Octeto 1Octeto 2Octeto 3
OPTIPO HHLENLÚPULO
0x010x010x060x00
ID X
0x3903F326
SECSBANDERAS
0x00000x0000
CIADDR (dirección IP del cliente)
0xC0A80164 (192.168.1.100)
YIADDR (Tu dirección IP)
0x00000000
SIADDR (dirección IP del servidor)
0xC0A80101 (192.168.1.1)
GIADDR (dirección IP de la puerta de enlace)
0x00000000
CHADDR (dirección de hardware del cliente)
0x00053C04
0x8D590000
0x00000000
0x00000000
192 octetos de 0s; Legado BOOTP.
galleta mágica
0x63825363
Opciones de DHCP
53: 3 (Solicitud DHCP)
50: 192.168.1.100 solicitado
54 (servidor DHCP): 192.168.1.1

Reconocimiento

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 el envío de 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 sondear la dirección recién recibida (por ejemplo, con el Protocolo de resolución de direcciones ARP) para evitar conflictos de direcciones causados ​​por conjuntos de direcciones superpuestas de servidores DHCP. Si esta sonda encuentra otra computadora que usa esa dirección, la computadora debe enviar DHCPDECLINE, difusión, al servidor.

Ethernet: fuente = MAC del remitente; destino = MAC del cliente
IP: fuente= 192.168.1.1; destino= 192.168.1.100UDP: puerto de origen=67; puerto de destino=68
Octeto 0Octeto 1Octeto 2Octeto 3
OPTIPO HHLENLÚPULO
0x020x010x060x00
ID X
0x3903F326
SECSBANDERAS
0x00000x0000
CIADDR (dirección IP del cliente)
0x00000000
YIADDR (Tu dirección IP)
0xC0A80164 (192.168.1.100)
SIADDR (dirección IP del servidor)
0xC0A80101 (192.168.1.1)
GIADDR (dirección IP de puerta de enlace conmutada por relé)
0x00000000
CHADDR (dirección de hardware del cliente)
0x00053C04
0x8D590000
0x00000000
0x00000000
192 octetos de 0s. legado BOOTP
galleta mágica
0x63825363
Opciones de DHCP
53: 5 (DHCP RECONOCIMIENTO)
1 (máscara de subred): 255.255.255.0
3 (enrutador): 192.168.1.1
51 (tiempo de arrendamiento de la dirección IP): 86400s (1 día)
54 (servidor DHCP): 192.168.1.1
6 (servidores DNS):9.7.10.15,9.7.10.16,9.7.10.18

Información

Un cliente DHCP puede solicitar más información que el servidor enviado con el DHCPOFFER original. El cliente también puede solicitar datos repetidos para una aplicación en particular. Por ejemplo, los navegadores usan DHCP Inform para obtener la configuración del proxy web a través de WPAD.

Liberando

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.

Parámetros de configuración del cliente

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.

Un cliente DHCP puede seleccionar, manipular y sobrescribir parámetros proporcionados por un servidor DHCP. En los sistemas similares a Unix, este refinamiento a nivel de cliente generalmente se lleva a cabo de acuerdo con los valores en el archivo de configuración /etc/dhclient.conf.

Opciones

Las opciones son cadenas de octetos de longitud variable. Esto se denomina codificación de 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, tal como se enumeran en RFC 2132 y el registro de la IANA.

CódigoNombreLongitudnotas
0Almohadilla0 octetosSe puede usar para rellenar otras opciones para que estén alineadas con el límite de la palabra; no va seguido del byte de longitud
1Máscara de subred4 octetosMáscara de subred del cliente según RFC 950. Si se incluyen tanto la máscara de subred como la opción de enrutador (opción 3), la opción de máscara de subred debe ser la primera.
2Desplazamiento de tiempo4 octetosDesplazamiento de la subred del cliente en segundos desde el tiempo universal coordinado (UTC). El desplazamiento se expresa como un entero de 32 bits en complemento a dos. Un desplazamiento positivo indica una ubicación al este del meridiano cero y un desplazamiento negativo indica una ubicación al oeste del meridiano cero.
3enrutadormúltiplos de 4 octetosLos enrutadores disponibles deben enumerarse en orden de preferencia
4servidor de tiempomúltiplos de 4 octetosLos servidores de tiempo disponibles para sincronizar deben enumerarse en orden de preferencia
5Nombre del servidormúltiplos de 4 octetosLos servidores de nombres IEN 116 disponibles deben enumerarse en orden de preferencia
6Servidor de nombres de dominiomúltiplos de 4 octetosLos servidores DNS disponibles deben enumerarse en orden de preferencia
7servidor de registromúltiplos de 4 octetosServidores de registro disponibles, deben enumerarse en orden de preferencia
8servidor de cookiesmúltiplos de 4 octetosCookie en este caso significa "galleta de la fortuna" o "cita del día", una anécdota concisa o humorística que a menudo se envía como parte de un proceso de inicio de sesión en computadoras grandes; no tiene nada que ver con las cookies enviadas por los sitios web.
9Servidor LPRmúltiplos de 4 octetosUna lista de servidores de impresora de línea RFC 1179 disponibles para el cliente, debe aparecer en orden de preferencia
10servidor de impresiónmúltiplos de 4 octetosUna lista de los servidores de Imagen Impress disponibles para el cliente, debe enumerarse en orden de preferencia
11Servidor de ubicación de recursosmúltiplos de 4 octetosUna lista de servidores de ubicación de recursos RFC 887 disponibles para el cliente, debe aparecer en orden de preferencia
12nombre de hostMínimo de 1 octetoNombre del cliente. El nombre puede estar calificado con el nombre de dominio local.
13Tamaño del archivo de arranque2 octetosLongitud de la imagen de arranque en bloques 512B
14Archivo de volcado de méritosMínimo de 1 octetoRuta donde se deben almacenar los volcados de memoria
15Nombre de dominioMínimo de 1 octeto
dieciséisservidor de intercambio4 octetos
17Ruta raízMínimo de 1 octeto
18Ruta de extensionesMínimo de 1 octeto
255Final0 octetosSe utiliza para marcar el final del campo de opción de proveedor
CódigoNombreLongitudnotas
19Habilitar/deshabilitar el reenvío de IP1 octeto
20Habilitar/deshabilitar enrutamiento de origen no local1 octeto
21Filtro de políticasmúltiplos de 8 octetos
22Tamaño máximo de reensamblaje de datagramas2 octetos
23Tiempo de vida de IP predeterminado1 octeto
24Tiempo de espera de vencimiento de MTU de ruta4 octetos
25Mesa Path MTUmúltiplos de 2 octetos
CódigoNombreLongitudnotas
26Interfaz MTU2 octetos
27Todas las subredes son locales1 octeto
28Dirección de Difusión4 octetos
29Realizar descubrimiento de máscara1 octeto
30Proveedor de máscaras1 octeto
31Realizar el descubrimiento del enrutador1 octeto
32Dirección de solicitud del enrutador4 octetos
33Ruta estáticamúltiplos de 8 octetosUna lista de pares de destino/enrutador
CódigoNombreLongitudnotas
34Opción de encapsulación de remolque1 octeto
35Tiempo de espera de caché ARP4 octetos
36Encapsulación Ethernet1 octeto
CódigoNombreLongitudnotas
37TTL predeterminado de TCP1 octeto
38Intervalo de mantenimiento de TCP4 octetos
39Basura de mantenimiento de TCP1 octeto
CódigoNombreLongitudnotas
40Dominio del servicio de información de redMínimo de 1 octeto
41Servidores de información de redmúltiplos de 4 octetos
42Servidores de protocolo de tiempo de red (NTP)múltiplos de 4 octetos
43Información específica del proveedorMínimo de 1 octetos
44Servidor de nombres NetBIOS sobre TCP/IPmúltiplos de 4 octetos
45Servidor de distribución de datagramas NetBIOS sobre TCP/IPmúltiplos de 4 octetos
46NetBIOS sobre tipo de nodo TCP/IP1 octeto
47NetBIOS sobre alcance TCP/IPMínimo de 1 octeto
48Servidor de fuentes del sistema X Windowmúltiplos de 4 octetos
49Administrador de pantalla del sistema X Windowmúltiplos de 4 octetos
64Servicio de información de red + dominioMínimo de 1 octeto
sesenta y cincoServicio de información de red + servidoresmúltiplos de 4 octetos
68Agente local de IP móvilmúltiplos de 4 octetos
69Servidor de protocolo simple de transferencia de correo (SMTP)múltiplos de 4 octetos
70Servidor de protocolo de oficina postal (POP3)múltiplos de 4 octetos
71Servidor de protocolo de transferencia de noticias de red (NNTP)múltiplos de 4 octetos
72Servidor World Wide Web (WWW) predeterminadomúltiplos de 4 octetos
73Servidor de protocolo Finger predeterminadomúltiplos de 4 octetos
74Servidor predeterminado de Internet Relay Chat (IRC)múltiplos de 4 octetos
75Servidor StreetTalkmúltiplos de 4 octetos
76Servidor de asistencia de directorio de StreetTalk (STDA)múltiplos de 4 octetos
CódigoNombreLongitudnotas
50Dirección IP solicitada4 octetos
51Tiempo de concesión de la dirección IP4 octetos
52Sobrecarga de opciones1 octeto
53Tipo de mensaje DHCP1 octeto
54identificador del servidor4 octetos
55Lista de solicitudes de parámetrosMínimo de 1 octeto
56MensajeMínimo de 1 octeto
57Tamaño máximo de mensaje DHCP2 octetos
58Valor de tiempo de renovación (T1)4 octetos
59Valor de tiempo de reenlace (T2)4 octetos
60Identificador de clase de proveedorMínimo de 1 octeto
61Identificador de clienteMínimo de 2 octetos
66nombre del servidor TFTPMínimo de 1 octeto
67Nombre del archivo de arranqueMínimo de 1 octeto

Tipos de mensajes DHCP

Esta tabla enumera los tipos de mensajes DHCP, documentados en RFC 2132, RFC 3203, RFC 4388, RFC 6926 y RFC 7724. Estos códigos son el valor en la extensión DHCP 53, que se muestra en la tabla anterior.

CódigoNombreLongitudRFC
1DHCPDESCUBRIR1 octetorfc2132
2DHCPOFERTA1 octetorfc2132
3DHCPREQUEST1 octetorfc2132
4DHCPDECLINE1 octetorfc2132
5DHCPPACK1 octetorfc2132
6DHCPNAK1 octetorfc2132
7LIBERARDHCP1 octetorfc2132
8DHCPINFORMAR1 octetorfc2132
9DHCPFORCENEW1 octetorfc3203
10DHCPLEASEQUERY1 octetorfc4388
11DHCPLEASEUNASIGNED1 octetorfc4388
12DHCPLEASEUNKNOWN1 octetorfc4388
13DHCPLEASEACTIVO1 octetorfc4388
14DHCPBULKLEASEQUERY1 octetorfc6926
15DHCPLEASEQUERYDONE1 octetorfc6926
dieciséisDHCPACTIVELEASEQUERY1 octetorfc7724
17DHCPLEASEQUERYSTATUS1 octetorfc7724
18DHCPTLS1 octetorfc7724

Identificación del proveedor del cliente

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 por el cual un cliente DHCP puede comunicarle al servidor que está utilizando cierto tipo de hardware o firmware es establecer un valor en sus solicitudes de DHCP denominado Identificador de clase de proveedor (VCI) (Opción 60). Este método permite que un servidor DHCP diferencie entre los dos tipos de máquinas cliente y procese las solicitudes de los dos tipos de módems de manera adecuada. Algunos tipos de decodificadores también configuran el VCI (Opción 60) para informar al servidor DHCP sobre el tipo de hardware y la funcionalidad del dispositivo.

Otras extensiones

CódigoNombreLongitudRFC
82Información del agente de retransmisiónMínimo de 2 octetosRFC 3046
85Servidores de servicio de directorio de Novell (NDS)Mínimo de 4 octetos, múltiplo de 4 octetosRFC 2241
86nombre del árbol NDSVariableRFC 2241
87contexto NDSVariableRFC 2241
100Zona horaria, estilo POSIXVariableRFC 4833
101Zona horaria, estilo de base de datos tzVariableRFC 4833
114Portal cautivo DHCPVariableRFC 8910
119búsqueda de dominioVariableRFC 3397
121Ruta estática sin clasesVariableRFC 3442
209Archivo de configuraciónVariableRFC 5071
210Prefijo de rutaVariableRFC 5071
211Tiempo de reinicioVariableRFC 5071

Subopciones de información del agente de retransmisión

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 un retransmisor DHCP y un servidor DHCP.

CódigoNombreLongitudRFC
1ID del circuito del agenteMínimo de 1 octetoRFC 3046
2Identificación remota del agenteMínimo de 1 octetoRFC 3046
4Clase de dispositivo de especificaciones de interfaz de servicio de datos por cable (DOCSIS)4 octetosRFC 3256

Retransmisión

En redes pequeñas, donde solo 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 varias subredes. En este caso, un cliente DHCP que aún no haya 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 solo puede recibirse en su propia subred.

Para permitir que los clientes DHCP en las subredes que no están atendidas directamente por los servidores DHCP se comuniquen con los 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 difusió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 ha recibido la difusión del cliente, en el GIADDRcampo del paquete DHCP. El servidor DHCP utiliza el valor GIADDR para determinar la subred y, posteriormente, el grupo de direcciones correspondiente, desde el que asignar una dirección IP. Cuando el servidor DHCP responde al cliente, envía la respuesta a la dirección GIADDR, nuevamente mediante 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 de 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. Inmediatamente después de procesar el paquete, el cliente configura la dirección IP en su interfaz y está listo para la comunicación IP regular, inmediatamente después.

Si la implementación del cliente de la pila IP no acepta paquetes de unidifusión cuando aún no tiene una dirección IP, el cliente puede establecer el bit de difusión en el campo FLAGS al enviar un paquete DHCPDISCOVER. El agente de retransmisión utilizará la dirección IP de difusión 255.255.255.255 (y la dirección MAC del cliente) para informar al cliente de la OFERTA DHCP del servidor.

La comunicación entre el agente de retransmisión y el servidor DHCP suele utilizar un puerto UDP 67 de origen y de destino.

Estados del cliente

Como se describe en RFC 2131, un cliente DHCP puede recibir estos mensajes de un servidor:

  • DHCPOFERTA
  • DHCPPACK
  • DHCPNAK

El cliente se mueve a través de los estados de DHCP según cómo responda el servidor a los mensajes que envía el cliente.

Fiabilidad

El DHCP garantiza la confiabilidad de varias maneras: renovación periódica, reenlace y conmutación por error. A los clientes DHCP se les asignan concesiones que duran un cierto período de tiempo. Los clientes comienzan a intentar renovar sus arrendamientos una vez que ha vencido la mitad del intervalo de arrendamiento. Para ello, envían un mensaje DHCPREQUEST de unidifusión al servidor DHCP que otorgó la concesión original. Si ese servidor está inactivo o no se puede acceder, no podrá responder a DHCPREQUEST. Sin embargo, en ese caso, el cliente repite DHCPREQUEST de vez en cuando, por lo que si el servidor DHCP vuelve a funcionar o vuelve a estar accesible, el cliente DHCP logrará contactarlo y renovar la concesión.

Si no se puede acceder al servidor DHCP durante un período de tiempo prolongado, el cliente DHCP intentará volver a vincular, transmitiendo su DHCPREQUEST en lugar de transmitirlo por unidifusión. Debido a que se transmite, el mensaje DHCPREQUEST llegará a todos los servidores DHCP disponibles. Si algún otro servidor DHCP puede renovar la concesión, lo hará en este momento.

Para que el reenlace funcione, cuando el cliente contacta con éxito a un servidor DHCP de respaldo, ese servidor debe tener información precisa sobre el enlace del cliente. Mantener información de enlace 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 envió una propuesta al Grupo de trabajo de ingeniería de Internet para implementar servidores DHCP tolerantes a fallas, pero nunca se formalizó.

Si la revinculación falla, el contrato de arrendamiento eventualmente vencerá. Cuando vence el contrato de arrendamiento, el cliente debe dejar de usar la dirección IP que se le otorgó en su contrato de arrendamiento. En ese momento reiniciará el proceso DHCP desde el principio emitiendo un DHCPDISCOVERmensaje. Dado que su 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 ha cambiado, se interrumpirán todas las conexiones en curso.

Redes IPv6

La metodología básica de DHCP se desarrolló para redes basadas en el Protocolo de Internet versión 4 (IPv4). Desde el desarrollo y la implementación de las 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 designa como DHCPv6.

Seguridad

El DHCP base no incluye ningún mecanismo de autenticación. Debido a esto, es vulnerable a una variedad de ataques. Estos ataques se dividen en tres categorías principales:

  • Servidores DHCP no autorizados que proporcionan información falsa a los clientes.
  • Clientes no autorizados que obtienen acceso a los recursos.
  • Ataques de agotamiento de recursos de clientes DHCP maliciosos.

Debido a que el cliente no tiene forma de validar la identidad de un servidor DHCP, los servidores DHCP no autorizados (comúnmente llamados "DHCP no autorizados") pueden funcionar en las redes y proporcionar información incorrecta a los clientes DHCP. Esto puede servir como un ataque de denegación de servicio, evitando que el cliente obtenga acceso a la conectividad de la red, o como un ataque de intermediario. Debido a que el servidor DHCP proporciona al cliente DHCP las direcciones IP del servidor, como la dirección IP de uno o más servidores DNS, 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 DNS del cliente.Esto, a su vez, permite al atacante redirigir el tráfico de la red a través de sí mismo, lo que le permite espiar las conexiones entre el cliente y los servidores de red con los que contacta, o simplemente reemplazar esos servidores de red con los suyos.

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 clientes, que pertenecen a otros clientes DHCP. Esto también permite a los clientes DHCP agotar el almacenamiento 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 obtengan el servicio.

DHCP proporciona algunos mecanismos para mitigar estos problemas. La extensión del protocolo de opción de información de agente de retransmisión (RFC 3046, generalmente denominada en la industria por su número real como opción 82) permite a los operadores de red adjuntar etiquetas a los mensajes DHCP a medida que estos mensajes llegan a la red de confianza del operador de red. Esta etiqueta se usa luego como un 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 aguas arriba 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.

Otra extensión, Autenticación para mensajes DHCP (RFC 3118), proporciona un mecanismo para autenticar mensajes DHCP. A partir de 2002, RFC 3118 no había tenido una adopción generalizada debido a los problemas de administración de claves para una gran cantidad de clientes DHCP. Un libro de 2007 sobre tecnologías DSL comentó que:

se identificaron numerosas vulnerabilidades de seguridad contra 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.

Un libro de 2010 señala que:

[h]a 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.

Las propuestas arquitectónicas de 2008 involucran la autenticación de solicitudes DHCP utilizando 802.1x o PANA (ambos transportan EAP). Se hizo una propuesta del IETF para incluir EAP en el mismo DHCP, el llamado EAPoDHCP; esto no parece haber progresado más allá del nivel de borrador de IETF, el último de los cuales data de 2010.

Documentos de estándares IETF

  • RFC 2131, Protocolo de configuración de host dinámico
  • RFC 2132, opciones DHCP y extensiones de proveedor BOOTP
  • RFC 3046, opción de información del agente de retransmisión DHCP
  • RFC 3397, Opción de búsqueda de dominio del Protocolo de configuración dinámica de host (DHCP)
  • RFC 3942, Reclasificación de las opciones del protocolo de configuración dinámica de host, versión cuatro (DHCPv4)
  • RFC 4242, opción de tiempo de actualización de información para el protocolo de configuración dinámica de host para IPv6
  • RFC 4361, Identificadores de cliente específicos de nodo para el protocolo de configuración dinámica de host, versión cuatro (DHCPv4)
  • RFC 4436, Detección de adjuntos de red en IPv4 (DNAv4)
  • RFC 3442, opción de ruta estática sin clases para el protocolo de configuración dinámica de host (DHCP) versión 4
  • RFC 3203, extensión de reconfiguración de DHCP
  • RFC 4388, Leasequery de protocolo de configuración dinámica de host (DHCP)
  • RFC 6926, consulta de arrendamiento masivo de DHCPv4
  • RFC 7724, consulta de concesión activa de DHCPv4

Contenido relacionado

Paquete de red

Capa de enlace de datos

La capa de enlace de datos, data link layer, o capa 2 es la segunda capa del modelo OSI de siete capas de redes informáticas. Esta capa es la capa de...

Protocolo de transporte en tiempo real (RTP)

El Real-time Transport Protocol o Protocolo de transporte en tiempo real es un protocolo de red para entregar audio y video a través de redes IP. RTP se...
Más resultados...
Tamaño del texto:
undoredo
format_boldformat_italicformat_underlinedstrikethrough_ssuperscriptsubscriptlink
save