- lir-wg - mailman.ripe.net

RIPE: last call for comments RPSL transition
by SchmitzJo＠aol.com 16 Feb '01

16 Feb '01

Hello all, as you are aware, we are preparing the migration of the RIPE database software to support and deploy the new RPSL format. The required steps have been discussed in depth on various occassions (for references, see end of mail). We are now preparing the most important step, really transitioning from old RIPE-181 to new RPSL format: proposed transition date is 23-Apr-2001. This step, once taken, will not be reversed. The majority of the user community takes a neutral role, while some want an earlier, and a few a later date for migration. During the joint session of Routing and DB WG at RIPE38, the chairmen of both WGs were tasked to file a last call for comments on that date, in particular whether there are serious, unresolvable technical or operational problems which would benefit from a slightly longer warning period. According to consensus at the session: If you are convinced that the transition date as proposed would lead to significant operational problems, please explain and justify why within the next 2 weeks: deadline for transition comments: 1-Mar-2001 Only well founded reasoning (including an educated guess about the time and resources required to resolve the issue) shall be accepted by the community in order to consider postponing the transition. With the discussion about the migration going on for quite some time, and information available from various places, we do not expect a delay, but we would want to give everybody a last opportunity to comment. To summarize the dates, we are looking at: o 23-Apr-2001: switching to the RPSL database - All objects are automatically converted to RPSL format - Queries return RPSL only - Mirroring follows new format and rules at whois.ripe.net, port 4444 - RPSL formatted updates can be submitted to auto-rpsl(a)ripe.net - RIPE-181 updates are still accepted at auto-dbm(a)ripe.net, but are autmatically converted to RPSL - RFC2725 (Routing Policy Security System) rules apply throughout o 14-May-2001: exchanging mail addresses for submitting RIPE181 and RPSL- formatted updates - auto-dbm(a)ripe.net only accepts RPSL updates - RIPE-181 updates are still possible but now go to auto-181(a)ripe.net and are automatically converted to RPSL (again, RFC2725 rules apply here as well) o 15-Oct-2001: RIPE-181 updates are no longer accepted For further reading, please refer to the migration web page http://www.ripe.net/rpsl or for the discussion during the joint session of the DB/Routing WGs please review the minutes. For technical specifications of RPSL please refer to - rfc2622: "Routing Policy Specification Language (RPSL)" Status: PROPOSED STANDARD, - rfc2650: "Using RPSL in Practice" Status: INFORMATIONAL - rfc2725: "Routing Policy System Security" Status: PROPOSED STANDARD Thanks a lot - the RIPE NCC and the chairmen of Routing: Joachim Schmitz DB: Wilfried Woeber LIR: Hans Peter Holen

1 0

SV: Fixed Boundary (/29) Assignments
by Bjarne Carlsen 13 Feb '01

13 Feb '01

> -----Oprindelig meddelelse----- > Fra: Randy Bush [SMTP:randy@psg.com] > Sendt: 9. februar 2001 15:16 > Til: Bjarne Carlsen > Cc: lir-wg(a)ripe.net > Emne: RE: Fixed Boundary (/29) Assignments > > are we? we see folk using dsl at t1 rates to replace p2p t1 lines because > it's a very different cost for the circuit. (here, t1 is expensive and > dsl > is based on old alarm circuit tarrifs) [Bjarne Carlsen] OK - in other words, you don't even see the small difference, that I see on this side of the pond.. > just to push this to the limit. in the states, we usually have free local > dialup. so we have analog "nail up" customers, i.e. they stay dialed up > 7x24. it's just another form of p2p dedicated circuit. and, as far as > address allocation policy goes, treat them the same as an OC12 customer, > they justify what address space they need. [Bjarne Carlsen] Yes, but make it somehow easier for them, since there is one significant difference between private an corporate customers, (at least as seen from this little backwater), namely that the corporate customer usually understands the technical jargon used in documents like RIPE-141 and the private customer invariably says "Huh, er... what is an IP-address??" /Bjarne

8 8

Re: Policy and PR problem
by Marco Davids 13 Feb '01

13 Feb '01

