NewsRegistrarsConferences & EventsInternet StatisticsSite MapFAQContact UsHOME

   Internet Protocol Address Service   
IPv4 Address Policy DocumentationLocal Internet Registries (LIRs)
IPv4 Address Space Allocations and Assignments Service
Application InstructionRequest Process │  
Request Form -- Second Opinion Request Form  ISP Request Form

APNIC-073
=========

APNIC Second Opinion Request Form
Issued: August, 1998

This form is intended for use by service providers who wish to assign
address space to customers beyond their assignment window. TWNIC 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 TWNIC gains a better understanding of the
service provider's address assignment patterns, TWNIC 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 TWNIC 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@twnic.net.tw

or in type written English via fax (discouraged) to:

2396-8832

If you have any questions regarding this form, you may contact us via
email at hostmaster@twnic.net (preferred), fax at the above number,
postal mail at the above address or via telephone at 2341-1313
between 9:00 AM to 5:00 PM. 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.

 


top

 

 
Copyright 2002 Taiwan Network Information Center All Rights Reserved.
4F-2, No. 9, Roosevelt Rd., Sec. 2, Taipei 100, Taiwan, R.O.C.
TEL:886-2-23411313•FAX:886-2-2396-8832
E-mail:service@twnic.net.tw