idnits 2.17.1 draft-ietf-magma-mrdisc-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 719. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 696. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 703. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 709. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each 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 becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 8, 2004) is 7170 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '12' is defined on line 661, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 664, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2463 (ref. '6') (Obsoleted by RFC 4443) -- Obsolete informational reference (is this intentional?): RFC 3668 (ref. '12') (Obsoleted by RFC 3979) Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MAGMA WG B. Haberman 2 Internet-Draft JHU APL 3 Expires: March 9, 2005 J. Martin 4 Netzwert AG 5 September 8, 2004 7 Multicast Router Discovery 8 draft-ietf-magma-mrdisc-02 10 Status of this Memo 12 This document is an Internet-Draft and is subject to all provisions 13 of section 3 of RFC 3667. By submitting this Internet-Draft, each 14 author represents that any applicable patent or other IPR claims of 15 which he or she is aware have been or will be disclosed, and any of 16 which he or she become aware will be disclosed, in accordance with 17 RFC 3668. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as 22 Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on March 9, 2005. 37 Copyright Notice 39 Copyright (C) The Internet Society (2004). 41 Abstract 43 The concept of Internet Group Membership Protocol (IGMP) and 44 Multicast Listener Discovery (MLD) snooping requires the ability to 45 identify the location of multicast routers. Since snooping is not 46 standardized, there are many mechanisms in use to identify the 47 multicast routers. However, this can lead to interoperability issues 48 between multicast routers and snooping switches from different 49 vendors. 51 This document introduces a general mechanism that allows for the 52 discovery of multicast routers. This new mechanism, Multicast Router 53 Discovery (MRD), introduces a standardized means of identifying 54 multicast routers without a dependency on particular multicast 55 routing protocols. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Multicast Router Advertisement . . . . . . . . . . . . . . . . 5 62 3.1 Advertisement Configuration Variables . . . . . . . . . . 5 63 3.1.1 MaxAdertisementInterval . . . . . . . . . . . . . . . 5 64 3.1.2 MinAdvertisementInterval . . . . . . . . . . . . . . . 5 65 3.1.3 MaxInitialAdvertisementInterval . . . . . . . . . . . 6 66 3.1.4 MaxInitialAdvertisements . . . . . . . . . . . . . . . 6 67 3.1.5 NeighborDeadInterval . . . . . . . . . . . . . . . . . 6 68 3.2 Advertisement Packet Format . . . . . . . . . . . . . . . 6 69 3.2.1 Type Field . . . . . . . . . . . . . . . . . . . . . . 6 70 3.2.2 Advertisement Interval Field . . . . . . . . . . . . . 7 71 3.2.3 Checksum Field . . . . . . . . . . . . . . . . . . . . 7 72 3.2.4 Query Interval Field . . . . . . . . . . . . . . . . . 7 73 3.2.5 Robustness Variable Field . . . . . . . . . . . . . . 7 74 3.3 IP Header Fields . . . . . . . . . . . . . . . . . . . . . 7 75 3.3.1 Source Address . . . . . . . . . . . . . . . . . . . . 7 76 3.3.2 Destination Address . . . . . . . . . . . . . . . . . 7 77 3.3.3 Time-to-Live / Hop Limit . . . . . . . . . . . . . . . 7 78 3.3.4 IPv4 Protocol . . . . . . . . . . . . . . . . . . . . 8 79 3.4 Sending Multicast Router Advertisements . . . . . . . . . 8 80 3.5 Receiving Multicast Router Advertisements . . . . . . . . 8 81 4. Multicast Router Solicitation . . . . . . . . . . . . . . . . 9 82 4.1 Solicitation Packet Format . . . . . . . . . . . . . . . . 9 83 4.1.1 Type Field . . . . . . . . . . . . . . . . . . . . . . 9 84 4.1.2 Reserved Field . . . . . . . . . . . . . . . . . . . . 9 85 4.1.3 Checksum Field . . . . . . . . . . . . . . . . . . . . 9 86 4.2 IP Header Fields . . . . . . . . . . . . . . . . . . . . . 10 87 4.2.1 Source Address . . . . . . . . . . . . . . . . . . . . 10 88 4.2.2 Destination Address . . . . . . . . . . . . . . . . . 10 89 4.2.3 Time-to-Live / Hop Limit . . . . . . . . . . . . . . . 10 90 4.2.4 IPv4 Protocol . . . . . . . . . . . . . . . . . . . . 10 91 4.3 Sending Multicast Router Solicitations . . . . . . . . . . 10 92 4.4 Receiving Multicast Router Solicitations . . . . . . . . . 10 93 5. Multicast Router Termination . . . . . . . . . . . . . . . . . 11 94 5.1 Termination Packet Format . . . . . . . . . . . . . . . . 11 95 5.1.1 Type Field . . . . . . . . . . . . . . . . . . . . . . 11 96 5.1.2 Reserved Field . . . . . . . . . . . . . . . . . . . . 11 97 5.1.3 Checksum Field . . . . . . . . . . . . . . . . . . . . 11 98 5.2 IP Header Fields . . . . . . . . . . . . . . . . . . . . . 12 99 5.2.1 Source Address . . . . . . . . . . . . . . . . . . . . 12 100 5.2.2 Destination Address . . . . . . . . . . . . . . . . . 12 101 5.2.3 Time-to-Live / Hop Limit . . . . . . . . . . . . . . . 12 102 5.2.4 IPv4 Protocol . . . . . . . . . . . . . . . . . . . . 12 103 5.3 Sending Multicast Router Terminations . . . . . . . . . . 12 104 5.4 Receiving Multicast Router Terminations . . . . . . . . . 12 105 6. Protocol Constants . . . . . . . . . . . . . . . . . . . . . . 13 106 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 107 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 108 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 109 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 110 10.1 Normative References . . . . . . . . . . . . . . . . . . . . 14 111 10.2 Informative References . . . . . . . . . . . . . . . . . . . 15 112 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15 113 Intellectual Property and Copyright Statements . . . . . . . . 17 115 1. Introduction 117 Multicast Router Discovery messages are useful for determining which 118 nodes attached to a switch have multicast routing enabled. This 119 capability is useful in a layer-2 bridging domain with snooping 120 switches. By utilizing MRD messages, layer-2 switches can determine 121 where to send multicast source data and group membership 122 messages[1][2]. Multicast source data and group membership Reports 123 must be received by all multicast routers on a segment. Using the 124 group membership protocol Query messages to discover multicast 125 routers is insufficient due to query suppression. 127 Although MRD messages could be sent as ICMP messages, the group 128 management protocols were chosen since this functionality is 129 multicast specific. The addition of this functionality to the group 130 membership protocol also allows operators to have congruency between 131 multicast router discovery problems and data forwarding issues. 133 The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 134 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 135 "OPTIONAL" in this document are to be interpreted as described in 136 [3]. 138 2. Protocol Overview 140 Multicast Router Discovery consists of three messages for discovering 141 multicast routers. The Multicast Router Advertisement is sent by 142 routers to advertise that IP multicast forwarding is enabled. 143 Devices may send Multicast Router Solicitation messages in order to 144 solicit Advertisement messages from multicast routers. The Multicast 145 Router Termination messages are sent when a router stops IP multicast 146 routing functions on an interface. 148 Multicast routers send Advertisements periodically on all interfaces 149 on which multicast forwarding is enabled. Advertisement messages are 150 also sent in response to Solicitations. In addition to advertising 151 the location of multicast routers, Advertisements also convey useful 152 information concerning group management protocol variables. This 153 information can be used for consistency checking on the subnet. 155 A device sends Solicitation messages whenever it wishes to discover 156 multicast routers on a directly attached link. 158 A router sends Termination messages when it terminates multicast 159 routing functionality on an interface. 161 All MRD messages are sent with an IPv4 TTL or IPv6 Hop Limit of 1 and 162 contain the Router Alert Option[4][5]. 164 Advertisement and Termination messages are sent to the All-Snoopers 165 multicast address. 167 Solicitation messages are sent to the All-Routers multicast address. 169 Any data beyond the fixed message format MUST be ignored. 171 3. Multicast Router Advertisement 173 Multicast Router Advertisements are sent periodically on all router 174 interfaces on which multicast forwarding is enabled. They are also 175 sent in response to Multicast Router Solicitation messages. 177 Advertisements are sent 179 1. Upon the expiration of a periodic (modulo randomization) timer 181 2. As a part of a router's start up procedure 183 3. During the restart of a multicast forwarding interface 185 4. On receipt of a Solicitation message 187 All Advertisements are sent as IGMP (for IPv4) or MLD (for IPv6) 188 messages to the All-Snoopers multicast address. These messages 189 SHOULD be rate-limited. 191 3.1 Advertisement Configuration Variables 193 An MRD implementation MUST support the following variables being 194 configured by system management. Default values are specified to 195 make it unnecessary to configure any of these variables in many 196 cases. 198 3.1.1 MaxAdertisementInterval 200 This variable is the maximum time (in seconds) allowed between the 201 transmissions of Advertisements on an interface. This value MUST be 202 no less than 4 seconds and no greater than 180 seconds. 204 Default: 20 seconds 206 3.1.2 MinAdvertisementInterval 208 This is the minimum time (in seconds) allowed between the 209 transmissions of Advertisements on an interface. This value MUST be 210 no less than 3 seconds and no greater than MaxAdvertisementInterval. 212 Default: 0.75 * MaxAdvertisementInterval 214 3.1.3 MaxInitialAdvertisementInterval 216 The first Advertisement transmitted on an interface is sent after 217 waiting a random interval (in seconds) less than this variable. This 218 prevents a flood of Advertisements when multiple routers start up at 219 the same time. 221 Default: 2 seconds 223 3.1.4 MaxInitialAdvertisements 225 This variable is the maximum number of Advertisements that will be 226 transmitted by the advertising interface when MRD starts up. 228 Default: 3 230 3.1.5 NeighborDeadInterval 232 This variable is the maximum time (in seconds) allowed to elapse 233 before a neighbor can be declared unreachable. In order for all 234 devices to have a consistent state, it is necessary for the 235 MaxAdvertisementInterval to be configured consistently in all devices 236 on the subnet. 238 Default: 3 * MaxAdvertisementInterval 240 3.2 Advertisement Packet Format 242 The Advertisement message has the following format: 244 0 1 2 3 245 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 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | Type | Ad. Interval | Checksum | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | Query Interval | Robustness Variable | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 3.2.1 Type Field 254 The Type field identifies the message as an Advertisement. It is set 255 to X1 (to be assigned by IANA) for IPv4 and X2 (to be assigned by 256 IANA) for IPv6. 258 3.2.2 Advertisement Interval Field 260 This field specifies the periodic time interval at which 261 Advertisement messages are transmitted in units of seconds. This 262 value is set to the configured MaxAdvertisementInterval variable. 264 3.2.3 Checksum Field 266 The checksum field is set as follows: 268 1. For IPv4 it is the 16-bit one's complement of the one's 269 complement sum of the IGMP message, starting with the Type field. 270 For computing the checksum, the checksum field is set to 0. 272 2. For IPv6 it is ICMPv6 checksum as specified in [6]. 274 3.2.4 Query Interval Field 276 The Query Interval field is set to the Query Interval value (in 277 seconds) in use by IGMP or MLD on the interface. If IGMP or MLD is 278 not enabled on the advertising interface, this field MUST be set to 279 0. Note that this is the Querier's Query Interval (QQI), not the 280 Querier's Query Interval Code (QQIC) as specified in the IGMP/MLD 281 specifications. 283 3.2.5 Robustness Variable Field 285 This field is set to the Robustness Variable in use by IGMPv2[2], 286 IGMPv3[7], or MLD[8][9] on the advertising interface. If IGMPv1 is 287 in use or no group management protocol is enabled on the interface, 288 this field MUST be set to 0. 290 3.3 IP Header Fields 292 3.3.1 Source Address 294 The IP source address is set to an IP address configured on the 295 advertising interface. For IPv6, a link-local address MUST be used. 297 3.3.2 Destination Address 299 The IP destination address is set to the All-Snoopers multicast 300 address. 302 3.3.3 Time-to-Live / Hop Limit 304 The IPv4 TTL and IPv6 Hop Limit are set to 1. 306 3.3.4 IPv4 Protocol 308 The IPv4 Protocol field is set to IGMP (2). 310 3.4 Sending Multicast Router Advertisements 312 Advertisement messages are sent when the following events occur: 314 1. The expiration of the periodic advertisement interval timer. 315 Note that it this timer is not strictly periodic since it is a 316 random number between MaxAdvertisementInterval and 317 MinAdvertisementInterval. 319 2. After a random delay less than MaxInitialAdvertisementInterval 320 when an interface is first enabled, is (re-)initialized, or MRD 321 is enabled. A router may send up to a maximum of 322 MaxInitialAdvertisements Advertisements, waiting for a random 323 delay less than MaxInitialAdvertisementInterval between each 324 successive message. Multiple Advertisements are sent for 325 robustness in the face of packet loss on the network. 327 This is to prevent an implosion of Advertisements. An example of 328 this occurring would be when many routers are powered on at the same 329 time. When a Solicitation is received, an Advertisement is sent in 330 response with a random delay less than MAX_RESPONSE_DELAY. If a 331 Solicitation is received while an Advertisement is pending, that 332 Solicitation MUST be ignored. 334 Changes in the Query Interval or Robustness Variable MUST NOT trigger 335 a new advertisement, however the new values MUST be used all future 336 Advertisement messages. 338 When an Advertisement is sent, the periodic advertisement interval 339 timer MUST be reset. 341 3.5 Receiving Multicast Router Advertisements 343 Upon receiving an Advertisement message, devices validate the message 344 with the following criteria: 346 1. The checksum is correct 348 2. The IP destination address is equal to the All-Snoopers multicast 349 address 351 3. For IPv6, the IP source address is a link-local address 353 An Advertisement not meeting the validity requirements MUST be 354 silently discarded and may be logged in a rate-limited manner. 356 If an Advertisement is not received for a particular neighbor within 357 a NeighborDeadInterval time interval, then the neighbor is considered 358 unreachable. 360 4. Multicast Router Solicitation 362 Multicast Router Solicitation messages are used to solicit 363 Advertisements from multicast routers on a segment. These messages 364 are used when a device wishes to discover multicast routers. Upon 365 receiving a solicitation on an interface with IP multicast forwarding 366 and MRD enabled, a router will respond with an Advertisement. 368 Solicitations may be sent when: 370 1. An interface is (re-)initialized 372 2. MRD is enabled 374 Solicitations are sent to the All-Routers multicast address and 375 SHOULD be rate-limited. 377 4.1 Solicitation Packet Format 379 The Solicitation message has the following format: 381 0 1 2 3 382 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 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 | Type | Reserved | Checksum | 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 4.1.1 Type Field 389 The Type field identifies the message as a Solicitation. It is set 390 to Y1 (to be assigned by IANA) for IPv4 and Y2 (to be assigned by 391 IANA) for IPv6. 393 4.1.2 Reserved Field 395 The Reserved field is set to 0 on transmission and ignored on 396 reception. 398 4.1.3 Checksum Field 400 The checksum field is set as follows: 402 o For IPv4 it is the 16-bit one's complement of the one's complement 403 sum of the IGMP message, starting with the Type field. For 404 computing the checksum, the checksum field is set to 0. 406 o For IPv6 it is ICMPv6 checksum as specified in [6]. 408 4.2 IP Header Fields 410 4.2.1 Source Address 412 The IP source address is set to an IP address configured on the 413 soliciting interface. For IPv6, a link-local address MUST be used. 415 4.2.2 Destination Address 417 The IP destination address is set to the All-Routers multicast 418 address. 420 4.2.3 Time-to-Live / Hop Limit 422 The IPv4 TTL and IPv6 Hop Limit are set to 1. 424 4.2.4 IPv4 Protocol 426 The IPv4 Protocol field is set to IGMP (2). 428 4.3 Sending Multicast Router Solicitations 430 Solicitation messages are sent when the following events occur: 432 o After waiting for a random delay less than MAX_SOLICITATION_DELAY 433 when an interface first becomes operational, is (re-)initialized, 434 or MRD is enabled. A device may send up to a maximum of 435 MAX_SOLICITATIONS, waiting for a random delay less than 436 MAX_SOLICITATION_DELAY between each solicitation. 438 o Optionally, for an implementation specific event. 440 Solicitations MUST be rate-limited; the implementation MUST send no 441 more than MAX_SOLICITATIONS in MAX_SOLICITATION_DELAY seconds. 443 4.4 Receiving Multicast Router Solicitations 445 A Solicitation message MUST be validated before a response is sent. 446 A router MUST verify that: 448 o The checksum is correct 449 o The IP destination address is the All-Routers multicast address 451 o For IPv6, the IP source address MUST be a link-local address 453 Solicitations not meeting the validity requirements SHOULD be 454 silently discarded and may be logged in a rate-limited manner. 456 5. Multicast Router Termination 458 The Multicast Router Termination message is used to expedite the 459 notification of a change in the status of a router's multicast 460 forwarding functions. Multicast routers send Terminations when 461 multicast forwarding is disabled on the advertising interface. 463 5.1 Termination Packet Format 465 The Termination message has the following format: 467 0 1 2 3 468 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 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 | Type | Reserved | Checksum | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 5.1.1 Type Field 475 The Type field identifies the message as a Termination. It is set to 476 Z1 (to be assigned by IANA) for IPv4 and Z2 (to be assigned by IANA) 477 for IPv6. 479 5.1.2 Reserved Field 481 The Reserved field is set to 0 on transmission and ignored on 482 reception. 484 5.1.3 Checksum Field 486 The checksum field is set as follows: 488 o For IPv4 it is the 16-bit one's complement of the one's complement 489 sum of the IGMP message, starting with the Type field. For 490 computing the checksum, the checksum field is set to 0. 492 o For IPv6 it is ICMPv6 checksum as specified in [6]. 494 5.2 IP Header Fields 496 5.2.1 Source Address 498 The IP source address is set to an IP address configured on the 499 advertising interface. For IPv6, a link-local address MUST be used. 501 5.2.2 Destination Address 503 The IP destination address is set to the All-Snoopers multicast 504 address. 506 5.2.3 Time-to-Live / Hop Limit 508 The IPv4 TTL and IPv6 Hop Limit are set to 1. 510 5.2.4 IPv4 Protocol 512 The IPv4 Protocol field is set to IGMP (2). 514 5.3 Sending Multicast Router Terminations 516 Termination messages are sent by multicast routers when: 518 o Multicast forwarding is disabled on an interface 520 o An interface is administratively disabled 522 o The router is gracefully shutdown 524 o MRD is disabled 526 5.4 Receiving Multicast Router Terminations 528 Upon receiving a Termination message, devices validate the message. 529 The validation criteria is: 531 o Checksum MUST be correct 533 o IP destination address MUST equal the All-Snoopers multicast 534 address 536 o For IPv6, the IP source address MUST be a link-local address 538 Termination messages not meeting the validity requirements MUST be 539 silently discarded and may be logged in a rate-limited manner. 541 If the message passes these validation steps, a Solicitation is sent. 542 If an Advertisement is not received within NeighborDeadInterval, the 543 sending router is removed from the list of active multicast routers. 545 6. Protocol Constants 547 The following list identifies constants used in the MRD protocol. 548 These constants are used in the calculation of parameters. 550 o MAX_RESPONSE_DELAY 2 seconds 552 o MAX_SOLICITATION_DELAY 1 second 554 o MAX_SOLICITATIONS 3 transmissions 556 7. Security Considerations 558 The Multicast Router Advertisement message may allow rogue machines 559 to masquerade as multicast routers. This could allow those machines 560 to eavesdrop on multicast data transmissions. Additionally, it could 561 constitute a denial of service attack to other hosts in the same 562 snooping domain or sharing the same device port in the presence of 563 high rate multicast flows. 565 This issue stems from the fact that there is currently no mechanism 566 for hosts to authenticate and authorize messages being sent from 567 local routers (e.g. source addresses are not checked). This problem 568 is shared by all IGMP and ICMPv6 messages, as well as other protocols 569 such as IPv6 Neighbor Discovery. 571 While solving this problem is beyond the scope of this document, it 572 is worth noting that work in the Secure Neighbor Discovery Working 573 Group may be applicable to Multicast Router Discovery. Should this 574 work prove successful, appropriate mechanisms may be incorporated 575 into a later extension to MRD. 577 8. IANA Considerations 579 This document introduces three new IGMP messages. Each of these 580 messages requires a new IGMP Type value. This document requests IANA 581 to assign three new IGMP Type values to the Multicast Router 582 Discovery Protocol: 584 +-----------+---------------+--------------------------------+ 585 | IGMP Type | Section | Message Name | 586 +-----------+---------------+--------------------------------+ 587 | X1 | Section 3.2.1 | Multicast Router Advertisement | 588 | Y1 | Section 4.1.1 | Multicast Router Solicitation | 589 | Z1 | Section 5.1.1 | Multicast Router Termination | 590 +-----------+---------------+--------------------------------+ 592 This document also introduces three new MLD messages. Each of these 593 messages requires a new ICMPv6 Type value. This document requests 594 IANA to assign three new ICMPv6 Type values from the Informational 595 range: 597 +-------------+---------------+--------------------------------+ 598 | ICMPv6 Type | Section | Message Name | 599 +-------------+---------------+--------------------------------+ 600 | X2 | Section 3.2.1 | Multicast Router Advertisement | 601 | Y2 | Section 4.1.1 | Multicast Router Solicitation | 602 | Z2 | Section 5.1.1 | Multicast Router Termination | 603 +-------------+---------------+--------------------------------+ 605 This document also requires the assignment of an All-Snoopers 606 multicast address for IPv4. This multicast address should be in the 607 224.0.0/24 range since it is used for link-local, control messages. 608 A corresponding IPv6 multicast address is also requested. Following 609 the guidelines in [10], the IPv6 multicast address should be 610 link-local in scope and have a group-ID value equal to the low order 611 8 bits of the requested IPv4 multicast address. 613 9. Acknowledgements 615 ICMP Router Discovery [11] was used as a general model for Multicast 616 Router Discovery. 618 Morten Christensen, Pekka Savola, Hugh Holbrook, and Isidor Kouvelas 619 provided helpful feedback on various versions of this document. 621 10. References 623 10.1 Normative References 625 [1] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 626 1112, August 1989. 628 [2] Fenner, W., "Internet Group Management Protocol, Version 2", 629 RFC 2236, November 1997. 631 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 632 Levels", BCP 14, RFC 2119, March 1997. 634 [4] Katz, D., "IP Router Alert Option", RFC 2113, February 1997. 636 [5] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", RFC 637 2711, October 1999. 639 [6] Conta, A. and S. Deering, "Internet Control Message Protocol 640 (ICMPv6) for the Internet Protocol Version 6 (IPv6) 641 Specification", RFC 2463, December 1998. 643 [7] Cain, B., Deering, S., Kouvelas, I., Fenner, B. and A. 644 Thyagarajan, "Internet Group Management Protocol, Version 3", 645 RFC 3376, October 2002. 647 [8] Deering, S., Fenner, W. and B. Haberman, "Multicast Listener 648 Discovery (MLD) for IPv6", RFC 2710, October 1999. 650 [9] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 651 (MLDv2) for IPv6", RFC 3810, June 2004. 653 [10] Haberman, B., "Allocation Guidelines for IPv6 Multicast 654 Addresses", RFC 3307, August 2002. 656 10.2 Informative References 658 [11] Deering, S., "ICMP Router Discovery Messages", RFC 1256, 659 September 1991. 661 [12] Bradner, S., "Intellectual Property Rights in IETF Technology", 662 BCP 79, RFC 3668, February 2004. 664 [13] Daigle, L. and Internet Architecture Board, "IETF ISOC Board of 665 Trustee Appointment Procedures", BCP 77, RFC 3677, December 666 2003. 668 Authors' Addresses 670 Brian Haberman 671 Johns Hopkins University Applied Physics Lab 672 11100 Johns Hopkins Road 673 Laurel, MD 20723-6099 674 US 676 Phone: +1 443 778 1319 677 EMail: brian@innovationslab.net 678 Jim Martin 679 Netzwert AG 680 An den Treptowers 1 681 D-12435 Berlin 682 Germany 684 Phone: +49.30/5 900 800-180 685 EMail: jim@netzwert.ag 687 Intellectual Property Statement 689 The IETF takes no position regarding the validity or scope of any 690 Intellectual Property Rights or other rights that might be claimed to 691 pertain to the implementation or use of the technology described in 692 this document or the extent to which any license under such rights 693 might or might not be available; nor does it represent that it has 694 made any independent effort to identify any such rights. Information 695 on the procedures with respect to rights in RFC documents can be 696 found in BCP 78 and BCP 79. 698 Copies of IPR disclosures made to the IETF Secretariat and any 699 assurances of licenses to be made available, or the result of an 700 attempt made to obtain a general license or permission for the use of 701 such proprietary rights by implementers or users of this 702 specification can be obtained from the IETF on-line IPR repository at 703 http://www.ietf.org/ipr. 705 The IETF invites any interested party to bring to its attention any 706 copyrights, patents or patent applications, or other proprietary 707 rights that may cover technology that may be required to implement 708 this standard. Please address the information to the IETF at 709 ietf-ipr@ietf.org. 711 Disclaimer of Validity 713 This document and the information contained herein are provided on an 714 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 715 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 716 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 717 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 718 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 719 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 721 Copyright Statement 723 Copyright (C) The Internet Society (2004). This document is subject 724 to the rights, licenses and restrictions contained in BCP 78, and 725 except as set forth therein, the authors retain all their rights. 727 Acknowledgment 729 Funding for the RFC Editor function is currently provided by the 730 Internet Society.