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

[Owen DeLong]

On Feb 23, 2011, at 7:42 AM, George, Wes E [NTK] wrote:

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

I think that isn't the argument. I think the argument is we have one or more mega-ISPs wanting
this policy to pass, but if it does not, will be forced to apply for resources for this purpose.
Current policy allows for them to number the necessary hosts accordingly, so, if this policy
does not pass, there is nothing at all that would prevent them from each obtaining large
blocks of addresses for this purpose. I don't know if any one of them could justify a /10
individually, but, I am quite certain that they can collectively easily exceed a /10. I'd estimate
that they can probably come close to a /7, collectively.

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

I think this is a legitimate criticism and would favor adding language to this effect to the draft policy.

Would you support it with that change?

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

Whether you consider it acceptable or not, it comes with greater risks than simply gobbling
up significant resources from the free pool, so, I suspect the less risky behavior is more likely.

> * 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)

But current policy doesn't require this, so, I'm not sure why you think it would magically happen.

> * 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.
> 
I don't think this proposal changes that determinism other than to make it deterministically slightly
later than without it.

Owen