Cualquiera que trabaje con un proveedor de servicios de Internet probablemente haya visto este tipo de queja:
«Mi cliente está en Paraná, pero el sitio web cree que está en São Paulo».
«El streaming está diciendo que estoy en otro país».
«El banco bloqueó el acceso porque pensó que la ubicación IP era extraña».
«Google está mostrando una previsión meteorológica para otra ciudad».
Es una situación un poco ingrata, porque la mayor parte del tiempo la red funciona. El cliente navega, BGP está bien, DNS responde, traceroute pasa, la latencia es aceptable.
Pero para el usuario final, la constatación es sencilla: algo va mal en su Internet.
Y a menudo lo es. No en la conectividad, sino en la forma en que esa dirección IP está siendo geolocalizada por terceros.
La IP no tiene ninguna ciudad registrada en su interior
Lo primero que hay que tener en cuenta es que una IP no nace con una ciudad dentro.
No existe tal campo en el protocolo IP:
este endereço fica em Apucaranao:
este prefixo pertence a LondrinaLa geolocalización de la IP es una inferencia. Las empresas de contenidos, los bancos, las CDN, las plataformas antifraude, los motores de búsqueda, los servicios de streaming y las bases comerciales intentan averiguar dónde se está utilizando probablemente esa IP.
Para ello, cruzan diversas informaciones: datos de registro de Internet, comportamiento del tráfico, mediciones, historial, información de usuarios, bases comerciales, DNS, BGP, entre otras cosas.
En la mayoría de los casos funciona bastante bien. Pero cuando va mal, es una verdadera molestia.
Un proveedor puede recibir un nuevo bloque, comprar o transferir recursos, cambiar prefijos entre ciudades, activar un nuevo POP, reorganizar CGNAT, dividir IPv6 por regiones, intercambiar upstreams o simplemente empezar a utilizar un bloque que antes estaba asociado a otra ubicación.
Sólo que las bases externas pueden tardar en aprenderlo.
Y entonces empiezan las llamadas.
Dónde entra el geofeed
El geofeed es una forma normalizada de que el operador de red diga:
«Estos prefijos IP se están utilizando en estos lugares».
No cambia el enrutamiento. No cambia BGP. No anuncia nada a Internet. No es una sesión ascendente.
No es más que un archivo CSV publicado a través de HTTPS, siguiendo un formato definido en el RFC 8805 [1].
192.0.2.0/24,BR,BR-PR,Apucarana,
198.51.100.0/24,BR,BR-PR,Londrina,
203.0.113.0/24,BR,BR-SP,Sao Paulo,
2001:db8:100::/48,BR,BR-RS,Porto Alegre,
Cada línea asocia un prefijo a una ubicación aproximada.
El formato es:
ip_prefix,alpha2code,region,city,postal_codeEn la práctica:
192.0.2.0/24,BR,BR-PR,Apucarana,Es decir:
o prefixo 192.0.2.0/24 está no Brasil, no Paraná, em ApucaranaLa coma del final es importante. Representa el último campo, postal_code, que está vacío.
Qué significa cada campo
El primer campo es el prefijo IP. Puede ser IPv4 o IPv6, en formato CIDR.
192.0.2.0/24,BR,BR-PR,Apucarana,
2001:db8::/32,BR,BR-PR,Londrina,El segundo campo es el país, utilizando ISO 3166-1 alfa-2. Para Brasil, utilizamos BR.
El tercer campo es la región, utilizando la norma ISO 3166-2. En el caso de los estados brasileños:
BR-PR Paraná
BR-SP São Paulo
BR-SC Santa Catarina
BR-RS Rio Grande do Sul
La lista oficial puede consultarse en la plataforma ISO [4]. Para una referencia rápida, también existe la página ISO 3166-2:BR, que enumera los códigos de los estados brasileños [5].
El cuarto campo es la ciudad.
El quinto campo es el código postal. Existe en el formato, pero normalmente no recomiendo utilizarlo para los proveedores. La propia RFC trata este campo con precaución, porque puede dar demasiada granularidad [1].
Para el ISP, en la mayoría de los casos, el país, el estado y la ciudad son suficientes.
La geolocalización es aproximación, no GPS
Este punto es más importante de lo que parece.
Cuando hablamos de geolocalización, es fácil caer en la tentación de intentar ser demasiado precisos. Pero la geolocalización IP no es un GPS.
En NANOG 96, Sid Mathur presentó una charla titulada Geolocalización IP de alta calidad mediante asistentes de codificación de IA y MCP. Uno de los mensajes más útiles de la presentación es precisamente éste: la geolocalización IP es estadística e inexacta. Lo ideal es pensar en regiones geográficas, no en un punto exacto del mapa [6].
Tiene razón: más precisión no siempre significa más calidad.
Para un ISP fijo, que sabe que un prefijo concreto sirve a una ciudad concreta, tiene sentido informar a la ciudad:
192.0.2.0/24,BR,BR-PR,Apucarana,Pero si el mismo prefijo sirve a varias ciudades cercanas, puede ser mejor detenerse en el estado:
192.0.2.0/24,BR,BR-PR,,Esto evita resolver el problema de un cliente y crear un problema a otro.
En la misma presentación, también comenta casos muy reales: usuarios bloqueados por contenidos regionales, streaming pensando que la persona está en otro país, sitios web que muestran el tiempo equivocado e ISP que reciben quejas por algo que a menudo está fuera de la capa de conectividad [6].
Cualquiera que viva en una operación sabe que esto ocurre.
¿El geofeed lo soluciona todo?
No.
Y aquí es importante ser honesto.
Publicar un geofeed no obliga a Google, Netflix, los bancos, MaxMind, IPinfo, Cloudflare o cualquier otro consumidor a aceptar inmediatamente esa información.
La RFC 8805 trata el geofeed como una fuente publicada por el operador. Los consumidores pueden recopilarlo, validarlo, cruzarlo con otras bases de datos y decidir si lo utilizan o no [1].
Aun así, publicar correctamente mejora mucho tu posición.
Antes, tenías que llamar manualmente a varias bases de datos diferentes, cada una con su propio proceso. Con geofeed, creas una fuente pública, normalizada y descubrible automáticamente.
No es una garantía de corrección instantánea, pero es una práctica operativa mucho mejor.
¿Cómo se enteran los demás de tu geofeed?
Publicar el archivo en una URL es sólo una parte de la historia.
Tienes que indicar dónde está este archivo en los registros del bloque IP.
Ahí es donde entra la RFC 9632 [2].
Define cómo asociar un archivo geofeed a objetos del registro de recursos IP, como inetnum y inet6num.
Hay dos formas principales.
La forma más novedosa es utilizar el atributo propio:
geofeed: https://geo.exemplo.com.br/geofeed-192.0.2.0-24.csvLa forma compatible con entornos que aún no admiten el atributo específico es utilizar remarks:
remarks: Geofeed https://geo.exemplo.com.br/geofeed-192.0.2.0-24.csvLo importante es que el consumidor pueda mirar el registro de bloque y descubrir que hay un archivo geofeed asociado a él.
¿Qué pasa con el RDAP?
RDAP es la forma más moderna de consultar los datos del registro.
Mientras que el WHOIS tradicional devuelve texto, el RDAP devuelve JSON. Esto hace que sea mucho más fácil de automatizar.
El RFC 9877 define cómo un servidor RDAP puede informar de enlaces geofeed dentro de la respuesta de un objeto IP [3].
Un ejemplo sería algo así
{
"rel": "geofeed",
"href": "https://geo.exemplo.com.br/geofeed-192.0.2.0-24.csv",
"type": "application/geofeed+csv"
}En otras palabras: el consumidor consulta el RDAP de una IP, encuentra el enlace geofeed, descarga el CSV y procesa la información.
Gana el más específico
La lógica aquí es muy familiar para los que trabajan con redes.
Gana el más específico.
Pero conviene separar dos cosas: la granularidad de la geolocalización no es necesariamente la granularidad del anuncio BGP.
En la Internet real, en IPv4, /24 suele ser la unidad práctica más pequeña para los anuncios globales. Así que si tienes un bloque más grande, como /22, e internamente utilizas cada /24 en una ciudad diferente, el geofeed puede representar esta división mediante /24.
bloco-a/24,BR,BR-PR,Apucarana,
bloco-b/24,BR,BR-PR,Londrina,
bloco-c/24,BR,BR-SP,Sao Paulo,
bloco-d/24,BR,BR-RS,Porto Alegre,Lo importante es entender la regla: cuando hay entradas que se solapan, el consumidor debe considerar la entrada más específica como la mejor coincidencia.
La RFC 8805 permite prefijos anidados e indica al consumidor que utilice la entrada más específica como la mejor coincidencia [1].
La RFC 9632 sigue la misma idea cuando se trata del descubrimiento a través de registros de Internet: debe utilizarse el objeto más específico con una referencia geoalimentada [2].
La calidad del archivo importa
Una mala geoalimentación puede no ayudar. En algunos casos, incluso puede estorbar.
Ejemplo erróneo:
192.0.2.0/24,BR,PR,Apucarana,La correcta es:
192.0.2.0/24,BR,BR-PR,ApucaranaOtro ejemplo erróneo:
192.0.2.0/24,BR,BR-PR,ApucaranaFalta el último campo vacío. Es mejor conservarlo:
192.0.2.0/24,BR,BR-PR,Apucarana,Otro error frecuente es mezclar bloques independientes dentro de un mismo archivo, sobre todo cuando el sistema donde vas a publicar exige un archivo por bloque.
Por ejemplo, si el archivo está asociado al bloque 192.0.2.0/24, no coloques otro bloque independiente dentro de él, como 198.51.100.0/24.
Aunque en las RFC hay supuestos en los que se puede utilizar un único archivo con cuidado, en la práctica operativa es mejor empezar de forma sencilla: un archivo por bloque, que contenga sólo ese bloque o sub-bloques del mismo.
En Brasil, atención a la política actual de Registro.br
Registro.br ha empezado a implementar el soporte para las RFC relacionadas con geofeed.
De momento, la política es más restrictiva. En la práctica, lo más seguro es mantener un archivo por bloque, que contenga sólo el propio bloque o sub-bloques del mismo, en UTF-8, con el número correcto de campos y publicado de forma que el archivo se descargue directamente.
Esto es importante porque una cosa es lo que permite la RFC en términos más generales. Otra cosa es cómo una implementación concreta valida y acepta los datos en ese momento.
Así que, para utilizar Registro.br, piensa en ello así:
bloco 192.0.2.0/24 -> arquivo geofeed-192.0.2.0-24.csv
bloco 198.51.100.0/24 -> arquivo geofeed-198.51.100.0-24.csv
bloco 203.0.113.0/24 -> arquivo geofeed-203.0.113.0-24.csvY cada archivo sólo debe contener el bloque o subbloques correspondientes.
Revisar la cadencia
Geofeed no debería ser un archivo olvidado en el servidor.
Necesita supervisar la operación.
¿Ha cambiado la distribución de los prefijos?
¿Nuevo POP activado?
¿Conseguiste un bloque nuevo?
¿Has transferido fondos?
¿Has ordenado el CGNAT por ciudades?
¿IPv6 reorganizado?
¿Has comprado otro proveedor?
Luego revisa la geoalimentación.
En la presentación de NANOG, una sugerencia interesante es tratar esto con cadencia. Los ISP pequeños pueden revisar mensualmente. Los grandes ISP y los operadores móviles pueden necesitar revisar semanalmente. Las nubes y las CDN pueden necesitar una revisión diaria [6].
Para la mayoría de los proveedores regionales, yo pondría esto en la lista de cambios de la red.
Conclusión
Geofeed es sencillo, pero resuelve un problema real.
Ayuda al proveedor a comunicar de forma normalizada dónde se utilizan sus prefijos IP. No garantiza que todas las bases del mundo lo corrijan inmediatamente, pero crea una referencia pública, organizada y automatizable.
En resumen:
- El RFC 8805 define el formato del archivo;
- El RFC 9632 define cómo descubrir y utilizar estos archivos a través de los registros de Internet;
- El RFC 9877 lleva esta información al RDAP;
- Registro.br ya ha empezado a apoyar este proceso;
- Para Brasil, de momento, es mejor trabajar con un archivo por bloque.
Al igual que RPKI, IRR, PeeringDB, DNS inverso y una buena documentación IPAM, el geofeed pasa a formar parte de la madurez operativa de un ISP.
No se trata sólo de «encontrar una ciudad en Google». Se trata de cuidar la identidad de tus recursos IP en Internet.
Referencias
[1] RFC 8805 – A Format for Self-Published IP Geolocation Feeds
https://www.rfc-editor.org/rfc/rfc8805
[2] RFC 9632 – Encontrar y utilizar datos de Geofeed
https://www.rfc-editor.org/rfc/rfc9632
[3] RFC 9877 – Extensión RDAP para datos Geofeed
https://www.rfc-editor.org/rfc/rfc9877
[4] Plataforma de navegación en línea ISO – ISO 3166 / Brasil
https://www.iso.org/obp/ui/#iso:code:3166:BR
[5] ISO 3166-2:BR – lista de códigos de los estados brasileños
https://en.wikipedia.org/wiki/ISO_3166-2:BR
[6] NANOG 96 – Geoalimentación IP de alta calidad mediante asistentes de codificación de IA y MCP
https://nanog.org/events/nanog-96/content/5683/
[7] Vídeo de presentación – Geofeeds IP de alta calidad
https://www.youtube.com/watch?v=x_vbTj_D91I
