RFC 4286

Multicast Router Discovery

📅 published December 2005, from ietf

Multicast Router Discovery 💖

Okay bestie, this is RFC 4286, called Multicast Router Discovery 🦋. It came out of the Network Working Group in December 2005, written by B. Haberman (JHU APL) and J. Martin (Netzwert AG). It's a Standards Track document, so it's a real spec people actually implement. The title block doesn't list anything it obsoletes or updates 🫶

Status of This Memo 📜

This doc specifies an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 💬 For the current standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1) ✨ And the distribution of this memo is unlimited, so share it wherever 🌈

Copyright (C) The Internet Society (2005).

Abstract 🌸

Okay so, IGMP and MLD snooping need to know where the multicast routers are. That's the whole idea behind the Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) snooping 🧚 Snooping isn't standardized, so there are tons of different ways people find multicast routers, and that can cause interoperability drama between multicast routers and snooping switches from different vendors 💀

This doc introduces a general mechanism for discovering multicast routers. It's called Multicast Router Discovery (MRD), and it gives us a standardized way to identify multicast routers without depending on any particular multicast routing protocol 👑

Table of Contents 🍓

   1. Introduction ....................................................3
   2. Protocol Overview ...............................................3
   3. Multicast Router Advertisement ..................................4
      3.1. Advertisement Configuration Variables ......................4
           3.1.1. AdvertisementInterval ...............................5
           3.1.2. AdvertisementJitter .................................5
           3.1.3. MaxInitialAdvertisementInterval .....................5
           3.1.4. MaxInitialAdvertisements ............................5
           3.1.5. NeighborDeadInterval ................................5
           3.1.6. MaxMessageRate ......................................6
      3.2. Advertisement Packet Format ................................6
           3.2.1. Type Field ..........................................6
           3.2.2. Advertisement Interval Field ........................6
           3.2.3. Checksum Field ......................................6
           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 .......................................7
           3.3.5. IPv6 Next Header ....................................7
      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.2.5. IPv6 Next Header ...................................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
           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.2.5. IPv6 Next Header ...................................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 ............................................14
   9. Acknowledgements ...............................................15
   10. References ....................................................15
      10.1. Normative References .....................................15
      10.2. Informative Reference ....................................16

1. Introduction ✨

MRD messages are super useful for figuring out which nodes attached to a switch have multicast routing enabled 💅 This is especially handy in a layer-2 bridging domain with snooping switches. By using MRD messages, layer-2 switches can work out 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 because of query suppression 🙈

Although MRD messages could be sent as ICMP messages, the group management protocols were chosen since this functionality is multicast specific 🌈 Adding this to the group membership protocol also gives operators congruence between MRD problems and data forwarding issues, which is so iconic for debugging 🔥

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

2. Protocol Overview 🎀

Multicast Router Discovery is made of three messages for discovering multicast routers 🦋 First up, the Multicast Router Advertisement is sent by routers to advertise that IP multicast forwarding is enabled. Devices may send Multicast Router Solicitation messages to solicit Advertisement messages from multicast routers. And the Multicast Router Termination messages are sent when a router stops IP multicast routing functions on an interface 💜

Multicast routers send unsolicited Advertisements periodically on all interfaces where multicast forwarding is enabled. Advertisement messages are also sent in response to Solicitations. Besides advertising where the multicast routers are, Advertisements also convey useful info about group management protocol variables. This info 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 Time to Live (TTL) or IPv6 Hop Limit of 1 and contain the Router Alert Option [4] [5]. All MRD messages SHOULD be rate-limited as per the MaxMessageRate variable ⭐

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. No extra data gets read, bestie, no exceptions 💀

3. Multicast Router Advertisement 🦋

Multicast Router Advertisements are sent unsolicited periodically on all router interfaces where multicast forwarding is enabled. They're also sent in response to Multicast Router Solicitation messages 🌸

Advertisements are sent:

  1. Upon the expiration of a periodic (modulo randomization) timer
  2. As 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 Internet Group Management Protocol (for IPv4) or Multicast Listener Discovery (for IPv6) messages to the All-Snoopers multicast address. These messages SHOULD be rate-limited as per the MaxMessageRate variable 🔥

3.1. Advertisement Configuration Variables 💅

An MRD implementation MUST support the following variables being configured by system management. Default values are specified so you don't have to configure any of these variables in many cases, which is honestly such a mood 🫶

3.1.1. AdvertisementInterval

This variable is the base interval (in integer seconds) between the transmissions of unsolicited 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. AdvertisementJitter

