Cloudflare BYOIP Integration Overview
Searching for the best IP providers? Cloudflare’s Enterprise-only BYOIP program lets you bring your own IPv4 and IPv6 prefixes onto Cloudflare’s global anycast network so your applications can keep your IP space while using Cloudflare’s security and performance services. Since November 2025, Cloudflare has offered a self-serve BYOIP API, using RPKI plus IRR or reverse-DNS TXT ownership validation instead of relying only on manual LOA review. Magic Transit uses the same Addressing API, but adds its own IP-prefix and BGP-prefix model, so confirm that scope with your account team. Below you’ll find Cloudflare setup documentation, BYOIP requirements, commercial notes, and practical onboarding steps.
Provider Details
| Field | Information |
|---|---|
| Provider Name | Cloudflare |
| Website | Cloudflare Website |
| ASN(s) | AS13335 (Cloudflare Customer ASN) if you do not have your own. You can also announce with your own ASN, in which case Cloudflare prepends AS13335 to the advertised BGP AS_PATH. |
| Regions Supported | Global anycast across Cloudflare’s network worldwide; service behavior depends on the product and service-binding configuration |
| Support Contact | Existing customers: confirm BYOIP contract coverage with your Cloudflare account team Magic Transit scope, BGP control through route reflectors, or CNI peering: work through your account team / Cloudflare Professional Services New prospects: contact Cloudflare Sales |
| Tech Article & Date | DIY BYOIP: a new way to Bring Your Own IP prefixes to Cloudflare - November 2025 Bringing Your Own IPs to Cloudflare (BYOIP) - July 2020 Cloudflare outage on February 20, 2026 - February 2026 |
| BYOIP Scope | Enterprise-only BYOIP for IPv4 and IPv6 across Cloudflare services including CDN services, Spectrum, Magic Transit, Gateway DNS locations, and dedicated egress IP use cases. Service bindings allow compatible per-prefix or per-IP routing between supported services. |
| Supported Versions | IPv4 and IPv6 |
| Supported Services | CDN / WAF and related Layer 7 services, Spectrum, Magic Transit, Gateway DNS locations, dedicated CDN egress IPs, plus Address Maps for proxied DNS IP control |
Technical Requirements
| Requirement | Details |
|---|---|
| Prefix Size | IPv4: /24 minimum. Prefixes longer than /24 are not accepted because they are not globally routable. IPv6: /48 minimum |
| ASN Ownership Required | A dedicated customer ASN is not required: you can onboard under the Cloudflare Customer ASN (AS13335). If you supply your own ASN, Cloudflare prepends AS13335 to the BGP AS_PATH, so a direct peer sees a path such as 13335 64496. Your IRR objects and ROAs must match the ASN you onboard with. |
| IRR or RADb Object | Required and must be current: exact route / route6 objects for the prefix, with the correct origin ASN. For ownership validation, Cloudflare can use IRR remarks / description fields containing the Cloudflare validation token. |
| ROA or LOA | Accurate RPKI ROAs are required for the modern validation flow. Self-serve onboarding validates RPKI plus IRR or reverse-DNS TXT ownership checks; Cloudflare can auto-generate LOA-style documentation for downstream acceptance. Manual or service-specific cases may still involve explicit LOA handling. |
| RIR Limitations | Prefixes must be registered under a supported Regional Internet Registry: AFRINIC, APNIC, ARIN, LACNIC, or RIPE NCC. |
Step-by-Step BYOIP Process
Confirm your Enterprise contract covers BYOIP and the specific service scope you need. Magic Transit uses the same Addressing API, but its separate IP-prefix and BGP-prefix model, per-BGP-prefix billing, and BGP control through route reflectors or CNI peering are scoped with your Cloudflare account team.
Ensure the prefix is registered with a supported RIR, update exact IRR route/route6 objects, and publish accurate RPKI ROAs. For the standard self-serve flow, ROAs should authorize AS13335.
Use Cloudflare’s Addressing API to create the prefix object. Cloudflare can generate LOA-style documentation on your behalf as part of the modern workflow.
Complete ownership checks using either IRR remarks/description fields or reverse-DNS TXT records with Cloudflare’s validation token. Wait until RPKI, IRR, and ownership checks pass.
Every onboarded prefix needs one service binding that spans the full prefix. This tells Cloudflare which service should handle traffic for the range by default.
After the default binding is in place, allow five hours, then advertise the BGP prefix with the Update BGP prefix endpoint. If needed, add more-specific service bindings for supported use cases such as CDN and Spectrum, allowing four to six hours for each change to propagate.
Use Address Maps for proxied DNS IP selection, assign application-specific bindings where appropriate, and for Magic Transit complete the separate tunnel and routing onboarding steps with Cloudflare.
Cost and Limitations
| Item | Details |
|---|---|
| Fees | No public BYOIP list price is published. Commercial terms are enterprise-contract specific, so confirm pricing and packaging with your Cloudflare account team or Sales. |
| Bundled or Standalone | BYOIP is consumed through supported Cloudflare enterprise products rather than a public standalone plan. One onboarded prefix can support multiple compatible services through service bindings, but a single prefix can be used for either CDN ingress or dedicated CDN egress, not both. |
| Traffic/Peering Restrictions | Cloudflare announces the onboarded prefix from its global anycast network. Keep IRR and ROA records exact and avoid conflicting external announcements. When migrating away, Cloudflare recommends draining in stages: advertise the same-length prefix from your own ISP, allow five to ten minutes for BGP convergence, then withdraw from the Cloudflare edge, which avoids leaving a stuck route in the default-free zone. |
| Other Limitations | Each onboarded prefix requires one default service binding covering the entire prefix. Additional bindings can be more specific. Service binding changes take four to six hours to propagate and may briefly disrupt traffic for the affected IPs during that window. Spectrum UDP applications are supported with BYOIP for CDN and Spectrum service bindings, but not with Magic Transit service bindings. Cloudflare does not reassemble fragmented UDP packets: they are dropped at the edge. On February 20, 2026 an Addressing API defect withdrew roughly 1,100 BYOIP prefixes for about six hours, so keep a documented re-advertisement path for your prefixes. |
Automation & Developer Access
- Addressing API: Cloudflare provides API coverage for creating prefixes, validating ownership, delegating prefixes, advertising BGP prefixes, and managing service bindings.
- Validation automation: Ownership can be verified through IRR token placement or reverse-DNS TXT records, with RPKI checks used to confirm routing authorization.
- Address Maps and delegations: BYOIP prefixes can be mapped to proxied DNS records through Address Maps, and portions of a prefix can be delegated to other accounts while service bindings remain managed on the parent account.
- API-first workflow: Service binding operations are currently API-based, which makes Cloudflare BYOIP suitable for scripted onboarding and infrastructure automation.
Abuse & Reputation Management
- Customer responsibility: You retain primary responsibility for IP reputation, allowlisting, and third-party delisting or remediation workflows tied to your address space.
- Operational visibility: Cloudflare provides routing controls and product-level observability, but external blacklist or sender-reputation management still remains with the customer.