igmpv3 rfc3376 (部分翻译)

faqs.org
faqs.org - Internet FAQ Archives
RFC 3376 - Internet Group Management Protocol, Version 3
Internet RFC Index
Usenet FAQ Index
Other FAQs
Documents
Tools
Search
Search FAQs
Search RFCs
IFC Home
Cities
Countries
Hospitals
Web Hosting Ratings
Search the RFC Archives
 
Or Display the document by number

[ RFC Index | Usenet FAQs | Web FAQs | Documents | Cities | Abstracts | Counties ]

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.

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.

   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.

   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].

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:

        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.

     Filtering of packets based upon a socket's multicast reception
     state is a new feature of this service interface.  The previous
     service interface [RFC1112] described no filtering based upon
     multicast join state; rather, a join on a socket simply caused the
     host to join a group on the given interface, and packets destined
     for that group could be delivered to all sockets whether they had
     joined or not.

     The general rules for deriving the per-interface state from the
     per-socket state are as follows:  For each distinct (interface,
     multicast-address) pair that appears in any socket state, a per-
     interface record is created for that multicast address on that
     interface.  Considering all socket records containing the same
     (interface, multicast-address) pair,

   o if *any* such record has a filter mode of EXCLUDE, then the filter
     mode of the interface record is EXCLUDE, and the source list of the
     interface record is the intersection of the source lists of all
     socket records in EXCLUDE mode, minus those source addresses that
     appear in any socket record in INCLUDE mode.  For example, if the
     socket records for multicast address m on interface i are:

        from socket s1:  ( i, m, EXCLUDE, {a, b, c, d} )
        from socket s2:  ( i, m, EXCLUDE, {b, c, d, e} )
        from socket s3:  ( i, m, INCLUDE, {d, e, f} )

     then the corresponding interface record on interface i is:

                         ( m, EXCLUDE, {b, c} )

     If a fourth socket is added, such as:

        from socket s4:  ( i, m, EXCLUDE, {} )

     then the interface record becomes:

                         ( m, EXCLUDE, {} )

   o if *all* such records have a filter mode of INCLUDE, then the
     filter mode of the interface record is INCLUDE, and the source list
     of the interface record is the union of the source lists of all the
     socket records.  For example, if the socket records for multicast
     address m on interface i are:

        from socket s1:  ( i, m, INCLUDE, {a, b, c} )
        from socket s2:  ( i, m, INCLUDE, {b, c, d} )
        from socket s3:  ( i, m, INCLUDE, {e, f} )

     then the corresponding interface record on interface i is:

                         ( m, INCLUDE, {a, b, c, d, e, f} )

     An implementation MUST NOT use an EXCLUDE interface record to
     represent a group when all sockets for this group are in INCLUDE
     state.  If system resource limits are reached when an interface
     state source list is calculated, an error MUST be returned to the
     application which requested the operation.

   The above rules for deriving the interface state are (re-)evaluated
   whenever an IPMulticastListen invocation modifies the socket state by
   adding, deleting, or modifying a per-socket state record.  Note that
   a change  of socket state does not necessarily result in a change of
   interface state.

4. Message Formats

   IGMP messages are encapsulated in IPv4 datagrams, with an IP protocol
   number of 2.  Every IGMP message described in this document is sent
   with an IP Time-to-Live of 1, IP Precedence of Internetwork Control
   (e.g., Type of Service 0xc0), and carries an IP Router Alert option
   [RFC-2113] in its IP header.  IGMP message types are registered by
   the IANA [IANA-REG] as described by [RFC-3228].

   There are two IGMP message types of concern to the IGMPv3 protocol
   described in this document:

      Type Number (hex)   Message Name
      -----------------   ------------

            0x11          Membership Query

            0x22          Version 3 Membership Report

   An implementation of IGMPv3 MUST also support the following three
   message types, for interoperation with previous versions of IGMP (see
   section 7):

           0x12          Version 1 Membership Report    [RFC-1112]

           0x16          Version 2 Membership Report    [RFC-2236]

           0x17          Version 2 Leave Group          [RFC-2236]

   Unrecognized message types MUST be silently ignored.  Other message
   types may be used by newer versions or extensions of IGMP, by
   multicast routing protocols, or for other uses.

   In this document, unless otherwise qualified, the capitalized words
   "Query" and "Report" refer to IGMP Membership Queries and IGMP
   Version 3 Membership Reports, respectively.

