[ppml] IPv6>>32

[Leo Bicknell]

In a message written on Mon, May 09, 2005 at 02:08:33PM -0700, Tony Hain wrote:
> will not need in 50 years is just wrong. Yes egregious waste of the address
> resource should be avoided, but so should miserly conservation that
> increases the market value of nat approaches. The /48-/64 units effectively
> reduce the market value of nat to $0. Artificially constraining the space

In a message written on Mon, May 09, 2005 at 08:57:20PM -0400, Leo Bicknell wrote:
> You did not say this directly, so I will ask directly.
> 
> Am I correct in assuming that you believe 32 bits of host space (4
> billion hosts per subnet) is a constraint that qualifies as "miserly",
> and that will lead to the adoption of IPv6 NAT?

In a message written on Tue, May 10, 2005 at 11:05:19AM -0700, Tony Hain wrote:
> You appear to be focused on absolute utilization efficiency. CGA approaches
> like:
> http://www.ietf.cnri.reston.va.us/proceedings/02jul/slides/send-2/tsld003.ht
> m
> trade space efficiency for authenticity. Approaches like using RFC3041
> addresses for everything trade utilization efficiency for immunity to
> scanning attacks. 
> 
> Maximizing allocation efficiency is simply one dimension in a
> multi-dimensional problem space. 

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?

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20050510/5ed144fd/attachment.sig>