c
! " #$
&'c (! #%c!)c%c!)&!) *!$
% Carlos A. Morillo Díaz. CI: 18.186.162
v Introducción««««««««««««««««««««««««««««««.1 Protocolo ICMP««««««««««««««««««««««««««««2-5 è è è
Mensajes Informativos. Mensajes de error. Gestión de errores.
Protocolo ARP««««««««««««««««««««««««««««5-13 Funcionamiento. Campos en los datagramas ARP. Objetivo del protocolo ARP. ARP y subredes. ARP Mensaje. Envenenamiento ARP. Cómo resuelve ARP las direcciones de control de acceso a medios para el tráfico local. è Cómo resuelve ARP las direcciones de control de acceso a medios para el tráfico remoto. è La caché de ARP.
è è è è è è è
Protocolo RARP««««««««««««««««««««««««««...13-15 Protocolo de administración de grupos de Internet (IGMP)««««««««..16-25
è IGMP Versión 1 è IGMP Versión 2 è IGMP Versión 3 Conclusión««««««««««««««««««««««««««««««.26 Bibliografía««««««««««««««««««««««««««««««..27
+ En el presente trabajo se habla sobre los diferentes tipos de protocolos que se encuentran en la capa 3 de red como son protocolos ICMP, ARP, RARP, IGMP. Se define cada uno de los protocolos mencionados, como funciona y los objetivos de los protocolos ICMP, ARP y RARP, se menciona las 3 versiones del protocolo IGMP. Cada uno de estos protocolos son importantes para el correcto funcionamiento y manejos de errores dentro de la RED.
&! TCP utiliza este protocolo para el envío de mensajes de control y de error. Por ejemplo ping se utiliza para ver si un ordenador está activo en la red. Los mensajes ICMP están dentro de datagramas IP (IP los trata igual que los demás datagramas). Es decir, dentro de los datos del datagrama, hay una cabecera del protocolo ICMP que indica una serie de parámetros como código de error, tipo de mensaje, etc., (como ya se ha dicho, IP no tiene constancia de que sea un datagrama especial). ICMP pueden enviar varios tipos de mensajes como por ejemplo, destino no alcanzable, control de congestión, redireccionamiento, tiempo excedido. El Protocolo de Mensajes de Control y Error de Internet, ICMP, es de características similares a UDP, pero con un formato mucho más simple, y su utilidad no está en el transporte de datos de usuario, sino en controlar si un paquete no puede alcanzar su destino, si su vida ha expirado, si el encabezamiento lleva un valor no permitido, si es un paquete de eco o respuesta, etc. Es decir, se usa para manejar mensajes de error y de control necesarios para los sistemas de la red, informando con ellos a la fuente original para que evite o corrija el problema detectado. ICMP proporciona así una comunicación entre el software IP de una máquina y el mismo software en otra. El protocolo ICMP solamente informa de incidencias en la entrega de paquetes o de errores en la red en general, pero no toma decisión alguna al respecto. Esto es tarea de las capas superiores.
V V V V
Los mensajes ICMP se transmiten como datagramas IP normales, con el campo de cabecera "protocolo" con un valor 1, y comienzan con un campo de 8 bits que define el tipo de mensaje de que se trata. A continuación viene un campo código, de o bits, que a veces ofrece una descripción del error concreto que se ha producido y después un campo suma de control, de 16 bits, que incluye una suma de verificación de errores de transmisión.
Tras estos campos viene el cuerpo del mensaje, determinado por el contenido del campo "tipo". Contienen además los 8 primeros bytes del datagrama que ocasionó el error.
Los principales tipos de mensaje ICMP son los siguientes: , " Entre estos mensajes hay algunos de suma importancia, como los mensajes de petición de ECO (tipo 8) y los de respuesta de Eco (tipo 0). Las peticiones y respuestas de eco se usan en redes para comprobar si existe una comunicación entre dos host a nivel de capa de red, por lo que nos pueden servir para identificar fallos en este nivel, ya que verifican si las capas física (cableado), de enlace de datos (tarjeta de red) y red (configuración IP) se encuentran en buen estado y configuración. , En el caso de obtener un mensaje ICMP de destino inalcanzable, con campo "tipo" de valor 3, el error concreto que se ha producido vendrá dado por el valor del campo "código", pudiendo presentar los siguientes valores que se muestran en la parte derecha.
Este tipo de mensajes se generan cuando el tiempo de vida del datagrama a llegado a cero mientras se encontraba en tránsito hacia el host destino (código=0), o porque, habiendo llegado al destino, el tiempo de reensamblado de los diferentes fragmentos expira antes de que lleguen todos los necesarios (código=1). Los mensajes ICMP de tipo= 12 (problemas de parámetros) se originan por ejemplo cuando existe información inconsistente en alguno de los campos del datagrama, que hace que sea imposible procesar el mismo correctamente, cuandose envían datagramas de tamaño incorrecto o cuando falta algún campo obligatorio. Por su parte, los mensajes de tipo=5 (mensajes de redirección) se suelen enviar cuando, existiendo dos o más routers diferentes en la misma red, el paquete se envía al router equivocado. En este caso, el router receptor devuelve el datagrama al host origen junto con un mensaje ICMP de redirección, lo que hará que éste actualice su tabla de enrutamiento y envíe el paquete al siguiente router. - , &! Los mensajes de error ICMP se envían a través de la red en forma de datagramas, como cualquier otro dato. Por lo tanto, los mismos mensajes de error pueden contener errores. Sin embargo, si existe un error en un datagrama que lleva un mensaje ICMP, no se envía ningún mensaje de error para evitar el efecto "bola de nieve", si hay un incidente en la red.
V V
* + &! (Protocolo de mensajes de control de Internet) es un protocolo que permite administrar información relacionada con errores de los equipos en red. Si se tienen en cuenta los escasos controles que lleva a cabo el protocolo IP, ICMP no permite corregir los errores sino que los notifica a los protocolos de capas cercanas. Por lo tanto, el protocolo ICMP es usado por todos los routers para indicar un error (llamado un problema de entrega).
%c! Convierte las direcciones IP en direcciones físicas de la red. Cada host tiene una tabla para realizar dicha conversión. Cuando una dirección pedida no figura en la tabla, ARP genera una petición por toda la red. Si alguna máquina de la red recibe esa petición y corresponde con la suya propia, avisa al host que ha realizado la petición y este incluye la nueva dirección en su tabla de direcciones. El protocolo ARP es un protocolo estándar específico de las redes. Su status es electivo. El protocolo de resolución de direcciones es responsable de convertir la dirección de protocolo de alto nivel(direcciones IP) a direcciones de red físicas. Primero, consideremos algunas cuestiones generales acerca de Ethernet. ARP se emplea en redes IEEE 802 además de en las viejas redes DIX Ethernet para mapear direcciones IP a dirección hardware. Para hacer esto, ha de estar estrechamente relacionado con el manejador de dispositivo de red. De hecho, las especificaciones de ARP en RFC 826 sólo describen su funcionalidad, no su implementación, que depende en gran medida del manejador de dispositivo para el tipo de red correspondiente, que suele estar codificado en el microcódigo del adaptador. Si una aplicación desea enviar datos a una determinado dirección IP de destino, el mecanismo de encaminamiento IP determina primero la dirección IP del siguiente salto del paquete (que puede ser el propio host de destino o un "router") y el dispositivo hardware al que se debería enviar. Si se trata de una red 802.3/4/5, deberá consultarse el módulo ARP para mapear el par a una dirección física. El módulo ARP intenta hallar la dirección en su caché. Si encuentra el par buscado, devuelve la correspondiente dirección física de 48 bits al llamador(el
manejador de dispositivo). Si no lo encuentra, descarta el paquete (se asume que al ser un protocolo de alto nivel volverá a transmitirlo) y genera un broadcast de red para una solicitud ARP.
Si queremos enviar un paquete de ³A´ a ³B´ que se encuentra en la misma red lo primero que hace ³A´ es comprobar en su tabla ARP si se encuentra la dirección %& de ³B´ si es así se utiliza si no se enviara el correspondiente paquete broadcast esperando la respuesta de la maquina cuya dirección IP corresponda con la preguntada añadiendo un nuevo registro a la tabla. Estas entradas se borran cada cierto tiempo.
En un segundo caso si ³A´ quiere enviar un paquete a ³B´ que no esta en su misma red lo que hace ³A´ es enviarlo a través de la dirección física de su de salida, para ello consulta la tabla %c! realizando el correspondiente intercambio de mensajes si dicha entrada no se encuentra en la tabla. Una vez en el router este consulta su tabla de encaminamiento enviando el paquete al próximo nodo y así sucesivamente hasta que le paquete llega a un router de la red en la que se encuentre la IP destino. Una vez allí el router se encarga de averiguar la dirección física consultando su tabla ARP o preguntando con mensajes correspondientes.
& %c! è
å - : 16bits. Tecnología de red empleada por debajo de TCP/IP.
è
ü - . : 16 bits. Tipo de protocolo empleado a nivel 3.
è
å - /: 8 bits. Longitud de la dirección de red de hardware.
è
ü - . /: 8 bits. Longitud de la dirección de red IP.
è
+ 16 bits. Tipo de operación que nos da información sobre si se trata de una petición o de una respuesta ARP.
è
/ - : 48 bits. Dirección física MAC. de la interfaz de red del emisor.
è
- . : 32 bits. Direction IP del emisor.
è
/ - : 48 bits. Dirección física mace e la interfaz de red del receptor.
è
- . : 32 bits. La direction IP del receptor.
, %c! El protocolo %c! tiene un papel clave entre los protocolos de capa de Internet relacionados con el protocolo TCP/IP, ya que permite que se conozca la dirección física de una tarjeta de interfaz de red correspondiente a una dirección IP. Por eso se llama Protocolo de Resolución de Dirección (en inglés ARP significa AddressResolutionProtocol). Cada equipo conectado a la red tiene un número de identificación de 48 bits. Éste es un número único establecido en la fábrica en el momento de
fabricación de la tarjeta. Sin embargo, la comunicación en Internet no utiliza directamente este número (ya que las direcciones de los equipos deberían cambiarse cada vez que se cambia la tarjeta de interfaz de red), sino que utiliza una dirección lógica asignada por un organismo: la dirección IP. Para que las direcciones físicas se puedan conectar con las direcciones lógicas, el protocolo ARP interroga a los equipos de la red para averiguar sus direcciones físicas y luego crea una tabla de búsqueda entre las direcciones lógicas y físicas en una memoria caché. Cuando un equipo debe comunicarse con otro, consulta la tabla de búsqueda. Si la dirección requerida no se encuentra en la tabla, el protocolo ARP envía una solicitud a la red. Todos los equipos en la red comparan esta dirección lógica con la suya. Si alguno de ellos se identifica con esta dirección, el equipo responderá al ARP, que almacenará el par de direcciones en la tabla de búsqueda, y, a continuación, podrá establecerse la comunicación. %c!0 El protocolo ARP es el mismo aunque haya subredes. Recordar que cada datagrama IP pasa primero por el algoritmo de encaminamiento IP. Este algoritmo selecciona el manejador de dispositivo que debería enviar el paquete. Sólo entonces se consulta al módulo ARP asociado con ese manejador.
%c! , A A A A A
Tipo de HW: Identifica el tipo de hardware que se utiliza: Ethernet, ATM, HDLC. Tipo de Protocolo: IPv4 Tamaño de dirección HW: para Ethernet (MAC) son 6 bytes. Tamaño de dirección de protocolo: Para la IPv4 son 4 bytes. Operación ARP: Petición o respuesta.
%c! A A A
Este tipo de vulnerabilidad consiste en el envenenamiento de las tablas ARP de los host implicados. También conocido como ARP Spoofing, Falsificación ARP... Se aprovecha de que las tablas son dinámicas y cambian conforme le llegan respuestas ARP, aunque no hayan pedido petición ninguna.
&+ %c!
" La siguiente ilustración muestra cómo resuelve ARP las direcciones IP en direcciones de hardware de hosts que se encuentran en la misma red local.
En este ejemplo, dos hosts TCP/IP, los hosts A y B, se encuentran en la misma red física. El host A tiene asignada la dirección IP 10.0.0.99 y el host B la dirección IP 10.0.0.100. Cuando el host A intenta comunicarse con el host B, los siguientes pasos permiten resolver la dirección asignada por el software al host B (10.0.0.100) en la dirección de control de acceso a medios asignada por el hardware al host B: 1. Según el contenido de la tabla de enrutamiento del host A, IP determina que la dirección IP de reenvío que se va a utilizar para llegar al host B es 10.0.0.100. Después, el host A busca en su propia caché de ARP local una dirección de hardware coincidente para el host B. 2. Si el host A no encuentra ninguna asignación en la caché, difunde una trama de solicitud ARP a todos los hosts de la red local con la pregunta "¿Cuál es la dirección de hardware para 10.0.0.100?" Las direcciones de hardware y software del origen, el host A, se incluyen en la solicitud ARP. Cada host de la red local recibe la solicitud ARP y comprueba si coincide con su propia dirección IP. Si el host no encuentra una coincidencia, descarta la solicitud ARP. 3. El host B determina que la dirección IP especificada en la solicitud ARP coincide con su propia dirección IP y agrega una asignación de direcciones de hardware y software para el host A a su caché de ARP local.
4. El host B envía directamente un mensaje de respuesta de ARP que contiene su dirección de hardware al host A. 5. Cuando el host A recibe el mensaje de respuesta de ARP del host B, actualiza su caché de ARP con una asignación de direcciones de hardware y software para el host B. Una vez determinada la dirección de control de acceso a medios del host B, el host A puede enviar al host B tráfico IP que se dirigirá a la dirección de control de acceso a medios del host B. &+ %c!
" ARP también se utiliza para reenviar datagramas IP a enrutadores locales de destinos que no se encuentran en la red local. En estos casos, ARP resuelve la dirección de control de acceso a medios de la interfaz de un enrutador en la red local. En la siguiente ilustración se muestra cómo resuelve ARP las direcciones IP en direcciones de hardware de dos hosts que se encuentran en redes físicas diferentes conectadas por un enrutador común.
En este ejemplo, el host A tiene asignada la dirección IP 10.0.0.99 y el host B la dirección IP 192.168.0.99. La interfaz del enrutador 1 se encuentra en la misma red física que el host A y utiliza la dirección IP 10.0.0.1. La interfaz del enrutador 2 se encuentra en la misma red física que el host B y utiliza la dirección IP 192.168.0.1.
Cuando el host A intenta comunicarse con el host B, los siguientes pasos permiten resolver la dirección asignada por el software a la interfaz del enrutador 1 (10.0.0.1) en la dirección de control de acceso a medios asignada por el hardware: 1. Según el contenido de la tabla de enrutamiento del host A, IP determina que la dirección IP de reenvío que se va a utilizar para llegar al host B es 10.0.0.1, la dirección IP de la puerta de enlace predeterminada. Después, el host A busca en su propia caché de ARP local una dirección de hardware coincidente para 10.0.0.1. 2. Si el host A no encuentra ninguna asignación en la caché, difunde una trama de solicitud ARP a todos los hosts de la red local con la pregunta "¿Cuál es la dirección de hardware para 10.0.0.1?" Las direcciones de hardware y software del origen, el host A, se incluyen en la solicitud ARP. Cada host de la red local recibe la solicitud ARP y comprueba si coincide con su propia dirección IP. Si el host no encuentra una coincidencia, descarta la solicitud ARP. 3. El enrutador determina que la dirección IP especificada en la solicitud ARP coincide con su propia dirección IP y agrega una asignación de direcciones de hardware y software para el host A a su caché de ARP local. 4. Después, el enrutador envía directamente un mensaje de respuesta de ARP que contiene su dirección de hardware al host A. 5. Cuando el host A recibe el mensaje de respuesta de ARP del enrutador, actualiza su caché de ARP con una asignación de direcciones de hardware y software para 10.0.0.1. Una vez determinada la dirección de control de acceso a medios de la interfaz del enrutador 1, el host A puede enviar a la interfaz del enrutador 1 tráfico IP que se dirigirá a la dirección de control de acceso a medios de esa interfaz. Posteriormente, el enrutador reenvía el tráfico al host B mediante el mismo proceso ARP que se describe en esta sección.
-/1 %c! Para disminuir el número de difusiones, ARP mantiene una caché de asignaciones de direcciones de control de acceso a direcciones de medios de IP para su uso posterior. La caché de ARP puede incluir entradas dinámicas y estáticas. Las entradas dinámicas se agregan y se quitan automáticamente a lo
largo del tiempo. Las entradas estáticas permanecen en la caché hasta que se reinicia el equipo. Las entradas dinámicas de la caché de ARP tienen un tiempo de vida posible de 10 minutos. Las nuevas entradas agregadas a la caché se marcan con la fecha y hora. Si una entrada no se vuelve a utilizar antes de 2 minutos desde que se agregó, caduca y se elimina de la caché de ARP. Si se utiliza una entrada, recibe dos minutos más de tiempo de vida. Si se sigue utilizando una entrada, recibe otros dos minutos más hasta un tiempo de vida máximo de 10 minutos. Puede ver la caché de ARP con el comando . Para ver la caché ARP, escriba 2 en el símbolo del sistema. Para ver las opciones de la línea de comandos de , escriba 34 en un símbolo del sistema. c%c! El protocolo RARP (Protocolo de Resolución de Dirección Inversa) es mucho menos utilizado. Es un tipo de directorio inverso de direcciones lógicas y físicas.
La resolución de direcciones inversa se lleva a cabo de la misma manera que la resolución de direcciones de ARP. El mismo formato de paquete se usa as for ARP. Una excepción es el campo de "código de operación" que ahora toma los valores siguientes: ' Para la petición RARP 5 Para la respuesta RARP
´ por supuesto, la cabecera "física" de la trama indicará ahora RARP as thehigher-levelprotocol (8035 hex) instead of ARP (0806 hex) or IP (0800 hex) en el campo !therType. Algunas diferencias provienen del propio concepto RARP: è
è
è è
ARP asume únicamente que cada host sabe la correspondencia existente entre su propia dirección hardware y la dirección de protocolo. RARP requiere uno o más hosts de servidores de la red para mantener una base de datos de correspondencias entre direcciones hardware y direcciones de protocolo así que serán capaces de responder a peticiones de hosts de clientes. Debido al tamaño que esta base de datos puede tomar, parte de la función del servidor se implementa con frecuencia fuera del microcódigo del adaptador, con una caché pequeña opcional en el microcódigo. La parte de microcódigo es responsable únicamente de la recepción y transmisión de las tramas RARP, la propia correspondencia RARP beingtakencare of by server software running as a normal process in the host machine. La naturaleza de esta base de datos también requiere algún software para crear y actualizar manualmente la base de datos. En caso de haya múltiples servidores RARP en la red, el solicitante RARP sólo usará la primera respuesta RARP recibida en su respuesta RARP broadcast, y descartarán las otras.
En realidad, el protocolo RARP se usa esencialmente para las estaciones de trabajo sin discos duros que desean conocer su dirección física.
El protocolo RARP le permite a la estación de trabajo averiguar su dirección IP desde una tabla de búsqueda entre las direcciones MAC (direcciones físicas) y
las direcciones IP alojadas por una pasarela ubicada en la misma red de área local (LAN). Para poder hacerlo, el administrador debe definir los parámetros de la pasarela (router) con la tabla de búsqueda para las direcciones MAC/IP. A diferencia del ARP, este protocolo es estático. Por lo que la tabla de búsqueda debe estar siempre actualizada para permitir la conexión de nuevas tarjetas de interfaz de red. El protocolo RARP tiene varias limitaciones. Se necesita mucho tiempo de administración para mantener las tablas importantes en los servidores. Esto se ve reflejado aún más en las grandes redes. Lo que plantea problemas de recursos humanos, necesarios para el mantenimiento de las tablas de búsqueda y de capacidad por parte del hardware que aloja la parte del servidor del protocolo RARP. Efectivamente, el protocolo RARP permite que varios servidores respondan a solicitudes, pero no prevé mecanismos que garanticen que todos los servidores puedan responder, ni que respondan en forma idéntica. Por lo que, en este tipo de arquitectura, no podemos confiar en que un servidor RARP sepa si una dirección MAC se puede conectar con una dirección IP, porque otros servidores ARP pueden tener una respuesta diferente. Otra limitación del protocolo RARP es que un servidor sólo puede servir a una LAN. Para solucionar los dos primeros problemas de administración, el protocolo RARP se puede remplazar por el protocolo DRARP, que es su versión dinámica. Otro enfoque consiste en la utilización de un servidor DHCP (Protocolo de configuración de host dinámico), que permite una resolución dinámica de las direcciones. Además, el protocolo DHCP es compatible con el protocolo BOOTP (Protocolo de secuencia de arranque) y, al igual que este protocolo, es enrutable, lo que le permite servir varias LAN. Sólo interactúa con el protocolo IP. Cuando un host desconoce su propia dirección, envía a la red su dirección física y si hay algún host a la escucha que la conozca, le envía al host peticionario su dirección IP. De esta manera, un host que arranca por primera vez, puede automáticamente conocer su dirección en Internet.
! + #*!$ El uso de la multidifusión IP en redes TCP/IP está definido como estándar TCP/IP en RFC 1112, "Internet Group Management Protocol (IGMP)" (Protocolo de administración de grupos de Internet (IGMP)). Además de definir las extensiones de direcciones y hosts para la compatibilidad de los hosts IP con multidifusión, esta RFC también define la versión 1 del Protocolo de administración de grupos de Internet (IGMP). RFC 2236, "Internet Group Management Protocol (IGMP), version 2" (Protocolo de administración de grupos de Internet (IGMP), versión 2) define la versión 2 de IGMP. Ambas versiones de IGMP proporcionan un protocolo para intercambiar y actualizar información acerca de la pertenencia de hosts a grupos de multidifusión específicos. Además, la familia Windows Server 2003 admite IGMP versión 3, descrito en el borrador Internet "Internet Group Management Protocol, version 3" (Protocolo de administración de grupos de Internet, versión 3). Mediante IGPM versión 3, los hosts pueden especificar su interés en recibir tráfico de multidifusión de los orígenes especificados o de todos los orígenes a excepción de un conjunto específico de orígenes. IGMP: â Protocolo que permite a los hosts comunicar su interés, o no, en pertenecer a grupos multicast, dinámicamente. â Este interés se comunica a los routersmulticast que usarán la información para construir o podar árboles de distribución multicast y usarlos en algún algoritmo de encaminamiento multicast. â Los mensajes IGMP van encapsulados dentro de datagramas IP, con número de protocolo IP = 2, TTL = 1 y con la opción IP RouterAlert en la cabecera IP. â Existen 3 versiones incrementales. La más usada es la versión 2. V V V V V V V
IGMP - Versión 1 ,
V
è è
è
Versión = 1 0 si fuese la versión 0 de IGMP (ya obsoleta). Tipo áembershipQuery. áembershipReport. CheckSum 16 bits. Complemento a uno del complemento a uno del mensaje.
V
( + * è è
Contiene la dirección del grupo multicast correspondiente cuando el mensaje es del tipo áembershipReport. Es igual a cero cuando el mensaje es del tipo áembershipQuery.
+ è
El host H que se quiera a un grupo G debe mandar un áembershipReport a la dirección del grupo al que quiere unirse. Ej.: Host 2 quiere unirse al Grupo 1.
*!2 + 6
è è è è è è è
Permite a los routersmulticast saber qué grupos están activos en la subred. El router envía a todos los equipos de la red un áembershipQuery. Esto lo hace cada cierto tiempo. Cuando un host recibe el áembershipQuery pone en marcha un temporizador distinto para cada grupo al que pertenezca. Cuando el temporizador expira, el host envía un áembershipReport al grupo correspondiente al temporizador. La inicialización de los temporizadores es aleatoria y distinta cada vez, siempre por debajo de un tiempo máximo. Si el router no recibe ningún Reportde algún grupo, entonces considera que ese grupo ya no existe. Sólo un host de cada grupo responde al router. Si un host en espera de contestar a una Query escucha un Report de otro host del mismo grupo, interrumpe su temporizador y cancela la respuesta.
%
è
Cuando un host quiere abandonar un grupo simplemente deja de responder como miembro de ese grupo a los mensajes áembershipQuery del router.
Ejemplo: Host C abandona el grupo 2.
/ *! + 6
! è è
QueryInterval. Tiempo que ha de transcurrir entre cada Query del router (Por defecto 125s.). _roupáembershipInterval. Tiempo que ha de transcurrir sin recibir Reports para que el router decida que ya no existen miembros de un determinado grupo.
*!2 + 7 ,
è
è è è
áembershipQuery(=0x11) _eneral Query _roup-SpecificQuery áembershipReportversión 1 (=0x12) áembershipReportversión 2 (=0x16) áembershipLeave_roup(=0x17)
c 8 è è è è
Se usa sólo en mensajes de tipo áembershipQuery. Especifica el valor, en décimas de segundo, que un host debe esperar como máximo para contestar a un áembershipQuery. Por defecto es igual a 100 (10s.). Usada para controlar la expansionabilidad de las respuestas y la latencia.
&/ . è
Igual que en la versión 1.
( + * è è è
0 en mensajes de tipo _eneral Query. Contiene la dirección del grupo multicast en mensajes de tipo _roupSpecificQuery. Contiene la dirección del grupo multicast en mensajes de tipo áembershipReport y áembershipLeave_roup.
%
è è è è è
Unirse a un grupo (igual que en versión 1) Pregunta-Respuesta General (igual que en versión 1) Pregunta-Respuesta Específica Abandonar un grupo Elección del routermulticast
&
+ 6 è
è
è
Hosts versión 2 - routers versión 1 Reports versión 2 son ignorados por lo routers. Los hosts deben mandar Reportsvesión 1 en respuestas a Queries. Hosts versión 1 - routers versión 2 Hosts responden igual a Queries v1 y v2. Los Reports versión 2 no suponen cancelación del temporizador en los hosts versión 1. El proceso de abandono se suspende, puesto que los hosts versión 1 no realizan esta acción y el router la requiere. Routers versión 1 - routers versión 2 Detección automática de routers versión 1. Si existen estos últimos es necesario configurar la versión 1 en todos los routers de la subred.
*!2 + '
Formato de mensajes (Query)
è
è è è è
áembershipQuery(=0x11) _eneral Query _roup-SpecificQuery _roup-and-Source-Specific Query áembershipReportversión 3 (=0x22) áembershipReportversión 1 (=0x12) áembershipReportversión 2 (=0x16) áembership Leave _roup versión 2 (=0x17)
8 c è è
Tiempo máximo permitido antes de enviar un Report. Si >=128 entonces se interpreta como un número en coma flotante, con el primer bit a 1, los tres siguientes el exponente y los restantes la mantisa.
Checksum (igual que en las versiones anteriores)
Dirección de Grupo
è
Igual a 0 en _eneral Queries.
è Dirección de grupo multicast en otras Queries.
c è Campo reservado.
è è
Cuando es igual a 1, indica a los routersmulticast que tienen que suprimir las actualizaciones de los temporizadores cuando escuchen una Query. Si no, elimina la elección del routermulticast.
'c (QuerierRobustness Variable) ''& (Querier¶sQueryIntervalCode) è
Especifica el intervalo del router para mandar Queries.
ü è
Indica el número de fuentes presentes en el mensaje Query.
( + 9: è
Vector de N direcciones IP unicast, indicando las fuentes.
, #c $
(=0x22) &/ . (igual que anteriormente)
ü c * è
Indica el número de registro que contiene el Report.
%
è è
Las propias de las versiones 1 y 2 Unirse a un grupo. Igual que en versiones anteriores, pero el Report se manda a 224.0.0.22, y se pueden especificar fuentes dentro de los grupos a las que unirse.
*!;
è
è
Como una dirección multicast no tiene una dirección MAC conocida, un switch manda los paquetes multicast por todos los puertos, de manera que todos los hosts están recibiendo los paquetes aunque no pertenezcan al grupo destinatario. Esto consume muchos recursos de red. El snooping consiste en que el switch ³fisgonee´ la red. Cuando escucha un mensaje de unirse a un grupo proveniente de un host, almacena la dirección del grupo multicast y el puerto por donde escuchó el mensaje.
è
Luego, cuando le llegue un mensaje dirigido a la dirección de grupo almacenada, lo enviará sólo por los puertos por donde haya escuchado mensajes de unión a ese grupo.
*!;c " è è
Internet Assigned Numbers Authority (IANA): http://www.iana.org Cisco ACSN Software Deployment and Configuration Guide. Appendix B: IP Multicasting. ISBN: 78-14586-01.
*! è è è è
Versión 1: S. Deering. NWG RFC-1112. Appendix I. Stanford University, 1989. Versión 2: W. Fenner. NWG RFC-2236. Xerox PARC, 1997. Versión 3: B. Cain et al. NWG RFC-3376. Cisco Systems, AT&T Labs, Ericsson. October 2002. Recopilación: M. Gibbs. Internet Group Management Protocol. Advanced Technical Paper Series. Riverstone Networks.
&
+ Como conclusión se puede resaltar que cada protocolo tiene objetivos diferentes en la CAPA 3 de RED. El protocolo ICMP es utilizado por TCP para el envío de mensajes de control y de error. Por ejemplo ping se utiliza para ver si un ordenador está activo en la red. El protocolo ARP convierte las direcciones IP en direcciones físicas de la red. Cada host tiene una tabla para realizar dicha conversión.El protocolo ARP es un protocolo estándar específico de las redes. Su status es electivo.El protocolo RARP es mucho menos utilizado. Es un tipo de directorio inverso de direcciones lógicas y físicas y por último el protocolo IGMP es el uso de la multidifusión IP en redes TCP/IP
está definido como estándar TCP/IP en RFC 1112. Además de definir las extensiones de direcciones y hosts para la compatibilidad de los hosts IP con multidifusión, esta RFC también define la versión 1 del Protocolo de administración de grupos de Internet (IGMP).
