Le 25 oct. 2010 à 15:03, Margaret Wasserman a écrit : > > 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.
OK, I could have explained more what I was referring to. This relates to ingress filtering. If a host sends a packet, it has no way, with NAT66 to make sure it goes to the right CPE (that of the ISP whose prefix is at the beginning of the source address. > >> 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. IMHO, for unmanaged CPE's they should rather be encouraged than discouraged: - Free's customers have been using such products successfully for years now. - Being among them, I prefer this product behavior to that you suggest. - If punching holes in CPEs become as necessary in IPv6 as in IPv4 to have incoming connections, the main advantage of IPv6 is lost. Every OS that supports IPv6 has AFAIK its internal FW, at least to the point where its doesn't accept unwanted incoming connections. > 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 consistently opposed that. Fortunately it has become a vendor responsibility to decide whether unmanaged CPEs are shipped with transparent mode by default or not. My hope is that the majority of vendors of IPv6-capable unmanaged CPEs will understand that the transparent mode is the one that favors IPv6 deployment: - no need to manage CPEs to take advantage of incoming connectivity - unwanted incoming connectivity is filtered by OS internal firewalls > 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. IMHO, a reference would be better than alignment (but both work for me). Regards, RD _______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
