RFC 4607

Source-Specific Multicast for IP

📅 published August 2006, from ietf

RFC 4607: Source-Specific Multicast for IP 💖

okay bestie, this one is the spec for source-specific multicast (SSM) 🦋 It's a Standards Track doc from August 2006, written by H. Holbrook (Arastra, Inc.) and B. Cain (Acopia Networks). It doesn't obsolete or update anything, since the header lists nothing for either. It's giving "IPv4 and IPv6 both get a reserved SSM lane" 🛣️✨

Status of This Memo ✨

This is an Internet standards track protocol for the Internet community, and it's open for discussion and suggestions for improvements 🫶 For the current standardization state and status, check the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌈

Copyright (C) The Internet Society (2006).

Abstract 🌸

okay so the abstract is basically the TL;DR 💅 IPv4 addresses in the 232/8 range (232.0.0.0 to 232.255.255.255) are designated as source-specific multicast (SSM) destination addresses, and they're reserved for source-specific apps and protocols 🔥 For IPv6, the prefix FF3x::/32 is reserved for SSM use. This doc defines an extension to the Internet network service that applies to datagrams sent to SSM addresses, and it defines the host and router requirements to support that extension 🧚

Table of Contents 🍓

1. Introduction ....................................................3
2. Semantics of Source-Specific Multicast Addresses ................5
3. Terminology .....................................................6
4. Host Requirements ...............................................7
   4.1. Extensions to the IP Module Interface ......................7
   4.2. Requirements on the Host IP Module .........................8
   4.3. Allocation of Source-Specific Multicast Addresses ..........9
5. Router Requirements ............................................10
   5.1. Packet Forwarding .........................................10
   5.2. Protocols .................................................10
6. Link-Layer Transmission of Datagrams ...........................11
7. Security Considerations ........................................12
   7.1. IPsec and SSM .............................................12
   7.2. SSM and RFC 2401 IPsec Caveats ............................12
   7.3. Denial of Service .........................................13
   7.4. Spoofed Source Addresses ..................................13
   7.5. Administrative Scoping ....................................14
8. Transition Considerations ......................................14
9. IANA Considerations ............................................15
10. Acknowledgements ..............................................15
11. Normative References ..........................................16
12. Informative References ........................................17

1. Introduction 🦋

okay so the IP multicast service model is defined in RFC 1112 [RFC1112] 💅 That RFC says a datagram sent to an IP multicast address (224.0.0.0 through 239.255.255.255) G gets delivered to each "upper-layer protocol module" that asked to receive datagrams sent to address G. RFC 1112 calls the network service behind a multicast destination address G a "host group" 👑 This model supports both one-to-many and many-to-many group communication. This doc uses the term "Any-Source Multicast" (ASM) for the model of multicast defined in RFC 1112. RFC 3513 [RFC3513] specifies the form of IPv6 multicast addresses with ASM semantics ✨

IPv4 addresses in the 232/8 range (232.0.0.0 to 232.255.255.255) are currently designated as source-specific multicast (SSM) destination addresses. They're reserved for source-specific apps and protocols [IANA-ALLOC] 🔥

For IPv6, the prefix FF3x::/32 is reserved for SSM use, where x is any valid scope identifier, by [IPv6-UBM]. Using the terminology of [IPv6-UBM], all SSM addresses must have P=1, T=1, and plen=0. [IPv6-MALLOC] mandates that the network prefix field of an SSM address also be set to zero, so all SSM addresses fall in the FF3x::/96 range 🎀 Future documents may allow a non-zero network prefix field if, for instance, a new IP-address-to-MAC-address mapping is defined. So address allocation should occur within FF3x::/96, but a system should treat all of FF3x::/32 as SSM addresses. That keeps it compatible with possible future uses of the network prefix field 🙈

