The Internet Group Management Protocol (IGMP) is a communications protocol used by hosts and adjacent routers on IPv4 networks to establish multicast group memberships. IGMP is an integral part of IP multicast and allows the network to direct multicast transmissions only to hosts that have requested them.
IGMP can be used for one-to-many networking applications such as online streaming video and gaming, and allows more efficient use of resources when supporting these types of applications.
IGMP is used on IPv4 networks. Multicast management on IPv6 networks is handled by Multicast Listener Discovery (MLD) which is a part of ICMPv6 in contrast to IGMP's bare IP encapsulation.
Architecture
A network designed to deliver a multicast service using IGMP might use this basic architecture:

IGMP operates between a host and a local multicast router. Switches featuring IGMP snooping also derive useful information by observing these IGMP transactions. Protocol Independent Multicast (PIM) is then used between the local and remote multicast routers to direct multicast traffic from hosts sending multicasts to hosts that have registered through IGMP to receive them.
IGMP operates on the network layer (layer 3), just the same as other network management protocols like ICMP.[1]
The IGMP protocol is implemented on hosts and within routers. A host requests membership to a group through its local router while a router listens for these requests and periodically sends out subscription queries. A single router per subnet is elected to perform this querying function. Some multilayer switches include an IGMP querier capability to allow their IGMP snooping features to work in the absence of an IGMP-capable router in the layer 2 network.
IGMP is vulnerable to some attacks,[2][3][4][5] and firewalls commonly allow the user to disable it if not needed.
Versions
There are three versions of IGMP.[6] IGMPv1 was defined in 1989.[7] IGMPv2, defined in 1997,[8] improves IGMPv1 by adding the ability for a host to signal a desire to leave a multicast group.
En 2002, IGMPv3 mejoró IGMPv2 al admitir la multidifusión específica de la fuente [ 9 ] e introdujo la agregación de informes de membresía. [ 10 ] La compatibilidad con la multidifusión específica de la fuente se mejoró en 2006. [ 11 ]
Las tres versiones de IGMP son retrocompatibles. Un enrutador que admite IGMPv3 puede admitir clientes que ejecutan 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 abandonar un grupo y ajusta otros tiempos de espera. Los mensajes de abandono de 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 consultor IGMP para la red. IGMPv3 introduce la capacidad de multidifusión específica de origen . Los informes de membresía se envían a 224.0.0.22 .
Mensajes
Existen varios tipos de mensajes IGMP:
- Consultas generales sobre la membresía
- Enviados por enrutadores de multidifusión para determinar qué direcciones de multidifusión son de interés para los sistemas conectados a la(s) red(es) a la(s) que sirven, con el fin de actualizar el estado de pertenencia al 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 específica.
- Consultas específicas por grupo y fuente
- Permitir 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 asíncrona al registrarse por primera vez en un grupo de multidifusión.
- Dejar mensajes de grupo
- 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 desnudos con el número de protocolo IP 2. [ 10 ] : §4 De forma similar al Protocolo de mensajes de control de Internet , no se utiliza una 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 para las respuestas a una consulta de membresía (0x11). Este campo solo tiene sentido en las 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 mayores reducen la variabilidad del tráfico IGMP y los valores menores mejoran la capacidad de respuesta del protocolo cuando el último host abandona un grupo. [ 8 ] : §2.2
- Suma de verificación : 16 bits
- Este es el complemento a uno de 16 bits de la suma en complemento a uno del mensaje IGMP completo. Se calcula antes del envío, con este campo establecido en cero. Al recalcularse 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 una consulta específica de grupo y origen. El campo se inicializa a cero al enviar una consulta general.
- El mensaje se envía a las siguientes direcciones IP de multidifusión : [ 8 ] : §9
Consulta de membresía IGMPv3
- Tipo : 8 bits
- Indica el tipo de paquete. Un valor de 0x11 indica una consulta de pertenencia a 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 igual o superior a 128, se interpreta como un exponente y una mantisa.
- Suma de verificación : 16 bits
- Este es el complemento a uno de 16 bits de la suma en complemento a uno del mensaje IGMP completo. Se calcula antes del envío, con este campo establecido en cero. Al recalcularse 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 una consulta específica de grupo y origen. El campo se inicializa a cero al enviar una consulta general.
- Reservado : 4 bits
- Este campo está reservado. Debe rellenarse con ceros al enviarlo e ignorarse al recibirlo.
- Suprimir el procesamiento del lado del enrutador (S) : 1 bit
- Cuando se activa este indicador, se les indica a los enrutadores receptores que deben suprimir las actualizaciones normales del temporizador.
- Variable de robustez del consultor (QRV) : 3 bits
- Si este valor no es cero, contiene el valor de la variable de robustez utilizada por 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. QRV establece la tolerancia a la pérdida de paquetes, permitiendo hasta QRV - 1 paquetes perdidos. Cero no es válido, uno no es recomendable; el valor predeterminado es 2.
- Código de intervalo de consulta del consultor (QQIC) : 8 bits
- Este código se utiliza para especificar el valor del intervalo de consulta (en segundos) que utiliza el consultor. Si el número es inferior a 128, se utiliza directamente. Si el valor es igual o superior a 128, se interpreta como un exponente y una 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 es distinto de 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 IP unicast, donde n es el valor en el campo Número de fuentes (N).
Informe de membresía de IGMPv3
- Tipo : 8 bits
- Indica el tipo de paquete. Un valor de 0x22 indica un informe de membresía IGMPv3 .
- Suma de verificación : 16 bits
- Este es el complemento a uno de 16 bits de la suma en complemento a uno del mensaje IGMP completo. Se calcula antes del envío, con este campo establecido en cero. Al recalcularse al recibir el paquete, se incluye este campo y el resultado debe ser cero.
- Número de registros de grupo (M) : 16 bits
- Este campo especifica el número de registros de grupo presentes en el informe.
- Registro de grupo [ i ] : Variable
- Cada registro de grupo es un bloque de campos que contiene información relativa a la pertenencia del remitente a un único grupo de multidifusión en la interfaz desde la que se envía el informe.
- Tipo de registro : 8 bits
- Indica el tipo de registro.
- Longitud de datos auxiliares : 8 bits
- Este campo contiene la longitud del campo de Datos Auxiliares en este registro, en unidades de palabras de 32 bits. Puede contener cero para indicar la ausencia de datos auxiliares.
- Número de fuentes (N) : 16 bits
- Este campo especifica el número de direcciones de origen presentes en el registro del grupo.
- Dirección de origen [ i ] : 32 bits
- Los campos Dirección de origen [ i ] son un vector de n direcciones IP unicast, donde n es el valor en el campo Número de fuentes (N).
- Datos auxiliares : Variable
- Este campo, si está presente, contiene información adicional relativa a este registro de grupo. No se utiliza en el estándar IGMPv3.
Implementaciones
FreeBSD , [ nota 1 ] Linux [ nota 2 ] y Windows admiten IGMP en el lado del host.
Véase también
Notas
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 mediante informe IGMP falsificado
- ↑ "Un paquete IGMP fragmentado puede facilitar un ataque de denegación de servicio" . 20 de diciembre de 2004. Archivado del original el 13 de febrero de 2005.
- ↑ Declaración del problema de seguridad y requisitos de IGMP Archivados el 13/10/2006 en Wayback Machine .
- ↑ "Vulnerabilidad en TCP/IP podría permitir un ataque de denegación de servicio (MS06-007, 913446)" . Microsoft . 14 de febrero de 2006. Archivado del original el 5 de febrero de 2007.
- ↑ Guía de configuración de enrutamiento multicast 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 .Internet Standard 5. Obsoletes RFC 988 and 1054. Updated by RFC 2236.
- 1234W. Fenner (November 1997). Internet Group Management Protocol, Version 2. Network Working Group. doi:10.17487/RFC2236. RFC2236.Proposed Standard. Updates RFC 1112. Updated by RFC 3376 and 9776.
- ↑"Internet Group Management Protocol Overview". Javvin. Archived from the original on 2010-11-10. Retrieved 2010-11-18.
- 12345B. Cain; S. Deering; I. Kouvelas; B. Fenner; A. Thyagarajan (October 2002). Internet Group Management Protocol, Version 3. Network Working Group. doi:10.17487/RFC3376. RFC3376.Obsolete. Obsoleted by RFC 9776. Updates RFC 2236. Updated by RFC 4604.
- ↑H. Holbrook; B. Cain; B. Haberman (August 2006). Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific Multicast. Network Working Group. doi:10.17487/RFC4604. RFC4604.Proposed Standard. Updates RFC 3376 and 3810.
- Internet protocols
- Internet Standards
- Internet layer protocols
- Network layer protocols