Subject: RE: v6ops:IPv4 vs. IPv6 operational costs

From: "Sofia, Rute" <[email-masked]>
Date: Wed, 23 Nov 2005 20:55:24 +0100

Hello,

Considering IPv4, a NAT "serves" two purposes: from a basic perspective,
either within the operator's net (to deal with overlapping IPs) or to
allow a set of devices to achieve global IP connectivity by means of a
single (globally routable) IP address.

Assuming that you are referring to the most popular option - the second
- then using a NAT requires workarounds to allow bi-directionality and
to cope with applications that embed IP addresses in the payload. Being
a translation solution, the first problem is that it adds entropy to the
end-to-end path. Notice that in most cases, translation may be required
in more than one point. Furthermore, ALGs have to be developed for
already existing applications, or new applications *must* consider that
a NAT is in the way. Or, NAT traversal techniques (STUN, etc.) can be
applied but again, there is always entropy added.
Is it very hard to deploy an ALG, or to rely on NAT traversal
techniques? Not really, but the problem is again: entropy added to the
end-to-end path and each time a new application emerges, one has to find
a way to deal with the NAT...this means that new services are now in
most cases dictated by the NAT existence which is pretty limitative.
Imagine trying to place in the future multicast sources behind a NAT,
for instance...or using mobility...

I do not know if it's possible to "quantify" the operational costs of
NAT+private addressing vs. IPv6. In fact, IMHO that does not really make
sense. Particularly because the operator has no chance to really reach
anything behind a NAT - unless you are referring to the use of a NAT
somewhere in the access, not in the extremes, as mentioned.

So, IMHO, what can be compared: the possibility of having *global*
connectivity per device - new services will for sure appear. And, due to
autoconfiguration it is possible to simplify the operations required to
provide connectivity to a group of devices. Despite the fact that such
features may or not be complete within the current standards - they are
not - the fact is that IPv6 autoconfiguration is one of the most
interesting features IPv6 has.

Regards,
Rute

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Dwight Jamieson
> Sent: Wednesday, November 23, 2005 7:47 PM
> To: Pekka Savola
> Cc: [email-masked]
> Subject: RE: v6ops:IPv4 vs. IPv6 operational costs
> 
> Pekka,
> 
> Looking a few years down the road, assuming that bulk of the 
> bleeding is
> over, will operating that network be simpler, easier, cheaper than
> operating a network with private addressing today?
> 
> How painful is introducing new applications behind NAT/ALGs? What
> percentage of an IT department's budget spent on issues relating to
> private addressing?
> 
> 
> -----Original Message-----
> From: Pekka Savola [mailto:[email-masked]] 
> Sent: Wednesday, November 23, 2005 1:33 PM
> To: Jamieson, Dwight [CAR:NP10:EXCH]
> Cc: [email-masked]
> Subject: Re: IPv4 vs. IPv6 operational costs
> 
> 
> On Wed, 23 Nov 2005, Dwight Jamieson wrote:
> > Is anyone aware of any studies that quantify the 
> differences between 
> > the operating costs of an IPv4 network using private 
> addressing vs. an
> 
> > IPv6 network using globally unique addresses?
> 
> I've not but I'd be interested to see _real_ calculations.
> 
> I assume from your wording that you're referring to an IPv6-only 
> network.  If so, my suspicion is that the costs can be high as you 
> need to live on the bleeding edge, i.e., are the one that'll find the 
> bugs, need to get a lot of consulting to get the network to work as 
> v6-only, etc.
> 
> -- 
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
> 
> 
>

---

From: "Dwight Jamieson" <[email-masked]>
Date: Wed, 23 Nov 2005 14:59:59 -0500

>> Looking a few years down the road, assuming that bulk of the bleeding

>> is over, will operating that network be simpler, easier, cheaper than

>Once that point is reached, I'd suspect so.  There's also an 
>alternative or a variation: keep using the existing v4 infrastructure 
>(for simpler applications), but introduce the new apps to (only) v6.

Yes, that would be the transition path. New apps would be v6 only. 
Existing apps would be transitioned to v6 only, as soon as that makes
sense
The core would be transitioned to IPv6 soon as it makes sense
Hosts would remain dual stack as long as v4 only services need to be
reached
 - tunnel hosts v4/v6 to a dual stack router/relay
 - of course this requires NAT, but hopefully limited ALG support

>That's a good question.  I'd guess that getting non-trivial apps 
>(e.g., VoIP, video conferencing, etc.) to work across NATs is 
>non-trivial exercise.  I'd guess that most cost is borne by those 
>folks who write and need to support those applications.  That includes 
>the enterprise if the app is important enough to the enterprise.

---

From: "Sofia, Rute" <[email-masked]>
Date: Thu, 24 Nov 2005 16:56:20 +0100

