[arin-ppml] Set aside round deux

[Owen DeLong]

On Jul 26, 2010, at 8:25 PM, Jason Schiller wrote:

> Owen, Martin,
> 
> It sounds to me like you are both missing each other.
> 
>> From Owen's perspective the only acceptable transition solution is a CGN 
> approach with 8,000 (or more) customers share a single IP address.  With 
> this limited definition, only the very largest transit providers would be 
> able to justify a /20 over 30 months.
> 
Not at all... I think that there are many acceptable solutions. However, for
space we set aside specifically for transitional technology only, it seems
to me that the point is to keep it available for transitional usage that has
higher than normal value (more users served per address). Otherwise,
what is the point of setting it aside or marking it separate?

>> From my perspective, it would certainly be best if all exiting IPv4-only 
> networks (at least for their Internet facing content) went dual-stack 
> prior to any transit provider running outof IPv4 addresses for their new 
> customers.  
> 
Of course. On that, we are in complete agreement and I'm doing everything
I can think of to encourage and support that. If you have ideas on other
things I can do, I'm open to them.

> This policy seeks to cover the ground in between these two extreems.  
> 
That may be what it seeks, but, the reality is that I think this suggestion preserves
business as usual for the largest consumers of address space for a very
short time (since it will get used up just about as fast as any other /8 as
it applies virtually no limits on the utilization) while raising the barrier for
smaller organizations.

> For many CGNs are too costly.  And I am not just referring to the cost of 
> purchasing and installing CGN boxes.  I am mostly refering to the problems 
> it creates such as breaking geolocation, breaking content acceleration, 
> breaking advertising decision systems, is difficult to support, 
> scales poorly, requires logging of all session level transactions for 
> CALEA, performs sub-optmially as traffic must be forwarded through the 
> translation node, and creates large anounts of collateral damage when one 
> IP address is taken off line, or placed in the penelty box.
> 
I completely agree. I think CGN/LSN is an absolutely abysmal state of
affairs for all concerned.  I'd hate to see it become widespread, although
if it does, I can think of few better motivators for transition towards IPv6.

> The next best solution is to move this problem to the end-site edge where 
> many of these issues are minamized.  In this case a single IPv4 /32 is 
> required for NAT64.  Likewise, and IPv6-only network could use a single 
> IPv4 /32 for NAT44 allowing them reachability the IPv4 Internet through 
> NAT and the IPv6 Internet natively.
> 
Correct. This is the part of this suggestion that I agree with and would be
allowed under proposal 116 as well. That's not the part I am objecting
to.

> Do people think such a transition mechanism is acceptable? And if so 
> should ARIN support it by making IPv4 addresses available for it?
> 
The bigger question is at what rate and on what basis ARIN should make
those addresses available. If we hand out a /8 in chunks of /20 or larger
as this proposal suggests, organizations that are adding fewer than
200+ customers per quarter would be essentially excluded under this
suggestion as written.

> Additionally current dual-stacked Internet facing services may have need 
> for continued growth.  In some cases it may not be possible to simply cap 
> the IPv4 growth and growth only in IPv6.  To continue to make this service 
> viable, it may require equalivent growth in both address families.
> 
If we had the numbers available, that seems perfectly reasonable. However,
the reality is that if this suggestion were to become active policy, then,
by the time it kicks in, such a provision would ensure that the set-aside
space evaporated at a rate very near to all prior space, making it
essentially a no-op.

> It is important to note in neither case is this business as usual.  For 
> business customers they can no longer get the IPv4 addresses they can 
> justify, instead they get only enough to build a NAT infrastructure.  This 
> represents a significant reduction in address usage.  
> 
It is business as usual for the majority of business customers. The majority
of business customers are small-medium sized businesses that currently
enjoy a /29 or less of IPv4 space. Reducing allocations to them from /29
to /32 will not slow consumption significantly. Yes, this will be harmful
to the large enterprises that don't have staff smart enough to put SSL
terminations on lots of dual-stacked machines or do appropriate
TE gymnastics to manipulate their networks into this suggestion.
I'm not inclined to believe that this represents a significant portion
of large enterprises.

It is business as usual for public-facing servers/services as it places no
restrictions whatsoever on address consumption there.

> For consumer customers that are typically behind NAT, their address usage 
> doesn't change.  One could argue that this policy would not curb their 
> consumption.  One could also argue that they are already being as efficent 
> as possible while avoiding the pain of CGNs.  
> 
Correct. This is also true of small and many medium sized enterprise
customers. That is why this would not change under proposal 116, either.

> In all cases it is not business as usual in that they have to make a real 
> comitment to deploy IPv6 in parity with the IPv4 addresses that they 
> receive.
> 
Putting reachable IPv6 addresses on machines is not a real
commitment to deploy IPv6 in parity with IPv4. It is all that is required
under this proposal. The parity of services is not required as this
suggestion is currently written. If it were, that would make the
suggestion more palatable, but, I still believe it would not sufficiently
curb consumption to make this much more than a no-op as a
policy.

Owen