Passa al contenuto principale

RFC 3376 - Internet Group Management Protocol, Version 3 (Protocollo di gestione dei gruppi Internet, versione 3)

Status of this Memo (Stato di questo promemoria)​

Questo documento specifica un protocollo di standard Internet per la comunità Internet e richiede discussioni e suggerimenti per miglioramenti. Fare riferimento all'edizione corrente degli "Standard ufficiali del protocollo Internet" (STD 1) per lo stato di standardizzazione e lo stato di questo protocollo. La distribuzione di questo promemoria è illimitata.

Abstract (Sommario)​

Questo documento specifica la versione 3 dell'Internet Group Management Protocol, IGMPv3. IGMP è il protocollo utilizzato dai sistemi IPv4 per segnalare le proprie appartenenze ai gruppi multicast IP ai router multicast vicini. La versione 3 di IGMP aggiunge il supporto per il "filtraggio della sorgente" (source filtering), ovvero la capacità di un sistema di segnalare l'interesse a ricevere pacchetti solo da specifici indirizzi sorgente, o da tutti tranne specifici indirizzi sorgente, inviati a un particolare indirizzo multicast. Tali informazioni possono essere utilizzate dai protocolli di instradamento multicast per evitare di consegnare pacchetti multicast da sorgenti specifiche a reti in cui non ci sono ricevitori interessati.

Contents (Contenuti)​

1. Introduction (Introduzione)​

L'Internet Group Management Protocol (IGMP) viene utilizzato dai sistemi IPv4 (host e router) per segnalare le proprie appartenenze ai gruppi multicast IP a qualsiasi router multicast vicino. Si noti che un router multicast IP può essere esso stesso membro di uno o più gruppi multicast, nel qual caso esegue sia la "parte router multicast" del protocollo (per raccogliere le informazioni di appartenenza necessarie al suo protocollo di instradamento multicast) sia la "parte membro del gruppo" del protocollo (per informare se stesso e altri router multicast vicini delle sue appartenenze).

IGMP viene utilizzato anche per altre funzioni di gestione multicast IP, utilizzando tipi di messaggi diversi da quelli utilizzati per la segnalazione dell'appartenenza al gruppo. Questo documento specifica solo le funzioni e i messaggi di segnalazione dell'appartenance al gruppo.

Questo documento specifica la versione 3 di IGMP. La versione 1, specificata in [RFC-1112], è stata la prima versione ampiamente diffusa e la prima versione a diventare uno standard Internet. La versione 2, specificata in [RFC-2236], ha aggiunto il supporto per la "bassa latenza di abbandono" (low leave latency), ovvero una riduzione del tempo impiegato da un router multicast per apprendere che non ci sono più membri di un particolare gruppo presenti su una rete collegata. La versione 3 aggiunge il supporto per il "filtraggio della sorgente" (source filtering), ovvero la capacità di un sistema di segnalare l'interesse a ricevere pacchetti solo da specifici indirizzi sorgente, come richiesto per supportare il Multicast specifico della sorgente [SSM], o da tutti tranne specifici indirizzi sorgente, inviati a un particolare indirizzo multicast. La versione 3 è progettata per essere interoperabile con le versioni 1 e 2.

Il Multicast Listener Discovery (MLD) viene utilizzato in modo simile dai sistemi IPv6. MLD versione 1 [MLD] implementa la funzionalità di IGMP versione 2; MLD versione 2 [MLDv2] implementa la funzionalità di IGMP versione 3.

Le parole chiave maiuscole "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" e "OPTIONAL" in questo documento devono essere interpretate come descritto in [RFC-2119]. A causa della mancanza di corsivo, l'enfasi è indicata qui racchiudendo una parola o una frase tra caratteri "*".

