IGMP协议V2版本（RFC2236）.doc

1、RFC 2236 (RFC2236)Internet RFC/STD/FYI/BCP Archives RFC Index | RFC Search | Usenet FAQs | Web FAQs | Documents | Cities Alternate Formats: rfc2236.txt | rfc2236.txt.pdfComment on RFC 2236 RFC 2236 - Internet Group Management Protocol, Version 2Network Working Group W. FennerRequest for Comments: 22

2、36 Xerox PARCUpdates: 1112 November 1997Category: Standards TrackInternet Group Management Protocol, Version 2Status of this MemoThis document specifies an Internet standards track protocol for theInternet community, and requests discussion and suggestions forimprovements. Please refer to the curren

3、t edition of the “InternetOfficial Protocol Standards“ (STD 1) for the standardization stateand status of this protocol. Distribution of this memo is unlimited.Copyright NoticeCopyright (C) The Internet Society (1997). All Rights Reserved.AbstractThis memo documents IGMPv2, used by IP hosts to repor

4、t theirmulticast group memberships to routers. It updates STD 5, RFC 1112.IGMPv2 allows group membership termination to be quickly reported tothe routing protocol, which is important for high-bandwidth multicastgroups and/or subnets with highly volatile group membership.This document is a product of

5、 the Inter-Domain Multicast Routingworking group within the Internet Engineering Task Force. Commentsare solicited and should be addressed to the working groups mailinglist at idmrcs.ucl.ac.uk and/or the author(s).1. DefinitionsThe key words “MUST“, “MUST NOT“, “REQUIRED“, “SHALL“, “SHALL NOT“,“SHOU

6、LD“, “SHOULD NOT“, “RECOMMENDED“, “MAY“, and “OPTIONAL“ in thisdocument are to be interpreted as described in RFC 2119 RFC 2119.2. IntroductionThe Internet Group Management Protocol (IGMP) is used by IP hosts toreport their multicast group memberships to any immediately-neighboring multicast routers

7、. This memo describes only the use ofIGMP between hosts and routers to determine group membership.Routers that are members of multicast groups are expected to behaveas hosts as well as routers, and may even respond to their ownqueries. IGMP may also be used between routers, but such use is notspecif

8、ied here.Like ICMP, IGMP is a integral part of IP. It is required to beimplemented by all hosts wishing to receive IP multicasts. IGMPmessages are encapsulated in IP datagrams, with an IP protocol numberof 2. All IGMP messages described in this document are sent with IPTTL 1, and contain the IP Rout

9、er Alert option RFC 2113 in their IPheader. All IGMP messages of concern to hosts have the followingformat:0 1 2 30 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 |+-+-+-+-+-+-+-+-+-+-+-+

10、-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Group Address |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+2.1. TypeThere are three types of IGMP messages of concern to the host-router interaction:0x11 = Membership QueryThere are two sub-types of Membership Query messages:- General

11、Query, used to learn which groups have members on anattached network.- Group-Specific Query, used to learn if a particular grouphas any members on an attached network.These two messages are differentiated by the Group Address, asdescribed in section 1.4 . Membership Query messages arereferred to sim

12、ply as “Query“ messages.0x16 = Version 2 Membership Report0x17 = Leave GroupThere is an additional type of message, for backwards-compatibilitywith IGMPv1:0x12 = Version 1 Membership ReportThis document refers to Membership Reports simply as “Reports“. Whenno version is specified, the statement appl

13、ies equally to bothversions.Unrecognized message types should be silently ignored. New messagetypes may be used by newer versions of IGMP, by multicast routingprotocols, or other uses.2.2. Max Response TimeThe Max Response Time field is meaningful only in Membership Querymessages, and specifies the

14、maximum allowed time before sending aresponding report in units of 1/10 second. In all other messages, itis set to zero by the sender and ignored by receivers.Varying this setting allows IGMPv2 routers to tune the “leavelatency“ (the time between the moment the last host leaves a groupand when the r

15、outing protocol is notified that there are no moremembers), as discussed in section 7.8. It also allows tuning of theburstiness of IGMP traffic on a subnet, as discussed in section 7.3.2.3. ChecksumThe checksum is the 16-bit ones complement of the ones complementsum of the whole IGMP message (the en

16、tire IP payload). For computingthe checksum, the checksum field is set to zero. When transmittingpackets, the checksum MUST be computed and inserted into this field.When receiving packets, the checksum MUST be verified beforeprocessing a packet.2.4. Group AddressIn a Membership Query message, the gr

