Está en la página 1de 19

Universidad Nacional Experimental del Tchira Departamento de Ingeniera Informtica Comunicaciones II

Realizado por: Fernando Medina CI: 16445000 Beximar Moreno C.I 17.644.131

San Cristbal Diciembre 2010

Introduccin ICMPv6 es parte integral de IPv6 y debe estar presente en cualquier implementacin de nodo Ipv6. ICMPv6 es empleado por IPv6 para reportar errores que se encuentran durante el procesado de los paquetes, as como para otras cosas. Los mensajes ICMPv6 se agrupan en dos tipos o clases: mensaje de error y mensajes informativos. Los mensajes de error tienen cero en el bit de mayor peso del campo tipo, por lo que sus valores se sitan entre 0 y 127. Los valores de los mensajes informativos oscilan entre 128 y 255.

Por razones de seguridad, las cabeceras ICMPv6 pueden ser autenticadas y encriptadas, usando la cabecera correspondiente. El uso de este mecanismo permite, adems, la prevencin de ataques ICMP, como el conocido Negacin de Servicio. A continuacin vamos a mostrar mas detalladamente todo lo ya mencionado.

Anlisis de ICMPv6 para Windows Lo primero que hacemos es abrir una maquina virtual con Windows XP, y abrimos Wireshark, all le indicamos a que interfaz le queremos hacer seguimiento en nuestro caso la maquina virtual la trabajamos con VMWare y este trabaja en la interfaz vmnet8, debido a esto en Wireshark especificamos que queremos hacer seguimiento a la interfaz vmnet8, luego le damos Start y ya comienza a mostrar todos los paquetes enviados o recibidos desde VMWare. Iniciamos VMWare con Windows XP y nos vamos a Wireshark para ver lo paquetes enviados o recibidos, es all donde podemos apreciar lo siguiente:

Esta captura se hizo al iniciar la maquina virtual con Windows XP, al momento de estarse iniciando se mostraron 6 paquetes ICMPv6. El primer paquete es un paquete Multicast listener report con una direccin origen no especificada (::) y una direccin destino ff02::1:ff54:9a0c (ff02::1 quiere decir que es una direccin de tipo multicast y que es dirigida a todos los nodos). Este paquete pertenece al RFC 2710, es de tipo decimal 131, la direccin de Ipv6mcast_ff:54:9a:0c es 33:33:ff:54:9a:0c (esta direccin MAC quiere decir que proviene de una direccin de tipo nodo solicitado), se tiene .... ...1 .... .... .... .... , esto nos dice que el bit que pertenece a g que esta en 1 es un bit de direccin de grupo (multicast/broadcast). .... ..1. .... .... .... .... , esto nos dice que el bit que pertenece a U esta en 1 y se refiere a que es un bit LG que quiere decir que es una direccin localmente administrada. Para la direccin de origen podemos apreciar que se tiene una direccin Vmware_54:9a:0c (00:0c:29:54:9a:0c) con .... ...0 .... .... .... .... , esto nos dice que el bit g esta en 0 y que es una direccin

individual (unicast). .... ..0. .... .... .... .... , esto nos dice que el bit U esta en 0 y que es una direccin nica global (factory default)

All en la parte de protocolos de internet versin 6 podemos ver que el next header est usando la opcin Ipv6 hopbyhop con un limite de espera de 1, una direccin origen no identificada (::) y una direccin destino ff02::1:ff54:9a0c. Una breve explicacin del campo Tipo: Hay tres tipos de mensajes de MLD: * Multicast Listener consulta (Tipo = decimal 130) Hay dos subtipos de Multicast Listener Mensajes de consultas: Consulta General (General Query ), que sirve para aprender que tienen las direcciones de multidifusin oyentes en un enlace adjunto. MulticastAddressSpecific Query, que sirve para saber si una direccin de multidifusin particular tiene detectores en un vnculo adjunto. Estos dos subtipos se diferencian por el contenido de la Multicast Address field. * Multicast Listener Report (Tipo = decimal 131) * Multicast Listener Hecho (Tipo = decimal 132)

Este campo Tipo se encuentra en el protocolo para controlar los mensajes de internet (Internet Control Message Protocol) que como lo habamos mencionado tiene un tipo numero 131 que se refiere a Multicast listener report. Tiene un Codigo igual a 0, esto quiere decir que es fijado 0 por el remitente e ignorado por los receptores. Tiene un Checksum de 0x4be2 [correct]. Tiene un campo llamado Maximum response delay (respuesta mximo de retardo) es significativo slo en consultas de mensajes, y especifica la demora mxima permitida antes de enviar un Informe de respuesta, en unidades de milisegundos. En todos los otros mensajes, que se fija en cero por el remitente e ignorado por los receptores. Variar este valor, permite a los routers ajustar la "leave latency " que es el tiempo entre el momento en el que el ltimo nodo en un enlace deja de escuchar a una direccin multicast especial y el momento en que el protocolo de enrutamiento es notificado que ya no hay ningn oyente para esa direccin). Este campo tiene un valor de 0, y tiene una direccin multicast ff02::1:ff54:9a0c.

