Light Reading
Chris Donley, project director for network protocols at Cable Labs, explains the problems CGN will introduce for some network services
Video

The Case Against Carrier-Grade NAT

50%
50%
Newest First  |  Oldest First  |  Threaded View
Page 1 / 2   >   >>
yarn
50%
50%
yarn,
User Rank: Light Sabre
12/5/2012 | 4:58:57 PM
re: The Case Against Carrier-Grade NAT


If CG-NAT would not break any applications, IPv6 would probably not happen for another 5 to 10 years. So rejoice!

paolo.franzoi
50%
50%
paolo.franzoi,
User Rank: Light Beer
12/5/2012 | 4:58:56 PM
re: The Case Against Carrier-Grade NAT


 


I also believe he stated only 1 of the 2 use-cases for CGNAT and maybe I am using this term incorrectly but it is what we call it here.


The second problem is that IPv6 can not address IPv4 directly nor the other way around.  Many devices in the world are going to have to be "dual stacked".  This means that they run both IPv4 and IPv6 at the same time.  It also means that anybody who wants to address devices in both domains will require an IPv6 address as well as an IPv4 address.


THAT is the problem.  Who in their right mind wants to put their content on an IPv6 network if nobody can get to it.  When we have written about CGNAT in the past what I thought we were discussing is the notion of the ability of IPv4 devices to have a presence in the IPv6 world (and vice versa) via a carrier based translation service that (at my site at least) we call CGNAT.


What was being discussed here seems like an alternate strategy to address translation.  Which is to double NAT in the IPv4 domain.  That will not solve the other problem of switching content simultaneously to IPv6.  


seven


 

fgoldstein
50%
50%
fgoldstein,
User Rank: Light Sabre
12/5/2012 | 4:58:56 PM
re: The Case Against Carrier-Grade NAT


NAT is your friend.  It only breaks broken applications.


Point-of-attachment addresses don't belong in the application layer.

fgoldstein
50%
50%
fgoldstein,
User Rank: Light Sabre
12/5/2012 | 4:58:55 PM
re: The Case Against Carrier-Grade NAT


He was talking about 4-4 NAT, not 4-6 NAT.  I see no point to 4-6 NAT, 6-6 or anything else with a 6 in it.  Once you realize that v6 was and is an Epic Fail of massive proportions, it al starts to make sense.


The problems he cited were that some NATs add latency or have limited capacity.  That's a capacity engineering problem; buffering strategy is often a problem, since some folks insert too much.


 

paolo.franzoi
50%
50%
paolo.franzoi,
User Rank: Light Beer
12/5/2012 | 4:58:55 PM
re: The Case Against Carrier-Grade NAT


 


Is your solution then to recover by force many of the IP address blocks that are wasted?  If we did that we could certainly delay IP address exhaust a LONG time.  Or are you suggesting we make an IPv7 which is completely different?


And I know he was only talking about double 4 NAT.  The problem is that this only solves one of the two huge hurdles on top of us.  Not the big one either.  Even if you are not happy with IPv6, then how about something more helpful than IPv6 sucks.


seven


 

rainbowarrior
50%
50%
rainbowarrior,
User Rank: Light Beer
12/5/2012 | 4:58:54 PM
re: The Case Against Carrier-Grade NAT


I think BrooksSeven has a salient point.


With 84% of the current IPv4 address space completely unused, doesn't it make sense to just go through the administrative excersise of reclaiming and reallocating them? Isn't that easier than a compelete vertical and horizontal change to all applications, networking gear and back office systems that IPv6 requires?

fgoldstein
50%
50%
fgoldstein,
User Rank: Light Sabre
12/5/2012 | 4:58:54 PM
re: The Case Against Carrier-Grade NAT


Reclaiming space would buy a lot of time.  But the point is that client devices never belong on public IP address space.  The v4 address space should be used for gateways and public-facing servers.  Private nets should stay in net 10.


