-------------------------------------------------------------------
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:
+<country code>-<area/city code>-<exchange>-<subscriber>
If an extension is necessary, please add "ext <extension>". 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:
+<country code>-<area/city code>-<exchange>-<subscriber>
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 <ncc@ripe.net>.