Here's how the IPv6 ranges break down:

  • Addresses in the range FF3x::4000:0001 through FF3x::7FFF:FFFF are reserved in [IPv6-MALLOC] for allocation by IANA.
  • Addresses in the range FF3x::8000:0000 through FF3x::FFFF:FFFF are allowed for dynamic allocation by a host, as described in [IPv6-MALLOC].
  • Addresses in the range FF3x::0000:0000 through FF3x::3FFF:FFFF are invalid IPv6 SSM addresses. ([IPv6-MALLOC] indicates that FF3x::0000:0001 to FF3x::3FFF:FFFF must set P=0 and T=0, but for SSM, [IPv6-UBM] mandates that P=1 and T=1, which is why they're labelled invalid.)

The treatment of a packet sent to such an invalid address is undefined. A router or host MAY choose to drop such a packet 🫠

Heads up: a packet sent to an invalid SSM address has no defined treatment. A router or host MAY drop it, but the spec doesn't require that.

Source-specific multicast delivery semantics apply to a datagram sent to an SSM address. A datagram with source IP address S and SSM destination address G gets delivered to each upper-layer "socket" that specifically asked for datagrams sent to address G by source S, and only to those sockets 💜 The network service identified by (S,G), for SSM address G and source host address S, is called a "channel". Unlike the ASM model of RFC 1112, SSM provides network-layer support for one-to-many delivery only 🌈

The benefits of source-specific multicast include:

  • Elimination of cross-delivery of traffic when two sources simultaneously use the same source-specific destination address. The simultaneous use of an SSM destination address by multiple sources and different applications is explicitly supported.
  • Avoidance of the need for inter-host coordination when choosing source-specific addresses, as a consequence of the above.
  • Avoidance of many of the router protocols and algorithms needed to provide the ASM service model. For instance, the "shared trees" and Rendezvous Points of the PIM - Sparse Mode (PIM-SM) protocol [PIM-SM] aren't necessary to support the source-specific model. The router mechanisms required for SSM are largely a subset of those used for ASM. For example, the shortest-path tree mechanism of the PIM-SM protocol can be adapted to provide SSM semantics 🧠

Like ASM, the set of receivers is unknown to an SSM sender. An SSM source gets neither the identity of receivers nor their number 🕵️‍♀️

SSM is especially good for dissemination-style apps with one or more senders whose identities are known before the app starts. For example, a data dissemination app that wants a secondary data source in case the primary fails over might use one channel per source and advertise both to receivers 🍓 SSM can also build multi-source apps where not all participants' identities are known in advance. In that case, the multi-source "rendezvous" functionality doesn't happen at the network layer. Just like an app that uses unicast as its transport, this functionality can be implemented by the app itself or by an application-layer library ✨

Multicast resource discovery, where a client sends a multicast query directly to a "service location group" that servers listen to, is not directly supported by SSM 🙅‍♀️

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] 📜

This document defines the semantics of source-specific multicast addresses and the policies that govern their use. In particular, it defines an extension to the Internet network service that applies to datagrams sent to SSM addresses, and it defines host extensions to support that network service. Hosts, routers, applications, and protocols that use these addresses MUST comply with the policies outlined in this document. If a host doesn't comply, it may stop itself or other hosts on the same LAN from receiving traffic sent to an SSM channel. If a router doesn't comply, SSM traffic may get delivered to parts of the network where it's unwanted, which unnecessarily burdens the network 😭

2. Semantics of Source-Specific Multicast Addresses 🎀

The source-specific multicast service is defined like this: a datagram sent with source IP address S and destination IP address G in the SSM range gets delivered to each host socket that specifically requested delivery of datagrams sent by S to G, and only to those sockets 💖

Using the terminology of [IGMPv3]:

"socket" is an implementation-specific parameter used to tell apart different requesting entities (for example, programs, processes, or communication end-points within a program or process) inside the requesting host. The socket parameter of BSD Unix system calls is a specific example 🧚

Any host may send a datagram to any SSM address, and delivery happens according to the semantics above 🌸

The IP module interface to upper-layer protocols is extended so a socket can "Subscribe" to or "Unsubscribe" from a particular channel, identified by an SSM destination address and a source IP address. The extended interface is defined in Section 4.1. It's meaningless for an application or host to request reception of datagrams sent to an SSM destination address G (the way the any-source multicast model allows) without also specifying a corresponding source address. Routers MUST ignore any such request 🙅‍♀️

Multiple source apps on different hosts can use the same SSM destination address G with no conflict, because datagrams sent by each source host Si are delivered only to those sockets that specifically requested datagrams sent to G by Si 🫶

