RFC 5135

IP Multicast Requirements for a Network Address Translator (NAT) and a Network Address Port Translator (NAPT)

📅 published February 2008, from ietf

IP Multicast Requirements for a Network Address Translator (NAT) and a Network Address Port Translator (NAPT) 💖

  • RFC: 5135 🦋
  • Stream: Network Working Group
  • Authors: D. Wing and T. Eckert, both at Cisco Systems, Inc. 👑
  • Category: Best Current Practice (it's BCP 135) ✨
  • Date: February 2008
  • Obsoletes / Updates: Nothing listed in the header, so it doesn't obsolete or update any other RFC 🌈

Status of This Memo 📜

Okay so this doc is an Internet Best Current Practice for the Internet Community, and it's literally asking for discussion and suggestions to make it better 🫶 Distribution of this memo is unlimited, so share it with everyone 💅

Abstract 🎀

This doc lays out requirements for a Network Address Translator (NAT) and a Network Address Port Translator (NAPT) that support Any Source IP Multicast or Source-Specific IP Multicast. An IP multicast-capable NAT device that follows these requirements can make IP multicast apps work better, even when those apps have no idea a NAT device is in the way 🦋

Table of Contents 🗂️

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
2.  Terminology Used in This Document  . . . . . . . . . . . . . .  2
3.  Background . . . . . . . . . . . . . . . . . . . . . . . . . .  3
4.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . .  5
  4.1.  NATing IP Multicast Data Packets . . . . . . . . . . . . .  5
    4.1.1.  Receiving Multicast Data Packets . . . . . . . . . . .  5
    4.1.2.  Sending Multicast Data Packets . . . . . . . . . . . .  5
  4.2.  IGMP Version Support . . . . . . . . . . . . . . . . . . .  6
    4.2.1.  IGMPv1 or IGMPv2 . . . . . . . . . . . . . . . . . . .  7
    4.2.2.  IGMPv3 . . . . . . . . . . . . . . . . . . . . . . . .  7
  4.3.  Any Source Multicast Transmitters  . . . . . . . . . . . .  8
5.  Requirements Summary . . . . . . . . . . . . . . . . . . . . .  9
6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 12
8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
  8.1.  Normative References . . . . . . . . . . . . . . . . . . . 12
  8.2.  Informative References . . . . . . . . . . . . . . . . . . 13
Appendix A.  Application Considerations  . . . . . . . . . . . . . 14

1. Introduction 🌸

Okay this part is the main reason we're here 😭 For IP multicast apps to vibe well over NATs, multicast UDP has to work as smoothly as unicast UDP. The problem is that NATs are kinda inconsistent with IP multicast, and that leads to messy user experiences and IP multicast that just… doesn't work 💀

This doc is all about requirements that help Any Source Multicast and Source-Specific Multicast work correctly on devices that run IGMP proxy routing and NAT, without NAT being applied to IP multicast group addresses. This setup is the expected best practice for residential access routers, small branch routers, or similar gear 🏠✨

Most of the ideas here also apply when you use other protocols, like Protocol Independent Multicast - Sparse Mode (PIM-SM), or when you do NAT between multiple "inside" interfaces. But detailed coverage of those situations is outside the scope of this document, so we're not going there today 🙈

This doc describes how a device behaves when it's a NAT for unicast flows and also forwards IP multicast traffic in either direction ('inside' to 'outside', or 'outside' to 'inside'). That lets a host 'inside' the NAT both receive multicast traffic and source multicast traffic 🦋 Hosts on the 'inside' interface(s) of a NAT say they want an IP multicast flow by sending an IGMP message to their local interface. The IP multicast-capable NAT sees that IGMP message (IGMPv1 [RFC1112], IGMPv2 [RFC2236], IGMPv3 [RFC3376]), might do some stuff with it, and forwards it to its upstream router. The upstream router then sends that IP multicast traffic to the NAT, which forwards it to the 'inside' segment(s) with hosts that previously sent IGMP messages for that traffic. Main character energy 👑

Out of scope for this doc are PIM-SM [RFC4601] and IPv6 [RFC2460]. The IGMP Proxy devices scoped in this document don't forward PIM-SM. IPv6 is out of scope because NAT isn't considered necessary with IPv6 🧚

This doc is a companion to "NAT Behavioral Requirements for Unicast UDP" [RFC4787] 💜

2. Terminology Used in This Document 📖

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]. These are the official requirement words, so they're the ones to pay attention to 🎀