Dwight,

> controlled P2P type
> service. The service has been developed to work on both
> IPv4/NAT/ALG(proxy) and IPv6 using global addresses. 
>  - will the IPv6 solution be easier/faster/cheaper to deploy?
>  - will the IPv6 solution be easier/cheaper to maintain and operate?
>  - will the IPv6 service typically offer enhance features (allowing
> content anywhere)?
>  - will it be typical for services to be developed for both IPv6 and
> IPv4/ALG or IPv6 first because it's easier or IPv6 only?
>  - others?

I am afraid that *we all* would like to have *quantitative* answers concerning such numbers. :) However, that is impossible to get. As Tim mentioned and related to (6NET) - NRENs expertise - you have plenty of info stating how to do things and the possible gaps.

> 
> From the replies to the original question, it seems that many
> applications will be easier/cheaper to deploy and operate using IPv6
> global addresses, but it's not clear how heavy the cost factor will be
> in the decision making process.
> 

There is no magic answer to the questions above. IP is IP so don't expect any major breakthrough. Having global connectivity is something that at least today can only be achieved (from a wide perspective) by means of IPv6. Or, one keeps adding hacks to deal with NAT.

The cost factor will for sure have some impact in the situation. But possibly what is really preventing a migration to IPv6 is 1) lack of generalized knowledge about current features and how mature is IPv6 when compared to IPv4 and 2) where is the business case for it.

The answer to 1) is provided by deployments in GEANT, Abilene or CERNET2, the research backbones. It shows that IPv6 is at least mature. And it is also provided by Japan IPv6 infrastructures and (starting to emerge) commercial services.
The answer to 2) is harder to get. Mainly because IPv6 is not a disruptive technology. Possible operational savings will only be seen in the long-run. Not by trying to compare IPv6 vs. IPv4 private addressing+NAT...

Regards,
Rute

> Dwight
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Tim Chown
> Sent: Thursday, November 24, 2005 4:24 AM
> To: [email-masked]
> Subject: Re: v6ops:IPv4 vs. IPv6 operational costs
> 
> 
> On Wed, Nov 23, 2005 at 01:21:25PM -0800, Fred Baker wrote:
> > that would surprise me. My Mac is dual stacked now, and they tell me
> > that Windows Leghorn (Longhorn?) will be as well. Comes 
> that way out  
> > of the box.
> > 
> > The question will be whether IT departments turn it on in the
> > network, not whether the hosts will use it if hey do.
> 
> The question isn't only the 'cost', it's also about the benefit.  You 
> also need to define 'cost' :)
> 
> Our experience of deploying dual-stack as far as open source 
> and vendor 
> provided solutions go on an enterprise of over 1,000 hosts is that the
> additional 'cost' is low.   
> 
> We didn't buy new hardware specifically for IPv6.   We used to run a
> parallel IPv6 routing infrastructure on BSD, but went 'properly' dual
> stacked when we reprocured our old IPv4 equipment this summer.   No
> extra cost per se.   The MRs on the procurement meant the new kit 
> supported IPv6 features (unicast amd multicast).   The costs 
> lie more in
> 
> managing the additional protocol, and in ensuring support staff have 
> expertise to do their job.
> 
> For most platforms, deployment Just Works.   The main gaps we 
> have lie 
> in certain vender applications (e.g. Exchange) and in commercial
> firewall 
> product, but from the host and router platform view, the picture is
> good. We have no issues running DNS, MXs, web, etc dual-stack.
> 
> We have occassional minor operational issues, but these cause very 
> little extra supprot effort.
> 
> By deploying dual-stack early, we believe our staff gain the expertise
> in IPv6 at an early stage.  As an educational site, we expose our CS
> graduates
> to be to the technology.   That is a benefit in our context.
> 
> I would imagine the backbone NRENs that have deployed would say
> likewise, provided they deployed IPv6 incrementally through new
> procurements 
> rather than going out and buying new line cards specifically 
> to support
> IPv6 in hardware.   
> 
> You can find example deployment reports at www.6net.org.
> 
> In terms of benefits, well, restoring global addressability is
> important, and in places where IPv4+NAT was used we can run IPv6 in
> parallel and use point to point conferencing and other 
> applications that
> would have 
> been very hard to do between two NATed sites.   Dual stack 
> with IPv4+NAT
> 
> alongside IPv6 will be common, I believe.
> 
> Another benefit is that, as an educational site, we see new innovation
> and 
> interest in networking, I believe in part because catering for NATs is
> no 
> longer an issue.   A couple of student developed packages 
> have attracted
> 
> (some) commercial interest.
> 
> I think Fred sums it up well when he says that had a business 
> case been
> required for the web, it probably wouldn't have happened.
> 
> -- 
> Tim/::1
> 
> 
> 
>