17、oup address field is set to zerowhen sending a General Query, and set to the group address beingqueried when sending a Group-Specific Query.In a Membership Report or Leave Group message, the group addressfield holds the IP multicast group address of the group beingreported or left.2.5. Other fieldsN

18、ote that IGMP messages may be longer than 8 octets, especiallyfuture backwards-compatible versions of IGMP. As long as the Type isone that is recognized, an IGMPv2 implementation MUST ignore anythingpast the first 8 octets while processing the packet. However, theIGMP checksum is always computed ove

19、r the whole IP payload, not justover the first 8 octets.3. Protocol DescriptionNote that defaults for timer values are described later in thisdocument. Timer and counter names appear in square brackets.The term “interface“ is sometimes used in this document to mean “theprimary interface on an attach

20、ed network“; if a router has multiplephysical interfaces on a single network this protocol need only runon one of them. Hosts, on the other hand, need to perform theiractions on all interfaces that have memberships associated with them.Multicast routers use IGMP to learn which groups have members on

21、 eachof their attached physical networks. A multicast router keeps a listof multicast group memberships for each attached network, and a timerfor each membership. “Multicast group memberships“ means thepresence of at least one member of a multicast group on a givenattached network, not a list of all

22、 of the members. With respect toeach of its attached networks, a multicast router may assume one oftwo roles: Querier or Non-Querier. There is normally only oneQuerier per physical network. All multicast routers start up as aQuerier on each attached network. If a multicast router hears aQuery messag

23、e from a router with a lower IP address, it MUST become aNon-Querier on that network. If a router has not heard a Querymessage from another router for Other Querier Present Interval, itresumes the role of Querier. Routers periodically Query Intervalsend a General Query on each attached network for w

24、hich this routeris the Querier, to solicit membership information. On startup, arouter SHOULD send Startup Query Count General Queries spacedclosely together Startup Query Interval in order to quickly andreliably determine membership information. A General Query isaddressed to the all-systems multic

25、ast group (224.0.0.1), has a GroupAddress field of 0, and has a Max Response Time of Query ResponseInterval.When a host receives a General Query, it sets delay timers for eachgroup (excluding the all-systems group) of which it is a member onthe interface from which it received the query. Each timer

