[ppml] IPv6>>32

Michael,

On May 9, 2005, at 9:39 AM, Michael.Dillon at radianz.com wrote:
>> The net result is that we're poised to burn through a /1 to a /4
>> of the IPv6 address space in the next 60 years based on our best
>> current guesses.  This makes me extremely nervous.
> I'm sorry but I cannot understand this sentiment at all.

For me, the sentiment derives from the discomfort of knowingly  
deploying something that is (arguably) broken.  I suspect if you went  
back in time and asked Vint or Bob Kahn or any of the other original  
net geeks if they thought IPv4 would ever really be at risk of  
running out, they'd laugh at you.

> ARIN should completely avoid this type of policymaking. It is
> not the job of ARIN or any RIR to drive today's policy based upon
> the hypothetical needs of people 60 years from now.

Hmm.  I would've thought this would be pretty close to the actual  
definition of "stewardship".

> And our job is not to change IETF designs.

No, market and operational realities change IETF designs as they also  
change RIR policies.

> Sorry, but I am not going to run a DHCP server on my mobile
> phone, on my fridge, on my TV or my stereo or my home lighting
> system.

Well, you might on your phone if it is the gateway for your personal  
area network, connecting all the biosensors and other gadgets  
attached to you.  You probably wouldn't run a _server_ on end devices  
like your TV, however I suspect you might on your residential gateway 
(s).

> Have you ever heard of something called "working code".
...
> Why should the IETF listen to an idea that has no running code to  
> back it up?

While I might argue the IETF long ago gave up on running code, I  
think the issue here is one of perception.  Some might argue that due  
to the fact there is very little actual operational experience with  
IPv6 and, in particular, essentially no operational experience with  
scaling IPv6 anywhere near what it is expected to be able to do, that  
the "working code" of address allocation for IPv6 has not yet been  
defined.  What I might suggest we have is an evolving working group  
draft that we're just now getting to actually implementing (and have  
already found some warts)...

Rgds,
-drc