- lir-wg - mailman.ripe.net

Re: Modifications to the inet6num in the RIPE Database
by Simon Leinen 15 Mar '99

15 Mar '99

Joao, sorry for the late comment, but I have a small issue with the following: > Syntax checks will be done so that: > TLA is only allowed if the prefix length is 3<x<=16 > NLA is only allowed if the prefix length is 16<x<=48 I think the separation between TLA and NLA space is not that clear. There are eight reserved bits between the TLA field and the NLA field (see section 2.5.7 of RFC 2373 and section 3.1 of RFC 2374). By introducing the checks as you proposed, you seem to have decided that those should be part of the NLA field. I don't think this is warranted. Section 3.2 of RFC 2374 makes it clear that some of the reserved bits might also be used to extend the TLA field in the future. You should permit either both TLAs and NLAs, or neither of them for prefix lengths between 16 and 24. I suggest rejecting such prefixes for the moment, and keep in mind that the reserved bits may be added to the TLA and/or NLA over time. If I missed some change in the intended structure of IPv6 unicast addresses, please apologize. Regards, -- Simon Leinen simon(a)switch.ch SWITCH http://www.switch.ch/ Who is General Failure & why's he reading my disk?

2 1

Modifications to the inet6num in the RIPE Database
by Joao Luis Silva Damas 04 Mar '99

04 Mar '99

Dear all, below are the proposed modifications to the inet6num object in the RIPE Database as discussed during the past RIPE Meeting. These are mainly to bring the IPv6 object up to the IPv4 object's functionality. The two suggested changes are: - addition of a "status" attribute with the following possible values: TLA, NLA and SLA. Syntax checks will be done so that: TLA is only allowed if the prefix length is 3<x<=16 NLA is only allowed if the prefix length is 16<x<=48 SLA is only allowed if the prefix length is 48<x<=64 - addition of "mnt-lower" capabilities, as in the IPv4 object. We would like to open a comment period of 1 week from today to gather input and proceed with implementation if there is consensus. Regards, Joao Damas DB Group RIPE NCC

1 0

Re: lowering maximum assignment window
by IRIS-NIC 03 Mar '99

03 Mar '99

Hello all, first of all, sorry for th delay in answering the messages. I'm totally agree with this proposal, but I have two doubts: - the first: the assignment window is applicable to the whole organization addressing or only to the requests? I mean, if an organization has ten C classes, then they apply for ten ones more, have I got to take into account the total of them, twenty C classes, to see if they are reaching to the maximum assignment window? Or have I got to take into account only the ten C classes they apply for in the request? - the second: When will this proposal be made effective? And Paula, could you tell me which is the maximum assignment window for es.rediris? In the other hand, I'd like to comment you something that, maybe, would be related to this issue. I'd like to know if there is any document that say if there is any policy to apply in case of bad use of the assigned addresses. Have you ever had an experience in which you have to unassigned addresses to an organization? Is there any type of revisions we could do to assure the correct use of the assigned addresses? Maybe this organization doesn't use the total addressing any more or they applied in the past for a quantity of addresses that they don't use now because they have reorganized their networks. Which are your thoughts about this? Thank you and regards, Maribel Cosin. > > 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. > -- +---------------------------------------------------------------+ | RedIRIS NIC | | Centro de Comunicaciones CSIC RedIRIS | | Serrano 142 Tel: + 34 915855150 | | 28006 Madrid Fax: + 34 915855146 | | SPAIN Email: iris-nic(a)rediris.es | +---------------------------------------------------------------+

1 0

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