On Tue, 13 Feb 2001, Hans Petter Holen wrote: > -"it is currently very difficult to get IP address space" and as a result of > that we have to plan complex network solutions with a combination of private > and public addresses. > > This claim is very different from the one I tend to make: "you get the > addresses you need as long as you can provide documentation that you realy > need them". I agree with that, although I use to have a hard time convincing my manager to come up with copy's of invoice and all kinds of other 'strategic' information to proof to RIPE that we really needed the IP-space that was required by that time. I wonder what RIPE does with all this information? I trust they destroy it, after the IP-request has been approved? And how about returning IP-space? The procedures there are not very clear to me (except for the case when the LIR does not pay its fee). Can allocated address-blocks for example be transferred to another party without mediation of RIPE after a merge of company's or something of that kind? Cheers, -- Marco

1 0

Re: Policy and PR problem
by Marco Davids 13 Feb '01

13 Feb '01

On Tue, 13 Feb 2001, Hans Petter Holen wrote: > -"it is currently very difficult to get IP address space" and as a result of > that we have to plan complex network solutions with a combination of private > and public addresses. > > This claim is very different from the one I tend to make: "you get the > addresses you need as long as you can provide documentation that you realy > need them". I agree with that, although I use to have a hard time convincing my manager to come up with copy's of invoice and all kinds of other 'strategic' information to proof to RIPE that we really needed the IP-space that was required by that time. I wonder what RIPE does with all this information? I trust they destroy it, after the IP-request has been approved? And how about returning IP-space? The procedures there are not very clear to me (except for the case when the LIR does not pay its fee). Can allocated address-blocks for example be transferred to another party without mediation of RIPE after a merge of company's or something of that kind? Cheers, -- Marco

2 1

Re: Policy and PR problem
by Wilfried Woeber, UniVie/ACOnet 13 Feb '01

13 Feb '01

Hi Nurani, Thanks for your comments, and I agree that your "the Hostmaster Role's" point of view is of interest of course, eventually, but that the community still has to do a bit more thinking and brain-storming before we can wrap up. >However, what I can say is that we at the RIPE NCC are very aware of >how complicated it is for new LIRs to learn all policies and >procedures involved in obtaining IP address space and AS numbers. >(And indeed there are quite a few.) One of the things that adds to complexity (IMHO) is the fact that the policies (you have to make your needs known, and to do so in a way that can be reviewed) are not clearly separated from the procedures involved. While I think the basic *policy* is more or less straightforward: You get what you need and as much as you can reasonably argue for, and we don't interfere with the engineering approach for your networks by making *policy* that cripples certain design approaches. (With a very few exceptions) We do, however require the applicant to think about alternative approaches, and to make a conscious decision in favour of one or another approach, like rfc1918, http 1.1, ... What indeed has become too complex is the *procedures*. What has been appropriate a few years ago, is not necessarily appropriate any longer for every application everywhere. The Internet has changed a bit. There are more diverse entities active now which have to look at some other boundary conditions in addition to network engineering and address space conservation (as the "only" goal) like size, internal structure, business models, investments, security, helpdesk and customer care issues, and last but not least privacy issues.... >Although it has always been seen as part of the hostmaster role to >educate the LIRs, it is not an easy task with the current dramatic >growth of LIRs. We have partly discussed this with the May 17 >Taskforce and we are also constantly discussing it internally at the >RIPE NCC, trying to find more efficient ways of coping with the >workload and the growth. Indeed. >This may be a PR problem. It is also possible that the policies >simply have become too complicated for new members. (Can it be that >the policies which are developed by experienced and clueful members >of the Internet community is not necessarily easy for newer, less >experienced LIRs?) Is the problem possibly a combination of the two? We should put the effort in dealing with the scaling problem of the *procedures*. While I do not know (and do not want to know) which application made Leo "go public", I would like to report to the community that I had a few very interesting private discussions during the last RIPE Meeting with a sizable company planning the roll-out of a "mass-market" product, and they indeed were a) present at the meeting, and b) had *very* sound questions to ask and were looking for input from the community. So "they" are out there, trying to do "the right thing". But the community should try to understand their position as well, and the scaling problems. Otherwise nobody should be surprised to hear the claims, that it is not possible for them to work with and as part of the "established" community, and that "they" have to build something else that fits their needs.... Wilfried.

