El Protocolo de configuración dinámica de host ( DHCP ) es un protocolo de administración de red que se utiliza en las redes de Protocolo de Internet (IP) para asignar automáticamente direcciones IP y otros parámetros de comunicación a los 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 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 redes de campus grandes y redes 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 .
Historia
En 1984, se introdujo el Protocolo de resolución de dirección inversa (RARP), definido en RFC 903, para permitir que dispositivos simples, como estaciones de trabajo sin disco, obtengan dinámicamente una dirección IP adecuada. Sin embargo, debido a que actuaba en la capa de enlace de datos , dificultaba la implementación en muchas plataformas de servidor y también requería que un servidor estuviera presente en cada enlace de red individual. RARP fue reemplazado por el Bootstrap Protocol ( BOOTP ) definido en RFC 951 en septiembre de 1985. Esto introdujo el concepto de un 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. [3]
DHCP se basa en BOOTP, pero puede asignar dinámicamente direcciones IP de un grupo y recuperarlas 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 IP, incluidos los parámetros específicos de la plataforma. [4] 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, el tipo de mensaje DHCPINFORM [5] y otros pequeños cambios fueron agregados por RFC 2131; que a partir de 2014[actualizar] sigue siendo el estándar para redes IPv4.
DHCPv6 fue descrito inicialmente por RFC 3315 en 2003, pero esto ha sido actualizado por muchas RFC posteriores. [6] RFC 3633 agregó un mecanismo DHCPv6 para la delegación de prefijos , y RFC 3736 agregó la configuración automática de direcciones sin estado .
Descripción general
El Protocolo de Internet (IP) define cómo se comunican los dispositivos dentro y a través de las 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 funciona según el modelo cliente-servidor . Cuando una computadora u otro dispositivo se conecta a una red, el software cliente DHCP envía una consulta de difusió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 tiempo . Al recibir una solicitud de DHCP, el servidor DHCP puede responder con información específica para cada cliente, configurada previamente 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 la asignación ( arrendamiento ) es válido. Un cliente DHCP suele consultar esta información inmediatamente después del arranque y, posteriormente , periódicamente antes de que caduque la información. Cuando un cliente DHCP actualiza una asignación, inicialmente solicita los mismos valores de parámetro, 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 cuando cuenta con la ayuda de agentes de retransmisión DHCP ubicados en los enrutadores de interconexión. 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ámica
- Un 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 al servidor DHCP reclamar y luego reasignar las direcciones IP que no se renuevan.
- Asignación automática
- El 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 pasadas, de modo que puede asignar preferencialmente a un cliente la misma dirección IP que el cliente tenía anteriormente.
- Asignación manual
- Este método también se denomina asignación de DHCP estática , asignación de dirección fija , reserva y enlace de dirección 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 considerarlos protocolos separados. [7] 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 utilizar el direccionamiento local de enlace para lograr operaciones restringidas al enlace de la 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 cliente utiliza el puerto UDP número 68.
Las operaciones de DHCP se dividen en cuatro fases: descubrimiento de servidor, 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 DHCP comienza con los clientes transmitiendo una solicitud. Si el cliente y el servidor están en subredes diferentes, se puede utilizar un asistente 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 punto. 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 difusión, 0x0000 para unidifusión. [8] Normalmente, 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.
Descubrimiento
El cliente DHCP transmite un mensaje DHCPDISCOVER en la subred de la red utilizando la dirección de destino 255.255.255.255 (transmisión limitada) o la dirección de transmisión de subred específica (transmisió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 rechaza la solicitud, lo que hace que el cliente emita una nueva solicitud. Un servidor no autorizado simplemente ignora la solicitud, lo que genera un tiempo de espera dependiente de la implementación para que el cliente expire 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.255 | |||
Octeto 0 | Octeto 1 | Octeto 2 | Octeto 3 |
---|---|---|---|
OP | HTYPE | HLEN | LÚPULO |
0x01 | 0x01 | 0x06 | 0x00 |
XID | |||
0x3903F326 | |||
SECS | BANDERAS | ||
0x0000 | 0x0000 | ||
CIADDR (dirección IP del cliente) | |||
0x00000000 | |||
YIADDR (su 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 de BOOTP . | |||
Galleta mágica | |||
0x63825363 | |||
Opciones de DHCP | |||
0x350101 53: 1 (DHCP Discover) | |||
0x3204c0a80164 50: 192.168.1.100 solicitado | |||
0x370401030f06 55 (Lista de solicitud de parámetros):
| |||
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 enviando 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 hace 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: de acuerdo con las RFC actuales, la dirección MAC de la capa de transporte puede usarse si no se proporciona una 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). 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 = 255.255.255.255 | ||||
Octeto 0 | Octeto 1 | Octeto 2 | Octeto 3 | |
---|---|---|---|---|
OP | HTYPE | HLEN | LÚPULO | |
0x02 | 0x01 | 0x06 | 0x00 | |
XID | ||||
0x3903F326 | ||||
SECS | BANDERAS | |||
0x0000 | 0x0000 | |||
CIADDR (dirección IP del cliente) | ||||
0x00000000 | ||||
YIADDR (su 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 ceros; Legado de 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 concesión de la dirección IP): 86400 s (1 día) | ||||
54 (servidor DHCP): 192.168.1.1 | ||||
6 (servidores DNS):
|
Pedido
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 de DHCP de varios servidores, pero solo aceptará una oferta de DHCP. El cliente producirá un ARP gratuito para encontrar si hay algún otro host presente en la red con la misma dirección IP. Si no hay respuesta de otro host, entonces no hay ningún host con la misma configuración de IP en la red y el mensaje se transmite al servidor mostrando la aceptación de la dirección IP. Según la opción de identificación del servidor requerida en la solicitud y la transmisión de mensajes, se informa a los servidores cuya oferta ha aceptado el cliente. [10] : Sección 3.1, Elemento 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.
Ethernet: fuente = MAC del remitente; destino = FF: FF: FF: FF: FF: FF | ||||
IP: fuente = 0.0.0.0; destino = 255.255.255.255; [a] | ||||
Octeto 0 | Octeto 1 | Octeto 2 | Octeto 3 | |
---|---|---|---|---|
OP | HTYPE | HLEN | LÚPULO | |
0x01 | 0x01 | 0x06 | 0x00 | |
XID | ||||
0x3903F326 | ||||
SECS | BANDERAS | |||
0x0000 | 0x0000 | |||
CIADDR (dirección IP del cliente) | ||||
0xC0A80164 (192.168.1.100) | ||||
YIADDR (su 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 ceros; Legado de 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 enviar un paquete DHCPACK al cliente. Este paquete incluye la duración de la concesión 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.
Una vez que el cliente obtiene una dirección IP, debe probar la dirección recién recibida [11] (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.
Ethernet: fuente = MAC del remitente; destino = MAC del cliente | |||
IP: fuente = 192.168.1.1; destino = 255.255.255.255 | |||
Octeto 0 | Octeto 1 | Octeto 2 | Octeto 3 |
---|---|---|---|
OP | HTYPE | HLEN | LÚPULO |
0x02 | 0x01 | 0x06 | 0x00 |
XID | |||
0x3903F326 | |||
SECS | BANDERAS | ||
0x0000 | 0x0000 | ||
CIADDR (dirección IP del cliente) | |||
0x00000000 | |||
YIADDR (su 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 conmutada por relé) | |||
0x00000000 | |||
CHADDR (dirección de hardware del cliente) | |||
0x00053C04 | |||
0x8D590000 | |||
0x00000000 | |||
0x00000000 | |||
192 octetos de 0s. Legado de BOOTP | |||
Galleta mágica | |||
0x63825363 | |||
Opciones de DHCP | |||
53: 5 (DHCP ACK) o 6 (DHCP NAK) | |||
1 (máscara de subred): 255.255.255.0 | |||
3 (enrutador): 192.168.1.1 | |||
51 (tiempo de concesión de la dirección IP): 86400 s (1 día) | |||
54 (servidor DHCP): 192.168.1.1 | |||
6 (servidores DNS):
|
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 utilizan DHCP Inform para obtener la configuración del proxy web a través de WPAD .
Liberar
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 la versión DHCP .
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 DHCP disponibles definidas por la Autoridad de números asignados de Internet (IANA) - PARÁMETROS DHCP y BOOTP. [12]
Un cliente DHCP puede seleccionar, manipular y sobrescribir parámetros proporcionados por un servidor DHCP. En 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. 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, como se enumeran en RFC 2132 [13] y el registro de IANA. [12]
Código | Nombre | Largo | Notas |
---|---|---|---|
0 | Pad [13] : Sección 3.1 | 0 octetos | Puede usarse para rellenar otras opciones para que estén alineadas con el límite de la palabra; no va seguido de un byte de longitud |
1 | Máscara de subred [13] : Sección 3.3 | 4 octetos | Debe enviarse antes de la opción de enrutador (opción 3) si se incluyen ambos |
2 | Diferencia horaria [13] : Sección 3.4 | 4 octetos | |
3 | Enrutador | Múltiplos de 4 octetos | Enrutadores disponibles, se deben enumerar en orden de preferencia |
4 | Servidor de tiempo | Múltiplos de 4 octetos | Los servidores de tiempo disponibles para sincronizar deben aparecer en orden de preferencia. |
5 | Nombre del servidor | Múltiplos de 4 octetos | Los servidores de nombres IEN 116 disponibles se deben enumerar en orden de preferencia |
6 | Servidor de nombres de dominio | Múltiplos de 4 octetos | Los servidores DNS disponibles deben aparecer en orden de preferencia. |
7 | Servidor de registro | Múltiplos de 4 octetos | Los servidores de registro disponibles deben aparecer en orden de preferencia. |
8 | Servidor de cookies | Múltiplos de 4 octetos | Cookie 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 . |
9 | Servidor LPR | Múltiplos de 4 octetos | |
10 | Impresionante servidor | Múltiplos de 4 octetos | |
11 | Servidor de ubicación de recursos | Múltiplos de 4 octetos | |
12 | Nombre de host | Mínimo de 1 octeto | |
13 | Tamaño del archivo de arranque | 2 octetos | Longitud de la imagen de arranque en bloques de 4 KB |
14 | Mérito archivo de volcado | Mínimo de 1 octeto | Ruta donde se deben almacenar los volcados de memoria |
15 | Nombre de dominio | Mínimo de 1 octeto | |
dieciséis | Servidor de intercambio | 4 octetos | |
17 | Ruta raíz | Mínimo de 1 octeto | |
18 | Ruta de extensiones | Mínimo de 1 octeto | |
255 | Final | 0 octetos | Se utiliza para marcar el final del campo de opción de proveedor. |
Código | Nombre | Largo | Notas |
---|---|---|---|
19 | Habilitar / deshabilitar el reenvío de IP | 1 octeto | |
20 | Activar / desactivar el enrutamiento de origen no local | 1 octeto | |
21 | Filtro de políticas | Múltiplos de 8 octetos | |
22 | Tamaño máximo de reensamblaje de datagramas | 2 octetos | |
23 | Tiempo de vida de IP predeterminado | 1 octeto | |
24 | Tiempo de espera de caducidad de MTU de ruta | 4 octetos | |
25 | Mesa de meseta Path MTU | Múltiplos de 2 octetos |
Código | Nombre | Largo | Notas |
---|---|---|---|
26 | Interfaz MTU | 2 octetos | |
27 | Todas las subredes son locales | 1 octeto | |
28 | Dirección de Difusión | 4 octetos | |
29 | Realizar descubrimiento de máscara | 1 octeto | |
30 | Proveedor de mascarillas | 1 octeto | |
31 | Realizar el descubrimiento de enrutadores | 1 octeto | |
32 | Dirección de solicitud del enrutador | 4 octetos | |
33 | Ruta estática | Múltiplos de 8 octetos | Una lista de pares de destino / enrutador |
Code | Name | Length | Notes |
---|---|---|---|
34 | Trailer encapsulation option | 1 octet | |
35 | ARP cache timeout | 4 octets | |
36 | Ethernet encapsulation | 1 octet |
Code | Name | Length | Notes |
---|---|---|---|
37 | TCP default TTL | 1 octet | |
38 | TCP keepalive interval | 4 octets | |
39 | TCP keepalive garbage | 1 octet |
Code | Name | Length | Notes |
---|---|---|---|
40 | Network information service domain | Minimum of 1 octet | |
41 | Network information servers | Multiples of 4 octets | |
42 | Network Time Protocol (NTP) servers | Multiples of 4 octets | |
43 | Vendor-specific information | Minimum of 1 octets | |
44 | NetBIOS over TCP/IP name server | Multiples of 4 octets | |
45 | NetBIOS over TCP/IP datagram Distribution Server | Multiples of 4 octets | |
46 | NetBIOS over TCP/IP node type | 1 octet | |
47 | NetBIOS over TCP/IP scope | Minimum of 1 octet | |
48 | X Window System font server | Multiples of 4 octets | |
49 | X Window System display manager | Multiples of 4 octets | |
64 | Network Information Service+ domain | Minimum of 1 octet | |
65 | Network Information Service+ servers | Multiples of 4 octets | |
68 | Mobile IP home agent | Multiples of 4 octets | |
69 | Simple Mail Transfer Protocol (SMTP) server | Multiples of 4 octets | |
70 | Post Office Protocol (POP3) server | Multiples of 4 octets | |
71 | Network News Transfer Protocol (NNTP) server | Multiples of 4 octets | |
72 | Default World Wide Web (WWW) server | Multiples of 4 octets | |
73 | Default Finger protocol server | Multiples of 4 octets | |
74 | Default Internet Relay Chat (IRC) server | Multiples of 4 octets | |
75 | StreetTalk server | Multiples of 4 octets | |
76 | StreetTalk Directory Assistance (STDA) server | Multiples of 4 octets |
Code | Name | Length | Notes |
---|---|---|---|
50 | Requested IP address | 4 octets | |
51 | IP address lease time | 4 octets | |
52 | Option overload | 1 octet | |
53 | DHCP message type | 1 octet | |
54 | Server identifier | 4 octets | |
55 | Parameter request list | Minimum of 1 octet | |
56 | Message | Minimum of 1 octet | |
57 | Maximum DHCP message size | 2 octets | |
58 | Renewal (T1) time value | 4 octets | |
59 | Rebinding (T2) time value | 4 octets | |
60 | Vendor class identifier | Minimum of 1 octet | |
61 | Client-identifier | Minimum of 2 octets | |
66 | TFTP server name | Minimum of 1 octet | |
67 | Bootfile name | Minimum of 1 octet |
DHCP Message Types
This table lists the DHCP message types, documented in RFC 2132, RFC 3203,[14] RFC 4388,[15] RFC 6926[16] and RFC 7724.[17] These codes are the value in the DHCP extension 53, shown in the table above.
Code | Name | Length | RFC |
---|---|---|---|
1 | DHCPDISCOVER | 1 octet | rfc2132[13]:Section 9.6 |
2 | DHCPOFFER | 1 octet | rfc2132[13]:Section 9.6 |
3 | DHCPREQUEST | 1 octet | rfc2132[13]:Section 9.6 |
4 | DHCPDECLINE | 1 octet | rfc2132[13]:Section 9.6 |
5 | DHCPACK | 1 octet | rfc2132[13]:Section 9.6 |
6 | DHCPNAK | 1 octet | rfc2132[13]:Section 9.6 |
7 | DHCPRELEASE | 1 octet | rfc2132[13]:Section 9.6 |
8 | DHCPINFORM | 1 octet | rfc2132[13]:Section 9.6 |
9 | DHCPFORCERENEW | 1 octet | rfc3203[14]:Section 4 |
10 | DHCPLEASEQUERY | 1 octet | rfc4388[15]:Section 6.1 |
11 | DHCPLEASEUNASSIGNED | 1 octet | rfc4388[15]:Section 6.1 |
12 | DHCPLEASEUNKNOWN | 1 octet | rfc4388[15]:Section 6.1 |
13 | DHCPLEASEACTIVE | 1 octet | rfc4388[15]:Section 6.1 |
14 | DHCPBULKLEASEQUERY | 1 octet | rfc6926[16]:Section 6.2.1 |
15 | DHCPLEASEQUERYDONE | 1 octet | rfc6926[16]:Section 6.2.1 |
16 | DHCPACTIVELEASEQUERY | 1 octet | rfc7724[17]:Section 5.2.1 |
17 | DHCPLEASEQUERYSTATUS | 1 octet | rfc7724[17]:Section 5.2.1 |
18 | DHCPTLS | 1 octet | rfc7724[17]:Section 5.2.1 |
Client vendor identification
An option exists to identify the vendor and functionality of a DHCP client. The information is a variable-length string of characters or octets which has a meaning specified by the vendor of the DHCP client. One method by which a DHCP client can communicate to the server that it is using a certain type of hardware or firmware is to set a value in its DHCP requests called the Vendor Class Identifier (VCI) (Option 60). This method allows a DHCP server to differentiate between the two kinds of client machines and process the requests from the two types of modems appropriately. Some types of set-top boxes also set the VCI (Option 60) to inform the DHCP server about the hardware type and functionality of the device. The value to which this option is set gives the DHCP server a hint about any required extra information that this client needs in a DHCP response.
Other extensions
Code | Name | Length | RFC |
---|---|---|---|
82 | Relay agent information | Minimum of 2 octets | RFC 3046[18] |
85 | Novell Directory Service (NDS) servers | Minimum of 4 octets, multiple of 4 octets | RFC 2241[19]:Section 2 |
86 | NDS tree name | Variable | RFC 2241[19]:Section 3 |
87 | NDS context | Variable | RFC 2241[19]:Section 4 |
100 | Time zone, POSIX style | Variable | RFC 4833[20] |
101 | Time zone, tz database style | Variable | RFC 4833[20] |
114 | DHCP Captive-Portal | Variable | RFC 8910[21] |
119 | Domain search | Variable | RFC 3397[22] |
121 | Classless static route | Variable | RFC 3442[23] |
209 | Configuration File | Variable | RFC 5071[24] |
210 | Path Prefix | Variable | RFC 5071[24] |
211 | Reboot Time | Variable | RFC 5071[24] |
Relay agent information sub-options
The relay agent information option (option 82) specifies container for attaching sub-options to DHCP requests transmitted between a DHCP relay and a DHCP server.[18]
Code | Name | Length | RFC |
---|---|---|---|
1 | Agent Circuit ID | Minimum of 1 octet | RFC 3046[18] |
2 | Agent Remote ID | Minimum of 1 octet | RFC 3046[18] |
4 | Data-Over-Cable Service Interface Specifications (DOCSIS) device class | 4 octets | RFC 3256[25] |
Retransmision
In small networks, where only one IP subnet is being managed, DHCP clients communicate directly with DHCP servers. However, DHCP servers can also provide IP addresses for multiple subnets. In this case, a DHCP client that has not yet acquired an IP address cannot communicate directly with the DHCP server using IP routing, because it does not have a routable IP address, does not know the link layer address of a router and does not know the IP address of the DHCP server.
In order to allow DHCP clients on subnets not directly served by DHCP servers to communicate with DHCP servers, DHCP relay agents can be installed on these subnets. The DHCP client broadcasts on the local link; the relay agent receives the broadcast and transmits it to one or more DHCP servers using unicast. The relay agent stores its own IP address in field GIADDR field of the DHCP packet. The DHCP server uses the GIADDR-value to determine the subnet on which the relay agent received the broadcast, and allocates an IP address on that subnet. When the DHCP server replies to the client, it sends the reply to the GIADDR-address, again using unicast. The relay agent then retransmits the response on the local network.
In this situation, the communication between the relay agent and the DHCP server typically uses both a source and destination UDP port of 67.
Estados del cliente
As described in RFC 2131,[10]:Section 4.4 a DHCP client can receive these messages from a server:
- DHCPOFFER
- DHCPACK
- DHCPNAK
The client moves through DHCP states depending on how the server responds to the messages that the client sends.
Fiabilidad
The DHCP ensures reliability in several ways: periodic renewal, rebinding,[10]:Section 4.4.5 and failover. DHCP clients are allocated leases that last for some period of time. Clients begin to attempt to renew their leases once half the lease interval has expired.[10]:Section 4.4.5 Paragraph 3 They do this by sending a unicast DHCPREQUEST message to the DHCP server that granted the original lease. If that server is down or unreachable, it will fail to respond to the DHCPREQUEST. However, in that case the client repeats the DHCPREQUEST from time to time,[10]:Section 4.4.5 Paragraph 8[b] so if the DHCP server comes back up or becomes reachable again, the DHCP client will succeed in contacting it and renew the lease.
If the DHCP server is unreachable for an extended period of time,[10]:Section 4.4.5 Paragraph 5 the DHCP client will attempt to rebind, by broadcasting its DHCPREQUEST rather than unicasting it. Because it is broadcast, the DHCPREQUEST message will reach all available DHCP servers. If some other DHCP server is able to renew the lease, it will do so at this time.
In order for rebinding to work, when the client successfully contacts a backup DHCP server, that server must have accurate information about the client's binding. Maintaining accurate binding information between two servers is a complicated problem; if both servers are able to update the same lease database, there must be a mechanism to avoid conflicts between updates on the independent servers. A proposal for implementing fault-tolerant DHCP servers was submitted to the Internet Engineering Task Force, but never formalized.[26][c]
If rebinding fails, the lease will eventually expire. When the lease expires, the client must stop using the IP address granted to it in its lease.[10]:Section 4.4.5 Paragraph 9 At that time it will restart the DHCP process from the beginning by broadcasting a DHCPDISCOVER
message. Since its lease has expired, it will accept any IP address offered to it. Once it has a new IP address (presumably from a different DHCP server) it will once again be able to use the network. However, since its IP address has changed, any ongoing connections will be broken.
Redes IPv6
The basic methodology of DHCP was developed for networks based on Internet Protocol version 4 (IPv4). Since the development and deployment of IPv6 networks, DHCP has also been used for assigning parameters in such networks, despite the inherent features of IPv6 for stateless address autoconfiguration. The IPv6 version of the protocol is designated as DHCPv6.[27]
Seguridad
The base DHCP does not include any mechanism for authentication.[28] Because of this, it is vulnerable to a variety of attacks. These attacks fall into three main categories:
- Unauthorized DHCP servers providing false information to clients.[29]
- Unauthorized clients gaining access to resources.[29]
- Resource exhaustion attacks from malicious DHCP clients.[29]
Because the client has no way to validate the identity of a DHCP server, unauthorized DHCP servers (commonly called "rogue DHCP") can be operated on networks, providing incorrect information to DHCP clients.[30] This can serve either as a denial-of-service attack, preventing the client from gaining access to network connectivity,[31] or as a man-in-the-middle attack.[32] Because the DHCP server provides the DHCP client with server IP addresses, such as the IP address of one or more DNS servers,[29] an attacker can convince a DHCP client to do its DNS lookups through its own DNS server, and can therefore provide its own answers to DNS queries from the client.[33][34] This in turn allows the attacker to redirect network traffic through itself, allowing it to eavesdrop on connections between the client and network servers it contacts, or to simply replace those network servers with its own.[33]
Because the DHCP server has no secure mechanism for authenticating the client, clients can gain unauthorized access to IP addresses by presenting credentials, such as client identifiers, that belong to other DHCP clients.[30] This also allows DHCP clients to exhaust the DHCP server's store of IP addresses—by presenting new credentials each time it asks for an address, the client can consume all the available IP addresses on a particular network link, preventing other DHCP clients from getting service.[30]
DHCP does provide some mechanisms for mitigating these problems. The Relay Agent Information Option protocol extension (RFC 3046, usually referred to in the industry by its actual number as Option 82[35][36]) allows network operators to attach tags to DHCP messages as these messages arrive on the network operator's trusted network. This tag is then used as an authorization token to control the client's access to network resources. Because the client has no access to the network upstream of the relay agent, the lack of authentication does not prevent the DHCP server operator from relying on the authorization token.[28]
Another extension, Authentication for DHCP Messages (RFC 3118), provides a mechanism for authenticating DHCP messages. As of 2002, RFC 3118 had not seen widespread adoption because of the problems of managing keys for large numbers of DHCP clients.[37] A 2007 book about DSL technologies remarked that:
there were numerous security vulnerabilities identified against the security measures proposed by RFC 3118. This fact, combined with the introduction of 802.1x, slowed the deployment and take-rate of authenticated DHCP, and it has never been widely deployed.[38]
A 2010 book notes that:
[t]here have been very few implementations of DHCP Authentication. The challenges of key management and processing delays due to hash computation have been deemed too heavy a price to pay for the perceived benefits.[39]
Architectural proposals from 2008 involve authenticating DHCP requests using 802.1x or PANA (both of which transport EAP).[40] An IETF proposal was made for including EAP in DHCP itself, the so-called EAPoDHCP;[41] this does not appear to have progressed beyond IETF draft level, the last of which dates to 2010.[42]
Documentos de estándares IETF
- RFC 2131, Dynamic Host Configuration Protocol
- RFC 2132, DHCP Options and BOOTP Vendor Extensions
- RFC 3046, DHCP Relay Agent Information Option
- RFC 3397, Dynamic Host Configuration Protocol (DHCP) Domain Search Option
- RFC 3942, Reclassifying Dynamic Host Configuration Protocol Version Four (DHCPv4) Options
- RFC 4242, Information Refresh Time Option for Dynamic Host Configuration Protocol for IPv6
- RFC 4361, Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4)
- RFC 4436, Detecting Network Attachment in IPv4 (DNAv4)
- RFC 3442, Classless Static Route Option for Dynamic Host Configuration Protocol (DHCP) version 4
- RFC 3203, DHCP reconfigure extension
- RFC 4388, Dynamic Host Configuration Protocol (DHCP) Leasequery
- RFC 6926, DHCPv4 Bulk Leasequery
- RFC 7724, Active DHCPv4 Lease Query
Ver también
- Boot Service Discovery Protocol (BSDP) – a DHCP extension used by Apple's NetBoot
- Comparison of DHCP server software
- Peg DHCP (RFC 2322)
- Preboot Execution Environment (PXE)
- Reverse Address Resolution Protocol (RARP)
- Rogue DHCP
- UDP Helper Address – a tool for routing DHCP requests across subnet boundaries
- Zeroconf – Zero Configuration Networking
Notas
- ^ a b As an optional client behavior, some broadcasts, such as those carrying DHCP discovery and request messages, may be replaced with unicasts in case the DHCP client already knows the DHCP server's IP address.[9]
- ^ The RFC calls for the client to wait one half of the remaining time until T2 before it retransmits the DHCPREQUEST packet
- ^ The proposal provided a mechanism whereby two servers could remain loosely in sync with each other in such a way that even in the event of a total failure of one server, the other server could recover the lease database and continue operating. Due to the length and complexity of the specification, it was never published as a standard; however, the techniques described in the proposal are in wide use, with open-source and several commercial implementations.
Referencias
- ^ Gillis, Alexander S. "What is DHCP (Dynamic Host Configuration Protocol)?". TechTarget: SearchNetworking. Retrieved 19 February 2021.
- ^ Peterson, Larry L.; Davie, Bruce S. (2011). Computer Networks: A Systems Approach (5th ed.). Elsevier. ISBN 978-0123850607. Retrieved March 21, 2019.
- ^ Bill Croft; John Gilmore (September 1985). "RFC 951 - Bootstrap Protocol". Network Working Group.
- ^ Network+ Certification 2006 Published By Microsoft Press.
- ^ used for the Web Proxy Autodiscovery Protocol Web Proxy Autodiscovery Protocol (WPAD)
- ^ RFC 4361, RFC 5494, RFC 6221, RFC 6422, RFC 6644, RFC 7083, RFC 7227, RFC 7283
- ^ Droms, Ralph; Lemon, Ted (2003). The DHCP Handbook. SAMS Publishing. p. 436. ISBN 978-0-672-32327-0.
- ^ a b Droms, Ralph. "Dynamic Host Configuration Protocol". tools.ietf.org. Retrieved 4 July 2017.
- ^ Droms, Ralph. "Dynamic Host Configuration Protocol". tools.ietf.org. Retrieved 4 July 2017.
- ^ a b c d e f g Droms, Ralph (March 1997). DHCP Options and BOOTP Vendor Extensions. IETF. doi:10.17487/RFC2131. RFC 2131. Retrieved September 9, 2014.
- ^ "RFC2131 Dynamic Host Configuration Protocol: Dynamic allocation of network addresses". tools.ietf.org.
- ^ a b "Dynamic Host Configuration Protocol (DHCP) and Bootstrap Protocol (BOOTP) Parameters". iana.org. Retrieved 2018-10-16.
- ^ a b c d e f g h i j k l m n o p q r s Alexander, Steve; Droms, Ralph (March 1997). DHCP options and BOOTP vendor extensions. IETF. doi:10.17487/RFC2132. RFC 2132. Retrieved June 10, 2012.
- ^ a b { T'joens, Yves; De Schrijver, Peter (December 2001). DHCP reconfigure extension. IETF. doi:10.17487/RFC3203. RFC 3203. Retrieved November 13, 2020.
- ^ a b c d e { Woundy, Rich; Kinnear, Kim (February 2006). DHCP reconfigure extension. IETF. doi:10.17487/RFC4388. RFC 4388. Retrieved November 13, 2020.
- ^ a b c { Kinnear, Kim; Stapp, Mark; Rao, D.T.V Ramakrishna; Joshi, Bharat; Russell, Neil; Kurapati, Pavan; Volz, Bernie (April 2013). DHCP reconfigure extension. IETF. doi:10.17487/RFC6926. RFC 6926. Retrieved November 13, 2020.
- ^ a b c d { Kinnear, Kim; Stapp, Mark; Volz, Bernie; Russell, Neil (December 2015). DHCP reconfigure extension. IETF. doi:10.17487/RFC7724. RFC 7724. Retrieved November 13, 2020.
- ^ a b c d Patrick, Michael (January 2001). "DHCP Relay Agent Information Option". IETF Documents. IETF. doi:10.17487/RFC3046. Retrieved 22 July 2017.
- ^ a b c Provan, Don (November 1997). "RFC 2241 – DHCP Options for Novell Directory Services". IETF Documents. IETF. doi:10.17487/RFC3256. Retrieved 23 July 2017.
- ^ a b Lear, E.; Eggert, P. (April 2007). "Timezone Options for DHCP". IETF Documents. IETF. Retrieved 28 June 2018.
- ^ Kumari, Warren. "RFC 8910 - Captive-Portal Identification in DHCP and Router Advertisements (RAs)". ietf.org. IETF. Retrieved 25 March 2021.
- ^ Bernard, Aboba; Stuart, Cheshire (November 2002). "RFC 3397 – Dynamic Host Configuration Protocol (DHCP) Domain Search Option". IETF Documents. IETF. doi:10.17487/RFC3397. Retrieved 22 July 2017.
- ^ RFC 3442
- ^ a b c Hankins, David. "RFC 5071 - Dynamic Host Configuration Protocol Options Used by PXELINUX". ietf.org. IETF. Retrieved 25 March 2021.
- ^ Doug, Jones; Rich, Woundy (April 2002). "RFC 3256 – The DOCSIS (Data-Over-Cable Service Interface Specifications) Device Class DHCP (Dynamic Host Configuration Protocol) Relay Agent Information Sub-option". IETF Documents. IETF. doi:10.17487/RFC3256. Retrieved 23 July 2017.
- ^ Droms, Ralph; Kinnear, Kim; Stapp, Mark; Volz, Bernie; Gonczi, Steve; Rabil, Greg; Dooley, Michael; Kapur, Arun (March 2003). DHCP Failover Protocol. IETF. I-D draft-ietf-dhc-failover-12. Retrieved May 9, 2010.
- ^ Weinberg, Neal (2018-08-14). "Why DHCP's days might be numbered". Network World. Retrieved 2019-08-07.
- ^ a b Patrick, Michael (January 2001). "RFC 3046 - DHCP Relay Agent Information Option". Network Working Group.
- ^ a b c d Droms, Ralph (March 1997). "RFC 2131 - Dynamic Host Configuration Protocol". Network Working Group.
- ^ a b c Stapko, Timothy (2011). Practical Embedded Security: Building Secure Resource-Constrained Systems. Newnes. p. 39. ISBN 978-0-08-055131-9.
- ^ Rountree, Derrick (2013). Windows 2012 Server Network Security: Securing Your Windows Network Systems and Infrastructure. Newnes. p. 22. ISBN 978-1-59749-965-1.
- ^ Rooney, Timothy (2010). Introduction to IP Address Management. John Wiley & Sons. p. 180. ISBN 978-1-118-07380-3.
- ^ a b Golovanov (Kaspersky Labs), Sergey (June 2011). "TDSS loader now got "legs"".
- ^ Sunny, Akash K (October 2015). "dhcp protocol and its vulnerabilities".
- ^ Hens, Francisco J.; Caballero, José M. (2008). Triple Play: Building the converged network for IP, VoIP and IPTV. John Wiley & Sons. p. 239. ISBN 978-0-470-75439-9.
- ^ Ramirez, David H. (2008). IPTV Security: Protecting High-Value Digital Contents. John Wiley & Sons. p. 55. ISBN 978-0-470-72719-5.
- ^ Lemon, Ted (April 2002). "Implementation of RFC 3118".
- ^ Golden, Philip; Dedieu, Hervé; Jacobsen, Krista S. (2007). Implementation and Applications of DSL Technology. Taylor & Francis. p. 484. ISBN 978-1-4200-1307-8.
- ^ Rooney, Timothy (2010). Introduction to IP Address Management. John Wiley & Sons. pp. 181–182. ISBN 978-1-118-07380-3.
- ^ Copeland, Rebecca (2008). Converging NGN Wireline and Mobile 3G Networks with IMS. Taylor & Francis. pp. 142–143. ISBN 978-1-4200-1378-8.
- ^ Prasad, Ramjee; Mihovska, Albena (2009). New Horizons in Mobile and Wireless Communications: Networks, services, and applications. 2. Artech House. p. 339. ISBN 978-1-60783-970-5.
- ^ "Archived copy". Archived from the original on 2015-04-03. Retrieved 2013-12-12.CS1 maint: archived copy as title (link)
enlaces externos
- Media related to Dynamic Host Configuration Protocol (DHCP) at Wikimedia Commons