idnits 2.17.1 draft-ietf-idmr-igmp-mrdisc-07.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 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 182: '...his document and MUST be supported by ...' RFC 2119 keyword, line 202: '... The Time-to-Live field MUST be 1....' RFC 2119 keyword, line 244: '... are sent this field MUST be set to 0....' RFC 2119 keyword, line 257: '...d is not zero, a receiver MUST examine...' RFC 2119 keyword, line 308: '... 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.) -- 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 218 == Missing Reference: 'N' is mentioned on line 222, but not defined == Missing Reference: 'IGMPv2' is mentioned on line 601, 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 B. Haberman 4 draft-ietf-idmr-igmp-mrdisc-07.txt Nortel Networks 5 June 2001 B. Cain 6 Expires December 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 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..................5 56 3.4 Sending Multicast Router Advertisements........................6 57 3.5 Receiving Multicast Router Advertisements......................6 58 3.6 Multicast Router Advertisement Configuration Variables.........7 59 4. Multicast Router Solicitation...................................8 60 4.1 Overview.......................................................8 61 4.2 IP Header Fields...............................................8 62 4.3 Multicast Router Solicitation Message Format...................9 63 4.4 Sending Multicast Router Solicitations.........................9 64 4.5 Receiving Multicast Router Solicitations.......................9 65 4.6 Multicast Router Solicitation Configuration Variables.........10 66 5. Multicast Router Termination...................................10 67 5.1 Overview......................................................10 68 5.2 IP Header Fields..............................................10 69 5.3 Multicast Router Termination Message Format...................10 70 5.4 Sending Multicast Router Termination Messages.................11 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...........................12 76 7.3 Robustness Variable Advertisement Option......................12 77 8. IPv6 Support...................................................12 78 8.1 Router Advertisement Message..................................13 79 8.2 Router Solicitations..........................................13 80 9. Security Considerations........................................14 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 Unlike ICMP router discovery messages [RFC1256], multicast router 100 discovery advertisements should not be listened to by hosts. Hosts 101 need not know the identity of multicast routers. 103 Biswas, Cain, Haberman 2 104 The use of the multicast router advertisement is not precluded from 105 being used for other purposes. Extensible options have been included 106 in the advertisement message for future enhancements. 108 The following are justifications for inventing another router 109 discovery protocol: 111 o Using ICMP router discovery is not an appropriate solution 112 for multicast router discovery because: 1.) It may confuse 113 hosts listening to ICMP router advertisements; unicast and 114 multicast topologies may not be congruent. 2.) There is 115 no way to tell from an ICMP router advertisement if a 116 router is running a multicast routing protocol. 118 o By making multicast router discovery messages extensible, 119 future enhancements can be made. 121 o By inventing a generic IP layer message, multiple types of 122 messages per link layer are not needed (i.e. including 123 this functionality as part of IP is better than inventing 124 N discovery protocols for N layer-2 technologies). 126 Although multicast router discovery messages could be sent as ICMP 127 messages, IGMP was chosen because IGMP snooping switches already 128 snoop IGMP messages and because the intended first use of these 129 protocol messages is multicast specific. 131 2. Protocol Overview 133 IGMP Multicast Router Discovery consists of three messages for 134 discovering multicast routers. The Multicast Router Advertisement is 135 sent by routers to advertise IP multicast forwarding enabled on an 136 interface. The Multicast Router Solicitation is used by routers to 137 solicit Multicast Router Advertisements. The Multicast Router 138 Termination message is sent when a router terminates its multicast 139 routing functions. 141 Multicast routers send Multicast Router Advertisements (hereafter 142 called advertisements) periodically on all interfaces on which 143 multicast forwarding is enabled. 145 Multicast Router Advertisements are also sent in response to 146 Multicast Router Solicitations (hereafter called solicitations). 147 These are sent to solicit a response of Multicast Router 148 Advertisements from all multicast routers on a subnet. Solicitations 149 are sent to the ALL-Routers (224.0.0.2) multicast group. 151 Multicast Router Solicitations are sent whenever a device wishes to 152 discover multicast routers on a directly attached subnet. 154 Biswas, Cain, Haberman 3 155 Multicast Router Termination messages are sent when a router 156 terminates its multicast routing functions. 158 All IGMP Multicast Router Discovery messages are sent with an IP TTL 159 of 1 and contain the IP Router Alert Option [RFC2113] in their IP 160 header. All IGMP Multicast Router Discovery messages are sent with 161 to the All-Routers multicast group (224.0.0.2). 163 Other non-IP forwarding devices (e.g. layer-2 switches) may send 164 Multicast Router Solicitations to solicit Multicast Router 165 Advertisements. 167 3. Multicast Router Advertisement 169 3.1 Overview 171 Multicast Router Advertisements are sent periodically on all router 172 interfaces on which multicast forwarding is enabled. They are also 173 sent in response to Multicast Router Solicitations. 175 Router advertisements are sent upon expiration of a periodic timer, 176 when a router starts up, and when a router interface (that has IP 177 multicast forwarding enabled) initializes/restarts. Advertisements 178 are sent as IGMP messages to the All-Routers multicast address 179 (224.0.0.2) and should be rate-limited. 181 Router advertisements may contain any number of options. Two options 182 are defined in this document and MUST be supported by any 183 implementation of IGMP multicast router discovery. These options are 184 described in Section 5. Additional options may be defined as needed 185 by future work. 187 3.2 IP Header Fields 189 3.2.1 Source Address 191 An IP address belonging to the interface from which this message is 192 sent. If multiple source addresses are configured on an interface, 193 then the one chosen is implementation dependent. 195 3.2.2 Destination Address 197 Router Advertisements are sent to the All-Routers multicast address 198 (224.0.0.2). 200 3.2.3 Time-to-Live 202 The Time-to-Live field MUST be 1. 204 Biswas, Cain, Haberman 4 205 3.2.4 Protocol 207 The protocol field is set to IGMP (2). 209 3.3 Multicast Router Advertisement Message Format 211 0 1 2 3 212 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 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | Type | Ad. Interval | Checksum | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | Unused | Number of Options (N) | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | Option [1] (TLV encoded) | 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | Option [...] (TLV encoded) | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | Option [N] (TLV encoded) | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 3.3.1 Type Field 227 The type field is set to XX (to be assigned by IANA). 229 3.3.2 Advertisement Interval 231 This specifies the periodic time interval at which Multicast Router 232 Advertisements are sent in units of seconds. This value is set to 233 the configured MaxAdvertisementInterval variable. 235 3.3.3 Checksum 237 The checksum is the 16-bit one's complement of the one's complement 238 sum of the IGMP message, starting with the IGMP type. For computing 239 the checksum, the Checksum field is set to 0. 241 3.3.4 Number of Options (N) 243 The number of options contained in the router advertisement. If no 244 options are sent this field MUST be set to 0. 246 3.3.5 Option[1..N] 248 Options are encoded as TLV in the following manner: 250 Biswas, Cain, Haberman 5 251 0 1 2 3 252 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 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | Type | Length | Value | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 If the Number of Options field is not zero, a receiver MUST examine 258 all options. No strict ordering of options is enforced. 260 Type: Set to option type being advertised 262 Length: Length in bytes of Value field 264 Value: Option dependent value 266 3.4 Sending Multicast Router Advertisements 268 Router Advertisements are sent when the following events occur: 270 o When the periodic advertisement interval timer expires. 271 Note that it is not strictly periodic because the 272 advertisement interval is a random number between 273 MaxAdvertisementInterval and MinAdvertisementInterval. 275 o After waiting for a random delay less than 276 MaxInitialAdvertisementInterval when an interface first 277 comes up, is (re)initialized, or IGMP Multicast Router 278 Discovery is enabled. A router may send up to a maximum 279 of MaxInitialAdvertisements advertisements, waiting for a 280 random delay less than MaxInitialAdvertisementInterval 281 between each successive advertisement. Multiple messages 282 are sent for robustness in the face of packet loss on the 283 network. 285 This is to prevent an implosion of router advertisements. An example 286 of this occurring would be when many routers are powered on at the 287 same time. When a solicitation is received, a router advertisement 288 is sent in response with a random delay less than MAX_RESPONSE_DELAY. 289 If a solicitation is received while an advertisement is pending 290 (because of a recent solicitation), that solicitation will be 291 ignored. 293 Whenever an advertisement is sent, the periodic advertisement 294 interval timer must be reset. 296 3.5 Receiving Multicast Router Advertisements 298 Upon receiving a router advertisement, devices will validate the 299 message by the following criteria: 301 1. Verifying the IGMP checksum 303 Biswas, Cain, Haberman 6 304 2. IP Destination Address = All-Routers multicast address 306 A router advertisement not meeting the validity requirements should 307 be silently discarded or logged in a rate-limited manner. Devices 308 MUST process all options, discarding options that are not recognized. 310 If a router advertisement is not received for a particular neighbor 311 within NeighborDeadInterval time interval, then the neighbor is 312 considered to be unreachable. 314 3.6 Multicast Router Advertisement Configuration Variables 316 A router that implements multicast router discovery MUST allow for 317 the following variables to be configured by system management; 318 default values are specified so as to make it unnecessary to 319 configure any of these variables in many cases. 321 For each interface the following configurable variables are defined: 323 3.6.1 MaxAdvertisementInterval 325 The maximum time allowed between sending router advertisements from 326 the interface, in seconds. Must be no less than 2 seconds and no 327 greater than 180 seconds. 329 Default: 20 seconds. 331 3.6.2 MinAdvertisementInterval 333 The minimum time allowed between sending unsolicited router 334 advertisements from the interface, in seconds. Must be no less than 3 335 seconds and no greater than MaxAdvertisementInterval. 337 Default: 0.75 * MaxAdvertisementInterval 339 3.6.3 MaxInitialAdvertisementInterval 341 The first router advertisement out of an interface is sent after 342 waiting for a random interval less than this variable. This will 343 prevent a flood of router advertisements when many routers start up 344 at the same time. 346 Default: 2 seconds 348 3.6.4 MaxInitialAdvertisements 350 The maximum number of router advertisements that will be sent on a 351 subnet after a router boots. 353 Default: 3 355 Biswas, Cain, Haberman 7 356 3.6.5 NeighborDeadInterval 358 The maximum time allowed before a neighbor can be declared "dead". 359 This variable is defined in seconds. In order for all devices to have 360 a consistent state, it is necessary for the MaxAdvertisementInterval 361 to be configured the same on all routers per subnet. 363 Default: 3 * MaxAdvertisementInterval 365 4. Multicast Router Solicitation 367 4.1 Overview 369 Multicast Router Solicitations are used to solicit Multicast Router 370 Advertisements. These messages are used when a device wishes to 371 discover multicast routers. Upon receiving a solicitation on an 372 interface with IP multicast forwarding enabled and multicast router 373 discovery enabled, a router will respond with an advertisement. 375 Router solicitations may be sent when a device starts up, when an 376 interface (re)initializes, or when IGMP Multicast Router Discovery is 377 enabled. Solicitations are sent as IGMP messages to the All-Routers 378 multicast address (224.0.0.2) and must be rate-limited. 380 4.2 IP Header Fields 382 4.2.1 Source Address 384 An IP address belonging to the interface from which this message is 385 sent. If multiple source addresses are configured on an interface, 386 then the one chosen is implementation dependent. 388 If the solicitation is being sent from a device that does not have an 389 IP address (i.e. non-managed layer-2 switch), then the source address 390 should be set to all zeros. 392 4.2.2 Destination Address 394 Solicitation messages are sent to the All-Routers multicast address 395 (224.0.0.2). 397 4.2.3 Time-to-Live 399 The time-to-live field MUST be 1. 401 4.2.4 Protocol 403 The protocol field is set to IGMP (2). 405 Biswas, Cain, Haberman 8 406 4.3 Multicast Router Solicitation Message Format 408 0 1 2 3 409 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 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | Type | Reserved | Checksum | 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 4.3.1 Type Field 416 The type field is set to YY (to be assigned by IANA). 418 4.3.2 Reserved Field 420 Sent as 0; ignored on reception. 422 4.3.3 Checksum 424 The checksum is the 16-bit one's complement of the one's complement 425 sum of the IGMP message, starting with the IGMP type. For computing 426 the checksum, the Checksum field is set to 0. 428 4.4 Sending Multicast Router Solicitations 430 Router solicitations are sent when the following events occur: 432 1. After waiting for a random delay less than SOLICITATION_INTERVAL 433 when an interface first comes up, is (re)initialized, or IGMP 434 Multicast Router Discovery is enabled. A device may send up to 435 a maximum of MAX_SOLICITATIONS, waiting for a random delay less 436 than SOLICITATION_INTERVAL between each successive solicitation. 438 2. Optionally, for an implementation specific event. Solicitations 439 MUST be rate-limited; no more than MAX_SOLICITATIONS MUST be 440 sent in SOLICITATION_INTERVAL seconds. 442 4.5 Receiving Multicast Router Solicitations 444 Upon receiving a router solicitation, routers will validate the 445 message by: 447 1. Verifying the IGMP checksum 449 2. IP Destination Address = All-Routers multicast address 451 A router solicitation not meeting the validity requirements should be 452 silently discarded or logged in a rate-limited manner. 454 Solicitation message IP source addresses MUST NOT be used as part of 455 the validity check. 457 Biswas, Cain, Haberman 9 458 4.6 Multicast Router Solicitation Configuration Variables 460 There are no configurable variables with respect to router 461 solicitations. 463 5. Multicast Router Termination 465 5.1 Overview 467 The Multicast Router Termination message is used to expedite the 468 notification of a change in the status of a routers multicast 469 forwarding functions. 471 5.2 IP Header Fields 473 5.2.1 Source Address 475 An IP address belonging to the interface from which this message is 476 sent. If multiple source addresses are configured on an interface, 477 then the one chosen is implementation dependent. 479 5.2.2 Destination Address 481 Multicast Router Termination messages are sent to the All-Routers 482 multicast address (224.0.0.2). 484 5.2.3 Time-to-Live 486 The Time-to-Live field MUST be 1. 488 5.2.4 Protocol 490 The protocol field is set to IGMP (2). 492 5.3 Multicast Router Termination Message Format 494 0 1 2 3 495 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 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 | Type | Reserved | Checksum | 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 5.3.1 Type Field 502 The type field is set to ZZ (to be assigned by IANA). 504 5.3.2 Reserved Field 506 Sent as 0; ignored on reception. 508 5.3.3 Checksum 510 Biswas, Cain, Haberman 10 511 The checksum is the 16-bit one's complement of the one's complement 512 sum of the IGMP message, starting with the IGMP type. For computing 513 the checksum, the Checksum field is set to 0. 515 5.4 Sending Multicast Router Termination Messages 517 Multicast Router Termination messages are sent for three reasons: 519 1. Multicast forwarding is disabled on the interface 521 2. The interface is administratively disabled 523 3. The router is gracefully shutdown 525 5.5 Receiving Multicast Router Termination Messages 527 Upon receiving a termination message, routers will validate the 528 message by the following criteria: 530 1. Verifying the IGMP checksum 532 2. IP Destination Address = All-Routers multicast address 534 A termination message not meeting the validity requirements should be 535 silently discarded or logged in a rate-limited manner. 537 6. Multicast Router Discovery Protocol Constants 539 o MAX_RESPONSE_DELAY 2 seconds 541 o MAX_SOLICITATION_DELAY 1 second 543 o SOLICITATION_INTERVAL 3 seconds 545 o MAX_SOLICITATIONS 3 transmissions 547 7. Mandatory Advertisement Options 549 7.1 Overview of Options 551 The following options MUST be supported by an implementation of IGMP 552 Multicast Router Discovery: Query Interval Advertisement Option and 553 Robustness Variable Advertisement Option. These options advertise 554 specific IGMP variables and are sent in an advertisement depending on 555 the version of IGMP enabled on an interface. Although no 556 requirements exist for multicast routers at this time, it is assumed 557 that all multicast routers support the IGMP protocol. 559 Biswas, Cain, Haberman 11 560 7.2 Query Interval Advertisement Option 562 0 1 2 3 563 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 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 | Type=1 | Length=2 | IGMP Query Interval | 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 If a multicast router has any version of IGMP [RFC1112] enabled on an 569 interface on which IGMP Multicast Router Discovery is also enabled, 570 it MUST send all advertisements with the Query Interval Advertisement 571 Option. This option contains the IGMP "Query Interval" configured on 572 the interface on which advertisements are sent. 574 This option is sent regardless of whether the router is currently the 575 IGMP querier for the subnet. This option is sent regardless of what 576 version of IGMP the router is running. 578 IGMP Query Interval field is equal (in seconds) to the configured 579 IGMP "query interval" on the interface from which the advertisement 580 was sent. 582 7.3 Robustness Variable Advertisement Option 584 0 1 2 3 585 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 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 | Type=2 | Length=2 | Robustness Variable | 588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 If a multicast router has IGMPv2 [IGMPv2] or IGMPv3 [IGMPv3] enabled 591 on an interface on which IGMP Multicast Router Discovery is also 592 enabled, it MUST send all advertisements with the Robustness Variable 593 Advertisement Option. This option contains the IGMP "Robustness 594 Variable" configured on the interface on which advertisements are 595 sent. 597 This option is sent regardless of whether the router is currently the 598 IGMP querier for the subnet. This option may be omitted if IGMPv1 is 599 enabled on the interface. 601 Robustness Variable is an integer that MUST not be zero [IGMPv2] and 602 is equal to the IGMPv2 robustness variable. 604 8. IPv6 Support 606 The Multicast Router Discovery function for IPv6 is accomplished 607 using the Neighbor Discovery Protocol for IPv6 [RFC2461] (hereafter 608 called NDP). Specifically, the Router Advertisement message contains 609 new fields to support the discovery of multicast routers. For this 611 Biswas, Cain, Haberman 12 612 reason, the timing mechanisms defined for NDP will be used instead of 613 those defined in this document for IPv4 support. 615 8.1 Router Advertisement Message 617 The Router Advertisement message contains two new fields to support 618 the multicast router discovery mechanism. The modified message 619 format is: 621 0 1 2 3 622 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 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 | Type | Code | Checksum | 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 | Cur Hop Limit |M|O|H|D|E|Rsrvd| Router Lifetime | 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 | Reachable Time | 629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 630 | Retrans Timer | 631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 632 | Options ... 633 +-+-+-+-+-+-+-+-+-+-+-+- 635 The two new fields are the 'D' and 'E' bits. All other fields retain 636 their definitions and functions as described in Section 4.2 of the 637 NDP specification [RFC2461]. 639 8.1.1 Discovery (D) bit 641 The 'D' bit is used by a router to indicate support for the Multicast 642 Router Discovery protocol. A value of '1' indicates that the router 643 supports the discovery protocol. A value of '0' indicates no 644 support. This allows for backwards compatibility of the Router 645 Advertisement message. 647 8.1.2 Enabled (E) bit 649 The 'E' bit indicates whether multicast routing is enabled on the 650 router's interface. A value of '1' indicates that multicast 651 forwarding is enabled on the router's interface. A value of '0' 652 indicates that multicast forwarding is disabled. 654 When the state of multicast forwarding changes on an interface, a 655 router must stop its Router Advertisement timer, transmit a Router 656 Advertisement with the 'E' bit set to the value associated with the 657 new multicast forwarding state, and restart its Router Advertisement 658 timer. 660 8.2 Router Solicitations 662 Biswas, Cain, Haberman 13 663 An NDP Router Solicitation message can be sent to solicit a Router 664 Advertisement message in order to determine the multicast forwarding 665 state of a router. The periodic transmission of solicitation 666 messages is outlined in RFC 2461. 668 9. Security Considerations 670 The Multicast Router Advertisement message may allow rogue machines 671 to masquerade as multicast routers. This could allow those machines 672 to eavesdrop on multicast data transmission or create a denial of 673 service attack on multicast flows. However, these new messages are 674 extensible and that allows for the introduction of security 675 associations into the protocol. These security extensions could be 676 used to authenticate or encrypt the messages. 678 10. IANA Considerations 680 This document introduces three new IGMP messages. Each of these 681 messages requires a new IGMP 'Type' value. 683 11. Acknowledgements 685 ICMP Router Discovery [RFC1256] was used as a general model for IGMP 686 Multicast Router Discovery. 688 12. References 690 [RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256, 691 September 1991. 693 [RFC1112] Deering, S., "Host Extensions for IP Multicasting", 694 RFC 1112, August 1989. 696 [RFC2236] Fenner, W., "Internet Group Management Protocol, 697 Version 2", RFC 2236, November 1997. 699 [IGMPv3] Cain, B., Deering, S., Thyagarajan, A., "Internet Group 700 Management Protocol, Version 3", work in progress, 701 March 2001. 703 [RFC2113] Katz, D., "IP Router Alert Option," RFC 2113, April 1996. 705 [RFC2461] Narten, T., Nordmark, E., and Simpson, W., "Neighbor 706 Discovery IP Version 6 (IPv6)", RFC 2461, December 1998. 708 13. Authors' Addresses 710 Shantam Biswas 711 Nortel Networks 712 600 Technology Park Drive 713 Billerica, MA 01821 715 Biswas, Cain, Haberman 14 716 Email: sbiswas@baynetworks.com 717 Phone: 1-978-916-8048 719 Brad Cain 720 Cereva Networks 721 Email: bcain@cereva.com 723 Brian Haberman 724 Nortel Networks 725 4309 Emperor Blvd 726 Suite 200 727 Durham, NC 27703 728 Email: haberman@nortelnetworks.com 729 Phone: 1-919-992-4439 731 14. Full Copyright Statement 733 Copyright (C) The Internet Society (2001). All Rights Reserved. 735 This document and translations of it may be copied and furnished to 736 others, and derivative works that comment on or otherwise explain it 737 or assist in its implementation may be prepared, copied, published 738 and distributed, in whole or in part, without restriction of any 739 kind, provided that the above copyright notice and this paragraph 740 are included on all such copies and derivative works. However, this 741 document itself may not be modified in any way, such as by removing 742 the copyright notice ore references to the Internet Society or other 743 Internet organizations, except as needed for the purpose of 744 developing Internet standards in which case the procedures for 745 copyrights defined in the Internet Standards process must be 746 followed, or as required to translate it into languages other than 747 English. 749 The limited permissions granted above are perpetual and will not be 750 revoked by the Internet Society or its successors or assigns. 752 This document and the information contained herein is provided on an 753 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 754 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 755 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 756 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 757 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 759 Biswas, Cain, Haberman 15