idnits 2.17.1 draft-ietf-idmr-igmp-mrdisc-08.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 5) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 4 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 178: '...his document and MUST be supported by ...' RFC 2119 keyword, line 198: '... The Time-to-Live field MUST be 1....' RFC 2119 keyword, line 241: '... are sent this field MUST be set to 0....' RFC 2119 keyword, line 253: '...d is not zero, a receiver MUST examine...' RFC 2119 keyword, line 304: '... MUST process all options, discardin...' (9 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == 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.) -- The document date (July 2002) is 7956 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) -- Looks like a reference, but probably isn't: '1' on line 215 == Missing Reference: 'N' is mentioned on line 219, but not defined == Missing Reference: 'IGMPv2' is mentioned on line 598, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'IGMPv3' ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) Summary: 6 errors (**), 0 flaws (~~), 6 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 Nortel Networks 4 draft-ietf-idmr-igmp-mrdisc-08.txt B. Cain 5 January 2002 B. Haberman 6 Expires July 2002 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 The concept of IGMP snooping requires the ability to identify the 33 location of multicast routers. Since IGMP snooping is not 34 standardized, there are many mechanisms in use to identify the 35 multicast routers. However, this scenario can lead to 36 interoperability issues between multicast routers and layer-2 37 switches from different vendors. 39 This document introduces a general mechanism that allows for the 40 discovery of multicast routers. By introducing these new messages, 41 IGMP snooping devices have a uniform means of identifying multicast 42 routers without dependency on particular routing protocols. In 43 addition, other devices that may need to discover multicast routers 44 can use these messages. 46 Table of Contents 48 1. Introduction....................................................2 49 2. Protocol Overview...............................................3 50 3. Multicast Router Advertisement..................................4 51 3.1 Overview.......................................................4 53 Biswas, Cain, Haberman 1 54 3.2 IP Header Fields...............................................4 55 3.3 Multicast Router Advertisement Message Format..................4 56 3.4 Sending Multicast Router Advertisements........................6 57 3.5 Receiving Multicast Router Advertisements......................6 58 3.6 Multicast Router Advertisement Configuration Variables.........6 59 4. Multicast Router Solicitation...................................7 60 4.1 Overview.......................................................8 61 4.2 IP Header Fields...............................................8 62 4.3 Multicast Router Solicitation Message Format...................8 63 4.4 Sending Multicast Router Solicitations.........................9 64 4.5 Receiving Multicast Router Solicitations.......................9 65 4.6 Multicast Router Solicitation Configuration Variables..........9 66 5. Multicast Router Termination....................................9 67 5.1 Overview.......................................................9 68 5.2 IP Header Fields..............................................10 69 5.3 Multicast Router Termination Message Format...................10 70 5.4 Sending Multicast Router Termination Messages.................10 71 5.5 Receiving Multicast Router Termination Messages...............11 72 6. Multicast Router Discovery Protocol Constants..................11 73 7. Mandatory Advertisement Options................................11 74 7.1 Overview of Options...........................................11 75 7.2 Query Interval Advertisement Option...........................11 76 7.3 Robustness Variable Advertisement Option......................12 77 8. IPv6 Support...................................................12 78 8.1 Router Advertisement Message..................................12 79 8.2 Router Solicitations..........................................13 80 9. Security Considerations........................................13 81 10. IANA Considerations...........................................14 82 11. Acknowledgements..............................................14 83 12. References....................................................14 84 13. Authors' Addresses............................................14 85 14. Full Copyright Statement......................................15 87 1. Introduction 89 Multicast router discovery messages are useful for discovering 90 multicast capable routers. This capability is useful in a layer-2 91 bridging domain with "IGMP snooping" type of schemes. By listening 92 to multicast router discovery messages, layer-2 devices can determine 93 where to send multicast source data and IGMP Host Membership Reports 94 [RFC1112] [RFC2236]. Multicast source data and IGMP Host Membership 95 Reports must be received by all multicast routers on a segment. 96 Using IGMP Host Membership Queries to discover multicast routers is 97 not useful because of query suppression in IGMP. 99 The use of the multicast router advertisement is not precluded from 100 being used for other purposes. Extensible options have been included 101 in the advertisement message for future enhancements. 103 The following are justifications for inventing another router 104 discovery protocol: 106 Biswas, Cain, Haberman 2 107 o Using ICMP router discovery is not an appropriate solution 108 for multicast router discovery because: 1.) It may confuse 109 hosts listening to ICMP router advertisements; unicast and 110 multicast topologies may not be congruent. 2.) There is 111 no way to tell from an ICMP router advertisement if a 112 router is running a multicast routing protocol. 114 o By making multicast router discovery messages extensible, 115 future enhancements can be made. 117 o By inventing a generic IP layer message, multiple types of 118 messages per link layer are not needed (i.e. including 119 this functionality as part of IP is better than inventing 120 N discovery protocols for N layer-2 technologies). 122 Although multicast router discovery messages could be sent as ICMP 123 messages, IGMP was chosen because IGMP snooping switches already 124 snoop IGMP messages and because the intended first use of these 125 protocol messages is multicast specific. 127 2. Protocol Overview 129 IGMP Multicast Router Discovery consists of three messages for 130 discovering multicast routers. The Multicast Router Advertisement is 131 sent by routers to advertise IP multicast forwarding enabled on an 132 interface. The Multicast Router Solicitation is used by routers to 133 solicit Multicast Router Advertisements. The Multicast Router 134 Termination message is sent when a router terminates its multicast 135 routing functions. 137 Multicast routers send Multicast Router Advertisements (hereafter 138 called advertisements) periodically on all interfaces on which 139 multicast forwarding is enabled. 141 Multicast Router Advertisements are also sent in response to 142 Multicast Router Solicitations (hereafter called solicitations). 143 These are sent to solicit a response of Multicast Router 144 Advertisements from all multicast routers on a subnet. Solicitations 145 are sent to the ALL-Systems (224.0.0.1) multicast group. 147 Multicast Router Solicitations are sent whenever a device wishes to 148 discover multicast routers on a directly attached subnet. 150 Multicast Router Termination messages are sent when a router 151 terminates its multicast routing functions. 153 All IGMP Multicast Router Discovery messages are sent with an IP TTL 154 of 1 and contain the IP Router Alert Option [RFC2113] in their IP 155 header. All IGMP Multicast Router Discovery messages are sent with 156 to the All-Systems multicast group (224.0.0.1). 158 Biswas, Cain, Haberman 3 159 Other non-IP forwarding devices (e.g. layer-2 switches) may send 160 Multicast Router Solicitations to solicit Multicast Router 161 Advertisements. 163 3. Multicast Router Advertisement 165 3.1 Overview 167 Multicast Router Advertisements are sent periodically on all router 168 interfaces on which multicast forwarding is enabled. They are also 169 sent in response to Multicast Router Solicitations. 171 Router advertisements are sent upon expiration of a periodic timer, 172 when a router starts up, and when a router interface (that has IP 173 multicast forwarding enabled) initializes/restarts. Advertisements 174 are sent as IGMP messages to the All-Systems multicast address 175 (224.0.0.1) and should be rate-limited. 177 Router advertisements may contain any number of options. Two options 178 are defined in this document and MUST be supported by any 179 implementation of IGMP multicast router discovery. These options are 180 described in Section 5. Additional options may be defined as needed 181 by future work. 183 3.2 IP Header Fields 185 3.2.1 Source Address 187 An IP address belonging to the interface from which this message is 188 sent. If multiple source addresses are configured on an interface, 189 then the one chosen is implementation dependent. 191 3.2.2 Destination Address 193 Router Advertisements are sent to the All-Systems multicast address 194 (224.0.0.1). 196 3.2.3 Time-to-Live 198 The Time-to-Live field MUST be 1. 200 3.2.4 Protocol 202 The protocol field is set to IGMP (2). 204 3.3 Multicast Router Advertisement Message Format 206 0 1 2 3 208 Biswas, Cain, Haberman 4 209 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 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | Type | Ad. Interval | Checksum | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | Unused | Number of Options (N) | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | Option [1] (TLV encoded) | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | Option [...] (TLV encoded) | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | Option [N] (TLV encoded) | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 3.3.1 Type Field 224 The type field is set to XX (to be assigned by IANA). 226 3.3.2 Advertisement Interval 228 This specifies the periodic time interval at which Multicast Router 229 Advertisements are sent in units of seconds. This value is set to 230 the configured MaxAdvertisementInterval variable. 232 3.3.3 Checksum 234 The checksum is the 16-bit one's complement of the one's complement 235 sum of the IGMP message, starting with the IGMP type. For computing 236 the checksum, the Checksum field is set to 0. 238 3.3.4 Number of Options (N) 240 The number of options contained in the router advertisement. If no 241 options are sent this field MUST be set to 0. 243 3.3.5 Option[1..N] 245 Options are encoded as TLV in the following manner: 247 0 1 2 3 248 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | Type | Length | Value | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 If the Number of Options field is not zero, a receiver MUST examine 254 all options. No strict ordering of options is enforced. 256 Type: Set to option type being advertised 258 Length: Length in bytes of Value field 260 Biswas, Cain, Haberman 5 261 Value: Option dependent value 263 3.4 Sending Multicast Router Advertisements 265 Router Advertisements are sent when the following events occur: 267 o When the periodic advertisement interval timer expires. 268 Note that it is not strictly periodic because the 269 advertisement interval is a random number between 270 MaxAdvertisementInterval and MinAdvertisementInterval. 272 o After waiting for a random delay less than 273 MaxInitialAdvertisementInterval when an interface first 274 comes up, is (re)initialized, or IGMP Multicast Router 275 Discovery is enabled. A router may send up to a maximum 276 of MaxInitialAdvertisements advertisements, waiting for a 277 random delay less than MaxInitialAdvertisementInterval 278 between each successive advertisement. Multiple messages 279 are sent for robustness in the face of packet loss on the 280 network. 282 This is to prevent an implosion of router advertisements. An example 283 of this occurring would be when many routers are powered on at the 284 same time. When a solicitation is received, a router advertisement 285 is sent in response with a random delay less than MAX_RESPONSE_DELAY. 286 If a solicitation is received while an advertisement is pending 287 (because of a recent solicitation), that solicitation will be 288 ignored. 290 Whenever an advertisement is sent, the periodic advertisement 291 interval timer must be reset. 293 3.5 Receiving Multicast Router Advertisements 295 Upon receiving a router advertisement, devices will validate the 296 message by the following criteria: 298 1. Verifying the IGMP checksum 300 2. IP Destination Address = All-Systems multicast address 302 A router advertisement not meeting the validity requirements should 303 be silently discarded or logged in a rate-limited manner. Devices 304 MUST process all options, discarding options that are not recognized. 306 If a router advertisement is not received for a particular neighbor 307 within NeighborDeadInterval time interval, then the neighbor is 308 considered to be unreachable. 310 3.6 Multicast Router Advertisement Configuration Variables 312 Biswas, Cain, Haberman 6 313 A router that implements multicast router discovery MUST allow for 314 the following variables to be configured by system management; 315 default values are specified so as to make it unnecessary to 316 configure any of these variables in many cases. 318 For each interface the following configurable variables are defined: 320 3.6.1 MaxAdvertisementInterval 322 The maximum time allowed between sending router advertisements from 323 the interface, in seconds. Must be no less than 2 seconds and no 324 greater than 180 seconds. 326 Default: 20 seconds. 328 3.6.2 MinAdvertisementInterval 330 The minimum time allowed between sending unsolicited router 331 advertisements from the interface, in seconds. Must be no less than 3 332 seconds and no greater than MaxAdvertisementInterval. 334 Default: 0.75 * MaxAdvertisementInterval 336 3.6.3 MaxInitialAdvertisementInterval 338 The first router advertisement out of an interface is sent after 339 waiting for a random interval less than this variable. This will 340 prevent a flood of router advertisements when many routers start up 341 at the same time. 343 Default: 2 seconds 345 3.6.4 MaxInitialAdvertisements 347 The maximum number of router advertisements that will be sent on a 348 subnet after a router boots. 350 Default: 3 352 3.6.5 NeighborDeadInterval 354 The maximum time allowed before a neighbor can be declared "dead". 355 This variable is defined in seconds. In order for all devices to have 356 a consistent state, it is necessary for the MaxAdvertisementInterval 357 to be configured the same on all routers per subnet. 359 Default: 3 * MaxAdvertisementInterval 361 4. Multicast Router Solicitation 363 Biswas, Cain, Haberman 7 364 4.1 Overview 366 Multicast Router Solicitations are used to solicit Multicast Router 367 Advertisements. These messages are used when a device wishes to 368 discover multicast routers. Upon receiving a solicitation on an 369 interface with IP multicast forwarding enabled and multicast router 370 discovery enabled, a router will respond with an advertisement. 372 Router solicitations may be sent when a device starts up, when an 373 interface (re)initializes, or when IGMP Multicast Router Discovery is 374 enabled. Solicitations are sent as IGMP messages to the All-Systems 375 multicast address (224.0.0.1) and must be rate-limited. 377 4.2 IP Header Fields 379 4.2.1 Source Address 381 An IP address belonging to the interface from which this message is 382 sent. If multiple source addresses are configured on an interface, 383 then the one chosen is implementation dependent. 385 If the solicitation is being sent from a device that does not have an 386 IP address (i.e. non-managed layer-2 switch), then the source address 387 should be set to all zeros. 389 4.2.2 Destination Address 391 Solicitation messages are sent to the All-Systems multicast address 392 (224.0.0.1). 394 4.2.3 Time-to-Live 396 The time-to-live field MUST be 1. 398 4.2.4 Protocol 400 The protocol field is set to IGMP (2). 402 4.3 Multicast Router Solicitation Message Format 404 0 1 2 3 405 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 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | Type | Reserved | Checksum | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 4.3.1 Type Field 412 The type field is set to YY (to be assigned by IANA). 414 4.3.2 Reserved Field 416 Biswas, Cain, Haberman 8 417 Sent as 0; ignored on reception. 419 4.3.3 Checksum 421 The checksum is the 16-bit one's complement of the one's complement 422 sum of the IGMP message, starting with the IGMP type. For computing 423 the checksum, the Checksum field is set to 0. 425 4.4 Sending Multicast Router Solicitations 427 Router solicitations are sent when the following events occur: 429 1. After waiting for a random delay less than SOLICITATION_INTERVAL 430 when an interface first comes up, is (re)initialized, or IGMP 431 Multicast Router Discovery is enabled. A device may send up to 432 a maximum of MAX_SOLICITATIONS, waiting for a random delay less 433 than SOLICITATION_INTERVAL between each successive solicitation. 435 2. Optionally, for an implementation specific event. Solicitations 436 MUST be rate-limited; no more than MAX_SOLICITATIONS MUST be 437 sent in SOLICITATION_INTERVAL seconds. 439 4.5 Receiving Multicast Router Solicitations 441 Upon receiving a router solicitation, routers will validate the 442 message by: 444 1. Verifying the IGMP checksum 446 2. IP Destination Address = All-Systems multicast address 448 A router solicitation not meeting the validity requirements should be 449 silently discarded or logged in a rate-limited manner. 451 Solicitation message IP source addresses MUST NOT be used as part of 452 the validity check. 454 4.6 Multicast Router Solicitation Configuration Variables 456 There are no configurable variables with respect to router 457 solicitations. 459 5. Multicast Router Termination 461 5.1 Overview 463 The Multicast Router Termination message is used to expedite the 464 notification of a change in the status of a routers multicast 465 forwarding functions. 467 Biswas, Cain, Haberman 9 468 5.2 IP Header Fields 470 5.2.1 Source Address 472 An IP address belonging to the interface from which this message is 473 sent. If multiple source addresses are configured on an interface, 474 then the one chosen is implementation dependent. 476 5.2.2 Destination Address 478 Multicast Router Termination messages are sent to the All-Systems 479 multicast address (224.0.0.1). 481 5.2.3 Time-to-Live 483 The Time-to-Live field MUST be 1. 485 5.2.4 Protocol 487 The protocol field is set to IGMP (2). 489 5.3 Multicast Router Termination Message Format 491 0 1 2 3 492 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 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 | Type | Reserved | Checksum | 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 5.3.1 Type Field 499 The type field is set to ZZ (to be assigned by IANA). 501 5.3.2 Reserved Field 503 Sent as 0; ignored on reception. 505 5.3.3 Checksum 507 The checksum is the 16-bit one's complement of the one's complement 508 sum of the IGMP message, starting with the IGMP type. For computing 509 the checksum, the Checksum field is set to 0. 511 5.4 Sending Multicast Router Termination Messages 513 Multicast Router Termination messages are sent for three reasons: 515 1. Multicast forwarding is disabled on the interface 517 2. The interface is administratively disabled 519 Biswas, Cain, Haberman 10 520 3. The router is gracefully shutdown 522 5.5 Receiving Multicast Router Termination Messages 524 Upon receiving a termination message, routers will validate the 525 message by the following criteria: 527 1. Verifying the IGMP checksum 529 2. IP Destination Address = All-Systems multicast address 531 A termination message not meeting the validity requirements should be 532 silently discarded or logged in a rate-limited manner. 534 6. Multicast Router Discovery Protocol Constants 536 o MAX_RESPONSE_DELAY 2 seconds 538 o MAX_SOLICITATION_DELAY 1 second 540 o SOLICITATION_INTERVAL 3 seconds 542 o MAX_SOLICITATIONS 3 transmissions 544 7. Mandatory Advertisement Options 546 7.1 Overview of Options 548 The following options MUST be supported by an implementation of IGMP 549 Multicast Router Discovery: Query Interval Advertisement Option and 550 Robustness Variable Advertisement Option. These options advertise 551 specific IGMP variables and are sent in an advertisement depending on 552 the version of IGMP enabled on an interface. Although no 553 requirements exist for multicast routers at this time, it is assumed 554 that all multicast routers support the IGMP protocol. 556 7.2 Query Interval Advertisement Option 558 0 1 2 3 559 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 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 | Type=1 | Length=2 | IGMP Query Interval | 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 If a multicast router has any version of IGMP [RFC1112] enabled on an 565 interface on which IGMP Multicast Router Discovery is also enabled, 566 it MUST send all advertisements with the Query Interval Advertisement 567 Option. This option contains the IGMP "Query Interval" configured on 568 the interface on which advertisements are sent. 570 Biswas, Cain, Haberman 11 571 This option is sent regardless of whether the router is currently the 572 IGMP querier for the subnet. This option is sent regardless of what 573 version of IGMP the router is running. 575 IGMP Query Interval field is equal (in seconds) to the configured 576 IGMP "query interval" on the interface from which the advertisement 577 was sent. 579 7.3 Robustness Variable Advertisement Option 581 0 1 2 3 582 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 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 | Type=2 | Length=2 | Robustness Variable | 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 If a multicast router has IGMPv2 [IGMPv2] or IGMPv3 [IGMPv3] enabled 588 on an interface on which IGMP Multicast Router Discovery is also 589 enabled, it MUST send all advertisements with the Robustness Variable 590 Advertisement Option. This option contains the IGMP "Robustness 591 Variable" configured on the interface on which advertisements are 592 sent. 594 This option is sent regardless of whether the router is currently the 595 IGMP querier for the subnet. This option may be omitted if IGMPv1 is 596 enabled on the interface. 598 Robustness Variable is an integer that MUST not be zero [IGMPv2] and 599 is equal to the IGMPv2 robustness variable. 601 8. IPv6 Support 603 The Multicast Router Discovery function for IPv6 is accomplished 604 using the Neighbor Discovery Protocol for IPv6 [RFC2461] (hereafter 605 called NDP). Specifically, the Router Advertisement message contains 606 new fields to support the discovery of multicast routers. For this 607 reason, the timing mechanisms defined for NDP will be used instead of 608 those defined in this document for IPv4 support. 610 8.1 Router Advertisement Message 612 The Router Advertisement message contains two new fields to support 613 the multicast router discovery mechanism. The modified message 614 format is: 616 Biswas, Cain, Haberman 12 617 0 1 2 3 618 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 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 | Type | Code | Checksum | 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 | Cur Hop Limit |M|O|H|D|E|Rsrvd| Router Lifetime | 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 | Reachable Time | 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 | Retrans Timer | 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 | Options ... 629 +-+-+-+-+-+-+-+-+-+-+-+- 631 The two new fields are the 'D' and 'E' bits. All other fields retain 632 their definitions and functions as described in Section 4.2 of the 633 NDP specification [RFC2461]. 635 8.1.1 Discovery (D) bit 637 The 'D' bit is used by a router to indicate support for the Multicast 638 Router Discovery protocol. A value of '1' indicates that the router 639 supports the discovery protocol. A value of '0' indicates no 640 support. This allows for backwards compatibility of the Router 641 Advertisement message. 643 8.1.2 Enabled (E) bit 645 The 'E' bit indicates whether multicast routing is enabled on the 646 router's interface. A value of '1' indicates that multicast 647 forwarding is enabled on the router's interface. A value of '0' 648 indicates that multicast forwarding is disabled. 650 When the state of multicast forwarding changes on an interface, a 651 router must stop its Router Advertisement timer, transmit a Router 652 Advertisement with the 'E' bit set to the value associated with the 653 new multicast forwarding state, and restart its Router Advertisement 654 timer. 656 8.2 Router Solicitations 658 An NDP Router Solicitation message can be sent to solicit a Router 659 Advertisement message in order to determine the multicast forwarding 660 state of a router. The periodic transmission of solicitation 661 messages is outlined in RFC 2461. 663 9. Security Considerations 665 The Multicast Router Advertisement message may allow rogue machines 666 to masquerade as multicast routers. This could allow those machines 667 to eavesdrop on multicast data transmission or create a denial of 669 Biswas, Cain, Haberman 13 670 service attack on multicast flows. However, these new messages are 671 extensible and that allows for the introduction of security 672 associations into the protocol. These security extensions could be 673 used to authenticate or encrypt the messages. 675 10. IANA Considerations 677 This document introduces three new IGMP messages. Each of these 678 messages requires a new IGMP 'Type' value. 680 11. Acknowledgements 682 ICMP Router Discovery [RFC1256] was used as a general model for IGMP 683 Multicast Router Discovery. 685 12. References 687 [RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256, 688 September 1991. 690 [RFC1112] Deering, S., "Host Extensions for IP Multicasting", 691 RFC 1112, August 1989. 693 [RFC2236] Fenner, W., "Internet Group Management Protocol, 694 Version 2", RFC 2236, November 1997. 696 [IGMPv3] Cain, B., et al, "Internet Group Management Protocol, 697 Version 3", work in progress, January 2002. 699 [RFC2113] Katz, D., "IP Router Alert Option," RFC 2113, April 1996. 701 [RFC2461] Narten, T., Nordmark, E., and Simpson, W., "Neighbor 702 Discovery IP Version 6 (IPv6)", RFC 2461, December 1998. 704 13. Authors' Addresses 706 Shantam Biswas 707 Nortel Networks 708 600 Technology Park Drive 709 Billerica, MA 01821 710 Email: sbiswas@baynetworks.com 711 Phone: 1-978-916-8048 713 Brad Cain 714 Email: bcain@mediaone.net 716 Brian Haberman 717 Email: haberman@innovationslab.net 718 Phone: 1-919-949-4828 720 Biswas, Cain, Haberman 14 721 14. Full Copyright Statement 723 Copyright (C) The Internet Society (2001). All Rights Reserved. 725 This document and translations of it may be copied and furnished to 726 others, and derivative works that comment on or otherwise explain it 727 or assist in its implementation may be prepared, copied, published 728 and distributed, in whole or in part, without restriction of any 729 kind, provided that the above copyright notice and this paragraph 730 are included on all such copies and derivative works. However, this 731 document itself may not be modified in any way, such as by removing 732 the copyright notice ore references to the Internet Society or other 733 Internet organizations, except as needed for the purpose of 734 developing Internet standards in which case the procedures for 735 copyrights defined in the Internet Standards process must be 736 followed, or as required to translate it into languages other than 737 English. 739 The limited permissions granted above are perpetual and will not be 740 revoked by the Internet Society or its successors or assigns. 742 This document and the information contained herein is provided on an 743 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 744 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 745 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 746 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 747 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 749 Biswas, Cain, Haberman 15