BYOIP en Cloudflare: tus propios prefijos IP en la red de Cloudflare

Un flujo documentado por API comprueba el prefijo contra el IRR, RPKI y un token de propiedad, y luego lo vinculas a los servicios que usarán sus direcciones.

Qué acepta Cloudflare

Según la documentación de Cloudflare, el día que la consultamos:

• Quién. Cuentas Enterprise cuyo contrato incluye BYOIP. El equipo de cuenta lo confirma, junto con la configuración de servicios de la cuenta, antes de la incorporación.
• Tamaño. Un /24 o mayor para IPv4; para IPv6, de un /48 a un /32.
• Registro. ARIN, el RIPE NCC, APNIC u otro de los registros regionales. Nada sobre espacio PA, PI o legacy.
• Quién lo origina. AS13335 en el flujo documentado; para tu propio ASN, pregunta al equipo de cuenta. Los clientes que ya están en el AS209242 de Cloudflare pueden conservarlo, pero las nuevas incorporaciones usan AS13335.
• Dónde. Todas las ubicaciones de Cloudflare.
• Servicios. Magic Transit, Spectrum, la CDN, y las ubicaciones DNS de Gateway y las IP de salida dedicadas. Magic Transit tiene su propia incorporación, es «not a self-serve product» (traducción: «no es un producto de autoservicio»), y solo puede ser el binding por defecto de un prefijo entero. Un prefijo sirve para la entrada de la CDN o para la salida de la CDN, no para ambas.
• Precio. No publicado. Las condiciones dicen que las direcciones deben usarse «solely in connection with the Customer's domains that are receiving Cloudflare's Enterprise Services» (traducción: «únicamente en relación con los dominios del Cliente que reciben los Enterprise Services de Cloudflare»).
• Plazo. Al menos cinco horas de aprovisionamiento BGP antes de anunciar, y de cuatro a seis horas para que se propague cada service binding. La configuración de Magic Transit «takes around one day to roll out» (traducción: «tarda alrededor de un día en desplegarse»).

Antes de empezar

Cloudflare no puede incorporar un prefijo si falla cualquier comprobación de registro, IRR, RPKI o propiedad. Prepara esto:

Un objeto route que coincida exactamente. Un objeto route por cada prefijo que incorporas, exactamente para ese prefijo, con el origen que usará Cloudflare: AS13335 en el flujo estándar. Para comprobarlo, Cloudflare sugiere IRR Explorer o whois -h rr.ntt.net 203.0.113.0/24.

Un ROA correcto para el mismo origen. Cloudflare te pide que lo verifiques en su RPKI Portal y en una segunda fuente, como Routinator (RPKI y ROA).

Una letter of agency (LOA), el nombre que da Cloudflare a la Letter of Authorization, que exigen sus proveedores de tránsito. Cloudflare la genera por ti cuando pones delegate_loa_creation en true, lo que se basa en el ROA y la comprobación de propiedad. Una LOA manual debe ser un PDF, y debería ir en papel con membrete de la empresa con firma manuscrita, aunque Cloudflare acepta una firma digital si queda claro quién firmó. Los proveedores de tránsito pueden rechazar un JPG o un PNG, y el procesamiento manual puede ralentizar la incorporación.

Un sitio para el token de validación: la descripción (descr) o los remarks del objeto route correspondiente, o un registro TXT cf-validation en cada zona de DNS inverso del prefijo.

Un ID de cuenta y un token de API con los permisos de IP Prefixes.

Paso a paso

Este es el flujo documentado de Cloudflare para prefijos que no se usan con Magic Transit, que tiene su propia incorporación a través del equipo de cuenta.

01Añade el prefijo a la cuenta que será su propietaria:

curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/addressing/prefixes" \
  --request POST --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
  --json '{"cidr":"203.0.113.0/24","asn":13335,"delegate_loa_creation":true}'

Guarda el id y el ownership_validation_token de la respuesta.

02Publica el token. Añade cf-validation: <token> al objeto route, o el registro TXT a las zonas inversas.

03Valida. Envía un POST a .../prefixes/$PREFIX_ID/validate. Cuando se superan las comprobaciones de IRR, RPKI y propiedad, el campo approved del prefijo muestra "V", y puedes quitar el token. Si falla una comprobación, los detalles del prefijo muestran estados como missing, invalid o mismatch_asn.

04Vincula el prefijo a un servicio. Todo prefijo necesita un service binding por defecto sobre el prefijo entero; bindings más específicos pueden enviar partes a la CDN o a Spectrum. Cloudflare crea el prefijo BGP en estado retirado. Cuenta con al menos cinco horas, y espera a que todos los bindings estén activos.

05Anuncia:

curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/addressing/prefixes/$PREFIX_ID/bgp/prefixes/$BGP_PREFIX_ID" \
  --request PATCH --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
  --json '{"on_demand":{"advertised":true}}'

Cloudflare dice que anunciar suele llevar de dos a siete minutos, y retirar unos 15.

06Para la CDN, crea un address map una vez anunciado el prefijo, para que los registros DNS con proxy respondan con tus direcciones.

Errores habituales

• Un objeto route que lo cubre no basta. Cloudflare quiere un objeto route que coincida exactamente con cada prefijo que incorporas, con el origen correcto.
• Los bindings tardan horas, y mientras tanto el tráfico se resiente. Cloudflare dice que es probable que los servicios de las direcciones afectadas se interrumpan mientras se propaga un binding. Configura los bindings antes de anunciar, y cámbialos fuera de las horas punta.
• Dos redes anunciando. Cuando trasladas un prefijo activo, deja que Cloudflare lo anuncie primero, compruébalo en un looking glass con AS13335 y luego retira tu propio anuncio. Si mantienes el tuyo, parte del tráfico puede saltarse Cloudflare.
• La regla de los 15 minutos. Tras cambiar el anuncio de un prefijo, espera al menos 15 minutos antes de volver a cambiarlo; la API rechaza las llamadas anteriores con el error 1004 (HTTP 429, rate_limit_exceeded).

Si alquilas el bloque

Las condiciones específicas del servicio de Cloudflare, actualizadas por última vez el 28 de septiembre de 2026, lo tratan directamente. Si no eres el propietario legal de las direcciones, «must obtain written authorization from the legal owner» (traducción: «debes obtener la autorización por escrito del propietario legal») para que Cloudflare las anuncie, y si el propietario la retira, Cloudflare puede dejar de anunciarlas. El titular también hace la parte del registro: el ROA para AS13335, el objeto route con AS13335 como origen, y el token de validación en ese objeto, que solo puede editar el maintainer del titular. Las condiciones piden datos WHOIS exactos y entradas IRR y RPKI válidas en todo momento, así que un alquiler que termina o un ROA que cambia puede sacar el prefijo de Cloudflare.

Dónde encaja RTM Networks

Alquilamos /24 y mayores de nuestro propio espacio de direcciones del RIPE NCC, y vendemos bloques en las regiones RIPE NCC, ARIN y APNIC. Para el espacio que nos alquilas, creamos el ROA y el objeto route exacto para AS13335, le añadimos el token de validación de Cloudflare y firmamos la Letter of Authorization, así que solo te quedan los pasos de la API (alquilar IPv4). Si BYOIP no está en tu contrato con Cloudflare, o necesitas menos de 256 direcciones, anunciamos un bloque y lo entregamos a tu servidor por GRE o WireGuard, hasta una sola dirección (túneles GRE y WireGuard). Otros proveedores: guías BYOIP.