stringtranslate.com

Protocolo Bootstrap

El protocolo Bootstrap ( BOOTP ) es un protocolo de red informática 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 la RFC  951 publicada en 1985.

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

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

BOOTP se implementa mediante el protocolo de datagramas de usuario (UDP) para el transporte. El servidor utiliza el puerto número 67 para recibir solicitudes del cliente y el cliente utiliza el puerto número 68 para recibir respuestas del servidor. BOOTP funciona únicamente en redes IPv4 .

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

Inicialmente, se requería el uso de un disquete de arranque para establecer la conexión de red inicial; luego, los fabricantes de interfaces de red incorporaron el protocolo en el firmware de las tarjetas de interfaz, así como en las placas del sistema con interfaces de red integradas, lo que permitió el arranque directo de la red.

Historia

El 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 principal motivación para reemplazar RARP por BOOTP es que RARP era un protocolo de capa de enlace . Esto dificultaba la implementación en muchas plataformas de servidor y requería 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 el enrutamiento IP estándar, de modo que un servidor BOOTP central pudiera servir a hosts en muchas subredes. [1] : §6 

Se definió un conjunto cada vez mayor de extensiones de información de proveedores 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étera.

Con la llegada del Protocolo de configuración dinámica de host , las extensiones de información del proveedor BOOTP se incorporaron como campos de opción DHCP, [7] [8] para permitir que los servidores DHCP también presten servicio 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 del cliente, la máscara de subred y la dirección de puerta de enlace predeterminada.
  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 redes diferentes

  1. El problema con la solicitud bootp es que la solicitud se transmite. Un datagrama IP transmitido no puede pasar por ningún enrutador. El enrutador descarta este paquete.
  2. Para solucionar este problema se necesita un intermediario (relé).
  3. Se puede configurar uno de los host o enrutadores en la capa de aplicación para que funcione como agente de retransmisión.
  4. El agente de retransmisión conoce la dirección de unidifusión del servidor bootp y escucha el mensaje 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 una solicitud al servidor bootp.
  6. El paquete que lleva una dirección de destino unicast 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

Véase también

Referencias

  1. ^ por Bill Croft; John Gilmore (septiembre de 1985). PROTOCOLO BOOTSTRAP (BOOTP). Grupo de trabajo de redes. 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 inversa. Grupo de trabajo de redes. doi : 10.17487/RFC0903 . STD 38. RFC 903. Estándar de Internet 38.
  3. ^ P. Prindeville (febrero de 1988). Extensiones de información de proveedores BOOTP. Grupo de trabajo de redes. doi : 10.17487/RFC1048 . RFC 1048. Obsoleto. Quedó obsoleto según RFC 1084, 1395, 1497 y 1533.
  4. ^ J. Reynolds (diciembre de 1988). Extensiones de información de proveedores BOOTP. Grupo de trabajo de redes. doi : 10.17487/RFC1084 . RFC 1084. Obsoleto. Quedó obsoleto por RFC 1395, 1497 y 1533. Queda obsoleto RFC 1048.
  5. ^ J. Reynolds (enero de 1993). Extensiones de información de proveedores BOOTP. Grupo de trabajo de redes. doi : 10.17487/RFC1395 . RFC 1395. Obsoleto. Quedó obsoleto por las RFC 1497 y 1533. Quedan obsoletos las RFC 1084 y 1048. Actualiza la RFC 951.
  6. ^ J. Reynolds (agosto de 1993). Extensiones de información de proveedores BOOTP. Grupo de trabajo de redes. doi : 10.17487/RFC1497 . RFC 1497. Obsoleto. Queda obsoleto por RFC 1533. Quedan obsoletos RFC 1395, 1084 y 1048. Actualiza RFC 951.
  7. ^ S. Alexander; R. Droms (octubre de 1993). Opciones de DHCP y extensiones de proveedores de BOOTP. Grupo de trabajo de redes. doi : 10.17487/RFC1533 . RFC 1533. Obsoleto. Quedó obsoleto por RFC 2132. Quedan obsoletos RFC 1497, 1395, 1084 y 1048.
  8. ^ S. Alexander; R. Droms (marzo de 1997). Opciones de DHCP y extensiones de proveedores BOOTP. Grupo de trabajo de redes. doi : 10.17487/RFC2132 . RFC 2132. Borrador de norma. Obsoleto RFC 1533. Actualizado por RFC 3442, 3942, 4361, 4833 y 5494.
  9. ^ "Protocolo Bootstrap (BOOTP)". Enciclopedia de la red .

Enlaces externos