4.3. Allocation des adresses multicast spécifiques à la source (Allocation of Source-Specific Multicast Addresses)

L'adresse de destination SSM (Source-Specific Multicast, multicast spécifique à la source) 232.0.0.0 est réservée et NE DOIT PAS être utilisée comme adresse de destination. De même, FF3x::4000:0000 est réservée. Ces deux adresses sont réservées afin de disposer d'une adresse de destination SSM invalide pour IPv4 et IPv6, ce qui peut être utile comme valeur nulle dans les implémentations. La plage d'adresses 232.0.0.1 - 232.0.0.255 est actuellement réservée pour attribution par l'IANA. Les adresses de destination SSM dans la plage FF3x::4000:0001 à FF3x::7FFF:FFFF sont également réservées pour attribution par l'IANA [IPv6-MALLOC]. La motivation pour réserver ces adresses est décrite à la section 9 « Considérations IANA » ci-dessous.

La politique d'attribution des adresses SSM restantes aux applications émettrices est déterminée strictement de manière locale par l'hôte émetteur.

Lors de l'attribution dynamique d'adresses SSM, un hôte ou son système d'exploitation NE DOIT PAS attribuer des adresses de manière séquentielle en commençant par la première adresse autorisée. Il est RECOMMANDÉ d'attribuer les adresses SSM aux applications de manière aléatoire, tout en s'assurant que les adresses déjà attribuées ne sont pas simultanément fournies à plusieurs applications (et en évitant les adresses réservées). Pour IPv6, la randomisation DEVRAIT s'appliquer aux 31 bits de poids faible de l'adresse.

Comme décrit à la section 6, lors du mappage des paquets IP avec une adresse de destination SSM vers des adresses multicast de couche liaison (sur les couches liaison couramment utilisées telles qu'Ethernet), l'adresse IP source du datagramme n'est pas prise en compte. Si tous les hôtes commençaient par la première adresse autorisée, il est probable que de nombreux canaux spécifiques à la source sur un LAN à support partagé utiliseraient la même adresse multicast de couche liaison. En conséquence, le trafic destiné aux abonnés d'un canal serait livré au module IP d'un autre, qui devrait alors rejeter le datagramme.

Le système d'exploitation de l'hôte DEVRAIT fournir une interface permettant aux applications de demander une attribution unique d'adresse de destination de canal avant le début d'une session, et cette base de données d'attribution DEVRAIT persister après le redémarrage de l'hôte. En fournissant des attributions persistantes, les applications hôtes peuvent annoncer la session sur une page web ou dans un autre répertoire avant le début de la session. (Nous notons que ce problème n'est pas spécifique aux applications SSM — le même problème existe pour l'ASM.)

Ce document ne définit ni l'interface pour demander ou retourner des adresses, ni l'algorithme hôte pour stocker ces attributions. Un API abstrait raisonnable est défini dans le RFC 2771 [RFC2771]. Notez que le RFC 2771 permet aux applications de demander des adresses dans une plage d'adresses spécifique. Si cette interface est utilisée, l'adresse de début de la plage DEVRAIT être choisie aléatoirement par l'application.

Pour IPv6, les adresses de canal SSM à portée administrative sont créées en choisissant un identifiant de portée approprié pour l'adresse de destination SSM. Les limites de portée multicast IPv6 normales [SCOPINGv6] s'appliquent au trafic envoyé aux adresses de destination SSM, y compris toutes les limites pertinentes appliquées aux adresses source et de destination.

Aucune plage d'adresses à portée administrative globalement cohérente n'a encore été définie pour le multicast spécifique à la source IPv4 [ADMIN-SCOPE]. Pour IPv4, la portée administrative des adresses SSM dans un domaine administratif PEUT être réalisée en filtrant le trafic SSM sortant envoyé aux adresses de portée aux routeurs frontières du domaine.