The key distinguishing property of this model is that a channel is identified (addressed) by the combination of a unicast source address and a multicast destination address in the SSM range. So, for example, the channel:

S,G = (192.0.2.1, 232.7.8.9)

differs from:

S,G = (192.0.2.2, 232.7.8.9)

even though they share the same destination address portion. It's giving "same G, different S, totally different channel" 💅 Similarly, for IPv6:

S,G = (2001:3618::1, FF33::1234)

and:

S,G = (2001:3618::2, FF33::1234)

are different channels 🌈

3. Terminology ✨

Okay bestie, let's get the vocab straight first, because this doc uses two different models and mixing them up is so not it 💅 To keep the any-source model and the source-specific model from getting confused, we use different words for each one 🦋

We say "channel" for the service tied to an SSM address. A channel is identified by an SSM destination address plus a specific source, so it's an (S,G) pair 🌸

We say "host group" (a term from RFC 1112) for the service tied to "regular" ASM multicast addresses, meaning everything except the SSM range. A host group is identified by just one multicast address 💜

Any host can send to a host group, and any host can send to an SSM destination address too. A packet that host S sends to an ASM destination address G gets delivered to the host group identified by G. A packet that host S sends to an SSM destination address G gets delivered to the channel identified by (S,G) 🎀 The receiver moves on a host group are called "join(G)" and "leave(G)" (same as RFC 1112 ✨). The receiver moves on a channel are called "Subscribe(S,G)" and "Unsubscribe(S,G)" 🫶

Here's the cheat sheet:

      Service Model:        any-source          source-specific
      Network Abstraction:  group               channel
      Identifier:           G                   S,G
      Receiver Operations:  Join, Leave         Subscribe, Unsubscribe

One more thing, and this is the lowkey best part 🌈 Even though this doc introduces a brand new service model apps can use, the protocols and techniques needed to support it are mostly a subset of what ASM already uses. So you're not starting from scratch, iykyk 🧚

4. Host Requirements 💖

This section is all about what hosts that support source-specific multicast need to do. It covers:

  • Extensions to the IP Module Interface
  • Extensions to the IP Module
  • Allocation of SSM Addresses

4.1. Extensions to the IP Module Interface 🎀

The IP module interface that upper-layer protocols talk to gets an upgrade so protocols can ask for every datagram sent to a particular channel. Main character energy 👑

   Subscribe ( socket, source-address, group-address, interface )

   Unsubscribe ( socket, source-address, group-address, interface )

where

   "socket" is as previously defined in Section 2,

and, paraphrasing [IGMPv3],

   "interface" is a local identifier of the network interface on
   which reception of the channel identified by the (source-
   address,group-address) pair is to be enabled or disabled.  A
   special value may be used to indicate a "default" interface.  If
   reception of the same channel is desired on multiple interfaces,
   Subscribe is invoked once for each.

Okay so these are strictly abstract functional interfaces, which just means the actual functionality can be built in any implementation-specific way 🦋 For example, a host that supports the multicast source filtering application programming interface of [MSFAPI] can provide Subscribe and Unsubscribe through that API ✨ Also, when a host has been set up to know the SSM address range (whether that setup is manual or through a protocol), the host's operating system SHOULD return an error to any app that makes a non-source-specific request to receive multicast sent to an SSM destination address 🙈 Not allowed, bestie 💅

Now, a host that doesn't support these IP module interfaces (think ASM-only hosts) and their underlying protocols can't expect to reliably receive traffic on an SSM channel 💀 As specified below in Section 5.2, routers will not set up SSM forwarding state or forward datagrams in response to an ASM join request. So, no vibes, no packets 😭

Here's a tea moment ☕ Widely used implementations of the IP packet reception interface (like the recvfrom() system call in BSD Unix) don't let a receiver figure out which destination address a datagram was sent to. So on a host like that, you can't infer the destination address of a datagram when the socket receiving it is Subscribed to multiple channels. That's rough 😭 Host operating systems SHOULD provide a way for a host to determine both the source and the destination address a datagram was sent to. (As one example, the Linux operating system gives you the destination of a packet as part of the response to the recvmsg() system call 💖) Until that capability shows up, apps may be forced to use higher-layer mechanisms to figure out which channel a datagram was sent to 🌸

