rfc3376.txt

xorp源码hg

Network Working Group                                            B. Cain
Request for Comments: 3376                               Cereva Networks
Obsoletes: 2236                                               S. Deering
Category: Standards Track                                    I. Kouvelas
                                                           Cisco Systems
                                                               B. Fenner
                                                    AT&T Labs - Research
                                                          A. Thyagarajan
                                                                Ericsson
                                                            October 2002


             Internet Group Management Protocol, Version 3

Status of this Memo

   This 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.  Distribution 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 neighboring 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 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 1]

RFC 3376                         IGMPv3                     October 2002


Table of Contents

   1.  Introduction. . . . . . . . . . . . . . . . . . . . . . . . .   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 . . . . . . . .  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 . . . . . . . . . . . . . . . . . . . . .  47
   11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  47
   12. Normative References. . . . . . . . . . . . . . . . . . . . .  47
   13. Informative References. . . . . . . . . . . . . . . . . . . .  47
       Appendix A. Design Rationale. . . . . . . . . . . . . . . . .  49
       Appendix B. Summary of changes from IGMPv2. . . . . . . . . .  50
       Authors' Addresses. . . . . . . . . . . . . . . . . . . . . .  52
       Full Copyright Statement. . . . . . . . . . . . . . . . . . .  53

1. Introduction

   The Internet Group Management Protocol (IGMP) is used by IPv4 systems
   (hosts 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 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.
   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 support 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 receiving
   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 2]

RFC 3376                         IGMPv3                     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", "SHOULD", "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, 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 system's IP service interface 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 socket 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 Frame 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 reception 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 interface is desired, IPMulticastListen is
     invoked separately for each desired multicast address.





Cain, et. al.               Standards Track                     [Page 3]

RFC 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 *only* 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
     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 service 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 that 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 Leave 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 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 4]

RFC 3376                         IGMPv3                     October 2002


3. Multicast Reception State Maintained by Systems

3.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-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 present.  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 reception state for each of
     its interfaces.  That state conceptually consists of a set of
     records of the form:

        (multicast-address, filter-mode, source-list)

     At most one record per multicast-address exists for a given
     interface.  This per-interface state is derived from the per-socket
     state, but may differ from the per-socket state when different
     sockets have differing filter modes and/or source lists for the
     same multicast address and interface.  For example, suppose one
     application or process invokes the following operation on socket
     s1:

        IPMulticastListen ( s1, i, m, INCLUDE, {a, b, c} )

     requesting reception on interface i of packets sent to multicast
     address m, *only* if they come from source a, b, or c.  Suppose
     another application or process invokes the following operation on
     socket s2:



Cain, et. al.               Standards Track                     [Page 5]

RFC 3376                         IGMPv3                     October 2002


        IPMulticastListen ( s2, i, m, INCLUDE, {b, c, d} )

     requesting reception on the same interface i of packets sent to the
     same multicast address m, *only* if they come from sources b, c, or
     d.  In order to satisfy the reception requirements of both sockets,
     it is necessary for interface i to receive packets sent to m from
     any one of the sources a, b, c, or d.  Thus, in this example, the
     reception state of interface i for multicast address m has filter
     mode INCLUDE and source list {a, b, c, d}.

     After a multicast packet has been accepted from an interface by the
     IP layer, its subsequent delivery to the application or process
     listening on a particular socket depends on the multicast reception
     state of that socket [and possibly also on other conditions, such
     as what transport-layer port the socket is bound to].  So, in the
     above example, if a packet arrives on interface i, destined to
     multicast address m, with source address a, it will be delivered on
     socket s1 but not on socket s2.  Note that IGMP Queries and Reports
     are not subject to source filtering and must always be processed by
     hosts and routers.