Well, accepting incoming IPv6 connections(!) through NATs would turn the
incoming-connection question from a technical issue into a
firewall-policy-only issue...
I'm with Dan that I don't see NATs disappearing in IPv6 - I remember in the
early days of the NAT working group (back when we thought our opinion about
NATs mattered) that someone got up and said their company had been audited,
and the auditors asked where the NATs were - apparently, this was (at that
time, at least) on audit checklists, and you got dinged if you weren't using
NATs, even if you were using firewalls (and even if you were using host OSes
that didn't roll over every time there was a virus outbreak, but I digress).
I'd love for that to change, but whether people agree about desirability or
not, we can all agree that it would be a change, I think.
Spencer
From: "Iljitsch van Beijnum" <iljitsch(_at_)muada(_dot_)com>
On 15 feb 2008, at 16:09, <michael(_dot_)dillon(_at_)bt(_dot_)com> wrote:
Vendors need to agree on the timeout for mappings and on the
method for substituting prefixes. Even if ignoring port translation
seems obvious, a vendor who is adapting/upgrading old code might
include this in the absence of a standard.
With 1-to-1 address translation without the port overloading the
mappings can be static so there is no need for timeouts. And incoming
connections can be translated just as easily as outgoing connections.
One wonders whether the pro-NAT crowd would actually like something as
open as that. Then again, emulating IPv4 NAT behavior just because
it's the devil we know even though it would require a significant
effort to create IPv6 versions of ALGs and then it would still get in
the way of legitimate applications a whole lot isn't all that
attractive, either.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
http://www.ietf.org/mailman/listinfo/ietf