idnits 2.17.00 (12 Aug 2021) /tmp/idnits7258/draft-ietf-idmr-igmp-mrdisc-05.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 13 longer pages, the longest (page 10) being 64 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 5 instances of too long lines in the document, the longest one being 3 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 139: '...his document and MUST be supported by ...' RFC 2119 keyword, line 160: '... The Time-to-Live field MUST be 1....' RFC 2119 keyword, line 201: '... are sent this field MUST be set to 0....' RFC 2119 keyword, line 214: '...d is not zero, a receiver MUST examine...' RFC 2119 keyword, line 267: '... MUST process all options, discardin...' (9 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Robustness Variable is an integer that MUST not be zero [IGMPv2] and is equal to the IGMPv2 robustness variable. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 175 == Missing Reference: 'N' is mentioned on line 179, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'IGMPv2' -- Possible downref: Non-RFC (?) normative reference: ref. 'IGMPv3' ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IDMR Working Group S. Biswas 2 Internet Draft B. Haberman 3 draft-ietf-idmr-igmp-mrdisc-05.txt Nortel Networks 4 October 2000 B. Cain 5 Expires April 2001 Mirror Image Internet 7 IGMP Multicast Router Discovery 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. Internet-Drafts are draft documents valid for a maximum of 18 six months and may be updated, replaced, or obsoleted by other 19 documents at any time. It is inappropriate to use Internet- Drafts 20 as reference material or to cite them other than as "work in 21 progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt. 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 Companies have been proposing IGMP snooping schemes for layer-2 32 bridging devices. A method for discovering multicast capable routers 33 is necessary for these schemes. An IGMP query message is inadequate 34 for discovering multicast routers as one querier is elected. In 35 order to "discover" multicast routers, we introduce three new types 36 of IGMP messages: Multicast Router Advertisement and Multicast Router 37 Solicitation. These two messages can be used by any device which 38 listens to IGMP to discovery multicast routers. Multicast Router 39 Solicitation messages may be used by any network device (e.g. layer-2 40 switch) to solicit discovery messages from multicast routers. 42 1. Introduction 44 Multicast router discovery messages are useful for discovering 45 multicast capable routers. This capability is useful in a layer-2 46 bridging domain with "IGMP snooping" type of schemes. By listening 47 to multicast router discovery messages, layer-2 devices can determine 48 where to send multicast source data and IGMP Host Membership Reports 50 Biswas, Cain, Haberman 1 52 [RFC1112] [IGMPv2]. Multicast source data and IGMP Host Membership 53 Reports must be received by all multicast routers on a segment. 54 Using IGMP Host Membership Queries to discover multicast routers is 55 not useful because of query suppression in IGMP. 57 Unlike ICMP router discovery messages [RFC1256], multicast router 58 discovery advertisements should not be listened to by hosts. Hosts 59 need not know the identity of multicast routers. 61 The use of the multicast router advertisement is not precluded from 62 being used for other purposes. Extensible options have been included 63 in the advertisement message for future enhancements. 65 The following are justifications for inventing another router 66 discovery protocol: 68 o Using ICMP router discovery is not an appropriate solution 69 for multicast router discovery because: 1.) It may confuse 70 hosts listening to ICMP router advertisements; unicast and 71 multicast topologies may not be congruent. 2.) There is 72 no way to tell from an ICMP router advertisement if a 73 router is running a multicast routing protocol. 75 o By making multicast router discovery messages extensible, 76 future enhancements can be made. 78 o By inventing a generic IP layer message, multiple types of 79 messages per link layer are not needed (i.e. including 80 this functionality as part of IP is better than inventing 81 N discovery protocols for N layer-2 technologies). 83 Although multicast router discovery messages could be sent as ICMP 84 messages, IGMP was chosen because IGMP snooping switches already 85 snoop IGMP messages and because the intended first use of these 86 protocol messages is multicast specific. 88 2. Protocol Overview 90 IGMP Multicast Router Discovery consists of three messages for 91 discovering multicast routers. The Multicast Router Advertisement is 92 sent by routers to advertise IP multicast forwarding enabled on an 93 interface. The Multicast Router Solicitation is used by routers to 94 solicit Multicast Router Advertisements. The Multicast Router 95 Termination message is sent when a router terminates its multicast 96 routing functions. 98 Multicast routers send Multicast Router Advertisements (hereafter 99 called advertisements) periodically on all interfaces on which 100 multicast forwarding is enabled. 102 Biswas, Cain, Haberman 2 103 Multicast Router Advertisements are also sent in response to 104 Multicast Router Solicitations (hereafter called solicitations). 105 These are sent to solicit a response of Multicast Router 106 Advertisements from all multicast routers on a subnet. Solicitations 107 are sent to the ALL-Routers (224.0.0.2) multicast group. 109 Multicast Router Solicitations are sent whenever a device wishes to 110 discover multicast routers on a directly attached subnet. 112 Multicast Router Termination messages are sent when a router 113 terminates its multicast routing functions. 115 All IGMP Multicast Router Discovery messages are sent with an IP TTL 116 of 1 and contain the IP Router Alert Option [RFC2113] in their IP 117 header. All IGMP Multicast Router Discovery messages are sent with 118 to the All-Routers multicast group (224.0.0.2). 120 Other non-IP forwarding devices (e.g. layer-2 switches) may send 121 Multicast Router Solicitations to solicit Multicast Router 122 Advertisements. 124 3. Multicast Router Advertisement 126 3.1 Overview 128 Multicast Router Advertisements are sent periodically on all router 129 interfaces on which multicast forwarding is enabled. They are also 130 sent in response to Multicast Router Solicitations. 132 Router advertisements are sent upon expiration of a periodic timer, 133 when a router starts up, and when a router interface (that has IP 134 multicast forwarding enabled) initializes/restarts. Advertisements 135 are sent as IGMP messages to the All-Routers multicast address 136 (224.0.0.2) and should be rate-limited. 138 Router advertisements may contain any number of options. Two options 139 are defined in this document and MUST be supported by any 140 implementation of IGMP multicast router discovery. These options are 141 described in Section 5. Additional options may be defined as needed 142 by future work. 144 3.2 IP Header Fields 146 3.2.1 Source Address 148 An IP address belonging to the interface from which this message is 149 sent. If multiple source addresses are configured on an interface, 150 then the one chosen is implementation dependent. 152 Biswas, Cain, Haberman 3 153 3.2.2 Destination Address 155 Router Advertisements are sent to the All-Routers multicast address 156 (224.0.0.2). 158 3.2.3 Time-to-Live 160 The Time-to-Live field MUST be 1. 162 3.2.4 Protocol 164 The protocol field is set to IGMP (2). 166 3.3 Multicast Router Advertisement Message Format 168 0 1 2 3 169 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 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | Type | Ad. Interval | Checksum | 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | Unused | Number of Options (N) | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 | Option [1] (TLV encoded) | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 | Option [...] (TLV encoded) | 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | Option [N] (TLV encoded) | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 3.3.1 Type Field 184 The type field is set to 0x24. 186 3.3.2 Advertisement Interval 188 This specifies the periodic time interval at which Multicast Router 189 Advertisements are sent in units of seconds. This value is set to 190 the configured MaxAdvertisementInterval variable. 192 3.3.3 Checksum 194 The checksum is the 16-bit one's complement of the one's complement 195 sum of the IGMP message, starting with the IGMP type. For computing 196 the checksum, the Checksum field is set to 0. 198 3.3.4 Number of Options (N) 200 The number of options contained in the router advertisement. If no 201 options are sent this field MUST be set to 0. 203 Biswas, Cain, Haberman 4 204 3.3.5 Option[1..N] 206 Options are encoded as TLV in the following manner: 208 0 1 2 3 209 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | Type | Length | Value | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 If the Number of Options field is not zero, a receiver MUST examine 215 all options. No strict ordering of options is enforced. 217 Type: Set to option type being advertised 219 Length: Length in bytes of Value field 221 Value: Option dependent value 223 3.4 Sending Multicast Router Advertisements 225 Router Advertisements are sent when the following events occur: 227 o When the periodic advertisement interval timer expires. 228 Note that it is not strictly periodic because the 229 advertisement interval is a random number between 230 MaxAdvertisementInterval and MinAdvertisementInterval. 232 o After waiting for a random delay less than 233 MaxInitialAdvertisementInterval when an interface first 234 comes up, is (re)initialized, or IGMP Multicast Router 235 Discovery is enabled. A router may send up to a maximum 236 of MaxInitialAdvertisements advertisements, waiting for a 237 random delay less than MaxInitialAdvertisementInterval 238 between each successive advertisement. Multiple messages 239 are sent for robustness in the face of packet loss on the 240 network. 242 This is to prevent an implosion of router advertisements. An example 243 of this occurring would be when many routers are powered on at the 244 same time. When a solicitation is received, a router advertisement 245 is sent in response with a random delay less than MAX_RESPONSE_DELAY. 246 If a solicitation is received while an advertisement is pending 247 (because of a recent solicitation), that solicitation will be 248 ignored. 250 Whenever an advertisement is sent, the periodic advertisement 251 interval timer must be reset. 253 3.5 Receiving Multicast Router Advertisements 255 Biswas, Cain, Haberman 5 256 Upon receiving a router advertisement, devices will validate the 257 message by the following criteria: 259 1. 260 Verifying the IGMP checksum 262 2. 263 IP Destination Address = All-Routers multicast address 265 A router advertisement not meeting the validity requirements should 266 be silently discarded or logged in a rate-limited manner. Devices 267 MUST process all options, discarding options that are not recognized. 269 If a router advertisement is not received for a particular neighbor 270 within NeighborDeadInterval time interval, then the neighbor is 271 considered to be unreachable. 273 3.6 Multicast Router Advertisement Configuration Variables 275 A router that implements multicast router discovery MUST allow for 276 the following variables to be configured by system management; 277 default values are specified so as to make it unnecessary to 278 configure any of these variables in many cases. 280 For each interface the following configurable variables are defined: 282 3.6.1 MaxAdvertisementInterval 284 The maximum time allowed between sending router advertisements from 285 the interface, in seconds. Must be no less than 2 seconds and no 286 greater than 180 seconds. 288 Default: 20 seconds. 290 3.6.2 MinAdvertisementInterval 292 The minimum time allowed between sending unsolicited router 293 advertisements from the interface, in seconds. Must be no less than 3 294 seconds and no greater than MaxAdvertisementInterval. 296 Default: 0.75 * MaxAdvertisementInterval 298 3.6.3 MaxInitialAdvertisementInterval 300 The first router advertisement out of an interface is sent after 301 waiting for a random interval less than this variable. This will 302 prevent a flood of router advertisements when many routers start up 303 at the same time. 305 Default: 2 seconds 307 3.6.4 MaxInitialAdvertisements 309 Biswas, Cain, Haberman 6 310 The maximum number of router advertisements that will be sent on a 311 subnet after a router boots. 313 Default: 3 315 3.6.5 NeighborDeadInterval 317 The maximum time allowed before a neighbor can be declared "dead". 318 This variable is defined in seconds. In order for all devices to have 319 a consistent state, it is necessary for the MaxAdvertisementInterval 320 to be configured the same on all routers per subnet. 322 Default: 3 * MaxAdvertisementInterval 324 4. Multicast Router Solicitation 326 4.1 Overview 328 Multicast Router Solicitations are used to solicit Multicast Router 329 Advertisements. These messages are used when a device wishes to 330 discover multicast routers. Upon receiving a solicitation on an 331 interface with IP multicast forwarding enabled and multicast router 332 discovery enabled, a router will respond with an advertisement. 334 Router solicitations may be sent when a device starts up, when an 335 interface (re)initializes, or when IGMP Multicast Router Discovery is 336 enabled. Solicitations are sent as IGMP messages to the All-Routers 337 multicast address (224.0.0.2) and must be rate-limited. 339 4.2 IP Header Fields 341 4.2.1 Source Address 343 An IP address belonging to the interface from which this message is 344 sent. If multiple source addresses are configured on an interface, 345 then the one chosen is implementation dependent. 347 If the solicitation is being sent from a device that does not have an 348 IP address (i.e. non-managed layer-2 switch), then the source address 349 should be set to all zeros. 351 4.2.2 Destination Address 353 Solicitation messages are sent to the All-Routers multicast address 354 (224.0.0.2). 356 4.2.3 Time-to-Live 358 The time-to-live field MUST be 1. 360 4.2.4 Protocol 362 Biswas, Cain, Haberman 7 363 The protocol field is set to IGMP (2). 365 4.3 Multicast Router Solicitation Message Format 367 0 1 2 3 368 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 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | Type | Reserved | Checksum | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 4.3.1 Type Field 375 The type field is set to 0x25. 377 4.3.2 Reserved Field 379 Sent as 0; ignored on reception. 381 4.3.3 Checksum 383 The checksum is the 16-bit one's complement of the one's complement 384 sum of the IGMP message, starting with the IGMP type. For computing 385 the checksum, the Checksum field is set to 0. 387 4.4 Sending Multicast Router Solicitations 389 Router solicitations are sent when the following events occur: 391 1. 392 After waiting for a random delay less than SOLICITATION_INTERVAL 393 when an interface first comes up, is (re)initialized, or IGMP 394 Multicast Router Discovery is enabled. A device may send up to 395 a maximum of MAX_SOLICITATIONS, waiting for a random delay less 396 than SOLICITATION_INTERVAL between each successive solicitation. 398 2. 399 Optionally, for an implementation specific event. Solicitations 400 MUST be rate-limited; no more than MAX_SOLICITATIONS MUST be 401 sent in SOLICITATION_INTERVAL seconds. 403 4.5 Receiving Multicast Router Solicitations 405 Upon receiving a router solicitation, routers will validate the 406 message by: 408 1. 409 Verifying the IGMP checksum 411 2. 412 IP Destination Address = All-Routers multicast address 414 A router solicitation not meeting the validity requirements should be 415 silently discarded or logged in a rate-limited manner. 417 Biswas, Cain, Haberman 8 418 Solicitation message IP source addresses MUST NOT be used as part of 419 the validity check. 421 4.6 Multicast Router Solicitation Configuration Variables 423 There are no configurable variables with respect to router 424 solicitations. 426 5. Multicast Router Termination 428 5.1 Overview 430 The Multicast Router Termination message is used to expedite the 431 notification of a change in the status of a routers multicast 432 forwarding functions. 434 5.2 IP Header Fields 436 5.2.1 Source Address 438 An IP address belonging to the interface from which this message is 439 sent. If multiple source addresses are configured on an interface, 440 then the one chosen is implementation dependent. 442 5.2.2 Destination Address 444 Multicast Router Termination messages are sent to the All-Routers 445 multicast address (224.0.0.2). 447 5.2.3 Time-to-Live 449 The Time-to-Live field MUST be 1. 451 5.2.4 Protocol 453 The protocol field is set to IGMP (2). 455 5.3 Multicast Router Termination Message Format 457 0 1 2 3 458 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 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 | Type | Reserved | Checksum | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 5.3.1 Type Field 465 The type field is set to 0x26. 467 5.3.2 Reserved Field 469 Biswas, Cain, Haberman 9 470 Sent as 0; ignored on reception. 472 5.3.3 Checksum 474 The checksum is the 16-bit one's complement of the one's complement 475 sum of the IGMP message, starting with the IGMP type. For computing 476 the checksum, the Checksum field is set to 0. 478 5.4 Sending Multicast Router Termination Messages 480 Multicast Router Termination messages are sent for three reasons: 482 1. 483 Multicast forwarding is disabled on the interface 485 2. 486 The interface is administratively disabled 488 3. 489 The router is gracefully shutdown 491 5.5 Receiving Multicast Router Termination Messages 493 Upon receiving a termination message, routers will validate the 494 message by the following criteria: 496 1. 497 Verifying the IGMP checksum 499 2. 500 IP Destination Address = All-Routers multicast address 502 A termination message not meeting the validity requirements should be 503 silently discarded or logged in a rate-limited manner. 505 6. Multicast Router Discovery Protocol Constants 507 o MAX_RESPONSE_DELAY 2 seconds 509 o MAX_SOLICITATION_DELAY 1 second 511 o SOLICITATION_INTERVAL 3 seconds 513 o MAX_SOLICITATIONS 3 transmissions 515 7. Mandatory Advertisement Options 517 7.1 Overview of Options 519 The following options MUST be supported by an implementation of IGMP 520 Multicast Router Discovery: Query Interval Advertisement Option and 521 Robustness Variable Advertisement Option. These options advertise 522 specific IGMP variables and are sent in an advertisement depending on 523 the version of IGMP enabled on an interface. Although no 524 requirements exist for multicast routers at this time, it is assumed 525 that all multicast routers support the IGMP protocol. 527 Biswas, Cain, Haberman 10 528 7.2 Query Interval Advertisement Option 530 0 1 2 3 531 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 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 | Type=1 | Length=2 | IGMP Query Interval | 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 If a multicast router has any version of IGMP [RFC1112] enabled on an 537 interface on which IGMP Multicast Router Discovery is also enabled, 538 it MUST send all advertisements with the Query Interval Advertisement 539 Option. This option contains the IGMP "Query Interval" configured on 540 the interface on which advertisements are sent. 542 This option is sent regardless of whether the router is currently the 543 IGMP querier for the subnet. This option is sent regardless of what 544 version of IGMP the router is running. 546 IGMP Query Interval field is equal (in seconds) to the configured 547 IGMP "query interval" on the interface from which the advertisement 548 was sent. 550 7.3 Robustness Variable Advertisement Option 552 0 1 2 3 553 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 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 | Type=2 | Length=2 | Robustness Variable | 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 If a multicast router has IGMPv2 [IGMPv2] or IGMPv3 [IGMPv3] enabled 559 on an interface on which IGMP Multicast Router Discovery is also 560 enabled, it MUST send all advertisements with the Robustness Variable 561 Advertisement Option. This option contains the IGMP "Robustness 562 Variable" configured on the interface on which advertisements are 563 sent. 565 This option is sent regardless of whether the router is currently the 566 IGMP querier for the subnet. This option may be omitted if IGMPv1 is 567 enabled on the interface. 569 Robustness Variable is an integer that MUST not be zero [IGMPv2] and 570 is equal to the IGMPv2 robustness variable. 572 8. IPv6 Support 574 The Multicast Router Discovery function for IPv6 is accomplished 575 using the Neighbor Discovery Protocol for IPv6 [RFC2461] (hereafter 576 called NDP). Specifically, the Router Advertisement message contains 577 new fields to support the discovery of multicast routers. For this 579 Biswas, Cain, Haberman 11 580 reason, the timing mechanisms defined for NDP will be used instead of 581 those defined in this document for IPv4 support. 583 8.1 Router Advertisement Message 585 The Router Advertisement message contains two new fields to support 586 the multicast router discovery mechanism. The modified message 587 format is: 589 0 1 2 3 590 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 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 | Type | Code | Checksum | 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 | Cur Hop Limit |M|O|H|D|E|Rsrvd| Router Lifetime | 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 | Reachable Time | 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 | Retrans Timer | 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 | Options ... 601 +-+-+-+-+-+-+-+-+-+-+- 603 The two new fields are the 'D' and 'E' bits. All other fields retain 604 their definitions and functions as described in Section 4.2 of the 605 NDP specification [RFC2461]. 607 8.1.1 Discovery (D) bit 609 The 'D' bit is used by a router to indicate support for the Multicast 610 Router Discovery protocol. A value of '1' indicates that the router 611 supports the discovery protocol. A value of '0' indicates no 612 support. This allows for backwards compatibility of the Router 613 Advertisement message. 615 8.1.2 Enabled (E) bit 617 The 'E' bit indicates whether multicast routing is enabled on the 618 router's interface. A value of '1' indicates that multicast 619 forwarding is enabled on the router's interface. A value of '0' 620 indicates that multicast forwarding is disabled. 622 When the state of multicast forwarding changes on an interface, a 623 router must stop its Router Advertisement timer, transmit a Router 624 Advertisement with the 'E' bit set to the value associated with the 625 new multicast forwarding state, and restart its Router Advertisement 626 timer. 628 8.2 Router Solicitations 630 Biswas, Cain, Haberman 12 631 An NDP Router Solicitation message can be sent to solicit a Router 632 Advertisement message in order to determine the multicast forwarding 633 state of a router. The periodic transmission of solicitation 634 messages is outlined in RFC 2461. 636 9. Acknowledgements 638 ICMP Router Discovery [RFC1256] was used as a general model for IGMP 639 Multicast Router Discovery. 641 10. References 643 [RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256, 644 September 1991. 646 [RFC1112] Deering, S., "Host Extensions for IP Multicasting", 647 RFC 1112, August 1989. 649 [IGMPv2] Fenner, W., "Internet Group Management Protocol, 650 Version 2", Internet-Draft, November 1997. 652 [IGMPv3] Cain, B., Deering, S., Thyagarajan, A., "Internet Group 653 Management Protocol, Version 3", Internet-Draft, November 654 1997. 656 [RFC2113] Katz, D., "IP Router Alert Option," RFC 2113, April 1996. 658 [RFC2461] Narten, T., Nordmark, E., and Simpson, W., "Neighbor 659 Discovery IP Version 6 (IPv6)", RFC 2461, December 1998. 661 10. Authors' Addresses 663 Shantam Biswas 664 Nortel Networks 665 600 Technology Park Drive 666 Billerica, MA 01821 667 Email: sbiswas@baynetworks.com 668 Phone: 1-978-916-8048 670 Brad Cain 671 Mirror Image Internet 672 49 Dragon Court 673 Woburn, MA 01801 674 Email: brad.cain@mirror-image.com 675 Phone: 1-781-276-1904 677 Brian Haberman 678 Nortel Networks 679 4309 Emperor Blvd 680 Suite 200 681 Durham, NC 27703 683 Biswas, Cain, Haberman 13 684 Email: haberman@nortelnetworks.com 685 Phone: 1-919-992-4439 687 Biswas, Cain, Haberman 14