RFC 3376 IGMP v3.docx

1、RFC 3376 IGMP v3Network Working Group B. CainRequest for Comments: 3376 Cereva NetworksObsoletes: 2236 S. DeeringCategory: Standards Track I. Kouvelas Cisco Systems B. Fenner AT&T Labs - Research A. Thyagarajan Ericsson October 2002 Internet Group Management Protocol, Version 3Status of this Memo Th

2、is document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribu

3、tion of this memo is unlimited.Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved.Abstract This document specifies Version 3 of the Internet Group Management Protocol, IGMPv3. IGMP is the protocol used by IPv4 systems to report their IP multicast group memberships to nei

4、ghboring multicast routers. Version 3 of IGMP adds support for source filtering, that is, the ability for a system to report interest in receiving packets *only* from specific source addresses, or from *all but* specific source addresses, sent to a particular multicast address. That information may

5、be used by multicast routing protocols to avoid delivering multicast packets from specific sources to networks where there are no interested receivers. This document obsoletes RFC 2236.Cain, et. al. Standards Track Page 1RFC 3376 IGMPv3 October 2002Table of Contents 1. Introduction. . . . . . . . .

6、. . . . . . . . . . . . . . . . 2 2. The Service Interface for Requesting IP Multicast Reception . 3 3. Multicast Reception State Maintained by Systems . . . . . . . 5 4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 7 5. Description of the Protocol for Group Members . . . . . . . .

7、19 6. Description of the Protocol for Multicast Routers . . . . . . 24 7. Interoperation with Older Versions of IGMP. . . . . . . . . . 35 8. List of Timers, Counters, and Their Default Values. . . . . . 40 9. Security Considerations . . . . . . . . . . . . . . . . . . . 43 10. IANA Considerations .

8、 . . . . . . . . . . . . . . . . . . . . 47 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 47 12. Normative References. . . . . . . . . . . . . . . . . . . . . 47 13. Informative References. . . . . . . . . . . . . . . . . . . . 47 Appendix A. Design Rationale. . . . . . . . . . .

9、 . . . . . . 49 Appendix B. Summary of changes from IGMPv2. . . . . . . . . . 50 Authors Addresses. . . . . . . . . . . . . . . . . . . . . . 52 Full Copyright Statement. . . . . . . . . . . . . . . . . . . 531. Introduction The Internet Group Management Protocol (IGMP) is used by IPv4 systems (host

10、s and routers) to report their IP multicast group memberships to any neighboring multicast routers. Note that an IP multicast router may itself be a member of one or more multicast groups, in which case it performs both the multicast router part of the protocol (to collect the membership information

11、 needed by its multicast routing protocol) and the group member part of the protocol (to inform itself and other, neighboring multicast routers of its memberships). IGMP is also used for other IP multicast management functions, using message types other than those used for group membership reporting

12、. This document specifies only the group membership reporting functions and messages. This document specifies Version 3 of IGMP. Version 1, specified in RFC-1112, was the first widely-deployed version and the first version to become an Internet Standard. Version 2, specified in RFC-2236, added suppo

13、rt for low leave latency, that is, a reduction in the time it takes for a multicast router to learn that there are no longer any members of a particular group present on an attached network. Version 3 adds support for source filtering, that is, the ability for a system to report interest in receivin

14、g packets *only* from specific source addresses, as required to support Source-Specific Multicast SSM, or from *all but* specific source addresses, sent to a particular multicast address. Version 3 is designed to be interoperable with Versions 1 and 2.Cain, et. al. Standards Track Page 2RFC 3376 IGM

15、Pv3 October 2002 Multicast Listener Discovery (MLD) is used in a similar way by IPv6 systems. MLD version 1 MLD implements the functionality of IGMP version 2; MLD version 2 MLDv2 implements the functionality of IGMP version 3. The capitalized key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SH

