Routing prefixes in the RIPE database?

Havard,

Thanks for starting this disussion.
Here's some comments from a database implementation point of
view, and some things we have discussed here at the NCC wrt aggregates
and/or prefixes.

There's two things in our view here:

- the RIPE database should become classless
	ie move to general classless type addressing that can be of the
	form:

		<begin> - <start>	# very general
		<begin> <mask>
		<begin>/<bits>

	we like the first form as general representation to keep them
	similar to what we have now. The other two could be accepted
	by the software, but would be rewritten to the first one. Of
	course extra flags could be added to the database to force a
	different representation, and tools to convert from one to the
	other are reasonably simple.

- the RIPE database should contain aggregates
	the idea here is to create a new object that would indicate
	someone that would aggregate for someone else; proxy
	aggregation.

Now, the first thing we should try and figure out is if we move all
routing information into a new object, or do we keep the "inetnum"
object for this, with the classless extensions above, and something
special for proxy aggregation. Personally I have no strong feelings
either way.

Now, for implementation:

 * Hint for implementation in the RIPE database: from a routing prefix eg.
 * "129.240/15" create keys for all the natural IP network numbers covered by
 * this prefix with pointers to the routing prefix object.  This should be a
 * fairly straight-forward approach (say I who haven't really hacked on the
 * RIPE software... ;-)  Side-effect: lookup of unassigned network numbers
 * within a routing prefix after this change will no longer give the "No
 * entries found for the selected source(s)" result when whois is used, but
 * instead the routing prefix(es) will be returned, but no inetnum object.

We thought of this one as well of course, and the move to anything
classless would mean a redesign of IP netnumber indexing in the
database. We know we have to do this, but we have not yet found a
suitable way of implementing this right now. The new indexing would
then be real classless, so it would conists of something like ranges,
and anything in that range would match that object, including
hostaddresses even (with classless you cannot tell anymore what is a
hostaddress and what is a netaddress in some cases). Disadvantage is
that nets that have no "inetnum" but do fall in a aggregate or prefix
or something like that that object will show up. You could even
explain that as a feature ;-)


I'd say, let's get some discussion on this. Also people who have ideas
on indexing classless IP numbers are more than welcome.

-Marten