Supporting Notes for the RIPE NCC Autonomous System Number Request
Form
Nurani Nimpuno
Sabrina Waschke
Document ID: ripe-228
Date: 2 October 2001
Obsoletes: ripe-147
See also: ripe-227
Contents
Abstract
Instructions
Administrative and Technical Information
Aut-num Template Fields
Maintainer Information
Contact Information
Abstract
This document provides supporting notes to the Autonomous System
Number Request Form. It contains instructions on how to complete the
request form for AS Numbers, in the RIPE document: "RIPE NCC
Autonomous System Number Request Form" at:
http://www.ripe.net/ripe/docs/asnrequestform.html
Instructions
Please read all the information below carefully before submitting your
application for an AS Number. For more detailed explanations on
routing policy objects, please refer to "Routing Policy Specification
Language (RPSL)" (RFC 2622). For an explanation on when an AS Number
is needed, please see: "Guidelines for Creation, Selection and
Registration of an Autonomous System" (RFC 1930). For Autonomous
System Number policies, please refer to the RIPE document: "European
Internet Registry Policies and Procedures" at:
http://www.ripe.net/ripe/docs/ir-policies-procedures.html
When sending the completed AS Number request form to the RIPE NCC, all
information requested in the form must be supplied, including the
technical routing policy. In some cases, the RIPE NCC will request
additional information.
Administrative and Technical Information
Current assignment guidelines only allow the RIPE NCC to assign AS
Numbers to multihomed organisations that need to define their own
unique routing policy. To evaluate the request in this regard, the
enterprise will have to provide information on who they will be
peering with by specifying a routing policy in the "import:" and
"export:" attributes. The enterprise will also have to provide
information about which IP addresses they will be routing
(originating) with this AS.
The "aut-num:" attributes described below are a minimal set sufficient
to register most common situations. Please consult RFC 2622 for full
details on the syntax of these and other attributes.
Note: All Database objects (such as mntner, as-set or router-set
objects) referenced in the aut-num template should be entered into the
Database before submitting the request or included on the request
form.
Aut-num Template Fields
-------------------------------------------------------
aut-num: <as number>
Specifies the temporary name of the AS to
be assigned. This name is usually needed
for the "export:" expression below. It
is suggested to use NEW. In case multiple
AS-es are required, NEW1, NEW2, etc can
be used. This field will be replaced with
the AS Number that will be assigned to
the organisation. This field is mandatory;
only a single line is possible.
as-name: <object-name>
The "as-name:" attribute is a descriptive
name (in RPSL name syntax) associated with
the AS. It is recommended to use an as-name
that relates to the organisation for which
the AS number is being requested. The
as-name should be written as a SINGLE word
of alphanumeric characters or a hyphen
('-') or underscore ('_') ONLY. It cannot
start with the prefix "AS". Please refer to
RFC 2622 for more information.
Example:
NAME-OF-ORGANISATION-AS
This field is mandatory; only a single
line is possible
descr: <free-form>
A short description of the Autonomous
System, including the organisation using
the AS Number and its location, to provide
sufficient detail to distinguish your
organisation from others in the RIPE Database.
The full postal address is not needed as this
is provided in the person template (see below).
This field is mandatory; multiple lines are
possible.
member-of: list of <set-name>
The value of the "member-of:" attribute
identifies an as-set object that this object
wants to be a member of. This claim, however,
should be acknowledged by a respective
"mbrs-by-ref:" attribute in the referenced
object. Please refer to RFC 2622 for more
information.
This field is optional; multiple lines are
possible.
import: [protocol <protocol-1>] [into <protocol-2>]
Specifies import policy expression.
Syntax: from <peering-1> [action <action-1>]
. . .
from <peering-N> [action <action-N>]
accept <filter>
Example:
aut-num: AS1
import: from AS2 accept { 128.9.0.0/16 }
The action specification is optional.
The semantics of an "import" attribute is as
follows: the set of routes that are matched by
<filter> are imported from all the peers in
<peerings>; while importing routes at
<peering-M>, <action-M> is executed. Please
refer to RFC 2622 for more information.
This field is optional; multiple lines are
possible.
export: to <peering-1> [action <action-1>]
Specifies an export policy expression.
Syntax:
export: to <peering-1> [action <action-1>]
. . .
to <peering-N> [action <action-N>]
announce <filter>
The action specification is optional.
The semantics of an export attribute is as
follows: the set of routes that are matched
by <filter> are exported to all the peers
specified in <peerings>; while exporting
routes at <peering-M>, <action-M> is executed.
Example:
aut-num: AS1
export: to AS2 announce AS4
Please refer to RFC 2622 for more information.
This field is optional; multiple lines are
possible.
default: to <peering> [action <action>]
[networks <filter>]
Description of default routes. If a peer will
be used as a default for this network, an
indication of how default routing will be done
should be provided here.
Syntax:
default: to <peering> [action <action>]
[networks <filter>]
The <action> and <filter> specifications are
optional. The semantics are as follows:
The <peering> specification indicates the AS
(and the router if present) it is being
defaulted to; the <action> specification, if
present, indicates various attributes of
defaulting, for example a relative preference
if multiple defaults are specified; and the
<filter> specifications, if present, is a policy
filter. A router only uses the default policy
if it received the routes matched by <filter>
from this peer.
This field is optional; multiple lines are
possible.
remarks: <free-form>
Remarks or comments, to be used for
clarification. This field is optional; multiple
lines are possible.
admin-c: The NIC handle referenced in the person object
(see below), which represents the administrative
contact for the Autonomous System. It is
recommended that the administrative contact is
physically located at the site that will be using
the AS Number. More than one contact can be
specified by adding more "admin-c:" fields.
This field is mandatory; multiple lines are
possible.
tech-c: The NIC handle referenced in the person object
(see below), which represents the technical
contact for the Autonomous System. There can
be more than one name specified in multiple
fields for this template.
This field is mandatory; multiple lines are
possible.
cross-mnt: list of <mntner-name>
Contains a list of mntner(s) to be notified for
overlaps with any of the prefixes announced in
route objects in which the given AS number is
specified in the "origin:" attribute.
A notification will be sent to mailbox(es)
listed in cross-nfy and mailbox(es) listed in
the "mnt-nfy:" attributes of the maintainers
referenced by the cross-mnt whenever an
overlapping route is added or removed.
This field is optional; multiple lines are
possible.
cross-nfy: <nic-handle>
The "cross-nfy:" attribute contains a
NIC-handle pointing to a person or role object.
The email address of this person or role object
will be used for notification for overlaps with
any of the prefixes announced in route objects
in which the given AS number is specified in
the "origin:" attribute.
This field is optional; multiple lines are
possible.
notify: <e-mail>
Specifies the e-mail address to which
notifications of changes to the aut-num object
will be sent.
This field is optional; multiple lines are
possible.
mnt-lower: list of <mntner-name>
Specifies the identifier of a registered mntner
object used for hierarchical authorisation.
Protects creation of objects directly (one level)
below in the hierarchy of the aut-num object.
The authentication method of this maintainer
object will then be used upon creation of any
object directly below this aut-num object.
This field is optional; multiple lines are
possible.
mnt-routes: <mnt-name>
[ { list of <address-prefix-range> } | ANY ]
This attribute references a maintainer object
which is used in determining authorisation for
the creation of route objects. After the
reference to the maintainer, an optional list
of prefix ranges inside of curly braces or the
keyword "ANY" may follow. The default, when no
additional set items are specified, is "ANY"
or all more specifics. Please refer to RFC 2622
for more information.
This field is optional; multiple lines are
possible.
mnt-by: list of <mntner-name>
Specifies the identifier of a registered mntner
object used for authorisation of operations
performed with the object that contains this
attribute. This field is mandatory; multiple
lines are possible.
changed: <e-mail> [<date>]
Specifies who submitted the update, and when
the object was updated. The format of the date
is YYYYMMDD; dates in the future are not
allowed. If the date is not specified, the
database will put the date when the update was
actually processed.
This field is mandatory; multiple lines are
possible.
source: <registry-name>
Specifies the registry where the object is
registered. Should be "RIPE" for the RIPE
Database.
This field is mandatory; only a single line
is possible.
aut-num: NEW
as-name: XMAS-AS
descr: Santa's Workshop Inc.
Christmas Toys Manufacturing Facility
Northern Nowhere
import: from AS1234
action pref=120;
accept ANY
import: from AS5678
action pref=100;
accept ANY
export: to AS1234
announce NEW
export: to AS5678
announce NEW
admin-c: CREW-RIPE
tech-c: OPS4-RIPE
mnt-by: SANTA-SECURITY-MNT
changed: hostmaster@ripe.net
source: RIPE
Maintainer Information
It is required for each aut-num (autonomous number) object to
reference a mntner (maintainer) object. If the maintainer information
is already in the RIPE Database, then the person handling the request
should check to see if it is up to date. If there is no database
entry, one should now be created by using the following template. An
example is included below.
#[MAINTAINER TEMPLATE]#
mntner: SANTA-SECURITY-MNT
descr: Santa's Workshop Inc. maintainer
admin-c: CREW-RIPE
tech-c: AUTO-1
tech-c: OPS4-RIPE
upd-to: santa@xmas.nn
auth: CRYPT-PW peEw8Gb4xBNqI
notify: jbgood@antarctic.nn
mnt-by: SANTA-SECURITY-MNT
referral-by: RIPE-DBM-MNT
changed: hostmaster@ripe.net
source: RIPE
Contact Information
Each aut-num and mntner object references contact persons, which also
need to be entered in the RIPE Database. If the contact information is
already in the RIPE Database, then the person handling the request
should check to see if it is up to date. If there is no database
entry, one should now be created by using the following template. An
example is included below.
#[PERSON TEMPLATE]#
person: Santa A Claus
address: Santa's Workshop Inc.
Jingle Bell Lane 12
1224CH Christmastown
Northern Nowhere
phone: +12 12 122 1122
+12 12 122 2211 ext. 1221
fax-no: +12 12 122 121
e-mail: santa@xmas.nn
nic-hdl: AUTO-1
notify: jbgood@antarctic.nn
mnt-by: SANTA-SECURITY-MNT
changed: jbgood@antarctic.nn
source: RIPE
**NOTE:
Each person or role object in the RIPE Database should contain a NIC
handle which allows unambiguous identification of the appropriate
persons as needed for Internet network administration. A RIPE NIC
handle has the form "MK16-RIPE". To obtain a NIC handle, just put
nic-hdl: AUTO-1
OR
nic-hdl: AUTO-1YourInitials
in the "nic-hdl:" field of the object to be added to the database. If
"YourInitials" are specified (no less than 2, and no more than 4
letters), the database will use them in constructing a NIC
handle. Otherwise, it will determine the letters itself. In both
cases, the NIC handle is guaranteed to be unique.
You can reference these (AUTO-1 or AUTO-1YourInitials) as temporary
NIC handles in the same update message in the fields of other objects
that require a NIC handle (e.g. the inetnum object described
above). 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 add more objects in one e-mail
message.