February 1999 - lir-wg - mailman.ripe.net

Adding nic handles to contact objects without one
by Joao Luis Silva Damas 02 Mar '99

02 Mar '99

Dear all, during the last RIPE meeting, in Amsterdam, the database working group discussed a proposal to automatically add NIC Handles to all person and role objects in the RIPE Database that don't yet have one (new objects can't be created without nic handles anymore). This proposal was supported by the working group and it was agreed that it should be circulated to the mailing lists to give people not attending a chance to provide input. This does not affect how other objects reference these person or role objects. This is only intended to bring old objects into conformance with the current object definitions and does not mean that data provided by the user will be modified. Only the nic handle attribute will be given a value when the object lacks one. No other attributes will be touched. Objects which already have nic handles will not be touched. The nic handle is a tag conveying no information about the user or role described in the object. It is an identifier for the object. This addition would make data more uniform and could be a benefit for everyone. For more information on nic handles, please read RIPE 157 and RIPE 189 available at http://www.ripe.net/docs Best regards, Joao Damas Database Group RIPE NCC

4 5

lowering maximum assignment window
by Paula Caslav 01 Mar '99

01 Mar '99

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(a)ripe.net> Sender: owner-lir-wg(a)ripe.net To: lir-wg(a)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

8 9

policy change: static verification methods
by Paula Caslav 26 Feb '99

26 Feb '99

Hello all, A few weeks ago I send the following proposal to the lir-wg mailing list for comments. Since no comments were received, we are assuming that nobody has objections to change the policy. We have therefore decided to implement it starting immediately. Kind regards, Paula Caslav RIPE NCC ------- Forwarded Message Date: Wed, 10 Feb 1999 14:38:52 +0100 From: Paula Caslav <paula(a)ripe.net> Sender: owner-lir-wg(a)ripe.net To: lir-wg(a)ripe.net Subject: static verification methods 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. ------- End of Forwarded Message

15 20

Another AS No.
by Anela Lovric 25 Feb '99

25 Feb '99

Hello all, We are ISP and local-ir too, and we have 4 links (bgp) to other ISP. We are thinking about dividing our network in two AS. Reason for that is to divide network and customers so we could announce AS-es different to different bgp peers. I know that we can use route-map in bgp to announce different IP addreses, but it seems simpliest with two different AS No. So my question is : Is it possible to ask another AS Number from RIPE within existing IP space or with new IP addresses allocation? I did not find anything about another AS in ripe documents. Maybe this is stupid idea, maybe not I do not know, so I would appreciate any suggestion or advice. Thanks in advance, Anela Lovric HiNet

3 2

Re: Another AS No.
by Berislav Todorovic 25 Feb '99

25 Feb '99

>> We are ISP and local-ir too, and we have 4 links (bgp) to other ISP. >> We are thinking about dividing our network in two AS. Reason for that >> is to divide network and customers so we could announce AS-es different >> to different bgp peers. >> ... (snip) >> Is it possible to ask another AS Number from RIPE within existing IP space >> or with new IP addresses allocation? According to the RFC 1930: An AS is only needed when you have a routing policy which is different from that of your border gateway peers. Here routing policy refers to how the rest of the Internet makes routing decisions based on information from your AS. Since your new AS will use different prefixes and different routing policies than your current AS, that may be a solid argument to ask the regional registry to assign you a separate number. At least - all huge ISP's in the world have several AS numbers. ;-) Regards, Beri .-------. | --+-- | Berislav Todorovic, B.Sc.E.E. | E-mail: BERI(a)etf.bg.ac.yu | /|\ Hostmaster of the YU TLD | |-(-+-)-| School of Electrical Engineering | Phone: (+381-11) 3221-419 | \|/ Bulevar Revolucije 73 | 3218-350 | --+-- | 11000 Belgrade SERBIA, YUGOSLAVIA | Fax: (+381-11) 3248-681 `-------' --------------------------------------------------------------------

1 0

allocation sizes
by Paula Caslav 23 Feb '99

23 Feb '99

Hello all, A few weeks ago a mail was send to the lirl-wg mailing list to start a discussion about increasing the maximum assignment size to something larger than a /16. I have included the original message from Guy Davies below. There didn't seem to be much consensus on the issue and some further issues were raised that the RIPE NCC needs to consider. The main reason for the proposal was that some larger registries feel that the /16 allocation size is too small and that for internal routing reasons they would sometimes need more than one allocation. The issue was raised that Registries also sometimes need additional allocations for external routing reasons and in the past they've always needed to open separate registries for this. The RIPE NCC needs to think about this issue some more, but in general we feel that opening a new registry for external routing reasons is usually a good idea because often the other network has different needs and is maintained by a different group of people, so it's best so keep them separate. When a registry needs additional address space for internal routing reasons however, we feel that the best solution for now is to consider each case individually and try to come to an agreement that gives the Registry extra flexibility with their internal routes, but still considers the goal of conservation. We'll be talking to the other Regional Registries about comming up with a better policy in the future. We'll keep you informed on this. Kind regards, Paula Caslav RIPE NCC ------- Forwarded Message To: lir-wg(a)ripe.net Subject: Proposal to raise the maximum allocation to a single LIR From: Guy Davies <guyd(a)uk.uu.net> Date: Tue, 2 Feb 1999 10:06:48 +0000 (BST) Sender: owner-lir-wg(a)ripe.net 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 ------- End of Forwarded Message

1 0

RE: policy change: static verification methods
by IP 23 Feb '99

23 Feb '99

Hi Paula et al. I, and as far as I know, a couple of other LIR:s, have no objections for the proposed policy, on the contrary. The proposal has a pretty fine tune in balancing the end-customer need as stated as one of our assigning goals in RIPE-185, and the not-that-good policy comment of CATV-network customers as beeing as any dial-up customers, just becouse they are using a modem. As far as I recon, one have to use a 'modem' when going for a Leased Line as well, though signalling would not be analog. Any way, I think it perfectly ok to implement the policy right away. Best regards Per Lundberg/Sonera Registry/RSS11-RIPE > -----Original Message----- > From: Paula Caslav [mailto:paula@ripe.net] > Sent: Tuesday, February 23, 1999 4:44 PM > To: lir-wg(a)ripe.net > Cc: local-ir(a)ripe.net > Subject: policy change: static verification methods > > > > Hello all, > > A few weeks ago I send the following proposal to the lir-wg mailing > list for comments. Since no comments were received, we are assuming > that nobody has objections to change the policy. We have therefore > decided to implement it starting immediately. > > Kind regards, > > Paula Caslav > RIPE NCC > > ------- Forwarded Message > > Date: Wed, 10 Feb 1999 14:38:52 +0100 > From: Paula Caslav <paula(a)ripe.net> > Sender: owner-lir-wg(a)ripe.net > To: lir-wg(a)ripe.net > Subject: static verification methods > > > 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. > > > > > > > > ------- End of Forwarded Message > > >

1 0

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