BYOIP su Cloudflare: i tuoi prefissi IP sulla rete di Cloudflare

Un flusso API documentato verifica il prefisso rispetto all’IRR, all’RPKI e a un token di proprietà, e poi lo colleghi ai servizi che useranno i suoi indirizzi.

Cosa accetta Cloudflare

Dalla documentazione di Cloudflare, il giorno in cui l’abbiamo verificata:

• Chi. Account Enterprise il cui contratto include il BYOIP. L’account team lo conferma, insieme alla configurazione dei servizi dell’account, prima del caricamento.
• Dimensione. Un /24 o più grande per IPv4; per IPv6, da un /48 a un /32.
• Registro. ARIN, il RIPE NCC, APNIC o uno degli altri registri regionali. Nulla sullo spazio PA, PI o legacy.
• Chi lo origina. AS13335 nel flusso documentato; per il tuo ASN, chiedi all’account team. I clienti già su AS209242 di Cloudflare possono mantenerlo, ma i nuovi caricamenti usano AS13335.
• Dove. Tutte le sedi di Cloudflare.
• Servizi. Magic Transit, Spectrum, la CDN, e le DNS location e gli IP di egress dedicati di Gateway. Magic Transit ha un suo processo di caricamento, è “not a self-serve product” (traduzione: “non un prodotto self-service”), e può essere solo il binding predefinito di un intero prefisso. Un prefisso serve l’ingresso della CDN o l’uscita della CDN, non entrambi.
• Prezzo. Non pubblicato. Le condizioni dicono che gli indirizzi devono essere usati “solely in connection with the Customer's domains that are receiving Cloudflare's Enterprise Services” (traduzione: “esclusivamente in relazione ai domini del Cliente che ricevono gli Enterprise Services di Cloudflare”).
• Tempi. Almeno cinque ore di provisioning BGP prima dell’annuncio, e da quattro a sei ore perché ogni service binding si propaghi. La configurazione di Magic Transit “takes around one day to roll out” (traduzione: “richiede circa un giorno per essere distribuita”).

Prima di iniziare

Cloudflare non può caricare un prefisso se fallisce una qualsiasi verifica di registrazione, IRR, RPKI o proprietà. Prepara questi elementi:

Un route object che corrisponda esattamente. Un oggetto route per ogni prefisso che carichi, esattamente per quel prefisso, con l’origin che Cloudflare userà: AS13335 nel flusso standard. Per verificarlo, Cloudflare suggerisce IRR Explorer o whois -h rr.ntt.net 203.0.113.0/24.

Una ROA corretta per lo stesso origin. Cloudflare ti chiede di verificarla nel suo RPKI Portal e in una seconda fonte, come Routinator (RPKI e ROA).

Una letter of agency (LOA), il nome che Cloudflare dà alla Letter of Authorization, richiesta dai suoi transit provider. Cloudflare la genera per te quando imposti delegate_loa_creation su true, cosa che si basa sulla ROA e sulla verifica di proprietà. Una LOA manuale deve essere un PDF, e dovrebbe essere su carta intestata con firma autografa, anche se Cloudflare accetta una firma digitale se è chiaro chi ha firmato. I transit provider possono rifiutare un JPG o un PNG, e l’elaborazione manuale può rallentare il caricamento.

Un posto per il token di validazione: la descrizione (descr) o i remarks del route object corrispondente, oppure un record TXT cf-validation in ogni zona DNS inversa del prefisso.

Un account ID e un API token con i permessi IP Prefixes.

Passo per passo

Questo è il flusso documentato di Cloudflare per i prefissi non usati con Magic Transit, che ha un suo caricamento tramite l’account team.

01Aggiungi il prefisso all’account che lo possiederà:

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

Salva l’id e l’ownership_validation_token dalla risposta.

02Pubblica il token. Aggiungi cf-validation: <token> al route object, oppure il record TXT alle zone inverse.

03Valida. Invia un POST a .../prefixes/$PREFIX_ID/validate. Quando le verifiche IRR, RPKI e di proprietà vanno a buon fine, il campo approved del prefisso riporta "V", e puoi rimuovere il token. Se una verifica fallisce, i dettagli del prefisso mostrano stati come missing, invalid o mismatch_asn.

04Collega il prefisso a un servizio. Ogni prefisso ha bisogno di un service binding predefinito sull’intero prefisso; binding più specifici possono mandarne delle parti alla CDN o a Spectrum. Cloudflare crea il prefisso BGP in stato ritirato. Calcola almeno cinque ore, e attendi che ogni binding sia attivo.

05Annuncia:

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 che l’annuncio richiede in genere da due a sette minuti, e il ritiro circa 15.

06Per la CDN, crea un address map una volta annunciato il prefisso, così i record DNS in proxy rispondono con i tuoi indirizzi.

Insidie

• Un route object che copre il prefisso non basta. Cloudflare vuole un route object che corrisponda esattamente a ogni prefisso che carichi, con l’origin giusto.
• I binding richiedono ore, e nel frattempo il traffico ne risente. Cloudflare dice che i servizi per gli indirizzi interessati probabilmente subiscono interruzioni mentre un binding si propaga. Configura i binding prima dell’annuncio, e modificali fuori dalle ore di punta.
• Due reti che annunciano. Quando sposti un prefisso attivo, lascia che Cloudflare annunci per prima, verificalo su un looking glass con AS13335, poi ritira il tuo annuncio. Se lasci attivo il tuo, parte del traffico potrebbe aggirare Cloudflare.
• La regola dei 15 minuti. Dopo aver modificato l’annuncio di un prefisso, attendi almeno 15 minuti prima di modificarlo di nuovo; l’API rifiuta le chiamate anticipate con l’errore 1004 (HTTP 429, rate_limit_exceeded).

Se il blocco è in affitto

Le condizioni specifiche di servizio di Cloudflare, aggiornate l’ultima volta il 28 settembre 2026, trattano direttamente questo caso. Se non sei il proprietario legale degli indirizzi, “must obtain written authorization from the legal owner” (traduzione: “devi ottenere un’autorizzazione scritta dal proprietario legale”) perché Cloudflare li annunci, e se il proprietario la revoca, Cloudflare può smettere di annunciarli. Il titolare si occupa anche della parte del registro: la ROA per AS13335, il route object con AS13335 come origin, e il token di validazione in quell’oggetto, che solo il maintainer del titolare può modificare. Le condizioni chiedono dati WHOIS accurati e voci IRR e RPKI valide in ogni momento, quindi un affitto che termina o una ROA che cambia può togliere il prefisso da Cloudflare.

Dove entra RTM Networks

Affittiamo /24 e blocchi più grandi dal nostro spazio di indirizzi RIPE NCC, e vendiamo blocchi nelle regioni del RIPE NCC, dell’ARIN e dell’APNIC. Per lo spazio affittato da noi, creiamo la ROA e il route object esatto per AS13335, vi aggiungiamo il token di validazione di Cloudflare e firmiamo la Letter of Authorization, così i passaggi API sono ciò che resta a te (affitto di indirizzi IPv4). Se il BYOIP non è nel tuo contratto Cloudflare, o ti servono meno di 256 indirizzi, annunciamo un blocco e lo consegniamo al tuo server via GRE o WireGuard, fino a un solo indirizzo (tunnel GRE e WireGuard). Altri provider: guide BYOIP.