idnits 2.17.1 draft-ietf-idmr-igmp-mrdisc-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 3 longer pages, the longest (page 4) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 5 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 140: '...his document and MUST be supported by ...' RFC 2119 keyword, line 161: '... The Time-to-Live field MUST be 1....' RFC 2119 keyword, line 202: '... are sent this field MUST be set to 0....' RFC 2119 keyword, line 215: '...d is not zero, a receiver MUST examine...' RFC 2119 keyword, line 266: '... MUST process all options, discardin...' (9 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Robustness Variable is an integer that MUST not be zero [IGMPv2] and is equal to the IGMPv2 robustness variable. -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 176 == Missing Reference: 'N' is mentioned on line 180, but not defined == Missing Reference: 'IGMPv2' is mentioned on line 559, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'IGMPv3' ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) Summary: 7 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDMR Working Group S. Biswas 3 Internet Draft B. Haberman 4 draft-ietf-idmr-igmp-mrdisc-06.txt Nortel Networks 5 May 2001 B. Cain 6 Expires November 2001 Cereva Networks 8 IGMP Multicast Router Discovery 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. Internet-Drafts are draft documents valid for a maximum of 19 six months and may be updated, replaced, or obsoleted by other 20 documents at any time. It is inappropriate to use Internet- Drafts 21 as reference material or to cite them other than as "work in 22 progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 Companies have been proposing IGMP snooping schemes for layer-2 33 bridging devices. A method for discovering multicast capable routers 34 is necessary for these schemes. An IGMP query message is inadequate 35 for discovering multicast routers as one querier is elected. In 36 order to "discover" multicast routers, we introduce three new types 37 of IGMP messages: Multicast Router Advertisement, Multicast Router 38 Solicitation, and Multicast Router Termination. These messages can 39 be used by any device which listens to IGMP to discovery multicast 40 routers. Multicast Router Solicitation messages may be used by any 41 network device (e.g. layer-2 switch) to solicit discovery messages 42 from multicast routers. 44 1. Introduction 46 Multicast router discovery messages are useful for discovering 47 multicast capable routers. This capability is useful in a layer-2 48 bridging domain with "IGMP snooping" type of schemes. By listening 49 to multicast router discovery messages, layer-2 devices can determine 51 Biswas, Cain, Haberman 1 52 where to send multicast source data and IGMP Host Membership Reports 53 [RFC1112] [RFC2236]. Multicast source data and IGMP Host Membership 54 Reports must be received by all multicast routers on a segment. 55 Using IGMP Host Membership Queries to discover multicast routers is 56 not useful because of query suppression in IGMP. 58 Unlike ICMP router discovery messages [RFC1256], multicast router 59 discovery advertisements should not be listened to by hosts. Hosts 60 need not know the identity of multicast routers. 62 The use of the multicast router advertisement is not precluded from 63 being used for other purposes. Extensible options have been included 64 in the advertisement message for future enhancements. 66 The following are justifications for inventing another router 67 discovery protocol: 69 o Using ICMP router discovery is not an appropriate solution 70 for multicast router discovery because: 1.) It may confuse 71 hosts listening to ICMP router advertisements; unicast and 72 multicast topologies may not be congruent. 2.) There is 73 no way to tell from an ICMP router advertisement if a 74 router is running a multicast routing protocol. 76 o By making multicast router discovery messages extensible, 77 future enhancements can be made. 79 o By inventing a generic IP layer message, multiple types of 80 messages per link layer are not needed (i.e. including 81 this functionality as part of IP is better than inventing 82 N discovery protocols for N layer-2 technologies). 84 Although multicast router discovery messages could be sent as ICMP 85 messages, IGMP was chosen because IGMP snooping switches already 86 snoop IGMP messages and because the intended first use of these 87 protocol messages is multicast specific. 89 2. Protocol Overview 91 IGMP Multicast Router Discovery consists of three messages for 92 discovering multicast routers. The Multicast Router Advertisement is 93 sent by routers to advertise IP multicast forwarding enabled on an 94 interface. The Multicast Router Solicitation is used by routers to 95 solicit Multicast Router Advertisements. The Multicast Router 96 Termination message is sent when a router terminates its multicast 97 routing functions. 99 Multicast routers send Multicast Router Advertisements (hereafter 100 called advertisements) periodically on all interfaces on which 101 multicast forwarding is enabled. 103 Biswas, Cain, Haberman 2 104 Multicast Router Advertisements are also sent in response to 105 Multicast Router Solicitations (hereafter called solicitations). 106 These are sent to solicit a response of Multicast Router 107 Advertisements from all multicast routers on a subnet. Solicitations 108 are sent to the ALL-Routers (224.0.0.2) multicast group. 110 Multicast Router Solicitations are sent whenever a device wishes to 111 discover multicast routers on a directly attached subnet. 113 Multicast Router Termination messages are sent when a router 114 terminates its multicast routing functions. 116 All IGMP Multicast Router Discovery messages are sent with an IP TTL 117 of 1 and contain the IP Router Alert Option [RFC2113] in their IP 118 header. All IGMP Multicast Router Discovery messages are sent with 119 to the All-Routers multicast group (224.0.0.2). 121 Other non-IP forwarding devices (e.g. layer-2 switches) may send 122 Multicast Router Solicitations to solicit Multicast Router 123 Advertisements. 125 3. Multicast Router Advertisement 127 3.1 Overview 129 Multicast Router Advertisements are sent periodically on all router 130 interfaces on which multicast forwarding is enabled. They are also 131 sent in response to Multicast Router Solicitations. 133 Router advertisements are sent upon expiration of a periodic timer, 134 when a router starts up, and when a router interface (that has IP 135 multicast forwarding enabled) initializes/restarts. Advertisements 136 are sent as IGMP messages to the All-Routers multicast address 137 (224.0.0.2) and should be rate-limited. 139 Router advertisements may contain any number of options. Two options 140 are defined in this document and MUST be supported by any 141 implementation of IGMP multicast router discovery. These options are 142 described in Section 5. Additional options may be defined as needed 143 by future work. 145 3.2 IP Header Fields 147 3.2.1 Source Address 149 An IP address belonging to the interface from which this message is 150 sent. If multiple source addresses are configured on an interface, 151 then the one chosen is implementation dependent. 153 Biswas, Cain, Haberman 3 154 3.2.2 Destination Address 156 Router Advertisements are sent to the All-Routers multicast address 157 (224.0.0.2). 159 3.2.3 Time-to-Live 161 The Time-to-Live field MUST be 1. 163 3.2.4 Protocol 165 The protocol field is set to IGMP (2). 167 3.3 Multicast Router Advertisement Message Format 169 0 1 2 3 170 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 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | Type | Ad. Interval | Checksum | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 | Unused | Number of Options (N) | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | Option [1] (TLV encoded) | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | Option [...] (TLV encoded) | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | Option [N] (TLV encoded) | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 3.3.1 Type Field 185 The type field is set to 0x24. 187 3.3.2 Advertisement Interval 189 This specifies the periodic time interval at which Multicast Router 190 Advertisements are sent in units of seconds. This value is set to 191 the configured MaxAdvertisementInterval variable. 193 3.3.3 Checksum 195 The checksum is the 16-bit one's complement of the one's complement 196 sum of the IGMP message, starting with the IGMP type. For computing 197 the checksum, the Checksum field is set to 0. 199 3.3.4 Number of Options (N) 201 The number of options contained in the router advertisement. If no 202 options are sent this field MUST be set to 0. 204 Biswas, Cain, Haberman 4 205 3.3.5 Option[1..N] 207 Options are encoded as TLV in the following manner: 209 0 1 2 3 210 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 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | Type | Length | Value | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 If the Number of Options field is not zero, a receiver MUST examine 216 all options. No strict ordering of options is enforced. 218 Type: Set to option type being advertised 220 Length: Length in bytes of Value field 222 Value: Option dependent value 224 3.4 Sending Multicast Router Advertisements 226 Router Advertisements are sent when the following events occur: 228 o When the periodic advertisement interval timer expires. 229 Note that it is not strictly periodic because the 230 advertisement interval is a random number between 231 MaxAdvertisementInterval and MinAdvertisementInterval. 233 o After waiting for a random delay less than 234 MaxInitialAdvertisementInterval when an interface first 235 comes up, is (re)initialized, or IGMP Multicast Router 236 Discovery is enabled. A router may send up to a maximum 237 of MaxInitialAdvertisements advertisements, waiting for a 238 random delay less than MaxInitialAdvertisementInterval 239 between each successive advertisement. Multiple messages 240 are sent for robustness in the face of packet loss on the 241 network. 243 This is to prevent an implosion of router advertisements. An example 244 of this occurring would be when many routers are powered on at the 245 same time. When a solicitation is received, a router advertisement 246 is sent in response with a random delay less than MAX_RESPONSE_DELAY. 247 If a solicitation is received while an advertisement is pending 248 (because of a recent solicitation), that solicitation will be 249 ignored. 251 Whenever an advertisement is sent, the periodic advertisement 252 interval timer must be reset. 254 3.5 Receiving Multicast Router Advertisements 256 Biswas, Cain, Haberman 5 257 Upon receiving a router advertisement, devices will validate the 258 message by the following criteria: 260 1. Verifying the IGMP checksum 262 2. IP Destination Address = All-Routers multicast address 264 A router advertisement not meeting the validity requirements should 265 be silently discarded or logged in a rate-limited manner. Devices 266 MUST process all options, discarding options that are not recognized. 268 If a router advertisement is not received for a particular neighbor 269 within NeighborDeadInterval time interval, then the neighbor is 270 considered to be unreachable. 272 3.6 Multicast Router Advertisement Configuration Variables 274 A router that implements multicast router discovery MUST allow for 275 the following variables to be configured by system management; 276 default values are specified so as to make it unnecessary to 277 configure any of these variables in many cases. 279 For each interface the following configurable variables are defined: 281 3.6.1 MaxAdvertisementInterval 283 The maximum time allowed between sending router advertisements from 284 the interface, in seconds. Must be no less than 2 seconds and no 285 greater than 180 seconds. 287 Default: 20 seconds. 289 3.6.2 MinAdvertisementInterval 291 The minimum time allowed between sending unsolicited router 292 advertisements from the interface, in seconds. Must be no less than 3 293 seconds and no greater than MaxAdvertisementInterval. 295 Default: 0.75 * MaxAdvertisementInterval 297 3.6.3 MaxInitialAdvertisementInterval 299 The first router advertisement out of an interface is sent after 300 waiting for a random interval less than this variable. This will 301 prevent a flood of router advertisements when many routers start up 302 at the same time. 304 Default: 2 seconds 306 3.6.4 MaxInitialAdvertisements 308 Biswas, Cain, Haberman 6 309 The maximum number of router advertisements that will be sent on a 310 subnet after a router boots. 312 Default: 3 314 3.6.5 NeighborDeadInterval 316 The maximum time allowed before a neighbor can be declared "dead". 317 This variable is defined in seconds. In order for all devices to have 318 a consistent state, it is necessary for the MaxAdvertisementInterval 319 to be configured the same on all routers per subnet. 321 Default: 3 * MaxAdvertisementInterval 323 4. Multicast Router Solicitation 325 4.1 Overview 327 Multicast Router Solicitations are used to solicit Multicast Router 328 Advertisements. These messages are used when a device wishes to 329 discover multicast routers. Upon receiving a solicitation on an 330 interface with IP multicast forwarding enabled and multicast router 331 discovery enabled, a router will respond with an advertisement. 333 Router solicitations may be sent when a device starts up, when an 334 interface (re)initializes, or when IGMP Multicast Router Discovery is 335 enabled. Solicitations are sent as IGMP messages to the All-Routers 336 multicast address (224.0.0.2) and must be rate-limited. 338 4.2 IP Header Fields 340 4.2.1 Source Address 342 An IP address belonging to the interface from which this message is 343 sent. If multiple source addresses are configured on an interface, 344 then the one chosen is implementation dependent. 346 If the solicitation is being sent from a device that does not have an 347 IP address (i.e. non-managed layer-2 switch), then the source address 348 should be set to all zeros. 350 4.2.2 Destination Address 352 Solicitation messages are sent to the All-Routers multicast address 353 (224.0.0.2). 355 4.2.3 Time-to-Live 357 The time-to-live field MUST be 1. 359 4.2.4 Protocol 361 Biswas, Cain, Haberman 7 362 The protocol field is set to IGMP (2). 364 4.3 Multicast Router Solicitation Message Format 366 0 1 2 3 367 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 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | Type | Reserved | Checksum | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 4.3.1 Type Field 374 The type field is set to 0x25. 376 4.3.2 Reserved Field 378 Sent as 0; ignored on reception. 380 4.3.3 Checksum 382 The checksum is the 16-bit one's complement of the one's complement 383 sum of the IGMP message, starting with the IGMP type. For computing 384 the checksum, the Checksum field is set to 0. 386 4.4 Sending Multicast Router Solicitations 388 Router solicitations are sent when the following events occur: 390 1. After waiting for a random delay less than SOLICITATION_INTERVAL 391 when an interface first comes up, is (re)initialized, or IGMP 392 Multicast Router Discovery is enabled. A device may send up to 393 a maximum of MAX_SOLICITATIONS, waiting for a random delay less 394 than SOLICITATION_INTERVAL between each successive solicitation. 396 2. Optionally, for an implementation specific event. Solicitations 397 MUST be rate-limited; no more than MAX_SOLICITATIONS MUST be 398 sent in SOLICITATION_INTERVAL seconds. 400 4.5 Receiving Multicast Router Solicitations 402 Upon receiving a router solicitation, routers will validate the 403 message by: 405 1. Verifying the IGMP checksum 407 2. IP Destination Address = All-Routers multicast address 409 A router solicitation not meeting the validity requirements should be 410 silently discarded or logged in a rate-limited manner. 412 Biswas, Cain, Haberman 8 413 Solicitation message IP source addresses MUST NOT be used as part of 414 the validity check. 416 4.6 Multicast Router Solicitation Configuration Variables 418 There are no configurable variables with respect to router 419 solicitations. 421 5. Multicast Router Termination 423 5.1 Overview 425 The Multicast Router Termination message is used to expedite the 426 notification of a change in the status of a routers multicast 427 forwarding functions. 429 5.2 IP Header Fields 431 5.2.1 Source Address 433 An IP address belonging to the interface from which this message is 434 sent. If multiple source addresses are configured on an interface, 435 then the one chosen is implementation dependent. 437 5.2.2 Destination Address 439 Multicast Router Termination messages are sent to the All-Routers 440 multicast address (224.0.0.2). 442 5.2.3 Time-to-Live 444 The Time-to-Live field MUST be 1. 446 5.2.4 Protocol 448 The protocol field is set to IGMP (2). 450 5.3 Multicast Router Termination Message Format 452 0 1 2 3 453 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 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 | Type | Reserved | Checksum | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 5.3.1 Type Field 460 The type field is set to 0x26. 462 5.3.2 Reserved Field 464 Biswas, Cain, Haberman 9 465 Sent as 0; ignored on reception. 467 5.3.3 Checksum 469 The checksum is the 16-bit one's complement of the one's complement 470 sum of the IGMP message, starting with the IGMP type. For computing 471 the checksum, the Checksum field is set to 0. 473 5.4 Sending Multicast Router Termination Messages 475 Multicast Router Termination messages are sent for three reasons: 477 1. Multicast forwarding is disabled on the interface 479 2. The interface is administratively disabled 481 3. The router is gracefully shutdown 483 5.5 Receiving Multicast Router Termination Messages 485 Upon receiving a termination message, routers will validate the 486 message by the following criteria: 488 1. Verifying the IGMP checksum 490 2. IP Destination Address = All-Routers multicast address 492 A termination message not meeting the validity requirements should be 493 silently discarded or logged in a rate-limited manner. 495 6. Multicast Router Discovery Protocol Constants 497 o MAX_RESPONSE_DELAY 2 seconds 499 o MAX_SOLICITATION_DELAY 1 second 501 o SOLICITATION_INTERVAL 3 seconds 503 o MAX_SOLICITATIONS 3 transmissions 505 7. Mandatory Advertisement Options 507 7.1 Overview of Options 509 The following options MUST be supported by an implementation of IGMP 510 Multicast Router Discovery: Query Interval Advertisement Option and 511 Robustness Variable Advertisement Option. These options advertise 512 specific IGMP variables and are sent in an advertisement depending on 513 the version of IGMP enabled on an interface. Although no 514 requirements exist for multicast routers at this time, it is assumed 515 that all multicast routers support the IGMP protocol. 517 Biswas, Cain, Haberman 10 518 7.2 Query Interval Advertisement Option 520 0 1 2 3 521 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 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 | Type=1 | Length=2 | IGMP Query Interval | 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 If a multicast router has any version of IGMP [RFC1112] enabled on an 527 interface on which IGMP Multicast Router Discovery is also enabled, 528 it MUST send all advertisements with the Query Interval Advertisement 529 Option. This option contains the IGMP "Query Interval" configured on 530 the interface on which advertisements are sent. 532 This option is sent regardless of whether the router is currently the 533 IGMP querier for the subnet. This option is sent regardless of what 534 version of IGMP the router is running. 536 IGMP Query Interval field is equal (in seconds) to the configured 537 IGMP "query interval" on the interface from which the advertisement 538 was sent. 540 7.3 Robustness Variable Advertisement Option 542 0 1 2 3 543 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 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 | Type=2 | Length=2 | Robustness Variable | 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 If a multicast router has IGMPv2 [IGMPv2] or IGMPv3 [IGMPv3] enabled 549 on an interface on which IGMP Multicast Router Discovery is also 550 enabled, it MUST send all advertisements with the Robustness Variable 551 Advertisement Option. This option contains the IGMP "Robustness 552 Variable" configured on the interface on which advertisements are 553 sent. 555 This option is sent regardless of whether the router is currently the 556 IGMP querier for the subnet. This option may be omitted if IGMPv1 is 557 enabled on the interface. 559 Robustness Variable is an integer that MUST not be zero [IGMPv2] and 560 is equal to the IGMPv2 robustness variable. 562 8. IPv6 Support 564 The Multicast Router Discovery function for IPv6 is accomplished 565 using the Neighbor Discovery Protocol for IPv6 [RFC2461] (hereafter 566 called NDP). Specifically, the Router Advertisement message contains 567 new fields to support the discovery of multicast routers. For this 569 Biswas, Cain, Haberman 11 570 reason, the timing mechanisms defined for NDP will be used instead of 571 those defined in this document for IPv4 support. 573 8.1 Router Advertisement Message 575 The Router Advertisement message contains two new fields to support 576 the multicast router discovery mechanism. The modified message 577 format is: 579 0 1 2 3 580 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 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 | Type | Code | Checksum | 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 | Cur Hop Limit |M|O|H|D|E|Rsrvd| Router Lifetime | 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 | Reachable Time | 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 | Retrans Timer | 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 | Options ... 591 +-+-+-+-+-+-+-+-+-+-+-+- 593 The two new fields are the 'D' and 'E' bits. All other fields retain 594 their definitions and functions as described in Section 4.2 of the 595 NDP specification [RFC2461]. 597 8.1.1 Discovery (D) bit 599 The 'D' bit is used by a router to indicate support for the Multicast 600 Router Discovery protocol. A value of '1' indicates that the router 601 supports the discovery protocol. A value of '0' indicates no 602 support. This allows for backwards compatibility of the Router 603 Advertisement message. 605 8.1.2 Enabled (E) bit 607 The 'E' bit indicates whether multicast routing is enabled on the 608 router's interface. A value of '1' indicates that multicast 609 forwarding is enabled on the router's interface. A value of '0' 610 indicates that multicast forwarding is disabled. 612 When the state of multicast forwarding changes on an interface, a 613 router must stop its Router Advertisement timer, transmit a Router 614 Advertisement with the 'E' bit set to the value associated with the 615 new multicast forwarding state, and restart its Router Advertisement 616 timer. 618 8.2 Router Solicitations 620 Biswas, Cain, Haberman 12 621 An NDP Router Solicitation message can be sent to solicit a Router 622 Advertisement message in order to determine the multicast forwarding 623 state of a router. The periodic transmission of solicitation 624 messages is outlined in RFC 2461. 626 9. Security Considerations 628 The Multicast Router Advertisement message may allow rogue machines 629 to masquerade as multicast routers. This could allow those machines 630 to eavesdrop on multicast data transmission or create a denial of 631 service attack on multicast flows. However, these new messages are 632 extensible and that allows for the introduction of security 633 associations into the protocol. These security extensions could be 634 used to authenticate or encrypt the messages. 636 10. Acknowledgements 638 ICMP Router Discovery [RFC1256] was used as a general model for IGMP 639 Multicast Router Discovery. 641 11. References 643 [RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256, 644 September 1991. 646 [RFC1112] Deering, S., "Host Extensions for IP Multicasting", 647 RFC 1112, August 1989. 649 [RFC2236] Fenner, W., "Internet Group Management Protocol, 650 Version 2", RFC 2236, November 1997. 652 [IGMPv3] Cain, B., Deering, S., Thyagarajan, A., "Internet Group 653 Management Protocol, Version 3", work in progress, 654 March 2001. 656 [RFC2113] Katz, D., "IP Router Alert Option," RFC 2113, April 1996. 658 [RFC2461] Narten, T., Nordmark, E., and Simpson, W., "Neighbor 659 Discovery IP Version 6 (IPv6)", RFC 2461, December 1998. 661 10. Authors' Addresses 663 Shantam Biswas 664 Nortel Networks 665 600 Technology Park Drive 666 Billerica, MA 01821 667 Email: sbiswas@baynetworks.com 668 Phone: 1-978-916-8048 670 Brad Cain 671 Cereva Networks 673 Biswas, Cain, Haberman 13 674 Email: bcain@cereva.com 676 Brian Haberman 677 Nortel Networks 678 4309 Emperor Blvd 679 Suite 200 680 Durham, NC 27703 681 Email: haberman@nortelnetworks.com 682 Phone: 1-919-992-4439 684 Biswas, Cain, Haberman 14