BEHAVE                                                           D. Wing
Internet-Draft                                             Cisco Systems
Expires: April 17, 2005                                 October 17, 2004



                          IGMP Proxy Behavior
                     draft-wing-behave-multicast-00


Status of this Memo


   This document is an Internet-Draft and is subject to all provisions
   of section 3 of RFC 3667.  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 become aware will be disclosed, in accordance with
   RFC 3668.


   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 April 17, 2005.


Copyright Notice


   Copyright (C) The Internet Society (2004).


Abstract


   This document describes the behavior of an IGMP Proxy, as implemented
   in NAT devices, and places requirements on such devices.


Requirements Language


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




Wing                     Expires April 17, 2005                 [Page 1]


Internet-Draft            IGMP Proxy Behavior               October 2004



Table of Contents


   1.  Problem Statement  . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Document Scope . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     3.1   Host Multicast Overview  . . . . . . . . . . . . . . . . .  4
   4.  NAT IGMP Proxy Requirements  . . . . . . . . . . . . . . . . .  5
     4.1   Perform Host and IGMP Proxy Functions  . . . . . . . . . .  5
     4.2   IGMP Packets Sent Towards WAN Interface  . . . . . . . . .  5
     4.3   Keep NAT Binding Open  . . . . . . . . . . . . . . . . . .  6
     4.4   Support Non-UDP Traffic  . . . . . . . . . . . . . . . . .  6
     4.5   Inform Upstream Router of Multicast Interest . . . . . . .  6
   5.  RTP Considerations . . . . . . . . . . . . . . . . . . . . . .  6
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  7
   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . .  7
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  7
   9.1   Normative References . . . . . . . . . . . . . . . . . . . .  7
   9.2   Informational References . . . . . . . . . . . . . . . . . .  7
       Author's Address . . . . . . . . . . . . . . . . . . . . . . .  8
       Intellectual Property and Copyright Statements . . . . . . . .  9































Wing                     Expires April 17, 2005                 [Page 2]


Internet-Draft            IGMP Proxy Behavior               October 2004



1.  Problem Statement


   For users to accept and enjoy multicast, multicast UDP must work as
   seamlessly as unicast UDP.  However, today's equipment has little
   consistency in multicast operation which results in inconsistant user
   experiences and failed multicast operation.


2.  Document Scope


   This document describes the behavior of a device which:


   o  functions as an IGMP proxy on behalf of hosts,
   o  receives multicast traffic from one interface (typically its WAN
      interface) and sends that multicast traffic to other interface(s),
   o  uses IGMPv2 or IGMPv3, and
   o  uses IPv4.


   Specifically out of scope are:


   o  sending multicast traffic,
   o  PIM-SM [13],
   o  IPv6, and,
   o  IGMPv1.


   Sending multicast traffic is out of scope because it requires NATting
   the source IP address of such transmitted multicast traffic.
   Similarly, PIM is used only between routers and the IGMP Proxy
   devices that are scoped in this document do not function as routers.
   IPv6 is out of scope because NAT is not considered necessary with
   IPv6.  IGMPv1 is not significantly deployed on the Internet.


   This document does not describe how to implement multicast, IGMPv2,
   or IGMPv3 in an IGMP Proxy device.  Rather, it provides requirements
   for an IGMP Proxy device so that hosts behind the NAT can receive
   multicast traffic without any knowledge of the IGMP Proxy.


3.  Introduction


   As detailed in the Document Scope section, the primary functions of
   an IGMP proxy device are to collect IGMP traffic from one interface
   and relay it to another interface, and accept multicast traffic from
   thatinterface and route -- or replicate it -- to other interface(s).










Wing                     Expires April 17, 2005                 [Page 3]


Internet-Draft            IGMP Proxy Behavior               October 2004



   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 |        +------------+
                +-------------+


   When an IGMP Proxy (NAT) device is added to such a network, its
   behavior is identical towards the upstream (WAN) router.
   Specifically, when dealing with multicast, the IGMP Proxy has the
   same behavior towards the WAN as if it was a host.


     +------+  +------------+   +-------------+
     | host +--+            |   |  DSL modem  |        +------------+
     +------+  | IGMP Proxy +---+     or      +---//---+ WAN Router |
     +------+  |   (NAT)    |   | cable modem |        +------------+
     | host +--+            |   +-------------+
     +------+  +------------+


   This document specifies how an IGMP Proxy provides multicast
   functionality to the hosts on its local LAN.


   At the time of this writing, IGMPv2 [2] is still a common multicast
   signaling protocol, although new applications are now using IGMPv3
   [3].  This document describes NAT requirements for both IGMPv2 and
   IGMPv3.


   This document is a companion document to "NAT/Firewall Behavioral
   Requirements" [6], and uses the terminology defined in that document.


