idnits 2.17.1 draft-ietf-malloc-arch-04.txt: ** The Abstract section seems to be numbered 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 an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. == There are 7 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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: Informational ---------------------------------------------------------------------------- == Unused Reference: '8' is defined on line 556, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-ietf-malloc-aap-02 == Outdated reference: A later version (-06) exists of draft-ietf-malloc-masc-03 ** Obsolete normative reference: RFC 1771 (ref. '8') (Obsoleted by RFC 4271) == Outdated reference: A later version (-06) exists of draft-ietf-mboned-mzap-04 ** Obsolete normative reference: RFC 1305 (ref. '13') (Obsoleted by RFC 5905) Summary: 7 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MALLOC Working Group D. Thaler 2 INTERNET-DRAFT Microsoft 3 January 13, 2000 M. Handley 4 Expires July 2000 ACIRI 5 Category: Informational D. Estrin 6 ISI 8 The Internet Multicast Address Allocation Architecture 9 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other 23 documents at any time. It is inappropriate to use Internet-Drafts 24 as reference material or to cite them other than as "work in 25 progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Copyright Notice 35 Copyright (C) The Internet Society (2000). All Rights Reserved. 37 Draft MALLOC Architecture January 2000 39 1. Abstract 41 This document proposes a multicast address allocation architecture 42 for the Internet. The architecture is modular with three layers, 43 comprising a host-server mechanism, an intra-domain server-server 44 coordination mechanism, and an inter-domain mechanism. 46 2. Introduction 48 This document proposes a multicast address allocation architecture 49 for the Internet, and is intended to be generic enough to apply to 50 both IPv4 and IPv6 environments. 52 As with unicast addresses, the usage of any given multicast 53 address is limited in two dimensions: 55 Lifetime: 56 An address has a start time and a (possibly infinite) end 57 time, between which it is valid. 59 Scope: 60 An address is valid over a specific area of the network. For 61 example, it may be globally valid and unique, or it may be a 62 private address which is valid only within a local area. 64 This architecture assumes that the primary scoping mechanism in 65 use is administrative scoping, as described in RFC 2365 [1]. 66 While solutions that work for TTL scoping are possible, they 67 introduce significant additional complication for address 68 allocation [2]. Moreover, TTL scoping is a poor solution for 69 multicast scope control, and our assumption is that usage of TTL 70 scoping will decline before this architecture is widely used. 72 3. Requirements 74 >From a design point of view, the important properties of multicast 75 allocation mechanisms are robustness, timeliness, low probability 76 of clashing allocations, and good address space utilization in 77 situations where space is scare. Where this interacts with 78 multicast routing, it is desirable for multicast addresses to be 79 allocated in a manner that aids aggregation of routing state. 81 Draft MALLOC Architecture January 2000 83 o Robustness/Availability 84 The robustness requirement is that an application requiring the 85 allocation of an address should always be able to obtain one, 86 even in the presence of other network failures. 88 o Timeliness 89 From a timeliness point of view, a short delay of up to a few 90 seconds is probably acceptable before the client is given an 91 address with reasonable confidence in its uniqueness. If the 92 session is defined in advance, the address should be allocated 93 as soon as possible, and should not wait until just before the 94 session starts. It is in some cases acceptable to change the 95 multicast addresses used by the session up until the time when 96 the session actually starts, but this should only be done when 97 it averts a significant problem such as an address clash that 98 was discovered after initial session definition. 100 o Low Probability of Clashes 101 A multicast address allocation scheme should always be able to 102 allocate an address that can be guaranteed not to clash with 103 that of another session. A top-down partitioning of the 104 address space would be required to completely guarantee that no 105 clashes would occur. 107 o Address Space Packing in Scarcity Situations 108 In situations where address space is scarce, simply 109 partitioning the address space would result in significant 110 fragmentation of the address space. This is because one 111 would need enough spare space in each address space partition 112 to give a reasonable degree of assurance that addresses could 113 still be allocated for a significant time in the event of a 114 network partition. In addition, providing backup allocation 115 servers in such a hierarchy, so that fail-over (including 116 partitioning of a server and its backup from each other) does 117 not cause collisions would add further to the address space 118 fragmentation. 120 Since guaranteeing no clashes in a robust manner requires 121 partitioning the address space, providing a hard guarantee 122 leads to inefficient address space usage. Hence, when address 123 space is scarce, it is difficult to achieve constant 124 availability and timeliness, guarantee no clashes, and achieve 125 good address space usage. As a result, we must prioritize 126 these properties. We believe that, when address space is 127 scarce, achieving good address space packing and constant 129 Draft MALLOC Architecture January 2000 131 availability are more important than guaranteeing that address 132 clashes never occur. What we aim for in these situations is a 133 very high probability that an address clash does not occur, but 134 we accept that there is a finite probability of this happening. 135 Should a clash occur (or should an application start using an 136 address it did not allocate, which may also lead to a clash), 137 either the clash can be detected and addresses changed, or 138 hosts receiving additional traffic can prune that traffic using 139 source-specific prunes available in IGMP version 3, and so we 140 do not believe that this is a disastrous situation. 142 In summary, tolerating the possibility of clashes is likely to 143 allow allocation of a very high proportion of the address space 144 in the presence of network conditions such as those observed in 145 [3]. We believe that we can get good packing and good 146 availability with good collision avoidance, while we would have 147 to compromise packing and availability significantly to avoid 148 all collisions. 150 Finally, in situations where address space is not scarce, such 151 as with IPv6, achieving good address space usage is less 152 important, and hence partitioning may potentially be used to 153 guarantee no collisions among hosts that use this architecture. 155 3.1. Address Dynamics 157 Multicast addresses may be allocated in any of three ways: 159 Static: 160 Statically allocated addresses are allocated by IANA for 161 specific protocols that require well-known addresses to work. 162 Examples of static addresses are 224.0.1.1 which is used for 163 the Network Time Protocol [13] and 224.2.127.255 which is 164 used for global scope multicast session announcements. 165 Applications that use multicast for bootstrap purposes should 166 not normally be given their own static multicast address, but 167 should bootstrap themselves using a well-known service 168 location address which can be used to announce the binding 169 between local services and multicast addresses. 171 Static addresses typically have a permanent lifetime, and a 172 scope defined by the scope range in which they reside. As 173 such, a static address is valid everywhere (although the set 174 of receivers may be different depending on location), and may 176 Draft MALLOC Architecture January 2000 178 be hard-coded into applications, devices, embedded systems, 179 etc. Static addresses are also useful for devices which 180 support sending but not receiving multicast IP datagrams 181 (Level 1 conformance as specified in RFC 1112 [7]), or even 182 are incapable of receiving any data at all, such as a 183 wireless broadcasting device. 185 Scope-relative: 186 RFC 2365 [1] reserves the highest 256 addresses in every 187 administrative scope range for relative assignments. 188 Relative assignments are made by IANA and consist of an 189 offset which is valid in every scope. Relative addresses are 190 reserved for infrastructure protocols which require an 191 address in every scope, and this offset may be hard-coded 192 into applications, devices, embedded systems, etc. Such 193 devices must have a way (e.g. via MZAP [9] or via MADCAP [4]) 194 to obtain the list of scopes in which they reside. 196 The offsets assigned typically have a permanent lifetime, and 197 are valid in every scope and location. Hence, the scope- 198 relative address in a given scope range has a lifetime equal 199 to that of the scope range in which it falls. 201 Dynamic: 202 For most purposes, the correct way to use multicast is to 203 obtain a dynamic multicast address. These addresses are 204 provided on demand and have a specific lifetime. An 205 application should request an address only for as long as it 206 expects to need the address. Under some circumstances, an 207 address will be granted for a period of time that is less 208 than the time that was requested. This will occur rarely if 209 the request is for a reasonable amount of time. Applications 210 should be prepared to cope with this when it occurs. 212 At any time during the lifetime of an existing address, 213 applications may also request an extension of the lifetime, 214 and such extensions will be granted when possible. When the 215 address extension is not granted, the application is expected 216 to request a new address to take over from the old address 217 when it expires, and to be able to cope with this situation 218 gracefully. As with unicast addresses, no guarantee of 219 reachability of an address is provided by the network once 220 the lifetime expires. 222 These restrictions on address lifetime are necessary to allow 224 Draft MALLOC Architecture January 2000 226 the address allocation architecture to be organized around 227 address usage patterns in a manner that ensures addresses are 228 aggregatable and multicast routing is reasonably close to 229 optimal. In contrast, statically allocated addresses may be 230 given sub-optimal routing. 232 4. Overview of the Architecture 234 The architecture is modular so that each layer may be used, 235 upgraded, or replaced independently of the others. Layering also 236 provides isolation, in that different mechanisms at the same layer 237 can be used by different organizations without adversely impacting 238 other layers. 240 There are three layers in this architecture (Figure 1). Note that 241 these layer numbers are different from the layer numbers in the 242 TCP/IP stack, which describe the path of data packets. 244 +--------------------------+ +------------------------+ 245 | | | | 246 | to other peers | | to other peers | 247 | || // | | || // || | 248 | Prefix | | Prefix Prefix | 249 | Coordinator | |Coordinator Coordinator| 250 +------------||------------+ +-------||----//---------+ 251 ||Layer 3 || // 252 +------------||------------------------------||--//-----------+ 253 | Prefix Prefix | 254 | Coordinator=======================Coordinator | 255 | ^ ^ | 256 | +----------------+-------------+ | 257 | | Layer 2 | | | 258 | MAAS<---/ | +---> MAAS | 259 | ^ ^ v ^ | 260 | . . MAAS . | 261 | . .Layer 1 ^ .Layer 1 | 262 | v v .Layer 1 v | 263 | Client Client v Client | 264 | Client | 265 +-------------------------------------------------------------+ 266 Figure 1: An Overview of the Multicast Address Allocation Architecture 268 Draft MALLOC Architecture January 2000 270 Layer 1 271 A protocol or mechanism that a multicast client uses to 272 request a multicast address from a multicast address 273 allocation server (MAAS). When the server grants an address, 274 it becomes the server's responsibility to ensure that this 275 address is not then reused elsewhere within the address's 276 scope during the lifetime granted. 278 Examples of possible protocols or mechanisms at this layer 279 include MADCAP [4], HTTP to access a web page for allocation, 280 and IANA static address assignments. 282 An abstract API for applications to use for dynamic 283 allocation, independent of the Layer 1 protocol/mechanism in 284 use, is given in [11]. 286 Layer 2 287 An intra-domain protocol or mechanism that MAAS's use to 288 coordinate allocations to ensure they do not allocate 289 duplicate addresses. A MAAS must have stable storage, or 290 some equivalent robustness mechanism, to ensure that 291 uniqueness is preserved across MAAS failures and reboots. 293 MAASs also use the Layer 2 protocol/mechanism to acquire 294 (from "Prefix Coordinators") the ranges of multicast 295 addresses out of which they may allocate addresses. 297 In this document we use the term "allocation domain" to mean 298 an administratively scoped multicast-capable region of the 299 network, within which addresses in a specific range may be 300 allocated by a Layer 2 protocol/mechanism. 302 Examples of protocols or mechanisms at this layer include AAP 303 [5], and manual configuration of MAAS's. 305 Layer 3 306 An inter-domain protocol or mechanism that allocates 307 multicast address ranges (with lifetimes) to Prefix 308 Coordinators. Individual addresses may then be allocated out 309 of these ranges by MAAS's inside allocation domains as 310 described above. 312 Examples of protocols or mechanisms at this layer include 313 MASC [6] (in which Prefix Coordinators are typically routers 314 without any stable storage requirement), and static 316 Draft MALLOC Architecture January 2000 318 allocations by AS number as described in [10] (in which 319 Prefix Coordinators are typically human administrators). 321 Each of the three layers serves slightly different purposes and as 322 such, protocols or mechanisms at each layer may require different 323 design tradeoffs. 325 5. Scoping 327 To allocate dynamic addresses within administrative scopes, a MAAS 328 must be able to learn which scopes are in effect, what their 329 address ranges and names are, and which addresses or subranges 330 within each scope are valid for dynamic allocation by the MAAS. 332 The first two tasks, learning the scopes in effect and the address 333 range and name(s) of each scope, may be provided by static 334 configuration or dynamically learned. For example, a MAAS may 335 simply passively listen to MZAP [9] messages to acquire this 336 information. 338 To determine the subrange for dynamic allocation, there are two 339 cases for each scope, corresponding to small "indivisible" scopes, 340 and big "divisible" scopes. Note that MZAP identifies which 341 scopes are divisible and which are not. 343 (1) For small scopes, the allocation domain corresponds to the 344 entire topology within the administrative scope. Hence, 345 all MAASs inside the scope may use the entire address range 346 (minus the last 256 addresses reserved as scope-relative 347 addresses), and use the Layer 2 mechanism/protocol to 348 coordinate allocations. For small scopes, Prefix 349 Coordinators are not involved. 351 Hence, for small scopes, the effective "allocation domain" 352 area may be different for different scopes. Note that a 353 small, indivisible scope could be larger or smaller than 354 the Allocation Scope used for big scopes (see below). 356 (2) For big scopes (including the global scope), the area 357 inside the scope may be large enough that simply using a 358 Layer 2 mechanism/protocol may be inefficient or otherwise 359 undesirable. In this case, the scope must span multiple 360 allocation domains, and the Layer 3 mechanism/protocol must 361 be used to divvy up the scoped address space among the 363 Draft MALLOC Architecture January 2000 365 allocation domains. Hence, a MAAS may learn of the scope 366 via MZAP, but must acquire a subrange from which to 367 allocate from a Prefix Coordinator. 369 For simplicity, the effective "allocation domain" area will 370 be the same for all big scopes, being the granularity at 371 which all big scopes are divided up. We define the 372 administrative scope at this granularity to be the 373 "Allocation Scope". 375 5.1. Allocation Scope 377 The Allocation Scope is a new administrative scope, defined in 378 this document and to be reserved by IANA with values as noted 379 below. This is the scope that is used by a Layer 2 380 protocol/mechanism to coordinate address allocation for addresses 381 in larger, divisible scopes. 383 We expect that the Allocation Scope will often coincide with a 384 unicast Autonomous System (AS) boundary. 386 If an AS is too large, or the network administrator wishes to run 387 different intra-domain multicast routing in different parts of an 388 AS, that AS can be split by manual setup of an allocation scope 389 boundary that is not an AS boundary. This is done by setting up a 390 multicast boundary dividing the unicast AS into two or more 391 multicast allocation domains. 393 If an AS is too small, and address space is scarce, address space 394 fragmentation may occur if the AS is its own allocation domain. 395 Here, the AS can instead be treated as part of its provider's 396 allocation domain, and use a Layer 2 protocol/mechanism to 397 coordinate allocation between its MAAS's (if any) and those of its 398 provider. An AS should probably take this course of action if: 400 o it is connected to a single provider, 402 o it does not provide transit for another AS, and 404 o it needs fewer than (say) 256 multicast addresses of larger 405 than AS scope allocated on average. 407 Draft MALLOC Architecture January 2000 409 5.1.1. The IPv4 Allocation Scope -- 239.251.0.0/16 411 The address space 239.251.0.0/16 is to be reserved for the 412 Allocation Scope. The ranges 239.248.0.0/16, 239.249.0.0/16 and 413 239.250.0.0/16 are to be left unassigned and available for 414 expansion of this space. These ranges should be left unassigned 415 until the 239.251.0.0/16 space is no longer sufficient. 417 5.1.2. The IPv6 Allocation Scope -- SCOP 6 419 The IPv6 "scop" value 6 is to be reserved for the Allocation 420 Scope. 422 6. Overview of the Allocation Process 424 Once Layer 3 allocation has been performed for large, divisible 425 scopes, and each Prefix Coordinator has acquired one or more 426 ranges, then those ranges are passed to all MAAS's within the 427 Prefix Coordinator's domain via a Layer 2 mechanism/protocol. 429 MAAS's within the domain receive these ranges and store them as 430 the currently allowable addresses for that domain. Each range is 431 valid for a given lifetime (also acquired via the Layer 3 432 mechanism/protocol) and is not revoked before the lifetime has 433 expired. MAAS's also learn of small scopes (e.g., via MZAP) and 434 store the ranges associated with them. 436 Using the Layer 2 mechanism/protocol, each MAAS ensures that it 437 will exclude any addresses which have been or will be allocated by 438 other MAAS's within its domain. 440 When a client needs a multicast address, it first needs to decide 441 what the scope of the intended session should be, and locate a 442 MAAS capable of allocating addresses within that scope. 444 To pick a scope, the client will either simply choose a well-known 445 scope, such as the global scope, or it will enumerate the 446 available scopes (e.g., by sending a MADCAP query, or by listening 447 to MZAP messages over time) and allow a user to select one. 449 Locating a MAAS can be done via a variety of methods, including 450 manual configuration, using a service location protocol such as 451 SLP [12], or via a mechanism provided by a Layer 1 protocol 452 Draft MALLOC Architecture January 2000 454 itself. MADCAP, for instance, includes such a facility. 456 Once the client has chosen a scope and located a MAAS, it then 457 requests an address in that scope from the MAAS located. Along 458 with the request it also passes the acceptable range for the 459 lifetimes of the allocation it desires. For example, if the Layer 460 1 protocol in use is MADCAP, the client sends a MADCAP REQUEST 461 message to the MAAS, and waits for a NAK message or an ACK message 462 containing the allocated information. 464 Upon receiving a request from a client, the MAAS then chooses an 465 unused address in a range for the specified scope, with a lifetime 466 which both satisfies the acceptable range specified by the client, 467 and is within the lifetime of the actual range. 469 The MAAS uses the Layer 2 mechanism/protocol to ensure that such 470 an address does not clash with any addresses allocated by other 471 MAASs. For example, if Layer 2 uses manual configuration of non- 472 overlapping ranges, then this simply consists of adhering to the 473 range configured in the local MAAS. If, on the other hand, AAP is 474 used at Layer 2 to provide less address space fragmentation, the 475 MAAS advertises the proposed allocation domain-wide using AAP. If 476 no clashing AAP claim is received within a short time interval, 477 then the address is returned to the client via the Layer 1 478 protocol/mechanism. If a clashing claim is received by the MAAS, 479 then it chooses a different address and tries again. AAP also 480 allows each MAAS to pre-reserve a small "pool" of addresses for 481 which it need not wait to detect clashes. 483 If a domain ever begins to run out of available multicast 484 addresses, a Prefix Coordinator in that domain uses the Layer 3 485 protocol/mechanism to acquire more space. 487 7. Security Considerations 489 The architecture described herein does not prevent an application 490 from just sending to or joining a multicast address without 491 allocating it (just as the same is true for unicast addresses 492 today). However, there is no guarantee that data for unallocated 493 addresses will be delivered by the network. That is, routers may 494 drop data for unallocated addresses if they have some way of 495 checking whether a destination address has been allocated. For 496 example, if the border routers of a domain participate in the 497 Draft MALLOC Architecture January 2000 499 Layer 2 protocol/mechanism and cache the set of allocated 500 addresses, then data for unallocated addresses in a range 501 allocated by that domain can be dropped by creating multicast 502 forwarding state with an empty outgoing interface list and/or 503 pruning back the tree branches for those groups. 505 A malicious application may attempt a denial-of-service attack by 506 attempting to allocate a large number of addresses, thus 507 attempting to exhaust the supply of available addresses. Other 508 attacks include releasing or modifying the allocation of another 509 party. These attacks can be combatted through the use of 510 authentication with policy restrictions (such as a maximum number 511 of addresses that can be allocated by a single party). 513 Hence, protocols/mechanisms that implement layers of this 514 architecture should be deployable in a secure fashion. For 515 example, one should support authentication with policy 516 restrictions, and should not allow someone unauthorized to release 517 or modify the allocation of another party. 519 8. Acknowledgments 521 Steve Hanna provided valuable feedback on this document. The 522 members of the MALLOC WG and the MBone community provided the 523 motivation for this work. 525 9. References 527 [1] D. Meyer, "Administratively Scoped IP Multicast", BCP 23, RFC 528 2365, July 1998. 530 [2] Mark Handley, "Multicast Session Directories and Address 531 Allocation", Chapter 6 of PhD Thesis entitled "On Scalable 532 Multimedia Conferencing Systems", University of London, 1997. 534 [3] Mark Handley, "An Analysis of Mbone Performance", Chapter 4 535 of PhD Thesis entitled "On Scalable Multimedia Conferencing 536 Systems", University of London, 1997. 538 [4] Hanna, S., Patel, B., and M. Shah, "Multicast Address Dynamic 539 Client Allocation Protocol (MADCAP)", Work in progress, 540 draft-ietf-malloc-madcap-07.txt, September 1999. 542 Draft MALLOC Architecture January 2000 544 [5] Handley, M., Hanna, S., "Multicast Address Allocation 545 Protocol (AAP)", Work in progress, draft-ietf-malloc- 546 aap-02.txt, October 1999. 548 [6] Estrin, D., Govindan, R., Handley, M., Kumar, S., Radoslavov, 549 P., and D. Thaler, "The Multicast Address-Set Claim (MASC) 550 Protocol", Work in progress, draft-ietf-malloc-masc-03.txt, 551 July 1999. 553 [7] Deering, S., "Host Extensions for IP Multicasting", RFC 1112, 554 August 1989. 556 [8] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 557 (BGP-4)", RFC 1771, March 1995. 559 [9] Handley, M., Thaler, D., and R. Kermode, "Multicast-Scope 560 Zone Announcement Protocol (MZAP)", Work in progress, draft- 561 ietf-mboned-mzap-04.txt, June 1999. 563 [10] Meyer, D., and P. Lothberg, "Static Allocations in 233/8", 564 Work in progress, draft-ietf-mboned-static-allocation-00.txt, 565 May 1999. 567 [11] R. Finlayson, "Abstract API for Multicast Address 568 Allocation", Work in progress, draft-ietf-malloc-api-07.txt, 569 August 1999. 571 [12] Veizades, J., Guttman, E., Perkins, C., and S. Kaplan, 572 "Service Location Protocol", RFC 2165, June 1997. 574 [13] D. Mills, "Network Time Protocol (Version 3) Specification, 575 Implementation and Analysis", RFC 1305, March 1992. 577 10. Authors' Addresses 579 Dave Thaler 580 Microsoft Corporation 581 One Microsoft Way 582 Redmond, WA 98052-6399 583 EMail: dthaler@microsoft.com 585 Mark Handley 586 AT&T Center for Internet Research at ICSI 587 1947 Center St, Suite 600 589 Draft MALLOC Architecture January 2000 591 Berkeley, CA 94704 592 EMail: mjh@aciri.org 594 Deborah Estrin 595 Computer Science Dept/ISI 596 University of Southern Calif. 597 Los Angeles, CA 90089 598 EMail: estrin@usc.edu 600 11. Full Copyright Statement 602 Copyright (C) The Internet Society (2000). All Rights Reserved. 604 This document and translations of it may be copied and furnished 605 to others, and derivative works that comment on or otherwise 606 explain it or assist in its implementation may be prepared, 607 copied, published and distributed, in whole or in part, without 608 restriction of any kind, provided that the above copyright notice 609 and this paragraph are included on all such copies and derivative 610 works. However, this document itself may not be modified in any 611 way, such as by removing the copyright notice or references to the 612 Internet Society or other Internet organizations, except as needed 613 for the purpose of developing Internet standards in which case the 614 procedures for copyrights defined in the Internet Standards 615 process must be followed, or as required to translate it into 616 languages other than English. 618 The limited permissions granted above are perpetual and will not 619 be revoked by the Internet Society or its successors or assigns. 621 This document and the information contained herein is provided on 622 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 623 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 624 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 625 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 626 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 628 Draft MALLOC Architecture January 2000 630 Table of Contents 632 1: Abstract ................................................. 2 633 2: Introduction ............................................. 2 634 3: Requirements ............................................. 2 635 3.1: Address Dynamics ....................................... 4 636 4: Overview of the Architecture ............................. 6 637 5: Scoping .................................................. 8 638 5.1: Allocation Scope ....................................... 9 639 5.1.1: The IPv4 Allocation Scope -- 239.251.0.0/16 .......... 10 640 5.1.2: The IPv6 Allocation Scope -- SCOP 6 .................. 10 641 6: Overview of the Allocation Process ....................... 10 642 7: Security Considerations .................................. 11 643 8: Acknowledgments .......................................... 12 644 9: References ............................................... 12 645 10: Authors' Addresses ...................................... 13 646 11: Full Copyright Statement ................................ 14