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

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

RE: Fixed Boundary (/29) Assignments
by Bjarne Carlsen 12 Feb '01

12 Feb '01

> -----Oprindelig meddelelse----- > Fra: Hans Petter Holen [SMTP:hph@online.no] > Sendt: 8. februar 2001 23:15 > Til: lir-wg(a)ripe.net > Emne: Re: Fixed Boundary (/29) Assignments > > > > > why is dsl different, from an address allocation view, than e1, flame > delay, > > point2point, etc. it's just the layer 1 point-to-point technology used > for > > provisioning an end site. > > In my oppinion it is not at should not be different. But what is different > is that we > are rolling out mass marked "always on" products in a larger scale than we > have > seen before. [Bjarne Carlsen] But what is different about it? It is - as Randy said - just the layer 1 point-to-point technology used for provisioning an end site (blatant cut'n paste here). The only real difference from "the good old days" that I can see, is that we are dealing with customers as single persons/families with lesser need for address space instead of companies with comparatively greater needs. > What I don't think the poicies should do is to prevent products like home > lans. > I dont think policies should force providers or the customers to use NAT. [Bjarne Carlsen] I agree, but I still think that the customers should be required by policy to somehow justify their needs for addresses. > So going back to the original question, is it OK to assign a /29 to a home > network > (beeing connected with wathever technology) ? [Bjarne Carlsen] That was not the original question. The question was whether a standard /29 assignment to all DSL/cable/insert-your-own-new-technology users would be feasible. > > I belive the answer is yes. [Bjarne Carlsen] I heartily disagree: With a standard assignment, there is absolutely no justification for the used space. The proposed policy does not even assume that all addresses will actually be used - not even that they will be used eventually. > I also belive that it is probably not > reasonalble to > expect an average customer to fill in the RIPE form. I also have a > tendency > to think > that it is probably not usefull to demand the form to be filled out for a > /29... [Bjarne Carlsen] Right, but the administration will have to be done at some point - whether it is done via a RIPE-141 or it is done some other way. The administrator should be the LIR in my opinion. > So my opinion would be that: > - the policy should not encourage an ISP to make /29 the default product > - the policy should not prevent an ISP from making a product option to > have > more than one IP address in a home network. (enabeled by clicking on a web > page > or some such.) [Bjarne Carlsen] And in my opinion the policy should not even _allow_ a /29 as default product - no tickee, no launly; no justification, no addresses. > - I think it would be a huge vaste of resources if RIPE NCC hostmasters > were > to spend their time reviewing RIPE forms for /29 for dsl, 3G or whatever > connected home¨ networks... [Bjarne Carlsen] Yes, but the administration will still have to be done somewhere in the system... > On the even more general side, I think more and more that we should be > realy > carefull to > create to strong restrictions on the use of address space available to new > and smaller players > today, while there are no such policies in place for legacy address space. > [Bjarne Carlsen] Couldn't have said that better myself. > -hph > /Bjarne

4 5

IP Address Tracking Software
by Jan-Ahrent Czmok 11 Feb '01

11 Feb '01

Hi! After reading through all the mails at nanog and other forums, i am asking: why not we all together work on a software which works together with RIPE, ARIN, APNIC ? Isn't that what internet was build on ? People doing great things. So let's get all ideas together and work together with the registries to solve that "evil" and "old" problem. Just my .2 cents (or euros, whatever) Jan

1 0

Re: Fixed Boundary (/29) Assignments
by Javier Llopis 10 Feb '01

10 Feb '01

