- lir-wg - mailman.ripe.net

Ripe 141 problem
by Mehdaoui Salma 14 Dec '00

14 Dec '00

Hello, I have sent a request for new addresses (ripe 141) and the answer was that I might have to wait up to a week for an initial response. I would like to precise that the request is very urgent, we need new addresses for our end users. I hope that we will have an answer as soon as possible, to enble us to satisfy our custmors requests. Please send a copy of your answer to satff(a)iam.net.ma Regards Salma

3 2

auto-dbm problems
by Okan Cimen 14 Dec '00

14 Dec '00

Hello, I am trying to update some information about our networks. I have sent the new information to auto-dbm(a)ripe.net but could not get a response for almost 6 hours. Does ayone have a suggestion about it? Is there a problem? Regards Okan

7 8

R: Allocations for "always-on" ISPs
by Pelosi Alessandro,Swisscom Italy 14 Dec '00

14 Dec '00

Ciao I read with a lot of interest the quantity of email regarding this problem. I think that we must avoid to generalize this problem. In most cases NAT or PAT are good solutions both to save waste of Ip addresses (v4 or v6)and to security. In many other cases there is the need to have public IP addresses both for clients and for servers, depends which applications run on these machine and how technology evolves. fortunately we are reducing the waste of ip addresses with new protocols and new features (http 1.1 teaches). Now we are assisting to the birth of many new services that need public ip addresses such as GPRS, video streaming, web controlled machines and so on. I think that in the lounch period of these services there will be a great deal of use of them simply because this is the simplest way to start and debug. I fund a little circuit that works like a web server and can be used to web remote control any kind of device, startink from the washing machine to the coffee distributor etc... http://world.std.com/~fwhite/ace/index.html http://world.std.com/~fwhite/ace/ace2.html To summarize I thing that we should allow to use public ip addresses to those who need and use them (home users, isp, companies and so...), with a little more control about the effective need and usage. Ing. Alessandro Pelosi Network Engineer SWISSCOM SpA Milano +39.02.40.934.312 -----Messaggio originale----- Da: Bruno Ciscato [mailto:bruno@flashnet.it] Inviato: mercoledì 13 dicembre 2000 9.53 A: lir-wg(a)ripe.net Oggetto: Re: Allocations for "always-on" ISPs I'm very glad my mail sparkled such an interesting discussion. I see three main threads developing: 1) NAT or not to NAT 2) prohibit /29 for residential users 3) where is IPv6 First of all let me try to put these problems in the context I was referring to in my mail. The service providers I was thinking about are those who want to offer an always on connection to customers that wont' simply surf the net. Once you have always on connectivity to the Internet you may end up buying an Internet washing machine (http://www.margherita2000.com) and an Internet camera (http://www.axis.com/products/camera_servers/index.htm) These are servers, not clients. Chances are that most devices like these will be manageable by a web browser,so they simply don't work behind a NAT/PAT. So, in this context, these are my opinions regarding the three threads : 1) NAT is bad for users that want to connect to the Internet, see http://www.ietf.org/rfc/rfc2993.txt and PAT is much worse. NAT/PAT is not an option in the scenario above. 2) how many addresses should RIPE allow a LIR to give to always home customers? /32, /30, /29 ? IF we want to couple a customer with a subnet, I agree with people that are thinking about a /29 at least, because a /30 leaves only one address for your PC. So you cannot use your camera to watch your washing machine doing its job ;-) An alternative would be not to couple a customer with a subnet and give each customer as many address as they need. This would work but would make security, multicast, and probably a few other thins harder to manage. 3) IPv6 is good, see http://search.ietf.org/internet-drafts/draft-iab-case-for-ipv6-06.txt and the service I'm describing would be much easier to deploy if we had it. Why don't we have it yet? Because we make a fundamental mistake in assessing IPv4 addresses exhaustion rate: we count how many addresses are actually allocated/assigned, not how many addresses people would actually need to access the Internet in a decent way. I've personally worked with two very big companies, one that offers always on Internet access, and the other GPRS. They have not even tried to contact the RIPE to request the public IPv4 addresses they would need to offer an architecturally sound service (see: http://www.ietf.org/rfc/rfc1958.txt) because they feel they will never get the number of addresses they anticipate to need!! So they try to get away with NAT, and fail. In this way we get the wrong picture and don't realize how much we need IPv6 today, and neither do the network equipment vendors. So I agree with Lars and Oystein: let's run out of IPv4 addresses once for ever, so we can move on to the next stage. And for that matter, let's stop being restrictive about allocations and assignment: let's give plentiful of addresses so we run out faster!! And I'm not kidding. Cheers bruno

1 0

Re: auto-dbm problems
by Javier Llopis 13 Dec '00

13 Dec '00

On Wed, 13 Dec 2000 17:57:19 -0200, Okan Cimen wrote: >I am trying to update some information about our networks. I have sent >the new information to auto-dbm(a)ripe.net but could not get a response >for almost 6 hours. Does ayone have a suggestion about it? Is there a >problem? Same thing here. I've just received a response for a request sent 4 hours ago. Regards Javier Llopis BitMailer, S.L. javier(a)bitmailer.com Juan Bravo 51, Dup. 1-Izq Tel: +34 91 402 1551 28006 Madrid Fax: +34 91 402 4115 SPAIN

1 0

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