Procedimiento Detallado de BOOTP

1. El Cliente crea la solicitud

La maquina del cliente empieza el procedimiento creando un mensaje de solicitud BOOTP. Cuando crea este mensaje, lo llena con la siguiente información:

- Establece el tipo de mensaje (Op) en 1, para mensaje BOOTREQUEST. Si sabe su propia dirección IP y planea seguir usandola, lo especifica en el campo CIAddr. De otra forma, llena este campo con ceros.

- Pone su dirección de hardware (capa dos) en el campo CHAddr. Esto es usado por el servidor para determinar la dirección correcta y otros parametros para el cliente.

- Genera un identificador de transacción aleatorio, y lo pone en el campo XID.

- El cliente puede especificar un servidor particular que quiere que le responda y pone eso en el campo Sname. También puede especificar en el campo File el nombre de un tipo particular de archivo boot que quiere que el servidor le brinde.

- El cliente puede especificar información especifica del fabricante, si se ha programado para hacerlo.

2. El cliente envía la solicitud


El cliente emite de forma broadcast el mensaje BOOTREQUEST transmitiendolo a la dirección 255.255.255.255. Alternativamente, si ya sabe la dirección de servidor BOOTP, puede mandar la solicitud de forma unicast.

3. El Servidor recibe la solicitud y la procesa

Un servidor BOOTP, escuchando el puerto UDP 67 recibe la solicitud emitida y la procesa. Si el nombre de un servidor particular fue especificado y es diferente del nombre del servidor que ha recibido la solicitud, este puede descartar la solicitud. Esto es cierto especialmente si sabe que el servidor que el cliente solicitó está también en la red local. Si ningun servidor en particular es específicado, o este servidor es el que el cliente queria, el servidor va a responder.

4. El Servidor crea la respuesta

El servidor crea un mensaje de respuesta copiando el mensaje de solicitud y cambiando varios campos:

- Cambia el tipo de mensaje (Op) al valor 2, para un mensaje BOOTREPLY. Toma la dirección de hardware especificada por el cliente en el campo CHAddr y lo usa en una busqueda a la tabla para encontrar la dirección IP que corresponde a este host. Luego ubica este valor en el campo YIAddr ("tu dirección IP") de la respuesta.

- Procesa el campo File y brinda el el nombre de archivo que el cliente solicitó, si el campo estaba vacio, el nombre de archivo por defecto.

- Pone su propia dirección IP y nombre en los campos SIAddr y SName. Establece cualquier valor específico del fabricante en el campo Vend.

*Manejo del campo ClAddr
El RFC 1542 establece el estandar para manejar el significado de este campo:

Si un cliente está dispuesto a aceptar cualquier dirección IP que el servidor le otorgue, establece CIAddr en puros ceros, aun si conoce una dirección previa.

Si el cliente llena un valor para el campo, está diciendo que usará está dirección y tiene que estar preparada para recibir mensajes unicast enviados a aquella dirección.

Si el cliente especifica una dirección CIAddr y recibe una dirección diferente en el campo YIAddr, la dirección provista por el servidor es ignorada.

Todos los dispositivos de hardware tienen que necesariamente estar de acuerdo con está interpretación como se provee en el RFC 1542, así que siguen habiendo problemas de interoperabilidad con equipos antiguos. El RFC 1542 fue escruto en 1993, asi que ya no debe ser un problema serio.

5. El Servidor envía respuesta
El Servidor envía la respuesta, el método depende de los contenidos de la solicitud:

- Si el flag B (Broadcast) está establecido, indica que el cliente no puede mandar la respuesta vía unicast, entonces el servidor la emite vía broadcast.

- Si el campo CIAddr es diferente de cero, el servidor enviará la respuesta vía unicast a aquella CIAddr (dirección IP del cliente).
Si la bandera B es cero y el campo CIAddr también es cero, el servidor podría usar una entrada ARP o broadcast.

6. El Cliente Procesa la respuesta
El cliente recibe la respuesta del servidor y la procesa, guardando la información y los parámetros provistos.

7. El Cliente completa el proceso de boot
Una vez configurado, el cliente procede con la fase dos del proceso bootstrap, usando un protocolo como TFTP para descargar el archivo de boot que contiene el software del sistema operativo, usando el nombre de archivo que el servidor devolvio.

Podemos ver un diagrama de secuencia del uso del protocolo BOOTP en una red local y mediante el uso de agentes Relay en el siguiente enlace: Diagrama de secuencia BOOTP (pdf - inglés)