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

From: "Dwight Jamieson" <[email-masked]>
Date: Wed, 23 Nov 2005 13:46:51 -0500

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: Joe Loiacono <[email-masked]>
Date: Wed, 23 Nov 2005 14:27:26 -0500

It's my understanding that if you run an IPv6 only network, you will still 
need a NAT (e.g., NAT-PT) anyway to talk with v4 hosts.

Joe

"Dwight Jamieson" <djamies
@nortel.com>
Sent by: owner-v6ops
11/23/2005 01:46 PM
 
        To:     "Pekka Savola" <[email-masked]>
        cc:     <[email-masked]>
        Subject:        RE: v6ops:IPv4 vs. IPv6 operational costs

Pekka,

---

From: Pekka Savola <[email-masked]>
Date: Wed, 23 Nov 2005 21:41:44 +0200 (EET)

> operating a network with private addressing today?

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.

> percentage of an IT department's budget spent on issues relating to

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: Fred Baker <[email-masked]>
Date: Wed, 23 Nov 2005 12:01:21 -0800

These are a lot of questions. Chair hat off.

There is a desire on the part of most networks to provide external  
access to only those systems that require external access. There are  
a list of reasons, but they all boil down to some flavor of  
"security". If you haven't read it, draft-ietf-v6ops-nap-02.txt gives  
a fairly thorough discussion of this. There is one problem with this  
- one has to in some way filter out external traffic coming into the  
network directed to those addresses. That can be with an ACL, by a  
stronger firewall, or whatever one likes.

My preferred solution is truly simple-minded - make the external- 
facing systems be *only* globally addressable, and in them program a  
null route to the prefix that one is using for one's internal-only  
systems (in IPv6, the internal interface would be addressed using a  
link-local address and one would route to the external-facing  
interface or to a loop-back address). It's a really cheap filter, and  
there is nothing quite like an air gap... Note that this would work  
whether the internal prefix is private or public. It also works for  
both IPv4 and IPv6 - if you're an IPv4 ISP and are using  
192.168.0.0/16 to address your internal-only systems, it works fine,  
and if you're an enterprise using a global address (Cisco uses some  
subset of 171.70.0.0/16 for internal data centers, for example) you  
can shield them just as effectively that way. It does mean that said  
internal-only systems are truly internal-only - they can't, for  
example, do a direct web access to the great wide world, or SMTP to  
some remote system - they have to go through a proxy of some sort. I  
don't know about Nortel, but Cisco does that at least for SMTP  
anyway, and one could imagine doing the same for other applications.  
Solves the multi-homing problem too, at least at the local end.

The first problem with introducing new applications behinds NATs/ALGs  
is that one has to have an ALG to deploy the application. Ask  
yourself how the web was popularized, and ask yourself whether the  
requisite proxy technology would have been deployed at your favorite  
company without there first being a business case to support it. If  
we were trying to deploy the web today, I'm not sure we would be able  
to do so. Note that we would have the same problem with the above  
"air gap" suggestion, apart from the fact that the department in  
question might simply choose to deploy its web access using globally  
addressable systems.

The second problem relates to the kind of application. The web is  
essentially client-server, so the only system that needs anything  
resembling a permanent address is the web server. There is no need  
for IP Mobility etc for the client - it works just fine using  
whatever address DHCP gave the client most recently, regardless of  
how a NAT munges the address. Now say VoIP... in a peer-to-peer  
application anyone can "call" the system, so it needs an address at  
the time that they "call" it. We can put a gateway into a NAT/ 
Firewall if we like; the SIP Proxy lives in the Linksys box or  
whatever, the telephone maintains a relationship with the proxy, and  
when a remote system sends an INVITE to the proxy referencing the  
name of the relevant telephone or group of telephones, the proxy can  
program the NAT link things up. Heck, it can even make the NAT  
translation of the destination address be a multicast address if  
appropriate. But if you want to do it without the proxy, you *have*  
to have a global address if you want to call outside, or you have to  
maintain a relationship with someone who does (as peer2peer  
applications often do for NAT traversal). The question is whether you  
want to be called from outside. If we can simply assume that anyone  
is accessible from anywhere, all that goes away - it becomes easier  
to deploy a new application, and it becomes easier to ddos the system  
deploying it.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 24 Nov 2005 15:09:11 +0100

My assumption is that there will be a one-off operational cost of updating
procedures and scripts, and re-training of staff, when a network switches
to dual stack. But after that peak, IPv6 will just be part of normal
operations and won't stand out as a separate cost at all.

Of course, if you choose a complex co-existence strategy, interworking
boxes will create operations costs of their own. Anybody who's operated
protocol gateways of any kind knows this. That's why I've always been
a strong advocate of straightforward dual stack solutions.

A few years down the road, the simplicity due to having enough address
space and no more NAT-related glitches and complexities should contain
operations costs - but that really is intangible today.

     Brian

Pekka Savola wrote:
> 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.
> 
> 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.
>