[email protected] wrote: > > Although by its nature IPv6 renders nat obsolete, it seems that in > practice many small setups prefers to use NAT instead of an extended > (seemingly too complicated) IPv6 proper configuration.
Adding NAT doesn't make it any less complicated - it just adds more complication and breaks things. For some "medium" sized setups there is a case for prefix translation*, but for small setups there really is no need for NAT - and many good reasons to avoid it like the plague (see the other thread running here at the moment about broken SIP - 100% a NAT problem). I think the problem is that people are now "comfortable" with IPv4 and want to carry on the same way - the "I've always done it this way" approach to change. For many of us, IPv4 was hard to get into (none of this plug and play malarkey that makes it easy for consumers these days). IPv6 has a learning curve, but it's worth the effort as it does far more than just add address space - it's an opportunity to leave baggage behind. NAT is one of those things to leave behind. If an ISP offers you a dynamic IPv6 prefix then ditch them and find one that has a clue/gives a **** ! The smallest delegation an ISP should be getting is a /32. If they delegated /64 prefixes then that would allow them to have 2^32 (4 billion !) customers with fixed delegations. Even offering /48s, they can have 65k customers. I suspect many will offer /56s which allows for 16 million customers. * Say you are a small-medium sized company, and you get 2 internet connections from 2 different providers. You'll get two different IPv6 prefixes delegated to you. The "official" way of handling that is to multi-home every host (ie give it an address from each provider). An alternative would be to apply prefix translation and use a "private" prefix internally. All address and port parts remain the same, only the prefix is altered - so no "port forwarding", only a single prefix translation rule and normal allow/permit firewall rules. It still breaks things, but it's simpler to work around - and I would hope that in time some standard will be done for a protocol for each host/service to determine what the translations are without having to mess around with helpers and STUN etc. The main reason for suggesting prefix translation in such a situation is to simplify load balancing and failover - keeping it in the router rather than pushing it out to the multihomed hosts. Larger outfits can go and get their own prefix and AS number, and so use the same prefix across multiple providers. Just my 2d worth on the subject. ------------------------------------------------------------------------------ Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk _______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
