Internet DRAFT - draft-arunt-ipv6-multicast-filtering-rules

draft-arunt-ipv6-multicast-filtering-rules




Network Working Group                                       Arun Thulasi
Internet-Draft                                           Hewlett Packard   
                                                           December 2005



                IPv6 Multicast Filtering Rules
        <draft-arunt-ipv6-multicast-filtering-rules-01.txt>



Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of section 3 of RFC 3978.  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.  This document may not be modified, and
   derivative works of it may not be created, except to publish it as
   an RFC and to translate it into languages other than English.

   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 June 10, 2006.


Copyright Notice

   Copyright (C) The Internet Society (2005).


Abstract

   This document describes requirements and rules for multicast
   packets to be filtered in IP before sending it to the upper layer
   protocols like TCP or UDP.





Arun Thulasi               Expires June 5, 2005               [Page 1]

Internet-Draft         IPv6 Multicast Filtering Rules     December  2005

Table of Contents

   1.    Introduction............................................    2
   2.    Terminologies and Definitions...........................    2
   3.    Current Behavior........................................    2
   4.    Multicast Applications' Behavior .......................    3
      4.1   Synopsis of Multicast Server Behavior................    3
      4.2   Synopsis of Multicast Client Behavior.................   3
   5.    Multicast Address Types and Recommended Behavior........    3 
      5.1   Special Case Addresses...............................    3
      5.2   Other Multicast Addresses............................    3 
   6. Behavior under SSM (Source Specific Multicasting)..........    4
   7. IANA Considerations........................................    5
   8. Security Considerations....................................    5

   References....................................................    5
   Authors' Addresses............................................    6
   Appendix A: A method to allow an implementation to provide
               both behaviors....................................    6
   Copyright Statement...........................................    6
   Intellectual Property Statement...............................    8
   Acknowledgements..............................................    8

1. Introduction

   Multicasting[MULTICAST] is one of the important functionalities
   supported by an Internet Protocol. Multicasting allows an 
   application to join any number of given multicast addresses on an
   interface and be able to receive packets destined for the multicast
   addresses. In certain cases, Multicasting also allows the application
   to receive packets destined to a multicast address even if it has not
   joined the appropriate multicast address. This behavior of
   Multicasting has been implemented differently across operating
   systems. This document specifies a set of rules to ensure
   interoperability across operating systems and would guarantee
   consistency across implementations. 

2. Terminologies and Definitions

   Upper Layer Protocols (ULP):    Upper Layer Protocol refers to a
        protocol that lies above the Internet Protocol. For example,
        It could be Transmission Control Protocol [TCP] or User
        Datagram Protocol [UDP].

   Multicast Address (MA):    A Multicast Address, unless and otherwise
        explicitly specified, refers to a Multicast Address in
        [IPv6]. It also refers to the Multicast Address Group that an
        application might join.

3. Current Behavior
   
   The current behavior is implementation specific. While certain
   implementations allow the application to receive packets destined to
   the All Nodes Address and other appropriate addresses even if
   they have not explicitly joined the address, certain other


Arun Thulasi               Expires June 5, 2005               [Page 2]

Internet-Draft         IPv6 Multicast Filtering Rules     December  2005

   implementations do not deliver such messages.

   This document aims at having interoperability when applications are
   ported across different implementations. This behavior of multicast
   filtering is optional, and the implementation might device its own
   way of intimating the application. However, the default behavior
   would be to perform no filtering in IP based on the multicast
   listening groups that the application is part of.


4. Multicast Applications' Behavior


4.1 Synopsis of Multicast Server Behavior

   The multicast server sends packets addressed to the appropriate
   MA. The destination address field in the IP header would be the MA
   and the port would be set to the foreign port in the remote host.
   The multicast server would expect the packet to reach the hosts
   that are associated with this multicast group and listening on 
   the port.

4.2 Synopsis of Multicast Client Socket Behavior

   A Multicast Client would join a MA Group using an implementation
   specific mechanism. It must bind either to the MA or to the
   unspecified address AND a given port. A client socket must join
   the multicast address group in order to ensure receiving packets
   destined to that multicast group address.

   A Multicast Client would leave a Multicast Address Group using an
   implementation specific mechanism. 


5. Multicast Address Types and Recommended Behavior

5.1 Special Addresses 

   In multicasting, certain addresses are designated as special
   addresses which every application is expected to listen on. All
   IPv6 hosts are expected to listen on the All Nodes Multicast
   Address of ff02::1 and the Solicited Node Multicast Address which is
   computed as function of the IPv6 Address [IPv6 Multi]. If a machine
   is brought up as a router, it would be expected to listen on the
   All Routers Multicast Address of ff02::2 as well [IPv6 Multi].

   Any Application should receive packets destined to the aforesaid
   multicast addresses even if they have not explicitly joined those
   Address Groups. Applications should continue to receive packets even
   if they had explicitly joined and left the aforesaid groups.


5.2 Other Multicast Addresses

   Any other address that is not a special address is considered to be


Arun Thulasi               Expires June 5, 2005               [Page 3]

