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

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

   MAGMA Working Group                                         B. Haberman
   Internet Draft                                         Caspian Networks
   draft-ietf-magma-mrdisc-00.txt                                J. Martin
   February 2004                                               Netzwert AG
   Expires August 2004


                       Multicast Router Discovery


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026 [RFC 2026].

   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.


Abstract

   The concept of IGMP 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 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.











Haberman, Martin                                                     1

Internet Draft        Multicast Router Discovery         February 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 listening to MRD messages, layer-2 switches can
   determine where to send multicast source data and group membership
   messages [RFC1112][RFC2236].  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.


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 [RFC2113][RFC2711].

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

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

Haberman, Martin                                                     2

Internet Draft        Multicast Router Discovery         February 2004



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 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 MaxAdvertisementInterval

   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.

   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

Haberman, Martin                                                     3

Internet Draft        Multicast Router Discovery         February 2004


   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.

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

  3.2.4 Query Interval Field

Haberman, Martin                                                     4

Internet Draft        Multicast Router Discovery         February 2004


   The Query Interval field is set to the Query Interval value 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.

  3.2.5 Robustness Variable Field

   This field is set to the Robustness Variable in use by IGMPv2
   [RFC2236], IGMPv3 [RFC3376], or MLD [RFC2710][MLDV2] 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.

  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:

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

Haberman, Martin                                                     5

Internet Draft        Multicast Router Discovery         February 2004

   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.

   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:

        . The checksum is correct
        . The IP destination address is equal to the All-Snoopers
           multicast address
        . For IPv6, the IP source address is a link-local address

   An Advertisement not meeting the validity requirements MUST be
   silently discarded or 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

Haberman, Martin                                                     6

Internet Draft        Multicast Router Discovery         February 2004


   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:

     . 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.
     . For IPv6 it is ICMPv6 checksum as specified in [RFC2463].

  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:

        . After waiting for a random delay less than
           SOLICITATION_INTERVAL 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 SOLICITATION_INTERVAL
           between each solicitation.
        . Optionally, for an implementation specific event.


Haberman, Martin                                                     7

Internet Draft        Multicast Router Discovery         February 2004


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

  4.4  Receiving Multicast Router Solicitations

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

        . The checksum is correct
        . The IP destination address is the All-Routers multicast
           address
        . For IPv6, the IP source address MUST be a link-local address

   Solicitations not meeting the validity requirements SHOULD be
   silently discarded or 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:

        . For IPv4 it is the 16-bit one's complement of the one's
           complement sum of the IGMP message, starting with the Type


Haberman, Martin                                                     8

Internet Draft        Multicast Router Discovery         February 2004

           field.  For computing the checksum, the checksum field is
           set to 0.
        . For IPv6 it is ICMPv6 checksum as specified in [RFC2463].

  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:

        . Multicast forwarding is disabled on an interface
        . An interface is administratively disabled
        . The router is gracefully shutdown
        . MRD is disabled

  5.4  Receiving Multicast Router Terminations

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

        . Checksum MUST be correct
        . IP destination address MUST equal the All-Snoopers multicast
           address
        . For IPv6, the IP source address MUST be a link-local address

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

   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

Haberman, Martin                                                     9

Internet Draft        Multicast Router Discovery         February 2004


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

     . MAX_RESPONSE_DELAY          2 seconds
     . MAX_SOLICITATION_DELAY      1 second
     . 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.

   Should a Multicast Router Terminate message be spoofed with the
   source address of a valid multicast router, a device may discontinue
   forwarding of multicast source data to that router. This would
   disrupt the reception of this data beyond the local subnet.

   Both of these issues stem from the fact that there is currently no
   mechanism for hosts to authenticate and authorize messages being
   sent from local routers. 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 will be incorporated
   into a later revision of 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 (for IPv4 Advertisements, Solicitations, and
   Terminations).

   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 to the Multicast Router
   Discovery Protocol (for IPv6 Advertisements, Solicitations, and
   Terminations).

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

Haberman, Martin                                                    10

Internet Draft        Multicast Router Discovery         February 2004

   A corresponding IPv6 multicast address is also requested.  Following
   the guidelines in [RFC3307], the IPv6 multicast address should be
   link-local in scope and have a group-ID value equal to the lowest-
   order 8 bits of the requested IPv4 multicast address.

9. Acknowledgements

   ICMP Router Discovery [RFC1256] 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

  10.2 Informative References

11. Authors

   Brad Cain and Shantam Biswas were initial authors on this document.

12. Editors' Addresses

             Brian Haberman                       Jim Martin
            Caspian Networks                     Netzwert AG
         753 Bridgewater Drive                 D-12435 Berlin
         Sykesville, MD  21784

        brian@innovationslab.net               jim@netzwert.ag
            +1-443-280-0932                 +49.30/5 900 800-180

13. Full Copyright Statement

   Copyright (C) The Internet Society (2004). 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

Haberman, Martin                                                    11

Internet Draft        Multicast Router Discovery         February 2004

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













































Haberman, Martin                                                    12


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