[ppml] IPv6>>32

Randy Bush wrote:
> > Yes stewardship is about resource management so that it is available
> > in the future, but is also about allowing current use of the resource
> > in ways that don't artificially constrain innovation to past practice.
> 
> this deserves one concrete example where it is doing so.  otherwise it's
> all outer space where we have no idea what we could or should be doing
> other than the current v6 marketing smoke, build it and they will come.
> 
> randy

One could argue that the smoke coming from the 'conservation is paramount'
crowd deserves at least one concrete example of why a well managed set of 45
bits is insufficient ...

1)
RFC 3306  - there are not enough bits to use this approach with Leo's
proposal. I don't know what they are using for server address allocations
but http://www.ipv6style.jp/en/action/20040902/index.shtml   shows that IPv6
multicast is already in commercial deployment. 

2)
http://www.ietf.cnri.reston.va.us/proceedings/02jul/slides/send-2/tsld003.ht
m
shows some thoughts about how security might be improved, and while current
proposals might not work out the overall approach suggests that aggressive
conservation will stifle innovation in this space.

The point is that IPv4/nat has constrained innovation; that IPv6 as defined
opens the potential again; and anyone that claims to know what we will or
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
available to network users will only negate that effect. 

Change the H-D ratio policy and gain back 3 bits (well over 300 years
worth), then we can talk about the impact/value of changing the customer
side allocation boundary. There are non-technical reasons that this whole
debate is moot so rather than wasting more time on it we should get past the
conservation FUD and get on with allocations. 

Tony