[ppml] 2005-1:Business Need for PI Assignments

[Owen DeLong]

--On Tuesday, April 26, 2005 10:03 AM +0100 Michael.Dillon at radianz.com
wrote:

>> What I mean is - I have yet to be convinced that there is a concrete 
>> reason to assign gobs of addresses to my house.  Why not dole out 
>> IPv6 a few addresses at a time until it's clear I need a /48 or /52 
>> or /60. 
> 
Look, I'm all for simple, but, oversimplification is costly, and, the
current IPv6 addressing architecture is oversimplified and, in my opinion,
just silly.  It strives for economies where costs are already minimal.

It's very nearly as simple to assign each residential or small end user
a /64 unless they request more.  Assigning more in the case of such a
request is also simple.  I agree that we shouldn't go quite as tight
as current CIDR (prefixes of all shapes and sizes), but, rounding requests
to 4 or 8 bit boundaries seems a perfectly reasonable compromise to me.
I just don't see a lot of economy to 16 bit rounding compared to the amount
of waste.

> Not at all. Innovation comes about when traditional ways of doing
> things can no longer cope. It has nothing to do with IPv6 address 
> conservation. If we run out of IPv6 addresses in the year 2105, then
> that may spark some innovation.
> 
So you're saying we should waste addresses today in order to limit the
useful live of IPv6 because that will accelerate our development of the
next protocol.  Michael, you have a unique way of viewing the world.
Personally, I'd like to see us try and find ways to make whatever protocol
we implement next (IPv6 being the currently most likely candidate) last
as long as possible.  There are plenty of other areas where innovation
is needed.

Owen


-- 
If it wasn't crypto-signed, it probably didn't come from me.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20050426/9141db82/attachment.sig>