Routing Policy Rules for ASN Numbers

The original 16-bit format offered only 65,536 values, forcing a migration to a 32-bit pool containing 4,294,967,296 numbers per ARIN data. An Autonomous System Number serves strictly as an identifier for a single routing policy, not merely a corporate management boundary. Network engineers often confuse administrative control with technical necessity, leading to bloated global tables that could be avoided by adhering to LACNIC definitions.

You will learn why sharing an ASN across different management groups demands excessive coordination and often requires significant network redesign. The discussion details how BGP exchanges external information only when a distinct policy exists, rendering multiple numbers unnecessary for uniform traffic handling. We will also examine the strict six-month utilization window LACNIC enforces before revoking unused allocations.

Operators must understand that IP address networks under identical policies belong in one system regardless of their ownership structure. ASN lookup tools reveal these distinctions by mapping IP addresses to their specific network owners and countries. Ignoring these fundamental mechanics results in inefficient resource consumption and potential policy conflicts within the global routing infrastructure.

Autonomous System Definitions and Routing Policy Fundamentals

Autonomous System Definition and Unique Routing Policy Requirement

BGP relies on policy unity to exchange external routing information effectively across the global internet. An Autonomous System constitutes a group of IP networks governed by one distinct routing policy, not merely shared management. The original 16-bit Autonomous System Number (ASN) range consists of 65,536 unique values, covering numbers from 0 to 65,535, whereas the expanded 32-bit format provides a total pool of 4,294,967,296 unique numbers. Despite this vast expansion, assigning a new number remains justified only when a new routing policy is necessary.

Sharing an identifier among networks not under the same management requires additional coordination among network administrators and, in some cases, will require redesigning the network to a certain degree. Applicants must detail their specific interconnection plans and the IP addresses they intend to announce before allocation. Organizations must meet specific requirements, such as having the need to interconnect with other independent Autonomous Systems at the time of application or within six months.

Administrative convenience often clashes with routing stability. To simplify global routing tables, a new Autonomous System Number (ASN) should only be assigned when a new routing policy is necessary. Operators must prioritize technical accuracy over organizational structure to maintain internet integrity.

Applying AS Boundaries When Multiple Routing Policies Exist

A distinct Autonomous System boundary forms immediately when a network group adopts a second routing policy, regardless of management structure. Exterior routing protocols, such as BGP, require this separation to exchange external routing information correctly between domains. If an entity enforces multiple policies, it necessitates more than one AS to maintain protocol integrity.

Conversely, networks sharing an identical policy fall within the same AS even if different teams manage them physically. This definition prevents unnecessary fragmentation of global routing tables while ensuring accurate path selection. Operators in the LACNIC region face complex coordination requirements if they attempt to share an ASN across non-managed networks without redesign.

Adherence to policy-based boundaries rather than organizational charts helps avoid future renumbering events. By definition, all networks that make up an Autonomous System share the same routing policy.

Verifying LACNIC Policy Manual Authority and Language Precedence

Validate policy compliance by confirming the PDF document serves as the authoritative version over web renders. The text explicitly states that in any conflict between these formats, the PDF version shall control operational decisions. Operators must also recognize that the original Spanish text, reflecting Uruguay incorporation laws, prevails over all translations. Discrepancies may exist between the translations and the original document written in Spanish; in this case, the original text will always prevail. This hierarchy prevents misinterpretation of rules governing Autonomous System assignments during audits.

Operators should execute the following verification steps:

• Download the official PDF file directly from the registry portal.
• Compare specific clauses against the rendered web page content.
• Consult the original Spanish text when translation ambiguity arises.
• Archive the PDF version for internal legal reference.

The web version is provided to make it easier for readers to quickly browse the different sections of the Manual, but the PDF document hosted on the page is the authoritative version. Treating translated documents as informal guides ensures accurate interpretation of allocation criteria and prevents administrative rejection.

Technical Mechanics of 16-bit and 32-bit ASN Allocation

