idnits 2.17.00 (12 Aug 2021) /tmp/idnits4631/draft-ietf-idmr-igmp-mrdisc-01.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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** 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 1 longer page, the longest (page 4) being 111 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 is 1 instance of lines with control characters in the document. ** 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 135: '...his document and MUST be supported by ...' RFC 2119 keyword, line 155: '... The Time-to-Live field MUST be 1....' RFC 2119 keyword, line 196: '... are sent this field MUST be set to 0....' RFC 2119 keyword, line 210: '...field is not zero, all options MUST be...' RFC 2119 keyword, line 260: '...scarded. Routers MUST process all opti...' (9 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 12 has weird spacing: '...d is in full ...' == Line 16 has weird spacing: '...), its areas...' == Line 17 has weird spacing: '...ups may also ...' == Line 21 has weird spacing: '... and may be u...' == Line 22 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 8315 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 170 == Missing Reference: 'N' is mentioned on line 174, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'IGMPv2' -- Possible downref: Non-RFC (?) normative reference: ref. 'IGMPv3' Summary: 8 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 draft-ietf-idmr-igmp-mrdisc-01.txt February 1999 5 Expires August 1999 7 IGMP Multicast Router Discovery 8 10 STATUS OF THIS MEMO 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet- Drafts as reference 23 material or to cite them other than as work in 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 Companies have been proposing "IGMP snooping" type schemes for 34 layer-2 bridging devices. A method for discovery multicast capable 35 routers is necessary for these schemes. An IGMP query message is 36 inadequate for discoverying multicast routers as one querier is 37 elected. In order to "discover" multicast routers, we introduce 38 two new types of IGMP messages: Multicast Router Advertisement and 39 Multicast Router Solicitation. These two messages can be used by 40 any device which listens to IGMP to discovery multicast routers. 41 Multicast ROuter Solicitation messages may be used by any network 42 device (e.g. layer-2 switch) to solicit discovery messages from 43 multicast routers. 45 1. Introduction 47 Multicast router discovery messages are useful for discovering 48 multicast capable routers. This capability is useful in a layer-2 49 bridging domain with "IGMP snooping" type of schemes. By listening 50 to multicast router discovery messages, layer-2 devices can 51 determine where to send multicast source data and IGMP Host 52 Membership Reports [RFC1112] [IGMPv2]. Multicast source data and 53 IGMP Host Membership Reports must be received by all multicast 54 routers on a segment. Using IGMP Host Membership Queries to 55 discover multicast routers is not useful because of query 56 suppression in IGMP. 58 Unlike ICMP router discovery messages [RFC1256], multicast router 59 discovery advertisements should not be listened to by hosts. 60 Hosts need not know the identity of multicast routers. 62 The use of the multicast router advertisement is not precluded 63 from being used for other purposes. Extensible options have been 64 included in the advertisement message for future enhancements. 66 The following are justifications for inventing another router 67 discovery protocol: 69 1. Using ICMP router discovery is not an appropriate solution 70 for multicast router discovery because: 1.) It may confuse 71 hosts listening to ICMP router advertisements; unicast and 72 multicast topologies may not be congruent. 2.) It is 73 desirable to have advertisements sent to a special link- 74 local group address. 3.) There is no way to tell from a 75 ICMP router advertisement if a router is running a multicast 76 routing protocol. 77 2. By making multicast router discovery messages extensible 78 and sending messages to a special address, future 79 enhancements can be made. 80 3. By inventing a generic IP layer message, multiple type of 81 messages per link layer are not needed (i.e. including this 82 functionality as part of IP is better than inventing N 83 discovery protocols for N layer-2 technologies). 85 Although multicast router discovery messages could be sent as 86 ICMP messages, IGMP was chosen because IGMP snooping switches 87 already snoop IGMP messages and because the first use of these 88 messages is multicast specific. 90 1.1 Protocol Overview 92 IGMP Multicast Router Discovery consists of two messages for 93 discovering multicast routers. The Multicast Router Advertisement 94 is sent by routers to advertise IP multicast forwarding enabled 95 on an interface. The Multicast Router Solicitation is used by 96 routers to solicit Multicast Router Advertisements. 98 Multicast routers send Multicast Router Advertisements (hereafter 99 called advertisements) periodically on all interfaces on which 100 multicast forwarding is enabled. These messages are sent to the 101 IGMP-MRDISC multicast group. 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. 107 Solicitations are sent to the IGMP-MRDISC multicast group. 109 Multicast Router Solicitations are sent whenever a router wishes 110 to discover multicast routers on a directly attached subnet. 112 All IGMP Multicast Router Discovery messages are sent with an 113 IP TLL of 1 and contain the IP Router Alert Option [RFC2113] in 114 their IP header. 116 Other non-router networking devices (e.g. layer-2 switches) may 117 send Multicast Router Solicitations to solicit Multicast Router 118 Advertisements. 120 2. Multicast Router Advertisement 122 2.1 Overview 124 Multicast Router Advertisements are sent periodically on all router 125 interfaces on which multicast forwarding is enabled. They are also 126 sent in response to Multicast Router Solicitations. 128 Router advertisements are sent upon expiration of a periodic 129 timer, when a router starts up, and when a router interface (that 130 has IP multicast forwarding enabled) initializes/restarts. 131 Advertisements are sent as IGMP messages to the IGMP-MRDISC 132 multicast address (224.0.0.x) and should be rate-limited. 134 Router advertisements may contain any number of options. Two 135 options are defined in this document and MUST be supported by any 136 implementation of IGMP multicast router discovery. These options 137 are described in Section 5. Additional options may be defined as 138 needed by future work. 140 2.2 IP Header Fields 142 2.2.1 Source Address 144 An IP address belonging to the interface from which this message is 145 sent. If multiple source addresses are configured on an interface, 146 then the one chosen is implementation dependent. 148 2.2.1 Destination Address 150 Router Advertisements are sent to the IGMP-MRDISC multicast 151 address (224.0.0.x). 153 2.2.2 Time-to-Live 155 The Time-to-Live field MUST be 1. 157 2.2.3 Protocol 159 The protocol field is set to IGMP (2). 161 2.3 Multicast Router Advertisement Message Format 163 0 1 2 3 164 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 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | Type | Ad. Interval | Checksum | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | Unused | Number of Options (N) | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | Option [1] (TLV encoded) | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | Option [...] (TLV encoded) | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 | Option [N] (TLV encoded) | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 2.3.1 Type Field 179 The type field is set to 0x24. 181 2.3.2 Advertisement Interval 183 This specifies the periodic time interval at which Multicast Router 184 Advertisements are sent in units of seconds. This value is set to 185 the configured MaxAdvertisementInterval variable. 187 2.3.3 Checksum 189 The 16-bit one's complement of the one's complement sum of the IGMP 190 message, starting with the IGMP type. For computing the checksum, 191 the Checksum field is set to 0. 193 2.3.4 Number of Options (N) 195 The number of options contained in the router advertisement. If no 196 options are sent this field MUST be set to 0. 198 2.3.5 Option[1..N] 200 Options are encoded as TLV in the following manner: 202 @ 204 0 1 2 3 205 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 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | Type | Length | Value | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 If the Number of Options field is not zero, all options MUST be 211 examined by a receiver. No strict ordering of options is enforced. 213 Type: Set to option type being advertised 215 Length: Length in bytes of Value field 217 Value: Option dependent value 219 2.4 Sending Multicast Router Advertisements 221 Router Advertisements are sent when the following events occur: 223 1. When the a periodic advertisement interval timer expires. 224 Note that it is not strictly periodic because the 225 advertisement interval is a random number between 226 MaxAdvertisementInterval and MinAdvertisementInterval. 227 (Default Value: 7-10 seconds). 229 2. After waiting for a random delay less than 230 MaxInitialAdvertisementInterval when an interface first 231 comes up, is (re)initialized, or IGMP Multicast Router 232 Discovery is enabled. A router may send up to a maximum of 233 MaxInitialAdvertisements advertisements, waiting for a 234 random delay less than MaxInitialAdvertisementInterval 235 between each successive advertisement. 237 This is to prevent an implosion of router advertisements. An 238 example of this occuring would be when many routers are 239 powered on at the same time. 241 3. When a solicitation is received, a router advertisement is 242 sent in response with a random delay less than 243 MAX_RESPONSE_DELAY. If a solicitation is received while 244 an advertisement is pending (because of a recent 245 solicitation), that solicitation will be ignored. 247 Whenever an advertisement is sent, the periodic advertisement 248 interval timer may be reset. 250 2.5 Receiving Multicast Router Advertisements 252 Upon receiving a router advertisement, routers will validate the 253 message by the following criteria: 255 1. Verifying that the IGMP type is 0x24 256 2. Verifying the IGMP checksum 257 3. IP Destination Address = IGMP-MRDISC multicast address 259 A router advertisement not meeting the validity requirements will 260 be silently discarded. Routers MUST process all options, discarding 261 options that are not recognized. 263 If a router advertisement is not received for a particular neighbor 264 within NeighborDeadInterval time interval, then the neigbor is 265 considered to be unreachable. 267 2.6 Multicast Router Advertisement Configuration Variables 269 A router that implements multicast router discovery MUST allow for 270 the following variables to be configured by system management; 271 default values are specified so as to make it unnecessary to 272 configure any of these variables in many cases. 274 For each interface the following configurable variables are 275 defined: 277 2.6.1 MaxAdvertisementInterval 279 The maximum time allowed between sending router advertisements from 280 the interface, in seconds. Must be no less than 2 seconds and no 281 greater than 180 seconds. 283 Default: 20 seconds. 285 2.6.2 MinAdvertisementInterval 287 The minimum time allowed between sending unsolicited router 288 advertisements from the interface, in seconds. Must be no less 289 than 3 seconds and no greater than MaxAdvertisementInterval. 291 Default: 0.75 * MaxAdvertisementInterval 293 2.6.3 MaxInitialAdvertisementInterval 295 The first router advertisement out of an interface is sent after 296 waiting for a random interval less than this variable. This will 297 prevent a flood of router advertisements when many routers start up 298 at the same time. 300 Default: 2 seconds 302 2.6.4 MaxInitialAdvertisements 304 The maximum number of router advertisements that will be sent 305 on a subnet after a router boots. 307 Default: 3 309 2.6.5 NeighborDeadInterval 311 The maximum time allowed before declaring that a neighbor can 312 can be declared "dead". This variable is defined in seconds. 313 In order for all routers to have a consistent state, it is 314 necessary for the MaxAdvertisementInterval to be configured the 315 same on all routers per subnet. 317 Default: 3 * MaxAdvertisementInterval 319 3. Multicast Router Solicitation 321 3.1 Overview 323 Multicast Router Solitications are used to solicit Multicast Router 324 Advertisements. These messages are used when a router (or other 325 device) wishes to discover multicast routers. Upon receiving a 326 solicitation on an interface with IP multicast forwarding enabled, 327 router will respond with an advertisement. 329 Router solicitations may be sent when a router starts up, when 330 a router interface (re)initializes, or when IGMP Multicast Router 331 Discovery is enabled. Solicitations are sent as IGMP messages to 332 the IGMP-MRDISC multicast address (224.0.0.x) and should be 333 rate-limited. 335 3.2 IP Header Fields 337 3.2.1 Source Address 339 An IP address belonging to the interface from which this message is 340 sent. If multiple source addresses are configured on an interface, 341 then the one chosen is implementation dependent. 343 If the solicitation is being sent from a device which does not have 344 an IP address (i.e. non-managed layer-2 switch), then the source 345 address should be set to all zeros. 347 3.2.2 Destination Address 349 Solicitation messages are sent to the IGMP-MRDISC multicast 350 address (224.0.0.x). 352 3.2.3 Time-to-Live 354 The time-to-live field MUST be 1. 356 3.2.4 Protocol 357 The protocol field is set to IGMP (2). 359 3.3 Multicast Router Solicitation Message Format 361 0 1 2 3 362 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 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | Type | Reserved | Checksum | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 3.3.1 Type Field 369 The type field is set to 0x25. 371 3.3.2 Reserved Field 373 Sent as 0; ignored on reception. 375 3.3.3 Checksum 377 The 16-bit one's complement of the one's complement sum of the IGMP 378 message, starting with the IGMP type. For computing the checksum, 379 the Checksum field is set to 0. 381 3.4 Sending Multicast Router Solicitations 383 Router solicitations are sent when the following events occur: 385 1. After waiting for a random delay less than 386 SOLICITATION_INTERVAL when an interface first comes up, is 387 (re)initialized, or IGMP Multicast Router Discovery is 388 enabled. A router may send up to a maximum of 389 MAX_SOLICITATIONS, waiting for a random delay less than 390 SOLICITATION_INTERVAL between each successive solicitation. 391 2. Optionally, for an implementation specific event. 392 Solicitations MUST be rate-limited; no more than 393 MAX_SOLICITATIONS MUST be sent in SOLICITATION_INTERVAL 394 seconds. 396 3.5 Receiving Multicast Router Solicitations 398 Upon receiving a router solicitation, routers will validate the 399 message by: 401 1. Verifying that the IGMP type is 0x25 402 2. Verifying the IGMP checksum 403 3. IP Destination Address = IGMP-MRDISC multicast address 405 A router solicitation not meeting the validity requirements will be 406 silently discarded. 408 Solicitation message IP source addresses MUST NOT be used as part 409 of the validity check. 411 3.6 Multicast Router Solicitation Configuration Variables 413 There are no configurable variables with respect to router 414 solicitations. 416 4. Multicast Router Discovery Protocol Constants 418 MAX_RESPONSE_DELAY 2 seconds 420 MAX_SOLICITATION_DELAY 1 second 422 SOLICITATION_INTERVAL 3 seconds 424 MAX_SOLICITATIONS 3 transmissions 426 5. Mandatory Advertisement Options 428 5.1 Overview of Options 430 The following options MUST be supported by an implementation of 431 IGMP Multicast Router Disovery: Query Interval Advertisement 432 Option and Robustness Variable Advertisement Option. These options 433 advertise specific IGMP variables and are sent in an advertisement 434 depending on the version of IGMP enabled on an interface. Although 435 no requirements exist for multicast routers at this time, it is 436 assumed that all multicast routers support the IGMP protocol. 438 5.1 Query Interval Advertisement Option 440 0 1 2 3 441 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 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | Type=1 | Length=2 | IGMP Query Interval | 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 If a multicast router has any version of IGMP [RFC1112] enabled on 447 an interface on which IGMP Multicast Router Discovery is also 448 enabled, it MUST send all advertisements with the Query Interval 449 Advertisement Option. This option contains the IGMP "Query 450 Interval" configured on the interface on which advertisements are 451 sent. 453 This option is sent regardless of whether the router is currently 454 the IGMP querier for the subnet. This option is sent regardless of 455 what version of IGMP the router is running. 457 IGMP Query Interval field is equal (in seconds) to the configured 458 IGMP "query interval" on the interface from which the advertisement 459 was sent. 461 5.2 Robustness Variable Advertisement Option 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=2 | Length=2 | Robustness Variable | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 If a multicast router has IGMPv2 [IGMPv2] or IGMPv3 [IGMPv3] 470 enabled on an interface on which IGMP Multicast Router Discovery 471 is also enabled, it MUST send all advertisements with the 472 Robustness Variable Advertisement Option. This option contains 473 the IGMP "Robustness Variable" configured on the interface on 474 which advertisements are sent. 476 This option is sent regardless of whether the router is currently 477 the IGMP querier for the subnet. This option may be omitted if 478 IGMPv1 is enabled on the interface. 480 Robustness Variable is an integer which MUST not be zero [IGMPv2] 481 and is equal to the IGMPv2 robustness variable. 483 6. Acknowledgements 485 ICMP Router Discovery [RFC1256] was used as a general model for 486 IGMP Multicast Router Discovery. 488 7. References 490 [RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256, 491 September 1991. 493 [RFC1112] Deering, S., "Host Extensions for IP Multicasting", RFC 1112, 494 August 1989. 496 [IGMPv2] Fenner, W., "Internet Group Management Protocol, Version 2", 497 Internet-Draft, November 1997. 499 [IGMPv3] Cain, B., Deering, S., Thyagarajan, A., "Internet Group 500 Management Protocol, Version 3", Internet-Draft, November 501 1997. 503 [RFC2113] Katz, D., "IP Router Alert Option," RFC 2113, April 1996. 505 8. Authors' Addresses 507 Shantam Biswas 508 Nortel Networks 509 600 Technology Park Drive 510 Billerica, MA 01821 511 EMail: sbiswas@baynetworks.com 512 Phone: 1-978-916-8048 514 Brad Cain 515 Nortel Networks 516 3 Federal Street 517 Billerica, MA 01821 518 EMail: bcain@baynetworks.com 519 Phone: 1-978-916-1316