4.3. Allocazione degli indirizzi multicast specifici della sorgente
L'indirizzo di destinazione SSM 232.0.0.0 è riservato e NON DEVE (MUST NOT) essere utilizzato come indirizzo di destinazione. Analogamente, anche FF3x::4000:0000 è riservato. Questi due indirizzi sono riservati per conservare un indirizzo di destinazione SSM non valido per IPv4 e IPv6, utilizzabile come valore nullo (null value) nelle implementazioni. L'intervallo di indirizzi 232.0.0.1 - 232.0.0.255 è attualmente riservato per l'allocazione IANA. Gli indirizzi di destinazione SSM nell'intervallo FF3x::4000:0001 - FF3x::7FFF:FFFF sono anch'essi riservati per l'allocazione IANA [IPv6-MALLOC]. La motivazione della riserva di questi indirizzi è delineata nella sezione 9 "Considerazioni IANA" (IANA Considerations) di seguito.
La politica di allocazione dei rimanenti indirizzi SSM alle applicazioni mittenti è strettamente una decisione locale dell'host mittente.
Durante l'allocazione dinamica degli indirizzi SSM, l'host o il sistema operativo dell'host NON DEVE (MUST NOT) allocare sequenzialmente a partire dal primo indirizzo consentito. La pratica RACCOMANDATA (RECOMMENDED) consiste nell'allocare in modo casuale alle applicazioni, avendo cura che l'indirizzo allocato non venga fornito simultaneamente a più applicazioni (ed evitando gli indirizzi riservati). Per IPv6, la randomizzazione deve interessare i 31 bit meno significativi dell'indirizzo.
Come descritto nella sezione 6, la mappatura dei pacchetti IP con indirizzo di destinazione SSM su un indirizzo di multicast a livello di collegamento non tiene conto dell'indirizzo IP sorgente del datagramma (sulle tipiche reti di livello collegamento come Ethernet). Se tutti gli host iniziano dal primo indirizzo consentito, allora su una LAN a supporto condiviso, molti canali specifici della sorgente probabilmente utilizzeranno lo stesso indirizzo di multicast a livello di collegamento. Di conseguenza, il traffico destinato a un sottoscrittore di un canale verrà recapitato al modulo IP di un altro host, che dovrà quindi scartare il datagramma.
Il sistema operativo dell'host DOVREBBE (SHOULD) fornire un'interfaccia che consenta a un'applicazione di richiedere in anticipo un'allocazione univoca di un indirizzo di destinazione del canale prima dell'inizio della sessione, e tale database di allocazione DOVREBBE (SHOULD) persistere dopo il riavvio dell'host. Fornendo un'allocazione persistente, l'applicazione host può pubblicare in anticipo la sessione su una pagina Web o in un altro elenco. (Notiamo che questo problema non è specifico delle applicazioni SSM -- si verifica anche con ASM.)
Il presente documento non definisce né l'interfaccia per richiedere o restituire indirizzi, né l'algoritmo host per memorizzare tali allocazioni. La RFC 2771 [RFC2771] definisce una ragionevole API astratta. Si noti che la RFC 2771 consente a un'applicazione di richiedere un indirizzo all'interno di un determinato intervallo. Se si utilizza questa interfaccia, l'indirizzo iniziale dell'intervallo DOVREBBE (SHOULD) essere scelto casualmente dall'applicazione.
Per IPv6, gli indirizzi di canale SSM a scope amministrativo (administratively scoped) sono creati scegliendo un identificatore di scope appropriato per l'indirizzo di destinazione SSM. I normali confini di scope del multicast IPv6 [SCOPINGv6] si applicano al traffico inviato a indirizzi di destinazione SSM, inclusi tutti i confini applicabili agli indirizzi sorgente e di destinazione.
Non è ancora definito un intervallo di indirizzi a scope amministrativo, coerente a livello globale, per il multicast specifico della sorgente IPv4 [ADMIN-SCOPE]. Per IPv4, lo scope amministrativo degli indirizzi SSM può essere realizzato all'interno di un dominio amministrativo filtrando il traffico SSM in uscita verso un intervallo di indirizzi sui router di confine del dominio.