Clarifying semantics of ip2prefix with BGP, RIR, and GeoFeed (Starlink) prefixes

[Vrittigyl]

I’d like to clarify the intended direction for ip2prefix in light of the comments about Starlink’s GeoFeed and prefix semantics.

As I understand it, ip2prefix currently links IPs to prefixes purely based on CIDR containment, treating all :Prefix nodes uniformly. In practice, prefixes represent different concepts: BGP prefixes (routing/origin), RIR prefixes (allocation), and GeoFeed prefixes (intended geolocation, e.g. Starlink).

The Starlink GeoFeed (geoip.starlinkisp.net/feed.csv) highlights this issue, since it provides geolocation intent and should coexist with BGP/RIR prefixes without being hierarchically mixed with them.

My understanding is that an IP should be able to belong to multiple prefix types in parallel (e.g. BGP + GeoFeed), while prefix-to-prefix PART_OF relationships should be restricted to semantically compatible prefix types rather than created solely based on CIDR containment.

Could you please confirm whether this interpretation is correct, and whether the expectation is for ip2prefix itself to become aware of prefix semantics, or for this separation to be enforced at the data model / labeling level outside of ip2prefix?

[m-appel]

Hi,

you should probably look at the ip2prefix code again. It does not treat all nodes uniformly and does two things:

1. Connect IP and prefix nodes: For an IP node one PART_OF relationship to the longest-prefix match of each prefix subtype (e.g., BGPPrefix, RIRPrefix) is created.
2. Connect prefix nodes: Prefix nodes are iterated per subtype. For a prefix node one PART_OF relationship to the covering prefix of each subtype is created. Within the same subtype (e.g., (:BGPPrefix)-[:PART_OF]->(:BGPPrefix) the covering prefix has to be larger, for connections between different subtypes it can be the same prefix. This is necessary, since multiple nodes with the same prefix property can exist in the graph, but with different subtypes.

We already have a GeoPrefix node type btw. but GeoFeed implementation is not straightforward since their location information is not standardized and we do not have a concept of city or region yet.

[Vrittigyl]

Thanks for the clarification. I rechecked the ip2prefix code and I see now that it already handles prefixes per subtype and does not mix semantics the way I initially assumed.

I also confirmed that GeoPrefix nodes already exist from other datasets, but Starlink’s GeoFeed is not ingested yet. Integrating Starlink would involve handling location fields like country/region/city (e.g. 74.244.51.0/24, US, US-CA, San Jose).

Would you prefer:

• a minimal Starlink GeoFeed ingestion as additional GeoPrefix nodes with raw location properties, relying on the existing ip2prefix behaviour, or

• to hold off on GeoFeed ingestion until location semantics (city/region) are defined more formally?

I’m happy to explore normalisation if that’s the desired approach.

Thanks!

[m-appel]

GeoFeed will have to wait. Not only do we not have good semantics in the graph, there is also the problem of different feeds using slightly different spelling for cities.

For example, the main source we plan to use is this file: https://geolocatemuch.com/geofeeds/validated-all.csv
Looking for "Washington" in that file, some specify "Washington D.C.", some "Washington" (although they mean the city, as indicated by the region code US-DC. So what do we do here? Normally we do not want to touch the data when integrating into the graph (rather fix the source), but this might decrease usefulness.

Long story short, we have to think about the modeling properly first, but that will take some time.

[Vrittigyl]

Thanks, that clears it up. I understand the issue now. I’ll think a bit about how the location semantics could be normalised in a clean and consistent way:)