[discuss] we need to fix what may be broken

Fri Apr 18 20:40:45 UTC 2014

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.

> 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.

> 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. 

> 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.

> 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.

Regards,
-drc

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://1net-mail.1net.org/pipermail/discuss/attachments/20140418/2ff78998/signature.asc>