idnits 2.17.1 draft-ietf-malloc-aap-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 35 pages 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. ** There are 2 instances of too long lines in the document, the longest one being 2 characters in excess of 72. == 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 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) -- Looks like a reference, but probably isn't: 'TIMER-1' on line 64 -- Looks like a reference, but probably isn't: 'STARTUP-WAIT' on line 1603 -- Looks like a reference, but probably isn't: 'ANNOUNCE-WAIT' on line 1142 -- Looks like a reference, but probably isn't: 'REPEAT-INTERVAL' on line 1606 -- Looks like a reference, but probably isn't: 'RESEND-WAIT' on line 1605 -- Looks like a reference, but probably isn't: 'CLAIM-WAIT' on line 1604 -- Looks like a reference, but probably isn't: 'ASA-INTERVAL' on line 1607 -- Looks like a reference, but probably isn't: 'ASRP-INTERVAL' on line 1608 -- Looks like a reference, but probably isn't: 'RESEND-INTERVAL' on line 1637 == Unused Reference: '11' is defined on line 1568, but no explicit reference was found in the text == Outdated reference: A later version (-05) exists of draft-ietf-malloc-arch-02 ** Downref: Normative reference to an Historic draft: draft-ietf-malloc-arch (ref. '1') == Outdated reference: A later version (-06) exists of draft-ietf-malloc-masc-03 ** Downref: Normative reference to an Historic draft: draft-ietf-malloc-masc (ref. '2') ** Obsolete normative reference: RFC 2460 (ref. '5') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2373 (ref. '6') (Obsoleted by RFC 3513) == Outdated reference: A later version (-02) exists of draft-ietf-mboned-glop-addressing-00 ** Downref: Normative reference to an Experimental draft: draft-ietf-mboned-glop-addressing (ref. '9') == Outdated reference: A later version (-06) exists of draft-ietf-mboned-mzap-04 ** Downref: Normative reference to an Historic draft: draft-ietf-mboned-mzap (ref. '10') ** Obsolete normative reference: RFC 1700 (ref. '11') (Obsoleted by RFC 3232) ** Obsolete normative reference: RFC 2434 (ref. '12') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 1305 (ref. '13') (Obsoleted by RFC 5905) Summary: 14 errors (**), 0 flaws (~~), 8 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MALLOC working group Mark Handley, ACIRI 2 Internet Draft Stephen R. Hanna, Sun Microsystems, Inc. 3 October 1999 draft-ietf-malloc-aap-01.txt 4 Expires: April 2000 6 Multicast Address Allocation Protocol (AAP) 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC 2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet- Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt. 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 The document defines a Multicast Address Allocation Protocol (AAP) 32 that forms a part of the Internet Multicast Address Allocation 33 Architecture being defined by the IETF Multicast Address Allocation 34 Working Group. AAP addresses the specific issue of coordination among 35 Multicast Address Allocation Servers within a domain. 37 1. Introduction 39 This document describes and defines the Multicast Address Allocation 40 Protocol (AAP), which allows Multicast Address Allocation Servers 41 (MAAS's) to coordinate multicast address allocation within a domain. 43 Section 1 introduces the concepts and terms used throughout the 44 document. Section 2 gives an overview of the protocol. Section 3 45 describes how multicast scopes relate to the protocol. Sections 4 46 and 5 describe how MAAS's and Prefix Coordinators behave with respect 47 to the protocol. Section 6 describes protocol details and message 48 formats. Section 7 describes Security Considerations and section 8 49 describes IANA Considerations. Section 9 lists acknowledgements, 50 section 10 lists references, and section 11 gives the authors' 51 addresses. Appendix A includes sample protocol interactions. Appendix 52 B lists constants and timers defined in this document. Appendix C 53 lists changes made in this version of the document. Appendix D lists 54 unresolved issues. 56 1.1 Terminology 58 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 59 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 60 document are to be interpreted as described in RFC 2119 [3]. 62 Constants and timers defined in this document are listed in Appendix 63 B. Their names are written in all caps with square braces surrounding 64 them (like [TIMER-1]). 66 References to other documents are listed in section 10. They are 67 indicated by arabic numerals in square braces (like [1]). 69 1.2. Definitions 71 AAP Address 72 The reserved scope-relative multicast address used for the AAP 73 protocol within an allocation domain. 75 Allocation Domain (or domain) 76 An administratively scoped multicast-capable region of the network, 77 within which multicast addresses are allocated dynamically using an 78 intra-domain protocol such as AAP. Allocation domains will 79 normally coincide with unicast Autonomous Systems (AS's). 81 For more information, see section 3. 83 Multicast 84 IP Multicast, as defined in [4] and modified in [5]. 86 Multicast Address 87 An IP multicast address or group address, as defined in [4] and 88 [6]. An identifier for a group of nodes. 90 Multicast Scope 91 A range of multicast addresses configured so that traffic sent to 92 these addresses is limited to some subset of the internetwork. See 93 [6] and [7]. 95 Multicast Address Allocation Server (MAAS) 96 A host providing multicast address allocation services. 98 Prefix Coordinator 99 A host that announces the set of multicast addresses available for 100 use within an allocation domain. 102 Scope Zone 103 One multicast scope may have several instances, which are known as 104 Scope Zones or zones, for short. 106 For instance, an organization may have multiple sites. Each site 107 might have its own site-local Scope Zone, each of which would be an 108 instance of the site-local Scope. However, a given interface on a 109 given host would only ever be in at most one instance of a given 110 scope. Messages sent by a host in a site-local Scope Zone to an 111 address in the site-local Scope would be limited to the site-local 112 Scope Zone containing the host. 114 1.3 The Internet Multicast Address Allocation Architecture 116 AAP fits into the Internet Multicast Address Allocation Architecture 117 [1] being defined by the IETF Multicast Address Allocation Working 118 Group. This architecture has three layers: 120 o A host-server protocol or mechanism that a host uses to request 121 multicast address allocation services from a Multicast Address 122 Allocation Server (MAAS). An example of such a protocol is MADCAP 123 [8]. 125 o An intra-domain protocol or mechanism that MAAS's use to coordinate 126 allocations within a domain to ensure that they do not collide. AAP 127 plays this role. 129 o An inter-domain protocol or mechanism that coordinates multicast 130 address allocation across domains to avoid duplicate allocations 131 and perhaps achieve other goals, such as improving aggregation of 132 multicast addresses to reduce the size of multicast routing tables. 133 MASC [2] or static allocations by AS number [9] can be used at this 134 layer. 136 1.4 Requirements 138 The AAP protocol is designed to meet certain requirements which are 139 appropriate for its role as an interdomain multicast address 140 allocation protocol designed primarily to coordinate the actions of 141 Multicast Address Allocation Servers within an allocation domain. 143 o The first and most important requirement is to ensure the continued 144 availability of multicast address allocation services. AAP has a 145 decentralized architecture so that it can survive the failure of 146 one or more Multicast Address Allocation Servers or Prefix 147 Coordinators. 149 AAP is also designed to continue functioning during a short-term 150 network partition. Long-term partitions may cause duplicate address 151 allocations. Section 4.2.9 contains a more detailed discussion of 152 how network partitions are handled. 154 o Since multicast addresses are a relatively scarce commodity, AAP is 155 designed to achieve high utilization. That is, it is designed to 156 ensure that in a situation where demand for multicast addresses 157 exceeds supply, all or almost all addresses can be in use 158 simultaneously. 160 o AAP helps MAAS's to detect and resist denial of service and other 161 attacks. AAP messages may be authenticated so that unauthorized 162 messages can be ignored. Even an attack from an authorized AAP 163 server can be resisted by blocking all of its claims with Address 164 In Use messages. 166 o Duplicate address allocations (collisions) are largely avoided. 167 Network partition, excessive packet loss, or unstable MAAS's can 168 cause collisions, but this should be rare. When collisions occur, 169 they can be detected via AAP. However, applications that use 170 multicast must always be prepared to filter out extraneous traffic, 171 since the IP Multicast model allows anyone to send on any multicast 172 address. 174 2 Protocol Overview 176 The Multicast Address Allocation Protocol (AAP) allows Multicast 177 Address Allocation Servers (MAAS's) and Prefix Coordinators within an 178 allocation domain to coordinate their actions. 180 MAAS's and Prefix Coordinators communicate by sending UDP messages to 181 a reserved port number and a reserved scope-relative multicast 182 address (known as the AAP address). This ensures that all MAAS's and 183 Prefix Coordinators within a domain receive all messages concerning 184 address allocation within that domain. Assignments for the port 185 number and scope-relative multicast address have been requested from 186 IANA, but have not yet been assigned. 188 Prefix Coordinators periodically announce the set of multicast 189 addresses and lifetimes available for allocation within the domain 190 using the Address Space Announce (ASA) message. 192 MAAS's periodically announce with the Address In Use (AIU) message 193 the set of multicast addresses that they have allocated. Before 194 allocating addresses, a MAAS MUST listen on the AAP address for at 195 least [STARTUP-WAIT] seconds so that it has a good idea of currently 196 available addresses. 198 To allocate one or more addresses, a MAAS sends an Address Claim 199 (ACLM) message listing the addresses and lifetimes desired and 200 retransmits this message at exponentially increasing intervals. If 201 another MAAS is aware of a conflicting allocation, it will send an 202 AIU listing the conflict (using a randomized timer to avoid storms). 203 If an AIU listing a conflict is received, the claiming MAAS will 204 choose another set of addresses and start again by sending an ACLM 205 for those addresses. If no AIU is received within [ANNOUNCE-WAIT] 206 seconds, the claiming MAAS will consider the addresses allocated and 207 being announcing them periodically using the AIU message. 209 MAAS's can "preallocate" addresses using the Address Intent To Use 210 (AITU) message. To preallocate one or more addresses, a MAAS 211 periodically announces the preallocation using AITU. If another MAAS 212 knows of a conflict, it responds as it would to a conflict to an 213 ACLM. If a MAAS has sent at least two AITU messages without receiving 214 notice of a conflict, it can skip the ACLM and move directly to 215 sending an AIU and allocating the addresses. 217 If a MAAS cannot meet its allocation needs with the addresses 218 currently available for allocation, it can report this to the other 219 MAAS's with an Address Not Available (ANA) message. 221 An Address Space Report (ASRP) message is sent periodically by a MAAS 222 (selected using random timeouts) to indicate to the Prefix 223 Coordinator(s) how much of the current address space is in use and 224 how many addresses are needed to satisfy demands. Prefix 225 Coordinator(s) are often small devices with no stable storage and 226 this provides a way for them to track usage without having to track 227 individual addresses. The Prefix Coordinator(s) may decide to 228 increase or decrease the available address space in response to a 229 single ASRP message or an observed trend in usage. 231 If security is desired, IPsec is used to authenticate messages (using 232 a manually configured shared key). Unauthenticated messages are 233 ignored. 235 3 Scopes 237 AAP can be used to manage global multicast addresses and/or 238 administratively scoped multicast addresses [7]. A MAAS will 239 typically use MZAP [10] to learn about the administrative scopes that 240 it is in. For each scope, it will learn the range of addresses 241 assigned to the scope, the name or names assigned to the scope, and 242 whether the scope is a "large"/"divisible" scope or a 243 "small"/"indivisible" scope. 245 AAP MUST NOT be used to manage TTL-scoped multicast addresses. 247 3.1 Large Scopes 249 A large scope is divided up using some interdomain multicast address 250 allocation protocol or mechanism into multiple allocation domains. 251 Some addresses within the large scope are assigned to each allocation 252 domain and AAP (or some other intradomain protocol or mechanism) is 253 used to manage these addresses within the allocation domain. 255 A new administrative scope named the Allocation Scope is defined in 256 section 3.3. Whenever AAP is to be used to manage addresses on large 257 scopes, an Allocation Scope MUST be defined. Its boundary MUST 258 coincide with the edge of the allocation domain and all large scopes 259 active within the allocation domain MUST contain the Allocation 260 Scope. 262 The AAP traffic for managing large scopes within a given allocation 263 domain is sent on the scope-relative multicast address reserved for 264 AAP within the Allocation Scope. 266 For the purposes of AAP, the global address space is considered to be 267 a large scope, although it is not an administrative scope and its 268 existence is not announced using MZAP. 270 3.2 Small Scopes 272 The AAP traffic for managing a small scope is sent on the scope- 273 relative multicast address reserved for AAP within the scope being 274 managed. ASA and ASRP messages SHOULD NOT be used within a small 275 scope and Prefix Coordinators are not needed, since there is no need 276 to coordinate with an inter-domain protocol or mechanism. However, 277 these messages MAY be sent for network management or other reasons. 279 All small scopes active in an allocation domain MUST be contained 280 within (or topologically equal to) the Allocation Scope for that 281 allocation domain (if an Allocation Scope is defined). 283 3.3 The Allocation Scope -- 239.251.0.0/16 285 The Allocation Scope is a new administrative scope, defined in this 286 document and soon to be reserved with the IANA. The address space 287 239.251.0.0/16 is reserved for the Allocation Scope. This is the 288 scope that is used to run AAP for large scopes. 290 If the Allocation Scope is not active within a region of the network, 291 then AAP cannot be used to manage large scopes in that region. 292 However, it can still be used to manage small scopes. 294 3.3.1 Expansion of the Allocation Scope 296 The ranges 239.248.0.0/16, 239.249.0.0/16 and 239.250.0.0/16 are 297 unassigned and available for expansion of this space. These ranges 298 should be left unassigned until the 239.251.0.0/16 space is no longer 299 sufficient. 301 4 Multicast Address Allocation Servers 303 A Multicast Address Allocation Server (MAAS) is a host providing 304 multicast address allocation services. This host may be providing 305 multicast address allocation services to other hosts using the MADCAP 306 protocol (or some other protocol or mechanism). Alternatively, a MAAS 307 may be concerned only with its own address allocation needs. 309 4.1 MAAS Requirements 311 All MAAS's MUST maintain stable storage so that they remember their 312 own address allocations, those of other MAAS's in the domain, and the 313 addresses available in the domain. This stable storage MUST be 314 maintained across power losses, reboots, etc. 316 If the stable storage on one MAAS is lost, other MAAS's in the domain 317 will continue to defend its allocations. However, the loss of stable 318 storage on several MAAS's or the combination of a network outage with 319 the loss of stable storage in a MAAS can result in duplicate address 320 allocations. 322 All MAAS's MUST attempt to maintain active participation in the AAP 323 protocol at all times, with constant network connectivity. Occasional 324 outages will be handled by by other MAAS's defending the missing 325 MAAS's allocations, but an extended loss of connectivity with one or 326 more MAAS's can result in duplicate address allocations. 328 Because of these requirements (and because large numbers of MAAS's 329 within an allocation domain can cause excess traffic and address 330 space fragmentation), most hosts should not be MAAS's. Instead, a few 331 reliable, well-connected hosts should be selected as MAAS's. Other 332 hosts should connect to those MAAS's using a client-server protocol 333 such as MADCAP. This will relieve them from the burdens of keeping 334 the available addresses and all the allocations in the domain in 335 stable storage, maintaining constant network connectivity and 336 participation in the AAP protocol, and waiting [STARTUP-WAIT] seconds 337 after joining the AAP address before they can allocate an address. 339 4.2 Specification of MAAS Behavior 341 The primary function of a MAAS is to allocate multicast addresses. 342 The hard part is to do this robustly, efficiently, and without 343 collisions. 345 4.2.1 The Allocation Record 347 A MAAS MUST listen to messages sent to the AAP address for all scopes 348 in which it is active. It MUST maintain a separate Allocation Record 349 for each scope, including information about all allocations 350 (announced using the AIU message), preallocations (announced using 351 the AITU message), address requests (announced using the ANA 352 message), and available addresses (announced using the ASA message). 353 The information about allocations, preallocations, and address 354 requests SHOULD be removed when they reach their end time. The 355 information about available addresses SHOULD be retained until it is 356 superseded by information from a newer ASA message. 358 The entries in this record allow a MAAS to defend the allocations of 359 other MAAS's (if those MAAS's are unable to defend their own 360 allocations for some reason). They also allow the MAAS to determine 361 which addresses it should choose for its own allocations. 363 4.2.2 Defending Allocations 365 A MAAS MUST send AIU messages periodically for all the addresses that 366 it currently has allocated. Each of these addresses SHOULD be 367 included in an AIU message about every [REPEAT-INTERVAL] seconds. 368 Actually, the MAAS SHOULD vary the interval by about 30% (+ or -) to 369 avoid synchronization effects. 371 For these regular AIU announcements (as opposed to AIU messages sent 372 in response to ACLM or AITU messages or AIU messages sent with a 373 shorter retransmission timer than [REPEAT-INTERVAL]), a MAAS SHOULD 374 consolidate its allocated addresses into as few AIU messages as 375 possible (while ensuring that the UDP payload of the AIU message does 376 not exceed 500 bytes). The MAAS should also use a separate randomized 377 timer for each of these messages or some similar technique to avoid 378 synchronizing the time when the messages are sent. This will reduce 379 the background traffic due to AIU messages and avoid synchronization 380 effects. 382 A MAAS that has just allocated one or more addresses SHOULD resend 383 the AIU for those addresses again after [RESEND-WAIT] seconds, and 384 again after a further [RESEND-WAIT]*2 seconds, doubling each time 385 until the interval reaches [REPEAT-INTERVAL] seconds. 387 When a MAAS A receives an ACLM or AITU message from another MAAS B, 388 it SHOULD check its Allocation Record to see whether it believes that 389 any of the addresses in question are already allocated (that is, 390 whether it has received an AIU for those addresses). If so, it SHOULD 391 set an Allocation Defense timer based on the algorithm below and 392 follow the processing rules described in the next two paragraphs. 394 If MAAS A sees an AIU message from someone other than MAAS B 395 containing one or more of the addresses in question before the 396 Allocation Defense timer expires, it SHOULD restart the timer with 397 double its original value. If MAAS A sees an ACLM or AITU message 398 from MAAS B with the same Request Sequence Number and a different set 399 of addresses, it SHOULD cancel the Allocation Defense timer and check 400 this message against the Allocation Record as described above. 402 If MAAS A's Allocation Defense timer expires, it SHOULD send an AIU 403 message containing the addresses in question and restart the timer 404 with twice its previous value, unless that value was 0, in which case 405 it SHOULD set it to [RESEND-WAIT]. If the timer interval becomes 406 greater than [REPEAT-INTERVAL], the timer SHOULD be cancelled. In 407 this case, the remote MAAS probably suffered some form of failure 408 after sending the ACLM or AITU. 410 The initial value for the Allocation Defense timer is determined as 411 follows: 413 o If MAAS A allocated one or more of the addresses in question, the 414 initial value of the timer is 0. 416 o If MAAS A did not allocate any of the addresses in question, the 417 initial value of the timer (t) is set to a random number between 418 [RESEND-WAIT]*2 and [RESEND-WAIT]*8. 420 4.2.3 Startup 422 When a MAAS starts up, it MUST listen to AAP messages for at least 423 [STARTUP-WAIT] before it can allocate addresses. For large scopes, it 424 SHOULD also have received at least one ASA message. If it does not 425 receive an ASA message within this time, it MAY allocate addresses 426 only if it has cached a previous ASA message which includes at least 427 one range that has not reached its end time. 429 4.2.4 Allocating Addresses Using ACLM 431 The simplest way to allocate addresses using AAP is to use the 432 Address Claim (ACLM) message. The MAAS selects one or more addresses 433 and an end time for the claim (using the techniques described in 434 section 4.2.6). It then sends these addresses in an ACLM message. 436 After sending the ACLM message, the MAAS SHOULD then set a Claim 437 Timer for [ANNOUNCE-WAIT] seconds in the future. The MAAS SHOULD also 438 resend the ACLM message after [RESEND-WAIT] seconds, and again after 439 a further [RESEND-WAIT]*2 seconds, doubling each time until the Claim 440 Timer expires. 442 If the MAAS receives an ACLM message or an AIU message from another 443 MAAS listing an address being claimed before the Claim Timer expires, 444 this indicates a collision. It MUST cancel the Claim Timer and give 445 up on the addresses mentioned in the ACLM or AIU message. It MAY 446 choose new addresses (possibly including addresses in the original 447 claim for which no collisions were report), send another ACLM message 448 with the same Request Sequence Number listing the new addresses, and 449 set a new Claim Timer for [ANNOUNCE-WAIT] seconds in the future. 451 If the MAAS receives an ASA message whose Expiration Time (after 452 adjusting for clock skew, as described in section 6.3.1) is newer 453 than the last ASA message processed and the newer ASA message does 454 not indicate that all of the addresses being claimed are available, 455 the MAAS MUST cancel the Claim Timer and give up on the unavailable 456 addresses. This should not normally happen, since the MAAS should 457 have been aware of the set of available addresses before it sent out 458 the ACLM message and the set of available addresses should not change 459 in a way that invalidates outstanding claims. 461 If the Claim Timer expires, the MAAS can conclude that there is a 462 good probability that the addresses being claimed are unique. It 463 SHOULD then send an AIU message listing those addresses and add the 464 addresses to its list of allocated addresses. 466 4.2.4.1 Anticipatory Allocation 468 A MAAS may allocate addresses because they are needed to satisfy an 469 immediate demand or in anticipation of a future demand. Anticipatory 470 allocation can reduce the amount of time required for a MAAS to 471 respond to an allocation request. 473 However, MAAS's SHOULD be moderate in their anticipatory allocations, 474 especially those with distant end times. If a MAAS allocates one or 475 more addresses with a distant end time in anticipation of demand and 476 then the MAAS fails, other MAAS's will defend the allocation and the 477 address space will be effectively lost. 479 Preallocation is a better way to handle this problem, as well as 480 several others. 482 4.2.5 Preallocating Addresses using AITU 483 Preallocation (using the Address Intent To Use or AITU message) 484 allows a MAAS to indicate which addresses it intends to use in the 485 future. Other MAAS's will attempt to avoid using these addresses. 486 However, these addresses are not completely off-limits, as they would 487 be if the MAAS allocated them (using the AIU message). Other MAAS's 488 are free to allocate preallocated addresses if address space runs 489 low. 491 To preallocate an address, a MAAS selects one or more addresses and 492 an end time for the preallocation (using the techniques described in 493 section 4.2.6). It then sends these addresses in an AITU message. 494 After sending the AITU message, the MAAS SHOULD then set a 495 Preallocation Timer for [ANNOUNCE-WAIT] seconds in the future. 497 The AITU message SHOULD be resent with the same time intervals as an 498 AIU message - i.e. the interval between messages starts at [RESEND- 499 WAIT] seconds and doubles until it reaches [REPEAT-INTERVAL]. As 500 with an AIU message, the MAAS SHOULD vary the interval by about 30% 501 (+ or -) to avoid synchronization effects. 503 If the MAAS receives an ACLM, AITU, or AIU message from another MAAS 504 listing one or more of the addresses being preallocated before the 505 Preallocation Timer expires, this indicates a collision. It MUST 506 cancel the Preallocation Timer and give up on that preallocation. It 507 MAY choose another set of addresses, send another AITU message with 508 the same Request Sequence Number listing the new addresses, set a new 509 Preallocation Timer for [ANNOUNCE-WAIT] seconds in the future, and 510 begin resending the AITU message again. 512 If the MAAS receives an ASA message whose Expiration Time (after 513 adjusting for clock skew, as described in section 6.3.1) is newer 514 than the last ASA message processed and the newer ASA message does 515 not indicate that all of the addresses in the AITU message are 516 available, the MAAS MUST cancel the Preallocation Timer and give up 517 on the unavailable addresses. This should not normally happen, since 518 the MAAS should have been aware of the set of available addresses 519 before it sent out the AITU message and the set of available 520 addresses should not change in a way that invalidates outstanding 521 claims. 523 If the Preallocation Timer expires, the MAAS can conclude that there 524 is a good probability that there is no collision. It SHOULD continue 525 sending the AITU message listing these addresses and can add the 526 addresses to its list of preallocated addresses. 528 However, if the MAAS receives an AITU, ACLM, or AIU message from 529 another MAAS listing one or more of the preallocated addresses, the 530 MAAS MUST abandon the preallocation. Also, if the MAAS processes an 531 ASA message that does not indicate that all of the addresses in the 532 AITU message are available, the MAAS MUST abandon the preallocation. 534 4.2.5.1 Allocating a Preallocated Address 536 Once a set of addresses has been preallocated, there should not be 537 any collisions for those addresses. Therefore, the MAAS that 538 preallocated the addresses can skip the ACLM portion of the 539 allocation process and go directly to the normal process of sending 540 an AIU message. 542 To be explicit, when a MAAS that has preallocated some addresses 543 wants to allocate one or more of those addresses, it SHOULD send an 544 AIU message for the addresses, resend the AIU again after [RESEND- 545 WAIT] seconds, and again after a further [RESEND-WAIT]*2 seconds, 546 doubling each time until the interval reaches [REPEAT-INTERVAL] 547 seconds. 549 If the MAAS is allocating only a subset of the addresses that were 550 preallocated, it SHOULD continue sending the AITU message for the 551 remaining preallocated addresses. 553 4.2.5.2 Benefits of Preallocation 555 Preallocation has several benefits. First, it allows a MAAS to 556 respond to requests for addresses rapidly without requiring the MAAS 557 to allocate addresses in anticipation of demand (which uses up 558 address space needlessly). 560 Second, and most importantly, it provides some protection against 561 network partition. If MAAS's have preallocated addresses before a 562 network partition, they can satisfy allocation requests safely by 563 using those preallocated addresses. Other MAAS's will avoid using 564 those preallocated addresses because they heard the preallocation 565 announcement before the network partition. See section 4.2.9 for 566 limitations of this technique and more details about handling network 567 partition. 569 4.2.6 Selecting Addresses for Allocation or Preallocation 571 The first step in allocating or preallocating addresses is to select 572 the addresses to use. 574 The first selection criterion SHOULD be to favor addresses that have 575 not been allocated or preallocated by any other MAAS. This can be 576 determined by consulting the Allocation Record, including the set of 577 addresses advertised in the most recent ASA message. 579 If there are no more addresses that have not been allocated or 580 preallocated by any other MAAS, then preallocation MUST NOT be done. 581 However, allocation (using ACLM) is allowed. For allocation, the next 582 choice SHOULD be addresses that have been preallocated and where the 583 preallocation has been announced recently. After that SHOULD come 584 addresses that have been preallocated and where the preallocation has 585 not been announced recently. 587 The rationale for this preference is that with addresses that have 588 been preannounced recently, the MAAS that preallocated them will 589 probably be able to hear the ACLM messages and stop preallocating the 590 addresses. With addresses that have not been preannounced recently, 591 the MAAS that preallocated them may not be able to hear the ACLM 592 messages (due to network partition or other failure) and may then 593 proceed to allocate them, causing a collision. 595 A further criterion that SHOULD be applied if the first criterion 596 provides several options is that a MAAS SHOULD choose addresses from 597 an address range whose end time is the shortest that will satisfy the 598 requirements of the MAAS. 600 If several options are still available, the MAAS SHOULD favor 601 addresses which are adjacent to other addresses already allocated by 602 the MAAS. This will allow the MAAS to avoid increasing the size of 603 its AIU messages. And if there are still several options available, 604 the MAAS SHOULD favor addresses that are far from addresses allocated 605 by other MAAS's. This will make it more likely that this MAAS and the 606 other MAAS's will be able to add adjacent addresses to their 607 allocations in the future. 609 4.2.7 Choosing an End Time for Allocation or Preallocation 611 When allocating or preallocating an address, a MAAS chooses an end 612 time and includes this end time in the ACLM, AIU, or AITU messages 613 that it sends. This is the time until which the addresses should be 614 allocated (or preallocated). After this time, they may be removed 615 from the Allocation Records of other MAAS's in the domain. 617 The allocating MAAS can choose this end time in any way it likes, as 618 long as the end time does not exceed the lifetime listed for that 619 address in the ASA message. In order to avoid excess traffic, MAAS's 620 SHOULD NOT use many short-lived allocations. Instead, they should use 621 a few long-lived allocations and reuse those addresses. This also has 622 the benefit of ensuring that if the network is partitioned, 623 allocations for MAAS's on one side of the partition will not time out 624 of the Allocation Records of MAAS's on the other side of the 625 partition. 627 A MAAS can change the end time for an allocated or preallocated 628 address at any time by changing it in the AIU or AITU message for 629 that address. This technique can be used to extend an allocation or 630 to shorten it. By reducing the end time to a time a few minutes after 631 the current time, the allocation is effectively deleted. 633 Note that if some MAAS's are partitioned from the network during the 634 time when this deletion is being announced, they may defend the 635 earlier allocation when they are later reconnected. In this case, the 636 MAAS that deleted the allocation SHOULD advertise the allocation 637 again with the correct end time (now in the past) so that it is 638 deleted from the Allocation Records of the MAAS's that were 639 partitioned. 641 No start time is included in any AAP messages because all allocations 642 start immediately. It is too difficult to manage two MAAS's with 643 allocations for the same address at different times. However, a 644 single MAAS can reuse an address for multiple clients over time. 646 4.2.8 Allocation Failure 648 If no addresses are available that meet the demands placed on the 649 MAAS (either because there are no addresses available at all or 650 because the lifetimes of the available addresses are not long 651 enough), the MAAS should indicate this by sending an Address Not 652 Available (ANA) message. This will allow other MAAS's to note the 653 allocation failure and report it to the Prefix Coordinator in the 654 next ASRP message. The Prefix Coordinator may, in response, attempt 655 to allocate more addresses or get a longer lifetime. 657 Since small scopes do not have Prefix Coordinators, MAAS's MUST NOT 658 send ANA messages for small scopes. Instead, they MAY log the failed 659 allocation so that the administrator can increase the number of 660 addresses in the scope. 662 An ANA message contains an address count and a requested lifetime. 663 When an allocation fails, the MAAS SHOULD assemble and send an ANA 664 message. After sending the ANA message, the MAAS SHOULD set an ANA 665 Retransmission Timer for [ANNOUNCE-WAIT] seconds in the future. The 666 MAAS SHOULD also resend the ANA message after [RESEND-WAIT] seconds, 667 and again after a further [RESEND-WAIT]*2 seconds, doubling each time 668 until the ANA Retransmission Timer expires. 670 A MAAS that receives an ANA message SHOULD check to see if it already 671 has noted this address request in its Allocation Record (by comparing 672 the number of addresses, lifetime, and Request Sequence number). If 673 not, it SHOULD add the request. 675 Because ANA messages are not repeated indefinitely, each MAAS may 676 have a different set of address requests in its Allocation Record. 677 This is normal and should not cause a problem. 679 4.2.9 Network Partition 681 The AAP protocol is designed to continue functioning properly in 682 spite of short-term network partitions or server failures. 684 However, certain steps should be taken to ensure optimal robustness. 685 First, MAAS's SHOULD preallocate enough addresses to last through a 686 short-term network partition (1 hour is a reasonable default). 687 Second, if the network is partitioned, no new MAAS's should be added 688 during the partition. Otherwise, the new MAAS's will not know about 689 addresses preallocated by MAAS's separated from them by the network 690 partition. 692 The failure of one or more MAAS's should not cause significant 693 problems. Other MAAS's will defend the allocations of the failed 694 MAAS's until their end time. After that, the allocations will be 695 deleted. 697 The failure of one or more Prefix Coordinators is also accomodated. 698 If another Prefix Coordinator is still around, it will pick up the 699 duties of the failed Prefix Coordinator. If no Prefix Coordinators 700 are working, the MAAS's will resend the latest ASA message until the 701 Prefix Coordinators are working again. In this circumstance, the 702 system should continue to work until the address lifetimes listed in 703 the ASA message expire. 705 4.2.10 Interacting with Prefix Coordinators 707 In "large" scopes, one or more Prefix Coordinators handle the 708 interaction between MAAS's within the allocation domain and those in 709 other allocation domains within the scope. In particular, the Prefix 710 Coordinators periodically announce the set of multicast addresses 711 available for allocation within the domain using the Address Space 712 Announce (ASA) message. And MAAS's periodically inform the Prefix 713 Coordinators of how much address space is currently in use, using the 714 Address Space Report (ASRP) message. 716 Prefix Coordinators (along with the ASA and ASRP messages) are not 717 needed or used in small scopes. In a small scope, the complete set 718 of addresses in the scope (as indicated by MZAP) is considered to be 719 available for use within the allocation domain, for an indefinite 720 lifetime. 722 4.2.10.1 Processing ASA Messages 723 The ASA message lists a number of address ranges, each of which has 724 an associated lifetime. The announcement also contains a timestamp to 725 detect replays or clock skew and an expiration time. Each ASA 726 message MUST contain the complete set of addresses available for a 727 given scope in the allocation domain at the time the message was 728 sent. A Prefix Coordinator MUST NOT attempt to split the available 729 addresses across multiple ASA messages. As described in section 730 4.2.11, each ASA message MUST pertain only to one scope and each MAAS 731 (and Prefix Coordinator) MUST treat each scope separately. 733 When an ASA message is received, a MAAS SHOULD adjust the Expiration 734 Time for clock skew as described in section 6.3.1 and compare it to 735 the adjusted Expiration Time of the last ASA message processed. If 736 the adjusted Expiration Time of the newly received ASA message is 737 earlier than or equal to the adjusted Expiration Time of the last ASA 738 message processed, the newly received ASA message SHOULD be ignored. 739 Otherwise, it SHOULD be processed. 741 Under normal circumstances, the set of addresses available in the 742 allocation domain should change in only three ways. First, addresses 743 can be removed once they have reached the end of their lifetime. 744 Second, the lifetime of one or more addresses can be extended. Third, 745 new addresses can be added. Any other change in the set of available 746 addresses (removing addresses, moving their start time later, or 747 making their end time earlier) is called an invalidating change, 748 since it may invalidate MAAS allocations and therefore SHOULD be 749 strongly avoided. 751 If an ASA message being processed does not contain any invalidating 752 changes (as determined by comparing it to the last ASA message 753 processed), it can be processed by updating the set of available 754 addresses in the Allocation Record (and caching the UDP payload of 755 the ASA message, as described later). If the ASA message extends the 756 lifetime of one or more addresses or adds new addresses, any 757 outstanding address requests in the Allocation Record SHOULD be 758 checked to see if they have been satisfied. If so, they SHOULD be 759 removed from the Allocation Record. 761 It may sometimes be necessary to make an invalidating change. If a 762 MAAS detects such a change, it should revise all allocations and 763 preallocations in its Allocation Record to conform with the change. 764 Actually, it need not revise its Allocation Record, but SHOULD behave 765 within AAP as if it has done so. The MAAS or its clients SHOULD also 766 stop using the invalidated addresses in any way which conflicts with 767 their revised status as soon as possible. If a MAAS detects an 768 invalidating change, it MAY log a message or otherwise alert an 769 administrator. An invalidating change is an unusual and highly 770 undesirable situation. 772 ASA messages MAY alternate between several cooperating Prefix 773 Coordinators. One common reason for invalidating changes is when an 774 allocation domain has two Prefix Coordinators whose actions are not 775 coordinated. This is a serious error that may make it nearly 776 impossible for MAAS's to allocate new addresses so this situation 777 should be remedied as soon as possible. 779 To prevent hostile parties from causing a denial of service by 780 sending invalidating ASA messages, ASA messages SHOULD be 781 authenticated and MAAS's SHOULD ignore unauthenticated ASA messages. 782 See section 7 (Security Considerations) for more information. 784 4.2.10.2 Resending ASA Messages 786 All ASA messages include an Expiration Time. Normally, the Expiration 787 Time is set so that several newer ASA messages will have been sent 788 before an ASA message expires. If an ASA message expires in a MAAS's 789 Allocation Record (that is, no newer ASA messages have been received 790 at the Expiration Time) and the MAAS is not in startup mode, 791 something has gone wrong. Either the Prefix Coordinator has stopped 792 sending ASA messages or they are being lost. 794 Under such a circumstance, a MAAS MAY log an error or notify an 795 operator. However, the MAAS SHOULD continue to work, using the 796 information in the old ASA until the address lifetimes are exceeded. 797 The MAAS SHOULD also resend the information included in the old ASA, 798 as described in the next paragraph. This allows new MAAS's to find 799 out what addresses are available for allocation. It also allows a 800 Prefix Coordinator to recover this information if it has lost it (by 801 losing its stable storage or simply rebooting, if it does not have 802 stable storage) and it cannot recover it via another mechanism (from 803 its MASC peers, for instance). 805 When an ASA message expires, each MAAS SHOULD choose a random number 806 between [ASA-INTERVAL]*0.7 and [ASA-INTERVAL]*1.3. It should set an 807 ASA Resend timer for a time this far in the future. If the timer 808 expires without an ASA message arriving, the MAAS SHOULD send an ASA 809 message with the same contents as the expired ASA message, but with 810 the Current Time field incremented by the amount of time passed since 811 the expired ASA message was received. 813 Updating the Current Time field ensures that anyone who receives the 814 message will be able to adjust the times in the message properly to 815 compensate for clock skew (as described in section 6.3.1). It also 816 ensures that the Current Time will be greater than the Expiration 817 Time, which makes it evident that this is a retransmitted ASA 818 message. 820 If the MAAS receives an ASA with an Expiration Time that is newer 821 (after adjustment for clock skew) than the Expiration Time of the 822 cached message before the timer expires, it SHOULD discard the timer 823 and process the newer ASA message. 825 If, however, the MAAS receives an ASA message that does not have a 826 newer adjusted Expiration Time, the MAAS SHOULD simply reset the ASA 827 Resend timer to a new random number in the same range. 829 4.2.10.3 Sending ASRP Messages 831 Unless otherwise configured, all MAAS's SHOULD participate in sending 832 periodic ASRP messages to the AAP address (for large scopes). An 833 ASRP message lists the same address ranges included in the most 834 recent ASA message, along with the number of addresses used in each 835 range. It may also include a list of address requests, each of which 836 contains a number of addresses and a lifetime. As described in 837 section 4.2.11, each ASRP message MUST pertain only to one scope and 838 each MAAS (and Prefix Coordinator) MUST treat each scope separately. 840 Whenever a MAAS completes its [STARTUP-WAIT] period, it SHOULD choose 841 a random number between [ASRP-INTERVAL]*0.7 and [ASRP-INTERVAL]*1.3. 842 It should set an ASRP Send timer for a time this far in the future. 843 If the timer expires without an ASRP message for that scope being 844 received, the MAAS SHOULD send an ASRP message containing a summary 845 of current address space usage in the allocation domain for that 846 scope. If an ASRP message for that scope is received before the timer 847 expires, the MAAS SHOULD reset the ASRP Resend timer to a new random 848 number in the same range. 850 When sending an ASRP message, a MAAS should list each address range 851 included in the most recent ASA message, along with the number of 852 addresses used in each range (calculated by consulting the Allocation 853 Record). The address requests should be constructed based on the 854 address requests noted in the Allocation Record. These requests 855 SHOULD be combined to ensure that the UDP payload of the ASRP message 856 does not exceed 500 bytes. The address requests SHOULD be combined 857 by finding requests whose end times are similar, adding their counts, 858 and taking the earlier of the two start times. This (and other 859 effects) will cause changes in the address request list from one ASRP 860 message to another, but that is to be expected. 862 4.2.11 Handling Multiple Scopes 864 When a MAAS is handling multiple scopes at the same time, it should 865 treat each scope separately. With multiple large scopes which share a 866 single allocation domain and Allocation Scope, each AAP message MUST 867 pertain to only one scope, so that a MAAS that is not interested in a 868 particular scope can discard messages pertaining to other scopes. 870 5 Prefix Coordinators 872 A Prefix Coordinator is a host that announces the set of multicast 873 addresses available for use within an allocation domain. Prefix 874 Coordinators are not needed for "small" scopes, where all addresses 875 in the scope are available for use within the allocation domain. 877 The mechanism or protocol by which a Prefix Coordinator determines 878 the set of available addresses is not specified in this document. It 879 may use an inter-domain protocol such as MASC, static allocations by 880 AS number [9], or some other system. It makes no difference to AAP 881 or to the MAAS's. 883 5.1 Prefix Coordinator Requirements 885 Prefix Coordinators SHOULD listen to and participate in the AAP 886 protocol on a regular basis, in order to send ASA messages and 887 receive ASRP messages. However, if a Prefix Coordinator is 888 temporarily unable to participate in the AAP protocol, MAAS's within 889 the allocation domain will step in and send ASA messages on its 890 behalf. 892 This ASA resend feature may also be used to restore the state of a 893 Prefix Coordinator which has lost its state. Therefore, Prefix 894 Coordinators need not have stable storage. If their state is lost 895 (during a power failure, for instance), they can use the information 896 in the ASA messages resent by MAAS's to restore their state. 898 However, a prolonged outage on the part of a Prefix Coordinator will 899 result in the expiration of the prefix lifetimes advertised by the 900 Prefix Coordinator in its ASA message. And an inoperative Prefix 901 Coordinator will not be able to respond to changes in demand, as 902 reported by MAAS's using ASRP messages. Therefore, it is best for a 903 Prefix Coordinator to be functioning at all times. 905 A Prefix Coordinator can be a MASC router or another host. But it 906 should be located on a machine with sufficient processing power and 907 network connectivity to participate in the AAP protocol. 909 5.2 Specification of Prefix Coordinator Behavior 911 The primary function of a Prefix Coordinator is to announce the set 912 of multicast addresses available for use within an allocation domain. 913 It is also responsible for accepting feedback from MAAS's regarding 914 demand for addresses. 916 5.2.1 Sending ASA Messages 918 The ASA message lists a number of address ranges, each of which has 919 an associated lifetime. The announcement also contains a timestamp to 920 detect replays or clock skew and an expiration time. Each ASA 921 message MUST contain the complete set of addresses available for a 922 given scope in the allocation domain at the time the message was 923 sent. A Prefix Coordinator MUST NOT attempt to split the available 924 addresses across multiple ASA messages. As described in section 925 5.2.3, each ASA message MUST pertain only to one scope and each MAAS 926 (and Prefix Coordinator) MUST treat each scope separately. 928 When a Prefix Coordinator is ready to begin announcing addresses in 929 an allocation domain, the Prefix Coordinator SHOULD choose a random 930 number between [ASA-INTERVAL]*1.7 and [ASA-INTERVAL]*2.3. It should 931 set an ASA Send timer for a time this far in the future. If the timer 932 expires without a new (not resent) ASA message arriving, the Prefix 933 Coordinator SHOULD send an ASA message and reset the timer to a new 934 random number between [ASA-INTERVAL]*0.7 and [ASA-INTERVAL]*1.3. A 935 Prefix Coordinator can identify a resent ASA message by checking the 936 Expiration Time in the message. If the Expiration Time exceeds the 937 Current Time in the message, the message has been resent by a MAAS. 939 If a Prefix Coordinator receives a new (not resent) ASA message 940 before the timer expires, it should reset the timer to a new random 941 number between [ASA-INTERVAL]*1.7 and [ASA-INTERVAL]*2.3. If more 942 than one Prefix Coordinator is operating within a domain, this timer 943 mechanism should encourage one of the Prefix Coordinators (the "lead 944 Prefix Coordinator") to take the lead, consistently sending ASA 945 messages. However, if that Prefix Coordinator stops working (due to 946 failure or network partition), another Prefix Coordinator will step 947 in to take its place. The timers used by a Prefix Coordinator MAY be 948 reduced to ensure that it will become the lead Prefix Coordinator. 950 5.2.1.1 Avoiding Invalidating Changes 952 Under normal circumstances, the set of addresses available in the 953 allocation domain should change in only three ways. First, addresses 954 can be removed once they have reached the end of their lifetime. 955 Second, the lifetime of one or more addresses can be extended. Third, 956 new addresses can be added. Any other change in the set of available 957 addresses (removing addresses, moving their start time later, or 958 making their end time earlier) is called an invalidating change, 959 since it may invalidate MAAS allocations and therefore SHOULD be 960 strongly avoided. 962 One common reason for invalidating changes is when an allocation 963 domain has two Prefix Coordinators which are announcing different 964 sets of available addresses. This is a serious error that may make 965 it nearly impossible for MAAS's to allocate new addresses so this 966 situation should be remedied as soon as possible. 968 If more than one Prefix Coordinator is active within a single 969 allocation domain, the Prefix Coordinators MUST be configured so that 970 their actions are coordinated. They MUST NOT announce different sets 971 of addresses. To detect and correct such a situation, a Prefix 972 Coordinator that detects ASA messages from another Prefix Coordinator 973 that are not consistent with its own SHOULD notify an operator and 974 stop sending ASA messages until it has not heard a new (not resent) 975 inconsistent ASA message for at least [ASA-INTERVAL]*5 seconds. This 976 default behavior may be overridden by configuration. 978 This behavior allows a malicious person to send invalid ASA messages, 979 confusing the MAAS's and keeping the valid Prefix Coordinator from 980 sending ASA messages. The best solution for this problem is for 981 MAAS's and Prefix Coordinators to ignore messages unless they are 982 authenticated. Then the invalid ASA messages will be ignored. Even 983 without authentication, the valid Prefix Coordinator will notify the 984 operator of the problem and the MAAS's MAY log an error or alert an 985 administrator when they see an invalidating change. 987 5.2.2 Processing ASRP Messages 989 Prefix Coordinators SHOULD (unless otherwise configured) listen for 990 and process ASRP messages. ASRP messages are sent periodically by 991 MAAS's and are intended to report address space usage to Prefix 992 Coordinators. 994 When a MAAS sends an ASRP message, it includes the address ranges it 995 received in the ASA message it processed most recently, along with 996 the number of addresses used in each range. It may also include a 997 list of address requests, each of which contains a number of 998 addresses and a lifetime. As described in section 4.2.11, each ASRP 999 message MUST pertain only to one scope and each MAAS (and Prefix 1000 Coordinator) MUST treat each scope separately. 1002 When a Prefix Coordinator receives an ASRP message, it SHOULD ignore 1003 the message unless it is the lead Prefix Coordinator (unless 1004 otherwise configured). If the Prefix Coordinator is the lead Prefix 1005 Coordinator, it SHOULD first check to see whether the address ranges 1006 included in the ASRP message match the address ranges that it has 1007 most recently announced. If the address ranges do not match, it 1008 SHOULD ignore the ASRP message and MAY log a message. 1010 Otherwise, the Prefix Coordinator MAY process the data included in 1011 the ASRP message in whatever way it deems appropriate. The algorithm 1012 used by the Prefix Coordinator to decide what actions to take, if 1013 any, and the mechanism or protocol used to effect these actions are 1014 beyond the scope of this document. However, with MASC the actions 1015 might include a request for more addresses and with a static 1016 allocation mechanism the actions might include a notice to an 1017 operator that more (or fewer) addresses are needed. Taking no action 1018 at all is also acceptable. 1020 In general, it is expected that the goals of the Prefix Coordinator 1021 in responding to ASRP messages may be as follows. If it notices that 1022 there is a growing demand for addresses, it may attempt to allocate 1023 more addresses via a higher-level mechanism. If it notices a 1024 diminishing demand, it may choose not to extend the lifetime of 1025 certain addresses. It may also choose to allocate addresses to 1026 respond directly to the list of address requests included in the ASRP 1027 message, although this is intended more as an indication of emergent 1028 demand than a specific request for addresses. 1030 5.2.3 Handling Multiple Scopes 1032 When a Prefix Coordinator is handling multiple scopes at the same 1033 time, it should treat each scope separately. With multiple large 1034 scopes which share a single allocation domain and Allocation Scope, 1035 each AAP message MUST pertain to only one scope, so that a MAAS that 1036 is not interested in a particular scope can discard messages 1037 pertaining to other scopes. 1039 6 Protocol Details 1041 This section describes the message formats and specifics of message 1042 processing. 1044 6.1 Message Formats 1046 AAP messages are binary format, as the additional flexibility of 1047 having a textual format is not required in this case. 1049 All AAP messages start with a common header, followed by a body whose 1050 format differs depending on the message type. Figure 1 shows the 1051 format of the header and Table 1 describes each of the fields in the 1052 header. The numbers in parentheses indicate the size of each field in 1053 octets. The names for the fields given in the figure are used 1054 throughout this document to refer to the fields in AAP messages. 1056 All multi-octet quantities are in network byte-order. 1058 Any message whose UDP data is too short to hold this format (at least 1059 12 bytes) MUST be ignored. 1061 +-+-+-+-+-+-+-+-+ 1062 | version (1) | 1063 +---------------+ 1064 | msgtype (1) | 1065 +---------------+ 1066 | addrfamily | 1067 | (2) | 1068 +---------------+ 1069 | rseq | 1070 | (3) | 1071 | | 1072 +---------------+ 1073 | mseq (1) | 1074 +---------------+ 1075 | | 1076 | body | 1077 | (variable) | 1078 | ... | 1079 +---------------+ 1081 Figure 1: Format of an AAP message 1083 FIELD OCTETS DESCRIPTION 1084 ----- ------ ----------- 1086 version 1 Protocol version number (zero for this specification) 1087 msgtype 1 Message type (ACLM, AIU, etc.) 1088 addrfamily 2 Address family (IPv4, IPv6, etc.) 1089 rseq 3 Request sequence number 1090 mseq 1 Message sequence number 1091 body var Body (format varies by msgtype) 1093 Table 1: Description of fields in an AAP message 1095 6.1.1 The version field 1097 The version field MUST always be zero for this version of the 1098 protocol. Any messages that include other values in this field MUST 1099 be ignored. 1101 6.1.2 The msgtype field 1103 The msgtype field defines the "type" of a MADCAP message. 1105 For more information about this field, see section 6.2. 1107 6.1.3 The addrfamily field 1108 The addrfamily field defines the default address family (such as IPv4 1109 or IPv6) for this AAP message, using the address family numbers 1110 defined in by the IANA (including those defined in [10]). Unless 1111 otherwise specified, all addresses included in the message will be 1112 from this family. 1114 6.1.4 The rseq field 1116 The rseq field is a Request Sequence Number. The first message that a 1117 MAAS or Prefix Coordinator sends after a restart should have a 1118 request sequence number of 0 and the request sequence number should 1119 be incremented for every subsequent distinct message or request. When 1120 an AITU or ACLM message results in a detected clash, a new address is 1121 chosen and an new message is sent with the same rseq as the original. 1122 In such cases, the message sequence number (mseq) is incremented 1123 instead. AIU messages always get new RSEQ if the addresses in use 1124 change, otherwise MSEQ is incremented instead. ASA messages always 1125 get a new RSEQ because they may alternate sender between multiple 1126 Prefix Coordinators. 1128 At peak usage rates of one request per second, it is possible for the 1129 RSEQ space to wrap about every 6 months. It is unlikely that any 1130 message sequence will last this long, but it conceivable that an AITU 1131 message sequence might do so. Implementors should be aware of this 1132 possibility and avoid reusing the RSEQ value that is in use. 1134 6.1.5 The mseq field 1136 The mseq field is a message sequence number that is used to identify 1137 different messages of the same request. For example, if a MAAS sends 1138 a new ACLM message with RSEQ=27, MSEQ=0, and receives an AIU message 1139 from another MAAS for the same address, it then chooses a new address 1140 and sends a new ACLM message with RSEQ=27, MSEQ=1. This may be 1141 resent after [RESEND-WAIT] seconds with RSEQ=27, MSEQ=2, after 1142 [RESEND-WAIT]*2 seconds with RSEQ=27, MSEQ=3, etc. After [ANNOUNCE- 1143 WAIT] seconds, the MAAS can send an AIU message for the address with 1144 RSEQ=28, MSEQ=0. 1146 MSEQ may wrap when AITU is sent for longer than about 2 hours (with 1147 default timer values) without an address being requested. This 1148 should not cause a problem, but if MSEQ and RSEQ are being used to 1149 monitor loss, this should be taken into account. 1151 MSEQ may also wrap if a long serious of address collisions occurs 1152 when sending ACLM. Under normal circumstances, this is extremely 1153 unlikely and probably signals a denial-of-service attack. 1154 Implementors should be aware of this possibility. 1156 6.1.6 The body field 1158 The format of the body field varies, depending on the value of the 1159 msgtype field. For more information, see section 6.4. 1161 6.2. Message Types 1163 The msgtype field defines the type of an AAP message. Legal values 1164 for this field are: 1166 Value Message Type 1167 ----- ------------ 1168 0 Address Claim (ACLM) 1169 1 Address In Use (AIU) 1170 2 Address Intent To Use (AITU) 1171 3 Address Space Announce (ASA) 1172 4 Address Space Report (ASRP) 1173 5 Address Not Available (ANA) 1175 Table 2: AAP message types 1177 Throughout this document, AAP messages are referred to by the type of 1178 the message; e.g., an AAP message with a message type of 1 is 1179 referred to as an AIU message. 1181 MAAS's and Prefix Coordinators MUST handle all AAP message types 1182 defined in this document in a manner consistent with this document. 1183 If a MAAS or Prefix Coordinator receives an AAP message whose message 1184 type it does not recognize, it MUST ignore the message. 1186 New AAP message types may only be defined by IETF Consensus, as 1187 described in section 7. 1189 For a brief description of the AAP message types, see section 2. For 1190 a description of how each message should be handled by MAAS's and 1191 Prefix Coordinators, see sections 4 and 5. And for a description of 1192 the format of the message body for each message type, see section 1193 6.4. 1195 6.3 AAP Time Fields 1197 AAP messages contain a number of places where absolute times must be 1198 represented. These time values are represented as unsigned 32 bit 1199 integers in network byte order giving the number of seconds since 1200 00:00 UTC, 1st January 1970. This arbitrary baseline is convenient on 1201 many current operating systems and can be converted to an NTP [13] 1202 timestamp by adding decimal 2208988800. Thus AAP time fields will not 1203 wrap until the year 2106. 1205 6.3.1 Correcting for Clock Skew 1207 All AAP messages that include an absolute time field also include a 1208 Current Time field. This field SHOULD be used to detect and correct 1209 for clock skew. The sender SHOULD set the Current Time field to the 1210 time when the message is sent (as indicated by the sender's clock). 1211 The receiver SHOULD determine the difference between the Current Time 1212 indicated in the message and the time when the message is received 1213 (as indicated by the receiver's clock). Then it SHOULD add this 1214 difference to all times in the AAP message. 1216 This will adjust the times to compensate for any clock skew between 1217 the sender and the receiver. Unfortunately, it will also cause times 1218 in the messages to drift backward due to message transmission time. 1219 However, this drift should not accumulate under normal circumstances. 1220 A few seconds' drift should not cause any problems with multicast 1221 address allocation, since MAAS's should be allowing minutes or hours 1222 of buffer time between allocations, anyway. 1224 See Appendix A for an example of correcting for clock skew. 1226 6.4 Body Formats 1228 The format of the AAP message body depends on the value of the 1229 msgtype field. Here is a description of the body formats associated 1230 with all message types defined in this document. 1232 6.4.1 Address Claim (ACLM) 1234 The Address Claim (ACLM) message is used by a MAAS to announce 1235 addresses that it wants to allocate. 1237 Current Time Range 1 Range 2 ... 1238 +----+----+----+----+----...----+----...----+----...----+ 1239 | current-time | R1 | R2 | | 1240 +----+----+----+----+----...----+----...----+----...----+ 1242 where each of the Ranges is of the following format: 1244 First Last 1245 Address Address End Time 1246 +----...----+----...----+----+----+----+----+ 1247 | first | last | end-time | 1248 +----...----+----...----+----+----+----+----+ 1250 current-time is the current time at the sending MAAS. 1252 first and last are the first and last address in the range of 1253 addresses being claimed. The address family of the addresses is 1254 determined by the addrfamily field in the message header. 1256 end-time is the time when the sending MAAS plans to stop using the 1257 addresses. 1259 6.4.2 Address In Use (AIU) 1261 The Address In Use (AIU) message is used by a MAAS to announce 1262 addresses that it has allocated. 1264 Current Time Range 1 Range 2 ... 1265 +----+----+----+----+----...----+----...----+----...----+ 1266 | current-time | R1 | R2 | | 1267 +----+----+----+----+----...----+----...----+----...----+ 1269 where each of the Ranges is of the following format: 1271 First Last 1272 Address Address End Time 1273 +----...----+----...----+----+----+----+----+ 1274 | first | last | end-time | 1275 +----...----+----...----+----+----+----+----+ 1277 current-time is the current time at the sending MAAS. 1279 first and last are the first and last address in the range of 1280 allocated addresses. The address family of the addresses is 1281 determined by the addrfamily field in the message header. 1283 end-time is the time when the sending MAAS plans to stop using the 1284 addresses. 1286 6.4.3 Address Intent To Use (AITU) 1288 The Address Intent To Use (AITU) message is used by a MAAS to 1289 announce addresses that wishes to preallocate. 1291 Current Time Range 1 Range 2 ... 1292 +----+----+----+----+----...----+----...----+----...----+ 1293 | current-time | R1 | R2 | | 1294 +----+----+----+----+----...----+----...----+----...----+ 1295 where each of the Ranges is of the following format: 1297 First Last 1298 Address Address End Time 1299 +----...----+----...----+----+----+----+----+ 1300 | first | last | end-time | 1301 +----...----+----...----+----+----+----+----+ 1303 current-time is the current time at the sending MAAS. 1305 first and last are the first and last address in the range of 1306 addresses being preallocated. The address family of the addresses is 1307 determined by the addrfamily field in the message header. 1309 end-time is the time when the sending MAAS plans to stop using the 1310 addresses. 1312 6.4.4 Address Space Announce (ASA) 1314 The Address Space Announce (ASA) message is used by a Prefix 1315 Coordinator to announce the set of multicast addresses and lifetimes 1316 available for allocation within the domain using the Address Space 1317 Announce (ASA) message. 1319 Current Time Expiration Time Range 1 Range 2 ... 1320 +---+---+---+---+---+---+---+---+---...---+---...---+---...---+ 1321 | current-time |expiration-time| R1 | R2 | | 1322 +---+---+---+---+---+---+---+---+---...---+---...---+---...---+ 1324 where each of the Ranges is of the following format: 1326 First Last 1327 Address Address End Time 1328 +----...----+----...----+----+----+----+----+ 1329 | first | last | end-time | 1330 +----...----+----...----+----+----+----+----+ 1332 current-time is the current time at the sending Prefix Coordinator. 1334 expiration-time is the time at which MAAS's should start resending 1335 this ASA message. 1337 first and last are the first and last address in the range of 1338 addresses. The address family of the addresses is determined by the 1339 addrfamily field in the message header. 1341 end-time is the time until which the addresses are available for 1342 allocation. 1344 6.4.5 Address Space Report (ASRP) 1346 The Address Space Report (ASRP) message is sent by a MAAS to indicate 1347 to the Prefix Coordinator(s) how much of the current address space is 1348 in use and to request more address space. 1350 Current Time Report List Request List 1351 +----+----+----+----+----...----+----...----+ 1352 | current-time | reports | requests | 1353 +----+----+----+----+----...----+----...----+ 1355 where the Report List is a single octet count of reports, followed by 1356 the reports: 1358 Report 1359 Count Report 1 Report n 1360 +-----+----...----+----...----+----...----+ 1361 | n | report-1 | | report-n | 1362 +-----+----...----+----...----+----...----+ 1364 and each Report is of the following form: 1366 First Last Number of 1367 Address Address Addresses In Use 1368 +----...----+----...----+----+----+----+----+ 1369 | first | last | in-use-count | 1370 +----...----+----...----+----+----+----+----+ 1372 and the Request List is a single octet count of requests, followed by 1373 the requests: 1375 Request 1376 Count Request 1 Request m 1377 +-----+----...----+----...----+----...----+ 1378 | m | request-1 | | request-m | 1379 +-----+----...----+----...----+----...----+ 1381 and each Request is of the following form: 1383 Number of Addresses End Time 1384 Requested Requested 1385 +----+----+----+----+----+----+----+----+ 1386 | addrs-requested | end-time-requested| 1387 +----+----+----+----+----+----+----+----+ 1389 current-time is the current time at the sending MAAS. 1391 n is a single octet count of address space reports, one for each 1392 address range listed in the most recent ASA message processed. 1394 first and last are the first and last address in the range of 1395 addresses. The address family of the addresses is determined by the 1396 addrfamily field in the message header. 1398 in-use-count is an unsigned four-octet number indicating the number 1399 of addresses in use in the range. If the number of addresses in use 1400 exceeds 0xfffffffe, then 0xffffffff is sent. 1402 m is a single octet count of address space requests. 1404 addrs-requested is an unsigned four-octet number indicating the 1405 number of addresses requested. 1407 end-time-requested is the time until which the addresses are desired 1408 to be available for allocation. 1410 6.4.6 Address Not Available (ANA) 1412 The Address Not Available (ANA) message is sent by a MAAS to indicate 1413 that no addresses are available that meet its needs. 1415 Current Time Address Count End Time 1416 +----+----+----+----+----+----+----+----+----+----+----+----+ 1417 | current-time | address-count | end-time | 1418 +----+----+----+----+----+----+----+----+----+----+----+----+ 1420 current-time is the current time at the sending MAAS. 1422 address-count is an unsigned four-octet number indicating the number 1423 of addresses needed to satisfy the MAAS's needs. 1425 end-time is the time until which the addresses are needed. 1427 7 Security Considerations 1429 Most attacks on AAP depend on being able to send a message that will 1430 be accepted by MAAS's and Prefix Coordinators as valid. 1432 A malicious party could send a false ASA message indicating that no 1433 addresses are available. This would cause MAAS's to stop allocating 1434 addresses (although they could continue to use addresses that they 1435 had already allocated). A false ASA message could also encourage 1436 MAAS's to allocate addresses that are already in use in another 1437 domain or addresses that will not be routed out of the domain. 1439 Another attack is to send an AIU message indicating a conflict 1440 whenever a MAAS tries to claim or preallocate an address. This would 1441 prevent the MAAS from claiming or preallocating any addresses. 1443 One more attack is to send an ASRP message reporting great demand 1444 when there is little. This could cause the Prefix Coordinator to 1445 allocate addresses that are not needed. Alternatively, a false ASRP 1446 could report little usage and demand when in fact there is a lot of 1447 usage and demand. This could cause the Prefix Coordinator to allocate 1448 too few addresses. Both of these attacks would take a while to 1449 effect, since the Prefix Coordinator typically changes the set of 1450 addresses available for allocation only slowly in response to long- 1451 term trends in demand. 1453 Of course, there is no way in the current multicast routing protocols 1454 to prevent an unauthorized party from sending data on an arbitrary 1455 multicast address or joining an arbitrary multicast group. Therefore, 1456 the multicast address allocation architecture is currently advisory 1457 in nature. Still, it is desirable to design for the future. 1459 The best way to address these attacks is by authenticating AAP 1460 messages and ignoring unauthenticated messages. Therefore, it is 1461 RECOMMENDED that when security is deemed necessary for AAP, IPsec be 1462 used to authenticate AAP messages and that unauthenticated messages 1463 be ignored. 1465 As currently specified and implemented, IPsec does not include 1466 support for group key establishment. The Secure Multicast Research 1467 Group (SMuG) in the IRTF is working on group key establishment and 1468 management techniques, but these are not yet ready for 1469 standardization. Therefore, for the time being, manual keying will 1470 need to be employed to establish and maintain a shared group key. 1471 However, it is hoped that the work of the SMuG group will allow for 1472 easier key establishment techniques in the future. 1474 It should also be mentioned that use of a shared group key does not 1475 protect against malicious acts by group members. Because all group 1476 members share a single key, it is not possible to securely determine 1477 which member sent a given message. In general, this should not be a 1478 problem for AAP, since all MAAS's and Prefix Coordinators are 1479 generally considered equal peers. But in some environments, this 1480 might be useful. Using asymmetric (public key) encryption would make 1481 it possible to securely determine which member sent a given message, 1482 but would add greatly to the cost of verifying the authenticity of 1483 each message. The SMuG group is also working on techniques for 1484 securely identifying the sender of a multicast message with greater 1485 efficiency. When these techniques are standardized, it may be useful 1486 to apply them to AAP. 1488 Protecting the confidentiality of AAP messages is not usually 1489 considered an important goal. Although some information about current 1490 network activities could be derived from monitoring AAP traffic, the 1491 same information (or more) could be derived from simple traffic 1492 analysis (who's using which multicast groups). 1494 Integrity protection for AAP messages is important, but will be taken 1495 care of by the IPsec authentication described above. 1497 Replay detection in a multicast situation is difficult. Because a 1498 shared group key is employed, a per-sender sequence number is not 1499 practical. A clock may be used (and all AAP messages include such a 1500 clock), but synchronized clocks cannot be assumed and even with 1501 synchronized clocks, some leeway must be allowed for transmission 1502 delays. 1504 Fortunately, replay detection is not a requirement for AAP. Replay 1505 of AIU, ANA, AITU messages should not be a problem, since they are 1506 supposed to be persistent anyway. Replay of ACLM messages will not 1507 be harmful, since they will be rejected if they interfere with an 1508 existing allocation. Replay of ASA messages should not be very 1509 problematic, since any messages that are inconsistent with a Prefix 1510 Coordinator's own state will be reported by the Prefix Coordinator to 1511 an operator. And replay of ASRP messages will simply result in the 1512 Prefix Coordinator not responding to changes in demand (which is a 1513 permissible action for the Prefix Coordinator, anyway). 1515 Once efficient techniques for sender authentication in a group are 1516 developed, per-sender sequence numbers should be used for replay 1517 detection. 1519 8 IANA Considerations 1521 New AAP Message Types may only be defined by IETF Consensus, as 1522 described in [12]. Basically, this means that they are defined by 1523 RFCs approved by the IESG. 1525 9 Acknowledgments 1527 The authors would like to thank the participants of the IETF 1528 Multicast Address Allocation Working Group (malloc) and the IETF as a 1529 whole for their assistance with this protocol. 1531 10 References 1533 [1] Handley, M., D. Thaler, D. Estrin, "The Internet Multicast 1534 Address Allocation Architecture", Internet Draft, 1535 draft-ietf-malloc-arch-02.txt, July 1999. 1537 [2] Estrin, D., R. Govindan, M, Handley, S. Kumar, P. Radoslavov, 1538 D. Thaler, "The Multicast Address Set Claim (MASC) Protocol", 1539 Internet Draft, draft-ietf-malloc-masc-03.txt, August 1999. 1541 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1542 Levels", RFC 2119, March 1997. 1544 [4] Deering, S., "Host Extensions for IP Multicasting", RFC 1112, 1545 August 1989. 1547 [5] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 1548 Specification", RFC 2460, December 1998. 1550 [6] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", 1551 RFC 2373, July 1998. 1553 [7] Meyer, D., "Administratively Scoped IP Multicast", RFC 2365, 1554 July 1998. 1556 [8] Hanna, S., B. Patel, M. Shah, "Multicast Address Dynamic 1557 Client Allocation Protocol (MADCAP)", Internet Draft, 1558 draft-ietf-malloc-madcap-07.txt, September 1999. 1560 [9] Meyer, D., and P. Lothberg, "GLOP Addressing in 233/8", 1561 Internet Draft, draft-ietf-mboned-glop-addressing-00.txt, 1562 October 1999. 1564 [10] Handley, M., Thaler, D., and R. Kermode, "Multicast-Scope 1565 Zone Announcement Protocol (MZAP)", Internet Draft, 1566 draft-ietf-mboned-mzap-04.txt, June 1999. 1568 [11] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, 1569 October 1994. 1571 [12] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA 1572 Considerations Section in RFCs", RFC 2434, October 1998. 1574 [13] Mills, D., "Network Time Protocol (Version 3) Specification, 1575 Implementation and Analysis", RFC 1305, March 1992. 1577 11 Authors' Addresses 1579 Mark Handley 1580 AT&T Center for Internet Research at ISCI (ACIRI) 1581 1947 Center St., Suite 600 1582 Berkeley, CA 94704 1583 Email: mjh@aciri.org 1584 Stephen R. Hanna 1585 Sun Microsystems, Inc. 1586 One Network Drive 1587 Burlington, MA 01803 1588 Phone: +1.781.442.0166 1589 Email: steve.hanna@sun.com 1591 Appendix A: Examples 1593 This appendix will include several examples of typical AAP protocol 1594 exchanges. But it hasn't been written yet. 1596 Appendix B: Recommended Constant Values 1598 Table 3 lists recommended values for constants defined in this 1599 specification. 1601 Constant Name Recommended Value 1602 ------------- ----------------- 1603 [STARTUP-WAIT] 150 seconds 1604 [CLAIM-WAIT] 4 seconds 1605 [RESEND-WAIT] 1 second 1606 [REPEAT-INTERVAL] 30 seconds 1607 [ASA-INTERVAL] 30 seconds 1608 [ASRP-INTERVAL] 30 seconds 1610 Table 3: Recommended Constant Values 1612 Appendix C: Change Log 1614 Note to the RFC Editor: This section should be removed before 1615 publication. 1617 Changes since draft-ietf-malloc-aap-01.txt: 1619 * Complete rewrite. Many details filled in. * Use IPsec for 1620 security. * Added support for IPv6 addresses. * Added ANA message. 1622 Appendix D: Unresolved Issues 1624 Note to the RFC Editor: This section should be removed before 1625 publication. 1627 This appendix lists unresolved issues. Please send comments to the 1628 authors. 1630 Is Prefix Coordinator really the right name for the hosts that 1631 announces the set of multicast addresses available for use within an 1632 allocation domain? We don't require the addresses to be prefixes any 1633 more. Maybe they should be called Address Coordinators. Or Domain 1634 Address Coordinators. 1636 When a MAAS has just done a successful claim, is it really necessary 1637 to send AIU with an interval starting at [RESEND-INTERVAL]? We 1638 already did that with the ACLM! 1640 The old draft talked about MAAS's allocating from only one half of a 1641 prefix if utilization is low in that prefix. I don't see how that 1642 will work. There will probably be long-lived allocations all over the 1643 prefix. And I don't think it is needed. A Prefix Coordinator can just 1644 extend the lifetime of only part of the existing prefix. Or allocate 1645 a new, smaller set of addresses with a longer lifetime and let the 1646 old prefix expire. 1648 Should we add start times to the ASA message so that Prefix 1649 Coordinators can announce upcoming addresses? If so, should we let 1650 MAAS's allocate addresses before their start times? And should we add 1651 something to ASA that says "I'm working on these address requests, 1652 but these others are right out." That would give MAAS's a way to give 1653 feedback to their clients on address requests. I would be inclined to 1654 leave all of these things for the future, when they can be added (via 1655 new message types).