idnits 2.17.1 draft-ietf-idmr-membership-reports-05.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-24) 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: ---------------------------------------------------------------------------- ** 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. == 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 an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 7 instances of too long lines in the document, the longest one being 8 characters in excess of 72. ** The abstract seems to contain references ([RFC2236]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 12 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (December 2000) is 8531 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? 'RFC2236' on line 341 looks like a reference -- Missing reference section? 'Thya94' on line 47 looks like a reference -- Missing reference section? 'Estr98' on line 47 looks like a reference -- Missing reference section? 'RFC2119' on line 64 looks like a reference -- Missing reference section? '0' on line 166 looks like a reference -- Missing reference section? '223' on line 166 looks like a reference -- Missing reference section? '224' on line 167 looks like a reference -- Missing reference section? '239' on line 167 looks like a reference -- Missing reference section? 'RFC2401' on line 538 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Internet-Draft Multicast Remnants WG 2 INTERNET-DRAFT W. Fenner 3 draft-ietf-idmr-membership-reports-05.txt July 11, 2000 4 Expires December 2000 6 Domain Wide Multicast Group Membership Reports 8 Status of this Memo 10 This document is an Internet Draft and is in full conformance with all 11 provisions of Section 10 of RFC2026. Internet Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its Areas, and 13 its Working Groups. Note that other groups may also distribute working 14 documents as Internet Drafts. 16 Internet Drafts are draft documents valid for a maximum of six months. 17 Internet Drafts may be updated, replaced, or obsoleted by other 18 documents at any time. It is not appropriate to use Internet Drafts as 19 reference material or to cite them other than as a "working draft" or 20 "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 Distribution of this document is unlimited. 30 Abstract 32 When running a multi-level multicast routing protocol, upper levels 33 need to know about group memberships in lower levels in a protocol- 34 independent fashion. Domain Wide Multicast Group Membership 35 Reports allow this information to be learned in a fashion similar 36 to IGMP[RFC2236] at the domain level. 38 This document is a product of the IDMR working group within the Internet 39 Engineering Task Force. Comments are solicited and should be addressed 40 to the working group's mailing list at idmr@cs.ucl.ac.uk and/or the 41 author. 43 1. Introduction 45 Domain-Wide Multicast Group Membership Reports (DWRs) are a group 46 membership protocol at the domain level. When using a hierarchical 47 multicast routing protocol [Thya94,Estr98], the inter-domain protocol 48 needs to learn of group memberships inside domains. Although some 49 intra-domain routing protocols can provide this information easily to 50 the domain border routers, some cannot. DWRs specify a protocol- 51 independent manner to learn group membership inside a domain. 53 This document specifies the DWR protocol, as used by border routers and 54 interior routers. It specifies a behavior that can be used with any 55 intra-domain protocol, along with optimizations for certain intra-domain 56 protocols, and a transition scheme so that all interior routers need not 57 be updated. 59 1.1. Conventions 61 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 62 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 63 document are to be interpreted as described in [RFC2119]. 65 Tunable timer values are named inside square brackets, e.g. [Robustness 66 Variable]. These values are described in section 8. 68 2. Packet Format 70 DWR packets are sent as UDP packets (IP protocol #17). The UDP 71 destination port is 644. The UDP checksum SHOULD be calculated on 72 transmission. However, packets without checksums MUST be accepted. 73 Received packets with incorrect checksums MUST be dropped. The UDP 74 payload is as follows: 76 0 1 2 3 77 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 78 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 79 | MBZ | DWR Type | 80 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 81 | Type-specific header ... 82 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 83 | Data ... 84 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 86 2.1. MBZ: 24 bits 88 Must be zeroed on transmission and ignored on reception. 90 2.2. DWR Type: 8 bits 92 The following DWR types are defined: 94 center; c | c l | l. Type Name _ 0x00 Domain-Wide Query 95 0x01 Domain-Wide Membership Report 0x02 Domain-Wide Leave 0x03 Non- 96 authoritative Domain-Wide Leave 98 2.3. Type-specific header 100 The only type-specific header defined is for the Domain-Wide Query; 101 its header contains: 103 0 1 2 3 104 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 105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 106 | Response Time | Query Interval| Robustness | 107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 108 | MBZ | Priority | 109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 111 2.3.1. Response Time 113 The time, in units of 10ms, allowed for responses to this query. 114 Varying this field allows tuning the burstiness of DWR traffic at 115 the cost of higher latencies. 117 2.3.2. Query Interval 119 The time, in units of 10 seconds, between periodic Query messages 120 from this Querier. 122 2.3.3. Robustness 124 The Robustness variable, described later. Along with the Query 125 Interval, conveying this data in the Query allows exact calculation 126 of Querier timeouts and allows interior routers to calculate the 127 group membership lifetime. 129 2.3.4. Priority 131 The configured priority of this border router for Querier Election 132 purposes. If no value is configured, the default value is 128. 133 Lower values are better, i.e. more likely to be selected as the 134 querier. 136 2.3.5. MBZ 138 This field must be zeroed on transmission and ignored on reception. 140 There is no type-specific header for Report and Leave messages; the data 141 field starts immediately after the checksum. 143 2.4. Data 145 The remainder of the packet consists of a series of groups and 146 options. Each field in the rest of the packet is either a group 147 address: 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 | Group Address | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 or an option header: 157 0 1 2 3 158 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 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | option number | MBZ |S|I| Option Length | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | Option Data... 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 The two forms may be told apart because option numbers are assigned 166 in the range [0,223], the first byte of an IPv4 group address is in 167 the range [224,239], and the first byte of an IPv6 group address is 168 255. 170 2.4.1. Data Description 172 2.4.1.1. Group Address 174 The group address being reported or queried. 176 2.4.1.2. Option Number 178 The number of the option. 180 2.4.1.3. MBZ 182 Must be zeroed on transmission and ignored on reception. 184 2.4.1.4. I 186 Ignore this packet or group for group membership purposes if 187 the option is not recognized. 189 2.4.1.5. S 191 Ignore this packet or group for report suppression purposes 192 (on Reports or Leaves) or for reply purposes (on Queries) if 193 the option is not recognized. 195 2.4.1.6. Option Length 197 The number of words, excluding the initial word, of option 198 data following the option header. 200 2.4.1.7. Option Data 202 Option Length words of data. 204 2.4.2. Option Processing 206 Options which precede any group addresses are called Global 207 Options. Options which follow a group address are associated 208 with that group address and are called Group Options. There 209 are two bits describing how to handle unsupported options. 211 2.4.2.1. The S bit 213 The S bit is used when processing Queries, Reports and Leaves 214 by interior routers. Groups with options attached should be 215 ignored as if they were not present if there are unrecognized 216 Group Options with the S bit set. Packets with Global Options 217 should be ignored as if they were not received if there are 218 unrecognized Global Options with the S bit set. 220 2.4.2.2. The I bit 222 The I bit is used when processing Reports and Leaves by border 223 routers. Groups with options attached should be ignored as if 224 they were not present if there are unrecognized Group Options 225 with the I bit set. Packets with Global Options should be 226 ignored as if they were not received if there are unrecognized 227 Global Options with the I bit set. 229 2.4.3. Defined Options 231 2.4.3.1. Padding (option #0) 233 This option need not be handled specially by option 234 parsers; it may be left as an unrecognized option. The S 235 and I bits are both 0, so failing to recognize this 236 option does not affect the processing of the packet. The 237 length field may be 0, meaning there are 0 additional 238 words of data associated with the option. A non-zero 239 length field may be used with the padding option if 240 additional padding is required. 242 Routers MUST interpret the S and I bits of Padding 243 options as though the option is not supported. 245 2.4.3.2. Group masks accepted/present (option #1) 247 This option may be used as a global option on a Query, to 248 indicate that all border routers understand the group 249 mask option in Report and Leave messages. This option 250 MUST only be sent when the Querier knows that all border 251 routers support it; in general this can only be by manual 252 configuration. In this use, the I and S bits are off. 254 When the most recent Query message contained the Group 255 masks accepted global option, a router may attach a group 256 masks present option to any group in its Report or Leave 257 messages. This option contains the following data: 259 0 1 2 3 260 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 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | 1 | MBZ |0|0| 1 for IPv4, 4 for IPv6 | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | Mask to go with group | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 The data portion is a bitwise mask, to be applied to the 268 group to create a group range. 270 This usage also has the S and I bits turned off. 272 2.4.3.3. Unicast-reply (option #2) 274 This option has the S and I bits turned off. If a query 275 is received with this option, the reply should be 276 unicasted to the source of the query. If the option 277 carries a unicast address, it is the address to be 278 unicasted to. 280 If a unicast address is specified in the option, the 281 option MUST be ignored if the packet is not authenticated 282 using IPSEC[RFC2401] as described later in this document. 284 3. Message Descriptions 286 3.1. Domain-Wide Query 288 A Domain-Wide Query is sent periodically by one of the domain's 289 border routers. The default period is 5 minutes, and MUST be 290 configurable. Domain-Wide Query messages are sent to the well- 291 known Domain-Wide Query multicast group (224.0.255.254). This 292 group is in the range of addresses that are scoped to a single 293 domain, 224.0.255.0 through 224.0.255.255. 295 A Domain-Wide Query with no additional data is a request for 296 knowledge of all multicast group memberships in the domain. The 297 Domain-Wide Query may be restricted by including groups or options 298 in the data portion of the packet. If group addresses or DWR 299 options are specified in the packet, the Query is restricted to 300 those groups or other options as specified in the packet. 302 3.2. Domain-Wide Report 304 A Domain-Wide Report is sent by a router in response to a Domain- 305 Wide Query message, or in response to the appearance of a new group 306 member in the domain. The latter messages are called "Unsolicited" 307 Domain-Wide Reports. 309 A Domain-Wide Report message includes a list of group memberships 310 and other options in the additional data portion of the packet. 312 3.3. Domain-Wide Leave 314 A Domain-Wide Leave is sent by a router when it knows that there 315 are no more members in the domain of a group or groups. The group 316 or groups listed in the additional data portion of the packet are 317 considered by the border routers to have no more members. 319 3.4. Non-Authoritative Domain-Wide Leave 321 A Non-Authoritative Domain-Wide Leave is sent by a router when it 322 knows of no more members of the group but cannot be sure there are 323 no more members in the domain. Reception of a Domain-Wide Leave 324 causes the elected border router to send a Domain-Wide Query 325 message for the group(s) mentioned in the Non-Authoritative Domain- 326 Wide Leave message. 328 4. Interior Router Behavior 330 4.1. General Behavior 332 This section describes the general behavior of interior routers, or 333 of proxies running inside domains. Some of these behaviors may be 334 optimized when running multicast routing protocols with more 335 centralized knowledge of group memberships inside the domain; these 336 optimizations will be described later. 338 If a router has not yet been upgraded to perform domain-wide 339 reports, a proxy may be placed on each of its connected networks. 340 This proxy must participate in the network's group membership 341 protocol (e.g. IGMPv2[RFC2236]). For example, it may perform only 342 the duties of a Non-Querier router in IGMPv2, which allow it to 343 passively learn all of the group members on a network. The proxy 344 can then respond to Domain-Wide Query messages just as the interior 345 router would. 347 4.1.1. Reception of Queries 349 All routers in the domain join the Domain-Wide Query well-known 350 multicast group. Upon reception of a Domain-Wide Query message, a 351 router sets a timer to a value randomly chosen from the range (0, 352 Response time] as specified in the packet. The Data section of the 353 Query should be saved to be used when the timer expires. 355 4.1.2. Transmission of Reports 357 Upon the expiration of a Domain-Wide Query timer, a router 358 assembles a packet containing the list of group memberships known 359 to this router via IGMP or other mechanism, excluding those that 360 were suppressed by previous reports, and sends this message to the 361 Domain-Wide Report well-known multicast group (224.0.255.253). If 362 the Domain-Wide Query contained a list of groups or options, the 363 Report should be restricted to those groups in the list in the 364 Query message. 366 4.1.3. Reception of Reports 368 All routers in the domain join the Domain-Wide Report well-known 369 multicast group in order to perform suppression, as follows. Upon 370 reception of a Domain-Wide Report message, a router processes the 371 list of groups in the message. If the packet contains unrecognized 372 global options, the packet should be dropped and not processed if 373 any of the unrecognized options have their S bit set. For each 374 group, if the group has unrecognized options, the group should be 375 skipped if any of the unrecognized options have their S bit set. 376 Otherwise, if the router's Domain-Wide Query timer is running, it 377 SHOULD mark the group as having been suppressed and SHOULD NOT 378 report it when the Domain-Wide Query timer expires. 380 Routers MAY record the existence of this group membership in the 381 domain to be used for future suppression. This record MUST time 382 out after [Query Interval] * [Robustness Variable], and MUST be 383 canceled by reception of a Domain-Wide Leave or Non-Authoritative 384 Domain-Wide Leave message mentioning this group. 386 4.1.4. Reception of Leaves 388 Upon the reception of a Domain-Wide Leave, a router should process 389 the list of groups in the message. For each group, if the group 390 has unrecognized options, it should be skipped if any of the 391 unrecognized options have their S bit set. Otherwise, the router 392 should remove its record of the existence of another group 393 membership in the domain. 395 4.1.5. Transmission of Leaves 397 A router sends a Non-Authoritative Leave when it no longer knows of 398 any members of the group. This message MAY be suppressed if this 399 router's last attempt to report this group was suppressed by 400 reception of a Report. 402 4.2. Optimizations 404 In explicit group membership protocols like PIM, CBT and MOSPF, 405 there is a set of routers smaller than "all routers in the domain" 406 which knows of group memberships in the domain. This section 407 describes the optimizations possible when running a protocol like 408 this. 410 In PIM and CBT, only RP's and Cores must participate. MOSPF is a 411 special case, in that all routers in the MOSPF domain know of all 412 group memberships in the domain. In this case, the DWR protocol 413 may degenerate to a virtual protocol run entirely inside the 414 elected border router. 416 4.2.1. Reception of a Query Message 418 Only participating interior routers must join the Domain-Wide Query 419 well-known multicast group. 421 4.2.2. Transmission of a Report Message 423 Report messages contain all memberships that this router knows 424 about (e.g. in MOSPF, it's all memberships in the domain; in PIM, 425 it's all groups that for which this router is the RP). 427 4.2.3. Reception of a Report Message 429 If there is no overlap of the groups being reported by each 430 participant, the interior routers need not join the Domain-Wide 431 Report well-known multicast group so will not receive Report 432 messages. E.g. if R1 and R2 each handle one half of the multicast 433 group address space, there is no need for either of them to join 434 the Domain-Wide Report group. 436 4.2.4. Reception of a Leave Message 438 As with Reports, if there is no overlap, the interior routers need 439 not join the DWR group so will not receive these messages. 441 4.2.5. Transmission of a Leave Message 443 If it is possible to know when the last member in the domain goes 444 away, routers SHOULD send authoritative Domain-Wide Leave messages, 445 instead of Non-Authoritative Domain-Wide Leave messages. 447 5. Unsolicited messages 449 When a new group member appears in the domain, a Report message 450 SHOULD be transmitted (called an Unsolicited Report). Interior 451 routers MAY track the presence of group members inside the domain; 452 a router which is doing this SHOULD suppress its unsolicited Report 453 if it knows of another group member inside the domain. 455 6. Border Router Behavior 457 6.1. Querier Election 459 All border routers should join the Domain-Wide Queries well-known 460 multicast group, in order to perform Querier Election. All routers 461 start up thinking they are the elected Querier. If a router hears 462 a DWQ which has a lower ("better") priority, or an equal priority 463 and a lower IP address, it elects that router as Querier. If a 464 router has not heard a DWQ from the elected Querier in [Querier's 465 Query Interval] * [Querier's Robustness Variable] + [Querier's 466 Response Interval], it assumes the role of Querier. It is 467 recommended to have an IPSEC[RFC2401] relationship for the DWQ 468 multicast group among the domain border routers so that Querier 469 Election can not be fouled by a forged packet. 471 6.2. Send Periodic Queries 473 The elected border router sends periodic Queries once every [Query 474 Interval]. These Queries include the router's Query Interval and 475 Robustness Variable. The Response Interval should be set to 476 [Normal Response Interval]. 478 6.3. Reception of Non-Authoritative Leave 480 Upon reception of a Non-Authoritative Leave, the elected Querier 481 sets a group membership timeout timer to [Robustness Variable] * 482 [Fast Response Interval] + [Round Trip Delay], and sends a group- 483 specific Query, listing all groups in the Non-Authoritative Leave 484 message. The Response Interval should be set to [Fast Response 485 Interval]. Until a response is heard for each listed group, the 486 Query should be retransmitted once every [Fast Response Interval] 487 for a total of [Robustness Variable] transmissions. The Querier 488 MUST wait an additional [Round Trip Delay] after the final [Fast 489 Response Interval] for reports before assuming that there are no 490 members present in the domain. 492 6.4. Reception of Group-Specific Queries 494 Upon reception of a Group-Specific Query, non-Querier routers MUST 495 set a group membership timeout timer to [Querier's Robustness 496 Variable] * [Querier's Response Interval] + [Round Trip Delay]. If 497 this timeout occurs without receiving a Report for the listed 498 groups, the group membership record is removed. The Querier's 499 Query Interval and Querier's Response Interval are the values 500 carried in the Query packet. 502 6.5. Reception of Reports 504 Upon reception of a Domain-Wide Report message, all border routers 505 set a group membership timer for each group mentioned in the 506 Report. This timer's value is set to [Querier's Query Interval] * 507 [Querier's Robustness Variable] + [Querier's Response Interval] * 508 2. The Querier's Query Interval, Querier's Response Interval and 509 Querier's Robustness Variable are remembered from the last General 510 Query received from the Querier. This timer is refreshed by 511 reception of further messages. 513 6.6. Request Unicast Replies 515 If a Border Router wishes to reduce the amount of DWR multicast 516 traffic in a domain, it may add the "Reply via Unicast" option to 517 its DWQ's. This has the advantage of reducing the amount of state 518 kept inside the domain for forwarding packets destined to the DWR- 519 reply multicast group, at the cost of eliminating suppression. The 520 border router must multicast DWR's summarizing the replies it got 521 via unicast to the DWR-reply multicast group at the end of the 522 response interval, in order to share membership information with 523 all routers. This summary MUST contain a global padding option 524 with its S bit set to 1, to prevent suppression of real reports. 526 7. Use of IPSEC 528 The use of IPSEC AH is recommended on Domain-Wide Query packets for 529 two reasons: 531 1. Prevention of forgery of Queries which can foil Querier election. 532 This use requires all border routers to use IPSEC. 534 2. In order to allow the use of the Unicast Replies option. This use 535 requires all border and interior routers to use IPSEC. 537 In either configuration, security associations are configured as 538 described in section 4.7 of [RFC2401]. Briefly, a single Security 539 Association is manually configured in all required devices with a 540 static key. The number of devices (e.g. domain border routers) 541 should be small enough for this to not be an undue burden. When a 542 secure multicast key distribution protocol exists in the IPSEC 543 framework, this protocol may be used instead of manual 544 configuration. 546 8. List of timers and tunable values 548 8.1. Robustness Variable 550 The Robustness Variable allows tuning for the expected packet loss 551 in a domain. If transmission inside a domain is expected to be 552 lossy, the Robustness Variable may be increased, at the cost of 553 increased latency in determining failures. The DWR protocol is 554 robust to ([Robustness Variable] - 1) packet losses. The 555 Robustness Variable MUST NOT be zero, and SHOULD NOT be one. 556 Default value: 2 558 8.2. Query Interval 560 The Query Interval is the interval between General Queries sent by 561 the domain-wide Querier. Default value: 5 minutes 563 8.3. Normal Response Interval 565 The Normal Response Interval is the Response Time inserted into the 566 periodic General Queries. Default: 60 seconds 568 By varying the [Normal Response Interval], an administrator may 569 tune the burstiness of DWR messages in the domain; larger values 570 make the traffic less bursty, as host responses are spread out over 571 a larger interval. The number of seconds represented by the 572 [Normal Response Interval] must be less than the [Query Interval]. 574 8.4. Fast Response Interval 576 The Fast Response Interval is the Response Time inserted into 577 Group-Specific Queries in response to Non-Authoritative Leave 578 messages, and is also the time between the Group-Specific Query 579 messages. Default: 1 second 581 This value may be tuned to modify the "leave latency" of the 582 domain. A reduced value results in reduced time to detect the loss 583 of the last member of a group. 585 8.5. Round Trip Delay 587 The Round Trip Delay is the worst-case round trip time through the 588 domain. This is used to ensure that group membership is not lost 589 due to a small Fast Response Interval and a large round trip delay 590 through the domain. This value must be manually configured. 591 Default: 100ms. 593 IGMPv2 ignores end-to-end message delay, assuming that this delay 594 is negligible. Although the DWR protocol is very similar to 595 IGMPv2, the reality is that end-to-end round trip delays can be 596 very different on LANs vs. in a routing domain. On a LAN, the 597 round trip delay is generally dwarfed by the IGMPv2 response 598 interval. Within a domain, the opposite may be true, so it's 599 important for the protocol to acknowledge that. 601 9. Message destinations 603 This information is provided elsewhere in the document, but is 604 summarized here for convenience. 606 Message Type Destination Group 607 ------------ ----------------- 608 General Query Domain-wide Query group (224.0.255.254) 609 Group-specific Query Domain-wide Query group (224.0.255.254) 610 Report Domain-wide Report group (224.0.255.253) 611 Leave Domain-wide Report group (224.0.255.253) 612 Non-Authoritative Leave Domain-wide Report group (224.0.255.253) 614 10. Acknowledgments 616 The ideas of unicasting DWR replies and of electing a "designated 617 reporter" came from a discussion on the IDMR mailing list with 618 Jeffrey Zhang and Yunzhou Li of Bay Networks. 620 11. Security Considerations 622 11.1. Forged Packets 624 11.1.1. Forged Packets from Outside the Domain 626 Since all packets in this memo are sent to domain-scoped multicast 627 groups, a scope boundary around the domain which drops domain- 628 scoped packets from entering the domain from outside protects 629 against forged packets from outside the domain. 631 11.1.2. Forged Packets from Inside the Domain 633 We consider the effects of a forged packet of each type. 635 11.1.2.1. Forged Query 637 A forged Query will cause interior routers to send Reports for some 638 or all of their group memberships, increasing control traffic 639 within the domain but not affecting the memberships learned by the 640 border routers. 642 Border routers perform Querier Elections on Query messages. A 643 forged General Query could cause the forger to be elected Querier, 644 giving him some control over the group membership reporting in the 645 domain. For this reason, IPSEC SHOULD be used between the domain 646 border routers to ensure that Querier election only occurs between 647 known border routers. 649 11.1.2.2. Forged Report 651 A forged Report will cause interior routers to suppress their own 652 Report messages for the group being reported. However, the forged 653 message will be accepted by the border routers, so this 654 accomplishes nothing. 656 If interior routers keep state for all Reports heard, forged 657 Reports can cause increased memory consumption on interior routers. 658 However, keeping state for all Reports is optional, so interior 659 routers that are running low on memory due to the amount of DWR- 660 related state may simply release all of that state. 662 Border routers must keep state for all Reports heard, so they are 663 vulnerable to increased memory consumption. If this is a worry, 664 once again IPSEC relationships may be created between all of the 665 interior routers and the border routers. This is a much larger 666 burden on administrators, however, so is only recommended if this 667 is expected to be a problem. 669 11.1.2.3. Forged Leave 671 A forged Leave (Authoritative or Non-Authoritative) will cause 672 interior routers to forget their state (if any) regarding the 673 suppression status of a group. This may cause increased control 674 message traffic during the next Query interval. 676 A forged Non-Authoritative leave will cause the border routers to 677 issue group-specific Query messages to learn if there are remaining 678 group members. This causes increased control message traffic. 680 A forged Authoritative Leave will cause a black hole until the next 681 Query occurs; the border routers will accept the Leave and not 682 perform any Queries. Border routers SHOULD be configurable to 683 ignore all Authoritative Leaves and interior routers SHOULD be 684 configurable to only send Non-Authoritative Leaves, in order to be 685 able to prevent this attack. 687 11.2. Unicast Responses 689 Sending a DWQ requesting a unicast response can cause many DWR's to 690 be unicasted to the sender. In order to prevent the use of this 691 option as a "packet amplifier", any DWQ message using this option 692 SHOULD be authenticated using IPSEC as described in this document. 694 12. References 696 RFC2119 Bradner, S., "Key words for use in RFCs to Indicate 697 Requirement Levels", RFC 2119/BCP 14, Harvard University, 698 March 1997. 700 Estr98 Estrin, D., D. Meyer, D. Thaler, ``Border Gateway 701 Multicast Protocol (BGMP): Protocol Specification'', Work 702 In Progress, March 1998. 704 RFC2236 Fenner, W. ``Internet Group Management Protocol, Version 705 2'', RFC2236, Xerox PARC, November 1997. 707 RFC2401 Kent, S. and R. Atkinson, ``Security Architecture for the 708 Internet Protocol'', RFC 2401, November 1998. 710 Thya95 Thyagarajan, A. and S. Deering, ``Hierarchical Distance- 711 Vector Multicast Routing'', Proceedings of ACM Sigcomm, 712 September 1995. 714 13. Author's Address 716 William C. Fenner 717 AT&T Labs - Research 718 75 Willow Road 719 Menlo Park, CA 94025 720 Phone: +1 650 330 7893 721 Email: fenner@research.att.com