-------------------------------------------------------------------
APNIC Document identity
Title: APNIC Autonomous System Number Request Form
Short title: asn-request
Document ref: APNIC-028
Version: 001
Date of original publication: 1 September 1995
Date of this version: 1 September 1995
Review scheduled: n/a
Obsoletes: APNIC-020
Status: Obsolete
Comments: Obsoleted by APNIC-038
--------------------------------------------------------------------
APNIC Autonomous System Number Request Form
Issued: September 1, 1995
Expires: January 31, 1996
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:
as-request@rs.apnic.net
or in type written English via fax (discouraged) to:
+81-3-5276-6239
or in type written English via postal mail (as a last resort) to:
Asia Pacific Network Information Center
c/o The United Nations University
53-70, Jingumae 5-Chome,
Shibuya-ku, Tokyo 150, Japan
If you have any questions, 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-5276-3973. Note that
we do not accept autonomous system number 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: IT IS NOT NECESSARY TO INCLUDE THIS HEADER NOR THE INSTRUCTIONS
AT THE BOTTOM OF THIS FORM WITH YOUR APPLICATION.
- - - - - - - - - - - - - CUT HERE - - - - - - - - - - - - - - -
#[AUT-NUM TEMPLATE V2.0]#
acct-no:
aut-num:
as-name:
descr:
descr:
admin-c:
tech-c:
as-in:
as-in:
as-out:
as-out:
default:
mnt-by:
changed:
notify:
source: APNIC
#[PERSON TEMPLATE V3.0]#
person:
address:
address:
address:
address:
phone:
fax-no:
e-mail:
nic-hdl:
mnt-by:
changed:
notify:
acct-no:
source: APNIC
#[PERSON TEMPLATE V3.0]#
person:
address:
address:
address:
address:
phone:
fax-no:
e-mail:
nic-hdl:
mnt-by:
changed:
notify:
acct-no:
source: APNIC
#[TEMPLATES END]#
Comments:
- - - - - - - - - - - - - - CUT HERE - - - - - - - - - - - - - - - - -
Instructions For Completing This Form
-------------------------------------
For details on how to fill out the person template, please see
ftp://archive.apnic.net/apnic/docs/apnic-025.txt. IF YOU HAVE AN
APNIC ISSUED NIC HANDLE, PLEASE USE IT INSTEAD OF FILLING IN THE REST
OF THE PERSON TEMPLATE. If you have filled in NIC handles for the
admin-c and tech-c fields of the AUT-NUM template and no aspect of the
person's contact information has changed, you do NOT need to complete
the PERSON templates -- please leave the fields blank.
Before attempting to complete the AUT-NUM template provided above,
APNIC *strongly* recommends you read the supporting notes provided
below. Each autonomous system (AS) is represented in the APNIC
database by an AUT-NUM object. The AUT-NUM object stores descriptive,
administrative and contact information about the AS as well as the
technical information relating to the routing policies of the AS in
relation to all neighboring ASes. With an AUT-NUM object you must
also supply completed PERSON templates which gives the full contact
details for the administrative and technical contacts.
Below are the instructions for filling in the AUT-NUM template
for an Autonomous System Number Request form. Please provide
attributes for the tags listed correctly. Failure to do so may result
in delays in service. All information provided in this form will be
made available to the Internet via the APNIC Registration database.
As always, if you have any questions or comments regarding
this form, please contact hostmaster@apnic.net at your convenience.
Details for filling in the AUT-NUM object
-----------------------------------------
acct-no:
Please provide your APNIC account number if you have one. If you do
not have an APNIC account number, please see APNIC-030 available from:
ftp://archive.apnic.net/apnic/docs/apnic-030.txt
Example:
acct-no: 208789233
aut-num:
Please provide a count of how many AS numbers you will require. If
you will require more than 1, please provide justifying documentation
in the Comments section. Please note that APNIC only allocates AS
numbers for imminent demonstrated need, e.g., you will be multi-homing
within one or two weeks. There should be exactly one aut-num: tag
per AUT-NUM template.
Example:
aut-num: 1
as-name:
Please indicate the name of this autonomous system. Please use up to
25 alphanumeric and dash characters ONLY, do not use a domain name
sytle representation. This field is optional, but you should only
have one as-name: field per AUT-NUM request if you choose to use it.
Example:
as-name: TERABIT-BORDER-AS
descr:
Please complete with a short description of the autonomous system.
Please provide sufficient detail as to distinguish your AS from others
in the APNIC database, i.e., "descr: Computer Center AS" is not
sufficient. Also, please limit the number of descr: lines to 5. This
tag is required for all AUT-NUM templates.
Example:
descr: Terabit Labs Inc.
descr: Network Bugs Feeding Facility
descr: Northtown
admin-c:
Please provide the name or NIC handle of the person who is the
administrative contact for the autonomous system. 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 handles administrative functions for the autonomous system. If
you specify a name instead of a NIC Handle, 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. In
addition, please do not add periods between the names or initials 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). At least one admin-c:
tag is required for all AUT-NUM templates.
Example:
admin-c: John E Doe
or with a NIC handle (preferred)
admin-c: JD1-HK
tech-c:
Please provide the name or NIC handle of the person who is the
technical contact for the autonomous system. The NIC handle (if
known) is greatly preferred and will result in minimal delays when
processing your request. The technical contact need not be someone
physically located at the site of the autonomous system, but must be
someone who can resolve technical issues such as network problems. If
you specify a name instead of a NIC Handle, 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. In
addition, please do not add periods between the names or initials 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). At least one tech-c:
tag is required for all AUT-NUM templates.
Example:
tech-c: Mark A Smith
or with a NIC handle (preferred)
tech-c: MS4-NZ
as-in:
Please provide a description of routing information your AS will
accept from neighboring ASes. The format for this field is:
as-in: <aut-num> <cost> <routing policy expression>
where:
<aut-num> refers to the neighboring AS from which you will
be receiving routing information.
<cost> is a positive integer used to express a relative cost
of routes learned from the neighboring AS. The lower
the cost the more preferred the route.
<routing policy expression> is a description of the routing
policy taking the following formats:
1. A list of one or more ASes, AS Macros and Communities.
Example:
as-in: AS1103 100 AS1103
as-in: AS786 105 AS1103
as-in: AS786 10 AS786 HEPNET
as-in: AS1755 110 AS1103 AS786
2. A set of KEYWORDS. The following keywords are currently
defined:
ANY - anything the neighbor AS knows.
APNIC-DB - any network currently in the APNIC database.
LOCAL - any network in the APNIC database which is
part of the community LOCAL (i.e. no
connectivity outside its own organisation).
THIS-AS - a special keyword which will be translated
to the assigned autonomous system number
when the AS is allocated ONLY. Subsequently,
you should use the AS assigned to you instead
of THIS-AS. The use of THIS-AS primarily
makes sense in the context of as-out: (see
below)
Example:
as-in: AS1103 10 ANY
as-in: AS1104 1 APNIC-DB
as-in: AS102 100 LOCAL
3. A logical expression of either 1 or 2 above. The current
logical operators are defined as:
AND
OR
NOT
NOTE: if no logical operator is given between ASes, AS-macros,
Communities and KEYWORDS an implicit OR operation is
assumed, thus OR can generally be left out for
conciseness. Rules may also be grouped together using
parenthesis i.e "(" and ")".
Example:
as-in: AS1755 100 APNIC-DB AND NOT (LOCAL OR AS1234 OR AS513)
as-in: AS1755 150 AS1234
A rule can be wrapped over lines providing the associated
<aut-num> and <cost> values are repeated and occur on
consecutive lines. For example:
as-in: AS1755 100 APNIC-DB AND NOT (LOCAL AS1234 AS513)
and
as-in: AS1755 100 APNIC-DB AND NOT (LOCAL
as-in: AS1755 100 AS1234 AS513)
are evaluated to the same result.
You may provide as many as-in: statements as necessary to accurately
describe the routing information you accept from your peers, but at
least one as-in: tag is required.
Example:
As above.
as-out:
Please provide a description of generated routing information sent to
other AS peers. The format for this field is:
as-out: <aut-num> <routing policy expression>
where:
<aut-num> refers to your AS of your peer to which you will be
supplying routing information
<routing policy expression> is the routing policy expression
as described in the as-in: tag.
You may provide as many as-out: statements as necessary to accurately
describe the routing information you provide to your peers, but at
least one as-out: tag is required.
Example:
as-out: AS786 APNIC-DB AND NOT (AS978 LOCAL)
default:
If you will be using a peer as a default for your network, please
provide an indication of how default routing will be done. The format
of this field is:
default: <aut-num> <relative cost>
where:
<aut-num> is the AS peer you will default route to.
<relative cost> is the relative cost used to express a
preference for default. There is no relationship to
the cost used in the as-in: tag. The lower cost
indicates which AS peer is more preferred for default.
You may provide as many default: statements as necessary to accurately
describe your choice of autonomous systems you default to (including
none if you do not use default routing).
Example:
default: AS1755 10
default: AS786 5
changed:
Please indicate the email address of the person who is completing the
template, followed by the current date in the format of YYMMDD (YY is
the last 2 digits of the current year, MM is the month and DD is the
day, all values 0 filled). If you do not have email 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 email
address, you should supply exactly one changed: tag per AUT-NUM
template.
Example:
changed: johndoe@terabit.na 950225
notify:
Please provide a electronic mailbox of who should be notified when
this record changes. This can be useful if more than one person
manage the same object. When a record is altered, either through the
action of APNIC staff or via the database update mechanisms described
in APNIC-019, an advisory email will be sent by the database system.
If the update is not appropriate, you should immediately contact the
APNIC database manager apnic-dbm@apnic.net. The format of this field
is one RFC822 electronic mail address per line. Although multiple
lines are allowed, usage should be kept to a minimum. Please put
'dbmon@apnic.net' into this field if you do not wish to be notified of
changes. If you specify a mailbox other than dbmon@apnic.net, be sure
that the person at the other end of the mailbox understands what the
update advisories mean. There should be at least one notify: tag per
AUT-NUM template.
Example:
notify: dbmon@apnic.net
mnt-by:
Please provide the APNIC allocated maintainer ID. The maintainer ID
provides some level of control over who can update an object protected
by a mnt-by: field. If you do not have a maintainer ID, you should
apply for one using the APNIC Maintainer Object Request form found at:
ftp://archive.apnic.net/apnic/docs/apnic-026.txt
As routing information will be derived from the contents of the APNIC
Registration database based on the contents of the AUT-NUM fields, the
data should be accurate. To have some level of assurance that data is
not accidentally or maliciously modified, at least one mnt-by: should
be supplied. If one is not supplied, APNIC will generate one for you
with an auth: field of NONE (see APNIC-018). Additional mnt-by:
attributes may be specified, but each maintainer object must already
exist in the APNIC Registration database.
Example:
mnt-by: MAINT-FOO-JP
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
Supporting Notes
----------------
1. What is an Autonomous System?
An Autonomous System (AS) is a group of IP networks run by one or more
network operators having a single and clearly defined routing policy.
An AS will normally use one or more interior gateway protocols when
exchanging routing information internally within its own autonomous
system.
An AS has a unique number associated with it which is used in both the
exchange of exterior routing information (i.e. network reachability
information between ASes) and as an identifier of the AS itself.
Exterior routing protocols such as BGP are used to exchange routing
information between ASes.
The term AS is often confused and/or misused as a convenient way of
grouping together a set of networks which belong under the same
administrative umbrella even if within that group of networks there
are various different routing policies. An AS can strictly have
exactly one routing policy. APNIC will not allocate an AS number to
organizations unless the organization will have a different routing
policy than its service provider(s) in the immediate future (e.g.,
within one to two weeks).
The creation of an AS should be done in a conscious and well
coordinated manner to avoid creating ASes unnecessarily, perhaps
resulting in the worst case scenario of one AS per IP network number.
This may mean that by applying the general rules for the creation and
allocation of an AS below, some re-engineering may be needed.
However, this may be the only way to actually implement a desired
routing policy anyway.
As a general rule one should always try to populate an AS with as many
IP networks as possible, providing all IP networks conform to the same
routing policy.
2. How can I be sure I need an AS number?
The creation of an AS is only required when exchanging routing
information with other ASes. Some routing protocol implementations
make use of an AS number as a form of tagging to identify the routing
process. However, it should be noted that this tag does not need to
be unique unless routing information is indeed exchanged with other
ASes.
An IP network number can and must belong to exactly one AS. This is a
direct consequence of the fact that at each point in the Internet
there can be exactly one routing policy for traffic destined to a
specific network. In the case of a network which is used in peering
between two ASes, say at the border between two ASes, a conscious
decision must be made as to which AS this IP network number actually
resides in.
For a simple case of customer networks connected to a single service
provider, the customer's IP network(s) should be a member of the
service provider's AS. In terms of routing policy the customer IP
network has exactly the same policy as the service provider thus there
is no need to make any distinction in routing information. This idea
may at first seem slightly alien to some, but it highlights the clear
distinction in the use of the AS number as a representation of routing
policy as opposed to some form of administrative use.
If a network connects to more than one AS with different routing
policies then they need to create their own AS. In the case of
multi-homed customer networks connected to two service providers there
are at least two different routing policies to a given customer
network. At this point the customer networks should be part of a
single AS and this AS would be distinct from either of the service
providers ASes. This allows the customer the ability of having a
different representation of policy and preference to the different
service providers. This is the ONLY case where a network operator
should create its own AS number.
Acknowledgements
----------------
This document in derived in large part from documents written by the
staff of the European Registry, RIPE-NCC <ncc@ripe.net>, particularly
RIPE-109.