Network Working Group Arun Thulasi Internet-Draft Hewlett Packard May 2005 IPv6 Multicast Filtering Rules 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 November 10, 2005. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. 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 November 10, 2005 [Page 1] Internet-Draft IPv6 Multicast Filtering Rules May 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. IANA Considerations........................................ 4 7. Security Considerations.................................... 4 References.................................................... 5 Authors' Addresses............................................ 5 Appendix A: A method to allow an implementation to provide both behaviors.................................... 5 Copyright Statement........................................... 6 Intellectual Property Statement............................... 7 Acknowledgements.............................................. 7 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 implementations do not deliver such messages. Arun Thulasi Expires November 10, 2005 [Page 2] Internet-Draft IPv6 Multicast Filtering Rules May 2005 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 nodes that are associated with this multicast group and listening on the port. 4.2 Synopsis of Multicast Client 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 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 nodes 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 an ordinary multicast address. Arun Thulasi Expires November 10, 2005 [Page 3] Internet-Draft IPv6 Multicast Filtering Rules May 2005 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. IANA Considerations There are no IANA considerations for this document. 7. 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 Arun Thulasi Expires November 10, 2005 [Page 4] Internet-Draft IPv6 Multicast Filtering Rules May 2005 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 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. 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. Arun Thulasi Expires November 10, 2005 [Page 5] Internet-Draft IPv6 Multicast Filtering Rules May 2005 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. 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 November 10, 2005 [Page 6] Internet-Draft IPv6 Multicast Filtering Rules May 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 November 10, 2005 [Page 7]