PIM Working Group                                              H. Asaeda
Internet-Draft                                                      NICT
Intended status: Informational                                N. Leymann                         December 11, 2012
Expires: April 19, June 14, 2013                              Deutsche Telekom AG
                                                        October 16, 2012

   IGMP/MLD-Based Explicit Membership Tracking Function for Multicast
                                Routers
                  draft-ietf-pim-explicit-tracking-02
                  draft-ietf-pim-explicit-tracking-03

Abstract

   This document describes the IGMP/MLD-based explicit membership
   tracking function for multicast routers.  The explicit tracking
   function is useful for accounting and contributes to saving network
   resource resources and fast leaves
   (i.e. shortened shortening leave latency).

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on April 19, June 14, 2013.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Explicit Tracking Function  .  Terminology . . . . . . . . . . . . . . . . . 4
     2.1.  Specific Query Surpression Mechanism  . . . . . . . . . . . 4
     2.2.  Shortening Leave Latencies  . . .
   3.  Explicit Tracking Function  . . . . . . . . . . . . . 5
     2.3.  Considerations . . . . . 4
     3.1.  Membership State Information  . . . . . . . . . . . . . . . 4
     3.2.  Specific Query Suppression  . . 5
   3.  Membership State Information . . . . . . . . . . . . . . 5
     3.3.  Shortening Leave Latency  . . . 6
   4.  Multicast Router Behavior . . . . . . . . . . . . . . 6
   4.  Lowering the Possibility of Outdated Membership State . . . . . 7
   5.  Compatibility . . . .  All-Zero and Unspecified Source Addresses . . . . . . . . . . . 8
   6.  Compatibility with Older Version Protocols  . . . . . . . . . . 8
   6.
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
   7.
   8.  Security Considerations . . . . . . . . . . . . . . . . . . . . 8
   8. 9
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 8
   9. 9
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . . . 9
     9.1.
     10.1. Normative References  . . . . . . . . . . . . . . . . . . . 9
     9.2.
     10.2. Informative References  . . . . . . . . . . . . . . . . . . 9
   Authors' Addresses
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.  Introduction

   The Internet Group Management Protocol (IGMP) [1] for IPv4 and the
   Multicast Listener Discovery Protocol (MLD) [2] for IPv6 are the
   standard protocols used by listener member hosts and multicast routers.  When
   a host starts starts/finishes listening to particular multicast channels, it
   sends IGMP/MLD State-Change Report messages specifying the
   corresponding channel information as the join/leave request to its
   upstream router (i.e., an adjacent multicast router or IGMP/MLD proxy [4]).  This
   device [5]).  The "unsolicited" Report is report messages are sent only once
   upon reception. reception/departure.

   IGMP/MLD are non-reliable protocols; the unsolicited Report report messages
   may be lost or may not be reached to upstream routers.  To recover resolve the
   problem, the routers need to update membership information by
   periodically sending IGMP/MLD General Query messages periodically. messages.  Member hosts
   then reply with "solicited" Report report messages whenever they receive the
   Query
   query messages.

   Multicast routers are able to capable of periodically maintain maintaining the
   multicast
   listener (or membership) membership state of downstream hosts attached on to the same
   link by getting acquiring unsolicited Report report messages and synchronize synchronizing the
   actual membership state within the General Query timer interval
   (i.e., [Query Interval] value defined in [1][2].)  However, this
   approach does not guarantee that the membership state is always
   perfectly synchronized.  To minimize the possibility of having the
   outdated membership information, routers may shorten the periodic
   General Query timer interval.  Unfortunately, this would increase increases the
   number of transmitted solicited Report report messages and induce induces network
   congestion.  And the more greater the amount of network congestion is occurred, congestion, the
   more
   greater the potential for IGMP/MLD Report report messages may be being lost and the
   membership state information may be being outdated in the router.

   The IGMPv3 [1] and MLDv2 [2] protocols can provide the capability of
   keeping ability to
   keep track of the downstream (adjacent) multicast listener membership state to
   multicast routers. routers, yet the specifications are not clearly given.
   This document describes the "IGMP/MLD-based explicit member tracking
   function" for multicast routers and details
   the a way for routers to
   implement the function.  By enabling the this explicit tracking function,
   routers can keep track of the downstream multicast membership state.
   This function implements enables the following
   requirements:

   o  Per-host accounting following:

   o  Reducing the number of transmitted Query query and Report report messages

   o  Shortening leave latencies

   o  Per-host accounting
   o  Maintaining multicast channel characteristics (or statistics)

   where this document mainly focuses on

   In addition, the above second processing of IGMP membership or MLD listener
   messages consumes CPU resources on individual IGMP/MLD querier and third
   bullets in the following sections.
   report sender devices.  The explicit tracking function does therefore
   reduces not change message formats used
   by only the standard IGMPv3 [1] and MLDv2 [2], and their lightweight
   version protocols [3].  It does not change a multicast data sender's
   and receiver's behavior as well.

