Practica Análisis del Protocolo de Configuración de
Host Dinámico – DHCP - con Wireshark
1 Marco de Referencia
Antes de pr...
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...
Dynamic Host Configuration Protocol (DHCP):
Historia:
DHCP es un protocolo basado en BOOTP, más avanzado, pero más difícil...
IPv4, aunque generalmente se utiliza en la práctica (en IPv6 su uso es obligatorio). A continuación se muestra los campos
...
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 dir...
solicitud de DHCPDISCOVER se pone al valor nulo. El servidor devuelve el
la ruta de acceso completa del fichero en una res...
Esta sección describe la interacción del cliente servidor cuando el cliente desktopno conoce su dirección de red. Se asume...
Figura No. 4Funcionamiento DHCP
Reutilizando una dirección de red previamente asignada
Si el cliente recuerda y desea usar...
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 a...
3 Proceso DORA sobre DHCP
Figura No. 6 Captura de Wireshark mostrando únicamente las tramas DHCP
Se pueden apreciar los 4 ...
4 DHCP Discover
Figura No. 7 Secuencia de captura de tramas en Wireshark
Al final se adjuntará como anexo el archivo origi...
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 ...
5 DHCP Offer
Al seguir rigurosamente el número de paquetes capturados, se encuentra que el enrutador con servidor DHCP y
c...
Figura No. 11 Respuesta del enrutador a través del protocolo DHCP Offer, parte 2.
Éste protocolo DHCP en el enrutador se c...
5.5 Capa Red (Determinar la ruta, con unidad paquete)
IP, Se reconoce que es Internet Protocol v 4, dado el código (0x0800...
6 DHCP Request
Nuevamente no haré énfasis en el header ya que es el mismo explicado al inicio, sino que me centraré en not...
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 (...
7 DHCP Acknowledge
Para este momento el enrutador ya tiene plenamente identificado el nodo, tanto dirección MAC como IP, y...
para éste caso específico el único nodo con posibilidad de responder esa petición DHCP fue el
enrutador.
7.6 Capa Enlace (...
8 Conclusiones
8.1 El protocolo DHCP cumple un propósito importante y ágil de facilitar la conexión de manera dinámica de
...
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.: Re...
10 Anexo – Paquetes del No. 29 al 33 capturados por Wireshark.
Paquete no. 29 DHCP Discover
No. Time Source Destination Pr...
Client hardware address padding: 00000000000000000000
Server host name not given
Boot file name not given
Magic cookie: DH...
Paquete no. 30ICMP
No. Time Source Destination Protocol Length Info
30 8.425440 192.168.0.1 192.168.0.5 ICMP 74 Echo (ping...
Paquete no. 31DHCP Offer
No. Time Source Destination Protocol Length Info
31 8.430767 192.168.0.1 192.168.0.5 DHCP 590 DHC...
Boot file name not given
Magic cookie: DHCP
Option: (t=53,l=1) DHCP Message Type = DHCP Offer
Option: (53) DHCP Message Ty...
Paquete no. 32DHCP Request
No. Time Source Destination Protocol Length Info
32 8.430924 0.0.0.0 255.255.255.255 DHCP 342 D...
Boot file name not given
Magic cookie: DHCP
Option: (t=53,l=1) DHCP Message Type = DHCP Request
Option: (53) DHCP Message ...
Paquete no. 33DHCP Acknowledge
No. Time Source Destination Protocol Length Info
33 8.437199 192.168.0.1 192.168.0.5 DHCP 5...
Boot file name not given
Magic cookie: DHCP
Option: (t=53,l=1) DHCP Message Type = DHCP ACK
Option: (53) DHCP Message Type...
Upcoming SlideShare
Loading in...5
×

Secuencia DORA del protocolo ARP analizado con wireshark

1,099

Published on

Secuencia DORA del protocolo ARP analizado con wireshark

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,099
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
42
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Secuencia DORA del protocolo ARP analizado con wireshark

  1. 1. 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
  2. 2. 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
  3. 3. 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
  4. 4. 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) .
  5. 5. 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
  6. 6. 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
  7. 7. 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.
  8. 8. 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:
  9. 9. Figura No. 5Funcionamiento DHCP con reutilización
  10. 10. 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 wlan0 Link encap:Ethernet direcciónHW 20:7c:8f:03:xx:xx Dirección inet6: fe80::227c:8fff:xxxx:xxxx/xx Alcance:Enlace ACTIVO DIFUSIÓN MULTICAST MTU:1500 Métrica:1 Paquetes RX:43195 errores:0 perdidos:0 overruns:0 frame:0 Paquetes TX:33713 errores:0 perdidos:0 overruns:0 carrier:0 colisiones:0 long.colaTX:1000 Bytes RX:54662319 (54.6 MB) TX bytes:4439080 (4.4 MB) 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). wlan0 Link encap:Ethernet direcciónHW 20:7c:8f:03:xx:xx Direc. inet:192.168.0.5 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:60125 errores:0 perdidos:0 overruns:0 frame:0 Paquetes TX:46675 errores:0 perdidos:0 overruns:0 carrier:0 colisiones:0 long.colaTX:1000 Bytes RX:75780157 (75.7 MB) TX bytes:5974690 (5.9 MB) 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.
  11. 11. 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.
  12. 12. 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.
  13. 13. 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).
  14. 14. 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. 5.1 Capa Aplicación (Servicios de Red a Aplicaciones) Figura No. 10 Respuesta del enrutador a través del protocolo DHCP Offer, parte 1. .
  15. 15. 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.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. 5.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. 5.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. Asi que la carga útil se monta sobre UDP. Esté será el protocolo por el cual se transportará el Datagrama. 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.
  16. 16. 5.5 Capa Red (Determinar la ruta, con unidad paquete) IP, Se reconoce que es Internet Protocol v 4, dado el código (0x0800). 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. 5.6 Capa Enlace (Direccionamiento físico, con unidad tramas) 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. Se identifica que el tipo de red es Ethernet. 5.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 elemente actual es la tarjeta inalámbrica del enrutador que seemite a través del medio (transmisión por radiofrencuencias).
  17. 17. 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. 6.1 Capa Aplicación (Servicios de Red a Aplicaciones) 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. 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. 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. 6.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. 6.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. 6.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. Asi que la carga útil se monta sobre UDP. Esté será el protocolo por el cual se transportará el Datagrama. 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. 6.5 Capa Red (Determinar la ruta, con unidad paquete) IP, Se reconoce que es Internet Protocol v 4, dado el código (0x0800). 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. 6.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
  18. 18. 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. 6.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).
  19. 19. 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. 7.1 Capa Aplicación (Servicios de Red a Aplicaciones) 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. 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. 7.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. 7.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. 7.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. Asi que la carga útil se monta sobre UDP. Esté será el protocolo por el cual se transportará el Datagrama. 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. 7.5 Capa Red (Determinar la ruta, con unidad paquete) IP, Se reconoce que es Internet Protocol v 4, dado el código (0x0800). 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
  20. 20. para éste caso específico el único nodo con posibilidad de responder esa petición DHCP fue el enrutador. 7.6 Capa Enlace (Direccionamiento físico, con unidad tramas) El servidor envía directamente su número de máquina (source) y el número de máquina del host (destination) Se identifica que el tipo de red es Ethernet. 7.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 elemente actual es la tarjeta inalámbrica del enrutador que se emite a través del medio (transmisión por radiofrencuencias).
  21. 21. 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.
  22. 22. 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
  23. 23. 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)
  24. 24. 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 121 = Classless Static Route 249 = Private/Classless Static Route (Microsoft) 252 = Private/Proxy autodiscovery 42 = Network Time Protocol Servers End Option Padding
  25. 25. Paquete no. 30ICMP No. Time Source Destination Protocol Length Info 30 8.425440 192.168.0.1 192.168.0.5 ICMP 74 Echo (ping) request id=0x2002, seq=51966/65226, ttl=254 Frame 30: 74 bytes on wire (592 bits), 74 bytes captured (592 bits) Arrival Time: May 6, 2013 12:18:26.007116000 COT Epoch Time: 1367860706.007116000 seconds [Time delta from previous captured frame: 0.002344000 seconds] [Time delta from previous displayed frame: 0.002344000 seconds] [Time since reference or first frame: 8.425440000 seconds] Frame Number: 30 Frame Length: 74 bytes (592 bits) Capture Length: 74 bytes (592 bits) [Frame is marked: False] [Frame is ignored: False] [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) 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) Source: AskeyCom_90:97:46 (b4:74:9f:90:xx:xx) Address: AskeyCom_90:97:46 (b4:74:9f:90:xx:xx) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) Type: IP (0x0800) Internet Protocol Version 4, Src: 192.168.0.1 (192.168.0.1), Dst: 192.168.0.5 (192.168.0.5) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport)) 0000 00.. = Differentiated Services Codepoint: Default (0x00) .... ..00 = Explicit Congestion Notification: Not-ECT (Not ECN-Capable Transport) (0x00) Total Length: 60 Identification: 0xf9fa (63994) Flags: 0x00 0... .... = Reserved bit: Not set .0.. .... = Don't fragment: Not set ..0. .... = More fragments: Not set 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]
  26. 26. Paquete no. 31DHCP Offer No. Time Source Destination Protocol Length Info 31 8.430767 192.168.0.1 192.168.0.5 DHCP 590 DHCP Offer - Transaction ID 0x2fafdd17 Frame 31: 590 bytes on wire (4720 bits), 590 bytes captured (4720 bits) Arrival Time: May 6, 2013 12:18:26.012443000 COT Epoch Time: 1367860706.012443000 seconds [Time delta from previous captured frame: 0.005327000 seconds] [Time delta from previous displayed frame: 0.007671000 seconds] [Time since reference or first frame: 8.430767000 seconds] Frame Number: 31 Frame Length: 590 bytes (4720 bits) Capture Length: 590 bytes (4720 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: 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) 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) Source: AskeyCom_90:97:46 (b4:74:9f:90:xx:xx) Address: AskeyCom_90:97:46 (b4:74:9f:90:xx:xx) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) Type: IP (0x0800) Internet Protocol Version 4, Src: 192.168.0.1 (192.168.0.1), Dst: 192.168.0.5 (192.168.0.5) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport)) 0000 00.. = Differentiated Services Codepoint: Default (0x00) .... ..00 = Explicit Congestion Notification: Not-ECT (Not ECN-Capable Transport) (0x00) Total Length: 576 Identification: 0xfa02 (64002) Flags: 0x00 0... .... = Reserved bit: Not set .0.. .... = Don't fragment: Not set ..0. .... = More fragments: Not set 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] [Good Checksum: False] [Bad Checksum: False] Bootstrap Protocol Message type: Boot Reply (2) Hardware type: Ethernet Hardware address length: 6 Hops: 0 Transaction ID: 0x2fafdd17 Seconds elapsed: 0 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: 192.168.0.5 (192.168.0.5) Next server IP address: 192.168.0.1 (192.168.0.1) 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: HG530
  27. 27. Boot file name not given Magic cookie: DHCP Option: (t=53,l=1) DHCP Message Type = DHCP Offer Option: (53) DHCP Message Type 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" Option: (12) Host Name 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
  28. 28. Paquete no. 32DHCP Request No. Time Source Destination Protocol Length Info 32 8.430924 0.0.0.0 255.255.255.255 DHCP 342 DHCP Request - Transaction ID 0x2fafdd17 Frame 32: 342 bytes on wire (2736 bits), 342 bytes captured (2736 bits) Arrival Time: May 6, 2013 12:18:26.012600000 COT Epoch Time: 1367860706.012600000 seconds [Time delta from previous captured frame: 0.000157000 seconds] [Time delta from previous displayed frame: 0.000157000 seconds] [Time since reference or first frame: 8.430924000 seconds] Frame Number: 32 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: 0xbcf1 [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
  29. 29. Boot file name not given Magic cookie: DHCP Option: (t=53,l=1) DHCP Message Type = DHCP Request Option: (53) DHCP Message Type Length: 1 Value: 03 Option: (t=54,l=4) DHCP Server Identifier = 192.168.0.1 Option: (54) DHCP Server Identifier 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" 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 121 = Classless Static Route 249 = Private/Classless Static Route (Microsoft) 252 = Private/Proxy autodiscovery 42 = Network Time Protocol Servers End Option Padding
  30. 30. Paquete no. 33DHCP Acknowledge No. Time Source Destination Protocol Length Info 33 8.437199 192.168.0.1 192.168.0.5 DHCP 590 DHCP ACK - Transaction ID 0x2fafdd17 Frame 33: 590 bytes on wire (4720 bits), 590 bytes captured (4720 bits) Arrival Time: May 6, 2013 12:18:26.018875000 COT Epoch Time: 1367860706.018875000 seconds [Time delta from previous captured frame: 0.006275000 seconds] [Time delta from previous displayed frame: 0.006275000 seconds] [Time since reference or first frame: 8.437199000 seconds] Frame Number: 33 Frame Length: 590 bytes (4720 bits) Capture Length: 590 bytes (4720 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: 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) 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) Source: AskeyCom_90:97:46 (b4:74:9f:90:xx:xx) Address: AskeyCom_90:97:46 (b4:74:9f:90:xx:xx) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) Type: IP (0x0800) Internet Protocol Version 4, Src: 192.168.0.1 (192.168.0.1), Dst: 192.168.0.5 (192.168.0.5) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport)) 0000 00.. = Differentiated Services Codepoint: Default (0x00) .... ..00 = Explicit Congestion Notification: Not-ECT (Not ECN-Capable Transport) (0x00) Total Length: 576 Identification: 0xfa03 (64003) Flags: 0x00 0... .... = Reserved bit: Not set .0.. .... = Don't fragment: Not set ..0. .... = More fragments: Not set 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] [Good Checksum: False] [Bad Checksum: False] Bootstrap Protocol Message type: Boot Reply (2) Hardware type: Ethernet Hardware address length: 6 Hops: 0 Transaction ID: 0x2fafdd17 Seconds elapsed: 0 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: 192.168.0.5 (192.168.0.5) Next server IP address: 192.168.0.1 (192.168.0.1) 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: HG530
  31. 31. Boot file name not given Magic cookie: DHCP Option: (t=53,l=1) DHCP Message Type = DHCP ACK Option: (53) DHCP Message Type 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" Option: (12) Host Name 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

×