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.
Formato del Mensaje BOOTP
El intercambio de información en BOOTP toma la forma de un request enviado por un cliente, y una respuesta del servidor. BOOTP usa un formato de mensaje común para solicitudes y respuestas. El cliente empieza por separar espacio de memoria para el mensaje y lo llena con puros ceros. Luego llena los campos del mensaje y envía la solicitud. El servidor crea la respuesta copiando la solicitud y cambiando los valores de ciertos campos.
Funcionamiento General de BOOTP
Proceso de broadcast dual:
En este ejemplo el dispositivo A intenta determinar su dirección IP y otros parámetros. Emite una solicitud BOOTP en la red local usando el puerto UDP 67 y luego espera una respuesta en el puerto 68. El dispositivo D está configurado como servidor BOOTP y escucha este puerto. Cuando recibe la solicitud envía una transmisión en el puerto 68 diciéndole a A cual es su dirección IP.
Uso de broadcasts y puertos
El hecho de que los servidores BOOTP se vean en la necesidad de devolver un broadcast al cliente exige algunos cambios en la manera en la cual la mayoría de protocolos TCP/IP usan los puertos cliente. Normalmente, el cliente en una transacción cliente/servidor que usa UDP o TCP genera un número de puerto temporal o efímero que usa como puerto origen en su solicitud. El servidor envía la respuesta de vuelta a la dirección IP del cliente usando ese número de puerto temporal. Los puertos temporales tienen que ser únicos para una dirección IP particular, pero podrían no ser necesariamente únicos a través de todos los dispositivos de una red. Por ejemplo, el dispositivo A podría estar usando el puerto temporal número 1248 para una solicitud HTTP a un servidor Web, mientras que un dispositivo B podría estar usando ese mismo puerto en su pila TCP/IP para enviar una solicitud DNS.
Un servidor BOOTP no puede hacer un envío seguro a un puerto temporal debido a que usa broadcast (no se está dirigiendo a un dispositivo particular con una transmisión unicast). Otro servidor en la red podría haber seleccionado el mismo puerto temporal para alguna otra transacción y podría confundir la respuesta del servidor BOOTP como una siendo enviada para sí. Para evitar esto, otro número de puerto muy conocido se usa solo para clientes BOOTP: el puerto UDP 68. Los clientes “escuchan” este puerto en espera de transmisiones broadcast o unicast, mientras que los dispositivos que no han enviado una solicitud BOOTP lo ignorarán.
Un servidor BOOTP no puede hacer un envío seguro a un puerto temporal debido a que usa broadcast (no se está dirigiendo a un dispositivo particular con una transmisión unicast). Otro servidor en la red podría haber seleccionado el mismo puerto temporal para alguna otra transacción y podría confundir la respuesta del servidor BOOTP como una siendo enviada para sí. Para evitar esto, otro número de puerto muy conocido se usa solo para clientes BOOTP: el puerto UDP 68. Los clientes “escuchan” este puerto en espera de transmisiones broadcast o unicast, mientras que los dispositivos que no han enviado una solicitud BOOTP lo ignorarán.
Retransmisión de mensajes perdidos
Un inconveniente a la simplicidad de usar UDP para los mensajes BOOTP es que no obtenemos características de transporte de calidad. UDP es poco fiable, una solicitud BOOTP podría perderse antes de llegar al servidor, en forma similar la respuesta del servidor podría no regresar al cliente. Como muchos otros protocolos que usan UDP, los clientes BOOTP cuidan esto usando un temporizador de retransmisión. Si luego de cierto periodo de tiempo el cliente no ha recibido una respuesta, reenvía la solicitud.
Sin embargo, los clientes BOOTP deben tener cuidado sobre como implementar su estrategia de retransmisión. Considere un escenario donde una red con 200 clientes BOOTP pierde el suministro eléctrico. Estas maquinas son muy similares, entonces cuando regresa la electricidad todas se reinician e intentan enviar solicitudes BOOTP casi al mismo tiempo. Más probablemente, ocurrirán problemas debido a todas estas solicitudes; algunas se perderán y otras serán abandonadas debido a la sobrecarga.
Si todos los clientes usan el mismo tiempo para la retransmisión, cuando ese tiempo culmine un montón de computadoras enviarán nuevamente solicitudes y se recreará el problema original. Para evitar esto, el estándar BOOTP recomienda usar un esquema backoff exponencial para la retransmisiones, empezando con un intervalo de 4 segundos y duplicándolo en los intentos sucesivos. Un elemento aleatorio también debe ser sumado o restado para prevenir que coincidan las retransmisiones de demasiados dispositivos. De esta manera reducimos las chances de perder retransmisiones y nos aseguramos de que el tráfico BOOTP no atasque la red.
Sin embargo, los clientes BOOTP deben tener cuidado sobre como implementar su estrategia de retransmisión. Considere un escenario donde una red con 200 clientes BOOTP pierde el suministro eléctrico. Estas maquinas son muy similares, entonces cuando regresa la electricidad todas se reinician e intentan enviar solicitudes BOOTP casi al mismo tiempo. Más probablemente, ocurrirán problemas debido a todas estas solicitudes; algunas se perderán y otras serán abandonadas debido a la sobrecarga.
Si todos los clientes usan el mismo tiempo para la retransmisión, cuando ese tiempo culmine un montón de computadoras enviarán nuevamente solicitudes y se recreará el problema original. Para evitar esto, el estándar BOOTP recomienda usar un esquema backoff exponencial para la retransmisiones, empezando con un intervalo de 4 segundos y duplicándolo en los intentos sucesivos. Un elemento aleatorio también debe ser sumado o restado para prevenir que coincidan las retransmisiones de demasiados dispositivos. De esta manera reducimos las chances de perder retransmisiones y nos aseguramos de que el tráfico BOOTP no atasque la red.
Envío y transporte de mensajes BOOTP
El envío de mensajes BOOTP usa el User Datagram Protocol (UDP) como protocolo de la capa de transporte por un par de razones. Primero, UDP es mucho menos complejo que los otros protocolos de la capa de transporte y es ideal para protocolos “solicitud/respuesta” simples como BOOTP. Segundo, debido a que el cliente obviamente no conoce la dirección del servidor BOOTP, la solicitud es emitida de forma broadcast en la red local; UDP soporta broadcast mientras que TCP no.
UDP usa un número de puerto reservado para servidores BOOTP: puerto UDP 67. El servidor BOOTP “escucha” el puerto 67 para estas solicitudes BOOTP emitidas por los clientes. Después de procesar la solicitud, el servidor devuelve una respuesta al cliente. La forma en que se maneja esto depende de si el cliente conoce su dirección propia o no:
El cliente conoce su propia dirección: Cuando el cliente BOOTP ya conoce su propia dirección esta puede ser usada por el servidor BOOTP para devolver la respuesta directamente.
El cliente no conoce su propia dirección: El servidor BOOTP tiene dos opciones. Si el sistema operativo lo permite, el servidor puede usar la dirección de hardware del cliente para crear una entrada ARP (en la PROM, usando la IP asignada y con timeout como cualquier entrada ARP) para el dispositivo y luego usar un unicast capa dos para entregar la respuesta. De otra forma, tiene que enviar la respuesta como broadcast en la red local.
UDP usa un número de puerto reservado para servidores BOOTP: puerto UDP 67. El servidor BOOTP “escucha” el puerto 67 para estas solicitudes BOOTP emitidas por los clientes. Después de procesar la solicitud, el servidor devuelve una respuesta al cliente. La forma en que se maneja esto depende de si el cliente conoce su dirección propia o no:
El cliente conoce su propia dirección: Cuando el cliente BOOTP ya conoce su propia dirección esta puede ser usada por el servidor BOOTP para devolver la respuesta directamente.
El cliente no conoce su propia dirección: El servidor BOOTP tiene dos opciones. Si el sistema operativo lo permite, el servidor puede usar la dirección de hardware del cliente para crear una entrada ARP (en la PROM, usando la IP asignada y con timeout como cualquier entrada ARP) para el dispositivo y luego usar un unicast capa dos para entregar la respuesta. De otra forma, tiene que enviar la respuesta como broadcast en la red local.
Tabla BOOTP: Ejemplo
En este ejemplo si 'mjh-gateway' hace un boot normal, obtendrá el archivo '/usr/boot/gate.mjh'.
Tabla BOOTP: Formato
La tabla tiene dos secciones delimitadas por una línea conteniendo un ‘%’ en la columna 1.
La primera sección contiene un directorio por defecto y mapeos de nombres genéricos a directorio/rutas. El primer genericname en esta sección es el ‘archivo por defecto’ que se obtiene cuando el BOOOTREQUEST contiene una cadena nula en el campo ‘file’.
La segunda sección mapea direcciones y tipos de hardware con direcciones IP. Opcionalmente se puede anular el genericname por defecto suministrando un genericname con ipaddress especifica.
El campo ‘suffix’ también es opcional, si se suministra cualquier genericname especificado por el cliente será accedido agregando ‘suffix’ a pathname. Si ese archivo no es encontrado, se intentará con pathname solo. La opción ‘suffix’ permite implementar un set completo de genericnames adaptables sin mucho esfuerzo.
Los campos son delimitados por uno o más espacios o tabs; los campos vacios son omitidos, las líneas en blanco y las que empiezan con ‘#’ también se omiten.
![]()
La primera sección contiene un directorio por defecto y mapeos de nombres genéricos a directorio/rutas. El primer genericname en esta sección es el ‘archivo por defecto’ que se obtiene cuando el BOOOTREQUEST contiene una cadena nula en el campo ‘file’.
La segunda sección mapea direcciones y tipos de hardware con direcciones IP. Opcionalmente se puede anular el genericname por defecto suministrando un genericname con ipaddress especifica.
El campo ‘suffix’ también es opcional, si se suministra cualquier genericname especificado por el cliente será accedido agregando ‘suffix’ a pathname. Si ese archivo no es encontrado, se intentará con pathname solo. La opción ‘suffix’ permite implementar un set completo de genericnames adaptables sin mucho esfuerzo.
Los campos son delimitados por uno o más espacios o tabs; los campos vacios son omitidos, las líneas en blanco y las que empiezan con ‘#’ también se omiten.
Clientes y Servidores BOOTP
Como muchos otros protocolos TCP/IP, BOOTP es de naturaleza cliente/servidor. La operación de el protocolo consiste en un intercambio simple de mensajes entre un cliente y un servidor BOOTP.
Un cliente BOOTP puede ser cualquier tipo de dispositivo que necesite ser configurado.
Un servidor BOOTP es un dispositivo de red que ha sido configurado especialmente para responder solicitudes de clientes BOOTP, y ha sido programado con direccionamiento y otra información que le pueda brindar a los clientes cuando se requiera.
El servidor BOOTP mantiene un conjunto de información especial sobre los clientes a los cuales sirve. Una parte clave de esto es una tabla que mapea las direcciones hardware de cada cliente (capa dos, enlace de datos) a una dirección IP asignada para ese dispositivo. El cliente especifica su dirección de hardware en su solicitud y el servidor la usa para buscar la dirección IP y retornarla al cliente (se pueden usar otras técnicas pero la tabla de mapeo es más común).
Un cliente BOOTP puede ser cualquier tipo de dispositivo que necesite ser configurado.
Un servidor BOOTP es un dispositivo de red que ha sido configurado especialmente para responder solicitudes de clientes BOOTP, y ha sido programado con direccionamiento y otra información que le pueda brindar a los clientes cuando se requiera.
El servidor BOOTP mantiene un conjunto de información especial sobre los clientes a los cuales sirve. Una parte clave de esto es una tabla que mapea las direcciones hardware de cada cliente (capa dos, enlace de datos) a una dirección IP asignada para ese dispositivo. El cliente especifica su dirección de hardware en su solicitud y el servidor la usa para buscar la dirección IP y retornarla al cliente (se pueden usar otras técnicas pero la tabla de mapeo es más común).
Aplicaciones
A pesar que el nombre BOOTP implica todo lo necesario para arrancar un dispositivo sin almacenamiento ese no es el caso. Como el mismo estándar BOOTP lo describe, el “bootstrapping” generalmente requiere dos fases:
En la primera, se le provee al cliente de una dirección y otros parámetros.
En la segunda fase el cliente emplea un protocolo como TFTP para descargar software u otros parámetros de configuración (sistemas operativos y drivers) que le permiten funcionar en la red y realizar cualquier labor que se le encargue.
El hecho de que BOOTP pueda usarse para brindar información a un cliente más allá de una simple dirección IP lo hace útil aun en casos cuando el dispositivo ya conoce su dirección.
BOOTP puede ser usado para enviar parámetros que el administrador quiere que todos los hosts tengan y asegurarse de que usan la red en una manera consistente.
Asimismo, en el caso de dispositivos que tienen almacenamiento local (y por consiguiente no necesitan obtener una dirección IP) el BOOTP aun puede ser usado para que estos obtengan el nombre del archivo boot para la fase dos del bootstrapping descrito anteriormente.
En la primera, se le provee al cliente de una dirección y otros parámetros.
En la segunda fase el cliente emplea un protocolo como TFTP para descargar software u otros parámetros de configuración (sistemas operativos y drivers) que le permiten funcionar en la red y realizar cualquier labor que se le encargue.
El hecho de que BOOTP pueda usarse para brindar información a un cliente más allá de una simple dirección IP lo hace útil aun en casos cuando el dispositivo ya conoce su dirección.
BOOTP puede ser usado para enviar parámetros que el administrador quiere que todos los hosts tengan y asegurarse de que usan la red en una manera consistente.
Asimismo, en el caso de dispositivos que tienen almacenamiento local (y por consiguiente no necesitan obtener una dirección IP) el BOOTP aun puede ser usado para que estos obtengan el nombre del archivo boot para la fase dos del bootstrapping descrito anteriormente.
miércoles, 22 de junio de 2011
Historia y Fundamentos del Protocolo BOOTP
El problema de automatizar los parámetros de configuración de los hosts de una red IP tiene tanto tiempo como el protocolo TCP/IP. Al no haber otra manera de arrancar y configurar estaciones sin almacenamiento surgió en 1984 el protocolo RARP.
RARP (Reverse Address Resolution Protocol) fue el primer intento de resolver el problema bootstrap y se originó a partir del Protocolo ARP. El protocolo ARP es un protocolo de bajo nivel que en la capa de enlace asocia una dirección IP a un dirección de hardware (MAC). RARP es capaz de proveerle a un dispositivo sin almacenamiento su dirección IP utilizando un intercambio sencillo cliente/servidor de una solicitud y respuesta entre un host y un servidor RARP. Las capacidades de RARP se limitan a esto y no le brindan a un host resto de información que pueda necesitar.
Como solución a las limitaciones del RARP se creó el BOOTP y se estandarizó en el RFC 951, publicado en septiembre de 1985 con las siguientes características:
- Se basa en un intercambio cliente/servidor (al igual que RARP), pero es implementado como protocolo software de una capa más alta usando UDP para el transporte de mensajes. No depende de un tipo particular de hardware como RARP.
- Soporta el envío de información de configuración adicional a la dirección IP del cliente. La información extra usualmente se envía en un solo mensaje por eficiencia.
- Puede tener al cliente y al servidor en diferentes redes de una internetwork. Esto permite la administración del servidor logrando que las direcciones IP estén más centralizadas, ahorrando dinero así como tiempo administrativo e inconveniencias.
RARP (Reverse Address Resolution Protocol) fue el primer intento de resolver el problema bootstrap y se originó a partir del Protocolo ARP. El protocolo ARP es un protocolo de bajo nivel que en la capa de enlace asocia una dirección IP a un dirección de hardware (MAC). RARP es capaz de proveerle a un dispositivo sin almacenamiento su dirección IP utilizando un intercambio sencillo cliente/servidor de una solicitud y respuesta entre un host y un servidor RARP. Las capacidades de RARP se limitan a esto y no le brindan a un host resto de información que pueda necesitar.
Como solución a las limitaciones del RARP se creó el BOOTP y se estandarizó en el RFC 951, publicado en septiembre de 1985 con las siguientes características:
- Se basa en un intercambio cliente/servidor (al igual que RARP), pero es implementado como protocolo software de una capa más alta usando UDP para el transporte de mensajes. No depende de un tipo particular de hardware como RARP.
- Soporta el envío de información de configuración adicional a la dirección IP del cliente. La información extra usualmente se envía en un solo mensaje por eficiencia.
- Puede tener al cliente y al servidor en diferentes redes de una internetwork. Esto permite la administración del servidor logrando que las direcciones IP estén más centralizadas, ahorrando dinero así como tiempo administrativo e inconveniencias.
Protocolo BOOTP
Antes de que se haga efectiva la comunicación de un dispositivo en una red TCP/IP se necesita conocer su dirección IP. Comunmente el host de una red convencional lee esta información de un disco interno, sin embargo en los dispositivos que no tienen almacenamiento no se puede realizar esto. Se necesita otro dispositivo en la red que les otorge la dirección IP y demás información o software que necesiten para volverse hosts con IP activo.
El arranque o proceso de inicio de una computadora es comúnmente llamado bootstrapping, y se ejecuta tras el proceso POST del BIOS. Para brindarle esta capacidad a los hosts (sin almacenamiento) de redes IP se creó el protocolo Bootstrap (BOOTP).
Según se especifica en el RFC 951, el protocolo BOOPT permite que:
una maquina cliente descubra su propia dirección IP, la dirección de un host servidor y el nombre de un archivo a ser cargado a memoria y ejecutado. De esta manera podemos efectuar arranques remotos en redes IP.
El arranque o proceso de inicio de una computadora es comúnmente llamado bootstrapping, y se ejecuta tras el proceso POST del BIOS. Para brindarle esta capacidad a los hosts (sin almacenamiento) de redes IP se creó el protocolo Bootstrap (BOOTP).
Según se especifica en el RFC 951, el protocolo BOOPT permite que:
una maquina cliente descubra su propia dirección IP, la dirección de un host servidor y el nombre de un archivo a ser cargado a memoria y ejecutado. De esta manera podemos efectuar arranques remotos en redes IP.
Suscribirse a:
Entradas (Atom)