idnits 2.17.1 draft-ietf-behave-multicast-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 702. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 713. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 720. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 726. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 8, 2007) is 5976 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3171 (Obsoleted by RFC 5771) == Outdated reference: A later version (-19) exists of draft-ietf-avt-rtcpssm-13 -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) -- Obsolete informational reference (is this intentional?): RFC 4601 (Obsoleted by RFC 7761) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BEHAVE Working Group D. Wing 3 Internet-Draft T. Eckert 4 Intended status: Best Current Cisco Systems, Inc. 5 Practice November 8, 2007 6 Expires: May 11, 2008 8 IP Multicast Requirements for a Network Address (and port) Translator 9 (NAT) 10 draft-ietf-behave-multicast-12 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on May 11, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 This document specifies requirements for a Network Address (and port) 44 Translator (NAT) that supports Any Source IP Multicast or Source- 45 Specific IP Multicast. An IP multicast-capable NAT device that 46 adheres to the requirements of this document can optimize the 47 operation of IP multicast applications that are generally unaware of 48 IP multicast NAT devices. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology Used in this Document . . . . . . . . . . . . . . 3 54 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 4.1. NAT'ing IP Multicast Data Packets . . . . . . . . . . . . 6 57 4.1.1. Receiving Multicast Data Packets . . . . . . . . . . . 6 58 4.1.2. Sending Multicast Data Packets . . . . . . . . . . . . 6 59 4.2. IGMP Version Support . . . . . . . . . . . . . . . . . . . 7 60 4.2.1. IGMPv1 or IGMPv2 . . . . . . . . . . . . . . . . . . . 8 61 4.2.2. IGMPv3 . . . . . . . . . . . . . . . . . . . . . . . . 8 62 4.3. Any Source Multicast Transmitters . . . . . . . . . . . . 9 63 5. Requirements Summary . . . . . . . . . . . . . . . . . . . . . 10 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 65 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 66 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 67 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 68 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 69 9.2. Informational References . . . . . . . . . . . . . . . . . 14 70 Appendix A. Application Considerations . . . . . . . . . . . . . 15 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 72 Intellectual Property and Copyright Statements . . . . . . . . . . 17 74 1. Introduction 76 In order for IP multicast applications to function well over NATs, 77 multicast UDP must work as seamlessly as unicast UDP. However, NATs 78 have little consistency in IP multicast operation which results in 79 inconsistent user experiences and failed IP multicast operation. 81 This document targets requirements intended to enable correct 82 operations of Any Source Multicast and Source-Specific Multicast in 83 devices running IGMP proxy routing and NAT and without applying NAT 84 to IP multicast group addresses. This profile of functionality is 85 the expected best practice for residential access routers, small 86 branch routers, or similar deployments. 88 Most of the principles outlined in this document do also apply when 89 using protocols other than IGMP, such as PIM-SM, or when performing 90 NAT between multiple "inside" interfaces, but explicit consideration 91 for these cases is outside the scope of this document. 93 This document describes the behavior of a device that functions as a 94 NAT for unicast flows and also forwards IP multicast traffic in 95 either direction ('inside' to 'outside', or 'outside' to 'inside'). 96 This allows a host 'inside' the NAT to both receive multicast traffic 97 and to source multicast traffic. Hosts on the 'inside' interface(s) 98 of a NAT indicate their interest in receiving an IP multicast flow by 99 sending an IGMP message to their local interface. An IP multicast- 100 capable NAT will see that IGMP message (IGMPv1 [RFC1112], IGMPv2 101 [RFC2236], IGMPv3 [RFC3376]), possibly perform some functions on that 102 IGMP message, and forward it to its upstream router. This causes the 103 upstream router to send that IP multicast traffic to the NAT, which 104 forwards it to those inside segment(s) with host(s) that had 105 previously sent IGMP messages for that IP multicast traffic. 107 Out of scope of this document are PIM-SM [RFC4601] and IPv6 108 [RFC2460]. The IGMP Proxy devices that are scoped in this document 109 do not forward PIM-SM. IPv6 is out of scope because NAT is not 110 considered necessary with IPv6. 112 This document is a companion document to "NAT Behavioral Requirements 113 for Unicast UDP" [RFC4787]. 115 2. Terminology Used in this Document 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in RFC 2119 [RFC2119]. 121 In this document, the term "NAT" applies to both Network Address and 122 Port Translator (NAPT) as well as a NAT that does not translate 123 ports. 125 The term 'inside' refers to the interface(s) on a NAT which contain 126 hosts that wish to source or receive IP multicast traffic. The term 127 'outside' refers to the interface(s) the NAT forwards IGMP membership 128 messages to, and where the NAT routes IP multicast traffic that 129 originates from hosts on its 'inside' interface. 131 3. Background 133 When a NAT isn't used, a host might be connected to the Internet in a 134 configuration such as this: 136 +-------------+ 137 +------+ | DSL modem | +------------+ 138 | host +---+ or +-//-+ WAN Router | 139 +------+ | cable modem | +------------+ 140 +-------------+ 142 Figure 1: Network without NAT'ing IGMP Proxy 144 If instead of a single host as shown in Figure 1, one or more LANs 145 with potentially multiple hosts are to be connected, with the same 146 type of service termination on the DSL or cable modem, a NAT device 147 is added as shown in Figure 2. This device in general perform 148 routing and NAT functions such that it does look like a single host 149 towards the DSL/cable modem. 151 +----+ +-------------+ 152 |host+---+ +---------+ | +-----------+ 153 +----+ | |Multicast| | | DSL modem | +------------+ 154 | | Proxy | +--+ or +-//-+ WAN Router | 155 inside | +---------+ | |cable modem| +------------+ 156 interfaces | | +-----------+ 157 | +------+ | 158 +----+ | | NAT | | outside 159 |host+---+ +------+ | interfaces 160 +----+ +-------------+ 161 IGMP Proxy NAT Device 163 Figure 2: Network with NATing IGMP Proxy 165 In IP multicast, IGMP is the protocol used by hosts, such as the one 166 shown in Figure 1. For the NAT device in Figure 2 to look like the 167 single host for IP multicast services towards the DSL/cable modem and 168 to forward IP multicast traffic from and to the multiple hosts in the 169 picture, it needs to perform so called "IGMP Proxying" [RFC4605] -- 170 but within the context of also performing NAT. NAT is not covered by 171 [RFC4605]. Adding NAT to IGMP proxying does not need to change the 172 processing of the IGMP messages as defined in RFC4605: 174 IGMP messages are never logically forwarded by the IGMP proxying 175 device, but rather sourced or received by it. In general, receipt 176 of IGMP messages by the device updates the device's IGMP state. 177 The updated state changes the device's forwarding of multicast 178 messages or triggers the sending of IGMP messages. "Forwarding" 179 of IGMP protocol messages may thus only happen implicitly by 180 implementation optimizations that create shortcuts in this 181 machinery. 183 This specifically means that IGMP protocol packets sent by the NAT 184 device will always use IP address of the interface (inside or 185 outside) from which they are sent, but because those packets are 186 logically "sourced" and not "forwarded", NAT does not have any impact 187 into this. 189 Unlike unicast flows, packets with a multicast destination IP address 190 do not have their destination IP address or destination port changed 191 by a NAT. However, their source IP address (and source UDP port, in 192 some cases with a NAPT) is changed if the packet goes from an 193 'inside' interface of a NAT to the 'outside' interface of a NAT -- 194 similar to the behavior of a unicast packet across those same 195 interfaces. 197 Adding NAT to IGMP proxying does change the processing of IP 198 multicast data packets forwarded across the IGMP proxying device as 199 described in the following sections. These changes do actually 200 simplify the ability to deploy IGMP proxying over a device that does 201 NOT perform NAT. 203 With an IGMP Proxy NAT Device, IP multicast data traffic sourced from 204 hosts on the inside is NATed such that it will look like being 205 sourced from a directly connected host to the WAN router, thus 206 eliminating all non-standard PIM-SM concerns/configurations described 207 in section 3.2 of [RFC4605]. 209 4. Requirements 210 4.1. NAT'ing IP Multicast Data Packets 212 4.1.1. Receiving Multicast Data Packets 214 REQ-1: For IP multicast packets that are forwarded to a host(s) on 215 its inside interface(s), a NAT MUST NOT modify the 216 destination IP address or destination port of the packets. 218 If a NAT were to modify the destination IP or port addresses, the 219 NAT would also need to modify session announcements (e.g., 220 electronic program guides, SAP) and session establishment and 221 control (e.g., SIP, RTSP) messages. Such modifications of 222 application messages is not considered a best practice. 223 Furthermore, a NAT'ed multi-homed network would need to coordinate 224 such rewriting between its NATs. 226 REQ-2: A NAT MUST forward IP multicast UDP datagrams from its 227 'outside' interface to multicast receivers on its 'inside' 228 interface(s). 230 REQ-3: A NAT SHOULD forward IP multicast non-UDP protocols (e.g., 231 PGM [RFC3208], RSVP [RFC2205]) from its 'outside' interface 232 to IP multicast receivers on its inside interface(s). 234 4.1.2. Sending Multicast Data Packets 236 The following requirement is normal NAT behavior for unicast packets, 237 as described in [RFC4787], and extended here to provide support for 238 IP multicast senders behind the NAT. 240 REQ-4: A NAT MUST modify the source IP address of packets that 241 arrive from an 'inside' interface towards the 'outside' 242 interface so that those packets use the NAT's 'outside' IP 243 address(es). 245 a: If the NAT also performs port translation (that is, it 246 is a NAPT), the NAT MUST also create a mapping to allow 247 responses to that IP multicast packet to be received by 248 the appropriate host. For Any Source Multicast, also 249 see Section 4.3. 251 b: To allow hosts to learn the NAT's 'outside' interface 252 address, the NAT MUST have "Endpoint-Independent 253 Mapping" behavior (REQ-1 of [RFC4787]) no matter if the 254 destination IP address is a unicast address or an IP 255 multicast address. 257 c: If the NAT has multiple public IP addresses, the NAT 258 SHOULD have address pooling behavior of "Paired" (as 259 described in section 4.1 of [RFC4787]) for its IP 260 multicast mappings as well as for its unicast UDP 261 mappings. This allows a multicast source to discover 262 the NAT's public IP address using a unicast address 263 discovery mechanism (e.g., [I-D.ietf-mmusic-ice]) and 264 communicate that discovered IP address to a multicast 265 receiver. 267 REQ-5: A NAT MUST forward IP multicast UDP datagrams from its 268 'inside' interface(s) to its 'outside' interface. 270 a: NATs which support the above requirement MUST also 271 provide a configuration option to disable this feature. 272 Otherwise, a multihomed network would cause duplicate 273 instances of the multicast data traffic on the public 274 network. 276 As many NATs are located adjacent to bandwidth-constrained access 277 links, it is important that IP multicast senders communicating with 278 IP multicast receivers behind the NAT not have their flows consume 279 bandwidth on the access link. This is accomplished by applications 280 using administratively scoped IP addresses. Similarly, link-local 281 multicast traffic isn't supposed to be routed off the local network. 283 REQ-6: The NAT's default configuration MUST NOT forward 284 administratively scoped IP multicast traffic (239.0.0.0/8) 285 [RFC2365] from its 'inside' interface(s) to its 'outside' 286 interface. 288 REQ-7: The NAT MUST NOT forward Local Network Control Block 289 (224.0.0/24) [RFC3171] (also known as "link-local 290 multicast") traffic from its 'inside' interface(s) to its 291 'outside' interface. 293 4.2. IGMP Version Support 295 REQ-8: A NAT MAY support IGMPv1 (although IGMPv1 is considered 296 obsolete). 298 REQ-9: A NAT MUST support IGMPv2. 300 REQ-10: A NAT SHOULD support IGMPv3. 302 4.2.1. IGMPv1 or IGMPv2 304 For IGMPv1 and IGMPv2, a NAT can successfully operate by merely 305 forwarding IGMP membership reports and queries between the interested 306 hosts (on its internal interface) towards its external interface. 308 REQ-11: If a NAT supports IGMPv1 and/or IGMPv2 (but not IGMPv3), the 309 NAT MAY simply receive IGMP membership reports on the inside 310 interface, NAT them, and relay the IGMP membership report, 311 and do the same function in the opposite direction to the 312 IGMP listeners. That is, the NAT does not need to do any 313 aggregation of IGMP messages. 315 a: If a NAT relays IGMPv1 or IGMPv2 messages in this 316 manner, it MUST NOT decrement the TTL of the IGMP 317 messages, as they are already sent with TTL=1. 319 b: However, it is RECOMMENDED that such a NAT implement 320 IGMP/MLD Proxying [RFC4605], because IGMP aggregation 321 provides a useful optimization. 323 4.2.2. IGMPv3 325 When a IGMPv3 proxying device receives an IGMP membership on an 326 inside interface, it creates its own IGMP proxying membership state 327 and its own IGMP forwarding table. It then creates an independent 328 IGMP membership report on its outside interface reporting the IP 329 multicast groups/channels -- but there is no direct relationship or 330 "forwarding" of IGMP membership reports or queries across the 331 interfaces. The NAT device will subsequently receive a IP multicast 332 data packet on the 'outside' interface and forward the IP multicast 333 packet to the 'inside' interface(s) based on its IGMP forwarding 334 table. 336 By performing NAT on IGMPv3 membership reports, the membership 337 reports appear to originate from a single IGMPv3 reporter instead of 338 different reporters. Because IGMPv3 has different types of 339 membership reports differentiating between status (IS_INCLUDE, 340 IS_EXCLUDE) and change indication (e.g., TO_INCLUDE, TO_EXCLUDE), if 341 a NAT were to interleave reports from two or more reporters (joining 342 and leaving the same groups) the NAT would create a sequence of 343 packets that are not compliant with an IGMPv3 reporter [RFC3376]. 344 For this reason, the following requirements are specified: 346 REQ-12: If a NAT supports IGMPv3, the NAT MUST implement IGMP/MLD 347 Proxying [RFC4605]. Such compliance causes the NAT to 348 aggregate the IGMPv3 membership reports and report only the 349 aggregated information upstream. 351 REQ-13: If a NAT supports IGMPv3, the NAT MUST implement Source- 352 Specific Multicast for IP [RFC4607] and IGMPv3/MLDv2 for SSM 353 [RFC4604]. 355 Failure to implement IGMP aggregation ([RFC4605]) will cause 356 undesired temporary black holing of IP multicast traffic. For 357 example, consider two hosts behind the same NAT. If one host is 358 joining a session at the same time another is leaving the session, 359 and the NAT were to merely relay the join and leave upstream, the 360 session will be terminated, and the join and leave announcements 361 would not comply with section 5 of [RFC3376]. 363 4.3. Any Source Multicast Transmitters 365 Any Source Multicast (ASM) uses the IP addresses in the 224/8 through 366 231/8, and 233/8 through 239/8 range [IANA-ALLOC]. 368 When a host both receives an ASM stream and sends traffic into it, 369 using RTP [RFC3550], there is a potential problem if a NAT merely 370 followed the requirements of [RFC4787]. The problem is that RTP uses 371 the source transport address (source IP address and source UDP port) 372 and the RTP/RTCP SSRC value to identify session members. If a 373 session member sees the same SSRC arrive from a different transport 374 address, that session member will perform RTP collision detection 375 (section 8.2 of [RFC3550]). If a NAT merely followed the 376 requirements of [RFC4787] and timed out a UDP session after 2 minutes 377 of inactivity and RTCP receiver reports are sent less often than 378 every 2 minutes, RTP collision detection would be performed by other 379 session members sharing the same SSRC, complicating diagnostic tools 380 and potentially interfering with jitter buffer algorithms. This 381 situation can occur, for example, with an IP multicast group of 382 approximately 300 members with a normal 50Kbps audio RTP stream. 384 Source-Specific Multicast does not need this long timer because 385 application feedback reports are unicast (rather than IP multicast) 386 and identifiers, rather than IP addresses and UDP ports, are used to 387 identify a specific IP multicast receiver (e.g., 388 [I-D.ietf-avt-rtcpssm]. 390 REQ-14: If a host on the inside interface of a NAT belongs to an Any 391 Source Multicast host group and the host sends a UDP packet 392 to the same group, the NAT SHOULD have a UDP mapping timer 393 of 60 minutes for that mapping. 395 a: This UDP mapping SHOULD be destroyed when the host 396 leaves that host group. The NAT is aware of this 397 through receipt of an IGMP message from the host. 399 b: If a NAT has exhausted its resources, the NAT MAY time 400 out that mapping before 60 minutes have elapsed, but 401 this is discouraged. Note that even in a situation with 402 resource exhaustion, a NAT is still required to follow 403 the minimum mapping duration of 2 minutes (REQ-5 of 404 [RFC4787]). 406 5. Requirements Summary 408 This section summarizes the requirements. 410 REQ-1: For IP multicast packets that are forwarded to a host(s) on 411 its inside interface(s), a NAT MUST NOT modify the 412 destination IP address or destination port of the packets. 414 REQ-2: A NAT MUST forward IP multicast UDP datagrams from its 415 'outside' interface to multicast receivers on its 'inside' 416 interface(s). 418 REQ-3: A NAT SHOULD forward IP multicast non-UDP protocols (e.g., 419 PGM [RFC3208], RSVP [RFC2205]) from its 'outside' interface 420 to IP multicast receivers on its inside interface(s). 422 REQ-4: A NAT MUST modify the source IP address of packets that 423 arrive from an 'inside' interface towards the 'outside' 424 interface so that those packets use the NAT's 'outside' IP 425 address(es). 427 a: If the NAT also performs port translation (that is, it 428 is a NAPT), the NAT MUST also create a mapping to allow 429 responses to that IP multicast packet to be received by 430 the appropriate host. For Any Source Multicast, also 431 see Section 4.3. 433 b: To allow hosts to learn the NAT's 'outside' interface 434 address, the NAT MUST have "Endpoint-Independent 435 Mapping" behavior (REQ-1 of [RFC4787]) no matter if the 436 destination IP address is a unicast address or an IP 437 multicast address. 439 c: If the NAT has multiple public IP addresses, the NAT 440 SHOULD have address pooling behavior of "Paired" (as 441 described in section 4.1 of [RFC4787]) for its IP 442 multicast mappings as well as for its unicast UDP 443 mappings. This allows a multicast source to discover 444 the NAT's public IP address using a unicast address 445 discovery mechanism (e.g., [I-D.ietf-mmusic-ice]) and 446 communicate that discovered IP address to a multicast 447 receiver. 449 REQ-5: A NAT MUST forward IP multicast UDP datagrams from its 450 'inside' interface(s) to its 'outside' interface. 452 a: NATs which support the above requirement MUST also 453 provide a configuration option to disable this feature. 454 Otherwise, a multihomed network would cause duplicate 455 instances of the multicast data traffic on the public 456 network. 458 REQ-6: The NAT's default configuration MUST NOT forward 459 administratively scoped IP multicast traffic (239.0.0.0/8) 460 [RFC2365] from its 'inside' interface(s) to its 'outside' 461 interface. 463 REQ-7: The NAT MUST NOT forward Local Network Control Block 464 (224.0.0/24) [RFC3171] (also known as "link-local 465 multicast") traffic from its 'inside' interface(s) to its 466 'outside' interface. 468 REQ-8: A NAT MAY support IGMPv1 (although IGMPv1 is considered 469 obsolete). 471 REQ-9: A NAT MUST support IGMPv2. 473 REQ-10: A NAT SHOULD support IGMPv3. 475 REQ-11: If a NAT supports IGMPv1 and/or IGMPv2 (but not IGMPv3), the 476 NAT MAY simply receive IGMP membership reports on the inside 477 interface, NAT them, and relay the IGMP membership report, 478 and do the same function in the opposite direction to the 479 IGMP listeners. That is, the NAT does not need to do any 480 aggregation of IGMP messages. 482 a: If a NAT relays IGMPv1 or IGMPv2 messages in this 483 manner, it MUST NOT decrement the TTL of the IGMP 484 messages, as they are already sent with TTL=1. 486 b: However, it is RECOMMENDED that such a NAT implement 487 IGMP/MLD Proxying [RFC4605], because IGMP aggregation 488 provides a useful optimization. 490 REQ-12: If a NAT supports IGMPv3, the NAT MUST implement IGMP/MLD 491 Proxying [RFC4605]. Such compliance causes the NAT to 492 aggregate the IGMPv3 membership reports and report only the 493 aggregated information upstream. 495 REQ-13: If a NAT supports IGMPv3, the NAT MUST implement Source- 496 Specific Multicast for IP [RFC4607] and IGMPv3/MLDv2 for SSM 497 [RFC4604]. 499 REQ-14: If a host on the inside interface of a NAT belongs to an Any 500 Source Multicast host group and the host sends a UDP packet 501 to the same group, the NAT SHOULD have a UDP mapping timer 502 of 60 minutes for that mapping. 504 a: This UDP mapping SHOULD be destroyed when the host 505 leaves that host group. The NAT is aware of this 506 through receipt of an IGMP message from the host. 508 b: If a NAT has exhausted its resources, the NAT MAY time 509 out that mapping before 60 minutes have elapsed, but 510 this is discouraged. Note that even in a situation with 511 resource exhaustion, a NAT is still required to follow 512 the minimum mapping duration of 2 minutes (REQ-5 of 513 [RFC4787]). 515 6. Security Considerations 517 The Security Considerations sections of IGMPv3 [RFC3376] and IGMP 518 Proxying [RFC4605] apply to a device complying with this document. 520 When a host is using RTP and participating in an Any Source Multicast 521 session, the host's periodic RTCP receiver reports cause the NAT to 522 create a mapping. When the group size is less than approximately 523 300, the RTCP reports are sent frequently enough that a NAT's mapping 524 will always be kept open. When the group size is larger than 525 approximately 300, the RTCP reports are sent less frequently. The 526 recommendation in Section 4.3 causes the NAT mapping to be kept open 527 for the duration of the host's participation in that IP multicast 528 session no matter the size of the multicast host or periodicity of 529 the host's RTCP transmissions. 531 7. IANA Considerations 533 This document does not require any IANA registrations. 535 8. Acknowledgments 537 Thanks to Jari Arkko, Yiqun Cai, Stephen Casner, Remi Denis-Courmont, 538 Lars Eggert, Gorry Fairhurst, Alfred Hines, Prashant Jhingran, Bharat 539 Joshi, Francois Le Faucheur, Albert Manfredi, Marcus Maranhao, Bryan 540 McLaughlin, Chris Newman, Tim Polk, Pekka Savola, Mark Townsley, 541 Magnus Westerlund, and Stig Venaas for their assistance in writing 542 this document. 544 9. References 546 9.1. Normative References 548 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 549 Requirement Levels", BCP 14, RFC 2119, March 1997. 551 [RFC2236] Fenner, W., "Internet Group Management Protocol, Version 552 2", RFC 2236, November 1997. 554 [RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, 555 RFC 2365, July 1998. 557 [RFC3171] Albanna, Z., Almeroth, K., Meyer, D., and M. Schipper, 558 "IANA Guidelines for IPv4 Multicast Address Assignments", 559 BCP 51, RFC 3171, August 2001. 561 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 562 Thyagarajan, "Internet Group Management Protocol, Version 563 3", RFC 3376, October 2002. 565 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 566 Jacobson, "RTP: A Transport Protocol for Real-Time 567 Applications", STD 64, RFC 3550, July 2003. 569 [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet 570 Group Management Protocol Version 3 (IGMPv3) and Multicast 571 Listener Discovery Protocol Version 2 (MLDv2) for Source- 572 Specific Multicast", RFC 4604, August 2006. 574 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 575 "Internet Group Management Protocol (IGMP) / Multicast 576 Listener Discovery (MLD)-Based Multicast Forwarding 577 ("IGMP/MLD Proxying")", RFC 4605, August 2006. 579 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 580 IP", RFC 4607, August 2006. 582 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 583 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 584 RFC 4787, January 2007. 586 9.2. Informational References 588 [I-D.ietf-avt-rtcpssm] 589 Chesterfield, J., "RTCP Extensions for Single-Source 590 Multicast Sessions with Unicast Feedback", 591 draft-ietf-avt-rtcpssm-13 (work in progress), March 2007. 593 [I-D.ietf-mmusic-ice] 594 Rosenberg, J., "Interactive Connectivity Establishment 595 (ICE): A Protocol for Network Address Translator (NAT) 596 Traversal for Offer/Answer Protocols", 597 draft-ietf-mmusic-ice-19 (work in progress), October 2007. 599 [IANA-ALLOC] 600 Internet Assigned Numbers Authority, "Internet Multicast 601 Addresses", 602 . 604 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 605 RFC 1112, August 1989. 607 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 608 E. Lear, "Address Allocation for Private Internets", 609 BCP 5, RFC 1918, February 1996. 611 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 612 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 613 Functional Specification", RFC 2205, September 1997. 615 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 616 (IPv6) Specification", RFC 2460, December 1998. 618 [RFC3208] Speakman, T., Crowcroft, J., Gemmell, J., Farinacci, D., 619 Lin, S., Leshchiner, D., Luby, M., Montgomery, T., Rizzo, 620 L., Tweedly, A., Bhaskar, N., Edmonstone, R., 621 Sumanasekera, R., and L. Vicisano, "PGM Reliable Transport 622 Protocol Specification", RFC 3208, December 2001. 624 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 625 Description Protocol", RFC 4566, July 2006. 627 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 628 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 629 Protocol Specification (Revised)", RFC 4601, August 2006. 631 Appendix A. Application Considerations 633 SSM requires listeners to know the SSM channel (S,G), which is 634 comprised of the IP source address (S) and the IP multicast group 635 (G). An SSM source needs to communicate its IP address in its SSM 636 session establishment message (e.g., in its Session Description 637 Protocol (SDP) [RFC4566]). When the SSM sender is behind a NAT and 638 the SSM receiver(s) are on the other side of that NAT, the SSM sender 639 will need to determine its IP source address relevant to the SSM 640 receivers; generally, this will be the 'outside' IP address of the 641 NAT. This 'outside' address needs to be included in the SSM session 642 establishment message (e.g., SDP) so that listeners on the 'outside' 643 of the NAT can receive the SSM channel. 645 If there are SSM listeners on both the 'outside' and 'inside' of the 646 NAT, it may be valuable to consider using ICE [I-D.ietf-mmusic-ice] 647 in the session advertisement; the full scope of the interaction 648 between SSM and ICE is beyond the scope of this document. 650 If multiple SSM sources on the inside of a NAT choose the same 651 multicast group address, those sources are uniquely identifiable 652 because their IP addresses are unique. However, if their multicast 653 traffic is NAT'ed and sent on the NAT's public interface, the traffic 654 from those individual sources is no longer uniquely identifiable. 655 This will cause problems for multicast receivers which will see an 656 intermixing of traffic from those sources. Resolution of this issue 657 is left for future study. In the meantime, applications that source 658 SSM multicast traffic are encouraged to allow the user to modify the 659 multicast SSM address so that users can avoid this problem if that 660 application is placed behind a NAT. 662 A multicast source that wants its traffic to not traverse a router 663 (e.g., leave a home network) may find it useful to send traffic with 664 IP TTL=1. Both ASM and SSM sources may find this useful. 666 As many NATs use the same private address space (e.g., 667 192.168.0.0/16, [RFC1918]), RTP stacks are encouraged to generate 668 CNAMEs properly (see end of Section 6.5.1 of [RFC3550].) 670 Authors' Addresses 672 Dan Wing 673 Cisco Systems, Inc. 674 170 West Tasman Drive 675 San Jose, CA 95134 676 USA 678 Email: dwing@cisco.com 680 Toerless Eckert 681 Cisco Systems, Inc. 682 170 West Tasman Drive 683 San Jose, CA 95134 684 USA 686 Email: eckert@cisco.com 688 Full Copyright Statement 690 Copyright (C) The IETF Trust (2007). 692 This document is subject to the rights, licenses and restrictions 693 contained in BCP 78, and except as set forth therein, the authors 694 retain all their rights. 696 This document and the information contained herein are provided on an 697 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 698 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 699 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 700 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 701 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 702 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 704 Intellectual Property 706 The IETF takes no position regarding the validity or scope of any 707 Intellectual Property Rights or other rights that might be claimed to 708 pertain to the implementation or use of the technology described in 709 this document or the extent to which any license under such rights 710 might or might not be available; nor does it represent that it has 711 made any independent effort to identify any such rights. Information 712 on the procedures with respect to rights in RFC documents can be 713 found in BCP 78 and BCP 79. 715 Copies of IPR disclosures made to the IETF Secretariat and any 716 assurances of licenses to be made available, or the result of an 717 attempt made to obtain a general license or permission for the use of 718 such proprietary rights by implementers or users of this 719 specification can be obtained from the IETF on-line IPR repository at 720 http://www.ietf.org/ipr. 722 The IETF invites any interested party to bring to its attention any 723 copyrights, patents or patent applications, or other proprietary 724 rights that may cover technology that may be required to implement 725 this standard. Please address the information to the IETF at 726 ietf-ipr@ietf.org. 728 Acknowledgment 730 Funding for the RFC Editor function is provided by the IETF 731 Administrative Support Activity (IASA).