Jason Thorpe writes:

| NAT also has the problem of being fundamentally incompatible with
| end-to-end security.  It is directly at odds with "prevent the packet
| from being modified or viewed by third parties", since it modifies the
| packet headers, and examines the contents for the purposes of proxying
| e.g. FTP connections.

This is a strange element of doctrine in the IPv6 catechism.

The IP header is strictly useful only for IP-handling equipment,
on a hop-by-hop basis.   Among other things, the IP header's ttl
field has to be decremented on a hop-by-hop basis; this field is
simply not end-to-end.   Likewise, the odd religious goal of 
"protecting the header" is in conflict with other network services
that rely upon interpretations of and modifications to the diff-serv
[ex-tos] field.

Carrying on, the network currently offers a service which is
based on the interpretation of the IP addresses; it is not really
a huge stretch to also allow modification of the IP address fields
in-flight, in the same way that the ex-tos/diff-serv field may
be interpreted and adjusted in flight.

NAT itself does NOT reach beyond the network address fields in
the IP header.  There are places in which the address fields are
used that are, in effect, layering violations, viz. pseudo-headers
and encoding IP addresses in data streams.

These NAT-unfriendly protocols and the applications that use them
quite simply fail when passing through a NAT.   For compatibility
reasons, therefore, most NATs are *ALSO* application-layer gateways
(ALGs) which are sensitive to a set of known NAT-unfriendly applications.

You can encrypt whatever you like - NAT doesn't break the encryption,
it doesn't scramble the bits inside, it simply rewrites the IP header,
and your receiving application fails because either it notices that
the IP header has been modified in a way it doesn't like (too bad), or
it doesn't notice the change at all, and uses bad data.

Unencrypted data are ALG-friendly, in that the ALG can reach in
and adjust the addresses inside the data stream, thus helping
applications that would otherwise not notice the IP header modification.

FTP in active mode is one such popular application.

I personally do not like ALGs.  It is ALGs that have the non-end-to-end
properties you are complaining about.  I personally would like to see
the RETIREMENT of all protocols which are NAT-unfriendly, so we can
resort to using IP addresses ONLY as topological locators, rather
than as identifiers of hosts/services/security-objects/whatever.
However, they are useful for preserving the utility of NAT-unfriendly
protocols in a NAT-filled world.

The conflation of NAT with ALG by some IPv6-Lovers strikes me as
an increasingly desperate ploy to discourage the use of IPv4-lifetime-extension
tools that allow for the localization of scope of transport addresses.

IPv6 sadly is the walking dead with respect to big networks, and
likely will never be much more than an interesting thinking experiment
in how to do a dual-stack transition from IPv4 to something better, someday.

|         -- Jason R. Thorpe <thorpej@zembu.com>
|            ...proud user of 3ffe:0507:0183::/48

	Sean. (echo subscribe IPv6-Haters | majordomo@precision.guesswork.com)