------------------------------------------------------------------- APNIC Document identity Title: APNIC Autonomous System Number Request Form Short title: asn-request Document ref: APNIC-066 Version: 001 Date of original publication: August 1998 Date of this version: August 1998 Review scheduled: n/a Obsoletes: APNIC-058 Status: Obsolete Comments: This document also exists as an online web form (with appropriate modifications). -------------------------------------------------------------------- APNIC Autonomous System Number Request Form This form is intended to be used to request an "autonomous system (AS) number" useful in facilitating routing in multi-homed environments. Unless you are multi-homed to more than one Internet service provider, you will generally not need an autonomous system number. See RFC 1930 to determine whether an AS number is justified in your case. 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@apnic.net or in type written English via fax (discouraged) to: 7-3367-0482 or in typewritten English via postal mail (as a last resort) to: Asia Pacific Network Information Center Level 1, 33 Park Road P. O. Box 2131 Milton, QLD 4064 Australia If you have any questions regarding this form, please contact us via email at hostmaster@apnic.net (preferred), fax at the above number, postal mail at the above address or via telephone at 7-3367-0490 between 9:00 AM to 5:00 PM Australian Eastern Standard Time. 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 V:3.0]# acct-name: aut-num: as-name: descr: descr: country: admin-c: tech-c: as-in: as-in: as-out: as-out: default: mnt-by: remarks: changed: source: APNIC #[PERSON TEMPLATE V:4.0]# person: address: address: address: country: phone: fax-no: e-mail: nic-hdl: mnt-by: remarks: changed: source: APNIC #[PERSON TEMPLATE V:3.0]# person: address: address: address: country: phone: fax-no: e-mail: nic-hdl: mnt-by: remarks: changed: source: APNIC #[TEMPLATES END]# Additional Comments: - - - - - - - - - - - - - - CUT HERE - - - - - - - - - - - - - - - - - 1. Instructions For Completing This Form ---------------------------------------- Below are the instructions for filling in an APNIC Autonomous System Number 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 AS number you are requesting. NOTE: Experience has shown the AS-IN, AS-OUT, and DEFAULT fields are prone to errors. *THESE FIELDS ARE NOT OPTIONAL*. If you have any questions on how to fill in these fields, please contact hostmaster@apnic.net. 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 or reference NIC handles that exist in the APNIC Registration database (NIC handles from other databases are not currently accepted). All information provided with the templates in this form (with the exception of the account name) will be 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. Autonomous System Number 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 AS application 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 AUT-NUM: Please provide a count of how many AS numbers you will require. If you will require more than one, please provide justifying documentation in the ADDITIONAL COMMENTS section. Note that APNIC ONLY allocates AS numbers for imminent demonstrated need, e.g., you will be multi-homing to two different service providers within one or two weeks. There should be exactly one AUT-NUM tag per AUT-NUM template. Example: aut-num: 1 AS-NAME: Please provide a short but meaningfully descriptive name for this autonomous system. The AS-NAME is used mainly for administrative purposes such as consistency checking of the Internet Registry. The autonomous system name should be written as a SINGLE word of less than 25 capital alphanumeric characters or a hyphen ('-') ONLY. It is requested you use an autonomous system name that relates to the organization for which the AS number is being requested. Please do NOT use domain names, such as FOO.COM, as the autonomous system name has no relation with the domain name system. There should be exactly one AS-NAME tag per AUT-NUM template. Example: as-name: TERABIT-AP DESCR: Please complete with a short description of the organization including the location to provide sufficient detail 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 AUT-NUM templates. Example: descr: Terabit Labs Inc. descr: Border AS descr: Network Bugs Feeding Facility, Northtown COUNTRY: Please give the two letter ISO 3166 country code appropriate for the organization requesting the autonomous system number. 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 autonomous systems crossing national boundaries, so choose the most appropriate country based on the location of the administrative contact. This tag is required for all AUT-NUM templates, with only one COUNTRY tag permitted per template. 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 autonomous system. 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 autonomous system and at least one ADMIN-C tag is required for all AUT-NUM 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 autonomous system. If you do not have an APNIC NIC handle, please see the section below titled "Obtaining an APNIC NIC Handle". The technical contact need not be physically located at the site of the autonomous system, but rather is the person who is responsible for the day-to-day operation of the network(s). At least one TECH-C tag is required for all AUT-NUM templates. Example: tech-c: MS4-AP AS-IN: Please provide a description of routing information your AS will accept from neighboring ASes. The format for this field is: as-in: which can be read as: "receive routing information from AS tagging it with weight if it passes the expression specified in " where: is 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. THIS-AS - a special keyword which will be translated to the assigned autonomous system number when the AS number is allocated. The use of THIS-AS primarily makes sense in the context of as-in: (see below) Example: as-in: AS1103 10 ANY 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 AS102 AND NOT (AS1234 OR AS513) as-in: AS1755 150 ANY AND NOT 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 AS102 AND NOT (AS1234 AS513) and as-in: AS1755 100 AS102 AND NOT 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 two AS-IN tags are 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: which can be read as: "send to AS our routing information if such information passes the expression specified in " 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. with the exception of the "ANY" 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 two AS-OUT tags are required. Example: as-out: AS786 AS701 AND NOT (AS978 AS65535) 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 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 APNIC 19990101 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 AUT-NUM template. 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 AUT-NUM 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. Autonomous System Number Request Person Template Details ----------------------------------------------------------- The fields of the PERSON template(s) should only be filled in when an APNIC NIC handle is being requested or when the contact information for an existing PERSON object must be modified. If the administrative and technical contacts already have APNIC NIC handles, please use them instead of requesting new APNIC NIC handles. 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: 20-1233-4676 phone: 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: 20-1233-4678 E-MAIL: Please supply the electronic mail address for the person. The electronic mail address MUST be an Internet reachable valid 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 titled "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 and leave the NIC-HDL field blank -- 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 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: -pager can be used for paging. 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. Supporting Notes ------------------- 4.1 What is an Autonomous System? An Autonomous System (AS) is a group of Internet 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. 4.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. 5. 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. 6. Recommended Reading ---------------------- RFC 1771 Y. Rehkter, T. Li, "A Border Gateway Protocol 4 (BGP-4)", 03/21/1995. (Pages=57) (Format=.txt) URL: ftp://ftp.apnic.net/ietf/rfc/rfc1771.txt RFC 1772 Y. Rehkter, P. Gross, "Application of the Border Gateway Protocol in the Internet", 03/21/1995. (Pages=19) (Format=.txt) URL: ftp://ftp.apnic.net/ietf/rfc/rfc1772.txt RFC 1773 P. Traina, "Experience with the BGP-4 protocol", 03/21/1995. (Pages=9) (Format=.txt) URL: ftp://ftp.apnic.net/ietf/rfc/rfc1773.txt RFC 1774 P. Traina, "BGP-4 Protocol Analysis", 03/21/1995. (Pages=10) (Format=.txt) URL: ftp://ftp.apnic.net/ietf/rfc/rfc1774.txt RFC 1786 T. Bates, E. Gerich, L. Joncheray, J. Jouanigot, and others, "Representation of IP Routing Policies in a Routing Registry (ripe-81)", 03/28/1995. (Pages=83) (Format=.txt) URL: ftp://ftp.apnic.net/ietf/rfc/rfc1786.txt RFC 1930 J. Hawkinson, T. Bates, "Guidelines for creation, selection, and registration of an Autonomous System (AS)", 04/03/1996. (Pages=10) (Format=.txt) URL: ftp://ftp.apnic.net/ietf/rfc/rfc1930.txt RFC 1998 E. Chen, T. Bates, "An Application of the BGP Community Attribute in Multi-home Routing", 08/30/1996. (Pages=9) (Format=.txt) URL: ftp://ftp.apnic.net/ietf/rfc/rfc1998.txt These documents are all available from the APNIC document store in the directories mentioned in the URLs. The APNIC document store can be accessed in a number of ways: 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 a fee may be associated with the delivery of hardcopy versions of documents. 7. Acknowledgements ------------------- This document in derived in large part from documents written by the staff of the European Registry, RIPE-NCC , particularly RIPE-109.