Date: Mon, 20 May 1996 17:23:35 -0700 From: bmah@cs.berkeley.edu (Bruce A. Mah) To: Terry Lambert <terry@lambert.org> Cc: bmah@cs.berkeley.edu, alk@think.com, questions@freebsd.org Subject: Re: ip masquerading Message-ID: <199605210023.RAA11139@premise.CS.Berkeley.EDU> In-Reply-To: Your message of "Mon, 20 May 1996 15:45:51 PDT." <199605202245.PAA28777@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert writes: > > 2. The Linux implementation (which I've examined *briefly*) puts all > > kinds of application-specific stuff *in kernel*. There are all kinds > > of clever tricks to get FTP, RealAudio, and other applications to work > > right. Layering? What layering? > > The packet rewriting is a bit annoying; on the other hand, there are > a finite number of protocols that really need to be supported this > way, so it's bad, but it's not as bad as it could be. Of course it'd be nice to fix protocols so they don't require these hacks (like change FTP not to require IP addresses to be passed in ASCII in the datastream). This isn't really practical, but I thought I'd mention it as an afterthought. I don't even want to think about how IP multicast applications would work with this thing. > > 3. There already exist other methods for doing what IP masquerading > > does (for example SOCKs, application-specific gateways). Why does > > FreeBSD need another? > > Socks really wants two additional tunnel-to-socks and socks-to-tunnel > daemons written; using two private nets, this would let you run a > private net of socks-unaware hosts that get their packets proxied > by setting up a default route, a private net route to one tunnel on > one private net, and a default route to the other tunnel on the > private net with the dumb hosts. Effectively, a gateway LLB in user > space. Dumb question: What's LLB? (You can send to me privately if it's a well-known term.) (Link-layer bridge?) > > Just so people don't think I'm completely one-sided about this: > > > > 1. IP masquerading does slow down the rate that addresses get used up, > > and, more importantly, the routing table size at the neighboring > > network. > > This is a weenie answer (I realize you're just quoting here ;-)) and > assumes IPv4 for eternity. It's bad because it codifies the current > system. What we're really talking about here is differences in charges > for routing table entries -- an artificial stair-step invented by some > ISP's to make money (their routing hardware generally doesn't care). I agree it's a weenie answer, but for the record I wasn't quoting...I had to think about 1/2 hour to come up with it. I also agree with most of the points you just made, especially the last one. However, the problem would be the same for IPv6 (I was thinking about using up addresses in an ISP's allocated address block, not the entire Internet). > > 2. Extremely reluctantly, "Linux does it". > > If Linus jumped off a bridge... 8-). Well...that one I was sort of paraphrasing... :-) Bruce.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199605210023.RAA11139>