Secuencia DORA del protocolo ARP analizado con wireshark

Practica Análisis del Protocolo de Configuración de
Host Dinámico – DHCP - con Wireshark
1 Marco de Referencia
Antes de proceder con la explicación del desarrollo del protocolo, realizo una consulta para desglosar con exactitud
y precisión la forma como el protocolo DHCP opera sobre la pila de protocolos TCP/IP.
Figura No. 1 Modelo de Capas OSI

Propósito de las capas:
Figura No. 2 Propósito por capa
Protocolos TCP/IP por cada capa OSI:
7. Aplicación: DHCP, DNS, FTP, HTTP, IMAP4, NNTP, POP3, SMTP, SNMP, SSH, TELNET and NTPmore)
6. Presentación: SSL, WEP, WPA, Kerberos,
5. Sesión: Logical Ports 21, 22, 23, 80 etc…
4. Transporte: TCP, SPX, UDP
3. Red: IPv4, IPV6, IPX, OSPF, ICMP, IGMP, ARP
2. Enlace: 802.11 (WLAN), Wi-Fi, WiMAX, ATM, Ethernet, Token Ring, Frame Relay, PPTP, L2TP and ISDN
1. Física:Hubs, Repeaters, Cables, Optical Fiber, Coaxial Cable, Twisted Pair Cable and Connectors

Dynamic Host Configuration Protocol (DHCP):
Historia:
DHCP es un protocolo basado en BOOTP, más avanzado, pero más difícil de implementar. Muchos servidores DHCP
también ofrecen soporte BOOTP.
Bootstrap Protocol - BOOTP
BOOTP son las siglas de Bootstrap Protocol. Es un protocolo de red UDP utilizado por los clientes de red para obtener
su dirección IP automáticamente. Normalmente se realiza en el proceso de arranque de los ordenadores o del sistema
operativo. Originalmente está definido en el RFC 951.
Este protocolo permite a los ordenadores sin disco obtener una dirección IP antes de cargar un sistema operativo
avanzado. Históricamente ha sido utilizado por las estaciones de trabajo sin disco basadas en UNIX (las cuales también
obtenían la localización de su imagen de arranque mediante este protocolo) y también por empresas para introducir una
instalación preconfigurada de Windows en PC recién comprados (típicamente en un entorno de red Windows NT).
Originalmente requería el uso de un disquete de arranque para establecer las conexiones de red iniciales, pero el
protocolo se integró en la BIOS de algunas tarjetas de red (como la 3c905c) y en muchas placas base modernas para
permitir el arranque directo desde la red.
El proceso BOOTP involucra los siguientes pasos:
1. El cliente determina su propia dirección de hardware; esta dirección está normalmente en una ROM en el
hardware.
2. Un cliente BOOTP envía su dirección hardware en un datagrama UDP al servidor. 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 configuración 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 - Puerto Servidor -.
3. 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 - Puerto Cliente -.
4. 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 bootstrapping.
User Datagram Protocol (UDP)
Es un protocolo mínimo de nivel de transporte orientado a mensajes documentado en el RFC 768de la IETF.
En la familia de protocolos de Internet UDP proporciona una sencilla interfaz entre la capa de red y la capa de aplicación.
UDP no otorga garantías para la entrega de sus mensajes (por lo que realmente no se debería encontrar en la capa 4) y el
origen UDP no retiene estados de los mensajes UDP que han sido enviados a la red. UDP sólo
añade multiplexado de aplicación y suma de verificación de la cabecera y la carga útil. Cualquier tipo de garantías para la
transmisión de la información deben ser implementadas en capas superiores.
La cabecera UDP consta de 4 campos de los cuales 2 son opcionales (con fondo rojo en la tabla). Los campos de los puertos
fuente y destino son campos de 16 bits que identifican el proceso de origen y recepción. Ya que UDP carece de un servidor
de estado y el origen UDP no solicita respuestas, el puerto origen es opcional. En caso de no ser utilizado, el puerto origen
debe ser puesto a cero. A los campos del puerto destino le sigue un campo obligatorio que indica el tamaño
en bytes del datagrama UDP incluidos los datos. El valor mínimo es de 8 bytes. El campo de la cabecera restante es una
suma de comprobación de 16 bits que abarca una pseudo-cabecera IP (con las IP origen y destino, el protocolo y la longitud
del paquete UDP), la cabecera UDP, los datos y 0’s hasta completar un múltiplo de 16. El checksum también es opcional en

IPv4, aunque generalmente se utiliza en la práctica (en IPv6 su uso es obligatorio). A continuación se muestra los campos
para el cálculo del checksum en IPv4, marcada en rojo la pseudo-cabecera IP.
Tabla No. 2 Datagrama UDP Detallado
bits 0 – 7 8 – 15 16 – 23 24 – 31
0 Dirección Origen
32 Dirección Destino
64 Ceros Protocolo Longitud UDP
96 Puerto Origen Puerto Destino
128 Longitud del Mensaje Suma de verificación
160 Datos
El protocolo UDP se utiliza por ejemplo cuando se necesita transmitir voz o vídeo y resulta más importante transmitir con
velocidad que garantizar el hecho de que lleguen absolutamente todos los bytes.
El formato del mensaje DHCP es el siguiente:
0 8 16 24 32
op htype hlen hops
xid
secs flags
Ciaddr(Client IP Address)
(4 bytes)
Yiaddr(Your IP Address)
(4 bytes)
Siaddr(Server IP Address)
(4 bytes)
Giaddr(Gateway IP Address switched by relay)
(4 bytes)
chaddr (Client Hardware Address)
(16 bytes)
sname
(64 bytes)
file
(128 bytes)
options
(variable)
.

