Shikanoko Networks (SKNK)
Back to blog

SKNK Technical Guide

How to Announce an IPv6 /48 via BGP in 2026: ROA, IRR, and Upstream Checklist

Updated for 2026: learn how to announce an IPv6 /48 via BGP with an ASN, matching RPKI and IRR records, upstream filters, and public visibility checks.

Technical content

Written and maintained by Shikanoko Networks

An IPv6 /48 is not globally reachable simply because it has been allocated or assigned for an organisation's use. To announce it through BGP, you need an ASN, a prefix you are authorised to use, an IPv6-capable upstream, a router with an active route to the prefix, and matching routing records. You also need to verify what other networks can actually see.

This guide explains the complete IPv6 /48 BGP announcement workflow: confirm the resource, prepare the upstream, create the RPKI and IRR records, establish eBGP, export the prefix, and check the result from more than one point of view.

The examples use the IPv6 documentation prefix 2001:db8:1234::/48 and the documentation ASNs AS64496 and AS64497. They are not real resources and must never be announced on the public Internet.

White-Face Xiaolu carries an IPv6 prefix from a resource desk toward a public routing gate, with two possible paths ahead.

An assigned prefix becomes a public route only after the resource, authorisation, BGP policy, and upstream path all agree.

The Short Answer

To announce an IPv6 /48 via BGP:

  1. Confirm that the ASN and IPv6 prefix are assigned to you or authorised for your use.
  2. Confirm that an upstream accepts customer IPv6 BGP announcements.
  3. Create a matching RPKI ROA for the prefix and the ASN that will originate the public route.
  4. Create an IRR route6 object if your upstream or peers use IRR filtering.
  5. Make sure the /48 exists in the router's local routing table.
  6. Establish the eBGP session and export only the intended prefix.
  7. Check the local route, upstream acceptance, RPKI state, IRR object, and public visibility.

A BGP session being Established does not automatically mean that your /48 is being advertised. A route can also be advertised by your router and then rejected by an upstream filter. These are separate checks.

What Does “Announce an IPv6 /48” Mean?

There are several different milestones in an IPv6 deployment:

State What it means
The /48 is assigned or allocated An address resource exists for the stated use
The /48 is in the local RIB Your router has an active route to the prefix
The BGP session is Established Your router and upstream can exchange BGP messages
The prefix is exported Your router has sent the route to the upstream
The upstream accepts it The upstream has passed its own filters and installed the route
The route is publicly visible Other networks or route collectors can see an announcement
The route is RPKI Valid The route matches a published origin authorisation

These states do not automatically produce one another. A prefix can be assigned without being routed, a BGP session can be Established without an exported prefix, and an RPKI-valid route can still have limited visibility if an upstream or peer filters it.

What You Need Before You Start

Requirement Why it matters What to confirm
An ASN Identifies the network originating the route Which ASN will appear as the public origin
An IPv6 prefix Defines the address space being announced Prefix length, resource holder, and permitted use
An IPv6-capable upstream Provides a path to other networks BGP support, filtering policy, and operational contact
A BGP-capable router Establishes the session and sends updates IPv6 reachability and export policy support
RPKI authority Authorises the origin ASN and prefix length Who can create or change the ROA
IRR authorisation Allows a route object to be registered where required Who can create or maintain the route6 object
Verification tools Shows what is visible outside your router Local BGP state, RPKI, IRR, and public collectors

The key is to identify the resource holder and the actual origin ASN before you configure anything. The same prefix, origin ASN, and prefix length must be represented consistently in the resource records, ROA, IRR object, BGP policy, and upstream request.

RIPE NCC ASN Policy 2026: Current Rule vs Open Proposal

Policy status reviewed: 2 August 2026.

The current published RIPE-679 ASN assignment policy says that a network must be multi-homed in order to qualify for an ASN. It also requires the request to describe the new external routing policy of the Autonomous System.

On 7 July 2026, the RIPE community published the 2026-01 “Simplify assignment of first ASN” proposal. The proposal would remove the needs justification for a first ASN in certain cases involving a holder of a prefix assigned or allocated directly by the RIPE NCC, but the page currently lists it as being in the discussion phase. It is not the current policy.

If you are applying for an ASN now, follow the current policy and the requirements communicated by the RIPE NCC or your Sponsoring LIR. Do not use an open policy proposal as if it were already in force.

Step 1: Confirm the Prefix and Origin ASN

Write down the exact relationship between the prefix and the ASN that will originate it:

