Dynamic Host Configuration Protocol
DHCP (siglas en inglés de Dynamic Host Configuration 2 Asignación de direcciones IP
Protocol, en español «protocolo de configuración dinámi-
ca de host») es un servidor que usa protocolo de red de
Cada dirección IP debe configurarse manualmente en ca-
tipo cliente/servidor en el que generalmente un servidor
da dispositivo y, si el dispositivo se mueve a otra subred,
posee una lista de direcciones IP dinámicas y las va asig-
se debe configurar otra dirección IP diferente. El DHCP
nando a los clientes conforme éstas van quedando libres,
le permite al administrador supervisar y distribuir de for-
sabiendo en todo momento quién ha estado en posesión
ma centralizada las direcciones IP necesarias y, automá-
de esa IP, cuánto tiempo la ha tenido y a quién se la ha
ticamente, asignar y enviar una nueva IP si fuera el caso
asignado después. Así los clientes de una red IP pueden
en que el dispositivo es conectado en un lugar diferente
conseguir sus parámetros de configuración automática-
de la red.
mente. Este protocolo se publicó en octubre de 1993,
y su implementación actual está en la RFC 2131. Para El protocolo DHCP incluye tres métodos de asignación
DHCPv6 se publica el RFC 3315. de direcciones IP:
• Asignación manual o estática: Asigna una direc-
ción IP a una máquina determinada. Se suele utili-
zar cuando se quiere controlar la asignación de di-
1 Historia rección IP a cada cliente, y evitar, también, que se
conecten clientes no identificados.
DHCP se definió por primera vez como un protocolo de
seguimiento estático de las normas en el RFC 1531 en oc-
• Asignación automática: Asigna una dirección IP a
tubre de 1993, como una extensión del protocolo Boots-
una máquina cliente la primera vez que hace la so-
trap (BOOTP). La motivación para extender BOOTP era
licitud al servidor DHCP y hasta que el cliente la
porque BOOTP requería intervención manual para com-
libera. Se suele utilizar cuando el número de clien-
pletar la información de configuración en cada cliente, y
tes no varía demasiado.
no proporciona un mecanismo para la recuperación de las
direcciones IP en desuso.
Muchos trabajaron para mejorar el protocolo, ya que ga- • Asignación dinámica: el único método que permi-
nó popularidad y en 1997 se publicó el RFC 2131, y te la reutilización dinámica de las direcciones IP. El
al 2011 se mantiene como el estándar para redes IPv4. administrador de la red determina un rango de di-
DHCPv6 está documentado en el RFC 3315. El RFC recciones IP y cada dispositivo conectado a la red
3633 añadió un mecanismo de delegación de prefijo para está configurado para solicitar su dirección IP al ser-
DHCPv6. DHCPv6 se amplió aún más para proporcionar vidor cuando la tarjeta de interfaz de red se inicia-
información a los clientes con la configuración automáti- liza. El procedimiento usa un concepto muy simple
ca de direcciones sin estado en el RFC 3736. en un intervalo de tiempo controlable. Esto facilita
la instalación de nuevas máquinas clientes.
El protocolo BOOTP a su vez fue definido por primera
vez en el RFC 951 como un reemplazo para el protoco-
lo RARP (del inglés “Reverse Address Resolution Pro- Algunas implementaciones de DHCP pueden actualizar
tocol”), o resolución de direcciones inversa. La principal el DNS asociado con los servidores para reflejar las nue-
motivación para la sustitución de RARP con BOOTP fue vas direcciones IP mediante el protocolo de actualización
que RARP era un protocolo de la capa de enlace de datos. de DNS establecido en RFC 2136 (Inglés).
Esto hizo más difícil su aplicación en muchas plataformas
de servidores, y requería un servidor presente en cada en- El DHCP es una alternativa a otros protocolos de gestión
lace de red individual. BOOTP introdujo la innovación de direcciones IP de red, como el BOOTP (Bootstrap Pro-
de un agente de retransmisión, lo que permitió el envío tocol). DHCP es un protocolo más avanzado, pero ambos
de paquetes BOOTP fuera de la red local utilizando en- son los usados normalmente.
rutamiento IP estándar, por lo que un servidor central de En Windows 98 y posteriores, cuando el DHCP es inca-
BOOTP podría servir de anfitriones en muchas subredes paz de asignar una dirección IP, se utiliza un proceso lla-
IP.[1] mado "Automatic Private Internet Protocol Addressing".
1
2 5 ANATOMÍA DEL PROTOCOLO
3 Parámetros configurables
client server
Un servidor DHCP puede proveer de una configuración
opcional al dispositivo cliente. Dichas opciones están de- DISCOV
finidas en RFC 2132 (Inglés) Lista de opciones configu- E RY
rables:
• Dirección del servidor DNS OFFER
time
• Nombre DNS
• Puerta de enlace de la dirección IP REQUE
S T
• Dirección de Publicación Masiva (broadcast ad-
dress)
E DGE
• Máscara de subred
ACKNOWL
• Tiempo máximo de espera del ARP (Protocolo de
Resolución de Direcciones según siglas en inglés)
• MTU (Unidad de Transferencia Máxima según si-
glas en inglés) para la interfaz
• Servidores NIS (Servicio de Información de Red se-
gún siglas en inglés) Esquema de una sesión típica DHCP.
• Dominios NIS
5 Anatomía del protocolo
• Servidores NTP (Protocolo de Tiempo de Red según
siglas en inglés)
(Autoridad de Números Asignados en Internet según siglas
• Servidor SMTP en inglés) en BOOTP: 67/UDP para las computadoras
servidor y 68/UDP para los clientes.
• Servidor TFTP
• Nombre del servidor WINS
5.1 DHCP Discovery
4 Implementaciones DHCP Discovery es una solicitud DHCP realizada por
un cliente de este protocolo para que el servidor DHCP
Microsoft introdujo el DHCP en sus Servidores NT con de dicha red de computadoras le asigne una dirección IP
la versión 3.5 de Windows NT a finales de 1994. y otros Parámetros DHCP como la máscara de red o el
nombre DNS.[2]
El Consorcio de Software de Internet (ISC: Internet Soft-
ware Consortium) publicó distribuciones de DHCP para
Unix con la versión 1.0.0 del ISC DHCP Server el 6 de
diciembre de 1997 y una versión (2.0) que se adaptaba 5.2 DHCP Offer
mejor al RFC el día 22 de junio de 1999. Se puede en-
contrar el software en [Link] DHCP Offer es el paquete de respuesta del Servidor
Otras implementaciones importantes incluyen: DHCP a un cliente DHCP ante su petición de la asig-
nación de los Parámetros DHCP. Para ello involucra su
dirección MAC (Media Access Control).
• Cisco: un servidor DHCP habilitado en Cisco IOS
12.0 en el mes de febrero de 1999
• Sun: añadió el soporte para DHCP a su sistema ope- 5.3 DHCP Request
rativo Solaris el 8 de julio de 2001.
El cliente selecciona la configuración de los paquetes re-
Además, varios routers incluyen soporte DHCP para re- cibidos de DHCP Offer. Una vez más, el cliente solicita
des de hasta 255 dispositivos. una dirección IP específica que indicó el servidor
3
5.4 DHCP Acknowledge • Tutorial DHCP
El servidor reconoce la solicitud y la envía acuse de reci- • Videotutorial de DHCP en GNU/Linux
bo al cliente del cliente, se inicia la fase final del proce-
so de configuración. Esta fase implica el reconocimiento Estándares
con el envío de un paquete al cliente. Este paquete inclu-
ye la duración de la concesión y cualquier otra informa- • RFC 2131 - Dynamic Host Configuration Protocol
ción de configuración que el cliente pueda tener solicita-
da. En este punto, el proceso de configuración TCP/IP se • RFC 2132 - DHCP Options and BOOTP Vendor
ha completado. El servidor reconoce la solicitud y la en- Extensions
vía acuse de recibo al cliente. El sistema en su conjunto
• RFC 3046 - DHCP Relay Agent Information Option
espera el cliente para configurar su interfaz de red con las
opciones suministradas. El servidor DHCP responde a la • RFC 3942 - Reclassifying Dynamic Host Configu-
DHCPREQUEST con un DHCPACK, completando así ration Protocol Version Four (DHCPv4) Options
el ciclo de iniciación. La dirección origen es la dirección
IP del servidor de DHCP y la dirección de destino es to- • RFC 4242 - Information Refresh Time Option for
davía [Link]. El campo YIADDR contiene la Dynamic Host Configuration Protocol for IPv6
dirección del cliente, y los campos CHADDR y DHCP:
• RFC 4361 - Node-specific Client Identifiers for Dy-
Client Identifier campos son la dirección física de la tarje-
namic Host Configuration Protocol Version Four
ta de red en el cliente. La sección de opciones del DHCP
(DHCPv4)
identifica el paquete como un ACK.
• RFC 4436 - Detecting Network Attachment in IPv4
(DNAv4)
5.5 Confidencialidad
En un contexto de proveedor de Internet, los registros
DHCP de asignación de direcciones o bien contienen o
están vinculadas a información de identificación personal
confidencial, los datos de contacto del cliente. Estos son
atractivos para los spammers, y podrían ser buscados pa-
ra “expediciones de pesca” por las agencias de policía o
litigantes. Por lo menos una aplicación[cita requerida] imita la
política de Canadian Library Association para la circula-
ción del libro y no retiene información de identificación
una vez que el “préstamo” ha terminado.
6 Véase también
• DHCPv6 para IPv6
• BOOTP
• IP Control Protocol
• Zeroconf
7 Referencias
[1] Bill Croft; John Gilmore (September 1985). «RFC 951 -
Bootstrap Protocol». Network Working Group.
[2] «DHCP Options and BOOTP Vendor Extensions».
8 Enlaces externos
• ISC DHCP Server (en inglés)
4 9 ORIGEN DEL TEXTO Y LAS IMÁGENES, COLABORADORES Y LICENCIAS
9 Origen del texto y las imágenes, colaboradores y licencias
9.1 Texto
• Dynamic Host Configuration Protocol Fuente: [Link]
Colaboradores: Jmieres, Loqu, Moriel, Sauron, Robbot, Sanbec, Aloriel, Dodo, Ascánder, Sms, Rsg, Murphy era un optimista, Barcex, Enric
Naval, Valyag, PeiT, Cinabrium, Fmariluis, MatiasBellone, Digigalos, Spangineer, Edub, Yrithinnd, Rembiapo pohyiete (bot), RobotQuist-
nix, Superzerocool, Chobot, Yrbot, BOT-Superzerocool, Adrruiz, FlaBot, Vitamine, YurikBot, Cameri, Icvav, GermanX, KnightRider, The
Photographer, Er Komandante, Cheveri, Lancaster, Tomatejc, Calsbert, BOTpolicia, CEM-bot, Alex15090, -jem-, Hilmarz, Jjvaca, Baiji,
Roberpl, Pacovila, Mister, Eamezaga, Mancku, Dorieo, PabloCastellano, Un Mercenario, Arkimedes, RoyFocker, Isha, Egaida, RauBn,
Esacchi, Mpeinadopa, JAnDbot, CommonsDelinker, TXiKiBoT, Netito777, Ale flashero, Fixertool, Pólux, Biasoli, AlnoktaBOT, Cinevo-
ro, Rubenazo, Matdrodes, Mathlop, Shooke, Vatelys, Barri, AlleborgoBot, CarlosCuriel, Muro Bot, Cpurodriguez, Mjollnir1984, SieBot,
Ensada, DaBot~eswiki, Cobalttempest, Aleposta, Egjose, Jarisleif, Marcecoro, Txusinho, Farisori, Siina, Estirabot, Eduardosalg, Botellín,
Botito777, Esauro, Poco a poco, Alexbot, Açipni-Lovrij, AVBOT, Louperibot, Diegusjaimes, Arjuno3, Saloca, Luckas-bot, Ranamalo,
Ptbotgourou, Jotterbot, Aescanero, Xqbot, Jkbw, Gonzalograndon, SeFeDeK, Jsaenznoval, BenzolBot, Cesarth15, Panderine!, TobeBot,
Omerta-ve, Danielrios blog, PatruBOT, Ganímedes, Foundling, GrouchoBot, EmausBot, ONDIUX, Savh, AVIADOR, Desaroll, Lehonar-
dEuler, Sergio Andres Segovia, PATRICIADR, ChuispastonBot, WikitanvirBot, Wikipedista-perfeccionista, ILoveSugar, Josephmorcu,
Ginacast86, MetroBot, Pitufeta-2011, Gusama Romero, Creosota, Lemilio775, Legobot, Emferr, Abelleta16, Chmarkine, Balles2601,
Glaisher, ConnieGB, [Link], Jarould, Crystallizedcarbon, Javinande, Flechaveloz 29, Illuminati doritos y Anónimos: 313
9.2 Imágenes
• Archivo:DHCP_session_en.svg Fuente: [Link] Licencia: Public
domain Colaboradores: Trabajo propio Artista original: helix84
9.3 Licencia del contenido
• Creative Commons Attribution-Share Alike 3.0