In this document, the term "NAT" covers both a Network Address and Port Translator (NAPT) and a NAT that doesn't translate ports 🍓

The term 'inside' refers to the interface(s) on a NAT that contain hosts wanting to source or receive IP multicast traffic. The term 'outside' refers to the interface(s) the NAT forwards IGMP membership messages to, and where the NAT routes IP multicast traffic that comes from hosts on its 'inside' interface ✨

3. Background 🧚‍♀️

When a NAT isn't used, a host might be connected to the Internet in a setup like this:

                         +-------------+
              +------+   |  DSL modem  |    +------------+
              | host +---+     or      +-//-+ WAN Router |
              +------+   | cable modem |    +------------+
                         +-------------+

Figure 1: Network without NATing IGMP Proxy

If, instead of a single host like in Figure 1, you want one or more LANs with potentially lots of hosts connected, using the same kind of service termination on the DSL or cable modem, you add a NAT device like in Figure 2. This device generally does routing and NAT functions, so it looks like a single host to the DSL/cable modem 💅

       +----+   +-------------+
       |host+---+ +---------+ |  +-----------+
       +----+   | |Multicast| |  | DSL modem |    +------------+
                | |  Proxy  | +--+    or     +-//-+ WAN Router |
      'inside'  | +---------+ |  |cable modem|    +------------+
     interfaces |             |  +-----------+
                |  +------+   |
       +----+   |  | NAT  |   | 'outside'
       |host+---+  +------+   | interfaces
       +----+   +-------------+
             IGMP Proxy NAT Device

Figure 2: Network with NATing IGMP Proxy

In IP multicast, IGMP is the protocol that hosts (like the one in Figure 1) use. For the NAT device in Figure 2 to look like a single host for IP multicast services towards the DSL/cable modem, and to forward IP multicast traffic from and to the multiple hosts in the picture, it needs to do so-called "IGMP Proxying" [RFC4605], but also do NAT at the same time. NAT isn't covered by [RFC4605]. Adding NAT to IGMP proxying doesn't need to change how IGMP messages are processed, as defined in RFC 4605:

IGMP messages are never logically forwarded by the IGMP proxying device, but rather sourced or received by it. In general, receipt of IGMP messages by the device updates the device's IGMP state. The updated state changes the device's forwarding of multicast messages or triggers the sending of IGMP messages. "Forwarding" of IGMP protocol messages may thus only happen implicitly by implementation optimizations that create shortcuts in this machinery.

This specifically means IGMP protocol packets sent by the NAT device always use the IP address of the interface ('inside' or 'outside') they're sent from. Those packets are logically "sourced," not "forwarded," so NAT has no impact on this 🫶

Unlike unicast flows, packets with a multicast destination IP address don't have their destination IP address or destination port changed by a NAT. However, their source IP address (and source UDP port, in some cases with a NAPT) changes if the packet goes from an 'inside' interface of a NAT to the 'outside' interface of a NAT, which is pretty similar to what happens to unicast packets across those same interfaces 🌈

Adding NAT to IGMP proxying changes how IP multicast data packets are processed when they're forwarded across the IGMP proxying device, as described in the following sections. These changes actually make it easier to deploy IGMP proxying over a device that does not perform NAT 🍓

With an IGMP Proxy NAT Device, IP multicast data traffic sourced from hosts on the 'inside' gets NATed so it looks like it's being sourced from a host directly connected to the WAN router. That gets rid of all the non-standard PIM-SM concerns and configurations described in Section 3.2 of [RFC4605] 🎀 Bye bye, messy configs 🧹

4. Requirements 💅

4.1. NATing IP Multicast Data Packets ✨

4.1.1. Receiving Multicast Data Packets 📥

REQ-1: For IP multicast packets forwarded to a host(s) on its 'inside' interface(s), a NAT MUST NOT modify the destination IP address or destination port of the packets. 🙅‍♀️

If a NAT were to modify the destination IP or port addresses, it would also need to modify session announcements (e.g., electronic program guides, Session Announcement Protocol (SAP)) and session establishment and control messages (e.g., SIP, Real Time Streaming Protocol (RTSP)). Changing application messages like that isn't considered a best practice 😬 On top of that, a NATed multi-homed network would need to coordinate that rewriting between its NATs, which is a whole mess 🌀

REQ-2: A NAT MUST forward IP multicast UDP datagrams from its 'outside' interface to multicast receivers on its 'inside' interface(s). 🦋