Campo Tamaño
en bytes
Descripción
op 1 Mensaje de código de operación
1 = Bootrequest
2 = Bootreply
htype 1 Tipo de la dirección hardware. Según RFC1010, Address Resolution Protocol,
sección: Assigned Numbers
1 : Ethernet (10Mb)
2 : Experimental Ethernet (3Mb)
3 : Amateur Radio AX.25
4 : Proteon ProNET Token Ring
5 : Chaos
6 : IEEE 802 Networks
7 : ARCNET
hlen 1 Longitud en bytes de la dirección hardware. Por ejemplo, Ethernet y las redes
en anillo usan 6.
hops 1 El cliente lo pone a cero. Cada router que retransmite la solicitud a otro
servidor la incrementa, con el fin de detectar bucles. El RFC sugiere que un
valor de 3 indica un bucle.
xid 4 Transaction ID, número aleatorio elegido por el cliente, usado por el cliente y
por el servidor para asociar mensajes y respuestas entre un cliente y el servidor.
secs 2 Fijado por el cliente. Es el tiempo transcurrido en segundos desde que el
cliente comenzó de arranque o de reanudación.
flags 2 El bit más a la izquierda de este campo se usa como flag de broadcast. Todos
los demás bits deben de estar a cero ya que están reservados para usos
futuros. Normalmente, los servidores DHCP tratan de entregar los mensajes
DHCPREPLY directamente al cliente usando unicast. La dirección de destino
en la cabecera IP se pone al valor de la dirección IP fijada por el servidor
DHCP, y la dirección MAC a ladirección hardware del cliente DHCP. Si un
host no puede recibir un datagrama IP en unicast hasta saber su propia
dirección IP, el bit de broadcast se debe poner a 1 para indicar al servidor que
el mensaje DHCPREPLY se debe enviar como un broadcast en IP y MAC. De
otro modo, este bit debe ponerse a cero.
ciaddr 4 Dirección IP del cliente, fijada por el cliente. O bien es su dirección IP real, o
0.0.0.0
yiaddr 4 Dirección IP del cliente, fijada por el servidor si el valor del campo anterior es
0.0.0.0
siaddr 4 Dirección IP del servidor próximo para usar en el proceso de configuración.
giaddr 4 Dirección del agente de retransmisión.
chaddr 16 Dirección del hardware del cliente y usada por el servidor para identificar cual
de los clientes registrados está arrancando.
sname 64 Nombre opcional del servidor más próximo al cliente para usar en el proceso
de configuración acabado en X’00’.
file 128 Nombre del fichero de arranque, o se deja vació o se especifica un nombre
genérico, como “router” indicando el tipo de fichero de arranque a usar. En la

solicitud de DHCPDISCOVER se pone al valor nulo. El servidor devuelve el
la ruta de acceso completa del fichero en una respuesta DHCPOFFER. El valor
termina en X’00’.
options Los primeros cuatro bytes del campo de opciones del mensaje DHCP
contienen el cookie(99.130.83.99). El resto del campo de opciones consiste en
parámetros marcados llamados opciones.
Tipos de mensaje DHCP
Tipo de
mensaje
Enviado por Uso del mensaje
DHCPDiscover Cliente
Localiza los servidores DHCP y requiere los parámetros de
configuración
DHCPOffer Servidor
Responde a un mensaje DHCPDiscover y ofrece suministrar
parámetros de configuración
DHCPRequest Cliente
Hace una de las tres opciones siguientes:
a) Requiere una dirección especifica de red y los parámetros de
configuración ofrecidos por un servidor DHCP e implícitamente
declina la oferta de los otros.
b) Confirma la corrección de la dirección de red asignada
previamente después de que por ejemplo, se reinicializó el sistema.
c) Prorrogar el arrendamiento de una dirección de red particular.
DHCPAck Servidor Reconocimiento del éxito del mensaje DHCPRequest
DHCPNak Servidor
Reconocimiento negativo p.e. el cliente se ha movido a una nueva
red o el periodo de arrendamiento ha acabado.
DHCPDecline Cliente
Declina los parámetros ofrecidos, por ejemplo el cliente detecta que
la dirección asignada ya está en uso.
DHCPRelease Cliente
El cliente devuelve la dirección asignada al servidor.
DHCPInform Cliente El cliente tiene dirección y reclama otros parámetros.
Asignando un nueva dirección de red
Figura No. 3Modelo de DHCP a través del enrutador

