[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-wing-behave-multicast) 00 01 02 03 04 05 06 07 08 09 10 11 12 RFC 5135

BEHAVE Working Group                                             D. Wing
Internet-Draft                                                 T. Eckert
Intended status:  Best Current                       Cisco Systems, Inc.
Practice                                               September 7, 2007
Expires:  March 10, 2008


 IP Multicast Requirements for a Network Address (and port) Translator
                                 (NAT)
                     draft-ietf-behave-multicast-10

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on March 10, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   This document specifies requirements for a Network Address (and port)
   Translator (NAT) that supports Any Source IP Multicast or Source-
   Specific IP Multicast.  An IP multicast-capable NAT device that
   adheres to the requirements of this document can optimize the
   operation of IP multicast applications that are generally unaware of
   IP multicast NAT devices.



Wing & Eckert            Expires March 10, 2008                 [Page 1]

Internet-Draft        NAT IP Multicast Requirements       September 2007


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology Used in this Document  . . . . . . . . . . . . . .  3
   3.  Background . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . .  5
     4.1.  NATting IP Multicast Data Packets  . . . . . . . . . . . .  6
       4.1.1.  Receiving Multicast Data Packets . . . . . . . . . . .  6
       4.1.2.  Sending Multicast Data Packets . . . . . . . . . . . .  6
     4.2.  IGMP Version Support . . . . . . . . . . . . . . . . . . .  7
       4.2.1.  IGMPv1 or IGMPv2 . . . . . . . . . . . . . . . . . . .  7
       4.2.2.  IGMPv3 . . . . . . . . . . . . . . . . . . . . . . . .  8
     4.3.  Any Source Multicast Transmitters  . . . . . . . . . . . .  9
   5.  Requirements Summary . . . . . . . . . . . . . . . . . . . . . 10
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 12
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 13
     9.2.  Informational References . . . . . . . . . . . . . . . . . 13
   Appendix A.  Application Considerations  . . . . . . . . . . . . . 14
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
   Intellectual Property and Copyright Statements . . . . . . . . . . 16




























Wing & Eckert            Expires March 10, 2008                 [Page 2]

Internet-Draft        NAT IP Multicast Requirements       September 2007


1.  Introduction

   In order for IP multicast applications to function well over NATs,
   multicast UDP must work as seamlessly as unicast UDP.  However, NATs
   have little consistency in IP multicast operation which results in
   inconsistent user experiences and failed IP multicast operation.

   This document targets requirements intended to enable correct
   operations of Any Source Multicast and Source-Specific Multicast in
   devices running IGMP proxy routing and NAT and without applying NAT
   to IP multicast group addresses.  This profile of functionality is
   the expected best practice for residential access routers small
   branch routers or similar deployments.

   Most of the principles outlined in this document do also apply when
   using protocols other than IGMP, such as PIM-SM, or when performing
   NAT between multiple "inside" interfaces, but explicit consideration
   for these cases is outside the scope of this document.

   This document describes the behavior of a device that functions as a
   NAT for unicast flows and also forwards IP multicast traffic in
   either direction ('inside' to 'outside', or 'outside' to 'inside').
   This allows a host 'inside' the NAT to both receive multicast traffic
   and to source multicast traffic.  Hosts on the 'inside' interface(s)
   of a NAT indicate their interest in receiving an IP multicast flow by
   sending an IGMP message to their local interface.  An IP multicast-
   capable NAT will see that IGMP message (IGMPv1 [RFC1112], IGMPv2
   [RFC2236], IGMPv3 [RFC3376]), possibly perform some functions on that
   IGMP message, and forward it to its upstream router.  This causes the
   upstream router to send that IP multicast traffic to the NAT, which
   forwards it to those inside segment(s) with host(s) that had
   previously sent IGMP messages for that IP multicast traffic.

   Out of scope of this document are PIM-SM [RFC4601] and IPv6
   [RFC2460].  The IGMP Proxy devices that are scoped in this document
   do not forward PIM-SM.  IPv6 is out of scope because NAT is not
   considered necessary with IPv6.

   This document is a companion document 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].




Wing & Eckert            Expires March 10, 2008                 [Page 3]

