idnits 2.17.1 draft-ietf-mboned-sadp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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 Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** 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. ** There are 4 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** The abstract seems to contain references ([MAAA], [MASC], [MZAP], [AAP]), 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 168 has weird spacing: '... = zone 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 (8 May 1999) is 9113 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: 'MASC' is mentioned on line 30, but not defined == Missing Reference: 'SADP-RELATIVE-GROUP' is mentioned on line 475, but not defined == Missing Reference: 'SADP-REQ-TIMEOUT' is mentioned on line 480, but not defined == Missing Reference: 'SADP-SUPPRESSION-INTERVAL' is mentioned on line 484, but not defined == Missing Reference: 'SADP-PORT' is mentioned on line 319, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'AAP' -- 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 1884 (Obsoleted by RFC 2373) ** Obsolete normative reference: RFC 2279 (Obsoleted by RFC 3629) -- Possible downref: Non-RFC (?) normative reference: ref. 'SHARQFEC' -- Possible downref: Normative reference to a draft: ref. 'UUID' Summary: 13 errors (**), 0 flaws (~~), 11 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Malloc Working Group Roger Kermode 3 Internet Engineering Task Force Motorola 4 INTERNET-DRAFT 5 8 November 1998 6 Expires 8 May 1999 8 Scoped Address Discovery Protocol (SADP) 9 11 Status of this Memo 13 This document is an Internet Draft. Internet Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its Areas, 15 and its Working Groups. Note that other groups may also distribute 16 working documents as Internet Drafts. 18 Internet Drafts are valid for a maximum of six months and may be 19 updated, replaced, or obsoleted by other documents at any time. It 20 is inappropriate to use Internet Drafts as reference material or to 21 cite them other than as a "work in progress". 23 Abstract 25 This document defines a protocol, the Scoped Address Discovery 26 Protocol (SADP), for discovering the scoped multicast address(es) 27 associated with a session at particular scopes within a 28 hierarchically nested set of multicast zones. SADP is designed to 29 work within the context of Multicast Address Allocation Architecture 30 [MAAA] consisting of the MZAP [MZAP], MASC [MASC], and AAP [AAP] 31 protocols. It is intended that SADP will provide the necessary 32 general services for reliable multicast and searching applications to 33 use expanding-zone searches in lieu of the well known, but less 34 efficient expanding-ring search. 36 Copyright Notice 38 Copyright (C) The Internet Society (1998). All Rights Reserved. 40 Contents 42 Abstract. . . . . . . . . . . . . . . . . . . . . . . . . 1 44 1. Introduction. . . . . . . . . . . . . . . . . . . . . 3 46 2. Overview. . . . . . . . . . . . . . . . . . . . . . . 4 48 3. Usage . . . . . . . . . . . . . . . . . . . . . . . . 5 49 3.1 Session Identifiers . . . . . . . . . . . . . . . . 6 50 3.2 Session Member Operation. . . . . . . . . . . . . . 6 51 3.3 SADP Server Operation . . . . . . . . . . . . . . . 7 53 4. Packet Formats. . . . . . . . . . . . . . . . . . . . 8 54 4.1 SADP Request. . . . . . . . . . . . . . . . . . . . 10 55 4.2 SADP Response . . . . . . . . . . . . . . . . . . . 10 57 5. Constants . . . . . . . . . . . . . . . . . . . . . . 11 59 6. Security Considerations . . . . . . . . . . . . . . . 12 61 7. Acknowledgements. . . . . . . . . . . . . . . . . . . 12 63 8. References. . . . . . . . . . . . . . . . . . . . . . 12 65 9. Author's Address. . . . . . . . . . . . . . . . . . . 13 67 10. Full Copyright Statement. . . . . . . . . . . . . . . 13 69 1. Introduction 71 Administrative scoping [RFC2365] provide a useful means for limiting 72 the spread of IP multicast traffic acros the Internet. Unlike Time- 73 To-Live (TTL) scoping, administrative scoping provides the means to 74 ensure that, for a given scope and ignoring packet loss, the same set 75 of nodes will receive a message, regardless of which node sent the 76 message. Thus, the use of administrative scoping greatly simplifies 77 the design of multicast protocols that require localization, since 78 the non-reception of sent packets is solely due to loss and not 79 design. 81 The Multicast Zone Announcement Protocol (MZAP) [MZAP] will provide 82 applications with the means for discovering the various scopes that 83 are locally visible at each point in the Internet. In addition, MZAP 84 will also provide the means for determining and announcing which 85 scope zones completely encapsulate others. This additional ability 86 will allow scope zones to be arranged into hierarchies which 87 applications can then used expanding zone searches instead of less 88 efficient and more problematic expanding-ring (TTL) searches. One 89 example of how expanding-zone searches provide increased localization 90 can be found in the Scoped Hybrid Automatic Repear reQuest with 91 Forward Error Correction (SHARQFEC) reliable multicast protocol 92 [SHARQFEC]. 94 While expanding-ring searches use one multicast address and 95 increasing TTLs, expanding-zone searches involve changing the 96 multicast addresses for each attempt at a different scope. SADP 97 builds upon the Multicast Address Allocation Architecture [MAAA] by 98 adding a new service that allows applications to discover the 99 relevant multicast address(es) associated with a session at each 100 level in a hierarchy of scope zones. SADP does not provide the means 101 to allocate an address should one not be present for a session in a 102 particular zone. In this case the application should use the Address 103 Allocation Protocol (AAP) [AAP] to allocate a new address for the 104 scope, which can then be announced to other application instances 105 within the scope. 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in RFC 2119 [RFC2119]. 111 2. Overview 113 Administrative scoping affords the ability to create network 114 partitions or zones in which multicast traffic addressed to one of a 115 block of addresses assigned to that zone will be limited to that 116 zone. The boundary of the zone is enforced by Zone Border Routers 117 (ZBRs) that reside at the edges of the zone. ZBRs must be carefully 118 configured so that traffic addressed within the zone does not pass 119 outside the zone. This can be a non trivial task, and hence the 120 Multicast Zone Announcement Protocol (MZAP) [MZAP], which is used to 121 announce the existence of zones, also provides the mechanisms to 122 detect ZBR misconfigurations. 124 . . . . . . . . . +B+------> 125 . . / 126 . * 127 . <---+A*--------+C+---> 128 . + . 129 . / . 130 . Zone X <--- . 131 . . . . . . ... 133 A, B, C - Routers * - border interface + - interface . - border 135 Figure 1: Admin scope zone border example 137 Zones may be of different sizes and can also overlap. In addition to 138 the services of zone announcement and fault detection, MZAP also 139 provides mechanisms for determining and announcing the existence of 140 zones that nest inside others as shown in Figure 2. 142 +-----------+ +-----------+ +-------------+ 143 | zone a | | zone c | | zone e | 144 | +------+| | +------+ | . . . . .|.. 145 | |zone b|| | |zone d| | : zone f | : 146 | +------+| | | | | : | : 147 +-----------+ +----+------+ +-------------+ : 148 :. . . . ..: 150 (a) "Contained" (b) "Common Border" (c) "Overlap" 151 zone b nests zone d nests zones e and f 152 inside zone a inside zone c do not nest 154 Figure 2: Zone nesting examples 156 This feature allows admin scope zones to be arranged in a hierarchy 157 as shown in Figure 3. The ability to nest admin scope zones in 158 hierarchies like that shown in Figure 3 is useful since it affords 159 localization through expanding-zone searches. For example, consider a 160 distributed application with session members distributed evenly 161 through out zone a. A session member in zone e, would perform a 162 search by multicasting a query within zone e, and if unsuccessful, 163 expand the scope to search in zone b, and eventually zone a if so 164 needed. 166 . . . . . . . . . . . . . . . . .. 167 . zone a . Zone Boundaries 168 . . . = zone a 169 . ______________ ______________ . - = zones b,c 170 . / zone b \ / zone c \ . # = zones d,e,f, & g 171 .| | | |. 172 .| #### #### | | #### #### |. 173 .| #zone# #zone# | | #zone# #zone# |. 174 .\ # d # # e # | | # f # # g # /. 175 .\ ### #### / \ #### #### /. 176 .\___________/ \____________/. 177 . . . . . . . . . . . . . . . . .. 179 Figure 3 : Zone Nesting Hierarchy example 181 In order for expanding-zone searches to be feasible, session members 182 must be able to determine two things: 184 o which zones are involved in the hierarchy for a particular session. 186 o what address(es) are to be used for communicating with other 187 session members within the zones involved in the hierarchy. 189 SADP affords the ability to discover this information by using a 190 single multicast group at each scope [SADP-RELATIVE-GROUP] for 191 communication between SADP servers and the members of various 192 sessions. New members to a session use the channels provided by the 193 addresses to query existing SADP servers and session members as to 194 which specific zones are valid and which zones to use. Since there is 195 only one multicast address used per zone for this purpose, members of 196 a particular session will ignore traffic intended for members of 197 another session. 199 3. Usage 201 In this section we summarize how session members can use SADP to 202 determine which admin zones are used by the session's hierarchy and 203 also the address(es) within these zones that are used by the current 204 session members should such addresses exist. 206 3.1 Session Identifiers 208 Each session that uses admin scoping will use a Globally Unique 209 Session Identifier (GUSID) that will distinguish it from all other 210 sessions. This GUSID will consists of a 128bit integer that is 211 allocated dynamically using the process described in [UUID]. The 212 GUSID will be allocated by the session creator and will be used to 213 associate traffic with a particular session regardless of which 214 multicast scoped address the traffic is sent to. 216 3.2 Session Member Operation 218 Several predefined administrative scopes already exist [RFC2365]: 220 o Link Local: Traffic is only carried across one physical link. 222 o Local: Traffic is restricted to a specific network region. 224 o Global: The entire multicast enabled network. 226 By definition Link Local zones nest inside Local zone which in turn 227 nests inside the Global zone. Other zones may exist between the local 228 and global scopes. These zones are constructed by the union of two or 229 more local zones and are announced to routers within their confines 230 using MZAP [MZAP]. 232 The general algorithm that new members to a session should use to 233 determine which zones and addresses are involved in the hierarchy for 234 a particular session is as follows: 236 1) Determine the GUSID, largest zone, and addresses for the largest 237 zone for the session. (this task is beyond the scope of this 238 document, but can be assumed to involve some kind of out-of-band 239 communication.) 241 2) Starting with the SADP group [SADP-RELATIVE-GROUP] for the 242 local scope, issue a SADP Request (SADP_REQ) message 243 containing the GUSID address. 245 3) Wait for a response on the SADP [SADP-RELATIVE-GROUP] address 246 for at least [SADP-REQ-TIMEOUT] seconds. If no response is 247 heard increase the scope to the next largest zone and repeat step 248 2. In cases where there are two non-nesting zones larger than the 249 current try one zone and then the other, should the first zone not 250 result in a reply. 252 4) Continue steps 2) and 3) until the largest zone has been queried 253 or a response has been heard. 255 In cases where the scope must be increased in order to find a session 256 member that can reply, the new session member MAY decide to add 257 levels to the hierarchy in order to increase localization for future 258 session members. New session members that decide to take this step 259 will use the existing addresses as discovered using SADP and request 260 new ones using AAP [AAP]. 262 SADP servers and existing session members, upon hearing an SADP_REQ 263 message from a new session member will issue an SADP Response 264 (SADP_RESP) after waiting for a random amount of time (T) that is 265 calculated as follows: 267 Choose a random value X from a uniform random interval [0:1] 268 Let C = 256 269 Set T = [SADP-SUPPRESSION-INTERVAL] log( C*X + 1) / log(C) 271 Should a member receive a SADP_RESP before its timer it expires it 272 SHALL suppress its own response. This method ensures that close to 273 one session member will respond. 275 3.2 SADP Server Operation 277 Were SADP to be deployed in a wide scale session with the members of 278 various sessions to use SADP between each other it would quickly 279 cause catastrophic congestion. The reason for this is that whenever a 280 new node joined a sparsely populated session with a large maximum 281 scope, it would inevitably end up sending SADP_REQs to every scope up 282 until the largest scope. Thus the highly likely occurrence of having 283 a global and continental scope zones combined with numerous sparse 284 sessions (probably on the order of 10,000 to 100,000) would quickly 285 cause SADP_REQ flooding at the continental scope. 287 To address this shortcoming SADP allows, and in fact encourages, the 288 deployment of SADP servers. These servers subscribe to the [SADP- 289 RELATIVE-GROUP] for each zone they are in and cache the SADP_RESP 290 messages they receive at each scope. Having cached and merged the 291 responses for sessions at various scopes, they can then respond to 292 SADP_REQs heard at lower scopes using the information heard at the 293 larger scope(s). Should a SADP server hear a SADP_REQ at some 294 intermediate scope it MUST NOT announce address information for 295 scopes smaller than one on which the SADP_REQ was received. 297 The effect of allowing larger-scoped information to be announced at 298 lower scopes by SADP servers significantly reduces the number of 299 scopes a new session will have to query. New session members now need 300 only expand the scope until a SADP server is found. This is a marked 301 improvement over the case where no SADP servers exist and the search 302 must continue until an existing session member is found. 304 Scope b Boundary 305 Scope a : Scope a and Scope b 306 _________ : ____________ _____________ 307 / \ : / \ / \ 308 |Source at| _____:___\ |SADP Server | /___________ | New Session | 309 |Scope a | SADP_RESP/ | Scopes a,b | \ SADP_REQ | Member | 310 \_________/ : \____________/ ___________\ | Scopes a,b | 311 : SADP_RESP/ \_____________/ 312 : 314 Figure 4 : SADP Server acting as proxy session member 316 4. Packet Formats 318 All SADP messages are sent over UDP, with a destination port of 319 [SADP-PORT]. THe common SADP message header (which follows the UDP 320 header), is shown below, 322 0 1 2 3 323 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 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | Version | PTYPE |NumScop|AddrFam| NameLen | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | Message Origin | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | Session ID (Hi) | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | Session ID (Mid Hi) | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | Session ID (Mid Lo) | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | Session ID (Lo) | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | Session Name | 338 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | | Padding (if needed) | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 Authentication Block 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 Version: 8 bits 345 The version defined in this document is version 0. 347 Packet Type (PTYPE): 8 bits 348 The packet types defined in this document are: 349 0: SADP Request 350 1: SADP Response 352 Number of Scope Entries (NumScop) : 4 bits 353 The number of scope entries present within a SADP_RESP message. 354 This field should be set to zero for SADP_REQ messages. 356 Address Family (AddrFam): 4 bits 357 This indicates the format of the following packet. The following 358 values are defined by this document: 359 0: IPv4 360 1: IPv6 362 Message Origin: 32 bits (IPv4) or 128 bits (IPv6) 363 This gives the IP address of the interface that originated the 364 message. 366 Session ID Address: 128 bits 367 This 128 bit number uniquely identifies a session. 369 Name Len: 370 The length, in bytes, of the Session Name field. 372 Session Name: multiple of 8 bits 373 The Zone Name is an ISO 10646 character string in UTF-8 encoding 374 [RFC2279] indicating the name given to the session (e.g.: 375 ``42ndIETF-Chicago''). It should be relatively short and MUST be 376 less than 256 bytes in length. All the session members SHOULD be 377 configured to give the same Session Name, or a zero length string 378 MAY be given. A zero length string is taken to mean that another 379 session member is expected to be configured with the session 380 name. Having ALL the members of a session announce zero length 381 names should be considered an error. 383 Padding (if needed): 384 The SADP header is padded with null bytes until it is 4-byte 385 aligned. 387 Authentication Block: 388 The Authentication Block provides information which can be used 389 to confirm that the sender of the SADP message is a valid member 390 of the session. Session Members that cannot confirm that the 391 sender of an SADP Request Message MAY ignore it, while new 392 session members that receiver an SADP Response Message MUST 393 ignore it. (the format of the authentication block is to be 394 decided) 396 4.1 SADP Request 398 SADP Request (SADP_REQ) Messages have PTYPE=0, and are sent by new 399 session members that wish to learn which administrative scopes and 400 multicast addresses to use within a particular session. SADP_REQ 401 Messages are sent according to the algorithm described in 3.2. 403 4.2 SADP Response 405 The SADP Response (SADP_RESP) Message has PTYPE=1, and is sent in 406 response to a SADP_REQ Message. It contains the list of address that 407 are to be used by a session within each scope. Session members that 408 transmit SADP Response Messages MUST NOT include zone and address 409 information for scopes known to be smaller that of the address upon 410 which the triggering SADP Request Message was received. 412 The format for a SADP Response Message is shown below: 414 0 1 2 3 415 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 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 MSADP Header 418 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 419 | MBZ | SCOP | NumSessAddr | MBZ | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | Zone Start Address 1 | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | Zone Stop Address 1 | 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | Zone 1 Session Address 1 | 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 . . . . . . . 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 | Zone 1 Session Address K | 430 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 431 | MBZ | SCOP | NumSessAddr | MBZ | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 | Zone Start Address N | 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 | Zone Stop Address N | 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 | Zone N Session Address 1 | 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 . . . . . . . 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | Zone N Session Address L | 442 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 443 SCOP : 4 bits 444 The SCOP value associated with the zone as defined in RFC 1884 445 [RFC1884] for IPv6 and RFC 2365 [RFC2365] for IPv4. 447 NumSessAddr : 8 bits 448 The number of session address per scope zone that are included. 449 Addresses will be listed in ascending order. The correspondence 450 between address and channel function is the responsibility of 451 the session application. 453 MBZ : 454 Must Be Zero, these bits must be set to zero, but may be used 455 for other functions later revision of the protocol. 457 Zone X Start Address : 32 bits (IPv4) or 128 bits (IPv6) 458 The smallest address for the block of multicast addresses 459 associated with a zone. If a zone X is valid for the range 460 239.128.0.0 to 239.128.255.255, this field will be set to 461 239.128.0.0. 463 Zone X Stop Address : 32 bits (IPv4) or 128 bits (IPv6) 464 The largest address for the block of multicast addresses 465 associated with a zone. If a zone X is valid for the range 466 239.128.0.0 to 239.128.255.255, this field will be set to 467 239.128.255.255. 469 Zone X Session Address Y : 32 bits (IPv4) or 128 bits (IPv6) 470 Up to Y address may be included for a zone address entry, where 471 Y is equal to the NumSessAddr value for entry X. 473 5. Constants 475 [SADP-RELATIVE-GROUP]: The relative group with each scope zone, to 476 which session members send SADP Requests and Responses. All sessions 477 that use administratively scoped multicast MUST subscribe to this 478 address. 480 [SADP-REQ-TIMEOUT]: The time after which a session member that sends 481 SADP Request should wait before concluding that no session members 482 are present at the current scope. Default value is 3 seconds. 484 [SADP-SUPPRESSION-INTERVAL]: The interval over which a session member 485 chooses a random delay before responding to SADP Request. Default 486 value 2 seconds. 488 6. Security Considerations 490 SADP employs distributed mechanisms to allow new session members to 491 learn of the existence of session-specific admin scoped multicast 492 address. This fact lay SADP open to attack by malicious hosts that 493 could potentially mis-inform new session members of incorrect 494 addresses, thereby affecting a man-in-the-middle attack. 496 To prevent attacks of this nature by non-session members from 497 occurring all SADP messages are signed by the sender. However, this 498 measure does not prevent malicious hosts from joining a session and 499 then performing the same attack. Hence, SADP's security depends upon 500 a suitable gating process for new-member admittance combined with (as 501 yet to be determined) mechanisms that allow spoofed SADP messages to 502 be identified for removal before processing. 504 7. Acknowledgments 506 The Author would like to acknowledge Mark Handley and Dave Thaler for 507 the helpful discussions and feedback which helped shape and refine 508 this document. 510 8. References 512 [AAP] Handley, M., "The Address Allocation Protocol", Internet 513 Draft, August 1998. 515 [MAAA] Handley, M., Thaler, D., and D. Estrin, "The Internet 516 Multicast Address Allocation Architecture", Internet 517 Draft, December 1997. 519 [MZAP] Handley, M., Thaler, D., "Multicast-Scope Zone 520 Announcement Protocol (MZAP)", 521 draft-ietf-mboned-mzap-02.txt, Internet-Draft, August, 522 1998. 524 [RFC1884] Hinden, R., Deering, S., "IP Version 6 Addressing 525 Architecture", RFC 1884, December 1995. 527 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 528 Requirement Levels", BCP, RFC 2119, March 1997. 530 [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 531 10646", RFC 2279, January 1998. 533 [RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP, 534 RFC 2365, July 1998. 536 [SHARQFEC] Kermode, R., "Scoped Hybrid Automatic Repeat reQuest with 537 Forward Error Correction (SHARQFEC)", ACM SIGCOMM98, 538 Vancouver Canada, September 1998. 540 [UUID] Leach, J., Salz, R., "UUIDs and GUIDs", 541 draft-leach-uuids-guids-01.txt, Internet-Draft, February, 542 1998. 544 9. Author's Address 546 Roger Kermode 547 Motorola 548 Chicago Corporate Research Laboratories 549 1301 East Algonquiin Rd, MS IL02-2712 550 Schaumburg, IL 60196 552 Phone: (847) 538 4587 553 Email: ark008@email.mot.com 555 10. Full Copyright Statement 557 Copyright (C) The Internet Society (1998). All Rights Reserved. 559 This document and translations of it may be copied and furnished to 560 others, and derivative works that comment on or otherwise explain it or 561 assist in its implementation may be prepared, copied, published and 562 distributed, in whole or in part, without restriction of any kind, 563 provided that the above copyright notice and this paragraph are 564 included on all such copies and derivative works. However, this 565 document itself may not be modified in any way, such as by removing 566 the copyright notice or references to the Internet Society or other 567 Internet organizations, except as needed for the purpose of developing 568 Internet standards in which case the procedures for copyrights defined 569 in the Internet languages other than English. 571 The limited permissions granted above are perpetual and will not be 572 revoked by the Internet Society or its successors or assigns. 574 This document and the information contained herein is provided on an 575 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 576 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 577 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 578 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 579 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."