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.
On Nov 23, 2005, at 10:46 AM, Dwight Jamieson wrote:
Pekka,Looking a few years down the road, assuming that bulk of the bleeding isover, 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:pekkas@netcore.fi] Sent: Wednesday, November 23, 2005 1:33 PM To: Jamieson, Dwight [CAR:NP10:EXCH] Cc: v6ops@ops.ietf.org 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 betweenthe operating costs of an IPv4 network using private addressing vs. anIPv6 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