idnits 2.17.1 draft-ietf-magma-mrdisc-03.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 760. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 737. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 744. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 750. ** 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 == The page length should not exceed 58 lines per page, but there was 16 longer pages, the longest (page 12) being 78 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 17 pages 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 2004) is 7156 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: '14' is defined on line 701, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 704, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2463 (ref. '6') (Obsoleted by RFC 4443) ** Obsolete normative reference: RFC 2402 (ref. '11') (Obsoleted by RFC 4302, RFC 4305) -- Obsolete informational reference (is this intentional?): RFC 3668 (ref. '14') (Obsoleted by RFC 3979) Summary: 7 errors (**), 0 flaws (~~), 7 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 2, 2005 J. Martin 4 Netzwert AG 5 September 2004 7 Multicast Router Discovery 8 draft-ietf-magma-mrdisc-03 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 2, 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 . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . 10 91 4.3 Sending Multicast Router Solicitations . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . 14 108 9. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 109 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 110 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 111 11.1 Normative References . . . . . . . . . . . . . . . . . . . . 15 112 11.2 Informative References . . . . . . . . . . . . . . . . . . . 16 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16 114 Intellectual Property and Copyright Statements . . . . . . . . 17 116 1. Introduction 118 Multicast Router Discovery messages are useful for determining which 119 nodes attached to a switch have multicast routing enabled. This 120 capability is useful in a layer-2 bridging domain with snooping 121 switches. By utilizing MRD messages, layer-2 switches can determine 122 where to send multicast source data and group membership 123 messages[1][2]. Multicast source data and group membership Reports 124 must be received by all multicast routers on a segment. Using the 125 group membership protocol Query messages to discover multicast 126 routers is insufficient due to query suppression. 128 Although MRD messages could be sent as ICMP messages, the group 129 management protocols were chosen since this functionality is 130 multicast specific. The addition of this functionality to the group 131 membership protocol also allows operators to have congruency between 132 multicast router discovery problems and data forwarding issues. 134 The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 135 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 136 "OPTIONAL" in this document are to be interpreted as described in 137 [3]. 139 2. Protocol Overview 141 Multicast Router Discovery consists of three messages for discovering 142 multicast routers. The Multicast Router Advertisement is sent by 143 routers to advertise that IP multicast forwarding is enabled. 144 Devices may send Multicast Router Solicitation messages in order to 145 solicit Advertisement messages from multicast routers. The Multicast 146 Router Termination messages are sent when a router stops IP multicast 147 routing functions on an interface. 149 Multicast routers send Advertisements periodically on all interfaces 150 on which multicast forwarding is enabled. Advertisement messages are 151 also sent in response to Solicitations. In addition to advertising 152 the location of multicast routers, Advertisements also convey useful 153 information concerning group management protocol variables. This 154 information can be used for consistency checking on 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. 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 periodically on all router 176 interfaces on which multicast forwarding is enabled. They are also 177 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. 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 MaxAdertisementInterval 202 This variable is the maximum time (in seconds) allowed between the 203 transmissions of Advertisements on an interface. This value MUST be 204 no less than 4 seconds and no greater than 180 seconds. 206 Default: 20 seconds 208 3.1.2 MinAdvertisementInterval 210 This is the minimum time (in seconds) allowed between the 211 transmissions of Advertisements on an interface. This value MUST be 212 no less than 3 seconds and no greater than MaxAdvertisementInterval. 214 Default: 0.75 * MaxAdvertisementInterval 216 3.1.3 MaxInitialAdvertisementInterval 218 The first Advertisement transmitted on an interface is sent after 219 waiting a random interval (in seconds) less than this variable. This 220 prevents a flood of Advertisements when multiple routers start up at 221 the same time. 223 Default: 2 seconds 225 3.1.4 MaxInitialAdvertisements 227 This variable is the maximum number of Advertisements that will be 228 transmitted by the advertising interface when MRD starts up. 230 Default: 3 232 3.1.5 NeighborDeadInterval 234 The NeighborDeadInterval variable is the maximum time (in seconds) 235 allowed to elapse (after receipt of the last valid Advertisement) 236 before a neighboring router is declared unreachable. This variable 237 is maintained per neighbor. In order for all devices to have a 238 consistent state, it is necessary for the MaxAdvertisementInterval to 239 be configured consistently in all devices on the subnet. 241 Default: 3 * MaxAdvertisementInterval 243 3.2 Advertisement Packet Format 245 The Advertisement message has the following format: 247 0 1 2 3 248 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 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | Type | Ad. Interval | Checksum | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | Query Interval | Robustness Variable | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 3.2.1 Type Field 257 The Type field identifies the message as an Advertisement. It is set 258 to X1 (to be assigned by IANA) for IPv4 and X2 (to be assigned by 259 IANA) for IPv6. 261 3.2.2 Advertisement Interval Field 263 This field specifies the periodic time interval at which 264 Advertisement messages are transmitted in units of seconds. This 265 value is set to the configured MaxAdvertisementInterval variable. 267 3.2.3 Checksum Field 269 The checksum field is set as follows: 271 1. For IPv4 it is the 16-bit one's complement of the one's 272 complement sum of the IGMP message, starting with the Type field. 273 For computing the checksum, the checksum field is set to 0. 275 2. For IPv6 it is ICMPv6 checksum as specified in [6]. 277 3.2.4 Query Interval Field 279 The Query Interval field is set to the Query Interval value (in 280 seconds) in use by IGMP or MLD on the interface. If IGMP or MLD is 281 not enabled on the advertising interface, this field MUST be set to 282 0. Note that this is the Querier's Query Interval (QQI), not the 283 Querier's Query Interval Code (QQIC) as specified in the IGMP/MLD 284 specifications. 286 3.2.5 Robustness Variable Field 288 This field is set to the Robustness Variable in use by IGMPv2[2], 289 IGMPv3[7], or MLD[8][9] on the advertising interface. If IGMPv1 is 290 in use or no group management protocol is enabled on the interface, 291 this field MUST be set to 0. 293 3.3 IP Header Fields 295 3.3.1 Source Address 297 The IP source address is set to an IP address configured on the 298 advertising interface. For IPv6, a link-local address MUST be used. 300 3.3.2 Destination Address 302 The IP destination address is set to the All-Snoopers multicast 303 address. 305 3.3.3 Time-to-Live / Hop Limit 307 The IPv4 TTL and IPv6 Hop Limit are set to 1. 309 3.3.4 IPv4 Protocol 311 The IPv4 Protocol field is set to IGMP (2). 313 3.4 Sending Multicast Router Advertisements 315 Advertisement messages are sent when the following events occur: 317 1. The expiration of the periodic advertisement interval timer. 318 Note that it this timer is not strictly periodic since it is a 319 random number between MaxAdvertisementInterval and 320 MinAdvertisementInterval. 322 2. After a random delay less than MaxInitialAdvertisementInterval 323 when an interface is first enabled, is (re-)initialized, or MRD 324 is enabled. A router may send up to a maximum of 325 MaxInitialAdvertisements Advertisements, waiting for a random 326 delay less than MaxInitialAdvertisementInterval between each 327 successive message. Multiple Advertisements are sent for 328 robustness in the face of packet loss on the network. 330 This is to prevent an implosion of Advertisements. An example of 331 this occurring would be when many routers are powered on at the same 332 time. When a Solicitation is received, an Advertisement is sent in 333 response with a random delay less than MAX_RESPONSE_DELAY. If a 334 Solicitation is received while an Advertisement is pending, that 335 Solicitation MUST be ignored. 337 Changes in the Query Interval or Robustness Variable MUST NOT trigger 338 a new advertisement, however the new values MUST be used all future 339 Advertisement messages. 341 When an Advertisement is sent, the periodic advertisement interval 342 timer MUST be reset. 344 3.5 Receiving Multicast Router Advertisements 346 Upon receiving an Advertisement message, devices validate the message 347 with the following criteria: 349 1. The checksum is correct 351 2. The IP destination address is equal to the All-Snoopers multicast 352 address 354 3. For IPv6, the IP source address is a link-local address 356 An Advertisement not meeting the validity requirements MUST be 357 silently discarded and may be logged in a rate-limited manner. 359 If an Advertisement is not received for a particular neighbor within 360 a NeighborDeadInterval time interval, then the neighbor is considered 361 unreachable. 363 4. Multicast Router Solicitation 365 Multicast Router Solicitation messages are used to solicit 366 Advertisements from multicast routers on a segment. These messages 367 are used when a device wishes to discover multicast routers. Upon 368 receiving a solicitation on an interface with IP multicast forwarding 369 and MRD enabled, a router will respond with an Advertisement. 371 Solicitations may be sent when: 373 1. An interface is (re-)initialized 375 2. MRD is enabled 377 Solicitations are sent to the All-Routers multicast address and 378 SHOULD be rate-limited. 380 4.1 Solicitation Packet Format 382 The Solicitation message has the following format: 384 0 1 2 3 385 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 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | Type | Reserved | Checksum | 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 4.1.1 Type Field 392 The Type field identifies the message as a Solicitation. It is set 393 to Y1 (to be assigned by IANA) for IPv4 and Y2 (to be assigned by 394 IANA) for IPv6. 396 4.1.2 Reserved Field 398 The Reserved field is set to 0 on transmission and ignored on 399 reception. 401 4.1.3 Checksum Field 403 The checksum field is set as follows: 405 o For IPv4 it is the 16-bit one's complement of the one's complement 406 sum of the IGMP message, starting with the Type field. For 407 computing the checksum, the checksum field is set to 0. 409 o For IPv6 it is ICMPv6 checksum as specified in [6]. 411 4.2 IP Header Fields 413 4.2.1 Source Address 415 The IP source address is set to an IP address configured on the 416 soliciting interface. For IPv6, a link-local address MUST be used. 418 4.2.2 Destination Address 420 The IP destination address is set to the All-Routers multicast 421 address. 423 4.2.3 Time-to-Live / Hop Limit 425 The IPv4 TTL and IPv6 Hop Limit are set to 1. 427 4.2.4 IPv4 Protocol 429 The IPv4 Protocol field is set to IGMP (2). 431 4.3 Sending Multicast Router Solicitations 433 Solicitation messages are sent when the following events occur: 435 o After waiting for a random delay less than MAX_SOLICITATION_DELAY 436 when an interface first becomes operational, is (re-)initialized, 437 or MRD is enabled. A device may send up to a maximum of 438 MAX_SOLICITATIONS, waiting for a random delay less than 439 MAX_SOLICITATION_DELAY between each solicitation. 441 o Optionally, for an implementation specific event. 443 Solicitations MUST be rate-limited; the implementation MUST send no 444 more than MAX_SOLICITATIONS in MAX_SOLICITATION_DELAY seconds. 446 4.4 Receiving Multicast Router Solicitations 448 A Solicitation message MUST be validated before a response is sent. 449 A router MUST verify that: 451 o The checksum is correct 453 o The IP destination address is the All-Routers multicast address 455 o For IPv6, the IP source address MUST be a link-local address 457 Solicitations not meeting the validity requirements SHOULD be 458 silently discarded and may be logged in a rate-limited manner. 460 5. Multicast Router Termination 462 The Multicast Router Termination message is used to expedite the 463 notification of a change in the status of a router's multicast 464 forwarding functions. Multicast routers send Terminations when 465 multicast forwarding is disabled on the advertising interface. 467 5.1 Termination Packet Format 469 The Termination message has the following format: 471 0 1 2 3 472 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 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 | Type | Reserved | Checksum | 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 5.1.1 Type Field 479 The Type field identifies the message as a Termination. It is set to 480 Z1 (to be assigned by IANA) for IPv4 and Z2 (to be assigned by IANA) 481 for IPv6. 483 5.1.2 Reserved Field 485 The Reserved field is set to 0 on transmission and ignored on 486 reception. 488 5.1.3 Checksum Field 490 The checksum field is set as follows: 492 o For IPv4 it is the 16-bit one's complement of the one's complement 493 sum of the IGMP message, starting with the Type field. For 494 computing the checksum, the checksum field is set to 0. 496 o For IPv6 it is ICMPv6 checksum as specified in [6]. 498 5.2 IP Header Fields 500 5.2.1 Source Address 502 The IP source address is set to an IP address configured on the 503 advertising interface. For IPv6, a link-local address MUST be used. 505 5.2.2 Destination Address 507 The IP destination address is set to the All-Snoopers multicast 508 address. 510 5.2.3 Time-to-Live / Hop Limit 512 The IPv4 TTL and IPv6 Hop Limit are set to 1. 514 5.2.4 IPv4 Protocol 516 The IPv4 Protocol field is set to IGMP (2). 518 5.3 Sending Multicast Router Terminations 520 Termination messages are sent by multicast routers when: 522 o Multicast forwarding is disabled on an interface 524 o An interface is administratively disabled 526 o The router is gracefully shutdown 528 o MRD is disabled 530 The sending of Termination messages SHOULD be rate-limited. 532 5.4 Receiving Multicast Router Terminations 534 Upon receiving a Termination message, devices validate the message. 535 The validation criteria is: 537 o Checksum MUST be correct 539 o IP destination address MUST equal the All-Snoopers multicast 540 address 542 o For IPv6, the IP source address MUST be a link-local address 544 Termination messages not meeting the validity requirements MUST be 545 silently discarded and may be logged in a rate-limited manner. 547 If the message passes these validation steps, a Solicitation is sent. 548 If an Advertisement is not received within NeighborDeadInterval, the 549 sending router is removed from the list of active multicast routers. 551 6. Protocol Constants 553 The following list identifies constants used in the MRD protocol. 554 These constants are used in the calculation of parameters. 556 o MAX_RESPONSE_DELAY 2 seconds 558 o MAX_SOLICITATION_DELAY 1 second 560 o MAX_SOLICITATIONS 3 transmissions 562 7. Security Considerations 564 Rogue nodes may attempt to attack a network running MRD by sending 565 spoofed Advertisement, Solicitation, or Termination messages. Each 566 type of spoofed message can be dealt with using existing technology. 568 A rogue node may attempt to interrupt multicast service by sending 569 spoofed Termination messages. As described in Section 5.4, all 570 Termination messages are validated by sending a Solicitation message. 571 By sending a Solicitation, the node will force the transmission of an 572 Advertisement by an active router. 574 Spoofed Solicitation messages do not cause any operational harm. 575 They may be used as a flooding mechanism to attack a multicast 576 router. This attack can be mitigated through the rate-limiting 577 recommendation for all MRD messages. 579 The Multicast Router Advertisement message may allow rogue machines 580 to masquerade as multicast routers. This could allow those machines 581 to eavesdrop on multicast data transmissions. Additionally, it could 582 constitute a denial of service attack to other hosts in the same 583 snooping domain or sharing the same device port in the presence of 584 high rate multicast flows. 586 The technology available in SEND[10] can be utilized to address 587 spoofed Advertisement messages in IPv6 networks. IPv6 Multicast 588 routers in an MRD-enabled network can use SEND-based link-local 589 addresses as the IPv6 source address for MRD messages. When a switch 590 receives an initial Advertisement, it can use the information in the 591 SEND-based address to challenge the router to authenticate itself. 592 It should be noted that this approach only applies to IPv6 networks. 594 Another solution which supports both IPv4 and IPv6 is to use IPSec in 595 Authentication Header mode[11] to protect against attacks by ensuring 596 that messages came from a system with the proper key. When using 597 IPSEC, the messages sent to the All-Snoopers address should be 598 authenticated using AH. For keying, a symmetric signature algorithm 599 with a single key for routers sending Advertisements. This allows 600 validation that the MRD message was sent by a system with the key. 601 It should be noted that this does not prevent a system with the key 602 from forging a message and it requires the disabling of IPSec's 603 Replay Protection. 605 8. IANA Considerations 607 This document introduces three new IGMP messages. Each of these 608 messages requires a new IGMP Type value. This document requests IANA 609 to assign three new IGMP Type values to the Multicast Router 610 Discovery Protocol: 612 +-----------+---------------+--------------------------------+ 613 | IGMP Type | Section | Message Name | 614 +-----------+---------------+--------------------------------+ 615 | X1 | Section 3.2.1 | Multicast Router Advertisement | 616 | Y1 | Section 4.1.1 | Multicast Router Solicitation | 617 | Z1 | Section 5.1.1 | Multicast Router Termination | 618 +-----------+---------------+--------------------------------+ 620 This document also introduces three new MLD messages. Each of these 621 messages requires a new ICMPv6 Type value. This document requests 622 IANA to assign three new ICMPv6 Type values from the Informational 623 range: 625 +-------------+---------------+--------------------------------+ 626 | ICMPv6 Type | Section | Message Name | 627 +-------------+---------------+--------------------------------+ 628 | X2 | Section 3.2.1 | Multicast Router Advertisement | 629 | Y2 | Section 4.1.1 | Multicast Router Solicitation | 630 | Z2 | Section 5.1.1 | Multicast Router Termination | 631 +-------------+---------------+--------------------------------+ 633 This document also requires the assignment of an All-Snoopers 634 multicast address for IPv4. This multicast address should be in the 635 224.0.0/24 range since it is used for link-local, control messages. 636 A corresponding IPv6 multicast address is also requested. Following 637 the guidelines in [12], the IPv6 multicast address should be 638 link-local in scope and have a group-ID value equal to the low order 639 8 bits of the requested IPv4 multicast address. 641 9. Authors 643 Brad Cain and Shantam Biswis are the authors of the original 644 Multicast Router Discovery proposal. 646 10. Acknowledgements 648 ICMP Router Discovery [13] was used as a general model for Multicast 649 Router Discovery. 651 Morten Christensen, Pekka Savola, Hugh Holbrook, and Isidor Kouvelas 652 provided helpful feedback on various versions of this document. 654 11. References 656 11.1 Normative References 658 [1] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 659 1112, August 1989. 661 [2] Fenner, W., "Internet Group Management Protocol, Version 2", 662 RFC 2236, November 1997. 664 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 665 Levels", BCP 14, RFC 2119, March 1997. 667 [4] Katz, D., "IP Router Alert Option", RFC 2113, February 1997. 669 [5] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", RFC 670 2711, October 1999. 672 [6] Conta, A. and S. Deering, "Internet Control Message Protocol 673 (ICMPv6) for the Internet Protocol Version 6 (IPv6) 674 Specification", RFC 2463, December 1998. 676 [7] Cain, B., Deering, S., Kouvelas, I., Fenner, B. and A. 677 Thyagarajan, "Internet Group Management Protocol, Version 3", 678 RFC 3376, October 2002. 680 [8] Deering, S., Fenner, W. and B. Haberman, "Multicast Listener 681 Discovery (MLD) for IPv6", RFC 2710, October 1999. 683 [9] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 684 (MLDv2) for IPv6", RFC 3810, June 2004. 686 [10] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P. Nikander, 687 "SEcure Neighbor Discovery (SEND)", draft-ietf-send-ndopt-06 688 (work in progress), July 2004. 690 [11] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, 691 November 1998. 693 [12] Haberman, B., "Allocation Guidelines for IPv6 Multicast 694 Addresses", RFC 3307, August 2002. 696 11.2 Informative References 698 [13] Deering, S., "ICMP Router Discovery Messages", RFC 1256, 699 September 1991. 701 [14] Bradner, S., "Intellectual Property Rights in IETF Technology", 702 BCP 79, RFC 3668, February 2004. 704 [15] Daigle, L. and Internet Architecture Board, "IETF ISOC Board of 705 Trustee Appointment Procedures", BCP 77, RFC 3677, December 706 2003. 708 Authors' Addresses 710 Brian Haberman 711 Johns Hopkins University Applied Physics Lab 712 11100 Johns Hopkins Road 713 Laurel, MD 20723-6099 714 US 716 Phone: +1 443 778 1319 717 EMail: brian@innovationslab.net 719 Jim Martin 720 Netzwert AG 721 An den Treptowers 1 722 D-12435 Berlin 723 Germany 725 Phone: +49.30/5 900 800-180 726 EMail: jim@netzwert.ag 728 Intellectual Property Statement 730 The IETF takes no position regarding the validity or scope of any 731 Intellectual Property Rights or other rights that might be claimed to 732 pertain to the implementation or use of the technology described in 733 this document or the extent to which any license under such rights 734 might or might not be available; nor does it represent that it has 735 made any independent effort to identify any such rights. Information 736 on the procedures with respect to rights in RFC documents can be 737 found in BCP 78 and BCP 79. 739 Copies of IPR disclosures made to the IETF Secretariat and any 740 assurances of licenses to be made available, or the result of an 741 attempt made to obtain a general license or permission for the use of 742 such proprietary rights by implementers or users of this 743 specification can be obtained from the IETF on-line IPR repository at 744 http://www.ietf.org/ipr. 746 The IETF invites any interested party to bring to its attention any 747 copyrights, patents or patent applications, or other proprietary 748 rights that may cover technology that may be required to implement 749 this standard. Please address the information to the IETF at 750 ietf-ipr@ietf.org. 752 Disclaimer of Validity 754 This document and the information contained herein are provided on an 755 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 756 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 757 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 758 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 759 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 760 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 762 Copyright Statement 764 Copyright (C) The Internet Society (2004). This document is subject 765 to the rights, licenses and restrictions contained in BCP 78, and 766 except as set forth therein, the authors retain all their rights. 768 Acknowledgment 770 Funding for the RFC Editor function is currently provided by the 771 Internet Society.