idnits 2.17.1 draft-ietf-zeroconf-zmaap-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 issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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: 'TBD' is mentioned on line 270, but not defined == Missing Reference: 'ANNOUNCE-WAIT' is mentioned on line 415, but not defined == Missing Reference: 'RESEND-WAIT' is mentioned on line 416, but not defined == Missing Reference: 'RESTART-WAIT' is mentioned on line 426, but not defined == Missing Reference: 'DEFEND-WAIT' is mentioned on line 449, but not defined == Unused Reference: 'MDNS' is defined on line 614, but no explicit reference was found in the text == Unused Reference: 'V4LL' is defined on line 660, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA' == Outdated reference: A later version (-47) exists of draft-ietf-dnsext-mdns-06 ** Downref: Normative reference to an Informational draft: draft-ietf-dnsext-mdns (ref. 'MDNS') ** Obsolete normative reference: RFC 2327 (Obsoleted by RFC 4566) ** Obsolete normative reference: RFC 2373 (Obsoleted by RFC 3513) ** Obsolete normative reference: RFC 2402 (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Downref: Normative reference to an Informational RFC: RFC 2771 ** Obsolete normative reference: RFC 2908 (Obsoleted by RFC 6308) ** Downref: Normative reference to an Experimental RFC: RFC 2974 -- Possible downref: Non-RFC (?) normative reference: ref. 'SSM' -- Unexpected draft version: The latest known version of draft-ietf-ipngwg-uni-based-mcast is -02, but you're referring to -03. == Outdated reference: A later version (-17) exists of draft-ietf-zeroconf-ipv4-linklocal-04 == Outdated reference: A later version (-12) exists of draft-ietf-zeroconf-reqts-06 ** Downref: Normative reference to an Informational draft: draft-ietf-zeroconf-reqts (ref. 'ZCREQTS') -- Possible downref: Normative reference to a draft: ref. 'ZMAAPAPI' Summary: 11 errors (**), 0 flaws (~~), 12 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETWORK Working Group Octavian Catrina, Editor 3 INTERNET-DRAFT International University 4 Category: Standards Track Dave Thaler 5 22 October 2002 Bernard Aboba 6 Expires in six months Microsoft 7 Erik Guttman 8 Sun Microsystems 10 Zeroconf Multicast Address Allocation Protocol (ZMAAP) 11 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Comments on this document should be sent to the zeroconf@merit.edu 19 mailing list. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 Copyright Notice 39 Copyright (C) The Internet Society (2001). All Rights Reserved. 41 Abstract 43 Today, with the rapid rise of home networking, there is an increasing 44 need for auto-configuration mechanisms. This document specifies a 45 protocol to be used on small networks without a multicast address 46 allocation server in order to allow peer to peer allocation of 47 multicast addresses. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 52 1.1 Changes since the last version of this document . . . . 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 54 3. Requirements and Design Considerations . . . . . . . . . . 55 4. Zeroconf Multicast Address Allocation Protocol . . . . . . 56 4.1 Protocol Overview . . . . . . . . . . . . . . . . . . . 57 4.2 Transmission of ZMAAP messages . . . . . . . . . . . . . 58 4.3 Protocol Message Format . . . . . . . . . . . . . . . . 59 4.4 ZMAAP mini-MAAS behavior . . . . . . . . . . . . . . . . 60 4.4.1 Claiming an Address . . . . . . . . . . . . . . . . . 61 4.4.2 Defending an Address . . . . . . . . . . . . . . . . . 62 4.4.3 Verifying a Lease Descriptor . . . . . . . . . . . . . 63 4.4.4 Detecting a Collision . . . . . . . . . . . . . . . . 64 4.4.5 Deallocation and Lease Lifetime . . . . . . . . . . . 65 5. Timer Default Values . . . . . . . . . . . . . . . . . . . 66 6. Security Considerations . . . . . . . . . . . . . . . . . 67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . 68 Appendix A: Application Programmer Interface (API) Issues 69 Appendix B: Session Management Implications . . . . . . . 70 Acknowledgments . . . . . . . . . . . . . . . . . . . . . 71 References . . . . . . . . . . . . . . . . . . . . . . . . 72 Author's Contact Information . . . . . . . . . . . . . . . 73 Full Copyright Statement . . . . . . . . . . . . . . . . . 75 1. Introduction 77 Servers and network administration staff are not available in all 78 environments. Home networks and ad-hoc networks, for example, need to 79 rely entirely on zero-configuration protocols [ZCREQTS]. This 80 document defines the Zeroconf Multicast Address Allocation Protocol 81 (ZMAAP), that allows hosts on small networks to allocate addresses 82 without the need for multicast address allocation servers. 84 The Internet Multicast Address Allocation Architecture [RFC2908] 85 provides a three-layer framework for allocating multicast addresses. 86 The top layer is used to decide which address range to use for 87 allocation. The middle layer is used to coordinate among peers 88 allocating from the same range. The bottom layer is used to provide 89 scalability in a managed environment whereby a small number of 90 servers can allocate addresses to a large number of hosts. In a 91 zero-configuration environment, less scalability is required, and 92 hence the bottom layer will not be needed. ZMAAP thus fits into the 93 Multicast Address Allocation Architecture as a middle-layer protocol 94 which is used between end nodes. 96 ZMAAP allows applications to allocate unique addresses from certain 97 address ranges, to defend those allocations and to detect conflicts 98 in those allocations. 100 1.1 Changes since the previous version of this document 102 1. Timers introduced before AIU responses to ACLM messages are sent 104 If there are many members of a group, an ACLM for that group's 105 allocation would cause a massive implosion of AIUs - like a 106 distributed denial of service attack. While it is unlikely that 107 ZMAAP will be used for large groups maintained by of thousands of 108 mini-MAASs, we won't rule out the possibility. 110 Currently mini-MAASs respond to ACLMs with an AIU immediately. 112 Now, before sending an AIU in response to an ACLM, mini-MAASs will 113 wait a random interval and listen for other AIUs defending the 114 allocation. If such an AIU is received, the mini-MAAS cancels its 115 waiting timer and does not send the AIU. 117 2. To prevent thrashing, rules slow down and stop allocation attempts 119 As more and more addresses in an address space are allocated, 120 claims for random address ranges in the address space have a 121 higher chance of collision. To prevent thrashing (excessively 122 repeated attempts for allocation), new rules are 124 3. Security: Text on WEP removed 126 4. Add a magic number to ZMAAP headers 128 This will be used to detect collision in the use of the same 129 multicast address by multiple applications. 131 5. Clarification of address range conflicts 133 Non overlapping ranges conflict even if the lease id is the same. 135 2. Terminology 137 This document uses the following terms: 139 Multicast 140 IP Multicast, as defined in [RFC1112] and [RFC2460]. 142 Multicast Address 143 An IP multicast address or group address, as defined in [RFC1112] 144 and [RFC2373]. An identifier for a group of nodes. 146 Multicast Scope 147 A range of multicast addresses configured so that traffic 148 sent to these addresses is limited to some subset of the 149 internetwork. See [RFC2365] and [RFC2373]. 151 Multicast Address Allocation Server (MAAS) 152 A node providing multicast address allocation services to 153 network clients. 155 Mini-MAAS 156 A service providing multicast address allocation services to 157 applications running on the same host. Mini-MAASs 158 cooperate to provide network-wide services in small networks 159 without MAASs. 161 In this document, the key words "MAY", "MUST", "MUST NOT", 162 "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be 163 interpreted as described in [RFC2119]. 165 3. Requirements and Design Considerations 167 As described in [RFC2771], a multicast allocation API provides two 168 main services to multicast applications. First, it allows enumeration 169 of the set of available multicast scopes applications may attempt to 170 allocate in. Second, applications can dynamically allocate multicast 171 addresses in scopes they specify. 173 Hosts may also use MADCAP [RFC2730] for these features. MADCAP 174 provides various functions, including allocation of addresses in 175 scopes which are not available using ZMAAP. 177 In general, applications should be unaware of which protocol is being 178 used to allocate multicast addresses (e.g., MADCAP, ZMAAP, or local 179 allocation of SSM [SSM] addresses). 181 ZMAAP satisfies the general requirements for multicast address 182 allocation mechanisms specified in [RFC2908]: robustness, 183 availability and low probability of clashes in the presence of host 184 and network failures, short allocation delay and efficient use of the 185 address space. ZMAAP is expected to work in a unreliable environment 186 (for example on laptops in an ad-hoc network, that can be switched 187 off and back on at any moment). 189 Applications can obtain the following services from a mini-MAAS 190 making use of ZMAAP. For further discussion, see Appendix A. 192 - Obtain an enumeration of supported multicast scopes. 193 - Allocate an address in a specified scope. 194 - Renew an existing address allocation, which an application is 195 using. 196 - Get notified when an allocation has been cancelled by the mini- 197 MAAS due to an allocation conflict. 199 4. Zeroconf Multicast Address Configuration Protocol 201 4.1 Protocol Overview 203 ZMAAP is a peer-to-peer protocol that allows mini-MAASs to coordinate 204 their multicast address allocations. Three messages are used for 205 this purpose: Address In Use (AIU), Address Claim (ACLM). 207 To obtain a multicast address allocation, an application makes a 208 request to a local mini-MAAS, specifying the scope and number of 209 addresses. The mini-MAAS selects the addresses to be allocated and 210 multicasts a ZMAAP ACLM request to the other mini-MAASs. The mini- 211 MAAS issues this request repeatedly. 213 Two things may occur. If an AIU response is received, the mini-MAAS 214 has requested a range of addresses which conflicts with an existing 215 allocation. In this case, the mini-MAAS must select a new range of 216 addresses and try again, or give up. If, on the other hand, the 217 receives no AIU response when the allotted time expire, it assumes it 218 has succeeded in allocating an address. 220 A mini-MAAS will defend an address allocation which it has made. An 221 application can also ask a local mini-MAAS to defend an address 222 allocation it uses, learned through another mechanism (for example, 223 through the use of an API). A mini-MAAS which receives an ACLM 224 message which it defends will issue an AIU response immediately, 225 indicating that the allocation already exists and the ACLM message 226 conflicts. 228 Mini-MAASs may cache information about allocations to aid in 229 selecting addresses which do not conflict with others. A cache entry 230 is maintained for the duration of the intended allocation lifetime 231 indicated in ZMAAP messages. The lifetime can be extended using AIU 232 messages. If an address is not in the cache, it is considered 233 available for allocation. 235 4.2 Transmission of ZMAAP Messages 237 A mini-MAAS sends AIU messages for the addresses that it currently 238 has allocated, before their allocation lifetime expires. 240 All ZMAAP messages are multicast using UDP. The reserved UDP port 241 number is TBD. The address allocations communicated in any message 242 MUST belong to the same multicast scope. 244 All messages are sent to a reserved IPv4 scope-relative multicast 245 address, or IPv6 variable scope multicast address, called in the 246 following the ZMAAP multicast address. 248 These address assignments are TBD. The destination address of a 249 message MUST be in the same multicast scope as the address 250 allocations it contains. A mini-MAAS MUST listen to messages sent to 251 the ZMAAP multicast address for all scopes in which it is has 252 allocated addresses or is in the process of allocating addresses. 254 ZMAAP is used to allocate addresses in all ranges for which 255 coordination must be done among multiple machines, but within an area 256 smaller than an Admin scope. This way, the ranges used by MADCAP, 257 ZMAAP, and SSM are all disjoint and clear ownership is preserved. 258 MADCAP is used for ranges which require coordination across an Admin 259 scope or larger, and SSM does not require coordination among multiple 260 machines. 262 The ranges which are defined or under discussion today, which ZMAAP 263 would be used for, include: 265 Allocation Scope 266 ---------------- 267 (1) IPv4 Dynamic Link-Local [TBD] 268 (2) IPv6 Dynamic Link-Local [RFC2373] 269 (3) IPv6 Dynamic Subnet-Local [RFC2373] 270 (4) IPv4 Unicast-Prefix-based [TBD] 271 (5) IPv6 Unicast-Prefix-based [UNIPREFIX] 273 To date, no range of addresses for (1) or (4) has been defined. 275 4.3 Protocol Message Format 277 ZMAAP uses two messages: Address In Use (AIU), used to announce an 278 existing address allocation, and Address Claim (ACLM), used to 279 announce a desired address allocation. ZMAAP implementations MUST 280 support both these messages. 282 The ZMAAP messages have the following common format: 284 0 1 2 3 285 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 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | 0x1b | 0xd7 | 0x3b | 0x48 | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | Version | Message Type | Address Family | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | Lease descriptor 1 (variable) / 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 . . . 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Lease descriptor N (variable) / 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 The initial 4 bytes in the message constitute a 'magic number' which 299 is used to detect protocol collisions on the port and multicast group 300 where ZMAAP is operating. Any message which does not begin with the 301 magic number MUST be silently discarded. 303 The Version field indicates the ZMAAP version. It MUST be 1 for the 304 version described in this document. 306 The Message Type field defines the type of ZMAAP message. The 307 following values are defined: 309 Value Message type 310 ----- ------------ 311 0 Address Claim (ACLM) 312 1 Address In Use (AIU) 314 The Address Family field indicates the address family for all the 315 addresses in the ZMAAP message, using the values defined by IANA 316 [IANA]. This version of ZMAAP supports the IPv4 and IPv6 address 317 families: 319 Value Address Family 320 ----- -------------- 321 1 IPv4 322 2 IPv6 324 Lease descriptors describe address allocations in ZMAAP messages. 326 An IPv4 address is represented by 4 bytes in network byte order. The 327 lease descriptor for IPv4 addresses has the following format: 329 0 1 2 3 330 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 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | Initial address in the range | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | Final address in the range | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | Lease Identifier | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | Lease Lifetime | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 An IPv6 address is represented by 16 bytes in network byte order. 342 The lease descriptor for IPv6 addresses has the following format: 344 0 1 2 3 345 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 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | | 348 | Initial address in the range | 349 | | 350 | | 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 | | 353 | Final address in the range | 354 | | 355 | | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | Lease Identifier | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | Lease Lifetime | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 The initial and final addresses define the range of addresses claimed 363 or allocated. When individual addresses are allocated rather than 364 ranges, the Initial and Final addresses are identical. 366 Addresses in the lease descriptor belong to the address family 367 indicated by the Address Family field in the message header. 369 The Lease Identifier distinguishes different allocations of the same 370 address range. It is assigned by the allocator mini-MAAS, using an 371 implementation dependent method. For example, it can be computed as 372 a hash of the allocator's address and the allocation time (and UDP 373 transmission port in case more than one mini-MAAS resides on the same 374 host). 376 The Lease Lifetime is the number of seconds which a lease may be 377 cached after it has been received. 379 The number of lease descriptors in a ZMAAP message is limited by the 380 condition that the message fits into a payload of maximum 576 bytes 381 for IPv4 packets and 1280 bytes for IPv6 packets. If the number of 382 lease descriptors is too large to fit into the maximum payload, they 383 are sent in separate ZMAAP messages. 385 4.4 ZMAAP mini-MAAS behavior 387 A ZMAAP mini-MAAS performs four functions: Claiming, defending, 388 verifying and detecting conflicts in allocations. 390 A mini-MAAS MUST maintain state information for the allocations it 391 makes or it maintains as a result of requests from its local 392 applications. This will be referred to as the 'allocation record.' 394 It MAY also cache state information for other allocations, learned 395 from received ZMAAP messages. This could be useful, for example, to 396 assist in selecting multicast addresses that will be unlikely to 397 conflict with preexisting allocations. The term 'allocation record' 398 as used below will NOT include this state information. 400 4.4.1 Claiming an address 402 To allocate multicast addresses, an application makes a request from 403 the local mini-MAAS, indicating the scope, the number of addresses 404 desired and the allocation lifetime. 406 The mini-MAAS selects free addresses by consulting its allocation 407 record and creates a lease descriptor. To reduce the likelihood of 408 collisions, a random selection of the free addresses is strongly 409 recommended (see Section 4.3). A unique identifier ("lease 410 identifier") is associated with each allocation to distinguish 411 allocations of the same addresses. 413 The mini-MAAS starts the claiming by sending an ACLM message 414 containing the lease descriptor. After sending the ACLM message it 415 MUST start a Claim Timer for [ANNOUNCE-WAIT] seconds. Also, it SHOULD 416 resend the ACLM message, first after [RESEND-WAIT] seconds, and later 417 doubling after each send, until either the Claim Timer expires, or 418 the claim is aborted. 420 If the mini-MAAS receives an AIU message or an ACLM message listing 421 addresses being claimed, it MUST abort the claiming, stop the Claim 422 Timer, and give up on the addresses indicated in the AIU or ACLM 423 message. It MAY select new addresses and restart the claiming 424 procedure, after waiting. Each successive attempt T, the mini-MAAS 425 waits for a uniformly distributed random interval from 0 to 426 ([RESTART-WAIT] * T) milliseconds. 428 If the Claim Timer expires, the mini-MAAS commits the allocation and 429 communicates the lease to the application. To complete a new address 430 allocation, a mini-MAAS MUST send an AIU message containing its lease 431 descriptor. 433 4.4.2 Defending an Address 435 A mini-MAAS MUST defend all allocations in its allocation record. 437 If there is any overlapping between address ranges in the received 438 ACLM and address ranges in its allocation record, the mini-MAAS MUST 439 respond with an AIU. This AIU contains the Lease Descriptors of the 440 mini-MAASs own allocations whose address ranges overlap with those in 441 the ACLM. 443 Note that the AIU is sent regardless of whether the Lease Identifiers 444 for an overlapping range match (same allocation) or not (conflicting 445 allocations). The other mini-MAAS will be able to distinguish these 446 cases using the Lease Identifier and take an appropriate action. 448 To send an AIU in response to an ACLM message, the mini-MAAS starts a 449 random Defense Timer, uniformly distributed from 0 to [DEFEND-WAIT] 450 milliseconds. During this waiting interval, the mini-MAAS listens 451 for AIU response to the ACLM. If the mini-MAAS detects the same AIU 452 which it would have sent, the mini-MAAS cancels the Defense Timer. 453 Otherwise, when the Defense Timer expires, the mini-MAAS sends the 454 AIU. 456 ZMAAP allows address allocations to persist without the initial 457 allocator. Other session participants can share the defense of the 458 address allocation by registering with their local mini-MAASs and 459 indicating the lease identifier (learned from the session initiator 460 via some session announcement mechanism, see Appendix B.) A mini- 461 MAAS MAY add an allocation to its record, even if it was not the 462 mini-MAAS which allocated the address. Before it does this, it MUST 463 verify the lease identifier is correct (see Section 4.4.3). 465 4.4.3 Verifying a Lease Descriptor 467 A valid lease identifier matches an existing (defended) allocation, 468 and does not conflict with any other allocations. 470 A mini-MAAS MUST verify the validity of a lease identifier before 471 adding it to its allocation record for 'shared defense' of an address 472 (see Section 4.4.2 and Appendix A). 474 To verify a lease identifier is correct, the mini-MAAS claims it 475 using ACLM messages, as described in section 4.4.1. 477 4.4.4. Detecting an Allocation Conflict 479 A mini-MAAS that receives an AIU message MUST check its allocation 480 record to determine the status of the indicated allocations. 482 If the mini-MAAS is currently trying to allocate any of the addresses 483 in the AIU message, the mini-MAAS MUST try a different address or 484 give up trying to allocate addresses (see Section 4.4.1). 486 If any ranges in the AIU message overlap without exactly matching 487 recorded allocations then an allocation conflict exists. Also, if an 488 address range in an AIU matches a recorded address allocation with a 489 different lease identifiery, this also indicates a conflict. The 490 mini-MAAS MUST remove the allocation from its allocation record. The 491 mini-MAAS will inform any local applications registered for the 492 canceled allocation, if it has implemented this functionality (see 493 Appendix A). 495 4.4.5. Deallocation and Lease Lifetime 497 A mini-MAAS maintains an address allocation in its record as long as 498 a local application uses it. 500 When an allocation is not needed anymore by any local application, 501 the mini-MAAS removes it from the allocation record, so it stops 502 defending it. However, the allocation can still be defended by other 503 mini-MAASs interested in preserving it. When an allocation is no 504 longer defended by any mini-MAAS, the addresses can be reallocated. 506 The Lease Lifetime indicated in ZMAAP messages limits the lifetime of 507 cache entries used to assist in address selection for new 508 allocations. A mini-MAAS MAY send AIUs to extend an expiring 509 lifetime for any of its allocations. It SHOULD NOT send AIUs to 510 reduce the lifetime (in particular set it to 0), since other mini- 511 MAASs may intend to preserve it. 513 5. Timer Default Values 515 ANNOUNCE-WAIT 3 seconds 516 RESEND-WAIT 200 milliseconds 517 RESTART-WAIT 100 milliseconds 518 DEFEND-WAIT 100 milliseconds 520 6. Security Considerations 522 In the interest of simplicity, this draft does not prescribe a means 523 of securing the multicast auto-configuration mechanism. Thus it is 524 possible that hosts will allocate conflicting multicast addresses for 525 a period of time, or that non-conforming hosts will attempt to deny 526 service to other hosts by allocating the same multicast addresses. 528 A 'greedy' mini-MAAS which simply ignored others' advertisements and 529 allocated any address it wished could steal addresses from others. 530 If there were more than one such 'greedy' mini-MAAS on the network, 531 address allocation conflicts would never be detected or corrected. 533 These threats are most serious in wireless networks since attackers 534 on a wired network will require physical access to the home network, 535 while wireless attackers may reside outside the home. 537 In order to counter these threats, IP or link layer security could be 538 applied to authenticate messages and thereby prevent the attacks 539 listed above. For example, if all authorized hosts in the network 540 shared a preconfigured key, this could be used with the IP 541 Authentication Header [RFC2402] to discard unauthenticated datagrams. 542 Admittedly, preconfiguration of keys runs counter to the goals of 543 zero configuration networking. There's no free lunch. 545 7. IANA Considerations 547 This document requires an allocation for a UDP port number, and a 548 range of IPv4 multicast addresses for link-local dynamic multicast 549 address allocation. 551 Appendix A Application Programmer Interface (API) Definition 553 The ZMAAP API will be presented as a set of abstract functions 554 followed by language specific mappings. These functions and their 555 names are derived from the Abstract API for Multicast Address 556 Allocation [RFC2771]. This API is specified in a separate document 557 [ZMAAPAPI]. 559 What distinguishes the ZMAAP API from the general multicast address 560 allocation API is the need for two additional functions: Shared 561 ownership, for renewal and defense of allocations, and conflict 562 notification for applications to determine if and when an allocation 563 can no longer be used. 565 Normally the mini-MAAS allocating an address maintains an allocation 566 record entry for it. This implies the mini-MAAS will defend the 567 address from conflicting claims and will send AIU messages before the 568 lease lifetime expires for all active allocations. In the case of 569 'shared ownership', (initiated via the ZMAAP API), a mini-MAAS first 570 verifies that the lease is still valid (section 4.4.3), then it adds 571 the record to its own allocation record. 573 Appendix B Session Management Implications 575 Multicast address allocation alone is not useful. A mechanism is 576 needed in order to discover sessions using multicast allocations. 577 This serves applications attempting to join an existing session, 578 those initiating new sessions and also for rendezvous at a new 579 session address if there has been a conflict with an address 580 currently in use. 582 Sessions are announced using the Session Announcement Protocol (SAP) 583 [RFC2974]. They are described using the Session Description Protocol 584 (SDP) [RFC2327]. 586 SAP describes how to announce sessions for IPv4 using global and 587 adminstrative scoped multicast. 589 This technique can be used to announce sessions which are allocated 590 in other scopes as well. For IPv4 link-local scope session 591 announcement, an IP time-to-live of 1 is used. This limits 592 propogation of the announcement to the same scope where it is 593 meaningful. 595 An additional SDP session attribute SHOULD be included for use in 596 announcing sessions for addresses allocated with ZMAAP. This 597 attribute allows coordination with ZMAAP. 599 a=zmaap-lease-id: 601 is set to the lease identifier associated with the 602 announced session. 604 An application which receives a session announcement with this 605 attribute may use it to form a Lease Descriptor and request the ZMAAP 606 API to either defend the allocation or for notification if there is 607 an address allocation conflict. 609 References 611 [IANA] Address Family Numbers. http://www.isi.edu/in- 612 notes/iana/assignments/address-family-numbers 614 [MDNS] Ebisov, L., Aboba, B., Thaler, D., "Multicast DNS", draft- 615 ietf-dnsext-mdns-06.txt, October 2001. Work in progress. 617 [RFC1112] Deering, S., "Host Extensions for IP Multicasting", RFC 618 1112, August 1989. 620 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 621 Requirement Levels", BCP 14, RFC 2119, March 1997. 623 [RFC2327] Handley, M., Jacobson, V., "SDP: Session Description 624 Protocol", RFC 2327, April 1998. 626 [RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, 627 RFC 2365, July 1998. 629 [RFC2373] Hinden, R. and Deering, S., "IP Version 6 Addressing 630 Architecture", RFC 2373, July 1998. 632 [RFC2402] Kent, S., Atkinson, R., "IP Authentication Header", RFC 633 2402, November 1998. 635 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 636 (IPv6) Specification", RFC 2460, December 1998. 638 [RFC2730] Hanna, S., Patel, B., and M. Shah, "Multicast Address 639 Dynamic Client Allocation Protocol (MADCAP)", RFC 2730, December 640 1999. 642 [RFC2771] Finlayson, R., "An Abstract API for Multicast Address 643 Allocation", RFC 2771, February 2000. 645 [RFC2908] Thaler, D., Handley, M., and D. Estrin, "The Internet 646 Multicast Address Allocation Architecture", RFC 2908, September 647 2000. 649 [RFC2974] Handley, M., Perkins, C., Whelan, E., "Session Announcement 650 Protocol", RFC 2974, October 2000. 652 [SSM] IANA, "Single-source IP Multicast Address Range", 653 http://www.isi.edu/in-notes/iana/assignments/single-source- 654 multicast, October 1998. 656 [UNIPREFIX] Haberman, B., Thaler, D., "Unicast-Prefix-based IPv6 657 Multicast Addresses", Internet Draft, draft-ietf-ipngwg-uni- 658 based-mcast-03.txt, October 2001. Work in progress. 660 [V4LL] Cheshire, S., Aboba, B., "Dynamic Configuration of IPv4 link- 661 local addresses", draft-ietf-zeroconf-ipv4-linklocal-04.txt, 662 July 2001. Work in progress. 664 [ZCREQTS] Hattig, M., "Zeroconf Requirements", draft-ietf-zeroconf- 665 reqts-06.txt, November 2000. Work in progress. 667 [ZMAAPAPI] Guttman, E., "An API for the Zeroconf Multicast Address 668 Allocation Protocol", draft-ietf-zeroconf-zmaap-api-00.txt. 669 Work in Progress. 671 Acknowledgments 673 This draft has been benefited from work by Mark Handley and Steve 674 Hanna on the Multicast Address Allocation Protocol (AAP). Prashant 675 Agarwal's master thesis work at International University provided 676 helpful insights. 678 Authors' Addresses 680 Octavian Catrina, Editor 681 International University in Germany 682 International University Campus 2 683 D-76646 Bruchsal, Germany 685 Phone: +49 7251 700 221 686 EMail: Octavian.Catrina@i-u.de 688 Dave Thaler 689 Microsoft Corporation 690 One Microsoft Way 691 Redmond, WA 98052 693 Phone: +1 (425) 703-8835 694 EMail: dthaler@microsoft.com 696 Bernard Aboba 697 Microsoft Corporation 698 One Microsoft Way 699 Redmond, WA 98052 701 Phone: +1 (425) 936-6605 702 EMail: bernarda@microsoft.com 703 Erik Guttman 704 Sun Microsystems 705 Eichhoelzelstr. 7 706 74915 Waibstadt Germany 708 Phone: +49 172 865 5497 709 Email: erik.guttman@sun.com 711 Full Copyright Statement 713 Copyright (C) The Internet Society (2001). All Rights Reserved. 715 This document and translations of it may be copied and furnished to 716 others, and derivative works that comment on or otherwise explain it 717 or assist in its implementation may be prepared, copied, published 718 and distributed, in whole or in part, without restriction of any 719 kind, provided that the above copyright notice and this paragraph are 720 included on all such copies and derivative works. However, this 721 document itself may not be modified in any way, such as by removing 722 the copyright notice or references to the Internet Society or other 723 Internet organizations, except as needed for the purpose of 724 developing Internet standards in which case the procedures for 725 copyrights defined in the Internet Standards process must be 726 followed, or as required to translate it into languages other than 727 English. 729 The limited permissions granted above are perpetual and will not be 730 revoked by the Internet Society or its successors or assigns. 732 This document and the information contained herein is provided on an 733 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 734 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 735 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 736 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 737 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 739 Acknowledgement 741 Funding for the RFC Editor function is currently provided by the 742 Internet Society.