December 2000 - lir-wg - mailman.ripe.net

Registration Services update
by Nurani Nimpuno 13 Dec '00

13 Dec '00

Dear all, As a follow up on Axel's mail in October, I would like to provide an update of the current status of the Registration Services at the RIPE NCC. As you may have noticed, the wait queue has dramatically been reduced over the last couple of month and is now at more satisfactory 5 working days. We are aiming at further reducing the wait queue but our main priorities for the coming period is to try to stabilise the wait queue at an acceptable level. Over the last period, we have taken both long term and short term measures that have had an impact on the wait queue. These can be summarised as follows: 1. Priority to correctly filled out requests. Well filled-out requests are dealt with swifter and faster than other requests. 2. Less strict with documentation being 100% complete Requests that are not 100% ok, missing relevant but not essential information have been approved but with a request to provide this information in future requests. 3. Less strict with smaller requests/ statistical sampling Less information has been requested for smaller request and "statistical sampling" has been applied when evaluating some requests. 4. Stricter with LIRs who have not read relevant documentation LIRs completely unfamiliar with relevant documentation are requested to read the very basics before proceeding further with the request. 5. Pro-active Assignment Window raises The Assignment Window tool is now fully developed and in use, leading to more pro-active AW raises! LIRs that send in good requests with all necessary documentation quickly get an AW. 6. New staff We have hired five new hostmasters, we have a good team of competent and dedicated hostmasters which is showing in the results coming from the department. 7. Tools to members - The Asused-public tool can now be: A) downloaded and run locally (http://www.ripe.net/ripencc/mem-services/tools/index.html) B) run from our website (http://www.ripe.net/cgi-bin/webasused.pl.cgi) C) run by sending a mail to hostmaster(a)ripe.net, with SENDASUSED in the subject line. - The output will be sent to the 'e-mail' contact(s) of you LIR. We have received very good feedback on this tool and can see that it is resulting in better managed allocations and consequently less audit work for the RIPE NCC. - Asused-public output is also automatically sent to the LIR in New Allocation request. (This to encourage the LIRs to correct possible errors before the intervention of a RIPE NCC hostmaster.) 8. FAQ and TIPS page http://www.ripe.net/ripencc/faq/index.html http://www.ripe.net/ripencc/tips/tips.html We have received very positive feedback on both the FAQ and the TIPS pages. It has especially proven useful for newer LIRs that also represent the bulk of our workload. IN PROGRESS 9. Improving Address Request form With input from people in the community, we are currently working on improving the Request form, which we hope will result in less iterations between the RIPE NCC and LIRs. 10. Tools to members A secure website is currently under development, where LIRs will be able to log in and modify contact information, running audit tools on their own allocation and in the future also send in requests through the website. More information on this will come soon. 11. Increase of LIR courses 2001 The number of courses planned in 2001 has been increased in order to provide additional help and support to new LIRs. We have used several ideas from the May17 Taskforce, also taking in consideration the input from the LIR working group at RIPE 37. We have focused on giving priority to correctly filled out requests, shifting more responsibility to the LIRs, providing the LIRs with useful tools, trying to improve documentation etc. We are happy to see the immediate results some of these measures have had but we are also very aware of all the work we have ahead of us. We are determined to further improve both response time and quality of service and will continue our efforts in 2001. Kind regards, Nurani Nimpuno Registration Services Manager RIPE NCC http://www.ripe.net

1 0

AS Macro
by Alison Gudgeon 11 Dec '00

11 Dec '00

Hi All, Can anyone help with this quick question I want to create an AS Macro - do I submit this to hostmaster(a)ripe.net or via auto-dbm(a)ripe.net Also - who choses the AS Macro the ISP or RIPE? Many Thanks in Advance, Alison

2 1

Announcement: RIPE Whois Database version 3.0 beta is out
by RIPE Database Administration 08 Dec '00

08 Dec '00

Dear All, [ Apologies for duplicate messages ] This mail is to inform you that version 3.0 beta of the RIPE Whois Database is out. Read on! You will be affected too. The RIPE Database is about to change its data format, from RIPE181 to RPSL (the Routing Policy Specification Language, see RFC2622). This will affect all object types, including "person", "domain" and "inetnum". The version 2 of the RIPE Database, the one currently in production on whois.ripe.net, will in the next months be replaced by version 3. All the entries in the RIPE Database will be translated into RPSL format, and that is the format you will get when you will be querying the Database. Don't be mistaken: for the moment, whois.ripe.net continues running with version 2 and answering to your queries in the old-fashioned way. But this will not last forever; in a few months, all will become RPSL. So if you use the Whois database, we encourage all of you to prepare for this change as soon as possible. We strongly suggest you to start to get used to RPSL and version 3.0 . In this aim, you can do the following: - Query rpsl.ripe.net at port 43. You will find there exactly the same objects that are in whois.ripe.net, mirrored live and in RPSL format. - If you have any script that runs by querying whois.ripe.net, test it by pointing it to rpsl.ripe.net and make it v3.0-compliant. - Try our CGI interface to the RPSL server: you can find it at http://www.ripe.net/ripencc/pub-services/db/reimp/. - Get to know the new update path: use our "sandbox" database for RPSL updates. Send your updates to <auto-rip(a)ripe.net> and query the corresponding database at rpsl.ripe.net, port 4343 . Remember that in a few months, that's the way the RIPE Database will be running; so the earlier you start working with it, the less likely you are to be unpleasantly surprised later. We are currently preparing additional resources to help ease the transition; we will announce them as soon as they are available, which will happen later this month. Please note that the software is still in a "beta" phase. So we need your feedback! If you happen to find something that looks like a bug when you are testing the RPSL database, don't hesitate... Send us a bug report at <dbrip(a)ripe.net> ! If you want to actively participate to the migration effort, you could join the "RIP migration Task force" and let yourself be heard. Just write to <ripe-dbm(a)ripe.net> and ask to join the Task Force. For the ones interested in viewing or trying the code, you can download it at: ftp://ftp.ripe.net/ripe/dbase/reimp/whois-rip-3.0beta1.tar.gz You can also join a discussion list related to version 3.0 beta of the RIPE Database Software. To subscribe to this list, send a message to <majordomo(a)ripe.net> with the line: subscribe db-beta in the body of your letter. It is a moderated mailing list so some delays in subscription are possible. Regards, The RIPE Database Group.