Esta sección describe la interacción del cliente servidor cuando el cliente desktopno conoce su dirección de red. Se asume
que existen varios servidores DHCP,dhcpserve, los cuales tienen bloques de direcciones de red con los que pueden
satisfacer peticiones de nuevas direcciones. Cada servidor mantiene además una base de datos local y permanente de las
direcciones asignadas y de los arrendamientos.
1. El cliente hace un broadcast de un mensaje DHCPDISCOVER en su subred física y se entrega a todos los
servidores DHCP. El mensaje DHCPDISCOVER puede incluir algunas opciones como sugerencias de la dirección
de red, duración del arrendamiento, etc.
2. Cada servidor puede responder con un mensaje DHCPOFFER, identificándose así mismo como un servidor DHCP
e incluyendo una dirección de red disponible y otras opciones de configuración. Por ejemplo, con referencia a la
Figura 2, puede seleccionar la dirección 192.68.11.25, adecuada a la red 192.68.11.0 a la cual está conectada el
cliente desktop.
3. El cliente recibe uno o más mensaje DHCPOFFER de uno o más servidores. Elige uno basándose en los
parámetros de configuración ofertados y hace un broadcast de un mensaje DHCPREQUEST que incluye la opción
identificadora del servidor para indicar qué mensaje ha seleccionado.
4. Los servidores reciben el broadcast de DHCPREQUEST del cliente. Los servidores no seleccionados utilizan el
mensaje como notificación e que el cliente ha declinado su oferta. El servidor seleccionado vincula al cliente al
almacenamiento persistente y responde con un mensaje DHCPACK que contiene los parámetros de configuración
para el cliente. La combinación de las direcciones hardware y asignada del cliente constituyen un identificador
único de su arrendamiento y las usan tanto el cliente como el servidor para identificar cualquier arrendamiento al
que se haga referencia en un mensaje DHCP. El campo “your IP address” en los mensaje DHCPACK se rellena
con la dirección de red seleccionada.
5. El cliente recibe el mensaje DHCPACK con parámetro de configuración. Realiza un chequeo final de estos
parámetros, por ejemplo con ARP para la dirección de red asignada, y registra la duración del arrendamiento y el
cookie de identificación de éste especificado en el mensaje DHCPACK. En este punto, el cliente está configurado.
Si el cliente detecta un problema con los parámetros en el mensaje DHCPACK, envía un mensaje DHCPDECLINE
al servidor y reinicia el proceso de configuración. El cliente debería esperar un mínimo de diez segundos antes de
reiniciar este proceso para evitar un exceso de tráfico en la red en caso de que se produzca algún bucle.
Si el cliente recibe un mensaje, reinicia el proceso de configuración.
6. Puede elegir renunciar a su arrendamiento enviando un mensaje DHCPRELEASE al servidor. El cliente especifica
el arrendamiento al que renuncia incluyendo sus direcciones hardware y de red.
La figura siguiente muestra el intercambio de mensajes entre el cliente y dos servidores, uno el seleccionado y otro
no.

Figura No. 4Funcionamiento DHCP
Reutilizando una dirección de red previamente asignada
Si el cliente recuerda y desea usar una dirección de red previamente asignada se llevan a cabo los siguientes pasos:
1. El cliente hace un broadcast de un mensaje DHCPREQUEST en su subred. Este mensaje incluye la dirección de
red del cliente en la opción “requested IP adress”.
2. Los servidores que conozcan los parámetros de configuración del cliente le responden con un mensaje DHCPACK.
3. El cliente recibe el mensaje DHCPACK con parámetros de configuración. Efectúa un último chequeo de estos y
registra la duración del arrendamiento y el cookie de identificación de este, especificado en el DHCPACK. El
arrendamiento especifico se identifica implícitamente por el “identificador del cliente” o “chaddr”. En este punto,
el cliente está configurado.
Si el cliente detecta algún problema con los parámetros en el DHCPACK, por ejemplo que la dirección IP está en uso,
envía un mensaje DHCPDECLINE al servidor y reinicia el proceso de configuración solicitando una nueva dirección de
red. Si el cliente recibe un mensaje DHCPNAK, no puede reutilizar la dirección que solicitó. En vez de eso debe pedir
una nueva dirección reiniciando el proceso de configuración descrito en Asignando una nueva dirección de red. El
cliente puede elegir renunciar a su arrendamiento de la dirección de red al enviar un mensaje DHCPRELEASE al
servidor. Identifica el arrendamiento al que renuncia con el cookie de identificación.
La figura siguiente muestra el intercambio de mensajes:

Figura No. 5Funcionamiento DHCP con reutilización

2 Proceso Realizado a través de una interfaz de Ubuntu y Wireshark:
2.1 El primer paso para el desarrollo del taller fue abrir una terminal de linux y observar el comportamiento de la
tarjeta de red inalámbrica, solo mostrare la información relativa a la tarjeta que estoy analizando:
jose@e3:~$ ifconfig
wlan0 Link encap:Ethernet direcciónHW 20:7c:8f:03:xx:xx
Direc. inet:192.168.0.26 Difus.:192.168.0.255 Másc:255.255.255.0
Dirección inet6: fe80::227c:8fff:xxxx:xxxx/xx Alcance:Enlace
ACTIVO DIFUSIÓN FUNCIONANDO MULTICAST MTU:1500 Métrica:1
Paquetes RX:40728 errores:0 perdidos:0 overruns:0 frame:0
Paquetes TX:31246 errores:0 perdidos:0 overruns:0 carrier:0
colisiones:0 long.colaTX:1000
Bytes RX:53234555 (53.2 MB) TX bytes:4000817 (4.0 MB)
2.2 El paso siguiente fue invocar desde una terminar el proceso wireshark con permisos administrativos,
selecciono la tarjeta de red sobre la que realizaré el análisis de las tramas y antes de comenzar a escuchar
desconecto la conexión inalámbrica establecida verifico por terminal su desconexión y entonces procedo a
escuchar el puerto.
jose@e3:~$ ifconfig
ACTIVO DIFUSIÓN MULTICAST MTU:1500 Métrica:1
En ésta captura se puede apreciar que no tengo ni ip, ni mascara ni puerto de difusión asociado como se puede
apreciar en el anterior.
2.3 Escuchando el puerto desde wireshark procedo a conectarme desde la tarjeta de red hacia una red inalámbrica
diferente, realizando así todos el proceso DORA. (ya que si sigo con la misma red sin borrar previamente los
datos almacenados en mi equipo solo realiza Discover y Acknowledge).
Direc. inet:192.168.0.5 Difus.:192.168.0.255 Másc:255.255.255.0
ACTIVO DIFUSIÓN FUNCIONANDO MULTICAST MTU:1500 Métrica:1
Se puede apreciar que he recibido una nueva ip y ésta red es diferente a la que estaba establecida anteriormente.
En éste momento detengo la escucha del puerto en wireshark y filtro la información con el comando bootp, el cual
me permite visualizar únicamente las tramas con protocolo DHCP.