1 0

Policy and PR problem
by Hans Petter Holen 13 Feb '01

13 Feb '01

Hi, I am just attending a seminar in Broad band networks, and met again the claim that -"it is currently very difficult to get IP address space" and as a result of that we have to plan complex network solutions with a combination of private and public addresses. This claim is very different from the one I tend to make: "you get the addresses you need as long as you can provide documentation that you realy need them". personally I think that we have a serious PR problem here: is it so that the rules and regulations have become so strict and complicated that we, the lirs, tell our customers that this is very difficult and you should realy use private addresses, rather than explaining how the procedures and policies realy work ? Is this what we want ? -hph

6 6

Re: Policy and PR problem
by Denesh Bhabuta 13 Feb '01

13 Feb '01

At 10:27 13/02/2001, Hans Petter Holen wrote: >personally I think that we have a serious PR problem here: is it so that the >rules and regulations have become so strict and complicated that we, the >lirs, tell our customers that this is very difficult and you should realy >use private addresses, rather than explaining how the procedures and >policies realy work ? IMHO, the main problem seems to be clueless salesmen who do not understand RIPEs procedures, and the clueless product managers who will go and design a solution without knowing what procedures they have to follow or restrictions they have when it comes to IP addresses. This leaves the poor hostmaster trying to explain to the company that it can not do what it wants to do and by then it is almost too late.. advertising etc is all done. What may be worth doing is getting 'salesmen' to go to RIPE training courses - as it is these people who talk to customers directly for that signature on the contract. :) What we need to realise is how companies in this industry conduct business nowadays.. (I am not including those companies who have followed the RIPE rules from time immemorial). I have also already spoken to Axel about RIPE maybe looking at an Outreach program (something that Nominet - the .uk not for profit registry - is doing now)... this will be good for PR. The other aspect I have briefly spoken to Axel about and also to Margriet is how to make the new LIR sign up process less administratively heavy. I am not saying that we change the RIPE NCC we have all come to love over the years.. just that we need to be aware of business in this industry and the way it is going. Regards Denesh -- Denesh Bhabuta Chairman, CEO and Principal Consultant Cyberstrider Limited www.cyberstrider.net Internet and E-Commerce: Strategy, Consultancy and Solutions

1 0

RE: Policy and PR problem
by mike.norris＠heanet.ie 13 Feb '01

13 Feb '01

> I am just attending a seminar in Broad band networks, and met again the > claim that > > -"it is currently very difficult to get IP address space" and as a result of > that we have to plan complex network solutions with a combination of private > and public addresses. This might be true if the words "For those who don't take the trouble to understand and follow the agreed procedures," were inserted at the start of the sentence. > > This claim is very different from the one I tend to make: "you get the > addresses you need as long as you can provide documentation that you realy > need them". This is my experience and my expectation of RIPE NCC. > > personally I think that we have a serious PR problem here: is it so that the > rules and regulations have become so strict and complicated that we, the > lirs, tell our customers that this is very difficult and you should realy > use private addresses, rather than explaining how the procedures and > policies realy work ? > > Is this what we want ? You're right, we do need to get the positive message across. RIPE NCC, and RIPE representatives such as yourself, Peter, have been doing this at various levels, and I think the effort is increasing. Perhaps we need to direct some attention to the more popular media, to explain the importance, the function and the challenges of address registration in the European Internet. Regards. Mike

1 0

1. draft minutes of joint Routing/DB wg session RIPE38
by SchmitzJo＠aol.com 13 Feb '01

13 Feb '01

