Ya sea en un Datacenter cómo el de Google o en tu casa, con un Modem-Router de dudosa calidad. El procedimiento de asignación de direcciones IP se maneja bajo un estándar que se respeta. Ya sea si te conectás mediante un cable ethernet, o por WiFi, el proceso de negociación para que un dispositivo (desde ahora en más “host”) y un servidor DHCP (acrónimo de Dinamic Host Configuration Protocol) por más complejo que parezca, se puede simplificar para que lo entienda cualquiera, por más que no sea un experto en redes.

Un servidor DHCP es básicamente un manager que asigna una dirección IP a cada dispositivo que así se lo pida. DHCP se definió por primera vez en 1993 y se dió cómo una respuesta a la necesidad de automatizar el proceso de asignación de direcciones IP que hasta ese entonces se hacía de manera manual (lo que complicaba en demasía el trabajo de los administradores TI de las empresas).

Para entender el proceso, imaginemos que podemos, de alguna manera, traducir los BITS que se envían estos dispositivos a un lenguaje natural y humano

Conversación entre un host y uno o mas servers, en un medio compartido, como ethernet.

HOST (gritando para que escuchen todos[1]): ¿Alguien por acá es servidor DHCP? necesito una direccion IP ya que quiero comunicarme con ustedes y otros hosts a un nivel mas “alto”, ah, por las dudas para que me reconozcan, soy 0E:80:0:2:20:ef [2]!

Momentun de escucha, silencio y reflexión[3].

SERVER A: señor 0E:80:0:2:20:ef, yo tengo una dirección IP para darle, así deja de identificarse por un numero tan frío y poco identificable ¿Le parece bien la IP 10.0.0.254 con máscara 255.0.0.0.0 y cuya puerta de enlace, para comunicarse al exterior sea 10.0.0.2[4]?

HOST: bien, gracias SERVER A, tomaré ese [5]!

SERVER B: Perdón señor 0E:80:0:2:20:ef, estaba ocupado en otras tareas, le parece bien utilizar la dirección IP 192.168.0.10 con máscara 255.255.255.0 cuya puerta de enlace sea 192.168.0.1?

HOST: Gracias SERVER B, pero ya le mandé el paquete DHCPAck a SERVER A y estoy con sus servicios ahora.

Consideraciones según cada punto:

[1] El proceso DHCPdiscover se realiza por broadcast (gritando) y con el IP 0.0.0.0 en su campo.
[2] Para “entenderse sin IP” se manejan con un identificador de menor nivel, la MAC de la NIC.
[3] Llega el mensaje a los servers, éstos analizan si tienen IP’s disponibles, entre otros.
[4] Los servers envían el paquete DHCPOffer ofreciendo IP, máscara y puerta de enlace.
[5] El cliente confirma al servidor que primero le ofreció IP con un paquete DHCPAck

Agradezco cualquier corrección, dato adicional que pueda aportar al artículo

8 Comentarios

  1. Buenisimo, aunque tarde estoy entrando en la tecnologia, lo necesito y estas explicaciones son las mas faciles de entender.

  2. jajaj, me gusto la explicacion.

    Estuve probando el pasado año en linux, con servicios wireless, y la verdad que me gusto mucho. Y ahora este post, me hizo recordar eso, cuando veia los logs en la consola, de los nuevos dispositivos que se conectaban, primeramente gritando por un dhcp-dicovery, para luego recivir el dhcp-pack con todo incluido.

    Si esto, me lo hubiesen explicado hace 15 años, cuando empeze a puyar esto en windows 98 y windows 2000, hubiese sido una ganga para aquel entonces.

    Saludos.

  3. Me hace acordar a cuando teniamos que revisar el trafico de red de unas centrales voip, y clavabamos el Wireshark en una pc, conectada en un puerto de un switch, que era espejo de otro puerto donde estaba la central.

  4. – a la máscara 255.0.0.0.0 le sobra un campo
    – se puede agregar que ademas de broadcast, existe multicast.
    – esa mac 0E:80:0:2:20:ef no existe (da para un tema próximo, como se crean las macs)

Dejar respuesta

Please enter your comment!
Please enter your name here