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)
martes, 28 de junio de 2011
lunes, 27 de junio de 2011
Debilidades de BOOTP
Una de las debilidades más importantes de BOOTP es la falta de soporte a asignación dinámica de direcciones. Esta debilidad se hizo más pronunciada cuando el internet empezó a despegar a finales de los 90, lo cual llevo directamente al desarrollo de DHCP.
DHCP se basó directamente en BOOTP, y tienen muchas características en común incluyendo el formato de mensajes. Existen versiones de BOOTP que son interoperables con DHCP.
A pesar de que DHCP reemplazó a BOOTP como el protocolo TCP/IP de configuración de host, el BOOTP se sigue usando actualmente en varias redes.
DHCP se basó directamente en BOOTP, y tienen muchas características en común incluyendo el formato de mensajes. Existen versiones de BOOTP que son interoperables con DHCP.
A pesar de que DHCP reemplazó a BOOTP como el protocolo TCP/IP de configuración de host, el BOOTP se sigue usando actualmente en varias redes.
Operación de BOOTP usando Agentes Relay BOOTP
- El cliente crea la solicitud:
Esto se hace de forma normal ya que la existencia
del agente de retransmisión es transparente al cliente.
- El cliente envía la solicitud:
El cliente emite el BOOTREQUEST de forma broadcast a la dirección
255.255.255.255.
- El agente de retransmisión recibe la solicitud y la procesa: El agente en la red física del cliente está escuchando al puerto UDP 67.
El agente procesa la solicitud de la siguiente manera:
- Revisa el valor del campo Hops, si el valor es menor o igual a 16 lo incrementa, caso contrario descarta la solicitud y no hace nada más.
- Examina los contenidos del campo GIAddr. Si el campo está lleno de ceros sabe que es el primer agente de retransmisión en manejar la solicitud y añade su IP a este campo (Si el agente tiene más de una dirección IP añade la de la interfaz que recibió la solicitud).
![]()
- El agente de retransmisión retransmite la solicitud:
El agente de retransmisión envía la solicitud BOOTP al servidor BOOTP. Si el agente sabe la dirección IP del servidor enviara la solicitud directamente de forma unicast. De otra forma, si el agente es un router, puede optar por emitir la solicitud a través de una interfaz diferente de la que recibió la solicitud. En este caso el agente pasaría la solicitud a la siguiente red esperando que el nuevo agente reconozca efectivamente la dirección IP del servidor BOOTP, es decir que está en su subred. Cada vez que la solicitud ingresara a un agente se daría el paso 3 del proceso, por lo cual el valor del campo Hops del mensaje se iría incrementando. Como se describe en el paso 3 la solicitud es descartada cuando el valor de Hops supera a 16, esto con el fin de que no hayan solicitudes rotando por la red eternamente.
- El servidor recibe la solicitud y la procesa:
El servidor BOOTP recibe la solicitud retransmitida desde el agente de retransmisión BOOTP y la procesa de forma normal.
- El servidor crea una respuesta:
El mensaje de respuesta se crea de forma normal.
- El servidor envía la respuesta:
Viendo que el valor del campo GIAddr era diferente a cero, el servidor se da cuenta de que la solicitud fue retransmitida. En vez de intentar enviar la respuesta de vuelta al cliente que envió la solicitud, este transmite la respuesta de forma unicast al agente de retransmisión especificado en GlAddr.
- El agente de retransmisión retransmite la respuesta:
El agente de retransmisión BOOTP transmite el mensaje BOOTREPLY de vuelta al cliente. Lo hace de forma unicast o broadcast, dependiendo del valor del campo CLAddr y de la flag B de la misma forma en que un servidor lo hace cuando no ha retransmisión.
Esto se hace de forma normal ya que la existencia
del agente de retransmisión es transparente al cliente.
- El cliente envía la solicitud:
El cliente emite el BOOTREQUEST de forma broadcast a la dirección
255.255.255.255.
- El agente de retransmisión recibe la solicitud y la procesa: El agente en la red física del cliente está escuchando al puerto UDP 67.
El agente procesa la solicitud de la siguiente manera:
- Revisa el valor del campo Hops, si el valor es menor o igual a 16 lo incrementa, caso contrario descarta la solicitud y no hace nada más.
- Examina los contenidos del campo GIAddr. Si el campo está lleno de ceros sabe que es el primer agente de retransmisión en manejar la solicitud y añade su IP a este campo (Si el agente tiene más de una dirección IP añade la de la interfaz que recibió la solicitud).
- El agente de retransmisión retransmite la solicitud:
El agente de retransmisión envía la solicitud BOOTP al servidor BOOTP. Si el agente sabe la dirección IP del servidor enviara la solicitud directamente de forma unicast. De otra forma, si el agente es un router, puede optar por emitir la solicitud a través de una interfaz diferente de la que recibió la solicitud. En este caso el agente pasaría la solicitud a la siguiente red esperando que el nuevo agente reconozca efectivamente la dirección IP del servidor BOOTP, es decir que está en su subred. Cada vez que la solicitud ingresara a un agente se daría el paso 3 del proceso, por lo cual el valor del campo Hops del mensaje se iría incrementando. Como se describe en el paso 3 la solicitud es descartada cuando el valor de Hops supera a 16, esto con el fin de que no hayan solicitudes rotando por la red eternamente.
- El servidor recibe la solicitud y la procesa:
El servidor BOOTP recibe la solicitud retransmitida desde el agente de retransmisión BOOTP y la procesa de forma normal.
- El servidor crea una respuesta:
El mensaje de respuesta se crea de forma normal.
- El servidor envía la respuesta:
Viendo que el valor del campo GIAddr era diferente a cero, el servidor se da cuenta de que la solicitud fue retransmitida. En vez de intentar enviar la respuesta de vuelta al cliente que envió la solicitud, este transmite la respuesta de forma unicast al agente de retransmisión especificado en GlAddr.
- El agente de retransmisión retransmite la respuesta:
El agente de retransmisión BOOTP transmite el mensaje BOOTREPLY de vuelta al cliente. Lo hace de forma unicast o broadcast, dependiendo del valor del campo CLAddr y de la flag B de la misma forma en que un servidor lo hace cuando no ha retransmisión.
Función de los Agentes Relay BOOTP
Para que la retransmisión BOOTP funcione necesitamos algo que actúe como intermediario entre el cliente y el servidor: un agente de retransmisión BOOTP. El trabajo de este es residir en la red física donde los clientes BOOTP podrían estar ubicados, y actuar como un proxy para el servidor BOOTP.
En la practica, un agente de retransmisión BOOTP no es usualmente un dispositivo de harware separado. Es un modulo de software que corre en un dispositivo existente que desempeña otras funciones. Es común que la funcionalidad de estos agentes sea implementada en un router IP. En ese caso, el router está funcionando como uno regular además de llevar el rol de agente BOOTP. Las funciones de retransmisión requeridas de parte de un agente de retransmisión BOOTP son diferentes a las labores normales de retransmisión de un datagrama IP de un router, a pesar de que hay similitudes.
El proceso de solicitud/respuesta de BOOTP cambia significativamente. Hay campos específicos en el formato de mensajes BOOTP que se utilizan para controlar el proceso. El RFC 1542 describe el funcionamiento de este proceso con detalle.
En la practica, un agente de retransmisión BOOTP no es usualmente un dispositivo de harware separado. Es un modulo de software que corre en un dispositivo existente que desempeña otras funciones. Es común que la funcionalidad de estos agentes sea implementada en un router IP. En ese caso, el router está funcionando como uno regular además de llevar el rol de agente BOOTP. Las funciones de retransmisión requeridas de parte de un agente de retransmisión BOOTP son diferentes a las labores normales de retransmisión de un datagrama IP de un router, a pesar de que hay similitudes.
El proceso de solicitud/respuesta de BOOTP cambia significativamente. Hay campos específicos en el formato de mensajes BOOTP que se utilizan para controlar el proceso. El RFC 1542 describe el funcionamiento de este proceso con detalle.
Agentes Relay BOOTP (Forwarding)
BOOTP está diseñado para permitir que el servidor BOOTP y los clientes a los que sirve estén en redes diferentes. Esto centraliza al servidor BOOTP y reduce enormemente la cantidad de trabajo requerido por los administradores de red. Implementar esta característica involucra a un dispositivo “externo” en el proceso de configuración.
Se esperaría que debido a que BOOTP usa IP podríamos enviar los mensajes de una red a otra arbitrariamente como con cualquier protocolo de mensajes basado en IP. Sin embargo, debemos tomar en cuenta de que a pesar de que BOOTP usa IP y UDP está basado en broadcast. Los hosts clientes usualmente no saben la dirección de un servidor, por lo cual envían la solicitud como un broadcast. Es decir, las solicitudes son emitidas a ningún servidor en particular de forma que cualquiera las puede “oír”. Por motivos de eficiencia los routers no enrutan dichas emisiones porque podrían atorar la red. Esto quiere decir que si el servidor y el cliente no están en la misma red, el servidor no podría oír la emisión del cliente. De forma similar, si el servidor recibe la solicitud y emite la respuesta de vuelta al cliente, este ultimo nunca la recibiría.
Es válido mencionar que en caso que el host cliente conociera la dirección IP del servidor BOOTP no sería necesario el uso de los agentes relay. La solicitud y la respuesta pueden enviarse directamente sobre una internetwork arbitraria.
Se esperaría que debido a que BOOTP usa IP podríamos enviar los mensajes de una red a otra arbitrariamente como con cualquier protocolo de mensajes basado en IP. Sin embargo, debemos tomar en cuenta de que a pesar de que BOOTP usa IP y UDP está basado en broadcast. Los hosts clientes usualmente no saben la dirección de un servidor, por lo cual envían la solicitud como un broadcast. Es decir, las solicitudes son emitidas a ningún servidor en particular de forma que cualquiera las puede “oír”. Por motivos de eficiencia los routers no enrutan dichas emisiones porque podrían atorar la red. Esto quiere decir que si el servidor y el cliente no están en la misma red, el servidor no podría oír la emisión del cliente. De forma similar, si el servidor recibe la solicitud y emite la respuesta de vuelta al cliente, este ultimo nunca la recibiría.
Es válido mencionar que en caso que el host cliente conociera la dirección IP del servidor BOOTP no sería necesario el uso de los agentes relay. La solicitud y la respuesta pueden enviarse directamente sobre una internetwork arbitraria.
Vendor-Specific Area
Los creadores de BOOTP se dieron cuenta de que ciertos tipos de hardware podían requerir información adicional a ser pasada del servidor al cliente con el fin de arrancar el cliente.
El protocolo BOOTP original no definía ningún tipo de estructura para este campo, dejándolo a decisión de cada fabricante de hardware. Evidentemente, nada evitaba que el cliente de un fabricante intentara enviar una solicitud a un servidor de otro fabricante. Si cada uno esperaba que este campo contuviera algo diferente, los resultados serían menos que satisfactorios. Así, para que el campo Vend fuera usado apropiadamente, ambos dispositivos debían estar hablando el mismo “lenguaje” en lo que respecta al significado de este campo. Esto se hace estableciendo los primeros cuatro bytes del campo con un valor especial. Cada fabricante elige su propio “número mágico” para este subcampo, el cual es también llamado “magic cookie”.
Incluir el campo Vend en BOOTP le da al protocolo extensibilidad para información especifica del fabricante. Desafortunadamente, el campo original no incluía ninguna forma de extender la información enviada del servidor al cliente a información TCP/IP genérica, independiente del fabricante. Esto era un gran descuido en la creación del protocolo porque hay muchos tipos de información que un host TCP/IP necesita al iniciarse que no tiene nada que ver con el fabricante. Por ejemplo, se le podría decir la dirección del router por defecto, la mascara de subred local, la dirección de un servidor DNS local, el MTU de una red local y mucho más. Esta información es independiente del fabricante, pero no hay lugar donde colocarla en el mensaje de respuesta BOOTP.
En el RFC 1048 se definió la forma de comunicar la información genérica adicional usando el campo Vend. Este esquema representa básicamente una forma particular de usar el campo, que la mayoría de implementaciones BOOTP TCP/IP ha adoptado sin tener en cuenta el fabricante. Esta mejora se conoce como BOOTP vendor information extensions. Para señalar que se le está dando este uso particular al campo Vend, se utiliza un valor “magic cookie” universal “90.130.83.99” que se inserta en los primeros cuatro bytes del campo.
Cuando las extensiones de la información de fabricante fueron presentadas, se creó una que apuntaba a un archivo donde se encontraba la información especifica del fabricante. Esto permite que los dispositivos puedan usar los campos estándar independientes del fabricante y también incorporar campos específicos del fabricante donde se necesiten. Posteriormente, se creó otro tipo de campo que permite que los campos específicos del fabricante se mezclaran con campos independientes del fabricante en un mismo mensaje BOOTP.
Estas extensiones de BOOTP se han vuelto tan populares que su uso es casi estándar. Es difícil de imaginar que alguien en la actualidad use el campo Vend solo para información especifica del fabricante de hardware.
El protocolo BOOTP original no definía ningún tipo de estructura para este campo, dejándolo a decisión de cada fabricante de hardware. Evidentemente, nada evitaba que el cliente de un fabricante intentara enviar una solicitud a un servidor de otro fabricante. Si cada uno esperaba que este campo contuviera algo diferente, los resultados serían menos que satisfactorios. Así, para que el campo Vend fuera usado apropiadamente, ambos dispositivos debían estar hablando el mismo “lenguaje” en lo que respecta al significado de este campo. Esto se hace estableciendo los primeros cuatro bytes del campo con un valor especial. Cada fabricante elige su propio “número mágico” para este subcampo, el cual es también llamado “magic cookie”.
Incluir el campo Vend en BOOTP le da al protocolo extensibilidad para información especifica del fabricante. Desafortunadamente, el campo original no incluía ninguna forma de extender la información enviada del servidor al cliente a información TCP/IP genérica, independiente del fabricante. Esto era un gran descuido en la creación del protocolo porque hay muchos tipos de información que un host TCP/IP necesita al iniciarse que no tiene nada que ver con el fabricante. Por ejemplo, se le podría decir la dirección del router por defecto, la mascara de subred local, la dirección de un servidor DNS local, el MTU de una red local y mucho más. Esta información es independiente del fabricante, pero no hay lugar donde colocarla en el mensaje de respuesta BOOTP.
En el RFC 1048 se definió la forma de comunicar la información genérica adicional usando el campo Vend. Este esquema representa básicamente una forma particular de usar el campo, que la mayoría de implementaciones BOOTP TCP/IP ha adoptado sin tener en cuenta el fabricante. Esta mejora se conoce como BOOTP vendor information extensions. Para señalar que se le está dando este uso particular al campo Vend, se utiliza un valor “magic cookie” universal “90.130.83.99” que se inserta en los primeros cuatro bytes del campo.
Cuando las extensiones de la información de fabricante fueron presentadas, se creó una que apuntaba a un archivo donde se encontraba la información especifica del fabricante. Esto permite que los dispositivos puedan usar los campos estándar independientes del fabricante y también incorporar campos específicos del fabricante donde se necesiten. Posteriormente, se creó otro tipo de campo que permite que los campos específicos del fabricante se mezclaran con campos independientes del fabricante en un mismo mensaje BOOTP.
Estas extensiones de BOOTP se han vuelto tan populares que su uso es casi estándar. Es difícil de imaginar que alguien en la actualidad use el campo Vend solo para información especifica del fabricante de hardware.
Suscribirse a:
Entradas (Atom)