4.2. Requirements on the Host IP Module 🧚

Okay, this is the strict part, so pay attention 👀 An incoming datagram sent to an SSM address MUST be delivered by the IP module to every socket that has said (via Subscribe) it wants data matching the datagram's source address, destination address, and arriving interface. It MUST NOT be delivered to other sockets 🚫

When the first socket on host H subscribes to a channel (S,G) on interface I, the host IP module on H sends a request on interface I to tell neighboring routers that the host wants traffic sent by source S to source-specific multicast destination G 🦋 Likewise, when the last socket on a host unsubscribes from a channel on interface I, the host IP module sends an unsubscription request for that channel out to interface I 🫶

These requests will typically be Internet Group Management Protocol version 3 (IGMPv3) messages for IPv4, or Multicast Listener Discovery Version 2 (MLDv2) messages for IPv6 [IGMPv3,MLDv2] ✨ A host that supports the SSM service model MUST implement the host portion of [IGMPv3] for IPv4 and [MLDv2] for IPv6. It MUST also conform to the IGMPv3/MLDv2 behavior described in [GMP-SSM] 💜 Non-negotiable, periodt 💅

4.3. Allocation of Source-Specific Multicast Addresses 🌈

Now for the address drama 🍓 The SSM destination address 232.0.0.0 is reserved, and it must not be used as a destination address. Same deal for FF3x::4000:0000 🙅 The whole goal of reserving these two is to keep one invalid SSM destination for IPv4 and one for IPv6, which can be handy 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 reserved for IANA allocation too [IPv6-MALLOC]. Why reserve them? That's outlined below in Section 9, "IANA Considerations" 🎀

The policy for handing out the rest of the SSM addresses to sending applications is strictly locally determined by the sending host 💖

When a host or host operating system allocates SSM addresses dynamically, it MUST NOT allocate sequentially starting at the first allowed address 🙈 It is RECOMMENDED to allocate SSM addresses to apps randomly, while making sure allocated addresses don't go to multiple apps at the same time (and avoiding the reserved addresses) ✨ For IPv6, the randomization should apply to the lowest 31 bits of the address 🌸

Here's why this matters 🧠 As described in Section 6, mapping an IP packet with an SSM destination address onto a link-layer multicast address doesn't take the datagram's source IP address into account (on commonly used link layers like Ethernet) 🦋 If every host started at the first allowed address, then with high probability, lots of source-specific channels on shared-medium local area networks would end up using the same link-layer multicast address 😭 Traffic meant for one channel's subscriber would then get delivered to another subscriber's IP module, which would have to throw the datagram away. Messy, bestie 💀

A host operating system SHOULD provide an interface that lets an application request a unique allocation of a channel destination address ahead of a session's start, and this allocation database SHOULD persist across host reboots 🎀 Persistent allocations are the move, because an app can advertise its session before it starts, like on a web page or some other directory 💜 (Side note: this isn't specific to SSM apps, since the same problem shows up for ASM too 🫶)

This document doesn't define the interfaces for requesting or returning addresses, and it doesn't specify the host algorithms for storing those allocations 🙃 One plausible abstract API is defined in RFC 2771 [RFC2771]. Note that RFC 2771 lets an application ask for an address within a specific range of addresses. If that interface is used, the starting address of the range SHOULD be selected at random by the application 🌈

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

Okay, the IPv4 side is a little less glam 💅 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 done inside an administrative domain by filtering outgoing SSM traffic sent to a scoped address at the domain's boundary routers 🧚

5. Router Requirements 🦋

Routers have their own rules, and this one is a big deal 🔥

5.1. Packet Forwarding 💜

A router that receives an IP datagram with a source-specific destination address MUST silently drop it, unless a neighboring host or router has communicated a desire to receive packets sent from the source and to the destination address of the received packet 🙅‍♀️ No subscriber, no forwarding, no exceptions, iconic 👑

5.2. Protocols 🦋

