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: 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: 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: 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 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 ] [into ] Specifies import policy expression. Syntax: from [action ] . . . from [action ] accept 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 are imported from all the peers in ; while importing routes at , is executed. Please refer to RFC 2622 for more information. This field is optional; multiple lines are possible. export: to [action ] Specifies an export policy expression. Syntax: export: to [action ] . . . to [action ] announce The action specification is optional. The semantics of an export attribute is as follows: the set of routes that are matched by are exported to all the peers specified in ; while exporting routes at , 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 [action ] [networks ] 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 [action ] [networks ] The and specifications are optional. The semantics are as follows: The specification indicates the AS (and the router if present) it is being defaulted to; the specification, if present, indicates various attributes of defaulting, for example a relative preference if multiple defaults are specified; and the specifications, if present, is a policy filter. A router only uses the default policy if it received the routes matched by from this peer. This field is optional; multiple lines are possible. remarks: 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 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: 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: 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 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: [ { list of } | 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 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: [] 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: 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.