[ppml] IPv6>>32

[Tony Hain]

David Conrad wrote:
> ...
> Perhaps we should have 3 buckets.  The first would be a /56, the
> second a /48, and the third, a /40.  Just for fun, let's call them
> class C, B, and A respectively...  (ironic half :-))

That analogy has invalid hidden assumptions. The IPv4 Class A,B,C addresses
were PI space randomly assigned. What we are talking about here is a
consistent bucket size such that subscribers can move between existing
provider aggregates without having to rebuild their network from scratch. 

> 
> > IPv4 will run out of space
> > before most people are ready to move, if for no other reason than
> > they are
> > being lulled into a state of unconsciousness by those who refuse to
> > accept
> > that change is inevitable.
> 
> I doubt IPv4 will ever run out.  As the unallocated pool of IPv4
> becomes smaller and, as a result, RIRs policies and procedures become
> even more unfair and draconian, people will either (a) migrate to
> IPv6, (b) NAT themselves so they only use a couple IP addresses, or
> (c) obtain the addresses they need from the black/gray market.
> Assuming the market will be allowed to exist (and I'd argue it will
> whether or not the RIRs accept the fact), I suspect a combination of
> (b) and (c) will satisfy the needs of most folks unable/unwilling/
> unmotivated to do (a).

The perceived 'unfair' distribution of the IPv4 space is the reason that
governments will not allow the market in address space trading to develop. 

> 
> Speaking only for myself of course, but the way things are going, in
> the end I'm afraid Paul Francis's NUTSS (Nats, Uris, Tunnels, Sip,
> and Stun) "architecture" will win out.  I personally would prefer a
> world in which there was a clear and obvious reason to migrate to end-
> to-end IPv6, e.g., deployable multi-homing and/or trivial
> renumbering, instead of FUD with questionable basis.  However, to
> date, I haven't see that reason.

Complex work around approaches have their value, but when it is cheaper to
operate an IPv6 application than the comparable nat hack version there will
be no contest as cheaper will win out. Getting to the point of cheaper
requires several things; awareness of the costs of operating the nat hack,
or the costs of mangling the application to work through the traversal
technologies; widespread availability of developer tools and libraries that
support IPv6 and remove the need for the app developer to think about
topology issues; key infrastructure components (like the dns root) available
via IPv6 networks; the perception that the IPv6 network reaches places that
are interesting to the app developer; network elements that support handling
IPv6 packets; trained staff to manage those elements; and availability of
addresses. 

The first of those is happening now as service providers have already told
me that application support costs through nat traversal (particularly a 3rd
party nat) are untenable and will bankrupt the business. Libraries and tools
are available though not as widespread as they need to be. Infrastructure
and elements are moving along and I expect them to be ready before the apps
are. Staff training is going to be painful, and after application
development this is the major point of inertia in the system. This leaves
address availability and management. 

We have a plan in place that with appropriate RIR policy about the HD metric
will arguably last for several hundred years. There are organizations that
have business reasons to differentiate prefix lengths, so our task is to
make sure they don't break the ability to reasonably manage the ptr zones,
and that they provide some consistency across providers so that people can
move between provider aggregates without having to rebuild everything. In
the end I would expect IPv6 to be replaced by some other approach long
before we run out of addresses. 

Tony