Prefix:      2001:db8:1234::/48
Origin ASN:  AS64496

The following values should describe the same intended public route:

  • The IPv6 prefix assigned or authorised for your use
  • The ASN configured as the BGP origin
  • The Origin ASN in the ROA
  • The origin: value in the IRR route6 object
  • The prefix allowed by the upstream's filter

If these values disagree, the result depends on the layer involved. An upstream may reject a route because of its IRR or manual filter. A route may become RPKI Invalid because its origin ASN or prefix length does not match a covering ROA.

If you are still deciding how to obtain the resources, read How to Get Your Own ASN and How to Get an IPv6 /48.

PA and PI Are Not the Same

Provider Aggregatable (PA) and Provider Independent (PI) resources have different registration and operational relationships.

PA space is part of an LIR's allocation and its use, portability, RPKI workflow, and lifecycle depend on the resource holder and the applicable agreement. PA should not be described as portable by default.

PI space is assigned to the end-user organisation and is requested through a Sponsoring LIR in the RIPE NCC service region. RIPE NCC documentation describes /48 as the minimum IPv6 PI assignment size. See How to Request an IPv6 PI Assignment for the current request path.

For SKNK's IPv6 PA /48 service, the prefix comes from SKNK's PA allocation. SKNK controls and maintains the RPKI ROA for that resource. The customer chooses an upstream and operates the BGP configuration; the Sponsoring LIR service does not include BGP configuration, transit, IRR administration, DNS management, or 24/7 routing operations. See the resource lifecycle information for the service boundary.

Step 2: Confirm That an Upstream Accepts the Route

You need an upstream that can establish an IPv6 eBGP session and is willing to accept your prefix.

Ask the upstream to confirm the following parameters:

Parameter Example
Your ASN AS64496
Upstream ASN AS64497
Your BGP neighbour address 2001:db8:ffff::2
Upstream neighbour address 2001:db8:ffff::1
Prefix to announce 2001:db8:1234::/48
Authentication Whether TCP MD5 or another method is required
Prefix limit The maximum number of routes allowed on the session
IRR requirement Whether a route6 object is required
RPKI requirement Whether the route must be Valid or merely not Invalid
Operational contact The NOC or routing contact for the service

Also confirm:

  • Whether IPv6 is enabled on the service or tunnel
  • Whether the session uses directly connected addresses or multihop
  • Whether the provider requires an LOA or another authorisation document
  • Which BGP communities are available, if any
  • Which IPv6 prefix lengths the provider accepts

Transit, peering, IXP and tunnel connections are not interchangeable. Transit vs Peering explains the different roles before you select an upstream arrangement.

White-Face Xiaolu connects a local routing machine to two independent upstream bridges, keeping the paths separate and visible.

The BGP session is the transport between your router and an upstream; it does not by itself announce every route.

Step 3: Create a Matching ROA

A Route Origin Authorization (ROA) is a signed RPKI object that states which ASN is authorised to originate a prefix and how specific the permitted announcement may be. RIPE NCC's BGP Origin Validation documentation describes the relationship between ROAs and route validation.

For a design that announces only the aggregate /48, an illustrative ROA is:

Prefix:       2001:db8:1234::/48
Origin ASN:   AS64496
maxLength:    /48

If the only public route you intend to announce is the /48, keeping maxLength at /48 is the narrowest matching authorisation. Do not set a broader value merely because more-specific routes might be useful later. A broader maxLength authorises more-specific announcements as well.

If you later need to announce a /52 or /56, confirm the routing design with the resource holder and every relevant upstream first. Update the ROA and the IRR object to match the actual announcement before changing the BGP policy.

The RPKI validation states are defined in RFC 6811:

State Meaning
Valid A covering ROA authorises the Origin ASN and prefix length
Invalid A covering ROA exists, but the ASN or prefix length does not match
NotFound No covering ROA is visible to the validator

The Origin ASN in the ROA must be the ASN that appears as the origin of the public BGP route. If an upstream originates the prefix with its own ASN, authorising only the customer's ASN will not match that route.

A ROA does not create a BGP session, add a route to your router, or force an upstream to accept the prefix. It provides origin-authorisation data for networks that perform RPKI validation.

For a separate explanation of ROAs and maxLength, read What Is a ROA?.

Step 4: Create an IRR route6 Object

