[arin-ppml] [Fwd: Draft Policy 2011-5: Shared Transition Space for IPv4 Address Extension]

[George, Wes E [NTK]]

-----Original Message-----
From: wherrin at gmail.com [mailto:wherrin at gmail.com] On Behalf Of William Herrin
Sent: Tuesday, February 22, 2011 10:06 PM
Subject: Re: [arin-ppml] [Fwd: Draft Policy 2011-5: Shared Transition Space for IPv4 Address
Extension]

It seems to me there are only two deciding questions for this proposal.
1. Should ARIN go counter to the IETF's determination not to create an ISP-local address space?

[WEG] Well, technically reserved address space is the purview of the IETF directing IANA (or all
RIRs agreeing to a global policy to direct IANA to do something). However, given that IANA no longer
has any address space to reserve for this purpose, it really doesn't matter anymore. ARIN should do
whatever its members direct it to do. That doesn't change the fact that I still think it's a bad
idea regardless of where it's implemented, but I'm not opposed to it simply on procedural grounds as
you implied.

2. Is an ISP-local address space a better use of a /10 _for ARIN-region registrants_ than giving
that /10 exclusively to whichever of the mega-ISPs happens to get to it first?

[WEG]  No, I don' t think that it is, even when you phrase it like that. 
* I reject the argument that we have one or more "mega-ISPs" waiting for this policy to die so that
they can make that final large allocation request (or to live so that they don't have to). It's
simply naïve to think that "the common good" is the only thing preventing them from doing what's
right for their business. They haven't because they can't justify the space.
* The Policy as written does not make inside NAT pool addresses an invalid use of current or
newly-allocated space (aka, it doesn't *require* the use of shared space for an inside NAT pool),
meaning that the same mega-ISPs we seem to be trying to prevent from decimating the free pool could
simply say, "I don't want to have to use that /10 10 different times in my network, or use shared
space at all, so I'm going to request my own block" or, keep justifying addresses BAU until
exhaustion.
* While neither IETF nor ARIN can exactly condone squatting on allocated but unrouted space, I
believe this to be an acceptable alternative should RFC1918 be found unsuitable as an inside NAT
pool. Doing nothing would be implicitly acknowledging the fact that it's *already being done*.
* If neither of the above are viable for some reason, we are within our rights to expect ISPs to
carve out a block of their existing space for this use - CGN applied to their existing deployment
would allow them to reclaim addresses by sharing them among more than one customer, freeing
addresses to be used as an internal NAT pool. Nevermind the idea of creating an incentive for more
efficient use of IPv4 in infrastructure (1918, moving to IPv6, etc)
* I believe that at this point it is simply better to let the IPv4 address exhaustion happen without
any significant fiddling with it so that it is more deterministic.

Hopefully that summarizes more succinctly

Wes George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6781 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20110223/b80beff6/attachment.p7s>