idnits 2.17.1 draft-ietf-idmr-membership-reports-04.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-23) 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 (February 2000) is 8834 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 345 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 170 looks like a reference -- Missing reference section? '223' on line 170 looks like a reference -- Missing reference section? '224' on line 171 looks like a reference -- Missing reference section? '239' on line 171 looks like a reference -- Missing reference section? 'RFC2401' on line 542 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-04.txt August 25, 1999 4 Expires February 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: 93 | 94 Type | Name 95 -----+------------------------------------- 96 0x00 | Domain-Wide Query 97 0x01 | Domain-Wide Membership Report 98 0x02 | Domain-Wide Leave 99 0x03 | Non-authoritative Domain-Wide Leave 101 2.3. Type-specific header 103 The only type-specific header defined is for the Domain-Wide Query; 104 its header contains: 106 0 1 2 3 107 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 108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 109 | Response Time | Query Interval| Robustness | 110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 111 | MBZ | Priority | 112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 114 2.3.1. Response Time 116 The time, in units of 10ms, allowed for responses to this query. 117 Varying this field allows tuning the burstiness of DWR traffic at 118 the cost of higher latencies. 120 2.3.2. Query Interval 122 The time, in units of 10 seconds, between periodic Query messages 123 from this Querier. 125 2.3.3. Robustness 127 The Robustness variable, described later. Along with the Query 128 Interval, conveying this data in the Query allows exact calculation 129 of Querier timeouts and allows interior routers to calculate the 130 group membership lifetime. 132 2.3.4. Priority 134 The configured priority of this border router for Querier Election 135 purposes. If no value is configured, the default value is 128. 137 Lower values are better, i.e. more likely to be selected as the 138 querier. 140 2.3.5. MBZ 142 This field must be zeroed on transmission and ignored on reception. 144 There is no type-specific header for Report and Leave messages; the data 145 field starts immediately after the checksum. 147 2.4. Data 149 The remainder of the packet consists of a series of groups and 150 options. Each field in the rest of the packet is either a group 151 address: 153 0 1 2 3 154 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 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | Group Address | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 or an option header: 161 0 1 2 3 162 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 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | option number | MBZ |S|I| Option Length | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | Option Data... 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 The two forms may be told apart because option numbers are assigned 170 in the range [0,223], the first byte of an IPv4 group address is in 171 the range [224,239], and the first byte of an IPv6 group address is 172 255. 174 2.4.1. Data Description 176 2.4.1.1. Group Address 178 The group address being reported or queried. 180 2.4.1.2. Option Number 182 The number of the option. 184 2.4.1.3. MBZ 186 Must be zeroed on transmission and ignored on reception. 188 2.4.1.4. I 190 Ignore this packet or group for group membership purposes if 191 the option is not recognized. 193 2.4.1.5. S 195 Ignore this packet or group for report suppression purposes 196 (on Reports or Leaves) or for reply purposes (on Queries) if 197 the option is not recognized. 199 2.4.1.6. Option Length 201 The number of words, excluding the initial word, of option 202 data following the option header. 204 2.4.1.7. Option Data 206 Option Length words of data. 208 2.4.2. Option Processing 210 Options which precede any group addresses are called Global 211 Options. Options which follow a group address are associated 212 with that group address and are called Group Options. There 213 are two bits describing how to handle unsupported options. 215 2.4.2.1. The S bit 217 The S bit is used when processing Queries, Reports and Leaves 218 by interior routers. Groups with options attached should be 219 ignored as if they were not present if there are unrecognized 220 Group Options with the S bit set. Packets with Global Options 221 should be ignored as if they were not received if there are 222 unrecognized Global Options with the S bit set. 224 2.4.2.2. The I bit 226 The I bit is used when processing Reports and Leaves by border 227 routers. Groups with options attached should be ignored as if 228 they were not present if there are unrecognized Group Options 229 with the I bit set. Packets with Global Options should be 230 ignored as if they were not received if there are unrecognized 231 Global Options with the I bit set. 233 2.4.3. Defined Options 235 2.4.3.1. Padding (option #0) 237 This option need not be handled specially by option 238 parsers; it may be left as an unrecognized option. The S 239 and I bits are both 0, so failing to recognize this 240 option does not affect the processing of the packet. The 241 length field may be 0, meaning there are 0 additional 242 words of data associated with the option. A non-zero 243 length field may be used with the padding option if 244 additional padding is required. 246 Routers MUST interpret the S and I bits of Padding 247 options as though the option is not supported. 249 2.4.3.2. Group masks accepted/present (option #1) 251 This option may be used as a global option on a Query, to 252 indicate that all border routers understand the group 253 mask option in Report and Leave messages. This option 254 MUST only be sent when the Querier knows that all border 255 routers support it; in general this can only be by manual 256 configuration. In this use, the I and S bits are off. 258 When the most recent Query message contained the Group 259 masks accepted global option, a router may attach a group 260 masks present option to any group in its Report or Leave 261 messages. This option contains the following data: 263 0 1 2 3 264 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 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | 1 | MBZ |0|0| 1 for IPv4, 4 for IPv6 | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | Mask to go with group | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 The data portion is a bitwise mask, to be applied to the 272 group to create a group range. 274 This usage also has the S and I bits turned off. 276 2.4.3.3. Unicast-reply (option #2) 278 This option has the S and I bits turned off. If a query 279 is received with this option, the reply should be 280 unicasted to the source of the query. If the option 281 carries a unicast address, it is the address to be 282 unicasted to. 284 If a unicast address is specified in the option, the 285 option MUST be ignored if the packet is not authenticated 286 using IPSEC[RFC2401] as described later in this document. 288 3. Message Descriptions 290 3.1. Domain-Wide Query 292 A Domain-Wide Query is sent periodically by one of the domain's 293 border routers. The default period is 5 minutes, and MUST be 294 configurable. Domain-Wide Query messages are sent to the well- 295 known Domain-Wide Query multicast group (224.0.255.254). This 296 group is in the range of addresses that are scoped to a single 297 domain, 224.0.255.0 through 224.0.255.255. 299 A Domain-Wide Query with no additional data is a request for 300 knowledge of all multicast group memberships in the domain. The 301 Domain-Wide Query may be restricted by including groups or options 302 in the data portion of the packet. If group addresses or DWR 303 options are specified in the packet, the Query is restricted to 304 those groups or other options as specified in the packet. 306 3.2. Domain-Wide Report 308 A Domain-Wide Report is sent by a router in response to a Domain- 309 Wide Query message, or in response to the appearance of a new group 310 member in the domain. The latter messages are called "Unsolicited" 311 Domain-Wide Reports. 313 A Domain-Wide Report message includes a list of group memberships 314 and other options in the additional data portion of the packet. 316 3.3. Domain-Wide Leave 318 A Domain-Wide Leave is sent by a router when it knows that there 319 are no more members in the domain of a group or groups. The group 320 or groups listed in the additional data portion of the packet are 321 considered by the border routers to have no more members. 323 3.4. Non-Authoritative Domain-Wide Leave 325 A Non-Authoritative Domain-Wide Leave is sent by a router when it 326 knows of no more members of the group but cannot be sure there are 327 no more members in the domain. Reception of a Domain-Wide Leave 328 causes the elected border router to send a Domain-Wide Query 329 message for the group(s) mentioned in the Non-Authoritative Domain- 330 Wide Leave message. 332 4. Interior Router Behavior 334 4.1. General Behavior 336 This section describes the general behavior of interior routers, or 337 of proxies running inside domains. Some of these behaviors may be 338 optimized when running multicast routing protocols with more 339 centralized knowledge of group memberships inside the domain; these 340 optimizations will be described later. 342 If a router has not yet been upgraded to perform domain-wide 343 reports, a proxy may be placed on each of its connected networks. 344 This proxy must participate in the network's group membership 345 protocol (e.g. IGMPv2[RFC2236]). For example, it may perform only 346 the duties of a Non-Querier router in IGMPv2, which allow it to 347 passively learn all of the group members on a network. The proxy 348 can then respond to Domain-Wide Query messages just as the interior 349 router would. 351 4.1.1. Reception of Queries 353 All routers in the domain join the Domain-Wide Query well-known 354 multicast group. Upon reception of a Domain-Wide Query message, a 355 router sets a timer to a value randomly chosen from the range (0, 356 Response time] as specified in the packet. The Data section of the 357 Query should be saved to be used when the timer expires. 359 4.1.2. Transmission of Reports 361 Upon the expiration of a Domain-Wide Query timer, a router 362 assembles a packet containing the list of group memberships known 363 to this router via IGMP or other mechanism, excluding those that 364 were suppressed by previous reports, and sends this message to the 365 Domain-Wide Report well-known multicast group (224.0.255.253). If 366 the Domain-Wide Query contained a list of groups or options, the 367 Report should be restricted to those groups in the list in the 368 Query message. 370 4.1.3. Reception of Reports 372 All routers in the domain join the Domain-Wide Report well-known 373 multicast group in order to perform suppression, as follows. Upon 374 reception of a Domain-Wide Report message, a router processes the 375 list of groups in the message. If the packet contains unrecognized 376 global options, the packet should be dropped and not processed if 377 any of the unrecognized options have their S bit set. For each 378 group, if the group has unrecognized options, the group should be 379 skipped if any of the unrecognized options have their S bit set. 380 Otherwise, if the router's Domain-Wide Query timer is running, it 381 SHOULD mark the group as having been suppressed and SHOULD NOT 382 report it when the Domain-Wide Query timer expires. 384 Routers MAY record the existence of this group membership in the 385 domain to be used for future suppression. This record MUST time 386 out after [Query Interval] * [Robustness Variable], and MUST be 387 canceled by reception of a Domain-Wide Leave or Non-Authoritative 388 Domain-Wide Leave message mentioning this group. 390 4.1.4. Reception of Leaves 392 Upon the reception of a Domain-Wide Leave, a router should process 393 the list of groups in the message. For each group, if the group 394 has unrecognized options, it should be skipped if any of the 395 unrecognized options have their S bit set. Otherwise, the router 396 should remove its record of the existence of another group 397 membership in the domain. 399 4.1.5. Transmission of Leaves 401 A router sends a Non-Authoritative Leave when it no longer knows of 402 any members of the group. This message MAY be suppressed if this 403 router's last attempt to report this group was suppressed by 404 reception of a Report. 406 4.2. Optimizations 408 In explicit group membership protocols like PIM, CBT and MOSPF, 409 there is a set of routers smaller than "all routers in the domain" 410 which knows of group memberships in the domain. This section 411 describes the optimizations possible when running a protocol like 412 this. 414 In PIM and CBT, only RP's and Cores must participate. MOSPF is a 415 special case, in that all routers in the MOSPF domain know of all 416 group memberships in the domain. In this case, the DWR protocol 417 may degenerate to a virtual protocol run entirely inside the 418 elected border router. 420 4.2.1. Reception of a Query Message 422 Only participating interior routers must join the Domain-Wide Query 423 well-known multicast group. 425 4.2.2. Transmission of a Report Message 427 Report messages contain all memberships that this router knows 428 about (e.g. in MOSPF, it's all memberships in the domain; in PIM, 429 it's all groups that for which this router is the RP). 431 4.2.3. Reception of a Report Message 433 If there is no overlap of the groups being reported by each 434 participant, the interior routers need not join the Domain-Wide 435 Report well-known multicast group so will not receive Report 436 messages. E.g. if R1 and R2 each handle one half of the multicast 437 group address space, there is no need for either of them to join 438 the Domain-Wide Report group. 440 4.2.4. Reception of a Leave Message 442 As with Reports, if there is no overlap, the interior routers need 443 not join the DWR group so will not receive these messages. 445 4.2.5. Transmission of a Leave Message 447 If it is possible to know when the last member in the domain goes 448 away, routers SHOULD send authoritative Domain-Wide Leave messages, 449 instead of Non-Authoritative Domain-Wide Leave messages. 451 5. Unsolicited messages 453 When a new group member appears in the domain, a Report message 454 SHOULD be transmitted (called an Unsolicited Report). Interior 455 routers MAY track the presence of group members inside the domain; 456 a router which is doing this SHOULD suppress its unsolicited Report 457 if it knows of another group member inside the domain. 459 6. Border Router Behavior 461 6.1. Querier Election 463 All border routers should join the Domain-Wide Queries well-known 464 multicast group, in order to perform Querier Election. All routers 465 start up thinking they are the elected Querier. If a router hears 466 a DWQ which has a lower ("better") priority, or an equal priority 467 and a lower IP address, it elects that router as Querier. If a 468 router has not heard a DWQ from the elected Querier in [Querier's 469 Query Interval] * [Querier's Robustness Variable] + [Querier's 470 Response Interval], it assumes the role of Querier. It is 471 recommended to have an IPSEC[RFC2401] relationship for the DWQ 472 multicast group among the domain border routers so that Querier 473 Election can not be fouled by a forged packet. 475 6.2. Send Periodic Queries 477 The elected border router sends periodic Queries once every [Query 478 Interval]. These Queries include the router's Query Interval and 479 Robustness Variable. The Response Interval should be set to 480 [Normal Response Interval]. 482 6.3. Reception of Non-Authoritative Leave 484 Upon reception of a Non-Authoritative Leave, the elected Querier 485 sets a group membership timeout timer to [Robustness Variable] * 486 [Fast Response Interval] + [Round Trip Delay], and sends a group- 487 specific Query, listing all groups in the Non-Authoritative Leave 488 message. The Response Interval should be set to [Fast Response 489 Interval]. Until a response is heard for each listed group, the 490 Query should be retransmitted once every [Fast Response Interval] 491 for a total of [Robustness Variable] transmissions. The Querier 492 MUST wait an additional [Round Trip Delay] after the final [Fast 493 Response Interval] for reports before assuming that there are no 494 members present in the domain. 496 6.4. Reception of Group-Specific Queries 498 Upon reception of a Group-Specific Query, non-Querier routers MUST 499 set a group membership timeout timer to [Querier's Robustness 500 Variable] * [Querier's Response Interval] + [Round Trip Delay]. If 501 this timeout occurs without receiving a Report for the listed 502 groups, the group membership record is removed. The Querier's 503 Query Interval and Querier's Response Interval are the values 504 carried in the Query packet. 506 6.5. Reception of Reports 508 Upon reception of a Domain-Wide Report message, all border routers 509 set a group membership timer for each group mentioned in the 510 Report. This timer's value is set to [Querier's Query Interval] * 511 [Querier's Robustness Variable] + [Querier's Response Interval] * 512 2. The Querier's Query Interval, Querier's Response Interval and 513 Querier's Robustness Variable are remembered from the last General 514 Query received from the Querier. This timer is refreshed by 515 reception of further messages. 517 6.6. Request Unicast Replies 519 If a Border Router wishes to reduce the amount of DWR multicast 520 traffic in a domain, it may add the "Reply via Unicast" option to 521 its DWQ's. This has the advantage of reducing the amount of state 522 kept inside the domain for forwarding packets destined to the DWR- 523 reply multicast group, at the cost of eliminating suppression. The 524 border router must multicast DWR's summarizing the replies it got 525 via unicast to the DWR-reply multicast group at the end of the 526 response interval, in order to share membership information with 527 all routers. This summary MUST contain a global padding option 528 with its S bit set to 1, to prevent suppression of real reports. 530 7. Use of IPSEC 532 The use of IPSEC AH is recommended on Domain-Wide Query packets for 533 two reasons: 535 1. Prevention of forgery of Queries which can foil Querier election. 536 This use requires all border routers to use IPSEC. 538 2. In order to allow the use of the Unicast Replies option. This use 539 requires all border and interior routers to use IPSEC. 541 In either configuration, security associations are configured as 542 described in section 4.7 of [RFC2401]. Briefly, a single Security 543 Association is manually configured in all required devices with a 544 static key. The number of devices (e.g. domain border routers) 545 should be small enough for this to not be an undue burden. When a 546 secure multicast key distribution protocol exists in the IPSEC 547 framework, this protocol may be used instead of manual 548 configuration. 550 8. List of timers and tunable values 552 8.1. Robustness Variable 554 The Robustness Variable allows tuning for the expected packet loss 555 in a domain. If transmission inside a domain is expected to be 556 lossy, the Robustness Variable may be increased, at the cost of 557 increased latency in determining failures. The DWR protocol is 558 robust to ([Robustness Variable] - 1) packet losses. The 559 Robustness Variable MUST NOT be zero, and SHOULD NOT be one. 560 Default value: 2 562 8.2. Query Interval 564 The Query Interval is the interval between General Queries sent by 565 the domain-wide Querier. Default value: 5 minutes 567 8.3. Normal Response Interval 569 The Normal Response Interval is the Response Time inserted into the 570 periodic General Queries. Default: 60 seconds 572 By varying the [Normal Response Interval], an administrator may 573 tune the burstiness of DWR messages in the domain; larger values 574 make the traffic less bursty, as host responses are spread out over 575 a larger interval. The number of seconds represented by the 576 [Normal Response Interval] must be less than the [Query Interval]. 578 8.4. Fast Response Interval 580 The Fast Response Interval is the Response Time inserted into 581 Group-Specific Queries in response to Non-Authoritative Leave 582 messages, and is also the time between the Group-Specific Query 583 messages. Default: 1 second 585 This value may be tuned to modify the "leave latency" of the 586 domain. A reduced value results in reduced time to detect the loss 587 of the last member of a group. 589 8.5. Round Trip Delay 591 The Round Trip Delay is the worst-case round trip time through the 592 domain. This is used to ensure that group membership is not lost 593 due to a small Fast Response Interval and a large round trip delay 594 through the domain. This value must be manually configured. 595 Default: 100ms. 597 IGMPv2 ignores end-to-end message delay, assuming that this delay 598 is negligible. Although the DWR protocol is very similar to 599 IGMPv2, the reality is that end-to-end round trip delays can be 600 very different on LANs vs. in a routing domain. On a LAN, the 601 round trip delay is generally dwarfed by the IGMPv2 response 602 interval. Within a domain, the opposite may be true, so it's 603 important for the protocol to acknowledge that. 605 9. Message destinations 607 This information is provided elsewhere in the document, but is 608 summarized here for convenience. 610 Message Type Destination Group 611 ------------ ----------------- 612 General Query Domain-wide Query group (224.0.255.254) 613 Group-specific Query Domain-wide Query group (224.0.255.254) 614 Report Domain-wide Report group (224.0.255.253) 615 Leave Domain-wide Report group (224.0.255.253) 616 Non-Authoritative Leave Domain-wide Report group (224.0.255.253) 618 10. Acknowledgments 620 The ideas of unicasting DWR replies and of electing a "designated 621 reporter" came from a discussion on the IDMR mailing list with 622 Jeffrey Zhang and Yunzhou Li of Bay Networks. 624 11. Security Considerations 626 11.1. Forged Packets 628 11.1.1. Forged Packets from Outside the Domain 630 Since all packets in this memo are sent to domain-scoped multicast 631 groups, a scope boundary around the domain which drops domain- 632 scoped packets from entering the domain from outside protects 633 against forged packets from outside the domain. 635 11.1.2. Forged Packets from Inside the Domain 637 We consider the effects of a forged packet of each type. 639 11.1.2.1. Forged Query 641 A forged Query will cause interior routers to send Reports for some 642 or all of their group memberships, increasing control traffic 643 within the domain but not affecting the memberships learned by the 644 border routers. 646 Border routers perform Querier Elections on Query messages. A 647 forged General Query could cause the forger to be elected Querier, 648 giving him some control over the group membership reporting in the 649 domain. For this reason, IPSEC SHOULD be used between the domain 650 border routers to ensure that Querier election only occurs between 651 known border routers. 653 11.1.2.2. Forged Report 655 A forged Report will cause interior routers to suppress their own 656 Report messages for the group being reported. However, the forged 657 message will be accepted by the border routers, so this 658 accomplishes nothing. 660 If interior routers keep state for all Reports heard, forged 661 Reports can cause increased memory consumption on interior routers. 662 However, keeping state for all Reports is optional, so interior 663 routers that are running low on memory due to the amount of DWR- 664 related state may simply release all of that state. 666 Border routers must keep state for all Reports heard, so they are 667 vulnerable to increased memory consumption. If this is a worry, 668 once again IPSEC relationships may be created between all of the 669 interior routers and the border routers. This is a much larger 670 burden on administrators, however, so is only recommended if this 671 is expected to be a problem. 673 11.1.2.3. Forged Leave 675 A forged Leave (Authoritative or Non-Authoritative) will cause 676 interior routers to forget their state (if any) regarding the 677 suppression status of a group. This may cause increased control 678 message traffic during the next Query interval. 680 A forged Non-Authoritative leave will cause the border routers to 681 issue group-specific Query messages to learn if there are remaining 682 group members. This causes increased control message traffic. 684 A forged Authoritative Leave will cause a black hole until the next 685 Query occurs; the border routers will accept the Leave and not 686 perform any Queries. Border routers SHOULD be configurable to 687 ignore all Authoritative Leaves and interior routers SHOULD be 688 configurable to only send Non-Authoritative Leaves, in order to be 689 able to prevent this attack. 691 11.2. Unicast Responses 693 Sending a DWQ requesting a unicast response can cause many DWR's to 694 be unicasted to the sender. In order to prevent the use of this 695 option as a "packet amplifier", any DWQ message using this option 696 SHOULD be authenticated using IPSEC as described in this document. 698 12. References 700 RFC2119 Bradner, S., "Key words for use in RFCs to Indicate 701 Requirement Levels", RFC 2119/BCP 14, Harvard University, 702 March 1997. 704 Estr98 Estrin, D., D. Meyer, D. Thaler, ``Border Gateway 705 Multicast Protocol (BGMP): Protocol Specification'', Work 706 In Progress, March 1998. 708 RFC2236 Fenner, W. ``Internet Group Management Protocol, Version 709 2'', RFC2236, Xerox PARC, November 1997. 711 RFC2401 Kent, S. and R. Atkinson, ``Security Architecture for the 712 Internet Protocol'', RFC 2401, November 1998. 714 Thya95 Thyagarajan, A. and S. Deering, ``Hierarchical Distance- 715 Vector Multicast Routing'', Proceedings of ACM Sigcomm, 716 September 1995. 718 13. Author's Address 720 William C. Fenner 721 AT&T Labs - Research 722 75 Willow Road 723 Menlo Park, CA 94025 724 Phone: +1 650 330 7893 725 Email: fenner@research.att.com