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