Prefix administration
Option one · IPv6 PA
The provider, LIR, or allocation relationship administers the prefix.
Option two · IPv6 PI
The registry relationship and duties attach to the independent resource.
Back to comparisons
SKNK Field Notes · Point by point
IPv6 PA and PI: Lifecycle and Responsibilities
PA and PI differ in prefix administration, route-origin authority, and the work triggered by a provider change. Those lifecycle facts shape the choice alongside price.
Reviewed against public documentation: 2 August 2026
Compare point by point
Every point is concrete work.
Announcement conditions
Option one · IPv6 PA
The upstream and the resource relationship both need to permit the announcement.
Option two · IPv6 PI
An upstream needs to accept the prefix and the intended BGP policy.
Provider changes
Option one · IPv6 PA
The end of the relationship can require renumbering.
Option two · IPv6 PI
Transfer, registry, and contract procedures govern a provider move.
ROA and IRR maintenance
Option one · IPv6 PA
The relevant ROA and route objects have a defined creation and change authority.
Option two · IPv6 PI
The resource holder's authority and the applicable registry workflow govern maintenance.
Where this model fits
The actual network determines the fit.
PA fits a plan that accepts the provider relationship and its service-end outcome.
PI brings eligibility, registry duties, upstream acceptance, and continuing upkeep into the resource plan.
Confirmation items before an application or change
These three facts shape the next steps.
1
Application materials and review timeline
2
One-off and recurring fee structure
3
Written process for changing a sponsor or upstream
This guide organises the decision points; formal pages and agreements provide the binding details.
Policies, resource relationships, service boundaries, and upstream filters vary by situation. Formal pages and the responsible party confirm price, eligibility, ownership, and service-end arrangements.
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.
Needs a separate check
Live BGP observations show the current announcement state.
RPKI / ROA
Route-origin authorisation
Useful for checking
Whether the announcer holds an authorisation — prefix, origin ASN, and maximum length matching.
Needs a separate check
Propagation, service availability, and application approval each use separate evidence.
SKNK resource lifecycle
Current service terms
Useful for checking
What SKNK publicly states about its PA resource model.
Needs a separate check
Other resource and policy paths have their own eligibility and availability conditions.