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]
