El protocolo BOOTP se utiliza para arranque remoto sobre redes IP. Permite a las máquinas cliente inicializarse con un stack IP mínimo y solicitar su dirección IP, dirección del Gateway y dirección del servidor de nombres a un servidor BOOTP. BOOTP no define como obtener el código de arranque necesario, pero se suele utilizar TFTP. Aunque BOOTP es ampliamente utilizado para el arranque de máquinas sin información IP, también es utilizado únicamente para proporcionar configuraciones a un cliente que no ha sido manualmente configurado.
Los pasos del proceso BOOTP son los siguientes:
1-. El cliente determina su propia dirección hardware. Esta se encuentra normalmente en una ROM del hardware.
2-. El cliente BOOTP envía al servidor su dirección física en un datagrama UDP (puerto 67 bootps). Si el cliente conoce su dirección IP o la dirección IP del servidor debería utilizarlas, pero en general los clientes BOOTP no tienen aún datos de configuración IP. Si el cliente no conoce su propia IP utilizará la dirección 0.0.0.0. Si el cliente no conoce la dirección IP del servidor utilizará la dirección de broadcast 255.255.255.255.
3-. El servidor BOOTP recibe el datagrama y busca la dirección hardware del cliente en su fichero de configuración, el cual contiene la dirección IP del cliente. El servidor rellena los campos correspondientes y devuelve el datagrama UDP al cliente por el puerto 68 (bootpc). Para hacer esto utilizará uno de estos tres métodos:
- Si el cliente conoce su propia dirección IP (estaba incluida en la solicitud BOOTP), el servidor devuelve el datagrama directamente a esta dirección.
- Si el cliente no conoce su propia dirección (0.0.0.0 en la solicitud BOOTP), el servidor debe basarse en su propia caché ARP.
- Si no se puede utilizar ARP en el servidor para encontrar la dirección hardware del cliente debido a que el cliente no conoce su dirección IP y por lo tanto no puede responder a la solicitud ARP, tenemos dos posibles soluciones:
- Si el servidor tiene un mecanismo para actualizar su propia caché ARP sin utilizar el propio ARP, lo hace y entonces envía el datagrama directamente.
- Si el servidor no puede actualizar su caché ARP debe enviar un broadcast
4-. Cuando recibe la respuesta, el cliente BOOTP guarda su propia dirección IP (permitiéndole contestar a las solicitudes ARP) y empieza el proceso de arranque.
· Código de operación. Indica solicitud (1) o respuesta (2)
· Tipo de hardware. Indica el tipo de hardware. Por ejemplo 1 indica Ethernet.
· Longitud. Indica la longitud en bytes de la dirección física.
· Saltos. Inicializado a 0 por el cliente es incrementado por cada router que reenvía el mensaje. Se utiliza para identificar bucles. Un valor de 3 indicaría un bucle (RFC 951)
· Identificador de transacción. Número aleatorio que marca el cliente y que se utiliza tanto por el cliente como por el servidor para asociar los mensajes de intercambio entre ellos.
· Tiempo. Establecido por el cliente. Indica, en segundos, el tiempo transcurrido desde que el inicio su secuencia de arranque.
· Indicador. El bit más significativo de este campo se utiliza como indicador de broadcast (1). Indica al servidor que la respuesta BOOTREPLY se debe enviar como broadcast dado que el cliente no recibe datagramas IP unicast. El resto de bits van a 0.
· Dirección IP del cliente. Establecido por el cliente, indica su dirección IP, en caso de que la conozca, o 0.0.0.0.
· Dirección IP del servidor. Establecido por el servidor, indica su dirección IP.
· Dirección IP del router. Indica la dirección de un relay de BOOTP (quien lo fija) para que el servidor devuelva la contestación.
· Dirección hardware del cliente. Establecido por el cliente, indica su dirección física. Se utiliza para que el servidor lo identifique.
· Nombre del servidor. Campo opcional. Indica el nombre del servidor de BOOTP.
· Nombre del archivo de arranque. Campo opcional. El cliente lo deja en blanco o especifica un nombre genérico. El servidor devuelve un nombre de fichero válido para el cliente.
· Opciones. Es un campo opcional para opciones específicas de fabricante. Descritas en la RFC 2132. El cliente siempre fijará los 4 primeros bytes con una ‘magic cookie’. En caso de no utilizar ‘magic cookies’ específicas de fabricante estos 4 bytes tendrán los valores: 99, 130, 83, 99.
No hay comentarios:
Publicar un comentario
Nota: solo los miembros de este blog pueden publicar comentarios.