------------------------------------------------------------------- APNIC Document identity Title: APNIC Enterprise IP Address Request Form Short title: enterprise-address-request Document ref: APNIC-042 Version: 001 Date of original publication: 12 November 1996 Date of this version: 12 November 1996 Review scheduled: n/a Obsoletes: APNIC-032 Status: Obsolete Comments: Obsoleted by APNIC-062 -------------------------------------------------------------------- APNIC Enterprise IP Address Request Form Issued: November 12, 1996 Expires: May 12, 1997* *) This form is valid until superseded by another form. After the date specified, please check the APNIC document store located at ftp://ftp.apnic.net/apnic/docs for a later version of this form. This form is intended for use by organizations requesting address space for their own INTERNAL use. If you will be sub-delegating address space to outside organizations not related to your company, you are considered an Internet service provider for the purposes of address allocations and thus should use form APNIC-041 (available at: ftp://ftp.apnic.net/apnic/docs/apnic-041.txt). If you are a confederation of service providers, that is a group of Internet service providers which have agreed on a single entity which will interact with APNIC, you should use form APNIC-043 (available at: ftp://ftp.apnic.net/apnic/docs/apnic-043.txt). 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-5500-0481 or in type written English via postal mail (as a last resort) to: Asia Pacific Network Information Center Tokyo Central Post Office Box 351 Tokyo, 100-91, Japan If you have any questions regarding this form, 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-5500-0480. 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: PLEASE DO NOT INCLUDE THIS HEADER NOR THE INSTRUCTIONS AT THE BOTTOM OF THIS FORM WITH YOUR APPLICATION. - - - - - - - - - - - - - CUT HERE - - - - - - - - - - - - - - - #[NETWORK TEMPLATE V:4.0]# netname: descr: descr: country: admin-c: tech-c: rev-srv: rev-srv: changed: mnt-by: source: APNIC #[PERSON TEMPLATE V:4.0]# person: address: address: country: phone: fax-no: e-mail: nic-hdl: changed: mnt-by: source: APNIC #[PERSON TEMPLATE V:4.0]# person: address: address: country: phone: fax-no: e-mail: nic-hdl: changed: mnt-by: source: APNIC #[ENTERPRISE TECHNICAL TEMPLATE V:3.0]# acct-name: host-bits: connectivity: conn-provider: all-0s-subnets: all-1s-subnets: supernets: subnets: hosts-now: hosts-6mo: hosts-1yr: network-plan: network-plan: old-network: old-network: #[TEMPLATES END]# Explantion why you cannot obtain addresses from your service provider: Additional Comments: - - - - - - - - - - - - - - CUT HERE - - - - - - - - - - - - - - - - - 1.0 Instructions For Completing This Form ----------------------------------------- Below are the instructions for filling in an APNIC Enterprise IP Address Request Form. It is *EXTREMELY* important you provide attributes for the tags listed below correctly. Failure to do so WILL result in delays in service and thus may delay when you will receive the IP addresses you require. Information provided in the ENTERPRISE TECHNICAL TEMPLATE will be kept in strict confidence, thus security reasons are not sufficient to leave fields blank. For further clarification on this issue, please contact hostmaster@apnic.net. Information provided in the NETWORK and PERSON templates will be made available over the Internet via WHOIS to whois.apnic.net, WAIS to wais.apnic.net (database APNIC), and ftp from the following URL: ftp://ftp.apnic.net/apnic/dbase/data/apnic.db This information is provided to the Internet community to aid in diagnosing and resolving issues related to the operation of the Internet. Any use outside of this context is expressly prohibited without written permission from APNIC, Ltd. As APNIC applications are machine processed, application forms *MUST* be submitted in plain ASCII, do not use MIME encoding unless that MIME encoding can be viewed without any form of decoding. In particular, do NOT encode your application using BASE64 encoding techniques. In addition, do not attempt to format your application in any fashion, e.g., do not justify text or insert extra blank lines between lines in a template. Failure to observe these restrictions will likely result in syntax errors being returned to you as the automated parsing system is not prepared to handle large deviations from the format presented in the form above. An example of a completed form is provided below. As always, if you have any questions or comments regarding this form, please contact hostmaster@apnic.net at your convenience. 2.0 Enterprise IP Address Request Network Template Details ---------------------------------------------------------- NETNAME: Please complete with an appropriate name which is short and meaningful for your enterprise. The NETNAME is used mainly for administrative purposes such as consistency checking of the Internet Registry. The network name should be written as a SINGLE word in less than 25 capital alphanumeric characters ONLY. Please do NOT use punctuation, special characters or a prefix or suffix of 'NET', 'LAN', etc (unless they are part of your company name). In order to tag network names as being found within the APNIC registry, APNIC will append '-AP' to your network name before it is entered into the APNIC database. Please do NOT use domain names, such as FOO.COM, as the network name has no relation with the domain name system. There should be exactly one NETNAME tag per NETWORK template. Example: netname: TBIT DESCR: Please complete with a short description of the organization, including the location providing sufficient detail as to distinguish your organization from others in the APNIC database, i.e., "descr: Computer Center" is not sufficient. Do NOT put advertising information such as 'The best maker of bars in Foo' in your description and please limit the number of DESCR lines to 5. This tag is required for all NETWORK templates. Example: descr: Terabit Labs Inc. descr: Network Bugs Feeding Facility descr: Northtown COUNTRY: Please give the two letter country code (ISO 3166) which is appropriate for the organisation requesting address space. Do NOT provide the country name or the three letter ISO 3166 country code. Please see the table of ISO 3166 codes maintained on APNIC at ftp://ftp.apnic.net/apnic/misc/iso-3166.txt if you do not know the appropriate ISO 3166 code for your country. We are aware listing a country may be ambiguous for networks crossing national boundaries, so choose the most appropriate country based on the location of the administrative contact. This tag is required for all NETWORK templates, with only one COUNTRY tag permited. Example: country: JP ADMIN-C: Please provide the NIC handle of the person who is the administrative contact for the network or the name of the person matching *EXACTLY* the name to be provided in a subsequent PERSON template if you do not have a NIC handle. The NIC handle (if known) is greatly preferred and will result in minimal delays when processing your request. The administrative contact must be someone who is physically located at the site of the network. If you specify a name instead of a NIC Handle, please do NOT use titles like `Dr' or `Prof.' or `Sir' as the words which comprise a name are indexed and there are many people with the same titles. Further, please provide full given names, not initials as single characters are not indexed within the database. Please list the name as you would be addressed in a letter salutation (e.g., given name followed by family name or family name followed by given name depending on the custom in your country). At least one ADMIN-C tag is required for all NETWORK templates. Example: admin-c: JD1-AP admin-c: John E Doe TECH-C: Please provide the NIC handle of the person who is the technical contact for the network or the name of the person matching *EXACTLY* the name to be provided in a subsequent PERSON template if you do not have a NIC handle. The NIC handle (if known) is greatly preferred and will result in minimal delays when processing your request. The technical contact need not be physically located at the site of the network, but rather is the person who is responsible for the day-to-day operation of the network. If you specify a name instead of a NIC Handle, please do NOT use titles like `Dr' or `Prof.' or `Sir' as the words which comprise a name are indexed and there are many people with the same titles. Further, please provide full given names, not initials as single characters are not indexed within the database. Please list the name as you would be addressed in a letter salutation (e.g., given name followed by family name or family name followed by given name depending on the custom in your country). At least one TECH-C tag is required for all NETWORK templates. Example: tech-c: MS4-AP tech-c: Mark A Smith REV-SRV: The rev-srv attribute contains the fully qualified domain name of the machine that runs a reverse domain name service for the address space. Please use a fully qualified domain name, do NOT put the internet address of the host. If there are multiple reverse name servers for this address space (and there should be at least two), they should all be specified on different lines. Only one hostname is allowed per line. You may have zero or more rev-srv: tags per NETWORK template. Example: rev-srv: ns.apnic.net rev-srv: ns.uu.net REMARKS: The remarks attribute contains any remarks about this address space that cannot be expressed in any of the other attributes. Although multiple lines are allowed, it should be only be used if it provides extra information to users of the database, and usage should be kept to a minimum. Example: remarks: will be returned to NIC 950101 CHANGED: Please indicate the e-mail address of the person who is completing the template followed by the current date in the format of YYMMDD (YY is the current year, MM is the month and DD is the day, all values 0 filled). If you do not have e-mail connectivity please leave blank and it will be filled in for you. Do not put "Please Assign" or similar for this field. If you have an e-mail address, you should supply exactly one changed: tag per NETWORK template if this is an application for new addresses. Example: changed: johndoe@terabit.na 950225 MNT-BY: Please provide the appropriate maintainer ID. The maintainer ID provides some level of authorization control over who can update an object protected by a mnt-by: field. If you do not have a maintainer ID, you may either leave this field blank and a default maintainer ID will be created for you (one without any authentication protection) or you may apply for one using the APNIC Maintainer Object Request form found at: ftp://ftp.apnic.net/apnic/docs/apnic-045.txt There can be zero or more MNT-BY tags per NETWORK template, however each maintainer object specified must already exist in the APNIC Registration database. Example: mnt-by: MAINT-FOO-AP SOURCE: Source of the information. For the purposes of APNIC forms, it will always be APNIC. This is information which is always required in the database, so it has been added to the forms already. Example: source: APNIC 3.0 Enterprise IP Address Request Person Template Details --------------------------------------------------------- PERSON: Please give the full name of the person this template will represent. If you have provided the person's name in the ADMIN-C or TECH-C fields of the NETWORK template (i.e., the person does not yet have a NIC handle), the names MUST be written identically to those provided in the fields. Please do not use formal titles like `Dr' or `Prof.' or `Sir' as the words which comprise a name is indexed and there are many people with the same titles and list the name as you would be addressed in a letter salutation (e.g., given name followed by family name or family name followed by given name depending on the custom in your country). Further, as single characters are not indexed, please provide the full given name. There can be exactly one PERSON field in a PERSON template. Example: person: John E Doe ADDRESS: Please complete with the full postal address written as you would for international postal mail using one line for each part of the address as shown below. Example: address: Terabit Labs Inc. address: Industrial Estate North address: North Perpendicular Road 12 address: NL-1234 Northtown COUNTRY: Please give the two letter country code (ISO 3166) which is appropriate for the contact person. Do NOT provide the country name or the three letter ISO 3166 country code. Please see the table of ISO 3166 codes maintained on APNIC at ftp://ftp.apnic.net/apnic/misc/iso-3166.txt if you do not know the appropriate ISO 3166 code for this person's address. This tag is required for all PERSON templates, with only one COUNTRY tag permited. Example: country: JP PHONE: Please provide the work telephone number of the person specified above as it would be dialed internationally in your country (WITHOUT the prefix necessary to reach an international line). Please do not include the leading zero when specifying their area/city code unless it is required to correctly dial the number internationally. The format for the telephone number is: +--- If an extension is necessary, please add "ext ". Please do not put 'x' or other abbreviations for "extension". More than one telephone number is fine; each telephone number should be put on a separate line and written in order of the most appropriate number for the person to the least. Example: phone: +81-20-1233-4676 phone: +81-20-1233-4677 ext 4711 FAX-NO: Please complete with the facsimile number of the person as it would be dialed internationally (WITHOUT the prefix necessary to reach an international line) in your country. Please do not include the leading zero when specifying their area/city code unless it is required to correctly dial the number internationally. The format for the facsimile number is: +--- More than one facsimile number is fine. Each facsimile number should be put on a separate line and written in order of the most appropriate to the least. If the person does not have a facsimile number, please leave blank. Example: fax-no: +81-20-1233-4678 E-MAIL: Please supply the electronic mail address for the person. The electronic mail address MUST be an Internet reachable valid RFC-822 address with a fully qualified domain name. If you do not have Internet reachable e-mail connectivity, please leave this field blank. Multiple e-mail addresses may be specified, with each on a separate line and written in order of the most appropriate to the least. Example: e-mail: johndoe@terabit.na NIC-HDL: A NIC Handle is a unique identifer used within the Internet registry database to differentiate between people with the same names. NIC handles are assigned by registries -- if you do not have one, please do not make one up. APNIC will provide you with one or you can reserve one for yourself using the procedures described in APNIC-044 (see ftp://ftp.apnic.net/docs/apnic-044.txt for more details). If you have an APNIC NIC handle, but do not remember it, please make a note of this in the ADDITIONAL COMMENTS section of the application form. If you have a NIC handle assigned by another registry, e.g., InterNIC, please provide a full person template anyway and leave the NIC-HDL field blank -- the regional registries are currently investigating ways in which information such as this can be shared, but no solution has yet been implemented. If you do not have a NIC handle, please leave the field blank -- do NOT put 'Please Assign' or similar for this field. Example: nic-hdl: JD401-AP CHANGED: Please indicate the e-mail address of the person who is completing the template followed by the current date in the format of YYMMDD (YY is the current year, MM is the month and DD is the day, all values 0 filled). If you do not have e-mail connectivity please leave blank and it will be filled in for you. Do not put "Please Assign" or similar for this field. If you have an e-mail address, you should supply exactly one CHANGED tag per PERSON template if this is a new person object. Example: changed: johndoe@terabit.na 960501 MNT-BY: Please provide the APNIC allocated maintainer ID. The maintainer ID provides some level of authorization control over who can update an object protected by a MNT-BY field. If you do not have a maintainer ID, you may either leave this field blank and a default maintainer ID will be created for you (one without any authentication protection) or you may apply for one using the APNIC Maintainer Object Request form found at: ftp://ftp.apnic.net/apnic/docs/apnic-045.txt There can be zero or more MNT-BY tags per NETWORK template, however each maintainer object specified must already exist in the APNIC Registration database. Example: mnt-by: MAINT-FOO-AP SOURCE: Source of the information. For the purposes of APNIC forms, it will always be APNIC. This is information which is always required in the database, so it has been added to the forms already. Example: source: APNIC 4.0 Enterprise IP Address Request Technical Details --------------------------------------------------- ACCT-NAME: Please provide your APNIC account name if you have one. If you do not have an APNIC account name, please see APNIC-046 available from: ftp://ftp.apnic.net/apnic/docs/apnic-046.txt Note that applications without account name will NOT be processed. Example: acct-name: APNIC-AP HOST-BITS: Please indicate the amount of address space you will require AFTER TWO YEARS in terms of BITS of host address space, *NOT* hosts, host addresses, networks, "Class Cs" or "blocks". This format reflects the classless network architecture the Internet has evolved to. 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 3 host addresses -> 2 host address bits (a /30) 7 host addresses -> 3 host address bits (a /29) 15 host addressse -> 4 host address bits (a /28) 31 host addresses -> 5 host address bits (a /27) 63 host addresses -> 6 host address bits (a /26) 127 host addresses -> 7 host address bits (a /25) 255 host addresses -> 8 host address bits (a /24 or 1 class C network) 511 host addresses -> 9 host address bits (a /23 or 2 class C networks) 1023 host addresses -> 10 host address bits (a /22 or 4 class C networks) 2047 host addresses -> 11 host address bits (a /21 or 8 class C networks) 4095 host addresses -> 12 host address bits (a /20 or 16 class C networks) 8191 host addresses -> 13 host address bits (a /19 or 32 class C networks) 16383 host addresses -> 14 host address bits (a /18 or 64 class C networks) 32767 host addresses -> 15 host address bits (a /17 or 128 class C networks) 65535 host addresses -> 16 host address bits (a /16 or 1 class B network) Note that large request will require significant additional documentation and small requests will be referred to their service provider for address space. Example: host-bits: 9 CONNECTIVITY: Please indicate how your network will be connecting to the Internet. Acceptible values for this field are PEERING-POINT, SERVICE-PROVIDER, OTHER, or NONE. 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. Examples of PEERING-POINT interconnects are MAE-West in the US, HKIX in Hong Kong, etc. The choice of SERVICE-PROVIDER indicates the use of an organization which provides Internet connectivity services. The use of OTHER implies neither a peering point nor 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 ADDITIONAL COMMENTS section. If you specify NONE, you indicate you will not be connecting to the global Internet. In such a case, please provide details in the ADDITIONAL COMMENTS section explaining the necessity of using limited global addresses for your private network and why you cannot make use of the private addresses specified in RFC 1918. If you will be connecting via more than one connectivity method, please list all connectivity methods, one per line. Example: connectivity: PEERING-POINT CONN-PROVIDER: Please provide the name of the organization providing your network with connectivity to the Internet. 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 connectivity denoted by SERVICE-PROVIDER, 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. If you have indicated NONE, you may leave this field blank. Example: conn-provider: MAE-West ALL-0S-SUBNETS: Please put YES if you can support all zeros subnets, NO if you cannot. If you indicate NO, please provide an explanation in the "Additional Comments" section at the end of your application. Note that all major router vendors can support all zeros subnets although it may be necessary to alter the default configuration to do so. Example: all-0s-subnets: YES ALL-1S-SUBNETS: Please put YES if you can support all ones subnets, NO if you cannot. If you indicate NO, please provide an explanation in the "Additional Comments" section at the end of your application. Note that all major router vendors can support all ones subnets although it may be necessary to alter the default configuration to do so. Example: all-1s-subnets: YES SUPERNETS: Please put YES if you can support supernetting, that is you can aggregate multiple contiguous networks into a single routing announcement, NO if you cannot. If you indicate NO, please provide an explanation in the "Additional Comments" section at the end of your application. Example: supernets: YES SUBNETS: Please put YES if you can support subnetting, that is you can separately route parts of a single routing prefix, NO if you cannot. If you indicate NO, please provide an explanation in the "Additional Comments" section at the end of your application. Note: APNIC assumes you will use subnets. Failure to do so will require justification when applying for additional address space. Example: subnets: YES HOSTS-NOW: Please provide an accurate accounting of the number of HOST addresses (NOT networks, "class Cs", "blocks", etc.) you will need immediately (i.e., within one month). You will need to document the usage of these addresses in the network-plan field described below, so please insure that the total of all hosts in the network-plan field corresponds to the number of addresses listed here. 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 IMMEDIATELY upon commencment of use of the block allocated. Example: hosts-now: 10 HOSTS-6MO: Please provide an accurate estimate of the number of HOST addresses (NOT networks, "class Cs", "blocks", etc.) you will need in the upcoming 6 months. You will need to document the usage of these addresses in the network-plan field described below, so please insure that the total of all hosts in the network-plan field corresponds to the number of addresses listed here. 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 at the end of the next six months. Example: hosts-6mo: 100 HOSTS-1YR: Please provide an accurate estimate of the number of HOST addresses (NOT networks, "class Cs", "blocks", etc.) you will need in the upcoming year. You will need to document the usage of these addresses in the network-plan field described below, so please insure that the total of all hosts in the network-plan field corresponds to the number of addresses listed here. 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 at the end of the year. Example: hosts-1yr: 306 NETWORK-PLAN: Please provide a summary of your network plans for the next year. This field provides information to APNIC on how you are using address space assigned to you for your internal infrastructure and should correspond to your network as it is or will be deployed within the next year. The format of this field is: network-plan: address mask connect max n0/n1/n2 remark where: address - the dotted decimal network number using network 10.0.0.0 as the prefix, e.g., 10.0.1.2 mask - the netmask for the network in dotted decimal form, e.g. 255.255.255.240 connect - 'NO' if the network is NOT connected to the Internet or 'YES' otherwise (e.g., it can be "pinged") max - the maximum number of host addresses possible on the network. Be sure to subtract two addresses for the 0's host part and the broadcast address. n0 - the number of devices initially planned or currently installed. n1 - the number of devices planned after 6 months n2 - the number of devices planned after 1 year remark - a descriptive remark about the network. 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 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: 10.0.0.0 255.255.255.240 YES 14 1/5/11 support group network-plan: 10.0.0.16 255.255.255.240 YES 14 4/8/8 customer svc network-plan: 10.0.0.32 255.255.255.240 YES 14 10/10/10 int. dial up network-plan: 10.0.0.48 255.255.255.240 NO 14 2/10/12 sales network-plan: 10.0.0.64 255.255.255.192 NO 62 0/0/0 future use network-plan: 10.0.0.128 255.255.255.128 YES 126 1/64/126 customer lines network-plan: 10.0.1.0 255.255.255.0 YES 254 0/128/254 customer lines old-network: In order to increase the utilization of already allocated address space, APNIC must determine the usage of addresses already allocated to your organization. For the purposes of address allocation, "organization" means all parts of your company (including your parent company, subsidiaries, branch offices, etc. regardless of where those networks reside geographically or the name of the company) which connected internally (including out-sourced private networks, e.g., "intranets"). If your organization 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: old-network: address mask connect devices remark where: address - the dotted decimal network number using network 10.0.0.0 as the prefix, e.g., 10.0.1.2 mask - the netmask for the network in dotted decimal form, e.g. 255.255.255.240 connect - 'NO' if the network is NOT connected to the Internet or 'YES' otherwise (e.g., it can be "pinged") devices - the number of devices attached to the network remark - a descriptive remark about the network. If your organizations has not had networks allocated to you in the past, please leave this field blank. Example: old-network: 202.5.10.0 255.255.255.0 YES 220 R&D Division old-network: 202.5.11.0 255.255.255.128 YES 104 Marketting old-network: 202.5.11.128 255.255.255.128 YES 112 Sales EXPLANTION WHY YOU CANNOT OBTAIN ADDRESSES FROM YOUR SERVICE PROVIDER: Please provide a detailed explanation why you cannot obtain addresses from your service provider. Failure to provide an explanation will result in your application being returned unprocessed. All organizations requesting address space are *strongly* encouraged to obtain their address space from their Internet service provider. See the supporting notes for more details. ADDITIONAL COMMENTS: This section is for you to provide whatever other details you feel may help justify your request. In particular, documenting your network topology via diagrams or providing detailed explanations why your address space usage and subnetting plans are the way they are can help APNIC understand your network requirements and will lead to faster processing of your request should there be any questions. If you have specified "NONE" for the connectivity field mentioned above, please provide details explaining why you cannot use RFC-1918 private networks. 5.0 Supporting Notes -------------------- 5.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 35,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 35,000 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 1918 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 1918 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 1918 private networks is somewhat controversial. 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. 6.0 Application Example ----------------------- #[NETWORK TEMPLATE V:4.0]# netname: EXAMPLE-AP descr: An example of a completed enterprise application form descr: Please don't send this verbatim to APNIC country: JP admin-c: DC1-AP tech-c: YF1-AP rev-srv: ns.apnic.net rev-srv: jatz.aarnet.edu.au changed: davidc@apnic.net 960501 mnt-by: MAINT-APNIC-AP source: APNIC #[PERSON TEMPLATE V:4.0]# person: David R Conrad address: Asia Pacific Network Information Center address: c/o The United Nations University address: 53-70 Jingumae 5-Chome, Shibuya-ku Tokyo 150 country: JP phone: +81-3-5467-7014 fax-no: +81-3-5467-7015 e-mail: davidc@apnic.net nic-hdl: DC1-AP changed: davidc@apnic.net 960401 mnt-by: MAINT-APNIC-AP source: APNIC #[PERSON TEMPLATE V:4.0]# person: Yoshiko O Chong Fong address: Asia Pacific Network Information Center address: c/o The United Nations University address: 53-70 Jingumae 5-Chome, Shibuya-ku Tokyo 150 country: JP phone: +81-3-5467-7014 fax-no: +81-3-5467-7015 e-mail: yoshiko@apnic.net nic-hdl: YF1-AP changed: davidc@apnic.net 960401 mnt-by: MAINT-APNIC-AP source: APNIC #[ENTERPRISE TECHNICAL TEMPLATE V:3.0]# acct-name: ACCT-APNIC-AP host-bits: 8 connectivity: SERVICE-PROVIDR conn-provider: SuperNetworks, Inc. all-0s-subnets: YES all-1s-subnets: YES supernets: YES subnets: YES addr-now: 4 addr-3mo: 84 addr-6mo: 233 network-plan: 10.0.0.0 255.255.255.0 YES 4/84/107 1/1/1 hardware lab network-plan: 10.0.0.0 255.255.255.128 YES 0/0/126 0/0/1 R&D net old-network: 202.12.28.0 255.255.255.252 YES 2 point-to-point link old-network: 202.12.28.4 255.255.255.252 NO 0 unused old-network: 202.12.28.8 255.255.255.248 YES 6 marketing dept. old-network: 202.12.28.16 255.255.255.240 YES 14 sales dept. old-network: 202.12.28.32 255.255.255.224 YES 27 allocation dept. old-network: 202.12.28.64 255.255.255.192 YES 55 recovery dept. old-network: 202.12.28.128 255.255.255.192 YES 47 service segment old-network: 202.12.28.224 255.255.255.192 NO 38 accounting dept. #[TEMPLATES END]# Explantion why you cannot obtain addresses from your service provider: We run a root domain server, thus we must have addresses that do not need to be renumbered in the event of a change of Internet service providers. We have obtained agreements from all major transit providers (available on request) to propagate our long prefix network. Additional Comments: We will be using BFR routers running BGP-4 to peer with our service provider. We will also be using OSPF to manage our internal infrastructure. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 7.0 Recommended Reading ----------------------- RFC 1466 E. Gerich, "Guidelines for Management of IP Address Space", 5/26/93, URL: ftp://ftp.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://ftp.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://ftp.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://ftp.apnic.net/ietf/rfc/rfc1519.txt RFC 1744 G. Huston, "Observations on the Management of the Internet Address Space", 12/23/94, URL: ftp://ftp.apnic.net/ietf/rfc/rfc1744.txt RFC 1814 E. Gerich, "Unique Addresses are Good", 6/22/95, URL: ftp://ftp.apnic.net/ietf/rfc/rfc1814.txt RFC 1817 Y. Rekhter, "CIDR and Classful Routing", 8/4/95, URL: ftp://ftp.apnic.net/ietf/rfc/rfc1817.txt RFC 1879 B. Manning, "Class A Subnet Experiment Results and Recommendations", 1/15/96, URL: ftp://ftp.apnic.net/ietf/rfc/rfc1879.txt RFC 1878 T. Pummill, B. Manning, "Variable Length Subnet Table For IPv4", 12/26/95, URL: ftp://ftp.apnic.net/ietf/rfc/rfc1878.txt RFC 1900 B. Carpenter, Y. Rekhter, "Renumbering Needs Work", 2/28/96, URL: ftp://ftp.apnic.net/ietf/rfc/rfc1900.txt RFC 1916 H. Berkowitz, P. Ferguson, W. Leland, P. Nesser, "Enterprise Renumbering: Experience and Information Solicitation", 2/28/96, URL: ftp://ftp.apnic.net/ietf/rfc/rfc1916.txt RFC 1917 P. Nesser, "An Appeal to the Internet Community to Return Unused IP Networks (Prefixes) to the IANA", 2/29/96, URL: ftp://ftp.apnic.net/ietf/rfc/rfc1917.txt RFC 1918 Y. Rekhter, R. Moskowitz, D. Karrenberg, G. de Groot, E. Lear, "Address Allocation for Private Internets", 2/29/96, URL: ftp://ftp.apnic.net/ietf/rfc/rfc1918.txt RFC 2008 Y. Rekhter, T. Li, "Implications of Various Address Allocation Policies for Internet Routing", 10/14/96, URL: ftp://ftp.apnic.net/ietf/rfc/rfc2008.txt RFC 2036 G. Huston, "Observations on the use of Components of the Class A Address Space within the Internet, 10/30/96, URL: ftp://ftp.apnic.net/ietf/rfc/rfc2036.txt RFC 2050 K. Hubbard, M. Kosters, D. Conrad, D. Karrenberg, J. Postel, "Internet Registry IP Allocation Guidelines", 11/6/96, URL: ftp://ftp.apnic.net/ietf/rfc/rfc2050.txt APNIC-041 APNIC Staff, "Internet Service Provider IP Address Request Form", 11/6/96 URL: ftp://ftp.apnic.net/apnic/docs/apnic-041.txt APNIC-043 APNIC Staff, "Confederation IP Address Request Form", 11/6/96 URL: ftp://ftp.apnic.net/apnic/docs/apnic-043.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 ftp.apnic.net Using your ftp application (usally called simply 'ftp'), connect to host ftp.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" documents 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. 8.0 Acknowledgements -------------------- This document in derived in large part from documents written by the staff of the European Registry, RIPE-NCC .