On Oct 25, 2010, at 7:59 AM, Rémi Després wrote:
That's what tools.ietf.org/html/draft-despres-softwire-sam-01 sec.
3.3 is about.
Provided hosts support it:
- e2e addresses are preserved
- it works even with an independent CPE per ISP (which isn't the
case with NAT66)
Could you explain what you mean here? As long as both devices support
NAT66, NAT66 should work fine in this environment, AFAIK.
Where they are desired, firewalls have to do their own work (they by
no means need addresses translation for this).
Per se, the stateless mechanism proposed by Margaret and Fred in
their NAT66 draft, does break e2e address preservation, but doesn't
do anything to prevent incoming calls. (Their NAT66 draft says:
"RECOMMENDED that NAT66 devices include an IPv6 firewall function,
and the firewall function SHOULD be configured by default to block
all incoming connections.").
This is stated specifically to discourage vendors from shipping a
product that, by default, blocks all incoming connections for IPv4
(due to the IPv4 NAT functionality) and does not block inbound
connections for IPv6. The advantage to separating the NAT and
firewall functionality, though, is that with NAT66, enterprise
administrators _can_ enable whatever inbound connectivity they like.
Every node can be made accessible on all of its available ports, using
a a distinct address per node.
At the time I wrote this, the v6ops group was (I think) recommending
that all sites deploy firewall functionality in IPv6. I've been told
more recently that I should check what those recommendations actually
were, to make sure I am aligned and/or reference them rather than
stating the recommendation here, which would be fine with me.
Margaret
_______________________________________________
nat66 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nat66
