De Wikipedia, la enciclopedia libre
Saltar a navegación Saltar a búsqueda

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 área local del Protocolo de Internet (IP) . Debe haber un servidor DHCP en la red. Un dispositivo conectado a la red solicita una dirección IP del servidor DHCP utilizando el protocolo DHCP; [1] el servidor asigna una dirección única al dispositivo, identificándolo para la comunicación TCP / IP , y proporciona otros parámetros de configuración de red. [1] En ausencia de un servidor DHCP, un dispositivo que necesita una dirección IP debe ser asignado manualmente una dirección estática por unadministrador de red , o debe asignarse a sí mismo una dirección APIPA (que no le permitirá comunicarse fuera de su subred local ). A un dispositivo configurado para usar direccionamiento dinámico (DHCP) que esté conectado a una red diferente se le asignará una dirección en esa red sin necesidad de volver a configurarlo. Sin embargo, si se debe conocer la dirección de un dispositivo, por ejemplo, una impresora que procesa trabajos de impresión enviados a su dirección IP, se requiere una dirección estática conocida.

DHCP se puede implementar en redes que varían en tamaño, desde redes domésticas hasta redes de campus grandes y redes ISP regionales. [2] Muchos enrutadores y puertas de enlace residenciales pueden actuar como servidores DHCP. La mayoría de los enrutadores de redes residenciales reciben una dirección IP única a nivel mundial dentro de la red del ISP. Dentro de una red local, un servidor DHCP asigna una dirección IP local a cada dispositivo conectado a la red.

Historia [ editar ]

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 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 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 .

Resumen [ editar ]

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 del rango definido por el 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
También comúnmente llamado asignación estática y reservas . El administrador asigna una dirección IP a un identificador único (una identificación de cliente o dirección MAC ) para cada cliente que necesita una dirección conocida. Si un cliente asignado luego solicita una dirección IP, el servidor DHCP emite la dirección asignada a su identificador. Este método se denomina asignación de DHCP estático por DD-WRT , dirección fija por la documentación de dhcpd, reserva de dirección por Netgear, reserva de DHCP o DHCP estático por Cisco y Linksys , y reserva de dirección IP.o el enlace de direcciones MAC / IP de varios otros fabricantes de enrutadores. Si el ID de cliente del cliente (si se proporciona) o la dirección MAC (si no se proporciona el ID de cliente) no se ha asignado a una dirección específica, el servidor puede o no recurrir a la asignación dinámica o automática.

DHCP se utiliza para el protocolo de Internet versión 4 (IPv4) e IPv6 . Si bien ambas versiones tienen el mismo propósito, los detalles del protocolo para IPv4 e IPv6 difieren lo suficiente como para que puedan considerarse 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 [ editar ]

Una ilustración de una sesión DHCP típica no renovable; cada mensaje puede ser de difusión o unidifusión , según las capacidades del cliente DHCP. [8]

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 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 [ editar ]

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.

Oferta [ editar ]

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).

Solicitar [ editar ]

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 TCP 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, 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.

Reconocimiento [ editar ]

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.

Información [ editar ]

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 .

Liberando [ editar ]

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 [ editar ]

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 [ editar ]

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".

Documentado en RFC 2132 [ editar ]

Las siguientes tablas enumeran las opciones de DHCP disponibles, como se enumeran en RFC 2132 [13] y el registro de IANA. [12]

Tipos de mensajes DHCP [ editar ]

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