3 Proceso DORA sobre DHCP
Figura No. 6 Captura de Wireshark mostrando únicamente las tramas DHCP
Se pueden apreciar los 4 momentos principales del protocolo DHCP en acción, para éste caso en específico
existieron tres solicitudes para que finalmente el enrutador realizara la oferta y como se puede apreciar las tramas
son recibidas y se da respuesta inmediatamente una después de la otra.
Al expandir para apreciar la sucesión de tramas como se mostrará en la figura No. 3, que aparece una pequeña
comunicación ICMP del servidor al nodo indicando la IP asignada.

4 DHCP Discover
Figura No. 7 Secuencia de captura de tramas en Wireshark
Al final se adjuntará como anexo el archivo original que exporta Wireshark.
4.1 Capa Aplicación (Servicios de Red a Aplicaciones)
Éste hace referencia a la carga útil del datagrama que se enviará dentro de las tramas en la capa de enlace.
En éste capa del modelo OSI va el protocolo DHCP que es emitido desde el cliente, y que busca
comunicarse con otro protocolo DHCP en el servidor, para esto va a utilizar todas las capas inferiores para
lograr el empalme de la conexión.
Figura No. 8 Descripción detallada línea 4 de la trama DHCP Discover
Se aprecia el DHCP discover en el tipo de mensaje DHCP, ya que se está solicitando una ip y se
desconoce si existe un servidor DHCP en la red, se arma ésta carga útil genérica en la cual se
solicita una IP, y envío la información de la MAC
El propósito del envío DHCP Dicover es que le sea asignado al esquipo la ip, máscara de red, y
demás parámetros para establecer la conexión.
4.2 Capa Presentación (Representación de los datos, gif, jpg, tiff, Codificación)
Para el protocolo DHCP no realiza una representación ni codificación de los mismos, ya que la carga útil
es generada por el protocolo DHCP sin codificación.

4.3 Capa Sesión(Comunicación entre dispositivos de la red)
Como se apreció en el marco de referencia, ya que DHCP se basa en Bootsratp Protocol, éste usa los
puertos 68 para el cliente y 67 para el servidor.
Por ende se toma la carga útil y se adiciona los puertos de conexión entre cliente y servidor.
4.4 Capa Transporte (Conexión extremo a extremo)
El protocolo de transporte es UDP, el cuál es no orientado a la conexión,ya que se desconoce si
se realizará una conexión, sin embargo permite el envío de paquetes.
Esté será el protocolo por el cual se transportará el Datagrama.
Sin embargo hasta éste punto la capa no entiende, ni hace énfasis en IP, ni tampoco en redes ni
subredes, su razón es prestar el servicio de verificar la conexión extremo a extremo e incluye el
CRC respectivo para verificar que la integridad de la información en la conexión.
4.5 Capa Red (Determinar la ruta, con unidad paquete)
IP, Se reconoce que es Internet Protocol v 4, dado el código (0x0800).
Se está haciendo un broadcast a la red a la misma dirección 255.255.255.255.
Se debe notar que se desconoce si esa es la dirección para multicast de la red, definida por el
estándar y en caso que no fuera no encontraría respuesta el protocolo DHCP Discover.
4.6 Capa Enlace (Direccionamiento físico, con unidad tramas)
Se puede ver que no tengo una mac de destino definida en este punto, por tanto se fija
(ff:ff:ff:ff:ff:ff) como destino, (ya que ese número no puede estar asignado a ningún dispositivo y
por ende nadie responderá con ese número como propio), sin embargo envía el número de
máquina en la cabecera de la trama (cliente).
Se identifica que el tipo de red es Ethernet.
4.7 Capa Física (Define el medio físico)
La información de capa física no es analizada a través del analizador Wireshark, sin embargo
para ilustrar el elemento de éste será la tarjeta de red que se conectará a través del medio
(transmisión por radiofrencuencias).

5 DHCP Offer
Al seguir rigurosamente el número de paquetes capturados, se encuentra que el enrutador con servidor DHCP y
con ip 192.168.0.1 responde dos veces seguidas, primero el paquete con protocolo ICMP para informarle al nodo
que no le asigna la ip que solicitó sino que le asigna una que está libre en el momento que es 192.168.0.5 e
inmediatamente después envía el paquete con el protocolo DHCP.
Para este caso como muestra el anexo, ejecuta el protocolo ICMP ejecuta un ping de verificación.
Figura No. 9 Respuesta del enrutador a traves del protocolo ICMP.
Figura No. 10 Respuesta del enrutador a través del protocolo DHCP Offer, parte 1.
.

