When Internet Blocking Creates Borders
October 14, 2026
By César Díaz, Head of Telecommunications Affairs at LACNIC.
I have always enjoyed working on cars, and for years I have subscribed to a website dedicated to my vehicle’s make. It is a do-it-yourself (DIY) resource where owners and enthusiasts can find technical information, learn how their cars work, and tackle some repairs on their own.
One of the resources I used most often was the collection of automotive schematics and diagrams. They showed how different parts of the engine, bodywork, and other vehicle components fit together, along with their part numbers and technical descriptions.
Then, one day, the diagrams disappeared.
(Free access, no subscription required)
The site was still working. I could browse it, look up descriptions and even see the part numbers, but the images with the diagrams were no longer available. My first reaction was to assume it was a problem with the site.
So I tried a simple experiment: I switched to a different Internet provider without changing my device or my physical location. To my surprise, the diagrams came back.
Nothing about me, my computer, or my location had changed. The only difference was my Internet provider—and therefore the public IP address I was using to reach the website.
The site was still working. I could browse it, look up descriptions and even see the part numbers, but the images with the diagrams were no longer available. My first reaction was to assume it was a problem with the site.
So I tried a simple experiment: I switched to a different Internet provider without changing my device or my physical location. To my surprise, the diagrams came back.
Nothing about me, my computer, or my location had changed. The only difference was my Internet provider—and therefore the public IP address I was using to reach the website.
I started looking into what might have caused this. According to the information I found, the vehicle manufacturer had sent a cease-and-desist notice to the content hosting provider over intellectual property rights to the diagrams. This had apparently led to a geolocation-based restriction on IP addresses, commonly known as GeoIP blocking.
So How Does It Work?
The website looks up geolocation data associated with the IP address from which the connection originates. Based on that information, it estimates the country from which the site is being accessed and may then apply a simple access rule:
There is a crucial distinction, however: an IP address does not encode the user’s precise geographic location. That location is inferred from external data.
That is what made my experience seem so contradictory. I had not crossed any border, but the location assigned to my IP address apparently had. And I had not used a VPN.
This small example allows me to introduce a much broader problem: the Internet was not designed around countries’ geographic borders. Yet certain blocking measures use IP addresses and the locations attributed to them to try to impose those borders on the Internet.
IP Addresses Do Not Come with a Geographic Location
National borders define the territorial limits of a state’s jurisdiction. The Internet is organized differently.
IPv4 and IPv6 addresses identify network interfaces and allow packets to be routed between networks. Neither protocol includes a field specifying a person’s country, city, or physical location.
External sources and geolocation databases are used to estimate that location.
There is an important difference here. Regional Internet Registries such as LACNIC maintain information about the organizations that receive and manage Internet number resources. However, the place where an organization is registered may be different from the places where it actually uses its IP addresses.
A network operator might deploy its resources across several countries or cities, relocate infrastructure, or serve an entire region. Administrative records accessed through WHOIS or RDAP should therefore not be taken as a direct indication of where the people using those addresses are located.
Geolocation providers rely on different data sources and methodologies. As a result, two databases can assign the very same IP address to different places.
Geofeeds are designed to make those estimates more accurate by enabling operators to publish the locations where their IP prefixes are used. RFC 8805 specifies the publication format. RFC 9632, which superseded RFC 9092, explains how to discover and use geofeed data and includes an optional RPKI-based mechanism for authenticating it.
LACNIC has encouraged geofeed adoption across Latin America and the Caribbean to improve information on where Internet number resources are deployed. Even so, the distinction remains essential: a geofeed can tell us where a resource is used; it cannot pinpoint a user’s exact coordinates or reveal who is behind an IP address.
When an Estimate Determines Who Can Access
IP geolocation serves many legitimate purposes: selecting a language automatically, routing traffic to nearby infrastructure, detecting anomalies, and enforcing certain territorial content rights. Problems begin when an estimated location determines whether someone can access a service.
A platform may decide to allow or deny access because a database places an IP address in a particular country. If the underlying estimate is wrong, the access decision can be wrong too.
It is therefore useful to distinguish geolocation from blocking. Geolocation seeks to estimate where a connection is located. Blocking is the decision made using that information—among other possible factors.
The danger lies in treating an estimate as a fact and then using it to deny access.
Blocking One IP Address Can Block Far More Than Intended
Consider a different situation: a court or other legal authority orders an Internet service provider to block an IP address linked to a particular website or service.
In this case, it is not the website deciding that a user is inside or outside a territory. The restriction is enforced within the Internet provider’s own network. The problem is that one IP address does not always correspond to one website.
Cloud platforms, shared hosting, reverse proxies, and content delivery networks (CDNs) allow many domains and services to run on the same infrastructure—and sometimes the same IP address.
What if the blocked address also serves websites or services entirely unrelated to the content behind the order?
We may end up blocking those services as well. In effect, it would be like closing an entire building to prevent access to just one office.
This phenomenon is known as “overblocking” and is one of the main risks of using IP addresses as a restriction mechanism. RFCs 7754 and 9505 examine the limitations of different blocking mechanisms and their possible effects on third parties.
So the question is not simply, “Did we block the targeted content?” It is also, “What else did we block along the way?”
Too Much Blocking—and Still Not Enough
This brings us to one of the paradoxes of IP-address-based blocking. It can be excessively broad, disrupting unrelated websites, services, and users sharing the same infrastructure. Yet it may still fail to stop people intent on reaching the targeted content: they can switch networks, use a VPN or proxy, or find another way in.
In other words, a measure can block too many people who were never its targets while doing too little to block those who were.
None of this suggests that every block is unjustified. Governments, courts, platforms, and rights holders may have legitimate reasons to act, including protecting intellectual property, preventing fraud, strengthening cybersecurity, or enforcing court orders. But having a legitimate objective does not guarantee that every technical method is suitable.
A legal decision stating “prevent access to this content” may ultimately be implemented technically as “block this IP address,” and those two things are not equivalent.
Before implementing a measure of this kind, it would be worth asking: What other services use that infrastructure? How many users could be affected? How reliable is the geolocation information being used? Are more precise alternatives available? Are there mechanisms for detecting and correcting errors? How long will the block remain in place?
Necessity, proportionality, transparency, and minimizing unintended harm should guide not only legal decisions but also the technical choices used to enforce them.
A Signal, Not a Border
An IP address can offer useful clues about where a connection originates. But it is not a person’s identity, a precise location, or a border.
The challenge arises when a technical estimate becomes an access decision. A block may pursue a legitimate objective and yet affect users or services that have nothing to do with what it seeks to restrict.
The missing diagrams on that automotive website were a small illustration of this problem. I had not moved or crossed into another country. I had merely changed Internet providers, and the system interpreted my connection differently.
That is why blocking measures must be evaluated not just by what they aim to achieve or how effective they are, but also by their accuracy, proportionality, and potential impact on third parties.
The Internet was not built around national borders. When we try to enforce such borders through technical blocks, we need to ask not only what we want to keep out, but also who may unintentionally be left on the wrong side.
References
LACNIC. (s. f.). What are the differences between geofeeds and WHOIS information? https://www.lacnic.net/4871/1/lacnic/que-diferencias-hay-entre-geofeeds-y-la-informacion-de-whois
Kline, E., Duleba, K., Szamonek, Z., Moser, S., & Kumari, W. (2020). A format for self-published IP geolocation feeds (RFC 8805). Internet Engineering Task Force. https://www.rfc-editor.org/info/rfc8805/
Bush, R., Candela, M., Kumari, W., & Housley, R. (2024). Finding and using geofeed data (RFC 9632). Internet Engineering Task Force. https://www.rfc-editor.org/info/rfc9632/
Barnes, R., Cooper, A., Kolkman, O., Thaler, D., & Nordmark, E. (2016). Technical considerations for Internet service blocking and filtering (RFC 7754). Internet Architecture Board. https://www.rfc-editor.org/info/rfc7754/
Hall, J. L., Aaron, M. D., Andersdotter, A., Jones, B., Feamster, N., & Knodel, M. (2023). A survey of worldwide censorship techniques (RFC 9505). Internet Research Task Force. https://www.rfc-editor.org/info/rfc9505/
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of LACNIC.