[arin-ppml] Set aside round deux

[Jason Schiller]

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.

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

This policy seeks to cover the ground in between these two extreems.  

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.

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.

Do people think such a transition mechanism is acceptable? And if so 
should ARIN support it by making IPv4 addresses available for it?

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.

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.  

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.  

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.


__Jason
  



==========================================================================
Jason Schiller                                               (703)886.6648
Senior Internet Network Engineer                         fax:(703)886.0512
Public IP Global Network Engineering                       schiller at uu.net
UUNET / Verizon                         jason.schiller at verizonbusiness.com

The good news about having an email address that is twice as long is that
it increases traffic on the Internet.

On Mon, 26 Jul 2010, Hannigan, Martin wrote:

|Date: Mon, 26 Jul 2010 17:30:30 -0400
|From: "Hannigan, Martin" <marty at akamai.com>
|To: Owen DeLong <owen at delong.com>
|Cc: "arin-ppml at arin.net List" <arin-ppml at arin.net>
|Subject: Re: [arin-ppml] Set aside round deux
|
|
|
|
|On 7/26/10 5:00 PM, "Owen DeLong" <owen at delong.com> wrote:
|
|> I did read it... A little math...
|
|
|> 
|> Let's assume you're trying to use this for NAT64 boxes... At an estimated
|> 5,000 customers per NAT64
|> box (most people I've talked to are talking between 8,000 and 80,000 per box),
|> to qualify for a /20
|> using a single /32 per NAT box, you need 4,096 NAT boxes or at least 80% of
|> 20,480,000
|> which works out to 16,384,000 customers in order to justify a minimum
|> allocation under this policy.
|> 
|> If you think that small providers have 16,000,000+ customers, we have
|> radically different ideas
|> of what constitutes small.
|> 
|
|
|That would be some very fuzzy math from my perspective. If the same network
|that only needs a /32 for a NAT device also needs a /20 to use for purposes
|defined on the acceptable use list then I think that they're in good shape.
|If a network is so small and not expecting to grow at all in $time, I'm not
|so sure why it wouldn't make sense for them to scrounge up an address or ask
|their upstream for "one" (both of which are much more likely to be routable
|at least in the early stages of transition).
|
|Alas, I'm not really in a position to argue the min/max until I receive some
|constructive feedback, which was the main purpose of the post.
|
|
|Best,
|
|-M<
|
|
|_______________________________________________
|PPML
|You are receiving this message because you are subscribed to
|the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
|Unsubscribe or manage your mailing list subscription at:
|http://lists.arin.net/mailman/listinfo/arin-ppml
|Please contact info at arin.net if you experience any issues.
|