2. The Service Interface for Requesting IP Multicast Reception (L'interfaccia di servizio per richiedere la ricezione multicast IP)​

All'interno di un sistema IP, esiste (almeno concettualmente) un'interfaccia di servizio utilizzata dai protocolli di livello superiore o dai programmi applicativi per chiedere al livello IP di abilitare e disabilitare la ricezione dei pacchetti inviati a specifici indirizzi multicast IP. Per sfruttare appieno le capacità di IGMPv3, l'interfaccia di servizio IP di un sistema deve supportare la seguente operazione:

IPMulticastListen ( socket, interface, multicast-address,
                    filter-mode, source-list )

  • "socket" è un parametro specifico dell'implementazione utilizzato per distinguere tra diverse entità richiedenti (ad esempio, programmi o processi) all'interno del sistema; il parametro socket delle chiamate di sistema BSD Unix è un esempio specifico.

  • "interface" è un identificatore locale dell'interfaccia di rete su cui deve essere abilitata o disabilitata la ricezione dell'indirizzo multicast specificato. Le interfacce possono essere fisiche (ad esempio, un'interfaccia Ethernet) o virtuali (ad esempio, l'endpoint di un circuito virtuale Frame Relay o l'endpoint di un "tunnel" IP-in-IP). Un'implementazione può consentire il passaggio di un valore speciale "non specificato" come parametro di interfaccia, nel qual caso la richiesta si applicherebbe all'interfaccia "primaria" o "predefinita" del sistema (forse stabilita dalla configurazione del sistema). Se si desidera la ricezione dello stesso indirizzo multicast su più di un'interfaccia, IPMulticastListen viene richiamato separatamente per ciascuna interfaccia desiderata.

  • "multicast-address" è l'indirizzo multicast IP, o gruppo, a cui si riferisce la richiesta. Se si desidera la ricezione di più di un indirizzo multicast su una determinata interfaccia, IPMulticastListen viene richiamato separatamente per ciascun indirizzo multicast desiderato.

  • "filter-mode" può essere INCLUDE o EXCLUDE. In modalità INCLUDE, la ricezione dei pacchetti inviati all'indirizzo multicast specificato è richiesta solo dagli indirizzi IP di origine elencati nel parametro source-list. In modalità EXCLUDE, la ricezione dei pacchetti inviati all'indirizzo multicast specificato è richiesta da tutti gli indirizzi IP di origine tranne quelli elencati nel parametro source-list.

  • "source-list" è un elenco non ordinato di zero o più indirizzi IP unicast da cui la ricezione multicast è desiderata o non desiderata, a seconda della modalità filtro. Un'implementazione PUÒ imporre un limite alla dimensione degli elenchi di sorgenti, ma tale limite NON DEVE essere inferiore a 64 indirizzi per elenco. Quando un'operazione provoca il superamento del limite di dimensione dell'elenco di sorgenti, l'interfaccia di servizio DEVE restituire un errore.

Per una data combinazione di socket, interfaccia e indirizzo multicast, possono essere attivi solo una singola modalità filtro e un elenco di sorgenti alla volta. Tuttavia, la modalità filtro o l'elenco di sorgenti, o entrambi, possono essere modificati da successive richieste IPMulticastListen che specificano lo stesso socket, interfaccia e indirizzo multicast. Ogni richiesta successiva sostituisce completamente qualsiasi richiesta precedente per il dato socket, interfaccia e indirizzo multicast.

Le versioni precedenti di IGMP non supportavano i filtri sorgente e avevano un'interfaccia di servizio più semplice costituita da operazioni Join e Leave per abilitare e disabilitare la ricezione di un dato indirizzo multicast (da tutte le sorgenti) su una data interfaccia. Le operazioni equivalenti nella nuova interfaccia di servizio seguono:

The Join operation is equivalent to

L'operazione Join è equivalente a

IPMulticastListen ( socket, interface, multicast-address,
                    EXCLUDE, {} )

e l'operazione Leave è equivalente a:

IPMulticastListen ( socket, interface, multicast-address,
                    INCLUDE, {} )

dove {} è un elenco di sorgenti vuoto.

Un esempio di API che fornisce le funzionalità descritte in questa interfaccia di servizio si trova in [FILTER-API].

3. Multicast Reception State Maintained by Systems (Stato di ricezione multicast mantenuto dai sistemi)​

3.1. Socket State (Stato del socket)​

Per ogni socket su cui è stato invocato IPMulticastListen, il sistema registra lo stato di ricezione multicast desiderato per quel socket. Tale stato consiste concettualmente in un insieme di record della forma:

(interface, multicast-address, filter-mode, source-list)

Lo stato del socket evolve in risposta a ogni invocazione di IPMulticastListen sul socket, come segue:

  • Se la modalità filtro richiesta è INCLUDE e l'elenco di sorgenti richiesto è vuoto, la voce corrispondente all'interfaccia e all'indirizzo multicast richiesti viene eliminata se presente. Se non è presente tale voce, la richiesta viene ignorata.

  • Se la modalità filtro richiesta è EXCLUDE o l'elenco di sorgenti richiesto non è vuoto, la voce corrispondente all'interfaccia e all'indirizzo multicast richiesti, se presente, viene modificata per contenere la modalità filtro e l'elenco di sorgenti richiesti. Se non è presente tale voce, viene creata una nuova voce, utilizzando i parametri specificati nella richiesta.

3.2. Interface State (Stato dell'interfaccia)​

Oltre allo stato di ricezione multicast per socket, un sistema deve anche mantenere o calcolare lo stato di ricezione multicast per ciascuna delle sue interfacce. Tale stato consiste concettualmente in un insieme di record della forma:

(multicast-address, filter-mode, source-list)

Esiste al massimo un record per indirizzo multicast per una data interfaccia. Questo stato per interfaccia è derivato dallo stato per socket, ma può differire dallo stato per socket quando socket diversi hanno modalità filtro e/o elenchi di sorgenti diversi per lo stesso indirizzo multicast e la stessa interfaccia. Ad esempio, supponiamo che un'applicazione o un processo invochi la seguente operazione sul socket s1:

IPMulticastListen ( s1, i, m, INCLUDE, {a, b, c} )

richiedendo la ricezione sull'interfaccia i dei pacchetti inviati all'indirizzo multicast m, solo se provengono dalla sorgente a, b o c. Supponiamo che un'altra applicazione o processo invochi la seguente operazione sul socket s2:

IPMulticastListen ( s2, i, m, INCLUDE, {b, c, d} )

richiedendo la ricezione sulla stessa interfaccia i dei pacchetti inviati allo stesso indirizzo multicast m, solo se provengono dalle sorgenti b, c o d. Per soddisfare i requisiti di ricezione di entrambi i socket, è necessario che l'interfaccia i riceva i pacchetti inviati a m da una qualsiasi delle sorgenti a, b, c o d. Pertanto, in questo esempio, lo stato di ricezione dell'interfaccia i per l'indirizzo multicast m ha modalità filtro INCLUDE ed elenco sorgenti {a, b, c, d}.

Dopo che un pacchetto multicast è stato accettato da un'interfaccia dal livello IP, la sua successiva consegna all'applicazione o al processo in ascolto su un particolare socket dipende dallo stato di ricezione multicast di quel socket [e possibilmente anche da altre condizioni, come a quale porta del livello di trasporto è associato il socket]. Quindi, nell'esempio sopra, se un pacchetto arriva sull'interfaccia i, destinato all'indirizzo multicast m, con indirizzo sorgente a, verrà consegnato sul socket s1 ma non sul socket s2. Si noti che le query e i report IGMP non sono soggetti al filtraggio della sorgente e devono essere sempre elaborati da host e router.

Il filtraggio dei pacchetti in base allo stato di ricezione multicast di un socket è una nuova funzionalità di questa interfaccia di servizio. La precedente interfaccia di servizio [RFC1112] non descriveva alcun filtraggio basato sullo stato di unione multicast; piuttosto, un'unione su un socket faceva semplicemente sì che l'host si unisse a un gruppo sulla data interfaccia e i pacchetti destinati a quel gruppo potevano essere consegnati a tutti i socket, indipendentemente dal fatto che si fossero uniti o meno.

Le regole generali per derivare lo stato per interfaccia dallo stato per socket sono le seguenti: Per ogni coppia distinta (interfaccia, indirizzo multicast) che appare in qualsiasi stato del socket, viene creato un record per interfaccia per quell'indirizzo multicast su quell'interfaccia. Considerando tutti i record del socket contenenti la stessa coppia (interfaccia, indirizzo multicast),

  • se uno qualsiasi di tali record ha una modalità filtro EXCLUDE, allora la modalità filtro del record di interfaccia è EXCLUDE e l'elenco di sorgenti del record di interfaccia è l'intersezione degli elenchi di sorgenti di tutti i record del socket in modalità EXCLUDE, meno quegli indirizzi di sorgente che appaiono in qualsiasi record del socket in modalità INCLUDE. Ad esempio, se i record del socket per l'indirizzo multicast m sull'interfaccia i sono:
from socket s1:  ( i, m, EXCLUDE, {a, b, c, d} )
from socket s2:  ( i, m, EXCLUDE, {b, c, d, e} )
from socket s3:  ( i, m, INCLUDE, {d, e, f} )

allora il record di interfaccia corrispondente sull'interfaccia i è:

( m, EXCLUDE, {b, c} )

Se viene aggiunto un quarto socket, come:

from socket s4:  ( i, m, EXCLUDE, {} )

allora il record di interfaccia diventa:

( m, EXCLUDE, {} )
  • se tutti tali record hanno una modalità filtro INCLUDE, allora la modalità filtro del record di interfaccia è INCLUDE e l'elenco di sorgenti del record di interfaccia è l'unione degli elenchi di sorgenti di tutti i record del socket. Ad esempio, se i record del socket per l'indirizzo multicast m sull'interfaccia i sono:
from socket s1:  ( i, m, INCLUDE, {a, b, c} )
from socket s2:  ( i, m, INCLUDE, {b, c, d} )
from socket s3:  ( i, m, INCLUDE, {e, f} )

allora il record di interfaccia corrispondente sull'interfaccia i è:

( m, INCLUDE, {a, b, c, d, e, f} )

Un'implementazione NON DEVE utilizzare un record di interfaccia EXCLUDE per rappresentare un gruppo quando tutti i socket per questo gruppo sono nello stato INCLUDE. Se i limiti delle risorse di sistema vengono raggiunti quando viene calcolato un elenco di sorgenti dello stato dell'interfaccia, DEVE essere restituito un errore all'applicazione che ha richiesto l'operazione.

Le regole di cui sopra per derivare lo stato dell'interfaccia vengono (ri)valutate ogni volta che un'invocazione IPMulticastListen modifica lo stato del socket aggiungendo, eliminando o modificando un record di stato per socket. Si noti che una modifica dello stato del socket non comporta necessariamente una modifica dello stato dell'interfaccia.

4. Formati dei messaggi​

I messaggi IGMP sono incapsulati in datagrammi IPv4, con un numero di protocollo IP di 2. Ogni messaggio IGMP descritto in questo documento viene inviato con un IP Time-to-Live di 1, IP Precedence di Internetwork Control (ad esempio, Type of Service 0xc0), e porta un'opzione IP Router Alert [RFC-2113] nel suo header IP. I tipi di messaggi IGMP sono registrati dall'IANA [IANA-REG] come descritto da [RFC-3228].

Ci sono due tipi di messaggi IGMP di interesse per il protocollo IGMPv3 descritto in questo documento:

Type Number (hex)Message Name
0x11Membership Query
0x22Version 3 Membership Report

Un'implementazione di IGMPv3 DEVE anche supportare i seguenti tre tipi di messaggi, per l'interoperazione con le versioni precedenti di IGMP (vedi sezione 7):

Type Number (hex)Message NameReference
0x12Version 1 Membership Report[RFC-1112]
0x16Version 2 Membership Report[RFC-2236]
0x17Version 2 Leave Group[RFC-2236]

I tipi di messaggi non riconosciuti DEVONO essere ignorati silenziosamente. Altri tipi di messaggi possono essere utilizzati da versioni più recenti o estensioni di IGMP, da protocolli di routing multicast, o per altri usi.

In questo documento, salvo diversa specificazione, le parole maiuscole "Query" e "Report" si riferiscono rispettivamente a IGMP Membership Queries e IGMP Version 3 Membership Reports.

4.1. Messaggio Membership Query​

I Membership Queries sono inviati dai router multicast IP per interrogare lo stato di ricezione multicast delle interfacce vicine. I Queries hanno il seguente formato:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Type = 0x11  | Max Resp Code |           Checksum            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Group Address                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Resv  |S| QRV |     QQIC      |     Number of Sources (N)     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Source Address [1]                      |
   +-                                                             -+
   |                       Source Address [2]                      |
   +-                              .                              -+
   .                               .                               .
   .                               .                               .
   +-                                                             -+
   |                       Source Address [N]                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4.1.1. Max Resp Code​

Il campo Max Resp Code specifica il tempo massimo consentito prima dell'invio di un report di risposta. Il tempo effettivamente consentito, chiamato Max Resp Time, è rappresentato in unità di 1/10 di secondo ed è derivato dal Max Resp Code come segue:

Se Max Resp Code < 128, Max Resp Time = Max Resp Code

Se Max Resp Code >= 128, Max Resp Code rappresenta un valore in virgola mobile come segue:

    0 1 2 3 4 5 6 7
   +-+-+-+-+-+-+-+-+
   |1| exp | mant  |
   +-+-+-+-+-+-+-+-+

Max Resp Time = (mant | 0x10) << (exp + 3)

Valori piccoli di Max Resp Time consentono ai router IGMPv3 di regolare la "latenza di abbandono" (il tempo tra il momento in cui l'ultimo host lascia un gruppo e il momento in cui il protocollo di routing viene notificato che non ci sono più membri). Valori più grandi, specialmente nell'intervallo esponenziale, consentono la regolazione dell'esplosività del traffico IGMP su una rete.

4.1.2. Checksum​

Il Checksum è il complemento a uno a 16 bit della somma in complemento a uno dell'intero messaggio IGMP (l'intero payload IP). Per calcolare il checksum, il campo Checksum è impostato a zero. Quando si ricevono pacchetti, il checksum DEVE essere verificato prima di elaborare un pacchetto. [RFC-1071]

4.1.3. Group Address​

Il campo Group Address è impostato a zero quando si invia una General Query, e impostato all'indirizzo multicast IP interrogato quando si invia una Group-Specific Query o Group-and-Source-Specific Query (vedi sezione 4.1.9, di seguito).

4.1.4. Resv (Reserved)​

Il campo Resv è impostato a zero in trasmissione, e ignorato in ricezione.

4.1.5. S Flag (Suppress Router-Side Processing)​

Quando impostato a uno, l'S Flag indica a tutti i router multicast riceventi che devono sopprimere gli aggiornamenti normali del timer che eseguono all'ascolto di una Query. Non sopprime, tuttavia, l'elezione del querier o l'elaborazione normale "lato host" di una Query che un router potrebbe essere tenuto a eseguire come conseguenza dell'essere esso stesso un membro del gruppo.

4.1.6. QRV (Querier's Robustness Variable)​

Se diverso da zero, il campo QRV contiene il valore [Robustness Variable] utilizzato dal querier, cioè il mittente della Query. Se la [Robustness Variable] del querier supera 7, il valore massimo del campo QRV, il QRV è impostato a zero. I router adottano il valore QRV dalla Query ricevuta più di recente come proprio valore [Robustness Variable], a meno che quel QRV ricevuto più di recente non fosse zero, nel qual caso i ricevitori utilizzano il valore [Robustness Variable] predefinito specificato nella sezione 8.1 o un valore configurato staticamente.

4.1.7. QQIC (Querier's Query Interval Code)​

Il campo Querier's Query Interval Code specifica il [Query Interval] utilizzato dal querier. L'intervallo effettivo, chiamato Querier's Query Interval (QQI), è rappresentato in unità di secondi ed è derivato dal Querier's Query Interval Code come segue:

Se QQIC < 128, QQI = QQIC

Se QQIC >= 128, QQIC rappresenta un valore in virgola mobile come segue:

    0 1 2 3 4 5 6 7
   +-+-+-+-+-+-+-+-+
   |1| exp | mant  |
   +-+-+-+-+-+-+-+-+

QQI = (mant | 0x10) << (exp + 3)

I router multicast che non sono il querier corrente adottano il valore QQI dalla Query ricevuta più di recente come proprio valore [Query Interval], a meno che quel QQI ricevuto più di recente non fosse zero, nel qual caso i router riceventi utilizzano il valore [Query Interval] predefinito specificato nella sezione 8.2.

4.1.8. Number of Sources (N)​

Il campo Number of Sources (N) specifica quanti indirizzi sorgente sono presenti nella Query. Questo numero è zero in una General Query o una Group-Specific Query, e diverso da zero in una Group-and-Source-Specific Query. Questo numero è limitato dalla MTU della rete su cui viene trasmessa la Query. Ad esempio, su un Ethernet con una MTU di 1500 ottetti, l'header IP inclusa l'opzione Router Alert consuma 24 ottetti, e i campi IGMP fino al campo Number of Sources (N) incluso consumano 12 ottetti, lasciando 1464 ottetti per gli indirizzi sorgente, il che limita il numero di indirizzi sorgente a 366 (1464/4).

4.1.9. Source Address [i]​

I campi Source Address [i] sono un vettore di n indirizzi unicast IP, dove n è il valore nel campo Number of Sources (N).

4.1.10. Additional Data​

Se il campo Packet Length nell'header IP di una Query ricevuta indica che ci sono ottetti di dati aggiuntivi presenti, oltre ai campi descritti qui, le implementazioni IGMPv3 DEVONO includere quegli ottetti nel calcolo per verificare il Checksum IGMP ricevuto, ma DEVONO altrimenti ignorare quegli ottetti aggiuntivi. Quando si invia una Query, un'implementazione IGMPv3 NON DEVE includere ottetti aggiuntivi oltre ai campi descritti qui.

4.1.11. Varianti di Query​

  1. Una "General Query" è inviata da un router multicast per conoscere lo stato completo di ricezione multicast delle interfacce vicine (cioè, le interfacce collegate alla rete su cui viene trasmessa la Query). In una General Query, sia il campo Group Address che il campo Number of Sources (N) sono zero.

  2. Una "Group-Specific Query" è inviata da un router multicast per conoscere lo stato di ricezione, rispetto a un singolo indirizzo multicast, delle interfacce vicine. In una Group-Specific Query, il campo Group Address contiene l'indirizzo multicast di interesse, e il campo Number of Sources (N) contiene zero.

  3. Una "Group-and-Source-Specific Query" è inviata da un router multicast per sapere se un'interfaccia vicina desidera la ricezione di pacchetti inviati a un indirizzo multicast specificato, da una qualsiasi delle sorgenti di un elenco specificato. In una Group-and-Source-Specific Query, il campo Group Address contiene l'indirizzo multicast di interesse, e i campi Source Address [i] contengono gli indirizzi sorgente di interesse.

4.1.12. Indirizzi di destinazione IP per le Queries​

In IGMPv3, le General Queries sono inviate con un indirizzo di destinazione IP di 224.0.0.1, l'indirizzo multicast all-systems. Le Group-Specific e Group-and-Source-Specific Queries sono inviate con un indirizzo di destinazione IP uguale all'indirizzo multicast di interesse. Tuttavia, un sistema DEVE accettare ed elaborare qualsiasi Query il cui campo IP Destination Address contenga uno qualsiasi degli indirizzi (unicast o multicast) assegnati all'interfaccia su cui arriva la Query.

4.2. Messaggio Version 3 Membership Report​

I Version 3 Membership Reports sono inviati dai sistemi IP per segnalare (ai router vicini) lo stato corrente di ricezione multicast, o i cambiamenti nello stato di ricezione multicast, delle loro interfacce. I Reports hanno il seguente formato:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Type = 0x22  |    Reserved   |           Checksum            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Reserved            |  Number of Group Records (M)  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   .                                                               .
   .                        Group Record [1]                       .
   .                                                               .
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   .                                                               .
   .                        Group Record [2]                       .
   .                                                               .
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               .                               |
   .                               .                               .
   |                               .                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   .                                                               .
   .                        Group Record [M]                       .
   .                                                               .
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

dove ogni Group Record ha il seguente formato interno:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Record Type  |  Aux Data Len |     Number of Sources (N)     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Multicast Address                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Source Address [1]                      |
   +-                                                             -+
   |                       Source Address [2]                      |
   +-                                                             -+
   .                               .                               .
   .                               .                               .
   .                               .                               .
   +-                                                             -+
   |                       Source Address [N]                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   .                                                               .
   .                         Auxiliary Data                        .
   .                                                               .
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4.2.1. Reserved​

4.2.2. Checksum​

Il Checksum è il complemento a uno a 16 bit della somma in complemento a uno dell'intero messaggio IGMP (l'intero payload IP). Per calcolare il checksum, il campo Checksum è impostato a zero. Quando si ricevono pacchetti, il checksum DEVE essere verificato prima di elaborare un messaggio.

4.2.3. Number of Group Records (M)​

Il campo Number of Group Records (M) specifica quanti Group Records sono presenti in questo Report.

4.2.4. Group Record​

Ogni Group Record è un blocco di campi contenente informazioni relative all'appartenenza del mittente a un singolo gruppo multicast sull'interfaccia da cui viene inviato il Report.

4.2.5. Record Type​

4.2.6. Aux Data Len​

Il campo Aux Data Len contiene la lunghezza del campo Auxiliary Data in questo Group Record, in unità di parole a 32 bit. Può contenere zero, per indicare l'assenza di dati ausiliari.

4.2.7. Number of Sources (N)​

Il campo Number of Sources (N) specifica quanti indirizzi sorgente sono presenti in questo Group Record.

4.2.8. Multicast Address​

Il campo Multicast Address contiene l'indirizzo multicast IP a cui si riferisce questo Group Record.

4.2.9. Source Address [i]​

I campi Source Address [i] sono un vettore di n indirizzi unicast IP, dove n è il valore nel campo Number of Sources (N) di questo record.

4.2.10. Auxiliary Data​

Il campo Auxiliary Data, se presente, contiene informazioni aggiuntive relative a questo Group Record. Il protocollo specificato in questo documento, IGMPv3, non definisce alcun dato ausiliario. Pertanto, le implementazioni di IGMPv3 NON DEVONO includere alcun dato ausiliario (cioè, DEVONO impostare il campo Aux Data Len a zero) in qualsiasi Group Record trasmesso, e DEVONO ignorare qualsiasi dato ausiliario presente in qualsiasi Group Record ricevuto. La semantica e la codifica interna del campo Auxiliary Data devono essere definite da qualsiasi versione futura o estensione di IGMP che utilizza questo campo.

4.2.11. Additional Data​

Se il campo Packet Length nell'header IP di un Report ricevuto indica che ci sono ottetti di dati aggiuntivi presenti, oltre all'ultimo Group Record, le implementazioni IGMPv3 DEVONO includere quegli ottetti nel calcolo per verificare il Checksum IGMP ricevuto, ma DEVONO altrimenti ignorare quegli ottetti aggiuntivi. Quando si invia un Report, un'implementazione IGMPv3 NON DEVE includere ottetti aggiuntivi oltre all'ultimo Group Record.

4.2.12. Tipi di Group Record​

Ci sono diversi tipi di Group Records che possono essere inclusi in un messaggio Report:

  • Un "Current-State Record" è inviato da un sistema in risposta a una Query ricevuta su un'interfaccia. Segnala lo stato corrente di ricezione di quell'interfaccia, rispetto a un singolo indirizzo multicast. Il Record Type di un Current-State Record può essere uno dei seguenti due valori:

    ValueName and Meaning
    1MODE_IS_INCLUDE - indica che l'interfaccia ha una modalità di filtro INCLUDE per l'indirizzo multicast specificato. I campi Source Address [i] in questo Group Record contengono l'elenco sorgente dell'interfaccia per l'indirizzo multicast specificato, se non è vuoto.
    2MODE_IS_EXCLUDE - indica che l'interfaccia ha una modalità di filtro EXCLUDE per l'indirizzo multicast specificato. I campi Source Address [i] in questo Group Record contengono l'elenco sorgente dell'interfaccia per l'indirizzo multicast specificato, se non è vuoto.

  • Un "Filter-Mode-Change Record" è inviato da un sistema ogni volta che un'invocazione locale di IPMulticastListen causa un cambiamento della modalità di filtro (cioè, un cambiamento da INCLUDE a EXCLUDE, o da EXCLUDE a INCLUDE), della voce di stato a livello di interfaccia per un particolare indirizzo multicast. Il Record è incluso in un Report inviato dall'interfaccia su cui si è verificato il cambiamento. Il Record Type di un Filter-Mode-Change Record può essere uno dei seguenti due valori:

    ValueName and Meaning
    3CHANGE_TO_INCLUDE_MODE - indica che l'interfaccia è passata alla modalità di filtro INCLUDE per l'indirizzo multicast specificato. I campi Source Address [i] in questo Group Record contengono il nuovo elenco sorgente dell'interfaccia per l'indirizzo multicast specificato, se non è vuoto.
    4CHANGE_TO_EXCLUDE_MODE - indica che l'interfaccia è passata alla modalità di filtro EXCLUDE per l'indirizzo multicast specificato. I campi Source Address [i] in questo Group Record contengono il nuovo elenco sorgente dell'interfaccia per l'indirizzo multicast specificato, se non è vuoto.

  • Un "Source-List-Change Record" è inviato da un sistema ogni volta che un'invocazione locale di IPMulticastListen causa un cambiamento dell'elenco sorgente che non coincide con un cambiamento della modalità di filtro, della voce di stato a livello di interfaccia per un particolare indirizzo multicast. Il Record è incluso in un Report inviato dall'interfaccia su cui si è verificato il cambiamento. Il Record Type di un Source-List-Change Record può essere uno dei seguenti due valori:

    ValueName and Meaning
    5ALLOW_NEW_SOURCES - indica che i campi Source Address [i] in questo Group Record contengono un elenco delle sorgenti aggiuntive da cui il sistema desidera ricevere, per i pacchetti inviati all'indirizzo multicast specificato. Se il cambiamento riguardava un elenco sorgente INCLUDE, questi sono gli indirizzi aggiunti all'elenco; se il cambiamento riguardava un elenco sorgente EXCLUDE, questi sono gli indirizzi eliminati dall'elenco.
    6BLOCK_OLD_SOURCES - indica che i campi Source Address [i] in questo Group Record contengono un elenco delle sorgenti da cui il sistema non desidera più ricevere, per i pacchetti inviati all'indirizzo multicast specificato. Se il cambiamento riguardava un elenco sorgente INCLUDE, questi sono gli indirizzi eliminati dall'elenco; se il cambiamento riguardava un elenco sorgente EXCLUDE, questi sono gli indirizzi aggiunti all'elenco.

Se un cambiamento dell'elenco sorgente comporta sia l'autorizzazione di nuove sorgenti che il blocco di vecchie sorgenti, vengono inviati due Group Records per lo stesso indirizzo multicast, uno di tipo ALLOW_NEW_SOURCES e uno di tipo BLOCK_OLD_SOURCES.

Usiamo il termine "State-Change Record" per riferirci a un Filter-Mode-Change Record o a un Source-List-Change Record.

I valori di Record Type non riconosciuti DEVONO essere ignorati silenziosamente.

4.2.13. Indirizzi sorgente IP per i Reports​

Un report IGMP è inviato con un indirizzo sorgente IP valido per la sottorete di destinazione. L'indirizzo sorgente 0.0.0.0 può essere utilizzato da un sistema che non ha ancora acquisito un indirizzo IP. Si noti che l'indirizzo sorgente 0.0.0.0 può essere utilizzato simultaneamente da più sistemi su una LAN. I router DEVONO accettare un report con un indirizzo sorgente di 0.0.0.0.

4.2.14. Indirizzi di destinazione IP per i Reports​

I Version 3 Reports sono inviati con un indirizzo di destinazione IP di 224.0.0.22, a cui tutti i router multicast compatibili con IGMPv3 ascoltano. Un sistema che opera in modalità di compatibilità versione 1 o versione 2 invia Reports versione 1 o versione 2 al gruppo multicast specificato nel campo Group Address del Report. Inoltre, un sistema DEVE accettare ed elaborare qualsiasi Report versione 1 o versione 2 il cui campo IP Destination Address contenga uno qualsiasi degli indirizzi (unicast o multicast) assegnati all'interfaccia su cui arriva il Report.

4.2.15. Notazione per i Group Records​

Nel resto di questo documento, utilizziamo la seguente notazione per descrivere il contenuto di un Group Record relativo a un particolare indirizzo multicast:

   IS_IN ( x )  -  Type MODE_IS_INCLUDE, source addresses x
   IS_EX ( x )  -  Type MODE_IS_EXCLUDE, source addresses x
   TO_IN ( x )  -  Type CHANGE_TO_INCLUDE_MODE, source addresses x
   TO_EX ( x )  -  Type CHANGE_TO_EXCLUDE_MODE, source addresses x
   ALLOW ( x )  -  Type ALLOW_NEW_SOURCES, source addresses x
   BLOCK ( x )  -  Type BLOCK_OLD_SOURCES, source addresses x

dove x è:

  • una lettera maiuscola (ad esempio, "A") per rappresentare l'insieme degli indirizzi sorgente, oppure

  • un'espressione di insieme (ad esempio, "A+B"), dove "A+B" significa l'unione degli insiemi A e B, "A*B" significa l'intersezione degli insiemi A e B, e "A-B" significa la rimozione di tutti gli elementi dell'insieme B dall'insieme A.

4.2.16. Dimensione del Membership Report​

Se l'insieme dei Group Records richiesti in un Report non rientra nel limite di dimensione di un singolo messaggio Report (come determinato dalla MTU della rete su cui verrà inviato), i Group Records sono inviati in tanti messaggi Report quanti necessari per segnalare l'intero insieme.

Se un singolo Group Record contiene così tanti indirizzi sorgente da non rientrare nel limite di dimensione di un singolo messaggio Report, se il suo Type non è MODE_IS_EXCLUDE o CHANGE_TO_EXCLUDE_MODE, viene diviso in più Group Records, ciascuno contenente un sottoinsieme diverso degli indirizzi sorgente e ciascuno inviato in un messaggio Report separato. Se il suo Type è MODE_IS_EXCLUDE o CHANGE_TO_EXCLUDE_MODE, viene inviato un singolo Group Record, contenente quanti più indirizzi sorgente possibile, e gli indirizzi sorgente rimanenti non vengono segnalati; sebbene la scelta di quali sorgenti segnalare sia arbitraria, è preferibile segnalare lo stesso insieme di sorgenti in ogni report successivo, piuttosto che segnalare sorgenti diverse ogni volta.

5. Descrizione del protocollo per i membri del gruppo​

IGMP è un protocollo asimmetrico, che specifica comportamenti diversi per i membri del gruppo (host o router che desiderano ricevere pacchetti multicast) e i router multicast (che ascoltano i messaggi IGMP e coordinano l'inoltro multicast). Questa sezione descrive la parte di IGMPv3 che si applica ai membri del gruppo. (Si noti che un router può anche essere un membro del gruppo.)

Un sistema esegue il protocollo descritto in questa sezione su ogni interfaccia su cui è supportata la ricezione multicast. Il protocollo su ogni interfaccia coinvolge l'elaborazione immediata di due tipi di eventi:

  1. Una modifica dello stato di ricezione multicast sull'interfaccia, causata da un'invocazione locale della definizione IPMulticastListen.

  2. Ricezione di un messaggio Membership Query.

5.1. Azione al cambio di stato dell'interfaccia​

Un'invocazione di IPMulticastListen può causare la modifica dello stato di ricezione multicast di un'interfaccia, secondo le regole nella Sezione 3.2. Ogni tale modifica influisce sullo stato per interfaccia per un singolo indirizzo di gruppo multicast.

Una modifica dello stato dell'interfaccia fa sì che il sistema trasmetta immediatamente un State Change Report da quell'interfaccia. Il tipo e il contenuto del State Change Report sono determinati come segue:

  1. Se la modifica dello stato non è significativa, come ad esempio il modo di filtraggio per un gruppo che passa da INCLUDE a INCLUDE o da EXCLUDE a EXCLUDE, con l'insieme di indirizzi sorgente che rimane invariato, non viene generato alcun report.

  2. Se la modifica dello stato è significativa, viene generato un State Change Report. Il Report contiene un singolo Group Record per il gruppo il cui stato è cambiato. Il tipo e il contenuto del Group Record sono determinati confrontando l'Old State (lo stato prima della modifica) con il New State (lo stato dopo la modifica), come indicato nella tabella seguente:

    Old StateNew StateState Change Record Sent
    INCLUDE (A)INCLUDE (B)ALLOW (B-A), BLOCK (A-B)
    EXCLUDE (A)EXCLUDE (B)ALLOW (A-B), BLOCK (B-A)
    INCLUDE (A)EXCLUDE (B)TO_EX (B)
    EXCLUDE (A)INCLUDE (B)TO_IN (B)

    La notazione "ALLOW (B-A)" significa che il State Change Record porta un elenco sorgente contenente tutti gli indirizzi sorgente che sono nell'insieme B ma non nell'insieme A. La notazione "BLOCK (A-B)" significa che il State Change Record porta un elenco sorgente contenente tutti gli indirizzi sorgente che sono nell'insieme A ma non nell'insieme B.

    Se l'elenco sorgente calcolato per un record ALLOW o BLOCK è vuoto, quel record viene omesso dal State Change Report.

Per garantire che il State Change Report sia ricevuto da tutti i router multicast sulla rete, il sistema ritrasmette il Report [Robustness Variable] - 1 volte, a intervalli casuali scelti dall'intervallo (0, [Unsolicited Report Interval]). La [Robustness Variable] è un parametro regolabile, predefinito a 2. L'[Unsolicited Report Interval] è anche un parametro regolabile, predefinito a 10 secondi.

Se un State Change Report è programmato per la trasmissione, e viene ricevuta una Query che causerebbe la generazione di un Current State Report (vedi Sezione 5.2), il State Change Report in attesa viene scartato e viene inviato invece il Current State Report. Il Current State Report deve contenere tutte le informazioni che sarebbero state nel State Change Report.

5.2. Azione alla ricezione di una Query​

Quando un sistema riceve una Query, verifica innanzitutto se la Query è valida. Per essere valida, la Query deve:

  1. avere un checksum IP corretto,
  2. avere un indirizzo IP di destinazione uguale all'indirizzo multicast all-systems (224.0.0.1) o all'indirizzo di gruppo specifico interrogato.

Se la Query non è valida, viene ignorata. Se la Query è valida, il sistema esegue le seguenti azioni:

  1. Aggiorna il suo timer per il Querier, se necessario (vedi Sezione 6).
  2. Determina se deve rispondere alla Query.

Le seguenti sottosezioni descrivono le regole per rispondere a diversi tipi di Queries.

5.2.1. Azione alla ricezione di una General Query​

Al ricevimento di una General Query, il sistema controlla ogni interfaccia per vedere se esiste uno stato di ricezione multicast per un gruppo. Per ogni gruppo per cui esiste uno stato, il sistema programma l'invio di un Current State Report.

Il Report contiene un Group Record per il gruppo. Il tipo del Group Record è MODE_IS_INCLUDE se il modo di filtraggio per il gruppo è INCLUDE, e MODE_IS_EXCLUDE se il modo di filtraggio è EXCLUDE. L'elenco sorgente nel Group Record contiene l'insieme di indirizzi sorgente per il gruppo.

Il Report è programmato per essere inviato in un momento casuale scelto dall'intervallo (0, [Max Resp Time]), dove [Max Resp Time] è il valore specificato nel campo Max Resp Code della Query.

5.2.2. Azione alla ricezione di una Group-Specific Query​

Al ricevimento di una Group-Specific Query, il sistema controlla se ha uno stato di ricezione multicast per l'indirizzo di gruppo specificato nella Query. In caso contrario, ignora la Query.

Se esiste uno stato per il gruppo, il sistema programma l'invio di un Current State Report. Il Report contiene un Group Record per il gruppo, costruito come descritto nella Sezione 5.2.1.

Il Report è programmato per essere inviato in un momento casuale scelto dall'intervallo (0, [Max Resp Time]).

5.2.3. Azione alla ricezione di una Group-and-Source-Specific Query​

Al ricevimento di una Group-and-Source-Specific Query, il sistema controlla se ha uno stato di ricezione multicast per l'indirizzo di gruppo specificato nella Query. In caso contrario, ignora la Query.

Se esiste uno stato per il gruppo, il sistema determina se è interessato a uno qualsiasi degli indirizzi sorgente specificati nella Query. Il sistema è interessato a un indirizzo sorgente se:

  1. Il modo di filtraggio per il gruppo è EXCLUDE, OPPURE
  2. Il modo di filtraggio per il gruppo è INCLUDE e l'indirizzo sorgente è nell'elenco sorgente.

Se il sistema è interessato ad almeno uno degli indirizzi sorgente, programma l'invio di un Current State Report. Il Report contiene un Group Record per il gruppo, costruito come descritto nella Sezione 5.2.1.

Il Report è programmato per essere inviato in un momento casuale scelto dall'intervallo (0, [Max Resp Time]).

5.2.4. Azione alla ricezione di una Query con il flag "S" impostato​

Se il flag "S" (Suppress Router-Side Processing) è impostato in una Query ricevuta, il sistema non aggiorna il suo timer per il Querier. Tuttavia, risponde comunque alla Query come descritto nelle Sezioni da 5.2.1 a 5.2.3.

6. Protocollo per i router multicast​

Lo scopo di IGMP è consentire a ciascun router multicast di apprendere, per ciascuna delle sue reti direttamente collegate, quali indirizzi multicast hanno ascoltatori su quella rete. IGMPv3 consente inoltre a un router multicast di apprendere quali sorgenti sono di interesse per gli ascoltatori.

6.1. Condizioni per l'elezione del Querier​

IGMPv3 concorda con IGMPv2 sul fatto che dovrebbe esserci un solo Querier per rete. Tuttavia, i Querier IGMPv3 e IGMPv2 possono coesistere sulla stessa rete. Il protocollo di elezione è lo stesso di IGMPv2:

  1. Inizialmente, ogni router multicast si avvia come Querier su ciascuna delle sue reti collegate.
  2. Se un router multicast sente un messaggio Query da un router con un indirizzo IP inferiore, deve diventare un Non-Querier su quella rete.
  3. Se un router multicast non ha sentito un messaggio Query da un router con un indirizzo IP inferiore per [Other Querier Present Interval], riprende il ruolo di Querier.

6.2. Azione del Querier alla ricezione di una Query​

Quando un Querier riceve un messaggio Query, controlla l'indirizzo IP sorgente della Query.

  1. Se l'indirizzo IP sorgente è inferiore al proprio indirizzo IP, il router diventa un Non-Querier.
  2. Se l'indirizzo IP sorgente è superiore al proprio indirizzo IP, il router continua a essere il Querier.
  3. Se l'indirizzo IP sorgente è uguale al proprio indirizzo IP, la Query viene ignorata (è una riflessione o un loopback).

6.3. Invio di Queries​

Il Querier invia periodicamente General Queries per sollecitare informazioni sull'appartenenza. Invia anche Group-Specific o Group-and-Source-Specific Queries quando riceve determinati tipi di State Change Reports.

6.3.1. General Queries​

Il Querier invia periodicamente General Queries all'indirizzo multicast all-systems (224.0.0.1). L'[Query Interval] predefinito è di 125 secondi.

Le General Queries sono utilizzate per aggiornare le informazioni sull'appartenenza per tutti i gruppi e le sorgenti.

6.3.2. Group-Specific Queries​

Quando il Querier riceve un State Change Report che indica che un sistema ha lasciato un gruppo (ad esempio, un cambiamento di modalità di filtro da EXCLUDE a INCLUDE, o un cambiamento di elenco sorgente che blocca una sorgente), invia una Group-Specific Query all'indirizzo del gruppo.

Questa Query viene utilizzata per determinare se ci sono sistemi rimanenti interessati al gruppo.

6.3.3. Group-and-Source-Specific Queries​

Quando il Querier riceve un State Change Report che indica che un sistema non è più interessato a sorgenti specifiche per un gruppo (ad esempio, bloccando sorgenti specifiche), invia una Group-and-Source-Specific Query.

Questa Query viene utilizzata per determinare se ci sono sistemi rimanenti interessati a quelle sorgenti specifiche.

6.4. Ricezione di Reports​

I router multicast registrano lo stato di ricezione per ciascun gruppo e sorgente in base ai Reports che ricevono. Lo stato è mantenuto per interfaccia.

6.4.1. Ricezione di Current State Records​

Quando un router riceve un Current State Record, aggiorna i suoi timer di gruppo/sorgente.

  • Se il record è MODE_IS_INCLUDE, il router aggiorna i timer per le sorgenti elencate.
  • Se il record è MODE_IS_EXCLUDE, il router aggiorna il timer di gruppo e i timer per le sorgenti escluse (se presenti).

6.4.2. Ricezione di Filter-Mode-Change Records​

Quando un router riceve un Filter-Mode-Change Record, aggiorna la modalità di filtro e i timer.

  • CHANGE_TO_INCLUDE_MODE: Il router passa alla modalità INCLUDE se non lo era già, e aggiorna i timer sorgente.
  • CHANGE_TO_EXCLUDE_MODE: Il router passa alla modalità EXCLUDE e aggiorna il timer di gruppo.

6.4.3. Ricezione di Source-List-Change Records​

Quando un router riceve un Source-List-Change Record, aggiorna i timer sorgente.

  • ALLOW_NEW_SOURCES: Il router aggiunge le nuove sorgenti al suo elenco e avvia i loro timer.
  • BLOCK_OLD_SOURCES: Il router può interrogare per vedere se altri sistemi hanno ancora bisogno di queste sorgenti prima di rimuoverle.

6.5. Cambio della modalità di filtro del router​

La modalità di filtro del router per un gruppo passa tra INCLUDE ed EXCLUDE in base allo stato del timer di gruppo e dei timer sorgente.

  • Se il timer di gruppo è in esecuzione, la modalità di filtro è EXCLUDE.
  • Se il timer di gruppo scade, la modalità di filtro passa a INCLUDE.

6.6. Azione alla ricezione di un messaggio Group Leave (IGMPv2)​

Se un router riceve un messaggio IGMPv2 Leave Group, si comporta come se avesse ricevuto un State Change Report che indica un cambiamento alla modalità INCLUDE (abbandonando effettivamente il gruppo) per il gruppo specificato nel messaggio Leave. Ciò consente ai router IGMPv3 di interoperare con gli host IGMPv2.

7. Interoperazione con IGMPv1 e IGMPv2​

Gli host e i router IGMPv3 interoperano con gli host e i router che non sono ancora stati aggiornati a IGMPv3. Questa compatibilità è mantenuta dai messaggi Membership Query periodici che vengono inviati in multicast dal Querier, e dai messaggi Membership Report Version 1 e Version 2 che vengono inviati in multicast dagli host più vecchi.

7.1. Funzionamento dell'host IGMPv3​

Il comportamento di un host IGMPv3 dipende dal fatto che il Querier sulla rete stia parlando IGMPv3, IGMPv2 o IGMPv1.

7.1.1. Distinzioni di versione della Query​

La versione IGMP di un messaggio Membership Query è determinata come segue:

7.1.2. Comportamento in presenza di Querier più vecchi​

Un host IGMPv3 può essere posizionato su una rete dove il Querier non è ancora stato aggiornato a IGMPv3. L'host deve tenere conto di questa possibilità.

  • IGMPv1 Querier Present: Se un host IGMPv3 riceve una Query IGMPv1, deve rispondere con Reports IGMPv1. Il filtraggio delle sorgenti non è supportato.
  • IGMPv2 Querier Present: Se un host IGMPv3 riceve una Query IGMPv2, deve rispondere con Reports IGMPv2. Il filtraggio delle sorgenti non è supportato.
  • IGMPv3 Querier Present: Se un host IGMPv3 riceve una Query IGMPv3, risponde con Reports IGMPv3. Il filtraggio delle sorgenti è supportato.

L'host mantiene una variabile di modalità di compatibilità per ogni interfaccia, che viene aggiornata ogni volta che viene ricevuta una Query. Se viene ricevuta una Query più vecchia, l'host passa alla modalità di compatibilità corrispondente e imposta un timer. Quando il timer scade, l'host torna in modalità IGMPv3.

7.2. Funzionamento del router IGMPv3​

Il comportamento di un router IGMPv3 dipende dalla presenza di host o router più vecchi sulla rete.

7.2.1. Presenza di host più vecchi​

Un router IGMPv3 può ricevere Reports IGMPv1 o IGMPv2 da host più vecchi.

  • IGMPv1 Report Received: Il router agisce come se avesse ricevuto un report IGMPv3 IS_EX({}) per il gruppo. Deve anche ignorare qualsiasi messaggio Leave Group per quel gruppo (poiché IGMPv1 non ha messaggi Leave).
  • IGMPv2 Report Received: Il router agisce come se avesse ricevuto un report IGMPv3 IS_EX({}) per il gruppo.

Quando sono presenti host più vecchi, il router potrebbe dover sopprimere l'elaborazione specifica di IGMPv3 (come le query specifiche per sorgente) per i gruppi interessati per garantire la compatibilità.

7.2.2. Presenza di router più vecchi​

Se un router IGMPv3 si trova su una rete con router più vecchi, il processo di elezione del Querier (Sezione 6.1) determina quale router diventa il Querier.

  • Se un router IGMPv1 è presente e diventa il Querier, tutti i router (compresi i router IGMPv3) devono agire come router IGMPv1.
  • Se un router IGMPv2 è presente e diventa il Querier, tutti i router devono agire come router IGMPv2.
  • Se un router IGMPv3 diventa il Querier, invia Queries IGMPv3. I router più vecchi vedranno queste come query IGMPv1/v2 non valide (o le gestiranno se sono parzialmente compatibili), ma in generale, i router IGMPv3 dovrebbero essere configurati per funzionare in modalità IGMPv1 o IGMPv2 se devono coesistere con router più vecchi che non possono gestire i pacchetti IGMPv3.

7.3. Mescolanza di host Version 1, 2 e 3​

È possibile avere un mix di host IGMPv1, IGMPv2 e IGMPv3 sulla stessa rete.

  • Se il Querier è IGMPv3, invia Queries IGMPv3.
  • Gli host IGMPv3 rispondono con Reports IGMPv3.
  • Gli host IGMPv2 rispondono con Reports IGMPv2.
  • Gli host IGMPv1 rispondono con Reports IGMPv1.

Il router IGMPv3 deve gestire tutti questi tipi di report. Per i gruppi con membri IGMPv1 o IGMPv2, il router deve trattare effettivamente il gruppo come se fosse in modalità EXCLUDE con un elenco sorgente vuoto (cioè, "inviami tutto per questo gruppo"), perché gli host più vecchi non possono specificare filtri sorgente.

8. Elenco di timer, contatori e loro valori predefiniti​

La maggior parte di questi timer e contatori sono configurabili. Se vengono utilizzate impostazioni non predefinite, DEVONO essere coerenti tra tutti i router su un singolo collegamento. Si noti che le parentesi indicano il valore del campo corrispondente nel messaggio Query.

8.1. Robustness Variable​

La Robustness Variable consente di regolare la perdita di pacchetti prevista su una rete. Se si prevede che una rete sia soggetta a perdite, la Robustness Variable può essere aumentata. IGMP è robusto a [Robustness Variable] - 1 perdite di pacchetti.

8.2. Query Interval​

Il Query Interval è l'intervallo tra le General Queries inviate dal Querier.

8.3. Query Response Interval​

8.4. Group Membership Interval​

Il Group Membership Interval è la quantità di tempo che deve passare prima che un router multicast decida che non ci sono più membri di un gruppo o di una particolare sorgente su una rete.

8.5. Other Querier Present Interval​

L'Other Querier Present Interval è la durata che deve passare prima che un router multicast decida che non c'è più un altro router multicast che dovrebbe essere il Querier.

8.6. Startup Query Interval​

Lo Startup Query Interval è l'intervallo tra le General Queries inviate da un Querier all'avvio.

8.7. Startup Query Count​

Lo Startup Query Count è il numero di Queries inviate all'avvio, separate dallo [Startup Query Interval].

8.8. Last Member Query Interval​

Il Last Member Query Interval è il Max Resp Time inserito nelle Group-Specific Queries inviate in risposta ai messaggi Leave Group.

8.9. Last Member Query Count​

Il Last Member Query Count è il numero di Group-Specific Queries inviate prima che il router assuma che non ci sono membri locali.

8.10. Unsolicited Report Interval​

L'Unsolicited Report Interval è il tempo tra le ripetizioni del report iniziale di un host dell'appartenenza a un gruppo.

8.11. Older Version Querier Present Timeout​

L'Older Version Querier Present Timeout è il timeout per la transizione di un host di nuovo alla modalità IGMPv3 una volta che è stata ascoltata una query di una versione precedente.

9. Considerazioni sulla sicurezza​

Consideriamo le ramificazioni di un messaggio falsificato di ciascun tipo.

9.1. Messaggio Query​

Un messaggio Query falsificato proveniente da una macchina con un indirizzo IP inferiore a quello del Querier corrente causerà l'avvio di un'elezione del Querier. Ciò può far sì che il Querier corrente smetta di inviare Queries e attenda che il nuovo Querier si avvii. Poiché il nuovo Querier non è valido, il timer Query sui router potrebbe eventualmente scadere, causando loro di eliminare le informazioni sull'appartenenza.

Un attacco DoS è possibile inviando Queries falsificate con un piccolo Max Resp Code. Ciò causerebbe l'invio simultaneo di Reports da parte di tutti gli host sulla LAN, sovraccaricando potenzialmente la rete o il router.

9.2. Messaggi Current State Report​

Un messaggio Report falsificato può far credere al router che ci siano membri di un gruppo su una rete quando non ce ne sono. Ciò può causare l'inoltro non necessario di traffico multicast alla rete, consumando larghezza di banda.

9.3. Messaggi State Change Report​

Un messaggio State Change Report falsificato può far credere al router che un sistema si sia unito o abbia lasciato un gruppo. I report "Join" falsificati (ALLOW o TO_IN) causano traffico non necessario. I report "Leave" falsificati (BLOCK o TO_EX) possono causare l'invio di una Group-Specific Query da parte del router, e se nessun host valido risponde in tempo, il router può smettere di inoltrare il traffico per il gruppo, causando un denial of service ai membri legittimi.

9.4. IPsec​

L'intestazione di autenticazione IPsec (AH) [RFC2402] può essere utilizzata per proteggere i messaggi IGMP. Quando viene utilizzato AH, l'autenticazione viene applicata all'intero pacchetto IP, incluso il messaggio IGMP. Ciò può impedire la falsificazione di messaggi IGMP. Tuttavia, la gestione delle chiavi per il multicast è complessa ed è un'area di ricerca in corso.

10. Considerazioni IANA​

10.1. Tipi di messaggi IGMP​

IANA ha assegnato il tipo di messaggio IGMP 0x22 a "Version 3 Membership Report".

10.2. Tipi di record di gruppo​

IANA ha creato un nuovo registro per "IGMPv3 Report Types" (tipi di record di gruppo). I valori da 0x01 a 0x06 sono definiti in questo documento. I valori 0x00 e da 0x07 a 0xFF sono disponibili per l'assegnazione.

10.3. Max Resp Code​

Il campo Max Resp Code nel messaggio Membership Query è un campo a 8 bit. I valori sono definiti nella sezione 4.1.1. Non è richiesto alcun registro.

11. Ringraziamenti​

Vorremmo ringraziare le numerose persone che hanno contribuito alla progettazione e alla documentazione di IGMPv3. In particolare, riconosciamo i contributi di:

  • Steve Deering, che ha inventato IP Multicast e progettato le versioni precedenti di IGMP.
  • Van Jacobson, che ha contribuito alla progettazione dei meccanismi di timer.
  • Isidor Kouvelas, che è stato co-autore delle bozze precedenti.
  • I membri del gruppo di lavoro IDMR per la loro revisione e commenti.

12. Riferimenti​

12.1. Riferimenti normativi​

12.2. Riferimenti informativi​

Appendice A. Motivazioni del design​

A.1. Il modo di filtraggio "Exclude"​

Il modo di filtraggio "Exclude" è stato introdotto per supportare il "Source-Specific Multicast" (SSM) mantenendo al contempo la compatibilità con il modello "Any-Source Multicast" (ASM) esistente.

In ASM, un host si unisce a un gruppo G e riceve traffico da tutte le sorgenti che inviano a G. Questo equivale a EXCLUDE({}, G). In SSM, un host si unisce a un canale specifico (S, G) e riceve traffico solo dalla sorgente S inviato al gruppo G. Questo equivale a INCLUDE({S}, G).

Il modo EXCLUDE consente a un host di bloccare sorgenti specifiche da un gruppo ASM, il che è utile per filtrare il traffico indesiderato.

A.2. Il modo di filtraggio "Include"​

Il modo di filtraggio "Include" è il modo principale per SSM. Consente a un host di specificare esplicitamente l'insieme di sorgenti che desidera ricevere. Ciò semplifica il protocollo di routing multicast, poiché il router deve solo costruire un albero specifico per sorgente.

A.3. State Change Reports​

I State Change Reports vengono inviati per garantire l'affidabilità. Ripetendo i report, la probabilità che vengano persi è ridotta. Questo è importante perché IGMP funziona su un trasporto inaffidabile (IP).

Appendice B. Riepilogo dei cambiamenti da IGMPv2​

Quanto segue è un riepilogo dei cambiamenti da IGMPv2 [RFC2236] a IGMPv3:

  1. Filtraggio delle sorgenti: La capacità per gli host di specificare quali sorgenti vogliono ricevere (modalità INCLUDE) o quali sorgenti vogliono bloccare (modalità EXCLUDE).

  2. Tipi di record di gruppo: I Reports IGMPv3 contengono Group Records, che possono essere di diversi tipi (Current State, Filter Mode Change, Source List Change) per trasmettere diversi tipi di informazioni.

  3. Formato del Membership Report: Il formato del Report è stato completamente riprogettato per supportare più Group Records in un singolo messaggio e per trasportare indirizzi sorgente.

  4. Formato della Query: Il formato della Query è stato esteso per supportare le Group-and-Source-Specific Queries e per trasportare la Robustness Variable e il Query Interval (QQIC).

  5. Max Resp Code: Il campo Max Resp Code è stato ridefinito per supportare valori più grandi utilizzando una rappresentazione in virgola mobile.

  6. Elezione del Querier: Il meccanismo di elezione del Querier rimane lo stesso, ma le regole per la gestione delle versioni precedenti sono state chiarite.

  7. S Flag: Il flag "Suppress Router-Side Processing" nelle Queries consente ai router di sopprimere gli aggiornamenti dei timer quando ricevono Queries, il che è utile per determinati diagnostici o configurazioni speciali.