1 0

Re: Allocations for "always-on" ISPs
by Nick Hüni 08 Dec '00

08 Dec '00

Why don't you guys use the newsgroups instead of "spamming" your opinions all over busy people... Thnaks. Nick >>> Kurt Erik Lindqvist <kurtis(a)kpnqwest.net> 12/07/00 17:01 PM >>> > It seems Kurt Erik Lindqvist wrote: > >That ofcourse depends on what services you want to offer your > >customers..... > > > >I don't see why you want to break services in order to solve assignment > >policies? This said, I do realise that there is a assignment policy aspect > >to this as well. > > You might realise that you will end up breaking promises to customers if > the offered services collide with acceptable assignment policies. I do. That is why I wrote that I realise that this is a problem. But I am seeing more and more companies offering Internet connections while in reality what the customer is getting is more or less a Intranet connection. This is a complex issue that in the end is up to what the customer has bought. > We are going to run out of IPv4 space very quickly if the assignment of, > for instance, /29's to home users becomes standard procedure at ISP's - and > bruno's mail does indicate that this is already happening: > > "[...]several new ISP in Europe are starting to offer "always on" Internet > access. The interesting part is ofcourse not that people are offering it. The interesting part is how many do actually sign up? Always on Internet have been around in Europe since the early '80:s. The price might have been somewhat high for consumers though...:) As I pointed out earlier and others as well - Maybe buy starting to use the address space for what it was intended for to provide a Internet connection) we can get a real push to go for another addressing scheme like IPv6 or IPv8 (just kidding). Or maybe something completly new. Best regards, - kurtis - Kurt Erik Lindqvist Kurtis.Lindqvist(a)KPNQwest.SE KPNQwest Sweden @ The speed of light http://www.kpnqwest.se PO Box 23163 S-10435 Stockholm

3 2

Re: Allocations for "always-on" ISPs
by Wilfried Woeber, UniVie/ACOnet 07 Dec '00

07 Dec '00

[ individual addresses stripped... ] Leigh, =From: Leigh Porter <leigh(a)insnet.net> =Subject: Re: Allocations for "always-on" ISPs = ="Neil J. McRae" wrote: = =And if they need address space the ASP knows, about, they can use some =kind of tunneling mechanism ...now I'm lost! What is the _some_ in "some kind of tunneling mechanism? And how do you propose to take care of the re-configuration on the customer's end for the tunnel? Dynamic DNS with TTL close to 0? Whater it is, it should be available for all of the "popular" operating systems, btw. =back to the ASP network so they have consistant addressing, even if their =providor uses dynamic addressing. Which requires some sort of (non-trivial?) static routing entries on the customer's end nodes and/or some sort of routing support by the "basic" transport provider. =-- =Leigh Porter =C&W If there is a reasonable solution for that, I'd really like to deploy that for my ADSL link (which only offers dynamic addresses ;-). Both for becoming a subnet in my universities LAN as well as for IPv6! Wilfried. _________________________________:_____________________________________ Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at UniVie Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 A-1010 Vienna, Austria, Europe : RIPE-DB: WW144, PGP keyID 0xF0ACB369 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

2 1

Re: Allocations for "always-on" ISPs
by Karl Jeacle 07 Dec '00

07 Dec '00

"Neil J. McRae" <neil(a)COLT.NET> wrote: > NAT is your friend - very few home users need real IP addresses. True, but the problem is logging the NAT translations to track down abuse cases. Since attacks on other sites will appear to come from NAT pool address, it's impossible(?) to find out which NAT'd user had a particular public IP address at a particular time. Sure, you might know what private IP address they had, but how do you log the translations? I think this make it very difficult to justify using NAT in public ADSL/Cable environments. I've heard that NAT logging is somewhere on Cisco's roadmap, but until it's available, or some other scalable NAT logging solution is possible, it looks like public IP addresses are the only viable option. Karl

1 0

RE: Allocations for "always-on" ISPs
by Sykes, Phil 07 Dec '00

07 Dec '00

>> Is there any way to reduce the address space fragmentation >> due to new non contiguous allocations ? > > I guess you need to use up your allocated block quickly > enough to allow you to get the next contiguous block. :) Also worth noting - your initial allocation can be larger than a /20 if you can convince RIPE that it will be needed quickly, and any further allocation will be of a size representative of how quickly you have used your current address space. Thus, if you burn through a /20 in a week, your next allocation will be somewhat larger. The figures for how quickly you have to go to justify larger address blocks are, I guess, not published. Cheers, Phil Sykes, Network Engineer Cable & Wireless Global Network p: +49 89 92699 204 m: +49 172 89 79 727

1 0