Figura No. 11 Respuesta del enrutador a través del protocolo DHCP Offer, parte 2.
Éste protocolo DHCP en el enrutador se comunica directamente con el protocolo DHCP del
cliente respondiendo la solicitud de Discovery a través de un Offer.
Ésta carga útil tiene contiene la información requerida por la aplicación, que va desde el tiempo
en que le ofrece la ip, el número de ip ofrecida (para este caso 192.168.0.5), el nombre del host,
además el número ip del servidor que ejecuta el servicio DHCP.
La dirección IP aquí contenida se refiere única y exclusivamente a la carga útil y nada tiene que
ver con la información de las demás capas (la ip que se maneja en la capa de RED), Para éste
momento el cliente no ha aceptado la oferta y por ende esa ip no está asociada a ninguna
máquina.
5.3 Capa Sesión (Comunicación entre dispositivos de la red)
Asi que la carga útil se monta sobre UDP.
En ésta capa no entiende, ni hace énfasis en IP, ni tampoco en redes ni subredes, su razón es
prestar el servicio de verificar la conexión extremo a extremo e incluye el CRC respectivo para
verificar que la integridad de la información en la conexión.

A pesar de que el cliente no ha aceptado la ip, en la cabecera de éste paquete va dirigido a la
dirección IP 192.168.0.5 desde la ip del servidor 192.168.0.1.
Se debe notar que en el envío del paquete anterior, el cliente no tenía ni el número ip del servidor
ni tampoco el número de máquina, por tanto el mensaje llego a todos los nodos en la red, pero
para éste caso específico el único nodo con posibilidad de responder esa petición DHCP fue el
enrutador.
Reconoce el número de máquina del cliente, y envía el del servidor, ambos en la cabecera, como
ésta capa es la encargada del direccionamiento y no entiende de direcciones IP sino solamente de
números de máquina, ésta le apunta exclusivamente a un número de máquina capturado en el
DHCP Discovery.
para ilustrar el elemente actual es la tarjeta inalámbrica del enrutador que seemite a través del
medio (transmisión por radiofrencuencias).

6 DHCP Request
Nuevamente no haré énfasis en el header ya que es el mismo explicado al inicio, sino que me centraré en notar que la
diferencia respecto a la trama DHCP Discover, es que el tipo de mensaje ya no es Discover sino Request y que cambio su
solicitud inicial de 192.168.0.11 a 192.168.0.5, aparece un nuevo campo que es DHCP server Identifier y relaciona la ip del
servidor DHCP, y no ha almacenado aún la información del enrutador, ni de su dirección MAC ni tampoco la IP que acabó
de ser enviada.
Figura No. 12 Protocolo DHCP Request
Éste protocolo DHCP cliente se comunica directamente con el protocolo DHCP del enrutador
respondiendo la solicitud de Offer a través de un Request.
Ésta carga útil tiene contiene la información requerida por la aplicación, básicamente está
diciendo que acepta el número que le acabo de ofrecer.
máquina.
La carga útil contiene el número de máquina del servidor, y la ip del mismo, además le está
enviando el nombre del cliente.
Se debe notar que el cliente aún no se asocia con la ip que le ofrecieron, sino que esperará hasta
el ACK para estar seguro.
Nuevamente se hace un Broadcast a la red a la misma dirección 255.255.255.255.
Se puede ver que no tengo una mac de destino definida en este punto, por tanto se fija
(ff:ff:ff:ff:ff:ff) como destino, (ya que ese número no puede estar asignado a ningún dispositivo y

por ende nadie responderá con ese número como propio), sin embargo envía el número de
máquina en la cabecera de la trama (cliente).
para ilustrar el elemento de éste será la tarjeta de red que se conectará a través del medio
(transmisión por radiofrencuencias).

7 DHCP Acknowledge
Para este momento el enrutador ya tiene plenamente identificado el nodo, tanto dirección MAC como IP, y el tipo de
mensaje DHCP que está enviando es el de reconocimiento de la máquina, le confirma la información que fue previamente
enviada a través de la trama DHCP Offer.
Al termino de ésta trama el nodo acepta la ip ofrecida por el servidor DHCP.
Finalmente como se puede apreciar en la siguiente trama, en la número 34, el nodo acepta la ip 192.168.0.5, y comienza a
hacer envío de tramas como un nodo de la red.
Figura No. 13 Protocolo DHCP Request
Éste protocolo DHCP en el enrutador se comunica directamente con el protocolo DHCP del
cliente respondiendo la solicitud de Request a través de un Acknowledge.
Ésta carga útil tiene contiene la información requerida por la aplicación, confirmando lo enviado
en la oferta (DHCP Offer) desde el tiempo en que le ofrece la ip, el número de ip ofrecida (para
este caso 192.168.0.5), el nombre del host, además el número ip del servidor que ejecuta el
servicio DHCP, diligenciando completamente la información de la carga útil dada por el
protocolo.
máquina.
A pesar de que el cliente no ha aceptado la ip, en la cabecera de éste paquete va dirigido a la
dirección IP 192.168.0.5 desde la ip del servidor 192.168.0.1.
Se debe notar que en el envío del paquete anterior, el cliente no tenía ni el número ip del servidor
ni tampoco el número de máquina, por tanto el mensaje llego a todos los nodos en la red, pero

