BYOIP chez Cloudflare : vos propres préfixes IP sur le réseau de Cloudflare

Une procédure documentée par API contrôle le préfixe auprès de l'IRR, du RPKI et d'un jeton de propriété, puis vous le liez aux services qui utiliseront ses adresses.

Ce que Cloudflare accepte

D'après la documentation de Cloudflare, le jour de notre vérification :

• Qui. Les comptes Enterprise dont le contrat inclut le BYOIP. L'équipe commerciale le confirme, ainsi que la configuration des services du compte, avant l'intégration.
• Taille. Un /24 ou plus pour l'IPv4 ; pour l'IPv6, d'un /48 à un /32.
• Registre. L'ARIN, le RIPE NCC, l'APNIC ou l'un des autres registres régionaux. Rien sur l'espace PA, PI ou legacy.
• Qui annonce. AS13335 dans la procédure documentée ; pour votre propre ASN, demandez à l'équipe commerciale. Les clients déjà sur AS209242 de Cloudflare peuvent le garder, mais les nouvelles intégrations utilisent AS13335.
• Où. Tous les sites de Cloudflare.
• Services. Magic Transit, Spectrum, le CDN, ainsi que les DNS locations et dedicated egress IPs de Gateway. Magic Transit a sa propre intégration, n'est « not a self-serve product » (traduction : « pas un produit en libre-service »), et ne peut être que le binding par défaut d'un préfixe entier. Un préfixe sert soit l'entrée CDN, soit la sortie CDN, pas les deux.
• Prix. Non publié. Les conditions disent que les adresses doivent être utilisées « solely in connection with the Customer's domains that are receiving Cloudflare's Enterprise Services » (traduction : « uniquement en lien avec les domaines du client qui reçoivent les Enterprise Services de Cloudflare »).
• Délai. Au moins cinq heures de provisionnement BGP avant l'annonce, et quatre à six heures pour la propagation de chaque service binding. La configuration de Magic Transit « takes around one day to roll out » (traduction : « prend environ une journée à se déployer »).

Avant de commencer

Cloudflare ne peut pas intégrer un préfixe si l'un des contrôles d'enregistrement, d'IRR, de RPKI ou de propriété échoue. Préparez ceci :

Un objet route qui correspond exactement. Un objet route par préfixe intégré, pour exactement ce préfixe, avec l'origine que Cloudflare utilisera : AS13335 dans la procédure standard. Pour le vérifier, Cloudflare suggère IRR Explorer ou whois -h rr.ntt.net 203.0.113.0/24.

Un ROA correct pour la même origine. Cloudflare vous demande de le vérifier dans son RPKI Portal et dans une seconde source, comme Routinator (RPKI et ROA).

Une letter of agency (LOA), le nom que Cloudflare donne à la lettre d'autorisation, que ses opérateurs de transit exigent. Cloudflare la génère pour vous si vous fixez delegate_loa_creation à true, ce qui s'appuie sur le ROA et le contrôle de propriété. Une LOA manuelle doit être un PDF, de préférence sur papier à en-tête de l'entreprise avec une signature manuscrite, mais Cloudflare accepte une signature numérique si l'on voit clairement qui a signé. Les opérateurs de transit peuvent refuser un JPG ou un PNG, et le traitement manuel peut ralentir l'intégration.

Un emplacement pour le jeton de validation : la description (descr) ou les remarks de l'objet route correspondant, ou un enregistrement TXT cf-validation dans chaque zone DNS inverse du préfixe.

Un ID de compte et un jeton d'API avec les permissions IP Prefixes.

Étape par étape

Voici la procédure documentée par Cloudflare pour les préfixes non utilisés avec Magic Transit, qui a sa propre intégration via l'équipe commerciale.

01Ajoutez le préfixe au compte qui en sera propriétaire :

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}'

Conservez l'id et l'ownership_validation_token de la réponse.

02Publiez le jeton. Ajoutez cf-validation: <token> à l'objet route, ou l'enregistrement TXT aux zones inverses.

03Validez. Envoyez un POST à .../prefixes/$PREFIX_ID/validate. Quand les contrôles IRR, RPKI et de propriété passent, le champ approved du préfixe vaut "V", et vous pouvez retirer le jeton. Si un contrôle échoue, les détails du préfixe affichent des états comme missing, invalid ou mismatch_asn.

04Liez le préfixe à un service. Chaque préfixe a besoin d'un service binding par défaut sur tout le préfixe ; des bindings plus spécifiques peuvent en envoyer des parties vers le CDN ou Spectrum. Cloudflare crée le préfixe BGP à l'état retiré. Comptez au moins cinq heures, et attendez que chaque binding soit actif.

05Annoncez :

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 indique que l'annonce prend en général deux à sept minutes, et le retrait environ 15.

06Pour le CDN, créez une address map une fois le préfixe annoncé, afin que les enregistrements DNS proxifiés répondent avec vos adresses.

Les pièges

• Un objet route couvrant ne suffit pas. Cloudflare veut un objet route qui correspond exactement à chaque préfixe intégré, avec la bonne origine.
• Les bindings prennent des heures, et le trafic en souffre entre-temps. Cloudflare indique que les services des adresses concernées sont probablement perturbés pendant la propagation d'un binding. Configurez les bindings avant l'annonce, et modifiez-les hors des heures chargées.
• Deux réseaux qui annoncent. Quand vous déplacez un préfixe actif, laissez d'abord Cloudflare l'annoncer, vérifiez-le sur un looking glass sous AS13335, puis retirez votre propre annonce. Si vous laissez la vôtre, une partie du trafic peut contourner Cloudflare.
• La règle des 15 minutes. Après avoir modifié l'annonce d'un préfixe, attendez au moins 15 minutes avant de la modifier de nouveau ; l'API refuse les appels plus précoces avec l'erreur 1004 (HTTP 429, rate_limit_exceeded).

Si vous louez le bloc

Les conditions spécifiques aux services de Cloudflare, mises à jour le 28 septembre 2026, traitent directement ce cas. Si vous n'êtes pas le propriétaire légal des adresses, vous « must obtain written authorization from the legal owner » (traduction : « devez obtenir l'autorisation écrite du propriétaire légal ») pour que Cloudflare les annonce, et si le propriétaire la retire, Cloudflare peut cesser de les annoncer. Le titulaire s'occupe aussi du côté registre : le ROA pour AS13335, l'objet route avec AS13335 comme origine, et le jeton de validation dans cet objet, que seul le mainteneur du titulaire peut modifier. Les conditions demandent des données WHOIS exactes et des entrées IRR et RPKI valides à tout moment : une location qui prend fin ou un ROA qui change peut donc retirer le préfixe de Cloudflare.

La place de RTM Networks

Nous louons des /24 et plus grands depuis notre propre espace d'adresses RIPE NCC, et vendons des blocs dans les régions du RIPE NCC, de l'ARIN et de l'APNIC. Pour un espace loué chez nous, nous créons le ROA et l'objet route exact pour AS13335, y ajoutons le jeton de validation de Cloudflare et signons la lettre d'autorisation : il ne vous reste que les étapes d'API (louer de l'IPv4). Si le BYOIP n'est pas dans votre contrat Cloudflare, ou s'il vous faut moins de 256 adresses, nous annonçons un bloc et le livrons à votre serveur par GRE ou WireGuard, jusqu'à une seule adresse (tunnels GRE et WireGuard). Autres fournisseurs : guides BYOIP.