Defining 16-bit and 32-bit ASN Ranges per RFC Standards

RFC 1930 established the original 16-bit AS numbers using integers ranging from 0 to 65,535. This specification restricts the legacy pool to exactly 65,536 unique values. Engineers later extended capacity via RFC 4893, which defines a secondary format supporting integers ranging from 0 to 4,294,967,295. Such expansion keeps the protocol viable despite exponential growth in network edge devices. Implementation requires strict adherence to asplain decimal representation for both formats. Operators must distinguish between "16-bit only" allocations and the broader "32-bit" category during infrastructure planning. Private routing scenarios often apply reserved high-range blocks instead of requesting public resources; within the 16-bit range, ASNs 64,512 to 65,534 are specifically reserved for Private Use.

Transitioning from the limited 16-bit space to the vast 32-bit space accommodates future growth. The legacy format offers only 65,536 unique values compared to the billions available in the expanded architecture.

LACNIC Allocation Phases and Default 32-bit Assignment Rules

LACNIC implemented specific phases for ASN allocation to manage the transition to the expanded number space. On January 1, 2007, the registry began processing applications that specifically requested 32-bit AS numbers. This operational shift prevents exhaustion of the legacy 16-bit space while maintaining global uniqueness through the allocation hierarchy managed by IANA. The registry enforces strict phases to manage this transition effectively:

1. Initial processing allowed specific 32-bit requests starting in 2007.
2. Subsequent phases adjusted default assignments to preserve the limited 16-bit pool.
3. Current policy emphasizes the necessity of a unique routing policy for any new ASN assignment.

On 1 January 2009, the registry processes applications specifically requesting 16-bit only AS Numbers and allocates them as requested. As of January 1st, 2010, LACNIC shall allocate 32-bit AS numbers by default. Network architects should note that sharing the same ASN among networks not under the same management requires additional coordination and may require redesigning the network. This constraint exists because all networks within an Autonomous System must share the same routing policy by definition. Most modern routers handle the full range of available identifiers natively. Organizations are advised to request 32-bit ASNs unless specific constraints dictate otherwise. This approach aligns with the global standard for resource distribution.

Justification Checklist for Requesting Legacy 16-bit ASN Numbers

Applicants must detail their routing policy to receive an identifier. LACNIC allocates numbers based on specific needs, so operators must demonstrate why a new routing policy is necessary. The primary validation step involves specifying the ASNs with which the organization will interconnect and the IP addresses that will be announced through the requested ASN. Operators should prepare the following technical justifications:

1. A clear definition of the unique routing policy requiring the ASN.
2. Specification of the ASNs with which the organization will interconnect.
3. Identification of the IP addresses that will be announced through the requested ASN.

The allocation hierarchy managed by IANA and implemented by RIRs dictates that resource distribution follows strict validation protocols. An Autonomous System represents a group of IP address networks managed by one or more operators having a clear and unique routing policy. If a group of networks has the same policy as other groups, they fall within the same AS regardless of their management structure. Simplifying global routing tables requires assigning a new ASN only when a new routing policy is necessary.

Operational Procedures for ASN Registration and WHOIS Management

LACNIC Interconnection Need and Six-Month Usage Window

Applicants must demonstrate an immediate interconnection requirement or a concrete plan to connect within six months. This strict timeline prevents resource fragmentation by ensuring allocated numbers serve active routing policies rather than speculative inventory. Failure to apply the ASN within this window exposes the assignment to revocation by LACNIC.

Operators should execute the following validation steps before applying:

1. Confirm physical peering agreements are signed with at least one independent Autonomous System.
2. Document the specific IP prefixes intended for announcement through the new identifier.
3. Prepare a technical diagram showing the distinct routing policy separate from upstream providers.