IRR and RPKI describe different forms of routing information:

  • A ROA is a cryptographically signed origin authorisation.
  • A route6 object records IPv6 routing intent in an Internet Routing Registry.
  • An upstream may use IRR data to generate or update prefix filters.
  • An upstream may also use RPKI data to validate the origin of the route.

A simplified route6 object might look like this:

route6:      2001:db8:1234::/48
descr:       Example IPv6 aggregate
origin:      AS64496
mnt-by:      YOUR-MAINTAINER

This is an illustrative template, not a copy-and-paste object. The correct maintainer and authorisation path depend on the database source and the resource holder.

RIPE Database documentation describes route6 as an IPv6 route advertised on the Internet and documents the attributes and authorisation rules for route objects. See the RIPE Database route6 documentation.

The records should describe the same intended route:

route6 prefix  = BGP prefix
route6 origin  = BGP Origin ASN
ROA prefix     = BGP prefix
ROA origin     = BGP Origin ASN

A correct ROA does not replace an IRR object when an upstream uses IRR-based filtering. A correct IRR object does not provide the cryptographic origin validation supplied by RPKI.

White-Face Xiaolu places two separate route records onto one matching path, keeping the authorisation record and routing-intent record distinct.

ROA and IRR describe different properties of the same intended announcement.

Step 5: Put the /48 in the Local Routing Table

BGP generally exports routes that exist in the router's local routing table. A prefix being registered in an IRR or authorised by RPKI does not automatically create a usable route on the router.

Before establishing the session, confirm that the /48 exists in the local RIB and is active. The route may be connected to:

  • A loopback or service interface
  • A routed server network
  • An aggregate covering internal subnets
  • A static route to an internal router
  • A deliberate aggregate design with a discard route and separately routed more-specifics

The last option requires care. A discard route can protect the aggregate's presence in the RIB, but it can also blackhole traffic if the underlying more-specific routes are not available. Use it only as part of a documented routing design.

Do not announce a prefix merely because an object exists in the RIPE Database. The prefix must be authorised for your use and deliberately routed in your network.

Use the IPv6 Subnet Calculator to plan /48, /56, and /64 boundaries, but keep subnet planning separate from BGP origination.

Step 6: Establish eBGP and Export Only the Intended Prefix

Configure the eBGP session with the values agreed with the upstream:

  • Local ASN
  • Remote ASN
  • Local and remote IPv6 neighbour addresses
  • IPv6 address-family activation
  • Required authentication
  • Directly connected or multihop transport settings
  • An export policy limited to the authorised prefix

The export policy should express a narrow rule:

If the route is active
and the prefix is the authorised prefix
then export it to the intended upstream
otherwise reject it

This is a policy description, not router-specific syntax. BIRD, FRRouting, Junos, IOS-XR and other platforms use different configuration formats. Use the documentation for the platform you actually operate.

Do not start with an export policy that sends every route in the local table. A broad policy can leak internal, learned, management, or default routes.

When using more than one upstream, configure and verify each session separately. The same /48 may be announced through more than one upstream, but the resource holder, upstream contracts, ROA design, filtering policy, and traffic-engineering plan must all support that arrangement.

For a wider post-allocation sequence, read What Happens After You Get an ASN?.

Step 7: Verify the Announcement in Four Layers

Check the route in four separate places.

1. Local router

Confirm:

  • The BGP session is Established
  • The IPv6 address family is active
  • The /48 exists in the local RIB
  • The prefix appears in the advertised-routes view
  • The export policy is not rejecting the route

The exact command depends on the router platform. Look for the platform's equivalent of local RIB, BGP session state, and advertised routes.

2. Upstream

Ask the upstream to confirm:

  • The session is Established on both sides
  • The prefix was received
  • The prefix passed the provider's filters
  • The prefix is being propagated according to the service policy

A route can appear in the local advertised-routes view and still be rejected immediately by the upstream.

3. RPKI and IRR

Use the SKNK tools for read-only checks:

Confirm that:

  • The prefix is correct
  • The Origin ASN is correct
  • The expected ROA is visible
  • The route is RPKI Valid when the intended route is covered by a matching ROA
  • The route6 object matches the prefix and origin
  • No stale ROA authorises a different origin
  • maxLength covers the exact route being announced

4. Public visibility

Use more than one public routing data source, such as RIPEstat, public looking glasses, and route collectors.

Different collectors may update at different times and may see different paths. A single positive result is not proof of universal reachability, and a single negative result may reflect collection delay or a policy difference.

The final question is not only “Did my router send the route?” It is:

