|
APNIC-065
=========
APNIC Internet Service Provider Internet Address Request Form
Issued: August, 1998
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.
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,
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 - - - - - - - - - - - -
- - -
#[NETWORK TEMPLATE V:5.0]#
netname:
descr:
descr:
country:
admin-c:
tech-c:
remarks:
changed:
mnt-by:
source: TWNIC
#[PERSON TEMPLATE V:4.0]#
person:
address:
address:
country:
phone:
fax-no:
e-mail:
nic-hdl:
remarks:
changed:
mnt-by:
source: TWNIC
#[PERSON TEMPLATE V:4.0]#
person:
address:
address:
country:
phone:
fax-no:
e-mail:
nic-hdl:
remarks:
changed:
mnt-by:
password:
source: TWNIC
#[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]#
Explanation why you cannot obtain addresses from your service
provider:
Additional Comments:
- - - - - - - - - - - - - - CUT HERE - - - - - - - - - - -
- - - - - -
1. Instructions For Completing This Form
Below are the instructions for filling in an APNIC Internet
Service
Provider Internet 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
other
mechanisms. 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 Pty 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. ISP Internet Address Request Network Template Details
NETNAME:
Please provide a short but meaningfully descriptive name for
this
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. 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 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 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 NETWORK templates, with only one COUNTRY tag permitted.
Example:
country: JP
ADMIN-C:
Please provide the APNIC NIC handle (NIC handles from other
registries
are not currently accepted) of the person who is the administrative
contact for the network. If you do not have an APNIC NIC handle,
please see the section below entitled "Obtaining an APNIC
NIC
Handle". The administrative contact must be someone who is
physically
located at the site of the network and at least one ADMIN-C
tag is
required for all NETWORK templates.
Example:
admin-c: JD1-AP
TECH-C:
Please provide the APNIC NIC handle (other registry NIC handles
are
not currently accepted) of the person who is the technical
contact for
the network. If you do not have an APNIC NIC handle, please
see the
section below entitled "Obtaining an APNIC NIC Handle". 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. At least one TECH-C tag is required for all
NETWORK
templates.
Example:
tech-c: MS4-AP
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 19950101
CHANGED:
Please indicate the e-mail address of the person who is completing
the
template followed by the current date in the format of YYYYMMDD
(YYYY
is the current year, MM is the month and DD is the day, all
values 0
filled). 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 19950225
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 information is always required in the
database
and has already been added to the forms.
Example:
source: APNIC
3. ISP Internet Address Request Person Template Details
PERSON:
Please give the full name of the person this template will
represent.
Do not use formal titles like `Dr' or `Prof.' or `Sir' and
please
provide full names, not initials. The name should be provided
as the
person 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). 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 (albeit without the country which
is
provided using the COUNTRY field described below) 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 ISO 3166 country code appropriate
for the
contact person. 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 this person's address, please see the list of ISO
3166 codes
maintained on APNIC at
ftp://ftp.apnic.net/apnic/docs/iso-3166.txt
This tag is required for all PERSON templates, with only one
COUNTRY
tag permitted.
Example:
country: JP
PHONE:
Please provide the work telephone number of the person specified
in
this template 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 a valid Internet reachable
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 identifier 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, a handle will be automatically generated
for you
if you follow the procedures described below in the section
entitled
"Obtaining an APNIC NIC Handle". 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 and leave this field
blank.
If you have a NIC handle assigned by another registry, e.g.,
InterNIC,
please provide a full person template anyway using the auto-generating
handles as described below -- the regional registries are
currently
investigating ways in which information such as this can be
shared,
but no solution has yet been implemented.
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 YYYYMMDD
(YYYY
is the current year, MM is the month and DD is the day, all
values 0
filled). You should supply exactly one CHANGED tag per PERSON
template if this is a new person object.
Example:
changed: johndoe@terabit.na 19950225
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 information is always required in the
database
and has already been added to the forms.
Example:
source: APNIC
4. ISP 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 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
CONNECTIVITY:
Please indicate how your network will be connecting to the
Internet.
Acceptable 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 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.
Examples
of SERVICE-PROVIDER connectivity would be MCI, UUNet, etc.
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 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. It is assumed however
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 you have assigned networks to customers, you MUST provide
the
re-assignment information for those networks in the following
format:
cust-network: netname address mask hinit/h1yr/h2yr sinit/s1yr/s2yr
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
h1yr - the estimated number of devices after one year
h2yr - the estimated number of devices after two years
sinit - the estimated number of subnets initially
s1yr - the estimated number of subnets after one year
s2yr - the estimated number of subnets after two years
date - the date the assignment occurred in YYYYMMDD 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 allows 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. 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 19960501
cust-network: BAR-AP 202.12.28.128 255.255.255.128 60/70/100
2/3/4 19960515
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. Please be as descriptive as possible about the
way the
IP addresses for each subnet are being deployed.
*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 you have used. Any address space not
described in CUST-NETWORK and INFRASTRUCTURE will be assumed
to be
unused.
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. As such,
it is not
necessary to specify addresses will be assigned to customers.
*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
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. ISP 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)
It must be noted however 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 over 50,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 50,000+ 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 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 Internet 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 to take
you to
a search engine :
http://www.rfc-editor.org/rfc.html
where you can search for "Renumbering". The resulting matches
will
provide a number of rfc documents authored by this working
group.
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 block to be used for their internal infrastructure needs
and their
first customers. Generally, APNIC will allocate a /19 to ISPs
when
they first approach APNIC even if their host requirements
do not imply
the need of a /19. If a /19 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. 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. If the ISP
does not
update the database as assignments are made, APNIC has no
information
by which to gauge the ISPs growth rate.
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 while also providing a means by which the ISP can
(eventually)
reach a reasonable level of address self-sufficiency.
6. Obtaining an APNIC NIC Handle
If you are completing a person template or want to reference
a person
in an another object in the APNIC registration database, you
should
use an APNIC NIC handle ('nic-hdl:'). NIC handles will give
you a
unique identifier attached to a person which you can use as
a
reference in those cases where multiple individuals have the
same
name. You can obtain an APNIC NIC handle by putting the following
in
the NIC-HDL field:
nic-hdl: AUTO-1
(that's a one, not the letter 'ell'). This will result in
the
database software deriving creating an APNIC handle from your
first
and last initials. For example, if you submitted the following
person
object (please don't):
person: David Conrad
address: Asia Pacific Network Information Center
address: Level 1, 33 Park Road
address: P. O. Box 2131
address: Milton, QLD 4064
country: AU
[...]
nic-hdl: AUTO-1
[...]
the database software would generate a NIC handle of the form
DC###-AP
where ### is the next available number that insures the APNIC
NIC
handle starting with DC would be unique.
Alternatively, you can specify the initials to use as the
prefix for
the handle instead of having the database software generate
them
itself. If you specify the NIC-HDL as:
nic-hdl: AUTO-1
where (without the '<' and '>') are no more than
4
characters, the database software will use those initials
to create
the handle. For example:
person: David Conrad
address: Asia Pacific Network Information Center
address: Level 1, 33 Park Road
address: P. O. Box 2131
address: Milton, QLD 4064
country: AU
[...]
nic-hdl: AUTO-1RC
[...]
the database software would generate a NIC handle of the form
RC###-AP
where ### is the next available number that insures the NIC
handle
starting with RC.
You can use the same identifiers (AUTO-1 or AUTO-1)
in the
same update message in other objects as a reference. The database
software will then fill in the freshly assigned NIC handles
in the
objects. Note that you can also use other numbers (example:
AUTO-2) so
that you can update more person objects and objects that reference
the
persons in one E-mail message. For example:
[...]
admin-c: AUTO-1
tech-c: AUTO-2
[...]
person: David Conrad
[...]
nic-hdl: AUTO-1
[...]
person: Yoshiko Chong
[...]
nic-hdl: AUTO-2
[...]
will result in two new handles being created, one of the form
DC###-AP
filled in for the ADMIN-C and David Conrad's NIC-HDL fields
and the
other, YC###-AP filled in for the TECH-C and Yoshiko Chong's
NIC-HDL
fields.
7. 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 19960501
mnt-by: MAINT-APNIC-AP
source: APNIC
#[PERSON TEMPLATE V:4.0]#
person: David R Conrad
address: Asia Pacific Network Information Center
address: Level 1, 33 Park Road
address: P. O. Box 2131
address: Milton, QLD 4064
country: AU
phone: +61-7-3367-0490
fax-no: +61-7-3367-0482
e-mail: davidc@apnic.net
nic-hdl: DC1-AP
changed: davidc@apnic.net 19960401
mnt-by: MAINT-APNIC-AP
source: APNIC
#[PERSON TEMPLATE V:4.0]#
person: Yoshiko O Chong Fong
address: Asia Pacific Network Information Center
address: Level 1, 33 Park Road
address: P. O. Box 2131
address: Milton, QLD 4064
country: AU
phone: +61-7-3367-0490
fax-no: +61-7-3367-0482
e-mail: yoshiko@apnic.net
nic-hdl: YF1-AP
changed: davidc@apnic.net 19960401
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/45/110
1/1/2 19960301
cust-network: BAR-AP 202.12.28.128 255.255.255.128 60/70/100
2/3/4 19960315
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.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 Blech
City POP
network-plan: 0.0.1.0 255.255.255.0 YES 254 0/128/254 Blahville
POP
#[TEMPLATES END]#
Explanation 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.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - -
8. 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
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 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.
9. Acknowledgements
This document in derived in large part from documents written
by the
staff of the European Registry, RIPE-NCC ncc@ripe.net.
|
HOME
IPv4 Address Space Allocations and Assignments Service