The operational risk lies in the gap between allocation and deployment; holding an unused number violates the core principle of distinct policy enforcement. Unlike some regions allowing longer lead times, this jurisdiction mandates proof of near-term utility to maintain registry hygiene. InterLIR advises that organizations lacking a verified six-month deployment window should delay application to avoid administrative penalties. The consequence of missing this deadline is not merely a request for extension but potential loss of the identifier entirely. This approach ensures the global routing table remains efficient and free from dormant entries.

Submitting Routing Policies and Legal Documents for ASN Approval

Applicants must detail their routing policy, specifying the ASNs for interconnection and IP addresses to be announced. This technical declaration forms the backbone of the application, ensuring the requested identifier serves a distinct function within the global BGP system rather than adding noise to routing tables. Operators define these parameters to demonstrate a clear separation of traffic engineering goals from upstream providers. The submission process requires precise configuration of contact roles within the WHOIS database. Administrators must assign an owner−c for administrative matters, a routing−c to manage policy updates via the IP and ASN administration system, and an abuse−c for security incidents.

Administrators must immediately update postal addresses and points of contact whenever organizational details change to satisfy LACNIC obligations. This maintenance prevents communication blackouts during critical routing incidents or legal disputes regarding resource ownership. Neglecting this duty risks the validity of the assignment itself.

1. Verify that owner−c, routing−c, and abuse−c roles reflect current personnel with active email addresses.
2. Confirm that the origin ASN displayed in WHOIS responses matches the value set in your ROA within the RPKI repository.
3. Trigger an update if the queried prefix fails to show an origin, as LACNIC explicitly states this absence in responses when data is missing.

The technical mechanism relies on synchronizing local registry data with the global RPKI framework to validate path origins. A common limitation involves the delay between RPKI updates and WHOIS reflection, potentially causing temporary validation failures for downstream peers. Operators must treat contact freshness as a routing policy requirement, not merely administrative hygiene.

Required Legal Documentation for Merger-Based ASN Registration

Mergers trigger mandatory submission of specific legal instruments to validate any ASN transfer request. Examples include a copy of the legal document validating the transfer of assets and a detailed inventory of all assets used by the applicant. Operators must also provide a thorough list of clients currently using the resources in question. This evidentiary burden ensures that resource fragmentation does not occur during corporate restructuring events. The registry evaluates these documents at its sole discretion to confirm the legitimacy of the business reorganization.

The operational cost involves significant administrative overhead, as compiling accurate client lists and asset inventories often requires cross-departmental coordination that delays registration. A critical tension exists between the speed of corporate closing and the slower pace of regulatory validation; until LACNIC approves the submission, the ASN remains legally tied to the predecessor entity, creating a window of potential routing policy ambiguity. Failure to justify the continued need for all resources forces the return of surplus holdings or their transfer to third parties under strict policies. This mechanism prevents hoarding by ensuring that only actively managed networks retain their identifiers post-merger.

Revocation Risks from Unjustified Resource Retention Post-Merger

Continuing entities face immediate ASN revocation if they fail to justify technical necessity for all held resources. LACNIC policy mandates the return of surplus assets when operational need cannot be proven during restructuring. Operators must submit a list of clients using the resources to validate retention claims. Without this evidence, the registry invalidates the transfer request entirely.

• Loss of legacy 16-bit identifiers due to inability to prove active routing policies.
• Forced reclamation of address blocks declared surplus during asset inventory reviews.
• Administrative delays while legal documentation undergoes discretionary evaluation.

The core tension lies between corporate desire to hoard speculative assets and regulatory requirements for efficient utilization. Unlike permanent ownership models, this framework treats unverified holdings as temporary privileges subject to audit. Data granularity maintained by regional registries allows precise tracking of individual assignments against declared routing policy requirements. Failure to align actual usage with submitted inventories triggers compliance reviews. InterLIR advises operators to audit merged portfolios before filing transfer applications.

References

• LACNIC ASN Allocations: Number of ASNs allocated by LACNIC
• How to Get Your Own ASN and IPv6 Space
• At the West Africa Peering Forum, in Cotonou, Benin