[discuss] we need to fix what may be broken

[Barry Shein]

On April 18, 2014 at 13:40 drc at virtualized.org (David Conrad) wrote:
 > On Apr 18, 2014, at 11:53 AM, Barry Shein <bzs at world.std.com> wrote:
 > > Since the RIRs are contractual entities of ICANN,
 > 
 > There might be some disagreement with this statement.

I stand corrected.

 > > and anyone might
 > > decide to engage in industry missionary work I don't see how one can
 > > say it's beyond ICANN's ability.
 > 
 > During the Singapore ICANN meeting, I suggested that ICANN should spend as much on IPv6 (and BCP38) evangelism as they spend on new gTLD evangelism.  I don't think my suggestion was taken seriously. However, beyond cheerleading, I'm uncertain what ICANN can do.

I listed several things earlier.

I guess if I list specifics of what ICANN might do to mitigate the
IPv6 transition it just invites each being shot down as if this were
an exhaustive proof.

My underlying point is that the downside of IPv6 not succeeding was a
bigger threat to ICANN and others' existence than I think is being
acknowledged.

 > > IPv4 addresses have not run out.
 > 
 > Right - how can a 32-bit integer run out? What has largely "run out" is the free pool of relatively policy-unconstrained unallocated IPv4 addresses. The canonical URL for information about the free pool is http://www.potaroo.net/tools/ipv4/index.html. 

I didn't say "largely".

And I pointed to the current ARIN available IPv4 inventory, about 30M
addresses, as one example RIR.

What I was responding to was the claim that IPv4 addresses have run
out and look, the internet runs fine!

I was saying it's a little more complicated than that and we might not
be quite to the point where we're seeing the effects of IPv4
exhaustion though getting very close.

 > 
 > > The average user won't notice until s/he is denied an address.
 > 
 > The average user will notice either an increase in price or a degradation of service.  The price increase will be due to ISPs passing on the cost of having to obtain addresses on the market, deploy really expensive CGN, or deploy IPv6. All three have a cost: it remains to be seen which is lowest. The degradation of service will result from multiple layers of NAT the average (non-IPv6) user will need to traverse.  Whether that degradation of service is sufficient to drive IPv6 adoption also remains to be seen.

Right now to the best of my knowledge there is no "market", other than
various sub-rosa schemes, but ok.

Users are already being denied IPv4 addresses. There was a time not
that long ago when you could get your own /24 for your house or home
office or pet project/hobby if you were so inclined without much
trouble, just fill out a resource allocation app and write a check.

Today that's nearly impossible.

But that's the new normal so no problem I suppose.

 > 
 > > For example one controversial issue in the RIR space is the creation
 > > and (if yes) management of orderly secondary IPv4 markets.
 > > 
 > > This seems bigger than something each RIR should just proceed with
 > > independently. ICANN is their common denominator for policy.
 > 
 > Not really since this implies a top-down model. ICANN does not control RIR policy.  While I might agree secondary IPv4 markets are bigger than something each RIR should proceed with independently, there currently does not exist any mechanism by which that issue can be addressed (pun intended). As some folks on this list can tell you, this is a topic I've beat my head against for more than a decade.

I know, it's a complicated issue going all the way down to who "owns"
those addresses.

But it was just an example. ICANN might not have the legal force to
compel the RIRs to participate in a IPv4 secondary market.

But if it were a reasonable vision they might all agree to something
amicably. For example, before someone else does it. Markets require
capitalization.

 > 
 > Regards,
 > -drc
 > 

-- 
        -Barry Shein

The World              | bzs at TheWorld.com           | http://www.TheWorld.com
Purveyors to the Trade | Voice: 800-THE-WRLD        | Dial-Up: US, PR, Canada
Software Tool & Die    | Public Access Internet     | SINCE 1989     *oo*