26、is set toa different random value, using the highest clock granularityavailable on the host, selected from the range (0, Max Response Timewith Max Response Time as specified in the Query packet. When a hostreceives a Group-Specific Query, it sets a delay timer to a randomvalue selected from the rang

27、e (0, Max Response Time as above for thegroup being queried if it is a member on the interface from which itreceived the query. If a timer for the group is already running, itis reset to the random value only if the requested Max Response Timeis less than the remaining value of the running timer. Wh

28、en agroups timer expires, the host multicasts a Version 2 MembershipReport to the group, with IP TTL of 1. If the host receives anotherhosts Report (version 1 or 2) while it has a timer running, it stopsits timer for the specified group and does not send a Report, inorder to suppress duplicate Repor

29、ts.When a router receives a Report, it adds the group being reported tothe list of multicast group memberships on the network on which itreceived the Report and sets the timer for the membership to theGroup Membership Interval. Repeated Reports refresh the timer. Ifno Reports are received for a part

30、icular group before this timer hasexpired, the router assumes that the group has no local members andthat it need not forward remotely-originated multicasts for thatgroup onto the attached network.When a host joins a multicast group, it should immediately transmitan unsolicited Version 2 Membership

31、Report for that group, in case itis the first member of that group on the network. To cover thepossibility of the initial Membership Report being lost or damaged,it is recommended that it be repeated once or twice after shortdelays Unsolicited Report Interval. (A simple way to accomplishthis is to s

32、end the initial Version 2 Membership Report and then actas if a Group-Specific Query was received for that group, and set atimer appropriately).When a host leaves a multicast group, if it was the last host toreply to a Query with a Membership Report for that group, it SHOULDsend a Leave Group messag

33、e to the all-routers multicast group(224.0.0.2). If it was not the last host to reply to a Query, it MAYsend nothing as there must be another member on the subnet. This isan optimization to reduce traffic; a host without sufficient storageto remember whether or not it was the last host to reply MAY

34、alwayssend a Leave Group message when it leaves a group. Routers SHOULDaccept a Leave Group message addressed to the group being left, inorder to accommodate implementations of an earlier version of thisstandard. Leave Group messages are addressed to the all-routersgroup because other group members

35、have no need to know that a hosthas left the group, but it does no harm to address the message to thegroup.When a Querier receives a Leave Group message for a group that hasgroup members on the reception interface, it sends Last Member QueryCount Group-Specific Queries every Last Member Query Interv

36、al tothe group being left. These Group-Specific Queries have their MaxResponse time set to Last Member Query Interval. If no Reports arereceived after the response time of the last query expires, therouters assume that the group has no local members, as above. AnyQuerier to non-Querier transition is

37、 ignored during this time; thesame router keeps sending the Group-Specific Queries.Non-Queriers MUST ignore Leave Group messages, and Queriers SHOULDignore Leave Group messages for which there are no group members onthe reception interface.When a non-Querier receives a Group-Specific Query message,

38、if itsexisting group membership timer is greater than Last Member QueryCount times the Max Response Time specified in the message, it setsits group membership timer to that value.4. Compatibility with IGMPv1 RoutersAn IGMPv2 host may be placed on a subnet where the Querier router hasnot yet been upg

39、raded to IGMPv2. The following requirements apply:The IGMPv1 router will send General Queries with the MaxResponse Time set to 0. This MUST be interpreted as a value of100 (10 seconds).The IGMPv1 router expects Version 1 Membership Reports inresponse to its Queries, and will not pay attention to Ver

40、sion 2Membership Reports. Therefore, a state variable MUST be keptfor each interface, describing whether the multicast Querier onthat interface is running IGMPv1 or IGMPv2. This variable MUSTbe based upon whether or not an IGMPv1 query was heard in thelast Version 1 Router Present Timeout seconds, a

41、nd MUST NOT bebased upon the type of the last Query heard. This statevariable MUST be used to decide what type of Membership Reportsto send for unsolicited Membership Reports as well as MembershipReports in response to Queries.An IGMPv2 host MAY suppress Leave Group messages on a networkwhere the Qu

42、erier is using IGMPv1.An IGMPv2 router may be placed on a subnet where at least one routeron the subnet has not yet been upgraded to IGMPv2. The followingrequirements apply:If any IGMPv1 routers are present, the querier MUST use IGMPv1.The use of IGMPv1 must be administratively configured, as therei

43、s no reliable way of dynamically determining whether IGMPv1routers are present on a network. Implementations MAY provide away for system administrators to enable the use of IGMPv1 ontheir routers; in the absence of explicit configuration, theconfiguration MUST default to IGMPv2. When in IGMPv1 mode,

44、routers MUST send Periodic Queries with a Max Response Time of0, and MUST ignore Leave Group messages. They SHOULD also warnabout receiving an IGMPv2 query, although such warnings MUST berate-limited.If a router is not explicitly configured to use IGMPv1 and hearsan IGMPv1 Query, it SHOULD log a war

45、ning. These warnings MUSTbe rate-limited.5. Compatibility with IGMPv1 HostsAn IGMPv2 host may be placed on a subnet where there are hosts thathave not yet been upgraded to IGMPv2. The following requirementapplies:The host MUST allow its Membership Report to be suppressed byeither a Version 1 Members

46、hip Report or a Version 2 MembershipReport.An IGMPv2 router may be placed on a subnet where there are hosts thathave not yet been upgraded to IGMPv2. The following requirementsapply:If a router receives a Version 1 Membership Report, it MUST seta timer to note that there are version 1 hosts present

47、which aremembers of the group for which it heard the report. This timershould be the same as the Group Membership Interval.If there are version 1 hosts present for a particular group, arouter MUST ignore any Leave Group messages that it receives forthat group.6. Host State DiagramHost behavior is mo

48、re formally specified by the state transitiondiagram below. A host may be in one of three possible states withrespect to any single IP multicast group on any single networkinterface:- “Non-Member“ state, when the host does not belong to the group onthe interface. This is the initial state for all memberships onall network interfaces; it requires no storage in the host.- “Delaying Member“ state, when the host belongs to the group on theinterface and has a report delay timer running for that membership.- “Idle Member“ stat