Como Obter uma Alocação de IPv6 /48 da RIPE NCC: Guia Completo

In contemporary network architecture, relying on upstream Internet Service Providers (ISPs) for dynamically assigned or non-portable IPv6 space creates vendor lock-in, complicates disaster recovery, and hinders carrier-neutral multi-homing.

An IPv6 /48 is widely recognized across global transit networks and Internet Exchange Points (IXPs) as the minimum allocation boundary for public BGP routing. While IPv6 addressing boundaries extend down to /64 (the standard single-subnet allocation under SLAAC), Tier-1 carriers and autonomous systems universally filter prefixes longer than /48 (such as /56 ou /64) to protect global routing tables from unbounded bloat.

By securing an independent IPv6 allocation directly through the RIPE NCC (Réseaux IP Européens Network Coordination Centre), an organization obtains:

1. Provider Independence (PI): Freedom to change transit carriers or upstream vendors without renumbering internal networks, infrastructure, or edge services.
2. True BGP Multi-homing: The ability to advertise your route to two or more transit providers simultaneously, optimizing latency and failover.
3. Decentralized Security & Trust: Direct administrative control over cryptographic origin validation (RPKI ROA) and reverse DNS (ip6.arpa) delegation.

Understanding RIPE NCC Policy: Allocations vs. Assignments

Before submitting requests, it is essential to understand the distinction in terminology defined by the RIPE NCC IPv6 Address Allocation and Assignment Policy:

• Allocations (PA – Provider Aggregatable): Blocks intended to be subdivided and distributed further to downstream customers or internal business units. These are typically issued to Local Internet Registries (LIRs), starting at /29 ou /32.
• Assignments (PI – Provider Independent): Blocks assigned directly to an End User organization for its own dedicated operational infrastructure. These prefixes cannot be further sub-allocated to third parties.

For an organization, homelab, or enterprise seeking a standalone /48, you will primarily seek a Provider Independent (PI) assignment, registered under an inet6num object with a status of ASSIGNED PI (or ALLOCATED-BY-LIR depending on contract structure).

Choosing Your Path: Direct LIR Membership vs. Sponsoring LIR

RIPE NCC allows two mechanisms for end users to secure resources:

Recommendation: Unless your organization anticipates becoming a commercial internet registry or requires massive /29–/32 aggregations, contracting a Sponsoring LIR is the standard, most economical approach to secure a /48.

Mandatory Prerequisites

To qualify for an IPv6 assignment under RIPE NCC criteria, the requesting entity must fulfill three primary requirements:

A. Demonstration of Multi-Homing Intent

RIPE NCC policies require that an End User requesting an independent prefix must demonstrate an intent to multi-home the prefix. This is evidenced by:

• Operating or acquiring an Autonomous System Number (ASN).
• Providing active or planned peering/transit arrangements with at least two distinct autonomous systems.

B. Legal Presence within the RIPE NCC Service Region

The applicant (the End User organization) must be legally established within the RIPE service territory (encompassing Europe, the Middle East, and parts of Central Asia). If contracting via a Sponsoring LIR, the sponsoring agreement requires:

• Official corporate registry documentation (e.g., Certificate of Incorporation, KVK, Handelsregister, Companies House excerpt).
• Proof of operational or infrastructure presence if applying from an international parent entity.

C. Technical Addressing Plan

You must be prepared to articulate a basic addressing scheme demonstrating that the /48 will be utilized across network segments (e.g., edge routers, DMZ, internal services, VPN gateways, site-to-site tunnels) within 12 months.

Step-by-Step Acquisition Lifecycle

1.Step 1: Create a RIPE NCC Access Account & Maintainer Objects：Establish identity in the RIPE Whois Database。

Begin by creating an administrative profile on the RIPE NCC Access Portal. Once authenticated, construct your base Whois database objects:

• pessoa ou função object: Defines the administrative and technical contacts (including email and postal address).
• mntner (Maintainer) object: Secures your objects with authentication (SSO, PGP key, or password hash). Every subsequent object (inet6num, route6, domain) will reference this maintainer.
• organização object: Represents the legal entity holding the IP resource.

2.Step 2: Engage a Sponsoring LIR & Execute the Agreement：Formally delegate the application to an active registry。

Select an established Sponsoring LIR. You will be required to execute the standardized RIPE End User Assignment Agreement.

This contract legally binds your organization to RIPE policies and confirms that if the sponsorship agreement terminates without transfer to a new sponsor, the resources revert to RIPE NCC.

3.Step 3: Formal Application & Subnet Plan Submission：Submit technical justification via the LIR portal。

Your Sponsoring LIR submits the resource request through the RIPE LIR Portal. Key parameters submitted include:

• Target Prefix Length: /48
• Holder Org ID & Maintainer handles (mnt-by, mnt-routes, mnt-domains)
• Upstream multi-homing details: Target Origin ASN and names of at least two transit providers or IXP peers.
• Deployment schedule: High-level subnet assignment plan (e.g., 10 to 50 /64 subnets deployed across multiple locations).

