Date: Thu, 14 May 1998 13:30:38 +0200 From: Eivind Eklund <eivind@yes.no> To: Terry Lambert <tlambert@primenet.com> Cc: brian@awfulhak.org, freebsd-hackers@FreeBSD.ORG Subject: Re: why /var/log/ppp.log Message-ID: <19980514133038.26270@follo.net> In-Reply-To: <199805140625.XAA21648@usr05.primenet.com>; from Terry Lambert on Thu, May 14, 1998 at 06:25:04AM %2B0000 References: <19980514051417.25127@follo.net> <199805140625.XAA21648@usr05.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, May 14, 1998 at 06:25:04AM +0000, Terry Lambert wrote: > > 'Transparent proxy' is not what we've got. We've got NAT - see > > RFC1631. I hope we'll get transparent proxy support in libalias, but > > it isn't too high on my list of priorities at the moment. > > RFC1631 is informational. RFC1919 is informational. RFC1918, however, > documents best current practice (it is officially "BCP5"). > > RFC1631 notes the use of a routable net, and specifically suggests > the use of a class A network, cv: RFC1597. > > "NAT" is for IPV4 address space reuse. That is one of it's uses. It can also be used e.g. to do load-balancing. > Even so, the terms "Masquerading" and "Network Address Translation" > have bugged me since they first began to be used to describe an > RFC1597 (obsoleted by RFC1918, but predating RFC1631) transparent > proxy. I agree that they are abused, and I agree that in some setups pure NAT functions indistingushable from a transparent proxy setup. That doesn't mean they're the same, any more than 'man' and 'woman' are the same, even if you sometimes can't see the difference when they're wearing coveralls. > You will note that a NAT *MUST* have proxy facilities (FTP is > specifically mentioned on page 7). I disagree with "*MUST*" here. A NAT that want to support protocols using separate connections back to the client from the server need special handling (which could be considered a proxy, but I'm slightly uncertain about whether this is correct, given that > Perhaps most damning is the inability to implement RFC1631 Figure 2 > topologies, and private network spanning of a public backbone (a > topology much better addressed by GRE and PTPP). Can do, though it can be inconvenient to setup - the interface is none too good. I'm planning to go back and look at that, but it goes along with a set of rewrites of other parts of the system (it has to hook in with IPFW and routing to be done properly). > The "-alias" option is *NOT* "NAT". Beg to differ. > > > The term "NAT" is generally meaningless, and doesn't imply some things > > > that it should, while at the same time imply some things it shouldn't. > > > It's too "fuzzy" to be truly meaningful. > > > > I'm not sure I follow you - for me, NAT is a very specific technology: > > Translating packets in transit to do manipulation of the address space. > > > > Transparent proxy, on the other hand, is a technology that re-assemble > > a stream (the easiest way of getting correct results for > > FTP/IRC(/CVSup?)) and then do a separate connection for that stream. > > I think you are fonfusing "NAT" with "ALG" -- Application Level > Gateway (or "classical application proxy"). Absolutely not, and I'm not certain how you could get that impression. NATwork on a packet-by-packet basis, and doesn't require any modifications. A classical proxy works by connecting to a host and sending in-band data, getting it to connect somewhere else. I don't see how I could confuse them. > You can tell the difference between them when you go to do route > autodiscovery. Sure. > The table on page 31 of RFC1919 makes this even clearer. The table lists only properties we agree on. I'm just arguing that NAT is a specific technology that can be used as a part of transparent proxies or on its own. On its own it can be used both as something that look like a transparent proxy (and probably meet the definition) and to do other translations. > > I can see the reasons for letting the definition for 'transparent > > proxy' flow to include the 'alias-to-single-address' versions of NAT > > (because it gives the exact same results if done properly), but I > > can't see how 'NAT' is fuzzy. Help me? > > The "-alias" option doesn't do what RFC1631 says NAT does. The effect > is the same. I've always considered NAT to be _any_ Network Address Translator - ie, a program that change IP-packets in transit to modify where they appear to come from or go to. With that defintion it's fairly precise, I think. Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980514133038.26270>