Demos un paso atrás y echemos un vistazo muy básico a DHCP. Veamos la analogía de asignar una dirección postal a su casa. Por lo general, esto lo realiza el centro de llamadas de emergencia local u otra autoridad central. Por lo general, usan un mapa topográfico o un par de latitud y longitud para ubicarlo antes de asignar los números de su casa de un grupo de direcciones disponibles que son compatibles con otras direcciones en el área.
Digamos que no sabe a quién llamar y simplemente envía un mensaje a todos los que se encuentran dentro del alcance: sus vecinos, las autoridades locales, etc. Ellos explican que se encuentra en una determinada latitud y longitud y que tiene una dirección. Podrías agarrar un megáfono y gritarle.
«Hola. Mi LatLong es 80.0, 35.7. ¡Necesito una dirección! ¿Puede alguien ayudarme?»
Es una posibilidad remota, ya sabes, pero es lo único en lo que puedes pensar en este momento. Y, sorpresa, alguien con autoridad le responde con una OFERTA.
“¡Hola LatLong 80.0, 35.7! Tengo una dirección única en 62 Wimberly Place, aquí están los detalles. Por cierto, estaré en 46 Reardon Lane si quieres contactarme «.
No va a perder esta oportunidad, así que déjele saber a las autoridades que sí, quiere esta dirección como la que le dio. De hecho, sin duda, solicite la dirección formalmente.
¿Hola? 46 ¿Pista de Reardon? Me gustaría solicitar oficialmente esta dirección «62». ¿Aún está disponible?
Afortunadamente, las autoridades CONFIRMAN que la dirección es suya, o al menos por un tiempo.
LatLong 80.0, 35.7, esta dirección aún está disponible. ¡Te lo escribiré! ¡Disfrutar!
Usamos «LatLong 80.0, 35.7» porque esta negociación en particular se hace esencialmente gritando por encima de las vallas. Sin embargo, los dos participantes deben estar seguros de que están hablando con el interlocutor correcto, por lo que deben usarse identificadores que garanticen ser únicos. 62 Reardon Lane tiene su dirección, por lo que son únicos. 80,0, 35,7 no tiene direcciónpor lo que tienen que usar algo más que los identifique de manera única.
La versión de red de DORA
El proceso de negociación de DHCP se conoce como DORA: Descubrir, Ofrecer, Solicitar, Reconocer. Al igual que el intercambio anterior, se realiza a través de la red equivalente a gritar, es decir, a través del intercambio de difusión. Si bien los datos del usuario para los mensajes contienen información de dirección única (después del primer mensaje DISCOVER), la IP de destino (DIP) es siempre 255.255.255.255 – modo de transmisión. Todas las máquinas de la red ven el paquete, pero lo ignoran cuando miran la carga útil.
En varios puntos del intercambio también hay algunas otras opciones de respuesta, como NACK (del servidor DHCP si el cliente espera demasiado tiempo para la solicitud) y DECLINE (por ejemplo, si la configuración de dirección IP ofrecida no es ‘utilizable para el cliente’) . Los cubriremos en otro blog.
La versión de red del partido de gritos anterior se parece a esto:
Puede leer los pasos anteriores: básicamente se explican por sí mismos. Lo que no es siempre obviamente es que todos los intercambios tienen lugar en transmisiones en lugar de paquetes direccionados. En otras palabras, la DIP (dirección IP de destino) es siempre 255.255.255.255, la dirección de transmisión. El intercambio se vuelve semiprivado con la primera OFERTA mediante el uso de cargas útiles de mensajes.
DORA en paquetes
De hecho, vale la pena pensar en un intercambio de paquetes DHCP (muy brevemente). Por lo general, se parece a esto:
DHCP Discover
Ehternet Header: DA=FF-FF-FF-FF-FF-FF, SA=<client MAC>
IP Header: SIP=0.0.0.0, DIP=255.255.255.255
DHCP Payload: Client MAC=<client MAC>
DHCP Offer
Ethernet Header: DA=FF-FF-FF-FF-FF-FF, SA=<DHCP server MAC>
IP Header: SIP=<DHCP server IP address>, DIP=255.255.255.255
DHCP Payload: Offered IP=<offered IP>, Client MAC=<client MAC>,
Subnet Mask=<Subnet mask>, Router IP=<router IP>,
DNS=<DNS server1 IP, DNS server2 IP>, IP Lease Time=<time>s,
DHCP Server Identifier=<DHCP server IP address>
DHCP Request
Ethernet Header: DA=FF-FF-FF-FF-FF-FF, SA=<client MAC>
IP Header: SIP=0.0.0.0, DIP=255.255.255.255
DHCP Payload: Client MAC=<client MAC>,
Requested IP Address=<offered IP>,
DHCP Server Identifier=<DHCP server IP address>
DHCP Ack
Ethernet Header: DA=FF-FF-FF-FF-FF-FF, SA=<DHCP server MAC>
IP Header: SIP=<DHCP server IP address>, DIP=255.255.255.255
DHCP Payload: Offered IP=<offered IP>, Client MAC=<client MAC>,
Subnet Mask=<Subnet mask>, Router IP=<router IP>,
DNS=<DNS server1 IP, DNS server2 IP>, IP Lease Time=<time>s,
DHCP Server Identifier=<DHCP server IP address>Ciertamente, podríamos pasar bastante tiempo decodificando estos paquetes y explicando cada uno de los parámetros en detalle. Para este artículo, sin embargo, solo nos centraremos en algunas cosas:
- El servidor DHCP proporciona todos los parámetros de configuración necesarios en los mensajes OFERTA y ACK. No queda nada fuera: el cliente recibe una dirección IP, una máscara de subred, una ubicación de enrutador, las IP de ambos servidores DNS, el límite de tiempo de arrendamiento y la identidad del servidor DHCP. No se requiere nada más para que el cliente solicitante trabaje de forma independiente en la red.
- El cliente solicitante lo hace No comience a usar la dirección IP ofrecida hasta que reciba el mensaje ACK. Tenga en cuenta que en la solicitud DHCP anterior, el SIP (IP de origen) sigue siendo 0.0.0.0, aunque el cliente conoce la IP ofrecida (la devuelve en la solicitud de confirmación).
Ahí lo tienes, una vista muy básica de DHCP. En el próximo blog, hablaremos en profundidad sobre cómo múltiples servidores DHCP y múltiples clientes solicitantes pueden mantener las cosas bien.
