- lir-wg - mailman.ripe.net

ANN: Web141 source release
by Maldwyn Morris 18 Feb '99

18 Feb '99

Hi, I am pleased to announce the public release of the source code to the plain-text formatting part of Web141, the European IP Address Space Request Syntax Checker. It is a simple, but large, perl script using the CGI module, designed to be run in the cgi-bin directory of a web server. It needs some customisation by users, but nothing too tricky and comments at the top of the code explain what needs doing. You can get the single source file at: ftp://ftp.ripe.net/tools/web141.pl.cgi You can see our local copy running at: http://www.ripe.net/cgi-bin/web141/web141.pl.cgi Note that this code only formats into plain text a request entered in the html form, and does *not* perform the syntax checks. We will release the source code to autohm, the syntax checker, in two weeks time. Please let us know your comments and suggestions. Cheers, Maldwyn Morris Software Manager RIPE NCC

1 0

Question: AS number preservation
by Barak Engel 15 Feb '99

15 Feb '99

Hello, I hope this is the right forum for asking this question... if not, please direct me to the right place. TIA. I have a question which I was hoping someone could answer: let us assume that an organization already has an AS number, due to, say, a multihomed connection to two other AS's. This organization now removes one of these connections, and is left with a single-homed connection. However, the organization may still wish to regain a multihomed connection in the future, and therefore would like to keep their AS number. What are the rules governing such a case? Will the AS number be preserved? Will it be taken from the organization? If so, how long does the organization have to reestablish a multihomed connection? Is there any document that deals with this issue (I havent found anything relevant in RIPE-181 or RIPE-185) Many 10x, Sincerely, \'"'/ Barak Engel ( o o ) ---------------------ooOO-^-oOOo--------------------------- barak(a)netvision.net.il Network Expert BE-RIPE BE174 Phone/Fax: +972 48 560600/551132 Cellular: +972 50 469 341 -----------------------------------------------------------

1 0

lowering maximum assignment window
by Paula Caslav 12 Feb '99

12 Feb '99

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

10 17

Web141 update
by Maldwyn Morris 11 Feb '99

11 Feb '99

Hi, Following two good suggestions on this list we have updated the Web141 form at: http://www.ripe.net/cgi-bin/web141/webdebug.pl.cgi You can now enter your current address space usage and addressing plans in a single text field, making it easier to cut and paste multiple lines, and an existing nic-hdl in the person template will be looked up and the details filled in. A bug with the phone: line in the person template has also been fixed. Thanks for the comments, and more are very welcome. Tomorrow we will put the source to Web141 on our FTP site. Cheers, Maldwyn Morris Software Manager RIPE NCC

1 0

Fwd: RE: Database security
by Wilfried Woeber, UniVie/ACOnet 11 Feb '99

11 Feb '99

