------------------------------------------------------------------- APNIC Document identity Title: APNIC Internet Service Provider IP Address Request Form Short title: isp-address-request Document ref: APNIC-014 Version: 001 Date of original publication: 1 September 1995 Date of this version: 1 September 1995 Review scheduled: n/a Obsoletes: APNIC-001, APNIC-002 Status: Obsolete Comments: Obsoleted by APNIC-022 -------------------------------------------------------------------- APNIC Internet Service Provider IP Address Request Form Issued: August 1, 1995 Expires: September 1, 1995 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: isp-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 #[ISP TECHNICAL TEMPLATE V:1.0]# connectivity: conn-provider: cust-network: portable: classless: addr-now: addr-3mo: addr-6mo: #[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-016.txt For details on how to fill out the person template, please see ftp://archive.apnic.net/apnic/docs/apnic-017.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 Internet Service Provider 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 ISP 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. ISP Internet Service Provider Request Technical Details ------------------------------------------------------- connectivity: Please indicate how your network will be connecting to the Internet. Acceptible values for this field are PEERING-POINT, SERVICE-PROVIDER, or OTHER. The choice PEERING-POINT denotes the use of a neutral Internet exchange point at which three or more service providers share a common layer 2 or layer 3 infrastructure to exchange traffic. The choice of SERVICE-PROVIDER indicates the use of a organization which provides Internet connectivity services. The use of OTHER implies neither a peering point or service provider is being used and should be accompanied by a description of the means by which connectivity to the Internet is being obtained in the comments section. Example: connectivity: PEERING-POINT conn-provider: The organization providing your network with connectivity. In the case of PEERING-POINT connectivity, the name of the peering point(s) should be provided, using multiple conn-provider: lines as necessary to describe all peering points your network will connect to. In the case of SERVICE-PROVIDER connectivity, the name of the organization(s) providing the Internet services should be listed, using multiple conn-provider: lines as necessary. If you have indicated OTHER as your connectivity, please put appropriate information denoting the mechanism in which you will be obtaining connectivity. Example: conn-provider: MAE-West cust-network: If you have not been allocated networks in the past, please leave this field blank. If networks have been allocated to you, please provide the assignment information for those networks in the following format: cust-network: netname prefix/len hinit/h1yr/h2yr sinit/s1yr/s2yr where: netname is the name you assigned as found in the APNIC database prefix is the unique prefix for the network len is the length of the unique prefix hinit is the estimated number of hosts initially h1yr is the estimated number of hosts after one year h2yr is the estimated number of hosts after two years sinit is the estimated number of subnets initially s1yr is the estimated number of subnets after one year s2yr is the estimated number of subnets after two year Please use as many cust-network: fields as necessary to describe all customer networks which you have assigned. If you have assigned a network in a non-CIDR fashion, please submit multiple cust-network: fields which describe the assignment in CIDR fashion, repeating the network name as necessary. Example: cust-network: FOO-AP 202.12.28.0/25 10/15/80 1/1/2 cust-network: BAR-AP 202.12.28.128/25 60/70/100 2/3/4 portable: If you will allow customers to keep addresses assigned to them from the CIDR block you are requesting, i.e. the addresses you assign are portable between providers, indicate YES for this attribute. If not, indicate NO. No other values are allowed. It should be stressed that due to limitations currently being experienced in the Internet the use of portable address space is *STRONGLY* discouraged. See the supporting notes for more details. Example: portable: NO classless: If your network is entirely classless, please indicate YES here. If not, please indicate NO and provide additional information as to why your network is not classless in the comments section of the application. Note that APNIC will make assumptions of appropriate levels of address utilization based on the value of this attribute. Example: classless: YES addr-now: Please provide an accurate accounting of the number of host addresses (NOT networks or "blocks") you will need immediately (i.e., within one month). Please be sure to include all devices which will need global Internet connectivity including your internal infrastructure such as routers, terminal servers, service machines, printers, etc. and the number of host addresses you will need for customers you will be connecting immediately upon commencment of use of the block allocated. Providing a description of your network topology in the commment section of the form may prove helpful. Example: addr-now: 150 addr-3mo: Please provide an accurate estimate of the number of host addresses (NOT networks or "blocks") you will need in the upcoming 3 months, including addresses which will be necessary for infrastructure buildout, expected customers, etc. Please be sure to include all devices which will need global Internet connectivity and thus addresses from your provider block. Example: addr-3mo: 500 addr-6mo: Please provide an accurate estimate of the number of host addresses (NOT networks or "blocks") you will need in the upcoming 6 months. Please be sure to include all devices which will need global Internet connectivity and thus addresses from your provider block. Example: addr-6mo: 1100 Supporing Notes --------------- 1. Provider Based Addressing 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, you have 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 from outside of a service provider block, it means those addresses 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. In general, the smaller the number of hosts you or your customer's address block can address, the more likely it is to be ignored. Note that networks being ignored can occur any time in any part of the world and 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 a customer switches service providers, they should renumber their machines into the new service provider's address space as otherwise, the old addresses will need to reach the global routing table. While it is acknowledged that renumbering is rarely a trivial task, most modern implementations of TCP/IP support or come with dynamic IP address assignment technologies such as DHCP or Bootp. These technologies greatly simplify the tasks associated with renumbering hosts as customers will generally only need to modify the dynamic IP address server, the DNS, and the routers. Since it is in most Internet users' interests to insure the Internet continues to function and reaches as many places as possible, the registries **STRONGLY** encourage sites to obtain addresses from their service providers and to return those addresses when they change service providers. Registries also encourage service provider include wording in their conectivity contracts which insure addresses are returned to the service provider when connectivity terminates. With these steps, the Internet can continue to grow at its current rate while also providing customers with the global connectivity they have come to expect. 2. APNIC Allocation Procedures When a service provider first contacts APNIC, we will allocate to them a small block to be used for their internal infrastructural needs and their first customers. Generally, APNIC will allocate a /22 (4 class C networks) to ISPs when they first approach APNIC even if their host requirements do not imply the need of a /22. If a /22 is not sufficient for the ISP to provide for its infrastructure, APNIC will request detailed plans for the implementation of their network. Note that exceptions, while rare, are made if sufficient justification can be supplied. In order to insure the highest probability that an ISP's network is not filtered as described in the previous section, APNIC will guarantee at least a /19 (32 class C networks) of contiguous space is available to the ISP. Additional space will be made available as necessary, but that space may not be in the same contiguous block (although all ISP blocks will be of at least /19 in prefix length). As an aide to the diagnosis and resolution of network problems, APNIC provides the APNIC Registration Database to the Internet. In order for this database to provide benefit, it must be kept up to date. As such, as the ISP assigns network addresses to customers, the ISP should update the APNIC database using the procedures defined in ftp://archive.apnic.net/apnic/docs/apnic-019.txt In addition to providing up to date registration information for an ISPs customers, APNIC uses the database and the rate of database update as a gauge on the growth rate of the ISP. When an ISP first comes to APNIC, APNIC reserves address space in addition to that allocated to the ISP for future growth. APNIC then adjusts the reserved space based on the ISPs growth pattern in order to both minimize the number of routes the ISP will announce as well as reduce the amount of address space locked away as reserved. When an ISP consumes approximately 70% - 80% of the space initially allocated to it by APNIC, it should submit another Internet Service Provider IP address request form to request additional space. ISPs should also request additional space if a single customer will consume more space than the ISP has available (the ISP should NOT refer the customer to APNIC). The ISP should make sure the cust-network: fields of the new application are filled in and accurately reflect the customer requests the ISP received. APNIC will review the information provided in the cust-network: fields as well as the information in the APNIC database and allocate additional space. The size of new allocations will depend on a high level of address space utilization assigned to customers as well as timely and accurate updates of the APNIC Registration database. If the information provided in the application and the APNIC Registration database is within established parameters, APNIC will allocate additional space, typically doubling the current allocation. The eventual goal is to provide enough address space to the ISP such that it can satisfy customer requests for a period of three to six months. As such, the actual amount of address space allocated will be determined dynamically based on the consumption rate of the ISP. While it is acknowledged this allocation mechanism will likely result in less than optimal request and allocation behavior for the first few transactions, it does have the benefit of insuring relatively little address space wastage due to over-reservation while also providing a means by which the ISP can (eventually) reach a reasonable level of address self-sufficiency. 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 These documents are all 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 (usally 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 file. 2. via gopher from host gopher.apnic.net Using your gopher application (usually called 'gopher'), connect to host gopher.apnic.net. For RFCs go down the "Information About Internet" branch, then down the "RFCs, FYIs, & STDs" branch and choose the correct RFC branch to go down. For APNIC documents, go down the "Information about APNIC branch, then the "docs" branch, then the "english" branch. The actual mechanism you use to traverse branches of the gopher tree depends on your gopher application. 3. 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. Organizations without connectivity wishing to obtain copies of the "Recommended Reading" articles should contact the APNIC or their local or national 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 .