Agree one routing plan before changing records
For a leased IPv6 /32, the customer and resource provider need the same prefix, origin ASN and announcement plan. Your upstream must also accept the arrangement. Record who is responsible for BGP configuration, authorisations, registry changes and incident handling.
This checklist is for planning. It is not a router configuration: commands and routing policies depend on your equipment, upstream and network design.
1. Confirm the prefix and origin ASN
Check the exact prefix in the service order and the ASN that will originate it. Identify the technical contact for that ASN. Confirm with your upstream which prefix lengths it accepts and which IRR or RPKI checks it applies. Do this before asking the resource provider to publish records.
2. Check the ROA
A Route Origin Authorisation associates address space with an authorised origin ASN. Its maximum length also matters: a more-specific announcement outside the permitted length can be RPKI Invalid even when the ASN matches. Coordinate any change with the party maintaining the ROA.
For a plan that announces only the agreed /32, review an exact /32 authorisation. Do not widen maximum length simply to avoid planning the announcements. If more-specific routes are needed, review the requirements and upstream policy first.
3. Align the route6 object
A RIPE Database route6 object records an IPv6 route and its origin ASN. Confirm that both match the agreed plan. An IRR route6 record and an RPKI ROA serve different purposes; one should not be assumed to replace the other for every upstream.
4. Prepare the LOA and reverse DNS
Ask your upstream whether it requires a Letter of Authorization and what details it expects. The LOA should identify the authorised resource and arrangement. Where reverse DNS is required, agree the authoritative nameservers and delegation with the resource provider. Reverse DNS does not activate BGP routing.
5. Verify before treating the service as live
- Confirm the actual announcement uses the intended prefix and origin ASN.
- Check RPKI validity and that the upstream has accepted the route.
- Inspect visibility from independent network vantage points.
- Test the intended traffic path; a visible route alone does not prove the application works.
- Test reverse-DNS delegation if it forms part of the setup.
Registry publication does not guarantee global route propagation. Keep a record of the agreed state and coordinate later ASN or prefix-length changes before announcing them.
Official references
For the commercial process, see how to lease a RIPE IPv6 /32.
Discuss your IPv6 /32 requirements
Share your company, intended use and proposed origin ASN. Request an IPv6 /32 lease or email sales@elisteka.com. No payment is collected through the application form.