Date: Thu, 14 May 1998 06:25:04 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: eivind@yes.no (Eivind Eklund) Cc: tlambert@primenet.com, brian@awfulhak.org, freebsd-hackers@FreeBSD.ORG Subject: Re: why /var/log/ppp.log Message-ID: <199805140625.XAA21648@usr05.primenet.com> In-Reply-To: <19980514051417.25127@follo.net> from "Eivind Eklund" at May 14, 98 05:14:17 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > > Possibly a good idea, due to the general confusion over terminology. > > > Aliasing is only a subset of the possible NAT forms. The library > > > should definately have been named libnat, at least :-) > > > > If you want to use the name it's called in the RFC's, you should > > use the term "transparent proxy" or just "proxy" for short. > > '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. 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. >From memory, the first use of these terms in reference to BSD came about from certain unnamed OS advocates trolling the FreeBSD "misc" usenet group asking "why doesn't FreeBSD support this feature?", using their own terminology because they had reinvented the feature without bothering to read the RFC's to notice that they weren't inventing something new, but rediscovering history. Nothing is more annoying than "not invented here" unless it's "not invented before". You will note that a NAT *MUST* have proxy facilities (FTP is specifically mentioned on page 7). 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). The "-alias" option is *NOT* "NAT". > > 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"). You can tell the difference between them when you go to do route autodiscovery. The table on page 31 of RFC1919 makes this even clearer. > 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. In general, the "NAT" terminology is imprecise. Imprecision is annoying, especially when its tied to historical trolls. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. 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?199805140625.XAA21648>