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

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 código DHCP DISCOVER (Descubrimiento).  Una analogía a esto sería una persona que pregunta abiertamente a las demás personas en una misma habitación si alguien es un servidor DHCP . Como el PC cliente aún no tiene IP y tampoco conoce la IP de algún servidor DHCP en la red, la dirección 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 petición expira y el cliente no recibe ninguna dirección IP. Alternativamente algunos sistemas operativos (como Windows) se autoasignan una dirección de tipo APIPA en el rango 169.254.0.0/16. Esta dirección no es enrutable y sirve solamente para establecer una conexión con alguna otra máquina en la misma red que se viera en la misma situación.

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 través del mensaje DISCOVER) y en la analogía de la persona en la habitación es equivalente a que una persona del grupo levante la mano y diga: “Yo soy un servidor DHCP”.

En la tercera fase el cliente envía un mensaje DHCP REQUEST (Solicitud), también de tipo broadcast. ¿Por qué broadcast y no Unicast? Simplemente por que el cliente aún no tiene dirección en este paso y su única opción 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 habitación (por que es Broadcast) ¿Puedes entregarme entonces una dirección 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 envía la IP, máscara de subred, dirección de gateway, servidores DNS y otros parámetros DHCP (ej: opciones de booteo para PXE, dirección de servidor TFTP, WINS, Lease time o tiempo de duración de la dirección 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 parámetros 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 varían y pueden ser por que hay un control de asignación 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 técnicas favoritas de los hackers para lanzar ataques en una red. Más 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 más detalle:

Más detalles pueden consultar en el RFC2131 sobre DHCP.

Use Facebook to Comment on this Post