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