Internet-Draft         IPv6 Multicast Filtering Rules     December  2005

   an ordinary multicast address.

   When the Internet Protocol receives a packet destined for a MA, it
   must check for listeners on the port, bound to either the MA
   specified in the destination field of the IP header or the
   Unspecified Address AND the port. If such an entry is available,
   IP SHOULD deliver it to the ULP. 

   An Application MAY receive packets destined to any of the other
   multicast addresses if, and only if, the application is bound to
   either the MA itself or to the UA, and is bound to the port that
   matches the destination port in the IP Packet.

   An Application MUST NOT receive packets destined to any of the
   ordinary multicast addresses if it is not bound to that specific
   address or the Unspecified Address OR if it is not bound to the
   appropriate port.

   The IP MAY implement another level of filtering to determine if the
   application has registered itself to the multicast group by joining
   the MA using an implementation specific mechanism. This behavior is
   optional and IP may implement this feature based on implementation
   specifications. However, the default behavior would be that
   an application MAY receive a packet even when it has not joined the
   group explicitly if it satisfies any of the conditions mentioned
   above.

   An application SHALL NOT expect to receive packets destined to the
   port by merely binding to unspecified address/port. To ensure that an
   application always receives packets destined to a certain
   multicast address, the application would have to explicitly join
   the multicast group. 

   This concept of optional filtering by IP arises only when the packet
   is delivered to IP by the lower layer. If the lower-layer, for any
   reason, does not send the packet upstream to IP, the requirement for
   optional filtering by IP does not arise.

6. Behavior under SSM (Source Specific Multicasting)

   Source Specific Multicasting [SSM] is a mechanism aimed at handling
   a set of problems existing in the current multicasting architecture
   like address allocation and access controls.

   Support for a SSM-based application involves a level of filtering
   that the SSM mechanism brings in by itself and is different from
   the filtering that IP should implement should handle ASM. An SSM
   based application should be able to run on a host that does not
   have filtering implemented at IP. However, IP should be sentient
   enough to handle packets in such a way as to adhere to the 
   requirements expressed in SSM.

   An implementation should provide a way with which an application
   notifies that it requires SSM (rather than ASM) to IP. Since SSM
   requires the calling application to use a different semantic


Arun Thulasi               Expires June 5, 2005               [Page 4]

Internet-Draft         IPv6 Multicast Filtering Rules     December  2005

   involving 'Channels', IP would be able to identify an SSM channel
   from other ASM streams. API requirements are given in "Socket
   Interface Extensions for Multicast Source Filters" [RFC3678].
   IP may use any implementation specific mechanism to store the
   list of such channels.

   When IP receives an incoming packet with its destination address
   from the SSM address space, IP SHOULD look for the appropriate
   SSM channel and pass on the message upstream. If IP is not able
   to locate an SSM channel for the packet, IP SHOULD drop the packet.

   When IP receives a packet with its destination address from the
   ASM address space, IP SHOULD deliver the packet upstream only if
   the receiving application is NOT a SSM-based application.

7. IANA Considerations

   There are no IANA considerations for this document.

8. Security Considerations

   The behavior specified in this document does not have any known
   security issue as of now since

   - The behavior suggested here is optional and not mandated. However
   it is recommended that an implementation provide a method of
   informing the application about its behavior to facilitate 
   interoperability.

   - The packet may be delivered to an application only if it has
   bound to the appropriate address/port combination AND if the packet
   has the same port number in the destination field of the IP header.
   Hence, to shut out unwanted packets, the application could bind
   itself to the MA itself.



References
   
   IP           Refers to [IPv6], unless specifically mentioned 
                otherwise.

   [IPv4]       Postel, J., "Internet Protocol", STD 5, RFC 791,
                September 1981. 

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

   [TCP]        Postel, J., "Transmission Control Protocol", STD 5,
                RFC 793, September 1981. 

   [UDP]        Postel, J., "User Datagram Protocol", STD 5, RFC 793,
                August 1980. 
   
   [IPv6-MULTI] Deering, S., Hinden, R., "IPv6 Multicast Address


Arun Thulasi               Expires June 5, 2005               [Page 5]

Internet-Draft         IPv6 Multicast Filtering Rules     December  2005

                Assignments", RFC 2375, December 1998

   [IPv6-ADDR]  Deering, S., Hinden, R., "IP Version 6 Addressing
                Architecture", Work in Progress, February 2005

   [RFC-2119]   Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP14, RFC2119, March 1997.

   [MULTICAST]  Deering, S., "Host Extensions for IP Multicasting",
                STD 5, RFC 1112, Stanford University, August 1989.
   
   [RFC-3678]   Thaler, D., Fenner, B., Quinn, B. "Socket Interface
                Extensions for Multicast Source Filters", RFC 3678,
                January 2004.

   [SSM]        Christophe Diot et al, "An Overview of Source-Specific
                Multicast (SSM)", RFC 3569, July 2003
 
 

Authors' Addresses

   Comments are solicited and should be addressed to the working
   group's mailing list at ipv6@ietf.org and/or the author(s).

   Arun Thulasi 
   Hewlett-Packard,
   29, Cunningham Road
   Bangalore - 560052
   India.
   arun_thulasi@hp.com


Appendix A: A method to allow an implementation to provide both
   behaviors

   One way to provide this behavior is using a kernel tunable and
   make multicast filtering in IP a system wide behavior. When
   multicast filtering is enabled, the implementation could intimate
   the calling application using an appropriate error message that 
   it has not been sent a packet which it should have gotten otherwise.
   
   Another way that an implementation could provide both the behaviors
   would be by providing an appropriate socket option. This option
   would make Multicast Filtering in IP a socket/application specific
   behavior. When an application wants to enable multicast filtering
   in IP, it would send the appropriate socket option to enable it
   in IP. Once the application is done, it could unset the option
   using a similar socket option. 

Copyright Statement

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


Arun Thulasi               Expires June 5, 2005               [Page 6]

Internet-Draft         IPv6 Multicast Filtering Rules     December  2005


   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.

















































Arun Thulasi               Expires June 5, 2005               [Page 7]

Internet-Draft         IPv6 Multicast Filtering Rules     December  2005

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.

Acknowledgments

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






























Arun Thulasi               Expires June 5, 2005               [Page 8]