[ppml] IPv6>>32

[Tony Hain]

Leo Bicknell wrote:
> ...
> You appear to be avoiding my question.
> 
> In your original statement you said miserly conservation increases
> the market value of nat.  I specifically asked if you considered
> 32 bits of host space miserly with respect to the adoption of IPv6
> NAT.  You then changed the subject to other things that more bits
> enable.  I realize it is a multi-dimentional problem, but I asked
> a question about one specific dimension.
> 
> I will be happy to address the merits of things like CGA after you
> answer my question.
> 
> Is 32 bits of host space miserly such that it would lead to IPv6
> NAT?

Any approach that needs more than 32 bits to work would be precluded by an
allocation policy that limited subnets to that size. NAT is a work around to
limitations imposed by a service provider, and may or may not be a
reasonable approach to work around the limited vision of the ISP. If nat by
its nature breaks the function that the larger IID was attempting to fix,
then no, the 32 bit IID would not drive nat. Restricting a customer to a
single subnet of any size would be a stronger motivator than limiting the
number of IID values. That said, equating number of IID values to number of
physical devices is already broken and will only become more so as
integration results in more logical functions being packaged into a single
device (cable modems already include multiple logical devices, virtual
machines mean a single computer appears to be a set, ...).  What you appear
to be asking is what the maximum number of devices will be on a subnet 100
years from now. If so, that is not even worth the time to blow off the
question since we can't possibly know what technologies will exist or be
dropped along the way as 'not worth the effort', no matter what size is
chosen. 

I am not interested in playing a 'throw darts at comments or proposals'
game. If this is going to be a serious discussion about what is reasonable
then it needs to include a recognition that routing doesn't 'need' more than
45 bits if it is managed to the degree that we already understand. We
already know that the HD ratio as defined is not a good match for real IP
network deployments. Fix that, then we can talk about why 600 years is
insufficient and the potential need to change the default customer prefix
length. Starting out by saying that 'that value for the other guy is too
rich' when the existing value for the routing side is equally rich is
nothing more than greed. 

Tony