< draft-ietf-magma-mrdisc-02.txt   draft-ietf-magma-mrdisc-03.txt >
MAGMA WG B. Haberman MAGMA WG B. Haberman
Internet-Draft JHU APL Internet-Draft JHU APL
Expires: March 9, 2005 J. Martin Expires: March 2, 2005 J. Martin
Netzwert AG Netzwert AG
September 8, 2004 September 2004
Multicast Router Discovery Multicast Router Discovery
draft-ietf-magma-mrdisc-02 draft-ietf-magma-mrdisc-03
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with which he or she become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
skipping to change at page 1, line 37 skipping to change at page 1, line 36
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 9, 2005. This Internet-Draft will expire on March 2, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). Copyright (C) The Internet Society (2004).
Abstract Abstract
The concept of Internet Group Membership Protocol (IGMP) and The concept of Internet Group Membership Protocol (IGMP) and
Multicast Listener Discovery (MLD) snooping requires the ability to Multicast Listener Discovery (MLD) snooping requires the ability to
identify the location of multicast routers. Since snooping is not identify the location of multicast routers. Since snooping is not
skipping to change at page 2, line 32 skipping to change at page 2, line 32
3.1.5 NeighborDeadInterval . . . . . . . . . . . . . . . . . 6 3.1.5 NeighborDeadInterval . . . . . . . . . . . . . . . . . 6
3.2 Advertisement Packet Format . . . . . . . . . . . . . . . 6 3.2 Advertisement Packet Format . . . . . . . . . . . . . . . 6
3.2.1 Type Field . . . . . . . . . . . . . . . . . . . . . . 6 3.2.1 Type Field . . . . . . . . . . . . . . . . . . . . . . 6
3.2.2 Advertisement Interval Field . . . . . . . . . . . . . 7 3.2.2 Advertisement Interval Field . . . . . . . . . . . . . 7
3.2.3 Checksum Field . . . . . . . . . . . . . . . . . . . . 7 3.2.3 Checksum Field . . . . . . . . . . . . . . . . . . . . 7
3.2.4 Query Interval Field . . . . . . . . . . . . . . . . . 7 3.2.4 Query Interval Field . . . . . . . . . . . . . . . . . 7
3.2.5 Robustness Variable Field . . . . . . . . . . . . . . 7 3.2.5 Robustness Variable Field . . . . . . . . . . . . . . 7
3.3 IP Header Fields . . . . . . . . . . . . . . . . . . . . . 7 3.3 IP Header Fields . . . . . . . . . . . . . . . . . . . . . 7
3.3.1 Source Address . . . . . . . . . . . . . . . . . . . . 7 3.3.1 Source Address . . . . . . . . . . . . . . . . . . . . 7
3.3.2 Destination Address . . . . . . . . . . . . . . . . . 7 3.3.2 Destination Address . . . . . . . . . . . . . . . . . 7
3.3.3 Time-to-Live / Hop Limit . . . . . . . . . . . . . . . 7 3.3.3 Time-to-Live / Hop Limit . . . . . . . . . . . . . . . 8
3.3.4 IPv4 Protocol . . . . . . . . . . . . . . . . . . . . 8 3.3.4 IPv4 Protocol . . . . . . . . . . . . . . . . . . . . 8
3.4 Sending Multicast Router Advertisements . . . . . . . . . 8 3.4 Sending Multicast Router Advertisements . . . . . . . . . 8
3.5 Receiving Multicast Router Advertisements . . . . . . . . 8 3.5 Receiving Multicast Router Advertisements . . . . . . . . 8
4. Multicast Router Solicitation . . . . . . . . . . . . . . . . 9 4. Multicast Router Solicitation . . . . . . . . . . . . . . . . 9
4.1 Solicitation Packet Format . . . . . . . . . . . . . . . . 9 4.1 Solicitation Packet Format . . . . . . . . . . . . . . . . 9
4.1.1 Type Field . . . . . . . . . . . . . . . . . . . . . . 9 4.1.1 Type Field . . . . . . . . . . . . . . . . . . . . . . 9
4.1.2 Reserved Field . . . . . . . . . . . . . . . . . . . . 9 4.1.2 Reserved Field . . . . . . . . . . . . . . . . . . . . 9
4.1.3 Checksum Field . . . . . . . . . . . . . . . . . . . . 9 4.1.3 Checksum Field . . . . . . . . . . . . . . . . . . . . 10
4.2 IP Header Fields . . . . . . . . . . . . . . . . . . . . . 10 4.2 IP Header Fields . . . . . . . . . . . . . . . . . . . . . 10
4.2.1 Source Address . . . . . . . . . . . . . . . . . . . . 10 4.2.1 Source Address . . . . . . . . . . . . . . . . . . . . 10
4.2.2 Destination Address . . . . . . . . . . . . . . . . . 10 4.2.2 Destination Address . . . . . . . . . . . . . . . . . 10
4.2.3 Time-to-Live / Hop Limit . . . . . . . . . . . . . . . 10 4.2.3 Time-to-Live / Hop Limit . . . . . . . . . . . . . . . 10
4.2.4 IPv4 Protocol . . . . . . . . . . . . . . . . . . . . 10 4.2.4 IPv4 Protocol . . . . . . . . . . . . . . . . . . . . 10
4.3 Sending Multicast Router Solicitations . . . . . . . . . . 10 4.3 Sending Multicast Router Solicitations . . . . . . . . . . 10
4.4 Receiving Multicast Router Solicitations . . . . . . . . . 10 4.4 Receiving Multicast Router Solicitations . . . . . . . . . 11
5. Multicast Router Termination . . . . . . . . . . . . . . . . . 11 5. Multicast Router Termination . . . . . . . . . . . . . . . . . 11
5.1 Termination Packet Format . . . . . . . . . . . . . . . . 11 5.1 Termination Packet Format . . . . . . . . . . . . . . . . 11
5.1.1 Type Field . . . . . . . . . . . . . . . . . . . . . . 11 5.1.1 Type Field . . . . . . . . . . . . . . . . . . . . . . 11
5.1.2 Reserved Field . . . . . . . . . . . . . . . . . . . . 11 5.1.2 Reserved Field . . . . . . . . . . . . . . . . . . . . 11
5.1.3 Checksum Field . . . . . . . . . . . . . . . . . . . . 11 5.1.3 Checksum Field . . . . . . . . . . . . . . . . . . . . 11
5.2 IP Header Fields . . . . . . . . . . . . . . . . . . . . . 12 5.2 IP Header Fields . . . . . . . . . . . . . . . . . . . . . 12
5.2.1 Source Address . . . . . . . . . . . . . . . . . . . . 12 5.2.1 Source Address . . . . . . . . . . . . . . . . . . . . 12
5.2.2 Destination Address . . . . . . . . . . . . . . . . . 12 5.2.2 Destination Address . . . . . . . . . . . . . . . . . 12
5.2.3 Time-to-Live / Hop Limit . . . . . . . . . . . . . . . 12 5.2.3 Time-to-Live / Hop Limit . . . . . . . . . . . . . . . 12
5.2.4 IPv4 Protocol . . . . . . . . . . . . . . . . . . . . 12 5.2.4 IPv4 Protocol . . . . . . . . . . . . . . . . . . . . 12
5.3 Sending Multicast Router Terminations . . . . . . . . . . 12 5.3 Sending Multicast Router Terminations . . . . . . . . . . 12
5.4 Receiving Multicast Router Terminations . . . . . . . . . 12 5.4 Receiving Multicast Router Terminations . . . . . . . . . 12
6. Protocol Constants . . . . . . . . . . . . . . . . . . . . . . 13 6. Protocol Constants . . . . . . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 9. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
10.1 Normative References . . . . . . . . . . . . . . . . . . . . 14 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.2 Informative References . . . . . . . . . . . . . . . . . . . 15 11.1 Normative References . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15 11.2 Informative References . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . 17
1. Introduction 1. Introduction
Multicast Router Discovery messages are useful for determining which Multicast Router Discovery messages are useful for determining which
nodes attached to a switch have multicast routing enabled. This nodes attached to a switch have multicast routing enabled. This
capability is useful in a layer-2 bridging domain with snooping capability is useful in a layer-2 bridging domain with snooping
switches. By utilizing MRD messages, layer-2 switches can determine switches. By utilizing MRD messages, layer-2 switches can determine
where to send multicast source data and group membership where to send multicast source data and group membership
messages[1][2]. Multicast source data and group membership Reports messages[1][2]. Multicast source data and group membership Reports
skipping to change at page 4, line 52 skipping to change at page 4, line 52
information concerning group management protocol variables. This information concerning group management protocol variables. This
information can be used for consistency checking on the subnet. information can be used for consistency checking on the subnet.
A device sends Solicitation messages whenever it wishes to discover A device sends Solicitation messages whenever it wishes to discover
multicast routers on a directly attached link. multicast routers on a directly attached link.
A router sends Termination messages when it terminates multicast A router sends Termination messages when it terminates multicast
routing functionality on an interface. routing functionality on an interface.
All MRD messages are sent with an IPv4 TTL or IPv6 Hop Limit of 1 and All MRD messages are sent with an IPv4 TTL or IPv6 Hop Limit of 1 and
contain the Router Alert Option[4][5]. contain the Router Alert Option[4][5]. All MRD messages SHOULD be
rate-limited.
Advertisement and Termination messages are sent to the All-Snoopers Advertisement and Termination messages are sent to the All-Snoopers
multicast address. multicast address.
Solicitation messages are sent to the All-Routers multicast address. Solicitation messages are sent to the All-Routers multicast address.
Any data beyond the fixed message format MUST be ignored. Any data beyond the fixed message format MUST be ignored.
3. Multicast Router Advertisement 3. Multicast Router Advertisement
skipping to change at page 6, line 25 skipping to change at page 6, line 26
3.1.4 MaxInitialAdvertisements 3.1.4 MaxInitialAdvertisements
This variable is the maximum number of Advertisements that will be This variable is the maximum number of Advertisements that will be
transmitted by the advertising interface when MRD starts up. transmitted by the advertising interface when MRD starts up.
Default: 3 Default: 3
3.1.5 NeighborDeadInterval 3.1.5 NeighborDeadInterval
This variable is the maximum time (in seconds) allowed to elapse The NeighborDeadInterval variable is the maximum time (in seconds)
before a neighbor can be declared unreachable. In order for all allowed to elapse (after receipt of the last valid Advertisement)
devices to have a consistent state, it is necessary for the before a neighboring router is declared unreachable. This variable
MaxAdvertisementInterval to be configured consistently in all devices is maintained per neighbor. In order for all devices to have a
on the subnet. consistent state, it is necessary for the MaxAdvertisementInterval to
be configured consistently in all devices on the subnet.
Default: 3 * MaxAdvertisementInterval Default: 3 * MaxAdvertisementInterval
3.2 Advertisement Packet Format 3.2 Advertisement Packet Format
The Advertisement message has the following format: The Advertisement message has the following format:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 12, line 37 skipping to change at page 12, line 41
Termination messages are sent by multicast routers when: Termination messages are sent by multicast routers when:
o Multicast forwarding is disabled on an interface o Multicast forwarding is disabled on an interface
o An interface is administratively disabled o An interface is administratively disabled
o The router is gracefully shutdown o The router is gracefully shutdown
o MRD is disabled o MRD is disabled
The sending of Termination messages SHOULD be rate-limited.
5.4 Receiving Multicast Router Terminations 5.4 Receiving Multicast Router Terminations
Upon receiving a Termination message, devices validate the message. Upon receiving a Termination message, devices validate the message.
The validation criteria is: The validation criteria is:
o Checksum MUST be correct o Checksum MUST be correct
o IP destination address MUST equal the All-Snoopers multicast o IP destination address MUST equal the All-Snoopers multicast
address address
skipping to change at page 13, line 22 skipping to change at page 13, line 28
These constants are used in the calculation of parameters. These constants are used in the calculation of parameters.
o MAX_RESPONSE_DELAY 2 seconds o MAX_RESPONSE_DELAY 2 seconds
o MAX_SOLICITATION_DELAY 1 second o MAX_SOLICITATION_DELAY 1 second
o MAX_SOLICITATIONS 3 transmissions o MAX_SOLICITATIONS 3 transmissions
7. Security Considerations 7. Security Considerations
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 The Multicast Router Advertisement message may allow rogue machines
to masquerade as multicast routers. This could allow those machines to masquerade as multicast routers. This could allow those machines
to eavesdrop on multicast data transmissions. Additionally, it could to eavesdrop on multicast data transmissions. Additionally, it could
constitute a denial of service attack to other hosts in the same constitute a denial of service attack to other hosts in the same
snooping domain or sharing the same device port in the presence of snooping domain or sharing the same device port in the presence of
high rate multicast flows. high rate multicast flows.
This issue stems from the fact that there is currently no mechanism The technology available in SEND[10] can be utilized to address
for hosts to authenticate and authorize messages being sent from spoofed Advertisement messages in IPv6 networks. IPv6 Multicast
local routers (e.g. source addresses are not checked). This problem routers in an MRD-enabled network can use SEND-based link-local
is shared by all IGMP and ICMPv6 messages, as well as other protocols addresses as the IPv6 source address for MRD messages. When a switch
such as IPv6 Neighbor Discovery. 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.
While solving this problem is beyond the scope of this document, it Another solution which supports both IPv4 and IPv6 is to use IPSec in
is worth noting that work in the Secure Neighbor Discovery Working Authentication Header mode[11] to protect against attacks by ensuring
Group may be applicable to Multicast Router Discovery. Should this that messages came from a system with the proper key. When using
work prove successful, appropriate mechanisms may be incorporated IPSEC, the messages sent to the All-Snoopers address should be
into a later extension to MRD. authenticated using AH. For keying, a symmetric signature algorithm
with a single key 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.
8. IANA Considerations 8. IANA Considerations
This document introduces three new IGMP messages. Each of these This document introduces three new IGMP messages. Each of these
messages requires a new IGMP Type value. This document requests IANA messages requires a new IGMP Type value. This document requests IANA
to assign three new IGMP Type values to the Multicast Router to assign three new IGMP Type values to the Multicast Router
Discovery Protocol: Discovery Protocol:
+-----------+---------------+--------------------------------+ +-----------+---------------+--------------------------------+
| IGMP Type | Section | Message Name | | IGMP Type | Section | Message Name |
skipping to change at page 14, line 25 skipping to change at page 15, line 6
+-------------+---------------+--------------------------------+ +-------------+---------------+--------------------------------+
| X2 | Section 3.2.1 | Multicast Router Advertisement | | X2 | Section 3.2.1 | Multicast Router Advertisement |
| Y2 | Section 4.1.1 | Multicast Router Solicitation | | Y2 | Section 4.1.1 | Multicast Router Solicitation |
| Z2 | Section 5.1.1 | Multicast Router Termination | | Z2 | Section 5.1.1 | Multicast Router Termination |
+-------------+---------------+--------------------------------+ +-------------+---------------+--------------------------------+
This document also requires the assignment of an All-Snoopers This document also requires the assignment of an All-Snoopers
multicast address for IPv4. This multicast address should be in the multicast address for IPv4. This multicast address should be in the
224.0.0/24 range since it is used for link-local, control messages. 224.0.0/24 range since it is used for link-local, control messages.
A corresponding IPv6 multicast address is also requested. Following A corresponding IPv6 multicast address is also requested. Following
the guidelines in [10], the IPv6 multicast address should be the guidelines in [12], the IPv6 multicast address should be
link-local in scope and have a group-ID value equal to the low order link-local in scope and have a group-ID value equal to the low order
8 bits of the requested IPv4 multicast address. 8 bits of the requested IPv4 multicast address.
9. Acknowledgements 9. Authors
ICMP Router Discovery [11] was used as a general model for Multicast Brad Cain and Shantam Biswis are the authors of the original
Multicast Router Discovery proposal.
10. Acknowledgements
ICMP Router Discovery [13] was used as a general model for Multicast
Router Discovery. Router Discovery.
Morten Christensen, Pekka Savola, Hugh Holbrook, and Isidor Kouvelas Morten Christensen, Pekka Savola, Hugh Holbrook, and Isidor Kouvelas
provided helpful feedback on various versions of this document. provided helpful feedback on various versions of this document.
10. References 11. References
10.1 Normative References 11.1 Normative References
[1] Deering, S., "Host extensions for IP multicasting", STD 5, RFC [1] Deering, S., "Host extensions for IP multicasting", STD 5, RFC
1112, August 1989. 1112, August 1989.
[2] Fenner, W., "Internet Group Management Protocol, Version 2", [2] Fenner, W., "Internet Group Management Protocol, Version 2",
RFC 2236, November 1997. RFC 2236, November 1997.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
skipping to change at page 15, line 22 skipping to change at page 16, line 8
[7] Cain, B., Deering, S., Kouvelas, I., Fenner, B. and A. [7] Cain, B., Deering, S., Kouvelas, I., Fenner, B. and A.
Thyagarajan, "Internet Group Management Protocol, Version 3", Thyagarajan, "Internet Group Management Protocol, Version 3",
RFC 3376, October 2002. RFC 3376, October 2002.
[8] Deering, S., Fenner, W. and B. Haberman, "Multicast Listener [8] Deering, S., Fenner, W. and B. Haberman, "Multicast Listener
Discovery (MLD) for IPv6", RFC 2710, October 1999. Discovery (MLD) for IPv6", RFC 2710, October 1999.
[9] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 [9] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2
(MLDv2) for IPv6", RFC 3810, June 2004. (MLDv2) for IPv6", RFC 3810, June 2004.
[10] Haberman, B., "Allocation Guidelines for IPv6 Multicast [10] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P. Nikander,
"SEcure Neighbor Discovery (SEND)", draft-ietf-send-ndopt-06
(work in progress), July 2004.
[11] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402,
November 1998.
[12] Haberman, B., "Allocation Guidelines for IPv6 Multicast
Addresses", RFC 3307, August 2002. Addresses", RFC 3307, August 2002.
10.2 Informative References 11.2 Informative References
[11] Deering, S., "ICMP Router Discovery Messages", RFC 1256, [13] Deering, S., "ICMP Router Discovery Messages", RFC 1256,
September 1991. September 1991.
[12] Bradner, S., "Intellectual Property Rights in IETF Technology", [14] Bradner, S., "Intellectual Property Rights in IETF Technology",
BCP 79, RFC 3668, February 2004. BCP 79, RFC 3668, February 2004.
[13] Daigle, L. and Internet Architecture Board, "IETF ISOC Board of [15] Daigle, L. and Internet Architecture Board, "IETF ISOC Board of
Trustee Appointment Procedures", BCP 77, RFC 3677, December Trustee Appointment Procedures", BCP 77, RFC 3677, December
2003. 2003.
Authors' Addresses Authors' Addresses
Brian Haberman Brian Haberman
Johns Hopkins University Applied Physics Lab Johns Hopkins University Applied Physics Lab
11100 Johns Hopkins Road 11100 Johns Hopkins Road
Laurel, MD 20723-6099 Laurel, MD 20723-6099
US US
 End of changes. 25 change blocks. 
40 lines changed or deleted 78 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/