idnits 2.17.1 draft-ietf-idmr-igmp-mrdisc-09.txt: -(109): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(119): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(694): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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? == There are 18 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard 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 6 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 177: '... (224.0.0.1) and SHOULD be rate-limite...' RFC 2119 keyword, line 180: '...his document and MUST be supported by ...' RFC 2119 keyword, line 200: '... The Time-to-Live field MUST be 1....' RFC 2119 keyword, line 242: '... are sent this field MUST be set to 0....' RFC 2119 keyword, line 254: '...d is not zero, a receiver MUST examine...' (11 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: Biswas, Cain, Haberman 12 Robustness Variable is an integer that MUST not be zero [IGMPv2][RFC2710] and is equal to the IGMPv2/MLDv1 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 216 == Missing Reference: 'N' is mentioned on line 220, but not defined == Missing Reference: 'IGMPv2' is mentioned on line 612, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'IGMPv3' ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) -- Possible downref: Non-RFC (?) normative reference: ref. 'MLDv2' Summary: 6 errors (**), 0 flaws (~~), 6 warnings (==), 5 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-09.txt B. Cain 5 September 2002 Storigen Systems 6 Expires March 2003 B. Haberman 7 Caspian Networks 9 Multicast Router Discovery 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. Internet-Drafts are draft documents valid for a maximum of 20 six months and may be updated, replaced, or obsoleted by other 21 documents at any time. It is inappropriate to use Internet- Drafts 22 as reference material or to cite them other than as "work in 23 progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 The concept of IGMP snooping requires the ability to identify the 34 location of multicast routers. Since IGMP (and MLD) snooping is not 35 standardized, there are many mechanisms in use to identify the 36 multicast routers. However, this scenario can lead to 37 interoperability issues between multicast routers and layer-2 38 switches from different vendors. 40 This document introduces a general mechanism that allows for the 41 discovery of multicast routers. By introducing these new messages, 42 snooping devices have a uniform means of identifying multicast 43 routers without dependency on particular routing protocols. These 44 messages may also be used to convey configuration parameters to all 45 systems on a network. In addition, other devices that may need to 46 discover multicast routers can utilize these messages. 48 Table of Contents 50 1. Introduction....................................................2 51 2. Protocol Overview...............................................3 53 Biswas, Cain, Haberman 1 54 3. Multicast Router Advertisement..................................4 55 3.1 Overview.......................................................4 56 3.2 IP Header Fields...............................................4 57 3.3 Multicast Router Advertisement Message Format..................5 58 3.4 Sending Multicast Router Advertisements........................6 59 3.5 Receiving Multicast Router Advertisements......................6 60 3.6 Multicast Router Advertisement Configuration Variables.........7 61 4. Multicast Router Solicitation...................................8 62 4.1 Overview.......................................................8 63 4.2 IP Header Fields...............................................8 64 4.3 Multicast Router Solicitation Message Format...................9 65 4.4 Sending Multicast Router Solicitations.........................9 66 4.5 Receiving Multicast Router Solicitations.......................9 67 4.6 Multicast Router Solicitation Configuration Variables.........10 68 5. Multicast Router Termination...................................10 69 5.1 Overview......................................................10 70 5.2 IP Header Fields..............................................10 71 5.3 Multicast Router Termination Message Format...................10 72 5.4 Sending Multicast Router Termination Messages.................11 73 5.5 Receiving Multicast Router Termination Messages...............11 74 6. Multicast Router Discovery Protocol Constants..................11 75 7. Mandatory Advertisement Options................................11 76 7.1 Overview of Options...........................................11 77 7.2 Query Interval Advertisement Option...........................12 78 7.3 Robustness Variable Advertisement Option......................12 79 8. IPv6 Support...................................................13 80 8.1 Router Advertisement Message..................................13 81 8.2 Router Solicitations..........................................14 82 9. Security Considerations........................................14 83 10. IANA Considerations...........................................14 84 11. Acknowledgements..............................................15 85 12. References....................................................15 86 13. Authors' Addresses............................................15 87 14. Full Copyright Statement......................................16 89 1. Introduction 91 Multicast router discovery messages are useful for discovering 92 multicast capable routers. This capability is useful in a layer-2 93 bridging domain with "snooping" type of schemes. By listening to 94 multicast router discovery messages, layer-2 devices can determine 95 where to send multicast source data and IGMP Host Membership Reports 96 [RFC1112] [RFC2236]. Multicast source data and IGMP Host Membership 97 Reports must be received by all multicast routers on a segment. 98 Using IGMP Host Membership Queries to discover multicast routers is 99 not useful because of query suppression in IGMP. 101 The use of the multicast router advertisement is not precluded from 102 being used for other purposes. Extensible options have been included 103 in the advertisement message for future enhancements. 105 Biswas, Cain, Haberman 2 106 The following are justifications for inventing another router 107 discovery protocol: 109 � Using ICMP router discovery is not an appropriate solution 110 for multicast router discovery because: 1.) It may confuse 111 hosts listening to ICMP router advertisements; unicast and 112 multicast topologies may not be congruent. 2.) There is 113 no way to tell from an ICMP router advertisement if a 114 router is running a multicast routing protocol. 116 � By making multicast router discovery messages extensible, 117 future enhancements can be made. 119 � By inventing a generic IP layer message, multiple types of 120 messages per link layer are not needed (i.e. including 121 this functionality as part of IP is better than inventing 122 N discovery protocols for N layer-2 technologies). 124 Although multicast router discovery messages could be sent as ICMP 125 messages, IGMP was chosen because IGMP snooping switches already 126 snoop IGMP messages and the protocol is multicast specific. 128 2. Protocol Overview 130 IGMP Multicast Router Discovery consists of three messages for 131 discovering multicast routers. The Multicast Router Advertisement is 132 sent by routers to advertise that IP multicast forwarding is enabled. 133 Devices may send Multicast Router Solicitation messages in order to 134 solicit Multicast Router Advertisements from multicast routers. The 135 Multicast Router Termination message is sent when a router terminates 136 its multicast routing functions. 138 Multicast routers send Multicast Router Advertisements (hereafter 139 called advertisements) periodically on all interfaces on which 140 multicast forwarding is enabled. Advertisements are also sent in 141 response to Multicast Router Solicitations (hereafter called 142 solicitations). 144 Multicast Router Solicitations are sent whenever a device wishes to 145 discover multicast routers on a directly attached subnet. 147 Multicast Router Terminations (hereafter called terminations) are 148 sent when a router terminates its multicast routing functions. 150 All IGMP Multicast Router Discovery messages are sent with an IP TTL 151 of 1 and contain the IP Router Alert Option [RFC2113] in their IP 152 header. 154 Advertisement and termination messages are sent to the All-Systems 155 multicast group (224.0.0.1). 157 Biswas, Cain, Haberman 3 158 Solicitation messages are sent to the All-Routers multicast group 159 (224.0.0.2). 161 Both IP (e.g. layer-3 switches) and non-IP forwarding devices (e.g. 162 layer-2 switches) may send Multicast Router Solicitations to solicit 163 Multicast Router Advertisements. 165 3. Multicast Router Advertisement 167 3.1 Overview 169 Multicast Router Advertisements are sent periodically on all router 170 interfaces on which multicast forwarding is enabled. They are also 171 sent in response to Multicast Router Solicitations. 173 Router advertisements are sent upon expiration of a periodic timer, 174 when a router starts up, and when a router interface (that has IP 175 multicast forwarding enabled) initializes/restarts. Advertisements 176 are sent as IGMP messages to the All-Systems multicast address 177 (224.0.0.1) and SHOULD be rate-limited. 179 Router advertisements may contain any number of options. Two options 180 are defined in this document and MUST be supported by any 181 implementation of IGMP multicast router discovery. These options are 182 described in Section 5. Additional options may be defined as needed 183 by future work. 185 3.2 IP Header Fields 187 3.2.1 Source Address 189 An IP address belonging to the interface from which this message is 190 sent. If multiple source addresses are configured on an interface, 191 then the one chosen is implementation dependent. 193 3.2.2 Destination Address 195 Router Advertisements are sent to the All-Systems multicast address 196 (224.0.0.1). 198 3.2.3 Time-to-Live 200 The Time-to-Live field MUST be 1. 202 3.2.4 Protocol 204 The protocol field is set to IGMP (2). 206 Biswas, Cain, Haberman 4 207 3.3 Multicast Router Advertisement Message Format 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 | Ad. Interval | Checksum | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | Unused | Number of Options (N) | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | Option [1] (TLV encoded) | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | Option [...] (TLV encoded) | 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | Option [N] (TLV encoded) | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 3.3.1 Type Field 225 The type field is set to XX (to be assigned by IANA). 227 3.3.2 Advertisement Interval 229 This specifies the periodic time interval at which Multicast Router 230 Advertisements are sent in units of seconds. This value is set to 231 the configured MaxAdvertisementInterval variable. 233 3.3.3 Checksum 235 The checksum is the 16-bit one's complement of the one's complement 236 sum of the IGMP message, starting with the IGMP type. For computing 237 the checksum, the Checksum field is set to 0. 239 3.3.4 Number of Options (N) 241 The number of options contained in the router advertisement. If no 242 options are sent this field MUST be set to 0. 244 3.3.5 Option[1..N] 246 Options are encoded as TLV in the following manner: 248 0 1 2 3 249 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 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | Type | Length | Value | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 If the Number of Options field is not zero, a receiver MUST examine 255 all options. No strict ordering of options is enforced. 257 Biswas, Cain, Haberman 5 258 Type: Set to option type being advertised 260 Length: Length in bytes of Value field 262 Value: Option dependent value 264 3.4 Sending Multicast Router Advertisements 266 Router Advertisements are sent when the following events occur: 268 � When the periodic advertisement interval timer expires. 269 Note that it is not strictly periodic because the 270 advertisement interval is a random number between 271 MaxAdvertisementInterval and MinAdvertisementInterval. 273 � After waiting for a random delay less than 274 MaxInitialAdvertisementInterval when an interface first 275 comes up, is (re)initialized, or IGMP Multicast Router 276 Discovery is enabled. A router may send up to a maximum 277 of MaxInitialAdvertisements advertisements, waiting for a 278 random delay less than MaxInitialAdvertisementInterval 279 between each successive advertisement. Multiple messages 280 are sent for robustness in the face of packet loss on the 281 network. 283 This is to prevent an implosion of router advertisements. An example 284 of this occurring would be when many routers are powered on at the 285 same time. When a solicitation is received, a router advertisement 286 is sent in response with a random delay less than MAX_RESPONSE_DELAY. 287 If a solicitation is received while an advertisement is pending 288 (because of a recent solicitation), that solicitation will be 289 ignored. 291 Whenever an advertisement is sent, the periodic advertisement 292 interval timer must be reset. 294 3.5 Receiving Multicast Router Advertisements 296 Upon receiving a router advertisement, devices will validate the 297 message by the following criteria: 299 1. Verifying the IGMP checksum 301 2. IP Destination Address = All-Systems multicast address 303 A router advertisement not meeting the validity requirements should 304 be silently discarded or logged in a rate-limited manner. Devices 305 MUST process all options, discarding options that are not recognized. 307 Biswas, Cain, Haberman 6 308 If a router advertisement is not received for a particular neighbor 309 within NeighborDeadInterval time interval, then the neighbor is 310 considered to be unreachable. 312 3.6 Multicast Router Advertisement Configuration Variables 314 A router that implements multicast router discovery MUST allow for 315 the following variables to be configured by system management; 316 default values are specified so as to make it unnecessary to 317 configure any of these variables in many cases. 319 For each interface the following configurable variables are defined: 321 3.6.1 MaxAdvertisementInterval 323 The maximum time allowed between sending router advertisements from 324 the interface, in seconds. Must be no less than 2 seconds and no 325 greater than 180 seconds. 327 Default: 20 seconds. 329 3.6.2 MinAdvertisementInterval 331 The minimum time allowed between sending unsolicited router 332 advertisements from the interface, in seconds. Must be no less than 3 333 seconds and no greater than MaxAdvertisementInterval. 335 Default: 0.75 * MaxAdvertisementInterval 337 3.6.3 MaxInitialAdvertisementInterval 339 The first router advertisement out of an interface is sent after 340 waiting for a random interval less than this variable. This will 341 prevent a flood of router advertisements when many routers start up 342 at the same time. 344 Default: 2 seconds 346 3.6.4 MaxInitialAdvertisements 348 The maximum number of router advertisements that will be sent on a 349 subnet after a router boots. 351 Default: 3 353 3.6.5 NeighborDeadInterval 355 The maximum time allowed before a neighbor can be declared "dead". 356 This variable is defined in seconds. In order for all devices to have 357 a consistent state, it is necessary for the MaxAdvertisementInterval 358 to be configured the same on all devices on the subnet. 360 Biswas, Cain, Haberman 7 361 Default: 3 * MaxAdvertisementInterval 363 4. Multicast Router Solicitation 365 4.1 Overview 367 Multicast Router Solicitations are used to solicit Multicast Router 368 Advertisements. These messages are used when a device wishes to 369 discover multicast routers. Upon receiving a solicitation on an 370 interface with IP multicast forwarding enabled and multicast router 371 discovery enabled, a router will respond with an advertisement. 373 Router solicitations may be sent when a device starts up, when an 374 interface (re)initializes, or when IGMP Multicast Router Discovery is 375 enabled. Solicitations are sent as IGMP messages to the All-Routers 376 multicast address (224.0.0.2) and SHOULD be rate-limited. 378 4.2 IP Header Fields 380 4.2.1 Source Address 382 An IP address belonging to the interface from which this message is 383 sent. If multiple source addresses are configured on an interface, 384 then the one chosen is implementation dependent. 386 If the solicitation is being sent from a device that does not have an 387 IP address (i.e. non-managed layer-2 switch), then the source address 388 should be set to all zeros. 390 4.2.2 Destination Address 392 Solicitation messages are sent to the All-Routers multicast address 393 (224.0.0.2). 395 4.2.3 Time-to-Live 397 The time-to-live field MUST be 1. 399 4.2.4 Protocol 401 The protocol field is set to IGMP (2). 403 Biswas, Cain, Haberman 8 404 4.3 Multicast Router Solicitation Message Format 406 0 1 2 3 407 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | Type | Reserved | Checksum | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 4.3.1 Type Field 414 The type field is set to YY (to be assigned by IANA). 416 4.3.2 Reserved Field 418 Sent as 0; ignored on reception. 420 4.3.3 Checksum 422 The checksum is the 16-bit one's complement of the one's complement 423 sum of the IGMP message, starting with the IGMP type. For computing 424 the checksum, the Checksum field is set to 0. 426 4.4 Sending Multicast Router Solicitations 428 Router solicitations are sent when the following events occur: 430 1. After waiting for a random delay less than SOLICITATION_INTERVAL 431 when an interface first comes up, is (re)initialized, or IGMP 432 Multicast Router Discovery is enabled. A device may send up to 433 a maximum of MAX_SOLICITATIONS, waiting for a random delay less 434 than SOLICITATION_INTERVAL between each successive solicitation. 436 2. Optionally, for an implementation specific event. Solicitations 437 MUST be rate-limited; no more than MAX_SOLICITATIONS MUST be 438 sent in SOLICITATION_INTERVAL seconds. 440 4.5 Receiving Multicast Router Solicitations 442 Upon receiving a router solicitation, routers will validate the 443 message by: 445 1. Verifying the IGMP checksum 447 2. IP Destination Address = All-Routers multicast address 449 A router solicitation not meeting the validity requirements should be 450 silently discarded or logged in a rate-limited manner. 452 Solicitation message IP source addresses MUST NOT be used as part of 453 the validity check. 455 Biswas, Cain, Haberman 9 456 4.6 Multicast Router Solicitation Configuration Variables 458 There are no configurable variables with respect to router 459 solicitations. 461 5. Multicast Router Termination 463 5.1 Overview 465 The Multicast Router Termination message is used to expedite the 466 notification of a change in the status of a routers multicast 467 forwarding functions. 469 5.2 IP Header Fields 471 5.2.1 Source Address 473 An IP address belonging to the interface from which this message is 474 sent. If multiple source addresses are configured on an interface, 475 then the one chosen is implementation dependent. 477 5.2.2 Destination Address 479 Multicast Router Termination messages are sent to the All-Systems 480 multicast address (224.0.0.1). 482 5.2.3 Time-to-Live 484 The Time-to-Live field MUST be 1. 486 5.2.4 Protocol 488 The protocol field is set to IGMP (2). 490 5.3 Multicast Router Termination Message Format 492 0 1 2 3 493 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 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 | Type | Reserved | Checksum | 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 5.3.1 Type Field 500 The type field is set to ZZ (to be assigned by IANA). 502 5.3.2 Reserved Field 504 Sent as 0; ignored on reception. 506 5.3.3 Checksum 508 Biswas, Cain, Haberman 10 509 The checksum is the 16-bit one's complement of the one's complement 510 sum of the IGMP message, starting with the IGMP type. For computing 511 the checksum, the Checksum field is set to 0. 513 5.4 Sending Multicast Router Termination Messages 515 Multicast Router Termination messages are sent for three reasons: 517 1. Multicast forwarding is disabled on the interface 519 2. The interface is administratively disabled 521 3. The router is gracefully shutdown 523 5.5 Receiving Multicast Router Termination Messages 525 Upon receiving a termination message, routers will validate the 526 message by the following criteria: 528 1. Verifying the IGMP checksum 530 2. IP Destination Address = All-Systems multicast address 532 A termination message not meeting the validity requirements should be 533 silently discarded or logged in a rate-limited manner. 535 6. Multicast Router Discovery Protocol Constants 537 The following list identifies constants used in the Multicast Router 538 Discovery protocol. These constants are used in the calculation of 539 parameters. 541 � MAX_RESPONSE_DELAY 2 seconds 543 � MAX_SOLICITATION_DELAY 1 second 545 � SOLICITATION_INTERVAL 3 seconds 547 � MAX_SOLICITATIONS 3 transmissions 549 7. Mandatory Advertisement Options 551 7.1 Overview of Options 553 The following options MUST be supported by an implementation of 554 Multicast Router Discovery: Query Interval Advertisement Option and 555 Robustness Variable Advertisement Option. These options advertise 556 specific group management variables on a per-interface basis. 557 Although no requirements exist for multicast routers at this time, it 559 Biswas, Cain, Haberman 11 560 is assumed that all multicast routers support a group management 561 protocol. 563 7.2 Query Interval Advertisement Option 565 0 1 2 3 566 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 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 | Type=x | Length=2 | IGMP Query Interval | 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 � For IPv4, x=1 572 � For IPv6, x=n (to be assigned by IANA) 574 If a multicast router has any version of IGMP or MLD [RFC2710, MLDv2] 575 enabled on an interface on which Multicast Router Discovery is also 576 enabled, it MUST send all advertisements with the Query Interval 577 Advertisement Option. This option contains the IGMP/MLD "Query 578 Interval" configured on the interface on which advertisements are 579 sent. 581 This option is sent regardless of whether the router is currently the 582 IGMP querier for the subnet. 584 IGMP Query Interval field is equal (in seconds) to the configured 585 IGMP/MLD "query interval" on the interface from which the 586 advertisement was sent. 588 7.3 Robustness Variable Advertisement Option 590 0 1 2 3 591 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 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 | Type=y | Length=2 | Robustness Variable | 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 � For IPv4, y=2 597 � For IPv6, y=m (to be assigned by IANA) 599 If a multicast router has IGMPv2 [IGMPv2], IGMPv3 [IGMPv3] or MLD 600 [RFC2710, MLDv2] enabled on an interface on which IGMP Multicast 601 Router Discovery is also enabled, it MUST send all advertisements 602 with the Robustness Variable Advertisement Option. This option 603 contains the IGMP/MLD "Robustness Variable" configured on the 604 interface on which advertisements are sent. 606 This option is sent regardless of whether the router is currently the 607 IGMP querier for the subnet. This option may be omitted if IGMPv1 is 608 enabled on the interface. 610 Biswas, Cain, Haberman 12 611 Robustness Variable is an integer that MUST not be zero 612 [IGMPv2][RFC2710] and is equal to the IGMPv2/MLDv1 robustness 613 variable. 615 8. IPv6 Support 617 The Multicast Router Discovery function for IPv6 is accomplished 618 using the Neighbor Discovery Protocol for IPv6 [RFC2461] (hereafter 619 called NDP). Specifically, the Router Advertisement message contains 620 new fields to support the discovery of multicast routers. For this 621 reason, the timing mechanisms defined for NDP will be used instead of 622 those defined in this document for IPv4 support. It should be noted 623 that the options defined in section 7 are not mandatory for IPv6 624 support. 626 8.1 Router Advertisement Message 628 The Router Advertisement message contains two new fields to support 629 the multicast router discovery mechanism. The modified message 630 format is: 632 0 1 2 3 633 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 634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 635 | Type | Code | Checksum | 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 | Cur Hop Limit |M|O|H|D|E|Rsrvd| Router Lifetime | 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 | Reachable Time | 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 | Retrans Timer | 642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 | Options ... 644 +-+-+-+-+-+-+-+-+-+-+-+- 646 The two new fields are the 'D' and 'E' bits. All other fields retain 647 their definitions and functions as described in Section 4.2 of the 648 NDP specification [RFC2461]. 650 8.1.1 Discovery (D) bit 652 The 'D' bit is used by a router to indicate support for the Multicast 653 Router Discovery protocol. A value of '1' indicates that the router 654 supports the discovery protocol. A value of '0' indicates no 655 support. This allows for backwards compatibility of the Router 656 Advertisement message. 658 8.1.2 Enabled (E) bit 660 The 'E' bit indicates whether multicast routing is enabled on the 661 router's interface. A value of '1' indicates that multicast 663 Biswas, Cain, Haberman 13 664 forwarding is enabled on the router's interface. A value of '0' 665 indicates that multicast forwarding is disabled. 667 When the state of multicast forwarding changes on an interface, a 668 router must stop its Router Advertisement timer, transmit a Router 669 Advertisement with the 'E' bit set to the value associated with the 670 new multicast forwarding state, and restart its Router Advertisement 671 timer. 673 8.2 Router Solicitations 675 An NDP Router Solicitation message can be sent to solicit a Router 676 Advertisement message in order to determine the multicast forwarding 677 state of a router. The periodic transmission of solicitation 678 messages is outlined in RFC 2461. 680 9. Security Considerations 682 The Multicast Router Advertisement message may allow rogue machines 683 to masquerade as multicast routers. This could allow those machines 684 to eavesdrop on multicast data transmission or create a denial of 685 service attack on multicast flows. However, these new messages are 686 extensible and that allows for the introduction of security 687 associations into the protocol. These security extensions could be 688 used to authenticate or encrypt the messages. 690 10. IANA Considerations 692 This document introduces three new IGMP messages. Each of these 693 messages requires a new IGMP 'Type' value. This document requests 694 IANA to assign three new IGMP �Type� values to the Multicast Router 695 Discovery protocol (for Advertisements, Solicitations, and 696 Terminations). 698 IPv6 support requests the allocation of two new Neighbor Discovery 699 Option Types to support the mandatory Multicast Router Discovery 700 options (found in Sections 7.2 and 7.3). 702 IPv4 support of this protocol requires the administration of the 703 Multicast Router Discovery option space. This document requests that 704 options be allocated using an IESG Approval or Standards Action 705 processes. In addition, this document requests that the options 706 defined, the Query Interval Advertisement option (Section 7.2) and 707 the Robustness Variable Advertisement option (Section 7.3) be 708 allocated the values specified in the respective sections. 710 This protocol also requests the creation of a new IANA registry to 711 manage the Multicast Router Discovery Code Values for IPv4 support. 712 New Code Values for the Multicast Router Discovery Type values are 713 allocated using IESG Approval or Standards Action processes. 715 Biswas, Cain, Haberman 14 716 11. Acknowledgements 718 ICMP Router Discovery [RFC1256] was used as a general model for IGMP 719 Multicast Router Discovery. 721 12. References 723 [RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256, 724 September 1991. 726 [RFC1112] Deering, S., "Host Extensions for IP Multicasting", 727 RFC 1112, August 1989. 729 [RFC2236] Fenner, W., "Internet Group Management Protocol, 730 Version 2", RFC 2236, November 1997. 732 [IGMPv3] Cain, B., et al, "Internet Group Management Protocol, 733 Version 3", work in progress. 735 [RFC2113] Katz, D., "IP Router Alert Option," RFC 2113, April 1996. 737 [RFC2461] Narten, T., Nordmark, E., and Simpson, W., "Neighbor 738 Discovery IP Version 6 (IPv6)", RFC 2461, December 1998. 740 [RFC2710] Deering, S., Fenner, B., and Haberman, B., �Multicast 741 Listener Discovery (MLD) for IPv6�, RFC 2710, October 742 1999. 744 [MLDv2] Vida, R., et al, �Multicast Listener Discovery Version 2 745 (MLDv2) for IPv6�, work in progress. 747 13. Authors' Addresses 749 Shantam Biswas 750 Nortel Networks 751 600 Technology Park Drive 752 Billerica, MA 01821 753 Email: sbiswas@baynetworks.com 754 Phone: 1-978-916-8048 756 Brad Cain 757 Storigen Systems 758 Email: bcain@storigen.com 760 Brian Haberman 761 Caspian Networks 762 Email: bkhabs@nc.rr.com 764 Biswas, Cain, Haberman 15 765 14. Full Copyright Statement 767 Copyright (C) The Internet Society (2001). All Rights Reserved. 769 This document and translations of it may be copied and furnished to 770 others, and derivative works that comment on or otherwise explain it 771 or assist in its implementation may be prepared, copied, published 772 and distributed, in whole or in part, without restriction of any 773 kind, provided that the above copyright notice and this paragraph 774 are included on all such copies and derivative works. However, this 775 document itself may not be modified in any way, such as by removing 776 the copyright notice ore references to the Internet Society or other 777 Internet organizations, except as needed for the purpose of 778 developing Internet standards in which case the procedures for 779 copyrights defined in the Internet Standards process must be 780 followed, or as required to translate it into languages other than 781 English. 783 The limited permissions granted above are perpetual and will not be 784 revoked by the Internet Society or its successors or assigns. 786 This document and the information contained herein is provided on an 787 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 788 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 789 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 790 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 791 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 793 Biswas, Cain, Haberman 16