REQ-3: A NAT SHOULD forward IP multicast non-UDP protocols (e.g., Pragmatic General Multicast (PGM) [RFC3208], Resource Reservation Protocol (RSVP) [RFC2205]) from its 'outside' interface to IP multicast receivers on its 'inside' interface(s). 🌸

4.1.2. Sending Multicast Data Packets ✨

okay so this one is basically normal NAT behavior for unicast packets, the stuff from [RFC4787], but we're extending it so IP multicast senders behind the NAT get love too 💖

  • REQ-4: A NAT MUST modify the source IP address of packets that arrive from an 'inside' interface towards the 'outside' interface so that those packets use the NAT's 'outside' IP address(es). 🌸
    • a: If the NAT also performs port translation (that is, it is a NAPT), the NAT MUST also create a mapping to allow responses to that IP multicast packet to be received by the appropriate host. For Any Source Multicast, also see Section 4.3.
    • b: To allow hosts to learn the NAT's 'outside' interface address, the NAT MUST have "Endpoint-Independent Mapping" behavior (REQ-1 of [RFC4787]), no matter if the destination IP address is a unicast address or an IP multicast address. 🦋
    • c: If the NAT has multiple public IP addresses, the NAT SHOULD have an address pooling behavior of "Paired" (as described in Section 4.1 of [RFC4787]) for its IP multicast mappings as well as for its unicast UDP mappings. This lets a multicast source find the NAT's public IP address using a unicast address discovery mechanism (e.g., [ICE]) and pass that discovered IP address along to a multicast receiver. 🧚
  • REQ-5: A NAT MUST forward IP multicast UDP datagrams from its 'inside' interface(s) to its 'outside' interface.
    • a: NATs that support the above requirement MUST also provide a configuration option to disable this feature. Otherwise, a multihomed network would cause duplicate instances of the multicast data traffic on the public network. 🙈

okay so bestie, here's the vibe check: many NATs sit right next to bandwidth-constrained access links, so it is super important that IP multicast senders talking to IP multicast receivers behind the NAT don't eat up bandwidth on that access link 💅. The way this gets handled is by applications using administratively scoped IP addresses. Similarly, link-local multicast traffic isn't supposed to be routed off the local network, so it's giving "stay home" energy 🏠.

  • REQ-6: The NAT's default configuration MUST NOT forward administratively scoped IP multicast traffic (239.0.0.0/8) [RFC2365] from its 'inside' interface(s) to its 'outside' interface.
  • REQ-7: The NAT MUST NOT forward Local Network Control Block (224.0.0/24) [RFC3171] (also known as "link-local multicast") traffic from its 'inside' interface(s) to its 'outside' interface. 🚫

4.2. IGMP Version Support 🎀

  • REQ-8: A NAT MAY support IGMPv1 (although IGMPv1 is considered obsolete).
  • REQ-9: A NAT MUST support IGMPv2.
  • REQ-10: A NAT SHOULD support IGMPv3. 💜

4.2.1. IGMPv1 or IGMPv2

for IGMPv1 and IGMPv2, a NAT can totally work just by forwarding IGMP membership reports and queries between the interested hosts (on its internal interface) and its external interface. easy mode 🍓

  • REQ-11: If a NAT supports IGMPv1 and/or IGMPv2 (but not IGMPv3), the NAT MAY simply receive IGMP membership reports on the 'inside' interface, NAT them, and relay the IGMP membership report, and do the same function in the opposite direction to the IGMP listeners. That is, the NAT does not need to do any aggregation of IGMP messages.
    • a: If a NAT relays IGMPv1 or IGMPv2 messages in this manner, it MUST NOT decrement the TTL of the IGMP messages, as they are already sent with TTL=1. 👑
    • b: However, it is RECOMMENDED that such a NAT implement IGMP/MLD Proxying [RFC4605], because IGMP aggregation provides a useful optimization. ✨

4.2.2. IGMPv3

okay so this is where it gets spicy 🌶️. When an IGMPv3 proxying device receives an IGMP membership on an 'inside' interface, it creates its own IGMP proxying membership state and its own IGMP forwarding table. Then it creates an independent IGMP membership report on its 'outside' interface reporting the IP multicast groups/channels. But there is no direct relationship or "forwarding" of IGMP membership reports or queries across the interfaces. The NAT device will later receive an IP multicast data packet on the 'outside' interface and forward the IP multicast packet to the 'inside' interface(s) based on its IGMP forwarding table.

