v4.0.0

(Another) Prefix Node Rework

Remember the changes to the prefix nodes introduced in v3.0.0? Although adding multiple labels to one node is clean, but querying was just getting too complicated. We also found some cases where normal querying just did not work. This is why we are remodeling the prefix nodes (again)!

Instead of adding multiple labels to a single node, each node type now has its own node (but all still have the Prefix label). While this increases the number of nodes and relationships in the graph, it makes querying considerably simpler:

1. Each IP node has one PART_OF relationship to the most-specific covering prefix of each type.
2. Each Prefix node type has one PART_OF relationship to the most-specific covering prefix of each type.

For the inter-prefix PART_OF relationships there is one catch: A PART_OF relationship between two different types can be between two nodes with the same prefix property (e.g., a BGPPrefix that is also a RPKIPrefix). For relationships between the same type, the PART_OF relationship indicates the most-specific covering prefix.

Warning: The prefix property is now only unique within each subtype. The general Prefix type is still there for convenience, but querying it will just return some prefix, even when prefix filter is specified. The Prefix type should thus not be used in most queries.

Example

MATCH p = (:IP {ip: '102.218.130.10'})-[:PART_OF]->+(:Prefix)
RETURN p

Although hard to see due to the cutoff label, here we see an IP node (blue), that is connected to its most-specific RIRPrefix (green), BGPPrefix (pink), RPKIPrefix (yellow), and RDNSPrefix (orange). The symmetric relationships between these prefixes indicates that they are actually all the same. The BGP and RDNS prefixes then have larger covering prefixes.

MATCH p = ((:RPKIPrefix)-[:PART_OF]->(:RPKIPrefix)){8}
RETURN p
LIMIT 1

The Donut of covering RPKI prefixes. Starts at a /24 and goes all the way to a /16.

What's Changed

• Prefix remodeling in #191

Full Changelog: v3.1.0...v4.0.0