Internet-Draft        NAT IP Multicast Requirements       September 2007


   In this document, the term "NAT" applies to both Network Address and
   Port Translator (NAPT) as well as a NAT that does not translate
   ports.

   The term 'inside' refers to the interface(s) on a NAT which contain
   hosts that wish 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
   originates from hosts on its 'inside' interface.


3.  Background

   When a NAT isn't used, a host might be connected to the Internet in a
   configuration such as this:

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

               Figure 1: Network without NATting IGMP Proxy

   If instead of a single host as shown in Figure 1, one or more LANs
   with potentially multiple hosts are to be connected, with the same
   type of service termination on the DSL or cable modem, a NAT device
   is added as shown in Figure 2.  This device in general perform
   routing and NAT functions such that it does look like a single host
   towards 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 used by hosts, such as the one
   shown in Figure 1.  For the NAT device in Figure 2 to look like the



Wing & Eckert            Expires March 10, 2008                 [Page 4]

Internet-Draft        NAT IP Multicast Requirements       September 2007


   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 perform so called "IGMP Proxying" [RFC4605] --
   but within the context of also performing NAT.  NAT is not covered by
   [RFC4605].  Adding NAT to IGMP proxying does not need to change the
   processing of the IGMP messages as defined in RFC4605:

      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 that IGMP protocol packets sent by the NAT
   device will always use IP address of the interface (inside or
   outside) from which they are sent, but because those packets are
   logically "sourced" and not "forwarded", NAT does not have any impact
   into this.

   Unlike unicast flows, packets with a multicast destination IP address
   do not 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) is changed if the packet goes from an
   'inside' interface of a NAT to the 'outside' interface of a NAT --
   similar to the behavior of a unicast packet across those same
   interfaces.

   Adding NAT to IGMP proxying does change the processing of IP
   multicast data packets forwarded across the IGMP proxying device as
   described in the following sections.  These changes do actually
   simplify the ability 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 is NATed such that it will look like being
   sourced from a directly connected host to the WAN router, thus
   eliminating all non-standard PIM-SM concerns/configurations described
   in section 3.2 of [RFC4605].


4.  Requirements







Wing & Eckert            Expires March 10, 2008                 [Page 5]

Internet-Draft        NAT IP Multicast Requirements       September 2007


4.1.  NATting IP Multicast Data Packets

4.1.1.  Receiving Multicast Data Packets

   REQ-1:   For IP multicast packets that are 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, the
      NAT would also need to modify session announcements (e.g.,
      electronic program guides, SAP) and session establishment and
      control (e.g., SIP, RTSP) messages.  Such modifications of
      application messages is not considered a best practice.
      Furthermore, a NATted multi-homed network would need to coordinate
      such rewriting between its NATs.

   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 [RFC2750]) from its 'outside' interface
            to IP multicast receivers on its inside interface(s).

4.1.2.  Sending Multicast Data Packets

   The following requirement is normal NAT behavior for unicast packets,
   as described in [RFC4787], and extended here to provide support for
   IP multicast senders behind the NAT.

   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.





Wing & Eckert            Expires March 10, 2008                 [Page 6]

Internet-Draft        NAT IP Multicast Requirements       September 2007


            c:  If the NAT has multiple public IP addresses, the NAT
                SHOULD have 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 allows a multicast source to discover
                the NAT's public IP address using a unicast address
                discovery mechanism (e.g., [I-D.ietf-mmusic-ice]) and
                communicate that discovered IP address to a multicast
                receiver.

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

            a:  If a network is multihomed, the NATs or the network
                configuration MUST ensure that duplicate instances of
                the multicast data traffic do not appear on the public
                network.  This can be accomplished by network design (an
                access control list) or a protocol between the NATs
                (e.g., the NAT with the higher IP address transmits
                multicast data towards the public network and other NATs
                drop it).

   As many NATs are located adjacent to bandwidth-constrained access
   links, it is important that IP multicast senders communicating with
   IP multicast receivers behind the NAT not have their flows consume
   bandwidth on the access link.  This is accomplished by applications
   using administratively scoped IP addresses.

   REQ-6:   A NAT MUST NOT forward administratively scoped IP multicast
            traffic (239.0.0.0/8) [RFC2365] from its 'inside'
            interface(s) to its 'outside' interface, unless the NAT has
            been configured to do so.