By performing NAT on IGMPv3 membership reports, the membership reports appear to come from a single IGMPv3 reporter instead of different reporters. IGMPv3 has different types of membership reports that tell apart status (IS_INCLUDE, IS_EXCLUDE) and change indication (e.g., TO_INCLUDE, TO_EXCLUDE). So if a NAT were to interleave reports from two or more reporters (joining and leaving the same groups), the NAT would create a sequence of packets that are not compliant with an IGMPv3 reporter [RFC3376]. 😭 For this reason, the following requirements are specified:

  • REQ-12: If a NAT supports IGMPv3, the NAT MUST implement IGMP/MLD Proxying [RFC4605]. Such compliance causes the NAT to aggregate the IGMPv3 membership reports and report only the aggregated information upstream.
  • REQ-13: If a NAT supports IGMPv3, the NAT MUST implement Source-Specific Multicast (SSM) for IP [RFC4607] and IGMPv3/MLDv2 for SSM [RFC4604]. 🔥
Failure to implement IGMP aggregation [RFC4605] will cause undesired temporary black holing of IP multicast traffic. For example, consider two hosts behind the same NAT. If one host is joining a session at the same time another is leaving the session, and the NAT were to merely relay the join and leave upstream, the session will be terminated, and the join and leave announcements would not comply with Section 5 of [RFC3376]. 💀

4.3. Any Source Multicast Transmitters 🦋

Any Source Multicast (ASM) uses the IP addresses in the 224/8 through 231/8, and 233/8 through 239/8 range [IANA-ALLOC].

okay so picture this: a host both receives an ASM stream AND sends traffic into it, using RTP [RFC3550]. That's where things can get messy if a NAT merely followed the requirements of [RFC4787]. RTP uses the source transport address (source IP address and source UDP port) and the Real-time Transport Protocol / RTP Control Protocol (RTP/RTCP) SSRC value to identify session members. If a session member sees the same SSRC arrive from a different transport address, that session member will perform RTP collision detection (Section 8.2 of [RFC3550]).

Now the drama: if a NAT merely followed the requirements of [RFC4787] and timed out a UDP session after 2 minutes of inactivity, and RTCP receiver reports are sent less often than every 2 minutes, then RTP collision detection would be performed by other session members sharing the same SSRC. That complicates diagnostic tools and can potentially interfere with jitter buffer algorithms 🙃. This situation can occur, for example, with an IP multicast group of approximately 300 members with a normal 50 Kbps audio RTP stream.

Source-Specific Multicast doesn't need this long timer, because application feedback reports are unicast (rather than IP multicast), and identifiers, rather than IP addresses and UDP ports, are used to identify a specific IP multicast receiver (e.g., [RTCPSSM]. 🌈

  • REQ-14: If a host on the 'inside' interface of a NAT belongs to an Any Source Multicast host group and the host sends a UDP packet to the same group, the NAT SHOULD have a UDP mapping timer of 60 minutes for that mapping. 💖
    • a: This UDP mapping SHOULD be destroyed when the host leaves that host group. The NAT is aware of this through receipt of an IGMP message from the host.
    • b: If a NAT has exhausted its resources, the NAT MAY time out that mapping before 60 minutes have elapsed, but this is discouraged. Note that even in a situation with resource exhaustion, a NAT is still required to follow the minimum mapping duration of 2 minutes (REQ-5 of [RFC4787]). 🫶

5. Requirements Summary ✨

