rfc2236.txt

xorp源码hg

Network Working Group                                            W. Fenner
Request for Comments: 2236                                      Xerox PARC
Updates: 1112                                                November 1997
Category: Standards Track


             Internet Group Management Protocol, Version 2


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 (1997).  All Rights Reserved.

Abstract

   This memo documents IGMPv2, used by IP hosts to report their
   multicast group memberships to routers.  It updates STD 5, RFC 1112.

   IGMPv2 allows group membership termination to be quickly reported to
   the routing protocol, which is important for high-bandwidth multicast
   groups and/or subnets with highly volatile group membership.

   This document is a product of the Inter-Domain Multicast Routing
   working group within the Internet Engineering Task Force.  Comments
   are solicited and should be addressed to the working group's mailing
   list at [e-mail] and/or the author(s).

1.  Definitions

   The 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 [RFC 2119].

2.  Introduction

   The Internet Group Management Protocol (IGMP) is used by IP hosts to
   report their multicast group memberships to any immediately-
   neighboring multicast routers.  This memo describes only the use of
   IGMP between hosts and routers to determine group membership.
   Routers that are members of multicast groups are expected to behave



Fenner                      Standards Track                     [Page 1]

RFC 2236           Internet Group Management Protocol      November 1997


   as hosts as well as routers, and may even respond to their own
   queries.  IGMP may also be used between routers, but such use is not
   specified here.

   Like ICMP, IGMP is a integral part of IP.  It is required to be
   implemented by all hosts wishing to receive IP multicasts.  IGMP
   messages are encapsulated in IP datagrams, with an IP protocol number
   of 2.  All IGMP messages described in this document are sent with IP
   TTL 1, and contain the IP Router Alert option [RFC 2113] in their IP
   header.  All IGMP messages of concern to hosts 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     | Max Resp Time |           Checksum            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Group Address                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2.1.  Type

   There are three types of IGMP messages of concern to the host-
   router interaction:

   0x11 = Membership Query
        There are two sub-types of Membership Query messages:
        - General Query, used to learn which groups have members on an
          attached network.
        - Group-Specific Query, used to learn if a particular group
          has any members on an attached network.

        These two messages are differentiated by the Group Address, as
        described in section 1.4 .  Membership Query messages are
        referred to simply as "Query" messages.

   0x16 = Version 2 Membership Report

   0x17 = Leave Group

   There is an additional type of message, for backwards-compatibility
   with IGMPv1:

   0x12 = Version 1 Membership Report







Fenner                      Standards Track                     [Page 2]

RFC 2236           Internet Group Management Protocol      November 1997


   This document refers to Membership Reports simply as "Reports".  When
   no version is specified, the statement applies equally to both
   versions.

   Unrecognized message types should be silently ignored.  New message
   types may be used by newer versions of IGMP, by multicast routing
   protocols, or other uses.

2.2.  Max Response Time

   The Max Response Time field is meaningful only in Membership Query
   messages, and specifies the maximum allowed time before sending a
   responding report in units of 1/10 second.  In all other messages, it
   is set to zero by the sender and ignored by receivers.

   Varying this setting allows IGMPv2 routers to tune the "leave
   latency" (the time between the moment the last host leaves a group
   and when the routing protocol is notified that there are no more
   members), as discussed in section 7.8.  It also allows tuning of the
   burstiness of IGMP traffic on a subnet, as discussed in section 7.3.

2.3.  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 transmitting
   packets, the checksum MUST be computed and inserted into this field.
   When receiving packets, the checksum MUST be verified before
   processing a packet.

2.4.  Group Address

   In a Membership Query message, the group address field is set to zero
   when sending a General Query, and set to the group address being
   queried when sending a Group-Specific Query.

   In a Membership Report or Leave Group message, the group address
   field holds the IP multicast group address of the group being
   reported or left.

2.5.  Other fields

   Note that IGMP messages may be longer than 8 octets, especially
   future backwards-compatible versions of IGMP.  As long as the Type is
   one that is recognized, an IGMPv2 implementation MUST ignore anything
   past the first 8 octets while processing the packet.  However, the
   IGMP checksum is always computed over the whole IP payload, not just
   over the first 8 octets.



Fenner                      Standards Track                     [Page 3]

RFC 2236           Internet Group Management Protocol      November 1997


3.  Protocol Description

   Note that defaults for timer values are described later in this
   document.  Timer and counter names appear in square brackets.

   The term "interface" is sometimes used in this document to mean "the
   primary interface on an attached network"; if a router has multiple
   physical interfaces on a single network this protocol need only run
   on one of them.  Hosts, on the other hand, need to perform their
   actions on all interfaces that have memberships associated with them.

   Multicast routers use IGMP to learn which groups have members on each
   of their attached physical networks.  A multicast router keeps a list
   of multicast group memberships for each attached network, and a timer
   for each membership.  "Multicast group memberships" means the
   presence of at least one member of a multicast group on a given
   attached network, not a list of all of the members.  With respect to
   each of its attached networks, a multicast router may assume one of
   two roles: Querier or Non-Querier.  There is normally only one
   Querier per physical network.  All multicast routers start up as a
   Querier on each attached network.  If a multicast router hears a
   Query message from a router with a lower IP address, it MUST become a
   Non-Querier on that network.  If a router has not heard a Query
   message from another router for [Other Querier Present Interval], it
   resumes the role of Querier.  Routers periodically [Query Interval]
   send a General Query on each attached network for which this router
   is the Querier, to solicit membership information.  On startup, a
   router SHOULD send [Startup Query Count] General Queries spaced
   closely together [Startup Query Interval] in order to quickly and
   reliably determine membership information.  A General Query is
   addressed to the all-systems multicast group (224.0.0.1), has a Group
   Address field of 0, and has a Max Response Time of [Query Response
   Interval].

   When a host receives a General Query, it sets delay timers for each
   group (excluding the all-systems group) of which it is a member on
   the interface from which it received the query.  Each timer is set to
   a different random value, using the highest clock granularity
   available on the host, selected from the range (0, Max Response Time]
   with Max Response Time as specified in the Query packet.  When a host
   receives a Group-Specific Query, it sets a delay timer to a random
   value selected from the range (0, Max Response Time] as above for the
   group being queried if it is a member on the interface from which it
   received the query.  If a timer for the group is already running, it
   is reset to the random value only if the requested Max Response Time
   is less than the remaining value of the running timer.  When a
   group's timer expires, the host multicasts a Version 2 Membership
   Report to the group, with IP TTL of 1.  If the host receives another



