Protocolo para establecer membresías de grupos de multidifusión en redes IPv4
El Protocolo de administración de grupos de Internet ( IGMP ) es un protocolo de comunicaciones que utilizan los hosts y los enrutadores adyacentes en redes IPv4 para establecer membresías de grupos de multidifusión. IGMP es una parte integral de la multidifusión IP y permite que la red dirija transmisiones de multidifusión solo a los hosts que las hayan solicitado.
IGMP se puede utilizar para aplicaciones de redes de uno a muchos, como transmisión de video y juegos en línea , y permite un uso más eficiente de los recursos al admitir este tipo de aplicaciones.
IGMP se utiliza en redes IPv4 . La gestión de multidifusión en redes IPv6 se realiza mediante Multicast Listener Discovery (MLD), que es parte de ICMPv6 en contraste con la encapsulación IP simple de IGMP.
Arquitectura
Una red diseñada para ofrecer un servicio de multidifusión mediante IGMP podría utilizar esta arquitectura básica:
IGMP opera entre un host y un enrutador de multidifusión local. Los conmutadores que cuentan con vigilancia IGMP también obtienen información útil al observar estas transacciones IGMP. Luego, se utiliza la multidifusión independiente del protocolo (PIM) entre los enrutadores de multidifusión locales y remotos para dirigir el tráfico de multidifusión desde los host que envían multidifusiones a los host que se han registrado a través de IGMP para recibirlas.
IGMP opera en la capa de red (capa 3), al igual que otros protocolos de gestión de red como ICMP . [1]
El protocolo IGMP se implementa en hosts y en enrutadores . Un host solicita la membresía a un grupo a través de su enrutador local mientras un enrutador escucha estas solicitudes y envía consultas de suscripción periódicamente. Se elige un solo enrutador por subred para realizar esta función de consulta. Algunos conmutadores multicapa incluyen una capacidad de consulta IGMP para permitir que sus funciones de espionaje IGMP funcionen en ausencia de un enrutador con capacidad IGMP en la red de capa 2.
IGMP es vulnerable a algunos ataques, [2] [3] [4] [5] y los firewalls comúnmente permiten al usuario desactivarlo si no es necesario.
Versiones
Hay tres versiones de IGMP. [6]
IGMPv1 se definió en 1989. [7] IGMPv2, definido en 1997, [8] mejora IGMPv1 al agregar la capacidad de que un host indique su deseo de abandonar un grupo de multidifusión.
En 2002, IGMPv3 mejoró IGMPv2 al admitir multidifusión específica de la fuente [9] e introdujo la agregación de informes de membresía. [10] El soporte para multidifusión específica de la fuente se mejoró en 2006. [11]
Las tres versiones de IGMP son compatibles con versiones anteriores. Un enrutador que admita IGMPv3 puede admitir clientes que ejecuten IGMPv1, IGMPv2 e IGMPv3. IGMPv1 utiliza un modelo de consulta-respuesta. Las consultas se envían a 224.0.0.1 . Los informes de membresía se envían a la dirección de multidifusión del grupo. IGMPv2 acelera el proceso de abandono de un grupo y ajusta otros tiempos de espera. Los mensajes de abandono del grupo se envían a 224.0.0.2 . Se introduce una consulta específica del grupo. Las consultas específicas del grupo se envían a la dirección de multidifusión del grupo. Se introduce un medio para que los enrutadores seleccionen un interrogador IGMP para la red. IGMPv3 introduce la capacidad de multidifusión específica de la fuente . Los informes de membresía se envían a 224.0.0.22 .
Mensajes
Hay varios tipos de mensajes IGMP:
- Consultas generales sobre membresía
- Enviado por enrutadores de multidifusión para determinar qué direcciones de multidifusión son de interés para los sistemas conectados a las redes a las que sirven para actualizar el estado de membresía del grupo para todos los sistemas en su red.
- Consultas de membresía específicas del grupo
- Se utiliza para determinar el estado de recepción de una dirección de multidifusión particular.
- Consultas específicas de grupos y fuentes
- Permite que el enrutador determine si algún sistema desea recibir mensajes enviados a un grupo de multidifusión desde una dirección de origen especificada en una lista de direcciones de unidifusión.
- Informes de membresía
- Enviado por receptores de multidifusión en respuesta a una consulta de membresía o de forma asincrónica cuando se registra por primera vez en un grupo de multidifusión.
- Dejar mensajes grupales
- Enviado por receptores de multidifusión cuando las transmisiones de multidifusión especificadas ya no son necesarias en el receptor.
Los mensajes IGMP se transportan en paquetes IP simples con el número de protocolo IP 2. [10] : §4 De manera similar al Protocolo de mensajes de control de Internet , no se utiliza ninguna capa de transporte con la mensajería IGMP.
Mensajes IGMPv2
- Tipo: 8 bits
- Indica el tipo de mensaje de la siguiente manera:
- Tiempo máximo de respuesta: 8 bits
- Especifica la capacidad de respuesta requerida de las respuestas a una consulta de membresía (0x11). Este campo solo tiene sentido en consultas de membresía; en otros mensajes, se establece en 0 y el receptor lo ignora. El campo especifica el tiempo en unidades de 0,1 segundos (un valor de campo de 10 especifica 1 segundo). Los valores más altos reducen la ráfaga de tráfico IGMP y los valores más bajos mejoran la capacidad de respuesta del protocolo cuando el último host abandona un grupo. [8] : §2.2
- Suma de comprobación : 16 bits
- Este es el complemento a uno de 16 bits de la suma del complemento a uno del mensaje IGMP completo. Se calcula antes del envío, con este campo establecido en cero. Cuando se vuelve a calcular al recibir el paquete, se incluye este campo y el resultado debe ser cero.
- Dirección de grupo: 32 bits
- Esta es la dirección de multidifusión que se consulta al enviar una consulta específica de grupo o de grupo y origen. El campo se pone a cero cuando se envía una consulta general.
- El mensaje se envía a las siguientes direcciones de multidifusión IP : [8] : §9
Consulta de membresía IGMPv3
- Tipo: 8 bits
- Indica el tipo de paquete. Un valor de 0x11 indica una consulta de membresía de IGMPv3 .
- Código de respuesta máximo: 8 bits
- Este campo se utiliza para calcular el tiempo máximo de respuesta (en incrementos de 1/10 de segundo) permitido antes de enviar un informe de respuesta. Si el número es inferior a 128, el valor se utiliza directamente. Si el valor es 128 o más, se interpreta como exponente y mantisa.
- Suma de comprobación : 16 bits
- Este es el complemento a uno de 16 bits de la suma del complemento a uno del mensaje IGMP completo. Se calcula antes del envío, con este campo establecido en cero. Cuando se vuelve a calcular al recibir el paquete, se incluye este campo y el resultado debe ser cero.
- Dirección de grupo: 32 bits
- Esta es la dirección de multidifusión que se consulta al enviar una consulta específica de grupo o de grupo y origen. El campo se pone a cero cuando se envía una consulta general.
- Reservado: 4 bits
- Este campo está reservado. Debe ponerse a cero al enviarse y debe ignorarse al recibirse.
- Suprimir procesamiento del lado del enrutador (S): 1 bit
- Cuando se establece esta bandera, indica a los enrutadores receptores que deben suprimir las actualizaciones normales del temporizador.
- Variable de robustez del consultante (QRV): 3 bits
- Si no es cero, contiene el valor de la variable de robustez que utilizó el remitente de la consulta. Los enrutadores deben actualizar su variable de robustez para que coincida con la consulta recibida más recientemente, a menos que el valor sea cero.
- Código de intervalo de consulta del consultante (QQIC): 8 bits
- Este código se utiliza para especificar el valor del intervalo de consulta (en segundos) que utiliza el consultante. Si el número es inferior a 128, el valor se utiliza directamente. Si el valor es 128 o más, se interpreta como exponente y mantisa.
- Número de fuentes (N): 16 bits
- Este campo especifica la cantidad de direcciones de origen presentes en la consulta. Para consultas generales y específicas de grupo, este valor es cero. Para consultas específicas de grupo y origen, este valor no es cero, pero está limitado por la MTU de la red.
- Dirección de origen [i]: 32 bits
- Los campos Dirección de origen [i] son un vector de n direcciones de unidifusión IP, donde n es el valor en el campo Número de fuentes (N).
Implementaciones
FreeBSD , [nota 1] Linux [nota 2] y Windows admiten IGMP en el lado del host.
Véase también
Notas
- ^ IGMPv3 se agregó a FreeBSD en la versión 8.0.
- ^ IGMPv3 se agregó en la serie de kernel Linux 2.5.
Referencias
- ^ Forouzan, Behrouz A. (2012). Comunicaciones de datos y redes (5.ª ed.). Nueva York, NY: McGraw-Hill. pág. 658. ISBN 978-0073376226.
- ^ Vulnerabilidad de denegación de servicio en informe IGMP falsificado.
- ^ "Un paquete IGMP fragmentado puede promover un ataque de "denegación de servicio"". 20 de diciembre de 2004. Archivado desde el original el 13 de febrero de 2005.
- ^ Declaración de problemas y requisitos de seguridad de IGMP Archivado el 13 de octubre de 2006 en Wayback Machine .
- ^ "Vulnerabilidad en TCP/IP podría permitir denegación de servicio (MS06-007, 913446))". 14 de febrero de 2006. Archivado desde el original el 5 de febrero de 2007.
- ^ Guía de configuración de enrutamiento de multidifusión IP, Cisco , págs. 25-28 , consultado el 27 de mayo de 2017
- ^ S. Deering (agosto de 1989). Extensiones de host para multidifusión IP. Grupo de trabajo de redes. doi : 10.17487/RFC1112 . STD 5. RFC 1112. Estándar de Internet 5. Deja obsoletos los RFC 988 y 1054. Actualizado por el RFC 2236.
- ^ abcd W. Fenner (noviembre de 1997). Protocolo de gestión de grupos de Internet, versión 2. Grupo de trabajo de redes. doi : 10.17487/RFC2236 . RFC 2236. Norma propuesta. Actualizaciones RFC 1112. Actualizado por RFC 3376.
- ^ "Descripción general del protocolo de administración de grupos de Internet". Javvin. Archivado desde el original el 10 de noviembre de 2010. Consultado el 18 de noviembre de 2010 .
- ^ abc B. Cain; S. Deering ; I. Kouvelas; B. Fenner; A. Thyagarajan (octubre de 2002). Protocolo de gestión de grupos de Internet, versión 3. Grupo de trabajo de redes. doi : 10.17487/RFC3376 . RFC 3376. Norma propuesta. Actualizaciones RFC 2236. Actualizado por RFC 4604.
- ^ H. Holbrook; B. Cain; B. Haberman (agosto de 2006). Uso del Protocolo de administración de grupos de Internet versión 3 (IGMPv3) y del Protocolo de descubrimiento de escucha de multidifusión versión 2 (MLDv2) para multidifusión específica de origen. Grupo de trabajo de redes. doi : 10.17487/RFC4604 . RFC 4604. Norma propuesta. Actualizaciones RFC 3376 y 3810.