okay so certain IP multicast routing protocols can already tell neighboring routers about source-specific joins (PIM-SM [PIM-SM] is the big one 👑), and with some light tweaks they can totally do source-specific semantics. A router that supports the SSM service model MUST implement the PIM-SSM subset of the PIM-SM protocol from [PIM-SM] and MUST implement the router portion of [IGMPv3] for IPv4 and [MLDv2] for IPv6. An SSM router MUST also conform to the IGMPv3/MLDv2 behavior described in [GMP-SSM] 💅

with PIM-SSM, getting an (S,G) forwarding path from the source S to any receiver depends on the explicit join hopping router to router from the receiver back toward the source 🧚 the protocol(s) and algorithms that pick the path for that explicit join must give you a loop-free path (no going in circles, bestie 🌀). When using PIM-SSM, the PIM-SSM implementation MUST (at least) support the ability to use the unicast topology database for this purpose.

a network can totally run SSM in the SSM address range and any-source multicast in the rest of the multicast address space at the same time, and it is expected that this will be commonplace ✨ in that kind of network, a router may get a non-source-specific, or "(,G)" in conventional terminology, request for traffic in the SSM range from a neighbor that doesn't do source-specific multicast the way this document wants 🙈 a router that gets one of those non-source-specific requests for SSM-range data MUST NOT use it to build forwarding state and MUST NOT pass it on to other neighboring routers. A router MAY log an error in such a case. This applies both to any request from a host (like an IGMPv1 or IGMPv2 [IGMPv2] host report) and to any request from a routing protocol (like a PIM-SM (,G) join). The inter-router case is further discussed in Section 8, "Transition Considerations" 🎀

it is essential that all routers in the network give source-specific semantics to the same range of addresses if you want the full benefit of SSM 😭 to comply with this specification, a router MUST treat ALL IANA-allocated SSM addresses with source-specific semantics. no exceptions, periodt 💀

source-specific multicast packets get sent over link-layer networks as specified in RFC 1112 for IPv4 and as in [ETHERv6] for IPv6. here's the tea: on most shared-medium link-layer networks that support multicast (Ethernet is the classic example), the IP source address isn't used when picking the link-layer destination address 👀 so on those networks, every packet sent to destination address G gets delivered to any host subscribed to any channel (S,G), no matter what S is. that's giving chaos 😩 which is why the IP module MUST filter packets it receives from the link layer before handing them up to the socket layer. filter it, bestie 🫶

7. Security Considerations 🔐

this section is where we get serious, okay? 🔥 we cover IPsec, denial-of-service attacks, source spoofing, and security issues tied to administrative scoping. buckle up 🎢

7.1. IPsec and SSM 🛡️

the IPsec Authentication Header (AH) and Encapsulating Security Payload (ESP) can be used to secure SSM traffic, as long as the receivers are using a multicast-capable implementation of IPsec (as required in [RFC4301]) ✨

7.2. SSM and RFC 2401 IPsec Caveats 💔

for existing implementations of RFC 2401 IPsec (now superseded by [RFC4301]), there are a few caveats related to SSM, and I'm listing them here so nobody gets caught off guard 🙈 in RFC 2401 IPsec, the source address isn't part of the key in the SAD lookup. so two senders that happen to use the same SSM destination address and the same Security Parameter Index (SPI) will "collide" in the SAD at any host receiving both channels 😱 because the channel addresses and SPIs are both picked autonomously by the senders, there's no reasonable way to make sure each sender uses a unique destination address or SPI.

a problem pops up if a receiver subscribes to two unrelated IPsec channels whose sources happen to be using the same IP destination address (IPDA) and the same IPsec SPI. since the channel destination addresses are picked autonomously by senders, any two hosts can use the same destination address at the same time, and there's no reasonable way to make sure that doesn't happen. the <IPDA,SPI> tuple, though, is 56 bits that are generally randomly chosen (24 bits of the IP destination and 32 bits of the SPI), so a conflict is unlikely to happen by random chance 🎲

if a collision does happen, a receiver won't be able to receive IPsec-protected traffic from the two colliding sources at once 😭 a receiver can spot this by noticing it's getting traffic from two different sources with the same SPI and the same SSM destination address.

7.3. Denial of Service 🚨

