------------------------------------------------------------------- APNIC Document identity Title: APNIC Enterprise IP Address Request Form Short title: enterprise-address-request Document ref: APNIC-023 Version: 001 Date of original publication: 1 September 1995 Date of this version: 1 September 1995 Review scheduled: n/a Obsoletes: APNIC-015 Status: Obsolete Comments: Obsoleted by APNIC-032 -------------------------------------------------------------------- APNIC Enterprise IP Address Request Form Issued: September 1, 1995 Expires: January 31, 1996 Please see comments at the bottom of this form regarding how to complete this application. Note that this form is parsed by machine and modification of lines starting with #[ or the field names will likely result in strange errors being returned to you and your request not being processed. After completing this form, please submit it via email to: ip-request@rs.apnic.net or in type written English via fax (discouraged) to: +81-3-5276-6239 or in type written English via postal mail (as a last resort) to: Asia Pacific Network Information Center c/o The United Nations University 53-70, Jingumae 5-Chome, Shibuya-ku, Tokyo 150, Japan If you have any questions, you may contact us via email at hostmaster@apnic.net (preferred), fax at the above number, postal mail at the above address or via telephone at +81-3-5276-3973. Note that we do not accept address requests via telephone. Please allow up to one week for processing electronic mail requests and up to one month for other forms of submission. NOTE: IT IS NOT NECESSARY TO INCLUDE THIS HEADER NOR THE INSTRUCTIONS AT THE BOTTOM OF THIS FORM WITH YOUR APPLICATION. - - - - - - - - - - - - - CUT HERE - - - - - - - - - - - - - - - #[NETWORK TEMPLATE V:3.0]# netname: descr: descr: country: admin-c: tech-c: changed: notify: mnt-by: source: APNIC #[PERSON TEMPLATE V:3.0]# person: address: address: phone: fax-no: e-mail: nic-hdl: changed: notify: mnt-by: source: APNIC #[PERSON TEMPLATE V:3.0]# person: address: address: phone: fax-no: e-mail: nic-hdl: changed: notify: mnt-by: source: APNIC #[ENTERPRISE TECHNICAL TEMPLATE V:2.0]# acct-no: host-bits: connect: classless: single-home: service-provider: service-provider: network-plan: country-net: old-network: #[TEMPLATES END]# Comments: - - - - - - - - - - - - - - CUT HERE - - - - - - - - - - - - - - - - - Instructions For Completing This Form ------------------------------------- For details on how to fill out the network template, please see ftp://archive.apnic.net/apnic/docs/apnic-024.txt For details on how to fill out the person template, please see ftp://archive.apnic.net/apnic/docs/apnic-025.txt. IF YOU HAVE AN APNIC ISSUED NIC HANDLE, PLEASE USE IT INSTEAD OF FILLING IN THE REST OF THE PERSON TEMPLATE. If you have filled in NIC handles for the admin-c and tech-c fields of the network template and no aspect of the person's contact information has changed, you DO NOT need to complete the person templates -- please leave the fields blank. Below are the instructions for filling in the technical details for an APNIC Enterprise IP Address Request Form. Please provide attributes for the tags listed correctly. Failure to do so may result in delays in service. Information provided in the ENTERPRISE TECHNICAL TEMPLATE will be kept in strict confidence. Information provided in the NETWORK and PERSON templates will be made available over the Internet. As always, if you have any questions or comments regarding this form, please contact hostmaster@apnic.net at your convenience. Enterprise IP Address Request Technical Details ----------------------------------------------- acct-no: Please provide your APNIC account number if you have one. If you do not have an APNIC account number, please see APNIC-030 available from: ftp://archive.apnic.net/apnic/docs/apnic-030.txt Example: acct-no: 208789233 host-bits: Please indicate the type of request you are making in terms of BITS of host address space, NOT hosts, host addresses, networks or "blocks". This format reflects the classless network architecture the Internet is moving towards. For example, a request with host-bits: 8 would indicate 2**8 (256) possible host addresses, equivalent to a single class C network in the (deprecated) classfull terminology. Please use the following guidelines derived from RFC 1466 to determine how many host-bits you should request: Requires fewer than 62 addresses -> 6 host address bits (a /26) 126 addresses -> 7 host address bits (a /25) 254 addresses -> 8 host address bits (a /24 or 1 class C network) 510 addresses -> 9 host address bits (a /23 or 2 class C networks) 1022 addresses -> 10 host address bits (a /22 or 4 class C networks) 2046 addresses -> 11 host address bits (a /21 or 8 class C networks) 4094 addresses -> 12 host address bits (a /20 or 16 class C networks) 8190 addresses -> 13 host address bits (a /19 or 32 class C networks) 16382 addresses -> 14 host address bits (a /18 or 64 class C networks) 32766 addresses -> 15 host address bits (a /17 or 128 class C networks) 65534 addresses -> 16 host address bits (a /16 1 class B network) Note that large request may require significant additional documentation. Example: host-bits: 9 connect: Will your network be connecting to the global Internet? Please indicate one of: YES you plan on being fully connected, e.g. all (or most) hosts on your network will have full access to (and be fully accessible from) the global Internet with the inherent security risks this implies. PARTIAL part of the network will be connected, but a majority of the hosts on the network your are requesting addresses for will not be global Internet accessible. NO you have no intention of having any part of the network connected to the Internet. UNSURE your plans on connecting to the Internet aren't established at this time. If you answer PARTIAL or NO, we request you review RFC 1597 (but, for a contrary view, please see RFC 1627). If you decide that RFC 1597 private nets will suffice for your needs, you do not need to submit a form to APNIC. If you will be connecting to the Internet, we strongly recommend you obtain address space from your service provider, not from APNIC. Example: connect: YES classless: Will your network be entirely classless? In this context, 'classless' means that your entire network supports variable length subnet masks and that you exchange classless routing information with your service provider. Please answer YES, NO, or UNSURE. Example: classless: YES single-home: Will your network be connected to the global Internet via exactly one service provider? If you are not attaching to the Internet, please leave this field blank. If you will connect through a single provider, please answer, YES, otherwise answer NO. single-home: YES service-provider: Please provide the name and address of your service provider using multiple service-provider: lines as necessary. If you are not connecting or you are unsure of who you are connecting through, you may leave this field blank. Note: it is requested that you contact your service provider for address space BEFORE coming to APNIC. Example: service-provider: FOONet, Inc. service-provider: Fubar Bldg., Suite 1234 service-provider: 5678 North Rd. service-provider: South Nowhere, 90123 service-provider: Bhutan network-plan: Please provide a summary of your network plans for the next two years. The format of this field is: where: is the dotted decimal network number (preceded by x's, e.g. x.x.0.0) is the netmask for the network in dotted decimal form, e.g. 255.255.255.240 is the number of devices initially planned on the network is the number of devices planned on the network after 1 year is the number of devices planned on the network after 2 years is a descriptive remark about the network. Please separate each field with at least one space. You may use as many network-plan: fields as necessary to accurately describe your network. In your device estimates, be sure to include all devices which will need globally unique IP numbers, including PCs, workstations, servers, printers, routers, etc. Be sure to specify valid network numbers (with the exception of the leading prefix) and associated network masks in order to convey the actual layout of your network, do NOT simply replicate one line for each sub-network. Example: network-plan: x.x.0.0 255.255.255.240 1 5 11 support group network-plan: x.x.0.16 255.255.255.240 4 8 8 customer svc network-plan: x.x.0.32 255.255.255.240 10 10 10 int. dial up network-plan: x.x.0.48 255.255.255.240 2 10 12 marketting network-plan: x.x.0.64 255.255.255.192 0 0 0 spare network-plan: x.x.0.128 255.255.255.128 1 64 126 customer lines network-plan: x.x.1.0 255.255.255.0 0 128 254 customer lines country-net: Please provide a list of the ISO-3166 country codes for the countries your network will be connected in via YOUR infrastructure, each country code separated by spaces or by using multiple country-net: lines. Do NOT put down countries to which your network will be connected via the Internet as you would need to put approximately 130 countries and this field in everybody's application would be the same. If you do not know the ISO-3166 country code, the list of ISO 3166 country codes found in ftp://archive.apnic.net/apnic/misc/iso-3166.txt. Example: country-net: JP AU KR ID country-net: SG TW TH MN TO old-network: If any part of your organisation has received address space in the past, please specify the actual network numbers allocated specifying the number of devices on each network using the following format: where: is the dotted decimal network number (preceded by x's, e.g. x.x.0.0) is the netmask for the network in dotted decimal form, e.g. 255.255.255.240 is the number of devices on the network is yes or no, depending on whether the network is connected to the Internet is a descriptive remark about the network. If your organizations has not had networks allocated to you in the past, please leave this field blank. For the purposes of this field, an organization is all parts of an enterprise which is found under a common domain tree sub-tree not administered by a registry, e.g., all networks which would be listed under the domain 'foo.com' would comprise an organization. Example: old-network: 202.5.10.0 255.255.255.0 220 YES R&D Division old-network: 202.5.11.0 255.255.255.128 104 YES Marketting old-network: 202.5.11.128 255.255.255.128 112 YES Sales source: Source of the information. It will always be APNIC. This is information which is always required in the database, so it has been added already. Example: source: APNIC Supporting Notes ---------------- 1. Advisability of Obtaining Enterprise Address Space In short, APNIC strongly recommends AGAINST organizations obtaining provider independent address space from APNIC or any other non-provider registry. In order for the Internet to continue to grow at its current rate, Internet addresses must be allocated hierarchically. Doing so allows for addressing information to be hidden so it need not be known globally (an example of hierarchical addressing is the telephone system. A phone switch in Italy has no knowledge of how to reach a particular phone in Japan, all it knows is how to reach the exchange for numbers not directly attached to the switch. The exchange knows how to reach the international trunking system which knows where exchanges in other countries are, etc). To implement hierarchical addressing, the assignment of addresses must be made in ways sensitive to the topology of the network. In the Internet, Internet service providers define the network topology, therefore if the Internet is to scale, addresses must be assigned by Internet service providers. In this way, the global routing system only need know how to get to Internet service providers. Today, the global routing system advertises around 30,000 networks. At this level, the Internet is (and has been) on the edge of breaking. Symptoms of this breakage are routers running out of memory (causing them to crash, reboot, come back up, run out of memory, crash, ...) or run out of CPU trying to compute how to reach each and every one of those 30000 sites (every time a network comes up or goes down, it is necessary to recompute how to get to the all the sites on the network. This is aggravated by the memory problem mentioned above). The end result of these problems is that parts of the Internet fall off (become unreachable). If a site joins the Internet using addresses allocated outside of a service provider block, it means it must be added to the global routing tables. In order to protect their customers and insure their network is functional (since many sites aren't interested in the Internet per se, but instead use the Interent to connect up branch offices, etc), some ISPs (particularly large transit providers in the US) are now ignoring some out-of-block network advertisements and/or refusing to accept networks from customers outside the service provider's block. In general, the smaller the number of hosts your address block can address, the more likely it is to be ignored. Note that reachability being refused can occur any time in any part of the world and what it means is you will not be able to reach anyone on the network which is ignoring you (nor they you). To combat this problem, registries recommend to sites requesting address space they obtain the address space from their service provider. Service provider blocks are generally large enough so that they won't be ignored. If you have not yet chosen a service provider, you will be asked to present evidence that at least one APNIC registered service provider in your area will accept your provider independent network block, however it must be stressed that ALLOCATION OF ADDRESS SPACE BY APNIC IN NO WAY INSURES THE ROUTABILITY OF THAT ADDRESS SPACE, EITHER NOW OR IN THE FUTURE. Since it is in most Internet user's interests to insure the Internet continues to function and reaches as many places as possible, the registries **STRONGLY** encourage sites obtain addresses from their service providers and to return those addresses when they change service providers. 2. "Non-Connected" Networks and RFC 1597 Current assignment guidelines require address space be used efficiently. If there is no plan to connect the networks for which address space is requested to the Internet for security reasons or otherwise, or if you wish to reserve address space for administrative convenience, please evaluate if RFC 1597 is appropriate for your network (or part thereof). This RFC contains important information regarding the policies/procedures that should be used when IP address space is requested for networks that do not plan to connect to the Internet in the foreseeable future. However, it should be noted the use of RFC 1597 private networks is somewhat controversial. In order to provide a balanced view, we recommend reading both RFC 1597 and a contrary view found in RFC 1627. If you have any questions regarding the applicability of these RFCs to your particular case, please contact APNIC. 3. Additional Hints when Requesting Additional Address Space When additional network numbers are needed by an organisation, the application should include information on the utilization of address space already held by the same organisation. This information needs to include the number of actually used/unused IP network numbers, the number of actually installed subnets, hosts connected to these and more structural information which may be appropriate to substantiate the new request. This data for previously assigned network numbers provides essential input for global monitoring of utilization of IP address space and feedback to registry operation. To summarise the object of requesting this information is to: o ensure proper use is made of the available address space o have single contiguous blocks of addresses assigned if possible (so routing information can be aggregated) For this a good estimate of real network requirements is needed and planning not just for the immediate needs or a specific parts of a network is encouraged. 4. Additional Hints for Requesting "Class B" Network Numbers The criteria for allocating "Class B" network addresses are extremely strict. This is due to the global scarcity of these network numbers. Out of necessity, the local registries and APNIC must closely examine each and every request received for a "class B" network address. As a result, the allocation process for "class B" requests will take longer. Organisations can speed up the process by providing as much information as possible on their initial request to enable a decision to be made without having to request more information. The number of hosts estimated should be substantiated with other data about the network and/or organisation like number of employees, geographical distribution, type of hosts, etc. The clearer you can document that your estimates are carefully derived, the easier it is for us to justify allocation of a "class B" address. Besides a sufficient number of hosts we must determine that your network cannot be engineered using a number of contiguous "class C" networks. If your network consists of a large number of physical networks with relatively small numbers of hosts on each, you will need to consider subnetting class C networks. A large number of subnetworks alone is not sufficient justification for allocation of a class B network number. We realise that a number of engineering decisions can be based on administrative convenience. Unfortunately the remaining class B address space is too small to take these considerations into account. The clearer your explanation is, as to why your network *cannot* be engineered using a block of class C network numbers, the easier it is for us to justify allocation of a class B network address. All the above mentioned points apply even more strongly to cases where multiple class B network numbers are requested. Assignments of multiple class B network numbers will only occur when your local registry, APNIC, and perhaps the IANA are convinced with a detailed justification in terms of the criteria mentioned. Appendices ---------- Appendix A -- Example Templates Example of a completed network, person and technical template #[NETWORK TEMPLATE V:3.0]# netname: TBIT2 descr: Terabit Labs Inc. descr: Network Bugs Feeding Facility descr: Northtown country: NA admin-c: JD0401-NA tech-c: Mark A Smith changed: johndoe@terabit.na 940625 notify: dbmon@apnic.net mnt-by: TERABIT-NA source: APNIC #[PERSON TEMPLATE V:3.0]# person: John E Doe address: Terabit Labs Inc. address: Industrial Estate North address: North Perpendicular Road 12 address: NL-1234 Northtown address: Nauru phone: +31 20 987 6542 ext. 4711 fax-no: +31 20 123 3467 e-mail: johndoe@terabit.na nic-hdl: JD0401-NA changed: johndoe@terabit.na 940625 notify: dbmon@apnic.net source: APNIC #[PERSON TEMPLATE V:3.0]# person: Mark A Smith address: Terabit Labs Inc. address: Industrial Estate North address: North Perpendicular Road 12 address: NL-1234 Northtown address: Nauru phone: +31 20 987 6542 ext. 4712 fax-no: +31 20 123 3467 e-mail: mark.smith@terabit.na nic-hdl: changed: mark.smith@terabit.na 940625 notify: johndoe@terabit.na source: APNIC #[ENTERPRISE TECHNICAL TEMPLATE V:1.0]# host-bits: 8 connect: yes classless: yes single-home: yes service-provider: Brokenet, Inc. service-provider: P. O. Box 1234 service-provider: Ocean City, 102 service-provider: Nauru network-plan: x.x.0.0 255.255.255.0 4 128 230 campus net country-net: NA TO FJ old-network: 202.10.5.0 255.255.255.0 224 YES campus net source: APNIC Appendix B -- References RFC 1466 E. Gerich, "Guidelines for Management of IP Address Space", 5/26/93, URL: ftp://archive.apnic.net/ietf/rfc/rfc1466.txt RFC 1517 R. Hinden, "Applicability Statement for the Implementation of Classless Inter-Domain Routing (CIDR), 9/24/93, URL: ftp://archive.apnic.net/ietf/rfc/rfc1517.txt RFC 1518 Y. Rekhter, T. Li, "An Architecture for IP Address Allocation with CIDR", 9/24/93, URL: ftp://archive.apnic.net/ietf/rfc/rfc1518.txt RFC 1519 V. Fuller, T. Li, J. Yu, K. Varadhan, "Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", 9/24/93, URL: ftp://archive.apnic.net/ietf/rfc/rfc1519.txt RFC 1597 Y. Rekhter, R. Moskowitz, D. Karrenberg, G. de Groot, "Address Allocation for Private Internets", 3/17/94, URL: ftp://archive.apnic.net/ietf/rfc/rfc1597.txt RFC 1627 E. Lear, E. Fair, D. Crocker, T. Kessler, "Network 10 Considered Harmful (Some Practices Shouldn't be Codified)", 7/1/1994, URL: ftp://archive.apnic.net/ietf/rfc/rfc1627.txt APNIC documents (not commercially available publications) are available from the APNIC document store in the directories mentioned in the URLs. The APNIC document store can be accessed in a number of ways: 1. via anonymous FTP from host archive.apnic.net Using your ftp application (usually called simply 'ftp'), connect to host archive.apnic.net using your email address as the password. For RFCs, use the "change directory" command (typically 'cd') to '/ietf/rfc'. For APNIC documents, 'cd' to '/apnic/docs'. You may then use the "get" command (typically 'get') to retrieve the specific file. 2. via electronic mail through the APNIC FTP Email gateway You may send mail to 'ftpmail@postoffice.apnic.net' with the body of the message being standard Unix 'ftp' commands. For more help, send an email message to 'ftpmail@postoffice.apnic.net' with a message body consisting of 'help'. Results will be mailed back to you. 3. via WWW to http://rs.apnic.net/archive Using your WWW browser, e.g. Mosaic, Netscape, etc. connect to the URL mentioned above and click on the appropriate subdirectory. Note the APNIC registration service web serve is currently under construction. 4. via gopher to gopher.apnic.net Using your gopher application (usually called 'gopher'), connect to gopher.apnic.net. Move to the "Information about APNIC" branch (choice number 3), then choose the docs branch (choice 2) then choose the appropriate document. If you are looking for IETF documents, choose the "Information About Internet" branch (choice 7), then the "IETF Information" branch (choice 1). Organizations without connectivity wishing to obtain copies of the referenced documents should contact the APNIC or their local registry to arrange postal delivery of one or more of the above documents. Note that some fee may be associated with the delivery of hardcopy versions of documents. Acknowledgements ---------------- This document in derived in large part from documents written by the staff of the European Registry, RIPE-NCC .