lowering maximum assignment window
Hi all, Below is my original message with a proposal to lower the maximum assignment window to a /21 instead of a /19. There was much discussion about this on the lir-wg mailing list. Here is our final proposal that tries to take all the comments into consideration: All registries that currently have a /20 or /19 assignment window will be at a rotating interval (doing them all at once would put too much of a load on an already large wait queue) set to a /23 assignment window temporarily. They will then need to start sending a few requests to show that they understand the assignment policies and procedures. If these requests are fine, we will raise their assignment window to a size that matches the requests we have seen from them (therefore not necessarily to a /19). Hopefully this will get these registries on an equal footing with other LIRs. The reason we need to review the assignment window for all of these registries is that they started out with a /19 assignment window in the beginning of the RIPE NCC. Whereas younger registries started out with a 0 assignment window and have since then proven that they can handle assignents of a certain size and have therefore had their assignment window raised. For all of the younger registries we already have a procedure in place of doing random audits and we will continue doing this. By the way, one of the results of this discussion was that Poul-Henning Kamp wrote a script that checks for inconsistencies between addresses that are in use but are not registrered in the RIPE database. These statistics can be found at: http://stat.cybercity.dk/ripe/ Please check this page for your own registry ID to see whether your registry has any inconsistencies to fix. Of course the RIPE NCC will also be contacting the Registries with the largest list of inconsistenceis as well, but we don't have the resources to systematically contact every registry on the list. Kind regards, Paula Caslav RIPE NCC ------- Forwarded Message Date: Wed, 10 Feb 1999 14:41:17 +0100 From: Paula Caslav <paula@ripe.net> Sender: owner-lir-wg@ripe.net To: lir-wg@ripe.net Subject: lowering maximum assignment window Hi all, As we discussed in our audit report at the Local IR working group at the RIPE 32 meeting, we would like to propose a change in the maximum assignment window that a Registry can have. Currently an assignment window for a Registry can be anything between a 0 and a /19. The /19 assignment window, is a historical legacy. These Registries were for the most part free to assign up to 8192 addresses to a customer without coming to the RIPE NCC for approval. Since some of them are still operating as Local Registries, and they still have a /19 assignment window, this means that we have very little contact with them and we have seen in doing audits on these Registries that many of them are out of date with the procedures for assigning IP addresses, and using the database. We also notice that most of them do not really use this large assignment window fully- meaning that most of their assignments are smaller. The router technology has changed much in the last few years, which means that assignments to customers in general are much smaller. Given the fact that most Registries rarely make such large assignments, and the fact that having such a large assignment window makes it easy for them to lose touch with the RIPE NCC policies, we would like to propose having a lower maximum assignment window. We think a /21 maximum assignment window would be more reasonable. Actually for most Registries, a /24 or /23 assignment window is enough, since they rarely make larger assignments than that. However, for the Registries that make more large customer assignments, having up to a /21 assignment window would allow them room to make most of these larger assignment without coming to us for approval. Please think about this proposal and give us any comments by the end of next week. Kind regards, Paula Caslav Registration Services Manager RIPE NCC ------- End of Forwarded Message
Hi Paula,
By the way, one of the results of this discussion was that Poul-Henning Kamp wrote a script that checks for inconsistencies between addresses that are in use but are not registrered in the RIPE database. These statistics can be found at: http://stat.cybercity.dk/ripe/
These statistics are a very valuable contribution to the community. I'd be even more delighted, were they not cramped into one 3 Megabyte file. I didn't even try any graphical browser on this. Good old lynx did the job anyway ;-) But you know I just don't like to wait... So my idea to Poul-Henning: Just split it down to the country codes. That will decrease traffic to your website I suppose Best regards, Elmar. -- | \ / |\/| Gesellschaft fuer Internet, Vernetzung und Mehrwertdienste mbH | \/ | | Zissener Str. 8 - D-53498 Waldorf - +49 2636 9769-0 - Fax -999 The Net People. Elmar K. Bins (ekb@ivm.net) http://www.ivm.net/
By the way, one of the results of this discussion was that Poul-Henning Kamp wrote a script that checks for inconsistencies between addresses that are in use but are not registrered in the RIPE database. These statistics can be found at: http://stat.cybercity.dk/ripe/
Btw, Im not sure how this was determined... for example, Netvision has over 600 of its dial-in IP's listed over there - the only ones listed - from the 62.0.128.0/18 block. These IPs are registered as one block in the RIPE DB, and the IPs are used in our POPs. What is the nature of the inconsistency? Just wondering. Sincerely, \'"'/ Barak Engel ( o o ) ---------------------ooOO-^-oOOo--------------------------- barak@netvision.net.il Network Expert BE-RIPE BE174 Phone/Fax: +972 48 560600/551132 Cellular: +972 50 469 341 -----------------------------------------------------------
Dear Barak, I think the problem is this: inetnum: 62.0.128.0 - 62.0.191.255 netname: NV-POPS descr: Netvision POPs country: IL admin-c: NN105-RIPE tech-c: NN105-RIPE status: ALLOCATED PA mnt-by: NV-MNT-RIPE mnt-lower: NV-MNT-RIPE changed: barak@netvision.net.il 19981228 source: RIPE You have "ALLOCATED" in the status attribute. A registry can only make assignments, therefore it should say "ASSIGNED" only the RIPE NCC can make allocations. I think this will be the cause of many of the inconsistencies on the list. If you have an inconsistency like this, please change the status attribute to say ASSIGNED instead of ALLOCATED. Kind regards, Paula Caslav RIPE NCC "Barak Engel" <barak@netvision.net.il> writes: * > > By the way, one of the results of this discussion was that Poul-Henning * > > Kamp wrote a script that checks for inconsistencies between addresses * > > that are in use but are not registrered in the RIPE database. These * > > statistics can be found at: http://stat.cybercity.dk/ripe/ * * Btw, Im not sure how this was determined... for example, Netvision has over * 600 * of its dial-in IP's listed over there - the only ones listed - from the * 62.0.128.0/18 block. These IPs are registered as one block in the RIPE DB, a * nd * the IPs are used in our POPs. What is the nature of the inconsistency? * * Just wondering. * * Sincerely, \'"'/ * Barak Engel ( o o ) * ---------------------ooOO-^-oOOo--------------------------- * barak@netvision.net.il Network Expert BE-RIPE BE174 * Phone/Fax: +972 48 560600/551132 Cellular: +972 50 469 341 * ----------------------------------------------------------- * *
In message <199902241048.LAA07700@x30.ripe.net>, Paula Caslav writes: Would it be an idea to go throught he database for all "ALLOCATED" objects not maintained by RIPE and change them to ASSIGNED and then have the database software reject such records in the future ?
A registry can only make assignments, therefore it should say "ASSIGNED" only the RIPE NCC can make allocations. I think this will be the cause of many of the inconsistencies on the list. If you have an inconsistency like this, please change the status attribute to say ASSIGNED instead of ALLOCATED.
-- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far!
Hi, Thus wrote Poul-Henning Kamp (phk@critter.freebsd.dk):
In message <199902241048.LAA07700@x30.ripe.net>, Paula Caslav writes:
Would it be an idea to go throught he database for all "ALLOCATED" objects not maintained by RIPE and change them to ASSIGNED and then have the database software reject such records in the future ?
That would probably be a good idea. BTW, the statistic also happened to find non-CIDR ClassC.0 - ClassC.0 entries, but I fear the ones you found weren't all of these from our (Xlinks) allocations. :-} db-scrubbingly yours, Petra Zeidler -- i.A. Petra Zeidler, Neukundenanschluss Xlink Internet Service GmbH [X] zeidler@xlink.net [X] Tel: 0721/9652-220 [X] Fax: 0721/9652-209 [X] Geschaeftsfuehrer: Michael Rotert. Amtsgericht Karlsruhe HRB 8161. [X] Auftraege erledigen wir zu unseren Allgemeinen Geschaeftsbedingungen.
Poul-Henning Kamp wrote:
In message <199902241048.LAA07700@x30.ripe.net>, Paula Caslav writes:
Would it be an idea to go throught he database for all "ALLOCATED" objects not maintained by RIPE and change them to ASSIGNED and then have the database software reject such records in the future ?
A registry can only make assignments, therefore it should say "ASSIGNED" only the RIPE NCC can make allocations. I think this will be the cause of many of the inconsistencies on the list. If you have an inconsistency like this, please change the status attribute to say ASSIGNED instead of ALLOCATED.
Personally I think that LIRs *should* be allowed to give objects a status of "ALLOCATED" in some circumstances. Imagine, if you can, your typical supernational registry which gets multiple address blocks allocated by the NCC for redistribution amongst the LIR's 20 or or more associated organisations. Here a lower level "ALLOCATED" inetnum could be used to keep track of this redistribution (if only the NCC's auditing tools didn't automatically assume that these - carefully labelled - allocations were duplicate assignments. Another possible use for LIR "ALLOCATED" inetnum objects would be to keep track of where a range of addresses was being used for assignments to VSE customers connected at a particular point of presence. ... just my thoughts from several years of running a large supernational registry and currently being in the middle of a lengthy registry audit by the RIPE NCC... ;-) James ----- ___ - James Aldridge, Senior Network Engineer, ---- / / / ___ ____ _/_ -- EUnet Communications Services BV --- /--- / / / / /___/ / --- Singel 540, 1017 AZ Amsterdam, NL -- /___ /___/ / / /___ /_ ---- Tel: +31 20 530 5327; Fax: +31 20 622 4657 - ----- 24hr emergency number: +31 20 421 0865
On Fri, Feb 26, 1999 at 07:56:38PM +0100, James Aldridge wrote:
Another possible use for LIR "ALLOCATED" inetnum objects would be to keep track of where a range of addresses was being used for assignments to VSE customers connected at a particular point of presence.
*chuckle* We tried to explain this kind of usage to the NCC about two years ago. No chance. Now we just keep such objects in an internal database and carefully screen them out when updating the RIPE database. Greetings, -- i.A. Michael van Elst / phone: +49 721 6635 330 Xlink - Network Information Centre \/ fax: +49 721 6635 349 Vincenz-Priessnitz-Str. 3 /\ link http://nic.xlink.net/ D-76131 Karlsruhe, Germany /_______ email: hostmaster@xlink.net [ Xlink Internet Consulting GmbH, Sitz Koeln ] [ Amtsgericht Koeln HRB 3526, Geschaeftsfuehrer: Michael Rotert ]
Agreed. "LIR-ALLOCATED" would be good especially with IPV6 on the way.
Personally I think that LIRs *should* be allowed to give objects a status of "ALLOCATED" in some circumstances.
Imagine, if you can, your typical supernational registry which gets multiple address blocks allocated by the NCC for redistribution amongst the LIR's 20 or or more associated organisations. Here a lower level "ALLOCATED" inetnum could be used to keep track of this redistribution (if only the NCC's auditing tools didn't automatically assume that these - carefully labelled - allocations were duplicate assignments.
Another possible use for LIR "ALLOCATED" inetnum objects would be to keep track of where a range of addresses was being used for assignments to VSE customers connected at a particular point of presence.
... just my thoughts from several years of running a large supernational registry and currently being in the middle of a lengthy registry audit by the RIPE NCC... ;-)
James
----- ___ - James Aldridge, Senior Network Engineer, ---- / / / ___ ____ _/_ -- EUnet Communications Services BV --- /--- / / / / /___/ / --- Singel 540, 1017 AZ Amsterdam, NL -- /___ /___/ / / /___ /_ ---- Tel: +31 20 530 5327; Fax: +31 20 622 4657 - ----- 24hr emergency number: +31 20 421 0865
---------------------------------- Stephen Burley Senior Hostmaster for UUNET Date: 01-Mar-99 Time: 08:12:32 http://www.uk.uu.net ---------------------------------- An MCI WorldCom Company
In message <19990223232409.63200@ivm.net>, "Elmar K. Bins" writes:
Hi Paula,
By the way, one of the results of this discussion was that Poul-Henning Kamp wrote a script that checks for inconsistencies between addresses that are in use but are not registrered in the RIPE database. These statistics can be found at: http://stat.cybercity.dk/ripe/
These statistics are a very valuable contribution to the community. I'd be even more delighted, were they not cramped into one 3 Megabyte file. I didn't even try any graphical browser on this. Good old lynx did the job anyway ;-)
But you know I just don't like to wait...
So my idea to Poul-Henning: Just split it down to the country codes. That will decrease traffic to your website I suppose
You know, I thought about that, but then I thought: The people most incovenienced by the size are the same people who has most work to do... :-) -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far!
participants (8)
-
Barak Engel -
Elmar K. Bins -
James Aldridge -
Michael van Elst -
Paula Caslav -
Petra Zeidler -
Poul-Henning Kamp -
Stephen Burley