idnits 2.17.1 draft-hubbard-registry-guidelines-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 70 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Introduction' ) ** The document seems to lack a Security Considerations section. ** 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 abstract seems to indicate that this document obsoletes RFC1466, but the header doesn't have an 'Obsoletes:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 340 has weird spacing: '...ization rate ...' == Line 416 has weird spacing: '...egistry may r...' == Line 478 has weird spacing: '...uesting organ...' -- 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 (July 1996) is 10146 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'RFC 1519' on line 519 looks like a reference -- Missing reference section? 'RFC 1518' on line 523 looks like a reference -- Missing reference section? 'RFC 1918' on line 526 looks like a reference -- Missing reference section? 'RFC 1814' on line 529 looks like a reference -- Missing reference section? 'RFC 1900' on line 531 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 K. Hubbard 2 InterNIC 3 M. Kosters 4 InterNIC 5 D. Conrad 6 APNIC 7 D. Karrenberg 8 RIPE 9 J.Postel 10 IANA 11 July 1996 13 INTERNET REGISTRY IP ALLOCATION GUIDELINES 14 draft-hubbard-registry-guidelines-04.txt 16 Status of this Memo 18 This memo provides information for the Internet community. 19 This memo does not specify an Internet standard of any kind. 20 Distribution of this memo is unlimited. 22 This document is an Internet-Draft. Internet-Drafts are working 23 documents of the Internet Engineering Task Force (IETF), its 24 areas, and its working groups. Note that other groups may also 25 distribute working documents as Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six 28 months and may be updated, replaced, or obsoleted by other 29 documents at any time. It is inappropriate to use Internet- 30 Drafts as reference material or to cite them other than as 31 ``work in progress.'' 33 To learn the current status of any Internet-Draft, please check 34 the ``1id-abstracts.txt'' listing contained in the Internet- 35 Drafts Shadow Directories on ftp.is.co.za (Africa), 36 nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), 37 ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 39 Abstract 41 This document describes the registry system for the distribution of 42 globally unique Internet address space and registry operations. 43 Particularly this document describes the rules and guidelines 44 governing the distribution of this address space. 46 This document replaces RFC 1466, with all the guidelines and 47 procedures updated and modified in the light of experience. 49 This document does not describe private Internet address space and 50 multicast address space. It also does not describe regional and local 51 refinements of the global rules and guidelines. 53 This document can be considered the base set of operational guidelines 54 in use by all registries. Additional guidelines may be imposed by a 55 particular registry as appropriate. 57 Expire in six months 59 Table of Contents 61 1. Introduction.......................................3 63 2. Allocation Framework...............................4 64 2.1 Guidelines for Internet Service Providers.........4 65 2.2 Submission of Reassignment Information............7 67 3. Assignment Framework..............................7 68 3.1 Common Registry Requirements......................8 69 3.2 Network Engineering Plans.........................9 70 3.3 Previous Assignment History.......................10 71 3.4 Network Deployment Plans..........................10 72 3.5 Organization Information..........................10 73 3.6 Expected Utilization Rate.........................10 75 4. Operational Guidelines for Registries.............10 77 5. In-Addr.Arpa Domain Maintenance...................12 79 6. Right to Appeal...................................12 81 7. References........................................12 83 8. Authors' Addresses................................13 84 1. Introduction 86 The addressing constraints described in this document are 87 largely the result of the interaction of existing router 88 technology, address assignment, and architectural history. 89 After extensive review and discussion, the authors of this 90 document, the IETF working group that reviewed it and the IESG 91 have concluded that there are no other currently deployable 92 technologies available to overcome these limitations. In the 93 event that routing or router technology develops to the point 94 that adequate routing aggregation can be achieved by other 95 means or that routers can deal with larger routing and more 96 dynamic tables, it may be appropriate to review these 97 constraints. 99 Internet address space is distributed according to the following 100 three goals: 102 1) Conservation: Fair distribution of globally unique Internet address 103 space according to the operational needs of the end-users and Internet 104 Service Providers operating networks using this address space. 105 Prevention of stockpiling in order to maximize the lifetime of the 106 Internet address space. 108 2) Routability: Distribution of globally unique Internet addresses 109 in a hierarchical manner, permitting the routing scalability of 110 the addresses. This scalability is necessary to ensure proper 111 operation of Internet routing, although it must be stressed that 112 routability is in no way guaranteed with the allocation or 113 assignment of IPv4 addresses. 115 3) Registration: Provision of a public registry documenting address 116 space allocation and assignment. This is necessary to ensure 117 uniqueness and to provide information for Internet trouble shooting 118 at all levels. 120 It is in the interest of the Internet community as a whole that the 121 above goals be pursued. However it should be noted that 122 "Conservation" and "Routability" are often conflicting goals. All 123 the above goals may sometimes be in conflict with the interests of 124 individual end-users or Internet service providers. Careful analysis 125 and judgement is necessary in each individual case to find an 126 appropriate compromise. 128 The Internet Registry system 130 In order to achieve the above goals the Internet Registry (IR) hierarchy 131 was established. 133 The Internet Registry hierarchy consists of the following levels of 134 hierarchy as seen from the top down: IANA, Regional IRs, Local IRs. 136 IANA 138 The Internet Assigned Numbers Authority has authority over all number 139 spaces used in the Internet. This includes Internet Address Space. IANA 140 allocates parts of the Internet address space to regional IRs according 141 to its established needs. 143 Regional IRs 145 Regional IRs operate in large geopolitical regions such as continents. 146 Currently there are three regional IRs established; InterNIC serving 147 North America, RIPE NCC serving Europe, and AP-NIC serving the Asian 148 Pacific region. Since this does not cover all areas, regional IRs also 149 serve areas around its core service areas. It is expected that the 150 number of regional IRs will remain relatively small. Service areas will 151 be of continental dimensions. 153 Regional IRs are established under the authority of the IANA. This 154 requires consensus within the Internet community of the region. A con- 155 sensus of Internet Service Providers in that region may be necessary to 156 fulfill that role. 158 The specific duties of the regional IRs include coordination and 159 representation of all local IRs in its respective regions. 161 Local IRs 163 Local IRs are established under the authority of the regional IR and 164 IANA. These local registries have the same role and responsibility as 165 the regional registries within its designated geographical areas. These 166 areas are usually of national dimensions. 168 2. Allocation Framework 170 2.1 Guidelines for Internet Service Providers (ISPs) 172 This document makes a distinction between the allocation of IP addresses 173 and the assignment of IP addresses. Addresses are allocated to ISPs by 174 regional registries to assign to its customer base. 176 ISPs who exchange routing information with other ISPs at multiple loca- 177 tions and operate without default routing may request space directly 178 from the regional registry in its geographical area. ISPs with no 179 designated regional registry may contact any regional registry and the 180 regional registry may either handle the request or refer the request to 181 an appropriate registry. 183 To facilitate hierarchical addressing, implemented using Classless 184 Inter-Domain Routing (CIDR), all other ISPs should request address space 185 directly from its upstream provider. ISPs only request address space 186 directly from regional registries if their immediate requirement, when 187 satisfied with a contiguous block allocation, has a reasonable probabil- 188 ity of being routable on the Internet, and they meet one or more of the 189 following conditions. 191 a) the ISP is directly connected to a major routing exchange 192 (for purposes of this document, a major routing exchange 193 is defined as a neutral layer 2 exchange point connecting 194 four or more unrelated ISPs.) 196 b) the ISP is multi-homed, that is, it has more than one 197 simultaneous connection to the global Internet and no 198 connection is favored over the other 200 Note that addresses issued directly from the IRs, (non-provider 202 based), 203 are the least likely to be routable across the Internet. 205 The following are the IP allocation guidelines for ISPs: 207 1. CIDR addresses are allocated to ISPs in blocks. It is 208 recommended that those blocks remain intact. Fragmentation of 209 CIDR blocks is discouraged. More specifically, ISPs are 210 encouraged to treat address assignments as loans for the 211 duration of the connectivity provision. At the termination 212 of the Internet connectivity contract, e.g., the customer 213 moves to another service provider, it is recommended the 214 customer return the network addresses currently in use and 215 renumber into the new provider's address space. The ISP 216 should allow sufficient time for the renumbering process to be 217 completed before the IP addresses are reused. 219 2. To ensure efficient implementation and use of Classless 220 Inter-Domain Routing (CIDR), the Regional Registries issue 221 address space on appropriate "CIDR-supported" bit boundaries. 223 3. ISPs are required to utilize address space in an efficient 224 manner. To this end, ISPs should have documented 225 justification available for each assignment. The regional 226 registry may, at any time, ask for this information. If the 227 information is not available, future allocations may be impacted. 228 In extreme cases, existing loans may be impacted. 230 4. IP addresses are allocated to ISPs using a slow-start 231 procedure. New ISPs will receive a minimal amount based 232 on immediate requirement. Thereafter, allocated blocks may be 233 increased based on utilization verification supplied to the 234 regional registry. The parent registries are responsible for 235 determining appropriate initial and subsequent allocations. 236 Additional address allocations will provide enough address space 237 to enable the ISP to assign addresses for three months 238 without requesting additional address space from its parent 239 registry. Please note that projected customer base has little 240 impact on the address allocations made by the parent registries. 241 Initial allocation will not be based on any current or future 242 routing restrictions but on demonstrated requirements. 244 5. Due to the requirement to increase the utilization efficiency 245 of IPv4 address space, all assignments are made with the 246 assumption that sites make use of variable length subnet mask 247 (VLSM) and classless technologies within their network. Any 248 request for address space based on the use of classfull 249 assumptions will require a detailed justification. The use of 250 classfull technologies for the purposes of administrative 251 convenience is generally insupportable due to the limited 252 availability of free IPv4 address space. 254 6. Regional registries may set a maximum limit on assignment sizes 255 such that a second opinion of the regional registry is required. 257 7. Due to constraints on the available free pool of IPv4 address 258 space, the use of static IP address assignments (e.g., one 259 address per customer) for dial-up users is strongly discouraged. 260 While it is understood that the use of static addressing may 261 ease some aspects of administration, the current rate of 262 consumption of the remaining unassigned IPv4 address space does 263 not permit the assignment of addresses for administrative ease. 264 Organizations considering the use of static IP address assignment 265 are expected to investigate and implement dynamic assignment 266 technologies whenever possible. 268 2.2 Submission of Reassignment Information 270 It is imperative that reassignment information be submitted in a prompt 271 and efficient manner to facilitate database maintenance and ensure 272 database integrity. Therefore, assignment information must be 273 submitted to the regional registry immediately upon making the 274 assignment. The following reasons necessitate transmission of the 275 reassignment information: 277 a) to provide operational staff with information on who is using 278 the network number and to provide a contact in case of 279 operational/ security problems, 281 b) to ensure that a provider has exhausted a majority of its 282 current CIDR allocation, thereby justifying an additional 283 allocation, 285 c) to assist in IP allocation studies. 287 Procedures for submitting the reassignment information will be 288 determined by each regional registry based on its unique requirements. 290 All sub-registries (ISPs, Local registries, etc.) must register with 291 their respective regional registry to receive information regarding 292 reassignment guidelines. No additional CIDR blocks will be 293 allocated by the regional registry or upstream providers until 294 approximately 80% of all reassignment information has been submitted. 296 3. Assignment Framework 298 An assignment is the delegation of authority over a block of IP 299 addresses to an end enterprise. The end enterprise will use addresses 300 from an assignment internally only; it will not sub-delegate those 301 addresses. This section discusses some of the issues involved in 302 assignments and the framework behind the assignment of addresses. 304 In order for the Internet to scale using existing technologies, use of 305 regional registry services should be limited to the assignment of IP 306 addresses for organizations meeting one or more of the following condi- 307 tions: 309 a) the organization has no intention of connecting to 310 the Internet-either now or in the future-but it still 311 requires a globally unique IP address. The organization 312 should consider using reserved addresses from RFC1918. 313 If it is determined this is not possible, they can be 314 issued unique (if not Internet routable) IP addresses. 316 b) the organization is multi-homed with no favored connection. 318 c) the organization's actual requirement for IP space is 319 very large, for example, the network prefix required to 320 cover the request is of length /18 or shorter. 322 All other requestors should contact its ISP for address 323 space or utilize the addresses reserved for non-connected networks 324 described in RFC1918 until an Internet connection is established. 325 Note that addresses issued directly from the IRs,(non-provider based), 326 are the least likely to be routable across the Internet. 328 3.1 Common Registry Requirements 330 Because the number of available IP addresses on the Internet is limited, 331 the utilization rate of address space will be a key factor in network 332 number assignment. Therefore, in the best interest of the Internet as a 333 whole, specific guidelines have been created to govern the assignment of 334 addresses based on utilization rates. 336 Although topological issues may make exceptions necessary, the basic 337 criteria that should be met to receive network numbers are listed below: 339 25% immediate utilization rate 340 50% utilization rate within 1 year 342 The utilization rate above is to be used as a guideline, there may be be 343 occasions when the 1 year rate does not fall exactly in this range. 344 Organizations must exhibit a high confidence level in its 1 year utili- 345 zation rate and supply documentation to justify the level of confidence. 347 Organizations will be assigned address space based on immediate utiliza- 348 tion plus 1 year projected utilization. A prefix longer than /24 may be 349 issued if deemed appropriate. Organizations with less than 128 hosts 350 will not be issued an IP address directly from the IRs. Organizations 351 may be issued a prefix longer than /24 if the organization can provide 352 documentation from a registry recognized ISP indicating the ISP will 353 accept the long prefix for injection into the global routing system. 355 Exceptions to the criteria will not be made based on insufficient equip- 356 ment without additional detailed justification. Organizations should 357 implement variable length subnet mask (VLSM) internally to maximize the 358 effective utilization of address space. Address assignments will be 359 made under the assumption that VLSM is or will be implemented. 361 IP addresses are valid as long as the criteria continues to be met. The 362 IANA reserves the right to invalidate any IP assignments once it is 363 determined the the requirement for the address space no longer exists. 364 In the event of address invalidation, reasonable efforts will be made by 365 the appropriate registry to inform the organization that the addresses 366 have been returned to the free pool of IPv4 address space. 368 3.2 Network Engineering Plans 370 Before a registry makes an assignment, it must examine each address 371 space request in terms of the requesting organization's networking 372 plans. These plans should be documented, and the following information 373 should be included: 375 1. subnetting plans, including subnet masks and number of 376 hosts on each subnet for at least one year 378 2. a description of the network topology 380 3. a description of the network routing plans, including the 381 routing protocols to be used as well as any limitations. 383 The subnetting plans should include: 385 a) a tabular listing of all subnets on the network 387 b) its associated subnet masks 389 c) the estimated number of hosts 391 d) a brief descriptive remark regarding the subnet. 393 If subnetting is not being used, an explanation why it cannot be imple- 394 mented is required. Care must be taken to ensure that the host and 395 subnet estimates correspond to realistic requirements and are not based 396 on administrative convenience. 398 3.3 Previous Assignment History 400 To promote increased usage of address space, the registries will require 401 an accounting of address space previously assigned to the enterprise, if 402 any. In the context of address space allocation, an "enterprise" con- 403 sists of all divisions and/or subsidiaries falling under a common parent 404 organization. The previous assignment history should include all net- 405 work numbers assigned to the organization, plus the network masks for 406 those networks and the number of hosts on each (sub-)network. Suffi- 407 cient corroborating evidence should be provided to allow the assigning 408 registry to be confident that the network descriptions provided are 409 accurate. Routing table efficiency will be taken into account by the 410 regional registries and each request will be handled on a case by case 411 basis. 413 3.4 Network Deployment Plans 415 In order to assign an appropriate amount of space in the required time 416 frame, a registry may request deployment plans for a network. Deploy- 417 ment plans should include the number of hosts to be deployed per time 418 period, expected network growth during that time period, and changes in 419 the network topology that describe the growth. 421 3.5 Organization Information 423 A registry may request that an organization furnish a published descrip- 424 tion verifying that the organization is what it claims to be. This 425 information can consist of brochures, documents of incorporation, or 426 similar published material. 428 3.6 Expected Utilization Rate 430 As stated in the foregoing text, one of the key factors in determining 431 how much address space is appropriate for an organization is the 432 expected utilization rate of the network. The expected utilization rate 433 is the number of hosts connected to the network divided by the total 434 number of hosts possible on the network. In addition, the estimated 435 number of hosts should be projected over a reasonable time frame, i.e., 436 one in which the requesting enterprise has a high level of confidence. 437 The minimal utilization rate is set by the IANA and may be changed at 438 any time. New utilization rates may be enforced by the regional regis- 439 tries prior to updating the written policy. 441 4. Operational Guidelines For Registries 443 1. Regional Registries provide registration services as its 444 primary function. Therefore, regional registries may charge some 445 fee for services rendered, generally in relation to the cost of 446 providing those services. 448 2. Regardless of the source of its address space, sub-registries 449 (Local IRs, ISPs, etc.) must adhere to the guidelines of its 450 regional registry. In turn, it must also ensure that its 451 customers follow those guidelines. 453 3. To maximize the effective use of address space, IP addresses need 454 to be assigned/allocated in classless blocks. With this in mind, 455 assignments will not be made in Class Cs or Bs but by prefix 456 length. Consequently, an organization that would have been 457 assigned a Class B in the past will now be assigned a /16 prefix, 458 regardless of the actual address class. 460 4. All IP address requests are subject to audit and verification 461 by any means deemed appropriate by the regional registry. 462 If any assignment is found to be based on false information, 463 the registry may invalidate the request and return the 464 assigned addresses back to the pool of free addresses for 465 later assignment. 467 5. Due to technical and implementation constraints on the Internet 468 routing system and the possibility of routing overload, major 469 transit providers may need to impose certain restrictions to 470 reduce the number of globally advertised routes. This may 471 include setting limits on the size of CIDR prefixes added to 472 the routing tables, filtering of non-aggregated routes, etc. 473 Therefore, addresses obtained directly from regional registry 474 (provider-independent, also known as portable) are not 475 guaranteed routable on the Internet. 477 6. Information provided to request address space is often considered 478 sensitive by the requesting organization. The assigning 479 registry must treat as confidential any and all information 480 that the requesting organization specifically indicates as 481 sensitive. When a requesting organization does not have 482 assurance of privacy, the parent of the assigning registry may 483 be required to do the assignment. In such cases, the parent 484 registry will provide the assigning registry with information 485 regarding the appropriate amount of address space to allocate. 487 7. The transfer of IP addresses from one party to another must be 488 approved by the regional registries. The party trying to obtain 489 the IP address must meet the same criteria as if they were 490 requesting an IP address directly from the IR. 492 5. In-ADDR.ARPA Domain Maintenance 494 The regional registries will be responsible for maintaining IN-ADDR.ARPA 495 records only on the parent blocks of IP addresses issued directly to the 496 ISPs or those CIDR blocks of less than /16. Local IRs/ISPs with a pre- 497 fix length of /16 or shorter will be responsible for maintaining all 498 IN-ADDR.ARPA resource records for its customers. 500 IN-ADDR.ARPA resource records for networks not associated with a 501 specific provider will continue to be maintained by the regional regis- 502 try. 504 6. Right to Appeal 505 If an organization feels that the registry that assigned its address has 506 not performed its task in the requisite manner, the organization has the 507 right of appeal to the parent registry. 509 In such cases, the assigning registry shall make available all relevant 510 documentation to the parent registry, and the decision of the parent 511 registry shall be considered final (barring additional appeals to the 512 parent registry's parent). If necessary, after exhausting all other 513 avenues, the appeal may be forwarded to IANA for a final decision. Each 514 registry must, as part of their policy, document and specify how to 515 appeal a registry assignment decision. 517 7. References 519 [RFC 1519] V. Fuller, T. Li, J. Yu, K. Varadhan, 520 "Classless Inter- Domain Routing (CIDR): an Address 521 Assignment and Aggregation Strategy". 523 [RFC 1518] Y. Rekhter, T. Li, "An Architecture for IP 524 Address Allocation with CIDR". 526 [RFC 1918] Y. Rekhter, B. Moskowitz, D. Karrenberg, G. de Groot, 527 "Address Allocation for Private Internets". 529 [RFC 1814] E. Gerich, "Unique Addresses are Good" 531 [RFC 1900] B. Carpenter, Y. Rekhter, "Renumbering Needs Work" 532 8. Authors' Addresses 534 Kim Hubbard 535 InterNIC Registration Services 536 c/o Network Solutions 537 505 Huntmar Park Drive 538 Herndon, VA 22070 539 Phone: (703) 742-4870 540 email: kimh@internic.net 542 Jon Postel 543 USC/Information Sciences Institute 544 4676 Admiralty Way 545 Marina del Rey, CA 90292 546 Phone: 310-822-1511 547 EMail: Postel@ISI.EDU 549 Mark Kosters 550 InterNIC Registration Services 551 c/o Network Solutions 552 505 Huntmar Park Drive 553 Herndon, VA 22070 554 Phone: (703) 742-4795 555 email: markk@internic.net 557 David Conrad 558 Asia Pacific Network Information Center 559 c/o United Nations University 560 53-70 Jingumae 5-chome, 561 Shibuya-ku, Tokyo 150 562 JP 563 Phone: +81-3-5467-7014 564 email: davidc@APNIC.NET 566 Daniel Karrenberg 567 RIPE NCC 568 Kruislaan 409 569 SJ Amsterdam NL-1098 570 NL 571 Phone: +31 20 592 5065 572 email: dfk@RIPE.NET