4.3. Allocation des adresses de multicast spécifique à la source

L'adresse de destination SSM 232.0.0.0 est réservée et NE DOIT PAS (MUST NOT) être utilisée comme adresse de destination. De même, FF3x::4000:0000 est également réservée. Ces deux adresses sont réservées afin de conserver une adresse de destination SSM invalide pour IPv4 et IPv6, utilisable comme valeur nulle (null value) dans les implémentations. La plage d'adresses 232.0.0.1 - 232.0.0.255 est actuellement réservée pour l'allocation par l'IANA. Les adresses de destination SSM dans la plage FF3x::4000:0001 à FF3x::7FFF:FFFF sont également réservées pour l'allocation par l'IANA [IPv6-MALLOC]. La motivation de la réservation de ces adresses est esquissée dans la section 9 « Considérations IANA » (IANA Considerations) ci-dessous.

La politique d'allocation des adresses SSM restantes aux applications émettrices est strictement une décision locale de l'hôte émetteur.

Lors de l'allocation dynamique d'adresses SSM, l'hôte ou le système d'exploitation de l'hôte NE DOIT PAS (MUST NOT) allouer séquentiellement à partir de la première adresse autorisée. La pratique RECOMMANDÉE (RECOMMENDED) consiste à allouer de manière aléatoire aux applications, en veillant à ce que l'adresse allouée ne soit pas fournie simultanément à plusieurs applications (et en évitant les adresses réservées). Pour IPv6, la randomisation doit porter sur les 31 bits les moins significatifs de l'adresse.

Comme décrit à la section 6, le mappage des paquets IP avec une adresse de destination SSM vers une adresse de multidiffusion de couche liaison ne tient pas compte de l'adresse IP source du datagramme (sur les couches liaison courantes telles qu'Ethernet). Si tous les hôtes commencent à partir de la première adresse autorisée, alors sur un LAN à support partagé, de nombreux canaux spécifiques à la source risquent fort d'utiliser la même adresse de multidiffusion de couche liaison. Par conséquent, le trafic destiné à un abonné d'un canal sera remis au module IP d'un autre hôte, qui devra alors supprimer le datagramme.

Le système d'exploitation de l'hôte DOIT (SHOULD) fournir une interface permettant à une application de demander à l'avance une allocation unique d'une adresse de destination de canal avant le début de la session, et cette base de données d'allocation DOIT (SHOULD) persister après le redémarrage de l'hôte. En fournissant une allocation persistante, l'application hôte peut publier à l'avance la session sur une page Web ou un autre annuaire. (Nous notons que ce problème n'est pas spécifique aux applications SSM -- il se pose également pour ASM.)

Ce document ne définit ni l'interface pour demander ou rendre des adresses, ni l'algorithme hôte pour stocker ces allocations. La RFC 2771 [RFC2771] définit une API abstraite raisonnable. Notez que la RFC 2771 permet à une application de demander une adresse dans une plage donnée. Si cette interface est utilisée, l'adresse de début de la plage DOIT (SHOULD) être choisie aléatoirement par l'application.

Pour IPv6, les adresses de canal SSM à périmètre administratif (administratively scoped) sont créées en choisissant un identificateur de périmètre approprié pour l'adresse de destination SSM. Les limites de périmètre de multidiffusion IPv6 habituelles [SCOPINGv6] s'appliquent au trafic envoyé vers des adresses de destination SSM, y compris toutes les limites applicables aux adresses source et de destination.

Il n'existe pas encore de plage d'adresses à périmètre administratif cohérente à l'échelle du globe définie pour le multicast spécifique à la source IPv4 [ADMIN-SCOPE]. Pour IPv4, le périmètre administratif des adresses SSM peut être réalisé au sein d'un domaine administratif en filtrant le trafic SSM sortant vers une plage d'adresses aux routeurs de bordure du domaine.