idnits 2.17.1 draft-ietf-idmr-igmp-mrdisc-02.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 == It seems as if not all pages are separated by form feeds - found 0 form feeds but 14 pages 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. ** 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 142: '...his document and MUST be supported by ...' RFC 2119 keyword, line 161: '... The Time-to-Live field MUST be 1....' RFC 2119 keyword, line 202: '... are sent this field MUST be set to 0....' RFC 2119 keyword, line 214: '...field is not zero, all options MUST be...' RFC 2119 keyword, line 264: '...scarded. Routers MUST process all opti...' (10 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 14 has weird spacing: '...d is in full ...' == Line 18 has weird spacing: '...), its areas...' == Line 19 has weird spacing: '...ups may also ...' == Line 23 has weird spacing: '... and may be u...' == Line 24 has weird spacing: '...opriate to u...' == (2 more instances...) == 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 which 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 (August 1999) is 8993 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 176 == Missing Reference: 'N' is mentioned on line 180, 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: 7 errors (**), 0 flaws (~~), 10 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT S. Biswas 2 IDMR Working Group B. Cain 3 Nortel Networks 4 B. Haberman 5 IBM 6 August 1999 7 Expires February 1999 9 IGMP Multicast Router Discovery 10 12 STATUS OF THIS MEMO 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet- Drafts as reference 25 material or to cite them other than as work in progress. 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Abstract 35 Companies have been proposing "IGMP snooping" type schemes for 36 layer-2 bridging devices. A method for discovering multicast capable 37 routers is necessary for these schemes. An IGMP query message is 38 inadequate for discoverying multicast routers as one querier is 39 elected. In order to "discover" multicast routers, we introduce 40 two new types of IGMP messages: Multicast Router Advertisement and 41 Multicast Router Solicitation. These two messages can be used by 42 any device which listens to IGMP to discovery multicast routers. 43 Multicast Router Solicitation messages may be used by any network 44 device (e.g. layer-2 switch) to solicit discovery messages from 45 multicast routers. 47 1. Introduction 49 Multicast router discovery messages are useful for discovering 50 multicast capable routers. This capability is useful in a layer-2 51 bridging domain with "IGMP snooping" type of schemes. By listening 52 to multicast router discovery messages, layer-2 devices can 53 determine where to send multicast source data and IGMP Host 54 Membership Reports [RFC1112] [IGMPv2]. Multicast source data and 55 IGMP Host Membership Reports must be received by all multicast 56 routers on a segment. Using IGMP Host Membership Queries to 57 discover multicast routers is not useful because of query 58 suppression in IGMP. 60 Unlike ICMP router discovery messages [RFC1256], multicast router 61 discovery advertisements should not be listened to by hosts. 62 Hosts need not know the identity of multicast routers. 64 The use of the multicast router advertisement is not precluded 65 from being used for other purposes. Extensible options have been 66 included in the advertisement message for future enhancements. 68 The following are justifications for inventing another router 69 discovery protocol: 71 1. Using ICMP router discovery is not an appropriate solution 72 for multicast router discovery because: 1.) It may confuse 73 hosts listening to ICMP router advertisements; unicast and 74 multicast topologies may not be congruent. 2.) It is 75 desirable to have advertisements sent to a special link- 76 local group address. 3.) There is no way to tell from a 77 ICMP router advertisement if a router is running a multicast 78 routing protocol. 79 2. By making multicast router discovery messages extensible 80 and sending messages to a special address, future 81 enhancements can be made. 82 3. By inventing a generic IP layer message, multiple types of 83 messages per link layer are not needed (i.e. including this 84 functionality as part of IP is better than inventing N 85 discovery protocols for N layer-2 technologies). 87 Although multicast router discovery messages could be sent as 88 ICMP messages, IGMP was chosen because IGMP snooping switches 89 already snoop IGMP messages and because the intended first use 90 of these protocol messages is multicast specific. 92 1.1 Protocol Overview 94 IGMP Multicast Router Discovery consists of three messages for 95 discovering multicast routers. The Multicast Router Advertisement 96 is sent by routers to advertise IP multicast forwarding enabled 97 on an interface. The Multicast Router Solicitation is used by 98 routers to solicit Multicast Router Advertisements. The Multicast 99 Router Termination message is sent when a router terminates its 100 multicast routing functions. 102 Multicast routers send Multicast Router Advertisements (hereafter 103 called advertisements) periodically on all interfaces on which 104 multicast forwarding is enabled. 106 Multicast Router Advertisements are also sent in response to 107 Multicast Router Solicitations (hereafter called solicitations). 108 These are sent to solicit a response of Multicast Router 109 Advertisements from all multicast routers on a subnet. 110 Solicitations are sent to the IGMP-MRDISC multicast group. 112 Multicast Router Solicitations are sent whenever a router wishes 113 to discover multicast routers on a directly attached subnet. 115 Multicast Router Termination messages are sent when a router 116 terminates its multicast routing functions. 118 All IGMP Multicast Router Discovery messages are sent with an 119 IP TLL of 1 and contain the IP Router Alert Option [RFC2113] in 120 their IP header. All IGMP Multicast Router Discovery messages 121 are sent with to the IGMP-MRDISC multicast group (224.0.0.x). 123 Other non-IP forwarding devices (e.g. layer-2 switches) may 124 send Multicast Router Solicitations to solicit Multicast Router 125 Advertisements. 127 2. Multicast Router Advertisement 129 2.1 Overview 131 Multicast Router Advertisements are sent periodically on all router 132 interfaces on which multicast forwarding is enabled. They are also 133 sent in response to Multicast Router Solicitations. 135 Router advertisements are sent upon expiration of a periodic 136 timer, when a router starts up, and when a router interface (that 137 has IP multicast forwarding enabled) initializes/restarts. 138 Advertisements are sent as IGMP messages to the IGMP-MRDISC 139 multicast address (224.0.0.x) and should be rate-limited. 141 Router advertisements may contain any number of options. Two 142 options are defined in this document and MUST be supported by any 143 implementation of IGMP multicast router discovery. These options 144 are described in Section 5. Additional options may be defined as 145 needed by future work. 147 2.2 IP Header Fields 148 2.2.1 Source Address 150 An IP address belonging to the interface from which this message is 151 sent. If multiple source addresses are configured on an interface, 152 then the one chosen is implementation dependent. 154 2.2.2 Destination Address 156 Router Advertisements are sent to the IGMP-MRDISC multicast 157 address (224.0.0.x). 159 2.2.3 Time-to-Live 161 The Time-to-Live field MUST be 1. 163 2.2.4 Protocol 165 The protocol field is set to IGMP (2). 167 2.3 Multicast Router Advertisement Message Format 169 0 1 2 3 170 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 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | Type | Ad. Interval | Checksum | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 | Unused | Number of Options (N) | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | Option [1] (TLV encoded) | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | Option [...] (TLV encoded) | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | Option [N] (TLV encoded) | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 2.3.1 Type Field 185 The type field is set to 0x24. 187 2.3.2 Advertisement Interval 189 This specifies the periodic time interval at which Multicast Router 190 Advertisements are sent in units of seconds. This value is set to 191 the configured MaxAdvertisementInterval variable. 193 2.3.3 Checksum 195 The 16-bit one's complement of the one's complement sum of the IGMP 196 message, starting with the IGMP type. For computing the checksum, 197 the Checksum field is set to 0. 199 2.3.4 Number of Options (N) 201 The number of options contained in the router advertisement. If no 202 options are sent this field MUST be set to 0. 204 2.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, all options MUST be 215 examined by a receiver. 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 2.4 Sending Multicast Router Advertisements 225 Router Advertisements are sent when the following events occur: 227 1. 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. 231 (Default Value: 7-10 seconds). 233 2. After waiting for a random delay less than 234 MaxInitialAdvertisementInterval when an interface first 235 comes up, is (re)initialized, or IGMP Multicast Router 236 Discovery is enabled. A router may send up to a maximum of 237 MaxInitialAdvertisements advertisements, waiting for a 238 random delay less than MaxInitialAdvertisementInterval 239 between each successive advertisement. 241 This is to prevent an implosion of router advertisements. An 242 example of this occuring would be when many routers are 243 powered on at the same time. 245 3. When a solicitation is received, a router advertisement is 246 sent in response with a random delay less than 247 MAX_RESPONSE_DELAY. If a solicitation is received while 248 an advertisement is pending (because of a recent 249 solicitation), that solicitation will be ignored. 251 Whenever an advertisement is sent, the periodic advertisement 252 interval timer may be reset. 254 2.5 Receiving Multicast Router Advertisements 256 Upon receiving a router advertisement, routers will validate the 257 message by the following criteria: 259 1. Verifying that the IGMP type is 0x24 260 2. Verifying the IGMP checksum 261 3. IP Destination Address = IGMP-MRDISC multicast address 263 A router advertisement not meeting the validity requirements will 264 be silently discarded. Routers MUST process all options, discarding 265 options that are not recognized. 267 If a router advertisement is not received for a particular neighbor 268 within NeighborDeadInterval time interval, then the neigbor is 269 considered to be unreachable. 271 2.6 Multicast Router Advertisement Configuration Variables 273 A router that implements multicast router discovery MUST allow for 274 the following variables to be configured by system management; 275 default values are specified so as to make it unnecessary to 276 configure any of these variables in many cases. 278 For each interface the following configurable variables are 279 defined: 281 2.6.1 MaxAdvertisementInterval 283 The maximum time allowed between sending router advertisements from 284 the interface, in seconds. Must be no less than 2 seconds and no 285 greater than 180 seconds. 287 Default: 20 seconds. 289 2.6.2 MinAdvertisementInterval 291 The minimum time allowed between sending unsolicited router 292 advertisements from the interface, in seconds. Must be no less 293 than 3 seconds and no greater than MaxAdvertisementInterval. 295 Default: 0.75 * MaxAdvertisementInterval 297 2.6.3 MaxInitialAdvertisementInterval 299 The first router advertisement out of an interface is sent after 300 waiting for a random interval less than this variable. This will 301 prevent a flood of router advertisements when many routers start up 302 at the same time. 304 Default: 2 seconds 306 2.6.4 MaxInitialAdvertisements 308 The maximum number of router advertisements that will be sent 309 on a subnet after a router boots. 311 Default: 3 313 2.6.5 NeighborDeadInterval 315 The maximum time allowed before declaring that a neighbor can 316 can be declared "dead". This variable is defined in seconds. 317 In order for all routers to have a consistent state, it is 318 necessary for the MaxAdvertisementInterval to be configured the 319 same on all routers per subnet. 321 Default: 3 * MaxAdvertisementInterval 323 3. Multicast Router Solicitation 325 3.1 Overview 327 Multicast Router Solitications are used to solicit Multicast Router 328 Advertisements. These messages are used when a router (or other 329 device) wishes to discover multicast routers. Upon receiving a 330 solicitation on an interface with IP multicast forwarding enabled, 331 router will respond with an advertisement. 333 Router solicitations may be sent when a router starts up, when 334 a router interface (re)initializes, or when IGMP Multicast Router 335 Discovery is enabled. Solicitations are sent as IGMP messages to 336 the IGMP-MRDISC multicast address (224.0.0.x) and should be 337 rate-limited. 339 3.2 IP Header Fields 341 3.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 which does not have 348 an IP address (i.e. non-managed layer-2 switch), then the source 349 address should be set to all zeros. 351 3.2.2 Destination Address 353 Solicitation messages are sent to the IGMP-MRDISC multicast 354 address (224.0.0.x). 356 3.2.3 Time-to-Live 358 The time-to-live field MUST be 1. 360 3.2.4 Protocol 362 The protocol field is set to IGMP (2). 364 3.3 Multicast Router Solicitation Message Format 366 0 1 2 3 367 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 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | Type | Reserved | Checksum | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 3.3.1 Type Field 374 The type field is set to 0x25. 376 3.3.2 Reserved Field 378 Sent as 0; ignored on reception. 380 3.3.3 Checksum 382 The 16-bit one's complement of the one's complement sum of the IGMP 383 message, starting with the IGMP type. For computing the checksum, 384 the Checksum field is set to 0. 386 3.4 Sending Multicast Router Solicitations 388 Router solicitations are sent when the following events occur: 390 1. After waiting for a random delay less than 391 SOLICITATION_INTERVAL when an interface first comes up, is 392 (re)initialized, or IGMP Multicast Router Discovery is 393 enabled. A router may send up to a maximum of 394 MAX_SOLICITATIONS, waiting for a random delay less than 395 SOLICITATION_INTERVAL between each successive solicitation. 396 2. Optionally, for an implementation specific event. 397 Solicitations MUST be rate-limited; no more than 398 MAX_SOLICITATIONS MUST be sent in SOLICITATION_INTERVAL 399 seconds. 401 3.5 Receiving Multicast Router Solicitations 403 Upon receiving a router solicitation, routers will validate the 404 message by: 406 1. Verifying that the IGMP type is 0x25 407 2. Verifying the IGMP checksum 408 3. IP Destination Address = IGMP-MRDISC multicast address 410 A router solicitation not meeting the validity requirements will be 411 silently discarded. 413 Solicitation message IP source addresses MUST NOT be used as part 414 of the validity check. 416 3.6 Multicast Router Solicitation Configuration Variables 418 There are no configurable variables with respect to router 419 solicitations. 421 4. Multicast Router Termination 423 4.1 Overview 425 The Multicast Router Termination message is used to expedite the 426 notification of a change in the status of a routers multicast 427 forwarding functions. 429 4.2 IP Header Fields 431 4.2.1 Source Address 433 An IP address belonging to the interface from which this message is 434 sent. If multiple source addresses are configured on an interface, 435 then the one chosen is implementation dependent. 437 4.2.2 Destination Address 439 Multicast Router Termination messages are sent to the IGMP-MRDISC 440 multicast address (224.0.0.x). 442 4.2.3 Time-to-Live 444 The Time-to-Live field MUST be 1. 446 4.2.4 Protocol 448 The protocol field is set to IGMP (2). 450 4.3 Multicast Router Termination Message Format 452 0 1 2 3 453 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 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 | Type | Reserved | Checksum | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 4.3.1 Type Field 460 The type field is set to 0x26. 462 4.3.2 Checksum 464 The 16-bit one's complement of the one's complement sum of the IGMP 465 message, starting with the IGMP type. For computing the checksum, 466 the Checksum field is set to 0. 468 4.4 Sending Multicast Router Termination Messages 470 Multicast Router Termination messages are sent for three reasons : 472 1. Multicast forwarding is disabled on the interface 473 2. The interface is administratively disabled 474 3. The router is gracefully shutdown 476 4.5 Receiving Multicast Router Termination Messages 478 Upon receiving a termination message, routers will validate the 479 message by the following criteria: 481 1. Verifying that the IGMP type is 0x26 482 2. Verifying the IGMP checksum 483 3. IP Destination Address = IGMP-MRDISC multicast address 485 A termination message not meeting the validity requirements will 486 be silently discarded. 488 5. Multicast Router Discovery Protocol Constants 490 MAX_RESPONSE_DELAY 2 seconds 492 MAX_SOLICITATION_DELAY 1 second 494 SOLICITATION_INTERVAL 3 seconds 496 MAX_SOLICITATIONS 3 transmissions 498 6. Mandatory Advertisement Options 499 6.1 Overview of Options 501 The following options MUST be supported by an implementation of 502 IGMP Multicast Router Disovery: Query Interval Advertisement 503 Option and Robustness Variable Advertisement Option. These options 504 advertise specific IGMP variables and are sent in an advertisement 505 depending on the version of IGMP enabled on an interface. Although 506 no requirements exist for multicast routers at this time, it is 507 assumed that all multicast routers support the IGMP protocol. 509 6.2 Query Interval Advertisement Option 511 0 1 2 3 512 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 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 | Type=1 | Length=2 | IGMP Query Interval | 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 If a multicast router has any version of IGMP [RFC1112] enabled on 518 an interface on which IGMP Multicast Router Discovery is also 519 enabled, it MUST send all advertisements with the Query Interval 520 Advertisement Option. This option contains the IGMP "Query 521 Interval" configured on the interface on which advertisements are 522 sent. 524 This option is sent regardless of whether the router is currently 525 the IGMP querier for the subnet. This option is sent regardless of 526 what version of IGMP the router is running. 528 IGMP Query Interval field is equal (in seconds) to the configured 529 IGMP "query interval" on the interface from which the advertisement 530 was sent. 532 6.3 Robustness Variable Advertisement Option 534 0 1 2 3 535 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 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 | Type=2 | Length=2 | Robustness Variable | 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 If a multicast router has IGMPv2 [IGMPv2] or IGMPv3 [IGMPv3] 541 enabled on an interface on which IGMP Multicast Router Discovery 542 is also enabled, it MUST send all advertisements with the 543 Robustness Variable Advertisement Option. This option contains 544 the IGMP "Robustness Variable" configured on the interface on 545 which advertisements are sent. 547 This option is sent regardless of whether the router is currently 548 the IGMP querier for the subnet. This option may be omitted if 549 IGMPv1 is enabled on the interface. 551 Robustness Variable is an integer which MUST not be zero [IGMPv2] 552 and is equal to the IGMPv2 robustness variable. 554 7. IPv6 Support 556 The Multicast Router Discovery function for IPv6 is accomplished 557 using the Neighbor Discovery Protocol for IPv6 [RFC2461] (hereafter 558 called NDP). Specifically, the Router Advertisement message 559 contains new fields to support the discovery of multicast routers. 560 For this reason, the timing mechanisms defined for NDP will be used 561 instead of those defined in this document for IPv4 support. 563 7.1 Router Advertisement Message 565 The Router Advertisement message contains two new fields to support 566 the multicast router discovery mechanism. The modified message 567 format is : 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 | Code | Checksum | 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 | Cur Hop Limit |M|O|D|E| Rsrvd | Router Lifetime | 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 | Reachable Time | 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 | Retrans Timer | 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 | Options ... 581 +-+-+-+-+-+-+-+-+-+-+-+- 583 The two new fields are the 'D' and 'E' bits. All other fields 584 retain their defintions and functions as described in Section 4.2 585 of the NDP specification [RFC2461]. 587 7.1.1 Discovery (D) bit 589 The 'D' bit is used by a router to indicate support for the 590 Multicast Router Discovery protocol. A value of '1' indicates that 591 the router supports the discovery protocol. A value of '0' 592 indicates no support. This allows for backwards compatibility of 593 the Router Advertisement message. 595 7.1.2 Enabled (E) bit 597 The 'E' bit indicates whether multicast routing is enabled on the 598 router's interface. A value of '1' indicates that multicast 599 forwarding is enabled on the router's interface. A value of '0' 600 indicates that multicast forwarding is disabled. 602 7.2 Router Solicitations 604 An NDP Router Solicitation message can be sent to solicit a Router 605 Advertisement message in order to determine the multicast 606 forwarding state of a router. The periodic transmission of 607 solicitation messages is outlined in RFC 2461. 609 8. Acknowledgements 611 ICMP Router Discovery [RFC1256] was used as a general model for 612 IGMP Multicast Router Discovery. 614 9. References 616 [RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256, 617 September 1991. 619 [RFC1112] Deering, S., "Host Extensions for IP Multicasting", RFC 1112, 620 August 1989. 622 [IGMPv2] Fenner, W., "Internet Group Management Protocol, Version 2", 623 Internet-Draft, November 1997. 625 [IGMPv3] Cain, B., Deering, S., Thyagarajan, A., "Internet Group 626 Management Protocol, Version 3", Internet-Draft, November 627 1997. 629 [RFC2113] Katz, D., "IP Router Alert Option," RFC 2113, April 1996. 631 [RFC2461] Narten, T., Nordmark, E., and Simpson, W., "Neighbor 632 Discovery IP Version 6 (IPv6)", RFC 2461, December 1998. 634 10. Authors' Addresses 636 Shantam Biswas 637 Nortel Networks 638 600 Technology Park Drive 639 Billerica, MA 01821 640 EMail: sbiswas@baynetworks.com 641 Phone: 1-978-916-8048 643 Brad Cain 644 Nortel Networks 645 3 Federal Street 646 Billerica, MA 01821 647 EMail: bcain@baynetworks.com 648 Phone: 1-978-916-1316 650 Brian Haberman 651 IBM Corporation 652 800 Park Office Drive 653 Research Triangle Park, NC 27709 654 EMail: haberman@raleigh.ibm.com 655 Phone: 1-919-254-2673