------------------------------------------------------------------- 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: where: refers to the neighboring AS from which you will be receiving routing information. 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. 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 and 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: where: refers to your AS of your peer to which you will be supplying routing information 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: where: is the AS peer you will default route to. 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 , particularly RIPE-109.