Fixed Boundary (/29) Assignments

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