Migrazione BGP: perché un prefisso IPv4 cambia ASN di origine
Perché un prefisso IPv4 può cambiare ASN di origine senza cambiare titolare, e come verificare BGP, RPKI, IRR e stato del registro.
Il blocco di indirizzi può restare lo stesso quando cambia la rete che ne origina la rotta. Instradamento, autorizzazione e dati sul titolare hanno ruoli diversi.
Un prefisso IPv4 può mantenere gli stessi numeri e sembrare comunque spostato su una rete diversa. In BGP, questo cambiamento è solitamente visibile come un nuovo ASN di origine.
È ciò che si chiama migrazione BGP, o rehoming. È un’osservazione sullo stato dell’instradamento. Di per sé non prova che sia cambiato il titolare registrato, che il prefisso si sia spostato in un altro Paese o che sia avvenuto un trasferimento di indirizzi.
Partire dalla rotta
Se un collettore osserva 203.0.113.0/24 → AS64500, sta vedendo AS64500 originare la rotta in quel momento. Se lo stesso prefisso appare in seguito come 203.0.113.0/24 → AS64550, l’ASN di origine è cambiato.
Qui il termine ASN di origine indica l’ASN all’estremità di origine del percorso AS osservato. Non va confuso con l’attributo BGP ORIGIN, che è un attributo distinto definito da RFC 4271.
Che cosa mostrano i dati recenti
Confrontando le istantanee dell’instradamento di inizio 2025 e inizio 2026, APNIC ha contato 29.699 prefissi IPv4 il cui ASN di origine era cambiato. La sua tabella di confronto con i trasferimenti elenca 1.991 prefissi migrati presenti nei registri dei trasferimenti e 26.722 assenti. Queste cifre sommano a 28.713, cioè 986 in meno rispetto al totale delle migrazioni riportato. La didascalia della tabella indica inoltre cambiamenti di instradamento nel 2024 e registri dei trasferimenti per il 2023–2024, mentre il testo circostante descrive cambiamenti nel 2025 e registri per il 2024–2025. Le cifre e le indicazioni temporali pubblicate non forniscono quindi un dettaglio annuale completamente riconciliato.
Il confronto non dimostra che i prefissi senza corrispondenza siano stati trasferiti impropriamente. Mostra perché la storia dell’instradamento e quella del registro non vadano trattate come lo stesso insieme di dati. Molti cambiamenti legittimi della rete non richiedono una modifica del titolare registrato.
Perché cambia un ASN di origine
Esistono diverse spiegazioni operative ordinarie:
- un’azienda cambia fornitore di transito o di hosting;
- l’infrastruttura si sposta in un altro data center o in una rete cloud;
- un cliente comincia a originare le rotte tramite un proprio ASN appena ottenuto;
- una rete aziendale viene unita ad altre, divisa o ristrutturata;
- un titolare delega l’instradamento a un altro operatore o fornitore di hosting; oppure
- l’architettura di instradamento cambia mentre il rapporto con il registro rimane stabile.
Ogni spiegazione richiede prove. La rotta, da sola, mostra che cosa viene annunciato, non perché sia cambiato o chi lo abbia autorizzato.
Migrazione BGP e trasferimento IPv4 rispondono a domande diverse
La migrazione BGP chiede: quale ASN sta originando la rotta per questo prefisso?
Un trasferimento IPv4 chiede: è cambiato il rapporto riconosciuto con il registro?
I due eventi possono avvenire nello stesso momento, oppure separatamente. Un titolare può cambiare fornitore senza trasferire la risorsa; il rapporto con il registro può cambiare mentre lo stesso fornitore continua a originare la rotta.
BGP fornisce prove di instradamento, non prove complete del controllo
Vedere AS64550 originare una rotta per un prefisso non dimostra automaticamente che AS64550 ne sia proprietario, sia il titolare registrato, possa trasferirlo o abbia un’autorità permanente ad annunciarlo. Una locazione, un accordo con un cliente, una migrazione temporanea o un errore potrebbero produrre la stessa osservazione.
Per comprendere il controllo, confrontare la rotta con i dati del registro, l’autorizzazione operativa e le prove che spiegano il rapporto. È questa la ragione pratica per distinguere il controllo dell’instradamento, il controllo del registro e i rapporti commerciali.
RPKI aggiunge l’autorizzazione
Una Route Origin Authorization dichiara che un determinato ASN è autorizzato a originare una rotta per un prefisso nel sistema RPKI. RFC 9582 definisce il profilo ROA attuale.
Quando l’origine cambia da AS64500 ad AS64550, la ROA pertinente dovrebbe riflettere il nuovo stato previsto. Una ROA valida non dimostra che la rotta sia attualmente annunciata, e una rotta osservata non dimostra che l’annuncio sia autorizzato. BGP e RPKI forniscono prove complementari.
IRR e DNS inverso fanno parte della migrazione
I fornitori possono usare oggetti di rotta IRR per costruire filtri. I clienti possono dipendere dal DNS inverso, da elenchi di autorizzazione, dal monitoraggio e dai sistemi di reputazione. Una migrazione dell’instradamento può quindi richiedere diversi aggiornamenti coordinati anche se il titolare registrato resta lo stesso.
Una documentazione operativa utile identifica ogni livello: stato del registro, origine BGP, autorizzazione RPKI, politica IRR, responsabilità del DNS inverso, contatti e registro interno della modifica.
Che cosa verificare quando cambia l’origine
Prima della modifica
- annotare i prefissi esatti e l’ASN di origine attuale;
- confermare il nuovo ASN previsto e l’operatore autorizzato;
- verificare ROA, oggetti IRR, DNS inverso e preparazione dei fornitori; e
- conservare le prove attuali relative a BGP e al registro.
Durante la migrazione
- osservare la propagazione e i cambiamenti di origine da più reti;
- controllare la validazione RPKI e gli annunci di prefissi più specifici; e
- verificare che la vecchia rotta scompaia dove la modifica lo richiede.
Dopo la migrazione
- verificare che l’ASN previsto stia originando la rotta per il prefisso;
- confermare che ROA, IRR e DNS inverso corrispondano allo stato previsto;
- controllare i dati del registro e i contatti; e
- salvare le prove affinché l’operatore successivo possa ricostruire la modifica.
Un’origine inattesa significa un dirottamento?
Non necessariamente. Merita un’indagine, ma la prima domanda dovrebbe essere se la modifica fosse autorizzata. Tra le possibili spiegazioni ci sono una migrazione di fornitore, manutenzione temporanea, instradamento del cliente, un nuovo ASN, una delega operativa, un errore di configurazione o un annuncio non autorizzato.
Prima di attribuire una causa, usare la storia BGP insieme ai dati del registro, alle ROA, alle informazioni IRR, alla documentazione del fornitore e ai registri interni delle modifiche. Un’etichetta affrettata può nascondere il vero problema operativo.
Perché conta per la portabilità
Le risorse IPv4 sopravvivono sempre più spesso ai cambiamenti di fornitori, data center, strutture societarie, ASN e utilizzatori operativi. La portabilità va quindi oltre la possibilità di mantenere lo stesso numero di indirizzo. I sistemi circostanti devono preservare unicità, autorizzazione, dati accurati, sicurezza e continuità mentre la rete cambia.
La continuità dell’IP pubblico dipende da questo livello pratico. DNS, controlli di accesso, elenchi di autorizzazione dei partner, VPN e monitoraggio possono tutti dipendere da un indirizzo, anche quando i cambiamenti del registro e dell’instradamento sembrano amministrativi.
La rete in funzione è la verifica finale
I dati del registro, RPKI, gli oggetti IRR e le osservazioni BGP sono strumenti diversi attorno a una rete in funzione. L’obiettivo di una migrazione legittima è semplice: effettuare il cambiamento di instradamento necessario, mantenendo la rete raggiungibile, autorizzata e spiegabile.
Leggere l’intera sequenza
Condividi il tuo punto di vista
Accedi con un account esistente per lasciare un commento.