rfc2236.txt

xorp源码hg

RFC 2236           Internet Group Management Protocol      November 1997


8.8.  Last Member Query Interval

   The Last Member Query Interval is the Max Response Time inserted into
   Group-Specific Queries sent in response to Leave Group messages, and
   is also the amount of time between Group-Specific Query messages.
   Default: 10 (1 second)

   This value may be tuned to modify the "leave latency" of the network.
   A reduced value results in reduced time to detect the loss of the
   last member of a group.

8.9.  Last Member Query Count

   The Last Member Query Count is the number of Group-Specific Queries
   sent before the router assumes there are no local members.  Default:
   the Robustness Variable.

8.10.  Unsolicited Report Interval

   The Unsolicited Report Interval is the time between repetitions of a
   host's initial report of membership in a group.  Default: 10 seconds.

8.11.  Version 1 Router Present Timeout

   The Version 1 Router Present Timeout is how long a host must wait
   after hearing a Version 1 Query before it may send any IGMPv2
   messages.  Value: 400 seconds.

9.  Message destinations

   This information is provided elsewhere in the document, but is
   summarized here for convenience.

   Message Type                  Destination Group
   ------------                  -----------------
   General Query                 ALL-SYSTEMS (224.0.0.1)
   Group-Specific Query          The group being queried
   Membership Report             The group being reported
   Leave Message                 ALL-ROUTERS (224.0.0.2)


     Note: in older (i.e., non-standard and now obsolete) versions of
     IGMPv2, hosts send Leave Messages to the group being left.  A
     router SHOULD accept Leave Messages addressed to the group being
     left in the interests of backwards compatibility with such hosts.
     In all cases, however, hosts MUST send to the ALL-ROUTERS address
     to be compliant with this specification.




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


10.  Security Considerations

   We consider the ramifications of a forged message of each type.

   Query Message:

     A forged Query message from a machine with a lower IP address than
     the current Querier will cause Querier duties to be assigned to the
     forger.  If the forger then sends no more Query messages, other
     routers' Other Querier Present timer will time out and one will
     resume the role of Querier.  During this time, if the forger
     ignores Leave Messages, traffic might flow to groups with no
     members for up to [Group Membership Interval].

     A forged Query message sent to a group with members will cause the
     hosts which are members of the group to report their memberships.
     This causes a small amount of extra traffic on the LAN, but causes
     no protocol problems.

   Report messages:

     A forged Report message may cause multicast routers to think there
     are members of a group on a subnet when there are not.  Forged
     Report messages from the local subnet are meaningless, since
     joining a group on a host is generally an unprivileged operation,
     so a local user may trivially gain the same result without forging
     any messages.  Forged Report messages from external sources are
     more troublesome; there are two defenses against externally forged
     Reports:

     - Ignore the Report if you cannot identify the source
       address of the packet as belonging to a subnet assigned to the
       interface on which the packet was received.  This solution means
       that Reports sent by mobile hosts without addresses on the local
       subnet will be ignored.

     - Ignore Report messages without Router Alert options [RFC 2113],
       and require that routers not forward Report messages.  (The
       requirement is not a requirement of generalized filtering in the
       forwarding path, since the packets already have Router Alert
       options in them).  This solution breaks backwards compatibility
       with implementations of earlier versions of this specification
       which did not require Router Alert.








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


     A forged Version 1 Report Message may put a router into "version 1
     members present" state for a particular group, meaning that the
     router will ignore Leave messages.  This can cause traffic to flow
     to groups with no members for up to [Group Membership Interval].
     There are two defenses against forged v1 Reports:

     - To defend against externally sourced v1 Reports, ignore the
       Report if you cannot identify the source address of the packet as
       belonging to a subnet assigned to the interface on which the
       packet was received.  This solution means that v1 Reports sent by
       mobile hosts without addresses on the local subnet will be
       ignored.

     - Provide routers with a configuration switch to ignore Version 1
       messages completely.  This breaks automatic compatibility with
       Version 1 hosts, so should only be used in situations where "fast
       leave" is critical.  This solution protects against forged
       version 1 reports from the local subnet as well.

   Leave message:

     A forged Leave message will cause the Querier to send out Group-
     Specific Queries for the group in question.  This causes extra
     processing on each router and on each member of the group, but can
     not cause loss of desired traffic.  There are two defenses against
     externally forged Leave messages:

     - Ignore the Leave message if you cannot identify the source
       address of the packet as belonging to a subnet assigned to the
       interface on which the packet was received.  This solution means
       that Leave messages sent by mobile hosts without addresses on the
       local subnet will be ignored.

     - Ignore Leave messages without Router Alert options [RFC 2113],
       and require that routers not forward Leave messages.  (The
       requirement is not a requirement of generalized filtering in the
       forwarding path, since the packets already have Router Alert
       options in them).  This solution breaks backwards compatibility
       with implementations of earlier versions of this specification
       which did not require Router Alert.

11.  Acknowledgments

   IGMPv2 was designed by Rosen Sharma and Steve Deering.







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


12.  References

   RFC 2119       Bradner, S., "Key words for use in RFCs to Indicate
                  Requirement Levels", BCP 14, RFC 2119, March 1997.

   RFC 2113       Katz, D., "IP Router Alert Option," RFC 2113,
                  February 1997.

   RFC 1112       Deering, S., "Host Extensions for IP Multicasting",
                  STD 5, RFC 1112, August 1989.









































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


13.  Appendix I - Changes from IGMPv1

   The IGMPv1 "Version" and "Type" fields are combined into a single
   "Type" field.

   A new IGMP Type is assigned to Version 2 Membership Report messages,
   so a router may tell the difference between an IGMPv1 and IGMPv2 host
   report.

   A new IGMP Type is created for the IGMPv2 Leave Group message.

   The Membership Query message is changed so that a previously unused
   field contains a new value, the Max Response Time.

   The IGMPv2 spec now specifies a querier election mechanism.  In
   IGMPv1, the querier election was left up to the multicast routing
   protocol, and different protocols used different mechanisms.  This
   could result in more than one querier per network, so the election
   mechanism has been standardized in IGMPv2.  However, this means that
   care must be taken when an IGMPv2 router is trying to coexist with an
   IGMPv1 router that uses a different querier election mechanism.  In
   particular, it means that an IGMPv2 router must be able to act as an
   IGMPv1 router on a particular network if configured to do so.  The
   actions required include:

   - Set the Max Response Time field to 0 in all queries.

   - Ignore Leave Group messages.

   The IGMPv2 spec relaxes the requirements on validity-checking for
   Membership Queries and Membership Reports.  When upgrading an
   implementation, be sure to remove any checks that do not belong.

   The IGMPv2 spec requires the presence of the IP Router Alert option
   [RFC 2113] in all packets described in this memo.

14.  Author's Address

   William C. Fenner
   Xerox PARC
   3333 Coyote Hill Road
   Palo Alto, CA 94304
   Phone: [phone]

   EMail: [e-mail]






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


15.  Full Copyright Statement

   Copyright (C) The Internet Society (1997).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
























Fenner                      Standards Track                    [Page 24]