This is the maximum time (in seconds) by which the AdvertisementInterval is perturbed for each unsolicited Advertisement. Note that the purpose of this jitter is to avoid synchronization of multiple routers on a network, so choosing a value of zero is discouraged 🙃 This value MUST be an integer no less than 0 seconds and no greater than AdvertisementInterval.

The AdvertisementJitter MUST be 0.025*AdvertisementInterval ✨

3.1.3. MaxInitialAdvertisementInterval

The first unsolicited 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 unsolicited Advertisements that will be transmitted by the advertising interface when MRD starts up 🚀

Default: 3

3.1.5. NeighborDeadInterval

The NeighborDeadInterval variable is the maximum time (in seconds) allowed to elapse (after receipt of the last valid Advertisement) before a neighboring router is declared unreachable. This variable is maintained per neighbor. An MRD receiver should set the NeighborDeadInterval to 3 times the sum of the Advertisement Interval Field received plus the AdvertisementJitter calculated from the received Advertisement Interval Field. This keeps behavior consistent between multiple devices on a network, which is giving teamwork 🤝

Default: 3 * (Advertisement Interval Field + calculated AdvertisementJitter)

3.1.6. MaxMessageRate

The MaxMessageRate variable is the maximum aggregate number of messages an MRD implementation SHOULD send (per second) per interface or per management or logging destination 💜

Default: 10

Okay so the Advertisement packet format is where it gets really packet-y, and I am so ready for it 🧚✨ Next up is Section 3.2 🦋

3.2. Advertisement Packet Format ✨

okay bestie, here's what an Advertisement message looks like 💅 the header is only a few fields, so it's super easy to read 🫶

    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 tells you the message is an Advertisement 🦋 it's set to 0x30 for IPv4 and 151 for IPv6. two different numbers, same vibe 💜

3.2.2. Advertisement Interval Field

this field says how often unsolicited Advertisement messages go out, measured in seconds ⏰ its value is set to the configured AdvertisementInterval. simple and iconic 👑

3.2.3. Checksum Field

the Checksum field gets set like this 🧮

  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) that IGMP or MLD is using on the interface 🌸 if IGMP or MLD isn't enabled on the advertising interface, this field MUST be set to 0. also, this is the Querier's Query Interval (QQI), NOT the Querier's Query Interval Code (QQIC) from the IGMP/MLD specs. don't mix those up, bestie 🙈

3.2.5. Robustness Variable Field

this field gets the Robustness Variable that's 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 the IPv6 Hop Limit are both set to 1 🦋

3.3.4. IPv4 Protocol

the IPv4 Protocol field is set to IGMP (2) 💖

3.3.5. IPv6 Next Header

the ICMPv6 header is identified by a Next Header value of 58 in the immediately preceding header [6] 🌈

3.4. Sending Multicast Router Advertisements ✨

Advertisement messages get sent when these events happen 💌

  1. The expiration of the periodic advertisement interval timer. Note that this timer is not strictly periodic, since the base AdvertisementInterval is varied at each interval by a random value no more than plus or minus AdvertisementJitter seconds. 🎲
  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 🛡️

the reason for all this is to stop an implosion of Advertisements 💥 the classic example is when a bunch of routers get powered on at the same time. when a Solicitation comes in, an Advertisement goes back out in response, after a random delay less than MAX_RESPONSE_DELAY. if a Solicitation arrives while an Advertisement is still 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 in all future Advertisement messages 🫶

when an Advertisement is sent, the periodic advertisement interval timer MUST be reset ⏱️

3.5. Receiving Multicast Router Advertisements 👂

when an Advertisement message comes in, devices check it against these 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 that doesn't meet the validity requirements MUST be silently discarded. it may be logged, in a rate-limited manner as per the MaxMessageRate variable 📝

if an Advertisement isn't received for a particular neighbor within a NeighborDeadInterval time interval, then that neighbor is considered unreachable 💀

4. Multicast Router Solicitation 🔎

Multicast Router Solicitation messages are how a device asks multicast routers on a segment to send Advertisements 🙋‍♀️ these messages get used when a device wants to discover multicast routers. when a router gets a solicitation on an interface that has IP multicast forwarding and MRD enabled, it responds with an Advertisement 🎉

Solicitations may be sent when these things happen:

  1. An interface is (re-)initialized
  2. MRD is enabled

Solicitations go to the All-Routers multicast address and SHOULD be rate-limited, as per the MaxMessageRate variable 🚦

