------------------------------------------------------------------- APNIC Document identity Title: APNIC Internet Service Provider Internet Address Request Form Short title: doc-review-policy Document ref: APNIC-061 Version: 001 Date of original publication: 20 July 1997 Date of this version: 20 July 1997 Review scheduled: n/a Obsoletes: APNIC-041 Status: Obsolete Comments: Obsoleted by APNIC-065 -------------------------------------------------------------------- APNIC Internet Service Provider Internet Address Request Form Issued: July 20, 1997 Expires: December 31, 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 to be used by organizations requesting address space that will be sub-delegated to unrelated external organizations in conjunction with the provision of Internet connectivity services. If you will be sub-delegating to internal organizations (subsidiaries, branch offices, etc), you should use the "End User Internet Address Request form (ftp://ftp.apnic.net/apnic/docs/end-user-address-request). If you are an APNIC recognized confederation of service providers, that is a group of unrelated Internet service providers which have agreed on a single entity which will interact with APNIC, you should use the "Confederation Internet Address Request form available at ftp://ftp.apnic.net/apnic/docs/confed-address-request. 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-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:5.0]# netname: descr: descr: country: admin-c: tech-c: remarks: changed: mnt-by: source: APNIC #[PERSON TEMPLATE V:4.0]# person: address: address: country: phone: fax-no: e-mail: nic-hdl: remarks: changed: mnt-by: source: APNIC #[PERSON TEMPLATE V:4.0]# person: address: address: country: phone: fax-no: e-mail: nic-hdl: remarks: changed: mnt-by: source: APNIC #[ISP TECHNICAL TEMPLATE V:4.0]# acct-name: connectivity: conn-provider: all-0s-subnets: all-1s-subnets: supernets: subnets: portable: cust-network: cust-network: infrastructure: infrastructure: network-plan: network-plan: #[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 Internet Service Provider 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 ISP 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 and WAIS to wais.apnic.net (database APNIC). 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 Internet Service Provider IP Address Request Network Template Details ------------------------------------------------------------------------- NETNAME: Please complete with an appropriate name which is short and meaningful for your network. 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 of 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). It is recommended you use a network name that relates to the organization the network is being assigned to. 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 internet provider 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/docs/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: Jon Q 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 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 a new provider block. Example: changed: johndoe@terabit.na 950225 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/maintainer-request 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 Internet Service Provider 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/docs/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 the "APNIC Registry Database Record Addition, Modification, and Deletion Instructions" document found at ftp://ftp.apnic.net/apnic/docs/database-update-info . 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 REMARKS: The remarks attribute contains any remarks about this person 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: pager can be accessed by -pager 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 950225 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/maintainer-request There can be zero or more MNT-BY tags per request 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 Internet Service Provider Internet Address Request Technical Details ------------------------------------------------------------------------ ACCT-NAME: Please provide your APNIC account name. If you do not have an account name but wish to become an APNIC member, please see the "APNIC Membership Application" form available at ftp://ftp.apnic.net/apnic/docs/membership-application If you do not wish to become a member, please leave this field blank and a non-member account will be assigned to you and returned along with an invoice and payment instructions. For more details on non-member applications, see: ftp://ftp.apnic.net/apnic/docs/non-member-fees Note that applications will not be processed until APNIC has received payment in either the member or non-member cases. Example: acct-name: APNIC-AP 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. 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 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. 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 ISPs will use subnets of prefixes allocated to them for assignments to customers. Failure to do so will require justification when applying for additional address space. Example: subnets: YES PORTABLE: If you will allow customers to keep addresses assigned to them from when they move to another provider, i.e. the addresses you assign are portable between providers, indicate YES for this attribute. If not, indicate NO. It should be stressed that due to limitations currently being experienced in the Internet routing system, the use of portable address space is *STRONGLY* discouraged however it is assumed that organizations which do not explicitly state to customers that address space must be returned at the end of the connectivity contract have assigned address space portably. See the supporting notes for more details. Example: portable: NO CUST-NETWORK: The CUST-NETWORK field provides a summary of the assignment information you have made to customers in the past. If you have not been allocated networks in the past, please leave this field blank. If networks have been assigned by you to customers, you MUST provide the re-assignment information for those networks in the following format: cust-network: netname address mask hinit/h6mo/h1yr sinit/s6mo/s1yr date where: netname - the name you assigned as found in the APNIC database (note: this name is of your choosing, but should relate to the organization the network is assigned to) address - the starting address of the assigned network mask - the subnet mask of assigned network in dotted decimal format, e.g. 255.255.248.0 hinit - the estimated number of devices initially h6mo - the estimated number of devices after six months h1yr - the estimated number of devices after one year sinit - the estimated number of subnets initially s6mo - the estimated number of subnets after six months s1yr - the estimated number of subnets after one year date - the date the assignment occurred in YYMMDD format It is VERY important that this field be specified correctly as APNIC bases future allocations on past assignment history. The information conveyed in the CUST-NETWORK fields allow APNIC to establish your address assignment patterns. Please make ABSOLUTELY SURE the netname portion of the CUST-NETWORK field corresponds *EXACLY* with the NETNAME field of the reassignment in the APNIC database. Failure to do so will result in APNIC assuming the network indicated has NOT been reassigned. Please use as many CUST-NETWORK fields as necessary to describe ALL customer networks which you have assigned using APNIC allocated addresses. If you have assigned a network in a non-CIDR fashion (e.g., there is no single subnet mask which can describe the subnet), please submit multiple CUST-NETWORK fields which describe the assignment in CIDR fashion, repeating the network name as necessary. *NOTE* The sum of the CUST-NETWORK described addresses and the INFRASTRUCTURE (see below) described addresses will be assumed to be the total amount of address space your network has utilized. Example: cust-network: FOO-AP 202.12.28.0 255.255.255.128 10/15/80 1/1/2 960501 cust-network: BAR-AP 202.12.28.128 255.255.255.128 60/70/100 2/3/4 960515 INFRASTRUCTURE: The INFRASTRUCTURE field provides a summary of the addresses you are currently using for your network infrastructure, that is, the addresses that you did not assign to customers and which do not appear in the APNIC database and the CUST-NETWORK fields described above. The INFRASTRUCTURE field has the following format: infrastructure: address mask connect max hinit/h6mo/h1yr remark where: address - the dotted decimal form of the start of the network as assigned in your network, e.g., 202.12.28.192 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, 'PART' if the network is connected part-time (e.g., a dialup connected network), or 'YES' otherwise (e.g., it can be "pinged" at any time) max - the maximum number of usable host addresses possible on the network. Be sure to subtract two addresses for the all 0's host part and the all 1's broadcast address. hinit - the number of devices initially planned or currently installed. h6mo - the number of devices planned after 6 months. h1yr - the number of devices planned after 1 year. remark - is a descriptive remark about the network. You may use as many INFRASTRUCTURE fields as necessary to accurately describe your internal infrastructure. Do NOT use INFRASTRUCTURE fields to describe networks which you are not yet using. If your infrastructure has been deployed on non-CIDR boundaries (e.g., there is no single subnet mask which can describe the subnet), please use multiple INFRASTRUCTURE fields to describe your infrastructure in CIDR fashion (including the use of 255.255.255.255 masks to define single hosts). In your device estimates, be sure to include all devices which 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. *NOTE* The sum of the CUST-NETWORK (see above) described addresses and the INFRASTRUCTURE described addresses will be assumed to be the total amount of address space your network has utilized. Example: infrastructure: 202.12.28.0 255.255.255.192 YES 62 12/24/48 servers infrastructure: 202.12.28.64 255.255.255.192 PART 62 30/40/50 dialup ports infrastructure: 202.12.28.128 255.255.255.128 NO 126 60/100/110 admin NETWORK-PLAN: This field provides information to APNIC on how you will use the address space allocated to you within the next 12 months. The format of the NETWORK-PLAN field is: network-plan: address mask connect max hinit/h6mo/h1yr remark where: address - the dotted decimal form of the start of the network using as offset, e.g., 0.0.1.0 with a mask of 255.255.255.0 would describe the second /24 (the first /24 being 0.0.0.0 with a mask of 255.255.255.0) mask - the netmask for the network in dotted decimal form, e.g. 255.255.255.240 connect - 'NO' if the network will NOT be connected to the Internet, 'PART' if it will be connected part-time (e.g., a dialup connection), or 'YES' otherwise (e.g., it can be "pinged") max - the maximum number of usable host addresses possible on the network. Be sure to subtract two addresses for the all 0's host part and the all 1's broadcast address. hinit - the number of devices initially planned or currently installed. h6mo - the number of devices planned after 6 months. h1yr - the number of devices planned after 1 year. remark - is a descriptive remark about the network. You may use as many NETWORK-PLAN fields as necessary to accurately describe your future network plans. The NETWORK-PLAN field is intended to be used to document your requirements for additional address space for internal infrastructure (over that which is documented in the INFRASTRUCTURE fields mentioned above) and customer networks. In your device estimates for your internal infrastructure, 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. With respect to customer networks, it is expected that some portion (perhaps even all) of the address space allocated to you will be placed in a pool for assignment to your customers. Please specify this by using an appropriately sized CIDR block designated "customer block" or similar with reasonable growth estimates. Note that you should partition this block as appropriate to reflect deployment of "Points of Presence" (POPs), e.g., if you have 2 POPs with half of your customers at each POP and are requesting a /23, a NETWORK-PLAN field as below would be recommended: network-plan: 0.0.0.0 255.255.255.0 YES 254 0/126/254 POP1 network-plan: 0.0.1.0 255.255.255.0 YES 254 0/126/254 POP2 This implies all 254 addresses will be assigned to customers and that the necessary infrastructure to do so (i.e., point-to-point links, null interfaces, terminal servers, service machines, etc.) will be described elsewhere in NETWORK-PLAN fields. *NOTE* The NETWORK-PLAN field is used to help determine how much address space should be allocated for this request. Accurate descriptions of how the address space will be used will likely be helpful to avoid misunderstandings. Example: network-plan: 0.0.0.0 255.255.255.240 YES 14 1/5/11 support group network-plan: 0.0.0.16 255.255.255.240 YES 14 4/8/8 customer svc network-plan: 0.0.0.32 255.255.255.240 YES 14 10/10/10 int. dial up network-plan: 0.0.0.48 255.255.255.240 NO 14 2/10/12 admin network-plan: 0.0.0.64 255.255.255.224 YES 30 10/20/30 servers network-plan: 0.0.0.96 255.255.255.224 YES 30 8/16/28 point-to-point network-plan: 0.0.0.128 255.255.255.128 YES 126 1/64/126 POP1 network-plan: 0.0.1.0 255.255.255.0 YES 254 0/128/254 POP2 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. 5.0 Internet Service Provider IP Address Request Form Supporting Notes --------------------------------------------------------------------- This form is intended to provide information necessary for APNIC to evaluate your request. In particular, the ISP TECHNICAL TEMPLATE provides specific information that is used as a basis for APNIC to understand how you have utilized and plan to utilize your address space. The ISP TECHNICAL TEMPLATE requests the following information: - how you are connected to the Internet (CONNNECTIVITY and CONN-PROVIDER) - the routing characteristics of your network (ALL-0S-SUBNETS, ALL-1S-SUBNETS, SUPERNETS, SUBNETS, PORTABLE) - how you have utilized previously assigned address space (CUST-NETWORK, INFRASTRUCTURE) - how you will utilize newly allocated address space (NETWORK-PLAN) however, it must be noted that the information provided is just the start of the evaluation process. APNIC will likely need to request additional information on how your network has been or will be deployed. Providing additional information in the "ADDITIONAL COMMENTS" field will likely help APNIC understand your requirements, thereby speeding up the allocation process. 5.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 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 30000 sites (every time a network comes up or goes down, how to get to the all the sites on the network must be recomputed. 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 in virtual private networks, 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 the routing system overflow problem, registries strongly recommend to sites requesting address space they obtain the address space from their service provider. Service provider blocks are generally large enough such that they won't be ignored by other providers. 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 tables. While it is acknowledged that renumbering may not be 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. The archives of the PIER (Procedures for Internet/Enterprise Renumbering) Working Group of the IETF may be consulted for more information on renumbering and renumbering technologies. See the following URL: ftp://ftp.apnic.net/ietf/wg/pier/pier-charter.txt 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, both ISPs and non-ISPs, to obtain addresses from their service providers and to return those addresses when they change service providers. It must be stressed in the strongest possible terms that allocation of address space by the registries, regardless of the prefix size allocated, in absolutely NO way ensures that address space will be routed on the Internet. Further, for ISPs, APNIC strongly recommends wording be included in the ISP's standard connectivity contract which will contractually obligate the service subscriber to return addresses to the service provider when the connectivity contract terminates. If this wording is not present, APNIC assumes assignments made to customers are at the customer's discretion, e.g., the customer may take the address space with them when they change providers. As such actions impact global routing tables, they should be avoided. 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. 5.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. APNIC reserves additional space behind the initial allocation to insure that as few routing prefixes are injected into the global routing system as possible. NO guarantees are made of the size of the block reserved, although APNIC does its best to insure the block is of sufficient size to allow ISPs to grow, yet at the same time does not result in unsupportable wastage of address space. When the ISP consumes the initial allocation, additional space will be made available as necessary, but that space may not be in the same contiguous block. 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 *MUST* update the APNIC database using the procedures defined in: ftp://ftp.apnic.net/apnic/docs/database-update-info as soon as feasible after assigning the address(es) to the customer. 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. If the ISP does not update the database as assignments are made, APNIC has no information by which to gauge the ISPs growth rate. This may result in APNIC reducing the amount of reserved space to a point where a new block must be started and a new routing prefix be injected into the routing system. As long and new prefixes tend to be more likely to be filtered than short and old prefixes, it is in the best interest of the ISP to update the APNIC database promptly. When an ISP consumes at least 75% of the space initially allocated to it by APNIC, it should submit another Internet Service Provider IP address request form (this 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 must NOT refer the customer to APNIC as APNIC will simply refer the customer back to the ISP). 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, e.g., the ISP will approach APNIC quite often initially, 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. 6.0 Application Example ----------------------- #[NETWORK TEMPLATE V:4.0]# netname: EXAMPLE-AP descr: An example of a completed ISP application form descr: Please don't send this verbatim to APNIC country: JP admin-c: DC1-AP tech-c: YF1-AP 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: Tokyo Central Post Office Box 351 address: Tokyo 100-91 country: JP phone: +81-3-5500-0480 fax-no: +81-3-5500-0481 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: Tokyo Central Post Office Box 351 address: Tokyo 100-91 country: JP phone: +81-3-5500-0480 fax-no: +81-3-5500-0481 e-mail: yoshiko@apnic.net nic-hdl: YF1-AP changed: davidc@apnic.net 960401 mnt-by: MAINT-APNIC-AP source: APNIC #[ISP TECHNICAL TEMPLATE V:3.0]# acct-name: APNIC-AP connectivity: PEERING-POINT conn-provider: MAE-West all-0s-subnets: YES all-1s-subnets: YES supernets: YES subnets: YES portable: NO cust-network: FOO-AP 202.12.28.0 255.255.255.128 10/15/80 1/1/2 960301 cust-network: BAR-AP 202.12.28.128 255.255.255.128 60/70/100 2/3/4 960315 infrastructure: 202.12.29.0 255.255.255.192 YES 62 12/24/48 servers infrastructure: 202.12.29.64 255.255.255.192 PART 62 30/40/50 dialup ports infrastructure: 202.12.29.128 255.255.255.128 NO 126 60/100/110 admin network-plan: 0.0.0.0 255.255.255.240 YES 14 1/5/11 support group network-plan: 0.0.0.16 255.255.255.240 YES 14 4/8/8 customer svc network-plan: 0.0.0.32 255.255.255.240 YES 14 10/10/10 int. dial up network-plan: 0.0.0.48 255.255.255.240 NO 14 2/10/12 admin network-plan: 0.0.0.64 255.255.255.224 YES 30 10/20/30 servers network-plan: 0.0.0.96 255.255.255.224 YES 30 8/16/28 point-to-point network-plan: 0.0.0.128 255.255.255.128 YES 126 1/64/126 POP1 network-plan: 0.0.1.0 255.255.255.0 YES 254 0/128/254 POP2 #[TEMPLATES END]# Explantion why you cannot obtain addresses from your service provider: We will be multi-homed as we are connecting to a connection point, peering with a variety of service providers and defaulting to none. Additional Comments: The following is the EXAMPLE network topology. --- +-----+ +----------+ / \ | DNS |--------+-------| Router 1 |-----+ F |---> Terminal Server +-----+ | +----------+ | D | | | | D |---> Router +----------+ | | | I | | 10 port | | V | |---> Router | Internal |---+ (ISDN Backup) | D | | Terminal | | | M |---> Router | Server | | +----------+ | Z | +----------+ |-------| Router 2 |-----+ | | +----------+ \ / +------+ | | --- | FS 1 |-------+ | +------+ | V +------+ | (OC48 to connection point) | FS 2 |-------+ +------+ | | +---------+--------+--------+ | | | | +------+ +------+ +------+ +------+ | WS 1 | | WS 2 | | WS 3 | | WS 4 | +------+ +------+ +------+ +------+ We will be using BFR routers running BGP-4 to peer with service providers at the MAE-West connection point. We will also be using OSPF to manage our internal infrastructure and static routing to our customers where possible. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 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-062 APNIC Staff, "End User Internet Address Request Form", 7/20/97 URL: ftp://ftp.apnic.net/apnic/docs/end-user-address-request APNIC-063 APNIC Staff, "Confederation Internet Address Request Form", 7/20/97 URL: ftp://ftp.apnic.net/apnic/docs/confed-address-request These documents are all available from the APNIC document store in the directories mentioned in the URLs. The APNIC document store can be accessed: 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 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 or Internet Service Provider 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 .