Home page logo

nanog logo nanog mailing list archives

Re: Verizon DSL moving to CGN
From: Owen DeLong <owen () delong com>
Date: Sun, 7 Apr 2013 22:36:01 -0700

On Apr 7, 2013, at 15:43 , Oliver Garraux <oliver () g garraux net> wrote:

If I'm an ISP deploying a network for users today, I effectively have to provide some mechanism to allow those users 
to get to IPv4 only content.  There is way too much stuff out there that is IPv4 only today.

Agreed... However...

Yes, content providers should provide IPv6 access....but if I'm an ISP, I can't really control that aspect.  If I 
provide users with a service that isn't able to connect to 80% of websites (to say nothing of VPN's, corporate email 
services, etc, that people may need), I'm not going to have a whole lot of business.

I was responding to Mikael's claim that pushing content providers to deploy IPv6 was orthogonal to the need for CGN.

Clearly your statement here indicates that you see my point that it is NOT orthogonal, but, in fact the failure of 
content providers to deploy IPv6 _IS_ the driving cause for CGN.

Now - I completely agree that ISP's must start deploying IPv6 natively.  Legacy equipment that doesn't support IPv6 
is not an acceptable excuse....its just evidence of poor decision making and short-sighed purchasing decisions.  CGN 
clearly isn't ideal and doesn't mitigate the need for native IPv6 connectivity.  But right now, native IPv6 
connectivity is still not a substitute for some level of IPv4 connectivity, even if its CGN'ed.

I don't disagree. You are actually making the exact point I was attempting to make. The need for CGN is not divorced 
from the failure to deploy IPv6, it is caused by it.




Oliver Garraux
Check out my blog:  blog.garraux.net
Follow me on Twitter:  twitter.com/olivergarraux

On Sun, Apr 7, 2013 at 4:06 PM, Owen DeLong <owen () delong com> wrote:

On Apr 7, 2013, at 00:31 , Mikael Abrahamsson <swmike () swm pp se> wrote:

On Sun, 7 Apr 2013, Fabien Delmotte wrote:

CGN is just a solution to save time, it is not a transition mechanism through IPv6
At the end (IPv6 at home) you will need at list :
Dual stack or NAT64/ DNS64

CGN doesn't stop anyone deploying dual stack. NAT64/DNS64 is dead in the water without other mechanisms (464XLAT or 

True... But... Resources deploying/maintaining all of these keep IPv4-limping along technologies are resources taken 
away from IPv6 deployment.

My point is that people seem to scoff at CGN. There is nothing stopping anyone putting in CGN for IPv4 (that has to 
be done to handle IPv4 address exhaustion), then giving dual stack for end users can be done at any time.

Not really...

Face it, we're running out of IPv4 addresses. For basic Internet subscriptions the IPv4 connectivity is going to be 
behind CGN. IPv6 is a completely different problem that has little bearing on CGN or not for IPv4. DS-Lite is also 
CGN, it just happens to be done over IPv6 access. MAP is also CGN.

No, it really isn't. Sufficient IPv6 deployment at the content side would actually allow the subscriber side to be 
IPv4 or dual-stack for existing customers with new customers receiving IPv6-only. The missing piece there is actually 
the set-top coversion unit for IPv4-only devices. (Ideally, a dongle which can be plugged into the back of an 
IPv4-only device with an IPv6-only jack on the other side. Power could be done a number of ways, including POE (with 
optional injector), USB, or other.

I'm ok with people complaining about lack of IPv6 deployment, but I don't understand people complaining about CGN. 
What's the alternative?

IPv6 deployment _IS_ the alternative. They are not orthogonal.


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]