idnits 2.17.1 draft-ietf-magma-mrdisc-05.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 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 791. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 768. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 775. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 781. ** 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. 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 (April 13, 2005) is 6952 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) ** Obsolete normative reference: RFC 2463 (ref. '6') (Obsoleted by RFC 4443) ** Obsolete normative reference: RFC 2406 (ref. '11') (Obsoleted by RFC 4303, RFC 4305) Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 7 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: October 15, 2005 J. Martin 4 Netzwert AG 5 April 13, 2005 7 Multicast Router Discovery 8 draft-ietf-magma-mrdisc-05 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on October 15, 2005. 35 Copyright Notice 37 Copyright (C) The Internet Society (2005). 39 Abstract 41 The concept of Internet Group Membership Protocol (IGMP) and 42 Multicast Listener Discovery (MLD) snooping requires the ability to 43 identify the location of multicast routers. Since snooping is not 44 standardized, there are many mechanisms in use to identify the 45 multicast routers. However, this can lead to interoperability issues 46 between multicast routers and snooping switches from different 47 vendors. 49 This document introduces a general mechanism that allows for the 50 discovery of multicast routers. This new mechanism, Multicast Router 51 Discovery (MRD), introduces a standardized means of identifying 52 multicast routers without a dependency on particular multicast 53 routing protocols. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Multicast Router Advertisement . . . . . . . . . . . . . . . . 5 60 3.1 Advertisement Configuration Variables . . . . . . . . . . 5 61 3.1.1 AdvertisementInterval . . . . . . . . . . . . . . . . 5 62 3.1.2 AdvertisementJitter . . . . . . . . . . . . . . . . . 5 63 3.1.3 MaxInitialAdvertisementInterval . . . . . . . . . . . 6 64 3.1.4 MaxInitialAdvertisements . . . . . . . . . . . . . . . 6 65 3.1.5 NeighborDeadInterval . . . . . . . . . . . . . . . . . 6 66 3.1.6 MaxMessageRate . . . . . . . . . . . . . . . . . . . . 6 67 3.2 Advertisement Packet Format . . . . . . . . . . . . . . . 7 68 3.2.1 Type Field . . . . . . . . . . . . . . . . . . . . . . 7 69 3.2.2 Advertisement Interval Field . . . . . . . . . . . . . 7 70 3.2.3 Checksum Field . . . . . . . . . . . . . . . . . . . . 7 71 3.2.4 Query Interval Field . . . . . . . . . . . . . . . . . 7 72 3.2.5 Robustness Variable Field . . . . . . . . . . . . . . 7 73 3.3 IP Header Fields . . . . . . . . . . . . . . . . . . . . . 8 74 3.3.1 Source Address . . . . . . . . . . . . . . . . . . . . 8 75 3.3.2 Destination Address . . . . . . . . . . . . . . . . . 8 76 3.3.3 Time-to-Live / Hop Limit . . . . . . . . . . . . . . . 8 77 3.3.4 IPv4 Protocol . . . . . . . . . . . . . . . . . . . . 8 78 3.3.5 IPv6 Next Header . . . . . . . . . . . . . . . . . . . 8 79 3.4 Sending Multicast Router Advertisements . . . . . . . . . 8 80 3.5 Receiving Multicast Router Advertisements . . . . . . . . 9 81 4. Multicast Router Solicitation . . . . . . . . . . . . . . . . 9 82 4.1 Solicitation Packet Format . . . . . . . . . . . . . . . . 10 83 4.1.1 Type Field . . . . . . . . . . . . . . . . . . . . . . 10 84 4.1.2 Reserved Field . . . . . . . . . . . . . . . . . . . . 10 85 4.1.3 Checksum Field . . . . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . . . . 11 91 4.3 Sending Multicast Router Solicitations . . . . . . . . . . 11 92 4.4 Receiving Multicast Router Solicitations . . . . . . . . . 11 93 5. Multicast Router Termination . . . . . . . . . . . . . . . . . 11 94 5.1 Termination Packet Format . . . . . . . . . . . . . . . . 11 95 5.1.1 Type Field . . . . . . . . . . . . . . . . . . . . . . 12 96 5.1.2 Reserved Field . . . . . . . . . . . . . . . . . . . . 12 97 5.1.3 Checksum Field . . . . . . . . . . . . . . . . . . . . 12 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 . . . . . . . . . . 13 104 5.4 Receiving Multicast Router Terminations . . . . . . . . . 13 105 6. Protocol Constants . . . . . . . . . . . . . . . . . . . . . . 13 106 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 107 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 108 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 109 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 110 10.1 Normative References . . . . . . . . . . . . . . . . . . . 16 111 10.2 Informative References . . . . . . . . . . . . . . . . . . 17 112 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17 113 Intellectual Property and Copyright Statements . . . . . . . . 18 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 unsolicited Advertisements periodically on all 149 interfaces on which multicast forwarding is enabled. Advertisement 150 messages are also sent in response to Solicitations. In addition to 151 advertising the location of multicast routers, Advertisements also 152 convey useful information concerning group management protocol 153 variables. This information can be used for consistency checking on 154 the subnet. 156 A device sends Solicitation messages whenever it wishes to discover 157 multicast routers on a directly attached link. 159 A router sends Termination messages when it terminates multicast 160 routing functionality on an interface. 162 All MRD messages are sent with an IPv4 TTL or IPv6 Hop Limit of 1 and 163 contain the Router Alert Option[4][5]. All MRD messages SHOULD be 164 rate-limited as per the MaxMessageRate variable. 166 Advertisement and Termination messages are sent to the All-Snoopers 167 multicast address. 169 Solicitation messages are sent to the All-Routers multicast address. 171 Any data beyond the fixed message format MUST be ignored. 173 3. Multicast Router Advertisement 175 Multicast Router Advertisements are sent unsolicited periodically on 176 all router interfaces on which multicast forwarding is enabled. They 177 are also sent in response to Multicast Router Solicitation messages. 179 Advertisements are sent 181 1. Upon the expiration of a periodic (modulo randomization) timer 183 2. As a part of a router's start up procedure 185 3. During the restart of a multicast forwarding interface 187 4. On receipt of a Solicitation message 189 All Advertisements are sent as IGMP (for IPv4) or MLD (for IPv6) 190 messages to the All-Snoopers multicast address. These messages 191 SHOULD be rate-limited as per the MaxMessageRate variable. 193 3.1 Advertisement Configuration Variables 195 An MRD implementation MUST support the following variables being 196 configured by system management. Default values are specified to 197 make it unnecessary to configure any of these variables in many 198 cases. 200 3.1.1 AdvertisementInterval 202 This variable is the base interval (in seconds) between the 203 transmissions of unsolicited Advertisements on an interface. This 204 value MUST be no less than 4 seconds and no greater than 180 seconds. 206 Default: 20 seconds 208 3.1.2 AdvertisementJitter 210 This is the maximum time (in seconds) by which the 211 AdvertismentInterval is perturbed for each unsolicited Advertisment. 212 Note that the purpose of this jitter is to avoid synchronization of 213 multiple routers on a network, hence choosing a value of zero is 214 discouraged. This value MUST be no less than 0 seconds and no 215 greater than AdvertisementInterval. 217 Default: 5 seconds 219 3.1.3 MaxInitialAdvertisementInterval 221 The first unsolicited Advertisement transmitted on an interface is 222 sent after waiting a random interval (in seconds) less than this 223 variable. This prevents a flood of Advertisements when multiple 224 routers start up at the same time. 226 Default: 2 seconds 228 3.1.4 MaxInitialAdvertisements 230 This variable is the maximum number of unsolicited Advertisements 231 that will be transmitted by the advertising interface when MRD starts 232 up. 234 Default: 3 236 3.1.5 NeighborDeadInterval 238 The NeighborDeadInterval variable is the maximum time (in seconds) 239 allowed to elapse (after receipt of the last valid Advertisement) 240 before a neighboring router is declared unreachable. This variable 241 is maintained per neighbor. An MRD receiver should set the 242 NeighborDeadInterval to 3 times the Advertisement Interval Field 243 received. This ensures consistant behavior between multiple devices 244 on a network. 246 Default (sender): 3 * AdvertisementInterval 248 Default (received): 3 * Advertisement Interval Field 250 3.1.6 MaxMessageRate 252 The MaxMessageRate variable is the maximum aggregate number of 253 messages per second per interface or per logical destination that an 254 MRD implementation SHOULD send. 256 Default: 10 258 3.2 Advertisement Packet Format 260 The Advertisement message has the following format: 262 0 1 2 3 263 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 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | Type | Ad. Interval | Checksum | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | Query Interval | Robustness Variable | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 3.2.1 Type Field 272 The Type field identifies the message as an Advertisement. It is set 273 to X1 (to be assigned by IANA) for IPv4 and X2 (to be assigned by 274 IANA) for IPv6. 276 3.2.2 Advertisement Interval Field 278 This field specifies the periodic time interval at which unsolicited 279 Advertisement messages are transmitted in units of seconds. This 280 value is set to the configured AdvertisementInterval variable. 282 3.2.3 Checksum Field 284 The checksum field is set as follows: 286 1. For IPv4 it is the 16-bit one's complement of the one's 287 complement sum of the IGMP message, starting with the Type field. 288 For computing the checksum, the checksum field is set to 0. 290 2. For IPv6 it is ICMPv6 checksum as specified in [6]. 292 3.2.4 Query Interval Field 294 The Query Interval field is set to the Query Interval value (in 295 seconds) in use by IGMP or MLD on the interface. If IGMP or MLD is 296 not enabled on the advertising interface, this field MUST be set to 297 0. Note that this is the Querier's Query Interval (QQI), not the 298 Querier's Query Interval Code (QQIC) as specified in the IGMP/MLD 299 specifications. 301 3.2.5 Robustness Variable Field 303 This field is set to the Robustness Variable in use by IGMPv2[2], 304 IGMPv3[7], or MLD[8][9] on the advertising interface. If IGMPv1 is 305 in use or no group management protocol is enabled on the interface, 306 this field MUST be set to 0. 308 3.3 IP Header Fields 310 3.3.1 Source Address 312 The IP source address is set to an IP address configured on the 313 advertising interface. For IPv6, a link-local address MUST be used. 315 3.3.2 Destination Address 317 The IP destination address is set to the All-Snoopers multicast 318 address. 320 3.3.3 Time-to-Live / Hop Limit 322 The IPv4 TTL and IPv6 Hop Limit are set to 1. 324 3.3.4 IPv4 Protocol 326 The IPv4 Protocol field is set to IGMP (2). 328 3.3.5 IPv6 Next Header 330 The ICMPv6 header is identified by a Next Header value of 58 in the 331 immediately preceding header.[6] 333 3.4 Sending Multicast Router Advertisements 335 Advertisement messages are sent when the following events occur: 337 1. The expiration of the periodic advertisement interval timer. 338 Note that this timer is not strictly periodic since the base 339 AdvertismentInterval is varied each interval by a random value no 340 more than plus or minus AdvertisementJitter seconds. 342 2. After a random delay less than MaxInitialAdvertisementInterval 343 when an interface is first enabled, is (re-)initialized, or MRD 344 is enabled. A router may send up to a maximum of 345 MaxInitialAdvertisements Advertisements, waiting for a random 346 delay less than MaxInitialAdvertisementInterval between each 347 successive message. Multiple Advertisements are sent for 348 robustness in the face of packet loss on the network. 350 This is to prevent an implosion of Advertisements. An example of 351 this occurring would be when many routers are powered on at the same 352 time. When a Solicitation is received, an Advertisement is sent in 353 response with a random delay less than MAX_RESPONSE_DELAY. If a 354 Solicitation is received while an Advertisement is pending, that 355 Solicitation MUST be ignored. 357 Changes in the Query Interval or Robustness Variable MUST NOT trigger 358 a new advertisement, however the new values MUST be used all future 359 Advertisement messages. 361 When an Advertisement is sent, the periodic advertisement interval 362 timer MUST be reset. 364 3.5 Receiving Multicast Router Advertisements 366 Upon receiving an Advertisement message, devices validate the message 367 with the following criteria: 369 1. The checksum is correct 371 2. The IP destination address is equal to the All-Snoopers multicast 372 address 374 3. For IPv6, the IP source address is a link-local address 376 An Advertisement not meeting the validity requirements MUST be 377 silently discarded and may be logged in a rate-limited manner as per 378 the MaxMessageRate variable. 380 If an Advertisement is not received for a particular neighbor within 381 a NeighborDeadInterval time interval, then the neighbor is considered 382 unreachable. 384 4. Multicast Router Solicitation 386 Multicast Router Solicitation messages are used to solicit 387 Advertisements from multicast routers on a segment. These messages 388 are used when a device wishes to discover multicast routers. Upon 389 receiving a solicitation on an interface with IP multicast forwarding 390 and MRD enabled, a router will respond with an Advertisement. 392 Solicitations may be sent when: 394 1. An interface is (re-)initialized 396 2. MRD is enabled 398 Solicitations are sent to the All-Routers multicast address and 399 SHOULD be rate-limited as per the MaxMessageRate variable. 401 4.1 Solicitation Packet Format 403 The Solicitation message has the following format: 405 0 1 2 3 406 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 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 | Type | Reserved | Checksum | 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 4.1.1 Type Field 413 The Type field identifies the message as a Solicitation. It is set 414 to Y1 (to be assigned by IANA) for IPv4 and Y2 (to be assigned by 415 IANA) for IPv6. 417 4.1.2 Reserved Field 419 The Reserved field is set to 0 on transmission and ignored on 420 reception. 422 4.1.3 Checksum Field 424 The checksum field is set as follows: 426 o For IPv4 it is the 16-bit one's complement of the one's complement 427 sum of the IGMP message, starting with the Type field. For 428 computing the checksum, the checksum field is set to 0. 430 o For IPv6 it is ICMPv6 checksum as specified in [6]. 432 4.2 IP Header Fields 434 4.2.1 Source Address 436 The IP source address is set to an IP address configured on the 437 soliciting interface. For IPv6, a link-local address MUST be used. 439 4.2.2 Destination Address 441 The IP destination address is set to the All-Routers multicast 442 address. 444 4.2.3 Time-to-Live / Hop Limit 446 The IPv4 TTL and IPv6 Hop Limit are set to 1. 448 4.2.4 IPv4 Protocol 450 The IPv4 Protocol field is set to IGMP (2). 452 4.3 Sending Multicast Router Solicitations 454 Solicitation messages are sent when the following events occur: 456 o After waiting for a random delay less than MAX_SOLICITATION_DELAY 457 when an interface first becomes operational, is (re-)initialized, 458 or MRD is enabled. A device may send up to a maximum of 459 MAX_SOLICITATIONS, waiting for a random delay less than 460 MAX_SOLICITATION_DELAY between each solicitation. 462 o Optionally, for an implementation specific event. 464 Solicitations MUST be rate-limited as per the MaxMessageRate 465 variable; the implementation MUST send no more than MAX_SOLICITATIONS 466 in MAX_SOLICITATION_DELAY seconds. 468 4.4 Receiving Multicast Router Solicitations 470 A Solicitation message MUST be validated before a response is sent. 471 A router MUST verify that: 473 o The checksum is correct 475 o The IP destination address is the All-Routers multicast address 477 o For IPv6, the IP source address MUST be a link-local address 479 Solicitations not meeting the validity requirements SHOULD be 480 silently discarded and may be logged in a rate-limited manner as per 481 the MaxMessageRate variable. 483 5. Multicast Router Termination 485 The Multicast Router Termination message is used to expedite the 486 notification of a change in the status of a router's multicast 487 forwarding functions. Multicast routers send Terminations when 488 multicast forwarding is disabled on the advertising interface. 490 5.1 Termination Packet Format 492 The Termination message has the following format: 494 0 1 2 3 495 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 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 | Type | Reserved | Checksum | 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 5.1.1 Type Field 502 The Type field identifies the message as a Termination. It is set to 503 Z1 (to be assigned by IANA) for IPv4 and Z2 (to be assigned by IANA) 504 for IPv6. 506 5.1.2 Reserved Field 508 The Reserved field is set to 0 on transmission and ignored on 509 reception. 511 5.1.3 Checksum Field 513 The checksum field is set as follows: 515 o For IPv4 it is the 16-bit one's complement of the one's complement 516 sum of the IGMP message, starting with the Type field. For 517 computing the checksum, the checksum field is set to 0. 519 o For IPv6 it is ICMPv6 checksum as specified in [6]. 521 5.2 IP Header Fields 523 5.2.1 Source Address 525 The IP source address is set to an IP address configured on the 526 advertising interface. For IPv6, a link-local address MUST be used. 528 5.2.2 Destination Address 530 The IP destination address is set to the All-Snoopers multicast 531 address. 533 5.2.3 Time-to-Live / Hop Limit 535 The IPv4 TTL and IPv6 Hop Limit are set to 1. 537 5.2.4 IPv4 Protocol 539 The IPv4 Protocol field is set to IGMP (2). 541 5.3 Sending Multicast Router Terminations 543 Termination messages are sent by multicast routers when: 545 o Multicast forwarding is disabled on an interface 547 o An interface is administratively disabled 549 o The router is gracefully shutdown 551 o MRD is disabled 553 The sending of Termination messages SHOULD be rate-limited as per the 554 MaxMessageRate variable. 556 5.4 Receiving Multicast Router Terminations 558 Upon receiving a Termination message, devices validate the message. 559 The validation criteria is: 561 o Checksum MUST be correct 563 o IP destination address MUST equal the All-Snoopers multicast 564 address 566 o For IPv6, the IP source address MUST be a link-local address 568 Termination messages not meeting the validity requirements MUST be 569 silently discarded and may be logged in a rate-limited manner as per 570 the MaxMessageRate variable. 572 If the message passes these validation steps, a Solicitation is sent. 573 If an Advertisement is not received within NeighborDeadInterval, the 574 sending router is removed from the list of active multicast routers. 576 6. Protocol Constants 578 The following list identifies constants used in the MRD protocol. 579 These constants are used in the calculation of parameters. 581 o MAX_RESPONSE_DELAY 2 seconds 583 o MAX_SOLICITATION_DELAY 1 second 585 o MAX_SOLICITATIONS 3 transmissions 587 7. Security Considerations 589 As MRD is a link-local protocol, there is no circumstance in which it 590 would be correct for a MRD receiver to receive MRD traffic from an 591 off-network source. For IPv6, MRD messages MUST have a valid link- 592 local source address. Any messages received without a valid link- 593 local source address MUST be discarded. Similarly, for IPv4, the MRD 594 receiver MUST determine if the source address is local to the 595 receiving interface, and MUST discard any messages that have a non- 596 local source. Determining what networks are local may be 597 accomplished through configuration information or operational 598 capabilities. 600 Rogue nodes may attempt to attack a network running MRD by sending 601 spoofed Advertisement, Solicitation, or Termination messages. Each 602 type of spoofed message can be dealt with using existing technology. 604 A rogue node may attempt to interrupt multicast service by sending 605 spoofed Termination messages. As described in Section 5.4, all 606 Termination messages are validated by sending a Solicitation message. 607 By sending a Solicitation, the node will force the transmission of an 608 Advertisement by an active router. 610 Spoofed Solicitation messages do not cause any operational harm. 611 They may be used as a flooding mechanism to attack a multicast 612 router. This attack can be mitigated through the rate-limiting 613 recommendation for all MRD messages. 615 The Multicast Router Advertisement message may allow rogue machines 616 to masquerade as multicast routers. This could allow those machines 617 to eavesdrop on multicast data transmissions. Additionally, it could 618 constitute a denial of service attack to other hosts in the same 619 snooping domain or sharing the same device port in the presence of 620 high rate multicast flows. 622 The technology available in SEND[10] can be utilized to address 623 spoofed Advertisement messages in IPv6 networks. IPv6 Multicast 624 routers in an MRD-enabled network can use SEND-based link-local 625 addresses as the IPv6 source address for MRD messages. When a switch 626 receives an initial Advertisement, it can use the information in the 627 SEND-based address to challenge the router to authenticate itself. 628 It should be noted that this approach only applies to IPv6 networks. 630 Another solution which supports both IPv4 and IPv6 is to use IPsec in 631 Encapsulating Security Payload (ESP) mode[11] to protect against 632 attacks by ensuring that messages came from a system with the proper 633 key. When using IPsec, the messages sent to the All-Snoopers address 634 should be authenticated using ESP. Should encryption not be desired, 635 ESP with a null encryption algorithm and a symmetric authentication 636 algorithm, such as HMAC-SHA-1, is viable. For keying, a symmetric 637 signature algorithm with a single manually configured key is used for 638 routers sending Advertisements. This allows validation that the MRD 639 message was sent by a system with the key. It should be noted that 640 this does not prevent a system with the key from forging a message 641 and it requires the disabling of IPsec's Replay Protection. It is 642 the responsibility of the network administrator to ensure that the 643 same key is present on all possible MRD participants. 645 8. IANA Considerations 647 This document introduces three new IGMP messages. Each of these 648 messages requires a new IGMP Type value. This document requests IANA 649 to assign three new IGMP Type values to the Multicast Router 650 Discovery Protocol: 652 +-----------+-----------------+--------------------------------+ 653 | IGMP Type | Section | Message Name | 654 +-----------+-----------------+--------------------------------+ 655 | X1 | Section 3.2.1 | Multicast Router Advertisement | 656 | Y1 | Section 4.1.1 | Multicast Router Solicitation | 657 | Z1 | Section 5.1.1 | Multicast Router Termination | 658 +-----------+-----------------+--------------------------------+ 660 This document also introduces three new MLD messages. Each of these 661 messages requires a new ICMPv6 Type value. This document requests 662 IANA to assign three new ICMPv6 Type values from the Informational 663 range: 665 +-------------+-----------------+--------------------------------+ 666 | ICMPv6 Type | Section | Message Name | 667 +-------------+-----------------+--------------------------------+ 668 | X2 | Section 3.2.1 | Multicast Router Advertisement | 669 | Y2 | Section 4.1.1 | Multicast Router Solicitation | 670 | Z2 | Section 5.1.1 | Multicast Router Termination | 671 +-------------+-----------------+--------------------------------+ 673 This document also requires the assignment of an All-Snoopers 674 multicast address for IPv4. This multicast address should be in the 675 224.0.0/24 range since it is used for link-local, control messages. 676 A corresponding IPv6 multicast address is also requested. Following 677 the guidelines in [12], the IPv6 multicast address should be link- 678 local in scope and have a group-ID value equal to the low order 8 679 bits of the requested IPv4 multicast address. 681 9. Acknowledgements 683 Brad Cain and Shantam Biswis are the authors of the original 684 Multicast Router Discovery proposal. 686 ICMP Router Discovery [13] was used as a general model for Multicast 687 Router Discovery. 689 Morten Christensen, Pekka Savola, Hugh Holbrook, and Isidor Kouvelas 690 provided helpful feedback on various versions of this document. 692 10. References 694 10.1 Normative References 696 [1] Deering, S., "Host extensions for IP multicasting", STD 5, 697 RFC 1112, August 1989. 699 [2] Fenner, W., "Internet Group Management Protocol, Version 2", 700 RFC 2236, November 1997. 702 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 703 Levels", BCP 14, RFC 2119, March 1997. 705 [4] Katz, D., "IP Router Alert Option", RFC 2113, February 1997. 707 [5] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", 708 RFC 2711, October 1999. 710 [6] Conta, A. and S. Deering, "Internet Control Message Protocol 711 (ICMPv6) for the Internet Protocol Version 6 (IPv6) 712 Specification", RFC 2463, December 1998. 714 [7] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 715 Thyagarajan, "Internet Group Management Protocol, Version 3", 716 RFC 3376, October 2002. 718 [8] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener 719 Discovery (MLD) for IPv6", RFC 2710, October 1999. 721 [9] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 722 (MLDv2) for IPv6", RFC 3810, June 2004. 724 [10] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B., and P. 725 Nikander, "SEcure Neighbor Discovery (SEND)", 726 draft-ietf-send-ndopt-06 (work in progress), July 2004. 728 [11] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload 729 (ESP)", RFC 2406, November 1998. 731 [12] Haberman, B., "Allocation Guidelines for IPv6 Multicast 732 Addresses", RFC 3307, August 2002. 734 10.2 Informative References 736 [13] Deering, S., "ICMP Router Discovery Messages", RFC 1256, 737 September 1991. 739 Authors' Addresses 741 Brian Haberman 742 Johns Hopkins University Applied Physics Lab 743 11100 Johns Hopkins Road 744 Laurel, MD 20723-6099 745 US 747 Phone: +1 443 778 1319 748 Email: brian@innovationslab.net 750 Jim Martin 751 Netzwert AG 752 An den Treptowers 1 753 D-12435 Berlin 754 Germany 756 Phone: +49.30/5 900 800-180 757 Email: jim@netzwert.ag 759 Intellectual Property Statement 761 The IETF takes no position regarding the validity or scope of any 762 Intellectual Property Rights or other rights that might be claimed to 763 pertain to the implementation or use of the technology described in 764 this document or the extent to which any license under such rights 765 might or might not be available; nor does it represent that it has 766 made any independent effort to identify any such rights. Information 767 on the procedures with respect to rights in RFC documents can be 768 found in BCP 78 and BCP 79. 770 Copies of IPR disclosures made to the IETF Secretariat and any 771 assurances of licenses to be made available, or the result of an 772 attempt made to obtain a general license or permission for the use of 773 such proprietary rights by implementers or users of this 774 specification can be obtained from the IETF on-line IPR repository at 775 http://www.ietf.org/ipr. 777 The IETF invites any interested party to bring to its attention any 778 copyrights, patents or patent applications, or other proprietary 779 rights that may cover technology that may be required to implement 780 this standard. Please address the information to the IETF at 781 ietf-ipr@ietf.org. 783 Disclaimer of Validity 785 This document and the information contained herein are provided on an 786 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 787 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 788 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 789 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 790 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 791 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 793 Copyright Statement 795 Copyright (C) The Internet Society (2005). This document is subject 796 to the rights, licenses and restrictions contained in BCP 78, and 797 except as set forth therein, the authors retain all their rights. 799 Acknowledgment 801 Funding for the RFC Editor function is currently provided by the 802 Internet Society.