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.