--- title: Cloudflare BYOIP description: Get Cloudflare's security and performance while using your own IPs. image: https://developers.cloudflare.com/core-services-preview.png --- > Documentation Index > Fetch the complete documentation index at: https://developers.cloudflare.com/byoip/llms.txt > Use this file to discover all available pages before exploring further. [Skip to content](#%5Ftop) # Cloudflare BYOIP Get Cloudflare's security and performance while using your own IPs. Enterprise-only When you use Cloudflare as a [reverse proxy](https://developers.cloudflare.com/fundamentals/concepts/how-cloudflare-works/), Cloudflare responds to DNS queries for proxied records with Cloudflare-owned IP addresses[1](#user-content-fn-1). For some organizations, it is important to keep their website or application associated with IP addresses they already own rather than using Cloudflare's. With Bring Your Own IP (BYOIP), Cloudflare announces your IP prefixes in all our locations. Use your IPs with [Magic Transit](https://developers.cloudflare.com/magic-transit/), [Spectrum](https://developers.cloudflare.com/spectrum/), [CDN services](https://developers.cloudflare.com/cache/), or Gateway [DNS locations](https://developers.cloudflare.com/cloudflare-one/networks/resolvers-and-proxies/dns/locations/) and [dedicated egress IPs](https://developers.cloudflare.com/cloudflare-one/traffic-policies/egress-policies/dedicated-egress-ips/). Learn how to [get started](https://developers.cloudflare.com/byoip/get-started/). --- ## Features ### Service bindings Control whether traffic destined for a given IP address is routed to Magic Transit, CDN, or Spectrum. [ Use Service bindings ](https://developers.cloudflare.com/byoip/service-bindings/) ### Address maps Specify which IP addresses should be mapped to DNS records when they are proxied through Cloudflare. [ Use Address maps ](https://developers.cloudflare.com/byoip/address-maps/) --- ## More resources [RPKI blog post](https://blog.cloudflare.com/rpki/) An overview of BGP, RPKI, and other important aspects of Internet routing. [Reference Architectures](https://developers.cloudflare.com/reference-architecture/) Explore how you can leverage Cloudflare's platform to create solutions based on your business needs. ## Footnotes 1. Without BYOIP, when your domain's records are `proxied`, Cloudflare responds with a Cloudflare-owned [anycast IP address](https://developers.cloudflare.com/fundamentals/concepts/cloudflare-ip-addresses/). [↩](#user-content-fnref-1) ```json {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"item":{"@id":"/directory/","name":"Directory"}},{"@type":"ListItem","position":2,"item":{"@id":"/byoip/","name":"BYOIP"}}]} ``` --- --- title: Get started description: Onboard your IP prefixes to Cloudflare with BYOIP. image: https://developers.cloudflare.com/core-services-preview.png --- > Documentation Index > Fetch the complete documentation index at: https://developers.cloudflare.com/byoip/llms.txt > Use this file to discover all available pages before exploring further. [Skip to content](#%5Ftop) ### Tags [ DNS ](https://developers.cloudflare.com/search/?tags=DNS) # Get started To use your own IP addresses with Cloudflare, please check with your account team to confirm your contract covers this functionality. You will need to configure settings specific to the services you want to use, as well as meet some standard requirements for all BYOIP customers. Once your account configurations are in place, consider the sections below to learn how to set up your BYOIP prefixes. Also make sure to review the [BYOIP Service-Specific Terms ↗](https://www.cloudflare.com/service-specific-terms-network-services/#bring-your-own-ip-terms). Magic Transit The process described on this page does not support onboarding IP prefixes for use with [Cloudflare Magic Transit](https://developers.cloudflare.com/magic-transit/). For further guidance, refer to the [Magic Transit get started](https://developers.cloudflare.com/magic-transit/get-started/). ## Before you begin * Your prefix must be registered under one of the Regional Internet Registries (RIRs): * [AFRINIC ↗](https://afrinic.net/) * [APNIC ↗](https://www.apnic.net/) * [ARIN ↗](https://www.arin.net/) * [LACNIC ↗](https://lacnic.net/) * [RIPE ↗](https://www.ripe.net/) * Also verify that your [Internet Routing Registry (IRR)](https://developers.cloudflare.com/byoip/concepts/irr-entries/) records are are up to date and contain: * `route` or `route6` objects matching the exact prefixes you want to onboard * `origin` matching the correct ASN you want to onboard 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. * You must use [Resource Public Key Infrastructure (RPKI) validation](https://developers.cloudflare.com/byoip/concepts/route-filtering-rpki/) and make sure your ROAs are accurate. You can use [Cloudflare's RPKI Portal ↗](https://rpki.cloudflare.com/?view=validator) and a second source such as [Routinator ↗](https://rpki-validator.ripe.net/ui/) to double-check your prefixes. * If you are not familiar with how Cloudflare API works, refer to [Fundamentals](https://developers.cloudflare.com/fundamentals/api/). Make sure you have the necessary permissions and that you have your account ID. --- ## 1\. Set up your prefixes ### Add your prefix 1. Use the [Add Prefix endpoint](https://developers.cloudflare.com/api/resources/addressing/subresources/prefixes/methods/create/) to create a prefix in the Cloudflare account that should own the BYOIP prefix. 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. Add Prefix ``` curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/addressing/prefixes" \ --request POST \ --header "X-Auth-Email: $CLOUDFLARE_EMAIL" \ --header "X-Auth-Key: $CLOUDFLARE_API_KEY" \ --json '{ "cidr": "203.0.113.0/24", "asn": 13335, "delegate_loa_creation": true }' ``` Response ``` "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, "ownership_validation_token": "", "delegate_loa_creation" : true, "irr_validation_state": "pending", "rpki_validation_state": "pending", "ownership_validation_state": "pending", } ``` 1. Take note of the `id` assigned to the prefix you added. It will be used in future steps. Letter of Agency (LOA) The process described on this page leverages automated [LOA](https://developers.cloudflare.com/byoip/concepts/loa/) generation. If you set `delegate_loa_creation` to `false`, you have to manually upload your LOA, make a [PATCH request](https://developers.cloudflare.com/api/resources/addressing/subresources/prefixes/methods/edit/) once the prefix is approved, and contact your account team - which is more prone to error and increases the onboarding time. ### Validate prefix ownership 1. Validate prefix ownership using one of the following methods: * [ IRR record ](#tab-panel-4716) * [ Reverse DNS zone and TXT record ](#tab-panel-4717) 1. Copy the `ownership_validation_token` returned by the API call. 2. On the IRR record of the prefix you are onboarding, add the following string in either a `description` or `remarks` field. Replace `` by the actual token you copied in the previous step. ``` cf-validation: ``` Note The exact steps to update your IRR record will depend on the registry you are using. Refer to [Internet Routing Registry (IRR)](https://developers.cloudflare.com/byoip/concepts/irr-entries/best-practices/) for details. 1. Consider the size of the prefix you are bringing to Cloudflare. Since the standard `in-addr.arpa` tree assumes delegations on octet or nibble boundaries, if you onboard prefixes that are not aligned with those, you will have to split up the prefix into subnets and create the corresponding reverse DNS zones for each. Example To calculate how many smaller subnets you need, use the following formula: ``` 2^(next boundary - current netmask) ``` For `1.1.0.0/23`, you would setup two (`2^(24-23)`) reverse DNS zones, one for `1.1.0.0/24` and another for `1.1.1.0/24`. For `2001:0db8::/34`, you would setup four (`2^(36-34)`) reverse DNS zones, for `2001:0db8::/36`, `2001:0db8:1:/36`, `2001:0db8:2::/36`, and `2001:0db8:3::/36`. 1. Set up a reverse DNS zone. If you use Cloudflare for DNS, refer to [Reverse DNS zones](https://developers.cloudflare.com/dns/additional-options/reverse-zones/#set-up-a-reverse-zone). If you use a different DNS provider, follow their instructions. 2. Create TXT records using `cf-validation` as their `name`. They should look like the following example: ``` cf-validation. IN TXT ``` 1. Update nameservers at your Regional Internet Registry (RIR). The exact steps to update your nameservers will depend on the registry you are using. 2. After applying the necessary changes, use the Validate Prefix endpoint to trigger the validation checks. Required API token permissions At least one of the following [token permissions](https://developers.cloudflare.com/fundamentals/api/reference/permissions/)is required: * `Magic Transit Write` * `IP Prefixes: Write` Validate Prefix ``` curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/addressing/prefixes/$PREFIX_ID/validate" \ --request POST \ --header "X-Auth-Email: $CLOUDFLARE_EMAIL" \ --header "X-Auth-Key: $CLOUDFLARE_API_KEY" ``` Once the ownership validation is successful, you can remove the token. When all validations pass - RPKI, IRR, and ownership - the `approved` field in your prefix will return `"V"`. This means you can proceed to create IP address service bindings[1](#user-content-fn-1). If needed, you can use the [Prefix Details endpoint](https://developers.cloudflare.com/api/resources/addressing/subresources/prefixes/methods/get/) to check if any issues were found during validation. If so, proceed with the necessary changes and make a request to restart validation. Refer to [Prefix validation checks](https://developers.cloudflare.com/byoip/troubleshooting/prefix-validation/) for details. ### (Optional) Delegate your BYOIP prefixes You can allow other accounts to use part or all of your BYOIP prefix. Refer to [Prefix delegations](https://developers.cloudflare.com/byoip/concepts/prefix-delegations/) for details. Required API token permissions At least one of the following [token permissions](https://developers.cloudflare.com/fundamentals/api/reference/permissions/)is required: * `IP Prefixes: Write` Create Prefix Delegation ``` curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/addressing/prefixes/$PREFIX_ID/delegations" \ --request POST \ --header "X-Auth-Email: $CLOUDFLARE_EMAIL" \ --header "X-Auth-Key: $CLOUDFLARE_API_KEY" \ --json '{ "cidr": "", "delegated_account_id": "" }' ``` Note Although you can delegate IPs to other accounts, the IP address service bindings are still created and managed on the parent account - meaning the Cloudflare account where you added the prefix in step 1. --- ## 2\. Create service bindings In IP address management, service bindings map the traffic destined for a given IP address to the Cloudflare service that it should be routed through. ### Default service binding When you onboard your IP prefixes to Cloudflare, there must be one service binding that spans across your entire prefix. Traffic destined for a given IP address will be routed to this service by default. You can also configure [additional service bindings](#optional-additional-bindings) as described in the next step. 1. Make a `GET` request to the [List Services](https://developers.cloudflare.com/api/resources/addressing/subresources/services/methods/list/) endpoint and take note of the `id` associated with the service you want to use. CDN egress [Dedicated CDN Egress IPs](https://developers.cloudflare.com/smart-shield/configuration/dedicated-egress-ips/) (formerly known as Aegis) is only available for Enterprise. If you are interested, reach out to your account team. Also note that a single BYOIP prefix can be used for either CDN ingress or CDN egress, but not both. 1. (Optional) If needed, use the [List Prefixes](https://developers.cloudflare.com/api/resources/addressing/subresources/prefixes/methods/list/) endpoint to get or confirm the `id` associated with your prefix. 2. Make a `POST` request to the [Create service binding](https://developers.cloudflare.com/api/resources/addressing/subresources/prefixes/subresources/service%5Fbindings/methods/create/) endpoint, indicating the entire BYOIP prefix that you are onboarding and the service that should be used for your default binding. Required API token permissions At least one of the following [token permissions](https://developers.cloudflare.com/fundamentals/api/reference/permissions/)is required: * `IP Prefixes: Write` Create Service Binding ``` curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/addressing/prefixes/$PREFIX_ID/bindings" \ --request POST \ --header "X-Auth-Email: $CLOUDFLARE_EMAIL" \ --header "X-Auth-Key: $CLOUDFLARE_API_KEY" \ --json '{ "cidr": "203.0.113.0/24", "service_id": "" }' ``` A corresponding BGP prefix will be created automatically. Allow five hours before you advertise the prefix. ### (Optional) Additional bindings If you want to selectively route traffic on a per-IP address basis to CDN or Spectrum, you can create additional service bindings. Note The steps below only cover assigning specific IPs to additional services. For guidance that includes CDN or Spectrum setup steps, refer to [Service bindings](https://developers.cloudflare.com/byoip/service-bindings/). 1. Plan for what IP(s) will get the additional binding. Cloudflare **strongly** recommends implementing service bindings through an **aggregated** CIDR block, as it is more efficient than adding discrete bindings for non-contiguous CIDR blocks. Example **Spectrum protected prefix:** `203.0.113.0/24` **IPs to upgrade to CDN:** `203.0.113.16` `203.0.113.17` `203.0.113.18` `203.0.113.19` `203.0.113.20` `203.0.113.21` `203.0.113.22` `203.0.113.23` Add one discrete CDN service binding for `203.0.113.16` with a `/29` netmask. 1. Make a `POST` request to the [Create service binding](https://developers.cloudflare.com/api/resources/addressing/subresources/prefixes/subresources/service%5Fbindings/methods/create/) endpoint, indicating the IP address you want to bind to the CDN or Spectrum. Specify the **corresponding network mask** as needed. Required API token permissions At least one of the following [token permissions](https://developers.cloudflare.com/fundamentals/api/reference/permissions/)is required: * `IP Prefixes: Write` Create Service Binding ``` curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/addressing/prefixes/$PREFIX_ID/bindings" \ --request POST \ --header "X-Auth-Email: $CLOUDFLARE_EMAIL" \ --header "X-Auth-Key: $CLOUDFLARE_API_KEY" \ --json '{ "cidr": "203.0.113.16/29", "service_id": "" }' ``` In the response body, the initial provisioning state should be `provisioning`. ``` { "errors": [], "messages": [], "success": true, "result": { "cidr": "203.0.113.16/29", "id": "", "provisioning": { "state": "provisioning" }, "service_id": "", "service_name": "" } } ``` Once a service binding is created (or deleted), it will take **four to six hours** to propagate across Cloudflare's global network. Note Magic Transit can only be used as default binding, spanning across your entire prefix. For more details, refer to [Service bindings scope](https://developers.cloudflare.com/byoip/service-bindings/#scope). --- ## 3\. Advertise the BGP prefix Once automatically created (following [step 2](#2-create-service-bindings)), BGP prefixes are initially withdrawn. After all your configurations are in place - including [address maps](https://developers.cloudflare.com/byoip/address-maps/)[2](#user-content-fn-2) if you will use CDN service -, proceed to advertise the BGP route for your prefix. 1. Use the [Update BGP prefix](https://developers.cloudflare.com/api/resources/addressing/subresources/prefixes/subresources/bgp%5Fprefixes/methods/edit/) endpoint to start the advertisement. Required API token permissions At least one of the following [token permissions](https://developers.cloudflare.com/fundamentals/api/reference/permissions/)is required: * `Magic Transit Write` * `IP Prefixes: Write` * `IP Prefixes: BGP On Demand Write` Update BGP Prefix ``` curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/addressing/prefixes/$PREFIX_ID/bgp/prefixes/$BGP_PREFIX_ID" \ --request PATCH \ --header "X-Auth-Email: $CLOUDFLARE_EMAIL" \ --header "X-Auth-Key: $CLOUDFLARE_API_KEY" \ --json '{ "on_demand": { "advertised": true } }' ``` ## Footnotes 1. Mappings that control through which pipeline traffic destined for a given IP address will be routed. [↩](#user-content-fnref-1) 2. Mappings that specify which IP addresses should be used when Cloudflare responds to DNS queries for proxied hostnames. [↩](#user-content-fnref-2) ```json {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"item":{"@id":"/directory/","name":"Directory"}},{"@type":"ListItem","position":2,"item":{"@id":"/byoip/","name":"BYOIP"}},{"@type":"ListItem","position":3,"item":{"@id":"/byoip/get-started/","name":"Get started"}}]} ``` --- --- title: About address maps description: Map IP prefixes to zones and accounts with address maps. image: https://developers.cloudflare.com/core-services-preview.png --- > Documentation Index > Fetch the complete documentation index at: https://developers.cloudflare.com/byoip/llms.txt > Use this file to discover all available pages before exploring further. [Skip to content](#%5Ftop) ### Tags [ DNS ](https://developers.cloudflare.com/search/?tags=DNS) # About address maps Address map is a data structure enabling customers with BYOIP prefixes or account-level static IPs to specify which IP addresses should be mapped to DNS records when they are proxied through Cloudflare. By default, Cloudflare responds to DNS queries for proxied hostnames with Cloudflare-owned [anycast IP addresses](https://developers.cloudflare.com/fundamentals/concepts/cloudflare-ip-addresses/). Address maps allow you to override this behavior — when a zone or account is associated with an address map, Cloudflare responds with the IP addresses you specify instead. To use address maps, you must first have [BYOIP](https://developers.cloudflare.com/byoip/) prefixes or [static IPs](https://developers.cloudflare.com/byoip/concepts/static-ips/) configured on your account. You can [customize the IPs Cloudflare uses](https://developers.cloudflare.com/fundamentals/concepts/cloudflare-ip-addresses/#customize-cloudflare-ip-addresses) through either approach. If you are interested in address maps but do not yet have BYOIP or static IPs, contact your account manager. Note Both IPv4 and IPv6 addresses are supported. --- ## How Address Maps works For zones using [Cloudflare's authoritative DNS](https://developers.cloudflare.com/dns/), Cloudflare typically responds to DNS queries for proxied hostnames with [anycast IPs](https://developers.cloudflare.com/fundamentals/concepts/cloudflare-ip-addresses/). However, if you [customize the IPs Cloudflare uses](https://developers.cloudflare.com/fundamentals/concepts/cloudflare-ip-addresses/#customize-cloudflare-ip-addresses) and use Address Maps, Cloudflare will respond with the IP address(es) on the address map. Address maps do not change [how Cloudflare reaches the configured origin](https://developers.cloudflare.com/fundamentals/concepts/how-cloudflare-works/#cloudflare-as-a-reverse-proxy). The IP addresses defined on your zone's [DNS Records ↗](https://dash.cloudflare.com/?to=/:account/:zone/dns/records) continue to instruct Cloudflare how to reach the origin. Warning Depending on whether you use static IPs or BYOIP, the process to [create an address map](https://developers.cloudflare.com/byoip/address-maps/setup/) is different. ### Static IPs or BYOIP Leased static IPs allow you to use a set of specifically assigned Cloudflare IPs to ensure they do not change. Cloudflare creates an address map with your static IPs that you may edit. You cannot create another map using your static IPs. With BYOIP, you use your IPs by bringing an address space that you lease or own and creating an address map. --- ## Immutable address maps Some customers may only proxy zones through BYOIP addresses, and are prohibited from using Cloudflare IP addresses for proxied DNS names. In this case, Cloudflare will create an immutable, account-wide address map to ensure all zones in your account receive BYOIP addresses as a fallback. These address maps cannot be deleted. It is still possible to create more specific zone-level address maps with specific BYOIPs, but DNS will fall back to the account-wide address map without one. To specify different addresses for certain zones, [create a new address map](https://developers.cloudflare.com/byoip/address-maps/setup/). --- ## Spectrum compatibility You can use address maps to set up [non-SNI support](https://developers.cloudflare.com/byoip/address-maps/setup/#spectrum-https-applications) for Spectrum HTTPS applications. However, to control what IP address Cloudflare will use when responding to requests for your Spectrum applications, you should first refer to their respective configuration and set the `edge_ips` field as `static`, e.g.: ``` "edge_ips": { "type": "static", "ips": ["1.2.3.4"] } ``` For details, refer to the [Spectrum API](https://developers.cloudflare.com/api/resources/spectrum#%28resource%29%20spectrum%20%3E%20%28model%29%20edge%5Fips%20%3E%20%28schema%29%20%3E%20%28variant%29%201). ```json {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"item":{"@id":"/directory/","name":"Directory"}},{"@type":"ListItem","position":2,"item":{"@id":"/byoip/","name":"BYOIP"}},{"@type":"ListItem","position":3,"item":{"@id":"/byoip/address-maps/","name":"About address maps"}}]} ``` --- --- title: Set up address maps description: Create and configure address maps for your IP prefixes. image: https://developers.cloudflare.com/core-services-preview.png --- > Documentation Index > Fetch the complete documentation index at: https://developers.cloudflare.com/byoip/llms.txt > Use this file to discover all available pages before exploring further. [Skip to content](#%5Ftop) ### Tags [ DNS ](https://developers.cloudflare.com/search/?tags=DNS) # Set up address maps Consider the sections below to learn how to set up address maps. Note There is **no expected downtime** when setting up or updating your address maps. ## Create address maps If you are using BYOIP, refer to the following steps. If you have [static IPs](https://developers.cloudflare.com/byoip/concepts/static-ips/), Cloudflare creates an address map during the static IP onboarding process, meaning you may only [edit](#manage-address-maps) the Cloudflare-created map. * [ Dashboard ](#tab-panel-4712) * [ API ](#tab-panel-4713) 1. In the Cloudflare dashboard, go to the **Address Maps** page. [ Go to **Address maps** ](https://dash.cloudflare.com/?to=/:account/ip-addresses/proxy-ips) 2. Select **Create an address map**. 3. Choose the scope of the address map. 4. Add the zones and IP addresses that you want to map. 5. Name your address map. 6. Review the information and select **Save and Deploy**. Note Creating an address map does not automatically change DNS configuration. DNS responses only begin to change when a zone or account is added to a map. Additionally, address maps that are not yet enabled will not take effect in DNS responses. Required API token permissions At least one of the following [token permissions](https://developers.cloudflare.com/fundamentals/api/reference/permissions/)is required: * `Address Maps Write` Create Address Map ``` curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/addressing/address_maps" \ --request POST \ --header "X-Auth-Email: $CLOUDFLARE_EMAIL" \ --header "X-Auth-Key: $CLOUDFLARE_API_KEY" \ --json '{ "description": "Example address map", "enabled": true, "ips": [ "203.0.113.1", "203.0.113.2" ], "memberships": [ { "identifier": "", "kind": "zone" } ] }' ``` Note A zone membership will take priority over an account membership. ## Manage address maps * [ Dashboard ](#tab-panel-4710) * [ API ](#tab-panel-4711) 1. In the Cloudflare dashboard, go to the **Address Maps** page. [ Go to **Address maps** ](https://dash.cloudflare.com/?to=/:account/ip-addresses/proxy-ips) 2. Go to your address map and select **Review**. 3. Edit your address map. 4. Review the information and select **Save**. Note You can also enable, disable, and delete address maps. This will likely change the IP addresses used for your zones. Use the following API endpoints depending on what you want to achieve: * [Modify the properties of an address map](https://developers.cloudflare.com/api/resources/addressing/subresources/address%5Fmaps/methods/edit/) * [Add or remove IP addresses](https://developers.cloudflare.com/api/resources/addressing/subresources/address%5Fmaps/subresources/ips/) * [Add or remove accounts](https://developers.cloudflare.com/api/resources/addressing/subresources/address%5Fmaps/subresources/accounts/) * [Add or remove zones](https://developers.cloudflare.com/api/resources/addressing/subresources/address%5Fmaps/subresources/zones/) Note A zone membership will take priority over an account membership. ## Non-SNI support If your visitors use devices that have not been updated since 2011, they may not have Server Name Indication (SNI) support. For further context, refer to [browser compatibility](https://developers.cloudflare.com/ssl/reference/browser-compatibility/#non-sni-support). Use address maps to specify a hostname as default SNI. This will be used whenever Cloudflare receives a non-SNI TLS handshake. Note Setting up a default SNI is currently only supported via API. 1. If you have not already, create an address map. Refer to the [section above](#create-address-maps) or to the [Create Address Map](https://developers.cloudflare.com/api/resources/addressing/subresources/address%5Fmaps/methods/create/) API endpoint. 2. Take note of the address map `id`. If needed, you can use the [List Address Maps](https://developers.cloudflare.com/api/resources/addressing/subresources/address%5Fmaps/methods/list/) endpoint to get it. 3. Make sure you add the desired IPs to the address map. Cloudflare will respond with the default SNI on those IPs. Use the dashboard or refer to [Add An IP To An Address Map](https://developers.cloudflare.com/api/resources/addressing/subresources/address%5Fmaps/subresources/ips/methods/update/). 4. Configure the `default_sni` value on the address map created in step 1\. Refer to the [Update Address Map](https://developers.cloudflare.com/api/resources/addressing/subresources/address%5Fmaps/methods/edit/) API endpoint for details. The default SNI can be any valid domain or subdomain owned by your account. ### Spectrum HTTPS applications Default SNI for Spectrum can only be created via API using the [Create Address Map](https://developers.cloudflare.com/api/resources/addressing/subresources/address%5Fmaps/methods/create/) endpoint. Do not include any membership in your command. Your API command should resemble the following: Required API token permissions At least one of the following [token permissions](https://developers.cloudflare.com/fundamentals/api/reference/permissions/)is required: * `Address Maps Write` Create Address Map ``` curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/addressing/address_maps" \ --request POST \ --header "X-Auth-Email: $CLOUDFLARE_EMAIL" \ --header "X-Auth-Key: $CLOUDFLARE_API_KEY" \ --json '{ "description": "default_sni", "default_sni": "sni.example.com", "enabled": false, "ips": [ "192.0.0.1" ], "memberships": [] }' ``` ```json {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"item":{"@id":"/directory/","name":"Directory"}},{"@type":"ListItem","position":2,"item":{"@id":"/byoip/","name":"BYOIP"}},{"@type":"ListItem","position":3,"item":{"@id":"/byoip/address-maps/","name":"About address maps"}},{"@type":"ListItem","position":4,"item":{"@id":"/byoip/address-maps/setup/","name":"Set up address maps"}}]} ``` --- --- title: IP address service bindings description: In IP address management, service binding refers to the association of IPs to specific Cloudflare services. Review the available options and the API endpoints to set up service bindings. image: https://developers.cloudflare.com/core-services-preview.png --- > Documentation Index > Fetch the complete documentation index at: https://developers.cloudflare.com/byoip/llms.txt > Use this file to discover all available pages before exploring further. [Skip to content](#%5Ftop) ### Tags [ Bindings ](https://developers.cloudflare.com/search/?tags=Bindings) # IP address service bindings In the context of BYOIP, service bindings map traffic destined for IP addresses to the Cloudflare service it should be routed through - such as Magic Transit, CDN, or Spectrum. A default binding covering the entire prefix is required when you first [onboard](https://developers.cloudflare.com/byoip/get-started/#2-create-service-bindings), and additional bindings can be created at any time to route specific IP addresses or CIDR ranges to a different service. For example, you could set Magic Transit as the default service for Layer 3 DDoS protection across the entire prefix, while directing specific IPs to the CDN for Layer 7 processing. Refer to [Scope](#scope) for the available combinations. Note **API-only**: Service binding operations are currently only available via API. You can find all endpoints and their specifications in the [Cloudflare API documentation](https://developers.cloudflare.com/api/resources/addressing/subresources/prefixes/subresources/service%5Fbindings/). For detailed guidance, refer to the sections and tutorials linked below. **Time to propagate**: Service bindings take four to six hours to propagate across Cloudflare's global network after being created or deleted. Services for the IP addresses in scope are likely disrupted during this window. ## Scope Customers using BYOIP with Magic Transit, [CDN services](https://developers.cloudflare.com/cache/), or [Spectrum](https://developers.cloudflare.com/spectrum/) can leverage the [service binding API endpoints](https://developers.cloudflare.com/api/resources/addressing/subresources/prefixes/subresources/service%5Fbindings/) to selectively route traffic through the CDN [1](#user-content-fn-1) or Spectrum [2](#user-content-fn-2) pipelines on a per-IP address basis. This means: * You can upgrade individual IPs within a Magic Transit prefix to either a CDN IP or a Spectrum IP. For example, if you have a Magic Transit prefix `203.0.113.0/24`, you can upgrade `203.0.113.1` to CDN and `203.0.113.2` to Spectrum. * You can upgrade individual IPs within a CDN prefix to a Spectrum IP. For example, if you have a CDN prefix `203.0.113.0/24`, you can upgrade `203.0.113.1` to Spectrum. * You can upgrade individual IPs within a Spectrum prefix to a CDN IP. For example, if you have a Spectrum prefix `203.0.113.0/24`, you can upgrade `203.0.113.1` to CDN. Refer to [Magic Transit with CDN](https://developers.cloudflare.com/byoip/service-bindings/magic-transit-with-cdn/) or [CDN and Spectrum](https://developers.cloudflare.com/byoip/service-bindings/cdn-and-spectrum/) for detailed guidance. Warning Magic Transit customers must ensure that their contract includes CDN and/or Spectrum according to their needs. ### CDN (Cache) When a service binding of type `CDN` is applied, once the change has propagated across Cloudflare's global network (four to six hours), any HTTP requests are directed into the CDN pipeline for Layer 7 processing. ### Spectrum When a service binding of type `Spectrum` is applied, once the change has propagated across Cloudflare's global network (four to six hours), any TCP/HTTP requests are directed into the Spectrum pipeline for Layer 4 or Layer 7 processing. UDP applications Spectrum UDP applications are [not supported](https://developers.cloudflare.com/spectrum/reference/limitations/#udp) when using Spectrum with BYOIP. ### Magic Transit Note Magic Transit can only be used as default binding, spanning across your entire prefix. You can then add CDN or Spectrum for smaller subnets but not the other way around. The entire BYOIP prefix is primarily announced for Magic Transit, providing layer 3 DDoS protection and acceleration. Traffic not explicitly bound to CDN will flow through Magic Transit. Also, traffic egressing to an IP in the prefix will always go to Magic Transit, even if there is an overlapping binding for CDN or Spectrum. This allows customers who want to use the same IP as ingress IP and as origin IP to do so. flowchart LR accTitle: Cloudflare as a reverse proxy accDescr: Diagram showing Cloudflare's network between clients and the origin server. A[Client] --ingress--> B((Cloudflare))--egress--> C[(Origin server)] When adding a service binding for a given IP address, it must be either a CDN service binding or a Spectrum service binding. It is not possible (or necessary) to bind both services. ### CDN egress [Dedicated CDN Egress IPs](https://developers.cloudflare.com/smart-shield/configuration/dedicated-egress-ips/) (formerly known as Aegis) is only available for Enterprise. If you are interested, reach out to your account team. Also note that a single BYOIP prefix can be used for either CDN ingress or CDN egress, but not both. ## Tutorials * [ Use BYOIP with Magic Transit and CDN ](https://developers.cloudflare.com/byoip/service-bindings/magic-transit-with-cdn/) * [ Use BYOIP with CDN and Spectrum ](https://developers.cloudflare.com/byoip/service-bindings/cdn-and-spectrum/) ## Footnotes 1. Layer 7 HTTP-based [↩](#user-content-fnref-1) 2. Layer 4 or Layer 7 HTTP with custom ports [↩](#user-content-fnref-2) ```json {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"item":{"@id":"/directory/","name":"Directory"}},{"@type":"ListItem","position":2,"item":{"@id":"/byoip/","name":"BYOIP"}},{"@type":"ListItem","position":3,"item":{"@id":"/byoip/service-bindings/","name":"IP address service bindings"}}]} ``` --- --- title: Use BYOIP with CDN and Spectrum description: Cloudflare allows users to use their Cloudflare prefix to route traffic to a different service. Service bindings must be created on the parent account of the prefix. image: https://developers.cloudflare.com/core-services-preview.png --- > Documentation Index > Fetch the complete documentation index at: https://developers.cloudflare.com/byoip/llms.txt > Use this file to discover all available pages before exploring further. [Skip to content](#%5Ftop) ### Tags [ DNS ](https://developers.cloudflare.com/search/?tags=DNS)[ Integration ](https://developers.cloudflare.com/search/?tags=Integration) # Use BYOIP with CDN and Spectrum With [service bindings](https://developers.cloudflare.com/byoip/service-bindings/), CDN[1](#user-content-fn-1) customers using BYOIP can take the same prefix they have onboarded to Cloudflare and use it to selectively route traffic on a per-IP address basis to [Spectrum](https://developers.cloudflare.com/spectrum/)[2](#user-content-fn-2), or vice versa. This means: * You can upgrade individual IPs within a CDN prefix to a Spectrum IP. For example, if you have a CDN prefix 203.0.113.0/24, you can upgrade 203.0.113.1 to Spectrum. * You can upgrade individual IPs within a Spectrum prefix to a CDN IP. For example, if you have a Spectrum prefix 203.0.113.0/24, you can upgrade 203.0.113.1 to CDN. This guide will use the first example and consider a prefix that was onboarded to the CDN, with a few IPs upgraded to Spectrum. ## Before you begin Cloudflare **strongly** recommends implementing service bindings through an **aggregated** CIDR block, as it is more efficient than adding discrete bindings for non-contiguous CIDR blocks. Example **CDN protected prefix:** `203.0.113.0/24` **IPs to upgrade to Spectrum:** `203.0.113.16` `203.0.113.17` `203.0.113.18` `203.0.113.19` `203.0.113.20` `203.0.113.21` `203.0.113.22` `203.0.113.23` Add one discrete Spectrum service binding for `203.0.113.16` with a `/29` netmask. Once a service binding is created (or deleted), it will take **four to six hours** to propagate across Cloudflare's global network. Services for the IP addresses in scope will likely be disrupted during this window. Note This guide assumes that the prefix is tied to a single Cloudflare account that has both CDN and Spectrum properties. If you are using [prefix delegations](https://developers.cloudflare.com/byoip/concepts/prefix-delegations/), the service bindings must be [created](#2-create-service-bindings) on the parent account. --- ## Prepare your IPs ### 1\. Get account information 1. Log in to your Cloudflare account and get your [account ID](https://developers.cloudflare.com/fundamentals/account/find-account-and-zone-ids/) and [authentication key or token](https://developers.cloudflare.com/fundamentals/api/get-started/). If using an [API token](https://developers.cloudflare.com/fundamentals/api/get-started/create-token/), the permissions should include `Account` \- `IP Prefixes` \- `Edit`. 2. Make a `GET` request to the [List Services](https://developers.cloudflare.com/api/resources/addressing/subresources/services/methods/list/) endpoint and take note of the `id` associated with the Spectrum service. 3. Use the [List Prefixes](https://developers.cloudflare.com/api/resources/addressing/subresources/prefixes/methods/list/) endpoint and take note of the `id` associated with the prefix (`cidr`) you will configure. At this point, continuing the [example](#before-you-begin), you should have a mapping similar to the following: | Variables | Description | | ------------- | ----------------------------------------------------------------------------------------------------------- | | {service\_id} | The ID of the Spectrum service within Cloudflare. Example: 969xxxxxxxx000xxx0000000x00001bf | | {prefix\_id} | The ID of the CDN prefix (203.0.113.0/24) you want to configure. Example: 6b25xxxxxxx000xxx0000000x0000cfc | 1. To confirm you currently have a CDN service binding and that it spans across your entire prefix, make a `GET` request to the [List Service Bindings](https://developers.cloudflare.com/api/resources/addressing/subresources/prefixes/subresources/service%5Fbindings/methods/list/) endpoint. Replace the `{prefix_id}` in the URI path by the actual prefix ID you got from the previous step. Required API token permissions At least one of the following [token permissions](https://developers.cloudflare.com/fundamentals/api/reference/permissions/)is required: * `IP Prefixes: Write` * `IP Prefixes: Read` List Service Bindings ``` curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/addressing/prefixes/$PREFIX_ID/bindings" \ --request GET \ --header "X-Auth-Email: $CLOUDFLARE_EMAIL" \ --header "X-Auth-Key: $CLOUDFLARE_API_KEY" ``` ### 2\. Create service bindings Caution Once a service binding is created (or deleted), it will take **four to six hours** to propagate across Cloudflare's global network. Services for the IP addresses in scope will likely be disrupted during this window. 1. Make a `POST` request to the [Create service binding](https://developers.cloudflare.com/api/resources/addressing/subresources/prefixes/subresources/service%5Fbindings/methods/create/) endpoint, indicating the IP address you want to bind to Spectrum. Specify the **corresponding network mask** as needed. Continuing the example, `203.0.113.100/32` designates an IP address that is within the CDN prefix `203.0.113.0/24`. Replace the `{prefix_id}` in the URI with your prefix ID from previous steps. Within the request body, the `cidr` value should correspond to the IP address or subnet that you are configuring for use with Spectrum. Required API token permissions At least one of the following [token permissions](https://developers.cloudflare.com/fundamentals/api/reference/permissions/)is required: * `IP Prefixes: Write` Create Service Binding ``` curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/addressing/prefixes/$PREFIX_ID/bindings" \ --request POST \ --header "X-Auth-Email: $CLOUDFLARE_EMAIL" \ --header "X-Auth-Key: $CLOUDFLARE_API_KEY" \ --json '{ "cidr": "203.0.113.100/32", "service_id": "" }' ``` In the response body, the initial provisioning state should be `provisioning`. ``` { "errors": [], "messages": [], "success": true, "result": { "cidr": "203.0.113.100/32", "id": "", "provisioning": { "state": "provisioning" }, "service_id": "", "service_name": "" } } ``` You can periodically check the service binding status using the [List Service Bindings](https://developers.cloudflare.com/api/resources/addressing/subresources/prefixes/subresources/service%5Fbindings/methods/list/) endpoint. ### 3\. Verify all service bindings After the propagation time (four to six hours), the [List Service Bindings](https://developers.cloudflare.com/api/resources/addressing/subresources/prefixes/subresources/service%5Fbindings/methods/get/) endpoint should return all service bindings that are part of the prefix - in this case, CDN and Spectrum. Required API token permissions At least one of the following [token permissions](https://developers.cloudflare.com/fundamentals/api/reference/permissions/)is required: * `IP Prefixes: Write` * `IP Prefixes: Read` List Service Bindings ``` curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/addressing/prefixes/$PREFIX_ID/bindings" \ --request GET \ --header "X-Auth-Email: $CLOUDFLARE_EMAIL" \ --header "X-Auth-Key: $CLOUDFLARE_API_KEY" ``` --- ## Set up your Cloudflare services ### CDN If you already use BYOIP with CDN, you might be able to skip this step. However, if you are using this guide to upgrade a few IPs from a Spectrum prefix to the CDN, consider the following sections on [address maps](#address-maps) and [DNS records](#dns-records). Note As described below, address maps and DNS records do not apply to Spectrum. To set up your Spectrum application with BYOIP, refer to [Spectrum](#spectrum). #### Address maps Use [address maps](https://developers.cloudflare.com/byoip/address-maps/) to specify which IPs should be used by Cloudflare in DNS responses when a record is [proxied](https://developers.cloudflare.com/dns/proxy-status/). You can choose between two different scopes: * Account-level: uses the address map for all proxied DNS records across all of the zones within an account. * Zone-level: uses the address map for all proxied DNS records within a zone. Note If you need to map only specific subdomains (and not all proxied DNS records) to specific IP addresses, you can use a [Subdomain setup](https://developers.cloudflare.com/dns/zone-setups/subdomain-setup/). * [ Dashboard ](#tab-panel-4718) * [ API ](#tab-panel-4719) 1. In the Cloudflare dashboard, go to the **Address Maps** page. [ Go to **Address maps** ](https://dash.cloudflare.com/?to=/:account/ip-addresses/proxy-ips) 2. Select **Create an address map**. 3. Choose the scope of the address map. 4. Add the zones and IP addresses that you want to map. 5. Name your address map. 6. Review the information and select **Save and Deploy**. Use the [Create Address Map](https://developers.cloudflare.com/api/resources/addressing/subresources/address%5Fmaps/methods/create/) endpoint. Make sure you have the correct Key/Token and permissions. #### DNS records While the DNS record proxy status and address map will determine how Cloudflare's authoritative DNS responds to requests for your hostnames, the IP addresses specified in `A`/`AAAA` records will determine [how Cloudflare reaches the configured origin](https://developers.cloudflare.com/fundamentals/concepts/how-cloudflare-works/#cloudflare-as-a-reverse-proxy). Note As you create the necessary DNS records, [Total TLS](https://developers.cloudflare.com/ssl/edge-certificates/additional-options/total-tls/) can help making sure that you have SSL/TLS certificates in place for all your hostnames. * [ Dashboard ](#tab-panel-4720) * [ API ](#tab-panel-4721) To create a DNS record in the dashboard: 1. In the Cloudflare dashboard, go to the **DNS Records** page. [ Go to **Records** ](https://dash.cloudflare.com/?to=/:account/:zone/dns/records) 2. Select **Add record**. 3. Choose an address (`A`/`AAAA`) [record type](https://developers.cloudflare.com/dns/manage-dns-records/reference/dns-record-types/). 4. Complete the required fields, setting the **Proxy status** to **proxied**. 5. Select **Save**. To create records with the API, use a [POST request](https://developers.cloudflare.com/api/resources/dns/subresources/records/methods/create/). For field definitions, select a record type under the request body specification. Example | Type | Name | IP address | Proxy status | TTL | | ---- | ---- | ------------- | ------------ | ---- | | A | www | 203.0.113.150 | Proxied | Auto | At this point, if an address map for a zone `example.com` specifies that Cloudflare should use `203.0.113.100` for proxied records and the above record exists in the same zone, you can expect the following: 1. Cloudflare responds to DNS requests for `www.example.com` with `203.0.113.100`. 2. Cloudflare proxies requests through the CDN and then routes the requests to the origin server `203.0.113.150`. 3. As the HTTP response egresses the Cloudflare network back to the client side, the source IP address of the response becomes `203.0.113.100` (the IP address that the HTTP request originally landed on). Note Having the same IP address as ingress IP (defined in the address map) and origin IP (listed in the DNS record) will not cause any loops. Example Assuming `203.0.113.100` was also the origin IP, the DNS record would look like the following: | Type | Name | IP address | Proxy status | TTL | | ---- | ---- | ------------- | ------------ | ---- | | A | www | 203.0.113.100 | Proxied | Auto | ### Spectrum UDP applications Spectrum UDP applications are [not supported](https://developers.cloudflare.com/spectrum/reference/limitations/#udp) when using Spectrum with BYOIP. Configuring Spectrum to use your own IP address is only possible via the [Cloudflare API](https://developers.cloudflare.com/api/resources/spectrum/). The `origin_direct` field takes the origin IP address, while `edge_ips` allows you to define which IP address from your BYOIP prefix Cloudflare should use to process requests for your Spectrum application. Required API token permissions At least one of the following [token permissions](https://developers.cloudflare.com/fundamentals/api/reference/permissions/)is required: * `Zone Settings Write` Create Spectrum application using a name for the origin ``` curl "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/spectrum/apps" \ --request POST \ --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \ --json '[ { "protocol": "tcp/22", "dns": { "type": "CNAME", "name": "ssh.example.com" }, "origin_direct": [ "tcp://192.0.2.1:22" ], "proxy_protocol": "off", "ip_firewall": true, "tls": "full", "edge_ips": { "type": "static", "ips": [ "203.0.113.18" ] }, "traffic_type": "direct" } ]' ``` --- ## (Optional) Add layer 7 functionality Leverage other features according to your needs. For example: * [Cache](https://developers.cloudflare.com/cache/) * [WAF custom rules](https://developers.cloudflare.com/waf/custom-rules/) * [Security analytics](https://developers.cloudflare.com/waf/analytics/security-analytics/) ## Footnotes 1. Layer 7 HTTP-based [↩](#user-content-fnref-1) 2. Layer 4 or Layer 7 HTTP with custom ports [↩](#user-content-fnref-2) ```json {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"item":{"@id":"/directory/","name":"Directory"}},{"@type":"ListItem","position":2,"item":{"@id":"/byoip/","name":"BYOIP"}},{"@type":"ListItem","position":3,"item":{"@id":"/byoip/service-bindings/","name":"IP address service bindings"}},{"@type":"ListItem","position":4,"item":{"@id":"/byoip/service-bindings/cdn-and-spectrum/","name":"Use BYOIP with CDN and Spectrum"}}]} ``` --- --- title: Use BYOIP with Magic Transit and CDN description: Service bindings allow BYOIP customers to selectively route traffic on a per-IP address basis to the CDN pipeline. It is important to note that traffic routed to the CDN pipeline is protected at Layers 3 and 4 by the inherent DDoS protection capabilities. image: https://developers.cloudflare.com/core-services-preview.png --- > Documentation Index > Fetch the complete documentation index at: https://developers.cloudflare.com/byoip/llms.txt > Use this file to discover all available pages before exploring further. [Skip to content](#%5Ftop) ### Tags [ DNS ](https://developers.cloudflare.com/search/?tags=DNS)[ Integration ](https://developers.cloudflare.com/search/?tags=Integration) # Use BYOIP with Magic Transit and CDN [Magic Transit](https://developers.cloudflare.com/magic-transit/) customers using BYOIP can also benefit from the performance, reliability, and security that Cloudflare offers for HTTP-based applications. [Service bindings](https://developers.cloudflare.com/byoip/service-bindings/) allow BYOIP customers to selectively route traffic on a per-IP address basis to the CDN pipeline (which includes [Cache](https://developers.cloudflare.com/cache/), [Web Application Firewall (WAF)](https://developers.cloudflare.com/waf/), and more). This guide covers using the Cloudflare API to configure Magic Transit with CDN. It is also possible to define service bindings to route traffic to the Spectrum pipeline selectively. Refer to [scope](https://developers.cloudflare.com/byoip/service-bindings/#scope) for the full list of possible configurations and other available guides. It is important to note that traffic routed to the CDN pipeline is protected at Layers 3 and 4 by the inherent DDoS protection capabilities native to the CDN pipeline. ## Before you begin * Make sure your contract includes CDN according to your needs. If you find any issues related to subscription when following the steps below, reach out to your account team. * Plan for what IPs will be used: Cloudflare **strongly** recommends implementing service bindings through an **aggregated** CIDR block, as it is more efficient than adding discrete bindings for non-contiguous CIDR blocks. Example **Magic Transit protected prefix:** `203.0.113.0/24` **IPs to upgrade to CDN:** `203.0.113.16` `203.0.113.17` `203.0.113.18` `203.0.113.19` `203.0.113.20` `203.0.113.21` `203.0.113.22` `203.0.113.23` Add one discrete CDN service binding for `203.0.113.16` with a `/29` netmask. Once a service binding is created (or deleted), it will take **four to six hours** to propagate across Cloudflare's global network. Services for the IP addresses in scope will likely be disrupted during this window. Note This guide assumes that the prefix is tied to a single Cloudflare account that has both Magic Transit and CDN properties. If you are using [prefix delegations](https://developers.cloudflare.com/byoip/concepts/prefix-delegations/), the service bindings must be [created](#2-create-service-bindings) on the parent account. ## 1\. Get account information 1. Log in to your Cloudflare account and get your [account ID](https://developers.cloudflare.com/fundamentals/account/find-account-and-zone-ids/) and [authentication key or token](https://developers.cloudflare.com/fundamentals/api/get-started/). If using an [API token](https://developers.cloudflare.com/fundamentals/api/get-started/create-token/), the permissions should include `Account` \- `IP Prefixes` \- `Edit`. 2. Make a `GET` request to the [List Services](https://developers.cloudflare.com/api/resources/addressing/subresources/services/methods/list/) endpoint and take note of the `id` associated with the CDN service. 3. Use the [List Prefixes](https://developers.cloudflare.com/api/resources/addressing/subresources/prefixes/methods/list/) endpoint and take note of the `id` associated with the prefix (`cidr`) you will configure. At this point, continuing the [example](#before-you-begin), you should have a mapping similar to the following: | Variables | Description | | ------------- | --------------------------------------------------------------------------------------------------------------------- | | {service\_id} | The ID of the CDN service within Cloudflare. Example: 969xxxxxxxx000xxx0000000x00001bf | | {prefix\_id} | The ID of the Magic Transit prefix (203.0.113.0/24) you want to configure. Example: 6b25xxxxxxx000xxx0000000x0000cfc | 1. To confirm you currently have a Magic Transit service binding and that it spans across your entire prefix, make a `GET` request to the [List Service Bindings](https://developers.cloudflare.com/api/resources/addressing/subresources/prefixes/subresources/service%5Fbindings/methods/list/) endpoint. Replace the `{prefix_id}` in the URI path by the actual prefix ID you got from the previous step. Required API token permissions At least one of the following [token permissions](https://developers.cloudflare.com/fundamentals/api/reference/permissions/)is required: * `IP Prefixes: Write` * `IP Prefixes: Read` List Service Bindings ``` curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/addressing/prefixes/$PREFIX_ID/bindings" \ --request GET \ --header "X-Auth-Email: $CLOUDFLARE_EMAIL" \ --header "X-Auth-Key: $CLOUDFLARE_API_KEY" ``` ## 2\. Create service bindings Caution Once a service binding is created (or deleted), it will take **four to six hours** to propagate across Cloudflare's global network. Services for the IP addresses in scope will likely be disrupted during this window. 1. Make a `POST` request to the [Create service binding](https://developers.cloudflare.com/api/resources/addressing/subresources/prefixes/subresources/service%5Fbindings/methods/create/) endpoint, indicating the IP address you want to bind to CDN. Specify the **corresponding network mask** as needed. Continuing the example, `203.0.113.100/32` designates an IP address that is within the Magic Transit prefix `203.0.113.0/24`. Replace the `{prefix_id}` in the URI with your prefix ID from previous steps. Within the request body, the `cidr` value should correspond to the IP address or subnet that you are configuring for use with CDN. Required API token permissions At least one of the following [token permissions](https://developers.cloudflare.com/fundamentals/api/reference/permissions/)is required: * `IP Prefixes: Write` Create Service Binding ``` curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/addressing/prefixes/$PREFIX_ID/bindings" \ --request POST \ --header "X-Auth-Email: $CLOUDFLARE_EMAIL" \ --header "X-Auth-Key: $CLOUDFLARE_API_KEY" \ --json '{ "cidr": "203.0.113.100/32", "service_id": "" }' ``` In the response body, the initial provisioning state should be `provisioning`. ``` { "errors": [], "messages": [], "success": true, "result": { "cidr": "203.0.113.100/32", "id": "", "provisioning": { "state": "provisioning" }, "service_id": "", "service_name": "" } } ``` You can periodically check the service binding status using the [List Service Bindings](https://developers.cloudflare.com/api/resources/addressing/subresources/prefixes/subresources/service%5Fbindings/methods/list/) endpoint. ## 3\. Create address maps Once you have configured your IPs to have CDN service, you can use [address maps](https://developers.cloudflare.com/byoip/address-maps/) to specify which IPs should be used by Cloudflare in DNS responses when a record is [proxied](https://developers.cloudflare.com/dns/proxy-status/). You can choose between two different scopes: * Account-level: uses the address map for all proxied DNS records across all of the zones within an account. * Zone-level: uses the address map for all proxied DNS records within a zone. Tip If you need to map only specific subdomains (and not all proxied DNS records) to specific IP addresses, you can use a zone on [Subdomain setup](https://developers.cloudflare.com/dns/zone-setups/subdomain-setup/). * [ Dashboard ](#tab-panel-4722) * [ API ](#tab-panel-4723) 1. In the Cloudflare dashboard, go to the **Address Maps** page. [ Go to **Address maps** ](https://dash.cloudflare.com/?to=/:account/ip-addresses/proxy-ips) 2. Select **Create an address map**. 3. Choose the scope of the address map. 4. Add the zones and IP addresses that you want to map. 5. Name your address map. 6. Review the information and select **Save and Deploy**. Use the [Create Address Map](https://developers.cloudflare.com/api/resources/addressing/subresources/address%5Fmaps/methods/create/) endpoint. Make sure you have the correct Key/Token and permissions. ## 4\. Create DNS records * [ Dashboard ](#tab-panel-4724) * [ API ](#tab-panel-4725) To create a DNS record in the dashboard: 1. In the Cloudflare dashboard, go to the **DNS Records** page. [ Go to **Records** ](https://dash.cloudflare.com/?to=/:account/:zone/dns/records) 2. Select **Add record**. 3. Choose an address (`A`/`AAAA`) [record type](https://developers.cloudflare.com/dns/manage-dns-records/reference/dns-record-types/). 4. Complete the required fields, setting the **Proxy status** to **proxied**. 5. Select **Save**. To create records with the API, use a [POST request](https://developers.cloudflare.com/api/resources/dns/subresources/records/methods/create/). For field definitions, select a record type under the request body specification. Tip As you create the necessary DNS records, [Total TLS](https://developers.cloudflare.com/ssl/edge-certificates/additional-options/total-tls/) can help making sure that you have SSL/TLS certificates in place for all your hostnames. While the DNS record proxy status and address map will determine how Cloudflare's authoritative DNS responds to requests for your hostnames, the IP addresses specified in `A`/`AAAA` records will determine [how Cloudflare reaches the configured origin](https://developers.cloudflare.com/fundamentals/concepts/how-cloudflare-works/#cloudflare-as-a-reverse-proxy). Example | Type | Name | IP address | Proxy status | TTL | | ---- | ---- | ------------- | ------------ | ---- | | A | www | 203.0.113.150 | Proxied | Auto | At this point, if an address map for a zone `example.com` specifies that Cloudflare should use `203.0.113.100` for proxied records and the above record exists in the same zone, you can expect the following: 1. Cloudflare responds to DNS requests with `203.0.113.100`. 2. Cloudflare proxies requests through the CDN and then routes the requests via [GRE](https://developers.cloudflare.com/magic-transit/reference/gre-ipsec-tunnels/) or [CNI](https://developers.cloudflare.com/magic-transit/network-interconnect/) to the origin server `203.0.113.150` (which is within the Magic Transit protected prefix). 3. Depending on whether Magic Transit is implemented with [direct server return model or with Magic Transit egress](https://developers.cloudflare.com/magic-transit/how-to/configure-tunnel-endpoints/#bidirectional-vs-unidirectional-health-checks), the origin server responds back to Cloudflare either: * Directly over the Internet in a Magic Transit direct server return model * Back through the Magic GRE tunnel(s) in a Magic Transit egress model 4. As the HTTP response egresses the Cloudflare network back to the client side, the source IP address of the response becomes `203.0.113.100` (the IP address that the HTTP request originally landed on). Note Having the same IP address as ingress IP (defined in the address map) and origin IP (listed in the DNS record) will not cause any loops. Example Assuming `203.0.113.100` was also the origin IP, the DNS record would look like the following: | Type | Name | IP address | Proxy status | TTL | | ---- | ---- | ------------- | ------------ | ---- | | A | www | 203.0.113.100 | Proxied | Auto | ## 5\. (Optional) Add layer 7 functionality Leverage other features according to your needs. For example: * [Cache](https://developers.cloudflare.com/cache/) * [WAF custom rules](https://developers.cloudflare.com/waf/custom-rules/) * [Security analytics](https://developers.cloudflare.com/waf/analytics/security-analytics/) ```json {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"item":{"@id":"/directory/","name":"Directory"}},{"@type":"ListItem","position":2,"item":{"@id":"/byoip/","name":"BYOIP"}},{"@type":"ListItem","position":3,"item":{"@id":"/byoip/service-bindings/","name":"IP address service bindings"}},{"@type":"ListItem","position":4,"item":{"@id":"/byoip/service-bindings/magic-transit-with-cdn/","name":"Use BYOIP with Magic Transit and CDN"}}]} ``` --- --- title: Route Leak Detection description: Detect unauthorized advertisement of your IP prefixes. image: https://developers.cloudflare.com/core-services-preview.png --- > Documentation Index > Fetch the complete documentation index at: https://developers.cloudflare.com/byoip/llms.txt > Use this file to discover all available pages before exploring further. [Skip to content](#%5Ftop) # Route Leak Detection Route Leak Detection protects your routes on the Internet by notifying you when your traffic is routed somewhere it should not go, which could indicate a possible attack. Route Leak Detection also reduces the amount of time needed to mitigate leaks by providing you with timely notifications. Cloudflare detects route leaks by using several sources of routing data to create a synthesis of how the Internet sees routes to BYOIP users. Cloudflare then watches these views to track any sudden changes that occur on the Internet. If the changes can be correlated to actions Cloudflare has taken, no further action is required. However, if changes have not been made, Cloudflare notifies you to inform you that your routes and users may be at risk. ## Enable Route Leak Detection Route Leak Detection Alert **Who is it for?** [BYOIP customers](https://developers.cloudflare.com/byoip/) who want to receive a notification when their prefixes are advertised in places they should not be. **Other options / filters** None. **Included with** Purchase of BYOIP. **What should you do if you receive one?** Confirm your traffic is healthy. Reach out to your transit providers to ensure you are behaving as expected and ask them to follow up with any providers accepting the unauthorized routes. You must be a user who has brought your own IP address to Cloudflare, which includes Magic Transit, Spectrum, and WAF users. Only prefixes advertised by Cloudflare qualify for Route Leak Detection. 1. In the Cloudflare dashboard, go to the **Notifications** page. [ Go to **Notifications** ](https://dash.cloudflare.com/?to=/:account/notifications) 2. Select **Add**. 3. Locate **Route Leak Detection** from the list > **Select**. 4. Enter a name and description for the notification. 5. Enter one or more email addresses to receive the notifications. 6. Select **Save**. ```json {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"item":{"@id":"/directory/","name":"Directory"}},{"@type":"ListItem","position":2,"item":{"@id":"/byoip/","name":"BYOIP"}},{"@type":"ListItem","position":3,"item":{"@id":"/byoip/route-leak-detection/","name":"Route Leak Detection"}}]} ``` --- --- title: Troubleshooting description: Review common troubleshooting scenarios for BYOIP. image: https://developers.cloudflare.com/core-services-preview.png --- > Documentation Index > Fetch the complete documentation index at: https://developers.cloudflare.com/byoip/llms.txt > Use this file to discover all available pages before exploring further. [Skip to content](#%5Ftop) ### Tags [ Debugging ](https://developers.cloudflare.com/search/?tags=Debugging) # Troubleshooting The following topics are useful for troubleshooting BYOIP issues. ## uRPF filtering and packet loss Routers receive IP packets and forward the packets to the destination IP address. Unicast Reverse Path Forwarding (uRPF) is a security feature that can prevent spoofing attacks. uRPF operates under two modes: strict and loose mode. Under **strict mode**, the router performs two checks on incoming packets to look for a matching entry in the source routing table and to determine whether the interface that received the packet can be used to reach the source. If the incoming IP packets pass both checks, the packets are forwarded; if the checks do not pass, the packets are dropped. When uRPF is set to loose mode, the router performs a single check when it receives an IP packet to look for a source's matching entry in the routing table. If you are experiencing packet loss as a result of an upstream ISP implementing uRPF filtering, contact your ISP and request the link be set to **loose mode**. ## Non-SNI support Currently, BYOIP cannot be used with [legacy custom certificates](https://developers.cloudflare.com/ssl/edge-certificates/custom-certificates/uploading/) to support [non-SNI](https://developers.cloudflare.com/ssl/reference/browser-compatibility/#non-sni-support) requests. Instead, you can use Address Maps to set a default SNI for IPs on your account or zone. Refer to [Setup](https://developers.cloudflare.com/byoip/address-maps/setup/#non-sni-support) for further guidance. ## Self-serve onboarding API errors When onboarding BYOIP prefixes via the API, you may encounter the following errors: | 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. | | 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](https://developers.cloudflare.com/byoip/service-bindings/magic-transit-with-cdn/). ```json {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"item":{"@id":"/directory/","name":"Directory"}},{"@type":"ListItem","position":2,"item":{"@id":"/byoip/","name":"BYOIP"}},{"@type":"ListItem","position":3,"item":{"@id":"/byoip/troubleshooting/","name":"Troubleshooting"}}]} ``` --- --- title: Troubleshoot prefix validation description: Resolve prefix validation errors during BYOIP onboarding. image: https://developers.cloudflare.com/core-services-preview.png --- > Documentation Index > Fetch the complete documentation index at: https://developers.cloudflare.com/byoip/llms.txt > Use this file to discover all available pages before exploring further. [Skip to content](#%5Ftop) # Troubleshoot prefix validation 1. Use the [Prefix Details endpoint](https://developers.cloudflare.com/api/resources/addressing/subresources/prefixes/methods/get/) to check if any issues were found during validation. Required API token permissions At least one of the following [token permissions](https://developers.cloudflare.com/fundamentals/api/reference/permissions/)is required: * `Magic Transit Read` * `Magic Transit Write` * `IP Prefixes: Write` * `IP Prefixes: Read` * `IP Prefixes: BGP On Demand Write` * `IP Prefixes: BGP On Demand Read` Prefix Details ``` curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/addressing/prefixes/$PREFIX_ID" \ --request GET \ --header "X-Auth-Email: $CLOUDFLARE_EMAIL" \ --header "X-Auth-Key: $CLOUDFLARE_API_KEY" ``` Response ``` "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, "ownership_validation_token": "", "delegate_loa_creation" : true, "irr_validation_state": "valid", "rpki_validation_state": "valid", "ownership_validation_state": "missing", } ``` 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. * Information in the IRR and ROA records should meet the [onboarding prerequisites](https://developers.cloudflare.com/byoip/get-started/#before-you-begin). * [Ownership validation](https://developers.cloudflare.com/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. 3. After applying the necessary changes, use the Validate Prefix endpoint to trigger the validation checks. Required API token permissions At least one of the following [token permissions](https://developers.cloudflare.com/fundamentals/api/reference/permissions/)is required: * `Magic Transit Write` * `IP Prefixes: Write` Validate Prefix ``` curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/addressing/prefixes/$PREFIX_ID/validate" \ --request POST \ --header "X-Auth-Email: $CLOUDFLARE_EMAIL" \ --header "X-Auth-Key: $CLOUDFLARE_API_KEY" ``` ```json {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"item":{"@id":"/directory/","name":"Directory"}},{"@type":"ListItem","position":2,"item":{"@id":"/byoip/","name":"BYOIP"}},{"@type":"ListItem","position":3,"item":{"@id":"/byoip/troubleshooting/","name":"Troubleshooting"}},{"@type":"ListItem","position":4,"item":{"@id":"/byoip/troubleshooting/prefix-validation/","name":"Troubleshoot prefix validation"}}]} ``` --- --- title: Glossary description: Definitions for terms used across BYOIP documentation. image: https://developers.cloudflare.com/core-services-preview.png --- > Documentation Index > Fetch the complete documentation index at: https://developers.cloudflare.com/byoip/llms.txt > Use this file to discover all available pages before exploring further. [Skip to content](#%5Ftop) # Glossary Review the definitions for terms used across Cloudflare's BYOIP documentation. | Term | Definition | | ----------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | address map | A data structure enabling customers with BYOIP prefixes or account-level static IPs to specify which IP addresses should be mapped to DNS records when they are proxied through Cloudflare. | | autonomous system numbers (ASNs) | A large network or group of networks that has a unified routing policy. Every computer or device that connects to the Internet is connected to an autonomous system. | | Border Gateway Protocol (BGP) | The routing protocol for the Internet, which is responsible for picking the most efficient routes to deliver Internet traffic. | | Internet Routing Registry (IRR) | A globally distributed database of routing information which contains announced routes and routing policies in a common format. Network operators use this information, as well as [RPKI](https://developers.cloudflare.com/byoip/concepts/route-filtering-rpki/), to configure backbone routers. | | Resource Public Key Infrastructure (RPKI) | A cryptographic method of signing records that associate a route with an originating autonomous system number. | | Route Origin Authorization (ROA) | The RPKI-signed object that states an autonomous system is authorized to originate a particular IP address prefix or set of prefixes. | | Unicast Reverse Path Forwarding (uRPF) | A security feature that can prevent spoofing attacks. | ```json {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"item":{"@id":"/directory/","name":"Directory"}},{"@type":"ListItem","position":2,"item":{"@id":"/byoip/","name":"BYOIP"}},{"@type":"ListItem","position":3,"item":{"@id":"/byoip/glossary/","name":"Glossary"}}]} ``` --- --- title: Changelog description: Track the latest updates and changes to BYOIP features. image: https://developers.cloudflare.com/core-services-preview.png --- > Documentation Index > Fetch the complete documentation index at: https://developers.cloudflare.com/byoip/llms.txt > Use this file to discover all available pages before exploring further. [Skip to content](#%5Ftop) # Changelog [ Subscribe to RSS ](https://developers.cloudflare.com/byoip/changelog/index.xml) ## 2024-07-02 **Address Maps for BYOIP and Static IPs** Address Maps is available via [API](https://developers.cloudflare.com/api/resources/addressing/subresources/address%5Fmaps/methods/list/) and via [dashboard](https://dash.cloudflare.com/?to=/:account/ip-addresses/proxy-ips). Address Maps allows customers with BYOIP prefixes or account-level Static IPs to specify which IP addresses should be mapped to DNS records when they are proxied through Cloudflare. Refer to the [documentation](https://developers.cloudflare.com/byoip/address-maps/) for details. ```json {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"item":{"@id":"/directory/","name":"Directory"}},{"@type":"ListItem","position":2,"item":{"@id":"/byoip/","name":"BYOIP"}},{"@type":"ListItem","position":3,"item":{"@id":"/byoip/changelog/","name":"Changelog"}}]} ``` --- --- title: Dynamic advertisement description: Advertise and withdraw IP prefixes on demand through the API or dashboard. image: https://developers.cloudflare.com/core-services-preview.png --- > Documentation Index > Fetch the complete documentation index at: https://developers.cloudflare.com/byoip/llms.txt > Use this file to discover all available pages before exploring further. [Skip to content](#%5Ftop) # Dynamic advertisement Dynamic advertisement allows you to control when Cloudflare announces your IP prefixes via BGP. When a prefix is advertised, Cloudflare announces it to the Internet so that traffic destined for those IPs can be routed to Cloudflare. When a prefix is withdrawn, Cloudflare stops announcing it — traffic will then follow whatever other BGP routes exist for that prefix. You can advertise and withdraw prefixes on demand using the [Cloudflare API](https://developers.cloudflare.com/byoip/concepts/dynamic-advertisement/best-practices/#via-the-api) or the [IP Prefixes page](https://developers.cloudflare.com/byoip/concepts/dynamic-advertisement/best-practices/#via-the-cloudflare-dashboard) in the Cloudflare dashboard. Enabling advertisement typically takes two to seven minutes, and disabling advertisement takes approximately 15 minutes. When using the API, you can authorize the call with your email and API key or create a service token for this purpose. A successful API response indicates the service registered the request. Both the API and the Cloudflare dashboard support [prefix delegations](https://developers.cloudflare.com/byoip/concepts/prefix-delegations/), which allow other Cloudflare accounts to interact with your prefix. The effect of a delegation is service-specific. ```json {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"item":{"@id":"/directory/","name":"Directory"}},{"@type":"ListItem","position":2,"item":{"@id":"/byoip/","name":"BYOIP"}},{"@type":"ListItem","position":3,"item":{"@id":"/byoip/concepts/","name":"Concepts"}},{"@type":"ListItem","position":4,"item":{"@id":"/byoip/concepts/dynamic-advertisement/","name":"Dynamic advertisement"}}]} ``` --- --- title: Best practices description: Best practices for managing dynamic IP prefix advertisement. image: https://developers.cloudflare.com/core-services-preview.png --- > Documentation Index > Fetch the complete documentation index at: https://developers.cloudflare.com/byoip/llms.txt > Use this file to discover all available pages before exploring further. [Skip to content](#%5Ftop) # Best practices ## Prerequisites To prevent issues and simplify the advertisement process during an attack scenario, complete the following tasks. * Assign appropriate user roles. Ensure that users assigned to manage the status of IP prefix advertisement have the **Administrator** or **Super Administrator** role in your Cloudflare account. For more information, refer to [Setting up Multi-user accounts on Cloudflare](https://developers.cloudflare.com/fundamentals/manage-members/). * Get a list of the prefix IDs that you want to manage. Maintain a list of Cloudflare prefix IDs to simplify dynamic advertisement management and operations. You can [obtain prefix IDs](#obtain-prefix-ids) via the Cloudflare dashboard or use the [list prefixes](https://developers.cloudflare.com/api/resources/addressing/subresources/prefixes/methods/list/) operation in the Cloudflare API. Refer to these prefix IDs when managing prefix advertisement. ## Enable prefix advertisement You can avoid latency and the possibility of dropped routes by enabling prefix advertisement from Cloudflare before you withdraw the advertisement from your data center. 1. Refer to [configure dynamic advertisement](#configure-dynamic-advertisement). This operation requires your account ID, prefix IDs, and API key. 2. Verify the advertisement using a looking glass of your choice, such as [Hurricane Electric Internet Services ↗](https://lg.he.net/). Use the Cloudflare ASN (`13335`) to track the advertisement route. 3. Remove the prefix advertisement that originates from your data center. Note If you do not remove the advertisement from your data center, some of your traffic may not route through Cloudflare for protection, depending on which routes your ISP prefers. If you want to continue advertising from your data center while using [Magic Transit](https://developers.cloudflare.com/magic-transit/), one option is to advertise a less specific route and have Cloudflare advertise more specific routes. Enablement takes approximately five to seven minutes. ## Disable or withdraw prefix advertisement 1. Add the prefix advertisement to your data center. 2. (Optional) Verify the advertisement using a looking glass of your choice, such as [Hurricane Electric Internet Services ↗](https://lg.he.net/). 3. Refer to [configure dynamic advertisement](#configure-dynamic-advertisement). This operation requires your account ID, prefix IDs, and API key. Disablement takes approximately 15 minutes. ## Configure dynamic advertisement ### Via the Cloudflare dashboard 1. Log in to your [Cloudflare dashboard ↗](https://dash.cloudflare.com/) and select your account. 2. Go to **IP Addresses** \> **BYOIP Prefixes**. 3. Select **Edit** at the end of the entry. 4. From **Edit IP Prefixes**, select **Advertised** or **Withdrawn** under **Status**. 5. Select **Save** to commit your changes. After saving your changes, it takes between two to seven minutes to enable advertisement and approximately 15 minutes to disable or withdraw advertisement. ### Via the API To configure prefix advertisement with the Cloudflare API, use the [IP Address Management and Dynamic Advertisement](https://developers.cloudflare.com/api/resources/addressing/subresources/prefixes/subresources/advertisement%5Fstatus/methods/edit/) API. Most dynamic advertisement operations require that you supply the Cloudflare ID for any prefix you want to access with the Cloudflare API. The following section outlines how to obtain prefix IDs. ## Obtain prefix IDs * [ Dashboard ](#tab-panel-4714) * [ API ](#tab-panel-4715) 1. Log in to your [Cloudflare dashboard ↗](https://dash.cloudflare.com/) and select your account. 2. Go to **IP Addresses** \> **BYOIP Prefixes**. 3. Find the CIDR for which you want the prefix ID, and select the arrow next to it. 4. Under **Prefix ID**, select **Copy** to add the value to your clipboard. To obtain prefix IDs using the API, refer to the [list prefixes](https://developers.cloudflare.com/api/resources/addressing/subresources/prefixes/methods/list/) operation in the Cloudflare API. ```json {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"item":{"@id":"/directory/","name":"Directory"}},{"@type":"ListItem","position":2,"item":{"@id":"/byoip/","name":"BYOIP"}},{"@type":"ListItem","position":3,"item":{"@id":"/byoip/concepts/","name":"Concepts"}},{"@type":"ListItem","position":4,"item":{"@id":"/byoip/concepts/dynamic-advertisement/","name":"Dynamic advertisement"}},{"@type":"ListItem","position":5,"item":{"@id":"/byoip/concepts/dynamic-advertisement/best-practices/","name":"Best practices"}}]} ``` --- --- title: Internet Routing Registry (IRR) description: How Internet Routing Registry entries validate prefix ownership. image: https://developers.cloudflare.com/core-services-preview.png --- > Documentation Index > Fetch the complete documentation index at: https://developers.cloudflare.com/byoip/llms.txt > Use this file to discover all available pages before exploring further. [Skip to content](#%5Ftop) # Internet Routing Registry (IRR) The [Internet Routing Registry (IRR)](http://www.irr.net/index.html) is a globally distributed database of routing information which contains announced routes and routing policies in a common format. Network operators use this information, as well as [RPKI](https://developers.cloudflare.com/byoip/concepts/route-filtering-rpki/), to configure backbone routers. IRR entries serve as a public record of which networks are authorized to announce specific IP prefixes. When Cloudflare advertises your IP prefixes on your behalf, other networks check IRR records to verify that Cloudflare has permission to do so. Without accurate IRR entries, your traffic may not be properly routed on the Internet. The IRR consists of many individual [routing registries ↗](http://www.irr.net/docs/list.html), some managed by regional entities such as the American Registry for Internet Numbers (ARIN) and the Regional Internet Registry for Europe, Middle East and Central Asia (RIPE). Each routing registry contains IRR entries that provide information about IP prefixes and the [autonomous systems ↗](https://www.cloudflare.com/learning/network-layer/what-is-an-autonomous-system/) authorized to announce them. To announce your IP prefixes through Cloudflare, you must have accurate IRR entries for your prefixes and autonomous system numbers (ASNs). When you configure network infrastructure for services such as [Magic Transit](https://developers.cloudflare.com/magic-transit/about/), or before onboarding your IPs to Cloudflare, [verify your IRR entries](https://developers.cloudflare.com/byoip/concepts/irr-entries/best-practices/#verify-an-irr-entry). ```json {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"item":{"@id":"/directory/","name":"Directory"}},{"@type":"ListItem","position":2,"item":{"@id":"/byoip/","name":"BYOIP"}},{"@type":"ListItem","position":3,"item":{"@id":"/byoip/concepts/","name":"Concepts"}},{"@type":"ListItem","position":4,"item":{"@id":"/byoip/concepts/irr-entries/","name":"Internet Routing Registry (IRR)"}}]} ``` --- --- title: Manage IRR entries description: Create and maintain IRR entries for your IP prefixes. image: https://developers.cloudflare.com/core-services-preview.png --- > Documentation Index > Fetch the complete documentation index at: https://developers.cloudflare.com/byoip/llms.txt > Use this file to discover all available pages before exploring further. [Skip to content](#%5Ftop) # Manage IRR entries You must keep your [Internet Routing Registry (IRR)](https://developers.cloudflare.com/byoip/concepts/irr-entries/) entries up to date so that it is public information that Cloudflare has permission to advertise your prefix or prefixes, and to ensure that your traffic can be properly routed on the Internet. ## Configure an IRR entry You can add or update an IRR entry by following the directions of your routing registry. Each routing registry has its own set of instructions to configure an IRR entry. The recommended registries are AFRINIC, APNIC, ARIN, LACNIC, and RIPE. Refer to the table below for more information. | Route registry | URL | | -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | AFRINIC | [https://afrinic.net/internet-routing-registry#guide ↗](https://afrinic.net/internet-routing-registry#guide) | | APNIC | [https://www.apnic.net/manage-ip/apnic-services/routing-registry/ ↗](https://www.apnic.net/manage-ip/apnic-services/routing-registry/) | | ARIN | [https://www.arin.net/resources/manage/irr/quickstart/ ↗](https://www.arin.net/resources/manage/irr/quickstart/) | | LACNIC | [https://lacnic.zendesk.com/hc/articles/360038667154-What-are-a-route-and-a-route-6-objects ↗](https://lacnic.zendesk.com/hc/articles/360038667154-What-are-a-route-and-a-route-6-objects) | | RIPE | [https://www.ripe.net/manage-ips-and-asns/db/support/managing-route-objects-in-the-irr ↗](https://www.ripe.net/manage-ips-and-asns/db/support/managing-route-objects-in-the-irr) | ## Verify an IRR entry Verify your Internet Routing Registry (IRR) entries to ensure that the IP prefixes Cloudflare advertises for you match the correct autonomous system numbers (ASNs). Each IRR entry record must include the following information: * **Route**: Each IP prefix Cloudflare advertises for you. * **Origin ASN**: The Cloudflare ASN (AS13335) or your own ASN. * **Source**: The name of the routing registry (for example, ARIN). Add or update IRR entries when they meet any of these criteria: * The entry is missing. * The entry is incomplete or inaccurate — for example, when the route object does not show the correct origin. * The entry is complete but requires updating — for example, when they correspond to supernets but need to correspond to subnets used in Magic Transit. ### Subnet prefix verification Use [IRR Explorer ↗](https://irrexplorer.nlnog.net) to verify which ASN is associated with a subnet prefix. **Method:** Search for the subnet prefix IP, for example, `162.211.156.0/24`. **Output:** List of ASN numbers, source (route registry), and any associated errors. ### ASN verification Use [IRR Explorer ↗](https://irrexplorer.nlnog.net) to verify which prefixes are associated with an ASN. **Method:** Search for the ASN, for example `AS13335`. **Output:** List of prefixes, source, and any associated errors. ### WHOIS lookup Use WHOIS lookup to verify your origin ASN and routing data. **Method:** In a terminal, use the following `whois` command, replacing `` with your network prefix. The host `rr.ntt.net` is the primary server for the Global IP network. Terminal window ``` whois -h rr.ntt.net ``` **Output:** IRR route, origin, and source information. WHOIS output example The `` in the WHOIS output shows the correct IRR entry information for the specified network. In this example, the network prefix is `1.1.1.0/24`, and the output includes the route, origin ASN, and route registry, which in this example is APNIC: Example ``` user@xxt32z conduit-qs-config % whois -h rr.ntt.net 1.1.1.0/24 route: 1.1.1.0/24 descr: RPKI ROA for 1.1.1.0/24 remarks: This route object represents routing data retrieved from the RPKI remarks: The original data can be found here: https://rpki.gin.ntt.net/r/AS13335/1.1.1.0/24 remarks: This route object is the result of an automated RPKI-to-IRR conversion process. remarks: maxLength 24 origin: AS13335 mnt-by: MAINT-NTTCOM-RPKI changed: job@ntt.net 20200913 source: RPKI # Trust Anchor: apnic route: 1.1.1.0/24 origin: AS13335 descr: APNIC Research and Development 6 Cordelia St mnt-by: MAINT-AU-APNIC-GM85-AP last-modified: 2018-03-16T16:58:06Z source: APNIC ``` Note WHOIS output also shows the RPKI entry information for prefix IP addresses. When your WHOIS output only contains an RPKI entry, you must add the IRR entry. ```json {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"item":{"@id":"/directory/","name":"Directory"}},{"@type":"ListItem","position":2,"item":{"@id":"/byoip/","name":"BYOIP"}},{"@type":"ListItem","position":3,"item":{"@id":"/byoip/concepts/","name":"Concepts"}},{"@type":"ListItem","position":4,"item":{"@id":"/byoip/concepts/irr-entries/","name":"Internet Routing Registry (IRR)"}},{"@type":"ListItem","position":5,"item":{"@id":"/byoip/concepts/irr-entries/best-practices/","name":"Manage IRR entries"}}]} ``` --- --- title: Letter of Agency description: Letter of Agency requirements for onboarding IP prefixes to Cloudflare. image: https://developers.cloudflare.com/core-services-preview.png --- > Documentation Index > Fetch the complete documentation index at: https://developers.cloudflare.com/byoip/llms.txt > Use this file to discover all available pages before exploring further. [Skip to content](#%5Ftop) # Letter of Agency A Letter of Agency (LOA), sometimes referred to as a Letter of Authorization, is a document that authorizes Cloudflare to announce your IP prefixes on your behalf. Cloudflare's transit providers — the upstream networks that Cloudflare peers with to exchange routing information — require an LOA before they will accept the routes Cloudflare advertises for you. The LOA must specify the prefixes you are authorizing Cloudflare to announce and the autonomous system number (ASN) they will be announced under. You can use your own ASN or Cloudflare's ASN (AS13335). ## Requirements * For all future onboardings, if using the Cloudflare ASN, you must use AS13335\. Current customers who are already using Cloudflare's AS209242 do not need to make any changes and can continue using that ASN. * Cloudflare accepts digital signatures on an LOA, as long as it is clear who is signing the LOA. * An LOA is a formal document which should be on company letterhead and contain a wet signature. The Letter of Agency must be a PDF. Transit providers may reject the LOA if it is in a JPG or PNG format. ## Auto-generated LOA If you are onboarding your own IPs via the [self-serve flow](https://developers.cloudflare.com/byoip/get-started/), you can set `delegate_loa_creation` (in the [Add Prefix API call](https://developers.cloudflare.com/api/resources/addressing/subresources/prefixes/methods/create/)) to `true` . This will allow Cloudflare to automatically generate the LOA, speeding up the process. Auto-generated LOAs rely on [RPKI-signed ROAs](https://developers.cloudflare.com/byoip/concepts/route-filtering-rpki/) and [ownership validation](https://developers.cloudflare.com/byoip/get-started/#validate-prefix-ownership) checks. ## Template If you need to create an LOA document, you can use the template below. Letter of Agency template ``` [COMPANY LETTERHEAD] LETTER OF AGENCY ("LOA") [DATE] To whom it may concern: [COMPANY NAME] (the "Company") authorizes Cloudflare, Inc. with AS13335 to advertise the following IP address blocks / originating ASNs: - - - - - - - - - - - - - - - - - - - [Subnet & Originating ASN] [Subnet & Originating ASN] [Subnet & Originating ASN] - - - - - - - - - - - - - - - - - - - As a representative of the Company that is the owner of the aforementioned IP address blocks / originating ASNs, I hereby declare that I am authorized to sign this LOA on the Company’s behalf. Should you have any questions please email me at [E-MAIL ADDRESS], or call: [TELEPHONE NUMBER] Regards, [SIGNATURE] [NAME TYPED] [TITLE] [COMPANY NAME] [COMPANY ADDRESS] [COMPANY STAMP] ``` ```json {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"item":{"@id":"/directory/","name":"Directory"}},{"@type":"ListItem","position":2,"item":{"@id":"/byoip/","name":"BYOIP"}},{"@type":"ListItem","position":3,"item":{"@id":"/byoip/concepts/","name":"Concepts"}},{"@type":"ListItem","position":4,"item":{"@id":"/byoip/concepts/loa/","name":"Letter of Agency"}}]} ``` --- --- title: Prefix delegations description: Delegate IP prefixes to other Cloudflare accounts. image: https://developers.cloudflare.com/core-services-preview.png --- > Documentation Index > Fetch the complete documentation index at: https://developers.cloudflare.com/byoip/llms.txt > Use this file to discover all available pages before exploring further. [Skip to content](#%5Ftop) # Prefix delegations Prefix delegations allow a prefix owner (Account A) to grant another Cloudflare account (Account B) permission to use all or part of their BYOIP prefix. The original prefix remains managed by Account A, but Account B can use the delegated IPs with CDN services (including Cloudflare for SaaS) or Spectrum. Refer to [service bindings](https://developers.cloudflare.com/byoip/service-bindings/) for more information on the services an IP can be bound to. ## CDN CDN delegations allow you to use the IP(s) with [Address Maps](https://developers.cloudflare.com/byoip/address-maps/) or [Cloudflare for SaaS](https://developers.cloudflare.com/cloudflare-for-platforms/cloudflare-for-saas/) customers. Address Maps allows you to assign IPs either at the account level or zone level. In the Cloudflare for SaaS example, Account A is using BYOIP + CDN and Cloudflare for SaaS. Account A can validate and serve traffic for a custom hostname on any of the IPs in its prefix. If Account A delegates some or all of the prefix to Account B, Account B may also validate and serve traffic for custom hostnames on those IPs as well. This is very useful if you use Cloudflare for SaaS but manage different configurations in different accounts. All the accounts can use the IPs through a delegation. ## Spectrum If Account A delegates use of part or all of a prefix to Account B via a prefix delegation, Account B can also use the [Spectrum API](https://developers.cloudflare.com/spectrum/about/byoip/) with the IPs it was delegated access to. **Example:** Account A is the primary owner of prefix 1.2.3.0/24\. Account A delegates the use of 1.2.3.0/32 to Account B. Account B can now use the Spectrum API to create a Spectrum app with 1.2.3.0/32. ## API calls for prefix delegations API calls for delegations can be found at [Prefix Delegations](https://developers.cloudflare.com/api/resources/addressing/subresources/prefixes/subresources/delegations/methods/list/). Note The dashboard only supports delegation of an entire prefix. If you want to delegate less than the entire prefix, use the API. To bind an IP from one service to another, use the API. ## Configure prefix delegations 1. Log in to the [Cloudflare dashboard ↗](https://dash.cloudflare.com/) and select your account. 2. Go to **IP Addresses** \> **BYOIP Prefixes**. 3. Select **Edit** to modify a prefix. **Edit IP Prefixes** displays. 4. At the bottom of the page, select **Add Delegation**. Other accounts that your user is a part of will auto-load when you create the delegation. 5. Select **Save**. 6. Bind IPs to a service via the [Service Bindings API](https://developers.cloudflare.com/api/resources/addressing/subresources/prefixes/subresources/service%5Fbindings/) as needed. ```json {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"item":{"@id":"/directory/","name":"Directory"}},{"@type":"ListItem","position":2,"item":{"@id":"/byoip/","name":"BYOIP"}},{"@type":"ListItem","position":3,"item":{"@id":"/byoip/concepts/","name":"Concepts"}},{"@type":"ListItem","position":4,"item":{"@id":"/byoip/concepts/prefix-delegations/","name":"Prefix delegations"}}]} ``` --- --- title: Route filtering and RPKI description: How route filtering and RPKI protect against route hijacking. image: https://developers.cloudflare.com/core-services-preview.png --- > Documentation Index > Fetch the complete documentation index at: https://developers.cloudflare.com/byoip/llms.txt > Use this file to discover all available pages before exploring further. [Skip to content](#%5Ftop) # Route filtering and RPKI Network operators rely on [IRR records](https://developers.cloudflare.com/byoip/concepts/irr-entries/) to determine which autonomous systems (ASNs) are authorized to announce specific IP prefixes. Based on these records, operators configure filtering policies on their routers to block unauthorized announcements — a practice known as route filtering. However, IRR records alone are not cryptographically verified, which means they can be inaccurate or outdated. Resource Public Key Infrastructure (RPKI) addresses this gap by adding cryptographic validation. With RPKI, the association between an IP prefix and its authorized ASN is signed and verifiable, allowing network operators to confirm that a route announcement is legitimate before accepting it. When you register your prefix with one of the five Regional Internet Registries (RIRs)[1](#user-content-fn-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/). ## Footnotes 1. AFRINIC, APNIC, ARIN, LACNIC, and RIPE. [↩](#user-content-fnref-1) ```json {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"item":{"@id":"/directory/","name":"Directory"}},{"@type":"ListItem","position":2,"item":{"@id":"/byoip/","name":"BYOIP"}},{"@type":"ListItem","position":3,"item":{"@id":"/byoip/concepts/","name":"Concepts"}},{"@type":"ListItem","position":4,"item":{"@id":"/byoip/concepts/route-filtering-rpki/","name":"Route filtering and RPKI"}}]} ``` --- --- title: Static IPs description: Assign static IPs from your prefix to specific Cloudflare services. image: https://developers.cloudflare.com/core-services-preview.png --- > Documentation Index > Fetch the complete documentation index at: https://developers.cloudflare.com/byoip/llms.txt > Use this file to discover all available pages before exploring further. [Skip to content](#%5Ftop) # Static IPs When you use Cloudflare as a [reverse proxy](https://developers.cloudflare.com/fundamentals/concepts/how-cloudflare-works/), Cloudflare assigns shared [anycast IP addresses](https://developers.cloudflare.com/fundamentals/concepts/cloudflare-ip-addresses/) to proxied DNS records by default. These IPs can change at any time. Static IPs give you a set of specifically assigned Cloudflare IP addresses — Cloudflare will not change them without notifying you, and will typically only do so at your request. Static IPs are useful when you need to allowlist your IPs or communicate them to third parties in advance. Note Although BYOIP and static IPs are different offerings, both can be managed using [Address Maps](https://developers.cloudflare.com/byoip/address-maps/). Static IPs are allocated at the account level but can be assigned to a single zone, meaning multiple zones can share the same static IPs. You can specify which zones are mapped to your static IPs and control when the IPs for your zones change. ## Availability Static IPs are available as an add-on purchase for Enterprise plans. ## Check Static IPs You can find your leased Static IPs for CDN Ingress on the dashboard under [**Address space** \> **Leased IPs** ↗](https://dash.cloudflare.com/?to=/:account/ip-addresses/address-space). ```json {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"item":{"@id":"/directory/","name":"Directory"}},{"@type":"ListItem","position":2,"item":{"@id":"/byoip/","name":"BYOIP"}},{"@type":"ListItem","position":3,"item":{"@id":"/byoip/concepts/","name":"Concepts"}},{"@type":"ListItem","position":4,"item":{"@id":"/byoip/concepts/static-ips/","name":"Static IPs"}}]} ```