On Mon, 6 Oct 2003, Ranjeet Shetye wrote: > On Mon, 2003-10-06 at 05:36, bill davidsen wrote: > > In article <1065035768.2548.8.camel@ranjeet-pc2.zultys.com>, > > Ranjeet Shetye <ranjeet.shetye2@zultys.com> wrote: > > > > | Here's my take on it. > > | > > | NAT is not an elegant standard. Its a hack to provide a temporary fix > > | for the IPv4 address space crunch. On the other hand, IPSec is a good > > | standard and is also mandatory for IPv6. Hence the focus should be on > > | IPSec much more than on NAT. > > > > I think you are starting from a totally incorrect premise. NAT is not a > > solution to an address space crunch, it is a way to have many servers > > behind a load balancing firewall, a way to have all outgoing mail come > > from a single IP (that of the inbound mail cluster), and a way to make > > all http clients have the same IP address (which doesn't accept any > > incoming connections) as part of a total security approach, to name a > > few uses. > > What you are describing is how people have adapted NAT from its original > purpose. DNS-based load-balancing is the "correct" way to do > load-balancing across publicly accessible servers that are protected > using packet filtering, but people want to shortcut all that using NAT. > Fine. I have no issues with that. Let people use whatever makes them > happy. DNS based load balancing doesn't work. Based on several dozzen machines in four timezones which I have been running for years, the response time if too slow to be useful. Users don't get new information quickly, don't use added servers, still use problem servers, etc. And since I can't control who ignores the timeout values in DNS, or which programs resolve once at boot time and run forever, a realtime association of IP to machine needs to be done to move load as soon as congestion happens, add new servers, do failover, and similar, because DNS is not realtime and load balancing is. > > However NAT does not provide ANY security from the knowledgeable e.g. > hping can work around NAT (using crafted RST responses) to give you an > idea of what the private network looks like. You want network level > security, do packet filtering (stateful preferably). You want VPN, use > IPSec. Guess the knowledgeable didn't work on nmap and any of the other commercial checkers I use then. Those programs reveal little information on a well-protected private net, and much of what they do return is bogus, based on easily generated misleading information. > > And to clarify, here's why NAT was designed in the first place. > > RFC 1631 > > " > Abstract > > The two most compelling problems facing the IP Internet are IP address > depletion and scaling in routing. Long-term and short-term solutions to > these problems are being developed. The short-term solution is CIDR > (Classless InterDomain Routing). The long-term solutions consist of > various proposals for new internet protocols with larger addresses. > > It is possible that CIDR will not be adequate to maintain the IP > Internet until the long-term solutions are in place. This memo proposes > another short-term solution, address reuse, that complements CIDR or > even makes it unnecessary. The address reuse solution is to place > Network Address Translators (NAT) at the borders of stub domains. Each > NAT box has a table consisting of pairs of local IP addresses and > globally unique addresses. The IP addresses inside the stub domain are > not globally unique. They are reused in other domains, thus solving the > address depletion problem. The globally unique IP addresses are assigned > according to current CIDR address allocation schemes. CIDR solves the > scaling problem. The main advantage of NAT is that it can be installed > without changes to routers or hosts. This memo presents a preliminary > design for NAT, and discusses its pros and cons. > " > > This clearly tells you that > 1. NAT was invented as an "address reuse" solution to solve the address > space crunch. > 2. NAT was a temporary solution that was to be discarded when IPv6 came > into its own. Tells you that (a) the RFC was written long ago, and (b) the RFC was only a codification of what was already in practice; nothing in it indicates that the authors had a clue what the Internet would become. The RFC describes how the authors were using it to solve what they saw as the problem of the day, in a much less hostile environment. -- bill davidsen <davidsen@tmr.com> CTO, TMR Associates, Inc Doing interesting things with little computers since 1979. - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
