Hispanopedia Wiki
Articulo de referencia

Protocolo de configuración dinámica de host

El Protocolo de Configuración Dinámica de Host ( DHCP ) es un protocolo de gestión de red utilizado en redes de Protocolo de Internet (IP) para asignar automáticamente direccion...

Hispanopedia WikiContenido en espanolLectura gratuita

El Protocolo de Configuración Dinámica de Host ( DHCP ) es un protocolo de gestión de red utilizado en redes de Protocolo de Internet (IP) para asignar automáticamente direcciones IP y otros parámetros de comunicación a los dispositivos conectados a la red mediante una arquitectura cliente-servidor . [ 1 ] : Introducción

Esta tecnología elimina la necesidad de configurar manualmente cada dispositivo de red y consta de dos componentes: un servidor DHCP centralizado y las instancias del protocolo en cada ordenador o dispositivo. Al conectarse a la red, y periódicamente después, un cliente solicita al servidor un conjunto de parámetros mediante DHCP.

DHCP se puede implementar en redes de diversos tamaños, desde redes residenciales hasta grandes redes universitarias y redes regionales de ISP. [ 2 ] Muchos enrutadores y gateways residenciales cuentan con 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 utilizan 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 . [ 3 ]

Historia

El Protocolo de Resolución de Direcciones Inversas (RARP) se definió en 1984 para la configuración de dispositivos simples, como estaciones de trabajo sin disco , con una dirección IP adecuada . [ 4 ] Al operar en la capa de enlace de datos , dificultó su implementación en muchas plataformas de servidor. Requería la presencia de un servidor en cada enlace de red individual. RARP fue reemplazado por el Protocolo Bootstrap (BOOTP), definido en septiembre de 1985. [ 5 ] Este introdujo el concepto de agente de retransmisión, que permitió el reenvío de paquetes BOOTP a través de redes, permitiendo que un servidor BOOTP central atendiera hosts en múltiples subredes IP.

DHCP se definió por primera vez en octubre de 1993. [ 6 ] [ 7 ] Se basa en BOOTP, pero puede asignar direcciones IP dinámicamente desde un grupo y recuperarlas cuando ya no están en uso. También se puede utilizar para proporcionar una amplia gama de parámetros de configuración adicionales a los clientes IP, incluidos parámetros específicos de la plataforma. [ 8 ]

Cuatro años después, se añadió el tipo de mensaje DHCPINFORM (utilizado para WPAD ) y otros pequeños cambios. Esta definición, de 1997, [ 1 ] sigue siendo la base del estándar para redes IPv4.

DHCPv6 se definió inicialmente en 2003. [ 9 ] Después de las actualizaciones de muchos RFC posteriores, su definición fue reemplazada en 2018, [ 10 ] donde la delegación de prefijos y la autoconfiguración de direcciones sin estado se fusionaron.

Descripción general

El Protocolo de Internet (IP) define cómo se comunican los dispositivos dentro y entre redes locales en Internet. Un servidor DHCP puede administrar la configuración de IP para los dispositivos en su red local, por ejemplo, asignando direcciones IP [ 8 ] a esos dispositivos de forma automática y dinámica. [ 11 ]

DHCP funciona según el modelo cliente-servidor . Cuando un ordenador 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 gestiona un conjunto de direcciones IP e información sobre los parámetros de configuración del cliente, como la puerta de enlace predeterminada , el nombre de dominio , los servidores de nombres y los servidores de hora . Al recibir una solicitud DHCP, el servidor DHCP puede responder con información específica para cada cliente, según la configuración previa del 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 durante el cual la asignación ( arrendamiento ) sea válida. Un cliente DHCP normalmente consulta esta información inmediatamente después del arranque y periódicamente después, 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 extensas con múltiples enlaces, un único servidor DHCP puede dar servicio a toda la red con la ayuda de agentes de retransmisión DHCP ubicados en los enrutadores interconectados. Estos agentes retransmiten mensajes entre clientes DHCP y servidores DHCP situados en subredes diferentes.

