idnits 2.17.1 draft-huston-ipv6-local-use-comments-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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 4 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** There is 1 instance of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 39 has weird spacing: '... as the requi...' == Line 166 has weird spacing: '...ery low proba...' == Line 191 has weird spacing: '...bserved that ...' == Line 413 has weird spacing: '... use addre...' == Line 522 has weird spacing: '...inition of "t...' == (5 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 28, 2003) is 7547 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-09) exists of draft-ietf-ipv6-unique-local-addr-00 ** Downref: Normative reference to an Informational RFC: RFC 1744 (ref. '2') Summary: 5 errors (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Individual Submission G. Huston 3 Internet-Draft Telstra 4 Expires: February 26, 2004 August 28, 2003 6 Commentary on Distribution Mechanisms for Unique Local IPv6 Unicast 7 Addresses 8 draft-huston-ipv6-local-use-comments-01.txt 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at http:// 25 www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on February 26, 2004. 32 Copyright Notice 34 Copyright (C) The Internet Society (2003). All Rights Reserved. 36 Abstract 38 This memorandum examines the characteristics of Unique Local IPv6 39 Unicast addresses, as well as the requirements for address 40 distribution mechanisms for this class of addresses. It is intended 41 as a commentary on an Internet Draft currently under consideration in 42 the IPv6 Working Group of the IETF. 44 Table of Contents 46 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 47 2. Characteristics of Local Use Addresses . . . . . . . . . . . . 3 48 3. Locally Assigned Global IDs . . . . . . . . . . . . . . . . . 5 49 4. Centrally Assigned Global IDs . . . . . . . . . . . . . . . . 5 50 5. Local Use Address Distribution Mechanisms . . . . . . . . . . 7 51 5.1 Allocation Fees . . . . . . . . . . . . . . . . . . . . . . . 7 52 5.2 Allocation Period . . . . . . . . . . . . . . . . . . . . . . 8 53 5.3 Choice in Service Models . . . . . . . . . . . . . . . . . . . 8 54 5.4 Recording Allocations . . . . . . . . . . . . . . . . . . . . 9 55 5.5 Reverse Mapping Local Use Addresses in ip6.arpa . . . . . . . 9 56 6. Management Requirements for Local Use Addresses . . . . . . . 10 57 7. Distribution Mechanisms . . . . . . . . . . . . . . . . . . . 11 58 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 59 9. Relationship with Existing Address Distribution Mechanisms . . 12 60 10. Security Considerations . . . . . . . . . . . . . . . . . . . 14 61 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 62 References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 15 64 Intellectual Property and Copyright Statements . . . . . . . . 16 66 1. Introduction 68 Current work within the IETF IPv6 working includes the drafting of a 69 proposal to define part of the IPv6 unicast address space for local 70 use. This is currently IETF work in progress being considered by the 71 IPv6 Working Group, documented in an Internet draft, 72 "draft-ietf-ipv6-unique-local-addr-00.txt" [1]. These addresses are 73 intended for various forms of local communications and are not 74 expected to be routable on the global Internet. The proposal refers 75 to such addresses as "Unique Local IPv6 Unicast Addresses". 77 There are a number of characteristics of such addresses that have 78 been proposed in order to ensure that they can fulfill the role of a 79 local-use address, and there are also a number of considerations 80 relating to the distribution mechanisms for these addresses that 81 distinguish them from globally routable unicast addresses. This 82 document explores these intended characteristics in further detail as 83 well as the associated distribution mechanisms. 85 2. Characteristics of Local Use Addresses 87 The characteristics listed in the draft proposal for such addresses 88 are: 90 1. Globally unique prefix. 92 2. Well known prefix to allow for easy filtering at site 93 boundaries. 95 3. Allows sites to be combined or privately interconnected 96 without creating any address conflicts or require renumbering 97 of interfaces using these prefixes. 99 4. Internet Service Provider independent and can be used for 100 communications inside of a site without having any permanent 101 or intermittent Internet connectivity. 103 5. If accidentally leaked outside of a site via routing or DNS, 104 there is no conflict with any other addresses. 106 6. In practice, applications may treat these address like global 107 scoped addresses. 109 It could be argued that, strictly, the third and fifth 110 characteristics are a consequence of the first, as they can be all 111 grouped under the overall characteristic of "use of a common unique 112 prefix". The second, forth and sixth characteristics commonly refer 113 to unique use of a local address block drawn from the global unicast 114 address pool. 116 Restating this list of characteristics gives: 118 1. Exclusive use of a common prefix drawn from the global unicast 119 address space for all local use addresses. 121 2. Unique assignment of local use address blocks from within the 122 pool of addresses defined by this prefix. 124 Section 3.1 of the Internet Draft proposal further refines the set of 125 characteristics, by describing the address as a four part object: 127 | 7 bits | 41 bits | 16 bits | 64 bits | 128 +--------+------------+-----------+-----------------------------+ 129 | prefix | global ID | subnet ID | interface ID | 130 +--------+------------+-----------+-----------------------------+ 132 where: 134 prefix: prefix to identify Local IPv6 unicast addresses. 135 (FC00::/7) 137 global ID: global identifier used to create a globally unique 138 prefix. 140 subnet ID: 16-bit subnet ID is an identifier of a subnet within 141 the site. 143 interface ID: 64-bit Interface ID. 145 The length of the prefix + global ID part is 48 bits in length, 146 allowing 16 bits for local assignation of subnet IDs and 64 bits for 147 the interface ID. This allows for 2,199,023,255,552 assignable local 148 use address blocks. 150 There is a further characteristic of the address block defined in 151 this section of the draft, namely: 153 3. There is no internal structure within the global ID, and these 154 global IDs cannot be aggregated in a routing context. 156 The proposal splits this address pool into two halves: locally and 157 centrally assigned prefixes. These will be considered in the 158 following sections. 160 3. Locally Assigned Global IDs 162 One half of the Local Use address space, using the common prefix 163 FD00::/8, is described as being "locally assigned". The proposal 164 indicates that such locally assigned global IDs must be generated 165 with a pseudo-random algorithm. The proposal notes that there is a 166 very low probability that the prefix will conflict with another 167 locally generated prefix (section 11.2 of the draft proposal). 168 Analysis of the probability involved here indicates that the 169 probability of a collision in the space using a random draw function 170 exceeds 0.5 after 1.24 million random draws. The general solution of 171 the probability of a collision after d draws from n possible values 172 is given by: 174 P = 1 - ((n!) / ((n**d)((n-d)!))) 176 Given that the value for n is 2.199,023,255,552, then the objective 177 is to find the lowest value of d for which P is greater than or equal 178 to 0.5. In this case the value for d is some 1.24 million. This 179 value is likely to be too small a value for any assured level of 180 uniqueness, particularly if there is some consideration that no 181 address conflicts would arise as a result of private interconnection. 182 While the draft proposal asserts that collisions of locally assigned 183 Global IDs "can be ignored for all practical purposes" (section 184 11.2), the actual probability of a clash is one where there will a 185 probable clash after 1.24 mission random draws. If this approach is 186 used on a widespread basis then the risk of clashing Global IDs is 187 far greater that the "theoretical" risk described in the proposal. 188 Some further consideration should be given to this part of the 189 proposal. 191 It is observed that this 'random draw' is an inadequate response to 192 item 2 of the required characteristics for Local Use addresses. A 193 probability of uniqueness is tangibly different to the property of 194 assured uniqueness. If assurred uniqueness is an essential 195 characteristic of all elements of this address space, then it is 196 necessary to drop the random self-selection mechanism from the draft 197 proposal, and that all Local-Use addresses be distributed in such a 198 manner that uniqueness is assured in every case. 200 4. Centrally Assigned Global IDs 202 The other half of the local use space is proposed in the draft to be 203 "centrally assigned" using fixed size /48 blocks. This refines the 204 second characteristic to read: 206 2. Unique assignment of fixed size local use address blocks from 207 within the pool of addresses defined by this prefix, using a 208 Global ID as the block prefix. 210 The proposal notes that these assignments can be escrowed to resolve 211 any disputes regarding duplicate assignments. It is noted that escrow 212 is a specific solution to a more general characteristic, and the 213 desired characteristic being defined here is: 215 4. The assignment information must be recorded and stored in a 216 reliable manner. 218 The assignment function is described in the proposal as one that 219 treats sequential allocations in a random fashion, and explicitly 220 notes that they should not be assigned accordingly to any particular 221 structure, and therefore they cannot be aggregated in a routing 222 environment. 224 5. Local Use Addresses are not intended to be passed within the 225 global routing environment 227 The complete list of characteristics of this Centrally Assigned Local 228 Use IPv6 Unicast address space is: 230 1. Exclusive use of a common prefix drawn from the global unicast 231 address space for all local use addresses. 233 2. Unique assignment of fixed size local use address blocks from 234 within the pool of addresses defined by this prefix, using a 235 Global ID as the block prefix. 237 3. There is no internal structure within the global ID, and these 238 global IDs cannot be aggregated in a routing context. 240 4. The assignment information must be recorded and stored in a 241 reliable manner. 243 5. Local Use Addresses are not intended to be passed within the 244 global routing environment 246 The potential for use of this address in end-to-end solutions 247 relating to multi-homing is limited to the extent that this identity 248 space is unstructured, so it cannot be used as a lookup key in any 249 mapping system that maps identities into locators. If the intended 250 use is through a sequence of mappings from domain name to identifier 251 to current locator, then the last mapping (from identifier to 252 locator) is not feasible in an unstructured identifier space. In this 253 sense the role of such an address is limited to an assertion of a 254 fixed, globally unique label that can be used in conjunction with 255 dynamic change of location-based address to provide some form of 256 transport session resiliency in a multi-homed environment. 258 5. Local Use Address Distribution Mechanisms 260 The proposal notes that: 262 The requirements for centrally assigned global ID allocations are: 264 * Available to anyone in an unbiased manner. 266 * Permanent with no periodic fees. 268 * One time non-refundable allocation fee in the order of 10 Euros 269 per allocation. 271 * The ownership of each individual allocation should be private, 272 but should be escrowed. 274 The unstated implication from the first requirement is that this is 275 undertaken without consideration of the current or intended level of 276 use of the address block, so that there are no qualifications 277 regarding assignment of a Local Use Address block. The proposal also 278 notes that such availability should include non-Internet access 279 mechanisms as a desired additional mechanism. 281 The second and third aspects of this proposed distribution mechanism 282 describe the use of a one-time fee for a one-time service transaction 283 that has enduring consequences. 285 5.1 Allocation Fees 287 The first aspect here is the consideration of the allocation fee. The 288 draft motivates this payment as a means of prevention of hoarding of 289 blocks from within this pool by imposing a financial impost. While 290 there are many forms of control over a distribution mechanism to 291 prevent distortions such as hoarding, this pricing approach is seen 292 as a lightweight and effective mechanism that has the potential to 293 address the identified problem. However, there are some consequences 294 of this aspect of the draft proposal that should be examined in 295 further detail. The imposition of a charge without relation to 296 service cost is seen in many regulatory regimes as an imposition that 297 is likened to a monopoly rental or a form of taxation. Such forms of 298 charges have no valid role, and should be avoided. It is more 299 reasonable to allow the operator(s) of this distribution mechanism to 300 be able to account for their costs in operating this service, and 301 allow the operator to determine a service fee that is based on these 302 costs. 304 The operator needs to consider that if this is to be a one-time fee 305 for an unbounded service (so called 'cemetery plot' fees), the fee 306 should cover both the processing component and the subsequent record 307 maintenance component of the service. 309 5.2 Allocation Period 311 The proposal explicitly indicates that the allocation should be 312 'permanent'. This implies that there is no concept of return of a 313 Local Use prefix once it has been allocated from the central 314 registry, and that there is no concept of a registry-recorded 315 transfer of an allocation. The implication of this service model is 316 that there is no form of reuse of blocks from this address space. The 317 implicit assumption here is that for the entire useful lifetime of 318 the technology, under all conceivable allocation demand scenarios, 319 that there will be adequate available address space to continue to 320 meet demand from the Local Use address pool. Without any form of 321 periodic renewal or similar opportunity to alter the terms of use of 322 this address space then, if exhaustion of the space is considered to 323 be a potential risk, the observations made in 1994 regarding the 324 possible outcomes of the (then) IPv4 address allocation practices 325 are once more relevant here: 327 "It is perhaps a sad reflection of the conflict of short term 328 objectives and longer term considerations that the evident short 329 term motivations of ready and equitable access to the IPv4 address 330 (which were the motivational factors in determining the current 331 Internet address allocation policies) run the consequent risk of 332 monopoly- based restrictive trade and barrier-based pricing as a 333 longer term outcome of unallocated address space exhaustion." [2] 335 Of course if there is a high degree of confidence that exhaustion of 336 the Local Use address pool is not a remotely possible eventuality, 337 then such address prefixes can be considered in the same terms as a 338 single-use disposable facility, and these considerations are not 339 directly relevant. 341 5.3 Choice in Service Models 343 It is possible that clients of this allocation service want the 344 choice between a single one-time permanent allocation (and a one-time 345 service fee) and a defined period renewable service, where, at the 346 end of the defined period the client has the choice of renewing the 347 allocation or allowing it to lapse back to the pool. Given the 348 central nature of the described distribution mechanism, allowing the 349 client some choice in the form of service, rather than imposing a 350 single service model is seen as a reasonable measure. 352 The model also proposes a single layer of distribution, where end 353 clients interact with a proposed single central registry. Again this 354 is an area where a different structure used for the distribution of 355 many other forms of goods or resources, typically using some form of 356 hierarchy in distribution with wholesale and retail roles. Such 357 hierarchies often allow for a more efficient form of overall 358 distribution than a single entity attempting to service a global 359 consumer base. Current regulatory environments also look to 360 competition as a means of ensuring that service regimes operate 361 efficiently and that no single player can distort the price of the 362 service through the imposition of monopoly rentals, artificial 363 scarcity or selective servicing. 365 5.4 Recording Allocations 367 The proposal indicates that information relating to the 'ownership' 368 of each individual allocation be private. This is not an easily 369 achieved outcome, given that 'ownership' is a public claim to the 370 unique ability to access and exploit the resource. Furthermore, this 371 implies that the resource itself is a form of property, and that 372 property can be traded, swapped or otherwise disposed of at the 373 discretion of the owner, inferring that the address block, is in some 374 form, an asset of the holder. It is unclear that this interpretation 375 of the status of an address is the actual intent of the proponents of 376 this approach, and that other forms of expression of unique and 377 enduring interest in the address resource may be more appropriate for 378 this resource. This observation is made in the context of the 379 characterization of the larger protocol address space as a public 380 good that is distinguished from concepts of ownership or the 381 inferring of aspects of property and asset into this resource. 383 5.5 Reverse Mapping Local Use Addresses in ip6.arpa 385 It is unclear from the proposal whether Local Use Addresses could or 386 should be entered into the ip6.arpa reverse mapping domain space. as 387 a delegated domain. 389 Locally assigned prefixes cannot be entered into this domain space 390 because of the lack of a condition of assured uniqueness. 392 The situation with respect to centrally assigned prefixes is not so 393 clear. The considerations include: 395 o The potential size of the domain zone. Because of the lack of any 396 structure beyond the 8th bit of the prefix, there is no ability to 397 impose a hierarchy of zone files, and the reverse zone would need 398 to list all assigned local use prefixes and their delegation 399 points. There are obvious implications in terms of the potential 400 size of this zone file. and some consideration as to the 401 efficiency of operation of a zone of such a potential size. 403 o The desired characteristic of Local Use prefixes where the 404 "ownership" of the prefix is not public information. If the domain 405 zone operator was distinct from the central registry operator, 406 then the privacy of the address allocation information could 407 preclude the domain operator from validating a delegation request 408 for a Local Use address block. 410 o The potential use of these addresses in some classes of end-point 411 identification may imply the need for an external entity, using 412 the global DNS to be map from the local use identifier to a global 413 use address, and one way to perform this mapping in the DNS is to 414 use the reverse domain to map from the end point local use address 415 to a global DNS name, and then map forward from this name to a 416 global address. Precluding local use addresses from the global DNS 417 would preclude this form of mapping. 419 For local use, a so called "two-faced" DNS can be configured to 420 provide a local reverse mapping service for the local site. 422 6. Management Requirements for Local Use Addresses 424 In summary, the characteristics of the management of this space is 425 where: 427 1. Every applicant may obtain an address block in this prefix space 428 without providing any form of justification to the registry 429 operator. 431 2. Every assigned Local-Use block is of the same size, namely a / 432 48. 434 3. Each block is uniquely assigned to the applicant. 436 4. Each assignment is a randomly selected block from the entire 437 remaining pool. 439 5. Each applicant may obtain an enduring assignment without further 440 need to contact the registry or to pay further service fees 441 (one-off service). 443 6. Any service fee, if used, should be high enough to make massive 444 seizure financially undesirable, yet low enough to make it 445 readily accessible to individuals as well as corporate entities 446 on a global scale. 448 7. Any service fee, if used, should be clearly attributable to the 449 costs associated with the provision of the service function for 450 the lifetime of the provided service. 452 8. The service model is not restricted to a one-off assignment 453 model, with the proviso that any other associated service models 454 must have similar attributes of ease of accessibility. 456 9. The association of the assigned space and the identity of the 457 applicant is not to be made public. 459 10. The assignment information is to be held in a way that is 460 reliable and enduring. 462 7. Distribution Mechanisms 464 Under the current arrangements, IANA is the IETF-selected registry 465 for IPv4 global unicast and IPv6 global unicast address space, and 466 the RIRs undertake the associated distribution function, using 467 policies that have been developed by an open process within each 468 region. 470 A complete consideration of the various regulatory and logistical 471 considerations is considered to be well beyond the appropriate scope 472 of the Internet Engineering Task Force to undertake within the 473 defined scope and mission, and a more general statement of intent 474 would be more fitting in this context. 476 An enumeration of the desired attributes of a distribution system is: 478 The adopted distribution mechanism should be: 480 * efficient, 482 * fair, 484 * generally accessible and imposing no barrier to access, 486 * undertaken in a manner that preserves the desired 487 characteristics of the Local Use address space, 489 * one that uses a fee structure that fairly reflects the costs of 490 efficient service delivery mechanisms, 492 * one that allows a choice of service models where feasible, 493 * one that prevents distortions of the distribution function 494 through behaviours such as hoarding or selective reselling, 496 * one that does not place the operator(s) in contravention to 497 various regulatory frameworks, and 499 * attuned to the long-term stable use of specific instances of 500 this resource by consumers 502 8. IANA Considerations 504 The Local Use Address draft proposes that: 506 The IANA is instructed to allocate the FC00::/7 prefix for Unique 507 Local IPv6 unicast addresses. 509 The IANA is instructed to delegate, within a reasonable time, the 510 prefix FC00::/8 to an allocation authority for Unique Local IPv6 511 Unicast prefixes of length /48. This allocation authority shall 512 comply with the requirements described in section 3.2 of this 513 document, including in particular the charging of a modest 514 one-time fee, with any profit being used for the public good in 515 connection with the Internet. 517 It is noted that there are significant problems with this proposed 518 approach to directions to IANA, particularly with the noted concept 519 that this is a for-profit activity and IANA is, in effect, being 520 directed to be in the position of selecting a global monopoly 521 operator. The indeterminate nature of a fair, open and reasonable 522 definition of "the public good" is also a problem in the context of 523 these instructions to IANA. Some of the lessons learned from DNS 524 administration over the past decade would indicate that this is not a 525 sensible directive to pass to IANA, as it is unlikely to be 526 reasonably implemented in this precise form. 528 9. Relationship with Existing Address Distribution Mechanisms 530 The Local Use proposal's desire to operate the address space without 531 any form of discernable structure by having all block assignments be 532 drawn from a random selection from across the entire managed space 533 precludes the reuse of the current distribution mechanism of an IANA 534 allocation to each of the RIRs to service their particular region. In 535 the context of assuming that the RIRs undertake this function, the 536 proposed mechanism would see FD00::/8 allocated to the RIRs and 537 managed via a single registry maintained by the RIRs working 538 together. Each RIR would lodge a "draw request" for a block from this 539 registry in response to individual customer requests, and the 540 registry would respond with the selected block, using a random draw 541 function. 543 The potential areas of difference between the current RIR practice 544 and the requirements here are: 546 o the absence of any form of justification for the allocation, 548 o a fixed size of allocation, 550 o the potential to make extensive use of automated mechanisms in the 551 registry allocation function 553 o public reporting of allocations from this space only in summary 554 form (no detailed reports, such as currently published via Whois 555 servers) 557 o consideration of adoption of a service model or models relating to 558 the terms of the assignment. 560 o consideration of various forms of renewable allocations and the 561 issue of whether permanent allocations are suitable for this 562 intended role. 564 o determining a fee schedule where the registry service is operated 565 in a manner that is cost neutral to the membership. 567 o adoption of a transaction-based fee-for service model (as distinct 568 from a membership service model) 570 o specific consideration relating to long term reliable storage of 571 individual allocation information 573 In this context, if the RIRs were to develop this as a supported 574 process, then the areas of RIR liaison with the IETF would appear to 575 be in understanding the role of coordinated RIR policies in this 576 area, and the role of the IETF. As an example, the nomination of a 577 fee schedule and a service model in the draft proposal would normally 578 seen as prescribing matters that would normally be determined by the 579 RIRs through the adoption of policy proposals rather than a matter 580 for the IETF to determine, while the consideration of permanent 581 allocations would be a matter that would entail some substantive 582 consideration by the IETF. 584 On a purely pragmatic level there is no practical way that the IETF 585 or the adopted distribution mechanism can totally prevent these 586 address prefixes from leaking into the IPv6 global routing space. 587 What is, or is not, carried in the routing space is largely a matter 588 of convention from within the operator community. If the decision is 589 taken not to publish the details of individual Local Use unique 590 allocations, then this would be a factor in determining whether or 591 not blocks drawn from this space may be carried in the global routing 592 system, but it would not absolutely prevent such use. 594 The service model is again a relatively challenging concept. The 595 original IPv4 address allocation system worked on a similar basis of 596 enduring allocations, and this has proved to be problematic in terms 597 of recovery of unused space in more recent times. While the draft 598 proposal is explicit about attempting to prevent short term 599 distortions such as hoarding, there is little doubt that any form of 600 finite unmanaged resource will be placed under consumption pressures 601 eventually. Attempting to set a global price that makes the resource 602 generally accessible, while still attempting to make the price a 603 deterrent to hoarding is not a completely reasonable exercise in 604 global terms. What would be regarded as a trivially small fee within 605 some economies would be seen as a prohibitively expensive price in 606 other economies. More worryingly, the concept of an enduring 607 assignment is that there is no opportunity to make any form of 608 correction in later times to the extant assignments, and, as in IPv4, 609 there is the distinct risk of giving early adopters a long term 610 advantage that may not be enjoyed by later players who may be working 611 under more restrictive allocation polices. A shorter term lease 612 arrangement (such as 2 - 5 years) allows for regular renewal of the 613 relationship with the registrar, allowing for assignment information 614 to be updated to reflect the current state of the assignee, but would 615 entail greater levels of registry activity. As this entire operation 616 is intended to be sufficiently low in cost that it is generally 617 accessible, and that the value here is not in routeable address 618 space, but in the attribute of assurred uniqueness for the address 619 space, the consideration of the level of registry activity is a 620 critical one. It may be that the distribution mechanism adopts both 621 service models, allowing an enduring application to be undertaken at 622 any time at one fee level, and a shorter identity-validated 623 application and renewal to be undertaken on a biannual basis at a 624 lower fee, This is obviously a matter for further consideration. 626 10. Security Considerations 628 The considerations listed in the draft proposal are: 630 Local IPv6 addresses do not provide any inherent security to the 631 nodes that use them. They may be used with filters at site 632 boundaries to keep Local IPv6 traffic inside of the site, but this 633 is no more or less secure than filtering any other type of global 634 IPv6 unicast addresses. 636 Local IPv6 addresses do allow for address-based security 637 mechanisms, including IPSEC, across end to end VPN connections. 639 It is noted that in the latter case, where end to end VPN connections 640 are being used, across local use address blocks there is a strong 641 requirement for uniqueness of the Local Use address prefix. 643 11. Acknowledgements 645 The author acknowledges the helpful comments of Alain Durand, Paul 646 Wilson, Anne Lord and George Michaelson in preparing this memo. 648 References 650 [1] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 651 Addresses", Internet-Drafts 652 draft-ietf-ipv6-unique-local-addr-00.txt, August 2003, . 656 [2] Huston, G., "Observations on the Management of the Internet 657 Address Space", RFC 1744, December 1994. 659 Author's Address 661 Geoff Huston 662 Telstra 664 Intellectual Property Statement 666 The IETF takes no position regarding the validity or scope of any 667 intellectual property or other rights that might be claimed to 668 pertain to the implementation or use of the technology described in 669 this document or the extent to which any license under such rights 670 might or might not be available; neither does it represent that it 671 has made any effort to identify any such rights. Information on the 672 IETF's procedures with respect to rights in standards-track and 673 standards-related documentation can be found in BCP-11. Copies of 674 claims of rights made available for publication and any assurances of 675 licenses to be made available, or the result of an attempt made to 676 obtain a general license or permission for the use of such 677 proprietary rights by implementors or users of this specification can 678 be obtained from the IETF Secretariat. 680 The IETF invites any interested party to bring to its attention any 681 copyrights, patents or patent applications, or other proprietary 682 rights which may cover technology that may be required to practice 683 this standard. Please address the information to the IETF Executive 684 Director. 686 Full Copyright Statement 688 Copyright (C) The Internet Society (2003). All Rights Reserved. 690 This document and translations of it may be copied and furnished to 691 others, and derivative works that comment on or otherwise explain it 692 or assist in its implementation may be prepared, copied, published 693 and distributed, in whole or in part, without restriction of any 694 kind, provided that the above copyright notice and this paragraph are 695 included on all such copies and derivative works. However, this 696 document itself may not be modified in any way, such as by removing 697 the copyright notice or references to the Internet Society or other 698 Internet organizations, except as needed for the purpose of 699 developing Internet standards in which case the procedures for 700 copyrights defined in the Internet Standards process must be 701 followed, or as required to translate it into languages other than 702 English. 704 The limited permissions granted above are perpetual and will not be 705 revoked by the Internet Society or its successors or assignees. 707 This document and the information contained herein is provided on an 708 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 709 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 710 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 711 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 712 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 714 Acknowledgment 716 Funding for the RFC Editor function is currently provided by the 717 Internet Society.