para éste caso específico el único nodo con posibilidad de responder esa petición DHCP fue el
enrutador.
El servidor envía directamente su número de máquina (source) y el número de máquina del host
(destination)
para ilustrar el elemente actual es la tarjeta inalámbrica del enrutador que se emite a través del
medio (transmisión por radiofrencuencias).

8 Conclusiones
8.1 El protocolo DHCP cumple un propósito importante y ágil de facilitar la conexión de manera dinámica de
nuevos nodos en la red.
8.2 Si desconecto de la red a un nodo y lo vuelvo a conectar en el momento, la negociación del protocolo DHCP
solamente utiliza Discovery y Acknowledge, ya que el enrutador mantiene una tabla interna de asociaciones de
MAC’s con IP’s e igualmente lo hace el nodo, haciendo mucho más rápida la ejecución del protocolo DHCP.
8.3 Es interesante que se pueda modificar la duración de la asignación de las IP en el enrutador, pudiéndola
modificar por el orden de segundos hasta el de meses, obligando así a liberar dinámicamente una IP según sea
necesario.
8.4 Wireshark no alcanza a definir los dispositivos de capa física asociados al medio.
8.5 Wireshark no muestra si el tipo de enlace establecido es inalámbrico o alámbrico y se limita a mostrarlo como
Ethernet.

9 Bibliografía:
9.1 http://www.youtube.com/watch?v=J9HY_nQ01uA visitado el 6 de mayo de 2013.
9.2 Tanenbaum, Andrew S.: Redes de Computadoras, 4ª Ed. Prentice-Hall, 1997. ISBN 968-880-958-6.
9.3 http://www.escotal.com/osilayer.html
9.4 http://www.cicei.com/ocon/gsi/tut_tcpip/3376c418n.html
9.5 http://es.wikipedia.org/wiki/Bootstrap_Protocol

10 Anexo – Paquetes del No. 29 al 33 capturados por Wireshark.
Paquete no. 29 DHCP Discover
No. Time Source Destination Protocol Length Info
29 8.423096 0.0.0.0 255.255.255.255 DHCP 342 DHCP Discover - Transaction ID 0x2fafdd17
Frame 29: 342 bytes on wire (2736 bits), 342 bytes captured (2736 bits)
Arrival Time: May 6, 2013 12:18:26.004772000 COT
Epoch Time: 1367860706.004772000 seconds
[Time delta from previous captured frame: 1.068061000 seconds]
[Time delta from previous displayed frame: 6.003944000 seconds]
[Time since reference or first frame: 8.423096000 seconds]
Frame Number: 29
Frame Length: 342 bytes (2736 bits)
Capture Length: 342 bytes (2736 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: eth:ip:udp:bootp]
[Coloring Rule Name: UDP]
[Coloring Rule String: udp]
Ethernet II, Src: QuantaMi_03:98:25 (20:7c:8f:03:xx:xx), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Destination: Broadcast (ff:ff:ff:ff:ff:ff)
Address: Broadcast (ff:ff:ff:ff:ff:ff)
.... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast)
.... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default)
Source: QuantaMi_03:98:25 (20:7c:8f:03:xx:xx)
Address: QuantaMi_03:98:25 (20:7c:8f:03:xx:xx)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
Type: IP (0x0800)
Internet Protocol Version 4, Src: 0.0.0.0 (0.0.0.0), Dst: 255.255.255.255 (255.255.255.255)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x10 (DSCP 0x04: Unknown DSCP; ECN: 0x00: Not-ECT (Not ECN-Capable Transport))
0001 00.. = Differentiated Services Codepoint: Unknown (0x04)
.... ..00 = Explicit Congestion Notification: Not-ECT (Not ECN-Capable Transport) (0x00)
Total Length: 328
Identification: 0x0000 (0)
Flags: 0x00
0... .... = Reserved bit: Not set
.0.. .... = Don't fragment: Not set
..0. .... = More fragments: Not set
Fragment offset: 0
Time to live: 128
Protocol: UDP (17)
Header checksum: 0x3996 [correct]
[Good: True]
[Bad: False]
Source: 0.0.0.0 (0.0.0.0)
Destination: 255.255.255.255 (255.255.255.255)
User Datagram Protocol, Src Port: bootpc (68), Dst Port: bootps (67)
Source port: bootpc (68)
Destination port: bootps (67)
Length: 308
Checksum: 0x66e8 [validation disabled]
[Good Checksum: False]
[Bad Checksum: False]
Bootstrap Protocol
Message type: Boot Request (1)
Hardware type: Ethernet
Hardware address length: 6
Hops: 0
Transaction ID: 0x2fafdd17
Seconds elapsed: 9
Bootp flags: 0x0000 (Unicast)
0... .... .... .... = Broadcast flag: Unicast
.000 0000 0000 0000 = Reserved flags: 0x0000
Client IP address: 0.0.0.0 (0.0.0.0)
Your (client) IP address: 0.0.0.0 (0.0.0.0)
Next server IP address: 0.0.0.0 (0.0.0.0)
Relay agent IP address: 0.0.0.0 (0.0.0.0)
Client MAC address: QuantaMi_03:98:25 (20:7c:8f:03:xx:xx)