Dependiendo de 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 se configura para solicitar una dirección IP al 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 recuperar y 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 dentro de un rango definido por el administrador. Esto es similar a la asignación dinámica, pero el servidor DHCP mantiene un registro de las asignaciones de direcciones IP anteriores, de modo que puede asignar preferentemente a un cliente la misma dirección IP que este tenía previamente.
Asignación manual
Este método también se conoce como asignación DHCP estática , asignación de dirección fija , reserva y vinculación de direcciones MAC/IP . Un administrador asigna un identificador único (un ID de cliente o una dirección MAC ) a cada cliente y lo asocia a una dirección IP, que se ofrece al cliente solicitante. Los servidores DHCP pueden configurarse para recurrir a otros métodos en caso de que este falle.

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. [ 12 ] Para el funcionamiento de IPv6, los dispositivos pueden utilizar alternativamente la autoconfiguración de direcciones sin estado. Los hosts IPv6 también pueden utilizar el direccionamiento de enlace local para realizar operaciones restringidas al enlace de red local.

Operación

Ilustración de una sesión DHCP típica no renovable; cada mensaje puede ser de difusión o de unidifusión , dependiendo de las capacidades del cliente DHCP. [ 1 ]

El DHCP utiliza un modelo de servicio sin conexión , basado en el Protocolo de Datagramas de Usuario (UDP). Se implementa con dos puertos UDP, los mismos que para el protocolo de arranque ( BOOTP ). El servidor escucha en el puerto UDP 67 y el cliente en el puerto UDP 68.

Las operaciones DHCP se dividen en cuatro fases: descubrimiento del servidor, oferta de concesión de IP, solicitud de concesión de IP y confirmación de concesión de IP. Estas fases suelen abreviarse como DORA (descubrimiento, oferta, solicitud y confirmación).

La operación DHCP comienza con los clientes enviando una solicitud por difusión. Si el cliente y el servidor están en dominios de difusión diferentes, se puede usar un DHCP Helper o un DHCP Relay Agent . Los clientes que solicitan la renovación de una concesión 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 un 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 la DHCPOFFER: 0x8000 para difusión, 0x0000 para unidifusión. [ 1 ] Normalmente, la 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 utilizando la dirección de destino 255.255.255.255 (difusión limitada) o la dirección de difusión específica de la subred (difusión dirigida). Un cliente DHCP también puede solicitar una dirección IP en el mensaje DHCPDISCOVER, que el servidor puede tener en cuenta al seleccionar una dirección para ofrecer.

Por ejemplo, si HTYPE se establece en 1 para especificar que el medio utilizado es Ethernet , HLEN se establece en 6 porque una dirección Ethernet (dirección MAC) tiene 6 octetos de longitud. CHADDR se establece en la dirección MAC utilizada por el cliente. También se configuran algunas opciones.

Oferta

