NAT isn't the only answer to the question "I can't get IPv4 addresses,
what do I do?" Using IPv6 and a proxy to reach the IPv4 world is much,
much cleaner. And it also works from v4 to v6. We really should start
advocating this as the preferred transition mechanism.
NAT and proxies are not mutually exclusive. There are advantages to
having a proxy that can forward TCP and UDP traffic from an outside
address/port to an inside address/port and vice versa; there are also
advantages to a NAT that can do the same thing on a per-packet level.
But a good, explicit protocol and API for doing each would be welcome.
It would also be useful if the forwarder/NAT had explicit means of
communicating the "external" source and destination address/port to the
"internal" host - say via the same control protocol used to establish
and maintain the address binding. That would make it relatively easy
to, say, have a server inside an IPv6-only network establish presence on
an IPv4 network provided by an ISP, while still allowing the application
to see the real IPv4 source address (say for logging or spam filtering).
The main thing is to avoid having "transparent NAT" - i.e. NATs that
automatically establish address bindings and start forwarding packets -
in IPv6. A lot of where NAT bites is when it tries to second-guess what
the application is doing. (that goes double for DNS ALG). I'm not
nearly so worried about IPv4-to-IPv6 NATs when the applications are
explicitly aware of the NAT and explicitly manage the binding, and where
the NAT doesn't try to muck with DNS.
Keith
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf