[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 RFC 4286

MAGMA WG                                                     B. Haberman
Internet-Draft                                                   JHU APL
Expires: March 9, 2005                                         J. Martin
                                                             Netzwert AG
                                                       September 8, 2004


                       Multicast Router Discovery
                       draft-ietf-magma-mrdisc-02

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
   author represents that any applicable patent or other IPR claims of
   which he or she is aware have been or will be disclosed, and any of
   which he or she become aware will be disclosed, in accordance with
   RFC 3668.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on March 9, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2004).

Abstract

   The concept of Internet Group Membership Protocol (IGMP) and
   Multicast Listener Discovery (MLD) snooping requires the ability to
   identify the location of multicast routers.  Since snooping is not
   standardized, there are many mechanisms in use to identify the
   multicast routers.  However, this can lead to interoperability issues
   between multicast routers and snooping switches from different



Haberman & Martin        Expires March 9, 2005                  [Page 1]

Internet-Draft         Multicast Router Discovery         September 2004


   vendors.

   This document introduces a general mechanism that allows for the
   discovery of multicast routers.  This new mechanism, Multicast Router
   Discovery (MRD), introduces a standardized means of identifying
   multicast routers without a dependency on particular multicast
   routing protocols.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Protocol Overview  . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Multicast Router Advertisement . . . . . . . . . . . . . . . .  5
     3.1   Advertisement Configuration Variables  . . . . . . . . . .  5
       3.1.1   MaxAdertisementInterval  . . . . . . . . . . . . . . .  5
       3.1.2   MinAdvertisementInterval . . . . . . . . . . . . . . .  5
       3.1.3   MaxInitialAdvertisementInterval  . . . . . . . . . . .  6
       3.1.4   MaxInitialAdvertisements . . . . . . . . . . . . . . .  6
       3.1.5   NeighborDeadInterval . . . . . . . . . . . . . . . . .  6
     3.2   Advertisement Packet Format  . . . . . . . . . . . . . . .  6
       3.2.1   Type Field . . . . . . . . . . . . . . . . . . . . . .  6
       3.2.2   Advertisement Interval Field . . . . . . . . . . . . .  7
       3.2.3   Checksum Field . . . . . . . . . . . . . . . . . . . .  7
       3.2.4   Query Interval Field . . . . . . . . . . . . . . . . .  7
       3.2.5   Robustness Variable Field  . . . . . . . . . . . . . .  7
     3.3   IP Header Fields . . . . . . . . . . . . . . . . . . . . .  7
       3.3.1   Source Address . . . . . . . . . . . . . . . . . . . .  7
       3.3.2   Destination Address  . . . . . . . . . . . . . . . . .  7
       3.3.3   Time-to-Live / Hop Limit . . . . . . . . . . . . . . .  7
       3.3.4   IPv4 Protocol  . . . . . . . . . . . . . . . . . . . .  8
     3.4   Sending Multicast Router Advertisements  . . . . . . . . .  8
     3.5   Receiving Multicast Router Advertisements  . . . . . . . .  8
   4.  Multicast Router Solicitation  . . . . . . . . . . . . . . . .  9
     4.1   Solicitation Packet Format . . . . . . . . . . . . . . . .  9
       4.1.1   Type Field . . . . . . . . . . . . . . . . . . . . . .  9
       4.1.2   Reserved Field . . . . . . . . . . . . . . . . . . . .  9
       4.1.3   Checksum Field . . . . . . . . . . . . . . . . . . . .  9
     4.2   IP Header Fields . . . . . . . . . . . . . . . . . . . . . 10
       4.2.1   Source Address . . . . . . . . . . . . . . . . . . . . 10
       4.2.2   Destination Address  . . . . . . . . . . . . . . . . . 10
       4.2.3   Time-to-Live / Hop Limit . . . . . . . . . . . . . . . 10
       4.2.4   IPv4 Protocol  . . . . . . . . . . . . . . . . . . . . 10
     4.3   Sending Multicast Router Solicitations . . . . . . . . . . 10
     4.4   Receiving Multicast Router Solicitations . . . . . . . . . 10
   5.  Multicast Router Termination . . . . . . . . . . . . . . . . . 11
     5.1   Termination Packet Format  . . . . . . . . . . . . . . . . 11
       5.1.1   Type Field . . . . . . . . . . . . . . . . . . . . . . 11
       5.1.2   Reserved Field . . . . . . . . . . . . . . . . . . . . 11



Haberman & Martin        Expires March 9, 2005                  [Page 2]

Internet-Draft         Multicast Router Discovery         September 2004


       5.1.3   Checksum Field . . . . . . . . . . . . . . . . . . . . 11
     5.2   IP Header Fields . . . . . . . . . . . . . . . . . . . . . 12
       5.2.1   Source Address . . . . . . . . . . . . . . . . . . . . 12
       5.2.2   Destination Address  . . . . . . . . . . . . . . . . . 12
       5.2.3   Time-to-Live / Hop Limit . . . . . . . . . . . . . . . 12
       5.2.4   IPv4 Protocol  . . . . . . . . . . . . . . . . . . . . 12
     5.3   Sending Multicast Router Terminations  . . . . . . . . . . 12
     5.4   Receiving Multicast Router Terminations  . . . . . . . . . 12
   6.  Protocol Constants . . . . . . . . . . . . . . . . . . . . . . 13
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
   10.   References . . . . . . . . . . . . . . . . . . . . . . . . . 14
   10.1  Normative References . . . . . . . . . . . . . . . . . . . . 14
   10.2  Informative References . . . . . . . . . . . . . . . . . . . 15
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15
       Intellectual Property and Copyright Statements . . . . . . . . 17


































Haberman & Martin        Expires March 9, 2005                  [Page 3]

Internet-Draft         Multicast Router Discovery         September 2004


1.  Introduction

   Multicast Router Discovery messages are useful for determining which
   nodes attached to a switch have multicast routing enabled.  This
   capability is useful in a layer-2 bridging domain with snooping
   switches.  By utilizing MRD messages, layer-2 switches can determine
   where to send multicast source data and group membership
   messages[1][2].  Multicast source data and group membership Reports
   must be received by all multicast routers on a segment.  Using the
   group membership protocol Query messages to discover multicast
   routers is insufficient due to query suppression.

   Although MRD messages could be sent as ICMP messages, the group
   management protocols were chosen since this functionality is
   multicast specific.  The addition of this functionality to the group
   membership protocol also allows operators to have congruency between
   multicast router discovery problems and data forwarding issues.

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

2.  Protocol Overview

   Multicast Router Discovery consists of three messages for discovering
   multicast routers.  The Multicast Router Advertisement is sent by
   routers to advertise that IP multicast forwarding is enabled.
   Devices may send Multicast Router Solicitation messages in order to
   solicit Advertisement messages from multicast routers.  The Multicast
   Router Termination messages are sent when a router stops IP multicast
   routing functions on an interface.

   Multicast routers send Advertisements periodically on all interfaces
   on which multicast forwarding is enabled.  Advertisement messages are
   also sent in response to Solicitations.  In addition to advertising
   the location of multicast routers, Advertisements also convey useful
   information concerning group management protocol variables.  This
   information can be used for consistency checking on the subnet.

   A device sends Solicitation messages whenever it wishes to discover
   multicast routers on a directly attached link.

   A router sends Termination messages when it terminates multicast
   routing functionality on an interface.

   All MRD messages are sent with an IPv4 TTL or IPv6 Hop Limit of 1 and
   contain the Router Alert Option[4][5].



Haberman & Martin        Expires March 9, 2005                  [Page 4]

Internet-Draft         Multicast Router Discovery         September 2004


   Advertisement and Termination messages are sent to the All-Snoopers
   multicast address.

   Solicitation messages are sent to the All-Routers multicast address.

   Any data beyond the fixed message format MUST be ignored.

3.  Multicast Router Advertisement

   Multicast Router Advertisements are sent periodically on all router
   interfaces on which multicast forwarding is enabled.  They are also
   sent in response to Multicast Router Solicitation messages.

   Advertisements are sent

   1.  Upon the expiration of a periodic (modulo randomization) timer

   2.  As a part of a router's start up procedure

   3.  During the restart of a multicast forwarding interface

   4.  On receipt of a Solicitation message

   All Advertisements are sent as IGMP (for IPv4) or MLD (for IPv6)
   messages to the All-Snoopers multicast address.  These messages
   SHOULD be rate-limited.

3.1  Advertisement Configuration Variables

   An MRD implementation MUST support the following variables being
   configured by system management.  Default values are specified to
   make it unnecessary to configure any of these variables in many
   cases.

3.1.1  MaxAdertisementInterval

   This variable is the maximum time (in seconds) allowed between the
   transmissions of Advertisements on an interface.  This value MUST be
   no less than 4 seconds and no greater than 180 seconds.

   Default: 20 seconds

3.1.2  MinAdvertisementInterval

   This is the minimum time (in seconds) allowed between the
   transmissions of Advertisements on an interface.  This value MUST be
   no less than 3 seconds and no greater than MaxAdvertisementInterval.




Haberman & Martin        Expires March 9, 2005                  [Page 5]

Internet-Draft         Multicast Router Discovery         September 2004


   Default: 0.75 * MaxAdvertisementInterval

3.1.3  MaxInitialAdvertisementInterval

   The first Advertisement transmitted on an interface is sent after
   waiting a random interval (in seconds) less than this variable.  This
   prevents a flood of Advertisements when multiple routers start up at
   the same time.

   Default: 2 seconds

3.1.4  MaxInitialAdvertisements

   This variable is the maximum number of Advertisements that will be
   transmitted by the advertising interface when MRD starts up.

   Default: 3

3.1.5  NeighborDeadInterval

   This variable is the maximum time (in seconds) allowed to elapse
   before a neighbor can be declared unreachable.  In order for all
   devices to have a consistent state, it is necessary for the
   MaxAdvertisementInterval to be configured consistently in all devices
   on the subnet.

   Default: 3 * MaxAdvertisementInterval

3.2  Advertisement Packet Format

   The Advertisement message has 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      | Ad. Interval  |           Checksum            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        Query Interval         |     Robustness Variable       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


3.2.1  Type Field

   The Type field identifies the message as an Advertisement.  It is set
   to X1 (to be assigned by IANA) for IPv4 and X2 (to be assigned by
   IANA) for IPv6.





Haberman & Martin        Expires March 9, 2005                  [Page 6]

Internet-Draft         Multicast Router Discovery         September 2004


3.2.2  Advertisement Interval Field

   This field specifies the periodic time interval at which
   Advertisement messages are transmitted in units of seconds.  This
   value is set to the configured MaxAdvertisementInterval variable.

3.2.3  Checksum Field

   The checksum field is set as follows:

   1.  For IPv4 it is the 16-bit one's complement of the one's
       complement sum of the IGMP message, starting with the Type field.
       For computing the checksum, the checksum field is set to 0.

   2.  For IPv6 it is ICMPv6 checksum as specified in [6].


3.2.4  Query Interval Field

   The Query Interval field is set to the Query Interval value (in
   seconds) in use by IGMP or MLD on the interface.  If IGMP or MLD is
   not enabled on the advertising interface, this field MUST be set to
   0.  Note that this is the Querier's Query Interval (QQI), not the
   Querier's Query Interval Code (QQIC) as specified in the IGMP/MLD
   specifications.

3.2.5  Robustness Variable Field

   This field is set to the Robustness Variable in use by IGMPv2[2],
   IGMPv3[7], or MLD[8][9] on the advertising interface.  If IGMPv1 is
   in use or no group management protocol is enabled on the interface,
   this field MUST be set to 0.

3.3  IP Header Fields

3.3.1  Source Address

   The IP source address is set to an IP address configured on the
   advertising interface.  For IPv6, a link-local address MUST be used.

3.3.2  Destination Address

   The IP destination address is set to the All-Snoopers multicast
   address.

3.3.3  Time-to-Live / Hop Limit

   The IPv4 TTL and IPv6 Hop Limit are set to 1.



Haberman & Martin        Expires March 9, 2005                  [Page 7]

Internet-Draft         Multicast Router Discovery         September 2004


3.3.4  IPv4 Protocol

   The IPv4 Protocol field is set to IGMP (2).

3.4  Sending Multicast Router Advertisements

   Advertisement messages are sent when the following events occur:

   1.  The expiration of the periodic advertisement interval timer.
       Note that it this timer is not strictly periodic since it is a
       random number between MaxAdvertisementInterval and
       MinAdvertisementInterval.

   2.  After a random delay less than MaxInitialAdvertisementInterval
       when an interface is first enabled, is (re-)initialized, or MRD
       is enabled.  A router may send up to a maximum of
       MaxInitialAdvertisements Advertisements, waiting for a random
       delay less than MaxInitialAdvertisementInterval between each
       successive message.  Multiple Advertisements are sent for
       robustness in the face of packet loss on the network.

   This is to prevent an implosion of Advertisements.  An example of
   this occurring would be when many routers are powered on at the same
   time.  When a Solicitation is received, an Advertisement is sent in
   response with a random delay less than MAX_RESPONSE_DELAY.  If a
   Solicitation is received while an Advertisement is pending, that
   Solicitation MUST be ignored.

   Changes in the Query Interval or Robustness Variable MUST NOT trigger
   a new advertisement, however the new values MUST be used all future
   Advertisement messages.

   When an Advertisement is sent, the periodic advertisement interval
   timer MUST be reset.

3.5  Receiving Multicast Router Advertisements

   Upon receiving an Advertisement message, devices validate the message
   with the following criteria:

   1.  The checksum is correct

   2.  The IP destination address is equal to the All-Snoopers multicast
       address

   3.  For IPv6, the IP source address is a link-local address

   An Advertisement not meeting the validity requirements MUST be



Haberman & Martin        Expires March 9, 2005                  [Page 8]

Internet-Draft         Multicast Router Discovery         September 2004


   silently discarded and may be logged in a rate-limited manner.

   If an Advertisement is not received for a particular neighbor within
   a NeighborDeadInterval time interval, then the neighbor is considered
   unreachable.

4.  Multicast Router Solicitation

   Multicast Router Solicitation messages are used to solicit
   Advertisements from multicast routers on a segment.  These messages
   are used when a device wishes to discover multicast routers.  Upon
   receiving a solicitation on an interface with IP multicast forwarding
   and MRD enabled, a router will respond with an Advertisement.

   Solicitations may be sent when:

   1.  An interface is (re-)initialized

   2.  MRD is enabled

   Solicitations are sent to the All-Routers multicast address and
   SHOULD be rate-limited.

4.1  Solicitation Packet Format

   The Solicitation message has 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      |   Reserved    |           Checksum            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


4.1.1  Type Field

   The Type field identifies the message as a Solicitation.  It is set
   to Y1 (to be assigned by IANA) for IPv4 and Y2 (to be assigned by
   IANA) for IPv6.

4.1.2  Reserved Field

   The Reserved field is set to 0 on transmission and ignored on
   reception.

4.1.3  Checksum Field

   The checksum field is set as follows:



Haberman & Martin        Expires March 9, 2005                  [Page 9]

Internet-Draft         Multicast Router Discovery         September 2004


   o  For IPv4 it is the 16-bit one's complement of the one's complement
      sum of the IGMP message, starting with the Type field.  For
      computing the checksum, the checksum field is set to 0.

   o  For IPv6 it is ICMPv6 checksum as specified in [6].


4.2  IP Header Fields

4.2.1  Source Address

   The IP source address is set to an IP address configured on the
   soliciting interface.  For IPv6, a link-local address MUST be used.

4.2.2  Destination Address

   The IP destination address is set to the All-Routers multicast
   address.

4.2.3  Time-to-Live / Hop Limit

   The IPv4 TTL and IPv6 Hop Limit are set to 1.

4.2.4  IPv4 Protocol

   The IPv4 Protocol field is set to IGMP (2).

4.3  Sending Multicast Router Solicitations

   Solicitation messages are sent when the following events occur:

   o  After waiting for a random delay less than MAX_SOLICITATION_DELAY
      when an interface first becomes operational, is (re-)initialized,
      or MRD is enabled.  A device may send up to a maximum of
      MAX_SOLICITATIONS, waiting for a random delay less than
      MAX_SOLICITATION_DELAY between each solicitation.

   o  Optionally, for an implementation specific event.

   Solicitations MUST be rate-limited; the implementation MUST send no
   more than MAX_SOLICITATIONS in MAX_SOLICITATION_DELAY seconds.

4.4  Receiving Multicast Router Solicitations

   A Solicitation message MUST be validated before a response is sent.
   A router MUST verify that:

   o  The checksum is correct



Haberman & Martin        Expires March 9, 2005                 [Page 10]

Internet-Draft         Multicast Router Discovery         September 2004


   o  The IP destination address is the All-Routers multicast address

   o  For IPv6, the IP source address MUST be a link-local address

   Solicitations not meeting the validity requirements SHOULD be
   silently discarded and may be logged in a rate-limited manner.

5.  Multicast Router Termination

   The Multicast Router Termination message is used to expedite the
   notification of a change in the status of a router's multicast
   forwarding functions.  Multicast routers send Terminations when
   multicast forwarding is disabled on the advertising interface.

5.1  Termination Packet Format

   The Termination message has 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      |   Reserved    |           Checksum            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


5.1.1  Type Field

   The Type field identifies the message as a Termination.  It is set to
   Z1 (to be assigned by IANA) for IPv4 and Z2 (to be assigned by IANA)
   for IPv6.

5.1.2  Reserved Field

   The Reserved field is set to 0 on transmission and ignored on
   reception.

5.1.3  Checksum Field

   The checksum field is set as follows:

   o  For IPv4 it is the 16-bit one's complement of the one's complement
      sum of the IGMP message, starting with the Type field.  For
      computing the checksum, the checksum field is set to 0.

   o  For IPv6 it is ICMPv6 checksum as specified in [6].






Haberman & Martin        Expires March 9, 2005                 [Page 11]

Internet-Draft         Multicast Router Discovery         September 2004


5.2  IP Header Fields

5.2.1  Source Address

   The IP source address is set to an IP address configured on the
   advertising interface.  For IPv6, a link-local address MUST be used.

5.2.2  Destination Address

   The IP destination address is set to the All-Snoopers multicast
   address.

5.2.3  Time-to-Live / Hop Limit

   The IPv4 TTL and IPv6 Hop Limit are set to 1.

5.2.4  IPv4 Protocol

   The IPv4 Protocol field is set to IGMP (2).

5.3  Sending Multicast Router Terminations

   Termination messages are sent by multicast routers when:

   o  Multicast forwarding is disabled on an interface

   o  An interface is administratively disabled

   o  The router is gracefully shutdown

   o  MRD is disabled


5.4  Receiving Multicast Router Terminations

   Upon receiving a Termination message, devices validate the message.
   The validation criteria is:

   o  Checksum MUST be correct

   o  IP destination address MUST equal the All-Snoopers multicast
      address

   o  For IPv6, the IP source address MUST be a link-local address

   Termination messages not meeting the validity requirements MUST be
   silently discarded and may be logged in a rate-limited manner.




Haberman & Martin        Expires March 9, 2005                 [Page 12]

Internet-Draft         Multicast Router Discovery         September 2004


   If the message passes these validation steps, a Solicitation is sent.
   If an Advertisement is not received within NeighborDeadInterval, the
   sending router is removed from the list of active multicast routers.

6.  Protocol Constants

   The following list identifies constants used in the MRD protocol.
   These constants are used in the calculation of parameters.

   o  MAX_RESPONSE_DELAY          2 seconds

   o  MAX_SOLICITATION_DELAY      1 second

   o  MAX_SOLICITATIONS           3 transmissions


7.  Security Considerations

   The Multicast Router Advertisement message may allow rogue machines
   to masquerade as multicast routers.  This could allow those machines
   to eavesdrop on multicast data transmissions.  Additionally, it could
   constitute a denial of service attack to other hosts in the same
   snooping domain or sharing the same device port in the presence of
   high rate multicast flows.

   This issue stems from the fact that there is currently no mechanism
   for hosts to authenticate and authorize messages being sent from
   local routers (e.g.  source addresses are not checked).  This problem
   is shared by all IGMP and ICMPv6 messages, as well as other protocols
   such as IPv6 Neighbor Discovery.

   While solving this problem is beyond the scope of this document, it
   is worth noting that work in the Secure Neighbor Discovery Working
   Group may be applicable to Multicast Router Discovery.  Should this
   work prove successful, appropriate mechanisms may be incorporated
   into a later extension to MRD.

8.  IANA Considerations

   This document introduces three new IGMP messages.  Each of these
   messages requires a new IGMP Type value.  This document requests IANA
   to assign three new IGMP Type values to the Multicast Router
   Discovery Protocol:

     +-----------+---------------+--------------------------------+
     | IGMP Type |    Section    |          Message Name          |
     +-----------+---------------+--------------------------------+
     |     X1    | Section 3.2.1 | Multicast Router Advertisement |



Haberman & Martin        Expires March 9, 2005                 [Page 13]

Internet-Draft         Multicast Router Discovery         September 2004


     |     Y1    | Section 4.1.1 |  Multicast Router Solicitation |
     |     Z1    | Section 5.1.1 |  Multicast Router Termination  |
     +-----------+---------------+--------------------------------+

   This document also introduces three new MLD messages.  Each of these
   messages requires a new ICMPv6 Type value.  This document requests
   IANA to assign three new ICMPv6 Type values from the Informational
   range:

    +-------------+---------------+--------------------------------+
    | ICMPv6 Type |    Section    |          Message Name          |
    +-------------+---------------+--------------------------------+
    |      X2     | Section 3.2.1 | Multicast Router Advertisement |
    |      Y2     | Section 4.1.1 |  Multicast Router Solicitation |
    |      Z2     | Section 5.1.1 |  Multicast Router Termination  |
    +-------------+---------------+--------------------------------+

   This document also requires the assignment of an All-Snoopers
   multicast address for IPv4.  This multicast address should be in the
   224.0.0/24 range since it is used for link-local, control messages.
   A corresponding IPv6 multicast address is also requested.  Following
   the guidelines in [10], the IPv6 multicast address should be
   link-local in scope and have a group-ID value equal to the low order
   8 bits of the requested IPv4 multicast address.

9.  Acknowledgements

   ICMP Router Discovery [11] was used as a general model for Multicast
   Router Discovery.

   Morten Christensen, Pekka Savola, Hugh Holbrook, and Isidor Kouvelas
   provided helpful feedback on various versions of this document.

10.  References

10.1  Normative References

   [1]   Deering, S., "Host extensions for IP multicasting", STD 5, RFC
         1112, August 1989.

   [2]   Fenner, W., "Internet Group Management Protocol, Version 2",
         RFC 2236, November 1997.

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

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




Haberman & Martin        Expires March 9, 2005                 [Page 14]

Internet-Draft         Multicast Router Discovery         September 2004


   [5]   Partridge, C. and A. Jackson, "IPv6 Router Alert Option", RFC
         2711, October 1999.

   [6]   Conta, A. and S. Deering, "Internet Control Message Protocol
         (ICMPv6) for the Internet Protocol Version 6 (IPv6)
         Specification", RFC 2463, December 1998.

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

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

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

   [10]  Haberman, B., "Allocation Guidelines for IPv6 Multicast
         Addresses", RFC 3307, August 2002.

10.2  Informative References

   [11]  Deering, S., "ICMP Router Discovery Messages", RFC 1256,
         September 1991.

   [12]  Bradner, S., "Intellectual Property Rights in IETF Technology",
         BCP 79, RFC 3668, February 2004.

   [13]  Daigle, L. and Internet Architecture Board, "IETF ISOC Board of
         Trustee Appointment Procedures", BCP 77, RFC 3677, December
         2003.


Authors' Addresses

   Brian Haberman
   Johns Hopkins University Applied Physics Lab
   11100 Johns Hopkins Road
   Laurel, MD  20723-6099
   US

   Phone: +1 443 778 1319
   EMail: brian@innovationslab.net








Haberman & Martin        Expires March 9, 2005                 [Page 15]

Internet-Draft         Multicast Router Discovery         September 2004


   Jim Martin
   Netzwert AG
   An den Treptowers 1
   D-12435 Berlin
   Germany

   Phone: +49.30/5 900 800-180
   EMail: jim@netzwert.ag











































Haberman & Martin        Expires March 9, 2005                 [Page 16]

Internet-Draft         Multicast Router Discovery         September 2004


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM 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.


Copyright Statement

   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Haberman & Martin        Expires March 9, 2005                 [Page 17]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/