[off-topic] Re: [address-policy-wg] 2008-01 Moved to Review Phase (Assigning IPv6 PI to Every Inetnum Holder)

Bill,

[ Apologies for the following rant... ]

On Thu, Mar 20, 2008 at 12:38:50PM +0000, bmanning at vacation.karoshi.com wrote:
> On Thu, Mar 20, 2008 at 12:18:52PM -0000, michael.dillon at bt.com wrote:
> > > Many entities will have no use for the /56 you're planning on
> > > giving them.
> > 
> > In general, I agree with those who oppose this proposal. But
> > another problem with the proposal is that it will lead many
> > organizations to design their IPv6 network based on a /56 rather
> > than a /48 which is more normal. Organizations really should think
> > about how they structure their IPv6 network and only squeeze it
> > into a /56 if they need to.
> 
> 	"normal" is a very odd way to couch this argument.
> 	why not /35 & /32, or the /56 & /64...  
> 
> 	pragmatically, a network operator would be working
> 	in the /88 to /110 space.  the massive waste in
> 	delegated and unused/unusable space is almost entirely
> 	the result of protocol designers who had little or no
> 	network operational experience.
> 
> 	IPv6 -  96 more bits,  No Magic.

I was a fly on the wall in one of the early discussions where /48 was
presented as a recommendation (just when I was starting with this
Internet stuff, done in a small circle of interested folks).

One assertion was that "allocations must be on byte boundaries" - the
reason given was hardware optimization. I didn't believe it then, and
I don't believe it now.

But the overriding idea was that it *must* be the same size for
everyone, otherwise someone might charge more for a larger block, or
simply not offer the same size. So people might end up either with a
smaller block than they need, or migrate from a larger to a smaller
network and not want to renumber. Which means they might use NAT.

So, as far as I can tell, the "one size fits all" idea is an attempt
to further the IETF anti-NAT jihad, and has nothing to do with
anyone's operational needs. :-(

--
Shane