4.Step 4: Ticket Review & Prefix Generation：RIPE Hostmasters validate and assign the prefix。

RIPE Hostmasters evaluate the request against current policy guidelines (typically within 1 to 3 business days). Upon approval:

• RIPE assigns an unallocated block from their reserved pool (e.g., 2a0f:...::/48 ou 2a10:...::/48).
• The corresponding inet6num object is created in the global RIPE Whois database with your maintainer and organization handles attached.

5.Step 5: RPKI Validation, Routing Objects, and DNS Delegation：Secure routing integrity before advertising。

Log in to the RIPE LIR or Access dashboard to establish:

• RPKI ROA (Route Origin Authorization): Cryptographically bind the assigned /48 to your originating ASN with MaxLength /48.
• route6 Object: Create the routing registry object in the RIPE IRR (Internet Routing Registry) to ensure automated upstream prefix-filters permit your announcements.
• Reverse DNS Delegation: Point the corresponding ip6.arpa domain object to your authoritative nameservers.

Post-Allocation Technical Configurations

Once the prefix is visible in the Whois database, perform the following operational tasks to make the block usable across the internet.

Creating the IRR route6 Object

Transit providers generate prefix filters using tools like bgpq4 by querying IRR databases (RIPE, RADB, NTT). Without an accurate route6 object, your BGP sessions will be rejected or filtered out.

route6:         2a0f:xxxx:xxxx::/48
descr:          Production Anycast & Core Routing
origin:         AS65530
mnt-by:         YOUR-MNT
source:         RIPE

Implementing RPKI ROA

RPKI (Resource Public Key Infrastructure) prevents BGP route hijacks and misconfigurations.

• In the RIPE NCC Access Dashboard -> RPKI Dashboard:
  • Set Origin ASN: Your operational ASN (e.g., AS65530).
  • Set Prefix: 2a0f:xxxx:xxxx::/48.
  • Set Max Length: 48 (Crucial: Avoid setting Max Length to /64 unless specifically required, as lax max-length configurations open attack surfaces for sub-prefix hijacks).

Establishing Upstream BGP Peering

Announce your aggregate prefix to your BGP upstream neighbors using dynamic routing engines (e.g., BIRD2, FRRouting, Junos, or Cisco IOS-XR).

Example: BIRD 2 Configuration Snippet

Example: BIRD 2 Configuration Snippet

protocol static {
    ipv6;
    # Route the entire /48 to blackhole locally to prevent loops
    rota 2a0f:xxxx:xxxx::/48 blackhole;
}

filter export_to_transit {
    # Announce only the exact /48 allocation
    if (net = 2a0f:xxxx:xxxx::/48) then {
        accept;
    }
    reject;
}

protocol bgp upstream_transit_a {
    local as 65530;
    neighbor 2001:db8:100::1 as 64496;
    ipv6 {
        import all;
        export filter export_to_transit;
    };
}

Addressing & Subnetting Architecture for a /48

An IPv6 /48 prefix provides a 16-bit subnet field, granting exactly 65,536 distinct /64 subnets. Because standard IPv6 end-user segments, VLANs, and VPN pools should always use a /64 to maintain compatibility with RFC specs, neighbor discovery, and hardware offloading, a /48 provides enormous headroom for structured hierarchical design:

  Global Prefix (48 bits)         Subnet ID (16 bits)     Interface ID (64 bits)
[ 2a0f : xxxx : xxxx ] : [     Site / VLAN / Pod     ] : [ Host / EUI-64 / SLAAC ]

• 0000–00FF (First 256 subnets): Core infrastructure, point-to-point router links, and loopbacks.
• 0100–0FFF: Internal corporate LANs, administrative segments, server VLANs.
• 1000–7FFF: Public-facing production clusters, ingress controllers, anycast services.
• 8000–FFFF: Remote site tunnels, branch locations, and dynamic wireguard/IPsec overlays.

Common Pitfalls & Compliance Reminders

1. Failure to Maintain Sponsor Relations: If your Sponsoring LIR ceases operations or you fail to pay the annual maintenance fee, RIPE NCC initiates an un-sponsorship grace period. You must transfer the assignment to a new sponsor within the specified timeframe (typically 30–60 days), or the assignment will be revoked and returned to the free pool.
2. Advertising Lengths Longer Than /48: Attempting to de-aggregate your /48 into two /49s or four /50s for traffic engineering across the global Internet will fail; almost all Tier-1 and Tier-2 transit carriers actively filter IPv6 announcements smaller than /48.
3. Overlooking Reverse DNS Delegations: Omitting the PTR record setup in ip6.arpa can cause outbound mail delivery failures, authentication rejections, and connectivity timeouts from enterprise security tools enforcing forward-confirmed reverse DNS (FCrDNS).