16、OULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in RFC-2119. Due to the lack of italics, emphasis is indicated herein by bracketing a word or phrase in * characters.2. The Service Interface for Requesting IP Multicast Reception Within an IP system

17、, there is (at least conceptually) a service interface used by upper-layer protocols or application programs to ask the IP layer to enable and disable reception of packets sent to specific IP multicast addresses. In order to take full advantage of the capabilities of IGMPv3, a systems IP service int

18、erface must support the following operation: IPMulticastListen ( socket, interface, multicast-address, filter-mode, source-list ) where: o socket is an implementation-specific parameter used to distinguish among different requesting entities (e.g., programs or processes) within the system; the socke

19、t parameter of BSD Unix system calls is a specific example. o interface is a local identifier of the network interface on which reception of the specified multicast address is to be enabled or disabled. Interfaces may be physical (e.g., an Ethernet interface) or virtual (e.g., the endpoint of a Fram

20、e Relay virtual circuit or the endpoint of an IP-in-IP tunnel). An implementation may allow a special unspecified value to be passed as the interface parameter, in which case the request would apply to the primary or default interface of the system (perhaps established by system configuration). If r

21、eception of the same multicast address is desired on more than one interface, IPMulticastListen is invoked separately for each desired interface. o multicast-address is the IP multicast address, or group, to which the request pertains. If reception of more than one multicast address on a given inter

22、face is desired, IPMulticastListen is invoked separately for each desired multicast address.Cain, et. al. Standards Track Page 3RFC 3376 IGMPv3 October 2002 o filter-mode may be either INCLUDE or EXCLUDE. In INCLUDE mode, reception of packets sent to the specified multicast address is requested *onl

23、y* from those IP source addresses listed in the source-list parameter. In EXCLUDE mode, reception of packets sent to the given multicast address is requested from all IP source addresses *except* those listed in the source-list parameter. o source-list is an unordered list of zero or more IP unicast

24、 addresses from which multicast reception is desired or not desired, depending on the filter mode. An implementation MAY impose a limit on the size of source lists, but that limit MUST NOT be less than 64 addresses per list. When an operation causes the source list size limit to be exceeded, the ser

25、vice interface MUST return an error. For a given combination of socket, interface, and multicast address, only a single filter mode and source list can be in effect at any one time. However, either the filter mode or the source list, or both, may be changed by subsequent IPMulticastListen requests t

26、hat specify the same socket, interface, and multicast address. Each subsequent request completely replaces any earlier request for the given socket, interface and multicast address. Previous versions of IGMP did not support source filters and had a simpler service interface consisting of Join and Le

27、ave operations to enable and disable reception of a given multicast address (from *all* sources) on a given interface. The equivalent operations in the new service interface follow: The Join operation is equivalent to IPMulticastListen ( socket, interface, multicast-address, EXCLUDE, ) and the Leave

28、 operation is equivalent to: IPMulticastListen ( socket, interface, multicast-address, INCLUDE, ) where is an empty source list. An example of an API providing the capabilities outlined in this service interface is in FILTER-API.Cain, et. al. Standards Track Page 4RFC 3376 IGMPv3 October 20023. Mult

29、icast Reception State Maintained by Systems3.1. Socket State For each socket on which IPMulticastListen has been invoked, the system records the desired multicast reception state for that socket. That state conceptually consists of a set of records of the form: (interface, multicast-address, filter-

30、mode, source-list) The socket state evolves in response to each invocation of IPMulticastListen on the socket, as follows: o If the requested filter mode is INCLUDE *and* the requested source list is empty, then the entry corresponding to the requested interface and multicast address is deleted if p

31、resent. If no such entry is present, the request is ignored. o If the requested filter mode is EXCLUDE *or* the requested source list is non-empty, then the entry corresponding to the requested interface and multicast address, if present, is changed to contain the requested filter mode and source list. If no such entry is present, a new entry is created, using the parameters specified in the request.3.2. Interface State In addition to the per-socket multicast reception state, a system must also maintain or compute multicast rece