idnits 2.17.00 (12 Aug 2021) /tmp/idnits52605/draft-ietf-behave-multicast-08.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 611. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 622. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 629. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 635. 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 : ---------------------------------------------------------------------------- No issues found here. 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 (July 3, 2007) is 5435 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) == Outdated reference: draft-ietf-avt-rtcpssm has been published as RFC 5760 == Outdated reference: draft-ietf-mmusic-ice has been published as RFC 5245 -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 4601 (Obsoleted by RFC 7761) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 9 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 July 3, 2007 6 Expires: January 4, 2008 8 IP Multicast Requirements for a Network Address (and port) Translator 9 (NAT) 10 draft-ietf-behave-multicast-08 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 January 4, 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 3.1. Application SSM Considerations . . . . . . . . . . . . . . 5 56 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6 57 4.1. NATting IP Multicast Packets . . . . . . . . . . . . . . . 6 58 4.1.1. Receiving Multicast Packets . . . . . . . . . . . . . 6 59 4.1.2. Sending Multicast Packets . . . . . . . . . . . . . . 6 60 4.2. IGMP Versions . . . . . . . . . . . . . . . . . . . . . . 7 61 4.2.1. IGMPv1 or IGMPv2 . . . . . . . . . . . . . . . . . . . 7 62 4.2.2. IGMPv3 . . . . . . . . . . . . . . . . . . . . . . . . 8 63 4.3. Any Source Multicast Transmitters . . . . . . . . . . . . 8 64 5. Requirements Summary . . . . . . . . . . . . . . . . . . . . . 9 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 67 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 68 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 69 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 70 9.2. Informational References . . . . . . . . . . . . . . . . . 13 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 72 Intellectual Property and Copyright Statements . . . . . . . . . . 15 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 and source specific IP multicast in devices 83 running IGMP proxy routing and NAT and without applying NAT to IP 84 multicast group addresses. This profile of functionality is the 85 expected best practice for residential access routers small branch 86 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 Hosts on the 'inside' interface(s) of a NAT indicate their interest 97 in receiving an IP multicast flow by sending an IGMP message to their 98 local interface. An IP multicast-capable NAT will see that IGMP 99 message (IGMPv1 [RFC1112], IGMPv2 [RFC2236], IGMPv3 [RFC3376]), 100 possibly perform some functions on that IGMP message, and forward it 101 to its upstream router. This causes the upstream router to send that 102 IP multicast traffic to the NAT, which forwards it to those inside 103 segment(s) with host(s) that had previously sent IGMP messages for 104 that IP multicast traffic. 106 Out of scope of this document are PIM-SM [RFC4601] and IPv6 107 [RFC2460]. The IGMP Proxy devices that are scoped in this document 108 do not forward PIM-SM. IPv6 is out of scope because NAT is not 109 considered necessary with IPv6. 111 This document is a companion document to "NAT Behavioral Requirements 112 for Unicast UDP" [RFC4787]. 114 2. Terminology Used in this Document 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in RFC 2119 [RFC2119]. 120 In this document, the term "NAT" applies to both Network Address and 121 Port Translator (NAPT) as well as a NAT that does not translate 122 ports. 124 The term 'inside' refers to the interface(s) on a NAT which contain 125 hosts that wish to send or receive IP multicast traffic. The term 126 'outside' refers to the interface(s) the NAT forwards IGMP membership 127 messages to, and where the NAT routes IP multicast traffic that 128 originates from hosts on its 'inside' interface. 130 3. Background 132 When a NAT isn't used, a host might be connected to the Internet in a 133 configuration such as this: 135 +-------------+ 136 +------+ | DSL modem | +------------+ 137 | host +---+ or +-//-+ WAN Router | 138 +------+ | cable modem | +------------+ 139 +-------------+ 141 Figure 1: Network without NATting IGMP Proxy 143 If instead of a single host as shown in Figure 1, one or more LANs 144 with potentially multiple hosts are to be connected, with the same 145 type of service termination on the DSL or cable modem, a NAT device 146 is added as shown in Figure 2. This device in general perform 147 routing and NAT functions such that it does look like a single host 148 towards the DSL/cable modem. 150 +----+ +-------------+ 151 |host+---+ +---------+ | +-----------+ 152 +----+ | |Multicast| | | DSL modem | +------------+ 153 | | Proxy | +--+ or +-//-+ WAN Router | 154 inside | +---------+ | |cable modem| +------------+ 155 interfaces | | +-----------+ 156 | +------+ | 157 +----+ | | NAT | | outside 158 |host+---+ +------+ | interfaces 159 +----+ +-------------+ 160 IGMP Proxy NAT Device 162 Figure 2: Network with NATing IGMP Proxy 164 In IP multicast, IGMP is the protocol used by hosts, such as the one 165 shown in Figure 1. For the NAT device in Figure 2 to look like the 166 single host for IP multicast services towards the DSL/cable modem and 167 to forward IP multicast traffic from and to the multiple hosts in the 168 picture, it needs to perform so called "IGMP Proxying" [RFC4605] -- 169 but within the context of also performing NAT. NAT is not covered by 170 [RFC4605]. Adding NAT to IGMP proxying does not need to change the 171 processing of the IGMP messages as defined in RFC4605: 173 IGMP messages are never logically forwarded by the IGMP proxying 174 device, but rather sourced or received by it. In general, receipt 175 of IGMP messages by the device updated IGMP state maintained by 176 the device and either those changes or timers trigger the sending 177 of IGMP messages. "Forwarding" of IGMP protocol messages may thus 178 only happen implicitly by implementation optimizations that create 179 shortcuts in this machinery. 181 This specifically means that IGMP protocol packets sent by the NAT 182 device will always use IP address of the interface (inside or 183 outside) to which they are sent, but because those packets are 184 logically "sourced" and not "forwarded", NAT does not have any impact 185 into this. 187 Unlike unicast flows, packets with a multicast destination IP address 188 do not have their destination IP address or destination port changed 189 by a NAT. However, their source IP address (and source UDP port, in 190 some cases with a NAPT) is changed if the packet goes from an 191 'inside' interface of a NAT to the 'outside' interface of a NAT -- 192 similar to the behavior of a unicast packet across those same 193 interfaces. 195 Adding NAT to IGMP proxying does change the processing of IP 196 multicast data packets forwarded across the IGMP proxying device as 197 described in the following sections. These changes do actually 198 simplify the ability to deploy IGMP proxying over a device that does 199 NOT perform NAT. 201 With an IGMP Proxy NAT Device, IP multicast data traffic sourced from 202 hosts on the inside is NATed such that it will look like being 203 sourced from a directly connected host to the WAN router, thus 204 eliminating all non-standard PIM-SM concerns/configurations described 205 in section 3.2 of [RFC4605]. 207 3.1. Application SSM Considerations 209 SSM requires listeners to know the SSM channel (S,G), which is 210 comprised of the IP source address (S) and the IP multicast group 211 (G). An SSM sender needs to communicate its IP address in its SSM 212 session establishment message (e.g., in its SDP). When the SSM 213 sender is behind a NAT and the SSM receiver(s) are on the other side 214 of that NAT, the SSM sender will need to determine its IP source 215 address relevant to the SSM receivers; generally, this will be the 216 'outside' IP address of the NAT. This 'outside' address needs to be 217 included in the SSM session establishment message (e.g., SDP) so that 218 listeners on the 'outside' of the NAT can receive the SSM channel. 220 If there are SSM listeners on both the 'outside' and 'inside' of the 221 NAT, it may be valuable to consider using ICE [I-D.ietf-mmusic-ice] 222 in the session advertisement; the full scope of the interaction 223 between SSM and ICE is beyond the scope of this document. 225 4. Requirements 227 4.1. NATting IP Multicast Packets 229 4.1.1. Receiving Multicast Packets 231 REQ-1: For IP multicast packets that are forward to a host(s) on 232 its inside interface(s), a NAT MUST NOT modify the 233 destination IP address or destination port of the packets. 235 Note: If a NAT were to modify the destination IP or port 236 addresses, the NAT would also need to modify session announcements 237 (e.g., electronic program guides, SAP) and session establishment 238 and control (e.g., SIP, RTSP) messages. Such modification is not 239 considered a best practice. 241 REQ-2: A NAT MUST forward IP multicast UDP datagrams from its 242 'outside' interface to multicast receivers on its 'inside' 243 interface(s). 245 REQ-3: A NAT SHOULD forward IP multicast non-UDP protocols (e.g., 246 PGM [RFC3208], RSVP [RFC2750]) from its 'outside' interface 247 to IP multicast receivers on its inside interface(s). 249 4.1.2. Sending Multicast Packets 251 The following requirement is normal NAT behavior for unicast packets, 252 as described in [RFC4787], and provides support for IP multicast 253 senders behind the NAT: 255 REQ-4: A NAT MUST modify the source IP address of packets that 256 arrive from an 'inside' interface towards the 'outside' 257 interface so that those packets use the NAT's 'outside' IP 258 address(es). 260 a: If the NAT also performs port translation (that is, it 261 is a NAPT), the NAT MUST also create a mapping to allow 262 responses to that IP multicast packet to be received by 263 the appropriate host. For any source IP multicast, also 264 see Section 4.3. 266 b: To allow hosts to learn the NAT's 'outside' interface 267 address, the NAT MUST have "Endpoint-Independent 268 Mapping" behavior (REQ-1 of [RFC4787]) no matter if the 269 destination IP address is a unicast address or an IP 270 multicast address. 272 REQ-5: A NAT MUST forward IP multicast UDP datagrams from its 273 'inside' interface(s) to its 'outside' interface. 275 As many NATs are located adjacent to bandwidth-constrained access 276 links, it is important that IP multicast senders communicating with 277 IP multicast receivers behind the NAT not have their flows consume 278 bandwidth on the access link. This is accomplished by applications 279 using administratively scoped IP addresses. 281 REQ-6: A NAT MUST NOT forward administratively scoped IP multicast 282 traffic (239.0.0.0/8) [RFC2365] from its 'inside' 283 interface(s) to its 'outside' interface, unless the NAT has 284 been configured to do so. 286 4.2. IGMP Versions 288 REQ-7: A NAT MAY support IGMPv1 (although IGMPv1 is considered 289 obsolete). 291 REQ-8: A NAT MUST support IGMPv2. 293 REQ-9: A NAT SHOULD support IGMPv3. 295 4.2.1. IGMPv1 or IGMPv2 297 For IGMPv1 and IGMPv2, a NAT can successfully operate by merely 298 forwarding IGMP membership reports and queries between the interested 299 hosts (on its internal interface) towards its external interface. 301 REQ-10: If a NAT supports IGMPv1 and/or IGMPv2 (but not IGMPv3), the 302 NAT MAY simply receive IGMP membership reports on the inside 303 interface, NAT them, and relay the IGMP membership report, 304 and do the same function in the opposite direction to the 305 IGMP listeners. That is, the NAT does not need to do any 306 aggregation of IGMP messages. 308 a: However, it is RECOMMENDED that such a NAT implement 309 IGMP/MLD Proxying [RFC4605], because IGMP aggregation 310 provides a useful optimization. 312 4.2.2. IGMPv3 314 When a IGMPv3 proxying device receives an IGMP membership on an 315 inside interface, it creates its own IGMP proxying membership state 316 and its own IGMP forwarding table. It then creates an independent 317 IGMP membership report on its outside interface reporting the IP 318 multicast groups/channels -- but there is no direct relationship or 319 "forwarding" of IGMP membership reports or queries across the 320 interfaces. The NAT device will subsequently receive a IP multicast 321 data packet on the 'outside' interface and forward the IP multicast 322 packet to the 'inside' interface(s) based on its IGMP forwarding 323 table. 325 By performing NAT on IGMPv3 membership reports, the membership 326 reports appear to originate from a single IGMPv3 reporter instead of 327 different reporters. Because IGMPv3 has different types of 328 membership reports differentiating between status (IS_INCLUDE, 329 IS_EXCLUDE) and change indication (e.g., TO_INCLUDE, TO_EXCLUDE), if 330 a NAT were to interleave reports from two or more reporters (joining 331 and leaving the same groups) the NAT would create a sequence of 332 packets that are not compliant with an IGMPv3 reporter [RFC3376]. 333 For this reason, the following requirements are specified: 335 REQ-11: If a NAT supports IGMPv3, the NAT MUST implement IGMP/MLD 336 Proxying [RFC4605]. Such compliance causes the NAT to 337 aggregate the IGMPv3 membership reports and report only the 338 aggregated information upstream. 340 REQ-12: If a NAT supports IGMPv3, the NAT MUST implement Source 341 Specific Multicast for IP [RFC4607] and IGMPv3/MLDv2 for SSM 342 [RFC4604]. 344 Failure to implement IGMP aggregation ([RFC4605]) will cause 345 undesired temporary blackholing of IP multicast traffic. For 346 example, consider two hosts behind the same NAT. If one host is 347 joining a session at the same time another is leaving the session, 348 and the NAT were to merely relay the join and leave upstream, the 349 session will be terminated, and the join and leave announcements 350 would not comply with section 5 of [RFC3376]. 352 4.3. Any Source Multicast Transmitters 354 Any source multicast (ASM) uses the IP addresses in the 224/8 through 355 231/8, and 233/8 through 239/8 range [IANA-ALLOC]. 357 When a host both receives an ASM stream and sends traffic into it, 358 using RTP [RFC3550], there is a potential problem if a NAT merely 359 followed the requirements of [RFC4787]. The problem is that RTP uses 360 the source transport address (source IP address and source UDP port) 361 and the RTP/RTCP SSRC value to identify session members. If a 362 session member sees the same SSRC arrive from a different transport 363 address, that session member will perform RTP collision detection 364 (section 8.2 of [RFC3550]). If a NAT merely followed the 365 requirements of [RFC4787] and timed out a UDP session after 2 minutes 366 of inactivity and RTCP receiver reports are sent less often than 367 every 2 minutes, RTP collision detection would be performed by other 368 session members sharing the same SSRC, complicating diagnostic tools 369 and potentially interfering with jitter buffer algorithms. This 370 situation can occur, for example, with an IP multicast group of 371 approximately 300 members with a normal 50kbps audio RTP stream. 373 Source specific IP multicast does not need this long timer because 374 application feedback reports are unicast (rather than IP multicast) 375 and identifiers, rather than IP addresses and UDP ports, are used to 376 identify a specific IP multicast receiver (e.g., 377 [I-D.ietf-avt-rtcpssm]. 379 REQ-13: If a host on the inside interface of a NAT belongs to an any 380 source IP multicast host group and the host sends a UDP 381 packet to the same group, the NAT SHOULD have a UDP mapping 382 timer of 60 minutes for that mapping. 384 a: This UDP mapping SHOULD be destroyed when the host 385 leaves that host group. The NAT is aware of this 386 through receipt of an IGMP message from the host. 388 b: If a NAT has exhausted its resources, the NAT MAY time 389 out that mapping before 60 minutes have elapsed, but 390 this is discouraged. Note that even in a situation with 391 resource exhaustion, a NAT is still required to follow 392 the minimum mapping duration of 2 minutes (REQ-5 of 393 [RFC4787]). 395 5. Requirements Summary 397 This section summarizes the requirements; if there is a difference in 398 this summary and the text in the main body of the document, the main 399 body takes precedence. 401 REQ-1: For IP multicast packets that are forward to a host(s) on 402 its inside interface(s), a NAT MUST NOT modify the 403 destination IP address or destination port of the packets. 405 REQ-2: A NAT MUST forward IP multicast UDP datagrams from its 406 'outside' interface to IP multicast receivers on its 407 'inside' interface(s). 409 REQ-3: A NAT SHOULD forward IP multicast non-UDP protocols (e.g., 410 PGM [RFC3208], RSVP [RFC2750]) from its 'outside' interface 411 to IP multicast receivers on its inside interface(s). 413 REQ-4: A NAT MUST modify the source IP address of packets that 414 arrive from an 'inside' interface towards the 'outside' 415 interface so that those packets use the NAT's 'outside' IP 416 address(es). 418 a: If the NAT also performs port translation (that is, it 419 is a NAPT), the NAT MUST also create a mapping to allow 420 responses to that IP multicast packet to be received by 421 the appropriate host. For any source multicast, also 422 see Section 4.3. 424 b: To allow hosts to learn the NAT's 'outside' interface 425 address, the NAT MUST have "Endpoint-Independent 426 Mapping" behavior (REQ-1 of [RFC4787]) no matter if the 427 destination IP address is a unicast address or an IP 428 multicast address. 430 REQ-5: A NAT MUST forward IP multicast UDP datagrams from its 431 'inside' interface(s) to its 'outside' interface. 433 REQ-6: A NAT MUST NOT forward administratively scoped IP multicast 434 traffic (239/8) [RFC2365] from its 'inside' interface(s) to 435 its 'outside' interface, unless the NAT has been configured 436 to do so. 438 REQ-7: A NAT MAY support IGMPv1 (although IGMPv1 is considered 439 obsolete). 441 REQ-8: A NAT MUST support IGMPv2. 443 REQ-9: A NAT SHOULD support IGMPv3. 445 REQ-10: If a NAT supports IGMPv1 and/or IGMPv2 (but not IGMPv3), the 446 NAT MAY simply receive IGMP membership reports on the inside 447 interface, NAT them, and relay the IGMP membership report, 448 and do the same function in the opposite direction to the 449 IGMP listeners. That is, the NAT does not need to do any 450 aggregation of IGMP messages. 452 a: However, it is RECOMMENDED that such a NAT implement 453 IGMP/MLD Proxying [RFC4605], because IGMP aggregation 454 provides a useful optimization. 456 REQ-11: If a NAT supports IGMPv3, the NAT MUST implement IGMP/MLD 457 Proxying [RFC4605]. Such compliance causes the NAT to 458 aggregate the IGMPv3 membership reports and report only the 459 aggregated information upstream. 461 REQ-12: If a host on the inside interface of a NAT belongs to an any 462 source multicast host group and the host sends a UDP packet 463 to the same group, the NAT SHOULD have a UDP mapping timer 464 of 60 minutes for that mapping. 466 a: This UDP mapping SHOULD be destroyed when the host 467 leaves that host group. The NAT is aware of this 468 through receipt of an IGMP message from the host. 470 b: If a NAT has exhausted its resources, the NAT MAY time 471 out that mapping before 60 minutes have elapsed, but 472 this is discouraged. Note that even in a situation with 473 resource exhaustion, a NAT is still required to follow 474 the minimum mapping duration of 2 minutes (REQ-5 of 475 [RFC4787]). 477 6. Security Considerations 479 The Security Considerations sections of IGMPv3 [RFC3376] and IGMP 480 Proxying [RFC4605] apply to a device complying with this document. 482 When a host is using RTP and participating in an any source IP 483 multicast session, the host's periodic RTCP receiver reports cause 484 the NAT to create a mapping. When the group size is less than 485 approximately 300, the RTCP reports are sent frequently enough that a 486 NAT's mapping will always be kept open. When the group size is 487 larger than approximately 300, the RTCP reports are sent less 488 frequently. The recommendation in Section 4.3 causes the NAT mapping 489 to be kept open for the duration of the host's participation in that 490 IP multicast session no matter the size of the multicast host or 491 periodicity of the host's RTCP transmissions. 493 7. IANA Considerations 495 This document does not require any IANA registrations. 497 8. Acknowledgments 499 Thanks to Yiqun Cai, Stephen Casner, Remi Denis-Courmont, Alfred 500 Hines, Prashant Jhingran, Albert Manfredi, Marcus Maranhao, Bryan 501 McLaughlin, Pekka Savola, and Magnus Westerlund for their assistance 502 in writing this document. 504 9. References 506 9.1. Normative References 508 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 509 Requirement Levels", BCP 14, RFC 2119, March 1997. 511 [RFC2236] Fenner, W., "Internet Group Management Protocol, Version 512 2", RFC 2236, November 1997. 514 [RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, 515 RFC 2365, July 1998. 517 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 518 Thyagarajan, "Internet Group Management Protocol, Version 519 3", RFC 3376, October 2002. 521 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 522 Jacobson, "RTP: A Transport Protocol for Real-Time 523 Applications", STD 64, RFC 3550, July 2003. 525 [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet 526 Group Management Protocol Version 3 (IGMPv3) and Multicast 527 Listener Discovery Protocol Version 2 (MLDv2) for Source- 528 Specific Multicast", RFC 4604, August 2006. 530 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 531 "Internet Group Management Protocol (IGMP) / Multicast 532 Listener Discovery (MLD)-Based Multicast Forwarding 533 ("IGMP/MLD Proxying")", RFC 4605, August 2006. 535 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 536 IP", RFC 4607, August 2006. 538 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 539 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 540 RFC 4787, January 2007. 542 9.2. Informational References 544 [I-D.ietf-avt-rtcpssm] 545 Chesterfield, J., "RTCP Extensions for Single-Source 546 Multicast Sessions with Unicast Feedback", 547 draft-ietf-avt-rtcpssm-13 (work in progress), March 2007. 549 [I-D.ietf-mmusic-ice] 550 Rosenberg, J., "Interactive Connectivity Establishment 551 (ICE): A Protocol for Network Address Translator (NAT) 552 Traversal for Offer/Answer Protocols", 553 draft-ietf-mmusic-ice-16 (work in progress), June 2007. 555 [IANA-ALLOC] 556 Internet Assigned Numbers Authority, "Internet Multicast 557 Addresses", 558 . 560 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 561 RFC 1112, August 1989. 563 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 564 (IPv6) Specification", RFC 2460, December 1998. 566 [RFC2750] Herzog, S., "RSVP Extensions for Policy Control", 567 RFC 2750, January 2000. 569 [RFC3208] Speakman, T., Crowcroft, J., Gemmell, J., Farinacci, D., 570 Lin, S., Leshchiner, D., Luby, M., Montgomery, T., Rizzo, 571 L., Tweedly, A., Bhaskar, N., Edmonstone, R., 572 Sumanasekera, R., and L. Vicisano, "PGM Reliable Transport 573 Protocol Specification", RFC 3208, December 2001. 575 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 576 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 577 Protocol Specification (Revised)", RFC 4601, August 2006. 579 Authors' Addresses 581 Dan Wing 582 Cisco Systems, Inc. 583 170 West Tasman Drive 584 San Jose, CA 95134 585 USA 587 Email: dwing@cisco.com 589 Toerless Eckert 590 Cisco Systems, Inc. 591 170 West Tasman Drive 592 San Jose, CA 95134 593 USA 595 Email: eckert@cisco.com 597 Full Copyright Statement 599 Copyright (C) The IETF Trust (2007). 601 This document is subject to the rights, licenses and restrictions 602 contained in BCP 78, and except as set forth therein, the authors 603 retain all their rights. 605 This document and the information contained herein are provided on an 606 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 607 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 608 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 609 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 610 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 611 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 613 Intellectual Property 615 The IETF takes no position regarding the validity or scope of any 616 Intellectual Property Rights or other rights that might be claimed to 617 pertain to the implementation or use of the technology described in 618 this document or the extent to which any license under such rights 619 might or might not be available; nor does it represent that it has 620 made any independent effort to identify any such rights. Information 621 on the procedures with respect to rights in RFC documents can be 622 found in BCP 78 and BCP 79. 624 Copies of IPR disclosures made to the IETF Secretariat and any 625 assurances of licenses to be made available, or the result of an 626 attempt made to obtain a general license or permission for the use of 627 such proprietary rights by implementers or users of this 628 specification can be obtained from the IETF on-line IPR repository at 629 http://www.ietf.org/ipr. 631 The IETF invites any interested party to bring to its attention any 632 copyrights, patents or patent applications, or other proprietary 633 rights that may cover technology that may be required to implement 634 this standard. Please address the information to the IETF at 635 ietf-ipr@ietf.org. 637 Acknowledgment 639 Funding for the RFC Editor function is provided by the IETF 640 Administrative Support Activity (IASA).