4.1. Solicitation Packet Format 🧩

the Solicitation message has this 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's set to 0x31 for IPv4 and 152 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 gets set like this 🧮

  • 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 [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 the IPv6 Hop Limit are both set to 1 🦋

4.2.4. IPv4 Protocol

the IPv4 Protocol field is set to IGMP (2) 💜

4.2.5. IPv6 Next Header

the ICMPv6 header is identified by a Next Header value of 58 in the immediately preceding header [6] 🌈

4.3. Sending Multicast Router Solicitations 📤

Solicitation messages get sent when these events happen 💅

  • 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 as per the MaxMessageRate variable. 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 the following:

  • 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 that don't meet the validity requirements SHOULD be silently discarded. they may be logged in a rate-limited manner as per the MaxMessageRate variable 📝

5. Multicast Router Termination 👋

the Multicast Router Termination message is used to speed up notifying everyone when a router's multicast forwarding functions change status ⚡ multicast routers send Terminations when multicast forwarding is disabled on the advertising interface 🙃

5.1. Termination Packet Format 🧾

the Termination message has this 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's set to 0x32 for IPv4 and 153 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 gets set like this 🧮

  • 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 [6].

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 the IPv6 Hop Limit are both set to 1 🦋

5.2.4. IPv4 Protocol

the IPv4 Protocol field is set to IGMP (2) 💜

5.2.5. IPv6 Next Header

the ICMPv6 header is identified by a Next Header value of 58 in the immediately preceding header [6] 🌈

5.3. Sending Multicast Router Terminations 📤

Termination messages get sent by multicast routers when

  • Multicast forwarding is disabled on an interface
  • An interface is administratively disabled
  • The router is gracefully shut down
  • MRD is disabled

the sending of Termination messages SHOULD be rate-limited as per the MaxMessageRate variable 🚦

5.4. Receiving Multicast Router Terminations 📥

when a Termination message comes in, devices validate it 🔍 the validation criteria are these:

  • 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 that don't meet the validity requirements MUST be silently discarded. they may be logged in a rate-limited manner as per the MaxMessageRate variable 📝

if the message passes these validation steps, a Solicitation is sent 📨 if an Advertisement isn't received within NeighborDeadInterval, the sending router gets removed from the list of active multicast routers 👋

6. Protocol Constants 🔢

this list has the constants used in the MRD protocol 💜 they get used when calculating parameters.

  • MAX_RESPONSE_DELAY 2 seconds
  • MAX_SOLICITATION_DELAY 1 second
  • MAX_SOLICITATIONS 3 transmissions

7. Security Considerations 🔒✨

okay bestie, this section is SERIOUS but also kind of iconic 💅 MRD is a link-local protocol, which means it's only meant to talk to things on the same network link. So there is literally no situation where an MRD receiver should be getting MRD traffic from somewhere off-network 🙅‍♀️. For IPv6, MRD messages MUST have a valid link-local source address. Anything that shows up without one MUST be discarded 🗑️. For IPv4, it's the same energy: the MRD receiver MUST work out whether the source address is local to the receiving interface, and MUST discard any messages with a non-local source. Figuring out what counts as "local" can come from configuration info or from operational capabilities 🧭.

Rogue nodes might try to mess with a network running MRD by sending spoofed Advertisement, Solicitation, or Termination messages 👀. The good news is that each type of spoofed message can be handled with existing technology, so we're not reinventing the wheel here 🛞.

A rogue node might also try to interrupt multicast service by sending spoofed Termination messages 😤. Remember from Section 5.4 that every Termination message gets validated by sending a Solicitation message. So when a node sends a Solicitation, it forces an active router to transmit an Advertisement 🔁.

Spoofed Solicitation messages don't cause any operational harm 🙌. The one thing they're good for is flooding a multicast router as an attack, and that can be mitigated with the rate-limiting recommendation that applies to all MRD messages 🚦.

The Multicast Router Advertisement message might let rogue machines pretend to be multicast routers 🎭. That could let them eavesdrop on multicast data transmissions 🙈. It could also be a denial of service attack against other hosts in the same snooping domain or sharing the same device port when there are high-rate multicast flows 📉.

SEND [10] has technology that can be used to deal with spoofed Advertisement messages in IPv6 networks 🔐. In an MRD-enabled network, IPv6 Multicast routers can use SEND-based link-local addresses as the IPv6 source address for MRD messages 💜. When a switch gets an initial Advertisement, it can use the info in that SEND-based address to challenge the router to authenticate itself 🫶. Just note that this approach only applies to IPv6 networks, so IPv4 folks, this one isn't for you 🥺.

Another option that works for both IPv4 and IPv6 is using IPsec in Encapsulating Security Payload (ESP) mode [11] 🛡️. It protects against attacks by making sure messages came from a system with the proper key 🗝️. When you're using IPsec, the messages sent to the All-Snoopers address should be authenticated using ESP ✨. If you don't want encryption, ESP with a null encryption algorithm and a symmetric authentication algorithm, such as HMAC-SHA-1, is viable 👍. For keying, a symmetric signature algorithm with a single manually configured key is used for routers sending Advertisements 🔑. That lets you validate that the MRD message was sent by a system holding the key ✅. BUT, and this is a big but 🫠, this does NOT stop a system with the key from forging a message, and it requires disabling IPsec's Replay Protection 💀. And it is the responsibility of the network administrator to make sure the same key is present on all possible MRD participants 👑.

⚠️ Quick reminder: the key-sharing stuff is the network admin's job. If one MRD participant is missing the key, the whole setup gets messy, so double-check everyone has it 🙏.

8. IANA Considerations 📋

this document introduces three new IGMP messages 🎀. Each one of these messages requires a new IGMP Type value. The IANA has assigned three new IGMP Type values to the Multicast Router Discovery Protocol 🥳:

    +-----------+-----------------+--------------------------------+
    | IGMP Type |     Section     |          Message Name          |
    +-----------+-----------------+--------------------------------+
    |   0x30    |  Section 3.2.1  | Multicast Router Advertisement |
    |   0x31    |  Section 4.1.1  | Multicast Router Solicitation  |
    |   0x32    |  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, and the IANA has assigned three new ICMPv6 Type values from the Informational range 🧚:

   +-------------+-----------------+--------------------------------+
   | ICMPv6 Type |     Section     |          Message Name          |
   +-------------+-----------------+--------------------------------+
   |     151     |  Section 3.2.1  | Multicast Router Advertisement |
   |     152     |  Section 4.1.1  | Multicast Router Solicitation  |
   |     153     |  Section 5.1.1  | Multicast Router Termination   |
   +-------------+-----------------+--------------------------------+

this document also requires the assignment of an All-Snoopers multicast address for IPv4 🌈. This multicast address is in the 224.0.0/24 range because it's used for link-local, control messages 🎯. The IPv4 multicast address for All-Snoopers is 224.0.0.106 💖.

A matching IPv6 multicast address has also been assigned 💜. Following the guidelines in [12], the IPv6 multicast address is link-local in scope, and its group-ID value is equal to the low-order 8 bits of the requested IPv4 multicast address ✨. The IPv6 multicast address is FF02:0:0:0:0:0:0:6A 🦋.

9. Acknowledgements 🫶

Brad Cain and Shantam Biswis are the authors of the original Multicast Router Discovery proposal 👑. They're the OGs, literally the start of this whole thing 💅.

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

Morten Christensen, Pekka Savola, Hugh Holbrook, and Isidor Kouvelas gave helpful feedback on various versions of this document 🙏. Thank you, queens 🍓.

10. References 📚

10.1. Normative References

  • [1] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989. 💫
  • [2] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002. 🌷
  • [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. 🚨
  • [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] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. 🔐
  • [11] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998. 🛡️
  • [12] Haberman, B., "Allocation Guidelines for IPv6 Multicast Addresses", RFC 3307, August 2002. 🗺️

10.2. Informative Reference

  • [13] Deering, S., "ICMP Router Discovery Messages", RFC 1256, September 1991. 🧭

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


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

   Phone: +49.30/5 900 80-1180
   EMail: jim@netzwert.ag

Copyright (C) The Internet Society (2005) 🌟.

this document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors keep all their rights 📜.

this document and the information in it 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 🙃.

Intellectual Property 💼

The IETF takes no position on the validity or scope of any Intellectual Property Rights or other rights that might be claimed to apply to the implementation or use of the technology described in this document, or on whether any license under such rights might or might not be available. It also doesn't say it has made any independent effort to find such rights 🕵️‍♀️. Info on the procedures for rights in RFC documents can be found in BCP 78 and BCP 79 📖.

Copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the result of an attempt to get a general license or permission for implementers or users to use these proprietary rights can be found in 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, patent applications, or other proprietary rights that may cover technology required to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org 💌.

Acknowledgement 🎉

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

📦 where this page comes from