Cómo Funciona El Proceso de Asignación de Direcciones Con DHCP

4
Cómo funciona el proceso de asignación de direcciones con DHCP (DORA) Publicado 28 octubre, 2011 | Por Paulo Colomés en RedesCisco.net Hace algún tiempo no escribía un artículo técnico y ahora tengo algo de tiempo para hacerlo mientras espero que se descarguen los 2.6 GB de una imagen ISO para VMware. Hoy quiero tocar una parte muy importante del protocolo DHCP que consiste en el proceso de asignación de direcciones IP automáticamente a los hosts de una red, proceso que se conoce como D.O.R.A (Discovery, Offer, Request, Acknowledgement). DHCP sin duda que facilita la vida en muchas cosas, sobre todo con aquellos usuarios que esperan que sus máquinas se enciendan y “mágicamente” ya puedan acceder a Internet, pero si recordamos el modelo OSI, no puede haber conexión con ninguna capa superior ni ninguna aplicación de red si no tenemos direccionamiento en capa 3. Tenemos un host A que no tiene dirección IP asignada e intentará buscar una mediante DHCP, obviamente es requisito indispensable que en la red exista un servidor DHCP. Cuando hablo de red me refiero al mismo dominio de broadcast, aunque bajo ciertas excepciones puede haber un servidor DHCP ubicado en otra red detrás de un router (funciona utilizando ip helper address). El proceso completo se explica en este diagrama.

description

Cómo Funciona El Proceso de Asignación de Direcciones Con DHCP

Transcript of Cómo Funciona El Proceso de Asignación de Direcciones Con DHCP

Cmo funciona el proceso de asignacin de direcciones con DHCP (DORA)

Publicado 28 octubre, 2011 | Por Paulo Coloms en RedesCisco.net

Hace algn tiempo no escriba un artculo tcnico y ahora tengo algo de tiempo para hacerlo mientras espero que se descarguen los 2.6 GB de una imagen ISO para VMware.

Hoy quiero tocar una parte muy importante del protocolo DHCP que consiste en el proceso de asignacin de direcciones IP automticamente a los hosts de una red, proceso que se conoce como D.O.R.A (Discovery, Offer, Request, Acknowledgement).

DHCP sin duda que facilita la vida en muchas cosas, sobre todo con aquellos usuarios que esperan que sus mquinas se enciendan y mgicamente ya puedan acceder a Internet, pero si recordamos el modelo OSI, no puede haber conexin con ninguna capa superior ni ninguna aplicacin de red si no tenemos direccionamiento en capa 3.

Tenemos un host A que no tiene direccin IP asignada e intentar buscar una mediante DHCP, obviamente es requisito indispensable que en la red exista un servidor DHCP. Cuando hablo de red me refiero al mismo dominio de broadcast, aunque bajo ciertas excepciones puede haber un servidor DHCP ubicado en otra red detrs de un router (funciona utilizando ip helper address).

El proceso completo se explica en este diagrama.

El primer paso lo ejecuta el cliente DHCP instalado en el PC (En Windows viene instalado por defecto, al igual que en Linux y S.O. similares) enviando un mensaje de broadcast con el cdigo DHCP DISCOVER (Descubrimiento). Una analoga a esto sera una persona que pregunta abiertamente a las dems personas en una misma habitacin si alguien es un servidor DHCP . Como el PC cliente an no tiene IP y tampoco conoce la IP de algn servidor DHCP en la red, la direccin de destino es un broadcast (IP: 255.255.255.255 MAC: FF-FF-FF-FF-FF-FF, puerto de destino 67 UDP correspondiente al servidor, puerto de origen: 68 UDP correspondiente al cliente).

Si no existe un servidor DHCP en la red, simplemente la peticin expira y el cliente no recibe ninguna direccin IP. Alternativamente algunos sistemas operativos (como Windows) se autoasignan una direccin de tipo APIPA en el rango 169.254.0.0/16. Esta direccin no es enrutable y sirve solamente para establecer una conexin con alguna otra mquina en la misma red que se viera en la misma situacin.

Caso contrario, si efectivamente hay un servidor DHCP ste responde de vuelta a la solicitud con un mensaje DHCP OFFER (Ofrecimiento). Es un mensaje Unicast (ya que l ya conoce la MAC del PC a travs del mensaje DISCOVER) y en la analoga de la persona en la habitacin es equivalente a que una persona del grupo levante la mano y diga: Yo soy un servidor DHCP.

En la tercera fase el cliente enva un mensaje DHCP REQUEST (Solicitud), tambin de tipo broadcast. Por qu broadcast y no Unicast? Simplemente por que el cliente an no tiene direccin en este paso y su nica opcin es seguir enviando broadcasts. Equivalente a que la persona que originalmente preguntaba quien es un servidor DHCP ahora pregunte a toda las personas en la misma habitacin (por que es Broadcast) Puedes entregarme entonces una direccin IP?.

La ltima etapa puede tener una respuesta positiva (ACKNOWLEDGEMENT o simplemente ACK) o negativa (NO ACKNOWLEDGEMENT o NACK). Si el servidor DHCP puede cumplir la solicitud, ste le enva la IP, mscara de subred, direccin de gateway, servidores DNS y otros parmetros DHCP (ej: opciones de booteo para PXE, direccin de servidor TFTP, WINS, Lease time o tiempo de duracin de la direccin IP antes de actualizarse, etc). y el cliente puede existosamente autoconfigurar su tarjeta de red con los datos recibidos.

En caso de que el servidor DHCP no pueda entregar los parmetros requeridos, ste devuelve un NACK y el cliente naturalmente no obtendr ninguna IP. Las razones por las cuales puedan enviarse NACKs desde el servidor hacia el cliente varan y pueden ser por que hay un control de asignacin estricto mediante direcciones MAC permitidas y la del cliente no est en la lista o por que se ha agotado el rango disponible en el servidor DHCP (esto se conoce como DHCP depletion y es una de las tcnicas favoritas de los hackers para lanzar ataques en una red. Ms info al respecto en: http://www.redescisco.net/v2/art/mitigando-ataques-de-dhcp-spoofing-utilizando-snooping-en-switches-cisco/).

Aunque en Windows este proceso no es muy visible (salvo con un sniffer como Wireshark), en la consola Unix/Linux si se puede ver con ms detalle:

Ms detalles pueden consultar en el RFC2131 sobre DHCP.