On Wed, 7 Feb 2001 09:04:15 -0700 (MST), David R Huberman wrote: >Hello everyone, > >It is my experience, both as a former RIR employee and as a former >employee of a large residential DSL provider in the United States, that by >affording all residential broadband provider the flexibility to make >address policy along a fixed /29 boundary will result in MORE conservation >of address space, not less. I appreciate your insight, David, but I fail to see this point. How do you save IP space by assigning 8 IP addresses instead of just one? > >Residential broadband is a market that is demand driven. The RIRs should >be seeking to take addressing out of the competitive side of the market, >and equal the playing field for all providers in the name of address >conservation. Absolutely agreed, however, in the rest of your message you seem to imply that fixed boundary assignments are a must if one wants to stay competitive. I don't doubt that. Although I don't see this happening down here, I appreciate that you share your experience as an indication of the scenario we are going to be facing shortly. >It has been my experience that customers will ask for MORE address space >(3+ usable, publicly-unique addresses), not less (I only have one PC, so >obviously I only need 1), when given a choice. Yes, just as when they take five ketchup bags at McDonalds and they use only one. >From a consumer point of view, MORE no-matter-what is BETTER. I think it is sad that some people are starting to use IP addresses as assets to make their offer look better. >If, other factors being equal, customers can shop broadband providers on >the basis of 'how much publicly unique address space will you provide me', >an imbalance will inevitably result - the long-term consequences of which >would be increased IP wastage. > >RIPE needs to allow providers to assign /29s to residential broadband >customers without question and apply its justification policies only for >residential assignments shorter than a /29. Mmmm... Disallowing automatic fixed boundary assignments for that purpose for everyone would work just as good in balancing the market. I wish IPv6 technology would be common enough between LIRS so we could give every residential customer 32 IPv6 addresses or 1 IPv4 address at their choice, so that woud skyrocket the demand of low-end IPv6 hardware and solve the address problem forever. Regards Javier Llopis BitMailer javier(a)bitmailer.com Juan Bravo 51, Dup. 1-Izq Tel: +34 91 402 1551 28006 Madrid Fax: +34 91 402 4115 SPAIN

4 4

Re: Fixed Boundary (/29) Assignments [ 1) missing]
by Wilfried Woeber, UniVie/ACOnet 09 Feb '01

09 Feb '01