R I P E 3 8 A M S T E R D A M Joint Session DB and Routing 24-Jan-2001 Draft Minutes Chairs: Joachim Schmitz, Wilfried Woeber Scribe: Engin Gunduz Participants: 97 Joint Session of Routing and Database Working Groups Due to the importance of the subject, and the overlap in topic, the chairmen of Routing and Database WG (Wilfried Woeber) decided to have a joint session of both WGs. Joachim introduced the audience to the session, and chaired it together with Wilfried. E. Migration to the new RIPE database (Andrei Robachevsky, RIPE NCC) (20min) [ The presentatino is available at http://www.ripe.net/ripe/meetings/archive/ripe-38/presentations/r38-reimp-a… ei/index.html ] Andrei gave an overview of what to expect for the migration to the new RIPE database. He began with asking who would be affected by the migration, and the answer is: everybody. Reasons are - RPSL format - new access control - new database format - new version mirroring protocol He supported this by a set of examples, and made suggestions on how to prepare for the migration, depending on which usage group a database user belongs to - query users - update users - adaptation of scripts - near real time mirroring Following that a schedule was presented which summarized the proposed final transition dates - 23-Apr-2001: switching to the RPSL database Queries return RPSL only Mirroring follows new format and rules at whois.ripe.net, port 4444 RPSL updates go to auto-rpsl(a)ripe.net RIPE-181 updates are still possible and still go to auto-dbm(a)ripe.net, but are autmatically converted to RPSL - 14-May-2001: exchanging mail addresses auto-dbm(a)ripe.net only accepts RPSL updates RIPE-181 updates are still possible but now go to auto-181(a)ripe.net and are automatically converted to RPSL - 15-Oct-2001: RIPE-181 updates are no longer possible The crucial date is the first one. It will not be possible to go back after that date. The RIPE NCC has prepared a vast set of aides to assist in the transition, and to get used to RPSL format. All details are available at the RIPE-181 to RPSL transition web page http://www.ripe.net/rpsl The presentation led to a vivid discussion, in particular whether the first transition date is too early or too late. Ping Lu was suggesting to move the dates further into the future because - they are using a lot of off-line tools - the downstreams need to be educated He later explains that he himself would transition rather earlier than later but he is worried about their vast customer base. Joachim pointed out that the transition should not be delayed because RADB is already running RPSL since quite some time, making it more complicated for people using both RADB and RIPE. Moreover, he thought that someone had written some tool to perform at least in part some back conversion from RPSL to RIPE-181, which as Wilfried Woeber pointed out would only be possible for a limited number of objects. However, such tool never was available. Christan Panigl reminded the audience that the idea had come up to supply a RAToolSet tutorial at the next RIPE meeting. He suggested to run it before the transition to the RPSL database, essentially before 23-Apr. The audience wants to have this tutorial parallel to the next RIPE meeting. However, this would delay the first transition date into May. A quick poll showed that 10 people in the audience knew RAToolSet, and that actually 2 were using it in conjunction with RADB. It obviously makes sense to have a tutorial -> action 38.R1 on Wilfried Woeber and Joachim Schmitz to organize a RAToolSet tutorial at the RIPE39 meeting Ruediger Volk points out that a transition very shortly after the tutorial does not make much sense. He also stresses that he objects against postponing the transition, because other transition projects within his company have already been delayed due to the not yet factual transition with RIPE. Jake Khuon agrees with Ruediger. He also points out that many of the objects are doubly registered both in RADB and RIPE. Joachim asked the audience who of them are actually using any kind of automated tools in conjunction with the database, and it turned out that these were more or less the same people who also knew RAToolSet. Accordingly, most of the people requesting a tutorial on RAToolSet do not need it right now and are thus also not affected for automation. This decouples the dates of when the tutorial will be held, and the transition to RPSL. Consequently, even though these are only proposed dates, Wilfried suggests to stick to these dates, and people who think that they have real technical problems must speak up to the community to have those reviewed. -> action 38.R2 on Wilfried Woeber and Joachim Schmitz to send around the transition dates, get input from the community, with a following decision on the dates Ping Lu thinking of interaction of databases then brings up the topic of global NIC handles. Wilfried explains that globally unique NIC handles are not related to RPSL, or the transition to RPSL. He has it on his agenda for the Database WG session tomorrow (25-Jan). F. Report from the DB migration task force (Wilfried Woeber, Andrei Robachevsky) Wilfried reported that the DB migration task force did a review and besides a set of questions identified by some active members of the user community, the following open issues were identified - Outreach The RIPE NCC has taken every effort to notify all parties repeatedly who will be affected by the transition. Disappointingly, the feedback on these efforts has been small. - Other items are * broken PGP keys * unprotected aut-num objects * object names not compliant with RPSL which were discussed in a short presentation by Andrei Andrei gave a few statistics on those items, first on their efforts to contact parties which need to be involved, and then on the open issues where Joao Damas explained the proposed solutions. - Broken PGP keys The old PGP programs generated non-compliant PGP keys. Those keys will be refused by version 3 software. It turns out that 7 out of 409 PGP keys are broken. The proposed solution is to delete the key certificates. This does not affect security for a simple reason: If someone wants to apply a change to objects protected that way, the software does not find the corresponding key certificate, and thus rejects the update. The party who wants to submit the change will then be required to contact the RIPE NCC. It was general consensus in the audience to follow that approach. - Unprotected aut-num objects In the past, it had become mandatory to have aut-num objects protected by a maintainer. However, 119 out of 4008 aut-num objects still today do not have a mnt-by attribute. So far, they enjoy a "special" protection: Only ripe-dbm can modify them. Surprisingly, none of them was ever touched in all the time since the original change of requirements. It is still mandatory to have a maintainer with each aut-num object in RPSL. The question is of how to proceed. The proposed solution is to add a special RIPE NCC maintainer. By that way, no security breach is opened, and no change compared to the situation today is introduced. If anybody ever wants to touch that aut-num object again, they still need to contact ripe-dbm. It was general consensus in the audience to follow that approach. - Reserved RPSL names Quite a lot of objects in the database have names which do not comply with RPSL rules. An example are 108 aut-num objects using the reserved prefix "AS-" in the AS-name attribute, or 7 maintainer objects with other reserved prefixes. The proposed solution is to change the names prior to transition in a way which still needs to be agreed upon. A suggestion is to contact all parties who own those objects, and also publish them on appropriate RIPE mailing lists. It was general consensus in the audience to follow that approach. Those results were taken to the Database WG. Ping Lu raised the question whether there was the intention to implement global maintainers. Andrei explained that so far all references must be resolved locally. Andrei also showed which OSs are currently supported for the database software o Solaris 2.8 (Intel & Sparc) o Linux (RedHat, SuSe). o FreeBSD The inquiry from Wilfried showed that this list is accepted by everybody, and no other OSs seem to be used by any company of registry, meaning from that side no problems are expected. Wilfried asked the NCC to release the database software for all platforms without putting too much effort into performance tweaking for each individual OS, just assuring its overall functionality. Anybody who wants to participate in the transition discussion is free to join the migration task force mailing list reimp-mig-tf(a)ripe.net Summary of Open Action Points from the Joint Session of DB and Routing 38.R1 on J.Schmitz, W.Woeber Organize RaToolSet tutorial at RIPE 39 status: new 38.R2 on J.Schmitz, W.Woeber Collect final community input on DB migration dates status: new Engin Gunduz, Joachim Schmitz, February 2001

3 3

Fixed Boundary (/29) Assignments
by leo vegoda 12 Feb '01

12 Feb '01

Dear all, In my presentation to the Working Group at RIPE 38 [0] I brought up the issue of assignment policies for ISPs wanting to assign all customers a fixed size network (/29). The RIPE NCC is experiencing an increase of requests for this type of setup and would therefore like the community's input on this matter. There is no specific mention of broadband connections or fixed-boundary assignments in the current policy. However, we believe that the policy now requires LIRs to make assignments on the usage-based requirements of the subscriber. This is consistent with the RIRs' goal of conservation. The method of assigning a standard prefix size is certainly quite wasteful as one quarter of the space is lost on network and broadcast addresses. The requester justification for this assignment method is an estimation of the number of customers taking IP based services or having multiple Internet connected terminals at home. As a reference, it may be worth noting that in recent discussions on the IETF mailing list, Bernard Aboba estimates [1] that currently 27% of homes have multiple 'PCs'. It is difficult to predict the take-up of non-Internet IP-based services. Based on the above, we would like the Working Group to consider whether: - a standard, fixed-boundary assignment is acceptable for residential broadband connections? Or - should the requester (the LIR) be required to ask the subscriber how many IP devices will be connected and base the assignment upon this? Regards, leo vegoda RIPE NCC Hostmaster [0] http://www.ripe.int/ripe/wg/lir/present/ [1] http://www.ietf.org/mail-archive/ietf/Current/msg10586.html

19 23