Corriger la géolocalisation IPv4 après un transfert

Réponse rapide : après un transfert, la géolocalisation IPv4 peut continuer à afficher le mauvais pays (l'ancien), car l'enregistrement du registre, l'annonce BGP et chaque base GeoIP commerciale sont des systèmes distincts. Modifier le registre ne réécrit pas les bases. Ce qui fonctionne : publier votre propre fichier de localisation (un geofeed selon la RFC 8805), le référencer dans votre objet de la RIPE Database et envoyer une correction à chaque fournisseur, en gardant les numéros de ticket. Aucun fournisseur ne garantit de date. Vérifié le 2026-10-14. Les étapes côté registre figurent dans notre guide du transfert RIPE NCC ; cet article commence une fois le bloc à vous.

Quatre enregistrements, quatre questions différentes

Enregistrement	Répond à	Qui le définit	Ce qu'il peut affecter
Enregistrement RIR (WHOIS)	Qui détient le bloc	Le titulaire, dans le registre	L'identité du titulaire. `country:` n'est pas une localisation
Origine BGP et ROA	Qui l'annonce et si c'est autorisé	Vous, sur vos routeurs et dans RPKI	L'accessibilité et la validité de la route, pas le pays
Geofeed (RFC 8805)	Où l'opérateur dit utiliser chaque préfixe	Vous, dans un fichier que vous hébergez	Une indication pour les fournisseurs qui le lisent
Base GeoIP commerciale	Où le fournisseur pense que l'adresse se trouve	Le fournisseur, avec ses sources	Ce que voient les sites et les applications

Le cinquième élément, l'emplacement réel de vos serveurs, est ce que les quatre autres cherchent à modéliser. La documentation de la RIPE Database dit qu'on n'a jamais précisé ce que représente country:, donc il ne peut pas servir de façon fiable à associer des adresses IP à des pays, et le RIPE NCC indique ne pas être un fournisseur de géolocalisation. Un bloc peut être enregistré au nom d'une société d'un pays et exploité dans un autre, et les deux enregistrements sont corrects.

Diagnostic : une liste et un script

Vérification	Commande	Affecte
CIDR et enregistrement	`whois -h whois.ripe.net -r -T inetnum 192.0.2.0/24`	Titulaire, `country:`, la ligne `geofeed:`
Fichier geofeed	`curl -s <URL de geofeed:>`	L'indication de localisation pour les fournisseurs qui le lisent
AS d'origine et ROA	RIPEstat `prefix-overview`, `rpki-validation`	Routage et validité de la route, pas le pays
Données des fournisseurs	La page de recherche publique du fournisseur	Le pays que voient vos utilisateurs et partenaires
DNS inverse	`dig -x 192.0.2.1`	Contrôles de messagerie et lisibilité des logs ; aucune source vérifiée ne l'utilise pour le pays

192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24 et 2001:db8::/32 sont des préfixes de documentation : à utiliser pour la syntaxe uniquement, car ils ne sont pas annoncés et la requête RIPE renvoie pour eux le bloc parent hors RIPE. Pour la sortie réelle, nous utilisons le préfixe propre de DCXV et AS204057 (exécuté le 2026-10-14 ; Linux, whois 5.6, jq 1.8 ; sur un système sans fichier services, ajoutez -p 43 à whois) :

$ whois -h whois.ripe.net -r -T inetnum 178.23.189.0/24 | grep -E '^(inetnum|netname|country|geofeed)'
inetnum:        178.23.189.0 - 178.23.189.255
netname:        CY-DCXV-20210903
country:        CY
geofeed:        https://dcxv.com/geofeed.csv
$ curl -s 'https://stat.ripe.net/data/prefix-overview/data.json?resource=178.23.189.0/24' | jq -c '.data.asns'
[{"asn":204057,"holder":"DCXV-AS DCXV INTERNATIONAL LTD"}]
$ curl -s 'https://stat.ripe.net/data/rpki-validation/data.json?resource=204057&prefix=178.23.189.0/24' | jq -r '.data.status'
valid

Le registre indique CY car le titulaire est une société chypriote, alors que les serveurs sont ailleurs. L'AS d'origine et la ROA sont valides, et un attribut geofeed: est présent. Ce mélange est normal et explique pourquoi un fournisseur peut afficher un pays que le registre ne mentionne pas. DCXV publie ici les données de son réseau. Si vous détenez un bloc avec ce problème, vous pouvez nous envoyer une demande concernant le transfert IPv4.

Le script ci-dessous (Python 3.8+, bibliothèque standard uniquement, testé sur 3.14, ressources de la région RIPE seulement) affiche l'objet de registre, l'AS d'origine, l'état RPKI et la ligne de geofeed la plus spécifique pour un préfixe, via la RIPE Database et RIPEstat. Nous l'avons exécuté sur des préfixes DCXV, des préfixes de documentation et des cas d'erreur ; la correspondance avec le feed a aussi été vérifiée hors ligne sur un fichier d'exemple.

#!/usr/bin/env python3
"""geocheck.py PREFIX - registry country, origin ASN, RPKI status and geofeed line for a prefix.
Python 3.8+, standard library only. Data: RIPE Database REST API and RIPEstat (RIPE region only)."""
import csv, io, ipaddress, json, sys, time, urllib.error, urllib.parse, urllib.request

def get(url):
    req = urllib.request.Request(url, headers={'Accept': 'application/json', 'User-Agent': 'geocheck/1.0'})
    for attempt in range(4):
        try:
            with urllib.request.urlopen(req, timeout=20) as r:
                return r.read(5_000_000).decode('utf-8-sig', 'replace')  # cap the read at 5 MB
        except OSError as e:  # includes HTTP 429 and connection resets
            if isinstance(e, urllib.error.HTTPError) and 400 <= e.code < 500 and e.code != 429:
                sys.exit('request refused for %s: %s' % (url, e))  # retrying a 4xx will not help
            if attempt == 3:
                sys.exit('network error for %s: %s' % (url, e))
            time.sleep(2 ** attempt)

def stat(call, **q):
    return json.loads(get('https://stat.ripe.net/data/%s/data.json?%s' % (call, urllib.parse.urlencode(q))))['data']

def registry(net):
    # best match: the most specific inetnum / inet6num that covers the prefix
    t = 'inet6num' if net.version == 6 else 'inetnum'
    q = urllib.parse.urlencode([('query-string', str(net)), ('source', 'ripe'), ('type-filter', t),
                                ('flags', 'no-referenced'), ('flags', 'no-irt')])
    try:
        obj = json.loads(get('https://rest.db.ripe.net/search.json?' + q))['objects']['object'][0]
    except (ValueError, KeyError, IndexError):
        return None
    return {a['name']: a['value'] for a in obj['attributes']['attribute']}

def feed_match(url, net):
    # most specific feed entry that covers the prefix; RFC 8805 columns: prefix,country,region,city
    best = None
    for row in csv.reader(io.StringIO(get(url))):
        if not row or row[0].lstrip().startswith('#'):
            continue
        try:
            p = ipaddress.ip_network(row[0].strip(), strict=False)
        except ValueError:
            continue
        if p.version == net.version and net.subnet_of(p) and (best is None or p.prefixlen > best[0].prefixlen):
            best = (p, row)
    return best[1] if best else None

def main(arg):
    try:
        net = ipaddress.ip_network(arg, strict=False)
    except ValueError:
        sys.exit('usage: geocheck.py PREFIX   (for example 192.0.2.0/24)')
    if net.prefixlen == net.max_prefixlen:
        sys.exit('give the prefix, not a single address: a /32 or /128 gives a misleading RPKI result')
    if net.prefixlen == 0:
        sys.exit('give a real prefix, not the default route')
    print('prefix           ', net)
    reg = registry(net)
    top = reg and ((reg.get('netname') or '').startswith('NON-RIPE-NCC-MANAGED')
                   or (reg.get('inetnum') or '').startswith('0.0.0.0 -') or reg.get('inet6num') == '::/0')
    if not reg or top:
        print('registry object   outside the RIPE NCC: query that RIR instead')
    else:
        print('registry object  ', reg.get('inetnum') or reg.get('inet6num'), '| netname', reg.get('netname'), '| status', reg.get('status'))
        print('registry country ', reg.get('country'), '(country: is not a location)')
    ov = stat('prefix-overview', resource=str(net))
    asns = [str(a['asn']) for a in ov.get('asns', [])]
    print('origin ASN       ', ', '.join('AS' + a for a in asns) or 'not announced (no origin in RIPEstat)')
    for a in asns:
        print('RPKI AS%-9s' % a, stat('rpki-validation', resource=a, prefix=str(net))['status'])
    url = None if top else (reg or {}).get('geofeed')
    if not url:
        print('geofeed          none (no geofeed: attribute on the best-match object)')
        return
    print('geofeed URL      ', url)
    if not url.startswith('https://'):
        sys.exit('geofeed URL is not https://, not fetched')
    row = feed_match(url, net)
    print('geofeed line     ', ','.join(row[:4]) if row else 'NO entry covers this prefix')

if __name__ == '__main__':
    if len(sys.argv) != 2:
        sys.exit('usage: geocheck.py PREFIX')
    main(sys.argv[1])

Ce que vous voulez voir : valid et une ligne du feed pour votre préfixe. "NO entry covers this prefix" signifie que les fournisseurs qui lisent votre feed ignoreront le bloc.

Où envoyer les corrections

Utilisez le canal actuel de chaque fournisseur ; corriger l'un ne corrige pas les autres. Documentation vérifiée le 2026-10-14.

Fournisseur	Canal	Ce que dit sa documentation
MaxMind	Formulaires ponctuels ; GeoIP Exchange pour les opérateurs	Accepte les geofeeds RFC 8805 et RFC 9632, examinés une fois par jour ouvré ; pas de date de publication
IPinfo	Page de corrections ; geofeeds	Message de la communauté (2026-02-05) : la mesure d'abord, les geofeeds de façon sélective
DB-IP	Lien de signalement dans le résultat ; lots via le formulaire de contact	Un changement du WHOIS du RIR déclenche généralement l'actualisation ; un geofeed est une autre voie
IP2Location	Contact et rapport sur la précision des données	Dates de publication par licence ; aucune procédure publique de correction ni de geofeed trouvée
Google	Formulaire de signalement d'IP dans l'aide Search	Les mises à jour peuvent prendre plus d'un mois ("may take more than a month") ; pas de suivi individuel

Publier un geofeed et le référencer

Un geofeed est un fichier CSV défini par la RFC 8805 : ip_prefix,alpha2code,region,city. Les préfixes imbriqués sont permis et le plus spécifique l'emporte. La RFC demande de l'UTF-8 et des fins de ligne CRLF, juge le code postal obsolète (omettez-le) et autorise les consommateurs à ne voir dans les données qu'une indication. Un fichier minimal avec des préfixes de documentation :

# prefix,country,region,city
192.0.2.0/24,CZ,CZ-10,Prague
2001:db8::/32,CZ,CZ-10,Prague

Hébergez-le en HTTPS et ajoutez une ligne geofeed: https://example.net/geofeed.csv à votre inetnum ou inet6num ; l'attribut est facultatif et unique. La RFC 9632 demande aux consommateurs d'utiliser l'objet le plus spécifique qui porte un geofeed, puis d'ignorer les autres indices comme country:. Elle définit aussi une signature RPKI facultative pour le fichier ; nous n'avons pas vérifié quels fournisseurs la contrôlent. Après un transfert, relisez l'objet : une ligne geofeed: laissée par le vendeur pointe vers un fichier que vous ne contrôlez pas.

Un plan d'action pour le nouveau titulaire

Réunir les preuves. L'enregistrement qui vous désigne comme titulaire, la liste des CIDR et la preuve de l'emplacement des serveurs.
Corriger votre côté. Rectifier la ligne geofeed:, publier le fichier, lancer le script.
Soumettre à chaque fournisseur. Une demande chacun, avec l'URL du feed. N'indiquez que l'emplacement réel : les fournisseurs peuvent le recouper avec leurs propres mesures.
Tenir un journal. Numéro de ticket, date, fournisseur, préfixe, réponse.
Revérifier plus tard. Personne ne promet de date : ne bâtissez pas un lancement dessus.

Symptôme, cause, vérification, action

Symptôme	Cause possible	Vérifier	Action
Plusieurs fournisseurs affichent l'ancien pays	Pas de geofeed, ou pas encore lu	Le script : ligne `geofeed:` et entrée correspondante ?	Publier le feed, puis une correction par fournisseur
Un fournisseur suit le registre, pas votre feed	Ce fournisseur n'utilise pas de feeds	Sa documentation et une recherche	Envoyer une correction avec l'URL du feed
Le feed est en ligne, les anciennes données restent	Retard de publication, échec de récupération ou mesure divergente	HTTPS joignable, préfixe couvert, pas de ligne imbriquée en conflit	Interroger le fournisseur, garder le ticket, revérifier plus tard
Seul un CDN, une banque ou un service de paiement se trompe	Il utilise ses propres données : Cloudflare, par exemple, met sa base à jour plusieurs fois par semaine et ne peut garantir qu'elle concorde avec d'autres fournisseurs ; les moteurs de risque peuvent aussi pondérer d'autres signaux	Demander quelle source il utilise	Corriger cette source, puis signaler au service
Bon pays, mauvaise ville	Le feed n'a pas de ville ou la mesure diffère	La colonne city du feed	Ajouter région et ville, puis redemander

Organigramme : cinq vérifications dans l'ordre pour un mauvais pays sur un bloc IPv4, avec l'action de chacune

Estimer le risque avant d'acheter

Les listes noires et les abus relèvent de la checklist de due diligence ; ici, seulement la géolocalisation. Interrogez le préfixe chez deux ou trois fournisseurs dès maintenant, lisez son inetnum (country: et toute URL geofeed:) et demandez qui contrôle ce fichier. Convenez au contrat que le vendeur transmette ou supprime la référence au feed à la clôture.

Étape suivante

Vous ne savez pas où est l'écart ? Envoyez-nous une demande concernant le transfert IPv4 ou écrivez à ipv4@dcxv.com avec le préfixe et le symptôme. Nous ne promettons aucune date de mise à jour par un fournisseur.

Séquestre IPv4 : calendrier des paiements et checklist

Séquestre (escrow) IPv4 expliqué : jalons de paiement, qui confirme quoi, conditions de libération des fonds et cas d'échec pour acheteurs et vendeurs.

October 14, 2026

ipv4 networking transfer