stringtranslate.com

Protocolo de arranque

El protocolo Bootstrap ( BOOTP ) es un protocolo de red de computadoras utilizado en redes de protocolo de Internet para asignar automáticamente una dirección IP a dispositivos de red desde un servidor de configuración. El BOOTP se definió originalmente en el RFC  951 publicado en 1985.

Si bien algunas partes de BOOTP han sido reemplazadas efectivamente por el Protocolo de configuración dinámica de host (DHCP), que agrega la característica de arrendamientos, partes de BOOTP se utilizan para brindar servicio al protocolo DHCP. Algunos servidores DHCP también proporcionan la funcionalidad BOOTP heredada.

Cuando se inicia una computadora conectada a la red , su pila de IP transmite mensajes de red BOOTP solicitando una asignación de dirección IP. Un servidor de configuración BOOTP responde a la solicitud asignando una dirección IP de un grupo de direcciones, que está preconfigurado por un administrador.

BOOTP se implementa utilizando el Protocolo de datagramas de usuario (UDP) para el transporte. El servidor utiliza el puerto número 67 para recibir solicitudes de clientes y el cliente utiliza el puerto número 68 para recibir respuestas del servidor. BOOTP opera sólo en redes IPv4 .

Históricamente, BOOTP también se ha utilizado para estaciones de trabajo sin disco tipo Unix para obtener la ubicación de red de su imagen de arranque , además de la asignación de dirección IP. Las empresas lo utilizaron para implementar una instalación de cliente preconfigurado (por ejemplo, Windows ) en las PC recién instaladas.

Inicialmente requerían el uso de un disquete de arranque para establecer la conexión de red inicial, pero los fabricantes de interfaces de red posteriormente incorporaron el protocolo en el firmware de las tarjetas de interfaz, así como en las placas del sistema con interfaces de red integradas, permitiendo así el arranque directo de la red.

Historia

