idnits 2.17.1 draft-ietf-magma-mrdisc-00.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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 4 instances of too long lines in the document, the longest one being 2 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 109: '... SHOULD be rate-limited....' RFC 2119 keyword, line 113: '...D implementation MUST support the foll...' RFC 2119 keyword, line 121: '...s on an interface. This value MUST be...' RFC 2119 keyword, line 129: '...s on an interface. This value MUST be...' RFC 2119 keyword, line 200: '...nterface, this field MUST be set to 0....' (17 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 2004) is 7191 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) -- Missing reference section? 'RFC 2026' on line 13 looks like a reference -- Missing reference section? 'RFC1112' on line 50 looks like a reference -- Missing reference section? 'RFC2236' on line 205 looks like a reference -- Missing reference section? 'RFC2113' on line 86 looks like a reference -- Missing reference section? 'RFC2711' on line 86 looks like a reference -- Missing reference section? 'RFC2463' on line 411 looks like a reference -- Missing reference section? 'RFC3376' on line 205 looks like a reference -- Missing reference section? 'RFC2710' on line 205 looks like a reference -- Missing reference section? 'MLDV2' on line 205 looks like a reference -- Missing reference section? 'RFC3307' on line 516 looks like a reference -- Missing reference section? 'RFC1256' on line 522 looks like a reference Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MAGMA Working Group B. Haberman 2 Internet Draft Caspian Networks 3 draft-ietf-magma-mrdisc-00.txt J. Martin 4 February 2004 Netzwert AG 5 Expires August 2004 7 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 [RFC 2026]. 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 as 20 reference material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt. 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Abstract 30 The concept of IGMP snooping requires the ability to identify the 31 location of multicast routers. Since snooping is not standardized, 32 there are many mechanisms in use to identify the multicast routers. 33 However, this can lead to interoperability issues between multicast 34 routers and snooping switches from different vendors. 36 This document introduces a general mechanism that allows for the 37 discovery of multicast routers. This new mechanism, Multicast 38 Router Discovery (MRD), introduces a standardized means of 39 identifying multicast routers without a dependency on particular 40 multicast routing protocols. 42 Haberman, Martin 1 43 1. Introduction 45 Multicast Router Discovery messages are useful for determining which 46 nodes attached to a switch have multicast routing enabled. This 47 capability is useful in a layer-2 bridging domain with snooping 48 switches. By listening to MRD messages, layer-2 switches can 49 determine where to send multicast source data and group membership 50 messages [RFC1112][RFC2236]. Multicast source data and group 51 membership Reports must be received by all multicast routers on a 52 segment. Using the group membership protocol Query messages to 53 discover multicast routers is insufficient due to query suppression. 55 Although MRD messages could be sent as ICMP messages, the group 56 management protocols were chosen since this functionality is 57 multicast specific. The addition of this functionality to the group 58 membership protocol also allows operators to have congruency between 59 multicast router discovery problems and data forwarding issues. 61 2. Protocol Overview 63 Multicast Router Discovery consists of three messages for 64 discovering multicast routers. The Multicast Router Advertisement 65 is sent by routers to advertise that IP multicast forwarding is 66 enabled. Devices may send Multicast Router Solicitation messages in 67 order to solicit Advertisement messages from multicast routers. The 68 Multicast Router Termination messages are sent when a router stops 69 IP multicast routing functions on an interface. 71 Multicast routers send Advertisements periodically on all interfaces 72 on which multicast forwarding is enabled. Advertisement messages 73 are also sent in response to Solicitations. In addition to 74 advertising the location of multicast routers, Advertisements also 75 convey useful information concerning group management protocol 76 variables. This information can be used for consistency checking on 77 the subnet. 79 A device sends Solicitation messages whenever it wishes to discover 80 multicast routers on a directly attached link. 82 A router sends Termination messages when it terminates multicast 83 routing functionality on an interface. 85 All MRD messages are sent with an IPv4 TTL or IPv6 Hop Limit of 1 86 and contain the Router Alert Option [RFC2113][RFC2711]. 88 Advertisement and Termination messages are sent to the All-Snoopers 89 multicast address. 91 Solicitation messages are sent to the All-Routers multicast address. 93 Haberman, Martin 2 94 3. Multicast Router Advertisement 96 Multicast Router Advertisements are sent periodically on all router 97 interfaces on which multicast forwarding is enabled. They are also 98 sent in response to Multicast Router Solicitation messages. 100 Advertisements are sent 102 1. Upon the expiration of a periodic timer 103 2. As a part of a router's start up procedure 104 3. During the restart of a multicast forwarding interface 105 4. On receipt of a Solicitation message 107 All Advertisements are sent as IGMP (for IPv4) or MLD (for IPv6) 108 messages to the All-Snoopers multicast address. These messages 109 SHOULD be rate-limited. 111 3.1 Advertisement Configuration Variables 113 An MRD implementation MUST support the following variables being 114 configured by system management. Default values are specified to 115 make it unnecessary to configure any of these variables in many 116 cases. 118 3.1.1 MaxAdvertisementInterval 120 This variable is the maximum time (in seconds) allowed between the 121 transmissions of Advertisements on an interface. This value MUST be 122 no less than 4 seconds and no greater than 180 seconds. 124 Default: 20 seconds 126 3.1.2 MinAdvertisementInterval 128 This is the minimum time (in seconds) allowed between the 129 transmissions of Advertisements on an interface. This value MUST be 130 no less than 3 seconds and no greater than MaxAdvertisementInterval. 132 Default: 0.75 * MaxAdvertisementInterval 134 3.1.3 MaxInitialAdvertisementInterval 136 The first Advertisement transmitted on an interface is sent after 137 waiting a random interval (in seconds) less than this variable. 138 This prevents a flood of Advertisements when multiple routers start 139 up at the same time. 141 Default: 2 seconds 143 3.1.4 MaxInitialAdvertisements 145 Haberman, Martin 3 146 This variable is the maximum number of Advertisements that will be 147 transmitted by the advertising interface when MRD starts up. 149 Default: 3 151 3.1.5 NeighborDeadInterval 153 This variable is the maximum time (in seconds) allowed to elapse 154 before a neighbor can be declared unreachable. In order for all 155 devices to have a consistent state, it is necessary for the 156 MaxAdvertisementInterval to be configured consistently in all 157 devices on the subnet. 159 Default: 3 * MaxAdvertisementInterval 161 3.2 Advertisement Packet Format 163 The Advertisement message has the following format: 165 0 1 2 3 166 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 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | Type | Ad. Interval | Checksum | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | Query Interval | Robustness Variable | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 3.2.1 Type Field 175 The Type field identifies the message as an Advertisement. It is 176 set to X1 (to be assigned by IANA) for IPv4 and X2 (to be assigned 177 by IANA) for IPv6. 179 3.2.2 Advertisement Interval Field 181 This field specifies the periodic time interval at which 182 Advertisement messages are transmitted in units of seconds. This 183 value is set to the configured MaxAdvertisementInterval variable. 185 3.2.3 Checksum Field 187 The checksum field is set as follows: 189 1. For IPv4 it is the 16-bit one's complement of the one's 190 complement sum of the IGMP message, starting with the Type 191 field. For computing the checksum, the checksum field is set 192 to 0. 193 2. For IPv6 it is ICMPv6 checksum as specified in [RFC2463]. 195 3.2.4 Query Interval Field 197 Haberman, Martin 4 198 The Query Interval field is set to the Query Interval value in use 199 by IGMP or MLD on the interface. If IGMP or MLD is not enabled on 200 the advertising interface, this field MUST be set to 0. 202 3.2.5 Robustness Variable Field 204 This field is set to the Robustness Variable in use by IGMPv2 205 [RFC2236], IGMPv3 [RFC3376], or MLD [RFC2710][MLDV2] on the 206 advertising interface. If IGMPv1 is in use or no group management 207 protocol is enabled on the interface, this field MUST be set to 0. 209 3.3 IP Header Fields 211 3.3.1 Source Address 213 The IP source address is set to an IP address configured on the 214 advertising interface. For IPv6, a link-local address MUST be used. 216 3.3.2 Destination Address 218 The IP destination address is set to the All-Snoopers multicast 219 address. 221 3.3.3 Time-to-Live / Hop Limit 223 The IPv4 TTL and IPv6 Hop Limit are set to 1. 225 3.3.4 IPv4 Protocol 227 The IPv4 Protocol field is set to IGMP (2). 229 3.4 Sending Multicast Router Advertisements 231 Advertisement messages are sent when the following events occur: 233 . The expiration of the periodic advertisement interval timer. 234 Note that it this timer is not strictly periodic since it is 235 a random number between MaxAdvertisementInterval and 236 MinAdvertisementInterval. 237 . After a random delay less than 238 MaxInitialAdvertisementInterval when an interface is first 239 enabled, is (re-)initialized, or MRD is enabled. A router 240 may send up to a maximum of MaxInitialAdvertisements 241 Advertisements, waiting for a random delay less than 242 MaxInitialAdvertisementInterval between each successive 243 message. Multiple Advertisements are sent for robustness in 244 the face of packet loss on the network. 246 This is to prevent an implosion of Advertisements. An example of 247 this occurring would be when many routers are powered on at the same 248 time. When a Solicitation is received, an Advertisement is sent in 250 Haberman, Martin 5 251 response with a random delay less than MAX_RESPONSE_DELAY. If a 252 Solicitation is received while an Advertisement is pending, that 253 Solicitation MUST be ignored. 255 When an Advertisement is sent, the periodic advertisement interval 256 timer MUST be reset. 258 3.5 Receiving Multicast Router Advertisements 260 Upon receiving an Advertisement message, devices validate the 261 message with the following criteria: 263 . The checksum is correct 264 . The IP destination address is equal to the All-Snoopers 265 multicast address 266 . For IPv6, the IP source address is a link-local address 268 An Advertisement not meeting the validity requirements MUST be 269 silently discarded or logged in a rate-limited manner. 271 If an Advertisement is not received for a particular neighbor within 272 a NeighborDeadInterval time interval, then the neighbor is 273 considered unreachable. 275 4. Multicast Router Solicitation 277 Multicast Router Solicitation messages are used to solicit 278 Advertisements from multicast routers on a segment. These messages 279 are used when a device wishes to discover multicast routers. Upon 280 receiving a solicitation on an interface with IP multicast 281 forwarding and MRD enabled, a router will respond with an 282 Advertisement. 284 Solicitations may be sent when: 286 1. An interface is (re-)initialized 287 2. MRD is enabled 289 Solicitations are sent to the All-Routers multicast address and 290 SHOULD be rate-limited. 292 4.1 Solicitation Packet Format 294 The Solicitation message has the following format: 296 0 1 2 3 297 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 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | Type | Reserved | Checksum | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 4.1.1 Type Field 304 Haberman, Martin 6 305 The Type field identifies the message as a Solicitation. It is set 306 to Y1 (to be assigned by IANA) for IPv4 and Y2 (to be assigned by 307 IANA) for IPv6. 309 4.1.2 Reserved Field 311 The Reserved field is set to 0 on transmission and ignored on 312 reception. 314 4.1.3 Checksum Field 316 The checksum field is set as follows: 318 . For IPv4 it is the 16-bit one's complement of the one's 319 complement sum of the IGMP message, starting with the Type 320 field. For computing the checksum, the checksum field is set 321 to 0. 322 . For IPv6 it is ICMPv6 checksum as specified in [RFC2463]. 324 4.2 IP Header Fields 326 4.2.1 Source Address 328 The IP source address is set to an IP address configured on the 329 soliciting interface. For IPv6, a link-local address MUST be used. 331 4.2.2 Destination Address 333 The IP destination address is set to the All-Routers multicast 334 address. 336 4.2.3 Time-to-Live / Hop Limit 338 The IPv4 TTL and IPv6 Hop Limit are set to 1. 340 4.2.4 IPv4 Protocol 342 The IPv4 Protocol field is set to IGMP (2). 344 4.3 Sending Multicast Router Solicitations 346 Solicitation messages are sent when the following events occur: 348 . After waiting for a random delay less than 349 SOLICITATION_INTERVAL when an interface first becomes 350 operational, is (re-)initialized, or MRD is enabled. A 351 device may send up to a maximum of MAX_SOLICITATIONS, 352 waiting for a random delay less than SOLICITATION_INTERVAL 353 between each solicitation. 354 . Optionally, for an implementation specific event. 356 Haberman, Martin 7 357 Solicitations MUST be rate-limited; the implementation MUST send no 358 more than MAX_SOLICITATIONS in SOLICITATION_INTERVAL seconds. 360 4.4 Receiving Multicast Router Solicitations 362 A Solicitation message MUST be validated before a response is sent. 363 A router MUST verify that: 365 . The checksum is correct 366 . The IP destination address is the All-Routers multicast 367 address 368 . For IPv6, the IP source address MUST be a link-local address 370 Solicitations not meeting the validity requirements SHOULD be 371 silently discarded or logged in a rate-limited manner. 373 5. Multicast Router Termination 375 The Multicast Router Termination message is used to expedite the 376 notification of a change in the status of a router's multicast 377 forwarding functions. Multicast routers send Terminations when 378 multicast forwarding is disabled on the advertising interface. 380 5.1 Termination Packet Format 382 The Termination message has the following format: 384 0 1 2 3 385 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 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | Type | Reserved | Checksum | 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 5.1.1 Type Field 392 The Type field identifies the message as a Termination. It is set 393 to Z1 (to be assigned by IANA) for IPv4 and Z2 (to be assigned by 394 IANA) for IPv6. 396 5.1.2 Reserved Field 398 The Reserved field is set to 0 on transmission and ignored on 399 reception. 401 5.1.3 Checksum Field 403 The checksum field is set as follows: 405 . For IPv4 it is the 16-bit one's complement of the one's 406 complement sum of the IGMP message, starting with the Type 408 Haberman, Martin 8 409 field. For computing the checksum, the checksum field is 410 set to 0. 411 . For IPv6 it is ICMPv6 checksum as specified in [RFC2463]. 413 5.2 IP Header Fields 415 5.2.1 Source Address 417 The IP source address is set to an IP address configured on the 418 advertising interface. For IPv6, a link-local address MUST be used. 420 5.2.2 Destination Address 422 The IP destination address is set to the All-Snoopers multicast 423 address. 425 5.2.3 Time-to-Live / Hop Limit 427 The IPv4 TTL and IPv6 Hop Limit are set to 1. 429 5.2.4 IPv4 Protocol 431 The IPv4 Protocol field is set to IGMP (2). 433 5.3 Sending Multicast Router Terminations 435 Termination messages are sent by multicast routers when: 437 . Multicast forwarding is disabled on an interface 438 . An interface is administratively disabled 439 . The router is gracefully shutdown 440 . MRD is disabled 442 5.4 Receiving Multicast Router Terminations 444 Upon receiving a Termination message, devices validate the message. 445 The validation criteria is: 447 . Checksum MUST be correct 448 . IP destination address MUST equal the All-Snoopers multicast 449 address 450 . For IPv6, the IP source address MUST be a link-local address 452 Termination messages not meeting the validity requirements MUST be 453 silently discarded or logged in a rate-limited manner. 455 If the message passes these validation steps, a Solicitation is 456 sent. If an Advertisement is not received within 457 NeighborDeadInterval, the sending router is removed from the list of 458 active multicast routers. 460 6. Protocol Constants 462 Haberman, Martin 9 463 The following list identifies constants used in the MRD protocol. 464 These constants are used in the calculation of parameters. 466 . MAX_RESPONSE_DELAY 2 seconds 467 . MAX_SOLICITATION_DELAY 1 second 468 . MAX_SOLICITATIONS 3 transmissions 470 7. Security Considerations 472 The Multicast Router Advertisement message may allow rogue machines 473 to masquerade as multicast routers. This could allow those machines 474 to eavesdrop on multicast data transmissions. Additionally, it could 475 constitute a denial of service attack to other hosts in the same 476 snooping domain or sharing the same device port in the presence of 477 high rate multicast flows. 479 Should a Multicast Router Terminate message be spoofed with the 480 source address of a valid multicast router, a device may discontinue 481 forwarding of multicast source data to that router. This would 482 disrupt the reception of this data beyond the local subnet. 484 Both of these issues stem from the fact that there is currently no 485 mechanism for hosts to authenticate and authorize messages being 486 sent from local routers. This problem is shared by all IGMP and 487 ICMPv6 messages, as well as other protocols such as IPv6 Neighbor 488 Discovery. 490 While solving this problem is beyond the scope of this document, it 491 is worth noting that work in the Secure Neighbor Discovery Working 492 Group may be applicable to Multicast Router Discovery. Should this 493 work prove successful, appropriate mechanisms will be incorporated 494 into a later revision of MRD. 496 8. IANA Considerations 498 This document introduces three new IGMP messages. Each of these 499 messages requires a new IGMP Type value. This document requests 500 IANA to assign three new IGMP Type values to the Multicast Router 501 Discovery Protocol (for IPv4 Advertisements, Solicitations, and 502 Terminations). 504 This document also introduces three new MLD messages. Each of these 505 messages requires a new ICMPv6 Type value. This document requests 506 IANA to assign three new ICMPv6 Type values to the Multicast Router 507 Discovery Protocol (for IPv6 Advertisements, Solicitations, and 508 Terminations). 510 This document also requires the assignment of an All-Snoopers 511 multicast address for IPv4. This multicast address should be in the 512 224.0.0/24 range since it is used for link-local, control message. 514 Haberman, Martin 10 515 A corresponding IPv6 multicast address is also requested. Following 516 the guidelines in [RFC3307], the IPv6 multicast address should be 517 link-local in scope and have a group-ID value equal to the lowest- 518 order 8 bits of the requested IPv4 multicast address. 520 9. Acknowledgements 522 ICMP Router Discovery [RFC1256] was used as a general model for 523 Multicast Router Discovery. 525 Morten Christensen, Pekka Savola, Hugh Holbrook, and Isidor Kouvelas 526 provided helpful feedback on various versions of this document. 528 10. References 530 10.1 Normative References 532 10.2 Informative References 534 11. Authors 536 Brad Cain and Shantam Biswas were initial authors on this document. 538 12. Editors' Addresses 540 Brian Haberman Jim Martin 541 Caspian Networks Netzwert AG 542 753 Bridgewater Drive D-12435 Berlin 543 Sykesville, MD 21784 545 brian@innovationslab.net jim@netzwert.ag 546 +1-443-280-0932 +49.30/5 900 800-180 548 13. Full Copyright Statement 550 Copyright (C) The Internet Society (2004). All Rights Reserved. 552 This document and translations of it may be copied and furnished to 553 others, and derivative works that comment on or otherwise explain it 554 or assist in its implementation may be prepared, copied, published 555 and distributed, in whole or in part, without restriction of any 556 kind, provided that the above copyright notice and this paragraph 557 are included on all such copies and derivative works. However, this 558 document itself may not be modified in any way, such as by removing 559 the copyright notice or references to the Internet Society or other 560 Internet organizations, except as needed for the purpose of 561 developing Internet standards in which case the procedures for 562 copyrights defined in the Internet Standards process must be 563 followed, or as required to translate it into languages other than 564 English. 566 The limited permissions granted above are perpetual and will not be 568 Haberman, Martin 11 569 revoked by the Internet Society or its successors or assigns. 571 This document and the information contained herein is provided on an 572 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 573 TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 574 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 575 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 576 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 578 Haberman, Martin 12