RFC 4286 PROPOSED STANDARD MULTICAST · IGMP · MLD
MRD: Multicast Router Discovery
A standard way for switches that snoop on multicast traffic to find which neighbors are multicast routers.
RFC EDITOR
Haberman, B. and J. Martin, "Multicast Router Discovery", RFC 4286, DOI 10.17487/RFC4286, December 2005, <https://www.rfc-editor.org/info/rfc4286>.
BIBTEX
@misc{rfc4286,
series = {Request for Comments},
number = 4286,
howpublished = {RFC 4286},
publisher = {RFC Editor},
doi = {10.17487/RFC4286},
url = {https://www.rfc-editor.org/info/rfc4286},
author = {B. Haberman and J. Martin},
title = {{Multicast Router Discovery}},
pagetotal = 18,
year = 2005,
month = dec,
} RFC text
Contents
Network Working Group B. Haberman
Request for Comments: 4286 JHU APL
Category: Standards Track J. Martin
Netzwert AG
December 2005
Multicast Router Discovery
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
The concept of Internet Group Management 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.
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
Multicast Router Discovery (MRD) 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 congruence between
MRD problems and data forwarding issues.
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 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 unsolicited 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 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.
3. Multicast Router Advertisement
Multicast Router Advertisements are sent unsolicited 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 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 to
make it unnecessary to configure any of these variables in many
cases.
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, hence 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 Advertisement Interval
Field received plus the AdvertisementJitter calculated from the
received Advertisement Interval Field. This ensures consistent
behavior between multiple devices on a network.
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
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 0x30 for IPv4 and 151 for IPv6.
3.2.2. Advertisement Interval Field
This field specifies the periodic time interval at which unsolicited
Advertisement messages are transmitted in units of seconds. This
value is set to the configured AdvertisementInterval.
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.
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 are sent when the following events occur:
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.
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 in 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 as per
the MaxMessageRate variable.
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 these occur:
1. An interface is (re-)initialized
2. MRD is enabled
Solicitations are sent 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 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 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 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].
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.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 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 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:
o The checksum is correct.
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 as per
the MaxMessageRate variable.
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
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 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].
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.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 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 shut down
o MRD is disabled
The sending of Termination messages SHOULD be rate-limited as per the
MaxMessageRate variable.
5.4. Receiving Multicast Router Terminations
Upon receiving a Termination message, devices validate the message.
The validation criteria are the following:
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 as per
the MaxMessageRate variable.
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
As MRD is a link-local protocol, there is no circumstance in which it
would be correct for an MRD receiver to receive MRD traffic from an
off-network source. For IPv6, MRD messages MUST have a valid link-
local source address. Any messages received without a valid link-
local source address MUST be discarded. Similarly, for IPv4, the MRD
receiver MUST determine if the source address is local to the
receiving interface, and MUST discard any messages that have a non-
local source. Determining what networks are local may be
accomplished through configuration information or operational
capabilities.
Rogue nodes may attempt to attack a network running MRD by sending
spoofed Advertisement, Solicitation, or Termination messages. Each
type of spoofed message can be dealt with using existing technology.
A rogue node may attempt to interrupt multicast service by sending
spoofed Termination messages. As described in Section 5.4, all
Termination messages are validated by sending a Solicitation message.
By sending a Solicitation, the node will force the transmission of an
Advertisement by an active router.
Spoofed Solicitation messages do not cause any operational harm.
They may be used as a flooding mechanism to attack a multicast
router. This attack can be mitigated through the rate-limiting
recommendation for all MRD messages.
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.
The technology available in SEND [10] can be utilized to address
spoofed Advertisement messages in IPv6 networks. IPv6 Multicast
routers in an MRD-enabled network can use SEND-based link-local
addresses as the IPv6 source address for MRD messages. When a switch
receives an initial Advertisement, it can use the information in the
SEND-based address to challenge the router to authenticate itself.
It should be noted that this approach only applies to IPv6 networks.
Another solution that supports both IPv4 and IPv6 is to use IPsec in
Encapsulating Security Payload (ESP) mode [11] to protect against
attacks by ensuring that messages came from a system with the proper
key. When using IPsec, the messages sent to the All-Snoopers address
should be authenticated using ESP. Should encryption not be desired,
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. This allows validation that the MRD
message was sent by a system with the key. It should be noted that
this does not prevent a system with the key from forging a message
and it requires the disabling of IPsec's Replay Protection. It is
the responsibility of the network administrator to ensure that the
same key is present on all possible MRD participants.
8. IANA Considerations
This document introduces three new IGMP messages. Each 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. 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 since it is used for link-local, control messages.
The IPv4 multicast address for All-Snoopers is 224.0.0.106.
A corresponding IPv6 multicast address has also been assigned.
Following the guidelines in [12], the IPv6 multicast address is a
link-local in scope and has a group-ID value 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.
ICMP Router Discovery [13] 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] 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
Full Copyright Statement
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
retain all their rights.
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.
Intellectual Property
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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
AI ELI5
On this page
PROBLEMIGMP and MLD snooping switches must know where multicast routers are, but snooping is not standardized and vendors used different methods, causing interoperability problems.
MECHANISMThree small messages sent over IGMP (IPv4) or MLD (IPv6): Advertisement from routers, Solicitation from devices, and Termination when a router stops forwarding.
WHY IT MATTERSSwitches can track multicast routers without relying on any particular multicast routing protocol; security relies on link-local checks, rate limiting and optionally SEND or IPsec.
§1Why Routers Must Be Discoverable
Multicast Router Discovery (MRD) messages help determine which nodes attached to a switch have multicast routing enabled. This matters in a layer-2 bridging domain with snooping switches, which need to know where to send multicast source data and group membership messages. Source data and membership reports must be received by all multicast routers on a segment.
Using group membership Query messages to find routers is insufficient because of query suppression. MRD could have been built on ICMP, but the group management protocols were chosen because the function is multicast specific, and this lets operators see MRD problems alongside data forwarding problems.
Switches need to know which neighbors pass multicast along. Asking the usual way does not always work, so there is a special hello message for it.
§2Three Messages
MRD has three messages. A multicast router sends an Advertisement to say IP multicast forwarding is enabled. A device may send a Solicitation to ask routers to advertise. A router sends a Termination when it stops multicast routing on an interface.
Advertisements go out periodically on every interface with multicast forwarding enabled, and also in reply to Solicitations. They also carry group management variables, which can be used for consistency checking on the subnet. All MRD messages use an IPv4 TTL or IPv6 Hop Limit of 1 and carry the Router Alert Option (RFC 2113, RFC 2711). Advertisement and Termination go to the All-Snoopers multicast address; Solicitation goes to the All-Routers address. All messages SHOULD be rate-limited per MaxMessageRate, and any data beyond the fixed format MUST be ignored.
There are three notes: "I am a router", "are there any routers?" and "I am quitting being a router". They only travel one hop, to the neighbors.
§3.2Message Formats
The Advertisement has a Type, an Advertisement Interval, a Checksum, a Query Interval and a Robustness Variable. The Type is 0x30 for IPv4 and 151 for IPv6. The Advertisement Interval is the configured AdvertisementInterval in seconds. The Query Interval is the Querier's Query Interval (QQI, not the coded QQIC) in use by IGMP or MLD on the interface, or 0 if neither is enabled. The Robustness Variable comes from IGMPv2, IGMPv3 or MLD on the interface, or is 0 if IGMPv1 or no group protocol is in use.
Solicitation and Termination are shorter: Type, Reserved (set to 0 and ignored on reception) and Checksum. Solicitation uses 0x31 and 152; Termination uses 0x32 and 153. For IPv4 the checksum is the usual one's complement over the IGMP message with the checksum field set to 0; for IPv6 it is the ICMPv6 checksum. The IPv4 Protocol field is IGMP (2), and the IPv6 Next Header is 58. IPv6 source addresses MUST be link-local.
Each note is tiny: a label saying which kind it is, a check number, and for the router's hello a couple of timing facts.
| Field | Name | Size | Value | Description |
|---|---|---|---|---|
TYPE | Type | 1 byte | 0x30 / 151 | 0x30 for IPv4, 151 for IPv6. |
AD-INTERVAL | Ad. Interval | 1 byte | Configured AdvertisementInterval, in seconds. | |
CHECKSUM | Checksum | 2 bytes | IGMP checksum for IPv4, ICMPv6 checksum for IPv6. | |
QUERY-INTERVAL | Query Interval | 2 bytes | IGMP or MLD Query Interval in seconds; 0 if not enabled. | |
ROBUSTNESS | Robustness Variable | 2 bytes | IGMPv2, IGMPv3 or MLD value; 0 if IGMPv1 or none. |
§3.1Timers and Constants
An MRD implementation MUST support configuring these variables. AdvertisementInterval must be between 4 and 180 seconds, default 20. AdvertisementJitter randomizes timing so routers do not synchronize, and zero is discouraged. MaxInitialAdvertisementInterval defaults to 2 seconds and MaxInitialAdvertisements to 3. MaxMessageRate defaults to 10 messages per second.
A receiver sets NeighborDeadInterval to 3 times the sum of the received Advertisement Interval field plus the jitter computed from it; a neighbor with no Advertisement in that time is considered unreachable. Protocol constants are MAX_RESPONSE_DELAY of 2 seconds, MAX_SOLICITATION_DELAY of 1 second and MAX_SOLICITATIONS of 3 transmissions.
Routers say hello about every 20 seconds, a little randomly. If a neighbor goes quiet for about three rounds, it is considered gone.
§3.4Sending and Receiving
Advertisements are sent when the periodic timer fires, and after a short random delay when an interface is enabled, re-initialized or MRD is enabled (up to MaxInitialAdvertisements, for robustness against loss). On a Solicitation, a router replies after a random delay less than MAX_RESPONSE_DELAY, and ignores further Solicitations while one reply is pending. Changes to Query Interval or Robustness Variable MUST NOT trigger a new Advertisement, but the new values MUST be used afterwards.
Receivers validate Advertisements: correct checksum, destination equal to All-Snoopers and, for IPv6, a link-local source. Failures MUST be silently discarded. Solicitations are sent when an interface is initialized or MRD is enabled, to the All-Routers address.
Terminations are sent when forwarding or the interface is disabled, the router shuts down gracefully, or MRD is disabled. A receiver that validates a Termination sends a Solicitation, and removes the sender from its active router list if no Advertisement arrives within NeighborDeadInterval.
Routers announce themselves when they wake up and now and then after. If one announces it is leaving, the others double-check by asking who is still there.
Snooping deviceMulticast router
- SolicitationSent to the All-Routers address.
- AdvertisementSent to All-Snoopers after a random delay below MAX_RESPONSE_DELAY.
- TerminationSent when multicast forwarding stops on the interface.
- SolicitationSent to validate the Termination.
§7Security Considerations
MRD is link-local, so traffic from off-network sources should never be accepted. IPv6 messages MUST have a valid link-local source; IPv4 receivers MUST discard messages with a non-local source.
Spoofed Terminations are handled by validating them with a Solicitation. Spoofed Solicitations can be used for flooding, mitigated by rate limiting. A spoofed Advertisement lets a rogue machine pose as a router and eavesdrop or cause denial of service. The RFC points to SEND (RFC 3971) for IPv6, and to IPsec ESP (RFC 2406) with a null encryption algorithm and a keyed authentication algorithm such as HMAC-SHA-1 for IPv4 and IPv6, which needs a manually configured shared key and requires disabling replay protection.
A fake sign could trick the mail sorter. The defenses are to only trust neighbors on the same hallway and, if needed, to check a secret handshake.
§8Assigned Values
IANA assigned three IGMP types (0x30, 0x31, 0x32) and three ICMPv6 types from the Informational range (151, 152, 153) for Advertisement, Solicitation and Termination. The IPv4 All-Snoopers address is 224.0.0.106, in the 224.0.0/24 link-local control range. The IPv6 address is FF02:0:0:0:0:0:0:6A, link-local in scope, with a group ID equal to the low-order 8 bits of the IPv4 address.
Each note kind and the special shared address got official numbers so every vendor uses the same ones.
- 0x30 / 151Advertisement — IGMP type / ICMPv6 type.
- 0x31 / 152Solicitation — IGMP type / ICMPv6 type.
- 0x32 / 153Termination — IGMP type / ICMPv6 type.
§8References
[1]RFC 1112Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.August 1989[2]RFC 3376Cain, B., et al., "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.October 2002[4]RFC 2113Katz, D., "IP Router Alert Option", RFC 2113, February 1997.February 1997[5]RFC 2711Partridge, C. and A. Jackson, "IPv6 Router Alert Option", RFC 2711, October 1999.October 1999[8]RFC 2710Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.October 1999[9]RFC 3810Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.June 2004[10]RFC 3971Arkko, J., et al., "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.March 2005[13]RFC 1256Deering, S., "ICMP Router Discovery Messages", RFC 1256, September 1991.September 1991