3.1  Host Multicast Overview


   A host interested in receiving multicast traffic indicates its
   interest by sending an IGMP message to its local LAN.  The contents
   of the IGMP message and the IP destination address is different for
   IGMPv2 and IGMPv3; see IGMPv2 [2] section 9 and IGMPv3 [3] section
   4.2.14 for details.


   The basic host operation is:


   o  the IGMP Proxy listens on the for an IGMP message from hosts on
      its local network,
   o  an application learns of a multicast address it's interested in
      receiving.  This usually occurs via some sort of signaling (such
      as SIP [10] or SAP [8]), or by a user entering a multicast address
      directly into an application,




Wing                     Expires April 17, 2005                 [Page 4]


Internet-Draft            IGMP Proxy Behavior               October 2004



   o  the application sends an IGMP membership report to the local
      network,
   o  The NAT performs specific aggregation functions (detailed in
      RFC2236 and RFC3376), creates a NAT binding, and informs the
      upstream WAN router of its interest in receiving the multicast
      traffic by sending an IGMP membership report to the upstream
      router,
   o  To indicate continued interest in recieving the multicast traffic,
      the application periodically re-transmits IGMP membership report
      messages, and these are aggregated by the NAT and periodically
      transmitted to the upstream router,
   o  when all multicast listeners are no longer interested in multicast
      traffic (either due to not sending membership reports, or due to
      the NAT querying the hosts using IGMP), the NAT closes its NAT
      binding and informs the upstream WAN router to cease sending
      multicast traffic.


   An IGMP Proxy would perform these operations, and would also route --
   or replicate -- incoming multicast traffic to the interface(s) where
   a host is interested in that multicast traffic.


4.  NAT IGMP Proxy Requirements


   This section lists the specific requirements for NATs that implement
   IGMP Proxies.


4.1  Perform Host and IGMP Proxy Functions


   The IGMP Proxy MUST perform functions as if it were a host, as
   outlined in Section 3.1.  Additionally, the IGMP Proxy MUST also
   route incoming multicast packets to the interface that contained the
   host(s) interested in that multicast traffic.  If hosts on multiple
   interfaces are interested in the same multicast traffic, the IGMP
   Proxy MUST replicate the traffic so that it is sent to all interfaces
   with interested hosts.


4.2  IGMP Packets Sent Towards WAN Interface


   The IGMP packets sent by the NAT MUST follow the requirements in
   RFC3376 section 4 [3], specificially the TTL MUST be 1, IP precedence
   MUST be Internetwork Control (Type of Service 0xc0), and it MUST
   carry the IP Router Alert option.


   The IGMP packets sent by the NAT towards the WAN MUST use the NAT's
   public IP address as the source IP address.







Wing                     Expires April 17, 2005                 [Page 5]


Internet-Draft            IGMP Proxy Behavior               October 2004



4.3  Keep NAT Binding Open


   The BEHAVE [6] document only requires that a NAT binding be kept open
   for inside-to-outside UDP flows.  However, with multicast traffic,
   UDP traffic will only arrive outside-to-inside.


   Hosts will periodically send IGMP Report messages to indicate
   continued interest in receiving the multicast traffic.  As long as
   the IGMP Proxy sees a host is interested in receiving the flow, the
   NAT MUST continue to receive multicast traffic from the WAN and send
   it to the interfaces with interested hosts.


   Per IGMPv3, the default transmission interval for the periodic
   Membership Report is one second.  Per IGMPv2, the default
   transmission interval for the periodic Unsolicited Report Interval is
   10 seconds.  If a host no longer sends its periodic messages within
   those timeframes, the NAT MAY consider the host no longer wants to
   receive the multicast traffic and can inform the upstream WAN router
   and close the NAT binding.  However, it is suggested that the NAT
   wait until 3 missing unsolicited reports (to account for packet loss
   on the LAN, especially wireless LANs), or that the NAT first query
   the host using IGMPv2 or IGMPv3.