okay bestie, this section is the cheat sheet 📝 everything you need, all in one place. let's gooo 💖

  • REQ-1: For IP multicast packets that get forwarded to a host(s) on its 'inside' interface(s), a NAT MUST NOT modify the destination IP address or destination port of the packets. 🎀
  • REQ-2: A NAT MUST forward IP multicast UDP datagrams from its 'outside' interface to multicast receivers on its 'inside' interface(s). 🦋
  • REQ-3: A NAT SHOULD forward IP multicast non-UDP protocols (e.g., PGM [RFC3208], RSVP [RFC2205]) from its 'outside' interface to IP multicast receivers on its 'inside' interface(s). 🌸
  • REQ-4: A NAT MUST modify the source IP address of packets that arrive from an 'inside' interface towards the 'outside' interface, so those packets use the NAT's 'outside' IP address(es). 💅
    • a: If the NAT also does port translation (so it's a NAPT), the NAT MUST also create a mapping so responses to that IP multicast packet can reach the right host. For Any Source Multicast, also see Section 4.3. 🧚
    • b: So hosts can learn the NAT's 'outside' interface address, the NAT MUST have "Endpoint-Independent Mapping" behavior (REQ-1 of [RFC4787]), no matter whether the destination IP address is unicast or IP multicast. 👑
    • c: If the NAT has multiple public IP addresses, the NAT SHOULD use an address pooling behavior of "Paired" (as described in Section 4.1 of [RFC4787]) for its IP multicast mappings AND its unicast UDP mappings. This lets a multicast source discover the NAT's public IP address using a unicast address discovery mechanism (e.g., [ICE]) and pass that discovered address on to a multicast receiver. 🫶
  • REQ-5: A NAT MUST forward IP multicast UDP datagrams from its 'inside' interface(s) to its 'outside' interface. ✨
    • a: NATs that support the above requirement MUST also provide a configuration option to disable this feature. Otherwise, a multihomed network would cause duplicate instances of the multicast data traffic on the public network. 🙈
  • REQ-6: The NAT's default configuration MUST NOT forward administratively scoped IP multicast traffic (239.0.0.0/8) [RFC2365] from its 'inside' interface(s) to its 'outside' interface. 💜
  • REQ-7: The NAT MUST NOT forward Local Network Control Block (224.0.0/24) [RFC3171] traffic (also known as "link-local multicast") from its 'inside' interface(s) to its 'outside' interface. 🚫
  • REQ-8: A NAT MAY support IGMPv1 (although IGMPv1 is considered obsolete). 🍓
  • REQ-9: A NAT MUST support IGMPv2. 🌈
  • REQ-10: A NAT SHOULD support IGMPv3. ⭐
  • REQ-11: If a NAT supports IGMPv1 and/or IGMPv2 (but not IGMPv3), the NAT MAY simply receive IGMP membership reports on the 'inside' interface, NAT them, and relay the IGMP membership report, and do the same thing in the opposite direction to the IGMP listeners. In other words, the NAT does not need to do any aggregation of IGMP messages. 🎀
    • a: If a NAT relays IGMPv1 or IGMPv2 messages this way, it MUST NOT decrement the TTL of the IGMP messages, since they are already sent with TTL=1. 🧚
    • b: However, it is RECOMMENDED that such a NAT implement IGMP/MLD Proxying [RFC4605], because IGMP aggregation is a useful optimization. 🦋
  • REQ-12: If a NAT supports IGMPv3, the NAT MUST implement IGMP/MLD Proxying [RFC4605]. This compliance causes the NAT to aggregate the IGMPv3 membership reports and report only the aggregated information upstream. 💖
  • REQ-13: If a NAT supports IGMPv3, the NAT MUST implement Source-Specific Multicast (SSM) for IP [RFC4607] and IGMPv3/MLDv2 for SSM [RFC4604]. 🔥
  • REQ-14: If a host on the 'inside' interface of a NAT belongs to an Any Source Multicast host group and sends a UDP packet to that same group, the NAT SHOULD have a UDP mapping timer of 60 minutes for that mapping. 🌸
    • a: This UDP mapping SHOULD be destroyed when the host leaves that host group. The NAT knows this because it receives an IGMP message from the host. 😭
    • b: If a NAT has run out of resources, the NAT MAY time out that mapping before 60 minutes have elapsed, but this is discouraged. Note that even when resources are exhausted, a NAT is still required to follow the minimum mapping duration of 2 minutes (REQ-5 of [RFC4787]). 💀

6. Security Considerations

okay this part is SERIOUS bestie, read it carefully 🚨😭

The Security Considerations sections of IGMPv3 [RFC3376] and IGMP Proxying [RFC4605] apply to a device that complies with this document. 🔐

When a host is using RTP and participating in an Any Source Multicast session, the host's periodic RTCP receiver reports cause the NAT to create a mapping. When the group size is less than approximately 300, the RTCP reports are sent often enough that a NAT's mapping will always stay open. When the group size is larger than approximately 300, the RTCP reports are sent less frequently. The recommendation in Section 4.3 causes the NAT mapping to stay open for the whole time the host is taking part in that IP multicast session, no matter how big the group is or how often the host's RTCP transmissions happen. this is the part where the NAT doesn't forget you mid-call 🥹💜

7. Acknowledgments

big thank-you to everyone who helped write this 🫶💖

Thanks to Jari Arkko, Yiqun Cai, Stephen Casner, Remi Denis-Courmont, Lars Eggert, Gorry Fairhurst, Alfred Hines, Prashant Jhingran, Bharat Joshi, Francois Le Faucheur, Albert Manfredi, Marcus Maranhao, Bryan McLaughlin, Chris Newman, Tim Polk, Pekka Savola, Mark Townsley, Magnus Westerlund, and Stig Venaas for their assistance in writing this document. 🌷

8. References 📚

8.1. Normative References

  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [RFC2236] Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, November 1997.
  • [RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 2365, July 1998.
  • [RFC3171] Albanna, Z., Almeroth, K., Meyer, D., and M. Schipper, "IANA Guidelines for IPv4 Multicast Address Assignments", BCP 51, RFC 3171, August 2001.
  • [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.
  • [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
  • [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific Multicast", RFC 4604, August 2006.
  • [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, "Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")", RFC 4605, August 2006.
  • [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006.
  • [RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007.

8.2. Informative References

  • [IANA-ALLOC] Internet Assigned Numbers Authority, "Internet Multicast Addresses", <http://www.iana.org/assignments/multicast-addresses>.
  • [ICE] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", Work in Progress, October 2007.
  • [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
  • [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
  • [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
  • [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
  • [RFC3208] Speakman, T., Crowcroft, J., Gemmell, J., Farinacci, D., Lin, S., Leshchiner, D., Luby, M., Montgomery, T., Rizzo, L., Tweedly, A., Bhaskar, N., Edmonstone, R., Sumanasekera, R., and L. Vicisano, "PGM Reliable Transport Protocol Specification", RFC 3208, December 2001.
  • [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
  • [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006.
  • [RTCPSSM] Ott, J., Chesterfield, J., and E. Schooler, "RTCP Extensions for Single-Source Multicast Sessions with Unicast Feedback", Work in Progress, January 2008. 💅✨

Appendix A. Application Considerations ✨

okay so this appendix is all about the real-life stuff apps have to deal with 💅. SSM means listeners need to know the SSM channel (S,G), which is basically the IP source address (S) plus the IP multicast group (G). 🎀 So an SSM source has to share its IP address in its session setup message, like in its Session Description Protocol (SDP) [RFC4566] 🦋.

Now the NAT drama 😭. If the SSM sender is behind a NAT and the receivers are on the other side, the sender needs to figure out which source IP address the receivers will see. Usually that's the NAT's 'outside' IP address. That 'outside' address has to go into the session setup message (like SDP) so that listeners on the 'outside' can actually receive the channel 🌸.

If there are SSM listeners on BOTH the 'outside' and 'inside' of the NAT, it could be worth looking at ICE [ICE] in the session advertisement 🧚. How SSM and ICE fit together is a whole other story, and this document doesn't go there ✨.

Here's the messy part 💀. If several SSM sources on the 'inside' of a NAT pick the same multicast group address, they're still uniquely identifiable on the inside, since their IP addresses are unique. BUT once their multicast traffic gets NATed and sent out the NAT's public interface, you can't tell the sources apart anymore 🙈. Receivers end up with traffic from those sources all mixed together, which is a problem. The fix for this is left for future study, so it's still open 🔥. In the meantime, apps that send SSM multicast traffic are encouraged to let the user change the multicast SSM address, so people can dodge this problem if the app sits behind a NAT 💖.

A multicast source that wants its traffic to stay off routers (like, to keep it from leaving the home network) might find it useful to send with IP TTL=1 🍓. That tip works for both ASM and SSM sources 👑.

And last but not least, lots of NATs use the same private address space (like 192.168.0.0/16 [RFC1918]) 🌈. So RTP stacks are encouraged to generate CNAMEs properly. Check the end of Section 6.5.1 of [RFC3550] for the details 🫶.

Authors' Addresses ✨

Dan Wing
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA  95134
USA

EMail: dwing@cisco.com


Toerless Eckert
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA  95134
USA

EMail: eckert@cisco.com

Copyright (C) The IETF Trust (2008) 🎀.

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 legal text is kept exactly as written:

THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST 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 on the validity or scope of any Intellectual Property Rights or other rights that might be claimed to apply to the implementation or use of the technology described here, or on whether any license under those rights might or might not be available. It also doesn't say it has made any independent effort to find those rights 🦋. You can find the procedures for rights in RFC documents in BCP 78 and BCP 79 📚.

Copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the result of an attempt to get a general license or permission for implementers or users to use these proprietary rights can be obtained from the IETF's online IPR repository at http://www.ietf.org/ipr 🌸.

The IETF invites any interested party to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that may cover technology needed to implement this standard 🧚. Send that info to the IETF at ietf-ipr@ietf.org 💖.

📦 where this page comes from