idnits 2.17.1 draft-ietf-mboned-sadp-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([MAAA]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 4 instances 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 copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 183 has weird spacing: '...= scope a...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (22 July 1999) is 9042 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: 'SADP-RELATIVE-GROUP' is mentioned on line 471, but not defined == Missing Reference: 'SADP-REQ-TIMEOUT' is mentioned on line 478, but not defined == Missing Reference: 'SADP-SUPPRESSION-INTERVAL' is mentioned on line 482, but not defined == Missing Reference: 'SADP-PORT' is mentioned on line 343, but not defined == Unused Reference: 'RFC1884' is defined on line 525, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-malloc-madcap-03 -- Possible downref: Non-RFC (?) normative reference: ref. 'MAAA' == Outdated reference: A later version (-06) exists of draft-ietf-mboned-mzap-02 ** Downref: Normative reference to an Historic draft: draft-ietf-mboned-mzap (ref. 'MZAP') ** Obsolete normative reference: RFC 1700 (Obsoleted by RFC 3232) ** Obsolete normative reference: RFC 1884 (Obsoleted by RFC 2373) -- Possible downref: Non-RFC (?) normative reference: ref. 'SHARQFEC' Summary: 10 errors (**), 0 flaws (~~), 12 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mboned Working Group Roger Kermode 3 Internet Engineering Task Force Motorola 4 INTERNET-DRAFT Dave Thaler 5 22 January 1999 Microsoft 6 Expires 22 July 1999 8 Scoped Address Discovery Protocol (SADP) 9 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance 14 with all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as 19 Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other 23 documents at any time. It is inappropriate to use Internet- 24 Drafts as reference material or to cite them other than as 25 "work in progress." 27 To view the list Internet-Draft Shadow Directories, see 28 http://www.ietf.org/shadow.html. 30 Abstract 32 This document defines an application-layer protocol, the Scoped 33 Address Discovery Protocol (SADP), for discovering the scoped 34 multicast address(es) associated with a session at particular scopes 35 within a hierarchically nested set of multicast scopes. SADP is 36 designed to work within the context of Multicast Address Allocation 37 Architecture [MAAA]. It is intended that SADP will provide the 38 necessary general services for reliable multicast and searching 39 applications to use expanding-scope searches in lieu of the well 40 known, but less efficient expanding-ring search. 42 Copyright Notice 44 Copyright (C) The Internet Society (1999). All Rights Reserved. 46 Contents 48 Abstract. . . . . . . . . . . . . . . . . . . . . . . . . 1 50 1. Introduction. . . . . . . . . . . . . . . . . . . . . 3 52 2. Overview. . . . . . . . . . . . . . . . . . . . . . . 4 54 3. Usage . . . . . . . . . . . . . . . . . . . . . . . . 6 55 3.1 Session Identifiers . . . . . . . . . . . . . . . . 6 56 3.2 Session Member Operation. . . . . . . . . . . . . . 6 57 3.3 SADP Server Operation . . . . . . . . . . . . . . . 7 59 4. Packet Formats. . . . . . . . . . . . . . . . . . . . 8 60 4.1 SADP Request. . . . . . . . . . . . . . . . . . . . 10 61 4.2 SADP Response . . . . . . . . . . . . . . . . . . . 10 62 4.2 SADP New Address. . . . . . . . . . . . . . . . . . 11 64 5. Constants . . . . . . . . . . . . . . . . . . . . . . 11 66 6. Security Considerations . . . . . . . . . . . . . . . 11 68 7. Acknowledgements. . . . . . . . . . . . . . . . . . . 11 70 8. References. . . . . . . . . . . . . . . . . . . . . . 11 72 9. Author's Address. . . . . . . . . . . . . . . . . . . 12 74 10. Full Copyright Statement. . . . . . . . . . . . . . . 12 76 1. Introduction 78 Administrative scoping [RFC2365] provides a useful means for limiting 79 the spread of IP multicast traffic across the Internet. Unlike Time- 80 To-Live (TTL) scoping, administrative scoping provides the means to 81 ensure that, for a given scope and ignoring packet loss, the same set 82 of nodes will receive a message, regardless of which node sent the 83 message. Thus, the use of administrative scoping greatly simplifies 84 the design of multicast protocols that require localization, since 85 the non-reception of sent packets is solely due to loss and not 86 design. 88 The Multicast Address Dynamic Client Allocation Protocol (MADCAP) 89 [MADCAP] will provide applications with the means for discovering the 90 various scopes that are locally visible at each point in the 91 Internet. The determination of which scopes nest inside each other 92 will be performed by the Multicast-Scope Zone Announcement Protocol 93 (MZAP) [MZAP]. MZAP's ability to provide this service will allow 94 scopes to be arranged into hierarchies so that applications can then 95 use expanding scope searches instead of the less efficient and more 96 problematic expanding-ring (TTL) searches. One example of how 97 expanding-scope searches provide increased localization can be found 98 in the Scoped Hybrid Automatic Repeat reQuest with Forward Error 99 Correction (SHARQFEC) reliable multicast protocol [SHARQFEC]. 101 While expanding-ring searches use one multicast address and 102 increasing TTLs, expanding-scope searches involve changing the 103 multicast addresses for each attempt at a different scope. For well- 104 known services, these addresses can be obtained by applying an IANA- 105 assigned offset from the top of the scope's address range. 106 Applications, on the other hand, generally require the use of 107 dynamically allocated addresses with offsets that will most likely 108 vary from scope to scope. 110 SADP builds upon the Multicast Address Allocation Architecture [MAAA] 111 by adding a new application-layer service that allows applications to 112 discover the relevant multicast address(es) associated with a session 113 at each level in a hierarchy of scopes. 115 SADP does not provide the means to allocate an address should one not 116 be present for a session in a particular zone. In this case the 117 application should take steps to obtain an address for that scope and 118 then announce it to other application instances that join that scope 119 at a later time. One proposed mechanism for allocating addresses is 120 the Multicast Address Dynamic Allocation Protocol (MADCAP) [MADCAP]. 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in RFC 2119 [RFC2119]. 126 2. Overview 128 Administrative scoping affords the ability to create network 129 partitions or zones in which multicast traffic addressed to one of a 130 block of addresses assigned to that zone will be limited to that 131 zone. The boundary of the zone is enforced by Zone Border Routers 132 (ZBRs) that reside at the edges of the zone. ZBRs must be carefully 133 configured so that traffic addressed within the zone does not pass 134 outside the zone. Ensuring consistency among boundary routers can be 135 a non-trivial task, and hence the Multicast Zone Announcement 136 Protocol (MZAP) [MZAP], which is used to announce the existence of 137 zones, also provides the mechanisms to detect ZBR misconfigurations. 139 . . . . . . . . . +B+------> 140 . . / 141 . * 142 . <---+A*--------+C+---> 143 . + . 144 . / . 145 . Zone X <--- . 146 . . . . . . ... 148 A, B, C - Routers * - border interface + - interface . - border 150 Figure 1: Admin scope zone border example 152 Zones may be of different sizes and can also overlap. In addition to 153 the services of zone announcement and fault detection, MZAP also 154 provides mechanisms for determining and announcing the existence of 155 zones that nest inside others as shown in Figure 2. 157 +-----------+ +-----------+ +-------------+ 158 | zone a | | zone c | | zone e | 159 | +------+| | +------+ | . . . . .|. . 160 | |zone b|| | |zone d| | : zone f | : 161 | +------+| | | | | : | : 162 +-----------+ +----+------+ +-------------+ : 163 : . . . . . : 165 (a) "Contained" (b) "Common Border" (c) "Overlap" 166 zone b nests zone d nests zones e and f 167 inside zone a inside zone c do not nest 169 Figure 2: Zone nesting examples 171 This feature allows admin scope zones to be arranged in a hierarchy 172 as shown in Figure 3. The ability to nest admin scope zones in 173 hierarchies like that shown in Figure 3 is useful since it affords 174 localization through expanding-scope searches. For example, consider 175 a distributed application with session members distributed evenly 176 through out zone a. A session member in scope e, would perform a 177 search by multicasting a query within scope e, and if unsuccessful, 178 expand the scope to search in scope b, and eventually scope a if so 179 needed. 181 . . . . . . . . . . . . . . . . . . 182 . scope a . Scope Boundaries 183 . . . = scope a 184 . _______________ ________________ . - = scopes b,c 185 . / scope b \ / scope c \ . # = scopes d,e,f, & g 186 .| | | |. 187 .| ##### ##### | | ##### ##### |. 188 .| #scope# #scope#| | #scope# #scope# |. 189 .\ # d # # e # | | # f # # g # /. 190 .\ #### #####/ #### #### /. 191 .\____________/ _____________/. 192 . . . . . . . . . . . . . . . . . 194 Figure 3 : Admin Scope Zone Nesting Hierarchy example 196 In order for expanding-scope searches to be feasible, session members 197 must be able to determine two things: 199 o which scopes are involved in the hierarchy for a particular 200 session. 202 o what address(es) are to be used for communicating with other 203 session members within these scopes. 205 SADP affords the ability to discover this information by using a 206 single multicast group inside each scope [SADP-RELATIVE-GROUP] for 207 communication between SADP servers (see section 3.2) and the members 208 of various sessions. New members to a session use the channels 209 provided by the addresses to query existing SADP servers and session 210 members as to which specific scopes are valid and which scopes to 211 use. Since there is only one multicast address used per admin scope 212 zone for this purpose, members of a particular session will ignore 213 traffic intended for members of another session. 215 3. Usage 217 In this section we summarize how session members can use SADP to 218 determine which admin zones are used by the session's hierarchy and 219 also the address(es) within these zones that are used by the current 220 session members should such addresses exist. 222 3.1 Session Identifiers 224 Each session that uses administrative scoping will be identified by a 225 Session Identifier (SID) that corresponds to the address of the group 226 used in the largest scope zone. Applications that require multiple 227 addresses shall be decomposed into multiple individual sessions which 228 will then be treated independently. 230 3.2 Session Member Operation 232 Several predefined administrative scopes already exist [RFC2365]: 234 o Link Local: Traffic is only carried across one physical link. 236 o Local: Traffic is restricted to a specific network region. 238 o Global: The entire multicast enabled network. 240 By definition Link Local scopes nest inside Local scopes which in 241 turn nest inside the Global Scope. Other scopes may exist between the 242 local and global scopes. These scopes are constructed by the union of 243 the admin scope zones that correspond to two or more topologically 244 adjacent local scopes and are announced to routers within their 245 confines using MZAP [MZAP]. 247 The general algorithm that new members to a session should use to 248 determine which scopes and addresses are involved in the hierarchy 249 for a particular session is as follows: 251 1) Determine largest scope, and address for the largest scope for 252 the session. (this task is beyond the scope of this document, 253 but can be assumed to involve some kind of out-of-band 254 communication.) 256 2) Starting with the SADP group [SADP-RELATIVE-GROUP] for the 257 local scope, issue a SADP Request (SADP_REQ) message 258 containing the SID address. 260 3) Wait for a response on the SADP [SADP-RELATIVE-GROUP] address 261 for at least [SADP-REQ-TIMEOUT] seconds. If no response is 262 heard, wait for some small amount of time, and then 263 repeat the request at the same scope. 265 4) If after a total of 3 attempts at a given scope, no response 266 has been received, increase the scope to the next largest scope 267 and repeat steps 2 and 3. In cases where there are two 268 non-nesting scopes larger than the current, try one scope and 269 then the other, should the first scope not result in a reply. 271 5) Continue steps 2), 3), and 4) until the largest scope has been 272 queried or a response has been heard. 274 In cases where the scope must be increased in order to find a session 275 member that can reply, the new session member MAY decide to add 276 levels to the hierarchy in order to increase localization for future 277 session members. New session members that decide to take this step 278 will use the existing addresses as discovered using SADP and request 279 new ones. (e.g., via MADCAP [MADCAP]). Upon the successful 280 allocation of a new address for use in the hierarchy, the new session 281 member shall announce the new address via a SADP_NEW_ADDR message to 282 the [SADP-RELATIVE-GROUP] address for the scope in which the address 283 was allocated. This will cause the address to be cached by any SADP 284 servers within the new address's scope. 286 SADP servers and existing session members, upon hearing an SADP_REQ 287 message from a new session member from [SADP-RELATIVE-GROUP] at a 288 particular scope will issue an SADP Response (SADP_RESP) to the 289 [SADP-RELATIVE-GROUP] at the same scope after waiting for a random 290 amount of time (T) that is calculated as follows: 292 Choose a random value X from a uniform random interval [0:1] Let 293 C = 256 Set 294 T = [SADP-SUPPRESSION-INTERVAL] log( C*X + 1) / log(C) 296 Should a member receive a SADP_RESP before its timer it expires it 297 SHALL suppress its own response. This method ensures that close to 298 one session member will respond. 300 3.3 SADP Server Operation 302 Were SADP to be deployed in a wide scale session with the members of 303 various sessions to use SADP between each other it would quickly 304 cause catastrophic congestion. The reason for this is that whenever a 305 new node joined a sparsely populated session with a large maximum 306 scope, it would inevitably end up sending SADP_REQs to every scope up 307 until the largest scope. Thus the highly likely occurrence of having 308 a global and continental scopes combined with numerous sparse 309 sessions (probably on the order of 10,000 to 100,000) would quickly 310 cause SADP_REQ flooding at the continental scope. 312 To address this shortcoming SADP allows, and in fact encourages, the 313 deployment of SADP servers. These servers subscribe to the [SADP- 314 RELATIVE-GROUP] for each scope they are in and cache the SADP_RESP 315 messages they receive at each scope. Having cached and merged the 316 responses for sessions at various scopes, they can then respond to 317 SADP_REQs heard at lower scopes using the information heard at the 318 larger scope(s). Should a SADP server hear a SADP_REQ at some 319 intermediate scope it MUST NOT announce address information for 320 scopes smaller than one on which the SADP_REQ was received. 322 The effect of allowing larger-scoped information to be announced at 323 lower scopes by SADP servers significantly reduces the number of 324 scopes a new session will have to query. New session members now need 325 only expand the scope until a SADP server is found. This is a marked 326 improvement over the case where no SADP servers exist and the search 327 must continue until an existing session member is found. 329 Scope b Boundary 330 Scope a : Scope a and Scope b 331 _________ : ____________ _____________ 332 / \ : / \ / \ 333 |Source at| _____:___\ |SADP Server | /___________ | New Session | 334 |Scope a | SADP_RESP/ | Scopes a,b | \ SADP_REQ | Member | 335 \_________/ : \____________/ ___________\ | Scopes a,b | 336 : SADP_RESP/ \_____________/ 337 : 338 Figure 4 : SADP Server acting as proxy session member 340 4. Packet Formats 342 All SADP messages are sent over UDP, with a destination port of 343 [SADP-PORT]. The common SADP message header (which follows the UDP 344 header), is shown below, 346 0 1 2 3 347 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 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | Version | PTYPE | Num Scopes | Addr Family | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | Largest Scope Group Address | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 Authentication Block 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 Version: 8 bits 356 The version defined in this document is version 0. 358 Packet Type (PTYPE): 8 bits 359 The packet types defined in this document are: 360 0: SADP Request 361 1: SADP Response 362 2: SADP New Address 364 Number of Scope Entries (Num Scopes) : 4 bits 365 The number of scope entries present within a SADP_RESP 366 message. This field should be set to zero for SADP_REQ messages. 368 Address Family (AddrFam): 4 bits 369 This indicates the IANA-assigned address family number to be 370 used for address contained in this message. Currently assigned 371 values are listed in RFC 1700 [RFC1700]. The values for IP 372 addresses are: 373 IPv4: 1 374 IPv6: 2 376 Session ID Address: 32 bits (IPv4) or 128 bits (IPv6) 377 The group address corresponding to the largest scope for this 378 hierarchy of addresses. 380 Authentication Block: 381 The Authentication Block provides information which can be used 382 to confirm that the sender of the SADP message is a valid member 383 of the session. Session Members that cannot confirm that the 384 sender of an SADP Request Message MAY ignore it, while new 385 session members that receive an SADP Response Message MUST 386 ignore it. (The format of the authentication block is to be 387 decided) 389 4.1 SADP Request 391 SADP Request (SADP_REQ) Messages have PTYPE=0, and are sent by new 392 session members that wish to learn which administrative scopes and 393 multicast addresses to use within a particular session. SADP_REQ 394 Messages are sent according to the algorithm described in 3.2. 396 4.2 SADP Response 398 The SADP Response (SADP_RESP) Message has PTYPE=1, and is sent in 399 response to a SADP_REQ Message to the same scope from which the 400 SADP_REQ was received. It contains the address that is to be used by 401 an application instance within a session for each scope that nests 402 within the scope to which the SADP_REQ was sent. (N.B. This includes 403 the scope to which the SADP_REQ was sent) Session members that 404 transmit SADP Response Messages MUST NOT include scope and address 405 information for scopes that are known to overlap or be larger than 406 that of the scope upon which the triggering SADP_REQ Message was 408 The format for a SADP Response Message is shown below: 410 0 1 2 3 411 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 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 SADP Header 414 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 415 | Scope Start Address 1 | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | Scope 1 Session Address | 418 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 419 . . . . . . . 420 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 421 | Scope Start Address N | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | Scope N Session Address | 424 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 426 Scope X Start Address : 32 bits (IPv4) or 128 bits (IPv6) 427 The smallest address for the block of multicast addresses 428 associated with a scope. If a scope X is valid for the range 429 239.128.0.0 to 239.128.255.255, this field will be set to 430 239.128.0.0. 432 Scope X Session Address : 32 bits (IPv4) or 128 bits (IPv6) 433 Address to be used for the named scope. 435 4.2 SADP New Address 437 The SADP New Address (SADP_NEW_ADDR) Message has PTYPE=2. It is 438 transmitted by session members that have attempted to find an address 439 for a particular scope, failed, and have then subsequently allocated 440 a new address for use in the session at that scope. Its purpose is 441 to inform other members of the session of the existence of this newly 442 allocated address and its availability for subsequent use. 444 Should two members attempt to announce a new address to the same 445 scope at the same time, their SADP_NEW_ADDR messages will result in a 446 collision. SADP_NEW_ADDR collisions are resolved by the session 447 members picking the lower of the two addresses. 449 0 1 2 3 450 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 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 SADP Header 453 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 454 | Scope Start Address | 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | New Scope Session Address | 457 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 459 Scope Start Address : 32 bits (IPv4) or 128 bits (IPv6) 460 The smallest address for the block of multicast addresses 461 associated with a scope. If a scope X is valid for the range 462 239.128.0.0 to 239.128.255.255, this field will be set to 463 239.128.0.0. 465 New Scope Session Address : 32 bits (IPv4) or 128 bits (IPv6) 466 Address of the newly allocated group to be used for the 467 specified scope. 469 5. Constants 471 [SADP-RELATIVE-GROUP]: The relative group with each scope, to which 472 session members send SADP Requests and Responses. All application 473 instances that use SADP for constructing hierarchies of scopes MUST 474 subscribe to this address for each scope which nests within the 475 session scope, in order to ensure that each application instance uses 476 the hierarchy in the most efficient manner. 478 [SADP-REQ-TIMEOUT]: The time after which a session member that sends 479 SADP Request should wait before concluding that no session members 480 are present at the current scope. Default value is 3 seconds. 482 [SADP-SUPPRESSION-INTERVAL]: The interval over which a session member 483 chooses a random delay before responding to SADP Request. Default 484 value 2 seconds. 486 6. Security Considerations 488 SADP employs distributed mechanisms to allow new session members to 489 learn of the existence of session-specific admin scoped multicast 490 address. This fact lays SADP open to attack by malicious hosts that 491 could potentially mis-inform new session members of incorrect 492 addresses, thereby affecting a man-in-the-middle attack. 494 To prevent attacks of this nature by non-session members from 495 occurring all SADP messages are signed by the sender. However, this 496 measure does not prevent malicious hosts from joining a session and 497 then performing the same attack. Hence, SADP's security depends upon 498 a suitable gating process for new-member admittance combined with (as 499 yet to be determined) mechanisms that allow spoofed SADP messages to 500 be identified for removal before processing. 502 7. Acknowledgments 504 The Authors would like to acknowledge Mark Handley for the helpful 505 discussions and feedback which helped shape and refine this document. 507 8. References 509 [MADCAP] Patel. B.V., Shah, M., Hanna, S.R., "Multicast Address 510 Dynamic Client Allocation Protocol (MADCAP)", Internet 511 Draft, draft-ietf-malloc-madcap-03.txt, February 1999. 513 [MAAA] Handley, M., Thaler, D., and D. Estrin, "The Internet 514 Multicast Address Allocation Architecture", Internet 515 Draft, December 1997. 517 [MZAP] Handley, M., Thaler, D., "Multicast-Scope Zone 518 Announcement Protocol (MZAP)", 519 draft-ietf-mboned-mzap-02.txt, Internet-Draft, August, 520 1998. 522 [RFC1700] Reynolds, J., Postel, J., "Assigned Numbers", RFC 1700, 523 October 1994. 525 [RFC1884] Hinden, R., Deering, S., "IP Version 6 Addressing 526 Architecture", RFC 1884, December 1995. 528 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 529 Requirement Levels", BCP, RFC 2119, March 1997. 531 [RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP, 532 RFC 2365, July 1998. 534 [SHARQFEC] Kermode, R., "Scoped Hybrid Automatic Repeat reQuest with 535 Forward Error Correction (SHARQFEC)", ACM SIGCOMM98, 536 Vancouver Canada, September 1998. 538 9. Authors' Addresses 540 Roger Kermode 541 Motorola Australia Research Centre 542 12 Lord St. 543 Botany, NSW 2091 544 Australia 545 Email: Roger_Kermode@email.mot.com 547 David Thaler 548 Microsoft 549 One Microsoft Way 550 Redmond, WA 98052 551 USA 552 Email: dthaler@microsoft.com 554 10. Full Copyright Statement 556 Copyright (C) The Internet Society (1999). All Rights Reserved. 558 This document and translations of it may be copied and furnished to 559 others, and derivative works that comment on or otherwise explain it 560 or assist in its implementation may be prepared, copied, published 561 and distributed, in whole or in part, without restriction of any 562 kind, provided that the above copyright notice and this paragraph are 563 included on all such copies and derivative works. However, this 564 document itself may not be modified in any way, such as by removing 565 the copyright notice or references to the Internet Society or other 566 Internet organizations, except as needed for the purpose of 567 developing Internet standards in which case the procedures for 568 copyrights defined in the Internet languages other than English. 570 The limited permissions granted above are perpetual and will not be 571 revoked by the Internet Society or its successors or assigns. 573 This document and the information contained herein is provided on an 574 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 575 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 576 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 577 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 578 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."