idnits 2.17.1 draft-ietf-magma-mrdisc-04.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 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 780. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 757. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 764. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 770. ** 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 (February 20, 2005) is 6999 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: 7 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MAGMA WG B. Haberman 3 Internet-Draft JHU APL 4 Expires: August 24, 2005 J. Martin 5 Netzwert AG 6 February 20, 2005 8 Multicast Router Discovery 9 draft-ietf-magma-mrdisc-04 11 Status of this Memo 13 This document is an Internet-Draft and is subject to all provisions 14 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 15 author represents that any applicable patent or other IPR claims of 16 which he or she is aware have been or will be disclosed, and any of 17 which he or she become aware will be disclosed, in accordance with 18 RFC 3668. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as 23 Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on August 24, 2005. 38 Copyright Notice 40 Copyright (C) The Internet Society (2005). 42 Abstract 44 The concept of Internet Group Membership Protocol (IGMP) and 45 Multicast Listener Discovery (MLD) snooping requires the ability to 46 identify the location of multicast routers. Since snooping is not 47 standardized, there are many mechanisms in use to identify the 48 multicast routers. However, this can lead to interoperability issues 49 between multicast routers and snooping switches from different 50 vendors. 52 This document introduces a general mechanism that allows for the 53 discovery of multicast routers. This new mechanism, Multicast Router 54 Discovery (MRD), introduces a standardized means of identifying 55 multicast routers without a dependency on particular multicast 56 routing protocols. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Multicast Router Advertisement . . . . . . . . . . . . . . . . 5 63 3.1 Advertisement Configuration Variables . . . . . . . . . . 5 64 3.1.1 MaxAdvertisementInterval . . . . . . . . . . . . . . . 5 65 3.1.2 MinAdvertisementInterval . . . . . . . . . . . . . . . 5 66 3.1.3 MaxInitialAdvertisementInterval . . . . . . . . . . . 6 67 3.1.4 MaxInitialAdvertisements . . . . . . . . . . . . . . . 6 68 3.1.5 NeighborDeadInterval . . . . . . . . . . . . . . . . . 6 69 3.1.6 MaxMessageRate . . . . . . . . . . . . . . . . . . . . 6 70 3.2 Advertisement Packet Format . . . . . . . . . . . . . . . 6 71 3.2.1 Type Field . . . . . . . . . . . . . . . . . . . . . . 7 72 3.2.2 Advertisement Interval Field . . . . . . . . . . . . . 7 73 3.2.3 Checksum Field . . . . . . . . . . . . . . . . . . . . 7 74 3.2.4 Query Interval Field . . . . . . . . . . . . . . . . . 7 75 3.2.5 Robustness Variable Field . . . . . . . . . . . . . . 7 76 3.3 IP Header Fields . . . . . . . . . . . . . . . . . . . . . 8 77 3.3.1 Source Address . . . . . . . . . . . . . . . . . . . . 8 78 3.3.2 Destination Address . . . . . . . . . . . . . . . . . 8 79 3.3.3 Time-to-Live / Hop Limit . . . . . . . . . . . . . . . 8 80 3.3.4 IPv4 Protocol . . . . . . . . . . . . . . . . . . . . 8 81 3.3.5 IPv6 Next Header . . . . . . . . . . . . . . . . . . . 8 82 3.4 Sending Multicast Router Advertisements . . . . . . . . . 8 83 3.5 Receiving Multicast Router Advertisements . . . . . . . . 9 84 4. Multicast Router Solicitation . . . . . . . . . . . . . . . . 9 85 4.1 Solicitation Packet Format . . . . . . . . . . . . . . . . 9 86 4.1.1 Type Field . . . . . . . . . . . . . . . . . . . . . . 10 87 4.1.2 Reserved Field . . . . . . . . . . . . . . . . . . . . 10 88 4.1.3 Checksum Field . . . . . . . . . . . . . . . . . . . . 10 89 4.2 IP Header Fields . . . . . . . . . . . . . . . . . . . . . 10 90 4.2.1 Source Address . . . . . . . . . . . . . . . . . . . . 10 91 4.2.2 Destination Address . . . . . . . . . . . . . . . . . 10 92 4.2.3 Time-to-Live / Hop Limit . . . . . . . . . . . . . . . 10 93 4.2.4 IPv4 Protocol . . . . . . . . . . . . . . . . . . . . 10 94 4.3 Sending Multicast Router Solicitations . . . . . . . . . . 11 95 4.4 Receiving Multicast Router Solicitations . . . . . . . . . 11 96 5. Multicast Router Termination . . . . . . . . . . . . . . . . . 11 97 5.1 Termination Packet Format . . . . . . . . . . . . . . . . 11 98 5.1.1 Type Field . . . . . . . . . . . . . . . . . . . . . . 12 99 5.1.2 Reserved Field . . . . . . . . . . . . . . . . . . . . 12 100 5.1.3 Checksum Field . . . . . . . . . . . . . . . . . . . . 12 101 5.2 IP Header Fields . . . . . . . . . . . . . . . . . . . . . 12 102 5.2.1 Source Address . . . . . . . . . . . . . . . . . . . . 12 103 5.2.2 Destination Address . . . . . . . . . . . . . . . . . 12 104 5.2.3 Time-to-Live / Hop Limit . . . . . . . . . . . . . . . 12 105 5.2.4 IPv4 Protocol . . . . . . . . . . . . . . . . . . . . 12 106 5.3 Sending Multicast Router Terminations . . . . . . . . . . 12 107 5.4 Receiving Multicast Router Terminations . . . . . . . . . 13 108 6. Protocol Constants . . . . . . . . . . . . . . . . . . . . . . 13 109 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 110 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 111 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 112 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 113 10.1 Normative References . . . . . . . . . . . . . . . . . . . 15 114 10.2 Informative References . . . . . . . . . . . . . . . . . . 16 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17 116 Intellectual Property and Copyright Statements . . . . . . . . 18 118 1. Introduction 120 Multicast Router Discovery messages are useful for determining which 121 nodes attached to a switch have multicast routing enabled. This 122 capability is useful in a layer-2 bridging domain with snooping 123 switches. By utilizing MRD messages, layer-2 switches can determine 124 where to send multicast source data and group membership 125 messages[1][2]. Multicast source data and group membership Reports 126 must be received by all multicast routers on a segment. Using the 127 group membership protocol Query messages to discover multicast 128 routers is insufficient due to query suppression. 130 Although MRD messages could be sent as ICMP messages, the group 131 management protocols were chosen since this functionality is 132 multicast specific. The addition of this functionality to the group 133 membership protocol also allows operators to have congruency between 134 multicast router discovery problems and data forwarding issues. 136 The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 137 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 138 "OPTIONAL" in this document are to be interpreted as described in 139 [3]. 141 2. Protocol Overview 143 Multicast Router Discovery consists of three messages for discovering 144 multicast routers. The Multicast Router Advertisement is sent by 145 routers to advertise that IP multicast forwarding is enabled. 146 Devices may send Multicast Router Solicitation messages in order to 147 solicit Advertisement messages from multicast routers. The Multicast 148 Router Termination messages are sent when a router stops IP multicast 149 routing functions on an interface. 151 Multicast routers send unsolicited Advertisements periodically on all 152 interfaces on which multicast forwarding is enabled. Advertisement 153 messages are also sent in response to Solicitations. In addition to 154 advertising the location of multicast routers, Advertisements also 155 convey useful information concerning group management protocol 156 variables. This information can be used for consistency checking on 157 the subnet. 159 A device sends Solicitation messages whenever it wishes to discover 160 multicast routers on a directly attached link. 162 A router sends Termination messages when it terminates multicast 163 routing functionality on an interface. 165 All MRD messages are sent with an IPv4 TTL or IPv6 Hop Limit of 1 and 166 contain the Router Alert Option[4][5]. All MRD messages SHOULD be 167 rate-limited as per the MaxMessageRate variable. 169 Advertisement and Termination messages are sent to the All-Snoopers 170 multicast address. 172 Solicitation messages are sent to the All-Routers multicast address. 174 Any data beyond the fixed message format MUST be ignored. 176 3. Multicast Router Advertisement 178 Multicast Router Advertisements are sent unsolicited periodically on 179 all router interfaces on which multicast forwarding is enabled. They 180 are also sent in response to Multicast Router Solicitation messages. 182 Advertisements are sent 184 1. Upon the expiration of a periodic (modulo randomization) timer 186 2. As a part of a router's start up procedure 188 3. During the restart of a multicast forwarding interface 190 4. On receipt of a Solicitation message 192 All Advertisements are sent as IGMP (for IPv4) or MLD (for IPv6) 193 messages to the All-Snoopers multicast address. These messages 194 SHOULD be rate-limited as per the MaxMessageRate variable. 196 3.1 Advertisement Configuration Variables 198 An MRD implementation MUST support the following variables being 199 configured by system management. Default values are specified to 200 make it unnecessary to configure any of these variables in many 201 cases. 203 3.1.1 MaxAdvertisementInterval 205 This variable is the maximum time (in seconds) allowed between the 206 transmissions of unsolicited Advertisements on an interface. This 207 value MUST be no less than 4 seconds and no greater than 180 seconds. 209 Default: 20 seconds 211 3.1.2 MinAdvertisementInterval 213 This is the minimum time (in seconds) allowed between the 214 transmissions of unsolicited Advertisements on an interface. This 215 value MUST be no less than 3 seconds and no greater than 216 MaxAdvertisementInterval. 218 Default: 0.75 * MaxAdvertisementInterval 220 3.1.3 MaxInitialAdvertisementInterval 222 The first unsolicited Advertisement transmitted on an interface is 223 sent after waiting a random interval (in seconds) less than this 224 variable. This prevents a flood of Advertisements when multiple 225 routers start up at the same time. 227 Default: 2 seconds 229 3.1.4 MaxInitialAdvertisements 231 This variable is the maximum number of unsolicited Advertisements 232 that will be transmitted by the advertising interface when MRD starts 233 up. 235 Default: 3 237 3.1.5 NeighborDeadInterval 239 The NeighborDeadInterval variable is the maximum time (in seconds) 240 allowed to elapse (after receipt of the last valid Advertisement) 241 before a neighboring router is declared unreachable. This variable 242 is maintained per neighbor. An MRD receiver should set the 243 NeighborDeadInterval to 3 times the Advertisement Interval Field 244 received. This ensures consistant behavior between multiple devices 245 on a network. 247 Default (sender): 3 * MaxAdvertisementInterval 249 Default (received): 3 * Advertisement Interval Field 251 3.1.6 MaxMessageRate 253 The MaxMessageRate variable is the maximum aggregate number of 254 messages per second per interface or per loggind destination that an 255 MRD implementation SHOULD send. 257 Default: 10 259 3.2 Advertisement Packet Format 261 The Advertisement message has the following format: 263 0 1 2 3 264 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 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | Type | Ad. Interval | Checksum | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | Query Interval | Robustness Variable | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 3.2.1 Type Field 273 The Type field identifies the message as an Advertisement. It is set 274 to X1 (to be assigned by IANA) for IPv4 and X2 (to be assigned by 275 IANA) for IPv6. 277 3.2.2 Advertisement Interval Field 279 This field specifies the periodic time interval at which unsolicited 280 Advertisement messages are transmitted in units of seconds. This 281 value is set to the configured MaxAdvertisementInterval variable. 283 3.2.3 Checksum Field 285 The checksum field is set as follows: 287 1. For IPv4 it is the 16-bit one's complement of the one's 288 complement sum of the IGMP message, starting with the Type field. 289 For computing the checksum, the checksum field is set to 0. 291 2. For IPv6 it is ICMPv6 checksum as specified in [6]. 293 3.2.4 Query Interval Field 295 The Query Interval field is set to the Query Interval value (in 296 seconds) in use by IGMP or MLD on the interface. If IGMP or MLD is 297 not enabled on the advertising interface, this field MUST be set to 298 0. Note that this is the Querier's Query Interval (QQI), not the 299 Querier's Query Interval Code (QQIC) as specified in the IGMP/MLD 300 specifications. 302 3.2.5 Robustness Variable Field 304 This field is set to the Robustness Variable in use by IGMPv2[2], 305 IGMPv3[7], or MLD[8][9] on the advertising interface. If IGMPv1 is 306 in use or no group management protocol is enabled on the interface, 307 this field MUST be set to 0. 309 3.3 IP Header Fields 311 3.3.1 Source Address 313 The IP source address is set to an IP address configured on the 314 advertising interface. For IPv6, a link-local address MUST be used. 316 3.3.2 Destination Address 318 The IP destination address is set to the All-Snoopers multicast 319 address. 321 3.3.3 Time-to-Live / Hop Limit 323 The IPv4 TTL and IPv6 Hop Limit are set to 1. 325 3.3.4 IPv4 Protocol 327 The IPv4 Protocol field is set to IGMP (2). 329 3.3.5 IPv6 Next Header 331 The ICMPv6 header is identified by a Next Header value of 58 in the 332 immediately preceding header.[6] 334 3.4 Sending Multicast Router Advertisements 336 Advertisement messages are sent when the following events occur: 338 1. The expiration of the periodic advertisement interval timer. 339 Note that it this timer is not strictly periodic since it is a 340 random number between MaxAdvertisementInterval and 341 MinAdvertisementInterval. 343 2. After a random delay less than MaxInitialAdvertisementInterval 344 when an interface is first enabled, is (re-)initialized, or MRD 345 is enabled. A router may send up to a maximum of 346 MaxInitialAdvertisements Advertisements, waiting for a random 347 delay less than MaxInitialAdvertisementInterval between each 348 successive message. Multiple Advertisements are sent for 349 robustness in the face of packet loss on the network. 351 This is to prevent an implosion of Advertisements. An example of 352 this occurring would be when many routers are powered on at the same 353 time. When a Solicitation is received, an Advertisement is sent in 354 response with a random delay less than MAX_RESPONSE_DELAY. If a 355 Solicitation is received while an Advertisement is pending, that 356 Solicitation MUST be ignored. 358 Changes in the Query Interval or Robustness Variable MUST NOT trigger 359 a new advertisement, however the new values MUST be used all future 360 Advertisement messages. 362 When an Advertisement is sent, the periodic advertisement interval 363 timer MUST be reset. 365 3.5 Receiving Multicast Router Advertisements 367 Upon receiving an Advertisement message, devices validate the message 368 with the following criteria: 370 1. The checksum is correct 372 2. The IP destination address is equal to the All-Snoopers multicast 373 address 375 3. For IPv6, the IP source address is a link-local address 377 An Advertisement not meeting the validity requirements MUST be 378 silently discarded and may be logged in a rate-limited manner as per 379 the MaxMessageRate variable. 381 If an Advertisement is not received for a particular neighbor within 382 a NeighborDeadInterval time interval, then the neighbor is considered 383 unreachable. 385 4. Multicast Router Solicitation 387 Multicast Router Solicitation messages are used to solicit 388 Advertisements from multicast routers on a segment. These messages 389 are used when a device wishes to discover multicast routers. Upon 390 receiving a solicitation on an interface with IP multicast forwarding 391 and MRD enabled, a router will respond with an Advertisement. 393 Solicitations may be sent when: 395 1. An interface is (re-)initialized 397 2. MRD is enabled 399 Solicitations are sent to the All-Routers multicast address and 400 SHOULD be rate-limited as per the MaxMessageRate variable. 402 4.1 Solicitation Packet Format 404 The Solicitation message has the following format: 406 0 1 2 3 407 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 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | Type | Reserved | Checksum | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 4.1.1 Type Field 414 The Type field identifies the message as a Solicitation. It is set 415 to Y1 (to be assigned by IANA) for IPv4 and Y2 (to be assigned by 416 IANA) for IPv6. 418 4.1.2 Reserved Field 420 The Reserved field is set to 0 on transmission and ignored on 421 reception. 423 4.1.3 Checksum Field 425 The checksum field is set as follows: 427 o For IPv4 it is the 16-bit one's complement of the one's complement 428 sum of the IGMP message, starting with the Type field. For 429 computing the checksum, the checksum field is set to 0. 431 o For IPv6 it is ICMPv6 checksum as specified in [6]. 433 4.2 IP Header Fields 435 4.2.1 Source Address 437 The IP source address is set to an IP address configured on the 438 soliciting interface. For IPv6, a link-local address MUST be used. 440 4.2.2 Destination Address 442 The IP destination address is set to the All-Routers multicast 443 address. 445 4.2.3 Time-to-Live / Hop Limit 447 The IPv4 TTL and IPv6 Hop Limit are set to 1. 449 4.2.4 IPv4 Protocol 451 The IPv4 Protocol field is set to IGMP (2). 453 4.3 Sending Multicast Router Solicitations 455 Solicitation messages are sent when the following events occur: 457 o After waiting for a random delay less than MAX_SOLICITATION_DELAY 458 when an interface first becomes operational, is (re-)initialized, 459 or MRD is enabled. A device may send up to a maximum of 460 MAX_SOLICITATIONS, waiting for a random delay less than 461 MAX_SOLICITATION_DELAY between each solicitation. 463 o Optionally, for an implementation specific event. 465 Solicitations MUST be rate-limited as per the MaxMessageRate 466 variable; the implementation MUST send no more than MAX_SOLICITATIONS 467 in MAX_SOLICITATION_DELAY seconds. 469 4.4 Receiving Multicast Router Solicitations 471 A Solicitation message MUST be validated before a response is sent. 472 A router MUST verify that: 474 o The checksum is correct 476 o The IP destination address is the All-Routers multicast address 478 o For IPv6, the IP source address MUST be a link-local address 480 Solicitations not meeting the validity requirements SHOULD be 481 silently discarded and may be logged in a rate-limited manner as per 482 the MaxMessageRate variable. 484 5. Multicast Router Termination 486 The Multicast Router Termination message is used to expedite the 487 notification of a change in the status of a router's multicast 488 forwarding functions. Multicast routers send Terminations when 489 multicast forwarding is disabled on the advertising interface. 491 5.1 Termination Packet Format 493 The Termination message has the following format: 495 0 1 2 3 496 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 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 | Type | Reserved | Checksum | 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 5.1.1 Type Field 503 The Type field identifies the message as a Termination. It is set to 504 Z1 (to be assigned by IANA) for IPv4 and Z2 (to be assigned by IANA) 505 for IPv6. 507 5.1.2 Reserved Field 509 The Reserved field is set to 0 on transmission and ignored on 510 reception. 512 5.1.3 Checksum Field 514 The checksum field is set as follows: 516 o For IPv4 it is the 16-bit one's complement of the one's complement 517 sum of the IGMP message, starting with the Type field. For 518 computing the checksum, the checksum field is set to 0. 520 o For IPv6 it is ICMPv6 checksum as specified in [6]. 522 5.2 IP Header Fields 524 5.2.1 Source Address 526 The IP source address is set to an IP address configured on the 527 advertising interface. For IPv6, a link-local address MUST be used. 529 5.2.2 Destination Address 531 The IP destination address is set to the All-Snoopers multicast 532 address. 534 5.2.3 Time-to-Live / Hop Limit 536 The IPv4 TTL and IPv6 Hop Limit are set to 1. 538 5.2.4 IPv4 Protocol 540 The IPv4 Protocol field is set to IGMP (2). 542 5.3 Sending Multicast Router Terminations 544 Termination messages are sent by multicast routers when: 546 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 Rogue nodes may attempt to attack a network running MRD by sending 590 spoofed Advertisement, Solicitation, or Termination messages. Each 591 type of spoofed message can be dealt with using existing technology. 593 A rogue node may attempt to interrupt multicast service by sending 594 spoofed Termination messages. As described in Section 5.4, all 595 Termination messages are validated by sending a Solicitation message. 596 By sending a Solicitation, the node will force the transmission of an 597 Advertisement by an active router. 599 Spoofed Solicitation messages do not cause any operational harm. 600 They may be used as a flooding mechanism to attack a multicast 601 router. This attack can be mitigated through the rate-limiting 602 recommendation for all MRD messages. 604 The Multicast Router Advertisement message may allow rogue machines 605 to masquerade as multicast routers. This could allow those machines 606 to eavesdrop on multicast data transmissions. Additionally, it could 607 constitute a denial of service attack to other hosts in the same 608 snooping domain or sharing the same device port in the presence of 609 high rate multicast flows. 611 The technology available in SEND[10] can be utilized to address 612 spoofed Advertisement messages in IPv6 networks. IPv6 Multicast 613 routers in an MRD-enabled network can use SEND-based link-local 614 addresses as the IPv6 source address for MRD messages. When a switch 615 receives an initial Advertisement, it can use the information in the 616 SEND-based address to challenge the router to authenticate itself. 617 It should be noted that this approach only applies to IPv6 networks. 619 Another solution which supports both IPv4 and IPv6 is to use IPsec in 620 Encapsulating Security Payload (ESP) mode[11] to protect against 621 attacks by ensuring that messages came from a system with the proper 622 key. When using IPsec, the messages sent to the All-Snoopers address 623 should be authenticated using ESP. Should encryption not be desired, 624 ESP with a null encryption algorithm and a symmetric authentication 625 algorithm, such as HMAC-SHA-1, is viable. For keying, a symmetric 626 signature algorithm with a single manually configured key is used for 627 routers sending Advertisements. This allows validation that the MRD 628 message was sent by a system with the key. It should be noted that 629 this does not prevent a system with the key from forging a message 630 and it requires the disabling of IPsec's Replay Protection. It is 631 the responsibility of the network administrator to ensure that the 632 same key is present on all possible MRD participants. 634 8. IANA Considerations 636 This document introduces three new IGMP messages. Each of these 637 messages requires a new IGMP Type value. This document requests IANA 638 to assign three new IGMP Type values to the Multicast Router 639 Discovery Protocol: 641 +-----------+---------------+--------------------------------+ 642 | IGMP Type | Section | Message Name | 643 +-----------+---------------+--------------------------------+ 644 | X1 | Section 3.2.1 | Multicast Router Advertisement | 645 | Y1 | Section 4.1.1 | Multicast Router Solicitation | 646 | Z1 | Section 5.1.1 | Multicast Router Termination | 647 +-----------+---------------+--------------------------------+ 649 This document also introduces three new MLD messages. Each of these 650 messages requires a new ICMPv6 Type value. This document requests 651 IANA to assign three new ICMPv6 Type values from the Informational 652 range: 654 +-------------+---------------+--------------------------------+ 655 | ICMPv6 Type | Section | Message Name | 656 +-------------+---------------+--------------------------------+ 657 | X2 | Section 3.2.1 | Multicast Router Advertisement | 658 | Y2 | Section 4.1.1 | Multicast Router Solicitation | 659 | Z2 | Section 5.1.1 | Multicast Router Termination | 660 +-------------+---------------+--------------------------------+ 662 This document also requires the assignment of an All-Snoopers 663 multicast address for IPv4. This multicast address should be in the 664 224.0.0/24 range since it is used for link-local, control messages. 665 A corresponding IPv6 multicast address is also requested. Following 666 the guidelines in [12], the IPv6 multicast address should be 667 link-local in scope and have a group-ID value equal to the low order 668 8 bits of the requested IPv4 multicast address. 670 9. Acknowledgements 672 Brad Cain and Shantam Biswis are the authors of the original 673 Multicast Router Discovery proposal. 675 ICMP Router Discovery [13] was used as a general model for Multicast 676 Router Discovery. 678 Morten Christensen, Pekka Savola, Hugh Holbrook, and Isidor Kouvelas 679 provided helpful feedback on various versions of this document. 681 10. References 683 10.1 Normative References 685 [1] Deering, S., "Host extensions for IP multicasting", STD 5, 686 RFC 1112, August 1989. 688 [2] Fenner, W., "Internet Group Management Protocol, Version 2", 689 RFC 2236, November 1997. 691 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 692 Levels", BCP 14, RFC 2119, March 1997. 694 [4] Katz, D., "IP Router Alert Option", RFC 2113, February 1997. 696 [5] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", 697 RFC 2711, October 1999. 699 [6] Conta, A. and S. Deering, "Internet Control Message Protocol 700 (ICMPv6) for the Internet Protocol Version 6 (IPv6) 701 Specification", RFC 2463, December 1998. 703 [7] Cain, B., Deering, S., Kouvelas, I., Fenner, B. and A. 704 Thyagarajan, "Internet Group Management Protocol, Version 3", 705 RFC 3376, October 2002. 707 [8] Deering, S., Fenner, W. and B. Haberman, "Multicast Listener 708 Discovery (MLD) for IPv6", RFC 2710, October 1999. 710 [9] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 711 (MLDv2) for IPv6", RFC 3810, June 2004. 713 [10] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P. Nikander, 714 "SEcure Neighbor Discovery (SEND)", 715 Internet-Draft draft-ietf-send-ndopt-06, July 2004. 717 [11] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload 718 (ESP)", RFC 2406, November 1998. 720 [12] Haberman, B., "Allocation Guidelines for IPv6 Multicast 721 Addresses", RFC 3307, August 2002. 723 10.2 Informative References 725 [13] Deering, S., "ICMP Router Discovery Messages", RFC 1256, 726 September 1991. 728 Authors' Addresses 730 Brian Haberman 731 Johns Hopkins University Applied Physics Lab 732 11100 Johns Hopkins Road 733 Laurel, MD 20723-6099 734 US 736 Phone: +1 443 778 1319 737 Email: brian@innovationslab.net 739 Jim Martin 740 Netzwert AG 741 An den Treptowers 1 742 D-12435 Berlin 743 Germany 745 Phone: +49.30/5 900 800-180 746 Email: jim@netzwert.ag 748 Intellectual Property Statement 750 The IETF takes no position regarding the validity or scope of any 751 Intellectual Property Rights or other rights that might be claimed to 752 pertain to the implementation or use of the technology described in 753 this document or the extent to which any license under such rights 754 might or might not be available; nor does it represent that it has 755 made any independent effort to identify any such rights. Information 756 on the procedures with respect to rights in RFC documents can be 757 found in BCP 78 and BCP 79. 759 Copies of IPR disclosures made to the IETF Secretariat and any 760 assurances of licenses to be made available, or the result of an 761 attempt made to obtain a general license or permission for the use of 762 such proprietary rights by implementers or users of this 763 specification can be obtained from the IETF on-line IPR repository at 764 http://www.ietf.org/ipr. 766 The IETF invites any interested party to bring to its attention any 767 copyrights, patents or patent applications, or other proprietary 768 rights that may cover technology that may be required to implement 769 this standard. Please address the information to the IETF at 770 ietf-ipr@ietf.org. 772 Disclaimer of Validity 774 This document and the information contained herein are provided on an 775 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 776 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 777 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 778 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 779 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 780 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 782 Copyright Statement 784 Copyright (C) The Internet Society (2005). This document is subject 785 to the rights, licenses and restrictions contained in BCP 78, and 786 except as set forth therein, the authors retain all their rights. 788 Acknowledgment 790 Funding for the RFC Editor function is currently provided by the 791 Internet Society.