Dear all, due to finger trouble I failed to send my reply to the list(s) as well. My apologies - here you go... Wilfried. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ First of all I'd like to start out by confirming, IMHO, the usefulness of this sort of on-line discussion. Next, in order to balance what I'm going to add as my comments further downstream, I'd like to assure you that I *do* understand your concerns. And on top of that, it might be useful to include the Local-IR WG... => Lets discuss, what measures should be taken to circumvent the situation you describe. => I can see the problem from two different point of views: => => 1) Yours. Then we have to close the database down, to a bare => documentation-tool for IP-Nets, accessible only by the registries. = = Thats not what I said. For example, the DB could only hide specific fields =behind a password. For example, the "descr" field which gives away the company =name. There's two basic problems with that: . I don't expect any agreement (soon) as to *which* fields should be hidden. We've been through that one recently - and painfully :-( All of the fields have been invented and defined because there was a community consensus about the usefulness of that sort of *public* information. If we can identify attributes which we do not need any longer, let's scrap them rather sooner than later :-) . The DB is not used by the operations folks exclusively, but also by the LIRs, I suppose, e.g. to cross-check the more complex IP-Address requests. Hiding descr: attributes would severly impede that possibility... On a more general level, restricting access to "registries" doesn't get you anywhere. Re-living the scenary you describe, the new "nasty" new-comer would simply arrange for a service contract with the NCC, and off we go. The cost: according to ripe-188, it's 2.650,- + 2.100,- ECU. That sounds like a bargain. And doing so gives them access to pre-paid education by the NCC staff about the use of the DB ;-) As long as I've been following the IANA/ICANN stuff recently, or have read some of the IETF drafts (rps-auth, rps-dist, amongst others), there's really no bottom to that pit we're supposed to dig... => 2) Mine. I need the database to track technical problems and people who are =able to solve them. (hopefully, this view is shared by most of the people here =;)) = = Including myself. But on the other hand, there is a problem here which, I feel, =needs to be addressed. The database structure was implemented in times when the =Internet was not so business oriented as it is today. I think that it may need =some rethinking to fit the times, so to speak :-) I fully agree with you that a fair amount of re-thinking is required during the immediate future. In particular about the usefulness of attempts to implement rules, BCPs, code of conduct and regulations by spending programming resources. It's not going to buy us anything. => The security mechanism, which is in place, is not technical, it is just =organisational. There is a copyright on the database. The uses, you describe, =are forbidden by this copyright. => => If someone violates this copyright, at least in Germany there are other =measures to forbid such a use of the database. = = Well, lucky for you in Germany :-) = Seriously, though, there is no way in which you could actually prove, in court, =the sort of thing I describe. I am talking from personal experience... *sigh* Well... I suppose in many, if not most regions, there is *quite a lot* of interesting data accessible to the "public", which does indeed have commercial value. For example in our old little country, it's access to - a comrehensive register of real estate ownership (and the debts secured by that!), - the official place of residence for an individual, - an official registry for companies (including management strucure and directors,...) and for assocations, - car ownership and license plates, - phone books (and eventually we've got PNO regulation going!) on and on... I could come up with zillions of good ideas to make use of that data. And indeed some people do. Some of these attempts are legal, some others are frowned upon, the rest is illegal and triggers prosecution. This is real life. I think we have to spend more effort in the future to work on the legal and social aspects, instead of on setting up technical "filters".... Any arguments to the contrary appreciated! Regards, Wilfried (DB-WG chair) PS: Still the best way for keeping customers is offering "the" better service, whatever that is :-) -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Vienna University : Fax: +43 1 4277 - 9 140 Universitaetsstrasse 7 : RIPE-DB (&NIC) Handle: WW144 A-1010 Vienna, Austria, Europe : PGP public key ID 0xF0ACB369 --------------------------------------------------------------------------

2 1

Re: lowering maximum assignment window
by Andrei V Masalov 11 Feb '99

11 Feb '99

-----Original Message----- From: Paula Caslav <paula(a)ripe.net> To: lir-wg(a)ripe.net <lir-wg(a)ripe.net> Date: Wednesday, February 10, 1999 4:50 PM 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. > .... >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. What about BGP announces which are less then /19? Many (if not all) of the major providers (like C&W, SprintLink) are filtering them out, at least for the 195/8 block. ??? Kind regards, Andrei Masalov PTTNET.

2 1

Re: lowering maximum assignment window
by Janos Zsako 11 Feb '99

11 Feb '99

> From owner-lir-wg(a)ripe.net Thu Feb 11 14:38:31 1999 > From: "Bernard Steiner" <bs(a)eunet.ch> > > Just for reference, I ran over 12-14h worth of trafic data (cisco > > NetFlow), starting at jan27 midnight, looking for source IP numbers > > which have a RIPE record of status "ALLOCATED" but not one of > > "ASSIGNED". > > > *na: EU-EUNET-950315 > > 193.73.103.80 > > Note: AFAIK, this is actually EUnet's PA address space. > Unfortunately, the customer ran away with it and refused to give it back. > I don't see why EUnet should be held responsible for keeping the database > up-to-date in this case. I also wonder how many cases like this one there > are out there (people running off with PA address space). > > Just my \(= 0.02 worth. This is not EUnet's fault then (if what you state above is correct), however it IS the access provider's fault who allows them to connect to the Internet with UNREGISTERED addresses! UUNet-GW>sho ip bg 193.73.103.80 BGP routing table entry for 193.73.103.0 255.255.255.0, version 8341409 Paths: (1 available, best #1, advertised over EBGP) 701 1833 3303 8408 157.130.33.17 from 157.130.33.17 (137.39.2.154) Origin IGP, valid, external, best aut-num: AS8408 descr: AS for MediaConnect SA descr: Joint network Company descr: Agence Telegraphique Suisse (SDA-ATS) and Groupe Publicitas descr: Avenue des Mousquines 4 - CH-1005 Lausanne descr: AS created by union of access by ISPs of both mother companies descr: (UBN for Publicitas - Eunet for SDA-ATS as-in: from AS3303 100 accept ANY as-in: from AS286 100 accept ANY as-out: to AS3303 announce AS8408 as-out: to AS286 announce AS8408 default: AS3303 100 admin-c: YD31-RIPE admin-c: DD227-RIPE tech-c: YD31-RIPE tech-c: DD227-RIPE mnt-by: AS8408-MNT changed: ddurand(a)mediaconnect.ch 970804 source: RIPE Ooops... Who said it was unregistered? inetnum: 193.73.72.0 - 193.73.103.0 netname: PUBLICITAS-BLOCK-32 descr: Publicitas-Holding AG descr: Lausanne country: CH admin-c: DD17-RIPE tech-c: DD17-RIPE changed: huber(a)switch.ch 950713 source: RIPE I suspect this is a registration error or more probably a legacy problem of the database... It seems to me that quite some time ago the above assignment was what we now mean by 193.73.72.0 - 193.73.103.255 ^^^ Therefore, It may be useful to slightly modify Poul's program to cope with this anomaly (since I suspect quite some LEGAL addresses fall in such INCORRECTLY REGISTERED assignments)... Janos

2 1

static verification methods
by Paula Caslav 10 Feb '99

10 Feb '99

Hello all, At the Local IR working group at RIPE 32, the issue was raised about changing the policy for applying verification methods to cable connections. Here is our proposal on how to change this policy. First some background: A few years ago, the IANA asked the Regional Registries to keep an eye on "very small assignments to individuals". This means cases like static dial-up where a registry has to use one IP address per dial-up customer. Since these kinds of assignments could potentially use up a lot of address space, it was decided to strongly discourage using static addresses for this and that that we should monitor these assignments more closely. To do this, any Local Registry that assigns a lot of addresses for this purpose (more than 1024 addresses), was requested that they would have to enter each of these customers in the database individually (as is the case with all assignments to end-users). Later when some Local Registries had a problem with entering all their dial-up customers in the database for confidentiality problems, it was decided to add an alternative method that they could instead send us a weekly report showing the customers they added that week. This is so that the Regional Registries could still keep track of these kinds of assignments. In the last few years, more and more technologies have come along that fall under this procedure. Aside from static dial-up, other services such as web hosting (when not using http 1.1), cable connections, ADSL connections, some ISDN connections, etc.. often need to assign one IP address per customer. In many of these cases, using one IP address per customer is necessary because the host is usually permanently connected to the Internet. The issue was raised that applying these verification methods to technologies that are permanently connected to the Internet and need one IP address per customer, is too cumbersome and adds a lot of extra administrative overhead for the provider. We also realise that there are inconsistencies between the Regional Registries in dealing with these technologies. For these reasons, we would like to change the policy and make a distinction between technologies that are usually connected to the Internet permanently and those that are connected only temporarily. Here is the proposal for the new policy, please give us your comments by the end of next week. Permanently online: This includes technologies such as cable, ADSL, and various server (web, ftp, etc..) connections that are usually permanently connected to the Internet. It can also include analogue or digital (ISDN) dial-up connections if they are used for a service that needs to be permanently online and for services like dial-out on demand. For most of these connections, you need to assign one IP address per connection, even if using DHCP (which we recommend because it makes renumbering easier). We propose to change the policy and to not apply the verification methods to these types of connections. For these technologies, we still need to keep track of the amounts of addresses being assigned, however we would do this whenever the customer requests a new assignment for this purpose. Since these services are permanently connected to the Internet, we will probe these addresses to verify whether the assigned addresses really are in use. It must therefore be made clear to the RIPE NCC exactly which block of IP addresses is used for this purpose. We would expect to see that a high percentage are reachable. We might at this point request additional information to show that they have really used the addresses that were assigned for this purpose in the past- this could be in the form of a list of all URLs assigned, their DNS records, config files, etc.. something to show that the IP addresses are all in use. Virtual web hosting is the only one that has an alternative available (http 1.1) that would allow assigning one IP address for several hosts. Since we want to encourage that people use http 1.1, we propose to continue applying the special verification methods to virtual web hosting that doesn't use http 1.1. Temporarily online: This includes technologies that only need to be connected to the Internet temporarily, such as most telephone dial-up connections. We recommend the use of DHCP and assigning IP addresses based on the number of modem ports. We will therefore continue to apply the special verification methods to any organisation that assigns IP addresses based on the number of customers instead.

1 0

ANN: Web141, the RIPE 141 syntax checking web page
by Maldwyn Morris 09 Feb '99

09 Feb '99

Hi, As announced at the Local IR Working Group at the 32nd RIPE Meeting on 27/1/1999, the RIPE NCC European IP Address Space Request Syntax Checking web page, Web 141, is now functioning. The URL is: http://www.ripe.net/cgi-bin/web141/web141.pl.cgi Please note that it is only for formatting and syntax checking requests - you must send the request in an email to hostmaster(a)ripe.net for any action to be taken with it. You can fill in your RIPE 141 format address request in the boxes provided and merely convert the request to correctly formatted plain text suitable for pasting into an email, or you can also have the autohm program check the syntax of your request. This is the same program that checks RIPE 141 requests sent to hostmaster(a)ripe.net, so if you pass these checks you can be sure you will not fail the syntax checks there. However please note that other checks are performed before you are given what you are requesting, and your request may still fail these checks. The simple source of the web page generator and plain text converter ( using Perl5 and CGI.pm ) will be made available in two weeks, and autohm, the syntax checking tool also written in Perl 5, will be made available in four weeks. Please let the lir-wg list know if you have any comments on the web page or the checks that are done. Cheers, Maldwyn Morris Software Manager RIPE NCC

3 2

Proposal to raise the maximum allocation to a single LIR
by Guy Davies 03 Feb '99

03 Feb '99

Hi All, Following on from my comments at the LIR wg, I'd like to describe the issues we have and some possible solutions for these problems for the longer term. Our primary problem is that we wish to have administrative boundaries within our network separating the Backbone, LL Customers and Dial pools. It is usual to aggregate routing announcements at these administrative boundaries which is essential for the network's scalability and stability. Unfortunately, the current policy decided by the LIR working group states that the maximum amount of total free address space held by any single LIR is a /16. This can be really problematic due to the differing rates at which addresses for customers, backbone addressing and dial space are used up. It is possible to have a serious shortage of addresses for one aspect of your network while there is quite a lot of space remaining for the other areas. The restriction of a /16 means that it may not be possible to acquire more addresses for the area which has the need. It has also been generally noted that the RIPE NCC have not taken internal aggregation of routes into account when making allocations. While it may have been OK to ignore this aspect of network address allocation in the past, this is no longer the case and the decision must now be based also on realistic internal aggregation model. Below are some possible solutions to this problem. 1) Increase the maximum free space available for all LIRs to a shorter prefix. This has the disadvantage that it is contrary to RIPE's aim of conservation of address space. It sets a general precedent that any large or rapidly growing LIR can cite when requesting larger allocations. However, the advantage is that it doesn't make any specific differentiation between those LIRs who make use of the larger allocations and is, therefore, easier for the RIPE NCC to administer. 2) Devise some scheme to differentiate the maximum simultaneous available addresses for large registries from that for the small and medium registries. This has the disadvantage that it adds to the administrative load on the RIPE NCC. It is more difficult to manage exceptions. However, it means that the scope of the availability of more addresses is limited which more closely matches RIPE's aims of conservation of address space. 3) Make a specific exception for those organisations who can show evidence of a need for more than a /16 of address space simultaneously available. This adds even more administrative load on the RIPE NCC because it is based on single exceptions each of which could have a different agreement with the RIPE NCC. However, it matches more closely still the aims of conservation. 4) Setup a registry for each function which needs to be separately administered. This adds more administrative load (and cost) to the LIR and to RIPE NCC because there are more independent registries. The primary benefit is that this solution doesn't require any new policies to be made (unless it's contrary to policy for a single entity to have multiple registries for administrative convenience ;-) I'd like this to be the catalyst for some discussion of this subject on the lir-wg list. If anyone has similar concerns or issues, I'd be particularly keen to hear that. Regards, Guy --- Guy Davies UUNET, an MCI WorldCom company European Network Specialist 332 Science Park, Cambridge, CB4 4BZ, UK e: Guy.Davies(a)uk.uu.net t: +44 (0)1223 250457 f: +44 (0)1223 250412

5 6