[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [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-01.txt                              J. Martin
    July 2004                                                 Netzwert AG
    Expires January 2005


                        Multicast Router Discovery


Status of this Memo

    By submitting this Internet-Draft, I certify that any applicable
    patent or other IPR claims of which I am aware have been disclosed,
    and any of which I 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 January 2005.



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

    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
    [RFC2119].  Due to the lack of italics, emphasis is indicated herein
    by bracketing a word or phrase in "*" characters.  Furthermore,
    square brackets are used to denote the value of the enclosed
    variable, as opposed to the variable itself, written without
    brackets.

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.

Haberman, Martin                                                     2

Internet Draft        Multicast Router Discovery         February 2004


    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.

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


Haberman, Martin                                                     3

Internet Draft        Multicast Router Discovery         February 2004

   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.

   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

Haberman, Martin                                                     4

Internet Draft        Multicast Router Discovery         February 2004


    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

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

         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.

Haberman, Martin                                                     5

Internet Draft        Multicast Router Discovery         February 2004

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

Haberman, Martin                                                     6

Internet Draft        Multicast Router Discovery         February 2004

      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:

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


Haberman, Martin                                                     7

Internet Draft        Multicast Router Discovery         February 2004

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

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


Haberman, Martin                                                     8

Internet Draft        Multicast Router Discovery         February 2004

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

Haberman, Martin                                                     9

Internet Draft        Multicast Router Discovery         February 2004


         . 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 and may be 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

    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.

    This issue stems 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 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 (for IPv4 Advertisements, Solicitations, and
    Terminations).

Haberman, Martin                                                    10

Internet Draft        Multicast Router Discovery         February 2004


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

    [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119, March 1997.
    [RFC1112]   Deering, S., "Host Extensions for IP Multicasting",
                RFC1112, August 1989.
    [RFC2236]   Fenner, W., "Internet Group Management Protocol,
                Version 2", RFC2236, November 1997.
    [RFC2113]   Katz, D., "IP Router Alert Option", RFC2113,
                February 1997.
    [RFC2711]   Partridge, C. and Jackson, A., "IPv6 Router Alert
                Option", RFC2711, October 1999.
    [RFC3376]   Cain, B., Deering, S., Kouvelas, I., et al., "Internet
                Group Management Protocol, Version 3", RFC3376, October
                2002.
    [RFC2710]   Deering, S., Fenner, W., and  Haberman, B., "Multicast
                Listener Discovery (MLD) for IPv6", RFC2710, October
                1999.
    [RFC3810]   Vida, R. and Costa, L., "Multicast Listener Discovery
                Version 2 (MLDv2) for IPv6", RFC3810, December 2003.
    [RFC2463]   Conta, A. and Deering, S., "Internet Control Message
                Protocol (ICMPv6) for the Internet Protocol Version 6
                (IPv6) Specification", RFC2463, December 1998.
    [RFC3307]   Haberman, B., "Allocation Guidelines for IPv6 Multicast
                Addresses", RFC3307, August 2002.

   10.2 Informative References

Haberman, Martin                                                    11

Internet Draft        Multicast Router Discovery         February 2004


    [RFC1256]   Deering, S., "ICMP Router Discovery Messages", September
                1991.
    [BCP78]     Bradner, S., "IETF Rights in Contributions"
                RFC3677, BCP78, February 2004.
    [BCP79]     Bradner, S., "Intellectual Property Rights in IETF
                Technology", RFC3668, BCP79, February 2004.



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               An den Treptowers 1
          Sykesville, MD  21784                 D-12435 Berlin
                   USA                              Germany

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

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

14.    Disclaimer of Validity



Haberman, Martin                                                    12

Internet Draft        Multicast Router Discovery         February 2004

    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.

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

16.    Acknowledgment

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



































Haberman, Martin                                                    13


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