4.4  Support Non-UDP Traffic


   Although multicast traffic is usually UDP, multicast traffic is not
   required to be UDP.  Thus, a NAT MUST support multicast traffic of
   any IP protocol.  This behavior will allows for seamless support of
   emerging protocols.  This behavior MAY be configurable by the user.


4.5  Inform Upstream Router of Multicast Interest


   As long as a host is interested in receiving a multicast stream, the
   IGMP Proxy -- because it is acting like a host -- MUST also send
   periodic IGMP Report messages to the upstream WAN router to indicate
   continued interest in receiving the multicast traffic.


   When all listeners behind the IGMP Proxy are no longer interested in
   the multicast traffic, the NAT MUST inform the upstream (WAN) router
   by sending an updated IGMP Membership Report, and the NAT MUST also
   delete its NAT binding.  Informing the upstream router quickly is
   necessary to avoid wasting the bandwidth of the access link.


5.  RTP Considerations


   A signficant use of multicast is RFC3550 [4] (RTP), which runs over
   UDP.  A multicast listener would receive RTP over multicast UDP on
   port X, and would send unicast RTCP to the multicast RTP transmitter




Wing                     Expires April 17, 2005                 [Page 6]


Internet-Draft            IGMP Proxy Behavior               October 2004



   over port Y.  Although RFC3550 implies that X+1=Y, the NAT MUST NOT
   make this assumption because signaling can specify an alternate port
   for RTCP[5].


6.  Security Considerations


   Compliance with this specification does not increase security risks
   beyond those already discussed in the Security Considerations section
   of IGMPv3 [3].


7.  IANA Considerations


   This document does not require any IANA registrations.


8.  Acknowledgments


   Thanks to Bryan McLaughlin and Yiqun Cai for their assistance in
   writing this document.


9.  References


9.1  Normative References


   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.


   [2]  Fenner, W., "Internet Group Management Protocol, Version 2", RFC
        2236, November 1997.


   [3]  Cain, B., Deering, S., Kouvelas, I., Fenner, B. and A.
        Thyagarajan, "Internet Group Management Protocol, Version 3",
        RFC 3376, October 2002.


   [4]  Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
        "RTP: A Transport Protocol for Real-Time Applications", STD 64,
        RFC 3550, July 2003.


   [5]  Huitema, C., "Real Time Control Protocol (RTCP) attribute in
        Session Description Protocol (SDP)", RFC 3605, October 2003.


   [6]  Jennings, C., "NAT/Firewall Behavioral Requirements",
        draft-audet-nat-behave-00 (work in progress), July 2004.


9.2  Informational References


   [7]   Deering, S., "Host extensions for IP multicasting", STD 5, RFC
         1112, August 1989.





Wing                     Expires April 17, 2005                 [Page 7]


Internet-Draft            IGMP Proxy Behavior               October 2004



   [8]   Handley, M., Perkins, C. and E. Whelan, "Session Announcement
         Protocol", RFC 2974, October 2000.


   [9]   Srisuresh, P. and K. Egevang, "Traditional IP Network Address
         Translator (Traditional NAT)", RFC 3022, January 2001.


   [10]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
         Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
         Session Initiation Protocol", RFC 3261, June 2002.


   [11]  Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
         March 1997.


   [12]  Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D. and
         R. Wheeler, "A Method for Transmitting PPP Over Ethernet
         (PPPoE)", RFC 2516, February 1999.


   [13]  Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, S.,
         Handley, M. and V. Jacobson, "Protocol Independent
         Multicast-Sparse Mode (PIM-SM): Protocol Specification", RFC
         2362, June 1998.



Author's Address


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


   EMail: dwing@cisco.com




















Wing                     Expires April 17, 2005                 [Page 8]


Internet-Draft            IGMP Proxy Behavior               October 2004



Intellectual Property Statement


   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.



Disclaimer of Validity


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



Copyright Statement


   Copyright (C) The Internet Society (2004).  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.



Acknowledgment


   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Wing                     Expires April 17, 2005                 [Page 9]