2.  Explicit Tracking Function

2.1.  Specific Query Surpression Mechanism network load but also the CPU load on these
   devices.

   The explicit tracking function can reduce does not guarantee that the number membership
   state will always be perfectly synchronized; the list of Group-
   Specific or Group-and-Source Specific Query messages transmitted from
   a router, and then the number of Current-State Report messages
   transmitted from member hosts.  As the result, network resources used
   for IGMP/MLD query-and-reply communications between a router and tracked
   member hosts can may be saved.  This mechanism is called "specific query
   surpression mechanism".

   According to [1] and [2], whenever a outdated in the router receives because of host departure
   from the network without sending State-Change
   Report, it sends the corresponding Group-Specific Report messages or Group-and-Source
   Specific Query loss
   of such messages due to confirm whether the Report sender is network congestion.  Therefore, a router
   enabling the
   last member host or not.  After getting these function ought to send periodic IGMPv3/MLDv2 General
   Query messages, all messages and inquire about solicited IGMPv3/MLDv2 report
   messages from downstream member hosts joining the corresponding channel reply with own
   Current-State Report messages.  This condition to maintain an up-to-date
   membership state.

   The explicit tracking function potentially requires transmitting a number large amount of Current-State Report messages and consumes network
   resources especially
   memory so that routers keep all membership states.  Particularly when many hosts have been joining the same
   channel.

   On the other hand, if
   a router enables needs to maintain a large number of member hosts, this
   resource requirement could have an impact.  Operators may decide to
   disable this function when their routers have insufficient memory
   resources, despite the benefits mentioned above.

   The explicit tracking
   function, it function does not need to always ask Current-State Report change message
   transmission to formats used
   by the member hosts whenever standard IGMPv3 [1] and MLDv2 [2], and their lightweight
   version protocols [3]; nor does it receives the State-
   Change Report.  This is because change a multicast data sender's
   and receiver's behavior.

2.  Terminology

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

3.  Explicit Tracking Function

