idnits 2.17.1 draft-hubbard-registry-guidelines-00.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-26) 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 == The page length should not exceed 58 lines per page, but there was 4 longer pages, the longest (page 2) being 63 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 13 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 197 has weird spacing: '...ntation of...' == Line 309 has weird spacing: '...-either now o...' == Line 341 has weird spacing: '...ization rate ...' == Line 420 has weird spacing: '...egistry may r...' == Line 485 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 (November 1995) is 10390 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 526 looks like a reference -- Missing reference section? 'RFC 1518' on line 530 looks like a reference -- Missing reference section? 'RFC 1597' on line 533 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 8 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT K. Hubbard 2 InterNIC 3 M. Kosters 4 InterNIC 5 D. Conrad 6 APNIC 7 D. Karrenberg 8 RIPE 9 November 1995 11 INTERNET REGISTRY GUIDELINES 12 draft-hubbard-registry-guidelines-00.txt 14 Status of this Memo 16 This document is an Internet Draft. Internet Drafts are 17 working documents of the Internet Engineering Task Force 18 (IETF), its Areas, and its Working Groups. Note that 19 other groups may also distribute working documents as 20 Internet Drafts. 22 Internet Drafts are draft documents valid for a maximum 23 of six months. Internet Drafts may be updated, replaced, 24 or obsoleted by other documents at any time. It is not 25 appropriate to use Internet Drafts as reference material 26 or to cite them other than as a ``working draft'' or 27 ``work in progress.'' 29 To learn the current status of any Internet-Draft, please check 30 the ``1id-abstracts.txt'' listing contained in the Internet- 31 Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net 32 (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East 33 Coast), or 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 does not describe private Internet address space and 43 multicast address space. It also does not describe regional and local 44 refinements of the global rules and guidelines. 46 This document can be considered the base set of operational guidelines 47 in use by all registries. Additional guidelines may be imposed by a 48 particular registry as appropriate. 50 ^L 51 Table of Contents 53 1. Introduction.......................................3 55 2. Allocation Framework...............................5 57 2.1 Guidelines for Internet Service Providers.........5 59 2.2 Submission of Reassignment Information............7 61 3. Assignment Framework..............................8 63 3.1 Common Registry Requirements......................8 65 3.2 Network Engineering Plans.........................9 67 3.3 Previous Assignment History.......................10 69 3.4 Network Deployment Plans..........................10 71 3.5 Organization Information..........................11 73 3.6 Expected Utilization Rate.........................11 75 4. Operational Guidelines for Registries.............11 77 5. In-Addr.Arpa Domain Maintenance...................12 79 6. Right to Appeal...................................12 81 7. References........................................13 83 8. Authors' Addresses................................13 85 ^L 87 Introduction 89 Internet address space is distributed according to the following 90 three goals: 92 1) Conservation: Fair distribution of globally unique Internet address 93 space according to the operational needs of the end-users and Internet 94 Service Providers operating networks using this address space. 95 Prevention of stockpiling in order to maximize the lifetime of the 96 Internet address space. 98 2) Routability: Distribution of globally unique Internet addresses 99 in a hierarchical manner, permitting the routing scalability of 100 the addresses. This scalability is necessary to ensure proper 101 operation of Internet routing, although it must be stressed that 102 routability is in no way guaranteed with the allocation or 103 assignment of IPv4 addresses. 105 3) Registration: Provision of a public registry documenting address 106 space allocation and assignment. This is necessary to ensure 107 uniqueness and to provide information for Internet trouble shooting 108 at all levels. 110 It is in the interest of the Internet community as a whole that the 111 above goals be pursued. However it should be noted that 112 "Conservation" and "Routability" are often conflicting goals. All 113 the above goals may sometimes be in conflict with the interests of 114 individual end-users or Internet service providers. Careful analysis 115 and judgement is necessary in each individual case to find an 116 appropriate compromise. 118 The Internet Registry system 120 In order to achieve the above goals the Internet Registry (IR) 121 hierarchy was established. 123 The Internet Registry hierarchy consists of the following levels 124 of hierarchy as seen from the top down: IANA, Regional IRs, Local IRs. 126 IANA 128 The Internet Assigned Numbers Authority has authority over all number 129 spaces used in the Internet. This includes Internet Address Space. 130 IANA allocates parts of the Internet address space to regional IRs 131 according to their established needs. 133 ^L 134 Regional IRs 136 Regional IRs operate in large geopolitical regions such as continents. 137 Currently there are three regional IRs established; InterNIC serving 138 North America, RIPE NCC serving Europe, and AP-NIC serving the Asian 139 Pacific region. Since this does not cover all areas, regional IRs 140 also serve areas around their core service areas. It is expected 141 that the number of regional IRs will remain relatively small. 142 Service areas will be of continental dimensions. 144 Regional IRs are established under the authority of the IANA. This 145 requires consensus within the Internet community of the region. A 146 consensus of Internet Service Providers in that region may be 147 necessary to fulfill that role. 149 The specific duties of the regional IRs include coordination and 150 representation of all local IRs in their respective regions. 152 Local IRs 154 Local IRs are established under the authority of the regional IR and 155 IANA. These local registries have the same role and responsibility 156 as the regional registries within their designated geographical areas. 157 These areas are usually of national dimensions. 159 ^L 160 INTERNET REGISTRY GUIDELINES November 1995 162 II. ALLOCATION FRAMEWORK 164 2.1 Guidelines for Internet Service Providers (ISPs) 166 This document makes a distinction between the allocation of IP 167 addresses and the assignment of IP addresses. Addresses are allocated 168 to ISPs to assign to their customer base. 170 ISPs who exchange routing information with other ISPs at multiple 171 locations and operate without default routing may request space 172 directly from the regional registry in their geographical area. 173 ISPs with no designated regional registry may contact any regional 174 registry and the regional registry may either handle the request 175 or refer the request to an appropriate registry. 177 To facilitate hierarchical addressing, implemented using Classless 178 Inter-Domain Routing (CIDR), all other ISPs should request address 179 space directly from their upstream provider. It is preferred that ISPs 180 only request address space directly from regional registries if their 181 immediate requirement, when satisfied with a contiguous block 182 allocation, has a reasonable probability of being routable on the 183 Internet, and they meet one or more of the following conditions. 185 a) the ISP is directly connected to a major routing exchange 187 b) the ISP is multi-homed, that is, it has more than one 188 simultaneous connection to the global Internet and no 189 connection is favored over the other 191 Note that addresses issued directly from the IRs, (non-provider 192 based), are the least likely to be routable across the Internet. 194 The following are the IP allocation guidelines for ISPs: 196 1. CIDR addresses are allocated to ISPs in blocks. It is 197 recommended that those blocks remain intact. Fragmentation of 198 CIDR blocks is discouraged. More specifically, ISPs are 199 encouraged to treat address assignments as loans for the 200 duration of the connectivity provision. At the termination 201 of the Internet connectivity contract, e.g., the customer 202 moves to another service provider, it is recommended the 203 customer return the network addresses currently in use and 204 renumber into the new provider's address space. The ISP 205 should allow sufficient time for the renumbering process to be 206 completed before the IP addresses are reused. 208 ^L 210 2. To ensure efficient implementation and use of Classless 211 Inter-Domain Routing (CIDR), the Regional Registries issue 212 address space on appropriate "CIDR-supported" bit boundaries. 213 ISPs will also be made aware of the procedures that define bit 214 boundary IP address allocation, and they must use these 215 procedures when allocating IP address space to their respective 216 customers if offering portable address space. Please note, in 217 this document "portable" is used to describe addresses that 218 are permitted to be removed from an ISP CIDR block. 220 3. ISPs are required to utilize address space in an efficient 221 manner. To this end, registries should have documented 222 justification available for each assignment. The parent registry 223 may, at any time, ask for this information. If the information 224 is not available, future allocations may be impacted. 226 4. IP addresses are allocated to ISPs using a slow-start 227 procedure. New ISPs will receive a minimal amount based 228 on immediate requirement. Thereafter, allocated blocks may be 229 increased based on utilization verification supplied to the 230 regional registry. The parent registries are responsible for 231 determining appropriate initial and subsequent allocations. 232 Additional address allocations will provide enough address space 233 to enable the ISP to assign addresses for three months 234 without requesting additional address space from their parent 235 registry. Please note that projected customer base has little 236 impact on the address allocations made by the parent registries. 237 Initial allocation will not be based on any current or future 238 routing restrictions but on demonstrated requirements. 240 5. Due to the requirement to increase the utilization efficiency 241 of IPv4 address space, all assignments are made with the 242 assumption that sites make use of variable length subnet mask 243 (VLSM) and classless technologies within their network. Any 244 request for address space based on the use of classfull assumptions 245 will require a detailed justification. The use of classfull 246 technologies for the purposes of administrative convenience is 247 generally insupportable due to the limited availability of free 248 IPv4 address space. 250 6. Regional registries may set a maximum limit on assignment sizes 251 such that a second opinion of the regional registry is required. 253 ^L 255 7. Due to constraints on the available free pool of IPv4 address 256 space, the use of static IP address assignments (e.g., one 257 address per customer) for dial-up users is strongly discouraged. 258 While it is understood that the use of static addressing may 259 ease some aspects of administration, the current rate of 260 consumption of the remaining unassigned IPv4 address space does 261 not permit the assignment of addresses for administrative ease. 262 Organizations considering the use of static IP address assignment 263 are expected to investigate and implement dynamic assignment 264 technologies whenever possible. 266 2.2 Submission of Reassignment Information 268 It is imperative that reassignment information be submitted in a prompt 269 and efficient manner to facilitate database maintenance and ensure 270 database integrity. Therefore, assignment information must be 271 submitted to the regional registry immediately upon making the 272 assignment. The following reasons necessitate transmission of the 273 reassignment information: 275 a) to provide operational staff with information on who is using 276 the network number and to provide a contact in case of 277 operational/ security problems, 279 b) to ensure that a provider has exhausted a majority of its 280 current CIDR allocation, thereby justifying an additional 281 allocation, 283 c) to assist in IP allocation studies. 285 Procedures for submitting the reassignment information will be 286 determined by each regional registry based on its unique requirements. 288 All sub-registries (ISPs, Local registries, etc.) must register with 289 their respective regional registry to receive information regarding 290 reassignment guidelines. No additional CIDR blocks will be 291 allocated by the regional registry or upstream providers until 292 approximately 80% of all reassignment information has been submitted. 294 ^L 295 III. ASSIGNMENT FRAMEWORK 297 An assignment is the delegation of authority over a block of IP 298 addresses to an end enterprise. The end enterprise will use 299 addresses from an assignment internally only; it will not sub-delegate 300 those addresses. This section discusses some of the issues involved in 301 assignments and the framework behind the assignment of addresses. 303 In order for the Internet to scale using existing technologies, 304 use of regional registry services should be limited to the 305 assignment of IP addresses for organizations meeting one or 306 more of the following conditions: 308 a) the organization has no intention of connecting to 309 the Internet-either now or in the future-but it still 310 requires a globally unique IP address. The organization 311 should consider using reserved addresses from RFC1597. 312 If it is determined this is not possible, they can be 313 issued unique (if not Internet routable) IP addresses. 315 b) the organization is multi-homed 317 c) the organization's request is very large, for example, 318 the network prefix required to cover the request is 319 of length /18 or shorter. 321 All other requestors should contact their ISP for address 322 space or utilize the addresses reserved for non-connected networks 323 described in RFC1597 until an Internet connection is established. 324 Note that addresses issued directly from the IRs,(non-provider based), 325 are the least likely to be routable across the Internet. 327 3.1 Common Registry Requirements 329 Because the number of available IP addresses on the Internet is 330 limited, the utilization rate of address space will be a key factor 331 in network number assignment. Therefore, in the best interest of the 332 Internet as a whole, specific guidelines have been created to govern 333 the assignment of addresses based on utilization rates. 335 ^L 336 Although topological issues may make exceptions necessary, the basic 337 criteria that should be met to receive network numbers are listed 338 below: 340 25% immediate utilization rate 341 50% utilization rate within 1 year 343 The utilization rate above is to be used as a guideline, there may be 344 be occasions when the 1 year rate does not fall exactly in this range. 345 Organizations must exhibit a high confidence level in their 1 year 346 utilization rate and supply documentation to justify their level of 347 confidence. 349 Organizations will be assigned address space based on immediate 350 utilization plus 1 year projected utilization. A prefix longer than 351 /24 may be issued if deemed appropriate. Organizations with less than 352 64 hosts will not be issued an IP address directly from the IRs. 353 Organizations may be issued a prefix longer than /24 if the 354 organization can provide documentation from a registry recognized 355 ISP indicating the ISP will accept the long prefix for injection 356 into the global routing system. 358 Exceptions to the criteria will not be made based on insufficient 359 equipment without additional detailed justification. Organizations 360 should implement variable length subnet mask (VLSM) internally to 361 maximize the effective utilization of address space. Address 362 assignments will be made under the assumption that VLSM is or will 363 be implemented. 365 IP addresses are valid as long as the criteria is met. The IANA 366 reserves the right to invalidate any IP assignments once it is 367 determined the the requirement for the address space no longer exists. 368 In the event of address invalidation, reasonable efforts will be made 369 by the appropriate registry to inform the organization that the 370 addresses have been returned to the free pool of IPv4 address space. 372 3.2 Network Engineering Plans 374 Before a registry makes an assignment, it must examine each address 375 space request in terms of the requesting organization's networking 376 plans. These plans should be documented, and the following information 377 should be included: 379 1. subnetting plans, including subnet masks and number of 380 hosts on each subnet for at least one year 382 ^L 384 2. a description of the network topology 386 3. a description of the network routing plans, including the 387 routing protocols to be used as well as any limitations. 389 The subnetting plans should include: 391 a) a tabular listing of all subnets on the network 393 b) their associated subnet masks 395 c) the estimated number of hosts 397 d) a brief descriptive remark regarding the subnet. 399 If subnetting is not being used, an explanation why it cannot be 400 implemented is required. Care must be taken to ensure that the host 401 and subnet estimates correspond to realistic requirements and are not 402 based on administrative convenience. 404 3.3 Previous Assignment History 406 To promote increased usage of address space, the registries will 407 require an accounting of address space previously assigned to the 408 enterprise, if any. In the context of address space allocation, an 409 "enterprise" consists of all divisions and/or subsidiaries falling 410 under a common parent organization. The previous assignment history 411 should include all network numbers assigned to the organization, 412 plus the network masks for those networks and the number of hosts 413 on each (sub-)network. Sufficient corroborating evidence should be 414 provided to allow the assigning registry to be confident that the 415 network descriptions provided are accurate. 417 3.4 Network Deployment Plans 419 In order to assign an appropriate amount of space in the required time 420 frame, a registry may request deployment plans for a network. 421 Deployment plans should include the number of hosts to be deployed per 422 time period, expected network growth during that time period, and 423 changes in the network topology that describe the growth. 425 ^L 426 3.5 Organization Information 428 A registry may request that an organization furnish a published 429 description verifying that the organization is what it claims to be. 430 This information can consist of brochures, documents of incorporation, 431 or similar published material. 433 3.6 Expected Utilization Rate 435 As stated in the foregoing text, one of the key factors in determining 436 how much address space is appropriate for an organization is the 437 expected utilization rate of the network. The expected utilization 438 rate is the number of hosts connected to the network divided by the 439 total number of hosts possible on the network. In addition, the 440 estimated number of hosts should be projected over a reasonable time 441 frame, i.e., one in which the requesting enterprise has a high level 442 of confidence. The minimal utilization rate is set by the IANA and 443 may be changed at any time. New utilization rates may be enforced by 444 the regional registries prior to updating the written policy. 446 IV. OPERATIONAL GUIDELINES FOR REGISTRIES 448 1. Regional Registries provide registration services as their 449 primary function. Therefore, regional registries may charge some 450 fee for services rendered, generally in relation to the cost of 451 providing those services. 453 2. Regardless of the source of their address space, sub-registries 454 (Local IRs, ISPs, etc.) must adhere to the guidelines of their 455 regional registry. In turn, they must also ensure that their 456 customers follow those guidelines. 458 3. To maximize the effective use of address space, IP addresses need 459 to be assigned/allocated in classless blocks. With this in mind, 460 assignments will not be made in Class Cs or Bs but by prefix 461 length. Consequently, an organization that would have been 462 assigned a Class B in the past will now be assigned a /16 prefix, 463 regardless of the actual address class. 465 4. All IP address requests are subject to audit and verification 466 by any means deemed appropriate by the regional registry. 467 If any assignment is found to be based on false information, 468 the registry may invalidate the request and return the 469 assigned addresses back to the pool of free addresses for 470 later assignment. 472 ^L 474 5. Due to technical and implementation constraints on the Internet 475 routing system and the possibility of routing overload, major 476 transit providers may need to impose certain restrictions to 477 reduce the number of globally advertised routes. This may 478 include setting limits on the size of CIDR prefixes added to 479 the routing tables, filtering of non-aggregated routes, etc. 480 Therefore, addresses obtained directly from regional registry 481 (provider-independent, also known as portable) are not 482 guaranteed routable on the Internet. 484 6. Information provided to request address space is often considered 485 sensitive by the requesting organization. The assigning 486 registry must treat as confidential any and all information 487 that the requesting organization specifically indicates as 488 sensitive. When a requesting organization does not have 489 assurance of privacy, the parent of the assigning registry may 490 be required to do the assignment. In such cases, the parent 491 registry will provide the assigning registry with information 492 regarding the appropriate amount of address space to allocate. 494 7. The transfer of IP addresses from one party to another must be 495 approved by the regional registries. The party trying to obtain 496 the IP address must meet the same criteria as if they were 497 requesting an IP address directly from the IR. 499 V. In-ADDR.ARPA Domain Maintenance 501 The regional registries will be responsible for maintaining 502 IN-ADDR.ARPA records only on the parent blocks of IP addresses issued 503 directly to the ISPs or those CIDR blocks of less than /16. Local 504 IRs/ISPs with a prefix length of /16 or shorter will be responsible 505 for maintaining all IN-ADDR.ARPA resource records for their customers. 507 IN-ADDR.ARPA resource records for networks not associated with a 508 specific provider will continue to be maintained by the regional 509 registry. 511 VI. Right to Appeal 513 If an organization feels that the registry that assigned its address 514 has not performed its task in the requisite manner, the organization 515 has the right of appeal to the parent registry. 517 In such cases, the assigning registry shall make available all relevant 518 documentation to the parent registry, and the decision of the parent 519 registry shall be considered final (barring additional appeals to the 520 parent registry's parent). 522 ^L 524 VII. References 526 [RFC 1519] V. Fuller, T. Li, J. Yu, K. Varadhan, 527 "Classless Inter- Domain Routing (CIDR): an Address 528 Assignment and Aggregation Strategy". 530 [RFC 1518] Y. Rekhter, T. Li, "An Architecture for IP 531 Address Allocation with CIDR". 533 [RFC 1597] Y. Rekhter, B. Moskowitz, D. Karrenberg, G. de Groot, 534 "Address Allocation for Private Internets". 536 VIII. Authors' Addresses 538 Kim Hubbard 539 InterNIC Registration Services 540 c/o Network Solutions 541 505 Huntmar Park Drive 542 Herndon, VA 22070 543 Phone: (703) 742-4870 544 email: kimh@internic.net 546 Mark Kosters 547 InterNIC Registration Services 548 c/o Network Solutions 549 505 Huntmar Park Drive 550 Herndon, VA 22070 551 Phone: (703) 742-4795 552 email: markk@internic.net 554 David Conrad 555 Asia Pacific Network Information Center 556 c/o United Nations University 557 53-70 Jingumae 5-chome, 558 Shibuya-ku, Tokyo 150 559 JP 560 Phone: +81-3-5467-7014 561 email: davidc@APNIC.NET 563 Daniel Karrenberg 564 RIPE NCC 565 Kruislaan 409 566 SJ Amsterdam NL-1098 567 NL 568 Phone: +31 20 592 5065 569 email: dfk@RIPE.NET