Fenner                      Standards Track                     [Page 4]

RFC 2236           Internet Group Management Protocol      November 1997


   host's Report (version 1 or 2) while it has a timer running, it stops
   its timer for the specified group and does not send a Report, in
   order to suppress duplicate Reports.

   When a router receives a Report, it adds the group being reported to
   the list of multicast group memberships on the network on which it
   received the Report and sets the timer for the membership to the
   [Group Membership Interval].  Repeated Reports refresh the timer.  If
   no Reports are received for a particular group before this timer has
   expired, the router assumes that the group has no local members and
   that it need not forward remotely-originated multicasts for that
   group onto the attached network.

   When a host joins a multicast group, it should immediately transmit
   an unsolicited Version 2 Membership Report for that group, in case it
   is the first member of that group on the network.  To cover the
   possibility of the initial Membership Report being lost or damaged,
   it is recommended that it be repeated once or twice after short
   delays [Unsolicited Report Interval].  (A simple way to accomplish
   this is to send the initial Version 2 Membership Report and then act
   as if a Group-Specific Query was received for that group, and set a
   timer appropriately).

   When a host leaves a multicast group, if it was the last host to
   reply to a Query with a Membership Report for that group, it SHOULD
   send a Leave Group message to the all-routers multicast group
   (224.0.0.2). If it was not the last host to reply to a Query, it MAY
   send nothing as there must be another member on the subnet.  This is
   an optimization to reduce traffic; a host without sufficient storage
   to remember whether or not it was the last host to reply MAY always
   send a Leave Group message when it leaves a group.  Routers SHOULD
   accept a Leave Group message addressed to the group being left, in
   order to accommodate implementations of an earlier version of this
   standard.  Leave Group messages are addressed to the all-routers
   group because other group members have no need to know that a host
   has left the group, but it does no harm to address the message to the
   group.

   When a Querier receives a Leave Group message for a group that has
   group members on the reception interface, it sends [Last Member Query
   Count] Group-Specific Queries every [Last Member Query Interval] to
   the group being left.  These Group-Specific Queries have their Max
   Response time set to [Last Member Query Interval].  If no Reports are
   received after the response time of the last query expires, the
   routers assume that the group has no local members, as above.  Any
   Querier to non-Querier transition is ignored during this time; the
   same router keeps sending the Group-Specific Queries.




Fenner                      Standards Track                     [Page 5]

RFC 2236           Internet Group Management Protocol      November 1997


   Non-Queriers MUST ignore Leave Group messages, and Queriers SHOULD
   ignore Leave Group messages for which there are no group members on
   the reception interface.

   When a non-Querier receives a Group-Specific Query message, if its
   existing group membership timer is greater than [Last Member Query
   Count] times the Max Response Time specified in the message, it sets
   its group membership timer to that value.

4.  Compatibility with IGMPv1 Routers

   An IGMPv2 host may be placed on a subnet where the Querier router has
   not yet been upgraded to IGMPv2.  The following requirements apply:

        The IGMPv1 router will send General Queries with the Max
        Response Time set to 0.  This MUST be interpreted as a value of
        100 (10 seconds).

        The IGMPv1 router expects Version 1 Membership Reports in
        response to its Queries, and will not pay attention to Version 2
        Membership Reports.  Therefore, a state variable MUST be kept
        for each interface, describing whether the multicast Querier on
        that interface is running IGMPv1 or IGMPv2.  This variable MUST
        be based upon whether or not an IGMPv1 query was heard in the
        last [Version 1 Router Present Timeout] seconds, and MUST NOT be
        based upon the type of the last Query heard.  This state
        variable MUST be used to decide what type of Membership Reports
        to send for unsolicited Membership Reports as well as Membership
        Reports in response to Queries.

        An IGMPv2 host MAY suppress Leave Group messages on a network
        where the Querier is using IGMPv1.

   An IGMPv2 router may be placed on a subnet where at least one router
   on the subnet has not yet been upgraded to IGMPv2.  The following
   requirements apply:

        If any IGMPv1 routers are present, the querier MUST use IGMPv1.
        The use of IGMPv1 must be administratively configured, as there
        is no reliable way of dynamically determining whether IGMPv1
        routers are present on a network.  Implementations MAY provide a
        way for system administrators to enable the use of IGMPv1 on
        their routers; in the absence of explicit configuration, the
        configuration MUST default to IGMPv2.  When in IGMPv1 mode,
        routers MUST send Periodic Queries with a Max Response Time of
        0, and MUST ignore Leave Group messages.  They SHOULD also warn
        about receiving an IGMPv2 query, although such warnings MUST be
        rate-limited.