| BOOTP | |
|---|---|
| Nombre | Protocolo de arranque |
| Nivel (según el modelo OSI ) | aplicado |
| Familia | TCP/IP |
| Creado en | 1985 |
| Puerto/ID |
67/ UDP (servidor), 68/UDP (cliente) [1] |
| Propósito del protocolo | obtener configuración de red |
| Especificación | RFC 951 , RFC 1542 |
BOOTP (del inglés bootstrap protocol ) es un protocolo de red de capa de aplicación utilizado para obtener automáticamente una dirección IP por parte del cliente . Esto suele suceder mientras la computadora se está iniciando . BOOTP se define en RFC 951 .
BOOTP, como RARP , permite que un servidor especial determine la dirección IP del cliente a partir de su dirección MAC (por ejemplo, al iniciar un dispositivo que no tiene la capacidad de almacenar su propia dirección IP), y también permite que los clientes aprendan otros parámetros de inicio (por ejemplo, el nombre del programa, descargado a través de TFTP ) y utiliza UDP como protocolo de capa de transporte. Esto le permite usar enrutadores (bootp relay) para enviar solicitudes y respuestas de un segmento LAN a otro. DHCP ( Protocolo de configuración dinámica de host) es un complemento para BOOTP (para compatibilidad con el relé bootp) y permite que el servidor asigne direcciones IP a los clientes de forma dinámica durante un período limitado.
El personal de mantenimiento de esos (?) años enfrentó los desafíos de conectar y mover constantemente nuevos dispositivos, así como la necesidad de cambiar la configuración de la red para cumplir con los requisitos de la red moderna. Todo esto llevó a la necesidad de crear un mecanismo para automatizar la configuración de los nodos de red, los sistemas operativos distribuidos y el software de red. La forma más eficiente de implementar dicho mecanismo puede ser almacenar los ajustes de configuración y las imágenes de software en uno o más servidores de arranque. Durante el inicio, el sistema interactúa con dicho servidor, recibe los parámetros de configuración iniciales y, si es necesario, descarga el software necesario.
BOOTP se introdujo en RFC 951 como reemplazo del obsoleto RARP. BOOTP se desarrolló originalmente para estaciones de trabajo sin disco . Las condiciones modernas han llevado a la necesidad de automatizar el arranque de los sistemas que solo tienen herramientas básicas para IP , UDP y TFTP en ROM. El script de arranque original se veía así:
La solicitud de descarga y la respuesta utilizan el mismo formato de mensaje. En la solicitud, algunos campos tienen valores nulos.
Estructura del paquete BOOTP [2] :
| Desplazamiento de segmento |
Longitud, octeto |
Descripción |
|---|---|---|
| 0 | una | Op Código de operación |
| una | una | Tipo H Tipo de equipo |
| 2 | una | HLen Longitud de dirección de hardware |
| 3 | una | Lúpulos Número de saltos |
| cuatro | cuatro | ID de transacción XID |
| ocho | 2 | Secs Contador de segundos desde que el cliente envió la primera solicitud |
| diez | 2 | No se usa en RFC 951 Banderas - Campo de banderas en RFC 1542 |
| 12 | cuatro | Dirección IP del cliente CIAddr |
| dieciséis | cuatro | YIAddr La dirección IP proporcionada al cliente por el servidor |
| veinte | cuatro | Dirección IP del servidor SIAddr |
| 24 | cuatro | GIAddr Dirección IP del enrutador intermedio |
| 28 | dieciséis | CHAddr Dirección de hardware del cliente |
| 44 | 64 | Nombre de host del servidor SName |
| 108 | 128 | Nombre de archivo del archivo de arranque |
| 236 | 64 | Área de Vend Developer y Opciones Avanzadas |
Consideremos todos los parámetros con más detalle.
El código de operación indica el tipo de mensaje:
Especifica el tipo de hardware de red que se está utilizando, utilizando valores similares al campo Tipo de hardware ( HType , HRD ) en la especificación del protocolo ARP [3] [4] .
Algunos valores de uso común:
| tipo h | Descripción |
|---|---|
| una | Ethernet (10Mb) |
| 6 | Redes IEEE 802 |
| 7 | ARCNET |
| quince | Retardo de fotograma |
| dieciséis | Modo de transferencia asincrónica (ATM) |
| Dieciocho | canal de fibra |
| veinte | línea serial |
Especifica la longitud de la dirección de hardware en el mensaje. Para redes Ethernet y otras que utilicen IEEE 802 , el valor de este parámetro es 6.
Un campo similar en el paquete ARP es HLN.
Los relés utilizan este segmento para controlar el reenvío de mensajes. El valor del campo se establece en 0 antes de enviarse y se incrementa en 1 a medida que pasa por cada relé.
El ID de transacción es un número entero de 32 bits que establece el cliente y lo devuelve el servidor. Permite al cliente hacer coincidir la respuesta con la solicitud. El cliente establece este campo en un número aleatorio para cada solicitud.
Cuando el cliente envía la primera solicitud de descarga, el campo del contador de segundos se establece en cero. Si la solicitud no recibe respuesta, después de que expira el tiempo de espera, el cliente envía la solicitud nuevamente, cambiando el valor en el campo del contador de segundos. Para el tiempo de espera, el cliente utiliza un intervalo aleatorio, aumentando hasta un valor de 60 segundos.
Este campo no tiene un propósito especial. Su contenido puede ser verificado por el servidor o el monitor de red para determinar cuánto tiempo espera el cliente para una descarga de red. El servidor PUEDE usar los valores en el campo del contador de segundos para priorizar las solicitudes, pero este campo actualmente se ignora en la mayoría de las implementaciones.
En el RFC 951 original , este campo de dos bytes se dejó en blanco. De acuerdo con RFC 1542 , se utiliza para establecer banderas [5] .
| Nombre de la bandera | tamaño, poco | Descripción |
|---|---|---|
| B | una | Difusión: al enviar el mensaje original, el cliente no conoce su propia dirección IP y este indicador se establece en "1". Este estado indica a los servidores y relés BOOTP que recibieron el paquete que se debe transmitir la solicitud de este cliente . |
| Reservado | quince | Reservado y no utilizado, valores establecidos en 0. |
Si el cliente ya conoce su dirección IP, completa el campo de dirección IP del cliente. De lo contrario, el cliente establece este valor en 0. En este último caso, el servidor inserta su dirección IP en el campo con la dirección IP del cliente. El servidor completa el campo de la dirección IP del servidor. Si se utiliza un servidor autorizado, completa la dirección IP de la puerta de enlace.
El cliente debe establecer su dirección de hardware de cliente. Este es el mismo valor que se encuentra en el encabezado de Ethernet y en el campo UDP del datagrama, lo que lo hace disponible para cualquier proceso de usuario (como un servidor BOOTP) que haya recibido el datagrama. Por lo general, es difícil o casi imposible para un proceso que maneja datagramas UDP determinar el valor en el campo de encabezado de Ethernet del datagrama en el que se transporta el datagrama UDP.
El nombre de host del servidor es una cadena que completa el servidor (opcional).
El servidor también puede completar el campo de nombre de archivo de inicio. Este campo contiene la ruta completa al archivo que se usa al cargar.
Originalmente, el área específica del proveedor se usaba en los mensajes para enviar información específica de la implementación. Sin embargo, al comienzo de BOOTP, esta área permaneció libre, aunque una gran cantidad de información (por ejemplo, la máscara de subred o la dirección del enrutador predeterminado) no se incluyó formalmente en los mensajes. El área de desarrolladores sirvió como un lugar para opciones de configuración adicionales, así como información específica para desarrolladores. Hay bastantes campos diferentes definidos en esta área.
BOOTP tiene dos puertos conocidos: 67 para el servidor y 68 para el cliente. Esto significa que el cliente no elige un puerto asignado dinámicamente sin usar, sino que usa el número de puerto 68. La razón por la que se eligieron dos números de puerto en lugar de usar solo uno para el servidor es que el servidor puede enviar una respuesta (aunque generalmente no lo hace). ) de forma retransmitida.
Si la respuesta del servidor se transmitiera y el cliente necesitara seleccionar un número de puerto asignado dinámicamente, esas transmisiones también serían recibidas por otras aplicaciones en otros hosts que usan el mismo número de puerto asignado dinámicamente. Por lo tanto, podemos concluir que enviar una solicitud de transmisión a un número de puerto aleatorio (asignado dinámicamente) no es racional.
Si el cliente utiliza el puerto conocido del servidor (67), todos los servidores de la red se verán obligados a escuchar cada respuesta de difusión. (Si todos los servidores estuvieran 'despertados', tendrían que verificar el código de operación, determinar que era una respuesta y no una solicitud, y 'dormir' nuevamente). Entonces, se tomó la decisión de cómo se hace ahora, es decir, el cliente tiene es el único puerto conocido que es diferente del puerto conocido del servidor.
Si varios clientes están descargando al mismo tiempo, y si las respuestas del servidor se propagan mediante solicitudes de difusión, cada cliente busca las respuestas destinadas a otros clientes. Los clientes usan el campo de ID de transacción en el encabezado BOOTP para hacer coincidir la respuesta con la solicitud, o los servidores miran la dirección de hardware del cliente devuelta.
| Protocolos TCP /IP básicos por capas del modelo OSI | |
|---|---|
| Físico | |
| canalizado | |
| la red | |
| Transporte | |
| sesión | |
| Representación | |
| Aplicado | |
| Otro aplicado | |
| Lista de puertos TCP y UDP | |