[arin-ppml] Set aside round deux
schiller at uu.net
Mon Jul 26 23:25:49 EDT 2010
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
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
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
|> 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.
|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:
|Please contact info at arin.net if you experience any issues.
More information about the ARIN-PPML