3.1.  Membership State Information

   A router enabling the explicit tracking function works
   with the expectation that maintains the
   "membership state information".  When a multicast router receives a
   Current-State or State-Change Report sender is the last
   remaining member of the channel.  Even if message, it creates this expectation is wrong
   (i.e.,
   membership state information or adds or deletes the State-Change Report sender was not receiver IP
   address to or from it.  If there are no more receivers maintained,
   the sole member), other
   members remaining in router may keep the same channel will reply membership state information with identical
   Report messages, so an empty
   receiver list.

   The membership state information consists of the end result following
   information:

      (S, G, number of receivers, (receiver records))

   where each receiver record is of the same and no problem occurs.
   (Section 3 details form:

      (IGMP/MLD membership/listener report sender's address)

   This state information must work properly when a receiver (i.e.,
   report sender) sends the point.) identical report messages multiple times.

   In addition, the processing of IGMP membership or MLD listener
   messages consumes CPU resources on state information, each IGMP/MLD querier S and report
   sender devices themselves.  Therefore, G indicates a single IPv4/IPv6
   address.  S is set to "Null" for Any-Source Multicast (ASM)
   communication (i.e., (*,G) join reception).  In order to simplify the
   implementation, the explicit tracking function
   reduces does not only the network load but also the CPU load on these
   devices as well.

   Note that keep the default behavior
   state of the (S,G) joined with EXCLUDE filter mode.  If a router that supports receives
   an (S,G) join/leave request with EXCLUDE filter mode from the
   explicit tracking function disables this specific query surpression
   mechanism, in order
   downstream hosts, it translates it to avoid the risk caused by the situation in
   which multiple multicast routers exist on a LAN (*,G) join state/leave
   request and records the querier
   router is not the forwarder router.  When state and the querier surpresses receivers' addresses in the
   specific query message transmission, if it recognizes
   maintained membership state information.  Note that the State-
   Change Report sender is not the sole member of the channel, it this membership
   state translation does not send change the specific query routing protocol behavior.  The
   routing protocol must deal with the original join/leave request and all routers on
   translate the same LAN do request only for the membership state information.

3.2.  Specific Query Suppression

   In accordance with [1] and [2], whenever a router receives the State-
   Change Report, it sends the corresponding Group-Specific or Group-
   and-Source Specific Query messages to confirm whether or not
   receive Current-State Report message from the member hosts.  The
   forwarder in this case may prune
   report sender is the routing path, although there are
   other sole member host.  All member hosts subscribing joining the
   identical channel on send their own Current-State Report messages after
   acquiring these query messages.  Transmitting a large number of
   Current-State Report messages consumes network resources, and this
   may pose a particular problem when many hosts joining the LAN.

2.2.  Shortening Leave Latencies identical
   channel send these reports simultaneously.

   The explicit tracking function works with can reduce the expectation that number of Group-
   Specific or Group-and-Source Specific Query messages transmitted from
   a router, and reduce the
   State-Change number of Current-State Report sender is the last remaining messages
   transmitted from member of the
   channel.  Thanks to this functionality, hosts.  If a router can tune timers enables the explicit
   tracking function with "specific query suppression", it suppresses
   specific query transmission and
   values related to decide transmits specific query messages
   only when the router expects that the State-Change Report sender was is
   the sole member.

   The [Last Member Query Interval] (LMQI) and [Last Listener Query
   Interval] (LLQI) values specify member of the maximum time allowed before
   sending a responding Report.  The [Last Member Query Count] (LMQC) channel, based on its membership state
   information (expressed in Section 3.1).

   As standard behavior for [1] and [Last Listener Query Count] (LLQC) are the number of [2], a router also sends a Group-
   Specific Queries or Group-and-Source Specific Queries sent before the
   router assumes there are no local members.  The [Last Member Query
   Time] (LMQT) and [Last Listener Query Time] (LLQT) values are the
   total time the router should wait for multiple times when it
   receives a report, after the Querier has
   sent the first query.

   The default values for LMQI/LLQI defined State Change Report message (e.g., leave request) from a
   member host.  This is in order to confirm whether or not the standard
   specifications [1][2] are 1 second.  For host is
   the sole member.  However, if the router enabling the explicit
   tracking function, LMQI/LLQI would be set to 1 second function runs specific query suppression and receives one or
   shorter.  The LMQC/LLQC may be set to "1"
   more replies for the router, whereas
   their default values are the [Robustness Variable] value whose
   default value is "2".  Smaller LMQC/LLQC give smaller LMQT/LLQT; this
   condition shortens specific query retransmission from the leave latencies.

2.3.  Considerations

   As with
   downstream member(s), the basic concepts router can cancel resending of IGMP and MLD, the explicit tracking
   function does not guarantee
   identical specific query message(s).

   Note that the membership state is always perfectly
   synchronized; routers enabling default behavior of the router that supports the
   explicit tracking function still
   need to send IGMPv3/MLDv2 Query messages and inquire solicited
   IGMPv3/MLDv2 Report messages from downstream members to maintain
   downstream membership state.

   o  IGMP/MLD messages are non-reliable and may be lost SHOULD disable this specific query
   suppression in the
      transmission, therefore routers need order to confirm avoid the membership risk caused by
      sending Query messages.

   o  To preserve compatibility with older versions of IGMP/MLD, routers
      need to support downstream hosts that are not upgraded to the
      latest versions of IGMP/MLD situation in
   which multiple multicast routers exist on a LAN and run the report suppression
      mechanism.

   o  It querier
   router is impossible to identify hosts when hosts send IGMP reports
      with a source address of 0.0.0.0.

   Regarding the last bullet, not the IGMPv3 specification [1] mentions that
   an IGMPv3 Report is usually sent with a valid IP source address,
   although it permits that a host uses forwarder router.  When the 0.0.0.0 source address (as
   it happens that querier suppresses the host has not yet acquired an IP address),
   specific query message transmission, and
   routers MUST accept a report with a source address of 0.0.0.0.  The
   MLDv2 specification [2] mentions expects that an MLDv2 Report MUST be sent
   with a valid IPv6 link-local source address, although an MLDv2 Report
   can be sent with the unspecified address (::), if the sending
   interface has not acquired a valid link-local address yet. [2] also
   mentions that routers silently discard a message that State-
   Change Report sender is not sent
   with a valid link-local address or sent with the unspecified address,
   without taking any action, because sole member of the security consideration.

   Another concern is that channel, it does
   not send the explicit tracking function requires
   additional processing capability specific query and a possibly large memory for none of the routers to keep all membership states.  Especially when a router
   needs to maintain on the same LAN
   receive a large number of Current-State Report message from the corresponding member hosts,
   hosts.  The forwarder in this resource
   requirement may be potentially-impacted.  Operators case may decide prune the routing path though
   there are other member hosts subscribing to
   disable this function when their routers do not have enough memory
   resources.

3.  Membership State Information

   The the channel on the LAN.

3.3.  Shortening Leave Latency

   A router enabling the explicit tracking function is implemented with can shorten leave
   latencies by tuning several timers and values to what it expects
   whether or not the following
   membership state information:

      (S, G, number of receivers, (receiver records))

   where each receiver record State-Change Report sender is of the form:

      (IGMP/MLD Membership/Listener Report sender's address)

   This state information must work properly when channel's sole
   member.

   The [Last Member Query Interval] (LMQI) and [Last Listener Query
   Interval] (LLQI) values specify the maximum time allowed before
   sending a receiver (i.e.,
   Report sender) sends responding Report.  The [Last Member Query Count] (LMQC)
   and [Last Listener Query Count] (LLQC) are the same Report messages multiple times.

   In number of Group-
   Specific Queries or Group-and-Source Specific Queries sent before the state information, each "S"
   router assumes there are no local members.  The [Last Member Query
   Time] (LMQT) and "G" indicates a single IPv4/
   IPv6 address.  "S" is set to "Null" [Last Listener Query Time] (LLQT) values are the
   total time the router should wait for an Any-Source Multicast (ASM)
   communication (i.e., (*,G) join reception).  In order to simplify a report after the
   implementation, Querier has
   sent the explicit tracking function does not keep first query.

   The default value for LMQI/LLQI defined in the
   state of (S,G) join with EXCLUDE filter mode.  If standard
   specifications [1][2] is 1 second.  For a router receives
   (S,G) join/leave request with EXCLUDE filter mode from enabling the downstream
   hosts, it translates
   explicit tracking function, the join/leave request LMQI/LLQI MAY be set to (*,G) join state/leave
   request and records the state and 1 second or
   shorter.  The LMQC/LLQC values MAY be set to 1 for the receivers' addresses into router,
   whereas their default values are the
   maintained membership state information.  Note that this membership
   state translation does not change [Robustness Variable] value
   whose default value is 2.  Smaller LMQC/LLQC values give smaller
   LMQT/LLQT, which shortens the routing protocol behavior; leave latencies.  On the
   routing protocol must deal with other hand,
   setting smaller LMQC/LLQC values poses the original join/leave request and
   translate risk described in
   Section 4.  Operators setting smaller LMQC/LLQC values must recognize
   this tradeoff.

4.  Lowering the request only for Possibility of Outdated Membership State

   There are possibilities that the membership state information.

4.  Multicast Router Behavior

   The expectation performed by
   a router enabling the explicit tracking function makes routers expect whether the
   State-Change Report sender is the last remaining will be inconsistent
   due to an outdated membership state.  For example, (1) a router
   expects that more than one corresponding member host exists on its
   LAN, but in fact no member host exists for that multicast channel, or
   (2) a router expects that no corresponding member host exists on its
   LAN, but in fact more than one member host exists for that multicast
   channel.  These cases are particularly likely for a router that
   enables specific query suppression (as in Section 3.2) and configures
   small LMQC/LLQC for shortening leave latency (as in Section 3.3).

   The first of these cases may occur in an environment where the
   channel.  Therefore sole
   member host departs the router transmits network without sending a corresponding Current-
   State State-Change Report message only when the
   message.  This is because a router thinks that enabling specific query
   suppression does not send a specific query if it believes the State-
   Change Report report
   sender is not the last remaining sole member host.  The router later detects that
   there is no member host for the corresponding channels when it does
   not receive a Current-State Report within the timeout of the channel.
   This contributes to saving response
   for the periodic General Query.  However, this situation prolongs
   leave latency and wastes network resources and also shortening
   leave latency.

   To synchronize since the membership state information, router forwards
   unneeded traffic until that point.

   The second case occurs when a multicast router receives sends a specific query but does
   not receive a Current-State or State-Change Report message, it
   adds the receiver IP address to from a downstream host within an
   LMQT or delete from LLQT period.  It recognizes that no member host exists on the receiver records
   or creates
   LAN and might prune the corresponding membership state information.  If there
   are no more receiver records left, routing path.  The router reestablishes the membership state information
   is deleted from
   routing path when it receives the router. solicited report message for the
   channels.  However, the membership state information downstream hosts may be still outdated in loose the router.  It may be happened especially in a mobile multicast
   environment that some member hosts have joined to or left from data packets
   until the
   network without sending State-Change Report messages.  Or, some
   State-Change Report messages are lost due routing path is reestablished and the data forwarding is
   restarted.

   In order to network congestion.
   Therefore, reduce the possibility of the incorrect membership
   expectation and keep the up-to-date membership state information,
   when a router enabling the explicit tracking function ought
   to send enables
   specific query suppression, the periodic General Query regularly.

   Regarding router SHOULD configure the leave latency, as specified in Section 2.2, LMQC/LLQC
   value to 2 (the default value of the [Robustness Variable] value) or
   higher; or, when a router enabling the explicit tracking function contributes to
   configures a small LMQC/LLQC, the fast leave by setting
   LMQI/LLQI to "1" second or shorter router SHOULD NOT enable specific
   query suppression.

5.  All-Zero and LMQC/LLQC to "1".  However, if
   LMQC/LLQC is configured "2" or bigger value, then the router's
   behavior may be changed from the standard specification.  According
   to Unspecified Source Addresses

   The IGMPv3 specification [1] and [2], a router sends mentions that an IGMPv3 report is
   usually sent with a Group- (and-Source) Specific Query
   [LMQC - 1] or [LLQC - 1] times when valid IP source address, yet it receives State Change Report
   message (e.g. leave request) from permits a member host, in order host to confirm
   whether or not
   use the 0.0.0.0 source address (since the host is has not yet acquired
   an IP address), and routers must accept a report with this source
   address.  The MLDv2 specification [2] mentions that an MLDv2 report
   must be sent with a valid IPv6 link-local source address, yet an
   MLDv2 report may be sent with the only remaining member.  However, this
   document RECOMMENDS that unspecified address (::) if the router enabling the explicit tracking
   function receives the corresponding Current State Report before the
   Specific Query retransmission, it cancels
   sending the same Specific
   Query for other [LMQC - 1] or [LLQC - 1] times.

   Note interface has not acquired a valid link-local address. [2]
   also mentions that there is some risk routers silently discard a message that is not
   sent with a router misses valid link-local address or looses Report
   messages sent from remaining members if the router adopts small LMQC/
   LLQC; however the wrong expectation would be lower happened for with the unspecified
   address, without taking any action, because of security
   considerations.

   When a router enabling the explicit tracking function.  And to avoid the
   problem, a router can start sending a Group- (and-Source) Specific
   Query message when function receives IGMP/
   MLD report messages with an all-zero or unspecified source address,
   it expects deals with the number IGMP/MLD report messages correctly as defined in
   [1][2] and continuously keeps track of the remaining members is
   small, such as 5, membership state, but not 0.

5.
   SHOULD NOT maintain the host specifying all-zero or an unspecified
   source address in its membership state information.

6.  Compatibility with Older Version Protocols

   The explicit tracking function does not work with the older versions of
   IGMP or MLD, IGMPv1 [5], [6], IGMPv2 [6] [7], or MLDv1 [7], [8], because a member
   host using these protocols adopts a enables "membership report suppression mechanism suppression" by
   which a the host would will cancel sending a pending membership Reports reports if a
   similar Report was report is observed from another member on the network.

   If

   To preserve compatibility with older versions of IGMP/MLD, routers
   need to support downstream hosts that are not upgraded to the latest
   versions and run membership report suppression.  Therefore, if a
   multicast router enabling the explicit tracking function changes its
   compatibility mode to the older versions of IGMP or MLD, versions, the router should turn off SHOULD disable
   the explicit tracking function but should not function.  On the other hand, the router MAY
   NOT flush the maintained membership state information (i.e., keep the
   current membership state information as is). information.  When the
   router changes back to IGMPv3 or MLDv2 mode, it would resume resumes the function
   with the
   kept old membership state information, information even if the state
   information is outdated.  This manner would give provides "smooth state transition"
   that does not initiate the membership state information from scratch
   and synchronizes the actual membership state smoothly.

6.

7.  IANA Considerations

   This document has no actions for IANA.

7.

8.  Security Considerations

   There is no additional security considerations.

8. consideration for [1][2][3] provided.

9.  Acknowledgements

   Toerless Eckert, Sergio Figueiredo, Nicolai Leymann, Stig Venaas, and
   others provided many constructive and insightful comments.

9.

10.  References

9.1.

10.1.  Normative References

   [1]  Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
        Thyagarajan, "Internet Group Management Protocol, Version 3",
        RFC 3376, October 2002.

   [2]  Vida, R. and L. Costa, "Multicast Listener Discovery Version 2
        (MLDv2) for IPv6", RFC 3810, June 2004.

   [3]  Liu, H., Cao, W., and H. Asaeda, "Lightweight Internet Group
        Management Protocol Version 3 (IGMPv3) and Multicast Listener
        Discovery Version 2 (MLDv2) Protocols", RFC 5790, February 2010.

9.2.

   [4]  Bradner, S., "Key words for use in RFCs to indicate requirement
        levels", RFC 2119, March 1997.

10.2.  Informative References

   [4]

   [5]  Fenner, B., He, H., Haberman, B., and H. Sandick, "Internet
        Group Management Protocol (IGMP) / Multicast Listener Discovery
        (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")",
        RFC 4605, August 2006.

   [5]

   [6]  Deering, S., "Host Extensions for IP Multicasting", RFC 1112,
        August 1989.

   [6]

   [7]  Fenner, W., "Internet Group Management Protocol, Version 2",
        RFC 2373, July 1997.

   [7]

   [8]  Deering, S., Fenner, W., and B. Haberman, "Multicast Listener
        Discovery (MLD) for IPv6", RFC 2710, October 1999.

Authors' Addresses

Author's Address

   Hitoshi Asaeda
   National Institute of Information and Communications Technology (NICT)
   Network Architecture Laboratory
   4-2-1 Nukui-Kitamachi
   Koganei, Tokyo  184-8795
   Japan

   Email: asaeda@nict.go.jp
   Nicolai Leymann
   Deutsche Telekom AG
   Winterfeldtstrasse 21-27
   Berlin  10781
   Germany

   Email: n.leymann@telekom.de