BOOTP es un pretocolo estándar borrador. Su estado es recomendado. Las especificaciones de BOOTP se pueden encontrar en el RFC 951 - Protocolo Bootstrap y en el RFC 1497 - Extensiones de Información del Fabricante BOOTP.
Exiten también actualizaciones de BOOTP que permiten interoperar con DHCP. Éstas se describen en el RFC 1542 - Aclaraciones y Extensiones para el Protocolo Bootstrap que actualiza el RFC 951 y el RFC 1533 - DHCP Options and BOOTP Vendor Extensions, que dejan obsoleto el RFC 1497. Estas actualizaciones de BOOTP son estándares propuestos con un estado de electivo.
Las LANs hacen posible el uso de hosts sin disco como estaciones de trabajo, routers, concentradores de terminal, etc. Los hosts sin disco requieren un mecanismo para arrancar remotamente sobre una red. El protocolo BOOTP se usa para arranque remoto sobre redes IP. Permite una pila de protocolo IP mínima sin información de configuración, típicamente almacenada en ROM, para obtener suficiente información para comenzar el proceso de descarga del código necesario para arrancar. BOOTP no define cómo se realiza la descarga, ya que este proceso típicamente usa TFTP como se describe en el RFC 906 - Cargar Bootstrap usando TFTP.
El proceso BOOTP involucra los siguientes pasos:
- El cliente determine su propia dirección hardware; esta dirección está normalmente en una ROM en el hardware.
- Un cliente BOOTP envía su dirección hardware en un datagrama UDP al servidor. El contenido completo de este datagrama se muestra en la figura - Formato del mensaje BOOTP. Si el cliente sabe su dirección IP y/o la dirección del servidor, debería usarlos, pero en general los clientes BOOTP no tienen datos de configuration IP del todo. Si el cliente no sabe su propia dirección IP, usa 0.0.0.0. Si el cliente no sabe la dirección IP del servidor, usa la dirección broadcast limitada (255.255.255.255). El número de puerto UDP es el 67.
- El servidor recibe el datagrama y busca la dirección hardware del cliente en su fichero de configuración, que contiene la dirección IP del cliente. El servidor rellena los campos restantes en el datagrama UDP y lo devuelve al cliente usando el puerto UDP 68. Se puede usar uno de estos tres métodos para hacer esto:
- Si el cliente supiera su propia dirección IP (se incluyó en la petición BOOTP), entonces el servidor devuelve el datagrama directamente a esta dirección. Es probable que la caché ARP en la pila de protocolo del servidor no sepa la dirección hardware que empareja la dirección IP. ARP se utilizará para determinarlo como normal.
- Si el cliente no sabía su propia dirección IP (0.0.0.0 en la petición BOOTP), entonces el servidor debe concern itself con su propia caché ARP. No se puede usar ARP en el servidor para encontrar la dirección hardware del cliente porque el cliente no sabe su dirección IP y por tanto no puede responder a una petición ARP. Esto se llama el problema "del huevo y la gallina". Existen dos soluciones posibles:
- Si el servidor tiene un mecanismo para actualizar directamente su propia caché ARP sin usar ARP, lo hace de esta manera y envía el datagrama directamente.
- Si el servidor no puede actualizar su propia caché ARP, debe enviar una respuesta broadcast.
- Cuando recibe la respuesta, el cliente BOOTP grabará su propia dirección IP (permitiendo que responda a las peticiones ARP) y comenzará el proceso de bootstrap.
- código
- Indica petición (1) o respuesta (2)
- TipoHW
- El tipo de hardware, por ejemplo: Ethernet (1) o redes IEEE 802 (6). Referirse a STD 2 - Números Asignados de Internet para una lista completa.
- longitud
- Longitud de la dirección Hardware en bytes. Ethernet y token-ring usan 6, por ejemplo.
- saltos
- El cliente lo pone a 0. Lo incrementa el router que transmite la petición a otro servidor y se usa para identificar bucles. El RFC 951 sugiere que un valor de 3 indica un bucle.
- ID de transacción
- Se utiliza un número aleatorio para emparejar esta petición de arranque con la respuesta generada.
- segundos
- Lo fija el cliente. Es el tiempo transcurrido en segundos desde que el cliente comenzó su proceso de arranque.
- campo flags
- El bit más significativo del campo flags se usa como flag de broadcast. El resto de los bits debe ponerse a cero, y están reservados para uso futuro. Normalmente, los servidores BOOTP intentan transportar mensajes BOOTREPLY directamente a un cliente usando transporte unicast. La dirección de destino en la cabecera IP se pone a tu drección IP BOOTP y la dirección MAC se pone a la dirección hardware del cliente DHCP. Si un host es incapaz de recibir un datagram IP unicast hasta que sepa su dirección IP, entonces este bit de broadcast se debe activar para indicar al servidor que la respuesta BOOTREPLY se debe enviar como un broadcast IP y MAC. En otro caso, este bit se debe poner a cero.
- dirección IP del cliente
- Lo fija el cliente. Es una dirección IP conocida ó 0.0.0.0.
- tu dirección IP
- Lo fija el servidor si el campo de la dirección IP del cliente era 0.0.0.0.
- dirección IP del servidor
- Lo fija el servidor.
- dirección IP del router
- Lo fija el router expedidor si se está usando BOOTP forwarding.
- dirección hardware del cliente
- Lo fija el cliente y lo usa el servidor para identificar el cliente registrado que está arrancando.
- nombre del host servidor
- Nombre del host servidor opcional terminado en X'00'.
- nombre del fichero de arranque
- El cliente lo deja nulo o especifica un nombre genérico, como el "router" indicando el tipo de fichero de arranque a utilizar. El servidor devuelve un nombre de fichero completamente cualificado de un fichero de arranque adecuado para el cliente. El valor termina en X'00'.
- área específica del fabricante
- Área específica del fabricante opcional. Se recomienda que los clientes rellenen siempre los cuatro primeros bytes con un "cookie mágico". Si un "cookie mágico" específico del fabricante no se usa el cliente debería usar 99.130.83.99 seguido de una etiqueta de terminación (255) y poner los bytes restantes a cero. Ver el RFC 1533 para más detalles.
Una restricción de este esquema es el uso de direcciones broadcast limitadas para peticiones BOOTP; esto requiere que el servidor esté en la misma subred que el receptor. BOOTP forwarding es un mecanismo para routers para enviar peticiones BOOTP. Es una opción de configuración disponible en algunos routers. Ver el RFC 951 para mayor información sobre BOOTP forwarding.
Una vez que el cliente BOOTP ha procesado la respuesta, puede seguir adelante con la transferencia del fichero de arranque y ejecutar el proceso de arranque completo. Ver el RFC 906 para la especificación de cómo se hace esto con TFTP. El proceso completo de arranque reemplazará la pila de protocolo IP mínima que usa BOOTP y TFTP por una pila de protocolo IP normal transferida como parte del fichero de arranque y que contiene la personalización correcta para el cliente.
Implementación
DOS
TCP/IP para DOS proporciona la función de cliente BOOTP. La orden BOOTP inicia esta función de cliente que puede ser muy útil estableciendo conexiones SLIP (dado que BOOTP se puede usar para asignar tu dirección IP, no se necesita saber la dirección IP antes de que se haga la conexión).