Esta captura muestra el segundo paquete que es un paquete de solicitud de router (Router solicitation), este paquete tiene una direccin origen no identificada (::) y una direccin destino ff02::2 (ff02::2 quiere decir que es una direccin de tipo multicast y que es dirigida a todos los routers). Este paquete pertenece al RFC 2461. Este Router Solicitation se refiere a que cuando una interfaz se habilita, los anfitriones pueden enviar Solicitudes de Router y estas solicitudes deben generar anuncios de enrutador de inmediato en

lugar de hacerlo en su siguiente hora programada. Tienen una direccin destino Ipv6mcast_00:00:00:02 (33:33:00:00:00:02), tienen .... ...1 .... .... .... .... , esto quiere decir que el bit g esta en 1 y que es una direccin de grupo (Group address) (multicast/broadcast) .... ..1. .... .... .... .... , esto quiere decir que el bit U esta en 1 y que tiene direcciones localmente administradas (locally administered address). Tiene una direccin Origen Vmware_54:9a:0c (00:0c:29:54:9a:0c), tienen .... ...0 .... .... .... .... , esto quiere decir que el bit g est en 0 y que es una direccin individual (Individual address) (unicast). .... ..0. .... .... .... .... , esto quiere decir que el bit U esta en 0 y que es una direccin nica global (Globally unique address). En Internet Protocol Version 6 se tiene un next header ICMPv6 (0x3a), un lmite de espera (hop limit) de 255, una direccin origen no identificada (::) y una direccin destino ff02::2.

En Internet Control Message Protocol v6 se puede apreciar que el tipo es nmero 133 que se refiere a un Router solicitation, se tiene un codigo 0 y un checksum 0x7bb8.

Esta captura pertenece al tercer mensaje que aparece en Wireshark , Neighbor Solicitation Message Format pertenece al RFC 2461, lo que quiere decir es que solicita el formato de mensaje del vecino, los Nodos envan Solicitudes a los Vecinos para pedir la direccin de la capa de enlace de un nodo de destino. Las solicitudes a los vecinos son multicast cuando el nodo las necesita para resolver una direccin y unicast cuando el nodo tiene por objeto verificar la accesibilidad de un vecino. Se puede apreciar que en Ethernet II se tiene una direccion de destino Ipv6mcast_ff:54:9a:0c (33:33:ff:54:9a:0c), tambien se tiene .... ...1 .... .... .... .... , esto quiere decir que el bit g esta en 1 y que es una direccin de grupo (Group address) (multicast/broadcast) .... ..1. .... .... .... .... , esto quiere decir que el bit U esta en 1 y que tiene direcciones localmente administradas (locally administered address). Tiene una direccin Origen Vmware_54:9a:0c (00:0c:29:54:9a:0c), tienen .... ...0 .... .... .... .... , esto quiere decir que el bit g est en 0 y que es una direccin individual (Individual address) (unicast). .... ..0. .... .... .... .... , esto quiere decir que el bit U esta en 0 y que es una direccin nica global (Globally unique address).

En esta captura tambin se puede apreciar que en Internet Protocol Version 6 se tiene un limite de espera de 255 y una direccion origen no identificada (::) y una direccin destino ff02::1:ff54:9a0c y en Internet Control Message Protocol v6 se muestra el tipo que es numero 135 que se refiere a Neighbor solicitation, un codigo 0 un checksum 0x1d5a [correct] y el taget fe80::20c:29ff:fe54:9a0c. Luego se presentan 3 mensajes ms, el Cuarto de tipo Multicast listener report, el Quinto de tipo Router solicitation y el Sexto de tipo Router solicitation, estos tipos de paquetes ya se han explicado anteriormente.

Anlisis de ICMPv6 para Linux Lo primero que hacemos es abrir una maquina virtual con Ubuntu, y abrimos Wireshark, all le indicamos a que interfaz le queremos hacer seguimiento en nuestro caso la maquina virtual la trabajamos con VMWare y este trabaja en la interfaz vmnet8, debido a esto en Wireshark especificamos que queremos hacer seguimiento a la interfaz vmnet8, luego de damos Start y ya comienza a mostrar todos los paquetes enviados o recibidos desde VMWare. Iniciamos VMWare con Ubuntu y nos vamos a Wireshark para ver lo paquetes enviados o recibidos, es all donde podemos apreciar lo siguiente:

