[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: IPv6 adoption behavior



I'm sorry to reply late to this, but I can't help but realize that
NAT+IPv4 vs IPv6+firewall can be equivalent in `isolation'.  Simply
`block in all' and `pass out on $ext_if keep state' (in the pf terms of
OpenBSD) and in two rules you have the same isolation of a NAT+IPv4 as
you do with IPv6+firewall.

I do not get your `reduced functionality' paridim.  It is the NAT network
that has the reduced functionality.  Most people that are using NAT are using
NAT because there was not the address space available from their upstream
to allocate a sufficient amount of IPv4 addresses to cover the subnets and
machines needing addressing space.  I include myself in this group.

Some people (perhaps a larger number of devices, due to enterprise deployment)
seem to think NAT is a safety net, a magic key, that will be a simple firewall
to protect them from the nasties of virueses and such.

To them I simply ask, how do you block mail viruses that are retrieved by the
client?  How do you stop the users inside the NAT from retrieving via other
means (http, nntp, im, etc) nasties that you want to keep out, and also keep
them from blowing up your internal network should a nasty infect a machine?

I believe a firewall + real allocation is superior to NAT in that protocols
that need true address space to operate properly (otherwise require proxies;
for example: ftp, realaudio) .. or they cannot operate at all (ever try to
do ESP IPsec from multiple machines inside nat to a single remote IPsec
gateway?) benifit, and there is only the `fear factor' regarding any other
differences.
-- 
Todd Fries .. todd@fries.net


Free Daemon Consulting, LLC                    Land: 405-748-4596
http://FreeDaemonConsulting.com              Mobile: 405-203-6124
"..in support of free software solutions."

Key fingerprint: 37E7 D3EB 74D0 8D66 A68D  B866 0326 204E 3F42 004A
            Key: http://todd.fries.net/pgp.txt

(last updated 2003/03/13 07:14:10)

Penned by Dan Lanciani on Tue, Oct 14, 2003 at 06:11:24PM -0400, we have:
| Geoff Huston <gih@telstra.net> writes:
| 
| |Indeed. The only other factor here is that it is not entirely a clean 
| |substitution,
| |as NATs provide an alternative product which is an imperfect substitution. 
| |The extent
| |to which the market, over the past few years, has tended towards NATs despite
| |the negative effects in both local and network domains  is quickly
| |becoming the dominant factor in any economic consideration of this entire
| |IPv4 / IPv6 area.
| 
| IMO, to consider IPv6 even as an imperfect substitution for IPv4+NAT is to
| vastly overstate IPv6 functionality.  IPv6 offers absolutely nothing as a
| replacement for NAT's primary function:  isolation of the customer network
| from the (typically business-driven) address policies of the service provider
| (e.g., cost, limits on number and stability, etc.).  If anything IPv6 moves
| in the opposite direction by providing more invasive mechanisms than existing
| DHCP leases for the provider to disrupt the customer's network.  It's all well
| and good to speculate that IPv6 customers won't *need* the isolation that NAT
| now offers with IPv4 because of (insert your favorite fantasy about transparent
| renumbering or philanthropic ISPs) but none of those dodges exist at present.
| Moreover, discussion of solutions that could actually fulfill the prophesy of
| rendering isolation unnecessary (e.g., source routing in its guise of locator/
| identifier separation) are systematically relegated to small discussion lists
| where they pose no threat of implementation.
| 
| You might be able to call IPv6 an imperfect substitution for IPv4 *without*
| NAT except for the glaring problem of single-address multi-homing support.
| Similarly, IPv6+NAT might be said to be an imperfect substitution for IPv4+NAT,
| and is probably what we will end up with if we end up with IPv6 (as an IPv4
| replacement) at all.  More likely v4 and v6 will continue in parallel forever
| since the upgrade costs are significant, especially when you consider the
| reduced functionality.
| 
| 				Dan Lanciani
| 				ddl@danlan.*com
| 
| --------------------------------------------------------------------
| IETF IPv6 working group mailing list
| ipv6@ietf.org
| Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
| --------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------