idnits 2.17.1 draft-ietf-magma-mrdisc-06.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 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 792. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 769. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 776. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 782. ** 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 2005) is 6951 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. -------------------------------------------------------------------------------- 2 MAGMA WG B. Haberman 3 Internet-Draft JHU APL 4 Expires: October 3, 2005 J. Martin 5 Netzwert AG 6 April 2005 8 Multicast Router Discovery 9 draft-ietf-magma-mrdisc-06 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on October 3, 2005. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 The concept of Internet Group Membership Protocol (IGMP) and 43 Multicast Listener Discovery (MLD) snooping requires the ability to 44 identify the location of multicast routers. Since snooping is not 45 standardized, there are many mechanisms in use to identify the 46 multicast routers. However, this can lead to interoperability issues 47 between multicast routers and snooping switches from different 48 vendors. 50 This document introduces a general mechanism that allows for the 51 discovery of multicast routers. This new mechanism, Multicast Router 52 Discovery (MRD), introduces a standardized means of identifying 53 multicast routers without a dependency on particular multicast 54 routing protocols. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Multicast Router Advertisement . . . . . . . . . . . . . . . . 5 61 3.1 Advertisement Configuration Variables . . . . . . . . . . 5 62 3.1.1 AdvertisementInterval . . . . . . . . . . . . . . . . 5 63 3.1.2 AdvertisementJitter . . . . . . . . . . . . . . . . . 5 64 3.1.3 MaxInitialAdvertisementInterval . . . . . . . . . . . 6 65 3.1.4 MaxInitialAdvertisements . . . . . . . . . . . . . . . 6 66 3.1.5 NeighborDeadInterval . . . . . . . . . . . . . . . . . 6 67 3.1.6 MaxMessageRate . . . . . . . . . . . . . . . . . . . . 6 68 3.2 Advertisement Packet Format . . . . . . . . . . . . . . . 7 69 3.2.1 Type Field . . . . . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . 8 74 3.3 IP Header Fields . . . . . . . . . . . . . . . . . . . . . 8 75 3.3.1 Source Address . . . . . . . . . . . . . . . . . . . . 8 76 3.3.2 Destination Address . . . . . . . . . . . . . . . . . 8 77 3.3.3 Time-to-Live / Hop Limit . . . . . . . . . . . . . . . 8 78 3.3.4 IPv4 Protocol . . . . . . . . . . . . . . . . . . . . 8 79 3.3.5 IPv6 Next Header . . . . . . . . . . . . . . . . . . . 8 80 3.4 Sending Multicast Router Advertisements . . . . . . . . . 8 81 3.5 Receiving Multicast Router Advertisements . . . . . . . . 9 82 4. Multicast Router Solicitation . . . . . . . . . . . . . . . . 9 83 4.1 Solicitation Packet Format . . . . . . . . . . . . . . . . 10 84 4.1.1 Type Field . . . . . . . . . . . . . . . . . . . . . . 10 85 4.1.2 Reserved Field . . . . . . . . . . . . . . . . . . . . 10 86 4.1.3 Checksum Field . . . . . . . . . . . . . . . . . . . . 10 87 4.2 IP Header Fields . . . . . . . . . . . . . . . . . . . . . 10 88 4.2.1 Source Address . . . . . . . . . . . . . . . . . . . . 10 89 4.2.2 Destination Address . . . . . . . . . . . . . . . . . 10 90 4.2.3 Time-to-Live / Hop Limit . . . . . . . . . . . . . . . 11 91 4.2.4 IPv4 Protocol . . . . . . . . . . . . . . . . . . . . 11 92 4.3 Sending Multicast Router Solicitations . . . . . . . . . . 11 93 4.4 Receiving Multicast Router Solicitations . . . . . . . . . 11 94 5. Multicast Router Termination . . . . . . . . . . . . . . . . . 11 95 5.1 Termination Packet Format . . . . . . . . . . . . . . . . 12 96 5.1.1 Type Field . . . . . . . . . . . . . . . . . . . . . . 12 97 5.1.2 Reserved Field . . . . . . . . . . . . . . . . . . . . 12 98 5.1.3 Checksum Field . . . . . . . . . . . . . . . . . . . . 12 99 5.2 IP Header Fields . . . . . . . . . . . . . . . . . . . . . 12 100 5.2.1 Source Address . . . . . . . . . . . . . . . . . . . . 12 101 5.2.2 Destination Address . . . . . . . . . . . . . . . . . 12 102 5.2.3 Time-to-Live / Hop Limit . . . . . . . . . . . . . . . 12 103 5.2.4 IPv4 Protocol . . . . . . . . . . . . . . . . . . . . 13 104 5.3 Sending Multicast Router Terminations . . . . . . . . . . 13 105 5.4 Receiving Multicast Router Terminations . . . . . . . . . 13 106 6. Protocol Constants . . . . . . . . . . . . . . . . . . . . . . 13 107 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 108 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 109 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 110 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 111 10.1 Normative References . . . . . . . . . . . . . . . . . . . 16 112 10.2 Informative References . . . . . . . . . . . . . . . . . . 17 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17 114 Intellectual Property and Copyright Statements . . . . . . . . 18 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 unsolicited Advertisements periodically on all 150 interfaces on which multicast forwarding is enabled. Advertisement 151 messages are also sent in response to Solicitations. In addition to 152 advertising the location of multicast routers, Advertisements also 153 convey useful information concerning group management protocol 154 variables. This information can be used for consistency checking on 155 the subnet. 157 A device sends Solicitation messages whenever it wishes to discover 158 multicast routers on a directly attached link. 160 A router sends Termination messages when it terminates multicast 161 routing functionality on an interface. 163 All MRD messages are sent with an IPv4 TTL or IPv6 Hop Limit of 1 and 164 contain the Router Alert Option[4][5]. All MRD messages SHOULD be 165 rate-limited as per the MaxMessageRate variable. 167 Advertisement and Termination messages are sent to the All-Snoopers 168 multicast address. 170 Solicitation messages are sent to the All-Routers multicast address. 172 Any data beyond the fixed message format MUST be ignored. 174 3. Multicast Router Advertisement 176 Multicast Router Advertisements are sent unsolicited periodically on 177 all router interfaces on which multicast forwarding is enabled. They 178 are also sent in response to Multicast Router Solicitation messages. 180 Advertisements are sent 182 1. Upon the expiration of a periodic (modulo randomization) timer 184 2. As a part of a router's start up procedure 186 3. During the restart of a multicast forwarding interface 188 4. On receipt of a Solicitation message 190 All Advertisements are sent as IGMP (for IPv4) or MLD (for IPv6) 191 messages to the All-Snoopers multicast address. These messages 192 SHOULD be rate-limited as per the MaxMessageRate variable. 194 3.1 Advertisement Configuration Variables 196 An MRD implementation MUST support the following variables being 197 configured by system management. Default values are specified to 198 make it unnecessary to configure any of these variables in many 199 cases. 201 3.1.1 AdvertisementInterval 203 This variable is the base interval (in seconds) between the 204 transmissions of unsolicited Advertisements on an interface. This 205 value MUST be no less than 4 seconds and no greater than 180 seconds. 207 Default: 20 seconds 209 3.1.2 AdvertisementJitter 211 This is the maximum time (in seconds) by which the 212 AdvertismentInterval is perturbed for each unsolicited Advertisment. 213 Note that the purpose of this jitter is to avoid synchronization of 214 multiple routers on a network, hence choosing a value of zero is 215 discouraged. This value MUST be no less than 0 seconds and no 216 greater than AdvertisementInterval. 218 Default: 0.025*AdvertisementInterval 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 * (AdvertisementInterval + AdvertisementJitter) 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 logical 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 AdvertisementInterval variable plus 282 the calculated AdvertisementJitter variable (i.e. Advertisement 283 Interval Field = AdvertisementInterval + AdvertisementJitter). 285 3.2.3 Checksum Field 287 The checksum field is set as follows: 289 1. For IPv4 it is the 16-bit one's complement of the one's 290 complement sum of the IGMP message, starting with the Type field. 291 For computing the checksum, the checksum field is set to 0. 293 2. For IPv6 it is ICMPv6 checksum as specified in [6]. 295 3.2.4 Query Interval Field 297 The Query Interval field is set to the Query Interval value (in 298 seconds) in use by IGMP or MLD on the interface. If IGMP or MLD is 299 not enabled on the advertising interface, this field MUST be set to 300 0. Note that this is the Querier's Query Interval (QQI), not the 301 Querier's Query Interval Code (QQIC) as specified in the IGMP/MLD 302 specifications. 304 3.2.5 Robustness Variable Field 306 This field is set to the Robustness Variable in use by IGMPv2[2], 307 IGMPv3[7], or MLD[8][9] on the advertising interface. If IGMPv1 is 308 in use or no group management protocol is enabled on the interface, 309 this field MUST be set to 0. 311 3.3 IP Header Fields 313 3.3.1 Source Address 315 The IP source address is set to an IP address configured on the 316 advertising interface. For IPv6, a link-local address MUST be used. 318 3.3.2 Destination Address 320 The IP destination address is set to the All-Snoopers multicast 321 address. 323 3.3.3 Time-to-Live / Hop Limit 325 The IPv4 TTL and IPv6 Hop Limit are set to 1. 327 3.3.4 IPv4 Protocol 329 The IPv4 Protocol field is set to IGMP (2). 331 3.3.5 IPv6 Next Header 333 The ICMPv6 header is identified by a Next Header value of 58 in the 334 immediately preceding header.[6] 336 3.4 Sending Multicast Router Advertisements 338 Advertisement messages are sent when the following events occur: 340 1. The expiration of the periodic advertisement interval timer. 341 Note that this timer is not strictly periodic since the base 342 AdvertismentInterval is varied each interval by a random value no 343 more than plus or minus AdvertisementJitter seconds. 345 2. After a random delay less than MaxInitialAdvertisementInterval 346 when an interface is first enabled, is (re-)initialized, or MRD 347 is enabled. A router may send up to a maximum of 348 MaxInitialAdvertisements Advertisements, waiting for a random 349 delay less than MaxInitialAdvertisementInterval between each 350 successive message. Multiple Advertisements are sent for 351 robustness in the face of packet loss on the network. 353 This is to prevent an implosion of Advertisements. An example of 354 this occurring would be when many routers are powered on at the same 355 time. When a Solicitation is received, an Advertisement is sent in 356 response with a random delay less than MAX_RESPONSE_DELAY. If a 357 Solicitation is received while an Advertisement is pending, that 358 Solicitation MUST be ignored. 360 Changes in the Query Interval or Robustness Variable MUST NOT trigger 361 a new advertisement, however the new values MUST be used all future 362 Advertisement messages. 364 When an Advertisement is sent, the periodic advertisement interval 365 timer MUST be reset. 367 3.5 Receiving Multicast Router Advertisements 369 Upon receiving an Advertisement message, devices validate the message 370 with the following criteria: 372 1. The checksum is correct 374 2. The IP destination address is equal to the All-Snoopers multicast 375 address 377 3. For IPv6, the IP source address is a link-local address 379 An Advertisement not meeting the validity requirements MUST be 380 silently discarded and may be logged in a rate-limited manner as per 381 the MaxMessageRate variable. 383 If an Advertisement is not received for a particular neighbor within 384 a NeighborDeadInterval time interval, then the neighbor is considered 385 unreachable. 387 4. Multicast Router Solicitation 389 Multicast Router Solicitation messages are used to solicit 390 Advertisements from multicast routers on a segment. These messages 391 are used when a device wishes to discover multicast routers. Upon 392 receiving a solicitation on an interface with IP multicast forwarding 393 and MRD enabled, a router will respond with an Advertisement. 395 Solicitations may be sent when: 397 1. An interface is (re-)initialized 399 2. MRD is enabled 400 Solicitations are sent to the All-Routers multicast address and 401 SHOULD be rate-limited as per the MaxMessageRate variable. 403 4.1 Solicitation Packet Format 405 The Solicitation message has the following format: 407 0 1 2 3 408 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 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | Type | Reserved | Checksum | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 4.1.1 Type Field 415 The Type field identifies the message as a Solicitation. It is set 416 to Y1 (to be assigned by IANA) for IPv4 and Y2 (to be assigned by 417 IANA) for IPv6. 419 4.1.2 Reserved Field 421 The Reserved field is set to 0 on transmission and ignored on 422 reception. 424 4.1.3 Checksum Field 426 The checksum field is set as follows: 428 o For IPv4 it is the 16-bit one's complement of the one's complement 429 sum of the IGMP message, starting with the Type field. For 430 computing the checksum, the checksum field is set to 0. 432 o For IPv6 it is ICMPv6 checksum as specified in [6]. 434 4.2 IP Header Fields 436 4.2.1 Source Address 438 The IP source address is set to an IP address configured on the 439 soliciting interface. For IPv6, a link-local address MUST be used. 441 4.2.2 Destination Address 443 The IP destination address is set to the All-Routers multicast 444 address. 446 4.2.3 Time-to-Live / Hop Limit 448 The IPv4 TTL and IPv6 Hop Limit are set to 1. 450 4.2.4 IPv4 Protocol 452 The IPv4 Protocol field is set to IGMP (2). 454 4.3 Sending Multicast Router Solicitations 456 Solicitation messages are sent when the following events occur: 458 o After waiting for a random delay less than MAX_SOLICITATION_DELAY 459 when an interface first becomes operational, is (re-)initialized, 460 or MRD is enabled. A device may send up to a maximum of 461 MAX_SOLICITATIONS, waiting for a random delay less than 462 MAX_SOLICITATION_DELAY between each solicitation. 464 o Optionally, for an implementation specific event. 466 Solicitations MUST be rate-limited as per the MaxMessageRate 467 variable; the implementation MUST send no more than MAX_SOLICITATIONS 468 in MAX_SOLICITATION_DELAY seconds. 470 4.4 Receiving Multicast Router Solicitations 472 A Solicitation message MUST be validated before a response is sent. 473 A router MUST verify that: 475 o The checksum is correct 477 o The IP destination address is the All-Routers multicast address 479 o For IPv6, the IP source address MUST be a link-local address 481 Solicitations not meeting the validity requirements SHOULD be 482 silently discarded and may be logged in a rate-limited manner as per 483 the MaxMessageRate variable. 485 5. Multicast Router Termination 487 The Multicast Router Termination message is used to expedite the 488 notification of a change in the status of a router's multicast 489 forwarding functions. Multicast routers send Terminations when 490 multicast forwarding is disabled on the advertising interface. 492 5.1 Termination Packet Format 494 The Termination message has the following format: 496 0 1 2 3 497 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 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 | Type | Reserved | Checksum | 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 5.1.1 Type Field 504 The Type field identifies the message as a Termination. It is set to 505 Z1 (to be assigned by IANA) for IPv4 and Z2 (to be assigned by IANA) 506 for IPv6. 508 5.1.2 Reserved Field 510 The Reserved field is set to 0 on transmission and ignored on 511 reception. 513 5.1.3 Checksum Field 515 The checksum field is set as follows: 517 o For IPv4 it is the 16-bit one's complement of the one's complement 518 sum of the IGMP message, starting with the Type field. For 519 computing the checksum, the checksum field is set to 0. 521 o For IPv6 it is ICMPv6 checksum as specified in [6]. 523 5.2 IP Header Fields 525 5.2.1 Source Address 527 The IP source address is set to an IP address configured on the 528 advertising interface. For IPv6, a link-local address MUST be used. 530 5.2.2 Destination Address 532 The IP destination address is set to the All-Snoopers multicast 533 address. 535 5.2.3 Time-to-Live / Hop Limit 537 The IPv4 TTL and IPv6 Hop Limit are set to 1. 539 5.2.4 IPv4 Protocol 541 The IPv4 Protocol field is set to IGMP (2). 543 5.3 Sending Multicast Router Terminations 545 Termination messages are sent by multicast routers when: 547 o Multicast forwarding is disabled on an interface 549 o An interface is administratively disabled 551 o The router is gracefully shutdown 553 o MRD is disabled 555 The sending of Termination messages SHOULD be rate-limited as per the 556 MaxMessageRate variable. 558 5.4 Receiving Multicast Router Terminations 560 Upon receiving a Termination message, devices validate the message. 561 The validation criteria is: 563 o Checksum MUST be correct 565 o IP destination address MUST equal the All-Snoopers multicast 566 address 568 o For IPv6, the IP source address MUST be a link-local address 570 Termination messages not meeting the validity requirements MUST be 571 silently discarded and may be logged in a rate-limited manner as per 572 the MaxMessageRate variable. 574 If the message passes these validation steps, a Solicitation is sent. 575 If an Advertisement is not received within NeighborDeadInterval, the 576 sending router is removed from the list of active multicast routers. 578 6. Protocol Constants 580 The following list identifies constants used in the MRD protocol. 581 These constants are used in the calculation of parameters. 583 o MAX_RESPONSE_DELAY 2 seconds 585 o MAX_SOLICITATION_DELAY 1 second 586 o MAX_SOLICITATIONS 3 transmissions 588 7. Security Considerations 590 As MRD is a link-local protocol, there is no circumstance in which it 591 would be correct for a MRD receiver to receive MRD traffic from an 592 off-network source. For IPv6, MRD messages MUST have a valid link- 593 local source address. Any messages received without a valid link- 594 local source address MUST be discarded. Similarly, for IPv4, the MRD 595 receiver MUST determine if the source address is local to the 596 receiving interface, and MUST discard any messages that have a non- 597 local source. Determining what networks are local may be 598 accomplished through configuration information or operational 599 capabilities. 601 Rogue nodes may attempt to attack a network running MRD by sending 602 spoofed Advertisement, Solicitation, or Termination messages. Each 603 type of spoofed message can be dealt with using existing technology. 605 A rogue node may attempt to interrupt multicast service by sending 606 spoofed Termination messages. As described in Section 5.4, all 607 Termination messages are validated by sending a Solicitation message. 608 By sending a Solicitation, the node will force the transmission of an 609 Advertisement by an active router. 611 Spoofed Solicitation messages do not cause any operational harm. 612 They may be used as a flooding mechanism to attack a multicast 613 router. This attack can be mitigated through the rate-limiting 614 recommendation for all MRD messages. 616 The Multicast Router Advertisement message may allow rogue machines 617 to masquerade as multicast routers. This could allow those machines 618 to eavesdrop on multicast data transmissions. Additionally, it could 619 constitute a denial of service attack to other hosts in the same 620 snooping domain or sharing the same device port in the presence of 621 high rate multicast flows. 623 The technology available in SEND[10] can be utilized to address 624 spoofed Advertisement messages in IPv6 networks. IPv6 Multicast 625 routers in an MRD-enabled network can use SEND-based link-local 626 addresses as the IPv6 source address for MRD messages. When a switch 627 receives an initial Advertisement, it can use the information in the 628 SEND-based address to challenge the router to authenticate itself. 629 It should be noted that this approach only applies to IPv6 networks. 631 Another solution which supports both IPv4 and IPv6 is to use IPsec in 632 Encapsulating Security Payload (ESP) mode[11] to protect against 633 attacks by ensuring that messages came from a system with the proper 634 key. When using IPsec, the messages sent to the All-Snoopers address 635 should be authenticated using ESP. Should encryption not be desired, 636 ESP with a null encryption algorithm and a symmetric authentication 637 algorithm, such as HMAC-SHA-1, is viable. For keying, a symmetric 638 signature algorithm with a single manually configured key is used for 639 routers sending Advertisements. This allows validation that the MRD 640 message was sent by a system with the key. It should be noted that 641 this does not prevent a system with the key from forging a message 642 and it requires the disabling of IPsec's Replay Protection. It is 643 the responsibility of the network administrator to ensure that the 644 same key is present on all possible MRD participants. 646 8. IANA Considerations 648 This document introduces three new IGMP messages. Each of these 649 messages requires a new IGMP Type value. This document requests IANA 650 to assign three new IGMP Type values to the Multicast Router 651 Discovery Protocol: 653 +-----------+-----------------+--------------------------------+ 654 | IGMP Type | Section | Message Name | 655 +-----------+-----------------+--------------------------------+ 656 | X1 | Section 3.2.1 | Multicast Router Advertisement | 657 | Y1 | Section 4.1.1 | Multicast Router Solicitation | 658 | Z1 | Section 5.1.1 | Multicast Router Termination | 659 +-----------+-----------------+--------------------------------+ 661 This document also introduces three new MLD messages. Each of these 662 messages requires a new ICMPv6 Type value. This document requests 663 IANA to assign three new ICMPv6 Type values from the Informational 664 range: 666 +-------------+-----------------+--------------------------------+ 667 | ICMPv6 Type | Section | Message Name | 668 +-------------+-----------------+--------------------------------+ 669 | X2 | Section 3.2.1 | Multicast Router Advertisement | 670 | Y2 | Section 4.1.1 | Multicast Router Solicitation | 671 | Z2 | Section 5.1.1 | Multicast Router Termination | 672 +-------------+-----------------+--------------------------------+ 674 This document also requires the assignment of an All-Snoopers 675 multicast address for IPv4. This multicast address should be in the 676 224.0.0/24 range since it is used for link-local, control messages. 677 A corresponding IPv6 multicast address is also requested. Following 678 the guidelines in [12], the IPv6 multicast address should be link- 679 local in scope and have a group-ID value equal to the low order 8 680 bits of the requested IPv4 multicast address. 682 9. Acknowledgements 684 Brad Cain and Shantam Biswis are the authors of the original 685 Multicast Router Discovery proposal. 687 ICMP Router Discovery [13] was used as a general model for Multicast 688 Router Discovery. 690 Morten Christensen, Pekka Savola, Hugh Holbrook, and Isidor Kouvelas 691 provided helpful feedback on various versions of this document. 693 10. References 695 10.1 Normative References 697 [1] Deering, S., "Host extensions for IP multicasting", STD 5, 698 RFC 1112, August 1989. 700 [2] Fenner, W., "Internet Group Management Protocol, Version 2", 701 RFC 2236, November 1997. 703 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 704 Levels", BCP 14, RFC 2119, March 1997. 706 [4] Katz, D., "IP Router Alert Option", RFC 2113, February 1997. 708 [5] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", 709 RFC 2711, October 1999. 711 [6] Conta, A. and S. Deering, "Internet Control Message Protocol 712 (ICMPv6) for the Internet Protocol Version 6 (IPv6) 713 Specification", RFC 2463, December 1998. 715 [7] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 716 Thyagarajan, "Internet Group Management Protocol, Version 3", 717 RFC 3376, October 2002. 719 [8] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener 720 Discovery (MLD) for IPv6", RFC 2710, October 1999. 722 [9] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 723 (MLDv2) for IPv6", RFC 3810, June 2004. 725 [10] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B., and P. 726 Nikander, "SEcure Neighbor Discovery (SEND)", 727 draft-ietf-send-ndopt-06 (work in progress), July 2004. 729 [11] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload 730 (ESP)", RFC 2406, November 1998. 732 [12] Haberman, B., "Allocation Guidelines for IPv6 Multicast 733 Addresses", RFC 3307, August 2002. 735 10.2 Informative References 737 [13] Deering, S., "ICMP Router Discovery Messages", RFC 1256, 738 September 1991. 740 Authors' Addresses 742 Brian Haberman 743 Johns Hopkins University Applied Physics Lab 744 11100 Johns Hopkins Road 745 Laurel, MD 20723-6099 746 US 748 Phone: +1 443 778 1319 749 Email: brian@innovationslab.net 751 Jim Martin 752 Netzwert AG 753 An den Treptowers 1 754 D-12435 Berlin 755 Germany 757 Phone: +49.30/5 900 800-180 758 Email: jim@netzwert.ag 760 Intellectual Property Statement 762 The IETF takes no position regarding the validity or scope of any 763 Intellectual Property Rights or other rights that might be claimed to 764 pertain to the implementation or use of the technology described in 765 this document or the extent to which any license under such rights 766 might or might not be available; nor does it represent that it has 767 made any independent effort to identify any such rights. Information 768 on the procedures with respect to rights in RFC documents can be 769 found in BCP 78 and BCP 79. 771 Copies of IPR disclosures made to the IETF Secretariat and any 772 assurances of licenses to be made available, or the result of an 773 attempt made to obtain a general license or permission for the use of 774 such proprietary rights by implementers or users of this 775 specification can be obtained from the IETF on-line IPR repository at 776 http://www.ietf.org/ipr. 778 The IETF invites any interested party to bring to its attention any 779 copyrights, patents or patent applications, or other proprietary 780 rights that may cover technology that may be required to implement 781 this standard. Please address the information to the IETF at 782 ietf-ipr@ietf.org. 784 Disclaimer of Validity 786 This document and the information contained herein are provided on an 787 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 788 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 789 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 790 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 791 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 792 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 794 Copyright Statement 796 Copyright (C) The Internet Society (2005). This document is subject 797 to the rights, licenses and restrictions contained in BCP 78, and 798 except as set forth therein, the authors retain all their rights. 800 Acknowledgment 802 Funding for the RFC Editor function is currently provided by the 803 Internet Society.