Cuando un servidor DHCP recibe un mensaje DHCPDISCOVER de un cliente, que es una solicitud de concesión de dirección IP, el servidor DHCP reserva una dirección IP para el cliente y realiza una oferta de concesión enviándole un mensaje DHCPOFFER. Este mensaje puede contener el ID de cliente (Opción 61, que contiene un valor único, 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 tener en cuenta la dirección MAC a nivel de hardware (tal como se especifica en el campo CHADDR). Este campo debe utilizarse para identificar al cliente si no se proporciona un ID de cliente en el paquete DHCP. [ 1 ] : §4.2

El servidor DHCP determina la configuración en función de la dirección de hardware del cliente, tal como se especifica en el campo CHADDR (dirección de hardware del cliente). En el siguiente ejemplo, el servidor ( 192.168.1.1 ) especifica la dirección IP del cliente en el campo YIADDR (su dirección IP).

Pedido

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 DHCP de varios servidores, pero solo aceptará una.

El cliente debe enviar la opción de identificación del servidor en el mensaje DHCPREQUEST, indicando el servidor cuya oferta ha seleccionado. [ 1 ] : Sección 3.1, Punto 3 Cuando otros servidores DHCP reciben este mensaje, retiran cualquier oferta que hayan hecho al cliente y devuelven su dirección IP ofrecida al grupo de direcciones disponibles.

Reconocimiento

Cuando el servidor DHCP recibe el mensaje DHCPREQUEST del cliente, el proceso de configuración entra en su fase final. La fase de confirmación consiste en enviar un paquete DHCPACK al cliente. Este paquete incluye la duración del arrendamiento y cualquier otra información de configuración que el cliente haya solicitado. En este punto, el proceso de configuración IP se completa.

El protocolo espera que el cliente DHCP configure su interfaz de red con los parámetros negociados.

Selección y configuración de direcciones IP

Cuando el servidor reutiliza una dirección IP de su grupo, puede comprobar primero (mediante ping ) si no está ya en uso. [ 1 ] : sec. 2.2 Esto puede ocurrir si un host se configura manualmente con una dirección IP que se encuentra dentro del ámbito DHCP.

Antes de reclamar una dirección IP, el cliente debe sondear la dirección recién recibida (por ejemplo, con ARP ) para determinar si existe otro host en la red con la dirección IP propuesta. [ 1 ] : sec. 2.2 Si no hay respuesta, esta dirección no entra en conflicto con la de otro host, por lo que está disponible. Si este sondeo encuentra otro equipo que utiliza esa dirección, el cliente debe enviar un mensaje DHCPDECLINE al servidor o servidores DHCP.

Información

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

Lanzamiento

El cliente envía una solicitud al servidor DHCP para liberar la información DHCP y desactiva su dirección IP. Dado que los dispositivos cliente generalmente desconocen 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. El RFC 2132 describe las opciones DHCP disponibles definidas por la Autoridad de Números Asignados de Internet (IANA): parámetros DHCP y BOOTP. [ 13 ]

Un cliente DHCP puede seleccionar, manipular y sobrescribir parámetros proporcionados por un servidor DHCP. En sistemas tipo Unix, este ajuste a nivel de cliente normalmente se realiza de acuerdo con los valores del archivo de configuración /etc/dhclient.conf .

Opciones

Las opciones son cadenas de octetos de longitud variable. Esto se denomina codificación tipo-longitud-valor . El primer octeto es el código de la opción, el segundo indica 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 indica que le sigue un octeto y 0x02 es el valor de "oferta".

Las siguientes tablas enumeran las opciones DHCP disponibles. [ 14 ] [ 13 ]

Tipos de mensajes DHCP

Esta tabla enumera los tipos de mensajes DHCP. Estos códigos corresponden al valor de la extensión DHCP 53, que se muestra en la tabla anterior.

Identificación del proveedor del cliente

Existe una opción para identificar el proveedor y la funcionalidad de un cliente DHCP. Esta información consiste en una cadena de caracteres u octetos de longitud variable cuyo significado especifica el proveedor del cliente DHCP. Un método que utiliza un cliente DHCP para comunicar al servidor que está utilizando un determinado tipo de hardware o firmware es establecer un valor en sus solicitudes DHCP denominado Identificador de Clase de Proveedor (VCI) (Opción 60).

El valor que se le asigna a esta opción le da al servidor DHCP una pista sobre cualquier información adicional que este cliente necesite en una respuesta DHCP. Algunos tipos de decodificadores configuran el VCI para informar al servidor DHCP sobre el tipo de hardware y la funcionalidad del dispositivo. Un punto de acceso inalámbrico de campus Aruba , por ejemplo, proporciona el valor 'ArubaAP' como opción 60 en su mensaje DHCPDISCOVER. [ 20 ] El servidor DHCP puede entonces complementar su DHCPOFFER con una dirección IP de un controlador inalámbrico Aruba en la opción 43, para que el punto de acceso sepa dónde registrarse.

Configurar un VCI por parte del cliente permite que un servidor DHCP diferencie entre las máquinas cliente y procese las solicitudes de cada una de ellas de forma adecuada.

Otras extensiones

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 relé DHCP y un servidor DHCP. [ 22 ]

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 ha obtenido una dirección IP no puede comunicarse directamente con un servidor DHCP que no se encuentre en la misma subred, ya que la difusión del cliente solo puede recibirse dentro de su propia subred.

Para permitir que los clientes DHCP en subredes no atendidas directamente por servidores DHCP se comuniquen con estos, se pueden instalar agentes de retransmisión DHCP en dichas subredes. Un agente de retransmisión DHCP se ejecuta en un dispositivo de red, capaz de enrutar entre la subred del cliente y la del servidor DHCP. El cliente DHCP realiza una difusión 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, de la interfaz por la que ha recibido la difusión del cliente, en el campo GIADDR del paquete DHCP. El servidor DHCP utiliza el valor GIADDR para determinar la subred y, posteriormente, el grupo de direcciones correspondiente, del que asignar una dirección IP. Cuando el servidor DHCP responde al cliente, envía la respuesta a la dirección GIADDR, también mediante unidifusión. El agente de retransmisión retransmite la respuesta en la red local, mediante unidifusión (en la mayoría de los casos) a la dirección IP recién reservada, en una trama Ethernet dirigida a la dirección MAC del cliente. El cliente debe aceptar el paquete como propio, incluso si esa dirección IP aún no está configurada en la interfaz. [ 1 ] : 25 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 de la pila IP del cliente no acepta paquetes unicast cuando aún no tiene una dirección IP, el cliente puede activar 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 informarle sobre la oferta DHCPOFFER del servidor.

La comunicación entre el agente de retransmisión y el servidor DHCP normalmente utiliza el puerto UDP 67 tanto de origen como de destino.

Estados del cliente

Diagrama simplificado de transición de estados del cliente DHCP basado en la figura 5 de la RFC 2131.

Un cliente DHCP puede recibir estos mensajes de un servidor: [ 1 ] : §4.4

  • Oferta DHCP
  • DHCPACK
  • DHCPNAK

El cliente pasa por los estados DHCP dependiendo de cómo responda el servidor a los mensajes que envía el cliente.

Fiabilidad

El DHCP garantiza la fiabilidad de varias maneras: renovación periódica, reasignación, [ 1 ] : §4.4.5 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 concesiones una vez que ha expirado la mitad del intervalo de concesión. [ 1 ] : §4.4.5 Párrafo 3 Lo hacen enviando un mensaje DHCPREQUEST unicast al servidor DHCP que otorgó la concesión original. Si ese servidor está caído o no accesible, no responderá al DHCPREQUEST . Sin embargo, en ese caso el cliente repite el DHCPREQUEST de vez en cuando, [ 1 ] : §4.4.5 Párrafo 8 [ b ] de modo que si el servidor DHCP vuelve a estar operativo o vuelve a ser accesible, el cliente DHCP logrará contactarlo y renovar la concesión.

Si el servidor DHCP no está disponible durante un período prolongado, [ 1 ] : §4.4.5 Párrafo 5 el cliente DHCP intentará volver a vincularse, difundiendo su DHCPREQUEST en lugar de enviarlo por unidifusión. Debido a que se difunde , el mensaje DHCPREQUEST llegará a todos los servidores DHCP disponibles. Si algún otro servidor DHCP puede renovar la concesión, lo hará en ese momento.

Para que el restablecimiento de la conexión funcione, cuando el cliente se comunica correctamente con un servidor DHCP de respaldo, este debe tener información precisa sobre la conexión del cliente. Mantener información precisa sobre la conexión entre dos servidores es un problema complejo; si ambos servidores pueden actualizar la misma base de datos de concesiones, debe existir un mecanismo para evitar conflictos entre las actualizaciones en los servidores independientes. Se presentó una propuesta para implementar servidores DHCP tolerantes a fallos al Grupo de Trabajo de Ingeniería de Internet, pero nunca se formalizó. [ 31 ] [ c ]

Si la reconexión falla, el arrendamiento eventualmente expirará. Cuando el arrendamiento expira, el cliente debe dejar de usar la dirección IP que se le asignó en su arrendamiento. [ 1 ] : §4.4.5 Párrafo 9 En ese momento reiniciará el proceso DHCP desde el principio mediante la difusión de 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 usar la red. Sin embargo, dado que su dirección IP ha cambiado, cualquier conexión en curso se interrumpirá.

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 e implementación de redes IPv6 , DHCP también se ha utilizado para asignar parámetros en dichas redes, a pesar de las características inherentes de IPv6 para la autoconfiguración de direcciones sin estado . La versión IPv6 del protocolo se denomina DHCPv6 . [ 32 ]

Seguridad

El DHCP básico no incluye ningún mecanismo de autenticación. [ 22 ] : §7 Debido a esto, es vulnerable a una variedad de ataques. Estos ataques se dividen en tres categorías principales: [ 1 ] : sec. 7

  • 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 por parte 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 maliciosos ") pueden operar en las redes, proporcionando información incorrecta a los clientes DHCP. [ 33 ] Esto puede servir como un ataque de denegación de servicio , impidiendo que el cliente obtenga acceso a la conectividad de red, [ 34 ] o como un ataque de intermediario . [ 35 ] Debido a que el servidor DHCP proporciona al cliente DHCP direcciones IP de servidor, como la dirección IP de uno o más servidores DNS, [ 1 ] : sec. 7 un atacante puede convencer a un cliente DHCP de que realice sus búsquedas DNS a través de su propio servidor DNS y, por lo tanto, puede proporcionar sus propias respuestas a las consultas DNS del cliente. [ 36 ] Esto a su vez permite al atacante redirigir el tráfico de red a través de sí mismo, lo que le permite interceptar las conexiones entre el cliente y los servidores de red con los que se comunica, o simplemente reemplazar esos servidores de red con los suyos. [ 36 ]

Debido a que el servidor DHCP no cuenta con un mecanismo seguro para autenticar al cliente, estos pueden obtener acceso no autorizado a direcciones IP presentando credenciales, como identificadores de cliente, que pertenecen a otros clientes DHCP. [ 33 ] 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 específico, impidiendo que otros clientes DHCP reciban servicio. [ 33 ]

DHCP proporciona algunos mecanismos para mitigar estos problemas. La extensión del protocolo Relay Agent Information Option [ 22 ] (generalmente conocida en la industria por su número real como Opción 82 [ 37 ] [ 38 ] ) permite a los operadores de red adjuntar etiquetas a los mensajes DHCP cuando estos llegan a la red de confianza del operador. Esta etiqueta se utiliza como token de autorización para controlar el acceso del cliente a los recursos de red. Dado 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. [ 22 ] : sec. 7

Otra extensión, Autenticación para mensajes DHCP [ 39 ] (RFC 3118), proporciona un mecanismo para autenticar mensajes DHCP. Hasta 2002, esta extensión no había tenido una adopción generalizada debido a los problemas de gestión de claves para un gran número de clientes DHCP. [ 40 ] Un libro de 2007 sobre tecnologías DSL señaló 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ó el despliegue y la adopción del DHCP autenticado, y nunca se ha implementado ampliamente. [ 41 ]

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

Las propuestas arquitectónicas de 2008 implican autenticar las solicitudes DHCP usando 802.1X o PANA (ambos transportan EAP ). [ 43 ] Se hizo una propuesta de la IETF para incluir EAP en el propio DHCP, el llamado EAPoDHCP ; [ 44 ] esto no parece haber avanzado más allá del nivel de borrador de la IETF, el último de los cuales data de 2010. [ 45 ]

Documentos de estándares de la IETF

  • RFC 2131 – “ Protocolo de configuración dinámica de host ” , [ 1 ] Borrador de estándar. 
  • RFC 2132 – " Opciones DHCP y extensiones de proveedor BOOTP " , [ 14 ] Borrador de estándar. 
  • RFC 3046 – " Opción de información del agente de retransmisión DHCP " , [ 22 ] Estándar propuesto. 
  • RFC 3203 – " Extensión de reconfiguración DHCP " , [ 16 ] Estándar propuesto. 
  • RFC 3397 – " Opción de búsqueda de dominio del protocolo de configuración dinámica de host (DHCP) " , [ 26 ] Estándar propuesto. 
  • RFC 3442 – " La opción de ruta estática sin clases para el protocolo de configuración dinámica de host (DHCP) versión 4 " , [ 27 ] Estándar propuesto. 
  • RFC 3942 – " Reclasificación de las opciones del Protocolo de configuración dinámica de host versión 4 (DHCPv4) " , [ 46 ] Estándar propuesto. 
  • RFC 4361 – " Identificadores de cliente específicos del nodo para el protocolo de configuración dinámica de host versión cuatro (DHCPv4), " [ 47 ] Estándar propuesto. 
  • RFC 4388 – " Consulta de arrendamiento del protocolo de configuración dinámica de host (DHCP) " , [ 17 ] Estándar propuesto. 
  • RFC 4436 – " Detección de conexión de red en IPv4 (DNAv4), " [ 48 ] Estándar propuesto. 
  • RFC 6926 – " Consulta masiva de arrendamiento DHCPv4 " , [ 18 ] Estándar propuesto. 
  • RFC 7724 – " Consulta de arrendamiento DHCPv4 activa " , [ 19 ] Estándar propuesto. 
  • RFC 8415 – " Protocolo de configuración dinámica de host para IPv6 (DHCPv6) " , [ 10 ] Estándar propuesto. 

Véase también

Notas

  1. ↑ Como comportamiento opcional del cliente, algunas difusiones, como las que transportan mensajes de descubrimiento y solicitud DHCP, pueden ser reemplazadas por unidifusiones en caso de que el cliente DHCP ya conozca la dirección IP del servidor DHCP. [ 1 ]
  2. ↑ El RFC exige que el cliente espere la mitad del tiempo restante hasta T2 antes de retransmitir elpaquete DHCPREQUEST.
  3. ↑ La propuesta planteaba un mecanismo que permitía a dos servidores mantenerse sincronizados de forma flexible, de modo que, incluso en caso de fallo total de uno de ellos, el otro pudiera recuperar la base de datos de arrendamientos y seguir 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 se utilizan ampliamente, con implementaciones de código abierto y varias comerciales.

Referencias

  1. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 R. Droms ( marzo de 1997 ) . Protocolo de configuración dinámica de host . Grupo de trabajo de redes de la IETF . doi : 10.17487/RFC2131 . RFC 2131 .Borrador de norma. Sustituye a RFC 1541. Actualizado por RFC 3396 , 4361 , 5494 y 6842 .  
  2. ↑ Peterson, Larry L.; Davie, Bruce S. (2011). Redes informáticas: Un enfoque de sistemas (5.ª ed.). Elsevier. ISBN  978-0-12-385060-7Consultado el 21 de marzo de 2019 .
  3. ↑ Mrugalski, Tomek; Volz, Bernie; Richardson, Michael; Jiang, Sheng; Winters, Timothy (2025-05-06). Protocolo de configuración dinámica de host para IPv6 (DHCPv6) (Informe). Grupo de trabajo de ingeniería de Internet.
  4. ↑ R. Finlayson; T. Mann; J. Mogul; M. Theimer (junio de 1984). Un protocolo de resolución de direcciones inversa . Grupo de trabajo de redes. doi : 10.17487/RFC0903 . STD 38. RFC 903 .Estándar de Internet 38.
  5. ↑ Bill Croft; John Gilmore (septiembre de 1985). PROTOCOLO BOOTSTRAP (BOOTP) . Grupo de trabajo de redes. doi : 10.17487/RFC0951 . RFC 951 .Borrador de norma. Actualizado por RFC 1395 , 1497 , 1532 , 1542 y 5494 . 
  6. ↑ R. Droms (octubre de 1993). Protocolo de configuración dinámica de host . Grupo de trabajo de redes. doi : 10.17487/RFC1531 . RFC 1531 .Obsoleto. Obsoleto según la RFC 1541 , debido a errores en el proceso editorial. 
  7. ↑ R. Droms (octubre de 1993). Protocolo de configuración dinámica de host . Grupo de trabajo de redes. doi : 10.17487/RFC1541 . RFC 1541 .Obsoleto. Obsoleto según RFC 2131. Obsoleto según RFC 1531 .  
  8. 1 2 Certificación Network+ 2006 Publicado por Microsoft Press.
  9. ↑ J. Bound; B. Volz; T. Lemon; C. Perkins; M. Carney (julio de 2002). R. Droms (ed.). Protocolo de configuración dinámica de host para IPv6 (DHCPv6) . Grupo de trabajo de redes. doi : 10.17487/RFC3315 . RFC 3315 .Obsoleto. Obsoleto según RFC 8415. Actualizado por RFC 4361 , 5494 , 6221 , 6422 , 6644 , 7083 , 7283 , 7227 y 7550 .  
  10. 1 2 T. Mrugalski; M. Siodelski; B. Volz; A. Yourtchenko; M. Richardson; S. Jiang; T. Lemon; T. Winters (noviembre de 2018). Protocolo de configuración dinámica de host para IPv6 (DHCPv6) . Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC8415 . ISSN 2070-1721 . RFC 8415 . Norma propuesta. Deja obsoletos los RFC 3315 , 3633 , 3736 , 4242 , 7083 , 7283 y 7550 . 
  11. ↑ "DHCP - Protocolo de configuración dinámica de host" .
  12. ↑ Droms, Ralph; Lemon, Ted (2003). Manual de DHCP . SAMS Publishing . pág. 436. ISBN  978-0-672-32327-0.
  13. 1 2 "Parámetros del Protocolo de configuración dinámica de host (DHCP) y del Protocolo de arranque (BOOTP)" . iana.org . Consultado el 16 de octubre de 2018 .
  14. 1 2 3 4 5 6 7 8 9 10 S. Alexander; R. Droms (marzo de 1997). Opciones DHCP y extensiones de proveedor BOOTP . Grupo de trabajo de redes IETF . doi : 10.17487/RFC2132 . RFC 2132 .Borrador de norma. Sustituye a RFC 1533. Actualizado por RFC 3442 , 3942 , 4361 , 4833 y 5494 .  
  15. ↑ Droms, Ralph; Lemon, Ted (2003). Manual de DHCP (2.ª ed.). Indianápolis, Indiana: Sams (publicado en octubre de 2002). pág. 134. ISBN   978-0-672-32327-0.
  16. 1 2 Y. T'Joens; C. Hublet; P. De Schrijver (diciembre de 2001). Extensión de reconfiguración de DHCP . Grupo de Trabajo de Red. doi : 10.17487/RFC3203 . RFC 3203 .Norma propuesta. Actualizada por RFC 6704 . 
  17. 1 2 R. Woundy; K. Kinnear (febrero de 2006). Consulta de arrendamiento del protocolo de configuración dinámica de host (DHCP) . Grupo de trabajo de redes. doi : 10.17487/RFC4388 . RFC 4388 .Norma propuesta. Actualizada por RFC 6148 . 
  18. 1 2 K. Kinnear; M. Stapp; R. Desetti; B. Joshi; N. Russell; P. Kurapati; B. Volz (abril de 2013). Consulta masiva de arrendamiento DHCPv4 . Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC6926 . ISSN 2070-1721 . RFC 6926 . Norma propuesta. Actualizada por RFC 7724 . 
  19. 1 2 K. Kinnear; M. Stapp; B. Volz; N. Russell (diciembre de 2015). Consulta de arrendamiento DHCPv4 activa . Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC7724 . ISSN 2070-1721 . RFC 7724 . Norma propuesta. Actualiza la RFC 6926 . 
  20. ↑ "Opción DHCP 60 de Aruba" . 7 de octubre de 2020. Archivado del original el 17 de abril de 2022.
  21. ↑ G. Stump; R. Droms; Y. Gu; R. Vyaghrapuri; A. Demirtjis; B. Beser; J. Privat (noviembre de 2000). La opción de clase de usuario para DHCP . Grupo de trabajo de redes. doi : 10.17487/RFC3004 . RFC 3004 .Norma propuesta.
  22. 1 2 3 4 5 6 7 M. Patrick (enero de 2001). Opción de información del agente de retransmisión DHCP . Grupo de trabajo de redes. doi : 10.17487/RFC3046 . RFC 3046 .Estándar propuesto. Actualizado por RFC 6607 . 
  23. 1 2 3 D. Provan (noviembre de 1997). Opciones DHCP para Novell Directory Services . Grupo de trabajo de redes. doi : 10.17487/RFC2241 . RFC 2241 .Norma propuesta.
  24. ↑ E. Lear; P. Eggert (abril de 2007). Opciones de zona horaria para DHCP . Grupo de trabajo de redes. doi : 10.17487/RFC4833 . RFC 4833 .Norma propuesta. Actualiza la RFC 2132 . 
  25. ↑ W. Kumari; E. Kline (septiembre de 2020). Identificación de portal cautivo en DHCP y anuncios de enrutador (RA) . Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC8910 . ISSN 2070-1721 . RFC 8910 . Estándar propuesto. Sustituye a RFC 7710. Actualiza RFC 3679 .  
  26. 1 2 B. Aboba; S. Cheshire (noviembre de 2002). Opción de búsqueda de dominio del protocolo de configuración dinámica de host (DHCP) . Grupo de trabajo de redes. doi : 10.17487/RFC3397 . RFC 3397 .Norma propuesta.
  27. 1 2 T. Lemon; S. Cheshire ; B. Volz (diciembre de 2002). La opción de ruta estática sin clases para el protocolo de configuración dinámica de host (DHCP) versión 4. Grupo de trabajo de redes. doi : 10.17487/RFC3442 . RFC 3442 .Norma propuesta. Actualiza la RFC 2132 . 
  28. ↑ D. Hankins (diciembre de 2007). Opciones del protocolo de configuración dinámica de host utilizadas por PXELINUX . Grupo de trabajo de redes. doi : 10.17487/RFC5071 . RFC 5071 .Informativo.
  29. ↑ D. Jones; R. Woundy (abril de 2002). La subopción de información del agente de retransmisión DHCP (Protocolo de configuración dinámica de host) de la clase de dispositivo DOCSIS (Especificaciones de interfaz de servicio de datos sobre cable). Grupo de trabajo de redes. doi : 10.17487/RFC3256 . RFC 3256 .Norma propuesta.
  30. ↑ K. Kinnear; M. Stapp; R. Johnson; J. Kumarasamy (abril de 2003). Subopción de selección de enlace para la opción de información del agente de retransmisión para DHCPv4 . Grupo de trabajo de redes. doi : 10.17487/RFC3527 . RFC 3527 .Norma propuesta.
  31. ↑ 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 draft-ietf-dhc-failover-12 . Consultado el 9 de mayo de 2010 .
  32. ↑ Weinberg, Neal (14 de agosto de 2018). "Por qué los días de DHCP podrían estar contados" . Network World . Recuperado el 7 de agosto de 2019 .
  33. 1 2 3 Stapko, Timothy (2011). Seguridad integrada práctica: Creación de sistemas seguros con recursos limitados . Newnes. pág. 39. ISBN  978-0-08-055131-9.
  34. ↑ Rountree, Derrick (2013). Seguridad de red de Windows Server 2012: Protección de sus sistemas e infraestructura de red de Windows . Newnes. pág. 22. ISBN  978-1-59749-965-1.
  35. ↑ Rooney, Timothy (2010). Introducción a la gestión de direcciones IP . John Wiley & Sons. pág. 180. ISBN  978-1-118-07380-3.
  36. 1 2 Golovanov (Kaspersky Labs), Sergey (junio de 2011). "El cargador TDSS ahora tiene "piernas"Archivado del original el 25 de enero de 2021 .
  37. ↑ Hens, Francisco J.; Caballero, José M. (2008). Triple Play: Construyendo la red convergente para IP, VoIP e IPTV . John Wiley & Sons. pág. 239. ISBN  978-0-470-75439-9.
  38. ↑ Ramirez, David H. (2008). Seguridad IPTV: Protección de contenidos digitales de alto valor . John Wiley & Sons. pág. 55. ISBN  978-0-470-72719-5.
  39. ↑ R. Droms; W. Arbaugh, eds. (junio de 2001). Autenticación para mensajes DHCP . Grupo de trabajo de redes. doi : 10.17487/RFC3118 . RFC 3118 .Norma propuesta.
  40. ↑ Lemon, Ted (abril de 2002). "Implementación de RFC 3118" .
  41. ↑ Golden, Philip; Dedieu, Hervé; Jacobsen, Krista S. (2007). Implementación y aplicaciones de la tecnología DSL . Taylor & Francis. pág. 484. ISBN  978-1-4200-1307-8.
  42. ↑ Rooney, Timothy (2010). Introducción a la gestión de direcciones IP . John Wiley & Sons. págs. 181–182 . ISBN  978-1-118-07380-3.
  43. ↑ Copeland, Rebecca (2008). Converging NGN Wireline and Mobile 3G Networks with IMS . Taylor & Francis. pp. 142–143 . ISBN  978-1-4200-1378-8.
  44. ↑ Prasad, Ramjee; Mihovska, Albena (2009). Nuevos horizontes en comunicaciones móviles e inalámbricas: redes, servicios y aplicaciones . Vol. 2. Artech House. pág. 339. ISBN   978-1-60783-970-5.
  45. ↑ "Draft-pruss-DHCP-auth-DSL-07 - Extensiones de autenticación EAP para el protocolo de configuración dinámica de host para banda ancha" . Archivado del original el 3 de abril de 2015. Consultado el 12 de diciembre de 2013 .
  46. ↑ B. Volz (noviembre de 2004). Reclasificación de las opciones del Protocolo de configuración dinámica de host versión 4 (DHCPv4) . Grupo de trabajo de redes. doi : 10.17487/RFC3942 . RFC 3942 .Norma propuesta. Actualiza la RFC 2132 . 
  47. ↑ T. Lemon; B. Sommerfield (febrero de 2006). Identificadores de cliente específicos de nodo para el protocolo de configuración dinámica de host versión cuatro (DHCPv4) . Grupo de trabajo de redes. doi : 10.17487/RFC4361 . RFC 4361 .Estándar propuesto. Actualizado por RFC 5494. Actualiza RFC 2131 , 3315 y 2132 .  
  48. ↑ B. Aboba; J. Carlson; S. Cheshire (marzo de 2006). Detección de conexión de red en IPv4 (DNAv4) . Grupo de trabajo de redes. doi : 10.17487/RFC4436 . RFC 4436 .Norma propuesta.
  • Logotipo de Wikimedia CommonsContenido multimedia relacionado con el Protocolo de configuración dinámica de host (DHCP) en Wikimedia Commons.