Identificación del proveedor del cliente [ editar ]

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 comunicar al servidor que está usando un cierto tipo de hardware o firmware es establecer un valor en sus solicitudes DHCP llamado Vendor Class Identifier (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 forma adecuada. Algunos tipos de decodificadorestambién configure el VCI (Opción 60) para informar al servidor DHCP sobre el tipo de hardware y la funcionalidad del dispositivo. El valor al 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.

Documentado en otro lugar [ editar ]

Subopciones de información del agente de retransmisión [ editar ]

La opción de información del agente de retransmisión (opción 82) [18] especifica un contenedor para adjuntar subopciones a las solicitudes DHCP transmitidas entre una retransmisión DHCP y un servidor DHCP.

Transmitiendo [ editar ]

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 múltiples subredes. En este caso, un cliente DHCP que aún no ha adquirido una dirección IP no puede comunicarse directamente con el servidor DHCP mediante el enrutamiento IP, porque no tiene una dirección IP enrutable, no conoce la dirección de la capa de enlace de un enrutador y no sabe la dirección IP del servidor DHCP.

Para permitir que los clientes DHCP en subredes no atendidas directamente por servidores DHCP se comuniquen con servidores DHCP, se pueden instalar agentes de retransmisión DHCP en estas subredes. El cliente DHCP difunde en el enlace local; el agente de retransmisión recibe la difusión y la transmite a uno o más servidores DHCP utilizando unidifusión . El agente de retransmisión almacena su propia dirección IP en el campo GIADDR del paquete DHCP. El servidor DHCP usa el valor GIADDR para determinar la subred en la que el agente de retransmisión recibió la transmisión y asigna una dirección IP en esa subred. Cuando el servidor DHCP responde al cliente, envía la respuesta a la dirección GIADDR, nuevamente usando unidifusión. El agente de retransmisión luego retransmite la respuesta en la red local.

En esta situación, la comunicación entre el agente de retransmisión y el servidor DHCP normalmente utiliza un puerto UDP 67 de origen y destino.

Estados clientes [ editar ]

Un diagrama de transición de estado del cliente DHCP simplificado basado en la figura 5 de RFC 2131.

Como se describe en RFC 2131, [10] : Sección 4.4, un cliente DHCP puede recibir estos mensajes desde un servidor:

  • DHCPOFFER
  • DHCPACK
  • DHCPNAK

El cliente se mueve a través de estados DHCP dependiendo de cómo responde el servidor a los mensajes que envía el cliente.

Fiabilidad [ editar ]

El DHCP asegura la confiabilidad de varias formas: renovación periódica, reenlace, [10] : Sección 4.4.5 y conmutación por error. A los clientes DHCP se les asignan concesiones que duran un período de tiempo. Los clientes comienzan a intentar renovar sus arrendamientos una vez que ha expirado la mitad del intervalo de arrendamiento. [10] : Sección 4.4.5 Párrafo 3 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 inaccesible, no responderá al DHCPREQUEST . Sin embargo, en ese caso, el cliente repite el DHCPREQUEST de vez en cuando, [10] : Sección 4.4.5 Párrafo 8 [b] por lo tanto, si el servidor DHCP vuelve a funcionar o vuelve a estar disponible, el cliente DHCP logrará comunicarse con él y renovar la concesión.

Si no se puede acceder al servidor DHCP durante un período prolongado de tiempo, [10] : Sección 4.4.5 Párrafo 5, el cliente DHCP intentará volver a enlazar, 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 la concesión, lo hará en este momento.

Para que el reenlace funcione, cuando el cliente contacta exitosamente con 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 para implementar servidores DHCP tolerantes a fallas al Grupo de Trabajo de Ingeniería de Internet, pero nunca se formalizó. [26] [c]

Si la reencuadernación falla, el contrato de arrendamiento eventualmente vencerá. Cuando el arrendamiento expira, el cliente debe dejar de usar la dirección IP que se le otorgó en su arrendamiento. [10] : Sección 4.4.5 Párrafo 9 En ese momento se 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 ha cambiado, se interrumpirá cualquier conexión en curso.

Aplicación moderna [ editar ]

A partir de 2018, DHCP sigue siendo ampliamente utilizado para la asignación automática de direcciones IP. [27] Las iteraciones más recientes para asignar direcciones IP incluyen DHCPv6 y SLAAC . [27]

Seguridad [ editar ]

El DHCP base no incluye ningún mecanismo de autenticación. [28] 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. [29]
  • Clientes no autorizados que obtienen acceso a los recursos. [29]
  • Ataques de agotamiento de recursos de clientes DHCP malintencionados. [29]

Debido a que el cliente no tiene manera de validar la identidad de un servidor DHCP, servidores DHCP no autorizados (comúnmente llamados " DHCP falsos ") pueden ser operados en las redes, proporcionando información incorrecta a los clientes DHCP. [30] Esto puede servir como un ataque de denegación de servicio, evitando que el cliente obtenga acceso a la conectividad de la red, [31] o como un ataque man-in-the-middle . [32] 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, [29] un atacante puede convencer a un cliente DHCP de 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. [33][34] Esto, a su vez, permite al atacante redirigir el tráfico de 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. [33]

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 al presentar credenciales, como identificadores de cliente, que pertenecen a otros clientes DHCP. [30] Esto también permite que los clientes DHCP agoten 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 obteniendo servicio. [30]

DHCP proporciona algunos mecanismos para mitigar estos problemas. La extensión del protocolo de la Opción de información del agente de retransmisión (RFC 3046, 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 de confianza del operador de red. . Esta etiqueta se utiliza 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. [28]

Otra extensión, Autenticación para mensajes DHCP ( RFC 3118 ), proporciona un mecanismo para autenticar mensajes DHCP. En 2002, RFC 3118 no había tenido una adopción generalizada debido a los problemas de administración de claves para un gran número de clientes DHCP. [37] Un libro de 2007 sobre tecnologías DSL señaló que:

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. [38]

Un libro de 2010 señala que:

[t] aquí 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 hash se han considerado un precio demasiado alto para pagar por los beneficios percibidos. [39]

Propuestas arquitectónicas de 2008 implican la autenticación de las solicitudes DHCP utilizando 802.1x o PANA (ambos de los cuales el transporte EAP ). [40] Se hizo una propuesta del IETF para incluir EAP en el propio DHCP, el llamado EAPoDHCP ; [41] esto no parece haber avanzado más allá del nivel de borrador del IETF, el último de los cuales data de 2010. [42]

Documentos de estándares IETF [ editar ]

  • RFC 2131, Protocolo de configuración dinámica de host
  • 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 de la versión cuatro del protocolo de configuración dinámica de host (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 la versión cuatro del protocolo de configuración dinámica de host (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, Consulta de arrendamiento del Protocolo de configuración dinámica de host (DHCP)
  • RFC 6926, consulta de arrendamiento masivo DHCPv4
  • RFC 7724, consulta de arrendamiento DHCPv4 activo

Ver también [ editar ]

  • Boot Service Discovery Protocol (BSDP): una extensión DHCP utilizada por NetBoot de Apple
  • Comparación del software del servidor DHCP
  • Peg DHCP (RFC 2322)
  • Entorno de ejecución de prearranque (PXE)
  • Protocolo de resolución de dirección inversa (RARP)
  • DHCP deshonesto
  • Dirección auxiliar UDP  : una herramienta para enrutar las solicitudes DHCP a través de los límites de la subred
  • Zeroconf  - Red de configuración cero

Notas [ editar ]

  1. ^ a b Como comportamiento opcional del cliente, algunas transmisiones, como las que llevan mensajes de solicitud y descubrimiento de DHCP, pueden reemplazarse con unidifusión en caso de que el cliente DHCP ya conozca la dirección IP del servidor DHCP. [9]
  2. ^ El RFC pide al cliente que espere la mitad del tiempo restante hasta T2 antes de retransmitir elpaquete DHCPREQUEST
  3. ^ La propuesta proporcionó un mecanismo por el cual dos servidores podrían permanecer débilmente sincronizados entre sí de tal manera que incluso en el caso de una falla total de un servidor, el otro servidor podría recuperar la base de datos de arrendamiento y continuar funcionando. Debido a la extensión y complejidad de la especificación, nunca se publicó como estándar; sin embargo, las técnicas descritas en la propuesta son de amplio uso, con código abierto y varias implementaciones comerciales.

Referencias [ editar ]

  1. ^ a b Gillis, Alexander S. "¿Qué es DHCP (Protocolo de configuración dinámica de host)?" . TechTarget: SearchNetworking . Consultado el 19 de febrero de 2021 .
  2. ^ Peterson, Larry L .; Davie, Bruce S. (2011). Redes de computadoras: un enfoque de sistemas (5ª ed.). Elsevier. ISBN 978-0123850607. Consultado el 21 de marzo de 2019 .
  3. ^ Bill Croft; John Gilmore (septiembre de 1985). "RFC 951 - Protocolo Bootstrap" . Grupo de trabajo en red .
  4. ^ Red + Certificación 2006 Publicado por Microsoft Press.
  5. ^ utilizado para el protocolo de descubrimiento automático de proxy web Protocolo de descubrimiento automático de proxy web (WPAD)
  6. ^ RFC 4361, RFC 5494, RFC 6221, RFC 6422, RFC 6644, RFC 7083, RFC 7227, RFC 7283
  7. ^ Droms, Ralph; Limón, Ted (2003). El manual de DHCP . Publicación SAMS . pag. 436. ISBN 978-0-672-32327-0.
  8. ^ a b Droms, Ralph. "Protocolo de configuración dinámica de host" . tools.ietf.org . Consultado el 4 de julio de 2017 .
  9. ^ Droms, Ralph. "Protocolo de configuración dinámica de host" . tools.ietf.org . Consultado el 4 de julio de 2017 .
  10. ↑ a b c d e f g Droms, Ralph (marzo de 1997). Opciones de DHCP y extensiones de proveedor BOOTP . IETF . doi : 10.17487 / RFC2131 . RFC 2131 . Consultado el 9 de septiembre de 2014 .
  11. ^ "Protocolo de configuración dinámica de host RFC2131: asignación dinámica de direcciones de red" . tools.ietf.org .
  12. ^ a b "Parámetros del protocolo de configuración dinámica de host (DHCP) y del protocolo Bootstrap (BOOTP)" . iana.org . Consultado el 16 de octubre de 2018 .
  13. ^ a b c d e f g h i j k l m n o p q r s Alexander, Steve; Droms, Ralph (marzo de 1997). Opciones de DHCP y extensiones de proveedores de BOOTP . IETF . doi : 10.17487 / RFC2132 . RFC 2132 . Consultado el 10 de junio de 2012 .
  14. ^ a b { T'joens, Yves; De Schrijver, Peter (diciembre de 2001). DHCP reconfigura la extensión . IETF . doi : 10.17487 / RFC3203 . RFC 3203 . Consultado el 13 de noviembre de 2020 .
  15. ^ a b c d e { Woundy, Rich; Kinnear, Kim (febrero de 2006). DHCP reconfigura la extensión . IETF . doi : 10.17487 / RFC4388 . RFC 4388 . Consultado el 13 de noviembre de 2020 .
  16. ^ a b c { Kinnear, Kim; Stapp, Mark; Rao, DTV Ramakrishna; Joshi, Bharat; Russell, Neil; Kurapati, Pavan; Volz, Bernie (abril de 2013). DHCP reconfigura la extensión . IETF . doi : 10.17487 / RFC6926 . RFC 6926 . Consultado el 13 de noviembre de 2020 .
  17. ^ a b c d { Kinnear, Kim; Stapp, Mark; Volz, Bernie; Russell, Neil (diciembre de 2015). DHCP reconfigura la extensión . IETF . doi : 10.17487 / RFC7724 . RFC 7724 . Consultado el 13 de noviembre de 2020 .
  18. ↑ a b c d Patrick, Michael (enero de 2001). "Opción de información del agente de retransmisión DHCP" . Documentos IETF . IETF . doi : 10.17487 / RFC3046 . Consultado el 22 de julio de 2017 .
  19. ↑ a b c Provan, Don (noviembre de 1997). "RFC 2241 - Opciones DHCP para Novell Directory Services" . Documentos IETF . IETF . doi : 10.17487 / RFC3256 . Consultado el 23 de julio de 2017 .
  20. ^ a b Lear, E .; Eggert, P. (abril de 2007). "Opciones de zona horaria para DHCP" . Documentos IETF . IETF . Consultado el 28 de junio de 2018 .
  21. ^ Kumari, Warren. "RFC 8910 - Identificación de portal cautivo en DHCP y anuncios de enrutador (RA)" . ietf.org . IETF . Consultado el 25 de marzo de 2021 .
  22. ^ Bernardo, Aboba; Stuart, Cheshire (noviembre de 2002). "RFC 3397 - Opción de búsqueda de dominio del Protocolo de configuración dinámica de host (DHCP)" . Documentos IETF . IETF . doi : 10.17487 / RFC3397 . Consultado el 22 de julio de 2017 .
  23. ^ RFC 3442
  24. ^ a b c Hankins, David. "RFC 5071 - Opciones de protocolo de configuración dinámica de host utilizadas por PXELINUX" . ietf.org . IETF . Consultado el 25 de marzo de 2021 .
  25. ^ Doug, Jones; Rich, Woundy (abril de 2002). "RFC 3256 - La subopción de información de agente de retransmisión de clase de dispositivo DOCSIS (especificaciones de interfaz de servicio de datos por cable) DHCP (Protocolo de configuración dinámica de host)" . Documentos IETF . IETF . doi : 10.17487 / RFC3256 . Consultado el 23 de julio de 2017 .
  26. ^ Droms, Ralph; Kinnear, Kim; Stapp, Mark; Volz, Bernie; Gonczi, Steve; Rabil, Greg; Dooley, Michael; Kapur, Arun (marzo de 2003). Protocolo de conmutación por error DHCP . IETF . ID borrador-ietf-dhc-failover-12 . Consultado el 9 de mayo de 2010 .
  27. ↑ a b Weinberg, Neal (14 de agosto de 2018). "Por qué los días de DHCP podrían estar contados" . Mundo de la red . Consultado el 7 de agosto de 2019 .
  28. ↑ a b Patrick, Michael (enero de 2001). "RFC 3046 - Opción de información del agente de retransmisión DHCP" . Grupo de trabajo en red .
  29. ↑ a b c d Droms, Ralph (marzo de 1997). "RFC 2131 - Protocolo de configuración dinámica de host" . Grupo de trabajo en red .
  30. ↑ a b c Stapko, Timothy (2011). Seguridad integrada práctica: creación de sistemas seguros con restricciones de recursos . Newnes. pag. 39. ISBN 978-0-08-055131-9.
  31. ^ Rountree, Derrick (2013). Seguridad de red de Windows 2012 Server: protección de la infraestructura y los sistemas de red de Windows . Newnes. pag. 22. ISBN 978-1-59749-965-1.
  32. ^ Rooney, Timothy (2010). Introducción a la gestión de direcciones IP . John Wiley e hijos. pag. 180. ISBN 978-1-118-07380-3.
  33. ↑ a b Golovanov (Kaspersky Labs), Sergey (junio de 2011). "El cargador TDSS ahora tiene" patas " " .
  34. ^ Sunny, Akash K (octubre de 2015). "Protocolo DHCP y sus vulnerabilidades" .
  35. ^ Gallinas, Francisco J .; Caballero, José M. (2008). Triple Play: Construcción de la red convergente para IP, VoIP e IPTV . John Wiley e hijos. pag. 239. ISBN 978-0-470-75439-9.
  36. ^ Ramírez, David H. (2008). Seguridad IPTV: protección de contenidos digitales de alto valor . John Wiley e hijos. pag. 55. ISBN 978-0-470-72719-5.
  37. ^ Lemon, Ted (abril de 2002). "Implementación de RFC 3118" .
  38. ^ Dorado, Felipe; Dedieu, Hervé; Jacobsen, Krista S. (2007). Implementación y Aplicaciones de Tecnología DSL . Taylor y Francis. pag. 484. ISBN 978-1-4200-1307-8.
  39. ^ Rooney, Timothy (2010). Introducción a la gestión de direcciones IP . John Wiley e hijos. págs. 181-182. ISBN 978-1-118-07380-3.
  40. ^ Copeland, Rebecca (2008). Convergencia de redes NGN alámbricas y móviles 3G con IMS . Taylor y Francis. págs. 142-143. ISBN 978-1-4200-1378-8.
  41. ^ Prasad, Ramjee; Mihovska, Albena (2009). Nuevos horizontes en comunicaciones móviles e inalámbricas: redes, servicios y aplicaciones . 2 . Casa Artech. pag. 339. ISBN 978-1-60783-970-5.
  42. ^ "Copia archivada" . Archivado desde el original el 3 de abril de 2015 . Consultado el 12 de diciembre de 2013 .Mantenimiento de CS1: copia archivada como título ( enlace )

Enlaces externos [ editar ]

  • Medios relacionados con el Protocolo de configuración dinámica de host (DHCP) en Wikimedia Commons