[arin-ppml] Use of "reserved" address space.

[Owen DeLong]

On Jun 27, 2010, at 3:05 PM, William Herrin wrote:

> On Sun, Jun 27, 2010 at 2:09 PM, Owen DeLong <owen at delong.com> wrote:
>>> What isn't debatable is that we're approaching a dire shortage and
>>> right now 240/4 is a honking lot of address space that benefits
>>> exactly _nobody_.
>>> 
>> But pulling resources off of IPv6 deployment to make this address space
>> workable, even in the scenarios you suggest simply doesn't make sense.
>> Taking resources away from a solution in order to propel a hack that will
>> by all accounts take nearly as long as the solution in order to develop
>> and deploy, especially when the solution already has momentum and
>> is accelerating simply doesn't make sense to me.
> 
> Not a zero sum game. The likely resources mostly aren't working on
> IPv6 right now regardless.
> 
We can agree to disagree about this. Even if the resources aren't working
on IPv6 right now, they could be. Redirecting them to this sort of boondoggle
instead is a zero sum game or worse.

>> It seems sort of like deciding to pull the experts off the efforts to cap the
>> well in the Gulf of Mexico in favor of having them build oil containment
>> booms, since we don't have nearly enough of those.
> 
> More like ramping up the manufacturing of oil booms independent of the
> experts daily activities since the experts really aren't needed to
> explain how to manufacture a plain old oil boom.
> 
Except in this case, we don't have those multiple pools of resources. There
is still lots of development work that needs to be done to bring IPv6 to
fruition. Feature parity still isn't there in lots of things like load-balancers,
firewalls, etc.

> 
>>>> Better to focus on v6 transition.
>>> 
>>> Myopic. Unless another credible solution presents, IPv4 carrier NATs
>>> -ARE- the v6 transition.
>>> 
>> IPv4 carrier NATs are the temporary hack to get around the incomplete
>> nature of the transition at runout. The transition is to native dual stack or
>> native IPv6.
> 
> I hear exactly zero chatter in the ops forums about bypassing dual
> stack in favor of going direct to native v6. I know some work has been
> done on nat64 but are you aware of shipping COTS products designed for
> enabling large scale collections of native v6 clients to communicate
> with v4 servers?
> 
Who said anything about bypassing dual-stack? We need to be dual-stacking
the servers and the content as fast as possible to minimize the need for
providing IPv4 solutions to clients that can't get IPv4 addresses, because,
reality is there are NO GOOD solutions for that situation.

LSN, nat64, and all the others all have their own different sets of pitfalls.
However, if we can dual stack the majority of the content and/or services
that end users care about prior to run out (and I believe this is actually
possible), then, new end-users getting IPv6-only with hacks to reach a
tiny subset of internet content that isn't IPv6-yet will be a lot less traumatic
than the alternatives.

> Unless something changes, the transition is to dual stack. Which
> requires an IPv4 address. From somewhere.
> 
The transition only needs to be to dual stack at one end of the equation.
Dual-stacking the content and servers can still be done in time.
Dual-stacking the eye-balls is a daunting task, and, as you point out,
eye-ball growth will eventually preclude doing so because of a lack
of IPv4 addresses with which to dual-stack.

Owen