DEV Community

Cover image for Whose ASN Goes on Your Leased IPv4 Prefix?
Artem Kohanevich
Artem Kohanevich

Posted on

Whose ASN Goes on Your Leased IPv4 Prefix?

#networking #bgp #devops #aws

You leased a /24. Something has to originate it in BGP. That something has an ASN attached, and if the wrong ASN is attached, your prefix gets dropped by every network running Route Origin Validation.

That is the entire problem. Here is how the four options differ at the object level.

The four origination paths

Path Origin AS Who creates what
Your own ASN + BGP Yours Owner issues LOA + route: + ROA, all naming your ASN
Upstream/host announces Provider's Same three objects, naming their ASN
Cloud BYOIP Cloud's, or yours on AWS ROA naming cloud ASN (or yours via BYOASN) + RDAP proof
Third-party AS Partner's Same three objects, naming the partner's ASN

Three of the four need no ASN registered to you.

The rule

ROA.asID must equal the origin AS in the announcement. RFC 6811 gives three outcomes:

  • NotFound - no covering ROA. Still widely accepted, decreasingly so.
  • Valid - origin AS and prefix length both match.
  • Invalid - wrong origin AS, or announced prefix longer than maxLength. Dropped by every validating peer.

Invalid is the dangerous one because it fails partially. Peers doing ROV drop you, peers that do not still carry you, and the symptom looks like an application bug.

The failure I see most

Renter plans to get their own ASN later. Asks the IP owner to create the ROA against that future ASN now. Goes live with the host announcing from the host's AS.

ROA:          198.51.100.0/24  origin AS64496  maxLength 24
Announcement: 198.51.100.0/24  AS_PATH ... 64511
                                            ^^^^^ mismatch -> Invalid
Enter fullscreen mode Exit fullscreen mode

Sequence it the other way. Decide the origin, then create the ROA.

Also watch maxLength 

ROA:          203.0.113.0/22   origin AS64496  maxLength 22
Announcement: 203.0.113.0/24   origin AS64496
                        ^^^ correct AS, too specific -> Invalid
Enter fullscreen mode Exit fullscreen mode

Correct ASN is not sufficient. maxLength has to cover what you actually originate.

Verifying before you announce

RIPEstat works regardless of which RIR administers the block:

curl -s "https://stat.ripe.net/data/rpki-validation/data.json?resource=64496&prefix=198.51.100.0/24" \
  | jq '.data.status, .data.validating_roas'
Enter fullscreen mode Exit fullscreen mode

Anything other than "valid" means stop. For a local relying-party cache, use Routinator, rpki-client or FORT.

Note: the RIPE NCC RPKI Validator has been unmaintained since 1 July 2021 and the public instance was migrated to Routinator in September 2021. Plenty of tutorials still point at it.

Then confirm what the world actually sees:

whois -h whois.radb.net -- '-i origin AS64496'   # route objects
# plus RIPE RIS / BGPView / HE looking glass for the live AS_PATH
Enter fullscreen mode Exit fullscreen mode

Cloud specifics

AWS commercial regions. ROA must authorise 16509 and 14618, maxLength 24 for IPv4. GovCloud (US) uses 8987. Authorisation is two-part: the ROA plus a self-signed X.509 certificate published in the RDAP remarks for the prefix.

AWS BYOASN. You are not forced onto Amazon's origin AS. Bring an ASN you hold:

aws ec2 provision-ipam-byoasn --ipam-id ipam-xxxx --asn 64496 --asn-authorization-context ...
aws ec2 associate-ipam-byoasn --asn 64496 --cidr 198.51.100.0/24
aws ec2 advertise-byoip-cidr --cidr 198.51.100.0/24 --asn 64496
Enter fullscreen mode Exit fullscreen mode

The ROA then names your ASN, not Amazon's.

Azure Custom IP Prefix. Origin AS must be 8075 (public) or 8070 (US Gov). Parent IPv4 prefix must be /21 to /24. Two constraints that kill use cases outright: SMTP is not permitted from Azure BYOIP space, and you must decommission the range before modifying or deleting the ROA - otherwise Microsoft keeps advertising a prefix it is no longer authorised to originate.

Do you actually want your own ASN?

RIPE still requires multihoming. ripe-679 §2.0 is unambiguous, and proposal 2025-01 - which would have dropped all justification for a first ASN - was withdrawn on 6 July 2026. The old criteria stand.

You submit a routing policy in RPSL:

aut-num:  AS64496
import:   from AS64500 accept ANY
import:   from AS64501 accept ANY
export:   to AS64500 announce AS64496
export:   to AS64501 announce AS64496
Enter fullscreen mode Exit fullscreen mode

Two upstreams in that object is not decoration. RIPE NCC may contact both to verify.

Single-homed with one /24? An ASN gets you EUR 50 per assignment, registry obligations, and a routing policy identical to your upstream's. Skip it until you are genuinely multihoming.

Pre-flight

  • [ ] LOA names the announcing ASN
  • [ ] route: object exists with correct origin:
  • [ ] ROA correct on both asID and maxLength
  • [ ] RPKI status valid
  • [ ] Prefix visible from multiple vantage points, observed origin matches the ROA
  • [ ] rDNS delegated
  • [ ] Reputation checked on the block and the announcing ASN

Longer version with the full path-by-path breakdown, the RIPE policy history, and the LOA/IRR/ROA sequencing: https://ipbnb.com/blog/asn-to-announce-ipv4

Top comments (0)