BOOTP se definió por primera vez en septiembre de 1985 [1] como reemplazo del Protocolo de resolución de direcciones inversas (RARP), publicado en junio de 1984. [2] La motivación principal para reemplazar RARP con BOOTP es que RARP era un protocolo de capa de enlace . Esto dificultó la implementación en muchas plataformas de servidores y requirió que hubiera un servidor presente en cada subred IP individual . BOOTP introdujo la innovación de los agentes de retransmisión, que reenviaban paquetes BOOTP desde la red local utilizando enrutamiento IP estándar, de modo que un servidor BOOTP central pudiera servir hosts en muchas subredes. [  dieciséis

Se definió un conjunto cada vez mayor de extensiones de información de proveedores de BOOTP [3] [4] [5] [6] para proporcionar a los clientes BOOTP información relevante sobre la red, como la puerta de enlace predeterminada , la dirección IP del servidor de nombres , el nombre de dominio , etc.

Con la llegada del Protocolo de configuración dinámica de host , las extensiones de información del proveedor de BOOTP se incorporaron como campos de opción de DHCP, [7] [8] para permitir que los servidores DHCP también sirvan a clientes BOOTP.

Operación

Caso 1: Cliente y servidor en la misma red

Cuando se inicia un cliente BOOTP, no tiene dirección IP, por lo que transmite un mensaje que contiene su dirección MAC a la red. Este mensaje se denomina "solicitud BOOTP" y lo recoge el servidor BOOTP, que responde al cliente con la siguiente información que el cliente necesita:

  1. La dirección IP, la máscara de subred y la dirección de puerta de enlace predeterminada del cliente.
  2. La dirección IP y el nombre de host del servidor BOOTP.
  3. La dirección IP del servidor que tiene la imagen de arranque, que el cliente necesita para cargar su sistema operativo.

Cuando el cliente recibe esta información del servidor BOOTP, configura e inicializa su pila de protocolos TCP/IP y luego se conecta al servidor en el que se comparte la imagen de arranque. El cliente carga la imagen de arranque y utiliza esta información para cargar e iniciar su sistema operativo. [9]

El Protocolo de configuración dinámica de host (DHCP) se desarrolló como una extensión de BOOTP. BOOTP se define en las Solicitudes de comentarios (RFC) 951 y 1084.

Caso 2: Cliente y servidor en diferentes redes

  1. El problema con la solicitud de bootp es que la solicitud se transmite. Un datagrama IP de transmisión no puede pasar a través de ningún enrutador. El enrutador descarta este paquete.
  2. Para resolver este problema, se necesita un intermediario (relé).
  3. Uno de los hosts o enrutadores se puede configurar en la capa de aplicación para operar como agente de retransmisión.
  4. El agente de retransmisión conoce la dirección de unidifusión del servidor bootp y escucha los mensajes de difusión en el puerto 67.
  5. Cuando recibe este paquete de difusión, encapsula el mensaje en un datagrama de unidifusión y envía la solicitud al servidor bootp.
  6. El paquete que lleva una dirección de destino de unidifusión es enrutado por cualquier enrutador y llega al servidor bootp.
  7. El agente de retransmisión, después de recibir la respuesta, la envía al cliente bootp.

Documentación de estándares IETF

Ver también

Referencias

  1. ^ ab Bill Croft; John Gilmore (septiembre de 1985). PROTOCOLO BOOTSTRAP (BOOTP). Grupo de Trabajo de Red. doi : 10.17487/RFC0951 . RFC 951. Proyecto de Norma. Actualizado por RFC 1395, 1497, 1532, 1542 y 5494.
  2. ^ R. Finlayson; T. Mann; J. Mogul; M. Theimer (junio de 1984). Un protocolo de resolución de direcciones inversas. Grupo de Trabajo de Red. doi : 10.17487/RFC0903 . ETS 38. RFC 903. Estándar de Internet 38.
  3. ^ P. Prindeville (febrero de 1988). Extensiones de información del proveedor BOOTP. Grupo de Trabajo de Red. doi : 10.17487/RFC1048 . RFC 1048. Obsoleto. Obsoleto por RFC 1084, 1395, 1497 y 1533.
  4. ^ J. Reynolds (diciembre de 1988). Extensiones de información del proveedor BOOTP. Grupo de Trabajo de Red. doi : 10.17487/RFC1084 . RFC 1084. Obsoleto. Obsoleto por RFC 1395, 1497 y 1533. Obsoleto por RFC 1048.
  5. ^ J. Reynolds (enero de 1993). Extensiones de información del proveedor BOOTP. Grupo de Trabajo de Red. doi : 10.17487/RFC1395 . RFC 1395. Obsoleto. Obsoleto por RFC 1497 y 1533. Obsoleto por RFC 1084 y 1048. Actualiza RFC 951.
  6. ^ J. Reynolds (agosto de 1993). Extensiones de información del proveedor BOOTP. Grupo de Trabajo de Red. doi : 10.17487/RFC1497 . RFC 1497. Obsoleto. Obsoleto por RFC 1533. Obsoleto RFC 1395, 1084 y 1048. Actualizaciones RFC 951.
  7. ^ S. Alejandro; R. Droms (octubre de 1993). Opciones de DHCP y extensiones de proveedores BOOTP. Grupo de Trabajo de Red. doi : 10.17487/RFC1533 . RFC 1533. Obsoleto. Obsoleto por RFC 2132. Obsoleto RFC 1497, 1395, 1084 y 1048.
  8. ^ S. Alejandro; R. Droms (marzo de 1997). Opciones de DHCP y extensiones de proveedores BOOTP. Grupo de Trabajo de Red. doi : 10.17487/RFC2132 . RFC 2132. Proyecto de Norma. Obsoletos RFC 1533. Actualizado por RFC 3442, 3942, 4361, 4833 y 5494.
  9. ^ "Protocolo Bootstrap (BOOTP)". Enciclopedia de la red .

enlaces externos