Who administers the prefix?
Option one · IPv6 PA
Identify the provider, LIR, or allocation relationship that administers it.
Option two · IPv6 PI
Identify the registry relationship and the duties attached to the independent resource.
Back to comparisons
SKNK Field Notes · Point by point
IPv6 PA or PI? Start with Lifecycle, Not Prefix Size
PA (Provider Aggregatable) and PI (Provider Independent) differ in who administers the prefix, who holds the authorisation, and what happens when you change providers. Lifecycle is the real topic; price comes later.
Reviewed against public documentation: 2 August 2026
Compare point by point
Every point is concrete work.
What is needed to announce it?
Option one · IPv6 PA
Both the upstream and the resource relationship must allow the announcement.
Option two · IPv6 PI
You still need an upstream that accepts the prefix and your intended BGP policy.
If the provider changes
Option one · IPv6 PA
Ending the relationship may mean renumbering. Ask before you sign.
Option two · IPv6 PI
Before moving providers, check the transfer, registry, and contract process.
Who can maintain ROA and IRR data?
Option one · IPv6 PA
Confirm who may create or change the relevant ROA and route objects.
Option two · IPv6 PI
Confirm the resource holder's authority and the registry workflow that applies.
Where this can be a useful starting point
Put the choice back into your actual network.
PA can fit when you understand and accept the provider relationship and its end-of-service outcome.
Before relying on PI, verify eligibility, registry duties, upstream acceptance, and the upkeep it needs.
Before an application or change
Settle these questions first.
1
What materials and timeline does an application for this prefix involve?
2
How are the fees structured — one-off and annual?
3
What is the written process for changing a sponsor or upstream?
This guide frames the questions; the answers come from the formal pages.
Policies, resource relationships, service boundaries, and upstream filters differ by situation. For price, eligibility, ownership, or service-end questions, use the formal pages and confirm with the responsible party.
SKNK · Sources and scope
Sources and scope for this comparison
Each source supports one kind of conclusion. Source pages, registry records, and routing observations update at different times, so read every result with its source and timestamp.
RIPE Database
Registry and IRR records
Useful for checking
Whether a public object exists for this ASN or prefix, who it is registered to, and who maintains it.
Not enough to prove alone
It cannot tell you whether the route is being announced. An object is not an announcement.
RPKI / ROA
Route-origin authorisation
Useful for checking
Whether the announcer holds an authorisation — prefix, origin ASN, and maximum length matching.
Not enough to prove alone
It does not prove propagation, uptime, or that an application was approved.
SKNK resource lifecycle
Current service terms
Useful for checking
What SKNK publicly states about its PA resource model.
Not enough to prove alone
It does not decide whether another resource or policy path is available.