a subscription request creates (S,G) state in a router to record the subscription, kicks off processing on that router, and possibly causes processing at neighboring routers too. a host can mount a denial-of-service attack by requesting a huge number of subscriptions 💀 denial of service can result if:

  • a large amount of traffic arrives when it was otherwise undesired, eating up network resources to deliver it and host resources to drop it;
  • a large amount of source-specific multicast state gets created in network routers, using router memory and CPU to store and process it; or
  • a large amount of control traffic is generated to manage the source-specific state, using router CPU and network bandwidth.

to reduce the damage from such an attack, a router MAY have configuration options to limit, for example, the following items:

  • The total rate at which all hosts on any one interface are allowed to initiate subscriptions (to limit the damage caused by forged source-address attacks).
  • The total number of subscriptions that can be initiated from any single interface or host.

any decision by an implementor to artificially limit the rate or number of subscriptions should be taken carefully, though 🥺 future applications may use large numbers of channels, and tight limits on the rate or number of channel subscriptions would block the deployment of those apps. a router SHOULD verify that the source of a subscription request is a valid address for the interface it came in on. failing to do that would make a spoofed-source address attack even worse 😤

we note that these attacks aren't unique to SSM -- they show up for any-source multicast too 🫠

7.4. Spoofed Source Addresses 🎭

by forging the source address in a datagram, an attacker can potentially break the SSM service model by sending datagrams on a channel that belongs to another host 👀 so an application that needs strong authentication should not assume that every packet arriving on a channel came from the requested source without higher-layer authentication mechanisms. the IPSEC Authentication Header [RFC2401, RFC4301] may be used to authenticate the source of an SSM transmission, for instance 🔑

some protection against spoofed source addresses in multicast is already pretty widespread, because the commonly deployed IP multicast routing protocols [PIM-DM, PIM-SM, DVMRP] include a "reverse-path forwarding check" that validates a multicast packet arrived on the expected interface for its source address ✅ routing protocols used for SSM SHOULD include such a check.

Source Routing [RFC791] (both Loose and Strict), combined with source address spoofing, may be used to let an impostor of the true channel source inject packets onto an SSM channel 🕵️ an SSM router SHOULD by default disallow source routing to an SSM destination address. a router MAY have a configuration option to allow source routing. anti-source-spoofing mechanisms, like source address filtering at the edges of the network, are also strongly encouraged 🙌

7.5. Administrative Scoping 🗺️

administrative scoping should not be relied upon as a security measure [ADMIN-SCOPE]; however, in some cases it's part of a security solution 🤓 it should be noted that no administrative scoping exists for IPv4 source-specific multicast. an alternative approach is to manually configure traffic filters to create that scoping if necessary.

