idnits 2.17.1 draft-ietf-idmr-igmp-mrdisc-10.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 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 13 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 : ---------------------------------------------------------------------------- ** There are 6 instances of too long lines in the document, the longest one being 2 characters in excess of 72. 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) == Missing Reference: 'RFC 2119' is mentioned on line 131, but not defined -- Looks like a reference, but probably isn't: '1' on line 220 == Missing Reference: 'N' is mentioned on line 224, but not defined == Missing Reference: 'IGMPv2' is mentioned on line 616, but not defined == Unused Reference: 'RFC2119' is defined on line 727, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) -- Possible downref: Non-RFC (?) normative reference: ref. 'MLDv2' Summary: 4 errors (**), 0 flaws (~~), 8 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-10.txt B. Cain 5 January 2003 Storigen Systems 6 Expires July 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 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 130 this document are to be interpreted as described in [RFC 2119]. 132 2. Protocol Overview 134 IGMP Multicast Router Discovery consists of three messages for 135 discovering multicast routers. The Multicast Router Advertisement is 136 sent by routers to advertise that IP multicast forwarding is enabled. 137 Devices may send Multicast Router Solicitation messages in order to 138 solicit Multicast Router Advertisements from multicast routers. The 139 Multicast Router Termination message is sent when a router terminates 140 its multicast routing functions. 142 Multicast routers send Multicast Router Advertisements (hereafter 143 called advertisements) periodically on all interfaces on which 144 multicast forwarding is enabled. Advertisements are also sent in 145 response to Multicast Router Solicitations (hereafter called 146 solicitations). 148 Multicast Router Solicitations are sent whenever a device wishes to 149 discover multicast routers on a directly attached subnet. 151 Multicast Router Terminations (hereafter called terminations) are 152 sent when a router terminates its multicast routing functions. 154 Biswas, Cain, Haberman 3 155 All IGMP Multicast Router Discovery messages are sent with an IP TTL 156 of 1 and contain the IP Router Alert Option [RFC2113] in their IP 157 header. 159 Advertisement and termination messages are sent to the All-Systems 160 multicast group (224.0.0.1). 162 Solicitation messages are sent to the All-Routers multicast group 163 (224.0.0.2). 165 Both IP (e.g. layer-3 switches) and non-IP forwarding devices (e.g. 166 layer-2 switches) may send Multicast Router Solicitations to solicit 167 Multicast Router Advertisements. 169 3. Multicast Router Advertisement 171 3.1 Overview 173 Multicast Router Advertisements are sent periodically on all router 174 interfaces on which multicast forwarding is enabled. They are also 175 sent in response to Multicast Router Solicitations. 177 Router advertisements are sent upon expiration of a periodic timer, 178 when a router starts up, and when a router interface (that has IP 179 multicast forwarding enabled) initializes/restarts. Advertisements 180 are sent as IGMP messages to the All-Systems multicast address 181 (224.0.0.1) and SHOULD be rate-limited. 183 Router advertisements may contain any number of options. Two options 184 are defined in this document and MUST be supported by any 185 implementation of IGMP multicast router discovery. These options are 186 described in Section 5. Additional options may be defined as needed 187 by future work. 189 3.2 IP Header Fields 191 3.2.1 Source Address 193 An IP address belonging to the interface from which this message is 194 sent. If multiple source addresses are configured on an interface, 195 then the one chosen is implementation dependent. 197 3.2.2 Destination Address 199 Router Advertisements are sent to the All-Systems multicast address 200 (224.0.0.1). 202 3.2.3 Time-to-Live 204 Biswas, Cain, Haberman 4 205 The Time-to-Live field MUST be 1. 207 3.2.4 Protocol 209 The protocol field is set to IGMP (2). 211 3.3 Multicast Router Advertisement Message Format 213 0 1 2 3 214 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 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | Type | Ad. Interval | Checksum | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | Unused | Number of Options (N) | 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | Option [1] (TLV encoded) | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | Option [...] (TLV encoded) | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | Option [N] (TLV encoded) | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 3.3.1 Type Field 229 The type field is set to XX (to be assigned by IANA). 231 3.3.2 Advertisement Interval 233 This specifies the periodic time interval at which Multicast Router 234 Advertisements are sent in units of seconds. This value is set to 235 the configured MaxAdvertisementInterval variable. 237 3.3.3 Checksum 239 The checksum is the 16-bit one's complement of the one's complement 240 sum of the IGMP message, starting with the IGMP type. For computing 241 the checksum, the Checksum field is set to 0. 243 3.3.4 Number of Options (N) 245 The number of options contained in the router advertisement. If no 246 options are sent this field MUST be set to 0. 248 3.3.5 Option[1..N] 250 Options are encoded as TLV in the following manner: 252 Biswas, Cain, Haberman 5 253 0 1 2 3 254 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 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | Type | Length | Value | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 If the Number of Options field is not zero, a receiver MUST examine 260 all options. No strict ordering of options is enforced. 262 Type: Set to option type being advertised 264 Length: Length in bytes of Value field 266 Value: Option dependent value 268 3.4 Sending Multicast Router Advertisements 270 Router Advertisements are sent when the following events occur: 272 � When the periodic advertisement interval timer expires. 273 Note that it is not strictly periodic because the 274 advertisement interval is a random number between 275 MaxAdvertisementInterval and MinAdvertisementInterval. 277 � After waiting for a random delay less than 278 MaxInitialAdvertisementInterval when an interface first 279 comes up, is (re)initialized, or IGMP Multicast Router 280 Discovery is enabled. A router may send up to a maximum 281 of MaxInitialAdvertisements advertisements, waiting for a 282 random delay less than MaxInitialAdvertisementInterval 283 between each successive advertisement. Multiple messages 284 are sent for robustness in the face of packet loss on the 285 network. 287 This is to prevent an implosion of router advertisements. An example 288 of this occurring would be when many routers are powered on at the 289 same time. When a solicitation is received, a router advertisement 290 is sent in response with a random delay less than MAX_RESPONSE_DELAY. 291 If a solicitation is received while an advertisement is pending 292 (because of a recent solicitation), that solicitation will be 293 ignored. 295 Whenever an advertisement is sent, the periodic advertisement 296 interval timer must be reset. 298 3.5 Receiving Multicast Router Advertisements 300 Upon receiving a router advertisement, devices will validate the 301 message by the following criteria: 303 1. Verifying the IGMP checksum 305 Biswas, Cain, Haberman 6 306 2. IP Destination Address = All-Systems multicast address 308 A router advertisement not meeting the validity requirements should 309 be silently discarded or logged in a rate-limited manner. Devices 310 MUST process all options, discarding options that are not recognized. 312 If a router advertisement is not received for a particular neighbor 313 within NeighborDeadInterval time interval, then the neighbor is 314 considered to be unreachable. 316 3.6 Multicast Router Advertisement Configuration Variables 318 A router that implements multicast router discovery MUST allow for 319 the following variables to be configured by system management; 320 default values are specified so as to make it unnecessary to 321 configure any of these variables in many cases. 323 For each interface the following configurable variables are defined: 325 3.6.1 MaxAdvertisementInterval 327 The maximum time allowed between sending router advertisements from 328 the interface, in seconds. Must be no less than 2 seconds and no 329 greater than 180 seconds. 331 Default: 20 seconds. 333 3.6.2 MinAdvertisementInterval 335 The minimum time allowed between sending unsolicited router 336 advertisements from the interface, in seconds. Must be no less than 3 337 seconds and no greater than MaxAdvertisementInterval. 339 Default: 0.75 * MaxAdvertisementInterval 341 3.6.3 MaxInitialAdvertisementInterval 343 The first router advertisement out of an interface is sent after 344 waiting for a random interval less than this variable. This will 345 prevent a flood of router advertisements when many routers start up 346 at the same time. 348 Default: 2 seconds 350 3.6.4 MaxInitialAdvertisements 352 The maximum number of router advertisements that will be sent on a 353 subnet after a router boots. 355 Default: 3 357 Biswas, Cain, Haberman 7 358 3.6.5 NeighborDeadInterval 360 The maximum time allowed before a neighbor can be declared "dead". 361 This variable is defined in seconds. In order for all devices to have 362 a consistent state, it is necessary for the MaxAdvertisementInterval 363 to be configured the same on all devices on the subnet. 365 Default: 3 * MaxAdvertisementInterval 367 4. Multicast Router Solicitation 369 4.1 Overview 371 Multicast Router Solicitations are used to solicit Multicast Router 372 Advertisements. These messages are used when a device wishes to 373 discover multicast routers. Upon receiving a solicitation on an 374 interface with IP multicast forwarding enabled and multicast router 375 discovery enabled, a router will respond with an advertisement. 377 Router solicitations may be sent when a device starts up, when an 378 interface (re)initializes, or when IGMP Multicast Router Discovery is 379 enabled. Solicitations are sent as IGMP messages to the All-Routers 380 multicast address (224.0.0.2) and SHOULD be rate-limited. 382 4.2 IP Header Fields 384 4.2.1 Source Address 386 An IP address belonging to the interface from which this message is 387 sent. If multiple source addresses are configured on an interface, 388 then the one chosen is implementation dependent. 390 If the solicitation is being sent from a device that does not have an 391 IP address (i.e. non-managed layer-2 switch), then the source address 392 should be set to all zeros. 394 4.2.2 Destination Address 396 Solicitation messages are sent to the All-Routers multicast address 397 (224.0.0.2). 399 4.2.3 Time-to-Live 401 The time-to-live field MUST be 1. 403 4.2.4 Protocol 405 The protocol field is set to IGMP (2). 407 Biswas, Cain, Haberman 8 408 4.3 Multicast Router Solicitation Message Format 410 0 1 2 3 411 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 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | Type | Reserved | Checksum | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 4.3.1 Type Field 418 The type field is set to YY (to be assigned by IANA). 420 4.3.2 Reserved Field 422 Sent as 0; ignored on reception. 424 4.3.3 Checksum 426 The checksum is the 16-bit one's complement of the one's complement 427 sum of the IGMP message, starting with the IGMP type. For computing 428 the checksum, the Checksum field is set to 0. 430 4.4 Sending Multicast Router Solicitations 432 Router solicitations are sent when the following events occur: 434 1. After waiting for a random delay less than SOLICITATION_INTERVAL 435 when an interface first comes up, is (re)initialized, or IGMP 436 Multicast Router Discovery is enabled. A device may send up to 437 a maximum of MAX_SOLICITATIONS, waiting for a random delay less 438 than SOLICITATION_INTERVAL between each successive solicitation. 440 2. Optionally, for an implementation specific event. Solicitations 441 MUST be rate-limited; no more than MAX_SOLICITATIONS MUST be 442 sent in SOLICITATION_INTERVAL seconds. 444 4.5 Receiving Multicast Router Solicitations 446 Upon receiving a router solicitation, routers will validate the 447 message by: 449 1. Verifying the IGMP checksum 451 2. IP Destination Address = All-Routers multicast address 453 A router solicitation not meeting the validity requirements should be 454 silently discarded or logged in a rate-limited manner. 456 Solicitation message IP source addresses MUST NOT be used as part of 457 the validity check. 459 Biswas, Cain, Haberman 9 460 4.6 Multicast Router Solicitation Configuration Variables 462 There are no configurable variables with respect to router 463 solicitations. 465 5. Multicast Router Termination 467 5.1 Overview 469 The Multicast Router Termination message is used to expedite the 470 notification of a change in the status of a routers multicast 471 forwarding functions. 473 5.2 IP Header Fields 475 5.2.1 Source Address 477 An IP address belonging to the interface from which this message is 478 sent. If multiple source addresses are configured on an interface, 479 then the one chosen is implementation dependent. 481 5.2.2 Destination Address 483 Multicast Router Termination messages are sent to the All-Systems 484 multicast address (224.0.0.1). 486 5.2.3 Time-to-Live 488 The Time-to-Live field MUST be 1. 490 5.2.4 Protocol 492 The protocol field is set to IGMP (2). 494 5.3 Multicast Router Termination Message Format 496 0 1 2 3 497 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 | Type | Reserved | Checksum | 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 5.3.1 Type Field 504 The type field is set to ZZ (to be assigned by IANA). 506 5.3.2 Reserved Field 508 Sent as 0; ignored on reception. 510 5.3.3 Checksum 512 Biswas, Cain, Haberman 10 513 The checksum is the 16-bit one's complement of the one's complement 514 sum of the IGMP message, starting with the IGMP type. For computing 515 the checksum, the Checksum field is set to 0. 517 5.4 Sending Multicast Router Termination Messages 519 Multicast Router Termination messages are sent for three reasons: 521 1. Multicast forwarding is disabled on the interface 523 2. The interface is administratively disabled 525 3. The router is gracefully shutdown 527 5.5 Receiving Multicast Router Termination Messages 529 Upon receiving a termination message, routers will validate the 530 message by the following criteria: 532 1. Verifying the IGMP checksum 534 2. IP Destination Address = All-Systems multicast address 536 A termination message not meeting the validity requirements should be 537 silently discarded or logged in a rate-limited manner. 539 6. Multicast Router Discovery Protocol Constants 541 The following list identifies constants used in the Multicast Router 542 Discovery protocol. These constants are used in the calculation of 543 parameters. 545 � MAX_RESPONSE_DELAY 2 seconds 547 � MAX_SOLICITATION_DELAY 1 second 549 � SOLICITATION_INTERVAL 3 seconds 551 � MAX_SOLICITATIONS 3 transmissions 553 7. Mandatory Advertisement Options 555 7.1 Overview of Options 557 The following options MUST be supported by an implementation of 558 Multicast Router Discovery: Query Interval Advertisement Option and 559 Robustness Variable Advertisement Option. These options advertise 560 specific group management variables on a per-interface basis. 561 Although no requirements exist for multicast routers at this time, it 563 Biswas, Cain, Haberman 11 564 is assumed that all multicast routers support a group management 565 protocol. 567 7.2 Query Interval Advertisement Option 569 0 1 2 3 570 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 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 | Type=x | Length=2 | IGMP Query Interval | 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 � For IPv4, x=1 576 � For IPv6, x=n (to be assigned by IANA) 578 If a multicast router has any version of IGMP or MLD [RFC2710, MLDv2] 579 enabled on an interface on which Multicast Router Discovery is also 580 enabled, it MUST send all advertisements with the Query Interval 581 Advertisement Option. This option contains the IGMP/MLD "Query 582 Interval" configured on the interface on which advertisements are 583 sent. 585 This option is sent regardless of whether the router is currently the 586 IGMP querier for the subnet. 588 IGMP Query Interval field is equal (in seconds) to the configured 589 IGMP/MLD "query interval" on the interface from which the 590 advertisement was sent. 592 7.3 Robustness Variable Advertisement Option 594 0 1 2 3 595 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 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 | Type=y | Length=2 | Robustness Variable | 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 � For IPv4, y=2 601 � For IPv6, y=m (to be assigned by IANA) 603 If a multicast router has IGMPv2 [IGMPv2], IGMPv3 [IGMPv3] or MLD 604 [RFC2710, MLDv2] enabled on an interface on which IGMP Multicast 605 Router Discovery is also enabled, it MUST send all advertisements 606 with the Robustness Variable Advertisement Option. This option 607 contains the IGMP/MLD "Robustness Variable" configured on the 608 interface on which advertisements are sent. 610 This option is sent regardless of whether the router is currently the 611 IGMP querier for the subnet. This option may be omitted if IGMPv1 is 612 enabled on the interface. 614 Biswas, Cain, Haberman 12 615 Robustness Variable is an integer that MUST not be zero 616 [IGMPv2][RFC2710] and is equal to the IGMPv2/MLDv1 robustness 617 variable. 619 8. IPv6 Support 621 The Multicast Router Discovery function for IPv6 is accomplished 622 using the Neighbor Discovery Protocol for IPv6 [RFC2461] (hereafter 623 called NDP). Specifically, the Router Advertisement message contains 624 new fields to support the discovery of multicast routers. For this 625 reason, the timing mechanisms defined for NDP will be used instead of 626 those defined in this document for IPv4 support. It should be noted 627 that the options defined in section 7 are not mandatory for IPv6 628 support. 630 8.1 Router Advertisement Message 632 The Router Advertisement message contains two new fields to support 633 the multicast router discovery mechanism. The modified message 634 format is: 636 0 1 2 3 637 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 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 | Type | Code | Checksum | 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 | Cur Hop Limit |M|O|H|D|E|Rsrvd| Router Lifetime | 642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 | Reachable Time | 644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 645 | Retrans Timer | 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 647 | Options ... 648 +-+-+-+-+-+-+-+-+-+-+-+- 650 The two new fields are the 'D' and 'E' bits. All other fields retain 651 their definitions and functions as described in Section 4.2 of the 652 NDP specification [RFC2461]. 654 8.1.1 Discovery (D) bit 656 The 'D' bit is used by a router to indicate support for the Multicast 657 Router Discovery protocol. A value of '1' indicates that the router 658 supports the discovery protocol. A value of '0' indicates no 659 support. This allows for backwards compatibility of the Router 660 Advertisement message. 662 8.1.2 Enabled (E) bit 664 The 'E' bit indicates whether multicast routing is enabled on the 665 router's interface. A value of '1' indicates that multicast 667 Biswas, Cain, Haberman 13 668 forwarding is enabled on the router's interface. A value of '0' 669 indicates that multicast forwarding is disabled. 671 When the state of multicast forwarding changes on an interface, a 672 router must stop its Router Advertisement timer, transmit a Router 673 Advertisement with the 'E' bit set to the value associated with the 674 new multicast forwarding state, and restart its Router Advertisement 675 timer. 677 8.2 Router Solicitations 679 An NDP Router Solicitation message can be sent to solicit a Router 680 Advertisement message in order to determine the multicast forwarding 681 state of a router. The periodic transmission of solicitation 682 messages is outlined in RFC 2461. 684 9. Security Considerations 686 The Multicast Router Advertisement message may allow rogue machines 687 to masquerade as multicast routers. This could allow those machines 688 to eavesdrop on multicast data transmission or create a denial of 689 service attack on multicast flows. However, these new messages are 690 extensible and that allows for the introduction of security 691 associations into the protocol. These security extensions could be 692 used to authenticate or encrypt the messages. 694 10. IANA Considerations 696 This document introduces three new IGMP messages. Each of these 697 messages requires a new IGMP 'Type' value. This document requests 698 IANA to assign three new IGMP 'Type' values to the Multicast Router 699 Discovery protocol (for Advertisements, Solicitations, and 700 Terminations). 702 IPv6 support requests the allocation of two new Neighbor Discovery 703 Option Types to support the mandatory Multicast Router Discovery 704 options (found in Sections 7.2 and 7.3). 706 IPv4 support of this protocol requires the administration of the 707 Multicast Router Discovery option space. This document requests that 708 options be allocated using an IESG Approval or Standards Action 709 processes. In addition, this document requests that the options 710 defined, the Query Interval Advertisement option (Section 7.2) and 711 the Robustness Variable Advertisement option (Section 7.3) be 712 allocated the values specified in the respective sections. 714 This protocol also requests the creation of a new IANA registry to 715 manage the Multicast Router Discovery Code Values for IPv4 support. 716 New Code Values for the Multicast Router Discovery Type values are 717 allocated using IESG Approval or Standards Action processes. 719 Biswas, Cain, Haberman 14 720 11. Acknowledgements 722 ICMP Router Discovery [RFC1256] was used as a general model for IGMP 723 Multicast Router Discovery. 725 12. Normative References 727 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 728 Requirement Levels", RFC 2119, BCP 14, March 1997. 730 [RFC2236] Fenner, W., "Internet Group Management Protocol, 731 Version 2", RFC 2236, November 1997. 733 [IGMPv3] Cain, B., et al, "Internet Group Management Protocol, 734 Version 3", RFC 3376, October 2002. 736 [RFC2461] Narten, T., Nordmark, E., and Simpson, W., "Neighbor 737 Discovery IP Version 6 (IPv6)", RFC 2461, December 1998. 739 [RFC2710] Deering, S., Fenner, B., and Haberman, B., "Multicast 740 Listener Discovery (MLD) for IPv6", RFC 2710, October 741 1999. 743 [MLDv2] Vida, R., et al, "Multicast Listener Discovery Version 2 744 (MLDv2) for IPv6", work in progress. 746 13. Informative References 748 [RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256, 749 September 1991. 751 [RFC1112] Deering, S., "Host Extensions for IP Multicasting", 752 RFC 1112, August 1989. 754 [RFC2113] Katz, D., "IP Router Alert Option," RFC 2113, April 1996. 756 14. Authors' Addresses 758 Shantam Biswas 759 Nortel Networks 760 600 Technology Park Drive 761 Billerica, MA 01821 762 Email: sbiswas@baynetworks.com 763 Phone: 1-978-916-8048 765 Brad Cain 766 Storigen Systems 768 Biswas, Cain, Haberman 15 769 Email: bcain@storigen.com 771 Brian Haberman 772 Caspian Networks 773 1 Park Drive, Suite 300 774 Research Triangle Park, NC 27709 776 Email: bkhabs@nc.rr.com 777 Phone: +1-919-949-4828 779 15. Full Copyright Statement 781 Copyright (C) The Internet Society (2003). All Rights Reserved. 783 This document and translations of it may be copied and furnished to 784 others, and derivative works that comment on or otherwise explain it 785 or assist in its implementation may be prepared, copied, published 786 and distributed, in whole or in part, without restriction of any 787 kind, provided that the above copyright notice and this paragraph 788 are included on all such copies and derivative works. However, this 789 document itself may not be modified in any way, such as by removing 790 the copyright notice ore references to the Internet Society or other 791 Internet organizations, except as needed for the purpose of 792 developing Internet standards in which case the procedures for 793 copyrights defined in the Internet Standards process must be 794 followed, or as required to translate it into languages other than 795 English. 797 The limited permissions granted above are perpetual and will not be 798 revoked by the Internet Society or its successors or assigns. 800 This document and the information contained herein is provided on an 801 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 802 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 803 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 804 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 805 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 807 This document expires in July, 2003. 809 Biswas, Cain, Haberman 16 810 Biswas, Cain, Haberman 17