DHCP Y BOOTP.

TABLA DE CONTENIDO

1.- DEFINICION DEL PROYECTO 3

1.1 Nombre del proyecto 3

1.2 Objetivo del proyecto 3

1.3 Recursos del proyecto 3

2.- PLANEACION DEL PROYECTO 4

2.1 Diagrama de Gantt 4

3.DISEÑO DE PROYECTO………………………………………………...…5

3.1 Introducción…………………………………………………………...5

3.1.1 Protocolo BOOTP………………………………………….5

3.1.2 Protocolo DHCP……………………………………………8

3.1.2.1 Configuración del servidor DHCP……………..9

3.2 Diagrama de flujo 10

3.3 Comandos utilizados en DHCP……………………………….……12

3.4 Tabla de comparación entre DHCP Y BOOTP…….…………......14

4.- CONSTRUCCION DE CODIGO………………………………………… 15

4.1 Código fuente 15

4.2 Código objeto……………………………………………………… 16

5.- IMPLEMENTACION 19

5.1Manual de usuario…………………………………………………....19

5.2 Operación……………………………………………………………..29

REFERENCIAS.………………………………………………………………..34

1- DEFINICION DEL PROYECTO.

1.1 Nombre del proyecto.

CONFIGURACION Y APLICACIONES DE DHCP Y BOOTP.

1.2 Objetivo:

Mediante este proyecto lograremos conocer y/o entender la configuración y algunas de las aplicaciones que se pueden hacer con los protocolos DHCP y el protocolo BOOTP, cuál es su funcionamiento y lo importantes que son para las redes de hoy en día.

1.3 Recursos del proyecto:

Para formar este proyecto se utilizó:

-windows

-ubuntu

2-PLANEACION DEL PROYECTO.

2.1 Diagrama de Gantt:

Figura 1

3.- DISEÑO DEL PROYECTO.

3.1 Introducción.

3.1.1 Protocolo BOOTP:

Es una alternativa al comando rarp que tiene la ventaja de permitir la configuración de la máscara de subred y de la puerta de acceso. Utilizado por los clientes de red para obtener su dirección IP automáticamente. Originalmente requería el uso de un disquete de arranque para establecer las conexiones de red iniciales, posteriormente comenzó a permitir el arranque directo desde la red.

BOOTP es un protocolo 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.

Existen también actualizaciones de BOOTP que permiten inter operar 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.

Figura 2

Código

Indica petición (1) o respuesta (2)

Tipo HW

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 direcció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

...