Client hardware address padding: 00000000000000000000
Server host name not given
Boot file name not given
Magic cookie: DHCP
Option: (t=53,l=1) DHCP Message Type = DHCP Discover
Option: (53) DHCP Message Type
Length: 1
Value: 01
Option: (t=50,l=4) Requested IP Address = 192.168.0.11
Option: (50) Requested IP Address
Length: 4
Value: c0a8000b
Option: (t=12,l=2) Host Name = "e3"
Option: (12) Host Name
Length: 2
Value: 6533
Option: (t=55,l=17) Parameter Request List
Option: (55) Parameter Request List
Length: 17
Value: 011c02030f06770c2c2f1a792a79f9fc2a
1 = Subnet Mask
28 = Broadcast Address
2 = Time Offset
3 = Router
15 = Domain Name
6 = Domain Name Server
119 = Domain Search [TODO:RFC3397]
12 = Host Name
44 = NetBIOS over TCP/IP Name Server
47 = NetBIOS over TCP/IP Scope
26 = Interface MTU
121 = Classless Static Route
42 = Network Time Protocol Servers
249 = Private/Classless Static Route (Microsoft)
252 = Private/Proxy autodiscovery
End Option
Padding

Paquete no. 30ICMP
30 8.425440 192.168.0.1 192.168.0.5 ICMP 74 Echo (ping) request id=0x2002, seq=51966/65226, ttl=254
Frame Number: 30
[Protocols in frame: eth:ip:icmp:data]
Ethernet II, Src: AskeyCom_90:97:46 (b4:74:9f:90:xx:xx), Dst: QuantaMi_03:98:25 (20:7c:8f:03:xx:xx)
Destination: QuantaMi_03:98:25 (20:7c:8f:03:xx:xx)
Source: AskeyCom_90:97:46 (b4:74:9f:90:xx:xx)
Address: AskeyCom_90:97:46 (b4:74:9f:90:xx:xx)
Type: IP (0x0800)
Version: 4
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport))
0000 00.. = Differentiated Services Codepoint: Default (0x00)
Total Length: 60
Identification: 0xf9fa (63994)
Flags: 0x00
Fragment offset: 0
Time to live: 254
Protocol: ICMP (1)
Header checksum: 0x416f [correct]
[Good: True]
[Bad: False]
Source: 192.168.0.1 (192.168.0.1)
Destination: 192.168.0.5 (192.168.0.5)
Internet Control Message Protocol
Type: 8 (Echo (ping) request)
Code: 0
Checksum: 0xbafa [correct]
Identifier (BE): 8194 (0x2002)
Identifier (LE): 544 (0x0220)
Sequence number (BE): 51966 (0xcafe)
Sequence number (LE): 65226 (0xfeca)
Data (32 bytes)
0000 c6 b1 46 14 c0 a8 00 05 00 01 02 03 04 05 06 07 ..F.............
0010 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 ................
Data: c6b14614c0a80005000102030405060708090a0b0c0d0e0f...
[Length: 32]

Paquete no. 31DHCP Offer
31 8.430767 192.168.0.1 192.168.0.5 DHCP 590 DHCP Offer - Transaction ID 0x2fafdd17
Frame Number: 31
Type: IP (0x0800)
Version: 4
Total Length: 576
Identification: 0xfa02 (64002)
Flags: 0x00
Fragment offset: 0
Time to live: 255
Protocol: UDP (17)
Header checksum: 0x3e53 [correct]
[Good: True]
[Bad: False]
Source: 192.168.0.1 (192.168.0.1)
Destination: 192.168.0.5 (192.168.0.5)
User Datagram Protocol, Src Port: bootps (67), Dst Port: bootpc (68)
Source port: bootps (67)
Destination port: bootpc (68)
Length: 556
Checksum: 0x8a13 [validation disabled]
Bootstrap Protocol
Message type: Boot Reply (2)
Hops: 0
Seconds elapsed: 0
.000 0000 0000 0000 = Reserved flags: 0x0000
Server host name: HG530

Magic cookie: DHCP
Option: (t=53,l=1) DHCP Message Type = DHCP Offer
Length: 1
Value: 02
Option: (t=1,l=4) Subnet Mask = 255.255.255.0
Option: (1) Subnet Mask
Length: 4
Value: ffffff00
Option: (t=3,l=4) Router = 192.168.0.1
Option: (3) Router
Length: 4
Value: c0a80001
Option: (t=15,l=1) Domain Name = ""
Option: (15) Domain Name
Length: 1
Value: 00
Option: (t=6,l=8) Domain Name Server
Option: (6) Domain Name Server
Length: 8
Value: c84b3384c84b3385
IP Address: 200.75.51.132
IP Address: 200.75.51.133
Option: (t=12,l=7) Host Name = "dhcppc2"
Length: 7
Value: 64686370706332
Option: (t=58,l=4) Renewal Time Value = 12 hours
Option: (58) Renewal Time Value
Length: 4
Value: 0000a8c0
Option: (t=59,l=4) Rebinding Time Value = 21 hours
Option: (59) Rebinding Time Value
Length: 4
Value: 00012750
Option: (t=51,l=4) IP Address Lease Time = 1 day
Option: (51) IP Address Lease Time
Length: 4
Value: 00015180
Option: (t=54,l=4) DHCP Server Identifier = 192.168.0.1
Option: (54) DHCP Server Identifier
Length: 4
Value: c0a80001
End Option
Padding

