Important notes:

The PDF document hosted on this page is the authoritative version of the Policy Manual. The web version is provided to make it easier for readers to quickly browse the different sections of the Manual.

In the event of a conflict between the web version and the pdf version of the Manual, the pdf version shall control.

This document and/or information was originally written in Spanish, the official language of Uruguay, the country where LACNIC is legally incorporated and whose laws and regulations LACNIC must meet. Likewise, unofficial information and/or documents are also written in Spanish, as this is the language in which most of LACNIC's collaborators and officers work and communicate. We do our best to ensure that our translations are reliable and serve as a guide for our non-Spanish-speaking members. However, discrepancies may exist between the translations and the original document and/or information written in Spanish. In this case, the original text written in Spanish will always prevail.

An Autonomous System (AS) is a group of IP address networks managed by one or more network operators having a clear and unique routing policy. Each Autonomous System (AS) has an associated number that is used as the Autonomous System’s identifier when exchanging external routing information. Exterior routing protocols, such as BGP, are used for exchanging routing information among Autonomous Systems.

The term "Autonomous System" is frequently misinterpreted as merely a convenient way to refer to a group networks that are under the same management. However, if there is more than one routing policy in the group, then more than one AS is necessary. On the other hand, if the group of networks has the same policy as the other groups, they fall within the same AS regardless of their management structure. Thus, by definition, all networks that make up an Autonomous System share the same routing policy.

In order to simplify global routing tables, a new Autonomous System Number (ASN) should only be assigned when a new routing policy is necessary.

Sharing the same ASN among a group of networks that are not under the same management will require additional coordination among network administrators and, in some cases, will require redesigning the network to a certain degree. However, this is probably the only way to implement the desired routing policy.

LACNIC shall allocate Autonomous System Numbers to those organizations that meet the following requirements:

  1. The organization must have the need to interconnect with other independent Autonomous Systems at the time of the application, or be planning to interconnect within a period of no more than six (6) month as of the moment of the application. After this period, LACNIC may revoke the assigned ASN if it has not been used.
  2. Detail the applicant's routing policy, specifying the ASNs with which the organization will interconnect and the IP addresses that will be announced through the requested ASN.

It is the obligation of the organization receiving an Autonomous System Number from LACNIC to maintain updated records of postal addresses and points of contact.

LACNIC's WHOIS system allows representing up to three different points of contact, namely:

owner−c, which represents the administrative contact of the organization to which the ASN was assigned;

routing−c, contact who, by means of the IP and ASN administration system, may register the routing policies adopted by the Autonomous System;

abuse−c, security contact (Abuse Contact).


16-bit AS numbers were defined in RFC 1930 and integers ranging from 0 to 65535 will be used for their identification. Likewise, 32-bit AS numbers were defined by RFC 4893 and, integers ranging from 0 to 4294967295 will be used for their identification. In both cases the “asplain” decimal value representation defined in RFC 5396 will be used.

Consequently, the following terminology will be adopted to refer to 16-bit and 32-bit ASNs:

  • "16-bit only AS Numbers" refers to AS numbers in the range 0 – 65535
  • "32-bit only AS Numbers" refers to AS Numbers in the range 65536 − 4294967295
  • "32-bit AS Numbers" refers to AS Numbers in the range 0 – 4294967295

3.2.AS Allocation Phases

There shall be three phases for ASN allocation on the part of LACNIC:

  1. On 1 January 2007, the registry will process applications that specifically request 32-bit only AS Numbers and allocate such AS Numbers as requested by the applicant. In the absence of any specific request for a 32-bit only AS Number, a 16-bit only AS Number will be allocated by the registry.
  2. On 1 January 2009, the registry will process applications that specifically request 16-bit only AS Numbers and allocate such AS Numbers as requested by the applicant. In the absence of any specific request for a 16-bit only AS Number, a 32-bit only AS Number will be allocated by the registry
  3. As of January 1st, 2010, LACNIC shall allocate 32-bit AS numbers by default. 16-bit AS numbers shall be allocated, if available, in response to applications specifically requesting said resource and that duly justify the technical reasons why a 32-bit AS number would not be appropriate for its needs.

3.3.Mergers, Acquisitions, Reorganizations or Relocations

Because LACNIC's policies do not recognize the non-authorized sale or transfer of assigned or allocated resources, such transfers will be considered invalid.

Nevertheless, LACNIC will process and register any ASN resource transfer that occurs as a result of a partial or complete merger, acquisition, business reorganization or relocation, regardless of whether the resources are held by an ISP or an end-user.

To initiate this change and proceed with the registration, legal documentation must be submitted which, at the discretion of LACNIC, supports the operation. Examples of such documentation include:
• A copy of the legal document validating the transfer of assets.
• A detailed inventory of all the assets used by the applicant for maintaining the resources in use.
• A list of the applicant's clients using the resources.

The need to maintain all the resources must also be justified, forcing the return of the surplus resources if applicable or, alternatively, the transfer of such surplus resources to third parties under the policies in force (3.). When resources are to be returned, LACNIC will determine the corresponding conditions and deadline.

3.4. Inclusion of origin ASN in WHOIS responses when available

Provided that this information is available, LACNIC shall include the origin ASN of the queried prefixes in its WHOIS responses.

The origin ASN of the assigned block may be extracted from the RPKI repository, considering the origin specified in the ROA as the origin ASN.

If a block’s origin ASN is not specified, the WHOIS response shall explicitly state this fact.