draft-ietf-idmr-msf-api-02.txt   draft-ietf-idmr-msf-api-03.txt 
IDMR Working Group Dave Thaler IDMR Working Group Dave Thaler
INTERNET-DRAFT Microsoft INTERNET-DRAFT Microsoft
Expires January 2002 Bill Fenner Expires December 2002 Bill Fenner
Type: Informational AT&T Research Type: Informational AT&T Research
Bob Quinn Bob Quinn
Stardust.com Stardust.com
20 July 2001 29 June 2002
Socket Interface Extensions for Multicast Source Filters Socket Interface Extensions for Multicast Source Filters
<draft-ietf-idmr-msf-api-02.txt> <draft-ietf-idmr-msf-api-03.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 2, line 5 skipping to change at page 2, line 5
in progress." in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Copyright Notice Copyright Notice
Draft Multicast Source Filter API July 2001 Draft Multicast Source Filter API June 2002
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2002). All Rights Reserved.
1. Abstract 1. Abstract
IGMPv3 for IPv4 adds the capability for applications to express IGMPv3 for IPv4 adds the capability for applications to express
source filters on multicast group memberships, which allows source filters on multicast group memberships, which allows
receiver applications to determine the set of senders (sources) receiver applications to determine the set of senders (sources)
from which to accept multicast traffic. This capability also from which to accept multicast traffic. This capability also
simplifies support of one-to-many type multicast applications. It simplifies support of one-to-many type multicast applications. It
is expected that in the future, the same capability will be is expected that in the future, the same capability will be
available in IPv6 as well. available in IPv6 as well.
skipping to change at page 3, line 5 skipping to change at page 3, line 5
arguments to these new APIs. These extensions are designed to arguments to these new APIs. These extensions are designed to
provide access to the source filtering features required by provide access to the source filtering features required by
applications, while introducing a minimum of change into the applications, while introducing a minimum of change into the
system and providing complete compatibility for existing multicast system and providing complete compatibility for existing multicast
applications. applications.
Furthermore, RFC 2553 [1] defines socket interface extensions for Furthermore, RFC 2553 [1] defines socket interface extensions for
IPv6, including protocol-independent functions for most IPv6, including protocol-independent functions for most
operations. However, while it defines join and leave functions operations. However, while it defines join and leave functions
Draft Multicast Source Filter API July 2001 Draft Multicast Source Filter API June 2002
for IPv6, it does not provide protocol-independent versions of for IPv6, it does not provide protocol-independent versions of
these operations. Such functions will be described in this these operations. Such functions will be described in this
document. document.
3. Design Considerations 3. Design Considerations
There are a number of important considerations in designing There are a number of important considerations in designing
changes to this well-worn API: changes to this well-worn API:
skipping to change at page 4, line 5 skipping to change at page 4, line 5
retain binary compatibility). Hence, what is needed are new retain binary compatibility). Hence, what is needed are new
source filter APIs that provide the same functionality and also source filter APIs that provide the same functionality and also
allow receiver multicast applications to: allow receiver multicast applications to:
o Specify zero or more unicast (source) address(es) in a source o Specify zero or more unicast (source) address(es) in a source
filter. filter.
o Determine whether the source filter describes an inclusive or o Determine whether the source filter describes an inclusive or
exclusive list of sources. exclusive list of sources.
Draft Multicast Source Filter API July 2001 Draft Multicast Source Filter API June 2002
The new API design must enable this functionality for both IPv4 The new API design must enable this functionality for both IPv4
and IPv6. and IPv6.
3.2. Data Types 3.2. Data Types
The data types of the structure elements given in this memo are The data types of the structure elements given in this memo are
intended to be examples, not absolute requirements. Whenever intended to be examples, not absolute requirements. Whenever
possible, data types from Draft 6.6 (March 1997) of POSIX 1003.1g possible, data types from Draft 6.6 (March 1997) of POSIX 1003.1g
are used: uintN_t means an unsigned integer of exactly N bits are used: uintN_t means an unsigned integer of exactly N bits
skipping to change at page 5, line 5 skipping to change at page 5, line 5
There are a number of different APIs described in this document, There are a number of different APIs described in this document,
that are appropriate for a number of different application types that are appropriate for a number of different application types
and IP versions. Before providing detailed descriptions, this and IP versions. Before providing detailed descriptions, this
section provides a "taxonomy" with a brief description of each. section provides a "taxonomy" with a brief description of each.
IPv4 Multicast Source Filter APIs: IPv4 Multicast Source Filter APIs:
o Basic (Delta-based): Use setsockopt() and reference a single o Basic (Delta-based): Use setsockopt() and reference a single
source and group address pair to make incremental changes source and group address pair to make incremental changes
Draft Multicast Source Filter API July 2001 Draft Multicast Source Filter API June 2002
+ Any-Source: Data accepted from any source by default, but + Any-Source: Data accepted from any source by default, but
source filter control is available source filter control is available
+ Controlled-Source: A source filter is required + Controlled-Source: A source filter is required
o Advanced (Full-state): Use ioctl() and reference the entire set o Advanced (Full-state): Use ioctl() and reference the entire set
of sources with the group address to affect membership changes of sources with the group address to affect membership changes
Protocol-Independent Multicast Source Filter APIs: Protocol-Independent Multicast Source Filter APIs:
skipping to change at page 6, line 5 skipping to change at page 6, line 5
5. IPv4 Multicast Source Filter APIs 5. IPv4 Multicast Source Filter APIs
Version 3 of the Internet Group Management Protocol (IGMPv3) [2] Version 3 of the Internet Group Management Protocol (IGMPv3) [2]
provides the ability to communicate source filter information to provides the ability to communicate source filter information to
the router and hence avoid pulling down data from unwanted sources the router and hence avoid pulling down data from unwanted sources
onto the local link. However, source filters may be implemented onto the local link. However, source filters may be implemented
by the operating system regardless of whether the routers support by the operating system regardless of whether the routers support
IGMPv3, so when the source-filter API is available, applications IGMPv3, so when the source-filter API is available, applications
Draft Multicast Source Filter API July 2001 Draft Multicast Source Filter API June 2002
can always benefit from using it. can always benefit from using it.
There are two categories of the IPv4 source-filter APIs, both of There are two categories of the IPv4 source-filter APIs, both of
which are designed to allow multicast receiver applications to which are designed to allow multicast receiver applications to
designate the unicast address(es) of sender(s) along with the designate the unicast address(es) of sender(s) along with the
multicast group (destination address) to receive. multicast group (destination address) to receive.
o The "Basic" (Delta-based) API is the simpler of the two and o The "Basic" (Delta-based) API is the simpler of the two and
allows an application to reference a single source address in allows an application to reference a single source address in
skipping to change at page 7, line 5 skipping to change at page 7, line 5
applications in the any-source category: applications in the any-source category:
Socket option Argument type Socket option Argument type
IP_ADD_MEMBERSHIP struct ip_mreq IP_ADD_MEMBERSHIP struct ip_mreq
IP_BLOCK_SOURCE struct ip_mreq_source IP_BLOCK_SOURCE struct ip_mreq_source
IP_UNBLOCK_SOURCE struct ip_mreq_source IP_UNBLOCK_SOURCE struct ip_mreq_source
IP_DROP_MEMBERSHIP struct ip_mreq IP_DROP_MEMBERSHIP struct ip_mreq
IP_ADD_MEMBERSHIP and IP_DROP_MEMBERSHIP are already implemented IP_ADD_MEMBERSHIP and IP_DROP_MEMBERSHIP are already implemented
Draft Multicast Source Filter API July 2001 Draft Multicast Source Filter API June 2002
on most operating systems, and are used to join and leave an any- on most operating systems, and are used to join and leave an any-
source group. source group.
IP_BLOCK_SOURCE can be used to block data from a given source to a IP_BLOCK_SOURCE can be used to block data from a given source to a
given group (e.g., if the user "mutes" that source), and given group (e.g., if the user "mutes" that source), and
IP_UNBLOCK_SOURCE can be used to undo this (e.g., if the user then IP_UNBLOCK_SOURCE can be used to undo this (e.g., if the user then
"unmutes" the source). "unmutes" the source).
The argument types of these options are defined as a result of The argument types of these options are defined as a result of
skipping to change at page 8, line 5 skipping to change at page 8, line 5
These options would be used, for example, by "single-source" style These options would be used, for example, by "single-source" style
applications such as audio/video broadcasting. They can also be applications such as audio/video broadcasting. They can also be
used for logical multi-source sessions where each source used for logical multi-source sessions where each source
independently allocates its own source-specific group address. independently allocates its own source-specific group address.
IP_DROP_MEMBERSHIP can be supported, as a convenience, to drop all IP_DROP_MEMBERSHIP can be supported, as a convenience, to drop all
sources which have been joined. The operations are the same as if sources which have been joined. The operations are the same as if
the socket had been closed. the socket had been closed.
Draft Multicast Source Filter API July 2001 Draft Multicast Source Filter API June 2002
5.1.3. Error Codes 5.1.3. Error Codes
When the option would be legal on the group, but an address is When the option would be legal on the group, but an address is
invalid (e.g., when trying to block a source that is already invalid (e.g., when trying to block a source that is already
blocked by the socket, or when trying to drop an unjoined group) blocked by the socket, or when trying to drop an unjoined group)
the error generated is EADDRNOTAVAIL. the error generated is EADDRNOTAVAIL.
When the option itself is not legal on the group (i.e., when When the option itself is not legal on the group (i.e., when
trying a Controlled-Source option on a group after doing trying a Controlled-Source option on a group after doing
skipping to change at page 9, line 5 skipping to change at page 9, line 5
o ioctl() SIOCSIPMSFILTER: to set or modify the source filter o ioctl() SIOCSIPMSFILTER: to set or modify the source filter
content (e.g. unicast source address list) or mode (exclude content (e.g. unicast source address list) or mode (exclude
or include). or include).
SIOCGIPMSFILTER could not be done with getsockopt(), since SIOCGIPMSFILTER could not be done with getsockopt(), since
the group and interface must be passed down in order to the group and interface must be passed down in order to
retrieve the correct filter. This can, however, be done with retrieve the correct filter. This can, however, be done with
an ioctl(), and hence for symmetry, both gets and sets are an ioctl(), and hence for symmetry, both gets and sets are
done with an ioctl. done with an ioctl.
Draft Multicast Source Filter API July 2001 Draft Multicast Source Filter API June 2002
5.2.1. Set Source Filter 5.2.1. Set Source Filter
Ioctl option Argument type Ioctl option Argument type
SIOCSIPMSFILTER struct ip_msfilter SIOCSIPMSFILTER struct ip_msfilter
The argument type of this option is defined as a result of The argument type of this option is defined as a result of
including the <netinet/in.h> header. including the <netinet/in.h> header.
struct ip_msfilter { struct ip_msfilter {
skipping to change at page 10, line 5 skipping to change at page 10, line 5
SIOCGIPMSFILTER struct ip_msfilter SIOCGIPMSFILTER struct ip_msfilter
The structure length pointed to must be at least The structure length pointed to must be at least
IP_MSFILTER_SIZE(0) bytes long, and the imsf_numsrc parameter IP_MSFILTER_SIZE(0) bytes long, and the imsf_numsrc parameter
should be set so that IP_MSFILTER_SIZE(imsf_numsrc) indicates the should be set so that IP_MSFILTER_SIZE(imsf_numsrc) indicates the
buffer length. The result of this call will be that the buffer length. The result of this call will be that the
imsf_multiaddr and imsf_interface fields will be unchanged, while imsf_multiaddr and imsf_interface fields will be unchanged, while
imsf_fmode, imsf_numsrc, and as many source addresses as fit will imsf_fmode, imsf_numsrc, and as many source addresses as fit will
be filled into the application's buffer. be filled into the application's buffer.
Draft Multicast Source Filter API July 2001 Draft Multicast Source Filter API June 2002
If the application does not know the size of the source list If the application does not know the size of the source list
beforehand, it can make a reasonable guess (e.g., 0), and if upon beforehand, it can make a reasonable guess (e.g., 0), and if upon
completion, the imsf_numsrc field holds a larger value, the completion, the imsf_numsrc field holds a larger value, the
operation can be repeated with a large enough buffer. operation can be repeated with a large enough buffer.
6. Protocol-Independent Multicast Source Filter APIs 6. Protocol-Independent Multicast Source Filter APIs
Protocol-independent functions are provided for join and leave Protocol-independent functions are provided for join and leave
operations so that an application may pass a sockaddr_storage operations so that an application may pass a sockaddr_storage
skipping to change at page 11, line 5 skipping to change at page 11, line 5
The argument types of these options are defined as a result of The argument types of these options are defined as a result of
including the <netinet/in.h> header. including the <netinet/in.h> header.
struct group_req { struct group_req {
uint32_t gr_interface; /* interface index */ uint32_t gr_interface; /* interface index */
struct sockaddr_storage gr_group; /* group address */ struct sockaddr_storage gr_group; /* group address */
}; };
struct group_source_req { struct group_source_req {
Draft Multicast Source Filter API July 2001 Draft Multicast Source Filter API June 2002
uint32_t gsr_interface; /* interface index */ uint32_t gsr_interface; /* interface index */
struct sockaddr_storage gsr_group; /* group address */ struct sockaddr_storage gsr_group; /* group address */
struct sockaddr_storage gsr_source; /* source address */ struct sockaddr_storage gsr_source; /* source address */
}; };
The sockaddr_storage structure is defined in RFC 2553 [1] to be The sockaddr_storage structure is defined in RFC 2553 [1] to be
large enough to hold either IPv4 or IPv6 address information. large enough to hold either IPv4 or IPv6 address information.
The rules for generating errors are the same as those given in The rules for generating errors are the same as those given in
skipping to change at page 12, line 5 skipping to change at page 12, line 5
struct sockaddr_storage gf_slist[1]; /* source address */ struct sockaddr_storage gf_slist[1]; /* source address */
}; };
#define GROUP_FILTER_SIZE(numsrc) \ #define GROUP_FILTER_SIZE(numsrc) \
(sizeof(struct group_filter) - sizeof(struct sockaddr_storage) \ (sizeof(struct group_filter) - sizeof(struct sockaddr_storage) \
+ (numsrc) * sizeof(struct sockaddr_storage)) + (numsrc) * sizeof(struct sockaddr_storage))
The imf_numsrc field is used in the same way as described for The imf_numsrc field is used in the same way as described for
imsf_numsrc in section 5.2.2. imsf_numsrc in section 5.2.2.
Draft Multicast Source Filter API July 2001 Draft Multicast Source Filter API June 2002
7. Security Considerations 7. Security Considerations
Although source filtering can help to combat denial-of-service Although source filtering can help to combat denial-of-service
attacks, source filtering alone is not a complete solution, since attacks, source filtering alone is not a complete solution, since
it does not provide protection against spoofing the source address it does not provide protection against spoofing the source address
to be an allowed source. Multicast routing protocols which use to be an allowed source. Multicast routing protocols which use
reverse-path forwarding based on the source address, however, do reverse-path forwarding based on the source address, however, do
provide some natural protection against spoofing the source provide some natural protection against spoofing the source
address, since if a router receives a packet on an interface other address, since if a router receives a packet on an interface other
skipping to change at page 13, line 5 skipping to change at page 13, line 5
EMail: fenner@research.att.com EMail: fenner@research.att.com
Bob Quinn Bob Quinn
IP Multicast Initiative (IPMI) IP Multicast Initiative (IPMI)
Stardust.com Stardust.com
1901 S. Bascom Ave. #333 1901 S. Bascom Ave. #333
Campbell, CA 95008 Campbell, CA 95008
Phone: +1 408 879 8080 Phone: +1 408 879 8080
EMail: rcq@ipmulticast.com EMail: rcq@ipmulticast.com
Draft Multicast Source Filter API July 2001 Draft Multicast Source Filter API June 2002
10. References 10. Normative References
[1] Gilligan, R., Thomson, S., Bound, J., and W. Stevens, "Basic [1] Gilligan, R., Thomson, S., Bound, J., and W. Stevens, "Basic
Socket Interface Extensions for IPv6", RFC 2553, March 1999. Socket Interface Extensions for IPv6", RFC 2553, March 1999.
11. Non-normative References
[2] Cain, B., Deering, S., Fenner, B., Kouvelas, I., and A. [2] Cain, B., Deering, S., Fenner, B., Kouvelas, I., and A.
Thyagarajan, "Internet Group Management Protocol, Version 3", Thyagarajan, "Internet Group Management Protocol, Version 3",
Work in progress, draft-ietf-idmr-igmp-v3-07.txt, March 2001. draft-ietf-idmr-igmp-v3-11.txt, Work in progress, May 2002.
[3] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener [3] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener
Discovery (MLD) for IPv6", RFC 2710, October 1999. Discovery (MLD) for IPv6", RFC 2710, October 1999.
11. Full Copyright Statement 12. Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished This document and translations of it may be copied and furnished
to others, and derivative works that comment on or otherwise to others, and derivative works that comment on or otherwise
explain it or assist in its implmentation may be prepared, copied, explain it or assist in its implmentation may be prepared, copied,
published and distributed, in whole or in part, without published and distributed, in whole or in part, without
restriction of any kind, provided that the above copyright notice restriction of any kind, provided that the above copyright notice
and this paragraph are included on all such copies and derivative and this paragraph are included on all such copies and derivative
works. However, this document itself may not be modified in any works. However, this document itself may not be modified in any
way, such as by removing the copyright notice or references to the way, such as by removing the copyright notice or references to the
Internet Society or other Internet organizations, except as needed Internet Society or other Internet organizations, except as needed
skipping to change at page 14, line 5 skipping to change at page 14, line 5
The limited permissions granted above are perpetual and will not The limited permissions granted above are perpetual and will not
be revoked by the Internet Society or its successors or assigns. be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on This document and the information contained herein is provided on
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Draft Multicast Source Filter API July 2001 Draft Multicast Source Filter API June 2002
Table of Contents Table of Contents
1: Abstract ................................................. 2 1: Abstract ................................................. 2
2: Introduction ............................................. 2 2: Introduction ............................................. 2
3: Design Considerations .................................... 3 3: Design Considerations .................................... 3
3.1: What Needs to be Added ................................. 3 3.1: What Needs to be Added ................................. 3
3.2: Data Types ............................................. 4 3.2: Data Types ............................................. 4
3.3: Headers ................................................ 4 3.3: Headers ................................................ 4
3.4: Structures ............................................. 4 3.4: Structures ............................................. 4
skipping to change at page 14, line 31 skipping to change at page 14, line 31
5.1.3: Error Codes .......................................... 8 5.1.3: Error Codes .......................................... 8
5.2: Advanced (Full-state) API for IPv4 ..................... 8 5.2: Advanced (Full-state) API for IPv4 ..................... 8
5.2.1: Set Source Filter .................................... 9 5.2.1: Set Source Filter .................................... 9
5.2.2: Get Source Filter .................................... 9 5.2.2: Get Source Filter .................................... 9
6: Protocol-Independent Multicast Source Filter APIs ........ 10 6: Protocol-Independent Multicast Source Filter APIs ........ 10
6.1: Basic (Delta-based) API ................................ 10 6.1: Basic (Delta-based) API ................................ 10
6.2: Advanced (Full-state) API .............................. 11 6.2: Advanced (Full-state) API .............................. 11
7: Security Considerations .................................. 12 7: Security Considerations .................................. 12
8: Acknowledgements ......................................... 12 8: Acknowledgements ......................................... 12
9: Authors' Addresses ....................................... 12 9: Authors' Addresses ....................................... 12
10: References .............................................. 13 10: Normative References .................................... 13
11: Full Copyright Statement ................................ 13 11: Non-normative References ................................ 13
12: Full Copyright Statement ................................ 13
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/