4.2.  IGMP Version Support

   REQ-7:   A NAT MAY support IGMPv1 (although IGMPv1 is considered
            obsolete).

   REQ-8:   A NAT MUST support IGMPv2.

   REQ-9:   A NAT SHOULD support IGMPv3.

4.2.1.  IGMPv1 or IGMPv2

   For IGMPv1 and IGMPv2, a NAT can successfully operate by merely
   forwarding IGMP membership reports and queries between the interested
   hosts (on its internal interface) towards its external interface.




Wing & Eckert            Expires March 10, 2008                 [Page 7]

Internet-Draft        NAT IP Multicast Requirements       September 2007


   REQ-10:  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

   When a 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.  It then 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 subsequently receive a 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 originate from a single IGMPv3 reporter instead of
   different reporters.  Because IGMPv3 has different types of
   membership reports differentiating between status (IS_INCLUDE,
   IS_EXCLUDE) and change indication (e.g., TO_INCLUDE, TO_EXCLUDE), 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-11:  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-12:  If a NAT supports IGMPv3, the NAT MUST implement Source-
            Specific Multicast for IP [RFC4607] and IGMPv3/MLDv2 for SSM
            [RFC4604].

   Failure to implement IGMP aggregation ([RFC4605]) will cause



Wing & Eckert            Expires March 10, 2008                 [Page 8]

Internet-Draft        NAT IP Multicast Requirements       September 2007


   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].

   When a host both receives an ASM stream and sends traffic into it,
   using RTP [RFC3550], there is a potential problem if a NAT merely
   followed the requirements of [RFC4787].  The problem is that RTP uses
   the source transport address (source IP address and source UDP port)
   and the 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]).  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, RTP collision detection would be performed by other
   session members sharing the same SSRC, complicating diagnostic tools
   and potentially interfering with jitter buffer algorithms.  This
   situation can occur, for example, with an IP multicast group of
   approximately 300 members with a normal 50kbps audio RTP stream.

   Source-Specific Multicast does not 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.,
   [I-D.ietf-avt-rtcpssm].

   REQ-13:  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



Wing & Eckert            Expires March 10, 2008                 [Page 9]

Internet-Draft        NAT IP Multicast Requirements       September 2007


                [RFC4787]).


5.  Requirements Summary

   This section summarizes the requirements; if there is a difference in
   this summary and the text in the main body of the document, the main
   body takes precedence.

   REQ-1:   For IP multicast packets that are forward 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 IP multicast receivers on its
            'inside' interface(s).

   REQ-3:   A NAT SHOULD forward IP multicast non-UDP protocols (e.g.,
            PGM [RFC3208], RSVP [RFC2750]) 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 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 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.








Wing & Eckert            Expires March 10, 2008                [Page 10]

Internet-Draft        NAT IP Multicast Requirements       September 2007


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

            a:  If a network is multihomed, the NATs or the network
                configuration MUST ensure that duplicate instances of
                the multicast data traffic do not appear on the public
                network.  This can be accomplished by network design (an
                access control list) or a protocol between the NATs
                (e.g., the NAT with the higher IP address transmits
                multicast data towards the public network and other NATs
                drop it).

   REQ-6:   A NAT MUST NOT forward administratively scoped IP multicast
            traffic (239/8) [RFC2365] from its 'inside' interface(s) to
            its 'outside' interface, unless the NAT has been configured
            to do so.

   REQ-7:   A NAT MAY support IGMPv1 (although IGMPv1 is considered
            obsolete).

   REQ-8:   A NAT MUST support IGMPv2.

   REQ-9:   A NAT SHOULD support IGMPv3.

   REQ-10:  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.

   REQ-11:  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-12:  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.



Wing & Eckert            Expires March 10, 2008                [Page 11]

Internet-Draft        NAT IP Multicast Requirements       September 2007


            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]).


6.  Security Considerations

   The Security Considerations sections of IGMPv3 [RFC3376] and IGMP
   Proxying [RFC4605] apply to a device complying 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 frequently enough that a NAT's mapping
   will always be kept 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 be kept open
   for the duration of the host's participation in that IP multicast
   session no matter the size of the multicast host or periodicity of
   the host's RTCP transmissions.