Paquete no. 32DHCP Request
32 8.430924 0.0.0.0 255.255.255.255 DHCP 342 DHCP Request - Transaction ID 0x2fafdd17
Frame Number: 32
Ethernet II, Src: QuantaMi_03:98:25 (20:7c:8f:03:xx:xx), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Destination: Broadcast (ff:ff:ff:ff:ff:ff)
Address: Broadcast (ff:ff:ff:ff:ff:ff)
.... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast)
.... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default)
Source: QuantaMi_03:98:25 (20:7c:8f:03:xx:xx)
Type: IP (0x0800)
Version: 4
Differentiated Services Field: 0x10 (DSCP 0x04: Unknown DSCP; ECN: 0x00: Not-ECT (Not ECN-Capable Transport))
0001 00.. = Differentiated Services Codepoint: Unknown (0x04)
Total Length: 328
Identification: 0x0000 (0)
Flags: 0x00
Fragment offset: 0
Time to live: 128
Protocol: UDP (17)
Header checksum: 0x3996 [correct]
[Good: True]
[Bad: False]
Source: 0.0.0.0 (0.0.0.0)
Destination: 255.255.255.255 (255.255.255.255)
User Datagram Protocol, Src Port: bootpc (68), Dst Port: bootps (67)
Source port: bootpc (68)
Destination port: bootps (67)
Length: 308
Checksum: 0xbcf1 [validation disabled]
Bootstrap Protocol
Message type: Boot Request (1)
Hops: 0
Seconds elapsed: 9
.000 0000 0000 0000 = Reserved flags: 0x0000
Server host name not given

Magic cookie: DHCP
Option: (t=53,l=1) DHCP Message Type = DHCP Request
Length: 1
Value: 03
Length: 4
Value: c0a80001
Option: (t=50,l=4) Requested IP Address = 192.168.0.5
Option: (50) Requested IP Address
Length: 4
Value: c0a80005
Option: (t=12,l=2) Host Name = "e3"
Length: 2
Value: 6533
Option: (t=55,l=17) Parameter Request List
Option: (55) Parameter Request List
Length: 17
Value: 011c02030f06770c2c2f1a792a79f9fc2a
1 = Subnet Mask
28 = Broadcast Address
2 = Time Offset
3 = Router
15 = Domain Name
6 = Domain Name Server
119 = Domain Search [TODO:RFC3397]
12 = Host Name
44 = NetBIOS over TCP/IP Name Server
47 = NetBIOS over TCP/IP Scope
26 = Interface MTU
249 = Private/Classless Static Route (Microsoft)
252 = Private/Proxy autodiscovery
End Option
Padding

Paquete no. 33DHCP Acknowledge
33 8.437199 192.168.0.1 192.168.0.5 DHCP 590 DHCP ACK - Transaction ID 0x2fafdd17
Frame Number: 33
Type: IP (0x0800)
Version: 4
Total Length: 576
Identification: 0xfa03 (64003)
Flags: 0x00
Fragment offset: 0
Time to live: 255
Protocol: UDP (17)
Header checksum: 0x3e52 [correct]
[Good: True]
[Bad: False]
Source: 192.168.0.1 (192.168.0.1)
Destination: 192.168.0.5 (192.168.0.5)
User Datagram Protocol, Src Port: bootps (67), Dst Port: bootpc (68)
Source port: bootps (67)
Destination port: bootpc (68)
Length: 556
Checksum: 0x8713 [validation disabled]
Bootstrap Protocol
Message type: Boot Reply (2)
Hops: 0
Seconds elapsed: 0
.000 0000 0000 0000 = Reserved flags: 0x0000
Server host name: HG530

Magic cookie: DHCP
Option: (t=53,l=1) DHCP Message Type = DHCP ACK
Length: 1
Value: 05
Option: (t=1,l=4) Subnet Mask = 255.255.255.0
Option: (1) Subnet Mask
Length: 4
Value: ffffff00
Option: (t=3,l=4) Router = 192.168.0.1
Option: (3) Router
Length: 4
Value: c0a80001
Option: (t=15,l=1) Domain Name = ""
Option: (15) Domain Name
Length: 1
Value: 00
Option: (t=6,l=8) Domain Name Server
Option: (6) Domain Name Server
Length: 8
Value: c84b3384c84b3385
IP Address: 200.75.51.132
IP Address: 200.75.51.133
Option: (t=12,l=7) Host Name = "dhcppc2"
Length: 7
Value: 64686370706332
Option: (t=58,l=4) Renewal Time Value = 12 hours
Option: (58) Renewal Time Value
Length: 4
Value: 0000a8c0
Option: (t=59,l=4) Rebinding Time Value = 21 hours
Option: (59) Rebinding Time Value
Length: 4
Value: 00012750
Option: (t=51,l=4) IP Address Lease Time = 1 day
Option: (51) IP Address Lease Time
Length: 4
Value: 00015180
Length: 4
Value: c0a80001
End Option
Padding

Secuencia DORA del protocolo ARP analizado con wireshark

Más contenido relacionado

La actualidad más candente

Similar a Secuencia DORA del protocolo ARP analizado con wireshark

Secuencia DORA del protocolo ARP analizado con wireshark