IPv4 addressing architecture is incomplete.  Applications should be addressed by name.  IPv6 does not fix this; it just makes for more wrong numbers, so to speak. As a stopgap (not to v6; as you might remember, I advocate RINA as the real answer), one should think about the "address" as being one 48-bit (IP+port (field, not as if they were separate layers. NAT gets this, but fundamentalists who believe old textbook descriptions of ARPANET protocols don't. And that's who wrote v6.


 

rainbowarrior
50%
50%
rainbowarrior,
User Rank: Light Beer
12/5/2012 | 4:58:54 PM
re: The Case Against Carrier-Grade NAT


I think BrooksSeven has a salient point.


With 84% of the current IPv4 address space completely unused, doesn't it make sense to just go through the administrative excersise of reclaiming and reallocating them? Isn't that easier than a compelete vertical and horizontal change to all applications, networking gear and back office systems that IPv6 requires?

paolo.franzoi
50%
50%
paolo.franzoi,
User Rank: Light Beer
12/5/2012 | 4:58:53 PM
re: The Case Against Carrier-Grade NAT


Okay, so I agree with your first paragraph (espeically if you read my comments to Carol).


I guess I am confused on how application addressing is going to help us with address exhaust.  At some level some switching/routing device must move packets along to the next stop.  Even if there is an application address, that name will not be unique per endpoint.  So, we would still have to resolve that application on that endpoint.  I think the idea of separating the addresses here is that you do not want to have to update the network to be able to introduce a new application.  You want the endpoints to be able to talk applications to each other while the network blithely shuffles packets between them.


Don't get me wrong, I am not thrilled with IPv6 but I think that is a ship that has sailed soon if we don't reclaim addresses.


seven


 

rainbowarrior
50%
50%
rainbowarrior,
User Rank: Light Beer
12/5/2012 | 4:58:51 PM
re: The Case Against Carrier-Grade NAT


A lot of people in the network vendor and service provider community will say privately that IPv6 has already failed. The core protocols have been around for over 10 years with almost zero global adoption. V6 advocates say that this is because the industry is lazy, greedy, short-sighted and/or ignorant- but the other side of the coin is that a set of protocols that don't offer enough inherent value to make lazy, greedy, short-sighted people want to implement them don't deserve to be implemented.


A lot has changed since V6 was proposed back in the mid-90's. Is it time to write-off v6 and move on?


Can we start having an open and honest conversation about this? Or do we all have to politely pretend to be making the transition?

Page 1 / 2   >   >>
Flash Poll
From The Founder
It's clear to me that the communications industry is divided into two types of people, and only one is living in the real world.
LRTV Huawei Video Resource Center
Interview With Rick Talbot, Principal Analyst, Current Analysis

10|31|14   |   2:12   |   (0) comments


At the NFV Open Cloud Forum 2014, Rick Talbot shared his positive feedback about the holistic and open approach that Huawei adopts for SDN and NFV. He also found the open sharing at the event valuable as it features different perspectives from Huawei experts, telecom operators, industry analysts as well as security experts.
LRTV Huawei Video Resource Center
Interview With David Snow, Principal Analyst, Current Analysis

10|31|14   |   2:24   |   (0) comments


David Snow talked about his understanding of Huawei and its SoftCOM strategy at the NFV Open Cloud Forum 2014, saying that Huawei's wide approach combining IT and CT expertise, introducing big data and analytics into solutions and contributing to the OpenStack community particularly resonate with him and make the company stand out in the industry.
LRTV Huawei Video Resource Center
Interview With Roz Roseboro, Senior Analyst, Heavy Reading

10|31|14   |   3:13   |   (0) comments


Roz Roseboro commented on Huawei's data center capabilities and NFV solutions at the NFV Open Cloud Forum 2014, saying that in addition to covering all three key domains of compute, storage and networking, the company also emphasizes the importance of management capabilities and professional services, which are essential in making NFV a reality.
LRTV Huawei Video Resource Center
Interview With Michael Howard, Co-founder & Principal Analyst, Infonetics Research

10|31|14   |   5:25   |   (0) comments


Michael Howard talked about SDN, NFV, and OpenStack adoption at Huawei's NFV Open Cloud Forum 2014. Particularly, he pointed out that Virtual Enterprise CPE is the top NFV use case that operators plan to invest in over 2014 and 2015 to deliver new enterprise services through virtualized functions.
LRTV Huawei Video Resource Center
Interview With Jerry Caron, Senior Vice President, Current Analysis

10|31|14   |   3:11   |   (0) comments


At Huawei's NFV Open Cloud Forum 2014, Jerry Caron from Current Analysis said that orchestration and management are key to realizing SDN and NFV for global carriers, and the approach that Huawei is taking, with its FusionSphere Cloud OS at the core, is in the right direction to address the challenges.
LRTV Documentaries
Broadband Battles

10|31|14   |   01:39   |   (0) comments


This year's Broadband World Forum featured a number of show floor battles focused on access gear, components and coffee.
Jonestown
Mobile Backhaul: Going to the Dark Side?

10|30|14   |   2:26   |   (1) comment


Heavy Reading's Patrick Donegan shares his view on a dark trend that bubbled up at Light Reading's annual backhaul conference in NYC.
LRTV Huawei Video Resource Center
2014 Huawei Electric Power Industry Summit: Interview With CEO of SwitchCom

10|30|14   |   4:13   |   (0) comments


SwitchCom, an IT company based in Angola, recommends a variety of Huawei solutions and hardware to their customers in the energy industry.
LRTV Huawei Video Resource Center
2014 Huawei Electric Power Industry Summit: Interview With Ethiopia's Ministry of Water Irrigation & Energy

10|30|14   |   4:08   |   (0) comments


Gosaye Mengistie of Ethiopia's Ministry of Water Irrigation & Energy discusses the collaboration with Huawei in that country.
LRTV Huawei Video Resource Center
2014 Huawei Electric Power Industry Summit: Interview with Dongfang Electronics Corporation

10|30|14   |   5:46   |   (0) comments


Dongfang Electronics Corporation, headquartered in Chengdu, China, is one of China's largest manufacturers of power generators and contractors of power station projects.
LRTV Huawei Video Resource Center
2014 Huawei Electric Power Industry Summit: Interview with Zimbabwe's Customers

10|30|14   |   3:31   |   (0) comments


Representatives of Zimbabwe's Ministry of Power and Development discuss the energy needs of their country as well as new areas of improvement due to enhanced ICT capabilities.
LRTV Huawei Video Resource Center
2014 Huawei Electric Power Industry Summit: Interview With Colbún Chile

10|30|14   |   4:29   |   (0) comments


In Chile, an aging energy infrastructure was in dire need of a modern update. Claudio Valenzuela of Colbún discusses how Huawei's ICT solutions continue to provide crucial information to improve the grid and how an in-country engineer is a cricial asset.
Upcoming Live Events
November 6, 2014, Santa Clara
November 11, 2014, Atlanta, GA
December 2, 2014, New York City
December 3, 2014, New York City
December 9-10, 2014, Reykjavik, Iceland
February 10, 2015, Atlanta, GA
May 6, 2015, McCormick Convention Center, Chicago, IL
May 30, 2015, The Westin Peachtree, Atlanta, GA
June 9-10, 2015, Chicago, IL
Infographics
WhoIsHostingThis.com presents six of the world's most extreme WiFi hotspots, enabling the most epic selfies you can imagine.
Hot Topics
Microsoft's Skype Embraces WebRTC on IE
Sarah Reedy, Senior Editor, 10/27/2014
FTC Slaps AT&T With Throttling Lawsuit
Sarah Reedy, Senior Editor, 10/28/2014
Wheeler Gets Down With OTT
Mari Silbey, Independent Technology Editor, 10/29/2014
China's MVNOs Hit the Wall
Robert Clark, 10/27/2014
Let's Not Kill SDN & NFV With Silos
Francois Locoh-Donou, Senior VP, Global Products Group, Ciena, 10/28/2014
Like Us on Facebook
Twitter Feed