7.  IANA Considerations

   This document does not require any IANA registrations.


8.  Acknowledgments

   Thanks to Yiqun Cai, Stephen Casner, Remi Denis-Courmont, Gorry
   Fairhurst, Alfred Hines, Prashant Jhingran, Bharat Joshi, Albert
   Manfredi, Marcus Maranhao, Bryan McLaughlin, Pekka Savola, Magnus
   Westerlund, and Stig Venaas for their assistance in writing this
   document.


9.  References







Wing & Eckert            Expires March 10, 2008                [Page 12]

Internet-Draft        NAT IP Multicast Requirements       September 2007


9.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.

   [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.

9.2.  Informational References

   [I-D.ietf-avt-rtcpssm]
              Chesterfield, J., "RTCP Extensions for Single-Source
              Multicast Sessions with Unicast Feedback",
              draft-ietf-avt-rtcpssm-13 (work in progress), March 2007.

   [I-D.ietf-mmusic-ice]
              Rosenberg, J., "Interactive Connectivity Establishment
              (ICE): A Protocol for Network Address  Translator (NAT)
              Traversal for Offer/Answer Protocols",
              draft-ietf-mmusic-ice-17 (work in progress), July 2007.



Wing & Eckert            Expires March 10, 2008                [Page 13]

Internet-Draft        NAT IP Multicast Requirements       September 2007


   [IANA-ALLOC]
              Internet Assigned Numbers Authority, "Internet Multicast
              Addresses",
              <http://www.iana.org/assignments/multicast-addresses>.

   [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.

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998.

   [RFC2750]  Herzog, S., "RSVP Extensions for Policy Control",
              RFC 2750, January 2000.

   [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.

   [RFC4601]  Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
              "Protocol Independent Multicast - Sparse Mode (PIM-SM):
              Protocol Specification (Revised)", RFC 4601, August 2006.


Appendix A.  Application Considerations

   SSM requires listeners to know the SSM channel (S,G), which is
   comprised of the IP source address (S) and the IP multicast group
   (G).  An SSM source needs to communicate its IP address in its SSM
   session establishment message (e.g., in its SDP).  When the SSM
   sender is behind a NAT and the SSM receiver(s) are on the other side
   of that NAT, the SSM sender will need to determine its IP source
   address relevant to the SSM receivers; generally, this will be the
   'outside' IP address of the NAT.  This 'outside' address needs to be
   included in the SSM session establishment message (e.g., SDP) so that
   listeners on the 'outside' of the NAT can receive the SSM channel.

   If there are SSM listeners on both the 'outside' and 'inside' of the
   NAT, it may be valuable to consider using ICE [I-D.ietf-mmusic-ice]
   in the session advertisement; the full scope of the interaction
   between SSM and ICE is beyond the scope of this document.

   If multiple SSM sources on the inside of a NAT choose the same



Wing & Eckert            Expires March 10, 2008                [Page 14]

Internet-Draft        NAT IP Multicast Requirements       September 2007


   multicast group address, those sources are uniquely identifiable
   because their IP addresses are unique.  However, if their multicast
   traffic is NATted and sent on the NAT's public interface, the traffic
   from those individual sources is no longer uniquely identifiable.
   This will cause problems for multicast receivers which will see an
   intermixing of traffic from those sources.  Resolution of this issue
   is left for future study.  In the meantime, applications that source
   SSM multicast traffic are encouraged to allow the user to modify the
   multicast SSM address so that users can avoid this problem if that
   application is placed behind a NAT.

   A multicast source that wants its traffic to not traverse a router
   (e.g., leave a home network) may find it useful to send traffic with
   IP TTL=1.  Both ASM and SSM sources may find this useful.

   As many NATs use the same private address space (e.g.,
   192.168.0.0/16, [RFC1918]), RTP stacks are encouraged to generate
   CNAMEs properly (see end of Section 6.5.1 of [RFC3550].)


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













Wing & Eckert            Expires March 10, 2008                [Page 15]

Internet-Draft        NAT IP Multicast Requirements       September 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

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

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, 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 regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

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

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


Acknowledgment

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





Wing & Eckert            Expires March 10, 2008                [Page 16]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/