4.1. Membership Query Message

   Membership Queries are sent by IP multicast routers to query the
   multicast reception state of neighboring interfaces.  Queries have
   the following format:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Type = 0x11  | Max Resp Code |           Checksum            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Group Address                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Resv  |S| QRV |     QQIC      |     Number of Sources (N)     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Source Address [1]                      |
      +-                                                             -+
      |                       Source Address [2]                      |
      +-                              .                              -+
      .                               .                               .
      .                               .                               .
      +-                                                             -+
      |                       Source Address [N]                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4.1.1. Max Resp Code

   The Max Resp Code field specifies the maximum time allowed before
   sending a responding report.  The actual time allowed, called the Max
   Resp Time, is represented in units of 1/10 second and is derived from
   the Max Resp Code as follows:

   If Max Resp Code < 128, Max Resp Time = Max Resp Code

   If Max Resp Code >= 128, Max Resp Code represents a floating-point
   value as follows:

       0 1 2 3 4 5 6 7
      +-+-+-+-+-+-+-+-+
      |1| exp | mant  |
      +-+-+-+-+-+-+-+-+

   Max Resp Time = (mant | 0x10) << (exp + 3)

   Small values of Max Resp Time allow IGMPv3 routers to tune the "leave
   latency" (the time between the moment the last host leaves a group
   and the moment the routing protocol is notified that there are no
   more members).  Larger values, especially in the exponential range,
   allow tuning of the burstiness of IGMP traffic on a network.

4.1.2. Checksum

   The Checksum is the 16-bit one's complement of the one's complement
   sum of the whole IGMP message (the entire IP payload).  For computing
   the checksum, the Checksum field is set to zero.  When receiving
   packets, the checksum MUST be verified before processing a packet.
   [RFC-1071]

4.1.3. Group Address

   The Group Address field is set to zero when sending a General Query,
   and set to the IP multicast address being queried when sending a
   Group-Specific Query or Group-and-Source-Specific Query (see section
   4.1.9, below).

4.1.4. Resv (Reserved)

   The Resv field is set to zero on transmission, and ignored on
   reception.

4.1.5. S Flag (Suppress Router-Side Processing)

   When set to one, the S Flag indicates to any receiving multicast
   routers that they are to suppress the normal timer updates they
   perform upon hearing a Query.  It does not, however, suppress the
   querier election or the normal "host-side" processing of a Query that
   a router may be required to perform as a consequence of itself being
   a group member.

4.1.6. QRV (Querier's Robustness Variable)

   If non-zero, the QRV field contains the [Robustness Variable] value
   used by the querier, i.e., the sender of the Query.  If the querier's
   [Robustness Variable] exceeds 7, the maximum value of the QRV field,
   the QRV is set to zero.  Routers adopt the QRV value from the most
   recently received Query as their own [Robustness Variable] value,
   unless that most recently received QRV was zero, in which case the
   receivers use the default [Robustness Variable] value specified in
   section 8.1 or a statically configured value.

4.1.7. QQIC (Querier's Query Interval Code)

   The Querier's Query Interval Code field specifies the [Query
   Interval] used by the querier.  The actual interval, called the
   Querier's Query Interval (QQI), is represented in units of seconds
   and is derived from the Querier's Query Interval Code as follows:

   If QQIC < 128, QQI = QQIC

   If QQIC >= 128, QQIC represents a floating-point value as follows:

       0 1 2 3 4 5 6 7
      +-+-+-+-+-+-+-+-+
      |1| exp | mant  |
      +-+-+-+-+-+-+-+-+

   QQI = (mant | 0x10) << (exp + 3)

   Multicast routers that are not the current querier adopt the QQI
   value from the most recently received Query as their own [Query
   Interval] value, unless that most recently received QQI was zero, in
   which case the receiving routers use the default [Query Interval]
   value specified in section 8.2.

4.1.8. Number of Sources (N)

   The Number of Sources (N) field specifies how many source addresses
   are present in the Query.  This number is zero in a General Query or
   a Group-Specific Query, and non-zero in a Group-and-Source