=From: "Hans Petter Holen" <hph@online.no> =To: <lir-wg@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@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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~