4.3. Allocation of Source-Specific Multicast Addresses

The SSM destination address 232.0.0.0 is reserved, and it must not be used as a destination address. Similarly, FF3x::4000:0000 is also reserved. The goal of reserving these two addresses is to preserve one invalid SSM destination for IPv4 and IPv6, which can be useful in an implementation as a null value. The address range 232.0.0.1 - 232.0.0.255 is currently reserved for allocation by IANA. SSM destination addresses in the range FF3x::4000:0001 through FF3x::7FFF:FFFF are similarly reserved for IANA allocation [IPv6-MALLOC]. The motivation to reserve these addresses is outlined below in Section 9, "IANA Considerations".

The policy for allocating the rest of the SSM addresses to sending applications is strictly locally determined by the sending host.

When allocating SSM addresses dynamically, a host or host operating system MUST NOT allocate sequentially starting at the first allowed address. It is RECOMMENDED to allocate SSM addresses to applications randomly, while ensuring that allocated addresses are not given simultaneously to multiple applications (and avoiding the reserved addresses). For IPv6, the randomization should apply to the lowest 31 bits of the address.

As described in Section 6, the mapping of an IP packet with SSM destination address onto a link-layer multicast address does not take into account the datagram's source IP address (on commonly-used link layers like Ethernet). If all hosts started at the first allowed address, then with high probability, many source-specific channels on shared-medium local area networks would use the same link-layer multicast address. As a result, traffic destined for one channel subscriber would be delivered to another's IP module, which would then have to discard the datagram.

A host operating system SHOULD provide an interface to allow an application to request a unique allocation of a channel destination address in advance of a session's commencement, and this allocation database SHOULD persist across host reboots. By providing persistent allocations, a host application can advertise the session in advance

Holbrook & Cain Standards Track [Page 9] RFC 4607 Source-Specific Multicast August 2006

of its start time on a web page or in another directory. (We note that this issue is not specific to SSM applications -- the same problem arises for ASM.)

This document neither defines the interfaces for requesting or returning addresses nor specifies the host algorithms for storing those allocations. One plausible abstract API is defined in RFC 2771 [RFC2771]. Note that RFC 2771 allows an application to request an address within a specific range of addresses. If this interface is used, the starting address of the range SHOULD be selected at random by the application.

For IPv6, administratively scoped SSM channel addresses are created by choosing an appropriate scope identifier for the SSM destination address. Normal IPv6 multicast scope boundaries [SCOPINGv6] are applied to traffic sent to an SSM destination address, including any relevant boundaries applied to both the source and destination address.

No globally agreed-upon administratively-scoped address range [ADMIN-SCOPE] is currently defined for IPv4 source-specific multicast. For IPv4, administrative scoping of SSM addresses can be implemented within an administrative domain by filtering outgoing SSM traffic sent to a scoped address at the domain's boundary routers.