idnits 2.17.1 draft-ietf-idmr-igmp-mrdisc-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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 Internet-Drafts being working documents. ** 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? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard 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 121: '...his document and MUST be supported by ...' RFC 2119 keyword, line 141: '... The Time-to-Live field MUST be 1....' RFC 2119 keyword, line 182: '... are sent this field MUST be set to 0....' RFC 2119 keyword, line 194: '...field is not zero, all options MUST be...' RFC 2119 keyword, line 244: '...scarded. Routers MUST process all opti...' (8 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 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 (September 1998) is 9354 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 156 == Missing Reference: 'N' is mentioned on line 160, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'IGMPv2' -- Possible downref: Non-RFC (?) normative reference: ref. 'IGMPv3' Summary: 10 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT S. Biswas 3 IDMR Working Group B. Cain 4 draft-ietf-idmr-igmp-mrdisc-00.txt March 1998 5 Expires September 1998 7 IGMP Multicast Router Discovery 8 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as `'work in progress.'' 22 To learn the current status of any Internet-Draft, please check the 23 `'1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 24 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 25 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 26 ftp.isi.edu (US West Coast). 28 Abstract 30 Companies have been proposing "IGMP snooping" type schemes for 31 layer-2 bridging devices. A method for discovery multicast capable 32 routers is necessary for these schemes. An IGMP query message is 33 inadequate for discoverying multicast routers as one querier is 34 elected. In order to "discover" multicast routers, we introduce 35 two new types of IGMP messages: Multicast Router Advertisement and 36 Multicast Router Solicitation. These two messages can be used by 37 any device which listens to IGMP to discovery multicast routers. 39 1. Introduction 41 Multicast router discovery messages are useful for discovering 42 multicast capable routers. This capability is useful in a layer-2 43 bridging domain with "IGMP snooping" type of schemes. By listening 44 to multicast router discovery messages, layer-2 devices can 45 determine where to send multicast source data and IGMP Host 46 Membership Reports [RFC1112] [IGMPv2]. Multicast source data and 47 IGMP Host Membership Reports must be received by all multicast 48 routers on a segment. Using IGMP Host Membership Queries to 49 discover multicast routers is not useful because of query 50 suppression in IGMP. 52 Unlike ICMP router discovery messages [RFC1256], multicast router 53 discovery advertisements should not be listened to by hosts. 54 Hosts need not know the identity of multicast routers. 56 The use of the multicast router advertisement is not precluded 57 from being used for other purposes. Extensible options have been 58 included in the advertisement message for future enhancements. 60 The following are justifications for inventing another router 61 discovery protocol: 63 1. Using ICMP router discovery is not an appropriate solution 64 for multicast router discovery because: 1.) It may confuse 65 hosts listening to ICMP router advertisements; unicast and 66 multicast topologies may not be congruent. 2.) It is 67 desirable to have advertisements sent to the all-multicast 68 routers group address. 3.) There is no way to tell from a 69 ICMP router advertisementif a router is running a multicast 70 routing protocol. 71 2. By making multicast router discovery messages extensible 72 and sending messages to the all-routers group, future 73 enhancements can be made. 74 3. By inventing a generic IP layer message, multiple type of 75 messages per link layer are not needed (i.e. including this 76 functionality as part of IP is better than inventing N 77 discovery protocols for N layer-2 technologies). 79 1.1 Protocol Overview 81 IGMP Multicast Router Discovery consists of two messages for 82 discovering multicast routers. The Multicast Router Advertisement 83 is sent by routers to advertise IP multicast forwarding enabled 84 on an interface. The Multicast Router Solicitation is used by 85 routers to solicit Multicast Router Advertisements. 87 Multicast routers send Multicast Router Advertisements (hereafter 88 called advertisements) periodically on all interfaces on which 89 multicast forwarding is enabled. These messages are sent to the 90 All-Routers multicast group. 92 Multicast Router Advertisements are also sent in response to 93 Multicast Router Solicitations (hereafter called solicitations). 94 These are sent to solicit a response of Multicast Router 95 Advertisements from all multicast routers. Solicitations are sent 96 to the All-Routers multicast group. 98 Multicast Router Solicitations are sent whenever a router wishes 99 to discover multicast routers on a directly attached subnet. 100 Solicitations are sent to the All-Routers multicast group. 102 All IGMP Multicast Router Discovery messages are sent with an 103 IP TLL of 1 and contain the IP Router Alert Option [RFC2113] in 104 their IP header. 106 2. Multicast Router Advertisement 108 2.1 Overview 110 Multicast Router Advertisements are sent periodically on all router 111 interfaces on which multicast forwarding is enabled. They are also 112 sent in response to Multicast Router Solicitations. 114 Router advertisements are sent upon expiration of a periodic 115 timer, when a router starts up, and when a router interface (that 116 has IP multicast forwarding enabled) initializes/restarts. 117 Advertisements are sent as IGMP messages to the All-Routers 118 multicast address (224.0.0.2) and should be rate-limited. 120 Router advertisements may contain any number of options. Two 121 options are defined in this document and MUST be supported by any 122 implementation of IGMP multicast router discovery. These options 123 are described in Section 5. Additional options may be defined as 124 needed by future work. 126 2.2 IP Header Fields 128 2.2.1 Source Address 130 An IP address belonging to the interface from which this message is 131 sent. If multiple source addresses are configured on an interface, 132 then the one chosen is implementation dependent. 134 2.2.1 Destination Address 136 Router Advertisements are sent to the All-Routers multicast 137 address (224.0.0.2). 139 2.2.2 Time-to-Live 141 The Time-to-Live field MUST be 1. 143 2.2.3 Protocol 145 The protocol field is set to IGMP (2). 147 2.3 Multicast Router Advertisement Message Format 149 0 1 2 3 150 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 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | Type | Ad. Interval | Checksum | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | Unused | Number of Options (N) | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | Option [1] (TLV encoded) | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | Option [...] (TLV encoded) | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | Option [N] (TLV encoded) | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 2.3.1 Type Field 165 The type field is set to 0x24. 167 2.3.2 Advertisement Interval 169 This specifies the periodic time interval at which Multicast Router 170 Advertisements are sent in units of seconds. This value is set to 171 the configured MaxAdvertisementInterval variable. 173 2.3.3 Checksum 175 The 16-bit one's complement of the one's complement sum of the IGMP 176 message, starting with the IGMP type. For computing the checksum, 177 the Checksum field is set to 0. 179 2.3.4 Number of Options (N) 181 The number of options contained in the router advertisement. If no 182 options are sent this field MUST be set to 0. 184 2.3.5 Option[1..N] 186 Options are encoded as TLV in the following manner: 188 0 1 2 3 189 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 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | Type | Length | Value | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 If the Number of Options field is not zero, all options MUST be 195 examined by a receiver. No strict ordering of options is enforced. 197 Type: Set to option type being advertised 199 Length: Length in bytes of Value field 201 Value: Option dependent value 203 2.4 Sending Multicast Router Advertisements 205 Router Advertisements are sent when the following events occur: 207 1. When the a periodic advertisement interval timer expires. 208 Note that it is not strictly periodic because the 209 advertisement interval is a random number between 210 MaxAdvertisementInterval and MinAdvertisementInterval. 211 (Default Value: 7-10 seconds). 213 2. After waiting for a random delay less than 214 MaxInitialAdvertisementInterval when an interface first 215 comes up, is (re)initialized, or IGMP Multicast Router 216 Discovery is enabled. A router may send up to a maximum of 217 MaxInitialAdvertisements advertisements, waiting for a random 218 delay less than MaxInitialAdvertisementInterval between each 219 successive advertisement. 221 This is to prevent an implosion of router advertisements. An 222 example of this occuring would be when many routers are 223 powered on at the same time. 225 3. When a solicitation is received, a router advertisement is 226 sent in response with a random delay less than 227 MAX_RESPONSE_DELAY. If a solicitation is received while 228 an advertisement is pending (because of a recent 229 solicitation), that solicitation will be ignored. 231 Whenever an advertisement is sent, the periodic advertisement 232 interval timer may be reset. 234 2.5 Receiving Multicast Router Advertisements 236 Upon receiving a router advertisement, routers will validate the 237 message by the following criteria: 239 1. Verifying that the IGMP type is 0x24 240 2. Verifying the IGMP checksum 241 3. IP Destination Address = All-Routers multicast address 243 A router advertisement not meeting the validity requirements will 244 be silently discarded. Routers MUST process all options, discarding 245 options that are not recognized. 247 If a router advertisement is not received for a particular neighbor 248 within NeighborDeadInterval time interval, then the neigbor is 249 considered to be unreachable. 251 2.6 Multicast Router Advertisement Configuration Variables 253 A router that implements multicast router discovery MUST allow for 254 the following variables to be configured by system management; 255 default values are specified so as to make it unnecessary to 256 configure any of these variables in many cases. 258 For each interface the following configurable variables are 259 defined: 261 2.6.1 MaxAdvertisementInterval 263 The maximum time allowed between sending router advertisements from 264 the interface, in seconds. Must be no less than 4 seconds and no 265 greater than 1800 seconds. 267 Default: 600 seconds. 269 2.6.2 MinAdvertisementInterval 271 The minimum time allowed between sending unsolicited router 272 advertisements from the interface, in seconds. Must be no less 273 than 3 seconds and no greater than MaxAdvertisementInterval. 275 Default: 0.75 * MaxAdvertisementInterval 277 Note: The default value will cause an the periodic interval to be 278 set to a period of 450-600 seconds. 280 2.6.3 MaxInitialAdvertisementInterval 282 The first router advertisement out of an interface is sent after 283 waiting for a random interval less than this variable. This will 284 prevent a flood of router advertisements when many routers start up 285 at the same time. 287 Default: 10 seconds 289 2.6.4 MaxInitialAdvertisement 291 The maximum number of router advertisements that will be sent 292 per event sending event. 294 Default: 3 296 2.6.5 NeighborDeadInterval 298 The maximum time allowed before declaring that a neighbor can 299 can be declared "dead". This variable is defined in seconds. 300 In order for all routers to have a consistent state, it is 301 necessary for the MaxAdvertisementInterval to be configured the 302 same on all routers per subnet. 304 Default: 3 * MaxAdvertisementInterval 306 3. Multicast Router Solicitation 308 3.1 Overview 310 Multicast Router Solitications are used to solicit Multicast Router 311 Advertisements. These messages are used when a router (or other 312 device) wishes to discover multicast routers. Upon receiving a 313 solicitation on an interface with IP multicast forwarding enabled, 314 router will respond with an advertisement. 316 Router solicitations may be sent when a router starts up, when 317 a router interface (re)initializes, or when IGMP Multicast Router 318 Discovery is enabled. Solicitations are sent as IGMP messages to 319 the All-Routers multicast address (224.0.0.2) and should be 320 rate-limited. 322 3.2 IP Header Fields 324 3.2.1 Source Address 326 An IP address belonging to the interface from which this message is 327 sent. If multiple source addresses are configured on an interface, 328 then the one chosen is implementation dependent. 330 3.2.2 Destination Address 332 Solicitation messages are sent to the All-Routers multicast 333 address (224.0.0.2). 335 3.2.3 Time-to-Live 337 The time-to-live field MUST be 1. 339 3.2.4 Protocol 341 The protocol field is set to IGMP (2). 343 3.3 Multicast Router Solicitation Message Format 345 0 1 2 3 346 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 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 | Type | Reserved | Checksum | 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 3.3.1 Type Field 353 The type field is set to 0x25. 355 3.3.2 Reserved Field 357 Sent as 0; ignored on reception. 359 3.3.3 Checksum 361 The 16-bit one's complement of the one's complement sum of the IGMP 362 message, starting with the IGMP type. For computing the checksum, 363 the Checksum field is set to 0. 365 3.4 Sending Multicast Router Solicitations 367 Router solicitations are sent when the following events occur: 369 1. After waiting for a random delay less than 370 SOLICITATION_INTERVAL when an interface first comes up, is 371 (re)initialized, or IGMP Multicast Router Discovery is 372 enabled. A router may send up to a maximum of 373 MAX_SOLICITATIONS, waiting for a random delay less than 374 SOLICITATION_INTERVAL between each successive solicitation. 375 2. Optionally, for an implementation specific event. 376 Solicitations MUST be rate-limited; no more than 377 MAX_SOLICITATIONS MUST be sent in SOLICITATION_INTERVAL 378 seconds. 380 3.5 Receiving Multicast Router Solicitations 382 Upon receiving a router solicitation, routers will validate the 383 message by: 385 1. Verifying that the IGMP type is 0x25 386 2. Verifying the IGMP checksum 387 3. IP Destination Address = All-Routers multicast address 389 A router solicitation not meeting the validity requirements will be 390 silently discarded. 392 3.6 Multicast Router Solicitation Configuration Variables 394 There are no configurable variables with respect to router 395 solicitations. 397 4. Multicast Router Discovery Protocol Constants 399 MAX_INITIAL_ADVERT_INTERVAL 10 seconds 401 MAX_INITIAL_ADVERTISEMENTS 3 transmissions 403 MAX_RESPONSE_DELAY 2 seconds 405 MAX_SOLICITATION_DELAY 1 second 407 SOLICITATION_INTERVAL 3 seconds 409 MAX_SOLICITATIONS 3 transmissions 411 5. Mandatory Advertisement Options 413 5.1 Overview of Options 415 The following options MUST be supported by an implementation of 416 IGMP Multicast Router Disovery: Query Interval Advertisement 417 Option and Robustness Variable Advertisement Option. These options 418 advertise specific IGMP variables and are sent in an advertisement 419 depending on the version of IGMP enabled on an interface. Although 420 no requirements exist for multicast routers at this time, it is 421 assumed that all multicast routers support the IGMP protocol. 423 5.1 Query Interval Advertisement Option 425 0 1 2 3 426 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 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 | Type=1 | Length=2 | IGMP Query Interval | 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 If a multicast router has any version of IGMP [RFC1112] enabled on 432 an interface on which IGMP Multicast Router Discovery is also 433 enabled, it MUST send all advertisements with the Query Interval 434 Advertisement Option. This option contains the IGMP "Query 435 Interval" configured on the interface on which advertisements are 436 sent. 438 This option is sent regardless of whether the router is currently 439 the IGMP querier for the subnet. This option is sent regardless of 440 what version of IGMP the router is running. 442 IGMP Query Interval field is equal (in seconds) to the configured 443 IGMP "query interval" on the interface from which the advertisement 444 was sent. 446 5.2 Robustness Variable Advertisement Option 448 0 1 2 3 449 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 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 | Type=2 | Length=2 | Robustness Variable | 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 If a multicast router has IGMPv2 [IGMPv2] or IGMPv3 [IGMPv3] 455 enabled on an interface on which IGMP Multicast Router Discovery 456 is also enabled, it MUST send all advertisements with the 457 Robustness Variable Advertisement Option. This option contains 458 the IGMP "Robustness Variable" configured on the interface on 459 which advertisements are sent. 461 This option is sent regardless of whether the router is currently 462 the IGMP querier for the subnet. This option may be omitted if 463 IGMPv1 is enabled on the interface. 465 Robustness Variable is an integer which MUST not be zero [IGMPv2] 466 and is equal to the IGMPv2 robustness variable. 468 6. Acknowledgements 470 ICMP Router Discovery [RFC1256] was used as a general model for 471 IGMP Multicast Router Discovery. 473 7. References 475 [RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256, 476 September 1991. 478 [RFC1112] Deering, S., "Host Extensions for IP Multicasting", RFC 1112, 479 August 1989. 481 [IGMPv2] Fenner, W., "Internet Group Management Protocol, Version 2", 482 Internet-Draft, November 1997. 484 [IGMPv3] Cain, B., Deering, S., Thyagarajan, A., "Internet Group 485 Management Protocol, Version 3", Internet-Draft, November 486 1997. 488 [RFC2113] Katz, D., "IP Router Alert Option," RFC 2113, April 1996. 490 8. Authors' Addresses 492 Shantam Biswas 493 Bay Networks 494 600 Technology Park Drive 495 Billerica, MA 01821 496 EMail: sbiswas@baynetworks.com 497 Phone: 1-978-916-8048 499 Brad Cain 500 Bay Networks 501 3 Federal Street 502 Billerica, MA 01821 503 EMail: bcain@baynetworks.com 504 Phone: 1-978-916-1316