------------------------------------------------------------------- APNIC Document identity Title: APNIC Second Opinion Request Form Short title: second-opinion-request Document ref: APNIC-073 Version: 002 Date of original publication: August 1998 Date of this version: 11 February 2002 Review scheduled: n/a Obsoletes: APNIC-060 Status: Obsolete Comments: Obsoleted by APNIC-097 -------------------------------------------------------------------- APNIC Second Opinion Request Form This form is intended for use by service providers who wish to assign address space to customers beyond their assignment window. APNIC uses an "assignment window" mechanism to insure organizations assigning address space understand the requirements and responsibilities associated with this activity. The assignment window initially starts at 0, indicating the service provider must request a second opinion for all assignments made. As the provider gains experience with address assignments and APNIC gains a better understanding of the service provider's address assignment patterns, APNIC opens the window to allow the provider to assign more and more address space autonomously. This form allows the provider to submit the necessary information to APNIC to enable it to provide our opinion as to the appropriate amount of address space for the 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: hostmaster@apnic.net or in type written English via fax (discouraged) to: 7-3858-3199 or in type written English via postal mail (as a last resort) to: Asia Pacific Network Information Center Level 1, 33 Park Road P. O. Box 2131 Milton, QLD 4064 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 7-3858-3100 between 9:00 AM to 5:00 PM Australian Eastern Standard Time. 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 - - - - - - - - - - - - - - - #[SECOND OPINION TEMPLATE V:1.0]# acct-name: netname: descr: descr: country: host-bits: all-0s-subnets: all-1s-subnets: supernets: subnets: network-plan: network-plan: old-network: old-network: #[TEMPLATES END]# Additional Comments: - - - - - - - - - - - - - - CUT HERE - - - - - - - - - - - - - - - - - 1.0 Instructions For Completing This Form ----------------------------------------- Below are the instructions for filling in an APNIC Second Opinion 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 authorization to sub-delegate address space to your customers. Information provided in the SECOND OPINION 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. 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 Second Opinion Template 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 see the "APNIC Non-Member Resource Request Application" form available at: ftp://ftp.apnic.net/apnic/docs/non-member-application In no case will an address request form be accepted without a completed account field. 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 NETNAME: Please provide a short but meaningfully descriptive name that you intend to use for this network when you update the APNIC database. The NETNAME is used mainly for administrative purposes such as consistency checking of the Internet Registry and should be written as a SINGLE word of less than 25 capital alphanumeric characters ONLY. It is requested 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 SECOND OPINION template. Example: netname: TBIT DESCR: Please complete with a short description of the organization, including the location providing sufficient detail as to describe the organization uniquely, i.e., "descr: Computer Center" is not sufficient. Do NOT put advertising information such as 'The best maker of bars in Foo' in the description and please limit the number of DESCR lines to 5. This tag is required for all SECOND OPINION templates. Example: descr: Terabit Labs Inc. descr: Network Bugs Feeding Facility descr: Northtown COUNTRY: Please give the two letter ISO 3166 country code appropriate for the organization requesting address space. Do NOT provide the country name or the three letter ISO 3166 country code. If you do not know the appropriate ISO 3166 code for your country, please see the table of ISO 3166 codes maintained on APNIC at ftp://ftp.apnic.net/apnic/docs/iso-3166.txt 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 SECOND OPINION templates, with only one COUNTRY tag permitted. Example: country: JP HOST-BITS: Please indicate the amount of address space you believe would be appropriate after one year for this customer in terms of BITS of host address space, *NOT* hosts, host addresses, networks, "Class Cs" or "blocks". For example, a request with HOST-BITS: 7 would indicate 2**7 (128) possible host addresses (however, please remember the all 0's and all 1's host addresses are typically unusable for end host assignments, thus the maximum number of hosts 7 bits would allow would be 126). Please use the following guidelines to determine how many host-bits would be appropriate: Requires 1 host address -> 1 host address bit (a /32) 2 host addresses -> 2 host address bits (a /30) 3-6 host addresses -> 3 host address bits (a /29) 7-14 host addresses -> 4 host address bits (a /28) 15-30 host addresses -> 5 host address bits (a /27) 31-62 host addresses -> 6 host address bits (a /26) 63-126 host addresses -> 7 host address bits (a /25) 127-254 host addresses -> 8 host address bits (a /24) 255-510 host addresses -> 9 host address bits (a /23) 511-1022 host addresses -> 10 host address bits (a /22) 1023-2046 host addresses -> 11 host address bits (a /21) 2047-4094 host addresses -> 12 host address bits (a /20) 4095-8190 host addresses -> 13 host address bits (a /19) 8191-16382 host addresses -> 14 host address bits (a /18) 16383-32766 host addresses -> 15 host address bits (a /17) 32767-65534 host addresses -> 16 host address bits (a /16) Note that larger requests will require significant additional documentation. Example: host-bits: 9 ALL-0S-SUBNETS: Please put YES if the network can support all zeros subnets, NO if it 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 the network can support all ones subnets, NO if it 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 the network can support supernetting, that is multiple contiguous networks can be aggregated into a single routing announcement, NO if they 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 the network can support subnetting, that is parts of a single routing prefix can be separately routed, NO if they cannot. If you indicate NO, please provide an explanation in the "Additional Comments" section at the end of your application. Note: APNIC assumes all networks will use subnets. Failure to do so will require justification when applying for additional address space. Example: subnets: YES NETWORK-PLAN: This field provides information to APNIC on how the customer network in question will use the address space assigned to it by you within the next 24 months. The format of the NETWORK-PLAN field is: network-plan: address mask connect max hinit/h1yr/h2yr 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. h1yr - the number of devices planned after one year. h2yr - the number of devices planned after two years. remark - is a descriptive remark about the network. You may use as many NETWORK-PLAN fields as necessary to accurately describe the customer's network. The NETWORK-PLAN field is intended to be used to document the requirements for address space for the network you are requesting a second opinion for. In the 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 the network, do NOT simply replicate one line for each sub-network. Example: network-plan: 0.0.0.0 255.255.255.240 YES 14 1/5/11 HQ support group network-plan: 0.0.0.16 255.255.255.240 YES 14 4/8/8 HQ 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 HQ 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 Branch support network-plan: 0.0.1.0 255.255.255.0 YES 254 0/128/254 R&D network old-network: In order to increase the utilization of already allocated address space, APNIC must determine the usage of addresses already allocated to the organization requesting additional space. For the purposes of address allocation, "organization" means all parts of a company (including the parent company, subsidiaries, branch offices, etc. regardless of where those networks reside geographically or the name of the company) which are connected internally (including out-sourced private networks, e.g., "intranets"). If the 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 the actual network address used 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 a dialup), 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 the 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 Marketing old-network: 202.5.11.128 255.255.255.128 YES 112 Sales ADDITIONAL COMMENTS: This section is for you to provide whatever other details you feel may help justify the request. In particular, documenting the network topology via diagrams or providing detailed explanations why the address space usage and subnetting plans are the way they are can help APNIC understand the network requirements and will lead to faster processing of your request should there be any questions. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 6.0 Second Opinion Example -------------------------- #[SECOND OPINION TEMPLATE V:1.0]# acct-name: APNIC-AP netname: BUGSRUS descr: Bugs 'R' Us Corporate Network descr: Bugs 'R' Us, Inc. descr: Anytown, Thatprovince, 101010 country: NA host-bits: 9 all-0s-subnets: YES all-1s-subnets: YES supernets: YES subnets: YES network-plan: 0.0.0.0 255.255.255.240 YES 14 1/5/11 HQ support group network-plan: 0.0.0.16 255.255.255.240 YES 14 4/8/8 HQ 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 HQ 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.252 YES 2 2/2/2 branch x -> HQ network-plan: 0.0.0.100 255.255.255.252 YES 2 2/2/2 branch y -> HQ network-plan: 0.0.0.104 255.255.255.252 YES 2 2/2/2 branch z -> HQ network-plan: 0.0.0.108 255.255.255.252 YES 2 2/2/2 R&D -> HQ network-plan: 0.0.0.112 255.255.255.252 YES 2 2/2/2 emp. a -> HQ network-plan: 0.0.0.116 255.255.255.252 YES 2 2/2/2 emp. b -> HQ network-plan: 0.0.0.120 255.255.255.252 YES 2 2/2/2 emp. c -> HQ network-plan: 0.0.0.124 255.255.255.252 YES 2 2/2/2 emp. d -> HQ network-plan: 0.0.0.128 255.255.255.128 YES 126 1/64/126 Branch support network-plan: 0.0.1.0 255.255.255.0 YES 254 0/128/254 R&D network 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 #[TEMPLATES END]# Additional Comments: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 4.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. Rehkter, 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. Rehkter, "CIDR and Classfull 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. Rehkter, "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. Rehkter, 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. Rehkter, 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 isp-address-request APNIC Staff, "End User Internet Address Request Form", 7/25/98 URL: ftp://ftp.apnic.net/apnic/docs/isp-address-request end-user-address-request APNIC Staff, "End User Internet Address Request Form", 7/25/98 URL: ftp://ftp.apnic.net/apnic/docs/ end-user-address-request confed-address-request APNIC Staff, "Confederation Internet Address Request Form", 7/25/98 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 (usually 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 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.