Can independent networks see the prefix with the expected Origin ASN, and is the route accepted by the policies that matter to the intended users?

White-Face Xiaolu checks the same route through four separate gates, comparing a local route card, an upstream bridge, an authorisation seal, and a distant public path.

A successful local announcement still needs upstream acceptance, matching authorisation, and public visibility checks.

Common Troubleshooting Problems

Symptom Likely area What to check
BGP stays Idle Transport or neighbour configuration IPv6 reachability, TCP/179, firewall, local and remote ASN
BGP stays Active Peer address, multihop, or authentication Peer address, TTL, password, and provider settings
Session is Established but no /48 appears Local route or export policy Local RIB and advertised-routes view
Upstream rejects the prefix Provider filter or missing authorisation Exact prefix, IRR object, LOA, and provider policy
Route is RPKI Invalid Origin ASN or prefix length mismatch Actual public origin, ROA, and maxLength
Route is RPKI NotFound No covering ROA is visible Whether a ROA exists, is published, and has reached validators
Route is visible at one collector only Propagation delay or policy filtering More collectors, upstream confirmation, and prefix length
Route exists but traffic fails Data-plane or return-path issue Next hop, internal routing, firewall, service binding, and return path

Do not change the ROA, IRR object, and BGP configuration at the same time unless you record the previous state. Otherwise, it becomes difficult to identify which change caused or fixed the result.

White-Face Xiaolu carefully untangles a route thread between a small router, a gate, and a public path, while keeping the authorised route separate from a rejected branch.

Troubleshooting is easier when resource records, routing policy, and public observations are checked one layer at a time.

Do You Need Your Own ASN and IPv6 /48?

You may not need your own ASN if:

  • You use one cloud or transit provider
  • The provider originates the route with its own ASN
  • You do not need your own external routing policy
  • You accept the provider's addressing and routing lifecycle

Your own ASN becomes relevant when you need an independent routing identity, multiple external networks, or control over how your own prefix is originated. In the RIPE NCC service region, the current published policy still includes a multihoming requirement; the 2026 first-ASN proposal described earlier has not replaced that policy.

If you are evaluating the application path, read What Is Multihoming? and How to Get Your Own ASN.

If you need ASN and IPv6 resource sponsorship rather than BGP configuration, review the current Sponsoring LIR pricing and resource lifecycle pages. The customer remains responsible for selecting an upstream and operating the network route unless a separate written service says otherwise.

Frequently Asked Questions

Can I announce an IPv6 prefix without an ROA?

BGP can technically carry the route without a ROA. When no covering ROA is visible, the route will normally be classified as RPKI NotFound (also shown as UNKNOWN in some documentation). However, network operators may prefer Valid routes or apply their own policy to NotFound routes, so a matching ROA is recommended for a production announcement.

Does a ROA make my route globally visible?

No. A ROA authorises an Origin ASN and prefix length. It does not create a BGP session, add the prefix to your router, or force an upstream to accept the route.

Do I need both a ROA and a route6 object?

They are different systems. A ROA supports RPKI origin validation. A route6 object records routing intent in an IRR. Many upstreams still use IRR data for filters, while others also use RPKI, so follow the requirements of each upstream.

Can I announce an IPv6 /64?

The BGP protocol can carry an IPv6 /64, but public reachability depends on the filtering policy of each upstream and peer. A /64 is normally a subnet inside a larger IPv6 allocation or assignment, not a reliable global Internet announcement. Confirm the accepted prefix length before designing a service around it.

Can I announce a PA /48 through two upstreams?

Possibly, but it depends on the PA resource holder, the Sponsoring LIR agreement, and each upstream's routing policy. Confirm who controls the ROA and whether the resource is authorised for announcements through both providers.

How long does IPv6 BGP propagation take?

There is no single global propagation time. The session may become Established immediately while route collectors and other networks update later. Check the route from multiple public vantage points instead of relying on a fixed time estimate.

Conclusion

Announcing an IPv6 /48 is not one configuration command. It is the alignment of five layers:

Resource authority
        ↓
ROA and IRR records
        ↓
Local route
        ↓
BGP export policy
        ↓
Upstream acceptance and public visibility

If the prefix, Origin ASN, ROA, route6 object, local route, and BGP export policy all describe the same announcement, troubleshooting becomes much easier.

Before going live, verify the route locally, confirm it with the upstream, check RPKI and IRR, and inspect it from multiple public routing sources.

Continue Reading

Official References