Andreas Schachtner (afs@Germany.EU.net) submitted the following proposal for discussion in Paris (RIPE-DB WG, agenda:2.3) -------------------------------------------------------------------------------- As it is getting more common, to allocate nets according to supernetting, the RIPE database should reflect this. It might change the perspective for a router manager (and might change the technical implications as soon as classless routing will be deployed), if someone realizes that [s]he's in fact seeing a supernetted network instead of a siongle class C. Considering this, I would propose to have thos networks classes in the RIPE DB as <net> <mask> pairs: *in: 192.124.0.0 255.255.0.0 instead of 256 (ok, 254 :-) network entries. The RIPE DB software has to be changed, of course. It would be clever, if for the purpose of indexing the software explodes the <net>,<mask> pair to all networks covered by this. All those index entries should point to the supernetted object, of course. By this, if such a network number comes along, I simply do a query as for an ordinary class C, but get the supernetted as answer. Opinions ? Andreas Schachtner --------------------------------------------------------------------------------
This proposal is a sound one. However, I would a slight change in the syntax: *in: <net-lo> - <net-hi> Reasons: - If a contiguous range consists of two supernet blocks the use of a mask would still make two database objects necessary. Example: 12 contiguous addresses (one 8 and one 4 net block) If a range of network numbers is used this does not happen. Supernet masks can easily be calculated from the range information if needed. - If a naive user queries a network in a range and gets the answer back as <net> <mask>, the meaning of the response will not necessarily be obvious. (The proposed "-" in the syntax is there to make the range meaning even more obvious) Daniel
"Wilfried Woeber, ACOnet, +43(1)58801-3614" <woeber@access.can.ac.at> write s: Andreas Schachtner (afs@Germany.EU.net) submitted the following proposal for discussion in Paris (RIPE-DB WG, agenda:2.3) --------------------------------------------------------------------------- ----- As it is getting more common, to allocate nets according to supernetting, the RIPE database should reflect this.
It might change the perspective for a router manager (and might change the technical implications as soon as classless routing will be deployed), if someone realizes that [s]he's in fact seeing a supernetted network inste ad of a siongle class C.
Considering this, I would propose to have thos networks classes in the RIPE DB as <net> <mask> pairs:
*in: 192.124.0.0 255.255.0.0
instead of 256 (ok, 254 :-) network entries.
The RIPE DB software has to be changed, of course. It would be clever, if for the purpose of indexing the software explodes the <net>,<mask> pair to all networks covered by this. All those index entries should point to the supernetted object, of course.
By this, if such a network number comes along, I simply do a query as for an ordinary class C, but get the supernetted as answer.
Opinions ? Andreas Schachtner --------------------------------------------------------------------------- -----
This proposal is a sound one. However, I would a slight change in the syntax :
*in: <net-lo> - <net-hi>
I have considered this as well. Current proposals for supernet allocation will allocate in powers of 2, however. Anyway, this can be done with this proposal as well. I only have to change my software :-) Andreas Schachtner
Andreas Schachtner <afs@Germany.EU.net> writes:
*in: <net-lo> - <net-hi>
I have considered this as well. Current proposals for supernet allocation will allocate in powers of 2, however.
If someone needs 95 class C networks, I could allocate them two blocks: one of 64 and one of 32 giving 96 networks for two supernet routes. It depends on the tradeoff of consider saving 32 C numbers against adding a route. Daniel
Considering this, I would propose to have thos networks classes in the RIPE DB as <net> <mask> pairs: *in: 192.124.0.0 255.255.0.0 instead of 256 (ok, 254 :-) network entries. Depends on what you take network entries to stand for. Sofar network entries in the RIPE database have always uniquely indentified a network, complete with associated persons etc. This can never be replaced by concatening network into "masked supernets" without serious loss of information. The proposed change is a useful one only for routing, not for information. The only case where I see a use for the proposed change is when an organisation has multiple networks with all the same data; but this is independent of the possible of supernetting and thus could be implemented independent of that. Piet
We have taken a few minutes and implemented the following as a "field trial" until a decision is taken in Paris. The inetnum field now accepts two forms: inetnum: 192.87.45.0 (old form nothing changed) and inetnum: 192.87.45.0 - 192.88.44.0 (new form) The second form indicates a block of networks between and including the two networks mentioned. The first network should be numerically lower than the second. The syntactic sugar " - " is required. Whois will find the block if any of the networks is queried. We now accept such blocks in database updates as part of the "field trial". Daniel
participants (4)
-
Andreas Schachtner -
Daniel Karrenberg -
Piet.Beertemaï¼ mcsun.EU.net -
Wilfried Woeber, ACOnet, +43(1)58801-3614