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

[George, Wes E [NTK]]

-----Original Message-----
From: Owen DeLong [mailto:owen at delong.com] 
Sent: Wednesday, February 23, 2011 11:16 AM
Subject: Re: [arin-ppml] [Fwd: Draft Policy 2011-5: Shared Transition Space for IPv4 Address
Extension]

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. 

[WEG] I maintain that if this policy *passes* the same is true. Really, I think your argument is
based on a fundamentally flawed assumption - that there is a huge group of hosts in one or more
mega-ISPs that don't *already* have IPv4 addresses and the requests for resources to address them
are being held back pending the decision on this policy. People aren't going to stake their jobs on
policy happening in the IETF or ARIN especially on a timeline that is advantageous to their business
needs. The mega-ISPs we keep talking about already have enough addresses for their current
customers, so any application of CGN is to manage new growth once it is no longer possible to
satisfy it with BAU IP requests. Growth takes the form of either additional customers (above churn
rate) or (in the case of mobile operators) more simultaneous users that limit your ability to
oversubscribe your DHCP address pools as heavily.
So assuming that this policy gets implemented, you're basically hoping that people accelerate their
plans for CGN instead of just using addresses BAU, and I think that's unlikely, meaning that this
/10 is ultimately wasted.

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

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?

[WEG] If you think it's a legitimate concern, I'd recommend making the change, but that change by
itself doesn't address all of my concerns.

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

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.
[WEG] I agree, which is why I made the comments I made above. I'm just apparently more cynical about
the potential course of action this policy generates within said mega-ISPs.
Consider this: CGN sucks, I don't want to do it unless I absolutely have to, so why should I give up
my place in line for some of the last remaining resources and do it earlier, especially if I *know*
it's going to break things and potentially make me lose some of my customers? That's competitive
advantage if I don't have to do it as soon as one of my rivals (or at all). Is that so far-fetched
of an argument? Why would the presence of a shared block alter that? It just removes one risk
associated with which address range to use. That's it.

> * 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.
[WEG] I'm not expecting magic. However, if current policy is not changed, (and likely even if it is)
ISPs will continue using addresses BAU until they can't get any more. At that time, and IMO *only*
at that time, they will seriously implement CGN to manage new growth. Those who aren't planning to
wait for that trigger point to be at least close have already implemented it, meaning that they've
already found an acceptable (to them) solution to this problem that you're convinced has only one
good solution. If there is no reserved pool of addresses, what choice do those who haven't
implemented CGN yet have but to figure something else out like I list above? There's no need for
policy to enforce it unless you want to try to legislate this behavior *prior* to ARIN's exhaustion
making it necessary.

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/461bf7e7/attachment.p7s>