Esta captura se hizo al iniciar la maquina virtual con Ubuntu, al momento de estarse iniciando se mostraron 6 paquetes ICMPv6. El primer paquete es un paquete Multicast listener report Message v2 con una direccin origen no especificada (::) y una direccin destino ff02::16. Este paquete pertenece al RFC 3810, es de tipo= 143. Se puede apreciar que en Ethernet II se tiene una direccin de destino Ipv6mcast_00:00:00:16 (33:33:00:00:00:16), tambin se tiene .... ...1 .... .... .... .... , esto nos dice que el bit que pertenece a g que esta en 1 es un bit de direccin de grupo (Group address)(multicast/broadcast) . .... ..1. .... .... .... .... , esto nos dice que el bit que pertenece a U esta en 1 y se refiere a que es un bit LG que quiere decir que es una direccin localmente administrada (Locally administered address). Tambin se puede observar una direccin origen Vmware_b2:df:db (00:0c:29:b2:df:db) y

.... ...0 .... .... .... .... , esto quiere decir que el bit g est en 0 y que es una direccin individual (Individual address) (unicast). .... ..0. .... .... .... .... , esto quiere decir que el bit U esta en 0 y que es una direccin nica global (Globally unique address).

En esta captura se puede observar el Internet Protocol Version 6 all se puede apreciar un next header Ipv6 hopbyhop option (0x00), tambien un limite de espera (hop limit) de 1, una direccin origen no identificada (::) y una direccin destino ff02::16. En Hopbyhop Option se puede observar que el next header es ICMPv6 (0x3a). Este campo Tipo se encuentra en el protocolo para controlar los mensajes de internet (Internet Control Message Protocol) que como lo habamos mencionado tiene un tipo numero 143 que se refiere a Multicast listener report Message v2.

Tiene un Codigo igual a 0 (should always be zero), esto quiere decir que es fijado 0 por el remitente e ignorado por los receptores. Tiene un Checksum de 0x8efc [correct].

Aux data len tiene un valor de 0, y tiene una direccin multicast ff02::1:ffb2:dfdb. Esta captura pertenece al Segundo mensaje que aparece en Wireshark , Neighbor Solicitation pertenece al RFC 2461, lo que quiere decir es que solicita el formato de mensaje del vecino, los Nodos envan Solicitudes a los Vecinos para pedir la direccin de la capa de enlace de un nodo de destino. Este paquete tiene una direccin origen no especificada (::) y una direccin destino ff02::1:ffb2:dfdb. Se puede apreciar que en Ethernet II se tiene una direccion de destino Ipv6mcast_ff:b2:df:db (33:33:ff:b2:df:db), tambien se tiene .... ...1 .... .... .... .... , esto quiere decir que el bit g esta en 1 y que es una direccin de grupo (Group address) (multicast/broadcast) .... ..1. .... .... .... .... , esto quiere decir que el bit U esta en 1 y que tiene direcciones localmente administradas (locally administered address). Tiene una direccin Origen Vmware_b2:df:db (00:0c:29:b2:df:db), tienen .... ...0 .... .... .... .... , esto quiere decir que el bit g est en 0 y que es una direccin individual (Individual address) (unicast). .... ..0. .... .... .... .... , esto quiere decir que el bit U esta en 0 y que es una direccin nica global (Globally unique address).

En esta captura tambin se puede apreciar que en Internet Protocol Version 6 se tiene un next header ICMPv6 (0x3a), un limite de espera de 255, una direccin origen no identificada (::) y una direccin destino ff02::1:ffb2:dfdb. En Internet Control Message Protocol v6 se muestra el tipo que es numero 135 que se refiere a Neighbor solicitation, un codigo 0, un checksum 0x90ff [correct] y el target fe80::20c:29ff:feb2:dfdb.

Esta captura muestra el Tercer paquete que es un paquete de solicitud de router (Router solicitation), este paquete tiene una direccin origen fe80::20c:29ff:feb2:dfdb y una direccin destino ff02::2. Este paquete pertenece al RFC 2461. Este Router Solicitation se refiere a que cuando una interfaz se habilita, los anfitriones pueden enviar Solicitudes de Router y estas solicitudes deben generar anuncios de enrutador de inmediato en lugar de hacerlo en su siguiente hora programada. Tienen una direccin destino Ipv6mcast_00:00:00:02 (33:33:00:00:00:02), tienen .... ...1 .... .... .... .... , esto quiere decir que el bit g esta en 1 y que es una direccin de grupo (Group address) (multicast/broadcast) .... ..1. .... .... .... .... , esto quiere decir que el bit U esta en 1 y que tiene direcciones localmente administradas (locally administered address). Tiene una direccin Origen Vmware_b2:df:db (00:0c:29:b2:df:db), tienen .... ...0 .... .... .... .... , esto quiere decir que el bit g est en 0 y que es una direccin individual (Individual address) (unicast). .... ..0. .... .... .... .... , esto quiere decir que el bit U esta en 0 y que es una direccin nica global (Globally unique address).