furthermore, for IPv6, neither source nor destination address scoping should be used as a security measure. in some currently-deployed IPv6 routers (the ones that don't conform to [SCOPINGv6]), scope boundaries aren't always applied to every source address (for instance, an implementation might filter link-local addresses but nothing else) 😵 a router like that may incorrectly forward an SSM channel (S,G) through a scope boundary for S.

8. Transition Considerations 🌷

a host that complies with this document will send ONLY source-specific host reports for addresses in the SSM range 💖 as said above, a router that gets a non-source-specific (like IGMPv1 or IGMPv2 or MLDv1 [RFC2710]) host report for a source-specific multicast destination address MUST ignore those reports. failing to do so would violate the SSM service model promised to the sender: that a packet sent to (S,G) would only be delivered to hosts that specifically asked for packets sent to G by S. big promise, big deal 🤝

during a transition period, it would be possible to deliver SSM datagrams in a domain where the routers don't support SSM semantics by simply forwarding any packet destined to G to all hosts that have requested a subscription to (S,G) for any S 🤷‍♀️ but this approach risks unduly burdening the network infrastructure by delivering (S,G) datagrams to hosts that never asked for them 😬 an implementation like that for addresses in the SSM range is specifically not compliant with Section 5.2 of this document. not it 🙅‍♀️

9. IANA Considerations 📋

IANA allocates IPv4 addresses in the range 232.0.0.1 through 232.0.0.255 and IPv6 addresses in the range FF3x:4000:0001 to FF3x::7FFF:FFFF. these addresses are allocated according to IETF Consensus [IANA-CONSID]. these address ranges are reserved for services with wide applicability that either require that or would strongly benefit if all hosts use a well-known SSM destination address for that service 🌟 any proposal for allocation must consider the fact that, on an Ethernet network, all datagrams sent to any SSM destination address get transmitted with the same link-layer destination address, regardless of the source 🫣 furthermore, the fact that SSM destinations in 232.0.0.0/24 and 232.128.0.0/24 use the same link-layer addresses as the reserved IP multicast group range 224.0.0.0/24 must also be considered. similar consideration should be given to the IPv6 reserved multicast addresses. 232.0.0.0 and FF3x::4000:0000 should not be allocated, as suggested above 🙅

except for the aforementioned addresses, IANA SHALL NOT allocate any SSM destination address to a particular entity or application 🚫 doing that would wreck one of the big benefits of the source-specific model: the ability for a host to simply and autonomously allocate a source-specific multicast address from a huge flat address space. that's the whole magic, okay 🦄✨

10. Acknowledgements 🌸

okay bestie, big thank-you energy time 🫶 The SSM service model is built on a bunch of earlier work on other ways to do IP multicast. That includes the EXPRESS multicast model from Holbrook and Cheriton [EXPRESS], Green's [SMRP], and the Simple Multicast proposal from Perlman, et al. [SIMPLE]. Huge thanks also to Jon Postel and David Cheriton for backing the move of the 232/8 address range over to SSM 👑. Brian Haberman did the IPv6 part of this document ✨, and Pekka Savola gave it a careful review 💖.

11. Normative References

These are the docs you need to read alongside this one 📚

  • [ETHERv6] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998.
  • [GMP-SSM] Holbrook, H. and B. Cain, "Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific Multicast", RFC 4604, August 2006.
  • [IGMPv3] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.
  • [IPv6-UBM] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 Multicast Addresses", RFC 3306, August 2002.
  • [IPv6-MALLOC] Haberman, B., "Allocation Guidelines for IPv6 Multicast Addresses", RFC 3307, August 2002.
  • [MLDv2] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
  • [PIM-SM] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas. "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006.
  • [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
  • [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
  • [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
  • [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.
  • [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.

12. Informative References

These are extra reading, handy for the backstory 🧚

  • [ADMIN-SCOPE] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 2365, July 1998.
  • [DVMRP] Waitzman, D., Partridge, C., and S. Deering, "Distance Vector Multicast Routing Protocol", RFC 1075, November 1988.
  • [EXPRESS] Holbrook, H., and Cheriton, D. "Explicitly Requested Source-Specific Multicast: EXPRESS support for Large-scale Single-source Applications." Proceedings of ACM SIGCOMM '99, Cambridge, MA, September 1999.
  • [IANA-ALLOC] Internet Assigned Numbers Authority, http://www.iana.org/assignments/multicast-addresses.
  • [IANA-CONSID] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
  • [IGMPv2] Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, November 1997.
  • [MSFAPI] Thaler, D., Fenner, B., and B. Quinn, "Socket Interface Extensions for Multicast Source Filters", RFC 3678, January 2004.
  • [PIM-DM] Adams, A., Nicholas, J., and W. Siadak, "Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)", RFC 3973, January 2005.
  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
  • [RFC2771] Finlayson, R., "An Abstract API for Multicast Address Allocation", RFC 2771, February 2000.
  • [SCOPINGv6] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, March 2005.
  • [SIMPLE] R. Perlman, C-Y. Lee, A. Ballardie, J. Crowcroft, Z. Wang, T. Maufer, C. Diot, and M. Green, "Simple Multicast: A Design for Simple, Low-Overhead Multicast", Work in Progress, October 1999.
  • [SMRP] Green, M. "Method and System of Multicast Routing for Groups with a Single Transmitter." United States Patent Number 5,517,494.

Authors' Addresses 💌

Brad Cain
Acopia Networks

EMail: `bcain99@gmail.com`
Hugh Holbrook
Arastra, Inc.
P.O. Box 10905
Palo Alto, CA 94303

Phone: +1 650 331-1620
EMail: holbrook@arastra.com

Copyright (C) The Internet Society (2006).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property 🔐

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Acknowledgement 💜

Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). 🎀

📦 where this page comes from