diff --git a/src/content/changelog/byoip/2026-10-20-bring-your-own-asn.mdx b/src/content/changelog/byoip/2026-10-20-bring-your-own-asn.mdx new file mode 100644 index 00000000000..3130a7ad550 --- /dev/null +++ b/src/content/changelog/byoip/2026-10-20-bring-your-own-asn.mdx @@ -0,0 +1,15 @@ +--- +title: Bring your own ASN with BYOIP +description: Onboard BYOIP prefixes with your own autonomous system number, with ASN ownership verification and ASPA validation. +products: + - byoip +date: 2026-10-20 +--- + +[Bring Your Own IP (BYOIP)](/byoip/) now supports self-service onboarding with your own autonomous system number (ASN). You can use your ASN as the origin for your prefixes instead of Cloudflare's AS13335, retaining your routing identity while using Cloudflare's services. + +To get started, select your ASN when adding a prefix and verify ownership by publishing your validation token in the ASN's `aut-num` record. ASN verification is reused for additional prefixes in the same Cloudflare account. Self-service ASN verification supports AFRINIC, APNIC, ARIN, and RIPE. For a LACNIC-registered ASN, contact your account team. + +BYOIP also validates Autonomous System Provider Authorization (ASPA) data for your ASN. Publishing an ASPA is optional. If you publish one, its provider list must include AS13335. You can keep other authorized providers. + +Follow the [BYOIP onboarding guide](/byoip/get-started/) to configure your prefix and verify ownership. For help interpreting validation results, refer to [Troubleshoot prefix validation](/byoip/troubleshooting/prefix-validation/). diff --git a/src/content/docs/byoip/concepts/route-filtering-rpki.mdx b/src/content/docs/byoip/concepts/route-filtering-rpki.mdx index d697d28e5d3..f80f09001fd 100644 --- a/src/content/docs/byoip/concepts/route-filtering-rpki.mdx +++ b/src/content/docs/byoip/concepts/route-filtering-rpki.mdx @@ -16,4 +16,12 @@ However, IRR records alone are not cryptographically verified, which means they When you register your prefix with one of the five Regional Internet Registries (RIRs)[^1], you can create a Route Origin Authorization (ROA) — a cryptographically signed object that declares which ASN is authorized to originate your prefix. ROAs are publicly verifiable, and you can check your prefixes using [Cloudflare's RPKI Portal](https://rpki.cloudflare.com/?view=validator) or other sources such as [Routinator](https://rpki-validator.ripe.net/ui/). +## ASPA authorization + +An [Autonomous System Provider Authorization (ASPA)](https://datatracker.ietf.org/doc/draft-ietf-sidrops-aspa-verification/) is another RPKI object. It declares which ASNs can act as upstream providers for an ASN. + +When you use your own ASN, Cloudflare checks ASPA data during onboarding and revalidation. Publishing an ASPA is optional. If you publish one for your ASN, include AS13335 in its provider list. Other authorized providers can remain. + +Refer to [Prefix validation checks](/byoip/troubleshooting/prefix-validation/) for response states and troubleshooting. + [^1]: AFRINIC, APNIC, ARIN, LACNIC, and RIPE. diff --git a/src/content/docs/byoip/get-started.mdx b/src/content/docs/byoip/get-started.mdx index 9e691b81c9d..99246b679ae 100644 --- a/src/content/docs/byoip/get-started.mdx +++ b/src/content/docs/byoip/get-started.mdx @@ -41,10 +41,12 @@ You must meet all of the following requirements. Cloudflare cannot onboard your - Your [Internet Routing Registry (IRR)](/byoip/concepts/irr-entries/) records must contain: - A `route` or `route6` object that exactly matches each prefix you want to onboard. - An `origin` that matches the ASN Cloudflare will use to advertise the prefix. + - An editable `aut-num` object for your ASN, if you use your own ASN. - Your [Route Origin Authorizations (ROAs)](/byoip/concepts/route-filtering-rpki/) must be accurate. You must verify them with [Cloudflare's RPKI Portal](https://rpki.cloudflare.com/?view=validator) and a second source such as [Routinator](https://rpki-validator.ripe.net/ui/). +- If your ASN has a published [Autonomous System Provider Authorization (ASPA)](/byoip/concepts/route-filtering-rpki/), its provider list must include AS13335. You do not need to publish an ASPA to onboard a prefix. - You must have your Cloudflare account ID and an API token with the permissions required by each operation in this guide. If you are unfamiliar with the Cloudflare API, refer to [Cloudflare API fundamentals](/fundamentals/api/). - +Self-service onboarding with your own ASN supports ASNs registered with AFRINIC, APNIC, ARIN, or RIPE. For a LACNIC-registered ASN, contact your account team. This ASN requirement is separate from the supported prefix registries. ## 1. Add and validate your prefix @@ -54,6 +56,8 @@ You must meet all of the following requirements. Cloudflare cannot onboard your 1. Use the [Add Prefix endpoint](/api/resources/addressing/subresources/prefixes/methods/create/) to add the prefix to the Cloudflare account that will own it. + Set `asn` to `13335` to use Cloudflare's ASN. To use your own ASN, enter its number without the `AS` prefix. Your IRR route and ROA must authorize the selected ASN. + ```bash curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/addressing/prefixes" --request POST --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" --json '{"cidr":"203.0.113.0/24","asn":13335,"delegate_loa_creation":true}' ``` @@ -87,6 +91,19 @@ You must meet all of the following requirements. Cloudflare cannot onboard your +When you use your own ASN, the same response's `result` object can also include the following fields: + +```json title="Additional fields in result" +{ + "asn_ownership_validation_state": "pending", + "aspa_validation_state": "pending" +} +``` + +`asn_ownership_validation_state` is omitted when ASN ownership validation does not apply, such as when you use AS13335. Its initial state can be `valid` if the same account previously verified the ASN. + +When `aspa_validation_state` is present, its value is `pending`, `valid`, or `invalid`. If the field is omitted, no ASPA validation result is available. Omission does not indicate successful validation or confirm that no ASPA exists. For more information, refer to [Prefix validation checks](/byoip/troubleshooting/prefix-validation/). + :::note[Letter of Agency] This guide uses automated Letter of Agency (LOA) generation. If you set `delegate_loa_creation` to `false`, you must upload the LOA manually, [update the prefix](/api/resources/addressing/subresources/prefixes/methods/edit/) after it is approved, and contact your account team. Manual LOA processing can increase onboarding time. ::: @@ -146,15 +163,31 @@ Prove ownership by adding the validation token to either your IRR record or reve -After publishing the validation token, use the [Validate Prefix endpoint](/api/resources/addressing/subresources/prefixes/methods/validate/) to trigger the prefix validation checks: +### Validate ASN ownership + +If `asn_ownership_validation_state` is present and is not `valid`, add `cf-validation: ` to an editable field in your ASN's `aut-num` object. Use the same `ownership_validation_token` returned when you added the prefix. Reverse DNS can prove prefix ownership, but it does not replace the `aut-num` check for ASN ownership. + +Cloudflare verifies ASN ownership once per Cloudflare account and ASN. If `asn_ownership_validation_state` is already `valid`, you do not need to update the `aut-num` object. + +### Check ASPA authorization + +If you publish an ASPA for your ASN, use your RIR's RPKI tooling to confirm its provider list includes AS13335. You can keep other authorized providers. Publishing an ASPA is optional. + +### Queue validation + +After publishing the required ownership tokens and updating any ASPA, use the [Validate Prefix endpoint](/api/resources/addressing/subresources/prefixes/methods/validate/) to queue validation: ```bash curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/addressing/prefixes/$PREFIX_ID/validate" --request POST --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" ``` -Use the [Prefix Details endpoint](/api/resources/addressing/subresources/prefixes/methods/get/) to monitor validation. When the IRR, RPKI, and ownership checks pass, the `approved` field for the prefix returns `"V"`. You can then remove the ownership validation token and proceed to create service bindings. +Checks run asynchronously. Use the [Prefix Details endpoint](/api/resources/addressing/subresources/prefixes/methods/get/) to monitor the results. You do not need to submit repeated validation requests while checks are pending. + +When all applicable checks pass, the `approved` field returns `"V"`. Checks include IRR, RPKI, prefix ownership, and, when applicable, ASN ownership and ASPA authorization. + +After prefix ownership and any required ASN ownership checks return `valid`, you can remove the token from the IRR, reverse DNS, and `aut-num` records where you added it. Approval allows you to create service bindings. It does not advertise the prefix or activate traffic. -If validation fails, refer to [Troubleshoot prefix validation](/byoip/troubleshooting/prefix-validation/), correct the reported issues, and trigger validation again. +If validation fails, refer to [Troubleshoot prefix validation](/byoip/troubleshooting/prefix-validation/), correct the reported issues, and queue validation again. ### Optional: Delegate the prefix diff --git a/src/content/docs/byoip/troubleshooting/index.mdx b/src/content/docs/byoip/troubleshooting/index.mdx index c3c66603d15..b54183ab8f5 100644 --- a/src/content/docs/byoip/troubleshooting/index.mdx +++ b/src/content/docs/byoip/troubleshooting/index.mdx @@ -38,11 +38,10 @@ When onboarding BYOIP prefixes via the API, you may encounter the following erro | Error code | Meaning | Resolution | |---|---|---| -| `prefix_not_valid_and_approved` | The prefix has not passed IRR validation, RPKI validation, and ownership verification (or manual approval). | Verify all three validation steps have completed. If one or more are failing, check prefix registration with your Regional Internet Registry (RIR) and your RPKI ROA configuration. If validation is passing but you are still seeing this error, contact support for manual approval. | +| `prefix_not_valid_and_approved` | The prefix has not passed all applicable validation checks or manual approval. | Use the [Prefix Details endpoint](/api/resources/addressing/subresources/prefixes/methods/get/) and follow [Prefix validation checks](/byoip/troubleshooting/prefix-validation/). When you use your own ASN, check ASN ownership and Autonomous System Provider Authorization (ASPA) validation. If all applicable checks pass but you still see this error, contact support for manual approval. | | `incomplete_bgp_deployment` | Cannot create a BGP prefix without a default edge service binding configured. | Configure a default edge service binding before creating BGP prefixes. | | `advertise_state_locked` | Cannot create a BGP prefix — the default edge service binding is still deploying. | Wait for the edge service binding deployment to complete, then retry. | :::note Self-serve BYOIP onboarding is not supported when BYOIP is used as a Magic Transit on-ramp configuration. For more information, refer to [Magic Transit with CDN](/byoip/service-bindings/magic-transit-with-cdn/). ::: - diff --git a/src/content/docs/byoip/troubleshooting/prefix-validation.mdx b/src/content/docs/byoip/troubleshooting/prefix-validation.mdx index 29cedf2f4c8..789cd259572 100644 --- a/src/content/docs/byoip/troubleshooting/prefix-validation.mdx +++ b/src/content/docs/byoip/troubleshooting/prefix-validation.mdx @@ -9,41 +9,103 @@ sidebar: label: Prefix validation checks --- -import { APIRequest, GlossaryTooltip, Render } from "~/components"; +import { APIRequest, GlossaryTooltip, Render, Steps } from "~/components"; + + 1. Use the [Prefix Details endpoint](/api/resources/addressing/subresources/prefixes/methods/get/) to check if any issues were found during validation. - ```json title="Response" {17-19} - - "result": { - "id": "72823e95d6c64d48a8111fec81179816", - "created_at": "2025-02-25T00:34:11.423722Z", - "modified_at": "2025-02-25T00:34:11.423722Z", - "cidr": "203.0.113.0/24", - "account_id": "654c5f71c324478cc9f68d60065d4620", - "description": "", - "approved": "P", - "on_demand_enabled": false, - "on_demand_locked": false, - "advertised": null, - "advertised_modified_at": null, - "loa_document_id": "b9ff4afe312246a8b2e7324d98f40b23", - "asn": 13335, + This customer-ASN response excerpt shows a failed ASN ownership check: + + ```json title="Customer ASN response excerpt" + { + "result": { "ownership_validation_token": "", - "delegate_loa_creation" : true, "irr_validation_state": "valid", "rpki_validation_state": "valid", - "ownership_validation_state": "missing", + "ownership_validation_state": "valid", + "asn_ownership_validation_state": "invalid" } - + } ``` -2. Consider the states returned in the API response (for example, `missing`, `invalid`, `mismatch_asn`) and review your IRR record, ROA, and ownership validation method accordingly. +2. Consider the states returned in the API response (for example, `missing`, `invalid`, `mismatch_asn`) and review the corresponding records: your IRR `route` or `route6` object, ROA, prefix ownership validation records, ASN `aut-num` object, and any published ASPA. - Information in the IRR and ROA records should meet the [onboarding prerequisites](/byoip/get-started/#before-you-begin). - - [Ownership validation](/byoip/get-started/#validate-prefix-ownership) requires a matching ROA and the correct validation token found in all DNS TXT records or in the IRR record. + - Token-based [prefix ownership validation](/byoip/get-started/#validate-prefix-ownership) requires a valid ROA. Publish the validation token either in the matching `route` or `route6` object, or in each required reverse DNS zone. + + - [ASN ownership validation](/byoip/get-started/#validate-asn-ownership) requires the same token in the `aut-num` object when `asn_ownership_validation_state` applies. + + - [Autonomous System Provider Authorization (ASPA)](/byoip/concepts/route-filtering-rpki/#aspa-authorization) validation checks whether ASPA data for your ASN authorizes AS13335 as a provider. + + ## IRR validation + + Use the following guidance for `irr_validation_state`: + + | State | Meaning | Resolution | + | --- | --- | --- | + | `pending` | IRR validation has not completed. | Monitor the results using Prefix Details. You do not need to queue validation again while checks are pending. | + | `valid` | An IRR `route` or `route6` object exactly matches the prefix and selected ASN. | No action is required. | + | `missing` | Cloudflare could not find a matching IRR route object. | Publish a `route` or `route6` object for the prefix with the selected ASN as its `origin`. | + | `mismatch_asn` | The IRR route object has a different origin ASN. | Update the `origin` to match the ASN selected when you added the prefix. | + | `mismatch_more_specific` | The IRR route object covers a smaller address range than the prefix you added. | Publish a route object that exactly matches the prefix you want to onboard. | + | `mismatch_less_specific` | The IRR route object covers a larger address range and has the selected origin ASN. | This passes IRR validation. Confirm that the other validation checks also pass. | + | `invalid` | The IRR records do not satisfy validation requirements. | Check the route object, prefix, and origin ASN against the onboarding prerequisites, then queue validation again. | + + ## RPKI validation + + Use the following guidance for `rpki_validation_state`: + + | State | Meaning | Resolution | + | --- | --- | --- | + | `pending` | RPKI validation has not completed. | Monitor the results using Prefix Details. You do not need to queue validation again while checks are pending. | + | `valid` | A ROA authorizes the selected ASN to originate the prefix at its prefix length. | No action is required. | + | `missing` | No ROA covers the prefix. | Publish a ROA authorizing the selected ASN and prefix length. Token-based prefix ownership validation also requires a valid ROA. | + | `invalid` | The ROAs do not authorize the selected ASN or prefix length. | Correct the authorized ASN or maximum prefix length in your ROA. Verify the result with the [RPKI Portal](https://rpki.cloudflare.com/?view=validator), then queue validation again. | + + ## Prefix ownership validation + + Use the following guidance for `ownership_validation_state`: + + | State | Meaning | Resolution | + | --- | --- | --- | + | `pending` | Prefix ownership validation has not completed. | Monitor the results using Prefix Details. You do not need to queue validation again while checks are pending. | + | `valid` | Prefix ownership is verified. | No action is required. Remove the token only after any required ASN ownership check also returns `valid`. | + | `missing` | RPKI validation is `missing`, or neither the IRR nor reverse DNS method provides the required ownership records. | Check `rpki_validation_state`, publish a valid ROA, and confirm that your IRR record or each required reverse DNS zone contains the token. | + | `invalid` | Prefix ownership proof did not pass validation. | Confirm that RPKI validation is `valid` and that the token matches `ownership_validation_token` in the IRR record or each required reverse DNS zone. | + + If you use a manually uploaded Letter of Agency (LOA), ownership validation remains `invalid` until Cloudflare verifies the document. Contact your account team to confirm its verification status. + + ## ASN ownership validation + + Use the following guidance for `asn_ownership_validation_state`: + + | State | Meaning | Resolution | + | --- | --- | --- | + | `pending` | ASN ownership validation has not completed. | Monitor the results using Prefix Details. You do not need to queue validation again while checks are pending. | + | `valid` | The account has verified ownership of the ASN. | No action is required. Future prefixes in the same account reuse this verification. | + | `missing` | Cloudflare could not find an `aut-num` object for the ASN at a supported RIR. | Verify the object exists at AFRINIC, APNIC, ARIN, or RIPE. For a LACNIC-registered ASN, contact your account team. | + | `invalid` | The `aut-num` object does not contain the expected token. | Add `cf-validation: ` to an editable field in the `aut-num` object. | + + This field is omitted when ASN ownership validation does not apply, such as when you use AS13335. Omission does not confirm ownership of a customer ASN. + + ## ASPA validation + + Use the following guidance for `aspa_validation_state`: + + | State | Meaning | Resolution | + | --- | --- | --- | + | `pending` | ASPA validation has not completed. | Monitor the results using Prefix Details. You do not need to queue validation again while checks are pending. | + | `valid` | ASPA data for your ASN authorizes AS13335 as a provider. | No action is required. | + | `invalid` | ASPA data for your ASN does not authorize AS13335 as a provider. | Use your RIR's RPKI tooling to add AS13335 to the ASPA provider list. You can keep other authorized providers. | + + If `aspa_validation_state` is omitted, no ASPA validation result is available. Omission does not indicate successful validation or confirm that no ASPA exists. + + Publishing an ASPA is optional. An `invalid` result blocks approval until your ASPA authorizes AS13335. + +3. -3. \ No newline at end of file + diff --git a/src/content/partials/byoip/cloudflare-asn-callout.mdx b/src/content/partials/byoip/cloudflare-asn-callout.mdx deleted file mode 100644 index c4c4f51e5e3..00000000000 --- a/src/content/partials/byoip/cloudflare-asn-callout.mdx +++ /dev/null @@ -1,7 +0,0 @@ ---- -{} ---- - -:::caution[Use Cloudflare's ASN] -The process described on this page only supports using Cloudflare's ASN (AS13335). If you must announce the prefixes under your own ASN, contact your account team. -::: \ No newline at end of file diff --git a/src/content/partials/byoip/validate-prefix-endpoint.mdx b/src/content/partials/byoip/validate-prefix-endpoint.mdx index 096f54fc687..995a40a6e13 100644 --- a/src/content/partials/byoip/validate-prefix-endpoint.mdx +++ b/src/content/partials/byoip/validate-prefix-endpoint.mdx @@ -5,7 +5,7 @@ import { APIRequest } from "~/components"; -After applying the necessary changes, use the Validate Prefix endpoint to trigger the validation checks. +After applying the necessary changes, use the Validate Prefix endpoint to queue validation. Checks run asynchronously. Use the [Prefix Details endpoint](/api/resources/addressing/subresources/prefixes/methods/get/) to monitor the results. You do not need to submit repeated validation requests while checks are pending.