[arin-ppml] CGN multiplier was: RE: Input on an article by Geoff Huston
owen at delong.com
Wed Sep 14 00:08:59 EDT 2011
Let me attempt to provide some useful comparisons:
Feature LSN IPv6
Sustainable Client Hosts ≤64,000,000,000 ≥100,000,000,000,000,000,000 at least.
Sustainable Servers ≤3,200,000,000 ≥100,000,000,000,000,000,000 at least.
Peer-to-Peer capabilities Limited, if any Anything mutually permitted by administrators
Security Dysfunctional, broken End-to-end addressing, in tact audit trails,
audit trails, limited stateful stateful inspection and/or ACLs available
Geolocation Implementation Dependent Can be more accurate than current IPv4 geolocation
Direct VOIP Dysfunctional at best Fully functional if permitted by administrators
Opportunistic Encryption Unlikely to work Relatively straight forward using IPSEC
Performance Reduced by additional Similar to native IPv4 without NAT
Game Hosting Eliminated or very restricted Easily achievable if permitted by site admin.
Internet of Things Virtually Impossible Already beginning to emerge
Remote Access to Residential Requires third party Easily permitted by local administrator
Permanent reachable address Unlikely at best Easily achievable, but requires support
from service provider
Log Retention Storage ≥1Mbyte/day/end-site Similar to current IPv4 deployments
Ongoing Support Cost $unknown Similar to current IPv4 costs
Ability to reach entire internet monotonically decreases monotonically increases
over time over time
 Server and client numbers are mutually exclusive and real answer will be some mix of clients and servers
in between. Every server is effectively 20 clients.
 Server and client numbers are not mutually exclusive, but, only address scalability is considered.
 Assumes a 20:1 address sharing ratio for clients. The sustainability of this ratio and/or its level of functionality
is highly controversial, but few people claim that address sharing beyond 20:1 will be at all functional.
 If carriers use large regional NAT centers, geolocation may be completely obfuscated. If carriers implement
reasonably local NAT environments, geolocation may remain largely functional (for that provider).
 Depends on development and deployment of better geolocation databases for IPv6 than currently exist.
 Amount of storage required to keep necessary logs to identify a subscriber from flow data
 Today IPv4 can basically reach the entire internet (though I'm not sure that is true with LSN). In the near
future, dual stack will be required to reach everything. Over time, there will be more and more IPv6 and less
and less IPv4. LSN will only reach the dwindling IPv4 portions of the internet.
Generally speaking, I believe that the vast majority of access providers are not looking at LSN as a way
to avoid deploying IPv6, but, rather as a way to cope with the need to provide some continued support
for IPv4 in the face of an ever worsening address shortage. I believe that most providers that are planning
to deploy LSN are planning to deploy it in parallel to some form of IPv6 capability for their end users and
that the better user experiences will be on IPv6 overall. It is my understanding from the access providers
that I have discussed the matter with that their intent is to deploy as little LSN as they can get away with
and focus on getting as much stuff on to IPv6 as quickly as is feasible, modulo customer limitations.
On Sep 13, 2011, at 3:21 PM, Paul Vixie wrote:
> On Tue, 13 Sep 2011 15:49:24 -0400
> Tom Vest <tvest at eyeconomics.com> wrote:
>> I don't claim to know the answer, or even how one would go about
>> calculating one, but then I believe that the value is "u" is very
>> close to being the inverse of Y (at best), so I don't require an
>> actual solution in order to be persuaded that CGNs wouldn't alter the
>> results -- not in any direction that we might wish for, anyway.
> intuitively, i agree (u being the inverse of Y). however, some don't.
> i was specifically asked what native dual stack could offer that would
> be a compelling value add compared to nat (including cgn). intuition
> is not a good enough answer, we need to be able to communicate about
> sharp short/medium term distinctions between the service levels or else
> some investors are going to figure that cgn is their whole IPv6
> deployment horizon.
> Paul Vixie
> 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