En Internet Protocol Version 6 se tiene un next header ICMPv6 (0x3a), un limite de espera (hop limit) de 255, una direccin origen fe80::20c:29ff:feb2:dfdb y una direccin destino ff02::2. En Internet Control Message Protocol v6 se puede apreciar que el tipo es numero 133 que se refiere a un Router solicitation, se tiene un codigo 0 y un checksum 0x67fa [correct]. Luego se presentan 3 mensajes ms, el Cuarto de tipo Router solicitation, el Quinto de tipo Multicast Listener Report Message v2 y el Sexto de tipo Router solicitation, estos tipos de paquetes ya se han explicado anteriormente.

Diferencias En Windows se presenta un paquete de tipo Multicast listener report y en Ubuntu se presenta un paquete de tipo Multicast listener report Message v2. El paquete de Router solicitation en Windos tiene como direccin origen una direccin no identificada (::) y una direccin destino ff02::2 y el mismo tipo de paquete en Linux tiene una direccin origen fe80::20c:29ff:feb2:dfdb y una direccin destino ff02::2. El paquete Neighbor solicitation en Windows tiene una direccin origen no identificada (::) y una direccin destino ff02::1:ff54:9a0c y en Linux se tiene una direccin origen no especificada (::) y una direccin destino ff02::1:ffb2:dfdb. Ademas de todo esto vemos una diferencia bastante marcada que es el orden en que se dan los acontecimientos, es decir, en Windows primero se hace un multicast listener report, un router solicitation y luego un neighbor solicitation para volver con un multicast listener report, en cambio en Linux primero se hace un multicast listener report message v2, un neighbor solicitation y luego se realiza dos veces un router solicitation para volver con el multicast listener report message v2. Anlisis de pruebas eco(ping pong) para Windows Lo primero que hacemos es abrir una maquina virtual con Windows XP, y abrimos Wireshark, all le indicamos a que interfaz le queremos hacer seguimiento en nuestro caso la maquina virtual la trabajamos con VMWare y este trabaja en la interfaz vmnet8, debido a esto en Wireshark especificamos que queremos hacer seguimiento a la interfaz vmnet8, luego de damos Start y ya comienza a mostrar todos los paquetes enviados o recibidos desde VMWare. Iniciamos VMWare con Windows XP y nos vamos a Wireshark para ver lo paquetes enviados o recibidos, es all donde podemos apreciar lo siguiente:

Primero hacemos un ping a localhost para chequear que este ipv6 instalado de manera exitosa en windows, luego hacemos un pingv6 multicast tecleando en cmd ping6 ff02::1 como vimos en la imagen anterior y tenemos como resultado lo siguiente:

All se logra observar 3 paquetes ICMPV6 de tipo Echo Request, perteneciente a los RFC 2463 o 4443. Este mensaje me dice si un nodo esta disponible en la red. Para estos paquetes tenemos como direccin origen fe80::20c:29ff:fe54:9a0c y direccin destino ff02::1. Tambien podemos observar que la direccin origen en Ethernet II es vmware_54:9a:0c y

direccin destino Ipv6mcast_00:00:00:01. El tipo esIPv6 (0x86dd), tiempo de espera de 128, un mensaje icmpv6 de tipo 128(Echo request), un checksum de 0x12c0 [correct]. Anlisis de pruebas eco(ping pong) para Linux Lo primero que hacemos es abrir una maquina virtual con Windows XP, y abrimos Wireshark, all le indicamos a que interfaz le queremos hacer seguimiento en nuestro caso la maquina virtual la trabajamos con VMWare y este trabaja en la interfaz vmnet8, debido a esto en Wireshark especificamos que queremos hacer seguimiento a la interfaz vmnet8, luego de damos Start y ya comienza a mostrar todos los paquetes enviados o recibidos desde VMWare. Iniciamos VMWare con Windows XP y nos vamos a Wireshark para ver lo paquetes enviados o recibidos, es all donde podemos apreciar lo siguiente:

Aqu se muestra una prueba del funcionamiento de ipv6 en la maquina virtual usando el comando ping6. A continuacin mostramos los paquetes transmitidos por la maquina virtual de Linux cuando hicimos la prueba de ping6 ff02::1

Aqu se logran ver 1os paquetes de tipo Echo Request perteneciente a los RFC 2463 o 4443 que dice si un nodo esta disponible en la red. Estos paquetes tienen como direccin de origen fe80::20c:29ff:fead:8a48 y como direccin destino ff02::1. En Ethernet II tienen una direccin origen de Vmware_ad:8a:48 y una direccin destino de Ipv6mcast_00:00:00:01, tipo ipv6 (0x86dd), mensajes de tipo Echo Request (128), cheksum de 0x4b5f [correct].