Passa al contenuto principale

3. Considerazioni su IPv6 (IPv6 Considerations)

Per evitare confusione, le discussioni precedenti si sono basate esclusivamente su IPv4. Il protocollo equivalente per IPv6 è la Multicast Listener Discovery [MLD]. Poiché MLD si basa su IGMP, la descrizione completa e le raccomandazioni non vengono ripetute qui; vengono invece indicati solo i casi in cui MLD differisce da IGMP.

Le regole di inoltro di controllo e dei dati descritte per IGMP nella sezione 2 possono essere applicate a MLD con poche considerazioni; vale a dire, la funzionalità di base di intercettare i messaggi MLD e di costruire elenchi di appartenenza e di router multicast è la stessa di IGMP.

L'inoltro dei dati IPv6 è più semplice di quello IPv4 sotto un aspetto: MLD è obbligatorio per gli indirizzi con scope 2 (locale al collegamento) e superiore. L'unica eccezione è l'indirizzo locale al collegamento di tutti gli host FF02::1, che non invia mai messaggi MLD; i pacchetti destinati all'indirizzo locale al collegamento di tutti gli host DOVREBBERO (SHOULD) essere inoltrati su tutte le porte.

I gruppi con indirizzi in FF00::/15 (che comprende FF00::/16, riservato, e FF01::/16, locale al nodo) non inviano messaggi MLD; tali indirizzi non dovrebbero quindi mai comparire nei pacchetti sul collegamento.

Le seguenti differenze tra IPv4 e IPv6 sono rilevanti per lo snooping:

  1. Il protocollo per il mantenimento dei gruppi multicast IPv6 si chiama Multicast Listener Discovery versione 2 [MLDv2]. MLDv2 usa tipi di messaggio ICMPv6 invece dei tipi di messaggio IGMP.

  2. [IPV6-ETHER] e [IPV6-FDDI] descrivono come i 32 bit dell'indirizzo IP di destinazione (DIP) a 128 bit vengano usati per formare l'indirizzo MAC di destinazione (DMAC) a 48 bit; [IPV6-TOKEN] descrive la corrispondenza per gli indirizzi DMAC Token Ring usando i tre bit meno significativi; e [IPV6-1394] usa un numero di canale a 6 bit.

  3. La scoperta dei router multicast è effettuata dal protocollo MRDISC come definito in [MRDISC].

In modo equivalente ai comportamenti IPv4 relativi all'indirizzo sorgente IP nullo, i rapporti di appartenenza MLD NON DEVONO (MUST NOT) essere respinti da uno switch con snooping MLD perché l'indirizzo IP sorgente non è specificato (::). Inoltre, se uno switch non Querier falsifica delle General Query (come trattato sopra nella sezione 2.1, per i cambiamenti di topologia dello spanning tree), DOVREBBE (SHOULD) usare l'indirizzo IP sorgente non specificato (::) quando invia tali query. Quando tali query per conto terzi vengono ricevute, NON DEVONO (MUST NOT) essere incluse nel processo di elezione del Querier.

L'intestazione IPv6 non include un campo di checksum. Tuttavia uno switch DOVREBBE (SHOULD), per quanto possibile, rilevare altri problemi di integrità dei pacchetti, come la coerenza tra versione dell'indirizzo e lunghezza del payload. Se tali errori vengono rilevati, le informazioni del pacchetto NON DEVONO (MUST NOT) essere incorporate nella tabella di inoltro MLD, e il codice di inoltro DOVREBBE (SHOULD) scartare il pacchetto e adottare le ragionevoli azioni successive discusse in precedenza.

Poiché MLDv2 usa ICMPv6, e ICMPv6 ha vari altri usi oltre a MLD, affidarsi unicamente al campo next-header dell'intestazione IP come ICMPv6 per determinare se un pacchetto è correlato allo snooping MLD non è più sufficiente. Un'implementazione software che tratta tutti i pacchetti ICMPv6 come candidati allo snooping MLD può facilmente riempire le code di ricezione e bloccare la CPU, vanificando lo scopo della funzione di snooping, e perderà i pacchetti non MLD destinati ad altri host.

Esistono due possibili approcci:

  1. Richiedere allo switch di esaminare più in profondità il contenuto del pacchetto. Questo approccio è preferibile quando viene fornita un'opzione di configurazione che consente all'amministratore di specificare quali tipi di pacchetto ICMPv6 devono attivare un reindirizzamento alla CPU; codificare in modo fisso i tipi di pacchetto manca di flessibilità per l'introduzione di nuovi tipi in futuro.

  2. Combinare il rilevamento ICMPv6 con l'indirizzo DMAC multicast. Questo approccio rischia di classificare erroneamente come MLD nuovi protocolli che usano ICMPv6 con un indirizzo DMAC multicast.

Si raccomanda il primo approccio. Se tale opzione di configurazione non può essere fornita, gli implementatori DOVREBBERO (SHOULD) considerare seriamente di aggiungerla, poiché i messaggi di Neighbor Discovery rientrano nella categoria che verrebbe classificata erroneamente, e sono critici per l'integrità operativa delle reti IPv6.

L'assegnazione iniziale degli indirizzi multicast IPv6, come descritto in [RFC3307], copre solo i 32 bit meno significativi dell'ID di gruppo. La corrispondenza tra indirizzi multicast IP e indirizzi DMAC multicast presenta quindi una forte sovrapposizione. La struttura di un indirizzo multicast IPv6 è:

   |   8    |  4 |  4 |             112 bits                  |
   +--------+----+----+---------------------------------------+
   |11111111|flgs|scop|             group ID                  |
   +--------+----+----+---------------------------------------+

Pertanto, su Ethernet e FDDI, 2 ** (112 - 32), cioè più di 1,2e24 indirizzi DIP univoci, corrispondono allo stesso indirizzo DMAC, rispetto a 2**5 per IPv4. Tuttavia, secondo [RFC3307], l'assegnazione iniziale degli indirizzi multicast IPv6 copre solo i 32 bit meno significativi dell'ID di gruppo; ciò limita temporaneamente il problema di ambiguità agli ID di gruppo con valori di flag e scope diversi, ma la politica di assegnazione potrebbe cambiare in futuro. Data questa potenziale sovrapposizione, si raccomanda un inoltro basato sugli indirizzi IPv6 anziché sugli indirizzi MAC.