idnits 2.17.1 draft-ietf-idmr-igmp-mrdisc-04.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 65 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 4 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 269: '...scarded. Devices MUST process all opti...' (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.) -- The document date (January 2001) is 8501 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 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. Cain 3 draft-ietf-idmr-igmp-mrdisc-04.txt B. Haberman 4 July 2000 Nortel Networks 5 Expires January 2001 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 two new types of 36 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 that the IGMP type is 0x24 262 2. 263 Verifying the IGMP checksum 265 3. 266 IP Destination Address = All-Routers multicast address 268 A router advertisement not meeting the validity requirements will be 269 silently discarded. Devices MUST process all options, discarding 270 options that are not recognized. 272 If a router advertisement is not received for a particular neighbor 273 within NeighborDeadInterval time interval, then the neighbor is 274 considered to be unreachable. 276 3.6 Multicast Router Advertisement Configuration Variables 278 A router that implements multicast router discovery MUST allow for 279 the following variables to be configured by system management; 280 default values are specified so as to make it unnecessary to 281 configure any of these variables in many cases. 283 For each interface the following configurable variables are defined: 285 3.6.1 MaxAdvertisementInterval 287 The maximum time allowed between sending router advertisements from 288 the interface, in seconds. Must be no less than 2 seconds and no 289 greater than 180 seconds. 291 Default: 20 seconds. 293 3.6.2 MinAdvertisementInterval 295 The minimum time allowed between sending unsolicited router 296 advertisements from the interface, in seconds. Must be no less than 3 297 seconds and no greater than MaxAdvertisementInterval. 299 Default: 0.75 * MaxAdvertisementInterval 301 3.6.3 MaxInitialAdvertisementInterval 303 The first router advertisement out of an interface is sent after 304 waiting for a random interval less than this variable. This will 305 prevent a flood of router advertisements when many routers start up 306 at the same time. 308 Default: 2 seconds 310 Biswas, Cain, Haberman 6 311 3.6.4 MaxInitialAdvertisements 313 The maximum number of router advertisements that will be sent on a 314 subnet after a router boots. 316 Default: 3 318 3.6.5 NeighborDeadInterval 320 The maximum time allowed before a neighbor can be declared "dead". 321 This variable is defined in seconds. In order for all devices to have 322 a consistent state, it is necessary for the MaxAdvertisementInterval 323 to be configured the same on all routers per subnet. 325 Default: 3 * MaxAdvertisementInterval 327 4. Multicast Router Solicitation 329 4.1 Overview 331 Multicast Router Solicitations are used to solicit Multicast Router 332 Advertisements. These messages are used when a device wishes to 333 discover multicast routers. Upon receiving a solicitation on an 334 interface with IP multicast forwarding enabled and multicast router 335 discovery enabled, a router will respond with an advertisement. 337 Router solicitations may be sent when a router starts up, when a 338 router interface (re)initializes, or when IGMP Multicast Router 339 Discovery is enabled. Solicitations are sent as IGMP messages to the 340 All-Routers multicast address (224.0.0.2) and must be rate-limited. 342 4.2 IP Header Fields 344 4.2.1 Source Address 346 An IP address belonging to the interface from which this message is 347 sent. If multiple source addresses are configured on an interface, 348 then the one chosen is implementation dependent. 350 If the solicitation is being sent from a device that does not have an 351 IP address (i.e. non-managed layer-2 switch), then the source address 352 should be set to all zeros. 354 4.2.2 Destination Address 356 Solicitation messages are sent to the All-Routers multicast address 357 (224.0.0.2). 359 4.2.3 Time-to-Live 361 The time-to-live field MUST be 1. 363 Biswas, Cain, Haberman 7 364 4.2.4 Protocol 366 The protocol field is set to IGMP (2). 368 4.3 Multicast Router Solicitation Message Format 370 0 1 2 3 371 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 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 | Type | Reserved | Checksum | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 4.3.1 Type Field 378 The type field is set to 0x25. 380 4.3.2 Reserved Field 382 Sent as 0; ignored on reception. 384 4.3.3 Checksum 386 The checksum is the 16-bit one's complement of the one's complement 387 sum of the IGMP message, starting with the IGMP type. For computing 388 the checksum, the Checksum field is set to 0. 390 4.4 Sending Multicast Router Solicitations 392 Router solicitations are sent when the following events occur: 394 1. 395 After waiting for a random delay less than SOLICITATION_INTERVAL 396 when an interface first comes up, is (re)initialized, or IGMP 397 Multicast Router Discovery is enabled. A router may send up to 398 a maximum of MAX_SOLICITATIONS, waiting for a random delay less 399 than SOLICITATION_INTERVAL between each successive solicitation. 401 2. 402 Optionally, for an implementation specific event. Solicitations 403 MUST be rate-limited; no more than MAX_SOLICITATIONS MUST be 404 sent in SOLICITATION_INTERVAL seconds. 406 4.5 Receiving Multicast Router Solicitations 408 Upon receiving a router solicitation, routers will validate the 409 message by: 411 1. 412 Verifying that the IGMP type is 0x25 414 2. 415 Verifying the IGMP checksum 417 3. 418 IP Destination Address = All-Routers multicast address 420 Biswas, Cain, Haberman 8 421 A router solicitation not meeting the validity requirements will be 422 silently discarded. 424 Solicitation message IP source addresses MUST NOT be used as part of 425 the validity check. 427 4.6 Multicast Router Solicitation Configuration Variables 429 There are no configurable variables with respect to router 430 solicitations. 432 5. Multicast Router Termination 434 5.1 Overview 436 The Multicast Router Termination message is used to expedite the 437 notification of a change in the status of a routers multicast 438 forwarding functions. 440 5.2 IP Header Fields 442 5.2.1 Source Address 444 An IP address belonging to the interface from which this message is 445 sent. If multiple source addresses are configured on an interface, 446 then the one chosen is implementation dependent. 448 5.2.2 Destination Address 450 Multicast Router Termination messages are sent to the All-Routers 451 multicast address (224.0.0.2). 453 5.2.3 Time-to-Live 455 The Time-to-Live field MUST be 1. 457 5.2.4 Protocol 459 The protocol field is set to IGMP (2). 461 5.3 Multicast Router Termination Message Format 463 0 1 2 3 464 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 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | Type | Reserved | Checksum | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 5.3.1 Type Field 471 Biswas, Cain, Haberman 9 472 The type field is set to 0x26. 474 5.3.2 Reserved Field 476 Sent as 0; ignored on reception. 478 5.3.3 Checksum 480 The checksum is the 16-bit one's complement of the one's complement 481 sum of the IGMP message, starting with the IGMP type. For computing 482 the checksum, the Checksum field is set to 0. 484 5.4 Sending Multicast Router Termination Messages 486 Multicast Router Termination messages are sent for three reasons: 488 1. 489 Multicast forwarding is disabled on the interface 491 2. 492 The interface is administratively disabled 494 3. 495 The router is gracefully shutdown 497 5.5 Receiving Multicast Router Termination Messages 499 Upon receiving a termination message, routers will validate the 500 message by the following criteria: 502 1. 503 Verifying that the IGMP type is 0x26 505 2. 506 Verifying the IGMP checksum 508 3. 509 IP Destination Address = All-Routers multicast address 511 A termination message not meeting the validity requirements will be 512 silently discarded. 514 6. Multicast Router Discovery Protocol Constants 516 o MAX_RESPONSE_DELAY 2 seconds 518 o MAX_SOLICITATION_DELAY 1 second 520 o SOLICITATION_INTERVAL 3 seconds 522 o MAX_SOLICITATIONS 3 transmissions 524 7. Mandatory Advertisement Options 526 7.1 Overview of Options 528 Biswas, Cain, Haberman 10 529 The following options MUST be supported by an implementation of IGMP 530 Multicast Router Discovery: Query Interval Advertisement Option and 531 Robustness Variable Advertisement Option. These options advertise 532 specific IGMP variables and are sent in an advertisement depending on 533 the version of IGMP enabled on an interface. Although no 534 requirements exist for multicast routers at this time, it is assumed 535 that all multicast routers support the IGMP protocol. 537 7.2 Query Interval Advertisement Option 539 0 1 2 3 540 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 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 | Type=1 | Length=2 | IGMP Query Interval | 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 If a multicast router has any version of IGMP [RFC1112] enabled on an 546 interface on which IGMP Multicast Router Discovery is also enabled, 547 it MUST send all advertisements with the Query Interval Advertisement 548 Option. This option contains the IGMP "Query Interval" configured on 549 the interface on which advertisements are sent. 551 This option is sent regardless of whether the router is currently the 552 IGMP querier for the subnet. This option is sent regardless of what 553 version of IGMP the router is running. 555 IGMP Query Interval field is equal (in seconds) to the configured 556 IGMP "query interval" on the interface from which the advertisement 557 was sent. 559 7.3 Robustness Variable Advertisement Option 561 0 1 2 3 562 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 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 | Type=2 | Length=2 | Robustness Variable | 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 If a multicast router has IGMPv2 [IGMPv2] or IGMPv3 [IGMPv3] enabled 568 on an interface on which IGMP Multicast Router Discovery is also 569 enabled, it MUST send all advertisements with the Robustness Variable 570 Advertisement Option. This option contains the IGMP "Robustness 571 Variable" configured on the interface on which advertisements are 572 sent. 574 This option is sent regardless of whether the router is currently the 575 IGMP querier for the subnet. This option may be omitted if IGMPv1 is 576 enabled on the interface. 578 Robustness Variable is an integer that MUST not be zero [IGMPv2] and 579 is equal to the IGMPv2 robustness variable. 581 Biswas, Cain, Haberman 11 582 8. IPv6 Support 584 The Multicast Router Discovery function for IPv6 is accomplished 585 using the Neighbor Discovery Protocol for IPv6 [RFC2461] (hereafter 586 called NDP). Specifically, the Router Advertisement message contains 587 new fields to support the discovery of multicast routers. For this 588 reason, the timing mechanisms defined for NDP will be used instead of 589 those defined in this document for IPv4 support. 591 8.1 Router Advertisement Message 593 The Router Advertisement message contains two new fields to support 594 the multicast router discovery mechanism. The modified message 595 format is: 597 0 1 2 3 598 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 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 | Type | Code | Checksum | 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 | Cur Hop Limit |M|O|H|D|E|Rsrvd| Router Lifetime | 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 | Reachable Time | 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 | Retrans Timer | 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 | Options ... 609 +-+-+-+-+-+-+-+-+-+-+-+- 611 The two new fields are the 'D' and 'E' bits. All other fields retain 612 their definitions and functions as described in Section 4.2 of the 613 NDP specification [RFC2461]. 615 8.1.1 Discovery (D) bit 617 The 'D' bit is used by a router to indicate support for the Multicast 618 Router Discovery protocol. A value of '1' indicates that the router 619 supports the discovery protocol. A value of '0' indicates no 620 support. This allows for backwards compatibility of the Router 621 Advertisement message. 623 8.1.2 Enabled (E) bit 625 The 'E' bit indicates whether multicast routing is enabled on the 626 router's interface. A value of '1' indicates that multicast 627 forwarding is enabled on the router's interface. A value of '0' 628 indicates that multicast forwarding is disabled. 630 When the state of multicast forwarding changes on an interface, a 631 router must stop its Router Advertisement timer, transmit a Router 633 Biswas, Cain, Haberman 12 634 Advertisement with the 'E' bit set to the value associated with the 635 new multicast forwarding state, and restart its Router Advertisement 636 timer. 638 8.2 Router Solicitations 640 An NDP Router Solicitation message can be sent to solicit a Router 641 Advertisement message in order to determine the multicast forwarding 642 state of a router. The periodic transmission of solicitation 643 messages is outlined in RFC 2461. 645 9. Acknowledgements 647 ICMP Router Discovery [RFC1256] was used as a general model for IGMP 648 Multicast Router Discovery. 650 10. References 652 [RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256, 653 September 1991. 655 [RFC1112] Deering, S., "Host Extensions for IP Multicasting", 656 RFC 1112, August 1989. 658 [IGMPv2] Fenner, W., "Internet Group Management Protocol, 659 Version 2", Internet-Draft, November 1997. 661 [IGMPv3] Cain, B., Deering, S., Thyagarajan, A., "Internet Group 662 Management Protocol, Version 3", Internet-Draft, November 663 1997. 665 [RFC2113] Katz, D., "IP Router Alert Option," RFC 2113, April 1996. 667 [RFC2461] Narten, T., Nordmark, E., and Simpson, W., "Neighbor 668 Discovery IP Version 6 (IPv6)", RFC 2461, December 1998. 670 10. Authors' Addresses 672 Shantam Biswas 673 Nortel Networks 674 600 Technology Park Drive 675 Billerica, MA 01821 676 Email: sbiswas@baynetworks.com 677 Phone: 1-978-916-8048 679 Brad Cain 680 Nortel Networks 681 600 Technology Park Drive 682 Billerica, MA 01821 683 Email: bcain@baynetworks.com 684 Phone: 1-978-916-1316 686 Biswas, Cain, Haberman 13 687 Brian Haberman 688 Nortel Networks 689 4309 Emperor Blvd 690 Suite 200 691 Durham, NC 27703 692 Email: haberman@nortelnetworks.com 693 Phone: 1-919-992-4439 695 Biswas, Cain, Haberman 14