I forgot to attach my footnote here... > However, we should accept the reality that another sizeable fraction of > the customers looking at those new services do indeed require "the real > thing". Pointing to NAT, masquerading, you name it is not going to work. > (see 1) Looking at _my_ "residential" requirements, I am hard pressed to work without a range of fixed addresses for waht I want to use without spending all my time to reconfigure boxes: - 1 ANT - 1 router (Ethernet and tunnels (v4,v6)) - 2 "full size PCs" - 2 Laptops (my wife's and mine) - a WS with a "traditional" operating system multiple boots and peripherals on the PCs and a mixture of Linux, W95, W/NT, (Solaris8/Intel, freeBSD to come) And no, this is not a university link, this is my link to a regular commercial service. But I want to talk my university, of course... Wilfried.

1 0

Re: Fixed Boundary (/29) Assignments
by Wilfried Woeber, UniVie/ACOnet 09 Feb '01

09 Feb '01

=From: "Hans Petter Holen" <hph(a)online.no> =To: <lir-wg(a)ripe.net> =Subject: Re: Fixed Boundary (/29) Assignments =Date: Thu, 8 Feb 2001 23:14:53 +0100 = => why is dsl different, from an address allocation view, than e1, flame delay, => point2point, etc. it's just the layer 1 point-to-point technology used for => provisioning an end site. = =In my oppinion it is not at should not be different. But what is different =is that we are rolling out mass marked "always on" products in a larger =scale than we have seen before. Correct. And we are going to see other technologies than xDSL posing the same challenge (WLL, mobile, someone might find metered usage of ISDN dropping, so offer a 24x7 package). From my pint of view, the only thing that is "new" - if at all - is the fact that bigger players are going after the commodity Internet market. And this definitely is not a criticism! =What I don't think the poicies should do is to prevent products like home =lans. I dont think policies should force providers or the customers to =use NAT. Again, I fully agree. Address distribution policy is not the appropriate mechanism to develop operational or technical recommendations. The RIRs would be very ill-advised to get dragged into that tar pit. =So going back to the original question, is it OK to assign a /29 to a home =network (beeing connected with wathever technology) ? =I belive the answer is yes. I also belive that it is probably not =reasonalble to expect an average customer to fill in the RIPE form. I also =have a tendency to think that it is probably not usefull to demand the =form to be filled out for a /29... Again, I fully agree. However this is _not_ to be read as an endorsement for giving away an address block of whatever size as a _default_ approach. Also, I agree that a sizeable fraction of the customer base can be reasonably served by a mix of technical solutions as outlined by other contributions. However, we should accept the reality that another sizeable fraction of the customers looking at those new services do indeed require "the real thing". Pointing to NAT, masquerading, you name it is not going to work. (see 1) In particular, any art of dynamic address or port management is probably going to impede the deployment of IPv6 for the mass-market, simply accelerating the consumption of IPv4 address space instead of contributing to breaking the exponential trend. =So my opinion would be that: =- the policy should not encourage an ISP to make /29 the default product I agree. But again, this is outside the access policy and documentation policy to obtain IPv4 addresses. =- the policy should not prevent an ISP from making a product option to have =more than one IP address in a home network. (enabeled by clicking on a web =page or some such.) Whatever the accepted means of documenting the "request for real addresses by the customer" is, is what should be considered here. And how the mechanisms would look like for certain bands of address consumption. In the end, "wasting" a few addresses from a /29 (or /30) address block is not too different from allowing network growth claims over 12..24 month of the order of slightly less than 50% in the "regular" 141 process for, say a /25. =- I think it would be a huge vaste of resources if RIPE NCC hostmasters =were to spend their time reviewing RIPE forms for /29 for dsl, 3G or =whatever connected homeš networks... What we have (painfully) seen over the last 6(..8) month is that micro-management on the LIR's end is not going to work. And that fact hits *everyone*. In order to make the whole process survive, we have to face reality! And, unless *all of us* are prepared to spend a *lot* of money and a *lot* of time to do that, we should focus on a reasonable solution for the mass-deployment scenario. Whatever that solution in reality is, I really don't care too much. We can either go the path of setting a cut-off block size where we no longer require public registration and the keeping of individual records (e.g. a 141 or equivalent for every customer), or we can go towards "charging" those addresses to the ISPs own address space assignment. That approach would require us to revisit the interaction between incremental self-assignment and the AW (which we should do anyway - but that is a completely different thread ;-). I guess there are other approaches as well. =On the even more general side, I think more and more that we should be =realy carefull to create to strong restrictions on the use of address =space available to new and smaller players today, while there are no such =policies in place for legacy address space. While this certainly is true, I am more worried about the "message" we might be sending to the community: "the end-to-end approach in the Internet is no longer supported" Go for a shrink-wrapped package of 1 address (wait a minute: why do you even need that one? We are offereing you an application gateway anyway? You are using a web-browser most of the time anyway, and we do have a cache, so what?). And the Internet (plus competiton and technical development) would simply look very different in a short while... =-hph Wilfried. _________________________________:_____________________________________ Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at UniVie Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 A-1010 Vienna, Austria, Europe : RIPE-DB: WW144, PGP keyID 0xF0ACB369 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1 0

Re: Fixed Boundary (/29) Assignments
by Wilfried Woeber, UniVie/ACOnet 09 Feb '01

09 Feb '01

=> IMHO, no. Why should the amount of address space assigned have anything to do => with the way that a network is connected to the outside world? = =I think the important bit is the word "residential" and not the =connection method. For the moment I cannot see clear-cut criteria to label one network as residential and another one as [implied from context] business, and to do so consistently over teh life-time of the connection/network. Which IMO makes that aspect useless to base address distribution policies on. Wilfried.

2 1

RE: Fixed Boundary (/29) Assignments
by Bjarne Carlsen 08 Feb '01

08 Feb '01

My $0,02: As I stated on the RIPE-meeting, one should consider the goal of preservation most carefully when contemplating any standard assignments for specific services. The proposed /29 assignment seems to me, (and I work for a cable provider), to be wasteful. I vote for the second option. Let the LIR ask for current and expected use. Rgds Bjarne Carlsen Fakse Municipality

6 6