Preparing the registry side of BYOIP: ROA, route objects and validation records

The cloud console is the easy part of BYOIP. Whether a request goes through is decided earlier, in the registry: by the database objects, the ROA and the validation record the provider checks. This article walks through what needs to be in place before you submit a prefix to a cloud provider, and in what order.

Step 1: check the registration itself

Start by looking at how the prefix appears in the RIR database. For RIPE NCC space, that means the inetnum object and the organisation object it links to.

• The organisation should match the entity that owns the cloud account, or you need written authorisation from the holder.
• Contact details, the abuse contact and maintainers should be current, as providers may review them.
• The block should be within the size range your provider accepts. For every major provider, that range includes a /24.
• Nobody else should be announcing the prefix. Check a looking glass or routing history tool, and make sure any old announcement is withdrawn or scheduled for withdrawal.

Who can change these objects matters for every step that follows. If the prefix is assigned from an LIR’s allocation, or you lease it, the LIR controls most of the records, so involve them from the start.

Step 2: create the ROA

A Route Origin Authorisation (ROA) is a signed RPKI object stating which ASN may originate a prefix, and up to which prefix length. Cloud providers check for it before announcing your block, and networks that perform route origin validation drop announcements that conflict with it.

For RIPE NCC resources, ROAs are created in the hosted RPKI system by whoever controls the resource certificate, usually the LIR. Each provider needs its own ASN authorised:

• AWS: Amazon’s ASNs, as listed in its BYOIP documentation.
• Azure: AS8075.
• OVHcloud: AS16276.
• Google Cloud: the origin stated in its BYOIP instructions.

Set the max length deliberately. If the provider will announce exactly a /24, a ROA for that /24 with a max length of /24 is tight and unambiguous. A loose max length on a large block authorises more-specific announcements you never intended.

During a migration, keep the ROA for the current origin until traffic has moved. Removing it early can make the live route invalid and cut off users whose networks enforce RPKI.

Step 3: add route objects

A route object in an Internet Routing Registry describes the same relationship as the ROA: this prefix, this origin ASN. Some transit networks still build prefix filters from IRR data rather than RPKI, so a missing route object can mean an announcement is filtered even when the ROA is correct.

In the RIPE Database, create a route object for each prefix and origin pair you expect to appear in the global routing table. Check the current RIPE Database documentation for the authorisation each object requires before you start.

Keep them tidy over time. When a provider no longer announces a prefix, delete its route object rather than leaving it in place to confuse filters or be misused.

Step 4: publish the provider’s validation record

Beyond the ROA, each provider wants proof that the request comes from the prefix holder. The forms differ:

• AWS accepts a self-signed X.509 certificate placed in the registry record and read via RDAP, or a DNS TXT record when you use VPC IPAM.
• Azure needs a signed message in the registry record, which it checks in the validation stage before provisioning and commissioning.
• Google Cloud validates through the ROA and reverse DNS.

Record exactly what was added, where and why. Ask the provider whether the record must stay in place after provisioning, and don’t remove it until you have the answer.

Some providers and upstreams also ask for a letter of authorisation (LOA) signed by the holder. Keep a template ready, with the prefix, the authorised ASN and a named contact, so it doesn’t hold up the request.

Step 5: sort out reverse DNS

Reverse DNS for IPv4 lives in the in-addr.arpa tree, delegated through domain objects in the RIR database. Decide who will run the zone once the addresses are in the cloud: you, your LIR or the provider.

This matters for two reasons. Google Cloud uses reverse DNS as part of its validation, and services such as mail need correct PTR records whatever provider they run on.

Delegations that still point to retired name servers fail quietly. Before submitting the BYOIP request, confirm that every delegated server answers authoritatively for the zone, and that the records you need are already there.

A short final check before you submit:

1. The inetnum and organisation data are correct and current.
2. A ROA exists for the provider’s ASN with the right max length.
3. A matching route object exists.
4. The provider’s validation record is published and visible.
5. Reverse DNS is delegated to servers that answer.

How TACS can help

TACS is a RIPE NCC member and prepares the full registry side for BYOIP: ROAs, route objects, validation records, LOAs and reverse DNS. If you need a sponsoring LIR for PI space or help running your own LIR, see our LIR services.