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 .. [EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> 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 | [EMAIL PROTECTED] | | -------------------------------------------------------------------- | IETF IPv6 working group mailing list | [EMAIL PROTECTED] | Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 | -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
